Guía de CENEVAL

ISOFT 2018

CICLO 2018

Por el grupo de Ingeniería en Sistemas Computacionales

CONTENIDO
A. Análisis de Sistemas de Información. ................................................ 3
1. Diagnóstico del problema y valoración de la factibilidad para el
desarrollo de sistemas de información.................................................................. 3
Análisis preliminar de los sistemas de operación de la organización
.............................................................................................................................. 3
Diagnóstico de la situación de los sistemas de operación de la
organización ...................................................................................................... 3
Identificación de los problemas a resolver con sistemas de
información ........................................................................................................ 3
Análisis de factibilidad de productos comerciales contra
desarrollos a la medida como estrategias de solución del problema .... 3
Propuestas de sistemas de información computacional que
solucionen la problemática detectada en la organización ..................... 3
2. Modelado de los requerimientos de un sistema de información 4
Requerimientos duraderos y volátiles ................................................. 5
Diseño de la arquitectura ..................................................................... 5
Análisis de los requerimientos de un sistema de información ......... 5
Validación de los requerimientos de un sistema de información .. 5
Documentación de los requerimientos de un sistema de
información ........................................................................................................ 5
B. Desarrollo e Implementación de Aplicaciones Computacionales
6
1. Diseño de la solución del problema de tecnología de
información ................................................................................................................ 6
2. Desarrollo de sistemas ......................................................................... 9
Métodos y etapas del Desarrollo de Proyectos .............................. 10
Detección de necesidades ................................................................ 10
Definición del Problema ...................................................................... 10
Estudio de Factibilidad ........................................................................ 10
Planeación del proyecto .................................................................... 10
elaboración del proyecto................................................................... 10
documentación del proyecto ........................................................... 10

I
 3. Implantación de sistemas ................................................................. 10
Codificación.......................................................................................... 11
Probando la aplicación ...................................................................... 11
Instalación y Evaluación...................................................................... 11
Adiestramiento (Training) .................................................................... 11
Conversión de archivos ....................................................................... 11
System Changeover............................................................................. 11
4. Aplicación de modelos matemáticos ............................................ 11
C. Gestión de Proyectos de Tecnologías de Información ............... 18
1. Administración de proyectos de tecnologías de información ... 18
2. Control de calidad de proyectos de tecnologías de información
28
D. Gestión de Redes, Bases de Datos, Sistemas Operativos y
Lenguaje de Desarrollo .......................................................................................... 31
1. Gestión de redes de datos ............................................................... 31
Implementación de redes. ................................................................. 31
2. Gestión de bases de datos ............................................................... 31
Diseño de base de datos utilizando de normalización.................. 31
Administrador de la base de datos ................................................... 31
Modificación de la base de datos .................................................... 31
3. Gestión de sistemas operativos o lenguajes de desarrollo ......... 31

II
A. ANÁLISIS DE SISTEMAS DE INFORMACIÓN.

1. Diagnóstico del problema y valoración de la factibilidad para el

desarrollo de sistemas de información
2. Modelado de los requerimientos de un sistema de información

En esta área se evalúa la capacidad de diagnosticar un problema

en operación de una organización, utilizando como estrategias
(metodologías) el análisis de factibilidad, así como el análisis, la validación
y la documentación de requerimientos a fin de proponer un sistema de
información computacional.

1. Diagnóstico del problema y valoración de la factibilidad

para el desarrollo de sistemas de información
Análisis preliminar de los sistemas de operación de la
organización

Diagnóstico de la situación de los sistemas de

operación de la organización

Identificación de los problemas a resolver con

sistemas de información

Análisis de factibilidad de productos comerciales

contra desarrollos a la medida como estrategias de
solución del problema

Propuestas de sistemas de información computacional

que solucionen la problemática detectada en la
organización

3
2. Modelado de los requerimientos de un sistema de
información

 Descubrimiento de requerimientos. Es el proceso de interactuar

con los stakeholders del sistema para recopilar sus requerimientos.
Los requerimientos del dominio de los stakeholders y la
documentación también se descubren durante esta actividad.
5. Clasificación y organización de requerimientos. Esta actividad
toma la recopilación no estructurada de requerimientos, grupos
relacionados de requerimientos y los organiza en grupos
coherentes.
6. Ordenación por prioridades y negociación de requerimientos.
Inevitablemente, cuando existen muchos stakeholders
involucrados, los requerimientos entrarán en conflicto. Esta
actividad se refiere a ordenar según las prioridades los
requerimientos, y a encontrar y resolver los requerimientos en
conflicto a través de la negociación.
7. Documentación de requerimientos. Se documentan los
requerimientos y se entra en la siguiente vuelta de la espiral. Se
pueden producir documentos de requerimientos formales o
informales.

4
Requerimientos duraderos y volátiles

Diseño de la arquitectura

Análisis de los requerimientos de un sistema de

información

Validación de los requerimientos de un sistema de

información

Documentación de los requerimientos de un sistema

de información

5
B. DESARROLLO E IMPLEMENTACIÓN DE APLICACIONES
COMPUTACIONALES

1. Diseño de la solución del problema de tecnología de

información
A fin de resolver un problema utilizando sistemas de cómputo, debe
seguirse una serie de pasos que permiten avanzar por etapas bien
definidas hacia la solución.
Estas etapas son las siguientes:
 Definición del problema.
 Análisis de los datos.
 Diseño de la solución.
 Codificación.
 Prueba y depuración.
 Documentación.
 Mantenimiento.

Definición del problema.

Está dada en sí por el enunciado del problema, el cual debe ser

claro y complejo. Es importante que conozcamos exactamente “que se
desea obtener al final del proceso”; mientras esto no se comprenda no
puede pasarse a la siguiente etapa.

Análisis de los datos.

Para poder definir con precisión el problema se requiere que las

especificaciones de entrada y salida sean descritas con detalle ya que
esto es un requisito para lograr una solución eficaz.
Una vez que el problema ha sido definido y comprendido, deben
analizarse los siguientes aspectos:
 Los resultados esperados.
 Los datos de entrada disponibles.

6
  Herramientas a nuestro alcance para manipular los datos y
alcanzar un resultado (fórmulas, tablas, accesorios diversos).
Una medida aconsejable para facilitar esta etapa consiste en
colocarnos en lugar de la computadora deduciendo los elementos que
necesitaremos para alcanzar el resultado.

Diseño de la solución.

Una computadora no tiene capacidad para solucionar problemas

más que cuando se le proporcionan los sucesivos pasos a realizar, esto se
refiere a la obtención de un algoritmo que resuelva adecuadamente el
problema. En caso de obtenerse varios algoritmos, seleccionar uno de
ellos utilizando criterios ya conocidos.
Esta etapa incluye la descripción del algoritmo resultante en un
lenguaje natural, de diagrama de flujo o natural de programación.
Como puede verse, solo se establece la metodología para alcanzar
la solución en forma conceptual, es decir; sin alcanzar la implementación
en el sistema de cómputo.
De acuerdo al ejemplo 2.1 tenemos que la información
proporcionada constituye su entrada y la información producida por el
algoritmo constituye su salida. Los problemas complejos se pueden
resolver más eficazmente por la computadora cuando se dividen en
subproblemas que sean más fácil de solucionar.
El problema de cálculo de la longitud y superficie de un círculo se
puede descomponer en subproblemas más simples:
 Leer datos de entrada.
 Calcular superficie y longitud.
 Escribir resultados (datos de salida).

Codificación.

Se refiere a la obtención de un programa definitivo que pueda ser

comprensible para la máquina. Incluye una etapa que se reconoce
como compilación.
Si la codificación original se realizó en papel, previo a la
compilación deberá existir un paso conocido como transcripción.

7
 Programa Fuente

Está escrito en un lenguaje de programación. (pascal, C++,Visual

Fox, Visual Basic, etc.).
Es entendible por el programador.

Programa Ejecutable

Está en lenguaje máquina.

Entendible por la máquina.

Prueba y depuración.

Una vez que se ha obtenido el programa ejecutable, este es

sometido a prueba a fin de determinar si resuelve o no el problema
planteado en forma satisfactoria.
Las pruebas que se le aplican son de diversa índole y generalmente
dependen del tipo de problema que se está resolviendo. Comúnmente
se inicia la prueba de un programa introduciendo datos válidos, inválidos
e incongruentes y observando cómo reacciona en cada ocasión.
El proceso de depuración consiste en localizar los errores y
corregirlos en caso de que estos existan. Si no existen errores, puede
entenderse la depuración como una etapa de refinamiento en la que se
ajustan detalles para optimizar el desempeño del programa.

Documentación.

Debido a que el programa resultante en esta etapa se encuentra

totalmente depurado (sin errores), se procede a la utilización para resolver
problemas del tipo que dio origen a su diseño. En vista de que esta
utilización no podrá ser supervisada en todas las ocasiones por el
programador, debe crearse un manual o guía de operación que indique
los pasos a seguir para utilizar el programa.

Mantenimiento.

Se refiere a las actualizaciones que deban aplicarse al programa

cuando las circunstancias así lo requieran. Este programa deberá ser
susceptible de ser modificado para adecuarlo a nuevas condiciones de
operación.

8
 Cualquier actualización o cambio en el programa deberá reflejarse
en su documentación.

Algoritmo

Casi inconscientemente, los humanos efectuamos cotidianamente

una serie de pasos procedimientos o acciones que nos permiten alcanzar
un resultado o resolver un problema.
Esta seria de pasos, procedimientos o acciones, comenzamos a
aplicarlas muy temprano en la mañana cuando, por ejemplo, decidimos
tomar un baño. Posteriormente cuando pensamos en desayunar también
seguimos una seria de pasos que nos permiten alcanzar un resultado
específico: tomar el desayuno. La historia se repite innumerables veces
durante el día. Continuamente seguimos una serie de pasos o conjuntos
de acciones que nos permite alcanzar un resultado. Estamos en realidad
aplicando un algoritmo para resolver un problema.
Definición: Formalmente definimos un algoritmo como un conjunto
de pasos. Procedimientos o acciones que nos permiten alcanzare un
resultado o resolver un problema.

Diagramas de Flujo

Un diagrama de flujo representa la esquematización grafica de un

algoritmo. En realidad, muestra gráficamente los pasos o procesos a
seguir para alcanzar la solución de u problema. Su correcta construcción
es sumamente importante porque a partir del mismo se escribe un
programa en un lenguaje de programación. Si el diagrama de flujo está
completo y correcto, el paso del mismo a un lenguaje de programación
es relativamente simple y director.

2. Desarrollo de sistemas
Para lograr la realización de un proyecto es muy importante que se
lleven a cabo una serie de pasos y procedimientos de investigación, los
cuales permitirán abrir aún más las perspectivas que tenemos de dicho
proyecto. La ejecución clara y objetiva de estos procedimientos de
investigación son las que nos permitirán obtener un enfoque claro de lo
que deseamos obtener y como lo habremos de lograr.

9
 El desarrollo de proyectos es una parte fundamental para toda
empresa u organización que desea obtener éxito en las áreas que
involucran un proyecto. Para llevar a cabo el desarrollo de un proyecto
nos planteamos algunas preguntas: ¿existe un problema?, ¿cuál es el
problema?, ¿cómo se realizan los procesos actuales?, etc. La aclaración
de estos aspectos permitirá obtener una visión más clara de los problemas
que serán resueltos con la realización del proyecto.
Dados los antecedentes, al iniciar un proyecto es claro que se
debe de conocer a fondo los pasos y procedimientos de investigación
que requiere un proyecto.
El Desarrollo de Proyectos es una herramienta de una
gran utilidad y es por esto que he decidido llevar a cabo una recopilación
de los pasos que conlleva la realización de un proyecto.

Métodos y etapas del Desarrollo de Proyectos

DETECCIÓN DE NECESIDADES

Definición del Problema

Estudio de Factibilidad

PLANEACIÓN DEL PROYECTO

ELABORACIÓN DEL PROYECTO

DOCUMENTACIÓN DEL PROYECTO

3. Implantación de sistemas
En la fase de implantación, las especificaciones del diseño del
sistema sirven como base para la construcción del nuevo sistema. En este
punto, los programadores y los analistas de sistemas asumen diferentes
responsabilidades. El analista debe proveer especificaciones claras y
correctas al programador. El programador codifica, prueba y documenta
los módulos de programas, mientras que el analista de sistema planifica la
integración de los programas y asegura que trabajen unidos para
satisfacer las necesidades de la organización.

10
 Un nuevo sistema requiere planificación, construcción y prueba. Los
programas y módulos deben ser diseñados, codificados, probados y
documentados. Cuando se planifica el sistema, muchas veces se usa un
estilo de arriba-hacia-abajo (top-down), que procede de un diseño
general a una estructura detallada siguiendo unos pasos lógicos. En el
estilo top-down, el analista de sistemas define los objetivos generales, y
luego los descompone en subsistemas y módulos en un proceso llamado
“partitioning”. Este estilo también se conoce como diseño modular. Un
módulo es un conjunto de instrucciones de programas que se pueden
ejecutar como un grupo. Asignando módulos a diferentes programadores
se agiliza el desarrollo del programa.

Codificación

Probando la aplicación

Instalación y Evaluación

Adiestramiento (Training)

Conversión de archivos

System Changeover

4. Aplicación de modelos matemáticos

El objetivo principal de las revisiones técnicas es encontrar errores
durante el proceso a fin de que no se conviertan en defectos después de
liberar el software. El beneficio obvio de las revisiones técnicas es el
descubrimiento temprano de los errores, de modo que no se propaguen
a la siguiente etapa del proceso del software.
Varios estudios de la industria indican que las actividades de diseño
introducen de 50 a 65 por ciento de todos los errores (y en realidad de
todos los defectos) durante el proceso del software.
Sin embargo, las técnicas de revisión han demostrado tener una
eficacia de hasta 75 por ciento para descubrir fallas del diseño. Al
detectar y eliminar un gran porcentaje de estos

11
 Errores, el proceso de revisión reduce de manera sustancial el costo
de las actividades posteriores en el proceso del software.
La figura ilustra un ejemplo hipotético de amplificación del defecto
para un proceso de software en el que no se hacen revisiones. En la figura,
se supone que en cada etapa de prueba se detecta y corrige 50 por
ciento de todos los errores de entrada sin que se introduzcan nuevos
errores (suposición optimista). Diez defectos preliminares de diseño se
amplifican a 94 errores antes de que comiencen las pruebas. Se liberan al
campo 12 errores latentes (defectos). La figura
15.3 considera las mismas condiciones, excepto porque se efectúan
revisiones del diseño y código como parte de cada acción de la
ingeniería de software. En este caso, son 10 los errores

MÉTRICAS DE REVISIÓN Y SU EMPLEO

12
 Las revisiones técnicas son una de las muchas acciones que se
requieren como parte de las buenas prácticas de la ingeniería de
software. Cada acción requiere un esfuerzo humano dirigido.
Como el esfuerzo disponible para el proyecto es finito, es importante
que una organización de software comprenda la eficacia de cada
acción, definiendo un conjunto de métricas que puedan utilizarse para
evaluar esa eficacia.
Aunque se han definido muchas métricas para las revisiones
técnicas, un conjunto relativamente pequeño da una perspectiva útil. Las
siguientes métricas para la revisión pueden obtenerse conforme se
efectúe ésta:
 Esfuerzo de preparación, Ep: esfuerzo (en horas-hombre) requerido
para revisar un producto del trabajo antes de la reunión de revisión
real.
 Esfuerzo de evaluación, Ea: esfuerzo requerido (en horas-hombre) que
se dedica a la revisión real.
 Esfuerzo de la repetición, Er: esfuerzo (en horas-hombre) que se
dedica a la corrección de los errores descubiertos durante la revisión.
 Tamaño del producto del trabajo, TPT: medición del tamaño del
producto del trabajo que se ha revisado (por ejemplo, número de
modelos UML o número de páginas de documento o de líneas de
código).
 Errores menores detectados, Errmenores: número de errores
detectados que pueden clasificarse como menores (requieren menos
de algún esfuerzo especificado para corregirse).
 Errores mayores detectados, Errmayores: número de errores
encontrados que pueden clasificarse como mayores (requieren más
que algún esfuerzo especificado para corregirse).
Estas métricas pueden mejorarse, asociando el tipo de producto del
trabajo que se revisó con las métricas obtenidas.

Análisis de las métricas

Antes de comenzar el análisis deben hacerse algunos cálculos

sencillos. El esfuerzo total de revisión y el número total de errores
descubiertos se definen como sigue:

13
 Erevisión =Ep + Ea +Er

Errtot = Errmenores +Errmayores

La densidad del error representa los errores encontrados por unidad
de producto del trabajo revisada.
Densidad del error = Errtot
TPT
Por ejemplo, si se revisa un modelo de requerimientos con objeto de
encontrar errores, inconsistencias y omisiones, es posible calcular la
densidad del error en varias formas diferentes. El modelo de
requerimientos contiene 18 diagramas UML como parte de 32 páginas de
materiales descriptivos. La revisión detecta 18 errores menores y 4
mayores. Por tanto, Errtot = 22. La densidad del error es errores por
diagrama UML o 0.68 errores por página del modelo de requerimientos.
Si las revisiones se llevan a cabo para varios tipos distintos de
productos del trabajo (por ejemplo, modelo de requerimientos, modelo
del diseño, código, casos de prueba, etc.), el porcentaje de errores no
descubiertos por cada revisión se confronta con el número total de errores
detectados en todas las revisiones. Además, puede calcularse la
densidad del error para cada producto del trabajo.
Una vez recabados los datos para muchas revisiones efectuadas en
muchos proyectos, los valores promedio de la densidad del error permiten
estimar el número de errores por hallar en un nuevo documento (aún no
revisado). Por ejemplo, si la densidad promedio de error para un modelo
de requerimientos es de 0.6 errores por página, y un nuevo modelo de
requerimientos tiene una longitud de 32 páginas, una estimación gruesa
sugiere que el equipo de software encontrará alrededor de 19 o 20 errores
durante la revisión del documento. Si sólo encuentra 6 errores, habrá
hecho un trabajo extremadamente bueno al desarrollar el modelo de
requerimientos o su enfoque de la revisión no fue tan profundo.
Una vez llevada a cabo la prueba es posible obtener datos
adicionales del error, incluso el esfuerzo requerido para detectar y corregir
errores no descubiertos durante las pruebas y la densidad del error del
software. Los costos asociados con la detección y corrección de un error
durante las pruebas pueden compararse con los de las revisiones.

Eficacia del costo de las revisiones

14
 Es difícil medir en tiempo real la eficacia del costo de cualquier
revisión técnica. Una organización de ingeniería de software puede
evaluar la eficacia de las revisiones y su relación costo-beneficio sólo
después de que éstas han terminado, de que las unidades de medida de
la revisión se han recabado, de que los datos promedio han sido
calculados y de que la calidad posterior del software ha sido medida
(mediante pruebas).
Los errores relacionados con los requerimientos no detectados
durante las pruebas requieren un promedio de 45 horas-hombre para
encontrarse y corregirse (no hay datos disponibles acerca de la severidad
relativa del error). Con estos promedios se obtiene lo siguiente:
Esfuerzo ahorrado por error = Epruebas - Erevisiones
45 – 6 = 30 horas – hombre / error
Como durante la revisión del modelo de requerimientos se
encontraron 22 errores, se tendrá un ahorro cercano a 660 horas-hombre
en el esfuerzo dedicado a las pruebas. Y esto se refiere sólo a los errores
relacionados con los requerimientos. Al beneficio general se suman
aquellos asociados con el diseño y el código. El esfuerzo total conduce a
ciclos de entrega más cortos y a un mejor tiempo para llegar al mercado.

REVISIONES: ESPECTRO DE
FORMALIDAD

Las revisiones técnicas deben aplicarse con un nivel de formalidad

apropiado para el producto que se va a elaborar, para el plazo que tiene
el proyecto y para el personal que realice el trabajo.

15
 La figura ilustra un modelo de referencia para las revisiones técnicas
que identifica cuatro características que contribuyen a la formalidad con
la que se efectúa una revisión.
Cada una de las características del modelo de referencia ayuda a
definir el nivel de formalidad de la revisión.
La formalidad de una revisión se incrementa cuando:
1. Se definen explícitamente roles distintos para los revisores,
2. Hay suficiente cantidad de planeación y preparación para la
revisión,
3. Se define una estructura distinta para la revisión (incluso tareas y
productos internos del trabajo) y
4. El seguimiento por parte de los revisores tiene lugar para
cualesquiera correcciones que se efectúen.

Medidas, métricas e indicadores

Aunque los términos medida, medición y métrica con frecuencia se

usan de modo intercambiable, es importante observar las sutiles
diferencias entre ellos. En el contexto de la ingeniería del software, una
medida proporciona un indicio cuantitativo de la extensión, cantidad,
dimensión, capacidad o tamaño de algún atributo de un producto o
proceso. La medición es el acto de determinar una medida.

Principios de medición

Antes de presentar una serie de métricas de producto que 1)

auxilien en la evaluación de los modelos de análisis y diseño, 2)
proporcionen un indicio de la complejidad de los diseños
procedimentales y del código fuente y 3) faciliten el diseño de pruebas
más efectivas, es importante comprender los principios de medición
básicos. Roche sugiere un proceso de medición que puede
caracterizarse mediante cinco actividades:
 Formulación. La derivación de medidas y métricas de software
apropiadas para la representación del software que se está
construyendo.
 Recolección. Mecanismo que se usa para acumular datos
requeridos para derivar las métricas formuladas.

16
  Análisis. El cálculo de métricas y la aplicación de herramientas
matemáticas.
 Interpretación. Evaluación de las métricas resultantes para
comprender la calidad de la representación.
 Retroalimentación. Recomendaciones derivadas de la
interpretación de las métricas del producto, transmitidas al equipo
de software.

Atributos de las métricas de software

efectivas

Se han propuesto cientos de métricas para el software de

computadora, pero no todas brindan apoyo práctico al ingeniero de
software. Algunas demandan medición demasiado compleja, otras son
tan particulares que pocos profesionales del mundo real tienen alguna
esperanza de entenderlas y otras más violan las nociones intuitivas básicas
de lo que realmente es el software de alta calidad. Ejiogu define un
conjunto de atributos que deben abarcar las métricas de software
efectivas. La métrica derivada y las medidas que conducen a ella deben
ser:
 Simple y calculable. Debe ser relativamente fácil aprender como
derivar la métrica y su cálculo no debe demandar esfuerzo o
tiempo excesivo.
 Empírica e intuitivamente convincente. Debe satisfacer las
nociones intuitivas del
 Ingeniero acerca del atributo de producto que se elabora (por
ejemplo, una métrica que mide la cohesión del módulo debe
aumentar en valor conforme aumenta el nivel de cohesión).
 Congruente y objetiva. Siempre debe producir resultados que no
tengan ambigüedades.
 Una tercera parte independiente debe poder derivar el mismo
valor de métrica usando la misma información acerca del
software.
 Constante en su uso de unidades y dimensiones. El cálculo
matemático de la métrica debe usar medidas que no conduzcan
a combinaciones extrañas de unidades. Por ejemplo, multiplicar

17
 personas en los equipos de proyecto por variables de lenguaje de
programación en el programa da como resultado una mezcla
sospechosa de unidades que no son intuitivamente convincentes.
 Independiente del lenguaje de programación. Debe basarse en el
modelo de requerimientos, el modelo de diseño o la estructura del
programa en sí. No debe depender de los caprichos de la sintaxis
o de la semántica del lenguaje de programación.
 Un mecanismo efectivo para retroalimentación de alta calidad.
Debe proporcionar información que pueda conducir a un
producto final de mayor calidad.

C. GESTIÓN DE PROYECTOS DE TECNOLOGÍAS DE

INFORMACIÓN

1. Administración de proyectos de tecnologías de información

2. Control de calidad de proyectos de tecnologías de información

En esta área se evalúan los conocimientos de las metodologías de

planeación, gestión y administración de proyectos de desarrollo e infraestructura,
así como los métodos de control de calidad en tecnologías de la información.

1. Administración de proyectos de tecnologías de información

Un proyecto es un esfuerzo temporal que se lleva a cabo para crear
un producto, servicio o resultado único. La naturaleza temporal de los
proyectos indica un principio y un final definidos. El final se alcanza
cuando se logran los objetivos del proyecto o cuando se termina el
proyecto porque sus objetivos no se cumplirán o no pueden ser cumplidos,
o cuando ya no existe la necesidad que dio origen al proyecto. Temporal
no necesariamente significa de corta duración. En general, esta cualidad
no se aplica al producto, servicio o resultado creado por el proyecto; la
mayor parte de los proyectos se emprenden para crear un resultado
duradero. Por ejemplo, un proyecto para construir un monumento
nacional creará un resultado que se espera que perdure durante siglos.
Por otra parte, los proyectos pueden tener impactos sociales, económicos
y ambientales que durarán mucho más que los propios proyectos.

18
 La dirección de proyectos es la aplicación de conocimientos,
habilidades, herramientas y técnicas a las actividades del proyecto para
cumplir con los requisitos del mismo. Se logra mediante la aplicación e
integración adecuadas de los 42 procesos de la dirección de proyectos,
agrupados lógicamente, que conforman los 5 grupos de procesos. Estos
5 grupos de procesos son:
 Iniciación
 Planificación
 Ejecución
 Seguimiento y Control
 Cierre
Dirigir un proyecto por lo general implica:
 Identificar requisitos
 Abordar las diversas necesidades, inquietudes y expectativas de los
interesados según se planifica y efectúa el proyecto
 Equilibrar las restricciones contrapuestas del proyecto que se
relacionan, entre otros aspectos, con:
 el alcance
 la calidad
 el cronograma
 el presupuesto
 los recursos
 el riesgo
Todo proyecto requiere para su realización una serie de recursos.
Los recursos necesarios para el desarrollo del proyecto generalmente se
clasifican en cuatro tipos:
Humanos: Para poner en marcha cualquier tipo de proyecto de
debe disponer de personas adecuadas y capacitadas para realizar las
actividades y tareas previstas.
Físicos: Los recursos físicos tradicionalmente comprenden varios
aspectos como terrenos, edificios, maquinaria, equipos, infraestructura,

19
bibliografía, documentación, medios de transporte, tecnología, etc. Sin
embargo, este tipo de recursos no siempre deben ser adquiridos, pero sí
puede ser cubiertos o sustituidos con lo que se tiene.
Técnicos: En caso de que el proyecto contemple herramientas o
recursos específicos, es necesario establecer las alternativas técnicas
elegidas y las tecnologías a utilizar. Cuando un proyecto contempla la
adopción de innovaciones tecnológicas, es bueno tener presente, que
muy probablemente, la adopción de la innovación no se va a producir
en su totalidad.
Financieros: Los recursos financieros hacen referencia al
presupuesto necesario para la operación del proyecto. Se sabe que
cualquier acción tiene un costo que es asumido por todas las partes
comprometidas en su puesta en marcha. Los recursos no necesariamente
tienen que provenir de entidades especializadas en financiar proyectos.
El éxito o fracaso de un proyecto esta medido en función del logro
de sus objetivos y posteriormente por la administración de los recursos
asignados al mismo. Cuando se habla de recursos, se hace referencia a
los requerimientos necesarios para lograr la realización de un proyecto:
a) Tiempo
b) Personas
c) Dinero
d) Equipo
e) Instalaciones o instrumentos
En muchas organizaciones la asignación de recursos responde a
una sola variable: “Disponibilidad”. No obstante, el establecimiento de un
plan adecuado permite asegurar que todos los recursos necesarios para
el establecimiento del coste del proyecto estén debidamente asignados.
Se precisa aplicar tres procesos para la gestión de los recursos al
asignarlos al proyecto. Estos procesos se presentan a continuación:

1. Planificación de Recursos.
Identificación del tipo de recursos materiales requeridos, la
cantidad precisa y el período de necesidad en el proyecto. Comprende
la identificación de los recursos necesarios para el desarrollo del proyecto,
teniendo en cuenta las tecnologías disponibles, la utilización de recursos

20
internos y de recursos existentes en el mercado, etc., así como las
restricciones existentes para el uso de tales recursos.

2. Asignación de Recursos.
Obtención de los recursos materiales, su asignación al proyecto y su
retirada durante la desactivación del proyecto. La adquisición de
recursos externos -si fuera precisa- se efectuará de acuerdo con los
procesos de gestión de adquisiciones del proyecto. La asignación a
cada tipo de recursos, es parte de la gestión del proyecto, focalizada por
la planificación estratégica. Partiendo del análisis de qué recursos se
tienen, definir cuáles falta y establecer el plan de acción para conseguir
los que faltan. Es entonces ahí, donde el concepto de administración
estratégica entra en juego. Al principio puede ser genérica, pero a
medida que avanza el proyecto debe ser más específica. Identificación
de recursos de plena disposición y compartidos (con qué otras
actividades o proyectos y características de los mismos).

3. Control de Recursos.
Comprobación del uso apropiado de los recursos materiales. Las
desviaciones respecto al plan de recursos deben ser identificadas y
analizadas, para proponer las acciones subsiguientes necesarias. Las
decisiones y acciones deben ser tomadas sólo tras tener en cuenta las
implicaciones sobre otros procesos y objetivos del proyecto. El control
adecuado permitirá:
 Que el proyecto coincida o se acerque a los estimados con
precisión
 Consistencia con los objetivos técnicos y de plazo de ejecución del
proyecto
 Consideración de un presupuesto de coste razonable en función
de los logros del proyecto.
La administración efectiva de un proyecto de software se enfoca
en las cuatro P: personal, producto, proceso y proyecto. El orden no es
arbitrario. El gerente que olvida que el trabajo de la ingeniería del
software es una empresa intensamente humana nunca triunfará en la
administración del proyecto. Un gerente que fracase en alentar una
comunicación comprensiva con los participantes durante las primeras
etapas de la evolución de un producto se arriesga a construir una solución
elegante para el problema equivocado. El gerente que ponga poca
atención al proceso corre el riesgo de insertar métodos y herramientas

21
técnicos competentes, pero en el vacío. Aquel que se embarque sin un
plan sólido pone en peligro el éxito del proyecto.
La administración de proyectos de software es una actividad
sombrilla dentro de la ingeniería
de software. Comienza antes de iniciar cualquier actividad técnica
y continúa a lo largo del
modelado, construcción y despliegue del software de cómputo.
Cuatro P tienen influencia sustancial sobre la administración del
proyecto de software: personal, producto, proceso y proyecto. El personal
debe organizarse en equipos eficaces, motivados para hacer trabajo de
software de alta calidad, y coordinarse para lograr comunicación
efectiva. Los requerimientos del producto deben comunicarse de cliente
a desarrollador, dividirse (descomponerse) en sus partes constitutivas y
ubicarse para su trabajo por parte del equipo de software. El proceso
debe adaptarse al personal y al producto. Se selecciona un marco
conceptual común al proceso, se aplica un paradigma de ingeniería de
software adecuado y se elige un conjunto de tareas de trabajo para
realizar el trabajo. Finalmente, el proyecto debe organizarse de forma que
permita triunfar al equipo de software.
El ciclo de vida del proyecto es un conjunto de fases del mismo,
generalmente secuenciales y en ocasiones superpuestas, cuyo nombre y
número se determinan por las necesidades de gestión y control de la
organización u organizaciones que participan en el proyecto, la
naturaleza propia del proyecto y su área de aplicación. Un ciclo de vida
puede documentarse con ayuda de una metodología. El ciclo de vida
del proyecto puede ser determinado o conformado por los aspectos
únicos de la organización, de la industria o de la tecnología empleada.
Mientras que cada proyecto tiene un inicio y un final definidos, los
entregables específicos y las actividades que se llevan a cabo entre éstos
variarán ampliamente de acuerdo con el proyecto. El ciclo de vida
proporciona el marco de referencia básico para dirigir el proyecto,
independientemente del trabajo específico involucrado.

Modelo de cascada

El modelo de cascada es el modelo de paradigma más simple en

desarrollo de software. Sigue un modelo en que las fases funcionarán una
detrás de la otra de forma lineal. Lo que significa que solamente cuando

22
la primera fase se termina se puede empezar con la segunda, y así
progresivamente.

Este modelo asume que todo se lleva a cabo y tiene lugar tal y
como se había planeado en la fase anterior, y no es necesario pensar en
asuntos pasados que podrían surgir en la siguiente fase. Este modelo no
funcionará correctamente si se dejan asuntos de lado en la fase previa.
La naturaleza secuencial del modelo no permite volver atrás y deshacer
o volver a hacer acciones. Este modelo es recomendable cuando el
desarrollador ya ha diseñado y desarrollado softwares similares con
anterioridad, y por eso está al tanto de todos sus dominios.

Modelo repetitivo

23
 Este modelo guía el proceso de desarrollo de software en
repeticiones.

El software primero se desarrolla en menor escala y se siguen y

tienen en consideración todos los pasos. Entonces, por cada repetición,
más módulos y características son diseñados, codificados, evaluados y
añadidos al software. Cada ciclo produce un software completo, con
más características y capacidad que los previos. Después de cada
repetición, el equipo directivo puede concentrarse en la gestión de
riesgos y prepararse para la siguiente repetición. Como el ciclo incluye
pequeñas porciones de la totalidad del proceso software, es más fácil
gestionar el proceso de desarrollo, pero a la vez se consumen más
recursos.

Modelo en espiral

24
 Este modelo considera el riesgo, factor que otros modelos olvidan o
no prestan atención en el proceso. El modelo empieza determinando los
objetivos y las limitaciones del software al inicio de cada repetición. En la
siguiente etapa se crean los modelos de prototipo del software. Esto
incluye el análisis de riesgos. En la cuarta etapa es donde se prepara el
plan de la siguiente repetición.

Modelo V

El mayor inconveniente del modelo de cascada es que solo se pasa

a la siguiente fase cuando se completa la anterior, por tanto no es posible
volver atrás si se encuentra algún error en las etapas posteriores. El Modelo
V aporta opciones de evaluación del software en cada etapa de manera
inversa.

25
 En cada etapa, se crea la planificación de las pruebas y los casos
de pruebas para verificar y validar el producto según los requisitos de la
etapa. Por ejemplo, en la etapa de recogida de requisitos, el equipo de
evaluadores prepara las pruebas de caso correspondientes a los
requisitos. Más tarde, cuando el producto se desarrolla y está preparado
para ser evaluado, las pruebas de caso en esta etapa verifican el
software y su validez según sus requisitos.
Esto hace que tanto la verificación como la validación vayan en
paralelo. Este modelo también se conoce como modelo de validación y
verificación.

Modelo Big Bang

Este modelo es el modelo con la forma más simple. Requiere poca

planificación, mucha programación y también muchos fondos. Este
modelo se conceptualiza alrededor de la teoría de creación del universo
'Big Bang'. Tal como cuentan los científicos, después del big bang muchas
galaxias, planetas y estrellas evolucionaron. De la misma manera, si

26
reunimos muchos fondos y programación, quizá podemos conseguir el
mejor producto de software.

Para este modelo, se requiere poca planificación. No sigue ningún

proceso concreto, y a veces el cliente no está seguro de las futuras
necesidades y requisitos. Por tanto, la entrada o input respecto a los
requisitos es arbitraria.
Este modelo no es recomendable para grandes proyectos de
software, pero es bueno para aprender y experimentar.
La medición es una herramienta administrativa. Si se realiza
adecuadamente, ofrece entendimiento al gerente de un proyecto. Y,
como resultado, lo auxilia a él y al equipo de software para tomar
decisiones que conducirán hacia un proyecto exitoso.
Las métricas de proceso se recopilan a través de todos los
proyectos y durante largos espacios de tiempo. Su intención es
proporcionar un conjunto de indicadores de proceso que conduzca a
mejorar el proceso de software a largo plazo.
Las métricas de proyecto permiten al gerente de un proyecto de
software: 1) valorar el estado de un proyecto en marcha, 2) rastrear
riesgos potenciales, 3) descubrir áreas problema antes de que se vuelvan
“críticas”, 4) ajustar el flujo de trabajo o las tareas y 5) evaluar la habilidad
del equipo del proyecto para controlar la calidad de los productos
operativos del software.

27
2. Control de calidad de proyectos de tecnologías de
información
La calidad del software en el sentido más general se define como:
Proceso eficaz de software que se aplica de manera que crea un
producto útil que proporciona valor medible a quienes lo producen y a
quienes lo utilizan.
Un proceso eficaz de software establece la infraestructura que da
apoyo a cualquier esfuerzo
de elaboración de un producto de software de alta calidad.
Un producto útil entrega contenido, funciones y características que
el usuario final desea; sin embargo, de igual importancia es que entrega
estos activos en forma confiable y libre de errores.
Al agregar valor para el productor y para el usuario de un producto,
el software de alta calidad proporciona beneficios a la organización que
lo produce y a la comunidad de usuarios finales. La organización que
elabora el software obtiene valor agregado porque el software de alta
calidad requiere un menor esfuerzo de mantenimiento, menos errores que
corregir y poca asistencia al cliente.
Los Modelos de Calidad son aquellos documentos que integran la
mayor parte de las mejores prácticas, proponen temas de administración
en los que cada organización debe hacer énfasis, integran diferentes
prácticas dirigidas a los procesos clave y permiten medir los avances en
calidad.
Los Estándares de Calidad son aquellos que permiten definir un
conjunto de criterios de desarrollo que guían la forma en que se aplica la
Ingeniería del Software. Los estándares suministran los medios para que
todos los procesos se realicen de la misma forma y son una guía para
lograr la productividad y la calidad.
Los Modelos y/o Estándares permiten que las Empresas de Software
realicen sus tareas y funciones teniendo en cuenta la Calidad. Cualquier
organización que se dedica a la investigación, producción y
comercialización de software debe considerar la calidad, hoy con más
razón, donde existe un mercado en el cual el cliente es cada vez más
exigente, no sólo en lo que se refiere al precio, sino, sobre todo, en cuanto
a los servicios y a la confiabilidad que brindan los productos de software.
La calidad desempeña un rol determinante para la competitividad de la
empresa. Cuando una empresa está funcionando y decide implantar un
28
Modelo / Estándar de Calidad del Software, es señal que la empresa tiene
el propósito de permanecer y crecer en el mercado, ser competitiva,
proteger los intereses de los accionistas, cuidar la fuente de trabajo y
mejorar la calidad de vida de su personal.
Implantar Modelos o Estándares de Calidad tiene como objetivo
principal que las empresas desarrollen sistemáticamente, productos,
bienes y servicios de mejor calidad y cumplan con las necesidades y
deseos de los clientes. Para esto, se requiere de un Modelo / Estándar que:
permita: (1) unir la misión de la empresa y el esfuerzo de cada área en
una sinergia de resultados hacia la competitividad y la calidad de clase
mundial; y (2) tener procesos y procedimientos ágiles; y comprensibles
para todos los involucrados, pasando por las etapas de desarrollo,
prueba, producción y satisfacción del cliente.
La implantación de un Modelo o Estándar de Calidad del Software
implica un cambio de mentalidad y una formación en todo el personal
de la Empresa teniendo en cuenta qué tarea realiza cada persona. La
Calidad en una Empresa de Software requiere un cambio de cultura muy
significativo tanto en la forma de trabajar como de pensar.
La Gestión de la Calidad del Proyecto incluye los procesos y
actividades de la organización ejecutante que determinan
responsabilidades, objetivos y políticas de calidad a fin de que el
proyecto satisfaga las necesidades por la cuales fue emprendido.
Implementa el sistema de gestión de calidad por medio de políticas
y procedimientos, con actividades de mejora continua de los procesos
llevados a cabo durante todo el proyecto, según corresponda.
El enfoque básico de la gestión de calidad que se describe en esta
sección pretende ser compatible con el de la Organización Internacional
de Normalización (ISO). También es compatible con enfoques
propietarios sobre la gestión de calidad, tales como los recomendados
por Deming, Juran, Crosby y otros, así como con enfoques que no son
propietarios, como la Gestión de la Calidad Total (TQM), Six Sigma, Análisis
de Modos de Fallo y Efectos, Revisiones del Diseño, Opinión del Cliente,
Costo de la Calidad (COQ) y Mejora Continua.
La gestión moderna de la calidad complementa la dirección de
proyectos. Ambas disciplinas reconocen la importancia de:
 La satisfacción del cliente.

29
 Entender, evaluar, definir y gestionar las expectativas, de modo que
se cumplan los requisitos del cliente. Esto requiere una combinación de
conformidad con los requisitos (para asegurar que el proyecto produzca
aquello para lo cual fue emprendido) y adecuación para su uso (el
producto o servicio debe satisfacer necesidades reales).
 La prevención antes que la inspección.
Uno de los preceptos fundamentales de la gestión moderna de la
calidad establece que la calidad se planifica, se diseña y se integra (y no
se inspecciona). Por lo general, el costo de prevenir errores es mucho
menor que el de corregirlos cuando son detectados por una inspección.
 La mejora continua.
El ciclo planificar-hacer-revisar-actuar es la base para la mejora de
la calidad, según la definición de Shewhart, modificada por Deming.
Además, las iniciativas de mejora de la calidad emprendidas por la
organización ejecutante, tales como TQM y Six Sigma, deben mejorar
tanto la calidad de la dirección del proyecto, como la del producto del
proyecto. Los modelos de mejora de procesos incluyen Malcolm Baldrige,
OPM3® (Organizational Project Management Maturity Model) y CMMI®
(Capability Maturity Model Integration).
 La responsabilidad de la dirección.
El éxito requiere la participación de todos los miembros del equipo
del proyecto, pero proporcionar los recursos necesarios para lograr dicho
éxito sigue siendo responsabilidad de la dirección.
El costo de la calidad se refiere al costo total de todos los esfuerzos
relacionados con la calidad a lo largo del ciclo de vida del proyecto. Las
decisiones del proyecto pueden causar un impacto en los costos
operativos de calidad, como resultado de devoluciones de productos,
reclamaciones de garantía y campañas para retirar productos del
mercado. Por lo tanto, debido a la naturaleza temporal de un proyecto,
la organización patrocinadora puede elegir invertir en la mejora de la
calidad del producto, especialmente en lo que se refiere a la prevención
y evaluación de defectos para reducir el costo externo de la calidad.

Realizar el Aseguramiento de Calidad es el proceso que consiste en

auditar los requisitos de calidad y los resultados obtenidos a partir de

30
 medidas de control de calidad, a fin de garantizar que se utilicen
definiciones operacionales y normas de calidad adecuadas.

D. GESTIÓN DE REDES, BASES DE DATOS, SISTEMAS

OPERATIVOS Y LENGUAJE DE DESARROLLO

En esta área se evalúan los aspectos fundamentales de

implantación y administración de redes computacionales, así como el
modelado y desarrollo de sistemas de bases de datos; la configuración y
administración de sistemas operativos y los componentes esenciales de
un lenguaje de programación.

1. Gestión de redes de datos

Implementación de redes.

2. Gestión de bases de datos

Diseño de base de datos utilizando de normalización.

Administrador de la base de datos

Modificación de la base de datos

3. Gestión de sistemas operativos o lenguajes de desarrollo

Una computadora moderna consta de uno o más procesadores,
una memoria principal, discos, impresoras, un teclado, un ratón, una
pantalla o monitor, interfaces de red y otros dispositivos de entrada/salida.
En general es un sistema complejo. Si todos los programadores de
aplicaciones tuvieran que comprender el funcionamiento de todas estas
partes, no escribirían código alguno. Es más: el trabajo de administrar
todos estos componentes y utilizarlos de manera óptima es una tarea muy
desafiante. Por esta razón, las computadoras están equipadas con una
capa de software llamada sistema operativo, cuyo trabajo es
proporcionar a los programas de usuario un modelo de computadora
mejor, más simple y pulcro, así como encargarse de la administración de
todos los recursos antes mencionados.

Revisión del hardware de computadora.

31
 Un sistema operativo está íntimamente relacionado con el
hardware de la computadora sobre la que se ejecuta. Extiende el
conjunto de instrucciones de la computadora y administra sus recursos.
Para trabajar debe conocer muy bien el hardware, por lo menos en lo
que respecta a cómo aparece para el programador. Por esta razón,
revisaremos brevemente el hardware de computadora como se
encuentra en las computadoras personales modernas. Después de eso,
podemos empezar a entrar en los detalles acerca de qué hacen los
sistemas operativos y cómo funcionan.

Procesadores.
El “cerebro” de la computadora es la CPU, que obtiene las
instrucciones de la memoria y las ejecuta. El ciclo básico de toda CPU es
obtener la primera instrucción de memoria, decodificarla para determinar
su tipo y operandos, ejecutarla y después obtener, decodificar y ejecutar
las instrucciones subsiguientes. El ciclo se repite hasta que el programa
termina. De esta forma se ejecutan los programas.
Cada CPU tiene un conjunto específico de instrucciones que puede
ejecutar. Como el acceso a la memoria para obtener una instrucción o
palabra de datos requiere mucho más tiempo que ejecutar una
instrucción, todas las CPU contienen ciertos registros en su interior para
contener las variables clave y los resultados temporales. Debido a esto, el
conjunto de instrucciones generalmente contiene instrucciones para
cargar una palabra de memoria en un registro y almacenar una palabra
de un registro en la memoria. Otras instrucciones combinan dos
operandos de los registros, la memoria o ambos en un solo resultado,
como la operación de sumar dos palabras y almacenar el resultado en
un registro o la memoria.
Además de los registros generales utilizados para contener variables
y resultados temporales, la mayoría de las computadoras tienen varios
registros especiales que están visibles para el programador. Uno de ellos
es el contador de programa (program counter), el cual contiene la
dirección de memoria de la siguiente instrucción a obtener. Una vez que
se obtiene esa instrucción, el contador de programa se actualiza para
apuntar a la siguiente.
Otro registro es el apuntador de pila (stack pointer), el cual apunta
a la parte superior de la pila (stack) actual en la memoria. La pila contiene
un conjunto de valores por cada procedimiento al que se ha entrado
pero del que todavía no se ha salido. El conjunto de valores en la pila por

32
procedimiento contiene los parámetros de entrada, las variables locales
y las variables temporales que no se mantienen en los registros.
Otro de los registros es PSW (Program Status Word; Palabra de
estado del programa). Este registro contiene los bits de código de
condición, que se asignan cada vez que se ejecutan las instrucciones de
comparación, la prioridad de la CPU, el modo (usuario o kernel) y varios
otros bits de control. Los programas de usuario pueden leer normalmente
todo el PSW pero por lo general sólo pueden escribir en algunos de sus
campos. El PSW juega un papel importante en las llamadas al sistema y
en las operaciones de E/S.
El sistema operativo debe estar al tanto de todos los registros.
Cuando la CPU se multiplexa en el tiempo, el sistema operativo detiene
con frecuencia el programa en ejecución para (re)iniciar otro. Cada vez
que detiene un programa en ejecución, el sistema operativo debe
guardar todos los registros para poder restaurarlos cuando el programa
continúe su ejecución.

Memoria
El segundo componente importante en cualquier computadora es
la memoria. En teoría, una memoria debe ser en extremo rápida (más
rápida que la velocidad de ejecución de una instrucción, de manera que
la memoria no
detenga a la
CPU), de gran
tamaño y muy
económica.
Ninguna
tecnología en
la actualidad
cumple con
todos estos objetivos, por lo que se adopta una solución distinta. El sistema
de memoria está construido como una jerarquía de capas. Las capas
superiores tienen mayor velocidad, menor capacidad y mayor costo por
bit que las capas inferiores, a menudo por factores de mil millones o más.

Discos
El siguiente lugar en la jerarquía corresponde al disco magnético
(disco duro). El almacenamiento en disco es dos órdenes de magnitud
más económico que la RAM por cada bit, y a menudo es dos órdenes de

33
magnitud más grande en tamaño también. El único problema es que el
tiempo para acceder en forma aleatoria a los datos en ella es de cerca
de tres órdenes de magnitud más lento. Esta baja velocidad se debe al
hecho de que un disco es un dispositivo mecánico.

Cintas
La última capa de la jerarquía en la memoria es la cinta magnética.
Este medio se utiliza con frecuencia como respaldo para el
almacenamiento en disco y para contener conjuntos de datos muy
extensos. Para acceder a una cinta, primero debe colocarse en un lector
de cinta, ya sea que lo haga una persona o un robot (el manejo
automatizado de las cintas es común en las instalaciones con bases de
datos enormes).

Dispositivos de E/S
La CPU y la memoria no son los únicos recursos que el sistema
operativo debe administrar. Los dispositivos de E/S también interactúan
mucho con el sistema operativo. Los dispositivos de E/S generalmente
constan de dos partes: un dispositivo controlador y el dispositivo en sí. El
dispositivo controlador es un chip o conjunto de chips que controla
físicamente el dispositivo. Por ejemplo, acepta los comandos del sistema
operativo para leer datos del dispositivo y los lleva a cabo.

Buses
A medida que los procesadores y las memorias se hicieron más
veloces, la habilidad de un solo bus (y sin duda, del bus de la IBM PC) de
manejar todo el tráfico se forzaba hasta el punto de quiebre. Algo tenía
que ceder. Como resultado se agregaron más buses, tanto para
dispositivos de E/S más rápidos como para el tráfico entre la CPU y la
memoria.

Arranque de la computadora
El BIOS contiene software de E/S de bajo nivel, incluyendo
procedimientos para leer el teclado, escribir en la pantalla y realizar
operaciones de E/S de disco, entre otras cosas. Hoy en día está contenido
en una RAM tipo flash que es no volátil pero el sistema operativo puede
actualizarla cuando se encuentran errores en el BIOS.
Cuando se arranca la computadora, el BIOS inicia su ejecución.
Primero hace pruebas para ver cuánta RAM hay instalada y si el teclado

34
junto con otros dispositivos básicos están instalados y responden en forma
correcta. Empieza explorando los buses ISA y PCI para detectar todos los
dispositivos conectados a ellos. Comúnmente, algunos de estos
dispositivos son heredados (es decir, se diseñaron antes de inventar la
tecnología plug and play), además de tener valores fijos para los niveles
de interrupciones y las direcciones de E/S (que posiblemente se
establecen mediante interruptores o puentes en la tarjeta de E/S, pero
que el sistema operativo no puede modificar). Estos dispositivos se
registran; y los dispositivos plug and play también. Si los dispositivos
presentes son distintos de los que había cuando el sistema se inició por
última vez, se configuran los nuevos dispositivos.
Después, el BIOS determina el dispositivo de arranque, para lo cual
prueba una lista de dispositivos almacenada en la memoria CMOS. El
usuario puede cambiar esta lista si entra a un programa de configuración
del BIOS, justo después de iniciar el sistema. Por lo general, se hace un
intento por arrancar del disco flexible, si hay uno presente. Si eso falla, se
hace una consulta a la unidad de CD-ROM para ver si contiene un CD-
ROM que se pueda arrancar. Si no hay disco flexible ni CD-ROM que
puedan iniciarse, el sistema se arranca desde el disco duro. El primer
sector del dispositivo de arranque se lee y se coloca en la memoria, para
luego ejecutarse. Este sector contiene un programa que por lo general
examina la tabla de particiones al final del sector de arranque, para
determinar qué partición está activa. Después se lee un cargador de
arranque secundario de esa partición. Este cargador lee el sistema
operativo de la partición activa y lo inicia.
Luego, el sistema operativo consulta al BIOS para obtener la
información de configuración. Para cada dispositivo, comprueba si tiene
el driver correspondiente. De no ser así, pide al usuario que inserte un CD-
ROM que contenga el driver (suministrado por el fabricante del
dispositivo). Una vez que tiene los drivers de todos los dispositivos, el
sistema operativo los carga en el kernel. Después inicializa sus tablas, crea
los procesos de segundo plano que se requieran, y arranca un programa
de inicio de sesión o GUI.

Los tipos de sistemas operativos

Sistemas operativos de mainframe
En el extremo superior están los sistemas operativos para las
mainframes, las computadoras del tamaño de un cuarto completo que
aún se encuentran en los principales centros de datos corporativos. La

35
diferencia entre estas computadoras y las personales está en su
capacidad de E/S. Una mainframe con 1000 discos y millones de
gigabytes de datos no es poco común; una computadora personal con
estas especificaciones sería la envidia de los amigos del propietario. Las
mainframes también están volviendo a figurar en el ámbito
computacional como servidores Web de alto rendimiento, servidores para
sitios de comercio electrónico a gran escala y servidores para
transacciones de negocio a negocio.
Los sistemas operativos para las mainframes están profundamente
orientados hacia el procesamiento de muchos trabajos a la vez, de los
cuales la mayor parte requiere muchas operaciones de E/S. Por lo general
ofrecen tres tipos de servicios: procesamiento por lotes, procesamiento de
transacciones y tiempo compartido. Un sistema de procesamiento por
lotes procesa los trabajos de rutina sin que haya un usuario interactivo
presente. El procesamiento de reclamaciones en una compañía de
seguros o el reporte de ventas para una cadena de tiendas son
actividades que se realizan comúnmente en modo de procesamiento por
lotes. Los sistemas de procesamiento de transacciones manejan grandes
cantidades de pequeñas peticiones, por ejemplo: el procesamiento de
cheques en un banco o las reservaciones en una aerolínea. Cada unidad
de trabajo es pequeña, pero el sistema debe manejar cientos o miles por
segundo. Los sistemas de tiempo compartido permiten que varios usuarios
remotos ejecuten trabajos en la computadora al mismo tiempo, como
consultar una gran base de datos. Estas funciones están íntimamente
relacionadas; a menudo los sistemas operativos de las mainframes las
realizan todas. Un ejemplo de sistema operativo de mainframe es el
OS/390, un descendiente del OS/360. Sin embargo, los sistemas operativos
de mainframes están siendo reemplazados gradualmente por variantes
de UNIX, como Linux.
Sistemas operativos de servidores
En el siguiente nivel hacia abajo se encuentran los sistemas
operativos de servidores. Se ejecutan en servidores, que son
computadoras personales muy grandes, estaciones de trabajo o incluso
mainframes. Dan servicio a varios usuarios a la vez a través de una red y
les permiten compartir los recursos de hardware y de software. Los
servidores pueden proporcionar servicio de impresión, de archivos o Web.
Los proveedores de Internet operan muchos equipos servidores para dar
soporte a sus clientes y los sitios Web utilizan servidores para almacenar las
páginas Web y hacerse cargo de las peticiones entrantes. Algunos

36
sistemas operativos de servidores comunes son Solaris, FreeBSD, Linux y
Windows Server 200x.
Sistemas operativos de multiprocesadores
Una manera cada vez más común de obtener poder de cómputo
de las grandes ligas es conectar varias CPU en un solo sistema.
Dependiendo de la exactitud con la que se conecten y de lo que se
comparta, estos sistemas se conocen como computadoras en paralelo,
multicomputadoras o multiprocesadores. Necesitan sistemas operativos
especiales, pero a menudo son variaciones de los sistemas operativos de
servidores con características especiales para la comunicación,
conectividad y consistencia.
Con la reciente llegada de los chips multinúcleo para las
computadoras personales, hasta los sistemas operativos de equipos de
escritorio y portátiles convencionales están empezando a lidiar con
multiprocesadores de al menos pequeña escala y es probable que el
número de núcleos aumente con el tiempo. Por fortuna, se conoce
mucho acerca de los sistemas operativos de multiprocesadores gracias a
los años de investigación previa, por lo que el uso de este conocimiento
en los sistemas multinúcleo no debe presentar dificultades. La parte difícil
será hacer que las aplicaciones hagan uso de todo este poder de
cómputo. Muchos sistemas operativos populares (incluyendo Windows y
Linux) se ejecutan en multiprocesadores.
Sistemas operativos de computadoras personales
La siguiente categoría es el sistema operativo de computadora
personal. Todos los sistemas operativos modernos soportan la
multiprogramación, con frecuencia se inician docenas de programas al
momento de arrancar el sistema. Su trabajo es proporcionar buen soporte
para un solo usuario. Se utilizan ampliamente para el procesamiento de
texto, las hojas de cálculo y el acceso a Internet. Algunos ejemplos
comunes son Linux, FreeBSD, Windows Vista y el sistema operativo
Macintosh. Los sistemas operativos de computadora personal son tan
conocidos que tal vez no sea necesario presentarlos con mucho detalle.
De hecho, muchas personas ni siquiera están conscientes de que existen
otros tipos de sistemas operativos.
Sistemas operativos de computadoras de bolsillo
Una computadora de bolsillo o PDA (Personal Digital Assitant,
Asistente personal digital) es una computadora que cabe en los bolsillos y

37
realiza una pequeña variedad de funciones, como libreta de direcciones
electrónica y bloc de notas. Además, hay muchos teléfonos celulares muy
similares a los PDAs, con la excepción de su teclado y pantalla. En efecto,
los PDAs y los teléfonos celulares se han fusionado en esencia y sus
principales diferencias se observan en el tamaño, el peso y la interfaz de
usuario. Casi todos ellos se basan en CPUs de 32 bits con el modo
protegido y ejecutan un sofisticado sistema operativo.
Los sistemas operativos que operan en estos dispositivos de bolsillo
son cada vez más sofisticados, con la habilidad de proporcionar telefonía,
fotografía digital y otras funciones. Muchos de ellos también ejecutan
aplicaciones desarrolladas por terceros. De hecho, algunos están
comenzando a asemejarse a los sistemas operativos de computadoras
personales de hace una década. Una de las principales diferencias entre
los dispositivos de bolsillo y las PCs es que los primeros no tienen discos
duros de varios cientos de gigabytes, lo cual cambia rápidamente. Dos
de los sistemas operativos más populares para los dispositivos de bolsillo
son Symbian OS y Palm OS.
Sistemas operativos integrados
Los sistemas integrados (embedded), que también se conocen
como incrustados o embebidos, operan en las computadoras que
controlan dispositivos que no se consideran generalmente como
computadoras, ya que no aceptan software instalado por el usuario.
Algunos ejemplos comunes son los hornos de microondas, las televisiones,
los autos, los grabadores de DVDs, los teléfonos celulares y los
reproductores de MP3. La propiedad principal que diferencia a los
sistemas integrados de los dispositivos de bolsillo es la certeza de que
nunca se podrá ejecutar software que no sea confiable. No se pueden
descargar nuevas aplicaciones en el horno de microondas; todo el
software se encuentra en ROM. Esto significa que no hay necesidad de
protección en las aplicaciones, lo cual conlleva a cierta simplificación. Los
sistemas como QNX y VxWorks son populares en este dominio.
Sistemas operativos de nodos sensores
Las redes de pequeños nodos sensores se están implementando
para varios fines. Estos nodos son pequeñas computadoras que se
comunican entre sí con una estación base, mediante el uso de
comunicación inalámbrica. Estas redes de sensores se utilizan para
proteger los perímetros de los edificios, resguardar las fronteras
nacionales, detectar incendios en bosques, medir la temperatura y la

38
precipitación para el pronóstico del tiempo, deducir información acerca
del movimiento de los enemigos en los campos de batalla y mucho más.
Los sensores son pequeñas computadoras con radios integrados y
alimentadas con baterías. Tienen energía limitada y deben trabajar
durante largos periodos al exterior y desatendidas, con frecuencia en
condiciones ambientales rudas. La red debe ser lo bastante robusta como
para tolerar fallas en los nodos individuales, que ocurren con mayor
frecuencia a medida que las baterías empiezan a agotarse.
Cada nodo sensor es una verdadera computadora, con una CPU,
RAM, ROM y uno o más sensores ambientales. Ejecuta un sistema
operativo pequeño pero real, por lo general manejador de eventos, que
responde a los eventos externos o realiza mediciones en forma periódica
con base en un reloj interno. El sistema operativo tiene que ser pequeño y
simple debido a que los nodos tienen poca RAM y el tiempo de vida de
las baterías es una cuestión importante. Además, al igual que con los
sistemas integrados, todos los programas se cargan por adelantado; los
usuarios no inician repentinamente programas que descargaron de
Internet, lo cual simplifica el diseño en forma considerable. TinyOS es un
sistema operativo bien conocido para un nodo sensor.
Sistemas operativos en tiempo real
Otro tipo de sistema operativo es el sistema en tiempo real. Estos
sistemas se caracterizan por tener el tiempo como un parámetro clave.
Por ejemplo, en los sistemas de control de procesos industriales, las
computadoras en tiempo real tienen que recolectar datos acerca del
proceso de producción y utilizarlos para controlar las máquinas en la
fábrica. A menudo hay tiempos de entrega estrictos que se deben
cumplir. Por ejemplo, si un auto se desplaza sobre una línea de
ensamblaje, deben llevarse a cabo ciertas acciones en determinados
instantes. Si un robot soldador realiza su trabajo de soldadura antes o
después de tiempo, el auto se arruinará. Si la acción debe ocurrir sin
excepción en cierto momento (o dentro de cierto rango), tenemos un
sistema en tiempo real duro. Muchos de estos sistemas se encuentran en
el control de procesos industriales, en aeronáutica, en la milicia y en áreas
de aplicación similares. Estos sistemas deben proveer garantías absolutas
de que cierta acción ocurrirá en un instante determinado.
Sistemas operativos de tarjetas inteligentes
Los sistemas operativos más pequeños operan en las tarjetas
inteligentes, que son dispositivos del tamaño de una tarjeta de crédito que
39
contienen un chip de CPU. Tienen varias severas restricciones de poder
de procesamiento y memoria. Algunas se energizan mediante contactos
en el lector en el que se insertan, pero las tarjetas inteligentes sin contactos
se energizan mediante inducción, lo cual limita en forma considerable las
cosas que pueden hacer. Algunos sistemas de este tipo pueden realizar
una sola función, como pagos electrónicos; otros pueden llevar a cabo
varias funciones en la misma tarjeta inteligente. A menudo éstos son
sistemas propietarios.

Conceptos básicos de los sistemas operativos

La mayoría de los sistemas operativos proporcionan ciertos
conceptos básicos y abstracciones tales como procesos, espacios de
direcciones y archivos, que son la base para comprender su
funcionamiento.
Procesos
Un proceso es en esencia un programa en ejecución. Cada
proceso tiene asociado un espacio de direcciones, una lista de
ubicaciones de memoria que va desde algún mínimo (generalmente 0)
hasta cierto valor máximo, donde el proceso puede leer y escribir
información. El espacio de direcciones contiene el programa ejecutable,
los datos del programa y su pila. También hay asociado a cada proceso
un conjunto de recursos, que comúnmente incluye registros (el contador
de programa y el apuntador de pila, entre ellos), una lista de archivos
abiertos, alarmas pendientes, listas de procesos relacionados y toda la
demás información necesaria para ejecutar el programa. En esencia, un
proceso es un recipiente que guarda toda la información necesaria para
ejecutar un programa.
Espacios de direcciones
Cada computadora tiene cierta memoria principal que utiliza para
mantener los programas en ejecución. En un sistema operativo muy simple
sólo hay un programa a la vez en la memoria. Para ejecutar un segundo
programa se tiene que quitar el primero y colocar el segundo en la
memoria. Los sistemas operativos más sofisticados permiten colocar varios
programas en memoria al mismo tiempo. Para evitar que interfieran unos
con otros (y con el sistema operativo), se necesita cierto mecanismo de
protección. Aunque este mecanismo tiene que estar en el hardware, es
controlado por el sistema operativo.
Archivos

40
 Otro concepto clave de casi todos los sistemas operativos es el
sistema de archivos. Como se dijo antes, una de las funciones principales
del sistema operativo es ocultar las peculiaridades de los discos y demás
dispositivos de E/S, presentando al programador un modelo abstracto
limpio y agradable de archivos independientes del dispositivo. Sin duda
se requieren las llamadas al sistema para crear los archivos, eliminarlos,
leer y escribir en ellos. Antes de poder leer un archivo, debe localizarse en
el disco para abrirse y una vez que se ha leído información del archivo
debe cerrarse, por lo que se proporcionan llamadas para hacer estas
cosas.

41