Ingeniería de Software y Sistemas Operativos

INSTRUCTIVOS DE PRACTICAS UGM
S. E. C.
UNIVERSIDAD DEL GOLFO DE MEXICO, A. C.
NOMBRE DEL ALUMNO
SEMESTRE
GRUPO
1
Licenciatura en Informática Ingeniería de Software y Sistemas Operativos
S. E. C.
UNIVERSIDAD DEL GOLFO DE MEXICO, A. C.
INSTRUCTIVO DE PRACTICAS
LICENCIATURA EN INFORMATICA
INGENIERIA DE SOFTWARE
SISTEMAS OPERATIVOS
Semestre V
AUTOR(ES)
L.I. ELIZABETH RODRÍGUEZ GUZMÁN
SISTEMAS OPERATIVOS
ING. RICARDO CARRERA HERNANDEZ
2
Ing. Luis Reyes Larios

Rector
Ing. Alfonso Juárez Jiménez

Secretario Académico
Ing Andrés Juárez Jiménez

Secretario de Administración y Finanzas
Ing. Prudencio Reyes Larios

Secretario de Asuntos Universitarios
Lic. María Isabel López Islas

Directora General del Área Académica
Ing. Jaime Rodrigo Sandoval Guzmán

Subdirector de Enseñanza
3
INDICE
Práctica No. Nombre Página
Ingeniería de Software
1 Aplicaciones de Software 5
2 Paradigmas de la Ingeniería de Software 9
3 Métricas del Proyecto 13
4 Estimación de Costos 16
5 Principio del Análisis 19
6 Especificaciones de los Requisistos de Software 22
7 Diseño e Ingeniería de Software y Proceso de Diseño 26
8 Diseño de Datos 30
9 Optimización del Diseño Arquitectónico y Diseño de la Interfaz 33
Sistemas Operativos
1 Análisis de los Estados de los Procesos 36
2 Análisis de los Semáforos en la Sincronización de los Procesos 40
3 Análisis de Monitores en la Concurrencia de Procesos 43
Créditos 46
4
PRACTICA 1
APLICACIONES DE SOFTWARE
OBJETIVO
El alumno debe ser capaz de clasificar las categorías genéricas del software.
DESCRIPCIÓN BASICA
El software puede aplicarse en cualquier situación en la que se haya definido previamente un

conjunto específico de pasos procedimentales.
Algunas veces es difícil desarrollar unas categorías genéricas con significado para las
aplicaciones de software. Conforme crece la complejidad del software, es más difícil establecer
comportamientos nítidos separados. Las siguientes áreas del software indican la amplitud de las
potencias aplicacionales.
Software de Sistemas. Es una colección de programas escritos para servir a otros programas. El
área del software de sistemas se caracteriza por la fuerte interacción con el hardware de la
computadora; su gran utilización por múltiples usuarios; la operación concurrente que requiere
planificación, comparición de recursos y justificada gestión de procesos; estructuras de datos
complejas y múltiples interfaces externas.
Software de Tiempo Real. Este software mide, analiza, controla sucesos del mundo real,
conforme ocurren se llama tiempo real. Los elementos del software de tiempo real incluyen un
componente de acumulación de datos que recolecta y formatea la información de un entorno
externo, un componente de análisis que transforma la información según requiera la aplicación, un
componente de control/salida que responda al entorno externo y un componente de
monitorización que coordina a todas los demás componentes, de forma que pueda mantenerse
la respuesta en tiempo real. Un sistema de tiempo real debe responder dentro de una ligadura
estricta de tiempo (típicamente en el rango de 1 milisegundo a 1 minuto).
Software de Gestión. El proceso de información comercial constituye la mayor de las áreas de
aplicación de software. Los sistemas de gestión acceden a uno o más bases de datos grandes
que contienen información comercial. Las aplicaciones en esta área reestructuran los datos
existentes en orden a facilitar las operaciones comerciales o gestionar la toma de decisiones.
Software de Ingeniería y Científico. Este software se ha caracterizado por los algoritmos de
manejo de números. Las aplicaciones van desde la astronomía a la vulcanología, desde la
biología molecular a la fabricación automática.
Software de Computadoras Personales. El mercado del software de las computadoras
personales ha gestionado en las ultimas décadas. El procesamiento de las palabras, las hojas de
calculo, los gráficos por computadora, aplicaciones financieras y comerciales son solo unos
cuantos de los cientos de aplicaciones. De hecho el software de las computadoras personales
continuara representando uno de los diseños del software más innovativos en el campo del
software.
5
Software de Inteligencia Artificial. Hace uso de algoritmos no numéricos para resolver problemas
complejos que no son adecuados para el calculo o análisis directo. Actualmente, el área más
activa de la I.A. es la de los sistemas expertos; otras áreas para ese software es el reconocimiento
de patrones (imágenes y voces), prueba de teoremas y juegos.
MATERIAL Y EQUIPO.
1 Libreta
1 Lápiz
1 Bolígrafo
- Material bibliográfico y revistas
1 Computadora (buscar por Internet)
DESARROLLO DE LA PRACTICA:
1.- Investigar en revistas y diferentes locales donde se vende software los nombres y características
de software disponible; así como el navegar en Internet para buscar los diferentes tipos de
software y tener más información sobre los mismos.
2.- Una vez recolectada la información. Dentro del salón de clases, relacionar a que clasificación del
software corresponden los nombres que investigaron y por que.
3.- Llenar la tabla 1 en base a la información encontrada.
Nombre Características Clasificación Por qué
Tabla 1
6
ESQUEMAS
OBSERVACIONES
_________________________________________________________________________________
_________________________________________________________________________________
_________________________________________________________________________________
_________________________________________________________________________________
_________________________________________________________________________________
_________________________________________________________________________________
_________________________________________________________________________________
_________________________________________________________________________________
CUESTIONARIO
1.- _______________________________________________________________________________
2.- _______________________________________________________________________________
3.- _______________________________________________________________________________
4.- _______________________________________________________________________________
5.- _______________________________________________________________________________
7
CONCLUSIONES
_________________________________________________________________________________
_________________________________________________________________________________
_________________________________________________________________________________
_________________________________________________________________________________
_________________________________________________________________________________
_________________________________________________________________________________
_________________________________________________________________________________
_________________________________________________________________________________
CRITERIO DE EVALUACION
BIBLIOGRAFIA
PREEMAN, Roger S.; Ingeniería de Software. Un enfoque práctico. Editorial Mc Graw Hill, España,
1994
Revistas PC Magazine, Byte, PC Computing
8
PRACTICA 2
PARADIGMAS DE LA INGENIERIA DE SOFWARE
OBJETIVO
El alumno debe ser capaz de escoger y aplicar correctamente los paradigmas de la Ingeniería
de Software en el desarrollo de un software.
DESCRIPCIÓN BASICA
La Ingeniería de Software está compuesta de pasos que abarcan los métodos, herramientas y
procedimientos para el desarrollo del Software. Estos pasos se denominan frecuentemente
“Paradigmas de la Ingeniería de Software”. Un paradigma para la Ingeniería de Software se elige
basándose en la naturaleza del proyecto y de la aplicación, los métodos y herramientas a usar y los
controles y entregas requeridos. Se han tratado ampliamente los paradigmas que se describen a
continuación:
Ciclo de vida clásico: llamado “el modelo de cascada”, exige un enfoque sistemático, secuencial,
del desarrollo del Software que comienza en el nivel de sistemas y progresa a través del análisis,
diseño, codificación, prueba y mantenimiento. Este paradigma abarca las siguientes actividades:
• Ingeniería y análisis de sistemas
• Análisis de los requerimientos de software
• Codificación
• Prueba
• Mantenimiento
Construcción de prototipos: generalmente un cliente definirá un conjunto de objetivos generales
para el software, pero no identificará los requerimientos detallados de entrada, procedimientos o
salida. En algunas ocasiones el programador no puede estar seguro de la eficiencia de un
algoritmo, la adaptabilidad de un sistema operativo o la forma en que debe realizarse la
interacción hombre máquina. En estas y otras muchas situaciones, puede ser mejor método de
Ingeniería de Software realizar un prototipo.
• Recolección de requerimientos
• “Diseño rápido”
• Construcción de prototipo
• Evaluar y refinar los requerimientos
Técnicas de cuarta generación (T4G): se orientan hacia la habilidad de especificar software a un
nivel que sea más próximo al lenguaje natural o en una notación que proporcione funciones
significativas.
Un entorno para el desarrollo del software que soporte el paradigma T4G incluye algunas o todas
las siguientes herramientas: lenguajes procedimentales para consulta a la base de datos,
generación de informes, manipulación de datos, interacción y definición de pantallas y generación
de códigos; capacidades gráficas de alto nivel y capacidad de hoja de cálculo. Este paradigma
abarca las siguientes actividades:
• Recolección de requerimientos
• Estrategia de “diseño”
• Implementación usando L4G
• Producto
9
Combinación de paradigmas: en muchos casos, los paradigmas pueden y deben combinarse de

forma que puedan utilizarse las ventajas de cada uno en un único proyecto. No hay necesidad de
ser dogmático en la elección de los paradigmas para la Ingeniería de Software; la naturaleza de la
aplicación debe dictar el método a elegir. Mediante la combinación de paradigmas, el todo puede
ser mejor que la suma de las partes. Este paradigma abarca las siguientes actividades:
• Recolección de prototipos
Aplicar L4G
• Construcción de prototipos
Prototipo
• Producto productivo
MATERIAL Y EQUIPO
1 Lápiz
1 Bolígrafo
Hojas blanca o libreta
Material bibliográfico
DESARROLLO DE LA PRACTICA
1.- Tomando como base la información proporcionada por parte del negocio o empresa que tenga
software implantado (para ver cual software utilizan), el alumno debe anotar e identificar cual de
los paradigmas de software utiliza la empresa o negocio para poder familiarizarse y
posteriormente poder desarrollar un software.
2.- Contestar lo siguiente y darlo a conocer en clases una vez analizado lo anterior.
1. Nombre de la Empresa o Negocio
___________________________________________________________________________
___________________________________________________________________________
___________________________________________________________________________
___________________________________________________________________________
___________________________________________________________________________
___________________________________________________________________________
___________________________________________________________________________
___________________________________________________________________________
___________________________________________________________________________
___________________________________________________________________________
2. ¿Cuál de los paradigmas de Software aplican?

___________________________________________________________________________
___________________________________________________________________________
___________________________________________________________________________
___________________________________________________________________________
___________________________________________________________________________
___________________________________________________________________________
___________________________________________________________________________
___________________________________________________________________________
___________________________________________________________________________
___________________________________________________________________________
10
ESQUEMAS
OBSERVACIONES
_________________________________________________________________________________
_________________________________________________________________________________
_________________________________________________________________________________
_________________________________________________________________________________
_________________________________________________________________________________
_________________________________________________________________________________
_________________________________________________________________________________
_________________________________________________________________________________
CUESTIONARIO
1.- _______________________________________________________________________________
2.- _______________________________________________________________________________
3.- _______________________________________________________________________________
4.- _______________________________________________________________________________
5.- _______________________________________________________________________________
11
CONCLUSIONES
_________________________________________________________________________________
_________________________________________________________________________________
_________________________________________________________________________________
_________________________________________________________________________________
_________________________________________________________________________________
_________________________________________________________________________________
_________________________________________________________________________________
_________________________________________________________________________________
BIBLIOGRAFIA
PREEMAN, Roger S.; Ingeniería de Software. Un enfoque práctico. Editorial Mc Graw Hill, España,
1994.
12
PRACTICA 3
METRICAS DEL PROYECTO
OBJETIVO
El alumno debe ser capaz de interpretar la importancia de la medición de un proyecto de

software, así como calcular la métrica orientada al tamaño y la métrica orientada a la función ya que
es fundamental para cualquier disciplina de ingeniería.
La medición. La medición permite que los gestores y profesionales mejoren el proceso del
software: ayudan en la planificación, seguimiento y control de un proyecto de software; y evalúan
la calidad del producto (software) que se produce. Las mediciones de los atributos específicos del
proceso, del proyecto y del producto se utilizan para calcular las métricas del software. Estas
métricas pueden analizarse para proporcionar indicadores que guían acciones de gestión y
técnicas.
La métrica del proceso. La métrica del proceso permite que una organización tome una visión
estratégica proporcionando mayor profundidad de la efectividad de un proceso de software. Las
métricas del proyecto son tácticas. Estas permiten que un gestor de proyectos adapte el enfoque
a los flujos de trabajo del proyecto y a proyectos técnicos en el tiempo real.
La métrica orientada al tamaño y función. Las métricas orientadas tanto al tamaño como a la
función se utilizan en toda la industria. Las métricas orientadas al tamaño hace uso de la línea de
código como factor estandarizador de otras medidas, como persona-mes o defectos. El punto de
función proviene de las medidas de dominio de información y de una evaluación subjetiva de la
complejidad del problema.
Las métricas de calidad de software, como la métricas de productividad se encuentran en el
proceso, tanto en el proyecto como en el producto. Desarrollando y analizando una línea base de
métrica de calidad, una organización puede actuar como objeto de corregir esas áreas del proceso del
software que es la causa de los defectos del software.
La medición produce cambios culturales. La recopilación de datos, el cálculo de métricas y la
evaluación de métricas son tres pasos que deben implementarse al comenzar un programa de
métrica.
MATERIAL Y EQUIPO
1 Libreta
1 Lápiz
1 Bolígrafo
Material bibliográfico y revistas
13
I. Se le presentará al alumno un sistema (opción libre) en el cual debe calcular:

1.- Métrica orientada al tamaño.
2.- Métrica orientadas a la función.
ESQUEMAS
OBSERVACIONES
_________________________________________________________________________________
_________________________________________________________________________________
_________________________________________________________________________________
_________________________________________________________________________________
_________________________________________________________________________________
_________________________________________________________________________________
_________________________________________________________________________________
_________________________________________________________________________________
14
CUESTIONARIO
1.- _______________________________________________________________________________
2.- _______________________________________________________________________________
3.- _______________________________________________________________________________
4.- _______________________________________________________________________________
5.- _______________________________________________________________________________
CONCLUSIONES
_________________________________________________________________________________
_________________________________________________________________________________
_________________________________________________________________________________
_________________________________________________________________________________
_________________________________________________________________________________
_________________________________________________________________________________
_________________________________________________________________________________
_________________________________________________________________________________
BIBLIOGRAFIA
PREEMAN, Roger S.; Ingeniería de Software. Un enfoque práctico. Editorial Mc Graw Hill, 4ª edición
España, 1998
FAIRLEY, Richard; Ingeniería de Software. Editorial Mc Graw Hill, 1ª edición, 1998
15
PRACTICA 4
ESTIMACION DE COSTOS
OBJETIVO
Al termino de esta practica el alumno debe tener una idea general de la importancia que tiene
la planeación adecuada de la estimación de costo de un proyecto de software como una fase para
definir los objetivos, necesidades y restricciones, y ser capaz de aplicar su propio proyecto.
DESCRIPCION BASICA
Estimación del proyecto del software. La estimación del costo del software nunca será una ciencia
exacta. Son demasiadas las variables-humanas, técnicas de entorno, políticas que pueden afectar
al costo final del software y al esfuerzo aplicado para desarrollarlo. Sin embargo, la estimación del
proyecto de software puede dejar de ser un oscuro arte para convertirse en una serie de pasos
sistemáticos que proporcionen estimaciones con un grado de riesgo aceptable.
El planificador de proyecto de software tiene que estimar tres cosas antes de que
comience el proyecto: cuánto durará, cuánto esfuerzo requerirá y cuánta gente estaría implicada.
Además el planificador debe predecir los recursos (de hardware y de software) que va requerir, y
el riesgo implicado.
El enunciado de ámbito ayuda a desarrollar estimaciones mediante una o varias de las
técnicas siguientes: descomposición, modelos empíricos y herramientas automáticas. Las
técnicas de descomposición requieren un esbozo de las principales funciones del software,
seguido de estimaciones del numero de LDC (Líneas de Código) o del PF (Punto de Función), o
del número de personas-mes requeridas para implementar cada funcion.
El Modelo COCOMO (Modelo Constructivo de Costo). La jerarquía de modelos esta constituida

por los siguientes:
• Modelo 1. El modelo COCOMO básico calcula el esfuerzo (y el costo) del desarrollo del
software en función del tamaño del programa, expresado en las líneas de código (LDC).
• Modelo 2. El modelo COCOMO intermedio calcula el esfuerzo del desarrollo de software en
función del tamaño del programa que incluye la evaluación subjetiva del producto, del
hardware, del personal y de los atributos del proyecto.
• Modelo 3. El modelo COCOMO avanzado incorpora todas la características de la versión
intermedia y lleva a cabo una evaluación del impacto de los conductores de costo en cada
fase (análisis, diseño, etc.) del proceso de ingeniería de software.
MATERIAL Y EQUIPO
1 Libreta
1 Lápiz
1 Bolígrafo
16
1.- Presentar un sistema ya implantado (por ejemplo uno de ventas, control escolar)
2.- Dar a conocer:
• PF
• LDC
• Personas –mes, y
• Utilizar el modelo COCOMO (modelo básico)
3.- Recordar que las formulas aplicar son:
E=ab KLDCbb
D=cb Edb
N= E/D
Donde:
E = Esfuerzo persona/mes
D = Tiempo de desarrollo en meses
KLDC = El número estimado de líneas de código distribuidas (en miles)
ab = Coeficientes (obtenidos de la parte orgánica, semiacoplado, empotrado)
bb = Exponente (obtenidos de la parte orgánica, semiacoplado, empotrado)
N = Número de personas para el proyecto
ESQUEMAS
17
OBSERVACIONES
_________________________________________________________________________________
_________________________________________________________________________________
_________________________________________________________________________________
_________________________________________________________________________________
_________________________________________________________________________________
_________________________________________________________________________________
_________________________________________________________________________________
_________________________________________________________________________________
CUESTIONARIO
1.- _______________________________________________________________________________
2.- _______________________________________________________________________________
3.- _______________________________________________________________________________
4.- _______________________________________________________________________________
5.- _______________________________________________________________________________
CONCLUSIONES
_________________________________________________________________________________
_________________________________________________________________________________
_________________________________________________________________________________
_________________________________________________________________________________
_________________________________________________________________________________
_________________________________________________________________________________
_________________________________________________________________________________
_________________________________________________________________________________
BIBLIOGRAFIA

España, 1998
Dirección en Internet: http://sunset.usc.edu/COCOMO2.0/cocomo.html
18
PRACTICA 5
PRINCIPIOS DEL ANALISIS
OBJETIVO
El alumno debe ser capaz de aplicar el análisis adecuado en el problema el cual va a

automatizar (implantar un sistema).
DESCRIPCION BASICA
Para el éxito de un desarrollo de software es esencial una comprensión total de los requisitos de
software. No importa lo bien diseñado y codificado que esté el programa si no se ha analizado
correctamente, pues defraudará al usuario y frustrará al desarrollador.
La tarea del análisis es un proceso de descubrimientos, refinamiento, modelado y especificación.
Se refina en detalle el ámbito del software, inicialmente establecido por el ingeniero de sistemas y
refinado durante la planificación temporal del proyecto de software. Se crean modelos de los
requisitos de datos, flujo de información y control, y del comportamiento operativo. Se analizan
soluciones alternativas y se asignan a diferentes elementos del software.
El análisis y la especificación de requisitos puede parecer un área relativamente sencilla, pero las
apariencias engañan. El contenido de comunicación es muy denso. Abundan las ocasiones para
las malas interpretaciones o falta de información. Es muy probable que haya ambigüedad.
Análisis de requisitos, es una tarea de ingeniería del software que cubre el hueco entre la
definición del software a nivel sistema y el diseño del software. El análisis de requisitos permite al
ingeniero de sistemas especificar la función y el rendimiento del software indica la interfaz del
software con otros elementos del sistema y establece las restricciones que debe cumplir el
software. El análisis de requisitos de software puede dividirse en cinco áreas de esfuerzo:
(1) Reconocimiento del problema
(2) Evaluación y síntesis
(3) Modelado
(4) Especificación y
(5) Revisión
Técnicas de comunicación. El análisis de requisitos del software siempre empieza con la
comunicación entre dos o más partes. Un usuario tiene un problema que pretende sea resuelto
con una solución basada en computadora.
Cada método de análisis tiene su propio punto de vista. Sin embargo todos los métodos de
análisis se relacionan por un conjunto de principios operativos:
1. Debe representarse y entenderse el dominio de información de un problema.
2. Deben definirse las funciones que debe realizar el software.
3. Debe representarse el comportamiento del software (como consecuencia de acontecimientos
externos).
4. Deben dividirse los modelos que representan información, función y comportamiento de
manera que se descubran los detalles por capas (o jerárquicamente).
5. El proceso de análisis debe ir desde información esencial hasta el detalle de implementación.
19
MATERIAL Y EQUIPO
1 Libreta
1 Lápiz
1 Bolígrafo
1.- Entender el problema antes de empezar a crear el modelo del análisis.

2.- Desarrollar prototipos que permitan entender cómo será la interacción hombre-máquina.
3.- Registrar el origen y la razón de cada requisito.
4.- Usar múltiples planteamientos de requisitos.
5.- Dar prioridad a los requisitos.
6.- Trabajar para eliminar la ambigüedad.
7.- Presentar todo el problema por escrito.
8.- Dar a conocer en qué se va a plantear el sistema, ya sea:
a) Institución
b) Negocio
c) Empresa
d) Otras
9.- Dar a conocer cuáles son las preguntas que se aplicarán al usuario al que se implantará el
sistema. ¿Cuál fue la comunicación entre ellos?
10.- ¿Cuál es la conclusión?
ESQUEMAS
20
OBSERVACIONES
_________________________________________________________________________________
_________________________________________________________________________________
_________________________________________________________________________________
_________________________________________________________________________________
_________________________________________________________________________________
_________________________________________________________________________________
_________________________________________________________________________________
_________________________________________________________________________________
CUESTIONARIO
1.- _______________________________________________________________________________
2.- _______________________________________________________________________________
3.- _______________________________________________________________________________
4.- _______________________________________________________________________________
5.- _______________________________________________________________________________
CONCLUSIONES
_________________________________________________________________________________
_________________________________________________________________________________
_________________________________________________________________________________
_________________________________________________________________________________
_________________________________________________________________________________
_________________________________________________________________________________
_________________________________________________________________________________
_________________________________________________________________________________
BIBLIOGRAFIA

España, 1998
21
PRACTICA 6
ESPECIFICACIONES DE LOS REQUISITOS DE SOFTWARE
OBJETIVO
El alumno debe se capaz de aplicar la especificación de requisitos del software necesario

sobre el resultado del análisis en la práctica anterior, así como la revisión esencial de la misma.
DESCRIPCIÓN BASICA
La especificación de los requisitos de software se produce en la culminación de la tarea de

análisis. La función y rendimientos asignados al software como parte de la ingeniería de sistemas se
refinan estableciendo una completa descripción de la información, una descripción detallada de la
función y del comportamiento, una indicación de los requisitos del rendimiento y restricciones del
diseño, criterios de validación apropiados, otros datos pertinentes a los requisitos.
El esquema de especificación de los requisitos del software está formado por:
Introducción. La introducción establece las metas y objetivos del software, describiéndolo en el
contexto del sistema basado en computadoras. De hecho la introducción puede no ser más que el
alcance del software en el documento de planificación.
Descripción de la información. Proporciona una detallada descripción del problema que el
software va a resolver. Se documenta el contenido de la información y sus relaciones, flujo y
estructura. Se describen las interfaces hardware, software y humanas para los elementos
externos del sistema y para las funciones internas del software.
Descripción funcional. En la descripción funcional se describen todas las funciones requeridas
para solucionar el problema. Se proporciona una descripción del proceso de cada función;
establecen y justifican las restricciones del diseño; se establecen las características del
rendimiento; y se incluye uno o más diagramas para representar gráficamente la estructura global
del software y las interacciones entre las funciones del software y otros elementos del sistema. La
sección de las especificaciones, descripción del comportamiento examina la operativa del
software como consecuencia de acontecimientos externos y características de control generadas
internamente.
Nota: Observar la tabla 1.

Esquema de especificaciones de requisitos de software.
I. Introducción
A. Referencias del sistema
B. Descripción general
C. Restricciones del proyecto de software
II. Descripción de la información
A. Representación del contenido de la información
B. Representación del flujo de la información
1. Flujo de datos
2. Flujo de control
22
III. Descripción funcional

A. Participación funcional
B. Descripción funcional
1. Descripción del procedimiento
2. Restricciones/limitaciones
3. Requisitos del rendimiento
4. Restricciones de diseño
5. Diagramas de soporte
C. Descripción del control
1. Especificación del control
2. Restricciones de diseño
IV. Descripción del comportamiento
A. Estados del sistema
B. Eventos y acciones
V. Criterios de validación
A. Límites del rendimiento
B. Clases de pruebas
C. Respuesta esperada del software
D. Consideraciones especiales
VI. Bibliografía
VII. Apéndice
Tabla 1
Revisión de la especificación. La revisión de la especificación de requisitos de software (y/o

prototipo) es llevada a cabo tanto por el desarrollador del software como por el cliente. Como la
especificación forma el fundamento para el diseño y las subsiguientes actividades de ingeniería
de software se debe poner extremo cuidado al realizar la revisión.
Inicialmente la revisión se lleva a cabo a nivel microscópico. A este nivel, los revisores
intentan asegurarse de que la especificación esté completa, es consistente y exacta.
MATERIAL Y EQUIPO
1 Libreta
1 Lápiz
1 Lapicero
1 Equipo de cómputo con procesador 586 en adelante
I. Recopilar toda la información recopilada en la práctica 5 y presentarla de acuerdo al esquema de

la tabla 1, aplicar una revisión y considerar los siguientes puntos:
1.- ¿Permanecen las metas y objetivos declarados para el software consistente con las metas y
objetos del sistema?
2.- ¿Se han descrito todas las interfaces importantes de todos los elementos del sistema?
3.- ¿Están adecuadamente relacionados el flujo y la estructura de la información para el
dominio del problema?
4.- ¿Son claros los diagramas? ¿Son autosuficientes sin texto suplementario?
5.- ¿Permanecen las funciones principales dentro del ámbito y se han descrito
adecuadamente?
6.- ¿Es consistente el comportamiento del software con la información que debe procesar y con
las funciones que debe realizar?
7.- ¿Son realistas las restricciones del diseño?
23
8.- ¿Se han considerado los riesgos tecnológicos del desarrollo?

9.- ¿Se han considerado alternativos del software?
10.- ¿Se han establecido en detalle los criterios de validación? ¿Son adecuados para describir
un buen sistema?
11.- ¿Existen inconsistencias, omisiones o redundancias?
12.- ¿Se ha estado en contacto permanente con el cliente?
13.- ¿Ha revisado el usuario los avances del sistema?
14.- Entre otras.
ESQUEMAS
24
OBSERVACIONES
_________________________________________________________________________________
_________________________________________________________________________________
_________________________________________________________________________________
_________________________________________________________________________________
_________________________________________________________________________________
_________________________________________________________________________________
_________________________________________________________________________________
_________________________________________________________________________________
CUESTIONARIO
1.- _______________________________________________________________________________
2.- _______________________________________________________________________________
3.- _______________________________________________________________________________
4.- _______________________________________________________________________________
5.- _______________________________________________________________________________
CONCLUSIONES
_________________________________________________________________________________
_________________________________________________________________________________
_________________________________________________________________________________
_________________________________________________________________________________
_________________________________________________________________________________
_________________________________________________________________________________
_________________________________________________________________________________
_________________________________________________________________________________
BIBLIOGRAFIA
España, 1998
25
PRACTICA 7
DISEÑO E INGENIERIA DE SOFTWARE Y PROCESO DE DISEÑO
OBJETIVO
El alumno debe investigar y aplicar los métodos de diseño para el desarrollo de software, así
como aplicar el proceso adecuado para la elaboración de su software.
DESCRIPCIÓN BASICA
El diseño es el primer paso en la fase de desarrollo de cualquier producto o sistema de

ingeniería. Podría definirse como “el proceso de aplicar distintas técnicas y principios como el
propósito de definir un dispositivo, un proceso o un sistema con suficiente detalle como para permitir
su realización física”.
Diseño e Ingeniería de Software. El diseño de software se sitúa en el núcleo técnico del proceso
de ingeniería de software y se aplica independientemente del paradigma de desarrollo utilizado.
Suponiendo que se hayan analizado y especificado los requisitos del software, el diseño
del software es la primera de las tres actividades técnicas –diseño, codificación y prueba-
necesarias para construir y verificar el software. Cada actividad transforma la información de
manera que se obtenga finalmente un software válido.
Cada uno de los elementos del modelo de análisis proporciona información necesaria para
crear un modelo de diseño. Los requerimientos del software, por los datos y modelo funcional y de
comportamiento, componen la fase de diseño. Mediante el empleo de uno de los métodos de
diseño, la fase de diseño produce un diseño de datos, un diseño arquitectónico, un diseño de
interfaz y un diseño procedimental.
Durante el diseño tomamos decisiones que afectarán al éxito de la construcción del
software, e igualmente importante, la facilidad con la que se podrá mantener. Pero ¿por qué es
tan importante el diseño?
La importancia del diseño del software se puede decir con una sola palabra: calidad. El
diseño es el lugar donde se fomenta la calidad en el desarrollo de software. El diseño nos
proporciona representaciones del software en las que puede valorar la calidad. El diseño es la
única manera de traducir con precisión los requerimientos del cliente en un sistema o producto de
software. El diseño del software sirve como fundamento para todas las fases posteriores de
ingeniería y mantenimiento de software. Sin el diseño, nos arriesgamos a construir un sistema
inestable, que fallará en cuanto se le hagan pequeños cambios; que puede ser difícil de probar;
uno cuya calidad no se puede valorar hasta bien avanzado el proceso del software, cuando quede
poco tiempo y se haya invertido ya mucho dinero.
Proceso de Diseño
Proceso de Diseño. El diseño del software es un proceso interactivo a través del cual se traducen
los requisitos en una representación del software. Inicialmente, el anteproyecto muestra una
visión holística del software. Es decir, el diseño se presenta en un alto nivel de abstracción, un
nivel que se puede seguir hasta requisitos específicos de datos, funcionales y de comportamiento.
A medida que ocurren interacciones del diseño, el refinamiento subsiguiente lleva a
representaciones del diseño de mucho menor nivel de abstracción. Estos todavía pueden ser
seguidos hasta los requisitos, pero la conexión es mucho más sutil.
26
Diseño y Calidad de Software. A lo largo del proceso de diseño, se evalúa la calidad del diseño
con una serie de revisiones técnicas formales, las cuales siguen tres características que sirven de
directrices para la evaluación de un buen diseño:
• El diseño puede implementar todos los requisitos explícitos contenidos en el modelo de
análisis y debe acomodar todos los requisitos implícitos que desea el cliente.
• El diseño debe ser una guía que puedan leer y entender los que construyan el código y los
que prueban y mantienen el software.
• El diseño debería proporcionar una completa idea de lo que es el software, enfocando los
dominios de datos, funcional y de comportamiento desde la perspectiva de la implementación.
Cada una de estas características es de hecho un objetivo del proceso de diseño. Pero
¿cómo se alcanza cada uno de los objetivos?
Para evaluar la calidad de una representación del diseño se pueden establecer unos criterios
técnicos para un buen diseño, es importante mencionar:
1. Un diseño debería representar una organización jerárquica que haga un uso inteligente del control
entre los componentes del software.
2. El diseño debería ser modular; es decir se debería hacer una partición lógica del software en
elementos que realicen las funciones y subfunciones específicas.
3. Un diseño debe contener abstracciones de datos y procedimentales.
4. Un diseño debería producir módulos.
5. Un diseño debería conducir a interfaces que reduzcan la complejidad de las conexiones entre
módulos y el entorno exterior.
6. Se debería producir un diseño usando un método que pudiera repetirse según la información
obtenida durante el análisis de requisitos de software.
Estos criterios no se consiguen por casualidad. El proceso de diseño de software exige un

buen diseño a través de la aplicación de principios fundamentales de diseño, metodología sistemática
y una revisión exhaustiva.
MATERIAL Y EQUIPO
1 Libreta
1 Lápiz
1 Bolígrafo
1.- Investigar y presentar en clase los métodos de diseño arquitectónico.

2.- ¿Se diseña software cuando se “escribe” un programa? Si o no y por qué.
3.- ¿Qué es lo que hace diferente el diseño a la codificación?
4.- Dar a conocer el sistema que se va a desarrollar.
5.- Estructurar un diseño de acuerdo a las necesidades y darlo a conocer al catedrático para poder
ser asesorado.
6.- Representar todos los requisitos explícitos de su diseño de software.
7.- El alumno debe desarrollar una lectura fácil y entendible sobre todo su código.
8.- Presentar lo anterior por escrito para poder asesorar al alumno y poder realizar un buen desarrollo
de software.
27
ESQUEMAS
OBSERVACIONES
_________________________________________________________________________________
_________________________________________________________________________________
_________________________________________________________________________________
_________________________________________________________________________________
_________________________________________________________________________________
_________________________________________________________________________________
_________________________________________________________________________________
_________________________________________________________________________________
CUESTIONARIO
1.- _______________________________________________________________________________
2.- _______________________________________________________________________________
3.- _______________________________________________________________________________
4.- _______________________________________________________________________________
5.- _______________________________________________________________________________
28
CONCLUSIONES
_________________________________________________________________________________
_________________________________________________________________________________
_________________________________________________________________________________
_________________________________________________________________________________
_________________________________________________________________________________
_________________________________________________________________________________
_________________________________________________________________________________
_________________________________________________________________________________
BIBLIOGRAFIA
España, 1998
29
PRACTICA 8
DISEÑO DE DATOS
OBJETIVO
El alumno debe ser capaz de aplicar el proceso adecuado para el diseño de datos.
DESCRIPCIÓN BASICA
Diseño de Datos. El diseño de datos es necesario en las actividades que se llevan a cabo en la
ingeniería del software.
El impacto de la estructura de datos en la estructura del programa y la complejidad
procedimental hace que el diseño de los datos tenga una profundidad de influencia en la calidad del
software. Los conceptos de ocultación de información y abstracción de datos proporcionan el
fundamento para un enfoque del diseño de datos.
Según Wasserman: La actividad principal del diseño de datos es seleccionar
representaciones lógicas de objetos de datos (estructuras de datos) identificadas durante la fase de
definición y especificación de requisitos. El proceso de selección puede incluir el análisis de
estructuras alternativas para determinar el diseño más eficiente o puede incluir simplemente el
ejemplo de un conjunto de módulos que proporcione las operaciones deseadas sobre alguna
representación de un objeto.
Una actividad relacionada importante durante el diseño es identificar aquellos módulos del
programa que deben operar directamente sobre las estructuras de datos lógicas. De esta manera se
puede restringir el alcance de efecto de las decisiones individuales sobre el diseño de datos.
Independiente de las técnicas de diseño que se emplean, unos datos bien diseñados pueden
conducir a una mejor estructura y modalidad del programa, y a una menor complejidad procedimental.
Wasserman ha propuesto un conjunto de principios que pueden emplearse para especificar y
diseñar datos. En realidad, el diseño de datos empieza durante la creación del modelo de análisis.
Recordando que el análisis de requisitos y diseño a menudo se solapan, consideramos el siguiente
conjunto de principios para la especificación de datos:
1. Los principios del análisis sistemático aplicados a la función y al comportamiento deberían aplicase
también a los datos
2. Todas las estructuras de datos y las operaciones a llevar a cabo en cada una de ellas deberían
estar claramente identificadas.
3. Se debería contar con un diccionario de datos y usarlo para definir el diseño de los datos y del
programa.
4. Las decisiones de diseño de datos de bajo nivel deberían dejarse para el final del proceso de
diseño.
5. La representación de las estructuras de datos deberían conocerla solo aquellos módulos que
deban hacer uso directo de los datos contenidos dentro de la estructura.
6. Debería desarrollarse una biblioteca de estructuras de datos útiles y de las operaciones que se les
puede aplicar.
7. Un diseño del software y un lenguaje de programación deberían soportar la especificación y
realización de los tipos abstractos de datos.
30
Los principios descritos anteriormente forman una base para un enfoque de diseño de datos
que puede integrarse en las fases de definición y desarrollo del proceso de ingeniería de software.
MATERIAL Y EQUIPO
1 Libreta
1 Lápiz
1 Bolígrafo
1 Equipo de computo con procesador 586 en adelante
1 Disco de 3 ½ de alta densidad
1.- De la práctica 7 en donde se presentó la estructura de un diseño, realizar un análisis adecuado

tanto a las funciones como a los datos.
2.- Presentar una adecuada identificación tanto de las estructuras de datos como de las operaciones.
3.- Presentar un diccionario de datos.
4.- Desarrollar y presentar una biblioteca de estructuras de datos de las operaciones.
ESQUEMAS
31
OBSERVACIONES
_________________________________________________________________________________
_________________________________________________________________________________
_________________________________________________________________________________
_________________________________________________________________________________
_________________________________________________________________________________
_________________________________________________________________________________
_________________________________________________________________________________
_________________________________________________________________________________
CUESTIONARIO
1.- _______________________________________________________________________________
2.- _______________________________________________________________________________
3.- _______________________________________________________________________________
4.- _______________________________________________________________________________
5.- _______________________________________________________________________________
CONCLUSIONES
_________________________________________________________________________________
_________________________________________________________________________________
_________________________________________________________________________________
_________________________________________________________________________________
_________________________________________________________________________________
_________________________________________________________________________________
_________________________________________________________________________________
_________________________________________________________________________________
BIBLIOGRAFIA
España, 1998.
32
PRACTICA 9
OPTIMIZACION DEL DISEÑO ARQUITECTONICO Y DISEÑO DE LA INTERFAZ
OBJETIVO
El alumno debe ser capaz de aplicar la optimización del diseño arquitectónico y el diseño de la
interfaz en el desarrollo de su codificación.
DESCRIPCIÓN BASICA
Optimización del Diseño Arquitectónico. Cualquier estudio sobre la optimización del diseño debería
estar precedida del siguiente comentario: “Recuerde que un diseño óptimo que no funciona tiene un
valor cuestionable”.
El diseño del software debería preocuparse de desarrollar una representación del software
que satisfaga todos los requisitos funcionales y de rendimiento, y que merezca la aceptación
basándose en la calidad del diseño.
Hay que insistir en el refinamiento de la estructura del programa durante las primeras fases
del diseño. Se puede obtener, refinar y evaluar representaciones alternativas para decidir el “mejor”
enfoque. Este enfoque de optimización de la arquitectura del software.
Es importante resaltar que la simplicidad estructural a menudo refleja elegancia y eficacia. La
optimización del diseño deberá intentar conseguir el menor número de módulos que sea compatible
con una modularidad efectiva y la estructura de datos menos compleja que satisfaga adecuadamente
los requisitos de la información.
Para aplicaciones de rendimiento crítico, puede ser necesario “optimizar” durante fases
posteriores del diseño y posiblemente durante la construcción del código. El que desarrolla el software
debería tener en cuenta, sin embargo, que un porcentaje relativamente pequeño de un programa
(típicamente, entre un 10 - 20 %) ocupa un gran porcentaje del tiempo de procesamiento (50 – 20 %).
Es razonable proponer el siguiente enfoque para el software de rendimiento crítico:
1. Desarrollar y definir la estructura de programa sin preocuparse de la optimización del rendimiento
crítico.
2. Usar herramientas CASE que simulan el rendimiento en tiempo de ejecución para aislar áreas de
ineficacia.
3. Durante iteraciones posteriores del diseño, seleccionar los módulos sospechosos de “devorar
tiempo” y desarrollar cuidadosamente procedimientos (algoritmos) que mejoren la eficiencia en el
empleo del tiempo.
4. Codificar en un lenguaje de programación apropiado.
5. Instrumentar el software para aislar módulos que consuman mucho tiempo de procesador.
6. Si es necesario, rediseñar o decodificar en lenguaje máquina para mejorar la eficiencia.
Diseño de interfaz. El diseño arquitectónico proporciona al ingeniero del software una imagen de la
estructura del programa. Como el plano para una casa, el diseño general no está completo sin la
representación de las puertas, ventanas y conexiones a servicios para agua, electricidad y teléfono
(sin mencionar la televisión por cable). Las “puertas, ventanas y conexiones a servicios” para el
software de computadora componen el diseño de la interfaz del sistema.
El diseño de la interfaz se concentra en las siguientes áreas importantes:
33
1. Diseño de la interfaz entre los módulos de software.

2. Diseño de la interfaz entre el software y otros productos y consumidores no humanos de
información (entidades externas).
3. Diseño de la interfaz entre el hombre y la computadora.
MATERIAL Y EQUIPO
1 Libreta
1 Lápiz
1 Bolígrafo
1 Disco de 3 ½ de alta densidad
1.- Refinar la información obtenida en base a la información de la práctica 8.

2.- Refinar la estructura del programa sin preocuparse de la optimización.
3.- Buscar la herramienta adecuada que simule el rendimiento en tiempo de ejecución.
4.- Codificar en un lenguaje apropiado de programación.
5.- Aplicar las pruebas necesarias para el funcionamiento del sistema.
ESQUEMAS
34
OBSERVACIONES
_________________________________________________________________________________
_________________________________________________________________________________
_________________________________________________________________________________
_________________________________________________________________________________
_________________________________________________________________________________
_________________________________________________________________________________
_________________________________________________________________________________
_________________________________________________________________________________
CUESTIONARIO
1.- _______________________________________________________________________________
2.- _______________________________________________________________________________
3.- _______________________________________________________________________________
4.- _______________________________________________________________________________
5.- _______________________________________________________________________________
CONCLUSIONES
_________________________________________________________________________________
_________________________________________________________________________________
_________________________________________________________________________________
_________________________________________________________________________________
_________________________________________________________________________________
_________________________________________________________________________________
_________________________________________________________________________________
_________________________________________________________________________________
BIBLIOGRAFIA
España, 1998
35
SISTEMAS OPERATIVOS
PRACTICA 1
ANALISIS DE LOS ESTADOS DE LOS PROCESOS
OBJETIVO
El alumno debe ser capaz de analizar el comportamiento de los procesos informáticos en sus
diferentes estados.
DESCRIPCIÓN BASICA
El término proceso no está aún claramente definido, a veces se usa como sinónimo de tarea.
Se ha intentado definir también como un programa en ejecución, una unidad despachable, una
actividad asíncrona, etc.
Un proceso pasa por una serie de estados. Varios eventos pueden ocasionar que un proceso
cambie de estado.
Se dice que un proceso se está ejecutando si se tiene asignado al CPU. Se dice que un
proceso está listo si pudiera utilizar una CPU en caso de haber una disponible. Un proceso está
bloqueado si está esperando que suceda algún evento antes de poder proseguir su ejecución.
Cuando se admite una tarea en el sistema, se crea el proceso y se inserta al final de la lista de
procesos listos. El proceso se desplaza poco a poco hacia el frente de la lista de procesos listos, a
medida que los procesos que se encuentran antes que él completen su turno de uso de la CPU.
Cuando el proceso llega al principio de la lista, se le asigna la CPU cuando ésta queda disponible y
entonces se dice que hay una transición de estado del estado listo al estado de ejecución. La
asignación del procesador al primer proceso de la lista de procesos listos se denomina despacho;
dicha actividad la realiza una entidad del sistema llamada despachador.
Despierto en ejecución
Despachar Bloqueado
Expiración
del tiempo
Despierto Listo Bloquear Dormido

Despertar
MATERIAL Y EQUIPO
Computadoras 586 con Sistema Operativo Linux
36
Nota: Linux es un sistema operativo para red multiusuario y multitarea ideal, para llevar a cabo todo el
proceso del análisis del comportamiento de los procesos. En Linux, al análisis de los procesos
se le llama control de trabajos y es la habilidad de poner procesos en segundo plano
(backgrownd) y ponerlos de vuelta en primer plano (foregrownd). Las dos palabras importantes
son fg para primer plano y bg para segundo plano.
I. Iniciar sesión de trabajo en Linux.
1.- Para poder iniciar una sesión de trabajo en Linux, existen dos maneras de hacerlo:
1.1 Si se está en red con un servidor Linux, ejecutar dentro de la computadora cliente con
Windows 95 una sesión telnet en línea de comando.
a) Conectarse a Linux seleccionando en el menú “conectar”
b) Seleccionar “sistema remoto”
c) En la ventana que se presenta, escribir el nombre del host (nombre del
servidor que contiene a Linux) o dirección IP del host
d) Oprimir el login y el password
1.2 Si se esta en una computadora con Linux instalado en el disco duro, insertar el diskette
con el sistema de arranque si este es el caso.
a) Encender la computadora
b) Proporcionar el login y el password
II. Análisis de procesos. Un solo proceso.

1.- Ejecutar el comando “yes” en la línea de comandos.
2.- Oprima la combinación de teclas CTRL.+Z. En la pantalla debe aparecer lo siguiente:
[1] + Stopped yes
esto significa que el trabajo “yes” se ha suspendido en el segundo plano
3.- Ejecutar fg
Esto hace que el trabajo yes pase nuevamente a primer plano y vuelva a ejecutarse.
4.- Oprimir la combinación de teclas CTRL+C. Esto matará al proceso; en la pantalla debe
aparecer lo siguiente
[1] + Stopped yes
El número entre corchetes es el número de trabajo de este proceso. El signo “+” indica que
ese es el trabajo actual (el proceso más reciente que se ha movido del primer plano al
segundo). La palabra stopped significa que el trabajo está “parado”. El trabajo no está muerto,
pero actualmente no se ejecuta. Linux lo ha guardado en un estado especial de suspendido
listo para saltar a la acción cuando alguien lo solicite.
5.- Para matar este trabajo, ejecutar la orden
Kill % 1
En la pantalla aparece el siguiente mensaje:
[1] + Stopped yes
El trabajo en realidad no está “parado”, ejecutar entonces el comando
Jobs
En la pantalla aparece lo siguiente:
[1] + Terminated yes
III. Análisis de procesos. Varios procesos.

1.- En la línea de comando, ejecutar lo siguiente:
Yes > /dev/null &
37

Yes | sort > /dev/null &
Yes | uniq > /dev/null, pulse CTRL+Z para suspenderlo
En la pantalla debe aparecer lo siguiente:
[3] + Stopped yes | uniq > /dev/null
Nota: El símbolo & indica al shell que el trabajo lo ejecute en segundo plano desde el principio
(es una forma de evitarse que ejecutar el programa, pulsar CTRL+Z y luego teclear
bg).
De esta manera, los dos primeros comandos han empezado a ejecutarse en segundo plano.
El tercero está suspendido e inactivo en este momento.
4.- Ejecutar kill %2 ó fg %2 y CTRL.+C para matar a la segunda tarea.
5.- Ejecutar Jobs para verificar que la tarea dos ha muerto. En la pantalla debe mostrarse lo
siguiente:
[1] – Running yes > /dev/null &
[3] + Stopped yes | uniq >/dev/null
El signo “-“ indica que ese trabajo número uno es segundo en la lista para ser puesto en el
primer plano, si sólo se ejecuta fg sin dar parámetros. El signo “+” indica que el trabajo
especificado es el primero en la lista.
6.- Ejecutar fg %1 en la línea de comando. Esto hace que el trabajo uno pase a primer plano y se
ejecute.
7.- Oprimir CRTL+Z para suspender al trabajo uno. En la pantalla debe aparecer lo siguiente:
[1] + Stopped yes >/dev/null
8.- Ejecutar comando jobs. En la pantalla debe aparecer lo siguiente:
[1] + Stopped yes >/dev/null
[3] - Stopped yes | uniq >/dev/null
Ambos están parados
9.- Ejecutar bg. Esto reiniciará al trabajo uno.
10.- Eliminar ambos procesos ejecutando kill %1 %3.
ESQUEMAS
38
OBSERVACIONES
_________________________________________________________________________________
_________________________________________________________________________________
_________________________________________________________________________________
_________________________________________________________________________________
_________________________________________________________________________________
_________________________________________________________________________________
_________________________________________________________________________________
_________________________________________________________________________________
CUESTIONARIO
1.- _______________________________________________________________________________
2.- _______________________________________________________________________________
3.- _______________________________________________________________________________
4.- _______________________________________________________________________________
5.- _______________________________________________________________________________
CONCLUSIONES
_________________________________________________________________________________
_________________________________________________________________________________
_________________________________________________________________________________
_________________________________________________________________________________
_________________________________________________________________________________
_________________________________________________________________________________
_________________________________________________________________________________
_________________________________________________________________________________
BIBLIOGRAFIA
GREENFIELD, Larry; Guía de Linux para el Usuario, Manual gratis obtenido en Internet en
ftp.sunsite.unc.edu
39
PRACTICA 2
ANÁLISIS DE LOS SEMÁFOROS EN LA SINCRONIZACION DE LOS PROCESOS
OBJETIVO
El alumno debe ser capaz de comprender la importancia de los semáforos en la

administración de los procesos que están en ejecución dentro de un lenguaje de programación.
DESCRIPCIÓN BASICA
Dijkstra extrajo los conceptos fundamentales de la exclusión mutua en su concepto de

semáforos. Un semáforo es una variable protegida cuyo valor sólo puede ser leído y alterado
mediante las operaciones P y V y una operación de asignación de valores iniciales que se puede
llamar Inicia semáforos. Los semáforos binarios pueden leer solamente los valores 0 ó 1. Los
semáforos contadores (llamados también semáforos generales) pueden tener tan solo valores enteros
no negativos.
La operación P sobre el semáforo S, opera como sigue:
Sí S>0
Entonces S: = S-1
Si no (esperar S)
La operación V sobre el semáforo S, opera como sigue:
Sí (uno o más procesos esperan S)
Entonces (dejar que prosiga uno de esos procesos)
Si no S: = +1
La exclusión mutua sobre el semáforo S o se implanta dentro de cualquiera de los algoritmos
anteriores P o V. Si varios procesos desean ejecutar la operación P (S) de manera simultánea,
solamente se permitirá la ejecución de uno de ellos. Los otros quedarán en espera, pero la manera
como se realizarán P y V garantiza que los procesos no se aplazarán en forma indefinida.
MATERIAL Y EQUIPO
Sistema operativo MS-DOS, Linux

Lenguaje de programación C o Pascal
Computadoras 586 con Sistema Operativo MS-DOS o Linux
I. Diseño de un Programa de Computadora

1.- Con el lenguaje de programación seleccionado, diseñar un programa de computadora de
acuerdo al siguiente algoritmo:
Programa semáforo
40
Variables
Activo
Procedimiento proceso_uno
Inicia
Mientras verdadero hacer
Inicia
Tareas_preliminares_procesos_dos
P(activo)
Sección_crítica_dos
V(activo)
Otras_tareas_dos
Fin
Fin
Empieza
Inicia_semáforo (activo, 1)
Inicia paralelo
Proceso_uno
Proceso_dos
Fin paralelo
Fin
II. Análisis del funcionamiento de la exclusión mutua

1.- Ejecutar el programa y visualizar en pantalla la manera en que se cumple la exclusión mutua
al lanzar dos procesos.
ESQUEMAS
41
OBSERVACIONES
_________________________________________________________________________________
_________________________________________________________________________________
_________________________________________________________________________________
_________________________________________________________________________________
_________________________________________________________________________________
_________________________________________________________________________________
_________________________________________________________________________________
_________________________________________________________________________________
CUESTIONARIO
1.- _______________________________________________________________________________
2.- _______________________________________________________________________________
3.- _______________________________________________________________________________
4.- _______________________________________________________________________________
5.- _______________________________________________________________________________
CONCLUSIONES
_________________________________________________________________________________
_________________________________________________________________________________
_________________________________________________________________________________
_________________________________________________________________________________
_________________________________________________________________________________
_________________________________________________________________________________
_________________________________________________________________________________
_________________________________________________________________________________
BIBLIOGRAFIA
DEITEL, H. M.; Sistemas Operativos. Editorial Addison-Wesley Iberoamericana, 2ª edición, 1993
42
PRACTICA 3
ANÁLISIS DE MONITORES EN LA CONCURRENCIA DE PROCESOS
OBJETIVO
El alumno debe analizar el papel fundamental de los monitores en la concurrencia de

procesos en un lenguaje de programación.
DESCRIPCIÓN BASICA
El monitor es una construcción para concurrencia que contiene tanto los datos como los
procedimientos necesarios para asignar un recurso compartido específico reutilizable en serie o un
grupo de estos recursos.
Para ejecutar una función de asignación de recursos, un proceso debe llamar a una entrada
de monitor específica.
Muchos procesos pueden desear entrar en el monitor en diversos momentos pero la exclusión
mutua se mantiene de manera estricta en los límites del monitor, solo se permite la entrada de un
proceso a la vez. Los procesos que desean entrar en el monitor cuando ya está en uso deben
esperar, el monitor controla automáticamente esta espera.
Si un proceso que está llamando a la entrada del monitor encuentra que el recurso requerido
ya ha sido asignado, el procedimiento monitor llama a la función esperar. El proceso podría
permanecer dentro del monitor, pero ello violaría la exclusión mutua si otro proceso entrara en el
monitor. Por tanto, el proceso que llamó a esperar debe aguardar fuera del monitor hasta que se
libere el recurso.
Para asegurar que un proceso que está esperando un recurso acabe por obtenerlo, el monitor
da mayor prioridad a los procesos en espera que a un nuevo proceso que solicite en el monitor.
Debe introducirse la noción de variable condicional. Son muy diferentes de las variables
“convencionales”. Cuando se define una variable condicional se crea una cola un proceso que llama a
la operación esperar se agrega a la cola, un proceso que llama a la operación señalar hace que un
proceso en espera sea sacado de la cola y entre al monitor.
En los sistemas de computo es común tener unos proceso (determinados lectores) que leen
datos y otros (denominados escritores) que los describen. Como los lectores no alteran el contenido
de la base de datos, muchos pueden obtener acceso a la base de datos al mismo tiempo. Sin
embargo, un escritor puede modificar los datos, por lo cual debe tener acceso exclusivo. Cuando un
escritor está activo, ningún otro lector o escritor puede estar igual.
MATERIAL Y EQUIPO
Lenguaje de programación
Computadora 586 con sistema operativo Linux
43
I. Diseñar un Programa de Computadora

1.- Con el lenguaje de programación seleccionado, diseñar un programa para computadora que
haga uso del siguiente algoritmo para lectores y escritores haciendo uso de monitores.
Monitor lectores_y_escritores
Variables: lectores de tipo entero
Alguien escribe de tipo booleano
Lectura permitida, escritura_permitida de tipo condición
Procedimiento comenzar_lectura
Inicio
Si alguien escribe o en_cola (escritura_permitida)
Entonces esperar (lectura permitida)
Lectores = lectores + 1
Señalar (lectura_permitida)
Fin
Procedimiento de lectura_terminada
Inicio
Lectores = lectores – 1
Si lectores = 0 entonces señalar (escritura-permitida)
Fin
Procedimiento escritura terminada

Inicio
Si lectores >0 ó alguien-escribe
Entonces esperar (escritura permitida)
Alguien escribe = verdadero
Fin
Procedimiento escritura terminada

Inicio
Alguien_escribe = falso
Fin
II. Analizar el funcionamiento de la concurrencia de procesos

1.- Ejecutae el programa y analizar el comportamiento de los proceso cuando trabajan
concurrentemente.
ESQUEMAS
44
OBSERVACIONES
_________________________________________________________________________________
_________________________________________________________________________________
_________________________________________________________________________________
_________________________________________________________________________________
_________________________________________________________________________________
_________________________________________________________________________________
_________________________________________________________________________________
_________________________________________________________________________________
CUESTIONARIO
1.- _______________________________________________________________________________
2.- _______________________________________________________________________________
3.- _______________________________________________________________________________
4.- _______________________________________________________________________________
5.- _______________________________________________________________________________
CONCLUSIONES
_________________________________________________________________________________
_________________________________________________________________________________
_________________________________________________________________________________
_________________________________________________________________________________
_________________________________________________________________________________
_________________________________________________________________________________
_________________________________________________________________________________
_________________________________________________________________________________
BIBLIOGRAFIA
DEITEL, H. M.; Sistemas Operativos. Editorial Addison-Wesley Iberoamericana, 2ª edición, 1993
45
CREDITOS
PLANTEL: ORIZABA
COORDINADOR DE INSTRUCTIVO:
LIC. ALMA PATRICIA VASQUEZ GONZALEZ
AUTOR(ES):
L.I. ELIZABETH RODRÍGUEZ GUZMÁN
SISTEMAS OPERATIVOS
ING. RICARDO CARRERA HERNANDEZ
REVISION:
ING. HILDA MARCELA RODRIGUEZ LAPA
ING. JAIME RODRIGO SANDOVAL GUZMAN
DEPARTAMENTO DE METODOS DE ENSEÑANZA
CAPTURISTA:
L.I. CLAUDIA VELASQUEZ CORTES
EDICION:
2001
46

Ingeniería de Software y Sistemas Operativos

Загружено:

Сведения о документе

Авторское право

Доступные форматы

Поделиться этим документом

Поделиться или встроить документ

Параметры публикации

Этот документ был вам полезен?

Это неприемлемый материал?

Авторское право:

Доступные форматы

Ingeniería de Software y Sistemas Operativos

Загружено:

Авторское право:

Доступные форматы

INSTRUCTIVOS DE PRACTICAS UGM

UNIVERSIDAD DEL GOLFO DE MEXICO, A. C.

NOMBRE DEL ALUMNO

UNIVERSIDAD DEL GOLFO DE MEXICO, A. C.

Ing. Luis Reyes Larios

Ing. Alfonso Juárez Jiménez

Ing Andrés Juárez Jiménez

Ing. Prudencio Reyes Larios

Lic. María Isabel López Islas

Ing. Jaime Rodrigo Sandoval Guzmán

2 Paradigmas de la Ingeniería de Software 9

3 Métricas del Proyecto 13

5 Principio del Análisis 19

6 Especificaciones de los Requisistos de Software 22

7 Diseño e Ingeniería de Software y Proceso de Diseño 26

9 Optimización del Diseño Arquitectónico y Diseño de la Interfaz 33

1 Análisis de los Estados de los Procesos 36

2 Análisis de los Semáforos en la Sincronización de los Procesos 40

3 Análisis de Monitores en la Concurrencia de Procesos 43

El software puede aplicarse en cualquier situación en la que se haya definido previamente un

Nombre Características Clasificación Por qué

PARADIGMAS DE LA INGENIERIA DE SOFWARE

Combinación de paradigmas: en muchos casos, los paradigmas pueden y deben combinarse de

2. ¿Cuál de los paradigmas de Software aplican?

METRICAS DEL PROYECTO

El alumno debe ser capaz de interpretar la importancia de la medición de un proyecto de

I. Se le presentará al alumno un sistema (opción libre) en el cual debe calcular:

El Modelo COCOMO (Modelo Constructivo de Costo). La jerarquía de modelos esta constituida

3.- Recordar que las formulas aplicar son:

bb = Exponente (obtenidos de la parte orgánica, semiacoplado, empotrado)

N = Número de personas para el proyecto

FAIRLEY, Richard; Ingeniería de Software. Editorial Mc Graw Hill, 1ª edición, 1998

PRINCIPIOS DEL ANALISIS

El alumno debe ser capaz de aplicar el análisis adecuado en el problema el cual va a

1.- Entender el problema antes de empezar a crear el modelo del análisis.

FAIRLEY, Richard; Ingeniería de Software. Editorial Mc Graw Hill, 1ª edición, 1998

ESPECIFICACIONES DE LOS REQUISITOS DE SOFTWARE

El alumno debe se capaz de aplicar la especificación de requisitos del software necesario

La especificación de los requisitos de software se produce en la culminación de la tarea de

Nota: Observar la tabla 1.

III. Descripción funcional

Revisión de la especificación. La revisión de la especificación de requisitos de software (y/o

I. Recopilar toda la información recopilada en la práctica 5 y presentarla de acuerdo al esquema de

8.- ¿Se han considerado los riesgos tecnológicos del desarrollo?

DISEÑO E INGENIERIA DE SOFTWARE Y PROCESO DE DISEÑO

El diseño es el primer paso en la fase de desarrollo de cualquier producto o sistema de

Estos criterios no se consiguen por casualidad. El proceso de diseño de software exige un

1.- Investigar y presentar en clase los métodos de diseño arquitectónico.

1.- De la práctica 7 en donde se presentó la estructura de un diseño, realizar un análisis adecuado

OPTIMIZACION DEL DISEÑO ARQUITECTONICO Y DISEÑO DE LA INTERFAZ

1. Diseño de la interfaz entre los módulos de software.

1.- Refinar la información obtenida en base a la información de la práctica 8.

ANALISIS DE LOS ESTADOS DE LOS PROCESOS

Despierto Listo Bloquear Dormido

Computadoras 586 con Sistema Operativo Linux

II. Análisis de procesos. Un solo proceso.

III. Análisis de procesos. Varios procesos.

2.- En la línea de comando, ejecutar lo siguiente:

ANÁLISIS DE LOS SEMÁFOROS EN LA SINCRONIZACION DE LOS PROCESOS

El alumno debe ser capaz de comprender la importancia de los semáforos en la

Dijkstra extrajo los conceptos fundamentales de la exclusión mutua en su concepto de

Sistema operativo MS-DOS, Linux

I. Diseño de un Programa de Computadora

II. Análisis del funcionamiento de la exclusión mutua