Cátedra: Fundamentos de TIC’s · Fundamentos de TIC’s (Tecnologías de la ... avance de la ingeniería, de las ciencias y de ... y su integración con las tecnologías 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




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




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




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




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




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.

http://definicion.de/algoritmo/

http://definicion.de/problema/




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.




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.




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




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.




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




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.




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




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




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




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




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.




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.




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




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.




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




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.




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.




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.




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.




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




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.




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




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.




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.




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.




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




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.




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




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?




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.




¿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




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.




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.




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.




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




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.




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)




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.




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




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]




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




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.




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.




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.




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.




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.




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




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.




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




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:




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.




Las principales ventajas y desventajas son:


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.




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/





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)




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:




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.




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.




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, reduciendo sus

costos y respetando factores medioambientales, en un marco de

desarrollo sustentable.

Desarrolla y evalúa proyectos de la más diversa naturaleza 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.




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 acciones

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




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.




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.




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




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.




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.

Documents

Cátedra: Fundamentos de TIC’s · Fundamentos de TIC’s (Tecnologías de la ... avance de la ingeniería, de las ciencias y de ... y su integración con las tecnologías de la