Introduccion a Sistemas

INTRODUCCION
La teoría de la organización y la práctica administrativa han experimentado cambios sustanciales en
años recientes. La información proporcionada por las ciencias de la administración y la conducta ha
enriquecido a la teoría tradicional. Estos esfuerzos de investigación y de conceptualización a veces
han llevado a descubrimientos divergentes. Sin embargo, surgió un enfoque que puede servir como
base para lograrla convergencia, el enfoque de sistemas, que facilita la unificación de muchos
campos del conocimiento. Dicho enfoque ha sido usado por las ciencias físicas, biológicas y
sociales, como marco de referencia para la integración de la teoría organizacional moderna.

El primer expositor de la Teoría General de los Sistemas fue Ludwing von Bertalanffy, en el intento
de lograr una metodología integradora para el tratamiento de problemas científicos.

La meta de la Teoría General de los Sistemas no es buscar analogías entre las ciencias, sino tratar de
evitar la superficialidad científica que ha estancado a las ciencias. Para ello emplea como
instrumento, modelos utilizables y transferibles entre varios continentes científicos, toda vez que
dicha extrapolación sea posible e integrable a las respectivas disciplinas.

La Teoría General de los Sistemas se basa en dos pilares básicos: aportes semánticos y aportes
metodológicos, a los cuales me referiero en las próximas páginas.

APORTES SEMANTICOS

Las sucesivas especializaciones de las ciencias obligan a la creación de nuevas palabras, estas se
acumulan durante sucesivas especializaciones, llegando a formar casi un verdadero lenguaje que
sólo es manejado por los especialistas.

De esta forma surgen problemas al tratarse de proyectos interdisciplinarios, ya que los participantes
del proyecto son especialistas de diferentes ramas de la ciencia y cada uno de ellos maneja una
semántica diferente a los demás.

La Teoría de los Sistemas, para solucionar estos inconvenientes, pretende introducir una semántica
científica de utilización universal.

Sistema:

Es un conjunto organizado de cosas o partes interactuantes e interdependientes, que se relacionan

formando un todo unitario y complejo.

Cabe aclarar que las cosas o partes que componen al sistema, no se refieren al campo físico
(objetos), sino mas bien al funcional. De este modo las cosas o partes pasan a ser funciones básicas
realizadas por el sistema. Podemos enumerarlas en: entradas, procesos y salidas.

Entradas:
Las entradas son los ingresos del sistema que pueden ser recursos materiales, recursos humanos o
información.

Las entradas constituyen la fuerza de arranque que suministra al sistema sus necesidades operativas.

Las entradas pueden ser:

- en serie: es el resultado o la salida de un sistema anterior con el cual el sistema en estudio está
relacionado en forma directa.

- aleatoria: es decir, al azar, donde el termino ³azar´ se utiliza en el sentido estadístico. Las entradas
aleatorias representan entradas potenciales para un sistema.

- retroacción: es la reintroducción de una parte de las salidas del sistema en sí mismo.

Clasificación extraída de apunte de cátedra.

Proceso:

El proceso es lo que transforma una entrada en salida, como tal puede ser una máquina, un
individuo, una computadora, un producto químico, una tarea realizada por un miembro de la
organización, etc.

En la transformación de entradas en salidas debemos saber siempre como se efectúa esa

transformación. Con frecuencia el procesador puede ser diseñado por el administrador. En tal caso,
este proceso se denomina ³caja blanca´. No obstante, en la mayor parte de las situaciones no se
conoce en sus detalles el proceso mediante el cual las entradas se transforman en salidas, porque
esta transformación es demasiado compleja. Diferentes combinaciones de entradas o su
combinación en diferentes órdenes de secuencia pueden originar diferentes situaciones de salida. En
tal caso la función de proceso se denomina una ³caja negra´.

Caja Negra:

La caja negra se utiliza para representar a los sistemas cuando no sabemos que elementos o cosas
componen al sistema o proceso, pero sabemos que a determinadas corresponden determinadas
salidas y con ello poder inducir, presumiendo que a determinados estímulos, las variables
funcionaran en cierto sentido.

Salidas:

Las salidas de los sistemas son los resultados que se obtienen de procesar las entradas. Al igual que
las entradas estas pueden adoptar la forma de productos, servicios e información. Las mismas son el
resultado del funcionamiento del sistema o, alternativamente, el propósito para el cual existe el
sistema.

Las salidas de un sistema se convierte en entrada de otro, que la procesará para convertirla en otra
salida, repitiéndose este ciclo indefinidamente.
Relaciones:

Las relaciones son los enlaces que vinculan entre sí a los objetos o subsistemas que componen a un
sistema complejo.

Podemos clasificarlas en :

- Simbióticas: es aquella en que los sistemas conectados no pueden seguir funcionando solos. A su
vez puede subdividirse en unipolar o parasitaria, que es cuando un sistema (parásito) no puede vivir
sin el otro sistema (planta); y bipolar o mutual, que es cuando ambos sistemas dependen entre si.

- Sinérgica: es una relación que no es necesaria para el funcionamiento pero que resulta útil, ya que
su desempeño mejora sustancialmente al desempeño del sistema. Sinergia significa ³acción
combinada´. Sin embargo, para la teoría de los sistemas el término significa algo más que el
esfuerzo cooperativo. En las relaciones sinérgicas la acción cooperativa de subsistemas semi-
independientes, tomados en forma conjunta, origina un producto total mayor que la suma de sus
productos tomados de una manera independiente.

- Superflua: Son las que repiten otras relaciones. La razón de las relaciones superfluas es la
confiabilidad. Las relaciones superfluas aumentan la probabilidad de que un sistema funcione todo
el tiempo y no una parte del mismo. Estas relaciones tienen un problema que es su costo, que se
suma al costo del sistema que sin ellas puede funcionar.

Clasificación obtenida de apunte de cátedra.

Atributos:

Los atributos de los sistemas, definen al sistema tal como lo conocemos u observamos. Los
atributos pueden ser definidores o concomitantes: los atributos definidores son aquellos sin los
cuales una entidad no sería designada o definida tal como se lo hace; los atributos concomitantes en
cambio son aquellos que cuya presencia o ausencia no establece ninguna diferencia con respecto al
uso del término que describe la unidad.

Contexto:

Un sistema siempre estará relacionado con el contexto que lo rodea, o sea, el conjunto de objetos
exteriores al sistema, pero que influyen decididamente a éste, y a su vez el sistema influye, aunque
en una menor proporción, influye sobre el contexto; se trata de una relación mutua de contexto-
sistema.

Tanto en la Teoría de los Sistemas como en el método científico, existe un concepto que es común a
ambos: el foco de atención, el elemento que se aísla para estudiar.

El contexto a analizar depende fundamentalmente del foco de atención que se fije. Ese foco de
atención, en términos de sistemas, se llama límite de interés.

Para determinar este límite se considerarían dos etapas por separado:

a) La determinación del contexto de interés.

b) La determinación del alcance del límite de interés entre el contexto y el sistema.

a) Se suele representar como un círculo que encierra al sistema, y que deja afuera del límite de
interés a la parte del contexto que no interesa al analista.

d) En lo que hace a las relaciones entre el contexto y los sistemas y viceversa. Es posible que sólo
interesen algunas de estas relaciones, con lo que habrá un límite de interés relacional.

Determinar el límite de interés es fundamental para marcar el foco de análisis, puesto que sólo será
considerado lo que quede dentro de ese límite.

Entre el sistema y el contexto, determinado con un límite de interés, existen infinitas relaciones.
Generalmente no se toman todas, sino aquellas que interesan al análisis, o aquellas que
probabilísticamente presentan las mejores características de predicción científica.

Rango:

En el universo existen distintas estructuras de sistemas y es factible ejercitar en ellas un proceso de

definición de rango relativo. Esto produciría una jerarquización de las distintas estructuras en
función de su grado de complejidad.

Cada rango o jerarquía marca con claridad una dimensión que actúa como un indicador claro de las
diferencias que existen entre los subsistemas respectivos.

Esta concepción denota que un sistema de nivel 1 es diferente de otro de nivel 8 y que, en
consecuencia, no pueden aplicarse los mismos modelos, ni métodos análogos a riesgo de cometer
evidentes falacias metodológicas y científicas.

Para aplicar el concepto de rango, el foco de atención debe utilizarse en forma alternativa: se
considera el contexto y a su nivel de rango o se considera al sistema y su nivel de rango.

Refiriéndonos a los rangos hay que establecer los distintos subsistemas. Cada sistema puede ser
fraccionado en partes sobre la base de un elemento común o en función de un método lógico de
detección.

El concepto de rango indica la jerarquía de los respectivos subsistemas entre sí y su nivel de

relación con el sistema mayor.

Subsistemas:

En la misma definición de sistema, se hace referencia a los subsistemas que lo componen, cuando se
indica que el mismo esta formado por partes o cosas que forman el todo.
Estos conjuntos o partes pueden ser a su vez sistemas (en este caso serían subsistemas del sistema
de definición), ya que conforman un todo en sí mismos y estos serían de un rango inferior al del
sistema que componen.

Estos subsistemas forman o componen un sistema de un rango mayor, el cual para los primeros se
denomina macrosistema.

Variables:

Cada sistema y subsistema contiene un proceso interno que se desarrolla sobre la base de la acción,
interacción y reacción de distintos elementos que deben necesariamente conocerse.

Dado que dicho proceso es dinámico, suele denominarse como variable, a cada elemento que
compone o existe dentro de los sistemas y subsistemas.

Pero no todo es tan fácil como parece a simple vista ya que no todas las variables tienen el mismo
comportamiento sino que, por lo contrario, según el proceso y las características del mismo, asumen
comportamientos diferentes dentro del mismo proceso de acuerdo al momento y las circunstancias
que las rodean.

Parámetro:

Uno de los comportamientos que puede tener una variable es el de parámetro, que es cuando una
variable no tiene cambios ante alguna circunstancia específica, no quiere decir que la variable es
estática ni mucho menos, ya que sólo permanece inactiva o estática frente a una situación
determinada.

Operadores:

Otro comportamiento es el de operador, que son las variables que activan a las demás y logran
influir decisivamente en el proceso para que este se ponga en marcha. Se puede decir que estas
variables actúan como líderes de las restantes y por consiguiente son privilegiadas respecto a las
demás variables. Cabe aquí una aclaración: las restantes variables no solamente son influidas por
los operadores, sino que también son influenciadas por el resto de las variables y estas tienen
también influencia sobre los operadores.

Retroalimentación:

La retroalimentación se produce cuando las salidas del sistema o la influencia de las salidas del
sistemas en el contexto, vuelven a ingresar al sistema como recursos o información.

La retroalimentación permite el control de un sistema y que el mismo tome medidas de corrección

en base a la información retroalimentada.

Feed-forward o alimentación delantera:

Es una forma de control de los sistemas, donde dicho control se realiza a la entrada del sistema, de
tal manera que el mismo no tenga entradas corruptas o malas, de esta forma al no haber entradas
malas en el sistema, las fallas no serán consecuencia de las entradas sino de los proceso mismos que
componen al sistema.

Homeostasis y entropía:

La homeostasis es la propiedad de un sistema que define su nivel de respuesta y de adaptación al

contexto.

Es el nivel de adaptación permanente del sistema o su tendencia a la supervivencia dinámica. Los

sistemas altamente homeostáticos sufren transformaciones estructurales en igual medida que el
contexto sufre transformaciones, ambos actúan como condicionantes del nivel de evolución.

La entropía de un sistema es el desgaste que el sistema presenta por el transcurso del tiempo o por
el funcionamiento del mismo. Los sistemas altamente entrópicos tienden a desaparecer por el
desgaste generado por su proceso sistémico. Los mismos deben tener rigurosos sistemas de control
y mecanismos de revisión, reelaboración y cambio permanente, para evitar su desaparición a través
del tiempo.

En un sistema cerrado la entropía siempre debe ser positiva. Sin embargo en los sistemas abiertos
biológicos o sociales, la entropía puede ser reducida o mejor aun transformarse en entropía
negativa, es decir, un proceso de organización más completo y de capacidad para transformar los
recursos. Esto es posible porque en los sistemas abiertos los recursos utilizados para reducir el
proceso de entropía se toman del medio externo. Asimismo, los sistemas vivientes se mantienen en
un estado estable y pueden evitar el incremento de la entropía y aun desarrollarse hacia estados de
orden y de organización creciente.

Permeabilidad:

La permeabilidad de un sistema mide la interacción que este recibe del medio, se dice que a mayor
o menor permeabilidad del sistema el mismo será mas o menos abierto.

Los sistemas que tienen mucha relación con el medio en el cuál se desarrollan son sistemas
altamente permeables, estos y los de permeabilidad media son los llamados sistemas abiertos.

Por el contrario los sistemas de permeabilidad casi nula se denominan sistemas cerrados.

Integración e independencia:

Se denomina sistema integrado a aquel en el cual su nivel de coherencia interna hace que un cambio
producido en cualquiera de sus subsistemas produzca cambios en los demás subsistemas y hasta en
el sistema mismo.

Un sistema es independiente cuando un cambio que se produce en él, no afecta a otros sistemas.

Centralización y descentralización:
Un sistema se dice centralizado cuando tiene un núcleo que comanda a todos los demás, y estos
dependen para su activación del primero, ya que por sí solos no son capaces de generar ningún
proceso.

Por el contrario los sistemas descentralizados son aquellos donde el núcleo de comando y decisión
está formado por varios subsistemas. En dicho caso el sistema no es tan dependiente, sino que
puede llegar a contar con subsistemas que actúan de reserva y que sólo se ponen en funcionamiento
cuando falla el sistema que debería actuar en dicho caso.

Los sistemas centralizados se controlan más fácilmente que los descentralizados, son más sumisos,
requieren menos recursos, pero son más lentos en su adaptación al contexto. Por el contrario los
sistemas descentralizados tienen una mayor velocidad de respuesta al medio ambiente pero
requieren mayor cantidad de recursos y métodos de coordinación y de control más elaborados y
complejos.

Adaptabilidad:

Es la propiedad que tiene un sistema de aprender y modificar un proceso, un estado o una

característica de acuerdo a las modificaciones que sufre el contexto. Esto se logra a través de un
mecanismo de adaptación que permita responder a los cambios internos y externos a través del
tiempo.

Para que un sistema pueda ser adaptable debe tener un fluido intercambio con el medio en el que se
desarrolla.

Mantenibilidad:

Es la propiedad que tiene un sistema de mantenerse constantemente en funcionamiento. Para ello

utiliza un mecanismo de mantenimiento que asegure que los distintos subsistemas están
balanceados y que el sistema total se mantiene en equilibrio con su medio.

Estabilidad:

Un sistema se dice estable cuando puede mantenerse en equilibrio a través del flujo continuo de
materiales, energía e información.

La estabilidad de los sistemas ocurre mientras los mismos pueden mantener su funcionamiento y
trabajen de manera efectiva (mantenibilidad).

Armonía:

Es la propiedad de los sistemas que mide el nivel de compatibilidad con su medio o contexto.

Un sistema altamente armónico es aquel que sufre modificaciones en su estructura, proceso o

características en la medida que el medio se lo exige y es estático cuando el medio también lo es.

Optimización y sub-optimización:
Optimización modificar el sistema para lograr el alcance de los objetivos.

Suboptimización en cambio es el proceso inverso, se presenta cuando un sistema no alcanza sus

objetivos por las restricciones del medio o porque el sistema tiene varios objetivos y los mismos son
excluyentes, en dicho caso se deben restringir los alcances de los objetivos o eliminar los de menor
importancia si estos son excluyentes con otros más importantes.

Exito:

El éxito de los sistemas es la medida en que los mismos alcanzan sus objetivos.

La falta de éxito exige una revisión del sistema ya que no cumple con los objetivos propuestos para
el mismo, de modo que se modifique dicho sistema de forma tal que el mismo pueda alcanzar los
objetivos determinados.

APORTES METODOLOGICOS

Jerarquía de los sistemas

Al considerar los distintos tipos de sistemas del universo Kennet Boulding proporciona una
clasificación útil de los sistemas donde establece los siguientes niveles jerárquicos:

1. Primer nivel, estructura estática. Se le puede llamar nivel de los marcos de referencia.

2. Segundo nivel, sistema dinámico simple. Considera movimientos necesarios y predeterminados.

Se puede denominar reloj de trabajo.

3. Tercer nivel, mecanismo de control o sistema cibernético. El sistema se autorregula para

mantener su equilibrio.

4. Cuarto nivel, ³sistema abierto´ o autoestructurado. En este nivel se comienza a diferenciar la

vida. Puede de considerarse nivel de célula.

5. Quinto nivel, genético-social. Está caracterizado por las plantas.

6. Sexto nivel, sistema animal. Se caracteriza por su creciente movilidad, comportamiento

teleológico y su autoconciencia.

7. Séptimo nivel, sistema humano. Es el nivel del ser individual, considerado como un sistema con
conciencia y habilidad para utilizar el lenguaje y símbolos.

8. Octavo nivel, sistema social o sistema de organizaciones humanas constituye el siguiente nivel, y
considera el contenido y significado de mensajes, la naturaleza y dimensiones del sistema de
valores, la transcripción de imágenes en registros históricos, sutiles simbolizaciones artísticas,
música, poesía y la compleja gama de emociones humanas.
. Noveno nivel, sistemas trascendentales. Completan los niveles de clasificación: estos son los
últimos y absolutos, los ineludibles y desconocidos, los cuales también presentan estructuras
sistemáticas e interrelaciones.

Teoría analógica o modelo de isomorfismo sistémico:

Este modelo busca integrar las relaciones entre fenómenos de las distintas ciencias. La detección de
estos fenómenos permite el armado de modelos de aplicación para distintas áreas de las ciencias.

Esto, que se repite en forma permanente, exige un análisis iterativo que responde a la idea de
modularidad que la teoría de los sistemas desarrolla en sus contenidos.

Se pretende por comparaciones sucesivas, una aproximación metodológica, a la vez que facilitar la
identificación de los elementos equivalentes o comunes, y permitir una correspondencia biunívoca
entre las distintas ciencias.

Como evidencia de que existen propiedades generales entre distintos sistemas, se identifican y
extraen sus similitudes estructurales.

Estos elementos son la esencia de la aplicación del modelo de isomorfismo, es decir, la

correspondencia entre principios que rigen el comportamiento de objetos que, si bien
intrínsecamente son diferentes, en algunos aspectos registran efectos que pueden necesitar un
mismo procedimiento.
Descripcion General Sistemas
„


Es un conjunto organizado de cosas o partes interactuantes e interdependientes, que se relacionan

formando un todo unitario y complejo.

Cabe aclarar que las cosas o partes que componen al sistema, no se refieren al campo físico
(objetos), sino mas bien al funcional. De este modo las cosas o partes pasan a ser funciones básicas
realizadas por el sistema. Podemos enumerarlas en: entradas,
procesos y salidas.

 
 
„„
„

1. Un conjunto de elementos
2. Dinámicamente relacionados
3. Formando una actividad
4. Para alcanzar un objetivo
5. Operando sobre datos/energía/materia
6. Para proveer información/energía/materia



Las entradas son los ingresos del sistema que pueden ser recursos materiales, recursos humanos o
información.

Las entradas constituyen la fuerza de arranque que suministra al sistema sus necesidades operativas.
Las entradas pueden ser:

- en serie: es el resultado o la salida de un sistema anterior con el cual el sistema en estudio está
relacionado en forma directa.

- aleatoria: es decir, al azar, donde el termino ³azar´ se utiliza en el sentido estadístico. Las entradas
aleatorias representan entradas potenciales para un sistema.

- retroacción: es la reintroducción de una parte de las salidas del sistema en sí mismo.

Clasificación extraída de apunte de cátedra.




El proceso es lo que transforma una entrada en salida, como tal puede ser una máquina, un
individuo, una computadora, un producto químico, una tarea realizada por un miembro de la
organización, etc.

En la transformación de entradas en salidas debemos saber siempre como se efectúa esa

transformación. Con frecuencia el procesador puede ser diseñado por el administrador. En tal caso,
este proceso se denomina ³caja blanca´. No obstante, en la mayor parte de las situaciones no se
conoce en sus detalles el proceso mediante el cual las entradas se transforman en salidas, porque
esta transformación es demasiado compleja. Diferentes combinaciones de entradas o su
combinación en diferentes órdenes de secuencia pueden originar diferentes situaciones de salida. En
tal caso la función de proceso se denomina una ³caja negra´.

 

La caja negra se utiliza para representar a los sistemas cuando no sabemos que elementos o cosas
componen al sistema o proceso, pero sabemos que a determinadas corresponden determinadas
salidas y con ello poder inducir, presumiendo que a determinados estímulos, las variables
funcionaran en cierto sentido.

„ 


Las salidas de los sistemas son los resultados que se obtienen de procesar las entradas. Al igual que
las entradas estas pueden adoptar la forma de productos, servicios e información. Las mismas son el
resultado del funcionamiento del sistema o, alternativamente, el propósito para el cual existe el
sistema.

Las salidas de un sistema se convierte en entrada de otro, que la procesará para convertirla en otra
salida, repitiéndose este ciclo indefinidamente.

 


Las relaciones son los enlaces que vinculan entre sí a los objetos o subsistemas que componen a un
sistema complejo.
Podemos clasificarlas en :

- „
   es aquella en que los sistemas conectados no pueden seguir funcionando solos. A su
vez puede subdividirse en unipolar o parasitaria, que es cuando un sistema (parásito) no puede vivir
sin el otro sistema (planta); y bipolar o mutual, que es cuando ambos sistemas dependen entre si.

„   
es una relación que no es necesaria para el funcionamiento pero que resulta útil, ya que
su desempeño mejora sustancialmente al desempeño del sistema. Sinergia significa ³acción
combinada´. Sin embargo, para la teoría de los sistemas el término significa algo más que el
esfuerzo cooperativo. En las relaciones sinérgicas la acción cooperativa de subsistemas semi-
independientes, tomados en forma conjunta, origina un producto total mayor que la suma de sus
productos tomados de una manera independiente.

„ : Son las que repiten otras relaciones. La razón de las relaciones superfluas es la
confiabilidad. Las relaciones superfluas aumentan la probabilidad de que un sistema funcione todo
el tiempo y no una parte del mismo. Estas relaciones tienen un problema que es su costo, que se
suma al costo del sistema que sin ellas puede funcionar.

Clasificación obtenida de apunte de cátedra.

 


Los atributos de los sistemas, definen al sistema tal como lo conocemos u observamos. Los
atributos pueden ser definidores o concomitantes: los atributos definidores son aquellos sin los
cuales una entidad no sería designada o definida tal como se lo hace; los atributos concomitantes en
cambio son aquellos que cuya presencia o ausencia no establece ninguna diferencia con respecto al
uso del término que describe la unidad.



Un sistema siempre estará relacionado con el contexto que lo rodea, o sea, el conjunto de objetos
exteriores al sistema, pero que influyen decididamente a éste, y a su vez el sistema influye, aunque
en una menor proporción, influye sobre el contexto; se trata de una relación mutua de contexto-
sistema.

Tanto en la Teoría de los Sistemas como en el método científico, existe un concepto que es común a
ambos: el foco de atención, el elemento que se aísla para estudiar.

El contexto a analizar depende fundamentalmente del foco de atención que se fije. Ese foco de
atención, en términos de sistemas, se llama límite de interés.

Para determinar este límite se considerarían dos etapas por separado:

a) La determinación del contexto de interés.

b) La determinación del alcance del límite de interés entre el contexto y el sistema.

a) Se suele representar como un círculo que encierra al sistema, y que deja afuera del límite de
interés a la parte del contexto que no interesa al analista.

d) En lo que hace a las relaciones entre el contexto y los sistemas y viceversa. Es posible que sólo
interesen algunas de estas relaciones, con lo que habrá un límite de interés relacional.

Determinar el límite de interés es fundamental para marcar el foco de análisis, puesto que sólo será
considerado lo que quede dentro de ese límite.

Entre el sistema y el contexto, determinado con un límite de interés, existen infinitas relaciones.
Generalmente no se toman todas, sino aquellas que interesan al análisis, o aquellas que
probabilísticamente presentan las mejores características de predicción científica.



En el universo existen distintas estructuras de sistemas y es factible ejercitar en ellas un proceso de

definición de rango relativo. Esto produciría una jerarquización de las distintas estructuras en
función de su grado de complejidad.

Cada rango o jerarquía marca con claridad una dimensión que actúa como un indicador claro de las
diferencias que existen entre los subsistemas respectivos.

Esta concepción denota que un sistema de nivel 1 es diferente de otro de nivel 8 y que, en
consecuencia, no pueden aplicarse los mismos modelos, ni métodos análogos a riesgo de cometer
evidentes falacias metodológicas y científicas.

Para aplicar el concepto de rango, el foco de atención debe utilizarse en forma alternativa: se
considera el contexto y a su nivel de rango o se considera al sistema y su nivel de rango.

Refiriéndonos a los rangos hay que establecer los distintos subsistemas. Cada sistema puede ser
fraccionado en partes sobre la base de un elemento común o en función de un método lógico de
detección.

El concepto de rango indica la jerarquía de los respectivos subsistemas entre sí y su nivel de

relación con el sistema mayor.

„




En la misma definición de sistema, se hace referencia a los subsistemas que lo componen, cuando se
indica que el mismo esta formado por partes o cosas que forman el todo.

Estos conjuntos o partes pueden ser a su vez sistemas (en este caso serían subsistemas del sistema
de definición), ya que conforman un todo en sí mismos y estos serían de un rango inferior al del
sistema que componen.

Estos subsistemas forman o componen un sistema de un rango mayor, el cual para los primeros se
denomina macrosistema.
] 


Cada sistema y subsistema contiene un proceso interno que se desarrolla sobre la base de la acción,
interacción y reacción de distintos elementos que deben necesariamente conocerse.

Dado que dicho proceso es dinámico, suele denominarse como variable, a cada elemento que
compone o existe dentro de los sistemas y subsistemas.

Pero no todo es tan fácil como parece a simple vista ya que no todas las variables tienen el mismo
comportamiento sino que, por lo contrario, según el proceso y las características del mismo, asumen
comportamientos diferentes dentro del mismo proceso de acuerdo al momento y las circunstancias
que las rodean.



Uno de los comportamientos que puede tener una variable es el de parámetro, que es cuando una
variable no tiene cambios ante alguna circunstancia específica, no quiere decir que la variable es
estática ni mucho menos, ya que sólo permanece inactiva o estática frente a una situación
determinada.




Otro comportamiento es el de operador, que son las variables que activan a las demás y logran
influir decisivamente en el proceso para que este se ponga en marcha. Se puede decir que estas
variables actúan como líderes de las restantes y por consiguiente son privilegiadas respecto a las
demás variables. Cabe aquí una aclaración: las restantes variables no solamente son influidas por
los operadores, sino que también son influenciadas por el resto de las variables y estas tienen
también influencia sobre los operadores.

  

La retroalimentación se produce cuando las salidas del sistema o la influencia de las salidas del
sistemas en el contexto, vuelven a ingresar al sistema como recursos o información.

La retroalimentación permite el control de un sistema y que el mismo tome medidas de corrección

en base a la información retroalimentada.

!"#$     

Es una forma de control de los sistemas, donde dicho control se realiza a la entrada del sistema, de
tal manera que el mismo no tenga entradas corruptas o malas, de esta forma al no haber entradas
malas en el sistema, las fallas no serán consecuencia de las entradas sino de los proceso mismos que
componen al sistema.

%


& '

La homeostasis es la propiedad de un sistema que define su nivel de respuesta y de adaptación al
contexto.

Es el nivel de adaptación permanente del sistema o su tendencia a la supervivencia dinámica. Los

sistemas altamente homeostáticos sufren transformaciones estructurales en igual medida que el
contexto sufre transformaciones, ambos actúan como condicionantes del nivel de evolución.

La entropía de un sistema es el desgaste que el sistema presenta por el transcurso del tiempo o por
el funcionamiento del mismo. Los sistemas altamente entrópicos tienden a desaparecer por el
desgaste generado por su proceso sistémico. Los mismos deben tener rigurosos sistemas de control
y mecanismos de revisión, reelaboración y cambio permanente, para evitar su desaparición a través
del tiempo.

En un sistema cerrado la entropía siempre debe ser positiva. Sin embargo en los sistemas abiertos
biológicos o sociales, la entropía puede ser reducida o mejor aun transformarse en entropía
negativa, es decir, un proceso de organización más completo y de capacidad para transformar los
recursos. Esto es posible porque en los sistemas abiertos los recursos utilizados para reducir el
proceso de entropía se toman del medio externo. Asimismo, los sistemas vivientes se mantienen en
un estado estable y pueden evitar el incremento de la entropía y aun desarrollarse hacia estados de
orden y de organización creciente.

  

La permeabilidad de un sistema mide la interacción que este recibe del medio, se dice que a mayor
o menor permeabilidad del sistema el mismo será mas o menos abierto.

Los sistemas que tienen mucha relación con el medio en el cuál se desarrollan son sistemas
altamente permeables, estos y los de permeabilidad media son los llamados sistemas abiertos.

Por el contrario los sistemas de permeabilidad casi nula se denominan sistemas cerrados.

    

Se denomina sistema integrado a aquel en el cual su nivel de coherencia interna hace que un cambio
producido en cualquiera de sus subsistemas produzca cambios en los demás subsistemas y hasta en
el sistema mismo.

Un sistema es independiente cuando un cambio que se produce en él, no afecta a otros sistemas.

 (  & 
 ( 

Un sistema se dice centralizado cuando tiene un núcleo que comanda a todos los demás, y estos
dependen para su activación del primero, ya que por sí solos no son capaces de generar ningún
proceso.

Por el contrario los sistemas descentralizados son aquellos donde el núcleo de comando y decisión
está formado por varios subsistemas. En dicho caso el sistema no es tan dependiente, sino que
puede llegar a contar con subsistemas que actúan de reserva y que sólo se ponen en funcionamiento
cuando falla el sistema que debería actuar en dicho caso.

Los sistemas centralizados se controlan más fácilmente que los descentralizados, son más sumisos,
requieren menos recursos, pero son más lentos en su adaptación al contexto. Por el contrario los
sistemas descentralizados tienen una mayor velocidad de respuesta al medio ambiente pero
requieren mayor cantidad de recursos y métodos de coordinación y de control más elaborados y
complejos.

  :

Es la propiedad que tiene un sistema de aprender y modificar un proceso, un estado o una

característica de acuerdo a las modificaciones que sufre el contexto. Esto se logra a través de un
mecanismo de adaptación que permita responder a los cambios internos y externos a través del
tiempo.

Para que un sistema pueda ser adaptable debe tener un fluido intercambio con el medio en el que se
desarrolla.

   :

Es la propiedad que tiene un sistema de mantenerse constantemente en funcionamiento. Para ello

utiliza un mecanismo de mantenimiento que asegure que los distintos subsistemas están
balanceados y que el sistema total se mantiene en equilibrio con su medio.

  :

Un sistema se dice estable cuando puede mantenerse en equilibrio a través del flujo continuo de
materiales, energía e información.

La estabilidad de los sistemas ocurre mientras los mismos pueden mantener su funcionamiento y
trabajen de manera efectiva (mantenibilidad).

':

Es la propiedad de los sistemas que mide el nivel de compatibilidad con su medio o contexto.

Un sistema altamente armónico es aquel que sufre modificaciones en su estructura, proceso o

características en la medida que el medio se lo exige y es estático cuando el medio también lo es.

  (  &
"  ( 

Optimización modificar el sistema para lograr el alcance de los objetivos.

Suboptimización en cambio es el proceso inverso, se presenta cuando un sistema no alcanza sus

objetivos por las restricciones del medio o porque el sistema tiene varios objetivos y los mismos son
excluyentes, en dicho caso se deben restringir los alcances de los objetivos o eliminar los de menor
importancia si estos son excluyentes con otros más importantes.

 :

El éxito de los sistemas es la medida en que los mismos alcanzan sus objetivos.

La falta de éxito exige una revisión del sistema ya que no cumple con los objetivos propuestos para
el mismo, de modo que se modifique dicho sistema de forma tal que el mismo pueda alcanzar los
objetivos determinados.
Tipos Sistemas
„

 
 


Son llamados TPS cuyas siglas corresponden a Transaction Processing System, o sistemas de
procesamiento de transacciones.

Un ejemplo es la Corporación Financiera Internacional (CFI), filial del Banco Internacional para la
Reconstrucción y el Desarrollo, cuyo sistema de transacciones funciona de la siguiente manera: El
CFI busca inversores interesados en los países más desarrollados y el capital proveído por éstos, es
transferido a empresas privadas de países subdesarrollados cuyo capital privado no basta.
Otro ejemplo es el de la industria naviera, el cual por medio de su sistema de transacciones
internacionales transportan diferentes tipos de carga de acuerdo a pedidos en diferentes países,
siendo uno de los más transportados el petróleo, cuyos pedidos pueden ser ya sea privados o por
contrato.

Los barcos transportan el petróleo desde los campos petrolíficos a las refinerías, siguiendo una serie
de tratados y convenciones internacionales.

„

   

KWS, knowledge work system, o sistema de manejo de conocimiento.

Un ejemplo es el de aplicaciones como Photoshop, la cual ayuda a diseñadores gráficos en crear su

arte publicitario por medio de poderosas herramientas con las cuales se puede manipular y
modificar distintos tipos de gráficos y fotografías.

„





AI, artificial intelligence, o inteligencia artificial.

Un famoso sistema experto es MYCIN, el cual es un sistema experto para la realización de

diagnósticos, el cual aconseja a los médicos en la investigación y determinación de diagnósticos en
el campo de las enfermedades infecciosas de la sangre. El sistema MYCIN, al ser consultado por el
médico, solicita primero datos generales sobre el paciente: nombre, edad, síntomas, etc. Una vez
conocida esta información por parte del sistema, el Sistema Experto plantea unas hipótesis. Para
verificar la hipótesis el sistema consulta a la base de conocimientos, y también haciendo una serie
de preguntas al usuario. Con las respuestas que recibe, el MYCIN verifica o rechaza las hipótesis
planteadas.
Otro sistema experto es el XCON el cual es un sistema experto de configuraciones el cual, según las
especificaciones del cliente, configura redes de ordenadores VAX. Tiene como base de su
funcionamiento las siguientes dos preguntas:

1. ¿Pueden conjugarse los componentes solicitados por el cliente de forma conveniente y razonable?

2. ¿Los componentes de sistema especificados son compatibles y completos?

Las respuestas a estas preguntas son muy detalladas. XCON es capaz de comprobar y completar los
pedidos entrantes mucho más rápido y mejor que las personas encargadas hasta ahora de esa labor.

„

 &  )


GDSS, group decission support system, o sistemas de apoyo a decisiones de grupo.

Un sistema GDSS es el Vision Quest, el cual permite realizar junta electrónicas. Entre sus ventajas
se encuentra su facilidad de uso. Cualquiera puede conducir una junta electrónica y el sistema puede
ser usado de manera distribuida . Las juntas se pueden realizar con los participantes en el mismo
lugar o diferentes lugares, al mismo tiempo o a distintos tiempos. Aunque no pretende reemplazar
las juntas cara a cara, su uso permite reducir los costos de viaje, la rapidez de toma de decisiones lo
que resulta en una mejor eficiencia y productividad de las juntas . El sistema funciona en terminales
de trabajo que pueden estar o no en el mismo lugar, la interacción se realiza a través del teclado y el
monitor de la computadora.

Otro sistema es el CRUISER cuyas siglas son para Computer Supported Spontaneous Interaction.
La importancia de este sistema se basa en la interacción informal . CRUISER está diseñado
alrededor del concepto de comunidad o grupo virtual que existe sólo en un mundo virtual, donde las
distancias geográficas entre los participantes no son importantes. Por sus características este sistema
provee acceso instantáneo a cualquier persona y cualquier lugar.

La importancia del sistema está basada en dos ideas. La primera, los usuarios pueden navegar a
través del mundo virtual en búsqueda de encuentros sociales. La segunda, el mundo virtual es
independiente del mundo físico y puede ser organizado de acuerdo a las necesidades del usuario. En
la práctica el usuario recorre pasillos, oficinas y áreas comunes, todas ellas generadas por
computadora. Los usuarios se comunican a través de audio y video. CRUISER ataca uno de los
problemas de los trabajos en equipo, reconoce la importancia de la comunicación informal. Provee
además características de la práctica de trabajo permitiéndole diferentes niveles de privacidad.

„
   *


ESS, executive support system, o sistemas de apoyo a ejecutivos.

Un ejemplo es el sistema comprado por Pratt & Whitney, una corporación que se dedica a la
producción de motores de propulsión a chorro. Ellos compraron el sistema denominado
Commander EIS que permite representaciones a todo color y un menú imaginativo que puede
aprenderse intuitivamente, con variaciones y excepciones que son destacadas mediante colores. Los
usuarios pueden accesar datos mediante una pantalla táctil, ratón o teclado y pueden agrandar las
imágenes para mayores niveles de detalle, ya sea navegando por sí mismos o siguiendo caminos
previamente definidos.

El Commnander EIS permite a la organización hacer el seguimiento de los parámetros de la calidad

y factibilidad de las medidas tomadas para cada motor a reacción por tipo de cliente. Los datos
aparecen de los sistemas actuales de producción y proporcionan información sobre la confiabilidad,
disponibilidad de motores y partes, y sobre las entregas.

Otro ejemplo es el sistema implantado por la New York State Office of General Services que es
responsable de dar servicio a otras dependencias en Nueva York. El sistema permite que los
ejecutivos verifiquen el estado por programa, comparando el presupuesto con el gasto real y
mostrando el gasto estimado hasta el final del año fiscal. La administración puede bajar para ver los
detalles específicos en cada categoría. El sistema sólo contiene datos crudos, permitiendo a los
usuarios una gran flexibilidad para agregarlos y analizarlos para satisfacer sus necesidades. El
sistema es operado por medio de un menú muy fácil de usar. Los nuevos usuarios son capacitados
mediante una demostración que dura media hora, y la experiencia ha demostrado que es todo lo que
necesitan. No se cuenta con un manual del usuario.
Clasificacion Sistemas
La clasificación de un sistema al igual que el análisis de los aspectos del mismo es un proceso
relativo; depende del individuo que lo hace, del objetivo que se persigue y de las circunstancias
particulares en las cuales se desarrolla. Los sistemas se clasifican así:

SEGÚN SU RELACION CON EL MEDIO AMBIENTE

¥ Abiertos: Sistemas que intercambian materia, energía o información con el ambiente. Ejemplos:
célula, ser humano, ciudad, perro, televisor, familia estación de radio.

¥ Cerrado: Sistemas que no intercambian materia, energía o información con el ambiente.

Ejemplos: universo, reloj desechable, llanta de carro.

SEGÚN SU NATURALEZA
¥ Concretos: Sistema físico o tangible. Ejemplos: Equipos de sonidos, pájaro, guitarra, elefante.

¥ Abstractos: Sistemas simbólicos o conceptuales. Ejemplo: Sistema sexagesimal, idioma español

lógica difusa.

SEGÚN SU ORIGEN

¥ Naturales: Sistemas generados por la naturaleza, tales como los ríos, los bosques las moléculas de
agua.

¥ Artificiales: Sistemas que son productos de la actividad humana, son concebidos y construidos
por el hombre, tenemos al tren, avión, idioma ingles.

SEGÚN SUS RELACIONES

¥ Simples: Sistemas con pocos elementos y relaciones, como los juegos de billar, péndulo,
f(x)=x+2, palanca.
¥ Complejos: Sistemas con numerosos elementos y relaciones. Ejemplo: cerebro universidad,
cámara, fotográfica.

Esta clasificación es relativa por que depende del número de elementos y relación considerados. En
la práctica y con base en límites psicológicos de la percepción y comprensión humanas, un sistema
con más o menos siete elementos y relaciones se puede considerar simple.

SEGÚN SU CAMBIO EN EL TIEMPO

¥ Estáticos: Sistema que no cambia en le tiempo: piedra, vaso de plástico, montañas.

¥ Dinámicos: Sistema que cambia en el tiempo: Universo, átomo, la tierra, hongo. Esta clasificación
es relativa por que depende del periodo de tiempo definido para el análisis del Sistema.

SEGÚN EL TIPO DE VARIABLEQUE LO DEFINEN

¥ Discretos: Sistema definido por variables discretas: lógica, boolean, alfabeto.

¥ Continuos: Sistema definido por variables continuas: alternador, ríos.

OTRAS CLASIFICACIONES

¥ Jerárquicos: Sistemas cuyos elementos están relacionados mediante relaciones de dependencia o

subordinación conformando una organización por niveles: gobierno de una ciudad.

¥ Sistema de control: Sistema jerárquico en el cual unos elementos son controlados por otros:
lámparas.

¥ Sistema de Control con retroalimentación: Sistema de control en el cual elementos controlados

envían información sobre su estado a los elementos controladores: termostato.

¥ Deterministico: Sistema con un comportamiento previsible: palanca, polea, programa de

computador.

¥ Probabilístico: Sistema con un comportamiento no previsible: clima mosca, sistema económico

mundial.

También cabe plantear que los sistemas pueden clasificarse como:

¥ Vivientes y no viviente: Los sistemas vivientes están dotados de funciones biológicas, como el
nacimiento, la reproducción y la muerte.

¥ Abstractos y concretos: Un sistema abstracto es aquel en que todos sus elementos son conceptos.
Un sistema concreto es aquel en el aquel por lo menos dos de sus elementos son objetivos o sujetos,
o ambos.
Ciclo Vida Proyecto Software
El desarrollo de software va unido a un ciclo de vida compuesto por una serie de etapas que
comprenden todas las actividades, desde el momento en que surge la idea de crear un nuevo
producto software, hasta aquel en que el producto deja definitivamente de ser tilizado por el último
de sus usuarios.

Etapas en el ciclo. Veamos, a grandes rasgos, una pequeña descripción de etapas con que podemos
contar a lo largo del ciclo de vida del software; una vez delimitadas en cierta manera las etapas,
habrá que ver la forma en que estas se afrontan (existen diversos modelos de ciclo de vida, y la
elección de un cierto modelo para un determinado tipo de proyecto puede ser de vital importancia;
el orden de las etapas es un factor importante, p.ej. tener una etapa de validación al final del
proyecto, tal como sugiere el modelo en cascada o lineal, puede implicar serios problemas sobre la
gestión de determinados proyectos; hay que tener en cuenta que retomar etapas previas es costoso, y
cuanto más tarde se haga más costoso resultará, por tanto el hecho de contar con una etapa de
validación tardía tiene su riesgo y, por su situación en el ciclo, un posible tiempo de reacción
mínimo en caso de tener que retornar a fases previas):

Expresión de necesidades Esta etapa tiene como objetivo la consecución de un primer documento
en que queden reflejados los requerimientos y funcionalidades que ofrecerá al usuario del sistema a
desarrollar (qué, y no cómo, se va a desarrollar). Dado que normalmente se trata de necesidades del
cliente para el que se creará la aplicación, el documento resultante suele tener como origen una serie
de entrevistas cliente-proveedor situadas en el contexto de una relación comercial, siendo que debe
ser comprendido por ambas partes (puede incluso tomarse como base para el propio acuerdo
comercial).

Especificaciones Ahora se trata de formalizar los requerimientos; el documento obtenido en la etapa

anterior se tomará como punto de partida para esta fase. Su contenido es aún insuficiente y lleno de
imprecisiones que será necesario completar y depurar. Por medio de esta etapa se obtendrá un
nuevo documento que definirá con más precisión el sistema requerido por el cliente (el empleo de
los casos de uso, use cases, de Jacobson es una muy buena elección para llevar a cabo la
especificación del sistema).

Lo más normal será que no resulte posible obtener una buena especificación del sistema a la
primera; serán necesarias sucesivas versiones del documento en que irán quedando reflejada la
evolución de las necesidades del cliente (por una parte no siempre sabe en los primeros contactos
todo lo que quiere realmente, y por otra parte pueden surgir cambios externos que supongan
requerimientos nuevos o modificaciones de los ya contemplados).

Análisis Es necesario determinar que elementos intervienen en el sistema a desarrollar, así como su
estructura, relaciones, evolución en el tiempo, detalle de sus funcionalidades, « que van a dar una
descripción clara de qué sistema vamos a construir, qué funcionalidades va a aportar y qué
comportamiento va a tener. Para ello se enfocará el sistema desde tres puntos de vista relacionados
pero diferentes:

Funcional. Estático. Dinámico.

Diseño Tras la etapa anterior ya se tiene claro que debe hacer el sistema, ahora tenemos que
determinar como va a hacerlo (¿cómo debe ser construido el sistema?; aquí se definirán en detalle
entidades y relaciones de las bases de datos, se pasará de casos de uso esenciales a su definición
como casos expandidos reales, se seleccionará el lenguaje más adecuado, el Sistema Gestor de
Bases de Datos a utilizar en su caso, librerías, configuraciones hardware, redes, etc.).

Observación: Aunque todo debe ser tratado a su tiempo, y sería muy deseable que las decisiones
correspondientes en esta etapa fueran tomadas precisamente en esta etapa, muchas veces nos vamos
a encontrar con unas decisiones previamente impuestas sobre lenguaje, plataforma, etc. Unas veces
se dirán justificadas en simple política de empresa y por mantener ³compatibilidad´ en lo que
respecta a los demás proyectos de la propia empresa, y en otras ocasiones por rumores de que tal o
cual herramienta mejoraría la velocidad de desarrollo u otro aspecto de interés (en parte de los casos
no serán rumores con fundamento o estudios previos realizados al efecto, sino más bien debidos a la
propia publicidad como consejera).

Implementación Llegado este punto se empieza a codificar algoritmos y estructuras de datos,

definidos en las etapas anteriores, en el correspondiente lenguaje de programación y/o para un
determinado sistema gestor de bases de datos.

Observación: Lamentablemente en la actualidad, año 2.000, quedan bastantes empresas en las que,
tras una reunión comercial en que tan solo se ha conseguido recabar una breve lista de
requerimientos, a pesar de tener que enfrentarse a proyectos grandes-medios, se pasa directamente a
la etapa de implementación; son proyectos guiados por el riesgo que supone adoptar un modelo de
ciclo de vida de codificar-corregir (code and fix) donde se eliminan las fases de especificaciones,
análisis y diseño con la consiguiente pérdida de control sobre la gestión del proyecto.

Pruebas El objetivo de estas pruebas es garantizar que el sistema ha sido desarrollado

correctamente, sin errores de diseño y/o programación. Es conveniente que sean planteadas al
menos tanto a nivel de cada módulo (aislado del resto), como de integración del sistema (según sea
la naturaleza del proyecto en cuestión se podrán tener en cuenta pruebas adicionales, p.ej. de
rendimiento).

Validación Esta etapa tiene como objetivo la verificación de que el sistema desarrollado cumple con
los requisitos expresados inicialmente por el cliente y que han dado lugar al presente proyecto (para
esta fase también es interesante contar con los use cases, generados a través de las correspondientes
fases previas, que servirán de guía para la verificación de que el sistema cumple con lo descrito por
estos).

Mantenimiento y evolución Finalmente la aplicación resultante se encuentra ya en fase de

producción (en funcionamiento para el cliente, cumpliendo ya los objetivos para los que ha sido
creada). A partir de este momento se entra en la etapa de mantenimiento, que supondrá ya pequeñas
operaciones tanto de corrección como de mejora de la aplicación (p.ej. mejora del rendimiento), así
como otras de mayor importancia, fruto de la propia evolución (p.ej. nuevas opciones para el
usuario debidas a nuevas operaciones contempladas para el producto). La mayoría de las veces en
que se desarrolla una nueva aplicación, se piensa sólamente en un ciclo de vida para su creación,
olvidando la posibilidad de que esta deba sufrir modificaciones futuras (que tendrán que producirse
con casi completa seguridad para la mayor parte de los casos).
Planificacion Gestion Del Proyecto

PLANIFICACIÓN Y GESTION DE PROYECTOS DE SOFTWARE

La gestión de un proyecto de software comienza con un conjunto de actividades que globalmente se
denomina planificación del proyecto.
Antes de que el proyecto comience, el gestor y el equipo de software deben realizar una estimación
del trabajo a realizar, y de los recursos necesarios y del tiempo que transcurrirá desde el comienzo
hasta el final de su realización.

Se han propuesto una serie de medidas continuas de la complejidad del software. Tales medidas se
aplican en el nivel de diseño y de codificación, y por consiguiente son difíciles de utilizar durante la
planificación del software (antes de que exista un diseño o código).

El tamaño del proyecto es otro factor importante que puede afectar la precisión y la eficiencia de las
estimaciones.

La complejidad del proyecto y el grado de incertidumbre estructural afectan a la fiabilidad de la

estimación.

El registro se mide por el grado de incertidumbre en las estimaciones cuantitativas establecidas por
recursos, coste y planificación temporal. El planificador del software debería solicitar definiciones
completas de rendimiento y de interfaz.

El objetivo de la planificación del proyecto de software es proporcional un marco de trabajo que

permita al gestor hacer estimaciones razonables de recursos, coste y plantación temporal. Las
estimaciones deberían definir los escenarios del mejor caso» y peor caso» de forma que los
resultados del proyecto puedan limitarse.

El ámbito del software describe el control y los datos a procesar, la función el rendimiento, las
restricciones, las interfaces y la fiabilidad.

La consideración del ámbito del software debe contener una evaluación de todas las interfaces
externas.

El concepto de interfaz abarca lo siguiente:

Hardware.- que ejecuta el software y los dispositivos que están controlados indirectamente por el
software. Software ya existente.
Determinacion Requerimientos Sistema
Ahora se trata de formalizar los requerimientos;el documento obtenido en la etapa anterior se
tomara como punto de partida para esta fase. Su contenido es aun insuficiente y lleno de
imprecisiones que serà necesario completar y depurar.

El aspecto fundamental del análisis de sistemas es comprender todas las facetas importantes de la
parte de la empresa que se encuentra bajo estudio. (Es por esta razón que el proceso de adquirir
información se denomina, con frecuencia, investigación detallada). Los analistas, al trabajar con los
empleados y administradores, deben estudiar los procesos de una empresa para dar respuesta a las
siguientes preguntas clave:

1.- ¿Qué es lo que se hace?

2.- ¿Cómo se hace?

3.- ¿Con que frecuencia se presenta?

4.- ¿Qué tan grande es el volumen de transacciones o de desisciones?

5.- ¿Cuál es el grado de eficiencia con el que se efectúan las tareas?

6.- ¿Existe algún problema?

7.- Si existe un problema, ¿Qué tan serio es?

8.- Si existe un problema, ¿Cuál es la causa que lo origina?

Para contestar estas preguntas, al analista conversa con varias personas para reunir detalles
relacionados con los procesos de la empresa, sus opiniones sobre porque ocurren las cosas, las
soluciones que proponen y sus ideas para cambiar el proceso. Se emplean cuestionarios para
obtener esta información cuando es posible entrevistar, en forma personal, a los miembros de
grupos grandes dentro de la organización. Asimismo, las investigaciones detalladas requieren el
estudio de manuales y reportes, la observación en condiciones reales de las actividades del trabajo
y, en algunas ocasiones, muestras de formas y documentos con el fin de comprender el proceso en
su totalidad.

Conforme se reúnen los detalles, los analistas estudian los datos sobre requerimientos con la
finalidad de identificar las características que debe tener el nuevo sistema, incluyendo la
información que deben producir los sistemas junto con características operacionales.
Analisis Diseño Sistema
ANALISIS DE SISTEMAS DE COMPUTACION

TEMA II. Análisis de Sistemas de Computación.

DESARROLLO.

2.1 Conceptos y Análisis:

ANALISIS:Es necesario determinar que elementos intervienen en el sistemas a desarrollar, asi

como su estructura, relaciones,evoluciòn en el tiempo, detalle de sus funcionalidades,«que van a
dar una descripcion clara de que sistema vamos a construir, què funcionalidades va a aportar y què
comportamiento va a tener.
DISEÑO:Tras la etapa anerior ya se tiene claro que debe hacer el sistema,ahora tenemos que
determinar como va a hacerlo(¿còmo debe ser construido el sistema?;aqui se definiràn en detalle
entidades y relaciones de las bases de datos, se pasarà de casos de uso esenciales a su definiciòn
como casos expandidos reales, se seleccionara el lenguaje mas adecuado, el Sistema Gestor de Base
de Datos a utilizar en un caso, librerias, configuraciones hardware, redes, etc.)

Estos son un conjunto o disposición de procedimientos o programas relacionados de manera que

juntos forman una sola unidad. Un conjunto de hechos, principios y reglas clasificadas y dispuestas
de manera ordenada mostrando un plan lógico en la unión de las partes. Un método, plan o
procedimiento de clasificación para hacer algo. También es un conjunto o arreglo de elementos para
realizar un objetivo predefinido en el procesamiento de la Información. Esto se lleva a cabo
teniendo en cuenta ciertos principios:

Debe presentarse y entenderse el dominio de la información de un problema. Defina las funciones

que debe realizar el Software. Represente el comportamiento del software a consecuencias de
acontecimientos externos. Divida en forma jerárquica los modelos que representan la información,
funciones y comportamiento. El proceso debe partir desde la información esencial hasta el detalle
de la Implementación.

La función del Análisis puede ser dar soporte a las actividades de un negocio, o desarrollar un
producto que pueda venderse para generar beneficios. Para conseguir este objetivo, un Sistema
basado en computadoras hace uso de seis (6) elementos fundamentales:

Software, que son Programas de computadora, con estructuras de datos y su documentación que
hacen efectiva la logística metodología o controles de requerimientos del Programa. Hardware,
dispositivos electrónicos y electromecánicos, que proporcionan capacidad de cálculos y funciones
rápidas, exactas y efectivas (Computadoras, Censores, maquinarias, bombas, lectores, etc.), que
proporcionan una función externa dentro de los Sistemas. Personal, son los operadores o usuarios
directos de las herramientas del Sistema. Base de Datos, una gran colección de informaciones
organizadas y enlazadas al Sistema a las que se accede por medio del Software. Documentación,
Manuales, formularios, y otra información descriptiva que detalla o da instrucciones sobre el
empleo y operación del Programa. Procedimientos, o pasos que definen el uso especifico de cada
uno de los elementos o componentes del Sistema y las reglas de su manejo y mantenimiento. Un
Análisis de Sistema se lleva a cabo teniendo en cuenta los siguientes objetivos en mente:

Identifique las necesidades del Cliente. Evalúe que conceptos tiene el cliente del sistema para
establecer su viabilidad. Realice un Análisis Técnico y económico. Asigne funciones al Hardware,
Software, personal, base de datos, y otros elementos del Sistema. Establezca las restricciones de
presupuestos y planificación temporal. Cree una definición del sistema que forme el fundamento de
todo el trabajo de Ingeniería. Para lograr estos objetivos se requiere tener un gran conocimiento y
dominio del Hardware y el Software, así como de la Ingeniería humana (Manejo y Administración
de personal), y administración de base de datos.

2.2 Objetivos del Análisis.

2.2.1 Identificación de Necesidades.

Es el primer paso del análisis del sistema, en este proceso en Analista se reúne con el cliente y/o
usuario (un representante institucional, departamental o cliente particular), e identifican las metas
globales, se analizan las perspectivas del cliente, sus necesidades y requerimientos, sobre la
planificación temporal y presupuestal, líneas de mercadeo y otros puntos que puedan ayudar a la
identificación y desarrollo del proyecto.

Algunos autores suelen llamar a esta parte ¨ Análisis de Requisitos ¨ y lo dividen en cinco partes:

Reconocimiento del problema. Evaluación y Síntesis. Modelado. Especificación. Revisión Antes de

su reunión con el analista, el cliente prepara un documento conceptual del proyecto, aunque es
recomendable que este se elabore durante la comunicación Cliente ± analista, ya que de hacerlo el
cliente solo de todas maneras tendría que ser modificado, durante la identificación de las
necesidades.

2.2.2 Estudio de Viabilidad.

Muchas veces cuando se emprende el desarrollo de un proyecto de Sistemas los recursos y el

tiempo no son realistas para su materialización sin tener perdidas económicas y frustración
profesional. La viabilidad y el análisis de riesgos están relacionados de muchas maneras, si el riesgo
del proyecto es alto, la viabilidad de producir software de calidad se reduce, sin embargo se deben
tomar en cuenta cuatro áreas principales de interés:

Viabilidad económica. Una evaluación de los costos de desarrollo, comparados con los ingresos
netos o beneficios obtenidos del producto o Sistema desarrollado.

Viabilidad Técnica. Un estudio de funciones, rendimiento y restricciones que puedan afectar la

realización de un sistema aceptable.

Viabilidad Legal. Es determinar cualquier posibilidad de infracción, violación o responsabilidad

legal en que se podría incurrir al desarrollar el Sistema.

Alternativas. Una evaluación de los enfoques alternativos del desarrollo del producto o Sistema.

El estudio de la viabilidad puede documentarse como un informe aparte para la alta gerencia.

2.2.3 Análisis Económico y Técnico.

El análisis económico incluye lo que llamamos, el análisis de costos ± beneficios, significa una
valoración de la inversión económica comparado con los beneficios que se obtendrán en la
comercialización y utilidad del producto o sistema.

Muchas veces en el desarrollo de Sistemas de Computación estos son intangibles y resulta un poco
dificultoso evaluarlo, esto varia de acuerdo a la características del Sistema. El análisis de costos ±
beneficios es una fase muy importante de ella depende la posibilidad de desarrollo del Proyecto.

En el Análisis Técnico, el Analista evalúa los principios técnicos del Sistema y al mismo tiempo
recoge información adicional sobre el rendimiento, fiabilidad, características de mantenimiento y
productividad.

Los resultados obtenidos del análisis técnico son la base para determinar sobre si continuar o
abandonar el proyecto, si hay riesgos de que no funcione, no tenga el rendimiento deseado, o si las
piezas no encajan perfectamente unas con otras.

2.2.4 Modelado de la arquitectura del Sistema.

Cuando queremos dar a entender mejor lo que vamos a construir en el caso de edificios,
Herramientas, Aviones, Maquinas, se crea un modelo idéntico, pero en menor escala (mas
pequeño).
Sin embargo cuando aquello que construiremos es un Software, nuestro modelo debe tomar una
forma diferente, deben representar todas las funciones y subfunciones de un Sistema. Los modelos
se concentran en lo que debe hacer el sistema no en como lo hace, estos modelos pueden incluir
notación gráfica, información y comportamiento del Sistema.

Todos los Sistemas basados en computadoras pueden modelarse como transformación de la

información empleando una arquitectura del tipo entrada y salida.

2.2.5 Especificaciones del Sistema.

Es un Documento que sirve como fundamento para la Ingeniería Hardware, software, Base de
datos, e ingeniería Humana. Describe la función y rendimiento de un Sistema basado en
computadoras y las dificultades que estarán presente durante su desarrollo. Las Especificaciones de
los requisitos del software se produce en la terminación de la tarea del análisis.

En Conclusión un proyecto de desarrollo de un Sistema de Información comprende varios

componentes o pasos llevados a cabo durante la etapa del análisis, el cual ayuda a traducir las
necesidades del cliente en un modelo de Sistema que utiliza uno mas de los componentes: Software,
hardware, personas, base de datos, documentación y procedimientos.

TEMA III.

DISEÑO DE SISTEMAS DE COMUTACION

TEMA III. DISEÑO DE SISTEMAS DE COMPUTACIÓN.

DESARROLLO.

3.1. Conceptos y principios:

El Diseño de Sistemas se define el proceso de aplicar ciertas técnicas y principios con el propósito
de definir un dispositivo, un proceso o un Sistema, con suficientes detalles como para permitir su
interpretación y realización física.

La etapa del Diseño del Sistema encierra cuatro etapas:

El diseño de los datos. Trasforma el modelo de dominio de la información, creado durante el

análisis, en las estructuras de datos necesarios para implementar el Software.

El Diseño Arquitectónico. Define la relación entre cada uno de los elementos estructurales del
programa.

El Diseño de la Interfaz. Describe como se comunica el Software consigo mismo, con los sistemas
que operan junto con el y con los operadores y usuarios que lo emplean.

El Diseño de procedimientos. Transforma elementos estructurales de la arquitectura del programa.

La importancia del Diseño del Software se puede definir en una sola palabra Calidad, dentro del
diseño es donde se fomenta la calidad del Proyecto. El Diseño es la única manera de materializar
con precisión los requerimientos del cliente.

El Diseño del Software es un proceso y un modelado a la vez. El proceso de Diseño es un conjunto

de pasos repetitivos que permiten al diseñador describir todos los aspectos del Sistema a construir.
A lo largo del diseño se evalúa la calidad del desarrollo del proyecto con un conjunto de revisiones
técnicas:

El diseño debe implementar todos los requisitos explícitos contenidos en el modelo de análisis y
debe acumular todos los requisitos implícitos que desea el cliente.

Debe ser una guía que puedan leer y entender los que construyan el código y los que prueban y
mantienen el Software.

El Diseño debe proporcionar una completa idea de lo que es el Software, enfocando los dominios de
datos, funcional y comportamiento desde el punto de vista de la Implementación.

Para evaluar la calidad de una presentación del diseño, se deben establecer criterios técnicos para un
buen diseño como son:

Un diseño debe presentar una organización jerárquica que haga un uso inteligente del control entre
los componentes del software. El diseño debe ser modular, es decir, se debe hacer una partición
lógica del Software en elementos que realicen funciones y subfunciones especificas. Un diseño debe
contener abstracciones de datos y procedimientos. Debe producir módulos que presenten
características de funcionamiento independiente. Debe conducir a interfaces que reduzcan la
complejidad de las conexiones entre los módulos y el entorno exterior. Debe producir un diseño
usando un método que pudiera repetirse según la información obtenida durante el análisis de
requisitos de Software. Estos criterios no se consiguen por casualidad. El proceso de Diseño del
Software exige buena calidad a través de la aplicación de principios fundamentales de Diseño,
Metodología sistemática y una revisión exhaustiva.

Cuando se va a diseñar un Sistema de Computadoras se debe tener presente que el proceso de un

diseño incluye, concebir y planear algo en la mente, así como hacer un dibujo o modelo o croquis.

3.2. Diseño de la Salida.

En este caso salida se refiere a los resultados e informaciones generadas por el Sistema, Para la
mayoría de los usuarios la salida es la única razón para el desarrollo de un Sistema y la base de
evaluación de su utilidad. Sin embargo cuando se realiza un sistema, como analistas deben realizar
lo siguiente:

Determine que información presentar. Decidir si la información será presentada en forma visual,
verbal o impresora y seleccionar el medio de salida. Disponga la presentación de la información en
un formato aceptable. Decida como distribuir la salida entre los posibles destinatarios. 3.3. Diseño
de Archivos.
Incluye decisiones con respecto a la naturaleza y contenido del propio archivo, como si se fuera a
emplear para guardar detalles de las transacciones, datos históricos, o información de referencia.
Entre las decisiones que se toman durante el diseño de archivos, se encuentran las siguientes:

Los datos que deben incluirse en el formato de registros contenidos en el archivo. La longitud de
cada registro, con base en las características de los datos que contenga. La secuencia a disposición
de los registros dentro del archivo (La estructura de almacenamiento que puede ser secuencial,
indexada o relativa). No todos los sistemas requieren del diseño de todos los archivos, ya que la
mayoría de ellos pueden utilizar los del viejo Sistema y solo tenga que enlazarse el nuevo Sistema
al Archivo maestro donde se encuentran los registros.

3.4. Diseño de Interacciones con la Base de Datos.

La mayoría de los sistemas de información ya sean implantado en sistemas de cómputos grandes o

pequeños, utilizan una base de datos que pueden abarcar varias aplicaciones, por esta razón estos
sistemas utilizan u administrador de base de datos, en este caso el diseñador no construye la base de
datos sino que consulta a su administrador para ponerse de acuerdo en el uso de esta en el sistema.

3.5 Herramientas para el Diseño de Sistemas.

Apoyan el proceso de formular las características que el sistema debe tener para satisfacer los
requerimientos detectados durante las actividades del análisis:

3.5.1 Herramientas de especificación.

Apoyan el proceso de formular las características que debe tener una aplicación, tales como
entradas, Salidas, procesamiento y especificaciones de control. Muchas incluyen herramientas para
crear especificaciones de datos.

3.5.2 Herramientas para presentación.

Se utilizan para describir la posición de datos, mensajes y encabezados sobre las pantallas de las
terminales, reportes y otros medios de entrada y salida.

3.5.3 Herramientas para el desarrollo de Sistemas.

Estas herramientas nos ayudan como analistas a trasladar diseños en aplicaciones funcionales.

3.5.4 Herramientas para Ingeniería de Software.

Apoyan el Proceso de formular diseños de Software, incluyendo procedimientos y controles, así

como la documentación correspondiente.

3.5.5 Generadores de códigos.

Producen el código fuente y las aplicaciones a partir de especificaciones funcionales bien

articuladas.
3.5.6 Herramientas para pruebas.

Apoyan la fase de la evaluación de un Sistema o de partes del mismo contra las especificaciones.
Incluyen facilidades para examinar la correcta operación del Sistema así como el grado de
perfección alcanzado en comparación con las expectativas.

La revolución del procesamiento de datos de manera computarizada, junto con las practicas de
Diseño sofisticadas están cambiando de forma dramática la manera en que se trasladan las
especificaciones de Diseño d Sistemas de Información funcionales.

En Conclusiones Generales. En una organización o Empresa, el análisis y Diseño de Sistemas, es el

proceso de estudiar su Situación con la finalidad de observar como trabaja y decidir si es necesario
realizar una mejora; el encargado de llevar a cabo estas tareas es el analista de sistemas.

Antes de comenzar con el desarrollo de cualquier proyecto, se conduce un estudio de Sistemas para
detectar todos los detalles de la situación actual de la empresa. La información reunida con este
estudio sirve como base para crear varias estrategias de Diseño. Los administradores deciden que
estrategias seguir. Los Gerentes, empleados y otros usuarios finales que se familiarizan cada vez
mas con el uso de computadoras están teniendo un papel muy importante en el desarrollo de
sistemas.

Todas las organizaciones son Sistemas que actúan de manera reciproca con su medio ambiente
recibiendo entradas y produciendo salidas. Los Sistemas que pueden estar formados por otros
Sistemas de denominan Sub-sistemas y funcionan para alcanzar los fines de su Implantación.
Programacion Sistemas
Los encargados de desarrollar software pueden instalar paquetes comprados a terceros o escribir
programas diseñados a la medida del solicitante.

La elecciòn depende del costo de cada alternativa, del tiempo disponible para escribir el software y
de la disponibilidad de los programadores.

Lenguajes de Programación

Los lenguajes utilizados para escribir programas de computadoras que puedan ser entendidos por
ellas se denominan programas de programación. Los lenguajes de programación se clasifican en tres
grandes categorías, maquinas: bajo nivel y alto nivel.
Lenguaje de maquina: El lenguaje de maquina es aquel cuyas instrucciones son directamente
entendibles por la computadora y no necesitan traducción posterior para que la UCP pueda
comprender y ejecutar el programa.

Las instrucciones en lenguaje maquina se expresan en términos de la unidad de memoria más

pequeña (bit) = digito binario 0 o 1 , en esencia una secuencia de bits que especifican la operación y
las celdas de memoria implicadas en una operación.

Ejemplo . Instrucciones en lenguaje de maquina :

0010, 0000, 1001, 1001, 10001, 1110.

Como se observa estas instrucciones son fáciles de leer por una computadora y difíciles para un
programador y viceversa. Por esta razón se hace difícil escribir programas en código o lenguaje de
maquina. Y se requiere otro lenguaje para comunicarse con la computadora pero que se hace más
fácil de escribir y de leer por el programador. Para evitar la tediosa tarea de escribir programas en
este lenguaje se han diseñado otros programas de programación que facilitan la escritura y posterior
ejecución de los programas.

Estos son lenguajes de bajo y alto nivel.

Lenguaje de bajo nivel( ensambladores)

La programación en lenguaje de maquina es difícil , por ello se necesitan lenguajes que permitan
simplificar este proceso los lenguajes de bajo nivel han sido diseñados para ese fin.

Estos lenguajes dependen de la maquina o sea del conjunto de instrucciones especificas de la

computadora , ejemplo el lenguaje ensamblador en el las instrucciones se escriben en códigos
alfabéticos conocidos como nemotécnicos (abreviaturas de palabras inglesas o españolas, ejemplo
sumar en ingles

ADD = suma

SUB= resta

MPY = multiplicar

DIV=dividir

LDA= cargar acumulador

STO= almacenar

Las palabras nemotécnicas son mas fáciles de recordar que las secuencias de dígitos de 0 a 1.Una
instrucciones típica en ensamblador puede ser ADD X, Y, Z.

Esta instrucción significa que se deben sumar los números almacenados en las direcciones X,Y y
almacenar el resultado en la dirección z, el lenguaje ensamblador traducirá la instrucción a código
de maquina, por ejemplo.

ADD = 1110

X=1001

Y=1010

Z=1011
La instrucción traducida será 1110 1001 1000 1011

Después que un programa ha sido escrito en lenguaje ensamblador se necesita un programa llamado
ensamblador, que lo traduzca a código de maquina

143. Lenguaje de alto nivel.

Los lenguaje de programación de alto nivel ( BASIC, PASCAL, FORTRAN, C ,COBOL) son
aquellos en los cuales las instrucciones o sentencias a la computadora se escriben con palabras
similares a los lenguajes humanos.

En general en lenguaje ingles como es el caso de Quick Basic , lo cual facilita la escritura y la
comprensión por parte del programador.

Una línea de un programa en Quick Basic es

REM Resolución de un triangulo PRINT

INPUT ³LADO A= ³ ; A

INPUT ³LADO B= ³; B

INPUT ³LADO C´; C

PRINT

LET PERIMETRO= A+B+C

PRINT ³PERIMETRO=³; PERIMETRO

END

Características de los lenguajes de programación:

‡ Transportabilidad :un programa escrito en un lenguaje de alto nivel se puede escribir con poca o
ninguna modificación en distintos tipos de computadora.

‡ Independencia : Los lenguajes deben ser independientes de la máquina o sea una sentencia no
depende del diseño de hardware de una computadora en particular.

Los programas escritos en lenguaje de alto nivel no son entendibles directamente por la maquina.

Necesitan ser traducidos a instrucciones en lenguaje de maquina que lo entienda la computadora.

Los programas que realizan esta traducción se llaman programas compiladores.

Los programas escritos en lenguaje de alto nivel se llaman programas fuentes

El compilador traduce el programa fuente en un programa objeto, el cual se utiliza en la fase de

ejecución del programa.

Algunas computadoras o microcomputadoras utilizan unos programas similares llamados

programas interpretes que traducen los programas.

El proceso de traducción de un programa fuente se denomina interpretación o compilación, según

sea el programa.

Un interprete traduce y ejecuta una traducción (sentencia) en código fuente cada vez. Los
programas interpretados generalmente se ejecutan mucho mas lentamente que los programas
compilados; sin embargo los interpretes son más fáciles de utilizar y la depuración (corrección) de
errores es mucho más cómoda.

Basic, Basica ( Basic Avanced ) , GW-Basic, son interpretes y Quick Basic es un compilador.

Fortran , Pascal , C , son programas compiladores.

Los lenguajes de programación C , Turbo C, C++ , son programas orientados a objeto. Windows
fue desarrollado en C

Visual Basic es un lenguaje orientado a eventos y en el futuro muy extremadamente cercano , ¡ ya !

esta influyendo en la informática universal. El lenguaje Quick Basic realiza la traducción y
ejecución cada vez que se ejecuta una línea.

Este lenguaje reúne las características de interprete en cuanto su facilidad de edición, ejecución y
puesta a punto de programas y de compilador por su estructura y velocidad de ejecución.

Programas:

lenguaje nivel ejemplos características

maquina bajo Asembler

Interprete, compilador alto Quick Basic

Pascal

C++

1. Software;

Software del sistema: es el conjunto de programas indispensables para la maquina funcione

(programas del sistema):

‡ Sistema operativo: DOS------

Windows
‡ Editores / Procesadores de textos

‡ Programas compiladores e interpretes.

‡ Lenguajes de programación

Software de aplicaciones: programas de utilidad:

Paquete Aplicación

Excel, Lotus 1 2 3. Hoja de calculo

Autocad Diseño mecánico, eléctrico, civil, topográfico, arquitectónico

Dbase, Accsess, Fox Pro Programa de Base de Datos

Power Point, Harvard Graphics Presentador de hipertexto

Mathcad Hoja de calculo análisis matemático

Software :

Sistema Operativo de Disco

Windows

Lenguajes de Programación:

Programación en Quick Basic

Quick Basic versión 4.5

Quick Basic

Caracteristicas :

Lenguaje : alto nivel

Compilado

Secuencial

Compilado

Estructurado: top-down
 Pruebas E Implementacion Sistema
Pruebas:

Antes de que pueda se usado el sistema de informacion debe ser probado. Durante este proceso se
debe poner en practica todas las estrategias posibles para garantizar que el usuario inicial del
sistema se encuentre libre de problemas.
La implementacion es la ùltima fase del desarrollo de sistemas. Es el proceso de instalar equipos o
software nuevo, como resultado de un anàlisis y diseño previo como resultado de la situaciòn o
mejoramiento de la forma de llevar acabo un proceso automatizado. Al implementar un sistema lo
primero que debemos hacer es asegurarnos què el sistema sea operacional o que funcione de
acuerdo a los requerimientos del analisis y permitir que los usuarios puedan operarlos.

Durante el proceso de implementación y prueba se deben poner en practica todas las estrategias
posibles para garantizar que el usuario inicial del sistema se encuentre libre de problemas lo cual se
puede describir durante este proceso t llevar acabo la correcciones.

Existen seis pruebas básicas:

1. Prueba de carga máxima

2. Prueba de almacenamiento

3. Prueba de tiempo de ejecución

4. Prueba de recuperación

5. Prueba de procedimientos

6. Prueba de recursos humanos

Prueba de carga máxima: Consiste en probar si el sistema puede manejar el volumen de actividades
que ocurren cuando el sistema esta en el punto mas alto de su demanda de procesamiento.

Prueba de almacenamiento: Determina si el sistema puede almacenar una alta cantidad proyectada
de datos tanto en sus dispositivos de discos fijos y movibles.

Prueba de tiempo de ejecución: Determina el tiempo de maquina que el sistema necesita para
procesar los datos de una transición. Prueba de recuperación: Probar la capacidad del sistema para
recuperar datos y restablecer después de una falla.

Prueba de procedimientos: Evaluar la claridad, validez, seguridad asi como su facilidad y sencillez
de los manuales de procedimientos.

Prueba de recursos humanos: Se determinan como utilizar los usuarios el sistema al procesar datos
o procesar informes.

Implementación:
Es la última fase del desarrollo de sistemas. Es el proceso de instalar equipos o software nuevo,
como resultado de un análisis y diseño previo como resultado de la situación o mejoramiento de la
forma de llevar acabo un proceso automatizado.

Al implementar un sistema lo primero que debemos hacer es asegurarnos que el sistema sea
operacional o que funcione de acuerdo a los requerimientos del análisis y permitir que los usuarios
puedan operarlos.

Existen varios enfoques de implementación:

‡ Es darle responsabilidad a los grupos

‡ Uso de diferentes estrategias para el enfrentamiento de usuarios.

‡ El analista necesita formular medidas de desempeño con los cuales evalúa a los usuarios.

Introduccion a La Ingenieria De Software

Durante los primeros años de la inforamacion la programacion era un arte para el que no existian
metodologias. Era un proceso frealizado sin planificacion alguna.En esta epoca, la programacion se
desarrollaba a medida de cada necesidad, y en consecuencia, tenia muy poca difuciòn.

En una segunda època(a partir de 160)se establecio el software como producto y aparecieron las
empresas dedicadas al desarrollo y distribucion masivo del mismo.
El termino ingenieria de software fue utilizado por primera vez por Feliz Baver en la primera
conferencia sobre desarrollo de software patrocinada por el comite de Ciencias de la OXAN
celebrado en Garmich Alemania en 168.

La tercera comenzo a medidas de los 70`s cuando los SI aumentaron su complejidad y nacieron las
redes de ordenadores. Esto supuso mucha presion para los desarrolladores lo que provoco´la crisis
sw´. Esta epoca termino al aparecer los microprocesadores.

La cuarta era la evoluciòn comienza hacia 10 y se dirige al impacto colectivo de los ordenadores
y el software. Aparecen los tecnicas de redes neuronales, junto con la lògica difusa.
Definicion Ingenieria De Software
Es una disciplina o área de la información o ciencias de la computación, que ofrece métodos o
técnicas para desarrollar y mantener software de calidad que resuelven problemas de todo tipo. Hoy
día es cada vez más frecuente la consideración de la Ingeniería del Software como una nueva área
de la Ingeniería y el Ingeniero de Software comienza a ser una profesión implantada en el mundo
natural, laboral, internacional con derechos.

La Ingeniería del Software trata de áreas muy diversas de la informática y de las ciencias
computacionales, tales como constantes de compiladores, sistemas operativos o desarrollos de
Internet.
³La ingeniería de Software es el esablecimiento y suso de principios sólidos de la ingeniería para
obtener económicamente un software confiable y que funcione de modo eficiente en máquinas
reales´ (Fritz Baver)

La IEE la define como la aplicación de un enfoque sistemático, disciplinado y cuantificable al

desarrollo, operación y mantenimiento de software, es decir, la aplicación de la ingeniería al
software.
Historia Ingenieria Software
Historia

La Ingeniería del Software, término utilizado por primera vez por Fritz Bauer en la primera
conferencia sobre desarrollo de software patrocinada por el Comité de Ciencia de la OTAN
celebrada en Garmisch, Alemania, en octubre de 168, puede definirse según Alan Davis como ³la
aplicación inteligente de principios probados, técnicas, lenguajes y herramientas para la creación y
mantenimiento, dentro de un coste razonable, de software que satisfaga las necesidades de los
usuarios´« Fuente Wikipedia..
El término ingeniería del software empezó a usarse a finales de la década de los sesenta, para
expresar el área de conocimiento que se estaba desarrollando en torno a las problemáticas que
ofrecía el software en ese momento.

En esa época, el crecimiento espectacular de la demanda de sistemas de computación cada vez más
y más complejos, asociado a la inmadurez del propio sector informático (totalmente ligado al
electrónico) y a la falta de métodos y recursos, provocó lo que se llamó la crisis del software (en
palabras de Edsger Dijkstra) entre los años 165 y 185.

Durante esa época muchos proyectos importantes superaban con creces los presupuestos y fechas
estimados, algunos de ellos eran tan críticos (sistemas de control de aeropuertos, equipos para
medicina, entre otros) que sus implicaciones iban más allá de las pérdidas millonarias que causaban.

La crisis del software pasó, no tanto por la mejora en la gestión de los proyectos, sino en parte
porque no es razonable estar en crisis más de veinte años, y en parte porque se estaban haciendo
progresos en los procesos de diseño y metodologías.

Así pues, desde 185 hasta el presente, han ido apareciendo herramientas, metodologías y
tecnologías que se presentaban como la solución definitiva al problema de la planificación,
previsión de costes y aseguramiento de la calidad en el desarrollo de software. Entre las que se
encuentran la programación estructurada, la programación orientada a objetos, a los aspectos, las
herramientas CASE, el lenguaje de programación ADA, la documentación, los estándares, CORBA,
los servicios web y el lenguaje UML (entre otros) fueron todos anunciados en su momento como la
solución a los problemas de la ingeniería del software, la llamada ³bala de plata´ (por silver bullet).
Y lo que es más, cada año surgen nuevas ideas e iniciativas encaminadas a ello.

En combinación con las herramientas, también se han hecho esfuerzos por incorporar los métodos
formales al desarrollo de software, argumentando que si se probaba formalmente que los desarrollos
hacían lo que se les requería, la industria del software sería tan predecible como lo son otras ramas
de la ingeniería.
Caracteristicas Del Software
1. El software se desarrolla o construye; no se manufactura en el sentido clásico.

A pesar de que existen similitudes entre el desarrollo del software y la manufactura del hardware,
las dos actividades serian diferentes en lo fundamental. En ambas la alta calidad se alcanza por
medio del buen diseño, la fase de manufactura del hardware puede incluir problemas de calidad
existentes en el software.

2. El software no se desgasta.
El software es inmune a los males ambientales que desgasten el hardware. Por lo tanto la curva de
tasas de fallas para el software debería tener la forma de la ³curva idealizada´. Los defectos sin
descubrir causan tasas de fallas altas en las primeras etapas de vida de un programa. Sin embargo,
los errores se corrigen y la curva se aplana: el software no se desgasta, pero si se deteriora.

3. A pesar de que la industria tiene una tendencia hacia la construcción por componentes, la
mayoría del software aun se construye a la medida.

Un componente de software se debe diseñar e implementar de forma que puede utilizarse en

muchos programas diferentes.

Los componentes reutilizables modernos encapsulan tanto los datos como el proceso se aplican a
estos, lo que permite al ingeniero de software crear nuevas aplicaciones nuevas a partir de partes
reutilizables.
 Mitos Del Software
Los mitos del software-creencias acerca del software y de los procesos empleados para construirlo-
se pueden rastrear hasta los primeros días de la computación. Los mitos tienen ciertos atributos que
los convierten en insidiosos.

Mitos de la administración

Los gestores con responsabilidad sobre el software, como los gestores en la mayoría de las
disciplinas, están normalmente bajo la presión de cumplir las propuestas, hacer que no se retrase el
proyecto y mejorar la calidad. Un gestor de software se agarra frecuentemente a un mito del
software.

Mito: Si se falla en la planificación, se puede añadir mas programadores y adelantar el tiempo

perdido.
Mitos del cliente

En muchos casos, el cliente cree en los mitos que existen sobre el software, debido a que los
gestores y desarrolladores de software hacen muy poco para corregir la mala información. Los
mitos conducen a que el cliente se cree una falsa expectativa y, finalmente, quede insatisfecho con
el desarrollador del software.

Mito: Si los requisitos del proyecto cambian continuamente, los cambios pueden acomodarse
fácilmente, ya que el software es flexible.

Mitos de los desarrolladores

Los mitos en los que aun creen muchos desarrolladores se han ido fomentando durante 50 años de
cultura informática. Durante los primeros días del desarrollo del software, la programación se veía
como un arte. Las viejas formas y actitudes tardan en morir.
Mito: Una vez que escribimos el programa y hacemos que funcione, nuestro trabajo ha terminado.
Capas Ingenieria De Software
La ingeniería de software es una tecnología multicapa, cualquier enfoque de ingeniería debe
apoyarse sobre un compromiso de organización de calidad.

El fundamento de la ingeniería de software es la capa del proceso. El proceso de la ingeniería de

software es la unión que mantiene juntas las capas de tecnología y que permiten un desarrollo
racional y oportuno de la ingeniería de software. El proceso define un marco de trabajo para un
conjunto de áreas clave de proceso que se deben establecer para la entrega de la tecnología de la
ingeniería de software.

Los métodos de la ingeniería de software indican como construir técnicamente el software.

Los métodos abarcan una gran gama de tareas que incluyen análisis de requisitos, diseño,
construcción de programas, pruebas y mantenimiento.

Las herramientas de la ingeniería de software proporcionan un enfoque automático o

semiautomático para el proceso y para los métodos.

Enfoque en capas

Herramientas

Metodos

Procesos

Un enfoque de Calidad
El Proceso Del Software
Conjunto estructurado de actividades requeridas para desarrollar un sistema de software.

Especificación.

Diseño.

Validación.

Evolución.

Las actividades varían dependiendo de la organización y del tipo de sistema a desarrollarse.

Debe estar explícitamente modelado si va a ser bien administrado.

Caracteristicas

Entendible
Se encuentra el proceso bien definido y es entendible ?

Visible

El proceso es visible al exterior ?

Soportable

Puede el proceso ser soportado por herramientas CASE ?

Aceptable

El proceso es aceptado por aquellos involucrados en el ?.

Confiable

Los errores del proceso son descubiertos antes de que se conviertan

en errores del producto ?

Robusto

Puede continuar el proceso a pesar de problemas inesperados ?

Mantenible

Puede el proceso evolucionar para cumplir con los objetivos organizacionales ?

Rapidez

Que tan rápido puede producirse el sistema ?

Problemas

Normalmente, las especificaciones son incompletas o anómalas.

No existe una distinción precisa entre la especificación, el diseño y la manufactura

Solo hasta que el sistema se ha producido se puede probar

El software no se puede remplazar siempre durante el mantenimiento

Software De Alta Calidad
El instituto de la ingeniería del software (CEI) ha desarrollado un modelo completo de un amplio
proceso basado en un conjunto de capacidades de software y de sistemas que deben de estar
presentes conforme las organizaciones alcanzan diferentes grados de capacidad y madurez.
MODELO DE CAPACIDAD DE MADUREZ (IMCM)

Nivel 0: Incompleto. El área del proceso (por ejemplo, la gestión de requisitos) aún no se realiza o
todavía no alcanza todas las metas y objetivos definidos para el nivel 1 de capacidad.
Nivel 1: Realizado. Todas las metas específicas de área del proceso (como las definió la IMCM)
han sido satisfechas. Las tareas de trabajo requeridas para producir el producto específico han sido
realizadas.

Nivel 2: Administrado. Todos los criterios del nivel 1 han sido satisfechos. Además, todo el trabajo
asociado con el área de proceso se ajusta a una política organizacional definida; toda la gente que
ejecuta el trabajo tiene acceso a recurso adecuados para realizar su labor; los clientes están
implicados de manera activa en el área de proceso, cuando esto se requiere; todas las tareas de
trabajo y productos están ³monitoreadas, controlados y revisados; y son evaluados en apego a la
descripción del proceso´

Nivel 3: Definido. Todos loa criterios del nivel 2 se han cumplido. Además, el proceso esta
³adaptado al conjunto de procesos de estándar de la organización, de acuerdo con las políticas de
adaptación de esta misma, y contribuye a la información de los productos del trabajo, mediciones y
otras mejorías del proceso para los activos del proceso organizacional´.

Nivel 4: Administrativo en forma cuantitativa. Todos los criterios del nivel 3 han sido cumplidos.
Además, el área del proceso se controla y mejora mediante mediciones y evaluación cuantitativa.
³Los objetivos cuantitativos para la calidad y el desempeño del proceso están establecidos y se
utilizan como un criterio para administrar el proceso´.

Nivel 5: Mejorado. Todos loa criterios del nivel 4 han sido satisfechos. Además, el área del proceso
³se adapta y mejora mediante el uso de medios cuantitativos (estadísticos) para conocer las
necesidades cambiantes del cliente y mejorar de manera continua la eficacia del área del proceso
que se está considerando´.
Coordinador de Investigación:

ING. JOSE ANTONIO FLORES LARA

Tecnologico ITSZO

Objetivos:

Proveer el conocimiento teórico y práctico para realizar el tipo de test apropiado para cada
aplicación garantizando el mayor nivel de calidad. Conocer la importancia del Testing de Software
como forma de asegurar la calidad de los procesos de desarrollo, implementación y mantenimiento.
Adquirir práctica en el conjunto de actividades que verifican que el software desarrollado o
modificado cumple los requerimientos solicitados en forma satisfactoria.

Reconocer las diferentes pruebas de software a realizar en todas las fases del ciclo de vida.

Reconocer los problemas más comunes de los desarrollos Web.

Aplicar las técnicas tradicionales de calidad sobre desarrollos Web.

Relacionar los conocimientos adquiridos como Operador de Testing desde el Ciclo de Vida de
Testing en el Ciclo de Vida de Desarrollo. Identificar variables involucradas en la estimación de
esfuerzo para determinar las formas de realizar el mismo.

Utilizar herramientas de testing para llevar el seguimiento de los casos de pruebas planteados,
automatizados o no.
Factores De Calidad Y Productividad
PROCESO DEL SOFTWARE PERSONAL (PSP)

Cada desarrollador usa distintos procesos para construir un software, estos pueden ser no eficientes
o exitosos o también pueden cambiar a diario, pero existe un proceso.

WATTS HUMPHREY dice que para cambiar un proceso inefectivo se tiene que pasar por cuatro
fases y estas requieren capacitación e instrumentación. PSP resalto la medida personal al
profesional de la planeación, también hace responsables al profesional de la planeación del proyecto
y la calidad de todos los productos.

Existen 5 actividades de marco de trabajo que son:

1. Planeación: Aquí se selecciona los requisitos y se desarrolla el tamaño y la estimación de los
recursos. Estas mediciones se anotan en las plantillas y al final se identifican las tareas de desarrollo
y se crea un programa del proyecto.

2. Diseño de alto nivel: Se analizan los factores externos y se construyen prototipos cuando hay
incertidumbre.

3. Revisión del diseño de alto nivel: Se aplican los métodos de verificación a los errores que se
descubrieran en el diseño.

4. Desarrollo: Se refina y revisa el diseño y se verifica el código y se compila, además todas las
mediciones se guardan para los resultados de trabajo.

5. Análisis de resultados: Aquí se determina la efectividad del proceso, analizando todos los datos
que se tienen.

El PSP destaca que cada ingeniero tiene la necesidad de identificar los errores y de entender la
importancia y los tipos de errores que suelen cometerse.

Factores de calidad y productividad

La calidad del software desarrollado, así como la productividad del programador son factores de
difícil, pero no imposible, medida. Existen una serie de factores que inÀuyen en la calidad y
productividad, que son los siguientes y que ayudan a realizar dicha medida:

La capacidad individual.- En este fáctor intervienen la competencia del individuo y su familiaridad

con el área de la aplicación.
La comunicación entre los miembros del equipo.- Es un factor importante, ya que el traba jo en la
mayor parte de las ocasiones no es individual y debe integrarse con el que ha sido desarrollado por
otros miembros del equipo.

La complejidad del producto.- Este factor depende del tipo de aplicación a desarrollar y es de difícil
estimación, ya que muchas veces hasta la fase de desarrollo no es posible comprender en toda su
perspectiva las complicaciones que conlleva su realización.

Utilización de una notación adecuada.- Este factor es de gran importancia para facilitar la
comunicación entre las partes involucradas (incluido el usuario).

Empleo de métodos sistemáticos.- Es importante que se empleen técnicas que sean de amplio
consenso y bien conocidas por los integrantes del equipo de desarrollo de la aplicación. También es
fundamental que estas técnicas se empleen de manera sistemática sobre todas las aplicaciones de
características semejantes con objeto de facilitar el análisis de coste y tiempo, y también para poder
observar la trayectoria profesional de los miembros del equipo.

Conocer el tiempo disponible.- Este factor esta vinculado a otros anteriores, ya que es básico
conocer el tiempo que puede aportar cada miembro del equipo y en que plazos, sobre todo en
función de las tareas a realizar y de la mejor o peor productividad de determinados miembros en
cada una de ellas.

Existencia de facilidades y recursos externos.- Este factor, es determinante en la medida en que se

conozcan productos o herramientas (automáticas o no) que faciliten las labores de desarrollo e
integración de la aplicación. En mayor medida cuando se conocen aplicaciones parecidas de fácil
trasportabilidad y modi cación que puedan servir de base a la que hay que realizar.

Como en el resto de las actividades industriales, en el desarrollo de software, también es importante

realizar una buena plani cación del trabajo y una buena asignación de recursos a los distintos
miembros del equipo. Una mala plani cación termina con una mala aplicación o una aplicación
terminada a destiempo (disgusto del peticionario), lo cual supone un fracaso. Varios fracasos
consecutivos de este mismo estilo suponen la ruina para la mayor parte de las empresas del sector,
debido a la competencia existente.
Paradigmas De La Ingenieria De Software
Paradigmas de programación:

a) Los que soportan técnicas de programación de bajo nivel (copia de ficheros frente estructuras de
datos compartidos)

b) Los que soportan métodos de diseño de algoritmos (programación dinámica)

c) Los que soportan soluciones de programación de alto nivel.

La ingeniería de software esta compuesta por una serie de pasos de abarcan los métodos, las
herramientas y los procedimientos antes mencionados.
Estos pasos se denominan frecuentemente paradigmas de la ingeniería de software.
La elección de un paradigma para la ingeniería de software se lleva a cabo de acuerdo con la
naturaleza del proyecto y de la aplicación, los métodos, herramientas a usar, los controles y entregas
requeridos.

ING. LAURIEL ALIGHIERI REYES LOPEZ

PARADIGMAS DE LA INGENIERIA DE SOFTWARE

La ingeniería de software surge de la ingeniería de sistemas y de hardware. Abarca un conjunto de

tres elementos que facilitan el control sobre el proceso de desarrollo de software y suministran las
bases para construir software de calidad de una forma productiva:

‡ Métodos

‡ Herramientas

‡ Procedimientos

Métodos que indican cómo construir el software técnicamente e incluyen un amplio espectro de
métodos para la planificación, la estimación, el análisis, el diseño, codificación, prueba y
mantenimiento.

Herramientas automáticas y semiautomáticas que apoyan a la aplicación de los métodos. Cuando se

integran las herramientas de forma que la información creada por una herramienta puede ser usada
por otra, se establece un sistema para el soporte del desarrollo de software, llamado Ingeniería de
Software Asistida por Computadora ( CASE ).

Procedimientos que definen la secuencia en la que se aplican los métodos, las entregas, los
controles de calidad y guías para evaluación del progreso.

La Ingeniería de Software está compuesta por una serie de pasos que abarcan los métodos,
herramientas y procedimientos mencionados, a los que se denominan Paradigmas de la Ingeniería
de Software.
El Enfoque Estructurado

En el Enfoque Estructurado se usan los DFD (Diagrama de Flujo de Datos) como principal
herramienta para entender al sistema antes de plasmarlo a codigo fuente. DFD es un diagrama en el
q participan procesos (metodos), flujo de datos (argumentos) y archivos (base de datos).

Hay de diferentes niveles dependiendo la complejidad del sistema q analiza. hablando de lenguajes
Tiene muchas diferencia con la OO. un minimo cambio en el codigo puede llegar alterar al resto del
programa cosa que en uno OO bien encarado eso no sucede lo cual es una ventaja por que asi no se
pierde tiempo en arreglar cosas ya hechas. Otra desventaja es que una porcion de codigo en
lenguaje estructurado es dificil que pueda servir en otros proyectos, esto si es habitual en lenguajes
OO, con solo importar clases ya hechas se escribe menos codigo y se ahorra tiempo.
Diagramas De Flujos De Datos
Un diagrama de flujo de datos (DFD) es un modelo lógico-gráfico para representar el
funcionamiento de un sistema en un proyecto software. Sus elementos gráficos son círculos,
flechas, y rectángulos cerrados o abiertos. Los cerrados representan entidades externas mientras que
los abiertos describen almacenes o archivos. Los círculos significan procesos y las flechas flujos de
datos desde, o hacia, un proceso.

En un DFD también se utiliza la escritura. Los flujos, entidades externas y los almacenes se
etiquetan con un nombre. Los procesos se etiquetan con un número y un verbo en infinitivo con
objeto directo.
Un diagrama de flujo de datos puede ser profundizado expandiendo algunos de sus procesos en
subprocesos, en este caso la etiqueta tendrá un número adicional. No hay un límite para el número
de procesos.

Un diagrama de flujo de datos (DFD por sus siglas en español e inglés) es una representación
gráfica del ³flujo´ de datos a través de un sistema de información. Un diagrama de flujo de datos
también se puede utilizar para la visualización de procesamiento de datos (diseño estructurado). Es
una práctica común para un diseñador dibujar un contexto a nivel de DFD que primero muestra la
interacción entre el sistema y la entidades externas. Este contexto a nivel de DFD se ³explotó´ para
mostrar más detalles del sistema que se está modelando.

Los diagramas de flujo de datos fueron inventados por Larry Constantine, el desarrollador original
del diseño estructurado, basado en el modelo de computación de Martin y Estrin: ³flujo gráfico de
datos´ . Los diagramas de flujo de datos(DFDs) son una de las tres perspectivas esenciales de
Análisis de Sistemas Estructurados y Diseño por Método SSADM. El patrocinador de un proyecto y
los usuarios finales tendrán que ser informados y consultados en todas las etapas de una evolución
del sistema. Con un diagrama de flujo de datos, los usuarios van a poder visualizar la forma en que
el sistema funcione, lo que el sistema va a lograr, y cómo el sistema se pondrá en práctica. El
antiguo sistema de diagramas de flujo de datos puede ser elaborado y se comparó con el nuevo
sistema de diagramas de flujo para establecer diferencias y mejoras a aplicar para desarrollar un
sistema más eficiente. Los diagramas de flujo de datos pueden ser usados para proporcionar al
usuario final una idea física de cómo resultarán los datos a última instancia, y cómo tienen un efecto
sobre la estructura de todo el sistema. La manera en que cualquier sistema es desarrollado puede
determinarse a través de un diagrama de flujo de datos. El desarrollo de un DFD ayuda en la
identificación de los datos de la transacción en el modelo de datos.

Los diagramas derivados de los procesos principales se clasifican en niveles, los cuales son:

Nivel 0: Diagrama de contexto.

Nivel 1: Diagrama de nivel superior.

Nivel 2: Diagrama de detalle o expansión.

Diccionarios De Datos
Diccionario de datos

El diccionario de datos es un listado organizado de todos los datos que pertenecen a un sistema.

El objetivo de un diccionario de datos es dar precisión sobre los datos que se manejan en un
sistema, evitando así malas interpretaciones o ambigüedades.
Define con precisión los datos de entrada, salida, componentes de almacenes, flujos, detalles de las
relaciones entre almacenes, etc.

Los diccionarios de datos son buenos complementos a los diagramas de flujo de datos, los
diagramas de entidad-relación, etc.
Un diccionario de datos es un conjunto de metadatos que contiene las características lógicas de los
datos que se van a utilizar en el sistema que se programa, incluyendo nombre, descripción, alias,
contenido y organización.

Estos diccionarios se desarrollan durante el análisis de flujo de datos y ayuda a los analistas que
participan en la determinación de los requerimientos del sistema, su contenido también se emplea
durante el diseño del proyecto.

Identifica los procesos donde se emplean los datos y los sitios donde se necesita el acceso inmediato
a la información, se desarrolla durante el análisis de flujo de datos y auxilia a los analistas que
participan en la determinación de los requerimientos del sistema, su contenido también se emplea
durante el diseño.

En un diccionario de datos se encuentra la lista de todos los elementos que forman parte del flujo de
datos de todo el sistema. Los elementos mas importantes son flujos de datos, almacenes de datos y
procesos. El diccionario de datos guarda los detalles y descripción de todos estos elementos.

NOTACIÓN

Las estructuras de datos son descritas por lo general usando notación algebraica. La notación
algebraica usa los siguientes símbolos:

1. Un signo de igual (=) significa ³está compuesto de´.

2. Un signo de más (+) significa ³y´.

3. Las llaves { } indican elementos repetidos, también llamados grupos repetidos o tablas. Puede
haber uno o varios elementos repetidos dentro del grupo. El grupo repetido puede tener condiciones,
tales como una cantidad fija de repeticiones o límites, superior e inferior para la cantidad de
repeticiones.

4. Los corchetes [ ] representan una situación disyuntiva. Puede estar presente un elemento u otro,
pero no ambos. Los elementos listados entre corchetes son mutuamente excluyentes, y se separan
mediante barras ( | ).

5. Los paréntesis ( ) representan un elemento opcional. Los elementos opcionales pueden ser
dejados en blanco en las pantallas de captura, y pueden contener espacios o ceros para los campos
numéricos en las estructuras de archivo.

6. La ³@´ (o una definición subrayada) identifica la llave para un almacén de datos.

7. Una frase entre asteriscos es un comentario (* *).

EJEMPLO:

Nombre = Título + Primer-nombre + Apellido-paterno + Apellido-materno

Título = [ Sr | Sra | Dr | Ing]

Primer-nombre = {caracter}

Apellido-paterno = {caracter}

Apellido-materno = {caracter}

caracter = [A-Z|a-z| |¶] a

DEFINICIONES

Una definición de un dato se introduce mediante el símbolo ³=´; en este contexto el ³=´ se lee como
³está definido por´, o ³está compuesto de´, o ³significa´. Para definir un dato completamente, la
definición debe incluir: ‡ El significado del dato en el contexto de la aplicación. Esto se documenta
en forma de comentario. ‡ La composición del dato, si es que está compuesto de otros elementos
significativos. ‡ Los valores que el dato puede tomar, si se trata de un dato elemental que ya no
puede ser descompuesto.

DATOS ELEMENTALES

Son aquellos para los cuales no hay una descomposición significativa. Por ejemplo, puede ser que
no se requiera descomponer el nombre de una persona en primer-nombre, apellido-materno y
apellido-paterno; esto depende del contexto del sistema que se esté modelando. Cuando se han
identificado los datos elementales, deben ser introducidos en el DD y proveer una breve descripción
que describa el significado del dato. En el caso de que el dato tenga un nombre significativo, se
puede omitir la descripción, sin embargo, es importante especificar las unidades de medida que el
dato puede tomar.

Ejemplo: Peso = * peso del paciente al ingresar al hospital *

‡ unidad: kilo, rango:2±150 *

Altura = * unidad: cm, rango: 100±200 * Sexo = * valores : [F|M] * APGR Ingeniería de Software I
Análisis Estructurado 24

DATOS OPCIONALES

Un dato opcional es aquel que puede o no estar presente como componente de un dato compuesto.
Ejemplo: Dirección = calle + número + (ciudad) + (país) + (código-postal)

SELECCIÓN
Indica que un elemento consiste de exactamente una opción de un conjunto de alternativas.
Ejemplos:

Sexo = [ Femenino | Masculino ]

Tipo-de-cliente = [ Gubernamental | Académico | Industria | Otros ]

ITERACIÓN

Se usa para indicar ocurrencias repetidas de un componente en un elemento compuesto. Ejemplo:

Orden-de compra = nombre-cliente + dirección-de-envío + {artículo} significa que una orden de
compra siempre debe contener un nombre de cliente, una dirección de envío y cero o más
ocurrencias de un artículo. Ejemplo: Se pueden especificar límites superiores e inferiores a las
iteraciones. Orden-de compra = nombre-cliente + dirección-de-envío + 1{artículo}10 significa que
una orden de compra siempre debe contener un nombre de cliente, una dirección de envío y de 1 a
10 artículos. APGR Ingeniería de Software I Análisis Estructurado 25 Ejemplos de iteraciones con
límites: a = 1{b} a = {b}10 a = 1{b}10 a = {b}
Diseño De Modulos
Un modelo de datos es un lenguaje orientado a describir una Base de Datos. Típicamente un
Modelo de Datos permite describir:

‡ Las estructuras de datos de la base: El tipo de los datos que hay en la base y la forma en que se
relacionan.

‡ Las restricciones de integridad: Un conjunto de condiciones que deben cumplir los datos para
reflejar correctamente la realidad deseada.

‡ Operaciones de manipulación de los datos: típicamente, operaciones de agregado, borrado,

modificación y recuperación de los datos de la base.
Otro enfoque es pensar que un modelo de datos permite describir los elementos de la realidad que
intervienen en un problema
dado y la forma en que se relacionan esos elementos entre sí.

No hay que perder de vista que una Base de Datos siempre está orientada a resolver un problema
determinado, por lo que los dos enfoques propuestos son necesarios en cualquier desarrollo de
software.

Una opción bastante usada a la hora de clasificar los modelos de datos es hacerlo de acuerdo al
nivel de abstracción que presentan: Modelos de Datos Conceptuales

Son los orientados a la descripción de estructuras de datos y restricciones de integridad. Se usan

fundamentalmente durante la etapa de Análisis de un problema dado y están orientados a
representar los elementos que intervienen en ese problema y sus relaciones. El ejemplo más típico
es el Modelo Entidad-Relación.

Modelos de Datos Lógicos

Son orientados a las operaciones más que a la descripción de una realidad. Usualmente están
implementados en algún Manejador de Base de Datos. El ejemplo más típico es el Modelo
Relacional, que cuenta con la particularidad de contar también con buenas características
conceptuales (Normalización de bases de datos).

Modelos de Datos Físicos

Son estructuras de datos a bajo nivel implementadas dentro del propio manejador. Ejemplos típicos
de estas estructuras son los Árboles B+, las estructuras de Hash, etc.

Un (DfD) presenta ser subdividido en diferentes partes, que llamaremos modulos conteniendo cada
uno de ellos procedimientos manuales o automatizados, a fin de que el sistema pueda ser
desarrolladoy ejecutado en unidades menores, mas faciles de implementar manejar y contolar.

Estos modulos pueden ser un programa, un procedimiento, una relacion de operaciones o comandos
Descomposicion En Procesos
Las organizaciones, funcionales, desarrollan multiples actividades el componente basico de estas
corresponde a la tarea, entendida como una microactividad que se responsabiliza a una sola persona.

Grupos de tareas conforman actividades mas complejas que se denominan procesos.

Todos los procesos tienen entradas (recursos humanos,tecnologicos materiales, etc.) para el
desarrollo de las actividades que lo conforman; como salidas se esperan productos, srvicios,
informacion, activos financieros, etc.

Entiende todo proceso como un : ³CONJUNTO DE TAREAS LOGICAMENTE

RELACIONADAS QUE EXISTEN PARA OBTENER UN RESULTADO BIEN DEFINIDO
DENTRO DE UN NEGOCIO´.
El Enfoque Orientado a Objetos
Historia

Vivimos 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. Pueden ser clasificados, descritos,
organizados, combinados, manipulados y creados. Por eso 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.
La primera vez que se propuso un enfoque orientado a objetos para el desarrollo de software fue a
finales de los años sesenta. Sin embargo, las tecnologías de objetos han necesitado casi veinte años
para llegar a ser ampliamente usadas. Durante los años 0, la ingeniería del software orientada a
objetos se convirtió en el paradigma de elección para muchos productores de software y para un
creciente número de sistemas de información y profesionales de la ingeniería.

Las tecnologías de objetos llevan a reutilizar, y la reutilización (de componente de software) lleva a
un desarrollo de software más rápido y a programas de mejor calidad. El software orientado a
objetos es más fácil de mantener debido a que su estructura es inherentemente poco acoplada. Esto
lleva a menores efectos colaterales cuando se deben hacer cambios. Los sistemas orientados a
objetos son más fáciles de adaptar y más fácilmente escalables (pueden crearse grandes sistemas
ensamblando subsistemas reutilizables).
Hacia mediados de los 80, los beneficios de la programación orientada a objetos empezaron a
obtener reconocimiento, y el diseño de objetos pareció ser un enfoque sensato para la gente que
deseaba utilizar el lenguaje de programación orientada a objetos. Un enfoque orientado a objetos
para programar ofrece muchos beneficios sobre un enfoque estructurado.

El análisis orientado a objetos y su diseño se enfoca en los objetos. Los objetos tienen ciertos
comportamientos y atributos que determinan la manera en que interactúan y funcionan. No se
intenta proporcionar un orden para las acciones al momento del diseño debido a que los objetos
funcionan basados en la manera en que funcionan otros objetos. La programación orientada a
objetos ayuda a los desarrolladores a crear objetos que reflejan escenarios del mundo real.

Las implementaciones orientadas a objetos ocultan datos, lo cual significa que muestran únicamente
los comportamientos a los usuarios y ocultan el código subyacente de un objeto. Los
comportamientos que el programador expone son únicamente aquellos elementos que el usuario de
un objeto puede afectar.

El enfoque orientado a objetos permite que los objetos estén autocontenidos. Los objetos existen
por sí mismos, con una funcionalidad para invocar comportamientos de otros objetos. Al utilizar un
enfoque orientado a objetos, los desarrolladores pueden crear aplicaciones que reflejan objetos del
mundo real, como rectángulos, elipses y triángulos, además de dinero, números de partes y
elementos en un inventario.

En un enfoque orientado a objetos, los objetos, por definición, son modulares en su construcción.
Esto quiere decir que son entidades completas y, por lo tanto, tienden a ser altamente reutilizables.
Las aplicaciones orientadas a objetos se construyen sobre el paradigma de los mensajes o de los
eventos en donde los objetos envían mensajes a otros objetos, como el sistema operativo
Microsoft® Windows®.

1. El paradigma orientado a objetos

Durante muchos años el término Orientado a Objetos (OO) se usó para referirse a un enfoque de
desarrollo de software que usaba uno de los lenguajes orientados a objetos (Ada 5, C++, Eiffel,
Smalltalk, etc.). En el libro The Structure of Scientific Revolutions, el historiador Thomas K
describía un paradigma como un conjunto de teorías, estándar y métodos que juntos representan un
medio de organización del conocimiento: es decir, un medio de visualizar el mundo. En este
sentido, la programación orientada a objetos es un nuevo paradigma. La orientación a objetos fuerza
a reconsiderar nuestro pensamiento sobre la computación, sobre lo que significa realizar
computación y sobre cómo se estructura la información dentro de la computadora.

Jenkins y Glasgow observan que ³la mayoría de los programadores trabajan en un lenguaje y
utilizan sólo un estilo de programación. Ellos programan en un paradigma forzado por el lenguaje
que utilizan. Con frecuencia, no se enfrentan a métodos alternativos de resolución de un problema,
y por consiguiente tienen dificultad en ver la ventaja de elegir un estilo más apropiado al problema
a manejar´. Bobrow y Stefik sugieren que existen cuatro clases de estilos de programación:

V Orientados a procedimientos:Algoritmos.

V Orientados a objetos:Clases y Objetos.
V Orientados a lógica:Expresado en cálculo de predicados.
V Orientados a reglas: Reglas if-then.
No existe ningún estilo de programación idóneo para todas las clases de programación. La
orientación a objetos se acopla a la simulación de situaciones del mundo real.

2. Orientación a Objetos

La orientación a objetos puede describirse como el conjunto de disciplinas que desarrollan y

modelizan software que facilitan la construcción de sistemas complejos a partir de componentes.

El atractivo intuitivo de la orientación a objetos es que proporciona conceptos y herramientas con

las cuales se modela y representa el mundo real tan fielmente como sea posible. Estos conceptos y
herramientas orientados a objetos son tecnologías que permiten que los problemas del mundo real
sean expresados de modo fácil y natural.

Las técnicas orientadas a objetos proporcionan mejoras y metodologías para construir sistemas de
software complejos a partir de unidades de software modularizado y reutilizable. Se necesita un
nuevo enfoque para construir software en la actualidad. Este nuevo enfoque debe ser capaz de
manipular tanto sistemas grandes como pequeños y debe crear sistemas fiables que sean flexibles,
mantenibles y capaces de evolucionar para cumplir las necesidades del cambio.

La orientación a objetos trata de cubrir las necesidades de los usuarios finales, así como las propias
de los desarrolladores de productos software. Estas tareas se realizan mediante la modelización del
mundo real. El soporte fundamental es el modelo objeto.

Un objeto es la instancia de una clase. Una clase es la representación abstracta de un concepto en el

mundo real, y proporciona la base a partir de la cual creamos instancias de objetos específicos.
Como ejemplo, puede crear una clase que defina a un cliente. Después puede crear una nueva
instancia de la clase cliente para tener un objeto utilizable de Cliente. Para poder crear un objeto de
la clase cliente, debe crear una nueva instancia basada en esa clase.

Por ejemplo:

Private Objeto Customer' as Clase Customer'

Objeto Customer = New Clase Customer()

Cada objeto es un elemento único de la clase en la que se basa. Si una clase es como un molde,
entonces un objeto es lo que se crea a partir del molde. La clase es la definición de un elemento; el
objeto es el elemento. El molde para una figura de cerámica en particular, es como una clase; la
figura es el objeto.

Todos los objetos están compuestos de tres cosas:

Interfaz

La Interfaz es el conjunto de métodos, propiedades, eventos y atributos que se declaran como

públicos en su alcance y que pueden invocar los programas escritos para usar nuestro objeto.
Implementación

Al código dentro de los métodos se le llama Implementación. Algunas veces también se le llama
comportamiento, ya que este código es el que efectivamente logra que el objeto haga un trabajo útil.
Es importante entender que las aplicaciones del cliente pueden utilizar nuestro objeto aunque
cambiemos la implementación, siempre que no cambiemos la interfaz. Siempre que se mantengan
sin cambio nuestro nombre de método, su lista de parámetro y el tipo de datos de devolución,
podremos cambiar la implementación totalmente.

Estado

El estado o los datos de un objeto es lo que lo hace diferente de otros objetos de la misma clase. El
estado se describe a través de las variables del Miembro o de la Instancia. Las variables del
miembro son aquellas declaradas, de tal manera que están disponibles para todo el código dentro de
la clase. Por lo general, las variables del miembro son Privadas en su alcance. Algunas veces, se les
conoce como variables de la instancia o como atributos. Observe que las propiedades no son
variables del Miembro, ya que son un tipo de método que funciona para recuperar y establecer
valores.

¿Qué es una clase?

Una clase es esencialmente un proyecto, a partir del cual puede crear objetos. Una clase define las
características de un objeto, incluyendo las propiedades que definen los tipos de datos que ese
objeto puede contener y los métodos que describen el comportamiento del objeto. Estas
características determinan la manera en que otros objetos pueden acceder y trabajar con los datos
que se incluyen en el objeto.

Para definir una clase, se coloca la palabra clave Class antes del nombre de su clase, y después se
insertan los miembros de la clase (datos y métodos) entre la definición del nombre de la clase y la
instrucción End Class. Si incluye los métodos, entonces el código de cada método también se debe
incluir entre la declaración del método y el final del mismo.

Por ejemplo, si desea construir objetos que representen perros, puede definir una clase Perro con
ciertos comportamientos, como caminar, ladrar y comer, y propiedades específicas, como altura,
peso y color. Una vez que haya definido la clase Perro, puede crear objetos con base en esa clase.
Es importante observar que todos los objetos Perro creados con base en la clase perro compartirán
los mismos comportamientos, pero tendrán sus propios valores específicos para el mismo conjunto
de propiedades.

El siguiente ejemplo representa la definición de la clase Perro. Tome en consideración que ésta no
es una sintaxis estricta de VB.NET; simplemente es un ejemplo de la definición de clase.
Public Class Perro
Dim Altura As Decimal
Dim Peso As Decimal
Dim Color As String

Sub Caminar(ByVal Pasos As Integer)

End Sub
 Sub Ladrar()
End Sub

Sub Comer()
End Sub

End Class
#]

Vamos con otro ejemplo. El siguiente ejemplo define una nueva clase, Persona, con dos partes de
información relevante asociadas: el nombre de la persona, su fecha de nacimiento y un Método que
calcula la edad de la persona. A pesar de que la clase Persona se define en el ejemplo, no existe aún
el objeto Persona. Deberán ser creados.

[@
Public Class Persona
Private mstrNombre As String
Private mdtFechaNacimiento As Date

Public Function Edad() As Integer

Return DateDiff(DateInterval.Year, mdtFechaNacimiento, Now())
End Function
End Class

Una clase es un tipo definido por el usuario en contraposición a un tipo proporcionado por el
sistema. Al definir una clase, en realidad crea un nuevo tipo en su aplicación.

Ahora que ya sabéis todo esto, vamos con os elementos (propiedades) más importantes de este
modelo. Estas son:

V Abstracción.
V Encapsulamiento.
V Modularidad.
V Jerarquía.
V Polimorfismo.

Como sugiere Booch, si alguno de estos elementos no existe se dice que el modelo no es orientado a
objetos.

2.1. Abstracción:

La abstracción es uno de los medios más importantes, mediante el cual nos enfrentamos con la
complejidad inherente al software. La abstracción es la propiedad que permite representar las
características esenciales de un objeto, sin preocuparse de las restantes características (no
esenciales). Abstracción es la técnica de quitarle a una idea o a un objeto todos los
acompañamientos innecesarios hasta que los deja en una forma esencial y mínima. Una buena
abstracción elimina todos los detalles poco importantes y le permite enfocarse y concentrarse en los
detalles importantes.
Una abstracción se centra en la vista externa de un objeto, de modo que sirva para separar el
comportamiento esencial de un objeto de su implementación. Definir una abstracción significa
describir una entidad del mundo real, no importa lo compleja que pueda ser y, a continuación,
utilizar esta descripción en un programa.

El elemento clave de la programación orientada a objetos es la clase. Una clase se puede definir
como una descripción abstracta de un grupo de objetos, cada uno de los cuales se diferencia por su
estado específico y por la posibilidad de realizar una serie de operaciones. Por ejemplo, una pluma
estilográfica es un objeto que tiene un estado (llena de tinta o vacía) y sobre la cual se pueden
realizar algunas operaciones (escribir, poner o quitar la tapa, llenar de tinta si está vacía, etc.).

La idea de escribir programas definiendo una serie de abstracciones no es nueva, pero el uso de
clases para gestionar dichas abstracciones en lenguajes de programación ha facilitado
considerablemente su aplicación.

La abstracción es un principio de software importante. Una clase bien diseñada expone un conjunto
mínimo de métodos cuidadosamente considerados que proporcionan el comportamiento esencial de
una clase en una forma fácil de usar. Crear buenas abstracciones de software no es fácil. Encontrar
buenas abstracciones generalmente requiere de un entendimiento muy claro del problema y de su
contexto, gran claridad de pensamiento y amplia experiencia.

Existe un principio muy importante relacionado con la abstracción, y esta es, la Dependencia
mínima. Las mejores abstracciones de software hacen que las cosas complejas sean simples. Logran
esto al ocultar por completo los aspectos no esenciales de una clase. Estos aspectos no esenciales,
una vez que han sido debidamente ocultados, no se pueden ver, ni usar, ni depender de ellos. Este
principio de dependencia mínima es lo que hace que la abstracción sea tan importante. El cambio es
normal en el desarrollo de software. Lo mejor que puede hacer es minimizar el impacto de un
cambio cuando éste sucede. Y cuanto menos dependa de algo, menos se verá afectado cuando
cambie.

Los lenguajes orientados a objetos proporcionan la Encapsulación. La encapsulación se puede

utilizar para aplicar el concepto de Abstracción.

2.2 Encapsulamiento

El Encapsulamiento o encapsulación es la propiedad que permite asegurar que el contenido de la

información de un objeto está oculta al mundo exterior: el objeto A no conoce lo que hace el objeto
B, y viceversa. La encapsulación (también se conoce como ocultación de la información), en
esencia, es el proceso de ocultar todos los secretos de un objeto que no contribuyen a sus
características esenciales.

La encapsulación permite la división de un programa en módulos. Estos módulos se implementan

mediante clases, de forma que una clase representa la encapsulación de una abstracción. En la
práctica, esto significa que cada clase debe tener dos partes: una interfaz y una implementación. La
interfaz de una clase captura sólo su vista externa y la implementación contiene la representación de
la abstracción, así como los mecanismos que realizan el comportamiento adecuado.

Encapsulación es la capacidad de contener y controlar el acceso a un grupo de elementos asociados.

Las clases proporcionan una de las formas más comunes para encapsular elementos. En el siguiente
ejemplo, la clase Bank Account' encapsula los métodos, campos y propiedades que se describen en
una cuenta bancaria. Sin una encapsulación, usted necesitaría declarar procedimientos y variables
por separado para almacenar y administrar información para la cuenta bancaria, y sería difícil
trabajar con más de una cuenta bancaria a la vez. La encapsulación le permite utilizar los datos y
procedimientos en la clase Bank Account como una unidad. Usted puede trabajar con varias cuentas
bancarias al mismo tiempo sin confusión, debido a que cada cuenta está representada por una
instancia única de la clase.

La encapsulación también le permite controlar la forma en que se utilizan los datos y los
procedimientos. Puede utilizar modificadores de acceso, como Private o Protected, para evitar que
los procedimientos externos ejecuten métodos de clase o lean y modifiquen datos en propiedades y
campos. Usted debe declarar los detalles internos de una clase como Private para evitar que sean
utilizados fuera de su clase; a esta técnica se le llama ocultamiento de datos. En la clase Bank
Account, la información del cliente, como el saldo de la cuenta, se protege de esta forma. Una de las
reglas básicas de la encapsulación es que los datos de la clase sólo se pueden modificar o recuperar
a través de los procedimientos o métodos Property. Ocultar los detalles de implementación de sus
clases evita que se usen de maneras no deseadas, y le permite modificar esos elementos
posteriormente sin riesgo de tener problemas de compatibilidad. Por ejemplo, versiones posteriores
de la clase Bank Account enlistadas más adelante, podrían cambiar el tipo de datos del
campo Account Balance' sin peligro de dañar la aplicación que depende de que este campo tenga
un tipo de dato específico.
Class BankAccount
Private AccountNumber As String
Private AccountBalance As Decimal
Private HoldOnAccount As Boolean = False
Public Sub PostInterest()
' Add code to calculate the interest for this account.
End Sub
ReadOnly Property Balance() As Decimal
Get
Return AccountBalance 'Returns the available balance.
End Get
End Property
End Class

Modularidad:

La Modularidad es la propiedad que permite subdividir una aplicación en partes más pequeñas
(llamadas módulos), cada una de las cuales debe ser tan independiente como sea posible de la
aplicación en sí y de las restantes partes.

La modularización consiste en dividir un programa en módulos que se puedan compilar por

separado, pero que tienen conexiones con otros módulos. Al igual que la encapsulación, los
lenguajes soportan la Modularidad de diversas formas.

La Modularidad es la propiedad de un sistema que permite su descomposición en un conjunto de

módulos cohesivos y débilmente acoplados. Por supuesto no todos los módulos son iguales: tomar
un programa monolítico y separarlo de forma aleatoria en archivos no es óptimo. Se debe tener en
cuenta los conceptos asociados de dependencia, acoplamiento, cohesión, interfaz, encapsulación y
abstracción. Una vez identificado lo que es un buen módulo, se puede contemplar la reutilización de
un buen módulo como componente.

El Módulo A depende del Módulo B si cualquier cambio en el Módulo B implica que el Módulo A
también tenga que ser modificado. A veces se dice que el Módulo A es un cliente del Módulo B, o
que el Módulo B actúa como servidor del Módulo A. En general, es normal que un mismo módulo
sea tanto cliente como servidor. Esto significa, que depende de algunos módulos, mientras que otros
módulos dependen de él. Incluso es posible que un par de módulos se tengan uno al otro de cliente;
sin embargo, éste es un ejemplo de dependencia circular, que debe evitarse cuando sea posible
debido a que impide la reutilización.

La dependencia a veces se conoce como acoplamiento. Un sistema con muchas dependencias tiene
fuerte acoplamiento. Los buenos sistemas tienen débil acoplamiento, porque en ese caso los
cambios en una parte del sistema son menos probables de propagarse a través del sistema.

Los módulos correctos a menudo tienen la propiedad de que sus interfaces proporcionan una
abstracción de algún elemento conocido de manera intuitiva que puede, no obstante, ser difícil de
implementar. Este tipo de módulos se dice que tienen una fuerte cohesión. El módulo realiza un
conjunto coherente de cosas, pero dentro de lo posible el desarrollador del cliente está protegido de
la información irrelevante relativa a cómo el módulo hace lo que hace.

Resumiendo: Abstracción es cuando un cliente de un módulo no necesita saber más de lo que hay
en la interfaz. Encapsulación es cuando un cliente de un módulo no es capaz de saber más de lo que
hay en la interfaz.

Si un módulo, de cualquier tamaño y complejidad, es una buena abstracción (tiene fuerte cohesión y
débil acoplamiento) puede ser factible reutilizarlo en sistemas posteriores, o sustituirlo en el sistema
existente.

2.4 Jerarquía

La Jerarquía es una propiedad que permite la ordenación de las abstracciones. Las dos jerarquías
más importantes de un sistema complejo son: estructura de clases (jerarquía ³es-un´ (is-a):
generalización/especialización) y estructura de objetos (jerarquía ³parte-de´ (part-of): agregación).

Las jerarquías de generalización/especialización se conocen como herencia. Básicamente, la

herencia define una relación entre clases, en donde una clase comparte la estructura o
comportamiento definido en una o más clases (herencia simple y herencia múltiple,
respectivamente).

La agregación es el concepto que permite el agrupamiento físico de estructuras relacionadas

lógicamente. Así, un camión se compone de ruedas, motor, sistema de transmisión y chasis; en
consecuencia, camión es una agregación, y ruedas, motor, transmisión y chasis son agregados de
camión.

2.5 Polimorfismo
La quinta propiedad significativa de los lenguajes de programación orientados a objetos es el
polimorfismo. Es la propiedad que indica, literalmente, la posibilidad de que una entidad tome
muchas formas. En términos prácticos, el polimorfismo permite referirse a objetos de clases
diferentes mediante el mismo elemento de programa y realizar la misma operación de diferentes
formas, según sea el objeto que se referencia en ese momento.

Por ejemplo, cuando se describe la clase mamíferos se puede observar que la operación comer es
una operación fundamental en la vida de los mamíferos, de modo que cada tipo de mamífero debe
poder realizar la operación o función comer. Por otra parte, una cabra o una vaca que pastan en un
campo, un niño que se come un caramelo y un león que devora a otro animal, son diferentes formas
que utilizan diferentes mamíferos para realizar la misma función (comer).

El polimorfismo adquiere su máxima expresión en la derivación o extensión de clases, es decir,

cuando se obtiene una clase a partir de una clase ya existente, mediante la propiedad de derivación
de clases o herencia.

El polimorfismo requiere ligadura tardía o postergada (también llamada dinámica), y esto sólo se
puede producir en lenguajes de programación orientados a objetos. Los lenguajes no orientados a
objetos soportan ligadura temprana o anterior (también llamada estática), esto significa que el
compilador genera una llamada a un nombre específico de función y el enlazador (linker) resuelve
la llamada a la dirección absoluta del código que se ha de ejecutar. En POO, el programa no puede
determinar la dirección del código hasta el momento de la ejecución. Cuando se envía un mensaje a
un objeto, el código que se llama no se determina hasta el momento de la ejecución. El compilador
asegura que la función existe y realiza verificación de tipos de los argumentos y del valor de
retorno, pero no conoce el código exacto a ejecutar.

y ¿Cuales son los beneficios? , buena pregunta eh «!!!

En resumen, la programación orientada a objetos beneficia a los desarrolladores debido a que:

V Los programas son fáciles de diseñar debido a que los objetos reflejan elementos del mundo
real.

V Las aplicaciones son más sencillas para los usuarios debido a que los datos innecesarios
están ocultos.
V Los objetos son unidades autocontenidas.
V La productividad se incrementa debido a que puede reutilizar el código.
V Los sistemas son fáciles de mantener y se adaptan a las cambiantes necesidades de
negocios.
V Es más fácil crear nuevos tipos de objetos a partir de los ya existentes.
V Simplifica los datos complejos.
V Reduce la complejidad de la transacción.
V Confiabilidad.
V Robustez.
V Capacidad de ampliación.

2.6 Otras propiedades:

El modelo objeto ideal no sólo tiene las propiedades anteriormente citadas sino que es conveniente
que soporte, además, estas otras propiedades:
o Concurrencia (multitarea): el lenguaje soporta la creación de procesos paralelos independientes
del sistema operativo.

Esta propiedad simplificará la transportabilidad de un sistema de tiempo real de una plataforma a

otra.

o Persistencia: los objetos deben poder ser persistentes; es decir, los objetos han de poder
permanecer después de la ejecución del programa

o Genericidad: las clases parametrizadas (mediante plantillas o unidades genéricas) sirven para
soportar un alto grado de reutilización.

Estos elementos genéricos se diseñan con parámetros formales, que se instanciarán con parámetros
reales, para crear instancias de módulos que se compilan y enlazan, y ejecutan posteriormente.

o Manejo de Excepciones: se deben poder detectar, informar y manejar condiciones excepcionales

utilizando construcciones del lenguaje. Esta propiedad añadida al soporte de tolerancia a fallos del
software permitirá una estrategia de diseño eficiente.

3. Taxonomía de lenguajes orientados a objetos

Una taxonomía de lenguajes de programación con propiedades de orientación a objetos fue creada
por Wegner. La clasificación incluye los siguientes grupos:

V Basado en objetos: Un lenguaje de programación es basado en objetos si su sintaxis y

semántica soportan la creación de objetos que tienen las propiedades descritas en el punto
anterior. Por ejemplo: Ada-83, Clipper 5.2, Visual Basic 4/5/6.
 V Basado en clases: Si un lenguaje de programación es basado en objetos y soporta además la
creación de clases, se considera basado en clases. Por ejemplo: Clu.
 V Orientación a objetos: Un lenguaje de programación orientado a objetos es un lenguaje
basado en clases que soporta también herencia. Por ejemplo: Visual Basic .NET, C# .NET,
C++, Java, Delphi, Eiffel, Simula.

4. Conceptos de orientación a objetos:

Coad y Yourdon definen el término Orientación a Objetos de la siguiente forma:

Orientación a Objetos = objetos + clasificación + herencia + comunicación

4.1. Clases y Objetos:

Un modelo Orientado a Objetos de software de computadora debe exhibir abstracciones de datos y

procedimientos que conducen a una Modularidad eficaz. Una clase es un concepto Orientado a
Objetos que encapsula las abstracciones de datos y procedimientos que se requieren para describir
el contenido y comportamiento de alguna entidad del mundo real.
Las abstracciones de datos (atributos) que describen la clase están encerradas por una ³muralla´ de
abstracciones procedimentales (llamadas operaciones, métodos o servicios) capaces de manipular
los datos de alguna manera. La única forma de alcanzar los atributos (y operar sobre ellos) es ir a
través de alguno de los métodos que forman la muralla. Por lo tanto, la clase encapsula datos
(dentro de la muralla) y el proceso que manipula los datos (los métodos que componen la muralla).
Esto posibilita la ocultación de información y reduce el impacto de efectos colaterales asociados a
cambios.

Nota: Un objeto encapsula datos (atributos) y los métodos (operaciones, métodos o servicios) que
manipulan esos datos.

4.2 Atributos:

Los atributos están asociados a clases y objetos, y describen la clase o el objeto de alguna manera.
Las entidades de la vida real están a menudo descritas con palabras que indican características
estables. La mayoría de los objetos físicos tienen características tales como forma, peso, color y tipo
de material. Las personas tienen características como fecha de nacimiento, padres, nombre y color
de los ojos. Una característica puede verse como una relación binaria entre una clase y cierto
dominio.

La ³relación´ binaria implica que un atributo puede tomar un valor definido por un dominio
enumerado. En la mayoría de los casos, un dominio es simplemente un conjunto de valores
específicos. Por ejemplo, supongamos que una clase Coche tiene un atributo color. El dominio de
valores de color es blanco, negro, plata, gris, azul, rojo, amarillo, verde.

Las características (valores del dominio) pueden aumentarse asignando un valor por defecto
(característica) a un atributo. Por ejemplo, el atributo color tiene el valor por defecto negro.

Nota: Los valores asignados a los atributos de un objeto hacen a ese objeto ser único.

4.3 Operaciones, métodos y servicios:

Un objeto encapsula datos (representados como una colección de atributos) y los algoritmos que
procesan estos datos. Estos algoritmos son llamados operaciones, métodos o servicios y pueden ser
vistos como módulos en un sentido convencional.

Cada uno de los métodos encapsulados por un objeto proporciona una representación de uno de los
comportamientos del objeto. Por ejemplo, el métodoDeterminar Color' para el objeto Coche
extraerá el color almacenado en el atributo color. La consecuencia de la existencia de ese método es
que la clase coche ha sido diseñada para recibir un estímulo (mensaje) que requiere el color de una
instancia particular de una clase. Cada vez que un objeto recibe un estímulo, éste inicia un cierto
comportamiento, que puede ser tan simple como determinar el color del coche o tan complejo como
la iniciación de una cadena de estímulos que se pasan entre una variedad e objetos diferentes.

Nota: Siempre que un objeto es estimulado por un mensaje, inicia algún comportamiento ejecutando
un método.

4.4 Mensajes:
Los mensajes son el medio a través del cual interactúan los objetos. Un mensaje estimula la
ocurrencia de cierto comportamiento en el objeto receptor. El comportamiento se realiza cuando se
ejecuta un método.

Una operación dentro de un objeto emisor genera un mensaje de la forma:

destino.operación (parámetros)

donde destino define al objeto receptor el cual es estimulado por el mensaje, operación se refiere al
método que recibe el mensaje y parámetros proporciona información requerida para el éxito de la
operación.

Los mensajes proporcionan una visión interna del comportamiento de objetos individuales, y del
sistema Orientado a Objetos como un todo.

Nota: El paso de mensajes mantiene comunicado un sistema orientado a objetos.

Hemos terminado. Quieres seguir abstrayéndote..??? jejeje«, entonces, te recomiendo este artículo
(Identificación de un modelo de objetos) para que puedas afianzar los conceptos sobre modelo de
objetos.
Analisis Objetos
El modelo de análisis se extiende luego para describir la manera en que interactúan los actores y el
sistema para manipular el modelo del dominio de aplicación. Los desarrolladores usan el modelo de
análisis, junto con los requerimientos no funcionales, para preparar la arquitectura del sistema que
se desarrolla durante el diseño de alto nivel.

Las actividades del análisis: la identificación de objetos, su comportamiento, sus relaciones, su

clasificación y su organización.
El modelo de análisis está compuesto por tres modelos individuales: el modelo funcional,
representado por casos de uso y escenarios, el modelo de objetos de análisis, representado por
diagramas de clase y objeto, y el modelo dinámico, representado por gráficas de estado y diagramas
de secuencia.

Conceptos de análisis

Particularmente describimos:

Objetos de entidad, frontera y control: Los objetos de entidad representan la información persistente
rastreada por el sistema. Los objetos de frontera representan la interacción entre los actores y el
sistema. Los objetos de control representan las tareas realizadas por el usuario y soportadas por el
sistema.

Multiplicidad de asociación: el extremo de una asociación puede etiquetarse como un conjunto de

enteros llamados multiplicidad. La multiplicidad indica la cantidad de vínculos que pueden
originarse legítimamente desde una instancia de la clase conectada al extremo de la asociación.
En UML, un extremo de una asociación puede tener como multiplicidad un conjunto de enteros
arbitrarios. Sin embargo, en la práctica, la mayoría de las asociaciones que encontramos pertenece a
alguno de los siguientes tres tipos:

Una asociación de uno a uno tiene una multiplicidad de 1 a cada extremo. Una asociación de uno a
uno entre dos clases significa que existe solamente un vínculo entre instancias de cada clase.

Una asociación de uno a muchos tiene una multiplicidad de 1 en un extremo y 0«n

Una asociación de uno a muchos entre dos clases (por ejemplo, Persona y Automóvil) indica
composición

Una asociación de muchos a muchos tiene una multiplicidad de 0. . n o 1. . n en ambos extremos.

Una asociación de muchos a muchos entre dos clases indica que puede existir una cantidad
arbitraria de vínculos entre instancias de las dos clases. Este es el tipo más complejo de asociación.

Asociaciones calificadas:

La calificación es una técnica para la reducción de la multiplicidad usando claves. Las asociaciones
que tienen multiplicidad de 0«1 o 1 son mas fáciles de comprender que las asociaciones con
multiplicidad de 0«n o 1«n. Con frecuencia, en el caso de una asociación de uno a muchos, los
objetos del lado de ³muchos´ pueden distinguirse entre ellos usando un nombre.

Generalización:

La generalización nos permite organizar conceptos en jerarquías.

El analisis para el enfoque orientado a objetos; En lugar de considerar el SW desde una prespectiva
basica de entrada-proceso-salida como los metodos estructurados se basa en modelar el sistema
mediante los objetos que forman parte de el y las relacio estaticas (herencia y compocicion )o
dinamicas(uso entre otros objetos ).El analisis identifica las clases y objetos relativamente en el
dominio del problema, el diseño proporciona detalles sobre la arquitectura, las interfaces y los
componentes la implementacion transforma el diseño en codigo yla pruebas checan tanto la
arquitectura como la interfaz y los componentes.
Diseño Objetos
Durante el diseño de objetos cerramos el hueco entre los objetos de aplicación y los componentes
hechos, identificando objetos de solución adicionales y refinando los objetos existentes.

El diseño de objetos incluye:

‡ Especificación de servicios, durante la cual describimos con precisión cada interfaz de clase.

‡ Selección de componentes, durante la cual identificamos componentes hechos y objetos de

solución adicionales.

‡ Reestructuración del modelo de objetos, durante la cual transformamos el modelo de diseño de

objetos para mejorar su comprensibilidad y extensibilidad.
‡ Optimización del modelo de objetos, durante la cual transformamos el modelo de diseño de
objetos para tratar criterios de desempeño, como el tiempo de respuesta o la utilización de la
memoria.

El diseño de objetos, al igual que el diseño del sistema, no es algorítmico.

El diseño de objetos a veces es dificil distinguir claramente el analisis y el diseño Orientado a

Objetos (OO).

Esencialmente AOO es una sctividad de clasificacion, se analisa un problema con el fin de

determinar clases de objetos que sea aplicables en el desarrollo de la solucion.

El de DOO permite al ing. de SW los objetos que se derivan de cada clase de las interrelaciones
entre ellos y proporciona una notificacion que refleja las relaciones entre los objetos.
Modelos De Proceso De Software
Modelos de procesos del software

Los estándares establecen los diferentes procesos implicados a la hora de desarrollar y mantener un
sistema desde que surge la idea o necesidad de desarrollar las aplicaciones hasta que éstas se retiran
de explotación. Sin embargo, ninguno impone un modelo de procesos concreto (modelo de ciclo de
vida) ni cómo realizar las diferentes actividades incluidas en cada proceso, por lo que cada empresa
deberá utilizar los métodos, técnicas y herramientas que considere oportuno.
Por su naturaleza, los modelos son simplificaciones; por lo tanto, un modelo de procesos del
software es una simplificación o abstracción de un proceso real. Podemos definir un modelo de
procesos del software como una representación abstracta de alto nivel de un proceso software.

Cada modelo es una descripción de un proceso software que se presenta desde una perspectiva
particular. Alternativamente, a veces se usan los términos ciclo de vida y Modelo de ciclo de vida.

Cada modelo describe una sucesión de fases y un encadenamiento entre ellas. Según las fases y el
modo en que se produzca este encadenamiento, tenemos diferentes modelos de proceso. Un modelo
es más adecuado que otro para desarrollar un proyecto dependiendo de un conjunto de
características de éste. Existe una gran variedad de modelos diferentes entre los que tenemos los que
se describen a continuación.
Modelo De Cascada
Este enfoque metodológico que ordena rigurosamente las etapas del ciclo de vida del software, de
forma tal que el inicio de cada etapa debe esperar a la finalización de la inmediatamente anterior. la
palabra  sugiere, mediante la metafora de la fuerza de la gravedad, el esfuerzo necesario
para introducir un cambio en las fases más avanzadas de un proyecto.

Modelo en Cascada: El mas conocido, esta basado en el ciclo convencional de una ingeniería, el
paradigma del ciclo de vida abarca las siguientes actividades:

- Ingenieria y Análisis del Sistema

- Análisis de los Requisitos

- Diseño
- Codificación

- Prueba

- Mantenimiento
1.- INGENIERÍA Y ANÁLISIS DEL SISTEMA

Debido a que el software es siempre parte de un sistema mayor, el trabajo comienza estableciendo
los requisitos de todos los elementos del sistema y luego asignando algun subconjunto de estos
requisitos al software.

2.- ANÁLISIS DE SISTEMAS DE COMPUTACIÓN

Se lleva a cabo teniendo den cuenta ciertos principios:

- Debe presentarse y entenderse el dominio de la información de unproblema.

- Defina las funciones que debe realizar el Software.

- Represente el comportamiendo del Software a consecuencias de acontecimientos externos.

- Divida en forma jerárquica los modelos que represerntan la información, funciones y

comportamiento.

Se analizan las necesidades de los usuarios finales del Software para determinar que objetivos debe
cubrir.

3.- DISEÑO

Traduce los requisitos en una representacion del Software con la calidad requerida antes de que
comience la codificación.

- Diseño del sistema: Se descompone y organiza el sistema en elementos que puedad elaborarse por
separado, aprovechando los ventajas del desarrollo en equipo, así como la manera en que se
combinan unos con otros.

- Diseño del Programa: Es la fase en donde se realizan los algoritmos necesarios para el
cumplimiento de los requerimientos del usuario así como también los análisis necesarios para saber
que herramientas usar en la etapa de Codificación.

4.- CODIFICACIÓN

El diseño debe traducirse en una forma legible para la maquina. Se implementa el código fuente.
Dependiendo del lenguaje de programacion y su versión se crean las librerías y componentes
reutilizables dentro del mismo proyecto para hacer que la programación sea un proceso mucha más
rápido.
5.- PRUEBA

Los elementos, ya programados, se ensamblan para componer el sistema y se comprueba que

funciona correctamente antes de ser puesto en explotación. Las pruebas de Software, testing o beta
testing es un proceso usado para identificar posibles fallos. En general, los usuarios distinguen entre
errores de programacion ( o ³bugs´ ) y defectos de forma. en un defecto de forma, el programa no
realiza lo que el usuario espera. Por el contrario, un error de programación puede describirse como
un fallo en la semántica de un rpograma de ordenador. A la versión del producto de pruebas y que
es anterior a la versión final ( o ³master´ ) se denomina beta, y a dicha fase de pruebas, beta testing.
Finalmente y antes de salir al mercado, es cada vez más habitual que se realice una fase de RTM
testing ( Release To Market ), dónde se comprueba cada funcionalidad del programa completo en
entornos de producción.

6.- IMPLANTACIÓN

El Software obtenido se pone en producción. Se implantan los niveles Software y Hardware que
componen el proyecto. La implantación es la fase con más duración y con más cambios en el ciclo
de elaboración de un proyecto. Es una de las fases finales del proyecto. Durante la explotación del
sistema Software pueden surgir cambios, bien para corregir errores o bien para introducir mejorar.
Todo ello recoge en los Documentos de Cambios.

7.- MANTENIMIENTO

El Software sufrirá cambios después de que se entrega al cliente. Los cambios ocurrirán debido a
que hayan encontrado errores, a que el Software deba adaptarse a cambios del entorno externo
(sistema operativo o dispositivos periféricos), o debido a que el cliente requiera ampliaciones
funcionales o del rendimiento.

Ventajas:

- Se tiene todo bien organizado y no se mezclan las fases.

- Es perfecto para proyectos que son rigidos.

- Idieal para proyectos donde se especifiquen muy bien los requerimientos.

- Ideal para proyectos en que se conozca muy bien la herramienta a utilizar.

- Sumamente sencillo ya que sigue los pasos intuitivos necesarios a la hora de desarrollar el
Software.

Desventajas:

- Difícilmente un cliente va a establecer al principio todos los requerimientos necesaríos, por lo que
provoca un gran atraso trabajando en este modelo, ya que este es muy restrictivo y no permite
movilizarse entre fases.
- Los resultados y/o mejoras no son visibles, el producto se ve recién cuando este esté finalizado.
Modelo De Espiral
El Desarrollo en Espiral es un modelo de ciclo de vida desarrollado por Barry Boehm en 185,
utilizado generalmente en la Ingeniería de software.

Las actividades de este modelo son una espiral, cada bucle es una actividad.

Para cada actividad habrá cuatro tareas:

No. 1

Planificación:

Determinación de objetivos, alternativas y restricciones.

Revisamos todo lo hecho, evaluándolo, y con ello decidimos si continuamos con las fases siguientes
y planificamos la próxima actividad.

No. 2

Análisis de riesgo:

Análisis de alternativas e identificación/resolución de riesgos.

No. 3

Ingeniería:
Desarrollo del producto del ³siguiente nivel´

Tareas de la actividad propia y se prueba.

Análisis de alternativas e identificación resolución de riesgos.

No.4

Evaluación del cliente:

Valorización de los resultados de la ingeniería.

Ventajas:

- El análisis del riesgo se hace de forma explícita y clara. Une los mejores elementos de los
restantes modelos.

- Reduce riesgos del proyecto

- Incorpora objetivos de calidad

- Integra el desarrollo con el mantenimiento, etc.

- Además es posible tener en cuenta mejoras y nuevos requerimientos sin romper con la
metodología, ya que este ciclo de vida no es rígido ni estático.

Desventajas:

- Genera mucho tiempo en el desarrollo del sistema.

- Modelo costoso.

- Requiere experiencia en la identificación de riesgos.

CONCLUCION:

El paradigma del modelo en espiral para la ingeniería de software es actualmente el enfoque más
realista para el desarrollo de software y de sistemas a gran escala. Utiliza un enfoque evolutivo para
la ingeniería de software, permitiendo al desarrollador y al cliente entender y reaccionar a los
riesgos en cada nivel evolutivo. Utiliza la creación de prototipos como un mecanismo de reducción
de riesgo, pero, lo que es más importante permite a quien lo desarrolla aplicar el enfoque de
creación de prototipos en cualquier etapa de la evolución de prototipos.
Modelo Incremental
El Modelo Incremental combina elementos del MLS con la filosofía interactiva de construcción de
prototipos.
En una visión genérica, el proceso se divide en 4 partes: Análisis, Diseño, Código y Prueba. Sin
embargo, para la producción del Software, se usa el principio de trabajo en cadena o ³Pipeline´,
utilizado en muchas otras formas de programación. Con esto se mantiene al cliente en constante
contacto con los resultados obtenidos en cada incremento. Es el mismo cliente el que incluye o
desecha elementos al final de cada incremento a fin de que el software se adapte mejor a sus
necesidades reales. El proceso se repite hasta que se elabore el producto completo.

De esta forma el tiempo de entrega se reduce considerablemente.

Al igual que los otros métodos de modelado, el Modelo Incremental es de naturaleza interactiva
pero se diferencia de aquellos en que al final de cada incremento se entrega un producto
completamente operacional.

El Modelo Incremental es particularmente útil cuando no se cuenta con una dotación de personal
suficiente. Los primeros pasos los pueden realizar un grupo reducido de personas y en cada
incremento se añadir‡ personal, de ser necesario. Por otro lado los incrementos se pueden planear
para gestionar riesgos técnicos.

El Modelo Incremental se puede ver aquí en forma grafica:

- Se evitan proyectos largos y se entrega algo de valor a los usuarios con cierta frecuencia.
- El usuario se involucra más.

- Difícil de evaluar el coste total.

- Difícil de aplicar a los sistemas transaccionales que tienden a ser integrados y a operar como un
todo.

- Requiere gestores experimentados.

- Los errores en los requisitos se detectan tarde.

- El resultado puede ser muy positivo.

Pipeline

La arquitectura en pipeline (basada en filtros) consiste en ir transformando un flujo de datos en un

proceso comprendido por varias fases secuenciales, siendo la entrada de cada una la salida de la
anterior.

Esta arquitectura es muy común en el desarrollo de programas para el intérprete de comandos, ya

que se pueden concatenar comandos fácilmente con tuberías (pipe).

También es una arquitectura muy natural en el paradigma de programación funcional, ya que

equivale a la composición de funciones matemáticas.

Interprete de comandos

Parte fundamental de un sistema operativo que ordena la ejecución de mandatos obtenidos del
usuario por medio de una interfaz alfanumérica.

Características

- Se evitan proyectos largos y se entrega ³algo de valor´ a los usuarios con cierta frecuencia.

- El usuario se involucre más.

- Dificil de evaluar el costo total.

- Díficil de aplicar a los sistemas transaccionales que tienden a ser integrados y a operar como un
todo.

- Requiere gestores experimentados.

- Los errores en los requisitos se detectan tarde.

- El resultado puede ser muy positivo.

Ventajas:

- Con un paradigma incremental se reduce el tiempo de desarrollo inicial, ya que se implementa la

funcionalidad parcial.

- También provee un impacto ventajoso frente al cliente, que es la entrega temprana de partes
operativas del Software.

- El modelo proporciona todas las ventajas del modelo en cascada realimentado, reduciendo sus
desventajas sólo al ámbito de cada incremento.

- Permite entregar al cliente un producto más rápido en comparación del modelo de cascada.

- Resulta más sencilo acomodar cambios al acotar el tamaño de los incrementos.

- Por su versatilidad requiere de una planeación cuidadosa tanto a nivel administrativo como
técnico.

Desventajas:

- El modelo Incremental no es recomendable para casos de sistemas de tiempo real, de alto nivel de
seguridad, de procesamiento distribuido, y/o de alto índice de riesgos.

- Requere de mucha planeacion, tanto administrativa como técnica.

- Requiere de metas claras para conocer el estado del proyecto.

Conclusion:

Un modelo incremental lleva a pensar en un desarrollo modular, con entregas parciales del
productoSoftware denomidados ³incrementos´ del sistema, que son escogidos en base a prioridades
predefinidas de algún modo.

El modelo permite una implementación con refinacmientos sucesivos (ampliación y/o mejora).

Con cada incremento se agrega nueva funcionalidad o se cubren nuevos requisitos o bien se mejora
la versión previamente implementada del producto software.
Proceso De Desarrollo Unificado
El Proceso Unificado de Desarrollo Software o simplemente Proceso Unificado es un marco de
desarrollo software iterativo e incremental. El refinamiento más conocido y documentado del
Proceso Unificado es el Proceso Unificado de Rational o simplemente RUP.
El Proceso Unificado no es simplemente un proceso, sino un marco de trabajo extensible que puede
ser adaptado a organizaciones o proyectos específicos. De la misma forma, el Proceso Unificado de
Rational, también es un marco de trabajo extensible, por lo que muchas veces resulta imposible
decir si un refinamiento particular del proceso ha sido derivado del Proceso Unificado o del RUP.
Por dicho motivo, los dos nombres suelen utilizarse para referirse a un mismo concepto.
El nombre Proceso Unificado se usa para describir el proceso genérico que incluye aquellos
elementos que son comunes a la mayoría de los refinamientos existentes. También permite evitar
problemas legales ya que Proceso Unificado de Rational o RUP son marcas registradas por IBM
(desde su compra de Rational Software Corporation en 2003). El primer libro sobre el tema se
denominó, en su versión española, El Proceso Unificado de Desarrollo de Software (ISBN 84±
782±036±2) y fue publicado en 1 por Ivar Jacobson, Grady Booch y James Rumbaugh,
conocidos también por ser los desarrolladores del UML, el Lenguaje Unificado de Modelado.
Desde entonces los autores que publican libros sobre el tema y que no están afiliados a Rational
utilizan el término Proceso Unificado, mientras que los autores que pertenecen a Rational favorecen
el nombre de Proceso Unificado de Rational.

Características:

- Iterativo e Incremental

El Proceso Unificado es un marco de desarrollo iterativo e incremental compuesto de cuatro fases

denominadas Inicio, Elaboración, Construcción y Transición. Cada una de estas fases es a su vez
dividida en una serie de iteraciones (la de inicio sólo consta de varias iteraciones en proyectos
grandes). Estas iteraciones ofrecen como resultado un incremento del producto desarrollado que
añade o mejora las funcionalidades del sistema en desarrollo.

Cada una de estas iteraciones se divide a su vez en una serie de disciplinas que recuerdan a las
definidas en el ciclo de vida clásico o en cascada: Análisis de requisitos, Diseño, Implementación y
Prueba. Aunque todas las iteraciones suelen incluir trabajo en casi todas las disciplinas, el grado de
esfuerzo dentro de cada una de ellas varía a lo largo del proyecto.

- Dirigido por los casos de uso

En el Proceso Unificado los casos de uso se utilizan para capturar los requisitos funcionales y para
definir los contenidos de las iteraciones. La idea es que cada iteración tome un conjunto de casos de
uso o escenarios y desarrolle todo el camino a través de las distintas disciplinas: diseño,
implementación, prueba, etc. el proceso dirigido por casos de uso es el rup. Nota: en UP se está
Dirigido por requisitos y riesgos de acuerdo con el Libro UML 2 de ARLOW , Jim que menciona el
tema.

- Centrado en la arquitectura

El Proceso Unificado asume que no existe un modelo único que cubra todos los aspectos del
sistema. Por dicho motivo existen múltiples modelos y vistas que definen la arquitectura de
software de un sistema. La analogía con la construcción es clara, cuando construyes un edificio
existen diversos planos que incluyen los distintos servicios del mismo: electricidad, fontanería, etc.

- Enfocado en los riesgos

El Proceso Unificado requiere que el equipo del proyecto se centre en identificar los riesgos críticos
en una etapa temprana del ciclo de vida. Los resultados de cada iteración, en especial los de la fase
de Elaboración, deben ser seleccionados en un orden que asegure que los riesgos principales son
considerados primero.
 Proceso Software Personal

 „#$ 


El Proceso Personal de Software es una versión pequeña de CMM donde se preocupa solo por un
conjunto de las KPAs. Fue propuesto por Watts Humphrey en 15 y estaba dirigido a estudiantes.
A partir de 17 con el lanzamiento del libro ³An introduction to the Personal Software Process´ se
dirige ahora a ingenieros principiantes.

El PSP se caracteriza porque es de uso personal y se aplica a programas pequeños de menos de

10.000 líneas de código. Se centra en la administración del tiempo y en la administración de la
calidad a través de la eliminación temprana de defectos. En el PSP se excluyen los siguientes temas:
Trabajo en equipo, Administración de configuraciones y Administración de requerimientos.

El PSP se orienta el conjunto de áreas clave del proceso que debe manejar un desarrollador cuando
trabaja de forma individual. Los siguientes son los niveles y las KPAs que se manejan en cada uno:

Nivel 2 - Inicial:

- Seguimiento y control de proyectos

- Planeación de los proyectos

Nivel 3 - Repetible:

- Revisión entre colegas.

- Ingeniería del producto de software.

- Manejo integrado del software.

- Definición del proceso de software.

- Foco del proceso de software.

Nivel 4 - Definido:

- Control de calidad.

- Administración cuantitativa del proyecto.

Nivel 5 - Controlado:

- Administración de los cambios del proceso.

- Administración del cambio tecnológico.

- Prevención de defectos.

- El PSP tiene varias fases:

PSP0: Proceso Base.

PSP0.1: Complementos al proceso base.

PSP1 y PSP1.1: Planeación personal.

PSP2 y PSP2.1: Control de calidad personal.

PSP3: Programas más grandes.

ITCG

Š

 „#$ 


El Proceso Personal Software, conocido por sus siglas como PSP, es una metodología de reciente
creación, proveniente del Instituto de Ingeniería del Software (SEI). PSP es una alternativa dirigida
a los ingenieros de sistemas, que les permite mejorar la forma en la que construyen software.
Considerando aspectos como la planeación, calidad, estimación de costos y productividad, PSP es
una metodología que vale la pena revisar cuando el ingeniero de software está interesado en
aumentar la calidad de los productos de software que desarrolla dentro de un contexto de trabajo
individual.

Atendiendo a la premisa de que existe una fuerte relación entre las habilidades de los ingenieros de
software y la calidad de los productos que desarrollan, las actividades establecidas en PSP están
orientadas al conocimiento, administración y mejora de sus habilidades al construir programas.
En PSP todas las tareas y actividades que el ingeniero de software debe realizar durante el proceso
de desarrollo de un producto de software, están puntualmente definidas en un conjunto de
documentos conocidos como scripts. Los scripts son el punto medular de PSP, por lo que se hace
mucho énfasis en que deben ser seguidos en forma disciplinada, ya que de ello dependerá el éxito
de la mejora que se busca. Gran parte de las tareas y actividades definidas en los scripts generará en
su realización un conjunto de datos, fundamentalmente de carácter estadístico. La aplicación de PSP
en varios procesos de desarrollo, y el análisis de la información estadística generada en cada uno de
éstos, permitirán al ingeniero de software identificar, tanto sus fortalezas como sus debilidades, y
crecer a través de un proceso de autoaprendizaje y auto-mejora.
Los scripts se organizan en cuatro niveles, identificados del 0 al 3, atendiéndose en cada nivel un
conjunto de aspectos a mejorar del proceso de desarrollo de software. Al primer nivel se le conoce
como 0 o de medición personal, al segundo como nivel 1 o de planeación personal, al tercero, como
nivel 2 o de calidad personal, y al cuarto, como nivel 3 o cíclico personal. Cada uno de estos
niveles, con excepción del 3, tiene una versión que los extiende, introduciendo tareas y actividades
para un mejor manejo de los aspectos de interés en nivel, o bien para incluir nuevos aspectos.
Tecnicas Herramientas Y Estudios Previos
Ingeniería de software es la disciplina o área de la informática que ofrece métodos y técnicas para
desarrollar y mantener software de calidad.
Esta ingeniería trata con áreas muy diversas de la informática y de las ciencias de la computación,
tales como construcción de compiladores, sistemas operativos, o desarrollos Intranet/Internet,
abordando todas las fases del ciclo de vida del desarrollo de cualquier tipo de sistemas de
información y aplicables a infinidad de áreas (negocios, investigación científica, medicina,
producción, logística, banca, control de tráfico, meteorología, derecho, Internet, Intranet, etc.)
Una definición precisa aún no ha sido contemplada en los diccionarios, sin embargo se pueden citar
las enunciadas por algunos de los más prestigiosos autores:

Ingeniería de Software es el estudio de los principios y metodologías para el desarrollo y

mantenimiento de sistemas software (Zelkovitz, 178).

Ingeniería de software es la aplicación práctica del conocimiento científico al diseño y construcción

de programas de computadora y a la documentación asociada requerida para desarrollar, operar y
mantenerlos. Se conoce también como Desarrollo de Software o Producción de Software ( Bohem,
176).

Ingeniería de Software trata del establecimiento de los principios y métodos de la ingeniería a fin de
obtener software de modo rentable, que sea fiable y trabaje en máquinas reales (Bauer, 172).

Es la aplicación de un enfoque sistemático, disciplinado y cuantificable al desarrollo, operación y

mantenimiento del software; es decir, la aplicación de la ingeniería al software (IEEE, 13).

En el 2004, en los Estados Unidos, la Oficina de Estadísticas del Trabajo (U. S. Bureau of Labor
Statistics) contó 760.840 ingenieros de software de computadora.[1] El término ³ingeniero de
software´, sin embargo, se utiliza en forma genérica en el ambiente empresarial, y no todos los
ingenieros de software poseen realmente títulos de Ingeniería de universidades reconocidas.

Algunos autores consideran que Desarrollo de Software es un término más apropiado que Ingeniería
de Software (IS) para el proceso de crear software. Personas como Pete McBreen (autor de
³Software Craftmanship´) cree que el término IS implica niveles de rigor y prueba de procesos que
no son apropiados para todo tipo de desarrollo de software.

Indistintamente se utilizan los términos Ingeniería de Software o Ingeniería del Software. En

hispanoamérica el término usado normalmente es el primero de ellos.

Etapas del proceso

La ingeniería de software requiere llevar a cabo numerosas tareas, dentro de etapas como las
siguientes:

- Análisis de requisitos:

Extraer los requisitos de un producto de software es la primera etapa para crearlo. Mientras que los
clientes piensan que ellos saben lo que el software tiene que hacer, se requiere de habilidad y
experiencia en la ingeniería de software para reconocer requisitos incompletos, ambiguos o
contradictorios. El resultado del análisis de requisitos con el cliente se plasma en el documento
ERS, Especificación de Requerimientos del Sistema, cuya estructura puede venir definida por
varios estándares, tales como CMM-I. Asimismo, se define un diagrama de Entidad/Relación, en el
que se plasman las principales entidades que participarán en el desarrollo del software.

La captura, análisis y especificación de requisitos (incluso pruebas de ellos), es una parte crucial; de
esta etapa depende en gran medida el logro de los objetivos finales. Se han ideado modelos y
diversos procesos de trabajo para estos fines. Aunque aún no está formalizada, ya se habla de la
Ingeniería de Requisitos.

La IEEE Std. 830±18 normaliza la creación de las Especificaciones de Requisitos Software

(Software Requirements Specification).

- Especificación:

Es la tarea de describir detalladamente el software a ser escrito, en una forma matemáticamente

rigurosa. En la realidad, la mayoría de las buenas especificaciones han sido escritas para entender y
afinar aplicaciones que ya estaban desarrolladas. Las especificaciones son más importantes para las
interfaces externas, que deben permanecer estables.

- Diseño y arquitectura:

Se refiere a determinar como funcionará de forma general sin entrar en detalles. Consiste en
incorporar consideraciones de la implementación tecnológica, como el hardware, la red, etc. Se
definen los Casos de Uso para cubrir las funciones que realizará el sistema, y se transforman las
entidades definidas en el análisis de requisitos en clases de diseño, obteniendo un modelo cercano a
la programación orientada a objetos.

- Programación:

Reducir un diseño a código puede ser la parte más obvia del trabajo de ingeniería de software, pero
no necesariamente es la que demanda mayor trabajo y ni la más complicada. La complejidad y la
duración de esta etapa está íntimamente relacionada al o a los lenguajes de programación utilizados,
así como al diseño previamente realizado.

- Prueba:

Consiste en comprobar que el software realice correctamente las tareas indicadas en la

especificación del problema. Una técnica de prueba es probar por separado cada módulo del
software, y luego probarlo de forma integral, para así llegar al objetivo. Se considera una buena
práctica el que las pruebas sean efectuadas por alguien distinto al desarrollador que la programó,
idealmente un área de pruebas; sin perjuicio de lo anterior el programador debe hacer sus propias
pruebas. En general hay dos grandes formas de organizar un área de pruebas, la primera es que esté
compuesta por personal inexperto y que desconozca el tema de pruebas, de esta forma se evalúa que
la documentación entregada sea de calidad, que los procesos descritos son tan claros que cualquiera
puede entenderlos y el software hace las cosas tal y como están descritas. El segundo enfoque es
tener un área de pruebas conformada por programadores con experiencia, personas que saben sin
mayores indicaciones en qué condiciones puede fallar una aplicación y que pueden poner atención
en detalles que personal inexperto no consideraría.
- Documentación:

Todo lo concerniente a la documentación del propio desarrollo del software y de la gestión del
proyecto, pasando por modelaciones (UML), diagramas, pruebas, manuales de usuario, manuales
técnicos, etc; todo con el propósito de eventuales correcciones, usabilidad, mantenimiento futuro y
ampliaciones al sistema.

- Mantenimiento:

Mantener y mejorar el software para enfrentar errores descubiertos y nuevos requisitos. Esto puede
llevar más tiempo incluso que el desarrollo inicial del software. Alrededor de 2/3 de toda la
ingeniería de software tiene que ver con dar mantenimiento. Una pequeña parte de este trabajo
consiste en arreglar errores, o bugs. La mayor parte consiste en extender el sistema para hacer
nuevas cosas. De manera similar, alrededor de 2/3 de toda la ingeniería civil, arquitectura y trabajo
de construcción es dar mantenimiento.

- Modelos de desarrollo de software:

La ingeniería de software tiene varios modelos o paradigmas de desarrollo en los cuales se puede
apoyar para la realización de software, de los cuales podemos destacar a éstos por ser los más
utilizados y los más completos:

Modelo en cascada o Clásico (modelo tradicional)

Modelo en espiral (modelo evolutivo)

Modelo de prototipos

Desarrollo por etapas

Desarrollo iterativo y creciente o Iterativo e Incremental

Tecnicas De Recopilacion De Informacion
TÉCNICAS DE RECOPILACIÓN DE INFORMACIÓN

Los analistas utilizan una variable de métodos a fin de recopilar los datos sobre una situación
existente, como entrevistas, cuestionario, inspección de registros y observación. Cada uno tiene
ventajas y desventajas. Generalmente, se utilizan dos o tres para complementar el trabajo de cada
una y ayudar a asegurar una investigación completa. A continuación se verán cada una de ellas.

ENTREVISTA
Las entrevistas se utilizan para recabar información en forma verbal, a través de preguntas que
propone el analista. Quienes responde pueden ser gerentes o empleados, los cuales son usuarios
actuales del sistema, existen usuarios potenciales del sistema propuesto o aquellos que
proporcionaran datos o serán afectadas por la aplicación propuesta. El analista puede entrevistar al
personal en forma individual o en grupos.

Recabar datos mediante la entrevista.

La entrevista es una forma de conversación, ¡no interrogación! Al analizar las características de los
sistemas con personal seleccionado cuidadosamente por sus conocimientos sobre es sistema los
analistas pueden conocerlos datos que no están disponibles en ninguna otra forma.

En las investigaciones de sistemas, las formas cualitativas y cuantitativas de la información son

importantes. La información cualitativa esta relacionada con opiniones, políticas y descripciones
cuantitativas tratan con números, frecuencia o cantidades. A menudo las entrevistas dan la mejor
fuente de información cualitativa; los otros métodos tienden a ser mas útiles en la recabación de
datos cuantitativos.

Mucha gente incapaz de expresarse por escrito puede discutir sus ideas en forma verbal. Como
resultado de esto las entrevistas pueden descubrir rápidamente malos entendidos, falsas expectativas
o incluso resistencia potencial para las aplicaciones en desarrollo; mas aun a menudo es más fácil
calendarizar una entrevista con los gerentes del alto nivel, que pedirles que llenen cuestionarios.

Determinación del tipo de entrevista.

La estructura de las entrevistas varia. Si el objetivo de la entrevista radica en adquirir información

general, es conveniente elaborar una serie de preguntas sin estructura, con una sección de preguntas
y respuestas libres. La atmósfera abierta y de fácil flujo de esta modalidad proporciona una mayor
oportunidad para conocer las actitudes, ideas y creencias de quien responde. Sin embargo, cuando
los analistas necesitan adquirir datos más específicos sobre la aplicación o desean asegurar una alta
confiabilidad en las respuestas a las preguntas que han propuesto a sus entrevistados, las entrevistas
estructuradas son mejores.

Las entrevistas estructuradas utilizan preguntas estandarizadas. El formato de respuestas para las
preguntas puede ser abierto o cerrado; las preguntas para respuesta abierta permiten a los
entrevistados dar cualquier respuesta que parezca apropiada. Con las preguntas para respuestas
cerradas se proporciona al usuario un conjunto de respuestas que se pueda seleccionar. Todas las
personas que responden se basan en un mismo conjunto de posibles respuestas.

La confiabilidad es solo una consideración en la selección del método de entrevista. Los analistas
también deben dividir su tiempo entre desarrollar preguntas para entrevistas y analizar las
respuestas. Las entrevistas no estructuradas requieren menos tiempo de preparación, porque no se
necesita tener por anticipado las palabras precisas de las preguntas. Sin embargo, analizar las
respuestas después de las entrevistas lleva más tiempo que con las entrevistas estructuradas. De
cualquier manera, el mayor costo radica en la preparación, administración y análisis de las
entrevistas estructuradas para preguntas cerradas.

Dado que un numero de personas se seleccionara para la entrevista, los analistas deben tener
cuidado de incluir aquellas personas que tienen información que no se podrá conseguir de otra
forma. Durante las primeras etapas de un estudio de sistemas, cuando los analistas determinan

La factibilidad del proyecto, con frecuencia las entrevistas solo se aplican a la gerencia o personal
de supervisión. Sin embargo, durante la investigación detallada en donde el objetivo es descubrir
hechos específicos, opiniones y conocer como se manejan las operaciones desempeñadas
actualmente, las entrevistas se aplican en todos los niveles gerenciales y de empleados y dependen
de quien pueda proporcionar la mayor parte de la información útil para el estudio. Así, los analistas
que estudian ala administración de inventarios pueden entrevistar a los trabajadores del embarque y
de recepción, al personal del almacén y a los supervisores de los diferentes turnos, es decir, aquellas
personas que realmente trabajan en el almacén; también entrevistaran a los agentes más
importantes.

Realización de la entrevista.

La habilidad del entrevistador es vital para el éxito en la búsqueda de hechos por medio de la
entrevista. Las buenas entrevistas dependen del conocimiento del analista tanto de la preparación
del objetivo de una entrevista especifica como de las preguntas por realizar a una persona
determinada.

El tacto, la imparcialidad e incluso la vestimenta apropiada ayudan a asegurar una entrevista

exitosa. La falta de estos factores puede reducir cualquier oportunidad de éxito. Por ejemplo, un
analista que trabaja en la aplicación enfocada a la reducción de errores probablemente no tendría
éxito si llegar a una oficina de gerencia de nivel medio con la presentación equivocada, por
ejemplo, si dijera, ³hola, fui enviado para encontrar una forma de mojar el rendimiento y de reducir
los errores que presentan aquí. O la introducción: ³Estamos aquí para resolver su problema´, es
igualmente mala. Es imaginable la rapidez con la que va a responder ser irrita y se molesta con un
enfoque de este tipo.

A través de la entrevista, los analistas deben preguntarse así mismos las siguientes interrogantes:

¿Qué es lo que me esta diciendo la persona?

¿Por qué me lo esta diciendo a mí?

¿Qué se esta olvidando?

¿Qué espera esta persona que haga yo?

Si se considera cada elemento de la información contra estas preguntas, los analistas tendrán mas
conocimientos no solamente de la información adquirida sino también de su importancia.

CUESTIONARIO.

Los cuestionarios proporcionan una alternativa muy útil para las entrevistas; sin embargo, existen
ciertas características que pueden ser apropiadas en algunas situaciones e inapropiadas en otras.

Recabación de datos mediante cuestionarios

Para los analistas los cuestionarios pueden ser la única forma posible de relacionarse con un gran
numero de personas para conocer varios aspectos del sistema. Cuando se llevan a cabo largos
estudios en varios departamentos, se puede distribuir los cuestionarios a todas las personas
apropiadas para recabar hechos con relación al sistema. Por supuesto, no es posible observar las
expresiones o relaciones de quienes responden a los cuestionarios.
También las preguntas estandarizadas pueden proporcionar datos más confiables. Por otra parte, las
características anteriores también son desventajas de los cuestionarios. Aunque su aplicación puede
realizarse con un mayor numero de individuos, es muy rara una respuesta total. Puede necesitarse
algún seguimiento de los cuestionarios para motivar al personal que responda; todas las respuestas
se encontraran en una proporción entre el 25 o 35%, que es lo más común.

Selección de formas para cuestionarios.

El desarrollo y distribución de los cuestionarios es caro; por lo tanto, el tiempo invertido en esto
debe utilizarse en una forma inteligente. También es importante el formato y contenido de las
preguntas en la recopilación de hechos significativos.

Existen dos formas de cuestionarios para recabar datos; cuestionario abierto y cerrados, y se aplican
dependiendo de si los analistas conocen de antemano todas las posibles respuestas de las preguntas
y pueden incluirlos. Con frecuencia se utilizan ambas formas en los estudios de sistemas.

Cuestionarios abiertos.

Al igual, que las entrevistas, los cuestionarios pueden ser abiertos y se aplican cuando se quieren
conocer los sentimientos, opiniones y experiencias generales; también son útiles al explorar el
problema básico, por ejemplo, un analista que utiliza cuestionarios para estudiar los métodos de
verificación de crédito, en un medio ambiente de ventas al a menudeo, podría recabar mas
información provechosa de una pregunta abierta de este tipo: ¿Cómo podría simplificarse y
mejorarse el proceso de verificación de crédito para los clientes?

Cuestionarios cerrados.

El cuestionario cerrado limita las respuestas posibles del interrogado. Por medio de un cuidadoso
estilo en la pregunta, el analista puede controlar el marco de referencia. Este formato es el mejor
método para obtener información sobre los hechos. También fuerza a los individuos para que tomen
una posición y forma de opinión sobre los aspectos importantes.

Etapas en el desarrollo de un cuestionario

Los cuestionarios bien hechos no se desarrollan rápidamente, llevan tiempo y mucho trabajo. La
primera consideración se encuentra en determinar el objetivo del cuestionario. ¿Qué datos quiere
conocer el analista a través de su uso? El analista define como utilizar los cuestionarios a fin de
obtener los hechos al considerar la estructura mas útil para el estudio y la más sencilla de entender
por parte de los interrogados.

Lleva tiempo desarrollar preguntas bien elaboradas y deben siempre probarse y modificarse, si es
necesario, antes de que imprima una forma final y se distribuya.

Selección de quienes recibirán el cuestionario

Aquellas personas que reciban el cuestionario deben seleccionarse de a cuerdo con la información
que puedan proporcionar. Escribir o imprimir un cuestionario no significa que se pueda distribuir
ampliamente sin un análisis previo. Lo pueden contestar personas no calificadas y si el cuestionario
no es anónimo, y no será posible retirar sus respuestas de la muestra. La realización de esto también
es desgastante y cara.
OBSERVACION

¡Ver es creer! Observar las operaciones le proporciona la analista hechos que no podría obtener de
otra forma.

Recopilación de datos mediante la observación

Leer en relación con una actividad del negocio le proporciona al analista una dimensión de las
actividades del sistema. Entrevistar personal, ya sea directamente o a través de cuestionarios,
también le ayuda y le dice algo más. Ninguno de los dos métodos da una información completa; por
ejemplo, leer en relación con un viaje en jet no reproduce la experiencia de volar a unos 30 mil pies
de altura.

La observación proporciona información de primera mano en relación con la forma en que se llevan
a cabo las actividades. Las preguntas sobre el uso de documentos, la manera en la que se realizan
las tareas y si ocurren los pasos específicos como se pre-establecierón, pueden contestarse
rápidamente si se observan las operaciones.

Cuando observar

La observación es muy útil cuando el analista necesita ver de primera mano como se manejan los
documentos, como se llevan a cabo los procesos y si ocurren los pasos especificados. Saber que
buscar y como guiar su significado, también requiere de experiencia. Los observadores con
experiencia captan quien utiliza los documentos y si encuentran dificultades; también están alertas
para detectar documentos o registros que no se utilizan.

MUESTREO

Con frecuencia, en muchas empresas la información ya se encuentra disponible para que el analista
conozca las actividades u operaciones con las cuales no esta familiarizado. Muchos tipos de
registros e informes son accesibles si el analista sabe donde buscar. En la revisión de registros, los
analistas examinan datos y descripciones que ya están escritos o registrados y en relación con el
sistema y los departamentos de usuarios. Esta forma de encontrar datos puede servir como
presentación del analista, si se realiza al iniciar el estudio, o como un termino de comparación de lo
que sucede en el departamento con lo que los registros presentan como lo que debería suceder.

Recopilación de datos por medio de la inspección de registros.

El termino ³registro´ se refiere a los manuales escritos sobre políticas, regulaciones y

procedimientos de operaciones estándar que la mayoría de las empresas mantienen como guía para
gerentes y empleados. Los manuales que documentan o describen las operaciones para los procesos
de datos existente, o sistemas de información que entran dentro del área de investigación, también
proporcionan una visión sobre la forma en la que el negocio debería conducirse. Normalmente
muestran los requerimientos y restricciones del sistema (como cantidad de transacciones o
capacidad de almacenamiento de datos) y características de diseño (controles y verificación del
procesamiento).
Los registro permiten que los analistas se familiaricen con algunas operaciones, oficinas de la
compañía y relaciones formales a las que debe darse apoyo. No obstante, no muestran como
producen de hecho las actividades, donde se ubica el poder verdadero para las decisiones, o como se
realizan las tareas en la actualidad. Los otros métodos con objeto de encontrar datos estudiados en
esta sección son más eficaces para proporcionar al analista este tipo de información.

Selección de los registros para revisión

En la mayor parte de las empresas los manuales de estándares sobre procedimientos de operación
usualmente son obsoletos; a menudo no se mantienen al corriente lo suficiente para señalar los
procedimientos existentes. Los diagramas de organización muestran como las diferentes unidades
deberían relacionarse con otras; pero muchas no reflejan las operaciones actuales.

Actividades obligatorias:

Explique brevemente la realización de la entrevista

Liste cuatro situaciones que hagan adecuado el uso de cuestionarios.

¿Cómo debe ser la selección de quien recibirá el cuestionario? Defina lo que significa muestreo

Actividades sugeridas:

Liste tres razones sobre el porqué la observación es útil para el analista de sistemas en la
organización Explique brevemente la fase de muestreo.

¿Qué tipos de información deben ser buscados en las entrevistas?

Recursos para ampliar el tema

Pags. 7±82, 10±123, 147±163, 175±181, Análisis y diseño de sistemas, Kendall & Kendall, 3ª
edición, ed. Pearson educación, 17.

Autoevaluación

¿Qué es la entrevista?

¿Para que sirven los comentarios?

¿En que momento es útil observar?

¿Qué es el muestreo o para que sirve?

Entrevista
La entrevista es una conversación dirigida que usa un formato de preguntas y respuestas. En la
entrevista se quiere obtener la opinión del entrevistado y sus sentimientos acerca del estado actual
del sistema.
PLANEACION PARA LA ENTREVISTA

Hay cinco pasos principales para la preparación de la entrevista:

V LECTURA DE MATERIAL DE FONDO:

Esto es leer y comprender la información acerca del entrevistado. Su ventaja es construir un

vocabulario común, para redactar las preguntas de la entrevista de forma que sea comprensible para
el entrevistado.

V ESTABLECIMIENTO DE LOS OBJETIVOS DE LA ENTREVISTA:

Requiere usar la información que se recopiló, asi como la experiencia para establecr los objetivos de
la entrevista.

V DECIDIR A QUIEN ENTREVISTAR:

Esto es incluir a todas las gentes claves de todos los niveles que van a ser afectadas por el sistema
de alguna forma.

V PREPARAR AL ENTREVISTADO:

Esto es preparar a la persona a ser entrevistada, llamandole con anticipación y permitiendo que el
entrevistado tenga tiempo para pensar acerca de la entrevista. Las entrevistas deben durar de 45
minutos a una hora, a lo mucho.

V DECIDA SOBRE TIPOS DE PREGUNTAS Y ESTRUCTURAS:

Esto es escribir preguntas para tratar las areas principales de la toma de decisiones descubiertas
cuando se averiguaron los objetivos de la entrevista.

los dos tipos basicos de preguntas son:

1._ Abiertas

2._ Cerradas

Cada tipo de pregunta puede lograr algo diferente y cada una tienen sus beneficios y desventajas.
Cuestionario

Los cuestionarios proporcionan una alternativa muy útil para las entrevistas; sin embargo, existen
ciertas características que pueden ser apropiadas en algunas situaciones e inapropiadas en otras.

Recabación de datos mediante cuestionarios

Para los analistas los cuestionarios pueden ser la única forma posible de relacionarse con un gran
numero de personas para conocer varios aspectos del sistema. Cuando se llevan a cabo largos
estudios en varios departamentos, se puede distribuir los cuestionarios a todas las personas
apropiadas para recabar hechos con relación al sistema. Por supuesto, no es posible observar las
expresiones o relaciones de quienes responden a los cuestionarios.

También las preguntas estandarizadas pueden proporcionar datos más confiables. Por otra parte, las
características anteriores también son desventajas de los cuestionarios. Aunque su aplicación puede
realizarse con un mayor numero de individuos, es muy rara una respuesta total. Puede necesitarse
algún seguimiento de los cuestionarios para motivar al personal que responda; todas las respuestas
se encontraran en una proporción entre el 25 o 35%, que es lo más común.

Selección de formas para cuestionarios.

El desarrollo y distribución de los cuestionarios es caro; por lo tanto, el tiempo invertido en esto
debe utilizarse en una forma inteligente. También es importante el formato y contenido de las
preguntas en la recopilación de hechos significativos.

Existen dos formas de cuestionarios para recabar datos; cuestionario abierto y cerrados, y se aplican
dependiendo de si los analistas conocen de antemano todas las posibles respuestas de las preguntas
y pueden incluirlos. Con frecuencia se utilizan ambas formas en los estudios de sistemas.

Cuestionarios abiertos.

Al igual, que las entrevistas, los cuestionarios pueden ser abiertos y se aplican cuando se quieren
conocer los sentimientos, opiniones y experiencias generales; también son útiles al explorar el
problema básico, por ejemplo, un analista que utiliza cuestionarios para estudiar los métodos de
verificación de crédito, en un medio ambiente de ventas al a menudeo, podría recabar mas
información provechosa de una pregunta abierta de este tipo: ¿Cómo podría simplificarse y
mejorarse el proceso de verificación de crédito para los clientes?

Cuestionarios cerrados.

El cuestionario cerrado limita las respuestas posibles del interrogado. Por medio de un cuidadoso
estilo en la pregunta, el analista puede controlar el marco de referencia. Este formato es el mejor
método para obtener información sobre los hechos. También fuerza a los individuos para que tomen
una posición y forma de opinión sobre los aspectos importantes.

Etapas en el desarrollo de un cuestionario

Los cuestionarios bien hechos no se desarrollan rápidamente, llevan tiempo y mucho trabajo. La
primera consideración se encuentra en determinar el objetivo del cuestionario. ¿Qué datos quiere
conocer el analista a través de su uso? El analista define como utilizar los cuestionarios a fin de
obtener los hechos al considerar la estructura mas útil para el estudio y la más sencilla de entender
por parte de los interrogados.

Lleva tiempo desarrollar preguntas bien elaboradas y deben siempre probarse y modificarse, si es
necesario, antes de que imprima una forma final y se distribuya.

Selección de quienes recibirán el cuestionario

Aquellas personas que reciban el cuestionario deben seleccionarse de a cuerdo con la información
que puedan proporcionar. Escribir o imprimir un cuestionario no significa que se pueda distribuir
ampliamente sin un análisis previo. Lo pueden contestar personas no calificadas y si el cuestionario
no es anónimo, y no será posible retirar sus respuestas de la muestra. La realización de esto también
es desgastante y cara.
Recopilacion Y Analisis De Documentos
RECOPILACION Y ANALISIS DE DOCUMENTOS

Consiste en recopilar, examinar y formular los requisitos del cliente y examinar cualquier
restricción que se pueda aplicar.

Para llevar a cabo este tipo de análisis se tabulan las respuestas en base a la cantidad de personas
que contestaron cada respuesta y el porcentaje que representa del total de la muestra.
Observacion Y Tecnica Strobe
OBSERVACION ESTRUCTURADA DEL AMBIENTE (STROBE)

Para que el analista de sistemas aprecie la forma en que los gerentes caracterizan su trabajo se usan
las entrevistas y cuestionarios, tal como se dijo anteriormente. Sin embargo la observación permite
que el analista vea de primera mano cómo los gerentes recopilan, procesan, comparten y usan la
información para hacer que el trabajo se realice.

³El método para la observación estructurada del ambiente es llamado STROBE. Es sistemático
debido a que:
(1) proporciona una metodología estándar y una clasificación estándar para el análisis de los
elementos organizacionales que influencian la toma de decisiones

(2) permite que otros analistas de sistemas apliquen el mismo marco de trabajo analítico a la misma
organización

(3) limita el análisis a la organización a como existe durante la etapa actual de su ciclo de vida. ´
Kendall & Kendall (Pág. 181).

Existen siete elementos concretos que son fácilmente observables por el analista de sistemas. Estos
elementos pueden revelar mucho acerca de la forma en que el tomador de decisiones recopila,
procesa, guarda y comparte información, así como acerca de la credibilidad del tomador de
decisiones en el espacio de trabajo:

1. Ubicación de la oficina.

Las oficinas accesibles tienden a incrementar la interacción y los mensajes informales. Las oficinas
inaccesibles disminuyen la frecuencia de interacción e incrementan los mensajes orientados a la
tarea. Las oficinas distribuidas dan como resultado la demora de reportes o memos en alguna de
ellas, en cambio, los grupos de oficinas motivan que se comparta la información.

2. Ubicación del escritorio del tomador de decisiones.

Proporciona pistas sobre el ejercicio de poder por el tomador de decisiones.

3. Equipo de oficina fijo.

Se conforma de archiveros, libreros, etc. Si no hay equipo, es probable que el tomador de decisiones
guarde pocos conceptos de información personalmente. Si hay abundancia de equipo, es presumible
que el tomador de decisiones almacene y valore mucha información.

4. Propiedades.

Todo el equipo pequeño que se usa para procesar información calculadoras, pantallas de video,
lápices, etc.)

5. Revistas y periódicos del negocio.

Estas revelan si el tomador de decisiones busca información externa o se apoya más en información
interna (reportes de la compañía, manuales de políticas, etc).

6. Iluminación y color de la oficina.

Nos indica la manera en que el tomador de decisiones recopila información. Un ejecutivo en una
oficina iluminada cálidamente, recopilará más información informalmente y, en cambio, en una
oficina brillantemente iluminada y coloreada se recolecta información mediante memorándums más
formales y reportes oficiales.

7. Vestimenta usada por los tomadores de decisiones.

El analista de sistemas puede obtener una comprensión de la credibilidad exhibida por los gerentes
de la organización observando la vestimenta que usan en el trabajo. El traje formal de tres piezas
para un hombre o el traje sastre para mujer, representan la máxima autoridad de acuerdo con
algunos investigadores que han estudiado la percepción de la apariencia de los ejecutivos.

Mediante el uso de STROBE el analista de sistemas puede obtener una mejor comprensión sobre la
manera en que los gerentes recopilan, procesan, almacenan y usan información.

Alternativas de aplicación

Existen estrategias para llevar a cabo los pasos antes mencionados:

V Análisis de fotografías. Consiste en fotografiar el ambiente de los tomadores de decisiones

y análisis posterior de las mismas sobre los elementos STROBE.
 V Enfoque de las listas de verificación/escala LIKERT. Es menos estructurada. Son listas con
escalas en relación con características del tomador de decisiones que fueron observables por
medio de elementos físicos en los ambientes organizacionales de los tomadores de
decisiones y existen rangos para la evaluación.
 V Lista anecdótica con símbolos

Es menos estructurada. Consiste en usar analistas de verificación anecdótica con símbolos de

abreviaturas significativas. Sirve para evaluar los elementos STROBE en comparación con la
narración organizacional generada por medio de entrevistas. símbolos (es una lista con situaciones
especificas y diversas respuestas que son dadas a través de símbolos)

Para usar esta técnica:

1. Determinar los temas organizacionales principales que se desprenden de las entrevistas.

2. Se construye una matriz, que liste las ideas principales a partir de la narrativa organizacional,
acerca de la recopilación, procesamiento, almacenamiento y compartición de la información (los
renglones) y elementos STROBE (columnas).

3. Se compara la narrativa y las acciones, se usa uno de los cinco símbolos adecuados para
caracterizar la relación entre la narración y el elemento relevante.

4. El analista crea una tabla que primero documenta y luego ayuda en el análisis de las
observaciones.
Herramientas Case
Las herramientas CASE (Computer Aided Software Engineering, Ingeniería de Software Asistida
por Ordenador) son diversas aplicaciones informáticas destinadas a aumentar la productividad en el
desarrollo de software reduciendo el coste de las mismas en términos de tiempo y de dinero. Estas
herramientas nos pueden ayudar en todos los aspectos del ciclo de vida de desarrollo del software
en tareas como el proceso de realizar un diseño del proyecto, calculo de costes, implementación de
parte del código automáticamente con el diseño dado, compilación automática, documentación o
detección de errores entre otras.

Historia
Ya en los años 70 un proyecto llamado ISDOS diseñó un lenguaje y por lo tanto un producto que
analizaba la relación existente entre los requisitos de un problema y las necesidades que éstos
generaban, el lenguaje en cuestión se denominaba PSL (Problem Statement Language) y la
aplicación que ayudaba a buscar las necesidades de los diseñadores PSA (Problem Statemente
Analyzer).

Aunque ésos son los inicios de las herramientas informáticas que ayudan a crear nuevos proyectos
informáticos, la primera herramienta CASE fue Excelerator que salió a la luz en el año 184 y
trabajaba bajo una plataforma PC.

Las herramientas CASE alcanzaron su techo a principios de los años 0. En la época en la que IBM
había conseguido una alianza con la empresa de software AD/Cycle para trabajar con sus
mainframes, estos dos gigantes trabajaban con herramientas CASE que abarcaban todo el ciclo de
vida del software. Pero poco a poco los mainframes han ido siendo menos utilizados y actualmente
el mercado de las Big CASE ha muerto completamente abriendo el mercado de diversas
herramientas más específicas para cada fase del ciclo de vida del software.

Objetivos

1. Mejorar la productividad en el desarrollo y mantenimiento del software.

2. Aumentar la calidad del software.

3. Mejorar el tiempo y coste de desarrollo y mantenimiento de los sistemas informáticos.

4. Mejorar la planificación de un proyecto

5. Aumentar la biblioteca de conocimiento informático de una empresa ayudando a la búsqueda de

soluciones para los requisitos.

6. Automatizar, desarrollo del software, documentación, generación de código, pruebas de errores y

gestión del proyecto.

7. Ayuda a la reutilización del software, portabilidad y estandarización de la documentación

8. Gestión global en todas las fases de desarrollo de software con una misma herramienta.

. Facilitar el uso de las distintas metodologías propias de la ingeniería del software.

Clasificación

Aunque no es fácil y no existe una forma única de clasificarlas, las herramientas CASE se pueden
clasificar teniendo en cuenta los siguientes parámetros:

1. Las plataformas que soportan.

2. Las fases del ciclo de vida del desarrollo de sistemas que cubren.

3. La arquitectura de las aplicaciones que producen.

4. Su funcionalidad.

La siguiente clasificación es la más habitual basada en las fases del ciclo de desarrollo que cubren:

‡ Upper CASE (U-CASE), herramientas que ayudan en las fases de planificación, análisis de
requisitos y estrategia del desarrollo, usando, entre otros diagramas UML.

‡ Middle CASE (M-CASE), herramientas para automatizar tareas en el análisis y diseño de la

aplicación.

‡ Lower CASE (L-CASE), herramientas que semiautomatizan la generación de código, crean

programas de detección de errores, soportan la depuración de programas y pruebas. Además
automatizan la documentación completa de la aplicación. Aquí pueden incluirse las herramientas de
Desarrollo_rápido_de_aplicaciones.

Existen otros nombres que se le dan a este tipo de herramientas, y que no es una clasificación
excluyente entre si, ni con la anterior:
‡ Integrated CASE (I-CASE), herramientas que engloban todo el proceso de desarrollo software,
desde análisis hasta implementación.

‡ Meta CASE, herramientas que permiten la definición de nuestra propia técnica de modelado, los
elementos permitidos del metamodelo generado se guardan en un repositorio y pueden ser usados
por otros analistas, es decir, es como si definiéramos nuestro propio UML, con nuestros elementos,
restricciones y relaciones posibles.

‡ CAST (Computer-Aided Software Testing), herramientas de soporte a la prueba de software.

‡ IPSE (Integrated Programming Support Environment), herramientas que soportan todo el ciclo de
vida, incluyen componentes para la gestión de proyectos y gestión de la configuración.

Por funcionalidad podríamos diferenciar algunas como:

‡ Herramientas de generación semiautomática de código.

‡ Editores UML.

‡ Herramientas de Refactorización de código.

‡ Herramientas de mantenimiento como los sistemas de control de versiones‡

Cristina Lazalde Miranda

Mayra Yanin Miranda Valles

Jesús Robles Domínguez

Esthela Gomez Hinojosa

Karla Domínguez Hernandez

Herramientas Case Estructuradas
Las herramientas Case utilizarán técnicas gráficas para diseñar las clases y sus interacciones, y para
utilizar objetos existentes adaptados en nuevas aplicaciones. Las herramientas deberían facilitar el
modelamiento en términos de eventos, triggers (iniciadores), estado de los objetos, etc. Las
herramientas de los CASE Orientados a Objetos generan códigos tan pronto como una clase sea
definida y permitirá al diseñador probar y utilizar el método creado. Las herramientas deberán ser
diseñadas para estimular la máxima creatividad y continuo refinamiento del diseño durante la
construcción.
Herramientas Case Orientadas a Objetos
Muchos de los beneficios son alcanzados únicamente cuando el Análisis y Diseño son utilizados
con herramientas CASE Orientadas a Objetos, basados en repositorios que generan códigos.

Fomenta la reutilización y extensión del código.

Permite crear sistemas más complejos.

Relacionar el sistema al mundo real.

Facilita la creación de programas visuales.

Construcción de prototipos

Agiliza el desarrollo de software

Facilita el trabajo en equipo

Facilita el mantenimiento del software

Lo interesante de la Programación Orientada a Objetos es que proporciona conceptos y
herramientas con las cuales se modela y representa el mundo real tan fielmente como sea posible.

Reutilización.- Las clases son diseñadas de tal manera que ellas puedan ser reutilizadas en muchos
sistemas. Para maximizar la reutilización las clases deben ser construidas de manera que puedan ser
personalizadas. Un repositorio debería ser cargado con una colección de clases reutilizables. Un
objetivo permanente de las técnicas Orientadas a Objetos, es conseguir la reutilización masiva en la
construcción de software.

Estabilidad.- Las clases diseñadas para la reutilización repetida, llegan a ser estables de la misma
manera que los microprocesadores y otros chips que son bastante estables. Las aplicaciones serán
construidas utilizando chips de software. El Diseñador piensa de Comportamiento de Objeto, no en
Niveles de Detalle. El encapsulamiento oculta los detalles y hace fácil el uso de clases complejas.
Las clases son semejantes a las cajas negras. El desarrollador utiliza la caja negra sin mirar su
interior. El tiene un entendimiento del comportamiento de la caja negra y cómo comunicarse con
ella.

Construcción de Objetos de complejidad Creciente.- Los objetos se construyen fuera de los objetos.
Una buena manera de fabricar es construir tomando una lista de materiales de partes y subpartes
existentes. Esto posibilita construir componentes de software complejos y los mismos se utilizarán
para construir otros bloques de software más complejos.

Confiabilidad.- EL software construido a partir de una librería de clases estables, es probable que se
encuentre libre de errores, respecto a construir software desde el inicio. Cada método en una clase
es en sí mismo simple y diseñado para ser confiable.

Verificación de Correcciones.- El Diseño Orientado a Objetos con técnica formal para la creación
de métodos, puede generar potencialmente software de alta confiabilidad. Técnicas para verificar y
garantizar la operación correcta de una clase, probablemente estén disponibles en nuevas
generaciones de herramientas CASE Orientadas a Objetos.

Diseño Rápido.- Las aplicaciones son creadas tomando componentes preexistentes. Muchos
componentes son construidos de tal forma que, puedan ser observados, personalizados, para un
diseño particular. Los componentes pueden ser vistos, customizados y enlazados en la pantalla de la
herramienta CASE.
Nuevos Mercados de Software.- Las compañías de software, deberían proporcionar librerías de
clases para áreas específicas, fácilmente adaptables a las necesidades de la organización. La era de
los paquetes monolíticos esta siendo reemplazada por software que incorpora clases y encapsula
paquetes de diferentes vendedores.

Diseño de Alta Calidad.- Los diseños son a menudo de alta calidad, ya que ellos se construyen a
partir de componentes que han sido aprobados y refinados repetidamente.

Integridad.- Las estructuras de Datos pueden ser utilizadas solamente con métodos específicos. Esto
es particularmente importante en sistemas distribuidos y sistemas CLIENTE/SERVIDOR, donde
usuarios desconocidos pueden tratar de accesar al sistema.

Facilidad de Programación.- Los programas son construidos utilizando pequeñas plazas de software
las cuales son generalmente fáciles de crear.

Fácil Mantenimiento.- Los programas de mantenimiento generalmente cambiarán los métodos

correspondientes a una clase. Cada clase realiza sus operaciones independientemente de otras
clases.

Creatividad.- Implementadores hábiles en poderosas herramientas CASE Orientadas a Objetos

laborando sobre estaciones de trabajo, encuentran que puede generar rápidamente muchas ideas.
Las herramientas estimulan la creación e implementan las invenciones. La genialidad individual
puede ser más creativa.

Ciclo de Vida Dinámico.- Los objetivos de desarrollo de un sistema, a menudo cambian durante la
implementación. Las herramientas CASE Orientadas a Objetos, hacen los cambios durante el ciclo
de vida rápidamente. Esto permite a los diseñadores de sistemas satisfacer mejor a los usuarios
finales, adaptarse a los cambios, refinar los objetivos y mejorar constantemente el diseño durante la
implementación.

Refinamiento durante la Construcción.- Las personas creativas cambian constantemente el diseño

de su trabajo mientras se está implementando. Esto conduce a más y mejores resultados. Los
trabajos creativos objetivos, son una y otra vez refinados. Las herramientas CASE Orientadas a
Objetos proporcionan a los constructores de software la capacidad para refinar el diseño durante la
implementación.

Modelamiento más realístico.- El Análisis Orientado a Objetos modela la empresa o área de

negocio de una manera más coherente y minuciosa que los métodos tradicionales de análisis. El
análisis se traslada directamente al diseño e implementación. En técnicas convencionales, el entorno
del problema cambia cuando vamos del análisis al diseño y del diseño a la programación. Con
técnicas de Análisis, Diseño e Implementación Orientados a Objetos utiliza el mismo paradigma y
lo refinan sucesivamente.

Interfase Gráfica Seductiva al Usuario.- Se debería utilizar interfaces gráficas para usuarios, tal que
ésta apunte al icono que relacione al objeto.

Independencia de Diseño.- Las clases son diseñadas independientemente de plataforma de

operación, hardware o software. Las clases emplean requerimientos y respuestas de forma. Esto
permite que ellos sean utilizados con múltiples sistemas operativos, DBMS, manejadores de redes,
interfaces gráficas para usuarios, etc.

Interoperatividad.- Software de diferentes vendedores pueden trabajar juntos. Un vendedor puede

utilizar clase de otros vendedores. La interoperatividad de software de diferentes vendedores es uno
de los objetivos más importantes de los estándares de la Orientación a Objetos. Software
desarrollados independientemente en lugares separados, deberían ser capaces de trabajar juntos y
presentarse como una unidad simple al usuario.

Computación Cliente / Servidor.- En el sistema Cliente / Servidor, las clases en el software cliente
deberían enviar sus requerimientos a las clases de software servidor y recibir respuestas. Una clase
servidor puede ser utilizada por muchos clientes. Esto puede accesar al software únicamente a
través de los métodos (así los datos se protegen de corrupciones).

Computación masivamente Distribuida.- Redes alrededor del mundo emplearán directorios de

software de objetos accesibles. El diseño orientado al objeto, es la clave para la computación
masivamente distribuida. Las clases en una máquina interactuarán con cualquier otra, sin necesidad
de saber dónde residen. Ellas envían y reciben mensajes en formatos estándares.

Computación Paralela.- La velocidad de las maquinas., pueden ser ampliamente mejoradas

mediante la instalación de computadoras en paralelo. Se pueden tener procesamientos simultáneos y
concurrentes en múltiples chips de procesadores (eventualmente, un chip puede tener muchos
procesadores). Objetos en diferentes procesadores se ejecutarán simultáneamente, cada uno de ellos
actuando independientemente.

Alto Nivel de Automatización de Bases de datos.- Las estructuras en Base de Datos OO, están
ligadas a métodos que toman acciones automáticas. Una Base de Datos OO, tiene su inteligencia
construida en la forma de métodos, mientras que otras bases de datos no.

Performance de Máquinas.- La Bases de Datos Orientada a Objetos han demostrado una mayor
performance que las bases de datos relacionales para ciertas aplicaciones con estructuras de datos
más complejas. Las bases de datos Orientados a Objetos, la computación concurrente y el diseño
Orientado a Objetos prometen mayores saltos en la performance de las máquinas LAN¶S basadas en
sistemas Cliente/Servidor. Emplearán servidores de Base de Datos concurrentes y orientadas al
objeto.

Migración.- Existiendo o no aplicaciones orientadas a objetos, ellos pueden ser preservados

convenientemente con una cobertura Orientada a Objetos, comunicándose entre ellos mediante
mensajes estándares Orientados a Objetos.

Mejores herramientas CASE.- Las herramientas Case utilizarán técnicas gráficas para diseñar las
clases y sus interacciones, y para utilizar objetos existentes adaptados en nuevas aplicaciones. Las
herramientas deberían facilitar el modelamiento en términos de eventos, triggers (iniciadores),
estado de los objetos, etc. Las herramientas de los CASE Orientados a Objetos generan códigos tan
pronto como una clase sea definida y permitirá al diseñador probar y utilizar el método creado. Las
herramientas deberán ser diseñadas para estimular la máxima creatividad y continuo refinamiento
del diseño durante la construcción.
Industriales de Librerías de Clases.- Las compañías de software comercializarán librerías para
diferentes áreas de aplicación. Las librerías de clases independientes de las aplicaciones, serán
también importantes y éstas serán proporcionadas como facilidades de herramientas CASE (VIC).

Librerías de Clases Corporativas.- Las corporaciones, crearán sus propias librerías de clases que
reflejen sus estándares internos y requerimientos de aplicación. La identificación TOP-DOWN de
los OBJETOS del negocio, es un aspecto importante de la ingeniería de la Información.

Los diferentes beneficios afectan a diferentes desarrolladores de diversas maneras. Examinaremos

los beneficios percibidos por:

Un Inventor.- El inventor de software requiere el conjunto de herramientas del CASE Orientadas a

Objetos, para generar códigos tan rápidos como él sobre la pantalla.

Fábrica de Software.- Para crear productos ricos e interesantes, el fabricante de software requiere
incorporar software de otros vendedores en sus propios diseños.

Jefe de Informática.- El objetivo es ensamblar aplicaciones de alta calidad tomando partes

reutilizables y utilizando un generador para todo código nuevo.

Un Equipo de Proyecto de Sistemas de Información.- Las herramientas CASE Orientadas a Objetos

posibilitan al equipo ajustar continuamente o diseñar la aplicación mientras se está construyendo
para satisfacer las necesidades del usuario, tan fielmente como sean posibles.

Un Integrador de Sistemas.- Un integrador de sistemas tiene que ver con:

Construcción del Sistema de Redes.

Maquinas y software de diferentes vendedores.

Un problema mayúsculo, es buscar que los software de los diferentes vendedores trabajen juntos.

Uno de los beneficios más importantes de la Orientación a Objetos es su nivel de reutilización. Las
técnicas Orientadas a Objetos permiten alcanzar la reutilización de dos maneras:

1. Construir software tomando componentes (clases) que ya existen.

2. Crear clases modificadas utilizando herencia que les permite reutilizar métodos y estructuras de
datos de clases de nivel superior.
Desarrollo De Prototipos
Problemas Candidatos

Para decidir si el prototipo debe incluirse o no Ciclo de Desarrollo de Sistema de Información, el

profesional considera los siguientes factores:

V Problemas no estructurado, novedosos y complejos, de información

personalizada del usuario, ya que sus salidas no son predecibles y definidas

V Problemas de ambiente Inestable, el profesional

también debe evaluar el contexto del sistema

!V Experiencia en diseños similares

"V No se conocen los requerimientos, la naturaleza

del sistema es tal que existe poca información con respecto a las características
que debe tener el nuevo sistema para satisfacer las necesidades del usuario

#V Los requerimientos deben evaluarse, se conocen los requerimientos aparentes

de información pero es necesario verificarlos y evaluarlos

$V Costos altos, donde la inversión involucra gran cantidad de recursos

financieros y humanos.

%V Altos riesgo, la evaluación inexacta de los requerimientos o el

desarrollo incorrecto ponen en peligro a la organización

&V El usuario, donde no está dispuesta examinar modelos en papel,

o no sabe lo que quiere pero lo reconocerá cuando lo vea.

'V Tecnologías Nuevas, la falta de experiencia en el uso de dichas

tecnologías, junto con el deseo de instalar nuevas tecnología hace que

sea propicio el uso del prototipo.

Etapas del Prototipo

El desarrollo de un prototipo se lleva a cabo en forma ordenada a través de las siguientes etapas,
Figura 1:

Identificación de Requerimientos Conocidos

El profesional de sistema identifica los requerimientos conocidos, generales, o características

esenciales y determina el propósito del prototipo de la aplicación.

Desarrollo de un Modelo

En esta etapa se explica el método iterativo y las responsabilidades a los usuarios ya que el usuario
participa directamente en todo el proceso. La rapidez con la que se genera el sistema es esencial
para que no se pierda el estado de ánimo sobre el proyecto y los usuarios puedan comenzar a
evaluar la aplicación con la mayor brevedad posible. El profesional de sistema para construcción
inicial del prototipo emplea cualquier herramienta, como Lenguajes de Cuarta Generación,
Generadores de Reportes, Generadores de Pantallas

En el desarrollo de un prototipo se preparan los siguientes componentes:

(V El lenguaje para el diálogo o conversación entre el usuario y el sistema

)V Pantallas y formatos para la entrada de datos
*V Módulos esenciales de procesamientos
+V Salida del sistema

La incorporación en la interfaz de entrada/salida de características representativas de las que serán

incluidas en el sistema final permite una mayor exactitud en el proceso de evaluación.

Revisión del Prototipo

Es responsabilidad del usuario trabajar con el prototipo y evaluar sus características y operación. La
experiencia con el sistema bajo condiciones reales permite la familiaridad indispensable para
determinar los cambios o mejoras que sean necesarios, o también la eliminación de características
innecesarias.

El profesional de sistema captura la información sobre lo que le gusta y lo que le desagrada a los
usuarios. Esta información tiene influencia en la siguiente versión del prototipo, la cual se presenta
modificada, refinada.

Iteración

Los dos últimos etapas descriptas anteriormente se repiten varias veces hasta que estén usuarios y
profesionales de sistema de acuerdo en que el prototipo ha evolucionado lo suficiente o que una
iteración mas no traerá beneficios adicionales.

Prototipo Terminado

Cuando el prototipo está terminado, es decir, tenemos la información que buscamos seguimos en el
punto donde habíamos quedado dentro del Ciclo de Desarrollo de Sistema.
Diseño Y Arquitectura De Productos De Software
La idea básica:
*Ensamblaje de partes de software previamente elaboradas

*Inspirada en los procesos de producción de sistemas

físicos

*Producción de aviones, vehículos, computadores, aparatos

electrónicos, etc.

*Fundamentada en la Reutilización de Software

*Asume la existencia de una industria de partes

Definicion
*se refieren a técnicas de ingeniería para crear un portafolio de
sistemas de software similares, a partir de un conjunto
compartido de activos de software, usando un medio común de
producción´ (Krueger, 2006)

*es un conjunto de sistemas de software que comparten un

conjunto común y gestionado de aspectos que satisfacen las
necesidades específicas de un segmento de mercado o misión y
que son desarrollados a partir de un conjunto común de activos
fundamentales [de software] de una manera preescrita´
(Clements and Northrop, 2002)

*consiste de una familia de sistemas de software que tienen

una funcionalidad común y alguna funcionalidad variable´
(Gomma, 2004)

Beneficios
*La entrega de productos de software de una manera

*más rápida,

*económica y

*con una mejor calidad

*Las LPS producen mejoras en:

*Tiempo de entrega del producto (time to market)

*Costos de ingeniería

*Tamaño del portafolio de productos

*Reducción de las tasas de defectos

*Calidad de los productos

*Beneficios tácticos y estratégicos (Krueger, 2006):

*Beneficios tácticos de ingeniería:

*Reducción en el tiempo promedio de creación y entrega de

nuevos productos

*Reducción en el número promedio de defectos por producto

*Reducción en el esfuerzo promedio requerido para desarrollar

y mantener los productos

*Reducción en el costo promedio de producción de los

 productos

*Incremento en el número total de productos que pueden ser

efectivamente desplegados y mantenidos

Aspectos fundamentales
*El paradigma de desarrollo de software LPS requiere que las
empresas que lo adopten consideren:

*Aspectos conceptuales

*Conceptos en los que las LPS se fundamentan

*Aspectos tecnológicos

*Qué tecnologías son fundamentales para desarrollar y mantener activos

y productos de software

*Aspectos metodológicos

*Cómo desarrollar y mantener los activos y productos de software

*Aspectos organizativos

*Cómo debe la empresa organizarse internamente

*Aspectos gerenciales

*Cómo gestionar los proyectos de desarrollo de activos y productos

Descomposicion Modular
DESCOMPOSICION MODULAR

El diseño modular propone dividir el sistema en partes diferenciadas y definir sus interfaces. sus
ventajas: claridad, reducción de costos y reutilizacion

Los pasos a seguir son:

1. Identificar los módulos

2. Describir cada módulo

3. Describir las relaciones entre módulos

Una descomposicion modular debe poseer ciertas cualidades mínimas para que se pueda considerar
suficiente válidad.

1. Independencia funcional

2. Acoplamiento
3. Cohesión

4. Comprensibilidad

5. Adaptabilidad

a) Independencia funcional
Cada módulo debe realizar una función concreta o un conjunto de funciones afines. Es
recomendable reducir las relaciones entre módulos al mínimo.

Para medir la independencia funcional hay dos criterios:acoplamiento y cohesión

b) Acoplamiento

El acoplamiento es un medida de la interconexión entre módulos en la estructura del programa.

Podemos graduarña en un amplio espectro, pero por lo general se tiede a que el acoplamiento sea lo
menor posible, esto es a reduir las interconexiones entre los distintos módulos en que se estructure
nuestra aplicación. El grado de acoplamiento mide la interrelación entre dos módulos, según el tipo
de conexión y la complejidad de la interfase:

. Fuerte

- Por contenido, cuando desde un módulo se puede cambiar datos locales de otro.

- Común, se emplea una zona común de datos a la que tienen acceso varios módulos.

. Moderado

- De control, la zona común es un dispositivo externo al que estan ligados los módulos, esto implica
que un cambio en el formato de datos los afecta a todos.

- Por etiqueta, en ontercambio de datos se realiza mediante una referencia a la estructura completa
de datos(vector, pila, árbol,grafo,«)

. Débil

- De datos, viene dado por los datos que intercambian los módulos. Es el mejor.

- Sin acoplamiento directo , es el acoplamiento que no existe

c) Cohesión

Un módulo coherente ejecuta una tarea sencilla en un procedimiento de sw y requiere poca

interacción con procedimientos que se ejecutan en otras partes de un programa. podemos decir que
un módulo coherente es aquel que intenta realizar solamente una cosa.
Para que n° de módulos no sea demaciado elevado y complique el diseño se tratan de agrupar
elementos afines y relacionados en un mismo módulo.

,V ALTA

. Cohesion abstraccional, se logra cuando se diseña el módulo como tipo abstracto de datos o como
una clase de objetos

. Cohesión funcional, el módulo realiza una función concreta y específica

-V MEDIA

. Cohesión secuencial, los elementos del módulo trabajan de forma secuencial

. Cohesión de comunicación, elementos que operan con el mismo conjunto de datos de entrada o de
salida

. Cohesión temporal, se agrupan elementos que se ejecutan en el mismo momento. Ej.Arrancar o

parar dispositivos

.V BAJA

. Cohesión lógica, se agrupan elementos que realizan funciones similares.

. Cohesión coincidental, es la peor y se produce cuando los elementos de un módulo no guardan

relación alguna

La descripción del comportamiento de un módulo permite establecer el grado de cohesión:

- Si es una frase compuesta y cotiene más de un verbo la cohesión será MEDIA

- Si contiene expreciones secuenciales (primero, entonces, cuando«), será temporal o secuencial

- Si la descripcion no se refiere a algo especifico(Ej. Todos los errores), cohesión lógica

- Si aparece ³inicializar´, ³preparar´, ³configurar´, probablemente sea temporal.

d) Comprensibilidad

Para facilitar los cambios, el mantenimiento y la reutilización de módulos es necesario que cada uno
sea comprensible de forma aislada. Para ello es bueno que posea independencia funcional, pero
además es deseable:

- Identificación, el nombre debe ser adecuado y descriptivo

- Documentación, debe aclarar todos los detalles de diseño e implementación que no queden de
manifiesto en el propio código

- SIMPLICIDAD, las soluciones sencillas son siempre laas mejores

e) Adaptabilidad

La adaptación de un sistema resulta más dificil cuando no hay idependencia funcional, es decir, con
alto acoplamiento y baja cohesión, y cuando el diseño es poco comprensible. Otros factores para
facilitar la adaptabilidad:

- Previsión, es necesario prever que aspectos del sistema pueden ser suseptibles de cambios en el
futuro, y poner estos elementos en módulos independientes, de manera que su modificación afecte
al menor número de módulos posibles

-Accesibilidad, debe resultar sencillo el acceso a los documentos de especificación, diseño, e

implementación para obtener un conocimiento suficiente del sistema antes de proceder a su
adaptación

- Consistencia, después de cualquier adaptación se debe mantener la consistencia del sistema,

incluidos los documentos afectados

Arquitectura del software

La Arquitectura de Software(As) constituye una disiplina dde reciente aparición y forma parte del
paradigma de la Ingenieria del Software. . Representa la versión moderna de un diseño software y
es apta para describir sistemas complejos.

Definicion: Arquitectura de Software

/V ³Una arquitectura de software es un conjunto de elementos arquitectónicos que tiene una

determinada forma. Las propiedades restringen la elección de los elementos de la
arquitectura mientras que la lógica captura la motivación de la elección de los elemetos y la
forma.´

(Perry y Wolf 12)

0V ³Una arquitectura de software incluye la descripción de elementos a partir de los cuales se

constituyen los sistemas de software, interacciones entre esos elementos, patrones que
guían la composición y restricciones sobre esos patrones. En general, un sistema de
software particular se define en términos de una colección de componentes e interacciones
entre dichos componentes. Tal sistema puede ser utilizado como un elemento en un sistema
más grande.´(Garlan y Shaw 16)
1 V ³Una arquitectura de software de un programa o sistema de computación es la estructura o
estructuras del sistema, el cual comprende componentes, las propiedades visibles externas
de dichos componentes y las relaciones entre ellos.´(Bass, Clements y Kazman 18).

Arquitecturas De Dominio Especifico

El reto para el diseño es diseñar el software y hardware para proporcionar características deseables
a los sistemas distribuidos y, al mismo tiempo, minimizar los problemas propios a estos sistemas.
Es necesario comprender las ventajas y desventajas de las diferentes arquitecturas de sistemas
distribuidos. Aquí se tratan dos tipos genéricos de arquitecturas de sistemas distribuidos:
Arquitectura cliente-servidor. En este caso el sistema puede ser visto como un conjunto de servicios
que se proporcionan a los clientes que hacen uso de dichos servicios. Los servidores y los clientes
se tratan de forma diferente en estos sistemas.
Arquitecturas de objetos distribuidos. Para esta arquitectura no hay distinción entre servidores y
clientes, y el sistema puede ser visto como un conjunto de objetos que interaccionan cuya
localización es irrelevante. No hay distinción entre un proveedor de servicios y el usuario de estos
servicios.

Ambas arquitecturas se usan ampliamente en la industria, pero la distribución de las aplicaciones

generalmente tiene lugar dentro de una única organización. La distribución soportada es, por lo
tanto, intraorganizacional. También se pueden tomar dos tipos más de arquitecturas distribuidas que
son más adecuadas para la distribución interorganizacional: arquitectura de sistemas peer-to-peer
(p2p) y arquitecturas orientadas a servicios. Los sistemas peer-to-peer han sido usados
principalmente para sistemas personales, pero están comenzando a usarse para aplicaciones de
empresa.

Los componentes en un sistema distribuido pueden implementarse en diferentes lenguajes de

programación y pueden ejecutarse en tipos de procesadores completamente diferentes. Los modelos
de datos, la representación de la información y los protocolos de comunicación pueden ser todos
diferentes. Un sistema distribuido, por lo tanto, requiere software que pueda gestionar estas partes
distintas, y asegurar que dichas partes se puedan comunicar e intercambiar datos. El término
middleware se usa para hacer referencia a ese software; se ubica en medio de los diferentes
componentes distribuidos del sistema. Bernstein (Bernstein, 16) resume los tipos de middleware
disponibles para soportar computación distribuida. El middleware es un software de propósito
general que normalmente se compra como un componente comercial más que escribirse
especialmente por los desarrolladores de la aplicación. Ejemplos de middleware son software para
gestionar comunicaciones con bases de datos, administradores de transacciones, convertidores de
datos y controladores de comunicación. Los sistemas distribuidos se desarrollan normalmente
utilizando una aproximación orientada a objetos. Estos sistemas están formados por partes
independientes pobremente integradas, cada una de las cuales puede interaccionar directamente con
los usuarios o con otras partes del sistema. Algunas partes del sistema pueden tener que responder a
eventos independientes. Los objetos software reflejan estas características; por lo tanto, son
abstracciones naturales para los componentes de sistemas distribuidos.
Diseño Software Arquitectura Multiprocesador
„   
+  „#$  ,   


Un sistema multiproceso o multitarea es aquel que permite ejecutar varios procesos de forma
concurrente, la razón es porque actualmente la mayoría de las CPU¶s sólo pueden ejecutar un
proceso cada vez. La única forma de que se ejecuten de forma simultánea varios procesos es tener
varias CPU¶s (ya sea en una máquina o en varias, en un sistema distribuido.
La ventaja de un sistema multiproceso reside en la operación llamada cambio de contexto. Esta
operación consiste en quitar a un proceso de la CPU, ejecutar otro proceso y volver a colocar el
primero sin que se entere de nada.

El multiproceso no es algo difícil de entender: más procesadores significa más potencia

computacional. Un conjunto de tareas puede ser completado más rápidamente si hay varias
unidades de proceso ejecutándolas en paralelo. Esa es la teoría, pero otra historia es la práctica,
como hacer funcionar el multiproceso, lo que requiere unos profundos conocimientos tanto del
hardware como del software. Es necesario conocer ampliamente como están interconectados dichos
procesadores, y la forma en que el código que se ejecuta en los mismos ha sido escrito para escribir
aplicaciones y software que aproveche al máximo sus prestaciones.

Para lograrlo, es necesario modificar varias facetas del sistema operativo, la organización del
código de las propias aplicaciones, así como los lenguajes de programación.

Se configuran dos computadoras de gran capacidad interconectados electrónicamente entre si. Esta
configuración recibe el nombre de multiproceso y se caracteriza porque permite proceso de datos
continuo aún en el caso de que surjan problemas de funcionamiento en alguno de las computadoras.

Un ejemplo de este tipo de sistema se muestra en la figura 6.3. Éste es un modelo sencillo de un
sistema de control de tráfico aéreo. Un conjunto de sensores distribuidos recolecta la información
del flujo de tráfico y la procesa localmente antes de enviarla al cuarto de control. Los operadores
toman decisiones utilizando esta información y dan instrucciones a un proceso de control de
diversas luces de tráfico. En este ejemplo existen varios procesos lógicos para administrar los
sensores, el cuarto de control y las luces de tráfico. Estos procesos lógicos son procesos sencillos a
un grupo de procesos. En este ejemplo se ejecutan en procesadores diferentes.

Los sistemas de software compuestos de procesos múltiples no necesariamente son sistemas

distribuidos. Si más de un procesador está disponible, entonces se puede implementar la
distribución, pero los diseñadores del sistema no siempre consideran lo puntos de distribución
durante el proceso de diseño. El enfoque de diseño para este tipo de sistemas es esencialmente el
mismo que para los de tiempo real.

Ventajas

‡ Es económica.

‡ El uso de componentes comúnmente disponibles, en grandes cantidades, permite ofrecer mayor

rendimiento, a un precio menor que el de máquinas con procesadores especialmente diseñados
(como por ejemplo las máquinas de procesadores vectoriales y de propósito específico).

‡ Adicionalmente, las computadoras paralelas son inherentemente escalables, permitiendo

actualizarlas para adecuarlas a una necesidad creciente.

‡ Las arquitecturas ³tradicionales´ se actualizan haciendo los procesadores existentes obsoletos por
la introducción de nueva tecnología a un costo posiblemente elevado. Por otro lado, una
arquitectura paralela se puede actualizar en términos de rendimiento simplemente agregando más
procesadores.

Desventajas

‡ En ocasiones se menciona también la limitante física; existen factores que limitan la velocidad
máxima de un procesador, independientemente del factor económico.
‡ Barreras físicas infranqueables, tales como la velocidad de la luz, efectos cuánticos al reducir el
tamaño de los elementos de los procesadores, y problemas causados por fenómenos eléctricos a
pequeñas escalas, restringen la capacidad máxima de un sistema uniprocesador, dejando la opción
obvia de colocar muchos procesadores para realizar cálculos cooperativamente.
Diseño Software Arquitectura Cliente Servidor
Modelo Cliente / Servidor:
Este modelo es un prototipo de sistemas distribuidos que muestra como los datos y el
procesamiento se distribuyen a lo largo de varios procesadores. Es una forma de dividir las
responsabilidades de un sistema de información
separando la interfaz del usuario de la gestión de la información. El funcionamiento básico de este
modelo consiste en que un programa cliente realiza peticiones a un programa servidor, y espera
hasta que el servidor de respuesta.

Características de un cliente En la arquitectura C/S el remitente de una solicitud es conocido como

cliente. Sus características son: ‡ Es quien inicia solicitudes o peticiones, tienen por tanto un papel
activo en la comunicación (dispositivo maestro o amo). ‡ Espera y recibe las respuestas del servidor.
‡ Por lo general, puede conectase a varios servidores a la vez. ‡ Normalmente interactúa
directamente con los usuarios finales mediante una interfaz gráfica de usuario.

Características de un servidor En los sistemas C/S el receptor de la solicitud enviada por cliente se
conoce como servidor. Sus características son: ‡ Al iniciarse esperan a que lleguen las solicitudes de
los clientes, desempeñan entonces un papel pasivo en la comunicación (dispositivo esclavo). ‡ Tras
la recepción de una solicitud, la procesan y luego envían la respuesta al cliente. ‡ Por lo general,
aceptan conexiones desde un gran número de clientes (en ciertos casos el número máximo de
peticiones puede estar limitado). ‡ No es frecuente que interactúen directamente con los usuarios
finales.

Ventajas ‡ Centralización del control: Los accesos, recursos y la integridad de los datos son
controlados por el servidor de forma que un programa cliente defectuoso o no autorizado no pueda
dañar el sistema. ‡ Escalabilidad: Se puede aumentar la capacidad de clientes y servidores por
separado. ‡ Fácil mantenimiento

Desventajas ‡ La congestión del tráfico (a mayor número de clientes, más problemas para el
servidor). ‡ El software y el hardware de un servidor son generalmente muy determinantes. Un
hardware regular de un ordenador personal puede no poder servir a cierta cantidad de clientes.
Normalmente se necesita software y hardware específico, sobre todo en el lado del servidor, para
satisfacer el trabajo. Por supuesto, esto aumentará el costo
Diseño Software Distribuido
Estoy invitando a todos los maestros y profesionales de esta area y/o carrera a colaborar
construyendo este sitio dedicado a esta hermosa y util profesion aportando el material apropiado a
cada uno de los mas de 1,000 temas que lo componen.

Tambien los invito a aportar material a los mas de 30,000 temas que constituyen las 30 carreras
profesionales que se imparten en los Institutos Tecnologicos de Mexico y se encuentran en este
sitio.
www.MiTecnologico.com es un esfuerzo personal y de muchos amigos de MEXICO y el Mundo
Hispano por devolver algo de lo mucho que hemos recibido en el proceso de la educacion superior,
saludos Prof Lauro Soto, Ensenada, BC, Mexico
PARA EMPEZAR SOLO USAR OPCION edit ABAJO Y EMPIEZA A CONSTRUIR ,
SALUDOS Y MUCHAS GRACIAS

Diseño Software Tiempo Real

El software de tiempo real esta muy acoplado con el mundo externo, esto es, el software de tiempo
real debe responder al ámbito del problema en un tiempo dictado por el ámbito del problema.
Debido a que el software de tiempo real debe operar bajo restricciones de rendimiento muy
rigurosas, el diseño del software esta conducido frecuentemente, tanto por la arquitectura del
hardware como por la del software, por las características del sistema operativo, por los requisitos
de la aplicación y tanto por los extras del lenguaje de programación como prospectos de diseño.
La computadora digital se ha convertido en una maquina omnipresente en al vida diaria de todos
nosotros. Las computadoras nos permiten ver juegos, así como contar el tiempo, optimizar el gasto
de gasolina de nuestras ultimas generaciones de coches y programar a nuestros aparatos.

Todas estas interacciones con las computadoras sean útiles o intrusivas son ejemplos de
computación de tiempo real. La computadora esta controlando algo que interactua con la realidad
sobre una base de tiempo de hecho, el tiempo es la esencia de la interacción