ingenieria de sistemas - obtencion.fap.mil.pe · a. reseÑa histÓrica a.1 la presente norma...

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

i

Í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

ii

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

iii

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

iv

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

NORMA TÉCNICA NTP-ISO/IEC 12207 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.


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


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.


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


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.


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.


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.


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


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.


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.


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.


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.


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.

7. PROCESOS ORGANIZATIVOS DEL CICLO DE VIDA

7.1 Gestión 7.2 Infraestructura

7.3 Mejora7.4 Recursos

Humanos

6. PROCESOS DE APOYODEL CICLO DE VIDA

6.1 Documentación

6.2 Gestión de la Configuración

6.3 Aseguramiento de la

Calidad

6.4 Verificación

6.5 Validación

6.6 Revisión Conjunta

6.7 Auditoría

6.8 Solución de Problemas

5. PROCESOS PRINCIPALES

DEL CICLO DE VIDA

5.1 Adquisición

5.2 Suministro

5.3

Desarrollo

5.4 Operación

5.5Mantenimiento

Figura 1 - Estructura de la normaFIGURA 1 – Estructura de la norma técnica peruana


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.


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.


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.


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.


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.


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.


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.


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.


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 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 a nivel de


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:


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.


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.


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.


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.


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


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


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.


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.


e) Viabilidad de la operación y mantenimiento. 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.


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.


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. f) Viabilidad de la operación y mantenimiento.

5.3.5.7 El desarrollador deberá llevar a cabo revisiones conjuntas de acuerdo con el 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


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.


f) Viabilidad de la operación y mantenimiento. 5.3.6.8 El desarrollador deberá llevar a cabo revisiones conjuntas de acuerdo con el 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.


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. 5.3.8.3 El desarrollador deberá actualizar la documentación de usuario, si es 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


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. 5.3.9.2 El desarrollador deberá actualizar la documentación de usuario, si es 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.


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.


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. e) Viabilidad de la operación y mantenimiento.

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.


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.


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 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 mejora de proceso (7.3) y el proceso de recursos 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:

a) Implementación del proceso. b) Pruebas de operación. c) Operación del sistema. d) Soporte al usuario.

5.4.1 Implementación del proceso: Esta actividad consta de las siguientes tareas:


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.


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). Lista de actividades. Este proceso consta de las siguientes actividades:


a) Implementación del proceso. 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:


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


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.


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


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.


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 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 a nivel de organización siguiendo el proceso de mejora de proceso (7.3) y el proceso de recursos 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


documentos que necesitan todos los involucrados tales como gerentes, ingenieros y usuarios del sistema o producto software. Lista de actividades. Este proceso consta de las siguientes actividades:

a) Implementación del proceso. 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


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


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.

Lista de actividades. Este proceso consta de las siguientes actividades:

a) Implementación del proceso. 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


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,


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). Lista de actividades. Este proceso consta de las siguientes actividades:

a) lmplementación del proceso.

b) Aseguramiento del producto.

c) Aseguramiento del proceso.

d) Aseguramiento del sistema de calidad. 6.3.1 Implementación del proceso: Esta actividad consta de las siguientes tareas: 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).


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:


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.


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. Lista de actividades. Este proceso consta de las siguientes actividades:

a) Implementación del proceso.

b) Verificación.

6.4.1 Implementación del proceso: Esta actividad consta de las siguientes tareas: 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:


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.


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:


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.


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


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. Lista de actividades. Este proceso consta de las siguientes actividades:

a) Implementación del proceso. b) Validación.

6.5.1 Implementación del proceso: Esta actividad consta de las siguientes tareas: 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.


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.


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). Lista de actividades. Este proceso consta de las siguientes actividades:


b) Revisiones de la gestión del proyecto.

c) Revisiones técnicas. 6.6.1 Implementación del proceso: Esta actividad consta de las siguientes tareas: 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.


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.


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). Lista de actividades. Este proceso consta de las siguientes actividades:

a) lmplementación del proceso. b) Auditoría.

6.7.1 Implementación del proceso: Esta actividad consta de las siguientes tareas: 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.


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.


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. Lista de actividades. Este proceso consta de las siguientes actividades:


b) Solución de problemas. 6.8.1 Implementación del proceso: Esta actividad consta de la siguiente tarea: 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


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. 7. PROCESOS ORGANIZATIVOS DEL CICLO DE VIDA 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.


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. Lista de actividades. Este proceso consta de las siguientes actividades:

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.


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.


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,


herramientas, técnicas, normas e instalaciones para el desarrollo, operación o mantenimiento. Lista de actividades. Este proceso consta de las siguientes actividades:

a) Implementación del proceso. b) Establecimiento de la infraestructura. c) Mantenimiento de la infraestructura.

7.2.1 Implementación del proceso: Esta actividad consta de las siguientes tareas: 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:


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. Lista de actividades. Este proceso consta de las siguientes actividades:

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.


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. Lista de actividades. Este proceso consta de las siguientes actividades:


a) lmplementación del proceso. b) Desarrollo del material de formación. c) lmplementación del plan de formación.

7.4.1 Implementación del proceso: Esta actividad consta de la siguiente tarea: 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


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. Lista de actividades. Este proceso consta de las siguientes actividades:

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 Esta actividad consta de la siguiente tarea:


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 Esta actividad consta de la siguiente tarea: A.4.1 Se deberán documentar todas las decisiones de adaptación, junto con las razones de las decisiones.


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.


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.


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.


FIGURA B.1 – Ejemplo de aplicación de esta NTP

ADAPTACIÓN DE LA

APLICACIÓN, PRUEBAS

DE EVALUACIÓN, ETC

NORMA ISO/IEC

DE PROCESOS

DEL CICLO DE

VIDA DEL

SOFTWARE

PLAN DEL

PROYECTO

PLAN DE LA

CALIDAD

CONTRATO

INICIO DEL PROYECTO

MNTOPDESSUADQ QUE

QUIÉN

ADQ

SU

DES

OP

MNT

PROCEDIMIENTOS

CAPACIDAD DE LA

ORGANIZACIÓN

MANUAL DE LA

CALIDAD

SEGURIDAD

FÍSICA

SEGURIDAD DE

ACCESO

NORMATIVA

LEGAL

REQUISITOS

TIEMPO

DINERO

ENTORNO

DE LA COMPAÑIA

ESPIRAL

CASCADA

M

E

T

O

D

O

S

OTRAS ENTRADAS

CREDENCIALES

(ISO 9001, ...)MATRIZ DE RESPONSABILIDAD

MODELOS Y MÉTODOS


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.


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


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.


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.


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


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.


FIGURA C.1. – Procesos del ciclo de vida del software – roles y relaciones

Procesos Organizativos

* Infraestructura *Mejora de Procesos *Recursos Humanos

•

•

•

Proceso de

Adquisición

Proceso de

Suministro

Proceso de Gestión

Proceso de

Operación

Proceso de Mantenimiento

Proceso de Desarrollo

• Adquiriente• Proveedor

• Gerente

• Operador

Usuario

• Desarrollador

• Responsable de mantenimiento

• Usuario de los procesos

de apoyo

emplea

emplea

VISIÓN CONTRACTUAL

VISIÓN GESTORA

VISIÓN OPERATIVA

VISIÓN DE LA

INGENIERÍA

PUNTO DE VISTA DEL APOYO

emplea

emplea

emplea

contrato

emplea emplea emplea

emplea

Procesos de Apoyo

• Documentación

• Gestión de la Configuración

• Solución de Problemas

• Aseguramiento de la Calidad

• Verificación

• Validación

• Revisión Conjunta

• Auditoría


FIGURA C.2 – Procesos del ciclo de vida del software - visiones y actividades

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

6.1 Proceso de

Documentación

6.7 Proceso de

Auditoría

6.6 Proceso de Revisión Conjunta

6.5 Proceso de

Validación

6.4 Proceso de

Verificación

6.3 Proceso de

Aseguramiento

de la Calidad

6.2 Gestión de la

Configuración

VISIÓN DE LA GESTIÓN

DE LA CALIDAD

6. PROCESOS DE APOYO DEL CICLO DE VIDA

5.1 Proceso de Adquisición

Contrato PlanificaciónInicioRevisión y

evaluación

Ejecución y

control

Suministro y

finalización

Preparación de la

respuesta

InicioPreparación de la

solicitud de propuestas

Preparación y actualización del

contrato

Seguimiento

del proveedorAceptación y

finalización

5.2 Proceso de Suministro

VISIÓN CONTRACTUAL

6.8 Proceso de Solución de

Problemas

5. PROCESOS PRINCIPALES DEL CICLO DE VIDA

Implementación

del proceso

Operación del

sistema

Pruebas de

operación

Soporte al

usuario

5.4 Proceso de Operación

VISIÓN OPERATIVAVISIÓN DE LA INGENIERÍA

5.5 Proceso de Mantenimiento

Implementación

del proceso

Analisis de

problemas y

moficaciones

Implementación

de las

modificaciones

Revisión /

aceptación del

mantenimient

o

Retirada del

softwareMigración

7. PROCESOS ORGANIZATIVOS DEL CICLO DE VIDA

7.2 Proceso de

Infraestructura

7.4 Proceso de Recursos

Humanos

Establecimiento

del proceso

Evaluación del

procesoMejora del

proceso

7.3 Proceso de Mejora de Procesos

VISIÓN GESTORA

Analisis de

los requisitos

del software

Diseño de la

arquitectura

del software

Integración

del

software

Instalación del

software

Apoyo a la

aceptación del

software

Analisis de los

requisitos del

sistema

Diseño de la

arquitectura

del sistema

Integración

del sistema

Pruebas de

calificación

del sistema

Implementación

del proceso

Pruebas de

calificación

del software

Codificación y

pruebas del

software

Diseño

detallado del

software

Inicio y definición

del alcance

Ejecución y

control

Planificación

Revisión y

evaluaciónTerminación

7.1 Proceso de Gestión

5.3 Proceso de Desarrollo


ANEXO D (INFORMATIVO)

BIBLIOGRAFIA NTP-ISO/IEC 12119:2005 - Tecnología de la Información. Paquetes software. Requerimientos de calidad y pruebas.


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.


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


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

Sistema básico

5.3.3 Diseño de la arquitectura del sistema ISO/IEC 12207 Diseño de la Arquitectura del Sistema

básico

5.3.4 Análisis de requisitos del software ISO/IEC 12207 Análisis de Requisitos del Software

básico

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

Configuración básico

6.3 Proceso de aseguramiento de la calidad ISO/IEC 12207 Proceso de Aseguramiento de Calidad

básico

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

problema básico

ISO 13407 Proceso de Usabilidad nuevo ISO/IEC 14598 Proceso de Evaluación de

producto extendido


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 de Reutilización

nuevo

7.7 IEEE 1517 Proceso de Ingeniería de Dominio

nuevo


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.


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.


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;


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;


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.


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.


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;


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.


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.


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.


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


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.


F.1.3.3 Diseño de la arquitectura del sistema Propósito: El propósito del diseño de la 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.


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.


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:


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;


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.


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.


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:


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.


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:


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;


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;


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.


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:


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.


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.


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;


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.


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.


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.


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.


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


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.


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:


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


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.


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.


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:


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.


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.


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.


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:


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.


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;


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.


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.


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


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.


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


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


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.


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.


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


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.


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


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:


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:


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.


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.


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. Lista de actividades: Este proceso consiste en las siguientes tareas:

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:


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;


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


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.


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;


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 .


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. Lista de actividades: Este proceso consiste en las siguientes tareas:

a) Implementación del proceso; b) Análisis del dominio; c) Diseño del dominio; d) Provisión del activo;


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;


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


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.


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


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.


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.


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


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:


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;


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.


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.


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.


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.


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: Como resultado de la implementación exitosa del proceso:

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.


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: Como resultado de la implementación exitosa del proceso:

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.


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: Como resultado de la implementación exitosa del proceso:

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.


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: Como resultado de la implementación exitosa del proceso:

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;


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.


Resultados: Como resultado de la implementación exitosa del proceso:

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: Como resultado de la implementación exitosa del proceso:

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;


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: Como resultado de la implementación exitosa del proceso:

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


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: Como resultado de la implementación exitosa del proceso:

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.


Resultados: Como resultado de la implementación exitosa del proceso:

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


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:


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;


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:


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.

NORMA TÉCNICA NTP-ISO/IEC 27001 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

i

Í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


ii

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


iii

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


iv

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;


v

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


vi

PartesInteresadas

PartesInteresadas

Requisito y expectativas de seguridad de información

Planear

Establecer el ISMS

HacerImplementar y Operar el

ISMS

Ciclo de desarrollo,

mantenimiento y mejora

Mantener y mejorar el

ISMSActuar

Monitorear y revisar el

ISMS

Verificar

Gestión de la Seguridad de la

Información

FIGURA 1 – Modelo PDCA aplicado al proceso ISMS

Planear (establecer el ISMS)

Establecer las políticas, objetivos, procesos y procedimientos 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 operar el ISMS)

Implementar y operar las políticas, controles, procesos y procedimientos de seguridad.

Verificar (monitorear y revisar el ISMS)

Monitorear y evaluar el funcionamiento de los procesos con 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 mejorar el ISMS)

Tomar acciones correctivas y preventivas basándose en los resultados de la revisión gerencial para alcanzar la mejora continua del ISMS.


vii

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



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 1.1 Aspectos generales 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.



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.



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]



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. [ISO/IEC Guide 73:2002] 3.11 análisis del riesgo: Uso sistemático de información para identificar amenazas y estimar el riesgo. [ISO/IEC Guide 73:2002] 3.12 estimación del riesgo: Proceso total de análisis y evaluación del riesgo. [ISO/IEC Guide 73:2002] 3.13 evaluación del riesgo: Proceso de comparación del riesgo estimado frente al criterio de riesgo para determinar el significado del riesgo. [ISO/IEC Guide 73:2002]



3.14 gestión del riesgo: Actividades coordinadas para dirigir y controlar el riesgo en una organización. [ISO/IEC Guide 73:2002] 3.15 tratamiento del riesgo: Proceso de selección e implementación de controles para minimizar el riesgo. [ISO/IEC Guide 73:2002] 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.



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.



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.



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.



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



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;



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.



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.



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.



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;



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.



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;



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 7.1 Aspectos generales 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).



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.



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;



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.



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



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

de seguridad de la información

Control 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 de seguridad de información

Control La política será revisada en intervalos planificados, y en caso de cambios que la afecten, asegurar que siga siendo apropiada, conveniente y efectiva.



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

seguridad de la información

Control La gerencia debe respaldar activamente la seguridad dentro de 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 seguridad de la información

Control 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 responsabilidades sobre seguridad de la información

Control Todas las responsabilidades sobre la seguridad de información deben ser claramente definidas.

A.6.1.4 Proceso de autorización para las nuevas instalaciones de procesamiento de información

Control Debe establecerse y definirse un proceso de gestión de autorización para facilitar los nuevos procesamientos información.

A.6.1.5 Acuerdos de confidencialidad

Control 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 autoridades

Control Se debe mantener contactos apropiados con las autorizaciones relevantes.

A.6.1.7 Contacto con grupos de interés especial

Control 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 independiente de seguridad de la información

Control El alcance de la organización para manejar la seguridad de información, así como su implementación (como por ejemplo: 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.



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

riesgos por el acceso de terceros

Control 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 seguridad cuando se trata con clientes

Control 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 seguridad en contratos con terceros

Control 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 activos

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



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 de la información

Control 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

responsabilidades Control 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 de la relación laboral

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



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

responsabilidades Control 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, educación y entrenamiento en la seguridad de información

Control Todos los empleados de la organización y, donde sea relevante, contratistas y usuarios externos deben recibir 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

finalización Control 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 de acceso

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



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

perimetral Control 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 entradas

Control 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, despachos y recursos

Control Se deben designar y mantener áreas seguras con el fin de proteger las oficinas, despachos e instalaciones.

A.9.1.4 Protección contra amenazas externas y ambientales

Control 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 seguras

Control Se debe designar y mantener protección física y pautas para trabajar en áreas seguras.

A.9.1.6 Áreas de carga, descarga y acceso público

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



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

de equipos Control 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 equipos

Control El equipamiento recibirá un adecuado mantenimiento para garantizar su continua disponibilidad e integridad.

A.9.2.5 Seguridad de equipos fuera de los locales de la organización

Control 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 o eliminación de equipos

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



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

procedimientos operativos

Control 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 instalaciones de desarrollo, prueba y operación

Control Se separarán las instalaciones de desarrollo, prueba y 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 los servicios externos

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



A.10.2.3 Gestión de cambios de los servicios externos

Control 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

software malicioso Control 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 software móvil

Control 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

información Control 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.



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 servicios de red

Control 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

removibles Control 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 manipulación de la información

Control 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 documentación de sistemas

Control La documentación de los sistemas se protegerá de accesos no autorizados.



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

procedimientos para el intercambio de información

Control Se deben establecer políticas, procedimientos y controles para proteger el intercambio de información durante el uso de todo tipo de recursos de comunicación.

A.10.8.2 Acuerdos de intercambio

Control 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 físicos en tránsito

Control 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 electrónico

Control La información contenida en correos electrónicos debe ser protegida apropiadamente.

A.10.8.5 Seguridad en los sistemas de información de negocio

Control Se deben desarrollar e implementar políticas y 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

electrónico Control 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 transacciones en línea

Control 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 disponible públicamente

Control Se protegerá la integridad de la información públicamente disponible para prevenir modificaciones no autorizadas.



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 monitoreo

Control 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 información de registro

Control Las instalaciones e información de registro debe ser protegido contra acceso forzado y no autorizado.

A.10.10.4 Registros de administrador y operador

Control 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 reloj

Control 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

accesos Control Se debe establecer, documentar y revisar una política de control de accesos, basado en requisitos de acceso de seguridad y del negocio.



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 de usuario

Control 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 de acceso de los usuarios

Control 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 usuario desatendido

Control Se exige al usuario que asegure protección adecuada a un equipo desatendido.

A.11.3.3 Política de pantalla y escritorio limpio

Control 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

servicios de la red Control Los usuarios deben tener acceso directo únicamente a los servicios cuyo uso está específicamente autorizado.

A.11.4.2 Autenticación de usuarios para conexiones externas

Control Deben usarse apropiados métodos de autenticación para controlar el acceso de usuarios remotos.



A.11.4.3 Autenticación de equipos en la red

Control 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 configuración de puertos y diagnóstico remoto

Control Debe controlarse la seguridad en el acceso lógico y físico para el diagnóstico y configuración de puertos.

A.11.4.5 Segregación en las redes

Control 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 las redes

Control 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 en la red

Control 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

de conexión Control 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 autenticación del usuario

Control Todos los usuarios tienen un identificador único para su 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 contraseñas

Control 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 utilitarios del sistema

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



A.11.5.5 Desconexión automática de terminales

Control Las sesiones inactivas deben cerrarse luego de un periodo definido de inactividad.

A.11.5.6 Limitación del tiempo de conexión

Control 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

la información Control 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 sensibles

Control 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

comunicaciones móviles Control 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

especificación de los requisitos de seguridad

Control Los requisitos de negocios para nuevos sistemas, o ampliaciones de los sistemas existentes, especificarán los requisitos de control.



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

de entrada Control 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 interno

Control 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 de salida

Control 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

controles criptográficos Control 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

producción Control 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 de prueba del sistema

Control Se protegerán y controlarán los datos de prueba los cuales deben ser seleccionados cuidadosamente.



A.12.4.3 Control de acceso a la librería de programas fuente

Control 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 de cambios Control 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 cambios en el sistema operativo

Control 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 cambios a los paquetes de software

Control 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 software

Control 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

vulnerabilidades técnicas

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



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

la seguridad de información

Control 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 de seguridad

Control 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

procedimientos Control. 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 incidentes en la seguridad de información

Control Deben existir mecanismos que habiliten que los tipos, volúmenes y costos de los incidentes en la seguridad de información sean cuantificados y monitoreados.

A.13.2.3 Recolección de evidencia

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



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

de la información en la gestión de la continuidad del negocio

Control Se deben de establecer procedimientos y 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 y evaluación de riesgos

Control 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 implementando planes de continuidad que incluyen la seguridad de la información

Control Se deben desarrollar e implementar planes para mantener o reparar operaciones y asegurar la disponibilidad de 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 de la continuidad del negocio

Control 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 y reevaluando los planes de continuidad del negocio

Control Los planes de continuidad del negocio deben ser probados y actualizados regularmente con el fin de asegurar que se encuentren actuales y que sean efectivos.



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

legislación aplicable Control 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 propiedad intelectual (DPI)

Control 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 registros de la organización

Control 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 datos y privacidad de la información personal

Control Se aplicarán controles para proteger información personal en conformidad con la legislación correspondiente y si es aplicable, con las cláusulas contractuales.

A.15.1.5 Prevención en el mal uso de las instalaciones de procesamiento de la información

Control Los usuarios deben ser disuadidos de utilizar las instalaciones del procesamiento de información para propósitos no autorizados.

A.15.1.6 Regulación de los controles criptográficos

Control Se implementarán controles para permitir el cumplimiento de los acuerdos nacionales, leyes y reglamentos.



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

estándares y la política de seguridad

Control 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 cumplimiento técnico

Control 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

auditoría de sistemas Control 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 herramientas de auditoría de sistemas

Control Se protegerá el acceso a las herramientas de auditoría del sistema para prevenir cualquier posible mal uso o daño.



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 Los participantes deben estar concientes de la necesidad de seguridad de los sistemas y redes de información y lo que pueden hacer para mejorar la seguridad.

Esta actividad es parte de la fase Hacer (véase 4.2.2 y 5.2.2).

Responsabilidad Todos los participantes son responsables por la seguridad de los sistemas y redes de información.

Esta actividad es parte de la fase Hacer (véase 4.2.2 y 5.1).

Respuesta Los participantes deben actuar de manera puntual y cooperativa para prevenir, detectar y responder a los incidentes de seguridad.

Esto es parte de la actividad de monitoreo de la fase Verificar (véase 4.2.3 y 6 a 7.3) y una actividad de respuesta de la fase Actuar (véase 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 Los participantes deben conducir evaluaciones del riesgo.

Esta actividad es parte de la fase Planear (véase 4.2.1) y evaluación de riesgo es parte de la fase Verificar (véase 4.2.3 y 6 a 7.3).



TABLA B.1 - Principios OECD y modelo PDCA (Fin)

Principio OECD Proceso ISMS y fase PDCA correspondiente

Diseño e implementación de seguridad Los participantes deben incorporar la

seguridad como un elemento esencial de

los sistemas y redes de información.

Una vez que se ha completado la evaluación del riesgo, se ha seleccionado controles para el tratamiento de riesgos como parte de la fase Planear (véase 4.2.1). La fase Hacer (véase 4.2.2 y 5.2) entonces cubre la implementación y uso operacional de estos controles.

Gestión de seguridad Los participantes deben adoptar un enfoque comprensivo de la gestión de seguridad.

La gestión del riesgo es un proceso que incluye la prevención, detección y respuesta 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 Los participantes deben revisar y reevaluar la seguridad de los sistemas y redes de información y hacer modificaciones adecuadas a las políticas, prácticas, medidas y procedimientos de seguridad

Reevaluación de la seguridad de la información es parte de la fase Verificación (véase 4.2.3 y 6 a 7.3) donde debe realizarse revisiones regulares para verificar la efectividad de los sistemas de gestión de 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)



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.1 Aspectos Generales 0.2 Enfoque de proceso 0.3 Compatibilidad con otros sistemas de gestión

0 Introducción 0.1 Aspectos Generales 0.1 Alcance del proceso 0.2 Relaciones con ISO 9004 0.3 Compatibilidad con otros sistemas de gestión

Introducción

1 Alcance 1.1 Aspectos Generales 1.2 Aplicación

1 Alcance 1.1 Aspectos Generales 1.2 Aplicaciones

1 Alcance

2 Referencias normativas



3 Términos y definiciones






4 Sistema de gestión de seguridad de la información 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 ISMS 4.2.3 Monitorear y revisar el ISMS 4.2.4 Mantener y mejorar el ISMS

4 Sistema de gestión de calidad 4.1 Requisitos generales 8.2.3 Monitoreo y medición de los procesos 8.2.4 Monitoreo y medición del producto

4 Requisitos del sistema de gestión ambiental 4.1 Requisitos generales 4.4 Implementación y operación 4.5.1 Monitoreo y medición

4.3 Requisitos de documentación 4.3.1 Aspectos Generales 4.3.2 Control de documentos 4.3.3 Control de registros

4.2 Requisitos de documentación 4.2.1 Aspectos Generales 4.2.2 Manual de calidad 4.2.3 Control de documentos 4.2.4 Control de registros

4.4.5 Control de la documentación 4.5.4 Control de registros

5 Responsabilidad de la gerencia 5.1 Compromiso de la gerencia

5 Responsabilidad de la gerencia 5.1 Compromiso de la gerencia 5.2 Enfoque de los clientes 5.3 Política de calidad 5.4 Planeamiento 5.5 Responsabilidad, autoridad y comunicación

4.2 Política ambiental 4.3 Planeamiento




5.2 Administración de recursos 5.2.1 Provisión de recursos 5.2.2 Capacitación, concientización y competencia

6 Gestión de recursos 6.1 Provisión de recursos 6.2 Recursos humanos 6.2.2 Competencia, concienti-zación y capacitación 6.3 Infraestructura 6.4 Ambiente de trabajo

4.4.2 Competencia, concientización y capacitación

6 Auditorías internas del ISMS

8.2.2 Auditoría interna

4.5.5 Auditoría interna

7 Revisión gerencial del ISMS 7.1 Aspectos Generales 7.2 Revisión: entradas 7.3 Revisión: salidas

5.6 Revisión gerencial 5.6.1 Aspectos Generales 5.6.2 Revisión: entradas 5.6.3 Revisión: salidas

4.6 Revisión gerencial

8 Mejora del ISMS 8.1 Mejora continua

8 Mejora 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 controles Anexo B Principios OECD y de esta Norma Anexo C Correspondencia entre la norma ISO 9001: 2000, ISO 14001:2004 y esta Norma

Anexo A Correspondencia entre la norma ISO 9001: 2000, ISO 14001:1996

Anexo A Pautas en el uso de esta norma Anexo B Correspondencia entre la norma ISO 14001: 2004, ISO 9001:2000



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



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

Presidencia del Consejo de Ministros – Gobierno del Perú – ONGEI

[email protected]

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”

Oficina Nacional de Gobierno Electrónico e Informática Presidencia del Consejo de Ministros

RESOLUCIÓN MINISTERIAL N073-2004-PCM

Guía Técnica sobre Evaluación

de SSooffttwwaarree eenn llaa

AAddmmiinniissttrraacciióónn PPúúbblliiccaa

Presidencia del Consejo de Ministros – Gobierno del Perú – ONGEI [email protected]

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” Fecha: 05/05/04

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

Presidencia del Consejo de Ministros – Gobierno del Perú – ONGEI [email protected]

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” Fecha: 05/05/04

CONTROL DE VERSIONES

FUENTE DE CAMBIO FECHA DE SOLICITU

D DEL CAMBIO

VERSIÓN PARTES QUE

CAMBIAN

DESCRIPCIÓN DEL CAMBIO

FECHA DE CAMBIO

P01-PCM-GUIAEVALUACIONSOFTWARE.doc 1.00

N/A

3

Í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

4

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

5

− 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;

6

• 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

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

Calidad delproceso

Atributos dela calidad

interna

Atributos dela calidadexterna

Atributos decalidad en el

uso

influye en influye en influye en

depende de depende de depende de

Producto de software Efectos del productosoftware

Proceso

Medición delproceso

Medicióninterna

Mediciónexterna

Medición de lacalidad en uso

Contextode uso

FIGURA 1 – Ciclo de vida de la calidad

7

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

8

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.

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

Necesidades decalidad del

usuarioCalidad en uso

Requerimientosde calidad

externa

Requerimientosde calidad

interna

Calidad externa

Calidad interna

uso yretroalimentación

validación

verificación

contribuye aespecificar

indica

indica

FIGURA 2 – Calidad en el ciclo de vida del software

9

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.

10

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

11

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.

12

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.

Calidad externa einterna

EficienciaFiabilidad UsabilidadCapacidad demantenimiento

Portabilidad Funcionalidad

Adecuación Exactitud

Interoperatividad Seguridad

Conformidad de funcionalidad

Comportamientode tiempos

Utilización derecursos

Conformidad deeficiencia

Capacidad de ser analizado

CambiabilidadEstabilidad

Facilidad deprueba

Conformidad de facilidad de

mantenimiento

Adaptabilidad Facilidad de instalación

Coexistencia ReemplazabilidadConformidad de

portabilidad

Entendimiento

AprendizajeOperabilidad

AtracciónConformidad de

uso

Madurez Recuperabilidad Tolerancia a fallas

Conformidad de fiabilidad

FIGURA 3 – Modelo de calidad para la calidad externa e interna

13

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.

14

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.

15

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

16

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.

17

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

18

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

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.

FIGURA 4 – Modelo de calidad para la calidad en uso

Calidad en uso

eficacia productividad satisfacción seguridad

19

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.

20

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.

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

atributo

21

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.

22

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

23

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.

24

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:

25

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

26

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

SOFT. 1 SOFT. 2 ……. SOFT.n

Atributos internos (Ai) • Ai1 • Ai2 • . • . • Ain

Atributos externos (Ae)

• Ae1 • Ae2 • . • . • Aen

Atributos de uso (Au)

• Au1 • Au2 • . • . • Aun

PMax. Ai1 PMax. Ai2 . . PMax Ain PMax Ae1 PMax Ae2 . . PMax Aen PMax Au1 PMax Au2 . . 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.

27

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

28

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.

29

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.

30

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.

31

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.

32

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.

Modelos para implantar la mejora continua en la gestión de empresas de transporte por carretera

1

Capítulo 4 La gestión por procesos

Edición MAYO 2005

La gestión por procesos

La gestión por procesos


2


Edición MAYO 2005

Í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


1


Edición MAYO 2005

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.


2


Edición MAYO 2005

SGC: ANÁLISIS DE DATOS

SSIISSTTEEMMAA -- OORRGGAANNIIZZAACCIIÓÓNN

ACTIVIDAD7

ACTIVIDAD8

ACTIVIDAD9

ACTIVIDAD10

ACTIVIDAD11

ACTIVIDAD12

RESULTADO 1

RESULTADO 2

RESULTADO 3

RESULTADO4

OBJETIVO

A

POLÍTICA DE LA CALIDAD

MISION DE LA ORGANIZACIÓN

OBJETIVO

BOBJETIVO

C

Sistema - Función Y

ACTIVIDAD1

ACTIVIDAD2

ACTIVIDAD3

ACTIVIDAD4

ACTIVIDAD5

ACTIVIDAD6

Sistema - Función XProceso A Proceso B Proceso C Proceso D

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. 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 Identificar, entender y gestionar los procesos interrelacionados como un sistema, contribuye a la eficacia y eficiencia de una organización en el logro de sus objetivos.

6. Mejora continua La mejora continua del desempeño global de la organización debería ser un objetivo permanente de ésta.

7. Toma de decisiones basada en hechos 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.

P

DC

AMejoraContinua

Comprobar

Actu

ar

Planificar

Ejecutar


3


Edición MAYO 2005

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

INNOVACIÓN TECNOLÓGICA

SOCIEDAD

CLIENTES

PROVEEDORES

ENTORNO

ESTRATEGIA

SISTEMA DE GESTIÓN

CONOCIMIENTO

RECURSOS ESTRUCTURA

ACCIONISTAS

Factores externos

Factores internos


4


Edición MAYO 2005

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.


5


Edición MAYO 2005

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.

Identificar misión

Establecer visión

Establecer factores críticos del éxito

Definir política y estrategia

Plan a largo plazo para abordar los factores clave que no están como deberían.

Estado deseado que se pretende lograr

Conjunto priorizado y ordenado de aspectos clave

Plan Anual

Acciones concretas

La razón de ser de la organización

Principios básicos de la gestión de la calidad Requisitos de los grupos de interés Entorno social, legal, comercial y tecnológico Información Interna

Establecer los objetivos estratégicos

Concretar el Plan

Estratégico Establecer los objetivos

anuales Desplegar los objetivos


6


Edición MAYO 2005

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.

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.

Elementos básicos de un proceso

ENTRADA

CONTROLES

RECURSOS

SALIDAACTIVIDADES DEL

PROCESO E

E

RE

C

S

R

E PROC A

S PROC D

C

S PROC C

R

E SPROC B

C

E

CR

Interrelaciones entre procesos


7


Edición MAYO 2005

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.

Actividades que aportan valor

Flujo de información Modelo de un SGC basado en

procesos, según ISO 9001

SaliSalidasEntradas

Clientes Clientes

Requisitos

Satisfacción

Leyenda

Responsabilidad de la Dirección

Realización del producto

Mejora continua del sistema de gestión de la calidad

Gestión de recursos

Medición, análisis y mejora

Producto


8


Edición MAYO 2005

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.


9


Edición MAYO 2005

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.

A B C DFUNCION FUNCION FUNCION FUNCION

Los procesos en la organización

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.


10


Edición MAYO 2005

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 DE APOYO

CONTABILIDAD FORMACIONSISTEMAS DEINFORMACIÓN

COMPRAS PERSONALY NÓMINAS

IMAGEN YCOMUNICACIÓN

CLIENTE CLIENTE

PEDIDOS PLANIFICACIÓN PRESTACIÓNDEL SERVICIO

ENTREGA FACTURACION YCOBRO

NEC

ESID

AD

ESY

EXPE

CTA

TIVA

S

SATI

SFA

CC

IÓN

PROCESOS CLAVE o DE REALIZACION

ATENCIONAL CLIENTE

DISEÑO NUEVOSSERVICIOS

GESTIONDE LOS

RECURSOS

GESTIÓN DELA CALIDAD

PROCESOS ESTRATÉGICOS

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.


11


Edición MAYO 2005

Un ejemplo de esta matriz puede verse en el gráfico adjunto.

FCE PROCESOS

Prec

io a

lto

Imag

en

espec

ializ

ació

n

Adap

taci

ón a

va

riac

iones

Plaz

o de

entr

ega

Ser

vici

os n

o co

nfo

rmes

Cos

tes

serv

icio

s

Dis

pon

ibili

dad

re

c. f

inan

cier

os

Dim

ensi

ones

in

stal

acio

nes

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.


12


Edición MAYO 2005

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

Identificación expectativas cliente Valoración expectativas

Valoración satisfacción clientes Benchmarking competencia

Análisis de procesos Indicadores de proceso

Servicio esperado

Servicio percibido

Servicio prestado

Áreas críticas de mejora

Identificación de procesos clave para la

satisfacción del cliente


13


Edición MAYO 2005

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.


14


Edición MAYO 2005

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.


15


Edición MAYO 2005

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.


16


Edición MAYO 2005

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.


17


Edición MAYO 2005

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.


18


Edición MAYO 2005

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.

Trabajobien hecho

Sistema

Querer

Motivación

Poder

Formación

Saber

Desarrollo Orientado a Objetos con UML

Xavier Ferré Grau, María Isabel Sánchez Segura

Facultad de Informática – UPM


i

Í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


ii

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


iii

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

I.1 Introducción 1

Desarrollo Orientado a Objetos con UML Xavier Ferré Grau, María Isabel Sánchez Segura

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.

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.

Figura 1 Logo de UML

Figura 2 Historia de UML

Booch’91 OMT - 1 OOSE Otros Métodos

Booch’93 OMT - 2

Unified Method 0.8 OOPSLA’95

UML 0.9 y 0.91

Revisión por parte del público

Junio del 96 y Octubre del 97

UML 1.0

UML 1.1

Enero del 97

Septiembre del 97

Experiencia de las empresas participantes en UML

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.

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

Figura 3 Ejemplo de nota

Usuario puede ser cualquiera de los actores definidos en el sistema

Usuario

4 II.3 Diagramas de Estructura Estática


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

Figura 5 Notación para clases a distintos niveles de detalle

Clase con detalles a nivel de análisis

Termostato

temperatura_deseada

temperatura_muestreada

establecer_temp ()

Termostato Clase con detalles suprimidos

Clase con detalles de implementación

Termostato

+temperatura_deseada: Temperatura = 20

#temperatura_muestreada: Temperatura

+establecer_temp (valor: Temperatura)

Clase dependiente Clase de la que depende

Pueden existir dependencias entre dos elementos cualesquiera

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.

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

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

Figura 6 Ejemplos de objetos

Objeto de la clase Termostato sin nombre específico

:Termostato

temperatura_deseada = 20°

temperatura_muestreada = 18°

establecer_temp ()

Objeto Eje_de_coordenadas de la clase Punto

Eje_de_coordenadas: Punto

coordenada_x = 0

coordenada_y = 0

Objeto p1de la clase Punto

p1: Punto

coordenada_x = 8,53

coordenada_y = 41,29

Figura 7 Ejemplo de asociación con nombre y dirección

Director Empleado manda sobre



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

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.

Figura 8 Ejemplos de multiplicidad en asociaciones

*

Vive_con

0..4

Nieto Abuelo

Corresponde_a

1

Cuenta Bancaria *

Operación

Figura 9 Ejemplo de roles en una asociación

Hijo

*

2

Padre Persona

Es_padre_de

Emplea * 1..*

Contratante

Empresa

Empleado

Trabajador

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

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.

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.

Figura 10 Ejemplo de agregación

CPU

Pantalla

Teclado

Ordenador

Figura 11 Ejemplo de clase asociación

Emplea * 1..*

Contratante

Empresa Empleado

Trabajador

salario



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

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

Figura 13 Ejemplo de herencia

Figura 12 Ejemplo de asociación ternaria

1 *

Equipo

Equipo

Delantero

Jugador

goles en juego goles a balón parado goles de penalty

Temporada *

Año

Juega

Departamento

Márketing Contabilidad ... Informática

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

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.

Figura 14 Ejemplo de atributo derivado

Persona

nombre fecha_de_nacimiento /edad

{edad = fecha_actual – fecha_de_nacimiento}

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.

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.

Figura 15 Diagrama de Casos de Uso

Cambiar PIN

Agregar Billetes

Realizar Reintegro

<<extiende>>

Cajero Automático

Cliente

Empleado de Sucursal

Realizar Reintegro con VISA

Obtener Últimos Movimientos y Saldo

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.

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

Figura 17 Diagrama de Colaboración

c:Comando-1

c:Comando-2

c:Comando

tratar_mensaje(mensaje)

1a [mensaje.tipo = 1] : crear(mensaje)

1.1: lanzar()

:Receptor_Mensajes

1b [mensaje.tipo = 2] : crear(mensaje)

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.

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

Figura 18 Diagrama de Estados

dígito(n) Marcado Parcial

entrada/número.añadir_digito(n)

Descolgado Sin Marcar

entrada / sonar_tono_de_llamada

dígito(n)

[número.es_válido()]

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 conuna acción simple

Contador := Primero(lista)*7 Esto es un estado de accióncon 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.

Activar Cajero

Desactivar Cajero

Estado de Parada

Estado inicial

Transición sin disparador

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.

ContabilizarMateriales

Asignar Nuevas Tareas

[Materiales disponibles]

[Materiales no disponibles]

Hacer Pedido de Materiales

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 operacionesdirectamente accesibles.

Sólo tienen operaciones y estas son 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.

Componente.java Imagen.java

ObservadorDeImagen

Figura 27 Componentes e interfaces, formato icónico



Componente.java Imagen.java«Interfaz»

ObservadorDeImagen

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.

Nombredel 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 los componentes.

Son los elementos que participan en la ejecución de un sistema.

Representan el despliegue físico de los componentes.

Representan el empaquetamiento 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

HUBTerminal

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

Dominio

Servicios

Lógica de laAplicación

Presentación

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.

Figura 34 Desarrollo Iterativo en la Construcción

Planificación y Especificación de

Requisitos

Construcción Instalación

Ciclo de Desarrollo 1

Ciclo de Desarrollo 2

...

Análisis Implementación Sincronización de Modelos

Diseño PruebasRefinamiento del

Plan

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.

3. Introduce la clave. 4. Presenta las opciones de operaciones

disponibles.

5. Selecciona la operación de Reintegro. 6. Pide la cantidad a retirar.

7. Introduce la cantidad requerida.

8. Procesa la petición y, eventualmente, da el 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 introduce una tarjeta en la ranura para tarjetas.

2. Pide el PIN (Personal Identification Number).

3. Introduce el PIN a través del teclado numérico.

4. Presenta las opciones de operaciones 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 llega al sistema. 2. Pide la operación a realizar.

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.

b. Si se paga con tarjeta ver sección Pago con Tarjeta.

6. Genera recibo.

7. Recoge el recibo y se va.


• Líneas 3 y 5: Selecciona Cancelar. Se cancela la operación.

− Sección: Pago al Contado


1. Mete los billetes correspondientes 2. Coge los billetes y sigue pidiendo dinero

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

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.

Figura 35 Planificación de Ciclos de Desarrollo según Casos de Uso

Ciclo de Desarrollo

Ciclo de Desarrollo

Ciclo de Desarrollo

Caso de Uso A Versión

Simplificada -------- -------- --------

Caso de Uso A Versión

Completa -------- -------- --------

Caso de Uso B

-------- -------- --------

Caso de Uso C

-------- -------- --------

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

Caso de Uso a b c d e f Suma

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

Objetos físicos o tangibles Avión Terminal_de_Caja

Especificaciones, diseños o descripciones de cosas

Especificación_de_Producto Descripción_de_Vuelo

Lugares Supermercado Aeropuerto

Transacciones Venta, Pago Reserva

Líneas de una transacción Artículo_de_Venta

Roles de una persona Cajero Piloto

Contenedores de otras cosas Supermercado, Cesta Avión

Cosas en un contenedor Artículo Pasajero

Otros ordenadores o sistemas electromecánicos externos a nuestro sistema

Sistema_de_Autorización_de_Tarjetas_de Crédito Sistema_Controlador_de_Tráfico_Aéreo

Conceptos abstractos Hambre

Organizaciones Departamento_de_Ventas Compañía_Aérea_Toto

Eventos Venta, Robo, Reunión Vuelo, Accidente, Aterrizaje

Reglas y políticas Política_de_Devoluciones Política_de_Cancelaciones

Catálogos Catálogo_de_Productos Catálogo_de_Piezas



Archivos financieros, de trabajo, de contratos, de asuntos legales

Recibo, Contrato_de_Empleo Registro_de_Revisiones

Instrumentos y servicios financieros

Línea_de_Crédito Stock

Manuales, libros Manual_del_Empleado 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 un informe B

Trabajo_de_Reparación – Registro_de_Reparaciones

A es registrado/archivado/capturado en B

Venta – Terminal_de_Caja

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 B

Cliente – Pago

Pasajero – Billete

A es una transacción relacionada con otra transacción B

Pago – Venta

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.

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

Figura 36 Ejemplo de Diagrama de Secuencia del Sistema

:cajero_automático

insertarTarjeta(número)

entrarIdentificación(clave)

solicitarOperación(operación)

realizarReintegro(cantidad)

dineroRetirado()

reciboRetirado()

tarjetaRetirada()

Cliente

CASO DE USO: Realizar Reintegro Curso Típico de Eventos

1. Este caso de uso empieza cuando un Cliente introduce una tarjeta en el cajero.

2. Pide la clave de identificación.

3. Introduce la clave.

4. Presenta las opciones de operaciones disponibles.

5. Selecciona la operación de Reintegro.

6. Pide la cantidad a retirar.

7. Introduce la cantidad requerida.

8. Procesa la petición y, eventualmente, da el dinero solicitado.

Devuelve la tarjeta y genera un recibo.

9. Recoge la tarjeta.

10. Recoge el recibo.

11. Recoge el dinero y se va.



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

Funciones del Sistema: R1.2, R1.6, R1.7

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

Números de referencia en los requisitos de funciones del sistema, casos de 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.

Figura 37 Ejemplo de Diagrama de Clases de Diseño

Sesion

+ create(login : String)

Operacion

- parametros : String[]

+ create(parametros : long[])

+ lanzar()

Servidor_Claves

+ dar_clave(nombre : int, cuenta : Cuenta)

+ invalidar_clave(mensaje : Mensaje, linea : int)

<<solitario>>

<<local>>

Cuenta

- cuota_disco : int

+ lanzar_operacion_inicial()

+ crear_clave(usuario : String) : String

1

1

-cuenta

1

1

trabaja_con

1

-operacion_inicial

1

lanza_al_iniciarse

*

-cuentas_abiertas

*

recibe_peticiones_de

Gestor_Cuentas

+ conseguir_cuenta(login : String) : Cuenta

<<solitario>>

<<solitario>>

*

1

*

1

gestiona

<<solitario>>

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

Pág. 1

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

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>;

Características Generales 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. 3

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

Características Generales 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. 5

Ejemplo 1, Definición de la Clase Rectángulo IMPLEMENTACIÓN Clase Rectángulo; // Atributos Privado:

Real Largo, Ancho; // Métodos // método constructor

Acción Rectángulo(Real lar, anc); Largo = lar; Ancho = anc; FAcción;

Rectángulo Privado Real Largo Privado Real Ancho

Constructor Acción Rectángulo(lar, anc) Público Función Área: Real Público Función Perímetro: Real

Público Función Área: Real // Retorna el área o superficie ocupada por el rectángulo retornar(Largo * Ancho); FFunción Área;

Público Función Perímetro: Real // 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. 6

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: [Constantes]; [Variables]; o [Estructuras]; Protegido: [Constantes]; [Variables]; o [Estructuras];

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

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;

# Lógico visible; Privado Real Lado

Métodos + color: Entero + modificar_tamaño(Real porcentaje)

Acción Cuadrado(Entero lad) Público Función Área: Real Público Función Perímetro: 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. 8

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:

Ejemplo: El siguiente diagrama de clases muestra la relación de Herencia entre la Clase Animal y sus hijas

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

Nombre del objeto de nivel superior

Nombre del objeto que lo compone

multiplicidadcarro ruedas 4 .. *

clase hija clase madre subclase superclase

Animal

Mamífero Reptil

Serpiente Cocodrilo Humano Perro Gato

Mujer Hombre

Casa

Habitación Baño

Pared Puerta Ventana

Terraza

1 .. * 1 .. * 0 .. *

3 .. 40 .. 41 .. *


Pág. 9

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:

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:

Ejemplos:

Impresora Cartucho_tinta «uso»

Estudiante Portamina recarga

clase 1 clase 2 usa a

clase mayor clase componente persona corazón


Pág. 10

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

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

VI. EJEMPLOS Ejemplo 1, Definición de la Clase Rectángulo Clase Rectángulo; // Atributos Privado:

Real Largo, Ancho; // Métodos Constructor Rectángulo(Real lar, anc); Largo = lar; Ancho = anc; FConstructor; Público Función Área: Real // Retorna el área o superficie ocupada por el rectángulo retornar(Largo * Ancho); FFunción Área;

Público Función Perímetro: Real // Retorna el perímetro del rectángulo

retornar(2 * (Largo + Ancho)); FFunción Perímetro; FClase Rectángulo;

Rectángulo - Real Largo - Real Ancho

+ Acción Rectángulo + Función Área: Real + Función Perímetro: Real

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

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

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

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

¿Te atreves a pasar?


Pág. 16

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

¿Te atreves a pasar?


Pág. 17

Ejemplo 5, Clase Raíces Ecuación de 2do Grado Desarrollar un algoritmo bajo el enfoque orientado a objetos, que permita calcular las raíces (reales e imaginarias) de una ecuación de segundo grado ax2+bx+c, dados los coeficientes a, b y c, con a>0. Análisis: El objeto principal a ser tratado en este problema es la ecuación y se implementará a través de la clase Ecuación2doGrado. Se considerará que cada ecuación tiene asociadas como atributos sus raíces, las cuales deben ser calculadas por el método constructor a través de una acción llamada Resolver. El método constructor tendrá tres parámetros, que son los coeficientes de la ecuación (a, b y c). La clase Ecuación2doGrado tendrá un método público para escribir las raíces llamado Imprimir.

Ecuación2doGrado

Privado Real RaízReal1

Privado Real RaízImaginaria1

Privado Real RaízReal2

Privado Real RaízImaginaria2

Constructor Ecuación2doGrado(Real a, b, c)

// Crea un Objeto Ecuacion2doGrado

Privado Acción Resolver(Real a, b, c)

// Calcula las raíces de la ecuación

Público Acción 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; Fsi; FAcción Resolver;

Público Acción Imprimir; # Muestra las raíces de la ecuación Escribir(r1, i1); Escribir(r2, i2); FAcción Imprimir; FClase Ecuación2doGrado;

// Usamos la clase Ecuacion2doGrado Acción CalcularEcuaciones Real a,b,c; Ecuación2doGrado E, F; Escribir(“suministre coeficientes ecuación 1”); Leer(a, b, c); E.Ecuación2doGrado(a, b, c); E.Imprimir; Escribir(“suministre coeficientes ecuación 2”); Leer(a, b, c); F.Ecuación2doGrado(a, b, c); F.Imprimir; FAcción;


Pág. 18

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

© b

erza

l@ac

m.o

rg

Diseño lógicoDiseño lógicoDiseño de bases de datos relacionalesDiseño de bases de datos relacionales

© b

erza

l@ac

m.o

rg

Diseño lógicoDiseño lógicode bases de datos relacionalesde bases de datos relacionales�� El modelo relacional:El modelo relacional:

�� El concepto de relación: El concepto de relación: tuplastuplas, atributos y dominios., atributos y dominios.�� Restricciones de integridad en el modelo relacional. Restricciones de integridad en el modelo relacional.

�� El proceso de diseño lógico en el modelo relacional.El proceso de diseño lógico en el modelo relacional.�� Del modelo E/R al modelo relacional:Del modelo E/R al modelo relacional:�� Del modelo E/R al modelo relacional:Del modelo E/R al modelo relacional:

�� Entidades.Entidades.�� Entidades débiles.Entidades débiles.�� Relaciones.Relaciones.�� Relaciones de especialización / generalización.Relaciones de especialización / generalización.�� Fusión de tablas.Fusión de tablas.

�� Normalización.Normalización.11

© b

erza

l@ac

m.o

rg

Diseño lógicoDiseño lógicode bases de datos relacionalesde bases de datos relacionalesETAPA DE DISEÑO LÓGICOETAPA DE DISEÑO LÓGICO

Objetivo: Objetivo: Creación del esquema conceptual y de los Creación del esquema conceptual y de los esquemas externos de la base de datos en el modelo esquemas externos de la base de datos en el modelo de datos elegido (p.ej. relacional), independientemente de datos elegido (p.ej. relacional), independientemente de datos elegido (p.ej. relacional), independientemente de datos elegido (p.ej. relacional), independientemente del SGBD que se vaya a utilizar.del SGBD que se vaya a utilizar.

Tarea:Tarea: Transformar los esquemas obtenidos en el Transformar los esquemas obtenidos en el diseño conceptual en un conjunto de estructuras diseño conceptual en un conjunto de estructuras propias del modelo de datos elegido. propias del modelo de datos elegido.

Resultado: Resultado: Conjunto de estructuras propias del modelo Conjunto de estructuras propias del modelo abstracto de datos (p.ej. relaciones).abstracto de datos (p.ej. relaciones).

22

© b

erza

l@ac

m.o

rg

El modelo de datos relacional organiza y representaEl modelo de datos relacional organiza y representalos datos en forma de tablas o relaciones:los datos en forma de tablas o relaciones:

Una base de datos relacional Una base de datos relacional es una colección de relaciones [tablas],es una colección de relaciones [tablas],

cada una de las cuales tiene un nombre único.cada una de las cuales tiene un nombre único.

El modelo relacionalEl modelo relacional

cada una de las cuales tiene un nombre único.cada una de las cuales tiene un nombre único.

RepresentaciónRepresentación RepresentaciónRepresentación ModeloModelológicalógica físicafísica relacionalrelacionalTablaTabla Archivo secuencialArchivo secuencial RelaciónRelaciónFilaFila RegistroRegistro TuplaTuplaColumnaColumna CampoCampo AtributoAtributo

33

© b

erza

l@ac

m.o

rg


El concepto de relación:El concepto de relación:TuplasTuplas, atributos y dominios, atributos y dominios

id_trabajador nombre tarifa_hr tipo_de_oficio id_supv1235 F. Aguilera 12,50 Electricista 13111412 A. Calvo 13,75 Fontanero 1540

44

1412 A. Calvo 13,75 Fontanero 15402920 N. Marín 10,00 Carpintero null3231 O. Pons 17,40 Albañil null1540 J.M. Medina 11,75 Fontanero null1311 J.C. Cubero 15,50 Electricista null3001 D. Sánchez 8,20 Albañil 3231

© b

erza

l@ac

m.o

rg


El concepto de relación:El concepto de relación:TuplasTuplas, atributos y dominios, atributos y dominios

�� AtributoAtributo ((AAii):): Elemento susceptible de tomar valores Elemento susceptible de tomar valores (cada una de las columnas de la tabla).(cada una de las columnas de la tabla).(cada una de las columnas de la tabla).(cada una de las columnas de la tabla).

�� DominioDominio (D(Dii): ): Conjunto de valores que puede tomar Conjunto de valores que puede tomar un atributo (se considera finito).un atributo (se considera finito).

�� TuplaTupla: : Cada uno de los elementos que contiene una Cada uno de los elementos que contiene una instancia de la relación (filas).instancia de la relación (filas).

55

© b

erza

l@ac

m.o

rg


El concepto de relaciónEl concepto de relación

Relación R(Relación R(AAii....AAnn))Subconjunto del producto cartesiano DSubconjunto del producto cartesiano D11××....××DDnn

(esto es, una tabla).(esto es, una tabla).(esto es, una tabla).(esto es, una tabla).

En una relación hay que distinguir dos aspectos:En una relación hay que distinguir dos aspectos:

�� Esquema de la relaciónEsquema de la relación: Los atributos A: Los atributos A11....AAnnp.ej. Trabajadores (p.ej. Trabajadores (id_trabajadorid_trabajador, nombre, , nombre, tarifa_hrtarifa_hr, , tipo_de_oficiotipo_de_oficio, , id_supvid_supv))

�� Instancia de la relaciónInstancia de la relación: El conjunto de : El conjunto de tuplastuplas{{(x(x11,x,x22,..,x,..,xnn))}} ⊆⊆ DD11××DD22××....××DDnn que la componen enque la componen encada momento.cada momento. 66

© b

erza

l@ac

m.o

rg


El concepto de relaciónEl concepto de relación

Relación R(Relación R(AAii....AAnn))Subconjunto del producto cartesiano DSubconjunto del producto cartesiano D11××....××DDnn

(esto es, una tabla).(esto es, una tabla).(esto es, una tabla).(esto es, una tabla).

Consecuencias de la definición de relaciónConsecuencias de la definición de relacióncomo conjunto de como conjunto de tuplastuplas::

�� No existen No existen tuplastuplas duplicadasduplicadas(concepto de clave primaria).(concepto de clave primaria).

�� No existe orden en las No existe orden en las tuplastuplas(ni en los atributos).(ni en los atributos). 77

© b

erza

l@ac

m.o

rg

Esquema de la base de datosEsquema de la base de datos

Una base de datos relacional es un conjunto finito de Una base de datos relacional es un conjunto finito de relaciones junto con una serie de restricciones o reglas relaciones junto con una serie de restricciones o reglas de integridad:de integridad:


de integridad:de integridad:

�� Restricción de integridadRestricción de integridad: Condición necesaria para : Condición necesaria para preservar la corrección semántica de la base de datos.preservar la corrección semántica de la base de datos.

�� Esquema de la base de datosEsquema de la base de datos: : Colección de Colección de esquemas de relaciones junto con las restriccionesesquemas de relaciones junto con las restriccionesde integridad que se definen sobre las relaciones.de integridad que se definen sobre las relaciones.

88

© b

erza

l@ac

m.o

rg

Instancia de la base de datosInstancia de la base de datos

�� Instancia (o estado) de la base de datosInstancia (o estado) de la base de datos: : Colección de instancias de relaciones que verifican las Colección de instancias de relaciones que verifican las restricciones de integridad.restricciones de integridad.


restricciones de integridad.restricciones de integridad.

�� Base de datos relacionalBase de datos relacional: : Instancia de la base de datosInstancia de la base de datosjunto con su esquema.junto con su esquema.

99

© b

erza

l@ac

m.o

rg

Restricciones de integridad:Restricciones de integridad:Asociadas a las Asociadas a las tuplastuplas de una relaciónde una relación

p.ej.p.ej. 0 ≤ edad ≤ 1200 ≤ edad ≤ 120impuestos ≤ sueldoimpuestos ≤ sueldo


impuestos ≤ sueldoimpuestos ≤ sueldo

�� En ocasiones, no se conoce el valor de un atributo para En ocasiones, no se conoce el valor de un atributo para una determinada una determinada tuplatupla. En esos casos, a ese atributo . En esos casos, a ese atributo de esa de esa tuplatupla se le asigna un se le asigna un valor nulo (valor nulo (nullnull)), que , que indica que el valor de ese atributo es desconocido o, indica que el valor de ese atributo es desconocido o, simplemente, que ese atributo no es aplicable a esa simplemente, que ese atributo no es aplicable a esa tuplatupla..

1010

© b

erza

l@ac

m.o

rg

Restricciones de integridad:Restricciones de integridad:Asociadas a las relaciones de la base de datosAsociadas a las relaciones de la base de datos

�� Clave primaria: Clave primaria: Conjunto de atributos seleccionados para identificar Conjunto de atributos seleccionados para identificar


Conjunto de atributos seleccionados para identificar Conjunto de atributos seleccionados para identificar unívocamente a las unívocamente a las tuplastuplas de una relación.de una relación.

�� Integridad de entidad:Integridad de entidad:Los atributos de la clave primaria no pueden Los atributos de la clave primaria no pueden tomar valores nulos, ya que la clave primariatomar valores nulos, ya que la clave primariadebe permitirnos identificar unívocamentedebe permitirnos identificar unívocamentecada cada tuplatupla de la relación.de la relación.

1111

© b

erza

l@ac

m.o

rg


�� Clave externa:Clave externa: Conjunto de atributos de una relación Conjunto de atributos de una relación cuyos valores en las cuyos valores en las tuplastuplas deben coincidir con valores deben coincidir con valores


cuyos valores en las cuyos valores en las tuplastuplas deben coincidir con valores deben coincidir con valores de la clave primaria de las de la clave primaria de las tuplastuplas de otra relación.de otra relación.

�� Integridad referencial:Integridad referencial:Todos los valores no nulos de una clave externa Todos los valores no nulos de una clave externa referencian valores reales de la clave referenciada.referencian valores reales de la clave referenciada.

1212

© b

erza

l@ac

m.o

rg


La integridad referencial mantieneLa integridad referencial mantienelas conexiones en las bases de datos relacionales:las conexiones en las bases de datos relacionales:


las conexiones en las bases de datos relacionales:las conexiones en las bases de datos relacionales:

imparte.NRP imparte.NRP ∈∈ profesor.NRPprofesor.NRPEl profesor que imparte una asignaturaEl profesor que imparte una asignaturadebe existir en la tabla de profesores.debe existir en la tabla de profesores.

cuenta.sucursalcuenta.sucursal ∈∈ sucursal.númerosucursal.númeroUna cuenta tiene que pertenecerUna cuenta tiene que pertenecera una sucursal existente.a una sucursal existente. 1313

© b

erza

l@ac

m.o

rg

El proceso de diseño lógicoEl proceso de diseño lógicoen el modelo relacionalen el modelo relacionalTransformación de un diagrama E/R en un esquema relacional:Transformación de un diagrama E/R en un esquema relacional:

1.1. Se transforman en tablas todos los tipos de entidades y Se transforman en tablas todos los tipos de entidades y relaciones que aparecen en el diagrama E/R.relaciones que aparecen en el diagrama E/R.

2.2. Se seleccionan las claves primarias para cada una de las Se seleccionan las claves primarias para cada una de las tablas de nuestro esquema lógico.tablas de nuestro esquema lógico.tablas de nuestro esquema lógico.tablas de nuestro esquema lógico.

3.3. Fusión de tablasFusión de tablas: Se combinan aquellas tablas que : Se combinan aquellas tablas que compartan su clave primaria.compartan su clave primaria.

4.4. NormalizaciónNormalización: Se normaliza el esquema resultante : Se normaliza el esquema resultante (al menos, hasta BCNF).(al menos, hasta BCNF).

5.5. Se definen todas las restricciones de integridadSe definen todas las restricciones de integridadque sean aplicables al esquema obtenido.que sean aplicables al esquema obtenido. 1414

© b

erza

l@ac

m.o

rg

Del modelo E/R al modelo relacionalDel modelo E/R al modelo relacional

EntidadesEntidades

Cada tipo de entidad da lugarCada tipo de entidad da lugara una tabla en la base de datos.a una tabla en la base de datos.

�� AtributosAtributos: : Los atributos del tipo de entidad.Los atributos del tipo de entidad.

�� Clave primariaClave primaria::Una de las claves candidatas Una de las claves candidatas del conjunto de entidades.del conjunto de entidades.

1515

© b

erza

l@ac

m.o

rg


EntidadesEntidades

Atributos compuestosAtributos compuestos�� Se incluyen en la relación todos los atributos simples Se incluyen en la relación todos los atributos simples

(atómicos) que forman parte del atributo compuesto.(atómicos) que forman parte del atributo compuesto.(atómicos) que forman parte del atributo compuesto.(atómicos) que forman parte del atributo compuesto.

Atributos derivados Atributos derivados �� No se almacenarán en la base de datos, por lo que No se almacenarán en la base de datos, por lo que nono se incluyen como atributos de las relaciones.se incluyen como atributos de las relaciones.

1616

© b

erza

l@ac

m.o

rg


EntidadesEntidadesAtributos Atributos multivaluadosmultivaluados�� Se almacenan en una tabla auxiliar que incluya las Se almacenan en una tabla auxiliar que incluya las

columnas necesarias para almacenar la clave primaria columnas necesarias para almacenar la clave primaria del conjunto de entidades más aquéllas que se del conjunto de entidades más aquéllas que se del conjunto de entidades más aquéllas que se del conjunto de entidades más aquéllas que se necesiten para representar un valor del atributo MV. necesiten para representar un valor del atributo MV.

�� Salvo que el atributo MV sea una clave alternativa del Salvo que el atributo MV sea una clave alternativa del conjunto de entidades, todas las columnas de la tabla conjunto de entidades, todas las columnas de la tabla auxiliar formarán parte de su clave primaria.auxiliar formarán parte de su clave primaria.

�� La tabla auxiliar incluirá una clave externa que haga La tabla auxiliar incluirá una clave externa que haga referencia a la tabla correspondiente al conjunto de referencia a la tabla correspondiente al conjunto de entidades que incluye el atributo entidades que incluye el atributo multivaluadomultivaluado. .

1717

© b

erza

l@ac

m.o

rg


Entidades débilesEntidades débiles

�� AtributosAtributos: : Además de los atributos propios de la entidad débil, Además de los atributos propios de la entidad débil, los atributos pertenecientes a la clave primaria de la los atributos pertenecientes a la clave primaria de la los atributos pertenecientes a la clave primaria de la los atributos pertenecientes a la clave primaria de la entidad fuerte de la que depende existencialmente la entidad fuerte de la que depende existencialmente la entidad débil.entidad débil.

Apunte (Apunte (CCCCCC, número, descripción, importe), número, descripción, importe)1818

© b

erza

l@ac

m.o

rg



�� Clave primariaClave primaria::La clave primaria de la entidad fuerteLa clave primaria de la entidad fuerte más un conjunto más un conjunto de atributos propio de la entidad débil (discriminante).de atributos propio de la entidad débil (discriminante).de atributos propio de la entidad débil (discriminante).de atributos propio de la entidad débil (discriminante).

Clave primaria de la entidad débil Clave primaria de la entidad débil ==

Clave primaria de la entidad fuerte Clave primaria de la entidad fuerte ++

DiscriminanteDiscriminante

Apunte (Apunte (CCC, númeroCCC, número, descripción, importe), descripción, importe) 1919

© b

erza

l@ac

m.o

rg



�� Clave externaClave externa: : Una, haciendo referencia a la entidad fuerte de la que Una, haciendo referencia a la entidad fuerte de la que depende existencialmente la entidad débil.depende existencialmente la entidad débil.depende existencialmente la entidad débil.depende existencialmente la entidad débil.

Apunte (Apunte (CCCCCC, número, número, descripción, importe), descripción, importe)

Cuenta (Cuenta (CCCCCC, …), …)

2020

© b

erza

l@ac

m.o

rg


RelacionesRelaciones

Cada tipo de relación da lugarCada tipo de relación da lugara una tabla en la base de datos.a una tabla en la base de datos.

Atributos:Atributos:

Los atributos de las claves primarias de las entidades Los atributos de las claves primarias de las entidades que intervienen en la relación más los atributos propios que intervienen en la relación más los atributos propios de la relación.de la relación.

2121

© b

erza

l@ac

m.o

rg



Clave primaria:Clave primaria:Si la relación no tiene atributos propios:Si la relación no tiene atributos propios:�� Relación muchos a muchosRelación muchos a muchos: La unión de las claves : La unión de las claves �� Relación muchos a muchosRelación muchos a muchos: La unión de las claves : La unión de las claves

de los conjuntos de entidades que intervienen.de los conjuntos de entidades que intervienen.�� Relación uno a muchosRelación uno a muchos: La clave correspondiente al : La clave correspondiente al

conjunto de entidades que participa en la relación con conjunto de entidades que participa en la relación con cardinalidadcardinalidad “muchos”.“muchos”.

�� Relación uno a unoRelación uno a uno: Una de las claves de las: Una de las claves de lasentidades intervinientes en la relación (cualquiera).entidades intervinientes en la relación (cualquiera).

2222

© b

erza

l@ac

m.o

rg



Clave primaria:Clave primaria:Si hay atributos propios de la relación:Si hay atributos propios de la relación:�� Los atributos correspondientes al tipo de relación,Los atributos correspondientes al tipo de relación,�� Los atributos correspondientes al tipo de relación,Los atributos correspondientes al tipo de relación,

a los que tal vez añadiremos algunos atributos propios a los que tal vez añadiremos algunos atributos propios de la relación, dependiendo de su semántica.de la relación, dependiendo de su semántica.

Claves externas:Claves externas:�� Una por cada una de las claves primarias de los Una por cada una de las claves primarias de los

conjuntos de entidades que intervienen en la relación.conjuntos de entidades que intervienen en la relación.

2323

© b

erza

l@ac

m.o

rg



SSOBREOBRE LALA RELACIÓNRELACIÓN ENTREENTRE ENTIDADESENTIDADES DÉBILESDÉBILES YY FUERTESFUERTES……

Las relaciones entre entidades débiles y fuertes no hay Las relaciones entre entidades débiles y fuertes no hay que pasarlas a tablas porque la relación se recoge como que pasarlas a tablas porque la relación se recoge como que pasarlas a tablas porque la relación se recoge como que pasarlas a tablas porque la relación se recoge como parte de la clave primaria de la entidad débil (la parte parte de la clave primaria de la entidad débil (la parte correspondiente a la clave primaria de la entidad fuerte correspondiente a la clave primaria de la entidad fuerte es una clave externa que apunta a la tabla derivada de es una clave externa que apunta a la tabla derivada de la entidad fuerte).la entidad fuerte).

2424

© b

erza

l@ac

m.o

rg


Relaciones nRelaciones n--ariasarias

Atributos: Atributos: Los atributos de las claves primarias de los Los atributos de las claves primarias de los conjuntos de entidades que intervienen en la relación conjuntos de entidades que intervienen en la relación más los atributos propios de la relación.más los atributos propios de la relación.

Clave primaria: Clave primaria: Estará formada por la unión de las claves Estará formada por la unión de las claves primarias correspondientes a todos aquellos conjuntos primarias correspondientes a todos aquellos conjuntos de entidades que intervengan en la relación con de entidades que intervengan en la relación con cardinalidadcardinalidad N (más, opcionalmente, alguno[s] de los N (más, opcionalmente, alguno[s] de los atributos propios de la relación).atributos propios de la relación).

Claves externas: Claves externas: Una por cada uno de los conjuntos de Una por cada uno de los conjuntos de entidades que intervienen en la relación.entidades que intervienen en la relación.

2525

© b

erza

l@ac

m.o

rg


Relaciones de generalización y especializaciónRelaciones de generalización y especialización

Estrategia A: Una tabla por cada conjunto de entidadesEstrategia A: Una tabla por cada conjunto de entidadesLas particularizaciones heredan la clave primaria del Las particularizaciones heredan la clave primaria del conjunto de entidades de nivel superior (la cual será, en conjunto de entidades de nivel superior (la cual será, en conjunto de entidades de nivel superior (la cual será, en conjunto de entidades de nivel superior (la cual será, en las tablas correspondientes a los subtipos, una clave las tablas correspondientes a los subtipos, una clave externa que referencia a la tabla derivada del externa que referencia a la tabla derivada del supertiposupertipo).).

Ejemplo:Ejemplo:

EmpleadoEmpleado (NRP, nombre, dirección… )(NRP, nombre, dirección… )ProfesorProfesor (NRP, departamento, categoría)(NRP, departamento, categoría)PAS PAS (NRP, grupo, nivel)(NRP, grupo, nivel)

2626

© b

erza

l@ac

m.o

rg



Estrategia B: Una tabla por cada caso particularEstrategia B: Una tabla por cada caso particularLas particularizaciones heredan todosLas particularizaciones heredan todoslos atributos de la entidad general.los atributos de la entidad general.los atributos de la entidad general.los atributos de la entidad general.

Ejemplo:Ejemplo:

Profesor Profesor (NRP, nombre, dirección… departamento, categoría)(NRP, nombre, dirección… departamento, categoría)PAS PAS (NRP, nombre, dirección… grupo, nivel)(NRP, nombre, dirección… grupo, nivel)

2727

© b

erza

l@ac

m.o

rg



Estrategia C: Una tabla para toda la jerarquíaEstrategia C: Una tabla para toda la jerarquía

En este caso, se suele añadir una columna artificial En este caso, se suele añadir una columna artificial En este caso, se suele añadir una columna artificial En este caso, se suele añadir una columna artificial (discriminante) que indique el tipo de la entidad (discriminante) que indique el tipo de la entidad representada por cada representada por cada tuplatupla de la tabla de la tabla (para permitir el mantenimiento de las (para permitir el mantenimiento de las restricciones de integridad aplicables).restricciones de integridad aplicables).

Ejemplo:Ejemplo:

Empleado (NRP, nombre, dirección… Empleado (NRP, nombre, dirección… departamento, categoría, grupo, nivel)departamento, categoría, grupo, nivel)

2828

© b

erza

l@ac

m.o

rg



Formalmente, la primera estrategia es la correcta. Formalmente, la primera estrategia es la correcta.

Las otras dos estrategias sólo las emplearemos cuando, Las otras dos estrategias sólo las emplearemos cuando, Las otras dos estrategias sólo las emplearemos cuando, Las otras dos estrategias sólo las emplearemos cuando, por cuestiones de eficiencia, queramos reducir el número por cuestiones de eficiencia, queramos reducir el número de reuniones necesarias para realizar determinadas de reuniones necesarias para realizar determinadas consultas (motivo por el que la decisión de utilizar un consultas (motivo por el que la decisión de utilizar un esquema u otro la pospondremos usualmente a la fase esquema u otro la pospondremos usualmente a la fase de diseño físico de la base de datos).de diseño físico de la base de datos).

2929

© b

erza

l@ac

m.o

rg


Fusión de tablasFusión de tablas

Se pueden combinar en una sola Se pueden combinar en una sola todas las tablas que compartan su clave primaria.todas las tablas que compartan su clave primaria.

p.ej.p.ej.Relaciones uno a muchosRelaciones uno a muchos

Las tablas derivadas de las relaciones muchos a uno se Las tablas derivadas de las relaciones muchos a uno se fusionan con las derivadas de las entidades que fusionan con las derivadas de las entidades que participan en la relación con participan en la relación con cardinalidadcardinalidad N.N.

3030

© b

erza

l@ac

m.o

rg

Fusión de tablasFusión de tablasRelaciones uno a unoRelaciones uno a uno

Se pueden combinar las tablas derivadas de los dos conjuntos de entidades Se pueden combinar las tablas derivadas de los dos conjuntos de entidades en una sola o mantener tablas separadas:en una sola o mantener tablas separadas:

�� Si la relación es obligatoria en ambos sentidos (las entidades involucradas Si la relación es obligatoria en ambos sentidos (las entidades involucradas


�� Si la relación es obligatoria en ambos sentidos (las entidades involucradas Si la relación es obligatoria en ambos sentidos (las entidades involucradas siempre aparecen conjuntamente), se pueden combinar las tablas derivadas siempre aparecen conjuntamente), se pueden combinar las tablas derivadas de los dos conjuntos de entidades, manteniendo como clave primaria la de los dos conjuntos de entidades, manteniendo como clave primaria la clave primaria de uno de los conjuntos de entidades y como clave clave primaria de uno de los conjuntos de entidades y como clave alternativa la clave primaria del otro conjunto de entidades.alternativa la clave primaria del otro conjunto de entidades.

�� En cualquier otro caso, siempre se mantendrán tablas separadas para los 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 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 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 entidades es obligatoria, se suele elegir su tabla para fusionarla con la tabla derivada de la relación.la tabla derivada de la relación.

3131

© b

erza

l@ac

m.o

rg

Fusión de tablasFusión de tablasRelaciones de especialización y generalizaciónRelaciones de especialización y generalización

A la hora de representar jerarquías de especialización/generalización, A la hora de representar jerarquías de especialización/generalización, a veces fusionaremos las tablas correspondientes a distintos conjuntos de a veces fusionaremos las tablas correspondientes a distintos conjuntos de entidades. entidades.


entidades. entidades.

Se ha de llegar a un compromiso entre el coste de realizar consultas que Se ha de llegar a un compromiso entre el coste de realizar consultas que involucren reuniones de distintas tablas (cuando tenemos tablas involucren reuniones de distintas tablas (cuando tenemos tablas independientes) y el coste que supone desaprovechar espacio de independientes) y el coste que supone desaprovechar espacio de almacenamiento y tener que mantener manualmente determinadas almacenamiento y tener que mantener manualmente determinadas restricciones de integridad (cuando se combinan varias tablas en una sola).restricciones de integridad (cuando se combinan varias tablas en una sola).

3232

© b

erza

l@ac

m.o

rg

NormalizaciónNormalización

La normalización permite obtener un conjunto La normalización permite obtener un conjunto adecuado de relaciones de tal forma que:adecuado de relaciones de tal forma que:

�� El esquema de la base de datos incluya el mínimo El esquema de la base de datos incluya el mínimo número de atributos necesarios para dar soporte a los número de atributos necesarios para dar soporte a los número de atributos necesarios para dar soporte a los número de atributos necesarios para dar soporte a los requerimientos del sistema.requerimientos del sistema.

�� Resulte más fácil acceder a la base de datos y, sobre Resulte más fácil acceder a la base de datos y, sobre todo, mantener los datos de la base de datos todo, mantener los datos de la base de datos ((redundancia mínimaredundancia mínima: salvo los atributos que : salvo los atributos que forman parte de claves externas, los demás se forman parte de claves externas, los demás se representarán una única vez en la base de datos).representarán una única vez en la base de datos).

3333

© b

erza

l@ac

m.o

rg


En una base de datos normalizada:En una base de datos normalizada:

�� Las actualizaciones se consiguen realizar con un Las actualizaciones se consiguen realizar con un número mínimo de operaciones número mínimo de operaciones número mínimo de operaciones número mínimo de operaciones (mejorando la eficiencia de la BD y reduciendo la (mejorando la eficiencia de la BD y reduciendo la posibilidad de que aparezcan inconsistencias).posibilidad de que aparezcan inconsistencias).

�� Se reduce al mínimo el espacio de almacenamiento Se reduce al mínimo el espacio de almacenamiento necesario para almacenar los datos de la BDnecesario para almacenar los datos de la BD(reduciendo los costes de operación de la BD).(reduciendo los costes de operación de la BD).

3434

© b

erza

l@ac

m.o

rg


Las relaciones que almacenan datos redundantes Las relaciones que almacenan datos redundantes presentan presentan anomalías de actualización anomalías de actualización (la inserción, eliminación o modificación de los datos (la inserción, eliminación o modificación de los datos puede provocar la aparición de inconsistencias), puede provocar la aparición de inconsistencias), por lo que resulta adecuado descomponerlas:por lo que resulta adecuado descomponerlas:

�� Sin pérdidasSin pérdidas (de forma que la relación original se (de forma que la relación original se pueda reconstruir a partir de las relaciones en las que pueda reconstruir a partir de las relaciones en las que la hayamos descompuesto).la hayamos descompuesto).

�� Preservando las dependencias Preservando las dependencias (para que podamos (para que podamos mantener las restricciones de integridad de la relación mantener las restricciones de integridad de la relación original introduciendo restricciones en las relaciones original introduciendo restricciones en las relaciones provenientes de la descomposición de la relación provenientes de la descomposición de la relación original).original). 3535

© b

erza

l@ac

m.o

rg


La descomposición sin pérdidas es indispensable, La descomposición sin pérdidas es indispensable, la descomposición que preserva las dependencias la descomposición que preserva las dependencias no siempre es posible. no siempre es posible. no siempre es posible. no siempre es posible.

A veces, el diseñador tiene que elegir entre A veces, el diseñador tiene que elegir entre �� no normalizar, o bien,no normalizar, o bien,�� perder dependencias.perder dependencias.

3636

© b

erza

l@ac

m.o

rg


Dependencias funcionalesDependencias funcionales

Describen relaciones entre los atributos de una relación: Describen relaciones entre los atributos de una relación:

B depende funcionalmente de A (AB depende funcionalmente de A (A→→B) B) cuando cada valor de A en una relación R cuando cada valor de A en una relación R

aparece siempre asociado al mismo valor de B en R.aparece siempre asociado al mismo valor de B en R.

3737

© b

erza

l@ac

m.o

rg


Dependencias funcionalesDependencias funcionales

Formalmente:Formalmente:

Sea un esquema R, sean Sea un esquema R, sean αα y y ββ subconjuntos de subconjuntos de ⊆⊆ ⊆⊆

Sea un esquema R, sean Sea un esquema R, sean αα y y ββ subconjuntos de subconjuntos de atributos, atributos, αα⊆⊆RR y y ββ⊆⊆RR. Decimos que . Decimos que αα determina determina funcionalmente a funcionalmente a ββ, o que , o que ββ depende funcionalmente depende funcionalmente de de αα, o que , o que α→βα→β, si y sólo si se verifica, que para toda , si y sólo si se verifica, que para toda relación relación rr instancia de ese esquema:instancia de ese esquema:

∀∀tt11,t,t22∈∈r ; tr ; t11[[αα]=t]=t22[[αα] ] ⇒⇒ tt11[[ββ]=t]=t22[[ββ]]

3838

© b

erza

l@ac

m.o

rg


Identificación de dependencias funcionalesIdentificación de dependencias funcionales

�� La identificación de las dependencias funcionales La identificación de las dependencias funcionales existentes es relativamente fácil si se conoce el existentes es relativamente fácil si se conoce el significado de cada atributo y las relaciones existentes significado de cada atributo y las relaciones existentes significado de cada atributo y las relaciones existentes significado de cada atributo y las relaciones existentes entre ellos.entre ellos.

�� Toda la información necesaria debería figurar en el Toda la información necesaria debería figurar en el documento de especificación de requerimientos, bien documento de especificación de requerimientos, bien en la parte correspondiente a los requerimientos en la parte correspondiente a los requerimientos funcionales o bien en el diccionario de datos que ha funcionales o bien en el diccionario de datos que ha de acompañar al modelo semántico de la base de de acompañar al modelo semántico de la base de datos.datos. 3939

© b

erza

l@ac

m.o

rg


La identificación de dependencias funcionales sirve para:La identificación de dependencias funcionales sirve para:

�� Especificar las Especificar las restricciones de integridadrestricciones de integridadasociadas a una relación (claves candidatas: asociadas a una relación (claves candidatas: clave primaria y claves alternativas).clave primaria y claves alternativas).clave primaria y claves alternativas).clave primaria y claves alternativas).

�� Detectar posibles Detectar posibles anomalías de actualización anomalías de actualización y y evitarlas, ya sea reorganizando el esquema de la base evitarlas, ya sea reorganizando el esquema de la base de datos (recomendado) o tomando las medidas de datos (recomendado) o tomando las medidas oportunas al implementar las aplicaciones que oportunas al implementar las aplicaciones que funcionen sobre la base de datos (trabajo adicional funcionen sobre la base de datos (trabajo adicional que habrá que justificar razonadamente).que habrá que justificar razonadamente).

4040

© b

erza

l@ac

m.o

rg


El proceso de normalizaciónEl proceso de normalización

�� La normalización consiste en analizar el conjunto de La normalización consiste en analizar el conjunto de relaciones obtenido a partir del diagrama E/R teniendo relaciones obtenido a partir del diagrama E/R teniendo en cuenta las claves candidatas y las dependencias en cuenta las claves candidatas y las dependencias en cuenta las claves candidatas y las dependencias en cuenta las claves candidatas y las dependencias existentes entre los atributos de cada relación.existentes entre los atributos de cada relación.

�� La normalización se suele descomponer en una serie La normalización se suele descomponer en una serie de pasos, cada uno de los cuales corresponde a una de pasos, cada uno de los cuales corresponde a una forma normalforma normal específica de propiedades conocidas.específica de propiedades conocidas.

4141

© b

erza

l@ac

m.o

rg

Normalización: 1NFNormalización: 1NF

1NF: Primera Forma Normal1NF: Primera Forma NormalTodos los atributos tienen dominios atómicos.Todos los atributos tienen dominios atómicos.

Para obtener una relación en 1NF:Para obtener una relación en 1NF:Se eliminan los atributos compuestos y Se eliminan los atributos compuestos y multivaluadosmultivaluados..Se eliminan los atributos compuestos y Se eliminan los atributos compuestos y multivaluadosmultivaluados..

4242

© b

erza

l@ac

m.o

rg


2NF: Segunda Forma Normal2NF: Segunda Forma NormalTodos los atributos no primos (los que no forman Todos los atributos no primos (los que no forman parte de claves candidatas) dependen funcionalmente parte de claves candidatas) dependen funcionalmente de las claves candidatas de forma completa.de las claves candidatas de forma completa.

�� Una dependencia funcional es completaUna dependencia funcional es completa�� Una dependencia funcional es completaUna dependencia funcional es completacuando el determinante no se puede simplificar. cuando el determinante no se puede simplificar.

Para obtener una relación en 2NF:Para obtener una relación en 2NF:Si existe una dependencia funcional incompleta Si existe una dependencia funcional incompleta CK→βCK→β

(esto es, (esto es, α→βα→β con con αα∈∈CKCK, siendo , siendo CKCK una clave una clave candidata de la relación), candidata de la relación), ββ se traslada a una nueva se traslada a una nueva relación junto con el determinante relación junto con el determinante αα y eliminamos y eliminamos ββde la relación original.de la relación original.

4343

© b

erza

l@ac

m.o

rg


3NF: Tercera Forma Normal3NF: Tercera Forma NormalNingún atributo no primo depende transitivamente de Ningún atributo no primo depende transitivamente de ninguna clave candidata.ninguna clave candidata.

�� Si ASi A→→B y BB y B→→C, entonces C depende C, entonces C depende transitivamente de A transitivamente de A aa través de B (esto es, Através de B (esto es, A→→C). C). transitivamente de A transitivamente de A aa través de B (esto es, Através de B (esto es, A→→C). C).

�� Esta dependencia transitiva puede causar Esta dependencia transitiva puede causar anomalías de actualización cuando B no es una anomalías de actualización cuando B no es una clave candidata de la relación.clave candidata de la relación.

Para obtener una relación en 3NF:Para obtener una relación en 3NF:Se eliminan las dependencias transitivas problemáticasSe eliminan las dependencias transitivas problemáticastrasladándolas a una nueva relación.trasladándolas a una nueva relación.

4444

© b

erza

l@ac

m.o

rg

Normalización: BCNFNormalización: BCNF

La definición original de La definición original de CoddCodd para la 3NF no produce para la 3NF no produce diseños satisfactorios si hay varias claves candidatas y diseños satisfactorios si hay varias claves candidatas y éstas se solapan:éstas se solapan:

BCNF: Forma Normal de BCNF: Forma Normal de BoyceBoyce y y CoddCoddBCNF: Forma Normal de BCNF: Forma Normal de BoyceBoyce y y CoddCoddTodo determinante es una clave candidata.Todo determinante es una clave candidata.�� Toda relación en BCNF está en 3NF.Toda relación en BCNF está en 3NF.

Diferencia entre 3NF y BCNF: Diferencia entre 3NF y BCNF: Dada una dependencia funcional ADada una dependencia funcional A→→B, 3NF la permite B, 3NF la permite en una relación si B es un atributo primo y A no es en una relación si B es un atributo primo y A no es una clave candidata, mientras que BCNF requiere una clave candidata, mientras que BCNF requiere que A sea una clave candidataque A sea una clave candidata. . 4545

© b

erza

l@ac

m.o

rg


Otros tipos de dependencias, distintas a las Otros tipos de dependencias, distintas a las dependencias funcionales, también pueden introducir dependencias funcionales, también pueden introducir redundancia en los datos almacenados en una relación:redundancia en los datos almacenados en una relación:

4NF: Cuarta Forma Normal4NF: Cuarta Forma Normal4NF: Cuarta Forma Normal4NF: Cuarta Forma Normal

Como consecuencia de la 1NF, pueden aparecer Como consecuencia de la 1NF, pueden aparecer dependencias dependencias multivaluadasmultivaluadas que habrá que eliminar. que habrá que eliminar.

Para que una relación esté en 4NF, todo determinante Para que una relación esté en 4NF, todo determinante de una dependencia de una dependencia multivaluadamultivaluada debe ser una clave debe ser una clave candidata (y, por tanto, una dependencia funcional).candidata (y, por tanto, una dependencia funcional).

4646

© b

erza

l@ac

m.o

rg


5NF: Quinta Forma Normal5NF: Quinta Forma Normal

Cuando una relación se descompone en más de dos Cuando una relación se descompone en más de dos relaciones (porque no se pueda encontrar una relaciones (porque no se pueda encontrar una descomposición sin pérdidas en dos proyecciones), descomposición sin pérdidas en dos proyecciones), descomposición sin pérdidas en dos proyecciones), descomposición sin pérdidas en dos proyecciones), se ha de cumplir un requisito para que la se ha de cumplir un requisito para que la descomposición sea sin pérdidas: descomposición sea sin pérdidas: toda dependencia de reunión toda dependencia de reunión debe ser consecuencia de las claves candidatas.debe ser consecuencia de las claves candidatas.

4747

© b

erza

l@ac

m.o

rg


Cuando se decida no normalizar tras haber encontrado Cuando se decida no normalizar tras haber encontrado una dependencia entre los atributos de una relación,una dependencia entre los atributos de una relación,se ha de justificar se ha de justificar el porquéel porqué..

p.ej. p.ej. CP CP →→ MunicipioMunicipio en una dirección, pero tal vez no en una dirección, pero tal vez no nos interese tener que mantener una tabla aparte con nos interese tener que mantener una tabla aparte con todos los municipios de España y sus códigos postales.todos los municipios de España y sus códigos postales.

4848

© b

erza

l@ac

m.o

rg

BibliografíaBibliografía

�� C.J. Date:C.J. Date:“Introducción a los sistemas de bases de datos”. “Introducción a los sistemas de bases de datos”. PrenticePrentice Hall, 2001 [7ª edición]. ISBN 968Hall, 2001 [7ª edición]. ISBN 968--444444--419419--2. 2.

�� RamezRamez A. A. ElmasriElmasri & & ShamkantShamkant B. B. NavatheNavathe: : “Fundamentos de Sistemas de Bases de Datos”. “Fundamentos de Sistemas de Bases de Datos”. AddisonAddison--WesleyWesley, 2007 [5ª edición]. ISBN 84, 2007 [5ª edición]. ISBN 84--782782--90859085--0. 0. AddisonAddison--WesleyWesley, 2007 [5ª edición]. ISBN 84, 2007 [5ª edición]. ISBN 84--782782--90859085--0. 0.

�� Thomas M. Connolly & Carolyn E. Thomas M. Connolly & Carolyn E. BeggBegg::““SistemasSistemas de Bases de de Bases de DatosDatos””AddisonAddison--Wesley, 2005 [4ª Wesley, 2005 [4ª ediciónedición]. ISBN 84]. ISBN 84--782782--90759075--3.3.

�� Henry F. Henry F. KorthKorth, Abraham , Abraham SilberschatzSilberschatz & S. & S. SudarshanSudarshan: : “Fundamentos de Bases de Datos”. “Fundamentos de Bases de Datos”. McGrawMcGraw--Hill, 2006 [5ª edición]. ISBN 84Hill, 2006 [5ª edición]. ISBN 84--481481--46444644--1.1.

�� Olga Pons, Nicolás Marín, Juan Miguel Medina, Silvia Olga Pons, Nicolás Marín, Juan Miguel Medina, Silvia AcidAcid &&Mª Amparo Vila: “Introducción a las Bases de Datos: El modelo Mª Amparo Vila: “Introducción a las Bases de Datos: El modelo relacional”. Paraninfo, 2005. ISBN 8497323963relacional”. Paraninfo, 2005. ISBN 8497323963 4949

1

Capítulo 5

Sistemas operativos

Autor: Santiago Felici

Fundamentos de Telemática

(Ingeniería Telemática)

2

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

3

¿QUÉ ES UN SISTEMA OPERATIVO?

Aplicaciones de usuario

Sistema Operativo

Hardware

Interfaz con la Máquina Virtual

Interfaz con el Hardware

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.

4

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.

HardwareSistema Operativo

Software del Sistema

Software de aplicaciones

Usuarios

5

Sistemas operativos



6

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

7

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


8

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,...)


9

Herramientas de una interfaz gráfica

Ventana

Iconos

Barra de Tareas

Menú

Barra de herramientas

10

Línea de comandos

Interfaz de línea de comandos

11

Sistemas operativos



12

1. Ejecución de Programas (programa en ejecución: ejecutable,

datos, pila, contador, registros...)

2. Operaciones de E/S3. Manipulación de ficheros4. Comunicaciones5. Detección de errores6. Asignación de recursos7. Contabilidad8. Protección

SERVICIOS PROPORCIONADOS POR EL SO

13

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.

Carga y ejecución de Programas

14

Sistemas operativos



15

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 SERVIDORy la que inicia el contacto es llamada CLIENTE.

16

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,

...

17

Sistemas operativos



18

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

19

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

20

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.

21

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.

22

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

23

Sistemas operativos



24

UNIX

v UNIX comienza en 1969, con Ken Thompson y Dennis Ritchie.v Es el más antiguo de los S.O. para computadoras personalesv Es multiusuario, multiprocesador, multitarea, soporta redesv En la mayoría de sus versiones, usa interfaz de línea de comando. Sin embargo, actualmente la mayoría utilizan interfaz gráfica

v Es una versión de UNIX. Se puede obtener a un muy bajo costo oincluso gratisv Esta basado en 32 bits y tiene todas las capacidades de UNIXvMultitarea, multiusuario, soporta redes, multiplataformav Se puede utilizar en cualquier tipo de computador, ya que demanda pocos recursos (trabaja muy bien hasta en equipos 386)

LINUX

25

v Creado en 1981 por IBM computers. DOS fue el S.O. adoptado inicialmente por la mayoría de los computadores personalesv No soporta multitarea, ni multiprocesamientov Usa interfaz de línea de comandosv Es relativamente fiable y estableVENTAJAS DOSvAmplio usovNúmero de Aplicaciones generadas bajo DOS.vFuncionamiento sobre Hardware de bajo costovUtilizado en Windows 95, Windows 98 or Windows NTDESVENTAJAS DOSvAlmacenamiento Primario Limitado.vTareas Únicas.vInterfaz basado en caracteres.

DOS

26

v Esta familia incluye Windows 3.0, 3.1 y 3.11v 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

WINDOWS 3.x

v Fue el primer S.O. realmente gráfico, para computadoras personales que utilizan procesadores Intel v Es multitarea, multiusuario y soporta redesv Fue el primer S.O. para computadores personales, con capacidades de reconocimiento de voz integradas

OS/2 Warp

27

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 redesv Viene en dos versiones: Workstation y Serverv Es muy poderoso y resistente a fallos

Windows NT

v Windows 95 fue el primer S.O. de interfaz gráfica de 32 bits de Microsoftv Es multitarea, y puede ejecutar programas de DOS y Windows 3.xv Windows 98 incluye capacidades para Internet, una interfaz gráfica mejorada y mayor eficiencia en el manejo de archivos

Windows 95 y 98

28

v Tiene todas las bondades gráficas de la versión 98, más todo elpoder, estabilidad, manejo de redes y archivos de Windows NTv Existen varias versiones dependiendo de las características delusuariovMultitarea, multiusuario

Windows 2000

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 realvAcceso a internet

Windows XP

29

v Fue el primer Sistema Operativo WIMP (Windows, Icons, Menus, Pointer). v Ofreció a los usuarios la primera interfaz verdaderamente gráficav Todas las aplicaciones bajo MAC/OS tienen la misma apariencia (look and feel) vMultitarea preferente, multiproceso simétrico,multiusuario, multimodo, de tiempo realvAcceso a internetvBasado en Unix, es establevCompatible con Windows

MAC/OS X

SISTEMAS OPERATIVOS: Diseño e Implementación

SEGUNDA EDICION

ANDREW S. TANENBAUMVrije Universiteit

Amsterdam, Países Bajos

ALBERT S. WOODHULLHampshire College

Amherst, Massachusetts

INTRODUCCIONSin 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, él1 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 extendidaComo 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 recursosEl 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 OPERATIVOSLos 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ónDespué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 loteLa 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ónA 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 personalesCon 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 MINIXCuando 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 OPERATIVOSLa 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 ProcesosUn 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 ArchivosLa 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 shellEl 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

datepor 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 >archivoDe forma similar, la entrada estándar puede redirigirse, como en

sort <archivo 1 >archivo2que 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/lpinvoca 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.

http://www.wikipedia.org/

http://guimi.net/index.php?pag_id=licencia/cc-by-sa-30-es_human.html

http://guimi.net/

Redes de comunicaciones

Redes de comunicacionesContenido

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

http://guimi.net/

Redes de comunicaciones

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


http://guimi.net/

Redes de comunicaciones 1. INTRODUCCIÓN

1. INTRODUCCIÓN 1.1. ConceptosRed de comunicacionesUna 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ónLa 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 flujoCapacidad 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éctricasEl 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).


http://guimi.net/


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


http://guimi.net/


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 redLas 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ónDiá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.


http://guimi.net/


Por su topologíaLa 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.).


http://guimi.net/


Por su técnica de transmisión de datosLí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


http://guimi.net/


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 dedicadasE1/T1

Conmutación de circuitosRTB, RDSI, GSM

Circuito Virtual Redes de conmutación con PVCsX.25, Frame Relay, ATM

Redes de conmutación con SVCsX.25, Frame Relay, ATM


http://guimi.net/

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.


LLC (Logical Link Control)

N2 Enlace de datosDirecc. físico y gestión tráfico

MAC (Medium Access Control)

N1 FísicoSeñal y transmisión

N3 RedDireccionamiento lógico

Selección de ruta y gestión tráfico

N4 TransporteDivide / Compone el mensaje

Fiabilidad de datos

N5 SesiónInterfaz de dispositivos

de red del sistema

N6 PresentaciónRepresentación de los datos

Comprime / Expande / Traduce

N7 AplicaciónServicios de red

Genera / Consume el mensaje

N2

N1

N3

N2

N1

N3

N4

N5

N6

N7

Subred comunicaciones

Nivel usuario

Medio(Hilo, ondas...)

Equipos

Mensajes

[Encaminadores / Puentes]

Datagramas (UDP)Segmentos (TCP)

Paquetes

Tramas

http://guimi.net/


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


http://guimi.net/


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.


http://guimi.net/

Redes de comunicaciones 3. EL MODELO INTERNET

3. EL MODELO INTERNET 3.1. Un poco de historiaLos 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 InternetLa 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.


http://guimi.net/


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 InternetEl 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).


http://guimi.net/


3.3. Protocolo Internet (IP)Diseño de IPLa 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 encaminamientoLos 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 v4En 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.


http://guimi.net/


Direccionamiento v4Una 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 v4Originalmente 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 IP0xxx 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 IP10xx 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 IP110x xxxx.xxxx xxxx.xxxx xxxx.||xxxx xxxx (192.0.0.0-223.255.255.255)

● Clase D: Multicasting, no utilizable1110 xxxx.xxxx xxxx.xxxx xxxx.xxxx xxxx (224.0.0.0-239.255.255.255)

● Clase E: Experimental, no utilizable1111 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).


http://guimi.net/


Máscara de redComo 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 reservadosIPv4 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


http://guimi.net/


Generación de SubredesCuando 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ónSe 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 subredesBits Subred / Equipo

1 / 7 *sxxx xxxx

2 / 6ssxx xxxx

3 / 5sssx xxxx

4 / 4ssss xxxx

5 / 3ssss sxxx

6 / 2ssss ssxx

7 / 1 *ssss sssx

8 / 0 *ssss ssss

Subredes / Rango

2 / 128 *sxxx xxxx

4 / 64ssxx xxxx

8 / 32sssx xxxx

16 / 16ssss xxxx

32 / 8ssss sxxx

64 / 4ssss ssxx

128 / 2 *ssss sssx

256 / 1 *ssss ssss

Máscara 128 *1000 0000

1921100 0000

2241110 0000

2401111 0000

2481111 1000

2521111 1100

254 *1111 1110

255 *1111 1111

Rangos efectivos(utilizables)

[0]* Inútil

[2]64-128

[6]32-64-96-128-160-192

[14]16-32-48-64-80-96-112-128-144-160-176-192-208-224

[30]8-16-24-32-40-48-...200-208-216-224-232-240

[62]4-8-12-16-20-24-... 232-236-240-244-248

[126]2-4-6-8-...250-252*Inútil en el último octeto de la máscara

[254]* Se pasa de una red a 254 redes de clase inferior.

● 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).


http://guimi.net/


Ejemplos de subredesEjemplo 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)Queremos crear 2 subredes -> Tomamos la máscara 255.192.0.0 (11|00 0000)Cada subred tiene un rango de direcciones de 64*255*255 -2 (xx xxxx): [64-128-192]Rangos de direcciones IP obtenidos: 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)

Ejemplo 3 con red tipo B:Rango de direcciones: 172.18.x.x (máscara inicial /16 o 255.255.0.0)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]Rangos de direcciones IP obtenidos: 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)Queremos crear 6 subredes -> Tomamos la máscara 255.255.224.0 (111|0 0000)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.Rangos de direcciones IP obtenidos: 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)


http://guimi.net/


Ejemplo 5 con red tipo B:Rango de direcciones: 172.16.x.x (máscara inicial /16 o 255.255.0.0)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]Rangos de direcciones IP obtenidos: 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.

Rango de direcciones: 172.16.x.x (máscara inicial /16 o 255.255.0.0)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


http://guimi.net/


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.


http://guimi.net/


Direccionamiento v6IPv6 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 IPv6Algunas 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::4Ejemplo 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 IPv6Los 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.


http://guimi.net/


Sistema de Nombres de Dominio (DNS) en IPv6Al 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.

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


http://guimi.net/


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

ProtocoloESP

Firmado (Opcional)

Cifrado

IPHeader

ESPHeader

TCP/UDPHeader

DATA ESPTrailer

ESPAuh

Firmado (Opcional)

Cifrado

New IPHeader

ESPHeader

Orig. IPHeader

TCP/UDPHeader

DATA ESPTrailer

ESPAuh

ProtocoloAH

Firmado

IPHeader

AuthHeader

TCP/UDPHeader

DATA

Firmado

New IPHeader

AuthHeader

Orig. IPHeader

TCP/UDPHeader

DATA

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.


http://guimi.net/


3.4. Otros protocolos de la familia InternetARP y RARPEl 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 IGMPICMP (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.

TCPTCP (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.


http://guimi.net/


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


http://guimi.net/


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

UDPUDP (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.


http://guimi.net/


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


http://guimi.net/

Redes de comunicaciones 4. ETHERNET

4. ETHERNET 4.1. Un poco de historiaEn 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.

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


Diagrama de Ethernet realizado por Metcalfe

http://guimi.net/


4.2. DefiniciónEthernet 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 colisionesEl 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.


http://guimi.net/


4.4. DireccionamientoCada 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 tramaLa 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.


http://guimi.net/


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


http://guimi.net/


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.


http://guimi.net/


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. RestriccionesEl 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)


http://guimi.net/


4.11. La evolución de la familia EthernetEthernetTransmite 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)Fue la primera versión comercial.

Coaxial amarillo de 50 ΩTransceptores vampiros y cable AUI (drop) de hasta 50 metros.

2 / 100 500 m.Half-Duplex

10Base-2 (1)Surgió para solucionar los problemas de coste y rigidez del coaxial amarillo.

Coaxial RG58 de 50 ΩConectores BNC -conectores T-

4 / 30 separadas entre sí por 1 m. o más.

185 m.Half-Duplex

10Base-T (2)Surgió para reutilizar los cables de telefonía -par trenzado no apantallado (UTP)- para datos.

Par trenzado a partir de Cat. 3.Conectores RJ-45.De los 4 pares del cable solo utiliza dos: El 2 y el 3 (hilos 1, 2, 3 y 6).

4 / 1024 Cat. 3 – 100mCat. 5 – 150mHalf-Duplex yFull-Duplex

10Base-F (3) (10Base-Fx)Implementación del estándar. Se usan sus variantes FL, FB o FP.

Multimodo; LED en primera ventana. Luz visible.Conectores ST.

2000 m.Half-Duplex yFull-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ó-).


http://guimi.net/


Fast EthernetEsta 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-TxVariante de 100Base-T con cable cat. 5.Código 4B/5B.

Par trenzado (TP) de categoría 5.Usa los mismos hilos que 10Base-T.

2 Clase II33 unidos con un cable de hasta 5m.

100m. - Full-Duplex

100Base-T4 (1)Variante de 100Base-T con cable cat. 3, usando 4 pares.Código 8B/6T.

UTP de categoría 3.Utiliza 3 pares para transmitir y uno para detección de colisiones.

2 Clase II unidos con un cable de hasta 5m.

100m. - Half-duplex

100Base-T2 (1)Variante de 100Base-T con cable cat. 3 Full-Duplex.Código PAM-5x5.

UTP de categoría 3.Utiliza los 4 pares.

Requiere procesadores de señal específicos muy sofisticados, ya que emiten y reciben a la vez por el mismo cable(*), por lo que era una opción cara que nunca se llegó a implementar.

100m. - Full-duplex(* Dual-Duplex)

100Base-FxCódigo 4B/5B NRZ-I (No Return to Zero - Inverted).

Fibra óptica multimodo con LED en segunda ventana.Conectores SC.

400m. - Half-duplex2000m - Full-Duplex

(1) Pensados para seguir utilizando el cableado telefónico existente (UTP Cat. 3).

Gigabit EthernetEsta 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-TCódigo PAM-5x5.

Par trenzado (TP) Cat. 5, 5e o 6. Emite y recibe simultáneamente por los 4 pares (*).

100 m. - Full-duplex(* Dual-duplex)

1000Base-LxCódigo 8B/10B NRZ. Se puede optimizar para conseguir hasta 10.000m. de alcance con fibras mono-modo.

Fibra óptica multi y monomodo con ILD en segunda ventana.Conectores SC.

En fibras multimodo: 330m - Half-duplex 550m - Full-duplexEn fibras monomodo: 330m - Half-duplex 2000m – Full-duplex

1000Base-SxCódigo 8B/10B (8 bits/10 baudios) NRZ.La optoelectrónica de LEDs en primera ventana lo hace mucho más económico que Lx

Fibra óptica multimodo con LED en primera ventana.Conectores SC.

62,5/125: 275m. 50/125: <~ 330m - Half-duplex <~ 550m – Full-duplexDepende de la calidad de la fibra.

33 Los concentradores pueden ser de Clase I o II en función del retardo que generan.


http://guimi.net/


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.


http://guimi.net/


Resumen

Estándar Medio / Conectores Distancia Codificación

10Base-5 (1)Primera versión comercial.

Coaxial amarillo de 50 Ω (grueso)y transceptores

500 m.Half-Duplex

Manchester

10Base-2 (1)Coaxial más económico.

Coaxial RG58 de 50 Ω (fino)y conectores BNC

185 m.Half-Duplex

Manchester

10Base-T (2)Reutiliz. cables de telefonía.

UTP Cat. 3 y RJ-45.UTP Cat. 5 y RJ-45.

Cat. 3 – 100mCat. 5 – 150mHalf-Duplex yFull-Duplex

Manchester

10Base-F (3) (10Base-Fx)Fibra óptica multimodo.FL / FB / FP

Multimodo; LED en primera ventana.Luz visible.Conectores ST.

2000 m.Half-Duplex yFull-Duplex

Manchester

100Base-TxUTP Cat. 5.

UTP Cat. 5 y RJ-45. 100m. - Full-Duplex 4B/5B

100Base-T4 (1)UTP Cat. 3 Half no balanceado.

UTP Cat. 3 y RJ-45.3 pares para transmisión1 par para colisiones

100m. - Half-duplex 8B/6T

100Base-T2 (1)UTP Cat. 3 Full balanceado.

UTP Cat. 3 y RJ-45.Procesadores específicos.

100m. - Full-duplex(Dual-Duplex)

PAM-5x5

100Base-FxFibra óptica.

Multimodo; LED en segunda ventana.Conectores SC.

400m. - Half-duplex2000m - Full-Duplex

4B/5B NRZ-I

1000Base-TPar trenzado.

UTP Cat. 5, 5e o 6 y RJ-45. 100 m. - Full-duplex(Dual-duplex)

PAM-5x5

1000Base-LxFibra más rápida.

Fibra óptica multi y monomodo con ILD en segunda ventana.Conectores SC.

En fibras multimodo: 330m - Half-duplex 550m - Full-duplexEn fibras monomodo: 330m - Half-duplex 2000m - Full-duplex

8B/10B NRZ

1000Base-SxFibra más económica.

Fibra óptica multimodo con LED en primera ventana.Conectores SC.

62,5/125: 275m. 50/125: 330m - Half-duplex 550m - Full-duplex

8B/10B NRZ


http://guimi.net/


4.12. Mejoras de rendimientoSegú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 enlacesLa 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.

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


http://guimi.net/


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.

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


http://guimi.net/

Redes de comunicaciones 5. IEEE 802.11 (Wi-Fi)

5. IEEE 802.11 (Wi-Fi) 5.1. DefiniciónIEEE 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ámbricasIEEE 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 definicionesPunto 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ónMecanismo 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.


http://guimi.net/


Señales BeacomLa 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 ISMLas 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ñalComo 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éctricaLas 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.


http://guimi.net/


5.3. Problemas añadidos en redes inalámbricasAdemá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.


http://guimi.net/


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


http://guimi.net/


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.11LegacyEl 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.11aLa 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.11bLa 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.11gLa 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.


http://guimi.net/


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.11hLa 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.11iAprobado 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.11eLa 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 WMMLa 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.


http://guimi.net/


802.11nPrevisto 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.11wTodaví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 revisionesAunque 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


http://guimi.net/

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


http://guimi.net/


6.2. X.25El 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. RDSILa 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.


http://guimi.net/


6.4. FDDI (Fiber Distributed Data Interface) / CDDIFDDI 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-RELAYIntroducciónFrame-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 circuitosLas 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.


http://guimi.net/


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-RelayEl 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 auxiliaresAunque 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.


http://guimi.net/


6.6. ATM (Asynchronous Transfer Mode)IntroducciónATM 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 [email protected], que se correspondería con el número 34961234567 en la RTC.


http://guimi.net/


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

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


http://guimi.net/


6.7. Redes de fibra SONet / SDHLas 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

(Synchronous Transfer Signal)SONet Óptico – OC

(Optical Carrier)SDH Óptico – STM

(Synchronous Transport Module)Velocidad

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


http://guimi.net/


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.


http://guimi.net/


6.12. Redes de satélitesSe 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.


http://guimi.net/

Redes de comunicaciones 7. MÉTODOS DE ACCESO A REDES

7. MÉTODOS DE ACCESO A REDES 7.1. IntroducciónExisten 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ódemsUn 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. xDSLIntroducciónLa 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-).


http://guimi.net/


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.


http://guimi.net/


Variantes de xDSLADSLLa 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 3 s 3 s

Corrección de Errores No Sí Sí

ADSL G.LitePermite 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.


http://guimi.net/


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)


http://guimi.net/


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.


http://guimi.net/

Redes de comunicaciones 8. REDES PRIVADAS VIRTUALES

8. REDES PRIVADAS VIRTUALES 8.1. IntroducciónSe 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/TUNPara 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 remotoEn 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.


http://guimi.net/


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 redesLa 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 usuarioLa 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).

ProtocolosPara 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).


http://guimi.net/


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 VPNsProtocolo 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 IPSecEl 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.


http://guimi.net/

Redes de comunicaciones 9. SEGURIDAD EN REDES

9. SEGURIDAD EN REDES 9.1. IntroducciónCriptología y esteganografíaLa 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étricaLa 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.


http://guimi.net/


Criptografía asimétricaLa 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 mensajesLos 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 seguraCuando 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.


http://guimi.net/


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.


http://guimi.net/


Intercambio Diffie-HellmanEl 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 medioEl 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.


http://guimi.net/


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. AlgoritmosComo 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 3DESEl 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).

AESAES (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.

RCxRC4 (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).

IDEAIDEA (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.


http://guimi.net/


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.


http://guimi.net/


9.3. Técnicas criptográficas y de seguridadLos 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 usuarioUna 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-CHAPPAP (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.


http://guimi.net/


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

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


http://guimi.net/


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 seguridadLas 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 TLSTLS (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).

IKEIKE (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.


http://guimi.net/


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 WPA2El 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 PEAPEAP (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.


http://guimi.net/


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 / GPGPGP (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.

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


http://guimi.net/


9.6. Herramientas de seguridad de redesLas 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 redEstas 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 seguridadOtro 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 paquetesLos 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 clavesLos 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.


http://guimi.net/

Redes de comunicaciones 10. TRANSMISIÓN MULTIMEDIA EN REDES IP

10. TRANSMISIÓN MULTIMEDIA EN REDES IP 10.1. IntroducciónEl 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ódechardware (H.26x) y una conexión RDSI, al que se le acopla un monitor de televisión y una serie de dispositivos deentrada/salida de altas prestaciones, tales como cámaras activadas por la voz, cámaras de documentos, micrófonosdireccionales, micrófonos de ambiente, un sistema de altavoces de alta calidad, etc. Además incorporan sofisticadossistemas 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 serun 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 usuariodonde 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 deuno 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).


http://guimi.net/


10.2. El protocolo H.323IntroducciónEl estándar H.323 es un conjunto de normas y protocolos recomendado por el ITU-T (International TelecommunicationUnion) diseñado para permitir transmisiones multimedia en LANs basadas en IP. Fue rápidamente adoptado porfabricantes de equipos para transmitir voz y videoconferencia sobre IP ya que define un modelo básico de llamada conservicios 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 oSS7. 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.


http://guimi.net/


ComponentesTerminalUn 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 decontrol, indicaciones, audio, vídeo y/o datos entre los dos terminales. Conforme a la especificación, un terminal debeproporcionar audio (voz) y opcionalmente puede proporcionar más canales de audio (por ejemplo para emitir envarios 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 buenasincronizació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 elprotocolo 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 redIP y otros terminales o pasarelas en una red conmutada. Además de realizar la conversión de protocolo puede realizaropcionalmente 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 elmundo 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).


http://guimi.net/


MCU (Multipoint Control Unit)Para conectar dos o más terminales -para realizar una llamada o una vídeoconferencia- hace falta una Unidad de ControlMultipunto (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 eluso de transmisión multicast, por ejemplo mediante el uso de la red MBone de Internet. En este caso en vez deencargarse 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 elementosLos proveedores de servicios pueden tener dentro de su red cientos de pasarelas, teléfonos, terminales multimedia... Enesos casos es útil dividir la red en zonas, por ejemplo por ciudades. A un conjunto de zonas controladas por una solaorganización se le llama “dominio administrativo”.Dentro de un dominio administrativo puede existir elementos llamados de borde o de frontera (Border element) quecentralizan las comunicaciones con elementos de borde de otros dominios administrativos. Estas comunicacionespueden 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 lainformación útil sobre los elementos de bordes del propio dominio y de otros dominios.


http://guimi.net/


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.


http://guimi.net/

http://www.voipforo.com/H323/H323ejemplo.php


10.3. Protocolo SIPIntroducciónEl protocolo SIP se concentra en el establecimiento, modificación y terminación de las sesiones. Se complementa, entreotros, con el SDP, que describe el contenido multimedia de la sesión, por ejemplo qué direcciones IP, puertos y códecsse usarán durante la comunicación. También se complementa con RTP (Real-time Transport Protocol), que es elverdadero 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 comoH.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 elestablecimiento de sesiones multipunto, permite que un usuario esté registrado en diferentes ubicaciones (pudiendorealizar 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 desus principios de diseño: es legible por humanos y sigue una estructura de petición-respuesta basado en el modelocliente-servidor. Las respuestas llevan un código de estado que brindan información acerca de si las peticiones fueronresueltas 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 protocolose define como punto-a-punto o entre pares -p2p-), este enfoque es impracticable para un servicio público. En ese casorequiere de servidores intermediarios (proxy), elementos de registro y servidores de localización (DNS), utilizando unnúcleo de red sencillo (y altamente escalable) con inteligencia distribuida en los extremos de la red, incluida en losterminales (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 laque se conecte el usuario, y dirección lógica que es invariable para cada usuario. Al igual que en el correo-e, lasdirecciones lógicas de SIP tienen la forma usuario@dominio, gestionando cada dominio una compañía o proveedor deservicios 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 haciaotros 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).


http://guimi.net/


ComponentesAgentes de Usuario (Terminales)Son los puntos extremos del protocolo, es decir son los que emiten y consumen los mensajes del protocolo SIP. Unvideoteléfono, un teléfono, un cliente de software (softphone) y cualquier otro dispositivo similar es para el protocoloSIP un agente de usuario.Todos los agentes de usuario se comportan como clientes (UAC: User Agent Clients) y como servidores (UAS: UserAgent Servers).

Algunos terminales por software que soportan charlas de audio y vídeo a través de SIP son Microsoft WindowsMessenger, 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 unperí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 utilizarseuna estrategia tipo p2p). Estos servidores a su vez se sirven del sistema DNS para localizar los dominios y puedenactuar de dos maneras:

a) Como intermediario, encaminando el mensaje hacia destinob) 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 deredirecció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ónEn 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.


http://guimi.net/


Normalmente la petición con el método INVITE lleva un cuerpo donde viaja una descripción de la sesión que quiereestablecer, 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 detransmisión, etc.). Esto se conoce como "oferta de sesión SDP". La respuesta a esta oferta viaja, en este caso, en elcuerpo de la respuesta definitiva a la petición con el método INVITE. La misma contiene la descripción de la sesióndesde el punto de vista del destinatario. Si las descripciones fueran incompatibles la sesión debe terminarse (medianteuna petición con el método BYE).


http://guimi.net/

Redes de comunicaciones 11. VÍDEO-DIFUSIÓN Y VÍDEO BAJO DEMANDA

11. VÍDEO-DIFUSIÓN Y VÍDEO BAJO DEMANDALos servicios de vídeo-difusión y vídeo bajo demanda se caracterizan por disponer de los contenidos multimediapreviamente comprimidos en servidores. De esta forma el proceso de compresión puede realizarse en diferido con laoptimizació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 bajo demanda

Vídeo-Conferencia

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.


http://guimi.net/

Redes de comunicaciones 12. ANEXO I – Cortafuegos

12. ANEXO I – CortafuegosUn 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


http://guimi.net/

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 redarpEl 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.# arpAddress HWtype HWaddress Flags Mask Ifacemaquina01.net2.upv.e ether 00:09:97:xx:xx:xx C eth1maquina2.degi.upv.es ether 00:15:F2:xx:xx:xx C eth1## arp -amaquina01.net2.upv.es (158.42.222.x) at 00:09:97:xx:xx:xx [ether] on eth1maquina2.degi.upv.es (158.42.222.x) at 00:15:F2:xx:xx:xx [ether] on eth1## arp -nAddress HWtype HWaddress Flags Mask Iface158.42.222.x ether 00:09:97:xx:xx:xx C eth1158.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).

digdig 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

hosthost 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


http://guimi.net/


ifconfigifconfig 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:# ifconfigeth1 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

ipconfigipconfig 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


http://guimi.net/


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 Gigabit 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

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

Los parámetros más interesantes son:● “-v” indica que muestre una salida con más información (similar a nbtstat).● “-h” hace que explique los servicios.

$ nbtscan 158.42.222.xDoing 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.xDoing NBT name scan for addresses from 158.42.222.x

NetBIOS Name Table for Host 158.42.222.x:

Name Service Type----------------------------------------MAQUINA01 <00> UNIQUEMAQUINA01 <20> UNIQUEUPVNET <00> GROUPUPVNET <1e> GROUPUPVNET <1d> UNIQUE__MSBROWSE__ <01> GROUP

Adapter address: 00:15:f2:xx:xx:xx----------------------------------------

$$ nbtscan -vh 158.42.222.xDoing NBT name scan for addresses from 158.42.222.x

NetBIOS Name Table for Host 158.42.222.x:

Name Service Type


http://guimi.net/


----------------------------------------MAQUINA01 Workstation ServiceMAQUINA01 File Server ServiceUPVNET Domain NameUPVNET Browser Service ElectionsUPVNET Master Browser__MSBROWSE__ Master Browser

Adapter address: 00:15:f2:xx:xx:xx----------------------------------------

nbtstatnbtstat 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.Los parámetros más interesantes son:

● “-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


http://guimi.net/


netEl 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:\>netNET [ 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 shareADMIN$ C:\WINDOWS Remote AdminIPC$ Remote IPCD$ D:\ Default shareThe command completed successfully.

W:\>net use <-- Permite ver y modificar las conexiones del sistemaNew connections will be remembered.

Status Local Remote Network-------------------------------------------------------------------------------OK W: \\maquina01\guimi Microsoft Windows NetworkDisconnected X: \\maquina02\guimi Microsoft Windows NetworkThe command completed successfully.

W:\>net start/stop <-- Permiten iniciar/parar o ver los servicios iniciados del sistemaThese Windows services are started:[...] WorkstationThe command completed successfully.

netdiagnetdiag 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

netshnetsh 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:\>netshnetsh>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:


http://guimi.net/


aaaa bridge dhcp diag firewall interface ipsec ras routing rpc wins winsock

netsh>quit

netstatnetstat 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 -eInterface Statistics Received SentBytes 3987777529 651861703Unicast packets 30617810 32440422Non-unicast packets 136910 9869Discards 0 0Errors 0 0Unknown 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.


http://guimi.net/


$ 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 nametcp 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 -nrKernel IP routing tableDestination Gateway Genmask Flags MSS Window irtt Iface158.42.xxx.0 0.0.0.0 255.255.255.0 U 0 0 0 eth10.0.0.0 158.42.xxx.250 0.0.0.0 UG 0 0 0 eth1O ifconfig:$ netstat -inetKernel Interface tableeth1 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[...]

nmapnmap 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 CESTInteresting ports on localhost (127.0.0.1):Not shown: 1672 closed portsPORT STATE SERVICE22/tcp open ssh80/tcp open http111/tcp open rpcbind113/tcp open auth631/tcp open ipp902/tcp open iss-realsecure-sensor3306/tcp open mysql5432/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 CESTHost maquina01 (xxx.xx.xxx.1) appears to be up.[...]Nmap finished: 256 IP addresses (5 hosts up) scanned in 2.258 seconds

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


http://guimi.net/


Ejemplo de uso interactivo:W:\>nslookupDefault Server: juno.cc.upv.es <-- Nos indica el servidor DNSAddress: 158.42.250.195

> guimi.net <-- Consultamos un dominioServer: juno.cc.upv.esAddress: 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 consultaDefault Server: 85.red-213-0-184.static.ccgg.telefonica.netAddress: 213.0.184.85

> exit <-- Terminamos la utilidad nslookup

Ejemplos de uso no interactivo:W:\>nslookup guimi.netServer: juno.cc.upv.esAddress: 158.42.250.195

Non-authoritative answer:Name: guimi.netAddress: 212.36.74.190

$ nslookup 212.36.74.190Server: 158.42.250.65Address: 158.42.250.65#53

Non-authoritative answer:190.74.36.212.in-addr.arpa name = hc05.cdmon.com.[...]

pathpingEl comando pathping primero muestra los saltos hacia el destino como tracert, a continuación ejecuta varios pings hacia cada destino y calcula estadísticas.

Los parámetros más interesantes son:● “-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.


http://guimi.net/


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/LinkHop 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.

pingEl 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 -nPING 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 0msrtt min/avg/max/mdev = 6.904/6.904/6.904/0.000 ms

routeEl 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):# routeKernel IP routing tableDestination Gateway Genmask Flags Metric Ref Use Iface158.42.xxx.0 * 255.255.255.0 U 0 0 0 eth1default 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”


http://guimi.net/


# 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 List0x1 ........................... MS TCP Loopback interface0x50003 ...00 15 f2 d0 0c b8 ...... Marvell Yukon 88E8001/8003/8010 PCI GigabitEthernet 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^

tctc 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).

traceroutetraceroute 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.nettraceroute 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 -Itraceroute 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


http://guimi.net/


tracerttracert 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:\>tracertUsage: 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). -4 Force using IPv4. -6 Force using IPv6.

W:\>tracert guimi.netTracing 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.


http://guimi.net/

Redes de comunicaciones 14. ANEXO III - La VC en el campo educativo

14. ANEXO III - La VC en el campo educativoExtracto 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ónDe 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ónLos 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.


http://guimi.net/

http://www.uib.es/depart/gte/oliver.html

Redes de comunicaciones 14. ANEXO III - La VC en el campo educativo

14.3. Elementos que el profesor tiene que contemplarAntes 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-conferenciaIntentar 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-conferenciaUna 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-.


http://guimi.net/

© 2008 Cisco Systems, Inc. Todos los derechos reservados. Información confidencial de CiscoPresentation_ID 1

Capítulo 9: División de redes IP en subredes

Introducción a redes

Ing. Aníbal Coto Cortés

Presentation_ID 2© 2008 Cisco Systems, Inc. Todos los derechos reservados. Información confidencial de Cisco

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 subredesEs 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 subredesPréstamo de bits para crear subredes

Si se toma prestado 1 bit, 2^1 = 2 subredes.

Subred 1

Red 192.168.1.128-255/25

Máscara: 255.255.255.128

Subred 0

Red 192.168.1.0-127/25

Máscara: 255.255.255.128

Si se toma prestado 1 bit de la porción de host, se crean 2 subredes con la misma máscara de subred.



Subredes en usoSubred 0

Red 192.168.1.0-127/25

Subred 1

Red 192.168.1.128-255/25



Fórmulas de división en subredesCálculo de cantidad de subredes

Cálculo de número de hosts



Creación de cuatro subredesSi se toman prestados 2 bits, se crean 4 subredes. 2^2 = 4 subredes



Creación de ocho subredesSi 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 requeridasCantidad de direcciones de host requeridasFórmula para determinar la cantidad de hosts utilizables

2^n-22^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 direccionesProporcionar y controlar el accesoControlar 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.

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.

C A P Í T U L O

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 abarcaprácticamente todos los modelos teóricos que Einstein garabateó en una servilleta. Lasredes 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 quebautizó con el nombre de Open Systems Interconnection Reference Model o Modelo deReferencia de Interconexión de Sistemas Abiertos. En los entornos de trabajo con redesse le conoce más comúnmente como el modelo OSI (y, con toda probabilidad, sin nisiquiera saber el significado exacto de esta sigla). En 1984, este modelo pasó a ser elestá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ñíasdeben hacer negocios en el mercado internacional. Seguramente habrá visto algu-na vez productos con etiquetas anunciando que cuentan con el certificado ISO9002. Esto significa que cumplen con el conjunto de normas y protocolos que hadesarrollado 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 lossistemas de archivo para CD-ROM.

El modelo OSI divide en siete capas el proceso de transmisión de la información entreequipos informáticos, donde cada capa se encarga de ejecutar una determinada parte delproceso 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 transmitirdatos; los protocolos que, de hecho, sirven como capas o niveles dentro de un conjunto deprotocolos como TCP/IP pueden, por tanto, explicarse de acuerdo con su correlación conel 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 elapartado “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

31

de un nodo a otro de la red. Las pilas de protocolos se asemejan mucho a lascarreras de relevos, pero, en vez de pasarse un testigo, se transmiten paquetes dedatos de un protocolo a otro hasta que éstos revisten la forma adecuada (unasecuencia ú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 dered como IPX/SPX de NetWare o TCP/IP, muchos desconocen la existencia de lasuite 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 lacomunicación entre sistemas. Proporciona las normas básicas empíricas para una serie deprocesos distintos de conexión en red:

• El modo en que los datos se traducen a un formato apropiado para la arquitecturade red que se está utilizando. Cuando se envía un mensaje de correo electrónico oun 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 datosque se transmiten utilizando dicha aplicación tienen que convertirse a un formatomá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. Cuandose 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 mismoque 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 formaen 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 enel direccionamiento físico que proporciona la red. Las redes informáticas utilizanesquemas de direccionamiento lógico, como direcciones IP. Por tanto, dichasdirecciones lógicas tienen que convertirse en las direcciones reales de hardwareque 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ólopermite internarse en los conjuntos de protocolos de red que actualmente se utilizan, sinoque 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.)

32 2 El modelo OSI y los protocolos de red

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 sonla 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 elresto de dispositivos que conforman el entorno físico de la red). Seguramente yahabrá interactuado más de una vez con la capa Física, por ejemplo al ajustar uncable 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óna 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 arribaabajo. La pirámide invertida es uno de los modos que mejor ilustran la estructura de estemodelo, en el que los datos con un formato bastante complejo pasan a convertirse en unasecuencia simple de bits cuando alcanzan el cable de la red. Como verá, las capas vienennumeradas 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 procesoglobal de transmisión de los datos.

FIGURA 2.1El modelo OSI ofrece un modelo teórico que explica el modo en que se desplazan losdatos desde una computadora emisora a otra computadora receptora.

33

Aplicación7

Presentación6

Sesión5

Transporte4

Red3

Enlace de datos2

Física1

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á RecordandoTodos Sus Primeros Años. Y de hecho es imprescindible que tenga siempre presente estemodelo, 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ículosque 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 unaidea 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 lared. El usuario que envía el mensaje utilizará un cliente o programa de correo (comoOutlook o Eudora) como herramienta de interfaz para escribir y enviar el mensaje. Estaactividad del usuario se produce en la capa de aplicación.

Cuando los datos abandonan la capa de aplicación (la capa insertará un encabezado decapa de aplicación en el paquete de datos), éstos pasan por las restantes capas del modeloOSI. 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 unencabezado (los encabezados vienen representados por cuadritos en la Figura 2.2) a losdatos. Puesto que la capa física está integrada por dispositivos de hardware (un cable, porejemplo) 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 depar 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, elusuario 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 asubir por la pila OSI. A medida que los datos van pasando por cada una de las capas, elencabezado 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ónicopara leer el mensaje que ha recibido.

A continuación pasamos a explicar cada una de las capas que componen el modeloOSI, 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 losservicios 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ónsuministra cada uno de estos servicios a los distintos programas de aplicación con los quecuenta el usuario en su computadora. Entre los servicios de intercambio de información


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 comoSMTP ––Simple Mail Transfer Protocol––incluido en TCP/IP), así como aplicacionesespeciales de bases de datos cliente/servidor.

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.2Los datos bajan por la pila OSI de la computadora emisora y suben por la pila OSI de lacomputadora 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 redempieza en realidad en la capa de aplicación) de la capa de aplicación y los convierte a unformato genérico que pueden leer todas las computadoras. Por ejemplo, los datos escritosen 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 laaplicación utilizada en la capa de aplicación) así como de comprimirlos para reducir sutamaño. El paquete que crea la capa de presentación contiene los datos prácticamente conel formato con el que viajarán por las restantes capas de la pila OSI (aunque las capassiguientes irán añadiendo elementos al paquete, lo cual puede dividir los datos en paque-tes más pequeños).

35

Data

Data

Data

Data

Data

Data

Data

A

A

A

A

A

A

P

P

P

P

P

S

S

S

S

T

T

T

N

SD

Data

Data

Data

Data

Data

Data

Data

A

A

A

A

A

A

P

P

P

P

P

S

S

S

S

T

T

T

N

SD

Aplicación

Presentación

Sesión

Transporte

Red

Enlace de datos

Física

Computadora emisora Computadora receptora

Entorno físico de la red

Aplicación

Presentación

Sesión

Transporte

Red

Enlace de datos

Física

➀ ➃

➂

➁

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 deahí 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 computadorasexiste entre ellas una comunicación virtual en la capa de sesión. Lo cual es deltodo lógico, ya que ésta es la capa que controla la comunicación entre ambascomputadoras por el entorno físico de la red (ya sean cables coaxiales, de partrenzado 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 seestablece entre ambos nodos (véase la Figura 2.3).

FIGURA 2.3La capa de sesión proporciona el enlace de comunicación entre dos computadoras quese están comunicando.

Una vez establecida la sesión entre los nodos participantes, la capa de sesión pasa aencargarse 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 fallay se pierde la comunicación entre los nodos, cuando después se restablezca la sesión sólotendrá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.


Estación de trabajoServidor

La estación de trabajo envíauna petición de servicio al servidor

El servidor accede a la petición

Comunicaciones enla capa de sesión

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 puedencomunicarse entre sí si utilizan el mismo conjunto de protocolos de red. Esto es loque explica que una máquina UNIX, un Macintosh o un PC que esté ejecutandoWindows utilicen el TCP/IP para comunicarse en Internet. Un ejemplo en el quedos computadoras no podrían comunicarse sería aquél en que una computadoraejecutara 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 proporcionanun entorno donde las computadoras conectadas se ponen de acuerdo sobre los parámetrosrelativos 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 detransferencia.

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 deseahablar. La persona que llama y la que se encuentra al otro lado del teléfono mantienen unaconexión directa. Y, cuando la conversación termina, ambos se ponen de acuerdo para darpor 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 decorreo 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 unpermiso 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 queestablecen una comunicación; los datos no sólo deben entregarse sin errores, sino ademásen 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 redque 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.

37

LOS SERVICIOS DE LA CAPA DE APLICACIÓN PERMITEN QUE LAS APLICACIONESDE 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 delmodelo OSI proporciona el servicio que permite mover dicho archivo desde lacomputadora cliente hasta el volumen de red pertinente. Esta transmisión estotalmente transparente para el usuario.

La comunicación también se establece entre computadoras del mismo nivel (el emisory el receptor); la aceptación por parte del nodo receptor se recibe cuando el nodo emisorha enviado el número acordado de paquetes. Por ejemplo, el nodo emisor puede enviar deun solo golpe tres paquetes al nodo receptor y después recibir la aceptación por parte delnodo receptor. El emisor puede entonces volver a enviar otros tres paquetes de datos deuna sola vez.

Esta comunicación en la capa de transporte resulta muy útil cuando la computadoraemisora manda demasiados datos a la computadora receptora. En este caso, el nodoreceptor tomará todos los datos que pueda aceptar de una sola vez y pasará a enviar unaseñal de “ocupado” si se envían más datos. Una vez que la computadora receptora hayaprocesado 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 entraday salida de información. Cuando los datos bajan por la pila de protocolos en unacomputadora 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óngené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 redLa 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 elintercambio 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 convertirseen direcciones físicas (las direcciones de hardware de la NIC, la Tarjeta de Interfaz paraRed, para esa computadora específica).


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 largode este libro.

VÉASE TAMBIÉN

➤ Encontrará una explicación más pormenorizada de la capa de red en los siguientes capítulos. Paraobtener una rápida introducción sobre el modo en que operan los routers en la capa de red, consulteel 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 quese 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, eidentifica 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 asignadaa la tarjeta de interfaz para red en una computadora que ejecuta Windows 98.

FIGURA 2.4Cada 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 ambasestrategias de comunicación, la que precisa de una conexión y la que no, para des-

39

plazar los datos por la red. Por lo general, en la capa de sesión opera más de unprotocolo 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 queoperan 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 algunodurante su transferencia.

Una vez más, y tal y como dijimos anteriormente, el tipo de trama que genera la capade 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 laTabla 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 deun encabezado que la describe, de los datos que incluye, y de la información referente ala 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), queno sólo definen el tipo de trama de que se trata (en este caso, Ethernet), sino que tambiéncontribuyen a que la trama llegue a la computadora receptora. (Para más informaciónacerca de las especificaciones IEEE 802, consulte la nota titulada “Tramas Ethernet”.)

FIGURA 2.5La 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.


Preámbulo

CAMPOS LLC

Destino Fuente Longitud DSAP SSAP CTRL Datos FCS

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: indicaa 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 detalleen 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 elapartado “Las subcapas del enlace de datos” incluido en este mismo capítulo.

La capa físicaEn 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 capafí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 esla 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 Windows95/98, haga clic en el menú Inicio y después en Ejecutar. En el cuadro de diálogoEjecutar, escriba winipcfg y después haga clic en Aceptar. Aparecerá el cuadro dediálogo Configuración IP donde se encuentra la dirección de la tarjeta de red. Enuna 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 elbotó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.

41

Las subcapas del enlace de datosAntes 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ónIEEE 802 dividía la capa de enlace de datos en dos subcapas, el Control Lógico delEnlace (Logical Link Control o LLC) y el Control de Acceso al Medio (Media AccessControl o MAC).

La subcapa de Control Lógico del Enlace establece y mantiene el enlace entre lascomputadoras emisora y receptora cuando los datos se desplazan por el entorno físico dela red. La subcapa LLC también proporciona Puntos de Acceso al Servicio (ServiceAccess 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 capassuperiores del conjunto de protocolos OSI dentro de un determinado nodo receptor. Laespecificació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, dehecho, al entorno físico de la red y enviar datos. La especificación 802 divide a su vez lasubcapa 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.

FIGURA 2.6La capa de enlace de datos está compuesta por dos subcapas: la subcapa LLC y la subca-pa MAC.


Capa de enlace de datos

Subcapa LLC

IEEE 802.2

Subcapa MAC

IEEE 802.3IEEE 802.3IEEE 802.5IEEE 802.12

Protocolos de red del mundo realDespué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 conformanel modelo OSI, podemos pasar a explicar algunos de los conjuntos de protocolos de redmás utilizados hoy en día y cotejar las capas que los integran con las del modelo OSI. Deesta forma, lograremos una visión clara y sencilla del modo en que operan estas pilas deprotocolos 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 dered del modelo OSI. Estos protocolos son de suma importancia ya que contribuyen aencaminar los paquetes en una conexión entre redes (algo sobre lo que versa gran parte deeste libro).

NetBEUINetBEUI (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 deEntrada/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 detransporte y red de OSI, necesita funcionar con NetBIOS, que opera en la capa de sesióndel 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). Elredirector opera en la capa de aplicación y hace que una computadora cliente percibatodos 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 nivelentre los redirectores incluidos en las máquinas cliente y servidor de la red. El Bloque deMensajes 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. Estasigla procede de la expresión inglesa Media Access Control o Control de Acceso alMedio, y es una de las subcapas de la capa de enlace de datos. Las direcciones dehardware 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 dedireccionamiento lo desarrolló en su día el Instituto de Ingenieros Eléctricos yElectrónicos (IEEE). De acuerdo con este esquema, cada dirección reviste la formade una cadena de 48 bits escrita en formato hexadecimal. Un ejemplo de direc-ción MAC sería 00-00-B3-83-B3-3F.

43

Aunque resulta un excelente protocolo de transporte de bajo coste, NetBEUI no es unprotocolo que pueda encaminarse por medio de routers, por lo que no puede utilizarse enlas interconexiones de redes. Por tanto, si bien NetBEUI es una opción de protocolo dered 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 todoslos requisitos especificados por el IEEE (y que se refieren más adelante en estemismo capítulo).

TCP/IPA 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 distintasplataformas de software (Windows, UNIX, etc.) y casi todos los sistemas operativos de redlo 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 lasdistintas 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 nouna imagen fiel y exhaustiva de todos los protocolos que incluye). La Tabla 2.2 describelos protocolos que aparecen en la figura. En el Capítulo 10, “Conceptos fundamentales deTCP/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 proporcionauna interfaz y servicios para la transferencia de archivos en la red.

SMTP El Simple Mail Transport Protocol o Protocolo Simple de Transferencia de Correoproporciona servicios de correo electrónico en las redes Internet e IP.



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 lascomputadoras emisora y receptora de forma parecida al desarrollo de las llamadastelefó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 direccionamientoque se produce en las redes TCP/IP y proporciona un protocolo orientado a la capade red sin conexión. Funciona de forma semejante a una carta con remite echadaal buzón y después entregada a su destinatario.

ARP El Address Resolution Protocol o Protocolo de Resolución de Direcciones hacecorresponder las direcciones IP con las direcciones MAC de hardware. ARP seexplica en más detalle en el Capítulo 10.

FIGURA 2.7TCP/IP es un amplio conjunto de protocolos que utiliza una serie de protocolos miembroen varias de las capas del modelo OSI.

45

Aplicación

Presentación

Sesión

Transporte

Red

Enlace de datos

Física

FTP SMTP

Los protocolosmiembro de lapila de protocolosTCP/IP, comoFTP, se solapancon más de unacapa delmodelo OSI.

TCP UDP

IPARP

Controladores de tarjetas de red

Entorno físico de la red (cables, hubs, etc.)

Otros protocolos,como TCP o IP,se correspondendirectamente conuna de las capasdel modelo OSI.

ESPECIFICACIONES 802 DEL IEEE

Las especificaciones IEEE 802 proporcionan categorías que definen la Capa delEnlace 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 quese 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 deuna dirección es del tipo 129.30.20.4, donde cada uno de los cuatro valores decimalesseparados por un punto representa 8 bits de información binaria. Las direcciones IP seexplican en más detalle en el Capítulo 10.

Dada la importancia de TCP/IP en las conexiones entre redes y la complejidad queentrañ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/SPXIPX/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


carga general que TCP/IP necesita. IPX/SPX puede utilizarse tanto en redes pequeñascomo 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 modeloOSI. La Tabla 2.3 describe brevemente cada uno de los protocolos que lo componen.

FIGURA 2.8IPX/SPX es un conjunto de protocolos eficaz que se utiliza tanto en redes grandes comopequeñ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. Dichodepartamento necesitaba un conjunto de protocolos que pudieran utilizarse encualquier 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 elDepartamento, que licitaba todos sus proyectos y servicios. De ahí que de formacoloquial se conozca TCP/IP como protocolo de baja puja, ya que surgió a raíz dela práctica del gobierno estadounidense por pujar.

47

Aplicación

Presentación

Sesión

Transporte

Red

Enlace de datos

Física

SAP NCP

SPX

IPX

Los protocolosSAP y NCP delconjunto IPX/SPXgestionan, de hecho,las tareas de trescapas OSI:aplicación,presentacióny sesión.

IPX es un protocolo sinconexión y opera en lascapas de transportey red. SPX, que es unprotocolo orientado ala conexión, opera enla capa de transporte.

Controladores de interfaz para red

Entorno físico

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 losservidores de archivo y los servidores de impresora de NetWare para anunciar ladirección del servidor.

NCP El NetWare Core Protocol o Protocolo de Núcleo NetWare gestiona las funcionesde 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 Secuenciadode Paquetes es un protocolo de transporte orientado a la conexión.

IPX El Internetwork Packet Exchange Protocol o Protocolo de Intercambio de Paquetesentre 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 esteconjunto de protocolos dentro de una conexión entre redes. Veremos el encaminamiento deIPX/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 conectadasen 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 delmodelo OSI), TCP/IP incorpora varios protocolos que gestionan a un tiempo lastareas de varias capas OSI. Por ejemplo, FTP gestiona las tareas de las capas OSI deaplicación, presentación y sesión. De ahí que en la Figura 2.7, el círculo de FTPenglobe 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”.

AppleTalkAunque muchos administradores de red no consideran AppleTalk un protocolo de red

corporativo o de interconexión, AppleTalk permite el encaminamiento de datos mediante


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 computadorasMacintosh 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 incluirAppleTalk como otro protocolo encaminado en la red corporativa.

En el Capítulo 1 hablábamos de AppleTalk como arquitectura de red, pero lo cierto esque también se trata de un conjunto de protocolos. La Figura 2.9 ofrece la correlaciónentre 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 puenteo 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 elconjunto internacional de computadoras heterogéneas que lo conforman.

Intranet: una red corporativa interna que sólo funciona en el entorno de laempresa (sin conexión a Internet) pero que utiliza protocolos de Internet, como elProtocolo Simple de Transporte de Correo (SMTP) y el Protocolo de Transporte deHipertexto (HTP), el mismo protocolo que utilizan los navegadores web. Unaextranet 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 ygestiona 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 corresponderlos 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 laszonas AppleTalk y hace corresponder los nombres de zonas con las direccionesde red.

49


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

FIGURA 2.9AppleTalk 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 protocolosviene encaminado por un router de Cisco se tratarán en el Capítulo 13, “EncaminarAppleTalk”.


Aplicación

Presentación

Sesión

Transporte

Red

Enlace de datos

Física

AppleTalk

AFP

ZIP

NBP

AARP DDP

Controladores de interfaz para red

Entorno físico

El conjunto de protocolosAppleTalk se componede varios protocolos, quese corresponden conalgunas de las capasdel modelo OSI.AppleTalk, por ejemplo,se corresponde con lascapas de aplicacióny presentación de OSI.

¿DÓNDE ESTÁN LOS PROTOCOLOS DE ENCAMINAMIENTO?

Seguramente ya habrá reparado en que muchas de las figuras que muestran lacorrelación entre conjuntos de protocolos y las capas del modelo OSI no incluíanprotocolos de encaminamiento. Obviamente, cada conjunto de protocolos cuentacon un protocolo de encaminamiento predeterminado; por ejemplo, RIP es el pro-tocolo predeterminado de TCP/IP y el Protocolo de Mantenimiento de la Tabla esel que utiliza por defecto AppleTalk. Estos protocolos se tratan en más detalle enlos 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 encaminanen un router de Cisco, consulte el Capítulo 13.

51

ingenieria de sistemas - obtencion.fap.mil.pe · a. reseÑa histÓrica a.1 la presente norma...

Documents