FUNDAMENTOS DE SISTEMAS DE TRANSMISIÓN: TECNOLOGÍAS Y APLICACIONES
Cátedra: Fundamentos de TIC’s · Fundamentos de TIC’s (Tecnologías de la ... avance de la...
Transcript of Cátedra: Fundamentos de TIC’s · Fundamentos de TIC’s (Tecnologías de la ... avance de la...
Giulianelli, Juan Ignacio Giulianelli, Daniel A
Doctorado en Ciencias Economías Universidad Nacional de la Matanza
Departamento: Ingeniería e Investigaciones Tecnológicas Cátedra:
Fundamentos de TIC’s (Tecnologías de la Información y la Comunicación)
e-mail: [email protected]
JEFE DE CÁTEDRA:
Dr. Daniel A. Giulianelli
COORDINADORA DE CÁTEDRA:
Mg. Artemisa Trigueros
UNIDAD NRO. 1 CONCEPTOS GENERALES E
INTRODUCCIÓN A LOS SISTEMAS DE INFORMACIÓN
COLABORACIÓN:
DOCENTES DE LA CÁTEDRA
CICLO LECTIVO:
2014
Universidad Nacional de la Matanza
Universidad Nacional de La Matanza Departamento: Ingeniería e Investigaciones Tecnológicas
Cátedra: Fundamentos de TIC’s
Introducción a Sistemas de Información Página 2 de 71
UNIDAD 1
INDICE
Parte A: INTRODUCCIÓN Y CONCEPTOS GENERALES ............................................................. 4
A.1. Introducción .............................................................................................................................. 4
A.1.1. La técnica y la tecnología .................................................................................................. 4
A.1.2. La información .................................................................................................................. 4
A.1.3. La comunicación ............................................................................................................... 5
A.2. Tecnologías de la información y la comunicación ................................................................... 5
A.3. La Informática .......................................................................................................................... 5
A.4. Los datos ................................................................................................................................... 6
A.4.1. La diferencia entre datos e información ............................................................................ 6
A.4.2. El procesamiento de datos ................................................................................................. 6
A.5. La computadora ........................................................................................................................ 6
A.5.1. Definición .......................................................................................................................... 6
A.5.2. La computación ................................................................................................................. 7
A.6. Las magnitudes y su clasificación ............................................................................................ 7
A.6.1. Magnitud, medición y error ............................................................................................... 7
1.1.1 Magnitud, medición y error .............................................................................................. 7
A.6.2. Magnitudes físicas y abstractas ......................................................................................... 8
A.7. Conversión analógica – digital ................................................................................................. 9
A.7.1. Necesidad de la conversión ............................................................................................... 9
A.7.2. Procedimiento para la conversión analógica – digital ..................................................... 10
A.7.3. Los sensores .................................................................................................................... 11
PARTE B: INTRODUCCIÓN A SISTEMAS DE INFORMACIÓN ............................................... 12
B.1. Introducción a Sistemas .......................................................................................................... 12
B.1.1. Modelo General de un Sistema ........................................................................................ 14
B.1.2. Subsistemas ..................................................................................................................... 16
B.1.3. Caja Negra ....................................................................................................................... 17
B.1.4. Clases de Sistemas ........................................................................................................... 17
B.2. Componentes de un Sistema Informático ............................................................................... 19
B.2.1. Modelo de Control Básico ............................................................................................... 20
B.2.2. Desempeño y Estándares de Sistemas ............................................................................. 20
B.2.3. Variables y Parámetros de Sistema.................................................................................. 22
B.2.4. Descomposición ............................................................................................................... 22
B.3. Simplificación ........................................................................................................................ 24
B.3.1. Agrupamiento de Subsistemas ......................................................................................... 24
B.3.2. Desacoplamiento ............................................................................................................. 26
B.4. Tensión de Sistemas y Cambio de Sistemas ........................................................................... 28
B.4.1. Clases de Tensiones (Stress) ............................................................................................ 28
B.4.2. Proceso de Adaptación .................................................................................................... 29
B.5. Características del Software ................................................................................................... 30
B.5.1. Proceso Software y Producto Software ........................................................................... 30
B.5.3. Participantes en el Desarrollo de Sistemas ...................................................................... 31
B.5.4. Inicio del Desarrollo de Sistemas .................................................................................... 32
B.6. Ingeniería del Software ........................................................................................................... 32
B.7. Ciclos de Vida y Desarrollo de Sistemas de Información ...................................................... 33
B.8. Etapas del Proceso de Desarrollo (Ciclo de Vida) ................................................................. 33
B.8.1. Investigación .................................................................................................................... 36
B.8.2. Análisis ............................................................................................................................ 37
Universidad Nacional de La Matanza Departamento: Ingeniería e Investigaciones Tecnológicas
Cátedra: Fundamentos de TIC’s
Introducción a Sistemas de Información Página 3 de 71
B.8.2.1. Técnicas para la Obtención de Requerimientos........................................................ 38
B.8.3. Diseño .............................................................................................................................. 40
B.8.3.1. Paradigma ................................................................................................................. 41
B.8.3.2. Modelar por Medio de Diagramas ........................................................................... 42
B.8.3.3. Paradigma Estructurado ............................................................................................ 42
B.8.3.4 Diagrama de Contexto / Diagrama de Flujo de Datos (DFD) ................................... 42
B.8.3.5. Herramientas Adicionales ......................................................................................... 43
B.8.3.6. Diagrama de Entidad-Relacion (DER) .................................................................... 44
B.8.3.7. Diagrama de Transición de Estados (DTE) .............................................................. 45
B.8.3.9. Construcción de Prototipos ....................................................................................... 46
B.8.3.10. Paradigma Orientado a Objetos (POO) .................................................................. 47
B.8.4. Desarrollo ........................................................................................................................ 55
B.8.5. Pruebas (Testing). ............................................................................................................ 55
B.8.6. Mantenimiento y Revisión ............................................................................................... 55
B.9. Documentación ....................................................................................................................... 56
B.10. Modelos del Proceso de Desarrollo del Software ................................................................ 56
B.10.1. Modelo Lineal o Modelo en Cascada ............................................................................ 57
B.10.2. Iterativo o Incremental ................................................................................................... 58
B.10.3. Espiral ............................................................................................................................ 59
B.10. 4. Ágil ............................................................................................................................... 60
B.11. Las Organizaciones como Sistemas...................................................................................... 61
B.11.1. Organizaciones .............................................................................................................. 61
B.11.3. Empresas ........................................................................................................................ 62
B.11.4. Estructura Organizativa ................................................................................................. 62
B.11.5. Organigrama .................................................................................................................. 63
B.11.6. Principios Básicos de las Organizaciones...................................................................... 63
ANEXO: Las TICs y su aplicación a Ingeniería Industrial y Civil .................................................... 65
Ingeniería Industrial ....................................................................................................................... 65
Ingeniería Civil ............................................................................................................................... 68
BIBLIOGRAFIA ............................................................................................................................ 71
Universidad Nacional de La Matanza Departamento: Ingeniería e Investigaciones Tecnológicas
Cátedra: Fundamentos de TIC’s
Introducción a Sistemas de Información Página 4 de 71
Parte A: INTRODUCCIÓN Y CONCEPTOS GENERALES Autores del capítulo: Ing. Alfredo V. Amato, Ing. Mabel Compagnoni, Mg. Artemisa Trigueros
A.1. Introducción
Las Tecnologías de la Información y la Comunicación representan un
cambio notable en la sociedad y desempeñan una función vital en el
avance de la ingeniería, de las ciencias y de los procesos industriales.
Su alcance se extiende a la educación, están presentes en las relaciones
interpersonales, en el modo de gene-
rar y difundir conocimientos, en las
actividades económicas, comerciales,
cívicas y de gobierno. Aportan los medios para lograr un desem-
peño óptimo de numerosas aplicaciones y plantean – por otra parte
– nuevas formas para la gestión administrativa y de los recursos en
el mundo actual.
Pero ¿por qué se llaman tecnologías? ¿Qué entendemos, esencial-
mente, por información y comunicación? Una breve reflexión so-
bre estos conceptos facilitará el camino hacia la comprensión de
una definición integral.
A.1.1. La técnica y la tecnología
La palabra tecnología proviene de los vocablos griegos tekne
(técnica, arte u oficio) y logos (ciencia, conocimiento, estudio). Si
consideramos la técnica como un conjunto de saberes prácticos
nacidos de la experiencia – habitualmente de la prueba y el error –
la tecnología surge entonces de forma científica y reflexiva a partir
de la técnica.
En general, al hablar de tecnología nos referimos a un concepto
amplio que comprende un conjunto de técnicas científicamente
explicadas, conocimientos y procesos que se utilizan para el diseño
y la construcción de objetos orientados a satisfacer las necesidades
humanas.
También utilizamos este término, en particular, para nombrar y
definir áreas específicas como tecnología mecánica, tecnología de
los materiales, tecnología de la información, entre otras.
A.1.2. La información
En sentido general, la información es un conjunto organizado de datos procesados, capaz de cam-
biar el estado de conocimiento del que la obtiene, permitiendo tomar decisiones pertinentes acordes
a dicho conocimiento.
La información debe ser: veraz (verdadera, no falsa), oportuna (que ha llegado en su momento jus-
to) y relevante (importante para el receptor).
Universidad Nacional de La Matanza Departamento: Ingeniería e Investigaciones Tecnológicas
Cátedra: Fundamentos de TIC’s
Introducción a Sistemas de Información Página 5 de 71
A.1.3. La comunicación
La comunicación es el proceso mediante el cual se transmite la información. Si bien existen nume-
rosas teorías que definen y explican la comunicación desde diferentes puntos de vista, todas ellas
coinciden en que se requiere, para este proceso, de un emisor, un receptor, un código, un mensaje
(escrito en ese código) y un canal a través del cual se pueda transmitir el mensaje. Un código es un
conjunto de símbolos, signos y reglas compartidos por el emisor y el receptor. Ver Figura A.1.
Figura A.1: Proceso de Comunicación.
A.2. Tecnologías de la información y la comunicación
La evolución de las tecnologías modernas de la comunicación – por ejemplo la radio, la televisión y
la telefonía tradicional – y su integración con las tecnologías de la información, caracterizadas fun-
damentalmente por la digitalización de los contenidos, dan origen a las Tecnologías de la Informa-
ción y la Comunicación, que en adelante llamaremos TICs.
El proceso de digitalización – se estudiará más adelante – consiste en tomar una señal analógica
(voz, música, datos) y transformarla en una señal digital. Esto significa convertir aquellos datos en
una sucesión de ceros y unos – código binario – de tal forma que cualquier computadora pueda pro-
cesar dicha información, aprovechando su gran capacidad de cálculo.
En un sentido amplio, se denominan TICs al conjunto de tecnologías que permiten la adquisición,
producción, almacenamiento, tratamiento, comunicación, registro y presentación de la información
en forma de voz, imágenes y datos contenidos en señales de naturaleza electromagnética, óptica o
acústica.
Están conformadas por los aportes asociados de tres especialidades estrechamente relacionadas en-
tre sí: la microelectrónica, la informática y las telecomunicaciones.
A.3. La Informática
Desde los comienzos de la historia, el hombre necesitó procesar datos y transmitir información.
Cientos de años antes de Cristo ya se había inventado el ábaco y en siglos posteriores máquinas
como la Pascalina (1645), la ENIAC (1946), Clementina (1960, primera computadora argentina),
etc.
Figura A.2: Del ábaco a la tablet.
EMISOR RECEPTOR
CANAL
MENSAJE
Universidad Nacional de La Matanza Departamento: Ingeniería e Investigaciones Tecnológicas
Cátedra: Fundamentos de TIC’s
Introducción a Sistemas de Información Página 6 de 71
En el siglo XX surge el vocablo informática (contracción de information automatique), que signifi-
ca procesamiento automático de la información.
Actualmente se considera que la informática es una disciplina que, basándose en conocimientos
científicos y técnicos, intenta establecer una base científica para el diseño y programación de com-
putadoras, la resolución de problemas por medio de algoritmos y el procesamiento de datos para
obtener información en forma automática.
A.4. Los datos
A.4.1. La diferencia entre datos e información
La palabra dato proviene del latín (datum) y significa “lo que se da”. El dato es el antecedente nece-
sario para abordar el conocimiento de una cosa.
Es importante tener en cuenta que los datos, por sí mismos, no constituyen información; sino que se
utilizan en la toma de decisiones o en la realización de cálculos a partir de un proceso adecuado; y
teniendo en cuenta su contexto.
Por ejemplo, los datos que maneja un programa son informaciones no elaboradas. El procesamiento
de éstos da origen a la información útil o resultado.
A.4.2. El procesamiento de datos
En general, se denomina procesamiento ó simplemente proceso a la operación que transforma una
entrada en salida, como puede hacerlo un panel solar, un ser humano, una computadora o una reac-
ción química. Dicha operación implica, habitualmente, una o varias actividades organizadas que se
realizan en forma sucesiva o simultánea, con un objetivo determinado. Las salidas son los resulta-
dos que se obtienen luego de procesar las entradas.
Gráficamente, un proceso suele simbolizarse como un rectángulo que nos sugiere la idea del espa-
cio real o teórico donde aquel tiene lugar, con el detalle de sus entradas y salidas. El procesamiento
de datos consiste, entonces, en la recolección de datos de entrada, que son ordenados y evaluados
para obtener información útil, como se representa en la figura siguiente.
Figura A.3: Proceso de datos
A.5. La computadora
A.5.1. Definición
Una computadora (del latín computare – calcular), es una máquina electrónica que recibe como
entrada datos y los procesa para convertirlos en información útil, de acuerdo a lo indicado por ins-
trucciones que forman parte de un programa. La información obtenida depende de la aplicación
PROCESAMIENTO DATOS
INFORMACIÓN
Universidad Nacional de La Matanza Departamento: Ingeniería e Investigaciones Tecnológicas
Cátedra: Fundamentos de TIC’s
Introducción a Sistemas de Información Página 7 de 71
seleccionada por el usuario, ya que son máquinas de propósito general. Es decir, una computadora
puede realizar tareas muy diversas, de acuerdo a las posibilidades que brinden los programas (soft-
ware) y su propia estructura física (hardware).
La computadora está capacitada para tomar datos, elaborarlos y presentarlos como información,
como se muestra en la Figura 1.A.2. Su materia prima son los datos: puede procesarlos en grandes
cantidades, velozmente y en forma automática.
Cabe destacar, que la informática es una disciplina amplia que utiliza a la computadora, en particu-
lar, como uno de los elementos que la constituyen.
A.5.2. La computación
La Computación es el estudio de métodos algorítmicos utilizados para representar y transformar la
información incluyendo su teoría, diseño, implementación, aplicación y eficiencia. Es la herramien-
ta utilizada por la informática para transformar los datos en información aplicable para resolver
problemas.
El concepto fundamental de la Computación es el concepto
de algoritmo.
Se denomina algoritmo a un grupo finito de operaciones
organizadas de manera lógica y ordenada que permi-
te solucionar un determinado problema. Se trata de una
serie de instrucciones o reglas establecidas que, por medio
de una sucesión de pasos, permiten arribar a un resultado o
solución.
A.6. Las magnitudes y su clasificación
A.6.1. Magnitud, medición y error
1.1.1 Magnitud, medición y error
Se denomina magnitud a todo atributo o propiedad que puede
ser medida.
Medir es comparar una entidad, dimensión o cantidad con otra
de la misma naturaleza, adoptada como referencia.
El resultado de esta relación se expresa como proporción numé-
rica por medio de dos valores:
a) El valor más probable y
b) El error
Acompañados por una unidad que corresponde al nombre de una de las entidades, adoptada como
patrón o referencia de la medición.
Por ejemplo (18,3 0,1) m. Esto representa una longitud de 18,3 metros con un error absoluto por exceso (+) o por defecto (–)
de 0,1 metros. En ningún caso es posible conocer el valor verdadero, pero se tiene la certeza de que
el mismo se encuentra comprendido entre los 18,2 y los 18,4 metros.
Universidad Nacional de La Matanza Departamento: Ingeniería e Investigaciones Tecnológicas
Cátedra: Fundamentos de TIC’s
Introducción a Sistemas de Información Página 8 de 71
Ejemplo: Medir el largo de su birome.
Ud. toma un instrumento de medición adecuado, por ejemplo una regla.
Coloca un extremo de la birome en el 0 de la regla y observa hasta dónde llega el otro extremo.
Anota este valor, pero observa que la regla tiene como marca mínima el milímetro.
De acuerdo a la exactitud con que ha ubicado la birome sobre la regla y a la posición de su propia
observación, es decir a la apreciación de la persona que mide, ésta queda “entre dos” líneas de
milímetro. Ese es el error.
Resultado de la medición 14,5 0,1 cm.
Esto representa una longitud de 14,5 cm con un error absoluto por exceso (+) o por defecto (–) de
0,1 cm. En ningún caso es posible conocer el valor verdadero, pero se tiene la certeza de que el
mismo se encuentra comprendido entre los 14,4 y los 14,6 cm.
Normalmente el error es un rango de valores cuyo límite se expresa en el resultado de una medi-
ción, pero no se conoce su valor exacto (ni su signo) y por este motivo, se indica pero no se corrige.
Los errores pueden ser absolutos o relativos.
A.6.2. Magnitudes físicas y abstractas
Una magnitud física es una propiedad o cualidad medible de un sistema material.
Es un atributo de un cuerpo, sustancia o fenómeno que puede ser distinguido cualitativamente y
determinado cuantitativamente.
Algunos ejemplos de magnitudes físicas son la longitud, la masa, el tiempo, la velocidad, la acele-
ración, la intensidad de corriente eléctrica, la temperatura.
Existen otras magnitudes, denominadas abstractas, (pueden medir “abstracciones”) como carac-
terísticas, atributos o particularidades de un conjunto dado, mediante un proceso mental. Por ejem-
plo, los tests de inteligencia, coeficiente intelectual, etc.
A.6.3. Magnitudes analógicas y digitales
Para realizar mediciones se puede emplear la misma magnitud, por ejemplo, una cinta métrica para
medir el largo de una pared (longitud para medir longitud) o en una balanza de platillos, se colocan
pesas de peso conocido en un platillo y – por ejemplo –una cantidad de harina de la cual se desea
conocer el peso en el otro platillo; hasta lograr el equilibrio (peso para medir peso).
Sin embargo, en otras ocasiones se utiliza una magnitud para medir otra diferente. Ambas magnitu-
des son “análogas”, tienen comportamientos semejantes. Por ejemplo, un reloj de arena. Se utiliza
para medir la magnitud tiempo, a través de la variación de la magnitud volumen de la arena. Lo
mismo ocurre con un termómetro de mercurio: en este caso se mide la magnitud temperatura por
medio de la magnitud longitud de la columna de mercurio, cuya dilatación lineal es directamente
proporcional a la temperatura.
En ambos ejemplos se presentan variaciones semejantes entre cada par de magnitudes, en forma
biunívoca, constituyendo representaciones analógicas de las magnitudes que se desean medir.
Universidad Nacional de La Matanza Departamento: Ingeniería e Investigaciones Tecnológicas
Cátedra: Fundamentos de TIC’s
Introducción a Sistemas de Información Página 9 de 71
Figura A.4: Medición de tiempo con volumen y de temperatura con longitud (dilatación).
Los fenómenos de la vida real que se miden por medio de magnitudes físicas NO son exactos, como
se trató en párrafos anteriores. La mayoría de las magnitudes físicas se denominan continuas. Si se
grafican en un par de ejes cartesianos, describen una curva que NO TIENE SALTOS (espacio, tiempo,
velocidad, etc.). Consecuentemente, entre cualesquiera dos valores existen infinitos puntos interme-
dios. A estas magnitudes continuas se las suele denominar “analógicas”, debido a su manera de me-
dición. La Figura A.4 se representa la velocidad de un móvil con Movimiento Rectilíneo Unifor-
memente Acelerado. La velocidad es una magnitud “continua o analógica”.
Figura A.5: Magnitud continua (analógica).
Existe otro tipo de magnitudes llamadas discretas o “digitales”, representadas por números enteros.
Por ejemplo, la cantidad de átomos de hidrógeno en una molécula de agua o la cantidad de electro-
nes en un átomo.
Figura A.6 Magnitudes discretas. Átomos en una molécula de agua
y cantidad de electrones en un átomo.
A.7. Conversión analógica – digital
A.7.1. Necesidad de la conversión
La mayoría de las magnitudes que pueden medirse en la naturaleza son analógicas, como por ejem-
plo la temperatura, la distancia o el tiempo. Sin embargo, hemos de recordar que una computadora
actual sólo es capaz de procesar una gran cantidad de datos; no infinitos. En los dispositivos
electrónicos, por otra parte, los datos digitales se pueden procesar y transmitir en forma más eficien-
te y confiable que los datos analógicos. El almacenamiento de datos digitales, además, se puede
¿Cuánto mide exactamente
este punto?
Es imposible saberlo, porque
siempre puede aproximarse un
poco más.
Universidad Nacional de La Matanza Departamento: Ingeniería e Investigaciones Tecnológicas
Cátedra: Fundamentos de TIC’s
Introducción a Sistemas de Información Página 10 de 71
realizar de manera más compacta y recuperarse luego con mayor facilidad. Por este motivo, cuando
los datos pasan del mundo físico a un dispositivo digital se necesita un conversor analógico – digi-
tal (A/D) (Ver Figura A.7 ) y cuando sucede lo contrario, un conversor digital – analógico (D/A).
Figura A.7. Conversión analógica – digital
1
La Figura A.8 muestra la Conversión Analógica Digital (ADC) y la Conversión Digital Analógica
(DAC). Las siglas corresponden a ambos conceptos en idioma inglés.
Figura A.8: ADC y DAC.
A.7.2. Procedimiento para la conversión analógica – digital
Las computadoras, actualmente, procesan datos digitales y por este motivo las señales analógicas
deben ser digitalizadas. La conversión analógica – digital consiste en tomar una cantidad finita de
muestras (en los instantes de tiempo t1, t2, t3, etc.) de los valores de la señal analógica (que son infi-
nitos) y obtener luego una representación numérica de cada muestra, con una cantidad conveniente
de dígitos; como muestra la Figura A.9. La cantidad de dígitos se elige en función del error admisi-
ble, es decir, de acuerdo con la precisión deseada.
Figura A.9: Conversión analógica – digital
2
1 Imagen extraída de: teo-telecomunicaciones.blogspot.com
2 Imagen extraída de: blecmc.blogspot.com
Universidad Nacional de La Matanza Departamento: Ingeniería e Investigaciones Tecnológicas
Cátedra: Fundamentos de TIC’s
Introducción a Sistemas de Información Página 11 de 71
En electrónica digital se utilizan dispositivos y circuitos en los que sólo existen dos estados posi-
bles. Por este motivo, cualquier dato deberá ser representado como una secuencia de dos valores,
que pueden considerarse como sí – no, abierto – cerrado, encendido – apagado (on – off) o cual-
quier otra pareja de símbolos. Por motivos prácticos se adoptan los dígitos 0 y 1, cuya sucesión pro-
porciona números binarios más fáciles de tratar que las otras secuencias mencionadas; y capaces de
intervenir en operaciones algebraicas lógicas. Los dígitos en el sistema binario se denominan bits,
por la contracción de los términos binary digit. Para representar los unos y ceros se utilizan peque-
ñas tensiones eléctricas que reciben el nombre de niveles lógicos. Existen dos convenciones para
asociar los niveles de tensión de un circuito a los valores 0 y 1:
Lógica positiva, en la que el cero se representa con un nivel de tensión bajo, y el uno con un
nivel de tensión alto.
Lógica negativa, en la que el uno se representa con un nivel de tensión bajo, y el cero con un
nivel de tensión alto.
El convenio más utilizado, si no se menciona lo contrario, es el de lógica positiva.
Es importante destacar que en la práctica, un nivel alto puede ser cualquier valor de tensión entre un
mínimo y un máximo especificados. Lo mismo ocurre con el nivel bajo. Por ejemplo, en un circuito
que trabaja con tensiones entre 0 y 5 Volts, un valor de tensión entre 0V y 0,8V podría representar
el 0, mientras que un valor entre 2V y 5V representaría el 1. Los valores entre 0,8V y 2V serán, en
este caso, indeterminados.
A.7.3. Los sensores
Un sensor es un dispositivo capaz de detectar magnitudes físicas o químicas, llamadas variables de
instrumentación, y transformarlas en variables eléctricas proporcionales a dichas magnitudes.
Existe una amplia variedad de sensores capaces de medir, de acuerdo con su principio de funciona-
miento, diversas magnitudes: temperatura, intensidad luminosa, distancia, fuerza, humedad, pH. Las
señales eléctricas proporcionales que provee el sensor pueden ser tensiones, corrientes, variaciones
de resistencia o de capacidad. Estas magnitudes, de naturaleza eléctrica, pueden adaptarse a los ni-
veles adecuados – mediante circuitos de acondicionamiento – para ser procesadas por la computa-
dora. Ver Figura A.10.
Figura A.10: Utilización de sensores en una vivienda.
Universidad Nacional de La Matanza Departamento: Ingeniería e Investigaciones Tecnológicas
Cátedra: Fundamentos de TIC’s
Introducción a Sistemas de Información Página 12 de 71
PARTE B: INTRODUCCIÓN A SISTEMAS DE INFORMACIÓN Autores: Claudia Alderete, Daniel Giulianelli, Rocío Rodriguez, Mónica Larrosa, Mabel Cilenti,
Sabrina Bozzi, Víctor Fernández, Artemisa Trigueros
B.1. Introducción a Sistemas
El concepto se sistemas tiene como principio el estudio del todo y de las partes. El estudio de los
sistemas comienza con interés en el trabajo interdisciplinar y realiza analogías entre los sistemas de
carácter biológico y automáticos en los años ´50, es L. von Bertalanffy (1901-1972) quién propone
su Teoría General de Sistemas.
Diferentes definiciones de Sistema se ponen de manifiesto para su comprensión algunas áreas de
importancia.
La finalidad de la teoría general de sistemas, se basa en la búsqueda sistemática de la ley y el orden
en el universo, y tiende a ampliar su búsqueda orientándola en un orden de órdenes y una ley de
leyes.
Del concepto de Sistema cabe destacar que:
Existe un Conjunto de elementos o partes.
Están Dinámicamente relacionados. (Movimiento o acción).
Forman una actividad. (todos los elementos)
Buscan alcanzar el objetivo del sistema.
L. von Bertalanffy (1968). Biólogo y Fisico
•Es un conjunto de unidades en interrelación
Ferdinand de Saussure (1931). Linguista
•Es una totalidad organizada, hecha de elementos solidarios que no puedenser definidos más que los unos con relación a los otros en función de sulugar en esa totalidad
IEEE Standard Dictionary of Electrical and Electronic Terms
•Es un todo integrado, aunque compueto de estructuras diversas,interactuantes y especializadas. Cualquier sistema tiene un número deobjetivos, y los pesos asignados a cada uno de ellos puede variarampliamente de un sistema a otro. Un sistema ejecuta una funciónimposible de realizar por una cualquiera de las partes individuales.
Etándar X·.12-1970 (ANSI), Estándar 2382/V.VI(ISO) Vocabulary for information Processing
•Es una colección organizada de hombres, máquinas y métodos necesariapara cumplir un objetivo específico.
Palabras
Universidad Nacional de La Matanza Departamento: Ingeniería e Investigaciones Tecnológicas
Cátedra: Fundamentos de TIC’s
Introducción a Sistemas de Información Página 13 de 71
Operan sobre datos de entrada.
Proveen una salida. Información.
En la Teoría General de sistemas se establece que el sistema
es una totalidad y sus partes o componentes sólo pueden
comprenderse como funciones del sistema total. Por esta
razón es que se entiende que:
EL "TODO" CONSTITUYE MAS QUE LA SIMPLE
SUMA DE SUS PARTES
De aquí se desprende el principio de Sinergia.
Ejemplo: si se considera un equipo de futbol como un sistema,
donde cada jugador es una parte del mismo, todos tienen un objeti-
vo común: “ganar el partido”. El equipo (sistema), lograra cumplir
su objetivo, realizando cada uno de los jugadores la acción que más
sabe y de la mejor manera posible, interactuando uno con otro. Así
se puede observar como el todo (sistema equipo) constituye más
que la simple suma de sus partes (la suma del juego de cada uno de
los jugadores).
El término “sistema” es de uso común. Se habla de sistemas educativos, de sistemas de computa-
ción, de sistemas solares, de sistemas de teología, y de muchos otros. Los conceptos de sistemas
proveen una infraestructura útil para la descripción y comprensión de muchos fenómenos organiza-
cionales incluyendo las características de los sistemas de información.
Los sistemas pueden ser abstractos o físicos. Un sistema abstracto, es una disposición de manera
ordenada de las ideas interdependientes o artefactos. Por ejemplo, un sistema de teología es una
organización de ideas interdependientes acerca de Dios y las relaciones de los hombres con Dios.
Los sistemas físicos serán los que consideraremos de aquí en más simplemente como sistemas.
La definición de sistemas comprende un amplio rango de sistemas. Por ejemplo, un sistema tan
simple como un bolígrafo incluye tres o cuatro componentes de hardware. En contraste, un sistema
de control de tráfico aéreo está compuesto de cientos de componentes de software y hardware,
además de las personas que toman decisiones basadas en la información del sistema.
A continuación se definen diversos sistemas físicos por medio de sus elementos:
Un sistema es una colección de componentes interrelacionados que trabajan conjun-
tamente para cumplir algún objetivo.
Principio de Sinergia: El todo constituye más que la simple suma de sus partes.
Universidad Nacional de La Matanza Departamento: Ingeniería e Investigaciones Tecnológicas
Cátedra: Fundamentos de TIC’s
Introducción a Sistemas de Información Página 14 de 71
Los ejemplos previos, ilustran cómo un sistema no es un conjunto ensamblado de elementos al azar;
consiste en elementos que se pueden identificar cómo pertenecientes a un todo en razón de un
propósito, meta u objetivo común. Los sistemas físicos son más que construcciones conceptuales:
presentan actividades o comportamientos. Las partes interactúan para lograr un objetivo.
B.1.1. Modelo General de un Sistema
Un modelo general de un sistema físico es la entrada, el proceso y la salida. Esto, por supuesto,
es muy simplificado en razón de que un sistema pueda tener varias entradas y salidas (ver las figura
que se presentan a continuación).
Sistema Circulatorio
•El corazón y los vasos sanguíneos que mueven la sangre a través del cuerpo.
Sistemas de transporte
•El personal, las máquinas y las organizaciones que transportado bienes.
Sistemas de Armamentos
•El equipo, procedimientos y el personal que hace posible utilizar el armamento.
Sistema Escolar
•Los edificios, los profesores, los administradores y los textos que funcionan conjuntamente para dar instrucción a los estudiantes.
Sistema de Computación
•El equipo que conjuntamente funciona para llevar a cabo el procesamiento basado en el computador.
Sistema de contabilidad
•Los registros, las reglas, los procedimientos y el personal que opera para registrar los datos, medir el ingreso y preparar los informes.
Figura: Modelo simplificado de un Sistema
Proceso Salida Entrada
Universidad Nacional de La Matanza Departamento: Ingeniería e Investigaciones Tecnológicas
Cátedra: Fundamentos de TIC’s
Introducción a Sistemas de Información Página 15 de 71
Sistemas con muchas entradas y salidas.
Una característica de los sistemas es que las propiedades y el comportamiento de los componentes
del sistema están inseparablemente entremezclados. El funcionamiento exitoso de cada componente
del sistema depende del funcionamiento de otros componentes. Así, el software sólo puede funcio-
nar si el procesador es operacional. El procesador sólo puede hacer cálculos si el sistema de softwa-
re que define las operaciones se ha instalado de forma exitosa. La compleja relación entre los com-
ponentes de un sistema significa que este último es más que la simple suma de sus partes.(sinergia)
Las características que delinean un sistema configuran su límite. El sistema está por dentro de
los límites; el medio ambiente está por fuera de los límites. En algunos casos es bastante sencillo de
definir lo que es parte de un sistema y qué no lo es; en otros casos, la persona que estudia el siste-
ma, deberá realizar un minucioso análisis para lograr definir los límites.
A continuación se presentan algunos ejemplos de sistemas en donde es posible de forma sencilla
definir sus límites:
SISTEMA LÍMITES
Humano Piel, cabellos, uñas y las partes que están contenidas en el interior for-
man el sistema.
Automóvil La carrocería del automóvil más las llantas y todas las partes conteni-
das dentro de él
Producción Las máquinas de producción, los inventarios de producción de trabajo
en proceso, los empleados de producción, los procedimientos de pro-
ducción, etc., forman el sistema.
Límite o frontera: es la línea que separa el sistema (que defino) de su entorno. Esta
línea puede ser física (visible) o imaginaria (estableciéndose hasta donde llega el siste-
ma.)
Entorno ó Medio Ambiente: Todo sistema se desarrolla en un medio que lo rodea, a
éste medio se lo llama entorno o medio ambiente.
Proceso
Salida 1 Entrada 1
Salida 2 Entrada 2
Salida n Entrada n
Universidad Nacional de La Matanza Departamento: Ingeniería e Investigaciones Tecnológicas
Cátedra: Fundamentos de TIC’s
Introducción a Sistemas de Información Página 16 de 71
Ejemplos de Límite:
B.1.2. Subsistemas
Por lo general, los sistemas son jerárquicos en el sentido de que incluyen otros sistemas. Por ejem-
plo, un sistema de órdenes y control policial puede incluir un sistema de información geográfico
para proporcionar los detalles de la localización de los incidentes. Estos otros sistemas se denomi-
nan subsistemas. Una característica de éstos es que se pueden operar por sí solos como sistemas
independientes. Por lo tanto, el mismo sistema de información geográfica se puede utilizar en dife-
rentes sistemas. Sin embargo, su comportamiento en un sistema particular depende de la relación
con otros subsistemas.
El uso de subsistemas como la construcción por bloques, es básico para analizar y desarrollar los
sistemas. Esto requiere la comprensión de los principios que dictaminan la manera como se cons-
truyen los sistemas a partir de los subsistemas. Cada subsistema es delineado por sus límites. Las
interconexiones y las interacciones entre los subsistemas se llaman interfaces. Las interfaces ocu-
rren en el límite y toman la forma de entradas y salidas.
Humano
•Piel
•Cabellos
•uñas
Automóvil
•Carrocerías
•Llantas
Unidades de
Almacenamien-
to
Unidades de
Salida
Subsistema de salida
CPU.
Unidad Central de Pro-
cesamiento
Subsistema de procesamiento.
Unidades de
Entrada
Subsistema de entrada
Interfaz
Interfaces (en los canales).
Subsistema de almacenamiento
La configuración de la computadora como sistema
Universidad Nacional de La Matanza Departamento: Ingeniería e Investigaciones Tecnológicas
Cátedra: Fundamentos de TIC’s
Introducción a Sistemas de Información Página 17 de 71
B.1.3. Caja Negra
Un subsistema en el nivel más elemental (entrada, proceso, salida) no se de-
fine en cuanto al proceso. A este sistema se le llama una “caja negra”, ya que
las entradas y las salidas se conocen pero no la transformación actual a partir
de las primeras sobre las otras (ver figura a continuación).
Ejemplo: en una máquina expendedora de café, se conocen las entradas: monedas o billetes y elec-
ción del tipo de café (dulce, corto, largo, capuchino, etc). Estas serías las Entradas definidas que se
muestran en la figura. El proceso que realiza la máquina no se conoce, tal vez se pueda intuir, pero
no es relevante para el usuario (persona que interactúa con el sistema) en qué proporción utiliza
cada elemento o en qué orden lo realiza. Por eso se dice “caja negra”, no se puede ver lo que hay
adentro. Y las salidas definidas como muestra la ilustración serían: el vaso y la bebida.
B.1.4. Clases de Sistemas
A pesar de la existencia de sistemas tan disimiles entre sí (por ejemplo: El cuerpo humano, el envío
de una nave al espacio, una máquina tragamonedas, el océano, etc). Es posible realizar una clasifi-
cación de los mismos en base a diversos criterios generales:
CRITERIO TIPO DE
SISTEMA
DESCRIPCIÓN
Según el comportamiento Determinístico
Programa de com-
putación
El sistema opera de una manera muy predecible. La
interacción entre las partes se conoce con certeza. Si
uno tiene la descripción de un estado del sistema en un
momento dado además de una descripción de su opera-
ción, el siguiente estado del sistema se puede dar con
exactitud, sin error.
Probabilístico
Mapa de meteo-
rología
El sistema se puede definir en términos de comporta-
miento probable; hay cierto grado de error que siempre
está asociado a la predicción de lo que hará este siste-
ma.
Proceso (transformación) no definido
Entradas
definidas
Salidas
definidas
Universidad Nacional de La Matanza Departamento: Ingeniería e Investigaciones Tecnológicas
Cátedra: Fundamentos de TIC’s
Introducción a Sistemas de Información Página 18 de 71
Según la cantidad de
componentes
Simple
Reloj de arena El sistema posee pocos componentes y la relación o
interacción entre ellos es sencilla y directa.
Complejo
Ecosistema El sistema posee muchos elementos estrechamente
relacionados e interconectados.
Según los cambios en el
tiempo
Estable
Una taza. El sistema sufre escasos cambios al paso del tiempo.
Dinámico
Sistema de células. El sistema sufre rápidos y constantes cambios al paso
del tiempo. (Incluye la variable de tiempo).
Según la capacidad de
modificación
Adaptable
Virus. Cubo de
hielo.
El sistema es capaz de modificarse en respuesta a cam-
bios en el entorno.
No adaptable
Mesa. El sistema es incapaz de modificarse en respuesta a
cambios en el entorno.
Según el tiempo de exis-
tencia
Permanente
Puente. El sistema está diseñado para existir durante un período
relativamente largo.
Temporal
Torta. El sistema está diseñado para existir durante un período
relativamente corto.
Según el intercambio con
el medio ambiente
Cerrado
Reacción química
en un contenedor
sellado y aislado
El sistema está definido en lo físico como un sistema
que está contenido en sí mismo. No intercambia mate-
riales, información ni energía con su medio ambiente.
Abierto
Maquinas, sistemas
de información,
célula.
El sistema intercambia información, materiales o
energía con el medio ambiente incluyendo el azar y
entradas no definidas.
Según su origen Natural
Universo Ocurren en la naturaleza no han requerido del ser
humano para su conformación
Artificial
Organizaciones,
sistemas de infor-
mación, programas
de computadoras.
Son creados, no ocurren en la naturaleza.
Los sistemas artificiales están diseñados para apoyar
los objetivos de los diseñadores y de los usuarios.
Todos los ejemplos que anteriormente se enumeran, son vistos como sistemas. Aunque en aparien-
cia, en algunos casos pareciera ser un solo objeto. En la teoría general de sistemas, todo debe ser
visto y tratado como un sistema.
Universidad Nacional de La Matanza Departamento: Ingeniería e Investigaciones Tecnológicas
Cátedra: Fundamentos de TIC’s
Introducción a Sistemas de Información Página 19 de 71
B.2. Componentes de un Sistema Informático
COMPONENTE CARACTERÍSTICAS
Hardware
HARDWARE: se refiere a todas las partes físicas
(tangibles) de un sistema informático. Está for-
mado por los componentes electrónicos, eléctri-
cos y mecánicos, el microprocesador y las placas
de la memoria principal, los circuitos impresos y
sus cables de conexión, los gabinetes, periféricos
y cualquier otro elemento tangible conforman el
hardware de una computadora. Conviene recor-
dar, además, que la denominación es amplia y no
se limita a las computadoras: también se reconoce
como hardware al conjunto de elementos físicos
que constituyen un teléfono celular, una consola
de juego o un robot.
Software Es cualquier conjunto de instrucciones (progra-
ma), NO TANGIBLE, capaces de ser ejecutadas
por una computadora y que producen que el pro-
cesador de la misma realice operaciones específi-
cas, tal más toda la documentación del mismo.
El software se clasifica en:
Software de base: es indispensable para hacer funcionar al hardware, proveyendo
la administración y control de todo el sis-
tema. Ejemplo: Sistema Operativo (Win-
dows, Linux, Unix, Mac, Android, etc.)
Software de aplicación: convierte a la computadora en una herramienta específi-
ca para una tarea concreta. Ejemplos: para
escribir: Word, Adobe Writer, para dise-
ño: AutoCAD, Corel Draw, etc., para es-
parcimiento: juegos, para comunicaciones:
Chrome, Explorer; para contabilidad:
Tango, Catedral, para protección: Antivi-
rus, Firewall, etc.
Humanware (Ser humano)
Son los humanos que desarrollan y/o interactúan
con el sistema de procesamiento de datos.
Desarrolladores: diseñan, programan y
mantienen el software que se ejecuta en el
sistema.
Usuario operador: utiliza la computadora para tareas habituales: trabajo, estudio,
comunicación, esparcimiento, etc.
Universidad Nacional de La Matanza Departamento: Ingeniería e Investigaciones Tecnológicas
Cátedra: Fundamentos de TIC’s
Introducción a Sistemas de Información Página 20 de 71
B.2.1. Modelo de Control Básico
Todos los sistemas tienen niveles aceptables de desempeño, denominados estándares y contra los
que se comparan los niveles de desempeño actuales. Siempre deben anotarse las actividades que se
encuentran muy por encima o por debajo de los estándares para poder efectuar los ajustes necesa-
rios. La información proporcionada al comparar los resultados con los estándares junto con el pro-
ceso de reportar las diferencias a los elementos de control recibe el nombre de retroalimentación.
Los sistemas emplean un modelo de control básico consistente en:
1. Un estándar para lograr un desempeño aceptable
2. Un método para medir el desempeño actual
3. Un medio para comparar el desempeño actual contra el estándar
4. Un método de retroalimentación
Los sistemas que pueden ajustar sus actividades para mantener niveles aceptables continúan funcio-
nando. Aquellos que no lo hacen, tarde o temprano dejan de trabajar.
Un estándar de desempeño de sistemas es un objetivo específico del sistema. Por ejemplo, un
estándar de desempeño de sistemas de un proceso de manufactura podría ser la producción de no
más de un 1 por ciento de partes defectuosas. Una vez establecidos los estándares, se mide el des-
empeño del sistema y se lo compara con el estándar. Las variaciones respecto al estándar son de-
terminantes del desempeño del sistema. El cumplimiento de estándares de desempeño de sistemas
también puede imponer disyuntivas en términos de costo, control y complejidad.
Modelo de Control Básico
El concepto de interacción con el medio ambiente, que es lo que caracteriza a los sistemas abiertos,
es esencial para el control. Recibir y evaluar la retroalimentación, permite al sistema determinar qué
tan bien está operando. En contraste, los sistemas cerrados sostienen su nivel de operación siempre
y cuando posean información de control adecuada y no necesiten nada de su medio ambiente. Un
objetivo en el diseño de sistemas es construir sistemas que necesiten la menor intervención del me-
dio externo para mantener un desempeño aceptable. Por consiguiente, la autorregulación y el propio
ajuste son objetivos de diseño en todos los ambientes de sistemas.
B.2.2. Desempeño y Estándares de Sistemas
Eficiencia
La eficiencia es una medida de lo que se produce dividido lo que se
consume; puede ir del 0 al 100 por ciento
Frontera o límite del sistema
Medir
Comparar
Estándar
Entrada Salida
Entrada
Retroalimentación
Desempeño
Actual
Desempeño
Actual
Universidad Nacional de La Matanza Departamento: Ingeniería e Investigaciones Tecnológicas
Cátedra: Fundamentos de TIC’s
Introducción a Sistemas de Información Página 21 de 71
La eficiencia es un término relativo empleado para comparar sistemas. Un motor de gasolina, por
ejemplo, es más eficiente que un motor de vapor, pues con un monto equivalente de insumo de
energía (gasolina o carbón), el motor de gasolina produce más energía.
El índice de eficiencia de energía de los motores de gasolina es alto en comparación con el de los
motores de vapor.
Eficiencia = Producido Consumido
Eficacia
Se le puede calcular al dividir las metas alcanzadas entre el total de las metas establecidas. Lo mis-
mo que la eficiencia, la eficacia también es un término relativo que sirve para comparar sistemas.
Ejemplo: se tienen dos tipos de fertilizante uno es más
eficaz que el otro, el fertilizante A ha cumplido sus
metas, en un grado superior.
Eficiencia = Metas Alcanzadas Metas Establecidas
Eficiencia y eficacia
Son objetivos de desempeño fijados en relación con un sistema general. El cumplimiento de estos
objetivos supone considerar no sólo la eficiencia y eficacia deseadas, sino también el costo, comple-
jidad y nivel de control que se desean del sistema. El costo comprende tanto los gastos iniciales de
un sistema como la totalidad de sus gastos directos permanentes. La complejidad tiene que ver con
qué tan complicada es la relación entre los elementos del sistema. El control es la capacidad de un
sistema para funcionar dentro del marco de normas predefinidas – tales como políticas, procedi-
Locomotora a Vapor Locomotora a Diessel
A
La eficacia es una medida del grado en el que un sistema cumple sus metas.
Universidad Nacional de La Matanza Departamento: Ingeniería e Investigaciones Tecnológicas
Cátedra: Fundamentos de TIC’s
Introducción a Sistemas de Información Página 22 de 71
mientos y presupuestos –, así como el esfuerzo administrativo requerido para mantener dentro de
esos límites el funcionamiento del sistema. El cumplimiento de objetivos definidos de eficiencia y
eficacia puede implicar disyuntivas en términos de costo, control y complejidad.
B.2.3. Variables y Parámetros de Sistema
Ciertas partes de un sistema son susceptibles de control administrativo directo, mientras que otras
no.
Ejemplo: El precio que una compañía fija a su producto es una variable de sistemas, porque puede
controlarse. Los valores se originarán a través de la aplicación del modelo
Ejemplo: El costo de una materia prima y la cantidad de gramos de un producto químico que habrá
de utilizarse en la fabricación de cierto tipo de plástico son ejemplo de cantidad o valor no controla-
ble por los administradores. Se consideran invariantes (que no varían) en la aplicación del modelo.
B.2.4. Descomposición
Cuando se tiene un problema grande, en ocasiones es difícil tener en cuenta todas las partes del
mismo. Así para una mejor comprensión, se divide en partes o problemas más pequeños y se anali-
za cada una de esas partes más metódicamente o detalladamente. Así ocurre con los sistemas. Un
sistema complejo, es difícil de comprender cuando se considera como un todo, por lo tanto, el sis-
tema se descompone o factoriza en subsistemas. Los límites e interfaces están definidos de tal ma-
nera que la suma de los subsistemas constituye un sistema completo. Este proceso de descomposi-
ción se continúa con los subsistemas que se dividen en subsistemas más pequeños hasta que el más
pequeño de los subsistemas tenga un tamaño manejable.
Los subsistemas resultantes de este proceso generalmente tienen la forma de estructura jerárquica.
En la jerarquía un subsistema es un elemento de un suprasistema (el sistema superior a él). Así se
deduce que cada sistema se encuentra dentro de otro sistema, pasando a ser el sistema de inferior
jerarquía un subsistema del suprasistema o sistema que lo contiene.
Variable de sistemas: es una cantidad o unidad que puede ser controlada por el tomador
de decisiones.
Parámetro de sistemas: es un valor o cantidad imposible de controlar.
Relaciones jerárquicas de los subsistemas
Sistema
Subsistema C Subsistema B Subsistema A
A1
A21
A2
A22
B1 B2 B3 C1
C11
C2
C12
Universidad Nacional de La Matanza Departamento: Ingeniería e Investigaciones Tecnológicas
Cátedra: Fundamentos de TIC’s
Introducción a Sistemas de Información Página 23 de 71
Ejemplos de suprasistemas y subsitemas:
En el diseño de sistemas existen dos conceptos muy importantes:
Cohesión: Grado en el cual los componentes o partes de un sistema son necesarios y suficientes
para llevar a cabo una sola función bien definida.
Ejemplo: Función APUNTADOR/SELECCIONADOR. Mouse: todas sus partes interactúan para
lograr apuntar y seleccionar objetos en la pantalla del monitor.
La cohesión está relacionada con la manera en que se agrupan los elementos, en éste caso, partes de
un sistema (subsistemas) en una unidad mayor (sistema o suprasistema).
Cohesión funcional: se da cuando se agrupan elementos que realizan un mismo fin, tarea o fun-
ción. Es decir, todas las unidades o elementos trabajan para realizar una misma función. Aquí se
puede observar también el concepto de equipo entre los componentes y enfatizar el beneficio de
ganancia de “sinergia”.
Ejemplo: Función ENSEÑAR Fundamentos de TICs. Todos los profesores miembros de esta cáte-
dra trabajan en distintos roles (organizar, dictar clase, atender consultas, escribir apuntes, evaluar,
etc.) para lograr el fin de ENSEÑAR.
La descomposición en subsistemas se usa tanto en el análisis del sistema actual como en el diseño e
implementación de un nuevo sistema. En ambos casos el investigador o diseñador debe decidir
cómo descomponerlo, por ejemplo, dónde ubicar los límites. Las decisiones dependerán de los obje-
tivos de la descomposición y también de las diferencias personales entre los diseñadores. Esta últi-
ma se podría minimizar.
El principio general de la descomposición que supone que los objetivos del sistema dictaminan el
proceso, es la cohesión funcional.
Los componentes están considerados como parte del mismo subsistema si desempeñan o están rela-
cionados a la misma función. Como ejemplo, un programa de aplicación al ser dividido en módulos
(subsistemas) se dividirá entre las principales funciones del programa. En diseño, la identificación
de los subsistemas cohesionados funcionalmente es el primer paso. En consecuencia, los límites
necesitan estar claramente especificados, las interfaces simplificadas y establecidas las conexiones
apropiadas entre los subsistemas.
Universidad Nacional de La Matanza Departamento: Ingeniería e Investigaciones Tecnológicas
Cátedra: Fundamentos de TIC’s
Introducción a Sistemas de Información Página 24 de 71
A1 A2 B1 B1
A3 A4 B3 B4
Todos los sistemas interconectados.
B.3. Simplificación
B.3.1. Agrupamiento de Subsistemas
El proceso de descomposición podría conducir a un gran número de interfaces de subsistemas por
definir. Por ejemplo, cuatro subsistemas que interactúan todos unos con otros tendrán seis interco-
nexiones: un sistema con 20 subsistemas todos interactuando, tendrá 190 interconexiones.
El número de interconexiones si todos los subsistemas interactúan en general es:
½ n . (n-1)
Donde n= número de subsistemas.
Algunos métodos de simplificación son:
1. Se establece que las agrupaciones de subsistemas interactúan cada una con la otra, por lo tanto
un simple paso de interfaz se define de un grupo hacia otros subsistemas o grupos de subsiste-
mas (ver figura precedente). Un ejemplo es la base de datos a la cual se tiene acceso por varios
programas, pero la interconexión se hace solamente a través de la interfaz de la administración
de la base de datos.
2. Se establecen los métodos para el desacoplamiento de sistemas de tal manera que la necesidad
de la interconexión se reduzca.
Cada interconexión es una interfaz potencial para la comunicación entre los subsistemas. Cada in-
terfaz implica una definición de un paso de comunicación. La Figura muestra un sistema con 8 sub-
sistemas, por lo tanto la cantidad de interconexiones es 28 interconexiones.
Simplificación: Es el proceso de organizar los subsistemas de manera tal que se reduz-
ca el número de interconexiones.
Universidad Nacional de La Matanza Departamento: Ingeniería e Investigaciones Tecnológicas
Cátedra: Fundamentos de TIC’s
Introducción a Sistemas de Información Página 25 de 71
La siguiente Figura muestra la simplificación del mismo sistema.
En este caso se han realizado dos grupos de subsistemas, de acuerdo a sus funciones.
Se trazaron todas las relaciones dentro de cada grupo (6 y 6) y luego se interrelacionaron los grupos
entre sí.
El total de interconexiones es de 13, es decir, 15 conexiones menos que las 28 anteriores.
Simplificación
Ejemplo: Se tiene un subsistema que realiza la inscripción a una lista, que podría ser un listado de inscrip-
ción. El sistema registra los datos que recibe, los ordena alfabéticamente. Luego se tiene otro sub-
sistema que lista o imprime los datos del listado.
Aplicación de la Fórmula…
½ .n(n-1)
½ . 2(2-1) =
½ . 2 . 1 =
2/2 = 1 Interfaz.
A1
A4
A2
A3 B3
B1
B4
B2
Interfaz: es la interconexión entre dos sistemas ó subsistemas.
Universidad Nacional de La Matanza Departamento: Ingeniería e Investigaciones Tecnológicas
Cátedra: Fundamentos de TIC’s
Introducción a Sistemas de Información Página 26 de 71
Ejemplos de Subsistemas e Interfaces: Sistema SILLA Sistema ANTEOJOS
B.3.2. Desacoplamiento
El acoplamiento es una de las metas y objetivos del diseño de sistemas; se define como el grado
por el cual los elementos se interconectan o se relacionan entre sí. De esto se desprende, cuánto
depende uno de otro. Para un bueno diseño es aconsejable un Bajo Acoplamiento.
Por otra parte, se habla de desacoplamiento cuando existe una independencia entre dos elementos.
Si se traslada este concepto a los sistemas, se tendrán dos sistemas cuyas funciones podrán realizar-
se sin recurrir un sistema al otro.
De esta manera, se advierte que si se necesita que dos sistemas estén comunicados o se relacionen,
se dirá que cuanto mayor intercambio realicen, mayor acoplados estarán y por lo tanto tendrán ma-
yor conocimiento uno de otro.
Si los diferentes subsistemas están conectados de modo muy compacto se requiere entre ellos una
coordinación muy exacta. Por ejemplo, si la materia prima entra directamente a producción en el
momento en que llega a la fábrica, el sistema de materia prima se puede decir que está fuertemente
acoplado. Bajo estas condiciones, las entregas de materia prima (insumos al sistema de producción
y salidas provenientes del sistema de materias primas), deben hacerse oportunamente con el fin de
evitar demoras en la producción o para prevenir que el material nuevo que llegue demasiado pronto,
no tenga lugar donde almacenarse.
Tales acoplamientos tan compactos plantean una coordinación muy fuerte y exigencias de oportuni-
dad entre los dos sistemas. En razón de que son algo independientes, es difícil hacer que operen de
una manera completamente sincronizada, puesto que eventos al azar crean incertidumbre en los
tiempos de entrega, y cambian los tiempos esperados de llegada. De la misma manera el proceso de
producción puede experimentar demoras al azar o no planeadas. La solución es desacoplar o reducir
conexiones de tal manera que los dos sistemas puedan operar en corto plazo con alguna medida de
independencia.
Un sistema es altamente eficiente y eficaz cuando tiene una muy alta cohesión fun-
cional y un muy bajo acoplamiento.
Acoplamiento: es el grado en el cuál los módulos se interconectan o se relacionan
entre ellos. Da la idea de cuánto depende uno de otro.
Universidad Nacional de La Matanza Departamento: Ingeniería e Investigaciones Tecnológicas
Cátedra: Fundamentos de TIC’s
Introducción a Sistemas de Información Página 27 de 71
Algunos tipos de desacoplamiento son:
1. Inventarios, almacenamientos intermedios, o líneas de espera. Se crea un almacenamiento de
manera tal que no dependa la salida de la entrada del sistema. En el ejemplo de los subsistemas
de materias primas y el subsistema de producción, el inventario de materias primas (stock) per-
mite a los dos subsistemas operar de alguna manera independiente (en el corto plazo). Las me-
morias intermedias (buffers) de datos se utilizan en algunos sistemas de computación y en algu-
nos sistemas de comunicación para compensar las diferentes relaciones de entradas y salidas de
datos.
Ejemplo: Un carpintero está en plena producción de
muebles, y un cliente le encarga un nuevo mueble. Para
realizarlo necesitará encargar más madera a su provee-
dor, la cual tardará 2 días en ser reciba. El carpintero de-
bería decirle a su cliente que la entrega del nuevo mueble
se retrasará 2 días. Esto sucede porque el sistema de
stock de materiales del carpintero está fuertemente aco-
plado con el de su proveedor. Cualquier problema, de-
mora o faltante en las materias primas (maderas, etc)
afectará e impactará notablemente en el sistema de la
carpintería.
Una de las soluciones planteadas es la de tener almacenamientos intermedios. Si el carpintero
tuviera un stock de materiales (una cantidad determinada de materias primas) podría realizar el
nuevo mueble mientras el pedido del proveedor es entregado. Cumpliría con su cliente en en-
tregar a tiempo y luego de 2 días repondría la madera que ha utilizado, quedando siempre con
una pequeña cantidad de materiales para futuros trabajos.
2. Recursos de holgura y flexibles. Cuando la salida de algún sistema es la entrada de otro, las
existencias de recursos de holgura permiten a los subsistemas que sean algo independientes y
aún más, que cada uno responda a las demandas de los otros subsistemas. La capacidad de la
organización para responder a las variaciones en la demanda mediante el uso de recursos de
holgura se mejora, si la disponibilidad de recursos se puede emplear para diferentes propósitos.
Una organización de sistemas de información que utiliza el concepto de combinación de pro-
gramadores y de analistas de sistemas tiene más flexibilidad en responder a las variaciones en la
demanda entre el análisis y la programación, que una organización con la misma cantidad de
personal que utiliza analistas de sistemas solamente para el análisis y el diseño y emplea pro-
gramadores solamente para la programación (está claro que es solo un ejemplo de consideración
del problema de selección de trabajos combinados o separados).
Siguiendo con el ejemplo de la carpintería, podríamos tener dos subsistemas: el subsistema de
producción y el subsistema de entrega y colocación.
Para cada uno de los subsistemas tenemos recursos que realizan tareas diferentes. Un cortador o
armador (sub. producción) no realiza las mismas tareas que un colocador (sub. entrega y coloca-
ción).
Si un día falta un armador, existiría un retraso en el armado del mueble, y no podríamos realizar-
se la entrega y colocación del mismo. Esto sucede porque la entrada del subsistema de “entrega y
colocación” está fuertemente acoplada con la salida del subsistema de “producción”.
Universidad Nacional de La Matanza Departamento: Ingeniería e Investigaciones Tecnológicas
Cátedra: Fundamentos de TIC’s
Introducción a Sistemas de Información Página 28 de 71
Para salvar este acoplamiento es posible tener recursos de holgura y flexibles. Si en la carpintería
hubiera un colocador/instalador (recurso de holgura) que también supiera armar muebles (recur-
so humano con capacidad de flexibilidad en las tareas), podría realizar esa tarea. De esta manera
estaríamos desacoplando los subsistemas. No teniendo retraso en la entrega y colocación.
3. Estándares. La especificación de las normas, los costos de los estándares y otras normas le
permiten a un subsistema planear y organizarse reduciendo la necesidad de comunicarse con
otros subsistemas. Si, por ejemplo, el departamento de producción desea diseñar un módulo de
procesamiento de datos que incluya bienes terminados y un código estándar de productos que
sea utilizado por toda la organización, no tiene necesidad de comunicar y negociar con otros de-
partamentos.
Los problemas de acoplamiento compacto no solamente se derivan de los problemas físicos de la
coordinación de los movimientos de los recursos, sino también de los problemas de la comunica-
ción. Los diferentes métodos de desacoplamiento reducen la necesidad de comunicación y permiten
a los subsistemas comunicarse sobre bases de excepción. Solamente si el sistema comienza a operar
por fuera de ciertos límites hace que los otros subsistemas, con los cuales se interconecta necesiten
estar informados. El empleo de mecanismos de desacoplamiento puede por lo tanto ser visto como
una alternativa al incremento en las comunicaciones. Esto implica que una mejora en el sistema de
información o de comunicación puede aumentar la oportunidad para el acoplamiento compacto y
puede reducir la necesidad de mecanismos de desacoplamiento.
B.4. Tensión de Sistemas y Cambio de Sistemas
Los sistemas ya sean vivientes o artificiales, los sistemas organizacionales, los sistemas de informa-
ción o los sistemas de control cambian en razón del esfuerzo de tensión que padecen.
B.4.1. Clases de Tensiones (Stress)
Hay dos formas básicas de tensiones que se pueden imponer sobre un sistema en forma separada o
concurrente.
Un esfuerzo de tensión (stress) es una fuerza que se transmite por intermedio de un
suprasistema al sistema que hace que éste cambie de tal manera que el suprasiste-
ma puede lograr mejor sus objetivos.
Universidad Nacional de La Matanza Departamento: Ingeniería e Investigaciones Tecnológicas
Cátedra: Fundamentos de TIC’s
Introducción a Sistemas de Información Página 29 de 71
1. Un cambio en el conjunto de objetivos del sistema. Nuevas metas pueden ser
creadas o las antiguas metas se pueden eliminar.
2. Un cambio deseado en los niveles de ejecución con los objetivos existentes. El
nivel deseado de ejecución puede ser aumentado o disminuido.
B.4.2. Proceso de Adaptación
Los sistemas se acomodan a la tensión mediante un cambio en la forma que pueden ser cambios
estructurales o cambios en los procesos.
Ejemplo: un sistema de computación bajo tensión para un mayor grado de participación de los da-
tos, puede ser cambiado por la instalación de terminales en sitios remotos. Esto es un cambio es-
tructural. Un cambio en el proceso se constituye por las demandas para una mayor eficiencia que se
pueda obtener o por el cambio en la forma como se clasifiquen los datos.
Ejemplo: Podemos ver a una Universidad como un sistema donde existen varios subsistemas (de
inscripciones, de sueldos, de asistencia, etc). Con el tiempo se fueron incorporando nuevos depar-
tamentos en la Universidad. Esto implica una mayor demanda de inscripciones, las cuales en una
primera instancia se realizan todas en un mismo lugar y una persona a recogía y recopila la infor-
mación de cada alumno que se inscribía. Como consecuencia de esto, hubo un cambio deseado en
los niveles de ejecución con los objetivos existentes. Se implemento que las inscripciones se infor-
matizaran e hicieran en cada uno de los departamentos. (Cambio estructural).
A consecuencia una mayor demanda y una mayor eficiencia, se implemento que la inscripción fuera
por medio de internet (vía web), esto sería un cambio: Cambio en los procesos y estructurales.
Sistema de Inscripciones
Es muy improbable que el sistema cambie para acomodar la tensión, pues sería un cambio global en
su estructura y proceso. En cambio, aquellos responsables del cambio intentarán ubicarlo por inter-
medio de limitaciones a los procesos de ajuste solamente, en uno o varios de sus subsistemas.
Como regla general, los subsistemas más próximos a la tensión cambiarán en mayor medida. La
proximidad a la tensión es funcional usualmente; el subsistema que realiza la función más seme-
jante a la necesitada para aliviar la tensión, es el sistema más próximo a dicha tensión. Un ejem-
plo es el caso de una tensión en razón de la actualización no autorizada de un registro, en un sistema
Universidad Nacional de La Matanza Departamento: Ingeniería e Investigaciones Tecnológicas
Cátedra: Fundamentos de TIC’s
Introducción a Sistemas de Información Página 30 de 71
en línea; la subdivisión más próxima a la tensión es el subsistema de entrada que tenga la función de
dar la autorización.
El concepto de tensión ayuda a explicar algo de la dinámica que hace que los sistemas cambien. El
proceso de cambio del sistema de información sigue un modelo conceptual general de adaptación al
sistema de tensión (stress).
B.5. Características del Software
B.5.1. Proceso Software y Producto Software
Un concepto que debe tenerse claro es la diferencia entre proceso software y producto software.
Existen cuatro actividades fundamentales de procesos que son comunes para todos los procesos de
software:
ACTIVIDADES CARACTERÍSTICAS
Especificación del software La funcionalidad del software y las restricciones sobre su operación
deben quedar definidas.
Desarrollo del software Debe producirse software que cumpla con la especificación.
Validación del software El software debe validarse para asegurar qué es lo que el cliente
requiere.
Evolución del software El software debe evolucionar para cumplir con los cambios requeri-
dos por el cliente.
Existen dos tipos de producto de software:
Productos genéricos: Son sistemas aislados producidos por una organización de de-
sarrollo y que se venden al mercado abierto a cualquier cliente que le sea posible
comprarlo. También se los denomina software empaquetados o enlatados. Ejemplos
son las bases de datos, los procesadores de texto, herramientas de administración de
proyectos, etc.
Producto Software: Consiste en programas desarrollados y en la documentación aso-
ciada.
Proceso Software: Es un conjunto de actividades y resultados asociados que producen
un producto de software. Estas actividades son llevadas a cabo por los ingenieros de
software.
Universidad Nacional de La Matanza Departamento: Ingeniería e Investigaciones Tecnológicas
Cátedra: Fundamentos de TIC’s
Introducción a Sistemas de Información Página 31 de 71
Productos personalizados: Son sistemas requeridos por un cliente en particular.
Ejemplos son sistemas desarrollados para llevar a cabo procesos de negocios especí-
ficos, sistemas de control aéreo, etc.
Diferencia entre Proceso y Producto:
El proceso son las actividades que se realizan y el producto es el resultado de esas actividades.
Ejemplo: La receta de cómo hacer una torta sería el detalle del proceso. La torta es el producto.
De la misma manera el Proceso de software describe que actividades deberán hacerse para obtener
un producto de software.
B.5.3. Participantes en el Desarrollo de Sistemas
En el desarrollo de un proyecto participan distintos actores que cumplen diferentes roles. El desa-
rrollo eficaz de sistemas requiere un esfuerzo de grupo. Este equipo, llamado grupo de desarrollo, se
encarga de establecer los objetivos del sistema de información y generar un sistema (software) que
satisfaga tales objetivos para la organización. En el grupo de desarrollo de sistemas se pueden enu-
merar los siguientes roles:
PARTICIPANTES DESCRIPCIÓN
Usuarios Son las personas que interactuarán con el sistema en forma regular. A quie-
nes estará destinado el software
Analista Funcional
Es un profesional encargado de analizar las necesidades funcionales que
deberá satisfacer el software.
Arquitecto de Software Es el responsable de la arquitectura del sistema: Define la plataforma en la
cual se realizará el desarrollo, la tecnología a utilizar, la estructura interna
del proyecto de desarrollo.
Líder de Proyecto Es el encargado de asignar tareas a los programadores y monitorear el ac-
cionar de los mismos.
Universidad Nacional de La Matanza Departamento: Ingeniería e Investigaciones Tecnológicas
Cátedra: Fundamentos de TIC’s
Introducción a Sistemas de Información Página 32 de 71
Programador Se encarga de modificar o desarrollar programas para satisfacer las necesi-
dades de los usuarios.
Tester (Probador)
Se encarga de realizar el testing (testeo ó prueba), es indispensable a fin de
asegurar cierto grado de calidad del producto software.
Se recomienda que las pruebas sean realizadas por personas distintas a los
programadores del software. Los tipos de pruebas existentes son:
Caja Negra: No se inspecciona el código fuente el control se realiza con
lotes de datos a través de la interface del producto
Caja Blanca: Se inspecciona el código fuente en búsqueda de defectos
Implementador Pone en funcionamiento el producto final en el destino. Se encarga de: Con-
figuración de equipos, Instalación del Software, etc.
B.5.4. Inicio del Desarrollo de Sistemas
Las actividades de desarrollo de sistemas empiezan cuando un individuo o grupo con la capacidad
de iniciar cambios en la organización perciben un posible beneficio de un sistema nuevo o modifi-
cado. Ellos tienen interés en el desarrollo del sistema.
No obstante lo anterior, reviste igual importancia la capacidad del individuo o grupo para iniciar el
cambio organizacional. Muchas personas no son capaces de iniciarlo. Ello podría deberse no a que
carezcan de motivación para hacerlo, sino a limitaciones de jerarquía, poder, autoridad y posición
política en la organización.
Posibles razonespara iniciar el CAMBIO
Problemas
con el sis-
tema exis-
tente
Aprovechar
nuevas oportu-
nidades
Competencia
creciente
Emplear más
eficazmente
la informa-
ción
Crecimiento
organizativo
Fusión o
adquisición
Cambio en
el mercado
o entorno
de negocios
Iniciar proceso de desarrollo
de sistemas
B.6. Ingeniería del Software El desarrollo de sistemas se encuentra dentro de la Ingeniería del Software se ocupa de todo lo re-
ferente a la planificación, construcción y mantenimiento del software, aportando metodologías,
herramientas y principios para que ese producto (SW) sea confiable, eficiente y relevante.
Dentro de la ingeniería del software uno de los conceptos importantes de los cuales se deberá co-
nocer es el ciclo de vida del software.
Universidad Nacional de La Matanza Departamento: Ingeniería e Investigaciones Tecnológicas
Cátedra: Fundamentos de TIC’s
Introducción a Sistemas de Información Página 33 de 71
B.7. Ciclos de Vida y Desarrollo de Sistemas de Información
A continuación se ofrecen dos definiciones de ciclo de vida3:
Ambas definiciones consideran:
Una actividad como un conjunto de tareas
Una tarea como una acción que transforma entrada en salida
El software deberá poder cumplir con los objetivos para los cuales fue creado, dicho en otras pala-
bras cumplir con las expectativas y necesidades de los usuarios.
Ejemplo: Si lo comparamos con otro producto, por ejemplo un celular, este como primer objetivo
deberá poder “realizar llamadas a otros teléfonos”. Ahora bien, si además puede: Sacar fotos con
alta resolución, Conectarse a internet y Reproducir música, será mejor aún, pero su objetivo pri-
mero deberá cumplirlo ya que fue creado con ese fin.
Se define al software de computadoras como un producto y como tal tiene una determina vida útil.
Haciendo nuevamente una analogía con un teléfono celular, se recuerda el primer modelo de celular
llamado el ladrillo, que si bien todavía funciona se ha vuelto obsoleto.
Se puede hablar de un ciclo de vida en todos los seres vivos: se desarrolla, vive, crece. Así también
en un sistema de información SI (o producto software): existe un desarrollo (se hace), uso (vive),
luego pueden surgir nuevas necesidades en las cuales el SI sufrirá una modificación para que cum-
pla con esas nuevos requerimientos, (en este punto se habla que se generan nuevas versiones del
producto -crece).
B.8. Etapas del Proceso de Desarrollo (Ciclo de Vida)
A medida que se crea cada sistema, el proyecto tiene calendarios y fechas límite, hasta que por
último se instala y acepta. La vida del sistema continúa con su mantenimiento y revisión. Se inicia
un nuevo proyecto si el sistema requiere mejoras significativas, que van más allá del alcance de su
mantenimiento, si es necesario reponerlo a causa de una nueva generación de tecnología, o las nece-
sidades del SI (Sistema de Información) de la organización cambian en forma importante. Los pasos
o etapas comunes en todos los desarrollos son:
3 Las definiciones han sido traducidas por Lic. Armando David Espinoza Robles, el cual ha publicado un trabajo en el
2008 denominado “El ciclo de vida del Software”. En él se pude profundizar sobre este tema.
“Un marco de referencia que contiene los procesos, actividades y las tareas invo-
lucradas, en el desarrollo, la explotación y el mantenimiento de un producto
Software, abarcando la vida del sistema desde la definición de los requisitos has-
ta la finalización de su uso” (ISO 12207-1) .
“Una aproximación lógica a la adquisición, el suministro, el desarrollo, la explo-
tación y mantenimiento del Software” (según norma IEEE 1040).
Universidad Nacional de La Matanza Departamento: Ingeniería e Investigaciones Tecnológicas
Cátedra: Fundamentos de TIC’s
Introducción a Sistemas de Información Página 34 de 71
ETAPA CARACTERÍSTICAS
Investigación
¿Tengo el Dinero, la tecno-
logía y los recursos?
FACTIBILIDAD
En esta etapa se buscan los requerimientos del sistema, es decir, se identi-
fican los posibles problemas y oportunidades, y se consideran a la luz de
los objetivos de la empresa. Se realiza un estudio de factibilidad.
Análisis
¿Qué debe hacer el sistema?
REQUERIMIENTOS
Esta fase incluye el estudio de los sistemas y procesos de trabajo existen-
tes para identificar puntos fuertes y débiles, así como oportunidades de
mejoramiento. Se obtienen los requerimientos que deberán cumplirse
Esto es, ¿Qué se necesita?
Diseño
¿Cómo lo hago?MODELOS
Se diseña el sistema, se construyen modelos. Se plantea ¿Cómo se con-
cretará el objetivo?
Desarrollo
Concreto el Diseño
PROGRAMAS
En esta etapa se construye el sistema a partir de la mejor solución encon-
trada en la etapa de Diseño.
Pruebas e Implementación
Pruebo si el sistema anda.
PRUEBAS
En esta etapa se realiza las pruebas ó “testing” del sistema, esto es, la
prueba de cada componente del mismo hasta llegar a una integración total.
Esta etapa consiste en la validar el desarrollo realizado.
Mantenimiento y revisión
Corrijo
Mejoro
Actualizo
Esta es la etapa más extensa en la vida de un software.
Es garantizar la operación del sistema y modificarlo, de modo que contin-
úe cubriendo las necesidades cambiantes de la empresa.
Implica el mantenimiento del software, que puede ser:
reparar fallas del software (corregir errores inadvertidos durante el
proceso),
adaptar el software a diferentes entornos operativos (funcionalidades
que mejoran la performance del sistema) y
agregar o modificar la funcionalidad del sistema (actualización del
sistema a los nuevos cambios).
Esto es, mantener, actualizar y mejorar el sistema.
Dentro de cada una de las etapas del desarrollo de software, se deberán realizar las siguientes
actividades.
Universidad Nacional de La Matanza Departamento: Ingeniería e Investigaciones Tecnológicas
Cátedra: Fundamentos de TIC’s
Introducción a Sistemas de Información Página 35 de 71
Un aspecto básico en el desarrollo de un sistema es que entre más avanzado esté en el momento de
la detección de un error, será más costosa su corrección. Una razón para ello es que la identifica-
ción de un error en una fase avanzada obliga a modificar, hasta cierto punto, las fases previas. Otra
razón es que los errores detectados en una etapa más avanzada, tienen efecto en más personas. Por
ejemplo, un error identificado después de instalar un sistema puede requerir el readiestramiento de
los usuarios, toda vez que se cuente con la "solución" del problema. Así pues, los desarrolladores
experimentados de sistemas prefieren un método que detecte errores en una etapa temprana del pro-
ceso de desarrollo del proyecto.
•Análisis de Factibilidad. Desde el punto de Vista....
•Económico
•Técnico
•Operativo
Investigación. ¿Es Posible?
•Definir el o los tipos de usuarios del sistema.
•Definir las necesidades. El usuario explica cuales son sus expectativas.
•Definir requisitos. El analista deberá definir con precisión los requerimientos del sistema. QUE hará el sistema.
•Definir métodos. el analista definira los metodos apropiados para cumplir esos requerimientos.
Análisis. ¿QUE?
•Definir como hará el sistema lo que se definió en el análisis
•Se definen y diseñan las estructuras de datos, arquitectura del SW, representaciones de las interfaces y detalle de las funciones del sistema.
•Se divide en módulos (Modularidad)
•Utilización de Herramientas de diseño y modelado.
Diseño. ¿COMO?
•Se traduce el diseño en código de programación que la máquina entienda.
•Se utilizan Herramientas para mostrar el flujo lógico de los programas.
•Se realiza la Codificación
Implementación Lo Hago
•Pruebas de caja negra
•Pruebas de caja blanca
•Pruebas de unidad. (se prueba cada componente de software).
•Pruebas de integración. (se van integrando los módulos hasta el sistema total)
•Pruebas con el usuario.
Prueba Funciona?
•Corrijo, Mejoro, Actualizo
•Las modificaciones generarán nuevas versiones en el software.
•Las modidficaciones deberán pasar por "Analisis, diseño, desarrollo y prueba".
Mantenimiento y Revisión. Nuevas Necesidades
Universidad Nacional de La Matanza Departamento: Ingeniería e Investigaciones Tecnológicas
Cátedra: Fundamentos de TIC’s
Introducción a Sistemas de Información Página 36 de 71
A continuación se explican cada una de las etapas con mayor detalle.
B.8.1. Investigación
En ésta etapa se realiza un estudio de factibilidad. Aquí se estima si la rea-
lización del software es factible. Si es posible o realizable desde el punto
de vista económico y de la tecnología.
Se estiman si las necesidades de los usuarios se pueden realizar o satisfa-
cer con las tecnologías actuales de software y de hardware. El estudio dará
La detección de un error será mayor cuánto más avanzado esté el desarrollo del
Sistema.
Desarrollo Investigación Análisis Diseño Puesta en
operación
Mantenimiento
y revisión
Tiempo
Costo de realizar un
cambio específico
Entre más tardíos sean los cambios mayor será su costo
QUE COMO
Mayor
Costo
menor
costo
QUE? COMO?
Universidad Nacional de La Matanza Departamento: Ingeniería e Investigaciones Tecnológicas
Cátedra: Fundamentos de TIC’s
Introducción a Sistemas de Información Página 37 de 71
como resultado el costo del sistema y de acuerdo a esto si es posible realizarlo con el presupuesto
que se tiene.
Este estudio deberá ser rápido y económico, y es de suma importancia para tomar la decisión de
seguir con el proyecto (siguiente etapas, análisis, diseño, etc) o no.
Consiste en realizar un estudio de factibilidad ¿Es posible realizar el sistema solicitado?.
Este estudio incluye tres aspectos: Técnico, Político y Económico.
Estas etapas no son exclusivas al desarrollo de un sistema informático, pueden
ser aplicadas o otros tipos de sistemas sin requerir modificaciones. Supongamos
un Ingeniero Civil a quién se lo contrata para realizar un edificio de 15 pisos.
Investigar si es Factible (o posible) la propuesta desde el punto de Vista……
B.8.2. Análisis
En el análisis se deberán adquirir (elicitar) los requerimientos del sistema a desarrollar. Un requeri-
miento es una necesidad documentada sobre el contenido, forma o funcionalidad de un producto,
servicio o sistema. En ésta etapa deberá quedar claro y verificado por el usuario:
¿Qué debe hacer el sistema?
¿Qué cosas hará el sistema y que cosas no hará?
Económico
• ¿El importe a recibir, permite financiar el proyecto (la obra)?
• Materiales requeridos, contratación de presonal, etc.
Político
• ¿Hay alguna normativa que impida la realización del proyecto ? (la construcción del edificio en la zona)
Técnico
• ¿Existe la tecnología para realizarlo?
• Ejemplo: el suelo podría no ser apto para soportar el peso total de la edificación construida. Existen técnicas o materiales para construirlo a pesar de eso?
Estudio de Factibilidad: Estudio que se realiza para decidir si es factible o posible
realizar el producto software. Se estudiará desde lo económico y técnico.
Universidad Nacional de La Matanza Departamento: Ingeniería e Investigaciones Tecnológicas
Cátedra: Fundamentos de TIC’s
Introducción a Sistemas de Información Página 38 de 71
¿Qué usuarios interactúan con el sistema?
Establecen QUÉ debe hacer el sistema, pero NO CÓMO hacerlo.
Los requerimientos se utilizan como datos de entrada en la etapa de diseño del producto, servicio o
sistema. Razón por la cual se busca exhaustivamente los requerimientos y luego se validan (se veri-
fican con el usuario), porque luego con esos Que, que se han obtenido, se buscará en la etapa de
diseño, el Como se hace. Si no se tiene claro que cosas deberá hacer el sistema, mal se podrá llevar
a cabo la tarea de definir como hacerlas.
La obtención de los requerimientos de un sistema comprende todas las tareas relacionadas con la
determinación de las necesidades o de las condiciones a satisfacer por el sistema.
Una colección de requerimientos describe las características o atributos del sistema deseado. Es in-
dispensable la participación de los usuarios y clientes (interesados o stakeholders: todos los interesa-
dos deberían estar involucrados al proyecto) para la identificación de los requerimientos del sistema.
Los analistas pueden emplear varias técnicas para obtener los requisitos del sistema. Algunas de
esas técnicas son: las encuestas, las entrevistas, los cuestionarios y la observación. Técnicas más
modernas incluyen los prototipos, y utilizan casos de uso. Cuando sea necesario, el analista emple-
ará una combinación de estos métodos para establecer los requisitos exactos y de ese modo, produ-
cir un sistema que resuelva las necesidades del cliente. La figura que se muestra a continuación pre-
senta el proceso de obtención de requerimientos.
Etapas necesarias para poder realizar un Análisis
B.8.2.1. Técnicas para la Obtención de Requerimientos
ENCUESTA
Es una herramienta que nos permite recolectar información sobre un tema
en particular, pero por si sola no es de utilidad, sino que los datos que se
recolectaron deben ser sometidos a cierto proceso de tratamiento de datos
para que puedan convertirse en información útil para la detección de nece-
sidades y requerimientos en el sistema a desarrollar.
La encuesta no es un método específico, se aplica al estudio e investigación en muchos campos del
conocimiento, y es empleada en aquellos casos en los que la información que se necesita, no puede
hallarse u obtenerse a través de otras fuentes. Por otra parte, tiene la particularidad de depender de
que las personas elegidas para ser entrevistadas puedan (no se requiera métodos especiales de medi-
ción), y quieran (no incrimine o reprima) proporcionar la información que les es requerida; no obs-
Comprender Problema
Recolectar Información
Definir Límites
Identificar Usuarios
Recolectar Requerimientos
ANÁLISIS
Universidad Nacional de La Matanza Departamento: Ingeniería e Investigaciones Tecnológicas
Cátedra: Fundamentos de TIC’s
Introducción a Sistemas de Información Página 39 de 71
tante si el entrevistador procede con habilidad y tacto la generalidad de los casos indica una gran
tolerancia a las preguntas realizadas aún en las que posean carácter personal.
Las encuestas varían fundamentalmente en su alcance, diseño y contenido, debiéndose determinar
dichas características a partir de los objetivos básicos. El universo de la encuesta permite definir el
tipo de población sobre el que se realizará la encuesta. Pueden ser universos de las encuestas la po-
blación nacional, áreas geográficas dentro de un país si la encuesta requiriera un análisis regional
especial, o la representación de provincias, distritos o ciudades específicas. La estructura de la en-
cuesta permite utilizar diversos tipos de preguntas, para facilitar la obtención de la información, estas
deben poseer un orden lógico y estar relacionadas entre sí.
ENTREVISTA
Consiste en un encuentro presencial, en vivo, frente a frente con la persona especia-
lizada (Persona que realiza una tarea específica o quién encarga el sistema). Por lo
general no se entrevista a toda la gente que se relacionará con el sistema, sino a una
selección de personas que represente a todos los sectores críticos, con el énfasis
puesto en los sectores más afectados o que harán un uso más frecuente del nuevo
sistema. Las entrevistas pueden ser personales o grupales.
En el planeamiento de una entrevista los pasos principales de la preparación son:
Establecer los objetivos de la entrevista
Decidir a quién entrevistar
Preparar a la persona a entrevistar
Decidir los tipos de preguntas y la estructura.
CUESTIONARIOS
Otro de los métodos que suele ayudar en los casos en los que un encuentro pre-
sencial sea imposible, es el envío de un cuestionario escrito, constituido por un
conjunto de preguntas, que se deberá completar y devolver.
Todas las consideraciones realizadas para la entrevista son válidas para los cues-
tionarios enviados por correo. En ellos, no existe la presencia del encuestador, lo que deriva en una
serie de ventajas y desventajas.
El envío postal del cuestionario requiere ciertas precauciones: la distribución debe ser hecha en con-
junto y dentro de un lapso relativamente breve. Se debe indicar el plazo para que sea devuelto.
OBSERVACIÓN
La observación permite al analista ganar información que no se puede obtener por otras técnicas.
Por medio de la observación el analista obtiene información de primera mano sobre la forma en que
se efectúan las actividades. Este método es más útil cuando el analista necesita observar, por un
lado, la forma en que se manejan los documentos y se llevan a cabo los procesos y, por otro, si se
siguen todos los pasos especificados. Los observadores experimentados saben qué buscar y cómo
evaluar la significancia de lo que observan.
La etnografía es una técnica de observación que se puede utilizar para entender requerimientos. El
analista se involucra como observador en el entorno laboral donde se implementará el sistema. Se
observa como se trabaja día a día, se toman notas y se inspecciona documentación.
Universidad Nacional de La Matanza Departamento: Ingeniería e Investigaciones Tecnológicas
Cátedra: Fundamentos de TIC’s
Introducción a Sistemas de Información Página 40 de 71
La ventaja más importante de ésta técnica es que se ponen al descubierto requerimientos de proce-
sos que de otra manera sería difícil de descubrir (Requerimientos Implícitos, que están sobrentendi-
dos.) Suelen surgir o salir a la luz procedimientos, detalles que son tan cotidianos que ni siquiera la
persona que los realiza en ocasiones suele darse cuenta o los puede explicar con claridad).
B.8.3. Diseño
Para diseñar un sistema es habitual el tener que recurrir a modelos. Un modelo de procesos de soft-
ware es una descripción de un proceso software que se presenta desde una perspectiva particular.
Por su naturaleza, los modelos son simplificaciones, por lo tanto un modelo de procesos del softwa-
re es una abstracción de un proceso real.
El término “modelo” parece algo formal, pero representa un concepto que se maneja durante la ma-
yor parte de la vida. Ejemplos de modelos son los siguientes:
Mapas: modelos bidimensionales del mundo en que vivimos. Globos terráqueos: modelos tridimensionales de nuestro mundo.
Diagramas de flujo: representaciones esquemáticas de las decisiones y la secuencia de acti-vidades para llevar a cabo un determinado procedimiento.
Dibujos arquitectónicos: representaciones esquemáticas de un edificio, o de un puente, etc.
Partituras musicales: representaciones gráficas y textuales de notas musicales y tiempos de una pieza musical.
¿Por qué se construyen modelos? ¿Por qué no se construye simplemente el sistema mismo? La res-
puesta es que se pueden construir modelos de manera tal de enfatizar ciertas propiedades críticas del
sistema, mientras que simultáneamente se desprecian otros de sus aspectos. Esto permite comuni-
carse con el usuario de una manera enfocada, sin distraerse con asuntos y características ajenas al
sistema. Y si la comprensión de los requerimientos del usuario no fue la correcta (o de que el usua-
rio cambió de parecer acerca de sus requerimientos), se pueden hacer cambios en el modelo o des-
echarlo y hacer uno nuevo, de ser necesario.
Podemos decir que un modelo es una representación de la realidad. Se realizan por medio de abs-
tracciones. Cuando mayor semejanza con la realidad tenga un modelo, mejor representará esa reali-
dad la cual se desea significar. Existen diferentes modelos, los cuáles se enfocan a diferentes partes
de un sistema. Son diferentes vistas de una misma situación.
Por ejemplo: si se tiene que representar una casa, un plano de la misma sería un modelo. Para esto
podríamos tener diferentes planos que representen distintas vistas.
Plano de estructura: se verá representada la estructura de la casa con elemen-
tos tales como: paredes, tabiques, puertas, ventanas, etc. Este plano o modelo le
será útil a las personas que construyen la estructura (albañiles, capataz)
Plano de electricidad: se representará un modelo de toda la parte eléctrica de la
casa. Cables, interruptores, etc. Modelo a realizar o desarrollar por los electri-
cistas.
Plano de instalaciones sanitarias (Hídrico-sanitarios): se verán representados los elementos como
caños, red de desagüe y drenaje, rejillas, etc. Los plomeros serán los que deberán realizar su trabajo
de plomería siguiendo éste modelo.
Modelo: Es una representación de la realidad.
Modelo de Procesos del Software: es una abstracción de un proceso real.
Universidad Nacional de La Matanza Departamento: Ingeniería e Investigaciones Tecnológicas
Cátedra: Fundamentos de TIC’s
Introducción a Sistemas de Información Página 41 de 71
Para no confundirnos:
B.8.3.1. Paradigma
Como primera medida, es importante saber qué es un paradigma, para decidir que paradigma se
empleará a la hora de diagramar y desarrollar un software. Los paradigmas son un marco o pers-
pectiva bajo la cual se analizan los problemas y se trata de resolverlos. Se puede ver a un paradig-
ma como un modelo que sirve de norma, brinda marcos de referencia que dice qué es lo que se pue-
de hacer y con qué elementos se cuenta.
Ejemplo: si tomamos como ejemplo el paradigma de como ver el Planeta Tierra en el Sistema Solar
y el Universo.
En la antigüedad, más precisamente en China, se creía que la tierra estaba sostenida por cuatro ele-
fantes sobre una tortuga.
Antes de la venida de Cristóbal Colón a América, existía el paradigma Geocéntrico, se creía que la
Tierra era el centro del Universo.
A partir de Cristóbal Colon hubo un cambio de Paradigma hacia el paradigma Heliocéntrico, donde
el Sol es el centro de nuestro sistema solar y todos los planetas incluía la Tierra giran en torno a Él.
Cambio la manera de percibir a la Tierra en el universo y respecto de los otros planetas.
Paradigma Geocéntrico Paradigma Heliocéntrico
La tarea de un equipo de desarrollo de software es crear la ilusión de la simplicidad.
La arquitectura de un sistema complejo es función de sus componentes así como de las relaciones
jerárquicas entre éstos.
Los sistemas complejos pueden ser estudiados y desarrollados desde dos perspectivas:
Análisis
¿QUÉ debo hacer? Diseño
¿CÓMO lo debo hacer?
Abstracción: Proceso mental o intelectual que se realiza para representar y seleccionar
características y propiedades de determinadas cosas del mundo real. Es una representa-
ción mental de la realidad que se desea representar.
Un paradigma es una forma de percibir la realidad.
Universidad Nacional de La Matanza Departamento: Ingeniería e Investigaciones Tecnológicas
Cátedra: Fundamentos de TIC’s
Introducción a Sistemas de Información Página 42 de 71
• Objetos (Paradigma Orientado a Objetos. POO)
• Procesos (Paradigma Estructurado)
B.8.3.2. Modelar por Medio de Diagramas
Existen diversos diagramas los cuales contribuyen a modelar un problema en la etapa de diseño. El
diseñador del sistema tendrá que prever si es conveniente modelar el sistema bajo el paradigma
orientado a objetos (POO) o bien bajo el Paradigma Estructurado.
B.8.3.3. Paradigma Estructurado
Este paradigma se ocupa de plantear las funciones y procesos que realizará el sistema y la forma en
que se llevarán a cabo.
Requiere traducir el dominio (realidad) del problema en una serie de funciones. El analista debe
comprender primero el dominio del problema y a continuación documentar las funciones que debe
proporcionar el sistema.
El paradigma estructurado tiene en cuenta la entrada, el proceso y la salida. Los datos y los procedimientos están separados y sin relación, ya que lo único que se busca es el
procesamiento de unos datos de entrada para obtener otros de salida. En la programación estructu-
rada sólo se escriben funciones que procesan datos.
La idea principal de esta forma de programación es separar las partes complejas del programa en
módulos. De esta manera se tiene un diseño modular compuestos por módulos independientes que
pueden comunicarse entre sí.
En el Paradigma estructurado el código se divide en bloques, estructuras, que pueden o no comuni-
carse entre sí. Este software se controla con secuencia, selección e iteración.
El código generado es más entendible, estructurado, modular, reusable y adaptable. A la larga pro-
duce código de gran calidad y reduce tiempos y costos.
Los diagramas más utilizados son:
Diagrama de Flujo de Datos
Diagramas de Entidad-Relación
Diagrama de Transición de Estados.
B.8.3.4 Diagrama de Contexto / Diagrama de Flujo de Datos (DFD)
El diagrama de contexto, muestra bajo un nombre general, el proceso que se realizará (Sistema de
Asistencias) y quiénes son los actores involucrados (Alumnos y Profesores).
Paradigma de Diseño
EstructuradoOrientado a
Objetos.
Universidad Nacional de La Matanza Departamento: Ingeniería e Investigaciones Tecnológicas
Cátedra: Fundamentos de TIC’s
Introducción a Sistemas de Información Página 43 de 71
Luego se podrá profundizar modelando subprocesos los cuales señalen de qué forma se llevará a
cabo el SISTEMA DE ASISTENCIAS. Para ello se recurre a un DFD, tal como el que se muestra a
continuación.
Es posible continuar haciendo DFD estallando las burbujas de cada uno de los procesos, hasta que
sea sencillo entender cómo se efectuará cada uno de los procesos. De esta forma puede verse al dia-
grama de contexto como un DFD de nivel inicial con una única burbuja.
En cada nivel del DFD si es necesario se toma una burbuja del nivel 1 y se explota.
Elementos de diagrama
Burbujas (procesos): Las diversas funciones individuales que el siste-
ma lleva a cabo.
Líneas paralela u Óvalos (agregado de datos): Muestran colecciones de datos (archivos) que el sistema debe recordar por un período de tiempo.
Rectángulos (terminadores): Muestran las entidades externas con las que el sistema se comunica.
Flechas curvas (flujo de datos): Son las conexiones entre los procesos y representan la información de entrada o salida de los mismos.
B.8.3.5. Herramientas Adicionales
Todo DFD suele estar acompañado por un Diccionario de Datos y una Especificación de Procesos.
Diccionario de datos (DD): Herramienta textual la cual muestra qué información se transforma.
Universidad Nacional de La Matanza Departamento: Ingeniería e Investigaciones Tecnológicas
Cátedra: Fundamentos de TIC’s
Introducción a Sistemas de Información Página 44 de 71
Cuando en un DFD desde el CLIENTE hacia un proceso dice NOMBRE deberá explicarse por me-
dio de un DD que es lo que incluye el nombre. A continuación se muestra un ejemplo.
Nombre = Tratamiento de cortesía o título + nombre + apellidos
Tratamiento de cortesía o título = [Sr. / Srta. / Sra. / Dr. / Prof. ]
Nombre = {carácter válido}
Apellido = {carácter válido}
Carácter válido = [A-Z / a-z / „ / - / /]
Especificación de Procesos (EP): se utiliza para explicar en lenguaje coloquial como se lleva a
cabo un proceso (como se efectúa cada uno de los procesos que han quedado señalados en el último
DFD realizado, es decir habrá una especificación de proceso por cada una de las burbujas). Es por
eso que una EP muestra cómo se transforma la información. A continuación se presenta un ejemplo.
1. Si el monto en dólares de la factura multiplicado por el número de semanas de retraso en el
pago rebasa los 10.000 dólares
ENTONCES:
a. Proporcionar una fotocopia de la factura al encargado de ventas que llamará al clien-
te.
b. Anotar en el reverso de la factura que se le dio una copia al vendedor, junto con la
fecha en la que se hizo esto.
c. Volver a archivar la factura para estudiarla de nuevo dentro de dos semanas.
EN CASO CONTRARIO: d. Dar una copia de la factura al vendedor apropiado para que llame al cliente.
e. Registrar en el reverso de la factura que una copia ha sido enviada al vendedor, y la
fecha en la que se hizo esto.
f. Volver a archivar la factura para reexaminarla dentro de una semana.
B.8.3.6. Diagrama de Entidad-Relacion (DER)
Modela la relación que existe entre los agregados o datos. Consiste en:
Entidades: Representa una colección o conjunto de objetos (cosas) del mundo real cuyos
miembros juegan algún papel en el desarrollo del sistema. Pueden además ser identificados de
manera única y ser descritos por uno o más atributos.
Atributos: definen las propiedades o características de un elemento de datos. Uno ó más atri-
butos se definen como identificar o clave. De ésta manera, este o estos atributos identificarán
de manera unívoca (sin equivocarse), toda la instancia o ocurrencia de la entidad.
Relaciones: Son la serie de conexiones o asociaciones entre los tipos de objetos que están co-
nectados con la relación por medio de flechas.
Elementos:
Rectángulo (entidad)
Rombos (relaciones)
Líneas (conectores de los elementos básicos: rectángulos y rombos)
Universidad Nacional de La Matanza Departamento: Ingeniería e Investigaciones Tecnológicas
Cátedra: Fundamentos de TIC’s
Introducción a Sistemas de Información Página 45 de 71
CLIENTE
PEDIDO
FACTURA
LIBRO DECONTABILI-
DAD
coloca
recibe
especifica
Por ejemplo: la entidad CLIENTE se conecta con la entidad FACTURA, esa conexión es la rela-
ción. Se puede pensar que el cliente recibe una factura.
B.8.3.7. Diagrama de Transición de Estados (DTE)
Describe el comportamiento del sistema dependiente del tiempo, evaluando las condiciones con la
cual se cambia de estado y las acciones pertinentes para lograrlo.
Los principales componentes del diagrama de estados, son los estados, y las flechas que representan
los cambios de estado. Los estados se pueden representar tanto por rectángulos como por óvalos. En
éste libro se representará con rectángulos.
Se puede definir un “estado”, como un conjunto de circunstancias o atributos que caracterizan a una
persona o cosa en un tiempo dado; forma de ser, o condición.
Ejemplo de estados:
ESTADOS Significado
Esperando Ingreso de contraseña.
Despliega Página de usuario
Frenado / acelerando Referido a un motor
Rojo / amarillo / verde Estados de un semáforo
Abierta / cerrada Una barrera, la inscripción a un curso…
Elementos:
Rectángulo (estado)
Flechas (cambio de estado)
A continuación se muestra un DTE a modo de ejemplo, el cual pone en evidencia el funcionamiento
de un lavarropas.
Universidad Nacional de La Matanza Departamento: Ingeniería e Investigaciones Tecnológicas
Cátedra: Fundamentos de TIC’s
Introducción a Sistemas de Información Página 46 de 71
INACTIVO
comenzar, alto,
alto,lavadora llena,
ciclo de lavado concluído,
ciclo de secadoconcluído,
habilitar el “llenado” deshabilitar el“llenado”
deshabilitar el“lavado”
habilitar el “lavado”
habilitar el “secado”centrífugo
LLENADO
LAVADO
Otro ejemplo: Diagrama de Transición de Estados: Inscripción a una materia.
Hay ocasiones en que se deberán realizar anotaciones adicionales en el diccionario de datos respec-
to de determinadas restricciones (de acuerdo a la manera de interactuar con el sistema).
B.8.3.9. Construcción de Prototipos
Universidad Nacional de La Matanza Departamento: Ingeniería e Investigaciones Tecnológicas
Cátedra: Fundamentos de TIC’s
Introducción a Sistemas de Información Página 47 de 71
Un prototipo es una versión inicial de un sistema de software que se utiliza para demostrar los
conceptos, probar las opciones de diseño y, de forma general, enterarse más acerca del problema
y las posibles soluciones. Si bien los prototipos suelen construirse en la etapa de diseño, estos
pueden realizarse al principio de la misma para verificar los requisitos de la etapa de análisis ó
bien para visualizar la opción de diseño seleccionada. En algunos casos los prototipos podrán
irse mejorando e incluso (en algunos casos convertirse en el producto final, sistema final). A
continuación se clasifican a los prototipos.
B.8.3.10. Paradigma Orientado a Objetos (POO)
Se vive en un mundo de objetos. Estos objetos existen en la naturaleza, en entidades hechas por el
hombre, en los negocios y en los productos que usamos. Ellos pueden ser clasificados, descritos,
organizados, combinados, manipulados y creados. Por esto no es sorprendente que se proponga una
visión orientada a objetos para la creación de software de computadora, una abstracción que modela
el mundo de forma tal que nos ayuda a entenderlo y gobernarlo mejor. Es así como a medida que se
vayan incorporando detalles más finos, se estará ingresando a niveles de mayor complejidad y al
mismo tiempo se tendrá un nivel de abstracción menor. La abstracción de datos permite no pre-
ocuparse de los detalles que no sean esenciales. Existe en casi todos los lenguajes de programación.
El paradigma orientado a objetos (POO) brinda un marco para la construcción de programas y esta-
blece a los objetos como únicos elementos del paradigma, es decir, que todo es un objeto o puede
ser representado como tal, considerando al mundo como una colección de objetos significativos que
colaboran para obtener un comportamiento de alto nivel.
Es una forma de pensar acerca de un problema en términos del mundo real en vez de en términos de
una computadora. El POO permite analizar mejor el dominio (realidad) del problema, sin pensar en
términos de implementar el sistema en una computadora.
La programación orientada a objetos o POO (OOP según sus siglas en inglés) es un paradigma de
programación que usa objetos y sus interacciones, para diseñar aplicaciones y programas informáti-
cos. Los programadores que emplean POO, primero definen objetos. Cada objeto juega un rol en la
solución del problema. Cada objeto proporciona un servicio o realiza una acción que es posterior-
mente utilizada por otros miembros de la comunidad.
La POO se basa en dividir el programa en pequeñas unidades lógicas que son los objetos, los cuales
se comunican entre ellos mediante mensajes.
Un programa está representado por un conjunto de objetos que colaboran entre sí para realizar una o
más tareas.
En POO se utiliza un lenguaje común para modelar diagramas que representen un sistema.
El Unified Modeling Language (UML) define un lenguaje de modelado orientado a objetos común
para visualizar, especificar, construir y documentar los componentes de un sistema software OO.
CLASE
Una clase permite describir en un solo lugar el comportamiento genérico de un conjunto de objetos.
Las clases permiten pensar en un nivel de abstracción más alto. Una clase puede pensarse como un
molde para un tipo específico de objeto. Molde en el mismo sentido que al referirse al mecanismo
de fabricación, es decir, entendiendo a la clase como un medio para definir la forma de los objetos.
Una clase es responsable de crear objetos.
Clase: es un conjunto de objetos que comparten una estructura, un comporta-
miento y un significado común. [Booch]
Universidad Nacional de La Matanza Departamento: Ingeniería e Investigaciones Tecnológicas
Cátedra: Fundamentos de TIC’s
Introducción a Sistemas de Información Página 48 de 71
Las clases se comportan como fábricas, dado que crean nuevos objetos a partir de un molde. En-
tonces se tiene que las clases cumplen tres roles:
Agrupan el comportamiento común de las instancias (ob-
jetos) Definen las formas de estas instancias
Crean objetos que serán esas instancias
Cada clase se define por medio de tres componentes:
Nombre de la clase
Atributos ó Propiedades (características propias de la
clase)
Operaciones, Métodos o Servicios (que pueden reali-zarse en dicha clase)
Así se pueden citar algunos ejemplos de clases.
Para ejemplificar se define la clase PERSONA de la siguiente manera:
OBJETO
• Un objeto es una instancia de una clase.
• Una cosa tangible o visible. Ej: Persona, auto, casa, alumno, etc.
• Algo que puede comprenderse intelectualmente. Ej: Alumno, Cliente de un Comercio,
Amigo de Facebook.
• Algo que puede pensarse o ejecutarle una acción. Ej: Caja de Ahorro, Impuesto, Cuenta de
correo electrónico.
• Los objetos modelan una parte de la realidad, por lo tanto exis-
ten en tiempo y espacio o son creados dentro del diseño para co-
laborar con otros objetos.
Ejemplo:
Objeto: es un concepto del mundo real, que es generado por una clase.
PERSONA
Nombre _ Apellido
Sexo
DNI
Fecha_Nacimiento
Calcular_Edad ()
NOMBRE DE LA CLASE
ATRIBUTOS
METODOS U OPERACIONES
Universidad Nacional de La Matanza Departamento: Ingeniería e Investigaciones Tecnológicas
Cátedra: Fundamentos de TIC’s
Introducción a Sistemas de Información Página 49 de 71
Se tiene la Clase Automóvil con los siguientes atributos y métodos
Se pueden tener objetos tales como los que muestran a continuación:
Todos los objetos (ó instancias) que pertenecen a la clase Automóvil, tie-
nen los mismos atributos y métodos (u operaciones), esto es, por pertene-
cer a la clase.
Pero cada objeto se va a diferenciar de otro porque tiene una identidad
única. Cada atributo tendrá una ocurrencia diferente.
A continuación se observan 2 instancias u objetos de la clase “Auto-
móvil”
Obsérvese la diferencia entre las ocurrencias de los atributos de los dos objetos.
ABSTRACCIÓN
Ejemplo: Se tiene un objeto “Gato”, y se tienen dos usuarios, una Abuelita y una Dra. Veterinaria.
A cada uno de ellos le interesarán distintas características del objeto gato, porque tienen dos puntos
de vista diferentes del mismo objeto, (según cómo interactúan con él).
La Abuelita lo ve como su mascota mimada y la Veterinaria como a un paciente.
Objeto: Gato
Abstracción: permite enfocarse en las características esenciales de un objeto, según el punto
de vista del usuario.
Universidad Nacional de La Matanza Departamento: Ingeniería e Investigaciones Tecnológicas
Cátedra: Fundamentos de TIC’s
Introducción a Sistemas de Información Página 50 de 71
COLABORACIÓN
Ejemplo: los objetos Bibliotecario, Alumno, Asistente y Catálogo, colaboran para lograr el compor-
tamiento : Préstamo de un libro.
ENCAPSULAMIENTO
Cuando se habla de encapsulación se intenta ocultar todos los aspec-
tos,(además de datos y métodos), que un objeto encierra para realizar el con-
junto de responsabilidades para las cuales se ha creado.
Ejemplo: un auto oculta los detalles de cómo hace para “arrancar, moverse, frenar” (para mane-
jarlo no se necesita saber de mecánica).
Colaboración: Los objetos colaboran para lograr un comportamiento.
Encapsulamiento: oculta los detalles de implementación del objeto.
Universidad Nacional de La Matanza Departamento: Ingeniería e Investigaciones Tecnológicas
Cátedra: Fundamentos de TIC’s
Introducción a Sistemas de Información Página 51 de 71
Así mismo en una aplicación o sistema de inscripción de alumnos, el objeto “inscripción”, no mues-
tra los detalles de cómo ni con que realiza la responsabilidad de la “inscripción”.
“Si se tiene un sistema complejo, ninguna parte del mismo debería depender, de los detalles inter-
nos de otra de las partes”. Sólo a través de mensajes se pueden comunicar los objetos.
De ésta manera los cambios se realizan de manera fiable y con poco esfuerzo.
MODULARIDAD
Dividir en partes algo complejo para reducir esa complejidad.
Esta es la premisa de este concepto.
Como ya se ha visto anteriormente cuanto mayor sea esa di-
visión mayor será el número de conexiones o interfaces entre
los módulos.
JERARQUÍA
Un conjunto de abstracciones en ocasiones forman una jerarquía. Identificar esas jerarquías en el
diseño, ayudan a simplificar la comprensión del problema.
Ejemplo: un auto, tiene un motor, dentro del motor se encuentran las partes mecánicas que lo for-
man, esto es una manera de ordenar o rankear las abstracciones.
ESTADO
En el ejemplo anterior, un automóvil tiene en un momento dado un conjunto de valores. Como si
fuera una foto del objeto en algún momento determinado.
El estado de un objeto abarca todas las propiedades (normalmente estática) del objeto además de los
valores actuales (normalmente dinámico) de cada una de estas propiedades.
COMPORTAMIENTO
Es lo que el objeto puede hacer. ¿Qué hace?
Modularidad: divide un sistema en partes para ayudar a reducir la complejidad.
Jerarquía: Ordena por prioridades las abstracciones.
Comportamiento: Encierra los servicios que presta a otros objetos y las operacio-
nes que puede realizar. Sobre otros objetos y sobre sí mismo.
Estado: es el conjunto de valores de sus atributos en un momento dado (o instan-
te). Es el valor actual de los atributos.
Universidad Nacional de La Matanza Departamento: Ingeniería e Investigaciones Tecnológicas
Cátedra: Fundamentos de TIC’s
Introducción a Sistemas de Información Página 52 de 71
Los métodos y operaciones que puede realizar o servicios que puede
ofrecer.
El comportamiento de un objeto puede modificar el estado de este.
En el caso del Objeto Bibliotecario: Busca libros. Pide libros. Entrega
libros.
IDENTIDAD
HERENCIA
En la realidad que se desea modelizar, ocurre que existen objetos que tienen características y com-
portamientos comunes pero a la vez tienen algo diferente.
Por ejemplo, un vehículo puede ser aéreo o terrestre. Ambos son vehículos y tienen atributos y res-
ponsabilidades que pueden tener o realizar, por el hecho de ser vehículos. Pero existen atributos
propios de los aéreos (valor del altímetro), que no tienen los terrestres y responsabilidades que no
pueden realizar los terrestres como aterrizar y despegar.
Por ser un vehículo aéreo tendrá atributos tales como: nro de vehículo, color, nro de motor, valor
del altímetro, tren de aterrizaje (que puede estar en solo dos estados subido / bajado). Y puede reali-
Identidad: propiedad o atributo que permite al objeto diferenciarse o distinguirse
de todos los demás objetos, inclusive los de su misma clase.
Herencia: una subclase puede heredar la estructura y el comportamiento de su
superclase.
Herencia: una subclase puede heredar la estructura y el comportamiento de su
superclase.
Universidad Nacional de La Matanza Departamento: Ingeniería e Investigaciones Tecnológicas
Cátedra: Fundamentos de TIC’s
Introducción a Sistemas de Información Página 53 de 71
zar las siguientes operaciones: informar todos sus atributos (color, nro vehículo, altitud, etc), aterri-
zar, despegar.
Por otro lado un vehículo terrestre tendrá atributos como freno, cantidad de ruedas, cambios; y res-
ponsabilidades como ser: frenar, estacionar, poner un cambio, avanzar, etc.
Se podría realizar un modelo con una clase Vehículo (con los atributos comunes de los aéros y los
terrestres y las responsabilidades que ambos comparten). Luego una clase Aéreo y otra terrestre,
donde cada una tenga los atributos y responsabilidades propios de cada una.
En la siguiente imagen se refleja lo expuesto.
De ésta manera cuando la SubClase Aereo instancie o cree objetos; éstos HEREDARAN todos los
atributos y responsabilidades de su superclase (en este ejemplo en particular, de la clase Vehículo).
También la subclase Terrestre heredará los atributos y responsabilidades de la superclase Vehículo.
Esto mismo se puede observar en otro ejemplo: Al definir las clases se establece una jerarquía de
clases, siguiendo con el ejemplo anterior se definen las clases ALUMNO y DOCENTE
PERSONA es una SUPERCLASE y las clases ALUMNO y DOCENTE son SUBCLASES de la
misma. Es decir que ALUMNO y DOCENTE también son PERSONA. Las subclases HEREDAN
todos los atributos y métodos de la superclase (es decir que la clase “ALUMNO” posee sus propios
atributos: “Carrera”, “Fecha_ Ingreso”, “Cant_Materias_Aprobadas”, y método, “Calcu-
lar_Materias_Pendientes()”, pero también los que ha heredado de PERSONAS, es decir que además
le corresponden los atributos: “Nombre_ Apellido”, “Sexo”, “DNI”, “Fecha_Nacimiento” y el
método: “Calcular_Edad()”).
Para cada una de las clases definidas se construyen OBJETOS, los cuales pertenecen a dicha clase
y por lo tanto poseen los mismos componentes que la clase. Las clases definen la estructura y com-
portamiento y los objetos serán las instancias de la clase.
En la clase PERSONA el método Calcular_Edad() extrae la fecha de nacimiento almacenada en el
atributo Fecha_Nacimiento; para poder realizar el cálculo.
Universidad Nacional de La Matanza Departamento: Ingeniería e Investigaciones Tecnológicas
Cátedra: Fundamentos de TIC’s
Introducción a Sistemas de Información Página 54 de 71
MENSAJES
El comportamiento simboliza como el objeto actúa y reacciona de acuerdo a los cambios en su esta-
do y los mensajes que da o recibe.
Todo objeto de una clase tiene determinadas responsabilidades que debe cumplir. Está relacionado
con la funcionalidad que tiene el objeto y las operaciones o métodos que puede realizar. Estas ope-
raciones las realiza como respuesta a los mensajes enviados por otros objetos.
Este es el principio del encapsulamiento, un objeto envía un mensaje a otro objeto, este último rea-
liza una operación (sin que el otro sepa cómo lo realiza, el funcionamiento y las partes se encuen-
tran ocultas, encapsuladas para el exterior); luego da la respuesta a ese mensaje.
Ejemplo: El objeto Bibliotecario envía un Mensaje al objeto Asistente.
El Asistente le responde entregándole un libro (no se sabe, cómo hizo el asistente para encontrar el
libro, tal vez se tuvo que subir a una escalera, o agacharse, o recorrer varias estanterías, todas esas
acciones que se llaman métodos o servicios, están encapsuladas).
REUSABILIDAD
La reusabilidad del código es una de las ventajas del paradigma de objetos, diseño orientado a obje-
tos (DOO) y programación orienta a objetos (POO). Significa que los objetos (clases) se definen
para un sistema y pueden ser usados en otros. Para una mayor eficiencia en la reusabilidad es nece-
sario que los objetos sean diseñados o definidos con una buena métrica de diseño, bajo acoplamien-
to y alta cohesión.
Mensajes: Los objetos se comunican a través de mensajes. Los objetos realizan
acciones que se activan cuando otro objeto le envía un mensaje.
PERSONA
ALUMNO DOCENTE
Nombre _Apellido
Sexo
DNI
Fecha_Nacimiento
Calcular_Edad ()
Carrera
Fecha_Ingreso
Cant_Materias _Aprobadas
Calcular_Materias_Pendientes ()
Título_Habilitante
Materias_ Dicta
Num_Legajo
Subclases
Superclase
Universidad Nacional de La Matanza Departamento: Ingeniería e Investigaciones Tecnológicas
Cátedra: Fundamentos de TIC’s
Introducción a Sistemas de Información Página 55 de 71
B.8.4. Desarrollo
En esta etapa se construye el sistema a partir de la mejor solución encontrada en la etapa de Diseño, ya sea
por medio del Paradigma Estructurado o por medio del Paradigma Orientado a Objetos.
B.8.5. Pruebas (Testing).
En esta etapa se realiza las pruebas ó “testing” del sistema, esto es, la prueba de cada componente del mismo
hasta llegar a una integración total. Esta etapa consiste en la validar el desarrollo realizado.
El objetivo principal del testing es determinar si los productos que surgen como consecuencia de cada una de
las etapas anteriormente vistas, satisfacen con los requisitos especificados. Cabe recordar que se entiende por
Producto software: “A todos los programas desarrollados y la documentación asociada”.
Las pruebas tienen dos momentos:
Planificar las pruebas en etapas tempranas del proyecto de desarrollo.
Realizar las pruebas en etapa de prueba.
En la etapa de la planificación de las pruebas se pueden identificar las siguientes tareas:
Realizar el plan de pruebas
Hacer una lista para verificar requerimientos.
Diseñar los Casos de Prueba.
El objetivo de las pruebas es descubrir errores.
B.8.6. Mantenimiento y Revisión
Esta es la etapa más extensa en la vida de un software.
Es garantizar la operación del sistema y modificarlo, de modo que continúe cubriendo las necesidades cam-
biantes de la empresa.
Universidad Nacional de La Matanza Departamento: Ingeniería e Investigaciones Tecnológicas
Cátedra: Fundamentos de TIC’s
Introducción a Sistemas de Información Página 56 de 71
B.9. Documentación
Un sistema de software no servirá de mucho a menos que las personas puedan aprender a usarlo y
mantenerlo. Por tanto, la documentación es una parte importante del software.
En este apunte no se ha incluido a la documentación en una etapa particular del proceso de desarro-
llo de un software porque se considera que deberá irse construyendo a medida que se construye el
software (sobre todo la documentación técnica).
TIPO DE
DOCUMENTACIÓN
PROPÓSITO CARACTERÍSTICAS
Documentación del
usuario
Ser leída por el
usuario
Tiende a no ser técnica
Hace que el paquete sea accesible
Adopta la forma de manual: una parte presenta una intro-
ducción a las funciones más utilizadas, una sección de
cómo instalar el software y una sección que describe los de-
talles de cada función del software
Está disponible en forma de libro, pero en muchos casos se
proporciona como un archivo almacenado en el mismo me-
dio que el software
Documentación técnica
ó
Documentación del
sistema
Describir el
software en sí
para poder
mantener el
sistema en una
etapa posterior
de su ciclo de
vida
Es una documentación técnica en la cual se asientan los
requisitos del usuario, los distintos modelos que un analista
haya realizado, comentarios sobre la opción de diseño ele-
gida, explicación de los distintos componentes desarrolla-
dos, etc.
En el pasado, consistía en los programas fuentes finales y al-
gunas explicaciones a grandes rasgos. Esta documentación in-
formal simplemente ya no es aceptable para los grandes siste-
mas de software de la actualidad
B.10. Modelos del Proceso de Desarrollo del Software
Para realizar el desarrollo, fabricación ó construcción del software, existen varios Modelos de
desarrollo. Llamamos así a un conjunto de estrategias, métodos y herramientas para realizar ese
Mantener
•Reparar fallas
•(Corregir errores inadvertidos)
Actualizar
•Adaptar el Software a diferentes entornos
•(funcionalidades que mejoran la performnace del sistema)
Mejorar el Sistema
•Actualizar el Sistema a Nuevos Cambios
•(Agregar o Modificar Funcionalidades del Sistema)
Mantenimiento del Software
Universidad Nacional de La Matanza Departamento: Ingeniería e Investigaciones Tecnológicas
Cátedra: Fundamentos de TIC’s
Introducción a Sistemas de Información Página 57 de 71
Requisitos
Diseño
Desarrollo
Operación
Prueba
desarrollo. Se puede decir que son normas para seguir en el desarrollo, un marco de referencia para
la construcción del sistema de información.
Dependiendo del enfoque de desarrollo que se utilizará, se indicarán:
procesos, actividades y tareas que serán realizados,
el orden en que se harán y
que productos o entregables se generan y en qué momento.
Que documentación se entregará al cliente y cuál será para el equipo de sistemas.
El modelo de desarrollo elegido para la fabricación del mismo, dependerá del tipo de software, del
contexto en el que se usará, de la rapidéz con que se necesite, y otros aspectos más a tener en
cuenta. Porque no es lo mismo si se necestia un sistema de software para la adminstración de
empleados, que un sistema de software para la administración del tráfico areo en un aeropuesto.
Las etapas de desarrollo “análisis, diseño, implementación y prueba” son genéricas, se encuentran
en todos los Modelos de desarrollo, pero dependiendo del modelo elegido podrá cambiar sutilmente
el nombre o la manera de cómo se realizan las mismas.
B.10.1. Modelo Lineal o Modelo en Cascada
Se realiza siguiendo una secuencia de fases, donde una fase no puede comenzar si no ha terminado
la anterior. La descripción formal de este modelo de proceso fue realizada en el año 1970, y es con-
siderado el más antiguo.
Cuando el análisis de requisitos haya finalizado (todos los requisitos del cliente fueron identificados
y revisados con el cliente) se pasa al diseño, y cuando se haya finalizado y revisado el diseño del
sistema, se pasará al desarrollo y así hasta finalizar con la etapa de operación. En la realidad este paradigma es poco realista, porque entre otras cosas el usuario deberá tener en
claro todas las necesidades del sistema, tener en claro que cosas deberá hacer sistema, y esto rara
vez es así.
Además deberá contar con el tiempo y paciencia suficientes para esperar a que el sistema este to-
talmente realizado, pasará mucho tiempo hasta que vea concretado el producto.
Cuando todos los requisitos del cliente fueron identificados se pasa al diseño
Las principales ventajas y desventajas son:
Universidad Nacional de La Matanza Departamento: Ingeniería e Investigaciones Tecnológicas
Cátedra: Fundamentos de TIC’s
Introducción a Sistemas de Información Página 58 de 71
B.10.2. Iterativo o Incremental
Los clientes identifican, de forma somera, los servicios que proveerá el sistema. Entonces, se defi-
nen varios incrementos en donde cada uno proporciona un subconjunto de funcionalidad al sistema.
Una vez que un incremento se completa y entrega, los clientes pueden ponerlo en servicio. Esto
significa utilizar parte de la funcionalidad del sistema. También experimentan con el sistema real, lo
cual les ayuda a clarificar sus requerimientos para los incrementos posteriores y para las últimas
versiones del incremento actual. La esencia de los procesos iterativos o incrementales es que la es-
pecificación se desarrolla junto con el software.
VENTAJAS DESVENTAJAS
Las etapas están organizadas de un modo lógico.
Es decir, una etapa no puede llevarse a cabo hasta
que se hayan tomado ciertas decisiones de más alto
nivel, debe esperar hasta que esas decisiones estén
tomadas.
El modelo en cascada asume que los requisitos de
un sistema pueden ser congelados antes de co-
menzar el diseño.
Esto, para sistemas totalmente nuevos, es poco
realista.
Cada etapa incluye cierto proceso de revisión, y se
necesita una aceptación del producto antes de que la
salida de la etapa pueda usarse.
Este ciclo de vida está organizado de modo que se
pase el menor número de errores de una etapa a la
siguiente.
Congelar los requisitos requiere seleccionar el
hardware.
La terminación de un gran proyecto puede llevar
años. Dada la velocidad de obsolescencia de la
tecnología es bastante probable que el software
final utilice un hardware obsoleto.
La revisión formal al final de cada fase permite el
control administrativo máximo.
El punto más débil del ciclo de vida en cascada es
que envía al cliente el primer producto solamente
después de que se ha consumido el 99 % de los
recursos para el desarrollo.
Universidad Nacional de La Matanza Departamento: Ingeniería e Investigaciones Tecnológicas
Cátedra: Fundamentos de TIC’s
Introducción a Sistemas de Información Página 59 de 71
Las principales ventajas y desventajas son:
VENTAJAS DESVENTAJAS
Los clientes no tienen que esperar hasta que el sis-
tema completo se entregue para sacar provecho del
él. El primer incremento satisface los requerimien-
tos más críticos de tal forma que el software está
disponible para su uso inmediato.
Los incrementos deben ser relativamente pequeños y
cada uno debe entregar alguna funcionalidad al sis-
tema.
Los clientes pueden utilizar los incrementos inicia-
les como un prototipo para obtener experiencia
sobre los requerimientos del los incrementos poste-
riores del sistema.
Puede ser difícil adaptar los requerimientos del
cliente a incrementos de tamaño apropiado.
Existe un bajo riesgo de fallar en el proyecto total.
Aunque algunos problemas se pueden encontrar en
algunos incrementos, lo normal es que el sistema se
entregue de forma satisfactoria al cliente.
Muchos de los sistemas requieren un conjunto de
recursos que se utilizan en diferentes partes del sis-
tema.
Puesto que los servicios de alta prioridad se entre-
gan primero y los incrementos posteriores se inte-
gran a ellos, es inevitable que los servicios más
importantes del sistema sean a los que les haga más
pruebas.
Es difícil identificar los recursos comunes que re-
quieren todos los incrementos.
B.10.3. Espiral
Las distintas etapas no se muestran como una sucesión de actividades con retrospectiva de una acti-
vidad a otra, sino que se representa como una espiral. Cada ciclo de la espiral se puede dividir en
seis sectores, que se corresponden con actividades de éste marco de trabajo.
Se comienza por el centro de la espiral, luego de pasar por las seis regiones se obtiene un producto
(cubo con el nro. 1 ) resultado de esa primer iteración. Luego se continúa en la 2da iteración pasan-
do por las seis regiones con cada una de sus actividades, obteniéndose el 2do producto (cubo con el
nro. 2), y así sucesivamente hasta obtener el producto final.
Universidad Nacional de La Matanza Departamento: Ingeniería e Investigaciones Tecnológicas
Cátedra: Fundamentos de TIC’s
Introducción a Sistemas de Información Página 60 de 71
Cada ciclo (o iteración) se completa con una revisión, que incluye todo el ciclo anterior y el plan
para el siguiente.
Conjunto de Tareas para cada una de las seis regiones.
• La diferencia importante entre el ciclo en espiral y los otros ciclos de vida es la considera-
ción explicita del riesgo en el modelo en espiral. Los riesgos conducen a problemas como
calendarización y excesos en los costos, por lo tanto, la disminución de riesgos es una acti-
vidad muy importante en la administración del proyecto (ej: Se evalúan los riesgos técnicos
y de de la gestión en sí. (riesgos que puedan atentar con la interrupción del desarrollo).
Las ventajas más significativas de este ciclo de vida son:
Su rango de opciones permite utilizar los modelos del proceso de construcción de software
tradicionales dentro del ciclo de vida.
Su orientación al riesgo evita muchas dificultades.
Presta atención a las opciones que permiten la reutilización de software existente.
B.10. 4. Ágil
La metodología de desarrollo ágil no es la especificación de un ciclo de vida sino que un conjunto
de modelos de procesos de software basados en los mismos principios. Estos principios fueron
plasmados en el “Manifiesto para el desarrollo ágil de software” firmado en el 2001 por un conjunto
de reconocidos desarrolladores de software4. Este comienza diciendo:
Estamos poniendo al descubierto mejores métodos para desarrollar software, haciéndolo y
ayudando a otros a que lo hagan. Con este trabajo hemos llegado a valorar:
A los individuos y su interacción, por encima de los procesos y las herramientas.
El software que funciona, por encima de la documentación exhaustiva.
La colaboración con el cliente, por encima de la negociación contractual.
La respuesta al cambio, por encima del seguimiento de un plan.
Aunque hay valor en los elementos de la derecha, valoramos más los de la izquierda.
Hasta mediados de los 90, se consideraba que la mejor manera de desarrollar software era a través
de una cuidadosa planeación del proyecto, de actividades formales para asegurar la calidad del
software, de un excesivo control y un riguroso proceso de desarrollo de software. Este enfoque "pe-
sado" puede ser correcto para sistemas de software grandes y de larga vida, pero implica una carga
adicional de control, planificación y documentación para proyectos medianos y pequeños. Los pro-
cesos de software ágiles surgen como alternativa a estos procesos de software "pesados".
Los métodos agiles se basan en iteraciones, pequeños grupos trabajan juntos con el cliente para de-
finir prototipos rápidos y pruebas de concepto (POCs). El equipo define los requerimientos para la
iteración, la cual rápidamente es verificada por el usuario. Las verificaciones por parte del usuario
son tempranas ya que las iteraciones son cortas, como por ejemplo en Scrum (una de las metodo-
logías agiles), las iteraciones (llamadas sprint) se recomiendan que sean de 2 a 3 semanas.
Una de las diferencias más importantes de los procesos agiles y los procesos en cascada es que estos
últimos tiene partes entregables (que NO ES un producto software funcionando)en todas las fa-
ses, mientras que los métodos agiles poseen iteraciones en lugar de fases, la salida de cada iteración
es una parte del software que PUEDE SER USADO y responde a un cambio evolucionando a
través de los requerimientos de usuario.
4 El manifiesto traducido al castellano está disponible en: http://agilemanifesto.org/iso/es/
Universidad Nacional de La Matanza Departamento: Ingeniería e Investigaciones Tecnológicas
Cátedra: Fundamentos de TIC’s
Introducción a Sistemas de Información Página 61 de 71
VENTAJAS DESVENTAJAS
Permite cambios en los requisitos durante el desa-
rrollo Es difícil estimar los costos al comienzo del proyec-
to, especialmente para aquellos de larga duración El equipo no dedica tiempo y esfuerzo a entregables
que no agregan valor y que no serán utilizados El proyecto puede tener un rumbo incierto, espe-
cialmente si el cliente no tiene claro sus objetivos Comunicación continúa con el usuario, lo cual per-
mite comprender mejor sus necesidades. El equipo de desarrollo tiene que estar formado en
su mayoría por desarrolladores experimentados. El resultado final es un software de alta calidad
entregado en el menor tiempo posible.
Algunas de las metodologías ágiles más conocidas que se pueden citar son: Programación Extrema
y Scrum.
B.11. Las Organizaciones como Sistemas
La definición de las organizaciones como sistemas implica la consideración de circunstancias que
no deben ser desconocidas si se trata de operar sobre ellas. Resulta necesario comprender que si el
subsistema técnico de una organización se realiza cambios, los otros subsistemas tendrán que ajus-
tarse en función de esos cambios.
B.11.1. Organizaciones
Es un sistema abierto, es decir se relaciona con el contexto y, por lo común, es frecuentemente in-
fluido por éste.
Básicamente tres elementos son los que permiten caracterizar el fenómeno organizacional:
Los valores comunes (objetivos, llamados también metas, fines o propósitos).
Los recursos
Los agentes
Fenómeno Organizacional
Agentes
Recursos
Valores comunes
Una organización es un sistema social integrado por individuos y grupos que, bajo
una determinada estructura y dentro de un contexto al que controlan parcialmente,
desarrollan actividades aplicando recursos para lograr determinados objetivos (valores
comunes)
Universidad Nacional de La Matanza Departamento: Ingeniería e Investigaciones Tecnológicas
Cátedra: Fundamentos de TIC’s
Introducción a Sistemas de Información Página 62 de 71
ENTRADAS
Materiales
Dinero
Esfuerzo humano
Información
SALIDAS
Producto
Servicio
Satisfacción humana
Supervivencia
Desarrollo
Beneficio Social
PROCESO
Transformación
de recursos
Retroalimentación
MICROENTORNO (Competidores, proveedores, Clientes, etc.)
CONTEXTO O AMBIENTE EXTERNO
La Organización como Sistema
Ninguno de estos elementos debe faltar para que exista una organización. Un grupo humano que
desarrolla actividades y tiene recursos para hacerlo, pero no sabe para qué lo hace, es errático y por
lo tanto no constituye una organización. Si sólo consideramos agentes y objetivos de que éstos
quieren cumplir, pero no tienen medios para hacerlo, no estamos en presencia de una organización.
Y finalmente, aunque existan recursos y objetivos a cumplir, sin grupos ni individuos que desarro-
llen actividades que permitan traducir los primeros en los segundos, tampoco se estaría ante una
organización.
A partir de la constante interacción con el medio ambiente, la organización desarrolla cierta capaci-
dad adaptativa con respecto a los cambios que se producen en aquél, operando en condiciones esta-
bles o de equilibrio dinámico, al tiempo que prosigue con su continuo flujo de entradas, transforma-
ción y salidas. Por lo tanto, la retroalimentación es fundamental para mantener al sistema dentro de
ese equilibrio dinámico.
B.11.3. Empresas
Una empresa es aquella organización que se dedica a los negocios. Desarrollan actividades econó-
micas a partir de ciertos recursos (humanos, materiales, energéticos, financieros, informáticos, etc.)
que aplican a procesos de producción de bienes y / o prestación de servicios y comercializan para
satisfacer las necesidades de los consumidores.
Si bien los objetivos de una empresa suelen ser muchos y variados, el fin económico que se traduce
en buscar la rentabilidad del patrimonio a través de la obtención de utilidades, suele hallarse en la
mayoría de los casos (con excepciones como por ejemplo: las empresas estatales que procuran fines
sociales).
Al desarrollar la gestión económica, la empresa debe enfrentar a otras que buscan los mismos
propósitos y en los mismos mercados (conjunto de personas que compran o que podrían comprar un
producto), generándose así una competencia, que es cada vez más aguda.
B.11.4. Estructura Organizativa
Las organizaciones se sustentan en dos procesos:
Universidad Nacional de La Matanza Departamento: Ingeniería e Investigaciones Tecnológicas
Cátedra: Fundamentos de TIC’s
Introducción a Sistemas de Información Página 63 de 71
Delegación: Es el proceso por el cual un miembro de la organización transfiere una o más
funciones a otro miembro.
Departamentalización: Consiste en agrupar tareas o funciones en conjuntos homogéneos,
especializados para el cumplimiento de cierto tipo de actividades. Generalmente adopta la
forma de gerencia, departamentos, secciones, etc.
Toda empresa cuenta en forma explícita o implícita, con un cierto conjunto de jerarquías y atribu-
ciones asignadas a los miembros de la misma. Por ese motivo, toda organización cuenta con una
estructura que puede ser:
Formal: En general suele estar representada por el organigrama (representación gráfica de esta es-
tructura formal, que muestra las relaciones existentes entre las partes que componen la empresa).
Informal: Es la distribución real de la empresa, generalmente en aquellas pequeñas o familiares,
que no tienen estructura predeterminada alguna.
B.11.5. Organigrama
Los organigramas son una representación gráfica de la estructura formal de la organización en un
momento determinado. Si bien no brindan una información completa de los aspectos formales e
informales de la organización, constituyen una primera aproximación al conocimiento de los mis-
mos. Los organigramas señalan la vinculación que existe a lo largo de las líneas de autoridad prin-
cipales. Dejan expresados:
La división de funciones.
Los niveles jerárquicos.
Las líneas de autoridad y responsabilidad.
Los canales formales de comunicación.
La naturaleza lineal o staff del departamento. La tarea staff se caracteriza por el asesoramien-
to y la consulta, y la influencia en lugar del ejercicio de la autoridad.
Los jefes de cada grupo.
Las relaciones existentes entre los diversos puestos de la empresa y en cada departamento o
sección.
Los organigramas deben ser, ante todo, muy claros.
Los organigramas deben contener nombres de funciones y no de personas.
B.11.6. Principios Básicos de las Organizaciones
Son pautas que determinan formalmente las reglas a las que deben ajustarse las entidades en cuanto
de las funciones y responsabilidades. Un organigrama podría denunciar el no cumplimiento de al-
guno de estos principios:
1) Unidad de mando: Cada sector debe responder a un “único superior”. Por ejemplo, un sector no puede
estar dependiendo jerárquicamente de dos o más sectores.
2) Definición precisa de los niveles jerárquicos: La ubicación jerárquica de un sector debe estar definida.
Esto puede acarrear problemas y conflictos varios al no tener claro qué sector depende de qué sector.
3) Separación de funciones: Funciones homogéneas deben ser parte de un mismo sector. Cuando una
serie de funciones impliquen una responsabilidad patrimonial, deben pertenecer a diferentes sectores.
Violar este principio puede crear además condición incompatible desde el punto de vista interno, para ta-
reas de control sobre si misma o control por oposición de intereses.
4) Precisión en la determinación de funciones de línea y de asesoramiento: Las funciones de asesora-
miento como su nombre lo indica no forman parte de la rutina de trabajo diaria. La existencia de cargos
“adscriptos” puede crear confusión.
5) Alcance de control: Dependiendo del tipo de tarea a desarrollar cada responsable tiene un número ideal
de colaboradores a controlar. Cuanto menos especializada sea la tarea menor será el número de puestos a
controlar. En funciones operativas de línea se considera un supervisor por cada tres subordinados.
Universidad Nacional de La Matanza Departamento: Ingeniería e Investigaciones Tecnológicas
Cátedra: Fundamentos de TIC’s
Introducción a Sistemas de Información Página 64 de 71
Aquí se muestra un ejemplo de un organigrama en el que no se cumplen estos principios básicos y a
continuación se muestran en dónde es que se encuentran los errores:
1. Existe una doble dependencia de Control de Calidad. No cumple con el principio de unidad de mando.
2. El Gerente Comercial no posee una definición precisa del nivel jerárquico.
3. Auditoría depende del Gerente Administrativo (debería reportar únicamente al Gerente General).
4. El Subgerente de Producción es innecesario, ya que cumpliría las mismas funciones que el Jefe de Pro-
ducción. No hay precisión en la determinación de las funciones de línea y de asesoramiento.
5. El Jefe de Producción posee una excesiva cantidad de subordinados, ya que por pertenecer al nivel opera-
tivo sólo debería poseer tres subordinados.
Universidad Nacional de La Matanza Departamento: Ingeniería e Investigaciones Tecnológicas
Cátedra: Fundamentos de TIC’s
Introducción a Sistemas de Información Página 65 de 71
ANEXO: Las TICs y su aplicación a Ingeniería Industrial y Civil Ing. Miguel Di Paolo y Luciano Marotta
Ingeniería Industrial
Perfil del Profesional
Está encargado de la programación, organización, puesta en marcha y control de los procesos pro-
ductivos de la empresa. Realiza una evaluación técnica y económica de éstos y formula una predic-
ción de su comportamiento.
Integra los elementos que constituyen un sistema o un proceso:
personas, tecnología, máquinas, equipos, materiales e informa-
ción, para optimizar su rendimiento y calidad, redu- ciendo sus
costos y respetando factores medioambientales, en un marco de
desarrollo sustentable.
Desarrolla y evalúa proyectos de la más diversa natu- raleza ya
que cuenta con una formación tanto tecnológica como de gestión de empresas., que lo hace un ex-
perto en el diseño y manejo de proceso productivos y de negocios.
Aplica la computación, la informática y sistemas de automatización a las actividades de pro-
ducción industrial y a los servicios de administración.
Entendido en métodos matemáticos de optimización de problemas y en la aplicación de estas técni-
cas a procesos industriales específicos, logísticos, de recursos humanos, ambientales y financieros.
Forma parte de equipos de trabajo junto a otros profesionales para tomar decisiones a nivel de la
administración estratégica de la empresa y asesora técnicamente a los diferentes departamentos.
El ingeniero industrial nace de la necesidad de las industrias de optimizar los procesos de produc-
ción para elevar su rendimiento; y de parte del área de servicios, de la necesidad de sus ejecutivos
de una asesoría para la toma de decisiones en áreas de su desempeño donde no cuentan con los co-
nocimientos técnicos específicos del área. Por ejemplo, la asesoría en la aprobación de una línea de
crédito para proyectos de áreas especializadas como la agricultura, mecánica, la industria química,
etc.
El trabajo de un Ingeniero Industrial
incluye la producción industrial, co-
mercio, distribución, energía, salud,
educación, servicios financieros,
agroindustria, informática, transportes,
etc.
Universidad Nacional de La Matanza Departamento: Ingeniería e Investigaciones Tecnológicas
Cátedra: Fundamentos de TIC’s
Introducción a Sistemas de Información Página 66 de 71
Tareas o actividades específicas que se realizan en la profesión
En su área de acción podrá realizar tareas como:
Por medio de modelos computacionales, estudia y optimiza procesos y métodos de pro-
ducción.
Estructura y distribuye la planta de
producción. (colocación de líne- as de
montaje).
Diseña sistemas operacionales y logís-
ticos para la manufactura.
Establece el programa y niveles de
producción a corto y largo plazo.
Realiza un análisis de las defi- cien-
cias habidas en la producción o de
servicios a ella y emprende ac- ciones
correctoras.
Plantea fórmulas para reducir embo-
tellamientos y stock de la duc-
ción.
Controla la instalación, mantenimiento preventivo y reparación de los equipos de fabrica-ción.
Observa y descompone las diferentes operaciones y fases del proceso de manufactura o fa-bricación y determina los tiempos estándares empleados en éstos, buscando una optimiza-
ción en los tiempos de producción.
Diseña, implanta y mejora sistemas y métodos de trabajo.
Selecciona, adecúa y diseña equipos y materiales específicos para la producción.
Establece los nexos de comunicación entre la línea y otros departamentos de la empresa (compras, mantenimiento, ventas,...)
Universidad Nacional de La Matanza Departamento: Ingeniería e Investigaciones Tecnológicas
Cátedra: Fundamentos de TIC’s
Introducción a Sistemas de Información Página 67 de 71
Selecciona y gestiona la compra de nueva ma-
quinaria (de control, fabricación, seguridad,..)
y coordina su instalación y mantenimiento.
Organiza al personal según necesidades.
Diseña, implanta y mejora sistemas de control de calidad.
Ve formas de reducir costos y riesgos de los
trabajadores.
Desarrolla y aplica técnicas para la medición y evaluación de la productividad.
Dirige y asesora a la organización de las áreas técnicas (producción, calidad, métodos y tiem-
pos, materiales, etc) y supervisa los procesos
industriales.
Elabora informes, gráficas y estadísticas de funcionamiento.
Formula modelos matemáticos acerca de cada problema generalmente para su pro-
gramación y tratamiento informático (como por ejemplo modelos eficientes de insumo
_ producto).
Proyecta, dirige y evalúa sistemas de información.
Estudia la evolución tecnológica.
Formula proyectos de inversión.
Realiza evaluación técnica y económica de proyectos de inversión.
Dirige el diseño, desarrollo y producción de nuevos pro-ductos y servicios.
Investiga acerca de nuevos productos, materiales, fuentes
de energía, tecnologías y procedimientos a fin de conseguir me-
joras de calidad y costos.
Analiza las causas de las deficiencias de productos y propone medidas correctoras.
Propone el lanzamiento, readaptación o abandono de productos y servicios.
Universidad Nacional de La Matanza Departamento: Ingeniería e Investigaciones Tecnológicas
Cátedra: Fundamentos de TIC’s
Introducción a Sistemas de Información Página 68 de 71
Controla la aplicación de las normas establecidas (seguridad, protección medio ambiente,...)
en los nuevos proyectos.
Realiza y supervisa ensayos y pruebas de laboratorio y de fabricación.
Colabora en el diseño de máquinas y herramientas específicas.
Mejora de la infraestructura técnica.
Se informa a través del departamento de márketing y comercial de las necesidades del mer-cado.
Ingeniería Civil
Hoy en día la tecnología se ha transformado en un pilar fundamental para el desarrollo social y
económico mundial. El gran progreso de las ciencias de la computación e informática son garantías
de un futuro con más posibilidades para los profesionales, ya que se vuelven indispensables para un
buen desempeño.
Podemos decir que como usuario común utilizamos distintas herramientas informáticas, como re-
des sociales, computadoras, celulares, calculadoras, etc.
Para Ingeniería Civil se utilizan desde el programa más común, como puede ser cualquiera perte-
neciente a Microsoft Office o también programas para utilizar con sistemas operativos de celulares
como Android o celulares Iphone, hasta programas de diseño y cálculos complejos como vamos a
mencionar posteriormente.
Estructuras: Análisis estructurales, análisis estáticos y dinámicos.
Programa: STAAD PRO.
Geotecnia: Análisis de deformación y estabilidad de problemas geotécnicos.
Programa: PLAXIS, GEO5.
Universidad Nacional de La Matanza Departamento: Ingeniería e Investigaciones Tecnológicas
Cátedra: Fundamentos de TIC’s
Introducción a Sistemas de Información Página 69 de 71
Hidráulica: Diseñador de estructuras hidráulicas. Programa:
HCANALES.
Auto CAD: Planos 2D y 3D de obras, existe una versión para ingeniería civil llamada Civil CAD
con funciones especiales para los dibujos.
Calculadoras: Gran variedad de programas para calculadoras como por ejemplo: análisis estático
de estructuras, análisis de tuberías, etc.
Domótica: Integración de la tecnología en el diseño inteligente de un recinto cerrado, aportando
servicios de gestión energética, seguridad, bienestar y comunicación. Aspectos principales:
1. Ahorro energético: no es necesario sustituir los aparatos o sistemas del hogar por otros que
consuman menos, si no hacer una gestión eficiente de los mismos.
2. Confort: acciones que se pueden llevar a cabo para mejorar el ambiente hogareño. Control
total de las luces de la vivienda (apagado y encendido general y a distancia, regulación
según el ambiente, luces inteligentes), control y programación de la calefacción, control vía
teléfono y/o internet, riego inteligente (control por humedad del suelo).
Universidad Nacional de La Matanza Departamento: Ingeniería e Investigaciones Tecnológicas
Cátedra: Fundamentos de TIC’s
Introducción a Sistemas de Información Página 70 de 71
3. Seguridad: red de seguridad encargada de proteger tanto los bienes como la seguridad per-
sonal. Alarma anti robo (control total de puertas y ventanas), alarma anti incendio, alerta
médica (teleasistencia), acceso a cámaras desde cualquier lugar de la casa que tenga un tele-
visor, simulador de presencia.
4. Comunicaciones: sistema e infraestructura que posee el hogar. Control interno y externo del
hogar, control remoto desde internet, informe de consumos y costos, intercomunicaciones.
Universidad Nacional de La Matanza Departamento: Ingeniería e Investigaciones Tecnológicas
Cátedra: Fundamentos de TIC’s
Introducción a Sistemas de Información Página 71 de 71
BIBLIOGRAFIA
J. P. Tremblay / P. G. Sorenson; “An Introduction to Data Structures whit applications”; Editori-al Mc. Graw Hill.
George Beekman; “Computación & Informática Hoy”; Editorial Addison Wesley.
H. N. Laden /T. R. Gildersleeve; “Diseño de Sistemas de Computación”; Editorial Limusa.
Glenn Brookshear; “Introducción a las Ciencias de la Computación”; Editorial Addison Wesley.
Mario D. Albarracín. E. Alcalde Lancharo García López; “Introducción a la Informática”; Edito-rial Mc Graw Hill.
Pressman Roger S; “Ingeniería de Software”; Editorial Mc Graw Hill
Yourdon, Edward; “Análisis Estructurado Moderno”; Editorial Prentice Hall
Klein Miguel Jorge; “Cursogramas Técnicas y casos”; Editorial Macchi
IEEE; Std. 1074-1989; “Standard Software Life Cycle. Processes”
Neighbors, J.; The Draco; “Approach to Constructing Software from Reusable Components”
IEEE; “Modelo de ciclo de vida por ensamblaje de componentes reutilizables”
Basili, V.R.-Tumer A.J.; “Iterative Enhancement: A practical technique for Software Develop-
ment” ; IEEE Modelo de ciclo de vida de refinamiento sucesivo
Bauer, F.L.; “Programming as an Evolutionary Process. Computer Society”; Modelo de ciclo de vida de transformación continua
Böehm, B.W.; “Prototyping vs. Specifying: A Multi-project Experiment. Conf. Soft. Engr.”; Modelo de ciclo de vida en cascada y prototipado
Lehman, M.M.A.; “Further Model of Coherent Programming Processes. IEEE Computer Socie-ty”; Modelo de ciclo de vida como una transformación continua
Tully, C.; “Software Development Models. IEEE Computer Society”; Modelo de ciclo de vida
con emision gradual
Ian Sommerville, “Software Engineering, Six Edition”; Editorial Pearson Educational Limited.
Cátedra Sistemas de Információn; “Operaciones típicas de una empresa”; Editorial Club de Es-tudio
Lardent Alberto, Gómez Echaren Manuel, Loro Alberto; “Técnicas de Organización, Sistemas y
Métodos”; Editorial Club de Estudio
Long, Larry; “Introducción a las computadoras y al procesamiento de información”; Editorial Prentice may
L. Alfonso Ureña López, Antonio Miguel Sánchez Solana, María Teresa Martín Valdivia, José Miguel Mantas Ruiz; “Fundamentos de informática”; Editorial Alfaomega
Narváez, Jorge Luis; “Planificación de organizaciones”; Editorial Universidad Nacional de La
Matanza, Editorial Prometeo libros.
Grady Booch, Robert A. Maksimchuk, Michael W. Engle, Bobbi J. Young, Ph.D., Jim Conallen
Kelli A. Houston; “Object-Oriented Analysis and Design” with Applications. Third Edition. Edi-
torial: Addison-Wesley.