Ing Sistemas 17 PDF

TEMARIO
INGENIERIA DE SISTEMAS
1.- NORMA TECNICA PERUANA NTP ISO/IEC 12207-2006. TECNOLOGIA DE LA

INFORMACION. PROCESOS DEL CICLO DE VIDA DEL SOFTWARE.
2.- NORMA TECNICA PERUANA NTP ISO/IEC 27001-2014. TECNOLOGIA DE LA

INFORMACION. SISTEMAS DE GESTION DE SEGURIDAD DE LA INFORMACION.
3.- GUIA TECNICA SOBRE EVALUACION DE SOFTWARE PARA LA ADMINSITRACION

PUBLICA DEL 28-05-2004 (BASADA EN LA NORMA TECNICA PERUANA NTP ISO/IEC
9126-2004. INGENIERIA DE SOFTWARE. CALIDAD DE PRODUCTO).
4.- GESTION POR PROCESOS
5.- LENGUAJE DE MODELADO UNIFICADO UML
6.- PROGRAMACION ORIENTADA A OBJETOS
7.- DISEÑO DE BASE DE DATOS RELACIONAL
8.- SISTEMAS OPERATIVOS
9.- NETWORKING
NORMA TÉCNICA NTP-ISO/IEC 12207
PERUANA 2006
Comisión de Reglamentos Técnicos y Comerciales-INDECOPI
Calle de La Prosa 138, San Borja (Lima 41) Apartado 145 Lima, Perú
TECNOLOGÍA DE LA INFORMACIÓN. Procesos del

ciclo de vida del software
INFORMATION TECHNOLOGY. Software life cycle processes
(ISO/IEC 12207:1995 Amd 1:2002, Amd 2: 2005 INFORMATION TECHNOLOGY. Software life cycle
processes.)
2006-07-13
2ª Edición
R.0055-2006/INDECOPI-CRT. Publicada el 2006-07-28 Precio basado en 189 páginas

I.C.S.: 35.080 ESTA NORMA ES RECOMENDABLE
Descriptores: Tecnología de la información, software, ciclo de vida del software
ÍNDICE
página
ÍNDICE i
PREFACIO ii
INTRODUCCIÓN iv
1. OBJETO Y CAMPO DE APLICACIÓN 1
2. REFERENCIAS NORMATIVAS 4
3. DEFINICIONES 6
4. APLICACIÓN 12
5. PROCESOS PRINCIPALES DEL CICLO DE VIDA 16
6. PROCESOS DE APOYO DEL CICLO DE VIDA 50
7. PROCESOS ORGANIZATIVOS DEL CICLO DE VIDA 70
8. ANTECEDENTE 77
ANEXO A 78
ANEXO B 80
ANEXO C 87
ANEXO D 92
ANEXO E 93
ANEXO F 97
ANEXO G 144
ANEXO H 169
FIGURA 1 ESTRUCTURA DE LA NORMA TÉCNICA PERUANA 13
FIGURA B.1 EJEMPLO DE APLICACIÓN DE ESTA NTP 83
FIGURA C.1 PROCESOS DEL CICLO DE VIDA DEL SOFTWARE - 90

ROLES Y RELACIONES
FIGURA C.2 PROCESOS DEL CICLO DE VIDA DEL SOFTWARE - 91

VISIONES Y ACTIVIDADES
TABLA E.1 CORRELACIÓN DE ISO/IEC 12207:1995 AL ANEXO F 95
i
PREFACIO
A. RESEÑA HISTÓRICA
A.1 La presente Norma Técnica Peruana fue elaborada por el Comité Técnico
de Normalización de Ingeniería de Software y Sistemas de Información, mediante el
Sistema 1 ó de Adopción, durante los meses de enero a marzo del 2006, utilizando como
antecedente a la Norma ISO/IEC 12207:1995/Amd 1:2002/Amd 2:2005 Information
technology. Software life cycle processes.
A.2 El Comité Técnico de Normalización de Ingeniería de Software y Sistemas

de Información presentó a la Comisión de Reglamentos Técnicos y Comerciales – CRT,
con fecha 2006-04-21, el PNTP-ISO/IEC 12207:2006, para su revisión y aprobación,
siendo sometido a la etapa de Discusión Pública el 2006-06-09. No habiéndose presentado
observaciones fue oficializado como Norma Técnica Peruana NTP-ISO/IEC 12207:2006
TECNOLOGÍA DE LA INFORMACIÓN. Procesos del ciclo de vida del software, 2ª
Edición, el 28 de julio de 2006.
A.3 Esta Norma Técnica Peruana reemplaza a la NTP-ISO/IEC 12207:2004 y

es una adopción de la ISO/IEC 12207:1995/Amd 1:2002/Amd 2:2005. La presente
Norma Técnica Peruana presenta cambios editoriales referidos principalmente a
terminología empleada propia del idioma español y ha sido estructurada de acuerdo con las
Guías Peruanas GP 001:1995 y GP 002:1995.
B. INSTITUCIONES QUE PARTICIPARON EN LA ELABORACION

DE LA NORMA TECNICA PERUANA
Secretaría Pontificia Universidad Católica del

Perú
Presidente Zalatiel Carranza Avalos
Secretario Abraham Eliseo Dávila Ramón
Secretaria a.i. Silvana Marianela Bernaola Biggio
ENTIDAD REPRESENTANTE
Asociación de Bancos del Perú Iván Estrada Montano

ii
APESOFT Paul Deza Diaz
Guillermo Pacheco Martínez
ESSALUD Pedro Vásquez Campos

Gustavo Villalobos Saavedra
IBM del Perú S.A. Ricardo Haro

Gianfranco Gugliandolo
ONGEI César Vilchez Inga
Petróleos del Perú –PETRO PERU S.A. Ricardo Verri Morchio

Felix Llap Yesán
Pontificia Universidad Católica del Perú José Antonio Pow Sang Portillo
Karin Ana Melendez Llave
QUIPUDATA S.A. (Corp. Backus) Wilfredo Kleeberg Hidalgo

Mery Zúñiga Gamero
Sociedad Nacional de industrias Ewen Juárez Jiménez
Southern Perú Boris Gilberto Sulca Solari

Arturo Cueto Aservi
SUNAT Rosa Carrasco Aguado

Jaime Ohashi Yusa
Superintendencia de Banca, Seguros y Romel Alvarez Llanos

Administradoras Privadas de Fondos y Pensiones Jorge Palacios Pozo
Universidad de Lima María Cecilia Moreno Moreno

Miriam Amable Cuidad
Universidad Peruana de Ciencias Aplicadas Ludvik D. Medic Corrales

Ilver Anache Pupo
UNISYS del Perú Jaime Espinoza Castillo

Luis Romero
INEXXO Eduardo García Pacheco

José Luis Yauri
Universidad Femenina del Sagrado Corazón Juan Fernández Chavesta

Cecilia Gadea Rubio
iii
INTRODUCCIÓN
El software es una parte esencial de sistemas convencionales y de tecnologías de la

información, tales como sistemas de transporte, militares, médicos y financieros. Hay
una proliferación de normas, procedimientos, métodos, herramienta y entornos para
desarrollar y gestionar el software. Esta proliferación ha creado dificultades en la
gestión y en la ingeniería de software, especialmente en la integración de productos y
servicios. La disciplina del software necesita evolucionar desde esta proliferación, hacia
un marco de referencia común que pueda ser usado por los profesionales del software
para "hablar el mismo lenguaje", a la hora de crear y gestionar el software. Esta Norma
Técnica Peruana proporciona ese marco de referencia común.
Este marco de referencia cubre el ciclo de vida del software desde la conceptualización
de ideas hasta su retirada y consta de procesos para adquirir y suministrar productos y
servicios software. Cubre además el control y la mejora de estos procesos.
Los procesos que hay en esta Norma Técnica Peruana forman un conjunto completo. Una
organización, dependiendo de sus necesidades, puede seleccionar un sub-conjunto
apropiado para satisfacer dichas necesidades. Esta Norma Técnica Peruana está, así pues,
diseñada para ser adaptada a una organización, proyecto o aplicación concreta. Está
también diseñada para ser usada cuando el software es una entidad independiente, está
integrado o es parte integral del sistema total.
---oooOooo---
iv
PERUANA 1 de 189
TECNOLOGÍA DE LA INFORMACIÓN. Procesos del ciclo

de vida del software
1. OBJETO Y CAMPO DE APLICACIÓN
1.1 Objeto
Esta Norma Técnica Peruana establece un marco de referencia común para los procesos del
ciclo de vida del software, con una terminología bien definida a la que puede hacer
referencia la industria del software. Contiene procesos, actividades y tareas para aplicar
durante la adquisición de un sistema que contiene software, un producto software puro o
un servicio software y durante el suministro, desarrollo, operación y mantenimiento de
productos software. El software incluye la parte software del firmware.
Esta NTP incluye también un proceso que se puede emplear para definir, controlar y mejorar
los procesos del ciclo de vida del software.
1.2 Campo de aplicación
Esta NTP es aplicable a la adquisición de sistemas, productos y servicios software, al

suministro, desarrollo, operación y mantenimiento de productos software y a la parte software
del firmware, independientemente de que sea hecho interna o externamente a una
organización. Incluye también aquellos aspectos de la definición de sistema necesarios para
proporcionar el contexto de los productos y servicios software.
NOTA: Es necesario que los procesos utilizados durante el ciclo de vida del software sean compatibles
con los procesos usados durante el ciclo de vida del sistema.
Esta NTP está orientada para ser usada en situaciones en las que haya dos partes incluido el
caso en que estas dos partes pertenezcan a la misma organización. La situación puede ir desde
un acuerdo informal, hasta un contrato con responsabilidades legales. Esta NTP puede ser
usada por una sola parte como una autoimposición.
PERUANA 2 de 189
Este apartado no impide el uso de la NTP a los proveedores o desarrolladores de software

empaquetado.
Esta NTP está escrita para adquirientes de sistemas y productos y servicios software y para
proveedores, desarrolladores, operadores, responsables de mantenimiento, administradores,
responsables de aseguramiento de calidad y usuarios de productos software.
1.3 Adaptación de esta NTP
Esta NTP contiene un conjunto de procesos, actividades y tareas diseñadas para ser adaptadas
a los proyectos software. El proceso de adaptación consiste en la eliminación de los procesos,
actividades y tareas no aplicables.
NOTA: Los contratos pueden contemplar la adición de procesos, actividades o tareas únicas o
especiales.
1.4 Conformidad
Se define como conformidad de esta NTP la ejecución de todos los procesos, actividades y
tareas seleccionadas de esta NTP para el proyecto software, mediante el proceso de
adaptación (Anexo A). La ejecución de un proceso o una actividad es completa cuando todas
las tareas requeridas por el proceso o actividad se llevan a cabo de acuerdo con los criterios
preestablecidos y los requerimientos que han sido especificados como aplicables dentro del
contrato.
Cualquier organización (nacional, asociación industrial, compañía, etc.) que imponga esta
NTP como condición para tener relaciones comerciales es responsable de especificar y hacer
público el conjunto mínimo de procesos, actividades y tareas que constituyen la conformidad
de esta NTP por parte del proveedor.
1.4.1 Conformidad a los Propósitos y Resultados
El Anexo F provee una forma alternativa de conformidad útil en situaciones donde los
procesos implementados son concebidos para alcanzar las mismas metas de aquellos
descritos en esta NTP, pero que podrían no implementar las especificaciones detalladas
PERUANA 3 de 189
prescritas en el cuerpo de esta NTP. Para dar conformidad, será demostrado que, para
cualquier proceso del conjunto de procesos declarados por la organización, la
implementación de los resultados de los procesos en la realización del propósito y
resultados correspondientes proporcionados en el anexo F. Cualquier organización definirá
el conjunto de procesos que le son aplicables, considerando el conjunto propuesto de
procesos descritos en el anexo F y sus propios parámetros de entorno. La aplicación del
estándar permite la creación de resultados adicionales.
NOTA: En la ISO/IEC 12207:1995 se utiliza el término "cumplimiento" en el apartado 1.4; sin

embargo, de acuerdo con la Guía 2 ISO/IEC, Estandarización y Actividades Relacionadas –
Vocabulario General, “conformidad” es el término apropiado para este apartado. La conformidad es
el cumplimiento para un producto, proceso o servicio de requerimientos especificados.
1.5 Limitaciones
Esta NTP describe la arquitectura de los procesos del ciclo de vida del software, pero no
especifica los detalles de cómo implementar o llevar a cabo las actividades y tareas
incluidas en los procesos.
Esta NTP no pretende establecer el nombre, el formato o el contenido explícito de la

documentación que se genere. Si bien esta NTP puede requerir la elaboración de diversos
documentos de tipo o clase similares (un ejemplo son los distintos tipos de planes), esto no
implica que dichos documentos se desarrollen, agrupen o mantengan separados de alguna
manera. Estas decisiones se dejan para el usuario de esta NTP.
Esta NTP no establece un modelo de ciclo de vida concreto para el desarrollo del software. En
esta NTP las partes son las responsables de seleccionar un modelo de ciclo de vida para el
proyecto software y de elaborar una correspondencia entre los procesos, actividades y tareas
de esta NTP y los de dicho modelo. Las partes son también responsables de seleccionar y
aplicar los métodos de desarrollo de software y de llevar a cabo las actividades y tareas
adecuadas para el proyecto software.
Esta NTP no pretende entrar en conflicto con las políticas, normas o procedimientos
actualmente en vigor en ninguna organización. Sin embargo, es necesario resolver
cualquier conflicto que surja, documentando por escrito en forma de excepción cualquier
incumplimiento de esta NTP autorizado por las partes.
PERUANA 4 de 189
A lo largo de esta NTP, “deberá” se usa para expresar una disposición obligatoria entre dos o
más partes, otros verbos en futuro para expresar una declaración de propósitos o intenciones
por una de las partes. “Debería” o “conviene que” se emplea para expresar una
recomendación habiendo otras posibilidades y “puede” o “podría” para expresar algo
permisible dentro de los límites de esta NTP.
En esta NTP, hay listas de tareas; no se pretende que sean completas, sino que se dan como
ejemplos, a menos que las listas sean precedidas por la palabra “deberá”.
2. REFERENCIAS NORMATIVAS
Las siguientes normas contienen disposiciones que al ser citadas en este texto, constituyen
requisitos de esta NTP. Las ediciones indicadas estaban en vigencia en el momento de esta
publicación. Como toda norma está sujeta a revisión, se recomienda a aquellos que realicen
acuerdos en base a ellas, que analicen la conveniencia de usar las ediciones recientes de las
normas citadas seguidamente. El Organismo Peruano de Normalización posee, en todo
momento, la información de las Normas Técnicas Peruanas en vigencia.
2.1 Normas Técnicas Internacionales
2.1.1 ISO/IEC 2382 - 1:1993 Information technology – Vocabulary – Part 1:

Fundamental terms
2.1.2 ISO/IEC 2382 - 20:1990 Information technology – Vocabulary – Part

20: System development
2.1.3 ISO/IEC 15504 – 2:2003 Software Engineering – Software process

assessment – Part 2: Performing an assessment.
2.1.4 ISO 13407:1999 Human-centred design processes for

interactive systems
2.1.5 ISO/IEC 15535:2003 General requirements for establishing

anthropometric databases
PERUANA 5 de 189
2.2 Normas Técnicas Peruanas
2.2.1 NTP-ISO 9000:2001 Sistema de gestión de la calidad.

Fundamentos y vocabularios
2.2.2 NTP-ISO 9001:2001 Sistemas de gestión de calidad. requisitos
2.2.3 NTP-ISO 14001:2002 Sistemas de gestión ambiental.

Especificación con orientación para su uso
2.2.4 NTP-ISO/IEC 9126 – 1: 2004 Ingeniería de software – Calidad de Producto

– Parte 1: Modelo de calidad.
2.2.5 NTP-ISO/IEC 12119:2005 Tecnología de la información – Paquetes

Software – Requerimientos de calidad y
pruebas.
2.2.6 NTP-ISO/IEC 14598 – 1:2004 Tecnología de la información –

Evaluación del producto software – Parte
1: Vista general
2.2.7 NTP-ISO/IEC TR 9126 – 2:2004 Ingeniería de software – Calidad de

producto - Parte 2: Métricas externas.
2.2.8 NTP-ISO/IEC TR 9126 – 3:2004 Ingeniería de software –Calidad de

producto – Parte 3: Métricas internas.
PERUANA 6 de 189
3. DEFINICIONES
Para los propósitos de esta NTP se aplican las definiciones dadas en la NTP-ISO 9000,
ISO/IEC 2382-1 y la ISO/IEC 2382-20 y las siguientes:
NOTA: Cuando aplique, se puede interpretar “producto” como una parte de un sistema.
3.1 acuerdo: Definición de términos y condiciones bajo los cuales se ha de

desarrollar una relación de trabajo.
3.2 adquisición: El proceso de obtener un sistema, producto software o servicio

software.
3.3 adquiriente: El que adquiere u obtiene un sistema, producto software o

servicio software, de un proveedor.
NOTA: Adquiriente puede ser el comprador, cliente, dueño, usuario, pagador.
3.4 aseguramiento de la calidad: Parte de la gestión de la calidad orientada a

proporcionar confianza en que se cumplirán los requisitos de la calidad. (NTP-ISO 9000).
3.5 auditoría: Proceso sistemático, independiente y documentado para obtener

evidencias de la auditoría y evaluarlas de manera objetiva con el fin de determinar la
extensión en que se cumplen los criterios de auditoría.
NOTA: Las auditorías internas, denominadas en algunos casos como auditorías de primera parte, se
realizan por, o en nombre, de la propia organización para fines internos y puede constituir la base
para la auto-declaración de conformidad de una organización.
Las auditorías externas incluyen lo que se denomina generalmente “auditorías de segunda o tercera
parte”.
Las auditorías de segunda parte se llevan a cabo por partes que tienen un interés en la organización,
tal como los clientes, o por otras personas en su nombre.
PERUANA 7 de 189
Las auditorías de tercera parte se llevan a cabo por organizaciones independientes externas. Tales
organizaciones proporcionan la certificación o el registro de conformidad con requisitos como los de
las Normas NTP-ISO 9001 e ISO 14001.
Cuando se auditan sistemas de gestión ambiental y de la calidad juntos, se denomina “auditoría

combinada”.
Cuando dos o más organizaciones auditoras cooperan para auditar a un único auditado, se denomina
“auditoría conjunta”.
La auditoría se refiere a productos y procesos de software. (NTP-ISO 9000).
3.6 calificación: Proceso para demostrar la capacidad para cumplir los

requisitos especificados.
NOTAS:
1. El término “calificado” se utiliza para designar el estado correspondiente.

2. La calificación se puede aplicar a personas, productos, procesos o sistemas. Por ejemplo:
Proceso de calificación del auditor, proceso de calificación del material. (NTP-ISO 9000).
3.7 cobertura de las pruebas: Grado en que los casos de prueba prueban los
requerimientos del sistema o producto software.
3.8 contrato: Acuerdo vinculante entre dos partes o más, especialmente

exigible por ley, o acuerdo del mismo estilo totalmente interno a una organización, para el
suministro de un servicio software, o para el suministro, desarrollo, producción, operación
o mantenimiento de un producto software.
3.9 desarrollador: Organización que lleva a cabo actividades de desarrollo

(incluyendo análisis de los requerimientos, diseño y pruebas hasta la aceptación) durante el
proceso del ciclo de vida del software.
3.10 elemento de configuración: Entidad dentro de una configuración que

satisface una funcionalidad y que puede ser unívocamente identificada en un punto de
referencia dado.
PERUANA 8 de 189
3.11 elemento no entregable: Producto hardware o software cuya entrega no es

requerida por el contrato, pero que puede ser empleado en el desarrollo de un producto
software.
3.12 especificación del trabajo: Documento usado por el adquiriente como

medio para describir y especificar las tareas a llevar a cabo bajo contrato.
3.13 evaluación: Determinación sistemática del grado en que una entidad

cumple con los criterios especificados para ella.
3.14 firmware: Combinación de un dispositivo de hardware e instrucciones de

computadora o datos de computadora que reside como software de sólo lectura en el
dispositivo hardware. Este software no se puede modificar fácilmente bajo el control del
programa que lo usa.
3.15 línea base: Versión formalmente aprobada de un elemento de

configuración, independientemente del soporte, formalmente identificada y fijada en un
momento dado de su ciclo de vida.
3.16 modelo del ciclo de vida: Marco de referencia que contiene los procesos,
actividades y tareas involucradas en el desarrollo, operación y mantenimiento de un
producto software y que abarca toda la vida del sistema desde la definición de sus
requerimientos hasta el final de su uso.
3.17 operador: Organización que opera el sistema.
3.18 proceso: Conjunto de actividades mutuamente relacionadas o que

interactúan, las cuales transforman elementos de entrada en resultados.
NOTAS:
1. Los elementos de entrada de un proceso son generalmente resultados de otros procesos.

2. Los procesos de una organización son generalmente planificados y puestos en práctica bajo
condiciones controladas para aportar valor.
3. Un proceso en el cual la conformidad del producto resultante, no pueda ser fácil o
económicamente verificada, se denomina habitualmente “proceso especial”. (NTP-ISO 9000).
PERUANA 9 de 189
3.19 producto preelaborado (off-the-shelf): Producto ya desarrollado y

disponible, utilizable “tal cual” o con modificaciones.
3.20 producto software: Conjunto de programas de computadora,

procedimientos y posible documentación y datos asociados.
3.21 propósito del proceso: El objetivo de alto nivel de realizar el proceso y los
probables resultados de la implementación eficaz del proceso. La implementación del
proceso debe proveer beneficios tangibles a los involucrados.
3.22 proveedor: Organización que es contratada por el adquiriente para el

suministro de un sistema, producto software o servicio software, bajo los términos del
contrato.
NOTAS:
1. El término "proveedor" es sinónimo de contratista, fabricante, suministrador, productor o

vendedor.
2. El adquiriente puede designar a parte de su organización como proveedor.
3.23 pruebas de calificación: Pruebas llevadas a cabo por el desarrollador y

presenciadas por el adquiriente (como corresponda) para demostrar que el producto
software cumple sus especificaciones y está listo para ser usado en su entorno de destino.
3.24 release: Versión concreta de un elemento de configuración que se hace

disponible para un propósito determinado (por ejemplo, release para pruebas).
3.25 requerimientos de calificación: Conjunto de criterios o condiciones que

deben cumplirse para calificar que un producto software cumple con sus especificaciones y
está listo para ser usado en su entorno de destino.
3.26 responsable de mantenimiento: Organización que lleva a cabo actividades

de mantenimiento.
PERUANA 10 de 189
3.27 resultado del proceso (salidas): Un resultado observable del logro exitoso
del propósito del proceso.
NOTAS:
1. Una declaración del resultado describe uno de los siguientes ítems:
- Producción de un artefacto;
- Un cambio significativo en el estado;
- Conocimiento de las restricciones especificadas. Por ejemplo, requerimientos, metas, etc.
2. Una lis ta de los resultados de los procesos principales forma parte de la descripción de cada
proceso en el modelo referencial.
3.28 retirada: Cese del soporte activo por parte de la organización de operación
y mantenimiento, sustitución parcial o total por un nuevo sistema, o instalación de un
sistema mejorado.
3.29 seguridad de acceso: Protección de información y datos de manera que las

personas o sistemas no autorizados no puedan leerlos ni modificarlos y que permita el
acceso a las personas o sistemas autorizados.
3.30 servicio software: Ejecución de actividades, trabajos o tareas relacionadas a

un producto software, tales como su desarrollo, operación y mantenimiento.
3.31 sistema informático: Conjunto de elementos relacionados compuesto por

uno o más procesos, hardware, software, instalaciones y personal que proporcionan la
capacidad de satisfacer una necesidad u objetivo definido.
3.32 solicitud de propuestas: Documento utilizado por el adquiriente como

mecanismo para anunciar su intención a potenciales ofertantes, de adquirir un sistema
especificado, un producto software o un servicio software.
3.33 supervisión: Examen del estado de las actividades de un proveedor

referidas al cumplimiento del contrato y de sus resultados, por el adquiriente o por una
tercera parte.
PERUANA 11 de 189
3.34 testeabilidad (testability): Grado en que es posible definir una prueba

objetiva y viable, que permita determinar si se cumple un requerimiento.
3.35 unidad software: Pieza de código compilable por separado.
3.36 usuario: Individuo u organización que utiliza el sistema en operación para

llevar a cabo una función específica.
NOTA: El usuario puede llevar a cabo otros papeles, tales como el de adquiriente, desarrollador, o
responsable de mantenimiento.
3.37 validación: Confirmación mediante el suministro de evidencia objetiva de

que se han cumplido los requerimientos para una utilización o aplicación específica
prevista.
NOTAS:
1. El término “validado” se utiliza para designar el estado correspondiente.

2. Las condiciones de utilización para validación pueden ser reales o simuladas. (NTP-ISO
9000)
3.38 verificación: Confirmación mediante la aportación de evidencia objetiva de

que se han cumplido los requerimientos especificados.
NOTAS:
1. El término “verificado” se utiliza para designar el estado correspondiente.

2. La confirmación puede comprender acciones tales como:
- la elaboración de cálculos alternativos,

- la comparación de una especificación de un diseño nuevo con una especificación de un
diseño similar aprobado,
- la realización de ensayos/pruebas y demostraciones y
- la revisión de los documentos antes de su release. (NTP-ISO 9000).
3.39 versión: Ejemplar identificado de un elemento de configuración.

PERUANA 12 de 189
NOTA: Modificar una versión de un producto software dando como resultado una nueva versión,
requiere una acción de gestión de configuración.
4. APLICACIÓN
Este capítulo presenta los procesos del ciclo de vida que se pueden emplear para adquirir,
suministrar, desarrollar, operar y mantener productos software. El objetivo es proporcionar
un mapa para que los usuarios de esta NTP puedan orientarse en ella y aplicarla
adecuadamente.
4.1 Organización
4.1.1 Procesos del ciclo de vida
Esta NTP agrupa las actividades que se pueden llevar a cabo durante el ciclo de vida del
software en cinco procesos principales, ocho procesos de apoyo y cuatro procesos
organizativos. Cada proceso del ciclo de vida está divido en un conjunto de actividades;
cada actividad se sub-divide a su vez en un conjunto de tareas. Los apartados numerados
a.b identifican procesos, los numerados a.b.c actividades y los numerados a.b.c.d tareas. A
continuación se hace una introducción de cada proceso, representado en la Figura 1.
4.1.1.1 Procesos principales del ciclo de vida
Los procesos principales del ciclo de vida (capítulo 5) son cinco, que dan servicio a las
partes principales durante el ciclo de vida del software. Una parte principal es aquella que
inicia o lleva a cabo el desarrollo, operación, o mantenimiento de los productos software.
Estas partes principales son el adquiriente, el proveedor, el desarrollador, el operador y el
responsable de mantenimiento de productos software. Los procesos principales son:
1) Proceso de adquisición (apartado 5.1). Define las actividades del

adquiriente, la organización que adquiere un sistema, producto software o servicio
software.
PERUANA 13 de 189
2) Proceso de suministro (apartado 5.2). Define las actividades del proveedor,

organización que proporciona un sistema, producto software o servicio software al
adquiriente.
3) Proceso de desarrollo (apartado 5.3). Define las actividades del

desarrollador, organización que define y desarrolla el producto software.
4) Proceso de operación (apartado 5.4). Define las actividades del operador,

organización que proporciona el servicio de operar un sistema informático en su
entorno real, para sus usuarios.
5) Proceso de mantenimiento (apartado 5.5). Define las actividades del

responsable de mantenimiento, organización que proporciona el servicio de
mantenimiento del producto software; esto es, la gestión de las modificaciones al
producto software para mantenerlo actualizado y operativo. Este proceso incluye la
migración y retirada del producto software.
5. PROCESOS PRINCIPALES 6. PROCESOS DE APOYO

DEL CICLO DE VIDA DEL CICLO DE VIDA
5.1 Adquisición 6.1 Documentación
6.2 Gestión de la Configuración

5.2 Suministro
6.3 Aseguramiento de la
Calidad
6.4 Verificación
5.4 Operación
6.5 Validación
5.3
Desarrollo
6.6 Revisión Conjunta
5.5
Mantenimiento 6.7 Auditoría
6.8 Solución de Problemas
7. PROCESOS ORGANIZATIVOS DEL CICLO DE VIDA
7.1 Gestión 7.2 Infraestructura
7.4 Recursos
7.3 Mejora Humanos
Figura 1 - de
FIGURA 1 – Estructura Estructura de la norma
la norma técnica peruana
PERUANA 14 de 189
4.1.1.2 Procesos de apoyo del ciclo de vida
Hay ocho procesos de apoyo del ciclo de vida (capítulo 6). Un proceso de apoyo es el que
apoya a otro proceso como parte esencial del mismo, con un propósito bien definido y
contribuye al éxito y calidad del proyecto software. Un proceso de apoyo se emplea y
ejecuta por otro proceso, según sus necesidades.
Los procesos de apoyo son:
a) Proceso de documentación (apartado 6.1). Define las actividades para el

registro de la información producida por un proceso del ciclo de vida.
b) Proceso de gestión de la configuración (apartado 6.2). Define las

actividades de la gestión de la configuración.
c) Proceso de aseguramiento de la calidad (apartado 6.3). Define las

actividades para asegurar, de una manera objetiva, que los productos software y los
procesos son conformes a sus requerimientos especificados y se ajustan a sus planes
establecidos. Revisión Conjunta, Auditoría, Verificación y Validación pueden ser
utilizados como técnicas de Aseguramiento de la Calidad.
d) Proceso de verificación (apartado 6.4). Define las actividades (para el

adquiriente, proveedor o una parte independiente) para verificar hasta un nivel de
detalle dependiente del proyecto software, los productos software.
e) Proceso de validación (apartado 6.5). Define las actividades (para el

adquiriente, proveedor o una parte independiente) para validar los productos software
del proyecto software.
f) Proceso de revisión conjunta (apartado 6.6). Define las actividades para

evaluar el estado y productos de una actividad. Este proceso puede ser empleado por
cualquiera de las dos partes, donde una de las partes (la revisora) revisa a la otra
parte (la parte revisada), de una manera conjunta.
PERUANA 15 de 189
g) Proceso de auditoría (apartado 6.7). Define las actividades para determinar

la conformidad con los requerimientos, planes y contrato. Este proceso puede ser
empleado por dos partes cualesquiera, donde una parte (la auditora) audita los
productos software o actividades de otra parte (la auditada).
h) Proceso de solución de problemas (apartado 6.8). Define las actividades

para analizar y eliminar los problemas (incluyendo las no conformidades) que sean
descubiertos durante la ejecución del proceso de desarrollo, operación,
mantenimiento u otros procesos, cualesquiera que sea su naturaleza o causa.
4.1.1.3 Procesos organizativos del ciclo de vida: Los procesos organizativos del
ciclo de vida (capítulo 7) son cuatro. Se emplean por una organización para establecer e
implementar una infraestructura constituida por procesos y personal asociado al ciclo de
vida y para mejorar continuamente esta infraestructura. Se usan habitualmente fuera del
ámbito de proyectos y contratos específicos; sin embargo, la experiencia adquirida
mediante dichos proyectos y contratos contribuye a la mejora de la organización. Los
procesos organizativos son:
a) Proceso de gestión (apartado 7.1). Define las actividades básicas de

gestión, incluyendo la gestión de proyectos, durante un proceso del ciclo de vida.
b) Proceso de infraestructura (apartado 7.2). Define las actividades básicas

para establecer la infraestructura de un proceso del ciclo de vida.
c) Proceso de mejora de proceso (apartado 7.3). Define las actividades

básicas que una organización (adquiriente, proveedor, desarrollador, operador,
responsable de mantenimiento o gestor de otro proceso) lleva a cabo para establecer,
medir, controlar y mejorar sus procesos del ciclo de vida.
d) Proceso de recursos humanos (apartado 7.4). Define las actividades

básicas para conseguir personal adecuadamente capacitado.
4.1.2 Proceso de adaptación. El anexo A, que es informativo, define las

actividades básicas necesarias para llevar a cabo adaptaciones de esta NTP. El Anexo B
proporciona una breve guía sobre cómo adaptar las directrices de esta NTP; enumera los
factores claves sobre los que se pueden basar las decisiones de adaptación.
PERUANA 16 de 189
4.1.3 Relación entre los procesos y las organizaciones. Esta NTP contiene
varios procesos que se aplican a lo largo del ciclo de vida del software por varias
organizaciones dependiendo de sus necesidades y metas. Para facilitar la comprensión, el
anexo C presenta las relaciones entre los procesos del ciclo de vida y las partes
relacionadas.
4.2 Relación entre el Anexo F y el texto principal de esta NTP
El Anexo F define un Modelo Referencial del Proceso (MRP) en un nivel de abstracción

más alto que el de los requerimientos detallados contenidos en el texto principal de esta
NTP. El MRP es aplicable a una organización que esté evaluando sus procesos para
determinar la capacidad de los mismos. El propósito y los resultados proporcionados en el
Anexo F son una declaración de las metas del desempeño de cada proceso. Esta
declaración de metas permite la evaluación de la eficacia de los procesos de una manera
más simple que la evaluación de conformidad. Por ejemplo, las nuevas definiciones del
proceso se pueden evaluar contra las declaraciones del propósito y los resultados en el
Anexo F más que contra provisiones detalladas en el texto principal de esta NTP.
NOTAS:
1. El término “modelo referencial del proceso” es utilizado con el mismo significado que la
revisión prevista de la ISO/IEC 15504-2.
2. El MRP está concebido para desarrollar modelo(s) de evaluación para evaluar procesos
usando la ISO/IEC 15504-2.
3. Los procesos descritos en el anexo F contienen las extensiones, elaboraciones y algunos
nuevos procesos donde no hay el correspondiente desarrollo de actividades y tareas en la ISO/IEC
12207. Esto será rectificado durante la revisión completa de la ISO/IEC 12207. Mientras tanto, los
nuevos apartados 6.9, 7.1.6 y 7.4 a la 7.7 proveen de actividades y tareas para los "nuevos" procesos
del anexo F.
5. PROCESOS PRINCIPALES DEL CICLO DE VIDA
Este capítulo define los siguientes procesos principales del ciclo de vida:
1. Proceso de adquisición.
2. Proceso de suministro.
PERUANA 17 de 189
3. Proceso de desarrollo.
4. Proceso de operación.
5. Proceso de mantenimiento.
Las actividades y tareas en un proceso primario son responsabilidad de la organización que

lo inicia y ejecuta. Esta organización asegura que ese proceso existe y es operativo.
5.1 Proceso de adquisición
El proceso de adquisición contiene las actividades y las tareas del adquiriente. El proceso
comienza con la identificación de la necesidad de adquirir un sistema, un producto
software o un servicio software. El proceso continúa con la preparación y publicación de
una solicitud de propuestas, la selección de un proveedor y la gestión del proceso de
adquisición hasta la aceptación del sistema, del producto software o del servicio software.
La organización concreta que tiene la necesidad puede ser llamada el propietario. El

propietario puede contratar todas o parte de las actividades de la adquisición a un tercero
que ejecutará por su parte estas actividades, de acuerdo con el proceso de adquisición. En
este apartado el adquiriente puede ser tanto el propietario como el tercero.
El adquiriente gestiona el proceso de adquisición al nivel del proyecto siguiendo el proceso

de gestión (7.1), que se emplea en este proceso; establece una infraestructura basada en el
proceso que se sigue en el proceso de infraestructura (7.2); adapta el proceso al proyecto
siguiendo el proceso de adaptación (Anexo A); y gestiona el proceso al nivel de
organización siguiendo el proceso de la mejora de proceso (7.3) y el proceso de recursos
humanos (7.4).
Lista de actividades: Este proceso consiste en las siguientes actividades:
a) Inicio.
b) Preparación de la solicitud de propuestas.
c) Preparación y actualización del contrato.

PERUANA 18 de 189
d) Seguimiento del proveedor.
e) Aceptación y finalización.
5.1.1 Inicio: Esta actividad consta de las siguientes tareas:
5.1.1.1 El adquiriente inicia el proceso de adquisición describiendo un concepto o

una necesidad de adquirir, desarrollar o de mejorar un sistema, producto software o un
servicio del software.
5.1.1.2 El adquiriente definirá y analizará los requerimientos del sistema. Conviene

que los requerimientos del sistema incluyan requerimientos de negocio, organizativos, de
usuario, así como de seguridad física y de acceso y otros requerimientos críticos, junto con
los procedimientos y normas de diseño, pruebas y conformidad relacionados.
5.1.1.3 Si el adquiriente contrata a un proveedor para llevar a cabo el análisis de

requerimientos del sistema, el adquiriente aprobará los requerimientos analizados.
5.1.1.4 El adquiriente puede llevar a cabo él mismo la definición y análisis de los

requerimientos software, o puede contratar a un proveedor para llevar a cabo dicha
actividad.
5.1.1.5 Conviene que se use el proceso del desarrollo (5.3) para llevar a cabo las
tareas de los apartados 5.1.1.2 y 5.1.1.4. El adquiriente puede usar los sub-procesos de
obtención de requerimientos descritos en el Anexo F para establecer los requerimientos del
cliente.
5.1.1.6 El adquiriente considerará las opciones para la adquisición a partir del

análisis de los criterios apropiados que incluya los riesgos, costos y beneficios de cada
opción. Las posibles opciones son:
a) Comprar un producto software preelaborado que satisfaga los

requerimientos.
PERUANA 19 de 189
b) Desarrollar el producto de software u obtener el servicio del software

internamente.
c) Desarrollar el producto de software u obtener el servicio del software

mediante un contrato.
d) Una combinación de a, b y c.
e) Mejorar un producto de software ya existente.
5.1.1.7 Cuando se vaya a adquirir un producto software preelaborado, el

adquiriente se asegurará que se satisfacen las siguientes condiciones:
a) Se cumplen los requerimientos del producto software.
b) La documentación está disponible.
c) Se respetan los derechos de marca, uso, propiedad, garantía y licencia.
d) Se ha planificado el soporte futuro al producto software.
5.1.1.8 Conviene que el adquiriente prepare, documente y ejecute un plan de

adquisición. El plan debería incluir lo siguiente:
a) Requerimientos para el sistema.
b) Empleo previsto del sistema.
c) Tipo de contrato a emplear.
d) Responsabilidades de las organizaciones implicadas.
e) Tipo de soporte que se va a usar.
f) Riesgos considerados y procedimientos para gestionar dichos riesgos.
5.1.1.9 Conviene que el adquiriente defina y documente la estrategia y condiciones

(criterios) de aceptación.
PERUANA 20 de 189
5.1.2 Preparación de la solicitud de propuestas: Esta actividad consta de las

siguientes tareas:
5.1.2.1 Conviene que el adquiriente documente los requerimientos de la adquisición

(por ejemplo, una solicitud de propuestas), cuyo contenido dependerá de la opción
seleccionada para la adquisición (apartado 5.1.1.6). La documentación de la adquisición
debe incluir, según proceda:
a) Requerimientos del sistema.
b) Definición del alcance.
c) Instrucciones para los ofertantes.
d) Lista de los productos de software.
e) Términos y condiciones.
f) Control de los sub-contratos.
g) Restricciones técnicas (por ejemplo, entorno de destino).
5.1.2.2 Conviene que el adquiriente determine qué procesos, actividades y tareas de

esta NTP son apropiados para el proyecto y adaptarlos convenientemente. El adquiriente
debería especificar especialmente los procesos de apoyo aplicables (capítulo 6) y las
organizaciones que los van a llevar acabo, incluyendo responsabilidades (cuando no
correspondan al propio proveedor), de modo que los proveedores, en sus propuestas,
puedan plantear su enfoque a cada uno de los procesos de soporte especificados. El
adquiriente definirá el alcance de cada una de las tareas que aparezcan en el contrato.
5.1.2.3 La documentación de la adquisición definirá también los hitos del contrato

en los que el progreso del proveedor será revisado y auditado como parte de la supervisión
de la adquisición (véase apartados 6.6 y 6.7).
5.1.2.4 Se deberían proporcionar a la organización seleccionada, los requerimientos

de la adquisición para llevar a cabo las actividades de la adquisición.
PERUANA 21 de 189
5.1.3 Preparación y actualización del contrato: Esta actividad consta de las

siguientes tareas:
5.1.3.1 Conviene que el adquiriente establezca un procedimiento para la selección

de proveedores, que incluya los criterios para la evaluación de propuestas y para la
ponderación del cumplimiento de los requerimientos.
5.1.3.2 Conviene que el adquiriente seleccione un proveedor basándose en la

evaluación de las propuestas de los proveedores, su capacidad y otros factores que deban
tenerse en cuenta.
5.1.3.3 Con el fin de adaptar esta NTP al proyecto, el adquiriente puede involucrar
a otras partes, incluso proveedores potenciales, antes de otorgar el contrato. En cualquier
caso el adquiriente tendrá la última palabra en las adaptaciones. El adquiriente incluirá o
hará referencia en el contrato a la norma adaptada.
5.1.3.4 El adquiriente preparará y negociará un contrato con el proveedor

estableciendo los requerimientos de la adquisición, incluyendo costos y plazos del
producto o servicio software a entregar. El contrato tendrá en cuenta los derechos de
marca, uso, propiedad, garantía y licencia asociados a los componentes pre-elaborados
reutilizables.
5.1.3.5 Una vez que el contrato está en curso, el adquiriente controlará las
modificaciones del contrato por la vía de la negociación con el proveedor, como parte del
mecanismo de control de cambios. Las modificaciones al contrato serán investigadas con
relación al posible impacto en los planes, costo, beneficios, calidad y plazos del proyecto.
NOTA: El adquiriente es el que determina si se ha de usar el término “contrato” o el término

“acuerdo” con relación a la aplicación de esta NTP.
5.1.4 Seguimiento del proveedor: Esta actividad consta de las siguientes tareas:
5.1.4.1 El adquiriente supervisará las actividades del proveedor de acuerdo con el

proceso de revisión conjunta (6.6) y el proceso de auditoría (6.7). Conviene que el
adquiriente complemente la supervisión con el proceso de verificación (6.4) y el proceso
de validación (6.5), según sea necesario.
PERUANA 22 de 189
5.1.4.2 El adquiriente cooperará con el proveedor para proporcionar toda la

información necesaria en el momento preciso y resolver todos los asuntos pendientes.
5.1.5 Aceptación y finalización: Esta actividad consta de las siguientes tareas:
5.1.5.1 Conviene que el adquiriente prepare la aceptación basándose en la estrategia

y los criterios de aceptación definidos. Deberían incluirse la preparación de los casos de
prueba, datos de prueba, procedimientos de prueba y entorno de las pruebas. Debería
definirse hasta qué grado se involucra al proveedor.
5.1.5.2 El adquiriente llevará a cabo revisiones de aceptación y pruebas de

aceptación del producto o servicio software entregable y sólo lo aceptará del proveedor
cuando se satisfagan todas las condiciones de aceptación. El procedimiento de aceptación
debería cumplir con lo dispuesto en el apartado 5.1.1.9.
5.1.5.3 Tras la aceptación, el adquiriente debería asumir la responsabilidad sobre la

gestión de la configuración del producto software entregado (véase el apartado 6.2).
NOTA: El adquiriente puede instalar el producto software o llevar a cabo el servicio software de
acuerdo con las instrucciones definidas por el proveedor.
5.2 Proceso de suministro
El proceso de suministro contiene las actividades y tareas del proveedor. El proceso se

puede iniciar ya sea por la decisión de preparar una oferta para contestar a una solicitud de
propuestas de un adquiriente, o por la firma e inicio de un contrato con el adquiriente para
proporcionarle un sistema, producto software o servicio software. El proceso continúa con
la determinación de los procedimientos y recursos necesarios para gestionar ty asegurar el
proyecto, incluyendo la preparación y ejecución de los planes del proyecto hasta la entrega
al adquiriente del sistema, producto o servicio software.
El proveedor gestiona el proceso de suministro a nivel de proyecto siguiendo el proceso de

gestión (7.1), que se emplea en este proceso; establece una infraestructura basada en el
siguiendo el proceso de adaptación (Anexo A); y gestiona el proceso a nivel de
PERUANA 23 de 189
organización siguiendo el proceso de mejora de proceso (7.3) y el proceso de recursos

humanos (7.4).
Lista de actividades: Este proceso consta de las siguientes actividades:
a) Inicio.
b) Preparación de la respuesta.
c) Contrato.
d) Planificación.
e) Ejecución y control.
f) Revisión y evaluación.
g) Entrega y finalización.
5.2.1 Inicio: Esta actividad consta de las siguientes tareas:
5.2.1.1 El proveedor lleva a cabo una revisión de los requerimientos de la solicitud

de propuestas, teniendo en cuenta las políticas de la organización y otras reglamentaciones.
5.2.1.2 El proveedor debería tomar la decisión de hacer o aceptar el contrato.
5.2.2 Preparación de la respuesta: Esta actividad consta de las siguientes tareas:
Conviene que el proveedor defina y prepare una oferta como respuesta a la solicitud de
propuestas, incluyendo su adaptación a las recomendaciones de esta NTP.
5.2.3 Contrato. Esta actividad consta de las siguientes tareas:

PERUANA 24 de 189
5.2.3.1 El proveedor deberá negociar y contratar con la organización adquiriente

para proporcionar el producto o servicio software.
5.2.3.2 El proveedor puede requerir modificaciones al contrato como parte del

mecanismo de control de cambios.
5.2.4 Planificación: Esta actividad consta de las siguientes tareas:
5.2.4.1 El proveedor deberá llevar a cabo una revisión de los requerimientos de la

adquisición para definir el marco para la gestión y aseguramiento del proyecto y para
asegurar la calidad del producto o servicio software entregable.
5.2.4.2 Si no está estipulado en el contrato, el proveedor deberá definir o

seleccionar un modelo de ciclo de vida para el software, apropiado al alcance, magnitud y
complejidad del proyecto. Se deberán seleccionar los procesos, actividades y tareas de esta
NTP y se deberá establecer una correspondencia entre ellas y el modelo de ciclo de vida
seleccionado.
5.2.4.3 El proveedor deberá establecer requerimientos para los planes de gestión y

aseguramiento del proyecto y para asegurar la calidad del producto o servicio software
entregable. Los requerimientos para los planes deberían incluir las necesidades de recursos
y el involucramiento del adquiriente.
5.2.4.4 Una vez que se hayan establecido los requerimientos para los planes, el
proveedor deberá considerar las opciones para desarrollar el producto software o
proporcionar el servicio software, considerando el análisis de los riesgos asociados con
cada opción. Las posibles opciones son:
a) Desarrollar el producto software o proporcionar el servicio software usando

recursos internos.
b) Desarrollar el producto software o proporcionar el servicio software sub-

contratándolo.
c) Obtener productos software preelaborados de fuentes internas o externas.

PERUANA 25 de 189
d) Una combinación de a, b y c.
5.2.4.5 El proveedor deberá desarrollar y documentar el plan o planes de gestión

del proyecto basándose en los requerimientos para los planes y en las opciones
seleccionadas en 5.2.4.4. Los aspectos a considerar en el plan incluyen, pero no están
limitadas a, lo siguiente:
a) Estructura organizativa del proyecto y autoridad y responsabilidad de cada

unidad organizativa, incluyendo las organizaciones externas.
b) Entorno de ingeniería (para desarrollo, operación, o mantenimiento, según

proceda), incluyendo el entorno de pruebas, biblioteca, equipos, instalaciones,
normas, procedimientos y herramientas.
c) Descomposición estructurada del trabajo de los procesos y actividades del

ciclo de vida, incluyendo los productos software, servicios software y elementos no
entregables que se deban desarrollar, junto con los presupuestos, personal, recursos
físicos, tamaño del software y plazos asociados a las tareas.
d) Gestión de las características de calidad de los productos o servicios

software. Se pueden elaborar planes separados para la calidad.
e) Gestión de la seguridad física y de acceso y otros requerimientos críticos de

los productos o servicios software. Se pueden elaborar planes por separado para la
seguridad, tanto física como de acceso.
f) Gestión de sub-contratistas, incluyendo su selección y la relación entre el

sub-contratista y el adquiriente, si existiera.
g) Aseguramiento de la calidad (véase 6.3).
h) Verificación (véase 6.4) y validación (véase 6.5), incluyendo el enfoque

para la interacción con el agente de verificación y validación, si está especificado.
i) Involucramiento del adquiriente; esto puede hacerse por medios tales como
revisiones conjuntas (véase 6.6), auditorías (véase 6.7), reuniones informales,
informes, modificaciones y cambios; implementación, aprobación, aceptación y
acceso a instalaciones.
j) Involucramiento del usuario; esto puede hacerse por medio de ejercicios de

establecimiento de requerimientos, demostración de prototipos y evaluaciones.
PERUANA 26 de 189
k) Gestión de riesgo; esto es, gestión de las áreas del proyecto que conllevan
riesgos potenciales relacionados con aspectos técnicos, costos y plazos.
l) Política de seguridad de acceso; esto es, reglas para lo que necesita saber y
la información que puede acceder cada nivel de la organización del proyecto.
m) Aprobación requerida por regulaciones, certificaciones requeridas y

derechos de marca, uso, propiedad y garantía y licencia.
n) Mecanismos para preparar los plazos, hacer el seguimiento y hacer los

informes.
o) Formación del personal (véase 7.4).
5.2.5 Ejecución y control: Esta actividad consta de las siguientes tareas:
5.2.5.1 El proveedor deberá implementar y ejecutar el plan o planes de gestión del

proyecto preparados en el apartado 5.2.4.
5.2.5.2 El proveedor deberá:
a) Desarrollar el producto software de acuerdo con el proceso de desarrollo

(5.3).
b) Operar el producto software de acuerdo con el proceso de operación (5.4).
c) Mantener el producto software de acuerdo con el proceso de mantenimiento

(5.5).
5.2.5.3 El proveedor deberá supervisar y controlar el progreso y la calidad de los

productos o servicios software del proyecto a lo largo del ciclo de vida contratado. Esta
deberá ser una tarea permanente e iterativa, que deberá permitir:
a) Hacer un seguimiento del progreso de las prestaciones técnicas, costos y

plazos, e informar del estado del proyecto.
b) Identificar, registrar, analizar y solucionar los problemas.

PERUANA 27 de 189
5.2.5.4 El proveedor deberá gestionar y controlar a los sub-contratistas de acuerdo

con el proceso de adquisición (5.1). El proveedor deberá transmitirles todos los
requerimientos contractuales necesarios para asegurar que el producto o servicio software
entregado al adquiriente, se desarrolla o lleva a cabo de acuerdo con los requerimientos del
contrato principal.
5.2.5.5 El proveedor deberá relacionarse con el agente de verificación y validación

independiente o de pruebas, tal como se especifique en el contrato y en los planes del
proyecto.
5.2.5.6 El proveedor deberá relacionarse con otras partes tal como se especifique en
el contrato y en los planes del proyecto.
5.2.6 Revisión y evaluación: Esta actividad consta de las siguientes tareas:
5.2.6.1 Conviene que el proveedor coordine las actividades de revisión del contrato,
de interfaces y de comunicación con la organización adquiriente.
5.2.6.2 El proveedor deberá llevar a cabo o dar soporte a las reuniones informales,
las revisiones de aceptación, las pruebas de aceptación, las revisiones conjuntas y las
auditorías con el adquiriente, tal como se especifique en el contrato y en los planes del
proyecto. Las revisiones conjuntas se deberán llevar a cabo de acuerdo con el apartado 6.6
y las auditorías de acuerdo con el apartado 6.7.
5.2.6.3 El proveedor deberá llevar a cabo la verificación y validación de acuerdo

con el apartado 6.4 y el apartado 6.5 respectivamente para demostrar que los productos o
servicios software y los procesos satisfacen completamente sus respectivos requerimientos.
5.2.6.4 El proveedor deberá poner a disposición del adquiriente los informes de

evaluación, revisiones, auditorías, pruebas y solución de problemas tal como se especifique
en el contrato.
5.2.6.5 El proveedor deberá proporcionar al adquiriente acceso a las instalaciones

del proveedor y de los sub-contratistas para la revisión de los productos o servicios
software, tal como se especifique en el contrato y en los planes del proyecto.
PERUANA 28 de 189
5.2.6.6 El proveedor deberá llevar a cabo actividades de aseguramiento de la

calidad de acuerdo con el apartado 6.3.
5.2.7 Entrega y finalización: Esta actividad consta de las siguientes tareas:
5.2.7.1 El proveedor deberá entregar el producto o servicio software tal como se

especifique en el contrato.
5.2.7.2 El proveedor deberá proporcionar asistencia al adquiriente para el soporte

del producto o servicio software entregado tal como se especifique en el contrato.
5.3 Proceso de desarrollo
El proceso de desarrollo contiene las actividades y tareas del desarrollador. El proceso

contiene las actividades para el análisis de los requerimientos, diseño, codificación,
integración, pruebas e instalación y aceptación relacionadas con los productos software.
Puede contener actividades a nivel de sistema si se estipula en el contrato. El desarrollador
lleva a cabo o soporta las actividades de este proceso de acuerdo con el contrato.
El desarrollador gestiona el proceso de desarrollo al nivel de proyecto siguiendo el proceso

de gestión (7.1), que se emplea en este proceso; establece una infraestructura basado en el
proceso que se sigue en el proceso de infraestructura (7.2) adapta el proceso al proyecto
humanos (7.4). Cuando el desarrollador es el proveedor del producto software
desarrollado, el desarrollador lleva a cabo el proceso de suministro (5.2).
Lista de actividades: Este proceso consta de las siguientes actividades:
a) Implementación del proceso.
b) Análisis de los requerimientos del sistema.
c) Diseño de la arquitectura del sistema.

PERUANA 29 de 189
d) Análisis de los requerimientos software.
e) Diseño de la arquitectura del software.
f) Diseño detallado del software.
g) Codificación y pruebas del software.
h) Integración del software.
i) Pruebas de calificación del software.
j) Integración del sistema.
k) Pruebas de calificación del sistema.
l) Instalación del software.
m) Apoyo a la aceptación del software.
5.3.1 Implementación del proceso: Esta actividad consta de las siguientes tareas:
5.3.1.1 Si no está estipulado en el contrato, el desarrollador deberá definir o

seleccionar un modelo de ciclo de vida apropiado al alcance, magnitud y complejidad del
proyecto. Se deberán seleccionar las actividades y tareas del proceso de desarrollo y
establecer una correspondencia entre dichas tareas y el modelo de ciclo de vida.
NOTA: Estas actividades y tareas pueden solaparse o interaccionar y pueden ser llevadas a cabo
iterativamente o recursivamente.
5.3.1.2 El desarrollador deberá:
a) Documentar las salidas de acuerdo con el proceso de documentación (6.1).
b) Poner las salidas basándose en el proceso de gestión de la configuración

(6.2) y llevar a cabo el control de los cambios de acuerdo con él.
c) Documentar y solucionar los problemas y no conformidades encontradas en

los productos software y tareas de acuerdo con el proceso de solución de problemas
(6.8).
PERUANA 30 de 189
d) Llevar a cabo los procesos de apoyo (capítulo 6) tal como se especifique en

el contrato.
e) Establecer una línea base para cada elemento de la configuración con los
elementos apropiados, como los determinados por el adquiriente y el proveedor.
5.3.1.3 El desarrollador deberá seleccionar, adaptar y usar aquellas normas,

métodos, herramientas y lenguajes de programación (si no están estipuilados en el
contrato) que estén documentados, sean pertinentes y estén establecidos por la
organización para llevar a cabo las actividades del proceso de desarrollo y de los procesos
de apoyo (capítulo 6).
5.3.1.4 El desarrollador deberá preparar planes para realizar las actividades del
proceso de desarrollo. Los planes deberían incluir normas específicas, métodos,
herramientas, acciones y responsabilidades asociadas con el desarrollo y calificación de
todos los requerimientos, incluyendo los de seguridad física y de acceso. Si fuese
necesario, se pueden preparar planes separados. Se deberán documentar y ejecutar estos
planes.
5.3.1.5 Para el desarrollo y mantenimiento del producto software se pueden emplear

elementos no entregables. Sin embargo, se deberá asegurar que la operación y
mantenimiento del producto software entregable, luego de entregado al adquiriente, es
independiente de dichos elementos, de otra manera se deberán considerar como
entregables.
5.3.2 Análisis de los requerimientos del sistema: Esta actividad consta de las
siguientes tareas, que el desarrollador deberá llevar a cabo o proporcionar apoyo, según
requiera el contrato:
5.3.2.1 Se deberá analizar el uso específico previsto del sistema a ser desarrollado
para especificar los requerimientos del sistema. La especificación de los requerimientos del
sistema deberá describir funciones y capacidades del sistema; requerimientos de negocio,
organizativos y de usuario; requerimientos de seguridad física y de acceso; requerimientos
de ingeniería de factores humanos (ergonomía), interfaces y requerimientos de operación y
mantenimiento; limitaciones de diseño y requerimientos de calificación. Se deberá
documentar la especificación de los requerimientos del sistema.
PERUANA 31 de 189
5.3.2.2 Se deberán evaluar los requerimientos del sistema teniendo en cuenta los
criterios enumerados a continuación. Se deberán documentar los resultados de las
evaluaciones.
a) Trazabilidad hacia las necesidades de la adquisición.
b) Consistencia con las necesidades de la adquisición.
c) Capacidad para ser probados.
d) Viabilidad del diseño de la arquitectura del sistema.
e) Viabilidad de la operación y mantenimiento.
5.3.3 Diseño de la arquitectura del sistema: Esta actividad consta de las

siguientes tareas, que el desarrollador deberá llevar a cabo o proporcionar apoyo, según
requiere el contrato.
5.3.3.1 Se deberá establecer la arquitectura del sistema a alto nivel. La arquitectura

deberá identificar los elementos hardware, software y operaciones manuales. Se deberá
asegurar que todos los requerimientos del sistema se distribuyen entre estos elementos. Se
deberán identificar posteriormente, los elementos de configuración hardware, elementos de
configuración software y las operaciones manuales partiendo de estos elementos. Se deberá
documentar la arquitectura del sistema y los requerimientos asignados a cada elemento.
5.3.3.2 Se deberá evaluar la arquitectura del sistema y los requerimientos para los
elementos teniendo en cuenta los criterios enumerados a continuación. Se deberán
documentar los resultados de las evaluaciones.
a) Trazabilidad hacia los requerimientos del sistema.
b) Consistencia con los requerimientos del sistema.
c) Adecuación de las normas y métodos de diseño usados.
d) Viabilidad de los elementos software para cumplir con sus requerimientos

asignados.
PERUANA 32 de 189
5.3.4 Análisis de los requerimientos software: Para cada elemento software (o

para cada elemento de configuración software, si se ha identificado) esta actividad consta
de las siguientes tareas:
5.3.4.1 El desarrollador deberá establecer y documentar los requerimientos software

descritos a continuación, incluyendo la especificación de las características de calidad. Se
pueden encontrar guías para la especificación de las características de calidad en la NTP-
ISO/IEC 9126.
a) Especificaciones funcionales y de capacidad, incluyendo prestaciones,

características físicas y condiciones del entorno en donde el elemento software ha de
funcionar.
b) Interfaces externas al elemento software.
c) Requerimientos de calificación.
d) Especificaciones de seguridad física, incluyendo aquellas relacionadas con

los métodos de operación y mantenimiento, influencias del entorno y daño a las
personas.
e) Especificaciones de seguridad de acceso, incluyendo aquellas que

comprometen información confidencial.
f) Especificaciones relacionadas con ingeniería de factores humanos

(ergonomía), incluyendo aquellas relacionadas con las operaciones manuales,
interacción hombre-máquina, obligaciones del personal y áreas con necesidad de una
especial atención por parte de las personas, debido a su sensibilidad a errores
humanos y a la destreza.
g) Definición de datos y requerimientos de las bases de datos.
h) Requerimientos de instalación y aceptación del producto software

entregado, en el lugar o lugares de operación y mantenimiento.
i) Documentación de usuario.
j) Requerimientos de operación y ejecución por parte del usuario.

PERUANA 33 de 189
k) Requerimientos de mantenimiento por parte del usuario.
5.3.4.2 El desarrollador deberá evaluar los requerimientos software teniendo en

cuenta los criterios enumerados a continuación. Se deberán documentar los resultados de la
evaluación.
a) Trazabilidad hacia los requerimientos del sistema y el diseño del sistema.
b) Consistencia externa con los requerimientos del sistema.
c) Consistencia interna.
d) Capacidad para ser probado.
e) Viabilidad del diseño software.
f) Viabilidad de la operación y mantenimiento.
5.3.4.3 El desarrollador deberá llevar a cabo revisiones conjuntas de acuerdo con el

apartado 6.6.
5.3.5 Diseño de la arquitectura del software: Para cada elemento software (o

para cada elemento de configuración software, si se ha identificado), esta actividad consta
de las siguientes tareas:
5.3.5.1 El desarrollador deberá transformar los requerimientos para el elemento

software, en una arquitectura que describa su estructura a alto nivel e identifique los
componentes software. Se deberá asegurar que todos los requerimientos para el elemento
software se asignan a sus componentes software y se refinan posteriormente para facilitar
el diseño detallado. Se deberá documentar la arquitectura del elemento software.
5.3.5.2 El desarrollador deberá desarrollar y documentar un diseño a alto nivel para

las interfaces externas al elemento software y para las interfaces entre los componentes
software del elemento software.
PERUANA 34 de 189
5.3.5.3 El desarrollador deberá desarrollar y documentar un diseño a alto nivel para

la base de datos.
5.3.5.4 Conviene que el desarrollador desarrolle y documente versiones

preliminares de la documentación de usuario.
5.3.5.5 El desarrollador deberá definir y documentar los requerimientos

preliminares de pruebas y la planificación para la integración del software.
5.3.5.6 El desarrollador deberá evaluar la arquitectura del elemento software y de

los diseños de su interfaz y base de datos teniendo en cuenta los criterios enumerados a
continuación. Se deberán documentar los resultados de las evaluaciones.
a) Trazabilidad hacia los requerimientos del elemento software.
b) Consistencia externa con los requerimientos del elemento software.
c) Consistencia interna entre los componentes software.
d) Adecuación de los métodos de diseño y normas usadas.
e) Viabilidad del diseño detallado.

apartado 6.6.
5.3.6 Diseño detallado del software: Para cada elemento software (o para cada
elemento de configuración software, si se ha identificado), esta actividad consta de las
siguientes tareas:
5.3.6.1 El desarrollador deberá preparar un diseño detallado para cada componente

software del elemento software. Se deberá refinar los componentes software hasta los
niveles más bajos, que contienen las unidades software que pueden ser codificadas,
compiladas y probadas. Se deberá asegurar que todos los requerimientos software están
PERUANA 35 de 189
asignados desde los componentes software hacia las unidades software. Se deberá
documentar el diseño detallado.
5.3.6.2 El desarrollador deberá preparar y documentar un diseño detallado de las

interfaces externas al elemento software y entre los componentes software y las unidades
software. El diseño detallado de las interfaces deberá permitir la codificación sin necesidad
de más información.
5.3.6.3 El desarrollador deberá preparar y documentar el diseño detallado para la

base de datos.
5.3.6.4 El desarrollador deberá actualizar la documentación de usuario si es

necesario.
5.3.6.5 El desarrollador deberá definir y documentar los requerimientos de prueba y

planificar la prueba de las unidades. Se deberían incluir en los requerimientos de prueba
situaciones que fuercen a las unidades software hasta los límites de los requerimientos del
software.
5.3.6.6 El desarrollador deberá actualizar los requerimientos de prueba y el plan

para la integración del software.
5.3.6.7 El desarrollador deberá evaluar el diseño detallado del software y los

requerimientos de prueba teniendo en cuenta los criterios enumerados a continuación. Se
deberán documentar los resultados de la evaluación.
a) Trazabilidad hacia los requerimientos del elemento software.
b) Consistencia externa con el diseño de la arquitectura.
c) Consistencia interna entre los componentes software y las unidades

software.
d) Adecuación de los métodos de diseño y normas usadas.
e) Viabilidad de las pruebas.

PERUANA 36 de 189

apartado 6.6.
5.3.7 Codificación y pruebas del software: Para cada elemento software (o para
cada elemento de configuración software, si se ha identificado), esta actividad consta de las
siguientes tareas:
5.3.7.1 El desarrollador deberá desarrollar y documentar lo siguiente:
a) Cada unidad software y base de datos.
b) Procedimientos de prueba y datos para probar cada unidad software y base

de datos.
5.3.7.2 El desarrollador deberá probar cada unidad software y base de datos

asegurando que satisfacen sus requerimientos. Se deberán documentar los resultados de las
pruebas.
5.3.7.3 El desarrollador deberá actualizar la documentación de usuario, si es

necesario.
5.3.7.4 El desarrollador deberá actualizar los requerimientos de prueba y el plan

para la integración del software.
5.3.7.5 El desarrollador deberá evaluar el código software y los resultados de las

pruebas teniendo en cuenta los criterios enumerados a continuación. Se deberán
documentar los resultados de las evaluaciones.
a) Trazabilidad hacia los requerimientos y el diseño del elemento software.
b) Consistencia externa con los requerimientos y el diseño del elemento

software.
PERUANA 37 de 189
c) Consistencia interna entre los requerimientos de las unidades.
d) Cobertura de pruebas de las unidades.
e) Adecuación de los métodos de codificación y normas usadas.
f) Viabilidad de la integración del software y de las pruebas.
g) Viabilidad de la operación y mantenimiento.
5.3.8 Integración del software: Para cada elemento software (o para cada
elemento de configuración de software, si se ha identificado), esta actividad consta de las
siguientes tareas:
5.3.8.1 El desarrollador deberá preparar un plan de integración para integrar las

unidades software y los componentes software en el elemento software. El plan deberá
incluir requerimientos de prueba, procedimientos, datos, responsabilidades y plazos. Se
deberá documentar el plan.
5.3.8.2 El desarrollador deberá integrar las unidades software y los componentes

software y probarlos a medida que se agrupan de acuerdo con el plan de integración. Se
deberá asegurar que cada agrupación satisface los requerimientos del elemento software y
que el elemento software está integrado al final de la actividad de integración. Se deberá
documentar los resultados de la integración y de las pruebas.

necesario.
5.3.8.4 El desarrollador deberá preparar y documentar, para cada requerimiento de

calificación del elemento software, un conjunto de pruebas, casos de prueba (entradas,
salidas, criterios de prueba) y procedimientos de prueba para llevar a cabo las pruebas de
calificación del software. El desarrollador deberá asegurar que el elemento software
integrado está listo para las pruebas de calificación del software.
5.3.8.5 El desarrollador deberá evaluar el plan de integración, el diseño, el código,

las pruebas, los resultados de las pruebas y la documentación de usuario teniendo en cuenta
PERUANA 38 de 189
los criterios enumerados a continuación. Se deberán documentar los resultados de las

evaluaciones.
a) Trazabilidad hacia los requerimientos del sistema.
b) Consistencia externa con los requerimientos del sistema.
c) Consistencia interna.
d) Cobertura de las pruebas de los requerimientos del elemento software.
e) Adecuación de las normas de prueba y de los métodos usados.
f) Conformidad con los resultados esperados.
g) Viabilidad de las pruebas de calificación del software.
h) Viabilidad de la operación y mantenimiento.
5.3.8.6 El desarrollador debería llevar a cabo revisiones conjuntas de acuerdo con

el apartado 6.6.
5.3.9 Pruebas de calificación del software: Para cada elemento software (o para
cada elemento de configuración software, si se ha identificado), esta actividad consta de las
siguientes tareas:
5.3.9.1 El desarrollador deberá llevar a cabo pruebas de calificación de acuerdo con

los requerimientos de calificación para el elemento software. Se deberá asegurar que se
prueba la conformidad de la implementación de cada requerimiento software. Se deberán
documentar los resultados de las pruebas de calificación.

necesario.
5.3.9.3 El desarrollador deberá evaluar el diseño, el código, las pruebas, los

resultados de las pruebas y la documentación de usuario teniendo en cuenta los criterios
enumerados a continuación. Se deberán documentar los resultados de las evaluaciones.
PERUANA 39 de 189
a) Cobertura de las pruebas de los requerimientos del elemento software.
b) Conformidad con los resultados esperados.
c) Viabilidad de la integración del sistema y las pruebas, si se llevan a cabo.
d) Viabilidad de la operación y mantenimiento.
5.3.9.4 El desarrollador deberá proporcionar soporte a las auditorías de acuerdo con

el apartado 6.7. Se deberán documentar los resultados de las auditorías. Si el hardware y el
software están bajo desarrollo o integración, las auditorías pueden posponerse hasta las
pruebas de calificación del sistema.
5.3.9.5 Tras la finalización exitosa de las auditorías, si se llevan a cabo, el

desarrollador deberá:
a) Actualizar y preparar el producto software entregable para la integración del

sistema, pruebas de calificación del sistema, instalación del software o apoyo a la
aceptación del software, como proceda.
NOTA: Las pruebas de calificación del software se pueden usar en el proceso de verificación (6.4)
o en el proceso de validación (6.5).
5.3.10 Integración del sistema: Esta actividad consta de las siguientes tareas, que
el desarrollador deberá llevar a cabo o proporcionar apoyo, tal como requiere el contrato.
5.3.10.1 Los elementos de configuración software se deberán integrar con los

elementos de configuración hardware, operaciones manuales y otros sistemas si es
necesario, para formar el sistema. Se deberán probar las integraciones frente a sus
requerimientos, al mismo tiempo que se desarrollen. Se deberán documentar los resultados
de la integración y pruebas.
5.3.10.2 Se deberá desarrollar y documentar para cada requerimiento de calificación

del sistema, un conjunto de pruebas, casos de prueba (entradas, salidas, criterios de prueba)
y procedimientos de prueba para llevar a cabo las pruebas de calificación del sistema. El
desarrollador deberá asegurar que el sistema integrado está listo para las pruebas de
calificación del sistema.
PERUANA 40 de 189
5.3.10.3 El sistema integrado se deberá evaluar teniendo en cuenta los criterios

enumerados a continuación. Se deberán documentar los resultados de las evaluaciones.
a) Cobertura de las pruebas de los requerimientos del sistema.
b) Adecuación de los métodos de prueba y normas usadas.
c) Conformidad con los resultados esperados.
d) Viabilidad de la prueba de calificación del sistema.
5.3.11 Pruebas de calificación del sistema. Esta actividad consta de las siguientes
tareas que el desarrollador deberá llevar a cabo o proporcionar apoyo, tal como requiere el
contrato.
5.3.11.1 Las pruebas de calificación del sistema se deberá llevar a cabo de acuerdo
con los requerimientos de calificación especificados para el sistema. Se deberá asegurar
que se prueba la conformidad de la implementación de cada requerimiento del sistema y
que el sistema está listo para su entrega. Se deberán documentar los resultados de las
pruebas de calificación.
5.3.11.2 Se deberá evaluar el sistema teniendo en cuenta los criterios enumerados a

continuación. Se deberán documentar los resultados de las evaluaciones.
a) Cobertura de las pruebas de los requerimientos del sistema.
b) Conformidad con los resultados esperados.
c) Viabilidad de la operación y mantenimiento.
5.3.11.3 El desarrollador deberá proporcionar apoyo a las auditorías de acuerdo con

el apartado 6.7. Se deberán documentar los resultados de las auditorías.
NOTA: Este apartado no es aplicable a aquellos elementos de configuración que hubieran sido
auditados previamente.
PERUANA 41 de 189
5.3.11.4 Tras la terminación con éxito de las auditorías, si se han llevado a cabo, el
desarrollador deberá:
a) Actualizar y preparar el producto software entregable para la instalación del

software y el soporte a la aceptación del software.
NOTA: Se pueden usar las pruebas de calificación del sistema en el proceso de verificación(6.4) o
en el proceso de validación (6.5).
5.3.12 Instalación del software: Esta actividad consta de las siguientes tareas:
5.3.12.1 El desarrollador deberá preparar un plan para instalar el producto software

en el entorno de destino, tal como se especifica en el contrato. Se deberán determinar y
estar disponibles los recursos y la información necesaria para instalar el producto software.
El desarrollador deberá ayudar al adquiriente con las actividades de puesta en marcha tal
como se especifique en el contrato. En los casos en que el software instalado reemplace a
un sistema existente, el desarrollador deberá proporcionar apoyo a cualquier actividad
realizada en paralelo que sea requerida por el contrato. Se deberá documentar el plan de
instalación.
5.3.12.2 El desarrollador deberá instalar el producto software de acuerdo con el plan

de instalación. Se deberá asegurar que el código software y las bases de datos se
inicializan, ejecutan y terminan tal como se especifica en el contrato. Se deberán
documentar las incidencias y resultados de la instalación.
5.3.13 Apoyo a la aceptación del software: Esta actividad consta de las siguientes
tareas:
5.3.13.1 El desarrollador deberá proporcionar apoyo a las revisiones y pruebas de

aceptación llevadas a cabo por el adquiriente del producto software. Las revisiones y
pruebas de aceptación deberán tener en cuenta los resultados de las revisiones conjuntas
(6.6), auditorías (6.7), pruebas de calificación del software y pruebas de calificación del
sistema (si se llevan a cabo). Se deberán documentar los resultados de las pruebas y
revisiones de aceptación.
PERUANA 42 de 189
5.3.13.2 El desarrollador deberá completar y entregar el producto software tal como

se especifica en el contrato.
5.3.13.3 El desarrollador deberá proporcionar formación inicial y continua y dar

apoyo al adquiriente tal como se especifica en el contrato.
5.4 Proceso de operación
El proceso de operación contiene las actividades y tareas del operador. El proceso cubre la
operación del producto software y el apoyo a la operación de los usuarios. Ya que la
operación del producto software está integrada a la operación del sistema, las actividades y
tareas de este proceso hacen referencia al sistema.
El operador gestiona el proceso de operación a nivel de proyecto usando el proceso de

gestión(7.1), que se emplea en este proceso; establece una infraestructura basada en el
siguiendo el proceso de adaptación (Anexo A); y gestiona el proceso al nivel de
humanos (7.4). Cuando el operador es el proveedor del servicio de operación, el operador
lleva a cabo proceso de suministro (5.2).
Lista de actividades. Este proceso consta de las siguientes actividades:
b) Pruebas de operación.
c) Operación del sistema.
d) Soporte al usuario.
PERUANA 43 de 189
5.4.1.1 El operador debería preparar un plan y establecer un conjunto de normas de

operación para llevar a cabo las actividades y tareas de este proceso. Se deberá documentar
y ejecutar el plan.
5.4.1.2 El operador deberá establecer procedimientos para recibir, registrar,

solucionar y hacer un seguimiento de los problemas y proporcionar información sobre su
situación. En cuanto se encuentren problemas, se deberán registrar e introducir en el
proceso de solución de problemas (6.8).
5.4.1.3 El operador deberá establecer procedimientos para probar el producto

software en su entorno de operación, para alimentar con informes de problemas y
peticiones de modificaciones al proceso de mantenimiento (5.5) y para liberar el producto
software para el uso en operación.
5.4.2 Pruebas de operación: Esta actividad consta de las siguientes tareas:
5.4.2.1 Para cada release del producto software, el operador deberá llevar a cabo
pruebas de operación y tras satisfacerse los criterios especificados, liberar el software para
uso en operación.
5.4.2.2 El operador deberá asegurar que el código software y las bases de datos se
inicializan, ejecutan y terminan tal como se describe en el plan.
5.4.3 Operación del sistema: Esta actividad consta de la siguiente tarea:
5.4.3.1 El sistema deberá ser operado en el entorno previsto de acuerdo con la

documentación de usuario.
5.4.4 Soporte al usuario: Esta actividad consta de las siguientes tareas:
5.4.4.1 El operador deberá proporcionar asistencia y consultoría a los usuarios

cuando la pidan. Estas peticiones y las acciones subsecuentes se deberán registrar y
supervisar.
PERUANA 44 de 189
5.4.4.2 El operador deberá pasar las peticiones del usuario, cuando sea necesario, al
proceso de mantenimiento (apartado 5.5) para su solución. Estas peticiones se deberán
tramitar y el originador de la petición deberá ser informado de las acciones que se
planifiquen y se tomen. Se deberá hacer un seguimiento de todas las decisiones hasta su
conclusión.
5.4.4.3 Si un problema reportado tiene una solución temporal, antes de que se

pueda liberar una solución permanente, se deberá dar la opción a quien reportó el
problema para que la use. Se deberán aplicar al software en operación, usando el proceso
de mantenimiento (5.5), las correcciones permanentes, los releases que incluyan funciones
o características omitidas anteriormente y las mejoras del sistema.
5.5 Proceso de mantenimiento
El proceso de mantenimiento contiene las actividades y tareas del responsable de

mantenimiento. Este proceso se inicia cuando el producto software sufre modificaciones en
el código y la documentación asociada, debido a un problema o a la necesidad de mejora o
adaptación. El objetivo es modificar el producto software existente preservando su
integridad. Este proceso incluye la migración y retirada del producto software. El proceso
termina con la retirada del producto software.
Las actividades proporcionadas por esta área son específicas del proceso de
mantenimiento; sin embargo, el proceso puede utilizar otros procesos de esta NTP. Si se
usa el proceso de desarrollo (5.3), el término desarrollador se deberá interpretar en él como
el responsable de mantenimiento.
El responsable de mantenimiento gestiona el proceso de mantenimiento a nivel de proyecto

siguiendo el proceso de gestión (7.1), que se emplea en este proceso; establece una
infraestructura basada en el proceso que se sigue en el proceso de infraestructura (7.2):
adapta el proceso para el proyecto siguiendo el proceso de adaptación (Anexo A); y
gestiona el proceso a nivel de organización siguiendo el proceso de mejora de proceso
(7.3) y el proceso de recursos humanos (7.4). Cuando el responsable de mantenimiento es
el proveedor del servicio de mantenimiento, el responsable de mantenimiento lleva a cabo
el proceso de suministro (5.2).

PERUANA 45 de 189
b) Análisis de problemas y modificaciones.
c) Implementación de las modificaciones.
d) Revisión/aceptación del mantenimiento.
e) Migración.
f) Retirada del software.
5.5.1 lmplementación del proceso: Esta actividad consta de las siguientes tareas:
5.5.1.1 El responsable de mantenimiento deberá preparar, documentar y ejecutar

planes y procedimientos para llevar a cabo las actividades y tareas del proceso de
mantenimiento.
5.5.1.2 El responsable de mantenimiento deberá establecer procedimientos para

recibir, registrar y hacer seguimiento a los informes de problemas y a las peticiones de
modificaciones de los usuarios y proporcionar información a los usuarios sobre su
situación. En el momento en que se encuentren problemas, se deberán registrar e introducir
en el proceso de solución de problemas (6.8).
5.5.1.3 El responsable de mantenimiento deberá implementar el proceso de gestión

de la configuración (6.2) (o establecer una interfaz con él a nivel organizacional) para
gestionar las modificaciones al sistema existente.
5.5.2 Análisis de problemas y modificaciones: Esta actividad consta de las

siguientes tareas:
5.5.2.1 El responsable de mantenimiento deberá analizar el informe del problema o

la petición de modificación de acuerdo con su impacto en la organización, el sistema
existente y los sistemas con los que interacciona según lo siguiente:
PERUANA 46 de 189
a) Tipo; por ejemplo correctivo, mejora, preventivo o adaptativo a un nuevo

entorno.
b) Alcance; por ejemplo tamaño de la modificación, costo, tiempo para

completar la modificación.
c) Aspectos críticos; por ejemplo, impacto en las características o seguridad

física o de acceso.
5.5.2.2 El responsable de mantenimiento deberá reproducir o comprobar el

problema.
5.5.2.3 Basándose en el análisis, el responsable de mantenimiento deberá preparar

alternativas para implementar la modificación.
5.5.2.4 El responsable de mantenimiento deberá documentar el problema/petición

de modificación, los resultados del análisis y las alternativas de implementación.
5.5.2.5 El responsable de mantenimiento deberá obtener la aprobación para la

implementación de la alternativa seleccionada tal como se especifica en el contrato.
5.5.3 Implementación de las modificaciones: Esta actividad consta de las

siguientes tareas.
5.5.3.1 El responsable de mantenimiento deberá llevar a cabo el análisis y

determinar qué documentación, unidades software y versiones requieren ser modificadas
por esta causa. Se deberá documentar este análisis.
5.5.3.2 El responsable de mantenimiento deberá ejecutar el proceso de desarrollo

(5.3) para implementar las modificaciones. Los requerimientos del proceso de desarrollo
se deben complementar con lo siguiente:
a) Se deberán definir y documentar criterios de prueba y evaluación para

probar y evaluar las partes modificadas y no modificadas del sistema (unidades
software, componentes y elementos de configuración).
PERUANA 47 de 189
b) Se deberá asegurar la implementación completa y correcta de los

requerimientos nuevos y modificados. También se deberá asegurar que los
requerimientos originales no modificados no han sido afectados. Se deberán
documentar los resultados de las pruebas.
5.5.4 Revisión/aceptación del mantenimiento: Esta actividad consta de las

siguientes tareas:
5.5.4.1 El responsable de mantenimiento deberá llevar a cabo revisiones, con la

organización que autoriza las modificaciones, para determinar la integridad del sistema
modificado.
5.5.4.2 El responsable de mantenimiento deberá obtener aprobación para la

finalización satisfactoria de la modificación, tal como se especifica en el contrato.
5.5.5 Migración: Esta actividad consta de las siguientes tareas:
5.5.5.1 Si se migra el sistema o producto software (incluyendo los datos) de un

entorno de operación viejo a uno nuevo, se deberá asegurar que cualquier producto
software o datos producidos o modificados durante la migración estén de acuerdo con esta
NTP.
5.5.5.2 Se deberá preparar, documentar y ejecutar un plan de migración. Las

actividades de planificación deberán incluir a los usuarios. El plan deberá incluir los
siguientes elementos:
a) Análisis de los requerimientos y definición de la migración.
b) Desarrollo de las herramientas de la migración.
c) Conversión del producto software y de los datos.
d) Ejecución de la migración.
e) Verificación de la migración.
PERUANA 48 de 189
f) Soporte para el antiguo entorno en el futuro.
5.5.5.3 Se deberá notificar a los usuarios las actividades y planes de la migración.

Las notificaciones deberán incluir lo siguiente:
a) Declaración de por qué el antiguo entorno no va a seguir siendo soportado.
b) Descripción del nuevo entorno con su fecha de disponibilidad.
c) Descripción de otras opciones de soporte, si existen, una vez que ha cesado

el soporte al antiguo entorno.
5.5.5.4 Para hacer más fluida la transición al nuevo entorno, se puede llevar a cabo
la operación en paralelo del antiguo y del nuevo entorno. Durante este periodo se deberá
proporcionar la formación necesaria tal como se especifica en el contrato.
5.5.5.5 Cuando llegue el momento previsto de la migración, se deberá notificar a

todos los afectados. Se deberá archivar toda la documentación, registros y código del
antiguo entorno.
5.5.5.6 Se deberá llevar a cabo una revisión post-operación para evaluar el impacto
del cambio al nuevo entorno. Los resultados de la revisión se deberán enviar a las
autoridades apropiadas para su conocimiento, guía y actuación.
5.5.5.7 Los datos usados por o asociados al antiguo entorno deberán ser accesibles
de acuerdo con los requerimientos del contrato sobre protección de datos y auditorías
aplicables.
5.5.6 Retirada del software: Esta actividad consta de las siguientes tareas:
NOTA: El producto software se retirará por petición del propietario.
5.5.6.1 Se deberá preparar y documentar un plan de retirada para el cese del soporte
activo por parte de las organizaciones de operación y mantenimiento. Las actividades de
PERUANA 49 de 189
planificación deberán incluir a los usuarios. El plan deberá considerar los elementos
enumerados a continuación. El plan deberá ser ejecutado.
a) Cese total o parcial del soporte tras un cierto periodo de tiempo.
b) Archivo del producto software y de su documentación asociada.
c) Responsabilidad para cualquier aspecto de soporte residual en el futuro.
d) Transición hacia el nuevo producto software, si es aplicable.
e) Accesibilidad de las copias archivadas de los datos.
5.5.6.2 Se deberá notificar a los usuarios los planes y actividades de la retirada.
Las notificaciones deberán incluir lo siguiente:
a) Descripción del sustitutivo o mejora, con su fecha de disponibilidad.
b) Descripción del por qué el producto software no va a seguir siendo

soportado.
c) Descripción de otras opciones de soporte disponibles, una vez que el soporte

ha cesado.
5.5.6.3 Para facilitar la transición al nuevo sistema, conviene que se lleve a cabo la
operación en paralelo del sistema a retirar y del nuevo producto software. Durante este
período, se deberá proporcionar formación a los usuarios, tal como se especifica en el
contrato.
5.5.6.4 Cuando llegue la fecha prevista de retirada, se deberá notificar a todos los
afectados. Toda la documentación de desarrollo asociada, registros y código se deberá
archivar en el momento oportuno.
5.5.6.5 Los datos usados o asociados al producto software retirado deberán ser
accesibles de acuerdo con los requerimientos del contrato sobre protección de datos y
auditorías aplicables.
PERUANA 50 de 189
6. PROCESOS DE APOYO DEL CICLO DE VIDA
Este capítulo define los siguientes procesos de apoyo del ciclo de vida:
a) Proceso de documentación.
b) Proceso de gestión de la configuración.
c) Proceso de aseguramiento de la calidad.
d) Proceso de verificación.
e) Proceso de validación.
f) Proceso de revisión conjunta.
g) Proceso de auditoría.
h) Proceso de solución de problemas.
Las actividades y tareas en un proceso de apoyo son responsabilidad de la organización

que lleva a cabo dicho proceso. Esta organización se asegura que el proceso existe y está
operativo.
La organización que emplea y lleva a cabo un proceso de apoyo lo gestiona a nivel de

proyecto siguiendo el proceso de gestión (7.1); establece una infraestructura basada en el
humanos (7.4). Se pueden emplear revisiones conjuntas, auditorías, verificación y
validación como técnicas de aseguramiento de la calidad.
6.1 Proceso de documentación
El proceso de documentación es un proceso para registrar la documentación producida por

un proceso o actividad del ciclo de vida. El proceso contiene el conjunto de actividades
para planificar, diseñar, desarrollar, producir, editar, distribuir y mantener aquellos
PERUANA 51 de 189
documentos que necesitan todos los involucrados tales como gerentes, ingenieros y
usuarios del sistema o producto software.
b) Diseño y desarrollo.
c) Producción.
d) Mantenimiento.
6.1.1 Implementación del proceso: Esta actividad consta de la siguiente tarea:
Se deberá preparar, documentar e implementar un plan que identifique los documentos que
se van a producir durante el ciclo de vida del producto software. Para cada documento
identificado, se deberá considerar lo siguiente:
a) Título o nombre.
b) Propósito.
c) Audiencia a la que se dirige.
d) Procedimientos y responsabilidades para las entradas, desarrollo, revisión,

modificación, aprobación, producción, almacenamiento, distribución, mantenimiento
y gestión de la configuración.
e) Plazos para las versiones intermedias y final.
6.1.2 Diseño y desarrollo: Esta actividad consta de las siguientes tareas:
6.1.2.1 Cada documento identificado se deberá diseñar de acuerdo con las normas
de documentación aplicables para el formato, descripción del contenido, numeración de
PERUANA 52 de 189
páginas, situación de las figuras y tablas, marcas de propiedad y seguridad, empaquetado y

otros elementos de presentación.
6.1.2.2 Se deberá confirmar la fuente y adecuación de los datos de entrada para los
documentos. Se pueden usar herramientas automáticas de documentación.
6.1.2.3 Se deberán revisar y corregir los documentos preparados de acuerdo con el

formato, contenido técnico y estilo de presentación frente a sus normas de documentación.
Personal autorizado deberá aprobar su adecuación antes de que sean hechos públicos.
6.1.3 Producción: Esta actividad consta de las siguientes tareas:
6.1.3.1 Los documentos se deberán producir y poner a disponibilidad de acuerdo

con el plan. La producción y distribución de los documentos puede hacerse usando papel,
medios electrónicos u otros medios. Se deberán almacenar los originales de acuerdo con
los requerimientos de conservación de registros, seguridad de acceso, mantenimiento y
copias de seguridad.
6.1.3.2 Se deberán establecer controles de acuerdo con el proceso de gestión de la

configuración (véase 6.2).
6.1.4 Mantenimiento. Esta actividad consta de la siguiente tarea:
6.1.4.1 Se deberán llevar a cabo las tareas que se requieran cuando se realice la
modificación de la documentación (véase apartado 5.5). Para aquellos documentos que
están bajo la gestión de la configuración, las modificaciones se deberán administrar de
acuerdo con el proceso de gestión de la configuración (6.2).
6.2 Proceso de gestión de la configuración
El proceso de gestión de la configuración es el proceso de aplicar procedimientos técnicos

y administrativos a lo largo del ciclo de vida del software para: identificar, definir y
establecer la línea base de los elementos software en un sistema; controlar modificaciones
y releases de los elementos; registrar e informar del estado de los elementos y peticiones de
PERUANA 53 de 189
modificación; asegurar la completitud, consistencia y corrección de los elementos; y

controlar el almacenamiento, manipulación y entrega de los elementos.
NOTA: Cuando este proceso se emplea sobre otros productos o entidades de software, el término
"elemento software" se deberá interpretar de acuerdo con ello.
b) Identificación de la configuración.
c) Control de la configuración.
d) Determinación del estado de la configuración.
e) Evaluación de la configuración.
f) Gestión de releases y entrega.
6.2.1 lmplementación del proceso: Esta actividad consta de la siguiente tarea:
6.2.1.1 Se deberá preparar un plan de gestión de la configuración. El plan deberá

describir: las actividades de gestión de la configuración; procedimientos y plazos para
llevar a cabo dichas actividades; la organización u organizaciones responsables de llevar a
cabo dichas actividades; sus relaciones con otras organizaciones, tales como las de
desarrollo o mantenimiento del software. Se deberá documentar e implementar el plan.
NOTA: El plan puede ser parte del plan de gestión de la configuración del sistema.
6.2.2 Identificación de la configuración: Esta actividad consta de la siguiente

tarea:
6.2.2.1 Se deberá establecer un esquema para la identificación de los elementos

software (y sus versiones) que van a ser controlados por el proyecto. Se deberá identificar
PERUANA 54 de 189
para cada elemento software y sus versiones: la documentación que establece la línea de
referencia, las referencias a las versiones y otros detalles de identificación.
6.2.3 Control de la configuración: Esta actividad consta de la siguiente tarea:
6.2.3.1 Se deberá llevar a cabo lo siguiente: identificación y registro de las

peticiones de cambio, análisis y evaluación de los cambios, aprobación o rechazo de la
petición, e implementación, verificación y release del elemento software modificado.
Deberá existir un rastro auditable mediante el cual se pueda rastrear cada modificación, las
razones para la modificación y la autorización de la modificación. Se deberá controlar y
auditar todos los accesos a los elementos software controlados que manejen funciones
críticas para la seguridad tanto física como de acceso.
6.2.4 Determinación del estado de la configuración: Esta actividad consta de la

siguiente tarea:
6.2.4.1 Se deberán preparar registros de la gestión e informes del estado que

muestren el estado y la historia de los elementos, software controlados, incluyendo las
líneas de referencia. Los informes del estado deberían incluir el número de cambios en un
proyecto, las últimas versiones de los elementos software, identificadores de los releases,
número de releases y comparación de releases.
6.2.5 Evaluación de la configuración: Esta actividad consta de la siguiente

tarea:
6.2.5.1 Se deberá determinar y asegurar lo siguiente: completitud funcional de los

elementos software frente a sus requerimientos y completitud física de los elementos
software (si su diseño y código reflejan una descripción técnica actualizada).
6.2.6 Gestión de releases y entrega: Esta actividad consta de la siguiente tarea:
6.2.6.1 El release y entrega de los productos software y de la documentación se

deberá controlar formalmente. Se deberán guardar copias maestras del código y la
documentación durante toda la vida del producto software. El código y la documentación
que contengan funciones críticas de seguridad física o de acceso se deberá manipular,
PERUANA 55 de 189
almacenar, empaquetar y entregar de acuerdo con las políticas de las organizaciones

involucradas.
6.3 Proceso de aseguramiento de la calidad
El proceso de aseguramiento de la calidad es un proceso para proporcionar la seguridad

apropiada de que los productos y procesos software del ciclo de vida del proyecto son
conformes con sus requerimientos especificados y se adhieren a los planes establecidos.
Para ser imparcial, el aseguramiento de la calidad necesita libertad organizativa y autoridad
respecto a las personas directamente responsables el desarrollo del producto software, o
que ejecutan el proceso del proyecto. El aseguramiento de la calidad puede ser interno o
externo, dependiendo de si la evidencia de la calidad del producto o proceso se le
demuestra a los gerentes del proveedor o del adquiriente. El aseguramiento de la calidad
puede hacer uso del resutlado de otros procesos de apoyo, tales como verificación (6.4),
validación(6.5), revisión conjunta(6.6), auditoría (6.7) y solución de problemas (6.8).
a) lmplementación del proceso.
b) Aseguramiento del producto.
c) Aseguramiento del proceso.
d) Aseguramiento del sistema de calidad.
6.3.1.1 Los objetivos del proceso de aseguramiento de la calidad deberán asegurar

que los productos software y los procesos empleados para proporcionar dichos productos
software cumplen con sus requerimientos establecidos y se adhieren a sus planes
establecidos.
6.3.1.2 Conviene que el proceso de aseguramiento de la calidad se coordine con los

procesos relacionados de verificación (6.4), validación (6.5), revisión conjunta (6.6) y
auditoría (6.7).
PERUANA 56 de 189
6.3.1.3 Se deberá preparar, documentar, implementar y mantener durante la vida del

contrato un plan para llevar a cabo las actividades y tareas del proceso de aseguramiento de
la calidad. El plan deberá incluir lo siguiente:
a) Normas de calidad, metodología, procedimientos y herramientas para llevar

a cabo las actividades de aseguramiento de la calidad (o las referencias a
documentación oficial de la organización).
b) Procedimientos para la revisión del contrato y posterior coordinación.
c) Procedimientos para la identificación, recopilación, rellenado,

mantenimiento y eliminación de los registros de calidad.
d) Recursos, plazos y responsabilidades para llevar a cabo las actividades de

aseguramiento de la calidad.
e) Tareas y actividades seleccionadas de los procesos de soporte tales como

verificación (6.4), validación (6.5), revisión conjunta (6.6), auditoría (6.7) y solución
de problemas (6.8).
6.3.1.4 Se deberán ejecutar las actividades y tareas de aseguramiento de la calidad

en curso y planificadas. Cuando se detecten problemas o no conformidades con los
requerimientos del contrato, se deberán documentar y éstos servirán como entrada al
proceso de solución de problemas (6.8). Se deberán preparar y mantener registros de estas
actividades y tareas, de su ejecución, de los problemas y de las soluciones.
6.3.1.5 Se deberá poner a disposición del adquiriente los registros de las actividades
y tareas de aseguramiento de la calidad, tal como se especifique en el contrato.
6.3.1.6 Se deberá asegurar que las personas responsables de asegurar el

cumplimiento de los requerimientos del contrato tienen la libertad, desde el punto de vista
organizativo, recursos y autoridad, necesaria para permitir evaluaciones objetivas y para
iniciar, efectuar, solucionar y verificar las soluciones a los problemas.
6.3.2 Aseguramiento del producto: Esta actividad consta de las siguientes

tareas:
PERUANA 57 de 189
6.3.2.1 Se deberá asegurar que todos los planes requeridos por el contrato se
documenten, cumplan con el contrato, son mutuamente consistentes y se ejecuten tal como
se requiere.
6.3.2.2 Se deberá asegurar que los productos software y la documentación

relacionada cumplen con el contrato y se adhieren a los planes.
6.3.2.3 Durante la preparación para la entrega de los productos software, se deberá

asegurar que se han satisfecho completamente los requerimientos contractuales y que son
aceptables para el adquiriente.
6.3.3 Aseguramiento del proceso: Esta actividad consta de las siguientes tareas:
6.3.3.1 Se deberá asegurar que aquellos procesos del ciclo de vida del software
(suministro, desarrollo, operación, mantenimiento y procesos de apoyo incluyendo el
aseguramiento de la calidad) empleados para el proyecto, cumplen con el contrato y se
adhieren a los planes.
6.3.3.2 Se deberá asegurar que las prácticas internas de ingeniería software, entorno
de desarrollo, entorno de pruebas y librerías cumplen con el contrato.
6.3.3.3 Se deberá asegurar que los requerimientos aplicables del contratista

principal se transfieren al sub-contratista y que los productos software del sub-contratista
satisfacen los requerimientos del contratista principal.
6.3.3.4 Se deberá asegurar que se proporciona al adquiriente y a otras partes el

soporte y la cooperación requerida de acuerdo con el contrato, negociaciones y planes.
6.3.3.5 Se deberá asegurar que las mediciones del producto software y del proceso
software están de acuerdo con las normas y procedimientos establecidos.
6.3.3.6 Se deberá asegurar que el personal asignado tiene la habilidad y los

conocimientos necesarios para cumplir los requerimientos del proyecto y recibe la
formación necesaria.
PERUANA 58 de 189
6.3.4 Aseguramiento del sistema de calidad: Esta actividad consta de la

siguiente tarea:
6.3.4.1 Las actividades adicionales de gestión de la calidad se deberán asegurar de

acuerdo con las cláusulas de NTP-ISO 9001 tal como se especifica en el contrato.
6.4 Proceso de verificación
El proceso de verificación es un proceso para determinar si los productos software de una

actividad cumplen con los requerimientos o condiciones que tienen impuestas por las
actividades precedentes. Por motivos de efectividad en costo y rendimiento, se debería
integrar, lo antes posible, la verificación, en los procesos (tales como los de suministro,
desarrollo, operación o mantenimiento) que la emplean. Estos procesos pueden incluir
análisis, revisión y prueba.
Este proceso se puede ejecutar con diversos grados de independencia. El grado de

independencia puede fluctuar desde la misma persona o diferente persona dentro de la
misma organización, hasta una persona en distinta organización con un grado de
separación variable. En el caso en que el proceso se ejecute por una organización
independiente del proveedor, desarrollador, operador o responsable de mantenimiento, se
llama proceso de verificación independiente.
b) Verificación.
6.4.1.1 Se deberá determinar si el proyecto requiere un esfuerzo de verificación y el

grado de independencia organizativa necesaria para dicho esfuerzo. Se deberá analizar los
aspectos críticos de los requerimientos del proyecto. Los aspectos críticos se deberán
evaluar en términos de:
PERUANA 59 de 189
a) La probabilidad de que un error no detectado en los requerimientos del

sistema o del software cause muerte o daños personales, fracaso del proyecto,
pérdida financiera o pérdida catastrófica o daño a equipos.
b) Madurez y riesgos asociados con la tecnología software usada.
c) Disponibilidad de fondos y recursos.
6.4.1.2 Si el proyecto requiere un esfuerzo de verificación, se deberá establecer un

proceso de verificación para verificar el producto software.
6.4.1.3 Si el proyecto requiere un esfuerzo de verificación independiente, se deberá

seleccionar una organización calificada responsable de llevar a cabo la verificación. Se
deberá garantizar a esta organización la independencia y autoridad para llevar a cabo las
actividades de verificación.
6.4.1.4 Basándose en el análisis anterior sobre el alcance, magnitud, complejidad y

aspectos críticos, se deberán determinar las actividades del ciclo de vida y los productos
software que requieren verificación. Para estas actividades del ciclo de vida y productos
software se deberá seleccionar las actividades y tareas de verificación definidas en el
apartado 6.4.2, incluyendo los métodos, técnicas y herramientas asociadas para llevarlas a
cabo.
6.4.1.5 Basándose en las tareas de verificación seleccionadas, se deberá preparar y

documentar un plan de verificación. El plan deberá tener en cuenta las actividades del ciclo
de vida y productos software sujetos a verificación, las tareas de verificación requeridas
para cada actividad del ciclo de vida y producto software y los recursos, responsabilidades
y plazos asociados. El plan deberá tener en cuenta procedimientos para hacer llegar los
informes de la verificación al adquiriente y a otras organizaciones involucradas.
6.4.1.6 Se deberá implementar el plan de verificación. Los problemas y no

conformidades detectadas por el esfuerzo de verificación se deberán pasar al proceso de
solución de problemas (6.8). Se deberán resolver todos los problemas y no conformidades.
Se deberá poner a disposición del adquiriente y otras organizaciones involucradas los
resultados de las actividades de verificación.
PERUANA 60 de 189
6.4.2 Verificación: Esta actividad consta de las siguientes tareas:
6.4.2.1 Verificación del contrato: Se deberá verificar el contrato teniendo en

cuenta los criterios enumerados a continuación:
a) El proveedor tiene la capacidad para satisfacer los requerimientos.
b) Los requerimientos son consistentes y cubren las necesidades del usuario.
c) Se han estipulado los procedimientos adecuados para manejar los cambios a

los requerimientos y el escalamiento de problemas.
d) Se han estipulado los procedimientos y el alcance de la interacción y

cooperación entre las partes, incluyendo propiedad, garantía, derechos de copia y
confidencialidad.
e) Se han estipulado criterios y procedimientos de aceptación, de acuerdo con

los requerimientos.
NOTA: Esta actividad se puede usar en las revisiones del contrato (6.3.1.3 b).
6.4.2.2 Verificación del proceso: Se deberá verificar el proceso teniendo en cuenta

los criterios enumerados a continuación:
a) Los requerimientos para la planificación del proyecto son adecuados y están

a su debido tiempo.
b) Los procesos seleccionados para el proyecto son adecuados, se

implementan, están siendo ejecutados tal como se planificó y cumplen con el
contrato.
c) Las normas, procedimientos y entornos para los procesos del proyecto son
adecuados.
d) El proyecto está dotado de personal y el personal está capacitado tal como lo

requiere el contrato.
6.4.2.3 Verificación de los requerimientos: Se deberán verificar los

requerimientos teniendo en cuenta los criterios enumerados a continuación:
PERUANA 61 de 189
a) Los requerimientos del sistema son consistentes, viables y se pueden probar.
b) Los requerimientos del sistema han sido adecuadamente asignados a

elementos hardware, elementos software y operaciones manuales de acuerdo con los
criterios de diseño.
c) Los requerimientos software son consistentes, viables, se pueden probar y

reflejan fielmente los requerimientos del sistema.
d) Los requerimientos software relacionados con seguridad física y de acceso y

otros requerimientos críticos son correctos, según demuestran métodos rigurosos v
adecuados.
6.4.2.4 Verificación del diseño: Se deberá verificar el diseño teniendo en cuenta

los criterios enumerados a continuación.
a) El diseño es correcto, consistente con los requerimientos y trazable hacia

ellos.
b) El diseño implementa la secuencia correcta de eventos, entradas, salidas,

interfaces, flujo lógico, asignación de sincronizaciones y tamaños y definición,
aislamiento y recuperación ante errores.
c) El diseño seleccionado se puede derivar de los requerimientos.
d) El diseño implementa correctamente los requerimientos de seguridad física

y de acceso y otros requerimientos críticos, según demuestran métodos rigurosos y
adecuados.
6.4.2.5 Verificación del código: Se deberá verificar el código teniendo en cuenta

los criterios enumerados a continuación:
a) El código es trazable hacia el diseño y los requerimientos, se puede probar,

es correcto y cumple con los requerimientos y normas de codificación.
b) El código implementa la secuencia correcta de eventos, interfaces

consistentes, flujo correcto de datos y control, completitud, una adecuada asignación
de sincronizaciones y tamaños y definición, aislamiento y recuperación ante errores.
c) El código seleccionado se puede derivar del diseño o de los requerimientos.

PERUANA 62 de 189
d) El código implementa correctamente los requerimientos de seguridad física

y de acceso y otros requerimientos críticos, según demuestran métodos rigurosos y
adecuados.
6.4.2.6 Verificación de la integración: Se deberá verificar la integración teniendo

en cuenta los criterios enumerados a continuación:
a) Los componentes y unidades software de cada elemento software han sido

integrados correcta y completamente en el elemento software.
b) Los elementos hardware, elementos software y operaciones manuales del

sistema han sido completa y correctamente integrados en el sistema.
c) Las tareas de integración se han llevado a cabo de acuerdo con un plan de

integración.
6.4.2.7 Verificación de la documentación: Se deberá verificar la documentación

teniendo en cuenta los criterios enumerados a continuación:
a) La documentación es adecuada, completa y consistente.
b) La preparación de la documentación se hace a su debido tiempo.
c) La gestión de la configuración de los documentos sigue procedimientos

especificados.
6.5 Proceso de validación
El proceso de validación es un proceso para determinar si los requerimientos y el sistema o

producto software, tal como se ha construido, cumplen con su uso específico previsto. La
validación se puede llevar a cabo en etapas tempranas. Este proceso se puede llevar a cabo
como parte del apoyo a la aceptación del producto (5.3.13).
Este proceso se puede ejecutar con diversos grados de independencia. El grado de

independencia puede variar desde la misma persona o diferente persona dentro de la misma
organización, hasta una persona en distinta organización con un grado de separación
PERUANA 63 de 189
variable. En el caso en que el proceso se ejecute por una organización independiente del
proveedor, desarrollador, operador o responsable de mantenimiento, se llama proceso de
validación independiente.
b) Validación.
6.5.1.1 Se deberá determinar si el proyecto merece un esfuerzo de validación y el

grado de independencia organizativa necesaria para dicho esfuerzo.
6.5.1.2 Si el proyecto merece un esfuerzo de validación, se deberá establecer un

proceso de validación para validar el sistema o el producto software. Se deberán
seleccionar las tareas de validación definidas más adelante, incluyendo los métodos,
técnicas y herramientas asociadas.
6.5.1.3 Si el proyecto merece un esfuerzo independiente, se deberá seleccionar una

organización calificada responsable de llevar a cabo este esfuerzo. Se deberá garantizar a
esta organización la independencia y autoridad para llevar a cabo las actividades de
validación.
6.5.1.4 Se deberá preparar y documentar un plan de validación. El plan deberá

incluir (sin estar limitado a ello) lo siguiente:
a) Elementos sujetos a validación.
b) Tareas de validación a llevar a cabo.
c) Recursos, responsabilidades y plazos para la validación.

PERUANA 64 de 189
d) Procedimientos para hacer llegar los informes de validación al adquiriente y

a otras partes.
6.5.1.5 Se deberá implementar el plan de validación. Los problemas y las no

conformidades detectadas por el esfuerzo de validación se deberán pasar al proceso de
solución de problemas (6.8). Se deberán resolver todos los problemas y no conformidades.
Se deberá poner a disposición del adquiriente y otras organizaciones involucradas los
resultados de las actividades de validación.
6.5.2 Validación: Esta actividad consta de las siguientes tareas:
6.5.2.1 Preparar los requerimientos de prueba, casos de prueba y especificaciones

de prueba seleccionados para analizar los resultados de las pruebas.
6.5.2.2 Asegurar que estos requerimientos de prueba, casos de prueba y

especificaciones de prueba reflejan los requerimientos particulares para el uso específico
previsto.
6.5.2.3 Llevar a cabo las pruebas de los apartados 6.5.2.1 y 6.5.2.2, incluyendo:
a) Pruebas con sobrecarga, límites y entradas excepcionales.
b) Pruebas del producto software respecto a su habilidad para aislar y

minimizar el efecto de errores; esto es, degradación elegante por fallos, petición de
asistencia del operador ante sobrecargas y situaciones límite y excepcionales.
c) Pruebas de usuarios representativos que pueden llevar a cabo con éxito sus
tareas previstas usando el producto software.
6.5.2.4 Validar que el producto software satisface su uso previsto.
6.5.2.5 Probar el producto software, cuando sea apropiado, en áreas seleccionadas

del entorno de destino.
PERUANA 65 de 189
6.6 Proceso de revisión conjunta
El proceso de revisión conjunta es un proceso para evaluar el estado y los productos de una
actvidad de un proyecto, según sea adecuado. Las revisiones conjuntas están a nivel tanto
de gestión del proyecto como técnico y se mantienen a lo largo de la vida del contrato. Este
proceso puede ser empleada por cualesquiera de las dos partes, donde una de ellas (la
revisora) revisa a la otra parte (la revisada).
b) Revisiones de la gestión del proyecto.
c) Revisiones técnicas.
6.6.1.1 Se deberán llevar a cabo revisiones periódicas en hitos predeterminados tal

como se especifica en los planes del proyecto. Se pueden llevar a cabo revisiones ad hoc
cuando se considere necesario por cualquiera de las partes.
6.6.1.2 Las partes deberán acordar todos los recursos necesarios para llevar a cabo
las revisiones. Estos recursos incluyen personal, ubicación, instalaciones, hardware,
software y herramientas.
6.6.1.3 Las partes deberán acordar para cada revisión los siguientes elementos:
agenda de la reunión, productos software (y resultados de una actividad) y problemas a
revisar; alcance y procedimientos y criterios de entrada y salida para la revisión.
6.6.1.4 Se deberán registrar los problemas detectados durante las revisiones y

pasarlos al proceso de solución de problemas (6.8) según se requiera.
PERUANA 66 de 189
6.6.1.5 Se deberá documentar y distribuir los resultados de las revisiones. La parte

revisora informará a la parte revisada sobre la adecuación (por ejemplo, aprobación, no-
aprobación o aprobación condicionada) de los resultados de la revisión.
6.6.1.6 Las partes deberán ponerse de acuerdo sobre los resultados de la revisión y
en la responsabilidad sobre cualquier punto de acción y sus criterios de finalización.
6.6.2 Revisiones de la gestión del proyecto: Esta actividad consta de la siguiente

tarea:
Se deberá evaluar el estado del proyecto con relación a los planes, plazos, normas y guías
del proyecto aplicables.
El resultado de la revisión deberá discutirse entre las dos partes y deberá conseguir lo
siguiente:
a) Hacer que las actividades progresen de acuerdo con el plan, basándose en

una evaluación del estado de la actividad o producto software.
b) Mantenimiento del control global del proyecto a través de la adecuada

asignación de recursos.
c) Cambio de la gestión del proyecto o determinación de la necesidad de una

planificación alternativa.
d) Evaluación y gestión de los elementos de riesgo que puedan amenazar el

éxito del proyecto.
6.6.3 Revisiones técnicas: Esta actividad consta de la siguiente tarea:
Se deberán mantener revisiones técnicas para evaluar los productos o servicios software
bajo consideración y proporcionar evidencia de que:
a) Son completos.
PERUANA 67 de 189
b) Cumplen con sus normas y especificaciones.
c) Los cambios se implementan adecuadamente y afectan sólo a aquellas áreas

identificadas por el proceso de gestión de la configuración (6.2).
d) Se están adhiriendo a los plazos aplicables.
e) Están listos para la siguiente actividad.
f) El desarrollo, operación o mantenimiento se lleva a cabo de acuerdo con los

planes, plazos, normas y guías del proyecto.
6.7 Proceso de auditoría
El proceso de auditoría es un proceso para determinar el cumplimiento con los

requerimientos, planes y contrato, según aplique. Este proceso puede ser empleado por
cualesquiera de las dos partes, donde una de ellas (la auditora) audita los productos
software o actividades de la otra parte (la auditada).
b) Auditoría.
6.7.1.1 Se deberán llevar a cabo auditorías en hitos predeterminados tal como se

especifique en los planes del proyecto.
6.7.1.2 El personal auditor no debería tener responsabilidad directa sobre los

productos software y actividades que auditen.
PERUANA 68 de 189
6.7.1.3 Las partes deberán acordar todos los recursos necesarios para llevar a cabo
las auditorías. Estos recursos incluyen personal, ubicación, instalaciones, hardware,
software y herramientas.
6.7.1.4 Las partes deberán acordar para cada auditoría los siguientes elementos:
agenda; productos software (y resultados de una actividad) a revisar; alcance y
procedimientos y criterios de entrada y salida para la auditoría.
6.7.1.5 Se deberán registrar los problemas detectados durante las auditorías y

pasarlos al proceso de solución de problemas (6.8) según se requiera.
6.7.1.6 Tras completar una auditoría, los resultados de la auditoría se deberán

documentar y proporcionar a la parte auditada. La parte auditada deberá informar a la parte
auditora de cualquier problema encontrado en la auditoría y las soluciones de problemas
planeados asociados.
6.7.1.7 Las partes deberán ponerse de acuerdo sobre los resultados de la auditoría y
en la responsabilidad sobre cualquier punto de acción y sus criterios de finalización.
6.7.2 Auditoría: Esta actividad consta de la siguiente tarea:
Se deberán llevar a cabo auditorías para asegurar que:
a) Los productos software tal como están codificados (tales como un elemento
software) reflejan la documentación de diseño.
b) Los requerimientos prescritos por la documentación para las revisiones de

aceptación y las pruebas, son adecuados para la aceptación de los productos
software.
c) Los datos para las pruebas cumplen con la especificación.
d) Los productos software han sido adecuadamente probados y cumplen sus

especificaciones.
PERUANA 69 de 189
e) Los informes de pruebas son correctos y las discrepancias entre los

resultados reales y los esperados se han resuelto.
f) La documentación de usuario cumple con las normas especificadas.
g) Las actividades se han llevado a cabo de acuerdo con los requerimientos

aplicables, planes y contrato.
h) Los costos y los plazos se adhieren a los planes establecidos.
6.8 Proceso de solución de problemas
El proceso de solución de problemas es un proceso para analizar y resolver problemas

(incluidas las no conformidades), cualquiera que sea su naturaleza u origen, que se
descubran durante la ejecución de los procesos de desarrollo (5.3), operación (5.4),
mantenimiento (5.5) u otros. El objetivo es el proporcionar un mecanismo que responsable,
documentariamente y a tiempo asegure que todos los problemas descubiertos se analizan y
resuelven y se reconozcan las tendencias.
b) Solución de problemas.
6.8.1.1 Se deberá establecer un proceso de solución de problemas para manejar

todos los problemas (incluyendo las no conformidades) detectados en los productos y
actividades software. El proceso deberá cumplir los siguientes requerimientos:
a) El proceso deberá ser un bucle cerrado, asegurando que: se informa

rápidamente de todos los problemas detectados y se introducen en el proceso de
solución de problemas; se inician acciones sobre ellos; se informa a las partes
implicadas según sea necesario acerca de la existencia de los problemas; las causas
se identifican, analizan y, donde sea posible, se eliminan; se consigue una solución y
PERUANA 70 de 189
la eliminación; se hace un seguimiento y se informa del estado; se mantienen

registros de los problemas tal como se estipule en el contrato.
b) El proceso deberá contener un esquema para categorizar y priorizar los

problemas. Conviene que cada problema se clasifique por categoría y prioridad para
facilitar el análisis de tendencias y la solución del problema.
c) Se deberán llevar a cabo análisis para detectar tendencias; en los problemas

informados.
d) Se deberán evaluar las soluciones y las disposiciones para evaluar que los
problemas han sido resueltos, las tendencias adversas han sido invertidas y los
cambios han sido implementados correctamente en los productos y actividades
software apropiados; y determinar si se han introducido problemas adicionales.
6.8.2 Solución de problemas: Esta actividad consta de la siguiente tarea:
6.8.2.1 Cuando se han detectado problemas (incluyendo no conformidades) en un

producto o actividad software, se deberá preparar para cada problema detectado un informe
describiendo el problema. El informe del problema se deberá usar como parte del proceso
en bucle cerrado descrito anteriormente: desde la detección del problema, pasando por la
investigación, análisis y solución del problema y su causa, hasta la detección de tendencias
en los problemas.
Este capítulo define los siguientes procesos organizativos del ciclo de vida:
1. Proceso de gestión.
2. Proceso de infraestructura.
3. Proceso de mejora.
4. Proceso de recursos humanos.

PERUANA 71 de 189
Las actividades y tareas en un proceso organizativo son responsabilidad de la organización

que usa dicho proceso. Esta organización se asegura de que el proceso exista y esté
operativo.
7.1 Proceso de gestión
El proceso de gestión contiene las actividades genéricas y tareas que pueden ser empleadas
por cualquier parte que tenga que gestionar sus respectivos procesos. El gerente es
responsable de la gestión del producto, gestión del proyecto y gestión de las tareas de los
procesos aplicables, tales como el de adquisición (5.1), suministro (5.2), desarrollo (5.3),
operación (5.4), mantenimiento (5.5) o soporte.
a) Inicio y definición del alcance.
b) Planificación.
c) Ejecución y control.
d) Revisión y evaluación.
e) Finalización.
7.1.1 Inicio y definición del alcance: Esta actividad consta de las siguientes
tareas:
7.1.1.1 El proceso de gestión se deberá iniciar estableciendo los requerimientos

del proceso a emprender.
7.1.1.2 Una vez que se han establecido los requerimientos, el gerente deberá
establecer la viabilidad del proceso comprobando que los recursos (personal, materiales,
tecnología y entorno) requeridos para ejecutar y gestionar el proceso están disponibles, son
adecuados y apropiados, y que los plazos para su finalización son alcanzables.
PERUANA 72 de 189
7.1.1.3 Tal como sea necesario y por acuerdo de todas las partes interesadas, los
requerimientos del proceso pueden ser modificados en este momento para alcanzar los
criterios de finalización.
7.1.2 Planificación: Esta actividad consta de la siguiente tarea:
7.1.2.1 El gerente deberá preparar los planes para la ejecución del proceso. Los
planes asociados con la ejecución del proceso deberán contener descripciones de las
actividades y tareas asociadas y la identificación de los productos software que serán
proporcionados. Estos planes deberán incluir, sin estar limitados a ello, lo siguiente:
a) Plazos para la terminación a tiempo de las tareas.
b) Estimación del esfuerzo.
c) Recursos adecuados necesarios para ejecutar las tareas.
d) Asignación de tareas.
e) Asignación de responsabilidades.
f) Cuantificación de los riesgos asociados con las tareas o el mismo proceso.
g) Medidas para el control de calidad a emplear a lo largo del proceso.
h) Costos asociados con la ejecución del proceso.
i) Provisión del entorno e infraestructura.
7.1.3 Ejecución y control: Esta actividad consta de las siguientes tareas:
7.1.3.1 El gerente deberá iniciar la implementación del plan para satisfacer los
objetivos y criterios establecidos, ejerciendo control sobre el proceso.
7.1.3.2 El gerente deberá supervisar la ejecución del proceso, proporcionando

informes internos del progreso del proceso e informes externos al adquiriente tal como se
define en el contrato.
PERUANA 73 de 189
7.1.3.3 El gerente deberá investigar, analizar y solucionar los problemas

descubiertos durante la ejecución del proceso. La solución de los problemas; puede dar
lugar a cambios en los planes. Es responsabilidad del gerente asegurar que se determine,
controle y supervise el impacto de cualquier cambio. Se deberán documentar los problemas
y sus soluciones.
7.1.3.4 El gerente deberá informar, en momentos acordados, sobre el progreso del

proceso, cumplimiento de los planes y soluciones a las situaciones de falta de progreso.
Esto incluye informes tanto internos como externos, tal como requieren los procedimientos
organizativos y el contrato.
7.1.4 Revisión y evaluación: Esta actividad consta de las siguientes tareas:
7.1.4.1 El gerente deberá asegurar que los productos software y los planes se
evalúan con relación a la satisfacción de los requerimientos.
7.1.4.2 El gerente deberá analizar los resultados de la evaluación de los productos

software, actividades y tareas completadas durante la ejecución del proceso, en relación al
cumplimiento de los objetivos y de los planes.
7.1.5 Finalización: Esta actividad consta de las siguientes tareas:
7.1.5.1 Cuando se complete todos los productos software, actividades y tareas, el

gerente deberá determinar si el proceso se ha completado teniendo en cuenta los criterios
especificados en el contrato, o como parte de un procedimiento de la organización.
7.1.5.2 El gerente deberá comprobar que los resultados y registros de los productos
software, actividades y tareas empleadas se han completado. Se deberán archivar estos
resultados y registros en un entorno adecuado, tal como se especifica en el contrato.
7.2 Proceso de infraestructura
El Proceso de Infraestructura es un proceso para establecer y mantener la infraestructura

que necesita cualquier otro proceso. La infraestructura puede incluir hardware, software,
PERUANA 74 de 189
herramientas, técnicas, normas e instalaciones para el desarrollo, operación o

mantenimiento.
b) Establecimiento de la infraestructura.
c) Mantenimiento de la infraestructura.
7.2.1.1 Conviene que se defina y documente la infraestructura para cumplir los

requerimientos del proceso que este emplea, considerando los procedimientos, normas,
herramientas y técnicas aplicables.
7.2.1.2 Conviene que se planifique y documente el establecimiento de la

infraestructura.
7.2.2 Establecimiento de la infraestructura: Esta actividad consta de las

siguientes tareas:
7.2.2.1 Conviene que se planifique y documente la configuración de la

infraestructura. Se deberían considerar aspectos de funcionalidad, prestaciones, seguridad
física y de acceso, disponibilidad, requerimientos de espacio, equipos, costos y
limitaciones de tiempo.
7.2.2.2 Se deberá instalar la infraestructura a tiempo para la ejecución del proceso

en cuestión.
7.2.3 Mantenimiento de la infraestructura: Esta actividad consta de la siguiente

tarea:
PERUANA 75 de 189
7.2.3.1 Se deberá hacer mantenimiento, seguimiento y modificación de la

infraestructura según sea necesario para asegurar que continúa satisfaciendo los
requerimientos del proceso que este emplea. Como parte del mantenimiento de la
infraestructura, se deberá definir hasta qué punto la infraestructura está bajo gestión de la
configuración.
7.3 Proceso de mejora de proceso
El proceso de mejora de proceso es un proceso para establecer, evaluar, medir, controlar y

mejorar un proceso del ciclo de vida del software.
a) Establecimiento del proceso.
b) Evaluación del proceso.
c) Mejora del proceso.
7.3.1 Establecimiento del proceso: Esta actividad consta de la siguiente tarea:
7.3.1.1 La organización deberá establecer un conjunto de procesos organizativos

para todos los procesos del ciclo de vida del software en tanto son de aplicación a sus
actividades de negocio. Se debería documentar en publicaciones de la organización los
procesos y su aplicación a casos específicos. Como sea apropiado, se deberá establecer un
mecanismo de control del proceso para desarrollar, hacer seguimiento, controlar y mejorar
los procesos.
7.3.2 Evaluación del proceso: Esta actividad consta de las siguientes tareas:
7.3.2.1 Se deberá desarrollar, documentar y aplicar un proceso de evaluación de

procesos. Se deberán guardar y mantener registros de las evaluaciones.
PERUANA 76 de 189
7.3.2.2 La organización deberá planificar y llevar a cabo revisiones de los procesos

con la periodicidad adecuada que asegure su continua adecuación y efectividad, a la luz de
los resultados de las evaluaciones.
7.3.3 Mejora del proceso de mejora: Esta actividad consta de las siguientes
tareas:
7.3.3.1 La organización deberá efectuar en sus procesos las mejoras que se

consideren necesarias como resultado de las evaluaciones y revisiones de los procesos. Se
deberá actualizar la documentación del proceso para reflejar las mejoras en los procesos de
la organización.
7.3.3.2 Se deberá recopilar y analizar los datos históricos, técnicos y de las

evaluaciones para conseguir un conocimiento de los puntos fuertes y débiles de los
procesos empleados. Se deberán emplear estos análisis como entrada para mejorar dichos
procesos, recomendar cambios en la gestión de los proyectos (actuales o sub-siguientes) y
determinar las necesidades de mejoras tecnológicas.
7.3.3.3 Se deberá recopilar, mantener y usar datos de costos de la calidad para

mejorar los procesos de la organización, como una actividad de gestión. Estos datos
deberán tener el propósito de establecer los costos de prevención y solución de problemas
y no conformidades en los productos y servicios software.
7.4 Proceso de recursos humanos
7.4.1.1 El proceso de recursos humanos es un proceso para proporcionar y

mantener personal capacitado. La adquisición, suministro, desarrollo, operación o
mantenimiento de los productos software depende en gran medida de personal entendido y
competente. Por ejemplo el personal de desarrollo deberá tener formación básica en
ingeniería y gestión del software. Es así pues imprescindible que la formación del personal
esté planificada e implementada de manera temprana, para que esté disponible personal
capacitado en el momento en que el producto software se adquiera, suministra, desarrolla,
opera o mantiene.

PERUANA 77 de 189
b) Desarrollo del material de formación.
c) lmplementación del plan de formación.

Se deberá llevar a cabo una revisión de los requerimientos del proyecto para establecer y
prever a tiempo la adquisición o desarrollo de los recursos y competencias que necesita el
personal de gestión y técnico. Se deberán determinar los tipos y niveles de formación y
categorías del personal que necesita formación. Se deberá preparar y documentar un plan
de formación que tenga en cuenta los plazos de implementación, necesidad de recursos y
necesidades de formación.
7.4.2 Desarrollo del material de formación: Esta actividad consta de la

siguiente tarea:
7.4.2.1 Se deberá desarrollar los manuales de formación, incluyendo material de

presentaciones, que se usen para proporcionar la formación.
7.4.3 Implementación del plan de formación: Esta actividad consta de las

siguientes tareas:
7.4.3.1 Se deberá implementar el plan de formación para proporcionar la formación

al personal. Se deberán mantener registros de formación.
7.4.3.2 Se deberá asegurar que personal adecuadamente capacitado y con la

composición y categorías adecuadas, esté disponible en el momento preciso para las
actividades y tareas planificadas.
8. ANTECEDENTE
ISO/IEC 12207:1995/Amd1:2002 INFORMATION TECHNOLOGY.

Software life cycle processes
PERUANA 78 de 189
ANEXO A
(INFORMATIVO)
PROCESO DE ADAPTACIÓN
El proceso de adaptación es un proceso para llevar a cabo las adaptaciones básicas de esta
NTP a un proyecto software. Este Anexo proporciona requerimientos para adaptar esta
NTP.
a) Identificación del entorno del proyecto.
b) Solicitud de entradas.
c) Selección de procesos, actividades y tareas.
d) Documentación de las decisiones y razones de las adaptaciones.
A.1 Identificación del entorno del proyecto
Esta actividad consta de la siguiente tarea:
A.1.1 Se deberán identificar las características del entorno del proyecto que van a
influir en la adaptación. Algunas de estas características pueden ser: modelo del ciclo de
vida; actividad actual del ciclo de vida del sistema; requerimientos del sistema y
requerimientos software; políticas, procedimientos y estrategias de la organización:
tamaño, aspectos críticos y tipo del sistema, producto o servicio software; número de
personal y partes involucradas.
A.2 Solicitud de entradas

PERUANA 79 de 189
Se deberán solicitar entradas de las organizaciones que se verán afectadas por las
decisiones de la adaptación. Se puede involucrar a los usuarios, personal de soporte,
responsables de la contratación y potenciales ofertantes.
A.3 Selección de procesos, actividades y tareas
Esta actividad consta de las siguientes tareas:
A.3.1 Se deberán decidir los procesos, actividades y tareas a llevar a cabo

incluyendo la documentación a desarrollar y quien es responsable de ellas. Por este motivo
se debería evaluar esta NTP frente a los datos relevantes obtenidos en los apartados A.1 y
A.2.
A.3.2 Los procesos, actividades y tareas que se decidieron en el apartado A.3.1 y

no contempladas en esta NTP se deberán especificar en el propio contrato. Conviene que
se evalúen los procesos del ciclo de vida (capítulo 7) de la organización para determinar si
pueden contemplar estos procesos, actividades y tareas.
A.3.3 En esta NTP, los requerimientos se indican mediante tareas con ‘deberá’ u
otros verbos en futuro. Conviene que estas tareas se consideren cuidadosamente por si se
deben mantener o eliminar en un proyecto dado o sector de negocios. Factores a tener en
consideración sin limitarse a ellos son: riesgo, costo, plazos, rendimiento, tamaño, aspectos
críticos e interfaz humana.
A.4 Documentación de las decisiones y razones de las adaptaciones
A.4.1 Se deberán documentar todas las decisiones de adaptación, junto con las
razones de las decisiones.
PERUANA 80 de 189
ANEXO B
(INFORMATIVO)
GUÍA PARA LA ADAPTACIÓN
No hay dos proyectos iguales. Las variaciones en los procedimientos y políticas de las
organizaciones, en los métodos y estrategias de adquisición, en el tamaño y complejidad de
los proyectos, en los requerimientos del sistema y métodos de desarrollo, entre otras cosas,
influyen en cómo un sistema se adquiere, desarrolla, opera o mantiene. Esta NTP se ha
escrito para que un proyecto genérico se adapte a tales variaciones tanto como sea posible.
Así pues, en interés de la reducción de costos y mejora de la calidad, conviene que esta
NTP sea adaptada a proyectos concretos. Se deberían incluir en la adaptación todas las
partes involucradas en el proyecto.
B.1 Guía general para la adaptación
Este apartado proporciona guías para la adaptación de esta NTP y no es exhaustivo. Este
apartado se puede usar para llevar a cabo una adaptación a primer nivel de esta NTP para
un área de negocio dada; por ejemplo aviación, nuclear, médica, militar, país u
organización. La adaptación a segundo nivel se debería llevar a cabo para un proyecto o
contrato específico.
B.2 Adaptación del proceso de desarrollo
El proceso de desarrollo (5.3) necesita una especial atención ya que este proceso se puede
usar por diferentes partes con diferentes objetivos. Para una adaptación a primer nivel de
este proceso se recomienda lo siguiente:
a) Para un producto software que está empotrado o es parte esencial de un

sistema: se deberían considerar todas las actividades del proceso y se debería
clarificar si se requiere que el desarrollador lleve a cabo o soporte las actividades del
sistema.
b) Para un producto software 100% las actividades del sistema (5.3.2, 5.3.3,
5.3.10 y 5.3.11) puede que no se requieran, aunque se deberían considerar.
PERUANA 81 de 189
B.3 Adaptación de las actividades relacionadas con evaluaciones
Las personas que están involucradas en alguna de las actividades del ciclo de vida de un
proyecto o de un proceso, llevan a cabo evaluaciones ya sea sobre sus productos o
actividades software o sobre los de otros. Esta NTP agrupa estas evaluaciones en cinco
categorías, que se enumeran más adelante. Las primeras cuatro categorías de evaluación
son al nivel de proyecto; la última es a nivel de organización. Conviene que se seleccionen
y adapten estas categorías en proporción al alcance, magnitud, complejidad y aspectos
críticos del proyecto o de la organización. Los informes sobre problemas, no
conformidades y mejoras provenientes de las evaluaciones alimentan el proceso de
solución de problemas (6.8).
a) Evaluaciones internas a un proceso (tareas de evaluación en 5.1 a 5.5): Se

ejecutan por personal que lleva a cabo las tareas asignadas dentro del proceso durante
sus actividades del día a día.
b) Verificación (6.4) y validación (6.5): Se llevan a cabo por el adquiriente, el

proveedor o una parte independiente, para verificar y validar los productos a mayor o
menor profundidad, dependiendo del proyecto. Estas evaluaciones no duplican ni
reemplazan otras evaluaciones, sino que las suplementan.
c) Revisión conjunta (6.6) y auditorías (6.7): Se llevan a cabo en una reunión

conjunta entre la parte revisora y la parte revisada, para evaluar el estado y
cumplimiento de los productos y actividades siguiendo un plan preacordado.
d) Aseguramiento de la calidad (6.3): Se lleva a cabo por personal

independiente del personal directamente responsable del desarrollo del producto
software o de la ejecución del proceso. El objetivo es asegurar, de una manera
independiente, la conformidad de los productos y procesos software con los
requerimientos del contrato y la adherencia a los planes establecidos. Este proceso
puede usar los resultados de a, b y c como entradas. Este proceso puede coordinar sus
actividades con las de a, b y c.
e) Mejora de Proceso (7.3): Se lleva a cabo por una organización para una
gestión eficiente y auto mejora de sus procesos. Se lleva a cabo independientemente
de los requerimientos del proyecto o contrato.
PERUANA 82 de 189
B.4 Consideraciones sobre las adaptaciones y la aplicación
Los párrafos de este apartado esbozan diversas consideraciones sobre adaptación y aplicación
para características clave del proyecto. Ni las consideraciones ni las características son
exhaustivas y representan sólo el pensamiento actual. La figura B.1 proporciona un ejemplo
de aplicación de esta NTP.
Políticas de la organización: Determina que políticas de la organización son relevantes y

aplicables, tales como lenguajes de computadora, seguridad física y de acceso,
requerimientos de necesidades hardware y gestión de riesgos. Se deberían mantener los
capítulos de esta NTP relacionados con estas políticas de la organización.
Estrategia de adquisición: Determina qué estrategias de adquisición son relevantes y

aplicables al proyecto, tales como tipos de contrato, más de un contratista, involucramiento
de los sub-contratistas y de los agentes de verificación y validación, grado de
involucramiento del adquiriente con los contratistas y evaluación de la capacidad de los
contratistas. Se deberían mantener los capítulos de esta NTP relacionados con estas
estrategias.
Concepto de soporte: Determina qué conceptos de soporte son relevantes y aplicables, tales
como la duración esperada del soporte, grado de cambio y si será soportado por el
adquiriente o por el proveedor. Si el producto software va a tener soporte durante un largo
tiempo, o si se espera que cambie significativamente, se deberían considerar todos los
requerimientos de documentación. Es recomendable tener automatizada la documentación.
Modelos de ciclo de vida: Determina qué modelo o modelos de ciclo de vida son
relevantes y aplicables al proyecto, tales como en cascada, evolutivo, incremental, mejoras
sucesivas planeadas del producto, o espiral. Todos estos modelos prescriben ciertos
procesos y actividades que se pueden llevar a cabo secuencialmente, repetidamente y
combinadamente; en estos modelos, las actividades del ciclo de vida de esta NTP deberían
estar correlacionadas con el modelo o modelos seleccionados. Para el evolutivo,
incremental o mejoras sucesivas, las salidas de una actividad del proyecto alimentan la
siguiente. En estos casos, la documentación se debería completar al final de cada actividad
o tarea.
PERUANA 83 de 189
MODELOS Y MÉTODOS
OTRAS ENTRADAS
TIEMPO NORMA ISO/IEC

DE PROCESOS
DINERO DEL CICLO DE
VIDA DEL
SOFTWARE M
CASCADA E
T
O
REQUISITOS D
NORMATIVA O
LEGAL ESPIRAL S
SEGURIDAD DE DE LA COMPAÑIA
ACCESO
ENTORNO
SEGURIDAD
FÍSICA
ADAPTACIÓN DE LA
APLICACIÓN, PRUEBAS
DE EVALUACIÓN, ETC
CREDENCIALES
MATRIZ DE RESPONSABILIDAD
(ISO 9001, ...)
QUE
CAPACIDAD DE LA ADQ SU DES OP MNT
ORGANIZACIÓN QUIÉN
ADQ
MANUAL DE LA SU
CALIDAD
DES
OP
PROCEDIMIENTOS CONTRATO
MNT
PLAN DE LA
CALIDAD
PLAN DEL
PROYECTO
INICIO DEL PROYECTO
FIGURA B.1 – Ejemplo de aplicación de esta NTP

PERUANA 84 de 189
Partes involucradas: Determina o identifica qué partes están involucradas en el proyecto,

tales como el adquiriente, proveedor, sub-contratista, agente de verificación, agente de
validación, responsable de mantenimiento; y el volumen de personal. Todos los
requerimientos relacionados con interfaces organizativas entre dos partes, entran en
consideración: por ejemplo entre adquiriente y desarrollador, o entre proveedor y agente
verificador o agente validador. Un proyecto grande que involucre a mucha gente (decenas
o cientos de personas) requiere una supervisión de gestión y control significativa.
Herramientas tales como evaluaciones internas o independientes. Revisiones, auditorías e
inspecciones y recopilación de datos, son importantes en proyectos grandes. En proyectos
pequeños estos controles pueden ser excesivos.
Actividad del ciclo de vida del sistema: Determina qué actividades del ciclo de vida del
sistema actual son relevantes y aplicables tales como el inicio del proyecto por parte del
adquiriente, el desarrollo por parte del proveedor y el mantenimiento. Algunos escenarios:
El adquiriente inicia o define los requerimientos del sistema. Se pueden llevar a cabo
estudios de viabilidad y el desarrollo prototipo para los requerimientos y el diseño. Se
puede desarrollar código software para los prototipos y este código puede o no ser usado
posteriormente en el desarrollo de los productos software a desarrollar bajo contrato. Se
pueden desarrollar los requerimientos del sistema y los requerimientos preliminares. En
estos casos se puede usar el proceso de desarrollo (5.3) más como guía que como
requerimiento; puede que no se necesite el rigor de una calificación ni de una evaluación;
puede que no se necesiten revisiones conjuntas ni auditorías.
El desarrollador está produciendo productos software bajo contrato. En este caso, se

deberían considerar todos los requerimientos del proceso de desarrollo (5.3) durante la
adaptación.
El responsable de mantenimiento está modificando los productos software. El proceso de

mantenimiento (5.5) está bajo consideración. Se pueden usar partes del proceso de
desarrollo (5.3) como mini-procesos.
Características a nivel de sistema: Determina qué características al nivel de sistema son

relevantes y aplicables, tales como el número de sub-sistemas y de elementos de
configuración. Si el sistema tiene muchos sub-sistemas o elementos de configuración,
conviene que el proceso de desarrollo (5.3) sea cuidadosamente adaptado para cada sub-
sistema y elemento de configuración. Se deberían considerar todos los requerimientos sobre
interfaces e integración.
PERUANA 85 de 189
Características a nivel software: Determina qué características a nivel software son

relevantes y aplicables, tales como número de elementos software, tipos, tamaño y
aspectos críticos de los productos software y riesgos técnicos. Si el producto software tiene
muchos elementos software, componentes y unidades, conviene que el proceso de
desarrollo (5.3) sea cuidadosamente adaptado para cada elemento software. Se deberían
considerar todos los requerimientos sobre interfaces e integración.
Determina qué tipos de productos software están involucrados ya que diferentes tipos de
productos software pueden requerir diferentes decisiones de adaptación. Algunos ejemplos:
a) Nuevo desarrollo: Todos los requerimientos, particularmente los del proceso

de desarrollo (5.3), deberían tenerse en consideración.
b) Uso de un producto software preelaborado, "tal cual”. El proceso de

desarrollo (5.3) completo puede ser excesivo. Conviene que se evalúen las
prestaciones, documentación, derechos de propiedad, uso, garantía y licencias y
soporte futuro relacionado con el producto software.
c) Modificación de un producto software preelaborado. La documentación

puede no estar disponible. Dependiendo de lo crítico y de los cambios futuros
esperados, se debería usar el proceso de desarrollo (5.3) a través de proceso de
mantenimiento (5.5). Se debería evaluar las prestaciones, documentación, derechos
de propiedad, uso, garantía y licencias y soporte futuro relacionado con el producto
software.
d) Producto software o firmware empotrado en o integrante de un sistema: Ya

que tal producto software es parte de un sistema más grande, conviene que se
consideren las actividades relacionadas con sistemas del proceso de desarrollo (5.3).
En las actividades relacionadas con sistemas, sólo es necesario seleccionar un verbo:
“llevar a cabo" o "dar soporte”. Si no es probable que en el futuro el producto
software o firmware vaya a ser modificado, se debería examinar cuidadosamente el
alcance y necesidades de documentación.
e) Producto software independiente: Ya que tal producto software no es parte

de un sistema, las actividades relacionadas con sistemas del proceso de desarrollo
(5.3) no tienen que ser consideradas. Conviene que se examinen cuidadosamente las
necesidades de documentación para su mantenimiento.
f) Producto software no entregable: Ya que no se va a adquirir, suministrar o

desarrollar ningún elemento, no se debería considerar ninguna estipulación de esta
NTP distinta de la 5.3.1.5 del proceso de desarrollo (5.3). Sin embargo, si el
PERUANA 86 de 189
adquiriente decide adquirir alguna parte de tal producto software para futura
operación y mantenimiento, entonces este producto software se debería tratar como
en b o c.
Otras consideraciones.
Cuanto más dependiente sea el sistema en que el producto software opere correctamente y
esté terminado a tiempo, más control de gestión debería imponerse a través de pruebas,
revisiones, auditorías, verificación, validación, etc. Por otra parte, demasiado control de
gestión sobre productos software pequeños o no críticos, puede no ser efectiva en costo.
El desarrollo del producto software puede tener riesgos técnicos. Si la tecnología software
usada no es madura, el producto software que se desarrolla no tiene precedentes o es
complejo, o contiene requerimientos de seguridad física o de acceso u otros requerimientos
críticos, entonces pueden ser necesarias unas especificaciones, diseño, pruebas y
evaluaciones rigurosas. Puede ser importante una verificación y validación independiente.
PERUANA 87 de 189
ANEXO C
(INFORMATIVO)
GUÍA SOBRE PROCESOS Y ORGANIZACIONES
Para facilitar la comprensión, este anexo, presenta una discusión sobre procesos,
organizaciones y sus relaciones bajo puntos de vista clave.
C.1 Procesos bajo puntos de vista clave
Esta NTP contiene los procesos que son aplicables a lo largo del ciclo de vida del software.
Sin embargo estos procesos se pueden usar de diferentes maneras por diferentes
organizaciones y partes con distintas visiones y objetivos. Este apartado presenta los
procesos y sus relaciones bajo puntos de vista clave, véase el apartado 4.1.1 para una
sinopsis de los procesos.
La Figura C.1 representa los procesos del ciclo de vida y sus relaciones bajo distintos
puntos de vista del uso de esta NTP. Los puntos de vista básicos mostrados son: contrato,
gestión, operación, ingeniería y apoyo. Bajo el punto de vista del contrato, las partes
adquiriente y proveedor negocian y se someten a un contrato empleando el proceso de
adquisición y el proceso de suministro, respectivamente. Bajo el punto de vista de gestión,
el adquiriente, proveedor, desarrollador, operador, responsable de mantenimiento u otras
partes gestionan sus respectivos procesos. Bajo el punto de vista de operación, el operador
proporciona el servicio de operación del software para sus usuarios. Bajo el punto de vista
de ingeniería, el desarrollador o responsable de mantenimiento llevan a cabo sus
respectivas tareas de ingeniería para producir o modificar los productos software. Bajo el
punto de vista del apoyo, las partes (tales como la gestión de la configuración o
aseguramiento de la calidad) proporcionan servicios de apoyo a otros para completar tareas
únicas y específicas. También se muestran (véase el recuadro de la parte interior) los
procesos organizativos; éstos se emplean por la organización a nivel corporativo, para
establecer e implementar la estructura subyacente compuesta por los procesos y el personal
asociados al ciclo de vida y mejorarlos continuamente.
La Figura C2 presenta los procesos principales (recuadro de arriba a la izquierda), de

apoyo (recuadro de arriba a la derecha) y organizativos (recuadro de abajo) del ciclo de
vida y los nombres de las actividades que los constituyen bajo distintos puntos de vista.
Los números que preceden a cada proceso hacen referencia a capítulos de esta NTP.
PERUANA 88 de 189
El punto de vista del contrato tiene dos procesos del ciclo de vida (véase el recuadro
superior sombreado en los procesos principales del ciclo de vida): Un proceso de
adquisición para el adquiriente y un proceso de suministro para el proveedor. Cada proceso
muestra sus actividades constituyentes. Estos procesos definen las tareas para el
adquiriente y proveedor respectivamente, desde el punto de vista contractual.
El punto de vista de ingeniería tiene dos procesos del ciclo de vida (véase el recuadro
inferior izquierdo sombreado en los procesos principales del ciclo de vida): un proceso de
desarrollo y un proceso de mantenimiento. Cada proceso muestra sus actividades
constituyentes. El proceso de desarrollo se emplea por los ingenieros de desarrollo para
producir los productos software. El proceso de mantenimiento se emplea por los ingenieros
de mantenimiento para modificar el software y mantenerlo actualizado.
El punto de vista operativo tiene un proceso del ciclo de vida (véase el recuadro inferior
derecho sombreado en los procesos principales del ciclo de vida): el proceso de operación
y sus actividades constituyentes. El proceso de operación se emplea para operar el software
para sus usuarios.
El punto de vista de la gestión de la calidad tiene seis procesos del ciclo de vida (véase el
recuadro sombreado de los procesos de apoyo del ciclo de vida): proceso de aseguramiento
de la calidad, proceso de verificación, proceso de validación, proceso de revisión conjunta,
y proceso de auditorías. No se muestran sus actividades constituyentes. Estos procesos
relacionados con la calidad se emplean para gestionar la calidad a lo largo del ciclo de vida
del software. Los procesos de verificación, validación, revisiones conjuntas y de auditorías
se pueden emplear por diferentes partes separadamente o como técnicas del proceso de
aseguramiento de la calidad.
El punto de vista de la gestión tiene un proceso (véase el recuadro sombreado en los

procesos organizativos del ciclo de vida): el proceso de gestión, que es usado por cualquier
organización para gestionar sus respectivos procesos. Se muestran sus actividades
constituyentes.
C.2 Procesos, organizaciones y relaciones
Los procesos y organizaciones (o partes) están sólo relacionados funcionalmente. No

prescriben ninguna estructura para ninguna organización (o parte),
PERUANA 89 de 189
En esta NTP, los términos "organización" y "parte" son casi sinónimos. Una organización
es una agrupación de personas organizadas para un propósito específico, como un club,
sindicato, corporación o sociedad. Cuando una organización ya sea como un todo o en
parte, entra en un contrato, es una parte. Las organizaciones son entidades separadas, pero
las partes pueden ser de la misma organización o de organizaciones distintas.
Una organización o una parte toman el nombre del proceso que llevan a cabo; por ejemplo
se le llama adquiriente cuando lleva a cabo el proceso de adquisición.
Una organización puede llevar a cabo uno o varios procesos; un proceso puede ser llevado
a cabo por una o varias organizaciones. Bajo un contrato o aplicación de esta NTP, una
parte no debería llevar a cabo simultáneamente el proceso de adquisición y el proceso de
suministro, pero puede llevar a cabo otros procesos.
En esta misma NTP, las relaciones entre procesos son sólo estáticas. Las relaciones
dinámicas más importantes de la vida real, entre procesos, entre partes y entre procesos y
partes se establecen automáticamente cuando esta NTP se aplica en proyectos software.
Cada proceso (y la parte que lo lleva a cabo) contribuye al proyecto software de una
manera propia y única. El proceso de adquisición (y el adquiriente), contribuye definiendo
el sistema, el cual contendrá el producto software. El proceso de suministro (y el
proveedor) contribuye proporcionando el producto o servicio software del cual dependerá
el sistema. El proceso de desarrollo (y el desarrollador) contribuye "mirando" en el sistema
para derivar y definir correctamente el producto software, soportando la integración
adecuada del producto software dentro del sistema y desarrollando el producto software
entre ellos. El proceso de operación (y el operador) contribuye operando el producto
software en el entorno del sistema para el beneficio de los usuarios, el negocio y la misión.
El proceso de mantenimiento (y el responsable de mantenimiento) contribuye manteniendo
y preservando el producto software en buen estado de operación y proporcionando soporte
y consejo a la comunidad de usuarios. Cada proceso de apoyo u organizativo contribuye
proporcionando funciones únicas y especializadas a otros procesos según se necesite.
PERUANA 90 de 189
VISIÓN CONTRACTUAL
emplea Proceso de Proceso de • Adquiriente
Adquisición contrato Suministro • Proveedor
emplea
emplea VISIÓN GESTORA

• Proceso de Gestión • Gerente
emplea emplea emplea
VISIÓN OPERATIVA
• Proceso de • Operador
Operación Usuario
emplea
emplea
VISIÓN DE LA • Desarrollador
emplea Proceso de Proceso de INGENIERÍA • Responsable de
•
Mantenimiento Desarrollo mantenimiento
Procesos de Apoyo
PUNTO DE VISTA DEL • Usuario de
• Documentación • Verificación APOYO
los procesos
• Gestión de la Configuración • Validación de apoyo
• Solución de Problemas • Revisión Conjunta
• Aseguramiento de la Calidad • Auditoría
Procesos Organizativos
* Infraestructura *Mejora de Procesos *Recursos Humanos
FIGURA C.1. – Procesos del ciclo de vida del software – roles y relaciones
PERUANA 91 de 189
5. PROCESOS PRINCIPALES DEL CICLO DE VIDA

6. PROCESOS
DE APOYO DEL
VISIÓN CONTRACTUAL CICLO DE VIDA
5.1 Proceso de Adquisición 6.1 Proceso de

Documentación
Preparación y Seguimiento
Preparación de la Aceptación y
Inicio actualización del
solicitud de propuestas del proveedor finalización
contrato
6.2 Gestión de la
Configuración
5.2 Proceso de Suministro

Preparación VISIÓN DE LA GESTIÓN
Ejecución y Revisión y Suministro y DE LA CALIDAD
Inicio de la Contrato Planificación
control evaluación finalización
respuesta 6.3 Proceso de
Aseguramiento
de la Calidad
VISIÓN DE LA INGENIERÍA VISIÓN OPERATIVA

6.4 Proceso de
5.3 Proceso de Desarrollo 5.4 Proceso de Operación Verificación
Apoyo a la
Implementación Instalación del Implementación Pruebas de
aceptación del
del proceso software del proceso operación
software
6.5 Proceso de
Validación
Operación del Soporte al
Analisis de los Diseño de la Pruebas de sistema usuario
Integración
requisitos del arquitectura
del sistema
calificación 6.6 Proceso de
sistema del sistema del sistema Revisión
Conjunta
5.5 Proceso de Mantenimiento
Analisis de Diseño de la Diseño Integración Pruebas de Analisis de
Implementación
los requisitos arquitectura detallado del del calificación problemas y 6.7 Proceso de
del software del software software software del software del proceso
moficaciones Auditoría
Implementación Revisión /
de las aceptación del
Codificación y mantenimient
pruebas del modificaciones
o 6.8 Proceso de
software
Solución de
Migración Retirada del
software Problemas
VISIÓN GESTORA 7.2 Proceso de 7.4 Proceso de Recursos

Infraestructura Humanos
7.1 Proceso de Gestión
Inicio y definición
Planificación
del alcance
7.3 Proceso de Mejora de Procesos
Ejecución y Revisión y
Terminación
control evaluación
Establecimiento Evaluación del Mejora del
del proceso proceso proceso
La posición de las actividades en la figura no implica orden temporal.

Los nombres de las actividades del Proceso de Desarrollo no son los nombres de las fases del desarrollo
FIGURA C.2 – Procesos del ciclo de vida del software - visiones y actividades
PERUANA 92 de 189
ANEXO D
(INFORMATIVO)
BIBLIOGRAFIA
NTP-ISO/IEC 12119:2005 - Tecnología de la Información. Paquetes software.

Requerimientos de calidad y pruebas.
PERUANA 93 de 189
ANEXO E
(INFORMATIVO)
E.1 Relaciones entre el propósito y los resultados para la ISO/IEC

12207:1995
La NTP- ISO/IEC 12207 documenta el conjunto de procesos de la ingeniería de software que

son fundamentales para una buena ingeniería de software y cubre las mejores prácticas. Los
procesos del ciclo de vida son descritos en el Anexo F en términos de lograr los propósitos y
resultados definidos; estas descripciones constituyen un modelo referencial, el cual describe
los procesos que una organización puede usar para adquirir, proveer, desarrollar, operar y
mantener un software. El modelo de referencia es también usado para proveer una base
común para diferentes modelos y métodos asegurando que la evaluación sea realizado en un
contexto común. La parte substantiva de la ISO/IEC 12207 precisa las actividades y tareas
requeridas para implementar a alto nivel los procesos del ciclo de vida para alcanzar las
capacidades deseadas para los adquirientes, proveedores, desarrolladores, responsables de
mantenimiento y operadores del sistema que contiene el software.
El Anexo F agrupa los propósitos y resultados en tres categorías del proceso del ciclo de vida
de la ISO/IEC 12207, por ejemplo: organizativos, apoyo y principales. Dentro de cada una de
las categorías los procesos son descritos en términos de una declaración de propósito, el cual
abarca únicamente los objetivos funcionales de un ambiente en particular. La declaración de
propósito incluye material adicional identificando las salidas de una implementación exitosa.
El anexo F no define cómo, o en qué orden, se lograrán los elementos de la declaración de

propósito. Los resultados serán alcanzados en una organización a través de varias prácticas
detalladas, siendo realizadas para producir productos intermedios. Estas prácticas realizadas y
las características de los productos intermedios producidos, son indicadores que demuestran si
los propósitos específicos están siendo logrados.
La estructura del anexo F y su relación con la NTP-ISO/IEC 12207, es graficada en la tabla E-

1. Para los propósitos y resultados que son “nuevos” para la ISO/IEC 12207, las descripciones
de sus actividades y/o tareas son proporcionadas en los nuevos apartados 6.9, 7.1.6 y 7.4 al
7.7. Las descripciones de las actividades y tareas en estos nuevos apartados están de acuerdo
con la estructura de procesos de la ISO/IEC 12207.
PERUANA 94 de 189
E.2 Propósitos y resultados
Los propósitos y resultados en el Anexo F están a un nivel apropiado de los procesos,

actividades o tareas, para alinearse con la estructura de procesos de la ISO/IEC 12207. La
definición de propósitos y salidas es proporcionada en el apartado 1.1.2 de esta enmienda.
E.3 Tipo de procesos
La tabla E.1 proporciona un mapeo detallado del contenido del anexo F a lo existente en la
Norma Técnica Peruana, NTP-ISO/IEC 12207, la fuente de información, la estructura del
contenido y tipo de contenido. La relación de la estructura de procesos del Anexo F a la
ISO/IEC 12207 está definido por tipos de proceso como sigue:
a) Básico – Estos procesos y sub-procesos son idénticos a las actividades y

proceso de la ISO/IEC 12207.
b) Nuevo – Estos procesos y sub-procesos son una expansión de la definición del

proceso de la ISO/IEC 12207
c) Extendido – Estos procesos y sub-procesos son ampliaciones de los procesos y

actividades existentes de la ISO/IEC 12207
d) Componente – Estos son agrupaciones de actividades existentes de la ISO/IEC

12207
PERUANA 95 de 189
TABLA E.1 – Correlación de la ISO/IEC 12207:1995 al anexo F
12207 12207 Procesos y Actividades Fuente de Anexo F Estructura de Proceso Anexo F Tipo de Proceso
5 Procesos principales del ciclo de vida

5.1 Proceso de adquisición ISO/IEC 12207 Proceso de Adquisición básico
ISO/IEC/TR 15504-2 Proceso de Abastecimiento componente
ISO/IEC/TR 15504-2 Proceso de Desarrollo componente
ISO/IEC/TR 15504-2 Proceso Operacional componente
ISO/IEC/TR 15504-2 Proceso de Mantenimiento componente
5.2 Proceso de suministro ISO/IEC 12207 Proceso de Abastecimiento básico
5.3 Proceso de desarrollo ISO/IEC 12207 Proceso de Desarrollo básico
5.3.1 Implementación del proceso
ISO/IEC/TR 15504-2 Obtención de Requisitos extendido
5.3.2 Análisis de los requisitos del sistema ISO/IEC 12207 Análisis de Requisitos del básico
Sistema
5.3.3 Diseño de la arquitectura del sistema ISO/IEC 12207 Diseño de la Arquitectura del básico
Sistema
5.3.4 Análisis de requisitos del software ISO/IEC 12207 Análisis de Requisitos del básico
Software
5.3.5 Diseño de la arquitectura software ISO/IEC/TR 15504-2 Diseño de Software componente
5.3.6 Diseño detallado del software ISO/IEC/TR 15504-2 Diseño de Software componente
5.3.7 Codificación y pruebas del software ISO/IEC/TR 15504-2 Construcción del Software componente
5.3.8 Integración del software ISO/IEC 12207 Integración del Software básico
5.3.9 Pruebas de calificación del software ISO/IEC/TR 15504-2 Prueba del Software componente
5.3.10 Integración del sistema ISO/IEC/TR 15504-2 Integración del Sistema componente
5.3.11 Pruebas de calificación del sistema ISO/IEC/TR 15504-2 Prueba del Sistema componente
5.3.12 Instalación del software ISO/IEC 12207 Instalación del Software básico
5.3.13 Apoyo en la aceptación del software ISO/IEC 12207 Proceso de Suministro básico
5.4 Proceso de operación ISO/IEC 12207 Proceso Operacional básico

ISO/IEC/TR 15504-2 Uso Operacional extendido
ISO/IEC/TR 15504-2 Apoyo al cliente extendido
5.5 Proceso de mantenimiento ISO/IEC 12207 Proceso de Mantenimiento básico
6 Procesos de apoyo del ciclo de vida
6.1 Proceso de documentación ISO/IEC 12207 Proceso de Documentación básico
6.2 Proceso de gestión de la configuración ISO/IEC 12207 Proceso de Gestión de básico
Configuración
6.3 Proceso de aseguramiento de la calidad ISO/IEC 12207 Proceso de Aseguramiento de básico
Calidad
6.4 Proceso de verificación ISO/IEC 12207 Proceso de Verificación básico
6.5 Proceso de validación ISO/IEC 12207 Proceso de Validación básico
6.6 Proceso de revisiones conjuntas ISO/IEC 12207 Proceso de Revisión Conjunta básico
6.7 Proceso de auditoría ISO/IEC 12207 Proceso de Auditoría básico
6.8 Proceso de solución de problemas ISO/IEC 12207 Proceso de Resolución de básico
problema
ISO 13407 Proceso de Usabilidad nuevo
ISO/IEC 14598 Proceso de Evaluación de extendido
producto
PERUANA 96 de 189
TABLA E.1 – (continuación)

7 Procesos de organizativos del ciclo de vida
7.1 Proceso de gestión ISO/IEC 12207 Proceso de Gestión básico
ISO/IEC/TR 15504-2 Alineamiento Organizativo extendido
ISO/IEC 12207 Gestión de la Organización básico
ISO/IEC/TR 15504-2 Gestión de Proyecto extendido
ISO/IEC/TR 15504-2 Gestión de la Calidad extendido
ISO/IEC/TR 15504-2 Gestión de Riesgos extendido
ISO/IEC 15939 Medición nuevo
7.2 Proceso de infraestructura ISO/IEC 12207 Proceso de Infraestructura básico
7.3 Procesos de mejora ISO/IEC 12207 Proceso de Mejora básico
7.3.1 Establecimiento del proceso ISO/IEC/TR 15504-2 Establecimiento del Proceso componente
7.3.2 Evaluación del proceso ISO/IEC/TR 15504-2 Proceso de Evaluación componente
7.3.3 Proceso de mejora ISO/IEC/TR 15504-2 Proceso de Mejora componente
7.4 Proceso de recursos humanos ISO/IEC/TR 15504-2 Proceso de Recursos Humanos nuevo
ISO/IEC/TR 15504-2 Gestión del Recurso Humano nuevo
ISO/IEC 12207 Entrenamiento básico
Gestión del Conocimiento nuevo
7.5 IEEE 1517 Proceso de Gestión del Recurso nuevo
7.6 IEEE 1517 Proceso de Gestión de Programa nuevo

de Reutilización
7.7 IEEE 1517 Proceso de Ingeniería de nuevo
Dominio
PERUANA 97 de 189
ANEXO F
(NORMATIVO)
PROPÓSITO Y RESULTADOS
El Anexo F proporciona un modelo de referencia del proceso y está caracterizado en

términos de propósitos y resultados de proceso, junto con una arquitectura que describe las
relaciones entre los procesos, que detallan los resultados previstos de la implementación de
este Anexo por una organización o un proyecto. El modelo de referencia del proceso es
aplicable a una organización que esté determinando los procesos necesarios para el éxito
del negocio y la mejora continua subsecuente de estos procesos.
El modelo de proceso no representa un acercamiento de un proceso particular de la

implementación ni prescribe una metodología, una técnica, o modelo del ciclo de vida del
sistema/software. En lugar de eso el modelo de referencia del proceso se crea para ser
adaptado por una organización basada en sus necesidades de negocio y dominio del uso. El
proceso definido de la organización es adoptado por los proyectos de la organización en el
contexto de los requerimientos del cliente.
Los propósitos y resultados del modelo de referencia son indicadores que demuestran si los
procesos de la organización se están alcanzando. Estos indicadores son útiles para planear
y determinar la capacidad del proceso implementado para la organización y proporcionar el
material necesario para el plan de mejoramiento del proceso organizativo. El modelo de
referencia se alinea fuertemente con la ISO/IEC 12207, proporciona expectativas de
proceso detalladas e incluye los procesos adicionales determinados como esenciales para
permitir un análisis confiable de las organizaciones de software.
NOTA Liberación de los derecho de autor: Los usuarios pueden reproducir libremente la
descripción detallada de los propósitos y resultados del proceso descrito en el presente anexo, como
parte de un Modelo de Evaluación basado en el Modelo de Referencia de Procesos, o como parte de
una demostración de compatibilidad con el Modelo de Referencia de Procesos; de esta manera, éste
puede ser usado para un propósito específico.
PERUANA 98 de 189
F.1 Procesos principales del ciclo de vida
F.1.1 Proceso de adquisición
Propósito:
El propósito del proceso de adquisición es obtener el producto y/o servicio que satisface la
necesidad expresada por el cliente. El proceso comienza con la identificación de una
necesidad del cliente y finaliza con la aceptación del producto y/o servicio necesitado por
el cliente.
NOTA: El Anexo H proporciona una extensión del proceso de adquisición que se puede utilizar en
lugar del proceso de adquisición proporcionado en el anexo F.
Resultados:
Como resultado de la implementación exitosa del proceso de adquisición:
1. Se definen las necesidades de adquisición, metas, criterios de aceptación del

producto y/o servicios y estrategias de adquisición;
2. Se desarrolla un acuerdo que exprese claramente la expectativa,

responsabilidades del cliente y del proveedor;
3. Se adquiere un producto y/o un servicio que satisface la necesidad

expresada por el cliente;
4. Se monitorea la adquisición, de modo que las restricciones tales como costo,

plazos y calidad son alcanzados;
5. Se aceptan los entregables del proveedor;
6. Se logra una culminación satisfactoria para elementos no claramente

especificado, según lo convenido entre el cliente y el proveedor.
NOTA: La enumeración de los resultados es solamente para la identificación y no implica prioridad

o secuencia.
PERUANA 99 de 189
El proceso de adquisición incluye propósitos y resultados para los sub-procesos siguientes:
- Preparación de la adquisición.
- Selección del proveedor.
- Supervisión del proveedor.
- Aceptación del cliente.
F.1.1.1 Preparación de la adquisición
Propósito:
El propósito de la preparación de la adquisición es establecer las necesidades y metas de la

adquisición y comunicar éstas a los proveedores potenciales.
Resultados:
Como resultado de la implementación exitosa de la preparación de la adquisición:
1. Se establece el concepto o necesidad para la adquisición, desarrollo o

mejoramiento;
2. Se definen y validan los requerimientos de adquisición establecidos por las

necesidades del proyecto;
3. Se definen y validan los requerimientos expresados por el cliente;
4. Se desarrolla una estrategia de adquisición; y
5. Se definen los criterios de selección del proveedor;

PERUANA 100 de 189
F.1.1.2 Selección del proveedor
Propósito:
El propósito de la selección del proveedor es elegir la organización que será responsable de

la entrega de los requerimientos del proyecto.
Resultados:
Como resultado de la implementación exitosa de la selección del proveedor:
1. Se establecen y utilizan los criterios de selección del proveedor para evaluar

proveedores potenciales;
2. Se selecciona el proveedor en base a la evaluación de sus ofertas,

capacidades de proceso y otros factores; y
3. Se establece y se negocia un acuerdo entre el cliente y el proveedor.
F.1.1.3 Supervisión del proveedor
Propósito:
El propósito de la supervisión del proveedor es seguir y evaluar el desempeño del

proveedor de acuerdo con los requerimientos acordados.
Resultados:
Como resultado de la implementación exitosa de la supervisión del proveedor:
1. Se ejecutan, según sea necesario, las actividades asociadas entre el cliente y

el proveedor;
PERUANA 101 de 189
2. Se intercambian regularmente con el proveedor, la información técnica

sobre el avance del proyecto;
3. Se supervisa el desempeño del proveedor de acuerdo con los requerimientos

acordados; y
4. Se negocian entre el adquiriente y el proveedor y se documentan en el

acuerdo, si es necesario, los cambios del acuerdo.
F.1.1.4 Aceptación del cliente
Propósito:
El propósito de la aceptación del cliente es aprobar el entregable del proveedor cuando

todos los criterios de aceptación son satisfechos.
Resultados:
Como resultado de la implementación exitosa de la aceptación del cliente:
1. Se evalúa el producto y/o servicio software entregado, con respecto al

acuerdo;
2. Se basa la aceptación de cliente, en el criterio de aceptación acordado; y
3. Se acepta, por parte del cliente, el producto y/o servicio de software.
F.1.2 Proceso de abastecimiento
Propósito:
El propósito del proceso de abastecimiento es proporcionar un producto o servicio al

cliente que reúne los requerimientos acordados.
PERUANA 102 de 189
Resultados:
Como resultado de la implementación exitosa del proceso de abastecimiento:
1. Se produce una respuesta a la petición del cliente;
2. Se establece un acuerdo entre el cliente y el proveedor para el desarrollo,

mantenimiento, operación, empaquetado, entrega, e instalación del producto y/o
servicio;
3. Se desarrolla, por parte del proveedor, un producto y/o servicio que cumple
con los requerimientos acordados;
4. Se entrega el producto y/o servicio al cliente de acuerdo con los

requerimientos acordados; y
5. Se instala el producto de acuerdo con los requerimientos establecidos.
El proceso de abastecimiento incluye los propósitos y resultados para los siguientes

subprocesos:
- Oferta del proveedor
- Acuerdo del contrato
- Entrega del producto
- Soporte de aceptación del producto
F.1.2.1 Oferta del proveedor
Propósito:
El propósito del proceso de oferta del proveedor es establecer un procedimiento para

responder a las preguntas y solicitudes para las propuestas del cliente, preparar y enviar las
propuestas y confirmarlas a través del establecimiento de un contrato o acuerdo pertinente.
PERUANA 103 de 189
Resultados:
Como resultado de la implementación exitosa de la oferta del proveedor:
1. Se establece y mantiene un medio de comunicación para responder a las

preguntas y solicitudes;
2. Se evalúan las solicitudes del cliente sobre las propuestas según criterios
definidos para determinar si se presenta o no una propuesta;
3. Se determina la necesidad de realizar estudios preliminares o estudios de

viabilidad;
4. Se identifican los recursos adecuados para realizar el trabajo propuesto;
5. Se prepara una propuesta y se presenta en respuesta a la solicitud del cliente;

y
6. Se obtiene la confirmación formal del acuerdo.
F.1.2.2 Acuerdo del contrato
Propósito:
El propósito de este proceso, de acuerdo con el contrato, es negociar y aprobar un contrato

o acuerdo que claramente y sin ambigüedad, especifica las expectativas, las
responsabilidades, los productos o entregables y las obligaciones de ambos, proveedor(es)
y adquiriente.
Resultados:
Como resultado de la implementación exitosa del acuerdo del contrato:
1. Se negocia, revisa, acepta y otorga al proveedor(es) un contrato o acuerdo;

PERUANA 104 de 189
2. Se revisan y consideran para su inclusión en el contrato, los mecanismos

para supervisar la capacidad y desempeño del proveedor(es) y para la mitigación de
los riesgos identificados;
3. Se notifica el resultado de la selección de las propuestas/ofertas a los

ofertantes; y
4. Se obtiene la confirmación formal del acuerdo.
F.1.2.3 Entrega del producto
Propósito:
El propósito del proceso de entrega del producto es controlar la disponibilidad de un

producto para un cliente previsto.
Resultados:
Como resultado de la implementación exitosa de la entrega del producto:
1. Se determinan los contenidos de la versión del producto;
2. Se ensambla la versión del producto a partir de los ítems configurados;
3. Se define y se produce la documentación de la versión;
4. Se determina el mecanismo y el medio de entrega de la versión;
5. Se efectúa la aprobación de la versión de acuerdo con los criterios de

aceptación definidos;
6. Se pone a disposición de un cliente la versión del producto; y
7. Se obtiene la confirmación de la versión.

PERUANA 105 de 189
F.1.2.4 Soporte de aceptación del producto
Propósito:
El propósito del proceso de soporte de aceptación del producto es lograr que el cliente
confie que el producto cumple con los requerimientos.
Resultados:
Como resultado de la implantación exitosa del proceso de soporte a la aceptación de

producto:
1. Se termina y entrega el producto al cliente;
2. Se conducen las pruebas de aceptación y las revisiones del cliente;
3. Se pone el producto en operación, en el ambiente del cliente; y
4. Se identifican y comunican los problemas descubiertos durante la

aceptación a los responsables para su resolución.
NOTA: La entrega incremental podrían ser en incrementos completos.
F.1.3 Proceso de desarrollo
Propósito:
El propósito del proceso de desarrollo es transformar un conjunto de requerimientos en un

producto software o en un sistema basado en software de acuerdo con las necesidades
expresadas por el cliente. Las actividades del proceso de desarrollo se componen de roles
del desarrollador de sistemas y del desarrollador de software.
PERUANA 106 de 189
Resultados:
Como resultado de la implementación exitosa del proceso de desarrollo:
1. Se reúnen y acuerdan los requerimientos para el desarrollo del software;
2. Se desarrolla un producto de software o un sistema basado en software;
3. Se desarrolla el producto de trabajo intermedio que demuestra que el

producto final está basado en los requerimientos;
4. Se establece la consistencia entre los productos del proceso de desarrollo;
5. Se optimizan los factores de calidad del sistema de acuerdo con los

requerimientos del sistema, por ejemplo costo del desarrollo, utilidad, etc.;
6. Se proporciona la evidencia (por ejemplo: evidencias de pruebas) que

demuestra que el producto final reúne los requerimientos; y
7. Se instala el producto final de acuerdo con los requerimientos acordados.
El proceso del desarrollo incluye propósitos y los resultados para los sub-procesos
siguientes:
− Obtención de requerimientos.
− Análisis de requerimientos del sistema.
− Diseño de la arquitectura del sistema.
− Análisis de requerimientos del software.
− Diseño del software.
− Construcción del software (código y prueba de unidad).
− Integración del software.
− Prueba del software.

PERUANA 107 de 189
− Integración del sistema.
− Prueba del sistema.
− Instalación del software.
F.1.3.1 Obtención de requerimientos
Propósito:
El propósito de la obtención de requerimientos es recolectar, procesar y seguir la evolución de

las necesidades y requerimientos del cliente a través de la vida del producto y/o del servicio
para establecer una línea base de los requerimientos, que sirvan como base para definir los
productos intermedios necesarios. La obtención de requerimientos se puede realizar por el
adquiriente o el desarrollador del sistema.
Resultados:
Como resultado de la implementación exitosa de la obtención de requerimientos:
1. Se establece la continua comunicación con el cliente;
2. Se definen y establecen como línea base los requerimientos convenidos con

el cliente;
3. Se establece un mecanismo de cambios para evaluar e incorporar cambios a

los requerimientos del cliente, requerimientos basados en las necesidades cambiantes
del cliente;
4. Se establece un mecanismo para el control continuo de las necesidades del

cliente.
5. Se establece un mecanismo para asegurar que los clientes pueden

determinar fácilmente el estado y la disposición de sus requerimientos; y
6. Se identifica y administra el impacto de las mejoras que se presentan por

cambios en la tecnología y necesidades del cliente.
PERUANA 108 de 189
F.1.3.2 Análisis de requerimientos del sistema
Propósito:
El propósito del análisis de requerimientos del sistema es transformar los requerimientos

definidos por los involucrados, en un conjunto de requerimientos técnicos del sistema que
dirigirán el diseño del mismo.
Resultados:
Como resultado de la implementación exitosa del análisis de los requerimientos del

sistema:
1. Se establece el conjunto definido de requerimientos funcionales y no

funcionales del sistema, que describe el problema que será resuelto;
2. Se utilizan las técnicas apropiadas para optimizar la preferible solución del

proyecto;
3. Se analizan los requerimientos del sistema para la corrección y prueba;
4. Se entiende el impacto de los requerimientos del sistema en el ambiente

operacional;
5. Se priorizan, aprueban y actualizan los requerimientos, según lo necesitado;
6. Se establece la consistencia y trazabilidad entre los requerimientos del

sistema y las líneas base de los requerimientos del cliente;
7. Se evalúa el costo, los plazos y el impacto técnico de los cambios a las

líneas base; y
8. Se comunican los requerimientos del sistema a todas las partes involucradas

y se establecen como línea base.
PERUANA 109 de 189
F.1.3.3 Diseño de la arquitectura del sistema
Propósito:
El propósito del diseño de al arquitectura del sistema es identificar qué requerimientos del
sistema deben ser asignados a cada elemento del sistema.
Resultados:
Como resultado de la implementación exitosa del diseño de la arquitectura del sistema:
1. Se define un diseño de la arquitectura del sistema que identifica los

elementos del sistema y reúne los requerimientos definidos;
2. Se tratan los requerimientos funcionales y no funcionales del sistema;
3. Se asignan los requerimientos a los elementos del sistema;
4. Se definen las interfaces internas y externas de cada elemento del sistema;
5. Se realiza la verificación entre los requerimientos del sistema y la

arquitectura del sistema;
6. Se contrastan los requerimientos asignados a los elementos del sistema y sus

interfaces con los requerimientos del cliente;
7. Se mantiene la consistencia y trazabilidad entre los requerimientos del

sistema y el diseño de la arquitectura de sistema; y
8. Se comunican los requerimientos del sistema, el diseño de la arquitectura de

sistema y sus relaciones a todas las partes involucradas.
PERUANA 110 de 189
F.1.3.4 Análisis de requerimientos del software
Propósito
El propósito de análisis de requerimientos de software es establecer los requerimientos de

los elementos del software del sistema.
Resultados:
Como resultado de la implementación exitosa del análisis de requerimientos de software:
1. Se definen los requerimientos asignados a los elementos del software del

sistema y sus interfaces;
2. Se analizan los requerimientos del software para asegurar corrección y

testeabilidad;
3. Se entiende el impacto de requerimientos del software en el ambiente
operativo;
4. Se establece la consistencia y correspondencia entre los requerimientos del

software y los del sistema;
5. Se define la priorización para implementar los requerimientos del software;
6. Se aprueban y actualizan los requerimientos del software , de acuerdo con lo

necesitado;
7. Se evalúan los cambios de los requerimientos del software por costo, plazo
y el impacto técnico; y
8. Se establecen los requerimientos del software como líneas base y se

comunica a todas las partes afectadas.
PERUANA 111 de 189
F.1.3.5 Diseño del software
Propósito:
El propósito del diseño del software es proporcionar un diseño que implemente el software
y pueda ser verificado contra los requerimientos.
Resultados:
Como resultado de la implementación exitosa de diseño del software:
1. Se desarrolla, cumpliendo con la línea base, el diseño de arquitectura

software que describe los elementos software que implementan los requerimientos;
2. Se definen interfaces internas y externas para cada elemento del software;
3. Se desarrolla un diseño detallado que describe las unidades del software

que se pueden construir y probar; y
4. Se establecen la consistencia y correspondencia entre los requerimientos del

software y el diseño del software.
F.1.3.6 Construcción del software
Propósito:
El propósito de la construcción del software es producir unidades de software ejecutables

que apropiadamente reflejen el diseño del software.
Resultados:
Como resultado de la implementación exitosa de la construcción del software:

PERUANA 112 de 189
1. Se definen los criterios de verificación para todas las unidades del software
de acuerdo con sus requerimientos;
2. Se producen unidades del software definidas por el diseño;
3. Se establece la consistencia y correspondencia entre los requerimientos del

software, diseño y unidades del software; y
4. Se realiza la comprobación de las unidades del software contra los

requerimientos y el diseño.
F.1.3.7 Integración del software
Propósito:
El propósito de integración del software es combinar las unidades del software,

produciendo los elementos del software integrados, consistentes con el diseño del software,
eso demuestra que los requerimientos funcionales y no-funcionales están satisfechos en
una equivalente o completa plataforma operacional.
Resultados:
Como resultado de la implementación exitosa de la integración del software:
1. Se desarrolla una estrategia de la integración para las unidades de software

consistentes con el diseño del mismo y la priorización de los requerimientos del
software;
2. Se desarrollan los criterios de verificación de los elementos del software

para asegurar el cumplimiento con los requerimientos del software asignado a los
elementos;
3. Se verifican los elementos del software usando los criterios definidos;
4. Se producen los elementos del software definidos por la estrategia de

integración;
PERUANA 113 de 189
5. Se registran los resultados de las pruebas de integración;
6. Se establece la consistencia y correspondencia entre el diseño del software y

elementos del software; y
7. Se desarrolla y aplica una estrategia de regresión para re-verificar los

elementos del software cuando ocurre un cambio en las unidades del software
(incluyendo los requerimientos, diseño y código asociados).
F.1.3.8 Prueba del software
Propósito:
El propósito de la prueba del software es confirmar que el producto de software integrado

reúne los requerimientos definidos.
Resultados:
Como resultado de la implementación exitosa de las pruebas del software:
1. Se desarrollan los criterios para la integración del software que demuestra el

cumplimiento con los requerimientos del software;
2. Se verifica la integración del software usando los criterios definidos;
3. Se registran los resultados de la prueba; y
4. Se desarrolla la estrategia de regresión para reaplicar las pruebas al software

integrado cuando se produce un cambio en los elementos del software.
PERUANA 114 de 189
F.1.3.9 Integración del sistema
Propósito:
El propósito de la integración del sistema es integrar los elementos del sistema (incluyendo
los elementos del software, hardware, las operaciones manuales y otros sistemas,
necesarios) para producir un sistema completo que satisface el diseño del sistema y las
expectativas de los clientes que se expresaron en los requerimientos del sistema.
Resultados:
Como resultado de la implementación exitosa de la integración del sistema:
1. Se desarrolla una estrategia para integrar el sistema de acuerdo con las

prioridades de los requerimientos del sistema;
2. Se desarrollan los criterios para verificar la conformidad con los

requerimientos del sistema asignados a sus elementos, incluyendo a las interfaces
entre los elementos del sistema;
3. Se verifica la integración del sistema usando los criterios definidos;
4. Se desarrolla la estrategia de regresión para reaplicar las pruebas al sistema

cuando los cambios son realizados;
5. Se establece la consistencia y correspondencia entre el diseño del sistema y

los elementos del sistema integrado; y
6. Se construye un sistema integrado que cumple con el diseño del sistema y se

valida que exista el conjunto completo de los elementos entregables del sistema.
PERUANA 115 de 189
F.1.3.10 Prueba del sistema
Propósito:
El propósito de la prueba del sistema es asegurar que la implementación de cada

requerimiento del sistema es aprobada para confirmar que el sistema está listo para su
entrega.
Resultados:
Como resultado de la implementación exitosa de la prueba del sistema:
1. Se desarrollan los criterios para la integración del sistema, que demuestre el

cumplimiento con los requerimientos del sistema;
2. Se verifica la integración del sistema usando los criterios definidos;
3. Se registran los resultados de la prueba; y
4. Se desarrolla la estrategia de regresión para reaplicar las pruebas que

deberán hacerse al sistema integrado cuando se producen cambios en los elementos
del sistema.
F.1.3.11 Instalación del software
Propósito:
El propósito de la instalación del software es instalar el producto del software que reúne
los requerimientos convenidos en el ambiente designado.
Resultados:
Como resultado de la implementación exitosa de la instalación del software:

PERUANA 116 de 189
1. Se desarrolla una estrategia de instalación de software;
2. Se desarrollan los criterios de instalación del software para demostrar el

cumplimiento con los requerimientos de instalación del software;
3. Se instala el producto software en el ambiente designado; y
4. Se asegura que el producto del software está listo para el uso en su ambiente
proyectado.
F.1.4 Proceso operacional
Propósito:
El propósito del proceso operacional es operar el producto del software en su ambiente

proyectado y proporcionar el apoyo a los clientes del producto del software.
Resultados:
Como resultado de la implementación exitosa del proceso operacional:
1. Se identifican y evalúan las condiciones para el funcionamiento correcto del

software en su ambiente intencional;
2. Se opera el software en su ambiente proyectado; y
3. Se proporciona la asistencia y consultoría a los clientes del producto de

software en cumplimiento con el acuerdo respectivo.
El proceso operacional incluye el propósito y resultado para los sub-procesos siguientes:
− El uso operacional.
− Apoyo al cliente.
PERUANA 117 de 189
F.1.4.1 Uso operacional
Propósito:
El propósito de uso operacional es asegurar el funcionamiento correcto y eficiente del

producto durante su uso proyectado y en el ambiente instalado.
Resultados:
Como resultado de la implementación exitosa del uso operacional:
1. Se identifica y se supervisa los riesgos operacionales para la introducción y

funcionamiento del producto;
2. Se opera el producto en su ambiente proyectado de acuerdo con los

requerimientos; y
3. Se desarrollan los criterios para el uso operacional que demuestra el

cumplimiento con los requerimientos acordados.
F.1.4.2 Apoyo al cliente
Propósito:
El propósito de apoyo al cliente es establecer y mantener un nivel aceptable de servicio a

través de la asistencia y consultoría al cliente para apoyarlo en el uso eficaz del producto.
Resultados:
Como resultado de la implementación exitosa de apoyo al cliente:

PERUANA 118 de 189
1. Se identifican y supervisan en forma continua las necesidades de servicio

para el apoyo al cliente;
2. Se evalúa en forma continua la satisfacción del cliente tanto con, los

servicios de apoyo proporcionados, como el producto mismo;
3. Se proporciona el apoyo operacional atendiendo las preguntas y demandas

del cliente y resolviendo los problemas operacionales; y
4. Se satisfacen las necesidades de apoyo de cliente a través de la prestación de

servicios apropiados.
F.1.5 Proceso de mantenimiento
Propósito:
El propósito del proceso de mantenimiento es modificar un producto del sistema/software

después de la entrega, para corregir las fallas, mejorar el rendimiento u otros atributos, o
adaptarlo a los cambios del entorno.
NOTA: El objetivo es modificar y/o retirar productos existentes del sistema/software en tanto se
conserve la integridad de las operaciones de la organización.
Resultados:
Como resultado de la implementación exitosa del proceso de mantenimiento:
1. Se desarrolla una estrategia de mantenimiento para manejar la modificación,

migración y retiro de productos de acuerdo con la estrategia de release;
2. Se identifica el impacto de los cambios en la organización, funcionamientos

o interfaces del sistema existente;
3. Se actualiza la documentación del software del sistema/software afectado

según sea necesario;
PERUANA 119 de 189
4. Se desarrollan los productos modificados con pruebas asociadas que

demuestren que los requerimientos no son los acordados;
5. Se migran las actualizaciones del producto al ambiente del cliente;
6. Se retiran los productos de su uso, a solicitud, de una manera controlada que

minimiza la perturbación a los clientes; y
7. Se comunica la modificación del sistema/software a todas las partes

afectadas.
F.2 Procesos de apoyo al ciclo de vida
F.2.1 Proceso de documentación
Propósito:
El propósito del proceso de documentación es desarrollar y mantener registrada la

información del software, producida por un proceso.
Resultados:
Como resultado de la implementación exitosa del proceso de la documentación:
1. Se desarrolla una estrategia que identifica la documentación a ser producida

durante el ciclo de vida del producto o servicio software;
2. Se identifican las normas a ser aplicadas para el desarrollo de la

documentación del software;
3. Se identifica la documentación a ser producida por el proceso o el proyecto;
4. Se especifican, revisan y aprueban el contenido y propósito de toda la

documentación;
PERUANA 120 de 189
5. Se desarrolla y se pone a disposición la documentación de acuerdo con las

normas identificadas; y
6. Se actualiza la documentación de acuerdo con los criterios definidos.
F.2.2 Proceso de gestión de configuración
Propósito:
El propósito del proceso de gestión de configuración es establecer y mantener la integridad

de los productos o ítems de un proceso o proyecto y hacerlos disponibles a las partes
interesadas.
Resultados:
Como resultado de la implementación exitosa del proceso de gestión de configuración:
1. Se desarrolla una estrategia de gestión de configuración;
2. Se identifican, definen y establecen la línea base de los productos o ítems

generados por el proceso o proyecto;
3. Se controlan las modificaciones y versiones de los productos o ítems;
4. Se pone a disposición de las partes afectadas las modificaciones y versiones;
5. Se registran e informan el estado de los productos o ítems y las

modificaciones;
6. Se asegura la completitud y consistencia de los productos o ítems; y
7. Se controla el almacenamiento, manejo y entrega de los productos o ítems.

PERUANA 121 de 189
F.2.3 Proceso de aseguramiento de la calidad
Propósito:
El propósito del proceso de aseguramiento de la calidad es proporcionar la seguridad de

que los productos y procesos cumplen con las previsiones y planes previstos.
Resultados:
Como resultado de la implementación exitosa del proceso de aseguramiento de la calidad:
1. Se desarrolla una estrategia para asegurar la calidad;
2. Se produce y se mantiene la evidencia del aseguramiento de calidad;
3. Se identifican y registran los problemas y/o las no-conformidades con los

requerimientos acordados; y
4. Se verifica la adhesión a las normas, procedimientos y requerimientos

acordados de los procesos, productos y actividades.
F.2.4 Proceso de verificación
Propósito:
El propósito del proceso de verificación es confirmar que cada producto y/o servicio
software de un proceso o proyecto refleja propiamente los requerimientos especificados.
Resultados:
Como resultado de la implementación exitosa del proceso de verificación:

PERUANA 122 de 189
1. Se desarrolla y se lleva a cabo una estrategia de verificación;
2. Se identifican los criterios para la verificación de todos los productos

software intermedios requeridos;
3. Se ejecutan las actividades de verificación requeridas;
4. Se identifican y se registran los defectos; y
5. Se pone a disposición del cliente y de las otras partes involucradas los

resultados de las actividades de verificación.
F.2.5 Proceso de validación
Propósito:
El propósito del proceso de validación es confirmar que los requerimientos para un uso
específico del producto son completamente cumplidos.
Resultados:
Como resultado de la implementación exitosa del proceso de validación:
1. Se desarrolla y se lleva a cabo una estrategia de validación;
2. Se identifican los criterios para la validación de todos los productos

requeridos;
3. Se ejecutan las actividades de validación requeridas;
4. Se identifican y se registran los problemas;
5. Se evidencia que los productos de software como fueron desarrollados son

apropiados para su uso previsto; y
6. Se pone a disposición del cliente y de las otras partes involucradas los

resultados de las actividades de validación.
PERUANA 123 de 189
F.2.6 Proceso de revisión conjunta
Propósito:
El propósito del proceso de revisión conjunta es mantener una comprensión común con los
involucrados del proceso contra los objetivos del acuerdo y lo que deberá hacerse para
ayudar a asegurar el desarrollo de un producto que satisface a los involucrados. Las
revisiones conjuntas están en los niveles de gestión del proyecto y técnicos y se sostienen a
lo largo de la vida del proyecto.
Resultados:
Como resultado de la implementación exitosa del proceso de revisión conjunta:
1. Se ejecutan la gestión y las revisiones técnicas basándose en las

necesidades del proyecto;
2. Se evalúan el estado y productos de una actividad de un proceso a través de

las actividades de revisión conjunta entre los involucrados;
3. Se ponen en conocimiento a todas las partes afectadas, los resultados de la

revisión;
4. Se rastrean, antes del cierre, los elementos de acción resultantes de las
revisiones; y
5. Se identifican y se registran los problemas.
F.2.7 Proceso de auditoría
Propósito:
El propósito del proceso de auditoría es determinar, independientemente la conformidad de

los productos seleccionados y procesos con los requerimientos, planes y acuerdos.
PERUANA 124 de 189
Resultados:
Como resultado de la implementación exitosa del proceso de auditoría:
1. Se desarrolla y se lleva a cabo una estrategia de auditoría;
2. Se determina la conformidad de productos y/o servicios o procesos de

trabajo de software seleccionados con los requerimientos, planes y acuerdos según la
estrategia de la auditoría;
3. Se realiza la conducción de la auditoría por una parte independiente

apropiada; y
4. Se identifican problemas descubiertos durante una auditoría y se comunican

a los responsables para la resolución y acción correctiva.
F.2.8 Proceso de gestión de solución de problemas
Propósito:
El propósito del proceso de gestión de solución de problemas es asegurar que todos los
problemas descubiertos son identificados, analizados, gestionados y controlados para su
solución.
Resultados:
Como resultado de la implementación exitosa del proceso de gestión de solución de

problemas:
1. Se desarrolla una estrategia de gestión de problemas;
2. Se registran, identifican y clasifican los problemas;
3. Se analizan y evalúan los problemas para identificar soluciones aceptables;

PERUANA 125 de 189
4. Se implementa la solución del problema;
5. Se hace el seguimiento del problema hasta su cierre; y
6. Se da a conocer el estado de todos los problemas reportados.
NOTA: La gestión de solución de problemas puede iniciar una solicitud de camb io.
F.2.9 Proceso de usabilidad
Propósito:
El propósito del proceso de usabilidad es asegurar la consideración de los intereses y

necesidades de los involucrados para optimizar el apoyo y entrenamiento, incrementar la
productividad y calidad de trabajo, mejorando las condiciones del trabajo humano y
reduciendo el rechazo del usuario al sistema.
Resultados:
Como resultado de la implementación exitosa del proceso de usabilidad:
1. Se satisface, con el sistema, las necesidades de los usuarios tomando en

cuenta sus capacidades y limitaciones;
2. Se incorporan al diseño del sistema, los factores humanos, conocimiento y

técnicas de ergonomía;
3. Se identifican y ejecutan las actividades de diseño orientadas a las personas;
4. Se reportan, en el diseño del sistema, posibles efectos adversos de uso en la

salud humana, seguridad y rendimiento; y
5. Se habrán reforzado, con el sistema, la efectividad, eficacia y satisfacción

del usuario.
PERUANA 126 de 189
F.2.10 Proceso de evaluación del producto
Propósito:
El propósito del proceso de evaluación del producto es asegurar a través de exámenes y

mediciones sistemáticas que un producto satisface las necesidades declaradas e implicadas
de los usuarios de ese producto.
Resultados:
Como resultado de la implementación exitosa de este proceso de evaluación de producto:
1. Se establecen los requerimientos para la evaluación;
2. Se identifican los criterios para la evaluación del producto;
3. Se definen los métodos a ser empleados para la evaluación y se identifican y

ejecutan las actividades necesarias;
4. Se reúnen las medidas y se contrastan los resultados con los criterios

definidos; y
5. Se ponen a disposición de las partes interesadas, los resultados de las

actividades de evaluación del producto.
Nota: los requerimientos para realizar las evaluaciones del producto se encuentran en la ISO/IEC
14598; evaluación de producto de software. Las evaluaciones pueden ser realizadas por el
adquiriente, el desarrollador, o un tercero evaluador.
F.2.11 Proceso de gestión de solicitudes de cambios
Propósito:
El propósito del proceso de gestión de solicitudes de cambios es asegurar que las

solicitudes de cambios son gestionadas, monitoreadas y controladas.
PERUANA 127 de 189
Resultados:
Como resultado de la implementación exitosa de este proceso de gestión de solicitudes de

cambios:
1. Se desarrolla una estrategia de gestión de cambios;
2. Se registran e identifican las solicitudes de cambios;
3. Se identifican las dependencias y relaciones con otras solicitudes de

cambios;
4. Se definen los criterios para confirmar la implementación de las solicitudes

de cambios;
5. Se aprueban, priorizan y estiman los requerimientos de recursos de las

solicitudes de cambios;
6. Son inician los cambios sobre la base de prioridades y disponibilidad de

recursos;
7. Se implementan y monitorean los cambios aprobados hasta la finalización; y
8. Se da a conocer el estado de todas las solicitudes de cambios.
F.3 PROCESOS ORGANIZATIVOS DEL CICLO DE VIDA
F.3.1 Proceso de gestión
Propósito:
El propósito del proceso de gestión es organizar, supervisar y controlar la iniciación y

actuación de cualquier proceso para lograr sus metas de acuerdo con las metas comerciales de
la organización. El proceso de gestión se establece por una organización para asegurar la
aplicación consistente de prácticas para el uso por la organización y los proyectos. Mientras
estas prácticas son inherentes a la gestión de una organización, éstas son pensadas para ser
instanciadas para el uso de cada uno de los proyectos de las organizaciones.
PERUANA 128 de 189
Resultados:
Como resultado de la implementación exitosa del proceso de gestión:
1. Se define el alcance de la actividad y proceso a ser administrados;
2. Se identifican las actividades y tareas que se deben realizar para lograr el

propósito del proceso;
3. Se evalúa la viabilidad de lograr las metas del proceso con los recursos
disponibles y las restricciones;
4. Se establecen los recursos e infraestructura requeridas para realizar las

actividades y tareas identificadas;
5. Se identifican las actividades y se llevan a cabo las tareas;
6. Se supervisa el desempeño de las actividades y tareas definidas;
7. Se revisan los productos intermedios de las actividades del proceso y los

resultados se analizan y evalúan;
8. Se toma acción para modificar el rendimiento del proceso cuando el

desempeño se desvía de las actividades identificadas y tareas o no logra sus metas; y
9. Se demuestra el logro exitoso del propósito del proceso.
El proceso de gestión incluye propósitos y resultados para los sub-procesos siguientes:
− Alineamiento organizativo.
− Gestión de la organización.
− Gestión de proyecto.
− Gestión de la calidad.
− Gestión de riesgos.
PERUANA 129 de 189
− Medición
F.3.1.1 Alineamiento organizativo
Propósito:
El propósito de alineamiento organizativo es habilitar los procesos del software

necesitados por la organización para proporcionar productos y servicios software que sean
consistentes con sus metas comerciales.
Resultados:
Como resultado de la implementación exitosa del alineamiento organizativo:
1. Se identifican las metas comerciales de la organización;
2. Se identifica el marco del proceso y se define el conjunto de procesos del

software necesarios para lograr las metas del negocio de la organización;
3. Se define una estrategia para la definición, implementación y mejora del

proceso;
4. Se proporciona el apoyo para habilitar esta estrategia;
5. Se ponen en conocimiento de todos los empleados la misión, visión, valores,

metas y objetivos de la organización;
6. Se logra un funcionamiento eficaz debido a que los individuos en la

organización comparten una visión, cultura y comprensión común de las metas del
negocio;
7. Cada miembro de la organización entiende su rol, de manera que pueda

alcanzar las metas del negocio y esté apto para realizar dicho rol.
PERUANA 130 de 189
F.3.1.2 Gestión de la organización
Propósito:
El propósito de la gestión de la organización es establecer y realizar la práctica de la

gestión del software, durante la ejecución de los procesos necesarios para proporcionar los
productos y servicios del software que son consistentes con las metas comerciales de la
organización.
NOTA: A pesar de que las operaciones de la organización en general tienen un alcance mucho mayor
que del proceso de software, estos se llevan a cabo en un contexto y su eficiencia requiere un
ambiente apropiado.
Resultados:
Como resultado de la implementación exitosa de la gestión de la organización:
1. Se invierte, por la organización, en la infraestructura de gestión apropiada;
2. Se identifican las mejores prácticas para apoyar en la implementación de

una organización y gestión del proyecto efectivas; y
3. Se establecen las bases para evaluar el logro de las metas comerciales de la

organización utilizando en las prácticas de gestión.
F.3.1.3 Gestión de proyecto
Propósito:
El propósito de la gestión de proyecto es identificar, establecer, coordinar y supervisar las

actividades, tareas y recursos necesarios para un proyecto para producir un producto y/o
servicio en el contexto de los requerimientos del proyecto y sus restricciones.
PERUANA 131 de 189
Resultados:
Como resultado de la implementación exitosa de gestión de proyecto:
1. Se define el alcance del trabajo para el proyecto;
2. Se evalúa la viabilidad de lograr las metas del proyecto con los recursos
disponibles y las restricciones;
3. Se miden y estiman las tareas y recursos necesarios para completar el

trabajo;
4. Se identifican y supervisan las interfaces entre los elementos del proyecto,

con otro proyecto y las unidades organizativas;
5. Se desarrollan e implementan los planes para la ejecución del proyecto;
6. Se supervisa e informa el progreso del proyecto; y
7. Se toman decisiones para corregir las desviaciones del plan y para prevenir
la repetición de problemas identificados en el proyecto, cuando los objetivos del
proyecto no son alcanzados.
F.3.1.4 Gestión de la calidad
Propósito:
El propósito de la gestión de la calidad es lograr la satisfacción del cliente supervisando la

calidad de los productos y servicios, en el nivel organizativo y del proyecto para asegurar
que reúnen los requerimientos del cliente.
Resultados:
Como resultado de la implementación exitosa de la gestión de calidad:

PERUANA 132 de 189
1. Se establece las metas de calidad en base a los requerimientos de calidad

establecidos e implícitos del cliente;
2. Se desarrolla una estrategia global para lograr las metas definidas;
3. Se establece un sistema de gestión de calidad para llevar a cabo la estrategia;
4. Se realiza y confirma la ejecución del control de calidad y de las actividades

de aseguramiento de la calidad identificadas;
5. Se supervisa el desempeño actual contra las metas de calidad; y
6. Se toma la acción apropiada, cuando no se logran las metas de calidad.
F.3.1.5 Gestión de riesgos
Propósito:
El propósito del proceso de gestión de riesgos es identificar, analizar, tratar y monitorear

los riesgos continuamente.
Resultados:
Como resultado de la implementación exitosa de la gestión de riesgos:
1. Se determina el alcance de la gestión de riesgos a ser ejecutado;
2. Se definen e implementan estrategias apropiadas de gestión de riesgos;
3. Se identifican los riesgos en la planificación de proyectos como ellos se

desarrollan y durante la conducción del proyecto;
4. Se analizan los riesgos en términos de probabilidades y consecuencias y se

determina la prioridad en el tratamiento de estos riesgos;
5. Se definen, aplican y evalúan las mediciones de riesgo para determinar los

cambios en el estado del riesgo y el progreso de las actividades de tratamiento; y
PERUANA 133 de 189
6. Se sigue el tratamiento apropiado para corregir o evitar el impacto del riesgo

basados en su prioridad, probabilidad y consecuencia u otros principios de riesgo
definido.
F.3.1.6 Medición
Propósito:
El propósito de la medición es recopilar y analizar datos que relacionan a los productos

desarrollados y procesos implementados en la organización y sus proyectos para apoyar la
gestión efectiva de los procesos y demostrar objetivamente la calidad de los productos.
Resultados:
Como resultado de la implementación exitosa de la medición:
1. Se establece y mantiene el compromiso organizativo para implementar el

proceso de medición;
2. Se identifican las necesidades de información de medición y los procesos de

gestión;
3. Se identifica y desarrolla un conjunto apropiado de medidas de acuerdo con

la necesidad de información;
4. Se identifican y ejecutan las actividades de medición;
5. Se recopilan, almacenan y analizan los datos requeridos y se interpretan los

resultados;
6. Se usan los productos de información para apoyar a las decisiones y proveer

una base objetiva de comunicación; y
7. Se evalúa el proceso de medición y las medidas y se comunican al dueño del

proceso.
PERUANA 134 de 189
F.3.2 Proceso de infraestructura
Propósito:
El propósito del proceso de infraestructura es mantener una infraestructura estable y

confiable que se necesita para apoyar la ejecución de cualquier otro proceso.
Resultados:
Como resultado de la implementación exitosa del proceso de la infraestructura:
1. Se definen los requerimientos de infraestructura para apoyar los procesos en

la unidad organizacional;
2. Se identifican y especifican los elementos de la infraestructura;
3. Se adquieren los elementos de la infraestructura;
4. Se implementan los elementos de la infraestructura; y
5. Se mantiene una infraestructura estable y fiable.
NOTA: La infraestructura puede incluir hardware, software, métodos, herramientas, técnicas,

estándares y facilidades para el desarrollo, operación o mantenimiento.
F.3.3 Mejora de proceso de mejora
Propósito:
El propósito del proceso de mejora de proceso es establecer, evaluar, medir, controlar y

mejorar el proceso del ciclo de vida del software.
PERUANA 135 de 189
Resultados:
Como resultado de la implementación exitosa del proceso de mejora de proceso:
1. Se desarrolla y pone a disposición un conjunto de ventajas del proceso

organizativo;
2. Se evalúa periódicamente la capacidad del proceso de la organización para

determinar hasta qué punto de la implementación del proceso es eficaz para lograr las
metas de la organización; y
3. Se mejoran continuamente la efectividad y eficacia de los procesos de la

organización con respecto al logro de las metas del negocio.
El proceso de mejora de proceso contiene propósito y resultados para los siguientes sub-
procesos:
− Establecimiento del proceso.
− Proceso de evaluación.
− Proceso de mejora.
F.3.3.1 Establecimiento del proceso
Propósito:
El propósito del establecimiento del proceso es establecer un conjunto relacionado de

procesos organizativos para todos los procesos del ciclo de vida que se aplica a las
actividades comerciales.
Como resultado de la implementación exitosa de establecimiento del proceso:

PERUANA 136 de 189
1. Se establece un conjunto de procesos estándar definido y mantenido, con

una indicación de la aplicabilidad de cada proceso;
2. Se identifican las tareas detalladas, actividades y productos intermedios

asociados con el proceso estándar, junto con las características de rendimiento
esperadas;
3. Se desarrolla una estrategia para adaptar el proceso estándar del producto o

el servicio de acuerdo con las necesidades del proyecto; y
4. Se dispone y mantiene la información y datos relacionados al uso del

proceso estándar para los proyectos específicos.
F.3.3.2 Proceso de evaluación
Propósito:
El propósito del proceso de evaluación es determinar hasta qué punto los procesos
estándares de la organización contribuyen al logro de sus metas del negocio y ayudan a la
organización a enfocarse en la necesidad de la mejora continua del proceso.
Resultados:
Como resultado de la implementación exitosa del proceso de evaluación:
1. Se tendrá y mantendrá información y datos relacionados al uso del proceso

estándar para proyectos específicos;
2. Se entienden las fortalezas y debilidades relativas a los procesos estándares

de la organización; y
3. Se guardan y mantienen precisos y accesibles registros de evaluación.

PERUANA 137 de 189
F.3.3.3 Mejora de proceso de mejora
Propósito:
El propósito del proceso de mejora de proceso es perfeccionar continuamente la

efectividad y eficiencia de la organización a través de los procesos usados y mantenidos
alineados con la necesidad del negocio.
Resultados:
Como resultado de la implementación exitosa del proceso de mejora de proceso:
1. Se establece el compromiso para proporcionar los recursos para sostener las

acciones de mejora;
2. Se identifican los problemas que surgen del ambiente organizacional

interno/externo como las oportunidades de mejora y justificados como razones para
el cambio;
3. Se realiza el análisis del estado actual del proceso existente, enfocándose en

los procesos desde los cuales surge el estímulo de mejora;
4. Se identifican y se da prioridad a las metas de mejora y como consecuencia

se definen e implementan los cambios al proceso;
5. Se monitorean y confirman los efectos de la implementación del proceso de

acuerdo con las metas de mejora definida;
6. Se comunica el conocimiento obtenido de las mejoras dentro de la

organización; y
7. Se evalúan las mejoras hechas y se toman en consideración para usar las

soluciones en otra parte dentro del la organización.
NOTA 1 Las fuentes de información que proporcionan la entrada para el cambio puede incluir: el
proceso de evaluación, auditorías, reportes de satisfacción del cliente, efectividad/eficiencia
organizacional, costo de calidad.
NOTA 2 Los estados actuales de los procesos pueden ser determinados por la evaluación del
proceso.
PERUANA 138 de 189
F.3.4 Proceso de recursos humanos
Propósito:
El propósito del proceso de recursos humanos es proporcionar a la organización los

recursos humanos adecuados que mantengan sus competencias consistentes con las
necesidades de negocio.
Resultados:
Como resultado de la implementación exitosa del proceso de recursos humanos:
1. Se identifican los roles y habilidades requeridas para el funcionamiento de

la organización y el proyecto a través de la revisión de los requerimientos
organizacionales y del proyecto;
2. Se proporcionan recursos humanos a la organización y al proyecto;
3. Se identifica y proporciona un conjunto de necesidades de entrenamiento

comunes por la organización basadas en entradas organizacionales y de proyectos; y
4. Se ponen a disposición (reúnen) los recursos intelectuales de la organización

y se aprovechan a través de un mecanismo establecido;
El proceso de recursos humanos incluye propósito y resultados para los sub-procesos

siguientes:
− Gestión del recurso humano.
− Entrenamiento.
− Gestión del conocimiento.

PERUANA 139 de 189
F.3.4.1 Gestión del recurso humano
Propósito:
El propósito del proceso de gestión del recurso humano es proporcionar a la organización y

proyectos, individuos que posean las habilidades y conocimientos necesarios para realizar
sus roles eficazmente y trabajar juntos como un equipo cohesionado.
Resultados:
Como resultado de la implementación exitosa de la gestión del recurso humano:
1. Se identifican y se reclutan individuos con las habilidades y competencias

requeridas;
2. Se apoya la interacción eficaz entre los individuos y grupos;
3. Se logra que la fuerza de trabajo tenga las habilidades para compartir

información y coordinar sus actividades eficazmente; y
4. Se definen criterios objetivos para el monitoreo de rendimiento individual y

grupal para proveer retroalimentación y mejora de dichos procesos.
F.3.4.2 Entrenamiento
Propósito:
El propósito del entrenamiento es proporcionar a la organización y el proyecto de individuos

que posean habilidades y conocimientos necesarios para realizar sus roles eficazmente.
Resultados:
Como resultado de la implementación exitosa de entrenamiento:

PERUANA 140 de 189
1. Se desarrolla o adquiere el entrenamiento para dirigir las necesidades de

entrenamiento de la organización y del proyecto; y
2. Se conduce el entrenamiento para asegurar que todos los individuos tienen

las habilidades requeridas para realizar sus asignaciones, usando mecanismos tales
como estrategias de entrenamiento y materiales.
F.3.4.3 Gestión del conocimiento
Propósito:
El propósito de la gestión del conocimiento es asegurar que el conocimiento del individuo,

la información y las habilidades son reunidas, compartidas, reutilizadas y mejoradas a lo
largo de la organización.
Resultados:
Como resultado de la implementación exitosa de la gestión del conocimiento:
1. Se establece y mantiene la infraestructura para compartir información

relevante y común a través de la organización;
2. Se pone a disposición siempre y se comparte el conocimiento a lo largo de

la organización; y
3. Se selecciona para la organización, una estrategia de gestión de

conocimiento apropiada.
F.3.5 Proceso de gestión del recurso
Propósito:
El propósito del proceso de gestión del recurso es manejar la vida de recursos reutilizables
desde la concepción hasta el retiro.
PERUANA 141 de 189
Resultados:
Como resultado de la implementación exitosa del proceso de gestión del recurso.
1. Se documenta una estrategia de gestión del recurso;
2. Se establece un esquema de clasificación de recurso;
3. Se define los criterios para la certificación, aceptación y retiro del recurso;
4. Se opera un almacenamiento del recurso y el mecanismo de la recuperación;
5. Se registra el uso de recursos;
6. Se controlan cambios a los recursos; y
7. Se notifican a los usuarios de los recursos de problemas descubiertos, las

modificaciones hechas, nuevas versiones creadas y eliminación de los recursos del
almacenamiento y los mecanismo de recuperación.
F.3.6 Proceso de gestión del programa de reuso
Propósito:
El propósito del proceso de gestión del programa de reuso es planear, establecer, manejar,
controlar y monitorear el programa de reuso en la organización y sistemáticamente
aprovechar las oportunidades de reuso.
Resultados:
Como resultado de la implementación exitosa del proceso de gestión del programa de

reuso:
1. Se definen las estrategias de reuso de la organización incluyendo su

propósito, alcance, metas y objetivos;
PERUANA 142 de 189
2. Se identifican los dominios para las potenciales oportunidades de reuso;
3. Se evalúa la capacidad de reuso sistemático en la organización;
4. Se evalúa el reuso potencial en cada dominio;
5. Se evalúa las propuestas de reuso para asegurar que el reuso del producto es
adecuada para la aplicación propuesta;
6. Se implementa la estrategia de reuso en la organización;
7. Se establece mecanismos de retroalimentación, comunicación y notificación

que son usadas entre las partes afectadas; y
8. Se monitorea y evalúa el programa de reuso.
NOTA: Las partes afectadas pueden incluir administradores de programas de reuso, gestores de
evaluación, ingenieros de dominio, desarrolladores, operadores y responsables de mantenimiento.
F.3.7 Proceso de ingeniería de dominio1
Propósito:
El propósito del proceso de ingeniería de dominio es desarrollar y mantener modelos,

arquitecturas y recursos para el dominio.
Resultados:
Como resultado de la implementación exitosa del proceso de ingeniería de dominio:
1. Se selecciona las formas de representación de los modelos de dominio y sus

arquitecturas;
1
Espacio físico o abstracto en donde se presenta el problema y/o la solución de un sistema (problema,
contexto y solución).
Un dominio usualmente consta de estructuras de datos, flujos de información, funciones, restricciones y
controles entre otros elementos.
PERUANA 143 de 189
2. Se establecen los límites del dominio y sus relaciones con otros dominios;
3. Se desarrolla un modelo de dominio que captura las similitudes y

diferencias de características, capacidades, conceptos y funciones en el dominio;
4. Se desarrolla una arquitectura del dominio que describe la familia de

sistemas dentro del dominio;
5. Se especifican los recursos que pertenecen al dominio;
6. Se adquieren o desarrollan y se mantenienen los recursos que pertenecen al

dominio, a lo largo de sus ciclos de vida; y
7. Se mantienen los modelos de dominio y las arquitecturas a lo largo de sus

ciclos de vida.
PERUANA 144 de 189
ANEXO G
(INFORMATIVO)
ISO/IEC 12207 ESTRUCTURA DEL PROCESO PARA

"NUEVOS" PROCESOS EN EL ANEXO F
La ISO/IEC 12207 define las categorías de los procesos, por ejemplo, organizativo,
principal y apoyo, que se pueden realizar durante el ciclo de vida de software. Dentro de
cada categoría de procesos, los procesos que son expresados en términos de actividades y
tareas. Las actividades dentro de un proceso proporcionan la descomposición estructural
del proceso y describen las acciones que son realizadas durante la ejecución del proceso.
Las tareas dentro del ciclo de vida del software proporcionan lo que va a ser realizado
durante la implementación del proceso.
El Anexo G proporciona una descripción de las actividades y tareas para "nuevos"

procesos identificados en la Tabla E.1. Estas actividades y tareas, proporcionadas en este
anexo, han sido numeradas consecutivamente para corresponder a la sucesión de la
enumeración que tendrían en el cuerpo de ISO/IEC 12207. Además, estas actividades y
tareas están de acuerdo con la estructura del proceso de ISO/IEC 12207.
G.1 Procesos de apoyo del ciclo de vida
El proceso siguiente se adiciona a los procesos de ciclo de vida:
a) Proceso de usabilidad
G.1.1 Actividades y tareas del proceso de usabilidad
6.9 Proceso de usabilidad
El proceso de usabilidad contiene las actividades y tareas del especialista en usabilidad. El

proceso contiene las actividades que toman en cuenta los intereses y necesidades de los
individuos y/o grupos que trabajarán o usarán el resultado del sistema a lo largo del
PERUANA 145 de 189
desarrollo y operación del software o sistema. El proceso de usabilidad asegura la calidad

en el uso del software. Detalles de los procesos de diseño centrado en lo humano (DCH)
para sistemas interactivos. Pueden ser hallados en la norma NTP ISO/IEC 9126-1.
El desarrollo maneja el proceso de usabilidad a nivel del proyecto. El especialista en

usabilidad integra las actividades y los resultados de las actividades de usabilidad con los
procesos de desarrollo (5.3), operación (5.4) y apoyo (6.3, 6.4, 6.5) al ciclo de vida.
Lista de actividades: Este proceso consiste en las siguientes actividades.
a. Implementación de procesos.
b. Diseño centrado en lo humano.
c. Aspectos humanos de estrategia, introducción y apoyo.
NOTA: Estas actividades y las tareas asociadas pueden superponerse o interaccionar

recíprocamente y se pueden realizar iterativa o recursivamente.
6.9.1 Implementación de procesos: Esta actividad consiste en las siguientes

tareas:
6.9.1.1 Plan y manejo de los procesos DCH. Especifica cómo las actividades
centradas en lo humano encajan en los procesos del ciclo de vida del sistema y la empresa.
6.9.1.2 El desarrollador y el especialista en usabilidad deberán:
a) Consultar a los involucrados y usuarios.
b) Identificar y planear el involucramiento del usuario.
c) Seleccionar métodos y técnicas centrados en lo humano.
d) Asegurar el enfoque centrado en lo humano dentro del equipo del proyecto.
e) Planear las actividades de diseño centrado en lo humano.

PERUANA 146 de 189
f) Gestionar un enfoque centrado en lo humano.
g) Orientar un enfoque ganador centrado en lo humano.
h) Proveer el apoyo para el diseño centrado en lo humano.
6.9.2 Diseño centrado en lo humano: Esta actividad consiste en las tareas

siguientes:
6.9.2.1 Se proporcionará una especificación de los requerimientos de los

involucrados y la organización, se establecerán los requerimientos de la organización y
otras partes interesadas para el sistema. Esta tarea toma muy en cuenta las necesidades,
competencias y ambiente de trabajo de cada involucrado importante en el sistema.
6.9.2.2 En asociación con el desarrollador el especialista en usabilidad deberá:
a) Clarificar y documentar las metas del sistema.
b) Analizar a los involucrados y usuarios.
c) Evaluar la importancia y relevancia del sistema para cada grupo

involucrado.
d) Evaluar el riesgo a los involucrados y usuarios.
e) Definir el uso del sistema.
f) Generar los requerimientos de los involucrados y de la organización.
g) Establecer los objetivos de calidad de uso del sistema.
6.9.2.3 Se determinará una comprensión y especificación del contexto de uso,

identificando, clarificando y registrando las características de los involucrados y usuarios,
sus tareas y las de la organización y el ambiente físico en que el sistema operará.
6.9.2.4 El especialista en usabilidad deberá:

PERUANA 147 de 189
a) Identificar y documentar las tareas de los usuarios.
b) Identificar y documentar los atributos importantes del usuario.
c) Identificar y documentar el ambiente organizativo.
d) Identificar y documentar el ambiente técnico.
e) Identificar y documentar el ambiente físico.
6.9.2.5 Se creará la producción de soluciones de diseño, originando diseños

potenciales de soluciones basadas en la práctica del “estado del arte” establecida, la
experiencia y conocimiento de los participantes y el resultado del contexto de uso.
6.9.2.6 El desarrollador asistido por el especialista en usabilidad deberá:
a) Asignar las funciones.
b) Producir el modelo completo de tareas.
c) Explorar el diseño del sistema.
d) Usar el conocimiento existente para desarrollar las soluciones de diseño.
e) Especificar el sistema y su uso.
f) Desarrollar los prototipos.
g) Desarrollar el entrenamiento a los usuarios.
h) Desarrollar el apoyo a los usuarios.
6.9.2.7 La evaluación de diseño respecto a los requerimientos es realizada,

recopilando la retroalimentación, el desarrollo y el diseño. Esta retroalimentación será
obtenida de los usuarios finales y otras fuentes representativas.
6.9.2.8 El especialista de usabilidad deberá:

PERUANA 148 de 189
a) Especificar y validar el contexto de evaluación.
b) Evaluar los prototipos preliminares para definir los requerimientos para el

sistema.
c) Evaluar los prototipos para mejorar el diseño.
d) Evaluar el sistema para verificar que se cumplan los requerimientos de los

involucrados y la organización.
e) Evaluar el sistema para verificar que la práctica requerida ha sido seguida.
f) Evaluar el sistema en uso para asegurar que continúa satisfaciendo las

necesidades de la organización y los usuarios.
6.9.3 Aspectos humanos de estrategia, introducción y apoyo: Esta actividad

consiste de las siguientes tareas:
6.9.3.1 Asegurar el contenido DCH en la estrategia de sistemas. Establecer y

mantener el enfoque los problemas de los involucrados y los usuarios en cada parte de la
organización que trata con las propuestas de sistema, concepto, desarrollo y apoyo.
El especialista en usabilidad trabajará con un estudio de mercado pertinente y especialistas

de estrategias y mercado para:
a) Representar a los involucrados y usuarios.
b) Recopilar inteligencia del mercado.
c) Definir y planear la estrategia del sistema.
d) Recopilar la retroalimentación de mercado.
e) Analizar las tendencias en los usuarios.
6.9.3.2 Introducir y operar el sistema. Establecer los aspectos humanos-sistemas

para el soporte y aplicación del sistema.
PERUANA 149 de 189
6.9.3.3 El especialista en usabilidad trabajará con los especialistas relevantes en

despliege, entrenamiento y apoyo para facilitar:
a) La administración del cambio.
b) La determinación del impacto en la organización, involucrados y usuarios.
c) La adaptación y diseño local.
d) El entrenamiento al usuario.
e) El apoyo para los usuarios en las actividades planeadas.
f) La conformidad con la legislación sobre ergonomía del lugar de trabajo.
G.2 Procesos de gestión
La actividad de medición se agrega al proceso de gestión.
G.2.1 Actividades y tareas de medición
7.1.6 Medición: Esta actividad consiste en las siguientes tareas:
7.1.6.1 El administrador establecerá y mantendrá el compromiso de la medición.

Asegurar que todo el recurso, personal y requisitos de compromiso para el proceso de
medición han sido satisfechos. Los resultados de esta tarea proporcionan un compromiso
de la gerencia para apoyar el proceso de medición, individuos competentes en el área de
esta NTP se han identificado y se han asignado las responsabilidades para el proceso de la
medición y los recursos están disponibles para planear y realizar el proceso de medición.
7.1.6.2 El gerente planeará el proceso de la medición. Desarrollará un plan

detallado para iniciar, guiar, monitorizar y evaluar las tareas de recopilación de datos,
análisis, interpretación y almacenamiento. Los resultados de esta tarea proveen
información de la unidad organizativa y cualquier tecnología de apoyo que haya sido
adquirida e implantada.
PERUANA 150 de 189
7.1.6.3 El gerente realizará la medición definida de acuerdo con el plan. Producirá

información de los productos y métricas de rendimiento de acuerdo con los resultados de
las tareas de medición planeadas. Los resultados de esta tarea asegurarán que los datos han
sido recopilados y archivados en forma conveniente para su subsecuente recuperación y
análisis. Se producirán y comunicarán productos de información a las unidades
organizacionales. Se recolectarán medidas de rendimiento.
7.1.6.4 El gerente evaluará la medición. Evaluará las métricas y las actividades de

la medición y guardará las lecciones aprendidas de esta evaluación en el documento
"Experiencias de Medición”. Estas tareas producirán métricas y actividades de medición se
evaluarán de acuerdo con criterios específicos.
G.3 Actividades y tareas del proceso de recurso humano
Los procesos de entrenamientos en ISO/IEC 12207 se renombra como proceso de recurso

humano.
7.4 Proceso del recurso humano
El proceso del recurso humano proporciona a la organización y los proyectos individuos

que poseen habilidades y conocimiento para realizar sus roles eficazmente y trabajar juntos
como un grupo cohesivo.
Lista de actividades: Este proceso consiste en las siguientes tareas:
a) Implementar el proceso
b) Definir los requerimientos de entrenamiento
c) Reclutar personal calificado
d) Evaluar el desempeño de personal
e) Establecer los requerimientos del equipo de proyecto
f) Gestionar el conocimiento
PERUANA 151 de 189
7.4.1 Implementar el proceso: Esta actividad consta de la siguiente tarea:
7.4.1.1 Se conduce una revisión de la organización y requerimientos del proyecto es

conducida para establecer y hacer la provisión oportuna para la obtención o desarrollo de
los recursos y las habilidades requeridas por la gerencia y personal técnico. Estas
necesidades pueden satisfacerse a través de entrenamiento, contratación u otros
mecanismos de desarrollo de personal.
7.4.2 Definir los requerimientos de entrenamiento: Esta actividad consta de las

siguientes tareas:
7.4.2.1 Determinar los tipos y niveles de entrenamiento y conocimiento necesarios

para satisfacer a la organización y los requerimientos del proyecto serán determinados. Se
deberá desarrollar y documentar un plan de entrenamiento, un cronograma de
implementación, requerimientos de recursos, necesidades de entrenamiento.
7.4.2.2 Desarrollar o adquirir manuales de entrenamiento, incluso materiales de

presentación a ser usados en el entrenamiento.
7.4.2.3 Entrenar al personal para que tenga el conocimiento y las habilidades

necesarias para realizar sus roles.
7.4.3 Reclutar personal calificado: Esta actividad consta de la siguiente tarea:
7.4.3.1 Establecer un programa sistemático para el reclutamiento del personal

calificado para satisfacer las necesidades de la organización y proyectos. Proveer
oportunidades para el desarrollo de la carrera del personal existente.
7.4.4 Evaluar el desempeño del personal: Esta actividad consta de las siguientes
tareas.
7.4.4.1 Definir criterios objetivos que se puedan usar para evaluar la actuación del
personal.
PERUANA 152 de 189
7.4.4.2 Evaluar el desempeño del personal con respeto a sus contribuciones a las
metas de la organización o proyecto.
7.4.4.3 Asegurar que la retroalimentación se proporciona al personal sobre los

resultados de cualquier evaluación realizada.
7.4.4.4 Mantener registros adecuados de desempeño del personal incluyendo la

información sobre habilidades, entrenamiento recibido y evaluaciones de desempeño.
7.4.5 Establecer los requerimientos del equipo: Esta actividad consta de las
siguientes tareas:
7.4.5.1 Definir las necesidades de la organización y del proyecto para el equipo de

trabajo. Definir la estructura del equipo y las reglas de operación.
7.4.5.2 Potenciar los equipos para realizar su rol, asegurando que los equipos
tengan:
a) Una comprensión de su rol en el proyecto;
b) Una visión compartida o sentido de intereses comunes en el éxito del

proyecto;
c) Mecanismos apropiados o medios para la comunicación e interacciones

entre los equipos; y
d) Apoyo apropiado de la gerencia para cumplir los requerimientos del

proyecto.
7.4.6 Gestionar el conocimiento: Esta actividad consiste en las siguientes tareas:
7.4.6.1 El gerente planeará los requerimientos para manejar los activos de

conocimiento de la organización. La planificación incluirá la definición de la
infraestructura y entrenamiento para apoyar a los contribuyentes y a los usuarios de los
PERUANA 153 de 189
activos de conocimiento de la organización, el esquema y criterios de clasificación de

dichos activos.
7.4.6.2 El gerente tratará de establecer una red de expertos dentro de la

organización. La red contendrá la identificación de los expertos de la organización, una
lista de su área de especialización y la identificación de información disponible dentro de
un esquema de la clasificación, por ejemplo, área de conocimiento. El gerente asegurará
que la red se mantiene actualizada.
7.4.6.3 El gerente establecerá un mecanismo para apoyar el intercambio de

información entre los expertos y el flujo de información especializado en los proyectos de
la organización. El mecanismo apoyará el acceso, archivo y requerimientos de
recuperación de la organización.
7.4.6.4 Se realizará la gestión de la configuración de activos de acuerdo con el

Proceso de Gestión de la Configuración especificado en cláusula 6.2.
G.4 Actividades y tareas del proceso de gestión de activos
7.5 Proceso de gestión de activos
Sin tener en cuenta su calidad global y potencial para ser reusados, los activos tienen un
pequeño valor para la organización a menos que los potenciales reusadores sepan de su
existencia y puedan rápidamente localizarlos y entenderlos.
Este proceso contiene las actividades y tareas del gestor del activo. La gestión de activos es
el proceso de aplicar los procedimientos administrativos y técnicos a lo largo de la vida de
un activo con el propósito de identificar, definir, certificar, clasificar y delinear el activo;
rastrear las modificaciones, migraciones y versiones del activo; registrar e informar el
estado del activo y establecer y controlar el almacenamiento y manipuleo del activo, la
entrega del activo a sus reusadores y el retiro del mismo.
Lista de actividades. Este proceso consiste en las siguientes tareas:

PERUANA 154 de 189
a) Implementación del proceso;
b) Definición del almacenamiento y recuperación del activo;
c) Administración y control del activo.
7.5.1 Implementación de procesos: Esta actividad consiste en las siguientes

tareas:
7.5.1.1 El gestor del activo creará y documentará un plan de gestión de activos

reusando uno ya existente (de existir) para definir los recursos y procedimientos para la
gestión de activos. Dicho plan deberá incluir lo siguiente:
a) Definición de requerimientos para un mecanismo de almacenamiento y

recuperación de activos;
b) Definición del mecanismo de almacenamiento y recuperación de activos;
c) Establecimiento del mecanismo de almacenamiento y recuperación de

activos como parte integral del ciclo de vida del software;
d) Nombramiento de la(s) organización(es) responsable(s) de administrar y

mantener el mecanismo de almacenamiento y recuperación de activos;
e) Definición los procedimientos de aceptación, certificación y retiro de

activos;
f) Definición de la relación entre el administrador del activo y demás partes

tales como desarrolladores, responsables de mantenimiento e ingenieros de dominio;
g) Promoción del uso del mecanismo de almacenamiento y recuperación de

activos;
h) Definición de un mecanismo de comunicación para la administración de

activos;
i) Definición de un esquema de clasificación de activos.
7.5.1.2 El gestor de activos realizará lo siguiente:

PERUANA 155 de 189
a) Documentar esta actividad de acuerdo con el proceso de documentación

especificado en el apartado 6.1;
Realizar la gestión de la configuración de activos de acuerdo con el proceso de

gestión de la configuración especificado en el apartado 6.2;
b) Documentar y resolver problemas y disconformidades encontrados en los

activos y en la gestión de activos de acuerdo con el proceso de resolución del
problema especificado en el apartado 6.8;
c) Conducir revisiones de activos en concordancia con el proceso de revisión

conjunta especificada en el apartado 6.6.
7.5.1.3 El plan de gestión de activos se revisará de acuerdo con el proceso de

revisión conjunta especificado en el apartado 6.6. Los ingenieros de dominio y los
administradores del programa de reuso serán incluidos en la revisión.
7.5.2 Definición de almacenamiento y recuperación de activos: Un mecanismo

de almacenamiento y recuperación de activos permite a los reusadores encontrar y entender
de forma rápida y fácil los activos. Esta actividad consiste en las siguientes tareas:
7.5.2.1 El gestor del activo implementará y mantendrá un mecanismo de

almacenamiento y recuperación de activos.
7.5.2.2 El gestor del activo desarrollará, documentará y mantendrá un esquema de

clasificación, el mismo que será utilizado para clasificar los activos.
7.5.2.3 El gestor del activo conducirá revisiones conjuntas del mecanismo de

almacenamiento y recuperación de activos de acuerdo con el proceso de revisión conjunta
especificado en el apartado 6.6. Los administradores del programa de reuso así como los
ingenieros de dominio serán incluidos en la revisión.
7.5.3 Administración y control del activo: Para cada activo, esta actividad
consiste en las siguientes tareas:
7.5.3.1 Para cada activo remitido al administrador de activo, se hará una evaluación
basada en los criterios de aceptación y certificación del activo.
PERUANA 156 de 189
7.5.3.2 Cada activo aceptado se pondrá a disposición para ser reusado utilizando el
mecanismo de almacenamiento y recuperación de activos.
7.5.3.3 El activo será clasificado de acuerdo con el esquema de clasificación de

reuso, de existir.
7.5.3.4 El gestor del activo realizará la gestión de la configuración para el activo

usando el Proceso de Gestión de la Configuración especificado en el apartado 6.2 .
7.5.3.5 El gestor del activo guardará la historia de cada reuso del activo y reportará
al ingeniero de dominio sobre el actual reuso del activo. La información de reuso del activo
deberá incluir el nombre del reusador, el nombre del proyecto, el desarrollador original o
dueño del activo, el costo de reuso del activo, así como el ahorro o beneficios derivados del
reuso del activo.
7.5.3.6 El gestor de activos derivará los requerimientos de modificación y reportes

de problemas comunicados por los reusadores al ingeniero de dominio para las
correspondientes acciones y planes de corrección y/o modificación. Las acciones planeadas
de modificación o corrección serán reportadas al gestor de activos.
7.5.3.7 El gestor de activos supervisará y registrará tanto los requerimientos y

reportes de problemas como las acciones llevadas a cabo para su corrección y/o
modificación. Siempre que se encuentren problemas con un activo, ellos se deben registrar
y deben entrar en el proceso de resolución de problemas, como está especificada en el
apartado 6.8.
7.5.3.8 El gestor de activos notificará a todos los reusadores de activos y al

ingeniero de dominio de los problemas detectados en el activo, las modificaciones hechas
al activo, nuevas versiones del activo y la eliminación del activo del mecanismo de
almacenamiento y recuperación de activos.
7.5.3.9 El gestor de activos retirará los activos del mecanismo de almacenamiento y

recuperación de acuerdo con los procedimientos y criterios de retiro de activos.
PERUANA 157 de 189
G.5 Actividades y tareas del proceso de gestión del programa de reuso
7.6 Proceso de gestión del programa de reuso
Tener éxito con la implementación del reuso sistemático a nivel de la organización

requiere de un planeamiento cuidadoso y una gestión apropiada. Debido a que los retos de
negocios de gestión y de personas a menudo sobrepasan los retos técnicos de
implementación de reuso, liderazgo de gestión, compromiso y apoyo, así como la cultura
del reuso positivo del software deberá ser enfatizado en un programa de reuso. Se espera
que todos los individuos en el alcance del programa de reuso cooperan entre ellos para
establecer los procesos de reuso y compartir entre ellas sus experiencias y activos de reuso.
El proceso de gestión del programa de reuso contiene actividades y tareas del

administrador de programa de reuso. Este proceso es usado para planear, establecer,
manejar, controlar y hacer seguimiento al programa de reuso de la organización.
a) Iniciación;
b) Identificación del dominio;
c) Valoración del reuso;
d) Planeamiento;
e) Ejecución y control;
f) Revisión y evaluación.
7.6.1 Iniciación: Esta actividad consiste en las siguientes tareas:
7.6.1.1 El programa de reuso para una organización se iniciará estableciendo la

estrategia de reuso del mismo, la que incluye las metas del reuso, los propósitos, los
objetivos y el alcance. Los elementos del programa de reuso deberán apuntar a lo
siguiente:
PERUANA 158 de 189
a) Promoción del reuso;
b) Infraestructura del reuso (incluye el hardware, software, herramientas,

técnicas, normas, métricas y facilidades para practicar el reuso);
c) Fondos y otros recursos para el reuso;
d) Funciones de apoyo al programa de reuso;
e) Mecanismos de comunicación, retroalimentación y notificación de reuso;
NOTA: El administrador del programa de reuso define los mecanismos siguientes:
1. Mecanismo de retroalimentación de cada proyecto de desarrollo de software hacia el

ingeniero de dominio y gestor de activos para comunicar el uso e impacto de los productos del
software y activos en cada proyecto;
2. Mecanismo de comunicación entre el desarrollador, operador, responsable de

mantenimiento, ingeniero de dominio, gestor de activos y el administrador del programa de reuso
para resolver problemas, responder preguntas y hacer recomendaciones relacionadas con los
productos de software y activos que cada proyecto encuentra;
3. Mecanismo de notificación que hace que el desarrollador, responsable de mantenimiento,

gestor de activos, e ingeniero de dominio estén informados de las actuales leyes comerciales, el
licenciamiento de productos de software y activos, restricciones organizativas que protegen sus
propios intereses y acuerdos que pueden restringir o excluir el uso de un producto de software o
activo especifico;
4. Mecanismo para que el ingeniero de dominio obtenga la participación y la información

necesaria de las fuentes apropiadas para completar las actividades de ingeniería de dominio.
7.6.1.2 Un promotor de reuso debe ser nombrado.
7.6.1.3 Los participantes del programa de reuso deben ser identificados y sus roles
asignados.
7.6.1.4 Una función de conducción del reuso será establecida para asumir la
autoridad y responsabilidad del programa de reuso de la organización. Sus funciones
deberán incluir lo siguiente:
a) Investigación de la práctica de reuso en la organización;

PERUANA 159 de 189
b) Identificación de las áreas en la organización donde hay potenciales

oportunidades de reuso;
c) Asignación de las responsabilidades para el reuso en la organización;
d) Redefinición de los incentivos de la organización, desincentivos y cultura

para soportar y encarar el reuso.
NOTA: Los miembros de la función de gestión del reuso incluyen al promotor del reuso, el
administrador de desarrollo de software, el administrador de operaciones, el administrador de
mantenimiento de software y un experto en reuso.
7.6.1.5 Una función de soporte al programa de reuso será establecida. Las

responsabilidades de la función de soporte al programa de reuso deberá incluir lo siguiente:
a) Participación en la creación e implementación de un plan de

implementación del programa de reuso;
b) Identificación, documentación y difusión de la estrategia de reuso a todos

los participantes del programa de reuso;
c) Promoción de la práctica del reuso para fomentar una cultura favorable de

reuso del software;
d) Búsqueda de oportunidades para practicar el reuso en los actuales y futuros

proyectos de software;
e) Establecimiento y mantenimiento de una infraestructura de reuso;
f) Provisión de consultoría en reuso a aquellos proyectos de software que lo

practican.
7.6.2 Identificación del dominio: Un dominio caracteriza un conjunto de

sistemas en base a propiedades comunes que pueden ser organizadas en una colección de
activos reusables que a su vez pueden ser utilizados para construir sistemas en el dominio.
Esta actividad consiste en las siguientes tareas:
7.6.2.1 El administrador del programa de reuso, apoyado por los gerentes

adecuados, ingenieros de dominio, usuarios y desarrolladores de software identificarán y
PERUANA 160 de 189
documentarán los dominios en donde investigar oportunidades de reuso o en donde la

organización tiene interés en aplicarlo.
7.6.2.2 El administrador del programa de reuso, ayudado por los gerentes

adecuados, ingenieros de dominio, usuarios y desarrolladores de software evaluarán los
dominios para asegurar que ellos reflejan con precisión la estrategia de reuso de la
organización. Los resultados de la evaluación serán documentados.
7.6.2.3 El administrador del programa de reuso dirigirá revisiones conjuntas de

acuerdo con el Proceso de Revisión Conjunta especificado en el apartado 6.6. Los
desarrolladores de software, ingenieros de dominio y usuarios serán incluidos en las
revisiones.
7.6.2.4 Cuanto más información sobre dominios de la organización y planes sobre

futuros productos de software se tenga a disposición, o cuando los dominios sean
analizados, éstos podrán ser refinados y reenfocados por al administrador del programa de
reuso.
7.6.3 Valuación del reuso: La valorización del reuso proporciona una base
contra la cual la práctica de reuso en la organización puede ser medida. Sin esta
evaluación, los beneficios que resulten de la práctica de reuso en la organización serán
difíciles de medir. Los propósitos de esta actividad son:
a) Ganar una comprensión de la madurez del reuso en la organización;
b) Valorar el potencial del reuso en los dominios objetivo de la organización;
c) Hacer recomendaciones de cómo proceder con la práctica del reuso en la

organización;
d) Motivar y direccionar mejoras incrementales en las diversas áreas del

programa de reuso en la organización, incluído el entrenamiento y la infraestructura.
Esta actividad consiste en las tareas siguientes.

PERUANA 161 de 189
7.6.3.1 El administrador del programa de reuso valorará la capacidad sistemática de

reuso de la organización. Los resultados de la valoración se documentarán y se
proporcionarán a la función de gestión del reuso.
7.6.3.2 El administrador del programa de reuso valorará cada dominio a ser

considerado para el reuso, con el objetivo de determinar el potencial de éxito del reuso en
dicho dominio. Los resultados de la valoración se documentará y se proporcionará a la
función de gestión del reuso.
7.6.3.3 El administrador del programa de reuso hará las recomendaciones para

refinar la estrategia de reuso en la organización y el plan de implementación del programa
de reuso basado en los resultados de la valoración del reuso. Las recomendaciones se
documentarán y proporcionarán a la función de gestión del reuso.
7.6.3.4 El administrador del programa de reuso, junto con los adquirientes,

proveedores, desarrolladores, operadores, responsables de mantenimiento, gestor de
activos e ingenieros de dominio, utilizarán el proceso de mejora de proceso especificado en
el apartado 7.3 para que en forma gradual mejoren sus habilidades, tecnologías, procesos
de reuso, estructura organizacional y métricas, las mismas que conforman la infraestructura
de reuso.
7.6.4 Planificación: Esta actividad consiste en las tareas siguientes:
7.6.4.1 Un plan de implementación del programa de reuso se creará, documentará y

mantendrá, reutilizando (de existir) la plantilla de algún plan ya existente, para definir los
recursos y procedimientos de implementación de un programa de reuso. El plan describirá
lo siguiente:
a) Las actividades del programa de reuso;
b) Los procedimientos y cronogramas para llevar a cabo estas actividades;
c) Los participantes responsables de llevar a cabo estas actividades;
d) Las relaciones con otros participantes, como desarrolladores de software o

ingenieros de dominio;
PERUANA 162 de 189
e) Los recursos necesarios para el programa de reuso;
7.6.4.2 El plan será revisado y evaluado considerando los siguientes criterios:
a) Integridad;
b) Habilidad para comprender la estrategia de reuso de la organización;
c) Posibilidad de llevar a cabo el plan.
Se documentarán los resultados de la evaluación. Aquéllos que evalúan el plan deben

incluir a los miembros de la función de gestión de la reutilización.
7.6.4.3 La aprobación y apoyo al plan de implementación del programa de reuso

será obtenido de la función de gestión del reuso y de los gerentes apropiados.
7.6.4.4 El administrador del programa de reuso dirigirá las revisiones conjuntas de

acuerdo con el proceso de revisión conjunta especificado en el apartado 6.6. Los miembros
de la función de gestión del reuso y los gerentes apropiados serán incluidos en las
revisiones.
7.6.5 Ejecución y control: Esta actividad consiste en las siguientes tareas:
7.6.5.1 Las actividades del plan de implementación del programa de reuso serán
ejecutadas de acuerdo con el plan.
7.6.5.2 El administrador del programa de reuso monitoreará el avance del programa

de reuso contra la estrategia de reuso, de la organización y realizará y documentará
cualquier ajuste necesario para que el plan se ajuste a la estrategia.
7.6.5.3 Problemas y no-conformidades que ocurran durante la ejecución del plan de

implementación del programa de reuso serán registrados e incorporados en el proceso de
resolución de problemas, tal como se especifica en el apartado 6.8 .
PERUANA 163 de 189
7.6.5.4 El administrador del programa de reuso reafirmará periódicamente el

patrocinio, apoyo y compromiso de la gerencia para con el programa de reuso.
7.6.6 Revisión y evaluación: Esta actividad consiste en las siguientes tareas:
7.6.6.1 El administrador del programa de reuso evaluará periódicamente el

programa para lograr la estrategia de reuso de la organización y la continua capacidad y
efectividad del programa de reuso.
7.6.6.2 El administrador del programa de reuso proporcionará los resultados de la

evaluación y las lecciones aprendidas a la función de gestión del reuso y a los gerentes
apropiados.
7.6.6.3 El administrador del programa de reuso recomendará y hará los cambios al

programa de reuso, lo difundirá y mejorará de acuerdo con el proceso de mejora de proceso
especificado en el apartado 7.3.
G.6 Actividades y tareas del proceso de ingeniería de dominio
7.7 Proceso de ingeniería de dominio
El proceso de ingeniería de dominio contiene las actividades y tareas del ingeniero de

dominio. El proceso cubre el desarrollo y mantenimiento de los modelos de dominio,
arquitectura de dominio y otros activos de este dominio.
a) Implementación del proceso;
b) Análisis del dominio;
c) Diseño del dominio;
d) Provisión del activo;

PERUANA 164 de 189
e) Mantenimiento del activo.
NOTA
1. La ingeniería del dominio es una aproximación basada en la reutilización para definir el

alcance (ejm. Definición de dominio), especificar la estructura (ejm. Arquitectura de dominio),
construir activos (ejm. Requerimientos, diseños, código de software, documentación) para una
clase de sistemas, sub-sistemas o aplicaciones. La ingeniería de dominio puede incluir las
siguientes actividades: definición de dominio, análisis de dominio, desarrollo de la arquitectura de
dominio e implementación de dominio.
2. Estas actividades y tareas pueden traslaparse o interactuar y pueden ser realizadas iterativa
o recursivamente. Asimismo el procesos de ingeniería de dominio puede traslaparse con los
procesos de desarrollo y mantenimiento que usan activos producidos por el dominio.
7.7.1 Implementación del proceso: Esta actividad consiste en las tareas

siguientes:
7.7.1.1 El ingeniero de dominio creará y documentará un plan de ingeniería de

dominio, reutilizando -de existir- una plantilla ya existente para definir los recursos y
procedimientos para llevar a cabo la ingeniería de dominio. El plan incluirá normas,
métodos, herramientas, actividades, asignaciones y responsabilidades. Para crear el plan de
ingeniería de dominio, el ingeniero de dominio consultará la literatura y/o recursos de
información sobre el dominio así como con expertos de dominio, desarrolladores y
usuarios de productos de software al interior del dominio. El plan de ingeniería de dominio
será ejecutado.
7.7.1.2 El ingeniero de dominio seleccionará la forma de representación a ser

utilizada para los modelos y arquitecturas de dominios respectivas, de acuerdo con las
normas de reutilización de la organización y consultando a los expertos del área,
diseñadores y usuarios de productos del software dentro del dominio.
7.7.1.3 El ingeniero de dominio realizará lo siguiente:
a) Documentar este proceso de acuerdo con el proceso de documentación

especificado en el apartado 6.1;
b) Ejecutar la gestión de la configuración para los resultados de la ingeniería

de dominio de acuerdo con el proceso de gestión de la configuración especificado en
el apartado 6.2;
PERUANA 165 de 189
c) Documentar y resolver problemas y no-conformidades encontradas en los

activos y en el proceso de ingeniería de dominio de acuerdo con el proceso de
solución de problemas especificado en el apartado 6.8 ;
d) Dirigir revisiones conjuntas de acuerdo con el proceso de revisiones

conjuntas especificado en el apartado 6.6 e incluir en las revisiones a expertos del
dominio, desarrolladores de software y usuarios de los productos de software dentro
del dominio;
e) Establecer procedimientos para recibir, resolver y proporcionar

retroalimentación al administrador de activos siempre que los problemas o consultas
se den para aquellos activos desarrollados por el ingeniero de dominio.
7.7.2 Análisis de dominio: El análisis de dominio es la actividad que descubre y

describe formalmente las semejanzas y variabilidades dentro de un dominio. El ingeniero
de dominio captura esta información en un conjunto de modelos de dominio. Esta actividad
consiste en las siguientes tareas:
7.7.2.1 El ingeniero de dominio define los límites del dominio y las relaciones entre
éste y otros dominios.
7.7.2.2 El ingeniero de dominio identificará las necesidades actuales y anticipadas

de los desarrolladores de software al interior del dominio.
7.7.2.3 El ingeniero de dominio construirá modelos de dominio utilizando formas

de representación seleccionadas en la actividad de implementación para este proceso.
7.7.2.4 El ingeniero de dominio construirá un glosario que proporcionará la

terminología para describir los conceptos importantes del dominio y las relaciones entre los
recursos similares o comunes del dominio,
7.7.2.5 El ingeniero de dominio clasificará y documentará los modelos del dominio.
7.7.2.6 El ingeniero del dominio evaluará los modelos y el vocabulario del dominio
de acuerdo con las provisiones de la técnica de modelamiento seleccionada y de acuerdo
PERUANA 166 de 189
con los procedimientos de aceptación y certificación de activos de la organización. Los

resultados de la evaluación serán documentados.
7.7.2.7 El ingeniero de dominio dirigirá las reuniones conjuntas de análisis de

dominio de acuerdo con el Proceso de Revisiones Conjuntas en el apartado 6.6. Los
desarrolladores de software, gestores de activos, expertos de dominio y usuarios serán
incluidos en las revisiones.
7.7.2.8 El ingeniero de dominio remitirá los modelos de dominio al gestor de

activos.
7.7.3 Diseño de dominio: Las actividades del diseño de dominio definen la

arquitectura de dominio y especifican los activos que pueden ser usados para construir los
productos del software. La arquitectura de dominio es un diseño de alto nivel en donde las
interfaces de activo están formalmente identificadas. La arquitectura de dominio sirve
como marco referencial para la construcción de productos de software mediante el reuso de
activos. Esta actividad consiste en las tareas siguientes:
7.7.3.1 El ingeniero del dominio creará y documentará la arquitectura de dominio,

consistente con el modelo de dominio y según las normas de la organización,
7.7.3.2 La arquitectura de dominio se evaluará de acuerdo con la técnica de diseño

de arquitectura seleccionada y los procedimientos de aceptación y certificación de activos
de la organización. Los resultados de la evaluación serán documentados.
7.7.3.3 Para cada entidad seleccionada a ser diseñada para el reuso, el ingeniero de
dominio desarrollará y documentará una especificación del activo.
7.7.3.4 Para cada activo especificado, la especificación se evaluará de acuerdo con

lo estipulado en el apartado 5.3.6.7. y con los procedimientos de aceptación y certificación
de activos de la organización. Los resultados de la evaluación serán documentados.
7.7.3.5 El ingeniero de dominio dirigirá las revisiones conjuntas de diseño de

dominio de acuerdo con el proceso de revisión conjunta especificado en el apartado 6.6.
PERUANA 167 de 189
Los desarrolladores de software, expertos de dominio y gestores de activos serán incluidos

en estas revisiones.
7.7.3.6 El ingeniero de dominio remitirá la arquitectura de dominio al gestor del

activo.
7.7.4 Provisión de activos: La actividad de provisión de activos desarrolla o

adquiere activos que pueden ser usados para ensamblar productos de software. Para cada
activo desarrollado o adquirido se deben realizar las siguientes tareas:
7.7.4.1 El ingeniero de dominio desarrollará los activos, de la siguiente manera
a) Ejecutando el proceso de adquisición (véase 5.1) se genera un contrato

mediante el cual el activo es puesto en su lugar una vez adquirido; o
b) Ejecutando el proceso de desarrollo (véase 5.3) si el activo será desarrollado

internamente,
7.7.4.2 El activo se documentará y será clasificado.
7.7.4.3 El ingeniero de dominio evaluará el activo de acuerdo con los

procedimientos de aceptación y certificación del activo. Los resultados de la evaluación se
documentará.
7.7.4.4 El ingeniero de dominio dirigirá la revisión conjunta de activos de acuerdo

con el proceso de revisión conjunta especificado en el apartado 6.6. Los desarrolladores de
software y gestores de activos serán incluidos en las revisiones.
7.7.4.5 El ingeniero de dominio remitirá el activo al gestor del activo.
7.7.5 Mantenimiento del activo: La actividad de mantenimiento del activo

contiene las tareas para modificar activos, incluyendo modelos y arquitecturas de dominio.
Un activo se modifica para corregir una deficiencia o para adaptarlo a un nuevo
requerimiento. El ingeniero de dominio modificará el activo ejecutando el proceso de
PERUANA 168 de 189
mantenimiento especificado en el apartado 5.5. Adicionalmente, las siguientes tareas

relacionadas con el reuso son agregadas a este proceso de mantenimiento siempre que sea
aplicado al mantenimiento de una activo:
7.7.5.1 Al analizar los pedidos para la modificación de activos y las opciones de

implementación, el ingeniero de dominio considerará:
a) Conformidad con el modelo y arquitectura del dominio;
b) Impacto en los sistemas y productos del software que usan el activo;
c) Impacto en los usuarios futuros del activo;
d) Impacto en la reutilización del activo.
7.7.5.2 El ingeniero de dominio obtendrá la aprobación para la opción de

implementación seleccionada así como la aprobación para el cronograma y planes de
modificación.
7.7.5.3 El ingeniero de dominio notificará al gestor de activos quien envió la

petición para modificar el activo, sobre si la modificación del activo fue aprobada así como
los planes y cronograma de la modificación. Cuando una petición de la modificación no es
aceptada, esta registrará e ingresará en el proceso de resolución de problema, como está
especificado en el apartado 6.8.
7.7.5.4 Después que se obtiene la aprobación, el ingeniero de dominio entrará en el

proceso de ingeniería de dominio para implementar las modificaciones para el activo.
7.7.5.5 El ingeniero de dominio enviará al activo modificado junto con cualquier

instrucción de uso y pruebas al gestor de activos quien envió la petición para modificar el
activo.
PERUANA 169 de 189
ANEXO H
(INFORMATIVO)
ISO/IEC TR 15504-2, PDAM1, EXTENSIÓN DEL

MODELO DE REFERENCIA PARA EL ISO/IEC
12207:1995 PROCESO DE ADQUISICIÓN
El Anexo H provee una extensión de las definiciones que se indican en el ISO/IEC TR 15504-
2 referido al proceso de adquisición y se centra en su actual falta de granularidad asociada al
Proceso de Adquisición de la ISO/IEC TR 15504-2. Este anexo amplía las definiciones del
proceso de adquisición establecidas en la TR 15504-2 y provee la granularidad necesaria con
el propósito de la evaluación y mejora del proceso de adquisición. Estos procesos extendidos
proveen una sólida base para la evaluación del proceso de adquisición y la capacidad de
identificar de una mejor manera los riesgos en el aprovisionamiento del software. Las
definiciones del proceso de adquisición establecidas en el presente anexo están incluidas en
esta enmienda para formar las bases del modelo de referencia de procesos a ser usado con la
ISO 15504 .
Los propósitos y resultados del proceso proveído en este anexo pueden ser usados en lugar de
los propósitos y resultados del F.1.1 proceso de adquisición. Adicionalmente a los propósitos
y resultados del proceso de adquisición, este anexo provee la extensión de la definición del
proceso en el formato de las actividades y tareas de la ISO/IEC 12207.
NOTA Liberación de los derecho de autor: Los usuarios pueden reproducir libremente la
descripción detall de los propósitos y resultados del proceso descrito en el presente anexo como parte
de un modelo de evaluación basado en el modelo de referencia de procesos, o como parte de una
demostración de compatibilidad con el modelo de referencia de procesos; de esta manera éste puede
ser usado para un propósito específico.
H.1 Propósito y resultados del proceso de adquisición
Lo siguiente proporciona una alternativa a ser usada en lugar del Anexo F.1.1 Propósitos y
resultados del proceso de adquisición.
PERUANA 170 de 189
Propósito:
El propósito del proceso de adquisición es obtener el producto y/o servicio que satisfaga
las necesidades expresadas del cliente. El proceso empieza con la identificación de la
necesidad del cliente y termina con la aceptación del producto y/o servicio solicitado por el
cliente.
Resultados:
Como resultado de la implementación exitosa del proceso de adquisición:
1. Se definirán las necesidades de adquisición, las metas, los criterios de

aceptación y las estrategias de adquisición;
2. Se desarrollará un acuerdo en donde se especificará claramente las

expectativas, responsabilidades y obligaciones tanto del cliente como del proveedor;
3. Se producirá un producto y/o servicio que satisfaga las necesidades

establecidas por el cliente;
4. Se monitoreará la adquisición para que se cumplan con aspectos específicos

como costos, plazos y calidad; y
5. Se aceptarán los entregables de los proveedores.
Los sub-procesos que pertenecen al proceso de adquisición son:
1. Política de adquisición
2. Estrategia de adquisición
3. Análisis de beneficios
4. Requerimientos técnicos
5. Requerimientos legales y administrativos

PERUANA 171 de 189
6. Requerimientos financieros
7. Requerimientos del proyecto
8. Solicitud de la propuesta
9. Calificación del proveedor
10. Evaluación de propuestas
11. Acuerdo contractual
12. Monitoreo del proveedor
13. Aceptación
14. Cierre del contrato
15. Relación con el proveedor
16. Relación con el usuario
17. Administración financiera
H.1.1 Política de adquisición
Propósito:
El propósito del proceso de la política de adquisición es establecer metas comunes, de alto

nivel, las bases para las necesidades de adquisición y los métodos a ser implementados
para la conducción de una adquisición.
Resultados:
Como resultado de la implementación exitosa del proceso de política de adquisición:

PERUANA 172 de 189
a) Se establecerá la necesidad de implementar una política común de

adquisición para la organización;
b) Se establecerán las bases sistemáticas, o la preferencia por, tecnología,

proceso, métodos, vendedores, estándares y regulaciones legales, para optimizar la
adquisición;
c) Se establecerá la necesidad de asegurar recursos adecuados para la gestión

de la adquisición, incluyendo las habilidades contractuales, técnicas, financieras y
gestión de proyectos del adquiriente;
d) Se establecerá la necesidad de definir estándares de calidad para entregables

de acuerdo con las necesidades establecidas e implícitas del adquiriente;
e) Se establecerá la necesidad de lograr una relación efectiva y productiva con

el proveedor y demás grupos involucrados.
H.1.2 Estrategia de adquisición
Propósito:
El propósito del proceso de la estrategia de adquisición es asegurar que los productos y/o
servicios a ser adquiridos cumplan con la misión, metas y objetivos del negocio, así como
proveer las bases para el planeamiento de todos los aspectos del proyecto de adquisición.
Este proceso involucra una combinación de infraestructura de negocio (presupuesto,
inversión financiera), métodos de adquisición (preelaborados, personalizados) y políticas
comunes (estrategias de adquisición, determinación de inventarios)
Resultados:
Como resultado de la implementación exitosa de la estrategia de adquisición:
1. Se desarrollará un enfoque de administración de programas planificados

hacia el cumplimiento de políticas de adquisición y necesidades del negocio tanto
para el usuario como para el adquirente;
PERUANA 173 de 189
2. Se identificarán las metas específicas (financieras, contractuales, del

proyecto, técnicas) y objetivos para enfoques diferentes o alternativos;
3. Se identificarán los factores críticos de éxito para la adquisición;
4. Se identificarán las distintas formas en que las soluciones pueden satisfacer

las necesidades y expectativas del adquiriente;
5. Se identificarán los riesgos de negocio, las implicancias financieras, técnicas

y de recursos, para los diferentes enfoques o soluciones;
6. Se identificarán los requerimientos de actualización de productos.
H.1.3 Análisis de beneficios
Propósito:
El propósito del proceso de análisis de beneficios es establecer la continua relevancia y

beneficio de la adquisición en concordancia con el desarrollo y necesidades de cambio en los
requerimientos de los adquirientes y necesidades del negocio.
Resultados:
Como resultado de la implementación exitosa del proceso de análisis de beneficio:
1. Se analizará el alineamiento de los beneficios de la adquisición con los

objetivos del negocio;
2. Se realizará el análisis de los beneficios relacionados a los costos de la

adquisición.
PERUANA 174 de 189
H.1.4 Requerimientos técnicos
Propósito:
El propósito del proceso de requerimientos técnicos es establecer los requerimientos técnicos

de la adquisición. Esto incluye la obtención de requerimientos funcionales y no funcionales
que consideran el ciclo de vida de desarrollo de productos así como establecer la línea base
para los requerimientos técnicos.
Resultados:
Como resultado de la implementación exitosa del proceso de requerimientos técnicos:
1. Se definirán y desarrollarán los requerimientos técnicos, incluyendo la

evaluación de efectos del entorno y requerimientos de seguridad, cuando sean
apropiados, de manera que correspondan con las necesidades y expectativas de los
usuarios;
2. Se recogerán y definirán las actuales y nuevas necesidades de adquisición;
3. Se comunicarán los requerimientos y soluciones potenciales a todos los

grupos afectados;
4. Se establecerá un mecanismo para incorporar requerimientos nuevos o

cambiados en la línea base establecida;
5. Se definirá un mecanismo para identificar y administrar el impacto de los

cambios tecnológicos en los requerimientos técnicos;
6. Se incluirán los requerimientos de conformidad con estándares relevantes,

incluyendo una evaluación de los efectos en el entorno y estándares de seguridad de
ser aplicable.
NOTA: La NTP-ISO 9126 puede ser un modelo muy útil para obtener requerimientos técnicos.
PERUANA 175 de 189
H.1.5 Requerimientos legales y administrativos
Propósito:
El propósito del proceso de requerimientos legales y administrativos es definir los aspectos de

la adjudicación, expectativas, responsabilidades, legalidad y otros temas, los cuales deben
cumplir con las leyes de contrato, nacionales e internacionales.
Resultados:
Como resultado de la implementación exitosa del proceso:
1. Se definirá un enfoque contractual, el mismo que estará acorde con las leyes
reguladoras nacionales e internacionales, reglamentos y políticas;
2. Se definirá un acuerdo (contractual) de términos y condiciones para

describir cómo el proveedor cumplirá las necesidades y expectativas;
3. Se establecerán criterios de aceptación y mecanismos para controlar el

incumplimiento de contrato;
4. Se establecerán los derechos del adquiriente para asumir, modificar o

evaluar, directa o indirectamente los derechos de propiedad intelectual;
5. Se proveerán garantías y acuerdos de nivel de servicio donde sean

aplicables;
6. Se definirá la provisión para que los proveedores entreguen otros

requerimientos (ejm. plan de calidad, acuerdos tipo escrow, etc);
7. Se establecerán criterios reconocidos de propiedad, regulación y otros temas

sobre responsabilidad de productos.
NOTA: El acuerdo final de términos será determinado durante el sub-proceso de establecimiento

del Contrato.
PERUANA 176 de 189
H.1.6 Requerimientos financieros
Propósito:
El propósito del proceso de requerimientos financieros es especificar los requerimientos para

preparar la infraestructura de una efectiva administración financiera del proyecto de
adquisición.
Resultados:
Como resultado de la implementación exitosa del proceso de requerimientos financieros:
1. Se establecerán una administración financiera, riesgos y costos para el

adquiriente;
2. Se definirán y registrarán las condiciones financieras para los costos y pagos

que originen la adquisición;
3. Se rastrearán aspectos financieros del proceso de adjudicación del contrato

hasta su término;
4. Se utilizarán requisitos de financiamiento como base para la preparación del

presupuestos de actividades de proyectos, los mismos que estarán sujetos a controles
presupuestales autorizados;
5. Se establecerán requerimientos para reporte de costos con el proveedor de

acuerdo con el modelo(s) de estimación de costos;
6. Se establecerán requerimientos de pagos a ser administrados de acuerdo con

un procedimiento definido que relaciona datos del contrato y su realización;
7. Se llevará a cabo la priorización de requerimientos con el fin de asegurar el

alineamiento de la solución del ciclo de vida de la adquisición con la importancia
relativa de los requerimientos.
PERUANA 177 de 189
H.1.7 Requerimientos del proyecto
Propósito:
El propósito del proceso de requerimientos del proyecto es especificar los requerimientos para
asegurar que el proyecto de adquisición sea desarrollado con una adecuada planeación,
personal, gestión, organización y control sobre todas las actividades y tareas del proyecto.
Resultados:
1. Se establecerá una consistencia entre los requerimientos financieros,

técnicos, contractuales y del proyecto;
2. Se definirán requerimientos sobre aspectos de un proyecto como

organización, administración, control y seguimiento;
3. Se definirán requerimientos para una adecuada dotación de personal para los

proyectos por un equipo competente (ejm. legal, contractual, técnico, recursos de
proyecto competentes) con responsabilidades y metas claras;
4. Se establecerán las necesidades de intercambio de información entre todas

las partes involucradas;
5. Se establecerán requerimientos para el término y aceptación de pagos de

entregables internos y versiones en producción y la ejecución de pagos;
6. Se identificarán riesgos asociados con el ciclo de vida del proyecto y con los
proveedores;
7. Se definirán requerimientos de interacciones e interrelaciones de propiedad

con proveedores;
8. Se definirán los derechos de uso correcto y distribución del producto por el

cliente y proveedor;
9. Se establecerán los requerimientos de soporte y mantenimiento.

PERUANA 178 de 189
H.1.8 Solicitud de la propuesta
Propósito:
El propósito del proceso de solicitud de la propuesta es preparar y dar a conocer los

requerimientos necesarios de adquisición. La documentación incluirá, pero no se limitará a, el
contrato, proyecto, requerimientos técnicos y financieros, los mismos que serán utilizados en
las convocatorias de los procesos de adquisición.
Resultados:
1. Se definirán las reglas para la invitación y evaluación de propuestas/ofertas

serán definidas acorde con las políticas y estrategias de adquisición.
2. Se recolectarán los requerimientos técnicos y no técnicos iniciales serán

recogidos para acompañar a las convocatorias de los procesos de adquisición;
3. Se establecerá los términos de referencia del acuerdo (contractuales) y las

condiciones para las convocatorias de los procesos de adquisición, serán
establecidas;
4. Se definirán los términos de referencia financieros para costos y pagos para

las convocatorias de los procesos de adquisición;
5. Se definirán los términos de referencia del proyecto para las convocatorias

de los procesos de adquisición;
6. Se definirán los términos de referencia técnicos para las convocatorias de

los procesos de adquisición;
7. Se preparará y publicará una convocatoria del proceso de adquisición de

acuerdo con las políticas de adquisición, las mismas que cumplen con las leyes,
requerimientos y políticas nacionales e internacionales.
PERUANA 179 de 189
H.1.9 Calificación del proveedor
Propósito:
El propósito del proceso de calificación del proveedor es evaluar y determinar si el potencial

proveedor(es) tiene la calificación requerida para presentarse al proceso de evaluación de la
propuesta/oferta. En este proceso, los antecedentes técnicos, el sistema de calidad, el servicio,
la capacidad de apoyo al usuario, etc. será evaluado.
Resultados:
1. Se establecerán los criterios para la calificación de proveedores.
2. Se realizará la determinación de capacidades de los proveedores como algo

necesario;
3. Se preseleccionarán los proveedores que posean la calificación requerida

para la evaluación de ofertas;
4. Se identificará y evaluará cualquier incumplimiento;
5. Se evaluarán y realizarán las acciones correctivas requeridas por el

adquiriente.
H.1.10 Evaluación de propuestas
Propósito:
El propósito del proceso de evaluación de propuestas es evaluar las propuestas/ofertas de

solución y/o productos preelaborados (OTS) para iniciar las negociaciones contractuales o
acuerdos.
PERUANA 180 de 189
Resultados:
Como resultado de la implementación exitosa del proceso de evaluación de propuestas:
1. Se evaluará la solución propuesta u ofertada contra los requerimientos de la

convocatoria del proceso de adquisición;
2. Se establecerán criterios para calificar productos preelaborados (OTS) en

donde éstos serán ofrecidos como parte de una solución propuesta u ofertada;
3. Se evaluarán los productos preelaborados (OTS) necesariamente contra un

plan definido para determinar el grado en que encajan con las necesidades y
expectativas de los adquirientes;
4. Se invitará al proveedor de la solución propuesta u ofertada exitosa a

participar en la negociación contractual o acuerdo.
H.1.11 Acuerdo contractual
Propósito:
El propósito del proceso de acuerdo contractual es negociar y aprobar un contrato/acuerdo

que claramente y sin ambigüedades especifique las expectativas, responsabilidades, productos
intermedios, entregables y obligaciones tanto para el proveedor como para el adquiriente.
Resultados:
1. Se negociará, aprobará y adjudicará un contrato/acuerdo revisado al

proveedor(es);
2. Se revisarán y considerarán para ser incluidos en las condiciones del

contrato/acuerdo los mecanismos para el monitoreo de la capacidad y performance
de los proveedores y para la mitigación de riesgos identificados;
PERUANA 181 de 189
3. Se notificará a los postores y ofertantes el resultado del proceso de

evaluación seleccionada.
H.1.12 Monitoreo del proveedor
Propósito:
El propósito del proceso de monitoreo del proveedor monitorear y facilitar la integración de

las actividades del proveedor bajo la conducción del proyecto de adquisición con los
requerimientos relevantes y enfoques de gestión relevantes.
Resultados
Como resultado de la implementación exitosa del proceso de monitoreo del proveedor:
1. Se conducirán las actividades conjuntas entre el adquiriente y el proveedor

de ser necesario;
2. Se intercambiará información y datos en proceso regularmente con el

proveedor;
3. Se monitoreará la performance del proveedor en relación a los

requerimientos acordados;
4. Se registrarán los problemas y se les hará seguimiento hasta su resolución.
H.1.13 Aceptación
Propósito:
El propósito del proceso de aceptación es aprobar y aceptar el producto constituido basado en

los criterios de aceptación. El proceso incluirá un enfoque planificado e integrado que reduce
la duplicación de actividades entre el proveedor y el adquiriente.
PERUANA 182 de 189
Resultados:
1. Se realizará la validación y/o verificación en base a una estrategia de

aceptación debidamente planificada y documentada;
2. Se realizará la aceptación en base a la estrategia de adquisición y será

conducida de acuerdo con los requerimientos acordados;
3. Se evaluará el producto entregado en base a los requerimientos acordados;
4. Se confirmarán los detalles de garantía, de ser necesarios.
NOTA: La ISO/IEC 14598 puede ser una base adecuada para evaluación de productos.
H.1.14 Cierre del contrato
Propósito:
El propósito del proceso de cierre del contrato es asegurar que toda la información detallada
relacionada a la ejecución y finalización del proyecto sea recopilada y coordinada a través de
todos los grupos involucrados.
Resultados:
1. Se acordarán la finalización de los pagos y el cronograma de futuros pagos;
2. Se confirmará la seguridad de la información confidencial tanto del

proveedor como del adquiriente;
3. Se efectuará el intercambio de información de resultados sobre la

adquisición entre los grupos involucrados;
PERUANA 183 de 189
4. Se evaluarán los resultados de aspectos contractuales, técnicos y financieros

del proyecto en base a los requerimientos y/u objetivos originales;
5. Se revisará el desempeño de todos los grupos involucrados;
6. Se archivará la información relevante al proyecto de una manera asequible a

futuras adquisiciones y mejoras.
H.1.15 Relación con el proveedor
Propósito:
El propósito del proceso de relación con el proveedor es mejorar la relación adquiriente-

proveedor en términos de calidad de servicio y el beneficio para la inversión realizada para así
obtener un mejor entendimiento de las necesidades de ambas partes.
Resultados:
1. Se establecerán las relaciones con proveedores que son relevantes para las
actuales y futuras necesidades;
2. Se definirán la conducción y coordinación de relaciones;
3. Se evidenciará un claro entendimiento de las relaciones que son muy

importantes para lograr objetivos de negocio;
4. Se identificarán los beneficios potenciales para implementar relaciones y

riesgos recíprocos de no cambio;
5. Se revisará y monitoreará la efectividad permanente de relaciones con el

proveedor..
PERUANA 184 de 189
H.1.16 Relación con el usuario
Propósito:
El propósito del proceso de relación con el usuario es mejorar la relación adquiriente-usuario

en términos de calidad de servicio y el beneficio para la inversión realizada para así obtener
un mejor entendimiento de las necesidades de ambas partes.
Resultados:
1. Se definirá la gestión y coordinación de relaciones;
2. Se evidenciará un claro entendimiento de las relaciones que son muy

importantes para lograr objetivos de negocio;
3. Se identificarán beneficios potenciales para implementar relaciones y riesgos

recíprocos de no cambio;
4. Se revisará y monitoreará la efectividad permanente de relaciones con el

usuario.
H.1.17 Administración financiera
Propósito:
El propósito del proceso de administración financiera es asegurar que los costos y

presupuestos para adquisiciones sean identificados y administrados, alineados con los planes
y objetivos acordados.
PERUANA 185 de 189
Resultados:
1. Se establecerán y mantendrán los planes y objetivos financieros;
2. Se elaborarán y aprobarán los presupuestos;
3. Se mantendrán los registros para satisfacer requerimientos de auditoría

financiera;
4. Se comunicarán los actuales desembolsos del proyecto a los responsables de

la administración de proyectos;
5. Se reportarán y analizarán las diferencias entre desembolsos planificados y

reales;
6. Se tomarán decisiones para asegurar que los objetivos financieros estén a

cargo de personal responsable.
H.2 Tareas y actividades del proceso de adquisición
H.2.1 Proceso de adquisición
Lista de actividades. Las siguientes actividades se adicionan al proceso de adquisición:
a) Cierre del contrato
b) Política de adquisición
c) Administración de relaciones con el proveedor
d) Administración de relaciones con el usuario
e) Administración financiera
PERUANA 186 de 189
H.2.1.1 Cierre del Contrato
Lista de actividades. Las siguientes actividades se adicionan al proceso de adquisición:
5.1.6 Cierre del contrato: Esta actividad consiste en las siguientes tareas:
En adición a las actividades normales definidas en la cláusula 7.1.5 el adquiriente asegurará

que lo siguiente sea satisfecho:
a) La finalización de los pagos es acordada y programada;
b) Toda la información confidencial proporcionada por el proveedor será

confirmada como segura;
c) El intercambio de la información de adquisición es realizada entre las partes

relevantes;
d) Los resultados generales del contrato, del proyecto, los aspectos técnicos y
financieros del proyecto de adquisición serán evaluados en base a los objetivos y/o
requerimientos originales.
H.2.1.2 Política de adquisición
5.1.7 Política de adquisición: Esta actividad consiste en las siguientes tareas:
5.1.7.1 El adquiriente establecerá la necesidad de implementar una política común de

adquisiciones a través de toda la organización. La política de adquisición debe considerar las
metas comunes de alto nivel, las necesidades de adquisición y los métodos para implementar
éstos en proyectos de adquisición.
5.1.7.2 Para definir una efectiva política de adquisición, lo siguiente deberá ser
considerado:
PERUANA 187 de 189
a) El fundamento de la elección o preferencia por tecnologías, procesos, métodos,

vendedores, estándares y regulaciones legales para optimizar las adquisiciones;
b) Los recursos, competencias y habilidades necesarias para administrar

adquisiciones, incluidas habilidades de tipo contractual, técnico, financiero, legal y de
administración de proyectos;
c) Los estándares de calidad a ser definidos;
d) Las relaciones en relación con proveedores, usuarios y demás grupos

afectados.
H.2.1.3 Administración de relaciones con el proveedor
5.1.8 Administración de relaciones con el proveedor: Esta actividad consiste en

las siguientes tareas:
5.1.8.1 La función de adquisición en la organización definirá una política respecto a la

totalidad de relaciones relevantes con los proveedores respecto a sus actuales y futuras
necesidades. El objetivo general para implementar las relaciones adquiriente-proveedor en
términos de servicio y beneficio de la inversión es lograr un mejor entendimiento de las
necesidades de ambas partes.
5.1.8.2 Es reconocido que en algunas situaciones contractuales, especialmente en

sectores del gobierno o de defensa, las políticas respecto a las relaciones con los proveedores
son bastante limitadas, sin embargo en la mayoría de industrias hay una gran movilización
hacia las relaciones estratégicas con los proveedores especialmente con la llegada del
abastecimiento electrónico.
5.1.8.3 Como parte de la definición de una política, lo siguiente debe ser considerado:
a) Regulaciones y/o políticas nacionales e internacionales sobre abastecimiento;
b) Conducción y coordinación de relaciones;
c) Beneficios potenciales de implementar relaciones y riesgos recíprocos de no

cambio;
PERUANA 188 de 189
d) Revisión y monitoreo de la efectividad de las relaciones con el proveedor.
H.2.1.4 Administración de relaciones con el usuario
5.1.9 Administración de relaciones con el usuario: Esta actividad consiste en las

siguientes tareas:
5.1.9.1 La función de adquisición en la organización definirá una política respecto la

totalidad de relaciones relevantes con los usuarios respecto a sus actuales y futuras
necesidades. El objetivo general para implementar las relaciones adquiriente-usuario en
términos de servicio y beneficio de la inversión es lograr un mejor entendimiento de las
necesidades de ambas partes.
5.1.9.2 Como parte de la definición de una política, lo siguiente debe ser considerado:
a) Gestión y coordinación de relaciones;
b) Beneficios potenciales de implementar relaciones y riesgos recíprocos de no

cambio;
c) Revisión y monitoreo de la efectividad de las relaciones con el usuario.
H.2.1.5 Administración financiera
5.1.10 Administración financiera: Esta actividad consiste en las siguientes tareas:
5.1.10.1 La organización debe asegurar una administración financiera sana por sobre
todo proyecto de adquisición. El objetivo general es asegurar que los costos y presupuestos
para adquisiciones son identificados y gestionados alineados con los acuerdos y objetivos
acordados. La administración financiera generalmente divide las responsabilidades entre las
diferentes funciones de la organización.
5.1.10.2 Para conseguir una administración financiera sana, lo siguiente se debe llevar a
cabo:
PERUANA 189 de 189
a) Objetivos y planes financieros deben ser establecidos y mantenidos;
b) Presupuestos deben ser elaborados y aprobados;
c) Registros deben ser mantenidos;
d) Los gastos del proyecto deben ser comunicados a los responsables de la

administración del proyecto;
e) Diferencias entre los gastos planificados y reales deben ser reportados y

analizados;
Las decisiones deben ser tomadas para asegurar que los objetivos financieros sean
cumplidos.
PERUANA 2008
Comisión de Normalización y de Fiscalización de Barreras Comerciales No Arancelarias - INDECOPI
Calle De La Prosa 138, San Borja (Lima 41) Apartado 145 Lima, Perú
EDI. Tecnología de la información. Técnicas de seguridad.

Sistemas de gestión de seguridad de la información.
Requisitos
EDI. Information technology. Security techniques. Information security management systems. Requirements
(EQV. ISO/IEC 27001:2005 Information technology -- Security techniques -- Information security

management systems – Requirements)
2008-12-12
1ª Edición
R.0042-2008/INDECOPI-CNB. Publicada el 2009-01-11 Precio basado en 49 páginas

I.C.S: 35.040 ESTA NORMA ES RECOMENDABLE
Descriptores: Administración de seguridad de la información, información.
PROHIBIDA LA REPRODUCCIÓN TOTAL O PARCIAL

ÍNDICE
página
ÍNDICE i
PREFACIO ii
INTRODUCCIÓN iv
1. ALCANCE 1
2. REFERENCIAS NORMATIVAS 2
3. TÉRMINOS Y DEFINICIONES 3
4. SISTEMA DE GESTIÓN DE SEGURIDAD DE LA INFORMACIÓN 5
5. RESPONSABILIDAD DE LA GERENCIA 14
6. AUDITORÍAS INTERNAS DEL ISMS 16
7. REVISIÓN GERENCIAL DEL ISMS 17
8. MEJORA DEL ISMS 19
9. ANTECEDENTES 21
ANEXO
ANEXO A 22
ANEXO B 43
ANEXO C 45
BIBLIOGRAFÍA 49
i
PREFACIO
A. RESEÑA HISTÓRICA
A.1 La presente Norma Técnica Peruana ha sido elaborada por el Comité

Técnico Permanente de Codificación e Intercambio Electrónico de Datos (EDI),
mediante el Sistema 1 o Adopción, durante los meses de mayo a octubre del 2008,
utilizando como antecedente la ISO/IEC 27001:2005 Information technology – Security
techniques – Information security management systems – Requirements.
A.2 El Comité Técnico de Normalización de Codificación e Intercambio

Electrónico de Datos – EDI presentó a la Comisión de Normalización y de Fiscalización
de Barreras Comerciales No Arancelarias -CNB-, con fecha 2008-10-22, el PNTP-
ISO/IEC 27001:2008, para su revisión y aprobación, siendo sometido a la etapa de
Discusión Pública el 2008-11-13. No habiéndose presentado observaciones fue
oficializado como Norma Técnica Peruana PNTP-ISO/IEC 27001:2008 EDI.
Tecnología de la información. Técnicas de seguridad. Sistemas de gestión de seguridad
de la información. Requisitos, 1ª Edición, el 11 de enero de 2009.
A.3 Esta Norma Técnica Peruana reemplaza a la NTP 821.101:2005 EDI.

Sistemas de gestión de seguridad de la información. Especificaciones con guía de uso y
es una adopción de la ISO/IEC 27001:2005. La presente Norma Técnica Peruana
presenta cambios editoriales referidos principalmente a terminología empleada propia
del idioma español y ha sido estructurada de acuerdo a las Guías Peruanas GP 001:1995
y GP 002:1995.
B. INSTITUCIONES QUE PARTICIPARON EN LA ELABORACIÓN

DE LA NORMA TÉCNICA PERUANA
Secretaría EAN PERU
Presidente Marcos Suárez
Secretaria Mary Wong
ii
ENTIDAD REPRESENTANTE
DISTRIBUIDORA MAYORISTA SYMBOL S.A. Deyanira Villanueva

Walter Equizabel
DROKASA PERU S.A. Juan Cruz Valdez
E. WONG S.A. Marcela Aparicio

Rolando Bartra
FOLIUM S.A.C. Roberto Huby
IBC SOLUTIONS PERU S.A.C. Oscar Velasquez

Daniella Orellana
ITS CONSULTANTS S.A.C. Ricardo Dioses
OFICINA DE NORMALIZACION PREVISIONAL Roberto Puyó
PONT. UNIV. CATOLICA DEL PERU Viktor Khlebnikov

Willy Carrera
PRESIDENCIA DEL CONSEJO Max Lazaro

DE MINISTROS Cesar Vilchez
PROCTER & GAMBLE DEL PERU S.A. Javier Kameya
SUPERINTENDENCIA DE ADMINISTRACION Daniel Llanos

TRIBUTARIA - SUNAT
TECNOLOGÍA FLEXOGRAFICA S.A. Luis Chávez Saavedra
TCI S.A. Renzo Alcántara
UNILEVER ANDINA PERU S.A. Rolando Rivadeneira
GS1 PERU Milagros Dávila

Tatiana Peña
iii
INTRODUCCIÓN
0.1 Aspectos generales
Esta Norma Técnica Peruana de Seguridad de la Información ha sido preparada con el

fin de ofrecer un modelo para establecer, implementar, operar, monitorear, mantener y
mejorar un efectivo Sistema de Gestión de Seguridad de la Información ISMS, por sus
siglas en Inglés (Information Security Management System). La adopción de un ISMS
debe ser una decisión estratégica para una organización. El diseño e implementación del
ISMS de una organización está influenciado por las necesidades y objetivos del negocio,
requisitos de seguridad, procesos, tamaño y estructura de la organización. Se espera que
éstos y sus sistemas de soporte cambien a lo largo del tiempo, así como que las
situaciones simples requieran soluciones ISMS simples.
Esta Norma Técnica Peruana puede usarse en el ámbito interno y externo de las
organizaciones.
0.2 Enfoque de proceso
Esta Norma Técnica Peruana promueve la adopción de un enfoque del proceso para
establecer, implementar, operar, monitorear, mantener y mejorar la efectividad de un
ISMS en la organización.
Una organización debe identificar y administrar varias actividades con el fin de

funcionar efectivamente. Cualquier actividad que administre y use recursos para lograr
la transformación de entradas en salidas, puede ser considerado un proceso. Con
frecuencia la salida de un proceso se convierte en la entrada del proceso siguiente.
La aplicación de un sistema de procesos dentro de una organización, junto con la

identificación e interacciones de estos procesos y su administración se define como un
“enfoque de proceso”.
El enfoque de proceso alienta a sus usuarios a enfatizar la importancia de:
a) entender los requisitos de seguridad de información de negocios y la

necesidad de establecer políticas y objetivos para la seguridad de la información;
iv
b) implementar y operar controles en el contexto de administrar el riesgo
total del negocio de una organización;
c) monitorear y revisar el desempeño y efectividad del ISMS; y
d) mejoramiento continuo basado en la medición de objetivos.
El modelo conocido como “Planear-Hacer-Verificar-Actuar” - PDCA (Plan-Do-Check-

Act), por sus siglas en inglés, puede aplicarse a todos los procesos ISMS. La Figura 1
ilustra cómo un ISMS toma como entrada los requisitos y expectativas de seguridad de
la información de las partes interesadas y a través de las acciones y procesos necesarios
genera productos de seguridad de la información (es decir: gestión de la seguridad de la
información) que cumple estos requisitos y expectativas. La Figura 1 también ilustra los
enlaces en los procesos presentados en los capítulos 4, 5, 6, 7 y 8.
La adopción del modelo PDCA también reflejará los principios como se establecieron
en la pautas de OECD (2002)1 para la gobernabilidad de los sistemas y redes de la
seguridad de información. Esta Norma Técnica Peruana provee un modelo para
implementar los principios en las pautas que gobiernan la evaluación del riesgo, el
diseño e implementación de la seguridad, la gestión de seguridad y la reevaluación.
EJEMPLO 1
Un requisito pudiera ser aquel que las brechas en la seguridad de la información no

causen serios daños financieros y/o dañen la imagen de la organización.
EJEMPLO 2
Una expectativa podría ser que si ocurriera un incidente serio – que afecte el web site
del negocio de una organización – debe existir personal capacitado en procedimientos
adecuados para minimizar el impacto.
1
OECD Guía para la seguridad de los Sistemas de Información y Redes – Hacia una cultura de seguridad.
Paris: OECD, Julio 2002. www.oecd.org
v
Planear
Establecer el
ISMS
Partes Implementar Ciclo de Mantener y Partes

Hacer y Operar el desarrollo, mejorar el Actuar
Interesadas ISMS mantenimiento ISMS Interesadas
y mejora
Monitorear
Requisito y y revisar el
expectativas de ISMS Gestión de la
seguridad de Seguridad de la
Verificar
información Información
FIGURA 1 – Modelo PDCA aplicado al proceso ISMS
Planear (establecer el Establecer las políticas, objetivos, procesos y procedimientos

ISMS) de seguridad relevantes para administrar el riesgo y mejorar la
seguridad de la información para obtener resultados de
acuerdo con las políticas y objetivos de la organización.
Hacer (implementar y Implementar y operar las políticas, controles, procesos y
operar el ISMS) procedimientos de seguridad.
Verificar (monitorear Monitorear y evaluar el funcionamiento de los procesos con
y revisar el ISMS) respecto a las políticas, objetivos y experiencia práctica de
seguridad, informando sobre los resultados obtenidos a la
gerencia para su revisión.
Actuar (mantener y Tomar acciones correctivas y preventivas basándose en los
mejorar el ISMS) resultados de la revisión gerencial para alcanzar la mejora
continua del ISMS.
vi
0.3 Compatibilidad con otros sistemas de gestión
Esta Norma Técnica Peruana está alineada con la ISO 9001:2000 y la ISO 14001:2004
con el fin de respaldar una implementación y operación consistente e integrada con las
normas de gestión afines. Un sistema de gestión convenientemente diseñado puede
satisfacer así los requisitos de todos estos estándares. Tabla C.1, ilustra la relación entre
los capítulos de esta norma, ISO 9001:2000 y la ISO 14001:2004.
Esta Norma Técnica Peruana está diseñada para hacer posible que una organización se
alinee o integre su ISMS con los requisitos de los sistemas de gestión relacionados.
---oooOooo---
vii
PERUANA 1 de 49
EDI. Tecnología de la información. Técnicas de seguridad.

Sistemas de gestión de seguridad de la información.
Requisitos
IMPORTANTE: Esta Norma Técnica Peruana no pretende incluir todos los términos necesarios para un
contrato. Los usuarios son responsables de su correcta aplicación. Cumplir con una norma no confiere en sí
mismo inmunidad de las obligaciones legales.
1. ALCANCE
Esta Norma Técnica Peruana cubre todo los tipos de organizaciones (como por ejemplo:
empresas comerciales, agencias de gobierno y organizaciones sin fines de lucro). Esta NTP
especifica los requisitos para establecer, implementar, operar, monitorear, revisar, mantener
y mejorar un ISMS documentado dentro del contexto de los riesgos de negocio de la
organización. Especifica los requisitos para implementar los controles de seguridad
adaptado a las necesidades individuales de las organizaciones o partes de las mismas.
El ISMS está diseñado para garantizar y proporcionar controles de seguridad adecuados

que protejan los activos de información, brindando confianza a las partes interesadas.
NOTA 1: Las referencias de “negocio” en esta Norma Técnica Peruana deben ser interpretadas
ampliamente para representar las actividades que son base para los propósitos de la existencia de la
organización.
NOTA 2: La ISO/IEC 17799 provee pautas de implementación que pueden ser utilizadas cuando se
designen controles.

PERUANA 2 de 49
1.2 Aplicación
Los requisitos establecidos en esta NTP son generales y tienen la intención de aplicarse a
todas las organizaciones, sin tomar en cuenta el tipo, tamaño y naturaleza del negocio.
Cuando una organización reclama conformidad con esta norma, no es aceptable excluir
cualquiera de los requisitos especificados en los capítulos 4, 5, 6, 7 y 8.
Cualquier exclusión de los controles necesarios para satisfacer el criterio de aceptación de

los riesgos necesarios, debe justificarse y las necesidades de evidencias que debe ofrecerse
en cuanto a que las personas responsables han aceptado adecuadamente los riesgos
asociados. Cuando se realiza exclusiones de controles, los reclamos de conformidad de esta
NTP no son aceptables a menos que esas exclusiones no afecten la capacidad y/o
responsabilidad de la organización para ofrecer seguridad de la información que cumple los
requisitos de seguridad establecidos por la evaluación de riesgo y requisitos reglamentarios
aplicables.
NOTA: Si una organización ya posee un sistema operativo de gestión de procesos de negocio (por
ejemplo en relación con la ISO 9001 o ISO 14001), es preferible, en la mayoría de los casos, satisfacer
los requisitos de esta NTP dentro de los sistemas de gestión existentes.
2. REFERENCIAS NORMATIVAS
Las siguientes normas contienen disposiciones que al ser citadas en este texto, constituyen
requisitos de esta Norma Técnica Peruana. Las ediciones indicadas estaban en vigencia en
el momento de esta publicación. Como toda Norma está sujeta a revisión, se recomienda a
aquellos que realicen acuerdos en base a ellas, que analicen la conveniencia de usar las
ediciones recientes de las normas citadas seguidamente. El Organismo Peruano de
Normalización posee la información de las Normas Técnicas Peruanas en vigencia en todo
momento.

PERUANA 3 de 49
2.1 Normas Técnicas Internacionales
2.1.1 ISO/IEC 17799:2005 Information technology – Security techniques -

Code of practice for information security
management
3. TÉRMINOS Y DEFINICIONES
Para los fines de esta Norma Técnica Peruana, se aplican los siguientes términos y
definiciones:
3.1 activo: Algo que presenta valor para la organización.

[ISO/IEC 13335-1:2004]
3.2 disponibilidad: Garantizar que los usuarios autorizados tengan acceso a la

información y activos asociados cuando sea necesario.
[ISO/IEC 13335-1:2004]
3.3 confidencialidad: Garantizar que la información sea accesible únicamente

para quienes tengan acceso autorizado.
[ISO/IEC 13335-1:2004]
3.4 seguridad de la información: Preservar la confidencialidad, integridad y

disponibilidad de la información; además, también pueden ser involucradas otras
características como la autenticación, responsabilidad, no-repudio y fiabilidad.
[ISO/IEC 17799:2005]
3.5 evento de la seguridad de la información: Ocurrencia identificada en un

sistema, servicio o red indicando una posible brecha de la política de seguridad de la
información o falla de las salvaguardas o una situación desconocida previa que puede ser
relevante.
[ISO/IEC TR 18044:2004]

PERUANA 4 de 49
3.6 incidente de la seguridad de la información: Una serie de eventos no

deseados que tienen una probabilidad significativa de comprometer operaciones del
negocio y amenazar la seguridad de la información.
[ISO/IEC TR 18044:2004]
3.7 sistema de gestión de seguridad de la información – ISMS: Es la parte

del sistema integral de gestión, basado en un enfoque del riesgo del negocio para
establecer, implementar, operar, monitorear, revisar, mantener y mejorar la seguridad de la
información.
NOTA: El sistema de gestión incluye la estructura organizacional, políticas, actividades de

planificación, responsabilidades, prácticas, procedimientos, procesos y recursos.
3.8 integridad: Salvaguardar la exactitud e integridad de la información y

activos asociados.
[ISO/IEC TR 13335-1:2004]
3.9 riesgo residual: Riesgo remanente después de un tratamiento del riesgo.

[ISO/IEC Guide 73:2002]
3.10 aceptación del riesgo: Decisión de aceptar el riesgo.

3.11 análisis del riesgo: Uso sistemático de información para identificar

amenazas y estimar el riesgo.
3.12 estimación del riesgo: Proceso total de análisis y evaluación del riesgo.
3.13 evaluación del riesgo: Proceso de comparación del riesgo estimado frente
al criterio de riesgo para determinar el significado del riesgo.

PERUANA 5 de 49
3.14 gestión del riesgo: Actividades coordinadas para dirigir y controlar el riesgo
en una organización.
3.15 tratamiento del riesgo: Proceso de selección e implementación de

controles para minimizar el riesgo.
3.16 declaración de aplicabilidad: Documento que describe los objetivos de

control y los controles que son relevantes y aplicables al ISMS de la organización.
NOTA: los objetivos y controles están basados en los resultados y conclusiones de los procesos de
evaluación del riesgo y tratamiento del riesgo, requisitos legales o regulatorios, obligaciones
contractuales y los requisitos de negocio de la información de seguridad de la organización.
4. SISTEMA DE GESTIÓN DE SEGURIDAD DE LA INFORMACIÓN
4.1 Requisitos generales
La organización desarrollará, implementará, operará, monitoreará, revisará, mantendrá y

continuará la mejora de un ISMS documentado dentro del contexto de las actividades y
riesgos totales de la organización. Para los fines de esta NTP, el proceso usado se basa en
el modelo PDCA mostrado en la Figura 1.

PERUANA 6 de 49
4.2 Establecimiento y administración del ISMS
4.2.1 Establecimiento del ISMS
La organización realizará lo siguiente:
a) Definir el alcance y límites del ISMS en términos de las características del

negocio, la organización, su localización, activos y tecnología e incluyendo detalles
y justificaciones para cualquier exclusión del alcance (véase 1.2).
b) Definir una política ISMS en términos de las características del negocio, la

organización, su localización, activos y tecnología que:
1) incluye un marco para establecer sus objetivos y establece un sentido total

de dirección y principios para acción con miras a la seguridad de la información;
2) considera requisitos de negocios, legales o regulatorios y obligaciones de
seguridad contractual;
3) establece el contexto estratégico organizacional y la gestión del riesgo en el
cual tiene lugar el establecimiento y mantenimiento del ISMS;
4) establece criterios frente a los cuales se evaluará el riesgo y se definirá la
estructura de evaluación del riesgo [véase 4.2.1c)];
5) ha sido aprobado por la gerencia.
NOTA: Para propósitos de esta Norma Técnica Peruana, la política de ISMS es considerada como un
conjunto de la política de la seguridad de información. Estas políticas pueden ser descritas en otro
documento.
c) Definir un enfoque sistemático para la evaluación del riesgo en la

organización.
1) Identificar una metodología de evaluación del riesgo que se adecue al ISMS

y a requisitos legales y regulatorios de la información de seguridad del negocio
identificada.
2) Determinar criterios para aceptar e identificar los niveles aceptables del
riesgo [véase 5.1f].
La metodología de evaluación de riesgos seleccionada debe asegurar que la

evaluación de riesgos produzca resultados comparables y reproducibles.

PERUANA 7 de 49
NOTA: Existen diferentes metodologías para una evaluación de riesgos. Los ejemplos de
metodologías de evaluación de riesgos son discutidas en la ISO/IEC TR 13335-3.
d) Identificar los riesgos.
1) Identificar los activos dentro del alcance del ISMS y los propietarios2 de
estos activos.
2) Identificar las amenazas a esos activos.
3) Identificar las vulnerabilidades que podrían explotarse mediante estas
amenazas.
4) Identificar los impactos de pérdidas de confidencialidad, integridad y
disponibilidad sobre los activos.
e) Analizar y Evaluar los riesgos.
1) Evaluar los daños comerciales que podrían resultar de una falla de

seguridad, considerando las consecuencias potenciales de una pérdida de
confidencialidad, integridad o disponibilidad de los activos.
2) Evaluar las posibilidades de falla de seguridad, teniendo en cuenta las
amenazas, vulnerabilidades e impactos asociados con estos activos y los controles
implementados actualmente.
3) Estimar los niveles de los riesgos.
4) Determinar si el riesgo es aceptable o requiere tratamiento usando el criterio
establecido en 4.2.1c)2).
f) Identificar y evaluar opciones para el tratamiento del riesgo.
Las posibles acciones incluyen:
1) aplicar los controles apropiados;

2) aceptar riesgos conciente y objetivamente, siempre y cuando satisfagan
claramente la política de la organización y el criterio para la aceptación del riesgo
[véase 4.2.1c)2)];
3) evitar riesgos; y
4) transferir los riesgos de negocio asociados a otras partes, por ejemplo:
aseguradores, proveedores.
g) Seleccionar objetivos de control y controles para el tratamiento del riesgo.
2
El termino “propietario” identifica a un individuo o entidad que aprueba la responsabilidad por la gestión
por controlar la producción, desarrollo, mantenimiento, uso y seguridad de los activos. El término
“propietario” no significa que la persona tiene algún derecho de propiedad realmente sobre el activo.

PERUANA 8 de 49
Se seleccionará los objetivos de control y controles adecuados y se justificará en base

a las conclusiones de la evaluación y proceso de tratamiento de riesgo. Esta selección
debe tomar en cuenta el criterio para aceptación de riesgos [véase 4.2.1c)2)] así como
los requisitos legales, regulatorios y contractuales.
Los objetivos de control y controles del Anexo A deben ser seleccionados como parte
del proceso así como adecuados para cubrir los requisitos identificados.
Los objetivos de control y los controles que figuran en el Anexo A no son

exhaustivos y también puede seleccionarse objetivos de control y controles
adicionales.
NOTA: El Anexo A contiene una lista comprensible de objetivos de control que han sido encontrados
como relevantes para las organizaciones. Los usuarios de esta NTP son dirigidos a este Anexo A como
un punto de partida para la selección de controles con el fin de asegurar que no se hayan obviado
opciones de control importantes.
h) Obtener aprobación por parte de la gerencia sobre los riesgos residuales

propuestos.
i) Obtener autorización por parte de la gerencia para implementar y operar el

ISMS.
j) Prepara una declaración de aplicabilidad.
Una declaración de aplicabilidad debe ser preparada y debe incluir lo siguiente:
1) los objetivos de control y los controles seleccionados en 4.2.1g) y las

razones para su selección;
2) los objetivos de control y los controles implementados actualmente [véase
4.2.1e)2)]; y
3) se registrará la exclusión de cualquier objetivo de control y controles que
figuran en el Anexo A así como su justificación.
NOTA: La declaración de aplicabilidad provee un resumen de decisiones concernientes a la

evaluación de riesgos. Las exclusiones justificadas proveen una verificación cruzada de que ningún
control se ha omitido inadvertidamente.

PERUANA 9 de 49
4.2.2 Implementar y operar el ISMS
La organización debe hacer lo siguiente:
a) Formular un plan de tratamiento de riesgos que identifique la acción

administrativa adecuada, recursos, responsabilidades y prioridades para manejar los
riesgos de seguridad de la información (véase el apartado 5).
b) Implementar el plan de tratamiento de riesgos con el fin de alcanzar los

objetivos de control identificados, que incluyen la consideración de financiamiento y
asignación de roles y responsabilidades.
c) Implementar los controles seleccionados en 4.2.1g) para cumplir con los

objetivos de control.
d) Definir como medir la efectividad de los controles o grupos de control

seleccionados y especificar como estas medidas serán utilizadas para alcanzar la
efectividad en el control con el fin de producir resultados comparables y
reproducibles [véase 4.2.3c)].
NOTA: Medir la efectividad de los controles permite a los gerentes y al personal determinar que tan
bien los controles logran los objetivos de control planeados.
e) Implementar programas de capacitación y concientización (véase 5.2.2).
f) Administrar las operaciones del ISMS.
g) Administrar los recursos para el ISMS (véase 5.2)
h) Implementar procedimientos y otros controles capaces de hacer posible la

inmediata detección y respuesta a los incidentes de seguridad (véase 4.2.3a)).

PERUANA 10 de 49
4.2.3 Monitorear y revisar el ISMS
La organización debe hacer lo siguiente:
a) Ejecutar procedimientos de monitoreo y otros controles para:
1) detectar inmediatamente errores en los resultados de procesamiento;

2) identificar inmediatamente brechas de seguridad e incidentes;
3) hacer posible que la gerencia determine si las actividades de seguridad
delegadas a personas o implementadas mediante el área de tecnología de la
información se realizan de acuerdo a lo planeado;
4) ayudar a detectar eventos de seguridad y desde ahí prevenir los incidentes de
seguridad mediante el uso de indicadores; y
5) determinar si las acciones realizadas para resolver una violación de
seguridad fueron efectivas.
b) Emprender revisiones regulares de la efectividad del ISMS (incluyendo

cumplir con la política de seguridad, objetivos y revisar los controles de seguridad)
considerando los resultados de auditorías de seguridad, incidentes, sugerencias y
retroalimentación de todas las partes interesadas.
c) Medir la efectividad de los controles para verificar que se tomaron en cuenta

los requisitos de seguridad.
d) Revisar la evaluación de riesgos en intervalos planificados y revisar el nivel

del riesgo residual y riesgo aceptable, tomando en cuenta los cambios a:
1) la organización;
2) la tecnología;
3) los objetivos y procesos del negocio;
4) amenazas identificadas;
5) efectividad de los controles implementados; y
6) eventos externos, tales como cambios en el ambiente legal o regulatorio,
cambios en obligaciones contractuales y en el clima social;

PERUANA 11 de 49
e) Realizar auditorías internas de ISMS en intervalos planificados (véase el

capítulo 6).
NOTA: Las auditorías internas son conducidas por, o a favor de, la misma organización, para
propósitos internos.
f) Emprender un revisión administrativa del ISMS en una base para garantizar

que el alcance siga siendo el adecuado y las mejoras al proceso ISMS sean
identificadas (Véase 7.1).
g) Actualizar los planes de seguridad para tomar en cuenta los resultados

encontrados del monitoreo y revisión de las actividades.
h) Registrar acciones y eventos que podrían tener un impacto en la efectividad

o funcionamiento del ISMS (véase 4.3.3).
4.2.4 Mantener y mejorar el ISMS
La organización debe regularmente hacer lo siguiente:
a) Implementar en el ISMS las mejoras identificadas.
b) Tomar las acciones correctivas y preventivas adecuadas en conformidad con

8.2 y 8.3. Aplicar las lecciones aprendidas de las experiencias de seguridad de otras
organizaciones y las de la misma organización.
c) Comunicar las acciones y resultados a todas las partes interesadas con un

nivel de detalle apropiado a las circunstancias y cuando sea relevante, acordar la
forma de cómo proceder.
d) Garantizar que las mejoras alcancen sus objetivos planificados.

PERUANA 12 de 49
4.3 Requisitos de documentación
4.3.1 Aspectos generales
La documentación debe incluir registros de la decisiones gerenciales, asegurar que las

acciones sean trazables a estas decisiones y a las políticas y asegurar que los resultados
grabados son reproducibles.
Es importante ser capaz de demostrar la relación de los controles seleccionados con los
resultados de la evaluación de riesgos y el proceso de tratamiento de riesgos así como
subsecuentemente a las políticas y objetivos de ISMS.
La documentación del ISMS deberá incluir lo siguiente:
a) Declaraciones documentadas de la política de seguridad (véase 4.2.1b)) y

objetivos;
b) el alcance del ISMS (véase 4.2.1a));
c) los procedimientos y controles que soportan el ISMS;
d) una descripción de la metodología de evaluación del riesgo (véase 4.2.1c));
e) informe de evaluación del riesgo (véase 4.2.1c) a 4.2.1g));
f) plan de tratamiento del riesgo (véase 4.2.2b));
g) procedimientos documentados necesarios en la organización para garantizar

la planificación efectiva, funcionamiento y control de sus procesos de seguridad de la
información y describir como medir la efectividad de los controles (véase 4.2.3c));
h) registros exigidos por esta NTP (véase 4.3.3); y
i) declaración de aplicabilidad.

PERUANA 13 de 49
NOTA 1: Cuando aparece el término “procedimiento documentado” dentro de esta norma, significa
que el procedimiento está establecido, documentado, implementado y mantenido.
NOTA 2: La extensión de la documentación del ISMS puede diferir de una organización a otra
dependiendo de:
- El tamaño de la organización y el tipo de actividades; y
- El alcance y complejidad de los requisitos de seguridad y del sistema a ser administrado.
NOTA 3: Los documentos y registros pueden tener cualquier forma y tipo de medio.
4.3.2 Control de documentos
Los documentos exigidos por el ISMS estarán protegidos y controlados. Se establecerá un

procedimiento documentado para definir las acciones administrativas necesarias para:
a) aprobar documentos para su adecuación antes de la emisión;
b) revisar y actualizar los documentos que sean necesarios y reaprobar

documentos;
c) asegurar que los cambios y el estado de la versión actual de los documentos

sean identificados;
d) asegurar que las versiones más recientes de los documentos pertinentes estén
disponibles en los puntos de uso;
e) asegurar que los documentos sean legibles y fácilmente identificables;
f) asegurar que los documentos se encuentren disponibles para quienes los

necesiten y sean transferidos, almacenados y dispuestos en concordancia con los
procedimientos aplicables a su clasificación;
g) asegurar que los documentos de origen externo sean identificados;
h) asegurar que la distribución de documentos sea controlada;
i) prevenir el uso no intencional de documentos obsoletos; y
j) aplicar la identificación adecuada de estos si se guardan para algún

propósito.

PERUANA 14 de 49
4.3.3 Control de registros
Se establecerán y mantendrán registros para ofrecer evidencia de conformidad con los

requisitos y el funcionamiento efectivo del ISMS. Estos registros deberán ser controlados.
El ISMS tomará en cuenta cualquier requisito legal pertinente. Los registros deben ser
legibles, fácilmente identificables y accesibles. Los controles necesarios para la
identificación, almacenamiento, protección, acceso, tiempo de retención y disposición de
registros deberán ser implementados y documentados.
Se mantendrán los registros del rendimiento del proceso como se señala en 4.2 y de todos
los incidentes de seguridad relacionados con el ISMS.
EJEMPLO:
Ejemplos de registros son los libros de visitantes, reportes de auditoría y autorización de

acceso.
5. RESPONSABILIDAD DE LA GERENCIA
5.1 Compromiso de la gerencia
La gerencia entregará evidencia de su compromiso con el establecimiento, implementación,

operación, monitoreo, revisión, mantenimiento y mejora del ISMS mediante:
a) estableciendo una política del ISMS;
b) asegurando que los objetivos y planes del ISMS sean establecidos;
c) estableciendo los roles y responsabilidades para la seguridad de la

información;

PERUANA 15 de 49
d) comunicando a la organización la importancia del cumplimiento de los

objetivos de seguridad de la información y de acuerdo a la política de seguridad de la
información, sus responsabilidades de acuerdo a ley y la necesidad de una mejora
continua;
e) brindando recursos suficientes para desarrollar, implementar, operar,

monitorear, revisar, mantener y mejorar el ISMS (véase 5.2.1);
f) decidiendo el criterio para aceptación de riesgos y el nivel de riesgo

aceptable;
g) asegurar que las auditorías internas del ISMS sean realizadas (véase capitulo
6); y
h) realizando revisiones gerenciales del ISMS (véase capítulo 7).
5.2 Administración de recursos
5.2.1 Provisión de recursos
La organización deberá determinar y brindar los recursos necesarios para:
a) establecer, implementar, hacer funcionar y mantener el ISMS;
b) asegurar que los procedimientos de seguridad de la información respalden

los requisitos de negocio;
c) identificar y atender los requisitos legales y regulatorios, obligaciones de

seguridad contractuales;
d) mantener una seguridad adecuada mediante la correcta aplicación de todos

los controles implementados;
e) llevar a cabo revisiones necesarias y aplicar las medidas correspondientes

según los resultados de estas revisiones;
f) cuando sea necesario, mejorar la efectividad del ISMS.

PERUANA 16 de 49
5.2.2 Capacitación, concientización y competencia
La organización deberá asegurar que todo el personal al cual se le asigna responsabilidades

definidas en el ISMS sea competente para realizar las tareas requeridas mediante:
a) determinando las aptitudes necesarias del personal que lleva a cabo labores
vinculadas al ISMS;
b) ofreciendo capacitación o tomando otras acciones (por ejemplo empleando

personal idóneo) para satisfacer estas necesidades;
c) evaluando la efectividad de la capacitación ofrecida y las acciones

ejecutadas; y
d) manteniendo registros de educación, capacitación, habilidades, experiencia y

calificaciones (véase 4.3.3).
La organización también debe garantizar que todo el personal pertinente tome conciencia
de la relevancia e importancia de las actividades de seguridad de la información y cómo
estas contribuyen al logro de los objetivos del ISMS.
6. AUDITORÍAS INTERNAS DEL ISMS
La organización conducirá auditorías internas del ISMS a intervalos periódicos para

determinar si los objetivos de control, controles, procesos y procedimientos identificados
de su ISMS:
a) están conformes a los requisitos de esta NTPy legislación o reglamentos

relevantes;
b) están conformes con los requisitos de seguridad de la información

identificados;

PERUANA 17 de 49
c) se han implementado y mantenido efectivamente; y
d) funcionan como se espera.
Un programa de auditoría debe planificarse tomando en consideración la condición e

importancia de los procesos y áreas a auditarse, así como los resultados de auditorías
previas. Deberá definirse los criterios, alcance, frecuencia y métodos de las auditorías. La
selección de auditores y conducción de auditorías deben garantizar objetividad e
imparcialidad en el proceso de auditoría. Los auditores no deben auditar su propio trabajo.
Las responsabilidades y requisitos para la planificación y conducción de auditorías y la
información de los resultados y mantenimiento de registros (véase 4.3.3) deberán definirse
en un procedimiento documentado.
La gerencia responsable del área que está bajo auditoría garantizará que las acciones se
ejecuten sin retrasos indebidos, con el fin de eliminar las no conformidades detectadas y
sus causas. Las actividades de mejora incluyen la verificación de las acciones tomadas y el
reporte de los resultados de verificación (véase capítulo 8).
NOTA: ISO 19011:2002, Guía para la calidad y/o gestión de sistemas de auditoría del medio
ambiente, pueden proveer una guía útil para llevar a cabo una auditoría ISMS interna.
7. REVISIÓN GERENCIAL DEL ISMS
La gerencia revisará el ISMS de la organización a intervalos planificados (al menos una

vez por año) para garantizar su idoneidad continua, adecuación y efectividad. Esta revisión
debe incluir las oportunidades de evaluación para mejora y la necesidad de cambios al
ISMS incluyendo la política y los objetivos de seguridad de la información. Los resultados
de las revisiones deben documentarse claramente y se mantendrán registros sobre las
mismas (véase el apartado 4.3.3).

PERUANA 18 de 49
7.2 Revisión: entradas
La revisión gerencial deberá incluir la información de entrada siguiente:
a) resultados de las auditorías y revisiones del ISMS;
b) retroalimentación de las partes interesadas;
c) técnicas, productos o procedimientos que podrían usarse en la organización

para mejorar el funcionamiento y efectividad del ISMS;
d) situación de las acciones preventivas y correctivas;
e) vulnerabilidad o amenazas no atendidas adecuadamente en la evaluación

previa del riesgo;
f) resultados de las medidas efectivas;
g) acciones de seguimiento de las revisiones gerenciales previas;
h) cualquier cambio que podría afectar el ISMS; y
i) recomendaciones para mejoras.
7.3 Revisión: salidas
La revisión gerencial incluirá cualquier decisión y acción relacionada con lo siguiente:
a) Mejora de la efectividad del ISMS.
b) Actualizaciones de la evaluación de riesgos y del plan de tratamiento de

riesgo.

PERUANA 19 de 49
c) Modificación de los procedimientos y controles vinculados con la seguridad

de la información, según sea necesario para responder a los eventos internos y
externos que pueden impactar en el ISMS, incluyendo cambios a:
1) requisitos de negocio;
2) requisitos de seguridad;
3) procesos de negocio que afectan los requisitos de negocio existentes;
4) marco regulatorio o legal;
5) obligaciones contractuales; y
6) niveles de riesgo y/o criterios de aceptación de riesgos.
d) Necesidades de recursos.
e) Mejoras en como se mide la efectividad de los controles;
8. MEJORA DEL ISMS
8.1 Mejora continua
La organización mejorará continuamente la efectividad de los ISMS a través del uso de la

política de seguridad de la información, objetivos de seguridad, resultados de auditorías,
análisis de eventos monitoreados, acciones correctivas y preventivas, y revisión gerencial
(véase capitulo 7).
8.2 Acciones correctivas
La organización tomará acciones para eliminar la causa de las no conformidades asociadas

con la implementación y operación del ISMS con el fin de prevenir recurrencias. Los
procedimientos documentados para las acciones correctivas se definirán como requisitos
para:
a) identificación de las no conformidades;
b) determinar las causas de las no conformidades;

PERUANA 20 de 49
c) evaluar la necesidad de acciones para asegurar que las no conformidades no

vuelvan a producirse;
d) determinar e implementar la acción correctiva necesaria;
e) registrar los resultados de las acciones tomadas (véase 4.3.3); y
f) revisar las acciones correctivas tomadas.
8.3 Acciones preventivas
La organización determinará las acciones para eliminar las causas potenciales no

conformidades con los requisitos de ISMS con el fin de prevenir su ocurrencia. Las
acciones preventivas deberán ser adecuadas al impacto de los problemas potenciales. El
procedimiento documentado para las acciones preventivas definirá los requisitos para:
a) identificar las no conformidades potenciales y sus causas;
b) evaluar la necesidad de una acción con el fin de prevenir ocurrencias de no

conformidades;
c) determinar e implementar las acciones preventivas necesarias;
d) registrar los resultados de las acciones tomadas (véase 4.3.3) y
e) revisar las acciones preventivas tomadas;
La organización debe identificar los riesgos alterados e identificar los requisitos de

acciones preventivas centrándose en aquellos significativamente alterados.
La prioridad de las acciones preventivas se determinará en base a los resultados de la

evaluación del riesgo.
NOTA: Las acciones para prevenir no conformidades con frecuencia son más económicas que las
acciones correctivas.

PERUANA 21 de 49
9. ANTECEDENTES
9.1. ISO/IEC 27001:2005 Information technology – Security techniques –

Information security management systems –
Requirements
9.2. NTP 821.101: 2005 EDI. Sistemas de gestión de seguridad de la

información – Especificaciones con guía de uso

PERUANA 22 de 49
ANEXO A
(NORMATIVO)
OBJETIVOS DE CONTROL Y CONTROLES
Los objetivos de control y los controles que figuran en la tabla A.1 se derivan y alinean
directamente con los que figuran en NTP-ISO/IEC 17799:2007, capítulos 5 a 15. Las listas
en estas tablas no son exhaustivas y la organización puede considerar que son necesarios
objetivos de control y controles adicionales. Los objetivos de control y los controles de
estas tablas deben seleccionarse como parte del proceso ISMS especificado en 4.2.1.
La NTP-ISO/IEC 17799:2006, capítulos 5 a 15 ofrecen asesoría de implementación y

pautas sobre las mejores prácticas en apoyo de los controles especificados de A.5 a A.15.
TABLA A.1 – Objetivos de control y controles
A.5 Política de seguridad
A.5.1 Política de seguridad de la información

Objetivo de control: Dirigir y dar soporte a la gestión de la seguridad de la información en
concordancia con los requisitos del negocio, las leyes y las regulaciones.
A.5.1.1 Documentos de política Control

de seguridad de la
información La gerencia deberá aprobar, publicar y comunicar a todos
los empleados y terceras partes que lo requieran.
A.5.1.2 Revisión de la política Control

de seguridad de
información La política será revisada en intervalos planificados, y en
caso de cambios que la afecten, asegurar que siga siendo
apropiada, conveniente y efectiva.

PERUANA 23 de 49
A.6 Seguridad organizacional

A.6.1 Organización interna
Objetivo de control: Gestionar la seguridad de la información dentro de la organización.
A.6.1.1 Comité de Gestión de Control
seguridad de la La gerencia debe respaldar activamente la seguridad dentro de
información la organización a través de una dirección clara, un
compromiso apropiado, recursos adecuados y conocimiento
de responsabilidades de la seguridad de información.
A.6.1.2 Coordinación de la Control
seguridad de la
información Las actividades en la seguridad de información deben ser
coordinados por representantes de diferentes partes de la
organización que tengan roles relevantes y funciones de
trabajo.
A.6.1.3 Asignación de Control
responsabilidades
sobre seguridad de la Todas las responsabilidades sobre la seguridad de
información información deben ser claramente definidas.
A.6.1.4 Proceso de Control
autorización para las
nuevas instalaciones Debe establecerse y definirse un proceso de gestión de
de procesamiento de autorización para facilitar los nuevos procesamientos
información información.
A.6.1.5 Acuerdos de Control
confidencialidad
Se debe identificar y revisar regularmente los requisitos de
confidencialidad o acuerdos de no divulgación que reflejen
las necesidades de la organización para la protección de
información.
A.6.1.6 Contacto con Control
autoridades
Se debe mantener contactos apropiados con las autorizaciones
relevantes.
A.6.1.7 Contacto con grupos Control
de interés especial
Se debe mantener contactos con grupos de interés especial u
otros foros de especialistas en seguridad así como de
asociaciones profesionales.
A.6.1.8 Revisión Control
independiente de El alcance de la organización para manejar la seguridad de
seguridad de la información, así como su implementación (como por ejemplo:
información los objetivos de control, los controles, las políticas, procesos y
procedimientos) deben ser revisados independientemente
durante intervalos planificados o cuando ocurran cambios
significativos en la implementación.

PERUANA 24 de 49
A.6.2 Seguridad del acceso a terceras partes

Objetivo de control: Mantener la seguridad de las instalaciones de procesamiento de la
información organizacional que acceden, procesan, comunican o gestionan terceros.
A.6.2.1 Identificación de Control
riesgos por el acceso
de terceros Se evaluará los riesgos asociados con el acceso a las
instalaciones de procesamiento de la información
organizacional por parte de terceros, y se implementarán
controles de seguridad adecuados antes de permitir su acceso.
A.6.2.2 Requisitos de Control
seguridad cuando se
trata con clientes Se deben identificar todos los requisitos de seguridad antes de
dar acceso a clientes a los activos o a la información de la
organización.
A.6.2.3 Requisitos de Control
seguridad en
contratos con terceros Los acuerdos que involucran el acceso, procesamiento,
comunicación o manejo de terceros de las instalaciones de
procesamiento de información organizacional o la adición de
productos o servicios a dichas instalaciones deben cubrir todos
los requisitos de seguridad necesarios.
A.7 Gestión de activos
A.7.1 Responsabilidad por los activos

Objetivo de control: Mantener la protección apropiada de los activos de la organización.
A.7.1.1 Inventario de activos Control
Se elaborará y mantendrá un inventario de todos los activos

importantes que sean claramente identificados.
A.7.1.2 Propiedad de los activos Control
Toda la información y los activos asociados con las

instalaciones de procesamiento de información deben ser
propiedad3 de una parte designada de la organización.
A.7.1.3 Uso aceptable de los Control
activos
Se deben de identificar, documentar e implementar las
reglas para el uso aceptable de los activos de información
asociados con las instalaciones de procesamiento de
información.
3
El termino “propietario” identifica a un individuo o entidad que aprueba la responsabilidad por la gestión
por controlar la producción, desarrollo, mantenimiento, uso y seguridad de los activos. El término
“propietario” no significa que la persona tiene algún derecho de propiedad realmente sobre el activo.

PERUANA 25 de 49
A.7.2 Clasificación de la información

Objetivo de control: Asegurar que los activos de información reciban un nivel de protección
adecuado.
A.7.2.1 Guías de clasificación Control
La información debe ser clasificada en términos de su

valor, requisitos legales, sensibilidad y criticidad para la
organización.
A.7.2.2 Etiquetado y tratamiento Control
de la información
Se definirá e implementará un conjunto de procedimientos
apropiados para etiquetar y manejar información de
conformidad con el esquema de clasificación adoptado por
la organización.
A.8 Seguridad en recursos humanos
A.8.1 Previo al empleo4

Objetivo de control: Asegurar que los empleados, contratistas y usuarios externos entiendan sus
responsabilidades y que estos sean adecuados a los roles para los cuales han sido considerados y
reducir así el riesgo de estafa, fraude o mal uso de las instalaciones.
A.8.1.1 Roles y Control
responsabilidades
Se definirán y documentarán los roles de seguridad y las
responsabilidades de los empleados, contratistas y usuarios
externos en concordancia con la política de seguridad de la
información de la organización.
A.8.1.2 Investigación Control
Se debe hacer un chequeo y verificación de informaciones

anteriores de todos los candidatos para empleos,
contratistas y personal externo, en concordancia con las
leyes, regulaciones y ética; y proporcional a los requisitos
del negocio, la clasificación de la información a ser
accedida y a los riesgos percibidos.
A.8.1.3 Términos y condiciones Control
de la relación laboral
Los empleados, contratistas y terceros suscribirán un
acuerdo de confidencialidad como parte de los términos y
condiciones iniciales de su empleo en donde se señalará la
responsabilidad del empleado en cuanto a la seguridad de
la información.
4
Explicación: la palabra “empleo” se utiliza aquí para cubrir las siguientes situaciones diferentes: empleo de
las personas (temporalmente o durante largo tiempo), designando roles de trabajo, cambiando roles de
trabajo, asignando contratos, y la terminación de cualquiera de estos arreglos.

PERUANA 26 de 49
A.8.2 Durante el empleo

Objetivo de control: Asegurar que todos los empleados, contratistas y usuarios externos sean
conscientes de las amenazas y riesgos en el ámbito de la seguridad de la información, y que estén
preparados para aplicar la política de seguridad de la organización en el curso de trabajo normal y
reducir el riesgo de error humano.
A.8.2.1 Gestión de Control
responsabilidades
La gerencia debe requerir a los empleados, contratistas y a
los usuarios externos aplicar la seguridad en concordancia
con las políticas y procedimientos de la organización.
A.8.2.2 Concientización, Control
educación y
entrenamiento en la Todos los empleados de la organización y, donde sea
seguridad de relevante, contratistas y usuarios externos deben recibir
información una adecuada concientización, entrenamiento y
actualizaciones regulares en los procesos y políticas
organizacionales, como acciones relevantes de su función
laboral.
A.8.2.3 Proceso disciplinario Control
Debe existir un proceso disciplinario para los empleados

que hayan cometido una violación de seguridad.
A.8.3 Finalización o cambio de empleo
Objetivo de control: Asegurar que los empleados, contratistas y usuarios externos dejen o
cambien de organización de una forma ordenada.
A.8.3.1 Responsabilidades de Control
finalización
Debe informarse sobre los incidentes de seguridad a través
de canales administrativos adecuados tan pronto como sea
posible.
A.8.3.2 Devolución de activos Control
Todos los empleados, contratistas y usuarios externos

deben realizar la devolución de los activos de la
organización que están en su posesión cuando termine su
empleo, contrato o acuerdo.
A.8.3.3 Retiro de los derechos Control
de acceso
El derecho de acceso a la información y a las instalaciones
de procesamiento de información, que se le otorga a los
empleados, contratistas y usuarios externos, debe ser
removido cuando termine su empleo, contrato o acuerdo; o
modificado ante cambios.

PERUANA 27 de 49
A.9 Seguridad física y del entorno
A.9.1 Áreas seguras

Objetivo de control: Prevenir accesos no autorizados, daños e interferencias contra los locales y la
información de la organización.
A.9.1.1 Seguridad física Control
perimetral
Las organizaciones usarán perímetros de seguridad
(barreras como paredes, puertas con control de entrada por
tarjeta o recepciones) para proteger áreas que contienen
información e instalaciones de procesamiento de
información.
A.9.1.2 Controles físicos de Control

entradas
Las áreas seguras estarán protegidas mediante controles de
acceso adecuados para garantizar que únicamente personal
autorizado pueda ingresar.
A.9.1.3 Seguridad de oficinas, Control

despachos y recursos
Se deben designar y mantener áreas seguras con el fin de
proteger las oficinas, despachos e instalaciones.
A.9.1.4 Protección contra Control

amenazas externas y
ambientales Se deben designar y mantener protección física contra
daños por fuego, inundación, terremoto, explosión,
manifestación civil y otras formas de desastre natural o
realizado por el hombre.
A.9.1.5 El trabajo en las áreas Control

seguras
Se debe designar y mantener protección física y pautas
para trabajar en áreas seguras.
A.9.1.6 Áreas de carga, Control

descarga y acceso
público Las áreas de carga, descarga y acceso público y otras áreas
donde las personas tengan acceso deben controlarse y,
cuando sea posible, aislarse de las instalaciones de
procesamiento de información para evitar un acceso no
autorizado.

PERUANA 28 de 49
A.9.2 Seguridad de los equipos

Objetivo de control: Prevenir pérdidas, daños o comprometer los activos así como la interrupción
de las actividades de la organización.
A.9.2.1 Ubicación y protección Control
de equipos El equipamiento será ubicado o protegido para reducir los
riesgos de amenazas, peligros ambientales y oportunidades
de acceso no autorizado.
A.9.2.2 Suministro eléctrico Control
El equipamiento se protegerá de fallas de energía y otras

anomalías eléctricas causadas por fallo en el suministro
eléctrico.
A.9.2.3 Seguridad del cableado Control
Se protegerá el cableado de energía y telecomunicaciones

que transportan datos o respaldan servicios de información
frente a interceptaciones o daños.
A.9.2.4 Mantenimiento de Control

equipos
El equipamiento recibirá un adecuado mantenimiento para
garantizar su continua disponibilidad e integridad.
A.9.2.5 Seguridad de equipos Control

fuera de los locales de
la organización Se debe aplicar seguridad al utilizar equipamiento para
procesar información fuera de los locales de la organización
tomando en cuenta los diferentes riesgos en los que se
incurre.
A.9.2.6 Seguridad en el re-uso Control

o eliminación de
equipos Todos los equipos que contienen almacenamiento de datos
deben ser revisados con el fin de asegurar que los datos
sensibles y los software con licencia han sido removidos o
sobrescritos antes de desecharlos o reutilizarlos.
A.9.2.7 Retiro de propiedad Control
Los equipos, información y software no deben ser retirados

fuera de la organización sin una autorización previa.

PERUANA 29 de 49
A.10 Gestión de comunicaciones y operaciones
A.10.1 Procedimientos y responsabilidades de operación

Objetivo de control: Asegurar la operación correcta y segura de los recursos de procesamiento de
información.
A.10.1.1 Documentación de Control
procedimientos
operativos Los procedimientos operativos deberán estar
documentados, mantenidos y estar disponibles a todos los
usuarios que lo requieran.
A.10.1.2 Gestión de cambios Control
Se controlarán los cambios en las instalaciones y sistemas

de procesamiento de la información.
A.10.1.3 Segregación de tareas Control
Se segregarán las obligaciones y las áreas de

responsabilidad con el fin de reducir las oportunidades de
modificaciones no autorizadas o mal uso de los activos de
la organización.
A.10.1.4 Separación de las Control

instalaciones de
desarrollo, prueba y Se separarán las instalaciones de desarrollo, prueba y
operación operación con el fin de reducir el riesgo de acceso no
autorizado o cambios en el sistema operacional.
A.10.2 Gestión de entrega de servicios externos

Objetivo de control: Implementar y mantener un nivel apropiado de seguridad de información y
servicios de entrega en concordancia con los acuerdos de servicios de entrega por parte de
terceros.
A.10.2.1 Entrega de servicios Control
Debemos asegurarnos que los controles de seguridad, las

definiciones de servicio y los niveles de entrega incluidos
en el acuerdo de servicios externos sean implementados,
estén operativos y sean mantenidos por el personal externo.
A.10.2.2 Monitoreo y revisión de Control
los servicios externos
Los servicios, reportes, y registros provistos por terceras
partes deben ser monitoreados y revisados regularmente.
Igualmente, se deben de llevar a cabo auditorías con
regularidad.

PERUANA 30 de 49
A.10.2.3 Gestión de cambios de Control

los servicios externos
Se debe manejar los cambios en la provisión de servicios,
incluyendo el mantenimiento y mejora de la política de
seguridad de información, procedimientos y controles,
tomando en cuenta la criticidad de los sistemas de negocio
y procesos envueltos en la reevaluación de riesgos.
A.10.3 Planificación y aceptación del sistema

Objetivo de control: Minimizar el riesgo de fallas de los sistemas.
A.10.3.1 Gestión de la capacidad Control
Se monitorearán las demandas de capacidad y se harán las

proyecciones de futuros requisitos de capacidad para
asegurar el desarrollo requerido por el sistema.
A.10.3.2 Aceptación del sistema Control

Se establecerán los criterios de aceptación para nuevos
sistemas de información, actualizaciones y nuevas
versiones y se llevarán a cabo pruebas adecuadas del
sistema antes de la aceptación.
A.10.4 Protección contra software malicioso

Objetivo de control: Proteger la integridad del software y de la información.
A.10.4.1 Controles contra Control
software malicioso
Para ofrecer protección frente a software malicioso, se
implementarán controles de detección, prevención y
procedimientos adecuados de toma de conciencia con los
usuarios.
A.10.4.2 Controles contra Control
software móvil
Donde sea autorizado el uso de software móvil, la
configuración debe asegurar que este opere de acuerdo a
una política de seguridad clara y definida. Igualmente, se
debe prevenir la ejecución de código móvil no autorizado.
A.10.5 Gestión interna de respaldo y recuperación
Objetivo de control: Mantener la integridad y disponibilidad del procesamiento de información y
servicios de comunicación.
A.10.5.1 Recuperación de la Control

información
Se obtendrán y probarán las copias de recuperación y
respaldo de información y software regularmente en
concordancia con la política acordada.

PERUANA 31 de 49
A.10.6 Gestión de seguridad de redes

Objetivo de control: Asegurar la salvaguarda de información en las redes y la protección de la
infraestructura de soporte.
A.10.6.1 Controles de red Control
Se implementará un conjunto de controles para lograr y

mantener la seguridad en las redes, y mantener la seguridad
de los sistemas y aplicaciones usuarios de la red, incluyendo
la información en tránsito.
A.10.6.2 Seguridad de los Control

servicios de red
Se deben identificar e incluir en cualquier acuerdo de
servicio de red los aspectos de seguridad, niveles de servicio
y requisitos de gestión, así estos servicios sean provistos
interna o externamente.
A.10.7 Utilización y seguridad de los medios de información

Objetivo de control: Prevenir daños, modificaciones o destrucciones a los activos e interrupciones
de las actividades del negocio.
A.10.7.1 Gestión de medios Control

removibles
Deben de existir procedimientos para la gestión de medios
removibles.
A.10.7.2 Eliminación de medios Control
Se eliminarán los medios de forma segura cuando ya no se

necesiten, utilizando procedimientos formales.
A.10.7.3 Procedimientos de Control

manipulación de la
información Se establecerán procedimientos para el manejo y
almacenamiento de la información con el fin de proteger
dicha información de divulgaciones no autorizadas o su mal
uso.
A.10.7.4 Seguridad de la Control

documentación de
sistemas La documentación de los sistemas se protegerá de accesos no
autorizados.

PERUANA 32 de 49
A.10.8 Intercambio de información

Objetivo de control: Mantener la seguridad de información y el intercambio de software dentro de
la organización y con entidades externas.
A.10.8.1 Políticas y Control

procedimientos para el
intercambio de Se deben establecer políticas, procedimientos y controles
información para proteger el intercambio de información durante el uso de
todo tipo de recursos de comunicación.
A.10.8.2 Acuerdos de Control
intercambio
Se deben de establecer acuerdos para el intercambio de
información y software entre la organización y entidades
externas.
A.10.8.3 Seguridad de medios Control
físicos en tránsito
Los medios a ser transportados deberán ser protegidos de
acceso no autorizado, mal uso o corrupción durante su
transporte fuera de los límites físicos de la organización.
A.10.8.4 Seguridad del correo Control
electrónico
La información contenida en correos electrónicos debe ser
protegida apropiadamente.
A.10.8.5 Seguridad en los Control
sistemas de
información de Se deben desarrollar e implementar políticas y
negocio procedimientos para proteger la información asociada con la
interconexión de los sistemas de información del negocio.
A.10.9 Servicios de comercio electrónico
Objetivo de control: Mantener la seguridad en los servicios de comercio electrónico y la
seguridad en su uso.
A.10.9.1 Seguridad en comercio Control

electrónico
El comercio electrónico será protegido frente a actividades
fraudulentas, controversias contractuales y divulgación o
modificación de información.
A.10.9.2 Seguridad en las Control
transacciones en línea
La información contenida en las transacciones en línea debe
ser protegida para prevenir transmisiones incompletas, rutas
incorrectas, alteración no autorizada de mensajes, o
duplicación no autorizada de mensajes.
A.10.9.3 Información Control
disponible Se protegerá la integridad de la información públicamente
públicamente disponible para prevenir modificaciones no autorizadas.

PERUANA 33 de 49
A.10.10 Monitoreo
Objetivo de control: Detectar actividades de procesamiento de información no autorizadas.
A.10.10.1 Registro de auditoría Control
Se deben producir y guardar, por un periodo acordado, los

registros de auditoría que registran las actividades de los
usuarios, excepciones y eventos de seguridad, con el fin de
asistir a investigaciones futuras y al monitoreo del control de
acceso.
A.10.10.2 Uso del sistema de Control

monitoreo
Se deben establecer procedimientos para monitorear las
instalaciones de procesamiento de información y los
resultados del monitoreo de actividades deben ser revisados
regularmente.
A.10.10.3 Protección de la Control

información de
registro Las instalaciones e información de registro debe ser
protegido contra acceso forzado y no autorizado.
A.10.10.4 Registros de Control

administrador y
operador Las actividades del administrador y operadores deben ser
registradas.
A.10.10.5 Registros con faltas Control

Las faltas deben ser registradas, analizadas y se deben tomar
acciones apropiadas.
A.10.10.6 Sincronización de Control

reloj Los relojes de todos los sistemas relevantes de procesamiento
de información dentro de la organización deben estar
sincronizados con una fuente de tiempo actual acordado.
A.11 Control de accesos
A.11.1 Requisitos de negocio para el control de accesos

Objetivo de control: Controlar los accesos a la información.
A.11.1.1 Política de control de Control
accesos Se debe establecer, documentar y revisar una política de
control de accesos, basado en requisitos de acceso de
seguridad y del negocio.

PERUANA 34 de 49
A.11.2 Gestión de acceso de usuarios

Objetivo de control: Asegurar que el acceso de usuarios es autorizado y prevenir el acceso no
autorizado a los sistemas de información.
A.11.2.1 Registro de usuarios Control
Habrá un procedimiento de registro y anulación formal de

usuarios para otorgar y eliminar el acceso a todos los
servicios y sistemas de información.
A.11.2.2 Gestión de privilegios Control
Se restringirá y controlará la asignación y uso de

privilegios.
A.11.2.3 Gestión de contraseñas Control
de usuario
Se controlará la asignación de contraseñas a través de un
proceso de gestión formal.
A.11.2.4 Revisión de los derechos Control
de acceso de los
usuarios La gerencia conducirá un proceso formal y de manera
periódica para revisar los derechos de acceso del usuario.
A.11.3 Responsabilidades de los usuarios
Objetivo de control: Prevenir el acceso no autorizado de usuarios y el compromiso o robo de la
información o de las instalaciones de procesamiento.
A.11.3.1 Uso de contraseñas Control
Los usuarios deben seguir buenas prácticas de seguridad en

la selección y uso de contraseñas.
A.11.3.2 Equipo informático de Control
usuario desatendido
Se exige al usuario que asegure protección adecuada a un
equipo desatendido.
A.11.3.3 Política de pantalla y Control
escritorio limpio Se debe adoptar una política de escritorio limpio para
papeles y dispositivos de almacenamiento removibles.
Igualmente, se debe adoptar una política para las
instalaciones de procesamiento de información.
A.11.4 Control de acceso a la red
Objetivo de control: Prevenir el acceso no autorizado a los servicios de red.
A.11.4.1 Política de uso de los Control
servicios de la red
Los usuarios deben tener acceso directo únicamente a los
servicios cuyo uso está específicamente autorizado.
A.11.4.2 Autenticación de Control
usuarios para
conexiones externas Deben usarse apropiados métodos de autenticación para
controlar el acceso de usuarios remotos.

PERUANA 35 de 49
A.11.4.3 Autenticación de Control

equipos en la red
Se debería considerar equipos con identificación
automática para autentificar conexiones desde ubicaciones
y equipos específicos.
A.11.4.4 Protección para la Control
configuración de
puertos y diagnóstico Debe controlarse la seguridad en el acceso lógico y físico
remoto para el diagnóstico y configuración de puertos.
A.11.4.5 Segregación en las Control
redes
Los grupos de servicios, usuarios y sistemas de
información deben ser segregados en las redes.
A.11.4.6 Control de conexión a Control
las redes
La capacidad de conexión de los usuarios de redes
compartidas, especialmente aquellas que se extienden fuera
de las fronteras de la organización, debe restringirse de
conformidad con la política de control de acceso y los
requisitos de las aplicaciones de negocio (véase 11.1).
A.11.4.7 Control de enrutamiento Control
en la red Se deben implementar controles de ruteo para asegurar que
las conexiones de computadora y los flujos de información
no violen la política de control de acceso de las
aplicaciones de negocios.
A.11.5 Control de acceso al sistema operativo
Objetivo de control: Prevenir accesos no autorizados a los sistemas operativos.
A.11.5.1 Procedimientos seguros Control
de conexión
Se usará un proceso de registro de conexión (login) seguro
para acceder a los servicios de información.
A.11.5.2 Identificación y Control
autenticación del Todos los usuarios tienen un identificador único para su
usuario uso propio y exclusivo para sus actividades y debe elegirse
una técnica de autenticación adecuada para sustentar la
identidad del usuario.
A.11.5.3 Sistema de gestión de Control
contraseñas
Sistemas de gestión de contraseñas proveerán medios
efectivos e interactivos, cuyo objetivo es asegurar
contraseñas de calidad.
A.11.5.4 Uso de los programas Control
utilitarios del sistema
Se debe registrar y controlar firmemente el uso de
programas utilitarios que puedan ser capaces de forzar el
sistema y los controles de aplicación.

PERUANA 36 de 49
A.11.5.5 Desconexión automática Control

de terminales
Las sesiones inactivas deben cerrarse luego de un periodo
definido de inactividad.
A.11.5.6 Limitación del tiempo de Control
conexión
Se usará restricciones de tiempos de conexión para ofrecer
seguridad adicional para las aplicaciones de alto riesgo.
A.11.6 Control de acceso a las aplicaciones e información
Objetivo de control: Evitar el acceso no autorizado a la información contenida en los sistemas.
A.11.6.1 Restricción de acceso a Control

la información
El acceso a las funciones de información y de aplicación
por usuarios y personal de soporte serán restringidos con la
política de control de acceso.
A.11.6.2 Aislamiento de sistemas Control
sensibles
Los sistemas sensibles tendrán un ambiente de computo
dedicado (aislado).
A.11.7 Informática móvil y teletrabajo
Objetivo de control: Garantizar la seguridad de la información cuando se usan dispositivos de
informática móvil y facilidades de teletrabajo.
A.11.7.1 Informática y Control

comunicaciones móviles
Se pondrá en práctica una política formal y se adoptarán los
controles adecuados para protegerse frente a los riesgos de
trabajar con puntos de computadores móviles y medios de
comunicación.
A.11.7.2 Teletrabajo Control
Se desarrollarán e implementaran políticas, procedimientos

y estándares para las actividades de teletrabajo.
A.12 Adquisición de sistemas de información, desarrollo y mantenimiento
A.12.1 Requisitos de seguridad de los sistemas de información

Objetivo de seguridad: Garantizar que la seguridad esté incluida dentro de los sistemas de
información.
A.12.1.1 Análisis y Control

especificación de los Los requisitos de negocios para nuevos sistemas, o
requisitos de seguridad ampliaciones de los sistemas existentes, especificarán los
requisitos de control.

PERUANA 37 de 49
A.12.2 Proceso correcto en aplicaciones

Objetivo de control: Prevenir errores, pérdidas, modificaciones no autorizadas o mal uso de los
datos del usuario en las aplicaciones.
A.12.2.1 Validación de los datos Control

de entrada
Se validará el ingreso de datos a los sistemas de aplicación
para asegurar que sean correctos y adecuados.
A.12.2.2 Control del proceso Control
interno
Se incorporarán verificaciones y validaciones para detectar
cualquier corrupción de los datos procesados.
A.12.2.3 Integridad de mensajes Control
Se deben identificar requisitos para la autenticación y

protección de la integridad de mensajes. Igualmente, se
deben implementar e identificar controles apropiados.
A.12.2.4 Validación de los datos Control
de salida
Los datos de salida de una aplicación se validarán para
garantizar que el procesamiento de la información
almacenada sea correcto y adecuado a las circunstancias.
A.12.3 Controles criptográficos
Objetivo de control: Proteger la confidencialidad, autenticidad o integridad a través de medios
criptográficos.
A.12.3.1 Política de uso de los Control

controles criptográficos Debe desarrollarse e implementarse una política sobre el
uso de controles criptográficos para proteger la
información.
A.12.3.2 Gestión de claves Control
Se usará un sistema de gestión de claves con el fin de
apoyar el uso de técnica criptográficas dentro de la
organización.
A.12.4 Seguridad de los archivos del sistema
Objetivo de control: Asegurar la seguridad de los archivos del sistema.
A.12.4.1 Control del software en Control

producción
Se pondrá en práctica procedimientos para controlar la
implementación del software en sistemas operacionales.
A.12.4.2 Protección de los datos Control

de prueba del sistema
Se protegerán y controlarán los datos de prueba los cuales
deben ser seleccionados cuidadosamente.

PERUANA 38 de 49
A.12.4.3 Control de acceso a la Control

librería de programas
fuente El acceso a las librerías de programas fuente debe ser
restringido.
A.12.5 Seguridad en los procesos de desarrollo y soporte

Objetivo de control: Mantener la seguridad del software de aplicación y la información.
A.12.5.1 Procedimientos de Control

control de cambios
La implementación de cambios se controlará estrictamente
mediante el uso de procedimientos formales de control de
cambios.
A.12.5.2 Revisión técnica de los Control
cambios en el sistema
operativo Cuando los sistemas operativos son cambiados, se deben
de revisar y probar las aplicaciones criticas de negocio con
el fin de asegurar que no existan impactos adversos en las
operaciones o seguridad de la organización.
A.12.5.3 Restricciones en los Control
cambios a los paquetes
de software No se debe fomentar las modificaciones en los paquetes.
Se debe limitar a cambios necesarios y todos estos cambios
deben ser estrictamente controlados.
A.12.5.4 Fuga de información Control
Se deben de prevenir las oportunidades de fuga de

información.
A.12.5.5 Desarrollo externo del Control
software
La organización debe supervisar y monitorear el desarrollo
externo de software.
A.12.6 Gestión de vulnerabilidades técnicas
Objetivo de control: Reducir los riesgos que son el resultado de la explotación de
vulnerabilidades técnicas publicadas.
A.12.6.1 Control de Control
vulnerabilidades
técnicas Se debe obtener información a tiempo sobre las
vulnerabilidades técnicas de los sistemas de información
que se utilizan. La exposición de la organización a tales
vulnerabilidades debe ser evaluada y se debe tomar
medidas apropiadas asociadas al riesgo.

PERUANA 39 de 49
A.13 Gestión de incidentes en la seguridad de información
A.13.1 Reportando eventos y debilidades en la seguridad de información

Objetivo de control: Asegurar que los eventos y debilidades en la seguridad de información
asociados con los sistemas de información sean comunicados de manera tal que permitan tomar
una acción correctiva a tiempo.
A.13.1.1 Reportando eventos de Control
la seguridad de
información Los eventos en la seguridad de información deben ser
reportados lo mas rápido posible a través de canales
apropiados.
A.13.1.2 Reportando debilidades Control
de seguridad
Todos los empleados, contratistas o personal externo
usuario de los sistemas y servicios de información, deben
estar obligados de notar y reportar cualquier debilidad en
la seguridad de los sistemas y servicios.
A.13.2 Gestión de los incidentes y mejoras en la seguridad de información
Objetivo de control: Asegurar que un alcance consistente y efectivo sea aplicado en la gestión
de incidentes de la seguridad de información.
A.13.2.1 Responsabilidades y Control.
procedimientos
Se deben de establecer procedimientos y responsabili-
dades de gestión con el fin de asegurar una respuesta
rápida, efectiva y ordenada ante incidentes en la
seguridad de información.
A.13.2.2 Aprendiendo de los Control
incidentes en la
seguridad de Deben existir mecanismos que habiliten que los tipos,
información volúmenes y costos de los incidentes en la seguridad de
información sean cuantificados y monitoreados.
A.13.2.3 Recolección de Control
evidencia Cuando exista una acción de seguimiento contra una
persona u organización, luego de que un incidente en el
sistema de información involucre una acción legal (civil o
criminal), se debe de recolectar, retener y presentar
evidencia conforme con las reglas dentro de la
jurisdicción.

PERUANA 40 de 49
A.14 Gestión de la continuidad del negocio
A.14.1 Aspectos de la gestión de continuidad del negocio en la seguridad de información

Objetivo de control: Neutralizar las interrupciones a las actividades del negocio y proteger los
procesos críticos del negocio de los efectos de fallas mayores o desastres en los sistemas de
información y asegurar su reanudación oportuna.
A.14.1.1 Incluyendo la seguridad Control

de la información en la
gestión de la Se deben de establecer procedimientos y
continuidad del negocio responsabilidades de gestión con el fin de asegurar una
respuesta rápida, efectiva y ordenada ante incidentes en la
seguridad de la información.
A.14.1.2 Continuidad del negocio Control
y evaluación de riesgos
Los eventos que pueden causar interrupciones en los
procesos del negocio deben ser identificados así como las
probabilidades e impacto de dichas interrupciones y sus
consecuencias para la seguridad de la información.
A.14.1.3 Desarrollando e Control
implementando planes
de continuidad que Se deben desarrollar e implementar planes para mantener
incluyen la seguridad de o reparar operaciones y asegurar la disponibilidad de
la información información al nivel y tiempo requerido, siguiendo las
interrupciones o fallas a los procesos críticos del negocio.
A.14.1.4 Marco de planificación Control
de la continuidad del
negocio Un simple marco de los planes de continuidad del
negocio debe ser mantenido para asegurar que todos los
planes sean consistentes, que anexen consistentemente
los requisitos de seguridad de la información, para
identificar prioridades de prueba y mantenimiento.
A.14.1.5 Probando, manteniendo Control
y reevaluando los planes
de continuidad del Los planes de continuidad del negocio deben ser
negocio probados y actualizados regularmente con el fin de
asegurar que se encuentren actuales y que sean efectivos.

PERUANA 41 de 49
A.15 Cumplimiento
A.15.1 Cumplimiento de los requisitos legales

Objetivo de control: Evitar los incumplimientos de cualquier ley civil o penal, requisito
reglamentario, regulación u obligación contractual, y de cualquier requisito de seguridad.
A.15.1.1 Identificación de la Control

legislación aplicable
Se definirán y documentarán explícitamente todos los
requisitos legales, regulatorios y contractuales relevantes y se
deben mantener actualizados cada sistema de información y la
organización.
A.15.1.2 Derechos de Control

propiedad intelectual
(DPI) Se implementarán procedimientos adecuados para garantizar el
cumplimiento de las restricciones legales en el uso de material
con respecto a derechos de propiedad intelectual y uso de
productos de software propietario.
A.15.1.3 Salvaguarda de los Control

registros de la
organización Se protegerán los registros importantes de la organización
frente a pérdidas, destrucción y falsificación en concordancia
con los requisitos regulatorios, contractuales y de negocio.
A.15.1.4 Protección de los Control

datos y privacidad de
la información Se aplicarán controles para proteger información personal en
personal conformidad con la legislación correspondiente y si es
aplicable, con las cláusulas contractuales.
A.15.1.5 Prevención en el mal Control

uso de las
instalaciones de Los usuarios deben ser disuadidos de utilizar las instalaciones
procesamiento de la del procesamiento de información para propósitos no
información autorizados.
A.15.1.6 Regulación de los Control

controles
criptográficos Se implementarán controles para permitir el cumplimiento de
los acuerdos nacionales, leyes y reglamentos.

PERUANA 42 de 49
A.15.2 Cumplimiento con las políticas y estándares de seguridad y del cumplimiento técnico
Objetivo de control: Asegurar el cumplimiento de los sistemas con las políticas y normas de
seguridad organizacionales.
A.15.2.1 Cumplimiento con los Control

estándares y la
política de seguridad Los gerentes deben tomar acciones para garantizar que todos
los procedimientos de seguridad dentro de sus áreas de
responsabilidad se lleven a cabo correctamente con el fin de
garantizar el cumplimiento de las políticas y estándares de
seguridad.
A.15.2.2 Comprobación del Control
cumplimiento técnico
Debe verificarse regularmente el cumplimiento de la
implementación de normas de seguridad en los sistemas de
información.
A.15.3 Consideraciones sobre la auditoría de sistemas
Objetivo de control: Maximizar la efectividad y minimizar las interferencias en el proceso de
auditoría del sistema.
A.15.3.1 Controles de Control

auditoría de sistemas
Se planificarán cuidadosamente las auditorías de los sistemas
operacionales a fin de minimizar el riesgo de interrupciones a
los procesos de negocio.
A.15.3.2 Protección de las Control
herramientas de
auditoría de sistemas Se protegerá el acceso a las herramientas de auditoría del
sistema para prevenir cualquier posible mal uso o daño.

PERUANA 43 de 49
ANEXO B
(INFORMATIVO)
PRINCIPIOS OECD Y ESTA NORMA
Los principios dados en las Pautas OECD para la Seguridad de los Sistemas y Redes de
Información se aplican a todos los niveles políticos y operativos que rigen la seguridad de
los sistemas de información y redes. Esta NTP ofrece un marco para el sistema de gestión
de la seguridad de la información para implementar algunos de los principios OECD
usando el modelo PDCA y los procesos descritos en los capítulos 4, 5, 6, y 8 como se
indica en la Tabla B.1
TABLA B.1 - Principios OECD y modelo PDCA
Principio OECD Proceso ISMS y fase PDCA correspondiente

Conocimiento Esta actividad es parte de la fase Hacer (véase
Los participantes deben estar concientes de la 4.2.2 y 5.2.2).
necesidad de seguridad de los sistemas y redes
de información y lo que pueden hacer para
mejorar la seguridad.
Responsabilidad Esta actividad es parte de la fase Hacer (véase
Todos los participantes son responsables por la 4.2.2 y 5.1).
seguridad de los sistemas y redes de
información.
Respuesta Esto es parte de la actividad de monitoreo de la
Los participantes deben actuar de manera fase Verificar (véase 4.2.3 y 6 a 7.3) y una
puntual y cooperativa para prevenir, detectar y
actividad de respuesta de la fase Actuar (véase
responder a los incidentes de seguridad. 4.2.4 y 8.1 a 8.3). También puede cubrirse con
varios aspectos de las fases Planear y
Verificar.
Evaluación del riesgo Esta actividad es parte de la fase Planear
Los participantes deben conducir evaluaciones (véase 4.2.1) y evaluación de riesgo es parte de
del riesgo. la fase Verificar (véase 4.2.3 y 6 a 7.3).

PERUANA 44 de 49
TABLA B.1 - Principios OECD y modelo PDCA (Fin)
Principio OECD Proceso ISMS y fase PDCA correspondiente

Diseño e implementación de seguridad Una vez que se ha completado la evaluación
Los participantes deben incorporar la del riesgo, se ha seleccionado controles para el
tratamiento de riesgos como parte de la fase
seguridad como un elemento esencial de Planear (véase 4.2.1). La fase Hacer (véase
los sistemas y redes de información. 4.2.2 y 5.2) entonces cubre la implementación
y uso operacional de estos controles.
Gestión de seguridad La gestión del riesgo es un proceso que
Los participantes deben adoptar un enfoque incluye la prevención, detección y respuesta
comprensivo de la gestión de seguridad. frente a incidentes, mantenimiento en curso,
revisión y auditoría. Todos estos aspectos
están incluidos en las fases Planear, Hacer,
Verificar y Actuar.
Reevaluación Reevaluación de la seguridad de la
Los participantes deben revisar y reevaluar la información es parte de la fase Verificación
seguridad de los sistemas y redes de (véase 4.2.3 y 6 a 7.3) donde debe realizarse
información y hacer modificaciones adecuadas revisiones regulares para verificar la
a las políticas, prácticas, medidas y efectividad de los sistemas de gestión de
procedimientos de seguridad seguridad de la información y mejorar la
seguridad es parte de la fase Actuar (véase
4.2.4 y 8.1 a 8.3)

PERUANA 45 de 49
ANEXO C
(INFORMATIVO)
CORRESPONDENCIA ENTRE LA NORMA ISO

9001:2000, ISO 14001:2004 Y ESTA NORMA
La tabla C.1 muestra la correspondencia entre la norma ISO 9001:2000, ISO 14001:2004 y
esta NTPperuana
TABLA C.1 – Correspondencia entre ISO 9001:2000, ISO 14001:2004 y esta Norma
Norma Peruana ISO 9001:2000 ISO 14001:2004
0 Introducción 0 Introducción Introducción
0.1 Aspectos Generales 0.1 Aspectos Generales
0.2 Enfoque de proceso 0.1 Alcance del proceso
0.2 Relaciones con ISO 9004
0.3 Compatibilidad con otros 0.3 Compatibilidad con otros

sistemas de gestión sistemas de gestión
1 Alcance 1 Alcance 1 Alcance
1.1 Aspectos Generales 1.1 Aspectos Generales
1.2 Aplicación 1.2 Aplicaciones
2 Referencias normativas 2 Referencias normativas 2 Referencias normativas
3 Términos y definiciones 3 Términos y definiciones 3 Términos y definiciones

PERUANA 46 de 49
4 Sistema de gestión de 4 Sistema de gestión de 4 Requisitos del sistema de

seguridad de la información calidad gestión ambiental
4.1 Requisitos generales 4.1 Requisitos generales 4.1 Requisitos generales
4.2 Establecimiento y
administración de ISMS
4.2.1 Establecimiento de ISMS
4.2.2 Implementar y operar el 4.4 Implementación y

ISMS 8.2.3 Monitoreo y medición operación
de los procesos
4.2.3 Monitorear y revisar el 4.5.1 Monitoreo y medición
ISMS 8.2.4 Monitoreo y medición
del producto
4.2.4 Mantener y mejorar el ISMS
4.3 Requisitos de documentación 4.2 Requisitos de

documentación
4.3.1 Aspectos Generales
4.2.1 Aspectos Generales
4.2.2 Manual de calidad

4.3.2 Control de documentos
4.2.3 Control de documentos 4.4.5 Control de la
4.3.3 Control de registros documentación
4.2.4 Control de registros 4.5.4 Control de registros
5 Responsabilidad de la 5 Responsabilidad de la
gerencia gerencia
5.1 Compromiso de la gerencia 5.1 Compromiso de la

gerencia
5.2 Enfoque de los clientes
5.3 Política de calidad 4.2 Política ambiental
5.4 Planeamiento 4.3 Planeamiento
5.5 Responsabilidad,
autoridad y comunicación

PERUANA 47 de 49
5.2 Administración de recursos 6 Gestión de recursos
5.2.1 Provisión de recursos 6.1 Provisión de recursos
6.2 Recursos humanos

5.2.2 Capacitación,
concientización y competencia 6.2.2 Competencia, concienti- 4.4.2 Competencia,
zación y capacitación concientización y capacitación
6.3 Infraestructura
6.4 Ambiente de trabajo
6 Auditorías internas del ISMS 8.2.2 Auditoría interna 4.5.5 Auditoría interna
7 Revisión gerencial del ISMS 5.6 Revisión gerencial 4.6 Revisión gerencial
7.1 Aspectos Generales 5.6.1 Aspectos Generales
7.2 Revisión: entradas 5.6.2 Revisión: entradas
7.3 Revisión: salidas 5.6.3 Revisión: salidas
8 Mejora del ISMS 8 Mejora
8.1 Mejora continua 8.5.1 Mejora continua
8.2 Acciones correctivas 8.5.3 Acciones correctivas 4.5.3 No conformidad,

acciones correctivas y
preventivas
8.3 Acciones preventivas 8.5.3 Acciones preventivas
Anexo A Objetivos de control y Anexo A Pautas en el uso de

controles esta norma
Anexo B Principios OECD y de

esta Norma
Anexo A Correspondencia
Anexo C Correspondencia entre la norma ISO 9001: Anexo B Correspondencia
entre la norma ISO 9001: 2000, ISO 14001:1996 entre la norma ISO 14001:
2000, ISO 14001:2004 y esta 2004, ISO 9001:2000
Norma

PERUANA 48 de 49
BIBLIOGRAFÍA
Publicaciones
1. ISO 9001:2000, Quality management systems - Requirements
2. ISO/IEC 13335-1:2004, Information technology – Security techniques –

Management of information and communications technology security – Part 1: Concepts
and models for information and communications technology security management
3. ISO/IEC TR 13335-3:1998, Information technology – Guidelines for the

management of IT Security – Part 3: Techniques for the management of IT security
4. ISO/IEC TR 13335-4:2000, Information technology – Guidelines for the

management of IT Security – Part 4: Selection of safeguards.
5. ISO 14001:2004, Environmental management systems – Requirements with

guidance for use
6. ISO/IEC TR 18044:2004, Information technology – Security techniques –

Information security incident management
7. ISO 19011:2002, Guidelines for quality and/or environmental management

systems auditing
8. ISO/IEC Guide 62:1996, General requirements for bodies operating

assessment and certification/registration of quality systems.
9. ISO/IEC Guide 73:2002, Risk management – Vocabulary – Guidelines for

use in standards
Otras publicaciones
1. OECD Guidelines for the Security of Information Systems and Networks –

Towards a Culture of Security. Paris: OECD, July 2002. www.oecd.org

PERUANA 49 de 49
2. NIST SP 800-30, Risk Management Guide for Information Technology

Systems
3. Deming W.E., Out of the Crisis, Cambridge, Mass: MIT, Center for
Advanced Engineering Study, 1986

APRUEBAN DOCUMENTO “GUÍA TÉCNICA SOBRE EVALUACIÓN
DE SOFTWARE PARA LA ADMINISTRACIÓN PUBLICA”
RESOLUCIÓN MINISTERIAL N° 139-2004-PCM
Lima, 27 de mayo de 2004
CONSIDERANDO:
Que, mediante el Decreto Supremo Nº 066-2003-PCM se fusionó la Subjefatura de

Informática del Instituto Nacional de Estadística e Informática - INEI y la Presidencia del
Consejo de Ministros, en virtud a lo cual el numeral 3.10 del artículo 3º del Reglamento de
Organización y Funciones de la Presidencia del Consejo de Ministros, aprobado por Decreto
Supremo Nº 067-2003-PCM, ha establecido que es función de la Presidencia del Consejo de
Ministros actuar como ente rector del Sistema Nacional de Informática;
Que, a efectos de implementar la infraestructura de Gobierno Electrónico, el mismo que

comienza con la identificación y evaluación de los componentes funcionales requeridos,
adopción de estándares abiertos y aceptados internacionalmente, la planificación y seguridad,
en el marco de sus funciones la Oficina Nacional de Gobierno Electrónico e Informática –
ONGEI, en coordinación con el Instituto Nacional de Defensa de la Competencia y de la
Protección de la Propiedad Intelectual – INDECOPI, ha propuesto la “Guía Técnica Sobre
Evaluación de Software para la Administración Pública”, por ser éste el que procesa datos y
produce información, que es considerada actualmente un activo importante y estratégico de las
organizaciones y países;
De conformidad con lo dispuesto por el Decreto Legislativo Nº 560 – Ley del Poder
Ejecutivo y el Reglamento de Organización y Funciones de la Presidencia del Consejo de
Ministros, aprobado por Decreto Supremo Nº 067-2003-PCM;
SE RESUELVE:
Artículo 1º.- Aprobar el documento “Guía Técnica Sobre Evaluación de Software para
la Administración Pública”, documento que será publicado en el portal de la Presidencia del
Consejo de Ministros (www.pcm.gob.pe).
Artículo 2º.- Las entidades de la Administración Pública, integrantes del Sistema

Nacional de Informática, deberán aplicar lo establecido en la “Guía Técnica Sobre Evaluación
de Software para la Administración Pública” en los productos de software que desarrollen o
adquieran a partir de la fecha de publicación de la presente Resolución.
Si no fuera posible parcial o totalmente su aplicación, el área de informática o la que

haga sus veces de la entidad respectiva, comunicará esta situación a la Oficina Nacional de
Gobierno Electrónico e Informática – ONGEI, adjuntando el informe técnico que sustente la
justificación para la no aplicación de la citada Guía.
Regístrese, comuníquese y publíquese.
CARLOS FERRERO
Presidente del Consejo de Ministros
Publicado en el Diario Oficial “El Peruano” el 28/05/04

Oficina Nacional de Gobierno Electrónico e Informática
Presidencia del Consejo de Ministros
Guía Técnica sobre Evaluación
de Software en la
Administración Pública
RESOLUCIÓN MINISTERIAL N073-2004-PCM
Presidencia del Consejo de Ministros – Gobierno del Perú – ONGEI

formatos@pcm.gob.pe
Ref: Guía Técnica de Evaluación Nombre del Proyecto: “Guía Técnica sobre Evaluación de Software
Versión: 01 en la Administración Pública”
HOJA DE INFORMACION GENERAL
CONTROL DOCUMENTAL:
PROYECTO: Guía Técnica sobre Evaluación de

Software en la Administración Pública
ENTIDAD: Presidencia del Consejo de Ministros
VERSIÓN: 1.0
FECHA EDICIÓN: 05/05/2004
NOMBRE DE ARCHIVO: P01-PCM-
GUIAEVALUACIONSOFTWARE
RESUMEN: Guía que permite evaluar eficientemente
los desarrollos y software en el Estado.
DERECHOS DE USO:
La presente documentación es de uso para la Administración Pública del Estado Peruano.
ESTADO FORMAL:
Preparado por: ONGEI Entidad: ONGEI – PCM Fecha: Mayo 2004

formatos@pcm.gob.pe
Fecha: 05/05/04
CONTROL DE VERSIONES
FUENTE DE CAMBIO FECHA DE VERSIÓN PARTES DESCRIPCIÓN FECHA DE

SOLICITU QUE DEL CAMBIO CAMBIO
D DEL CAMBIAN
CAMBIO
P01-PCM-GUIAEVALUACIONSOFTWARE.doc 1.00 N/A

formatos@pcm.gob.pe
Fecha: 05/05/04
Índice
INTRODUCCIÓN 04
APLICACIÓN 04
ESTRUCTURA 04
PARTE 1: MODELO DE LA CALIDAD 05
1.1 Alcance 05
1.2 Conformidad 06
1.3 Marco de trabajo del modelo de la calidad 06
1.4 Modelo de calidad para la calidad externa e interna 11
1.5 Modelo de calidad para la calidad en uso 18
PARTE 2: MÉTRICAS 20
2.1 Atributos Internos y Externos 20

2.2 Métrica interna 21
2.3 Métrica externa 21
2.4 Relación entre las métricas internas y externas 21
2.5 Calidad en el uso de métricas 22
2.6 Opción de métrica y criterio de medidas 22
2.7 Métricas usadas para la comparación 23
PARTE 3: PROCESO DE EVALUACIÓN DE SOFTWARE 24
3.1 Establecer el propósito de la evaluación 24

3.2 Identificar el tipo de producto 24
3.3 Especificar el Modelo de Calidad 24
3.4 Seleccionar métricas 24
3.5 Establecer niveles, escalas para las métricas 25
3.6 Establecer criterios de valoración 25
3.7 Tomar medidas 25
3.8 Comparar con los criterios 26
3.9 Valorar resultados 26
3.10 Documentación 26
GLOSARIO DE TÉRMINOS 27
BIBLIOGRAFÍA 32
3
GUÍA TÉCNICA SOBRE EVALUACIÓN DE SOFTWARE PARA LA
ADMINISTRACIÓN PÚBLICA
INTRODUCCIÓN
La presente guía esta basada sobre la norma ISO/IEC 9126 de la ISO (Organización
Internacional de Normalización) y la IEC (Comisión Electrotécnica Internacional) que
forman el sistema especializado para la normalización internacional.
El desarrollo o selección de productos de software con calidad es muy importante en la

actualidad en las instituciones públicas, ya que éstas procesan información, que es
considerada como un activo importante de sus organizaciones.
Una especificación y evaluación integral y detallada de la calidad de los productos de

software es un factor clave para asegurar que la calidad sea la adecuada. Esto se
puede lograr definiendo de manera apropiada las características de calidad, teniendo
en cuenta el propósito del uso del producto de software en la institución.
Es importante especificar y evaluar cada característica relevante de la calidad de los

productos de software, cuando esto sea posible, utilizando mediciones validadas o de
amplia aceptación, que hagan técnicamente transparente esta actividad.
Agradecemos la colaboración del Comité Técnico de Normalización de Ingeniería de

Software y Sistemas de Información - INDECOPI, por su apoyo técnico en la
elaboración de la presente guía.
APLICACIÓN
• La presente guía es aplicable al software propietario y software libre o de

código abierto utilizado en la Administración Pública.
• Esta guía debe aplicarse en toda evaluación de software propietario

considerando esquemas comparativos con el software libre o de código abierto
y viceversa, evidenciando ventajas y desventajas.
• Será utilizada para evaluar un solo software o un conjunto de softwares de

naturaleza o funciones similares, tipo y/o categoría.
ESTRUCTURA
La presente guía consta de las siguientes partes:
− 1: Modelo de la calidad
− 2: Métricas
4
− 3. Proceso de evaluación de software
PARTE 1: MODELO DE LA CALIDAD
1.1 ALCANCE
Se describe un modelo de calidad para los productos de software, dividido en dos

partes:
a) Calidad interna y externa, y
b) Calidad en uso.
La primera parte del modelo especifica seis características para calidad interna y
externa, las cuales, a su vez, están subdivididas en sub características. Estas sub
características se manifiestan externamente cuando el software es usado como parte
de un sistema de computadora, y son el resultado de atributos internos de software.
La segunda parte del modelo, especifica cuatro características para la calidad en uso.
Calidad en uso es el efecto combinado para el usuario de las seis características de la
calidad interna y externa de productos de software.
Las características definidas son aplicables a todo software, incluyendo programas de

computadora y datos contenidos en firmware. Las características y sub características
proveen terminología consistente para la calidad de productos de software. Ellas
también proveen un marco de trabajo para especificar los requerimientos de la calidad
para productos de software, y para hacer análisis y evaluaciones entre capacidades de
productos de software.
Esta parte de la norma permite especificar y evaluar la calidad de productos de

software desde diferentes perspectivas asociadas con adquisición, requerimientos,
desarrollo, uso, evaluación, soporte, mantenimiento, aseguramiento de la calidad y
auditoria de software.
Esta norma será usada por personal de informática que cumple funciones de
desarrolladores, adquirientes, personal de aseguramiento de la calidad y aquellos
responsables de especificar y evaluar la calidad de productos de software.
Como ejemplo del uso del modelo de la calidad, tenemos:
• Validar que la definición de un requerimiento esté completa;
• Identificar requerimientos de software;
• Identificar objetivos del diseño de software;
5
• Identificar objetivos de prueba de software;
• Identificar criterios de aseguramiento de la calidad;
• Identificar criterios de aceptación para un producto de software completo.
1.2 CONFORMIDAD
Cualquier requerimiento, especificación o evaluación de la calidad sobre cualquier

producto de software que cumpla esta parte de la guía, debe usar las características y
sub características de los ítems 1.4 y 1.5, dando las razones por cualquier exclusión, o
describiendo su propia categorización de los atributos de la calidad de productos de
software, explicando la equivalencia respectiva.
1.3 MARCO DE TRABAJO DEL MODELO DE LA CALIDAD
En esta parte se describe el marco de trabajo de un modelo de calidad, el cual explica

la relación entre los diferentes enfoques de la calidad.
1.3.1 Perspectivas de calidad
Proceso Producto de software Efectos del producto

software
influye en influye en influye en

Atributos de Atributos de Atributos de
Calidad del
la calidad la calidad calidad en el
proceso
depende de interna depende de externa depende de uso
Contexto
de uso
Medición del Medición Medición Medición de la
proceso interna externa calidad en uso
FIGURA 1 – Ciclo de vida de la calidad
Las necesidades de calidad del usuario incluyen requerimientos de calidad en uso, en

contextos específicos. Estas necesidades identificadas pueden ser usadas cuando se
especifiquen la calidad externa e interna, utilizando características y sub
características de la calidad del producto de software.
La evaluación de los productos de software para satisfacer las necesidades de calidad

es uno de los procesos en el ciclo de vida del desarrollo del software. La calidad del
6
producto de software puede ser evaluada midiendo atributos internos (medidas
típicamente estáticas de productos intermedios), o midiendo atributos externos
(midiendo típicamente el comportamiento del código cuando es ejecutado), o bien
midiendo los atributos de aplicación de calidad en uso. El objetivo para que este
producto tenga el efecto requerido en un contexto particular de uso se diagrama en la
Figura 2.
La calidad del proceso contribuye a mejorar la calidad del producto, y la calidad del
producto contribuye a mejorar la calidad en uso. Por lo tanto, evaluar y mejorar un
proceso es una manera de mejorar la calidad del producto, y evaluar y mejorar la
calidad del producto es una manera de mejorar la calidad en uso. De igual manera,
evaluar la calidad en uso proporciona una retroalimentación para mejorar el producto,
y evaluar un producto puede proporcionar una respuesta para mejorar un proceso.
Atributos internos apropiados en el software son pre requisitos para alcanzar el

comportamiento externo requerido, y un apropiado comportamiento externo es un pre
requisito para alcanzar la calidad en uso (Figura 1).
Los requisitos para la calidad del producto de software incluirán criterios de evaluación
para calidad interna, calidad externa y calidad en uso, para cumplir las necesidades de
los desarrolladores, responsables de mantenimiento, adquirientes y usuarios finales.
1.3.2 Calidad de producto y el ciclo de vida
Las vistas de calidad interna, calidad externa y calidad en uso cambian durante el ciclo
de vida del software. Por ejemplo, la calidad especificada, como requisito de calidad al
comienzo de un ciclo de vida, es mayormente observada desde el punto de vista
externo y de usuario, y se diferencia de la calidad del producto intermedio, como la
calidad del diseño, la cual es mayormente observada desde el punto de vista interno
del desarrollador. Las tecnologías usadas para alcanzar el nivel de calidad necesario,
así como la especificación y evaluación de calidad, necesitan soportar estos diversos
puntos de vista. Es necesario definir estas perspectivas y las tecnologías asociadas a
la calidad, para manejarla apropiadamente en cada etapa del ciclo de vida.
La meta es alcanzar la calidad necesaria y suficiente para cumplir con las necesidades
reales de los usuarios. La norma ISO 8402 define calidad en términos de la habilidad
de satisfacer necesidades explícitas (declaradas/descritas/especificadas) e implícitas.
Sin embargo, las necesidades descritas por un usuario no siempre reflejan las
verdaderas necesidades del mismo, porque:
• Un usuario normalmente no está consciente de sus necesidades reales.

• Las necesidades podrían cambiar después de ser especificadas.
• Diferentes usuarios pueden tener diferentes ambientes de operación.
• Podría ser imposible consultar a todos los posibles tipos de usuario,
particularmente para un tipo de software (que no está en el mostrador/
producto preelaborado).
7
Por lo tanto, los requisitos de calidad no pueden ser completamente definidos antes de
empezar con el diseño. Sin embargo, es necesario entender las necesidades reales
del usuario tan al detalle como sea posible, y representarlas en los requerimientos. La
meta no es obtener la calidad perfecta, pero sí la calidad necesaria y suficiente para
cada contexto específico de uso, cuando el producto sea entregado y utilizado por los
usuarios.
Necesidades de
calidad del Calidad en uso
usuario
uso y
retroalimentación
indica
Requerimientos
de calidad Calidad externa
externa
validación
contribuye a indica
especificar
Requerimientos
de calidad Calidad interna
interna
verificación
FIGURA 2 – Calidad en el ciclo de vida del software
Las escalas de medidas para las métricas usadas en los requerimientos de calidad
pueden ser divididas en categorías correspondientes a diferentes grados de
satisfacción de los requerimientos. Por ejemplo, la escala podría estar dividida en dos
categorías: no satisfactoria y satisfactoria, o en cuatro categorías: excede los
requerimientos, cumple los objetivos, mínimamente aceptable e inaceptable. Las
categorías deberían ser especificadas para que ambos, el usuario y el desarrollador,
puedan evitar costos innecesarios e incumplimiento de cronogramas. Existen
diferentes perspectivas de la calidad del producto y sus métricas asociadas a las
diferentes etapas del ciclo de vida del software. (Ver Figura 3)
Las Necesidades de Calidad del Usuario pueden ser especificadas como

requerimientos de calidad por las métricas de calidad en uso, por métricas externas y
a veces por métricas internas. Estos requerimientos especificados por las métricas,
deberían ser usados como criterios cuando un producto es validado. Lograr un
producto que satisfaga las necesidades del usuario, normalmente requiere de un
enfoque interactivo en el desarrollo de software, con una continua retroalimentación
desde la perspectiva del usuario.
Los Requerimientos de Calidad Externos especifican el nivel de calidad requerido

desde una perspectiva externa. Estos incluyen requerimientos derivados de las
necesidades de calidad de usuarios, incluyendo calidad en requerimientos de uso. Los
8
requerimientos de calidad externos son usados como los objetivos para la validación
en varias etapas de desarrollo. Los requerimientos de calidad externos para todas las
características de calidad definidas en esta parte, deben ser establecidos en la
especificación de requerimientos de calidad usando métricas externas, deben ser
transformados en requerimientos de calidad internos y deben ser usados como
criterios cuando un producto es evaluado.
Los Requerimientos de Calidad Internos especifican el nivel de calidad requerido

desde la perspectiva interna del producto. Los requerimientos de calidad internos son
usados para especificar propiedades internas de productos. Estos pueden incluir
modelos estáticos y dinámicos, otros documentos y código fuente. Los requerimientos
de calidad internos pueden ser usados como objetivos para la validación en varias
etapas de desarrollo. Ellos también pueden ser usados para definir estrategias de
desarrollo y criterios de evaluación y verificación durante el desarrollo. Esto puede
incluir el uso de métricas adicionales (por ejemplo: reusabilidad). Los requerimientos
específicos de calidad interna deben ser especificados cuantitativamente usando
métricas internas.
La Calidad Interna es la totalidad de características del producto de software desde

una perspectiva interna. La calidad interna es medida y evaluada en base a los
requerimientos internos de calidad. Los detalles de la calidad del producto de software
pueden ser mejorados durante la implementación, revisión y prueba del código fuente
del software, pero la naturaleza fundamental de la calidad del producto de software
representada por la calidad interna, permanece sin cambios a menos que sea
rediseñado.
La Calidad Externa Estimada (o Predicha) es la calidad que es estimada o predicha

para el producto de software final, en cada etapa de desarrollo para cada
característica de calidad, basada en el conocimiento de la calidad interna.
La Calidad Externa es la totalidad de las características del producto de software

desde una perspectiva externa. Es la calidad cuando el software es ejecutado, la cual
es típicamente medida y evaluada en un ambiente simulado, con datos simulados y
usando métricas externas. Durante las pruebas, muchas fallas serán descubiertas y
eliminadas. Sin embargo, algunas fallas todavía pueden permanecer después de las
pruebas. Como es difícil corregir la arquitectura del software u otros aspectos
fundamentales del diseño del software, el diseño fundamental permanece sin cambios
a través de las pruebas.
La Calidad en Uso Estimada (o Predicha) es la calidad que es estimada o predicha

para el producto de software final, en cada etapa de desarrollo para cada
característica de calidad en uso, y se basa en el conocimiento de la calidad externa e
interna.
La calidad externa y la calidad en uso pueden ser estimadas y predichas durante el

desarrollo de cada característica de calidad cuando las tecnologías apropiadas son
desarrolladas. Sin embargo, como actualmente no se proporciona todo el soporte
necesario para el propósito de predicción, se debe desarrollar más tecnología para
mostrar la correlación entre la calidad interna, la calidad externa y la calidad en uso.
9
La Calidad en Uso es la perspectiva del usuario de la calidad del producto de
software cuando éste es usado en un ambiente específico y en un contexto de uso
específico. Esta mide la extensión en la cual los usuarios pueden conseguir sus metas
en un ambiente particular, en vez de medir las propiedades del software en si mismo.
El término 'Usuario' se refiere a cualquier tipo de posible usuario, incluyendo

operadores y personal de mantenimiento, y sus requerimientos pueden ser diferentes.
El nivel de calidad en el ambiente del usuario puede ser diferente del ambiente de
desarrollo, debido a diferencias entre las necesidades y capacidades de diversos
usuarios y diferencias entre hardware y ambientes de soporte. El usuario evalúa sólo
aquellos atributos de software que son usados para sus tareas. Algunas veces, los
atributos de software especificados por un usuario final durante la fase de análisis de
requerimientos, ya no cumplen los requerimientos del usuario cuando el producto está
en uso, debido a cambiantes requerimientos del usuario y a la dificultad de especificar
necesidades implícitas.
1.3.3 Ítems a ser evaluados
Los ítems pueden ser evaluados por medición directa, o de manera indirecta, midiendo
sus consecuencias. Por ejemplo, un proceso puede ser medido indirectamente por la
medición y evaluación de sus productos, y un producto puede ser evaluado
indirectamente por la medición del desempeño de un usuario en sus tareas (usando
métricas de calidad en uso).
El software nunca corre solo sino que siempre es parte de un sistema mayor,
típicamente consistente de otros productos de software con los cuales él tiene
interfaces: hardware, operadores humanos, y flujos de trabajo. El producto de software
completado puede ser evaluado por los niveles de las métricas externas elegidas.
Estas métricas describen su interacción con su entorno, y son medidas al observar el
software en operación. La calidad en uso puede ser medida por la extensión por la
cual un producto empleado por usuarios específicos cumple las necesidades de
alcanzar metas específicas con efectividad, productividad, seguridad y satisfacción.
Esto normalmente será complementado con mediciones de características de calidad
más específicas del producto de software, lo cual también es posible en el proceso
inicial de desarrollo.
En etapas más tempranas de desarrollo, sólo pueden ser medidos los recursos y
procesos. Cuando los productos intermedios (especificaciones, código fuente, etc.) se
tornan disponibles, estos pueden ser evaluados por los niveles de las métricas
internas elegidas. Estas métricas pueden ser usadas para predecir los valores de las
métricas externas. Ellas también pueden ser medidas por derecho propio, al ser pre
requisitos esenciales para la calidad externa.
Se puede hacer una distinción adicional entre la evaluación del producto de software y
la evaluación del sistema en el cual es ejecutado.
Por ejemplo, la confiabilidad de un sistema es medida al observar todas las fallas

originadas por cualquier causa (hardware, software, errores humanos, etc.), mientras
que la confiabilidad del producto de software es medida al extraer de las fallas
10
observadas sólo aquellas que son debidas a faltas en el software (originadas en
requerimientos, diseño o implementación).
Además, depende del propósito de la evaluación y de quienes son los usuarios, el

juzgar dónde están los límites del sistema.
En ese sentido, por ejemplo, si se supone que los pasajeros son los usuarios de un
avión con un sistema de control de vuelo basado en computadora, entonces el sistema
del cual ellos dependen incluye la tripulación, el fuselaje, el hardware y software del
sistema de control de vuelo, mientras que si se toma a la tripulación como los
usuarios, entonces el sistema del cual ellos dependen consiste sólo del fuselaje y el
sistema de control de vuelo.
1.3.4 Usando un modelo de calidad
La calidad de un producto de software se debe evaluar usando un modelo definido. El

modelo de calidad debe ser utilizado al fijar las metas de la calidad para los productos
de software y los productos intermedios. La calidad del producto de software debería
ser jerárquicamente descompuesta en un modelo de calidad constituido por
características y sub características, las cuales se pueden utilizar como lista de
comprobación de las ediciones relacionadas con la calidad. Más adelante se define un
modelo jerárquico de calidad (aunque otras maneras de categorizar la calidad pueden
ser más apropiadas en circunstancias particulares y justificadas).
No es prácticamente posible medir todas las sub características internas y externas

para todas las partes de un gran producto de software. De modo similar, no es
generalmente práctico medir la calidad en el uso para todos los escenarios posibles de
las tareas del usuario. Los recursos para la evaluación necesitan ser asignados entre
los diversos tipos de medida, dependiente de los objetivos de la institución y de la
naturaleza del producto y diseño de procesos.
1.4 Modelo de calidad para la calidad externa e interna
En esta sección se define el Modelo de Calidad para la calidad externa e interna a ser
usado en las instituciones públicas. Se han establecido categorías para las cualidades
de la calidad del software, basadas en seis características (funcionalidad,
confiabilidad, utilidad, eficiencia, capacidad de mantenimiento y portabilidad), que se
subdividen a su vez en sub características (Figura 3). Las sub características se
pueden medir por métrica interna o externa.
11
Calidad externa e
interna
Capacidad de
Funcionalidad Fiabilidad Usabilidad Eficiencia Portabilidad
mantenimiento
Capacidad de ser
Adecuación analizado Adaptabilidad
Madurez Entendimiento Comportamiento
Cambiabilidad Facilidad de
Exactitud Tolerancia a fallas Aprendizaje de tiempos
Estabilidad instalación
Interoperatividad Recuperabilidad Operabilidad Utilización de
Facilidad de Coexistencia
Seguridad recursos
Atracción prueba Reemplazabilidad
Conformidad de Conformidad de
Conformidad de Conformidad de Conformidad de Conformidad de
funcionalidad fiabilidad uso eficiencia
facilidad de portabilidad
mantenimiento
FIGURA 3 – Modelo de calidad para la calidad externa e interna
Las definiciones se dan para cada característica y sub característica de calidad del
software que influye en la calidad. Para cada característica y sub característica, la
capacidad del software es determinada por un conjunto de atributos internos que
pueden ser medidos. Las características y sub características se pueden medir
externamente por la capacidad provista por el sistema que contiene el software.
1.4.1 Funcionalidad
La capacidad del producto de software para proveer las funciones que satisfacen las
necesidades explícitas e implícitas cuando el software se utiliza bajo condiciones
específicas.
Esta característica se refiere a lo que hace el software para satisfacer necesidades,

mientras que las otras características se refieren principalmente a cuándo y a cómo
satisfacen las necesidades.
Para un sistema que es operado por un usuario, la combinación de la funcionalidad,

fiabilidad, usabilidad y eficiencia puede ser medida externamente por su calidad en
uso.
1.4.1.1 Adecuación
La capacidad del producto de software para proveer un adecuado conjunto de
funciones para las tareas y objetivos especificados por el usuario.
Ejemplos de adecuación son la composición orientada a tareas de funciones a
partir de sub funciones que las constituyen, y las capacidades de las tablas.
12
1.4.1.2 Exactitud
La capacidad del producto de software para proveer los resultados o efectos
acordados con un grado necesario de precisión.
1.4.1.3 Interoperabilidad
La capacidad del producto de software de interactuar con uno o más sistemas
especificados. La interoperabilidad se utiliza en lugar de compatibilidad para
evitar una posible ambigüedad con la reemplazabilidad.
1.4.1.4 Seguridad
La capacidad del producto de software para proteger la información y los datos
de modo que las personas o los sistemas no autorizados no puedan leerlos o
modificarlos, y a las personas o sistemas autorizados no se les niegue el
acceso a ellos.
La seguridad en un sentido amplio se define como característica de la calidad

en uso, pues no se relaciona con el software solamente, sino con todo un
sistema.
1.4.1.5 Conformidad de la funcionalidad

La capacidad del producto de software de adherirse a los estándares,
convenciones o regulaciones legales y prescripciones similares referentes a la
funcionalidad.
1.4.2 Fiabilidad
La capacidad del producto de software para mantener un nivel específico de

funcionamiento cuando se está utilizando bajo condiciones especificadas.
El desgaste o envejecimiento no ocurre en el software. Las limitaciones en fiabilidad

son debido a fallas en los requerimientos, diseño, e implementación. Las fallas debido
a estos errores dependen de la manera en que se utiliza el producto de software y de
las opciones del programa seleccionadas, más que del tiempo transcurrido.
La definición de fiabilidad en la ISO/IEC 2382-14:1997 es "la habilidad de la unidad

funcional de realizar una función requerida...". En este documento, la funcionalidad es
solamente una de las características de la calidad del software. Por lo tanto, la
definición de la fiabilidad se ha ampliado a "mantener un nivel especificado del
funcionamiento..." en vez de "...realizar una función requerida".
1.4.2.1 Madurez
La capacidad del producto de software para evitar fallas como resultado de
errores en el software.
13
1.4.2.2 Tolerancia a errores
La capacidad del producto de software para mantener un nivel especificado de
funcionamiento en caso de errores del software o de incumplimiento de su
interfaz especificada.
El nivel especificado de funcionamiento puede incluir la falta de capacidad de

seguridad.
1.4.2.3 Recuperabilidad
La capacidad del producto de software para restablecer un nivel especificado
de funcionamiento y recuperar los datos afectados directamente en el caso de
una falla.
Después de una falla, un producto de software a veces estará no disponible por

cierto período del tiempo, intervalo en el cual se evaluará su recuperabilidad.
La disponibilidad es la capacidad del producto de software para poder realizar

una función requerida en un punto dado en el tiempo, bajo condiciones
indicadas de uso. En extremo, la disponibilidad se puede determinar por la
proporción de tiempo total, durante la cual, el producto de software está en un
estado ascendente. La disponibilidad, por lo tanto, es una combinación de
madurez (con control de frecuencias de fallas), de la tolerancia de errores y de
la recuperabilidad (que gobierna el intervalo de tiempo en cada falla). Por esta
razón es que no ha sido incluida como una sub característica separada.
1.4.2.4 Conformidad de la fiabilidad

La capacidad del producto de software para adherirse a las normas,
convenciones o regulaciones relativas a la fiabilidad.
1.4.3 Usabilidad
La capacidad del producto de software de ser entendido, aprendido, usado y atractivo

al usuario, cuando es utilizado bajo las condiciones especificadas.
Algunos aspectos de funcionalidad, fiabilidad y eficiencia también afectarán la

usabilidad, pero para los propósitos de la ISO/IEC 9126 ellos no son clasificados como
usabilidad.
Los usuarios pueden ser operadores, usuarios finales y usuarios indirectos que están
bajo la influencia o dependencia del uso del software. La usabilidad debe dirigirse a
todo los diferentes ambientes de usuarios que el software puede afectar, o estar
relacionado con la preparación del uso y evaluación de los resultados.
14
1.4.3.1 Entendimiento
La capacidad del producto de software para permitir al usuario entender si el
software es adecuado, y cómo puede ser utilizado para las tareas y las
condiciones particulares de la aplicación.
Esto dependerá de la documentación y de las impresiones iniciales dadas por el

software.
1.4.3.2 Aprendizaje
La capacidad del producto de software para permitir al usuario aprender su
aplicación. Un aspecto importante a considerar aquí es la documentación del
software.
1.4.3.3 Operabilidad
La capacidad del producto de software para permitir al usuario operarlo y
controlarlo.
Los aspectos de propiedad, de cambio, de adaptabilidad y de instalación pueden

afectar la operabilidad.
La operabilidad corresponde a la controlabilidad, a la tolerancia a errores y a la

conformidad con las expectativas del usuario.
Para un sistema que es operado por un usuario, la combinación de la

funcionalidad, confiabilidad, usabilidad y eficacia puede ser una medida
considerada por la calidad en uso.
1.4.3.4 Atracción
La capacidad del producto de software de ser atractivo al usuario.
Esto se refiere a las cualidades del software para hacer el software más atractivo
al usuario, tal como el uso del color y la naturaleza del diseño gráfico.
1.4.3.5 Conformidad de uso

La capacidad del producto de software para adherirse a los estándares,
convenciones, guías de estilo o regulaciones relacionadas a su usabilidad.
1.4.4 Eficiencia
La capacidad del producto de software para proveer un desempeño adecuado, de

acuerdo a la cantidad de recursos utilizados y bajo las condiciones planteadas.
Los recursos pueden incluir otros productos de software, la configuración de hardware

y software del sistema, y materiales (Ej: Papel de impresión o diskettes).
15
Para un sistema operado por usuarios, la combinación de funcionalidad, fiabilidad,
usabilidad y eficiencia pueden ser medidas externamente por medio de la calidad en
uso.
1.4.4.1 Comportamiento de tiempos

La capacidad del producto de software para proveer tiempos adecuados de
respuesta y procesamiento, y ratios de rendimiento cuando realiza su función
bajo las condiciones establecidas.
1.4.4.2 Utilización de recursos

La capacidad del producto de software para utilizar cantidades y tipos
adecuados de recursos cuando este funciona bajo las condiciones
establecidas.
Los recursos humanos están incluidos dentro del concepto de productividad.
1.4.4.3 Conformidad de eficiencia

La capacidad del producto de software para adherirse a estándares o
convenciones relacionados a la eficiencia.
1.4.5 Capacidad de mantenimiento
Capacidad del producto de software para ser modificado. Las modificaciones pueden
incluir correcciones, mejoras o adaptación del software a cambios en el entorno, y
especificaciones de requerimientos funcionales.
1.4.5.1 Capacidad de ser analizado

La capacidad del producto de software para atenerse a diagnósticos de
deficiencias o causas de fallas en el software o la identificación de las partes a
ser modificadas.
1.4.5.2 Cambiabilidad
La capacidad del software para permitir que una determinada modificación sea
implementada.
Implementación incluye codificación, diseño y documentación de cambios.
Si el software va a ser modificado por el usuario final, la cambiabilidad podría

afectar la operabilidad.
1.4.5.3 Estabilidad
La capacidad del producto de software para evitar efectos inesperados debido
a modificaciones del software.
16
1.4.5.4 Facilidad de prueba
La capacidad del software para permitir que las modificaciones sean validadas.
1.4.5.5 Conformidad de facilidad de mantenimiento

La capacidad del software para adherirse a estándares o convenciones
relativas a la facilidad de mantenimiento.
1.4.6 Portabilidad
La capacidad del software para ser trasladado de un entorno a otro. El entorno puede
incluir entornos organizacionales, de hardware o de software.
1.4.6.1 Adaptabilidad
La capacidad del producto de software para ser adaptado a diferentes entornos
especificados sin aplicar acciones o medios diferentes de los previstos para el
propósito del software considerado.
Adaptabilidad incluye la escalabilidad de capacidad interna (Ejemplo: Campos en

pantalla, tablas, volúmenes de transacciones, formatos de reporte, etc.).
Si el software va a ser adaptado por el usuario final, la adaptabilidad

corresponde a la conveniencia de la individualización, y podría afectar la
operabilidad.
1.4.6.2 Facilidad de instalación

La capacidad del producto de software para ser instalado en un ambiente
especificado.
Si el software va a ser instalado por el usuario final, puede afectar la propiedad y

operatividad resultantes.
1.4.6.3 Coexistencia
La capacidad del producto de software para coexistir con otros productos de
software independientes dentro de un mismo entorno, compartiendo recursos
comunes.
1.4.6.4 Reemplazabilidad
La capacidad del producto de software para ser utilizado en lugar de otro
producto de software, para el mismo propósito y en el mismo entorno.
Por ejemplo, la reemplazabilidad de una nueva versión de un producto de

software es importante para el usuario cuando dicho producto de software es
actualizado (actualizaciones, upgrades).
17
Reemplazabilidad se utiliza en lugar de compatibilidad de manera que se evitan
posibles ambigüedades con la interoperabilidad.
La reemplazabilidad puede incluir atributos de ambos, inestabilidad y

adaptabilidad. El concepto ha sido introducido como una sub característica por sí
misma, dada su importancia.
1.4.6.5 Conformidad de portabilidad

La capacidad del software para adherirse a estándares o convenciones
relacionados a la portabilidad.
1.5 MODELO DE CALIDAD PARA LA CALIDAD EN USO
En esta parte se define el modelo de calidad para la calidad en uso. Los atributos de la
calidad en uso están categorizados en cuatro características: eficacia, productividad,
seguridad y satisfacción (Figura 4).
Calidad en uso
eficacia productividad satisfacción seguridad
FIGURA 4 – Modelo de calidad para la calidad en uso
La calidad en uso es la visión de calidad del usuario. Alcanzar la calidad en uso

depende de alcanzar la calidad externa necesaria que a su vez depende de alcanzar
la calidad interna necesaria (Figura 1)
Las medidas son normalmente requeridas en tres niveles: interno, externo y de uso.
Encontrar criterios para las medidas internas, no es normalmente suficiente para
asegurar el logro de criterios para las medidas externas, y encontrar criterios para las
medidas externas, no es normalmente suficiente para asegurar el logro de criterios
para la calidad en uso.
18
1.5.1 Calidad en uso
La capacidad del producto de software para permitirles a usuarios específicos lograr

las metas propuestas con eficacia, productividad, seguridad y satisfacción, en
contextos especificados de uso.
Calidad en uso es la visión de calidad del usuario de un entorno que contiene el

software, y es medida a partir de los resultados de usar el software en el entorno, más
que por las propiedades del software mismo.
1.5.1.1 Eficacia
La capacidad del producto de software para permitir a los usuarios lograr las
metas especificadas con exactitud e integridad, en un contexto especificado de
uso.
1.5.1.2 Productividad
La capacidad del producto de software para permitir a los usuarios emplear
cantidades apropiadas de recursos, en relación a la eficacia lograda en un
contexto especificado de uso.
Los recursos relevantes pueden incluir: tiempo para completar la tarea, esfuerzo
del usuario, materiales o costo financiero.
1.5.1.3 Seguridad
La capacidad del producto de software para lograr niveles aceptables de riesgo
de daño a las personas, institución, software, propiedad (licencias, contratos de
uso de software) o entorno, en un contexto especificado de uso.
Los riesgos son normalmente el resultado de deficiencias en la funcionalidad

(incluyendo seguridad), fiabilidad, usabilidad o facilidad de mantenimiento.
1.5.1.4 Satisfacción
La capacidad del producto de software para satisfacer a los usuarios en un
contexto especificado de uso.
La satisfacción es la respuesta del usuario a la interacción con el producto, e

incluye las actitudes hacia el uso del producto.
19
PARTE 2: MÉTRICAS
2.1 Atributos Internos y Externos
Los niveles de ciertos atributos internos se han encontrado para influir en los niveles
de algunos atributos externos, de modo que haya un aspecto externo y un aspecto
interno en la mayoría de las características. Por ejemplo, la confiabilidad puede ser
medida externamente observando el número de fallas en un período dado del tiempo
de ejecución durante un ensayo del software, e internamente examinando las
especificaciones detalladas y el código fuente para determinar el nivel de la tolerancia
de falla. Los atributos internos serían los indicadores de los atributos externos.
Un atributo interno puede influenciar a una o más características, y una característica

puede estar influenciada por más de un atributo (ver Figura 5). En este modelo la
totalidad de atributos de la calidad del producto de software se clasifica en una
estructura arborescente jerárquica de características y de sub características. El nivel
más alto de esta estructura consiste en características de calidad y el nivel más bajo
consiste en atributos de calidad de software. La jerarquía no es perfecta cuando
algunos atributos pueden contribuir a más de una sub característica.
atributo
Figura 5 – Características de calidad, sub características y atributos
La sub característica puede medirse por la métrica interna o por la métrica externa.
La correlación entre los atributos internos y las medidas externas nunca es perfecta, y
el efecto que un atributo interno dado tiene en una medida externa asociada, será
determinado por la experiencia, y dependerá del contexto particular en que el software
es usado.
De la misma manera, las propiedades externas (como la conveniencia, exactitud,

tolerancia a fallas o tiempos de ejecución) influirán en la calidad observada. Una falla
en la calidad del uso (por ejemplo: el usuario no puede completar la tarea) puede
20
remontarse a los atributos de calidad externa (por ejemplo: conveniencia u
operabilidad) y los atributos internos asociados tienen que ser cambiados.
2.2 Métrica interna
La métrica interna puede ser aplicada a un producto de software no-ejecutable (como

una especificación o código fuente) durante el diseño y la codificación. En el desarrollo
de un producto de software, los productos intermedios deben ser evaluados usando
métricas internas que permitan medir las propiedades intrínsecas, incluyendo aquellas
que pueden derivarse de comportamientos simulados. El propósito primario de esta
métrica interna es asegurar que se logre la calidad externa y la calidad de uso
requerida. La métrica interna proporciona a los usuarios, evaluadores, verificadores y
desarrolladores el beneficio de que puedan evaluar la calidad del producto de software
y lo referido a problemas de calidad antes que el producto de software sea puesto en
ejecución.
Las métricas internas miden atributos internos o indican los atributos externos, a través
del análisis de las propiedades estáticas de productos intermedios o entregables del
software. Las medidas de las métricas internas usan números o frecuencias de
elementos de composición de software, los cuales aparecen, por ejemplo, en las
sentencias de código de fuente, control de gráficos, flujo de datos y estados de
representación de procesos.
2.3 Métrica externa
Las métricas externas usan medidas de un producto de software, derivadas del

comportamiento del mismo, a través de la prueba, operación y observación del
software. Antes de adquirir o usar un producto de software, éste debe ser evaluado
usando las métricas basadas en los objetivos del área usuaria de la institución
relacionados al uso, explotación y dirección del producto, considerando la organización
y el ambiente técnico. La métrica externa proporciona a los usuarios, evaluadores,
verificadores y desarrolladores, el beneficio de que puedan evaluar la calidad del
producto de software durante las pruebas o el funcionamiento.
2.4 Relación entre las métricas internas y externas
Cuando los requisitos de calidad del producto de software son definidos, se listan las
características o sub características de calidad del producto de software que
contribuyen a dichos requisitos. Entonces, las métricas externas apropiadas y los
rangos aceptables son especificados para cuantificar el criterio de calidad que valida
que el software satisface las necesidades del usuario. Luego, los atributos de calidad
interna del software se definen y especifican para planear y finalmente lograr la calidad
externa y calidad en el uso requeridas, para construirlos durante el desarrollo del
producto.
Apropiadas métricas internas y rangos aceptables son especificados para cuantificar

los atributos de calidad interna, así ellos pueden usarse para verificar que el software
intermedio reúne las especificaciones de calidad interna durante el desarrollo.
21
Se recomienda que las métricas internas que se usen tengan en lo posible una fuerte
relación con la métrica externa diseñada, para que ellas puedan ser usadas para
predecir los valores de las métricas externas. Sin embargo, es generalmente difícil
diseñar un modelo teórico riguroso que proporcione una relación fuerte entre la métrica
interna y la externa.
2.5 Calidad en el uso de métricas
La calidad en el uso de métricas mide la extensión de un producto que reúne las

necesidades especificadas por los usuarios para lograr las metas propuestas, con la
efectividad, productividad, seguridad y satisfacción en un contexto de uso específico.
La evaluación de la calidad en uso valida la calidad del producto de software en los
escenarios específicos de tareas de usuario.
La calidad en el uso es la vista del usuario sobre la calidad que el sistema de software
contiene y es medida en términos de resultados de uso del software, en lugar de las
propiedades del propio software. La calidad en el uso es el efecto combinado de
calidad interna y externa para el usuario.
La relación de calidad en el uso con otras características de calidad del producto de

software depende del tipo de usuario:
− El usuario final para quien la calidad en el uso es principalmente un resultado de

funcionalidad, fiabilidad, utilidad y eficacia.
− La persona que mantiene el software para quien la calidad en el uso es un
resultado del mantenimiento.
− La persona que hace portable el software para quien la calidad en el uso es un
resultado de portabilidad.
2.6 Opción de métrica y criterio de medidas
La base en que las métricas son seleccionadas dependerá de las metas de la

institución para el producto y las necesidades del evaluador. Las necesidades son
especificadas por un criterio de medidas. El modelo en esta parte soporta una
variedad de requisitos de evaluación, por ejemplo:
− Un usuario o un área de la institución, podría evaluar la conveniencia de un

producto de software usando las métricas de calidad en el uso.
− Una institución que adquiere, podría evaluar un producto de software contra un
criterio de valores de medidas externas de funcionalidad, fiabilidad, utilidad y
eficacia, o de calidad en el uso.
− Un responsable de mantenimiento, podría evaluar un producto de software usando
métricas para mantenimiento.
− Una persona responsable de la implementación del software en diferentes
ambientes, podría evaluar un producto de software usando métricas de
portabilidad.
− Un desarrollador, podría evaluar un producto de software contra criterios de
22
valores usando medidas internas de cualquiera de las características de calidad.
2.7 Métricas usadas para la comparación
Al informar los resultados del uso de métricas cuantitativas para hacer las
comparaciones entre los productos, el informe mostrará si las métricas son objetivas o
empíricas, usando valores conocidos y reproducibles.
Las comparaciones fiables entre los productos sólo se pueden hacer cuando se usan
métricas rigurosas. Los procedimientos de medición deben medir las características (o
sub características) de calidad del producto de software. Estos exigen ser medidos con
suficiente exactitud para permitir asignar los criterios y hacer las comparaciones.
La concesión debe hacerse para posibles errores de medición causados por

herramientas de medida o errores humanos.
La métrica usada para las comparaciones debe ser válida y suficientemente exacta
para permitir hacer comparaciones fiables. Esto significa que las medidas deben ser
objetivas, empíricas, usando una escala válida, y reproducibles.
• Para ser objetivo, habrá un procedimiento escrito y convenido para asignar el

número o categoría al atributo del producto.
• Para ser empírico, los datos serán obtenidos de la observación o de un

cuestionario psicométricamente válido.
• Para utilizar una escala válida, los datos deberán estar basados en ítems de igual
valor o de un valor conocido. Si una lista de comprobación se utiliza para
proporcionar datos, los ítems deben, si es necesario, ser ponderados.
• Para ser reproducible, el proceso para medir debería producir las mismas medidas
(dentro de las tolerancias apropiadas) que son obtenidas por diferentes personas
haciendo la misma medición del producto de software en diferentes ocasiones.
Las métricas internas deberían también tener valor predictivo, esto es, ellas deben
correlacionarse con algunas medidas externas deseadas. Por ejemplo, una medida
interna de un atributo particular del software debería tener correlación con cierto
aspecto medible de calidad cuando se utiliza el software. Es importante que los
valores asignados a las mediciones coincidan con las expectativas normales. Por
ejemplo, si la medición sugiere que el producto es de alta calidad, entonces ésta
debería ser consistente con el producto, satisfaciendo las necesidades de un
usuario.
23
PARTE 3: PROCESO DE EVALUACIÓN DE SOFTWARE
Todo proceso de evaluación de software deberá partir de una evaluación cualitativa y

derivar en una evaluación cuantitativa, siendo todo el proceso documentado,
cumpliendo los siguientes pasos:
3.1 Establecer el propósito de la evaluación:
Productos intermedios:
• Decidir sobre la aceptación de un producto intermedio de un subcontratista
o proveedor.
• Decidir cuándo un proceso está completo y cuando remitir los productos al
siguiente proceso.
• Predecir o estimar la calidad del producto final.
• Recoger información con objeto de controlar y gestionar el proceso.
• Otros con justificación.
Producto final:
• Decidir sobre la aceptación del producto.
• Decidir cuando publicar el producto.
• Comparar el producto con otros productos competitivos.
• Seleccionar un producto entre productos alternativos.
• Valorar tanto el aspecto positivo, como el negativo, cuando está en uso.
• Decidir cuando mejorar o reemplazar un producto.
• Otros con justificación.
3.2 Identificar el tipo de producto
Especificar el tipo de producto a evaluar, si es un sistema operativo, software de

seguridad, software de ofimática, lenguaje de programación, base de datos,
aplicativo desarrollado, ERP, entre otros. Asimismo, se deberá establecer su
relación con Estándares de Tecnologías de Información y Comunicaciones que
utiliza la Institución; y asegurar la legalidad del producto.
3.3 Especificar el Modelo de Calidad
Se elaborará de acuerdo a lo establecido en la Parte I, y deberá ser aprobado por

el Jefe de Informática o quien haga sus veces.
3.4 Seleccionar métricas
La selección de métricas se obtiene a partir de los atributos especificados en el

Modelo de Calidad. Se agruparán en:
24
• Métricas internas.
• Métricas externas.
• Métricas de uso.
3.5 Establecer niveles, escalas para las métricas
• El área de informática aplicará el tipo de escala de proporción.
• A cada métrica seleccionada le asignará un puntaje máximo de referencia.
• La suma de los puntajes máximos de todas las métricas deberá ser igual a 100
puntos.
• El área de informática podrá establecer niveles de calificación cualitativa en

base a los puntajes como por ejemplo:
o Puntaje mínimo de aprobación.

o Inaceptable, mínimo aceptable, rango objeto, excede los requisitos.
o Insatisfactorio, satisfactorio.
• Se pueden usar números hasta con un decimal de aproximación. (Ejemplos:

4.1, 3.8, 11.7).
• El área de informática podrá establecer, por cada métrica, un puntaje mínimo

de aprobación. En caso no se alcance ese puntaje, se considerará que el
producto de software no cumple con las necesidades de información de la
institución y será rechazado.
3.6 Establecer criterios de valoración
El área de informática elaborará sus procedimientos, con criterios distintos para

diferentes características de calidad, cada uno puede estar expresado en términos
de sub características individuales, o una combinación ponderada de ellas. El
procedimiento puede incluir otros aspectos como el tiempo y costo que contribuyen
a la estimación de la calidad de un producto de software en un entorno concreto.
3.7 Tomar medidas
Para la medición, las métricas seleccionadas se aplican al producto de software.

Los resultados son valores expresados en las escalas de las métricas, definidos
previamente.
25
3.8 Comparar con los criterios
En el paso de puntuación, el valor medido se compara con los criterios

predeterminados.
Se debe elaborar un cuadro de resultados, como el que se aprecia a continuación.
PUNTAJE SOFT. 1 SOFT. 2 ……. SOFT.n

MAX.
Atributos internos (Ai)
• Ai1 PMax. Ai1
• Ai2 PMax. Ai2
• . .
• . .
• Ain PMax Ain
Atributos externos
(Ae)
• Ae1 PMax Ae1
• Ae2 PMax Ae2
.
• .
.
• .
PMax Aen
• Aen
Atributos de uso (Au)

• Au1 PMax Au1
• Au2 PMax Au2
• . .
• . .
• Aun PMax Aun
PUNTAJE TOTAL 100.0
3.9 Valorar resultados
La valoración, que resume un conjunto de niveles calificados, es el paso final del

proceso de evaluación del software.
3.10 Documentación
Todo el proceso de evaluación debe estar documentado, indicando nombres y

apellidos, cargos, procedencia de las personas que participaron en el proceso de
evaluación, especificando las etapas en las que participaron, si es necesario. Este
documento deberá ser aprobado por el Jefe de Informática o quien haga sus veces.
26
GLOSARIO DE TÉRMINOS
Adquiriente
Una organización que adquiere u obtiene un sistema, producto de software o servicio
software de un proveedor.
Atributo
Una característica física o abstracta mensurable de una entidad. Los atributos pueden
ser internos o externos.
Calidad
Son todas las características de una entidad que forman parte de su habilidad para
satisfacer las necesidades propias e implícitas.
Calidad en el empleo
Es la medida en que un producto empleado por usuarios específicos satisface sus
necesidades con efectividad, productividad y entera satisfacción para alcanzar
objetivos o metas en contextos específicos de su empleo.
Calidad externa
La extensión para la cual un producto satisface necesidades explícitas e implícitas
cuando es usado bajo condiciones específicas.
Calidad interna
Es la totalidad de atributos del producto que determinan su habilidad para satisfacer
las necesidades propias e implícitas bajo condiciones específicas.
Calificación
La acción de evaluar el valor medido al nivel de calificación adecuado. Utilizado para
determinar el nivel de calificación asociado con el software para una característica
específica de calidad.
Defecto
Un paso, proceso o definición de dato incorrecto en un programa de computadora.
Desarrollador
Una organización que realiza actividades de desarrollo (incluyendo análisis de los
requisitos, diseño y pruebas de aceptación) durante el proceso del ciclo de vida del
software.
Escala
Un conjunto de valores con propiedades definidas
Ejemplos de tipos de escalas son: una escala nominal que corresponda a un conjunto
de categorías; una escala ordinal que corresponda a un conjunto ordenado de puntos;
una escala de intervalo que corresponda a una escala ordenada con puntos
equidistantes; y una escala de ratios que no sólo tiene puntos equidistantes sino que
27
posee el cero absoluto. Las métricas utilizando escalas nominales u ordinales
producen datos cualitativos, y las métricas utilizando escalas de intervalos o ratios
producen datos cuantitativos.
Falla
La terminación de la capacidad de un producto de realizar una función requerida o su
incapacidad para realizarla dentro de límites previamente especificados.
Firmware
El firmware contiene las instrucciones e información acerca del
funcionamiento de un dispositivo o hardware, generalmente grabado en un chip. Es el
código que rige el comportamiento del mismo.
Indicador
Una medida que se puede utilizar para estimar o para predecir otra medida. Los
indicadores pueden emplearse para evaluar los atributos cualitativos del software y
para calcular los atributos del proceso de desarrollo. Ambos son valores indirectos e
imprecisos de los atributos.
Medición
Actividad que usa la definición de la métrica para producir el valor de una medida.
Medida
Número o categoría asignada a un atributo de una entidad mediante una medición.
Medida directa
Una medida de un atributo que no depende de la medida de ningún otro atributo.
Métrica
Es un método definido de valoración y su escala de valoración.
Las métricas pueden ser internas o externas, directas o indirectas.
Las métricas incluyen métodos para clasificar la data o información cualitativa en
diferentes categorías.
Medida externa
Una medida indirecta de un producto derivada de las medidas del comportamiento del
sistema del que es parte.
El sistema incluye cualquier hardware, software (ya sea software a medida o software
tipo paquete) y usuarios.
El número de fallas encontradas durante las pruebas es una medida externa del
número de fallas en el programa, porque el número de fallas es contado durante la
operación del programa corriendo en un sistema de cómputo.
Las medidas externas pueden ser usadas para evaluar los atributos de calidad
cercanos a los objetivos finales de diseño.
Modelo cualitativo
Es una serie de características y la relación entre las mismas, que conforman la base
de los requerimientos cualitativos específicos y la valoración cualitativa.
28
Módulo de evaluación
Un paquete de tecnología de evaluación para una característica o sub característica
de calidad de un software específico. El paquete incluye métodos y técnicas de
evaluación, entradas a ser evaluadas, datos a ser medidos y recopilados y
procedimientos y herramientas de soporte.
Necesidades implícitas
Necesidades que pueden no haber sido especificadas pero que son necesidades
reales cuando la entidad es usada en condiciones particulares.
Necesidades implícitas son necesidades reales, las cuales pueden no haber sido
documentadas.
Nivel de calificación
Un punto en la escala ordinal que es utilizado para categorizar una escala de medida.
El nivel de calificación habilita al software para ser clasificado de acuerdo con las
necesidades explícitas o implícitas.
Los niveles de clasificación adecuados pueden ser asociados con las vistas diferentes
de calidad, por ejemplo, usuarios, gerentes o desarrolladores.
Producto de software
El conjunto de programas de cómputo, procedimientos, y posible documentación y
datos asociados.
Los productos incluyen productos intermedios y productos para los usuarios, como los
desarrolladores y personal de soporte.
Producto de software intermedio

Es un producto del proceso de desarrollo del software que se emplea para alimentar
una etapa diferente del proceso de desarrollo.
En algunos casos, un producto intermedio puede ser también un producto final.
Proveedor
Una organización que entra a un contrato con el adquiriente para el suministro de un
sistema, producto de software o servicio de software bajo los términos de dicho
contrato.
Servicio
Es una organización que presta servicios de mantenimiento.
Sistema
Una composición integrada que consiste en uno o más procesos, hardware, software,
instalaciones y personas, que proveen una capacidad para satisfacer una necesidad
establecida o un objetivo.
Software
Todo o parte de los programas, procedimientos, reglas y documentación asociada a un
sistema de procesamiento de información.
El software es una creación intelectual que es independiente del medio en el cual fue
grabado.
29
Usuario
Un individuo que utiliza el producto de software para realizar una función específica.
Los usuarios pueden incluir operadores, receptores de los resultados del software,
desarrolladores o personal de soporte de software.
Valoración
Emplear una métrica para asignar uno de los valores de una escala (el mismo que
puede ser un número o categoría) al atributo de una entidad.
La valoración puede ser cualitativa cuando se emplean categorías. Por ejemplo,
algunos de los atributos importantes de los productos de software, tales como el
lenguaje del programa base (ADA, C, COBOL, etc.) son categorías cualitativas.
Valoración indirecta
Es la valoración de un atributo derivada del valor de uno o más atributos diferentes. La
valoración externa de un atributo de un sistema de cómputo (tal como el tiempo de
respuesta a la información alimentada por el usuario) es una valoración indirecta de
los atributos del software, dado que esta medida se verá influenciada por los atributos
del entorno de cómputo, así como por los atributos propios del software.
Valoración interna
Es una valoración del producto en sí, ya sea directa o indirecta.
El número de líneas del código, las valoraciones de complejidad, el número de fallas
encontradas durante el proceso y el índice de señales o alertas, son todas las
valoraciones internas propias del producto en sí.
Valorar (verbo)
Realizar una valoración o estimación.
Valor (sustantivo)
Es el número o categoría que una entidad le asigna a un atributo al efectuar la
valoración.
Valoración Cualitativa
Es una evaluación sistemática del grado o capacidad de una entidad para satisfacer
necesidades o requerimientos específicos.
Dichos requerimientos pueden ser formalmente especificados, por ejemplo, por el área
de desarrollo de sistemas, cuando el producto se diseña por contrato para un usuario
específico, cuando el producto es desarrollado sin un usuario específico, o bien que
se trate de necesidades más generales, como cuando un usuario evalúa los productos
con propósitos de comparación y selección.
Validación
Confirmación por inspección y provisión de evidencia objetiva de que los
requerimientos particulares para un uso específico son alcanzados.
En diseño y desarrollo, la validación está relacionada con el proceso de reexaminación
de un producto para determinar la conformidad con las necesidades del usuario.
La validación es realizada normalmente sobre el producto final bajo condiciones
operacionales definidas. Puede ser necesaria en las fases iniciales.
“Validado” es utilizado para designar el estado correspondiente.
30
Verificación
Confirmación por examen y provisión de evidencia objetiva que los requerimientos
específicos han sido alcanzados.
En diseño y desarrollo, la verificación está relacionada con el proceso de examinar el
resultado de una actividad dada para determinar su conformidad con los
requerimientos definidos para dicha actividad.
“Verificado” es utilizado para designar el estado correspondiente.
31
BIBLIOGRAFÍA
• Norma ISO/IEC 9126-1: 2001 - Software engineering -- Product quality -- Part

1: Quality model.
• Norma ISO/IEC TR 9126-2: 2003 - Software engineering -- Product quality --
Part 2: External metrics.
• Norma ISO/IEC TR 9126-3: 2003 - Software engineering -- Product quality --
Part 3: Internal metrics.
• Norma ISO/IEC 14598-1:1999 - Part 1: General overview.
• Norma ISO/IEC 14598-2:2000 - Part 2: Planning and management.
• Norma ISO/IEC 14598-3:2000 - Part 3: Process for developers.
• Norma ISO/IEC 14598-5:1998 - Part 5: Process for evaluators.
32
Modelos para implantar la mejora continua en la gestión
de empresas de transporte por carretera
La gestión por procesos
La gestión
por procesos
Capítulo 4
Edición MAYO 2005 1
Índice
IV.1 Principios de la gestión de la calidad
IV.2 Factores críticos del éxito
IV.3 El enfoque basado en procesos
IV.4 El modelo ISO 9001:2000
IV.5 Los procesos en la organización
IV.6 El mapa de procesos
IV.7 La mejora de procesos
IV.8 Requisitos para mejorar los procesos
IV.9 Fases de la mejora de procesos
IV.10 La mejora continua y la organización
Capítulo 4
IV.1 PRINCIPIOS DE LA GESTIÓN DE LA CALIDAD
La calidad implica mejorar permanentemente la eficacia y eficiencia de la organización y de sus

actividades y estar siempre muy atento a las necesidades del cliente y a sus quejas o muestras
de insatisfacción. Si se planifican, depuran y controlan los procesos de trabajo, aumentará la
capacidad de la organización y su rendimiento. Pero, además, es necesario indagar con cierta
regularidad sobre la calidad que percibe el cliente y las posibilidades de mejorar el servicio que
recibe.
La calidad percibida por el cliente está condicionada por la forma en que la organización realiza
todas las actividades que repercuten en el servicio que presta a sus clientes (la contratación, las
compras o las subcontrataciones, el mantenimiento, el control del servicio, la documentación, la
detección y corrección de fallos o incidencias a tiempo, la formación adecuada del personal,…).
Los clientes, normalmente, no forman un conjunto homogéneo y, a menudo, es preciso
considerar el cliente en un sentido amplio (consumidor, intermediarios, terceros afectados,
sociedad en general, etc.). Además, los atributos que le satisfacen también han de ser
considerados en un sentido amplio: pueden ser cualesquiera de los elementos que
habitualmente maneja el marketing (especificaciones tangibles, plazo de entrega, trato recibido,
financiación, etc.).
A este escenario se suma un entorno donde los cambios se producen cada vez con más rapidez,
los competidores mejoran continuamente sus productos, los avances tecnológicos inducen
productos sustitutivos y los valores, costumbres y hábitos del consumidor también cambian
haciendo evolucionar las necesidades de los clientes. Todo ello, nos lleva a pensar que si el
objetivo de acertar en la diana (satisfacer al cliente) ya era difícil, ahora la diana se mueve cada
vez más rápidamente (objetivo móvil).
Por esto, los sistemas de gestión de la calidad (SGC) están evolucionando de manera que cada
vez adquieren más relieve los factores que permiten un mejor conocimiento y una ágil adaptación
a las condiciones cambiantes del mercado. Entre estos factores destacamos la visión del
mercado y planteamiento estratégico, el diseño de los procesos clave del negocio y la medición,
análisis y mejora continua.
Cada organización tiene que identificar en qué mercado está actuando y cuáles son las
expectativas de los clientes que tiene (o de los que desearía tener) respecto a los atributos del
servicio que contratan. Para dar credibilidad a su propósito de satisfacer las expectativas y
requisitos del cliente, en el orden de importancia que éste les dé, la organización tiene que
asegurar que cuenta con la voluntad decidida de la Dirección, con los recursos humanos y
materiales suficientes y con un SGC estructurado.
La Dirección (persona o grupo de personas que dirigen y controlan al mas alto nivel una
organización), a través de su liderazgo y sus acciones, puede crear un ambiente en el que el
personal se encuentre completamente motivado e involucrado y en el cual un SGC puede operar
eficazmente.
Se han identificado ocho Principios de gestión de la calidad que pueden ser utilizados por la
Dirección con el fin de conducir a la organización hacia una mejora en el desempeño. Estos ocho
principios se derivan de la experiencia colectiva y el conocimiento de los expertos internacionales
(que participan en el Comité Técnico responsable de desarrollar y mantener actualizadas las
normas) y constituyen la base de las normas de SGC de la familia ISO 9000.
El cuadro adjunto incluye el enunciado de cada uno de estos principios que deberían inspirar la
gestión de las organizaciones1.
1
Puede leer una descripción detallada de los ocho principios, de los posibles beneficios que se derivan de su aplicación y de la
forma en que puede materializarse su aplicación en el documento IV.A1 – Los principios de la gestión de la calidad.
Capítulo 4
PRINCIPIOS BÁSICOS DE LA GESTIÓN DE LA CALIDAD
1. Enfoque al cliente
Las organizaciones dependen de sus clientes y por lo tanto deberían comprender las
necesidades actuales y futuras de los clientes, satisfacer los requisitos de los clientes
y esforzarse en exceder las expectativas de los clientes.
2. Liderazgo
Los líderes establecen la unidad de propósito y la orientación de la organización. Ellos

deberían crear y mantener un ambiente interno, en el cual el personal pueda llegar a
involucrarse totalmente en el logro de los objetivos de la organización.
3. Compromiso del personal
El personal, a todos los niveles, es la esencia de una organización y su total compromiso

posibilita que sus habilidades sean usadas para el beneficio de la organización.
B
4. Enfoque a procesos
Un resultado deseado se alcanza más eficientemente cuando las actividades y los

recursos relacionados se gestionan como un proceso.
5. Enfoque a la gestión
SISTEMA - ORGANIZACIÓN
Sistema - Función X Sistema - Función Y
Proceso A Proceso B Proceso C Proceso D
ACTIVIDAD ACTIVIDAD ACTIVIDAD ACTIVIDAD
1 4 7 10
Identificar, entender y gestionar los procesos interrelacionados como un sistema, ACTIVIDAD

2
ACTIVIDAD
3
ACTIVIDAD
5
ACTIVIDAD
6
ACTIVIDAD
8
ACTIVIDAD
9
ACTIVIDAD
11
ACTIVIDAD
12
contribuye a la eficacia y eficiencia de una organización en el logro de sus objetivos. RESULTADO

1
RESULTADO
2
RESULTADO
3
RESULTADO
4
OBJETIVO OBJETIVO OBJETIVO
A B C
POLÍTICA DE LA CALIDAD
MISION DE LA ORGANIZACIÓN
6. Mejora continua
Planificar
La mejora continua del desempeño global de la organización debería ser un objetivo A P

Act uar
Mejora
permanente de ésta.
Ejecut ar
Continua
C Comprobar D
7. Toma de decisiones basada en hechos

SGC: ANÁLISIS DE DATOS
Las decisiones eficaces se basan en el análisis de los datos y la información.

8. Relaciones mutuamente beneficiosas con los proveedores
Una organización y sus proveedores son interdependientes, y una relación mutuamente

beneficiosa aumenta la capacidad de ambos para crear valor.
Capítulo 4
IV.2 FACTORES CRÍTICOS DEL ÉXITO
Cuando una organización se plantea la mejora global de sus resultados, la primera acción que
debe llevar a cabo es identificar cuál es su posición dentro de su sector de mercado y dentro de
la sociedad para después plantearse los objetivos y metas que espera alcanzar. Para lograr
estos objetivos y metas, la Dirección debe desarrollar la misión, la visión y los valores de la
organización.
La misión es una declaración en la que se describe el propósito o razón de ser de la

organización; la visión es lo que la organización pretende alcanzar a largo plazo y los valores
son la base sobre la que se asienta la cultura de la organización.
Los valores y principios constituyen el soporte para la visión y la misión y son la clave de una
dirección eficaz. Es necesario que las partes interesadas definan una serie de valores y se
aseguren de que se cumplan. Si, por ejemplo, uno de los valores esenciales de una organización
de transporte es “ante todo la calidad”, esta organización no podrá permitirse ofrecer, a
sabiendas, un servicio de dudosa calidad para alcanzar una meta a corto plazo. Saltarse valores
para lograr una misión puede hacerle ganar una batalla, pero en último término hará que pierda
la guerra.
Estos conduce a una caracterización del negocio que obliga a la organización a realizar un
ejercicio de reflexión cuyo resultado ha de permitir dos cosas. Por una parte, definir:
¿quiénes somos y qué pretendemos?

¿qué necesidades internas y externas nos influyen y condicionan?
¿quiénes son nuestros clientes y qué desean?
¿qué requisitos nos impone nuestra empresa?
Por otra parte, determinar los factores críticos de éxito de nuestro negocio. En el gráfico adjunto
se muestran los factores más importantes que pueden influir a la hora de caracterizar a una
organización de transportes:
COMPETENCIA
TENDENCIAS
ECONÓMICAS NORMATIVA
ESTRATEGIA
ACCIONISTAS CONOCIMIENTO
ENTORNO
CLIENTES SISTEMA DE
GESTIÓN
ESTRUCTURA
RECURSOS
INNOVACIÓN
PROVEEDORES TECNOLÓGICA
SOCIEDAD
Factores externos
Factores internos
Capítulo 4
La caracterización del negocio suele plasmarse en la Declaración de Propósitos (DP), que incluye
la misión, la visión y los valores de la organización. Una DP ha de ser fácil de recordar,
contundente y, por consiguiente, relativamente breve2.
Una vez caracterizado el propósito de la organización, es necesario determinar los factores

críticos para el éxito de nuestro negocio (en adelante, FCE). Los FCE son las acciones críticas
para el éxito de una organización. Con ellos pretendemos identificar los resultados que, de no
conseguirse, pueden poner en peligro el éxito del negocio.
Ayudan a distinguir entre lo que es conveniente y lo que es un requisito esencial, con el objetivo
de establecer prioridades
La identificación de los FCE debe incluir factores externos, como los niveles de satisfacción de
los clientes y los vínculos comerciales con los proveedores (por ejemplo, conductores
subcontratados), así como los factores internos, como un personal motivado y bien cualificado.
En la identificación de los FCE han de colaborar todas las partes interesadas en la actividad,
proceso o proyecto a analizar. Este hecho incluye no sólo a todo el personal interno involucrado,
sino también a las partes externas, es decir, a los clientes y a los proveedores o subcontratados.
También es fundamental contar con información sobre el entorno social y legal de la

organización. Así, deberá recopilarse información sobre regulaciones gubernamentales,
evolución previsible de parámetros generales de la economía, datos demográficos, problemas
sociales de conocimiento general, cuestiones medioambientales, situación del entorno local o
regional de la organización, etc. La organización podrá para ello emplear datos procedentes de
publicaciones, informes de organizaciones sectoriales, reuniones con representantes de distintos
grupos sociales, solicitar informes o estudios.
Como punto de partida para identificar los FCE, se debe elaborar un análisis DAFO (Debilidades,
Amenazas, Fuerzas y Oportunidades). Una vez obtenidos los resultados del análisis DAFO, se
clasificarán. Esta categorización deberá ser acorde con la DP. Para saber si esta categorización
es correcta, las partes involucradas deberán analizar si el fracaso de una de estas categorías
podría poner en peligro la consecución de la DP. Si la respuesta es afirmativa, esta categoría
será un FCE3.
Sugerencia:
El número ideal de FCE seleccionados no debiera ser mayor de ocho. Antes que por la
cantidad, hay que esforzarse por la calidad. Lo que se pretende con esto es identificar los
FCE más importantes que representen la mayor parte del éxito de la organización.
Como ejemplo de FCE, podemos tomar los criterios definidos en el modelo de excelencia
empresarial de la EFQM (Fundación Europea para la Gestión de la Calidad). Estos criterios son:
Resultados empresariales
Satisfacción del cliente
Satisfacción del personal
Impacto en la sociedad
Proceso
2
Pueden verse algunos ejemplos de la DP de algunas organizaciones de transporte en el documento IV.A2 – Ejemplos de
Declaraciones de propósitos en organizaciones de transporte.
3
Puede obtenerse más detalles y ejemplos que ayudan a elaborar un DAFO en el documento IV.A3 – Elaboración de un análisis
DAFO en organizaciones de transportes.
Capítulo 4
Dirección del personal

Recursos
Estrategia y política
Liderazgo.
A pesar de que la mayor parte de estos criterios pueden convertirse en FCE, es absolutamente
necesario que cada organización de transporte los interprete a la luz de sus propias circunstancias
y se asegure altos niveles de compromiso y participación por parte de los interesados.
Sugerencia:
Una forma interesante de ser competitivos es realizar sistemáticamente análisis DAFO a

los servicios y organizaciones de la competencia; esto ayuda a descubrir los nichos o
huecos que dejan, lo que nos servirá como argumento de ventas o para entrar en un
determinado mercado.
El proceso general de planificación comienza en el mismo momento en que los máximos directivos
de la organización piensan en los logros futuros que desearían alcanzar y en el tipo de
organización que les gustaría estar dirigiendo.
Es sobre la misión, visión y valores de la organización y teniendo en cuenta toda la información

relativa al entorno y a sus grupos de interés sobre los que debe configurarse la política y
estrategia de la organización. Del mismo modo, la base de la política y estrategia son los
Principios básicos de la gestión de la calidad. El gráfico adjunto ilustra el proceso de definición de
la política y estrategia de una organización.
Principios básicos de la
gestión de la calidad Identificar misión La razón de ser de la organización
Requisitos de los grupos

de interés Establecer visión Estado deseado que se pretende lograr
Establecer factores
Entorno social, legal,
comercial y tecnológico críticos del éxito Conjunto priorizado y ordenado de aspectos clave
Establecer los objetivos Plan a largo plazo

estratégicos para abordar los
factores clave que
no están como
Concretar el Plan
Definir política deberían.
Estratégico
Información Interna
y estrategia
Establecer los objetivos
Plan Anual
anuales

Desplegar los objetivos Acciones concretas
Capítulo 4
IV.3 EL ENFOQUE BASADO EN PROCESOS
La Dirección debe dotar a la organización de una estructura que permita cumplir con la misión y
la visión establecidas. La implantación de la gestión de procesos se ha revelado como una de
las herramientas de mejora de la gestión más efectivas para todos los tipos de organizaciones.
Cualquier actividad, o conjunto de actividades ligadas entre sí, que utiliza recursos y controles
para transformar elementos de entrada (especificaciones, recursos, información, servicios,…) en
resultados (otras informaciones, servicios,…) puede considerarse como un proceso. Los
resultados de un proceso han de tener un valor añadido respecto a las entradas y pueden
constituir directamente elementos de entrada del siguiente proceso, como muestra el gráfico
adjunto.
Elementos básicos de un proceso Interrelaciones entre procesos
R R
RECURSOS
S E S
E PROC A PROC B
E R E R
ENTRADA ACTIVIDADES DEL
SALIDA
C C
PROCESO
S E S
E PROC C PROC D
CONTROLES
C C
Todas las actividades de la organización, desde la planificación de las compras hasta la atención
de una reclamación, pueden y deben considerarse como procesos. Para operar de manera
eficaz, las organizaciones tienen que identificar y gestionar numerosos procesos
interrelacionados y que interactúan. La identificación y gestión sistemática de los procesos que
se realizan en la organización y en particular las interacciones entre tales procesos se conoce
como enfoque basado en procesos.
ISO 9001 pretende fomentar la adopción del enfoque basado en procesos para gestionar una
organización. Este tipo de gestión por procesos, cuando se utiliza en el desarrollo, la
implementación y la mejora de la eficacia de un Sistema de Gestión de la Calidad (SGC),
concentra su atención en:
1 la comprensión y el cumplimiento de los requisitos de los clientes de cada proceso,

2 la necesidad de considerar y de planificar los procesos en términos que aporten valor
(el cliente no debe pagar por algo que no le aporte valor),
3 el control, la medición y la obtención de resultados del desempeño y de la eficacia de
los procesos,
4 la mejora continua de los procesos con base en mediciones objetivas.
Los servicios de transporte se caracterizan por unas condiciones (los medios, el personal, las
condiciones ambientales, etc.) que, en general, nunca se repetirán de forma idéntica. Para
asegurar los resultados es vital generar y establecer procesos con mecanismos de control que
permitan corregir previamente las posibles desviaciones.
La gestión de procesos no va dirigida a la detección de errores en el servicio, sino que la forma

de concebir cada proceso ha de permitir evaluar las desviaciones del mismo, con el fin de
corregir sus tendencias antes de que se produzca un resultado defectuoso.
Capítulo 4
Para que un conjunto de actividades ligadas entre sí conduzcan a un resultado determinado es

necesario definir y controlar el proceso del que forman parte. La importancia de dirigir y controlar
un proceso radica que no es posible actuar directamente sobre los resultados, ya que el propio
proceso conduce a ellos. Para controlar el efecto (resultado) hay que actuar sobre la causa
(proceso).
La gestión por procesos está dirigida a realizar procesos competitivos y capaces de reaccionar
autónomamente a los cambios mediante el control constante de la capacidad de cada proceso, la
mejora continua, la flexibilidad estructural y la orientación de las actividades hacia la plena
satisfacción del cliente y de sus necesidades. Es uno de los mecanismos más efectivos para que
la organización alcance unos altos niveles de eficiencia.
IV.4 EL MODELO ISO 9001:2000
En los últimos años un gran número de organizaciones de transporte implantaron SGC con
objeto de “documentar lo que hacían y hacer lo que documentaban”. Estos SGC venían a ser
simples recopilaciones de la forma de enfocar o cumplir los 20 elementos de la norma ISO
9002:1994. La idea era la de cumplir con todos los requisitos de esta norma, muchas veces de
forma independiente de las necesidades de la propia organización de transporte.
Esta situación llevó a que muchas organizaciones obtuviesen como único beneficio de su SGC la
diferenciación comercial en el mercado con respecto a la competencia por la obtención del
certificado. La revisión en el año 2000 de la familia de normas ISO 9000, introduce un
planteamiento diferente (pasar del aseguramiento de la calidad a la gestión de la calidad),
fundamentado en los ocho Principios de gestión de la calidad, para hacerlos más acordes con los
criterios del modelo de excelencia para la Calidad EFQM.
La siguiente figura ilustra el modelo ISO 9001 de un SGC basado en procesos y refleja
gráficamente la integración de los cuatro pilares básicos de la norma ISO 9001 (Responsabilidad
de la Dirección, Gestión de los recursos, Prestación del servicio y Medición, análisis y mejora).
Dado que es un modelo de todos los procesos del SGC, permite demostrar, por medio de bucles,
la integración vertical y horizontal de los procesos.
Mejora continua del
sistema de gestión de la calidad
Responsabilidad
Clientes de la Dirección Clientes
Gestión de Medición, análisis

recursos y mejora Satisfacción
Entradas Realización Salidas

Requisitos del producto Producto Sali
Leyenda
Actividades que aportan valor Modelo de un SGC basado en
procesos, según ISO 9001
Flujo de información
Capítulo 4
Como ejemplo de bucle vertical,

1 la Dirección define los requisitos en el marco de la "Responsabilidad de la Dirección";
2 los recursos necesarios se determinan y aplican dentro de la "Gestión de recursos";
3 los productos o servicios se producen en el marco de la "Realización del
producto/servicio";
4 los resultados se miden, analizan y mejoran por medio de la "Medición, análisis y
mejora";
5 la revisión por la Dirección cierra el bucle y el ciclo vuelve a “Responsabilidad de la
Dirección” para autorizar los cambios e iniciar el proceso de mejora.
Como ejemplo de un bucle horizontal, el modelo reconoce la importancia que tienen el cliente y
otras partes interesadas para definir los elementos de entrada (las expectativas que tiene el
cliente puestas en el producto o servicio que se le va a ofrecer), así como el seguimiento de la
satisfacción del cliente y de otras partes interesadas para comprobar si la organización ha
satisfecho sus necesidades (si las expectativas que tenían en origen sobre el producto o servicio
se han visto cubiertas).
Cuando los procesos de realización de los productos o de prestación de los servicios se llevan a
cabo, la satisfacción del cliente es evaluada a través de los resultados de los procesos. Los
resultados se usan para mejorar las entradas provenientes de los clientes, completando el
proceso del bucle horizontal. Los bucles verticales y horizontales subordinados serán
descubiertos o creados cuando se pongan en práctica los procesos principales.
El modelo de procesos no trata de reflejar los procesos de forma detallada. Sin embargo, todos
los requisitos del SGC encaminados a lograr la conformidad de los productos o servicios pueden
ser llevados a cabo dentro del modelo. Aunque siempre ha resultado necesario gestionar de uno
u otro modo las relaciones que se plantean entre las diversas actividades que se llevan a cabo
en las organizaciones, lo que aporta el modelo de procesos es que la gestión de las
organizaciones se centra en las actividades que resultan críticas para generar valor añadido.
IV.5 LOS PROCESOS EN LA ORGANIZACIÓN
Para adoptar un enfoque basado en procesos, la organización debe identificar todas y cada una
de las actividades que realiza. A la representación gráfica, ordenada y secuencial de todas las
actividades o grupos de actividades se le llama mapa de procesos y sirve para tener una
visión clara de las actividades que aportan valor al producto/servicio recibido finalmente por el
cliente. En su elaboración debería intervenir toda la organización, a través de un equipo
multidisciplinar con presencia de personas conocedoras de los diferentes procesos.
Una característica importante de los procesos, que queda de manifiesto en cuanto se elabora el
mapa de procesos, es que las actividades que lo constituyen no pueden ser ordenadas de una
manera predeterminada, atendiendo a criterios sólo de jerarquía o de adscripción departamental.
Se puede decir que el proceso cruza transversalmente el organigrama de la organización y se
orienta al resultado, alineando los objetivos de la organización con las necesidades y
expectativas de los clientes, sin atender en sentido estricto a las relaciones funcionales clásicas.
Las actividades de la organización son generalmente horizontales y afectan a varios

departamentos o funciones (comercial, tráfico, administración, etc.), como ilustra el siguiente
gráfico. Esta concepción “horizontal” (actividades o procesos) se contrapone a la concepción
tradicional de organización “vertical” (departamentos o funciones). Esto no significa que los
procesos suplan o anulen las funciones. Como un pastel, se puede organizar por capas pero se
ha de servir por porciones.
Capítulo 4
La gestión de procesos consiste en dotar a la organización de una estructura de carácter

horizontal siguiendo los procesos interfuncionales y con una clara visión de orientación al cliente
final. Los procesos deben estar perfectamente definidos y documentados, señalando las
responsabilidades de cada miembro, y deben tener un responsable y un equipo de personas
asignado.
En este contexto es fundamental la figura del propietario, que es la persona que, además de
ocupar una determinada posición en el organigrama “convencional” (vertical), es responsable de
analizar el proceso, mejorarlo y especialmente conseguir sus objetivos. La organización debe
conocer quién es el propietario de cada uno de los procesos. El propietario asume la
responsabilidad global de la gestión del proceso y de su mejora continua. Por ello, debe tener la
suficiente autoridad para poder implantar los cambios en el proceso que él o el equipo de mejora
del proceso estimen oportuno.
Los procesos en la organización
FUNCION FUNCION FUNCION FUNCION

A B C D
Proceso 1
Proceso 2
En consecuencia, las personas implicadas forman parte de un grupo multidisciplinar que rinde
cuentas al responsable del proceso independientemente de las funciones de cada uno en
relación con el departamento al que pertenece. Esto se conoce como “integración horizontal”
del personal de la organización.
La organización “horizontal” se visualiza como un conjunto de flujos que de forma

interrelacionada consiguen el producto y/o servicio final. Estos flujos están constituidos por todas
las secuencias de actividades que se producen en la organización. La Dirección parte de
objetivos cuantificables (mejora de indicadores) para alcanzar los resultados globales de la
organización (producto o servicio que recibe el cliente final).
La organización “vertical” se visualiza como una agregación de departamentos independientes

unos de otros y que funcionan autónomamente. La Dirección marca objetivos, logros y
actividades independientes para cada departamento y la suma de los logros parciales da como
resultado el logro de los objetivos globales de la organización. La descripción gráfica de la
organización vertical es el organigrama. En el organigrama cada casilla representa
departamentos y jerarquías dentro de la organización.
Capítulo 4
IV.6 EL MAPA DE PROCESOS
Los procesos de una organización se pueden agrupar en tres tipos, como se representa en el gráfico:
1 Procesos clave. Son los procesos que tienen contacto directo con el cliente (los
procesos operativos necesarios para la realización del producto/servicio, a partir de los
cuales el cliente percibirá y valorará la calidad: comercialización, planificación del
servicio, prestación del servicio, entrega, facturación,…).
2 Procesos estratégicos. Son los procesos responsables de analizar las necesidades y
condicionantes de la sociedad, del mercado y de los accionistas, para asegurar la
respuesta a las mencionadas necesidades y condicionantes estratégicos (procesos de
gestión responsabilidad de la Dirección: marketing, recursos humanos, gestión de la
calidad,…).
3 Procesos de soporte. Son los procesos responsables de proveer a la organización de
todos los recursos necesarios en cuanto a personas, maquinaria y materia prima, para
poder generar el valor añadido deseado por los clientes (contabilidad, compras,
nóminas, sistemas de información,…).
PROCESOS ESTRATÉGICOS
ATENCION DISEÑO NUEVOS GESTION

GESTIÓN DE
AL CLIENTE SERVICIOS DE LOS
LA CALIDAD
RECURSOS
EXPECTATIVAS
NECESIDADES
SATISFACCIÓN
PLANIFICACIÓN PRESTACIÓN ENTREGA FACTURACION Y
Y
PEDIDOS
DEL SERVICIO COBRO
PROCESOS CLAVE o DE REALIZACION
CLIENTE CLIENTE
CONTABILIDAD SISTEMAS DE
FORMACION
INFORMACIÓN
PERSONAL IMAGEN Y
COMPRAS
Y NÓMINAS COMUNICACIÓN
PROCESOS DE APOYO
Después de seleccionar los FCE, se deberán identificar todas aquellas actividades que afecten o
puedan afectar a la DP. El siguiente paso es conocer cuáles son los procesos que resultan ser
claves para la consecución de la DP. Para ello se suele utilizar una matriz o tabla que tiene como
objetivo priorizar los procesos que se desarrollan en la organización según su impacto real o
potencial sobre la DP. Esta herramienta permite identificar a esos “pocos procesos” que son
“críticos” en la empresa.
En la columna vertical se anotan los procesos o actividades y en la columna horizontal se anotan

los FCE. A continuación se trata de ir discutiendo y decidiendo el efecto potencial o real de los
FCE en cada uno de los procesos. Recordemos siempre que lo que se está evaluando son las
consecuencias de un proceso sobre un FCE, es decir, de una acción en una reacción. No hay
correspondencia inversa entre los FCE y el proceso.
Capítulo 4
Un ejemplo de esta matriz puede verse en el gráfico adjunto.
Costes servicios
rec. financieros
especialización
FCE
Disponibilidad
Adaptación a
instalaciones
Dimensiones
Servicios no
variaciones
Precio alto
conformes
Plazo de
entrega
Imagen
PROCESOS
Comercial
Gestión tráfico
Gestión almacén
Facturación
Gestión recursos humanos
Mantenimiento flota
Compras y contrataciones
Mejora continua
Seguimiento calidad
Gestión sist. informáticos
Gestión incidencias
administración
Vigilancia
Imagen corporativa
Planificación estratégica
Leyenda: Relación alta

Relación media
Relación baja o nula
Sugerencia:
Hay que tener en cuenta que una actividad o proceso puede tener consecuencias en
muchos resultados y, al mismo tiempo, que un resultado puede estar influido por muchas
actividades.
Suele ser habitual que las organizaciones no identifiquen TODOS los procesos clave para
la consecución de la DP, como por ejemplo, el proceso de facturación.
Una vez analizados todos los procesos, debe realizarse una clasificación de los mismos por
orden de puntuación y, a continuación, deberá discutirse el resultado. Para clasificar los procesos
suelen utilizarse métodos de puntuación como, por ejemplo, asignar 3 puntos a relación alta, 2
puntos a relación media, etc.
Capítulo 4
Sugerencia:
Es muy importante la selección de los procesos clave ya que sobre ellos se va a centrar la
gestión de la organización.
Es interesante establecer comparaciones entre procesos. Por ejemplo, si se calificó a un

proceso anterior de alta relación respecto a un FCE, pero uno posterior demostró ser
mucho más fuerte, entonces el primer proceso tendría que ser cambiado a relación media.
Los procesos clave inciden de un modo directo en la prestación del servicio/satisfacción del
cliente externo de la organización y, por tanto, están directamente relacionados con la misión de
la organización (los objetivos de negocio) y, en general, consumen gran parte de los recursos de
la misma. Constituyen la secuencia de valor añadido, desde la comprensión de las necesidades
del cliente hasta la recepción del producto/servicio por el cliente.
Por otra parte, en la mayoría de los casos se puede afirmar que todos los procesos que influyen
directamente en la satisfacción del cliente, también lo hacen en los resultados económicos, al
depender estos últimos de la respuesta de los clientes hacia los servicios de la organización.
La relación de procesos clave deberá ser revisada y mejorada periódicamente y siempre que la
organización cambie alguno de los procesos de la misma. En cada momento deberá asegurarse
que los procesos clave son aquellos que más contribuyen a lograr la misión de la organización.
El siguiente gráfico muestra los pasos para identificar los procesos clave para la satisfacción de
los clientes.
Identificación expectativas cliente

Valoración expectativas
Servicio esperado
Áreas críticas de mejora

Identificación
Valoración satisfacción clientes de procesos
clave para la
Benchmarking competencia Servicio percibido
satisfacción del
cliente
Análisis de procesos
Indicadores de proceso Servicio prestado
Una vez se han identificado todos los procesos de la organización (mapa de procesos), el paso
siguiente es definir y documentar cada proceso. Esto puede hacerse:
1 preparando procedimientos escritos,

2 representándolos gráficamente (por ejemplo, mediante diagrama de flujo),
3 mediante información, check list, datos, etc.
La documentación de los procesos debe respetar tres criterios:
minimizar el papeleo,
facilitar la comprensión, y
permitir el trabajo en equipo.
Capítulo 4
En breve, la definición ha de hacer posible que el proceso sea gestionado y mejorable. Para ello,
el proceso debe:
1 tener la finalidad del proceso bien definida,

2 tener bien identificados proveedores y clientes,
3 tener objetivos cuantitativos y cualitativos,
4 tener un responsable del proceso (propietario),
5 tener definidos los límites concretos (inicio y final bien definidos),
6 tener asignados recursos para el proceso,
7 tener algún sistema de medida,
8 que el proceso opere bajo control,
9 que el proceso esté documentado, y
10 que el proceso tenga interrelaciones definidas4.
IV.7 LA MEJORA DE PROCESOS
En resumen, los pasos a seguir para adoptar un enfoque basado en procesos son:
1. Constituir un equipo de trabajo con capacitación adecuada y analizar los objetivos y
actividades de la organización.
2. Identificar los procesos, clasificarlos y elaborar el mapa de procesos.
3. Determinar los factores clave para la organización.
4. Elaborar el diagrama de flujo de cada proceso.
5. Establecer el panel de indicadores de cada proceso.
6. Iniciar el ciclo de mejora sobre la base de los indicadores asociados a los factores
clave.
ISO 9001 orienta sobre los aspectos del SGC que es importante documentar y sobre cómo
deben documentarse, pero el hecho de documentar un proceso no excluye que, con el tiempo,
puedan incorporarse mejoras o encontrar otras formas más adecuadas para realizar las
actividades. Cuando, a pesar de realizar correctamente las actividades definidas para el proceso,
aparecen problemas (quejas de los destinatarios, despilfarro de recursos, etc.), o se constata que
el proceso no se adapta a lo que necesita el cliente (necesidad de reestructurar el proceso), es
necesario aplicar el ciclo de mejora.
Una acción de mejora es toda acción destinada a cambiar la forma en que se está
desarrollando un proceso. Estas mejoras, se deben reflejar en una mejora de los indicadores del
proceso. Se puede mejorar un proceso mediante aportaciones creativas, imaginación y sentido
crítico. Dentro de esta categoría entran, por ejemplo:
1 simplificar y eliminar burocracia (simplificar el lenguaje, eliminar duplicidades,…),

2 normalizar la forma de realizar las actividades,
3 mejorar la eficiencia en el uso de los recursos,
4 reducir el tiempo de ciclo,
5 análisis del valor, y
6 alianzas (con proveedores,…).
Vivimos en una época de cambios constantes en la que haber llegado a puerto tan sólo asegura
el punto de partida de la siguiente jornada. La mejora continua es un proceso estructurado en el
que participan todas las personas de la organización con el objeto de incrementar
progresivamente la calidad, la competitividad y la productividad, aumentando el valor para el
cliente y aumentando la eficiencia en el uso de los recursos, en el seno de un entorno cambiante.
4
Un amplio detalle sobre cómo hacer la definición y despliegue de los procesos en una organización de transportes puede verse
en el documento IV.A4 – Arquitectura de procesos.
Capítulo 4
La aplicación continuada de esta estrategia produce beneficios para los clientes (mejor
cumplimiento de sus requisitos), para la organización (mayor sensibilidad para detectar
oportunidades y aumentar la eficiencia) y para las personas (aumento de la capacidad, la
motivación y la satisfacción por el trabajo realizado).
Algunos de los beneficios que se derivan de una adecuada mejora de procesos son:
Se disminuyen recursos (materiales, personas, dinero, mano de obra, etc.),
aumentando la eficiencia.
Se disminuyen tiempos, aumentando la productividad.
Se disminuyen errores, ayudando a prevenirlos.
Se ofrece una visión sistemática de las actividades de la organización.
Uno de los problemas que puede presentársele a una organización de transporte que trabaje
según áreas funcionales (que son la mayoría) es que cuando se disponga a mejorar algo lo haga
de una forma intuitiva, sin analizar realmente cuales son aquellas actividades que consumen más
recursos. Este problema se previene con la técnica de la mejora de procesos:
La visión global de las actividades de la organización y el análisis sistemático de éstas
impiden que alguna quede sin mejorar.
Permite a la organización centrarse en el cliente. Como todo el rediseño de los
procesos se hace pensando en el cliente, resulta casi obligatorio centrarse en éste.
Permite evaluar el "valor añadido" de todas y cada una de las actividades de la
organización y, por tanto, resulta más sencillo intentar eliminar las actividades sin "valor
añadido" y buscar la forma de aumentar éste en todas las acciones que ya lo tengan.
Mejora la "calidad total" en todas las actividades de la organización. Dado que la
calidad la define el cliente y la concentración en éste es máxima, esta mejora buscada
ayuda a la calidad pretendida, coincidiendo muchos de los objetivos de ambas.
Mejora las relaciones y la comunicación. El simple hecho de trabajar con procesos ya
implica un cierto cambio de mentalidad, tendente ésta a ser más participativa,
pensándose más en compañeros en busca de un resultado definido que en empleados
que trabajan. Todo este cambio provoca una mejora en la comunicación y en las
relaciones entre las personas.
IV.8 REQUISITOS PARA MEJORAR LOS PROCESOS
La mejora continua de los procesos es una estrategia que permite a las organizaciones generar
valor de modo continuo, adaptándose a los cambios en el mercado y satisfaciendo
permanentemente las necesidades y expectativas cada vez más exigentes de sus clientes.
Las mejoras en los procesos podrán producirse de dos formas, de manera continua o mediante
reingeniería de procesos. La mejora continua de procesos optimiza los procesos existentes,
eliminando las operaciones que no aportan valor y reduciendo los errores o defectos del proceso.
La reingeniería, por el contrario, se aplica en un espacio de tiempo limitado y el objetivo es
conseguir un cambio radical del proceso sin respetar nada de lo existente.
Para la mejora de los procesos, la organización deberá estimular al máximo la creatividad de sus
empleados y además deberá adaptar su estructura para aprovecharla al máximo. Algunos de los
requisitos para la mejora de procesos se describen a continuación:
Apoyo de la Dirección.
Nadie va a poner todo su entusiasmo en algo que a la Dirección le resulte indiferente y
pocas personas se comprometerán a algún cambio si éste no está respaldado por la
cúpula de la organización. Por ello, el primer requisito para una mejora de los procesos
en cualquier organización es que la Dirección de ésta lo respalde y apoye totalmente.
Capítulo 4
Compromiso a largo plazo.

Resulta muy difícil obtener resultados satisfactorios y comprobables a corto plazo. Es
necesario saber que surgirán muchos problemas y dificultades que habrá que
solucionar y... esto lleva tiempo.
Metodología disciplinada y unificada5.
Es necesario que todos los integrantes de cada proceso trabajen con la misma
metodología y que se cumpla ésta. Surgirán momentos de desaliento y frustración en
los que algunos pensarán "tirar por su lado" y "hacerlo a su manera", pero... ¿qué
ocurriría si todos hicieran lo mismo pero cada persona actuara de forma distinta? ¿No
es verdad que difícilmente se alcanzarían resultados satisfactorios?. Por ello, es
aconsejable que todos trabajen con igual metodología y que ésta sea lo más
disciplinada posible.
Debe haber siempre una persona responsable de cada proceso (propietario).
Se deben desarrollar sistemas de evaluación y retroalimentación.
Todos los trabajadores tienen derecho a saber "cómo lo están haciendo" y si van en el
camino correcto y todos los directivos tienen la obligación de hacérselo saber a sus
subordinados o, al menos, de facilitarles las herramientas para que ellos mismos se
autoevalúen.
Centrarse en los procesos y éstos en los clientes.
Esto es fundamental. Esta forma de trabajar está basada en que los resultados que
pretende cualquier organización provienen de determinados "procesos" y, por tanto,
éstos son los que hay que mejorar, antes que el trabajo individual de cada persona.
Por otra parte, si una organización de transporte disminuye sus costos al máximo,
obtiene una excelente producción con unos mínimos recursos. O sea, es muy
productiva..., pero si sus clientes prefieren los servicios de transporte de otras
organizaciones, ¿de qué le vale disminuir sus costes y aumentar su productividad?
Llegará a ser la organización de transporte en quiebra más productiva del mundo... Por
ello hay que centrarse en el cliente y en la satisfacción de sus necesidades y deseos,
antes que nada.
Sugerencia:
La idea de que una organización es un proceso de satisfacción al cliente y no un proceso
de producción de bienes y servicios es vital para todo empresario.
La organización empieza por el cliente y sus necesidades y no por una patente, una
materia prima o la habilidad para vender; parte de las necesidades del cliente.
Theodore Levitt.
IV.9 FASES DE LA MEJORA DE PROCESOS
Cuatro son las fases necesarias para comprender y poder mejorar continuamente los procesos.
La descripción y el detalle de cada una de ellas sigue a continuación.
5
Puede verse una descripción de herramientas útiles (modelo ISAMA, equipos de mejora, orden y limpieza, 6 Sigma, etc.) en el
documento IV.A5 – Algunas herramientas para la mejora de los procesos.
Capítulo 4
1ª Fase: Planificar
1. Definir la misión del proceso de forma que permita la comprensión del valor añadido del
mismo respecto de su contribución a la misión general de la organización.
2. Comprender los requisitos del cliente como primer paso para la mejora de calidad.
3. Definir indicadores sólidos y consistentes que permitan la toma de decisiones respecto de la
mejora de la calidad. Es necesario estar seguro de que los datos en todo momento reflejan la
situación actual y que son coherentes con los requisitos6.
4. Evaluar el proceso identificando las ayudas y barreras existentes en el entorno y los puntos
fuertes y áreas de oportunidad del proceso en si El resultado de la evaluación nos permitirá
detectar las áreas de mejora a contemplar. Se pueden utilizar las herramientas para la
calidad descritas en el capítulo 1 (El mapa de la calidad). En particular, conviene determinar
los beneficios que la aplicación del “benchmarking” puede aportar, en cuanto al conocimiento
de prácticas adecuadas para obtener las mejoras de rendimiento necesarias.
5. Asignar un responsable de proceso que lidere la mejora continua de la eficacia y la eficiencia,
identificar las acciones adecuadas para garantizar la mejora del rendimiento y convertirlas en
planes detallados de mejora.
2ª Fase: Ejecutar
6. Llevar a cabo los planes de mejora, detallando el diseño propuesto para la solución de cada
problema.
3ª Fase: Comprobar
7. Probar y aportar pruebas que confirmen que el diseño y sus hipótesis son correctos.
8. Comparar el diseño con el resultado de las pruebas, buscando las causas del éxito o fracaso
de la solución adoptada.
4ª Fase: Actuar
9. Comparar los resultados de los indicadores con los resultados previos (comprobando de esta
forma si cada acción produce la mejora esperada, especialmente en lo relativo a la
satisfacción del cliente).
10. Si las pruebas confirman la hipótesis corresponde normalizar la solución y establecer las
condiciones que permitan mantenerla. En caso contrario, corresponde iniciar un nuevo ciclo,
volviendo a la fase de planificación (fijando nuevos objetivos, mejorando la formación del
personal, modificando la asignación de recursos, etc.).
IV.10 LA MEJORA CONTINUA Y LA ORGANIZACIÓN
Una organización es una unidad viva (conjunto de personas proveedoras) que pretende
sobrevivir en un determinado entorno. Para ello, a partir del análisis del mismo, lleva a cabo una
serie de actividades (procesos) dirigidas a añadir valor a recursos propios y ajenos,
transformándolos así en recursos requeridos por otras organizaciones (conjunto de personas
cliente). La voluntad y capacidad de adaptarse a las necesidades de los clientes y la voluntad y
capacidad de añadir valor, son las bases conceptuales a partir de las cuales la mejora continua
se convierte en una forma de hacer las cosas, en un estilo.
6
Una descripción detallada sobre diseño, implantación, explotación y revisión de indicadores de procesos puede leerse en el
documento IV.A6 – Gestión de indicadores.
Capítulo 4
Es necesario que las personas conozcan la situación de partida previa a sus esfuerzos y luego
dispongan de los resultados de sus esfuerzos y los logros conseguidos (por ejemplo, el nivel de
reclamaciones existentes en función de los servicios realizados y el correspondiente porcentaje
de reducción de reclamaciones conseguido).
El hecho de que todo el personal conozca la evolución de los indicadores de calidad o los
objetivos y el que se ponga de manifiesto el buen o mal funcionamiento de las actividades que
afectan a la calidad en la organización es lo que debe mover a las personas a que trabajen en un
determinado sentido.
La organización debe tener definidos sus objetivos y su política de la calidad y contar con el
apoyo de los empleados, comprometidos todos con el fin de dar el mejor servicio posible en todo
momento y de aumentar la eficiencia y los beneficios económicos para la organización. Cada
empleado debe saber en qué medida afectará la gestión de la calidad a su trabajo y debe existir
un consenso general en que la implantación del sistema es por el interés de la organización y en
que aportará ventajas a todas sus áreas.
La Dirección debe fomentar el trabajo en equipo y una cultura empresarial basada en los
resultados, la responsabilidad y el compromiso de sus empleados. Debe crear equipos que sean
capaces de gestionar y mejorar los procesos en los que intervienen. Cuando la Dirección asume
realmente el liderazgo de la gestión de la calidad y se convierte en la impulsora del proceso de
mejora continua en su organización, debe hacerlo involucrando de manera estable a todo el
personal (basarse en voluntarios que se reúnen fuera del horario de trabajo, no ayuda a poner de
relieve que el tema tiene gran importancia).
Es necesario que cada empleado conozca exactamente lo que se espera de él y cómo será
evaluada su contribución a los objetivos de la organización. Las personas se han de implicar en
la detección de errores y en la elaboración de estrategias de mejora. La Dirección debe ser
capaz de motivar y reconocer a sus empleados. Reconocer significa comunicarles y hacerles
saber que la organización aprecia y valora su labor y su esfuerzo. El reconocimiento es una
poderosa fuerza que puede aportar a los empleados:
Ganas de pertenecer a la organización.
Sentimiento de grupo.
Ganas de trabajar y de esforzarse.
Autoestima personal y de grupo7.
La mejora continua es un valor que no puede ser impuesto a los empleados, sino que tiene que
salir de ellos mismos. Conseguir que los empleados puedan aportar lo mejor de si mismos y así
garantizar el éxito en la mejora continua de la organización exige gestionar tres requisitos, como
muestra el siguiente gráfico.
7
Pueden leerse algunas orientaciones sobre aspectos de la calidad y recursos humanos en el documento IV.A7 – Aspectos de la
gestión de la calidad relacionados con el factor humano.
Capítulo 4
Poder
Querer
Motivación Sistema
Trabajo
bien hecho
Formación
Saber
1. QUERER.- Tener la intención determinada de participar en la mejora continua es el primer

requisito. Para ello un clima de comunicación abierta y honesta y la práctica del
reconocimiento son elementos básicos a construir mediante el adecuado rol de la Dirección.
2. SABER.- El segundo requisito consiste en canalizar adecuadamente la energía creativa de
las personas hacia la mejora continua. Para ello, debe asegurarse que las personas están
comprometidas con la satisfacción del cliente (saber qué mejorar) y disponen de la formación
necesaria para poder mejorar los procesos (saber cómo mejorar).
3. PODER.- Materializar el beneficio de la mejora continua exige invertir no sólo en horas sino
también en recursos. Así pues, es preciso proveer a las personas de la delegación de poder y
los recursos necesarios para hacer realidad todo el potencial de mejora identificado.
Conviene destacar la labor de los mandos intermedios en la mejora continua y en la gestión

de la calidad en la organización:
Explican las políticas y objetivos de la Dirección mediante un lenguaje sencillo y en el

contexto operativo de los empleados.
Deben llevar a la práctica las ideas de la Dirección, mediante la asignación de
recursos, prioridades y tareas, el control de los resultados (indicadores) y la toma de
las acciones adecuadas si se producen desviaciones respecto a los planes.
Deben motivar y animar a los empleados a que logren los objetivos fijados por la
Dirección, contando con su propio entusiasmo y carisma, con gratificaciones
económicas, con la adecuada delegación de responsabilidades, con el establecimiento
de objetivos colectivos y personales (si es el caso) bien claros, con la formación del
personal, etc.
Capítulo 4
Desarrollo Orientado a
Objetos con UML
Xavier Ferré Grau, María Isabel Sánchez Segura

Facultad de Informática – UPM
Desarrollo Orientado a Objetos con UML
Índice
I UML ...............................................................................................................................1
I.1 Introducción...........................................................................................................................................................1
II NOTACIÓN BÁSICA UML .......................................................................................3
II.1 Modelos..................................................................................................................................................................3
II.2 Elementos Comunes a Todos los Diagramas ...............................................................................................3

II.2.1 Notas.................................................................................................................................................................3
II.2.2 Dependencias..................................................................................................................................................3
II.3 Diagramas de Estructura Estática..................................................................................................................4

II.3.1 Clases ...............................................................................................................................................................4
II.3.2 Objetos.............................................................................................................................................................5
II.3.3 Asociaciones ...................................................................................................................................................5
II.3.3.1 Nombre de la Asociación y Dirección................................................................................................5
II.3.3.2 Multiplicidad...........................................................................................................................................6
II.3.3.3 Roles.........................................................................................................................................................6
II.3.3.4 Agregación ..............................................................................................................................................7
II.3.3.5 Clases Asociación ..................................................................................................................................7
II.3.3.6 Asociaciones N-Arias............................................................................................................................7
II.3.3.7 Navegabilidad.........................................................................................................................................8
II.3.4 Herencia...........................................................................................................................................................8
II.3.5 Elementos Derivados.....................................................................................................................................9
II.4 Diagrama de Casos de Uso ...............................................................................................................................9

II.4.1 Elementos........................................................................................................................................................9
II.4.1.1 Actores.....................................................................................................................................................9
II.4.1.2 Casos de Uso...........................................................................................................................................9
II.4.1.3 Relaciones entre Casos de Uso............................................................................................................9
II.5 Diagramas de Interacción...............................................................................................................................10

II.5.1 Diagrama de Secuencia...............................................................................................................................10
II.5.2 Diagrama de Colaboración.........................................................................................................................11
II.6 Diagrama de Estados........................................................................................................................................12
III NOTACIÓN AVANZADA UML .............................................................................14
III.1 Modelado Dinámico........................................................................................................................................14

III.1.1 Diagramas De Actividades........................................................................................................................14
III.1.2 Contenido del diagrama de actividades ..................................................................................................14
III.1.2.1 Estados de actividad y estados de acción .......................................................................................14
III.1.2.2 Transiciones.........................................................................................................................................15
III.1.2.3 Bifurcaciones.......................................................................................................................................16
III.1.2.4 División y unión..................................................................................................................................16
III.1.2.5 Calles ....................................................................................................................................................16
III.2 Modelado Físico De Un Sistema OO..........................................................................................................17
i
III.2.1 Componentes...............................................................................................................................................17
III.2.1.1 Interfaces..............................................................................................................................................18
III.2.1.2 Tipos de componentes .......................................................................................................................19
III.2.1.3 Organización de componentes..........................................................................................................19
III.2.1.4 Estereotipos de componentes............................................................................................................19
III.2.2 Despliegue ...................................................................................................................................................19
III.2.2.1 Nodos....................................................................................................................................................19
III.2.2.2 Nodos y componentes........................................................................................................................20
III.2.3 Diagramas de Componentes .....................................................................................................................21
III.2.3.1 Algunos conceptos .............................................................................................................................21
III.2.3.2 Usos más comunes .............................................................................................................................21
III.2.4 Diagramas de Despliegue..........................................................................................................................22
III.2.4.1 Técnicas más comunes de modelado ..............................................................................................22
III.2.5 Arquitectura del Sistema ...........................................................................................................................23
III.2.5.1 Arquitectura de tres niveles ..............................................................................................................23
III.2.5.2 Arquitectura de tres niveles orientadas a objetos..........................................................................23
III.2.5.3 Arquitectura MULTI-nivel ...............................................................................................................23
III.2.5.4 Paquetes................................................................................................................................................24
III.2.5.5 Identificación de Paquetes.................................................................................................................24
IV DESARROLLO ORIENTADO A OBJETOS ......................................................25
IV.1 Proceso de Desarrollo.....................................................................................................................................25

IV.1.1 Visión General............................................................................................................................................25
IV.2 Fase de Planificación y Especificación de Requisitos.............................................................................27

IV.2.1 Actividades..................................................................................................................................................27
IV.2.2 Requisitos ....................................................................................................................................................27
IV.2.3 Casos de Uso...............................................................................................................................................28
IV.2.3.1 Casos de Uso de Alto Nivel..............................................................................................................28
IV.2.3.2 Casos de Uso Expandidos.................................................................................................................28
IV.2.3.3 Identificación de Casos de Uso........................................................................................................30
IV.2.3.4 Identificación de los Límites del Sistema ......................................................................................30
IV.2.3.5 Tipos de Casos de Uso ......................................................................................................................30
IV.2.3.6 Consejos Relativos a Casos de Uso.................................................................................................31
IV.2.4 Construcción del Modelo de Casos de Uso ...........................................................................................32
IV.2.5 Planificación de Casos de Uso según Ciclos de Desarrollo................................................................33
IV.2.5.1 Caso de Uso Inicialización...............................................................................................................34
IV.3 Fase de Construcción: Análisis ....................................................................................................................34

IV.3.1 Actividades..................................................................................................................................................34
IV.3.2 Modelo Conceptual....................................................................................................................................35
IV.3.2.1 Identificación de Conceptos .............................................................................................................35
IV.3.2.2 Creación del Modelo Conceptual ....................................................................................................36
IV.3.2.3 Identificación de Asociaciones ........................................................................................................36
IV.3.2.4 Identificación de Atributos ...............................................................................................................37
IV.3.3 Glosario........................................................................................................................................................38
IV.3.4 Diagramas de Secuencia del Sistema......................................................................................................38
IV.3.4.1 Construcción de un Diagrama de Secuencia del Sistema............................................................39
IV.3.5 Contratos de Operaciones .........................................................................................................................39
IV.3.5.1 Construcción de un Contrato............................................................................................................40
IV.3.5.2 Post-condiciones.................................................................................................................................41
IV.3.6 Diagramas de Estados................................................................................................................................41
IV.4 Fase de Construcción: Diseño ......................................................................................................................41

IV.4.1 Actividades..................................................................................................................................................41
IV.4.2 Casos de Uso Reales..................................................................................................................................42
IV.4.3 Diagramas de Colaboración......................................................................................................................42
IV.4.3.1 Creación de Diagramas de Colaboración.......................................................................................42
ii
IV.4.4 Diagrama de Clases de Diseño.................................................................................................................43

IV.4.4.1 Relaciones de Dependencia para Representar Visibilidad entre Clases ...................................44
IV.4.4.2 Construcción de un Diagrama de Clases de Diseño.....................................................................45
IV.4.4.3 Navegabilidad .....................................................................................................................................46
IV.4.4.4 Visibilidad de Atributos y Métodos ................................................................................................46
IV.4.5 Otros Aspectos en el Diseño del Sistema...............................................................................................46
IV.5 Fases de Implementación y Pruebas...........................................................................................................46
V BIBLIOGRAFÍA........................................................................................................47
iii
I.1 Introducción 1
I UML
I.1 Introducción
UML (Unified Modeling Language) es un lenguaje que permite modelar, construir y
documentar los elementos que forman un sistema software orientado a objetos. Se ha convertido
en el estándar de facto de la industria, debido a que ha sido concebido por los autores de los tres
métodos más usados de orientación a objetos: Grady Booch, Ivar Jacobson y Jim Rumbaugh.
Estos autores fueron contratados por la empresa Rational Software Co. para crear una notación
unificada en la que basar la construcción de sus herramientas CASE. En el proceso de creación
de UML han participado, no obstante, otras empresas de gran peso en la industria como
Microsoft, Hewlett-Packard, Oracle o IBM, así como grupos de analistas y desarrolladores.
Figura 1 Logo de UML
Esta notación ha sido ampliamente aceptada debido al prestigio de sus creadores y debido a que
incorpora las principales ventajas de cada uno de los métodos particulares en los que se basa:
Booch, OMT y OOSE. UML ha puesto fin a las llamadas “guerras de métodos” que se han
mantenido a lo largo de los 90, en las que los principales métodos sacaban nuevas versiones que
incorporaban las técnicas de los demás. Con UML se fusiona la notación de estas técnicas para
formar una herramienta compartida entre todos los ingenieros software que trabajan en el
desarrollo orientado a objetos.
Booch’91 OMT - 1 Otros Métodos OOSE
Booch’93 OMT - 2
Unified Method 0.8 OOPSLA’95

Revisión por
parte del
público
UML 0.9 y 0.91 Junio del 96 y Octubre del 97
Experiencia de las
empresas participantes en
UML
UML 1.0 Enero del 97
UML 1.1 Septiembre del 97
Figura 2 Historia de UML
Desarrollo Orientado a Objetos con UML Xavier Ferré Grau, María Isabel Sánchez Segura
2 I.1 Introducción
El objetivo principal cuando se empezó a gestar UML era posibilitar el intercambio de modelos
entre las distintas herramientas CASE orientadas a objetos del mercado. Para ello era necesario
definir una notación y semántica común. En la Figura 2 se puede ver cuál ha sido la evolución
de UML hasta la creación de UML 1.1.
Hay que tener en cuenta que el estándar UML no define un proceso de desarrollo específico, tan
solo se trata de una notación. En este curso se sigue el método propuesto por Craig Larman
[Larman99] que se ajusta a un ciclo de vida iterativo e incremental dirigido por casos de uso.
En la parte II de este texto se expone la notación y semántica básica de UML, en la parte III se
presentan conceptos avanzados de la notación UML, mientras que en la parte IV se presenta el
método de desarrollo orientado a objetos de Larman, que se sirve de los modelos de UML que
se han visto anteriormente.
II.1 Modelos 3
II Notación básica UML
En esta parte se verá cómo se representan gráficamente en UML los conceptos principales de la
orientación a objetos.
II.1 Modelos
Un modelo representa a un sistema software desde una perspectiva específica. Al igual que la
planta y el alzado de una figura en dibujo técnico nos muestran la misma figura vista desde
distintos ángulos, cada modelo nos permite fijarnos en un aspecto distinto del sistema.
Los modelos de UML que se tratan en esta parte son los siguientes:
• Diagrama de Estructura Estática.
• Diagrama de Casos de Uso.
• Diagrama de Secuencia.
• Diagrama de Colaboración.
• Diagrama de Estados.
II.2 Elementos Comunes a Todos los Diagramas

II.2.1 Notas
Una nota sirve para añadir cualquier tipo de comentario a un diagrama o a un elemento de un
diagrama. Es un modo de indicar información en un formato libre, cuando la notación del
diagrama en cuestión no nos permite expresar dicha información de manera adecuada.
Una nota se representa como un rectángulo con una esquina doblada con texto en su interior.
Puede aparecer en un diagrama tanto sola como unida a un elemento por medio de una línea
discontinua. Puede contener restricciones, comentarios, el cuerpo de un procedimiento, etc.
Usuario puede ser cualquiera de

los actores definidos en el sistema
Usuario
Figura 3 Ejemplo de nota
II.2.2 Dependencias
La relación de dependencia entre dos elementos de un diagrama significa que un cambio en el
elemento destino puede implicar un cambio en el elemento origen (por tanto, si cambia el
elemento destino habría que revisar el elemento origen).
Una dependencia se representa por medio de una línea de trazo discontinuo entre los dos
elementos con una flecha en su extremo. El elemento dependiente es el origen de la flecha y el
elemento del que depende es el destino (junto a él está la flecha).
4 II.3 Diagramas de Estructura Estática
Pueden existir
dependencias entre dos
elementos cualesquiera
Clase dependiente Clase de la que depende
Figura 4 Dependencias
II.3 Diagramas de Estructura Estática

Con el nombre de Diagramas de Estructura Estática se engloba tanto al Modelo Conceptual de
la fase de Análisis como al Diagrama de Clases de la fase de Diseño. Ambos son distintos
conceptualmente, mientras el primero modela elementos del dominio el segundo presenta los
elementos de la solución software. Sin embargo, ambos comparten la misma notación para los
elementos que los forman (clases y objetos) y las relaciones que existen entre los mismos
(asociaciones).
II.3.1 Clases
Una clase se representa mediante una caja subdividida en tres partes: En la superior se muestra
el nombre de la clase, en la media los atributos y en la inferior las operaciones. Una clase puede
representarse de forma esquemática (plegada), con los detalles como atributos y operaciones
suprimidos, siendo entonces tan solo un rectángulo con el nombre de la clase. En la Figura 5 se
ve cómo una misma clase puede representarse a distinto nivel de detalle según interese, y según
la fase en la que se esté.
Clase con detalles de implementación

Clase con Termostato
detalles a
nivel de Termostato
análisis temperatura_deseada
temperatura_muestreada +temperatura_deseada: Temperatura = 20
#temperatura_muestreada: Temperatura
establecer_temp ()
+establecer_temp (valor: Temperatura)

Clase con
detalles Termostato
suprimidos
Figura 5 Notación para clases a distintos niveles de detalle
II.3 Diagramas de Estructura Estática 5
II.3.2 Objetos
Un objeto se representa de la misma forma que una clase. En el compartimento superior
aparecen el nombre del objeto junto con el nombre de la clase subrayados, según la siguiente
sintaxis:
nombre_del_objeto: nombre_de_la_clase
Puede representarse un objeto sin un nombre específico, entonces sólo aparece el nombre de la
clase.
Objeto Eje_de_coordenadas de la clase Punto

Objeto de la clase Termostato sin
nombre específico Eje_de_coordenadas: Punto
:Termostato coordenada_x = 0
coordenada_y = 0
temperatura_deseada = 20°
Objeto p1de la clase Punto
temperatura_muestreada = 18°
p1: Punto
establecer_temp ()
coordenada_x = 8,53
coordenada_y = 41,29
Figura 6 Ejemplos de objetos
II.3.3 Asociaciones
Las asociaciones entre dos clases se representan mediante una línea que las une. La línea puede
tener una serie de elementos gráficos que expresan características particulares de la asociación.
A continuación se verán los más importantes de entre dichos elementos gráficos.
II.3.3.1 Nombre de la Asociación y Dirección

El nombre de la asociación es opcional y se muestra como un texto que está próximo a la línea.
Se puede añadir un pequeño triángulo negro sólido que indique la dirección en la cual leer el
nombre de la asociación. En el ejemplo de la Figura 7 se puede leer la asociación como
“Director manda sobre Empleado”.
manda sobre
Director Empleado
Figura 7 Ejemplo de asociación con nombre y dirección
Los nombres de las asociaciones normalmente se incluyen en los modelos para aumentar la
legibilidad. Sin embargo, en ocasiones pueden hacer demasiado abundante la información que
se presenta, con el consiguiente riesgo de saturación. En ese caso se puede suprimir el nombre
de las asociaciones consideradas como suficientemente conocidas.
En las asociaciones de tipo agregación y de herencia no se suele poner el nombre.
II.3.3.2 Multiplicidad
Corresponde_a
Cuenta Operación
Bancaria 1 *
Vive_con
Nieto Abuelo
* 0..4
Figura 8 Ejemplos de multiplicidad en asociaciones
La multiplicidad es una restricción que se pone a una asociación, que limita el número de
instancias de una clase que pueden tener esa asociación con una instancia de la otra clase. Puede
expresarse de las siguientes formas:
• Con un número fijo: 1.
• Con un intervalo de valores: 2..5.
• Con un rango en el cual uno de los extremos es un asterisco. Significa que es un intervalo
abierto. Por ejemplo, 2..* significa 2 o más.
• Con una combinación de elementos como los anteriores separados por comas: 1, 3..5, 7,
15..*.
• Con un asterisco: * . En este caso indica que puede tomar cualquier valor (cero o más).
II.3.3.3 Roles
Para indicar el papel que juega una clase en una asociación se puede especificar un nombre de
rol. Se representa en el extremo de la asociación junto a la clase que desempeña dicho rol.
Emplea
Empresa * 1..* Trabajador
Contratante Empleado
2
Padre Es_padre_de
Persona
Hijo
*
Figura 9 Ejemplo de roles en una asociación
II.3 Diagramas de Estructura Estática 7
II.3.3.4 Agregación
El símbolo de agregación es un diamante colocado en el extremo en el que está la clase que
representa el “todo”.
CPU
Ordenador Pantalla
Teclado
Figura 10 Ejemplo de agregación
II.3.3.5 Clases Asociación

Cuando una asociación tiene propiedades propias se representa como una clase unida a la línea
de la asociación por medio de una línea a trazos. Tanto la línea como el rectángulo de clase
representan el mismo elemento conceptual: la asociación. Por tanto ambos tienen el mismo
nombre, el de la asociación. Cuando la clase asociación sólo tiene atributos el nombre suele
ponerse sobre la línea (como ocurre en el ejemplo de la Figura 11). Por el contrario, cuando la
clase asociación tiene alguna operación o asociación propia, entonces se pone el nombre en la
clase asociación y se puede quitar de la línea.
Emplea
Empresa * 1..* Trabajador
Contratante Empleado
salario
Figura 11 Ejemplo de clase asociación
II.3.3.6 Asociaciones N-Arias

En el caso de una asociación en la que participan más de dos clases, las clases se unen con una
línea a un diamante central. Si se muestra multiplicidad en un rol, representa el número
potencial de tuplas de instancias en la asociación cuando el resto de los N-1 valores están fijos.
En la Figura 12 se ha impuesto la restricción de que un jugador no puede jugar en dos equipos
distintos a lo largo de una temporada, porque la multiplicidad de “Equipo” es 1 en la asociación
ternaria.
Año
Temporada *
Juega
Equipo 1 * Jugador
Equipo Delantero
goles en juego
goles a balón parado
goles de penalty
Figura 12 Ejemplo de asociación ternaria
II.3.3.7 Navegabilidad
En un extremo de una asociación se puede indicar la navegabilidad mediante una flecha.
Significa que es posible "navegar" desde el objeto de la clase origen hasta el objeto de la clase
destino. Se trata de un concepto de diseño, que indica que un objeto de la clase origen conoce al
(los) objeto(s) de la clase destino, y por tanto puede llamar a alguna de sus operaciones.
II.3.4 Herencia
La relación de herencia se representa mediante un triángulo en el extremo de la relación que
corresponde a la clase más general o clase “padre”.
Departamento
Márketing Contabilidad Informática ...
Figura 13 Ejemplo de herencia
Si se tiene una relación de herencia con varias clases subordinadas, pero en un diagrama
concreto no se quieren poner todas, esto se representa mediante puntos suspensivos. En el
ejemplo de la Figura 13, sólo aparecen en el diagrama 3 tipos de departamentos, pero con los
puntos suspensivos se indica que en el modelo completo (el formado por todos los diagramas) la
II.4 Diagrama de Casos de Uso 9
clase “Departamento” tiene subclases adicionales, como podrían ser “Recursos Humanos” y
“Producción”.
II.3.5 Elementos Derivados
Persona
{edad = fecha_actual – fecha_de_nacimiento} nombre

fecha_de_nacimiento
/edad
Figura 14 Ejemplo de atributo derivado
Un elemento derivado es aquel cuyo valor se puede calcular a partir de otros elementos
presentes en el modelo, pero que se incluye en el modelo por motivos de claridad o como
decisión de diseño. Se representa con una barra “/” precediendo al nombre del elemento
derivado.
II.4 Diagrama de Casos de Uso

Un Diagrama de Casos de Uso muestra la relación entre los actores y los casos de uso del
sistema. Representa la funcionalidad que ofrece el sistema en lo que se refiere a su interacción
externa.
II.4.1 Elementos
Los elementos que pueden aparecer en un Diagrama de Casos de Uso son: actores, casos de uso
y relaciones entre casos de uso.
II.4.1.1 Actores
Un actor es una entidad externa al sistema que realiza algún tipo de interacción con el mismo.
Se representa mediante una figura humana dibujada con palotes. Esta representación sirve tanto
para actores que son personas como para otro tipo de actores (otros sistemas, sensores, etc.).
II.4.1.2 Casos de Uso

Un caso de uso es una descripción de la secuencia de interacciones que se producen entre un
actor y el sistema, cuando el actor usa el sistema para llevar a cabo una tarea específica. Expresa
una unidad coherente de funcionalidad, y se representa en el Diagrama de Casos de Uso
mediante una elipse con el nombre del caso de uso en su interior. El nombre del caso de uso
debe reflejar la tarea específica que el actor desea llevar a cabo usando el sistema.
II.4.1.3 Relaciones entre Casos de Uso

Entre dos casos de uso puede haber las siguientes relaciones:
• Extiende: Cuando un caso de uso especializa a otro extendiendo su funcionalidad.
• Usa: Cuando un caso de uso utiliza a otro.
Se representan como una línea que une a los dos casos de uso relacionados, con una flecha en
forma de triángulo y con una etiqueta <<extiende>> o <<usa>> según sea el tipo de relación.
10 II.5 Diagramas de Interacción
En el diagrama de casos de uso se representa también el sistema como una caja rectangular con
el nombre en su interior. Los casos de uso están en el interior de la caja del sistema, y los
actores fuera, y cada actor está unido a los casos de uso en los que participa mediante una línea.
En la Figura 15 se muestra un ejemplo de Diagrama de Casos de Uso para un cajero automático.
Cajero Automático
Realizar
Reintegro
Cambiar PIN <<extiende>>
Realizar
Cliente Reintegro
con VISA
Obtener Últimos
Movimientos y Saldo
Agregar
Billetes
Empleado de
Sucursal
Figura 15 Diagrama de Casos de Uso
II.5 Diagramas de Interacción

En los diagramas de interacción se muestra un patrón de interacción entre objetos. Hay dos
tipos de diagrama de interacción, ambos basados en la misma información, pero cada uno
enfatizando un aspecto particular: Diagramas de Secuencia y Diagramas de Colaboración.
II.5.1 Diagrama de Secuencia

Un diagrama de Secuencia muestra una interacción ordenada según la secuencia temporal de
eventos. En particular, muestra los objetos participantes en la interacción y los mensajes que
intercambian ordenados según su secuencia en el tiempo.
El eje vertical representa el tiempo, y en el eje horizontal se colocan los objetos y actores
participantes en la interacción, sin un orden prefijado. Cada objeto o actor tiene una línea
vertical, y los mensajes se representan mediante flechas entre los distintos objetos. El tiempo
fluye de arriba abajo.
Se pueden colocar etiquetas (como restricciones de tiempo, descripciones de acciones, etc.)
bien en el margen izquierdo o bien junto a las transiciones o activaciones a las que se refieren.
II.5 Diagramas de Interacción 11
:ClaseA :ClaseB
mensaje1( )
mensaje2( )
mensaje3( )
Figura 16 Diagrama de Secuencia
II.5.2 Diagrama de Colaboración

Un Diagrama de Colaboración muestra una interacción organizada basándose en los objetos que
toman parte en la interacción y los enlaces entre los mismos (en cuanto a la interacción se
refiere). A diferencia de los Diagramas de Secuencia, los Diagramas de Colaboración muestran
las relaciones entre los roles de los objetos. La secuencia de los mensajes y los flujos de
ejecución concurrentes deben determinarse explícitamente mediante números de secuencia.
tratar_mensaje(mensaje)
:Receptor_Mensajes 1a [mensaje.tipo = 1] : crear(mensaje) c:Comando-1
c:Comando-2
1b [mensaje.tipo = 2] : crear(mensaje)
1.1: lanzar()
c:Comando
Figura 17 Diagrama de Colaboración
En cuanto a la representación, un Diagrama de Colaboración muestra a una serie de objetos con

los enlaces entre los mismos, y con los mensajes que se intercambian dichos objetos. Los
12 II.6 Diagrama de Estados
mensajes son flechas que van junto al enlace por el que “circulan”, y con el nombre del mensaje
y los parámetros (si los tiene) entre paréntesis.
Cada mensaje lleva un número de secuencia que denota cuál es el mensaje que le precede,
excepto el mensaje que inicia el diagrama, que no lleva número de secuencia. Se pueden indicar
alternativas con condiciones entre corchetes (por ejemplo 3 [condición_de_test] :
nombre_de_método() ), tal y como aparece en el ejemplo de la Figura 17. También se puede
mostrar el anidamiento de mensajes con números de secuencia como 2.1, que significa que el
mensaje con número de secuencia 2 no acaba de ejecutarse hasta que no se han ejecutado todos
los 2. x .
II.6 Diagrama de Estados

Un Diagrama de Estados muestra la secuencia de estados por los que pasa un caso de uso o un
objeto a lo largo de su vida, indicando qué eventos hacen que se pase de un estado a otro y
cuáles son las respuestas y acciones que genera.
En cuanto a la representación, un diagrama de estados es un grafo cuyos nodos son estados y
cuyos arcos dirigidos son transiciones etiquetadas con los nombres de los eventos.
Un estado se representa como una caja redondeada con el nombre del estado en su interior. Una
transición se representa como una flecha desde el estado origen al estado destino.
La caja de un estado puede tener 1 o 2 compartimentos. En el primer compartimento aparece el
nombre del estado. El segundo compartimento es opcional, y en él pueden aparecer acciones de
entrada, de salida y acciones internas.
Una acción de entrada aparece en la forma entrada/acción_asociada donde acción_asociada es
el nombre de la acción que se realiza al entrar en ese estado. Cada vez que se entra al estado por
medio de una transición la acción de entrada se ejecuta.
Una acción de salida aparece en la forma salida/acción_asociada. Cada vez que se sale del
estado por una transición de salida la acción de salida se ejecuta.
Una acción interna es una acción que se ejecuta cuando se recibe un determinado evento en ese
estado, pero que no causa una transición a otro estado. Se indica en la forma
nombre_de_evento/acción_asociada.
[número.es_válido()]
Descolgado Sin Marcar Marcado Parcial

dígito(n)
entrada / sonar_tono_de_llamada entrada/número.añadir_digito(n)
dígito(n)
Figura 18 Diagrama de Estados
Un diagrama de estados puede representar ciclos continuos o bien una vida finita, en la que hay
un estado inicial de creación y un estado final de destrucción (del caso de uso o del objeto). El
estado inicial se muestra como un círculo sólido y el estado final como un círculo sólido
rodeado de otro círculo. En realidad, los estados inicial y final son pseudoestados, pues un
II.6 Diagrama de Estados 13
objeto no puede “estar” en esos estados, pero nos sirven para saber cuáles son las transiciones
inicial y final(es).
14 III.1 Modelado Dinámico
III Notación Avanzada UML
III.1 Modelado Dinámico

III.1.1 Diagramas De Actividades
Vamos a recordar los diferentes modelos que sirven para representar el aspecto dinámico de un
sistema:
• Diagramas de secuencia
• Diagramas de colaboración
• Diagramas de estados
• Diagramas de casos de uso
• Diagramas de actividades
En este capítulo nos centraremos en los diagramas de actividades que sirven fundamentalmente
para modelar el flujo de control entre actividades.
La idea es generar una especie de diagrama Pert, en el que se puede ver el flujo de actividades
que tienen lugar a lo largo del tiempo, así como las tareas concurrentes que pueden realizarse a
la vez. El diagrama de actividades sirve para representar el sistema desde otra perspectiva, y de
este modo complementa a los anteriores diagramas vistos.
Gráficamente un diagrama de actividades será un conjunto de arcos y nodos.
Desde un punto de vista conceptual, el diagrama de actividades muestra cómo fluye el control
de unas clases a otras con la finalidad de culminar con un flujo de control total que se
corresponde con la consecución de un proceso más complejo.
Por este motivo, en un diagrama de actividades aparecerán acciones y actividades
correspondientes a distintas clases. Colaborando todas ellas para conseguir un mismo fin.
Ejemplo: Hacer un pedido.
III.1.2 Contenido del diagrama de actividades

Básicamente un diagrama de actividades contiene:
• Estados de actividad
• Estados de acción
• Transiciones
• Objetos
III.1.2.1 Estados de actividad y estados de acción

La representación de ambos es un rectángulo con las puntas redondeadas, en cuyo interior se
representa bien una actividad o bien una acción. La forma de expresar tanto una actividad como
una acción, no queda impuesta por UML, se podría utilizar lenguaje natural, una especificación
formal de expresiones, un metalenguaje, etc.
La idea central es la siguiente:
III.1 Modelado Dinámico 15
“Un estado que represente una acción es

atómico, lo que significa que su ejecución se
puede considerar instantánea y no puede ser
interrumpida”
En la Figura 19, podemos ver ejemplos de estados de acción.
Preparar Pedido Esto es un estado de acción con

una acción simple
Contador := Primero(lista)*7 Esto es un estado de acción

con una expresión
Figura 19 Estados de Acción
En cambio un estado de actividad, sí puede descomponerse en más sub-actividades

representadas a través de otros diagramas de actividades. Además estos estados sí pueden ser
interrumpidos y tardan un cierto tiempo en completarse. En los estados de actividad podemos
encontrar otros elementos adicionales como son: acciones de entrada (entry) y de salida (exit)
del estado en cuestión, así como definición de submáquinas, como podemos ver en la Figura 20.
ProcesarFactura(Fact)
entry/SacarPrimeraFactura(Fact)
Figura 20 Estado de Actividad
III.1.2.2 Transiciones
Las transiciones reflejan el paso de un estado a otro, bien sea de actividad o de acción. Esta
transición se produce como resultado de la finalización del estado del que parte el arco dirigido
que marca la transición. Como todo flujo de control debe empezar y terminar en algún
momento, podemos indicar esto utilizando dos disparadores de inicio y fin tal y como queda
reflejado en el ejemplo de la Figura 21.
Estado inicial
Activar Cajero
Transición sin disparador
Desactivar Cajero
Estado de Parada
Figura 21 Transiciones sin disparadores
16 III.1 Modelado Dinámico
III.1.2.3 Bifurcaciones
Un flujo de control no tiene porqué ser siempre secuencial, puede presentar caminos
alternativos. Para poder representar dichos caminos alternativos o bifurcación se utilizará como
símbolo el rombo. Dicha bifurcación tendrá una transición de entrada y dos o más de salida. En
cada transición de salida se colocará una expresión booleana que será evaluada una vez al llegar
a la bifurcación, las guardas de la bifurcación han de ser excluyentes y contemplar todos los
casos ya que de otro modo la ejecución del flujo de control quedaría interrumpida.
Para poder cubrir todas las posibilidades se puede utilizar la palabra ELSE, para indicar una
transición obligada a un determinado estado cuando el resto de guardas han fallado.
En la Figura 22 podemos ver un ejemplo de bifurcación.
Contabilizar
Materiales
[Materiales no disponibles]
Hacer Pedido de Materiales

[Materiales disponibles]
Asignar Nuevas Tareas
Figura 22 Bifurcación
III.1.2.4 División y unión

No sólo existe el flujo secuencial y la bifurcación, también hay algunos casos en los que se
requieren tareas concurrentes. UML representa gráficamente el proceso de división, que
representa la concurrencia, y el momento de la unión de nuevo al flujo de control secuencial,
por una línea horizontal ancha. En la Figura 23 podemos ver cómo se representa gráficamente.
División
Unión
Figura 23 División y unión
III.1.2.5 Calles
Cuando se modelan flujos de trabajo de organizaciones, es especialmente útil dividir los estados
de actividades en grupos, cada grupo tiene un nombre concreto y se denominan calles. Cada
III.2 Modelado Físico De Un Sistema OO 17
calle representa a la parte de la organización responsable de las actividades que aparecen en esa
calle. Gráficamente quedaría como se muestra en la Figura 24.
Figura 24 Calles
III.2 Modelado Físico De Un Sistema OO

III.2.1 Componentes
Los componentes pertenecen al mundo físico, es decir, representan un bloque de construcción al
modelar aspectos físicos de un sistema.
Una característica básica de un componente es que:
“debe definir una abstracción precisa con una
interfaz bien definida, y permitiendo
reemplazar fácilmente los componentes más
viejos con otros más nuevos y compatibles.”
En UML todos los elementos físicos se modelan como componentes. UML proporciona una
representación gráfica para estos como se puede ver en la Figura 25, en la que XXXX.dll, es el
nombre del componente.
XXXX.dll
Figura 25 Representación de un componente
Cada componente debe tener un nombre que lo distinga de los demás. Al igual que las clases los
componentes pueden enriquecerse con compartimentos adicionales que muestran sus detalles,
como se puede ver en la Figura 26.
18 III.2 Modelado Físico De Un Sistema OO
Expresion.dll
CalculaExpresionLógica
CalculaExpresionAritm
Figura 26 Representación extendida de un componente
Vamos a ver con más detalle cuáles son los parecidos y las diferencias entre los componentes y
las clases.
PARECIDOS
Ambos tienen nombre
Ambos pueden realizar un conjunto de interfaces.
Pueden participar en relaciones de dependencia, generalización y
asociación.
Ambos pueden anidarse
Ambos pueden tener instancias
Ambos pueden participar en interacciones
DIFERENCIAS
Las Clases Los Componentes
Representan abstracciones lógicas Representan elementos físicos
Es decir los componentes pueden estar en nodos y las clases no
Pueden tener atributos y Sólo tienen operaciones y estas son

operacionesdirectamente accesibles. alcanzables a través de la interfaz del
componente.
III.2.1.1 Interfaces
Tanto los servicios propio de una clase como los de un componente, se especifican a través de
una Interfaz. Por ejemplo, todas las facilidades más conocidas de los sistemas operativos,
basados en componentes (COM+, CORBA, etc.), utilizan las interfaces como lazo de unión
entre unos componentes y otros.
La relación entre un componente y sus interfaces se puede representar de dos maneras
diferentes, de forma icónica como se indica en la Figura 27, y de forma expandida como se
muestra en la Figura 28.
ObservadorDeImagen
Componente.java Imagen.java
Figura 27 Componentes e interfaces, formato icónico
«Interfaz»
Componente.java ObservadorDeImagen Imagen.java
Cancelar: int {final static}

Error: int {final static}
ActualizarImagen() Booolean
Figura 28 Componentes e interfaces, formato extendido
III.2.1.2 Tipos de componentes

Existen básicamente tres tipos de componentes:
Ø Componentes de despliegue: componentes necesarios y suficientes para formar un
sistema ejecutable, como pueden ser las bibliotecas dinámicas (DLLs) y ejecutables
(EXEs).
Ø Componentes producto del trabajo: estos componentes son básicamente productos
que quedan al final del proceso de desarrollo. Consisten en cosas como archivos de
código fuente y de datos a partir de los cuales se crean los componentes de despliegue.
Ø Componentes de ejecución: son componentes que se crean como consecuencia de un
sistema en ejecución. Es el caso de un objeto COM+ que se instancia a partir de una
DLL.
III.2.1.3 Organización de componentes

Los componentes se pueden agrupar en paquetes de la misma forma que se organizan las clases.
Además se pueden especificar entre ellos relaciones de dependencia, generalización, asociación
(incluyendo agregación), y realización.
III.2.1.4 Estereotipos de componentes

UML define cinco estereotipos estándar que se aplican a los componentes:
executable Componente que se puede ejecutar en un nodo.
library Biblioteca de objetos estática o dinámica.
table Componentes que representa una tabla de una base de datos.
file Componente que representa un documento que contiene código fuente o datos.
document Componente que representa un documento.
UML no especifica iconos predefinidos para estos estereotipos.
III.2.2 Despliegue
III.2.2.1 Nodos
Al igual que los componentes los nodos pertenecen al mundo material. Vamos a definir un nodo
como un elemento físico, que existe en tiempo de ejecución y representa un recurso
computacional que generalmente tiene alguna memoria y, a menudo, capacidad de
procesamiento.
Los nodos sirven para modelar la topología del hardware sobre el que se ejecuta el sistema. Un
nodo representa normalmente un procesador o un dispositivo sobre el que se pueden desplegar
los componentes.
Un nodo debe tener un nombre asignado que lo distinga del resto de nodos. Además los nodos
se representan gráficamente como se indica en la Figura 29.
Nombre
del nodo
Figura 29 Nodos
III.2.2.2 Nodos y componentes

En muchos aspectos los nodos y los componentes tienen características parecidas. Vamos a ver
con más detalle cuales son los parecidos y las diferencias entre los componentes y los nodos.
PARECIDOS
Ambos tienen nombre
Pueden participar en relaciones de dependencia, generalización y
asociación.
Ambos pueden anidarse
Ambos pueden tener instancias
Ambos pueden participar en interacciones
DIFERENCIAS
Los Nodos Los Componentes
Son los elementos donde se ejecutan Son los elementos que participan en
los componentes. la ejecución de un sistema.
Representan el despliegue físico de Representan el empaquetamiento
los componentes. físico de los elementos lógicos.
La relación entre un nodo y los componentes que despliega se pueden representar mediante una
relación de dependencia como se indica en la Figura 30.
Los nodos se pueden agrupar en paquetes igual que los las clases y los componentes.
Los tipos de relación más común entre nodos es la asociación. Una asociación entre nodos viene
a representar una conexión física entre nodos como se puede ver en la Figura 31.
Ventas
Proveedores.exe Facturas.exe
Figura 30 Relación entre nodos y componentes
Servidor
HUB
Terminal
Figura 31 Conexiones entre nodos
Existen dos tipos de diagramas que sirven para modelar los aspectos físicos de un sistema
orientado a objetos:
Ø Diagramas de Componentes
Ø Diagramas de Despliegue
Seguidamente veremos para qué sirve cada uno de ellos y cual es su representación gráfica.
III.2.3 Diagramas de Componentes

Un diagrama de componentes muestra la organización y las dependencias entre un conjunto de
componentes.
Para todo sistema OO se han de construir una serie de diagramas que modelan tanto la parte
estática (diagrama de clases), como dinámica (diagramas de secuencia, colaboración, estados y
de actividades), pero llegado el momento todo esto se debe materializar en un sistema
implementado que utilizará partes ya implementadas de otros sistemas, todo esto es lo que
pretendemos modelar con los diagramas de componentes.
III.2.3.1 Algunos conceptos

Un diagrama de componentes muestra un conjunto de componentes y sus relaciones de manera
gráfica a través del uso de nodos y arcos entre estos.
Normalmente los diagramas de componentes contienen:
Ø Componentes
Ø Interfaces
Ø Relaciones de dependencia, generalización, asociaciones y realización.
Ø Paquetes o subsistemas
Ø Instancias de algunas clases
Visto de otro modo un diagrama de componentes puede ser un tipo especial de diagrama de
clases que se centra en los componentes físicos del sistema.
III.2.3.2 Usos más comunes
a) Modelado de Código Fuente

Los diagramas de componentes se pueden utilizar para modelar la gestión de la configuración de
los archivos de código fuente, tomando como productos de trabajo precisamente estos ficheros.
Esto resulta bastante útil por ejemplo cuando se han implementado unas partes con Java otras
con C, etc. El resultado de esta implementación pueden ser multitud de ficheros ejecutables con
características particulares, de manera que la mejor forma de controlarlos es estableciendo
gestión de configuración.
Para poder llevar a cabo esta gestión con éxito será necesario definir los estereotipos de ficheros
que se quieren tener bajo control así como las relaciones entre dichos tipos de ficheros.
Para modelar el código fuente de un sistema:
Ø Hay que identificar el conjunto de archivos de código fuente de interés y modelarlos
como componentes estereotipados como archivos.
Ø Si el sistema es muy grande es necesario utilizar los paquetes para agrupar los archivos
de código fuente.
Ø Es necesario identificar la versión del componente.
b) Modelado de una versión ejecutable y bibliotecas.

La utilización de los componentes para modelar versiones ejecutables se centra en la definición
de todos los elementos que componen lo que se conoce como versión ejecutable, es decir la
documentación, los ficheros que se entregan etc.
Para modelar una versión ejecutable es preciso:
Ø Identificar el conjunto de componentes que se pretende modelar.
Ø Identificar el estereotipo de cada componente del conjunto seleccionado.
Ø Para cada componente de este conjunto hay que considerar las relaciones con los
vecinos. Esto implica definir las interfaces importadas por ciertos componentes y las
exportadas por otros.
c) Modelado de una base de datos física

Para modelar una base de datos física es necesario:
Ø Identificar las clases del modelo que representan el esquema lógico de la base de datos.
Ø Seleccionar una estrategia para hacer corresponder las clases con tablas. Así como la
distribución física de la/s base/s de datos.
Ø Para poder visualizar, especificar, construir y documentar dicha correspondencia es
necesario crear un diagrama de componentes que tenga componentes estereotipados
como tablas.
Ø Donde sea posible es aconsejable utilizar herramientas que ayuden a transformar diseño
lógico en físico.
III.2.4 Diagramas de Despliegue
III.2.4.1 Técnicas más comunes de modelado
a) Modelado de un sistema empotrado

El desarrollo de un sistema empotrado es más que el desarrollo de un sistema software. Hay que
manejar el mundo físico. Los diagramas de despliegue son útiles para facilitar la comunicación
entre los ingenieros de hardware y los de software.
Para modelar un sistema empotrado es necesario:
Ø Identificar los dispositivos y nodos propios del sistema.
Ø Proporcionar señales visuales, sobre todo para los dispositivos poco usuales.
Ø Modelar las relaciones entre esos procesadores y dispositivos en un diagrama de
despliegue.
Ø Si es necesario hay que detallar cualquier dispositivo inteligente, modelando su

estructura en un diagrama de despliegue más pormenorizado.
b) Modelado de un sistema cliente servidor

La división entre cliente y servidor en un sistema es complicada ya que implica tomar algunas
decisiones sobre dónde colocar físicamente sus componentes software, qué cantidad de software
debe residir en el cliente, etc.
Para modelar un sistema cliente/servidor hay que hace lo siguiente:
Ø Identificar los nodos que representan los procesadores cliente y servidor del sistema.
Ø Destacar los dispositivos relacionados con el comportamiento del sistema.
Ø Proporcionar señales visuales para esos procesadores y dispositivos a través de
estereotipos.
Ø Modelar la tipología de esos nodos mediante un diagrama de despliegue.
III.2.5 Arquitectura del Sistema
III.2.5.1 Arquitectura de tres niveles

La llamada “Arquitectura en Tres Niveles”, es la más común en sistemas de información que
además de tener una interfaz de usuario contemplan la persistencia de los datos.
Una descripción de los tres niveles sería la siguiente:
Nivel 1: Presentación – ventanas, informes, etc.
Nivel 2: Lógica de la Aplicación – tareas y reglas que gobiernan el proceso.
Nivel 3: Almacenamiento – mecanismo de almacenamiento.
III.2.5.2 Arquitectura de tres niveles orientadas a objetos
a) Descomposición del nivel de lógica de la aplicación

En el diseño orientado a objetos, el nivel de lógica de la aplicación se descompone en sub-
niveles que son los siguientes:
Objetos del Dominio: son clases que representan objetos del dominio. Por ejemplo en un
problema de ventas, una “Venta” sería un objeto del dominio.
Servicios: se hace referencia a funciones de interacción con la base de datos, informes,
comunicaciones, seguridad, etc.
III.2.5.3 Arquitectura MULTI-nivel

La arquitectura de tres niveles puede pasar a llamarse de Múltiples Niveles si tenemos en cuenta
el hecho de que todos los niveles de la arquitectura de tres niveles se pueden descomponer cada
uno de ellos cada vez más.
Por ejemplo el nivel de Servicios, se puede descomponer en servicios de alto y de bajo nivel,
identificando como de alto nivel los servicios de generación de informes y como de bajo nivel
los de manejo de ficheros de entrada y salida.
El motivo que lleva a descomponer la arquitectura del sistema en diferentes niveles es múltiple:
Ø Separación de la lógica de la aplicación en componentes separados que sean más
fácilmente reutilizables.
Ø Distribución de niveles en diferentes nodos físicos de computación.
Ø Reparto de recursos humanos en diferentes niveles de la arquitectura.
III.2.5.4 Paquetes
La forma que tiene UML de agrupar elementos en subsistemas es a través del uso de Paquetes,
pudiéndose anidar los paquetes formando jerarquías de paquetes. De hecho un sistema que no
tenga necesidad de ser descompuesto en subsistemas se puede considerar como con un único
paquete que lo abarca todo.
Gráficamente un paquete viene representado como se indica en la Figura 32.
Figura 32 Representación de un paquete en UML
En la Figura 33, vemos cómo se representa la arquitectura del sistema con la notación de
paquetes.
Presentación Presentación
Dominio
Lógica de la
Aplicación
Servicios
Almacenamiento
Figura 33 Arquitectura de un sistema utilizando paquetes
III.2.5.5 Identificación de Paquetes

Vamos a definir una serie de reglas que nos pueden ser de utilidad a la hora de agrupar los
diferentes elementos en paquetes.
Ø Conviene agrupar elementos que proporcionen un mismo servicio.
Ø Los elementos que se agrupen en un mismo paquete han de presentar un alto grado de
cohesión, es decir deben estar muy relacionados.
Ø Los elementos que estén en diferentes paquetes deben tener poca relación, es decir deben
colaborar lo menos posible.
IV.1 Proceso de Desarrollo 25
IV Desarrollo Orientado a Objetos
IV.1 Proceso de Desarrollo

Cuando se va a construir un sistema software es necesario conocer un lenguaje de
programación, pero con eso no basta. Si se quiere que el sistema sea robusto y mantenible es
necesario que el problema sea analizado y la solución sea cuidadosamente diseñada. Se debe
seguir un proceso robusto, que incluya las actividades principales. Si se sigue un proceso de
desarrollo que se ocupa de plantear cómo se realiza el análisis y el diseño, y cómo se relacionan
los productos de ambos, entonces la construcción de sistemas software va a poder ser
planificable y repetible, y la probabilidad de obtener un sistema de mejor calidad al final del
proceso aumenta considerablemente, especialmente cuando se trata de un equipo de desarrollo
formado por varias personas.
Para este curso se va a seguir el método de desarrollo orientado a objetos que propone Craig
Larman [Larman99]. Este proceso no fija una metodología estricta, sino que define una serie de
actividades que pueden realizarse en cada fase, las cuales deben adaptarse según las condiciones
del proyecto que se esté llevando a cabo. Se ha escogido seguir este proceso debido a que aplica
los últimos avances en Ingeniería del Software, y a que adopta un enfoque eminentemente
práctico, aportando soluciones a las principales dudas y/o problemas con los que se enfrenta el
desarrollador. Su mayor aportación consiste en atar los cabos sueltos que anteriores métodos
dejan.
La notación que se usa para los distintos modelos, tal y como se ha dicho anteriormente, es la
proporcionada por UML, que se ha convertido en el estándar de facto en cuanto a notación
orientada a objetos. El uso de UML permite integrar con mayor facilidad en el equipo de
desarrollo a nuevos miembros y compartir con otros equipos la documentación, pues es de
esperar que cualquier desarrollador versado en orientación a objetos conozca y use UML (o se
esté planteando su uso).
Se va a abarcar todo el ciclo de vida, empezando por los requisitos y acabando en el sistema
funcionando, proporcionando así una visión completa y coherente de la producción de sistemas
software. El enfoque que toma es el de un ciclo de vida iterativo incremental, el cual permite
una gran flexibilidad a la hora de adaptarlo a un proyecto y a un equipo de desarrollo
específicos. El ciclo de vida está dirigido por casos de uso, es decir, por la funcionalidad que
ofrece el sistema a los futuros usuarios del mismo. Así no se pierde de vista la motivación
principal que debería estar en cualquier proceso de construcción de software: el resolver una
necesidad del usuario/cliente.
IV.1.1 Visión General

El proceso a seguir para realizar desarrollo orientado a objetos es complejo, debido a la
complejidad que nos vamos a encontrar al intentar desarrollar cualquier sistema software de
tamaño medio-alto. El proceso está formado por una serie de actividades y subactividades, cuya
realización se va repitiendo en el tiempo aplicadas a distintos elementos.
En este apartado se va a presentar una visión general para poder tener una idea del proceso a
alto nivel, y más adelante se verán los pasos que componen cada fase.
Las tres fases al nivel más alto son las siguientes:
• Planificación y Especificación de Requisitos: Planificación, definición de requisitos,
construcción de prototipos, etc.
26 IV.1 Proceso de Desarrollo
• Construcción: La construcción del sistema. Las fases dentro de esta etapa son las
siguientes:
- Análisis: Se analiza el problema a resolver desde la perspectiva de los usuarios y de las
entidades externas que van a solicitar servicios al sistema.
- Diseño: El sistema se especifica en detalle, describiendo cómo va a funcionar
internamente para satisfacer lo especificado en el análisis.
- Implementación: Se lleva lo especificado en el diseño a un lenguaje de programación.
- Pruebas: Se llevan a cabo una serie de pruebas para corroborar que el software
funciona correctamente y que satisface lo especificado en la etapa de Planificación y
Especificación de Requisitos.
• Instalación: La puesta en marcha del sistema en el entorno previsto de uso.
De ellas, la fase de Construir es la que va a consumir la mayor parte del esfuerzo y del tiempo
en un proyecto de desarrollo. Para llevarla a cabo se va adoptar un enfoque iterativo, tomando
en cada iteración un subconjunto de los requisitos (agrupados según casos de uso) y llevándolo
a través del análisis y diseño hasta la implementación y pruebas, tal y como se muestra en la
Figura 34. El sistema va creciendo incrementalmente en cada ciclo.
Con esta aproximación se consigue disminuir el grado de complejidad que se trata en cada ciclo,
y se tiene pronto en el proceso una parte del sistema funcionando que se puede contrastar con el
usuario/cliente.
Planificación y Construcción Instalación

Especificación de
Requisitos
Ciclo de Ciclo de
Desarrollo 1 Desarrollo 2
...
Refinamiento Sincronización Análisis Diseño Implementación Pruebas

del de Modelos
Plan
Figura 34 Desarrollo Iterativo en la Construcción
IV.2 Fase de Planificación y Especificación de Requisitos 27
IV.2 Fase de Planificación y Especificación de Requisitos

Esta fase se corresponde con la Especificación de Requisitos tradicional ampliada con un
Borrador de Modelo Conceptual y con una definición de Casos de Uso de alto nivel. En esta
fase se decidiría si se aborda la construcción del sistema mediante desarrollo orientado a objetos
o no, por lo que, en principio, es independiente del paradigma empleado posteriormente.
IV.2.1 Actividades
Las actividades de esta fase son las siguientes:
1. Definir el Plan-Borrador.
2. Crear el Informe de Investigación Preliminar.
3. Definir los Requisitos.
4. Registrar Términos en el Glosario. (continuado en posteriores fases)
5. Implementar un Prototipo. (opcional)
6. Definir Casos de Uso (de alto nivel y esenciales).
7. Definir el Modelo Conceptual-Borrador. (puede retrasarse hasta una fase posterior)
8. Definir la Arquitectura del Sistema-Borrador. (puede retrasarse hasta una fase posterior)
9. Refinar el Plan.
El orden propuesto es el que parece más lógico, y en él los pasos 5 y 7 pueden estar en
posiciones distintas. De todos modos, el orden no es estricto, lo normal es que las distintas
actividades se solapen en el tiempo. Esto sucede también en las actividades de las fases de
Análisis y de Diseño, que se verán más adelante.
De estas actividades no se va a entrar en las que corresponden al campo de la planificación de
proyectos software, como las correspondientes a creación de planes e informes preliminares.
Tan solo se va a ver por encima la actividad de Definición de Requisitos en cuanto está
relacionada con los Casos de Uso, pues son éstos los que van a servir de punto de partida en el
Análisis Orientado a Objetos.
IV.2.2 Requisitos
Un requisito es una descripción de necesidades o aspiraciones respecto a un producto. El
objetivo principal de la actividad de definición de requisitos consiste en identificar qué es lo que
realmente se necesita, separar el grano de la paja. Esto se hace en un modo que sirva de
comunicación entre el cliente y el equipo de desarrollo.
Es aconsejable que un documento de Especificación de Requisitos tenga los siguientes puntos:
− Propósito.
− Ámbito del Sistema, Usuarios.
− Funciones del Sistema.
− Atributos del Sistema.
El formato del documento de Especificación de Requisitos no está definido en UML, pero se ha
incluido este punto para resaltar que la actividad de definición de requisitos es un paso clave en
la creación de cualquier producto software.
Para refinar los requisitos y mejorar la comprensión de los mismos la técnica de casos de uso
constituye una valiosa ayuda.
28 IV.2 Fase de Planificación y Especificación de Requisitos
IV.2.3 Casos de Uso

Un Caso de Uso es un documento narrativo que describe la secuencia de eventos de un actor (un
agente externo) que usa un sistema para completar un proceso [Jacobson92]. Es una historia o
una forma particular de usar un sistema. Los casos de uso no son exactamente requisitos ni
especificaciones funcionales, pero ilustran e implican requisitos en las historias que cuentan.
En la página 9 se definió la notación de UML para los Diagramas de Casos de Uso. Nótese que
UML no define un formato para describir un caso de uso. Tan sólo define la manera de
representar la relación entre actores y casos de uso en un diagrama (Diagrama de Casos de Uso).
El formato textual que se va a usar en este texto para definir los caso de uso se va a definir a
continuación, mientras que la representación de los escenarios correspondientes a un caso de
uso por medio de Diagramas de Secuencia se verá más adelatnte.
En un primer momento interesa abordar un caso de uso desde un nivel de abstracción alto, es lo
que se denomina Caso de Uso de Alto Nivel.
IV.2.3.1 Casos de Uso de Alto Nivel

El siguiente Caso de Uso de Alto Nivel describe el proceso de sacar dinero cuando se está
usando un cajero automático:
− Caso de Uso: Realizar Reintegro
− Actores: Cliente
− Tipo: primario
− Descripción: Un Cliente llega al cajero automático, introduce la tarjeta, se identifica y
solicita realizar una operación de reintegro por una cantidad específica. El cajero le da el
dinero solicitado tras comprobar que la operación puede realizarse. El Cliente coge el dinero
y la tarjeta y se va.
En un caso de uso descrito a alto nivel la descripción es muy general, normalmente se condensa
en dos o tres frases. Es útil para comprender el ámbito y el grado de complejidad del sistema.
IV.2.3.2 Casos de Uso Expandidos

Los casos de uso que se consideren los más importantes y que se considere que son los que más
influencian al resto, se describen a un nivel más detallado: en el formato expandido.
La principal diferencia con un caso de uso de alto nivel está en que incluye un apartado de
Curso Típico de Eventos, pero también incluye otros apartados como se ve en el siguiente
ejemplo:
− Caso de Uso: Realizar Reintegro
− Actores: Cliente (iniciador)
− Propósito: Realizar una operación de reintegro de una cuenta del banco.
− Visión General: Un Cliente llega al cajero automático, introduce la tarjeta, se identifica y
solicita realizar una operación de reintegro por una cantidad específica. El cajero le da el
dinero solicitado tras comprobar que la operación puede realizarse. El Cliente coge el dinero
y la tarjeta y se va.
− Tipo: primario y esencial
− Referencias: Funciones: R1.3, R1.7
− Curso Típico de Eventos:
Acción del Actor Respuesta del Sistema
1. Este caso de uso empieza cuando un Cliente

introduce una tarjeta en el cajero. 2. Pide la clave de identificación.
4. Presenta las opciones de operaciones

3. Introduce la clave. disponibles.
5. Selecciona la operación de Reintegro. 6. Pide la cantidad a retirar.
8. Procesa la petición y, eventualmente, da el

7. Introduce la cantidad requerida. dinero solicitado.
Devuelve la tarjeta y genera un recibo.
9. Recoge la tarjeta.
10. Recoge el recibo.
11. Recoge el dinero y se va.
Cursos Alternativos:
• Línea 4: La clave es incorrecta. Se indica el error y se cancela la operación.
• Línea 8: La cantidad solicitada supera el saldo. Se indica el error y se cancela la
operación.
El significado de cada apartado de este formato es como sigue:
− Caso de Uso: Nombre del Caso de Uso
− Actores: Lista de actores (agentes externos), indicando quién inicia el caso de uso. Los
actores son normalmente roles que un ser humano desempeña, pero puede ser cualquier tipo
de sistema.
− Propósito: Intención del caso de uso.
− Visión General: Repetición del caso de uso de alto nivel, o un resumen similar.
− Tipo: 1. primario, secundario u opcional (descritos más adelante).
2. esencial o real (descritos más adelante).
− Referencias: Casos de uso relacionados y funciones del sistema que aparecen en los
requisitos.
− Curso Típico de Eventos: Descripción de la interacción entre los actores y el sistema
mediante las acciones numeradas de cada uno. Describe la secuencia más común de
eventos, cuando todo va bien y el proceso se completa satisfactoriamente. En caso de haber
alternativas con grado similar de probabilidad se pueden añadir secciones adicionales a la
sección principal, como se verá más adelante.
− Cursos Alternativos: Puntos en los que puede surgir una alternativa, junto con la descripción
de la excepción.
IV.2.3.3 Identificación de Casos de Uso

La identificación de casos de uso requiere un conocimiento medio acerca de los requisitos, y se
basa en la revisión de los documentos de requisitos existentes, y en el uso de la técnica de
brainstorming entre los miembros del equipo de desarrollo.
Como guía para la identificación inicial de casos de uso hay dos métodos:
a) Basado en Actores
1. Identificar los actores relacionados con el sistema y/o la organización.
2. Para cada actor, identificar los procesos que inicia o en los que participa.
b) Basado en Eventos
1. Identificar los eventos externos a los que el sistema va a tener que responder.
2. Relacionar los eventos con actores y casos de uso.
Ejemplos de casos de uso:

• Pedir un producto.
• Matricularse en un curso de la facultad.
• Comprobar la ortografía de un documento en un procesador de textos.
• Realizar una llamada telefónica.
IV.2.3.4 Identificación de los Límites del Sistema

En la descripción de un caso de uso se hace referencia en todo momento al “sistema”. Para que
los casos de uso tengan un significado completo es necesario que el sistema esté definido con
precisión.
Al definir los límites del sistema se establece una diferenciación entre lo que es interno y lo que
es externo al sistema. El entorno exterior se representa mediante los actores.
Ejemplos de sistemas son:
• El hardware y software de un sistema informático.
• Un departamento de una organización.
• Una organización entera.
Si no se está haciendo reingeniería del proceso de negocio lo más normal es escoger como
sistema el primero de los ejemplos: el hardware y el software del sistema que se quiere
construir.
IV.2.3.5 Tipos de Casos de Uso
a) Según Importancia
Para poder priorizar los casos de uso que identifiquemos los vamos a distinguir entre:
• Primarios: Representan los procesos principales, los más comunes, como Realizar
Reintegro en el caso del cajero automático.
• Secundarios: Representan casos de uso menores, que van a necesitarse raramente, tales
como Añadir Nueva Operación.
• Opcionales: Representan procesos que pueden no ser abordados en el presente proyecto.
b) Según el Grado de Compromiso con el Diseño

En las descripciones que se han visto anteriormente no se han hecho apenas compromisos con la
solución, se han descrito los casos de uso a un nivel abstracto, independiente de la tecnología y
de la implementación. Un caso de uso definido a nivel abstracto se denomina esencial. Los
casos de uso definidos a alto nivel son siempre esenciales por naturaleza, debido a su brevedad
y abstracción.
Por el contrario, un caso de uso real describe concretamente el proceso en términos del diseño
real, de la solución específica que se va a llevar a cabo. Se ajusta a un tipo de interfaz específica,
y se baja a detalles como pantallas y objetos en las mismas.
Como ejemplo de una parte de un Caso de Uso Real para el caso del reintegro en un cajero
automático tenemos la siguiente descripción del Curso Típico de Eventos:
1. Este caso de uso empieza cuando un Cliente

2. Pide el PIN (Personal Identification
introduce una tarjeta en la ranura para
Number).
tarjetas.
3. Introduce el PIN a través del teclado 4. Presenta las opciones de operaciones
numérico. disponibles.
5. etc. 6. etc.
En principio, los casos de uso reales deberían ser creados en la fase de Diseño y no antes, puesto
que se trata de elementos de diseño. Sin embargo, en algunos proyectos se plantea la definición
de interfaces en fases tempranas del ciclo de desarrollo, en base a que son parte del contrato. En
este caso se pueden definir algunos o todos los casos de uso reales, a pesar de que suponen
tomar decisiones de diseño muy pronto en el ciclo de vida.
No hay una diferencia estricta entre un Caso de Uso Esencial y uno Real, el grado de
compromiso con el Diseño es un continuo, y una descripción específica de un caso de uso estará
situada en algún punto de la línea entre Casos de Uso Esenciales y Reales, normalmente más
cercano a un extremo que al otro, pero es raro encontrar Casos de Uso Esenciales o Reales
puros.
IV.2.3.6 Consejos Relativos a Casos de Uso
a) Nombre
El nombre de un Caso de Uso debería ser un verbo, para enfatizar que se trata de un proceso,
por ejemplo: Comprar Artículos o Realizar Pedido.
b) Alternativas equiprobables
Cuando se tiene una alternativa que ocurre de manera relativamente ocasional, se indica en el
apartado Cursos Alternativos. Pero cuando se tienen distintas opciones, todas ellas consideradas
normales se puede completar el Curso Típico de Eventos con secciones adicionales.
Así, si en un determinado número de línea hay una bifurcación se pueden poner opciones que
dirigen el caso de uso a una sección que se detalla al final del Curso Típico de Eventos, en la
siguiente forma:
− Curso Típico de Eventos:
− Sección: Principal
1. Este caso de uso empieza cuando Actor

2. Pide la operación a realizar.
llega al sistema.
3. Escoge la operación A. 4. Presenta las opciones de pago.
5. Selecciona el tipo de pago:

a. Si se paga al contado ver sección Pago
al Contado. 6. Genera recibo.
b. Si se paga con tarjeta ver sección Pago
con Tarjeta.
7. Recoge el recibo y se va.
• Líneas 3 y 5: Selecciona Cancelar. Se cancela la operación.
− Sección: Pago al Contado
2. Coge los billetes y sigue pidiendo dinero

1. Mete los billetes correspondientes
hasta que la cantidad está satisfecha
3. Devuelve el cambio.
• Línea 3: No hay cambio suficiente. Se cancela la operación.
− Sección: Pago con Tarjeta

...
IV.2.4 Construcción del Modelo de Casos de Uso

Para construir el Modelo de Casos de Uso en la fase de Planificación y Especificación de
Requisitos se siguen los siguientes pasos:
1. Después de listar las funciones del sistema, se definen los límites del sistema y se
identifican los actores y los casos de uso.
2. Se escriben todos los casos de uso en el formato de alto nivel. Se categorizan como
primarios, secundarios u opcionales.
3. Se dibuja el Diagrama de Casos de Uso.
4. Se relacionan los casos de uso y se ilustran las relaciones en el Diagrama de Casos de Uso
(<<extiende>> y <<usa>>).
5. Los casos de uso más críticos, importantes y que conllevan un mayor riesgo, se describen en
el formato expandido esencial. Se deja la definición en formato expandido esencial del resto
de casos de uso para cuando sean tratados en posteriores ciclos de desarrollo, para no tratar
toda la complejidad del problema de una sola vez.
6. Se crean casos de uso reales sólo cuando:
• Descripciones más detalladas ayudan significativamente a incrementar la comprensión
del problema.
• El cliente pide que los procesos se describan de esta forma.
7. Ordenar según prioridad los casos de uso (este paso se va a ver a continuación).
IV.2.5 Planificación de Casos de Uso según Ciclos de Desarrollo

La decisión de qué partes del sistema abordar en cada ciclo de desarrollo se va a tomar
basándose en los casos de uso. Esto es, a cada ciclo de desarrollo se le va a asignar la
implementación de uno o más casos de uso, o versiones simplificadas de casos de uso. Se asigna
una versión simplificada cuando el caso de uso completo es demasiado complejo para ser
tratado en un solo ciclo (ver Figura 35).
Ciclo de Ciclo de Ciclo de

Desarrollo Desarrollo Desarrollo
Caso de Uso A Caso de Uso A Caso de Uso B

Versión Versión
Simplificada Completa --------
-------- -------- --------
-------- -------- --------
-------- --------
Caso de Uso C
--------
--------
--------
Figura 35 Planificación de Ciclos de Desarrollo según Casos de Uso
Para tomar la decisión de qué casos de uso se van a tratar primero es necesario ordenarlos según
prioridad. Las características de un caso de uso específico que van a hacer que un caso de uso
tenga una prioridad alta son las siguientes:
a. Impacto significativo en el diseño de la arquitectura. Por ejemplo, si aporta muchas clases al
modelo del dominio o requiere persistencia en los datos.
b. Se obtiene una mejor comprensión del diseño con un nivel de esfuerzo relativamente bajo.
c. Incluye funciones complejas, críticas en el tiempo o de nivel elevado de riesgo.
34 IV.3 Fase de Construcción: Análisis
d. Implica bien un trabajo de investigación significante, o bien el uso de una tecnología nueva
o arriesgada.
e. Representa un proceso de gran importancia en la línea de negocio.
f. Supone directamente un aumento de beneficios o una disminución de costes.
Para realizar la clasificación se puede asignar a cada caso de uso una valoración numérica de
cada uno de estos puntos, para conseguir una puntuación total aplicando pesos a cada apartado.
En la siguiente tabla se muestra un ejemplo de tal tipo de clasificación:
Peso 3 2 4 1 3 4
Suma
Caso de Uso a b c d e f
Reintegro 5 4 1 0 5 2 50
...
IV.2.5.1 Caso de Uso Inicialización

Prácticamente todos los sistemas van a tener un caso de uso Inicialización. Aunque puede ser
que no tenga una prioridad alta en la clasificación realizada según el punto anterior,
normalmente va a interesar que sea desarrollado desde el principio. Inicialmente se desarrolla
una versión simplificada, que se va completando en cada ciclo de desarrollo para satisfacer las
necesidades de inicialización de los casos de uso que se tratan en dicho ciclo. Así se tiene un
sistema en cada ciclo de desarrollo que puede funcionar.
IV.3 Fase de Construcción: Análisis

En la fase de Análisis de un ciclo de desarrollo se investiga sobre el problema, sobre los
conceptos relacionados con el subconjunto de casos de uso que se esté tratando. Se intenta llegar
a una buena comprensión del problema por parte del equipo de desarrollo, sin entrar en cómo va
a ser la solución en cuanto a detalles de implementación.
Cuando el ciclo de desarrollo no es el primero, antes de la fase de Análisis hay una serie de
actividades de planificación. Estas actividades consisten en actualizar los modelos que se tengan
según lo que se haya implementado, pues siempre se producen desviaciones entre lo que se ha
analizado y diseñado y lo que finalmente se construye. Una vez se tienen los modelos acordes
con lo implementado se empieza el nuevo ciclo de desarrollo con la fase de Análisis.
En esta fase se trabaja con los modelos de Análisis construidos en la fase anterior, ampliándolos
con los conceptos correspondientes a los casos de uso que se traten en el ciclo de desarrollo
actual.
IV.3.1 Actividades
Las actividades de la fase de Análisis son las siguientes:
1. Definir Casos de Uso Esenciales en formato expandido. (si no están definidos )
2. Refinar los Diagramas de Casos de Uso.
3. Refinar el Modelo Conceptual.
4. Refinar el Glosario. (continuado en posteriores fases)
5. Definir los Diagramas de Secuencia del Sistema.
6. Definir Contratos de Operación.
IV.3 Fase de Construcción: Análisis 35
7. Definir Diagramas de Estados. (opcional)
IV.3.2 Modelo Conceptual

Una parte de la investigación sobre el dominio del problema consiste en identificar los
conceptos que lo conforman. Para representar estos conceptos se va a usar un Diagrama de
Estructura Estática de UML, al que se va a llamar Modelo Conceptual.
En el Modelo Conceptual se tiene una representación de conceptos del mundo real, no de
componentes software.
El objetivo de la creación de un Modelo Conceptual es aumentar la comprensión del problema.
Por tanto, a la hora de incluir conceptos en el modelo, es mejor crear un modelo con muchos
conceptos que quedarse corto y olvidar algún concepto importante.
IV.3.2.1 Identificación de Conceptos

Para identificar conceptos hay que basarse en el documento de Especificación de Requisitos y
en el conocimiento general acerca del dominio del problema.
En la Tabla 1 se muestran algunas categorías típicas, junto con ejemplos pertenecientes al
dominio de los supermercados y al de la reserva de billetes de avión:
Tabla 1 Lista de Conceptos Típicos
Tipo de Concepto Ejemplos

Avión
Objetos físicos o tangibles
Terminal_de_Caja
Especificaciones, diseños o Especificación_de_Producto
descripciones de cosas Descripción_de_Vuelo
Supermercado
Lugares
Aeropuerto
Venta, Pago
Transacciones
Reserva
Líneas de una transacción Artículo_de_Venta
Cajero
Roles de una persona
Piloto
Supermercado, Cesta
Contenedores de otras cosas
Avión
Artículo
Cosas en un contenedor
Pasajero
Otros ordenadores o sistemas Sistema_de_Autorización_de_Tarjetas_de Crédito
electromecánicos externos a Sistema_Controlador_de_Tráfico_Aéreo
nuestro sistema
Conceptos abstractos Hambre
Departamento_de_Ventas
Organizaciones
Compañía_Aérea_Toto
Venta, Robo, Reunión
Eventos
Vuelo, Accidente, Aterrizaje
Política_de_Devoluciones
Reglas y políticas
Política_de_Cancelaciones
Catálogo_de_Productos
Catálogos
Catálogo_de_Piezas
Archivos financieros, de trabajo, Recibo, Contrato_de_Empleo

de contratos, de asuntos legales Registro_de_Revisiones
Instrumentos y servicios Línea_de_Crédito
financieros Stock
Manual_del_Empleado
Manuales, libros
Manual_de_Reparaciones
Otro consejo para identificar conceptos consiste en buscar sustantivos en los documentos de
requisitos o, más concretamente, en la descripción de los casos de uso. No es un método
infalible, pero puede servir de guía para empezar.
Para poner nombre a los conceptos se puede usar la analogía con el cartógrafo, resumida en los
siguientes tres puntos:
• Usar los nombres existentes en el territorio: Hay que usar el vocabulario del dominio para
nombrar conceptos y atributos.
• Excluir características irrelevantes: Al igual que el cartógrafo elimina características no
relevantes según la finalidad del mapa (por ejemplo datos de población en un mapa de
carreteras), un Modelo Conceptual puede excluir conceptos en el dominio que no son
pertinentes en base a los requisitos.
• No añadir cosas que no están ahí: Si algo no pertenece al dominio del problema no se
añade al modelo.
IV.3.2.2 Creación del Modelo Conceptual

Para crear el Modelo Conceptual se siguen los siguientes pasos:
1. Hacer una lista de conceptos candidato usando la Lista de Categorías de Conceptos de la
Tabla 1 y la búsqueda de sustantivos relacionados con los requisitos en consideración en
este ciclo.
2. Representarlos en un diagrama.
3. Añadir las asociaciones necesarias para ilustrar las relaciones entre conceptos que es
necesario conocer.
4. Añadir los atributos necesarios para contener toda la información que se necesite conocer de
cada concepto.
IV.3.2.3 Identificación de Asociaciones

Una asociación es una relación entre conceptos que indica una conexión con sentido y que es de
interés en el conjunto de casos de uso que se está tratando.
Se incluyen en el modelo las asociaciones siguientes:
• Asociaciones para las que el conocimiento de la relación necesita mantenerse por un cierto
período de tiempo (asociaciones “necesita-conocer”).
• Asociaciones derivadas de la Lista de Asociaciones Típicas que se muestra en la Tabla 2.
Tabla 2 Lista de Asociaciones Típicas
Categoría Ejemplos
A es una parte física de B Ala – Avión
A es una parte lógica de B Artículo_en_Venta –Venta
A está físicamente contenido en B Artículo – Estantería
Pasajero – Avión
A está lógicamente contenido en B Descripción_de_Artículo – Catálogo
A es una descripción de B Descripción_de_Artículo – Artículo
A es un elemento en una transacción o Trabajo_de_Reparación – Registro_de_Reparaciones
un informe B
A es registrado/archivado/capturado en Venta – Terminal_de_Caja
B
A es un miembro de B Cajero – Supermercado
Piloto – Compañía_Aerea
A es una subunidad organizativa de B Sección – Supermercado
Mantenimiento – Compañía_Aerea
A usa o gestiona B Cajero – Terminal_de_Caja
Piloto – Avión
A comunica con B Cliente – Cajero
Empleado_de_Agencia_de_Viajes – Pasajero
A está relacionado con una transacción Cliente – Pago
B
Pasajero – Billete
A es una transacción relacionada con Pago – Venta
otra transacción B
Reserva – Cancelación
A está junto a B Ciudad – Ciudad
A posee B Supermercado – Terminal_de_Caja
Compañía_Aérea – Avión
Una vez identificadas las asociaciones se representan en el Modelo Conceptual con la
multiplicidad adecuada.
IV.3.2.4 Identificación de Atributos

Es necesario incorporar al Modelo Conceptual los atributos necesarios para satisfacer las
necesidades de información de los casos de uso que se estén desarrollando en ese momento.
Los atributos deben tomar valor en tipos simples (número, texto, etc.), pues los tipos complejos
deberían ser modelados como conceptos y ser relacionados mediante asociaciones.
Incluso cuando un valor es de un tipo simple es más conveniente representarlo como concepto
en las siguientes ocasiones:
• Se compone de distintas secciones. Por ejemplo: un número de teléfono, el nombre de una
persona, etc.
• Tiene operaciones asociadas, tales como validación. Ejemplo: NIF.
• Tiene otros atributos. Por ejemplo un precio de oferta puede tener fecha de fin.
• Es una cantidad con una unidad. Ejemplo: El precio, que puede estar en pesetas o en euros.
Una vez definidos los atributos se tiene ya un Modelo Conceptual. Este modelo no es un modelo
definitivo, pues a lo largo del Análisis y del Diseño se va refinando según se le añaden
conceptos que se habían pasado por alto.
IV.3.3 Glosario
En el glosario debe aparecer una descripción textual de cualquier elemento de cualquier modelo,
para eliminar toda posible ambigüedad.
Un formato tipo para el glosario es el que se muestra en la Tabla 3.
Tabla 3 Formato tipo de Glosario
Término Categoría Descripción

Realizar Reintegro caso de uso Descripción del proceso por el que un Cliente realiza
un reintegro en un cajero automático.
Banco concepto Entidad que ofrece servicios financieros a sus clientes.
... ... ...
IV.3.4 Diagramas de Secuencia del Sistema

Además de investigar sobre los conceptos del sistema y su estructura, también es preciso
investigar en el Análisis sobre el comportamiento del sistema, visto éste como una caja negra.
Una parte de la descripción del comportamiento del sistema se realiza mediante los Diagramas
de Secuencia del Sistema.
CASO DE USO: Realizar :cajero_automático

Reintegro
Cliente
Curso Típico de Eventos
1. Este caso de uso empieza cuando insertarTarjeta(número)
un Cliente introduce una tarjeta en
el cajero.
2. Pide la clave de identificación.
3. Introduce la clave. entrarIdentificación(clave)
4. Presenta las opciones de
operaciones disponibles.
5. Selecciona la operación de solicitarOperación(operación)
Reintegro.
6. Pide la cantidad a retirar.
7. Introduce la cantidad requerida. realizarReintegro(cantidad)
8. Procesa la petición y,
eventualmente, da el dinero
solicitado.
Devuelve la tarjeta y genera un
recibo.
9. Recoge la tarjeta. dineroRetirado()
10. Recoge el recibo. reciboRetirado()
11. Recoge el dinero y se va. tarjetaRetirada()
Figura 36 Ejemplo de Diagrama de Secuencia del Sistema
En cada caso de uso se muestra una interacción de actores con el sistema. En esta interacción los
actores generan eventos, solicitando al sistema operaciones. Por ejemplo, en el caso de una
reserva de un billete de avión, el empleado de la agencia de viajes solicita al sistema de reservas

que realice una reserva. El evento que supone esa solicitud inicia una operación en el sistema de
reservas.
Los casos de uso representan una interacción genérica. Una instancia de un caso de uso se
denomina escenario, y muestra una ejecución real del caso de uso, con las posibles
bifurcaciones y alternativas resueltas de forma particular.
Un Diagrama de Secuencia de Sistema se representa usando la notación para diagramas de
secuencia de UML (ver página 10). En él se muestra para un escenario particular de un caso de
uso los eventos que los actores generan, su orden, y los eventos que se intercambian entre
sistemas.
Para cada caso de uso que se esté tratando se realiza un diagrama para el curso típico de
eventos, y además se realiza un diagrama para los cursos alternativos de mayor interés.
En la Figura 36 se muestra el Diagrama de Secuencia del Sistema para el caso de uso Realizar
Reintegro de un cajero automático.
IV.3.4.1 Construcción de un Diagrama de Secuencia del Sistema

Para construir un Diagrama de Secuencia del Sistema para el curso típico de eventos de un caso
de uso, se siguen los siguientes pasos:
1. Representar el sistema como un objeto con una línea debajo.
2. Identificar los actores que directamente operan con el sistema, y dibujar una línea para cada
uno de ellos.
3. Partiendo del texto del curso típico de eventos del caso de uso, identificar los eventos
(externos) del sistema que cada actor genera y representarlos en el diagrama.
4. Opcionalmente, incluir el texto del caso de uso en el margen del diagrama.
Los eventos del sistema deberían expresarse en base a la noción de operación que representan,
en vez de en base a la interfaz particular. Por ejemplo, se prefiere “finOperación” a
“presionadaTeclaEnter”, porque captura la finalidad de la operación sin realizar compromisos
en cuanto a la interfaz usada.
IV.3.5 Contratos de Operaciones

Una vez se tienen las Operaciones del Sistema identificadas en los Diagramas de Secuencia, se
describe mediante contratos el comportamiento esperado del sistema en cada operación.
Un Contrato es un documento que describe qué es lo que se espera de una operación. Tiene una
redacción en estilo declarativo, enfatizando en el qué más que en el cómo. Lo más común es
expresar los contratos en forma de pre- y post-condiciones en torno a cambios de estado.
Se puede escribir un contrato para un método individual de una clase software, o para una
operación del sistema completa. En este punto se verá únicamente éste último caso.
Un Contrato de Operación del Sistema describe cambios en el estado del sistema cuando una
operación del sistema es invocada.
A continuación se ve un ejemplo de Contrato:
Contrato
Nombre: insertarTarjeta (número_tarjeta: número)
Responsabilidades: Comenzar una sesión con el sistema para realizar una operación. Presentar
las opciones disponibles.
Referencias Funciones del Sistema: R1.2, R1.6, R1.7

Cruzadas:
Casos de Uso: Reintegro
Notas:
Excepciones: Si la tarjeta es ilegible, indicar que ha habido un error.
Salida:
Pre-condiciones: No hay una sesión activa.
Post-condiciones: • Una nueva Sesión se ha creado. (creación de instancia).
• La Sesión se ha asociado con Cajero. (asociación formada).
La descripción de cada apartado de un contrato es como sigue:
Nombre: Nombre de la operación y parámetros.

Responsabilidades: Una descripción informal de las responsabilidades que la operación debe
desempeñar.
Referencias Números de referencia en los requisitos de funciones del sistema, casos de
Cruzadas: uso, etc.
Notas: Comentarios de diseño, algoritmos, etc.
Excepciones: Casos excepcionales. Situaciones que debemos tener en cuenta que
pueden pasar. Se indica también qué se hace cuando ocurre la excepción.
Salida: Salidas que no corresponden a la interfaz de usuario, como mensajes o
registros que se envían fuera del sistema. (En la mayor parte de las
operaciones del sistema este apartado queda vacio)
Pre-condiciones: Asunciones acerca del estado del sistema antes de ejecutar la operación.
Algo que no tenemos en cuenta que pueda ocurrir cuando se llama a esta
operación del sistema.
Post-condiciones: El estado del sistema después de completar la operación.
IV.3.5.1 Construcción de un Contrato

Los pasos a seguir para construir un contrato son los siguientes:
1. Identificar las operaciones del sistema a partir de los Diagramas de Secuencia del Sistema.
2. Para cada operación del sistema construir un contrato.
3. Empezar escribiendo el apartado de Responsabilidades, describiendo informalmente el
propósito de la operación. Este es el apartado más importante del contrato.
4. A continuación rellenar el apartado de Post-condiciones, describiendo declarativamente los
cambios de estado que sufren los objetos en el Modelo Conceptual. Puede ser que este
apartado quede vacío si no cambia el valor de ningún dato de los maneja el sistema (por
ejemplo en una operación del sistema que tan solo se encarga de sacar por pantalla algo al
usuario).
5. Para describir las post-condiciones, usar las siguientes categorías:
• Creación y borrado de instancias.
• Modificación de atributos.
IV.4 Fase de Construcción: Diseño 41
• Asociaciones formadas y retiradas.

6. Completar el resto de apartados en su caso.
IV.3.5.2 Post-condiciones
Las post-condiciones se basan en el Modelo Conceptual, en los cambios que sufren los
elementos del mismo una vez se ha realizado la operación.
Es mejor usar el tiempo pasado o el pretérito perfecto al redactar una post-condición, para
enfatizar que se trata de declaraciones sobre un cambio en el estado que ya ha pasado. Por
ejemplo es mejor decir “se ha creado una Sesión” que decir “crear una Sesión”.
Cuando se ha creado un objeto, lo normal es que se haya asociado a algún otro objeto ya
existente, porque si no queda aislado del resto del sistema. Por tanto, al escribir las post-
condiciones hay que acordarse de añadir asociaciones a los objetos creados. Olvidar incluir estas
asociaciones es el fallo más común cometido al escribir las post-condiciones de un contrato.
IV.3.6 Diagramas de Estados

Para modelar el comportamiento del sistema pueden usarse los Diagramas de Estados que
define UML (ver página 12).
Se puede aplicar un Diagrama de Estados al comportamiento de los siguientes elementos:
- Una clase software.
- Un concepto.
- Un caso de uso.
En la fase de Análisis sólo se haría para los dos últimos tipos de elemento, pues una clase
software pertenece al Diagrama de Clases de Diseño.
Puesto que el sistema entero puede ser representado por un concepto, también se puede modelar
el comportamiento del sistema completo mediante un Diagrama de Estados.
La utilidad de un Diagrama de Estados en el análisis reside en mostrar la secuencia permitida de
eventos externos que pueden ser reconocidos y tratados por el sistema. Por ejemplo, no se puede
insertar una tarjeta en un cajero automático si se está en el transcurso de una operación.
Para los casos de uso complejos se puede construir un Diagrama de Estados. El Diagrama de
Estados del sistema sería una combinación de los diagramas de todos los casos de uso.
El uso de Diagramas de Estados es opcional. Tan solo los usaremos cuando consideremos que
nos ayudan a expresar mejor el comportamiento del elemento descrito.
IV.4 Fase de Construcción: Diseño

En la fase de Diseño se crea una solución a nivel lógico para satisfacer los requisitos, basándose
en el conocimiento reunido en la fase de Análisis.
IV.4.1 Actividades
Las actividades que se realizan en la etapa de Diseño son las siguientes:
1. Definir los Casos de Uso Reales.
2. Definir Informes e Interfaz de Usuario.
3. Refinar la Arquitectura del Sistema.
4. Definir los Diagramas de Interacción.
5. Definir el Diagrama de Clases de Diseño. (en paralelo con los Diagramas de Interacción)
42 IV.4 Fase de Construcción: Diseño
6. Definir el Esquema de Base de Datos.

El paso de Refinar la Arquitectura del Sistema no tiene por qué realizarse en la posición 3,
puede realizarse antes o después.
IV.4.2 Casos de Uso Reales

Un Caso de Uso Real describe el diseño real del caso de uso según una tecnología concreta de
entrada y de salida y su implementación. Si el caso de uso implica una interfaz de usuario, el
caso de uso real incluirá bocetos de las ventanas y detalles de la interacción a bajo nivel con los
widgets (botón, lista seleccionable, campo editable, etc.) de la ventana.
Como alternativa a la creación de los Casos de Uso Reales, el desarrollador puede crear bocetos
de la interfaz en papel, y dejar los detalles para la fase de implementación.
IV.4.3 Diagramas de Colaboración

Los Diagramas de Interacción muestran el intercambio de mensajes entre instancias del modelo
de clases para cumplir las post-condiciones establecidas en un contrato.
Hay dos clases de Diagramas de Interacción:
1. Diagramas de Colaboración.
2. Diagramas de Secuencia.
La notación en UML para ambos es la definida en la página 10.
De entre ambos tipos se prefieren los Diagramas de Colaboración por su expresividad y por su
economía espacial (una interacción compleja puede ser muy larga en un Diagrama de
Secuencia).
La creación de los Diagramas de Colaboración de un sistema es una de las actividades más
importantes en el desarrollo orientado a objetos, pues al construirlos se toman unas decisiones
clave acerca del funcionamiento del futuro sistema. La creación de estos diagramas, por tanto,
debería ocupar un porcentaje significativo en el esfuerzo dedicado al proyecto entero.
IV.4.3.1 Creación de Diagramas de Colaboración

Para crear los Diagramas de Colaboración se pueden seguir los siguientes consejos:
• Crear un diagrama separado para cada operación del sistema en desarrollo en el ciclo de
desarrollo actual.
q Para cada evento del sistema, hacer un diagrama con él como mensaje inicial.
• Si el diagrama se complica, dividirlo en diagramas más pequeños.
• Usando los apartados de responsabilidades y de post-condiciones del contrato de operación,
y la descripción del caso de uso como punto de partida, diseñar un sistema de objetos que
interaccionan para llevar a cabo las tareas requeridas.
La capacidad de realizar una buena asignación de responsabilidades a los distintos objetos es
una habilidad clave, y se va adquiriendo según aumenta la experiencia en el desarrollo
orientado a objetos.
Booch, Rumbaugh y Jacobson definen responsabilidad como “un contrato u obligación de una
clase o tipo”[BJR97]. Las responsabilidades están ligadas a las obligaciones de un objeto en
cuanto a su comportamiento. Básicamente, estas responsabilidades son de los dos siguientes
tipos:
• Conocer:
q Conocer datos privados encapsulados.
q Conocer los objetos relacionados.

q Conocer las cosas que puede calcular o derivar.
• Hacer:
q Hacer algo él mismo.
q Iniciar una acción en otros objetos.
q Controlar y coordinar actividades en otros objetos.
Por ejemplo, puedo decir que “un Recibo es responsable de imprimirse” (tipo hacer), o que “una
Transacción es responsable de saber su fecha” (tipo conocer). Las responsabilidades de tipo
“conocer” se pueden inferir normalmente del Modelo Conceptual.
Una responsabilidad no es lo mismo que un método, pero los métodos se implementan para
satisfacer responsabilidades.
IV.4.4 Diagrama de Clases de Diseño

Al construir los Diagramas de Colaboración se van usando clases procedentes del Modelo
Conceptual, junto con otras creadas para encargarse de responsabilidades específicas. El
conjunto de todas las clases usadas, junto con sus relaciones, forma el Diagrama de Clases de
Diseño.
Sesion
+ create(login : String)
1
<<solitario>>
Gestor_Cuentas <<solitario>>
+ conseguir_cuenta(login : String) : Cuenta

trabaja_con
gestiona
1
-cuenta
1
* Cuenta
Operacion - cuota_disco : int
lanza_al_iniciarse
- parametros : String[] 1
+ lanzar_operacion_inicial()
-operacion_inicial + crear_clave(usuario : String) : String
+ create(parametros : long[])
+ lanzar() -cuentas_abiertas *
recibe_peticiones_de
<<local>>
<<solitario>>
<<solitario>>
Servidor_Claves
+ dar_clave(nombre : int, cuenta : Cuenta)

+ invalidar_clave(mensaje : Mensaje, linea : int)
Figura 37 Ejemplo de Diagrama de Clases de Diseño
44 IV.4 Fase de Construcción: Diseño
Un Diagrama de Clases de Diseño muestra la especificación para las clases software de una
aplicación. Incluye la siguiente información:
• Clases, asociaciones y atributos.
• Interfaces, con sus operaciones y constantes.
• Métodos.
• Navegabilidad.
• Dependencias.
A diferencia del Modelo Conceptual, un Diagrama de Clases de Diseño muestra definiciones de
entidades software más que conceptos del mundo real. En la Figura 37 se muestra un ejemplo de
Diagrama de Clases de Diseño sencillo.
IV.4.4.1 Relaciones de Dependencia para Representar Visibilidad entre Clases

Cuando una clase conoce a otra por un medio que no es a través de un atributo (una asociación
con la navegabilidad adecuada), entonces es preciso indicar esta situación por medio de una
dependencia.
Un objeto debe conocer a otro para poder llamar a uno de sus métodos, se dice entonces que el
primer objeto tiene “visibilidad” sobre el segundo. La visibilidad más directa es por medio de
atributo, cuando hay una asociación entre ambas clases y se puede navegar de la primera a la
segunda (un atributo de la primera es un puntero a un objeto de la segunda). Hay otros tres tipos
de visibilidad que hay que representar en el diagrama de clases mediante relaciones de
dependencia:
Ø Parámetro: Cuando a un método de una clase se le pasa como parámetro un objeto de
otra clase, se dice que la primera tiene visibilidad de parámetro sobre la segunda. La
relación de dependencia entre ambas clases se etiqueta con el estereotipo
<<parámetro>> (<<parameter>> en inglés).
Ø Local: Cuando en un método de una clase se define una variable local que es un objeto
de otra clase, se dice que la primera tiene visibilidad local sobre la segunda. La relación
de dependencia entre ambas clases se etiqueta con el estereotipo <<local>>.
Ø Global: Cuando hay una variable global en el sistema, y un método de una clase llama a
un método de esa variable global, se dice que la clase tiene visibilidad global sobre la
clase a la que pertenece la instancia que es una variable global. La relación de
dependencia entre ambas clases se etiqueta con el estereotipo <<global>>.
No es necesario representar la relación de dependencia entre clases que ya están relacionadas
por medio de una asociación, que se trata de una “dependencia” más fuerte. Las relaciones de
dependencia se incluyen tan solo para conocer qué elementos hay que revisar cuando se realiza
un cambio en el diseño de un elemento del sistema.
a) Solitario: Caso Particular de Visibilidad global

El uso de variables globales no se aconseja por los efectos laterales que se pueden presentar,
pero hay un caso en el que sí hay cierta globalidad: las clases que sólo van a tener una instancia.
Suele tratarse de clases que se han creado en el diseño, que no aparecían en el Modelo
Conceptual.
Varias clases de nuestro sistema pueden querer llamar a los métodos de la única instancia de una
clase de ese tipo, entonces sí se considera que es beneficioso que se pueda acceder a esa
instancia como un valor accesible de forma global. Una solución elegante para este caso se
implementa mediante un método de clase para obtener esa única instancia (los métodos de clase
los permiten algunos lenguajes orientados a objetos, por ejemplo Java), en vez de definirla
directamente como una variable global. Para indicar que una clase sólo va a tener una instancia,
se etiqueta la clase con el estereotipo <<solitario>> (<<singleton>> en inglés), y las relaciones

de dependencia entre las clases que la usan y se etiquetan también <<solitario>> en vez de
<<global>>.
A continuación se muestra un ejemplo del código en Java de una clase solitario:
public class Solitario {
// se define la instancia como atributo de clase (static)

Solitario static instancia := null;
// método de clase que devuelve la instancia

public static Solitario dar_instancia() {
if (instancia = = null) {
// si no está creada la instancia la crea
instancia := new Solitario();
}
return instancia;
}
... // otros métodos de la clase
}
Cuando otra clase quiere llamar a un método de la instancia incluye el siguiente código:
variable Solitario;
variable = Solitario.dar_instancia();
variable.método(); // llamada al método que necesitamos
IV.4.4.2 Construcción de un Diagrama de Clases de Diseño

Para crear un Diagrama de Clases de Diseño se puede seguir la siguiente estrategia:
1. Identificar todas las clases participantes en la solución software. Esto se lleva a cabo
analizando los Diagramas de Interacción.
2. Representarlas en un diagrama de clases.
3. Duplicar los atributos que aparezcan en los conceptos asociados del Modelo Conceptual.
4. Añadir los métodos, según aparecen en los Diagramas de Interacción.
5. Añadir información de tipo a los atributos y métodos.
6. Añadir las asociaciones necesarias para soportar la visibilidad de atributos requerida.
7. Añadir flechas de navegabilidad a las asociaciones para indicar la dirección de visibilidad
de los atributos.
8. Añadir relaciones de dependencia para indicar visibilidad no correspondiente a atributos.
No todas las clases que aparecían en el Modelo Conceptual tienen por qué aparecer en el
Diagrama de Clases de Diseño. De hecho, tan solo se incluirán aquellas clases que tengan
interés en cuanto a que se les ha asignado algún tipo de responsabilidad en el diseño de la
interacción del sistema. No hay, por tanto, un transición directa entre el Modelo Conceptual y el
Diagrama de Clases de Diseño, debido a que ambos se basan en enfoques completamente
distintos: el primero en comprensión de un dominio, y el segundo en una solución software.
En la fase de Diseño se añaden los detalles referentes al lenguaje de programación que se vaya a
usar. Por ejemplo, los tipos de los atributos y parámetros se expresarán según la sintaxis del
lenguaje de implementación escogido.
46 IV.5 Fases de Implementación y Pruebas
IV.4.4.3 Navegabilidad
La navegabilidad es una propiedad de un rol (un extremo de una asociación) que indica que es
posible “navegar” unidireccionalmente a través de la asociación, desde objetos de la clase
origen a objetos de la clase destino. Como se vio en la parte II, se representa en UML mediante
una flecha.
La navegabilidad implica visibilidad, normalmente visibilidad por medio de un atributo en la
clase origen. En la implementación se traducirá en la clase origen como un atributo que sea una
referencia a la clase destino.
Las asociaciones que aparezcan en el Diagrama de Clases deben cumplir una función, deben ser
necesarias, si no es así deben eliminarse.
Las situaciones más comunes en las que parece que se necesita definir una asociación con
navegabilidad de A a B son:
• A envía un mensaje a B.
• A crea una instancia B.
• A necesita mantener una conexión con B.
IV.4.4.4 Visibilidad de Atributos y Métodos

Los atributos y los métodos deben tener una visibilidad asignada, que puede ser:
+ Visibilidad pública.
# Visibilidad protegida.
- Visibilidad privada.
También puede ser necesario incluir valores por defecto, y todos los detalles ya cercanos a la
implementación que sean necesarios para completar el Diagrama de Clases.
IV.4.5 Otros Aspectos en el Diseño del Sistema

En los puntos anteriores se ha hablado de decisiones de diseño a un nivel de granularidad fina,
con las clases y objetos como unidades de decisión. En el diseño de un sistema es necesario
también tomar decisiones a un nivel más alto sobre la descomposición de un sistema en
subsistemas y sobre la arquitectura del sistema (ver sección III.2.5). Esta parte del Diseño es lo
que se denomina Diseño del Sistema. Estas decisiones no se toman de forma distinta en un
desarrollo orientado a objetos a como se llevan a cabo en un desarrollo tradicional. Por tanto, no
se va a entrar en este documento en cómo se realiza esta actividad.
Sí hay que tener en cuenta que las posibles divisiones en subsistemas tienen que hacerse en base
a las clases definidas en el Diagrama de Clases del Diseño.
IV.5 Fases de Implementación y Pruebas

Una vez se tiene completo el Diagrama de Clases de Diseño, se pasa a la implementación en el
lenguaje de programación elegido.
El programa obtenido se depura y prueba, y ya se tiene una parte del sistema funcionando que se
puede probar con los futuros usuarios, e incluso poner en producción si se ha planificado una
instalación gradual.
Una vez se tiene una versión estable se pasa al siguiente ciclo de desarrollo para incrementar el
sistema con los casos de uso asignados a tal ciclo.
Bibliografía 47
V Bibliografía
[Booch99] El Lenguaje Unificado de Modelado. G. Booch, J. Rumbaugh, I. Jacobson.

Addison Wesley Iberoamericana, 1999.
[Booch94] Object-Oriented Analysis and Design. G. Booch. Benjamin/Cummings,
1994.
[BJR97] The UML Specification Document. G. Booch, I. Jacobson and J.
Rumbaugh. Rational Software Corp., 1997.
[Jacobson92] Object-Oriented Software Engineering: A Use Case Driven Approach. I.
Jacobson. Addison-Wesley, 1992.
[Larman99] UML y Patrones. C. Larman. Prentice Hall, 1999.
[Rumbaugh91] Object-Oriented Modeling and Design. J. Rumbaugh et al.Prentice-

Hall,1991.
[UML00] UML Resource Center. Rational Software. http://www.rational.com/uml/
Universidad Central de Venezuela. Recopilación y Preparación Prof. Yusneyi Carballo
Escuela de Computación - Algoritmos y Programación Oct-05, Julio 07
Tema 8.
PROGRAMACIÓN ORIENTADA A OBJETOS
I. CONCEPTOS BÁSICOS
1. Programación Orientada a Objeto (POO)

La programación Orientada a Objetos es una metodología que basa la estructura de los programas en torno a los objetos.
Los lenguajes de POO ofrecen medios y herramientas para describir los objetos manipulados por un programa. Más que
describir cada objeto individualmente, estos lenguajes proveen una construcción (Clase) que describe a un conjunto de objetos
que poseen las mismas propiedades.
2. Objeto
Es una entidad (tangible o intangible) que posee características y acciones que realiza por sí solo o interactuando con otros
objetos.
Un objeto es una entidad caracterizada por sus atributos propios y cuyo comportamiento está determinado por las acciones o
funciones que pueden modificarlo, así como también las acciones que requiere de otros objetos. Un objeto tiene identidad e
inteligencia y constituye una unidad que oculta tanto datos como la descripción de su manipulación. Puede ser definido como
una encapsulación y una abstracción: una encapsulación de atributos y servicios, y una abstracción del mundo real.
Para el contexto del Enfoque Orientado a Objetos (EOO) un objeto es una entidad que encapsula datos (atributos) y acciones o
funciones que los manejan (métodos). También para el EOO un objeto se define como una instancia o particularización de una
clase.
Los objetos de interés durante el desarrollo de software no sólo son tomados de la vida real (objetos visibles o tangibles),
también pueden ser abstractos. En general son entidades que juegan un rol bien definido en el dominio del problema. Un libro,
una persona, un carro, un polígono, son apenas algunos ejemplos de objeto.
Cada objeto puede ser considerado como un proveedor de servicios utilizados por otros objetos que son sus clientes. Cada
objeto puede ser a al vez proveedor y cliente. De allí que un programa pueda ser visto como un conjunto de relaciones entre
proveedores clientes. Los servicios ofrecidos por los objetos son de dos tipos:
1.- Los datos, que llamamos atributos.
2.- Las acciones o funciones, que llamamos métodos.
Características Generales
Un objeto se identifica por un nombre o un identificador único que lo diferencia de los demás. Ejemplo: el objeto
Cuenta de Ahorros número 12345 es diferente al objeto Cuenta de Ahorros número 25789. En este caso el identificador que
los hace únicos es el número de la cuenta.
Un objeto posee estados. El estado de un objeto está determinado por los valores que poseen sus atributos en un
momento dado.
Un objeto tiene un conjunto de métodos. El comportamiento general de los objetos dentro de un sistema se describe o
representa mediante sus operaciones o métodos. Los métodos se utilizarán para obtener o cambiar el estado de los objetos,
así como para proporcionar un medio de comunicación entre objetos.
Un objeto tiene un conjunto de atributos. Los atributos de un objeto contienen valores que determinan el estado del
objeto durante su tiempo de vida. Se implementan con variables, constantes y estructuras de datos (similares a los campos
de un registro).
Pág. 1
Los objetos soportan encapsulamiento. La estructura interna de un objeto normalmente está oculta a los usuarios del
mismo. Los datos del objeto están disponibles solo para ser manipulados por los propios métodos del objeto. El único
mecanismo que lo conecta con el mundo exterior es el paso de mensajes.
Un objeto tiene un tiempo de vida dentro del programa o sistema que lo crea y utiliza. Para ser utilizado en un
algoritmo el objeto debe ser creado con una instrucción particular (New ó Nuevo) y al finalizar su utilización es destruido con
el uso de otra instrucción o de manera automática.
3. Clase
La clase es la unidad de modularidad en el EOO. La tendencia natural del individuo es la de clasificar los objetos según sus
características comunes (clase). Por ejemplo, las personas que asisten a la universidad se pueden clasificar (haciendo
abstracción) en estudiante, docente, empleado e investigador.
La clase puede definirse como la agrupación o colección de objetos que comparten una estructura común y un comportamiento
común.
Es una plantilla que contiene la descripción general de una colección de objetos. Consta de atributos y métodos que resumen
las características y el comportamiento comunes de un conjunto de objetos.
Todo objeto (también llamado instancia de una clase), pertenece a alguna clase. Mientras un objeto es una entidad concreta
que existe en el tiempo y en el espacio, una clase representa solo una abstracción.
Todos aquellos objetos que pertenecen a la misma clase son descritos o comparten el mismo conjunto de atributos y métodos.
Todos los objetos de una clase tienen el mismo formato y comportamiento, son diferentes únicamente en los valores que
contienen sus atributos. Todos ellos responden a los mismos mensajes.
Su sintaxis algorítmica es:
Clase <Nombre de la Clase>
…
FClase <Nombre de la Clase>;
Una clase es un nivel de abstracción alto. La clase permite describir un conjunto de características comunes para los
objetos que representa. Ejemplo: La clase Avión se puede utilizar para definir los atributos (tipo de avión, distancia, altura,
velocidad de crucero, capacidad, país de origen, etc.) y los métodos (calcular posición en el vuelo, calcular velocidad de
vuelo, estimar tiempo de llegada, despegar, aterrizar, volar, etc.) de los objetos particulares Avión que representa.
Un objeto es una instancia de una clase. Cada objeto concreto dentro de un sistema es miembro de una clase específica y
tiene el conjunto de atributos y métodos especificados en la misma
Las clases se relacionan entre sí mediante una jerarquía. Entre las clases se establecen diferentes tipos de relaciones de
herencia, en las cuales la clase hija (subclase) hereda los atributos y métodos de la clase padre (superclase), además de
incorporar sus propios atributos y métodos.
Ejemplos, Superclase: Clase Avión
Subclases de Avión: Clase Avión Comercial, Avión de Combate, Avión de Transporte
Los nombres o identificadores de las clases deben colocarse en singular (clase Animal, clase Carro, clase Alumno).
Pág. 2
4. Relación entre Clase y Objeto

Algorítmicamente, las clases son descripciones netamente estáticas o plantillas que describen objetos. Su rol es definir
nuevos tipos conformados por atributos y operaciones.
Por el contrario, los objetos son instancias particulares de una clase. Las clases son una especie de molde de fábrica, en
base al cual son construidos los objetos. Durante la ejecución de un programa sólo existen los objetos, no las clases.
La declaración de una variable de una clase NO crea el objeto.
La asociación siguiente: <Nombre_Clase> <Nombre_Variable>; (por ejemplo, Rectángulo R), no genera o no crea
automáticamente un objeto Rectángulo. Sólo indica que R será una referencia o una variable de objeto de la clase Rectángulo.
La creación de un objeto, debe ser indicada explícitamente por el programador, de forma análoga a como inicializamos las
variables con un valor dado, sólo que para los objetos se hace a través de un método Constructor (ver punto Métodos).
5. Atributo
Son los datos o variables que caracterizan al objeto y cuyos valores en un momento dado indican su estado.
Un atributo es una característica de un objeto. Mediante los atributos se define información oculta dentro de un objeto, la cual
es manipulada solamente por los métodos definidos sobre dicho objeto
Un atributo consta de un nombre y un valor. Cada atributo está asociado a un tipo de dato, que puede ser simple (entero, real,
lógico, carácter, string) o estructurado (arreglo, registro, archivo, lista, etc.)
Su sintaxis algorítmica es: <Modo de Acceso> <Tipo de dato> <Nombre del Atributo>;
Los modos de acceso son:
Público: Atributos (o Métodos) que son accesibles fuera de la clase. Pueden ser llamados por cualquier clase, aun si no
está relacionada con ella. Este modo de acceso también se puede representar con el símbolo +
Privado: Atributos (o Métodos) que sólo son accesibles dentro de la implementación de la clase. También se puede
representar con el símbolo –
Protegido: Atributos (o Métodos) que son accesibles para la propia clase y sus clases hijas (subclases). También se puede
representar con el símbolo #
6. Método
Son las operaciones (acciones o funciones) que se aplican sobre los objetos y que permiten crearlos, cambiar su estado o
consultar el valor de sus atributos.
Los métodos constituyen la secuencia de acciones que implementan las operaciones sobre los objetos. La implementación de
los métodos no es visible fuera de objeto.
La sintaxis algorítmica de los métodos expresados como funciones y acciones es:
Para funciones se pueden usar cualquiera de estas dos sintaxis:
<Modo de Acceso> Función <Nombre> [(Lista Parámetros)]: <Descripción del Tipo de datos>
Para acciones:
<Modo de Acceso> Acción <Nombre> [(Lista Parámetros)] donde los parámetros son opcionales
Ejemplo: Un rectángulo es un objeto caracterizado por los atributos Largo y Ancho, y por varios métodos, entre otros Calcular
su área y Calcular su perímetro.
Pág. 3
Cada método tiene un nombre, cero o más parámetros (por valor o por referencia) que recibe o devuelve y un algoritmo con
el desarrollo del mismo.
En particular se destaca el método constructor, que no es más que el método que se ejecuta cuando el objeto es creado.
Este constructor suele tener el mismo nombre de la clase/ objeto, pero aunque es una práctica común, el método
constructor no necesariamente tiene que llamarse igual a la clase (al menos, no en pseudos-código). Es un método que
recibe cero o más parámetros y lo usual es que inicialicen los valores de los atributos del objeto.
En lenguajes como Java y C++ se puede definir más de un método constructor, que normalmente se diferencian entre sí
por la cantidad de parámetros que reciben.
Los métodos se ejecutan o activan cuando el objeto recibe un mensaje, enviado por un objeto o clase externo al que lo
contiene, o por el mismo objeto de manera local.
Creación de Objetos y Métodos Constructores:

Cada objeto o instancia de una clase debe ser creada explícitamente a través de un método u operación especial denominado
Constructor. Los atributos de un objeto toman valores iniciales dados por el constructor. Por convención el método constructor
tiene el mismo nombre de la clase y no se le asocia un modo de acceso (es público).
Algunos lenguajes proveen un método constructor por defecto para cada clase y/o permiten la definición de más de un método
constructor.
Método de Destructores de objetos:

Los objetos que ya no son utilizados en un programa, ocupan inútilmente espacio de memoria, que es conveniente recuperar
en un momento dado. Según el lenguaje de programación utilizado esta tarea es dada al programador o es tratada
automáticamente por el procesador o soporte de ejecución del lenguaje.
En la notación algorítmica NO tomaremos en cuenta ese problema de administración de memoria, por lo tanto no definiremos
formas para destruir objetos. En cambio al utilizar lenguajes de programación si debemos conocer los métodos destructores
suministrados por el lenguaje y utilizarlos a fin de eliminar objetos una vez no sean útiles.
7. Mensaje
Es la petición de un objeto a otro para solicitar la ejecución de alguno de sus métodos o para obtener el valor de un atributo
público.
Estructuralmente, un mensaje consta de 3 partes:
Identidad del receptor: Nombre del objeto que contiene el método a ejecutar.
Nombre del método a ejecutar: Solo los métodos declarados públicos.
Lista de Parámetros que recibe el método (cero o mas parámetros)
Su sintaxis algorítmica es: <Variable_Objeto>.<Nombre_Método> ( [<Lista de Parámetros> ] );
Cuando el objeto receptor recibe el mensaje, comienza la ejecución del algoritmo contenido dentro del método invocado,
recibiendo y/o devolviendo los valores de los parámetros correspondientes, si los tiene ya que son opcionales: ( [ ] )
Pág. 4
Ejemplo 1, Definición de la Clase Rectángulo
IMPLEMENTACIÓN
Clase Rectángulo; Rectángulo
// Atributos Privado Real Largo
Privado: Privado Real Ancho
Real Largo, Ancho;
Constructor Acción Rectángulo(lar, anc)
// Métodos
Público Función Área: Real
// método constructor
Público Función Perímetro: Real
Acción Rectángulo(Real lar, anc);
Largo = lar;
Ancho = anc;
FAcción;

// Retorna el área o superficie ocupada por el rectángulo
retornar(Largo * Ancho);
FFunción Área;

// Retorna el perímetro del rectángulo
retornar(2 * (Largo + Ancho));
FFunción Perímetro;
FClase Rectángulo;
// Uso de la clase rectángulo

Acción Principal
Rectángulo R; // se declara una variable de tipo objeto Rectángulo, a la cual llamaremos R
Real L, A; // se declaran las variables reales L y A para largo y ancho del rectángulo
Escribir(“Suministre a continuación los valores para el largo y el ancho”);
Leer(L); Leer(A);
R.Rectángulo(L, A);
Escribir(“Resultados de los cálculos:”);
Escribir(“Área: ”+ R.Área + “ - Perímetro ” + R.Perímetro);
FAcción Principal;
Pág. 5
II. REPRESENTACIÓN EN NOTACIÓN ALGORÍTMICA DE UNA CLASE

Las clases son el elemento principal dentro del enfoque orientado a objetos. En este lenguaje las declaraciones forman parte de
su propio grupo, el grupo [Clases]. Cada una de las declaraciones de clase debe tener el siguiente formato:
Clase <Identificador> [Hereda de: <Clases>]

Atributos
Público:
[Constantes]; [Variables]; o [Estructuras];
Privado:
Protegido:
Operaciones
Público:
[Métodos]
Privado:
[Métodos]
Protegido:
[Métodos]
FClase <Identificador>
En el caso de la especificación de los Atributos o de los Métodos los modos de acceso Público (+), Privado (-) o Protegido (#)
pueden omitirse, solamente en el caso en el que los grupos [Constantes], [Estructuras] y [Variables] son vacíos, es decir, no se
estén declarando Atributos ó Métodos.
NOTA: Otra forma de especificar los modos de acceso es colocándolo antes del nombre DE CADA UNO de los
atributos o métodos
Pág. 6
III. DIAGRAMAS DE CLASE

La representación gráfica de una o varias clases se hará mediante los denominados Diagramas de Clase. Para los diagramas
de clase se utilizará la notación que provee el Lenguaje de Modelación Unificado (UML, ver www.omg.org), a saber:
Las clases se denotan como rectángulos divididos en tres partes. La primera contiene el nombre de la clase, la segunda
contiene los atributos y la tercera los métodos.
Los modificadores de acceso a datos y operaciones, a saber: público, protegido y privado; se representan con los símbolos
+, # y – respectivamente, al lado derecho del atributo. (+ público, # protegido, - privado).
En la figura se muestra el método “color” que no tiene ningún parámetro y retorna un valor entero y el método
“modificar_tamaño” que tiene un real como parámetro y no retorna nada (es una acción).
Notación: Ejemplos
Nombre Clase Ventana Rectángulo
Atributos + Real área; Privado Real Lado
# Lógico visible;
Métodos + color: Entero Acción Cuadrado(Entero lad)
+ modificar_tamaño(Real porcentaje) Público Función Área: Real
IV. RELACIONES ENTRE CLASES

Las clases no se construyen para que trabajen de manera aislada, la idea es que ellas se puedan relacionar entre sí, de
manera que puedan compartir atributos y métodos sin necesidad de rescribirlos.
La posibilidad de establecer jerarquías entre las clases es una característica que diferencia esencialmente la programación
orientada a objetos de la programación tradicional, ello debido fundamentalmente a que permite extender y reutilizar el código
existente sin tener que rescribirlo cada vez que se necesite.
Los cuatro tipos de relaciones entre clases estudiados en este curso serán:
Herencia (Generalización / Especialización o Es-un)
Agregación (Todo / Parte o Forma-parte-de)
Composición (Es parte elemental de)
Asociación (entre otras, la relación Usa-a)
1. Relación de Herencia (Generalización / Especialización, Es un)

Es un tipo de jerarquía de clases, en la que cada subclase contiene los atributos y métodos de una (herencia simple) o más
superclases (herencia múltiple).
Mediante la herencia las instancias de una clase hija (o subclase) pueden acceder tanto a los atributos como a los métodos
públicos y protegidos de la clase padre (o superclase). Cada subclase o clase hija en la jerarquía es siempre una extensión
(esto es, conjunto estrictamente más grande) de la(s) superclase(s) o clase(s) padre(s) y además incorporar atributos y
métodos propios, que a su vez serán heredados por sus hijas.
Representación:
En la notación algorítmica: Se coloca el nombre de la clase padre después de la frase Hereda de del encabezado de la
clase y se usan sus atributos y métodos públicos o protegidos. Ejemplo: Clase Punto3D Hereda de Punto2D
Pág. 7
En el diagrama de clases: La herencia se representa mediante una relación de generalización/especificación, que se denota
de la siguiente forma:
clase hija clase madre subclase superclase
Ejemplo: El siguiente diagrama de clases muestra la relación de Herencia entre la Clase Animal y sus hijas
Animal
Mamífero Reptil
Perro Gato Humano Cocodrilo Serpiente
Hombre Mujer
2. Relación de Agregación (Todo / Parte, Forma parte de)

Es una relación que representa a los objetos compuestos por otros objetos. Indica Objetos que a su vez están formados por
otros. El objeto en el nivel superior de la jerarquía es el todo y los que están en los niveles inferiores son sus partes o
componentes.
Representación en el Diagrama de Clase
La relación forma parte de, no es más que una asociación, que se denota:
Nombre del objeto multiplicidad Nombre del objeto 4 .. *

carro ruedas
de nivel superior que lo compone
Si motor forma parte de carro, la flecha apunta a la clase motor, y el diamante va pegado a carro.
La multiplicidad es el rango de cardinalidad permitido que puede asumir la asociación, se denota LI..LS. Se puede usar * en el
limite superior para representar una cantidad ilimitada (ejemplo: 3..*).
Ejemplo: Objeto Casa descrito en términos de sus componentes
Casa
1 .. * 1 .. * 0 .. *
Habitación Baño Terraza
1 .. * 0 .. 4 3 .. 4
Puerta Ventana Pared
Pág. 8
3. Relación de Composición
Un componente es parte esencial de un elemento. La relación es más fuerte que el caso de agregación, al punto que si el
componente es eliminado o desaparece, la clase mayor deja de existir.
Representación en el Diagrama de Clases
La relación de composición, se denota de la siguiente forma:
clase mayor clase componente persona corazón
4. Relación de Asociación («uso», usa, cualquier otra relación)

Es una asociación que se establece cuando dos clases tienen una dependencia de utilización, es decir, una clase utiliza
atributos y/o métodos de otra para funcionar. Estas dos clases no necesariamente están en jerarquía, es decir, no
necesariamente una es clase padre de la otra, a diferencia de las otras relaciones de clases.
El ejemplo mas común de esta relación es de objetos que son utilizados por los humanos para alguna función, como Lápiz (se
usa para escribir), tenedor (se usa para comer), silla (se usa para sentarse), etc. Otro ejemplo son los objetos Cajero y Cuenta.
El Cajero “usa a” la cuenta para hacer las transacciones de consulta y retiro y verificar la información del usuario.
Representación en el Diagrama de Clases
La relación de uso, se denota con una dependencia estereotipada:
usa a
clase 1 clase 2
Ejemplos:
«uso» recarga
Impresora Cartucho_tinta Estudiante Portamina
Pág. 9
V. FUNDAMENTOS DEL ENFOQUE ORIENTADO A OBJETO

El Enfoque Orientado a Objeto se basa en cuatro principios que constituyen la base de todo desarrollo orientado a objetos.
Estos principios son: la Abstracción, el Encapsulamiento, la Modularidad y la Herencia.
Otros elementos a destacar (aunque no fundamentales) en el EOO son: Polimorfismo, Enlace dinámico (o binding),
Concurrencia y Persistencia.
Fundamento 1: Abstracción
Es el principio de ignorar aquellos aspectos de un fenómeno observado que no son relevantes, con el objetivo de
concentrarse en aquellos que si lo son. Una abstracción denota las características esenciales de un objeto (datos y
operaciones), que lo distingue de otras clases de objetos. Decidir el conjunto correcto de abstracciones de un determinado
dominio, es el problema central del diseño orientado a objetos.
Los mecanismos de abstracción son usados en el EOO para extraer y definir del medio a modelar, sus características y su
comportamiento. Dentro del EOO son muy usados mecanismos de abstracción: la Generalización, la Agregación y la
clasificación.
La generalización es el mecanismo de abstracción mediante el cual un conjunto de clases de objetos son agrupados en
una clase de nivel superior (Superclase), donde las semejanzas de las clases constituyentes (Subclases) son enfatizadas, y
las diferencias entre ellas son ignoradas. En consecuencia, a través de la generalización, la superclase almacena datos
generales de las subclases, y las subclases almacenan sólo datos particulares. La especialización es lo contrario de la
generalización. La clase Médico es una especialización de la clase Persona, y a su vez, la clase Pediatra es una
especialización de la superclase Médico.
La agregación es el mecanismo de abstracción por el cual una clase de objeto es definida a partir de sus partes (otras
clases de objetos). Mediante agregación se puede definir por ejemplo un computador, por descomponerse en: la CPU, la
ULA, la memoria y los dispositivos periféricos. El contrario de agregación es la descomposición.
La clasificación consiste en la definición de una clase a partir de un conjunto de objetos que tienen un comportamiento
similar. La ejemplificación es lo contrario a la clasificación, y corresponde a la instanciación de una clase, usando el
ejemplo de un objeto en particular.
Fundamento 2: Encapsulamiento (Ocultamiento de Información)

Es la propiedad del EOO que permite ocultar al mundo exterior la representación interna del objeto. Esto quiere decir
que el objeto puede ser utilizado, pero los datos esenciales del mismo no son conocidos fuera de él.
La idea central del encapsulamiento es esconder los detalles y mostrar lo relevante. Permite el ocultamiento de la información
separando el aspecto correspondiente a la especificación de la implementación; de esta forma, distingue el "qué hacer" del
"cómo hacer". La especificación es visible al usuario, mientras que la implementación se le oculta.
El encapsulamiento en un sistema orientado a objeto se representa en cada clase u objeto, definiendo sus atributos y métodos
con los siguientes modos de acceso:
Público (+) Atributos o Métodos que son accesibles fuera de la clase. Pueden ser llamados por cualquier clase, aun si no
está relacionada con ella.
Privado (-) Atributos o Métodos que solo son accesibles dentro de la implementación de la clase.
Protegido (#): Atributos o Métodos que son accesibles para la propia clase y sus clases hijas (subclases).
Los atributos y los métodos que son públicos constituyen la interfaz de la clase, es decir, lo que el mundo exterior conoce de la
misma.
Normalmente lo usual es que se oculten los atributos de la clase y solo sean visibles los métodos, incluyendo entonces algunos
de consulta para ver los valores de los atributos. El método constructor (Nuevo, New) siempre es Público.
Pág. 10
Fundamento 3: Modularidad
Es la propiedad que permite tener independencia entre las diferentes partes de un sistema. La modularidad consiste
en dividir un programa en módulos o partes, que pueden ser compilados separadamente, pero que tienen conexiones
con otros módulos. En un mismo módulo se suele colocar clases y objetos que guarden una estrecha relación. El sentido de
modularidad está muy relacionado con el ocultamiento de información.
Fundamento 4: Herencia
Es el proceso mediante el cual un objeto de una clase adquiere propiedades definidas en otra clase que lo preceda en
una jerarquía de clasificaciones. Permite la definición de un nuevo objeto a partir de otros, agregando las diferencias entre
ellos (Programación Diferencial), evitando repetición de código y permitiendo la reusabilidad.
Las clases heredan los datos y métodos de la superclase. Un método heredado puede ser sustituido por uno propio si ambos
tienen el mismo nombre.
La herencia puede ser simple (cada clase tiene sólo una superclase) o múltiple (cada clase puede tener asociada
varias superclases). La clase Docente y la clase Estudiante heredan las propiedades de la clase Persona (superclase,
herencia simple). La clase Preparador (subclase) hereda propiedades de la clase Docente y de la clase Estudiante (herencia
múltiple).
Fundamento 5: Polimorfismo
Es una propiedad del EOO que permite que un método tenga múltiples implementaciones, que se seleccionan en base
al tipo objeto indicado al solicitar la ejecución del método.
El polimorfismo operacional o Sobrecarga operacional permite aplicar operaciones con igual nombre a diferentes clases o
están relacionados en términos de inclusión. En este tipo de polimorfismo, los métodos son interpretados en el contexto del
objeto particular, ya que los métodos con nombres comunes son implementados de diferente manera dependiendo de cada
clase.
Por ejemplo, el área de un cuadrado, rectángulo y círculo, son calculados de manera distinta; sin embargo, en sus clases
respectivas puede existir la implementación del área bajo el nombre común Área. En la práctica y dependiendo del objeto que
llame al método, se usará el código correspondiente.
Ejemplos, Superclase: Clase Animal Subclases: Clases Mamífero, Ave, Pez
Se puede definir un método Comer en cada subclase, cuya implementación cambia de acuerdo a la clase invocada, sin
embargo el nombre del método es el mismo.
Mamifero.Comer ≠ Ave.Comer ≠ Pez.Comer
Otro ejemplo de polimorfismo es el operador +. Este operador tiene dos funciones diferentes de acuerdo al tipo de dato de los
operandos a los que se aplica. Si los dos elementos son numéricos, el operador + significa suma algebraica de los mismos, en
cambio si por lo menos uno de los operandos es un String o Carácter, el operador es la concatenación de cadenas de
caracteres.
Otro ejemplo de sobrecarga es cuando tenemos un método definido originalmente en la clase madre, que ha sido
adaptado o modificado en la clase hija. Por ejemplo, un método Comer para la clase Animal y otro Comer que ha sido
adaptado para la clase Ave, quien está heredando de la clase Animal.
Cuando se desea indicar que se está invocando (o llamando) a un método sobrecargado y que pertenece a otra clase
(por ejemplo, a la clase padre) lo indicamos con la siguiente sintaxis:
Clase_Madre::nombre_método;
Para el ejemplo, la llamada en la clase hija Ave del método sobrecargado Comer de la clase madre Animal sería:
Animal::Comer
Pág. 11
VI. EJEMPLOS
Ejemplo 1, Definición de la Clase Rectángulo
Clase Rectángulo; Rectángulo

// Atributos - Real Largo
Privado: - Real Ancho
Real Largo, Ancho;
+ Acción Rectángulo
// Métodos + Función Área: Real
Constructor Rectángulo(Real lar, anc); + Función Perímetro: Real
Largo = lar;
Ancho = anc;
FConstructor;

// Retorna el área o superficie ocupada por el rectángulo
retornar(Largo * Ancho);
FFunción Área;

// Retorna el perímetro del rectángulo
retornar(2 * (Largo + Ancho));
FFunción Perímetro;
FClase Rectángulo;
Clase Principal
Acción Usa_Rectángulo
Rectángulo R; // se declara una variable de tipo objeto Rectángulo, a la cual llamaremos R
Real L, A; // se declaran las variables reales L y A para leer el largo y ancho dado por el usuario
Escribir(“Suministre a continuación los valores para el largo y el ancho”);
Leer(L, A);
R.Rectángulo(L, A);
Escribir(“Resultados de los cálculos:”);
Escribir(“Área: ”+ R.Área + “ - Perímetro ” + R.Perímetro);
FAcción Usa_Rectángulo;
FClase Principal;
Pág. 12
Ejemplo 2, Clase que implementa un punto en el plano real

Clase Punto2D
//Atributos
Protegido Real X, Y; // representan las coordenadas X e Y de un punto
// Métodos u operaciones
Público:
//constructores
Acción Punto2D
X = 0; Y = 0;
FAcción;
Acción Punto2D(Real CX, CY)

X = CX; Y = CY;
FAcción;
// otros métodos de la clase

Función CoordenadaX: Real
// devuelve el valor de la coordenada X del punto que hace la llamada
retornar(X);
Ffunción;
Función CoordenadaY: Real

// devuelve el valor de la coordenada Y del punto que hace la llamada
retornar(Y);
Ffunción;
Acción CambiarX(Real NX)

// modifica el valor de la coordenada X del punto que hace la llamada
X = NX;
Ffunción;
Acción CambiarY(Real NY)

// modifica el valor de la coordenada Y del punto que hace la llamada
Y = NY;
Ffunción;
Función Distancia(Real CX, CY): Real

// devuelve la distancia entre el punto actual y otro con coordenadas CX y CY
Real D; // variable donde se almacenará la distancia
D = (RestaC(X, CX) + RestaC(Y, CY)) ∧ (1/2);
retornar(D);
Ffunción;
Función Distancia(Ref Punto2D P): Real;

//devuelve la distancia entre el punto actual y otro punto P
retornar(Distancia(P.X, P.Y));
Ffunción Distancia;
Pág. 13
Protegido Función RestaC (Real X,Y): Real;

// devuelve la resta entre X y Y elevada al cuadrado
retornar((X – Y) ∧ 2));
Ffunción Resta_C;
FClase Punto2D;
Clase Prueba_Punto
Acción Principal
Real CX, CY; // valores para las coordenadas del punto a crear
Real D; // contiene la distancia entre los puntos
Escribir (“Introduzca las coordenadas X e Y del punto a crear: ”);
Leer(CX, CY);
Punto P = nuevo Punto2D(CX , CY);
Punto P1 = nuevo Punto2D; // crea un punto en el origen, es decir, en el punto (0.0 , 0.0)
D = P.Distancia(P1.CoordenadaX , P1.CoordenadaY;
Escribir (“Distancia entre el punto P y el origen: ” + D);
P1.CambiarX (15.0); P1.CambiarY(18.75); // se cambia a al punto (15.0 , 18.75)
Escribir (“Nuevo punto P1: (“ + P1.CoordenadaX + “ , “+ P1.CoordenadaY + “) “);
D = P.Distancia(P1);
Escribir (“La nueva Distancia entre P y P1 es: “+ D);
fAcción Principal;
FClase Prueba_Punto;
Ejemplo 3, Clase Punto3D que se deriva de la clase Punto2D

Clase Punto3D Hereda de Punto2D;
// Atributos
Protegido Real Z; // coordenada Z del punto
// Métodos u operaciones
Público:
// métodos constructores Punto3D
Acción Punto3D
// Crea un punto con coordenadas (0,0,0) reutilizando el constructor de un punto de 2D
Punto2D;
Z = 0;
FAcción;
Acción Punto3D(Real CX, CY, CZ)

// Crea un punto de tres coordenadas reutilizando el constructor de un punto de 2D
Punto2D(CX, CY);
Z = CZ;
FAcción;
Pág. 14
// otros métodos de la clase

Función CoordenadaZ: Real
// devuelve el valor de la coordenada Z del punto que hace la llamada
retornar(Z);
Ffunción;
Acción CambiarZ(Real NZ)

// modifica el valor de la coordenada Z del punto que hace la llamada
Z = NZ;
Ffunción;
Función Distancia3D(Real CX, CY, CZ): Real

// devuelve la distancia entre el punto actual y otro con coordenadas CX, CY y CZ
Real D; //contiene la distancia
D = RestaC(X, CX) + RestaC(Y, CY) + RestaC(Z, CZ);
D = D ∧ (1/2);
retornar(D);
Ffunción;
Función Distancia3D(Ref Punto3D P): Real

// devuelve la distancia entre el punto actual y otro punto P
retornar(Distancia3D(P.X, P.Y, P.Z));
Ffunción;
FClase Punto3D
Plantea tus reflexiones y respuestas a:

¿Te atreves
a pasar? 1. ¿Qué atributos y métodos hereda la clase Punto3D de la clase Punto2D?
2. ¿Qué atributos y métodos hereda la clase Punto2D de la clase Punto3D?
3. ¿Quiénes pueden usar los atributos y métodos de Punto2D?
4. Plantea un algoritmo principal que utilice las clases Punto2D y Punto3D
Pág. 15
Ejemplo 4, Clase Cuenta Bancaria

Clase CuentaBancaria
// atributos
Privado Entero Saldo;
Privado String NroCuenta;
Privado String Titular;
// métodos
Acción CuentaBancaria(Entero montoInicial; String num, nombre)
// asigna a los atributo de la clase sus valores iniciales
Saldo = montoInicial;
NroCuenta = num;
Titular = nombre;
Facción;
Público Acción depositar(Entero cantidad)

// incrementa el saldo de la cuenta
Saldo = Saldo + cantidad;
Facción;
Público Acción retirar(Entero cantidad)

// disminuye el saldo de la cuenta
Saldo = Saldo - cantidad;
Facción;
Público Función obtenerSaldo: Entero

// permite conocer el monto disponible o saldo de la cuenta
Retornar(saldo);
FFunción;
FinClase CuentaBancaria
Reflexiona y plantea propuestas para:

¿Te atreves
a pasar? 5. Crear un algoritmo principal que utilice la clase CuentaBancaria, creando
varios objetos cuenta y actualizando sus saldos. Recuerda agregar en tu
algoritmo principal las solicitudes de datos al usuario que consideres
necesarias y las validaciones de estos datos de entrada
6. ¿Desde tu algoritmo principal podrías actualizar directamente el valor del
atributo saldo? ¿Cómo lo puedes hacer?
7. Utiliza los métodos de la clase CuentaBancaria para verificar, en el algoritmo
principal, que no se retire un monto que el saldo no puede cubrir
Pág. 16
Ejemplo 5, Clase Raíces Ecuación de 2do Grado
Desarrollar un algoritmo bajo el enfoque orientado a objetos, que Ecuación2doGrado

permita calcular las raíces (reales e imaginarias) de una ecuación de Privado Real RaízReal1
segundo grado ax2+bx+c, dados los coeficientes a, b y c, con a>0. Privado Real RaízImaginaria1
Análisis: Privado Real RaízReal2
El objeto principal a ser tratado en este problema es la ecuación y se Privado Real RaízImaginaria2
implementará a través de la clase Ecuación2doGrado.
Se considerará que cada ecuación tiene asociadas como atributos sus Constructor Ecuación2doGrado(Real a, b, c)
raíces, las cuales deben ser calculadas por el método constructor a // Crea un Objeto Ecuacion2doGrado
través de una acción llamada Resolver. El método constructor tendrá Privado Acción Resolver(Real a, b, c)
tres parámetros, que son los coeficientes de la ecuación (a, b y c). // Calcula las raíces de la ecuación
La clase Ecuación2doGrado tendrá un método público para escribir Público Acción Imprimir
las raíces llamado Imprimir.
// Muestra las raíces de la ecuación
Clase Ecuación2doGrado;
Privado Real r1, r2, i1, i2;
Constructor Ecuación2doGrado(Real a, b, c);

Resolver(a,b,c);
FConstructor;
Privado Acción Resolver(Real a,b,c);

// Calcula las raíces de la ecuación ax2+bx+c
Real delta;
delta = b * b - (4*a*c);
Si delta ≥ 0 entonces // Cálculo de raíces reales
Si b > 0 entonces r1 = - ( b + delta^(1/2) ) / (2*a);
sino r1 = - (delta^(1/2) - b) / (2*a);
Fsi;
r2 = c / (r1*a); i1 = 0; i2 = 0;
sino // Cálculo de raíces complejas
r1 = -b / (2*a); r2 = -b / (2*a);
i1 = (-delta)^(1/2) / (2*a);
i2 = -i1; // Usamos la clase Ecuacion2doGrado
Fsi; Acción CalcularEcuaciones
FAcción Resolver; Real a,b,c;
Ecuación2doGrado E, F;
Escribir(“suministre coeficientes ecuación 1”);
Público Acción Imprimir; Leer(a, b, c);
# Muestra las raíces de la ecuación E.Ecuación2doGrado(a, b, c);
Escribir(r1, i1); E.Imprimir;
Escribir(r2, i2); Escribir(“suministre coeficientes ecuación 2”);
FAcción Imprimir; Leer(a, b, c);
F.Ecuación2doGrado(a, b, c);
FClase Ecuación2doGrado; F.Imprimir;
FAcción;
Pág. 17
CONCLUSIONES
En la Programación Orientada a Objetos los programas son representados por un conjunto de objetos que interactúan. Un
objeto engloba datos y operaciones sobre estos datos.
La Programación Orientada a Objetos constituye una buena opción a la hora de resolver un problema, sobre todo cuando éste
es muy extenso. En este enfoque de programación, se facilita evitar la repetición de código, no sólo a través de la creación de
clases que hereden propiedades y métodos de otras, sino además que el código es reutilizable por sistemas posteriores que
tengan alguna similitud con los ya creados.
BIBLIOGRAFÍA
BOOCH, Grady. "Object-oriented Analysis and Design with Applications". 2da. edición, Benjamín/Cummings
Publishing, 1993.
CARMONA, Rhadamés. “El Enfoque Orientado a Objetos”. Guía para estudiantes de Algoritmos y Programación. UCV.
2004.
COTO, Ernesto. Notación Algorítmica para estudiantes de Algoritmos y Programación. UCV.
DEITEL & DEITEL. "Cómo Programar en Java". Pearson Prentice Hall, 2004
JOYANES AGUILAR, Luis; RODRÍGUEZ BAENA, Luis; FERNÁNDEZ, Matilde. "Texto: Fundamentos de Programación,
Algoritmos, Estructuras de Datos y Objetos". McGraw-Hill, 2003
JOYANES AGUILAR, Luis; RODRÍGUEZ BAENA, Luis; FERNÁNDEZ, Matilde. "Libro de problemas: Fundamentos de
Programación, Algoritmos, Estructuras de Datos y Objetos". McGraw-Hill, 2003
WU, Thomas C. “Introducción a la Programación Orientada a Objetos en Java”. McGraw-Hill. 2001
Pág. 18
© berzal@acm.org
Diseño lógico
Diseño de bases de datos relacionales
© berzal@acm.org
Diseño lógico
de bases de datos relacionales
El modelo relacional:
El concepto de relación: tuplas,
tuplas, atributos y dominios.
Restricciones de integridad en el modelo relacional.
El proceso de diseño lógico en el modelo relacional.
Del modelo E/R al modelo relacional:
Entidades.
Entidades débiles.
Relaciones.
Relaciones de especialización / generalización.
Fusión de tablas.
Normalización.
1
© berzal@acm.org
Diseño lógico
de bases de datos relacionales
ETAPA DE DISEÑO LÓGICO
Objetivo: Creación del esquema conceptual y de los

esquemas externos de la base de datos en el modelo
de datos elegido (p.ej. relacional), independientemente
del SGBD que se vaya a utilizar.
Tarea: Transformar los esquemas obtenidos en el

diseño conceptual en un conjunto de estructuras
propias del modelo de datos elegido.
Resultado: Conjunto de estructuras propias del modelo

abstracto de datos (p.ej. relaciones).
2
© berzal@acm.org
El modelo relacional
El modelo de datos relacional organiza y representa
los datos en forma de tablas o relaciones:
Una base de datos relacional
es una colección de relaciones [tablas],
cada una de las cuales tiene un nombre único.
Representación Representación Modelo

lógica física relacional
Tabla Archivo secuencial Relación
Fila Registro Tupla
Columna Campo Atributo
3
© berzal@acm.org
El concepto de relación:
Tuplas,, atributos y dominios
Tuplas
id_trabajador nombre tarifa_hr tipo_de_oficio id_supv

1235 F. Aguilera 12,50 Electricista 1311
1412 A. Calvo 13,75 Fontanero 1540
2920 N. Marín 10,00 Carpintero null
3231 O. Pons 17,40 Albañil null
1540 J.M. Medina 11,75 Fontanero null
1311 J.C. Cubero 15,50 Electricista null
3001 D. Sánchez 8,20 Albañil 3231
4
© berzal@acm.org
El concepto de relación:
Tuplas,, atributos y dominios
Tuplas
Atributo (Ai): Elemento susceptible de tomar valores

(cada una de las columnas de la tabla).
Dominio (Di): Conjunto de valores que puede tomar

un atributo (se considera finito).
Tupla: Cada uno de los elementos que contiene una

Tupla:
instancia de la relación (filas).
5
© berzal@acm.org
El concepto de relación
Relación R(A
R(Ai..
..A
An)
Subconjunto del producto cartesiano D1×..
..××D n
(esto es, una tabla).
En una relación hay que distinguir dos aspectos:

Esquema de la relación:
relación: Los atributos A1..
..AAn
p.ej. Trabajadores (id_trabajador
(id_trabajador,, nombre, tarifa_hr,
tarifa_hr, tipo_de_oficio,
tipo_de_oficio, id_supv)
id_supv)
Instancia de la relación:
relación: El conjunto de tuplas
{(x1,x2,..,xn)} ⊆ D1×D2×..
..×
×Dn que la componen en
cada momento. 6
© berzal@acm.org
El concepto de relación
Relación R(A
R(Ai..
..A
An)
Subconjunto del producto cartesiano D1×..
..××D n
(esto es, una tabla).
Consecuencias de la definición de relación

como conjunto de tuplas:
tuplas:
No existen tuplas duplicadas
(concepto de clave primaria).
No existe orden en las tuplas
(ni en los atributos). 7
© berzal@acm.org
Esquema de la base de datos
Una base de datos relacional es un conjunto finito de

relaciones junto con una serie de restricciones o reglas
de integridad:
Restricción de integridad:
integridad: Condición necesaria para
preservar la corrección semántica de la base de datos.
Esquema de la base de datos:

datos: Colección de
esquemas de relaciones junto con las restricciones
de integridad que se definen sobre las relaciones.
8
© berzal@acm.org
Instancia de la base de datos
Instancia (o estado) de la base de datos:

datos:
Colección de instancias de relaciones que verifican las
restricciones de integridad.
Base de datos relacional:

relacional:
Instancia de la base de datos
junto con su esquema.
9
© berzal@acm.org
Restricciones de integridad:
Asociadas a las tuplas de una relación
p.ej. 0 ≤ edad ≤ 120

impuestos ≤ sueldo
En ocasiones, no se conoce el valor de un atributo para

una determinada tupla.
tupla. En esos casos, a ese atributo
de esa tupla se le asigna un valor nulo (null
(null)), que
indica que el valor de ese atributo es desconocido o,
simplemente, que ese atributo no es aplicable a esa
tupla..
tupla
10
© berzal@acm.org
Asociadas a las relaciones de la base de datos
Clave primaria:
Conjunto de atributos seleccionados para identificar
unívocamente a las tuplas de una relación.
Integridad de entidad:
Los atributos de la clave primaria no pueden
tomar valores nulos, ya que la clave primaria
debe permitirnos identificar unívocamente
cada tupla de la relación.
11
© berzal@acm.org
Clave externa: Conjunto de atributos de una relación

cuyos valores en las tuplas deben coincidir con valores
de la clave primaria de las tuplas de otra relación.
Integridad referencial:
Todos los valores no nulos de una clave externa
referencian valores reales de la clave referenciada.
12
© berzal@acm.org
La integridad referencial mantiene

las conexiones en las bases de datos relacionales:
imparte.NRP ∈ profesor.NRP
El profesor que imparte una asignatura
debe existir en la tabla de profesores.
cuenta.sucursal ∈ sucursal.número
Una cuenta tiene que pertenecer
a una sucursal existente. 13
© berzal@acm.org
El proceso de diseño lógico
en el modelo relacional
Transformación de un diagrama E/R en un esquema relacional:
1. Se transforman en tablas todos los tipos de entidades y

relaciones que aparecen en el diagrama E/R.
2. Se seleccionan las claves primarias para cada una de las
tablas de nuestro esquema lógico.
3. Fusión de tablas:
tablas: Se combinan aquellas tablas que
compartan su clave primaria.
4. Normalización: Se normaliza el esquema resultante
Normalización:
(al menos, hasta BCNF).
5. Se definen todas las restricciones de integridad
que sean aplicables al esquema obtenido. 14
© berzal@acm.org
Del modelo E/R al modelo relacional
Entidades
Cada tipo de entidad da lugar

a una tabla en la base de datos.
Atributos:
Atributos:
Los atributos del tipo de entidad.
Clave primaria:
primaria:
Una de las claves candidatas
del conjunto de entidades.
15
© berzal@acm.org
Entidades
Atributos compuestos
Se incluyen en la relación todos los atributos simples
(atómicos) que forman parte del atributo compuesto.
Atributos derivados
No se almacenarán en la base de datos, por lo que
no se incluyen como atributos de las relaciones.
16
© berzal@acm.org
Entidades
Atributos multivaluados
Se almacenan en una tabla auxiliar que incluya las
columnas necesarias para almacenar la clave primaria
del conjunto de entidades más aquéllas que se
necesiten para representar un valor del atributo MV.
Salvo que el atributo MV sea una clave alternativa del
conjunto de entidades, todas las columnas de la tabla
auxiliar formarán parte de su clave primaria.
La tabla auxiliar incluirá una clave externa que haga
referencia a la tabla correspondiente al conjunto de
entidades que incluye el atributo multivaluado.
multivaluado.
17
© berzal@acm.org
Entidades débiles
Atributos:
Atributos:
Además de los atributos propios de la entidad débil,
los atributos pertenecientes a la clave primaria de la
entidad fuerte de la que depende existencialmente la
entidad débil.
Apunte (CCC
(CCC,
, número, descripción, importe)
18
© berzal@acm.org
Entidades débiles
Clave primaria:
primaria:
La clave primaria de la entidad fuerte más un conjunto
de atributos propio de la entidad débil (discriminante).
Clave primaria de la entidad débil

=
Clave primaria de la entidad fuerte
+
Discriminante
Apunte (CCC,
(CCC, número,
número, descripción, importe) 19
© berzal@acm.org
Entidades débiles
Clave externa:
externa:
Una, haciendo referencia a la entidad fuerte de la que
depende existencialmente la entidad débil.
Apunte (CCC
(CCC,
, número,
número, descripción, importe)
Cuenta (CCC
(CCC,
, …)
20
© berzal@acm.org
Relaciones
Cada tipo de relación da lugar

a una tabla en la base de datos.
Atributos:
Los atributos de las claves primarias de las entidades
que intervienen en la relación más los atributos propios
de la relación.
21
© berzal@acm.org
Relaciones
Clave primaria:
Si la relación no tiene atributos propios:
Relación muchos a muchos:
muchos: La unión de las claves
de los conjuntos de entidades que intervienen.
Relación uno a muchos:
muchos: La clave correspondiente al
conjunto de entidades que participa en la relación con
cardinalidad “muchos”.
Relación uno a uno: uno: Una de las claves de las
entidades intervinientes en la relación (cualquiera).
22
© berzal@acm.org
Relaciones
Clave primaria:
Si hay atributos propios de la relación:
Los atributos correspondientes al tipo de relación,
a los que tal vez añadiremos algunos atributos propios
de la relación, dependiendo de su semántica.
Claves externas:
Una por cada una de las claves primarias de los
conjuntos de entidades que intervienen en la relación.
23
© berzal@acm.org
Relaciones
SOBRE LA RELACIÓN ENTRE ENTIDADES DÉBILES Y FUERTES…
Las relaciones entre entidades débiles y fuertes no hay

que pasarlas a tablas porque la relación se recoge como
parte de la clave primaria de la entidad débil (la parte
correspondiente a la clave primaria de la entidad fuerte
es una clave externa que apunta a la tabla derivada de
la entidad fuerte).
24
© berzal@acm.org
Relaciones n-
n-arias
Atributos: Los atributos de las claves primarias de los

conjuntos de entidades que intervienen en la relación
más los atributos propios de la relación.
Clave primaria: Estará formada por la unión de las claves

primarias correspondientes a todos aquellos conjuntos
de entidades que intervengan en la relación con
cardinalidad N (más, opcionalmente, alguno[s] de los
atributos propios de la relación).
Claves externas: Una por cada uno de los conjuntos de

entidades que intervienen en la relación. 25
© berzal@acm.org
Relaciones de generalización y especialización
Estrategia A: Una tabla por cada conjunto de entidades

Las particularizaciones heredan la clave primaria del
conjunto de entidades de nivel superior (la cual será, en
las tablas correspondientes a los subtipos, una clave
externa que referencia a la tabla derivada del supertipo).
supertipo).
Ejemplo:
Empleado (NRP, nombre, dirección… )
Profesor (NRP, departamento, categoría)
PAS (NRP, grupo, nivel)
26
© berzal@acm.org
Estrategia B: Una tabla por cada caso particular

Las particularizaciones heredan todos
los atributos de la entidad general.
Ejemplo:
Profesor (NRP, nombre, dirección… departamento, categoría)
PAS (NRP, nombre, dirección… grupo, nivel)
27
© berzal@acm.org
Estrategia C: Una tabla para toda la jerarquía
En este caso, se suele añadir una columna artificial

(discriminante) que indique el tipo de la entidad
representada por cada tupla de la tabla
(para permitir el mantenimiento de las
restricciones de integridad aplicables).
Ejemplo:
Empleado (NRP, nombre, dirección…
departamento, categoría, grupo, nivel)
28
© berzal@acm.org
Formalmente, la primera estrategia es la correcta.
Las otras dos estrategias sólo las emplearemos cuando,

por cuestiones de eficiencia, queramos reducir el número
de reuniones necesarias para realizar determinadas
consultas (motivo por el que la decisión de utilizar un
esquema u otro la pospondremos usualmente a la fase
de diseño físico de la base de datos).
29
© berzal@acm.org
Fusión de tablas
Se pueden combinar en una sola

todas las tablas que compartan su clave primaria.
p.ej.
Relaciones uno a muchos
Las tablas derivadas de las relaciones muchos a uno se

fusionan con las derivadas de las entidades que
participan en la relación con cardinalidad N.
30
© berzal@acm.org
Fusión de tablas
Relaciones uno a uno
Se pueden combinar las tablas derivadas de los dos conjuntos de entidades
en una sola o mantener tablas separadas:
Si la relación es obligatoria en ambos sentidos (las entidades involucradas

siempre aparecen conjuntamente), se pueden combinar las tablas derivadas
de los dos conjuntos de entidades, manteniendo como clave primaria la
clave primaria de uno de los conjuntos de entidades y como clave
alternativa la clave primaria del otro conjunto de entidades.
En cualquier otro caso, siempre se mantendrán tablas separadas para los

dos conjuntos de entidades, haciendo que la tabla de una de ellas absorba
la tabla que se derivaría de la relación. Si la participación de una de las
entidades es obligatoria, se suele elegir su tabla para fusionarla con
la tabla derivada de la relación.
31
© berzal@acm.org
Fusión de tablas
Relaciones de especialización y generalización
A la hora de representar jerarquías de especialización/generalización,

a veces fusionaremos las tablas correspondientes a distintos conjuntos de
entidades.
Se ha de llegar a un compromiso entre el coste de realizar consultas que

involucren reuniones de distintas tablas (cuando tenemos tablas
independientes) y el coste que supone desaprovechar espacio de
almacenamiento y tener que mantener manualmente determinadas
restricciones de integridad (cuando se combinan varias tablas en una sola).
32
© berzal@acm.org
Normalización
La normalización permite obtener un conjunto
adecuado de relaciones de tal forma que:
El esquema de la base de datos incluya el mínimo

número de atributos necesarios para dar soporte a los
requerimientos del sistema.
Resulte más fácil acceder a la base de datos y, sobre

todo, mantener los datos de la base de datos
(redundancia mínima:
mínima: salvo los atributos que
forman parte de claves externas, los demás se
representarán una única vez en la base de datos).
33
© berzal@acm.org
Normalización
En una base de datos normalizada:
Las actualizaciones se consiguen realizar con un

número mínimo de operaciones
(mejorando la eficiencia de la BD y reduciendo la
posibilidad de que aparezcan inconsistencias).
Se reduce al mínimo el espacio de almacenamiento

necesario para almacenar los datos de la BD
(reduciendo los costes de operación de la BD).
34
© berzal@acm.org
Normalización
Las relaciones que almacenan datos redundantes
presentan anomalías de actualización
(la inserción, eliminación o modificación de los datos
puede provocar la aparición de inconsistencias),
por lo que resulta adecuado descomponerlas:
Sin pérdidas (de forma que la relación original se
pueda reconstruir a partir de las relaciones en las que
la hayamos descompuesto).
Preservando las dependencias (para que podamos
mantener las restricciones de integridad de la relación
original introduciendo restricciones en las relaciones
provenientes de la descomposición de la relación
original). 35
© berzal@acm.org
Normalización
La descomposición sin pérdidas es indispensable,

la descomposición que preserva las dependencias
no siempre es posible.
A veces, el diseñador tiene que elegir entre

no normalizar, o bien,
perder dependencias.
36
© berzal@acm.org
Normalización
Dependencias funcionales
Describen relaciones entre los atributos de una relación:
B depende funcionalmente de A (A→

(A→B)
cuando cada valor de A en una relación R
aparece siempre asociado al mismo valor de B en R.
37
© berzal@acm.org
Normalización
Dependencias funcionales
Formalmente:
Sea un esquema R, sean α y β subconjuntos de

atributos, α⊆R y β⊆R. Decimos que α determina
funcionalmente a β, o que β depende funcionalmente
de α, o que α→β
α→β,, si y sólo si se verifica, que para toda
relación r instancia de ese esquema:
∀t1,t2∈r ; t1[α]=t2[α] ⇒ t1[β]=t2[β]
38
© berzal@acm.org
Normalización
Identificación de dependencias funcionales
La identificación de las dependencias funcionales

existentes es relativamente fácil si se conoce el
significado de cada atributo y las relaciones existentes
entre ellos.
Toda la información necesaria debería figurar en el

documento de especificación de requerimientos, bien
en la parte correspondiente a los requerimientos
funcionales o bien en el diccionario de datos que ha
de acompañar al modelo semántico de la base de
datos. 39
© berzal@acm.org
Normalización
La identificación de dependencias funcionales sirve para:
Especificar las restricciones de integridad

asociadas a una relación (claves candidatas:
clave primaria y claves alternativas).
Detectar posibles anomalías de actualización y

evitarlas, ya sea reorganizando el esquema de la base
de datos (recomendado) o tomando las medidas
oportunas al implementar las aplicaciones que
funcionen sobre la base de datos (trabajo adicional
que habrá que justificar razonadamente).
40
© berzal@acm.org
Normalización
El proceso de normalización
La normalización consiste en analizar el conjunto de

relaciones obtenido a partir del diagrama E/R teniendo
en cuenta las claves candidatas y las dependencias
existentes entre los atributos de cada relación.
La normalización se suele descomponer en una serie

de pasos, cada uno de los cuales corresponde a una
forma normal específica de propiedades conocidas.
41
© berzal@acm.org
Normalización: 1NF
1NF: Primera Forma Normal
Todos los atributos tienen dominios atómicos.
Para obtener una relación en 1NF:

Se eliminan los atributos compuestos y multivaluados
multivaluados..
42
© berzal@acm.org
Normalización: 2NF
2NF: Segunda Forma Normal
Todos los atributos no primos (los que no forman
parte de claves candidatas) dependen funcionalmente
de las claves candidatas de forma completa.
Una dependencia funcional es completa
cuando el determinante no se puede simplificar.

Si existe una dependencia funcional incompleta CK→β
(esto es, α→β con α∈CK,CK, siendo CK una clave
candidata de la relación), β se traslada a una nueva
relación junto con el determinante α y eliminamos β
43
de la relación original.
© berzal@acm.org
Normalización: 3NF
3NF: Tercera Forma Normal
Ningún atributo no primo depende transitivamente de
ninguna clave candidata.
Si A→
A→B y B→
B→C, entonces C depende
transitivamente de A a través de B (esto es, A→
A→C).
Esta dependencia transitiva puede causar
anomalías de actualización cuando B no es una
clave candidata de la relación.

Se eliminan las dependencias transitivas problemáticas
trasladándolas a una nueva relación. 44
© berzal@acm.org
Normalización: BCNF
La definición original de Codd para la 3NF no produce
diseños satisfactorios si hay varias claves candidatas y
éstas se solapan:
BCNF: Forma Normal de Boyce y Codd

Todo determinante es una clave candidata.
Toda relación en BCNF está en 3NF.
Diferencia entre 3NF y BCNF:

Dada una dependencia funcional A→ A→B, 3NF la permite
en una relación si B es un atributo primo y A no es
una clave candidata, mientras que BCNF requiere
45
que A sea una clave candidata.
candidata.
© berzal@acm.org
Normalización: 4NF
Otros tipos de dependencias, distintas a las
dependencias funcionales, también pueden introducir
redundancia en los datos almacenados en una relación:
4NF: Cuarta Forma Normal
Como consecuencia de la 1NF, pueden aparecer

dependencias multivaluadas que habrá que eliminar.
Para que una relación esté en 4NF, todo determinante

de una dependencia multivaluada debe ser una clave
candidata (y, por tanto, una dependencia funcional).
46
© berzal@acm.org
Normalización: 5NF
5NF: Quinta Forma Normal
Cuando una relación se descompone en más de dos

relaciones (porque no se pueda encontrar una
descomposición sin pérdidas en dos proyecciones),
se ha de cumplir un requisito para que la
descomposición sea sin pérdidas:
toda dependencia de reunión
debe ser consecuencia de las claves candidatas.
47
© berzal@acm.org
Normalización
Cuando se decida no normalizar tras haber encontrado

una dependencia entre los atributos de una relación,
se ha de justificar el porqué.
porqué.
p.ej.
CP → Municipio en una dirección, pero tal vez no
nos interese tener que mantener una tabla aparte con
todos los municipios de España y sus códigos postales.
48
© berzal@acm.org
Bibliografía
C.J. Date:
“Introducción a los sistemas de bases de datos”.
Prentice Hall, 2001 [7ª edición]. ISBN 968
968--444-
444-419
419--2.
Ramez A. Elmasri & Shamkant B. Navathe:
Navathe:
“Fundamentos de Sistemas de Bases de Datos”.
Addison--Wesley
Addison Wesley,, 2007 [5ª edición]. ISBN 84-
84-782
782--9085
9085--0.
Thomas M. Connolly & Carolyn E. Begg:
Begg:
“Sistemas de Bases de Datos”
Datos”
Addison--Wesley, 2005 [4ª edición].
Addison edición]. ISBN 84-
84-782-
782-9075
9075--3.
Henry F. Korth,
Korth, Abraham Silberschatz & S. Sudarshan:
Sudarshan:
“Fundamentos de Bases de Datos”.
McGraw--Hill, 2006 [5ª edición]. ISBN 84
McGraw 84--481-
481-4644
4644--1.
Olga Pons, Nicolás Marín, Juan Miguel Medina, Silvia Acid &
Mª Amparo Vila: “Introducción a las Bases de Datos: El modelo
49
relacional”. Paraninfo, 2005. ISBN 8497323963
Capítulo 5
Sistemas operativos
Autor: Santiago Felici

Fundamentos de Telemática
(Ingeniería Telemática)
1
Sistemas operativos
• Definición de Sistema Operativo
• Partes de un Sistema Operativo
• Servicios proporcionados: carga de
programas
• Arquitectura cliente-servidor
• Algunos conceptos
• Algunos Sistemas Operativos
2
¿QUÉ ES UN SISTEMA OPERATIVO?
Un Sistema Operativo (SO) es un software que proporciona un acceso
sencillo y seguro al soporte físico del ordenador (hardware), ocultando
al usuario detalles de la implementación particular y creando la ilusión
de existencia de recursos ilimitados (o abundantes). Máquina Virtual.
Otra definición, es el de un programa que actúa como intermediario entre el
usuario de la computadora y el hardware de la computadora.
Aplicaciones de usuario
Interfaz con la Máquina Virtual
Sistema Operativo
Interfaz con el Hardware
Hardware
3
Objetivos del Sistema Operativo
• Ejecutar programas del usuario y resolver los

problemas del usuario de manera fácil y sencilla.
• Hace que la computadora sea fácil y conveniente de
usar.
• Utiliza el hardware de la computadora de forma
eficiente.
Usuarios
Software de aplicaciones
Software del Sistema
Sistema Operativo
Hardware 4
Sistemas operativos
programas
5
PARTES DE UN SISTEMA OPERATIVO (1/3)
1. Manejo de Procesos (programa en ejecución: ejecutable, datos,

pila, contador, registros...) Tareas de las que el SO es responsable:
• Creación y terminación de procesos
• Asignación/actualización/liberación de recursos
• Suspensión y reinicio
• Sincronización entre procesos
• Comunicación entre procesos
• Solución de “trampas” y bloqueos
2. Manejo de Memoria. “Almacén” (array) de datos direccionables (y
por lo tanto accesibles) por la CPU y algunos dispositivos de E/S
(DMA). Tareas de las que el SO es responsable
• “inventario” del uso de memoria
• selección de procesos a cargar en memoria
• reserva/liberacion de memoria
• conversión de direcciones virtuales
• protección de memoria
6
3. Manejo de Ficheros. La función del SO es abstraer las propiedades

físicas del dispositivo de almacenamiento, proporcionando una unidad
lógica de almacenamiento. Tareas de las que el SO es responsable
• creación y eliminación de ficheros
• creación y eliminación de directorios
• proporcionar primitivas para la modificación de ficheros
• asignar/manejar permisos de acceso a ficheros
• realización de copias de seguridad
4. Manejo de Dispositivos de Entrada/Salida. La función del SO es
abstraer las propiedades físicas del dispositivo de Entrada/Salida, así
como coordinar el accesos a los mismos de múltiples procesos.
Tareas específicas:
• manejo de memoria para acceso directo, buffering y
acceso a memoria “cache”
• Proporcionar la interfaz entre el usuario y el dispositivo
• Proporcionar la interfaz entre el sistema y el dispositivo
7
5. Manejo de Redes. La función del SO es proporcionar una interfaz

de acceso a dispositivos remotos, conectados a través de líneas de
comunicación.
6. Intérprete de Comandos. Proporciona la interfaz entre el usuario

y el sistema operativo. (Shell). Varía en complejidad de sistema a
sistema, desde los más simples por línea de comando a complejos
sistemas gráficos basados en ventanas (WindowsNT, LINUX KDE,
Solaris CDE,...)
8
Herramientas de una interfaz gráfica
Iconos
Barra de herramientas
M
e
n
ú
Barra de Tareas Ventana
9
Interfaz de línea de comandos
Línea de comandos
10
Sistemas operativos
programas
11
SERVICIOS PROPORCIONADOS POR EL SO
1. Ejecución de Programas (programa en ejecución: ejecutable,

datos, pila, contador, registros...)
2. Operaciones de E/S
3. Manipulación de ficheros
4. Comunicaciones
5. Detección de errores
6. Asignación de recursos
7. Contabilidad
8. Protección
12
Carga y ejecución de Programas
v Multiusuario: Permite a dos o más usuarios ejecutar programas al
mismo tiempo. Algunos sistemas operativos permiten cientos o hasta
miles de usuarios concurrentes. Todos los Mainframes y
minicomputadores son multiusuario, a diferencia de la mayoría de los
computadores personales. Otro término para multiusuario es tiempo
compartido.
v Multiproceso: Soporta la ejecución de un programa en más de un CPU.
v Multimódulo: Permite que diferentes partes de un programa se
ejecuten concurrentemente.
v De tiempo real: Responde instantáneamente a las entradas. Los
sistemas operativos de propósito general, tales como DOS y UNIX no
son de tiempo real.
v Los términos multitarea y multiproceso suelen usarse indistintamente,
aunque el segundo implica que hay más de un CPU involucrado.
13
Sistemas operativos
programas
14
Modelo o arquitectura Cliente-Servidor
• Para que la comunicación entre dos aplicaciones en una red se
lleve a cabo, uno de los programas de aplicación debe estar
esperando por requerimientos por parte del programa
llamador, también llamado cliente.
• Este modelo, un programa espera pasivamente y el otro inicia
la comunicación. Se conoce como el paradigma de
interacción cliente servidor.
• La aplicación que espera pasivamente es llamada SERVIDOR
y la que inicia el contacto es llamada CLIENTE.
15
Características de los Clientes y Servidores
• Cliente:
– Es una aplicación normal que actúa como cliente cuando se
requiere acceso remoto.
– Es invocado directamente por el usuario y tiene una existencia
dada por la duración de la sesión del usuario.
– Corre localmente en el computador del usuario.
– Inicia activamente el contacto con un servidor.
– Ejemplo: cliente web o navegador, cliente de correo o agente de
usuario de correo, cliente DNS o resolvedor de nombres
• Servidor:
– Corre en un computador compartido.
– Espera pasivamente ser contactado por clientes remotos.
– Acepta ser contactado por clientes diversos clientes pero ofrece un
servicio bien definido.
– Ejemplo: servidor Web, servidor de correo, servidor de nombres,
...
16
Sistemas operativos
programas
17
PnP (Plug and Play): es una tecnología para soportar la
instalación de dispositivos, que pueden usarse
inmediatamente después de conectarlos físicamente, sin
procesos adicionales. La capacidad PnP viene integrada
en los sistemas operativos Mac OS, Windows 95 y
posteriores, pero para usarlo, el BIOS del computador así
como las tarjetas de expansión deben también tener
soporte para PnP.
Kernel: es el módulo central del sistema operativo. Es la
parte que se carga primero y permanece en memoria
principal. Debido a esto, es importante que el kernel sea
lo más pequeño posible, pero provea todos los servicios
esenciales que requieren las otras partes del sistema
operativo y las aplicaciones. Normalmente, el kernel es
responsable por la administración de la memoria, los
procesos, las tareas y los discos.
Driver: es un programa de bajo nivel encargado de atender a
un dispositivo físico, ejecutado como resultado de
invocación desde el sistema operativo 18
Paquetes de Software: son combinaciones de diferentes
programas que forman parte de una oferta comercial. Por
ejemplo, Microsoft Windows viene “empaquetado” con
muchas herramientas de software.
Archivo ejecutable (código objeto): Es un archivo cuyo
contenido tiene un formato que el computador puede
ejecutar directamente. A diferencia de los archivos o
códigos fuente, los ejecutables no pueden ser leídos por
las personas. Para transformar el código fuente
(programa con las instrucciones) en código ejecutable, se
necesita pasarlo a través de un programa compilador o
ensamblador..
Código Abierto : Es una certificación estándar generada por
la Open Source Initiative (OSI), indica que el código
abierto de un programa de computación está disponible
para el público en general, libre de cargo
19
Software Propietario : Se refiere a los programas que
pertenecen y son controlados por alguien. En la industria
de la computación, propietario es lo opuesto de abierto.
Un diseño o técnica propietaria es la que pertenece a
una empresa y esto implica que no se han divulgado
especificaciones, que podrían permitir que otras
compañías duplicaran el producto.
Licencia de software: Permiso que se le otorga a un
individuo o grupo, para el uso de una pieza de software.
Casi todas las aplicaciones trabajan bajo la modalidad de
darle una licencia al usuario, en lugar de venderle el
programa. Existe una amplia gama de tipos de licencias
de software. Algunas se basan en el número de
máquinas en las que se ejecutará el programa y otras en
el número de usuarios que lo pueden utilizar.
20
Piratería de software: Es la copia no autorizada de software.
Los usuarios incurren en este delito, cuando copian
programas y los distribuyen entre sus amigos y colegas,
sin costo alguno.
Software de dominio público: Se refiere a cualquier
programa que no está sujeto a Derechos de Autor. Este
software es gratuito y se puede usar sin restricciones.
Este término se usa a veces equivocadamente para
incluir freeware y shareware. El error radica en que estos
últimos sí están sujetos a Derechos de Autor.
Freeware: Software protegido por Derechos de Autor, pero
liberado por el autor para su uso gratuito. Aunque está
disponible sin costo, el autor retiene su derecho, lo que
significa que el usuario no puede hacer con ese software,
nada que no esté expresamente permitido por el autor.
Generalmente, se permite el uso pero no la venta.
21
Shareware : Software que se distribuye sobre las bases de
un sistema de ética. La mayoría del shareware se
distribuye libre de cargo, pero el autor generalmente
solicita que se pague una pequeña tarifa en caso de que
al usuario le guste el programa y lo use con regularidad.
Al cancelar esa tarifa, el usuario queda registrado con el
productor y puede recibir asistencia y actualizaciones. El
shareware está sujeto a Derechos de Autor. Esto
significa que no podemos vender un producto shareware
como nuestro, a menos que lo sea.
Courseware : Software diseñado para usarse en un
programa educativo.
Firmware : Es software (programas o datos) que se han
escrito en la memoria ROM. El firmware es una
combinación de hardware y software. Las memorias
ROM, PROM y EPROM que tienen datos o programas
grabados, son firmware
22
Sistemas operativos
programas
23
UNIX
v UNIX comienza en 1969, con Ken Thompson y Dennis Ritchie.

v Es el más antiguo de los S.O. para computadoras personales
v Es multiusuario, multiprocesador, multitarea, soporta redes
v En la mayoría de sus versiones, usa interfaz de línea de
comando. Sin embargo, actualmente la mayoría utilizan interfaz
gráfica
LINUX
v Es una versión de UNIX. Se puede obtener a un muy bajo costo o

incluso gratis
v Esta basado en 32 bits y tiene todas las capacidades de UNIX
vMultitarea, multiusuario, soporta redes, multiplataforma
v Se puede utilizar en cualquier tipo de computador, ya que demanda
pocos recursos (trabaja muy bien hasta en equipos 386) 24
DOS
v Creado en 1981 por IBM computers. DOS fue el S.O. adoptado
inicialmente por la mayoría de los computadores personales
v No soporta multitarea, ni multiprocesamiento
v Usa interfaz de línea de comandos
v Es relativamente fiable y estable
VENTAJAS DOS
vAmplio uso
vNúmero de Aplicaciones generadas bajo DOS.
vFuncionamiento sobre Hardware de bajo costo
vUtilizado en Windows 95, Windows 98 or Windows NT
DESVENTAJAS DOS
vAlmacenamiento Primario Limitado.
vTareas Únicas.
vInterfaz basado en caracteres. 25
OS/2 Warp
v Fue el primer S.O. realmente gráfico, para computadoras

personales que utilizan procesadores Intel
v Es multitarea, multiusuario y soporta redes
v Fue el primer S.O. para computadores personales, con
capacidades de reconocimiento de voz integradas
WINDOWS 3.x
v Esta familia incluye Windows 3.0, 3.1 y 3.11

v No es un Sistema Operativo, es un ambiente operativo que se
ejecuta sobre DOS, que es el verdadero S.O.
v Su aparición trajo la interfaz gráfica (GUI) al mundo de las
computadoras personales que utilizaban DOS 26
Windows NT
v Fue creado inicialmente para sustituir el DOS en los PC, pero

requería muchos recursos (memoria y disco) para la mayoría de los
equipos de la época.
v Es multitarea, multiprocesador, multiusuario y soporta redes
v Viene en dos versiones: Workstation y Server
v Es muy poderoso y resistente a fallos
Windows 95 y 98
v Windows 95 fue el primer S.O. de interfaz gráfica de 32 bits de

Microsoft
v Es multitarea, y puede ejecutar programas de DOS y Windows
3.x
v Windows 98 incluye capacidades para Internet, una interfaz
gráfica mejorada y mayor eficiencia en el manejo de archivos 27
Windows 2000
v Tiene todas las bondades gráficas de la versión 98, más todo el
poder, estabilidad, manejo de redes y archivos de Windows NT
v Existen varias versiones dependiendo de las características del
usuario
vMultitarea, multiusuario
Windows XP
vCombina las mejores características de sus sistemas operativos de

consumo con la eficacia, seguridad y fiabilidad del motor de Windows
2000 para crear un sistema operativo más seguro y fácil de utilizar.
vXP no es más que la abreviatura de 'eXPerience'
v Multitarea preferente, multiproceso simétrico, multiusuario,
multimodo, de tiempo real
vAcceso a internet
28
MAC/OS X
v Fue el primer Sistema Operativo WIMP (Windows, Icons, Menus,

Pointer).
v Ofreció a los usuarios la primera interfaz verdaderamente gráfica
v Todas las aplicaciones bajo MAC/OS tienen la misma apariencia (look
and feel)
vMultitarea preferente, multiproceso simétrico,multiusuario, multimodo,
de tiempo real
vAcceso a internet
vBasado en Unix, es estable
vCompatible con Windows
29
SISTEMAS OPERATIVOS:
Diseño e Implementación
SEGUNDA EDICION
ANDREW S. TANENBAUM
Vrije Universiteit
Amsterdam, Países Bajos
ALBERT S. WOODHULL
Hampshire College
Amherst, Massachusetts
INTRODUCCION
Sin su software, la computadora es básicamente un montón de metal inútil. Con su software, una
computadora puede almacenar, procesar y recuperar información; exhibir documentos multimedia; realizar
búsquedas en Internet; y realizar muchas otras actividades valiosas para justificar su existencia. El software
de computadora puede dividirse a grandes rasgos en dos tipos: programas de sistema, que controlan la
operación de la computadora misma, y programas de aplicación, que realizan las tareas reales que el
usuario desea. El programa de sistema más fundamental es el sistema operativo, que controla todos los
recursos de la computadora y establece la base sobre la que pueden escribirse los programas de aplicación.
Un sistema de computadora moderno consiste en uno o más procesadores, memoria principal (también
conocida como RAM, memoria de acceso aleatorio), discos, impresoras, interfaces de red y otros
dispositivos de entrada/salida. A todas luces, se trata de un sistema complejo. Escribir programas que sigan
la pista a todos estos componentes y los usen correctamente, ya no digamos óptimamente, es una tarea en
extremo difícil. Si todos los programadores tuvieran que ocuparse de cómo trabajan las unidades de disco, y
de las docenas de cosas que pueden fallar al leer un bloque de disco, es poco probable que pudieran
escribirse muchos programas.
Hace muchos años se hizo muy evidente que debía encontrarse alguna forma de proteger a los
programadores de la complejidad del hardware. La solución que ha evolucionado gradualmente consiste en
poner una capa de software encima del hardware solo, que se encargue de administrar todas las partes del
sistema y presente al usuario una interfaz o máquina virtual que sea más fácil de entender y programar.
Esta capa de software es el sistema operativo, y constituye el tema de este libro.
La situación se muestra en la Fig. 1-1. En la parte inferior está el hardware que, en muchos casos, también
se compone de dos o más capas. La capa más baja contiene los dispositivos físicos, que consisten en chips
de circuitos integrados, alambres, fuentes de potencia, tubos de rayos catódicos y otros aparatos físicos
similares. La forma en que éstos se construyen y sus principios de funcionamiento pertenecen al campo del
ingeniero electricista.
Figura 1-1. Un sistema de computadora consiste en hardware,

programas de sistema y programas de aplicación.
A continuación (en algunas máquinas) viene una capa de software primitivo que controla directamente estos
dispositivos y ofrece una interfaz más aseada a la siguiente capa. Este software, llamado microprograma,
suele estar almacenado en memoria de sólo lectura. En realidad es un intérprete, que obtiene las
instrucciones de lenguaje de máquina como ADD, MOVE y JUMP y las ejecuta en una serie de pasos
pequeños. Por ejemplo, para ejecutar una instrucción ADD (sumar), el microprograma debe determinar
dónde se encuentran los números que se van a sumar, obtenerlos, sumarlos y almacenar el resultado en
algún lugar. El conjunto de instrucciones que el microprograma interpreta define el lenguaje de máquina,
que no es realmente parte de la máquina física, aunque los fabricantes de computadoras siempre lo
describen en sus manuales como tal, de modo que muchas personas piensan en él como si fuera la
“máquina” real.
Algunas computadoras, llamadas RISC (computadoras con conjunto de instrucciones reducido), no
tienen un nivel de microprogramación. En estas máquinas, el hardware ejecuta las instrucciones de lenguaje
de máquina directamente. Por ejemplo, el Motorola 680x0 tiene un nivel de microprogramación, pero el IBM
PowerPC no.
El lenguaje de máquina por lo regular cuenta con entre 50 y 300 instrucciones, la mayor parte de ellas para
-1-
trasladar datos dentro de la máquina, realizar operaciones aritméticas y comparar valores. En esta capa, los
dispositivos de entrada/salida se controlan cargando valores registros de dispositivo especiales. Por
ejemplo, para un disco que ejecuta una lectura, sus registros se cargan con los valores de dirección del
disco, dirección de memoria principal, conteo de bytes y dirección de acceso (READ o WRITE). En la
práctica se requieren muchos parámetros más, y el estado devuelto por la unidad de disco después de una
operación es muy complejo. Además, la temporización desempeña un papel importante en la programación
de muchos dispositivos de E/S.
Una función importante del sistema operativo es ocultar toda esta complejidad y ofrecer al programador un
conjunto de instrucciones más cómodo con el que pueda trabajar. Por ejemplo, LEER BLOQUE DE
ARCHIVO es conceptualmente más sencillo que tener que preocuparse por los detalles de mover cabezas
de disco, esperar que se estabilicen, etcétera.
Encima del sistema operativo está el resto del software de sistema. Aquí encontramos el intérprete de
comandos (shell), sistemas de ventanas, compiladores, editores y otros programas similares
independientes de la aplicación. Es importante darse cuenta de que estos programas definitivamente no
forman parte del sistema operativo, a pesar de que casi siempre son provistos por el fabricante de la
computadora. Éste es un punto crucial, aunque sutil. El sistema operativo es la porción del software que se
ejecuta en modo kernel o modo supervisor, y está protegido por el hardware contra la intervención del
usuario (olvidándonos por el momento de algunos de los microprocesadores más viejos que no tienen
ninguna protección de hardware). Los compiladores y editores se ejecutan en modo de usuario. Si a un
usuario no le gusta un compilador en particular, él 1 está en libertad de escribir el suyo propio si lo desea; no
está en libertad de escribir su propio manejador de interrupciones del disco, que forma parte del sistema
operativo y normalmente está protegido por el hardware contra los intentos de los usuarios por modificarlo.
Por último, encima de los programas de sistema vienen los programas de aplicación. Los usuarios compran
o escriben estos programas para resolver sus problemas particulares, como procesamiento de textos, hojas
de cálculo, cálculos de ingeniería o juegos.
1.1 ¿QUÉ ES UN SISTEMA OPERATIVO?

La mayoría de los usuarios de computadora han tenido algo de experiencia con un sistema operativo, pero
no es fácil precisar con exactitud qué es un sistema operativo. Parte del problema consiste en que el
sistema operativo realiza dos funciones que básicamente no están relacionadas entre sí y, dependiendo de
a quién le preguntemos, por lo general se nos habla principalmente de una función o de la otra. Veamos
ahora las dos.
1.1.1 El sistema operativo como máquina extendida

Como ya dijimos, la arquitectura (conjunto de instrucciones, organización de memoria, E/S y estructura de
buses) de la mayor parte de las computadoras en el nivel de lenguaje de máquina es primitiva y difícil de
programar, sobre todo para entrada/salida. A fin de hacer más concreto este punto, veamos brevemente
cómo se realiza la E/S de disco flexible usando el chip controlador NEC PD765 (o su equivalente), utilizado
por la mayor parte de las computadoras personales. (En todo este libro usaremos indistintamente los
términos “disco flexible” y “disquete”.) El PD765 tiene 16 comandos, cada uno de los cuales se especifica
cargando entre 1 y 9 bytes en un registro de dispositivo. Estos comandos sirven para leer y escribir datos,
mover el brazo del disco y formatear pistas, así como para inicializar, detectar, restablecer y recalibrar el
controlador y las unidades de disco.
Los comandos más básicos son READ y WRITE, cada uno de los cuales requiere 13 parámetros
empacados en 9 bytes. Estos parámetros especifican cosas tales como la dirección del bloque de disco que
se va a leer, el número de sectores por pista, el modo de grabación empleado en el medio físico, el
espaciado de la brecha entre sectores y qué hacer con una marca de “dirección de datos eliminada”. Si
usted no entiende a qué nos referimos, no se preocupe; de eso se trata precisamente: es algo muy
esotérico. Cuando se completa la operación, el chip controlador devuelve 23 campos de estado y error
empacados en 7 bytes. Por si esto no fuera suficiente, el programador del disco flexible también debe tener
presente en todo momento si el motor está encendido o apagado. Si el motor está apagado, debe
encenderse (con un retardo de arranque largo) antes de que puedan leerse o escribirse datos. Empero, el
motor no puede dejarse encendido demasiado tiempo, pues el disco flexible se desgastaría. Por tanto, el
programador debe encontrar un equilibrio entre los retardos de arranque largos y el desgaste de los discos
flexibles (y la pérdida de los datos que contienen).
Sin entrar en los verdaderos detalles, debe quedar claro que el programador ordinario seguramente no
1 “Él” debe leerse “él o ella” a lo largo de todo el libro
-2-
quiere intervenir de manera demasiado íntima en la programación de los discos flexibles (o de los duros,
que son igualmente complejos, y muy distintos). En vez de ello, lo que el programador quiere es manejar
una abstracción sencilla, de alto nivel. En el caso de los discos, una abstracción típica sería que el disco
contiene una colección de archivos con nombre. Cada archivo puede abrirse para lectura o escritura, leerse
o escribirse, y por último cerrarse. Los detalles de si la grabación debe usar o no modulación de frecuencia
modificada y cuál es la situación actual del motor no deberán aparecer en la abstracción presentada al
usuario.
El programa que oculta la verdad acerca del hardware y presenta al programador una vista sencilla y bonita
de archivos con nombre que pueden leerse y escribirse es, por supuesto, el sistema operativo. Así como el
sistema operativo aísla al programador del hardware del disco y presenta una interfaz sencilla orientada a
archivos, también oculta muchos asuntos desagradables referentes a interrupciones, temporizadores,
administración de memoria y otras funciones de bajo nivel. En cada caso, la abstracción que el sistema
operativo ofrece es más sencilla y fácil de usar que el hardware subyacente.
En esta vista, la función del sistema operativo es presentar al usuario el equivalente de una máquina
extendida o máquina virtual que es más fácil de programar que el hardware subyacente. La forma en que
el sistema operativo logra este objetivo es una historia larga, que estudiaremos con detalle a lo largo del
libro.
1.1.2 El sistema operativo como administrador de recursos

El concepto del sistema operativo como algo cuya función primordial es ofrecer a los usuarios una Interfaz
cómoda es una visión descendente. Una visión ascendente alternativa postula que el sistema operativo está
ahí para administrar todos los componentes de un sistema complejo. Las computadoras modernas constan
de procesadores, memorias, temporizadores, discos, ratones, interfaces con redes, impresoras láser y una
gran variedad de otros dispositivos. En la visión alternativa, la misión del sistema operativo es asegurar un
reparto ordenado y controlado de los procesadores, memorias y dispositivos de E/S entre los diferentes
programas que compiten por ellos.
Imagine lo que sucedería si tres programas que se ejecutan en alguna computadora trataran de imprimir sus
salidas simultáneamente en la misma impresora. Las primeras líneas del listado podrían ser del programa 1,
las siguientes del programa 2, luego algunas del programa 3, y así sucesivamente. El resultado sería un
caos. El sistema operativo puede poner orden en el caos potencial almacenando temporalmente en el disco
todas las salidas destinadas para la impresora. Cuando un programa haya terminado, el sistema operativo
podrá copiar su salida del archivo de disco donde se almacenó a la impresora, mientras que el otro
programa puede continuar generando salidas, ajeno al hecho de que dichas salidas no están yendo
directamente a la impresora (todavía).
Cuando una computadora (o red) tiene múltiples usuarios, la necesidad de administrar y proteger la
memoria, los dispositivos de E/S y demás recursos es aún mayor, ya que de otra manera los usuarios
podrían interferirse. Además, es frecuente que los usuarios tengan que compartir no sólo hardware, sino
también información (archivos, bases de datos, etc.). En pocas palabras, esta es visión del sistema
operativo sostiene que su tarea primordial es seguir la pista de quién está usando cuál recurso, atender
solicitudes de recursos, contabilizar la utilización y mediar entre solicitudes en conflicto provenientes de
diferentes programas y usuarios.
1.2 HISTORIA DE LOS SISTEMAS OPERATIVOS

Los sistemas operativos han estado evolucionando durante muchos años. En las siguientes secciones
examinaremos brevemente este desarrollo. Dado que, históricamente, los sistemas operativos han estado
de manera muy estrecha vinculados con la arquitectura de las computadoras en las que se ejecutan,
estudiaremos las sucesivas generaciones de computadoras para ver qué clase de sistemas operativos
usaban. Esta correspondencia entre las generaciones de sistemas operativos y de computadoras es algo
burda, pero establece un poco de estructura que de otra forma sería inexistente.
La primera computadora digital verdadera fue diseñada por el matemático inglés Charles Babbage (1792-
1871). Aunque Babbage invirtió la mayor parte de su vida y su fortuna tratando de construir su “máquina
analítica”, nunca logró que funcionara correctamente porque era totalmente mecánica, y la tecnología de su
época no podía producir las ruedas, engranes y levas con la elevada precisión que él requería. Huelga decir
que la máquina analítica no contaba con un sistema operativo.
Como acotación histórica interesante, diremos que Babbage se dio cuenta de que necesitaría software para
su máquina analítica, así que contrató a una joven mujer, Ada Lovelace, hija del famoso poeta británico,
Lord Byron, como la primera programadora de la historia. El lenguaje de programación Ada® recibió su
-3-
nombre en honor a ella.
1.2.1 La primera generación (1945-55): Tubos de vacío y tableros de conmutación

Después del fracaso de los trabajos de Babbage, fueron pocos los avances que se lograron en la
construcción de computadoras digitales hasta la Segunda Guerra Mundial. A mediados de la década de
1940, Howard Aiken en Harvard, John von Neumann en el Institute for Advanced Study en Princeton, J.
Presper Eckert y William Mauchley en la University of Pennsylvania y Konrad Zuse en Alemania, entre otros,
lograron construir máquinas calculadoras usando tubos de vacío. Estas máquinas eran enormes, y
ocupaban cuartos enteros con decenas de miles de tubos de vacío, pero eran mucho más lentas que
incluso las computadoras personales más baratas de la actualidad.
En esos primeros días, un solo grupo de personas diseñaba, construía, programaba, operaba y mantenía a
cada máquina. Toda la programación se realizaba en lenguaje de máquina absoluto, a menudo alambrando
tableros de conmutación para controlar las funciones básicas de la máquina. No existían los lenguajes de
programación (ni siquiera los de ensamblador). Nadie había oído hablar de los sistemas operativos. La
forma de operación usual consistía en que el programador se anotaba para recibir un bloque de tiempo en la
hoja de reservaciones colgada en la pared, luego bajaba al cuarto de la máquina, insertaba su tablero de
conmutación en la computadora, y pasaba las siguientes horas con la esperanza de que ninguno de los
cerca de 20000 tubos de vacío se quemara durante la sesión. Prácticamente todos los problemas eran
cálculos numéricos directos, como la producción de tablas de senos y cosenos.
A principios de la década de 1950, la rutina había mejorado un poco con la introducción de las tarjetas
perforadas. Ahora era posible escribir programas en tarjetas e introducirlas para ser leídas, en lugar de usar
tableros de conmutación; por lo demás, el procedimiento era el mismo.
1.2.2 La segunda generación (1955-65): Transistores y sistemas por lote

La introducción del transistor a mediados de la década de 1950 alteró el panorama radicalmente. Las
computadoras se hicieron lo bastante confiables como para poderse fabricar y vender a clientes comerciales
con la expectativa de que seguirían funcionando el tiempo suficiente para realizar algo de trabajo útil. Por
primera vez, había una separación clara entre diseñadores, constructores, operadores, programadores y
personal de mantenimiento.
Estas máquinas se encerraban en cuartos de computadora con acondicionamiento de aire especial, con
equipos de operadores profesionales para operarlas. Sólo las grandes empresas, o las principales
dependencias del gobierno o universidades, podían solventar el costo de muchos millones de dólares. Para
ejecutar un trabajo (es decir, un programa o serie de programas), un programador escribía primero el
programa en papel (en FORTRAN o ensamblador) y luego lo perforaba en tarjetas. Después, llevaba el
grupo de tarjetas al cuarto de entrada y lo entregaba a uno de los operadores.
Cuando la computadora terminaba el trabajo que estaba ejecutando en ese momento, un operador acudía a
la impresora, separaba la salida impresa y la llevaba al cuarto de salida donde el programador podía
recogerla después. Luego, el operador tomaba uno de los grupos de tarjetas traídos del cuarto de entrada y
lo introducía en el lector. Si se requería el compilador de FORTRAN, el operador tenía que traerlo de un
archivero e introducirlo en el lector. Gran parte del tiempo de computadora se desperdiciaba mientras los
operadores iban de un lugar a otro, en el cuarto de la máquina.
Dado el alto costo del equipo, no es sorprendente que la gente pronto buscara formas de reducir el
desperdicio de tiempo. La solución que se adoptó generalmente fue el sistema por lotes. El principio de
este modo de operación consistía en juntar una serie de trabajos en el cuarto de entrada, leerlos y grabarlos
en una cinta magnética usando una computadora pequeña y (relativamente) económica, como una IBM
1401, que era muy buena para leer tarjetas, copiar cintas e imprimir salidas, pero no para realizar cálculos
numéricos. Otras máquinas, mucho más costosas, como la IBM 7094, se usaban para la computación
propiamente dicha. Esta situación se muestra en la Fig. 1-2.
-4-
Figura 1-2. Uno de los primeros sistemas por lotes. (a) Los programadores traen tarjetas a la 1401. (b)
La 1401 lee lotes de trabajos y los graba en cinta. (c) El operador lleva la cinta de entrada a la 7094. (d)
La 7094 realiza la computación. (e) El operador lleva la cinta de salida a la 1401. (f) La 1401 imprime la
salida.
Después de cerca de una hora de reunir un lote de trabajos, la cinta se rebobinaba y se llevaba al cuarto de
la máquina, donde se montaba en una unidad de cinta. El operador cargaba entonces un programa especial
(el antepasado del sistema operativo actual), que leía el primer trabajo de la cinta y lo ejecutaba. La salida
se escribía en una segunda cinta, en lugar de imprimirse. Cada vez que terminaba un trabajo, el sistema
operativo leía automáticamente el siguiente trabajo de la cinta y comenzaba a ejecutarlo. Una vez que
estaba listo todo el lote, el operador desmontaba las cintas de entrada y salida, montaba la cinta de entrada
del siguiente lote, y llevaba la cinta de salida a una 1401 para la impresión fuera de línea (o sea, no
conectada a la computadora principal).
La estructura de un trabajo de entrada típico se muestra en la Fig. 1-3. El trabajo comenzaba con una tarjeta
$JOB, que especificaba el tiempo de ejecución máximo en minutos, el número de cuenta al que se debía
cobrar el trabajo, y el nombre del programador. Luego venía una tarjeta $FORTRAN, que ordenaba al
sistema operativo leer el compilador de FORTRAN de la cinta de sistema. Esta tarjeta iba seguida del
programa por compilar y por una tarjeta $LOAD, que ordenaba al sistema operativo cargar el programa
objeto recién compilado. (Los programas compilados a menudo se escribían en cintas temporales y tenían
que cargarse explícitamente.) Luego venía la tarjeta $RUN, que ordenaba al sistema operativo ejecutar el
programa con los datos que le seguían. Por último, la tarjeta $END marcaba el final del trabajo. Estas
tarjetas de control primitivas eran los precursores de los lenguajes de control de trabajos e intérpretes de
comandos modernos.
Figura 1-3. Estructura de un trabajo FMS típico

Las computadoras grandes de la segunda generación se usaban primordialmente para cálculos científicos y
de ingeniería, como la resolución de ecuaciones diferenciales parciales. Estas máquinas generalmente se
programaban en FORTRAN y lenguaje ensamblador. Los sistemas operativos típicos eran FMS (el Fortran
Monitor System) e IBSYS, el sistema operativo de IBM para la 7094.
1.2.3 La tercera generación (1965-1980): Circuitos integrados y multiprogramación

A principios de la década de 1960, la mayoría de los fabricantes de computadoras tenían dos líneas de
producto distintas y totalmente incompatibles. Por un lado estaban las computadoras científicas a gran
escala, orientadas hacia las palabras, como la 7094, que se usaban para cálculos numéricos en ciencias e
-5-
ingeniería. Por el otro, estaban las computadoras comerciales orientadas hacia los caracteres, como la
1401, que los bancos y las compañías de seguros utilizaban ampliamente para ordenar e imprimir desde
cinta.
La creación y mantenimiento de dos líneas de producto totalmente distintas era una situación costosa para
los fabricantes. Además, muchos clientes de computadoras nuevas necesitaban inicialmente una máquina
pequeña que más adelante les resultaba insuficiente, de modo que querían una máquina más grande que
ejecutara todos sus viejos programas, pero más rápidamente.
IBM trató de resolver simultáneamente ambos problemas introduciendo la System/360. La 360 era una serie
de máquinas de software compatible que iban desde tamaños comparables a la 1401 hasta computadoras
mucho más potentes que la 7094. Las máquinas diferían sólo en el precio y el rendimiento (memoria
máxima, velocidad del procesador, número de dispositivos de E/S permitidos, etc.). Puesto que todas las
máquinas tenían la misma arquitectura y conjunto de instrucciones, los programas escritos para una
máquina podían ejecutarse en todas las demás, al menos en teoría. Además, la 360 estaba diseñada para
manejar computación tanto científica como comercial. Así, una sola familia de máquinas podía satisfacer las
necesidades de todos los clientes. En años subsecuentes IBM produjo sucesoras comparables a la línea
360, usando tecnología más moderna, conocidas como series 370, 4300, 3080 y 3090.
La 360 fue la primera línea importante de computadoras en usar (a pequeña escala) circuitos integrados
(IC), ofreciendo así una ventaja de precio/rendimiento considerable respecto a las máquinas de la segunda
generación, que se armaban con transistores individuales. Esta línea fue un éxito inmediato, y la idea de
una familia de computadoras compatibles pronto fue adoptada por todos los demás fabricantes importantes.
Los descendientes de estas máquinas todavía se emplean en uno que otro centro de cómputo en la
actualidad, pero su uso está en rápido declive.
La gran ventaja de la idea de “una familia” fue también su gran debilidad. La intención era que todo el
software, incluido el sistema operativo, funcionara en todos los modelos. El software tenía que funcionar en
sistemas pequeños, que en muchos casos simplemente sustituían a la 1401 para copiar tarjetas en cinta, y
en sistemas muy grandes, que con frecuencia sustituían a las 7094 para realizar pronósticos del tiempo y
otros trabajos de computación pesada. El software tenía que ser bueno en sistemas con pocos y con
muchos periféricos; tenía que funcionar en entornos comerciales y. científicos y, sobre todo, tenía que ser
eficiente para todos estos usos distintos.
Era imposible que IBM (o alguien más) pudiera escribir un programa que satisficiera todos esos requisitos
opuestos. El resultado fue un sistema operativo enorme, extraordinariamente complejo, tal vez dos o tres
órdenes de magnitud mayor que FMS. Este sistema consistía en millones de líneas de lenguaje
ensamblador escrito por miles de programadores, y contenía miles y miles de errores, requiriéndose un flujo
continuo de nuevas versiones en un intento por corregirlos. Cada versión nueva corregía algunos errores e
introducía otros nuevos, de modo que es probable que el número de errores se mantuviera constante con el
tiempo.
Uno de los diseñadores de OS/360, Fred Brooks, escribió después un ingenioso e incisivo libro (Brooks,
1975) describiendo sus experiencias con el OS/360. Aunque sería imposible resumir aquí ese libro, baste
con decir que la portada muestra una manada de bestias prehistóricas atascadas en un foso de brea. La
portada del libro de Silberschatz y Galvin (1994) es una alusión similar.
A pesar de su enorme tamaño y de sus problemas, OS/360 y los sistemas operativos de tercera generación
parecidos a él producidos por otros fabricantes de computadoras lograron satisfacer a sus clientes en un
grado razonable, y también popularizaron varias técnicas clave que no existían en los sistemas operativos
de la segunda generación. Tal vez la más importante de ellas haya sido la multiprogramación. En la 7094,
cuando el trabajo actual hacía una pausa para esperar que se completara una operación de cinta u otra
operación de E/S, la CPU simplemente permanecía ociosa hasta que la E/S terminaba. En los cálculos
científicos, con gran uso de CPU, la E/S es poco frecuente, así que el tiempo desperdiciado no es
significativo. En el procesamiento de datos comerciales, el tiempo de espera por E/S puede ser el 80 o 90%
del tiempo total, de modo que algo debía hacerse para evitar que la CPU estuviera ociosa tanto tiempo.
La solución a la que se llegó fue dividir la memoria en varias secciones, con un trabajo distinto en cada
partición, como se muestra en la Fig. 1-4. Mientras un trabajo estaba esperando que terminara su E/S, otro
podía estar usando la CPU. Si se podían tener en la memoria principal suficientes trabajos a la vez, la CPU
podía mantenerse ocupada casi todo el tiempo. Tener múltiples trabajos en la memoria a la vez requiere
hardware especial para proteger cada trabajo contra espionaje por parte de los demás, pero la 360 y otros
sistemas de tercera generación estaban equipados con este hardware.
-6-
Figura 1-4. Sistema de multiprogramación
con tres trabajos en la memoria
Otra característica importante presente en los sistemas operativos de la tercera generación era la capacidad
de leer trabajos de las tarjetas al disco tan pronto como se llevaban al cuarto de computadoras. Luego, cada
vez que un trabajo terminaba su ejecución, el sistema operativo podía cargar uno nuevo del disco en la
partición que había quedado vacía y ejecutarlo. Esta técnica se llama spooling (de “operación simultánea
de periféricos en línea”) y también se usaba para la salida. Con spooling, las 1401 ya no eran necesarias, y
desapareció una buena parte del transporte de cintas.
Aunque los sistemas operativos de la tercera generación se adaptaban bien a cálculos científicos extensos y
sesiones masivas de procesamiento de datos comerciales, seguían siendo básicamente sistemas por lotes.
Muchos programadores añoraban los días de la primera generación cuando tenían toda la máquina para
ellos solos durante unas cuantas horas, lo que les permitía depurar sus programas rápidamente. Con los
sistemas de la tercera generación, el tiempo entre la presentación de un trabajo y la obtención de las salidas
a menudo era de varias horas, y una sola coma mal colocada podía causar el fracaso de una compilación y
que el programador desperdiciara medio día.
Este deseo de respuesta rápida preparó el camino para el tiempo compartido, una variante de la
multiprogramación, en la que cada usuario tiene una terminal en línea. En un sistema de tiempo compartido,
si 20 usuarios ingresan en el sistema y 17 de ellos están pensando, hablando o tomando café, la CPU
puede asignarse por turno a los tres trabajos que requieren servicio. Puesto que las personas que están
depurando programas usualmente emiten comandos cortos (p. ej., compilar un procedimiento de cinco
páginas) en vez de largos (p. ej., ordenar un archivo de un millón de registros), la computadora puede
proporcionar servicio rápido interactivo a varios usuarios y tal vez también trabajar con trabajos de lote
grandes en segundo plano cuando la CPU está ociosa. Aunque el primer sistema serio de tiempo
compartido (CTSS) fue creado en el M.I.T. en una 7094 especialmente modificada (Corbato et al., 1962), el
tiempo compartido no se popularizó realmente hasta que se generalizó el uso del hardware de protección
necesario durante la tercera generación.
Después del éxito del sistema CTSS, MIT, Bell Labs y General Electric (por ese entonces un fabricante
importante de computadoras) decidieron emprender el desarrollo de un “servicio de computadora” una
máquina que diera apoyo a cientos de usuarios de tiempo compartido simultáneos. Su modelo fue el
sistema de distribución de electricidad: cuando usted necesita potencia eléctrica, simplemente enchufa una
clavija en la pared y, dentro de límites razonables, obtendrá tanta electricidad como necesite. Los
diseñadores de este sistema, llamado MULTICS (servicio de información y computación multiplexado),
contemplaban una enorme máquina que proporcionara potencia de cómputo a todos los usuarios de Boston.
La idea de que máquinas mucho más potentes que su GE-645 se vendieran como computadoras
personales por unos cuantos miles de dólares sólo 30 años después no era sino ciencia ficción en ese
entonces.
Para resumir un poco la historia, MULTICS introdujo muchas ideas seminales en la literatura de
computación, pero su construcción fue mucho más difícil de lo que nadie había imaginado. Bell Labs
abandonó el proyecto, y General Electric dejó el negocio de las computadoras por completo. Finalmente,
MULTICS funcionó lo bastante bien como para usarse en un entorno de producción de MIT y en docenas de
otros sitios, pero el concepto de un servicio de computadora se hizo obsoleto al desplomarse los precios de
las computadoras. No obstante, MULTICS tuvo una influencia enorme sobre los sistemas subsecuentes; se
le describe en (Corbato et al., 1972; Corbato y Vyssotsky, 1965; Daley y Dennis, 1968; Organick, 1972;
Saltzer, 1974).
Otro avance importante durante la tercera generación fue el crecimiento fenomenal de las
minicomputadoras, comenzando con la DEC PDP- 1 en 1961. La PDP-1 sólo tenía 4K de palabras de 18
bits, pero a $120 000 por máquina (menos del 5% del precio de una 7094), se vendieron como pan caliente.
Para ciertos tipos de trabajos no numéricos, la PDP-1 era casi tan rápida como la 7094, e hizo nacer una
-7-
industria totalmente nueva. A esta máquina pronto siguió una serie de otras PDP (todas incompatibles, a
diferencia de la familia IBM), culminando en la PDP-11.
Uno de los computólogos de BelI Labs que había trabajado en el proyecto MULTICS, Ken Thompson,
encontró subsecuentemente una pequeña minicomputadora PDP-7 que nadie estaba usando y se propuso
escribir una versión de MULTICS reducida al mínimo, para un solo usuario. Este trabajo posteriormente
evolucionó para convertirse en el sistema operativo UNIX®, que se popularizó en el mundo académico, las
dependencias del gobierno y muchas compañías.
La historia de UNIX se cuenta en otras obras (p. ej., Salus, 1994). Baste con decir que, dado que casi todo
mundo podía obtener el código fuente, diversas organizaciones desarrollaron sus propias versiones
(incompatibles), lo que condujo al caos. Con objeto de que fuera posible escribir programas susceptibles de
ejecución en cualquier sistema UNIX, el IEEE creó un estándar para UNIX, llamado Posix, que casi todas
las versiones actuales de UNIX reconocen. POSIX define una interfaz mínima de llamadas al sistema que
los sistemas UNIX deben reconocer. De hecho, algunos otros sistemas de programación ya reconocen la
interfaz POSIX.
1.2.4 La cuarta generación (1980-presente): Computadoras personales

Con la invención de los circuitos integrados a gran escala (LSI), chips que contienen miles de transistores
en un cm2 de silicio, nació la era de la computadora personal. En términos de arquitectura, las
computadoras personales no eran muy diferentes de las minicomputadoras de la clase PDP-11, pero en
términos de precio sí que eran diferentes. Si bien la minicomputadora hacía posible que un departamento de
una compañía o universidad tuviera su propia computadora, el chip microprocesador permitía que un solo
individuo tuviera su propia computadora personal. Las computadoras personales más potentes empleadas
por empresas, universidades e instalaciones del gobierno suelen llamarse estaciones de trabajo, pero en
realidad sólo son computadoras personales grandes. Por lo regular estas máquinas están interconectadas
mediante una red.
La amplia disponibilidad de la potencia de cómputo, sobre todo la potencia de cómputo altamente interactiva
casi siempre acompañada por excelentes gráficos, dio pie al crecimiento de una importante industria
productora de software para computadoras personales. Una buena parte de este software era amistoso
con el usuario, lo que significa que estaba dirigido a usuarios que no sólo no sabían nada de computación,
sino que además no tenían la mínima intención de aprender. Sin duda, esto representaba un cambio
drástico respecto al OS/360, cuyo lenguaje de control de trabajos, JCL, era tan arcano que llegaron a
escribirse libros enteros sobre él (p. ej., Cadow, 1970).
Dos sistemas operativos dominaron inicialmente el campo de las computadoras personales y las estaciones
de trabajo: MS-DOS de Microsoft y UNIX. MS-DOS se usaba ampliamente en la IBM PC y otras máquinas
basadas en la CPU Intel 8088 y sus sucesoras, la 80286, 80386 y 80486 (que en adelante llamaremos la
286, 386 y 486, respectivamente) y más tarde la Pentium y Pentium Pro. Aunque la versión inicial de MS-
DOS era relativamente primitiva, versiones subsecuentes han incluido características más avanzadas,
muchas de ellas tomadas de UNIX. El sucesor de Microsoft para MS-DOS, WINDOWS, originalmente se
ejecutaba encima de MS-DOS (es decir, era más un shell que un verdadero sistema operativo), pero a partir
de 1995 se produjo una versión autosuficiente de WINDOWS, WINDOWS 95®, de modo que ya no se
necesita MS-DOS para apoyarlo. Otro sistema operativo de Microsoft es WINDOWS NT, que es compatible
con WINDOWS 95 en cierto nivel, pero internamente se reescribió desde cero.
El otro competidor importante es UNIX, que domina en las estaciones de trabajo y otras computadoras del
extremo alto, como los servidores de red. UNIX es popular sobre todo en máquinas basadas en chips RISC
de alto rendimiento. Estas máquinas por lo regular tienen la potencia de cómputo de una minicomputadora,
a pesar de estar dedicadas a un solo usuario, por lo que resulta lógico que estén equipadas con un sistema
operativo diseñado originalmente para minicomputadoras, a saber, UNIX.
Una tendencia interesante que apareció a mediados de la década de 1980 fue el crecimiento de redes de
computadoras personales en las que se ejecutan sistemas operativos de red o sistemas operativos
distribuidos (Tanenbaum, 1995). En un sistema operativo de red los usuarios están conscientes de la
existencia de múltiples computadoras y pueden ingresar en máquinas remotas y copiar archivos de una
máquina a otra. Cada máquina ejecuta su propio sistema operativo local y tiene su propio usuario o usuarios
locales.
Los sistemas operativos de red no son fundamentalmente distintos de aquellos para un solo procesador.
Obviamente, estos sistemas necesitan un controlador de la interfaz con la red y software de bajo nivel para
operarlo, así como programas para realizar inicios de sesión remotos y acceso a archivos remotos, pero
estas adiciones no alteran la estructura esencial del sistema operativo.
-8-
Un sistema operativo distribuido, en cambio, presenta el mismo aspecto a los usuarios que un sistema
tradicional de un solo procesador, aunque en realidad se compone de múltiples procesadores. Los usuarios
no deben enterarse de en dónde se están ejecutando sus programas o almacenando sus archivos; de todo
eso debe encargarse el sistema operativo automática y eficientemente.
Los verdaderos sistemas operativos distribuidos requieren más que la adición de un poco más de código a
un sistema operativo uniprocesador, porque los sistemas distribuidos y centralizados difieren en aspectos
cruciales. Los sistemas distribuidos, por ejemplo, a menudo permiten a las aplicaciones ejecutarse en varios
procesadores al mismo tiempo, por lo que requieren algoritmos de planificación de más complejos a fin de
optimizar el grado de paralelismo.
En muchos casos, los retardos de comunicación dentro de la red implican que éstos (y otros) algoritmos
deban ejecutarse con información incompleta, caduca o incluso incorrecta. Esta situación difiere
radicalmente un sistema de un solo procesador en el que el sistema operativo tiene toda la información
sobré el estado del sistema.
1.2.5 Historia de MINIX

Cuando UNIX era joven (Versión 6), era fácil conseguir el código fuente, bajo licencia de AT&T, y se
estudiaba mucho. John Lions, de la University of New South Wales en Australia, incluso escribió un librito
que describía su operación, línea por línea (Lions, 1996). Este librito se usó (con permiso de AT&T) como
texto en muchos cursos universitarios de sistemas operativos.
Cuando AT&T liberó la Versión 7, comenzó a darse cuenta de que UNIX era un producto comercial valioso,
así que entregó la Versión 7 junto con una licencia que prohibía el estudio del código fuente en cursos, a fin
de evitar poner en peligro su situación de secreto comercial. Muchas universidades simplemente
abandonaron el estudio de UNIX e impartieron sólo teoría.
Desafortunadamente, cuando sólo se enseña teoría el estudiante adquiere una visión desbalanceada de
cómo se ve realmente un sistema operativo. Los temas teóricos que suelen cubrirse con gran detalle en
cursos y libros sobre sistemas operativos, como los algoritmos de planificación, en la práctica realmente no
son tan importantes. Los temas que en verdad son relevantes, como E/S y sistemas de archivos,
generalmente se descuidan porque no hay mucha teoría al respecto.
A fin de remediar esta situación, uno de los autores de este libro (Tanenbaum) decidió escribir un nuevo
sistema operativo desde cero que fuera compatible con UNIX desde el punto de vista del usuario, pero
completamente distinto en su interior. Al no utilizar ni una sola línea del código de AT&T, este sistema evita
las restricciones de la licencia, así que puede usarse en clase o para estudio individual. De esta forma, los
lectores pueden disectar un sistema operativo real para ver qué hay dentro, tal como los estudiantes de
biología disectan ranas. El nombre MINIX significa mini-UNIX porque es lo suficientemente pequeño como
para poderlo entender a pesar de no ser un gurú.
Además de la ventaja de eliminar los problemas legales, MINIX tiene otra ventaja respecto a UNIX: se
escribió una década después de UNIX y tiene una estructura más modular. El sistema de archivos de
MINIX, por ejemplo, no forma parte del sistema operativo, sino que se ejecuta como programa de usuario.
Otra diferencia es que UNIX se diseñó de modo que fuera eficiente; MINIX se diseñó pensando en que fuera
comprensible (hasta donde puede ser comprensible cualquier programa que ocupa cientos de páginas). El
código de MINIX, por ejemplo, incluye miles de comentarios.
MINIX se diseñó originalmente de modo que fuera compatible con UNIX Versión 7 (V7). Se usó como
modelo esta versión a causa de su sencillez y elegancia. A veces se dice que la Versión 7 no sólo
representó una mejora respecto a sus predecesores, sino también respecto a todos sus sucesores. Con la
llegada de POSIX, MINIX comenzó a evolucionar hacia el nuevo estándar, al tiempo que mantenía la
compatibilidad hacia atrás con los programas existentes. Este tipo de evolución es común en la industria de
las computadoras, pues ningún proveedor desea introducir un sistema nuevo que ninguno de sus clientes
existentes podrá usar sin grandes convulsiones. La versión de MINIX que se describe en este libro se basa
en el estándar POSIX (a diferencia de la versión descrita en la primera edición, que se basaba en V7).
Al igual que UNIX, MINIX se escribió en el lenguaje de programación C y se pretendía que fuera fácil
transportarlo a diversas computadoras. La implementación inicial fue para la IBM PC, porque esta
computadora se usa ampliamente. Subsecuentemente se llevó a las computadoras Atari, Amiga, Macintosh
y SPARC. Acorde con la filosofía de que “lo pequeño es hermoso”, MINIX originalmente no requería siquiera
un disco duro para ejecutarse, lo que lo ponía al alcance del presupuesto de muchos estudiantes (aunque
puede parecer asombroso ahora, a mediados de la década de 1980 cuando MINIX vio por primera vez la
luz, los discos duros aún eran una novedad de precio elevado). Al crecer MINIX en funcionalidad y tamaño,
-9-
llegó al punto en que se hizo necesario un disco duro, pero en concordancia con la filosofía de MINIX basta
con una partición de 30 megabytes. En contraste, algunos sistemas UNIX comerciales ahora recomiendan
una partición de disco de 200 MB como mínimo indispensable.
Para el usuario medio sentado ante una IBM PC, ejecutar MINIX es similar a ejecutar UNIX. Muchos de los
programas básicos, como cat, grep, is, make y el shell están presentes y desempeñan las mismas funciones
que sus contrapartes de UNIX. Al igual que el sistema operativo mismo, todos estos programas de utilería
fueron reescritos completamente desde cero por el autor, sus estudiantes y algunas otras personas
dedicadas.
En todo este libro se usará MINIX como ejemplo. No obstante, casi todo lo que se diga acerca de MINIX, a
menos que se refiera al código en sí, también aplica a UNIX. Muchos de estos comentarios también aplican
a otros sistemas. Esto debe tenerse siempre presente al leer el libro.
Como acotación, es posible que unas cuantas palabras acerca de LINUX y su relación con MINIX sean de
interés para algunos lectores. Poco después de liberarse MINIX, se formó un grupo de noticias de USENET
para hablar de él. En pocas semanas, este grupo tenía 40000 suscriptores, la mayor parte de los cuales
quería agregar enormes cantidades de nuevas capacidades a MINIX a fin de hacerlo más grande y mejor
(bueno, al menos más grande). Cada día, varios cientos de ellos ofrecían sugerencias, ideas y fragmentos
de código. El autor de MINIX resistió con éxito esta arremetida durante varios años, a fin de mantener a
MINIX lo suficientemente pequeño y aseado como para que los estudiantes lo entendieran. Gradualmente,
la gente comenzó a convencerse de que su posición era inamovible. Finalmente, un estudiante finlandés,
Linus Torvalds, decidió escribir un clon de MINIX que pretendía ser un sistema de producción con
abundantes capacidades, más que una herramienta educativa. Así fue como nació LINUX.
1.3 CONCEPTOS DE SISTEMAS OPERATIVOS

La interfaz entre el sistema operativo y los programas de usuario está definida por el conjunto de
“operaciones extendidas” que el sistema operativo ofrece. Estas instrucciones se han llamado
tradicionalmente llamadas al sistema, aunque ahora pueden implementarse de varias formas. Para
entender realmente lo que los sistemas operativos hacen, debemos examinar con detenimiento esta
interfaz. Las llamadas disponibles en la interfaz varían de un sistema operativo a otro (aunque los conceptos
subyacentes tienden a ser similares).
Por tanto, nos vemos obligados a escoger entre (1) generalidades vagas (“los sistemas operativos tienen
llamadas al sistema para leer archivos”) y (2) algún sistema específico (“MINIX tiene una llamada al sistema
READ) con tres parámetros: uno para especificar el archivo, uno para indicar dónde deben colocarse los
datos y uno para indicar cuántos bytes deben leerse”)
Hemos escogido el segundo enfoque. Esto implica más trabajo, pero nos permite entender mejor qué es
realmente lo que hacen los sistemas operativos. En la sección 1.4 examinaremos de cerca las llamadas al
sistema presentes tanto en UNIX como en MINIX. Por sencillez, sólo nos referiremos a MINIX, pero las
llamadas al sistema UNIX correspondientes se basan en POSIX en la mayor parte de los casos. Sin
embargo, antes de estudiar las llamadas al sistema reales, vale la pena presentar un panorama general de
MINIX, a fin de tener una idea global de qué es lo que hace un sistema operativo. Este panorama aplica
igualmente bien a UNIX.
Las llamadas al sistema de MINIX pertenecen a dos categorías amplias: las que se ocupan de los procesos
y las que se ocupan del sistema de archivos. A continuación las examinaremos por turno.
1.3.1 Procesos
Un concepto clave en MINIX, y en todos los sistemas operativos, es el proceso. Un proceso es
básicamente un programa en ejecución. Cada proceso tiene asociado un espacio de direcciones, una lista
de posiciones de memoria desde algún mínimo (usualmente 0) hasta algún máximo, que el proceso puede
leer y escribir. El espacio de direcciones contiene el programa ejecutable, los datos del programa, y su pila.
A cada proceso también se asocia un conjunto de registros, que incluyen el contador del programa, el
apuntador de la pila y otros registros de hardware, así como toda la demás información necesaria para
ejecutar el programa.
Volveremos al concepto de proceso con mucho mayor detalle en el capítulo 2, pero por ahora la forma más
fácil de adquirir una idea intuitiva de lo que es un proceso es pensar en los sistemas de tiempo compartido.
Periódicamente, el sistema operativo decide dejar de ejecutar un proceso y comenzar a ejecutar otro, por
ejemplo, porque el primero ya tuvo más tiempo de CPU del que le tocaba durante el segundo anterior.
Cuando un proceso se suspende temporalmente de esta manera, debe reiniciarse después en el mismo
-10-
estado exactamente en que estaba en el momento en que se le detuvo. Esto implica que toda la información
acerca del proceso se debe guardar explícitamente en algún lugar durante la suspensión. Por ejemplo, es
posible que el proceso tenga varios archivos abiertos para lectura. Cada uno de estos archivos tiene
asociado un apuntador que indica la posición actual (es decir, el número del byte o registro que se leerá a
continuación). Cuando un proceso se suspende temporalmente, es necesario guardar todos estos
apuntadores para que una llamada READ ejecutada después de reiniciarse el proceso lea los datos
correctos. En muchos sistemas operativos, toda la información acerca de cada proceso, aparte del
contenido de su propio espacio de direcciones, se almacena en una tabla del sistema operativo llamada
tabla de procesos, que es un arreglo (o lista enlazada) de estructuras, una para cada proceso existente en
ese momento.
Así, un proceso (suspendido) consiste en su espacio de direcciones, por lo regular llamado imagen de
núcleo (recordando las memorias de núcleos magnéticos que se usaban en el pasado), y su entrada en la
tabla de procesos, que contiene sus registros, entre otras cosas.
Las llamadas al sistema de administración para procesos clave son las que se ocupan de la creación y
terminación de procesos. Consideremos un ejemplo representativo. Un proceso llamado intérprete de
comandos o shell lee comandos de una terminal. El usuario acaba de teclear un comando solicitando la
compilación de un programa. El shell debe crear ahora un proceso nuevo que ejecute el compilador. Cuando
ese proceso haya terminado la compilación, ejecutará una llamada al sistema para terminarse a sí mismo.
Si un proceso puede crear uno o más procesos distintos (denominados procesos hijos) y éstos a su vez
pueden crear procesos hijos, pronto llegamos a la estructura de árbol de procesos de la Fig. 1-5. Los
procesos relacionados que están cooperando para realizar alguna tarea a menudo necesitan comunicarse
entre sí y sincronizar sus actividades. Esta comunicación se llama comunicación entre procesos, y se
estudiará con detalle en el capítulo 2.
Figura 1-5. Un árbol de procesos.

El proceso A creó dos procesos
hijos, B y C. El proceso B creó tres
procesos hijos, D, E y F.
Hay otras llamadas al sistema relacionadas con procesos que solicitan más memoria (o liberan memoria no
utilizada), esperan que un proceso hijo termine, y superponen otro programa al suyo.
Ocasionalmente, se hace necesario comunicar información a un proceso en ejecución que no está
simplemente esperando recibirla. Por ejemplo, un proceso que se comunica con otro proceso en una
computadora distinta lo hace enviando mensajes por una red. A fin de prevenir la posibilidad de que un
mensaje o su respuesta se pierda, el remitente puede solicitar que su propio sistema operativo le notifique
cuando haya transcurrido cierto número de segundos, a fin de poder retransmitir el mensaje si todavía no ha
llegado un acuse de recibo. Después de establecer este temporizador, el programa puede seguir realizando
otros trabajos.
Cuando ha transcurrido el número de segundos que se especificó, el sistema operativo envía una señal al
proceso. La señal hace que el proceso suspenda temporalmente lo que estaba haciendo, guarde sus
registros en la pila, y comience a ejecutar un procedimiento especial de manejo de señales, por ejemplo,
para retransmitir un mensaje que al parecer se perdió. Una vez que el manejador de señales termina, el
proceso en ejecución se reinicia en el estado en que estaba justo antes de la señal. Las señales son el
análogo en software de las interrupciones de hardware, y pueden ser generadas por diversas causas
además de la expiración de temporizadores. Muchas trampas detectadas por el hardware, como la
ejecución de una instrucción no permitida o el empleo de una dirección no válida, también se convierten en
señales que se envían al proceso culpable.
El administrador del sistema asigna un uid (identificador de usuario) a cada persona autorizada para usar
MINIX. Cada proceso iniciado en MINIX tiene el uid de la persona que lo inició. Un proceso hijo tiene el
mismo uid que su padre. Un uid, llamado superusuario, tiene facultades especiales, y puede violar muchas
-11-
de las reglas de protección. En las instalaciones grandes, sólo el administrador del sistema conoce la
contraseña necesaria para convertirse en superusuario, pero muchos de los usuarios ordinarios (sobre todo
estudiantes) dedican un esfuerzo considerable a tratar de encontrar defectos en el sistema que les permitan
convertirse en superusuarios sin contar con la contraseña.
1.3.2 Archivos
La otra categoría amplia de llamadas al sistema se relaciona con el sistema de archivos. Como ya se
apuntó, una función importante del sistema operativo es ocultar las peculiaridades de los discos y otros
dispositivos de E/S y presentar al programador un modelo abstracto, aseado y bonito, de archivos
independientes del dispositivo. Es obvio que se necesitan llamadas al sistema para crear, eliminar, leer y
escribir archivos. Antes de que un archivo pueda leerse, debe abrirse, y después de leerse debe cerrarse,
así que también se incluyen llamadas para hacer estas cosas.
A fin de contar con un lugar para guardar los archivos, MINIX tiene el concepto de directorio como
mecanismo para agrupar los archivos. Un estudiante, por ejemplo, podría tener un directorio para cada
curso en el que está inscrito (donde guardaría los programas necesarios para ese curso), otro directorio
para su correo electrónico, y otro más para su página base de la World Wide Web. Por tanto, se necesitan
llamadas al sistema para crear y eliminar directorios. También se incluyen llamadas para poner un archivo
existente en un directorio, y para quitar un archivo de un directorio. Las entradas de directorio pueden ser
archivos u otros directorios. Este modelo también da pie a una jerarquía -el sistema de archivos- como se
muestra en la Fig. 1-6.
Figura 1-6. Sistema de archivos para un departamento universitario

Las jerarquías de procesos y de archivos están organizadas como árboles, pero hasta ahí llega la similitud.
Las jerarquías de procesos no suelen ser muy profundas (casi nunca tienen más de tres niveles), en tanto
que las de archivos comúnmente tienen cuatro, cinco o incluso más niveles de profundidad. Las jerarquías
de procesos por lo regular tienen una vida corta, generalmente de unos cuantos minutos como máximo, en
tanto que la jerarquía de directorios podría existir durante años. La propiedad y protección también es
diferente para los procesos y para los archivos. Típicamente, sólo un proceso padre puede controlar o
incluso acceder a un proceso hijo, pero casi siempre existen mecanismos para permitir que los archivos y
directorios sean leídos por un grupo más amplio que sólo el propietario.
Cada archivo dentro de la jerarquía de directorios se puede especificar dando su nombre de ruta a partir
del tope de la jerarquía de directorios, el directorio raíz. Semejantes nombres de ruta absolutos consisten
en la lista de directorios por los que se debe pasar partiendo del directorio raíz para llegar al archivo,
separando los componentes con diagonales. En la Fig. 1-6, la ruta del archivo CS101 es /Profesorado/Prof.
Ruiz/Cursos/CS101. La diagonal (/) inicial indica que la ruta es absoluta, es decir, que comienza en el
directorio raíz.
-12-
En todo momento, cada proceso tiene un directorio de trabajo actual, en el cual se buscan los archivos
cuyos nombres de ruta no comienzan con una diagonal. Por ejemplo, en la Fig. 1-6, si /Profesorado/Prof.
Ruiz fuera el directorio de trabajo, el empleo del nombre de ruta Cursos/ CS101 se referiría al mismo archivo
que el nombre de ruta absoluta dado en el párrafo anterior. Los procesos pueden cambiar de directorio de
trabajo emitiendo una llamada al sistema que especifique el nuevo directorio de trabajo.
Los archivos y directorios en MINIX se protegen asignando a cada uno un código de protección binario de 9
bits. El código de protección consiste en tres campos de 3 bits, uno para el propietario, uno para otros
miembros del grupo del propietario (el administrador del sistema divide a los usuarios en grupos) y uno para
toda la demás gente. Cada campo tiene un bit para acceso de lectura, uno para acceso de escritura y uno
para acceso de ejecución. Estos tres bits se conocen como bits rwx. Por ejemplo, el código de protección
rwxr-x--x significa que el propietario puede leer, escribir o ejecutar el archivo, otros miembros del grupo
pueden leer o ejecutar (pero no escribir) el archivo, y el resto de la gente puede ejecutar (pero no leer ni
escribir) el archivo. En el caso de un directorio, x indica permiso de búsqueda. Un guión significa que el
permiso correspondiente está ausente.
Antes de poder leer o escribir un archivo, es preciso abrirlo, y en ese momento se verifican los permisos. Si
está permitido el acceso, el sistema devuelve un entero pequeño llamado descriptor de archivo que se
usará en operaciones subsecuentes. Si el acceso está prohibido, se devuelve un código de error.
Otro concepto importante en MINIX es el de sistema de archivos montado. Casi todas las computadoras
personales tienen una o más unidades de disco flexible en las que pueden insertarse y de las que pueden
retirarse disquetes. A fin de contar con una forma congruente de manejar estos medios removibles (y
también los CD-ROM, que también son removibles), MINIX permite conectar el sistema de archivos del
disco flexible al árbol principal. Considere la situación de la Fig. 1-7(a). Antes de la llamada MOUNT, el disco
en RAM (disco simulado en la memoria principal) contiene el sistema de archivos raíz, o primario, y la
unidad 0 contiene un disquete que contiene otro sistema de archivos.
Figura 1-7. (a) Antes de montarse, los archivos de la unidad 0 no están accesibles. (b) Después de
montarse, esos archivos forman parte de la jerarquía de archivos.
Sin embargo, no podemos usar el sistema de archivos de la unidad 0, porque no hay forma de especificar
nombres de ruta en él. MINIX no permite anteponer a los nombres de ruta un nombre o número de unidad;
ésa sería precisamente la clase de dependencia del dispositivo que los sistemas operativos deben eliminar.
En vez de ello, la llamada al sistema MOUNT permite conectar el sistema de archivos de la unidad 0 al
sistema de archivo raíz en cualquier lugar en el que el programa quiera que esté. En la Fig. 1-7(b) el sistema
de archivos de la unidad 0 se montó en el directorio b, permitiendo así el acceso a los archivos /b/x y /b/y. Si
el directorio b hubiera contenido archivos, éstos no habrían estado accesibles mientras estuviera montada la
unidad 0, ya que /b se habría referido al directorio raíz de la unidad 0. (No poder acceder a esos archivos no
es tan grave como parece a primera vista: los sistemas de archivos casi siempre se montan en directorios
vacíos.)
Otro concepto importante en MINIX es el archivo especial. Los archivos especiales sirven para hacer que
los dispositivos de E/S semejen archivos. Así, esos dispositivos pueden leerse y escribirse usando las
mismas llamadas al sistema que se usan para leer y escribir archivos. Existen dos tipos de archivos
especiales: archivos especiales por bloques y archivos especiales por caracteres. Los primeros se
usan para modelar dispositivos que consisten en una colección de bloques directamente direccionables,
como los discos. Al abrir un archivo especial por bloques y leer, digamos, el bloque 4, un programa puede
acceder directamente al bloque 4 del dispositivo, pasando por alto la estructura del sistema de archivos que
contiene. De forma similar, los archivos especiales por caracteres se usan para modelar impresoras,
módems y otros dispositivos que aceptan o producen flujos de caracteres.
-13-
La última característica que mencionaremos en esta reseña general se relaciona tanto con los procesos
como con los archivos: los conductos. El conducto (o tubería) es una especie de seudoarchivo que puede
servir para conectar dos procesos, como se muestra en la Fig. 1-8. Cuando el proceso A desea enviar datos
al proceso B, escribe en el conducto como si fuera un archivo de salida. El proceso B puede leer los datos
leyendo del conducto como si fuera un archivo de entrada. Así, la comunicación entre procesos en MINIX se
parece mucho a las lecturas y escrituras de archivos normales. Es más, la única forma en que un proceso
puede descubrir que el archivo de salida en el que está escribiendo no es realmente un archivo, sino un
conducto, es emitiendo una llamada especial al sistema.
Figura 1-8. Dos procesos conectados

por un conducto
1.3.3 El shell
El sistema operativo MINIX es el código que ejecuta las llamadas al sistema. Los editores, compiladores,
ensambladores, vinculadores e intérpretes de comandos definitivamente no forman parte del sistema
operativo, aunque son importantes y útiles. A riesgo de confundir un poco las cosas, en esta sección
examinaremos brevemente el intérprete de comandos de MINIX, llamado shell, que, si bien no es parte del
sistema operativo, utiliza intensivamente muchas de las características del sistema operativo y, por tanto, es
un buen ejemplo de la forma en que pueden usarse las llamadas al sistema. El shell también es la interfaz
primaria entre un usuario sentado ante su terminal y el sistema operativo.
Cuando un usuario ingresa en el sistema, se inicia un shell. El shell tiene la terminal como entrada estándar
y salida estándar, y lo primero que hace es exhibir la indicación (prompt), un carácter como un signo de
dólar, que le indica al usuario que el shell está esperando para aceptar un comando. Si el usuario ahora
teclea
date
por ejemplo, el shell crea un proceso hijo y ejecuta el programa date como hijo. Mientras se está ejecutando
el proceso hijo, el shell espera a que termine. Cuando el hijo termina, el shell exhibe otra vez la indicación y
trata de leer la siguiente línea de entrada.
El usuario puede especificar que la salida estándar sea redirigida a un archivo, por ejemplo,
date >archivo
De forma similar, la entrada estándar puede redirigirse, como en
sort <archivo 1 >archivo2
que invoca el programa sort con entradas tomadas de archivo1 y enviando las salidas a archivo2.
La salida de un programa puede usarse como entrada para otro programa conectándolos con un conducto
Así,
cat archivo1 archivo2 archivo3 | sort >/dev/lp
invoca el programa cat para concatenar tres archivos y enviar la salida a sort para que acomode todas las
líneas en orden alfabético. La salida de sort se redirige al archivo /dev/lp, que es un nombre típico para el
archivo especial por caracteres de la impresora. (Por convención, todos los archivos especiales se guardan
en el directorio /dev.)
Si un usuario escribe un signo & después de un comando, el shell no espera hasta que se completa, sino
que exhibe una indicación de inmediato. Por tanto,
cat archivo1 archivo2 archivo3 | sort >/dev/lp &
inicia el ordenamiento como trabajo de segundo plano, permitiendo que el usuario siga trabajando
normalmente mientras se está realizando el ordenamiento. El shell tiene varias otras características
interesantes que no tenemos espacio para examinar aquí
-14-
Redes de comunicaciones
Última modificación 2009/04
Se solía decir que TCP/IP debería funcionar incluso entre dos latas unidas por una cuerda.
En la foto vemos a Jon Postel, Steve Crocker y Vinton Cerf haciendo la prueba.
2004-2009 – Güimi (http://guimi.net)

Esta obra está bajo una licencia "Reconocimiento-Compartir bajo la misma licencia 3.0 España" de Creative Commons.
Para ver una copia de esta licencia, visite http://guimi.net/index.php?pag_id=licencia/cc-by-sa-30-es_human.html.
Reconocimiento tautológico: Todas las marcas pertenecen a sus respectivos propietarios.
Elaboración propia utilizando principalmente apuntes de trabajo, de distintas asignaturas universitarias, trabajos del
profesor Montañana publicados en RedIRIS y artículos de la wikipedia (http://www.wikipedia.org).
Algunas partes son directamente copia o traducción de las fuentes.
Contenido
1. INTRODUCCIÓN...........................................................................................................................................................4
1.1. Conceptos................................................................................................................................................................4
1.2. Tipos de red.............................................................................................................................................................6
1.3. Redes de área local (LAN)......................................................................................................................................9
1.4. Redes de área extensa (WAN)................................................................................................................................9
2. EL MODELO ISO OSI.................................................................................................................................................10
2.1. Niveles de red del modelo OSI.............................................................................................................................11
3. EL MODELO INTERNET............................................................................................................................................13
3.1. Un poco de historia...............................................................................................................................................13
3.2. Familia de protocolos de Internet.........................................................................................................................13
3.3. Protocolo Internet (IP)..........................................................................................................................................15
3.4. Otros protocolos de la familia Internet.................................................................................................................25
4. ETHERNET...................................................................................................................................................................29
4.1. Un poco de historia...............................................................................................................................................29
4.2. Definición.............................................................................................................................................................30
4.3. Control de colisiones.............................................................................................................................................30
4.4. Direccionamiento..................................................................................................................................................31
4.5. Formato de trama..................................................................................................................................................31
4.6. Tarjetas interfaces de red (NIC: Network Interface Card)....................................................................................32
4.7. Repetidores y concentradores (Hubs)...................................................................................................................32
4.8. Puentes (Bridges) y conmutadores (Switches).....................................................................................................33
4.9. Comunicación Dúplex (Full-Duplex)...................................................................................................................33
4.10. Restricciones.......................................................................................................................................................34
4.11. La evolución de la familia Ethernet....................................................................................................................35
4.12. Mejoras de rendimiento......................................................................................................................................39
5. IEEE 802.11 (Wi-Fi).....................................................................................................................................................41
5.1. Definición.............................................................................................................................................................41
5.2. Otras definiciones.................................................................................................................................................41
5.3. Problemas añadidos en redes inalámbricas...........................................................................................................43
5.4. Control de acceso al medio (MAC: Medium Access Control).............................................................................43
5.5. Seguridad..............................................................................................................................................................44
5.6. Evolución del estándar 802.11..............................................................................................................................45
6. PROTOCOLOS WAN..................................................................................................................................................48
6.1. Portadora-T y PDH (Plesiochronous Digital Hierarchy)......................................................................................48
6.2. X.25.......................................................................................................................................................................49
6.3. RDSI.....................................................................................................................................................................49
6.4. FDDI (Fiber Distributed Data Interface) / CDDI.................................................................................................50
6.5. FRAME-RELAY..................................................................................................................................................50
6.6. ATM (Asynchronous Transfer Mode)..................................................................................................................52
6.7. Redes de fibra SONet / SDH................................................................................................................................54
6.8. PoS (Packet Over SONet/SDH)............................................................................................................................55
6.9. GSM (Global System for Mobile comunications)................................................................................................55
6.10. GPRS (General Packet Radio Service)...............................................................................................................55
6.11. UMTS (Universal Mobile Telecommunications System)..................................................................................55
6.12. Redes de satélites................................................................................................................................................56
6.13. MPLS (Multi-Protocol Label Switching)...........................................................................................................56
7. MÉTODOS DE ACCESO A REDES...........................................................................................................................57
7.1. Introducción..........................................................................................................................................................57
7.2. Módems.................................................................................................................................................................57
http://guimi.net 2 / 99
7.3. xDSL.....................................................................................................................................................................57
7.4. CATV (Redes de TV por cable)...........................................................................................................................60
7.5. LMDS (Local Multipoint Distribution System)...................................................................................................61
8. REDES PRIVADAS VIRTUALES..............................................................................................................................62
8.1. Introducción..........................................................................................................................................................62
8.2. Autenticación de usuario.......................................................................................................................................63
8.3. Protocolos para la realización de VPNs................................................................................................................64
9. SEGURIDAD EN REDES............................................................................................................................................65
9.1. Introducción..........................................................................................................................................................65
9.2. Algoritmos............................................................................................................................................................69
9.3. Técnicas criptográficas y de seguridad.................................................................................................................71
9.4. Autenticación de usuario.......................................................................................................................................71
9.5. Esquemas de seguridad.........................................................................................................................................73
9.6. Herramientas de seguridad de redes.....................................................................................................................76
10. TRANSMISIÓN MULTIMEDIA EN REDES IP.......................................................................................................77
10.1. Introducción........................................................................................................................................................77
10.2. El protocolo H.323..............................................................................................................................................78
10.3. Protocolo SIP......................................................................................................................................................82
11. VÍDEO-DIFUSIÓN Y VÍDEO BAJO DEMANDA...................................................................................................85
12. ANEXO I – Cortafuegos.............................................................................................................................................86
13. ANEXO II – Comandos para la gestión de red...........................................................................................................87
14. ANEXO III - La VC en el campo educativo...............................................................................................................98
14.1. Introducción........................................................................................................................................................98
14.2. Técnicas de realización.......................................................................................................................................98
14.3. Elementos que el profesor tiene que contemplar................................................................................................99
Redes de comunicaciones 1. INTRODUCCIÓN
1. INTRODUCCIÓN
1.1. Conceptos
Red de comunicaciones
Una red de comunicaciones es un conjunto de medios técnicos que permiten la comunicación a distancia entre equipos
autónomos (no jerárquica -master/slave-). Normalmente se trata de transmitir datos, audio y vídeo por ondas
electromagnéticas a través de diversos medios (aire, vacío, cable de cobre, fibra óptica, etc.). La información se puede
transmitir de forma analógica, digital o mixta, pero en cualquier caso las conversiones, si las hay, siempre se realizan de
forma transparente al usuario, el cual maneja la información de forma analógica exclusivamente.
Las redes más habituales son las de ordenadores, las de teléfono, las de transmisión de audio (sistemas de megafonía o
radio ambiental) y las de transmisión de vídeo (televisión o vídeo vigilancia).
Capacidad de transmisión
La capacidad de transmisión indica el número de bits por segundo que se pueden transmitir a través de una conexión. A
menudo se llama erróneamente velocidad de transmisión (que depende de la capacidad y de otros factores) o ancho de
banda (que es la amplitud de onda utilizable). En este texto usaremos ancho de banda como sinónimo de capacidad de
transmisión excepto cuando se hable explícitamente de frecuencias de onda.
En el contexto de velocidades o capacidades de transmisión (caudales), los prefijos (K, M, G, ... ) se utilizan con su
significado métrico de potencias de 10 (103, 106, etc.).
En el contexto de almacenamientos, buffers, etc, los prefijos significan potencias de 2 (210, 220, etc.)1.
Control de flujo
Capacidad del receptor de enviar un mensaje al emisor para indicarle que deje de enviar momentáneamente datos
porque no se puede garantizar la recepción correcta de ellos (porque hay saturación de buffers, por ejemplo).
Codificaciones eléctricas
El código eléctrico más simple, el unipolar establece un valor de voltaje para indicar un 1 y otro valor para indicar un 0
(p.e.: bit 1=+0,85V y bit 0=-0,85V). Este código no tiene límites en su
componente continua: si debemos enviar muchos bits consecutivos a 1, la
señal debe mantenerse varios ciclos de reloj al voltaje necesario.
Esto hace que una señal continua se desincronice fácilmente si para emisor
y receptor la señal no ha durado los mismos ciclos de su reloj. Además la
mayoría de medios de comunicaciones de red no pueden transportar una
componente continua. Por ello se utilizan códigos en línea (modulación en
banda base o codificación eléctrica) que eliminan la componente continua y
facilitan la sincronización de relojes de emisor y receptor.
Existen dos modos básicos de realizar la codificación eléctrica:

● Diseñar cada código transmitido de tal forma que contenga el mismo número de impulsos positivos que
negativos, así se anularía la componente continua. Por ejemplo el código Manchester2.
● Realizar una traducción de la señal usando un código de disparidades emparejadas o código alternante. Es
decir, algunos o todos los símbolos están representados por dos conjuntos de dígitos, de disparidad opuesta,
que se utilizan en una secuencia de manera que se minimice la componente continua y se facilite la
sincronización3.
1 La CEI definió en 1999 los símbolos para potencias de dos: kibi (Ki), mebi (Mi), gibi (Gi), tebi (Ti), pebi (Pi) y exbi (Ei).
2 El código Manchester, también denominado codificación bifase-L, es un método de codificación eléctrica de una señal binaria en el que en cada
tiempo de bit hay una transición entre dos niveles de señal. Así 1 es una transición de alto a bajo y 0 es una transición de bajo a alto (o al revés).
Es un código autosincronizado, ya que en cada bit se puede obtener la señal de reloj, lo que hace posible una sincronización precisa del flujo de
datos. Una desventaja es que consume el doble de ancho de banda que una transmisión asíncrona.
3 La codificación de traducción utiliza un código en línea (modulación en banda base) que traduce símbolos para conseguir un balance de corriente
y permitir la sincronización de la señal. 4B/5B utiliza MLT para traducir símbolos de 4 bits en símbolos de 5 bits. 8B/6T utiliza PAM para
traducir 5 binarios en 6 ternarios. PAM 5x5 utiliza códigos quinarios (5 voltajes diferentes).
Encaminamiento (Enrutamiento o Routing)

Cada nodo intermedio de una comunicación debe conocer dónde ha de enviar el paquete que ha recibido. En el caso de
los circuitos (conmutados o virtuales) solo se toma la decisión en el inicio de la conexión. En el caso de paquetes
conmutados (datagramas) se toma la decisión con cada paquete.
Este proceso de decisión se denomina encaminamiento (routing).
La solución más sencilla pero ineficaz es enviar el paquete por todos los interfaces menos por el que llegó (inundación).
Es el funcionamiento de los concentradores. Este sistema no se considera un protocolo de encaminamiento.
Para encaminadores (routers) sencillos se puede utilizar configuraciones estáticas de encaminamiento.
Los encaminadores más modernos permiten utilizar auténticos protocolos de encaminamiento dinámico que sirven para
intercambiar información entre encaminadores y adaptarse a situaciones cambiantes de tráfico basándose en:
● Capacidad del enlace.
● Tráfico medio.
● Retardo.
● Fiabilidad.
Las técnicas básicas son:

● Vector de distancia: Cada encaminador mantiene una tabla con las distancias mínimas hacia cada posible
destino y el interfaz de salida. Le pasa esta información a todos sus vecinos. Tiene el problema de la cuenta a
infinito.
● Estado de enlace. Identifica a sus vecinos y su coste y manda esa información a todos los encaminadores de la
red. Con esa información se calcula el mapa de la red.
Debido a que los protocolos de encaminamiento no son escalables se utiliza encaminamiento jerárquico. Esto simplifica
el intercambio de información aunque puede no aprovechar todos los caminos mínimos.
Cada nodo intermedio de una comunicación puede utilizar variantes de dos técnicas de reenvío:
● Store-and-forward: Almacena completamente el paquete y luego, si es correcto, lo reenvía.
● Cut-througth: Conforme recibe el paquete, y una vez que sabe por que puerto lo tiene que reenviar, empieza
su retransmisión. Si después el paquete resulta erróneo se propaga el error al siguiente nodo. Esta técnica es
más rápida y sencilla para redes fiables.
Calidad de Servicio (QoS: Quality of Service)

La congestión es la situación en la que un equipo o una línea no puede procesar todo el tráfico que se le envía. La
congestión puede provocar pérdida de datos y baja mucho el rendimiento de la red.
Para resolverla, en conexiones punto a punto se utiliza el control de flujo, que puede aplicarse a nivel de enlace o de
transporte.
Un factor que propicia la congestión es la tendencia del tráfico a generarse a ráfagas.
Una red puede comprometerse a garantizar una serie de parámetros de una conexión o servicio. El contrato que
especifica los parámetros de QoS se denomina Acuerdo de Nivel de Servicio (SLA: Service Level Agreement). Los
parámetros que se pueden garantizar son:
– Ancho de banda (Throughput) mínimo.
– Retardo o latencia máximo.
– Fluctuación del retardo (Jitter) máxima.
– Pérdida de datos tolerable.
– Disponibilidad del servicio (en % del tiempo).
Los tipos de servicio que puede dar una red desde el punto de vista de la QoS son:
● Mejor esfuerzo posible (Best Effort Service): La red no se compromete a nada, pero intentará que los datos
lleguen al otro extremo lo antes posibles.
● Con servicio diferenciado (soft QoS o Differentiated Service): Trata cierto tráfico con más preferencia que
otro, pero no garantiza nada a ninguno de ellos.
● Con servicio garantizado (hard QoS o Guaranteed Service): Se definen unos valores límite requeridos al
establecer una conexión extremo a extremo y todos los nodos de la red se comprometen a garantizarlos,
reservando los recursos necesarios.
Para implementar QoS es necesario utilizar técnicas de:

● Gestión de tráfico individual en cada encaminador de la red:
○ Gestión de colas.
○ Perfilado de tráfico (Traffic Shaping)
○ Vigilancia de tráfico (Traffic Policing)
● Señalización entre los elementos de la red:
○ Marcado de paquetes descartables.
○ Envío de paquetes de asfixia.
○ Descarte selectivo de paquetes.
○ Marcado de Prioridad en paquetes.
○ Control de admisión y reserva de recursos.
● Mejora del aprovechamiento de enlaces lentos:
○ Fragmentación de paquetes grandes
○ Compresión de datos
1.2. Tipos de red

Las redes se pueden clasificar de diferentes maneras. Las principales clasificaciones son:
● Por su extensión: Redes de área personal (PAN), local (LAN), extensa (WAN)... (ver cuadro inferior).
● Por su topología: Estrella, bus, anillo, malla, mixta...
● Por su conexión física: se clasifican en redes punto a punto (unicast) y redes multipunto o de difusión
(broadcast).
● Por su técnica de transmisión de datos: líneas dedicadas, circuito conmutado o paquetes conmutados.
● Por su uso: se clasifican en redes privadas o corporativas y redes públicas.
● ...
Por su extensión
Diámetro Tipo
< 0,01 m Paralelismo masivo. Procesadores multi-núcleo.
< 0,1 m Multiprocesadores.
< 10 m Redes de área personal (PAN: Personal Area Network). Redes de infrarrojos o bluetooth.
10 m – 3 km Redes de área local (LAN: Local Area Network) y metropolitana (MAN). Ethernet, Wi-Fi.
> 3 km Redes de área extensa (WAN: Wide Area Network) o redes interconectadas.
Frame-Relay, RDSI, ATM, SONet/SDH.
Por su topología
La topología de una red es el diseño de las comunicaciones entre los nodos de la red. Las topologías principales son tipo
bus compartido (o símplemente bus), estrella o anillo aunque existen más topologías.
Hay que diferenciar entre la topología física, que define como están conectados físicamente los nodos y la topología
lógica que es como tratan los nodos las conexiones. Así por ejemplo se puede disponer de una red física en estrella
donde el nodo central es un concentrador y el resto de nodos son equipos utilizando para comunicarse el protocolo
Ethernet original, que considera el medio utilizado como una topología de bus compartido.
Por su conexión física

● Redes punto a punto (unicast): basadas principalmente en cable y en cada conexión intervienen solo dos
equipos. Tienen problemas de tipología. Se subdividen en:
○ Simplex: inútil en redes de computadores (monodireccional).
○ Semi-dúplex (Half-duplex): envía datos cada vez en un sentido.
○ Dúplex (Full-duplex): envía datos en los dos sentidos a la vez.
En las redes semi-dúplex y dúplex se puede disponer de la misma capacidad en las dos direcciones de
transmisión (conexión simétrica) o no (conexión asimétrica).
Ejemplos de redes punto a punto: LANs en estrella con conmutadores centrales y la mayoría de las WAN
(enlaces telefónicos, X.25, Frame Relay, RDSI, ATM, etc.).
● Redes multipunto o redes de difusión (broadcast): basadas principalmente en bus compartido (cable bus y
anillo) y redes inalámbricas (radio, satélites...); todos los equipos comparten el mismo medio de transmisión.
Tienen problemas de colisiones que se pueden afrontar con una gestión:
○ Estática (TDM): No emite si alguien lo está haciendo.
○ Dinámica (Centralizada o Distribuida).
Las emisiones pueden estar marcadas como unicast, multicast o broadcast, pero no garantizan la
confidencialidad.
Ejemplos de redes multipunto: transmisiones vía radio o satélite, redes CATV y la mayoría de las LANs
originales (Ethernet original, FDDI, Token Ring, Inalámbricas, etc.).
Por su técnica de transmisión de datos

Líneas dedicadas. Enlace punto a punto permanente y siempre disponible. Se utilizan principalmente en redes WAN
con velocidades prefijadas por el proveedor, generalmente simétricas y full-dúplex. Otro caso habitual es el radio
enlace. El nivel de enlace utilizado suele ser HDLC o PPP. Suelen tener un coste elevado por lo que solo son adecuadas
si hay mucho tráfico continuo.
Modelos de circuito conmutado (Circuit Switching). En ellos las comunicaciones no comparten los medios. Al
iniciarse la comunicación se reserva los recursos intermedios necesarios para establecer y mantener el circuito. Si el
canal se corta se corta la comunicación. Los dispositivos mantienen información sobre el estado de la comunicación
(statusfull). Utilizado en la Red Telefónica Conmutada (RTC4) incluyendo:
● Red Telefónica Básica (RTB) -analógica-.
● Red Digital de Servicios Integrados (RDSI o ISDN) -digital-.
● GSM (Global System for Mobile Comunications) -digital por radioenlace-.
Una vez establecido el el circuito se comporta como una línea dedicada ofreciendo un transporte físico de bits sobre el
que se puede utilizar cualquier protocolo de nivel de enlace.
El costo es proporcional al tiempo y la distancia de conexión.
Modelos de paquetes conmutados (Packet Switching). En ellos las comunicaciones se dividen en paquetes que
comparten los medios. Se pueden utilizar varios enlaces en cada interfaz físico.
Ofrece un medio físico de transmisión de datos para los equipos. Existen dos submodelos:
● Datagramas: Cada paquete debe estar delimitado e identificado y llevar la dirección destino, y cada uno se
encamina independientemente, sin que el origen y el destino tengan que pasar por un establecimiento de
comunicación previo. En este modelo no sabemos si los paquetes van a llegar todos ni si van a llegar por orden
(ni si van a llegar sin errores). Los dispositivos no mantienen información sobre el estado de la comunicación
(stateless). Es el modelo más sencillo de implementar y el único que soporta multidifusión (multicast). Se
puede asimilar al sistema de correo tradicional.
● Circuitos virtuales (VC: Virtual Circuit): Simula un circuito conmutado, pero compartiendo los medios.
Primero se establece una conexión y los equipos intermedios reservan una parte de sus recursos; después todos
los paquetes siguen la misma ruta ordenadamente. Este modelo es utilizado en telefonía digital GPRS y redes
como X.25, Frame Relay o ATM.
○ PVC (Permanent VC): Los PVC son circuitos virtuales definidos estáticamente y permanentes.
○ SVC (Switched VC): Se establecen y terminan a petición del usuario de forma dinámica. La
implementación de circuitos virtuales es más compleja que la de circuitos permanentes.
Otra división de redes por su técnica de transmisión de datos sería en servicios orientados a conexión – que incluiría
los modelos de líneas dedicadas, circuito conmutado y circuito virtual- y servicios no orientados a conexión -el
modelo de datagramas-.
La primera red (ARPANET) nació en 1964 y unía cuatro nodos con un protocolo de datagramas (NCP).
4 RTC o PSTN: Public switched telephone network
1.3. Redes de área local (LAN)

El comité de estándares IEEE 802 LAN/MAN es el encargado de desarrollar estándares de redes PAN, LAN y MAN.
Los estándares ISO 8802.x se corresponden con los estándares IEEE 802.x. Los más utilizados son:
● 802.1 – Definición de interfaces
○ 802.1d – Puentes y conmutadores. Define el protocolo "Spanning Tree".
○ 802.1e – Gestión de la carga de la red
○ 802.1p (integrado posteriormente en 802.1q) – Tráfico por prioridades
○ 802.1q – VLANs
○ 802.1x – Control de acceso a redes en base a puertos
● 802.3 – Ethernet CMSA/CD
○ 802.3u – Fast-Ethernet
○ 802.3x – Full-Duplex
○ 802.3z – Gigabit Ethernet Fibra
○ 802.3ab – Gigabit Ethernet Cobre
○ 802.3ae – Gigabit Ethernet (En desarrollo)
● 802.4 – Token Bus
● 802.5 – Token Ring
● 802.8 – FDDI
● 802.11 – Inalámbrica (Wi-Fi)
○ Ver el apartado IEEE 802.11 para un detalle de las principales revisiones.
● 802.14 – Módems
● 802.15 – Inalámbrica PAN
○ 802.15.1 – Bluetooth
● 802.16 – Inalámbrica MAN (WMAN)
● 802.20 – Inalámbrica MAN con movilidad (Mobile Wi-Fi)
1.4. Redes de área extensa (WAN)

A diferencia de las redes locales, cuya infraestructura es generalmente propiedad y responsabilidad del usuario, las
redes de área extensa (WAN) normalmente utilizan redes de proveedores. Inicialmente estas redes eran únicamente las
instaladas para la transmisión de voz por las compañías telefónicas, pero hoy en día se utilizan también redes creadas
específicamente para datos por distintos proveedores (compañías de telecomunicaciones).
Así las primeras redes se caracterizaban por su baja velocidad y su alta tasa de errores, además de por su alto costo. Hoy
en día existen sin embargo redes de gran fiabilidad y velocidad, aunque el costo suele seguir siendo alto.
Casi siempre son redes punto a punto (excepto redes de satélites) sobre líneas E1/T1 o sobre la RTC dependientes de un
proveedor de servicios. Por ello se utilizan servicios orientados a conexión: líneas dedicadas, circuitos conmutados y
circuito virtuales.
Algunos ejemplos de WAN:

Conexión permanente Conexión temporal
Circuito Real Líneas dedicadas Conmutación de circuitos
E1/T1 RTB, RDSI, GSM
Circuito Virtual Redes de conmutación con PVCs Redes de conmutación con SVCs
X.25, Frame Relay, ATM X.25, Frame Relay, ATM
Redes de comunicaciones 2. EL MODELO ISO OSI
2. EL MODELO ISO OSI

(Open Systems Interconnection Basic Reference Model)
Este es el modelo de referencia para la descripción de las arquitecturas de redes (conjunto de capas y protocolos de red),
aunque raramente se ha implementado por completo. Su objetivo es conseguir que un conjunto heterogéneo de equipos
autónomos (no jerárquico -master/slave-) comunicados por medios de baja calidad también heterogéneos, aparezca ante
el usuario como un medio homogéneo y fiable.
Antes de ISO OSI cada arquitectura de red dependía del fabricante y de protocolos propietarios (SNA, Appletalk,
NetWare, DECnet...). ISO e ITU-T colaboraron a partir de finales de los 70 para estandarizar un modelo de referencia
para redes que se aprobó en 1984 (ISO 7498:1984). Aunque OSI sigue siendo el modelo teórico de referencia, en 1996
se renunció definitivamente a su implementación práctica debido a que, mientras se desarrollaban los trabajos de diseño
y estandarización de OSI, la pila TCP/IP se había ya convertido en el estándar de hecho en los niveles 3 y 4, mientras
que en las capas 1 y 2 Ethernet y Token Ring asumían el mismo rol en las redes de área local.
N7 Aplicación
Mensajes
Servicios de red N7
Genera / Consume el mensaje
N6 Presentación
Nivel usuario N6
Representación de los datos
Comprime / Expande / Traduce
Equipos
N5 Sesión
Interfaz de dispositivos N5
de red del sistema
N4 Transporte Datagramas (UDP)

Divide / Compone el mensaje Segmentos (TCP) N4
Fiabilidad de datos
Subred comunicaciones
[Encaminadores / Puentes]
N3 Red Paquetes
Direccionamiento lógico N3 N3
Selección de ruta y gestión tráfico
LLC (Logical Link Control) Tramas

N2 Enlace de datos N2 N2
Direcc. físico y gestión tráfico
MAC (Medium Access Control) Medio
(Hilo, ondas...)
N1 Físico N1
Señal y transmisión N1
Cada nivel es independiente de los demás y se comunica únicamente

con los niveles inmediatamente superior y/o inferior por medio de
interfaces. Así cada nivel aporta una cabecera, de forma que los datos
realmente comunicados entre aplicaciones (N7) son solo una parte de
los transmitidos físicamente (N1). Esto causa sobrecarga (overhead)
pero aporta gran flexibilidad al sistema.
A nivel lógico cada capa se comunica con las aplicaciones de su misma

capa en otra máquina a través de las capas inferiores.
2.1. Niveles de red del modelo OSI

Subred de comunicaciones (Niveles 1, 2 y 3)
La capa física (N1) se encarga de transmitir los bits de información a través del medio utilizado. Es responsable de las
conexiones físicas del equipo con la red en lo que se refiere al medio físico (cable de distintos tipos, radio,
infrarrojos...), características del medio (p.e. tipo de cable o calidad del mismo; tipo de conectores normalizados o de
antena...) y la forma en la que se transmite la información (codificación de señal, niveles de tensión/intensidad de
corriente eléctrica, modulación, tasa binaria, velocidad de transmisión, etc.). Para ello establece interfaces mecánicas,
eléctricas y de procedimiento, en base a las características del medio de transmisión (Manchester, 4B/5B, DSSS...).
El medio de transmisión, por ejemplo un cable, se convierte en un almacén intermedio (buffer) lo que produce bastantes
problemas de comunicación. Además esto hace que los ficheros grandes tengan más probabilidades de sufrir errores,
por lo que se seccionan en paquetes. Al mejorar las conexiones físicas se puede utilizar tramas mayores (Jumbo
frames).
La capa de enlace (N2) pretende ser capaz de proporcionar un tránsito de datos fiable a través de un enlace físico. Para
ello debe crear y reconocer los límites de las tramas, así como opcionalmente resolver los problemas derivados del
deterioro, pérdida o duplicidad de las tramas y colisiones en conexiones de multidifusión. También puede incluir algún
mecanismo de control del flujo que evite la saturación de un receptor que sea más lento que el emisor.
Suele tener una conexión con el nivel físico (MAC -Medium Access Control-) y varias con el nivel de red (LLC
-Logical Link Control-).
A este nivel se implementa la calidad del servicio de red o QoS (Quality of Service). Cada usuario contrata con la red un
tipo de servicio y una calidad (p.e: mayor prioridad, mayor ancho de banda...).
Sistemas de control de errores

● Unack conectionless: ningún control. Fácil y rápido. Para redes de nivel 1 (físicas) muy fiables.
● Ack conectionless: informa de errores, pidiendo reenvíos al emisor.
● Ack conection oriented: informa de errores, pide reenvíos y ordena los paquetes.
Por tanto la capa de enlace de datos se ocupa del direccionamiento físico, de la topología de la red, del acceso a la red
(MAC: Medium Access Control), de la distribución ordenada de tramas y opcionalmente del control del flujo, de la
notificación de errores y de la calidad del servicio (QoS).
Los concentradores (hubs) actúan exclusivamente a nivel físico (N1) y, entre otras cosas, no controlan las colisiones;
mientras que los conmutadores (switches) actúan a nivel de enlace.
El cometido de la capa de red (N3) es hacer que los datos lleguen desde el origen al destino, aún cuando ambos no
estén conectados directamente. Para ello se basan en dos aspectos: el direccionamiento y el encaminamiento (utilizando
encaminadores (routers), a veces llamados "enrutadores").
Adicionalmente la capa de red debe gestionar la congestión de red.
Nivel de transporte (Nivel 4)

El nivel de transporte (N4) se encarga de efectuar y asegurar el transporte de los datos de la máquina origen a la
máquina destino, independizándolo del tipo de red física que se esté utilizando. En el modelo de Internet los protocolos
de transporte también determinan a que aplicación van destinados los datos.
Sesión y presentación (Niveles 5 y 6)

En la práctica el nivel de sesión (N5) nunca se implementa por separado, sino con el nivel de presentación (N6).
La capa de sesión (N5) establece, gestiona y finaliza las conexiones entre usuarios (procesos o aplicaciones) finales. Se
encarga de controlar la sesión, la concurrencia y la reanudación en caso de interrupción.
La capa de presentación (N6) se encarga de la representación de la información. Esta capa es la primera en trabajar
más el contenido de la comunicación que la forma en que se establece la misma. En ella se tratan aspectos tales como la
semántica y la sintaxis de los datos transmitidos, de manera que aunque distintos equipos puedan tener diferentes
representaciones internas de caracteres (ASCII, Unicode, EBCDIC), números (little-endian tipo Intel, big-endian tipo
Motorola), sonido o imágenes, los datos lleguen de manera reconocible. Además permite cifrar los datos y
comprimirlos.
Nivel de aplicación (Nivel 7)

El nivel de aplicación (N7) ofrece a las aplicaciones (de usuario o no) la posibilidad de acceder a los servicios de red y
define los protocolos que utilizan las aplicaciones para intercambiar datos, como correo electrónico (POP y SMTP),
gestores de bases de datos y servidor de ficheros (FTP). Hay tantos protocolos como aplicaciones distintas y puesto que
continuamente se desarrollan nuevas aplicaciones el número de protocolos crece sin parar.
El nivel de aplicación abstrae al usuario del acceso a la red. El usuario utiliza aplicaciones que son las que interactúan
en este nivel. Así por ejemplo un usuario para utilizar el protocolo HTTP interactúa con un navegador, no manda una
petición "HTTP/1.0 GET index.html" para conseguir una página en html, ni lee directamente el código html/xml.
Redes de comunicaciones 3. EL MODELO INTERNET
3. EL MODELO INTERNET
3.1. Un poco de historia
Los protocolos TCP/IP (Transmission Control Protocol / Internet Protocol) fueron desarrollados por la agencia
DARPA (Defense Advanced Research Projects Agency). En primavera de 1973 se unieron para desarrollar modelos de
interconexión entre distintas arquitecturas5 Robert E. Kahn y Vicent Cerf, el desarrollador del protocolo NCP (Network
Control Program) que se utilizaba en ARPANET.
En verano de 1973 hicieron una reformulación fundamental del protocolo: las diferencias entre protocolos de red
quedarían escondidas usando un protocolo común entre redes (Internetwork Protocol) y la responsabilidad de la
fiabilidad caería sobre los equipos, en vez de sobre la red. Para ello se inspiraron en la red Cyclades desarrollada por
Hubert Zimmerman y Louis Pouzin.
Un equipo de red especial llamado encaminador (router), con una conexión a cada red, se encarga de enviar paquetes
entre ellas. El papel de los encaminadores está definido en el RFC 1812 (Request For Comments 1812).
Al reducir el papel de la red al mínimo se pudo conectar con cualquier red6, solventando el problema inicial de Kahn
para interconectar las redes de satélites y las de radio. Cerf y su equipo de Stanford desarrollaron con detalle el nuevo
modelo, generando la primera especificación de TCP (RFC 675). En 1978 se publico la versión estable -TCP/IP versión
4- que aún se utiliza en Internet.
En 1980 David P. Reed diseñó el protocolo UDP (User Datagram Protocol, también llamado Universal Datagram
Protocol) para trabajar sobre IP con un esquema de datagramas -no orientado a conexión-.
En 1982 el departamento de defensa de los EE.UU. seleccionó TCP/IP como su protocolo estándar y el 1 de enero de
1983 ARPANET mudó sus sistemas al nuevo protocolo.
En 1992 nace la ISOC (Internet SOCiety) una entidad pública internacional sin ánimo de lucro, para dirigir el desarrollo
de Internet7. Así en Enero de 1992 el IAB (Internet Architecture Board) pasa a depender de esta nueva sociedad,
dejando de depender del departamento de defensa de EE.UU.
El IAB es responsable de la edición y publicación de los RFCs (Request For Comments); es la autoridad oficial sobre
los números de Internet (IANA8: Internet Assigned Numbers Authority)9; supervisa las actividades de las IxTF como la
IETF (Internet Engineering Task Force) -que ratifica los estándares oficiales de Internet- o la IRTF (Internet Research
Task Force)...
3.2. Familia de protocolos de Internet

La pila IP forma un conjunto de protocolos que utiliza tanto el origen como el destino para la comunicación de datos a
través de una red de paquetes conmutados. Este conjunto no está orientado a la conexión entre equipos, sino a la
interconexión de redes que ya están implementadas en origen, por tanto no pretende competir con el modelo OSI, sino
implementar una parte de sus niveles.
Así el conjunto TCP/IP no hace ninguna referencia al nivel de usuario ni al nivel físico, sino únicamente al nivel de
encaminamiento entre redes (protocolo IP) y al de transporte (por medio de los protocolos TCP y UDP).
Sin embargo en la práctica la gran mayoría de redes, y en concreto Internet, se basan en IP para generar redes, es decir
para conectar equipos, complementando TCP-UDP/IP con protocolos a nivel de usuario “por arriba” y a nivel físico
“por debajo”, generando una pila de protocolos conocida como familia de protocolos de Internet o modelo Internet.
5 Pretendían conectar con ARPANET una red de paquetes satelitales (SATNET -conectaba EE.UU., Noruega y Reino Unido-) con redes de
paquetes de radio (PRNETs -como ALOHAnet de la Universidad de Hawaii-).
6 Se solía decir que TCP/IP debería funcionar incluso entre dos latas unidas por una cuerda. (Ver portada ;-).
7 “...to assure the open development, evolution and use of the Internet for the benefit of all people throughout the world.”
8 El primer IANA fue Jon Postel, que también era el editor de los RFCs. Protagonizó la rebelión de Internet frente al gobierno Clinton que dio pie a
la creación de ISOC e ICANN (1998/02/28).
9 En la práctica es ICANN (Internet Corporation for Assigned Names and Numbers), quién desde su fundación en 1998 gestiona los dominios
principales genéricos y de países (generic -gTLD- and country code -ccTLD- Top-Level Domain). La renovación del contrato (2006) fue
polémica porque se solicitaba que el IANA fuese una agencia de la ONU en vez de una organización de EE.UU. -aunque sea no lucrativa- sobre
cuyas decisiones el gobierno de EE.UU. tiene derecho de veto.
Efectivamente muchas redes van implementadas cada vez más sobre el protocolo Internet que no controla errores, ni
congestión, ni disponen de garantías de QoS (Quality of Service); en parte confiando en la mejor calidad de los medios
actuales, en parte obviando el control de errores para protocolos de tiempo real, como transmisión de audio y vídeo,
donde por ejemplo no tiene sentido retransmitir parte del fotograma que se emitió hace 2 segundos.
De la misma manera, como TCP/IP no tiene un nivel de sesión unificado sobre el que los niveles superiores se
sostengan, estas funciones son típicamente desempeñadas (o ignoradas) por las aplicaciones de usuario.
Comparación entre el modelo OSI y el modelo de Internet

El modelo OSI fue propuesto como una aproximación teórica y también como una primera fase en la evolución de las
redes de ordenadores. En cambio el modelo de Internet fue creado como la solución a un problema práctico. Aunque la
familia de protocolos de Internet puede describirse por analogía con el modelo OSI, en la práctica no se corresponden
exactamente.
Concretamente hay protocolos de la familia Internet (ICMP, IGMP) que funcionan sobre IP pero se utilizan para control
de comunicaciones, por lo que por pila estarían en el nivel OSI N4 (al ir encima de IP -N3-) pero por función estarían
en parte como OSI N3 (red), en parte como OSI N2 (enlace, direccionamiento físico).
También existen protocolos de comunicación entre encaminadores (IGP: Interior Gateway Protocol) que funcionan
sobre IP (OSPF) o sobre TCP-UDP (RIP, BGP, IGRP, EIGRP) y podrían llegar a considerarse parte del nivel de enlace.
Igualmente los protocolos ARP (Address Resolution Protocol) y RARP (Reverse ARP) que forman parte de la familia
IP, operan por encima del nivel de enlace (N2 OSI) pero por debajo de IP (N3 OSI).
3.3. Protocolo Internet (IP)

Diseño de IP
La versión más utilizada de IP (Internet Protocol) todavía es la 4 (IPv4), la primera versión estable que se publicó. La
versión 5 es experimental y la versión 6 está sustituyendo progresivamente a la versión 4.
IP utiliza un esquema de red no fiable de datagramas o paquetes independientes. En particular, en IP no se necesita

ninguna configuración antes de que un equipo intente enviar paquetes a otro con el que no se había comunicado antes.
Aunque IP define clases de paquetes, no provee ningún mecanismo para determinar si un paquete alcanza o no su
destino, ni verifica la integridad de los datos transmitidos. Al no garantizar nada sobre la recepción del paquete, éste
podría llegar dañado, en otro orden con respecto a otros paquetes, duplicado o simplemente no llegar. Si se necesita
fiabilidad, ésta es proporcionada por los protocolos de la capa de transporte, como TCP.
En v4 verifica la integridad de sus cabeceras (mediante checksums o sumas de comprobación), pero en v6 ya no.
Direccionamiento y encaminamiento
Los aspectos principales de IP son el direccionamiento y el encaminamiento. Cada interfaz de red (NIC: Network
Interface Card) se identifica por medio de una dirección IP unívoca. Además cada NIC está asignado a una subred. La
clasificación de redes estaba definida inicialmente en la propia dirección IP, pero en 1993 IETF definió el sistema
CIDR (Classless Inter-Domain Routing) que estableció la gestión de subredes mediante el uso de la máscaras de red10.
Una red IP (o una subred) comprende un rango de direccionamiento IP. Cuando un equipo va a enviar un paquete a otro
equipo -identificado por su dirección IP- comprueba si la dirección del destinatario está en su misma subred. En caso de
ser así emite el mensaje dando por supuesto que el equipo destinatario será capaz de escucharlo (como debería ser si la
configuración es correcta y el otro equipo está operativo). Si el equipo destinatario está en otra red diferente a la del
remitente, éste enviará el mensaje a la puerta de enlace (gateway) que tenga configurada -si la tiene-.
Podemos apreciar que un equipo sin puerta de enlace solo será capaz de comunicarse con su propia subred, y que la
puerta de enlace de un equipo debe encontrarse en su misma subred.
Las cabeceras IP contienen las direcciones de las máquinas de origen y destino (direcciones IP), direcciones que serán
usadas por los conmutadores de paquetes (switches) y los encaminadores (routers) para decidir el tramo de red por el
que reenviarán los paquetes.
La configuración IP (dirección, máscara y pasarela) puede asignarse de manera estática (especificándose en cada
equipo) o dinámica, mediante DHCP (Dynamic Host Configuration Protocol). Puede generar confusión el que se suele
decir que un equipo tiene IP fija si siempre tiene la misma dirección IP y que tiene IP dinámica si su dirección IP varía
con el tiempo. Sin embargo puede asignarse siempre la misma dirección al mismo equipo dinámicamente por DHCP.
Fragmentación en v4
En IPv4 si el paquete a transmitir supera el tamaño máximo negociado (MTU: Maximum Transmission Unit) en el
tramo de red por el que va a circular, podrá ser dividido en paquetes más pequeños, y reensamblado luego cuando sea
necesario. Estos fragmentos podrán ir cada uno por un camino diferente dependiendo de la congestión de las rutas en
cada momento. Si uno de los fragmentos se pierde, todo el paquete original se considerará perdido, y los restantes
fragmentos se descartarán.
Esto puede ocurrir por ejemplo con los protocolos ICMP o UDP, pero no con el protocolo TCP que adapta su tamaño de
paquete para que no deba ser fragmentado. Para ello al inicio de la comunicación utiliza una técnica de tanteo enviando
paquetes IP con el bit "No fragmentar" activado para encontrar el tamaño de MTU adecuado11.
IP no establece un MTU máximo, pero sí establece un MTU mínimo de 576 bytes para v4 y 1280 bytes para v6 que no
permite fragmentación (solo en origen)12.
10 Máscaras de subred de tamaño variable (VLSM: Variable-Length Subnet Masks).

11 Para facilitar esto, los encaminadores actuales al recibir un paquete no fragmentable demasiado grande incluyen el MTU en el mensaje de error.
12 Nótese que la MTU de IPv6 es menor que la MTU de Ethernet (1518B), lo que permite que IPv6 se pueda encapsular sobre Ethernet sin
problemas.
Direccionamiento v4
Una dirección IP es un número que identifica de manera lógica y jerárquica a una interfaz de red (NIC). IPv4 utiliza un
direccionamiento de 4 bytes que permite aproximadamente 4.295 millones de direcciones (232), un número inadecuado
para dar una dirección a cada persona del planeta, y mucho menos para cada coche, teléfono, PDA o tostadora, lo que
obliga a usar direccionamientos privados y NAT; mientras que el direccionamiento de 16 bytes de IPv6 soporta
aproximadamente 340 sextillones de direcciones (2128) -aproximadamente 670 mil billones de direcciones por cada
mm2 de la superficie de La Tierra-.
En IPv4 las direcciones de 4 bytes (32 bits) se escriben en formato decimal punteado, es decir, 4 números decimales
separados por puntos, representando cada uno 8 bits. Por tanto cada número debe estar en el rango [0-255].
Por ejemplo: "127.0.0.1".
Rangos de direcciones IPv4 reservadas (Intranets)

Dado que no puede haber dos interfaces con la misma dirección IP, dichas direcciones las otorgan organismos y
entidades especialmente designadas, que delegan dicha autoridad jerárquicamente13. De este modo, los ISPs
(proveedores de Internet, Internet Services Provider) disponen de rangos de IP que pueden otorgar.
Cuando un equipo se conecta a Internet necesita una IP pública ya sea variable o fija, que le proporciona su ISP.
Existen rangos de direcciones IPv4 que no se utilizan en la red pública, sino que están reservadas para redes internas
("intranets") cuyos equipos no disponen de conexión directa a Internet. Al reutilizarse los mismo rangos en todas las
organizaciones todavía se consigue disponer de suficientes direcciones IP públicas para todos... aunque el límite ya casi
se ha alcanzado14. Al utilizar direccionamiento privado, si se conecta dicha red privada a Internet, la pasarela obtiene
una IP pública con la se conectan todos los equipos de la red privada utilizando una técnica llamada NAT (Network
Address Translation).
Los rangos de IP v4 reservados para intranets son:
● 1 rango clase A: 10.x.x.x
● 16 rangos clase B: 172.16.x-172.31.x
● 256 rangos clase C: 192.168.0.x-192.168.255.x
● 1 rango clase B para enlace local15: 169.254.x.x
Clases de direcciones IP v4
Originalmente existían cinco clases de direcciones IP, indicadas por el primer 0 de los 4 primeros bits, pero solo se
utilizan las tres primeras:
● Clase A: 7 bits de red || 24 bits de equipo (host), indicada por un 0 en el primer bit de dirección IP
0xxx xxxx.||xxxx xxxx.xxxx xxxx.xxxx xxxx (0.0.0.0-127.255.255.255)
● Clase B: 14 bits de red || 16 bits de equipo, indicada por un 0 en el segundo bit de dirección IP
10xx xxxx.xxxx xxxx.||xxxx xxxx.xxxx xxxx (128.0.0.0-191.255.255.255)
● Clase C: 21 bits de red || 8 bits de equipo, indicada por un 0 en el primer bit de dirección IP
110x xxxx.xxxx xxxx.xxxx xxxx.||xxxx xxxx (192.0.0.0-223.255.255.255)
● Clase D: Multicasting, no utilizable
1110 xxxx.xxxx xxxx.xxxx xxxx.xxxx xxxx (224.0.0.0-239.255.255.255)
● Clase E: Experimental, no utilizable
1111 xxxx.xxxx xxxx.xxxx xxxx.xxxx xxxx (240.0.0.0 - 255.255.255.255)
13 La autoridad superior es la IANA (Internet Assigned Numbers Authority) que en este momento es la organización ICANN. Después aparecen por
debajo los distintos ISPs (Internet Services Providers).
14 El principal objetivo de IPv6 es subsanar el agotamiento de direcciones IP disponibles. Además introduce optimizaciones en el protocolo.
15 Este sistema configura automáticamente una NIC asignando una IP aleatoria en el rango de enlace local tras verificar mediante ARP que está
disponible. No configura pasarela ni servidores DNS (por eso "enlace local"). Llamado por Microsoft APIPA (Automatic Private IP Addressing).
Máscara de red
Como ya se ha dicho, el sistema de clases de red de IP quedó pronto sobrepasado, por lo que la IETF estableció en 1993
el sistema CIDR (Classless Inter-Domain Routing) que eliminó el uso de clases de direcciones IP y estableció la gestión
de subredes mediante el uso de la máscaras de red. En IPv6 el concepto de clases se ha abandonado definitivamente.
Una máscara de red es un prefijo de n bits de valor '1' que se aplica sobre las direcciones IP y que se indica "/n". Así en
IPv4 una máscara puede tener hasta 32 bits y en IPv6 hasta 128 bits.
Para conocer si dos direcciones IPs se encuentran en la misma subred basta con realizar una operación binaria AND
entre la máscara y cada dirección; si el resultado es el mismo es que están en la misma red.
En IPv4 la máscara se puede especificar con la notación CIDR (/n) o con la misma notación que las direcciones IP.
Para IPv4 se definen tres clases de red básicas basadas en máscaras:
● Clase A: máscara de 8 bits (/8) o 255.0.0.0
● Clase B: máscara de 16 bits (/16) o 255.255.0.0
● Clase C: máscara de 24 bits (/24) o 255.255.255.0
Por ejemplo, dada la dirección IP 192.168.1.4 con máscara de 24 bits (/24 o 255.255.255.0).
La dirección en binario es: 1100 0000.1010 1000.0000 0001.0000 0100.
La máscara en binario es: 1111 1111.1111 1111.1111 1111.0000 0000.
Realizamos un AND binario entre dirección y máscara para obtener la red en la que se encuentra dicha dirección:
1100 0000.1010 1000.0000 0001.0000 0100 [192.168.1.4] IP
AND 1111 1111.1111 1111.1111 1111.0000 0000 [255.255.255.0] Máscara
--------------------------------------------------------------------
1100 0000.1010 1000.0000 0001.0000 0000 [192.168.1.0/24] RED
Para indicar la red de la dirección 192.168.1.4 con máscara de 24 bits puede escribirse en el formato CIDR como
192.168.1.0/24 y en el formato decimal punteado como 192.168.1.0/255.255.255.0.
Es fácil ver por tanto que dada una dirección IP a.b.c.d:

● La red de clase A (/8) estará formada por todas las direcciones a.x.x.x (red a.0.0.0/8)
● La red de clase B (/16) estará formada por todas las direcciones a.b.x.x (red a.b.0.0/16)
● La red de clase C (/24) estará formada por todas las direcciones a.b.c.x (red a.b.c.0/24)
Direccionamientos reservados
IPv4 contempla una serie de direcciones con significado especial y que por tanto no pueden utilizarse en interfaces de
red normales:
● 127.x.x.x -> loopback (p.e. 127.0.0.1)
● Todos los bits a 0 -> equipo local
● Todos los bits a 1 (255.255.255.255) -> todos los equipos (difusión, broadcast)
● Todos los bits de equipo a 1 -> todos los equipos de la red (difusión limitada, multicast)
● Todos los bits de red a 0 -> un equipo de la red local
Generación de Subredes
Cuando disponemos de redes grandes y complejas, es interesante crear subredes, lo que facilita su administración.
Para crear subredes modificamos las máscaras de red, incrementando la cantidad de bits a 1 de la máscara.
El número n de bits a 1 de la máscara nos proporciona la cantidad de subredes generadas (2n-2) y el número m de bits a
0 el número de equipos permitidos (2m-2).
Limitación
Se puede comprobar que en realidad se generan 2n subredes de 2m equipos, pero por las restricciones de
direccionamiento, solo podemos utilizar 2n-2 y 2m-2, ya que no se permiten las direcciones con todos los bits de red y/o
todos los bits de equipo (host) con el mismo valor (todos a 1 o todos a 0), ya que son direcciones especiales.
En concreto el octeto "1000 0000" (128) no se debe utilizar para crear subredes porque generaría dos subredes que no
se deben usar (todo 0 o todo 1 en el bit de red). Del mismo modo 255.255.255.254 es una máscara inútil porque solo
permite dos direcciones que no se pueden usar (todo 0 o todo 1 en el equipo).
Algunas implementaciones (llamadas "subnet-zero") sí utilizan esas dos subredes (y también la máscara 128), pero no
es una utilización correcta y en redes complejas puede generar problemas inesperados.
Tabla resumen de subredes

Bits Subred 1 / 7 * 2/6 3/5 4/4 5/3 6/2 7/1* 8/0*
/ Equipo sxxx xxxx ssxx xxxx sssx xxxx ssss xxxx ssss sxxx ssss ssxx ssss sssx ssss ssss
Subredes / 2 / 128 * 4 / 64 8 / 32 16 / 16 32 / 8 64 / 4 128 / 2 * 256 / 1 *

Rango sxxx xxxx ssxx xxxx sssx xxxx ssss xxxx ssss sxxx ssss ssxx ssss sssx ssss ssss
Máscara 128 * 192 224 240 248 252 254 * 255 *

1000 0000 1100 0000 1110 0000 1111 0000 1111 1000 1111 1100 1111 1110 1111 1111
Rangos [0] [2] [6] [14] [30] [62] [126] [254]

efectivos * Inútil 64-128 32-64-96- 16-32-48- 8-16-24- 4-8-12- 2-4-6-8- * Se pasa
(utilizables) 128-160-19 64-80-96- 32-40-48- 16-20-24- ... de una red
2 112-128-14 ... ... 250-252 a 254 redes
4- 200-208-21 232-236-24 *Inútil en de clase
160-176-19 6- 0- el último inferior.
2- 224-232-24 244-248 octeto de la
208-224 0 máscara
● En la primera fila vemos los bits de la máscara de red que dedicamos a crear subredes, marcados con 's', y los
bits que dedicamos a equipos, marcados con 'x' (p.e. en la tercera columna dedicamos 3 a subredes y 5 a
equipos sssx xxxx).
● En la segunda fila vemos el número de subredes creadas (2s) y el rango de equipos en cada subred (2x).
Recordemos que siempre hay dos subredes y dos equipos por subred que no son utilizables (todo 0 y todo 1).
● La tercera fila indica el valor decimal de la máscara. Se puede obtener para cada celda fácilmente sumando al
valor de la celda izquierda con el rango de la celda superior. P.e.: 128 + 64 = 192; 240 + 8 = 248 ...
● La cuarta fila nos indica los rangos efectivos (utilizables). Por ejemplo en la columna 3 -máscara 224-, si los
rangos son de 32 direcciones y no podemos usar ni el primer rango (todos los bits de red a 0) ni el último
(todos los bits de red a 1), los rangos resultantes serán 32-64-96-128-160-192.
● Nótese que en ningún caso se utilizan ni la primera ni la última subred (la que empieza en 0 y la que acaba en
255). La penúltima columna (máscara 254) no se puede utilizar en el último octeto (obtendríamos redes
inviables de 2 equipos).
Ejemplos de subredes
Ejemplo 1 con red tipo B:
Rango de direcciones: 172.16.x.x (máscara inicial /16 o 255.255.0.0)
Queremos crear 6 subredes -> Tomamos la máscara 255.255.224.0 (111|0 0000)
Cada subred tiene un rango de direcciones de 32*255 -2 (x xxxx): [32-64-96-128-160-192]
Rangos de direcciones IP obtenidos:
172.16. 32.1 - 172.16. 63.254 (001|0 0000.0000 0001 - 001|1 1111.1111 1110)
172.16. 64.1 - 172.16. 95.254 (010|0 0000.0000 0001 - 010|1 1111.1111 1110)
172.16. 96.1 - 172.16.127.254 (011|0 0000.0000 0001 - 011|1 1111.1111 1110)
172.16.128.1 - 172.16.159.254 (100|0 0000.0000 0001 - 100|1 1111.1111 1110)
172.16.160.1 - 172.16.191.254 (101|0 0000.0000 0001 - 101|1 1111.1111 1110)
172.16.192.1 - 172.16.223.254 (110|0 0000.0000 0001 - 110|1 1111.1111 1110)
Ejemplo 2 con red tipo A:

Rango de direcciones: 10.x.x.x (máscara inicial /8 o 255.0.0.0)
Cada subred tiene un rango de direcciones de 64*255*255 -2 (xx xxxx): [64-128-192]
10. 64.0.1 – 10.127.255.254 (01|00 0000.0000 0000.0000 0001 - 01|11 1111.1111 1111.1111 1110)
10.128.0.1 – 10.191.255.254 (10|00 0000.0000 0000.0000 0001 - 10|11 1111.1111 1111.1111 1110)

Queremos crear 14 subredes -> Tomamos la máscara 255.255.240.0 (1111| 0000)
Cada subred tiene un rango de direcciones de 16*255 -2 (xxxx):
[16-32-48-64-80-96-112-128-144-160-176-192-208-224-240]
172.18. 16.1 - 172.18. 31.254 (0001| 0000.0000 0000.0000 0001 - 0001| 1111.1111 1111.1111 1110)
172.18. 32.1 - 172.18. 47.254 (0010| 0000.0000 0000.0000 0001 - 0010| 1111.1111 1111.1111 1110)
172.18. 48.1 - 172.18. 63.254 (0011| 0000.0000 0000.0000 0001 - 0011| 1111.1111 1111.1111 1110)
172.18. 64.1 - 172.18. 79.254 (0100| 0000.0000 0000.0000 0001 - 0100| 1111.1111 1111.1111 1110)
172.18. 80.1 - 172.18. 95.254 (0101| 0000.0000 0000.0000 0001 - 0101| 1111.1111 1111.1111 1110)
172.18. 96.1 - 172.18.111.254 (0110| 0000.0000 0000.0000 0001 - 0110| 1111.1111 1111.1111 1110)
172.18.112.1 - 172.18.127.254 (0111| 0000.0000 0000.0000 0001 - 0111| 1111.1111 1111.1111 1110)
172.18.128.1 - 172.18.143.254 (1000| 0000.0000 0000.0000 0001 - 1000| 1111.1111 1111.1111 1110)
172.18.144.1 - 172.18.159.254 (1001| 0000.0000 0000.0000 0001 - 1001| 1111.1111 1111.1111 1110)
172.18.160.1 - 172.18.175.254 (1010| 0000.0000 0000.0000 0001 - 1010| 1111.1111 1111.1111 1110)
172.18.176.1 - 172.18.191.254 (1011| 0000.0000 0000.0000 0001 - 1011| 1111.1111 1111.1111 1110)
172.18.192.1 - 172.18.207.254 (1100| 0000.0000 0000.0000 0001 - 1100| 1111.1111 1111.1111 1110)
172.18.208.1 - 172.18.223.254 (1101| 0000.0000 0000.0000 0001 - 1101| 1111.1111 1111.1111 1110)
172.18.224.1 - 172.18.239.254 (1110| 0000.0000 0000.0000 0001 - 1110| 1111.1111 1111.1111 1110)
Ejemplo 4 con red tipo C:

Rango de direcciones: 192.168.2.x (máscara inicial /24 o 255.255.255.0)
Cada subred tiene un rango de direcciones de 32 -2 (x xxxx): [32-64-96-128-160-192-224]
ATENCIÓN: Como trabajamos con el último octeto debemos descontar las direcciones todo 0 y todo 1.
192.168.2. 33 - 192.168.2. 62 (001|0 0000.0000 0000.0000 0001 - 001|1 1111.1111 1111.1111 1110)
192.168.2. 65 - 192.168.2. 94 (010|0 0000.0000 0000.0000 0001 - 010|1 1111.1111 1111.1111 1110)
192.168.2. 97 - 192.168.2.126 (011|0 0000.0000 0000.0000 0001 - 011|1 1111.1111 1111.1111 1110)
192.168.2.128 - 192.168.2.158 (100|0 0000.0000 0000.0000 0001 - 100|1 1111.1111 1111.1111 1110)
192.168.2.161 - 192.168.2.190 (101|0 0000.0000 0000.0000 0001 - 101|1 1111.1111 1111.1111 1110)
192.168.2.193 - 192.168.2.222 (110|0 0000.0000 0000.0000 0001 - 110|1 1111.1111 1111.1111 1110)

Queremos crear 126 subredes -> Tomamos la máscara 255.255.254.0 (1111 111|0)
Cada subred tiene un rango de direcciones de 2*255 -2 (x): [2-4-6-8-10-12-...252]
172.16. 2.1 - 172.18. 3.254 (0000 001|0.0000 0000.0000 0001 - 0000 001|1.1111 1111.1111 1110)
172.16. 4.1 - 172.18. 5.254 (0000 010|0.0000 0000.0000 0001 - 0000 010|1.1111 1111.1111 1110)
172.16. 6.1 - 172.18. 7.254 (0000 011|0.0000 0000.0000 0001 - 0000 011|1.1111 1111.1111 1110)
[...]
172.16.248.1 - 172.18.249.254 (1111 100|0.0000 0000.0000 0001 - 1111 100|1.1111 1111.1111 1110)
172.16.250.1 - 172.18.251.254 (1111 101|0.0000 0000.0000 0001 - 1111 101|1.1111 1111.1111 1110)
172.16.252.1 - 172.18.253.254 (1111 110|0.0000 0000.0000 0001 - 1111 110|1.1111 1111.1111 1110)
Ejemplo de mezcla de subredes en una red tipo B:

Para una mayor flexibilidad, a veces se utilizan rangos de subredes distintos, cuidando que no se solapen.
Dada la complejidad de mantenimiento de este sistema no se recomienda su uso.

Combinando máscaras de 18, 19 y 21 bits podemos obtener 3 subredes de 8 equipos, 3 de 32 y 1 de 64:
/21 (255.255.248.0) 172.16. 8.1 - 172.16. 15.254
/21 (255.255.248.0) 172.16. 16.1 - 172.16. 23.254
/21 (255.255.248.0) 172.16. 24.1 - 172.16. 31.254
/19 (255.255.224.0) 172.16. 32.1 - 172.16. 63.254
/19 (255.255.224.0) 172.16. 64.1 - 172.16. 95.254
/19 (255.255.224.0) 172.16. 96.1 - 172.16.127.254
/18 (255.255.192.0) 172.16.128.1 - 172.16.191.254
Cabecera de trama de IPv4
0 4 8 16 19 31
Version Hdr. len. Type of Service Total Length

Identification Flags Fragment Offset
Time To Live Protocol Header Checksum
Source IP Address
Destination IP Address
Options & Padding
● Version: Versión del protocolo: v4.

● Hdr. Len.: Indica la longitud de la cabecera en palabras de 32 bits y, por tanto, dónde empiezan los datos. Esta
longitud es de 5 palabras (20 Bytes) más el campo "Opciones" si existe.
● Type Of Service: tipo de servicio de calidad solicitado (QoS).
● Total Length: longitud total del datagrama -cabecera y datos- en bytes.
● Identification: número del datagrama asignado por el emisor. Los fragmentos de un datagrama tendrán el
mismo número de identificación.
● Flags: 3 bits utilizados para el control de fragmentación.
○ bit 0 – reservado. Debe ser 0.
○ bit DF (Don't Fragment) – A 1 significa "no fragmentar".
○ bit MF (More Fragments) - 0 indica que es el último o único fragmento y 1 que hay más fragmentos.
● Fragment Offset (FO): se usa en datagramas fragmentados. Indica el número de partes de datos de 64 bits
contenidas en fragmentos anteriores. En el primer (o único) fragmento el valor es cero.
● Time To Live (TTL): indica un tiempo en segundos -especificado por el protocolo de alto nivel que genera el
datagrama- tras el cual se debe descartar el paquete -timeout del protocolo superior-. Cada encaminador
actualiza el campo restando su tiempo de proceso. Como los encaminadores tardan menos de un segundo en
procesar un paquete se convierte en una cuenta de saltos.
● Protocol: número oficial del protocolo de alto nivel al que IP debe entregar los datos.
● Header Checksum: código de control de la cabecera16. Si no es correcto se desecha el datagrama.
● Source IP Address: dirección IP del equipo emisor.
● Destination IP Address: dirección IP del equipo receptor.
● Options & Padding (Opciones y relleno): este es un campo opcional de longitud variable para pruebas de red
o depuración. No se requiere que las implementaciones de IP puedan generar las opciones, pero sí que puedan
procesar los datagramas que contienen opciones saltando las opciones, gracias a que conocen la longitud de la
cabecera. Esto hace que la longitud de las opciones deba ser múltiplo de 32bits, utilizándose bits de relleno si
es necesario.
16 Se calcula como el complemento a uno de la suma de los complementos a uno de todas las palabras de 16 bits de la cabecera.
Direccionamiento v6
IPv6 utiliza un direccionamiento de 16 bytes. Las direcciones se escriben mediante 8 grupos de 2 bytes cada uno,
escritos mediante 4 cifras hexadecimales y separados por el símbolo ":".
En muchas ocasiones las direcciones IPv6 están compuestas por dos partes lógicas: un prefijo de 8 bytes (16 cifras
hexadecimales) y otra parte de 8 bytes que corresponde al identificador de interfaz. En el caso de Ethernet este
identificador se genera automáticamente a partir de su dirección MAC -6 bytes-, insertando dos bytes (0xFFFF) entre
los 3 bytes que identifican al fabricante y los otros 3 bytes.
Las direcciones IPv4 pueden ser transformadas fácilmente al formato IPv6. Por ejemplo, si la dirección decimal IPv4 es
135.75.43.52 (en hexadecimal, 0x874B2B34), puede ser convertida a 0000:0000:0000:0000:0000:0000:874B:2B34 con
máscara de 96 bits, o ::874B:2B34/9617 lo que se conoce como dirección “IPv4 compatible”.
Se puede utilizar una notación mixta, que siguiendo el ejemplo quedaría como ::135.75.43.52. Este tipo de dirección
IPv4 compatible casi no está siendo utilizada en la práctica, aunque los estándares no la han declarado obsoleta.
Representación de direcciones IPv6

Algunas reglas acerca de la representación de direcciones IPv6 son:
– Los ceros iniciales, como en IPv4, se pueden obviar.
Ejemplo: 2001:0123:0004:00ab:0cde:3403:0001:0063 -> 2001:123:4:ab:cde:3403:1:63
– Los bloques contiguos de ceros se pueden comprimir empleando "::". Esta operación sólo se puede hacer una vez.
Ejemplo válido: 2001:0:0:0:0:0:0:4 -> 2001::4
Ejemplo no válido: 2001:0:0:0:2:0:0:1 -> 2001::2::1 (debería ser 2001::2:0:0:1 o 2001:0:0:0:2::1)
– Si la dirección es una dirección IPv4 “camuflada” o “mapeada”, los últimos 32 bits pueden escribirse en base
decimal; así:
::ffff:192.168.89.9 es lo mismo que
::ffff:c0a8:5909 pero no lo mismo que
::192.168.89.9 (IPv4 compatible) o
::c0a8:5909 (IPv4 compatible)
El formato ::ffff:1.2.3.4 se denomina dirección IPv4 mapeada, y el formato ::1.2.3.4 dirección IPv4 compatible.
Tipos de direcciones IPv6

Los tipos de direcciones IPv6 pueden identificarse tomando en cuenta los primeros bits de cada dirección.
● :: /128 – Dirección indefinida -todo ceros, máscara de 128 bits- se utiliza para indicar la ausencia de dirección,
y no se asigna a ningún nodo.
● ::1 /128 – Dirección de loopback es una dirección que puede usar un nodo para enviarse paquetes a sí mismo.
No puede asignarse a ninguna interfaz física.
● :: /96 – (La máscara cubre toda la dirección excepto los últimos 4 bytes) Dirección IPv4 compatible se usa
como un mecanismo de transición en las redes duales IPv4/IPv6. Es un mecanismo obsoleto.
● ::ffff:0:0 /96 – Dirección IPv4 mapeada es usada como un mecanismo de transición en redes duales.
● fe80:: /10 – Prefijo de enlace local específica que la dirección sólo es válida en el enlace físico local.
● fec0:: /10 – Prefijo de emplazamiento local específica que la dirección sólo es válida dentro de una
organización. Declarado obsoleto (RFC 1918).
● ff00:: /8 – Prefijo de difusión (multicast).
● ff01::1 – Funcionalidad de "todos los nodos" (broadcast) utilizando difusión (multicast).
17 Nótese que la máscara cubre los 0's iniciales.
Sistema de Nombres de Dominio (DNS) en IPv6

Al diseñarse IPv6 se realizaron dos propuestas para el sistema de nombres de dominio, una basada en registros AAAA
(quad-A) y otra basada en registros A6. Mientras que la idea de quad-A es una simple generalización del DNS IPv4, la
idea de A6 es una revisión y puesta a punto del DNS para ser más genérico incluyendo otras innovaciones como las
etiquetas de cadena de bits (bit-string labels) y los registros DNAME, de ahí su complejidad.
El RFC 3363 recomienda utilizar registros AAAA mientras se prueba y estudia exhaustivamente el uso de registros A6.
El RFC 3364 realiza una comparación de las ventajas y desventajas de cada tipo de registro.
Cabecera de trama de IPv6
0 4 12 32 48 56 63
Vers. Traffic Class Flow Label Payload Length Next Header Hop Limit
Source Address
(128 bits)
Destination Address
(128 bits)
El campo Longitud ya no es necesario, ya que la cabecera de IPv6 siempre tiene 40 bytes. Tampoco se realiza una suma
de integridad de la cabecera.
● Version: Versión del protocolo: v6.

● Traffic Class: Equivale a "Type of Service". Indica la clase de tráfico para la gestión de QoS.
● Flow Label: Todos los paquetes pertenecientes al mismo flujo tienen el mismo valor de FL, haciendo que sea
reconocible sin necesidad de estudiar el contenido del paquete. Esto puede ser útil para QoS, encaminamiento,
filtros...
● Payload Length: Longitud de los datos transmitidos del paquete.
● Next Header: Indica el tipo de cabecera de los datos transportados.
● Hop Limit: Equivale a Time to Live (TTL). Indica un número de saltos -especificado por el protocolo de alto
nivel que genera el datagrama- tras el cual se debe descartar el paquete.
● Source IP Address: dirección IP del equipo emisor.
● Destination IP Address: dirección IP del equipo receptor.
IPSec
Los protocolos de IPSec se definieron originalmente en las RFCs 1825 y 1829, publicadas en 1995. IPSec es obligatorio
en IPv6 y opcional en IPv4. El objetivo principal de IPSec es proporcionar protección a los paquetes IP.
IPSec establece comunicaciones IP con seguridad de extremo a extremo, lo que significa que los nodos intermedios
utilizan el protocolo IP, sin necesidad de una implementación específica para IPSec.
Antes de iniciar el envío de datos, IPSec realiza una autenticación de los extremos y negocia los parámetros de la
comunicación. Durante la comunicación utiliza ISAKMP (Internet Security Association and Key Management
Protocol) para realizar cambios dinámicos de las claves.
Para la comunicación IPSec permite utilizar dos protocolos diferentes: AH (Authentication Header) y ESP
(Encapsulation Security Payload). El protocolo AH permite únicamente verificar la integridad del paquete (mediante
firma). El protocolo ESP permite cifrar la información (DES, 3DES...) y opcionalmente verificar la integridad del
paquete.
Los protocolos de IPSec actúan en la capa de red, la capa 3 del modelo OSI. Otros protocolos de seguridad para Internet
de uso extendido, como SSL, TLS y SSH operan en la capa de transporte o por encima (capas OSI 4 a 7). Esto hace que
IPSec sea más flexible, ya que puede ser utilizado para proteger protocolos de la capa 4, incluyendo TCP y UDP, los
protocolos de capa de transporte más usados. Así para que una aplicación pueda usar IPSec no es necesario modificarla,
mientras que para usar SSL y otros protocolos de niveles superiores sí.
Hay dos modos de operación de IPSec: modo transporte y modo túnel.

● Modo transporte: El modo transporte permite que dos equipos se comuniquen entre ellos utilizando IPSec
igual que utilizarían IP pero firmando y/o cifrando los datos que se transfieren (la carga útil del paquete IP).
Este sistema añade poca sobrecarga de bytes y permite a los dispositivos de la red conocer el origen y el
destino del paquete, lo que puede ser necesario para algunos servicios como QoS.
El sistema de encaminamiento no varía respecto a IP, ya que no se modifica ni se cifra la cabecera IP; sin
embargo, cuando se utiliza integridad con AH -que firma la cabecera IP-, las direcciones IP no pueden ser
traducidas (p.e. con NAT), ya que eso invalidaría la firma del paquete (hash). Para encapsular mensajes IPSec
a través de NAT se usa NAT Transversal (NAT-T).
● Modo túnel: En el modo túnel dos equipos establecen un canal de comunicación por el que otros equipos o
procesos envían información. Es decir el emisor y el receptor originales siguen enviando y recibiendo sus
datos sin cifrar ni firmar mediante las pasarelas del túnel IPSec (IPSec Proxy), que se encargan de cifrar y/o
firmar todo el paquete IP original que debe ser encapsulado en un nuevo paquete IP.
El modo túnel se utiliza para comunicaciones red a red (túneles seguros entre encaminadores, p.e. para VPNs)
o comunicaciones ordenador a red u ordenador a ordenador sobre Internet.
Modo Transporte Modo Túnel

Protocolo Firmado (Opcional) Firmado (Opcional)
ESP Cifrado Cifrado
IP ESP TCP/UDP DATA ESP ESP New ESP Orig. IP TCP/UDP DATA ESP ESP
Header Header Header Trailer Auh IP Header Header Header Trailer Auh
Header
Protocolo Firmado Firmado

AH IP Auth TCP/UDP DATA New IP Auth Orig. IP TCP/UDP DATA
Header Header Header Header Header Header Header
IPSec no define unos algoritmos específicos de cifrado sino que mediante ISAKMP permite utilizar IKE (Internet Key
Exchange) para realizar un autonegociado del algoritmo a utilizar y del intercambio de claves. IKE funciona sobre UDP
y aporta escalabilidad y flexibilidad ya que permite utilizar algoritmos de varios tipos:
– Claves Pre-Compartidas (PSK: Pre-Shared Key). Su mayor inconveniente es la distribución de la PSK.
– Kerberos.
– Criptografía de clave pública-privada.
– Certificados digitales.
El principal problema de IKE viene de que, aunque es un estándar abierto, la norma es admite distintas interpretaciones,
lo que ha dado lugar a implementaciones ligeramente incompatibles. Este es uno de los motivos por el que se están
imponiendo las VPNs sobre SSL. Actualmente está en desarrollo IKE v2.
3.4. Otros protocolos de la familia Internet

ARP y RARP
El protocolo ARP (Address Resolution Protocol) es el método estándar para obtener la dirección “física” (nivel 2 -de
enlace-) de una NIC cuando únicamente se conoce su dirección “lógica” (nivel 3 -de red-). Una vez obtenida se guarda
temporalmente la información en una tabla (tablas caché ARP) para reducir el número de consultas.
No es un protocolo de uso exclusivo con IP, aunque dada la gran implantación de dicho protocolo y de Ethernet, se
utiliza principalmente para asociar una dirección IP a una dirección MAC de Ethernet. También se utiliza ampliamente
con IP sobre otras tecnologías LAN como Token Ring, FDDI, IEEE 802.11 (Wi-Fi) o ATM.
Existe un protocolo, RARP (Reverse ARP), cuya función es la inversa.
ICMP e IGMP
ICMP (Internet Control Messaging Protocol) es parte fundamental y complementaria de IP y es empleado por éste para
notificar mensajes de error o situaciones que requieren cierta atención. Debido a que los paquetes ICMP viajan en
paquetes IP es a veces considerado un nivel por encima.
Los distintos mensajes ICMP posibles utilizan un identificador numérico, que en el caso de los mensajes de error es
menor que 128. ICMP también permite adquirir información mediante pares de paquetes petición / respuesta, por
ejemplo, para adquirir la máscara de red de un sistema o el valor de su reloj (timestamps). Por último, en numerosas
ocasiones se emplea para comprobar la existencia de conectividad, como en la utilidad “ping”, empleando paquetes
ICMP “echo” (id. 128) y “echo reply” (id. 129).
Los mensajes de error de ICMP se generan cuando el destinatario o un encaminador no puede procesar un paquete IP e
incluyen la cabecera del paquete IP que ha generado el error y los primeros 8 bytes del contenido del mismo, lo que es
suficiente en TCP para conocer la comunicación que originó el paquete erróneo -recordemos que IP no garantiza la
recepción de paquetes-.
Como IPv6 está diseñado para poder soportar múltiples protocolos de transporte, ICMPv6 incluye el inicio del paquete
IP fallido original (incluyendo la cabecera) hasta generar un paquete de error de 1280 bytes, que es el MTU mínimo
admitido por IPv6.
IGMP (Internet Group Management Protocol) se utiliza para informar a los encaminadores de la pertenencia de un
equipo a un grupo de multicast. Es análogo a ICMP pero para conexiones multicast en vez de unicast. IGMP se puede
usar para transmisión de vídeo, para juegos... Es un protocolo vulnerable, poco utilizado y opcional (mientras que ICMP
es requerido por IAB) por lo que algunos cortafuegos lo bloquean opcionalmente.
TCP
TCP (Transmission Control Protocol) es el protocolo de transporte empleado actualmente por la mayoría de los
protocolos de aplicaciones en Internet. Utiliza un esquema de circuito virtual para establecer un flujo de bytes sobre IP.
El protocolo TCP utiliza la técnica de ventana deslizante -pudiéndose cambiar el tamaño de la ventana durante la
comunicación- y la técnica de "piggybacking" es decir, incluye en la transmisión de paquetes, la confirmación de
recepción de paquetes. Así un equipo que reciba correctamente los bytes 1, 3 y 4, emitirá el reconocimiento del byte 1
(ACK 1). Cuando reciba correctamente el 2 emitirá ACK 4, indicando que ha recibido correctamente hasta el byte 418.
Para permitir múltiples conexiones entre equipos e identificar a los destinatarios y remitentes de manera sencilla, TCP
multiplexa las direcciones IP utilizando "puertos". Así una conexión TCP se identifica como:
<TCP, IP_local.Puerto_local, IP_destino.Puerto_destino>.
18 Dado que emisor y receptor han acordado un tamaño de ventana, el emisor no envía más bytes de los que puede almacenar el receptor.
Antes de comenzar la transmisión de datos, se debe establecer una conexión haciendo que los nodos reserven recursos y
estableciendo parámetros como el tamaño de los mensajes (MTU del circuito virtual) o la ventana de transmisión. Una
conexión TCP se establece en tres pasos (three-way handshake):
1. El equipo que inicia la conexión envía al destinatario un paquete de sincronización “SYN” con el número de
secuencia inicial elegido para esta conexión19 y el tamaño de ventana;
2. éste le responde con un paquete de reconocimiento “SYN-ACK”, confirmándole la recepción de su número
inicial (ACK) y enviándole un número propio inicial de secuencia (SYN);
3. el equipo que ha iniciado la conexión reconoce la recepción de la señal “SYN-ACK” mediante una señal
“ACK”. En este momento la conexión se ha establecido y puede tener lugar toda la transferencia de datos.
De igual modo, la finalización de la conexión se lleva a cabo mediante el intercambio de un par de paquetes TCP por
parte de cada equipo: un paquete “FIN” y un paquete “ACK”. Esto puede llevarse a cabo en 4 pasos (FIN-ACK-FIN-
ACK) o en tres pasos (FIN-FIN&ACK-ACK). Algunas implementaciones permiten finalizar en dos pasos o cerrar solo
un lado de la comunicación...
Si bien una vez establecida la comunicación, TCP envía los bytes agrupados en conjuntos llamados "segmentos", el
control de la transmisión, incluyendo la cuenta de envíos ("Sequence Number") o las recepciones correctas
("Acknowledgment Number"), se hace en base a bytes no a paquetes o segmentos.
Las aplicaciones que utilizan TCP pueden invocar a la función "Push" para solicitar que se envíe un segmento sin
esperar nuevos bytes para incluir en él20. De manera similar la función "Urgent" solicita que los nuevos bytes añadidos
al segmento se traten antes que los que ya estén en él esperando su envío21.
Cabecera de trama de TCP
0 4 10 16 31
Source Port Destination Port

Sequence Number
Acknowledgment Number
Dat. Offset Reserved Flags Window
Checksum Urgent Pointer
Options & Padding
● Source Port: Número de puerto de 16 bits del emisor, que el receptor debe usar para responder.
● Destination Port: Número de puerto de 16 bits del receptor.
● Sequence Number: Número de secuencia del primer byte de datos del segmento enviado en el paquete. Si el
byte de control SYN está a 1, el número de secuencia es el inicial y el primer byte de datos será el n+1.
● Acknowledgment Number: Contiene el valor del último byte recibido correctamente. Este número implica
que todos los bytes anteriores han sido recibidos correctamente ("reconocidos").
● Data Offset: Indica la longitud de la cabecera en palabras de 32 bits y, por tanto, dónde empiezan los datos.
Esta longitud es de 5 palabras (20 Bytes) más el campo "Opciones" si existe.
● Reserved: bits reservados para un uso futuro; deben ser cero.
● Flags: 6 bits utilizados para el control de la conexión
○ URG (Urgent): Indica al receptor que los primeros bytes en tratar sean los bytes urgentes, cuyo inicio se
indica en el campo "urgent pointer".
○ ACK (Acknowledge): Indica que el campo de reconocimiento es significativo en el segmento.
○ PSH (Push): Indica que se ha solicitado la función "Push".
○ RST (Reset): Reinicia la conexión porque el puerto destino no está en uso o el número de secuencia no se
puede usar.
19 El número de secuencia inicial se elige de manera pseudoaleatoria para que no se pueda mezclar con otra comunicación por error.
20 Por ejemplo en una conexión telnet con eco remoto, al pulsar "Intro" se envía la información con "Push".
21 Por ejemplo en una conexión telnet, al pulsar Ctrl-C se envía como "Urgent".
○ SYN (Syncro.): Indica si el número de secuencia es el inicial.

○ FIN: Indica que el emisor desea terminar la comunicación.
● Window: Establece un nuevo tamaño de la ventana de bytes para la comunicación.
● Checksum: código de control de la cabecera22. Si no es correcto se desecha el paquete.
● Urgent Pointer: Apunta al primer byte de datos urgentes.
● Options & Padding (Opciones y relleno): este es un campo opcional de longitud variable para pruebas de red
o depuración. No se requiere que las implementaciones de TCP puedan generar las opciones, pero sí que
puedan procesar los segmentos que contienen opciones saltando las opciones, gracias a que conocen la
longitud de la cabecera. Esto hace que la longitud de las opciones deba ser múltiplo de 32bits, utilizándose bits
de relleno si es necesario.
UDP
UDP (User Datagram Protocol) es un protocolo que utiliza un esquema de datagramas sobre IP. UDP no garantiza la
comunicación, es decir, los paquetes pueden no llegar, llegar correctamente, duplicados o fuera de orden. Al evitar esas
comprobaciones y su sobrecarga (overhead) el protocolo UDP es más sencillo, rápido y eficiente que TCP, pero solo
sirve para aplicaciones que no necesiten garantías en la comunicación. Esto es muy práctico en aplicaciones en que es
más importante la velocidad de transmisión (como comunicación de audio y vídeo: IPTV, VoIP, juegos en línea) o en
aplicaciones servidoras sin estado que deben responder pequeñas consultas de un gran número de clientes (como DNS).
A diferencia de TCP, UDP permite paquetes de difusión (broadcast y multicast).
Cabecera de trama de UDP
0 16 31
Source Port Destination Port

Length Checksum
La cabecera de trama de UDP únicamente indica puertos de origen y destino, longitud del datagrama -incluyendo la
cabecera- y un código de control del paquete23.
22 Para este código se utiliza el complemento a uno de 16 bits de la suma en complemento a uno del paquete con una pseudo cabecera IP "virtual".
23 Se calcula igual que en TCP.
Puertos de aplicaciones basadas en TCP/UDP
A continuación se indican algunos de los principales protocolos de aplicaciones y sus puertos habituales asociados24.
Puerto Protocol. Descripción
7 tcp y udp Echo - Responde con eco a llamadas remotas
20-21 tcp FTP (File Transfer Protocol) - Transferencia de Ficheros [datos (20) y control (21)]
22 tcp SSH, SCP, SFTP - Juego de protocolos de comunicación segura
23 tcp Telnet - Protocolo de comunicación de inseguro
25 tcp SMTP (Simple Mail Transfer Protocol) - Transferencia Simple de Correo
53 tcp y udp DNS (Domain Name System) - Sistema de Nombres de Dominio
67-68 udp BOOTP (Server-Client) / DHCP (Dynamic Host Configuration Protocol)
80 tcp HTTP (HyperText Transfer Protocol) - Transferencia de HiperTexto (web)
88 tcp Kerberos - Agente de autenticación
110 tcp POP3 (Post Office Protocol 3) - Correo-e
123 tcp y udp NTP - Protocolo de sincronización de tiempo
135 tcp RPC (Remote Procedure Call)
137-139 tcp y udp NetBIOS Servicio de nombres [nombres (137), datagramas (138), sesiones (139)]
143 tcp IMAP4 (Internet Message Access Protocol 4) - Correo-e
161-162 tcp y udp SNMP - Gestión Simple de Red [consultas (161) y señales (162)]
389 tcp y udp LDAP - Protocolo de acceso ligero a Bases de Datos
443 tcp HTTPS/SSL – HTTP sobre una capa SSL
631 tcp CUPS - Sistema de impresión Unix
636 tcp LDAPs – LDAP sobre SSL
993 tcp IMAP4 sobre SSL
995 tcp POP3 sobre SSL
1433-1434 tcp Microsoft-SQL (Server-Monitor)
1512 tcp WINS
1521 tcp Oracle listener (por defecto)
1701 udp Enrutamiento y Acceso Remoto para VPN con L2TP.
1723 tcp Enrutamiento y Acceso Remoto para VPN con PPTP.
2049 tcp NFS - Archivos del sistema de red
3128 tcp Servidores intermediarios de HTTP, como Squid
3306 tcp MySQL sistema de gestión de bases de datos
3389 tcp RDP (Remote Desktop Protocol)
5060 udp Session Initiation Protocol (SIP)
5432 tcp PostgreSQL sistema de gestión de bases de datos
10000 tcp Webmin (Administración remota web)
24 Puertos reservados [0-1.023]; Puertos registrados [1.024-49.151]; Puertos dinámicos [49.152-62.535].
Redes de comunicaciones 4. ETHERNET
4. ETHERNET
4.1. Un poco de historia
En 1970 Robert Metcalfe, recién graduado en el MIT, se encontraba realizando sus estudios de doctorado en la
Universidad de Harvard trabajando para ARPANET. Encontró un artículo de Norm Abramson en el que describía la red
Aloha en Hawaii y pensó que podía mejorarlo. Escribió un artículo que se convertiría en su tesis doctoral, presentada en
1973, con un idea básica simple: las estaciones antes de transmitir deberían detectar si el canal ya estaba en uso (es
decir si ya había 'portadora'), en cuyo caso esperarían a que la estación activa terminara. Además cada estación,
mientras transmitiera, estaría continuamente vigilando el medio físico por si se producía alguna colisión, en cuyo caso
se pararía y retransmitiría más tarde. Este protocolo MAC recibiría más tarde la denominación Acceso Múltiple con
Detección de Portadora y Detección de Colisiones, o más brevemente CSMA/CD (Carrier Sense Multiple Access /
Colision Detect).
En 1972 Metcalfe se mudó a California para trabajar en el Centro de Investigación de Xerox en Palo Alto llamado
Xerox PARC (Palo Alto Research Center). Allí se estaba diseñando lo que se consideraba la 'oficina del futuro', con las
primeras impresoras láser y computadoras Alto, que ya disponían de capacidades gráficas y ratón y fueron consideradas
las primeras computadoras personales... Se quería conectar las computadoras entre sí para compartir ficheros y con las
impresoras y Metcalfe tenía la tarea de diseñar y construir la red que debía ser de muy alta velocidad, del orden de
megabits por segundo. Contaba para ello con la ayuda de un estudiante de doctorado de Stanford llamado David Boggs.
El 22 de mayo de 1973 Metcalfe escribió un memorándum interno en el

que informaba de la nueva red. En principio la red se llamaba Alto
Aloha Network, pero para evitar que se pudiera pensar que sólo servía
para conectar computadoras Alto se cambió el nombre de la red por el
de Ethernet (en alusión al éter como portador de ondas en el espacio).
Las dos computadoras Alto utilizadas para las primeras pruebas de
Ethernet (11 noviembre de 1973) fueron rebautizadas con los nombres
Michelson y Morley, en alusión a los dos físicos que habían demostrado
en 1887 la inexistencia del éter.
Diagrama de Ethernet realizado por Metcalfe
La red de 1973 ya tenía todas las características esenciales de la
Ethernet actual. Empleaba CSMA/CD para minimizar la probabilidad de colisión, y en caso de que ésta se produjera
utilizaba un mecanismo denominado retroceso exponencial binario para reducir gradualmente la ‘agresividad’ del
emisor, con lo que éste se adaptaba a situaciones de muy diverso nivel de tráfico. Tenía topología de bus y funcionaba a
2,94 Mb/s sobre un segmento de cable coaxial de 1,6 Km de longitud. Las direcciones eran de 8 bits y el CRC de las
tramas de 16 bits. El protocolo utilizado a nivel de red era el PUP (Parc Universal Packet) que luego evolucionaría
hasta convertirse en el que luego fue XNS (Xerox Network System), antecesor a su vez de IPX (Protocolo Netware de
Novell).
En vez de utilizar el cable coaxial de 75 ohms de las redes de televisión por cable se optó por emplear cable de 50 ohms
que producía menos reflexiones de la señal, a las cuales Ethernet era muy sensible por transmitir la señal en banda base
(es decir sin modulación). Cada empalme del cable y cada 'pincho' vampiro (transceptor o transceiver) instalado
producía la reflexión de una parte de la señal transmitida. En la práctica el número máximo de transceptores, y por tanto
el número máximo de estaciones en un segmento de cable coaxial, venía limitado por la máxima intensidad de señal
reflejada tolerable.
En 1975 Metcalfe y Boggs describieron Ethernet en un artículo que se publicó en 1976 (en “Communications of the
ACM”). En él ya describían el uso de repetidores para aumentar el alcance de la red. Ese mismo año Boggs construyó el
primer encaminador. En 1977 Metcalfe, Boggs y otros dos ingenieros de Xerox recibieron una patente por la tecnología
básica de Ethernet, y en 1978 Metcalfe y Boggs recibieron otra por el repetidor. En esta época todo el sistema Ethernet
era propietario de Xerox25. En 1979 Metcalfe dejó Xerox y fundó 3Com.
25 Xerox se juntó con DEC e Intel para fundar DIX y promocionar el uso de Ethernet. Publicaron la versión 1.0 en el Libro Azul de Ethernet (1980).
La licencia costaba $1000 anuales por cada rango de 24 bits de direcciones MAC (hoy controlado por el IEEEE a un precio similar).
4.2. Definición
Ethernet es un protocolo de nivel de enlace (N2) para redes de área local (LAN) basado en datagramas y definido en el
estándar IEEE 802.326, de comunicaciones entre iguales (PTP o P2P: peer to peer) en el que no hay un control
centralizado y todas las estaciones son tratadas por igual.
El protocolo original se basa en una topología de bus con medio compartido, es decir, varias estaciones que pueden
enviar datos al mismo tiempo. Por tanto se debe arbitrar un mecanismo de control de acceso al medio y resolver los
problemas que conllevan los accesos simultáneos (colisiones). Las nuevas versiones se basan en comunicaciones full-
duplex sobre canales independientes, por lo que no pueden existir las colisiones.
Una vez una estación consigue enviar sus datos sin colisiones, supone un medio físico altamente fiable, por lo que no
implementa confirmación de entrega de datos en destino. Si hay perdida de datos en el camino deben detectarla los
niveles superiores. Esto hace que cuando realmente se pierdan datos en este nivel, las aplicaciones se vean bastante
perjudicadas.
4.3. Control de colisiones

El mecanismo de control de colisiones de Ethernet es el CSMA/CD (Carrier Sense Multiple Access/Colision Detect) y
se basa en escuchar si el medio está libre para empezar a transmitir y asegurarse que la señal transmitida no es alterada
por otra señal. Una vez comprobado que el medio esta libre únicamente hay que dejar pasar un tiempo equivalente a 12
bytes antes de comenzar a transmitir. Esta pausa sirve para evitar que los datos transmitidos se concatenen con otra
trama en la red y para dar tiempo a las estaciones a procesar una posible trama recibida y que vuelvan a la escucha.
Cuando dos estaciones transmiten a la vez se produce una "colisión" que supone una alteración de las señales enviadas.
Esta alteración es detectada por las dos estaciones emisoras, que actúan de la siguiente manera:
1. Detienen la transmisión de la trama.
2. Envían una señal de atasco (Jam) durante el tiempo equivalente a 4 Bytes para que todas las estaciones se
enteren de que ha habido colisión.
3. Ponen en marcha el mecanismo de retroceso exponencial binario27 para decidir cuanto tiempo esperan a
retransmitir. Ese tiempo será aleatorio para evitar que las dos esperaren el mismo tiempo y vuelvan a
colisionar.
4. Transcurrido ese tiempo, si el medio esta libre, vuelven a intentar emitir.
Todas las estaciones que comparten el medio físico forman un dominio de colisión. Una estación compite por el medio
con todas las de su dominio de colisión. No solo con las que estén en su mismo cable, también con las que estén al otro
lado de repetidores y concentradores (hubs), pero no con las que estén al otro lado de puentes (bridges), conmutadores
(switchs) o encaminadores (routers).
El diámetro de un dominio de colisión es la distancia máxima entre estaciones. Esta distancia debe ser lo
suficientemente pequeña para que en el tiempo que tarda en ir y volver la señal de un extremo a otro no se pueda
transmitir una trama de tamaño mínimo T (2τ propagación en el diámetro máximo < τ transmisión de T).
26 En general, los protocolos de la rama IEEE 802.x definen la tecnología de redes de área local. ISO los define como ISO 8802x.
27 Cada vez que hay una colisión la estación espera entre 0 y 2i -1 veces el tiempo 2τ, siendo 'i' la iteración del algoritmo.
4.4. Direccionamiento
Cada nodo tiene una dirección de nivel 2 única, llamada dirección MAC (Medium Access Control). Esta dirección tiene
48 bits (6 bytes) y se suele representar con 12 caracteres hexadecimales separados por ":" o por "-" entre cada dos.
Las direcciones son asignadas por los fabricantes, que se identifican por los primeros 24 bits28.
Una trama puede ir dirigida a:

● Una estación concreta (unicast). Lleva como dirección de destino la dirección MAC de la estación de destino.
● Todas las estaciones de su red (difusión o broadcast). Lleva como dirección de destino la dirección de difusión
-todos los bits a uno- (FF:FF:FF:FF:FF:FF).
● Un grupo de estaciones que comparten una dirección especial (multicast). Estas direcciones especiales tienen
un 1 en el ultimo bit de su primer byte. Típicamente, son de la forma 01:xx:xx:xx:xx:xx.
4.5. Formato de trama

La trama en Ethernet puede tener entre 64 y 1518 bytes y tiene el siguiente formato:
Preámbulo Inicio (SoF) Dir. Destino Dir. Origen Tipo / Long. Datos Relleno CRC32 (Pausa)
7 1 6 6 2 0 – 1500 0 – 46 4 (12)
Donde:
➢ Preámbulo: Secuencia de 7 bytes 10101010 para estabilizar el medio.
➢ Inicio (Start of Frame): Byte 10101011 que indica que se va a iniciar la transmisión.
● Dir. Destino: es la dirección de destino.
● Dir. Origen: es la dirección de origen.
● Tipo/Long: es interpretado como:
○ Tipo de protocolo de nivel 3, si su valor es mayor de 1536 (formato original DIX29).
○ Longitud de la trama, si es menor que 1536 (formato IEEE 802.3).
● Datos: son los datos que lleva la trama.
● Relleno: existirá si no hay suficientes datos para que la trama tenga al menos 64 bytes.
● CRC32: es un código de redundancia cíclico para comprobar que no ha habido errores.
➢ El final de la trama se detecta por el hueco equivalente a 12 bytes que todas las estaciones deben respetar. Es
decir tras cada trama el emisor hace una pausa por el tiempo equivalente a enviar 12 bytes.
En función del protocolo de nivel 3 que se utilice, dentro de los datos puede haber una cabecera LLC (Logical Link
Control) para resolver a qué protocolo se le entrega la trama. Por ejemplo NetBEUI lo utiliza pero IP no.
El tamaño máximo de trama condiciona la cantidad de memoria que debe tener la interfaz de red.
En el caso de Gigabit Ethernet si se mantuviese una trama mínima de 64B, el diámetro del dominio de colisión sería de
~45m. Por ello mientras viajan por Gigabit las tramas deben tener un mínimo de 512B (diámetro ~330m), añadiéndose
en caso necesario un relleno conocido como extensión de portadora que se elimina si la trama deja la red Gigabit.
Sin embargo el uso de extensión de portadora supone por un lado mayor proporción de datos enviados/colisiones30 y por
otro lado pérdida de eficiencia en el caso de tramas pequeñas -mayor proporción de datos de control-. Para este caso se
prevé la posibilidad de que una estación que quiera enviar varias tramas pequeñas seguidas lo haga como una ráfaga.
Actualmente existen implementaciones que utilizan tramas Jumbo (Jumbo-frames) con MTU (Maximum Transmission
Unit) mayor que 1518B, lo que permite reducir la sobrecarga de cabeceras presuponiendo una mayor calidad de los
medios. El MTU típico de las tramas Jumbo es de 9000 B, pero existen distintas implementaciones.
28 OUI: Organization Unic Identifier.

29 DIX fue un consorcio creado por DEC, Intel y Xerox para hacer de Ethernet un protocolo abierto al que se pudiesen sumar distintos fabricantes.
Cuando 802 sacó su estándar (1983), para permitir su convivencia DIX movió los tipos utilizados a valores mayores que 1536, sin embargo el
sistema DIX es más eficiente y era el preferido por los fabricantes. En 1997 IEEE estandariza el uso de Tipo/Longitud.
30 Dado que se emiten más bits en el mismo tiempo límite de propagación de 2τ bits.
4.6. Tarjetas interfaces de red (NIC: Network Interface Card)

Las tarjetas interfaces de red (NIC: Network Interface Card) son la electrónica que utilizan las estaciones para acceder
al medio físico para comunicar con otras estaciones. Implementan el subnivel MAC (Medium Access Control), mientras
que el controlador de las mismas (driver) implementa el subnivel LLC (Logical Link Control).
En funcionamiento normal, sólo reciben y entregan al nivel superior las tramas que cumplen:
● La dirección de destino es su propia dirección MAC
● Son tramas de difusión (broadcast)
● Son tramas de multicast y alguna aplicación le ha indicado a la tarjeta que reciba tramas a esa dirección
multicast en concreto.
Tienen un modo de funcionamiento especial llamado "modo promiscuo" en el que reciben y entregan al nivel superior
todas las tramas que escuchan. Algunos programas configuran la tarjeta en este modo para analizar todo el trafico que
pasa por su segmento.
En un principio, cada trama que se recibía en la tarjeta provocaba una interrupción a la CPU para pasársela al
controlador y que éste la entregara al protocolo correspondiente de nivel 3. Hoy en día se pueden configurar para que
esperen (durante un tiempo máximo) a recibir varias tramas para pasárselas todas juntas al controlador y así provocar
menos interrupciones a la CPU.
Si se utilizan canales no compartidos (full-duplex) y el interfaz soporta varias velocidades, normalmente también es
capaz de negociar su velocidad con el otro extremo del cable por medio de una señal especial intentando negociar
primero la velocidad más alta. Esta negociación se lleva a cabo cuando se inicializa el enlace, antes de enviar datos.
En fibra óptica no se puede negociar la velocidad porque cada estándar utiliza transmisores diferentes.
Es muy importante que los interfaces que no usan full-duplex implementen correctamente el protocolo CSMA/CD para
que no disminuya el rendimiento de la red.
4.7. Repetidores y concentradores (Hubs)

Los repetidores son componentes que actúan a nivel puramente físico (N1) y sirven para ampliar el alcance de la red.
Simplemente repiten (y con ello amplían / regeneran) la señal recibida sin actuar a nivel lógico, esto es, sin realizar
ningún control o análisis de la misma y sin aislar segmentos de la red. A nivel lógico son únicamente una parte más del
medio (un trozo de cable, o parte del aire). Algunos permiten cambiar de medio físico (no de velocidad).
Los concentradores (hubs) son repetidores con varios puertos. Un concentrador simula un único segmento Ethernet
entre todas las estaciones que se conectan a el. Como cualquier otro repetidor actúan a nivel físico (N1) retransmitiendo
las tramas que se reciben en un puerto a todos los puertos restantes, independientemente de que estén libres u ocupados,
por lo que también propagan las colisiones. Todos los puertos de un concentrador deben ser de la misma velocidad. En
los inicios de Fast Ethernet, dado el alto coste de los conmutadores, aparecieron concentradores de doble velocidad
(dual-speed hubs) que en realidad eran dos concentradores unidos internamente por un puente.
El estándar de IEEE define los puertos RJ45 para cable de par trenzado (xTP31) de los equipos como MDI (Medium
Dependent Interface), mientras que los puertos de los concentradores son MDI-X (Medium Dependent Interface –
Crossover). De los 4 pares del cable el interfaz MDI transmite por el par 2 (hilos 1-2) y recibe por el par 3 (hilos 3-6),
mientras que el MDI-X lo hace al revés.
Para conectar una estación a un concentrador se utiliza un cable paralelo (straight-through), pero para conectar entre si
dos concentradores o dos equipos se necesita un cable cruzado (crossover).
Con el tiempo los concentradores y conmutadores (switches) fueron incorporando un puerto MDI para interconectar (o
“apilar”) concentradores. Actualmente los conmutadores utilizan puertos propios o fibra para conectarse entre ellos y
todos sus puertos se configuran automáticamente como MDI o MDI-X (además de negociar Half o Full-duplex,
velocidad, control de flujo...).
31 Par trenzado no apantallado (UTP: Unshielded Twisted Pair) o par trenzado apantallado (STP: Shielded Twisted Pair).
4.8. Puentes (Bridges) y conmutadores (Switches)

Los puentes son nodos que unen dos o más redes a nivel de enlace de datos (N2) y permiten:
● Ampliar las distancias de la red.
● Separar dominios de colisión y aislar trafico unicast innecesario.
● Cambiar de protocolo de nivel de enlace (N2) entre dos redes (de FDDI a Ethernet, por ejemplo).
● Cambiar de velocidad.
● Transmisiones full-duplex.
Los conmutadores son puentes de múltiples puertos con circuitos integrados específicos de aplicación (ASIC32).
Desde el punto de vista MAC los puentes y conmutadores se comportan como una estación más. Durante su
funcionamiento, cuando reciben una trama por un puerto, apuntan en una tabla que la dirección MAC de origen de la
trama está en ese puerto. Así pueden saber en que puerto está cada estación y más tarde, cuando tienen que enviar una
trama a esa estación la envían solo al puerto donde se detectó.
Las entradas en la relación MAC-puerto se renuevan cada pocos segundos. Si un puente o conmutador no conoce donde
esta la estación de destino envía la trama a todos sus puertos (inundación o flood).
Aunque cada puente o conmutador produce un retardo en la señal, en principio no hay limite en cuanto al número de
puentes que se pueden poner en una red ya que cada retransmisión regenera la señal.
Como los puentes y conmutadores aislan el trafico unicast enviándolo solo al puerto necesario, aumenta también la
seguridad de la red ya que las estaciones conectadas a otros puertos no pueden capturar ese trafico. Para poder hacerlo,
algunos conmutadores soportan configurar especialmente un puerto espejo (mirror) que transmite el mismo trafico que
otro. De todas maneras este esquema puede atacarse por medio de inyecciones ARP (ARP spoofing) o inundación de
MAC (MAC flooding), aunque los conmutadores (switches) más modernos implementan defensas al respecto.
Si los puentes soportan el protocolo Spanning Tree definido en el estándar 802.ld se pueden unir dos puentes a través de
2 o más caminos (pasando incluso por otros puentes) evitando los bucles, lo que permite tener un camino alternativo en
caso de que haya una avería en el camino principal o poder repartir tráfico.
4.9. Comunicación Dúplex (Full-Duplex)

El protocolo Ethernet original transmite en semi-dúplex (half-duplex) porque el medio es compartido. La transmisión
dúplex (full-duplex) en Ethernet esta normalizada por el IEEE en el estándar 802.3x. Una línea es dúplex si puede
enviar y recibir datos al mismo tiempo, lo que puede ocurrir entre dos nodos conectados directamente.
Para que la transmisión pueda ser dúplex se deben cumplir:

● Que haya un medio de transmisión diferente del de recepción.
● Que solo haya dos nodos compartiendo el medio.
● Que los interfaces de los nodos lo soporten.
En transmisión dúplex no hay gestión CSMA/CD ya que no puede haber colisiones. Si la transmisión es dúplex se
puede aumentar la distancia entre estación y conmutador, ya que tampoco hay que tener en cuenta el tiempo de ida y
vuelta porque no hay control de colisiones. La única restricción es la atenuación de la señal. Con algunos emisores láser
se ha llegado a 800km.
Cuando la comunicación es dúplex puede que uno de los extremos no sea capaz de procesar el trafico que le envía el
otro. Para resolver este problema en el estándar IEEE 802.3x se define un método de control de flujo que consiste en
que el extremo saturado le envía al otro una trama especial llamada Pause (con tipo 8808) donde le ordena dejar de
enviar datos durante un tiempo indicado. Antes de que transcurra ese tiempo le puede enviar la orden Pause-Release
para que vuelva a transmitir. La orden Pause debe darse antes de que se llenen los buffers ya que puede haber datos en
el cable que todavía no se han recibido. El control de flujo puede ser simétrico (los dos extremos pueden ordenar parar
al otro) o asimétrico (sólo puede ordenarlo un extremo).
32 ASIC: Application-Specific Integrated Circuit.
Normalmente un interfaz de red es capaz de negociar automáticamente con el otro extremo el modo de transmisión
(half o full-duplex) y el control de flujo.
4.10. Restricciones
El estándar Ethernet impone las siguientes restricciones:
● Como máximo 100 m para cable de par trenzado.
● MTU (Maximum Transmission Unit) = 1518 bytes
● Restricciones en el estándar Ethernet original:
○ Como máximo 4 repetidores o concentradores entre dos equipos del mismo dominio de colisión.
○ Como máximo 1.024 estaciones de trabajo en el mismo dominio de colisión.
○ 2τ propagación en el diámetro máximo del dominio de colisión < τ transmisión de T (tamaño de trama
mínima = 64 bytes = 512 bits)
4.11. La evolución de la familia Ethernet

Ethernet
Transmite a 10Mbps. Utiliza codigo Manchester, que es sencillo y barato de implementar, pero poco eficiente ya que al
utilizar el doble de frecuencia requiere un cable de altas prestaciones como el coaxial.
En Ethernet la codificación se realiza en el controlador, no en el transceiver, por lo que se ha de emplear en todos los
medios físicos. En las siguientes especificaciones la codificación se realiza en el transceiver, con lo que para cada
medio físico puede elegirse el código que más convenga.
Definido en el libro azul de Ethernet publicado por DIX en 1980. Al primer protocolo implantado en Palo Alto a 2,94
Mbs se le conoce como Ethernet Experimental.
Estándar Medio y conectores Repet. /Est. Distancia / Transmisión

10Base-5 (1) Coaxial amarillo de 50 Ω 2 / 100 500 m.
Fue la primera versión comercial. Transceptores vampiros y cable AUI Half-Duplex
(drop) de hasta 50 metros.
10Base-2 (1) Coaxial RG58 de 50 Ω 4 / 30 separadas 185 m.
Surgió para solucionar los Conectores BNC -conectores T- entre sí por 1 m. Half-Duplex
problemas de coste y rigidez del o más.
coaxial amarillo.
10Base-T (2) Par trenzado a partir de Cat. 3. 4 / 1024 Cat. 3 – 100m
Surgió para reutilizar los cables Conectores RJ-45. Cat. 5 – 150m
de telefonía -par trenzado no De los 4 pares del cable solo utiliza Half-Duplex y
apantallado (UTP)- para datos. dos: El 2 y el 3 (hilos 1, 2, 3 y 6). Full-Duplex
10Base-F (3) (10Base-Fx) Multimodo; LED en primera 2000 m.
Implementación del estándar. Se ventana. Luz visible. Half-Duplex y
usan sus variantes FL, FB o FP. Conectores ST. Full-Duplex
(1) Basado en cable coaxial y topología lineal (o de bus). Se pueden unir varios segmentos con repetidores siempre que
no haya más de 4 repetidores entre dos segmentos cualesquiera. Si se abre el coaxial o uno de los terminadores, deja de
funcionar toda la red. Necesita terminadores de 50 Ω en los extremos del cable.
(2) Aunque su topología lógica sigue siendo lineal, su topología física es de estrella con un repetidor multipuerto
(concentrador o hub) en su centro. Cada estación tiene un cable propio que lo une al concentrador. Se puede mezclar
con 10Base-5 o 10Base-2 siempre que no se interconecten por más de 3 coaxiales.
Soporta 1024 estaciones en cada dominio de colisión.
(3) Implementación del estándar original Ethernet sobre fibra: FOIRL (Fiber-Optic Inter-Repeater Link). No se utiliza
directamente, si no una de sus variantes (FL -la más utilizada-, FB -para espinazos (backbones)- o FP -nunca se usó-).
Fast Ethernet
Esta regulada por la norma IEEE 802.3u. Transmite a 100 Mbps. Utiliza codificación de traducción.
Estándar Medio y conectores Repetidores / Estaciones Dist. / Trans.

100Base-Tx Par trenzado (TP) de 2 Clase II33 unidos con un cable de 100m.
Variante de 100Base-T con categoría 5. hasta 5m. - Full-Duplex
cable cat. 5. Usa los mismos hilos que
Código 4B/5B. 10Base-T.
100Base-T4 (1) UTP de categoría 3. 2 Clase II unidos con un cable de hasta 100m.
Variante de 100Base-T con Utiliza 3 pares para 5m. - Half-duplex
cable cat. 3, usando 4 pares. transmitir y uno para
Código 8B/6T. detección de colisiones.
100Base-T2 (1) UTP de categoría 3. Requiere procesadores de señal 100m.
Variante de 100Base-T con Utiliza los 4 pares. específicos muy sofisticados, ya que - Full-duplex
cable cat. 3 Full-Duplex. emiten y reciben a la vez por el mismo (* Dual-Duplex)
Código PAM-5x5. cable(*), por lo que era una opción cara
que nunca se llegó a implementar.
100Base-Fx Fibra óptica multimodo con 400m.
Código 4B/5B NRZ-I LED en segunda ventana. - Half-duplex
(No Return to Zero - Conectores SC. 2000m
Inverted). - Full-Duplex
(1) Pensados para seguir utilizando el cableado telefónico existente (UTP Cat. 3).
Gigabit Ethernet
Esta regulada por las normas IEEE 802.3z para fibra e IEEE 802.3ab para cobre. Transmite a 1000 Mbps.
Estándar Medio y conectores Distancia / Transmisión

1000Base-T Par trenzado (TP) Cat. 5, 5e o 6. 100 m. - Full-duplex
Código PAM-5x5. Emite y recibe simultáneamente por (* Dual-duplex)
los 4 pares (*).
1000Base-Lx Fibra óptica multi y monomodo con En fibras multimodo:
Código 8B/10B NRZ. Se puede ILD en segunda ventana. 330m - Half-duplex
optimizar para conseguir hasta Conectores SC. 550m - Full-duplex
10.000m. de alcance con fibras mono- En fibras monomodo:
modo. 330m - Half-duplex
2000m – Full-duplex
1000Base-Sx Fibra óptica multimodo con LED en 62,5/125: 275m.
Código 8B/10B (8 bits/10 baudios) primera ventana. 50/125:
NRZ. Conectores SC. <~ 330m - Half-duplex
La optoelectrónica de LEDs en <~ 550m – Full-duplex
primera ventana lo hace mucho más Depende de la calidad de la fibra.
económico que Lx
33 Los concentradores pueden ser de Clase I o II en función del retardo que generan.
Aunque el estándar define el uso half-duplex, no se suele utilizar en fibras. En el caso de half-duplex solo se soporta un
concentrador. Para poder alcanzar mayor distancia (330m) en half-duplex el tamaño mínimo de trama se amplia a 512B
bits. Debido a la complejidad de la implementación half-duplex, se han diseñado concentradores especiales de fibra
llamados buffered repeaters que funcionan en full-duplex pero sin aislar tráfico como hacen los conmutadores que son
más complejos.
En caso de que por un puerto de un conmutador llegue una trama de menos de 512B y el conmutador tenga que enviarla
por un puerto half-duplex, el conmutador podrá:
● Añadir una extensión de portadora para que la trama tenga 512B.
● Concatenar tramas (tramas Jumbo o Jumbo frames) y añadir luego la extensión de portadora si no llegan a
tener 512B.
Cuando el conmutador recibe una trama con extensión de portadora y tiene que enviarla a un puerto full-duplex o un
puerto no gigabit elimina la portadora.
En fibra óptica aparecen los Gbics que llevan la óptica del protocolo para hacer más flexibles los nodos.
Actualmente se está desarrollando el estándar IEEE 802.3ae a 10 Gbps. No funcionará en cable de par trenzado
categoría 5, pero puede que si en categoría 5e o 6. Se están pensando hacer un estándar con velocidad variable como en
los módems.
Problemas en Ethernet
● Su funcionamiento no permitía a los administradores un control centralizado de la red. Esto se soluciona con
conmutadores programables.
● Ethernet considera el medio suficientemente fiable como para no ocuparse de la pérdida de tramas. Una trama
perdida no se retransmite hasta que no vence el tiempo de espera (timeout) del nivel superior. Como el nivel de
red también supone un nivel de enlace fiable, estos tiempos suelen ser altos.
● El mecanismo de retroceso exponencial binario intenta transmitir la trama hasta 16 veces. Si no lo consigue se
reporta al nivel superior que hay excesivas colisiones, lo que suele ser debido a errores en el nivel físico.
● Efecto captura. Distintos paquetes pequeños de una máquina que los prepara y emite rápidamente pueden
colisionar repetidamente con el mismo paquete de una máquina más lenta que irá aumentando su contador de
retroceso, mientras que para la máquina rápida son distintas colisiones y cada vez pone su contador a 0,
teniendo más probabilidades de enviar antes su paquete y mantener el uso del medio.
● La tasa de colisiones de una red es más o menos preocupante en función de los tamaños de trama que se
utilicen. Normalmente debe ser menor del 10%.
● Ethernet no reparte equitativamente los recursos en condiciones de alta ocupación. Con una tasa de colisiones
alta puede proporcionar más ancho de banda a aplicaciones que utilizan una trama más grande.
● En una topología no valida (diámetro excesivo del dominio de colisión), puede haber colisiones que se
detecten después de haber enviado una trama mínima y haber dado la trama por transmitida. Este fenómeno se
denomina "colisiones tardías" y es un síntoma de que pueden estar perdiéndose tramas mínimas.
● Un elevado numero de broadcast y/o multicast es indeseable. Algunos conmutadores pueden configurarse para
filtrar estos paquetes si se supera un cierto umbral o no permitirlos.
● Si dos puntos de la red están unidos por dos caminos alternativos, la topología deja de ser un bus para
contener un anillo. Por ese anillo circulan las tramas infinitamente sin ser nunca eliminadas lo que provoca una
saturación inmediata de la red. En el caso de que el bucle se cree entre conmutadores sin spannig tree activado
en al menos uno de ellos, aunque las tramas de unicast no entren en el bucle, si lo harán las tramas de
multicast y de broadcast, saturando igualmente la red.
● Otro de los mayores problemas en Ethernet es que uno de los dos extremos este configurado en full-duplex y el
otro en half-duplex. Aunque la mayoría de dispositivos actuales detecta automáticamente el tipo de envío, esto
provocaría colisiones en el extremo half-duplex que tendrá que reenviar la trama y la pérdida de la trama del
extremo full-duplex que presupone que no pueden existir colisiones.
Los problemas de colisiones se solucionan si los equipos se conectan a conmutadores full-duplex.
Resumen
Estándar Medio / Conectores Distancia Codificación

10Base-5 (1) Coaxial amarillo de 50 Ω (grueso) 500 m. Manchester
Primera versión comercial. y transceptores Half-Duplex
10Base-2 (1) Coaxial RG58 de 50 Ω (fino) 185 m. Manchester
Coaxial más económico. y conectores BNC Half-Duplex
10Base-T (2) UTP Cat. 3 y RJ-45. Cat. 3 – 100m Manchester
Reutiliz. cables de telefonía. UTP Cat. 5 y RJ-45. Cat. 5 – 150m
Half-Duplex y
Full-Duplex
10Base-F (3) (10Base-Fx) Multimodo; LED en primera ventana. 2000 m. Manchester
Fibra óptica multimodo. Luz visible. Half-Duplex y
FL / FB / FP Conectores ST. Full-Duplex
100Base-Tx UTP Cat. 5 y RJ-45. 100m. - Full-Duplex 4B/5B

UTP Cat. 5.
100Base-T4 (1) UTP Cat. 3 y RJ-45. 100m. - Half-duplex 8B/6T
UTP Cat. 3 Half no 3 pares para transmisión
balanceado. 1 par para colisiones
100Base-T2 (1) UTP Cat. 3 y RJ-45. 100m. - Full-duplex PAM-5x5
UTP Cat. 3 Full balanceado. Procesadores específicos. (Dual-Duplex)
100Base-Fx Multimodo; LED en segunda ventana. 400m. - Half-duplex 4B/5B NRZ-I
Fibra óptica. Conectores SC. 2000m - Full-Duplex
1000Base-T UTP Cat. 5, 5e o 6 y RJ-45. 100 m. - Full-duplex PAM-5x5

Par trenzado. (Dual-duplex)
1000Base-Lx Fibra óptica multi y monomodo con ILD En fibras multimodo: 8B/10B NRZ
Fibra más rápida. en segunda ventana. 330m - Half-duplex
Conectores SC. 550m - Full-duplex
En fibras monomodo:
330m - Half-duplex
2000m - Full-duplex
1000Base-Sx Fibra óptica multimodo con LED en 62,5/125: 275m. 8B/10B NRZ
Fibra más económica. primera ventana. 50/125:
Conectores SC. 330m - Half-duplex
550m - Full-duplex
4.12. Mejoras de rendimiento

Según estudios de Boggs34 y colaboradores el rendimiento de una red Ethernet depende de:
● el tamaño de trama utilizado (a mayor trama, mayor rendimiento). Probablemente el más influyente dado que
las colisiones siempre se producen en los primeros 2τ bits35 (que su vez debe ser <= 512 bits por respeto a la
trama mínima).
● el número de estaciones del dominio de colisión (a menor número de estaciones, mayor rendimiento).
● el tiempo de ida y vuelta (a menor diámetro del dominio de colisión, mayor rendimiento).
Recomendaciones para mejorar el rendimiento:

● no instalar “cables” largos (incluir puentes o conmutadores).
● no instalar demasiados ordenadores en un mismo dominio de colisión (incluir puentes o conmutadores).
● utilizar el tamaño de trama máximo posible.
● no mezclar aplicaciones de transferencia masiva de datos con aplicaciones de tiempo real.
● utilizar el protocolo correctamente -detección de colisiones, retroceso exponencial binario y pausa entre
tramas- (detectaron que muchos de los principales fabricantes no lo hacían).
Agregación de enlaces
La agregación de enlaces (Link Aggregation) es una técnica también llamada "Port trunking", "NIC bonding" o
"Ethernet trunk", entre otros. Consiste en agregar dos enlaces físicos en un único enlace lógico entre dos nodos. Estos
nodos serán normalmente dos conmutadores o un conmutador y un equipo con tarjetas especiales que lo soporten.
El trafico se reparte entre los dos enlaces, consiguiendo más ancho de banda y más fiabilidad, puesto que si cae un
enlace (rotura de un cable) se mantiene la conexión por los restantes.
VLANs
Las VLANs (Virtual LANs) aparecen para montar redes de nivel 2 independientes compartiendo la electrónica y el
cableado. El estándar que las normaliza es el IEEE 802.1Q y su implantación más habitual es por puertos.
Si se configuran 2 puertos de un conmutador en VLANs diferentes, las estaciones conectadas a uno de los puertos no
podrán comunicar (en este nivel) con las estaciones del otro puerto.
Se pueden configurar puertos por los que circulen tramas de varias VLANs con un campo especial que define a cual
pertenece cada trama. Estos puertos se suelen llamar 'etiquetados' (tagged) y pueden utilizarse para unir dos
conmutadores o un conmutador y un servidor con tarjetas especiales.
Destino Origen [Tag] Tipo/Long. Datos Relleno CRC

6 6 [4] 2 0 – 1500 0 – 46 4
El formato del campo Tag es el siguiente (en bits):

8100 Prioridad CFI VID
16 3 1 12
El campo 8100 se utiliza para identificar que esto es un campo tag. Si esto no fuera un campo tag, en su lugar estaría el
campo Tipo/Longitud que nunca puede tener un valor 8100.
El campo de prioridad permite 8 niveles (3 bits).
El campo CFI (Canonical Format Indicator) se pone a 1 para indicar compatibilidad con Token-Ring.
El campo VID es el identificativo de la VLAN a la que pertenece el paquete. Si se conecta a un puerto etiquetado un
equipo que no soporte 802.1Q, éste no funciona porque no entiende las tramas que le llegan.
34 (1988) Measured Capacity of an Ethernet: Myths and Reality. David Boggs colaboró con Robert Metcalfe en el diseño de Ethernet y construyó en
1975 el primer encaminador y el primer servidor de nombres de Internet.
35 Un número que crece con la velocidad de la red, ya que en el mismo tiempo se transmite más información.
Además de las VLAN por puertos, en que cada puerto de un concentrador pertenece a una VLAN, existen equipos que
permiten realizar VLANs por direcciones MAC, por protocolo (inspeccionando datos de la capa 3 y formando redes
según estos protocolos) o por direcciones IP (también de la capa 3), independientemente del puerto en que se conecten
las máquinas.
Por coste y sencillez de gestión la gran mayoría de VLANs que se implementan son por puertos.
Prioridades
En redes Ethernet con conmutadores se pueden implementar prioridades para dar preferencia a un cierto tráfico de la
red. Esto permite en cierta medida implementar aplicaciones de tiempo real sobre Ethernet.
El estándar que regula este mecanismo es el IEEE 802.1P que se integró más tarde dentro de IEEE 802.1Q.
Se puede aplicar una prioridad a cada puerto de un conmutador para que procese las tramas recibidas en cada puerto con
más o menos rapidez.
Para poder aplicar prioridades entre concentradores, esta información es incluida en la trama en un campo especial
añadido. Este campo aparece también en la trama 802.1Q.
Cuando un conmutador recibe una trama, la asigna a una cola con más o menos prioridad en función de la etiqueta que
tenga la trama.
Como el campo de prioridad es de 3 bits, existen 8 niveles de prioridad diferentes.
Redes de comunicaciones 5. IEEE 802.11 (Wi-Fi)
5. IEEE 802.11 (Wi-Fi)

5.1. Definición
IEEE 802.1136 es un conjunto de estándares de protocolo de nivel de enlace (N2) para redes inalámbricas de área local
(WLAN: Wireless LAN), que trabaja en las bandas de 2.4 GHz y 5 GHz.
Aunque los términos 802.11 y Wi-Fi se intercambian habitualmente, no son exactamente lo mismo. 802.11 es el
estándar de IEEE, mientras que “Wi-Fi” es una marca registrada de la alianza Wi-Fi (Wi-Fi Alliance), un grupo
empresarial que inicialmente incluía empresas como 3Com, Cisco, Lucent, Nokia... y que actualmente engloba a casi
todas las empresas del mercado en una u otra manera. Esta alianza nació para asegurar la compatibilidad entre
dispositivos 802.11 y entrega certificados Wi-Fi. Sin embargo por cuestiones de mercado a veces se ha anticipado a los
estándares certificando en base a borradores 802.11 (“futuros estándares”).
Otras redes inalámbricas

IEEE 802.11 es el estándar para redes inalámbricas de área local (WLAN). Para redes inalámbricas de área personal
(WPAN: Wireless PAN) se utiliza:
● IEEE 802.15.1 - Bluetooth: versión estandarizada de Bluetooth. Frec. 2’45 GHz. Entre 1 y 20 Mbps.
● IEEE 802.15.x: 4 estándares más de WPAN.
● Infrarrojo.
Para áreas metropolitanas (WMAN) se utiliza:

● IEEE 802.16: Conmutación de paquetes. Punto a multipunto.
● IEEE 802.20: WMAN Mobile.
5.2. Otras definiciones

Punto de acceso (AP: Access Point)
Un punto de acceso es un puente (N2) entre la red inalámbrica y otra red, que se encarga de realizar las conversiones de
trama pertinentes.
Conjunto de Servicio Básico (BSS: Basic Service Set)

Bloque mínimo de una red WLAN. Se identifica mediante un BSSID (BSS IDentifier) y puede configurarse en dos
modos:
● Infraestructura o gestionado: las estaciones se comunican a través de un punto de acceso. En este caso se
conoce también como BSS la cobertura del AP -que es quien gestiona la red-. En este caso el BSSID es la
dirección MAC del AP.
● Independiente o ad-hoc (IBSS): las estaciones se intercomunican directamente. Su precursor fueron las redes
de paquetes de radio (packet radio network) de DARPA. En este caso el BSSID es un número aleatorio
(PseudoMAC).
Conjunto de Servicio Extendido (ESS: Extended Service Set)

Conjunto de uno o más BSSs que funcionan como un único BSS para la capa lógica de red (N2 LLC). Este conjunto se
identifica mediante una cadena de caracteres llamada ESSID (ESS Identifier) definida por el administrador. Este ESSID
es a veces llamado simplemente SSID o "nombre de la red". Los distintos BSS del ESS pueden trabajar en el mismo
canal o en distintos canales para ampliar la capacidad de la red.
Sistema de Distribución
Mecanismo que sirve para controlar a qué AP se envían las tramas. Proporciona movilidad entre distintos AP aunque
las estaciones solo podrán cambiar de ubicación sin perder conectividad siempre que la transición se realice dentro de
un mismo ESS.
36 En general, los protocolos de la rama 802.x definen la tecnología de redes de área local.
Señales Beacom
La sincronización de estaciones es muy importante y se hace a través de tramas especiales llamadas Beacom. El punto
de acceso las emite periódicamente. Una estación puede esperarlos para sincronizarse (passive scanning) o emitir
peticiones para recibirlas (active scanning).
Las bandas ISM

Las bandas ISM (Industrial Scientific Medical) son bandas de radiofrecuencia electromagnética reservadas
internacionalmente para uso no comercial en áreas de trabajo industriales, científicas y médicas. Estas bandas pueden
utilizarse sin necesidad de licencia siempre que se respeten unos determinados límites de potencia.
Fueron definidas por la ITU (International Telecomunications Union) en el artículo 5 de las Regulaciones de Radio (RR
5.138, 5.150 y 5.280) y todo aparato que trabaje con ellas debe ser tolerante a errores y utilizar mecanismos de
protección contra interferencias, como técnicas de ensanchado de espectro (RR 15.13). Por este motivo, las redes que
funcionan en esta banda se les denomina redes de espectro ensanchado.
Algunos aparatos que usan la frecuencia de 2,4 GHz son los microondas, teléfonos inalámbricos, monitores de bebés,
IEEE 802.15.1 (WPAN - Bluetooth) e IEEE 802.11 (WLAN)...
Además de utilizarse diferentes técnicas de espectro ensanchado, en función de la relación señal/ruido se puede utilizar
una modulación (bits por símbolo) más o menos rica para alcanzar más velocidad, por lo que los aparatos realizan una
negociación de velocidades.
Según la zona geográfica, en la banda de los 2.4GHz se utilizan de 7 a 14 canales (13 en Europa). El ancho de banda de
la señal (22MHz) es superior a la separación entre canales consecutivos (5MHz), por eso se hace necesaria una
separación de al menos 5 canales con el fin de evitar interferencias entre celdas adyacentes. Tradicionalmente se
utilizan los canales 1, 6 y 11 o los canales 1, 5, 9 y 13.
Diversificación de la señal
Como las señales viajan rebotando en las paredes y objetos, se produce autointerferencia de las señales al llegar
desfasadas según el camino que recorren (multitrayectoria de la onda). Es decir se produce interferencia debido a la
diferencia de tiempo entre la señal que llega directamente y la que llega reflejada por diversos obstáculos. Para
minimizar este efecto, se suelen utilizar dos antenas ligeramente separadas y el receptor elige la señal de la antena
donde se recibe con más claridad.
Codificación radioeléctrica
Las técnicas de codificación que se utilizan son variantes de CDMA (Code Division Multiple Access). A 5 GHz se
utiliza OFDM (Orthogonal Frequency Division Multiplexing). A 2,4 GHz se utiliza DSSS (Direct Sequence Spread
Spectrum) con diversidad de antenas (dobles antenas). El estándar original también permitía el uso de la técnica FHSS
(Frequency Hopping Spread Spectrum) que reduce mejor la autointerferencia usando una sola antena.
Con dichas técnicas, si hay ruido en alguna frecuencia no afecta a una sola banda, sino que se reparte el efecto entre
todas y su efecto es menor.
5.3. Problemas añadidos en redes inalámbricas

Además de los problemas habituales de acceso al medio existen dos problemas añadidos:
– Nodos ocultos: en que una estación cree que el canal está libre, pero en realidad
está ocupado por un nodo al que no escucha.
Por ejemplo el nodo A está en el rango del nodo B, pero queda fuera del rango
del nodo C y no puede detectar si el nodo C está transmitiendo al nodo B.
– Nodos expuestos: en que una estación cree que el canal está ocupado, pero en
realidad está libre pues el nodo al que oye no le interferiría.
Por ejemplo el nodo C puede retrasar sus transmisiones al nodo D mientras el nodo B transmite para A, que en
realidad no interferiría.
5.4. Control de acceso al medio (MAC: Medium Access Control)

El sistema de control de acceso al medio (N2 capa MAC) de IEEE 802.11 es la pila de protocolos DFWMAC
(Distributed Foundation Wireless Medium Access Control), aunque este nombre es poco utilizado en la literatura al
respecto. La base de DFWMAC es una técnica de coordinación distribuida llamada DCF (Distributed Coordination
Function), obligatoria en el estándar 802.11.
IEEE 802.11 también define una técnica de coordinación centralizada llamada PCF (Point Coordinated Function) que
solo está disponible en modo infraestructura. Esta técnica es opcional y además no se exige para los certificados de la
alianza Wi-Fi, por lo que muy pocos aparatos lo implementan.
PCF (Point Coordinated Function)

PCF alterna dos periodos de tiempo: periodos con conflictos (CP: Contention Period) y periodos libres de conflictos
(CFP: Contention Free Period). Durante los CP las estaciones simplemente utilizan DCF. Durante los CFP el punto de
coordinación (el AP) controla qué estación puede transmitir en cada momento de manera síncrona37 con un algoritmo
Round-Robin. Esta coordinación centralizada permite ciertas gestiones de QoS, por ejemplo para conexiones sensibles
al tiempo, como emisiones de vídeo, y se puede utilizar para minimizar el problema de los nodos ocultos (si ningún
nodo queda oculto al controlador). El principal inconveniente que se le achaca es que no define clases de tráfico.
IEEE 802.11e define una nueva función de coordinación HCF (Hybrid Coordination Function) con el objetivo de
incorporar garantías QoS y permitir aplicaciones de tiempo real.
DCF (Distributed Coordination Function)

DCF utiliza un algoritmo CSMA/CA (Carrier Sense Multiple Access with Collision Avoidance) con intercambio
RTS/CTS opcional y acuse explícito de recibo. Usa comunicación asíncrona38 entre estaciones.
La idea base de CSMA es que una estación que desea transmitir en un medio compartido primero escucha el canal para
verificar si tiene actividad. En caso de que el canal esté libre la estación comienza a emitir inmediatamente.
Ethernet que utiliza CSMA/CD espera a que el canal quede libre (más la pausa requerida) y comienza a emitir. En caso
de que otra estación estuviese también esperando para emitir se produce una colisión. Las estaciones emisoras detectan
la colisión y esperan un tiempo aleatorio antes de volver a intentarlo.
Sin embargo dado que el rango dinámico de señales es muy amplio las NIC inalámbricas no son capaces detectar
colisiones, por lo que no se puede usar CSMA/CD. En vez de ello se utiliza CSMA/CA.
37 Las comunicaciones síncronas utilizan ventanas de tiempo en las que se puede transmitir, y obligan a que las estaciones se mantengan
sincronizadas para utilizar las mismas ventanas de tiempo (de manera centralizada o distribuida).
38 Las comunicaciones asíncronas utilizan ventanas variables y no sincronizadas de tiempo.
CSMA/CA hace varias cosas:

– verifica si el medio está libre u ocupado (CSMA);
– cuando la línea está ocupada espera un tiempo aleatorio antes de volver a intentar enviar (CSMA);
– incluye un mecanismo opcional de intercambio RTS/CTS antes de emitir el mensaje (CA);
– incluye un mecanismo de acuse explícito de recibo a nivel de MAC (CA);
Es decir, cuando una estación inalámbrica desea transmitir primero verifica que el canal está libre durante un tiempo
predeterminado. Si está libre comienza a emitir inmediatamente y si está ocupado espera primero a que quede libre y
después un tiempo aleatorio antes de volver a verificarlo (CSMA).
Una vez la estación puede emitir utiliza un intercambio RTS/CTS (éste intercambio no se utiliza para mensajes muy
cortos en que la sobrecarga no vale la pena). Para este intercambio primero envía una trama corta de control de solicitud
de transmisión RTS (Request To Send) indicando a las demás estaciones que no transmitan. Esta trama además
especifica las estaciones origen y destino de la comunicación y el tamaño de la trama que se desea transmitir. Si la
estación destinataria recibe correctamente esta señal devuelve una trama indicando que está ocupado -comunicándose
con un nodo oculto- (RxBUSY) o una trama indicando que todo está preparado para la emisión (CTS: Clear To Send) y
el tamaño de trama que va a recibir.
Si una estación recibe el mensaje RTS pero no la respuesta (CTS o RxBUSY) sabe que es un nodo expuesto y que
puede comunicarse con otro nodo a la vez.
Si una estación no ha recibido un RTS pero recibe un CTS sabe que es un nodo oculto y que debe esperar y además
sabe cuánto tiempo debe hacerlo porque conoce el tamaño de trama que se va a enviar.
Tras emitir el mensaje, la estación emisora espera a una respuesta del destinatario indicando una recepción correcta
(“ACK”) o incorrecta (“NACK”). En el segundo caso -o si no recibe respuesta- el emisor volverá a emitir el mensaje,
existiendo un límite para el número de posibles reenvíos.
Sus principales inconvenientes son:

– Si muchas estaciones pretenden comunicar a la vez, ocurrirán muchas colisiones que disminuirán el ancho de banda
disponible.
– No hay prioridades o clases de tráfico ni garantías de QoS.
– Cuando una estación gana el medio puede secuestrarlo. Por ejemplo una estación que transmita a 1Mb/s puede
tardar mucho tiempo en enviar un paquete, perjudicando al resto de estaciones.
– Para poder garantizar la usabilidad del canal ha de sacrificar un porcentaje significativo de la capacidad
incrementando el volumen de tráfico -con tráfico de control-.
5.5. Seguridad
Aunque la seguridad se contempló desde el principio, originalmente no era muy buena debido principalmente a las
limitaciones para exportar productos de criptografía de muchos países (especialmente EE.UU.). Tras cambios
normativos apareció una revisión del protocolo (802.11i) que mejora la seguridad del mismo. Otros estándares de esta
familia (c–f, h–j, n) son mejoras de servicio y extensiones o correcciones a especificaciones anteriores.
El sistema inicial se llamó WEP (Wired Equivalent Privacy) basado en el algoritmo de encriptación RC4 y clave pre-
compartida (PSK). Ya en 2001 se presentaron trabajos que mostraban la debilidad de este sistema y hoy día existen
programas que se encargan desatendidamente de romper la seguridad de una red basada en WEP.
IEEE creó un grupo -802.11i- dedicado a reemplazar el sistema de seguridad (anteriormente se encargaba el grupo
802.11e). La alianza Wi-Fi anunció una especificación llamada WPA (Wi-Fi Protected Access) basándose en el
borrador de 802.11i que comenzó a utilizarse en 2003. Esta especificación era TKIP (Temporal Key Integrity Protocol)
y se basaba también en RC4 con PSK. Sus mejoras en seguridad consistían principalmente en realizar un control de
integridad de los paquetes (ya que en los ataques algunos paquetes se alteraban sin llegarlos a descifrar), un conteo de
los mismos y utilizar una función de mezcla de la clave con el vector de inicialización de la red (en vez de una simple
concatenación) para generar la clave RC4.
El sistema 802.11i final, conocido como WPA2, apareció en 2004. Permite nuevos mecanismos de distribución de la
clave (como EAP), autenticación PSK o basada en servidores (como RADIUS) y CCMP (basado en AES) para cifrado.
La configuración habitual recomendada es WPA2 con clave precompartida (AES PreShared Key) -en entornos
domésticos o PyMES- o WPA2 con servidores RADIUS (EAP-TLS) en entornos corporativos.
En 2005 IEEE creó otro grupo -802.11w- que pretende asegurar las tramas de gestión y difusión, que en los estándares
anteriores son inseguras. La fecha prevista de publicación es Marzo de 2008.
Muchos puntos de acceso permiten establecer un control por dirección MAC permitiendo o denegando el acceso
únicamente a las tarjetas inventariadas. En algunos casos, la lista de MACs se puede mantener en un servidor RADIUS.
5.6. Evolución del estándar 802.11

Legacy
El estándar original IEEE 802.11 de 1997 -conocido como “legacy”-, especificaba dos ratios de transmisión de 1 y 2
Mbps sobre infrarrojos (IR) o sobre radiofrecuencia en la banda ISM de 2,4 GHz. Aunque la transmisión por infrarrojos
sigue incluida en el estándar no hay en el mercado productos que la utilicen.
Permite usar codificación DSSS (Direct Sequence Spread Spectrum) o FHSS (Frequency Hopping Spread Spectrum).
802.11a
La revisión 802.11a al estándar original fue ratificada en 1999 y funciona en la banda de 5GHz utilizando 52
subportadoras OFDM (Orthogonal Frequency-Division Multiplexing).
802.11a tiene una velocidad teórica máxima de 54 Mbit/s, con velocidades reales de aproximadamente 20 Mbit/s. La
velocidad de datos se reduce a 48, 36, 24, 18, 12, 9 o 6 Mbit/s en caso necesario.
802.11a tiene 12 canales no solapados, 8 para red inalámbrica y 4 para conexiones punto a punto.
Los equipos 802.11a y 802.11b no pueden operar entre ellos.
La revisión 802.11a utiliza la banda de 5 GHz, que tiene restricciones -de hecho 802.11a no es utilizable en Europa-.
Sin embargo la cantidad de canales disponibles y la ausencia de interferencias hacen de él una buena opción para
profesionales y empresas que estén dispuestos a obtener (y pagar) una licencia para el uso de dicha banda. Sin embargo,
la utilización de esta banda también tiene sus desventajas. Dado que sus ondas son más fácilmente absorbidas, los
equipos 802.11a deben quedar en línea de vista y son necesarios un mayor número de puntos de acceso.
Los productos del estándar 802.11a aparecieron en el mercado en 2001.
802.11b
La revisión 802.11b del estándar original fue ratificada en 1999 y funciona en la banda de 2.4GHz. Fue la primera
revisión que tuvo una amplia aceptación en el mercado.
802.11b tiene una velocidad teórica máxima de transmisión de 11 Mbit/s, pero debido al espacio ocupado por la
codificación del protocolo CSMA/CA, en la práctica la velocidad máxima de transmisión es de aproximadamente 5.9
Mbit/s para TCP y 7.1 Mbit/s para UDP.
Los dispositivos 802.11b deben mantener la compatibilidad con la norma original IEEE 802.11 -utilizando DSSS-.
Aunque también utiliza una técnica de ensanchado de espectro basada en DSSS, en realidad la extensión 802.11b
introduce CCK (Complementary Code Keying) para llegar a velocidades de 5,5 y 11 Mbps (tasa física de bit). El
estándar también admite el uso de PBCC (Packet Binary Convolutional Coding) como opcional.
802.11g
La revisión 802.11g es la evolución del estándar 802.11b y fue ratificada en Junio de 2003. Es compatible con el
estándar 'b' y utiliza las mismas frecuencias (2.4GHz) aunque con una velocidad teórica máxima de transmisión de 54
Mbit/s. La velocidad real de transferencia es de aproximadamente 22 Mbit/s, similar a la del estándar 802.11a.
En redes bajo el estándar 'g' la presencia de nodos bajo el estándar 'b' reduce significativamente la velocidad de
transmisión.
Los equipos que trabajan bajo el estándar 802.11g llegaron al mercado muy rápidamente, incluso antes de su
ratificación oficial. Esto se debió en parte a que para construir equipos bajo este nuevo estándar se podían adaptar los ya
diseñados para el estándar 'b'. A partir de 2005, la mayoría de los productos que se comercializan siguen la revisión
802.11g con compatibilidad hacia 802.11b.
Actualmente se venden equipos con esta especificación, con potencias de hasta medio vatio, que permite hacer
comunicaciones de hasta 50 km con antenas parabólicas apropiadas.
802.11h
La especificación 802.11h se hizo pública en octubre de 2003 y soluciona problemas derivados de la coexistencia de las
redes 802.11a con sistemas de Radares y Satélite. Aunque se utiliza en muchos otros países, fue originalmente
desarrollada para incorporar directrices europeas que pretenden minimizar el impacto de abrir la banda de 5 GHz
-utilizada generalmente por sistemas militares- a aplicaciones ISM.
Dichas directrices imponen la capacidad de gestionar dinámicamente tanto la frecuencia como la potencia de
transmisión mediante funcionalidades DFS y TPC.
– DFS (Dynamic Frequency Selection) pretende evitar interferencias co-canal con sistemas de radar y asegurar una
utilización uniforme de los canales disponibles.
– TPC (Transmitter Power Control) permite limitar la potencia transmitida para diferentes canales en una
determinada región, de manera que se minimiza la interferencia con sistemas de satélite.
802.11i
Aprobado en 2004, está dirigido a mejorar la seguridad. El estándar abarca los protocolos 802.1x, TKIP (Temporal Key
Integrity Protocol) -basado en RC4, conocido inicialmente como WEP2 y posteriormente como WPA- y AES
(Advanced Encryption Standard). La versión definitiva del estándar, basada en AES, se conoce como WPA2, y se
utiliza generalmente en la forma AES-PSK o EAP-TLS.
802.11e
La revisión 802.11e, aprobada en 2005, aporta mejoras en el sistema de control y servicios de 802.11.
Su objetivo es soportar tráfico en tiempo real con garantías de Calidad de Servicio (QoS). Para ello introduce clases de
tráfico y un nuevo sistema de coordinación llamado HCF (Hybrid Coordination Function) con dos tipos de acceso:
● EDCA (Enhanced Distributed Channel Access): Sistema distribuido de control. Se basa en prioridades de
tráfico. El tráfico más prioritario espera menos tiempo antes de emitir y utiliza marcos de tiempo de envío
(TXOP Transmit Opportunity) más largos que el tráfico menos prioritario, que espera más antes de emitir y
emite por menos tiempo (TXOP menores).
● HCCA (HCF-Controlled Channel Access): Sistema centralizado de control. De forma parecida al
funcionamiento de PCF, HCF contempla periodos controlados o no, con la diferencia principal de que el AP
puede iniciar un periodo controlado en cualquier momento y no de forma predeterminada. Análogamente a
como ocurría en PCF, los periodos no controlados se rigen por el sistema EDCA. Además el controlador recibe
información sobre el tráfico que desea enviar cada estación y en base a ellos y la QoS utiliza algoritmos de
planificación complejos, no únicamente Round-Robin.
También análogamente a PCF, su implementación es opcional y casi ningún equipo la soporta.
Además 802.11 incorpora otras mejoras como APSD (Automatic Power Save Delivery), BA (Block Acknowledgments),
QoSAck / QoSNoAck y DLS (Direct Link Setup).
Certificación WMM
La certificación WMM (Wireless MultiMedia) de la alianza Wi-Fi, no es un estándar. Basándose en el borrador de
802.11e, prioriza el tráfico en base a 4 categorías de acceso AC (Access Categories): voz, vídeo, mejor esfuerzo (best
effort) y fondo (background).
Para que un AP obtenenga el certificado WMM debe incorporar soporte para EDCA y TXOP así como Power Save
Certification.
802.11n
Previsto para finales de 2009 802.11n debería ser capaz de trabajar tanto en banda de 2.4GHz como en banda de 5GHz,
siendo compatible con todas las revisiones anteriores y alcanzando una velocidad teórica mayor de 600 Mbit/s.
También se espera que el alcance de operación de las redes sea mayor gracias a la tecnología MIMO (Multiple Input –
Multiple Output), que permite utilizar varios canales a la vez para enviar y recibir datos gracias a la incorporación de
varias antenas.
Actualmente ya existen varios productos que cumplen el segundo borrador de la revisión 'n' con un máximo de 300
Mbps (80-100 estables).
802.11w
Todavía no concluido. TGw está trabajando en mejorar la capa del control de acceso al medio de IEEE 802.11 para
aumentar la seguridad de los protocolos de autenticación y codificación. Se intenta extender la protección que aporta
802.11i en los datos a las tramas de gestión.
Resumen de revisiones
Aunque se usan los términos “estándar” y “revisión” (amendment) para referirse a las diferentes variantes de IEEE
802.11, oficialmente solo existe un estándar llamado IEEE 802.11, siendo la versión actual del estándar la IEEE
802.11-2007. Sin embargo el estándar se va actualizando con revisiones creadas por grupos de trabajo (TG: Task
Group) identificados por una letra minúscula. Por ejemplo el grupo de trabajo TGm se encarga de actualizar 802.11 y
realizar aclaraciones e interpretaciones de los documentos publicados para la industria.
Independientemente de los estándares están las certificaciones de la Wi-Fi Alliance, como WMM, que se basan en los
estándares, revisiones y borradores de IEEE.
Revisión Notas Banda Velocidad Publicación

802.11-1997 Legacy IR / 2.4GHz 1 o 2 Mb/s 1997
802.11a Banda de 5 GHz 5 GHz 54 Mb/s 1999
802.11b Primero con gran aceptación comercial 2.4 GHz 11 Mb/s 1999
802.11g Revisión de b 2.4 GHz 54 Mb/s 2003
802.11h Revisión de a para Europa 5 GHz 54 Mb/s 2003
802.11i Mejoras en la seguridad (WPA, WPA2) 2004
802.11e Mejoras QoS (EDCA y HCCA) 2005
802.11n MIMO 2.4 y 5 GHz >600 Mb/s* 2009*
802.11w Seguridad en tramas de gestión 2008-2009*
* Previsto
Redes de comunicaciones 6. PROTOCOLOS WAN
6. PROTOCOLOS WAN
6.1. Portadora-T y PDH (Plesiochronous Digital Hierarchy)
El sistema portadora-T fue introducido por Bell System en los Estados Unidos en los años 60 y se utiliza principalmente
en EE.UU. y Japón. A partir de ella e impulsada en Europa se desarrolló la jerarquía digital plesiócrona39 o PDH
(Plesiochronous Digital Hierarchy) también conocida como portadora-E. PDH tiene mayor capacidad porque
presupone el uso de líneas más fiables, eliminando sobrecarga del control de errores.
El sistema PDH es un protocolo de capa física (N1) basado en líneas dedicadas enteramente digitales. Usando
modulación de pulso y multiplexación de división de tiempo permite enviar varios canales sobre un mismo medio. Por
tanto cada línea se compone de varios canales básicos. Al agrupar canales hay que añadir bits de sincronismo y
entramado porque el reloj de cada canal es independiente.
El sistema utiliza conexiones full-dúplex, originalmente mediante dos pares trenzados de cobre y actualmente también
sobre coaxial, microondas o fibra óptica. Sin embargo este diseño no obtiene un buen rendimiento sobre fibra, por lo
que está siendo sustituido por las redes SONet/SDH.
La línea digital E1 consiste en 32 canales de 64 Kbps multiplexados (2 Mbps)40. Un enlace E1 estructurado utiliza un
canal para sincronización y uno para entramado. Un enlace E1 no estructurado, utilizado como línea punto a punto,
utiliza los 32 canales para datos.
En el sistema portadora-E al canal básico de 64 kbps se le llama a veces línea E0.
Protocolo Capacidad Canales por línea Interfaz

E1 2 Mbps 30 canales + sinc. + entram. V.35
E2 8 Mbps 4 x E1 + sinc. + entram. -no se comercializan (se utilizan enlaces E1 en paralelo)-
E3 34 Mbps 4 x E2 + sinc. + entram. HSSI (High Speed Serial Interfaz)
E4 140 Mbps 4 x E3 + sinc. + entram. -no se comercializan-
Sus principales inconvenientes son:

● Los sistemas de portadora-T y portadora-E no son compatibles, aunque pueden interconectarse.
● Fue diseñado para utilizar señales eléctricas o microondas y no utiliza eficazmente la fibra óptica .
● No dispone de un buen sistema de gestión ni de redundancia.
● Los bits de relleno utilizados para forzar el sincronismo impiden extraer un canal de voz directamente cuando
se encuentra en una trama de jerarquía superior (E1, E2, E3) necesitándose descomponer completamente la
trama para extraer el canal y volver a componer una trama. Esto requiere equipos muy costosos y complejos en
las centrales.
39 Deriva del griego plesio -cercano- y chronos -tiempo- y se refiere a que los canales de PDH están casi, pero no completamente, sincronizados.
40 La línea digital T1 utiliza 24 canales de 64 Kbps (1,5 Mbps).
6.2. X.25
El protocolo X.25 fue el primer protocolo que utilizaba la RTC en ser estandarizado por el antiguo CCITT (ahora ITU)
en 1976. Diseñado para líneas de comunicación poco fiables (con muchos errores de transmisión), ofrece un servicio
fiable orientado a conexión (circuitos PVC y SVC), que garantiza que los paquetes llegan en el mismo orden que
salieron. Para ello utiliza la técnica de store-and-forward con confirmación de llegada en cada nodo, unido a un
protocolo de ventana deslizante y un tamaño de trama pequeño (128 bytes).
Especifica los tres niveles inferiores del modelo ISO OSI:
● Define dos niveles físicos posibles: X.21 (digital) y X.21bis (analógico).
● El nivel de enlace se llama LAP-B (Link Access Procedure-Balanced).
● El nivel de red se llama PLP (Packet Layer Protocol) y el direccionamiento está estandarizado a nivel
internacional (X.121).
Los protocolos de nivel 2 y 3 son complejos, por ello hay unos aparatos llamados PAD (Packet Assembler
Dissasembler) que realizan las funciones de estos niveles para conectar equipos terminales poco potentes.
Sus velocidades típicas oscilan entre 9,6Kbps a 64kbps, siendo el costo proporcional al tiempo de duración del circuito
y al número de paquetes enviados. No es apto para tráfico en tiempo real y en la actualidad está siendo totalmente
reemplazado por otros protocolos como Frame-Relay.
6.3. RDSI
La Red Digital de Servicios Integrados (RDSI o ISDN: Integrated Services Digital Network) es una red que provee
conexiones digitales extremo a extremo para proporcionar una amplia gama de servicios, tanto de voz como de otros
tipos, y a la que los usuarios acceden a través de un conjunto de interfaces normalizados, independientemente de la
naturaleza de la información a transmitir y del equipo terminal que la genere.
Los protocolos de acceso RDSI presentan una arquitectura de capas que se puede hacer corresponder con la del modelo
OSI, con gran variedad de configuraciones.
RDSI proporciona conexiones de conmutación de circuitos y de datagramas a 64 kbps bajo demanda, siendo su coste
proporcional al tiempo de uso (aunque pueden contratarse tarifas planas).
Otras ventajas son:
● Establecimiento de conexión en un tiempo muy corto (entre ½ y 2 segundos) lo que permite que se realice la
llamada cuando se necesite enviar datos para enviar.
● El receptor puede identificar al número que llama, con lo que se pueden establecer mecanismos de seguridad.
Existen dos tipos de canales:

● B -bearer- para transmisión de datos a 64Kbps
● D -data- de señalización y administración que siempre está activo. Puede ser de 16 (BRI) o 64 (PRI) kbps.
También existen dos tipos de acceso al servicio:

● Básico (BRI: Basic Rate Interface): 2B + 1D (16 kbps). Orientado a PyMEs y domicilios. El interfaz físico se
llama TR1 (Terminador de Red 1 o NT1: Network Terminator) y se conecta mediante RJ45 usando dos pares
para datos y dos para alimentación eléctrica.
● Primario (PRI: Primary Rate Interface): Si se implementa sobre T1 (EEUU y Japón) son 23B + 1D. Si se
implementa sobre un E1 se utilizan 30B + 1D y el canal restante se utiliza para sincronismo.
Los canales B se pueden utilizar agregados o independientemente tanto para voz como para datos. Sus usos principales
son: conexión de centralitas digitales privadas (PBX) a la red telefónica; videoconferencia (estándar H.320 con 2
canales B -128 kbps- o 6 canales B -384 kbps-); transmisión de varios canales de audio (conexiones de radio); y
transmisión de datos, actualmente como servicio de apoyo a otras líneas en horas punta, o como conexión redundante.
6.4. FDDI (Fiber Distributed Data Interface) / CDDI

FDDI comenzó a ser desarrollado por el comité de estándares ANSI X3T9.5 en 1983 para constituir una LAN
alternativa a Ethernet y Token Ring que además ofreciese una mayor fiabilidad. En la actualidad, en redes LAN se
prefiere utilizar Fast/Gigabit Ethernet.
FDDI es un estándar de transmisión basado en un doble anillo con token bus en direcciones contrarias. Puede
extenderse hasta 200 kilometros y permitir miles de usuarios, por lo que se ha utilizado también como WAN.
En caso de utilizarse cobre en vez de fibra como soporte, se llama CDDI.
6.5. FRAME-RELAY
Introducción
Frame-Relay es un protocolo de nivel 2 utilizado principalmente para interconectar redes LAN. Se basa en la utilización
de la infraestructura de red disponible por los prestadores de servicio público, aunque puede ser también implementada
sobre líneas dedicadas.
Frame Relay surgió como es el sucesor de la tecnología X.25, y está pensada para capas físicas con bajas tasas de
errores y velocidades relativamente altas (de hasta 2 Mb/s, aunque podría funcionar sin problemas a velocidades
mayores). El único control de errores que realiza es la verificación de tramas, sin realizar acuse de recibo. En caso de
detectar una trama errónea la descarta, pero no solicita retransmisiones.
La tecnología Frame Relay se basa en la utilización de circuitos virtuales (VC: Virtual Circuits) tanto permanentes
como conmutados (PVCs y SVCs). Los circuitos virtuales son caminos bidireccionales, establecidos entre dos puntos
extremos de la red Frame Relay. Existen dos tipos de circuitos virtuales:
● PVC (Permanent VC): Los PVC son circuitos virtuales permanentes -independientemente del tráfico-
establecidos por el operador de red. Los PVC son definidos de forma estática, y se requiere la intervención de
un operador para establecerlos y liberarlos. Son los más utilizados en Frame Relay.
● SVC (Switched VC): Son circuitos que se establecen de forma dinámica en el momento de establecer la
conexión. La implementación de circuitos virtuales es más compleja que la de circuitos permanentes, pero
permite, en principio, conectar cualquier nodo de la red Frame Relay con cualquier otro.
Cada nodo dispone de un enlace Frame-Relay sobre el que se pueden establecer distintos circuitos. Cada nodo se
identifica con un DLCI (Data Link Connection Identifier) local a cada conmutador, el cual lo puede cambiar cuando
reenvía la trama. Para establecer circuitos conmutados se utiliza señalización fuera de banda a través del DLCI 0.
Características de los circuitos

Las características de los circuitos depende del servicio contratado. Las velocidades de acceso típicas están entre
64kbps y 2Mbps -aunque hay mayores-. Además en el contrato se fija un ancho de banda garantizado para el circuito
virtual (CIR: Commited Information Rate) y un margen de tolerancia que se permite rebasar (EIR: Excess Information
Rate) en caso de que haya ancho de banda disponible.
El usuario puede enviar hasta CIR+EIR bps, pero al exceder el CIR, los demás paquetes serán enviados en modo Best
Effort y se marcarán con un bit llamado DE (Discard Elegibility) que indica que dichos paquetes se pueden descartar en
caso de congestión en un nodo. Si se supera la cantidad CIR+EIR en un intervalo, las tramas se descartan directamente.
En realidad una de las ventajas de Frame Relay es que las limitaciones se hacen en base a velocidades medias,
adaptándose muy bien al tráfico en ráfagas. De esta forma los valores CIR y EIR surgen de dividir por un tiempo
prefijado “Tc” los valores Bc (Committed Burst Size ) y Be (Excess Burst Size). Al basarse en velocidades medias se
puede usar una mayor velocidad de la contratada en momentos puntuales (incluso por encima de CIR+EIR) siempre que
la media en el intervalo Tc no supere la cantidad estipulada. Como habitualmente Tc es un segundo CIR=Bc y EIR=Be.
El contrato del CIR y EIR puede ser asimétrico y se establece de forma independiente para cada PVC.
En una configuración típica, un “nodo central” puede tener un enlace sobre el que se configuran varios PVCs hacia los
“nodos secundarios”, o sucursales. En el “nodo central” el enlace físico podría ser, por ejemplo, de 1 Mb/s, y cada PVC
disponer de un CIR de 64 kb/s. Esto significa que la velocidad media garantizada de transmisión entre el nodo central y
los nodos secundarios debe ser 64 kb/s (CIR), aunque la velocidad física del enlace central será de 1 Mb/s.
Se tarifica por cuota fija en función de la velocidad de acceso, de la distancia y del CIR/EIR del circuito contratado.
En España la red de Frame-Relay de Telefónica se llama Red Uno y permite establecer conexiones internacionales.
Tramas Frame-Relay
El tamaño de trama es variable. El máximo depende de las implementaciones (hasta 8kb). Una trama contiene: un
indicador de comienzo de trama que facilita la sincronización (Flag), una cabecera (Header), los datos a transmitir
(Information), y los campos FCS (Frame Check Sequence Field) -un CRC básico- y un nuevo Flag de sincronización
que indica final de trama.
Dentro de la cabecera (2 o 4 bytes) existen muchos formatos diferentes que presentan los siguientes campos:
● DLCI destino: Identificador de 10 bits del destino de la trama.
● DLCI remitente: Identifica la conexión virtual de procedencia. Este valor DLCI es local y se modifica en cada
salto.
● 2 bits AFE (Address Field Extension): Indica que la cabecera está utilizando direcciones más largas de lo
habitual.
● bit FECN (Forward Explicit Congestion Notification): Este bit indica que el nodo que envía la trama ha
detectado congestión en la red en el mismo sentido que va la trama.
● bit BECN (Backward Explicit Congestion Notification): Este bit indica que el nodo que envía la trama ha
detectado congestión en la red en el sentido opuesto al que va la trama.
● bit DE (Discard Eligibility Indicator): Este bit indica que la trama es descartable en caso de congestión. Todas
las tramas que exceden el CIR contratado, son marcadas como “DE”.
● bit(s) EA (Extension Bit): Indica(n) si la cabecera es de 2 o 4 bytes.
Protocolos auxiliares
Aunque Frame-Relay aparece ante otros protocolos, por ejemplo IP, como un protocolo de enlace (N2), para gestionar
los circuitos virtuales utiliza a su vez un protocolo de enlace llamado LAPF, que se encarga de gestionar los bits FECN,
BECN y DE.
Por otra parte LMI (Local Management Interface) es un protocolo que se implementa de forma opcional, pero habitual,
en las instalaciones de Frame-Relay y permite el intercambio de información entre equipos de clientes y equipos del
prestador de servicios mediante el uso de tramas especiales de administración, que disponen de números de DLCI
reservados para estos fines.
Esta información de administración incluye:
● Indicación de que la interfaz está activa (keep alive).
● Información de los DLCIs definidos en la interfaz.
● Información sobre el estado de cada circuito virtual, por ejemplo, si está congestionado o no.
6.6. ATM (Asynchronous Transfer Mode)

Introducción
ATM es una arquitectura de red de cuatro capas diseñada para presentar circuitos virtuales que permitan integrar voz,
datos y vídeo (red multimedia). Surgió como respuesta a la necesidad de tener una red multiservicio que pudiera
manejar velocidades muy dispares, con altos picos de transmisión y dispositivos de diferentes velocidades. Funciona
tanto en medios ópticos como eléctricos.
A veces se llama RDSI de banda ancha y en cierto sentido es una evolución de Frame Relay.
Los protocolos de ATM están estandarizados por la ITU-T, con especial contribución del “ATM Forum41” y si bien
pueden ser utilizados en LANs, se usan principalmente en las redes de espinazo (backbone) de los proveedores de
servicios públicos. Sin embargo parece tener poco futuro debido a la aparición de GigaEthernet y de PoS (Packet Over
SONet/SDH).
Algunas de las ventajas de ATM frente a otras tecnologías son:

● Alto rendimiento, realizando las operaciones de conmutación a nivel de hardware.
● Ancho de banda dinámico, para permitir el manejo de picos de tráfico.
● Soporte de “clase de servicio” para aplicaciones multimedia (QoS).
● Escalabilidad en velocidades y tamaños de redes. ATM puede utilizar desde redes E1/T1 hasta redes
SONet/SDH soportando velocidades que oscilan entre 1.5 Mb/s y 2 Gb/s.
● Arquitectura común para las redes de LAN y WAN.
● Permite establecer conexiones punto a punto o punto a multipunto unidireccional. No soporta multicast, pero
puede ser simulado.
Permite establecer circuitos virtuales permanentes (PVC) -configurados estáticamente- o conmutados (SVC) mediante
señalización Q2931 a través de los circuitos reservados VPI 0 VCI 5.
Siguiendo el estándar OSI NSAP, las direcciones ATM son de 20 bytes: 13 bytes identifican la red, 6 el equipo y el
último la entidad en el equipo.
El primer byte marca la utilización de uno de los 3 formatos posibles de dirección. Uno de los formatos incluye
direcciones E.164 (tradicionales de telefonía internacional)42 codificadas en los 20 bytes.
Permite contratar características diversas de un circuito virtual:

● Ancho de banda máximo
● Ancho de banda mínimo garantizado
● Margen de tolerancia
● Ancho de banda asimétrico
● Perfil horario
● Prioridades
Además define cuatro compromisos distintos de calidad (QoS):

● CBR (Constant Bit Rate): Garantiza capacidad constante reservada en todo el trayecto.
● VBR (Variable Bit Rate): Para tráfico a ráfagas. Se fija un caudal medio garantizado.
● ABR (Available Bit Rate): Fija un mínimo garantizado y un máximo orientativo. Informa de congestión.
● UBR (Unspecified Bit Rate): Sin garantías.
41 Organización voluntaria internacional, formada por fabricantes, prestadores de servicio, organizaciones de investigación y usuarios finales.
42 Por ejemplo 34961234567@timofonica.com, que se correspondería con el número 34961234567 en la RTC.
Los nodos de la red se llaman conmutadores ATM y los terminales equipos (hosts). De forma similar al modelo OSI,
ATM también está diseñada en un modelo de capas. En el caso de ATM, el modelo de capas puede verse en dos
“planos”, uno de gestión con una sola capa y otro de transmisión dividido en 4 capas:
● Física. Dividida en:
○ PMD (Physical Media Dependent) Equivale a la física de OSI
○ TC (Transmisión Convergente) Equivale a enlace OSI
● ATM. Realiza tareas de señalización, transporte y control de congestión. Está a caballo entre las capas de
enlace y de red de OSI.
○ El algoritmo de encaminamiento dinámico entre conmutadores se llama P-NNI y es parecido al OSPF.
● AAL (ATM Adaptación Layer). Equivale a la de transporte OSI y se divide en:
○ SAR (Segmentation and Reassembly) Se encarga de fragmentar paquetes en celdas y reensamblarlos.
○ CS (Convergence Sublayer) Ofrece los tipos de servicio
● Aplicación. No se define. Se deja total libertad. En realidad hay muy pocas aplicaciones diseñadas para ATM.
Se suele utilizar para transportar otros protocolos de nivel 3 (como IP).
Funcionamiento
No envía acuse de recibo. Los paquetes -llamados celdas- son de longitud fija y tienen 53bytes (5 de cabecera y 48 de
datos). Esto permite dos cosas: que una celda de mayor prioridad no espere mucho tiempo porque hay otra de menos
prioridad enviándose (y no se puede suspender el envío); y también reduce la complejidad del conmutador y puede ser
más rápido. El inconveniente es una sobrecarga (overhead) de 5/53 (casi un 10%).
De los 5 bytes de la cabecera hay que destacar los campos VPI (Virtual Path Identifier) y VCI (Virtual Channel
Identification) que son los campos que utilizan los conmutadores para saber por qué puerto hay que enviar la celda.
Estos campos tienen sentido local al conmutador y pueden cambiarse al pasar de un conmutador a otro.
Hay un bit (CLP Cell Loss Priority) para identificar si la celda es más o menos susceptible de ser descartada en
momentos de congestión y un campo HEC (Header Error Control) que es un checksum de cabecera.
La sincronización entre equipos para delimitar donde empieza cada celda se hace calculando los checksums de cabecera
(HEC) hasta encontrar una secuencia de bytes que cumple la función del checksum.
Se definen dos tipos de interfaz:

● UNI (User-Network Interface): entre el equipo de usuario y el conmutador. Normalmente versión 3.0 o 3.1.
● NNI (Network-Network Interace): entre dos conmutadores.
6.7. Redes de fibra SONet / SDH

Las redes SONet (Synchronous Optical NETworking) y SDH (Synchronous Digital Hierarchy), son protocolos de nivel
1 basados en multiplexado de tiempo (TDM: Time Division Multiplexing) para transferencia de datos sobre fibra óptica
usando LEDs o ILDs. Están estandarizados por el ANSI y el ITU-T respectivamente y son compatibles, aunque una se
utiliza sobre T3 y la otra sobre E3 -o sobre fibra-.
Ofrecen circuitos permanentes full-dúplex y se comporta como un medio físico de transmisión de bits. Se utilizan
principalmente como nivel físico de ATM, PoS o 10GbE (Ethernet a 10 Gb).
Las tramas básicas de transmisión son:

SONet Eléctrico – STS SONet Óptico – OC SDH Óptico – STM Velocidad
(Synchronous Transfer Signal) (Optical Carrier) (Synchronous Transport Module) (Mb/s)
STS-1 OC-1 STM-0 51,84
STS-3 OC-3 STM-1 155,52
STS-12 OC-12 STM-4 622,08
STS-48 OC-48 STM-16 2.488,32
STS-192 OC-192 STM-64 9.953,28
De esta manera se garantiza la compatibilidad entre ambas si se utilizan múltiplos de 3. Cada trama STM está
compuesta por 4 de las anteriores. Una trama STM4 lleva 4 tramas STM-1. Una trama STM-1 puede llevar 3 E3 o 1 E3
y 32 E1, etc.
Una red SDH está formada por repetidores, multiplexores y conmutadores interconectados por fibra óptica
habitualmente con topología de doble anillo para mantener redundancia (como la de FDDI). El tiempo de reacción a un
corte del anillo es de 50ms.
Los multiplexores se llaman ADM (Add-Drop Multiplexor) y se encargan de extraer e inyectar tramas de menor nivel
en otras de mayor nivel. El tramo que recorre un circuito completo se llama ruta, el que comunica dos equipos sección y
el que une dos ADMs contiguos línea.
6.8. PoS (Packet Over SONet/SDH)

Implementa PPP (Point-to-Point Protocol) directamente sobre SONet/SDH. Es una alternativa a ATM sobre
SONet/SDH para redes IP43 que reduce la sobrecarga (overhead) y la complejidad de ATM. Además, suprime la
necesidad de conmutadores ATM y conecta los encaminadores directamente a los ADM de SONet/SDH. Sin embargo,
al suprimir la capa ATM, no se puede establecer circuitos virtuales, solo redes de datagramas (p.e. IP).
La multiplexación se ha de hacer a nivel de circuitos SONet/SDH.
Si se dispone de un cableado de fibra entre dos encaminadores con interfaz PoS, se puede suprimir los equipos SDH y
conectarlos directamente. Esto permite crear redes IP sobre PoS pero sin electrónica añadida.
6.9. GSM (Global System for Mobile comunications)

GSM es un protocolo de comunicaciones telefónicas móviles que permite formar circuito reales digitales por
radioenlace. Se considera la segunda generación de sistemas de telefonía móvil, siendo la primera analógica y la tercera
UMTS. Por tanto forma parte de la RTC.
El espacio geográfico es dividido en células con una estación base en su interior y un grupo de frecuencias propio. El
usuario se comunica con la estación base que corresponde a la célula donde se encuentra. Si se desplaza a otra célula
contigua cambia automáticamente de estación base (roaming).
Dos células contiguas no pueden utilizar el mismo grupo de frecuencias por lo que, siendo la estructura como la de un
panal, se necesitan 7 grupos de frecuencias diferentes.
El rango de frecuencias de una célula se divide en canales de 200 KHz de anchura. Unos se utilizan para comunicación
ascendente (hacia la estación base) y otros para la descendente (desde la base).
Cada canal soporta 8 circuitos de voz o datos multiplexados en el tiempo. La voz se transmite digitalizada y
comprimida a 13,6 Kbps. Para datos sólo se puede transmitir a 9,6 kbps.
El número de usuarios simultáneos que soporta una célula está limitado por el número de canales que puede utilizar,
que es fijo. Para aumentar este número hay que dividir la célula en otras más pequeñas poniendo más estaciones base
con menos alcance (menos potencia). El teléfono adapta su potencia en función de la proximidad de la estación base.
En Europa se utiliza en dos bandas de frecuencia, entorno a 900 MHz y a 1800 MHz (GSM 900 y GSM 1800), mientras
que en EE.UU. se utiliza en la banda de 1900 MHz (GSM 1900) y en el Sureste Asiático y Japón a 850 MHz (GSM
850).
6.10. GPRS (General Packet Radio Service)

GPRS es un protocolo de conmutación de paquetes sobre GSM, es decir para transmisión de datos sobre redes de
móviles. Su velocidad máxima teórica es de 171,2 kbps, pero en la práctica es menor. A los dispositivos móviles que
utilizan esta tecnología se les conoce como de generación 2.5 (2.5G).
6.11. UMTS (Universal Mobile Telecommunications System)

Red digital por microondas para teléfonos móviles. Se considera la tercera generación de sistemas de telefonía móvil,
siendo la primera analógica y la segunda GSM. Por tanto forma parte de la RTC.
El estándar de ITU IMT-2000 (International Mobile Telecommunications-2000) garantiza que todas las redes 3G sean
compatibles unas con otras.
Los servicios que ofrecen las tecnologías 3G son básicamente: acceso a Internet, servicios de banda ancha, roaming
internacional e interoperatividad, con una velocidad máxima de 2 Mbit/s en condiciones óptimas.
43 En caso de querer enviarse tráfico no IP, debe encapsularse sobre IP.
6.12. Redes de satélites

Se utilizan para cubrir grandes distancias y para llegar a sitios donde no hay infraestructura de comunicaciones.
Utilizan frecuencias del orden de GHz y rangos distintos para comunicaciones ascendentes y descendentes.
Los satélites se comportan como repetidores con velocidades típicas de entre 300 kbps y 2 Mbps y pueden dirigir el haz
a una zona concreta (250 km) pero todas las estaciones de esa zona recibirán la señal, por lo que los datos deben ir
cifrados.
Hay satélites geoestacionarios que permanecen fijos en el cielo y permiten utilizar antenas parabólicas direccionales y
fijas. Están a 36000 Kms de altura y eso hace que las comunicaciones tengan una alta latencia.
Hay proyectos de satélites de baja órbita (menor altura y por tanto menor latencia) pero al no estar fijos en el cielo
aparecen y desaparecen, por lo que hay que crear una malla de satélites en el cielo para que en un punto de la tierra
siempre haya alguno a la vista (como hace por ejemplo GPS).
Los problemas técnicos más importantes son debidos a que es un medio de multi-difusión y al control de acceso al
medio (MAC) debido a que las estaciones no se ven entre sí y a las largas distancias del medio.
Dado que los equipos de emisión son caros, se pueden plantear para recibir información, utilizando las líneas
telefónicas para las subidas de datos, creando una conexión altamente asimétrica.
6.13. MPLS (Multi-Protocol Label Switching)

Más que un protocolo de red es una técnica utilizada por los encaminadores del núcleo de Internet. Dado que el análisis
de destino de un paquete IP es muy costoso, cuando la tabla de encaminamiento es muy grande, es más sencillo y
rápido comparar etiquetas como hace ATM (con los campos VPI VCI). La etiqueta, como en ATM sólo tiene sentido
local y cada encaminador la va cambiando.
Para agilizar el proceso, los llamados “edge routers” (encaminadores del borde de Internet) añaden a los paquetes, una
vez resuelto su destino, una cabecera especial con una etiqueta identificando el flujo al que pertenece. Los siguientes
encaminadores sólo tienen que fijarse en esa etiqueta. A la salida del núcleo, el último “edge router” elimina la
cabecera MPLS.
Redes de comunicaciones 7. MÉTODOS DE ACCESO A REDES
7. MÉTODOS DE ACCESO A REDES

7.1. Introducción
Existen métodos diseñados para acceder a las redes de comunicaciones que se caracterizan por comunicar equipos de
manera jerárquica: generalmente un equipo “usuario” o “cliente” y un equipo “proveedor”, “servidor” o “central” que
depende de los llamados “proveedores de acceso” cuyo servicios suponen un coste para el usuario. En algunos textos se
les llama “Redes de Acceso”, aunque en este se prefiere “Métodos de Acceso a Redes” por coherencia con la definición
dada de redes de comunicaciones44.
7.2. Módems
Un módem es un dispositivo que sirve para modular y demodular (en amplitud, frecuencia, fase u otro sistema) una
señal llamada portadora mediante otra señal de entrada llamada moduladora.
Su uso más común y conocido es para realizar transmisiones de datos por vía telefónica ya que mientras las
computadoras procesan datos de forma digital las líneas telefónicas de la RTB sólo transmiten señales analógicas.
Además de los módems telefónicos existen otros módems como los módems xDSL o módems utilizados para
transmisiones radiofónicas y de televisión.
Los métodos de modulación y otras características de los módems telefónicos están estandarizados por el UIT-T (el
antiguo CCITT) en la serie de Recomendaciones "V" que determinan la velocidad de transmisión. Así podemos
encontrar desde el V.32. (transmisión a 9.600 bps) hasta el V.92 (transmisión a 56'6 kbps con compresión de datos y
llamada en espera).
Las características que se pueden modificar de la señal portadora son:

● Amplitud, dando lugar a una modulación de amplitud (AM/ASK).
● Frecuencia, dando lugar a una modulación de frecuencia (FM/FSK).
● Fase, dando lugar a una modulación de fase (PM/PSK)
También es posible una combinación de modulaciones o modulaciones más complejas como la Modulación de amplitud
en cuadratura.
7.3. xDSL
Introducción
La tecnología xDSL (Digital Subscriber Line: Línea de Abonado Digital) es una evolución de los módems telefónicos
que utilizan un espectro de frecuencias situado por encima de la banda vocal (300 - 3.400 Hz) e incluso por encima de
los 25 KHz ocupados en las líneas RDSI, y permiten alcanzar velocidades mucho mayores que un módem telefónico
convencional, al mismo tiempo que se puede establecer comunicaciones telefónicas.
Por tanto permite utilizar para la transmisión de datos la infraestructura existente de RTB de manera transparente para
su uso habitual, es decir sin interferir en el uso telefónico de la línea.
En el nivel de enlace utiliza celdas ATM. O dicho de otra manera, es un nivel físico para ATM. Por ello muchos
proveedores pueden ofrecer servicios xDSL sin disponer de un bucle de abonado propio. En vez de ello contratan con la
compañía proveedora de la RTB para que envíe el circuito ATM a sus conmutadores.
Aún así no se puede usar en cualquier cable de teléfono. Básicamente tiene que cumplir dos condiciones:
– que el cable esté en buen estado y no sea muy viejo, lo que impide su utilización en zonas y países con un mal
mantenimiento de líneas telefónicas
– que el terminal (el módem) no esté a más de una distancia determinada de una central digital. En general se da por
buena una distancia máxima de 5,5 Km, con una distancia óptima inferior a 2 Km.
Esto hace que xDSL resulte económico en países con una infraestructura adecuada e inviable en zonas con malas
infraestructuras
44 Conjunto de medios técnicos que permiten la comunicación a distancia entre equipos autónomos (no jerárquica -master/slave-).
La voz humana usa normalmente frecuencias entre 0 y 4 Khz45. El sistema xDSL aprovecha la capacidad de la línea
para transmitir datos en una banda de frecuencia más alta que la que se utiliza para transmitir voz. Así se puede
transmitir voz y datos a la vez. Para evitar que se oiga un ruido de fondo en el teléfono se añaden filtros (splitters) a la
conexión del teléfono. Al llegar a la central, los datos viajan por una red de datos separada de la de voz.
La banda de frecuencia utilizada para la transmisión de datos se divide en tres canales: subida, bajada y control. Es
decir, en total se utilizan cuatro canales: el de voz y los tres de transmisión de datos.
La técnica de modulación más utilizada es la DMT (Discrete Multi Tone) estandarizada por el ITU-T. Consiste en
dividir la gama de frecuencias en 256 subcanales denominados “bins” de 4,3125 KHz de anchura, que xDSL maneja de
forma independiente. Esto permite que si hay ruido en una frecuencia se deje de utilizar solo un bin pero se siga
aprovechando el resto. La capacidad exacta de datos por canal depende de la modulación.
Los 6 primeros se reservan para la voz y el RDSI (25,875 KHz), los siguientes se utilizan para subida (según la
capacidad de subida contratada) y los últimos para bajada.
Otra técnica disponible llamada CAP (Carrierless Amplitude Phase) utiliza una filosofía similar pero sin dividir los
rangos ascendentes en bins, con lo que da menor rendimiento, aunque los equipos son más sencillos.
xDSL utiliza transmisión full-duplex síncrona sobre una línea dedicada punto a punto, conocida como bucle de
abonado, entre el módem del abonado (ATU-R) y la central digital del proveedor (ATU-C). Normalmente la central
ATU-C se conecta un conmutador ATM con aparatos conocidos como DSLAM (Digital Subscriber Line Access
Multiplexer).
45 Por teléfono analógico se suelen transmitir entre 300 y 3400 Hz.
Variantes de xDSL
ADSL
La variante de xDSL utilizada en España es el ADSL o Asymmetric Digital Subscriber Line ("Línea de Abonado Digital
Asimétrica"). Esto significa que la velocidad de subida es distinta de la velocidad de bajada.
Por ejemplo, un ADSL2 en España para la subida utiliza las frecuencias 25,875 Khz a 138 Khz y para la bajada de
138-1104Khz. El canal de control se sitúa entre ambos (utiliza un ancho de banda pequeño).
Actualmente se están implantando tecnologías ADSL2 y ADSL2+ cuya diferencia fundamental es la utilización de un
mayor ancho de banda (hasta 2,2 MHz), lo que permite en el caso del ADSL2 dar mayores velocidades de carga y
descarga y en el caso del ADSL2+ utilizar uno de los rangos para enviar una señal de televisión.
ADSL (T1.413) ADSL2 (G.992.3/4) ADSL2+ (G.992.5)

Frecuencia Máx. 0,5 MHz 1,1 MHz 2,2 MHz
Velocidad Máx. Subida 1 Mbps 1 Mbps 1,2 Mbps
Velocidad Máx. Bajada 8 Mbps 12 Mbps 24 Mbps
Distancia Máx. 2 Km 2,5 Km 2,5 Km
Tiempo Sincronización 10-30s 3s 3s
Corrección de Errores No Sí Sí
ADSL G.Lite
Permite prescindir del filtro en la vivienda a costa de suprimir frecuencias y utilizar una modulación más pobre,
obteniendo peores rendimientos.
RADSL (Rate Adaptative ADSL)

Negocia dinámicamente frecuencias con el otro extremo para suprimir o recuperarlas en función de las fluctuaciones del
ruido.
VDSL (Very high speed DSL)

Permite velocidades muy grandes pero a muy cortas distancias.
HDSL (High Data-rate DSL)

Consigue altas velocidades sobre varios pares telefónicos en paralelo.
No es útil en el hogar porque no hay varios pares instalados y además no reserva las frecuencias de la voz.
Se suele utilizar para enviar líneas E1 sobre dos pares de hilos telefónicos.
SDSL (Symetric DSL)

Similar a HDSL pero sobre un solo par de hilos.
7.4. CATV (Redes de TV por cable)

Las redes CATV surgen para distribuir la señal de TV a zonas donde no se recibían bien las ondas. Utilizaba cable
coaxial de 75 ohmios y amplificadores cada ½ o 1 km. Los amplificadores degradaba la señal y se comportaban como
válvulas que impedían señales ascendentes.
Las redes más modernas -entre ellas casi todas las europeas- son del tipo HFC (Hibrid Fiber Coaxial). Estas redes
distribuyen la señal desde la cabecera -proveedor- hasta la manzana -residencias- por fibra y llegan a las viviendas por
cable coaxial46. Tienen menos de 5 amplificadores y son de un tipo que permiten utilizar las frecuencias inferiores en
sentido contrario (de subida), por lo que se pueden utilizar para transmisión bidireccional de datos.
En la cabecera de la red hay un equipo especial llamado CMTS (Cable Modem Termination System) y en las viviendas
de los usuarios se instala un equipo llamado CM (Cable Modem). Normalmente, la compañía configura el cable módem
para que no rebase un caudal contratado.
La transmisión de datos se hace modulada en un canal de TV reservado. Se utilizan frecuencias y modulaciones

diferentes para las señales de subida y de bajada debido a la diferencia de relación señal/ruido de dichas frecuencias en
el cable.
El medio de transmisión es asimétrico. Además es poco fiable, por lo que se utilizan códigos de corrección Reed-
Solomon que suponen un 10% de sobrecarga.
Cada CM solo puede comunicarse con el CMTS que se comporta como un puente remoto. Todos los CMs de un
segmento comparten el medio físico y tienen que compartir los canales de datos. Las emisiones del CMTS llegan a
todos los CM del segmento, por lo que la información debe viajar cifrada.
Para competir por el canal ascendente hacia el CMTS se utiliza un protocolo basado en créditos. El canal ascendente se
divide en intervalos de tiempo llamados “minislots”. El CMTS informa a los CM a través del canal descendente (junto
con los datos) del mapa de asignación de minislots.
46 Según donde acabe la fibra: FTTN / FTTC / FTTB / FTTH (Fiber to the Node / Curb / Building / Home)
Hay tres tipos de minislots:

● Asignados a un CM en concreto para que envíe datos. Los demás deben permanecer callados.
● De contención, en los cuales los CM compiten por los minislots con un protocolo de tipo Aloha. Si hay
colisión los CM no se enteran directamente, pero la detecta el CMTS y les informa.
● De mantenimiento. Para la inicialización de CM y el mantenimiento y sincronización de los relojes y la
potencia de los CM. Debido a la distancia, es muy importante que se adapten los relojes y la potencia para que
todos lleguen con la misma intensidad al CMTS y éste pueda detectar las colisiones.
7.5. LMDS (Local Multipoint Distribution System)

LMDS es una tecnología inalámbrica de red que se utiliza para transmitir voz, datos y servicios de vídeo en la banda de
frecuencias superiores a 20 GHz (microondas), según licencias. Se diseñó para reemplazar las redes CATV con una
mayor velocidad de despliegue. Sin embargo no llegó a cuajar en el mercado.
Para el canal descendente se utiliza emisión multidifusión omnidireccional y para el ascendente se puede utilizar
telefonía o emisión dirigida con parabólica.
Su alcance se ve afectado por la lluvia y necesita visión directa. Entre 3 y 9kms.
Su despliegue puede ser mucho más rápido que otro tipo de redes, pero el retorno telefónico es lento y el de antena
parabólica caro.
Redes de comunicaciones 8. REDES PRIVADAS VIRTUALES
8. REDES PRIVADAS VIRTUALES

8.1. Introducción
Se entiende por VPN (Virtual Private Network) la construcción de una red privada (intranet) sobre otra red,
generalmente pública como Internet, de manera que se utiliza la red inicial como un enlace de nivel 2 para montar sobre
él una red privada de nivel 3 (transportando protocolos de nivel 3 como IP, NetBEUI, IPX, SNA…).
Para conseguir esta abstracción se basa en el concepto de túnel que consiste en un enlace punto a punto virtual entre dos
extremos construido sobre una red compleja, de manera que los dos extremos se comportan a nivel lógico como si
estuvieran unidos directamente por un enlace punto a punto.
Los paquetes se encapsulan en un extremo del túnel dentro de otros paquetes para cruzar la red. En el otro extremo se
desempaquetan los datos que pueden haber viajado comprimidos y cifrados (para que la red sea “privada”).
Desde el punto de vista de la seguridad, los protocolos que se utilizan para montar VPNs ofrecen:
● Autenticidad de los extremos. Cuando se utilizan certificados, se garantiza que tanto el emisor como el
receptor son quienes dicen ser.
● Cifrado de datos. Permite que no puedan ser comprendidos por extraños que los pudiera interceptar.
● Integridad de los datos. Asegura que los datos no puedan ser alterados en algún punto del recorrido sin que el
receptor lo detecte.
● No repudio. Cuando un mensaje va firmado el emisor no puede negar su emisión.
Se puede utilizar VPN sobre una red pública para realizar dos tipos básicos de conexión:
● Acceso remoto. También llamada Remote Access VPN, client-gateway o usuario-red. Permite unir
virtualmente un equipo remoto a una red.
● Interconexión de redes. También llamada Site to Site VPN, Router to Router VPN, gateway-gateway o red-
red. Permite unir virtualmente dos redes para crear una única red.
De manera similar, se puede utilizar VPN sobre una red privada para acceder a una subred protegida y/u oculta de dos
maneras básicas:
● Acceso privado. Permite controlar el acceso a la subred oculta y cifrar el tráfico hacia dicha red.
● Interconexión de redes privadas. Permite unir dos subredes protegidas y/u ocultas cifrando el tráfico entre
ellas.
Para poder configurar cualquier VPN hace falta al menos un servidor de VPN por cada red que forma parte de la VPN,
y un cliente de VPN por cada cliente de acceso remoto que se conecta a la misma. El servidor VPN es el encargado de
autenticar la conexión (o delegar dicha función) y permitir la comunicación entre la red y el otro extremo de la VPN.
TAP/TUN
Para la realización de VPNs se utiliza habitualmente dos controladores virtuales de red llamados TAP y TUN. TAP (de
"network tap") simula un dispositivo de red de nivel 2 y opera con paquetes Ethernet. TUN (de "network TUNnel")
simula un dispsitivo de red de nivel 3 y opera con paquetes IP. TAP se utiliza para crear el puente de red y TUN para
encaminar los paquetes por dicho puente.
VPN de acceso remoto

En una conexión VPN de acceso remoto, el cliente, a través del protocolo IPCP (IP Control Protocol) de PPP (Point-to-
Point Protocol) recibe del servidor VPN los parámetros de la configuración IP de su conexión virtual, incluyendo
dirección IP, máscara de red y direcciones IP de los servidores DNS y WINS de la intranet.
Después de crear el túnel, el cliente pasa a tener 2 interfaces de red y 2 direcciones IP:
● La interfaz con la que conecta a la red principal (generalmente Internet) y que utiliza para conectar con el
servidor VPN.
● La interfaz virtual PPP con la configuración IP que le ha dado el servidor de túneles y que establece una
ubicación virtual dentro de la red destino.
Además la tabla de rutas se modifica para que el tráfico hacia la red privada se envíe por el túnel VPN y opcionalmente
también el tráfico hacia Internet -lo que permite usar los filtros y servidores de la red privada, normalmente a cambio de
reducir el rendimiento-.
De la misma manera el servidor VPN se encarga de recibir el tráfico destinado al equipo remoto y reenviárselo.
Antes de las VPN para conseguir un acceso remoto a una red se utilizaban sistemas RAS (Remote Access Service)47
mediante PoPs (Point of Presence) de forma parecida al de las conexiones que ofrecían los proveedores de Internet
(ISPs) a través de módems telefónicos. De esta forma un cliente llama mediante módem telefónico al servidor RAS de
su organización, se valida mediante un servidor RADIUS o TACACS y establece la conexión. Opcionalmente el
servidor RAS puede configurarse para devolver la llamada, cargando el gasto de la misma a la organización.
Las principales ventajas de la conexión VPN frente a la conexión mediante RAS son:
● Para clientes de acceso remoto vía módem supone una reducción del coste de las llamadas, ya que conecta a un
proveedor local de Internet y no a un servidor RAS de la organización remota.
● Reducción del coste de los equipos y líneas de entrada (RDSI) que representa el RAS.
● Escalabilidad. Es mucho más fácil y barato de añadir servidores VPN que líneas de acceso y equipos de RAS.
● Permite acceso a mayor velocidad que la de un módem telefónico mediante el uso de cable-modems, xDSL u
otras redes.
Otra diferencia es que al usar RAS se dispone únicamente de una sola interfaz de red, la del cliente RAS o PPP.
VPN de Interconexión de redes

La conexión de redes a través de Internet es una alternativa a las líneas alquiladas que permite reducir costes, ya que
suele ser más barato conectar las dos redes a Internet que alquilar una línea para unirlas, sobre todo si están muy
alejadas. Sin embargo esta alternativa tiene dos grandes inconvenientes, la falta de seguridad de Internet y el
rendimiento, que es mucho menor que el de una línea dedicada. Para suplir el primero de ellos se utilizan las VPNs de
interconexión de redes que ofrece seguridad en el túnel entre servidores VPN (no en las conexiones locales equipo-
servidor).
Otras ventajas:
● Toda la configuración necesaria se realiza en los encaminadores o servidores VPN, de manera transparente al
usuario.
● Permite transportar otros protocolos diferentes a IP que no pueden ser transportados sobre Internet si no es con
túneles (IPX, Appletalk , SNA, NetBEUI, etc).
● Se puede introducir compresión de datos para aprovechar mejor los enlaces.
● Se puede utilizar el mismo rango -público o privado- de direcciones IP en todas las redes.
8.2. Autenticación de usuario

La autenticación del usuario se puede realizar mediante un usuario y contraseña, certificados digitales o tarjetas físicas
(tokens) tanto contra el propio servidor VPN como utilizando otro servidor de autenticación, como servidores RADIUS,
TACACS+ , LDAP (mediante NTLM) o Kerberos (en territorios sobre GNU/Linux).
Protocolos
Para realizar la autenticación se pueden usar distintos protocolos como:
● PAP (Password Authentication Protocol). La contraseña viaja en claro por la red.
● CHAP (Challenger Authentication Protocol).
● MS-CHAP (Microsoft CHAP) y MS-CHAP v2.
● Familia EAP (Extensible Authentication Protocol).
● SPAP (Shiva Password Authentication Protocol).
● Acceso sin necesidad de autenticación.
47 Actualmente el servicio de Windows que gestiona las VPNs se sigue llamando RRAS (Routing and RAS).
Aunque el protocolo Kerberos ha sido adoptado por Microsoft para la autenticación en el directorio activo, todavía
utiliza NTLM en determinadas circunstancias:
● Si el cliente se autentica usando una dirección IP.
● Si el cliente se autentica en un servidor de otro bosque del directorio activo o no pertenece a ningún dominio o
no existe ningún dominio.
● Si un cortafuegos corta los puertos necesarios para usar Kerberos.
8.3. Protocolos para la realización de VPNs

Protocolo PPTP (Point to Point Tunneling Protocol)
El protocolo PPTP fue desarrollado por el “PPTP Forum48” para encapsular otros protocolos, como IPX o NetBEUI, a
través de Internet y se propuso al IETF en la RFC 2637. Así su función es encapsular tramas PPP49 sobre IP.
Permite conexiones usuario-red y red-red con compresión y cifrado, pero no es muy seguro. Los servidores de
Microsoft permiten usar MPPE (Ms Point-to-Point Encryption) para cifrar las conexiones VPN establecidas con PPTP.
No necesita infraestructura PKI (Public Key Infraestructure) ya que autentica con los mecanismos de PPP (usuario y
contraseña) en base a EAP, MS-CHAP, MS-CHAPv2, SPAP y PAP.
Es multiprotocolo, permite NAT (Network Translation Protocol) y multidifusión.
L2TP sobre IPSec

El protocolo L2TP es una combinación de PPTP y L2F (protocolo propietario de Cisco). Utiliza UDP a través del
puerto 1701 con dos tipos de paquetes: de transporte de tramas PPP y de control (creación, destrucción y mantenimiento
del túnel). L2TP se encarga de realizar la autenticación de usuario, la asignación de direcciones y el encapsulado de
tramas que pueden ser cifradas y comprimidas.
Permite encapsular tramas de diferentes protocolos sobre IP, X.25, Frame Relay o ATM... aunque en el caso de las
VPNs se encapsulan los paquetes L2TP sobre paquetes IPSec, obteniéndose un sistema seguro de VPN multiprotocolo
que permite NAT y multidifusión, tanto para conexiones usuario-red como conexiones red-red.
En el caso de conexiones VPN de acceso remoto, IPSec se utiliza en modo transporte.
En el caso de conexiones entre redes se utiliza IPSec en modo túnel.
Algunos servidores permiten usar IPSec sobre TCP o UDP (normalmente por el puerto 10000) para poder traspasar
cortafuegos y servidores NAT.
48 En este foro participaron Microsoft, 3Com, Us Robotics entre otros.

49 Las tramas PPP a su vez encapsulan tramas de cualquier paquete de nivel 3.
Redes de comunicaciones 9. SEGURIDAD EN REDES
9. SEGURIDAD EN REDES
9.1. Introducción
Criptología y esteganografía
La criptografía (literalmente "escritura oculta") es la disciplina que se ocupa del conjunto de técnicas para cifrar y
descifrar información haciendo posible el intercambio de mensajes de manera confidencial, es decir de manera que sólo
puedan ser leídos por aquellos a quienes van dirigidos.
El criptoanálisis es la disciplina que se ocupa del conjunto de técnicas para descifrar mensajes en ausencia de las claves
("romper el cifrado").
La criptología es la disciplina que engloba tanto la criptografía como el criptoanálisis.
La esteganografía es la disciplina que se ocupa del conjunto de técnicas que permiten el ocultamiento de mensajes
dentro de otros, llamados portadores, de modo que no se perciba su existencia. En informática probablemente el sistema
esteganográfico más utilizado sea el de ocultar mensajes en imágenes a nivel binario, alterando los bits de menor peso
de determinados píxeles de la imagen e insertando en ellos el mensaje. Esta técnica hace indistinguible al ojo humano la
imagen original de la alterada. Como además los mensajes se guardan cifrados en píxeles determinados por una clave
no es posible saber si una imagen dada lleva un mensaje oculto o no.
Un ejemplo:
Dos presos, Ana y Bob, planean fugarse y para organizarlo necesitan intercambiar mensajes. La única manera de
enviar mensajes es solicitándole a la guardiana Eva que haga de portadora. Si Ana le da a Eva un mensaje para Bob
que dice "Nos fugamos mañana a las 12" no es muy probable que la fuga tenga éxito. Ana puede utilizar la
criptografía para enviar entonces el siguiente mensaje "gdtrhfuwjeldikarstyivh", pero Eva sospechará que algo
ocurre, aunque no sepa qué. Por último Ana puede utilizar la esteganografía para enviar un mensaje en apariencia
normal que oculte el mensaje real para Bob. Este mensaje podría ser, por ejemplo, un poema acróstico50. Para mayor
seguridad Ana podría enviar un mensaje cifrado oculto mediante esteganografía.
En este capítulo nos ocuparemos solo de criptografía y sistemas de seguridad relacionados en redes informáticas.
Criptografía simétrica
La criptografía simétrica utiliza una clave para alterar un mensaje -"cifrado"- de manera que sea necesaria esa misma
clave para recuperar el mensaje original -"descifrado"-. La criptografía de clave simétrica es la más antigua, la más
sencilla (y por tanto la más rápida y eficiente) y la más utilizada. Los primeros sistemas se basaban simplemente en la
trasposición o sustitución de las letras del alfabeto, desde la scitala espartana (cuya clave era la vara o "scitala"), el
atbash utilizado por los hebreos (la trasposición se hace con el alfabeto invertido) o el método atribuido a Julio César y
conocido como "cifrado del César" (la trasposición se hace con el alfabeto movido tres posiciones, la clave sería 3)51.
Los algoritmos informáticos se basan principalmente en la trasposición de bloques52 de bits en base a claves binarias.
50 Un acróstico es una composición poética en el que las letras iniciales, medias o finales de cada verso, leídas en sentido vertical, forman un
vocablo o una locución. El acróstico más conocido de la lengua española está constituido por los versos que conforman el Prólogo de La
Celestina (Fernando de Rojas, 1497), en cuyas octavas se puede leer: "El bachiller Fernando de Rojas acabó la comedia de Calisto y Melibea y
fue nacido en la Puebla de Montalván".
51 Otro sistema de claves, por ejemplo "JULIOCESAR" (sin letras repetidas) nos daría el alfabeto de sustitución
JULIOCESARBDFGHKMNÑPQTUVWXYZ
52 CBC (Cipher-Block Chaining) es el modo más utilizado de cifrado por bloques en contraposición al más simple y antiguo ECB (Electronic
CodeBook). Su principal inconveniente es que el cifrado y descifrado es secuencial y no puede paralelizarse, mientras que en ECB el mensaje se
divide en bloques que se cifran separadamente.
Criptografía asimétrica
La criptografía de clave pública se basa en la creación de "rompecabezas matemáticos" que son difíciles de resolver sin
uno de los datos, pero fáciles de resolver con ese dato. El creador de las claves publica el rompecabezas (clave pública)
y guarda el dato clave (clave privada). Ese rompecabezas matemático (clave pública) puede utilizarse para cifrar un
número (mensaje) de manera que solo con el dato clave (clave privada) se pueda calcular el número original.
Por ejemplo es fácil multiplicar dos números primos pero es difícil factorizar el resultado. Lo mismo ocurre con el
módulo de grandes números primos (DSA), los logaritmos discretos (ElGamal) o las matemáticas de las curvas
elípticas. Por ejemplo si se usa la función "ga mod p=s", es fácil calcular "s" a partir del resto de valores (g,a,p), pero
es muy costoso computacionalmente calcular "a" a partir del resto de valores (g,p,s).
Se dice que un algoritmo de clave pública es reversible si se puede utilizar tanto la clave privada como la pública para
cifrar y siempre es necesaria la clave contraria para descifrar.
La Criptografía de Curva Elíptica (ECC: Elliptic Curve Cryptography) es una variante de la criptografía asimétrica
basada en las matemáticas de las curvas elípticas. Sus autores argumentan que la CCE puede ser más rápida y usar
claves más cortas que los métodos anteriores al tiempo que proporcionan un nivel de seguridad equivalente.
Firma de mensajes
Los algoritmos de firma aportan autenticación, integridad y no-repudio a la comunicación.
El sistema básico para firmar un fichero, un mensaje o un resumen es mediante su cifrado con una clave, de forma que
solo podrá entenderse descifrándolo de nuevo. El hecho de que pueda descifrarse con la clave establecida garantiza su
integridad (si se hubiese alterado una vez cifrado no se podría descifrar) y su autenticidad (ha sido cifrado con la clave -
firma- correcta).
Para firmar un mensaje o un fichero se genera un resumen y se cifra únicamente el resumen, por varios motivos:
– Eficiencia: es más eficiente firmar un resumen de tamaño fijo y "pequeño" que largos ficheros de incluso varios
GiB.
– Integridad: al firmar un resumen, éste no debe fraccionarse previamente
– Compatibilidad: los resúmenes siempre tienen el mismo tamaño y formato (para cada algoritmo de resumen) y es
más fácil implementar algoritmos de firma sobre ellos
– Múltiples firmas: al mantener el mensaje original sin cifrar y firmar (cifrar un resumen) un mismo archivo puede
ser firmado por diferentes entidades
– Firmado de datos públicos: El fichero original puede ser público (no necesita cifrarse) y basta con cifrar un
resumen del mismo para garantizar su integridad y origen.
A cambio se introduce un nuevo punto de fallo (el algoritmo de resumen, que puede ser sensible a colisiones).
Además los protocolos de firma agregan mecanismos de estampado de tiempo, lo que aporta no-repudio a la
comunicación, es decir el emisor no puede negar que es quién ha creado el mensaje si la clave no había sido
comprometida con anterioridad.
Por tanto los protocolos de firma se componen de un algoritmo de cifrado de clave pública, un algoritmo de resumen y
mecanismos de estampado de tiempo. En vez de algoritmos de clave asimétrica se pueden utilizar un algoritmo de clave
simétrica con clave pre-compartida para realizar el cifrado.
Cuando se firman mensajes de comunicación dentro de un protocolo seguro, las firmas generadas se conocen como
"código de autenticación de mensaje"(MAC o kHMAC keyed-Hash Message Authentication Code).
Comunicación segura
Cuando dos partes desean comunicarse de manera segura han de enviar sus mensajes cifrados, lo que permite garantizar
la confidencialidad de la comunicación, es decir que solo quienes dispongan de la clave podrán entender el mensaje.
Además han de utilizarse técnicas de firmado para garantizar la integridad y autenticidad del mensaje.
Estas tres garantías (Autenticidad, Confidencialidad e Integridad) definen una comunicación segura.
Por tanto para establecer una comunicación segura las dos partes establecen una negociación en la que acuerdan el uso
de un algoritmo de cifrado simétrico -son los más rápidos-, una clave para el algoritmo -que puede ir variando con el
tiempo- y un sistema de firmado (mediante claves asimétricas o clave simétrica pre-compartida que también tendrán
que acordar). Una vez realizada la negociación y establecidos los parámetros de una comunicación segura se dice que se
ha establecido una asociación de seguridad (SA: Security Association).
Si ambas partes de la comunicación utilizan algoritmos asimétricos reversibles y disponen de la clave pública de la otra
parte pueden realizar la negociación de manera segura usando un medio inseguro. Para ello el remitente debe firmar sus
mensajes con su clave privada y utilizar la clave pública del destinatario para cifrar los mensajes que le envía.
Esto permite que:

– solo el destinatario puede leer el mensaje -descifrándolo con su clave privada- (confidencialidad)
– el mensaje no puede ser alterado y seguir siendo dado por bueno -fallaría el descifrado- (integridad)
– el destinatario puede verificar la firma del mensaje -mediante la clave pública del remitente- (autenticidad)
PKI (Public Key Infraestructure) y Redes de confianza (Web of Trust)

Si las partes no tienen conocimiento previo del otro no pueden simplemente solicitar a la otra parte su clave pública, ya
que ésta podría ser alterada o intercambiada (ver más adelante el problema del hombre-en-medio). Para obtener las
claves públicas de manera segura pueden utilizar una infraestructura de clave pública (PKI: Public Key Infrastructure).
Estas infraestructuras se basan en la existencia de entidades certificadoras de claves públicas. Estas entidades emiten
certificados que contienen el periodo de validez del certificado, datos del solicitante (datos de identificación y su clave
pública) y están firmados por la entidad certificadora mediante la clave privada de la entidad. El principal formato de
certificados utilizado es X.509, un estándar de ITU-T.
Para que una parte otorgue validez a un certificado de nuevo necesita conocer la clave pública de la entidad
certificadora persistiendo el problema original. Por ello en última instancia las entidades certificadoras distribuyen su
clave pública lo máximo posible mediante medios fiables, incluso en la propia instalación de los sistemas operativos y
aplicaciones, por medio de certificados autofirmados. Además las entidades certificadoras deben certificarse unas a
otras y crear listados de revocación de claves (para anular la validez de claves certificadas en su periodo de validez por
haber quedado comprometidas).
Si no se dispone de PKI las partes deben acordar una clave para el algoritmo de cifrado simétrico sin llegar a
comunicársela y sin que un tercero a la escucha pueda deducirla ya que entonces tendría capacidad para entender toda la
comunicación. Este problema se conoce como "intercambio de claves" aunque, como se ha dicho, en realidad lo que se
hace no es intercambiar una clave sino acordar una clave entre las partes.
Alternativamente las redes de confianza se basan en que cada usuario firme las claves públicas de usuarios de su entera
confianza, que a su vez firman las claves públicas de otros exponencialmente, creando una red de claves públicas de
confianza. Para obtener redes amplias y de calidad los usuarios deben conseguir que muchos terceros firmen su clave
pública y, esto es muy importante, firmar solo la clave pública de terceros de confianza.
Intercambio Diffie-Hellman
El principal esquema teórico para acordar claves se conoce como intercambio Diffie-Hellman53 (DH). Este esquema se
basa, igual que la criptografía de clave pública en funciones cuya reversible es difícil de calcular.
Su funcionamiento se puede ver en el siguiente ejemplo con la función "ga mod p=s":
Un extremo "Ana" quiere acordar una clave con "Bob" por un canal en el que escucha "Eva".
Ana informa a Bob (y a Eva) de que va a utilizar "g=5" y "p=23". En la práctica "g" suele ser 2 o 5, pero "p" debe ser
un número primo de al menos 300 dígitos.
Entonces Ana elige un número aleatorio "a=6" (en la práctica "a" debe ser un número de al menos 100 dígitos),
calcula "56 mod 23=8" y envía a Bob (y a Eva) el resultado (8).
Bob elige un número aleatorio "b=15" (que como el número aleatorio "a" de Ana debe ser en la práctica de al menos
100 dígitos), calcula "515 mod 23=19" y envía a Ana (y a Eva) el resultado (19).
Con estos datos Ana calcula que la clave acordada con Bob es "196 mod 23=2". Bob calcula que la clave acordada
con Ana es "815 mod 23=2". Nótese que solo Ana conoce "a" y solo Bob conoce "b" pero ambos calculan el
mismo valor para la clave "s=2".
Eva para conocer la clave acordada "s" sin conocer ni "a" ni "b" debería resolver el sistema de ecuaciones
● 5a mod 23=8
● 5b mod 23=19
● 19a mod 23=8b mod 23=s
lo cual, con las restricciones dadas para los valores de "p", "a" y "b", actualmente es irresoluble computacionalmente.
El problema del hombre en medio

El esquema DH solo se ocupa de acordar una clave, pero no de autenticar a los extremos, por lo que es atacable
mediante un esquema de hombre-en-medio (man-in-the-middle). Para realizar este ataque, el atacante debe conseguir
interceptar la comunicación haciendo de intermediario, es decir debe conseguir que los mensajes que las partes envían
lleguen al intermediario y no al destinatario original y después reenviarles los mensaje, sustituyendo la comunicación
directa por una indirecta. Para que las partes no noten la interferencia el intruso finge ser en cada momento el remitente
original.
Siguiendo el ejemplo anterior:

Si Eva en vez de solo escuchar quisiera hacer un ataque tipo hombre-en-medio, lo que haría es establecer una
comunicación con Ana fingiendo ser Bob y establecer otra comunicación con Bob fingiendo ser Ana. Usando el
esquema Diffie-Hellman acordaría una clave con Ana y otra con Bob. Después desencriptaría los mensajes enviados
por Ana con la clave acordada con ella y los volvería a encriptar con la clave acordada por Bob para enviárselos a él.
De la misma manera desencriptaría los mensajes enviados por Bob con la clave acordada con él y los volvería a
encriptar con la clave acordada por Ana para enviárselos a ella.
En medio de una comunicación con claves asimétricas:

Si Eva quiere hacer un ataque tipo hombre-en-medio en una comunicación con claves asimétricas entre Ana y Bob,
lo que haría es enviar a Ana su clave pública -una generada al efecto- como si fuese la de Bob y enviar a Bob otra
clave pública -generada al efecto- como si fuese la de Ana. De nuevo establecería una comunicación segura con Ana
y otra con Bob, reenviando los mensajes interceptados tras descifrarlos y volverlos a cifrar y firmar.
Como hemos visto, este ataque no es posible si previamente Ana y Bob conocen las claves públicas de la otra parte o
si Ana y Bob verifican las claves públicas que reciben mediante certificados de una entidad que previamente hayan
reconocido.
Este ataque de hombre-en-medio permite no solo conocer la información intercambiada sino también alterarla enviando
al destinatario mensajes o ficheros totalmente diferentes de los enviados por el remitente original.
El uso de PKI con claves públicas certificadas por las partes hace innecesario el esquema DH. Pero ¿qué ocurre cuando
un cliente sin certificado quiere comunicarse de manera segura con un servidor con certificado? Es decir ¿y si solo una
de las partes usa PKI para certificar su autenticidad?
53 El esquema fue publicado por Whitfield Diffie y Martin Hellman en 1976.
En estos casos se utiliza el intercambio DH y el servidor firma todos sus mensajes. Esto hace que el hombre-en-medio
pueda alterar los mensajes solo en una dirección (cliente sin certificar → servidor). Haciéndolo podría engañar al
servidor pero no al cliente, con lo que la comunicación cliente-servidor no se establecería. Si no se altera ningún
mensaje, como hemos visto, cliente y servidor podrán acordar una clave sin que ningún tercero sea capaz de
averiguarla.
9.2. Algoritmos
Como hemos comentado existen tres tipos básicos de algoritmos:
● Cifrado simétrico. Permiten cifrar y descifrar mensajes mediante una misma clave.
● Cifrado asimétrico -algoritmos de clave pública y privada-. Estos algoritmos utilizan dos claves diferentes
para cifrar y descifrar mensajes. Una de las claves se publica y la otra se mantiene privada.
● Resumen -"Digest", "Hash", "Cheksum"-. No son algoritmos de cifrado sino que generan un resumen que
permite verificar la integridad del fichero o mensaje pero no permite obtener el original.
Cifrado simétrico (DES, 3DES, AES, RCx e IDEA)

Los algoritmos informáticos de cifrado simétrico se basan principalmente en la trasposición de bloques (block cipher)
de bits en base a claves binarias.
DES y 3DES
El algoritmo DES (Data Encryption Standard) creado en 1976 requiere una clave de 64 bits, de los cuales utiliza
únicamente 56 bits siendo los otros 8 un control de paridad.
Para mejorar la seguridad se creo Triple DES (TDES o 3DES), que consiste en utilizar tres veces DES, cifrando y/o
descifrando con una, dos o tres claves diferentes. Así DES-EEE1 cifra tres veces con la misma clave, mientras que
DES-EDE3 cifra-descifra-cifra con tres claves diferentes (al usar para "descifrar" una clave diferente que para cifrar, en
realidad se complica el cifrado). Las variantes más seguras son DES-EEE3 y DES-EDE354.
Si se utilizan 3 claves diferentes la longitud de la clave usada es de 168 bits (56x3) pero la seguridad efectiva55 es de
112 bits.
3DES es un algoritmo seguro pero lento, que permitió seguir utilizando dispositivos creados para DES. Sin embargo
está siendo sustituido por AES (Advanced Encryption Standard).
AES
AES (Advanced Encryption Standard) es uno de los algoritmos más utilizados, ya que se convirtió en estándar en 2002.
Utiliza un tamaño de bloque de 128 bits y claves de 128, 192 o 256 bits. AES es rápido tanto por software como por
hardware, es relativamente sencillo de implementar y requiere poca memoria en el proceso.
RCx
RC4 (Rivest Cipher o Ron's Code) era el algoritmo de cifrado por software más utilizado en parte por ser el algoritmo
utilizado por SSL y WEP. Este algoritmo utiliza un sistema de cifrado de flujo (stream cipher) no de trasposición de
bloques. Esto hace que sea rápido y sencillo. Sin embargo este algoritmo es fácilmente atacable si la clave de flujo
(keystream) no se descarta, o no es aleatoria o cambia en relación a la clave anterior o se usa varias veces la misma.
Utiliza una clave de entre 40 y 256 bits y no se recomienda su uso ya que no aporta seguridad suficiente.
RC4 ha sido sustituido por RC5 y RC6 que utilizan trasposición de bloques. RC6 utiliza un tamaño de bloque de 128
bits y claves de 128, 192 o 256 bits (como AES), aunque puede parametrizarse con otros valores.
ARCFour (Alleged RC4) es un algoritmo libre al parecer compatible con RC4 (algoritmo patentado y cerrado).
IDEA
IDEA (International Data Encryption Algorithm) es un algoritmo de trasposición de bloques de 64 bits con clave de
128 bits. Se usa en PGPv2 (Pretty Good Privacy) y es opcional en OpenPGP dado que está sujeto a licencia en algunos
paises.
54 Se puede observar que DES-EDE1 equivale a DES.

55 Se dice que un algoritmo tiene una seguridad efectiva de N bits si un ataque por fuerza bruta necesitaría del orden de 2n intentos para tener éxito.
Cifrado asimétrico (RSA, ElGamal, DSA y ECDSA)

El esquema propuesto por Diffie-Hellman en 1976 era un modelo teórico. La primera realización robusta del modelo
Diffie-Hellman apareció en 1978 (RSA78: Rivest-Shamir-Adleman 1978).
El algoritmo de cifrado RSA es reversible, es decir, además de permitir cifrar con la clave pública y descifrar con la
privada, permite cifrar con la clave privada y descifrar con la pública. Así se puede utilizar tanto para obtener
confidencialidad (cifrando con la clave pública del destinatario) como para firmar (cifrando con la clave privada del
emisor).
La primera versión de RSA (RSA base) no es suficientemente segura. En cambio "RSA Security" publica los PKCS
(Public Key Cryptography Standards)56 que definen los detalles de las implementaciones de RSA, y esquemas
criptográficos de seguridad, incluyendo certificados, etc.
Se basa en la función "me mod n=s" con amplias restricciones para cada parámetro utilizado.
La clave pública se compone de "n" (n=pq) y "e" (e=mínimo común múltiplo(p-1,q-1)). La clave privada
es un número "d" que cumple "de≡1 (mod φ(n))"57 ("p" y "q" son números primos grandes).
Dado un número cualquiera "m" (el mensaje a cifrar) se obtiene el número "c" (mensaje cifrado) "c≡me (mod n)". A
partir de "c" (mensaje cifrado), "d" (clave privada) y "n" (parte de la clave pública) se puede obtener "m" (el mensaje
original sin cifrar) mediante "m≡cd (mod n)".
El cifrado ElGamal (1984) es otra implementación, pero se basa en logaritmos discretos. Se utiliza en GPG y PGP.
DSA (Digital Signature Algorithm) es un algoritmo de clave asimétrica no reversible adoptado en 1993 para el estándar
DSS (Digital Signature Standard)58. Como su nombre indica, sirve para firmar, no para cifrar información -dado que no
es reversible-. Se basa en la dificultad de calcular logaritmos discretos en campos finitos -métodos de Schnorr y
ElGamal-.
DSA primero selecciona un algoritmo de resumen (generalmente uno de la familia SHA) y una longitud de clave
(inicialmente un múltiplo de 64 entre 512 y 1024, pero actualmente 1024, 2048 o 3072).
Utiliza la función "g = h(p–1)/q mod p" y "y = gx mod p" con varias restricciones sobre los parámetros, siendo
(p,q,g,y) la clave pública y (x) la clave privada.
ECDSA (Elliptic Curve DSA) es una variante de DSA que utiliza CCE. En teoría es mucho más seguro que DSA y
genera firmas del mismo tamaño.
Resumen (CRC-32, MD5 y SHA)

No son realmente algoritmos de cifrado sino que generan un resumen ("Digest", "Hash" o "Checksum") que permite
verificar la integridad del fichero o mensaje pero no permite obtener el original59. Los principales son: MD5 (Message-
Digest 5) y SHA (Secure Hash Algorithm). Tanto SHA-1 como MD5 descienden de MD4.
A este resumen a veces se le llama "firma de fichero" lo que puede llevar a confusión con los algoritmos de firma
electrónica, que incluyen cifrado y estampado de tiempo.
MD5 (Message-Digest algorithm 5) es una función de resumen ampliamente difundida que genera resúmenes de 128
bits, expresada habitualmente como un número hexadecimal de 32 digitos. Actualmente se pueden generar colisiones
arbitrariamente60 por lo que está empezando a ser sustituido.
Los algoritmos SHA (Secure Hash Algorithm) son un conjunto de funciones (SHA-0, SHA-1 y SHA-2). SHA-1 es la
versión más empleada y se utiliza entre otros en SSL y TLS, PGP, SSH, S/MIME e IPSec. SHA-1 genera resúmenes de
160 bits y se han encontrado debilidades teóricas.
Por su parte SHA-2 utiliza un algoritmo muy similar a SHA-1 pero genera resúmenes de tamaño variable conociendose
las variantes como SHA-224, SHA-256, SHA-384 y SHA-512. Debido a las debilidades teóricas expuestas en SHA-1, y
por tanto SHA-1, está en desarrollo SHA-3.
56 PKCS#1 (v 2.1) define el esquema RSA; PKCS#3 (v. 1.4) define el intercambio DH. Hasta PKCS#15 (algunos obsoletos) que definen varios
esquemas más de seguridad criptográfica.
57 Relación de congruencia entre "de" y "1" con módulo "φ(n)". Es decir "de mod φ(n) = 1 mod φ(n)".
58 Aunque ha sufrido también algunas modificaciones desde entonces.
59 P.e. la letra del NIF se calcula a partir del DNI.
60 Crear un archivo que genere el mismo resumen y por tanto permita sustituir al archivo original.
9.3. Técnicas criptográficas y de seguridad

Los diferentes algoritmos de cifrado se utilizan en diferentes técnicas criptográficas y de seguridad, principalmente:
● Acuerdo de claves. Permite a dos partes que no tienen un conocimiento previo el uno del otro, acordar una
clave secreta -y establecer una comunicación cifrada- usando un canal inseguro.
● Autenticación de las partes. Permiten verificar que los extremos de una comunicación son quienes dicen ser.
● Firma electrónica. Permiten firmar un fichero, un mensaje o un resumen mediante su cifrado con una clave,
de forma que se garantice la procedencia mediante un correcto descifrado.
Acuerdo de claves (PSK, DH, ECDH, RSA, SRP)

Estos esquemas se utilizan cuando no existe una clave pre-compartida (PSK: Pre-Shared Key). Los principales son los
ya comentados DH (Diffie-Hellman), ECDH (Elliptic Curve DH) y RSA (Rivest-Shamir-Adleman), además del
protocolo SRP (Secure Remote Password).
El protocolo SRP (Secure Remote Password) es un protocolo de acuerdo de clave basado en la autenticación por clave
de una de las partes (cliente). Este protocolo acuerda una clave privada de manera similar a DH y después verifica que
las dos partes tienen la misma clave y ambas conocen la clave del usuario (cliente).
Autenticación de las partes (PSK, RSA, DSA y ECDSA)

Para autenticar a las partes de la comunicación se utilizan bien PSK o bien algoritmos de clave pública apoyados en una
PKI o una red de confianza (web of trust).
Firma electrónica (DSA, ECDSA, HMAC-MD5 y HMAC-SHA)

Los protocolos de firma se componen generalmente de un algoritmo de cifrado asimétrico (RSA, DSA y ECDSA) o
cifrado simétrico con clave pre-compartida (PSK), un algoritmo de resumen (MD5 y SHA) y mecanismos de estampado
de tiempo para incorporar no-repudio.
9.4. Autenticación de usuario

Una vez establecida una comunicación segura puede ser necesaria la identificación de una de las partes como cliente en
la otra parte como servidor. Para ello se pueden utilizar diferentes algoritmos, protocolos y sistemas.
PAP, CHAP, Ms-CHAP

PAP (Password Authentication Protocol) es el mecanismo más sencillo de autenticación de usuario y lo que hace es
enviar un par usuario/contraseña en claro por la red.
La familia de algoritmos CHAP (Challenge-Handshake Authentication Protocol) y en particular las implementaciones

de Microsoft (MS-CHAP y MS-CHAPv2) se basan en mecanismos de "retos" para realizar la autenticación. En vez de
solicitar la clave, que podría ser interceptada, se realiza una comunicación de acuerdo en tres partes ("three-way
handshake") en la que el servidor "reta" al cliente basándose en la clave secreta, el cliente responde al reto y el servidor
confirma o deniega la autenticación. Este proceso se repite regularmente durante la comunicación.
El protocolo original CHAP requiere que ambos extremos cliente y servidor conozcan la clave secreta aunque nunca sea
trasmitida.
La versión MS-CHAP además permite al usuario cambiar la clave, permite autenticación mutua entre pares y no
requiere que ambas partes conozcan la clave en claro, sino un resumen (Hash) de la misma.
PPP (Point-to-Point Protocol) utiliza CHAP para autenticar a los usuarios.
Kerberos
Kerberos es un protocolo de autenticación de partes cliente-servidor que permite autenticar ambas partes sobre un
medio inseguro. Se basa en cifrado simétrico (DES) y un tercero en quien confían ambas partes (KDC Key Distribution
Center). Este tercero provee las funciones de autenticación (AS: Authentication Server) y despacho de etiquetas (TGS:
Ticket Granting Server). Todas las partes deben autenticarse en el AS. Algunas extensiones de Kerberos permiten el uso
de PKI. La versión 5, vigente, permite el uso de AES en vez de DES.
Todos los equipos gestionados por un servidor forman un dominio o territorio Kerberos (realm).
Supongamos que Ana quiere solicitar un servicio de Bob y el KDC es Carlos. Tanto Ana como Bob deben ser
conocidos por Carlos (tener un usuario y contraseña).
Primero Ana solicita a Carlos autenticarse mediante un mensaje en claro. Carlos le envía a Ana dos mensajes. El
primer mensaje se llama TGT ("Ticket-Granting Ticket") y está cifrado con una clave privada de Carlos
(indescifrable para Ana). El TGT incluye el identificador de Ana, el periodo de validez de la sesión y la clave de
sesión Ana-Carlos.
El segundo mensaje que le envía Carlos a Ana es la "etiqueta de sesión Ana-Carlos" que contiene una clave de sesión
Ana-Carlos y está cifrado con la clave de Ana. Al estar cifrado con la clave de Ana solo ella podrá acceder a la clave
de sesión Ana-Carlos. Si Ana es capaz de usar la clave de sesión Ana-Carlos está autenticada.
Una vez autenticada Ana debe solicitar a Carlos el uso del servicio de Bob. Para hacer la solicitud envía a Carlos un
mensaje con el TGT y el identificador del servicio de Bob al que quiere acceder. Además Ana envía un mensaje
"Autenticador" que contiene su identificador y una marca de tiempo, cifrado con la clave de sesión Ana-Carlos.
Carlos utiliza su clave secreta para descifrar el TGT y obtener la clave de sesión Ana-Carlos. Con la clave de sesión
Ana-Carlos descifra el "Autenticador" y lo da por válido (pues solo Ana lo ha podido enviar ya que es la única que
conoce la clave de sesión Ana-Carlos).
Carlos verifica si Ana tiene permiso para acceder al servicio de Bob y en ese caso le envía a Ana dos nuevos
mensajes. Un mensaje contiene una nueva clave de sesión Ana-Bob cifrada con la clave de sesión Ana-Carlos (que
Ana puede descifrar).
Otro mensaje "petición de servicio" contiene los datos de Ana (identificador, periodo de validez) y la clave de sesión
Ana-Bob cifrados con la clave de Bob (indescifrable para Ana).
Ana envía entonces a Bob el mensaje "petición de servicio" tal y como se lo envió Carlos.
Además le envía un nuevo mensaje "Autenticador" con su identificador y una marca de tiempo cifrado con la clave
de sesión Ana-Bob.
Bob descifra con su clave secreta el mensaje "petición de servicio", lo que le garantiza que la petición proviene de un
cliente autenticado (pues lo ha generado Carlos), y obtiene la clave de sesión Ana-Bob.
Con la clave de sesión Ana-Bob descifra el "Autenticador" suma uno a la marca de tiempo y lo devuelve a Ana, de
nuevo cifrado por la clave de sesión Ana-Bob.
Ana descifra el "Autenticador" y verifica que la marca de tiempo es la que había indicado más uno, lo que sirve para
autenticar a Bob.
NTLM
NTLM es un protocolo de autenticación similar a MS-CHAP, basado en retos sobre los datos de usuario. Utiliza
algoritmos MD4/MD5, SHA y DES para los cálculos.
NTLMv2 utiliza HMAC-MD5 y separa el control de sesión en el protocolo NTLM-session (similar a MS-CHAPv2).
Aunque el protocolo Kerberos ha sido adoptado por Microsoft para la autenticación en el directorio activo, todavía
utiliza NTLM en determinadas circunstancias:
● Si el cliente se autentica usando una dirección IP.
● Si el cliente se autentica en un servidor de otro bosque del directorio activo o no pertenece a ningún dominio o
no existe ningún dominio.
● Si un cortafuegos corta los puertos necesarios para usar Kerberos.
Servidores AAA (RADIUS y TACACS)

Una función relacionada con la comunicación segura es la autenticación de los usuarios, diferenciándola de la
autenticación de los extremos en una asociación de seguridad que permite evitar ataques de tipo hombre-en-medio.
Una vez establecida una comunicación entre un cliente y un servidor, éste puede requerir una autenticación de usuario,
para verificar que dicho usuario tiene acceso al servicio. Pero esta autenticación de usuario puede realizarse
independientemente de si la comunicación es segura o no (aunque cada vez más, los servicios restringidos suelen
realizarse a través de comunicaciones seguras).
Las funciones de los servidores de autenticación son en realidad tres, conocidas como triple A o AAA: Authentication,
Authorization, Accounting (Autenticación, Autorización y Registro).
El sistema RADIUS (Remote Authentication Dial-In User Service) permite decidir la concesión de acceso a partir de
una combinación de datos como la identidad del usuario, la pertenencia a un grupo, la hora del día, la fecha, el nivel de
cifrado soportado, el tipo de túnel... Además permite la asignación de parámetros de conexión, como algoritmos de
seguridad obligatorios.
RADIUS es escalable y permite configurarse para solicitar la autenticación a otro servidor (RADIUS o de otro tipo).
El estándar de IETF (RFCs 2138 y 2139) define el puerto UDP 1812 para autenticación, pero se ha utilizado durante
mucho tiempo el 1645.
Mientras que RADIUS combina la autenticación y autorización en el perfil de usuario, TACAS+ separa las dos
operaciones. Además RADIUS utiliza UDP y TACACS+ utiliza TCP.
9.5. Esquemas de seguridad

Las diferentes técnicas criptográficas (algoritmos de cifrado y resumen, intercambio de claves, autenticación de equipos
y usuarios y firma electrónica) vistas hasta ahora se combinan para crear diferentes esquemas de seguridad y protocolos
de comunicación segura.
SSL y TLS
TLS (Transport Layer Security) es un protocolo estándar basado en SSL (Secure Sockets Layer), desarrollado por
Netscape. TLS permite establecer comunicaciones seguras punto-a-punto por encima de la capa de transporte de la red
(generalmente TCP/IP). TLS otorga autenticación (mediante PKI), confidencialidad e integridad. La autenticación
puede ser unilateral (por ejemplo en un entorno web cliente-servidor) o bilateral, ya sea utilizando PKI, TLS-PSK o
SRP.
Durante el inicio de la comunicación los extremos negocian el algoritmo de cifrado simétrico a utilizar, realizan el
intercambio (o acuerdo) de clave y acuerdan los algoritmos de firma a utilizar. Una vez establecida la comunicación se
utiliza el algoritmo de clave simétrica (con la clave acordada) para cifrar la comunicación y el algoritmo de firma para
generar los códigos de autenticación de los mensajes (MAC: Message Authentication Codes o kHMAC).
Los algoritmos más utilizados en TLS son:
– Para intercambio de claves: RSA, Diffie-Hellman, ECDH, SRP, PSK
– Para autenticación de las partes: RSA, DSA, ECDSA
– Para cifrado: Triple DES, AES, IDEA
– Para firma de mensajes: HMAC-MD5 (SSLv2 en desuso) o HMAC-SHA (SSLv3).
IKE
IKE (Internet Key Exchange) o IKEv2 (la versión 1 es obsoleta) permite la creación de conexiones de seguridad que
utiliza DH para el intercambio de claves y PSK, PKI o Kerberos para la autenticación de las partes. Permite negociar el
cifrado simétrico y la firma de mensajes.
IKE funciona sobre UDP y, entre otros, es utilizado por ISAKMP y EAP-IKE.
ISAKMP (Internet Security Association and Key Management Protocol)

Es un esquema utilizado en IPSec para establecer comunicaciones seguras (crear asociaciones de seguridad) y renovar
periódica y automáticamente la clave del cifrado simétrico entre las partes. ISAKMP generalmente utiliza IKE para
crear la asociación de seguridad y negociar el algoritmo de cifrado y firma, aunque puede utilizar otros protocolos.
WEP, WPA (TKIP) y WPA2

El esquema de seguridad inicial de 802.11 se llamó WEP (Wired Equivalent Privacy) y se basaba en el algoritmo de
cifrado de flujo RC4 y una clave pre-compartida (PSK: Pre-Shared Key).
El esquema original (WEP-40) para generar la clave de flujo de RC4 (64 bits) utiliza una clave PSK de 40 bits que se
concatena con una cadena de 24 bits que identifica la red (vector de inicialización).
Tras aliviar las restricciones legales a los algoritmos de cifrado (año 2000) se comenzó a usar una clave de 128 bits
(WEP-104). Sin embargo los problemas de WEP con RC4 tienen mucho que ver con el vector de inicialización y la
obtención de la clave de flujo, por lo que el aumento de la clave no es útil ya que el sistema sigue siendo inseguro.
WPA (Wi-Fi Protected Access) comenzó a utilizarse en 2003. Esta especificación se basaba también en RC4 con PSK
pero utiliza TKIP (Temporal Key Integrity Protocol) para mejorar la seguridad. TKIP realiza un control de integridad de
los paquetes (ya que en los ataques algunos paquetes se alteraban sin llegarlos a descifrar), un conteo de los mismos y
utiliza una función para obtener la clave de RC4 mezclando la clave de usuario con el vector de inicialización de la red
(en vez de realizar una simple concatenación).
El sistema 802.11i final, conocido como WPA2, apareció en 2004. Permite utilizar nuevos mecanismos de distribución
de la clave (comoEAP), autenticación basada en PSK o en servidores (como servidores RADIUS) y CCMP (basado en
AES) para cifrado. CCMP (Counter-mode with Cipher-block-chaining Message-authentication Protocol), es opcional
en WPA y sustituye totalmente a TKIP y WEP (obsoletos) en WPA2. CCMP utiliza AES tanto para la mantener la
confidencialidad como para verificar la integridad.
La configuración habitual recomendada es WPA2 con clave precompartida (AES-PSK) -en entornos domésticos o
PyMES- o WPA2 con servidores RADIUS (EAP-TLS) en entornos corporativos.
EAP, LEAP y PEAP

EAP (Extensible Authentication Protocol) es un esquema de autenticación utilizado en PPP y redes inalámbricas, siendo
el esquema oficial de WPA y WPA2. No es un mecanismo de autenticación sino que define formatos de mensajes y
mecanismos de autenticación para distintos protocolos (conocidos como EAP-MD5, EAP-SIM, EAP-AKA, EAP-TLS,
EAP-IKEv2, EAP-TTLS...). Cada protocolo encapsula mensajes EAP.
El objetivo de EAP es generar una clave inicial llamada PMK (Pair-wise Master Key) a partir de la cual establecer la
comunicación. Para ello básicamente realiza la autenticación de los extremos y el intercambio de claves para el
algoritmo de cifrado acordado.
LEAP (Lightweight Extensible Authentication Protocol) es una versión de EAP creada por Cisco que utiliza MS-CHAP
para autenticación de usuarios y actualmente obsoleta por insegura
EAP-PSK utiliza PSK para la autenticación y el intercambio de clave.
EAP-TLS es un esquema poco utilizado ya que requiere que ambas partes utilicen PKI (certificados) para su
autenticación. Es universalmente soportado y considerado uno de los más seguros.
EAP-TTLS, conocido a veces únicamente como TTLS (Tunneled Transport Layer Security), es una extensión de EAP-
TLS que permite que una de las partes (cliente) se autentique sin necesidad de certificado PKI. El cliente una vez
autenticado el servidor crea con él un túnel cuyo uso sirve de autenticación del cliente.
EAP-IKEv2 se basa en IKEv2 para autenticar las dos partes cliente-servidor e intercambiar claves. El servidor puede
autenticarse mediante PKI o algoritmos de clave simétrica. El cliente puede autenticarse además mediante una clave de
cliente.
PEAP (Protected EAP) es un estándar de la industria similar a EAP-TTLS. Para autenticar las partes se puede utilizar
PEAPv0 o v1. Microsoft solo implementa PEAPv0. Para autenticar a los clientes en el servidor se puede utilizar EAP-
MSCHAPv2, EAP-TLS, EAP-GTC o EAP-SIM.
La versión más extendida y utilizada, que se conoce símplemente como PEAP, es PEAPv0/EAP-MSCHAPv2.
PGP / OpenPGP / GPG

PGP (Pretty Good Privacy), desarrollado originalmente por Philip Zimmermann en 1991, derivó en el estándar
OpenPGP (1997). GPG o GnuPG (GNU Privacy Guard) es una implementación de OpenPGP.
OpenPGP es probablemente el sistema de cifrado personal más utilizado. Nació con el objetivo de cifrar correo-e, a lo
que se añadió la firma de mensajes y el cifrado de archivos en disco.
GPG es una utilidad de línea de comandos, pero existen numerosos "front-end" gráficos y es la herramienta utilizada
por múltiples programas para gestionar su cifrado, especialmente clientes de correo y navegadores.
GPG utiliza algoritmos de cifrados libres de patentes como 3DES, AES o Blowfish y ElGamal, mientras que PGP
utiliza además algoritmos como IDEA o RSA que tiene restricciones de patentes en algunos países61.
SSH
SSH es un protocolo cliente-servidor que permite la conexión segura con máquinas remotas para abrir sesiones y
ejecutar comandos, crear túneles o reenviar puertos TCP y conexiones X11. Además puede trasferir ficheros mediante
los protocolos asociados SFTP y SCP. El servidor generalmente escucha en el puerto TCP 22.
SSH-1 es un protocolo monolítico, mientras que SSH-2 es un protocolo de 4 capas: Una de transporte (que incluye el
intercambio de claves, cifrado, compresión e integridad), Una de autenticación de usuario (mediante contraseña, clave
pública, Kerberos y otros), Una de conexión (que permite múltiples canales en una sola conexión) y una llamada
"SSHFP DNS" que se encarga de las firmas de los servidores ("host key fingerprints").
SSH-2 inicialmente utilizaba solo DSA como algoritmo de autenticación de equipos (y opcionalmente usuarios) y el
intercambio DH para acordar la clave del algoritmo simétrico. Dado que actualmente RSA ha pasado a dominio público
también puede utilizarse en OpenSSH para la autenticación de equipos y usuarios y el intercambio de claves.
SSH utiliza el cifrado asimétrico para la autenticación del servidor y el intercambio de claves (RSA o DSA + DH); el
cifrado simétrico para la confidencialidad y los resúmenes para la integridad (mediante MACs: Message Authentication
Codes). Además permite comprimir los paquetes para mejorar el rendimiento de la conexión.
SSH-1 SSH-2
Cifrado asimétrico RSA RSA, DSA, DH
Cifrado simétrico 3DES, Blowfish, IDEA 3DES, AES, Blowfish, CAST-128, Twofish, IDEA
Resumen MD5, CRC-32 MD5, SHA-1
Compresión zlib zlib
SSH nació como software libre pero cambió a privado como SSH-2 tras la versión 1.2.12. OpenSSH se desarrolló a
partir de la última versión libre disponible. Más tarde SSH-2 se propuso como estándar de Internet. OpenSSH incluye:
● sshd, servidor
● ssh, cliente que reemplaza a rlogin y telnet para conectar con máquinas remotas
● scp y sftp, clientes que reemplazan respectivamente a rcp y ftp para copiar ficheros entre máquinas
● ssh-keygen, herramienta para generar y verificar las claves RSA y DSA utilizadas para la autenticación de
equipos y usuarios.
● ssh-agent y ssh-add, utilidades para facilitar el uso y administración de claves públicas y privadas.
● ssh-keyscan, herramienta para analizar las claves de un servidor
61 GPG permite utilizar IDEA, mediante un "plug-in" sujeto a restricciones de licencia según países.
9.6. Herramientas de seguridad de redes

Las herramientas de seguridad de redes pueden utilizarse para revisar la seguridad de un sistema con buenas o con
malas intenciones. Si no revisas la seguridad de tu sistema, alguien lo hará por ti.
Analizadores de red
Estas herramientas buscan equipos en la red, hacen barridos de puertos y descubrimiento de servicios, analizando los
resultados para inferir información, como versión y tipo de sistema y/o servicios, y exponer deficiencias de seguridad.
Algunos de los más utilizados son nmap, SATAN y SAINT.
Analizadores de seguridad
Otro tipo de herramientas se utiliza para analizar un equipo y localizar todo tipo de posibles problemas de seguridad.
Permite detectar y exponer aplicaciones conocidas por su fragilidad, configuraciones particulares inseguras, uso de
claves predefinidas y múltiples bugs y sus exploits.
Nessus es una aplicación gratuita para uso no comercial (en origen era libre). Sus desarrolladores producen decenas de
nuevos análisis de vulnerabilidades a la semana. Estos análisis -llamados "plug-ins"- se publican para su uso gratuito
una semana después de su puesta a disposición de los clientes de pago.
OpenVAS -inicialmente gnessus- es un analizador libre que nació como una ramificación del último Nessus libre. Los
análisis de vulnerabilidades son llamados NVTs (Network Vulnerability Tests).
Analizadores de paquetes
Los analizadores de paquetes captan todos los paquetes que llegan a la tarjeta de red (NIC) configurándola en modo
promiscuo. Después facilitan el análisis de dichos paquetes de red según los protocolos utilizados en los paquetes.
El más utilizado es WireShark, inicialmente llamado Ethereal, que dispone de interfaz gráfica. Otro analizador bastante
utilizado es tcpdump, disponible solo en modo comando, aunque existen frontispicios gráficos como WinDump.
Descubrimiento de claves
Los programas de descubrimiento de claves analizan listados de claves cifradas o resumidas (mediante algoritmos como
MD4) para intentar descubrirlas.
La herramienta más utilizada es "John The Ripper", que es libre. JTR autodetecta el tipo de resumen de la clave y puede
atacar claves de multitud de algoritmos como DES, MD5, Blowfish, Kerberos o LM Hash (Windows) tanto en ficheros
de texto como en repositorios sobre LDAP o MySQL. Puede trabajar con ataques de diccionario y alteraciones o
mediante fuerza bruta usando tablas de caracteres frecuentes para marcar el orden.
Redes de comunicaciones 10. TRANSMISIÓN MULTIMEDIA EN REDES IP
10. TRANSMISIÓN MULTIMEDIA EN REDES IP

10.1. Introducción
El sistema tradicional de vídeo-conferencia es un conjunto de normas y protocolos definido como H.320, que se basa en
la utilización de redes RDSI. Para poder realizar transmisiones multimedia en LANs basadas en IP se desarrolló el
estándar H.323, basándose en tres ideas fundamentales:
– Utilizar los estándares existentes.
– Incorporar las ventajas de las redes de conmutación de paquetes para el transporte de voz y vídeo.
– Conseguir la transmisión de información multimedia en tiempo real a través de redes compartidas.
Los equipos tradicionales de vídeo-conferencia sobre RDSI (H.320) están formados por un ordenador con un códec
hardware (H.26x) y una conexión RDSI, al que se le acopla un monitor de televisión y una serie de dispositivos de
entrada/salida de altas prestaciones, tales como cámaras activadas por la voz, cámaras de documentos, micrófonos
direccionales, micrófonos de ambiente, un sistema de altavoces de alta calidad, etc. Además incorporan sofisticados
sistemas de supresión de eco para mejorar la calidad del sonido. Sin embargo su capacidad de multi-conferencia está
limitada a un máximo de 5 usuarios por conexión RDSI, ya que con un flujo entrante y cuatro salientes se ocuparía toda
la capacidad del acceso RDSI primario.
En el caso de H.323 la situación es similar salvo que se utiliza redes IP (principalmente Internet) en vez de RDSI. En
muchos casos los terminales H.323 ofrecen una calidad inferior comparados con los H.320 debido al tipo de
componentes utilizados: cámaras digitales de baja calidad, micrófonos baratos, carecen de supresión de eco, etc.
Si bien la familia de protocolos H.323 se diseñó para videoconferencia, los terminales H.323 implementan
obligatoriamente únicamente un canal de audio y el resto de canales son opcionales. Por ello es posible utilizar H.323
para telefonía IP que utiliza únicamente Voz sobre IP (VoIP: Voice over IP) para realizar llamadas telefónicas
tradicionales utilizando como terminales tanto equipos informáticos como teléfonos de la RTC.
Algunas ventajas de la telefonía IP son:
● Las llamadas de VoIP entre equipos de red IP no tienen coste adicional. El coste de una llamada de VoIP a la
RTC se calcula en base a la ubicación de la pasarela utilizada (llamada local, nacional...) sin coste extra.
● Las llamadas pueden ser dirigidas a un terminal IP independientemente de su ubicación física real.
● Los terminales de VoIP pueden integrarse con otros servicios multimedia y de intercambio de datos.
● Dispone de múltiples servicios digitales: contestador automático, desvío de llamadas inteligente, bloqueo de
llamadas salientes, filtrado de llamadas entrantes, multi-conferencia, marcación abreviada, extensiones
virtuales, facturación de llamadas en tiempo real, identificador de llamada entrante, llamada en espera,
transferencia de llamada en curso...
Sin embargo H.323 resulta excesivamente complejo en algunos aspectos para utilizarlo solo como VoIP. Esto motivó
que la IETF desarrollara un protocolo alternativo denominado SIP (Session Initiation Protocol), con la intención de ser
un estándar más sencillo y orientado a telefonía IP.
Más específicamente SIP está orientado a la iniciación, modificación y finalización de sesiones interactivas de usuario
donde intervienen elementos multimedia. Así se utiliza para videoconferencias, mensajería instantánea, juegos en red...
En resumen actualmente H.323 y SIP realizan básicamente las mismas funciones, si bien son protocolos incompatibles.
Para permitir la interconexión de redes existen pasarelas entre H.323 y SIP.
Aunque los protocolos multimedia más antiguos y utilizados son H.323 y SIP, existen otro muchos62. De la elección de
uno u otro dependerá la eficacia y la complejidad de la comunicación.
62 Por orden de antigüedad (de más antiguo a más nuevo): H.323 (ITU-T), SIP (IETF), Megaco, Skinny CCP (Cisco), MiNet (Mitel), CorNet-IP
(Siemens), IAX (Asterisk -obsoleto-), Skype (Skype), IAX2 (Asterisk), Jingle (abierto, Jabber), Telme (Woip2) y MGCP (Cisco).
10.2. El protocolo H.323

Introducción
El estándar H.323 es un conjunto de normas y protocolos recomendado por el ITU-T (International Telecommunication
Union) diseñado para permitir transmisiones multimedia en LANs basadas en IP. Fue rápidamente adoptado por
fabricantes de equipos para transmitir voz y videoconferencia sobre IP ya que define un modelo básico de llamada con
servicios suplementarios (convergencia de voz, vídeo y datos en una sola red) y surgió en el momento adecuado.
Forma parte de la serie de protocolos H.32x, los cuales también dirigen las comunicaciones sobre RDSI (H.320), RTC o
SS7. Esta familia de protocolos ha ido evolucionando con el tiempo para permitir mejorar las transmisiones de voz y
vídeo en LANs y WANs sobre distintos medios. La versión actual data de 2006 y se conoce como H.323v6.
Sus principales características son:

– No garantiza una calidad de servicio (QoS)
– Es independiente de la topología de la red
– Admite pasarelas
– Permite usar más de un canal (voz, vídeo, datos) al mismo tiempo.
– El estándar permite que las empresas añadan funcionalidades, siempre que implementen las funciones de
interoperabilidad necesarias.
Los componentes principales del sistema H.323 son:

● Terminales: Equipamiento que utilizan directamente los usuarios. Se pueden implementar tanto por software
(mediante un ordenador) como por hardware (dispositivo físico).
● Guardianes (GateKeepers): Son el centro de toda organización VoIP y son el equivalente a las centralitas
privadas o PBX (Private Branch eXchange). Normalmente se implementan por software.
● Pasarelas (Gateways): Hacen de enlace con la red telefónica conmutada, actuando de forma transparente para
el usuario.
● Unidades de Control Multipunto (MCUs): se encargan de gestionar las multi-conferencias.
Los principales protocolos utilizados son:

● RAS (Registro, Admisión, Situación): Se utiliza sólo en zonas que tengan un guardián para la gestión de la
zona de control del mismo.
● H.225: Mensajes de establecimiento y finalización de llamada entre terminales o con el guardián.
● H.245: Mensajes de control extremo a extremo. Negociación de las capacidades de ancho de banda (mensajes
TerminalCapabilitySet), de la apertura y cierre de los canales lógicos (mensajes OpenLogicalChannel,
CloseLogicalChannel y EndSessionComand), de los códecs y mensajes de control de flujo.
● RTP/RTCP (Real-Time Transport Protocol / Real-Time Transport Control Protocol): Transporte punto a
punto de datos en tiempo real.
Componentes
Terminal
Un terminal es un extremo de la red que proporciona comunicaciones bidireccionales en tiempo real con otro terminal,
con una pasarela (gateway) o con una unidad de control multipunto (MCU). Esta comunicación consta de señales de
control, indicaciones, audio, vídeo y/o datos entre los dos terminales. Conforme a la especificación, un terminal debe
proporcionar audio (voz) y opcionalmente puede proporcionar más canales de audio (por ejemplo para emitir en
varios idiomas), datos o vídeo. Además del códec de audio puede disponer de un códec específico para voz humana.
Generalmente el terminal receptor se encarga de incluir el retardo necesario en las tramas para obtener una buena
sincronización. Por ejemplo retardando las tramas de audio para mantener la sincronización con las tramas de vídeo.
Un terminal H.323 consta de:

● Interfaces de usuario: cámaras, monitores, micrófonos, aplicaciones de datos...
● Códecs de vídeo (opcional) y audio.
● Canal de datos.
● Unidad de control que gestiona de los protocolos RAS, H.245 y H.225.
● Capa H.225 para definición de mensajes.
● Interfaz con la red por paquetes.
Guardián (Gatekeeper)
La función del guardián es gestionar una “zona de control” que consiste en un conjunto de equipos registrados
(terminales, pasarelas y MCUs). Para las comunicaciones entre el guardián y los equipos de su zona se utiliza el
protocolo RAS (Registro, Admisión, Situación).
Las funciones principales del guardián son:
● Gestión de la zona: Lleva a cabo el registro y la admisión de los equipos de su zona.
● Traducción de direcciones E.164: Existen varias formas de asignar direcciones E.164 a terminales H.323,
siendo la más universal la asignación de números de extensión.
● Gestión del ancho de banda: Asignación de ancho de banda a terminales, pasarelas y MCUs, de manera que se
garantice ancho de banda suficiente, o rechazo de la conexión (red saturada).
El guardián puede también ofrecer otros servicios de control:

● Restricciones de uso: Por tipo de conexión (entrante o saliente), por pasarela, por franjas horarias.
● Localización de las pasarelas: Si existen varias pasarelas registradas, encamina las conexiones salientes por la
pasarela más conveniente (generalmente elige en base al coste una pasarela a telefonía móvil o fija en distintas
ciudades o países...).
Un ejemplo de guardián es GNU Gatekeeper (GnuGk).
Pasarela (Gateway)
Una pasarela es un extremo que proporciona comunicaciones bidireccionales en tiempo real entre terminales de la red
IP y otros terminales o pasarelas en una red conmutada. Además de realizar la conversión de protocolo puede realizar
opcionalmente una conversión de formatos de audio y vídeo (transcodificación).
Una organización puede disponer de pasarelas a redes de telefonía móvil y de telefonía fija distribuidas por todo el
mundo de tal manera que una llamada a la red convencional se realice desde la pasarela más conveniente.
Un ejemplo de pasarela (y guardián) es Asterisk (es tanto pasarela como PBX completo tanto para H.323 como SIP).
MCU (Multipoint Control Unit)

Para conectar dos o más terminales -para realizar una llamada o una vídeoconferencia- hace falta una Unidad de Control
Multipunto (MCU).
Una MCU comprende dos unidades lógicas:
● Controlador Multipunto (MC: Multipoint Controller): gestiona las conexiones y se encarga de realizar la
negociación entre los terminales para determinar las capacidades comunes para el proceso de audio y vídeo.
● Procesador Multipunto (MP: Multipoint Processor): mezcla, conmuta y procesa los diferentes canales de
audio, vídeo y/o datos y los enviar a los participantes.
Las MCUs no son la única forma de realizar conferencias multipunto. Una alternativa muy interesante la constituye el
uso de transmisión multicast, por ejemplo mediante el uso de la red MBone de Internet. En este caso en vez de
encargarse un equipo de replicar los flujos de audio-vídeo es la propia red (más concretamente los encaminadores) la
que se ocupa de replicar los paquetes en los puntos donde se producen las bifurcaciones del árbol multicast. Los
estándares H.323 no contemplan la transmisión multicast, por lo que los terminales H.323 no pueden participar en este
tipo de conferencias.
Existe una gran cantidad de usuarios que no tienen acceso a la red MBone, bien porque su proveedor de acceso no
soporta encaminamiento multidifusión o porque la velocidad de su conexión no hace viable o interesante activar
encaminamiento multicast. La solución es instalar en la red multicast una pasarela bidireccional que convierta el flujo
multicast en flujos unicast y viceversa, generando un flujo diferente para cada usuario unicast. Los flujos unicast
pueden ser transcodificados o no.
Desde el punto de vista de eficiencia la pasarela debería estar en el borde de la red multicast y tan cerca como sea
posible de los usuarios unicast, ya que de este modo se aprovecha al máximo la optimización que supone la transmisión
multicast.
Otro elementos
Los proveedores de servicios pueden tener dentro de su red cientos de pasarelas, teléfonos, terminales multimedia... En
esos casos es útil dividir la red en zonas, por ejemplo por ciudades. A un conjunto de zonas controladas por una sola
organización se le llama “dominio administrativo”.
Dentro de un dominio administrativo puede existir elementos llamados de borde o de frontera (Border element) que
centralizan las comunicaciones con elementos de borde de otros dominios administrativos. Estas comunicaciones
pueden incluir autorizaciones de acceso, información de costes de conexión y uso, y otros datos de gestión.
Además, dentro de un dominio pueden existir elementos (Peer elements) que ayuden a propagar a los guardianes la
información útil sobre los elementos de bordes del propio dominio y de otros dominios.
Ejemplo de llamada H.323

(http://www.voipforo.com/H323/H323ejemplo.php)
A continuación se analizará detalladamente una llamada. Cada protocolo se muestra de un color diferente.
Una llamada H.323 se caracteriza por las siguientes fases:
1. ESTABLECIMIENTO
- Uno de los terminales se registra en el guardián utilizando
el protocolo RAS (mensajes ARQ y ACF).
- Mediante el protocolo H.225 se manda un mensaje de
inicio de llamada (SETUP) con los datos (IP y puerto) de
llamante y llamado.
- El terminal llamado contesta con CALL PROCEEDING.
- El segundo terminal tiene que registrarse con el guardián
de manera similar al primer terminal.
- ALERTING indica el inicio de generación de tono.
- CONNECT indica el comienzo de la conexión.
2. SEÑALIZACIÓN DE CONTROL
- Se abre una negociación mediante el protocolo H.245,
para establecer quién será maestro y quién esclavo, las
capacidades de los participantes y los códecs de audio y
vídeo a utilizar. Como punto final de esta negociación se
abre el canal de comunicación (direcciones IP, puerto).
3. AUDIO (+ DATOS y/o VÍDEO)

Los terminales inician la comunicación y el intercambio de
audio (+ datos y/o vídeo) mediante RTP/RTCP.
4. DESCONEXIÓN
- Cualquiera de los participantes activos puede iniciar el
proceso de finalización de llamada mediante mensajes
CloseLogicalChannel y EndSessionComand de H.245.
- Posteriormente utilizando H.225 se cierra la conexión con
el mensaje RELEASE COMPLETE
- Por último se liberan los registros con el guardián
utilizando mensajes del protocolo RAS.
10.3. Protocolo SIP

Introducción
El protocolo SIP se concentra en el establecimiento, modificación y terminación de las sesiones. Se complementa, entre
otros, con el SDP, que describe el contenido multimedia de la sesión, por ejemplo qué direcciones IP, puertos y códecs
se usarán durante la comunicación. También se complementa con RTP (Real-time Transport Protocol), que es el
verdadero portador del contenido de voz y vídeo que intercambian los participantes en una sesión establecida por SIP.
Aunque originalmente SIP tenía como objetivo la simplicidad, en su estado actual se ha vuelto tan complejo como
H.323. El protocolo SIP permite el establecimiento de sesiones multimedia, implementa funciones típicas de telefonía
(llamar a un número, provocar que un teléfono suene al ser llamado, escuchar la señal de tono o de ocupado), permite el
establecimiento de sesiones multipunto, permite que un usuario esté registrado en diferentes ubicaciones (pudiendo
realizar la búsqueda en paralelo o secuencial entre todas ellas).
SIP es similar a HTTP, comparte muchos códigos de estado (como 404: “no encontrado”) y comparte con él algunos de
sus principios de diseño: es legible por humanos y sigue una estructura de petición-respuesta basado en el modelo
cliente-servidor. Las respuestas llevan un código de estado que brindan información acerca de si las peticiones fueron
resueltas con éxito o si se produjo un error. La petición inicial y todas sus respuestas constituyen una transacción.
Aunque dos terminales SIP puedan comunicarse sin intervención de infraestructuras SIP (razón por la que el protocolo
se define como punto-a-punto o entre pares -p2p-), este enfoque es impracticable para un servicio público. En ese caso
requiere de servidores intermediarios (proxy), elementos de registro y servidores de localización (DNS), utilizando un
núcleo de red sencillo (y altamente escalable) con inteligencia distribuida en los extremos de la red, incluida en los
terminales (ya sea mediante hardware o software).
El protocolo SIP diferencia entre dirección física (denominada "dirección de contacto"), que depende de la IP desde la
que se conecte el usuario, y dirección lógica que es invariable para cada usuario. Al igual que en el correo-e, las
direcciones lógicas de SIP tienen la forma usuario@dominio, gestionando cada dominio una compañía o proveedor de
servicios de comunicaciones a través de un servidor (o varios).
Es habitual también, que exista un servidor que reciba las peticiones originadas por los usuarios de un dominio hacia
otros dominios. Este recibe el nombre de Servidor Saliente.
Los principales elementos del sistema SIP son:

● Agentes de Usuario (Terminales)
● Servidores de Registro (Registrar)
● Servidores Intermediarios (Proxys)
● Servidores de Redirección (Redirectors).
Componentes
Agentes de Usuario (Terminales)
Son los puntos extremos del protocolo, es decir son los que emiten y consumen los mensajes del protocolo SIP. Un
videoteléfono, un teléfono, un cliente de software (softphone) y cualquier otro dispositivo similar es para el protocolo
SIP un agente de usuario.
Todos los agentes de usuario se comportan como clientes (UAC: User Agent Clients) y como servidores (UAS: User
Agent Servers).
Algunos terminales por software que soportan charlas de audio y vídeo a través de SIP son Microsoft Windows
Messenger, Apple iChat, AOL Instant Messenger, Ekiga, OpenWengo...
Servidores de Registro (Registrar)

Al iniciarse el agente de usuario SIP envía una petición con el método REGISTER a un Servidor de Registro,
informando a qué dirección física debe asociarse la dirección lógica del usuario (binding). Esta asociación tiene un
período de vigencia y si no es renovada, caduca. También puede terminarse mediante el método DEREGISTER.
El protocolo SIP no determinada la forma en que se debe gestionar los registros.
Servidores Intermediarios (Proxy) y de Redirección (Redirectors)

Para encaminar un mensaje entre un UAC y un UAS normalmente se recurre a los servidores (aunque puede utilizarse
una estrategia tipo p2p). Estos servidores a su vez se sirven del sistema DNS para localizar los dominios y pueden
actuar de dos maneras:
a) Como intermediario, encaminando el mensaje hacia destino
b) Como redirector, generando una respuesta que indica al remitente la dirección del destino o de otro servidor
que lo acerque al destino.
La principal diferencia es que el servidor intermediario forma parte de la comunicación, mientras que el servidor de
redirección una vez que indica al UAC cómo encaminar el mensaje ya no interviene más.
Un mismo servidor puede actuar como redirector o como intermediario dependiendo de la situación.
Esquema de comunicación
En este ejemplo se utiliza servidores, no un sistema entre pares (p2p).
● Un usuario indica a su terminal la dirección lógica de la persona con la que quiere comunicarse.
● El agente de usuario SIP actuando como UAC envía la petición (en este caso con el método INVITE) bien al
servidor de registro local (si la llamada es a un miembro del mismo dominio) bien al servidor intermediario
que tiene configurado como servidor saliente.
○ El servidor intermediario se vale del sistema DNS para determinar la dirección del servidor SIP del
dominio del destinatario. Una vez obtenida la dirección del servidor del dominio destino, encamina hacia
allí la petición.
● El servidor del dominio destino se vale de la información de registro de dicho usuario para establecer su
ubicación física. Si la encuentra encamina la petición hacia dicha dirección.
● El agente de usuario destino, si se encuentra desocupado, comenzará a alertar al usuario destino y enviará una
respuesta hacia el usuario llamante (código 180) que sigue el camino inverso de la comunicación. Cuando el
usuario destinatario finalmente acepta la invitación, se genera una respuesta con un nuevo código de estado
(200) cuya recepción es confirmada por el UAC llamante mediante el método ACK.
● Cuando cualquiera de las partes terminar la sesión, actuando como UAC, envía una petición con el método
BYE.
Normalmente la petición con el método INVITE lleva un cuerpo donde viaja una descripción de la sesión que quiere
establecer, esta descripción es realizada con el protocolo SDP. En ella se indica el tipo de contenido a intercambiar
(voz, vídeo, etc.) y sus características (códecs, direcciones, puertos donde se espera recibirlos, velocidades de
transmisión, etc.). Esto se conoce como "oferta de sesión SDP". La respuesta a esta oferta viaja, en este caso, en el
cuerpo de la respuesta definitiva a la petición con el método INVITE. La misma contiene la descripción de la sesión
desde el punto de vista del destinatario. Si las descripciones fueran incompatibles la sesión debe terminarse (mediante
una petición con el método BYE).
Redes de comunicaciones 11. VÍDEO-DIFUSIÓN Y VÍDEO BAJO DEMANDA
11. VÍDEO-DIFUSIÓN Y VÍDEO BAJO DEMANDA

Los servicios de vídeo-difusión y vídeo bajo demanda se caracterizan por disponer de los contenidos multimedia
previamente comprimidos en servidores. De esta forma el proceso de compresión puede realizarse en diferido con la
optimización y compresión óptima.
Los servicios de vídeo-difusión son de tipo multidifusión (multicast), de forma que diferentes usuarios pueden seguir la
misma emisión, lo que produce un ahorro de recursos. El uso de multidifusión es especialmente adecuado en LAN por
su gran ventaja y sencilla implementación.
Los servicios de vídeo bajo demanda requieren el envío de la información en modo monodifusión (unicast), ya que se
pretende que el receptor tenga un control total sobre el flujo generado, pudiendo por ejemplo parar la imagen o
retroceder.
Los algoritmos de compresión preferidos para este tipo de servicio son los MPEG, ya que permiten conseguir una
eficiencia máxima a cualquier caudal. Para caudales reducidos (0,8 Mb/s e inferiores) el más adecuado es MPEG-4,
pudiéndose utilizar MPEG-2 para obtener una mayor calidad cuando el caudal disponible es de 2 Mb/s o mayor.
Debemos tener en cuenta que el uso de MPEG-4 o MPEG-2 requiere una estación decodificadora potente.
MPEG-1 es una opción interesante para valores intermedios ya que es menos exigente.
En general es aconsejable mantener los caudales utilizados por debajo del 85% del caudal nominal de la conexión para
dar cabida a la información de control que acompaña el tráfico de la aplicación.
La distribución de vídeo en directo es otra aplicación de las redes multimedia. En este caso si se utilizan los algoritmos
de compresión MPEG es necesario disponer de un códec hardware para poder realizar la compresión en tiempo real, y
aun en ese caso el retardo introducido por el proceso de compresión es apreciable. Otra opción es utilizar algoritmos
más sencillos con menor compresión.
Diferencias entre vídeo-difusión y vídeo-conferencia:

Vídeo-Difusión / Vídeo-Conferencia
Vídeo bajo demanda
Codificación MPEG-1, MPEG-4 H.263
Caudal típico 750-1500 Kb/s 128-384 Kb/s
Retardo 4-5 s 200 ms
Fluctuación del retardo (Jitter) 5-6 s 20-70 ms
La vídeo-conferencia es más exigente con la Calidad de Servicio que la vídeo-difusión.
Redes de comunicaciones 12. ANEXO I – Cortafuegos
12. ANEXO I – Cortafuegos

Un cortafuegos es un elemento de monitorización y control del tráfico entre redes. Para poder realizar su función, todo
el tráfico de entrada o salida debe de atravesarlo.
La función más básica y fundamental de un cortafuegos es determinar qué tramas deben transitar de una red a otra. El
filtrado se basa en un conjunto de reglas ordenadas y políticas definidas por el administrador. Las acciones más
generales son: aceptar la trama, rechazarla, registrarla, reenviarla o invocar tareas de autenticación. Además la mayoría
de los cortafuegos permite realizar funciones de NAT y de pasarela IP.
El orden de aplicación de las reglas es fundamental.
Las políticas principales indican si las tramas que no encajan en ningún regla de aceptación o rechazo deben ser
aceptadas o rechazadas. La política más segura, y más difícil de configurar, es la de rechazar todo lo que no sea
aceptado expresamente.
El reenvío de tramas permite la instalación en la red de servidores intermediarios transparentes. Así por ejemplo se
pueden redirigir todas las peticiones web a un intermediario web (Web Proxy) o filtrar todo el correo con herramientas
antivirus y/o antispam, sin necesidad de configurar nada en los clientes e incluso sin que éstos se enteren.
Los cortafuegos más básicos filtran paquetes a nivel 3 y a nivel 4 (existen encaminadores con capacidades de filtrado a
nivel 3, pero no se pueden considerar cortafuegos). También existen cortafuegos extendidos que trabajan a nivel de
aplicación (nivel 7) y pueden añadir cifrado, autenticación y traducción de direcciones.
Estos cortafuegos extendidos utilizan más información para posibilitar un mayor refinamiento en la definición de los
objetos a proteger. Esta nueva información se divide en:
● Información relativa al paquete en niveles superiores de la arquitectura; niveles del 4 al 7 (OSI).
● Información del estado actual y pasado de la comunicación.
● Información del estado actual y pasado de las aplicaciones.
Como ejemplo de filtrado basado en información de niveles superiores podríamos hablar de protección de URLs,
recursos, ficheros, usuarios, etc. O dentro de la gestión del estado puede supervisarse el orden en el que se realizan los
diferentes comandos de una conexión ftp: autenticación, apertura de canales, transferencias, etc.
Se puede ver un ejemplo de configuración de un servidor que actúa de pasarela y cortafuegos (iptables) con
intermediario pop3 (P3Scan), antispam (SpamAssassin), antivirus (ClamAV) e intermediario web (Squid) en:
http://www.guimi.net/index.php?pag_id=tec-docs/firewall/fw-instalacion.html
Redes de comunicaciones 13. ANEXO II – Comandos para la gestión de red
13. ANEXO II – Comandos para la gestión de red

arp
El comando arp permite utilizar el protocolo del mismo nombre para resolver equivalencias entre direcciones MAC e
IP.
En sistemas POSIX el comando arp solo puede ser utilizado por el administrador.
# arp
Address HWtype HWaddress Flags Mask Iface
maquina01.net2.upv.e ether 00:09:97:xx:xx:xx C eth1
maquina2.degi.upv.es ether 00:15:F2:xx:xx:xx C eth1
#
# arp -a
maquina01.net2.upv.es (158.42.222.x) at 00:09:97:xx:xx:xx [ether] on eth1
maquina2.degi.upv.es (158.42.222.x) at 00:15:F2:xx:xx:xx [ether] on eth1
#
# arp -n
Address HWtype HWaddress Flags Mask Iface
158.42.222.x ether 00:09:97:xx:xx:xx C eth1
158.42.222.x ether 00:15:F2:xx:xx:xx C eth1
W:\>arp -a
Interface: 158.42.222.x --- 0x50003

Internet Address Physical Address Type
158.42.222.x 00-09-97-xx-xx-xx dynamic
● “-a” indica que se muestre toda la tabla.

● “-s” permite añadir una relación estática (arp -s 192.168.1.1 xx-xx-xx-xx-xx-xx).
● “-d” permite borrar una relación de la tabla (arp -d 192.168.1.1).
dig
dig es una herramienta avanzada de sistemas POSIX que obtiene información sobre consultas y servidores DNS.
$ dig guimi.net
; <<>> DiG 9.3.4-P1.1 <<>> guimi.net

;; global options: printcmd
;; Got answer:
;; ->>HEADER<<- opcode: QUERY, status: NOERROR, id: 62659
;; flags: qr rd ra; QUERY: 1, ANSWER: 1, AUTHORITY: 0, ADDITIONAL: 0
;; QUESTION SECTION:
;guimi.net. IN A
;; ANSWER SECTION:
guimi.net. 4345 IN A 212.36.74.190
;; Query time: 0 msec

;; SERVER: 158.42.250.65#53(158.42.250.65)
;; WHEN: Tue Oct 14 12:39:53 2008
;; MSG SIZE rcvd: 43
$ dig -x 212.36.74.190
--> permite hacer búsquedas inversas
host
host es una herramienta de sistemas POSIX que obtiene información sobre consultas y servidores DNS.
$ host guimi.net
$ host -t MX guimi.net
$ host -a guimi.net
$ host 212.36.74.190
--> Respuestas similares a dig
ifconfig
ifconfig es un comando de los sistemas POSIX que permite configurar y gestionar las interfaces de red. El comando
equivalente en sistemas Windows es ipconfig.
Este comando permite mostrar información:

# ifconfig
eth1 Link encap:Ethernet HWaddr 00:17:9A:xx:xx:xx
inet addr:158.42.222.x Bcast:158.42.222.255 Mask:255.255.255.0
inet6 addr: fe80::217:9aff:fe39:xxxx/64 Scope:Link
UP BROADCAST RUNNING MULTICAST MTU:1500 Metric:1
RX packets:5563 errors:0 dropped:0 overruns:0 frame:0
TX packets:4135 errors:0 dropped:0 overruns:0 carrier:0
collisions:0 txqueuelen:1000
RX bytes:3408791 (3.2 MiB) TX bytes:743314 (725.8 KiB)
Interrupt:50 Base address:0xe400
lo Link encap:Local Loopback

inet addr:127.0.0.1 Mask:255.0.0.0
inet6 addr: ::1/128 Scope:Host
UP LOOPBACK RUNNING MTU:16436 Metric:1
RX packets:229 errors:0 dropped:0 overruns:0 frame:0
TX packets:229 errors:0 dropped:0 overruns:0 carrier:0
collisions:0 txqueuelen:0
RX bytes:246518 (240.7 KiB) TX bytes:246518 (240.7 KiB)
● “-a” permite mostrar todos los interfaces, incluyendo los que no están activos.
Permite configurar una interfaz (en todos sus detalles, aquí se muestra un ejemplo simple):
# ifconfig eth0 10.0.0.3 netmask 255.0.0.0
Permite activar o desactivar una interfaz:

# ifconfig eth0 up / down
ipconfig
ipconfig es un comando de sistemas Windows que muestra información de la configuración TCP/IP en los distintos
interfaces del sistema. Además permite renovar o liberar una configuración DHCP o limpiar la caché de DNS. El
comando equivalente en sistemas POSIX es ifconfig.
Los parámetros más interesantes son:
● “/all” muestra toda la información de todos los interfaces, aunque no estén activos.
● “/release” libera la configuración IP recibida por DHCP.
● “/renew” renueva la configuración IP de DHCP.
● “/flushdns” limpia la caché de DNS.
W:\>ipconfig
Windows IP Configuration
Ethernet adapter Local Area Connection:
Connection-specific DNS Suffix . : dominio.es

IP Address. . . . . . . . . . . . : 158.42.222.x
Subnet Mask . . . . . . . . . . . : 255.255.255.0
Default Gateway . . . . . . . . . : 158.42.222.250
W:\>
W:\>ipconfig /all
Windows IP Configuration
Host Name . . . . . . . . . . . . : maquina01

Primary Dns Suffix . . . . . . . : upvnet.upv.es
Node Type . . . . . . . . . . . . : Hybrid
IP Routing Enabled. . . . . . . . : No
WINS Proxy Enabled. . . . . . . . : No
DNS Suffix Search List. . . . . . : upv.es
Ethernet adapter Local Area Connection:
Connection-specific DNS Suffix . : upv.es

Description . . . . . . . . . . . : Marvell Yukon 88E8001/8003/8010 PCI Gigab
it Ethernet Controller
Physical Address. . . . . . . . . : 00-15-F2-xx-xx-xx
DHCP Enabled. . . . . . . . . . . : Yes
Autoconfiguration Enabled . . . . : Yes
IP Address. . . . . . . . . . . . : 158.42.222.x
Subnet Mask . . . . . . . . . . . : 255.255.255.0
Default Gateway . . . . . . . . . : 158.42.222.250
DHCP Server . . . . . . . . . . . : 158.42.xxx.x
DNS Servers . . . . . . . . . . . : 158.42.250.195
158.42.250.65
Primary WINS Server . . . . . . . : 158.42.250.200
Secondary WINS Server . . . . . . : 158.42.xxx.x
Lease Obtained. . . . . . . . . . : martes, 14 de octubre de 2008 9:22:53
Lease Expires . . . . . . . . . . : jueves, 16 de octubre de 2008 9:22:53
nbtscan
nbtscan es un comando de los sistemas POSIX que muestra estadísticas de NetBIOS y conexiones de NetBIOS sobre
TCP/IP. El comando equivalente en sistemas Windows es nbtstat.

● “-v” indica que muestre una salida con más información (similar a nbtstat).
● “-h” hace que explique los servicios.
$ nbtscan 158.42.222.x
Doing NBT name scan for addresses from 158.42.222.x
IP address NetBIOS Name Server User MAC address

------------------------------------------------------------------------------
158.42.222.x MAQUINA01 <server> <unknown> 00:15:f2:xx:xx:xx
$
$ nbtscan -v 158.42.222.x
NetBIOS Name Table for Host 158.42.222.x:
Name Service Type

----------------------------------------
MAQUINA01 <00> UNIQUE
MAQUINA01 <20> UNIQUE
UPVNET <00> GROUP
UPVNET <1e> GROUP
UPVNET <1d> UNIQUE
__MSBROWSE__ <01> GROUP
Adapter address: 00:15:f2:xx:xx:xx

----------------------------------------
$
$ nbtscan -vh 158.42.222.x
NetBIOS Name Table for Host 158.42.222.x:
Name Service Type
----------------------------------------
MAQUINA01 Workstation Service
MAQUINA01 File Server Service
UPVNET Domain Name
UPVNET Browser Service Elections
UPVNET Master Browser
__MSBROWSE__ Master Browser
Adapter address: 00:15:f2:xx:xx:xx

----------------------------------------
nbtstat
nbtstat es un comando de lo sistemas Windows muestra estadísticas de NetBIOS y conexiones de NetBIOS sobre
TCP/IP. El comando equivalente en sistemas POSIX es nbtscan.
● “-n” indica que muestre la tabla de nombres del equipo local.
● “-c” indica que utilice la caché del equipo local.
● “-r” verifica que los nombres NetBIOS se resuelven correctamente mediante WINS.
● “-a nombre” o “-A dirección_IP” indica que utilice la tabla de nombres de un equipo remoto.
W:\>nbtstat -n
Local Area Connection:

Node IpAddress: [158.42.222.x] Scope Id: []
NetBIOS Local Name Table
Name Type Status

---------------------------------------------
MAQUINA01 <00> UNIQUE Registered
MAQUINA01 <20> UNIQUE Registered
UPVNET <00> GROUP Registered
UPVNET <1E> GROUP Registered
UPVNET <1D> UNIQUE Registered
..__MSBROWSE__.<01> GROUP Registered
W:\>nbtstat -c
Local Area Connection:

Node IpAddress: [158.42.222.x] Scope Id: []
NetBIOS Remote Cache Name Table
Name Type Host Address Life [sec]

------------------------------------------------------------
TYNDAREUS <20> UNIQUE 158.42.250.x 587
JUNO.UPVNET.UPV<2E> UNIQUE 158.42.250.x 467
W:\>nbtstat -r
NetBIOS Names Resolution and Registration Statistics

----------------------------------------------------
Resolved By Broadcast = 0
Resolved By Name Server = 4608
Registered By Broadcast = 0
Registered By Name Server = 12
net
El comando net es uno de los más complejos por la cantidad de opciones diferentes que ofrece, tanto en sistemas
Windows como POSIX. En el caso de Windows agrupa 22 comandos de gestión de redes Windows (net share, net
use...). En el caso de POSIX es una herramienta para administrar servidores Samba y CIFS que en realidad agrupa 19
comandos (net time, lookup, user, group, sam, ...) de forma similar al comando de Windows.
W:\>net
NET [ ACCOUNTS | COMPUTER | CONFIG | CONTINUE | FILE | GROUP | HELP |
HELPMSG | LOCALGROUP | NAME | PAUSE | PRINT | SEND | SESSION |
SHARE | START | STATISTICS | STOP | TIME | USE | USER | VIEW ]
Algunos de los más interesantes son:

W:\>net share <-- Permite ver y modificar los recursos compartidos del sistema
Share name Resource Remark

-------------------------------------------------------------------------------
C$ C:\ Default share
ADMIN$ C:\WINDOWS Remote Admin
IPC$ Remote IPC
D$ D:\ Default share
The command completed successfully.
W:\>net use <-- Permite ver y modificar las conexiones del sistema
New connections will be remembered.
Status Local Remote Network

-------------------------------------------------------------------------------
OK W: \\maquina01\guimi Microsoft Windows Network
Disconnected X: \\maquina02\guimi Microsoft Windows Network
W:\>net start/stop <-- Permiten iniciar/parar o ver los servicios iniciados del sistema
These Windows services are started:
[...]
Workstation
netdiag
netdiag es un comando de sistemas Windows que no se instala por omisión, pero está disponible en el paquete
“Resource kit”. Permite realiza una serie de pruebas para determinar el estado y la funcionalidad de la red del equipo.
netdiag [/q] [/v] [/l] [/debug] [/d:nombreDeDominio] [/fix] [/dcaccountenum] [/test:nombreDePrueba]

[/skip:nombreDePrueba]
Algunas pruebas interesantes son: Bindings, DcList, DefGw, DNS, IPSec, Kerberos, Route...
netdiag /test:ipsec
netsh
netsh en sistemas Windows permite de forma interactiva o por parámetros configurar la red de un equipo, incluyendo
las interfaces, el cortafuegos, los sistemas ras, wins, dhcp...
W:\>netsh
netsh>help
<-- Se han eliminado la mayoría de lineas de ayuda -->
add - Adds a configuration entry to a list of entries.
firewall - Changes to the `netsh firewall' context.
interface - Changes to the `netsh interface' context.
show - Displays information.
The following sub-contexts are available:
aaaa bridge dhcp diag firewall interface ipsec ras routing rpc wins winsock
netsh>quit
netstat
netstat muestra estadísticas de uso de TCP-UDP/IP y sus conexiones. Este comando tiene muchas opciones que
además varían de sistemas Windows a sistemas POSIX.
En sistemas Windows los parámetros más interesantes son:
● “-a” muestra las conexiones y los puertos de escucha.
● “-r” muestra la tabla de encaminamiento (igual que el comando route print).
● “-e” muestra estadísticas de Ethernet.
● “-s” muestra estadísticas por protocolo.
W:\>netstat -s
IPv4 Statistics
Packets Received = 31097937

[...]
Datagrams Successfully Fragmented = 0
Datagrams Failing Fragmentation = 0
Fragments Created = 0
ICMPv4 Statistics
[...]
TCP Statistics for IPv4
[...]
UDP Statistics for IPv4
[...]
W:\>netstat -e
Interface Statistics
Received Sent
Bytes 3987777529 651861703
Unicast packets 30617810 32440422
Non-unicast packets 136910 9869
Discards 0 0
Errors 0 0
Unknown protocols 26122
W:\>
W:\>netstat -ano
Active Connections
Proto Local Address Foreign Address State PID

TCP 0.0.0.0:80 0.0.0.0:0 LISTENING 9924
TCP 0.0.0.0:135 0.0.0.0:0 LISTENING 784
TCP 0.0.0.0:389 0.0.0.0:0 LISTENING 1296
[...]
UDP 0.0.0.0:445 *:* 4
UDP 0.0.0.0:500 *:* 476
[...]
En sistemas POSIX los parámetros más interesantes son:

● “-p” muestra el PID del programa al que pertenece el socket.
● “-u” muestra datos de UDP.
● “-t” muestra datos de TCP.
● “-a” muestra todos los sockets, los que están a la escucha y los que no.
$ netstat -puta
(Not all processes could be identified, non-owned process info
will not be shown, you would have to be root to see it all.)
Active Internet connections (servers and established)
Proto Recv-Q Send-Q Local Address Foreign Address State PID/Program name
tcp 0 0 localhost:2208 *:* LISTEN -
tcp 0 0 *:vmware-authd *:* LISTEN -
[...]
tcp6 0 0 *:www *:* LISTEN -
tcp6 0 0 *:ssh *:* LISTEN -
[...]
udp 0 0 *:sunrpc *:* -
udp 0 0 *:ipp *:* -
Además en sistemas POSIX netstat sustituye a nivel de usuario a otros comandos que son propios del superusuario.
Por ejemplo route:
$ netstat -nr
Kernel IP routing table
Destination Gateway Genmask Flags MSS Window irtt Iface
158.42.xxx.0 0.0.0.0 255.255.255.0 U 0 0 0 eth1
0.0.0.0 158.42.xxx.250 0.0.0.0 UG 0 0 0 eth1
O ifconfig:
$ netstat -inet
Kernel Interface table
eth1 Link encap:Ethernet HWaddr 00:17:9A:xx:xx:xx
inet addr:158.42.xxx.x Bcast:158.42.xxx.255 Mask:255.255.255.0
inet6 addr: fe80::217:9aff:fe39:xxxx/64 Scope:Link
[...]
nmap
nmap es un analizador de puertos disponible en sistemas POSIX y Windows.
Ejemplos de uso:
$ nmap localhost <-- Si no se indican puertos con -p analiza [0-1023]
Starting Nmap 4.11 ( http://www.insecure.org/nmap/ ) at 2008-10-17 14:34 CEST

Interesting ports on localhost (127.0.0.1):
Not shown: 1672 closed ports
PORT STATE SERVICE
22/tcp open ssh
80/tcp open http
111/tcp open rpcbind
113/tcp open auth
631/tcp open ipp
902/tcp open iss-realsecure-sensor
3306/tcp open mysql
5432/tcp open postgres
nmap finished: 1 IP address (1 host up) scanned in 0.209 seconds$ nmap 192.168.1.1
$ nmap -sP xxx.xx.xxx.0/24 <-- Busca e identifica equipos en la red
Starting Nmap 4.11 ( http://www.insecure.org/nmap/ ) at 2008-10-17 14:34 CEST

Host maquina01 (xxx.xx.xxx.1) appears to be up.
[...]
Nmap finished: 256 IP addresses (5 hosts up) scanned in 2.258 seconds
nslookup
nslookup obtiene información sobre consultas y servidores DNS. Se puede utilizar interactivamente o proporcionando
parámetros directamente en la invocación. Se utiliza igual en sistemas Windows y POSIX.
Ejemplo de uso interactivo:

W:\>nslookup
Default Server: juno.cc.upv.es <-- Nos indica el servidor DNS
Address: 158.42.250.195
> guimi.net <-- Consultamos un dominio

Server: juno.cc.upv.es
Address: 158.42.250.195
[...]
> set type=MX <-- Consultamos un subconjunto de entradas DNS
<-- Podemos indicar: any, MX, NS, CNAME, A, SOA
> guimi.net
[...]
>
> server 213.0.184.85 <-- Cambiamos el servidor DNS de consulta
Default Server: 85.red-213-0-184.static.ccgg.telefonica.net
Address: 213.0.184.85
> exit <-- Terminamos la utilidad nslookup
Ejemplos de uso no interactivo:

W:\>nslookup guimi.net
Server: juno.cc.upv.es
Address: 158.42.250.195
Non-authoritative answer:
Name: guimi.net
Address: 212.36.74.190
$ nslookup 212.36.74.190
Server: 158.42.250.65
Address: 158.42.250.65#53
Non-authoritative answer:
190.74.36.212.in-addr.arpa name = hc05.cdmon.com.
[...]
pathping
El comando pathping primero muestra los saltos hacia el destino como tracert, a continuación ejecuta varios pings
hacia cada destino y calcula estadísticas.

● “-n” para que no resuelva nombres de máquina.
● “-h” indica la cantidad máxima de saltos.
● “-q” indica el número de pings a enviar a cada nodo.
W:\>pathping
Usage: pathping [-g host-list] [-h maximum_hops] [-i address] [-n]

[-p period] [-q num_queries] [-w timeout]
[-4] [-6] target_name
Options:
-g host-list Loose source route along host-list.
-h maximum_hops Maximum number of hops to search for target.
-i address Use the specified source address.
-n Do not resolve addresses to hostnames.
-p period Wait period milliseconds between pings.
-q num_queries Number of queries per hop.
-w timeout Wait timeout milliseconds for each reply.
-4 Force using IPv4.
-6 Force using Ipv6.
W:\>pathping -n guimi.net
Tracing route to guimi.net [212.36.74.190]

over a maximum of 30 hops:
0 158.42.xxx.x
1 158.42.xxx.xx
[...]
8 212.36.74.190
Computing statistics for 200 seconds...

Source to Here This Node/Link
Hop RTT Lost/Sent = Pct Lost/Sent = Pct Address
0 158.42.xxx.x
0/ 100 = 0% |
1 0ms 0/ 100 = 0% 0/ 100 = 0% 158.42.xxx.xxx
0/ 100 = 0% |
[...]
8 7ms 0/ 100 = 0% 0/ 100 = 0% 212.36.74.190
Trace complete.
ping
El comando ping utiliza paquetes “echo” (ping) y “echo reply” (pong) de ICMP para comprobar la conectividad con
una IP.
En sistemas Windows “-n” establece el número de paquetes a enviar (por omisión 4).
W:\>ping guimi.net -n 1
Pinging guimi.net [212.36.74.190] with 32 bytes of data:
Reply from 212.36.74.190: bytes=32 time=6ms TTL=57
Ping statistics for 212.36.74.190:

Packets: Sent = 1, Received = 1, Lost = 0 (0% loss),
Approximate round trip times in milli-seconds:
Minimum = 6ms, Maximum = 6ms, Average = 6ms
En sistemas POSIX el parámetro “-n” (numbers) indica que no resuelva los nombres y muestre solo los números de la
dirección y el parámetro “-c” establece el número de paquetes a enviar (por omisión infinitos).
$ ping guimi.net -c 1 -n
PING guimi.net (212.36.74.190) 56(84) bytes of data.
64 bytes from 212.36.74.190: icmp_seq=1 ttl=57 time=6.90 ms
--- guimi.net ping statistics ---

1 packets transmitted, 1 received, 0% packet loss, time 0ms
rtt min/avg/max/mdev = 6.904/6.904/6.904/0.000 ms
route
El comando route permite consultar y gestionar las tablas de encaminamiento de red. Las posibilidades que ofrece son
amplias y su sintaxis varía considerablemente de sistemas Windows a sistemas POSIX.
Ejemplos en un sistema POSIX (debe ejecutarse como superusuario):

# route
Kernel IP routing table
Destination Gateway Genmask Flags Metric Ref Use Iface
158.42.xxx.0 * 255.255.255.0 U 0 0 0 eth1
default rou-aulasiqn.ne 0.0.0.0 UG 0 0 0 eth1
# route add -net 192.56.76.0 netmask 255.255.255.0 eth0

--> Indica que los paquetes enviados a la red 192.56.76.0/24 salgan por la interfaz eth0
# route add default gw migw

--> Establece como pasarela por defecto “migw”
# route add -net 10.0.0.0 netmask 255.0.0.0 reject

--> Indica que se rechacen los paquetes con destino 10.0.0.0/8
Ejemplos en un sistema Windows:

W:\>route print
IPv4 Route Table

===========================================================================
Interface List
0x1 ........................... MS TCP Loopback interface
0x50003 ...00 15 f2 d0 0c b8 ...... Marvell Yukon 88E8001/8003/8010 PCI Gigabit
Ethernet Controller - Trend Micro Common Firewall Miniport
===========================================================================
===========================================================================
Active Routes:
Network Destination Netmask Gateway Interface Metric
0.0.0.0 0.0.0.0 158.42.222.250 158.42.222.1 20
127.0.0.0 255.0.0.0 127.0.0.1 127.0.0.1 1
[...]
Default Gateway: 158.42.222.250
===========================================================================
Persistent Routes:
None
C:\> route ADD 157.0.0.0 MASK 255.0.0.0 157.55.80.1 METRIC 3 IF 2

destination^ ^mask ^gateway metric^ ^
Interface^
tc
tc es un comando de sistemas POSIX que permite gestionar el control de tráfico, limitando las capacidades de una
interfaz o generando prioridades de tráfico (QoS).
traceroute
traceroute es un comando de sistemas POSIX que determina la ruta y los saltos necesarios para alcanzar un destino IP
utilizando por omisión paquetes UDP. También puede utilizar paquetes ICMP con el parámetro “-I”. El comando
equivalente en sistemas WINDOWS es tracert.
El parámetro “-n” (numbers) indica que no resuelva los nombres y muestre solo los números de la dirección.
$ traceroute guimi.net
traceroute to guimi.net (212.36.74.190), 30 hops max, 40 byte packets
1 rou-aulasiqn.net2.upv.es (158.42.222.250) 0.631 ms 0.527 ms 0.521 ms
2 cauac-1.net2.upv.es (158.42.254.94) 0.234 ms 0.205 ms 0.204 ms
3 kukulcan.net.upv.es (158.42.255.58) 0.613 ms 0.538 ms 0.683 ms
4 GE1-0-3.EB-Valencia0.red.rediris.es (130.206.211.153) 1.092 ms 1.011 ms 0.815 ms
5 VAL.XE0-0-0.EB-Barcelona0.red.rediris.es (130.206.250.45) 15.142 ms 11.206 ms 5.661 ms
6 adam.01.catnix.net (193.242.98.12) 7.375 ms 6.776 ms 6.758 ms
7 sw2pp-rc1-dc.adam.es (195.219.118.3) 6.883 ms 7.623 ms 8.799 ms
8 * * *
$ traceroute guimi.net -n -I
traceroute to guimi.net (212.36.74.190), 30 hops max, 40 byte packets
1 158.42.222.250 0.674 ms 0.511 ms 0.508 ms
2 158.42.254.94 8.106 ms 0.335 ms 0.212 ms
3 158.42.255.58 0.786 ms 0.485 ms 0.341 ms
4 130.206.211.153 0.802 ms 2.129 ms 15.974 ms
5 130.206.250.45 7.915 ms 7.992 ms 7.917 ms
6 193.242.98.12 8.017 ms 9.086 ms 14.754 ms
7 195.219.118.3 8.104 ms 9.810 ms 6.707 ms
8 212.36.74.190 7.284 ms 6.463 ms 6.530 ms
tracert
tracert es un comando de sistemas Windows que determina la ruta y los saltos necesarios para alcanzar un destino IP
utilizando paquetes ICMP y su valor de TTL (Time To Live). El comando equivalente en sistemas POSIX es
traceroute.
W:\>tracert
Usage: tracert [-d] [-h maximum_hops] [-j host-list] [-w timeout] [-R] [-S srcaddr] [-4] [-6]
target_name
Options:
-d Do not resolve addresses to hostnames.
-h maximum_hops Maximum number of hops to search for target.
-j host-list Loose source route along host-list (IPv4-only).
-w timeout Wait timeout milliseconds for each reply.
-R Trace round-trip path (IPv6-only).
-S srcaddr Source address to use (IPv6-only).
W:\>tracert guimi.net
Tracing route to guimi.net [212.36.74.190] over a maximum of 30 hops:
[...]
6 8 ms 7 ms 7 ms adam.01.catnix.net [193.242.98.12]
7 7 ms 7 ms 6 ms sw2pp-rc1-dc.adam.es [195.219.118.3]
8 6 ms 6 ms 6 ms hc05.cdmon.com [212.36.74.190]
Trace complete.
Redes de comunicaciones 14. ANEXO III - La VC en el campo educativo
14. ANEXO III - La VC en el campo educativo

Extracto de “La videoconferencia en el campo educativo. Técnicas y procedimientos.” de Miquel Oliver Ribas, Universidad de las Islas Baleares.
(http://www.uib.es/depart/gte/oliver.html).
14.1. Introducción
De entre la multitud de tecnologías de posible aplicación que posibilitan la interactividad en el campo de la formación,
la vídeo-conferencia es, sin duda, una de las que mayor futuro tiene en lo referente a enseñanza no presencial, puesto
que permite una interacción permanente, en tiempo real, con imagen y sonido entre diferentes puntos, haciendo posible
que, diferentes profesores, diferentes alumnos, diferentes centros escolares, etc. participen en el proceso de
comunicación.
Enseñar a través de vídeo-conferencia supone, no obstante, un cambio en cuanto a la metodología tradicional aplicada
en los sistemas presenciales de enseñanza. Esta nueva tecnología necesita formas distintas de interacción, diferente
comportamiento físico, distintas maneras de presentar la información y diferentes formas de juzgar los mensajes que se
puedan transmitir en ambas direcciones.
La vídeo-conferencia puede ser punto a punto o multipunto. En el primer caso cada punto dispone de una consola que
controla las diferentes funciones: como el movimiento de la cámara, el foco, el sonido, etc y cada lugar observa el otro a
través de sus respectivos monitores. En la vídeo-conferencia multipunto no es posible lograr la denominada "presencia
continua", es decir, todos los usuarios no pueden verse simultáneamente entre sí. En cada momento dado, sólo se puede
ver a una persona.
La mayoría de equipos admiten cámaras auxiliares, de modo que la vídeo-conferencia pueda ser más flexible. La salida
de vídeo puede ser conectada a un cañón de proyección y/o a un magnetoscopio, pudiéndose grabar la vídeo-
conferencia. Además también pueden compartir datos y trabajar a la vez con un mismo documento, hacer anotaciones
sobre él, modificar campos, tomar notas, etc.
14.2. Técnicas de realización

Los distintos elementos que componen un equipo de videoconferencia pueden ser controlados por el mismo
conferenciante, o por un equipo de realización formado por técnicos.
Cuando se trata de vídeo-conferencia punto a punto, en la que el conferenciante utiliza pocos medios para
complementar su exposición (a veces un solo PC con una cámara) puede controlarlo el mismo conferenciante.
En entornos más complejos, con multipunto, varias cámaras y micrófonos, salas de conferenciantes, etc ..., la
realización puede pasar a uno o varios técnicos, que efectúan las conmutaciones de las diferentes cámaras, del sonido y
de todos los demás elementos que se vayan a utilizar, así como la selección de la imagen a recibir (en multipunto).
Existen sistemas automatizados que permiten que la conmutación de vídeo se efectúe a través de la voz, de manera que
cuando alguien habla, todos los demás participantes ven la imagen del orador en la pantalla. Incluso algunos sistemas
permiten enfocar automáticamente la cámara hacia el orador en grandes salas con múltiples participantes.
Aspectos técnicos que hay que prever

– Pantallas. Lo ideal es que cada sala disponga de un sistema de vídeo-proyección, de forma que los alumnos
presten atención a una sola pantalla.
– Micrófonos. Los micrófonos de solapa son los mejores, puesto que ofrecen una mayor libertad de movimiento. Es
bueno disponer de uno o más micrófonos para captar el ambiente de la sala y para las intervenciones del público.
– Cámaras. En la sala donde se emite la vídeo-conferencia, lo mejor es disponer de dos: una para el profesor y otra
para los alumnos presentes. En la sala(s) receptora(s) los alumnos el profesor debe poder ver a los alumnos
mediante cámaras instaladas en cada sala. Cuando se trata de una videoconferencia punto a punto, el profesor debe
poder controlar de forma remota la cámara de la otra sala.
– Iluminación. Es importante cuidar la iluminación. Es recomendable que sea cenital, fría o luz rebotada en
superficies blancas. La temperatura de color ideal es de 3.200º K.
Redes de comunicaciones 14. ANEXO III - La VC en el campo educativo
14.3. Elementos que el profesor tiene que contemplar

Antes de la vídeo-conferencia
– Planificar y ensayar la presentación.
– Familiarizarse con el equipo y los diferentes medios que utilizará (escáner, retro-proyector, vídeo-
presentación...).
– Conseguir que todos los participantes se impliquen.
– Fomentar la interacción informal entre las distintas aulas que participen en la VC:
– Hacer una introducción personal.
– Recorrer la sala con la cámara, haciendo panorámica (si es posible).
Durante la vídeo-conferencia
Intentar involucrar a toda la audiencia (participación de alumnos de cada una de las aulas).
Nivel oral.
– Hablar claro e intentar mantener un volumen constante.
– Utilizar a menudo pausas.
– Permitir interrupciones por parte de los participantes.
– Indicar, claramente, cuándo ha terminado de hablar y se está esperando la réplica.
Nivel visual.
– Evitar excesivos movimientos o movimientos bruscos.
– Mantener a la vista los gráficos, imágenes o cualquier otro tipo de material que utilicemos durante un
periodo de tiempo más largo de lo habitual. No moverlos una vez posicionados.
– Evitar el uso de imágenes, gráficos, etc. de baja calidad (no utilizar segundas generaciones de vídeo).
– Ir vestido con ropas de colores poco llamativos.
– La persona que quiera intervenir, en primer lugar tiene que esperar a que la cámara lo encuadre y enfoque,
en segundo lugar tiene que identificarse.
– Utilizar diferentes medios para atraer la atención (transparencias, diapositivas, vídeo, etc.)
Después de la vídeo-conferencia
Una vez terminada la vídeo-conferencia evaluar la experiencia. Desde el punto de vista pedagógico, la evaluación
comportaría dos vertientes: evaluación de la experiencia tecnológica, de la metodología empleada y del profesorado
-por parte del alumno-, y evaluación de la eficacia del aprendizaje, -por parte del profesor o profesores-.
Capítulo 9: División de
redes IP en subredes
Introducción a redes
Ing. Aníbal Coto Cortés
Presentation_ID © 2008 Cisco Systems, Inc. Todos los derechos reservados. Información confidencial de Cisco 1
Capítulo 9
9.1 División de una red IPv4 en subredes
9.2 Esquemas de direccionamiento
9.3 Consideraciones de diseño para IPv6
9.4 Resumen
Capítulo 9: Objetivos
 Explicar por qué el enrutamiento es necesario para que los
hosts de distintas redes puedan comunicarse.
 Describir el protocolo IP como un protocolo de comunicación
utilizado para identificar un único dispositivo en una red.
 Dada una red y una máscara de subred, calcular la cantidad
de direcciones de host disponibles.
 Calcular la máscara de subred necesaria para adaptarse a los
requisitos de una red.
 Describir los beneficios de las máscaras de subred de
longitud variable (VLSM, variable length subnet masking).
 Explicar la forma en que se implementan las asignaciones de
direcciones IPv6 en una red comercial.
Segmentación de red
Motivos para la división en subredes
Es necesario segmentar las redes grandes en subredes más
pequeñas, con lo que se crean grupos más pequeños de
dispositivos y servicios con los siguientes fines:
 Controlar el tráfico mediante la contención del tráfico de broadcast
dentro de la subred.
 Reducir el tráfico general de la red y mejorar el rendimiento de esta.
División en subredes: proceso de segmentación de una red en varios
espacios de red más pequeños o subredes.
Comunicación entre subredes

 Se necesita un router para que los dispositivos en diferentes redes
y subredes puedan comunicarse.
 Cada interfaz del router debe tener una dirección de host IPv4 que
pertenezca a la red o a la subred a la cual se conecta la interfaz del
router.
 Los dispositivos en una red y una subred utilizan la interfaz del
router conectada a su LAN como gateway predeterminado.
División de una red IPv4 en subredes
La división de IP en subredes es fundamental
División básica en subredes
Préstamo de bits para crear subredes
Si se toma prestado 1 bit, 2^1 = 2 subredes.
Si se toma prestado 1 bit de la porción de host, se crean 2 subredes con la misma

máscara de subred.
Subred 0 Subred 1
Red 192.168.1.0-127/25 Red 192.168.1.128-255/25
Máscara: 255.255.255.128 Máscara: 255.255.255.128
Subredes en uso
Subred 0
Red 192.168.1.0-127/25
Subred 1
Red 192.168.1.128-255/25
Fórmulas de división en subredes
Cálculo de cantidad de subredes
Cálculo de número de hosts
Creación de cuatro subredes
Si se toman prestados 2 bits, se crean 4 subredes.
2^2 = 4 subredes
Creación de ocho subredes
Si se toman prestados 3 bits, se crean 8 subredes.
2^3 = 8 subredes
Creación de ocho subredes (continuación)
Determinación de la máscara de subred
Requisitos de la división en subredes
basada en host
Existen dos factores que se deben tener en cuenta al
planificar las subredes:
Cantidad de subredes requeridas
Cantidad de direcciones de host requeridas
Fórmula para determinar la cantidad de hosts utilizables
2^n-2
2^n (donde “n” es la cantidad de bits de host restantes) se utiliza
para calcular la cantidad de hosts.
-2 la ID de subred y la dirección de broadcast no se pueden utilizar
en cada subred.
Requisitos de la división en subredes basada en redes
Cálculo de cantidad de subredes
 Fórmula 2^n (donde n representa la cantidad de bits que
se tomaron prestados)
 Subredes
necesarias para
cada departamento
en el gráfico
División en subredes para cumplir con los
requisitos de la red
 Es importante lograr un equilibrio entre la cantidad de
subredes necesarias y la cantidad de hosts que se
requieren para la subred más grande.
 Diseñar el esquema
de direccionamiento
para admitir la
cantidad máxima de
hosts para cada
subred.
 Dejar espacio para el
crecimiento en cada
subred.
División en subredes para cumplir con los requisitos de
la red (cont.)
Beneficios de la máscara de subred de longitud variable
Desperdicio de direcciones de la división en
subredes tradicional
 División en subredes tradicional: se asigna la misma cantidad de
direcciones a cada subred.
 Las subredes que requieren menos direcciones tienen direcciones
sin utilizar (desperdiciadas). Por ejemplo, los enlaces WAN solo
necesitan dos direcciones.
 La máscara de subred de longitud variable (VLSM), o subdivisión de
subredes, permite un uso más eficiente de las direcciones.
Máscaras de subred de longitud variable (VLSM)
 VLSM permite dividir un espacio de red en partes
desiguales.
 La máscara de subred varía según la cantidad de bits
que se toman prestados para una subred específica.
 La red primero se divide en subredes y, a continuación,
las subredes se vuelven a dividir en subredes.
 Este proceso se repite según sea necesario para crear
subredes de diversos tamaños.
 En el proceso de crear subredes con VLSM se

recomienda iniciar con la subredes más grandes y
terminar con las más pequeñas.
VLSM básica
VLSM en la práctica
 Si se utilizan subredes VLSM, se pueden direccionar los
segmentos LAN y WAN incluidos en el ejemplo
a continuación con un mínimo desperdicio.
 A cada LAN se le asignará una subred con la máscara /27.
 A cada enlace WAN se le asignará una subred con la
máscara /30.
Cuadro de VLSM
Diseño estructurado
Planificación del direccionamiento de la red
Se debe planificar y registrar la asignación de direcciones
de red para los siguientes propósitos:
Evitar duplicación de direcciones
Proporcionar y controlar el acceso
Controlar seguridad y rendimiento
Direcciones para los clientes: por lo general, se asignan de
forma dinámica mediante el protocolo de configuración
dinámica de host (DHCP).
Ejemplo de plan de
direccionamiento de
red
División en subredes de una red IPv6
División en subredes mediante la ID de subred
Un espacio de red IPv6 se divide en subredes para admitir
un diseño jerárquico y lógico de la red.
Asignación de subredes IPv6
División en subredes en la ID de interfaz
Se pueden tomar prestados bits de la ID de interfaz para
crear subredes IPv6 adicionales.
Capítulo 9: Resumen
 El proceso de segmentación de una red mediante su división
en varios espacios de red más pequeños se denomina
“división en subredes”.
 La subdivisión de subredes, o el uso de una máscara de
subred de longitud variable (VLSM), se diseñó para evitar que
se desperdicien direcciones.
 El espacio de direcciones IPv6 es enorme, de manera que se
divide en subredes para admitir el diseño jerárquico y lógico
de la red y no para conservar direcciones.
 Los requisitos de tamaño, ubicación, uso y acceso son
consideraciones que se deben tener en cuenta en el proceso
de planificación de direcciones.
 Se deben probar las redes IP para verificar la conectividad
y el rendimiento operativo.
Capítulo 9: Resumen
 El proceso de segmentación de una red mediante su división
en varios espacios de red más pequeños se denomina
“división en subredes”.
 La subdivisión de subredes, o el uso de una máscara de
subred de longitud variable (VLSM), se diseñó para evitar que
se desperdicien direcciones.
 El espacio de direcciones IPv6 es enorme, de manera que se
divide en subredes para admitir el diseño jerárquico y lógico
de la red y no para conservar direcciones.
 Los requisitos de tamaño, ubicación, uso y acceso son
consideraciones que se deben tener en cuenta en el proceso
de planificación de direcciones.
 Se deben probar las redes IP para verificar la conectividad
y el rendimiento operativo.
C A P Í T U L O
2
El modelo OSI y los
protocolos de red
• OSI, la pila teórica de protocolos de red.

• Las capas OSI.
• Las subcapas del enlace de datos.
• Protocolos de red del mundo real.
31
OSI, la pila teórica de protocolos de red

Los modelos conceptuales no versan sobre ninguna cuestión en particular, se trate de
la disciplina que se trate. El arte incluye las teorías del color y el diseño; la física abarca
prácticamente todos los modelos teóricos que Einstein garabateó en una servilleta. Las
redes informáticas no son distintas, y se sirven de un modelo conceptual o marco de tra-
bajo que da cabida a una compleja cadena de eventos: el movimiento de datos en una red.
A finales de la década de los setenta, la Organización Internacional para la Normali-
zación (ISO) empezó a desarrollar un modelo conceptual para la conexión en red al que
bautizó con el nombre de Open Systems Interconnection Reference Model o Modelo de
Referencia de Interconexión de Sistemas Abiertos. En los entornos de trabajo con redes
se le conoce más comúnmente como el modelo OSI (y, con toda probabilidad, sin ni
siquiera saber el significado exacto de esta sigla). En 1984, este modelo pasó a ser el
estándar internacional para las comunicaciones en red al ofrecer un marco de trabajo con-
ceptual que permitía explicar el modo en que los datos se desplazaban dentro de una red.
ISO ABARCA MUCHOS CAMPOS

La Organización Internacional para la Normalización (ISO) se encarga de desarro-
llar conjuntos de normas y modelos para cuestiones que van desde los estánda-
res técnicos para las conexiones en red hasta la forma en que las compañías
deben hacer negocios en el mercado internacional. Seguramente habrá visto algu-
na vez productos con etiquetas anunciando que cuentan con el certificado ISO
9002. Esto significa que cumplen con el conjunto de normas y protocolos que ha
desarrollado la ISO para regular la actividad comercial en el mercado mundial.
Otro certificado ISO que suele verse con frecuencia es el ISO 9660, que define los
sistemas de archivo para CD-ROM.
El modelo OSI divide en siete capas el proceso de transmisión de la información entre

equipos informáticos, donde cada capa se encarga de ejecutar una determinada parte del
proceso global. Este marco de trabajo estructurado en capas, aun siendo puramente con-
ceptual, puede utilizarse para describir y explicar el conjunto de protocolos reales que,
como veremos, se utilizan para la conexión de sistemas. Por ejemplo, TCP/IP y Apple-
Talk son dos de las pilas de protocolos que se utilizan en el mundo real para transmitir
datos; los protocolos que, de hecho, sirven como capas o niveles dentro de un conjunto de
protocolos como TCP/IP pueden, por tanto, explicarse de acuerdo con su correlación con
el modelo teórico de capas o niveles de red que conforma OSI.
VÉASE TAMBIÉN
➤ Para más información acerca de las suite de protocolos de red que actualmente se utilizan, consulte el
apartado “Protocolos de red del mundo real” incluido en este mismo capítulo.
PERO, ¿QUÉ ES EXACTAMENTE UNA PILA DE PROTOCOLOS?

Las pilas o suite (o capas) de protocolos no son más que una jerarquía de peque-
ños protocolos que trabajan juntos para llevar a cabo la transmisión de los datos
32 2 El modelo OSI y los protocolos de red
de un nodo a otro de la red. Las pilas de protocolos se asemejan mucho a las

carreras de relevos, pero, en vez de pasarse un testigo, se transmiten paquetes de
datos de un protocolo a otro hasta que éstos revisten la forma adecuada (una
secuencia única de bits) para transmitirse por el entorno físico de la red.
TAMBIÉN EXISTE LA PILA DE PROTOCOLOS ISO/OSI

Aunque los administradores de red están familiarizados con pilas de protocolos de
red como IPX/SPX de NetWare o TCP/IP, muchos desconocen la existencia de la
suite de protocolos basada en el modelo OSI, denominada pila de protocolos OSI.
Por desgracia, los sistemas operativos de red más utilizados (como Novell NetWa-
re o Windows NT) no la soportan.
El modelo OSI abarca una serie de eventos importantes que se producen durante la
comunicación entre sistemas. Proporciona las normas básicas empíricas para una serie de
procesos distintos de conexión en red:
• El modo en que los datos se traducen a un formato apropiado para la arquitectura
de red que se está utilizando. Cuando se envía un mensaje de correo electrónico o
un archivo a otra computadora, se está trabajando, en realidad, con una determi-
nada aplicación, como un cliente de correo electrónico o un cliente FTP. Los datos
que se transmiten utilizando dicha aplicación tienen que convertirse a un formato
más genérico si van a viajar por la red hasta llegar a su destino.
• El modo en que los PC u otro tipo de dispositivos de la red se comunican. Cuando
se envían datos desde un PC, tiene que existir algún tipo de mecanismo que pro-
porcione un canal de comunicación entre el remitente y el destinatario. Lo mismo
que cuando se desea hablar por teléfono, para lo cual hay que descolgar el teléfo-
no y marcar el número.
• El modo en que los datos se transmiten entre los distintos dispositivos y la forma
en que se resuelve la secuenciación y comprobación de errores. Una vez estable-
cida la sesión de comunicación entre dos computadoras, tiene que existir un con-
junto de reglas que controlen la forma en que los datos van de una a otra.
• El modo en que el direccionamiento lógico de los paquetes pasa a convertirse en
el direccionamiento físico que proporciona la red. Las redes informáticas utilizan
esquemas de direccionamiento lógico, como direcciones IP. Por tanto, dichas
direcciones lógicas tienen que convertirse en las direcciones reales de hardware
que determinan las NIC instaladas en las distintas computadoras.
El modelo OSI ofrece los mecanismos y reglas que permiten resolver todas las cues-
tiones que acabamos de referir. Comprender las distintas capas del modelo OSI no sólo
permite internarse en los conjuntos de protocolos de red que actualmente se utilizan, sino
que también proporciona un marco de trabajo conceptual del que puede servirse cual-
quiera para comprender el funcionamiento de dispositivos de red complejos, como con-
mutadores, puentes y routers. (Buena parte de este libro versa sobre los routers y el enca-
minamiento de datos en general.)
33
Las capas OSI

Las capas del modelo OSI describen el proceso de transmisión de los datos dentro de
una red. Las dos únicas capas del modelo con las que, de hecho, interactúa el usuario son
la primera capa, la capa Física, y la última capa, la capa de Aplicación.
• La capa física abarca los aspectos físicos de la red (es decir, los cables, hubs y el
resto de dispositivos que conforman el entorno físico de la red). Seguramente ya
habrá interactuado más de una vez con la capa Física, por ejemplo al ajustar un
cable mal conectado.
• La capa de aplicación proporciona la interfaz que utiliza el usuario en su compu-
tadora para enviar mensajes de correo electrónico o ubicar un archivo en la red.
Obviamente, el capítulo resultaría demasiado corto si limitáramos nuestra explicación
a estas dos capas, además de ser incompleto, ya que cada capa del modelo OSI desempe-
ña un papel decisivo en la transmisión por red de la información.
La Figura 2.1 presenta la estructura de capas que conforman el modelo OSI de arriba
abajo. La pirámide invertida es uno de los modos que mejor ilustran la estructura de este
modelo, en el que los datos con un formato bastante complejo pasan a convertirse en una
secuencia simple de bits cuando alcanzan el cable de la red. Como verá, las capas vienen
numeradas de abajo arriba, cuando lo lógico sería que vinieran numeradas de arriba aba-
jo. Éste es el sistema adoptado y, de hecho, muchas veces se alude al mismo para referir-
se a una de las capas de la red. Pero, tanto si se usa el nombre como el número, lo impor-
tante es que recuerde siempre el papel que desarrollan cada una de las capas en el proceso
global de transmisión de los datos.
Aplicación
7
Presentación
6
Sesión
5
Transporte
4
Red
3
Enlace de datos
2
Física
1
FIGURA 2.1
El modelo OSI ofrece un modelo teórico que explica el modo en que se desplazan los
datos desde una computadora emisora a otra computadora receptora.
Una buena forma de recordar el orden ascendente que siguen las capas de este mode-
lo es utilizar una expresión mnemónica como la siguiente: Fernando Está Recordando
Todos Sus Primeros Años. Y de hecho es imprescindible que tenga siempre presente este
modelo, ya que cualquier cuestión referente a la tecnología de conexión entre sistemas,
desde la más nimia hasta la más compleja, alude al mismo. Todos los libros y artículos
que hablan de la conexión en red hacen referencia a este modelo.
Antes de explicar cada una de las capas que componen la pila, conviene hacerse una
idea general de lo que ocurre cuando los datos se mueven por el modelo OSI. Suponga-
mos que un usuario decide enviar un mensaje de correo electrónico a otro usuario de la
red. El usuario que envía el mensaje utilizará un cliente o programa de correo (como
Outlook o Eudora) como herramienta de interfaz para escribir y enviar el mensaje. Esta
actividad del usuario se produce en la capa de aplicación.
Cuando los datos abandonan la capa de aplicación (la capa insertará un encabezado de
capa de aplicación en el paquete de datos), éstos pasan por las restantes capas del modelo
OSI. Cada capa proporcionará servicios específicos relacionados con el enlace de comuni-
cación que debe establecerse, o bien formateará los datos de una determinada forma.
Al margen de la función específica que tenga asignada cada capa, todas adjuntan un
encabezado (los encabezados vienen representados por cuadritos en la Figura 2.2) a los
datos. Puesto que la capa física está integrada por dispositivos de hardware (un cable, por
ejemplo) nunca añade un encabezado a los datos.
Los datos llegan así a la capa física (el entorno tangible de la red, como los cables de
par trenzado y hubs que conectan las computadoras entre sí) de la computadora del desti-
natario, desplazándose por el entorno físico de la red hasta alcanzar su destino final, el
usuario al que iba dirigido el mensaje de correo electrónico.
Los datos se reciben en la capa física de la computadora del destinatario y pasan a
subir por la pila OSI. A medida que los datos van pasando por cada una de las capas, el
encabezado pertinente se va suprimiendo de los datos. Cuando los datos finalmente alcan-
zan la capa de aplicación, el destinatario puede utilizar su cliente de correo electrónico
para leer el mensaje que ha recibido.
A continuación pasamos a explicar cada una de las capas que componen el modelo
OSI, de arriba abajo (es decir, desde la capa de aplicación hasta la capa física).
La capa de aplicación
La capa de aplicación proporciona la interfaz y servicios que soportan las aplicacio-
nes de usuario. También se encarga de ofrecer acceso general a la red.
Esta capa suministra las herramientas que el usuario, de hecho, ve. También ofrece los
servicios de red relacionados con estas aplicaciones de usuario, como la gestión de men-
sajes, la transferencia de archivos y las consultas a bases de datos. La capa de aplicación
suministra cada uno de estos servicios a los distintos programas de aplicación con los que
cuenta el usuario en su computadora. Entre los servicios de intercambio de información
35
que gestiona la capa de aplicación se encuentran la Web, los servicios de correo electró-
nico (como el Protocolo Simple de Transferencia de Correo, comúnmente conocido como
SMTP ––Simple Mail Transfer Protocol––incluido en TCP/IP), así como aplicaciones
especiales de bases de datos cliente/servidor.
➁ ➀ ➃
Computadora emisora Computadora receptora
Aplicación Data Data Aplicación
Presentación A Data A Data Presentación
Sesión P A Data P A Data Sesión
Transporte S P A Data S P A Data Transporte
Red T S P A Data T S P A Data Red

Enlace de datos N T S P A Data N T S P A Data Enlace de datos
Física D S T S P A Data D S T S P A Data Física
Entorno físico de la red
➂
1. Encabezado de la capa de aplicación.
2. Encabezado de la capa de presentación.
3. Paquete con todos los encabezados de las capas OSI.
4. Los encabezados se van suprimiendo a medida que los datos suben por la capa OSI.
FIGURA 2.2
Los datos bajan por la pila OSI de la computadora emisora y suben por la pila OSI de la
computadora receptora.
La capa de presentación
La capa de presentación puede considerarse el traductor del modelo OSI. Esta capa
toma los paquetes (la creación del paquete para la transmisión de los datos por la red
empieza en realidad en la capa de aplicación) de la capa de aplicación y los convierte a un
formato genérico que pueden leer todas las computadoras. Por ejemplo, los datos escritos
en caracteres ASCII se traducirán a un formato más básico y genérico.
La capa de presentación también se encarga de cifrar los datos (si así lo requiere la
aplicación utilizada en la capa de aplicación) así como de comprimirlos para reducir su
tamaño. El paquete que crea la capa de presentación contiene los datos prácticamente con
el formato con el que viajarán por las restantes capas de la pila OSI (aunque las capas
siguientes irán añadiendo elementos al paquete, lo cual puede dividir los datos en paque-
tes más pequeños).
LA COMUNICACIÓN SE PRODUCE DIRECTAMENTE ENTRE CAPAS

A medida que los datos bajan por la pila de protocolos de la computadora emiso-
ra (por ejemplo, un mensaje de correo electrónico) hasta llegar al cable físico y de
ahí pasan a subir por la pila de protocolos de la computadora receptora, la comu-
nicación entre ambas máquinas se está produciendo en realidad entre capas com-
plementarias. Por ejemplo, cuando se envía un mensaje entre dos computadoras
existe entre ellas una comunicación virtual en la capa de sesión. Lo cual es del
todo lógico, ya que ésta es la capa que controla la comunicación entre ambas
computadoras por el entorno físico de la red (ya sean cables coaxiales, de par
trenzado o de fibra óptica).
La capa de sesión
La capa de sesión es la encargada de establecer el enlace de comunicación o sesión
entre las computadoras emisora y receptora. Esta capa también gestiona la sesión que se
establece entre ambos nodos (véase la Figura 2.3).
La estación de trabajo envía

una petición de servicio al servidor
El servidor accede a la petición
Estación de trabajo
Servidor
Comunicaciones en
la capa de sesión
FIGURA 2.3
La capa de sesión proporciona el enlace de comunicación entre dos computadoras que
se están comunicando.
Una vez establecida la sesión entre los nodos participantes, la capa de sesión pasa a
encargarse de ubicar puntos de control en la secuencia de datos. De esta forma, se pro-
porciona cierta tolerancia a fallos dentro de la sesión de comunicación. Si una sesión falla
y se pierde la comunicación entre los nodos, cuando después se restablezca la sesión sólo
tendrán que volver a enviarse los datos situados detrás del último punto de control recibi-
do. Así se evita el tener que enviar de nuevo todos los paquetes que incluía la sesión.
Los protocolos que operan en la capa de sesión pueden proporcionar dos tipos distin-
tos de enfoques para que los datos vayan del emisor al receptor: la comunicación orienta-
da a la conexión y la comunicación sin conexión.
37
PARA COMUNICARSE, LOS USUARIOS TIENE QUE EJECUTAR EL MISMO

CONJUNTO DE PROTOCOLOS
En el ejemplo anterior del envío y recepción de un mensaje de correo electrónico,

dimos por sentado que tanto el remitente como el destinatario estaban ejecutan-
do la misma pila de protocolos (la pila teórica OSI) en sus computadoras clientes.
De hecho, las computadoras que ejecuten sistemas operativos distintos pueden
comunicarse entre sí si utilizan el mismo conjunto de protocolos de red. Esto es lo
que explica que una máquina UNIX, un Macintosh o un PC que esté ejecutando
Windows utilicen el TCP/IP para comunicarse en Internet. Un ejemplo en el que
dos computadoras no podrían comunicarse sería aquél en que una computadora
ejecutara TCP/IP y la otra IPX/SPX. Estos dos protocolos de red del mundo real uti-
lizan reglas distintas y formatos de datos diferentes que hacen que la comunica-
ción resulte imposible.
Los protocolos orientados a la conexión que operan en la capa de sesión proporcionan

un entorno donde las computadoras conectadas se ponen de acuerdo sobre los parámetros
relativos a la creación de los puntos de control en los datos, mantienen un diálogo duran-
te la transferencia de los mismos, y después terminan de forma simultánea la sesión de
transferencia.
Los protocolos orientados a la conexión operan de forma parecida a una llamada tele-
fónica: en este caso, la sesión se establece llamando a la persona con la que se desea
hablar. La persona que llama y la que se encuentra al otro lado del teléfono mantienen una
conexión directa. Y, cuando la conversación termina, ambos se ponen de acuerdo para dar
por terminada la sesión y cuelgan el teléfono a la par.
El funcionamiento de los protocolos sin conexión se parece más bien a un sistema de
correo regular. Proporciona las direcciones pertinentes para el envío de los paquetes y
éstos pasan a enviarse como si se echaran a un buzón de correos. Se supone que la direc-
ción que incluyen permitirá que los paquetes lleguen a su destino, sin necesidad de un
permiso previo de la computadora que va a recibirlos.
La capa de transporte
La capa de transporte es la encargada de controlar el flujo de datos entre los nodos que
establecen una comunicación; los datos no sólo deben entregarse sin errores, sino además
en la secuencia que proceda. La capa de transporte se ocupa también de evaluar el tama-
ño de los paquetes con el fin de que éstos tengan el tamaño requerido por las capas infe-
riores del conjunto de protocolos. El tamaño de los paquetes lo dicta la arquitectura de red
que se utilice.
VÉASE TAMBIÉN
➤ Para más información sobre arquitecturas de red, como Ethernet y Token Ring, consulte el Capítulo 1.
LOS SERVICIOS DE LA CAPA DE APLICACIÓN PERMITEN QUE LAS APLICACIONES

DE USUARIO PUEDAN TRABAJAR EN RED
Cuando un usuario que está trabajando en una determinada aplicación (por ejem-
plo, en Excel) decide guardar un archivo de hoja de cálculo en el directorio que tie-
ne asignado dentro del servidor de archivos de red, la capa de aplicación del
modelo OSI proporciona el servicio que permite mover dicho archivo desde la
computadora cliente hasta el volumen de red pertinente. Esta transmisión es
totalmente transparente para el usuario.
La comunicación también se establece entre computadoras del mismo nivel (el emisor
y el receptor); la aceptación por parte del nodo receptor se recibe cuando el nodo emisor
ha enviado el número acordado de paquetes. Por ejemplo, el nodo emisor puede enviar de
un solo golpe tres paquetes al nodo receptor y después recibir la aceptación por parte del
nodo receptor. El emisor puede entonces volver a enviar otros tres paquetes de datos de
una sola vez.
Esta comunicación en la capa de transporte resulta muy útil cuando la computadora
emisora manda demasiados datos a la computadora receptora. En este caso, el nodo
receptor tomará todos los datos que pueda aceptar de una sola vez y pasará a enviar una
señal de “ocupado” si se envían más datos. Una vez que la computadora receptora haya
procesado los datos y esté lista para recibir más paquetes, enviará a la computadora emi-
sora un mensaje de “luz verde” para que envíe los restantes.
CADA CAPA EJECUTA FUNCIONES DE ENTRADA Y SALIDA DE DATOS
No debe olvidarse que cada capa del modelo OSI (o de un conjunto real de pro-
tocolos de red, como IPX/SPX o TCP/IP) ejecutan funciones relativas a la entrada
y salida de información. Cuando los datos bajan por la pila de protocolos en una
computadora emisora, la capa de presentación convierte la información proce-
dente de una determinada aplicación a un formato más genérico. En la computa-
dora receptora, la capa de presentación se ocupará de tomar dicha información
genérica y de convertirla al formato que utilice el programa que se esté ejecutan-
do en la capa de aplicación de la computadora receptora.
La capa de red
La capa de red encamina los paquetes además de ocuparse de entregarlos. La deter-
minación de la ruta que deben seguir los datos se produce en esta capa, lo mismo que el
intercambio efectivo de los mismos dentro de dicha ruta. La Capa 3 es donde las direc-
ciones lógicas (como las direcciones IP de una computadora de red) pasan a convertirse
en direcciones físicas (las direcciones de hardware de la NIC, la Tarjeta de Interfaz para
Red, para esa computadora específica).
39
Los routers operan precisamente en la capa de red y utilizan los protocolos de enca-
minamiento de la Capa 3 para determinar la ruta que deben seguir los paquetes de datos.
El modo en que se determinan los routers y la forma en que éstos convierten las direc-
ciones lógicas en direcciones físicas son temas sobre los que profundizaremos a lo largo
de este libro.
VÉASE TAMBIÉN
➤ Encontrará una explicación más pormenorizada de la capa de red en los siguientes capítulos. Para
obtener una rápida introducción sobre el modo en que operan los routers en la capa de red, consulte
el Capítulo 5.
La capa de enlace de datos

Cuando los paquetes de datos llegan a la capa de enlace de datos, éstos pasan a ubi-
carse en tramas (unidades de datos), que vienen definidas por la arquitectura de red que
se está utilizando (como Ethernet, Token Ring, etc.). La capa de enlace de datos se encar-
ga de desplazar los datos por el enlace físico de comunicación hasta el nodo receptor, e
identifica cada computadora incluida en la red de acuerdo con su dirección de hardware,
que viene codificada en la NIC. La Figura 2.4 muestra la dirección de hardware asignada
a la tarjeta de interfaz para red en una computadora que ejecuta Windows 98.
FIGURA 2.4
Cada nodo de la red sólo tiene asignada una única dirección física.
LOS PROTOCOLOS REALES UTILIZAN AMBOS MÉTODOS DE COMUNICACIÓN:

SIN CONEXIÓN Y ORIENTADOS A LA CONEXIÓN
En los conjuntos de protocolos de red, como TCP/IP e IPX/SPX, se utilizan ambas
estrategias de comunicación, la que precisa de una conexión y la que no, para des-
plazar los datos por la red. Por lo general, en la capa de sesión opera más de un
protocolo para gestionar estas estrategias distintas de comunicación.
La información de encabezamiento se añade a cada trama que contenga las direccio-

nes de envío y recepción. La capa de enlace de datos también se asegura de que las tra-
mas enviadas por el enlace físico se reciben sin error alguno. Por ello, los protocolos que
operan en esta capa adjuntarán un Chequeo de Redundancia Cíclica (Cyclical Redun-
dancy Check o CRC) al final de cada trama. El CRC es básicamente un valor que se cal-
cula tanto en la computadora emisora como en la receptora. Si los dos valores CRC coin-
ciden, significa que la trama se recibió correcta e íntegramente, y no sufrió error alguno
durante su transferencia.
Una vez más, y tal y como dijimos anteriormente, el tipo de trama que genera la capa
de enlace de datos dependerá de la arquitectura de red que se esté utilizando, como Ether-
net, Token Ring de IBM o FDDI. La Figura 2.5 muestra una trama Ethernet 802.2 y la
Tabla 2.1 describe cada uno de sus componentes. Aunque es posible que ahora no com-
prenda todas las partes que integra la trama representada, ésta se compone básicamente de
un encabezado que la describe, de los datos que incluye, y de la información referente a
la capa de enlace de datos (como los Puntos de Acceso al Servicio de Destino, Destina-
tion Service Access Points, y Puntos de Acceso al Servicio, Service Access Points), que
no sólo definen el tipo de trama de que se trata (en este caso, Ethernet), sino que también
contribuyen a que la trama llegue a la computadora receptora. (Para más información
acerca de las especificaciones IEEE 802, consulte la nota titulada “Tramas Ethernet”.)
CAMPOS LLC
Preámbulo Destino Fuente Longitud DSAP SSAP CTRL Datos FCS
FIGURA 2.5
La trama Ethernet se crea en la capa de enlace de datos del modelo OSI.
Tabla 2.1
Segmentos de la trama Ethernet.

Segmento Función
Preámbulo Bits de alternación (1 y 0) que indican que se ha enviado una trama.
Destino La dirección de destino.
Fuente La dirección de origen.
41
Tabla 2.1 (continuación)

Segmentos de la trama Ethernet.
Segmento Función
Longitud Especifica el número de bytes de datos incluidos en la trama.
DSAP Destination Service Access Point o Punto de Acceso al Servicio de Destino: indica
a la tarjeta de red de la computadora receptora dónde tiene que ubicar la trama den-
tro de la memoria intermedia.
SSAP Proporciona la información de Punto de Acceso al Servicio (Service Access Point)
para la trama (los Puntos de Acceso al Servicio se tratan en más detalle en el apar-
tado “Las subcapas del enlace de datos” incluido en este mismo capítulo).
CTRL Un campo del Control Lógico del Enlace. (El enlace lógico se explica en más detalle
en el apartado “Las subcapas del enlace de datos” incluido en este mismo capítulo.)
Datos Este segmento de la trama mantiene los datos que se han enviado.
FCS El campo de Secuencia de Comprobación de la Trama (Frame Check Sequence)
contiene el valor CRC para la trama.
La capa de enlace de datos también controla la forma en que las computadoras acce-
den a las conexiones físicas de la red. Nos detendremos en este aspecto de la Capa 2 en el
apartado “Las subcapas del enlace de datos” incluido en este mismo capítulo.
La capa física
En la capa física las tramas procedentes de la capa de enlace de datos se convierten en
una secuencia única de bits que puede transmitirse por el entorno físico de la red. La capa
física también determina los aspectos físicos sobre la forma en que el cableado está engan-
chado a la NIC de la computadora. En la computadora receptora de datos, la capa física es
la encargada de recibir la secuencia única de bits (es decir, información formada por 1 y 0).
LOCALIZAR DIRECCIONES MAC EN COMPUTADORAS WINDOWS

Para encontrar la dirección de una tarjeta de red que se ejecute en Windows
95/98, haga clic en el menú Inicio y después en Ejecutar. En el cuadro de diálogo
Ejecutar, escriba winipcfg y después haga clic en Aceptar. Aparecerá el cuadro de
diálogo Configuración IP donde se encuentra la dirección de la tarjeta de red. En
una computadora Windows NT, haga clic con el botón derecho del ratón en el ico-
no Entorno de red y después seleccione la ficha Adaptadores en el cuadro de diá-
logo Red. Seleccione el adaptador de red que utilice y después haga clic en el
botón Propiedades. Debería aparecer la dirección MAC de la NIC.
VÉASE TAMBIÉN
➤ Para más información acerca del entorno físico que actualmente se utiliza para conectar sistemas, con-
sulte el apartado “Cableado de la red” del Capítulo 1.
Las subcapas del enlace de datos

Antes de dar por finalizada nuestra explicación del modelo de red OSI, es preciso
que volvamos atrás y comentemos con más detalle algunas especificaciones desarrolla-
das por el IEEE para la capa de enlace de datos del modelo OSI. La especificación
IEEE 802 dividía la capa de enlace de datos en dos subcapas, el Control Lógico del
Enlace (Logical Link Control o LLC) y el Control de Acceso al Medio (Media Access
Control o MAC).
La subcapa de Control Lógico del Enlace establece y mantiene el enlace entre las
computadoras emisora y receptora cuando los datos se desplazan por el entorno físico de
la red. La subcapa LLC también proporciona Puntos de Acceso al Servicio (Service
Access Points o SAP), que no son más que puntos de referencia a los que otras computa-
doras que envíen información pueden referirse y utilizar para comunicarse con las capas
superiores del conjunto de protocolos OSI dentro de un determinado nodo receptor. La
especificación IEEE que define la capa LLC es la 802.2 (consulte la nota sobre las espe-
cificaciones IEEE 802.2 para más información acerca de otras categorías).
La subcapa de Control de Acceso al Medio determina la forma en que las computado-
ras se comunican dentro de la red, y cómo y dónde una computadora puede acceder, de
hecho, al entorno físico de la red y enviar datos. La especificación 802 divide a su vez la
subcapa MAC en una serie de categorías (que no son más que formas de acceder al entor-
no físico de la red), directamente relacionadas con la arquitectura específica de la red,
como Ethernet y Token Ring (véase la Figura 2.6).
VÉASE TAMBIÉN
➤ Para más información acerca de las arquitecturas de red más utilizadas hoy en día, consulte el apartado
“Comprender las arquitecturas de red” del Capítulo 1.
Subcapa LLC
IEEE 802.2
Capa de enlace de datos
Subcapa MAC
IEEE 802.3
IEEE 802.3
IEEE 802.5
IEEE 802.12
FIGURA 2.6
La capa de enlace de datos está compuesta por dos subcapas: la subcapa LLC y la subca-
pa MAC.
43
Protocolos de red del mundo real

Después de repasar el modelo teórico que determina la forma en que los datos van de
una computadora a otra dentro de una red, pasando por las distintas capas que conforman
el modelo OSI, podemos pasar a explicar algunos de los conjuntos de protocolos de red
más utilizados hoy en día y cotejar las capas que los integran con las del modelo OSI. De
esta forma, lograremos una visión clara y sencilla del modo en que operan estas pilas de
protocolos reales y de la forma en que transportan los datos por la red.
También veremos qué protocolos de un determinado conjunto participan en la capa de
red del modelo OSI. Estos protocolos son de suma importancia ya que contribuyen a
encaminar los paquetes en una conexión entre redes (algo sobre lo que versa gran parte de
este libro).
NetBEUI
NetBEUI (NetBIOS Extended User Interface o Interfaz Ampliada de Usuario para
NetBIOS) es un protocolo de red rápido y sencillo que fue diseñado para ser utilizado jun-
to con el protocolo NetBIOS (Network Basic Input Output System o Sistema Básico de
Entrada/Salida para Red) desarrollado por Microsoft e IBM para redes pequeñas. Net-
BEUI opera en las capas de transporte y red del modelo OSI.
Puesto que NetBEUI sólo proporciona los servicios que se requieren en las capas de
transporte y red de OSI, necesita funcionar con NetBIOS, que opera en la capa de sesión
del modelo OSI, y se encarga de establecer la sesión de comunicación entre las dos com-
putadoras conectadas a la red. Las redes Microsoft incluyen además otros dos compo-
nentes: el redirector y el Bloque de Mensajes del Servidor (Server Message Block). El
redirector opera en la capa de aplicación y hace que una computadora cliente perciba
todos los recursos de la red como si fueran locales. El Bloque de Mensajes del Servidor
(Server Message Block o SMB), por su parte, proporciona comunicación de mismo nivel
entre los redirectores incluidos en las máquinas cliente y servidor de la red. El Bloque de
Mensajes del Servidor opera en la capa de presentación del modelo OSI.
UN APUNTE SOBRE DIRECCIONES DE HARDWARE

Las direcciones NIC de hardware también se denominan direcciones MAC. Esta
sigla procede de la expresión inglesa Media Access Control o Control de Acceso al
Medio, y es una de las subcapas de la capa de enlace de datos. Las direcciones de
hardware están grabadas en los chips de la memoria ROM en las tarjetas de inter-
faz para red y cada una de ellas proporciona una dirección única. El esquema de
direccionamiento lo desarrolló en su día el Instituto de Ingenieros Eléctricos y
Electrónicos (IEEE). De acuerdo con este esquema, cada dirección reviste la forma
de una cadena de 48 bits escrita en formato hexadecimal. Un ejemplo de direc-
ción MAC sería 00-00-B3-83-B3-3F.
Aunque resulta un excelente protocolo de transporte de bajo coste, NetBEUI no es un

protocolo que pueda encaminarse por medio de routers, por lo que no puede utilizarse en
las interconexiones de redes. Por tanto, si bien NetBEUI es una opción de protocolo de
red para redes pequeñas y sencillas, no resulta válida para redes más amplias que requie-
ren el uso de routers (por lo que dejará de tratarse en este libro).
TRAMAS ETHERNET
La trama Ethernet que utilizaban las primeras versiones de NetWare de Novell
(NetWare 2.x y 3.x) se creó antes de que el IEEE completara sus especificaciones.
Esto hace que el tipo de trama Ethernet 802.3 no se ajuste estrictamente a las nor-
mas que ha dictado el IEEE. Las versiones más recientes de NetWare y de otros sis-
temas operativos de red utilizan la trama Ethernet 802.2, que cumple con todos
los requisitos especificados por el IEEE (y que se refieren más adelante en este
mismo capítulo).
TCP/IP
A menudo referido como el “protocolo de baja puja” (véase la nota titulada “Orígenes
de TCP/IP”), TCP/IP se ha convertido en el estándar de-facto para la conexión en red cor-
porativa. Las redes TCP/IP son ampliamente escalables, por lo que TCP/IP puede utili-
zarse tanto para redes pequeñas como grandes.
TCP/IP es un conjunto de protocolos encaminados que puede ejecutarse en distintas
plataformas de software (Windows, UNIX, etc.) y casi todos los sistemas operativos de red
lo soportan como protocolo de red predeterminado. TCP/IP consta de una serie de proto-
colos “miembro” que componen de hecho la pila TCP/IP. Y puesto que el conjunto de pro-
tocolos TCP/IP se desarrolló antes de que terminara de desarrollarse el modelo de referen-
cia OSI, los protocolos que lo conforman no se corresponden perfectamente con las
distintas capas del modelo. La Figura 2.7 muestra la correlación entre el conjunto de pro-
tocolos TCP/IP y las capas OSI (la figura ofrece una descripción general de TCP/IP y no
una imagen fiel y exhaustiva de todos los protocolos que incluye). La Tabla 2.2 describe
los protocolos que aparecen en la figura. En el Capítulo 10, “Conceptos fundamentales de
TCP/IP”, se ofrece más información acerca de los protocolos que integran la pila TCP/IP.
Tabla 2.2
Protocolos miembro de la pila TCP/IP.

Protocolo Función
FTP El File Transfer Protocol o Protocolo de Transferencia de Archivos proporciona
una interfaz y servicios para la transferencia de archivos en la red.
SMTP El Simple Mail Transport Protocol o Protocolo Simple de Transferencia de Correo
proporciona servicios de correo electrónico en las redes Internet e IP.
45
Protocolos miembro de la pila TCP/IP.

Protocolo Función
TCP El Transport Control Protocol o Protocolo de Control de Transporte es un proto-
colo de transporte orientado a la conexión. TCP gestiona la conexión entre las
computadoras emisora y receptora de forma parecida al desarrollo de las llamadas
telefónicas.
UDP El User Datagram Protocol o Protocolo de Datagrama de Usuario es un protoco-
lo de transporte sin conexión que proporciona servicios en colaboración con TCP.
IP El Internet Protocol o Protocolo Internet es la base para todo el direccionamiento
que se produce en las redes TCP/IP y proporciona un protocolo orientado a la capa
de red sin conexión. Funciona de forma semejante a una carta con remite echada
al buzón y después entregada a su destinatario.
ARP El Address Resolution Protocol o Protocolo de Resolución de Direcciones hace
corresponder las direcciones IP con las direcciones MAC de hardware. ARP se
explica en más detalle en el Capítulo 10.
Aplicación
Los protocolos
miembro de la
pila de protocolos
Presentación TCP/IP, como
FTP FTP, se solapan SMTP
con más de una
capa del
Sesión modelo OSI.
Transporte TCP UDP
Otros protocolos,
Red IP como TCP o IP,
ARP se corresponden
directamente con
una de las capas
Enlace de datos Controladores de tarjetas de red del modelo OSI.
Física
Entorno físico de la red (cables, hubs, etc.)
FIGURA 2.7
TCP/IP es un amplio conjunto de protocolos que utiliza una serie de protocolos miembro
en varias de las capas del modelo OSI.
ESPECIFICACIONES 802 DEL IEEE

Las especificaciones IEEE 802 proporcionan categorías que definen la Capa del
Enlace Lógico así como las distintas arquitecturas de red que puede utilizar la sub-
capa MAC. A continuación se incluye el listado completo de las categorías 802:
• -802.1 Conexión entre redes.
• -802.2 Control del Enlace Lógico.
• -802.3 LAN Ethernet (CSMA/CD).
• -802.4 LAN Token Bus.
• -802.5 LAN Token Ring.
• -802.6 Red de Área Metropolitana.
• -802.7 Grupo Técnico Asesor sobre Banda Ancha.
• -802.8 Grupo Técnico Asesor sobre Fibra Óptica.
• -802.9 Redes Integradas de Voz y Datos.
• -802.10 Seguridad de Red.
• -802.11 Redes Inalámbricas.
• -802.12 LAN de Demanda de Prioridad.
TCP/IP no sólo proporciona un amplio conjunto de características referidas a la cone-

xión en red (lo cual significa que TCP/IP requiere de una gran carga general para ejecu-
tarse) sino también un sistema de direccionamiento lógico y único. Cualquier usuario que
se conecte a Internet estará familiarizado con las direcciones IP de 32 bits, que normal-
mente se escriben en 4 octetos (un octeto equivale a 8 bits de información). El formato de
una dirección es del tipo 129.30.20.4, donde cada uno de los cuatro valores decimales
separados por un punto representa 8 bits de información binaria. Las direcciones IP se
explican en más detalle en el Capítulo 10.
Dada la importancia de TCP/IP en las conexiones entre redes y la complejidad que
entraña encaminar redes TCP/IP, hemos consagrado un capítulo entero a explicar y repa-
sar todos los aspectos del direccionamiento TCP/IP. De igual forma, los comandos referi-
dos al encaminamiento TCP/IP en redes de campus y corporativas que también se inclu-
yen en dicho capítulo ofrecen amplia información al respecto.
VÉASE TAMBIÉN
➤ Para obtener una idea global sobre TCP/IP y el encaminamiento de datos, consulte el Capítulo 10, “Con-
ceptos fundamentales de TCP/IP”.
IPX/SPX
IPX/SPX (Internetwork Packet Exchange/Sequenced Packet Exchange o Intercambio
de Paquetes entre Redes/Intercambio Secuenciado de Paquetes) es un conjunto de proto-
colos de red desarrollado por Novell para ser utilizado en su sistema operativo de red Net-
Ware. IPX/SPX agrupa menos protocolos que TCP/IP, por lo que no requiere la misma
47
carga general que TCP/IP necesita. IPX/SPX puede utilizarse tanto en redes pequeñas
como grandes y también permite el encaminamiento de datos.
La Figura 2.8 ofrece una correlación entre la pila IPX/SPX y las capas del modelo
OSI. La Tabla 2.3 describe brevemente cada uno de los protocolos que lo componen.
Los protocolos
Aplicación
SAP y NCP del
conjunto IPX/SPX
gestionan, de hecho,
SAP NCP las tareas de tres
Presentación capas OSI:
aplicación,
presentación
y sesión.
Sesión
IPX es un protocolo sin

Transporte conexión y opera en las
SPX capas de transporte
y red. SPX, que es un
IPX protocolo orientado a
la conexión, opera en
Red la capa de transporte.
Enlace de datos Controladores de interfaz para red
Física Entorno físico
FIGURA 2.8
IPX/SPX es un conjunto de protocolos eficaz que se utiliza tanto en redes grandes como
pequeñas.
ORÍGENES DE TCP/IP
TCP/IP lo desarrolló la Agencia de Defensa de Proyectos Avanzados de Investiga-
ción (DARPA) a petición del Departamento de Defensa de Estados Unidos. Dicho
departamento necesitaba un conjunto de protocolos que pudieran utilizarse en
cualquier sistema operativo, ya que no existía uniformidad alguna entre los siste-
mas informáticos de sus oficinas. Y ello por la forma misma en que funcionaba el
Departamento, que licitaba todos sus proyectos y servicios. De ahí que de forma
coloquial se conozca TCP/IP como protocolo de baja puja, ya que surgió a raíz de
la práctica del gobierno estadounidense por pujar.
Tabla 2.3
Protocolos miembro de la pila IPX/SPX.

Protocolo Función
SAP El Service Advertising Protocol o Protocolo de Anuncio de Servicio lo utilizan los
servidores de archivo y los servidores de impresora de NetWare para anunciar la
dirección del servidor.
NCP El NetWare Core Protocol o Protocolo de Núcleo NetWare gestiona las funciones
de red en las capas de aplicación, presentación y sesión. Gestiona además la crea-
ción de paquetes y se encarga de proporcionar servicios de conexión entre los clien-
tes y servidores.
SPX El Sequenced Packet Exchange Protocol o Protocolo de Intercambio Secuenciado
de Paquetes es un protocolo de transporte orientado a la conexión.
IPX El Internetwork Packet Exchange Protocol o Protocolo de Intercambio de Paquetes
entre Redes es un protocolo de transporte sin conexión que gestiona el direcciona-
miento y encaminamiento de los datos en la red.
Lo que más nos interesa acerca de IPX/SPX es la forma en que debe encaminarse este
conjunto de protocolos dentro de una conexión entre redes. Veremos el encaminamiento de
IPX/SPX y el modo en que transmite los datos dentro de una red en próximos capítulos.
UN COMENTARIO ACERCA DE LAS FIGURAS

Las Figuras 2.7, 2.8 y 2.9 presentan correlaciones entre protocolos reales y el mode-
lo OSI. Para entender estas figuras, debe tenerse en cuenta la forma en que las sie-
te capas de OSI convierten y transmiten datos entre dos computadoras conectadas
en red. Los conjuntos de protocolos del mundo real, como TCP/IP, ejecutan tam-
bién todas las tareas que describe el modelo teórico, pero utilizando menos proto-
colos que el modelo OSI. En vez de tener siete protocolos (uno para cada capa del
modelo OSI), TCP/IP incorpora varios protocolos que gestionan a un tiempo las
tareas de varias capas OSI. Por ejemplo, FTP gestiona las tareas de las capas OSI de
aplicación, presentación y sesión. De ahí que en la Figura 2.7, el círculo de FTP
englobe las tres capas del modelo OSI (que se muestran enmarcadas).
VÉASE TAMBIÉN
➤ El encaminamiento de IPX/SPX se explica en detalle en el Capítulo 12, “Encaminar IPX de Novell”.
AppleTalk
Aunque muchos administradores de red no consideran AppleTalk un protocolo de red
corporativo o de interconexión, AppleTalk permite el encaminamiento de datos mediante
49
routers. De hecho, con el tipo apropiado de NIC (los Macintosh de Apple pueden conec-
tarse a una red Ethernet si cuentan con tarjetas EtherTalk u otro tipo de adaptadores)
AppleTalk puede soportar arquitecturas Ethernet, Token Ring y FDDI. Las computadoras
Macintosh suelen utilizarse en los entornos empresariales para la manipulación de gráfi-
cos y otras tareas de tipo multimedia, por lo que no resulta nada descabellado incluir
AppleTalk como otro protocolo encaminado en la red corporativa.
En el Capítulo 1 hablábamos de AppleTalk como arquitectura de red, pero lo cierto es
que también se trata de un conjunto de protocolos. La Figura 2.9 ofrece la correlación
entre los protocolos que integra AppleTalk y las capas del modelo OSI. La Tabla 2.4 des-
cribe brevemente cada uno de estos protocolos.
TERMINOLOGÍA EQUÍVOCA
Antes de proseguir, convendría que repasáramos las definiciones de algunos tér-
minos que se repetirán con frecuencia a lo largo del libro.
Conexión entre redes: una red de redes. Se trata de redes de área local conecta-
das entre sí por medio de dispositivos de conexión entre redes, como un puente
o un router. La conexión entre redes se explica en detalle en el Capítulo 4, “Fun-
damentos básicos de la conexión entre redes”.
Internet: la Red de redes por antonomasia. TCP/IP es el estándar de-facto para el
conjunto internacional de computadoras heterogéneas que lo conforman.
Intranet: una red corporativa interna que sólo funciona en el entorno de la
empresa (sin conexión a Internet) pero que utiliza protocolos de Internet, como el
Protocolo Simple de Transporte de Correo (SMTP) y el Protocolo de Transporte de
Hipertexto (HTP), el mismo protocolo que utilizan los navegadores web. Una
extranet es una intranet que proporciona acceso a la red corporativa a determina-
dos empleados que se encuentran fuera de la compañía.
Tabla 2.4
Protocolos miembro de AppleTalk.
Protocolo Función
AppleShare AppleShare proporciona servicios en la capa de aplicación.
AFP El AppleTalk Filing Protocol o Protocolo de Archivo AppleTalk proporciona y
gestiona la compartición de archivos entre nodos de una red.
ATP El AppleTalk Transaction Protocol o Protocolo de Transacción AppleTalk pro-
porciona la conexión de capa de transporte entre computadoras.
NBP El Name Binding Protocol o Protocolo de Enlace de Nombre hace corresponder
los nombres de servidores de red con las direcciones de la capa de red.
ZIP El Zone Information Protocol o Protocolo de Información de Zona controla las
zonas AppleTalk y hace corresponder los nombres de zonas con las direcciones
de red.

Protocolos miembro de AppleTalk.
Protocolo Función
AARP El AppleTalk Address Resolution Protocol o Protocolo de Resolución de Direc-
ciones AppleTalk hace corresponder las direcciones de la capa de red con las
direcciones del hardware de enlace de datos.
DDP El Datagram Delivery Protocol o Protocolo de Entrega de Datagramas propor-
ciona el sistema de direccionamiento para la red AppleTalk, así como el trans-
porte sin conexión de los datagramas entre las distintas computadoras.
El conjunto de protocolos
AppleTalk se compone
AFP
Aplicación de varios protocolos, que
se corresponden con
algunas de las capas
AppleTalk del modelo OSI.
AppleTalk, por ejemplo,
Presentación se corresponde con las
capas de aplicación
y presentación de OSI.
Sesión
ZIP
Transporte
NBP
Red
AARP DDP
Enlace de datos Controladores de interfaz para red
Física Entorno físico
FIGURA 2.9
AppleTalk es un conjunto de protocolos encaminados para las redes Macintosh que pue-
den comunicarse con redes Ethernet, Token Ring y FDDI.
Al igual que con IPX/SPX, nuestro interés en el conjunto de protocolos de red Apple-
Talk se centrará en el modo en que AppleTalk encamina los datos por medio de routers.
La configuración de las redes AppleTalk y la forma en que este conjunto de protocolos
viene encaminado por un router de Cisco se tratarán en el Capítulo 13, “Encaminar
AppleTalk”.
51
¿DÓNDE ESTÁN LOS PROTOCOLOS DE ENCAMINAMIENTO?

Seguramente ya habrá reparado en que muchas de las figuras que muestran la
correlación entre conjuntos de protocolos y las capas del modelo OSI no incluían
protocolos de encaminamiento. Obviamente, cada conjunto de protocolos cuenta
con un protocolo de encaminamiento predeterminado; por ejemplo, RIP es el pro-
tocolo predeterminado de TCP/IP y el Protocolo de Mantenimiento de la Tabla es
el que utiliza por defecto AppleTalk. Estos protocolos se tratan en más detalle en
los capítulos sobre el encaminamiento de datos.
VÉASE TAMBIÉN
➤ Para más información acerca de la configuración de las redes AppleTalk y el modo en que se encaminan
en un router de Cisco, consulte el Capítulo 13.

Ing Sistemas 17 PDF

Caricato da

Informazioni sul documento

Titolo originale

Copyright

Formati disponibili

Condividi questo documento

Condividi o incorpora il documento

Opzioni di condivisione

Hai trovato utile questo documento?

Questo contenuto è inappropriato?

Copyright:

Formati disponibili

Ing Sistemas 17 PDF

Caricato da

Copyright:

Formati disponibili

TEMARIO

1.- NORMA TECNICA PERUANA NTP ISO/IEC 12207-2006. TECNOLOGIA DE LA

2.- NORMA TECNICA PERUANA NTP ISO/IEC 27001-2014. TECNOLOGIA DE LA

3.- GUIA TECNICA SOBRE EVALUACION DE SOFTWARE PARA LA ADMINSITRACION

4.- GESTION POR PROCESOS

5.- LENGUAJE DE MODELADO UNIFICADO UML

6.- PROGRAMACION ORIENTADA A OBJETOS

7.- DISEÑO DE BASE DE DATOS RELACIONAL

8.- SISTEMAS OPERATIVOS

TECNOLOGÍA DE LA INFORMACIÓN. Procesos del

R.0055-2006/INDECOPI-CRT. Publicada el 2006-07-28 Precio basado en 189 páginas

1. OBJETO Y CAMPO DE APLICACIÓN 1

5. PROCESOS PRINCIPALES DEL CICLO DE VIDA 16

6. PROCESOS DE APOYO DEL CICLO DE VIDA 50

7. PROCESOS ORGANIZATIVOS DEL CICLO DE VIDA 70

FIGURA 1 ESTRUCTURA DE LA NORMA TÉCNICA PERUANA 13

FIGURA B.1 EJEMPLO DE APLICACIÓN DE ESTA NTP 83

FIGURA C.1 PROCESOS DEL CICLO DE VIDA DEL SOFTWARE - 90

FIGURA C.2 PROCESOS DEL CICLO DE VIDA DEL SOFTWARE - 91

TABLA E.1 CORRELACIÓN DE ISO/IEC 12207:1995 AL ANEXO F 95

A.2 El Comité Técnico de Normalización de Ingeniería de Software y Sistemas

A.3 Esta Norma Técnica Peruana reemplaza a la NTP-ISO/IEC 12207:2004 y

B. INSTITUCIONES QUE PARTICIPARON EN LA ELABORACION

Secretaría Pontificia Universidad Católica del

Presidente Zalatiel Carranza Avalos

Secretario Abraham Eliseo Dávila Ramón

Secretaria a.i. Silvana Marianela Bernaola Biggio

Asociación de Bancos del Perú Iván Estrada Montano

ESSALUD Pedro Vásquez Campos

IBM del Perú S.A. Ricardo Haro

ONGEI César Vilchez Inga

Petróleos del Perú –PETRO PERU S.A. Ricardo Verri Morchio

QUIPUDATA S.A. (Corp. Backus) Wilfredo Kleeberg Hidalgo

Sociedad Nacional de industrias Ewen Juárez Jiménez

Southern Perú Boris Gilberto Sulca Solari

SUNAT Rosa Carrasco Aguado

Superintendencia de Banca, Seguros y Romel Alvarez Llanos

Universidad de Lima María Cecilia Moreno Moreno

Universidad Peruana de Ciencias Aplicadas Ludvik D. Medic Corrales

UNISYS del Perú Jaime Espinoza Castillo

INEXXO Eduardo García Pacheco

Universidad Femenina del Sagrado Corazón Juan Fernández Chavesta

El software es una parte esencial de sistemas convencionales y de tecnologías de la

TECNOLOGÍA DE LA INFORMACIÓN. Procesos del ciclo

1. OBJETO Y CAMPO DE APLICACIÓN

1.2 Campo de aplicación

Esta NTP es aplicable a la adquisición de sistemas, productos y servicios software, al

Este apartado no impide el uso de la NTP a los proveedores o desarrolladores de software

1.3 Adaptación de esta NTP

1.4.1 Conformidad a los Propósitos y Resultados

NOTA: En la ISO/IEC 12207:1995 se utiliza el término "cumplimiento" en el apartado 1.4; sin

Esta NTP no pretende establecer el nombre, el formato o el contenido explícito de la

2.1 Normas Técnicas Internacionales

2.1.1 ISO/IEC 2382 - 1:1993 Information technology – Vocabulary – Part 1:

2.1.2 ISO/IEC 2382 - 20:1990 Information technology – Vocabulary – Part

2.1.3 ISO/IEC 15504 – 2:2003 Software Engineering – Software process

2.1.4 ISO 13407:1999 Human-centred design processes for

2.1.5 ISO/IEC 15535:2003 General requirements for establishing

2.2 Normas Técnicas Peruanas

2.2.1 NTP-ISO 9000:2001 Sistema de gestión de la calidad.

2.2.2 NTP-ISO 9001:2001 Sistemas de gestión de calidad. requisitos

2.2.3 NTP-ISO 14001:2002 Sistemas de gestión ambiental.

2.2.4 NTP-ISO/IEC 9126 – 1: 2004 Ingeniería de software – Calidad de Producto