Fundamentos de Ingenieria de Software

FUNDAMENTOS DE INGENIERIA DE SOFTWARE
MODULO 1 INTRODUCCION
Objetivo
1.1 Qu es la ingeniera del software?
1.2 Paradigmas
1.3 Importancia de esta disciplina
MODULO 2 DESARROLLO Y GESTION DE PROYECTOS INFORMATICOS.
Objetivo
2.1 Mtricas.
2.2 Estimacin.
2.3 Planificacin.
MODULO 3 ANALISIS DE SISTEMAS
Objetivo
3.1 La informacin como un recurso de las organizaciones.
3.2 Papel del analista de sistemas.
3.3 Anlisis de los requerimientos de informacin.
3.3.1 Tcnicas de recopilacin de informacin.
3.3.2 Prototipos.
3.4 Anlisis orientado a objetos
3.4.1 Modelo esttico(estructurado).
3.4.2 Modelo dinmico (comportamiento)
MODULO 4 DISEO DE SISTEMAS.
Objetivo
4.1 Objetivos del diseo.
4.2 Cmo pasar del anlisis al diseo.
4.3 Diseo Orientado a Objetos.
4.4 Diseo de salidas.
4.5 Diseo de entradas.
4.6 Diseo de bases de datos.
4.7 Diseo de la interfaz hombre-mquina.
4.8 Diseo en ambiente de redes.
4.9 Diseo en tiempo real.
Modulo 5 CODIFICACION
Objetivo
5.1 Cmo pasar del diseo a la codificacin.
5.2 Documentacin del cdigo.
5.3 Declaracin de datos.
5.4 Construccin de sentencias.
5.5 Entrada-salida.
5.6 Reutilizacin.
5.7 Uso de bibliotecas.

5.8 Eficiencia.
MODULO 6 PRUEBAS E IMPLANTACION DE SISTEMAS
Objetivo
6.1 Diseo y ejecucin de pruebas de software.
6.2 Enfoques de implementacin.
6.3 Capacitacin de usuarios.
6.4 Seguridad de sistemas.
MODULO 7 INGENIERIA DEL SOFTWARE ASISTIDA POR COMPUTADORAS(CASE)
Objetivo
7.1 Concepto de CASE.
7.2 Composicin de un CASE.
7.3 Principales CASE del mercado y su uso.
Bibliografia
1.1 QUE ES LA INGENIERIA DE SOFTWARE?
Es la ciencia que ayuda a elaborar sistemas con el fin de que sea econmico, fiable y funcione
eficientemente sobre las maquinas reales.
La ingeniera de software surge de la ingeniera de sistemas y de hardware. Abarca un conjunto
de 3 elementos clave: mtodos, herramientas y procedimientos, estos facilitan al gestor a
controlar el proceso de desarrollo de software y suministra a los que practique dicha ingeniera
las bases para construir software de alta calidad.
Los mtodos de la ingeniera de software. Suministran el cmo construir tcnicamente el
software. Los mtodos abarcan un amplio espectro de tareas que incluyen: planificacin y
estimacin de proyectos, anlisis de los requerimientos del sistema y del software, diseo de
procedimientos algoritmicos, codificacin, prueba y mantenimiento.
Los mtodos de la ingeniera de software introducen frecuentemente una notacin especial
orientada al lenguaje o grfica y a un conjunto de criterios para la calidad del software.
Las herramientas de ingeniera de software. Suministran un soporte automtico o
semiautomtico para los mtodos. Cuando se integran las herramientas de forma que la
informacin creada por una herramienta pueda ser usada por otra, se establece un sistema
para el soporte del desarrollo del software llamado ingeniera de software asistido por
computadora, por mencionar alguna de estas herramientas existen las herramientas CASE.
CASE[(Ingeniera de software asistida por computadora) computer aided software engineering].
Combina del software, hardware y base de datos para crear un entorno de la ingeniera de
software. Las herramientas son como voy a aplicar los mtodos para tener un desarrollo.
Las herramientas de ingeniera de software son los mtodos necesarios para desarrollar el
sistema.
Los procedimientos de la ingeniera de software. Son la cola que paga a los mtodos y
herramientas, facilita un desarrollo racional y oportuno del software de computadoras.
Los procedimientos definen la secuencia en la que se aplican los mtodos, las entregas que se
requieren y los controles que ayuden asegurar, la calidad y coordinar los cambios y las guas
que facilitan a los gestores de software establecer el desarrollo.
Actividades Obligatorias
o
o
Investigue otras 2 definiciones de ingeniera de software.

La ingeniera de software abarca un conjunto de 3 elementos clave, explique
cada uno de ellos.
Actividades sugeridas
o
Cree su propia definicin de lo que es la ingeniera de software.
Recursos para ampliar el tema

Pgs. 17-18, Ingeniera de software un enfoque prctico, 4a. edicin, Roger S. Pressman, Ed.
Mc Graw Hill, 1997.
Autoevaluacin
1.
2.
3.
4.
5.
Qu es la ingeniera de software?
Para qu son los mtodos de la ingeniera de software?
Qu son los procedimientos?
Qu son las herramientas?
Para que nos sirven las herramientas?
1.2 PARADIGMAS
La ingeniera de software esta compuesta por una serie de pasos de abarcan los metodos, las
herramientas y los procedimientos antes mencionados. estos pasos se denominan
frecuentemente paradigmas de la ingenieria de software. La eleccin de un paradigma para la
ingeniera de software se lleva a cabo de acuerdo con la naturaleza del proyecto y de la
aplicacin, los metodos, herramientas a usar, los controles y entregas requeridos.
Gama de paradigmas de la ingeniera de software:
EL PROCESO
Las fases genricas que caracterizan el proceso de software (definicin, desarrollo y

mantenimiento) son aplicables a todo software. El problema es seleccionar el modelo de
proceso apropiado para la ingeniera de software que debe aplicarse en el proyecto.
El gestor del proyecto debe decidir que mtodo de proceso es el mas adecuado para el
proyecto, despus debe definir un plan preliminar basado en un conjunto de actividades
estructurarles validas para cualquier proyecto. Una vez establecido el plan preliminar, empieza
la descomposicin del proceso. Es decir, se debe crear un plan completo reflejando las tareas
requeridas a las personas para cubrir las actividades estructurales.
Maduracin Del Problema Y El Proceso.

La planificacin del proyecto empieza con la maduracin del problema y del proceso. Todas las
funciones que se deben tratar dentro de un proceso de ingeniera por el equipo de software
deben pasar por el conjunto de actividades estructurales que se han definido por una
organizacin de software. Asuma que la organizacin ha adoptado el siguiente conjunto de
actividades estructurales:
Comunicacin con el cliente: tareas requeridas para establecer una comunicacin

eficiente entre el desarrollo y el cliente.
Planificacin: Tareas requeridas para definir los recursos, la planificacin temporal del
proyecto y cualquier informacin relativa a el.
Anlisis de riesgo: Tareas requeridas para valorar los riesgos tcnicos y de gestin.
Ingeniera: Tareas requeridas para construir una o mas representaciones de la
aplicacin.
Construccin y entrega: Tareas requeridas para construir, probar, instalar y
proporcionar asistencia al usuario. (ejemplo: documentacin y entrenamiento).
Evaluacin del cliente: Tareas requeridas para obtener la informacin de la opinin del
cliente basadas en la evaluacin de las representaciones de software creadas durante
la fase de ingeniera e implementadas durante la fase de ingeniera e implementadas
durante la fase de instalacin.
Los miembros del equipo que trabajan en cada funcin aplicaran todas las actividades
estructurales. En esencia, se crea una matriz similar a la que se muestra en la figura. Cada
funcin principal del problema se lista en una columna de la izquierda. Las actividades
estructurales se listan en la fila de arriba. las tareas de trabajo de la ingeniera de software se
introducirn en la fila siguiente. El trabajo de gestor del proyecto es estimar los requisitos de
recursos para cada celda de la matriz, poner fechas de inicio y finalizacin para las tareas
asociadas con cada celda y los productos a fabricas como consecuencia de cada celda.
Maduracin del problema y proceso:
Descomposicin Del Proceso
Una vez que se ha elegido el modelo de proceso, la estructura comn de proceso (ECP) se
adapta a l. En todos los casos, la ECP (comunicacin con el cliente, planificacin, anlisis de
riesgo, ingeniera, construccin, entrega y evaluacin del cliente) puede adaptarse al
paradigma. Funcionara para modelos lineales, para modelos interactivos e incremntales, para
modelos de evolucin e incluso para modelos concurrentes o de ensamblaje de componente.
La ECP es invariable y sirve como base para todo el trabajo de software realizado por una
organizacin.
La descomposicin de trabajo empieza cuando el gestor del proyecto pregunta: "cmo vamos
a realizar esta actividad ECP?". Por ejemplo, un pequeo proyecto, relativamente simple,
requiere las siguientes tareas para la actividad de comunicacin con el cliente:
1.- Desarrollar una lista de aspectos que se han de clasificar.
2.- Reunirse con el cliente para resolver los aspectos que se han de clasificar.
3.- Desarrollar conjuntamente una exposicin del mbito del proyecto.
4.- Revisar el alcance del proyecto con todos los implicados.
5.-Modificar el alcance del proyecto cuando se requiera.
Estos acontecimientos pueden ocurrir en un periodo de menos de 48 horas. Representa una
descomposicin del problema apropiado para proyectos pequeos relativamente sencillos.
Ahora, consideremos un proyecto mas complejo que tenga un mbito mas amplio y un mayor
impacto comercial. Un proyecto como ese podra requerir las siguientes tareas para la actividad
de comunicacin con el cliente:
1.
2.
3.
4.
5.
6.
7.
8.
9.
10.
Revisar la peticin del cliente.

Planificar y programar una reunin formal con el cliente.
Realizar una investigacin para definir soluciones propuestas y enfoques existentes.
Preparar un "documento de trabajo" y una agenda par la reunin formal.
Realizar una reunin.
Desarrollar conjuntamente mini-especificaciones que reflejan la informacin, funcin y
caractersticas de comportamiento de software.
Revisar todas las mini-especificaciones para comprobar su correccin, su consistencia
y sus ambigedades.
Ensamblar las mini-especificaciones en un documento de alcance del proyecto.
Revisar ese documento general con todo lo que pueda afectar.
Modificar el documento de alcance del proyecto cuando se requiera.
Ambos proyectos realizan la actividad estructural que denominamos comunicacin con el

cliente, pero el equipo del primer proyecto lleva a cabo la mitad de tareas de ingeniera del
software que el segundo.
o
o
o
Cual de los paradigmas de la ingeniera de software sera ms til para las

aplicaciones del software?Porque?.
Proporcione tres ejemplos de tcnicas de 4 generacin.
Describa el modelo concurrente
o
o
A medida que vaya hacia afuera del modelo espiral qu puede decir del
software que se esta desarrollando?
Explique los pasos tradicionales de cualquier modelo.
o
o
o
Proporcione cinco ejemplos de desarrollo del software que sean adecuados

para construir prototipos. Nombre dos o tres aplicaicones que fueran ms
dificiles para construir prototipos.
Cmo seleccionar el modelo adecuado?.
Explique como el paradigma ciclo de vida clasico y el de construccin de
prototipos pueden acomodarse en el modelo espiral.

pags. 21-32, 46-47, Ingeniera de software. un enfoque prctico, 4a. edicin, Roger S.
Pressman, Ed. Mc Graw Hill, 1997.
Autoevaluacin
1.
2.
3.
4.
5.
Cuales son las carcteriscticas del paradigma ciclo de vida clsico?

En que consiste el paradigma de construccin de prototipos?
Cuales son los pasos a seguir en el paradigma espiral?
Cules son las desventajas del modelo DRA?
Cul es el pardigma de tcnicas de cuarta generacin?
EL PROCESO
Las fases genricas que caracterizan el proceso de software (definicin, desarrollo y

mantenimiento) son aplicables a todo software. El problema es seleccionar el modelo de
proceso apropiado para la ingeniera de software que debe aplicarse en el proyecto.
El gestor del proyecto debe decidir que mtodo de proceso es el mas adecuado para el
proyecto, despus debe definir un plan preliminar basado en un conjunto de actividades
estructurarles validas para cualquier proyecto. Una vez establecido el plan preliminar, empieza
la descomposicin del proceso. Es decir, se debe crear un plan completo reflejando las tareas
requeridas a las personas para cubrir las actividades estructurales.
Maduracin Del Problema Y El Proceso.

La planificacin del proyecto empieza con la maduracin del problema y del proceso. Todas las
funciones que se deben tratar dentro de un proceso de ingeniera por el equipo de software
deben pasar por el conjunto de actividades estructurales que se han definido por una
organizacin de software. Asuma que la organizacin ha adoptado el siguiente conjunto de
actividades estructurales:
Comunicacin con el cliente: tareas requeridas para establecer una comunicacin

eficiente entre el desarrollo y el cliente.
Planificacin: Tareas requeridas para definir los recursos, la planificacin temporal del
proyecto y cualquier informacin relativa a el.
Anlisis de riesgo: Tareas requeridas para valorar los riesgos tcnicos y de gestin.
Ingeniera: Tareas requeridas para construir una o mas representaciones de la
aplicacin.
Construccin y entrega: Tareas requeridas para construir, probar, instalar y
proporcionar asistencia al usuario. (ejemplo: documentacin y entrenamiento).
Evaluacin del cliente: Tareas requeridas para obtener la informacin de la opinin del
cliente basadas en la evaluacin de las representaciones de software creadas durante
la fase de ingeniera e implementadas durante la fase de ingeniera e implementadas
durante la fase de instalacin.
Los miembros del equipo que trabajan en cada funcin aplicaran todas las actividades
estructurales. En esencia, se crea una matriz similar a la que se muestra en la figura. Cada
funcin principal del problema se lista en una columna de la izquierda. Las actividades
estructurales se listan en la fila de arriba. las tareas de trabajo de la ingeniera de software se
introducirn en la fila siguiente. El trabajo de gestor del proyecto es estimar los requisitos de
recursos para cada celda de la matriz, poner fechas de inicio y finalizacin para las tareas
asociadas con cada celda y los productos a fabricas como consecuencia de cada celda.
Maduracin del problema y proceso:
Descomposicin Del Proceso
Una vez que se ha elegido el modelo de proceso, la estructura comn de proceso (ECP) se
adapta a l. En todos los casos, la ECP (comunicacin con el cliente, planificacin, anlisis de
riesgo, ingeniera, construccin, entrega y evaluacin del cliente) puede adaptarse al
paradigma. Funcionara para modelos lineales, para modelos interactivos e incremntales, para
modelos de evolucin e incluso para modelos concurrentes o de ensamblaje de componente.
La ECP es invariable y sirve como base para todo el trabajo de software realizado por una
organizacin.
La descomposicin de trabajo empieza cuando el gestor del proyecto pregunta: "cmo vamos
a realizar esta actividad ECP?". Por ejemplo, un pequeo proyecto, relativamente simple,
requiere las siguientes tareas para la actividad de comunicacin con el cliente:
1.- Desarrollar una lista de aspectos que se han de clasificar.
2.- Reunirse con el cliente para resolver los aspectos que se han de clasificar.
3.- Desarrollar conjuntamente una exposicin del mbito del proyecto.
4.- Revisar el alcance del proyecto con todos los implicados.
5.-Modificar el alcance del proyecto cuando se requiera.
Estos acontecimientos pueden ocurrir en un periodo de menos de 48 horas. Representa una
descomposicin del problema apropiado para proyectos pequeos relativamente sencillos.
Ahora, consideremos un proyecto mas complejo que tenga un mbito mas amplio y un mayor
impacto comercial. Un proyecto como ese podra requerir las siguientes tareas para la actividad
de comunicacin con el cliente:
1.
2.
3.
4.
5.
6.
7.
8.
9.
10.
Revisar la peticin del cliente.

Planificar y programar una reunin formal con el cliente.
Realizar una investigacin para definir soluciones propuestas y enfoques existentes.
Preparar un "documento de trabajo" y una agenda par la reunin formal.
Realizar una reunin.
Desarrollar conjuntamente mini-especificaciones que reflejan la informacin, funcin y
caractersticas de comportamiento de software.
Revisar todas las mini-especificaciones para comprobar su correccin, su consistencia
y sus ambigedades.
Ensamblar las mini-especificaciones en un documento de alcance del proyecto.
Revisar ese documento general con todo lo que pueda afectar.
Modificar el documento de alcance del proyecto cuando se requiera.
Ambos proyectos realizan la actividad estructural que denominamos comunicacin con el

cliente, pero el equipo del primer proyecto lleva a cabo la mitad de tareas de ingeniera del
software que el segundo.
o
o
o
o
o
Cual de los paradigmas de la ingeniera de software sera ms til para las

aplicaciones del software?Porque?.
Proporcione tres ejemplos de tcnicas de 4 generacin.
Describa el modelo concurrente
A medida que vaya hacia afuera del modelo espiral qu puede decir del
software que se esta desarrollando?
Explique los pasos tradicionales de cualquier modelo.
o
o
o
Proporcione cinco ejemplos de desarrollo del software que sean adecuados

para construir prototipos. Nombre dos o tres aplicaicones que fueran ms
dificiles para construir prototipos.
Cmo seleccionar el modelo adecuado?.
Explique como el paradigma ciclo de vida clasico y el de construccin de
prototipos pueden acomodarse en el modelo espiral.

pags. 21-32, 46-47, Ingeniera de software. un enfoque prctico, 4a. edicin, Roger S.
Autoevaluacin
1.
2.
3.
4.
Cuales son las carcteriscticas del paradigma ciclo de vida clsico?

En que consiste el paradigma de construccin de prototipos?
Cuales son los pasos a seguir en el paradigma espiral?
Cules son las desventajas del modelo DRA?
5. Cul es el pardigma de tcnicas de cuarta generacin?
................................................................................................................
2.1 MTRICAS
En la mayora de los desafos tcnicos, las mtricas nos ayudan a entender tanto el proceso
tcnico que se utiliza para desarrollar un producto, como el propio producto. El proceso para
intentar mejorarlo, el producto se mide para intentar aumentar su calidad.
El principio, podra parecer que la necesidad de la medicin e s algo evidente. Despus de todo
es lo que nos permite cuantificar y por consiguiente gestionar de forma ms efectiva. Pero la
realidad puede ser muy deferente. Frecuentemente la medicin con lleva una gran controversia
y discusin.
1. Cules son las mtricas apropiadas para el proceso y para el producto?
2. Cmo se deben utilizar los datos que se recopilan?
3. Es bueno usar medidas para comparar gente, procesos o productos?
Estas preguntas y otras tantas docenas de ellas siempre surgen cuando se intenta medir algo
que no se ha medido en el pasado.
La medicin es muy comn en el mundo de la ingeniera. Medimos potencia de consumo,
pesos, dimensiones fsicas, temperaturas, voltajes, seales de ruidos por mencionar algunos
aspectos. Desgraciadamente la medicin se aleja de lo comn en el mundo de la ingeniera del
software. Encontramos dificultades en ponernos de acuerdo sobre que medir y como va evaluar
las medidas.
Hay varias razones para medir un producto.
1. Para indicar la calidad del producto.
2. Para evaluar la productividad de la gente que desarrolla el producto.
3. Par evaluar los beneficios en trminos de productividad y de calidad, derivados del uso
de nuevos mtodos y herramientas de la ingeniera de software.
4. Para establecer una lnea de base para la estimacin
5. Para ayudar a justificar el uso de nuevas herramientas o de formacin adicional.
Las mediciones del mundo fsico pueden englobarse en dos categoras: medidas directas y
medidas indirectas.
Medidas Directas. En el proceso de ingeniera se encuentran el costo, y el esfuerzo aplicado,
las lneas de cdigo producidas, velocidad de ejecucin, el tamao de memoria y los defectos
observados en un determinado periodo de tiempo.
Medidas Indirectas. Se encuentra la funcionalidad, calidad, complejidad, eficiencia, fiabilidad,
facilidad de mantenimiento, etc.
MTRICAS DEL SOFTWARE.
Son las que estn relacionadas con el desarrollo del software como funcionalidad, complejidad,
eficiencia.
MTRICAS TCNICAS: Se centran en lasa caractersticas de software pro ejemplo: la
complejidad lgica, el grado de modularidad. Mide la estructura del sistema, el cmo esta
hecho.
MTRICAS DE CALIDAD: proporcionan una indicacin de cmo se ajusta el software a los
requisitos implcitos y explcitos del cliente. Es decir cmo voy a medir para que mi sistema se
adapte a los requisitos que me pide el cliente.
MTRICAS DE PRODUCTIVIDAD. Se centran en el rendimiento del proceso de la ingeniera
del software. Es decir que tan productivo va a ser el software que voy a disear.
MTRICAS ORIENTADAS A LA PERSONA. Proporcionan medidas e informacin sobre la
forma que la gente desarrolla el software de computadoras y sobre todo el punto de vista
humano de la efectividad de las herramientas y mtodos. Son las medidas que voy a hacer de
mi personal que va har el sistema.
MTRICAS ORIENTADAS AL TAMAO. Es para saber en que tiempo voy a terminar el
software y cuantas personas voy a necesitar. Son medidas directas al software y el proceso por
el cual se desarrolla, si una organizacin de software mantiene registros sencillos, se puede
crear una tabla de datos orientados al tamao como se muestra en la siguiente figura:
La tabla lista cada proyecto del desarrollo del software de los ltimos aos correspondientes,
datos orientados al tamao de c/u. Refirindonos a la entrada de la tabla del proyecto 999-01
se desarrollaron 12.1 KLDC (miles de lneas de cdigo) con un esfuerzo de 24 personas mes y
un costo de 168 mil dlares. Debe tenerse en cuenta que el esfuerzo y el costo registrados en
la tabla incluyen todas las actividades de la ingeniera de software como son anlisis, diseo,
codificacin y prueba. Otra informacin del proyecto 222-01 indica que se desarrollaron 365
paginas mientras que se encontraron 29 errores tras entregrselo al cliente, dentro del primer
ao de utilizacin tambin sabemos que trabajaron 3 personas en el desarrollo del proyecto.
En los rendimientos del sistema y los rudimentarios datos contenidos en la tabla se puede
desarrollar, para cada proyecto un conjunto de mtricas sencillas de productividad y calidad
orientadas al tamao. Se obtienen las siguientes formulas:
Productividad = KLDC/persona-mes
Calidad = errores/KLDC
Documentacin = pags. Doc/ KLDC

Costo = $/KLDC
persona-mes es el esfuerzo
MTRICAS ORIENTADAS A LA FUNCIN. Son medidas indirectas del software y del proceso
por el cual se desarrolla. En lugar de calcularlas las LDC, las mtricas orientadas a la funcin
se centran en la funcionalidad o utilidad del programa.
Las mtricas orientadas a la funcin fueron el principio propuestas por Albercht quien sugiri un
acercamiento a la medida de la productividad denominado mtodo del punto de funcin. Los
puntos de funcin que obtienen utilizando una funcin emprica basando en medidas
cuantitativas del dominio de informacin del software y valoraciones subjetivos de la
complejidad del software.
Los puntos de funcin se calculan rellenando la tabla como se muestra en la siguiente figura:
Calculo de mtricas de punto de funcin.
Se determinan 5 caractersticas del mbito de la informacin y los clculos aparecen en la

posicin apropiada de la tabla. Los valores del mbito de informacin estn definidos de la
siguiente manera.
1. Nmeros de entrada de usuario: se cuenta cada entrada del usuario que proporcione al
software diferentes datos orientados a la aplicacin. Las entradas deben ser
distinguidas de las peticiones que se contabilizan por separado.
2. Numero de salida del usuario: se encuentra cada salida que proporciona la usuario
informacin orientada ala aplicacin. En este contexto las salidas se refieren a
informes, pantalla, mensajes de error. Los elementos de datos individuales dentro de
un informe se encuentran por separado.
3. Nmeros de peticiones al usuario: una peticin esta definida como una entrada
interactiva que resulta de la generacin de algn tipo de respuesta en forma de salida
interactiva. Se cuenta cada peticin por separado.
4. Numero de archivos: se cuenta cada archivo maestro lgico, o sea una agrupacin
lgica de datos que puede ser una parte en una gran base de datos o un archivo
independiente.
5. Numero de interfaces externas: se cuentan todas las interfaces legibles por la maquina
por ejemplo: archivos de datos, en cinta o discos que son utilizados para transmitir
informacin a otro sistema.
Cuando han sido recogidos los datos anteriores se asocian el valor de complejidad a cada
cuenta. Las organizaciones que utilizan mtodos de puntos de funcin desarrollan criterios para
determinar si una entrada es denominada simple, media o compleja. No obstante la
determinacin de la complejidad es algo subjetivo.
Para calcular los puntos de funcin se utiliza la siguiente relacin.
PF = CUENTA_TOTAL * [0.65 + 0.01 * SUM(fi)]
Donde CUENTA_TOTAL es la suma de todas las entradas de PF obtenidas de la tabla anterior.
Fi donde i puede ser de uno hasta 14 los valores de ajuste de complejidad basados en las
respuestas a las cuestiones sealadas de la siguiente tabla.
Evaluar cada factor en escala 0 a 5.
Los valores constantes de la ecuacin anterior y los factores de peso aplicados en las
encuestas de los mbitos de informacin han sido determinados empricamente.
Una vez calculado los puntos de funcin se usan de forma analgica a las LDC como medida
de la productividad, calidad y otros productos del software.
Productividad = PF / persona-mes
Calidad = Errores / PF
Costo = Dlares / PF
Documentacin = Pags. Doc / PF
La medida de puntos de funcin se diseo originalmente para ser utilizadas en aplicacin de

sistemas de informacin de gestin. Sin embargo, algunas aplicaciones se les denomina
puntos de caractersticas.
La medida del punto de caracterstica da cabida a aplicaciones cuya complejidad algoritmica es
alta. Las aplicaciones de software de tiempo real de control de procesos y de sistemas que
encontrados tienden a tener una complejidad algoritmica alta y por tanto fcilmente tratables
por puntos de caractersticas.
Para calcular los puntos de caractersticas, nuevamente se cuentan y ponderan los valores del
mbito de informacin, como se describi anteriormente. Adems, las mtricas de punto de
caracterstica tienen en cuenta otra caracterstica del software, los algoritmos.
Un algoritmo se define como un problema de complejidad computacional limitada que se
incluye dentro de un determinado programa de computadora. La inversin de una matriz, la
decodificacin de una cadena de bits o el manejo de una interrupcin son todo ellos ejemplos
de algoritmos.
Para calcular los puntos de caracterstica, se utiliza la siguiente tabla.
Puntos de caracterstica
Se usa nico valor de peso para cada uno de los parmetros de medida y se calcula el valor
del punto caracterstica global mediante la ecuacin.
PF = CUENTA_TOTAL * [0.65 + 0.01 * SUM(fi)]
Debe tenerse en cuenta que los puntos de caracterstica y los puntos de funcin representan lo
mismo. "funcionalidad o utilidad" en forma de software.
Mtricas orientadas al tamao
Proyecto
Esfuerzo
KLDC
Pag. doc
Errores
Gente
Farmacia
30
168,500
12,100 378
29
Hospital
60
578,300
39,443 921
540
20
Calcular:
a) Productividad = KLDC/esfuerzo
Hopital = ?
farmacia = ?
b) Calidad = Errores/KLDC
Hospital = ?
Farmacia = ?
c) Costo = $/KLDC
Hospital = ?
Farmacia = ?
d) Documentacin = Pags. doc/KLDC
Hospital=?
Farmacia=?
Mtricas orientadas a la funcin
Se tiene un sistema el cual cuenta con 3 entradas de catalogo productos, proveedores

y clientes. Una pantalla de la elaboracin de facturas, 4 tipos de reportes
proporcionados tanto en pantalla como en papel. Estas representaciones son: factura,
lista de inventario, estado de cuenta de los clientes y estado de cuenta con los
proveedores. Adems la entrada de factura tiene alrededor de 30 peticiones, el sistema
genra alrededor de 30 archivos adems de estar conectado a un lector ptico y una

impresora. Calcula los puntos de funcin.
Parmetro de medida
Factor de peso
medio
Cuenta
Numero de entradas al
usuario
16
Numero de salidas al
usuario
40
Numero de peticiones al
30
usuario
120
Numero de archivos
30
10
300
Numero de interfaces
externas
14
490
Cuenta total
Contestacin de las preguntas basada en la complejidad media
1=0; 2=5; 3=3; 4=5; 5=5;
6=5; 7=1; 8=5; 9=2; 10=2;
11=4; 12=0; 13=0; 14=4
Fi =?
PF = ?
Productividad = ?
Calidad = ?
Costo = ?
Documentacin = ?
o
o
o
Sugiera tres mtricas de calidad y de productividad directas y 3 indirectas para

la documentacin del software.
Describa dos mtricas utilizadas para medir la productividad de los
programadores.
Qu es una metrica indirecta y porque son comunes tales cambios en un
trabajo de metricas de software?

Pgs. 51-61, Ingeniera de software. un enfoque prctico, 4 edicin, Roger S. Pressman, Ed.
Mc Graw Hill, 1997.
Autoevaluacin
1. Qu son las mtricas?
2.
3.
4.
5.
Cules son las mtricas directas?

Cules son las mtricas indirectas?
Cules son las mtricas del software?
Cules son las mtricas orientadas a la funcin?
2.2 ESTIMACIN
Es una pequea planeacin sobre que es lo que va a ser mi proyecto. Una de las actividades
cruciales del proceso de gestin del proyecto del software es la planificacin. Cuando se
planifica un proyecto de software se tiene que obtener estimaciones de esfuerzo humano
requerido, de la duracin cronolgica del esfuerzo humano requerido, de la duracin
cronolgica del proyecto y del costo. Pero en muchos de los casos las estimaciones se hacen
valindose de la experiencia pasada como nica gua. Si un proyecto es bastante similar en
tamao y funciona un proyecto es bastante similar en tamao y funciona un proyecto pasado es
probable que el nuevo proyecto requiera aproximadamente la misma cantidad de esfuerzo, que
dure aproximadamente lo mismo que el trabajo anterior. Pero que pasa si el proyecto es
totalmente distinto entonces puede que la experiencia obtenida no sea lo suficiente.
Se han desarrollado varias tcnicas de estimacin para el desarrollo de software, aunque cada
una tiene sus puntos fuertes y sus puntos dbiles, todas tienen en comn los siguientes
atributos.
1. Se han de establecer de antemano el mbito del proyecto.
2. Como bases para la realizacin de estimaciones se usan mtricas del software de
proyectos pasados.
3. El proyecto se desgloba en partes ms pequeas que se estiman individualmente.

Pgs. 45, Ingeniera de software. un enfoque prctico, 3a. edicin, Roger S.
Autoevaluacin
1. Qu es la estimacin?
2. Porqu es tan importante?
3. Mensiona las tcnicas de estimacin para el desarrollo del software?
2.3 PLANEACIN DEL PROYECTO
La planeacin efectiva de un proyecto de software depende de la planeacin detallada de su

avance, anticipado problemas que puedan surgir y preparando con anticipacin soluciones
tentativas a ellos. Se supondr que el administrador del proyecto es responsable de la
planeacin desde la definicin de requisitos hasta la entrega del sistema terminado. No se
analizara la planeacin que implica a la estimacin de la necesidad de un sistema de software y

la habilidad de producir tal sistema, la asignacin de prioridad al proceso de su produccin.
Los puntos analizados posteriormente generalmente son requeridos por grandes sistemas de
programacin, sine embargo estos puntos son validos tambin para sistemas pequeos.
Panorama. Hace una descripcin general del proyecto detalle de la organizacin del plan y
resume el resto del documento.
Plan de fases. Se analiza el ciclo de desarrollo del proyecto como es: anlisis de requisitos,
fase de diseo de alto nivel, fase de diseo de bajo nivel, etc. Asociada con cada fase debe de
haber una fecha que especifique cuando se debe terminar estas fases y una indicacin de
como se pueden solapar las distintas fases del proyecto.
Plan de organizacin. Se definen las responsabilidades especificas de los grupos que
intervienen en el proyecto.
Plan de pruebas. Se hace un esbozo general de las pruebas y de las herramientas,
procedimientos y responsabilidades para realizar las pruebas del sistema.
Plan de control de modificaciones. Se establece un mecanismo para aplicar las
modificaciones que se requieran a medida que se desarrolle el sistema.
Plan de documentacin. Su funcin es definir y controlar la documentacin asociada con el
proyecto.
Plan de capacitacin. Se describe la preparacin de los programadores que participan en el
proyecto y las instrucciones a los usuarios para la utilizacin del sistema que se les entregue.
Plan de revisin e informes. Se analiza como se informa del estado del proyecto y se definen
las revisiones formales asociadas con el avance de proyecto.
Plan de instalacin y operacin. Se describe el procedimiento para instalar el sistema en la
localidad del usuario.
Plan de recursos y entregas. Se resume los detalles crticos del proyecto como fechas
programadas, marcas de logros y todos los artculos que deben entrar bajo contrato.
Indice. Se muestra en donde encontrar las cosas dentro del plan.
Plan de mantenimiento. Se establece un bosquejo de los posibles tipos de mantenimiento que
se tienen que dar para futuras versiones del sistema.
ERRORES CLASICOS EN UN PROYECTO INFORMATICO.

1.
2.
3.
4.
5.
6.
7.
Mal anlisis en los requerimientos.

Una mala planeacin.
No tener una negociacin (documento, contrato) con el cliente.
No hacer un anlisis costo beneficio.
Desconocer el ambiente de trabajo de los usuarios.
Desconocer los usuarios que trabajan con el sistema.
Mala eleccin de recursos (hardware, software, humanos).
o
o
o
Explique las tcnicas de estimacin para el desarrollo del software.

Explique porque se dice que en muchos de los casos las estimaciones se
hacen valiendose de la experiencia pasada.
Mensione y explique los errores clsicos en un proyecto informtico
o
o
Explique porque la estimacin debe ajustarse para tomar en cuenta la

proyecto, al personal, al producto y a los factores organizaciones.
Explique brevemente en que consiste la planeacin del proyecto.

Pg. 70, Ingeniera de software. un enfoque prctico, 4a. edicin, Roger S.
Autoevaluacin
1. Porqu es importante las planeacin del proyecto?

2. En que consiste el plan de fases?
3. Mensiona los puntos requeridos por grandes sistemas de
programacin.
3.1 LA INFORMACIN COMO UN RECURSO DE LAS ORGANIZACIONES.
A primeros de los aos 60, simplemente se automatizaron funciones de negocio que

previamente se hacan manualmente. A medida que paso el tiempo, los programas individuales
de computadora se combinaron para componer aplicaciones de negocio. Las aplicaciones se
agruparon en sistemas de informacin principales que prestaban sus servicios a reas de
negocio especificas.
La informacin se ha colocado en un lugar adecuado como recurso principal. Los tomadores de
decisiones estn comenzando a comprender que la informacin no es solo un subproducto de
la conduccin, si no que a la vez alimenta a los negocios y puede ser el factor critico par la
determinacin del xito o fracaso de estos.
Para maximizar la utilidad de informacin, un negocio la debe manejar correctamente tal como
maneja los dems recursos. Los administradores necesitan comprender que hay costos
asociados con la produccin, distribucin, seguridad, almacenamiento y recuperacin de toda
informacin. Aunque la informacin se encuentra a nuestro alrededor esta no es gratis y su uso
es estratgico para posicionar la competitividad de un negocio.
El manejo de la informacin generada por computadora difiere en forma significativa del manejo
de datos producidos manualmente. Por lo general, hay mayor cantidad de informacin
generada por computadora a administrar.
INGENIERA DE LA INFORMACION.
El objetivo global de la ingeniera de la informacin es aplicar tecnologa de informacin de la
mejor manera que satisfaga las necesidades generales del negocio. Para conseguirlo la
ingeniera de la informacin debe empezar por analizar los objetivos y metas del negocio,
despus debe definir las necesidades de la informacin de cada rea de negocio y del negocio
en su totalidad. Solo despus de hacer esto la ingeniera de la informacin hace la transicin al
dominio ms tcnico de la ingeniera de software; el proceso, donde los sistemas de
informacin, aplicaciones y programas son analizados, diseados y construidos.
El primer paso de la ingeniera de informacin es la planificacin de la estrategia de la
informacin (PEI). Los objetivos generales del PEI son:
Definir los objetivos y metas del negocio que sean estratgico.

Aislar los factores de xito critico.
Analizar el impacto de la tecnologa y automatizacin en las metas y objetivos.
Analizar la informacin existente para determinar su papel en la consecucin de las
metas y objetivos.
Los trminos de objetivos y metas toman un significado especifico en la PEI. Un objetivo es una
declaracin general de direccin. Las metas define un curso de accin cuantitativo. Los
factores crticos de xito (FCE) pueden estar unidos a un objetivo o a una meta individual. Si se
quiere conseguir un objetivo o una meta debe estar presente un FCE.
El anlisis del impacto tecnolgico examina los objetivos y las metas y proporciona una
indicacin de aquellas tecnologas que tendrn un impacto directo o indirecto en el xito de su
consecucin. El ingeniero de la informacin pondera las siguientes cuestiones:
Cmo es de critica la tecnologa para el logra de un objetivo de negocio?

Esta disponible la tecnologa actualmente?
Cmo modificar la tecnologa el modo de hacer negocios?
Cules son los costes directos e indirectos?
Cmo debera el negocio adaptar o extender o objetivos y metas para adecuarse a la
tecnologa?
Despus de la PEI (planificacin de la estrategia de informacin) se hace el anlisis del rea de

negocio (AAN). Durante el AAN, nuestro punto de mira se desplaza de la visin global a la
visin de dominio. El ingeniero de la informacin deber describir como se usan y transforman
los objetos de datos o conjunto de atributos (descritos durante la PEI y refinados durante el
AAN) dentro de cada rea de negocio y como las funciones de negocio y los procesos dentro
de cada rea de negocio transforman estos objetos de datos.
Los objetos de datos definidos durante la PEI se refinan para el uso dentro de cada rea de
negocio. Por ejemplo, el objeto de datos cliente es empleado por el departamento de ventas.
Despus de evaluar las necesidades del departamento de ventas, la definicin original de
cliente se refina aun ms para satisfacer las necesidades de ventas.
Objeto: Cliente
Atributos:
Nombre
Nombre de la compaa objeto: Compaa
Clasificacin del empleo y autorizacin de compra
Direccin de negocio e informacin de contacto
Inters de producto(s)
Compra(s) anterior(s)
Fecha de ultimo contacto --> registro de contactos
Estado del contacto -- > estado del ultimo contacto
--> Prxima fecha de contacto
--> Naturaleza recomendada de contacto
El atributo nombre de la compaa ha sido modificado para apuntar a otro objeto denominado
Compaa. Este objeto no slo contiene le nombre de la compaa sino tambin otros atributos
que completan la informacin necesaria de ese objeto de datos.
Actividades obligatorias:
o
o
o
Explique porque es importante la informacin.

Mencione y explique los objetivos generales de la planeacin estratgica de la
informacin.
Ha decidido empezar un negocio con envo de ordenes por correo electrnico.
Como quiere llevar su negocio con eficacia, decide hacer algo de ingeniera de
informacin. Empiece por el PEI. Construya un sencillo modelo de empresa
que incluya un organigrama, esquemas de funciones y de los procesos de
negocio y un modelo de datos en el mbito del negocio.
Asumamos que una de las reas del negocio que ha identificado para el
negocio de software por correo (actividad anterior) es el proceso de pedidos
por telfono. Haga un AAN para desarrollar un modelo de datos y diagrama de
flujo del proceso detallado para esta rea del negocio.
Actividades sugeridas:
o
o
o
Explique que realiza la ingeniera de la informacin.

Explique que se hace durante el anlisis del rea del negocio.
La planeacin de la estrategia de la informacin empieza por la definicin de
objetivos y metas. Ponga ejemplos de cada uno de los dominios del negocio.

Pags. 163-166, Ingeniera de software. Un enfoque practico, Roger S. Pressman, 4 edicin,
ed. Mc Graw Hill, 1997.
Autoevaluacin
1. Cul es el objetivo de la ingeniera de la informacin?
2. Cul es factor critico para la determinacin del xito o fracaso de los

negocios?
3. Qu es un objetivo?
4. Qu es una meta?
3.2 EL PAPEL DEL ANALISTA DE SISTEMAS
El analista de sistemas generalmente valora la manera que funcionan los negocios examinando
la entrada, el procesamiento de datos y la salida de informacin con el propsito de mejorar los
procesos organizacionales.
Muchas mejoras involucran mejor apoyo para las funciones de los negocios por medio del uso
de sistemas de informacin computarizados. Esta definicin enfatiza un enfoque sistemtico y
metdico para analizar, y posiblemente mejorar, lo que esta sucediendo con el contexto
especifico creado por un negocio.
Se requiere que los analistas de sistemas desempeen muchos paquetes en el curso de su
trabajo. Algunos de estos papeles son:
1. Consultores externos para negocios.

2. Experto de soporte dentro de un negocio.
3. Agente de cambio en situaciones tanto internas como externas.
Los analistas poseen un amplio rango de habilidades. La primera y principal es que le analista
soluciona problemas, le gusta el reto de analizar un problema y encontrar una respuesta
funcional. Los analistas de sistemas requieren habilidades de comunicacin que les permitan
relacionarse en forma significativa con muchos tipos de gente diariamente, as como
habilidades de computacin. Para su xito es necesario que se involucre el usuario final.
Los analistas proceden sistemticamente. El marco de referencia para su enfoque sistemtico
es proporcionado por lo que es llamado el ciclo de vida del desarrollo de sistemas (SDLC). Este
puede ser dividido en siete fases secuenciales, aunque en realidad las fases estn
interrelacionadas y frecuentemente se llevan a cabo simultneamente. Las siete fases son:
1.
2.
3.
4.
5.
6.
7.
Identificacin de problemas.
Oportunidades y objetivos
Determinacin de los requerimientos de informacin
Anlisis de las necesidades de sistemas
Diseo del sistema recomendado
Desarrollo y documentacin del software
Prueba y mantenimiento del sistema e implementacin del mismo.
Los paquetes de software basados en microcomputadora automatizado para el anlisis y

diseo de sistemas son llamados herramientas CASE. Las cuatro razones para la adopcin de
herramientas CASE son:
1.
2.
3.
4.
El incremento de la productividad del analista

La mejora de la comunicacin entre analistas y usuarios
La integracin de actividades del ciclo de vida y el anlisis.
La valoracin del impacto de los cambios por mantenimiento.
Los analistas tambin usan enfoque CARE (Reingeniera Asistida por Computadora) para hacer
ingeniera inversa y reingeniera de software para extender la vida del software legado.
Un enfoque nuevo y diferente al anlisis y diseo de sistemas es el anlisis y diseo de
sistemas orientados a objetos (O-O). Estas tcnicas estn basadas en conceptos de
programacin orientada a objetos en los cuales los objetos, que son creados incluyen no
solamente cdigo acerca de los datos sino tambin instrucciones acerca de las operaciones
que se pueden realizar con ellos.
Cuando la situacin organizacional lo demanda, el analista puede apartarse del SDLC para
intentar una metodologa alterna, tal como la elaboracin de prototipos, ETHICS, el enfoque de
campen de proyecto, la metodologa Soft Systems o Multiview.
COMPRENSIN DE LOS ESTILOS, ORGANIZACINES Y SU IMPACTO SOBRE LOS
SISTEMAS DE INFORMACION
Hay tres amplios puntos fundamentales de las organizaciones a considerar cuando se analizan
y disean sistemas de informacin. Estos son el concepto de la organizacin. Esos son el
concepto de la organizacin como sistema, los diversos niveles de administracin y la cultura
organizacional general.
Las organizaciones son sistemas completos compuestos de subsistemas interrelacionados e
interdependientes. Adems, los sistemas y subsistemas estn caracterizados por su ambiente
interno, en un continuo que va desde abiertos a cerrados. Un sistema abierto permite el paso
libre de recursos (personas, informacin y materiales) a travs de su frontera. Los sistemas
cerrados no permiten el libre flujo de entrada o salida.
Los diagramas entidad-relacin ayudan a que le analista de sistemas comprenda las entidades
y relaciones que comprende el sistema organizacional. Los cuatro tipos diferentes de
relaciones en los diagramas E-R son: relacin uno a uno, relacin uno a muchos, relacin
muchos a uno y relacin muchos a muchos.
Los tres niveles de control administrativo son: operacional, medio y estratgico. El horizonte de
tiempo para la toma de decisiones es diferente para cada nivel.
Las culturas y subculturas organizacionales son determinantemente importantes sobre la
manera en que las personas usan la informacin y los sistemas de informacin. Apoyando los
sistemas de informacin y los sistemas de informacin. Apoyando los sistemas de informacin
en el contexto de la organizacin como un sistema ms grande, es posible darse cuenta que
numerosos factores son importantes y deben ser tomados en cuenta cuando se determinen los
requerimientos de informacin y se disea e implementa los sistemas de informacin.
DETERMINACIN DE LA FACTIBILIDAD Y EL MANEJO DE LAS ACTIVIDADES DE
ANLISIS Y DISEO
Los cuatro puntos fundamentales del proyecto que el analista de sistemas debe manejar son:
1.
2.
3.
4.
Iniciacin del proyecto

Determinacin de la factibilidad del proyecto
Calendarizacion del proyecto
Administracin de los miembros del equipo del anlisis de sistema.
Los proyectos pueden ser solicitados por muchas personas diferentes dentro del negocio o por
los mismos analistas de sistema.
La seleccin de un proyecto es una decisin difcil, debido a que sern solicitados ms
proyectos de los que pueden ser hechos. Cinco criterios importantes para la seleccin de
proyectos son:
1.
2.
3.
4.
5.
Que el proyecto solicitado este respaldado por la administracin.

Que tenga el tiempo adecuado para la asignacin de recursos.
Que mueva al negocio hacia la obtencin de sus objetivos.
Que sea practicable.
Que sea lo suficientemente importante para ser considerado en vez de otros
proyectos posibles.
Si un proyecto solicitado satisface estos criterios, entonces puede ser elaborado un estudio de
la factibilidad de sus mritos operacionales, tcnicos y econmicos. Por medio del estudio de
factibilidad los analistas de sistemas recopilan datos que permiten a la administracin decidir si
continan con un estudio de sistema completo.
La planeacin del proyecto incluye la estimacin del tiempo requerido por cada una de las
actividades del analista, su calendarizacin y la agilizacin de ellas, si es necesario para
asegurar que un proyecto sea terminado a tiempo. Una tcnica de que dispone el analista de
sistemas para la calendarizacin de tareas es la grfica de Gantt, que despliega actividades en
forma de barras en una grfica.
La calendarizacin de proyectos basada en computadora, usando microcomputadoras, es
ahora practica comn, debido principalmente al uso de interfaces de usuario grficas.
Adicionalmente. Se pueden usar los administradores de informacin personales (PIM) por los
analistas para planear, crear deposito de nmeros telefnicos y de fax y hasta para ejecutar
otros programas.
Una segunda tcnica, llamada PERT (evaluacin de programas y tcnicas de revisin),
despliega las actividades como flechas en una red. El PERT ayuda a que el analista determine
la ruta critica y el tiempo de holgura, que es la informacin requerida para el control efectivo del
proyecto. Cuando es necesario terminar un proyecto en menor tiempo, el analista puede reducir
la duracin total del proyecto identificacin y agilizando las actividades principales.
Una vez que un proyecto ha sido juzgado factible, el analista de sistemas debe administrar a
los miembros del equipo, sus actividades, tiempo y recursos. La mayor parte de esto se logra
mediante la comunicacin con los miembros del equipo. Los equipos estn constantemente
buscando un balance entre el trabajar sobre las tareas y el mantener las relaciones con el
equipo. Deben ser solucionadas las tensiones que suceden al intentar lograr este balance.
Frecuentemente emergen dos lideres en un equipo, un lder de tarea y un lder socioemocional.
Los miembros deben valorar peridicamente las normas del equipo para asegurarse de que
sean funcionales en vez de disfuncionales para el logro de los objetivos del equipo.
Es importante que le equipo de anlisis de sistemas ponga objetivos de productividad
razonables para las salidas tangibles y las actividades del proceso. Las fallas del proyecto
pueden ser evitadas, por lo general, examinando las motivaciones de los proyectos solicitados,
as como los motivos del equipo para recomendar o evitar un proyecto particular.
o
o
o
Describa cuales son las habilidades del analista de sistemas.

Mencione las siete fases secuenciales.
Explique cada una de los tres puntos fundamentales de las organizaciones a
considerar cuando se analizan y disean sistemas de informacin.
o
o
Cules son las cuatro razones para la adopcin de las herramientas CASE?
Explique en que consiste la tcnica PERT.
Cmo se determina la factibilidad del proyecto?
Recursos para ampliar el tema:

Pags. 5-7, Anlisis y diseo de sistemas, Kendall & Kendall, 3 edicin, ed. Pearson educacin,
1997.
Autoevaluacin
1. Quin es el analista de sistemas?
2. Cules son algunos de los papeles del analista de sistemas?
3. Explique cual es la principal habilidad del analista de sistemas
3.3 ANLISIS DE LOS REQUERIMIENTOS DE INFORMACIN
3.3.1 TCNICAS DE RECOPILACIN DE INFORMACIN
Los analistas utilizan una variable de mtodos a fin de recopilar los datos sobre una situacin
existente, como entrevistas, cuestionario, inspeccin de registros y observacin. Cada uno
tiene ventajas y desventajas. Generalmente, se utilizan dos o tres para complementar el trabajo
de cada una y ayudar a asegurar una investigacin completa. A continuacin se vern cada una
de ellas.
ENTREVISTA
Las entrevistas se utilizan para recabar informacin en forma verbal, a travs de preguntas que
propone el analista. Quienes responde pueden ser gerentes o empleados, los cuales son
usuarios actuales del sistema, existen usuarios potenciales del sistema propuesto o aquellos
que proporcionaran datos o sern afectadas por la aplicacin propuesta. El analista puede
entrevistar al personal en forma individual o en grupos.
Recabar datos mediante la entrevista.
La entrevista es una forma de conversacin, no interrogacin! Al analizar las caractersticas de
los sistemas con personal seleccionado cuidadosamente por sus conocimientos sobre es
sistema los analistas pueden conocerlos datos que no estn disponibles en ninguna otra forma.
En las investigaciones de sistemas, las formas cualitativas y cuantitativas de la informacin son
importantes. La informacin cualitativa esta relacionada con opiniones, polticas y descripciones
cuantitativas tratan con nmeros, frecuencia o cantidades. A menudo las entrevistas dan la
mejor fuente de informacin cualitativa; los otros mtodos tienden a ser mas tiles en la
recabacin de datos cuantitativos.
Mucha gente incapaz de expresarse por escrito puede discutir sus ideas en forma verbal. Como
resultado de esto las entrevistas pueden descubrir rpidamente malos entendidos, falsas
expectativas o incluso resistencia potencial para las aplicaciones en desarrollo; mas aun a
menudo es ms fcil calendarizar una entrevista con los gerentes del alto nivel, que pedirles
que llenen cuestionarios.
Determinacin del tipo de entrevista.

La estructura de las entrevistas varia. Si el objetivo de la entrevista radica en adquirir
informacin general, es conveniente elaborar una serie de preguntas sin estructura, con una
seccin de preguntas y respuestas libres. La atmsfera abierta y de fcil flujo de esta
modalidad proporciona una mayor oportunidad para conocer las actitudes, ideas y creencias de
quien responde. Sin embargo, cuando los analistas necesitan adquirir datos ms especficos
sobre la aplicacin o desean asegurar una alta confiabilidad en las respuestas a las preguntas
que han propuesto a sus entrevistados, las entrevistas estructuradas son mejores.
Las entrevistas estructuradas utilizan preguntas estandarizadas. El formato de respuestas para
las preguntas puede ser abierto o cerrado; las preguntas para respuesta abierta permiten a los
entrevistados dar cualquier respuesta que parezca apropiada. Con las preguntas para
respuestas cerradas se proporciona al usuario un conjunto de respuestas que se pueda
seleccionar. Todas las personas que responden se basan en un mismo conjunto de posibles
respuestas.
La confiabilidad es solo una consideracin en la seleccin del mtodo de entrevista. Los
analistas tambin deben dividir su tiempo entre desarrollar preguntas para entrevistas y
analizar las respuestas. Las entrevistas no estructuradas requieren menos tiempo de
preparacin, porque no se necesita tener por anticipado las palabras precisas de las preguntas.
Sin embargo, analizar las respuestas despus de las entrevistas lleva ms tiempo que con las
entrevistas estructuradas. De cualquier manera, el mayor costo radica en la preparacin,
administracin y anlisis de las entrevistas estructuradas para preguntas cerradas.
Dado que un numero de personas se seleccionara para la entrevista, los analistas deben tener
cuidado de incluir aquellas personas que tienen informacin que no se podr conseguir de otra
forma. Durante las primeras etapas de un estudio de sistemas, cuando los analistas determinan
La factibilidad del proyecto, con frecuencia las entrevistas solo se aplican a la gerencia o
personal de supervisin. Sin embargo, durante la investigacin detallada en donde el objetivo
es descubrir hechos especficos, opiniones y conocer como se manejan las operaciones
desempeadas actualmente, las entrevistas se aplican en todos los niveles gerenciales y de
empleados y dependen de quien pueda proporcionar la mayor parte de la informacin til para
el estudio. As, los analistas que estudian ala administracin de inventarios pueden entrevistar a
los trabajadores del embarque y de recepcin, al personal del almacn y a los supervisores de
los diferentes turnos, es decir, aquellas personas que realmente trabajan en el almacn;
tambin entrevistaran a los agentes ms importantes.
Realizacin de la entrevista.
La habilidad del entrevistador es vital para el xito en la bsqueda de hechos por medio de la
entrevista. Las buenas entrevistas dependen del conocimiento del analista tanto de la
preparacin del objetivo de una entrevista especifica como de las preguntas por realizar a una
persona determinada.
El tacto, la imparcialidad e incluso la vestimenta apropiada ayudan a asegurar una entrevista
exitosa. La falta de estos factores puede reducir cualquier oportunidad de xito. Por ejemplo, un
analista que trabaja en la aplicacin enfocada a la reduccin de errores probablemente no
tendra xito si llegar a una oficina de gerencia de nivel medio con la presentacin equivocada,
por ejemplo, si dijera, "hola, fui enviado para encontrar una forma de mojar el rendimiento y de
reducir los errores que presentan aqu. O la introduccin: "Estamos aqu para resolver su
problema", es igualmente mala. Es imaginable la rapidez con la que va a responder ser irrita y
se molesta con un enfoque de este tipo.
A travs de la entrevista, los analistas deben preguntarse as mismos las siguientes
interrogantes:
1.
2.
3.
4.
Qu es lo que me esta diciendo la persona?

Por qu me lo esta diciendo a m?
Qu se esta olvidando?
Qu espera esta persona que haga yo?
Si se considera cada elemento de la informacin contra estas preguntas, los analistas tendrn
mas conocimientos no solamente de la informacin adquirida sino tambin de su importancia.
CUESTIONARIO.
Los cuestionarios proporcionan una alternativa muy til para las entrevistas; sin embargo,
existen ciertas caractersticas que pueden ser apropiadas en algunas situaciones e
inapropiadas en otras.
Recabacin de datos mediante cuestionarios
Para los analistas los cuestionarios pueden ser la nica forma posible de relacionarse con un
gran numero de personas para conocer varios aspectos del sistema. Cuando se llevan a cabo
largos estudios en varios departamentos, se puede distribuir los cuestionarios a todas las
personas apropiadas para recabar hechos con relacin al sistema. Por supuesto, no es posible
observar las expresiones o relaciones de quienes responden a los cuestionarios.
Tambin las preguntas estandarizadas pueden proporcionar datos ms confiables. Por otra
parte, las caractersticas anteriores tambin son desventajas de los cuestionarios. Aunque su
aplicacin puede realizarse con un mayor numero de individuos, es muy rara una respuesta
total. Puede necesitarse algn seguimiento de los cuestionarios para motivar al personal que
responda; todas las respuestas se encontraran en una proporcin entre el 25 o 35%, que es lo
ms comn.
Seleccin de formas para cuestionarios.
El desarrollo y distribucin de los cuestionarios es caro; por lo tanto, el tiempo invertido en esto
debe utilizarse en una forma inteligente. Tambin es importante el formato y contenido de las
preguntas en la recopilacin de hechos significativos.
Existen dos formas de cuestionarios para recabar datos; cuestionario abierto y cerrados, y se
aplican dependiendo de si los analistas conocen de antemano todas las posibles respuestas de
las preguntas y pueden incluirlos. Con frecuencia se utilizan ambas formas en los estudios de
sistemas.
Cuestionarios abiertos.
Al igual, que las entrevistas, los cuestionarios pueden ser abiertos y se aplican cuando se
quieren conocer los sentimientos, opiniones y experiencias generales; tambin son tiles al
explorar el problema bsico, por ejemplo, un analista que utiliza cuestionarios para estudiar los
mtodos de verificacin de crdito, en un medio ambiente de ventas al a menudeo, podra
recabar mas informacin provechosa de una pregunta abierta de este tipo: Cmo podra
simplificarse y mejorarse el proceso de verificacin de crdito para los clientes?
Cuestionarios cerrados.
El cuestionario cerrado limita las respuestas posibles del interrogado. Por medio de un
cuidadoso estilo en la pregunta, el analista puede controlar el marco de referencia. Este
formato es el mejor mtodo para obtener informacin sobre los hechos. Tambin fuerza a los
individuos para que tomen una posicin y forma de opinin sobre los aspectos importantes.
Etapas en el desarrollo de un cuestionario
Los cuestionarios bien hechos no se desarrollan rpidamente, llevan tiempo y mucho trabajo.
La primera consideracin se encuentra en determinar el objetivo del cuestionario. Qu datos
quiere conocer el analista a travs de su uso? El analista define como utilizar los cuestionarios
a fin de obtener los hechos al considerar la estructura mas til para el estudio y la ms sencilla
de entender por parte de los interrogados.
Lleva tiempo desarrollar preguntas bien elaboradas y deben siempre probarse y modificarse, si
es necesario, antes de que imprima una forma final y se distribuya.
Seleccin de quienes recibirn el cuestionario
Aquellas personas que reciban el cuestionario deben seleccionarse de a cuerdo con la
informacin que puedan proporcionar. Escribir o imprimir un cuestionario no significa que se
pueda distribuir ampliamente sin un anlisis previo. Lo pueden contestar personas no
calificadas y si el cuestionario no es annimo, y no ser posible retirar sus respuestas de la
muestra. La realizacin de esto tambin es desgastante y cara.
OBSERVACION
Ver es creer! Observar las operaciones le proporciona la analista hechos que no podra
obtener de otra forma.
Recopilacin de datos mediante la observacin
Leer en relacin con una actividad del negocio le proporciona al analista una dimensin de las
actividades del sistema. Entrevistar personal, ya sea directamente o a travs de cuestionarios,
tambin le ayuda y le dice algo ms. Ninguno de los dos mtodos da una informacin completa;
por ejemplo, leer en relacin con un viaje en jet no reproduce la experiencia de volar a unos 30
mil pies de altura.
La observacin proporciona informacin de primera mano en relacin con la forma en que se
llevan a cabo las actividades. Las preguntas sobre el uso de documentos, la manera en la que
se realizan las tareas y si ocurren los pasos especficos como se pre-estableciern, pueden
contestarse rpidamente si se observan las operaciones.
Cuando observar
La observacin es muy til cuando el analista necesita ver de primera mano como se manejan
los documentos, como se llevan a cabo los procesos y si ocurren los pasos especificados.
Saber que buscar y como guiar su significado, tambin requiere de experiencia. Los
observadores con experiencia captan quien utiliza los documentos y si encuentran dificultades;
tambin estn alertas para detectar documentos o registros que no se utilizan.
MUESTREO
Con frecuencia, en muchas empresas la informacin ya se encuentra disponible para que el
analista conozca las actividades u operaciones con las cuales no esta familiarizado. Muchos
tipos de registros e informes son accesibles si el analista sabe donde buscar. En la revisin de
registros, los analistas examinan datos y descripciones que ya estn escritos o registrados y en
relacin con el sistema y los departamentos de usuarios. Esta forma de encontrar datos puede
servir como presentacin del analista, si se realiza al iniciar el estudio, o como un termino de
comparacin de lo que sucede en el departamento con lo que los registros presentan como lo
que debera suceder.
Recopilacin de datos por medio de la inspeccin de registros.
El termino "registro" se refiere a los manuales escritos sobre polticas, regulaciones y
procedimientos de operaciones estndar que la mayora de las empresas mantienen como gua
para gerentes y empleados. Los manuales que documentan o describen las operaciones para
los procesos de datos existente, o sistemas de informacin que entran dentro del rea de
investigacin, tambin proporcionan una visin sobre la forma en la que el negocio debera
conducirse. Normalmente muestran los requerimientos y restricciones del sistema (como
cantidad de transacciones o capacidad de almacenamiento de datos) y caractersticas de
diseo (controles y verificacin del procesamiento).
Los registro permiten que los analistas se familiaricen con algunas operaciones, oficinas de la
compaa y relaciones formales a las que debe darse apoyo. No obstante, no muestran como
producen de hecho las actividades, donde se ubica el poder verdadero para las decisiones, o
como se realizan las tareas en la actualidad. Los otros mtodos con objeto de encontrar datos
estudiados en esta seccin son ms eficaces para proporcionar al analista este tipo de
informacin.
Seleccin de los registros para revisin
En la mayor parte de las empresas los manuales de estndares sobre procedimientos de
operacin usualmente son obsoletos; a menudo no se mantienen al corriente lo suficiente para
sealar los procedimientos existentes. Los diagramas de organizacin muestran como las
diferentes unidades deberan relacionarse con otras; pero muchas no reflejan las operaciones
actuales.
o
o
o
o
Explique brevemente la realizacin de la entrevista

Liste cuatro situaciones que hagan adecuado el uso de cuestionarios.
Cmo debe ser la seleccin de quien recibir el cuestionario?
Defina lo que significa muestreo
o
o
o
Liste tres razones sobre el porqu la observacin es til para el analista de

sistemas en la organizacin
Explique brevemente la fase de muestreo.
Qu tipos de informacin deben ser buscados en las entrevistas?
Pags. 79-82, 109-123, 147-163, 175-181, Anlisis y diseo de sistemas,

Kendall & Kendall, 3 edicin, ed. Pearson educacin, 1997.
Autoevaluacin
1.
2.
3.
4.
Qu es la entrevista?
Para que sirven los comentarios?
En que momento es til observar?
Qu es el muestreo o para que sirve?
PROTOTIPOS
El anlisis hay que hacerlo independientemente del paradigma que se aplique. En algunos
casos es posible aplicar los principios operativos del anlisis y obtener un modelo del software
del que se pueda desarrollar un diseo. En otras ocasiones se realizan recopilaciones de
requisitos u otras tcnicas se aplican los principios del anlisis y se construye un modelo del
software a fabricar denominado prototipo para que lo valore el cliente y el desarrollador.
Finalmente hay circunstancias que requieren la construccin de un prototipo al comienzo del
anlisis ya que el modelo es el nico medio a travs del cual se pueden obtener eficazmente
los requisitos. El modelo evoluciona despus hacia la produccin del software.
SELECCIONE EL ENFOQUE DE CREACIN DE PROTOTIPOS

El paradigma de creacin de prototipos puede ser cerrado o abierto. Al enfoque cerrado se
denomina a menudo prototipo desechable. Este prototipo sirve como una basta demostracin
de los requisitos. Despus se desecha y se hace una ingeniera de software con un paradigma
diferente. Un enfoque abierto denominado prototipo evolutivo, emplea el prototipo como
primera evaluacin del sistema terminado.
Antes de poder elegir un enfoque abierto cerrado, es necesario determinar si se puede crear un
prototipo como primera evaluacin del sistema terminado.
Se pueden definir varios factores candidatos para la creacin de prototipos:
rea de aplicacin
complejidad
caractersticas del cliente
caractersticas del proyecto
En general cualquier aplicacin que cree pantallas visuales dinmicas, interactue intensamente
con el ser humano o demande algoritmos o procesamiento de combinaciones que deba de
manera progresiva, es un buen candidato para la creacin de prototipos. Pero sin embargo
estas reas de aplicacin deben ponderarse con la complejidad de la aplicacin. Si una
aplicacin candidata va a requerir el desarrollo de docenas de miles de lneas de cdigo antes
de poder realizar cualquier funcin demostrable, es probable que sea demasiado compleja para
la creacin de un prototipo.
Como el cliente debe interactuar con el prototipo en fases posteriores, es esencial que:
1. Se destinen recursos del cliente a la evaluacin y refinamiento del prototipo.

2. El cliente pueda tomar decisiones inmediatas sobre los requisitos.
MTODOS Y HERRAMIENTAS PARA EL DESARROLLO DE PROTOTIPOS.

Tcnicas de cuarta generacin. Estas comprenden una amplia gama de lenguajes de consulta
y de otros lenguajes no procedimentales de muy alto nivel. Como las tcnicas de cuarta
generacin permiten al ingeniero del software generar cdigo ejecutable rpidamente son
ideales para la creacin rpida de prototipos.
Componente de software reutilizables. El ensamblar mas que el construir, es un prototipo
mediante software existente. Un componente de software puede ser una estructura de datos o
un componente arquitectnico. En pocas palabras un software existente que cumpla con los
requisitos del cliente.
Especificaciones formales y entornos para prototipos. Durante las pasadas dos dcadas, se
han desarrollado varios lenguajes formales de especificacin y herramientas como sustitutos de
las tcnicas de especificacin con lenguaje natural.
Hoy en da los desarrolladores de estos lenguajes formales estn desarrollando entornos
interactivos que:
1. Permitan al analista crear interactivamente una especificacin basada en lenguaje de
un sistema o software.
2. Invoque herramientas automticas que traducen la especificacin basada en el
lenguaje de cdigo ejecutable.
3. Permitan al cliente usar el cdigo ejecutable del producto para refinar los requisitos
formales.
Mtodos y herramientas para el desarrollo de los prototipos, para la seleccin de un enfoque
apropiado de creacin de prototipo.
o
o
o
Cules tipos de informacin est buscando el analista por medio de la

elaboracin de prototipos?
Liste las ventajas y desventajas del uso de prototipos
D un ejemplo de un prototipo que sea un "primer modelo a escala completa"
o
o
o
Liste cuatro lineamientos que debe observar el analista en el desarrollo de

prototipos
Cules son los criterios para decidir si un sistema debe tener un prototipo
Defina lo que significa un prototipo que es un modelo con algunas pero no
todas, las cartactersticas esenciales.

o
o
Pgs. 192-194, Ingeniera de software. un enfoque prctico,4a. edicin, Roger

S. Pressman, ed. Mc Graw Hill, 1997
Pgs. 197-208, Anlisis y Diseo de sistemas, 3a. edicin, Kendall & Kendall,
ed. Prentice Hall, 1997
Autoevaluacin:
1. Cules son los metodos y herramientas para el desarrollo de prototipos?

2. Cul es el prototipo desechable?
3. Qu es un prototipo?
4. Cules son los factores candidatos para la creacin de prototipos?
3.4 ANLISIS ORIENTADO A OBJETOS
El anlisis orientado a objetos esta basado en un modelo de cinco capas:
1. Capa clase/objeto.
2. Capa de estructura.
3. Capa de atributos.
4. Capa de servicios
5. Capa de tema.
La figura ilustra como se entrelazan estas cinco capas.
1. Capa Clase/Objeto. Esta capa indica las clase y objetos.

2. Capa de Estructura. Esta capa captura diversas estructuras de clase y objetos, tales
como las relaciones uno a muchos y la herencia.
3. Capa de Atributos. Esta capa detalla los atributos de las clases.

4. Capa de Servicios. Esta capa indica los mensajes y comportamientos del objeto
5.
(servicios y mtodos).
Capa de Tema. Esta capa divide el diseo en unidades de implementacin o
asignaciones de equipos.
Anlisis y clases de objetos.

Objeto: es una abstraccin de algo en un dominio de un problema que refleja las capacidades
de un sistema para llevar informacin acerca de ello, interactuar con ello a ambas cosas.
Es una representacin en computadora de alguna cosa o evento del mundo real. Pueden tener
tanto atributos y comportamientos.
Clase. Es una categora de objetos similares. Los objetos se agrupan en clases. Una clase
define el conjunto de atributos y comportamientos compartidos que se encuentran a cada
objeto de la clase.
Clase y objeto. Un trmino que se refiere tanto a clase como a los objetos que ocurren en la
clase.
Hay cinco tipos generales de objetos que pueden descubrirse durante el anlisis. Los objetos a
veces representan cosas tangibles como vehculos, dispositivos y libros. Algunas veces los
objetos representan papeles actuados por personas u organizaciones. Los objetos tambin
pueden ser derivados de incidentes o eventos. Otros objetos pueden indicar interacciones tales
como una venta o un matrimonio. Las interacciones tienen una cualidad de transaccin o
contrato. Los objetos tambin pueden detallar especificaciones. Las especificaciones tienen
estndares o una cualidad de definicin y, por lo general, implican que otros objetos
representaran ocurrencias de cosas tangibles.
Las clases son representadas por cuadros rectangulares redondeados (bubtngulos) divididos
en tres partes. El nombre de la clase se muestra en la divisin superior del cuadro. Las otras
dos divisiones se usan para las capas de atributo y servicio. Cuando una clase aparece sin
objetos, puede ser solamente una clase base, debido a que la nica razn para tal clase "sin
objetos" es que sea un medio para agrupar atributos y servicios que sern heredados por
varias otras clases.
Los objetos que tienen ocurrencia de una clase son representados por un cuadro sombreados
rodeado por la clase. Debido a que los objetos tiene ocurrencias de una clase.
Criterios que podemos usar para que nos ayuden a determinar si se justifica una nueva clase
de objetos:
1. Hay una necesidad de recordar el objeto. Esto es, el objeto puede ser descrito en un
sentido definido y sus atributos son relevantes para el problema.
2. Hay una necesidad de determinados comportamientos del objeto. Esto es, aunque
3.
4.
5.
6.
un objeto no tenga atributos, hay servicios que debe proporcionar o estados de objeto
que deben ser llamados.
Usualmente un objeto tendr varios atributos. Los objetos que tienen solamente
uno o dos atributos sugieren diseos sobreanalizados.
Usualmente una clase tendr mas de una instancia de objeto, a menos de que sea
una clase base.
Usualmente los atributos tendrn siempre un valor significativo para cada objeto
de la clase. Los objetos que producen valor NULO para un atributo, o para los que no
es aplicable un atributo, por lo general implican una estructura generalizacinespecificacin.
Usualmente los servicios siempre se comportarn en la misma forma para todos
los objetos de la clase. Los servicios que varan dramticamente para algunos
7.
8.
objetos de una clase o que regresan sin realizar accin para algunos objetos tambin
sugieren una estructura generalizacin-especificacin.
Los objetos deben implementar requerimientos que son derivados del problema
y no de la tecnologa de solucin. La parte de anlisis del proyecto orientado a
objetos no debe llegar a ser dependiente de una tecnologa de implementacin
particular, tal como un sistema de computadora especifico o un lenguaje de
programacin especifico. Los objetos que atienden tales detalles tcnicos no deben
aparecer sino hasta muy tarde en la etapa de diseo. Los objetos dependientes de la
tecnologa sugieren que el proceso de anlisis tiene fallas.
Los objetos no deben duplicar atributos o servicios que pueden ser derivados de
otros objetos del sistema. Por ejemplo, un objeto que guarda la edad de un
empleado es superfluo cuando existe un objeto de empleado separado que conserva el
atributo fecha de nacimiento. El objeto edad puede ser eliminado por un servicio edad
que es componente del objeto empleado.
o
o
o
Explique las cinco capas en las que esta basado el diseo orientado a objetos
Cules son los cinco tipos generales de objetos?
Cmo puede decidirse si una clase ha tenido ocurrencia de objetos?
o
o
Explique los ocho criterios usados para determinar si se justifica una nueva
clase
Describa la diferencia entre una clase y un objeto

o
Pgs. 864-866, Anlisis y diseo de sistemas, 3a. edicin, Kendall & Kendall,
ed. Prentice Hall, 1997
Autoevaluacin:
1. Cules son las cinco capas en las que est basado el diseo orientado a
objetos?
2. Nombra tres criterios para usados para determinar si se justifica una nueva
3.
4.
clase
Qu es una clase?
Qu es un objeto?
3.4.1 MODELO ESTATICO (ESTRUCTURADO)

MODELO DE OBJETOS
Conceptos y Principios Orientados a Objetos.

El enfoque orientado a objetos no es nuevo. Por primera vez fue propuesto a finales de los
aos 60, pero como muchas cosas en la vida, ha tenido que esperar casi 20 aos para ser
retomado con la fuerza que tiene actualmente. A diferencia del enfoque estructurado, en el
orientado a objetos debemos centrarnos en caracterizar los objetos reales del mundo tal y
como ellos son, concibindolos de manera natural, con sus caractersticas o propiedades y sus
operaciones o mtodos; y no en la divisin de estos en estructuras abstractas que particionan
todas las caractersticas de esos objetos, adems de separar de su caracterizacin las
operaciones que incidan sobre los mismos.
Pero hay dos cuestiones bsicas que hacen que el enfoque orientado a objetos sea ms til en
los momentos actuales:
La reutilizacin de componentes de software ya creados con anterioridad (objetos que

pueden ser usados en diferentes aplicaciones y que se almacenan en bibliotecas de
clase).
La facilidad de mantenimiento por ser el Software orientado a objetos de una estructura
descompuesta.
El paradigma orientado a objetos durante mucho tiempo se ha identificado con el uso de

lenguajes orientado a objetos (Ada95, C++, Delphi, Eiffel, Smalltalk) pero desde hace unos
aos se trabaja para establecer principios y fundamentos ms slidos en el desarrollo de SW
orientado a objetos, pasando por el establecimiento de anlisis orientado a objetos, diseo
orientado a objetos, SGBDOO, y CASE orientado a objetos.
La Ingeniera de software tambin est evolucionando para adaptarse al paradigma orientado a
objetos. Los principios bsicos de la ingeniera des software mencionados antes deben ser
adaptados a este nuevo enfoque, pero hay cosas que nos sirven. Por ejemplo si hablamos de
un paradigma o ciclo de vida del software, deberamos pensar en un enfoque evolutivo, pues el
software orientado a objetos se caracteriza por su evolucin.
Conceptos de la orientacin a objetos.
Es evidente que el concepto bsico de la orientacin a objetos es el objeto, pero para ello
debemos precisar primero porque orientado a objetos. Un objeto puede ser algo tan trivial como
una silla o una mesa, pero en el mundo hay infinidad de objetos de ese tipo y las declaraciones
de atributos y operaciones para cada uno sera muy difcil y desgastante. La verdadera esencia
de la orientacin a objetos est en la estructuracin de una jerarqua de clases y esto trae
consigo otros conceptos que siguen. Por otra parte los objetos deben comunicarse unos con
otros. Es por ello que Coad y Yourdon definieron la orientacin a objetos as:
Orientado a objetos = Objetos + Clasificacin + Herencia + Comunicacin.
Clases y objetos.
Un modelo orientado a objetos de SW debe exhibir abstracciones de datos y procedimientos

que conduzcan a una modularidad eficaz. Una clase es un concepto orientado a objetos que
encapsula las abstracciones de datos y procedimientos que se requieren para describir el
contenido y el comportamiento de alguna entidad del mundo real.
Una clase es una descripcin generalizada que describe una coleccin de objetos similares.
Por definicin, todos los objetos que existen dentro de una clase heredan sus atributos y
operaciones. De este concepto se derivan cosas como:
Una superclase es una coleccin de clases.

Una subclase es una instancia de una clase.
Es interesante sin embargo la notacin de Taylor sobre una clase, donde queda destacado de
forma relevante que la clase encapsula las abstracciones de datos (atributos) dentro de una
muralla de abstracciones procedimentales (operaciones), a travs de la cual hay que pasar
para poder acceder a los datos. De esta forma queda representado de alguna manera el
concepto de ocultacin de la informacin. Tambin favorece el concepto de alta cohesin entre
los mtodos y los pocos datos que estos manipulan, mientras que se presupone tambin, el
acople de la clase con otros elementos del sistema a travs de la comunicacin va mtodos.
Para todas las cosas orientadas a objetos, el marco de referencia conceptual es el modelo de
objetos que incluye cuatro elementos fundamentales: abstraccin, encapsulamiento,
modularidad y jerarqua; as como tres elementos secundarios: tipos, concurrencia y
persistencia.
Una abstraccin denota las caractersticas esenciales de un objeto que lo distinguen de todos
los dems tipos de objetos y proporciona as fronteras conceptuales ntidamente definidas
respecto a la perspectiva del observador.
El encapsulamiento es el proceso de almacenar en un mismo compartimento los elementos de
una abstraccin que constituyen su estructura y su comportamiento; sirve para separar la
interfaz contractual de una abstraccin y su implantacin.
La modularidad es la propiedad que tiene un sistema que ha sido descompuesto en un
conjunto de mdulos cohesivos y dbilmente acoplados.
La jerarqua es una clasificacin u ordenacin de abstracciones.
Los tipos son la puesta en vigor de una clase de los objetos, de modo que los objetos de tipos
distintos no pueden intercambiarse o, como mucho, pueden intercambiarse slo de formas muy
restringidas.
La concurrencia es la propiedad que distingue un objeto activo de uno que no est activo.
La persistencia es la propiedad de un objeto por la que su existencia trasciende el tiempo, el
espacio, o ambos.
Atributos.
Los atributos son las caractersticas estables que identifican claramente a los objetos y clases
de objetos de la vida real. Se puede decir que una caracterstica puede verse como una
relacin binaria entre una clase y cierto dominio donde quedan definidos los posibles valores
que puede tomar esa caracterstica.
Ejemplo: Clase: carro, atributo: color, dominio del atributo: {blanco, rojo, verde, ...}
Operaciones.
Lo caracterstico de la programacin orientada a objetos est en que las clases y objetos

encapsulan dentro de s no solo atributos, sino tambin las operaciones (mtodos o servicios)
que se implementan para que este objeto reaccione ante un estmulo.
Las operaciones pueden ser vistas como mdulos en el sentido convencional y son algoritmos
de procesamiento de los datos contenidos en esa clase.
Mensajes.
Los mensajes son el medio a travs del cual los objetos interactuan, o sea un mensaje estimula
la ocurrencia de cierto comportamiento en el objeto receptor. El comportamiento se realiza
cuando se ejecuta una operacin.
El pase de mensajes mantiene comunicados a los objetos de un sistema orientado a objetos.
Los mensajes proporcionan una visin interna del comportamiento de objetos individuales y del
sistema orientado a objetos como un todo.
Encapsulamiento, herencia y polimorfismo.
Estos son tres conceptos clsicos dentro de la orientacin a objetos.

Las clases y los objetos derivados de ellas "encapsulan" los datos y las operaciones que
trabajan sobre estas en un nico paquete. Esto posibilita que:
Los detalles de implementacin interna de los datos y operaciones estn ocultos al

mundo exterior (ocultamiento de la informacin). Esto reduce la propagacin de efectos
colaterales cuando ocurren cambios.
Las estructuras de datos y las operaciones que las manipulan estn mezcladas en una
simple entidad: clases. Esto facilita la reutilizacin de componentes.
Las interfaces entre objetos encapsulados estn simplificadas. Un objeto que enva un
mensaje no se tiene que preocupar de los detalles de estructuras de datos internas en
el objeto receptor. Esto simplifica la interaccin y el acoplamiento tiende a reducirse.
La herencia es un mecanismo que posibilita la reutilizacin de componentes existentes (como

superclase) y reduce el trabajo de creacin nuevo. Tambin da la posibilidad de propagar
rpidamente por todo el sistema los cambios realizados en niveles superiores de la jerarqua de
clases. Por otra parte es posible aadir nuevos atributos y operaciones a las subclases dentro
de la jerarqua. Para crear una nueva clase el ingeniero del software puede:
Disear y crear una clase desde cero (no usa herencia).

Rastrear la jerarqua de clases para localizar una clase que tenga la mayora de los
atributos y operaciones que necesita la nueva clase, aadindosele a la misma los
elementos nuevos necesarios.
Reestructurar la jerarqua de clases para que los atributos y operaciones necesarias
puedan ser heredadas por la nueva clase.
Sobreescribir las caractersticas de una clase existente e implementar versiones
privadas de atributos y operaciones para la nueva clase.
A veces la reestructuracin de la jerarqua puede ser ms difcil y puede ser entonces

necesario heredar de una clase que tiene alguna caracterstica que no necesite la nueva clase.
En ese caso se aplica la "anulacin" de esa caracterstica, haciendo que la herencia no sea
transitiva como seala Ivar Jacobson en su metodologa OOSE.
En otras ocasiones sucede que es necesario heredar algunos atributos y operaciones de una
clase y otros de otra clase. Esto se conoce como "herencia mltiple" y es un concepto muy
controvertido pues se sale de la jerarqua normal de clases. Al respecto hay una serie de
recomendaciones dadas por James Rumbaugh en su libro "Modelado y Diseo Orientado a
Objetos. Metodologa OMT"
El polimorfismo es una caracterstica que reduce en gran medida el esfuerzo necesario para
extender un sistema orientado a objetos. Se fundamenta en una interpretacin, o mejor en una
implementacin especfica de una operacin de una clase, de forma diferente en algunas de
sus subclases u objetos, de manera que estos puedan "privatizar" esa operacin y no haya
necesidad de redefinirla para toda la jerarqua o prever las diferentes variantes en la clase. Esto
reduce el acoplamiento entre objetos, haciendo a cada uno ms independiente.
Identificacin de los elementos de un modelo de objetos.
Identificacin de clases y objetos.
Los objetos pueden ser:
Entidades externas (otros sistemas, dispositivos, personas) que producen o consumen

informacin a usar por un sistema computacional.
Cosas (informes, presentaciones, cartas, seales) que son parte del dominio de
informacin del problema.
Ocurrencias o eventos (una trasferencia de propiedad, aniversario) que ocurren dentro
del contexto de la operacin del sistema.
Papeles o roles (director, ingeniero, etc.) desempeados por personas que interactuan
con el sistema.
Unidades organizacionales (divisin, grupo, equipo) que son relevantes en una
aplicacin.
Lugares (planta de produccin o muelle) que establece el contexto del problema y la
funcin general del sistema.
Estructuras (sensores, vehculos, computadoras) que definen una clase de objetos, o
clases relacionales con objetos.
Coad y Yourdon sugieren las caractersticas de seleccin de objetos potenciales para incluirlos
en el modelo de anlisis:
Informacin retenida: el objeto potencial ser de utilidad durante el anlisis solamente

si la informacin acerca de l debe recordarse para que el sistema funcione.
Servicios necesarios: el objeto potencial debe poseer un conjunto de operaciones

identificables que pueden cambiar de alguna manera el valor de los atributos.
Atributos mltiples: durante el anlisis de requisitos se debe centrar la atencin en la
informacin principal (un objeto con un solo atributo, puede en efecto, ser til durante el
diseo, pero seguramente ser mejor representado como un atributo dentro de otro
objeto durante las actividades de anlisis).
Atributos comunes: puede definirse un conjunto de atributos del objeto potencial,
aplicables a todas las ocurrencias del objeto.
Operaciones comunes: puede definirse un conjunto de operaciones del objeto
potencial, aplicables a todas las ocurrencias del objeto.
Requisitos esenciales: entidades externas que producen o consumen informacin
esencial del sistema.
Especificacin de atributos.
Los atributos describen un objeto que ha sido seleccionado para ser incluido en el modelo de
anlisis.
Para desarrollar un conjunto significativo de atributos para un objeto, el analista puede estudiar
de nuevo la descripcin del mbito y el alcance para el problema y seleccionar aquellos
elementos que pertenecen al objeto.
Definicin de operaciones.
Las operaciones definen el comportamiento de un objeto y cambian de alguna forma los

atributos del objeto. Por tanto, una operacin debe conocer la naturaleza de los atributos de los
objetos y debe ser implementada de manera que permita manipular las estructuras de datos,
derivadas de dichos atributos. Existen:
Operaciones que manipulan de alguna forma datos.

Operaciones que realizan algn clculo
Operaciones que monitorizan un objeto frente a la ocurrencia de un suceso de
control.
Gestin de proyectos de software orientado a objetos.

Como ya se analiz en clases anteriores, la gestin de proyectos actual puede subdividirse en
las siguientes actividades:
Establecimiento de un marco de proceso comn para el proyecto.

Uso del marco y de mtricas histricas para desarrollar estimaciones de esfuerzo y
tiempo.
Especificacin de productos de trabajo y avances que permitirn la medicin del
progreso.
Definicin de puntos de comprobacin para asegurar la calidad y el control.
Gestin de cambios que ocurren invariablemente al progresar el proyecto.
Seguimiento, monitorizacin y control del progreso.
Se analizarn cada una de ellas a continuacin.
Marco de proceso comn para orientado a objetos.
El marco de proceso comn para orientado a objetos siempre es adaptable, para que siempre
cumpla con las necesidades individuales del equipo de proyecto. Aqu se define el enfoque
organizativo para el desarrollo y mantenimiento del SW, o sea se identifica el paradigma de
ingeniera de software, as como las tareas, hitos y entregas requeridos; tambin se especifica
el grado de rigor con que se enfocan los diferentes tipos de proyectos.
Ed Berard y Grady Booch proponen el uso de un modelo recursivo/paralelo para el desarrollo
de SW orientado a objetos. Ese modelo funciona as:
Realizar los anlisis suficientes para aislar las clases de problemas y las conexiones
ms importantes.
Realizar un pequeo diseo para determinar si las clases y conexiones pueden ser
implementadas de manera prctica.
Extraer objetos reutilizables de bibliotecas, para construir un prototipo previo.
Conducir algunas pruebas para descubrir errores en el prototipo.
Obtencin de la realimentacin del cliente sobre el prototipo.
Modificar el modelo de anlisis basndose en lo que se ha aprendido del prototipo, de
la realizacin del diseo y de la realimentacin obtenida del cliente.
Refinar el diseo para acomodar sus cambios.
Construccin de objetos especiales (no disponibles en bibliotecas).
Ensamblar el nuevo prototipo usando objetos de la biblioteca y los objetos que se
crearon nuevos.
Realizar pruebas para descubrir errores en el prototipo.
Obtencin de la realimentacin del cliente sobre el prototipo.
Este enfoque contina hasta que el prototipo evoluciona hacia una aplicacin productiva.
Un poco ms concretamente el modelo pudiera definirse as:
Descomposicin sistemtica del problema en componentes altamente independientes.

Aplicar de nuevo el proceso de descomposicin a cada una de las componentes
independientes para, a su vez, descomponerlas (parte recursiva).
Conduccin de este proceso de reaplicar la descomposicin de forma concurrente
sobre todas las componentes (parte paralela).
Continuar este proceso hasta cumplir los criterios de completamiento.
Mtricas y estimacin de proyectos orientado a objetos.
Las estimaciones realizadas a partir de LCF tienen poco sentido en proyectos orientado a
objetos debido a que el objetivo fundamental es la reutilizacin. Las estimaciones a partir de PF
pueden usarse de manera efectiva, pues los elementos del dominio de la informacin
requeridos se pueden determinar a partir del planteamiento del problema, solo que la medida
de PF no provee una granularidad suficiente para ajustes de planificacin y esfuerzo a realizar,
lo cual es necesario si iteramos en un paradigma recursivo/paralelo.
Lorenz y Kidd sugieren el siguiente conjunto de mtricas para proyectos:
Nmero de guiones de escenario: un guin de escenario es una secuencia detallada

de pasos que describen la interaccin entre el usuario y la aplicacin. Cada guin se
organiza en triplas de la forma: {iniciador, accin, participante}. El nmero de guiones
de actuacin est determinado al tamao de la aplicacin y al nmero de casos de
prueba que se deben desarrollar para ejercitar el sistema una vez concluido.
Nmero de clases claves: las clases clave son las componentes altamente
independientes definidas inicialmente en el anlisis orientado a objetos. Debido a que
estas clases son centrales al dominio del problema, el nmero de dichas clases es una
indicacin del esfuerzo necesario para desarrollar el SW y de la cantidad potencial de
reutilizacin a aplicar durante el desarrollo del sistema.
Nmero de clases de soporte: las clases de soporte son necesarias para
implementar el sistema, pero no estn directamente relacionadas con el dominio del
problema. Como ejemplo estn las clase de la IGU, el acceso a bases de datos y su
manipulacin y las clases de la comunicacin. Adicionalmente las clases de soporte se
definen iterativamente a lo largo del proceso recursivo/paralelo. El nmero de clases de
soporte es un indicador del esfuerzo necesario requerido para desarrollar el SW y de la
cantidad potencial de reutilizacin a aplicar durante el desarrollo del sistema.
Nmero promedio de clases de soporte por clase clave: por lo general las clases
claves se conocen al inicio del proyecto, mientras que las de soporte se definen a lo
largo de este. Si dado un dominio de problema se conociera la cantidad promedio de
clases de soporte por cada clase clave, la estimacin se simplificara mucho.
Nmero de subsistemas: un subsistema es una agregacin de clases que dan
soporte a una funcin visible al usuario final del sistema. Una vez que se identifican los
subsistemas, resulta ms fcil realizar una planificacin razonable en la cual el trabajo
en los subsistemas est repartida entre los miembros del proyecto.
Un enfoque orientado a objetos para estimaciones y planificacin.
Aunque se pueden usar los conceptos de estimaciones y planificacin estudiados antes a los
proyectos orientado a objetos, debe tenerse en cuenta que en la mayora de las empresas de
desarrollo de SW, estos son muy recientes y pocos, como para crear una base histrica
suficiente. Por ello Lorenz y Kidd sugieren el siguiente enfoque:
Desarrollo de estimaciones usando la descomposicin de esfuerzos, anlisis de PF, y

cualquier otro mtodo aplicable a aplicaciones convencionales.
Desarrollo de guiones de escenario y determinar una cuenta, usando anlisis orientado
a objetos. Reconozca que el nmero de guiones de escenarios puede cambiar con el
progreso del proyecto.
Determinacin de la cantidad de clases clave usando anlisis orientado a objetos.
Clasificacin del tipo de interfaz para la aplicacin y desarrollo de un multiplicador para
las clases de soporte:
Tipo de Interfaz
Multiplicador
Interfaz no grfica (no IGU)
2,0
Interfaz de usuario basada en

texto
2,25
Interfaz grfica de usuario (IGU)
2,5
Interfaz grfica de usuario

compleja
3,0
Multiplican el nmero de clases clave por el multiplicador anterior para obtener

una estimacin del nmero de clases de soporte.
Multiplicacin de la cantidad total de clases (clave + soporte) por el nmero de

unidades de trabajo por clase. Lorenz y Kidd sugieren entre 15 y 20 das/persona por
clase.
Comprobacin de la estimacin respecto a clases, multiplicando el nmero promedio
de unidades de trabajo por guin de accin.
La planificacin para proyectos orientados a objetos es complicada por la naturaleza iterativa

del marco del trabajo del proceso. Otras mtricas que pueden ayudar a la planificacin de
proyectos:
Nmero de iteraciones principales.

Nmero de contratos completos.
Seguimiento del progreso en un proyecto orientado a objetos.
El paralelismo del proyecto puede afectar el seguimiento del proyecto. El jefe de proyecto
puede tener dificultades al establecer hitos significativos, debido a que ciertas cosas suceden a
la vez. En general, los siguientes hitos pueden considerarse terminados al cumplirse los
criterios mostrados:
Hito tcnico: anlisis orientado a objetos terminado.
Todas las clases, y la jerarqua de clases estn definidas y revisadas.

Los atributos de clases y las operaciones asociadas a una clase se han definido y
revisado.
Las relaciones entre clases se han establecido y revisado.
Se han creado y revisado un modelo de comportamiento.
Se han marcado clases reutilizables.
Hito tcnico: diseo orientado a objetos terminado.
El conjunto de subsistemas se ha definido y revisado.

Las clases se han asignado a subsistemas y han sido revisadas.
Se ha establecido y revisado la asignacin de tareas.
Se han identificado responsabilidades y colaboraciones.
Se han diseado y revisado atributos y operaciones.
El modelo de pase de mensajes se ha creado y revisado.
Cada nueva clase ha sido implementada en cdigo a partir del modelo de diseo.
Las clases extradas de una biblioteca se han integrado.

Se ha construido un prototipo o incremento.
Hito tcnico: prueba orientada a objetos.
La correccin y completamiento del anlisis orientado a objetos y del modelo de diseo

se han revisado.
Se ha desarrollado y revisado una red de clases responsabilidades colaboraciones.
Se han diseado casos de prueba y ejecutado pruebas en el mbito de clases para
cada clase.
Se han diseado casos de prueba y completado las pruebas de agrupamientos y las
clases se han integrado.
Las pruebas al nivel de sistema se han terminado.
Consideraciones del Anlisis Orientado a Objetos.

El objetivo del anlisis orientado a objetos es desarrollar una serie de modelos que describan al
SW de computadoras al trabajar para satisfacer un conjunto de requisitos definidos por el
cliente. El modelo de anlisis ilustra informacin, funcionamiento y comportamiento dentro del
contexto de los elementos del modelo de objetos.
Para cumplir con el propsito del anlisis orientado a objetos se debe hacer lo siguiente:
Los requisitos bsicos del usuario deben comunicarse entre el cliente y el ingeniero del
SW.
Identificacin de las clases (definir atributos y operaciones).
Especificacin de una jerarqua de clases.
Representacin de las relaciones de objeto a objeto (conexiones).
Modelacin del comportamiento del objeto.
Repetir iterativamente las tareas anteriores hasta terminar el modelo.
La popularidad de la tecnologa orientada a objetos ha generado varios mtodos de anlisis

orientado a objetos. Cada uno introduce un proceso para el anlisis de un producto o sistema,
un conjunto de modelos que evoluciona fuera del proceso y una notacin que posibilita al
ingeniero del software crear cada modelo de manera consistente. Analizaremos algunos de los
ms populares.
En el contexto de la ingeniera del software, se sugiere que el propsito del diseo es construir
un sistema que:
Satisface determinada especificacin funcional.

Se ajusta a las limitaciones impuestas por el medio de destino.
Respeta requisitos implcitos o explcitos sobre rendimiento y utilizacin de recursos.
Satisface criterios de diseo implcitos o explcitos sobre la forma del SW.
Satisface restricciones sobre el propio proceso de diseo, tales como su longitud o
costo, o las herramientas disponibles para realizar el diseo.
La construccin de modelos goza de amplia aceptacin entre todas las disciplinas de

ingeniera, sobre todo porque construir un modelo es algo atractivo respecto a los principios de
descomposicin, abstraccin y jerarqua. Cada modelo dentro de un diseo describe un
aspecto especfico del sistema que se est considerando. Los modelos dan la oportunidad de
fallar en condiciones controladas, y modificarlo cuando falla para que se comporte del modo
esperado o deseado, sin grandes prdidas.
La comunidad de la ingeniera del software ha desarrollado docenas de mtodos de diseo
diferentes. A pesar de sus diferencias, todos estos mtodos tienen elementos en comn, como
son:
Notacin: El lenguaje para expresar cada modelo.

Proceso: Las actividades que encaminan a la construccin ordenada de los modelos
del sistema.
Herramientas: Los artefactos que eliminan el tedio de construir el modelo y reafirman
las reglas sobre los propios modelos, de forma que sea posible revelar errores e
inconsistencias.
Un buen mtodo de diseo se basa en fundamentos tericos slidos, pero eso no le impide
ofrecer grados de libertad para la innovacin artstica.
Cuando se habla de la aplicacin de metodologas orientadas a objetos, debemos considerar
que casi todas hablan de establecer tal como en el ciclo de vida clsico del desarrollo de un
software, una etapa de anlisis y otra de diseo antes de la implementacin. En concreto, qu
se entiende por estas cosas?.
"El anlisis orientado a objetos es un mtodo de anlisis que examina los

requisitos desde la perspectiva de las clases y objetos que se encuentran en el
vocabulario del dominio del problema".
"El diseo orientado a objetos es un mtodo de diseo que abarca el proceso

de descomposicin orientado a objetos y una notacin para describir los
modelos lgico y fsico, as como los modelos esttico y dinmico del sistema
que se disea".
Mtodo de Coad y Yourdon.
Este mtodo se considera con frecuencia como uno de los ms fciles de aprender. La
notacin del modelado es relativamente simple y las reglas para desarrollar el modelo de
anlisis son evidentes. Consiste en:
Identificacin de objetos usando criterios de "que buscar".

Definicin de una estructura de generalizacin especificacin.
Definicin de una estructura de todo parte.
Identificacin de temas.
Definicin de atributos.
Definicin de servicios.
Mtodo de Wirfs y Brock.
Este mtodo no hace una distincin clara entre las tareas de anlisis y diseo. En su lugar, se
propone un proceso continuo que comienza con la valoracin de una especificacin del cliente
y termina con el diseo. Las tareas relacionadas con este mtodo son:
Evaluacin de la especificacin del cliente.

Uso de un anlisis gramatical para extraer clases candidatas de la especificacin.
Agrupamiento de las clases en un intento de determinar superclases.
Definicin de responsabilidades para cada clase.
Asignacin de responsabilidades a cada clase.
Identificacin de relaciones entre clases.
Definicin de colaboraciones entre clases basndose en sus responsabilidades.
Construccin de representaciones jerrquicas de clases para mostrar relaciones de
herencia.
Construccin de un grfico de colaboraciones para el sistema.
Mtodo de Martin y Odell.
Este mtodo es bastante simple y pragmtico, pero refleja una concepcin de AOO muy
cercana a mtodos tradicionales pues se hace anlisis independiente de la estructura esttica y
la dinmica de los objetos. En concreto se hace:
Anlisis de los requisitos del cliente.

Identificacin de la estructura esttica del objeto.
Modelacin del anlisis de la estructura del objeto.
Identificacin de la estructura dinmica de los objetos.
Modelacin del anlisis del comportamiento de los objetos.
Modelo de Requerimientos
En su libro de Ingeniera del Software Orientada a Objetos, Jacobson plantea con respecto a su
metodologa que: "La primera transformacin hecha es, de la especificacin de los
requerimientos, al modelo de requerimientos. El modelo de requerimientos consiste de: un
modelo de casos de usos, la descripcin de las interfaces y un modelo del dominio del
problema".
Los modelos de casos de uso usan dos conceptos bsicos: actores y casos de uso. Estos
ayudan a definir que existe fuera del sistema (actores) y que debe ser ejecutado por el sistema
(casos de uso). En otras palabras, los actores representan lo que interacta con el sistema, sin
querer decir con esto que un actor es un usuario, ya que este ltimo es la persona que
realmente usa el sistema, mientras que el actor puede ser el rol que un usuario puede jugar.
Por otra parte un caso de uso puede ser considerado una secuencia de transacciones
relacionadas contenidas en una interfaz en el sistema.
Un sistema diseado de esta forma puede ser considerado como un sistema controlado por
Casos de Uso. Esto implicara que cualquier modificacin o mejora al sistema implicara el
rediseo del actor y del caso de uso apropiado. "Para soportar el modelo de casos de uso es
generalmente apropiado desarrollar tambin interfaces de los casos de uso".
Para comprender mejor a los casos de uso, es posible modelar sus descripciones como
diagramas de transicin de estado, en el cual cada estmulo enviado entre un actor y el sistema
ejecuta un cambio de estado en el grfico. La razn por la que se busque inicialmente a los
actores est en que ellos son la mejor herramienta para hallar los casos de uso correctamente.
El mtodo de Jacobson conocido tambin por OOSE (ISWOO), es una simplificacin de
OBJECTORY, tambin de Jacobson. Se diferencia de los dems por la importancia que le da al
caso de uso que describe como el usuario interacta con el producto o sistema. Consiste en:
Identificacin de los usuarios del sistema y sus responsabilidades globales.

Construccin de un modelo de requisitos.
Definicin de los actores y sus responsabilidades.

Identificacin de los casos de uso para cada actor.
Preparacin de una visin inicial de los objetos del sistema y sus relaciones.
Revisin del modelo usando los casos de uso como escenarios para determinar su
validez.
Construccin de un modelo de anlisis.
Identificacin de objetos de interfaz usando informacin del tipo actor interaccin.

Creacin de vistas estructurales de los objetos de la interfaz.
Representacin del comportamiento del objeto.
Aislamiento de subsistemas y modelos para cada uno.
Revisin del modelo usando casos de uso con escenarios para determinar su validez.
En general OOSE est compuesto por cinco modelos que son:
El modelo de requerimientos que ayuda a capturar los requerimientos funcionales.

El modelo de anlisis que ayuda a darle al sistema una estructura de objetos robusta y
modificable.
El modelo de diseo que ayuda a adaptar y refinar la estructura de objetos al ambiente
real de implementacin.
El modelo de implementacin que ayuda a implementar el sistema.
El modelo de prueba que ayuda a verificar el sistema.
Actividades Obligatorias:
o
o
o
o
Cual es el metodo de Coad y Yourdon?

Cuales son las caractersticas de seleccin de objetos potenciales para
incluirlos en el modelo de anlisis que Couad y Yourdon sugieren?
En que consiste el Mtodo de Martin y Odell.
En que consiste el Mtodo de Wirfs y Brock.
Actividades Sugeridas:
o
o
o
o
En que consiste el mtodo de Jacobson

Sucede unicamente el polimorfismo cuando hay herencia?
Cul es el modelo de requerimientos?
Qu es el encapsulamiento?
http://computo.cuci.udg.mx/IngSoft/Teoria/estatico.htm
Autoevaluacin:
1.
2.
3.
4.
5.
Qu es una superclase?
Qu es una subclase?
Qu es un atributo?
Que son las operaciones?
Qu son los mensajes?
3.4.1 MODELO DINAMICO (comportamiento)
Modelos de Objeto y Dinmico

En su libro de Modelacin y Diseo Orientado a Objetos, Rumbaugh seala con respecto a su
metodologa OMT que: "La metodologa consiste en construir un modelo de un dominio de
aplicacin aadindosele detalles de implementacin durante el diseo del sistema. Esta
aproximacin se denomina Tcnica de Modelado de Objetos (OMT) y consta de las siguientes
fases: Anlisis, Diseo de Sistema, Diseo de Objetos e Implementacin".
La metodologa OMT consta para su desarrollo con tres modelos bsicos que son:
1. 1.Modelo de Objetos: describe la estructura esttica de los objetos del sistema, y

tambin sus relaciones. El modelo de objetos contiene diagramas de objetos, los
cuales no son ms que grafos cuyos nodos son clases de objetos y cuyos arcos son
relaciones entre clases.
2. 2.Modelo Dinmico: describe los aspectos de un sistema que cambian con el tiempo.
El modelo dinmico se utiliza para especificar e implementar los aspectos de control
del sistema. Los modelos dinmicos contienen diagramas de estado, los cuales no son
ms que grafos cuyos nodos son estados y cuyos arcos son transiciones entre estados
causadas por sucesos.
3. 3.Modelo Funcional: describe las transformaciones de valores de datos que ocurren
dentro del sistema. El modelo funcional contiene diagramas de flujos de datos, los
cuales son grafos cuyos nodos son procesos y cuyos arcos son flujos de datos.
Si algo es importante, entre otras cosas en la OMT es la forma simple en que orienta utilizar el
modelo dinmico, o sea los diagramas de estado, para representar una interfaz interactiva
hombre mquina, ya que "el modelo dinmico captura el control, aquel aspecto de un sistema
que describe las secuencias de operaciones que se producen sin tener en cuenta lo que hagan
las operaciones, aquello a lo que afecten o la forma en que estn implementadas".
El mtodo de Rumbaugh consiste en:
Desarrollo de una declaracin del mbito del problema.

Desarrollo de un modelo de objetos.
Identificacin de clases relevantes al problema.
Definicin de atributos y asociaciones.

Definicin de enlaces de objetos.
Organizacin de las clases de objetos usando la herencia.
Desarrollo de un modelo dinmico.
Preparacin de escenarios.
Definicin de eventos y desarrollo de una traza de eventos para cada escenario.
Construccin de un diagrama de flujos de datos.
Desarrollo de un diagrama de estado.
Revisin del comportamiento para comprobar consistencia y completitud.
Desarrollo de un modelo funcional.
Identificacin de entradas y salidas.

Uso de diagramas de flujos de datos para representar transformaciones del flujo.
Desarrollo de especificaciones de proceso para cada funcin.
Especificacin de criterios de restricciones y optimizacin.
Mtodo de Grady Booch.

En su libro Anlisis y Diseo Orientado a Objetos con Aplicaciones, Grady Booch seala que:
"Los mtodos son importantes por varias razones. En primer lugar, inculcan una disciplina en el
desarrollo de sistemas de software complejos. Definen los productos que sirven como vehculo
comn para la comunicacin entre los miembros de un equipo de desarrollo. Adems, los
mtodos definen los hitos que necesita la direccin para medir el progreso y gestionar el
riesgo".
El papel del ingeniero como artista es particularmente dificultoso cuando la tarea es disear un
sistema completamente nuevo. Francamente, es la circunstancia ms habitual en la ingeniera
del software.
"Es imposible capturar todos los detalles sutiles de un sistema de software

complejo en una sola vista. ... Uno debe comprender la estructura taxonmica
de las clases, los mecanismos de herencia utilizados, los comportamientos
individuales de los objetos y el comportamiento dinmico del sistema en su
conjunto".
El mtodo de Booch incluye los siguientes diagramas:

1. 1.
Diagramas de Clases. Se usa para mostrar la existencia de clases y sus
relaciones en la visin lgica de un sistema. Un solo diagrama de clases representa
una vista de la estructura de clases de un sistema. Durante el anlisis, se utilizan
diagramas de clases para indicar las misiones y responsabilidades comunes de las
entidades que caracterizan el comportamiento de un sistema. Durante el diseo, se
utilizan diagramas de clases para plasmar la estructura de las clases que forman la
arquitectura del sistema.
2. 2.
Diagramas de Objetos. Se usa para mostrar la existencia de objetos y sus
relaciones en el diseo lgico de un sistema. O sea, un diagrama de objetos representa
3.
4.
5.
6.
una instantnea en el tiempo de una corriente de eventos sobre una cierta

configuracin de objetos.
3.
Diagramas de Mdulos. Se usa para mostrar la asignacin de clases y objetos a
mdulos en el diseo fsico de un sistema. Un solo diagrama de mdulos representa
una vista de la estructura de mdulos de un sistema.
4.
Diagramas de Procesos. Se usa para mostrar la asignacin de procesos a
procesadores en el diseo fsico de un sistema. Un solo diagrama de procesos
representa una vista de la estructura de procesos de un sistema.
5.
Diagramas de Transicin de Estados. Se usa para mostrar el espacio de
estados de una clase determinada, los eventos que provocan una transicin de un
estado a otro, y las acciones que resultan de ese cambio de estado.
6.
Diagramas de Interaccin. Se usa para realizar una traza de la ejecucin de un
escenario en el mismo contexto que un diagrama de objetos.
Booch en esencia plantea que para trabajar con su mtodo es conveniente trabajar en dos
partes fundamentales: un microproceso y un macroproceso. Ambas partes incluyen varios
pasos como son la identificacin de clases y objetos a un nivel de abstraccin dado, la
identificacin de la semntica de esas clases y objetos, la identificacin de las relaciones entre
esas clases y objetos, la seleccin de la estructura de datos y algoritmos para la implantacin
de estas clases y objetos, la conceptualizacin del sistema, etc. El microproceso de desarrollo
del AOO de Booch incluye:
Identificacin de clases y objetos.

Proposicin de objetos candidatos.
Conduccin del anlisis de comportamiento.
Identificacin de escenarios relevantes.
Definicin de atributos y operaciones para cada clase.
Identificacin de la semntica de clases y objetos.
Seleccin y anlisis de escenarios.

Asignacin de responsabilidades para alcanzar el comportamiento deseado.
Divisin de las responsabilidades para equilibrar el comportamiento.
Seleccin de un objeto y enumerar sus papeles y responsabilidades.
Definicin de operaciones para satisfacer las responsabilidades.
Bsqueda de colaboraciones entre objetos.
Identificacin de interrelaciones entre clases y objetos.
Definicin de las dependencias que existen entre objetos.

Descripcin del papel de cada objeto participante.
Validacin de escenarios por revisin completa.
Realizacin de una serie de refinamientos.
Produccin de los diagramas apropiados para el trabajo realizado en las partes

anteriores.
Definicin de jerarquas de clases apropiadas.
Creacin de agrupamientos basados en clases comunes.
Implementacin de clases y objetos.
Actividades obligatorias
o
o
o
Explique en que consiste el mtodo de Rumbaugh

Explique el Mtodo de Grady Booch.
Explique los diagramas que incluye el mtodo de Booch
o
o
Explique los tres modelos bsicos que la metodologa OMT consta para su
desarrollo
Mensione lo que incluye el microproceso de desarrollo del AOO de Booch

http://computo.cuci.udg.mx/IngSoft/Teoria/dinamico.htm
Autoevaluacin
1.
2.
3.
4.
Cul o en qu consiste el modelo dinmico?

Cul es el mtodo de Grady Booch?
Cul es el modelo funcional?
Para qu se usa el diagrama de objetos?
OBJETIVO DEL DISEO
El diseo es el proceso de determinar cual de muchas posibles soluciones es la mejor para

lograr lo que se necesita hacer, respetando las restricciones tecnolgicas y de presupuesto del
proyecto. El diseo escoge un cmo especifico para aplicarlo al qu.
El diseo consiste en decidir la manera en que debe construirse el sistema para satisfacer los
requerimientos de los usuarios. Las buenas metodologas de diseo comparten las siguientes
caractersticas:
1. El buen diseo debe motivar la toma de decisiones ayudando a evaluar
alternativas. Todo el diseo es acerca de compromisos. Una tcnica de diseo debe
permitir que el diseador evale su decisin contra otras posibilidades. Por ejemplo,
usando el modelo de anlisis de eventos acoplado con el esquema de diseo de datos,
el diseador puede simular el volumen de lecturas y escrituras a la base de datos para
cualquier evento de negocios dado. Esto permite que el equipo evale la factibilidad y
desempeo proyectado de una disposicin de tabla de base de datos dada y de un
esquema de distribucin de datos antes de construirlos.
2. El diseo necesita ser completo, de tal forma que cubra cada uno de los aspectos
principales del software que necesita construirse. Esto causara que se tengan varios
tipos diferentes de modelos en la documentacin del diseo. Cada modelo est
especializado para mostrar un aspecto particular del sistema. Encontrar que los
modeladores son particularmente adeptos de la articulacin de esos aspectos para los
que est orientada la tcnica de modelado, pero fallan miserablemente cuando se trata
de estirar el modelo ms all de su propsito original. Ningn modelo puede mostrar
todas las facetas del sistema funcional completo. Ese sera el sistema mismo.
3. El diseo debe ser verificable antes de su construccin. Uno de los propsitos

principales del diseo es revisar y discutir la solucin antes de lanzarse a la carga y
codificarla. Parte del proceso de verificacin es su rastreabilidad. Con una buena
especificacin del diseo se debe ser capaz de demostrar que se satisfarn los
requerimientos del proyecto y as mismo se distinguir entre varias versiones del
diseo en cualquier momento.
4. Una buena metodologa de diseo crea productos diferenciados que son
mensurables. Una de las tareas ms difciles de cualquier proyecto es estimar cuando
se terminar. Para hacer una estimacin el gerente del proyecto debe tomar medidas,
la cual involucra el conteo de cosas que necesitan hacerse y la aplicacin de algn tipo
de medida sobre ellas para estimar que tanto tiempo se llevara el hacerlas. La
medicin viene, por supuesto, de haber contado estas cosas en el pasado y haber
medido que tanto tardo el hacerlas anteriormente. Por lo tanto, una metodologa de
diseo debe producir componentes discretos lo ms pronto posible.
5. Por ltimo, pero no menos importante, el diseo debe ser fcilmente aprovechado
en el producto final. Debe expresar el uso y la estructura del sistema en una forma
muy cercana al resultado pretendido. Este punto puede parecer obvio, pero se ha visto
proyectos que trataron de usar tcnicas de diseo que fueron completamente
inadecuadas para el lenguaje de destino en el que se codifico el sistema. Usted no
querra que su arquitecto casero le presentara un plano que fuera tan esotrico que no
le diera idea de la forma que tendra la casa en su terreno. El lema de un diseador es:
hacer un mapa de la tcnica hacia el destino. Si el sistema va a operar con una base
datos relacional se deben escoger tecnicas que sean particularmente adecuadas para
el diseo de bases de datos relacionales. Si el sistema empleara un lenguaje orientado
a objetos, entonces se debern usar tcnicas de diseo orientado a objetos para las
partes del sistema que requieren objetos para lograr sus tareas. Si el sistema incluir
componentes ms tradicionales, tales como funciones estructuradas en las rutinas
cliente o por lotes en el servidor, entonces son adecuadas tcnicas de diseo
estructurado ms tradicionales para esas partes del sistema.
o
o
o
Describa con sus propias palabras que es el diseo.

Diga con sus propias palabras cual es el objetivo del diseo.
Describa brevemente las caracteristicas de las buenas metodologas
o
o
Se disea software cuando se escribe un programa?

El diseo necesita ser complejo porque?

Pags. 2-3, Anlisis y diseo prctico de sistemas cliente/servidor con GUI, 1a. edicin, David A.
Ruble, Prentice Hall, 1997.
Autoevaluacin
1. Qu es el diseo?
2. En que consiste el diseo?
3. Cules son las tres caracteristicas de las 5 buenas metodologas del
diseo?
4. Porqu el diseo debe ser verificable antes de su cosntruccin?

5. Porqu el diseo debe ser aprovechado en el producto final?
4.2 COMO PASAR DEL ANALISIS AL DISEO

El anlisis es el proceso de determinar qu se necesita hacer, antes de decidir cmo debe
hacerse. El diseo escoge un cmo especifico para aplicarlo al qu.
Una vez que se ha analizado el problema, es preciso decidir la forma de aproximarse al diseo.
El diseo del sistema es la estrategia de alto nivel para resolver el problema y construir una
solucin. Este incluye decisiones acerca de la organizacin del sistema en subsistemas, la
asignacin de subsistemas a componentes hardware y software, y decisiones fundamentales
conceptuales y de poltica que son las que constituyen un marco de trabajo para el diseo
detallado.
Durante el anlisis, lo fundamental es lo que necesita hacerse, independientemente de la forma
de hacerlo. Durante el diseo, se toman decisiones acerca de la forma en que se resolver el
problema, primero desde un nivel un nivel elevado y despus empleando niveles cada vez ms
detallados.
El diseo de sistemas es la primera fase de diseo en la cual se selecciona la aproximacin
bsica para resolver el problema. Durante el diseo del sistema, se decide la estructura y el
estilo global. La arquitectura del sistema es la organizacin global del mismo en componentes
llamados subsistemas. La arquitectura proporciona el contexto en el cual se toman decisiones
ms detalladas en una fase posterior del diseo. Al tomar decisiones de alto nivel que se
apliquen a todo el sistema, el diseador desglosa el problema en subsistemas, de tal manera
que sea posible realizar ms trabajo por parte de varios diseadores que trabajaran
independientemente en distintos subsistemas. El diseador de sistemas debe tomar decisiones
siguientes:
Organizar el sistema en subsistemas.

Identificar la concurrencia inherente al problema.
Asignar los subsistemas a los procesadores y tareas.
Seleccionar una aproximacin para la administracin de almacenes de datos.
Manejar el acceso a recursos globales.
Seleccionar la implementacin de control en software.
Manejar las condiciones de contorno.
Establecer la compensacin de prioridades.
Con frecuencia, la arquitectura global de un sistema se puede se puede seleccionar basndose

en su similitud con otros sistemas anteriores. Alguna clase de arquitectura de sistemas son
tiles para resolver una amplia gama de problemas. Aunque no todos los problemas se pueden
resolver empleando una de estas arquitecturas. Otras muchas arquitecturas se pueden
construir combinando estas formas.
o
o
o
Explique brevemente con sus palabras como pasar del analisis al diseo?.
Cuales son las decisiones que el diseador deber tomar?
Describa cada uno de ellas.
o
o
o
Explique que es la arquitectura del sistema

Explique que es la arquitectua global?
Cul es la diferencia entre arquitectuar del sistema y arquitectura global?

Pags. 266-282, Modelado y diseo orientado a objetos, 1a. edicin, James Rumbauch,Michael
Blaha, William Premerlani, Frederick Eddy, William Lorensen, ed Mc Graw Hill, 1997.
Autoevaluacin
1.
2.
3.
4.
Qu es lo fundamental durante el diseo?

Escriba ocho decisiones que un diseador debe tomar
Cmo pasar del anlisis al diseo?.
Qu es la Arquitectura del sistema?
.............................................................................................................................................................................................
DISEO ORIENTADO A OBJETOS
En vez de desarrollar el diseo de un sistema software por medio de una descomposicin

funcional descendiente, se ha mencionado que la mejor metodologa es el diseo orientado al
objeto. En este diseo los componentes del software se ven mas como objetos que como
funciones. Cada objeto tiene una conjunto asociado de operaciones permitidas, y los objetos se
comunican mediante el paso de mensajes que, por lo general, incluyen una instruccin para
activar una instruccin para activar una funcin determinada.
El diseo orientado a objetos se basa en la idea de utilizar ocultamiento de informacin como
principal criterio de descomposicin y en la nocin de los tipos de datos abstractos. Esta
metodologa ha sido adoptada de manera entusiasta de algunos desarrolladores y educadores.
Abbot ha llegado a decir que "los programas bien escritos en ada suelen ser orientados al
objeto", no esta bien escrito. Tales generalizaciones sin comprobar no son de ayuda, y es poco
probable que haya alguna metodologa de diseo que sea superior a todas las circunstancias.
Para situar estos comentarios en perspectiva, se han construido muchos sistemas grandes
utilizando el diseo ascendente.
Y pocos con un enfoque orientado al objeto.
Por medio de un funcional, se identificaron las siguientes operaciones:
1.
2.
3.
4.
Dividir el documento en palabras.

Revisar si las palabras que no estn en el diccionario.
Formar listas de palabras que no estn en el diccionario.
Intercalar las palabras buenas en el diccionario, para obtener un nuevo diccionario.
Una nueva visin orientada al objeto de este sistema puede tener como objetos generalizados
documentos, diccionarios y listas de palabras. El sistema se puede presentar como un conjunto
de objetos actuando recprocamente.
Esta estrategia depende de la escritura de una descripcin informal en lenguaje natural acerca
de cmo tratar el problema de diseo. Dada esta descripcin, se extraen nombres comunes,
con fechas, mensajes, documentos, diccionarios, etc., y se consideran tipos de datos
abstractos. Los llamados nombres de mas como unidades de medida, nombres de calidades,
actividades, etc., tambin se incluyen en esta categora.
Los nombres propios y referencias directas a los nombres comunes, por ejemplo la fecha de
envo del sistema, un cumpleaos, la propuesta del proyecto, etc., se consideran como casos
de tipos de datos abstractos. Los verbos y adverbios se emplean para identificar operadores y
atributos de un objeto. Estos se asocian con el correspondiente tipo de datos abstractos.
Este enfoque de diseo orientado al objeto que se basa en una descripcin del problema el
lenguaje natural parece ser til en algunas circunstancias. Sin embargo, no esta claro como se
puede aplicar al diseo de sistemas grandes y complejos. Cuando un sistema es complejo y
con muchas funciones en relacin reciproca, es en verdad muy difcil producir una descripcin
del lenguaje natural y de manera concisa y completa. Por lo tanto, es probable que se
presenten errores, omisiones e inconsistencias en la descripcin informal de un problema.
Mientras que la resolucin de tales errores es siempre un problema de diseo, la falta de
estructura y ambigedad inerte del lenguaje natural dificulta la obtencin de una descripcin
completa del problema. Esto quiere decir que quiz sea necesaria una combinacin de
estrategias para obtener diseos orientados a objetos; aqu el diseador utiliza su experiencia e
intuicin para obtener un diseo a partir de alto nivel del sistema, un modelo funcional
descendente, etc., se ha mencionado que una visin centrada en el objeto de los sistemas de
software debe reemplazar por completo la visin funcional. En opcin de autor, esto sera un
error. Ms bien, la descomposicin funcional descendente y el diseo orientado a objetos se
complementan uno al otro, y cada uno es aplicable en diferentes etapas de diseo del sistema.
o
o
Explique con sus palabras que es el diseo orientado a objetos.

Cuando es probable que se presenten errores.
o
o
Liste 6 lenguajes de programacin orientado a objetos

Qu quiere decir "el sistema se puede presentar como un conjunto de objetos
actuando recprocamente"?
o
o
Pags. 878-894, Anlisis y diseo de sistemas, 3a. edicin, Kendall & Kendall,
ed Pearson educacin, 1997.
Pags. 407-412, Ingeniera de software. un enfoque prctico, 4 edicin, Roger
S. Pressman, ed. Mc Graw Hill, 1997
Autoevaluacin
1. En que se basa el enfoque de diseo orientado a objetos?

2. Cuales son los tipos de datos abstractos?
3. En que se basa el diseo orientado a objeto
DISEO DE LA SALIDA
La salida es la informacin que se entrega a los usuarios por medio del sistema de informacin.
Algunos datos requieren un procesamiento extenso antes de que se conviertan en salida
adecuada, y otros datos son guardados y considerados salida cuando se les recupera con poco
o ningn procesamiento. La salida puede tomar muchas formas, la permanente tradicional de
los reportes impresos y la fugaz, tal como la de las pantallas VDT, microformas y sonido. Los
usuarios dependen de la salida para realizar sus tareas, y frecuentemente juzgan el mrito de
un sistema nicamente por su salida. Para crear la salida ms til posible, los analistas de
sistemas trabajan de cerca con los usuarios, por medio de un proceso interactivo hasta que el
resultado se considera satisfactorio.
Debido a que la salida es til es esencialmente para asegurar el uso y aceptacin del sistema
de informacin, hay varios objetivos que el analista de sistemas trata de obtener cuando disea
la salida.
1.
2.
3.
4.
5.
6.
Disear la salida para que sirva al propsito deseado.

Disear la salida para que se ajuste al usuario.
Entregar la cantidad adecuada de salida.
Asegurarse de que la salida se encuentra donde se necesita.
Entregar la salida a tiempo.
Seleccionar el mtodo de salida adecuado.
Diseo de la salida para que sirva al propsito deseado. Toda la salida debe tener un
propsito. Durante la fase de anlisis de terminacin de los requerimientos de informacin, el
analista de sistemas encuentra cuales propsitos deben ser atendidos. La lista es diseada
luego con base en esos propsitos.
Diseo de la salida para el ajuste al usuario. Con un gran sistema de informacin sirviendo a
muchos usuarios para muchos propsitos diferentes, es difcil personalizar la salida que atienda
lo que muchos usuarios, aunque no todos necesitan y prefieren. Hablando en termino
generales, es ms practico crear una salida especifica para el usuario cuando se le disea para
un sistema de soporte de decisiones u otras aplicaciones altamente interactivas.
Entregar la cantidad adecuada de salida. No siempre ms es mejor, especialmente cuando
se refiere a la cantidad de salida. Parte de la tarea del diseo de la salida es decidir la cantidad
de salida que es correcta para los usuarios. Una regla til es que el sistema debe proporcionar
lo que cada personal necesita para completar su trabajo. Sin embargo, esto est todava muy
lejos de ser una solucin total, debido a que puede ser adecuado desplegar primero un
subconjunto de esa informacin y luego proporcionar formas para que el usuario accese
fcilmente a la informacin adicional.
Asegurarse de que la salida se encuentra donde se necesita. La salida es impresa en
papel, desplegada en pantalla, difundida por bocinas y guardada en microformas. La salida a
veces se produce en un lugar y luego se distribuye a los usuarios. El incremento de salida
desplegada en pantallas en lnea es accesable personalmente ha reducido en cierta forma el
problema de la distribucin, pero la distribucin adecuada todava es un objeto importante para
el analista de sistemas, para ser usada y til, la salida debe ser presentada al usuario
adecuado.
Entrega de la salida a tiempo. Una de las quejas ms comunes de los usuarios es que no
reciben la informacin a tiempo para tomar decisiones necesarias. Los objetivos del analista de
sistemas con respecto a la salida con compuestos. No solo se tiene que ser consciente acerca
de quien esta recibiendo cual salida, sino tambin hay que preocuparse de la distribucin en el
tiempo de la salida para los tomadores de decisiones, mediante esta fase del ciclo de vida del
desarrollo de sistemas ustedes han aprendido que salida es necesaria, y en que momento para
dirigir cada etapa de los procesos de la organizacin.
Seleccin del mtodo de salida adecuado. Tal como se dijo anteriormente, la salida puede
tomar muchas formas, incluyendo reportes impresos en papel, informacin en pantallas VDT
audio con sonidos digitalizados que simulan voz humana y microformas. La seleccin del
mtodo adecuado de salida para cada usuario es otro objetivo de la salida. El analista necesita
reconocer los compromisos involucrados en la seccin de un mtodo de salida. Los costos
difieren, as como la flexibilidad, tiempo de vida, distribucin almacenamiento y posibilidades de
recuperacin, transportabilidad e impacto general sobre los datos para el usuario. La seleccin
de los mtodos de salida no es trivial ni es generalmente una conclusin predecible con
certeza.
RELACIN DEL CONTENIDO DE LA SALIDA CON EL MTODO DE SALIDA.

El contenido de la salida de los sistemas de informacin debe considerarse interrelacionado
con el mtodo de salida. Cada vez que se disea una salida, es necesario pensar sobre cmo
la funcin influencia la forma y cmo el propsito influencia la salida que se escoge. Se debe
pensar en forma general sobre la salida, para que en cualquier informacin que salga del
sistema de computo y que sea til de alguna forma a las gentes, pueda ser considerada la
salida.
SELECCIN DE LA TECNOLOGA DE SALIDA.
El producir diferentes tipos de salida requiere el uso de diferentes tecnologas para la salida de
la computadora impresa. Las opciones incluyen impresoras de impacto o no. Para la salida en
pantalla las opciones incluyen tubos de rayos catdicos conectados o aislados o pantallas de
cristal liquido. La salida de audio puede ser amplificada y emitida por un altavoz o escuchada
por medio de bocinas pequeas en una PC. Las microformas de salida son creadas por
cmaras especialmente equipadas y pelculas en microficha o microfilm.
FACTORES A CONSIDERAR CUANDO SE SELECCIONA A LA TECNOLOGA DE SALIDA.

Quin usara la salida? Descubrir quien usara la salida es importante, debido a que los
requerimientos de trabajo ayudan a indicar cual es el medio de salida es adecuado. Tambin se
aplican diferentes estndares, dependiendo si el receptor de la salida es interno (clientes,
vendedores, accionistas y agencias reglamentadoras) requerirn diferente salida que los
usuarios internos del negocio. Los clientes a veces tienen dificultad para accesar la salida
electrnica, debido simplemente a que ellos no tienen el equipo. En este caso, se les debe
proporcionar salida impresa a desarrollar otra interfaz comn (como el tono de un telfono), y
en cambio la salida en pantalla, en audio o impresa puede ser viable para uso interno. El
conocer quien usara la salida tambin debe ayudarle a determinar los requerimientos de
calidad de la salida.
La salida es cualquier informacin til o datos proporcionados por el sistema de informacin o,
el sistema de apoyo a decisiones ante el usuario. La salida puede tomar virtualmente cualquier
forma, incluyendo la impresin, pantallas, audio, microformas, CD-ROM y electrnica.
El analista de sistemas tiene seis objetivos principales para el diseo de la salida. Estos
disean la salida para que sirva al propsito pretendido y para que se ajuste al usuario,
proporcionar la cantidad adecuada de salida, proporcionarla en el lugar adecuado, proporcionar
la salida a tiempo y seleccionar el mtodo de salida adecuado.
o
o
o
Liste 6 objetivos que pretende el analista al disear la salida del sistema.

D 2 ejemplos que indiquen que la salida en pantallas es la mejor solucin
para la seleccin de tecnologa de salida.
Qu tipo de salioda es mejor si son una necesidad las actualizaciones
frecuentes?
Liste 10 factores que deben ser considerado cuando se escoge la tecnologa

de salida.
o
o
o
Qu tipo de salida es deseable si muchos lectores leern, guardarn y

revisaran la salida a lo largo de varios aos?
Cules son las formas de salida?
Cules son los lineamientos para el diseo de la pantalla?

Autoevaluacin
1. Cual es el diseo de salida?

2. Cmo seleccionar la tecnologa de salida?
3. Cmo debe ser la relacin del contenido de la salida con el mtodo
4.
de salida?
Cules son los factores a considerar cuando se selecciona la
tecnologa de salida?
DISEO DE ENTRADA
La calidad de la entrada de un sistema determina la calidad de la salida del sistema.

Es vital que las formas y pantallas de entrada sena diseadas con esta relacin critica en
mente.
Al asistir en entrada bien diseada, el analista de sistemas est reconociendo que la entrada
pobre plantea preguntas sobre la confiabilidad del sistema completo.
Buen Diseo de Formas

Aunque se pueda disponer de especialistas de formas en casa, el analista de sistemas debe
ser capaz de reconocer las formas til. Tambin es importante que sea capaz de reconocer las
formas mal diseadas, traslapantes o innecesarias que estn desperdiciando recursos de la
organizacin y que, por lo tanto, deben ser eliminadas. Las formas son instrumentos
importantes para dirigir el curso de los trabajos por definicin son los papeles impresos o
duplicados que requieren que la gente llene con repuestas en una forma estandarizada. Las
formas extraen y capturan informacin requerida por los miembros de la organizacin que
frecuentemente alimentaran a la computadora. Por medio de este proceso, las formas sirven
frecuentemente como documentos fuente para el personal de captura de datos.
Cuatro lineamientos para el diseo de formas
Se deben observar cuatro lineamientos del diseo de las formas para disear formas tiles:
1.
2.
3.
4.
Haga que las formas sean fciles de llenar.

Asegrese de que las formas satisfacen el objetivo para el que fueron diseadas.
Disee formas que aseguren el llenado preciso.
Mantenga las formas atractivas.
Hay varios medios para lograr cada lineamiento del diseo de formas.
Flujo de formas. El disear una forma con un flujo adecuado puede minimizar el tiempo y
esfuerzo gastado por los empleados en el llenado de las formas. Y las formas deben fluir de
izquierda a derecha y de arriba hacia abajo.
Secciones de una forma. Otra tcnica que facilita a la gente el llenar las formas correctamente
es el agrupamiento lgico de la informacin. Hay 7 secciones principales de una buena forma
son:
1.
2.
3.
4.
5.
6.
7.
Encabezado.
Identificacin y acceso.
Instrucciones
Cuerpo
Firma y verificacin
Totales
Comentarios.
La seccin de encabezado incluye, por lo general, el nombre y direccin del negocio que enva
la forma.
La seccin de identificacin y acceso incluye cdigo que puede ser usado para archivar el
reporte y obtener acceso a l en una fecha posterior. Esta informacin es muy importante
cuando se requiere de una organizacin conserve el documento por una cantidad de aos
especificada.
La seccin de instruccin dice cmo debe ser llenada la forma y dnde debe ser enviada
cuando est llena.
La parte media de la forma es su cuerpo, que comprende aproximadamente la mitad de la
forma. Esta es la parte de la forma que requiere el mayor detalle y desarrollo de la persona que
la llena. El cuerpo es la parte de la forma que es ms probable que contenga datos variables
explcitos. Por ejemplo en una forma de requisicin de partes esta seccin puede incluir datos
tales como la empresa que pide la parte, el nmero de parte, la cantidad pedida y el precio.
La cuarta parte inferior de la forma est compuesta de tres secciones firma y verificacin,
totales y comentarios. Al solicitar una firma en esta parte de la forma, el diseador esta
limitando el diseo de otros familiares, tales como cartas. Al solicitar totales finales y un
resumen de comentarios es una manera lgica de proporcionar el cierre de la persona que
llena la forma.
Diseo de Formas Atractivas
Aunque el atractivo de las formas es dejado al final, su orden de aparicin no significa que
tenga menos importancia. Las formas estticas llevan a las gentes hacia ellas y motivan su
llenado. Esto significa que las gentes que llenan las formas estarn satisfechas y que las
formas sern llenadas. Las formas no deben verse amontonadas, deben parecer organizadas y
lgicas despus de que son llenadas. Par ser atractivas, las formas deben solicitar la
informacin en el orden esperado, las convenciones indican que se pida el nombre, la calle, la
ciudad, estado y el cdigo postal y el pas, en caso necesario. La disposicin adecuada y el
flujo contribuyen el atractivo de la forma. El uso de diferentes tipos de letra dentro de la misma
forma puede ayudar a hacer atractivo el llenarla. El separar categoras y subcategorias con
lneas gruesas y delgadas tambin puede motivar el inters por la forma.
Diseo de Formas con Ayuda de Computadoras.
Se dispone de numerosos paquetes de diseo de formas para microcomputadoras. Uno de los
mejores paquetes, es llamado FORM LOW de delrina. El FORM LOW ejecuta en el ambiente
Windows y su interfaz GUI es familiar par cualquiera que se use en Windows.
Buen Diseo de Pantalla
Mucho de lo que ya hemos dicho acerca del buen diseo de formas se aplica tambin al diseo
de pantallas. Nuevamente, el usuario debe permanecer presente en los pensamientos del
analista durante el diseo de pantallas de terminales de desplegado visual (VDT). Bien
diseadas deben satisfacer los objetivos de efectividad, precisin, facilidad de uso,
consistencia, simplicidad y atractivo. Todos estos objetivos se logran mediante el uso de
principios bsicos de diseo, conocimiento de lo que es necesario como entrada para el
sistema y una comprensin sobre la manera en que responden los usuarios a los diferentes
elementos de las formas y pantallas.
La efectividad significa que las formas y pantallas de entrada sirven a propsitos especficos
del sistema de manejo de informacin y a su vez, la precisin se refiere al diseo que asegura
el llenado adecuado, la facilidad de uso significa que las formas y pantallas son directas y no
requieren tiempo adicional para decifrarlas. La consistencia significa, en este caso, que las
formas y pantallas agrupan los datos en forma similar de una aplicacin a la siguiente, y a su
vez, simplicidad se refiere a mantener las formas y pantallas intencionalmente sin
amontonamiento en una forma que enfoque la atencin del usuario. El atractivo implica que los
usuarios les agradara o sern atrados a usar la s formas y pantallas debido a su diseo
interesante.
Sin embargo hay diferencias, y el analista de sistemas debe esforzarse para darse cuenta de
las cualidades nicas de las pantallas de desplegado, en vez de adoptar a ciegas las
convenciones de las formas en papel. Una gran diferencia es la presencia constante de una
cursor (un bloque iluminado u otro tipo de apuntador) en pantalla, que orienta al usuario sobre
la posicin actual de entrada de datos. Conforme los dato son dados a la pantalla, el cursor se
mueve un carcter hacia delante indicando el camino.
Lineamientos para el diseo de pantalla

Hay cuatro lineamientos para el diseo de pantalla.
1.
2.
3.
4.
Mantener la pantalla simple.

Mantener consistente la presentacin de la pantalla.
Facilitar al usuario el movimiento entre pantallas.
Crear una pantalla atractiva.
Secciones de una Pantalla

La pantalla cuenta con tres secciones:
La parte superior de la pantalla tiene una seccin de encabezado, parte de la cual est
escrita en el software para describir al usuario en que parte del paquete se encuentra.
El resto del encabezado puede consistir del nombre de archivo creado por el usuario.
La seccin media es llamada el cuerpo de la pantalla. Este puede ser usado para la
captura de datos, y es organizado de izquierda a derecha y de arriba hacia abajo. Los
ttulos e instrucciones deben ser proporcionados en esta seccin parta que ayuden al
usuario a dar los datos adecuados en el lugar correcto. Tambin se deben proporcionar
al usuario las definiciones de campos que muestren que tantos datos se permite en
cada campo de la pantalla.
La tercera seccin de la pantalla es la seccin de comentarios e instrucciones: esta
seccin puede desplegar un men corto de comandos que recuerden al usuario los
puntos bsicos, tales como cambiar pantallas o funciones, guardar el archivo o terminar
la captura. La inclusin de estos puntos bsicos puede hacer que los usuarios sin
experiencia se encuentren mucho mas seguros acerca de su habilidad para operar la
computadora sin causar un error fatal.
o
o
o
o
Cules son los objetivos del diseo para las formas y pantallas del entrada?.
Liste los cuatro lineamientos para el buen diseo de formas.
Cules son las siete secciones de una buena forma?
Liste cuatro tipos de titulos que se usan en formas
o
o
o
Qu es una forma especial?

Cules son las 3 secciones simples para simplificar una pantalla?
Liste 4 elementos de diseo de interfaz grfica. Junto concada uno, decriba
cuando podra ser adecuado incorporar en el diseo de pantalla.

Autoevaluacin
1.
2.
3.
4.
Cual es el diseo de entrada?

Cuales son algunas desventajas del uso de formas especiales?
Cmo debe ser el diseo de formas atractivas?
Cules son las secciones de una pantalla?
DISEO DE BASES DE DATOS
El almacenamiento de datos es considerado por algunos como parte medular de los sistemas
de informacin. Los objetivos generales para el diseo de la organizacin de almacenamiento
de datos se muestran en la siguiente figura.
Primero, los datos tienen que estar disponibles cuando el usuario quiere usarlos. Segundo, los
datos deben ser precisos y consistentes (deben poseer integridad). Aparte de esto, los
objetivos del diseo de base de datos incluyen el almacenamiento eficiente de los datos, as
como su eficiente actualizacin y recuperacin. Por ultimo, es necesario que la recuperacin de
informacin tenga un propsito. La informacin obtenida de los datos almacenados debe estar
en un formato til para la administracin, planeacin, control o toma de decisiones.
ARCHIVOS CONVENCIONALES Y BASES DE DATOS.
Hay dos enfoques para el almacenamiento de datos en un sistema basado en computadora. El
primer mtodo es guardar los datos en archivos individuales, cada uno de ellos nico para una
aplicacin particular.
El segundo enfoque para el almacenamiento de datos en un sistema basado en computadora

involucra la construccin de una base de datos. Una base de datos es un almacn de datos
formalmente definido y centralmente controlado para ser usado en muchas aplicaciones
diferentes.
Los archivos convencionales seguirn siendo una forma practica para guardar datos para
algunas aplicaciones (pero no para todas). Un archivo puede ser diseado y construido muy
rpidamente, y las preocupaciones sobre disponibilidad y seguridad de los datos son
minimizadas. Cuando los diseos de archivo estn cuidadosamente pensados se puede incluir
toda la informacin necesaria, y el riesgo de omitir datos inintencionalmente ser bajo.
La velocidad de procesamiento es otra ventaja del uso de archivos. Es posible escoger la
tcnica optima para el procesamiento de archivos para una sola aplicacin, pero es imposible
obtener un diseo optimo para muchas tareas diferentes. Cuando la eficiencia del
procesamiento es la mayor preocupacin, el mejor enfoque puede ser disear un archivo
individual para ese propsito.
El uso de archivos individuales tiene muchas consecuencias. Frecuentemente los archivos son
diseados solamente con las necesidades inmediatas en mente. Cuando llega a ser importante
consultar el sistema para una combinacin de algunos de los atributos, esos atributos pueden
estar contenidos en archivos separados o puede ser que ni siquiera existan. El rediseo de los
archivos implica frecuentemente que, por consecuencia los programas que accesan los
archivos deben ser vueltos a escribir. Esto se traduce en tiempo de programadores caro para el
desarrollo y mantenimiento de archivos y programas.
Un sistema que usa archivos convencionales implica que los datos guardados sern
redundantes. Lo que es mas, la actualizacin de archivos se lleva mas tiempo. Los archivos
poco usados pueden ser olvidados cuando es momento de actualizacin.
BASES DE DATOS
Las bases de datos no son simplemente un conjunto de archivos. Es una fuente central de
datos que esta pensada para que sea compartida por muchos usuarios con una diversidad de
aplicaciones. La parte medular de la base de datos es el DBMS (sistema de manejo de base de
datos) que permite la creacin, modificacin y actualizacin de la base de datos, la
recuperacin de datos y la generacin de reportes.
Los objetivos de efectividad de la base de datos incluyen:
1. Asegurarse de que la base de datos pueda ser compartida entre los usuarios de una
diversidad de aplicaciones.
2. Mantener datos que sean precisos y consistentes.
3. Asegurarse de que todos los datos requeridos para las aplicaciones actuales y futuras estn
fcilmente disponibles.
4. Permitir que la base de datos evolucione y que las necesidades de los usuarios crezcan.
5. Permitir que los usuarios construyan su vista personal de los datos sin preocuparse de la
forma en que estn fsicamente guardados los datos.
El enfoque de base de datos tiene la ventaja de permitir que los usuarios tengan su propia vista
de los datos. Los usuarios no necesitan preocuparse de la estructura actual de la base de datos
o de su almacenamiento fsico.
La primera desventaja del enfoque de base de datos es que todos los datos estn guardados
en un solo lugar. Los datos son ms vulnerables a catstrofes y requieren respaldos completos.
Otras desventajas aparecen cuando se trata de lograr dos objetivos de eficiencia para la
administracin del recurso de datos:
1. Mantener en una cantidad tolerable el tiempo requerido para insertar,
actualizar, borrar y recuperar datos.
2. Mantener en una cantidad razonable el costo de almacenamiento de
los datos.
Una base de datos no puede ser optimizada para la recuperacin de datos de una aplicacin
especifica, debido a que puede ser compartida por muchos usuarios con diversas, aplicaciones.
Lo que es ms, se requiere software adicional para la DBMS y, ocasionalmente, se requiere
una computadora ms grande.
CONCEPTOS DE DATOS.
La realidad, los datos y los metadatos. La relacin entre la realidad, los datos y los
metadatos se muestra en la siguiente figura:
Entidades. Una entidad puede ser una persona, lugar o cosa. Cualquier entidad tambin
puede ser un evento o unidad de tiempo.
Relaciones. Las relaciones son asociaciones entre entidades (tambin llamadas asociaciones
de datos):
1. Relacin uno a uno (indicada como 1:1).
2. Relacin de uno a muchos (indicada 1:M), por ejemplo un medico tiene
asignados muchos pacientes, pero un paciente tiene asignado un solo medico.
3. Relacin muchos a muchos (indicada M:N) describe la posibilidad de que las
entidades tengan muchas asociaciones en cualquier direccin.
Atributos. Es alguna caracterstica de una entidad. Puede haber muchos atributos para cada
cantidad. Son de hecho las unidades ms pequeas en un archivo o base de datos. Pueden
tener valores, los cuales pueden ser de longitud fija o variable, pueden ser alfabticos,
numricos o alfanumricos.
Registros. Es un conjunto de conceptos de datos que tienen algo en comn con la entidad
descrita. La mayora de los registros son de longitud fija y, por lo tanto, no hay necesidad de
determinar la longitud del registro cada vez.
Llaves. Es uno de los conceptos de atributos de un registro. Cuando una llave identifica en
forma nica a un registro es llamada la llave primaria.
Una llave es llamada llave secundaria si no puede identificar en forma nica a un registro. Las
llaves secundarias pueden usarse para seleccionar un grupo de registros que pertenecen a un
conjunto.
Cuando no es posible identificar unos registros en forma nica mediante el uso de uno de los
conceptos de datos que se encuentran en un registro, se puede construir una clave
seleccionando dos o ms atributos y combinndolos. A esto se le llama una llave concatenada.
Metadatos. Son datos acerca de los datos del archivo o base de datos. Los metadatos
describen el nombre dado y la longitud asignada a cada concepto de datos. Los metadatos
tambin describen la longitud y composicin de cada uno de los registros.
ORGANIZACIN DE ARCHIVOS.
Un archivo contiene grupos de registros usados para proporcionar informacin para operacin,
planeacin administracin y toma de decisiones.
Tipo de archivos. Los archivos pueden ser usados para guardar datos durante un periodo
indefinido de tiempo o pueden ser usados para guardar datos temporalmente para un propsito
especfico. Los archivos maestros y los archivos de tablas son usados para guardar datos
durante un periodo largo. Los archivos temporales son llamados, por lo general, archivos de
transacciones, archivos de trabajo o archivos de reporte.
Archivos maestros. Contienen registros de un grupo de entidades. Los atributos pueden ser
actualizados frecuentemente, pero los registro mismos son relativamente permanentes. Estos
archivos tienden a tener grandes registros que contienen toda la informacin acerca de una
entidad de datos. Cada registro contiene, por lo general, una llave primaria y varias llaves
secundarias. Frecuentemente, los archivos maestros son guardados como archivos indexados
o secuenciales con ndice.
Si el archivo maestro es guardado usando mtodos de archivo convencional, se reserva un
rea de expansin al final de cada registro. Esto proporciona espacio para la adicin de nuevos
campos al registro si es que cambian las necesidades del negocio. Si el archivo es parte de
una estructura de base de datos, no se requiere el rea de expansin.
Archivos de tablas. Un archivo de tabla contiene datos usados para calcular mas datos o
mediadas de desempeo. Los archivos de tablas por lo general son ledos solamente por un
programa.
Archivos de transaccin. Se usa para capturar cambios para actualizar el archivo maestro y
para producir reportes. Los archivos de transaccin son mantenidos, por lo general, a una
longitud mnima. Pueden contener varios tipos de registro diferentes.
Archivos de trabajo. Un programa puede a veces ejecutar mas eficientemente si se usa un
archivo de trabajo. Un ejemplo comn de un archivo de trabajo es aquel que sido reordenado
para que los registros puedan ser accesado mas rpidamente.
Archivos de reporte. Cuando es necesario ejecutar un programa, pero no se dispone de
impresora (o esta ocupada imprimiendo otros trabajos), se usa un archivo de reporte. El enviar
la salida a un archivo en vez de a la impresora es llamado spooling. Posteriormente, cuando el
dispositivo se encuentra listo, se puede imprimir el documento. Los archivos de reporte son
muy tiles, debido a que los usuarios pueden llevar los archivos a otros sistemas de
computadora y hacer la salida en dispositivos especiales, tales como graficadores, impresoras
lser, unidades de microficha y hasta maquinas de composicin tipogrfica computarizadas.
Organizacin secuencial. Cuando los registros estn fsicamente en orden en un archivo se
dice que el archivo es un archivo secuencial. Cuando es actualizado un archivo secuencial es
necesario recorrer todo el archivo. Debido a que los registros no pueden ser insertados en la
parte media del archivo, el archivo secuencial es por lo general, copiado durante el proceso de
actualizacin.
Los archivos maestros secuenciales se usan cuando el hardware lo requiere o cuando el
acceso normal requiere que sean accesados la mayor parte de los registros. La organizacin
secuencial es usada normalmente para todos los tipos de archivos, a excepcin de los archivos
maestros.
Listas encadenadas. Cuando se guardan archivos en dispositivos de acceso directo, tales
como disco o tambor, las opciones se expanden. Los registros pueden ser ordenados en forma
lgica, en vez de fsica, usando listas encadenadas. Las listas encadenadas se logran usando
un juego de apuntadores para dirigirse al siguiente registro lgico que se encuentre ubicado en
cualquier parte del archivo.
Organizacin de archivos de dispersin. La dispersin (hashing) es el proceso de calcular
una direccin a partir de la llave de registro.
Hay muchas tcnicas de dispersin. Una comn es dividir el numero original entre un numero
primo que se aproxime a las posiciones de almacenamiento y luego usar el residuo como la
direccin.
o
o
o
o
o
Liste algunos ejemplos de entidades y sus atributos.

Defina el trmino metadato cul es su propsito?.
Cules son las ventajas de organizar el almacenamiento de datos como
archivos separados?
Cules son las ventajas de organizar el almacenamiento de datos usando un
enfoque de base de datos?
Liste los tipos de archivo usados comunmente en archivos convencionales
cules de stos son archivos temporales?
o
o
o
Qu sucede frecuentemente cuando se usa luna organizacin de archivos

revuelta?
Nombre los tres tipos principales de organizacin de base de datos
Indique las diferencias entre "ordenar" e "indexar".

Autoevaluacin
1.
2.
3.
4.
5.
Cual es el diseo de base de datos?

Qu son las bases de datos?
cules son los tipos de archivos?
En que consiste la organizacin secuencial?
Cules son las listas encadenadas?
DISEO DE LA INTERFAZ HOMBRE-MAQUINA

El proceso general para disear la interfaz de usuario empieza con la creacin de diferentes
modelos de funcin del sistema (tal y como se percibe desde fuera). Se definen las tareas
orientadas al hombre y a la maquina, requeridas para conseguir la funcin del sistema; se
consideran los aspectos de diseo aplicables a todos los diseos del sistema; se consideran
los aspectos del diseo aplicables a todos los diseos de interfaz; se usan herramientas para
crear el prototipo e implementar el modelo de diseo y se evala la calidad del resultado.
Modelos de Diseo de Interfaz

Cuatro modelos diferentes entran en juego cuando hay que disear una interfaz hombremaquina (IHM). El ingeniero de software crea un modelo de diseo, el "ingeniero del software"
establece un modelo de usuario, el usuario final desarrolla una imagen mental que se
denomina a menudo el modelo del usuario o la percepcin del sistema, y los creadores del
sistema crean una imagen del sistema. Desgraciadamente, estos modelos pueden diferir
significativamente. El papel del diseador de interfaces es reconciliar estas diferencias y
obtener una representacin consistente de la interfaz.
Un modelo de diseo del sistema completo incorpora representaciones de datos,
arquitectnicas, de interfaces y procedimentales del software. La especificacin de requisitos
puede establecer ciertas restricciones que ayudan a definir al usuario del sistema, pero el
diseo de interfaz es a menudo secundario en comparacin con el modelo de diseo.
Un modelo de usuario muestra el perfil de los usuarios finales del sistema. Para construir una
interfaz de usuario eficaz, "todo diseo debera empezar con el conocimiento de los usuarios a
los que va dirigido, incluyendo perfiles con el conocimiento de su edad, sexo, capacidades
fsicas, estudios, historial cultural o tnico, motivacin, metas y personalidad". Adems, los
usuarios se pueden categorizar como:
Novatos: sin conocimientos sintcticos del sistema y escaso conocimiento semntico

de la aplicacin o del uso de la computadora en general.
Usuarios espordicos, con conocimientos: conocimiento semntico razonable de la
aplicacin, pero que recuerda vagamente la informacin sintctica necesaria para usar
la interfaz
Usuarios frecuentes, con conocimientos: buenos conocimientos semnticos y
sintcticos que a menudo conduce al "sndrome de usuario potente", es decir,
individuos que buscan accesos directos y modos abreviados de interaccin.
La percepcin del sistema (modelo del usuario) es la imagen del sistema que lleva en la cabeza
el usuario final. Por ejemplo, si el usuario de un procesador de textos particular se le pidiera
describir su operacin, la percepcin del sistema guiara su respuesta. La exactitud de la
descripcin dependera del perfil de usuario y de la familiaridad general con el software en el
dominio de la aplicacin. Un usuario que comprende el funcionamiento de los procesadores de
texto totalmente, pero que slo ha trabajado con este procesador de textos especfico, podra
ser capaz, de proporcionar una descripcin ms completa de su funcin que el novato que ha
estado semanas intentando aprenderse el sistema.
La imagen del sistema combina la manifestacin exterior del sistema basado en computadora
(el aspecto y sensacin de la interfaz), con toda la informacin de soporte (libros, manuales,
cintas de vdeo) que describen la sintaxis y semntica del sistema. Cuando coinciden la imagen
del sistema y la percepcin del sistema, los usuarios se sienten a gusto con el software y lo
utilizan eficazmente. Para conseguir esta "fusin" de modelos, el modelo de diseo debe
desarrollarse para acomodar la informacin sintctica y semntica sobre la interfaz.
Los modelos descritos en esta seccin son "abstracciones de los que esta haciendo el usuario
o de los que piensa que debera estar haciendo cuando usa un sistema interactivo". En
resumen, estos modelos permiten al diseador de interfaz satisfacer el elemento clave del
diseo de interfaz de usuario: " Conocer al usuario, conocer las tareas".
Anlisis y Modelado de Tareas

El anlisis y modelado de tareas puede aplicarse para entender las tareas que realizan
comnmente los usuarios (cuando usan un manual o un enfoque semiautomtico) y despus
orientarlas en un conjunto similar de tareas (pero no necesariamente idnticas) que se
implementan en el contexto de interfaz hombre-maquina. Esto se puede llevar a cabo mediante

la observacin o estudiando una especificacin existente de una solucin basada en
computadora y obteniendo un conjunto de tareas de usuario que implante el modelo del
usuario, el modelo de diseo y la percepcin del sistema.
Independientemente del enfoque general del anlisis de tareas, el ingeniero del software debe
definir y clasificar las tareas. Un enfoque es hacer la elaboracin paso a paso.
El modelo de diseo de la interfaz debera acomodar todas estas tareas de manera que sean
compatibles con el modelo de usuario y con la percepcin del sistema.
Un enfoque alternativo del anlisis de tareas toma un punto de vista orientado a objetos. El
ingeniero del software observa los objetos fsicos que utiliza el diseador de interiores y las
acciones que se aplican a cada objeto. El modelo de diseo de la interfaz no describira los
detalles de la implementacin para cada una de estas acciones, pero definira las tareas del
usuario que consiguen el resultado final.
Una vez que se ha definido cada tarea o accin, empieza el diseo de la interfaz. Los primeros
pasos en el proceso de diseo de la interfaz se puede llevar a cabo usando el siguiente
enfoque:
1. Establecer los objetivos e intenciones de la tarea.
2. Analizar cada objetivo/intencin en una secuencia de acciones
especficas.
3. Especificar la secuencia de la accin tal y como se ejecutar a nivel de
la interfaz.
4. Indicar el estado del sistema; por ejemplo, cmo es la interfaz cuando
se realiza una accin de la secuencia?
5. Definir los mecanismos de control, por ejemplo, los dispositivos y
acciones disponibles para el usuario para alterar el estado del sistema.
6. Mostrar como afectan los mecanismos de control al estado del
sistema.
7. Indicar como interpreta el usuario el estado del sistema por la
informacin que le proporciona a travs de la interfaz.
Aspectos del Diseo
A medida que evoluciona el diseo de la interfaz del usuario, emergen casi siempre cuatro
aspectos comunes del diseo: el tiempo de respuesta del sistema, las facilidades de ayuda al
usuario, la manipulacin de la informacin de errores y el etiquetado de rdenes.
Desgraciadamente, muchos diseadores no tratan estos aspectos hasta relativamente tarde en
el proceso de diseo (a veces la primera indicacin de un problema no aparece hasta que
tenemos disponible un prototipo en funcionamiento). Casi siempre provoca revisiones
innecesarias, retrasos del proyecto y frustracin del cliente. Es mucho mejor establecer cada
una como un aspecto del diseo a considerar al principio del diseo del software, cuando
todava los cambios son fciles de realizar y los costes son bajos.
El tiempo de respuesta del sistema es la queja principal de muchos sistemas interactivos. En
general, el tiempo de respuesta de un sistema se mide desde el momento en que el usuario
realiza alguna accin de control hasta que responde el software con la salida o accin deseada.
El tiempo de respuesta del sistema tiene dos caractersticas importantes. Duracin y
variabilidad. Si la duracin del tiempo de respuesta de un sistema es demasiado largo, el
resultado inevitable es la frustracin y estrs del usuario. Sin embargo, un tiempo de respuesta
demasiado corto puede ser tambin perjudicial si la interfaz le mete prisas al usuario. Una
respuesta rpida puede forzar al usuario a correr y, por tanto, a cometer errores.
La variabilidad se refiere a la desviacin del tiempo medio de respuesta y en muchos aspectos,

es la caracterstica ms importante del tiempo de respuesta. Una variabilidad pequea permite
al usuario establecer un ritmo, incluso si el tiempo de respuesta es relativamente largo. Por
ejemplo, es preferible un segundo de retardo a una orden que un retardo que varia de 0,1 a 2,5
segundos. En este segundo caso, el usuario est siempre desequilibrado, preguntndose
siempre si ha ocurrido algo diferente detrs de bastidores. Casi todos los usuarios de un
sistema interactivo basado en computadora necesitan la ayuda de vez en cuando. En algunos
casos, una pregunta fcil dirigida a un compaero con ms conocimientos basta. En otros, la
nica opcin puede ser hacer una detallada investigacin en un conjunto amplio de manuales
de usuario. En muchos casos, sin embargo, el software moderno proporciona una ayuda en
lnea que permite al usuario responder una pregunta o resolver un problema sin abandonar la
interfaz.
Encontramos dos tipos diferentes de ayudas. La integrada y la agregada. Una ayuda integrada
se disea en el software desde el principio. Es a menudo sensible al contexto, permitiendo al
usuario seleccionarla de los temas relacionados con las acciones que se realizan comnmente:
Obviamente, esto reduce el tiempo necesario para que el usuario obtenga la ayuda y
aumenta la "amigabilidad" de la interfaz. Una ayuda agregada se aade al software
despus de que se haya construido el sistema. En muchos aspectos, es realmente un
manual de usuario en lnea con limitada capacidad de consulta. El usuario puede tener
que buscar en una lista de cientos de temas para encontrar una ayuda apropiada,
haciendo a menudo muchos falsos intentos y recibiendo mucha informacin que no
viene al caso. No hay duda de que es preferible el enfoque de la ayuda integrada al de
la agregada.
Cuando se plantea una ayuda se deben tratar varios aspectos del diseo:
Estar disponible la ayuda para todas las funciones del sistema y en todo momento
durante la interaccin con el sistema? Las opciones incluyen desde slo un conjunto de
todas las funciones y acciones hasta la ayuda para todas las funciones.
Cmo pedir el usuario la ayuda? Las opciones pueden ser un men de ayuda, una
tecla de funcin especial y una orden de AYUDA.
Cmo se representar la ayuda? Las opciones incluyen una ventana diferente, una
referencia a un documento escrito (algo menos que ideal) y una sugerencia de una o
dos lneas en un lugar fijo de la pantalla.
Cmo vuelve el usuario a la interaccin normal? Las opciones incluyen un botn de
vuelta en el monitor y una tecla de funcin o secuencia de control.
Cmo se estructurar la informacin de ayuda? Las opciones van desde una
estructura "plana" en la que toda la informacin es accesible a travs de una palabra
clave a una jerarqua estratificada de informacin que proporciona cada vez ms
detalles a medida que el usuario se mete ms en la estructura y el uso de hipertexto.
Los mensajes de error y advertencias son "malas noticias" enviadas a los usuarios de sistemas
interactivos cuando algo ha ido mal. En el peor de los casos, los mensajes de error o
advertencias ofrecen informacin intil o engaosa y sirven slo para aumentar la frustracin
del usuario. Pocos usuarios de computadoras no han topado alguna vez con un error de tipo:
ERROR GRAVE DEL SISTEMA-14 A
En algn lugar debe existir una explicacin del error 14 A; sino, por qu habran aadido los
diseadores la identificacin? No obstante el mensaje de error no proporciona ninguna
indicacin real de los que est mal o donde buscar para obtener informacin adicional. Un
mensaje de error presentado como arriba no hace nada por aliviar la ansiedad del usuario o
para ayudar a corregir el problema.
En general, todos los mensajes de error o de advertencia producidos por un sistema interactivo
deberan tener las siguientes caractersticas:
El mensaje debera describir el problema en un argot que pueda entender el usuario.

El mensaje debera proporcionar una informacin constructiva para recuperarse del
error.
El mensaje debera indicar cualquier consecuencia negativa del error de manera que el
usuario pueda comprobarlos para asegurarse de que no ha ocurrido (o corregirlos s lo
estn).
El mensaje debera ir acompaado por una seal audible o visible, es decir, se podra
generar un pitido para acompaar a la visualizacin del mensaje, o el mensaje podra
parpadear momentneamente o mostrarse en un color fcilmente reconocible como el
"color de error".
El mensaje no debera hacer juicios. Es decir, el texto nunca debera culpar al usuario.
Como a nadie le gustan realmente las malas noticias, a pocos usuarios les gustar el mensaje
de error, no importa lo bien diseado que est. Pero una filosofa eficaz de mensajes de error
puede ayudar mucho a mejorar la calidad de un sistema interactivo y reducir
significativamente la frustracin del usuario cuando ocurran problemas.
Las ordenes escritas con el teclado fueron durante un tiempo la forma ms comn de
interaccin entre el usuario y el software del sistema, y fue comnmente usado para
aplicaciones de todo tipo. Hoy en da el uso de interfaces orientadas a ventanas, sealizacin y
eleccin han reducido un modo de interaccin orientado a rdenes. En muchas situaciones, se
proporciona al usuario una opcin: las funciones software se pueden seleccionar de un men
esttico o desplegable, o invocado a travs de alguna secuencia de rdenes con el teclado.
Cuando se proporcionan rdenes como modo de interaccin surgen varios aspectos del diseo:
Tendrn todas las opciones del men su correspondiente orden?

Qu formato deben tener las rdenes? Las opciones incluyen una secuencia de
control; teclas de funcin y una palabra escrita.
Ser difcil aprender y recordar las ordenes? Qu se puede hacer si se olvida una
orden?
Puede el usuario personalizar o abreviar las rdenes?
En un numero creciente de aplicaciones, los diseadores de interfaces proporcionan una ayuda

para macros de ordenes que permite al usuario almacenar una secuencia de rdenes usadas
habitualmente bajo un nombre definido por el usuario. En vez de escribir cada orden
individualmente (y repetitivamente), se escribe la macro de rdenes y se ejecutan todas las
ordenes implicadas en secuencia.
Herramientas de Implementacin
El proceso de diseo de la interfaz del usuario es iterativo. Es decir, se crea un modelo de
diseo, se implementa como prototipo, lo examinan los usuarios y se modifica basndose en
sus comentarios.
Para adaptarse a este enfoque de diseo iterativo han evolucionado una amplia gama de
herramientas de diseo de interfaz de creacin de prototipos. Denominadas kits de
herramientas de interfaz de usuario o sistemas de desarrollo de interfaz de usuario, estas
herramientas proporcionan rutinas u objetos que facilitan la creacin de ventanas, mens,
interaccin con dispositivos, mensajes de error, rdenes y muchos otros elementos de un
entorno interactivo.
Al utilizar paquetes de software pueden usar directamente el diseador y el que lo implemente,
o bien por la interfaz de usuario, un desarrollo de interfaz de usuario proporciona mecanismos
integrados para:
Gestionar dispositivos de entrada (tales como ratn o teclado)

Validar las entradas del usuario
Manejar errores y mostrar mensajes de error
Proporcionar respuestas
Proporcionar ayuda y peticiones de informacin
Manejar ventanas y campos, controlando el movimiento del texto dentro de ventanas
Establecer conexiones entre el software de aplicacin y la interfaz
Aislar la aplicacin de las funciones de gestin de la interfaz
Permitir al usuario personalizar la interfaz
Las funciones descritas anteriormente se pueden implementar usando un enfoque grfico o

basado en lenguaje.
Evaluacin del Diseo

Una vez que se ha creado un prototipo de interfaz de usuario que funcione, debe evaluarse
para determinar si satisface las necesidades del usuario. El espectro de la evaluacin puede ir
desde una "ejecucin de prueba" informal en la que el usuario proporcione sus sensaciones
hasta un estudio diseado formalmente que use mtodos estadsticos para la evaluacin de
cuestionarios rellenados por una poblacin de usuarios finales.
Despus de completar el diseo preliminar, se crea un prototipo de primer nivel. El prototipo lo
evala el usuario, quien proporciona el diseador comentarios directos sobre la eficacia de la
interfaz. Adems, si se utilizan tcnicas formales de evaluacin, el diseador puede extraer
informacin til. Las modificaciones del diseo se hacen basndose en la informacin que
aporta el usuario y se crea el prototipo de siguiente nivel. El ciclo de evaluacin continua hasta
que no son necesarias ms modificaciones al diseo de la interfaz. Pero es posible evaluar la
calidad de la interfaz de usuario antes de crear un prototipo? Si se pueden descubrir y corregir
tempranamente los problemas potenciales, el numero de bucles de ciclo de evaluacin se
reducir y se acortara la duracin del desarrollo.
o
o
o
Mensione como se pueden categorizar los usuarios y explique cada uno .

Cules son los pasos en el proceso del diseo de la interfaz. Defina cada uno
de ellos.
Explique brevemente los aspectos del diseo
o
o
o
Explique brevemente en que consiste la evaluacin del diseo.

Cuales son las herramientas de implementacin.
Explique para que se aplican en el anlisis y el modelado de tareas.

Pags. 265-269, Ingeniera de software. un enfoque prctico, 4a. edicin, Roger
S. Pressman, ed Mc Graw Hill, 1997.
Autoevaluacin
1. Qu es el diseo de la interfaz hombre-mquina?

2. Para qu sirven los modelos de diseo de interfaz?
3. Cules son los 4 aspectos comunes del diseo que casa siempre
4.
emergen a medida que evoluciona el diseo de la interfaz del usuario?

Cul es el papel de diseador de interfaces?
ESTRUCTURA CLIENTE/SERVIDOR
Las tecnologas de hardware, de software, de bases de datos y de redes contribuyen todas
ellas a las arquitecturas de computadoras distribuidas y cooperativas. En su forma mas
general, una arquitectura de computadora distribuida y cooperativa se ilustra en la siguiente
figura:
Un sistema raz tpicamente ser una gran computadora, acta como deposito de los datos
corporativos. El sistema raz esta conectado con servidores (tpicamente son estaciones de
trabajo potentes, o PC) y que poseen un doble papel. Los servidores actan para actualizar y
solicitar los datos corporativos mantenidos por el sistema raz. Adems mantienen sistemas
departamentales locales y desempean un papel clave al poner en red los PC de nivel de
usuario a travs de una red de rea local (LAN).
Una estructura cliente/servidor, la computadora que reside de otra computadora se denomina
servidor, y las computadoras de nivel inferior se denominan clientes. Los clientes solicitan
servicios, y el servidor los proporciona. Sin embargo, en el contexto de la arquitectura
representada en la siguiente figura, se pueden llevar a cabo un cierto numero de
implementaciones distintas.
Servidores de archivos. El cliente solicita registros especficos de un archivo. El servidor

transmite estos registros al cliente a travs de la red.
Servidores de base de datos. El cliente enva solicitudes en lenguaje de consulta estructurado
(SQL) al servidor. Estas se transmiten como mensajes a travs de la red. El servidor procesa la
solicitud SQL y halla la informacin solicitada, pasando nicamente los resultados al cliente.
Servidores de transacciones. El cliente enva una solicitud que invoca procedimientos
remotos en el centro servidor. Los procedimientos remotos pueden ser una conjunto de
sentencias SQL. Se produce una transaccin cuando una solicitud da lugar a la ejecucin de
procedimientos remotos y a la transmisin del resultado devuelto al cliente.
Servidores de grupos de trabajo. Cuando el servidor proporciona un conjunto de aplicaciones
que hacen posible la comunicacin entre clientes (y entre las personas que los usan) mediante
el uso de texto, imgenes, boletines electrnicos, vdeo y otras representaciones, existe una
arquitectura de grupos de trabajo.
DISTRIBUCION DE LOS COMPONENTES DE SOFTWARE.

Una vez que se han determinado los requisitos bsicos de una aplicacin cliente/servidor, el
ingeniero del software debe de decidir la forma en que distribuir los componentes de software
entre el cliente y el servidor. Cuando la mayor parte de la funcionalidad asociada a cada uno de
los tres componentes se le asocia al servidor, se ha creado un diseo de servidor principal
(grueso). A la inversa, cuando el cliente implementa la mayor parte de los componentes de
interaccin / presentacin con el usuario, de aplicacin y de bases de datos, se tiene un diseo
de cliente principal (grueso).
Los clientes principales suelen encontrarse cuando se implementan arquitecturas de servidor
de archivo y de servidor de base de datos. En este caso, el servidor proporciona apoyo para la
gestin de datos, pero todo el software de aplicacin y de IGU reside en el cliente. Los
servidores principales son los que suelen disearse cuando se implementan sistemas de
transacciones y de trabajo en grupo. El servidor proporciona el apoyo de la aplicacin
necesario para responder a transacciones y comunicaciones que provengan de los clientes. El
software de cliente se centra en la gestin de IGU y de comunicaciones.
Se pueden utilizar clientes principales y servidores principales para ilustrar el enfoque general
de asignacin de componentes de software de cliente/servidor.
Presentacin distribuida. En este enfoque la lgica de la base de datos y la lgica de la

aplicacin permanecen en el servidor, tpicamente en una computadora central. El servidor
contiene tambin la lgica para preparar informacin de pantalla, empleando un software tal
como CICS. Se utiliza un software especial basado en PC para transformar la informacin de
pantalla basada en caracteres que se transmite desde el servidor en una presentacin IGU en
un PC.
Presentacin remota. La lgica primaria de la base de datos y de la aplicacin permanecen en
el servidor, y los datos enviados por el servidor sern utilizados por el cliente para preparar la
presentacin del usuario.
Lgica distribuida. Se asignan al cliente todas las tareas de presentacin del usuario y
tambin los procesos asociados a la introduccin de datos tales como la validacin de nivel de
campo, la formulacin de consultas de servidor, y las solicitudes de informaciones de
actualizaciones del servidor. Se asignan al servidor las tareas de gestin de las bases de datos,
y los procesos para las consultas del cliente, para actualizaciones de archivos del servidor, para
control de versin de clientes, y para aplicaciones de mbito general de la empresa.
Gestin de datos remota. Las aplicaciones del servidor crean una nueva fuente de datos
dando formato a los datos que se han extrado de alguno otro lugar. Las aplicaciones
asignadas al cliente se utilizan para explotar los nuevos datos a los que se ha dado formato
mediante el servidor.
Bases de datos distribuidas. Los datos de que consta la base de datos se distribuyen entre
mltiples clientes y servidores. Consiguientemente, el cliente debe de admitir componentes de
software de gestin de datos as como componentes de aplicacin y de IGU.
DISEO PARA SISTEMAS C/S
Cuando se esta desarrollando un software para su implementacin empleando una arquitectura
de computadoras concreta, el enfoque de diseo debe de considerar el entorno especifico de
construccin. En esencia, el diseo debera de personalizarse para adecuarlo a la arquitectura
del hardware.
Cuando se disea software para su implementacin empleando una arquitectura
cliente/servidor, el enfoque de diseo debe de ser "personalizado" para adecuarlo a los
problemas siguientes:
El diseo de datos domina el proceso de diseo. Para utilizar efectivamente las

capacidades de un sistema de gestin de bases de datos relacional (SGBDR) o un
sistema de gestin de bases de datos orientado a objetos (SGBDOO) el diseo de los
datos pasa a ser todava ms significativo que en las aplicaciones convencionales.
Cuando se selecciona el paradigma controlado por sucesos, el modelado del
comportamiento (una actividad de anlisis), deber de realizarse y ser preciso traducir
los aspectos orientados al control implcitos en el modelo de comportamiento al modelo
de diseo.
El componente de interaccin/presentacin del usuario de un sistema C/S implementa
todas aquellas funciones que se asocian tpicamente con una interfaz grfica de
usuario (IGU).
Suele seleccionarse un punto de vista orientado a objetos para el diseo. En lugar de la
estructura secuencial que proporciona un lenguaje de procedimientos se proporciona
una estructura de objetos mediante la vinculacin entre los sucesos iniciados en la IGU
y una funcin de gestin de sucesos que reside en el software basado en el cliente.
DISEO DE BASES DE DATOS
El diseo de bases de datos se utiliza para definir y despus especificar la estructura de los
objetos de negocios que se emplean en el sistema cliente/servidor. Es preciso desarrollar toda
una gama de informaciones de diseo durante el diseo de base de datos. Esta informacin,
implementada mediante el uso de una base de datos relacional. Se podr mantener en un
deposito de diseo modelado en la figura que muestra a continuacin:
Se utilizan tablas individuales del lado izquierdo del diagrama para definir la siguiente
informacin de diseo para la base de datos cliente/servidor:
Entidades: se identifican en el diagrama entidad relacin del nuevo sistema.

Archivos: que implementan las entidades en el diagrama entidad relacin.
Relacin entre campo y archivo: establece la disposicin de los archivos al identificar
los campos que estn incluidos en cada archivo.
Campos: define los campos del diseo (el diccionario de datos).
Relaciones entre archivos: identifican los archivos relacionados que se pueden unir
para crear vistas lgicas o consultas.
Validacin de relaciones: identifica el tipo de relaciones entre archivo o entre archivos y
campos que se utilicen para la validacin.
Tipos de campo: se utiliza para permitir la herencia de caractersticas de campos
procedentes de superclases del campo (por ejem.: fecha, texto, numero, valor, precio).
Tipo de datos: las caractersticas de los datos contenidos en el campo.
Tipo de archivo: se utiliza para identificar cualquiera de las ubicaciones del archivo.
Funcin de campo: clave, clave externa, atributo, campo virtual, campo derivado, etc.
Valores permitidos: identifica los valores permitidos para los campos de tipo de estado.
Reglas de negocios: reglas para editar, calcular campos derivados, etc.
En el contexto del diseo de bases de datos, un problema fundamental es la distribucin de

datos. Esto es, cmo se distribuyen los datos entre el cliente y el servidor y cmo se
dispersan entre los nudos de la red?
Un sistema de base de datos relacional (SGBDR) hace fcil el acceso a datos distribuidos
mediante el uso del lenguaje de consulta estructurado (SQL). La ventaja de SQL en una
arquitectura C/S es que "no requiere navegar". La implicacin de esto es que el sistema de
base de datos relacional debe de ser suficientemente sofisticado para mantener la ubicacin de
todos los datos y tiene que ser capaz de definir la mejor ruta hasta ella. En sistemas de bases
de datos menos sofisticados, una solicitud de datos debe de indicar a que hay que acceder y
donde se encuentra. Si el software de aplicacin debe de mantener la informacin de
navegacin, entonces la gestin de datos se vuelve mucho ms complicada por los sistemas
C/S.
Es preciso tener en cuenta que tambien estan disponibles para el diseador otras tecnicas para
la distribucin y gestin de datos:
Extraccin manual. Se permite al usuario copiar manualmente los datos adecuados de un
servidor a un cliente. Este enfoque resulta til cuando el usuario requiere unos datos estticos,
y cuando se puede dejar el control de la estacin en manos del usuario.
Instantnea. Esta tecnica automatiza la extraccin malual al especificar una "instantnea" de
los datos que deberan de transferirse desde un cliente hasta un servidor a intervalos
predefinidos. Este enfoque es til para distribuir unos datos relativemtne estaticos que
solamente requieran actualizaciones infrecuentes.
Duplicacin. Se puede utilizar esta tecnica cuando es preciso mantener multiples copias de los
datos en distintos centros. En este caso, el nivel de complejidad se incomplementa porque la
consistencia de los datos, las actualizaciones, la seguridad, y el procesamiento deben de
coordinarse entre los multiples centros.
Fragmentacin. Este enfoque, la base de datos del sistema se fragmenta entre multiples
mquuienas. Aunque resulta intrigante en teoria, la fragmentacin es excepcionalmente dificil
de implementar, y haste el momento no es frecuente encontrarla.
o
o
o
o
Empleando publicaciones comerciales o recursos de internet de informacin de

fondo, defina un conjunto de criterios pra evaluar herramientas para la
ingeniera de software cliente/servidor.
Investigue los ltimos avances en el software para trabajo en grupo y
desarrolle un resumen breve.
Ofrezca ejemplos de de tres o cuatro mensajes que pudieran dar lugar a una
solicitud de un metodo de cliente mantenido en el servidor
Investigue cuales son los componentes de software para sistemas
cliente/servidor
o
o
o
Sugiera cinco aplicaciones en las cuales un servidor principal parezca una

estrategia de diseo adecuada.
Sugiera cinco aplicaciones en las cuales el cliente principal parezca ser una
estrategia de diseo adecuada
Investigue un lenguaje de consulta estructurado (SQL) y proporcione un breve
ejemplo de la forma en que se podra caracterizar una transaccin empleando
ese lenguaje.

Autoevaluacin
1. En qu consiste el diseo en ambiente de redes?

2. Cmo se debe ser la estructura de los sistemas cliente / servidor?
3. Cules son las cinco configuraciones diferentes para la asignacin de
componentes de software?
4. Cmo debe ser el diseo para sistemas cliente/servidor?

5. Para qu es necesario el diseo de bases de datos en el ambiente de
redes?
DISEO DE TIEMPO REAL

El software de tiempo real esta muy acoplado con el mundo externo, esto es, el software de
tiempo real debe responder al mbito del problema en un tiempo dictado por el mbito del
problema. Debido a que el software de tiempo real debe operar bajo restricciones de
rendimiento muy rigurosas, el diseo del software esta conducido frecuentemente, tanto por la
arquitectura del hardware como por la del software, por las caractersticas del sistema
operativo, por los requisitos de la aplicacin y tanto por los extras del lenguaje de programacin
como prospectos de diseo.
La computadora digital se ha convertido en una maquina omnipresente en al vida diaria de
todos nosotros. Las computadoras nos permiten ver juegos, as como contar el tiempo,
optimizar el gasto de gasolina de nuestras ultimas generaciones de coches y programar a
nuestros aparatos.
Todas estas interacciones con las computadoras sean tiles o intrusivas son ejemplos de
computacin de tiempo real. La computadora esta controlando algo que interactua con la
realidad sobre una base de tiempo de hecho, el tiempo es la esencia de la interaccin.
Consideraciones Sobre los Sistemas

Como cualquier sistema basado en computadora, un sistema de tiempo real debe integrar
hardware, software, hombres y elementos de una base de datos, par conseguir
adecuadamente un conjunto de requisitos funcionales y de rendimiento.
El problema para los sistemas de tiempo real es realzar la asignacin importante como la
funcin, pero las decisiones de asignacin relativas al rendimiento son frecuentemente difciles
de hacer con seguridad.
Puede un algoritmo de procesamiento cumplir varias ligaduras de tiempo o debe construirse
un hardware especial para hacer el trabajo?
Puede un sistema operativo cumplir nuestras necesidades para un manejo eficiente de

interrupciones multitareas y comunicaciones, o especificado, acoplado con el software
propuesto, cumplir los criterios de rendimiento? Estas y otras muchas preguntas deben ser
respondidas por el ingeniero de sistemas de tiempo real.
SISTEMAS DE TIEMPO REAL

Los sistemas de tiempo real generan alguna accin en respuesta a sucesos externos. Para
realizar esta funcin, ejecutan una adquisicin y control de datos a alta velocidad bajo varias
ligaduras de tiempo y fiabilidad. Debido a que estas ligaduras son muy rigurosas, los sistemas
de tiempo real estn frecuentemente dedicados a una nica aplicacin.
Durante muchos aos, los principales consumidores de sistemas de tiempo real eran militares.
Sin embargo, hoy la significativa reduccin del coste del hardware ha hecho posible para la
mayora de las compaas, proporcionar sistemas (y productos) de tiempo real para diversas
aplicaciones, que incluyen control de procesos, automatizacin industrial, investigacin medica
y cientfica, grficos de computadoras, comunicaciones locales y de largo alcance, sistemas
aeroespaciales, prueba asistida por computadora y un vasto abanico de instrumentacin
industrial.
Aspecto de Integracin y Rendimiento

Globalmente, un sistema de tiempo real enfrenta al ingeniero de sistemas con difciles
decisiones sobre el software. Una vez que el elemento software ha sido asignado, se
establecen los requisitos detallados del software y debe desarrollarse un diseo fundamental
de software.
Entre los muchos aspectos relativos al diseo de tiempo real estn: la coordinacin entre las
tareas de tiempo real, el procesamiento de interrupciones del sistema, el manejo de E/S para
asegurar que no se pierden datos, la especificacin de las ligaduras de tiempo externas e
internas del sistema y el asegurar la precisin de su base de datos.
Cada diseo de tiempo real relativo al software debe ser aplicado en el contexto del
rendimiento de sistema. En la mayora de los casos, el rendimiento de un sistema de tiempo
real se mide con una o ms caractersticas relativas al tiempo, pero tambin se utilizan otras
medidas, tales como la tolerancia al fallo. Algunos sistemas de tiempo real se han diseado
para aplicaciones en las que solo el tiempo de repuesta o la trasferencia de datos es critica.
Otras aplicaciones de tiempo real requieren la optimizacin ambos parmetros bajo unas
condiciones de carga extremas. Y lo que es mas, los sistemas de tiempo real deben manejar
sus cargas mximas, mientras se ejecutan varias tareas simultneamente.
Puesto que el rendimiento de un sistema de tiempo real se determina principalmente por el
tiempo de respuesta del sistema y su razn de transferencia de datos, es importante
comprender estos dos parmetros. El tiempo de respuesta del sistema es el tiempo en el que
un sistema debe detectar un suceso interno o externo y responder con una accin.
Frecuentemente, la deteccin del suceso y la generacin de la respuesta son tareas sencillas,
Es el procesamiento de la informacin sobre el suceso para determinar la respuesta adecuada
lo que puede implicar algoritmos complejos que consumen mucho tiempo.
Entre los parmetros clave que afectan al tiempo de respuesta esta el cambio de contextos y la
latencia de la interrupcin. El cambio de contexto se refiere al tiempo y sobrecarga necesitado
para conmutar entre tareas, y la latencia de interrupcin es el tiempo que pasa antes de que el
cambio sea realmente posible. Otros parmetros afectan al tiempo de repuesta son la velocidad
de calculo y el acceso a memorias masivas.
La razn de transferencia de dato sindica con que rapidez se introducen o salen del sistema los
datos series o paralelos, tanto los analgicos como digitales.
Los sistemas de tiempo real necesitan normalmente para procesar un flujo continuo de datos
de llegada. El diseo debe asegurar que no falte ningn dato. Adems, un sistema de tiempo
real debe responder a los sucesos que son asncronos. Por lo tanto, la secuencia de llegada y
el volumen de los datos no pueden predecirse fcilmente de antemano.
Aunque todas las aplicaciones de software deben ser fiables, los sistemas de tiempo real hacen
una especial demanda de fiabilidad, reinicializacin y recuperacin de fallos. Debido a que el
mundo real est siendo monitorizado y controlado, la prdida de monitorizado o control (o
cambios) es intolerable en muchas circunstancias.
Consecuentemente, los sistemas de tiempo real contienen mecanismos de restauracin y
recuperacin de fallos y frecuentemente tienen incorporados redundancias para asegurar la
restauracin.
Sin embargo, la necesidad de fiabilidad ha estimulado un continuo debate sobre los sistemas
interactivos, tales como los sistemas de reserva de billetes y cajeros automticos de los
bancos, tambin son de tiempo real. Por otra parte, tales sistemas interactivos deben
responder a interrupciones externas dentro de tiempos de respuesta prescritos en el orden de
un segundo.
Manejo de Interrupciones
Una caracterstica que sirve para distinguir a los sistemas de tiempo real de cualquier otro tipo
es el manejo de interrupciones. Un sistema real debe responder a un estimulo externo
interrupcin- en un tiempo dictado por el mundo externo. Debido a que frecuentemente, se
presentan mltiples estmulos (interrupciones), deben establecerse prioritarias, en otras
palabras, la tarea ms importante debe ser siempre ser servida de las ligaduras de tiempo
predefinidas, independientemente de otros sucesos.
El manejo de interrupciones supone, no solo almacenar informacin, de forma que la
computadora pueda restablecer correctamente la tarea interrumpida, sino tambin evitar
interbloqueos y bucles sin fin. El enfoque global para el manejo de interrupciones, el flujo
normal de procesamiento es interrumpido por un suceso que es detectado por el hardware del
procesador. Un suceso es cualquier ocurrencia que necesita un servicio inmediato y puede ser
generado por hardware o por software se salva el estado del programa interrumpido, es decir,
se guardan todos los contenidos de los registros, los bloques de control, etc. Y se pasa el
control a una rutina de servicio de interrupcin, que bifurca al software apropiado para el
manejo de la interrupcin.
BASES DE DATOS DE TIEMPO REAL

Como muchos sistemas de procesamiento de datos, los sistemas de tiempo real,
frecuentemente, van junto con una funcin de gestin de base de datos. Sin embargo, puede
parecer que las bases de datos distribuidas constituyen el mtodo preferido en los sistemas de
tiempo real, debido a que multitarea es muy comn y que los datos se procesan
frecuentemente en paralelo. Si la base de datos es distribuida y no centralizada, las tareas
individuales pueden acceder a sus datos de forma rpida, fiable y con menos cuellos de botella.
El uso de una base de datos distribuida par aplicaciones de tiempo real divide el trafico de
entrada/salida y acorta las colas de las tareas en espera, para acceder a una base de datos
raramente causar el fallo del sistema entero si se construyen con redundancia.
Las eficiencias del rendimiento conseguido mediante el uso de una forma de base de datos
distribuida, debe ser sopesada frente a cualquier problema potencial asociado con la particin y
replicacin de los datos. Aunque la redundancia de los datos mejora el tiempo de requisitos de
replicacin para los archivos distribuidos tambin producen problemas logsticos y de
sobrecarga, puesto que todas las copias de los archivos deben ser actualizadas, adems el uso
de base de datos distribuida introduce el problema de control de concurrencia. El control de
concurrencia implica la sincronizacin de las bases de datos de forma que todas las copias
tengan la misma y correcta informacin disponible para los accesos.
El mtodo convencional para el control de concurrencia se basa en lo que se conoce como
bloqueo y estampado de tiempo. En intervalos regulares, se inician las siguientes tareas: las
bases de datos son bloqueadas de forma que se asegure el control de concurrencia, se realiza
la actualizacin requerida.
Sin embargo, se han desarrollado algunas tcnicas para aumentar la velocidad de actualizacin
y resolver el problema de concurrencia. Una de estas, llamada protocolo del escritor exclusivo,
mantiene la consistencia de los archivos replicados, permitiendo que slo una tarea de
escritura actualice un archivo en exclusiva. Por tanto se elimina la gran sobrecarga de los
procesamientos de bloqueo y estampado de tiempo.
SISTEMAS OPERATIVOS DE TIEMPO REAL

Hoy, dos amplias clases de sistemas operativos se utilizan los trabajos de tiempo real. Un
sistema operativo de tiempo real diseado exclusivamente para aplicaciones de tiempo real y
sistemas operativos de propsito general que se han reforzado para suministrar capacidades
de tiempo real. El uso de un ejecutivo de tiempo real hace factible el rendimiento en tiempo real
para un sistema operativo de propsito general comportndose como software de aplicacin, el
ejecutivo ejecuta varias funciones del sistema operativo, particularmente las que afectan al
rendimiento de tiempo real de una forma ms rpida y eficiente que el sistema operativo de
propsito general.
Todos los sistemas operativos deben tener un mecanismo de planificacin de prioridades, pero
un sistema operativo de tiempo real debe dar mecanismo de prioridades que permita que las
interrupciones de prioridad alta tengan precedencia sobre la menos importante. Adems,
debido a que las interrupciones de prioridad ocurren en respuesta a sucesos asncronos no
recurrentes, deben ser servidas sin consumir primero un tiempo de respuesta de carga de un
programa de disco. Consecuentemente para garantizar el tiempo de respuesta requerido, un
sistema operativo de tiempo real debe tener un mecanismo de bloqueo de memoria, esto es,
mantener unos mnimos programas en memoria principal, de forma que se evite la sobrecarga
del almacenamiento en la misma.
Para determinar cuando una aplicacin, puede definirse y evaluarse medidas de la calidad de
sistema operativo de tiempo real.
LENGUAJES DE TIEMPO REAL

Debido a los requisitos especiales de rendimiento y de fiabilidad demandados por los sistemas
de tiempo real, es importante la eleccin del lenguaje de programacin. Puede usarse con
efectividad muchos lenguajes de programacin de propsito general. Sin embargo una clase
llamada lenguajes de tiempo real, se utilizan frecuentemente en aplicaciones especializadas de
comunicaciones y militares.
Varias caractersticas a un lenguaje de tiempo real diferente de un lenguaje de propsito
general. Estas incluyen la capacidad de multitarea, construcciones para implementacin directa
de funciones de tiempo real y caractersticas modernas de programacin que ayuden a

asegurar la correccin del programa.
Es importante que el lenguaje de programacin soporte directamente la multitarea debido a que
los sistemas de tiempo real deben responder a sucesos asncronos que ocurren
simultneamente. Aunque sistemas operativos de tiempo real dan capacidad multitarea,
frecuentemente existe software de tiempo real empotrado sin un sistema operativo. En vez de
ello, las aplicaciones se escriben en un lenguaje que da un soporte de tiempo real suficiente
para la ejecucin del programa de tiempo real. El soporte de tiempo de ejecucin requiere
menos memoria que un sistema operativo y puede ser adaptado a una aplicacin,
incrementando as el rendimiento.
SINCRONIZACIN Y COMUNICACIN DE TAREAS.

Un sistema de multitarea debe suministrar un mecanismo por que el que las tareas se pasen
informacin unas a otras, as como para asegurar su sincronizacin. Para estas funciones, los
sistemas operativos y los lenguajes con soporte de tiempo real, utilizan frecuentemente
semforos de colas, buzones o sistemas de mensajes. Los semforos suministran
sincronizacin y sealizacin pero no contienen informacin. Los mensajes son similares a los
semforos, excepto en aquellos que llevan una informacin sino que la contienen.
Los semforos de colas son primitivos de software que ayudan a gestionar el trafico.
Suministran un mtodo para dividir varias colas. Por ejemplo colas de tareas en espera de
recursos, acceso a bases de datos o dispositivos, as como colas de recursos y dispositivos.
Los semforos coordinan (sincronizan) las tareas en espera con lo que estn esperando, sin
dejar que las tareas o recursos interfieran entre s.
En un sistema de tiempo real, los semforos se utilizan frecuentemente para implementar y
gestionar buzones. Los buzones se almacenan temporalmente en lugares tambin llamados
buffers o almacenas de mensajes para evitar mensajes de un proceso a otro. Un proceso
produce una informacin, la sita en el buzn y luego seala a un proceso consumidor que hay
una informacin en el buzn para que la utilice.
Algunos mtodos para los sistemas operativos de tiempo real o sistemas de soporte de tiempo
de ejecucin ven los buzones como forma ms eficiente de implementar comunicaciones entre
los procesos. Algunos sistemas de tiempo real suministran un lugar para evitar y recibir
referencias a los datos del buzn. Esto elimina la necesidad de transferir todos los datos
ahorrando as tiempo y sobrecarga.
ANLISIS Y SIMULACION DE SISTEMAS DE TIEMPO REAL.

Requisitos funcionales de un sistema de tiempo real:
Manejo de interrupciones y cambio de contexto.

Tiempo de respuesta.
Razn de transferencia de datos y tiempo invertido.
Asignacin de recursos y manejo de prioridades
Sincronizacin de tareas y comunicaciones entre tareas.
Puede especificarse cada uno de estos atributos de rendimiento, pero es extremadamente

difcil verificar si los elementos del sistema consiguen las respuestas deseadas, si los recursos
del sistema consiguen las respuestas deseadas, si los recursos del sistema sern
suficientemente para satisfacer los requisitos computacionales o si los algoritmos de

procesamiento se ejecutaran con la velocidad suficiente.
o
o
o
o
Indique cinco ejemplos de sistemas de tiempo real basados en computadora.

Indique que "estimulos" alimentan al sistema y qu dispositivos o situaciones
controla o supervisa el sistema.
Proporcione tres ejemplos en los que los semaforos sean un mecanismo
apropiados de sincronizacin de tareas.
Obtenga informacin sobre una o ms herramientas de anlisis formales para
sistemas de tiempo real.
Describa las bases de datos en tiempo real
o
o
o
Explique los sistemas operativos en tiempo real

Cules son las carcteristicas de un lenguaje de tiempo real?
Mensione los requisitos funcionales de un sistema de tiempo real

Autoevaluacin
1.
2.
3.
4.
En qu consisite el diseo en tiempo real?

Qu son los sistemas de tiempo real?
Cules son los sistemas operativos en tiempo real?
En qu consiste la siscronizacin y comunicacin de tareas?
COMO PASAR DEL DISEO A LA CODIFICACIN
Eleccin de un lenguaje
Es la decisin ms importante que debe de tomarse al disear un sistema grande de software

la de tomar en consideracin el lenguaje de software que va a utilizar en la aplicacin del
sistema.
Ya que la mayora de las veces el costo se produce en fases de prueba de un sistema y en el
mantenimiento del ciclo de vida, un empleo inapropiado de una notacin puede ocasionar
dificultades posteriores.
Este problema puede desaparecer si solo se dispone de un lenguaje de programacin o si el

cliente demanda alguno en particular.
Una buena eleccin de un lenguaje es importante porque reduce al mnimo las dificultades de
codificar un diseo, reduce la cantidad de pruebas necesarias haciendo el programa ms
legible y ms fcil de mantener.
La aplicacin del sistema debe ser fcil de mantener, por lo tanto esto implica que debe
codificarse en un lenguaje de alto nivel que nos proporcione la posibilidad de construir un
sistema como varios mdulos autnomos cooperativos. Tendr el lenguaje como caracterstica
que debe producir un programa legible.
Entre los criterios que se aplican para la evaluacin de lenguajes disponibles estn:
1. Los requisitos del contratista del sistema. La persona que contrata el sistema puede
especificar que se utilice determinado lenguaje especifico y debemos respetar ese
requisito, y debe el diseador del proyecto o realizador decir cual es el lenguaje que
ser mas apropiado para realizar el sistema.
2. Disponibilidades de compiladores del lenguaje. Si realizaremos una aplicacin por
3.
4.
5.
6.
7.
8.
medio de la configuracin de un sistema operativo o un hardware en particular, debe

disponerse de un traductor del lenguaje de aplicacin de aceptable eficiencia para
aplicar el lenguaje.
Disponibilidad de instrumentos de software para apoyar el desarrollo de los
programas. Instrumentos de software, construcciones de referencia cruzada, sistemas
para control de cdigo, y analizadores de flujo de ejecucin, son importantes en el
apoyo del proceso de programacin. Pues facilitan la aplicacin y confirmacin del
sistema.
Tamao del proceso. Es recomendable disear y disear un lenguaje de
programacin especifico para l.
Conocimiento del personal de programacin existente. Aunque no es una dificultad
para un programador aprender un nuevo lenguaje, necesitan adquirir prctica en algn
lenguaje antes de adquirir una verdadera competencia.
Lenguaje de programacin utilizado en proyecto previos. Esto se utiliza cuando los
programadores han trabajado en un lenguaje anterior, ya se familiarizan con l.
Necesidad de transportar el software. Si esta orientado el software a una sola
configuracin de hardware y tiene un tiempo de vida limitado, los aspectos de su
transporte no son limitados. Si el sistema esta destinado a operar en maquinas
distintas es necesario un lenguaje de programacin capaz de crear programas
porttiles.
La aplicacin que se esta programando. Influye en gran medida respecto al lenguaje
que se utilizara.
Lenguaje de programacin e ingeniera de software

Independientemente del paradigma o ingeniera del software, el lenguaje de programacin
tendr impacto en la planificacin, el anlisis, el diseo, la codificacin, la prueba y el
mantenimiento.
La calidad del resultado final se encuentra mas fuertemente unida a las actividades de
ingeniera de software que preceden y sigue a la codificacin.
La planificacin de herramientas de soporte asociadas con la definicin de recursos puede
requerir que se especifique un compilador en especial (o software asociado) o un entorno de

programacin.
Una vez establecidos los requisitos, las tcnicas de los lenguajes de programacin candidatos,
se hace ms importante.
En estos tenemos que tomar en cuenta si se requiere que el lenguaje soporte complejas
estructuras de datos, si lo ms importante es un alto rendimiento y posibilidades de tiempo real
o para eficiencia en memoria y velocidad, etc.
En algunas ocasiones los requisitos del diseo solo se pueden satisfacer cuando un lenguaje
tiene caractersticas especiales.
Al Igual que ocurre con la prueba, no se comprende totalmente el efecto de las caractersticas
de los lenguajes de programacin sobre el mantenimiento del software.
No hay duda sin embargo de que las caractersticas tcnicas pueden mejorar la legibilidad del
cdigo y reducir la complejidad, lo que es importante para el mantenimiento efectivo del
sistema.
Estilo de codificacin
Una vez generado el cdigo fuente, la funcin de un mdulo debe ser clara sin necesidad de
referirse a ningn diseo, el cdigo debe ser comprensible(debe mezclarse la simplicidad con
la claridad).
Entre los elementos de estilo se encuentran la documentacin interna(a nivel cdigo fuente),
los mtodos de declaracin de datos, enfoque de construccin de sentencias y las tcnicas de
entrada y salida.
o
o
o
Seleccione cualquier lenguaje especializado y prepare resumen de sus

caracteristicas importantes y sus prosibilidades especiales. Escriba un prqueo
programa que ilustre la sntaxis del lenguaje.
Seleccione algn lenguaje orientado a los objetos y prepare un resumen de sus
caractersticas importantes y de sus posibilidades especiales. Escribe un
pequeo programa que ilustre la sintaxis del lenguaje.
Seleccione algn lenguaje de cuarta generacin y prepare un resumen de sus
carcteristicas importantes y de sus posibilidades especiales.
o
Las aplicaciones de sistemas expertos es una de las muchas reas de

aplicacin especializadas. Investigue sobre los lenguajes LISP y PROLOG y
resuma sus potentes posibilidades y debilidades en esa rea de aplicacin en
qu se parecen los lenguajes?en qu se diferencian?
Ada es un gran lenguajes de programiopn con un gran abanico de
posibilidades.En qu se diferencia Ada de los lenguajes de programacin
como PASCAL C?

Pags. 544-559, Ingeniera de software. Un enfoque prctico, 3a. edicin, Roger
Autoevaluacin
1. Qu es un lenguaje de programacin?
2. Cmo debe ser el estilo de codificacin?

3. Cules son los criterios que se aplican para la evaluacin de
lenguajes disponibles?
DOCUMENTACIN DE CODIGO
La documentacin comienza con la eleccin de los nombres de los identificadores(variables y

etiquetas), contina con la localizacin y composicin de los comentarios y termina con la
organizacin visual del programa.
La eleccin de nombres de identificadores significativos es crucial para la legibilidad. Los
lenguajes que limitan la longitud de los nombres de las variables o de las etiquetas a unos
pocos caracteres, implcitamente limitan la comprensin. Considere las siguientes sentencias:
D=V * T
DIST= VELHOR * TIEMPO
DISTANCIA=VELOCIDAD.HORIZONTAL * TIEMPO TRANSCURRIDO EN SEG.
La posibilidad de expresar los comentarios en el lenguaje natural como parte del listado de
cdigo fuente es algo que aparece en todos los lenguajes de programacin de propsito
general. Sin embargo surgen ciertas preguntas:
Cuntos comentarios son "suficientes"?

Dnde se deben situar los comentarios?
Oscurecen los comentarios la lgica del programa?
Pueden los comentarios distraer al lector?
Son los comentarios "no mantenibles", y por lo tanto, no fiables?
Hay pocas respuestas definitivas a las preguntas anteriores. Pero una esta muy clara:
El software debe contener documentacin interna. Los comentarios permiten al programador
comunicarse con otros lectores do cdigo fuente. Los comentarios pueden tambin resultar una
clara gua de comprensin durante la ltima fase de la ingeniera de software el
mantenimiento -.
Existen varios modelos propuestos para la creacin de comentarios.
Los comentarios de prlogo y los comentarios descriptivos son dos categoras que requieren un
enfoque diferente. Al principio de cada mdulo, debe haber un comentario de prlogo. El
formato para estos comentarios es el siguiente:
1. Una sentencia de propsito que indique la funcin del mdulo.
2. Una descripcin de la interfaz que incluya:
a. Un ejemplo de la "secuencia de llamada"
b. Una descripcin de todos los argumentos.
c. Una lista de todos los mdulos subordinados.
1. Una explicacin de los datos pertinentes, tales como las variables importantes y su
uso, de las restricciones y de las limitaciones y de otra informacin importante.
2. Una historia del desarrollo que incluya:
a. El diseador del mdulo(autor).
b. El revisor(auditor) y fecha.
c. Fechas de modificacin y descripcin.
Comentarios descriptivos.
Los comentarios descriptivos se incluyen en el cuerpo del cdigo fuente y se usan para
describir las funciones del procesamiento. "los comentarios deben proporcionar algn extra no
solamente parafrasear el cdigo"
Adems los comentarios descriptivos deben:
Describir los bloques de cdigo en vez de describir cada lnea.

Usar lneas en blanco o tabulaciones de forma que sean fcilmente distinguibles del
cdigo.
Que sean correctos, un comentario incorrecto o que se pueda interpretar mal es peor
que no ponerlo.
Con unos recursos nemotcticos apropiados para los identificadores y unos buenos
comentarios se asegura una documentacin interna adecuada.
Cuando se representa un diseo de procedimientos detallado mediante un lenguaje de diseo
de programas, se puede incluir directamente la documentacin del diseo en el listado fuente
como sentencias de comentario. Esta tcnica es particularmente til cuando la implementacin
se lleva a cabo en lenguaje ensamblador y ayuda a asegurar que, tanto el cdigo como el
diseo, podrn fcilmente mantenerse al hacer cambios sobre ellos.
El sangrado del cdigo fuente realza las construcciones lgicas y los bloques de cdigo,
tabulando desde el margen izquierdo de forma que se vean desplazados estos atributos.
o
o
o
o
Explique cmo deben ser los nombres de los identificadores.

Explique para que sirven los comentarios
En qu parte van los comentarios de prologo
Escriba cual es el formato para los comentarios de prologo.
o
o
o
En que parte van los comentarios descriptivos.

Como deben ser los comentarios descriptivos.
Cul es la mejor forma de hacer el sangrado.

Pags. 560-563 , Ingeniera de software. Un enfoque prctico, 3a. edicin,
Roger S. Pressman, ed Mc Graw Hill, 1993.
Autoevaluacin
1. Cmo debe ser la documentacin del cdigo?

2. Qu es la documentacin interna?
3. Cules son las carcteristicas que deben contener los comentarios
descriptivos?
DECLARACION DE DATOS
La complejidad y la organizacin de las estructuras de datos se definen durante el paso de

diseo. El estilo de la declaracin de datos se establece cuando se genera el cdigo. Se
pueden establecer varios mtodos para hacer ms comprensibles los datos y ms fciles de
mantener.
El orden de las declaraciones de datos, debe estandarizarse aunque un lenguaje de
programacin no tenga requisitos especficos.
Por ejemplo el orden de declaracin en un mdulo en FORTRAN sera la siguiente:
1. Todas las declaraciones explcitas(para mas claridad deben de declararse todas las
variables)
INTEGER, REAL, DOUBLE PRECISION,.......
2. Todos los bloques de datos globales.
COMMON/nombrebloque/....
3. Todos los arrays globales
DIMENSION nombre de arrays y dimensiones.
4. Todas las declaraciones de los archivos.
DEFINE FILE, OPEN, CLOSE.
El orden hace que los atributos sean fciles de descubrir, comprobar, depurar y mantener.
Cuando se declaran mltiples nombres de variables en una sola sentencia, merece la pena
ponerlos en orden alfabtico, al igual las etiquetas.
Si el diseo prescribe una estructura de datos compleja, se deben usar comentarios para
explicar las particularidades inherentes a la implementacin en el lenguaje de programacin.
o
o
o
Qu diferencia el diseo de la codificacin?

En qu momento se establece el estilo de la declaracin de datos?
Cmo debe ser el orden de las declaraciones?
o
o
Explique porqu el orden hace que los atributos sean fciles de descubrir,
comprobar, depurar y mantener.
Cuando se declaran multiples nombres de variables en una sola sentencia que
se recomienda hacer

Pags. 563, Ingeniera de software. Un enfoque prctico, 3a. edicin, Roger S.
Pressman, ed Mc Graw Hill, 1993.
Autoevaluacin
1. Qu es la declaracin de datos?
2. Cmo debe ser la declaracin de datos?
3. Porqu se deben usar comentarios?
CONSTRUCCION DE SENTENCIAS
La construccin de flujo lgico del software se establece durante el diseo. La construccin de

sentencias individuales, sin embargo, es parte del paso de codificacin. La construccin de
sentencias se debe basar en una regla general: cada sentencia debe ser simple y directa; el
cdigo no debe ser retorcido aunque se precise una mayor eficiencia.
Muchos lenguajes de programacin permiten disponer mltiples sentencias en una misma lnea
el ahorro de espacio que esto implica esta difcilmente justificado por la pobre legibilidad del
resultado. Considere los siguientes segmentos de cdigo:
Do I=1 to n-1; T=I; Do J=I+1 to n; If A(j)<A(t) then Do t=j;

End;
If t<>I then Do H= A(t); A(t)=A(I); A(I)=T; End; end;
La estructura de bucles y Las operaciones condicionales del anterior segmento estn

enmascaradas por la construccin de mltiples sentencias por lnea. Reorganizando el formato
el formato del cdigo:
Do I=1 to n-1;
T=I;
Do J=I+1 to n;
If A(j)<A(t) then Do
t=j;
End;
If t<>I then Do
H= A(t);
A(t)=A(I);
A(I)=T;
End;
end;
Aqu, la sencilla construccin de las sentencias y el sangrado dan luz sobre las caractersticas
lgicas y funcionales del segmento. Las sentencias de cdigo fuente individuales se pueden
simplificar al:
Evitar el uso de complicadas comparaciones condicionales.

Eliminar comparaciones con condiciones negativas.
Evitar un gran anidamiento de bucles o condiciones.
Usar parntesis para clasificar las expresiones lgicas o aritmticas.
Usar espacios o smbolos claros para incrementar la legibilidad del contenido de la
sentencia.
Usar solo caractersticas del estndar ANSI.
Pensar "Podra yo entender eso si fuera la persona que lo codifico?
o
o
o
La construccin de sentencias se deben basar en una regla general, diga cual

es y expliquela con sus palabras.
Qu implica poner multiples sentencias en una sola lnea
Cmo se pueden simplificar las sentencias de cdigo
o
o
Explique que quiere decir "usar espacios y/o simbolos claros para implementar
la legibilidad del contenido de la sentencia.
Porqu usar prentesis para clarificar las expresiones lgicas o aritmticas?

Pags. 563 - 564, Ingeniera de software. Un enfoque prctico, 3a. edicin,
Autoevaluacin
1. En que momento se establece la construccin del flujo lgico?
2. Escribe 3 formas de como se puede simplificar las sentencias del

codigo fuente
3. Porqu el cdigo es menos legible si se encuentra escrito todo en

una sola linea?
ENTRADA / SALIDA
El estilo de entrada salida se establece durante el anlisis de requisitos del software y el

diseo. Sin embargo, la forma en que se implementa la E/S puede ser una caracterstica
determinante de la aceptacin del sistema por una comunidad de usuarios. El estilo de entrada
y salida variar con el grado de interaccin humana. Para una E/S orientada a lotes sern
deseables caractersticas tales como una organizacin lgica de entrada, una comprobacin de
errores de entrada/salida significativa, una buena recuperacin de errores de E/S. Para la E/S
interactiva lo principal ser un esquema de entrada simple y dirigido, una extensa
comprobacin y recuperacin de errores, una salida humanizada y una consistencia de
formatos de E/S.
Serie de principios de estilo para la E/S durante el diseo y la codificacin:

Validar los datos de entrada.
Comprobar las importantes combinaciones de elementos de entrada.
Mantener el formato de entrada simple.
Usar el indicativo de fin de dato, en lugar de pedir al usuario especificar el nmero de
elementos.
Etiquetar peticiones interactivas de entrada, especificando los valores posibles o
valores limites.
Mantener el formato de entrada uniforme cuando un lenguaje de programacin tenga
estrictos requisitos de formato.
Etiquetar todas las salidas y disear todos los informes.
El estilo de E/S se ver afectado por muchas otras caractersticas, tales como los dispositivos de
E/S, la sofisticacin del usuario y el entorno de comunicacin.
o
o
o
Cuando se establece la entrada y la salida.

Qu es lo principal para una entrada/salida interactiva?
Escriba la serie de principios de estilo para la entrada/salida durante el diseo
y la cdificacin
o
o
o
Porqu otras carcteristicas se ve afectado el estilo de entrada/salida?

Porqu etiquetar todas las salidas y disear todos los informes?
Porqu validar todos datos de entrada?

Autoevaluacin
1. En qu consiste la entrada/salida?
2. En qu consiste la entrada/salida orientada a lotes?
3. Con que puede variar el estilo de entrada/salida?
REUTILIZACION
El software reutilizable reduce los costes de diseo, codificacin y comprobacin, porque se

amortiza el esfuerzo a lo largo de varios diseos. Al reducirse la cantidad de cdigo se
simplifica tambin la comprensin, lo cual hace que aumente la probabilidad de que el cdigo
sea correcto. La reutilizacin es posible en los lenguajes convencionales, pero los lenguajes
orientados a objetos incrementan mucho la posibilidad de que se reutilice el cdigo.
Clase De Reutilizacion.
Hay dos clases de reutilizacin: Compartir un cdigo recin escrito dentro de un proyecto, y
volver a utilizar un cdigo previamente escrito en proyectos nuevos. Se pueden aplicar unas
lneas generales a las dos clase de reutilizacin. Compartir cdigo dentro de un proyecto es
una cuestin de descubrir secuencias de cdigo redundantes dentro del diseo, y de utilizar las
capacidades del lenguaje de programacin (los procedimientos o mtodos) para compartir su
implementacin. Este tipo de cdigo compartido casi siempre resulta beneficioso de manera
inmediata, produciendo unos programas ms pequeos, mas correcciones ms rpidas y una
iteracin del diseo ms gil.
El planeamiento para una futura reutilizacin requiere mas anticipacin y representa una
inversin. Es probable que una clase aislada se utilice para mltiples proyectos. Los
programadores suelen reutilizar unos subsistemas cuidadosamente pensados, tales como tipos
abstractos de datos, paquetes grficos y bibliotecas de anlisis numrico.
Reglas De Estilo Para La Reutilizacin
Mantener la coherencia de mtodos. Un mtodo es coherente si lleva a cabo una nica

funcin o un grupo de funciones ntimamente relacionadas. Si hace dos o ms cosas que no
este relacionadas, hay que descomponerlo en mtodos ms pequeos.
Mantener pequeos mtodos. Si un mtodo es muy extenso, descompngalo en mtodos
ms pequeos. Un mtodo que vaya mas all de una o dos paginas ser probablemente,
demasiado grande al descomponer los mtodos en piezas ms pequeas, quiz sea posible
reutilizar algunas piezas, aun cuando el mtodo completo no resulte reutilizable.
Mantener la congruencia de los mtodos. Los mtodos similares deberan de tener los
mismos nombres, condiciones, orden de argumentos, tipos de datos, valor proporcionado y
condiciones de error. Hay que mantener la estructura paralela siempre que sea posible.
Separar la poltica de la implementacin. Los mtodos de poltica toman decisiones, bajan
argumentos, y recogen el contexto global. Los mtodos de poltica conmutan el control entre
mtodos de implementacin. Los mtodos de poltica deberan de comprobar el estado y los
errores; no deberan efectuar directamente clculos, ni tampoco deberan de implementar
algoritmos complejos. Los mtodos de poltica suelen ser muy dependientes de la aplicacin,
pero son fciles de escribir y fciles de entender.
Proporcionar una cobertura uniforme. Si las situaciones de entrada se pueden producir en
distintas combinaciones, hay que escribir mtodos para todas las combinaciones, y no solo
para aquellas que sean necesarias tan solo en el presente.
Generalizar el mtodo lo ms posible. Intente generalizar los tipos de argumentos, las
condiciones previas y restricciones, las suposiciones acerca de la forma en que funciona el
mtodo, y el contexto en el que funciona el mtodo. Lleve a cabo acciones significativas
cuando los valores estn vacos, cuando sean valores extremos, y cuando los valore queden
fuera de los limites. Con frecuencia, es posible hacer mas general un mtodo mediante un
ligero incremento de cdigo.
Evitar la informacin global. Minimice las referencias externas. La alusin a un objeto global
impone el contexto requerido a la utilizacin del mtodo. Con frecuencia, la informacin se
puede pasar como argumento. En caso contrario, almacenar la informacin global como parte
del objeto blanco, para que los otros mtodos puedan acceder a ella de manera uniforme.
Evitar los modos. Las funciones que modifican drsticamente su comportamiento
dependiendo del contexto en curso son difciles de reutilizar. Intente sustituirlas por funciones
sin modo.
Recursos De Software Reutilizable

Cada da toma ms importancia la estimacin del software reutilizable como recurso, por
cuanto contribuye al aumento de la productividad en el proceso de la ingeniera de software.
Bennatan sugiere estas categoras de software reutilizable:
Componentes ya desarrollados. Software existente que puede adquirirse o que fue

desarrollado por el equipo antes y que estn totalmente validados.
Componentes ya experimentados. Anlisis, Diseos, Cdigos o Pruebas existentes y
usados en proyectos anteriores pero similares al software en creacin. Las
modificaciones sern de bajo costo.
Componentes con experiencia parcial. Lo mismo a lo anterior, pero con posibles
modificaciones ms sustanciales, que pueden implicar ms riesgo.
Componentes nuevos. Lo que debe crearse especficamente para este proyecto de
software.
El software reutilizable como recurso debe cumplir con lo siguiente:
Si los componentes ya desarrollados cumplen los requisitos, hay que adquirirlos. El

costo de adquisicin y acople de los componentes ya desarrollados es generalmente
menor al de desarrollo de nuevos componentes, adems el riesgo es bajo.
Si se dispone de componentes ya experimentados, los riesgos asociados a la

modificacin y la integracin, son generalmente aceptables.
Si se dispone de componentes de experiencia parcial, su uso debe analizarse en detalle. Su

uso depende del grado de mantenimiento requerido. El costo de modificacin del software
existente suele ser mayor que el costo de un nuevo desarrollo.
o
Uno de los obstaculos principales de la reutilizacin consiste en hacer que los

desarrolladores de software consideren la reutilizacin de componentes ya
existentes, en lugar de volver a inventar otros otros nuevos. (despus de todo,
es divertido construir cosas!) Sugiera tres o cuatro formas distintas en que una
organizacin de software pueda proporcionar incentivos para que los
ingenieros de software utilicen la reutilizacin. Que tcnologias deberan estar
implantandas para apoyar ese esfuerzo de reutilizacin?
Entre los "artefactos de reutilizacin" descritos en el libro ingeniera de
software. un enfoque prctico, 4a. edicion de Roger S. Pressman, se cuenta
los planes de proyectos y las estimaciones de costes. Cmo es posible
reutilizar estos objetos y cuales son los beneficios derivados de hacer esto?
Explique que es la reutilizacin y porque es importante.
o
o
Explique con qu debe cumplir el software reutilizable como recursos

Explique las clases de reutilizacin

o
o
Pags. 372 - 374, Modelado y diseo orientado a objetos, 1a. edicin, James
Rumbaugh, Michael Blaha, William Premerlani, Frederick Eddy, William
Lorensen, ed. Prentice Hall, 1991.
Autoevaluacin
1. Qu es la reutilizacin?
2. Cules son las categorias de software reutilizable?
3. Nombre las cuatro reglas de estilo para la reutilizacin
USO DE BIBLIOTECAS
Las libreras son elementos indispensables en la construccin de programas. Algunos
lenguajes entregan ms facilidades para la utilizacin y creacin de estas libreras.
Por ejemplo en C, se encuentran disponibles gran cantidad de libreras, entre las que se
pueden mencionar stdio.h, conio.h, string, bios.h, memory.h, allec.h,...etc. cada una con
funciones y declaraciones que pueden ser utilizados para algn fin.
Pero tambin es posible que el programador pueda crear sus propias libreras que le ayuden a
resolver un problema particular, pero que posteriormente pueda ser re-utilizada en otro
proyecto posterior.
El uso de libreras es tremendamente til, nos permiten agrupar varias funciones y variables en
un mismo fichero, de manera que luego podemos incluir esta librera en distintas pginas y
disponer de esas funciones fcilmente.
Lo lgico, en cualquier sistema operativo, o cualquier programa, es que las cosas que haya que
realizar muy repetitivamente, se haga desde un solo sitio. Con ello, tendremos tres ventajas:
1. Ahorro de esfuerzos. Si ya esta hecho, se utiliza sino se hace (pensndolo bien) y se
utiliza desde cualquier sitio.
2. Lo haga bien o lo haga mal, al menos est en un solo sitio. Fcil de localizar para su
arreglo si tenemos problemas.
3. Fcil de mantener. Debido al punto 2) si necesitamos cambiar o ampliar su
funcionalidad, est en un solo sitio y solo debemos tocar en ese sitio.
El objetivo que se persigue con la creacin de libreras de funciones, como las DLLs, es poder
aprovechar el mismo cdigo desde diferentes aplicaciones, lo que supone un ahorro evidente
en cada una de esas aplicaciones. Para que crear una funcin nueva para llevar a cabo lo
mismo que me ofrece una funcin ya creada y probada.
Una librera DLL (Librera de Enlace Dinmico[Dynamic Link Library]), es un archivo ejecutable
en donde se encuentran funciones y/o Recursos (Bitmaps, Definiciones de Fuentes,...), que
pueden ser llamados y utilizados por cualquier aplicacin en tiempo de ejecucin. La ventaja de
las DLL frente a las libreras convencionales es que slo se cargan en memoria, cuando se
necesitan los recursos de esa DLL. Hace varios aos esto resultaba muy til, ya que la
memoria era muy limitada. Aunque con el uso de DLL la estabilidad del sistema es menor que
con el uso de libreras estticas.
Las caractersticas de un sistema que utiliza DLLs son:
Las aplicaciones ligan el cdigo de la librera, reduciendo el espacio de

almacenamiento y evitando la duplicacin de cdigo.
Una aplicacin que utiliza DLLs se comporta idnticamente a cualquier otra aplicacin
que utiliza las mismas DLLs.
Si un problema surge, o se quiere aadir una nueva caracterstica, simplemente se
actualizan las DLLs y todas las aplicaciones resultan beneficiadas.
Como se mencion anteriormente una DLL debe ser cargada en el espacio de direcciones de
un proceso y ello se puede hacer de dos maneras: implcitamente y explcitamente.
a. Enlazado Implcito. Cuando se enlaza una aplicacin se debe pasar una lista de
archivos LIB. Los archivos LIB, en la programacin Windows, contienen una lista de las
funciones que las DLL permiten llamar. Cada DLL tiene su correspondiente archivo LIB.
Cuando el enlazador se percata que la aplicacin est llamando a una funcin incluida
en el archivo LIB de una DLL, pone informacin adicional en la imagen del EXE que
indican el nombre de la DLL que se requiere. Luego, cuando el sistema operativo carga
el EXE, recorre esta lista de DLLs necesarias y trata de cargarlas una por una.
Cuando el sistema operativo busca una DLL, recorre los siguientes directorios:
1.
2.
3.
4.
5.
El directorio de contiene la imagen del EXE.

El directorio actual del proceso.
El directorio de sistema de Windows.
El directorio Windows.
Los directorios de la variable PATH.
Si el archivo no se puede encontrar, el sistema muestra un mensaje en la pantalla

indicando el error y termina el proceso. Cuando se utiliza este mtodo las proyecciones
de las DLLs en el espacio de direcciones no se eliminan hasta que termina el proceso.
a. Enlazado Explcito. Es posible proyectar una DLL en el espacio de un proceso en
tiempo de ejecucin llamando a la funcin LoadLibrary o LoadLibraryEx.
Ambas funciones tratan de cargar una DLL en el espacio de direcciones de un proceso.
Ventajas e Inconvenientes del uso de DLLs

El uso de este tipo de archivos ofrece una serie de ventajas que se pueden resumir en:
Una funcin definida dentro de una DLL se encuentra disponible para cualquier
aplicacin Windows.
Reduccin del tamao de las aplicaciones que utilizan la DLL, por la Reutilizacion de su
cdigo. Este hecho comporta dos ventajas aadidas, como son:
Mejora en el tiempo de compilacin y/o carga de la aplicacin (el tamao del cdigo se
ha reducido)
Ahorro de espacio en disco, esa funcin se encuentra una sola vez en el disco,
independientemente del nmero de aplicaciones que la usen.
Las DLLs son independientes de la aplicacin
Sin embargo, no todo son ventajas. Existe tambin, como no, algn inconveniente que
podramos resumir en:
Tienen que estar presentes antes de ser usadas.

Tiempo de Acceso a la DLL por parte de la aplicacin que usa esa DLL.
Para poder acceder a las funciones de esa DLL, existen dos mtodos alternativos, que
denominaremos: Llamada Esttica y Llamada Dinmica a una DLL
Llamada Esttica a DLL
Tambin conocido como Enlace Esttico, es un mtodo que emplea la librera esttica
(archivo .lib) generada durante el proceso de creacin de la DLL.
En este mtodo, durante el proceso de compilacin de la aplicacin se produce el enlace entre
la DLL y la aplicacin que la va a usar. Ms en concreto se produce durante el proceso de
linkado de la aplicacin que va a usar la DLL, cuando se enlazan los mdulos objeto (.obj), los
archivos de libreras en tiempo de ejecucin (.lib) y, en el caso de existir, los archivos de
recursos compilados (.res) para generar un nico archivo ejecutable (.exe) para Windows.
A partir de esto, se puede deducir que la librera queda incluida dentro del archivo ejecutable, lo
que lleva consigo una serie de ventajas, como pueden ser:
Al estar incluida dentro del ejecutable, la librera se carga al inicio de la aplicacin y se
descarga al finalizar la ejecucin de nuestra aplicacin. Esto hace que se cumpla uno de los
requisitos de las DLLs consistente en que siempre deben estar presentes.
La llamada a las funciones contenidas en la DLL se realizar de igual forma como se realizan
las llamadas a cualquier otra funcin implementado en el cdigo de nuestra aplicacin. Esto es
debido a que se encuentran en la misma zona de memoria de la aplicacin y, como se conoce
su posicin exacta, ya que se ha fijado durante la carga del ejecutable. Este aspecto, favorece
muy mucho la implementacin del cdigo necesario para el acceso a las funciones de la DLL.
pero como no todo pueden ser ventajas, tambin aparecer algn inconveniente que se puede
resumir en:
Debido a que la DLL se carga junto como el ejecutable de la aplicacin y se descarga al
finalizar la aplicacin, no hay forma de poder controlar lo que sucede durante los procesos de
carga y descarga de la DLL. As pues, se puede dar el caso que se intente acceder a una DLL
que no se ha podido cargar en memoria por el motivo que sea.
Al estar incluido el archivo .lib dentro del archivo ejecutable (.exe) de la aplicacin, cualquier
cambio que se produjera en la DLL que se est ejecutando supondra tener que recompilar esta
aplicacin, para obtener dentro del archivo ejecutable (.exe) la nueva versin del archivo (.lib).
AL incluir el archivo .lib dentro del ejecutable de nuestra aplicacin, comporta un incremento del
tamao del archivo.exe. Esto conlleva, entre otras cosas, que la DLL est ocupando, durante
toda la ejecucin de la aplicacin, un cierto espacio de memoria. Esto ser as, aun cuando no
se acceda en ningn momento, durante toda la ejecucin de la aplicacin, a las funciones de la
DLL.
Llamada Dinmica a DLL

La Llamada Dinmica a DLL, tambin conocido como Enlace Dinmico, es un mtodo que
emplea la librera dinmica (archivo .dll) generada durante el proceso de creacin de la DLL.
En este mtodo, el enlace entre la DLL y la aplicacin que la va a usar, se producir durante la
ejecucin de la aplicacin. Como se ha visto antes, la Llamada Esttica apostaba por asegurar
la presencia de la DLL en todo momento.
Por su parte, la Llamada Dinmica apuesta por tener un mayor control sobre los procesos de
carga/descarga de la DLL, as como obtener una mayor independencia entre la DLL y la
aplicacin que la va a usar. Entonces, la DLL no ser incluida dentro del ejecutable, sino que
ser cargada cuando sea necesaria y ser descargada en el momento en que ya no sea
necesaria. Esta carga/descarga de la DLL en funcin de su uso, nos permite una mejor gestin
de los recursos, pues no ocupar espacio en memoria, a menso que sea necesario. Adems,
nos proporcionar un alto grado de control sobre el proceso de carga y descarga de la DLL.
Vamos a llevar esto a la prctica. Cuando se desee acceder a las funciones implementadas
dentro de la DLL, deberemos proceder, si es necesario, a cargarla en memoria de la DLL.
o
o
Explique las tres ventajas del uso de bibliotecas

Explique las caracteristicas de un sistema que utiliza DLL's
Liste las ventajas del uso de las DLL's
o
o
o
Explique el enlace esttico a DLL

Explique el enlace dinmico a DLL
Busque en libros o internet mas informacin acerca del tema y haga un
resumen

o
o
o
Pags. http://www.duiops.net/windows/articulos/desde23.htm
http://www.terra.es/personal6/karpoff/archivos/tutor1b.htm
http://www.webestilo.com/php/php05b.phtml
Autoevaluacin
1.
2.
3.
4.
Qu son las libreras y para que sirven?

Cul es el objetivo de la creacin de libreras de funciones?
Qu son las DLL's?
Cules son las desventajas?
EFICIENCIA
Aunque la eficiencia es un fin recomendable, se deben establecer tres mximas antes de pasar
a una discusin ms profunda:
1. La eficiencia es un requisito de rendimiento y como tal, se debe establecer durante el
anlisis de requisitos del software. El software debe ser tan eficiente como se requiera,
no tan eficiente como sea humanamente posible.
2. La eficiencia se incrementa con un buen diseo.
3. La eficiencia del cdigo y la simplicidad del cdigo van de la mano.
En general, no hay que sacrificar la claridad, la legibilidad o la correccin en aras de unas
mejoras en eficiencia que no sean esenciales.
Eficiencia En Cdigo
La eficiencia del cdigo fuente esta directamente unida a la eficiencia de los algoritmos
definidos durante el diseo detallado. Sin embargo el estilo de codificacin puede afectar a la
velocidad de ejecucin y a los requisitos de memoria. El siguiente conjunto de directrices se
debe seguir siempre en el proceso de traduccin del diseo detallado al cdigo:
Simplificar las expresiones aritmticas y lgicas antes de convertirlas en cdigo.

Evaluar cuidadosamente los bucles anidados para determinar si se pueden sacar fuera
de ellos algunas sentencias o expresiones.
Cuando sea posible, evitar el uso de arrays multidimensionales.

Cuando sea posible, evitar el uso de punteros y listas complejas.
Usar "rpidas" operaciones aritmticas.
No mezclar tipos de datos, incluso aunque el lenguaje lo permita.
Usar, cuando sea posible, aritmtica entera y expresiones lgicas.
Muchos compiladores incluyen opciones de optimizacin que generan automticamente cdigo

eficiente al colapsar expresiones repetitivas, evaluar los bucles, usar aritmtica rpida y aplicar
otros algoritmos relacionados con la eficiencia. Para las aplicaciones en las que la eficiencia
sea vital, tales compiladores son una herramienta de codificacin fundamental.
Eficiencia En Memoria
Para la eficiencia en memoria se debe tener en cuenta las posibilidades de "paginacin" del
sistema operativo. La localizacin o el mantenimiento del cdigo en un campo funcional
mediante construcciones estructuradas es un mtodo excelente para reducir la paginacin y,
por tanto, incrementar la eficiencia.
A diferencia de otras caractersticas de los sistemas que se encuentran enfrentadas unas con
otras, las tcnicas para conseguir una eficiencia en tiempo de ejecucin pueden llevar a veces
a una eficiencia en memoria. Por ejemplo al limitar el uso de arrays tri o tetradimensionales, se
obtienen sencillos algoritmos de acceso a los elementos que son ms rpidos y ms cortos. De
nuevo, la clave para la eficiencia en memoria es "mantenerlo simple".
Eficiencia en la entrada/salida
Cuando se habla de eficiencia se han de considerar dos clases de E/S:

E/S dirigida a la persona. La entrada suministrada por un usuario y la salida producida para un
usuario son eficientes cuando la informacin se puede suministrar o se puede comprender con
el mnimo esfuerzo intelectual.
E/S dirigida a otro dispositivo (por ejem. Un disco u otra computadora). La eficiencia de la E/S
dirigida a otro hardware es un punto extremadamente complicado. Desde el punto de vista de
la codificacin (y del diseo detallado), sin embargo, se pueden establecer algunas sencillas
directrices para mejorar la eficiencia en la E/S:
Debe minimizarse el numero de peticiones de E/S

Toda la E/S debe ser tratada con buffer para reducir el embotellamiento en la
comunicacin.
Para las memorias secundarias, se debe seleccionar y usar el mtodo de acceso ms
simple dentro de los aceptables.
La E/S a dispositivos de memoria secundaria debe hacerse por bloques.
La E/S a terminales e impresoras debe tener en cuenta las posibilidades del dispositivo
que puedan afectar a la calidad o a la velocidad.
Recuerde que la "supereficiencia" en la E/S no merece la pena si no le puede
comprender.
El diseo de la E/S establece el estilo y, posteriormente, dicta la eficiencia.
o
o
o
Explique que es la eficiencia.

A que se refiere la eficiencia en memoria.
Cuales son las dos calses de E/S que se deben considerar cuando se habla de
eficiencia. Explique cada una de ellas.
o
o
o
Cules son las directrices apra mejorar la eficiencia en la E/S?

Porqu la entrada/salida a dispositivos de memoria secuandaria debe
hacerse por bloques?
Cul es el conjunto de directrices a seguir en el proceso de traduccin del
diseo detallado al cdigo?

Autoevaluacin
1. Qu es la eficiencia?
2. Qu es la eficiencia en cdigo.
3. Qu abarca la eficiencia?
6.1 DISEO Y EJECUCIN DE PRUEBAS DE SOFTWARE
EL PROCESO DE PRUEBA
Las pruebas se realizan a lo largo del desarrollo del sistema y no simplemente al final. Esto
significa sacar a la luz problemas no conocidos y no demostrar la perfeccin de programas
manuales o equipo.
Aunque el probar es aburrido, es una serie esencial de pasos que ayuda a asegurar la calidad
del sistema eventual. La prueba se realiza en subsistemas o mdulos de programa conforme el
trabajo avanza. La prueba se hace en muchos niveles diferentes y a diversos intervalos. Antes
de que el sistema sea puesto en produccin, todos los programas deben ser probados en el
escritorio, revisados con datos de prueba y revisados para ver si los mdulos los trabajan
juntos entre ellos, tal como se planeo.
Tambin debe ser probado el sistema trabajando con un todo. Esto incluye probar las interfaces
entre subsistemas, la correccin de la salida y la utilidad y comprensibilidad de la
documentacin de la salida del sistema. Los programadores, analistas, operadores y usuarios
juegan papeles diferentes en los diversos aspectos de la prueba, tal como se muestra en la
siguiente figura.
PRUEBA DE PROGRAMAS CON DATOS DE PRUEBA. En esta etapa, los programadores

primero probaran sus programas en escritorio para verificar la forma en que el sistema
trabajar. En la prueba de escritorio el programador sigue cada paso del programa en papel
para revisar si la rutina trabaja como fue escrita.
Luego los programadores deben crear datos de prueba vlidos e invlidos. Luego, estos datos
son ejecutados para ver si trabajan las rutinas bsicas y tambin para atrapar errores. Si la
salida de los mdulos principales es satisfactoria, se pueden aadir mas datos de prueba para
revisar otros mdulos. Los datos de prueba creados deben probar los valores mnimo y mximo
posibles, as como tambin todas las variaciones posibles de formatos y cdigos. Se debe
revisar cuidadosamente se debe revisar cuidadosamente los archivos de salida de los datos de
prueba. Nunca se debe suponer que los datos contenidos en un archivo son correctos
simplemente debido a que el archivo fue creado y accesado.
A lo largo de este proceso el analista de sistemas revisa la salida buscando errores, dando
consejos al programador sobre cualquier correccin necesaria. Por lo general, el analista
recomendara o crear datos de prueba para la prueba de programas, pero puede resaltar al
programador omisiones de tipos de datos que deban ser aadidos en pruebas posteriores.
PRUEBA DE ENLACE CON DATOS DE PRUEBA. Tambin se le conoce como prueba en

cadena. La prueba de enlace revisa para ver si los programas que son interdependientes
trabajan, de hecho, como se planeo.
Una pequea cantidad de datos de prueba, para probar las especificaciones del sistema, as
como los programas, se usan para la prueba de enlace. La prueba de todas las combinaciones
puede llevarse varios pasos a travs del sistema, debido a que es mucho muy difcil describir
los problemas si se trata de probar todo en una sola vez.
El analista crea datos de prueba especiales que cubren una diversidad de situaciones de
procesamiento para la prueba de enlace. Primero, se procesan datos de prueba tpicos para
ver si el sistema puede trabajar las transacciones normales, aquellas que conformarn la mayor
parte de su carga. Si el sistema trabaja con las transacciones normales, luego se aaden
variaciones, incluyendo los datos invlidos usados para asegurarse de que el sistema pueda
detectar errores adecuadamente.
PRUEBA COMPLETA DEL SISTEMA CON DATOS DE PRUEBA. En esta etapa, los
operadores y usuarios finales llegan a estar activamente involucrados en la prueba. Se usan
datos de prueba creado por el equipo de anlisis de sistemas para el propsito especifico de
probar los objetivos del sistema.
Factores a considerar cuando se prueba el sistema con datos de prueba:
1. Examinar si los operadores tienen documentacin adecuada en los manuales de
procedimientos para lograr la operacin correcta y eficiente.
2. Revisar si los manuales de procedimientos son lo suficientemente claros para
comunicar como deben ser preparados los datos para su entrada.
3. Asegurarse si el flujo de trabajo que necesita el sistema nuevo o modificado de hecho
fluye.
4. Determinar si la salida es correcta y si los usuarios comprenden que esta es, en todos
los sentidos, la forma en que la salida se vera en su forma final.
Esta prueba incluye la reafirmacin de los estndares de calidad para el desempeo del
sistema, que fueron puestos cuando se establecieron las especificaciones iniciales del sistema.
Todos los involucrados deben nuevamente estar de acuerdo con la manera de determinar si el
sistema esta haciendo lo que se supone que debe hacer. Esto incluir mediciones de error,
oportunidad, facilidad de uso, ordenamiento adecuado de transacciones, aceptable tiempo
cado, manuales de procedimientos comprensibles, etc.
PRUEBA COMPLETA DEL SISTEMA CON DATOS REALES. Este paso permite una
comparacin precisa de la salida del nuevo sistema con a que s sabe que es salida
correctamente procesada, as como una buena sensacin de cmo sern manejados los datos
reales.
El de prueba es un periodo importante para valorar como interactan, de hecho, los usuarios
finales y operadores del sistema. No es suficiente entrevistar a los usuarios acerca de cmo
estn interactuando con el sistema, sino que se les debe observar de primera mano.
Los conceptos de observar son la facilidad de aprendizaje del sistema, el ajuste a factores
ergonmicos y la reaccin del usuario a la retroalimentacin del sistema, incluyendo lo que
sucede cuando se recibe un mensaje de error y lo que sucede cuando al usuario se le informa
que el sistema esta ejecutando sus comandos. Escuche lo que los usuarios dicen acerca del
sistema con relacin a cmo lo encuentran. Cualquier problema real debe ser resuelto antes de
que el sistema sea puesto en produccin, y no slo superficialmente como ajustes al sistema
que los usuarios y operadores "debieran" hacer por s mismos.
Tambin se necesitan ser probados los manuales de procedimientos. La nica forma real de
probarlos es hacer que lo usuarios y operadores los usen, de ser preferible durante la prueba
completa del sistema con datos reales.
Es difcil comunicar los procedimientos con precisin. Los manuales necesitan estar
organizados en formas diferentes para los usuarios que interactuarn con el sistema en
innumerable maneras. Demasiada informacin, o muy poca, ser obstculo para el uso del
sistema. El uso de hipertexto para manuales en lnea puede ayudar en este aspecto. Considere
e incorpore las sugerencias de usuarios y operadores en la versin final de los manuales y en

otras formas de documentacin.
o
o
o
Podra una prueba exhaustiva (incluso si fuera posible para pequeos

programas? garantizar que un programa es al 100 % correcto?
Pruebe un manual de usuario (o una ayuda) de una aplicacin que utilice
frecuentemente. Encuentre al menos un error en la documentacin.
Cul es la diferencia entre datos de prueba y datos reales?
o
Su equipo de anlisis de sistemas esta a punto de terminar un sistema para

Meecham Feeds. Roger tiene bastante confianza de que los programas que ha
escrito para el sistema de inventario de Meecham ejecutarn como se
necesitan, debido a que son similares a los que ha hecho anteriormente. el
equipo ha estado muy ocupado y quisiera comenzar la prueba de sistemas
completos tan pronto sea posible. Esto es lo que han propuesto dos de los
miembros y jvenes del equipo:
a) Saltarse la prueba de escritorio de los programas (debido a que programas
similares han sido revisados en otras instalaciones, y Roger esta deacuerdo)
b) Hacer la prueba de enlace con gran cantidad de datos para probar que el
sistema trabajar.
c) Hacer pruebas del sistema completo con gran cantidad de datos reales para
mostrar que el sistema es funcional.
Responda a cada uno de estos pasos de su calendarizacon de pruebas de
propuesta. Use un prrafo para explicar la respuesta.Proponga un plan de
prueba. Divida su plan en una secuencia de pasos detallados.
De quin es la responsabilidad primario para la prueba de programas de

computadora.

Pags. 796- 800, Anlisis y diseo de sistemas, Kendall & Kendall, 3 edicin, ed. Pearson
educacin, 1997.
Autoevaluacin
1.
2.
3.
4.
Qu es el diseo de prueba?
En que consiste la prueba de programas con datos de prueba?
En qu consiste la prueba de enlace con datos de prueba?
Cul es la prueba completa del sistema con datos de prueba?
6.2 ENFOQUES DE IMPLEMENTACIN.
El proceso de primero asegurarse de que el sistema de informacin sea operacional, y permitir

que luego tomen los usuarios control de la operacin para su uso y evaluacin es llamado
implementacin. El analista de sistemas tiene varios enfoques para la implementacin, que
deben ser considerados mas cuando se esta preparando el cambio al nuevo sistema. Estos
incluyen darle ms poder de computo a los usuarios va un centro de informacin y/o
procesamiento distribuido, capacitacin de usuarios, conversiones a partir del sistema antiguo y
evaluaciones del nuevo.
El primer enfoque para la implementacin se refiere al movimiento del poder de computo a
usuarios individuales, poniendo un centro de informacin (IC) o dndole poder de computo y
responsabilidad a los grupos a lo largo del negocio con la ayuda de la computacin distribuida.
El segundo enfoque la implementacin es el uso de diferentes estrategias para el
entrenamiento de los usuarios y el personal del centro de informacin, incluyendo el hablarles
en su propio nivel, usando una diversidad de tcnicas de entrenamiento y asegurndose de
que cada usuario comprenda cualquier papel nuevo que deba desempear debido al nuevo
sistema de informacin.
Otro enfoque para la implementacin es la seleccin de una estrategia de conversin. El
analista de sistemas necesita ponderar la situacin y proponer un plan de conversin que sea
adecuado para la organizacin particular del sistema de informacin.
El cuarto enfoque para la implementacin involucra la evaluacin del sistema de informacin
nuevo o modificado o el centro de informacin. El analista necesita formular mediadas de
desempeo con las cuales evaluar al centro de informacin o al sistema. Las evaluaciones
vienen del personal del centro de informacin, usuarios, administracin y los mismos analistas.

Pags. 821, Anlisis y diseo de sistemas, Kendall & Kendall, 3 edicin, ed. Pearson
educacin, 1997.
Autoevaluacin
1. A qu se refiere el tercer enfoque de la implementacin?

2. Qu es la implementacin?
3. Cules son los cuatro enfoques de implementacin?
6.3 CAPACITACIN A USUARIOS.
Los analistas de sistemas se involucran en un proceso educacional con los usuarios que es
llamado capacitacin. A lo largo del ciclo de vida de desarrollo de sistemas los usuarios han
estado involucrados, por lo que ahora el analista debe poseer una valoracin adecuada de los
usuarios que deben ser capacitados. Tal como hemos visto, los centros de informacin
mantienen instructores propios.
En la implementacin de grandes proyectos, el analista estafa frecuentemente analizando la
capacitacin en vez de estar personalmente involucrado en l. Uno de los valores mas
preciados que puede dar el analista a cualquier situacin de capacitacin es la capacidad de
ver el sistema desde el punto de vista del usuario. El analista nunca debe olvidar qu es el
enfrentar un nuevo sistema. Estos recuerdos pueden ayudar a que el analista empatice con os
usuarios y facilite su capacitacin.
ESTRATEGIAS DE CAPACITACIN.
Las estrategias de capacitacin son determinadas por quien esta siendo capacitacin y quien lo
capacitara. El analista querr asegurarse de que cualquiera cuyo trabajo este afectado por el
nuevo sistema de informacin est capacitado adecuadamente por el instructor adecuado.
A quien capacitar. Todas las personas que tendrn uso primario o secundario del sistema
deben ser capacitadas. Esto incluye a todos, desde el personal de captura de datos hasta
aquellos que usaran la salida para tomar decisiones sin usar personalmente una computadora.
La cantidad de capacitacin que requiere un sistema depende, por lo tanto, de qu tanto
cambiara el trabajo de alguien debido al nuevo sistema.
Hay que asegurarse de que estn separados usuarios de diferentes niveles de habilidades e
intereses de trabajo. Es ciertamente problemtico incluir novatos en las mismas sesiones de
capacitacin con los expertos, debido a que los novatos se pierden rpidamente y los expertos
rpidamente se aburren con los puntos bsicos. Ambos grupos quedan perdidos.
Las personas capacitaran a los usuarios. Para un proyecto grande, se pueden usar muchos
instructores diferentes, dependiendo de que tantos usuarios deben ser capacitados y quienes
son. Las fuentes de capacitacin posibles incluyen:
1.
2.
3.
4.
5.
Vendedores.
Analistas de sistemas.
Instructores pagados externamente.
Instructores en casa.
Otros usuarios del sistema.
Esta lista da solamente unas cuantas de las operaciones que tiene el analista para planear y
proporcionar la capacitacin.
Los grandes vendedores frecuentemente proporcionan capacitacin gratuita fuera de sitio y de
uno o dos das en sus instalaciones. Estas sesiones incluyen tanto platicas como capacitacin
practica en un ambiente enfocado.
Debido a que los analistas de sistemas conocen al personal de la organizacin y al sistema,
frecuentemente pueden proporcionar buena capacitacin. El uso de analistas con objeto de
capacitar depende de su disponibilidad, debido a que tambin se espera que supervisen todo el
proceso de implementacin.
Los instructores pagados externamente a veces son llamados a la organizacin para que
ayuden con la capacitacin. Pueden tener amplia experiencia en ensear a la gente como usar
una diversidad de computadoras, pero tal vez no den la capacitacin practica necesario para
algunos usuarios. Adems, tal vez no sean capaces de personalizar sus presentaciones lo
suficiente para hacerlas significativas a los usuarios.
Los instructores de casa de tiempo completo estn, por lo general, familiarizados con el
personal y pueden adecuar los materiales a sus necesidades. Una de las desventajas de los
instructores de casa es que pueden poseer experiencia en otras reas, pero no en sistemas de
informacin, y tal vez les falte, por lo tanto, la profundidad que necesitan lo usuarios.
Tambin es posible hacer que cualquiera de esos instructores capaciten a un pequeo grupo
de personas de cada rea funcional que usara el nuevo sistema de informacin. Ellos a su vez
pueden ser requeridos para que capaciten a los usuarios restantes. Este enfoque puede
trabajar bien si los capacitados originalmente todava tienen acceso a los materiales e
instructores como recursos cuando estn ellos mismos proporcionando la capacitacin. En
caos contrario, puede degenerar en una situacin de prueba y error, en vez de una
estructurada.
LINEAMIENTOS PARA LA CAPACITACIN.
El analista tiene cuatro lineamientos principales para ajustar una capacitacin. Son:
1.
2.
3.
4.
Establecimiento de objetivos mensurables.

Uso de mtodos de capacitacin adecuados.
Seleccin de lugares de capacitacin adecuados.
Empleo de materiales de capacitacin comprensibles.
Objetivos de capacitacin. Quien est siendo entrenado dicta, en gran parte, los objetivos de
la capacitacin. Los objetivos del entrenamiento para cada grupo deben ser indicados
claramente. Los objetivos bien definidos son de una gran ayuda para permitir que los
capacitados sepan lo que se espera de ellos. Adems, los objetivos permiten la evaluacin de
la capacitacin cuando ha terminado. Por ejemplo, los operadores deben saber cosas bsicas,
tales como el encendido de la maquina, que hacer cuando suceden los errores comunes,
bsqueda de fallas bsicas y como terminar una captura.
Mtodos de capacitacin. Cada usuario y operador necesitara una capacitacin ligeramente
diferente. Hasta cierto punto, sus trabajos determinan lo que necesitan saber, y su
personalidad, experiencia y conocimientos de fondo determinan cmo aprender mejor. Algunos
usuarios aprenden mejor viendo, otros oyendo y otros haciendo. Debido a que, por lo general,
no es posible personalizar la capacitacin para un individuo, frecuentemente la mejor manera
de proceder es con una combinacin de los mtodos. De esta forma se llega a la mayora de
los usuarios por medio de un mtodo u otro.
Los mtodos para aquellos que aprenden mejor viendo incluyen demostraciones del equipo y
exposiciones a los manuales de entrenamiento. Aquellos que aprenden mejor oyendo se
beneficiaran de platicas acerca de los procedimientos, discusiones y sesiones de preguntas y
respuestas entre los instructores y capacitados. Aquellos que aprenden mejor haciendo
necesitan experiencia practica con el nuevo equipo. Para trabajos como el del operador de
computadora, la experiencia practica es esencial y, en cambio, tal vez un gerente de
aseguramiento de calidad de una lnea de produccin pueda solamente necesitar ver la salida,
aprender como interpretarla y saber cundo est programado que llegue.
Lugares de capacitacin. La capacitacin se realiza en diferentes ubicaciones, algunas de las

cuales son mas adecuadas para el aprendizaje que otras. Los grandes vendedores de
computadoras proporcionan ubicaciones fuera del local donde se mantiene equipo operable
libre de costos. Sus instructores proporcionan experiencia practica, as como seminarios, en un
ambiente que permite que los usuarios se concentren en el aprendizaje del nuevo sistema. Una
de las desventajas de la capacitacin fuera de sitio es que los usuarios estn alejados del
contexto de la organizacin dentro de la cual deben existir eventualmente.
La capacitacin en sito dentro de la organizacin de los usuarios tambin es posible con varios
tipos diferentes de instructores. La ventaja es que los usuarios ven el equipo puesto en donde
estar cuando sea completamente operacional. Una desventaja seria es que los capacitados a
veces de sienten culpables de no cumplir sus labores de trabajo normales si permanecen en el
sitio para la capacitacin, por lo tanto, puede ser que no sea posible la concentracin completa
en la capacitacin.
La capacitacin fuera de sitio tambin puede estar disponible por una cuota a travs de
consultores y vendedores. Estos pueden estar ubicados en lugares donde hay espacio rentado
para reuniones, tal como un hotel, o incluso pueden ser instalaciones permanentes mantenidas
por los instructores. Estos arreglos permiten que los trabajadores estn libres de las demandas
del trabajo normal, pero tambin puede ser que no proporcionen el equipo para la capacitacin
practica.
Materiales de capacitacin. Al planear la capacitacin de los usuarios, los analistas de
sistemas deben darse cuenta de la importancia de materiales, de capacitacin bien preparados.
Estos incluyen manuales de capacitacin, cosos de capacitacin, en donde a los usuarios les
es asignado trabajo por medio de un caso que incorpora la mayora de las interacciones
comnmente encontradas con el sistema, uy prototipos y esquemas de la salida. La mayora
del software en paquete proporciona tutoriales en lnea para ilustrar las funciones bsicas.
Debido a que la comprensin del sistema pro parte del usuario depende de ellos, los materiales
de capacitacin deben estar escritos con claridad. Esto significa que los materiales de
capacitacin deben tener buenos ndices, estar escritos para la audiencia adecuada con un
mnimo de vocabulario especial y disponible para cualquiera que los necesite. En la figura
21.16 se proporciona un resumen de consideracin para los objetivos, mtodos, lugares y
materiales de capacitacin.
ELEMENTOS
FACTORES RELEVANTES
Dependen de los requerimientos del trabajo del
usuario. Dependen del trabajo del usuario,
Objetivos de la capacitacin.
personalidad conocimientos y experiencias; use
Mtodos de capacitacin.
una combinacin de plticas, demostraciones,
prctica y estudio.
Depende de los objetivos de la capacitacin,
costo, disponibilidad; sitios gratis de vendedor
Sitios de capacitacin
con equipo operable; instalacin en casa;
instalaciones rentadas
Depende de las necesidades del usuario;
Materiales de capacitacin
manuales de operacin, casos, prototipos de
equipo y salida; tutoriales en lnea.
o
Explique con sus palabras que es la implementacin
o
o
o
Explique los cuatro enfoques de implementacin.

Algunos usuarios aprenden mejor viendo, otros oyendo y todava otros
haciendo. D un ejemplo de cmo puede ser incorporado cada tipo de
aprendizaje en una sesin de capacitacin.
Liste los atributos de materiales de capacitacin bien realizados para los
usuarios.
o
o
Liste las fuentes posibles de capacitacin para los usuarios de sistemas de

informacin.
Cramtrack, el sistema de trenes regional/local, est tratando de capacitar a los
usuarios de su sistema de computo recientemente instalado. Para que los
usuarios obtengan la capacitacin adecuada, los analistas de sistemas
involucrados con el proyecto envan un memorndum a las cabezas de los
cuatro departamentos que incluyen usuarios primarios y secundarios. El
memorndum dice en una parte, "solamente las personas que sienten que
requieren capacitacin necesitan hacer reservaciones para capacitarse fuera
de sitio, y todos los dems debern aprender el sistema conforme trabajan con
l en su trabajo. Solamente tres de los cuarenta posibles usuarios se
registraron. Los analistas quedaron satisfechos de que el memorndum
efectivamente separ a la gente que necesita capacitacin de aquella que no.
a) En un prrafo explique como perdieron el rumbo los analistas de

sistema en su enfoque para la capacitacin.
b) Esquematice los pasos que usted seguira para asegurar que las
personas correctas de Cramtrack fueron capacitadas.
Pags. 837-842, Anlisis y diseo de sistemas, Kendall & Kendall, 3 edicin, ed. Pearson
educacin, 1997.
Autoevaluacin
1. Porqu es importante tener objetivos de capacitacin bien definidos?

2. Quin debe ser capacitado para usar el sistema de capacitacin nuevo o
3.
4.
5.
modificado?
Indique una ventaja y una desventaja de las sesiones de capacitacin en sitio.
Cules son los mtodos de capacitacin?
Cules son los lugares de capacitacin?
SEGURIDAD DEL SISTEMA.
La seguridad de las instalaciones de computacin, los datos guardados y la informacin

generada es parte de una conversin satisfactoria.
Es til pensar sobre la seguridad de los sistemas, datos e informacin en un continuo

imaginario, desde totalmente segura hasta totalmente seguro, las acciones que toman los
analistas y los usuarios se pretende que muevan al sistema hacia el lado seguro del continuo,
disminuyendo la vulnerabilidad del sistema. Debe hacerse notar que conforme mas gente de la
organizacin obtenga mayor poder de computo, la seguridad llega a ser cada vez ms difcil y
compleja. A veces las organizaciones contrataran a un consultor de seguridad para que trabaje
con el analista de sistemas cuando la seguridad es crucial para las operaciones exitosas.
La seguridad es responsabilidad de todos aquellos que estn en contacto con el sistema, y es
solo tan buena como el comportamiento o poltica ms laxa en la organizacin. La seguridad
tiene tres aspectos interrelacionados: fsica, lgica y de comportamiento. Los tres deben
trabajar juntos si se pretende que la calidad de la seguridad permanezca alta.
Seguridad fisica. La seguridad fsica se refiere a la seguridad de las instalaciones de

computacin, su equipo y software por medios fsicos. Esto puede incluir el control del acceso
al cueto de la computadora por medio de gafetes legibles por maquina o sistemas de
registro/despedida humanos, el uso de cmaras de televisin de circuito cerrado para
monitorear las reas de computadora y el respaldo de datos frecuente as como el
almacenamiento de los respaldos en un rea a prueba de fuego y de agua.
Adems, el equipo de computo pequeo debe estar asegurado para que un usuario tpico no
pueda moverlo, y se debe garantizar la corriente sin interrupciones. Las alarmas que notifican a
las personas adecuadas la presencia de fuego, inundaciones o intrusin humana no autorizada
deben ser funcionales todo el tiempo.
Las decisiones acerca de la seguridad fsica deben tomarse cuando el analista esta planeando
las instalaciones de computo y la compra de equipo. Obviamente, la seguridad fsica puede ser
mucho ms fuerte si se piensa en ella antes de la instalacin actual cuando son construidos, en
vez de ser acondicionados posteriormente.
Seguridad lgica. La seguridad lgica se refiere a los controles lgicos dentro del mismo
software. Los controles lgicos familiares para la mayora de los usuarios son contraseas y
cdigos de autorizacin de algn tipo. Cuando son usados permiten que el usuario con la
contrasea correcta entre al sistema o a una parte particular de la base de datos.
Sin embargo, las contraseas son tratadas desdeosamente en muchas organizaciones. Se ha
visto que los empleados gritan una contrasea a travs de oficinas con mucha gente, escriben
las contraseas en papeles pegados a sus terminales y comparten contraseas personales con
empleados autorizados que han olvidado la suya.
Los controles lgicos y fsicos son importantes, pero claramente no son suficientes para
proporcionar una seguridad adecuada. Tambin se necesitan cambios de comportamiento.
Seguridad de comportamiento. Las expectativas de comportamiento de una organizacin

estn codificadas en sus manuales de poltica y hasta en signos puestos en tableros de
noticias. Pero el comportamiento que tienen internamente los miembros de la organizacin
tambin es critico para el xito de los esfuerzos de seguridad.
La seguridad puede comenzar por investigar a los empleados que eventualmente tendrn
acceso a las computadoras, datos e informacin, para asegurarse de que sus intereses sean
consistentes con los de la organizacin y que comprenden completamente la importancia de
llevar a cabo procedimientos de seguridad. Las polticas que se refieren a seguridad deben ser
escritas, distribuidas y actualizadas por que los empleados estn totalmente conscientes de las
expectativas y responsabilidades. Por lo general, aqu es donde el analista de sistemas tendr
contacto por primera vez con los aspectos de comportamiento de la seguridad.
Parte de la faceta de comportamiento de seguridad es monitorear el comportamiento a
intervalos irregulares para asegurarse de que se estn siguiendo los procedimientos
adecuados y para corregir cualquier comportamiento que los haya erosionado con el tiempo. El
hacer que el sistema registre la cantidad de intentos de registro no satisfactorios de los
usuarios es una forma de monitorear si usuarios no autorizados estn tratando de registrarse
en el sistema. El inventario peridico y frecuente de equipo y software es deseable. Adems, se
deben examinar sesiones extraamente largas o el acceso despus de horas de trabajo no
tpico al sistema.
La salida generada por el sistema debe ser reconocida por su potencial de poner la
organizacin en riesgo en algunas circunstancias. Los controles de la salida incluyen pantallas
que solo pueden ser accesadas por medio de contraseas, clasificacin de informacin (esto
es, a quien se le puede distribuir y cuando) y almacenamiento seguro de documentos impresos
y almacenados magnticamente.
En algunos casos se debe hacer provisiones para la destruccin de documentos que son
clasificados o propios. Se pueden contratar servicios de destruccin o pulverizacin de una
empresa externa, por una cuota, que destruirn medios magnticos, cartuchos de maquinas de
escribir e impresoras y papel.
o
o
o
o
Defina lo que es seguridad

D tres ejemplos de seguridad fsica.
D tres ejemplos de seguridad lgica.
De tres ejemplo de seguridad de comportamiento.
o
o
De quin es la responsabilidad de la seguridad del sistema?

Por qu la seguridad fsica, lgica y de comportamiento deben trabajar
juntos?

Pags. 844-847, Anlisis y diseo de sistemas, Kendall & Kendall, 3 edicin, ed. Pearson
educacin, 1997.
Autoevaluacin
1. Qu es la seguridad?
2. Qu es la seguridad fsica?
3. Qu es la seguridad lgica?
4. Qu es la seguridad de comportamiento?
BIBLIOGRAFIA
McNamara, Technical Aspects of Data Communication, Digital Press

Pressman, Roger S., Ingeniera del Software. Un enfoque prctico. 3ra. edicin.
McGraw Hill, 1992
Boehm, Barry, et al, Cost Models for Future Software Life Cycle Processes:COCOMO
2.0,
Pages-Jones, Meilir, The Practical Guide to Structured Systems Design, englewood
Cliffs, N.J. Yourdon
Press, 1988
Kendall y Kendall, Anlisis y Diseo de Sistemas, 3ra. edicin, Prentice Hall, 1997
Yourdon, Ed., Anlisis Estructurado Moderno, Prentice Hall, 1991
Colleman, The Fusion Method, Prentice Hall, 1996.
Rumbaugh, James y otros, Modelado y Diseo Orientado a Objetos, Metodologa OMT,
Prentice Hall, 1996.
Graham, lan Mtodos Orientados a Objetos, Addison Wesley, 2da. De 1996.
Booch, Grady, Diseo Orientado a Objetos con Aplicaciones, Adision Wesley, 1996
Sommerville, Ian, Software Engineering, 6th Edicin addison Wesley, 1996.
Ward, p. Y Mellor, S, Structured Development for Real Time Systems, Yourdon Press,
1986.
Capers, Jones, Programming Productivity, McGraw Hill, 1985

Fundamentos de Ingenieria de Software

Încărcat de

Informații document

Drepturi de autor

Formate disponibile

Partajați acest document

Partajați sau inserați document

Opțiuni de partajare

Vi se pare util acest document?

Este necorespunzător acest conținut?

Drepturi de autor:

Formate disponibile

Fundamentos de Ingenieria de Software

Încărcat de

Drepturi de autor:

Formate disponibile

FUNDAMENTOS DE INGENIERIA DE SOFTWARE

5.7 Uso de bibliotecas.

Investigue otras 2 definiciones de ingeniera de software.

Cree su propia definicin de lo que es la ingeniera de software.

Recursos para ampliar el tema

Las fases genricas que caracterizan el proceso de software (definicin, desarrollo y

Maduracin Del Problema Y El Proceso.

Comunicacin con el cliente: tareas requeridas para establecer una comunicacin

Maduracin del problema y proceso:

Descomposicin Del Proceso

Revisar la peticin del cliente.

Ambos proyectos realizan la actividad estructural que denominamos comunicacin con el

Cual de los paradigmas de la ingeniera de software sera ms til para las

Proporcione cinco ejemplos de desarrollo del software que sean adecuados

Recursos para ampliar el tema

Cuales son las carcteriscticas del paradigma ciclo de vida clsico?

Las fases genricas que caracterizan el proceso de software (definicin, desarrollo y

Maduracin Del Problema Y El Proceso.

Comunicacin con el cliente: tareas requeridas para establecer una comunicacin

Maduracin del problema y proceso:

Descomposicin Del Proceso

Revisar la peticin del cliente.

Ambos proyectos realizan la actividad estructural que denominamos comunicacin con el

Cual de los paradigmas de la ingeniera de software sera ms til para las

Proporcione cinco ejemplos de desarrollo del software que sean adecuados

Recursos para ampliar el tema

Cuales son las carcteriscticas del paradigma ciclo de vida clsico?

5. Cul es el pardigma de tcnicas de cuarta generacin?

MTRICAS DEL SOFTWARE.

Documentacin = pags. Doc/ KLDC

Se determinan 5 caractersticas del mbito de la informacin y los clculos aparecen en la

La medida de puntos de funcin se diseo originalmente para ser utilizadas en aplicacin de

d) Documentacin = Pags. doc/KLDC

Mtricas orientadas a la funcin

Se tiene un sistema el cual cuenta con 3 entradas de catalogo productos, proveedores

genra alrededor de 30 archivos adems de estar conectado a un lector ptico y una

Sugiera tres mtricas de calidad y de productividad directas y 3 indirectas para

Recursos para ampliar el tema

1. Qu son las mtricas?

Cules son las mtricas directas?

Recursos para ampliar el tema

2.3 PLANEACIN DEL PROYECTO

La planeacin efectiva de un proyecto de software depende de la planeacin detallada de su

analizara la planeacin que implica a la estimacin de la necesidad de un sistema de software y

ERRORES CLASICOS EN UN PROYECTO INFORMATICO.

Mal anlisis en los requerimientos.

Explique las tcnicas de estimacin para el desarrollo del software.

Explique porque la estimacin debe ajustarse para tomar en cuenta la

Recursos para ampliar el tema

1. Porqu es importante las planeacin del proyecto?

3.1 LA INFORMACIN COMO UN RECURSO DE LAS ORGANIZACIONES.

A primeros de los aos 60, simplemente se automatizaron funciones de negocio que

Definir los objetivos y metas del negocio que sean estratgico.

Cmo es de critica la tecnologa para el logra de un objetivo de negocio?

Despus de la PEI (planificacin de la estrategia de informacin) se hace el anlisis del rea de

Explique porque es importante la informacin.

Explique que realiza la ingeniera de la informacin.

Recursos para ampliar el tema

2. Cul es factor critico para la determinacin del xito o fracaso de los

3.2 EL PAPEL DEL ANALISTA DE SISTEMAS

1. Consultores externos para negocios.

Los paquetes de software basados en microcomputadora automatizado para el anlisis y

El incremento de la productividad del analista

Iniciacin del proyecto