INSTITUTO TECNOLÓGICO DE JIQUILPAN Apuntes de Fundamentos de Desarrollo de Sistemas Ingeniería en Sistemas Computacionales Plan 2004

UNIDAD 1: CONCEPTOS INTRODUCTORIOS Introducción General. Seguramente si comprendemos algo de la teoría General de Sistemas nos ayudará a entender mejor un Sistema computarizado de información. Esto es muy importante, puesto que necesitamos Sistemas estables y confiables y existen muchos ejemplos de Sistemas no computarizados, como la cucaracha que ha sobrevivido millones de años en esta sociedad. Comencemos entonces con algunas definiciones básicas de Sistemas del New Collegiate Dictionary de Webster: Grupo de elementos interdependientes o que interactúan regularmente formando un todo (Ej.: el Sistema numérico). Juego organizado de doctrinas, ideas o principios, usualmente con la intención de explicar el acomodo o el trabajo de un todo sistemático (Ej.: el Sistema newtoniano de la mecánica). Patrón o arreglo armonioso: Orden. Etc. Podemos ver así que existen muchos tipos diferentes de Sistemas, de hecho casi todo aquello con lo que tenemos contacto en nuestra vida es un Sistema o forma parte de un Sistema. Organicemos entonces los distintos tipos de Sistemas en categorías: Sistemas Naturales: Ej. : Sistema geológico: ríos, cordilleras, etc. Sistemas Hechos Por El Hombre: Ej. : Sistema de comunicación: teléfono, señales de humo, etc. En la actualidad la mayoría de los Sistemas incluyen computadoras y muchos no podrían vivir sin ellas, pero sin duda muchos Sistemas existen antes de que las mismas se inventaran; algunos continúan por completo sin computarizar y otros la contienen como componente pero también incluyen componentes no computarizados. Veremos entonces que la labor primaria es analizar o estudiar un Sistema para determinar su esencia: su comportamiento requerido, independientemente de la tecnología utilizada para implantar el Sistema. En casi todos los casos podremos determinar si tiene sentido utilizar una computadora para llevar a cabo las funciones del Sistema solo tras haber modelado su comportamiento esencial. Ahora podríamos preguntarnos ¿porque no deberían automatizarse algunos Sistemas de procesamiento de información?, pueden existir muchas razones para esto como por ejemplo: Costo: podría resultar más barato continuar llevando a cabo las funciones y almacenando la información del Sistema en forma manual. Política: la comunidad usuaria podría impartir resistencia a las mismas, puesto que las ven como amenaza de su puesto laboral, pudiendo llegar a hacer lo imposible por lograr que falle si se les quiere imponer.

Elaborados por:

Lic. Martin Valencia

Pág. 1

INSTITUTO TECNOLÓGICO DE JIQUILPAN Apuntes de Fundamentos de Desarrollo de Sistemas Ingeniería en Sistemas Computacionales Plan 2004

Pero ahora nos ocuparemos de los Sistemas automatizados, aquellos hechos por el hombre que interactúan con o son controlados por una o más computadoras. Todos estos Sistemas tienden a poseer componentes comunes: Hardware: procesadores, discos, impresoras, terminales, etc. Software: Sistemas operativos, Sistemas de base de datos, programas de control de telecomunicaciones, etc. Personas: los que operan el Sistema, proveen material de entrada, consumen su salida, etc. Datos: información que el Sistema recuerda durante un período, etc. Procedimientos: políticas formales e instrucciones de operación del Sistema. Los Sistemas automatizados. Pueden recibir una división en categorías como ser: Sistemas en línea. Sistemas de tiempo Real. Sistemas de apoyo a decisiones. Sistemas basados en el conocimiento. Sistemas en línea: Son aquellos que acepta material de entrada directamente del área donde se creó. También es aquel en el que el material de salida o resultado de la computación se devuelve directamente a donde es requerido. Una característica común de estos es que entran datos a la computadora o se les recibe de ella en forma remota. Es decir que los usuarios del Sistema normalmente interactúan con la computadora desde terminales que pueden estar localizadas a cientos de kilómetros de la computadora misma. Otra característica es que sus datos almacenados usualmente se organizan de modo de que los componentes individuales de información puedan ser recuperados, modificados o ambas cosas en forma rápida y sin tener que efectuar necesariamente accesos a otros componentes de información del Sistema. Ejemplo: Sistema de reservación aérea, etc. Sistemas de tiempo Real. Puede definirse como aquel que controla un ambiente recibiendo datos, procesándolos y devolviéndolos con la suficiente rapidez como para influir en dicho ambiente en ese momento.

Elaborados por:

Lic. Martin Valencia

Pág. 2

INSTITUTO TECNOLÓGICO DE JIQUILPAN Apuntes de Fundamentos de Desarrollo de Sistemas Ingeniería en Sistemas Computacionales Plan 2004

Una de sus características son la velocidad de respuesta y su interacción tanto con personas como con un ambiente generalmente autónomo y hostil. Ejemplo: Sistemas de cajeros automáticos, etc. Sistemas de apoyo a decisiones. Son utilizados por gerentes y jefes para evaluar y analizar la misión de la organización. En lugar de consejos sobre una decisión de negocio en forma aislada, estos Sistemas ofrecen consejos más amplios y generales acerca de la naturaleza del mercado, preferencia del consumidor, comportamiento de la competencia, etc.

Sistemas basados en el conocimiento. También conocidos como Sistemas expertos, son asociados al campo de la inteligencia artificial. La meta de los científicos de la computación que trabajan en este campo, es producir programas capaces de imitar el desempeño humano en una gran variedad de tareas inteligentes. Son programas que contienen conocimientos y capacidades necesarias para desempeñarse en un nivel de experto. Desempeño experto significa por ejemplo nivel de desempeño de médicos que llevan a cabo diagnósticos y procesos terapéuticos

1.1. Introducción a los Sistemas 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.
Elaborados por: Lic. Martin Valencia Pág. 3

Las entradas constituyen la fuerza de arranque que suministra al Sistema sus necesidades operativas. pretende introducir una semántica científica de utilización universal. recursos humanos o información. etc. Martin Valencia Pág. . Clasificación extraída de apunte de cátedra. La Teoría de los Sistemas. Proceso: El proceso es lo que transforma una entrada en salida.INSTITUTO TECNOLÓGICO DE JIQUILPAN Apuntes de Fundamentos de Desarrollo de Sistemas Ingeniería en Sistemas Computacionales Plan 2004 Aportes Semánticos: Las sucesivas especializaciones de las ciencias obligan a la creación de nuevas palabras. Las entradas aleatorias representan entradas potenciales para un Sistema. estas se acumulan durante sucesivas especializaciones. Las entradas pueden ser: . De esta forma surgen problemas al tratarse de proyectos interdisciplinarios. una tarea realizada por un miembro de la organización. Entradas: Las entradas son los ingresos del Sistema que pueden ser recursos materiales. al azar. 4 . una computadora. como tal puede ser una máquina. que se relacionan formando un todo unitario y complejo. Podemos enumerarlas en: entradas. llegando a formar casi un verdadero lenguaje que sólo es manejado por los especialistas. Cabe aclarar que las cosas o partes que componen al Sistema. Elaborados por: Lic. no se refieren al campo físico (objetos). 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. un producto químico. De este modo las cosas o partes pasan a ser funciones básicas realizadas por el Sistema. sino más bien al funcional. para solucionar estos inconvenientes. un individuo.En serie: es el resultado o la salida de un Sistema anterior con el cual el Sistema en estudio está relacionado en forma directa. Sistema: Es un conjunto organizado de cosas o partes interactuantes e interdependientes. . procesos y salidas.Aleatoria: es decir.Retroacción: es la reintroducción de una parte de las salidas del Sistema en sí mismo. donde el término “azar” se utiliza en el sentido estadístico.

No obstante. origina un producto total mayor que la suma de sus productos tomados de una manera independiente. porque esta transformación es demasiado compleja. Al igual que las entradas estas pueden adoptar la forma de productos. . En las relaciones sinérgicas la acción cooperativa de subSistemas semi-independientes. ya que su desempeño mejora sustancialmente al desempeño del Sistema. el propósito para el cual existe el Sistema. en la mayor parte de las situaciones no se conoce en sus detalles el proceso mediante el cual las entradas se transforman en salidas.Simbióticas: es aquella en que los Sistemas conectados no pueden seguir funcionando solos.Superflua: Son las que repiten otras relaciones. Sin embargo. Las relaciones superfluas aumentan la probabilidad de que un Sistema funcione todo el tiempo y no una Elaborados por: Lic. Caja Negra: La caja negra se utiliza para representar a los Sistemas cuando no sabemos qué elementos o cosas componen al Sistema o proceso. En tal caso.INSTITUTO TECNOLÓGICO DE JIQUILPAN Apuntes de Fundamentos de Desarrollo de Sistemas Ingeniería en Sistemas Computacionales Plan 2004 En la transformación de entradas en salidas debemos saber siempre cómo se efectúa esa transformación. que es cuando un Sistema (parásito) no puede vivir sin el otro Sistema (planta). Martin Valencia Pág. 5 . Con frecuencia el procesador puede ser diseñado por el administrador. Las mismas son el resultado del funcionamiento del Sistema o.Sinérgica: es una relación que no es necesaria para el funcionamiento pero que resulta útil. Relaciones: Las relaciones son los enlaces que vinculan entre sí a los objetos o SubSistemas que componen a un Sistema complejo. que es cuando ambos Sistemas dependen entre si. este proceso se denomina “caja blanca”. A su vez puede subdividirse en unipolar o parasitaria. las variables funcionaran en cierto sentido. Podemos clasificarlas en: . . En tal caso la función de proceso se denomina una “caja negra”. y bipolar o mutual. servicios e información. alternativamente. La razón de las relaciones superfluas es la confiabilidad. presumiendo que a determinados estímulos. para la teoría de los Sistemas el término significa algo más que el esfuerzo cooperativo. que la procesará para convertirla en otra salida. Las salidas de un Sistema se convierte en entrada de otro. Diferentes combinaciones de entradas o su combinación en diferentes órdenes de secuencia pueden originar diferentes situaciones de salida. pero sabemos que a determinadas corresponden determinadas salidas y con ello poder inducir. repitiéndose este ciclo indefinidamente. Sinergia significa “acción combinada”. tomados en forma conjunta. Salidas: Las salidas de los Sistemas son los resultados que se obtienen de procesar las entradas.

Generalmente no se toman todas. existen infinitas relaciones. Ese foco de atención. d) En lo que hace a las relaciones entre el contexto y los Sistemas y viceversa.INSTITUTO TECNOLÓGICO DE JIQUILPAN Apuntes de Fundamentos de Desarrollo de Sistemas Ingeniería en Sistemas Computacionales Plan 2004 parte del mismo. Entre el Sistema y el contexto. que se suma al costo del Sistema que sin ellas puede funcionar. 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. Tanto en la Teoría de los Sistemas como en el método científico. Clasificación obtenida de apunte de cátedra. El contexto a analizar depende fundamentalmente del foco de atención que se fije. se trata de una relación mutua de contexto-Sistema. Elaborados por: Lic. y a su vez el Sistema influye. pero que influyen decididamente a éste. b) La determinación del alcance del límite de interés entre el contexto y el Sistema. se llama límite de interés. definen al Sistema tal como lo conocemos u observamos. el conjunto de objetos exteriores al Sistema. 6 . Martin Valencia Pág. Para determinar este límite se considerarían dos etapas por separado: a) La determinación del contexto de interés. 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. Estas relaciones tienen un problema que es su costo. Es posible que sólo interesen algunas de estas relaciones. Esto produciría una jerarquización de las distintas estructuras en función de su grado de complejidad. determinado con un límite de interés. y que deja afuera del límite de interés a la parte del contexto que no interesa al analista. Contexto: Un Sistema siempre estará relacionado con el contexto que lo rodea. el elemento que se aísla para estudiar. Atributos: Los atributos de los Sistemas. existe un concepto que es común a ambos: el foco de atención. a) Se suele representar como un círculo que encierra al Sistema. en términos de Sistemas. puesto que sólo será considerado lo que quede dentro de ese límite. o sea. Determinar el límite de interés es fundamental para marcar el foco de análisis. sino aquellas que interesan al análisis. aunque en una menor proporción. Rango: En el universo existen distintas estructuras de Sistemas y es factible ejercitar en ellas un proceso de definición de rango relativo. o aquellas que probabilísticamente presentan las mejores características de predicción científica. con lo que habrá un límite de interés relacional. influye sobre el contexto.

cuando se indica que el mismo está formado por partes o cosas que forman el todo. Variables: Cada Sistema y subSistema contiene un proceso interno que se desarrolla sobre la base de la acción. ni métodos análogos a riesgo de cometer evidentes falacias metodológicas y científicas. el cual para los primeros se denomina macroSistema. Parámetro: Uno de los comportamientos que puede tener una variable es el de parámetro. 7 . Elaborados por: Lic. Estos subSistemas forman o componen un Sistema de un rango mayor. Para aplicar el concepto de rango. a cada elemento que compone o existe dentro de los Sistemas y subSistemas. ya que conforman un todo en sí mismos y estos serían de un rango inferior al del Sistema que componen. SubSistemas: En la misma definición de Sistema. según el proceso y las características del mismo. Martin Valencia Pág. 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. interacción y reacción de distintos elementos que deben necesariamente conocerse. en consecuencia. Refiriéndonos a los rangos hay que establecer los distintos subSistemas. ya que sólo permanece inactiva o estática frente a una situación determinada. suele denominarse como variable. 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. Estos conjuntos o partes pueden ser a su vez Sistemas (en este caso serían subSistemas del Sistema de definición). que es cuando una variable no tiene cambios ante alguna circunstancia específica. Dado que dicho proceso es dinámico. El concepto de rango indica la jerarquía de los respectivos subSistemas entre sí y su nivel de relación con el Sistema mayor.INSTITUTO TECNOLÓGICO DE JIQUILPAN Apuntes de Fundamentos de Desarrollo de Sistemas Ingeniería en Sistemas Computacionales Plan 2004 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. no pueden aplicarse los mismos modelos. Pero no todo es tan fácil como parece a simple vista ya que no todas las variables tienen el mismo comportamiento sino que. no quiere decir que la variable es estática ni mucho menos. asumen comportamientos diferentes dentro del mismo proceso de acuerdo al momento y las circunstancias que las rodean. se hace referencia a los subSistemas que lo componen. por lo contrario. Esta concepción denota que un Sistema de nivel 1 es diferente de otro de nivel 8 y que.

INSTITUTO TECNOLÓGICO DE JIQUILPAN Apuntes de Fundamentos de Desarrollo de Sistemas Ingeniería en Sistemas Computacionales Plan 2004 Operadores: Otro comportamiento es el de operador. 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. un proceso de organización más completa y de capacidad para transformar los recursos. Elaborados por: Lic. sino que también son influenciadas por el resto de las variables y estas tienen también influencia sobre los operadores. Sin embargo en los Sistemas abiertos biológicos o sociales. para evitar su desaparición a través del tiempo. vuelven a ingresar al Sistema como recursos o información. 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 entropía de un Sistema es el desgaste que el Sistema presenta por el transcurso del tiempo o por el funcionamiento del mismo. se dice que a mayor o menor permeabilidad del Sistema el mismo será más o menos abierto. de esta forma al no haber entradas malas en el Sistema. Retroalimentación: La retroalimentación se produce cuando las salidas del Sistema o la influencia de éstas en el contexto. Feed-forward o alimentación delantera: Es una forma de control de los Sistemas. de tal manera que el mismo no tenga entradas corruptas o malas. Es el nivel de adaptación permanente del Sistema o su tendencia a la supervivencia dinámica. Cabe aquí una aclaración: las restantes variables no solamente son influidas por los operadores. En un Sistema cerrado la entropía siempre debe ser positiva. las fallas no serán consecuencia de las entradas sino de los proceso mismos que componen al Sistema. Los mismos deben tener rigurosos Sistemas de control y mecanismos de revisión. que son las variables que activan a las demás y logran influir decisivamente en el proceso para que este se ponga en marcha. es decir. Homeostasis y entropía: La homeostasis es la propiedad de un Sistema que define su nivel de respuesta y de adaptación al contexto. 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. Los Sistemas altamente entrópicos tienden a desaparecer por el desgaste generado por su proceso sistémico. Permeabilidad: La permeabilidad de un Sistema mide la interacción que este recibe del medio. reelaboración y cambio permanente. Martin Valencia Pág. 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. la entropía puede ser reducida o mejor aún transformarse en entropía negativa. donde dicho control se realiza a la entrada del Sistema. 8 . Esto es posible porque en los Sistemas abiertos los recursos utilizados para reducir el proceso de entropía se toman del medio externo.

Un Sistema es independiente cuando un cambio que se produce en él. Por el contrario los Sistemas de permeabilidad casi nula se denominan Sistemas cerrados. un estado o una característica de acuerdo a las modificaciones que sufre el contexto. son más sumisos. estos y los de permeabilidad media son los llamados Sistemas abiertos. 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. 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. Por el contrario los Sistemas descentralizados son aquellos donde el núcleo de comando y decisión está formado por varios subSistemas. Centralización y descentralización: Un Sistema se dice centralizado cuando tiene un núcleo que comanda a todos los demás. 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. no afecta a otros Sistemas. Los Sistemas centralizados se controlan más fácilmente que los descentralizados. Para que un Sistema pueda ser adaptable debe tener un fluido intercambio con el medio en el que se desarrolla. Martin Valencia Pág. ya que por sí solos no son capaces de generar ningún proceso. requieren menos recursos. Estabilidad: Un Sistema se dice estable cuando puede mantenerse en equilibrio a través del flujo continuo de materiales. 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. Mantenibilidad: Es la propiedad que tiene un Sistema de mantenerse constantemente en funcionamiento. Adaptabilidad: Es la propiedad que tiene un Sistema de aprender y modificar un proceso. energía e información. 9 . y estos dependen para su activación del primero. Elaborados por: Lic.INSTITUTO TECNOLÓGICO DE JIQUILPAN Apuntes de Fundamentos de Desarrollo de Sistemas Ingeniería en Sistemas Computacionales Plan 2004 Los Sistemas que tienen mucha relación con el medio en el cuál se desarrollan son Sistemas altamente permeables. En dicho caso el Sistema no es tan dependiente. 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. pero son más lentos en su adaptación al contexto.

Éxito: El éxito de los Sistemas es la medida en que los mismos alcanzan sus objetivos. Sexto nivel. Se le puede llamar nivel de los marcos de referencia. La falta de éxito exige una revisión del Sistema ya que no cumple con los objetivos propuestos para el mismo. genético-social. proceso o características en la medida que el medio se lo exige y es estático cuando el medio también lo es. Un Sistema altamente armónico es aquel que sufre modificaciones en su estructura. “Sistema abierto” o autoestructurado. 10 . Cuarto nivel.INSTITUTO TECNOLÓGICO DE JIQUILPAN Apuntes de Fundamentos de Desarrollo de Sistemas Ingeniería en Sistemas Computacionales Plan 2004 La estabilidad de los Sistemas ocurre mientras los mismos pueden mantener su funcionamiento y trabajen de manera efectiva (mantenibilidad). En este nivel se comienza a diferenciar la vida. 5. Aportes Metodológicos: 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. Suboptimización en cambio es el proceso inverso. Optimización y sub-optimización: Optimización modificar el Sistema para lograr el alcance de los objetivos. de modo que se modifique dicho Sistema de forma tal que el mismo pueda alcanzar los objetivos determinados. Elaborados por: Lic. Segundo nivel. Se puede denominar reloj de trabajo. 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. Considera movimientos necesarios y predeterminados. Primer nivel. Sistema animal. 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. Martin Valencia Pág. Está caracterizado por las plantas. Sistema dinámico simple. comportamiento teleológico y su autoconciencia. Puede de considerarse nivel de célula. El Sistema se autorregula para mantener su equilibrio. 2. mecanismo de control o Sistema cibernético. 3. Se caracteriza por su creciente movilidad. estructura estática. 6. Quinto nivel. 4. Tercer nivel. Armonía: Es la propiedad de los Sistemas que mide el nivel de compatibilidad con su medio o contexto.

Formando una actividad 4. una aproximación metodológica. se identifican y extraen sus similitudes estructurales. Estos elementos son la esencia de la aplicación del modelo de isomorfismo. y permitir una correspondencia biunívoca entre las distintas ciencias. De este modo las cosas o partes pasan a ser funciones básicas realizadas por el Sistema. Como evidencia de que existen propiedades generales entre distintos Sistemas. 8. Noveno nivel. es decir. Se pretende por comparaciones sucesivas. poesía y la compleja gama de emociones humanas. sino más bien al funcional. Podemos enumerarlas en: entradas. si bien intrínsecamente son diferentes. Para alcanzar un objetivo Elaborados por: Lic. no se refieren al campo físico (objetos). música. Completan los niveles de clasificación: estos son los últimos y absolutos. Cabe aclarar que las cosas o partes que componen al Sistema. la naturaleza y dimensiones del Sistema de valores. Sistema humano. Es el nivel del ser individual. CONCEPTO DE SISTEMAS 1. Octavo nivel. Teoría analógica o modelo de isomorfismo sistémico: Este modelo busca integrar las relaciones entre fenómenos de las distintas ciencias. Dinámicamente relacionados 3. la correspondencia entre principios que rigen el comportamiento de objetos que.INSTITUTO TECNOLÓGICO DE JIQUILPAN Apuntes de Fundamentos de Desarrollo de Sistemas Ingeniería en Sistemas Computacionales Plan 2004 7. que se relacionan formando un todo unitario y complejo. a la vez que facilitar la identificación de los elementos equivalentes o comunes. Sistemas trascendentales. exige un análisis iterativo que responde a la idea de modularidad que la teoría de los Sistemas desarrolla en sus contenidos. Procesos y Salidas. 1.1 Descripción General de Sistemas: Es un conjunto organizado de cosas o partes interactuantes e interdependientes. que se repite en forma permanente. Esto. La detección de estos fenómenos permite el armado de modelos de aplicación para distintas áreas de las ciencias. considerado como un Sistema con conciencia y habilidad para utilizar el lenguaje y símbolos. Séptimo nivel. 11 . los cuales también presentan estructuras sistemáticas e interrelaciones. Martin Valencia Pág. sutiles simbolizaciones artísticas. y considera el contenido y significado de mensajes. en algunos aspectos registran efectos que pueden necesitar un mismo procedimiento. 9. la transcripción de imágenes en registros históricos. los ineludibles y desconocidos. Sistema social o Sistema de organizaciones humanas constituye el siguiente nivel. Un conjunto de elementos 2.1.

porque esta transformación es demasiado compleja. Martin Valencia Pág. una computadora. En tal caso. Las mismas son el resultado del funcionamiento del Sistema o. pero sabemos que a determinadas corresponden determinadas salidas y con ello poder inducir. etc.INSTITUTO TECNOLÓGICO DE JIQUILPAN Apuntes de Fundamentos de Desarrollo de Sistemas Ingeniería en Sistemas Computacionales Plan 2004 5.retroacción: es la reintroducción de una parte de las salidas del Sistema en sí mismo. Las entradas constituyen la fuerza de arranque que suministra al Sistema sus necesidades operativas. alternativamente. recursos humanos o información. como tal puede ser una máquina. en la mayor parte de las situaciones no se conoce en sus detalles el proceso mediante el cual las entradas se transforman en salidas. Caja Negra: La caja negra se utiliza para representar a los Sistemas cuando no sabemos que elementos o cosas componen al Sistema o proceso. Las entradas aleatorias representan entradas potenciales para un Sistema. Diferentes combinaciones de entradas o su combinación en diferentes órdenes de secuencia pueden originar diferentes situaciones de salida.en serie: es el resultado o la salida de un Sistema anterior con el cual el Sistema en estudio está relacionado en forma directa. una tarea realizada por un miembro de la organización. este proceso se denomina “caja blanca”. el propósito para el cual existe el Sistema. Elaborados por: Lic. . servicios e información. las variables funcionaran en cierto sentido. Proceso: El proceso es lo que transforma una entrada en salida. 12 . Salidas: Las salidas de los Sistemas son los resultados que se obtienen de procesar las entradas. . un individuo. Clasificación extraída de apunte de cátedra.aleatoria: es decir. No obstante. donde el término “azar” se utiliza en el sentido estadístico. En la transformación de entradas en salidas debemos saber siempre como se efectúa esa transformación. Las entradas pueden ser: . Con frecuencia el procesador puede ser diseñado por el administrador. un producto químico. al azar. En tal caso la función de proceso se denomina una “caja negra”. Para proveer información/energía/materia Entradas: Las entradas son los ingresos del Sistema que pueden ser recursos materiales. presumiendo que a determinados estímulos. Al igual que las entradas estas pueden adoptar la forma de productos. Operando sobre datos/energía/materia 6.

ya que su desempeño mejora sustancialmente al desempeño del Sistema. Para determinar este límite se considerarían dos etapas por separado: Elaborados por: Lic. La razón de las relaciones superfluas es la confiabilidad. o sea. aunque en una menor proporción. Clasificación obtenida de apunte de cátedra. y a su vez el Sistema influye. 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. origina un producto total mayor que la suma de sus productos tomados de una manera independiente. Tanto en la Teoría de los Sistemas como en el método científico. En las relaciones sinérgicas la acción cooperativa de subSistemas semi-independientes.Simbióticas: es aquella en que los Sistemas conectados no pueden seguir funcionando solos. que se suma al costo del Sistema que sin ellas puede funcionar. Martin Valencia Pág. .INSTITUTO TECNOLÓGICO DE JIQUILPAN Apuntes de Fundamentos de Desarrollo de Sistemas Ingeniería en Sistemas Computacionales Plan 2004 Las salidas de un Sistema se convierte en entrada de otro. pero que influyen decididamente a éste. existe un concepto que es común a ambos: el foco de atención. Podemos clasificarlas en: . se llama límite de interés. Estas relaciones tienen un problema que es su costo. El contexto a analizar depende fundamentalmente del foco de atención que se fije. repitiéndose este ciclo indefinidamente. . Atributos: Los atributos de los Sistemas. Las relaciones superfluas aumentan la probabilidad de que un Sistema funcione todo el tiempo y no una parte del mismo. y bipolar o mutual. definen al Sistema tal como lo conocemos u observamos.Sinérgica: es una relación que no es necesaria para el funcionamiento pero que resulta útil. que la procesará para convertirla en otra salida.Superflua: Son las que repiten otras relaciones. se trata de una relación mutua de contexto-Sistema. en términos de Sistemas. el conjunto de objetos exteriores al Sistema. tomados en forma conjunta. que es cuando ambos Sistemas dependen entre si. para la teoría de los Sistemas el término significa algo más que el esfuerzo cooperativo. Contexto: Un Sistema siempre estará relacionado con el contexto que lo rodea. 13 . Relaciones: Las relaciones son los enlaces que vinculan entre sí a los objetos o subSistemas que componen a un Sistema complejo. el elemento que se aísla para estudiar. Ese foco de atención. 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. Sinergia significa “acción combinada”. que es cuando un Sistema (parásito) no puede vivir sin el otro Sistema (planta). A su vez puede subdividirse en unipolar o parasitaria. Sin embargo. influye sobre el contexto.

cuando se indica que el mismo está formado por partes o cosas que forman el todo. a) Se suele representar como un círculo que encierra al Sistema. Para aplicar el concepto de rango. puesto que sólo será considerado lo que quede dentro de ese límite. Elaborados por: Lic. Generalmente no se toman todas. sino aquellas que interesan al análisis. Esta concepción denota que un Sistema de nivel 1 es diferente de otro de nivel 8 y que. existen infinitas relaciones. SubSistemas: En la misma definición de Sistema. b) La determinación del alcance del límite de interés entre el contexto y el Sistema. Rango: En el universo existen distintas estructuras de Sistemas y es factible ejercitar en ellas un proceso de definición de rango relativo. 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. Refiriéndonos a los rangos hay que establecer los distintos subSistemas. en consecuencia. Estos conjuntos o partes pueden ser a su vez Sistemas (en este caso serían subSistemas del Sistema de definición). determinado con un límite de interés. El concepto de rango indica la jerarquía de los respectivos subSistemas entre sí y su nivel de relación con el Sistema mayor. 14 . 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 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. ya que conforman un todo en sí mismos y estos serían de un rango inferior al del Sistema que componen. d) En lo que hace a las relaciones entre el contexto y los Sistemas y viceversa. Martin Valencia Pág.INSTITUTO TECNOLÓGICO DE JIQUILPAN Apuntes de Fundamentos de Desarrollo de Sistemas Ingeniería en Sistemas Computacionales Plan 2004 a) La determinación del contexto de interés. o aquellas que probabilísticamente presentan las mejores características de predicción científica. con lo que habrá un límite de interés relacional. se hace referencia a los subSistemas que lo componen. Esto produciría una jerarquización de las distintas estructuras en función de su grado de complejidad. Determinar el límite de interés es fundamental para marcar el foco de análisis. y que deja afuera del límite de interés a la parte del contexto que no interesa al analista. Es posible que sólo interesen algunas de estas relaciones. ni métodos análogos a riesgo de cometer evidentes falacias metodológicas y científicas. no pueden aplicarse los mismos modelos. Entre el Sistema y el contexto.

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. según el proceso y las características del mismo. Retroalimentación: La retroalimentación se produce cuando las salidas del Sistema o la influencia de las salidas del Sistema en el contexto. ya que sólo permanece inactiva o estática frente a una situación determinada. que son las variables que activan a las demás y logran influir decisivamente en el proceso para que este se ponga en marcha. Parámetro: Uno de los comportamientos que puede tener una variable es el de parámetro. interacción y reacción de distintos elementos que deben necesariamente conocerse. Martin Valencia Pág. vuelven a ingresar al Sistema como recursos o información. Variables: Cada Sistema y subSistema contiene un proceso interno que se desarrolla sobre la base de la acción. de esta forma al no haber entradas malas en el Sistema. asumen comportamientos diferentes dentro del mismo proceso de acuerdo al momento y las circunstancias que las rodean. suele denominarse como variable. de tal manera que el mismo no tenga entradas corruptas o malas. que es cuando una variable no tiene cambios ante alguna circunstancia específica. las fallas no serán consecuencia de las entradas sino de los proceso mismos que componen al Sistema. no quiere decir que la variable es estática ni mucho menos. Dado que dicho proceso es dinámico. Feed-forward o alimentación delantera: Es una forma de control de los Sistemas. Pero no todo es tan fácil como parece a simple vista ya que no todas las variables tienen el mismo comportamiento sino que.INSTITUTO TECNOLÓGICO DE JIQUILPAN Apuntes de Fundamentos de Desarrollo de Sistemas Ingeniería en Sistemas Computacionales Plan 2004 Estos subSistemas forman o componen un Sistema de un rango mayor. Operadores: Otro comportamiento es el de operador. por lo contrario. a cada elemento que compone o existe dentro de los Sistemas y subSistemas. Cabe aquí una aclaración: las restantes variables no solamente son influidas por los operadores. 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. el cual para los primeros se denomina macroSistema. sino que también son influenciadas por el resto de las variables y estas tienen también influencia sobre los operadores. Homeostasis y entropía: Elaborados por: Lic. donde dicho control se realiza a la entrada del Sistema. 15 .

Asimismo. y estos dependen para su activación del primero. para evitar su desaparición a través del tiempo. requieren menos recursos. Es el nivel de adaptación permanente del Sistema o su tendencia a la supervivencia dinámica. 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. ambos actúan como condicionantes del nivel de evolución. estos y los de permeabilidad media son los llamados Sistemas abiertos. La entropía de un Sistema es el desgaste que el Sistema presenta por el transcurso del tiempo o por el funcionamiento del mismo. un proceso de organización más completa y de capacidad para transformar los recursos. Martin Valencia Pág. no afecta a otros Sistemas. Los Sistemas altamente homeostáticos sufren transformaciones estructurales en igual medida que el contexto sufre transformaciones. En dicho caso el Sistema no es tan dependiente. Los Sistemas centralizados se controlan más fácilmente que los descentralizados. En un Sistema cerrado la entropía siempre debe ser positiva. pero son más lentos en su adaptación al contexto. la entropía puede ser reducida o mejor aún transformarse en entropía negativa. son más sumisos. Por el contrario los Sistemas de permeabilidad casi nula se denominan Sistemas cerrados. Esto es posible porque en los Sistemas abiertos los recursos utilizados para reducir el proceso de entropía se toman del medio externo. Por el contrario los Sistemas Elaborados por: Lic. 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. Permeabilidad: La permeabilidad de un Sistema mide la interacción que este recibe del medio. Centralización y descentralización: Un Sistema se dice centralizado cuando tiene un núcleo que comanda a todos los demás. Los Sistemas que tienen mucha relación con el medio en el cuál se desarrollan son Sistemas altamente permeables.INSTITUTO TECNOLÓGICO DE JIQUILPAN Apuntes de Fundamentos de Desarrollo de Sistemas Ingeniería en Sistemas Computacionales Plan 2004 La homeostasis es la propiedad de un Sistema que define su nivel de respuesta y de adaptación al contexto. Los mismos deben tener rigurosos Sistemas de control y mecanismos de revisión. es decir. Sin embargo en los Sistemas abiertos biológicos o sociales. se dice que a mayor o menor permeabilidad del Sistema el mismo será más o menos abierto. 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. reelaboración y cambio permanente. Un Sistema es independiente cuando un cambio que se produce en él. Por el contrario los Sistemas descentralizados son aquellos donde el núcleo de comando y decisión está formado por varios subSistemas. 16 . ya que por sí solos no son capaces de generar ningún proceso. Los Sistemas altamente entrópicos tienden a desaparecer por el desgaste generado por su proceso sistémico.

Para que un Sistema pueda ser adaptable debe tener un fluido intercambio con el medio en el que se desarrolla. La falta de éxito exige una revisión del Sistema ya que no cumple con los objetivos propuestos para el mismo. Estabilidad: Un Sistema se dice estable cuando puede mantenerse en equilibrio a través del flujo continuo de materiales. 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. un estado o una característica de acuerdo a las modificaciones que sufre el contexto. 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.INSTITUTO TECNOLÓGICO DE JIQUILPAN Apuntes de Fundamentos de Desarrollo de Sistemas Ingeniería en Sistemas Computacionales Plan 2004 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. 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. Éxito: El éxito de los Sistemas es la medida en que los mismos alcanzan sus objetivos. Adaptabilidad: Es la propiedad que tiene un Sistema de aprender y modificar un proceso. 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. Mantenibilidad: Es la propiedad que tiene un Sistema de mantenerse constantemente en funcionamiento. 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. 17 . Suboptimización en cambio es el proceso inverso. energía e información. Martin Valencia Pág. Armonía: Es la propiedad de los Sistemas que mide el nivel de compatibilidad con su medio o contexto. Optimización y sub-optimización: Optimización modificar el Sistema para lograr el alcance de los objetivos. de modo que se modifique dicho Sistema de forma tal que el mismo pueda alcanzar los objetivos determinados. La estabilidad de los Sistemas ocurre mientras los mismos pueden mantener su funcionamiento y trabajen de manera efectiva (mantenibilidad). Elaborados por: Lic.

Los barcos transportan el petróleo desde los campos petrolíferos a las refinerías.INSTITUTO TECNOLÓGICO DE JIQUILPAN Apuntes de Fundamentos de Desarrollo de Sistemas Ingeniería en Sistemas Computacionales Plan 2004 1. o Sistemas de procesamiento de transacciones. el MYCIN verifica o rechaza las hipótesis planteadas. Otro ejemplo es el de la industria naviera. siguiendo una serie de tratados y convenciones internacionales. o inteligencia artificial. Para verificar la hipótesis el Sistema consulta a la base de conocimientos. el Sistema Experto plantea unas hipótesis. filial del Banco Internacional para la Reconstrucción y el Desarrollo. y también haciendo una serie de preguntas al usuario. Con las respuestas que recibe. siendo uno de los más transportados el petróleo. 18 . o Sistema de manejo de conocimiento. al ser consultado por el médico. según las especificaciones del cliente. cuyos pedidos pueden ser ya sea privado o por contrato. knowledge work system. el cual por medio de su Sistema de transacciones internacionales transportan diferentes tipos de carga de acuerdo a pedidos en diferentes países. El Sistema MYCIN. es transferido a empresas privadas de países subdesarrollados cuyo capital privado no basta. ¿Los componentes de Sistema especificados son compatibles y completos? Elaborados por: Lic. etc. 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. Sistemas de Conocimiento: KWS. Sistemas Expertos: AI. Un famoso Sistema experto es MYCIN. 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. ¿Pueden conjugarse los componentes solicitados por el cliente de forma conveniente y razonable? 2. Un ejemplo es la Corporación Financiera Internacional (CFI). el cual es un Sistema experto para la realización de diagnósticos.1. Otro Sistema experto es el XCON el cual es un Sistema experto de configuraciones el cual. artificial intelligence. solicita primero datos generales sobre el paciente: nombre. síntomas. 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.2 Tipos de Sistemas Sistemas de Transacciones: Son llamados TPS cuyas siglas corresponden a Transaction Processing System. Tiene como base de su funcionamiento las siguientes dos preguntas: 1. edad. configura redes de ordenadores VAX. Un ejemplo es el de aplicaciones como Photoshop. Martin Valencia Pág. Una vez conocida esta información por parte del Sistema.

comparando el presupuesto con el gasto real y mostrando el gasto estimado hasta el final del año fiscal. una corporación que se dedica a la producción de motores de propulsión a chorro. La primera. Los usuarios pueden accesar datos mediante una pantalla táctil. Los datos aparecen de los Sistemas actuales de producción y proporcionan información sobre la confiabilidad. Martin Valencia Pág. al mismo tiempo o a distintos tiempos.INSTITUTO TECNOLÓGICO DE JIQUILPAN Apuntes de Fundamentos de Desarrollo de Sistemas Ingeniería en Sistemas Computacionales Plan 2004 Las respuestas a estas preguntas son muy detalladas. Ellos compraron el Sistema denominado Commander EIS que permite representaciones a todo color y un menú imaginativo que puede aprenderse intuitivamente. Cualquiera puede conducir una junta electrónica y el Sistema puede ser usado de manera distribuida. Por sus características este Sistema provee acceso instantáneo a cualquier persona y cualquier lugar. En la práctica el usuario recorre pasillos. Las juntas se pueden realizar con los participantes en el mismo lugar o diferentes lugares. La importancia del Sistema está basada en dos ideas. la rapidez de toma de decisiones lo que resulta en una mejor eficiencia y productividad de las juntas. los usuarios pueden navegar a través del mundo virtual en búsqueda de encuentros sociales. su uso permite reducir los costos de viaje. Aunque no pretende reemplazar las juntas cara a cara. executive support system. El Sistema permite que los ejecutivos verifiquen el estado por programa. reconoce la importancia de la comunicación informal. el mundo virtual es independiente del mundo físico y puede ser organizado de acuerdo a las necesidades del usuario. Un ejemplo es el Sistema comprado por Pratt & Whitney. donde las distancias geográficas entre los participantes no son importantes. ratón o teclado y pueden agrandar las imágenes para mayores niveles de detalle. La segunda. Los usuarios se comunican a través de audio y video. oficinas y áreas comunes. Un Sistema GDSS es el Vision Quest. Sistemas de ejecutivos: ESS. el cual permite realizar junta electrónicas. o Sistemas de apoyo a decisiones de grupo. La administración puede bajar para ver los detalles específicos en Elaborados por: Lic. group decission support system. CRUISER está diseñado alrededor del concepto de comunidad o grupo virtual que existe sólo en un mundo virtual. Otro Sistema es el CRUISER cuyas siglas son para Computer Supported Spontaneous Interaction. Provee además características de la práctica de trabajo permitiéndole diferentes niveles de privacidad. 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. 19 . o Sistemas de apoyo a ejecutivos. y sobre las entregas. disponibilidad de motores y partes. CRUISER ataca uno de los problemas de los trabajos en equipo. La importancia de este Sistema se basa en la interacción informal. Entre sus ventajas se encuentra su facilidad de uso. con variaciones y excepciones que son destacadas mediante colores. 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. Sistemas de Apoyo a Grupos: GDSS. 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. todas ellas generadas por computadora. la interacción se realiza a través del teclado y el monitor de la computadora. El Sistema funciona en terminales de trabajo que pueden estar o no en el mismo lugar.

las propiedades de los Sistemas proveen una manera sencilla de separar un Sistema de otro. Entender la diferencia básica entre Sistemas. Como puede ser visto. permitiendo a los usuarios una gran flexibilidad para agregarlos y analizarlos para satisfacer sus necesidades. c) Por su relación con el Medio Ambiente: Elaborados por: Lic. y la experiencia ha demostrado que es todo lo que necesitan. Algunos ejemplos de Sistemas simples se podrán encontrar aquí. Clasificación de los Sistemas A través de la siguiente clasificación. pero pueden ser aceptadas debido a la clasificación de los Sistemas. 20 . 1. El Sistema sólo contiene datos crudos. uno ya no tiene que proveer ciertas características del Sistema cada vez.INSTITUTO TECNOLÓGICO DE JIQUILPAN Apuntes de Fundamentos de Desarrollo de Sistemas Ingeniería en Sistemas Computacionales Plan 2004 cada categoría. También cabe recordar que las clasificaciones presentadas aquí pueden no ser exclusivas (los Sistemas pueden pertenecer a diferentes clasificaciones) ni únicas (hay otros métodos de clasificación). No se cuenta con un manual del usuario. El Sistema es operado por medio de un menú muy fácil de usar. Martin Valencia Pág. a) Por su naturaleza: b) Naturales: Sistemas creados en los que el hombre no interviene en su creación. será un concepto fundamental utilizado en todos los cursos de señales y Sistemas. 1.3 Clasificación En este módulo algunas de las clasificaciones básicas de Sistemas serán temporalmente introducidas mientras que las propiedades más importantes de Sistemas serán explicadas. Los nuevos usuarios son capacitados mediante una demostración que dura media hora. Una vez que el conjunto de señales puede ser identificado por compartir propiedades particulares. y sus propiedades. Fig.1. así como de procesamiento digital de señales (Digital Signal Processing) DSP. 1 Clasificación de Sistemas de Información. también es importante entender otras Clasificaciones de Señales y se clasifican de la siguiente forma.-Artificiales: Sistemas creados por el hombre.

incide en las demás y en el conjunto. Medio Ambiente (Contexto): En los Sistemas abiertos y adaptables. d) Por su dependencia del Medio Ambiente 1. actúan y operan en función de los objetivos del Sistema.INSTITUTO TECNOLÓGICO DE JIQUILPAN Apuntes de Fundamentos de Desarrollo de Sistemas Ingeniería en Sistemas Computacionales Plan 2004 1. ya que el Sistema está permanentemente interactuando con él para lograr sus objetivos. Sistemas y subSistemas.-Adaptable (dinámico): Sistemas que ante un cambio en el contexto reaccionan en forma adecuada. Proceso/Transformación: Es el componente que transforma el estado original de las entradas en salidas. son los fines y las metas del Sistema. no interaccionan con el contexto. los cuales serán objeto de operaciones y/o procesos hasta transformarse en salidas.-Abierto: Sistemas que interactúan con el contexto. Se dice que los objetivos constituyen el factor o elemento que aglutina e integra a todas las partes del conjunto. la retroalimentación se asocia al concepto de control. teniendo en cuenta la finalidad para la que fueron creados. Martin Valencia Pág. ya sea porque la salida es errónea o posee fallas o porque se puede mejorar el Sistema. Esto da como resultado una auténtica categorización de supraSistemas (medio ambiente). reglas. así como sus interrelaciones. que responden a una lógica y orden. g) La alteración o variación de una de las partes o de sus relaciones. sin esta interacción no podrían existir. 21   Elaborados por: . Retroalimentación: Son aquellas salidas del Sistema que se convierte en entradas del mismo.-Todos los componentes de un Sistema.-Cerrado: Sistemas aislados. 2.-Todo Sistema contiene otros Sistemas y/o subSistemas y a la vez está contenido en otros Sistemas de carácter superior. Lic. e) Características de los Sistemas f) Todo Sistema cualquiera sea su naturaleza tiene las siguientes características básicas: 1. el Medio Ambiente tiene un papel preponderante. intercambiando elementos. 2. En general. procedimientos. Elementos de los Sistemas      Entradas Salidas Procesos Retroalimentación Medio Ambiente    Entrada/Insumo/Input: Constituye los componentes que ingresan al Sistema. La transformación es una serie de operaciones. 2.-No adaptable (estático): no modifican su conducta y/o estructura a pesar de cambios en el medio ambiente. Salida/Producto/Output: Son la expresión material de los objetivos del Sistema.

Prueba de Sistemas: Durante la prueba de Sistemas. al trabajar con los empleados y administradores. el Sistema se emplea de manera experimental para asegurarse de que el Software no tenga fallas. Por lo general. Los especialistas en Sistemas se refieren. es decir. a esta etapa como diseño lógico en contraste con la del desarrollo del Software. Investigación Preliminar: La solicitud para recibir ayuda de un Sistema de información puede originarse por varias razones: sin importar cuales sean estas. 2). a la que denominan diseño físico. Martin Valencia Pág. El Medio Ambiente influye en forma determinante en el Sistema. 22 .2 Ciclo de Vida de un proyecto de Software. del tiempo disponible para escribir el Software y de la disponibilidad de los programadores. que funciona de acuerdo con las especificaciones y en la forma en que los usuarios esperan que lo haga.INSTITUTO TECNOLÓGICO DE JIQUILPAN Apuntes de Fundamentos de Desarrollo de Sistemas Ingeniería en Sistemas Computacionales Plan 2004 En general el medio ambiente es cambiante lo que ocasiona que el Sistema deba ser dinámico. el proceso se inicia siempre con la petición de una persona. mientras que el Sistema influye débilmente en el Medio Ambiente. Desarrollo del Software: Los encargados de desarrollar Software pueden instalar Software comprobando a terceros o escribir programas diseñados a la medida del solicitante. El método del ciclo de vida para el desarrollo de Sistemas consta de 6 fases: 1). Diseño del Sistema: El diseño de un Sistema de información produce los detalles que establecen la forma en la que el Sistema cumplirá con los requerimientos identificados durante la fase de análisis. La elección depende del costo de cada alternativa. Elaborados por: Lic. revisarse y ajustarse a los cambios para poder lograr sus objetivos. con frecuencia. Determinación de los requerimientos del Sistema: 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. deben estudiar los procesos de una empresa para dar respuesta a las siguientes preguntas clave: ¿Qué es lo que hace? ¿Cómo se hace? ¿Con que frecuencia se presenta? ¿Qué tan grande es el volumen de transacciones o decisiones? ¿Cuál es el grado de eficiencia con el que se efectúan las tareas? ¿Existe algún problema? ¿Qué tan serio es? ¿Cuál es la causa que lo origina? 3). 4). Los analistas. El método de ciclo de vida para el desarrollo de Sistemas es el conjunto de actividades que los analistas. diseñadores y usuarios realizan para desarrollar e implantar un Sistema de información. 1. 5). los programadores que trabajan en las grandes organizaciones pertenecen a un grupo permanente de profesionales.

El desarrollo de Software va unido a un ciclo de vida compuesto por una serie de etapas que comprenden todas las actividades. y la elección de un cierto modelo para un determinado tipo de proyecto puede ser de vital importancia. es indudable que debe darse mantenimiento a las aplicaciones. y otros criterios de administración de proyectos. 6). La evaluación ocurre a lo largo de cualquiera de las siguientes dimensiones: *Evaluación operacional: Valoración de la forma en que funciona el Sistema. Elaborados por: Lic. Por consiguiente. las organizaciones y los usuarios cambian con el paso del tiempo.INSTITUTO TECNOLÓGICO DE JIQUILPAN Apuntes de Fundamentos de Desarrollo de Sistemas Ingeniería en Sistemas Computacionales Plan 2004 Se alimentan como entradas conjunto de datos de prueba para su procesamiento y después se examinan los resultados. y cuanto más tarde se haga más costoso resultará. confiabilidad global y nivel de utilización. Dado que normalmente se trata de necesidades del cliente para el que se creará la aplicación. A grandes rasgos. hay que tener en cuenta que retomar etapas previas es costoso. instalar la aplicación y construir todos los archivos de datos necesarios para utilizarla. habrá que ver la forma en que estas se afrontan (existen diversos modelos de ciclo de vida. una pequeña descripción de etapas con que podemos contar a lo largo del ciclo de vida del Software. concuerdan con presupuestos y estándares. p. tal como sugiere el modelo en cascada o lineal. y no cómo. por su situación en el ciclo. También se incluye la valoración de los métodos y herramientas utilizados en el desarrollo. tener una etapa de validación al final del proyecto. las aplicaciones se emplean durante muchos años. por tanto el hecho de contar con una etapa de validación tardía tiene su riesgo y. Implantación y evaluación: La implantación es el proceso de verificar e instalar nuevo equipo. hasta aquel en que el producto deja definitivamente de ser utilizado por el último de sus usuarios. También se incluye el impacto sobre el flujo de información externo e interno. siendo que debe ser comprendido por ambas partes (puede incluso tomarse como base para el propio acuerdo comercial). 23 . puede implicar serios problemas sobre la gestión de determinados proyectos. La evaluación de un Sistema se lleva a cabo para identificar puntos débiles y fuertes. *Impacto organizacional: Identificación y medición de los beneficios para la organización en áreas tales como finanzas. el orden de las etapas es un factor importante. lo adecuado de los formatos de información. Sin embargo. una vez delimitadas en cierta manera las etapas.ej. tiempo de respuesta. 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é. desde el momento en que surge la idea de crear un nuevo producto Software. el documento resultante suele tener como origen una serie de entrevistas cliente-proveedor situadas en el contexto de una relación comercial. incluso el ambiente es diferente con el paso de las semanas y los meses. *Desempeño del desarrollo: La evaluación de proceso de desarrollo de acuerdo con criterios tales como tiempo y esfuerzo de desarrollo. eficiencia operacional e impacto competitivo. incluyendo su facilidad de uso. Una vez instaladas. *Opinión de loa administradores: evaluación de las actividades de directivos y administradores dentro de la organización así como de los usuarios finales. entrenar a los usuarios. se va a desarrollar). Etapas en el ciclo. Martin Valencia Pág.

sin errores de diseño y/o programación. de Jacobson es una muy buena elección para llevar a cabo la especificación del Sistema). el Sistema Gestor de Bases de Datos a utilizar en su caso. Observación: Aunque todo debe ser tratado a su tiempo. librerías. plataforma. Diseño Tras la etapa anterior ya se tiene claro que debe hacer el Sistema. el documento obtenido en la etapa anterior se tomará como punto de partida para esta fase. muchas veces nos vamos a encontrar con unas decisiones previamente impuestas sobre lenguaje. Su contenido es aún insuficiente y lleno de imprecisiones que será necesario completar y depurar. qué funcionalidades va a aportar y qué comportamiento va a tener. definidos en las etapas anteriores. 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. use cases. redes. … que van a dar una descripción clara de qué Sistema vamos a construir. Lo más normal será que no resulte posible obtener una buena especificación del Sistema a la primera. ahora tenemos que determinar como va a hacerlo (¿cómo debe ser construido el Sistema?. 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. 24 . se pasará de casos de uso esenciales a su definición como casos expandidos reales. detalle de sus funcionalidades.). Análisis Es necesario determinar que elementos intervienen en el Sistema a desarrollar. 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. aquí se definirán en detalle entidades y relaciones de las bases de datos. se seleccionará el lenguaje más adecuado. Para ello se enfocará el Sistema desde tres puntos de vista relacionados pero diferentes: Funcional. quedan bastantes empresas en las que. Estático. Observación: Lamentablemente en la actualidad. y sería muy deseable que las decisiones correspondientes en esta etapa fueran tomadas precisamente en esta etapa. Martin Valencia Pág. se pasa directamente a la etapa de implementación. 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. a pesar de tener que enfrentarse a proyectos grandes-medios. sino más bien debidos a la propia publicidad como consejera). etc. así como su estructura. tras una reunión comercial en que tan solo se ha conseguido recabar una breve lista de requerimientos. y por otra parte pueden surgir cambios externos que supongan requerimientos nuevos o modificaciones de los ya contemplados). año 2. Dinámico. Es conveniente que sean planteadas al menos tanto a nivel de cada Elaborados por: Lic. en el correspondiente lenguaje de programación y/o para un determinado Sistema gestor de bases de datos. evolución en el tiempo. relaciones. 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. etc. Pruebas El objetivo de estas pruebas es garantizar que el Sistema ha sido desarrollado correctamente.INSTITUTO TECNOLÓGICO DE JIQUILPAN Apuntes de Fundamentos de Desarrollo de Sistemas Ingeniería en Sistemas Computacionales Plan 2004 Especificaciones Ahora se trata de formalizar los requerimientos. análisis y diseño con la consiguiente pérdida de control sobre la gestión del proyecto. Implementación legado este punto se empieza a codificar algoritmos y estructuras de datos.000. configuraciones Hardware.

fruto de la propia evolución (p. Según el modelo de ciclo de vida.  Ajustar las especificaciones del producto. La mayoría de las veces en que se desarrolla una nueva aplicación. OBJETIVOS DE CADA FASE Dentro de cada fase general de un modelo de ciclo de vida. A partir de este momento se entra en la etapa de mantenimiento.ej.  Formalizar el acuerdo con los usuarios. como de integración del Sistema (según sea la naturaleza del proyecto en cuestión se podrán tener en cuenta pruebas adicionales. recibiendo en cada pasada de ejecución aportaciones de los resultados intermedios que se van produciendo (realimentación). mejora del rendimiento). Fase de definición (¿qué hacer?)  Estudio de viabilidad. de rendimiento). Fase de diseño (¿cómo hacerlo? Soluciones en coste.  Establecer métodos de validación del diseño.  Asegurar que los requisitos son alcanzables.  Realizar una planificación detallada. que servirán de guía para la verificación de que el Sistema cumple con lo descrito por estos). cumpliendo ya los objetivos para los que ha sido creada).  Asignar recursos materiales para cada una de las funciones. se piensa solamente en un ciclo de vida para su creación.  Conocer los requisitos que debe satisfacer el Sistema (funciones y limitaciones de contexto).INSTITUTO TECNOLÓGICO DE JIQUILPAN Apuntes de Fundamentos de Desarrollo de Sistemas Ingeniería en Sistemas Computacionales Plan 2004 módulo (aislado del resto). tiempo y calidad)  Identificar soluciones tecnológicas para cada una de las funciones del Sistema. 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).  Proponer (identificar y seleccionar) subcontratas. nuevas opciones para el usuario debidas a nuevas operaciones contempladas para el producto). de manera que lo que conceptualmente se considera una misma fase se pueda ejecutar más de una vez a lo largo de un proyecto. ELEMENTOS DEL CICLO DE VIDA Un ciclo de vida para un proyecto se compone de fases sucesivas compuestas por tareas planificables. la sucesión de fases puede ampliarse con bucles de realimentación. Elaborados por: Lic.ej. Mantenimiento y evolución Finalmente la aplicación resultante se encuentra ya en fase de producción (en funcionamiento para el cliente. p. Fase de construcción  Generar el producto o servicio pretendido con el proyecto. Martin Valencia Pág. que supondrá ya pequeñas operaciones tanto de corrección como de mejora de la aplicación (p.ej. así como otras de mayor importancia. generados a través de las correspondientes fases previas. 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. 25 . se pueden establecer una serie de objetivos y tareas que lo caracterizan.

Estructura organizacional (tiene roles y responsabilidades. clientes. emprendido para crear un producto o un servicio también único. 26   Elaborados por: . La gestión de proyectos es la disciplina de Planificar. sponsor. Un proyecto es un esfuerzo temporal. 1.INSTITUTO TECNOLÓGICO DE JIQUILPAN Apuntes de Fundamentos de Desarrollo de Sistemas Ingeniería en Sistemas Computacionales Plan 2004   Integrar los elementos subcontratados o adquiridos externamente. conocimientos. ej. Las características o atributos comunes a la mayoría de los proyectos:       Objetivo (poner los pies en la tierra. DESVIACIONES: Si hay desviaciones. Lic. Martin Valencia Pág. para identificar oportunamente cualquier desviación sobre lo planificado con el objetivo de tomar decisiones oportunas para corregirlas. Validar que el producto obtenido satisface los requisitos de diseño previamente definidos y realizar. único y progresivo. Fase de mantenimiento y operación  Operación: asegurar que el uso del proyecto es el pretendido.2. Aspectos del seguimiento en la gestión de los proyectos  El seguimiento es parte fundamental de la Gestión de Proyectos se basa en proveer una adecuada visibilidad a la administración sobre la situación del proyecto. la naturaleza del proyecto debe ser real. dinero y recursos. organizar y administrar recursos de manera tal que se pueda culminar todo el trabajo requerido en el proyecto dentro del alcance. VISIBILIDAD: Hace referencia a la actitud del líder. gerente de proyecto.1 Planificación y Gestión del Proyecto. de cara a estar siempre enterado de cómo va el proyecto y su posible desviación de los parámetros establecidos. Sistema de Control e Información (por lo menos un Sistema manual o automatizado de registrar la documentación e información relacionada al proyecto). es decir. si es necesario.  Mantenimiento (nos referimos a un mantenimiento no habitual. Complejo (no es nada sencillo y está compuesto por múltiples elementos) Demanda recursos (Requiere habilidades. líder de proyecto. el tiempo. sustentable y medible). en función del tiempo. para conocer si es posible volver al camino correcto y cuánto costaría. se deben cuantificar. además se debe cuantificar el grado de desviación. capital y esfuerzo humano de diversas áreas de una organización o comunidad). errores o inconsistencias. Calendario de Actividades (debe tener un programa de actividades o plan de trabajo). los ajustes necesarios en dicho diseño para corregir posibles lagunas. etc). aquel que no se limita a reparar averías o desgastes habituales -este es el caso del mantenimiento en producto. y coste definidos.

para conocer el estado del proyecto. Estas pueden ir desde la compatibilidad con cierto Sistema operativo hasta la adecuación a leyes o regulaciones aplicables al producto Una colección de requerimientos describe las características o atributos del Sistema deseado. revisiones. 27    Elaborados por: . para solventar el problema. Lic.2 Determinación de Requerimientos.2. Conjunto de actividades encaminadas a obtener las características necesarias que deberá poseer el nuevo Sistema. Rentabilidad. Calidad. Riesgos. TECNICAS DE SEGUIMIENTO: Las herramientas más usadas. Un requerimiento no funcional: de rendimiento. Los reportes deben dar fe de: Progreso. Otros tipos de limitaciones externas. en la Gestión de Proyectos son reuniones. Recursos Humanos y Recursos Materiales entre otros. Se omite el cómo debe lograrse su implementación. y cómo debe realizar sus funciones. etc. etc. Los analistas estructuran su investigación al buscar respuestas a las siguientes cuatro importantes preguntas: ¿Cuál es el proceso básico de la empresa? ¿Qué datos utiliza o produce esta empresa? ¿Cuáles son los límites impuestos por el tiempo y la carga de trabajo? ¿Qué controles de desempeño utiliza? Existen tres tipos de requerimientos. el testeo. ya que esto debe ser decidido en la etapa de diseño por los diseñadores. la facilidad de uso. 1. TOMA DE DECISIONES: Después de ver en que se falla hay que tomar decisiones. Costes. Martin Valencia Pág. Tiempos.. pues a veces se esconden detrás de otros. Algunos ejemplos de aspectos solicitables son la disponibilidad. Conviene que todo el equipo envíe reportes del grado de avance de sus tareas y actividades. es el estudio de un Sistema. de la manera más sencilla y eficaz de entender. y Software administrativo. Este tipo de requerimiento específica algo que el Sistema entregado debe ser capaz de realizar. el mantenimiento. para comprender cómo trabaja y dónde es necesario efectuar mejoras o cambios considerables. reportes. de calidad.  Un requerimiento funcional puede ser una descripción de lo que un Sistema debe hacer. actividad o proceso.INSTITUTO TECNOLÓGICO DE JIQUILPAN Apuntes de Fundamentos de Desarrollo de Sistemas Ingeniería en Sistemas Computacionales Plan 2004    FRECUENCIA: Cuanto más rápido se identifique una deficiencia en el proyecto más fácil será enmendarlo por eso se recomiendan análisis y revisiones semanales. especifica algo sobre el propio Sistema. Alcance. se debe tener cuidado en la identificación de los causantes del retraso. Problemas. que afectan en una forma indirecta al producto.

si el requerimiento fue satisfecho o no. procesan datos por alguna razón por ejemplo: en un Sistema de pedidos los clientes son procesados de forma tal que sean artículos indicados. Esta verificación puede lograrse mediante inspección. estos Sistemas pueden utilizar datos que se originan dentro de empresas como los generados por el procesamiento de transacciones fuera de ella. el tiempo y los recursos disponibles. y no remitir a otras fuentes externas que los expliquen con más detalle.     Estas características suelen ser subjetivas. se tiende a medir otras métricas o indicadores que sí pueden ser calculados de forma automática y que. por ejemplo asociaciones o fuentes comerciales en algunos casos se procesan los datos de transacción para generar Elaborados por: Lic. el lenguaje empleado entre los distintos requerimientos debe ser consistente también. Algunos brindan su porte para decisiones recurrentes mientras que otros son únicos y no recurrentes. demostración o testeo. deben ser reformulados hasta hacerlo. análisis. Completo: Los requerimientos deben contener en sí mismos toda la información necesaria. Los requerimientos bien formulados deben satisfacer varias características. capturan. de algún modo. Los Sistemas a nivel de transacciones. Asimismo. No ambiguo: El texto debe ser claro. no pueden ser calculadas de forma automática por ningún Sistema. Si no lo hacen. aunque aun así debe referenciar los aspectos importantes Consistente: Ningún requerimiento debe entrar en conflicto con otro requerimiento diferente. Los analistas seleccionados para trabajar en un Sistema de pedidos deben conocer todo lo relacionado cuándo procesan estas transacciones. Alcanzable: Un requerimiento debe ser un objetivo realista.    Necesario: Lo que pida un requerimiento debe ser necesario para el producto. 28 . presente o el futuro. posible de ser alcanzado con el dinero. Es probable que los Sistemas de decisión tengan que ver con el pasado. ni con parte de otro. preciso y tener una única interpretación posible. es decir. Requerimiento de decisión de los usuarios: A diferencia de las actividades de transacción las relacionadas con decisiones no siguen un procedimiento especifico las rutinas son muy claras y es posible que los controles vagos. pueden sustituir o mapear con esta lista de características.INSTITUTO TECNOLÓGICO DE JIQUILPAN Apuntes de Fundamentos de Desarrollo de Sistemas Ingeniería en Sistemas Computacionales Plan 2004  En la ingeniería de Software se aplica el mismo significado. Por ello. sólo que el énfasis está puesto en el propio Software. Verificable: Se debe poder verificar con absoluta certeza. Martin Valencia Pág. Conciso: Debe redactarse en un lenguaje comprensible por los inversores en lugar de uno de tipo técnico y especializado.

¿QUÉ ES EL ANÁLISIS DE SISTEMAS? Ciencia encargada del análisis de Sistemas grandes y complejos y la interacción entre esos Sistemas. La recepción del pedido ilustra la importancia de considerar las ramificaciones de un tipo de actividad para el resto de las organizaciones. que consiste en relevar la información actual y proponer los rasgos generales de la solución futura. Algunas veces los Sistemas abarcan los trabajos de varios deptos. Cuando el grupo de ventas toma un pedido la acción da origen a una serie de actividades que afectan a las demás áreas. 29 .2. Esta área se encuentra muy relacionada con la Investigación de operaciones. Martin Valencia Pág. Es probable que los analistas que tiene interés en el proceso de recepción de pedidos no trabaje al mismo tiempo sobre el Sistema de facturación.3 Análisis y Diseño. Cuando los analistas estudian Sistemas para un departamento también deben evaluar las implicaciones. Afecta al de los otros. LO QUE NO ES EL ANÁLISIS DE SISTEMAS No es profesional en mantenimiento de computadores. Requerimiento de toda la organización: En las empresas los departamentos dependen de uno de otro para brindar servicios para fabricar productos y satisfacer a los clientes. También se denomina análisis de Sistemas a una de las etapas de construcción de un Sistema informático. No es especialista en redes. No es desarrollador de Hardware. sin embargo deben tener conocimientos de cualquier requerimiento en cualquier otra parte de la organización. Por consiguiente el trabajo hecho en un depto.INSTITUTO TECNOLÓGICO DE JIQUILPAN Apuntes de Fundamentos de Desarrollo de Sistemas Ingeniería en Sistemas Computacionales Plan 2004 nueva información para la toma de decisiones. si el proceso de recepción de pedidos no captura la dirección de los clientes para el cobro o el lugar donde deben enviar los productos entonces ¿cómo enviar los artículos o las facturas por correo a su lugar de destino? Entonces es importante estar al tanto de otros requerimientos de la organización. 1. No es un ensamblador de computadores. Elaborados por: Lic.

El diseño lógico se convierte en parte en la especificación funcional que se usa en el diseño físico. EL TRABAJO DEL ANALISTA DE SISTEMAS El analista de Sistemas evalúa de manera sistemática el funcionamiento de un negocio mediante el examen de la entrada y el procesamiento de datos y su consiguiente producción de información. Un servicio es una unidad con capacidad de cómputo. experto en soporte técnico y agente de cambio. Un servicio debe satisfacer lo siguiente:    Ser seguro. organiza y detalla la solución de negocios y define formalmente las reglas y políticas específicas de negocios. Muchas mejoras incluyen un mayor apoyo a las funciones de negocios a través del uso de Sistemas de información computarizados. cuándo. encuestas y/o visitas a los usuarios. informando al cliente Lic. con el propósito de mejorar los procesos de una organización. 30 Elaborados por: . Martin Valencia Pág. de tal manera que se obtenga quién. Diseño Lógico El diseño lógico traduce los escenarios de uso creados en el diseño conceptual en un conjunto de objetos de negocio y sus servicios. qué tareas o reglas se pueden aplicar Manejar excepciones.INSTITUTO TECNOLÓGICO DE JIQUILPAN Apuntes de Fundamentos de Desarrollo de Sistemas Ingeniería en Sistemas Computacionales Plan 2004 No es especialista en electrónica. realizar entrevistas. El analista debe tener la capacidad de trabajar con todo tipo de gente y contar con suficiente experiencia en computadoras. lo que equivale a un uso correcto y con autorización Ser válido. El analista desempeña diversos roles. dónde y por qué de la solución. qué. en ocasiones varios de ellos al mismo tiempo. El diseño lógico es independiente de la tecnología. El diseño lógico es la solución del equipo de proyecto del negocio y consiste de las siguientes tareas:       Identificar los usuarios y sus roles Obtener datos de los usuarios Evaluar la información Documentar los escenarios de uso Validar con los usuarios Validar contra la arquitectura de la empresa Una forma de obtener estos requerimientos es construir una matriz usuarios-actividades de negocios. Un objeto de negocios es la encapsulación de un servicio que abstrae las cualidades esenciales de algo de interés. Los tres roles principales del analista de Sistemas son el de consultor. Diseño Conceptual El diseño conceptual se considera como un análisis de actividades y consiste en la solución de negocios para el usuario y se expresa con los casos de uso. El diseño lógico refina.

Martin Valencia Pág. Las tareas de verificación incluyen:   Una verificación independiente: o Pre y post condiciones o Lógica y funcionalidad individual Una verificación dependiente: o Verificación de dependencias o Que operan como una unidad específica de trabajo El diseño lógico comprende las siguientes tareas:       Identificar y definir los objetos de negocio y sus servicios Definir las interfaces Identificar las dependencias entre objetos Validar contra los escenarios de uso Comparar con la arquitectura de la empresa Revisar y refinar tanto como sea necesario Para definir los objetos de negocios y sus servicios se puede usar la técnica de análisis nombre-verbo de los escenarios de uso. estado final Capacidad o funcionalidad (SQL. En estas técnicas los sujetos y el objeto directo son los candidatos a objetos de negocio y los verbos activos son los candidatos a servicios. 31 . pseudocódigo. Una interface tiene las siguientes partes:      Nombre Precondiciones.INSTITUTO TECNOLÓGICO DE JIQUILPAN Apuntes de Fundamentos de Desarrollo de Sistemas Ingeniería en Sistemas Computacionales Plan 2004  Contar con un catálogo de servicios que constituye un repositorio de servicios. Para ello se debe considerar lo siguiente:         Identificar los eventos disparadores (triggers) Determinar cualquier dependencia (existencial o funcional) Determinar cualquier problema de consistencia o secuencia Identificar cualquier regulación de tiempo crítica Considerar algún problema organizacional (transacciones) Identificar y auditar los requerimientos de control Determinar lugares y dependencias a través de la ubicación Determinar cuando el servicio que controla la transacción es dependiente de los servicios contenidos en otros objetos de negocio La validación del modelo lógico debe ser tal que éste sea: Elaborados por: Lic. función matemática) Dependencias La tarea de identificar las dependencias entre objetos permite identificar eventos. Los objetos de negocio deben verificarse y probarse de tal manera que asegure que los módulos operen como unidades completas de trabajo. sucesos o condiciones que permitan la realización de tareas de negocios coordinadamente o transaccionalmente. También se puede emplear la técnica sujeto-verbo-objeto directo. lo que debe estar presente antes de ejecutarse Postcondiciones.

Establecer una conexión involucra: una identificación. permisos a usuario y grupos y servicios) Administración de la conexión (mecanismos básicos para establecer una sesión de los servicios de datos). operaciones.INSTITUTO TECNOLÓGICO DE JIQUILPAN Apuntes de Fundamentos de Desarrollo de Sistemas Ingeniería en Sistemas Computacionales Plan 2004    Completo – debe representar todos los escenarios de uso. la colocación y provisión de datos. triggers y gateways para verificar el estado de los datos antes de aceptarlos. Bloqueo (permite al acceso concurrente a los datos) Validación de datos (verifica la integridad del dominio. Distribución de datos (Distribuye información. multiusuario. El objetivo central es minimizar el esfuerzo de conocimiento requerido para interpretar la información. a múltiples unidades de recuperación. Las tareas de los servicios de negocio son:     Dar formato a los datos Obtener y mover datos desde y hasta los servicios de datos Transformar los datos en información Validar los datos inmediatamente en el contexto o en forma diferida una vez terminada la transacción. 32 . tiempo de sesión. monousuario). formación de un conjunto de resultados) Inserción. según la topologías de la red). el tipo de interacción (conversacional. Una transacción es atómica (ocurre o no). Generalmente involucra una interfase gráfica de usuario (GUI) o pude ser no visual (mensajes o funciones). Los servicios de usuario (user services) controlan la interacción. ésta sobrevive). APIs) Respaldo y recuperación (recuperación de datos si un evento falla) Búsqueda y Lectura (búsquedas. aislada (otras transacciones ocurren antes o después) y durable (una vez completada. Un servicio de usuario son personas. manejo de errores) Seguridad (acceso seguro a los objetos. compilación. bases de datos heterogéneas. maneja todos los aspectos de la interacción con la aplicación. Martin Valencia Pág. Un servicio de usuario incluye un contenido (qué se necesita comunicar al usuario) y una forma (cómo se comunica el contenido) cuando es necesaria la comunicación. otros servicios o la combinación de éstos. acceso indexado. SQL. aplicaciones. Los servicios de negocio (bussines services) convierten datos recibidos de los servicios de datos y de usuario en información (datos + regla de negocio) y pueden usar otros servicios de negocio para completar su tarea. Correcto – el comportamiento lógico debe corresponder con el comportamiento conceptual. Elaborados por: Lic. servicios de negocio y servicios de datos. consistente (preserva integridad). tipos. transaccional. Los servicios de datos (data services) son los servicios de bajo nivel que apoyan los servicios de negocio y son de una amplia gama de categorías como las siguientes:          Declaración del esquema y su evolución (estructuras de datos. optimización y ejecución de solicitudes. y Claro – los objetos de negocio y servicios no deben ser ambiguos En el diseño lógico conceptualmente se divide en tres niveles de servicios con el fin de que la aplicación resulte flexible ante los cambios de requerimientos y/o de tecnología cambiando únicamente la capa o capas necesarias. Los tres niveles son: servicios de usuario. actualización y borrado (procesar modificaciones consistentemente transaccional).

Martin Valencia Pág.INSTITUTO TECNOLÓGICO DE JIQUILPAN Apuntes de Fundamentos de Desarrollo de Sistemas Ingeniería en Sistemas Computacionales Plan 2004 Diseño físico El diseño físico traduce el diseño lógico en una solución implementable y costo-efectiva o económica. Las características de un componente son:      Se define según cómo interactúa con otros Encapsula sus funciones y sus datos Es reusable a través de las aplicaciones Puede verse como una caja negra Puede contener otros componentes En el diseño físico se debe cuidar el nivel de granularidad (un componente puede ser tan grande o tan pequeño según su funcionalidad. Elaborados por: Lic. o Debugging – crear una versión para limpiar errores.a la entrada antes de continuar con cualquier proceso. El componente es la unidad de construcción elemental del diseño físico. El diseño para multitarea – debe diseñarse en términos de la administración concurrente de dos o más tareas distintas por una computadora y el multithreading o múltiples hilos de un mismo proceso) El diseño para uso concurrente – el desempeño de un componente remoto depende de si está corriendo mientras recibe una solicitud. 33 . sin duplicar código). o Protegiendo recursos críticos –manejar excepciones para evitar la falla o terminación sin cerrar archivos. o Protegiendo datos importantes – contar con una excepción a la mitad de la actuación en las bases de datos. del tamaño tal que pueda proveer de una funcionalidad compleja pero de control genérico) y la agregación y contención (un componente puede reusar utilizando técnicas de agregación y contención. El diseño físico debe involucrar:     El diseño para distribución – debe minimizarse la cantidad de datos que pasan como parámetros entre los componentes y éstos deben enviarse de manera segura por la red. o Protección integral de transacciones de negocios – los errores deben regresarse al componente que llama. liberar objetos sincronizados o memoria. El diseño con el manejo de errores y prueba de eventos: o Validando los parámetros. es decir.

Los datos centralizados equivalen a una base de datos maestra ubicada en un lugar central. En una partición horizontal cada hilera existe en una sola base de datos. Martin Valencia Pág. No hay sobreposición entre particiones. No se permite la actualización. Es útil cuando los datos se pueden fragmentar fácilmente y actualizarse en un sitio local con cambios frecuentes. Una partición de datos es una segmentación de la base de datos maestra. una partición. No hay copias de los datos. Se usa un timestamp o etiqueta de tiempo para indicar qué tan viejos son los datos. un extracto o una réplica. Arquitectura física de tres capas de la aplicación cliente/servidor El diseño físico comprende las siguientes tareas:        Definir los componentes Refinar el empaquetamiento y distribución de componentes Especificar las interfaces de los componentes Distribuir los componentes en la red Distribuir los repositorios físicos de datos Examinar la tolerancia a fallas y la recuperación de errores Validar el diseño físico De las tareas anteriores la más importante es la distribución de los datos que pueden ser centralizados. Un extracto de datos es una copia de toda o una porción de la base de datos maestra. Una réplica de datos es un fragmento de la bases de datos maestra que se puede actualizar. No se permiten actualizaciones en la base Elaborados por: Lic. En una partición vertical cada columna es contenida en una y solo una base de datos. 34 .INSTITUTO TECNOLÓGICO DE JIQUILPAN Apuntes de Fundamentos de Desarrollo de Sistemas Ingeniería en Sistemas Computacionales Plan 2004 Figura 2. Una réplica de datos es cuando el sitio de actualización cambia a un sitio local.

Desarrollo del Software: Los encargados de desarrollar Software pueden instalar Software comprobando a terceros o escribir programas diseñados a la medida del solicitante. Por lo general. La evaluación de un Sistema se lleva a cabo para identificar puntos débiles y fuertes. del tiempo disponible para escribir el Software y de la disponibilidad de los programadores. incluyendo su facilidad de uso. Sin embargo. es decir. Una vez instaladas. por lo que debe de haber sincronización entre ambas. los programadores que trabajan en las grandes organizaciones pertenecen a un grupo permanente de profesionales. Martin Valencia Pág. los programadores que trabajan en las grandes organizaciones pertenecen a un grupo permanente de profesionales. La elección depende del costo de cada alternativa. las organizaciones y los usuarios cambian con el paso del tiempo.INSTITUTO TECNOLÓGICO DE JIQUILPAN Apuntes de Fundamentos de Desarrollo de Sistemas Ingeniería en Sistemas Computacionales Plan 2004 de datos réplica y en la base de datos maestra a la vez. El diseño físico está íntimamente ligado a una alternativa tecnológica. incluso el ambiente es diferente con el paso de las semanas y los meses.2. tiempo de respuesta. Se alimentan como entradas conjunto de datos de prueba para su procesamiento y después se examinan los resultados. La tendencia actual en la arquitectura cliente/servidor es crear el back-end como un servidor robusto multitareas y multithreading y el front-end como un cliente muy delgado que no acapare al servidor comunicándose entre sí en una plataforma internet con protocolos estándar en redes heterogéneas. las aplicaciones se emplean durante muchos años. Lic. Por lo general. el Sistema se emplea de manera experimental para asegurarse de que el Software no tenga fallas. Implantación y evaluación La implantación es el proceso de verificar e instalar nuevo equipo. lo adecuado de los formatos de información. 1. del tiempo disponible para escribir el Software y de la disponibilidad de los programadores. entrenar a los usuarios. confiabilidad global y nivel de utilización.4 Programación. La elección depende del costo de cada alternativa. 1.5 Prueba e Implantación Durante la prueba de Sistemas. 35 Elaborados por: . Por consiguiente. Ante la acelerada evolución tecnológica es importante considerar los estándares del momento y las tendencias ya que una mala decisión implicará un costo enorme (en dinero y en tiempo) al actualizarse a otra plataforma distinta. La evaluación ocurre a lo largo de cualquiera de las siguientes dimensiones:  Evaluación operacional: Valoración de la forma en que funciona el Sistema. es indudable que debe darse mantenimiento a las aplicaciones. instalar la aplicación y construir todos los archivos de datos necesarios para utilizarla. Los encargados de desarrollar Software pueden instalar Software comprobando a terceros o escribir programas diseñados a la medida del solicitante. que funciona de acuerdo con las especificaciones y en la forma en que los usuarios esperan que lo haga.2.

INSTITUTO TECNOLÓGICO DE JIQUILPAN Apuntes de Fundamentos de Desarrollo de Sistemas Ingeniería en Sistemas Computacionales Plan 2004    Impacto organizacional: Identificación y medición de los beneficios para la organización en áreas tales como finanzas. que ofrece métodos o técnicas para desarrollar y mantener Software de calidad que resuelven problemas de todo tipo. eficiencia operacional e impacto competitivo. También se incluye el impacto sobre el flujo de información externo e interno. UNIDAD II INTRODUCCION A LA INGENIERIA DEL SOFTWARE 2. Opinión de loa administradores: evaluación de las actividades de directivos y administradores dentro de la organización así como de los usuarios finales. Sistemas operativos o desarrollos de Internet. La Ingeniería del Software trata de áreas muy diversas de la informática y de las ciencias computacionales. tales como constantes de compiladores. 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. y otros criterios de administración de proyectos. Martin Valencia Pág. concuerdan con presupuestos y estándares.1 Definición de Ingeniería de Software Es una disciplina o área de la información o ciencias de la computación. 36 . internacional con derechos. Desempeño del desarrollo: La evaluación de proceso de desarrollo de acuerdo con criterios tales como tiempo y esfuerzo de desarrollo. Elaborados por: Lic. También se incluye la valoración de los métodos y herramientas utilizados en el desarrollo. laboral.

cada año surgen nuevas ideas e iniciativas encaminadas a ello. Entre las que se encuentran la programación estructurada. 37 Lic. la aplicación de la ingeniería al Software. sino en parte porque no es razonable estar en crisis más de veinte años. CORBA. de Software que satisfaga las necesidades de los usuarios”… Fuente Wikipedia. La crisis del Software pasó. han ido apareciendo herramientas.. no tanto por la mejora en la gestión de los proyectos. 2. Alemania. El término ingeniería del Software empezó a usarse a finales de la década de los sesenta. disciplinado y cuantificable al desarrollo. puede definirse según Alan Davis como “la aplicación inteligente de principios probados. asociado a la inmadurez del propio sector informático (totalmente ligado al electrónico) y a la falta de métodos y recursos. 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. operación y mantenimiento de Software. Martin Valencia . equipos para medicina.2 Historia de la Ingeniería del Software La Ingeniería del Software. metodologías y tecnologías que se presentaban como la solución definitiva al problema de la planificación. algunos de ellos eran tan críticos (Sistemas de control de aeropuertos. previsión de costes y aseguramiento de la calidad en el desarrollo de Software. la industria del Software sería tan predecible como lo son otras ramas de la ingeniería. la documentación. dentro de un coste razonable. Evolución del Software Primeros años 50´s a los 60´s: Elaborados por: • Orientación por lotes Pág. el crecimiento espectacular de la demanda de Sistemas de computación cada vez más y más complejos. lenguajes y herramientas para la creación y mantenimiento. y en parte porque se estaban haciendo progresos en los procesos de diseño y metodologías. también se han hecho esfuerzos por incorporar los métodos formales al desarrollo de Software. técnicas. En esa época. Así pues. es decir. el lenguaje de programación ADA. Durante esa época muchos proyectos importantes superaban con creces los presupuestos y fechas estimados. la programación orientada a objetos. Y lo que es más. la llamada “bala de plata” (por silver bullet). para expresar el área de conocimiento que se estaba desarrollando en torno a las problemáticas que ofrecía el Software en ese momento. a los aspectos. en octubre de 1968.INSTITUTO TECNOLÓGICO DE JIQUILPAN Apuntes de Fundamentos de Desarrollo de Sistemas Ingeniería en Sistemas Computacionales Plan 2004 “La ingeniería de Software es el establecimiento y uso 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 IEEE la define como la aplicación de un enfoque sistemático. En combinación con las herramientas. argumentando que si se probaba formalmente que los desarrollos hacían lo que se les requería. las herramientas CASE. los estándares. 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. desde 1985 hasta el presente. provocó lo que se llamó la crisis del Software (en palabras de Edsger Dijkstra) entre los años 1965 y 1985. entre otros) que sus implicaciones iban más allá de las pérdidas millonarias que causaban.

Martin Valencia Pág. A pesar de que la industria tiene una tendencia hacia la construcción por componentes. pero si se deteriora. la mayoría del Software aún se construye a la medida. En ambas la alta calidad se alcanza por medio del buen diseño. 2.INSTITUTO TECNOLÓGICO DE JIQUILPAN Apuntes de Fundamentos de Desarrollo de Sistemas Ingeniería en Sistemas Computacionales Plan 2004 • Distribución limitada • Software “a medida” •Segunda era 70´s: • Multiusuario • Tiempo real • Bases de datos • Software como producto • Sistemas distribuidos • Incorporación de “inteligencia” • Hardware bajo coste • Impacto en el consumo Cuarta era 90´s al 2000 • Potentes Sistemas de sobremesa • Tecnologías orientadas a objetos • Sistemas expertos • Redes neuronales • Computación paralela 2. El Software no se desgasta. Elaborados por: Lic. las dos actividades serian diferentes en lo fundamental. 38 Tercera era 80´s . Un componente de Software se debe diseñar e implementar de forma que puede utilizarse en muchos programas diferentes. no se manufactura en el sentido clásico. Los defectos sin descubrir causan tasas de fallas altas en las primeras etapas de vida de un programa. A pesar de que existen similitudes entre el desarrollo del Software y la manufactura del Hardware. Por lo tanto la curva de tasas de fallas para el Software debería tener la forma de la “curva idealizada”. El Software es inmune a los males ambientales que desgasten el Hardware. El Software se desarrolla o construye.3 Características del Software 1. la fase de manufactura del Hardware puede incluir problemas de calidad existentes en el Software. los errores se corrigen y la curva se aplana: el Software no se desgasta. 3. Sin embargo.

2.. Desde que surge la necesidad.Funcionabilidad.Utilidad.. 3. Disponibilidad y Rendimiento. Una metodología es una manera ordenada y sistemática de proceder para obtener algún fin. 6. Se llevara a cabo a través de una serie de normas o reglas precisas. El conjunto de normas incluye además un Sistema de documentación donde se irá reflejando el trabajo realizado. Martin Valencia Pág. Curvas del Sw Paradigma Los Sistemas informáticos (Software) desde su concepción hasta su desaparición pasan por una serie de etapas o fases.. Elaborados por: Lic.. 4.Oportunidad e Innovación. constituyendo el cuerpo formal de la metodología. lo que permite al ingeniero de Software crear nuevas aplicaciones nuevas a partir de partes reutilizables y que cumplan con estos atributos. pasa por una serie de etapas que constituyen su ciclo de vida.. pasando por su propia construcción. cuyo cumplimiento será más o menos estricto. siendo el aspecto más visible del método.INSTITUTO TECNOLÓGICO DE JIQUILPAN Apuntes de Fundamentos de Desarrollo de Sistemas Ingeniería en Sistemas Computacionales Plan 2004 Los componentes reutilizables modernos encapsulan tanto los datos como el proceso se aplican a estos.Usabilidad y Reusabilidad. Figura 3. puesta en marcha y continúas revisiones hasta su abandono.. 5.Seguridad. 39 . 1.Confiabilidad. Las actividades para la construcción de un Sistema se realizan de acuerdo a un método.

se pueden rastrear hasta los primeros días de la computación. En el CDV clásico era muy importante partir de unos requerimientos claros. merisse. Junto con esta metodología aparecen nuevos conceptos como la modularización y el diseño descendente. Cada fase se compone de actividades más detalladas. marcando la dirección del proyecto y proporcionando una guía sobre lo que se debería obtener como resultado del mismo. Es una metodología que ofrece mayores puntos de control para el proyecto. Existen varias metodologías: clásica. 40 . lo que facilita el mantenimiento (modificación y adaptación del Sistema). Elaborados por: Lic. completos y bien definidos. etc. 2. Cuando las necesidades del usuario simples. Los Sistemas de información se desarrollan en una serie de pasos: esta secuencia se conoce como el ciclo de vida. El CDVE es un ciclo lineal o en cascada. El CDV estructurado surge así como una superación del CDVC en entornos grandes y complejos. oo. prototipos. pero este método es bastante más que esto. Es más flexible. diseño estructurado y programación estructurada. Los mitos tienen ciertos atributos que los convierten en insidiosos. determinar y definir requerimientos puede ser relativamente fácil. El ciclo de vida se define como una secuencia de fases.4 Mitos del Software: Los mitos del Software-creencias acerca del Software y de los procesos empleados para construirlo. o difíciles de definir. pero cuando las necesidades del usuario crecen. o son complejas. cada una de las cuales tienen un objetivo específico. En la actualidad se conocen como análisis estructurado. dirigir y realizar las actividades del ciclo de vida de un Sistema de información. Esta revisión produce un informe como resultado y define el objetivo y un plan detallado para la siguiente fase. entre otras ventajas. En los años 70 esta situación hizo que el ciclo de vida clásico entrara en crisis. Martin Valencia Pág. Cada fase se revisa cuando se completa. Gane & Sarson. B) El ciclo de vida ayuda a los analistas a resolver problemas que surjan durante el desarrollo del Sistema. el analista estaba seguro de conocer perfectamente lo que el usuario quería que haga el Sistema. Yourdon. que provee técnicas y herramientas adecuadas para cada fase del proyecto. Se utiliza por varias razones: A) Para organizar el gran número de actividades necesarias en la construcción de un Sistema y especificar la secuencia en que se deben tratar esas actividades para su desarrollo. si además la aplicación debe servir a varios usuarios con necesidades e intereses diferentes y a veces opuestos. Metodología Estructurada Principales exponentes: De Marco.INSTITUTO TECNOLÓGICO DE JIQUILPAN Apuntes de Fundamentos de Desarrollo de Sistemas Ingeniería en Sistemas Computacionales Plan 2004 • Una metodología es un enfoque para organizar. permitiendo un seguimiento de las necesidades de recursos. C) El ciclo de vida ayuda también a producir informes del estado del proyecto. el análisis de los requerimientos se complica y se convierte en el principal problema en el desarrollo de un Sistema de información.

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. construcción de programas. pruebas y mantenimiento. nuestro trabajo ha terminado. Martin Valencia Pág. 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 abarcan una gran gama de tareas que incluyen análisis de requisitos. quede insatisfecho con el desarrollador del Software. hacer que no se retrase el proyecto y mejorar la calidad. como los gestores en la mayoría de las disciplinas. diseño. se puede añadir más programadores y adelantar el tiempo perdido. la programación se veía como un arte. En muchos casos. Los mitos conducen a que el cliente se cree una falsa expectativa y.5 Capas de la Ingeniería del Software La ingeniería de Software es una tecnología multicapa. 2. cualquier enfoque de ingeniería debe apoyarse sobre un compromiso de organización de calidad. debido a que los gestores y desarrolladores de Software hacen muy poco para corregir la mala información. Mitos de los desarrolladores. el cliente cree en los mitos que existen sobre el Software. ya que el Software es flexible. Las viejas formas y actitudes tardan en morir. El fundamento de la ingeniería de Software es la capa del proceso. Mito: Si se falla en la planificación. finalmente. Los mitos en los que aún creen muchos desarrolladores se han ido fomentando durante 50 años de cultura informática. Las herramientas de la ingeniería de Software proporcionan un enfoque automático o semiautomático para el proceso y para los métodos. Mito: Si los requisitos del proyecto cambian continuamente. 41 . Durante los primeros días del desarrollo del Software. Mito: Una vez que escribimos el programa y hacemos que funcione. están normalmente bajo la presión de cumplir las propuestas.INSTITUTO TECNOLÓGICO DE JIQUILPAN Apuntes de Fundamentos de Desarrollo de Sistemas Ingeniería en Sistemas Computacionales Plan 2004 Mitos de la administración. Elaborados por: Lic. Un gestor de Software se agarra frecuentemente a un mito del Software. Los gestores con responsabilidad sobre el Software. los cambios pueden acomodarse fácilmente. Mitos del cliente.

.INSTITUTO TECNOLÓGICO DE JIQUILPAN Apuntes de Fundamentos de Desarrollo de Sistemas Ingeniería en Sistemas Computacionales Plan 2004 Enfoque en capas • Herramientas. Un enfoque de Calidad. Procesos: El fundamento de la ingeniería de Software es la capa proceso.indican cómo construir técnicamente el Software Procesos. las cuales forman la base del control de gestión de proyectos de Software y establecen el contexto en el cual: se aplican los métodos técnicos.. Los métodos abarcan una gran gama de tareas que incluyen análisis de requisitos. se producen resultados de trabajo. se establecen hitos. pruebas y mantenimiento. Capas de la Ingeniería de Software. • • • Métodos.. 42 . Martin Valencia Pág. Estos métodos dependen de un conjunto de principios básicos que gobiernan cada área de la tecnología e incluyen actividades de modelado y otras técnicas descriptivas. El proceso define un marco de trabajo para un conjunto de áreas clave.proporcionan un soporte automático o semi automático a los procesos y a los métodos. Herramientas: Las herramientas de la ingeniería del Software proporcionan un soporte automático o semi-automático para el proceso y los métodos. Métodos: Los métodos de la ingeniería de Software indican cómo construir técnicamente el Software.son la base o cimientos de la ingeniería de Software. construcción de programas. a estas herramientas se les llama herramientas CASE (Computer-Aided Software Engineering). Elaborados por: Lic. diseño.-son el fundamento de la ingeniería de Software. se asegura la calidad y el cambio se gestiona adecuadamente.

        Software de Sistema. salud. Educación. Martin Valencia Pág. Software de Negocios.Aunque un proyecto de desarrollo de Software es equiparable en muchos aspectos a cualquier otro proyecto de ingeniería. Juegos. relativos esencialmente a la naturaleza del producto obtenido. 2. Software de IA. Software de PC. en el desarrollo de Software hay una serie de desafíos adicionales. Cualquier disciplina de ingeniería (incluida la ingeniería del Software) debe descansar sobre un esfuerzo de organización de calidad.INSTITUTO TECNOLÓGICO DE JIQUILPAN Apuntes de Fundamentos de Desarrollo de Sistemas Ingeniería en Sistemas Computacionales Plan 2004 Un enfoque de calidad: Son la base o cimientos de la ingeniería de Software. Vida Social. 43 . y se encuentra dividida en las siguientes aplicaciones. Un proceso de desarrollo de Software tiene como propósito la producción eficaz y eficiente de un producto Software que reúna los requisitos del cliente. afectado por la creatividad y juicio de las personas involucradas . Software Incrustrado.. Telecomunicaciones. Este proceso es intensamente intelectual.6 El Proceso del Software Qué es el Software? Es un conjunto de elementos u objetos Que conforman una configuración e Incluye:    Programas Documentos Datos Se puede decir que hoy en día se encuentra en casi todas las diferentes áreas de trabajo y ocio como son la Ingeniería. Dicho proceso. Aplicaciones Web. Software de Ingeniería/Científico. Etc. Perspectiva histórica del desarrollo de Software  Década 50-60: Elaborados por: Lic. A continuación se explican algunas particularidades asociadas al desarrollo de Software y que influyen en su proceso de construcción. La gestión total de la calidad y las filosofías similares fomentan una cultura continua de mejoras de procesos que conduce al desarrollo de enfoques cada vez más robustos para la ingeniería del Software en si esta capa está referida a la seriedad con la que los programadores trabajan en el desarrollo de Software de calidad ya que estos a su vez son criticados por los usuarios y esto puede llevar a mejorar o disminuir el prestigio del programador. Software de Tiempo Real.

e-business. . Primeros métodos estructurados. Ingeniería del Software. Tecnología CASE Componentes y reutilización Interoperabilidad (CORBA. Martin Valencia Pág.) Internet .ISW. usar todo o nada (poco ensamblaje de componentes: reutilización).7 Software de Alta Calidad Las inspecciones de Software surgen a partir de la necesidad de producir Software de alta calidad. 2. 44 Elaborados por: ..      El Software es un elemento del Sistema que es lógico. Algunos grupos de desarrollo creen que la calidad del Software es algo en lo que deben preocuparse una vez que se ha generado el código.  Década 80-90: Nuevos paradigmas de programación y de producción de programas: OO C/S  90’s – en la actualidad: Análisis/Diseño OO. Desarrollo artesanal. e-commerce Estas son algunas consideraciones que se deben tener en cuenta al momento de elegir o diseñar algún Software. “Crisis del Software”. en lugar de físico. El Software no se «estropea».NET.INSTITUTO TECNOLÓGICO DE JIQUILPAN Apuntes de Fundamentos de Desarrollo de Sistemas Ingeniería en Sistemas Computacionales Plan 2004 “Software como un añadido”. El Software se desarrolla no se fábrica en un sentido clásico. La mayoría del Software se construye a medida. Lenguajes de bajo nivel.  Década 70-80: Programación estructurada.  Década 60-70: Software como producto..Repositorios de componentes reutilizables . Década lenguajes y compilación. ¡Error ¡ La garantía de la calidad del Software es una actividad de protección que se aplica a lo largo de todo el proceso de ingeniería de Software. Distribuida . ¡Pero se deteriora!. La SQA (Software Quality Assurance) engloba:   Un enfoque de gestión de calidad Tecnología de Ingeniería de Software efectiva (métodos y herramientas) Lic. a medida.

El aseguramiento de calidad del Software se diseña para cada aplicación antes de comenzar a desarrollarla y no después. las personas desarrolladoras deben tener en cuenta claramente que son otras personas las que utilizarán sus productos.Productos Software son realizados por personas para personas. Los requisitos del Software son la base de las medidas de calidad. Martin Valencia Pág. – Existen algunos requisitos implícitos o expectativas que a menudo no se mencionan. El control de la calidad es una serie de revisiones. o se mencionan de forma incompleta (por ejemplo el deseo de un buen mantenimiento) que también pueden implicar una falta de calidad. El aseguramiento de calidad del Software es el conjunto de actividades planificadas y sistemáticas necesarias para aportar la confianza en que el producto (Software) satisfará los requisitos dados de calidad. 45 . Todas las metodologías y herramientas tienen un único fin producir Software de gran calidad Definiciones de calidad del Software. Así. – “Concordancia con los requisitos funcionales y de rendimiento explícitamente establecidos con los estándares de desarrollo explícitamente documentados y con las características implícitas que se espera de todo Software desarrollado profesionalmente” R. Pressman (1992). y pruebas utilizados a los largo del ciclo de desarrollo para asegurar que cada producto cumple con los requisitos que le han sido asignados. – “El conjunto de características de una entidad que le confieren su aptitud para satisfacer las necesidades expresadas y las implícitas” ISO 8402 (UNE 66-001-92). los que pueden estar sujetos a fallos constantes. Elaborados por: Lic. La principal meta de un equipo desarrollador de Software debería ser siempre producir Software catalogado como de alta calidad. Si no se sigue ninguna metodología siempre habrá falta de calidad. Pero para ello se deben tener en cuenta algunas ideas previas: . – Los estándares o metodologías definen un conjunto de criterios de desarrollo que guían la forma en que se aplica la ingeniería del Software. El desarrollo de productos Software es una actividad sujeta a muchos factores que la pueden hacer poco confiable. S. los asistentes Software para el desarrollo de Software no son demasiado confiables como para que la mano humana no intervenga en este proceso. Aún a pesar de los avances actuales en Inteligencia Artificial. La falta de concordancia con los requisitos es una falta de calidad.INSTITUTO TECNOLÓGICO DE JIQUILPAN Apuntes de Fundamentos de Desarrollo de Sistemas Ingeniería en Sistemas Computacionales Plan 2004        Revisiones técnicas formales que se aplican durante el proceso del Software Una estrategia de prueba multiescalada Un control de la documentación del Software y de los cambios realizados Un procedimiento que asegure un ajuste a los estándares de desarrollo de Software Mecanismos de medición y de generación de informes.

El aseguramiento de calidad del Software está presente en: – Métodos y herramientas de análisis. programación y prueba. Nivel 1: Realizado. El área del proceso (por ejemplo.de calidad del Software – Métricas de Software para el control del proyecto – Verificación y validación del Software a lo largo del ciclo de vida • Incluye las pruebas y los procesos de revisión e inspección – La gestión de la configuración del Software 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. Todas las metas específicas de área del proceso (como las definió la IMCM) han sido satisfechas. Además. Las tareas de trabajo requeridas para producir el producto específico han sido realizadas. todo el trabajo asociado con el área de proceso se ajusta a una política organizacional definida. Martin Valencia Pág. 46 . – Inspecciones técnicas formales en todos los pasos del proceso de desarrollo del Software. puede confundir con garantía de productos. – Estrategias de prueba multiescala. Actividades para el aseguramiento. Nivel 0: Incompleto. con el fin de alcanzar la calidaden el desarrollo de cualquier proyecto de Software. Nivel 2: Administrado. 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. diseño. los clientes están implicados de manera Elaborados por: Lic. – Control de la documentación del Software y de los cambios realizados – Procedimientos para ajustarse a los estándares (y dejar claro cuando se está fuera de ellos) – Mecanismos de medida (métricas) – Registro de auditorías y realización de informes. Todos los criterios del nivel 1 han sido satisfechos. – Aseguramiento pretende dar confianza en que el producto tiene calidad. Modelo de Capacidad de Madurez (IMCM). – Garantía. toda la gente que ejecuta el trabajo tiene acceso a recurso adecuados para realizar su labor.INSTITUTO TECNOLÓGICO DE JIQUILPAN Apuntes de Fundamentos de Desarrollo de Sistemas Ingeniería en Sistemas Computacionales Plan 2004 Algunos autores prefieren decir garantía de calidad en vez de aseguramiento.

Si se una un navegador Web o se vive cerca de una planta nuclear controlada por computadora. perceptibles sólo por profesionales de la informática que tienen acceso al código fuente. modulares. mediciones y otras mejorías del proceso para los activos del proceso organizacional”. 47 . o como tal. Otras cualidades aplicables a un producto de Software. es decir. Todos los criterios del nivel 4 han sido satisfechos. 2. el área del proceso se controla y mejora mediante mediciones y evaluación cuantitativa. 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”. fáciles de usar. actualmente estudiar cualquier Ingeniería basada en los Sistemas Informáticos. estructurados y así sucesivamente. todas las tareas de trabajo y productos están “monitoreadas. Elaborados por: Lic. legibles. Además. importa poco que el Software sea legible o modular si los gráficos tardan años en cargarse o si la introducción de datos erróneos hace explotar la planta. de acuerdo con las políticas de adaptación de esta misma. Incluso el primer paso hacia la corrección es ya difícil: debemos ser capaces de especificar los requisitos del Sistema de una forma precisa. si tiene una bonita interfaz de usuario. Todos los criterios del nivel 2 se han cumplido. siempre es preocupante el incrementar la calidad del Software. fiables. Pero esto es más fácil de decir que de lograr. se consideran cualidades tales como la velocidad o la facilidad de uso. controlados y revisados. si es rápido. Estas propiedades pueden ser denominadas factores de calidad externos. cuando esto se requiere. En última instancia. Además. y contribuye a la información de los productos del trabajo.INSTITUTO TECNOLÓGICO DE JIQUILPAN Apuntes de Fundamentos de Desarrollo de Sistemas Ingeniería en Sistemas Computacionales Plan 2004 activa en el área de proceso. buscando la calidad. Si un Sistema no hace lo que se supone que debe hacer. lo que es en sí una ardua tarea. La clave para obtener los factores externos radica en los internos: para que los usuarios disfruten de las cualidades visibles. la ingeniería del Software es la producción de Software de calidad. como Ingeniero. el proceso está “adaptado al conjunto de procesos de estándar de la organización. Todos los criterios del nivel 3 han sido cumplidos. Por una parte. cuya presencia o ausencia en un producto de Software puede ser detectada por sus usuarios. Todos deseamos que nuestros Sistemas de Software sean rápidos. “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”. sólo importan los factores externos. La corrección es la cualidad principal. poco importan el resto de consideraciones que hagamos sobre él. Pero estos adjetivos describen dos tipos de cualidades diferentes. Nivel 5: Mejorado. Martin Valencia Pág. Nivel 4: Administrativo en forma cuantitativa. y son evaluados en apego a la descripción del proceso” Nivel 3: Definido. los diseñadores y los implementadores deben aplicar técnicas internas que aseguren las cualidades ocultas como se sugieren a continuación: Corrección. etc.8 Factores de Calidad y productividad Como bien sabrán ustedes. como la Modularidad o legibilidad son factores internos. Además.

como con la corrección. El papel del requisito de robustez es asegurar que si tal caso surgiese el Sistema no causará eventos catastróficos. de las técnicas de implementación. nada es más fácil de cambiar que un programa si se tiene acceso a su código fuente. de la representación de los datos. en lugar de provocar una reacción en cadena de cambios en el Sistema completo. su relevancia sólo se ve con claridad en los grandes proyectos. es necesaria una solución multinivel. no es posible decir. La robustez es por naturaleza una noción más difusa que la corrección. más alta es la probabilidad de que un cambio afecte a un solo módulo. implica a tantas áreas que sería imposible garantizar su corrección manejando todas las componentes y propiedades en un solo nivel. de los algoritmos. La corrección tiene que ver con el comportamiento de un Sistema en los casos previstos por su especificación. Ofrecer soporte para los cambios es un objetivo básico de la tecnología de objetos. o a un número pequeño de módulos. En cambio. debería producir mensajes de error apropiados. Hay dos principios esenciales para mejorar la extensibilidad: Simplicidad del diseño: una arquitectura simple siempre será más fácil de adaptar a los cambios que una compleja. Extensibilidad El Software se supone que es Software (blando). pero a medida que el Software crece comienza a ser cada vez más difícil de adaptar. sólo hay que preocuparse en garantizar que cada nivel sea correcto bajo el supuesto de que los niveles inferiores son correctos. y realmente lo es en un principio. el caso excepcional formaría parte de la especificación y regresaríamos al terreno de la corrección. la robustez caracteriza lo que sucede fuera de tal especificación. Puesto que tiene que ver aquí con casos no previstos por la especificación. El problema de extensibilidad es un problema de escala. de nuestra comprensión de los requisitos. donde las tareas son conocidas. terminar su ejecución limpiamente en lo posible. Descentralización: cuanto más autónomos sean los módulos. Elaborados por: Lic. Siempre habrá casos que la especificación no contemple explícitamente. que el Sistema debería “realizar sus tareas” en tal caso. en la que cada nivel confía en la corrección de los inferiores: Hardware ----> Sistema Operativo----> Compilador ----> Sistema de Aplicación En la solución condicional de la corrección.INSTITUTO TECNOLÓGICO DE JIQUILPAN Apuntes de Fundamentos de Desarrollo de Sistemas Ingeniería en Sistemas Computacionales Plan 2004 Los métodos que aseguran la corrección son usualmente condicionales. Para programas pequeños realizar cambios no es normalmente una tarea difícil. La extensibilidad es necesaria porque en la base de todo Software encontramos algún fenómeno humano y de ahí su volatilidad. Martin Valencia Pág. Robustez La robustez complementa la corrección. incluso uno pequeño según los estándares de hoy. El cambio es omnipresente en el desarrollo del Software: cambios en los requisitos. Aunque muchas de las técnicas que mejoran la extensibilidad se pueden aplicar con pequeños ejemplos. 48 . Un Sistema de Software importante.

como en el Sistema Unix. Martin Valencia Pág. Es más. Eficiencia Casi sinónimo de eficiencia es la palabra “rendimiento”. Pero con mucha frecuencia los Sistemas tienen dificultades para interactuar porque hacen suposiciones contradictorias sobre el resto del mundo. etc. la potencia creciente del Hardware de las computadoras nos permite tener una actitud más relajada con respecto a tratar de ganar hasta el último byte o microsegundo. Compatibilidad La compatibilidad es importante debido a que los Sistemas Software no se desarrollan en el vacío: necesitan interactuar con otros. Por otro lado. Los enfoques incluyen:    Formatos de archivos estándares. basado en componentes estándares tales como ventanas. como se evidencia en las frases de la industria “hágalo correcto antes de hacerlo rápido” y “de todos modos los modelos de computadoras del año que viene van a ser un 50% más rápidos”. la preocupación por la eficiencia debe sopesarse con otros objetivos tales como la extensibilidad y la reutilización. Un ejemplo es la amplia variedad de formatos de archivos soportados por muchos Sistemas operativos. Capturando tal patrón. menús. donde tanto los datos como los programas. se representan mediante árboles binarios. donde cualquier archivo de texto es simplemente una secuencia de caracteres. Interfaces de usuario estándares. De manera más general. La comunidad del Software muestra dos tipos de actitud con relación a la eficiencia: Algunos desarrolladores tienen una obsesión con las cuestiones de rendimiento y le dedican gran cantidad de esfuerzos a presuntas optimizaciones. optimizaciones extremas pueden hacer al Software tan especializado que limite el cambio y la reutilización. Elaborados por: Lic. Estructuras de datos estándares como en los Sistemas Lisp. ya que al resolver el problema de la reutilización se tendrá que escribir menos Software y en consecuencia se podrán dedicar entonces mayores esfuerzos a mejorar los otros factores. un elemento de Software reutilizable se podrá aplicar en muchos desarrollos diferentes. tales como la corrección y la robustez.INSTITUTO TECNOLÓGICO DE JIQUILPAN Apuntes de Fundamentos de Desarrollo de Sistemas Ingeniería en Sistemas Computacionales Plan 2004 Reutilización La necesidad de la reutilización surge de la observación de que los Sistemas de Software a menudo siguen patrones similares. Un programa puede usar directamente como entrada los resultados de otro sólo si los formatos de archivos son compatibles. La clave de la compatibilidad recae en la homogeneidad del diseño y en acordar convenciones estándares para la comunicación entre programas. La reutilización tiene una influencia sobre todos los demás aspectos de la Calidad del Software. debería ser posible explotar esta similitud y evitar reinventar soluciones a problemas que ya han sido encontradas con anterioridad. existe la tendencia de soslayar las cuestiones de eficiencia. como en las diferentes versiones de Windows donde todas las herramientas utilizan un solo paradigma para la comunicación con el usuario. 49 . íconos.

Los usuarios se quejan con razón de que toda la parafernalia que acompaña a una nueva versión de un producto lo hace tremendamente complejo. se debe esperar que los usuarios sean miembros de la raza humana y que sepan leer. se puede dar por supuesto que los usuarios están familiarizados con sus conceptos básicos. Lo que a unos les puede resultar algo superfluo puede ser una facilidad indispensable para otros. no mucho más. Si el Software está dirigido a un área especializada de aplicación. Pero incluso esto es arriesgado. y son peores para los productos comerciales. éstas deberían explicarse como consecuencia de los conceptos básicos. 50 . Este requisito plantea uno de los mayores retos de los diseñadores de Software preocupados por la facilidad de uso: cómo proporcionar explicaciones y guías detalladas a los usuarios novatos sin fastidiar a los usuarios expertos que quieren ir directo al grano. Hacen las menos suposiciones posibles sobre los usuarios. mover un ratón. construido de acuerdo a una estructura clara y bien pensada. Cuando se diseña un Sistema interactivo. Un buen producto Software está basado en un número pequeño de potentes ideas. La solución aquí es trabajar una y otra vez sobre la consistencia del producto global. está constantemente presente. lo que puede afectar a su facilidad de uso. donde las presiones vienen de los usuarios de la misma compañía. incluso si tiene muchas propiedades especializadas. Facilidad de uso La definición insiste en los diferentes niveles de experiencia de los posibles usuarios. y convierte a la portabilidad en un asunto primordial tanto para los que desarrollan como para los que usan el Software. Sus consecuencias son malas para los proyectos internos. El “gran plan” debe estar visible y todo debería ocupar su sitio dentro de él. Elaborados por: Lic. Martin Valencia Pág. presionar un botón y teclear (lentamente). el Sistema de ventanas y otras herramientas fundamentales. ya que la parte más destacada de los análisis comparativos suele ser una tabla donde se enumeran una por una las propiedades que ofrecen los distintos productos analizados. Funcionalidad Uno de los problemas más difíciles a los que se enfrenta un jefe de proyecto es conocer cuanta funcionalidad es suficiente. El problema más fácil es la pérdida de consistencia como consecuencia de estar añadiendo nuevas propiedades. El featurism. Una de las claves de la facilidad de uso es la simplicidad estructural. tratando de que todo encaje en un molde general. La presión para ofrecer más facilidades (conocida como featurism). Los buenos diseñadores de interfaces siguen una política prudente. Muchas de las incompatibilidades existentes entre las plataformas son injustificadas. Un Sistema bien diseñado. uno más difícil que el otro. Tales comentarios no deberían preocuparnos en exceso. la que realmente programamos y que incluye el Sistema operativo. puesto que las nuevas propiedades no surgen de la nada: la mayor parte de las veces han sido solicitadas por los usuarios finales.INSTITUTO TECNOLÓGICO DE JIQUILPAN Apuntes de Fundamentos de Desarrollo de Sistemas Ingeniería en Sistemas Computacionales Plan 2004 Portabilidad (transportabilidad) La portabilidad tiene que ver con las variaciones no sólo del Hardware físico sino más generalmente de la máquina Hardware-Software. es realmente la combinación de dos problemas. tiende a ser más fácil de aprender y usar que uno confuso.

51 .INSTITUTO TECNOLÓGICO DE JIQUILPAN Apuntes de Fundamentos de Desarrollo de Sistemas Ingeniería en Sistemas Computacionales Plan 2004 Oportunidad La oportunidad es una de las mayores frustraciones de nuestra industria. Integridad: es la capacidad de los Sistemas Software de proteger sus diversos componentes (programas. es la capacidad que un Sistema tiene de completarse con el presupuesto asignado o por debajo del mismo. existen otras que afectan a los usuarios de Sistemas Software y a la gente que compra estos Sistemas o encarga su desarrollo. Un gran producto Software que aparece demasiado tarde puede no alcanzar su objetivo. Martin Valencia Pág. pero pocas evolucionan tan rápidamente como el Software. En particular: Verificabilidad: es la facilidad para preparar procedimientos de aceptación. para grandes proyectos. Pero éste no es un factor de calidad separado. datos. La oportunidad es todavía. la necesidad de documentación es una consecuencia de otros factores de calidad vistos anteriormente. es preferible producir Software lo más autodocumentado posible. Economía: junto con la oportunidad. uno podría esperar encontrar la presencia de una buena documentación como uno de los requisitos. saldría al mercado un mes antes de lo previsto. Esto se aplica a los tres tipos de documentación: Elaborados por: Lic. que llevaba realizando varios años. ya que una documentación de la interfaz de un módulo permite determinar cuándo cierto cambio afecta a un determinado módulo. que permite a los usuarios conocer la potencia de un Sistema y usarlo convenientemente. es una consecuencia del requisito de extensibilidad. En lugar de tratar la documentación como un producto propio del Software. También se desprende de la extensibilidad. Otras cualidades: Además de las cualidades analizadas. es una consecuencia de la definición de facilidad de uso. que permite a los desarrolladores de Software comprender las funciones proporcionadas por un módulo sin tener que comprender su implementación. especialmente datos de prueba y procedimientos para detectar fallos y localizar errores durante las fases de validación y operación. el suceso fue lo suficientemente relevante como para encabezar los titulares de Computer World. etc.) contra modificaciones y accesos no autorizados. Cuando Microsoft anunció que la última versión de su principal Sistema operativo. Esto es cierto en otras industrias también. Reparabilidad: es la capacidad para facilitar la reparación de los defectos. que permite a los desarrolladores de Software comprender la estructura e implementación de un Sistema. La necesidad de documentación interna. La necesidad de documentación de la interfaz de un módulo. Sobre la documentación: En una lista de factores de Calidad del Software. Se pueden distinguir tres tipos de documentación: La necesidad de documentación externa. un fenómeno poco común. es una consecuencia del requisito de reutilización.

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. prueba y mantenimiento. los controles de calidad y guías para evaluación del progreso. Procedimientos que definen la secuencia en la que se aplican los métodos. Elaborados por: Lic. Será posible entonces utilizar herramientas para producir automáticamente documentación de la interfaz del módulo a partir del texto de los módulos. 52 .INSTITUTO TECNOLÓGICO DE JIQUILPAN Apuntes de Fundamentos de Desarrollo de Sistemas Ingeniería en Sistemas Computacionales Plan 2004 Incluyendo facilidades de “ayuda” en línea y siguiendo normas para interfaces claras y consistentes. se establece un Sistema para el soporte del desarrollo de Software. Martin Valencia Pág. codificación. Herramientas automáticas y semiautomáticas que apoyan a la aplicación de los métodos. se alivia la tarea de los autores de los manuales de usuario y de otras formas de documentación externa. el diseño. herramientas y procedimientos mencionados. UNIDAD III PARADIGMAS DE LA INGENIERIA DE SOFTWARE Introducción: a los Paradigmas de la Ingeniería del Software La ingeniería de Software surge de la ingeniería de Sistemas y de Hardware. las entregas. Un buen lenguaje de implementación puede eliminar muchas de las necesidades de documentación interna si favorece la claridad y la estructura. llamado Ingeniería de Software Asistida por Computadora ( CASE ). el análisis. La Ingeniería de Software está compuesta por una serie de pasos que abarcan los métodos. La notación soportará la ocultación de información y otras técnicas para separar la interfaz de los módulos de su implementación. Cuando se integran las herramientas de forma que la información creada por una herramienta puede ser usada por otra. a los que se denominan Paradigmas de la Ingeniería de Software. la estimación.

los métodos. Los procesos se etiquetan con un número y un verbo en infinitivo con objeto directo. No hay un límite para el número de procesos. Un diagrama de flujo de datos puede ser profundizado expandiendo algunos de sus procesos en subprocesos. las herramientas y los procedimientos antes mencionados. flechas. Sus elementos gráficos son círculos.1 Diagramas de Flujo 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. Hay de diferentes niveles dependiendo la complejidad del Sistema que analiza. Un mínimo cambio en el código puede llegar alterar al resto del programa cosa que en uno OO bien encarado eso no sucede lo cual es una ventaja porque así no se pierde tiempo en arreglar cosas ya hechas. Otra desventaja es que una porción de código en lenguaje estructurado es difícil que pueda servir en otros proyectos. 3. Los cerrados representan entidades externas mientras que los abiertos describen almacenes o archivos. La ingeniería de Software está compuesta por una serie de pasos de abarcan los métodos. 3. Estos pasos se denominan frecuentemente paradigmas de la ingeniería de Software. En un DFD también se utiliza la escritura. entidades externas y los almacenes se etiquetan con un nombre.INSTITUTO TECNOLÓGICO DE JIQUILPAN Apuntes de Fundamentos de Desarrollo de Sistemas Ingeniería en Sistemas Computacionales Plan 2004 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. 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. flujo de datos (argumentos) y archivos (base de datos). 53 . Hablando de lenguajes Tiene muchas diferencias con la OO. o hacia. con solo importar clases ya hechas se escribe menos código y se ahorra tiempo. esto sí es habitual en lenguajes OO. en este caso la etiqueta tendrá un número adicional. un proceso. 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 las Elaborados por: Lic. Los flujos. y rectángulos cerrados o abiertos. DFD es un diagrama en el q participan procesos (métodos). Martin Valencia Pág. los controles y entregas requeridos. Los círculos significan procesos y las flechas flujos de datos desde. 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.1.1 En el Enfoque Estructurado Se usan los DFD (Diagrama de Flujo de Datos) como principal herramienta para entender al Sistema antes de plasmarlo a código fuente. herramientas a usar.

descripción. y cómo el Sistema se pondrá en práctica. alias. su contenido también se emplea durante el diseño del proyecto. detalles de las relaciones entre almacenes. 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. Nivel 1: Diagrama de nivel superior. Los diagramas de flujo de datos fueron inventados por Larry Constantine. Este contexto a nivel de DFD se “explotó” para mostrar más detalles del Sistema que se está modelando.1. incluyendo nombre. El objetivo de un diccionario de datos es dar precisión sobre los datos que se manejan en un Sistema. 54 . La manera en que cualquier Sistema es desarrollado puede determinarse a través de un diagrama de flujo de datos. Define con precisión los datos de entrada.INSTITUTO TECNOLÓGICO DE JIQUILPAN Apuntes de Fundamentos de Desarrollo de Sistemas Ingeniería en Sistemas Computacionales Plan 2004 entidades externas. El desarrollo de un DFD ayuda en la identificación de los datos de la transacción en el modelo de datos. contenido y organización. 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 desarrollador original del diseño estructurado. lo que el Sistema va a lograr. los cuales son: Nivel 0: Diagrama de contexto. y cómo tienen un efecto sobre la estructura de todo el Sistema. salida. los usuarios van a poder visualizar la forma en que el Sistema funcione. Nivel 2: Diagrama de detalle o expansión. Con un diagrama de flujo de datos. 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. componentes de almacenes. etc. Elaborados por: Lic. 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.2 Diccionario de datos El diccionario de datos es un listado organizado de todos los datos que pertenecen a un Sistema. Los diagramas derivados de los procesos principales se clasifican en niveles. basado en el modelo de computación de Martin y Estrin: “flujo gráfico de datos”. Los diccionarios de datos son buenos complementos a los diagramas de flujo de datos. flujos. Martin Valencia Pág. los diagramas de entidad-relación. evitando así malas interpretaciones o ambigüedades. 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. 3. etc.

4. superior e inferior para la cantidad de repeticiones. 3. almacenes de datos y procesos. 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 Elaborados por: Lic. 2. El grupo repetido puede tener condiciones. 5. Puede haber uno o varios elementos repetidos dentro del grupo. Los paréntesis ( ) representan un elemento opcional.INSTITUTO TECNOLÓGICO DE JIQUILPAN Apuntes de Fundamentos de Desarrollo de Sistemas Ingeniería en Sistemas Computacionales Plan 2004 Identifica los procesos donde se emplean los datos y los sitios donde se necesita el acceso inmediato a la información. y pueden contener espacios o ceros para los campos numéricos en las estructuras de archivo. NOTACIÓN Las estructuras de datos son descritas por lo general usando notación algebraica. Las llaves { } indican elementos repetidos. 6. también llamados grupos repetidos o tablas. La notación algebraica usa los siguientes símbolos: 1. tales como una cantidad fija de repeticiones o límites. 7. Un signo de más (+) significa “y”. pero no ambos. su contenido también se emplea durante el diseño. Los elementos opcionales pueden ser dejados en blanco en las pantallas de captura. Una frase entre asteriscos es un comentario (* *). Los elementos más importantes son flujos de datos. 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 corchetes [ ] representan una situación disyuntiva. Un signo de igual (=) significa “está compuesto de”. y se separan mediante barras ( | ). Puede estar presente un elemento u otro. 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. El diccionario de datos guarda los detalles y descripción de todos estos elementos. La “@” (o una definición subrayada) identifica la llave para un almacén de datos. 55 . Martin Valencia Pág. Los elementos listados entre corchetes son mutuamente excluyentes.

Ejemplo: Peso = * peso del paciente al ingresar al hospital * • Unidad: kilo. si se trata de un dato elemental que ya no puede ser descompuesto. 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. apellido-materno y apellido-paterno. 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.3 Diseño de Módulos. 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.1. 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} 3. Esto se documenta en forma de comentario. esto depende del contexto del Sistema que se esté modelando. deben ser introducidos en el DD y proveer una breve descripción que describa el significado del dato. • Los valores que el dato puede tomar. Para definir un dato completamente. Cuando se han identificado los datos elementales. sin embargo. o “significa”. o “está compuesto de”. rango:2–150 * Altura = * unidad: cm. Ejemplo: Ordende compra = nombre-cliente + dirección-de-envío + {artículo} significa que una orden de compra siempre debe contener un nombre de cliente. En el caso de que el dato tenga un nombre significativo. se puede omitir la descripción. • La composición del dato. en este contexto el “=” se lee como “está definido por”.INSTITUTO TECNOLÓGICO DE JIQUILPAN Apuntes de Fundamentos de Desarrollo de Sistemas Ingeniería en Sistemas Computacionales Plan 2004 Una definición de un dato se introduce mediante el símbolo “=”. DATOS ELEMENTALES Son aquellos para los cuales no hay una descomposición significativa. Martin Valencia Pág. 56 . Ejemplo: Se pueden especificar límites superiores e inferiores a las iteraciones. una dirección de envío y de 1 a 10 artículos. la definición debe incluir: • El significado del dato en el contexto de la aplicación. Por ejemplo. una dirección de envío y cero o más ocurrencias de un artículo. si es que está compuesto de otros elementos significativos. es importante especificar las unidades de medida que el dato puede tomar. 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. Elaborados por: Lic. puede ser que no se requiera descomponer el nombre de una persona en primer-nombre.

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. 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í. Usualmente están implementados en algún Manejador de Base de Datos. 57 . desarrollan múltiples actividades el componente básico de estas corresponde a la tarea. El ejemplo más típico es el Modelo Relacional. entendida como una microactividad que se responsabiliza a una sola persona. funcionales.4 Descomposición En Procesos. • Operaciones de manipulación de los datos: típicamente. Un (DFD) presenta ser subdividido en diferentes partes. operaciones de agregado.INSTITUTO TECNOLÓGICO DE JIQUILPAN Apuntes de Fundamentos de Desarrollo de Sistemas Ingeniería en Sistemas Computacionales Plan 2004 Un modelo de datos es un lenguaje orientado a describir una Base de Datos. a fin de que el Sistema pueda ser desarrollado y ejecutado en unidades menores. Modelos de Datos Físicos Son estructuras de datos a bajo nivel implementadas dentro del propio manejador. Estos módulos pueden ser un programa. El ejemplo más típico es el Modelo EntidadRelación. borrado. por lo que los dos enfoques propuestos son necesarios en cualquier desarrollo de Software. Ejemplos típicos de estas estructuras son los Árboles B+. las estructuras de Hash. más fáciles de implementar manejar y controlar. 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. 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. Martin Valencia Pág. que cuenta con la particularidad de contar también con buenas características conceptuales (Normalización de bases de datos). Las organizaciones. una relación de operaciones o comandos 3. No hay que perder de vista que una Base de Datos siempre está orientada a resolver un problema determinado. modificación y recuperación de los datos de la base. un procedimiento. • Las restricciones de integridad: Un conjunto de condiciones que deben cumplir los datos para reflejar correctamente la realidad deseada. Elaborados por: Lic. que llamaremos módulos conteniendo cada uno de ellos procedimientos manuales o automatizados.1. Modelos de Datos Lógicos Son orientados a las operaciones más que a la descripción de una realidad. etc.

Pueden ser clasificados. Durante los años 90. El análisis orientado a objetos y su diseño se enfoca en los objetos. tecnológicos materiales. Sin embargo. Martin Valencia Pág.) para el desarrollo de las actividades que lo conforman. Las tecnologías de objetos llevan a reutilizar. 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. 3. etc. Un enfoque orientado a objetos para programar ofrece muchos beneficios sobre un enfoque estructurado. Las implementaciones orientadas a objetos ocultan datos. descritos. 58 . y la reutilización (de componente de Software) lleva a un desarrollo de Software más rápido y a programas de mejor calidad. Elaborados por: Lic. Hacia mediados de los 80. Los objetos tienen ciertos comportamientos y atributos que determinan la manera en que interactúan y funcionan. manipulados y creados. como salidas se esperan productos.2 Enfoque Orientado a Objetos. Entiende todo proceso como un : “CONJUNTO DE TAREAS LOGICAMENTE RELACIONADAS QUE EXISTEN PARA OBTENER UN RESULTADO BIEN DEFINIDO DENTRO DE UN NEGOCIO”. 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. Todos los procesos tienen entradas (recursos humanos. organizados. en los negocios y en los productos que usamos. lo cual significa que muestran únicamente los comportamientos a los usuarios y ocultan el código subyacente de un objeto. Esto lleva a menores efectos colaterales cuando se deben hacer cambios. una abstracción que modela el mundo de forma tal que nos ayuda a entenderlo y gobernarlo mejor. Por eso no es sorprendente que se proponga una visión orientada a objetos para la creación de Software de computadora. servicios. Historia: Vivimos en un mundo de objetos. Los comportamientos que el programador expone son únicamente aquellos elementos que el usuario de un objeto puede afectar.INSTITUTO TECNOLÓGICO DE JIQUILPAN Apuntes de Fundamentos de Desarrollo de Sistemas Ingeniería en Sistemas Computacionales Plan 2004 Grupos de tareas conforman actividades más complejas que se denominan procesos. en entidades hechas por el hombre. etc. 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. Estos objetos existen en la naturaleza. activos financieros. información. combinados. los beneficios de la programación orientada a objetos empezaron a obtener reconocimiento. La programación orientada a objetos ayuda a los desarrolladores a crear objetos que reflejan escenarios del mundo real. El Software orientado a objetos es más fácil de mantener debido a que su estructura es inherentemente poco acoplada. las tecnologías de objetos han necesitado casi veinte años para llegar a ser ampliamente usadas. 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). La primera vez que se propuso un enfoque orientado a objetos para el desarrollo de Software fue a finales de los años sesenta.

Al utilizar un enfoque orientado a objetos. Se necesita un nuevo enfoque para construir Software en la actualidad. además de dinero. números de partes y elementos en un inventario. Orientados a lógica: Expresado en cálculo de predicados. Orientación a Objetos La orientación a objetos puede describirse como el conjunto de disciplinas que desarrollan y modelan Software. 59 .). Ellos programan en un paradigma forzado por el lenguaje que utilizan. Eiffel. La orientación a objetos fuerza a reconsiderar nuestro pensamiento sobre la computación. la programación orientada a objetos es un nuevo paradigma. y por consiguiente tienen dificultad en ver la ventaja de elegir un estilo más apropiado al problema a manejar”. No existe ningún estilo de programación idóneo para todas las clases de programación. Bobrow y Stefik sugieren que existen cuatro clases de estilos de programación:     Orientados a procedimientos: Algoritmos. Orientados a objetos: Clases y Objetos. En este sentido. La orientación a objetos se acopla a la simulación de situaciones del mundo real. Smalltalk. En el libro The Structure of Scientific Revolutions. 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. estándar y métodos que juntos representan un medio de organización del conocimiento: es decir. Los objetos existen por sí mismos. Con frecuencia. los desarrolladores pueden crear aplicaciones que reflejan objetos del mundo real. Esto quiere decir que son entidades completas y. 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. elipses y triángulos. sobre lo que significa realizar computación y sobre cómo se estructura la información dentro de la computadora. b. etc. Martin Valencia Pág. 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. C++. como rectángulos. el historiador Thomas K describía un paradigma como un conjunto de teorías. son modulares en su construcción. que facilitan la construcción de Sistemas complejos a partir de componentes. tienden a ser altamente reutilizables. 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 95. 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. con una funcionalidad para invocar comportamientos de otros objetos. por lo tanto. Jenkins y Glasgow observan que “la mayoría de los programadores trabajan en un lenguaje y utilizan sólo un estilo de programación. un medio de visualizar el mundo. como el Sistema operativo Microsoft® Windows®. por definición. a. Orientados a reglas: Reglas if-then. En un enfoque orientado a objetos. Este nuevo enfoque debe ser capaz de manipular tanto Elaborados por: Lic. los objetos. no se enfrentan a métodos alternativos de resolución de un problema.INSTITUTO TECNOLÓGICO DE JIQUILPAN Apuntes de Fundamentos de Desarrollo de Sistemas Ingeniería en Sistemas Computacionales Plan 2004 El enfoque orientado a objetos permite que los objetos estén autocontenidos.

la figura es el objeto. Todos los objetos están compuestos de tres cosas: Interfaz: La Interfaz es el conjunto de métodos. Después puede crear una nueva instancia de la clase cliente para tener un objeto utilizable de Cliente. La clase es la definición de un elemento. se les conoce como variables de la instancia o como atributos. El estado se describe a través de las variables del Miembro o de la Instancia. eventos y atributos que se declaran como públicos en su alcance y que pueden invocar los programas escritos para usar nuestro objeto. El soporte fundamental es el modelo objeto. su lista de parámetro y el tipo de datos de devolución. Observe que las propiedades no son variables del Miembro. Estado: El estado o los datos de un objeto es lo que lo hace diferente de otros objetos de la misma clase. Para poder crear un objeto de la clase cliente. Las variables del miembro son aquellas declaradas. ya que este código es el que efectivamente logra que el objeto haga un trabajo útil. podremos cambiar la implementación totalmente. puede crear una clase que defina a un cliente. Implementación: Al código dentro de los métodos se le llama Implementación. Estas tareas se realizan mediante la modelización del mundo real. es como una clase. Un objeto es la instancia de una clase. Es importante entender que las aplicaciones del cliente pueden utilizar nuestro objeto aunque cambiemos la implementación. las variables del miembro son Privadas en su alcance. entonces un objeto es lo que se crea a partir del molde. de tal manera que están disponibles para todo el código dentro de la clase. ya que son un tipo de método que funciona para recuperar y establecer valores.INSTITUTO TECNOLÓGICO DE JIQUILPAN Apuntes de Fundamentos de Desarrollo de Sistemas Ingeniería en Sistemas Computacionales Plan 2004 Sistemas grandes como pequeños y debe crear Sistemas fiables que sean flexibles. Por lo general. Elaborados por: Lic. Si una clase es como un molde. el objeto es el elemento. Como ejemplo. y proporciona la base a partir de la cual creamos instancias de objetos específicos. debe crear una nueva instancia basada en esa clase. propiedades. Martin Valencia Pág. El molde para una figura de cerámica en particular. siempre que no cambiemos la interfaz. Siempre que se mantengan sin cambio nuestro nombre de método. 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. Una clase es la representación abstracta de un concepto en el mundo real. 60 . Algunas veces. La orientación a objetos trata de cubrir las necesidades de los usuarios finales. así como las propias de los desarrolladores de productos Software. mantenibles y capaces de evolucionar para cumplir las necesidades del cambio. Algunas veces también se le llama comportamiento.

Persona. si desea construir objetos que representen perros. puede definir una clase Perro con ciertos comportamientos. Una clase define las características de un objeto.INSTITUTO TECNOLÓGICO DE JIQUILPAN Apuntes de Fundamentos de Desarrollo de Sistemas Ingeniería en Sistemas Computacionales Plan 2004 ¿Qué es una clase? Una clase es esencialmente un proyecto. Deberán ser creados. a partir del cual puede crear objetos. y propiedades específicas. peso y color. A pesar de que la clase Persona se define en el ejemplo. Estas características determinan la manera en que otros objetos pueden acceder y trabajar con los datos que se incluyen en el objeto. como caminar. El siguiente ejemplo representa la definición de la clase Perro. Martin Valencia Pág. Es importante observar que todos los objetos Perro creados con base en la clase perro compartirán los mismos comportamientos. se coloca la palabra clave Class antes del nombre de su clase. Para definir una clase. incluyendo las propiedades que definen los tipos de datos que ese objeto puede contener y los métodos que describen el comportamiento del objeto. Si incluye los métodos. no existe aún el objeto Persona. 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. Por ejemplo. El siguiente ejemplo define una nueva clase. con dos partes de información relevante asociadas: el nombre de la persona. Tome en consideración que ésta no es una sintaxis estricta de VB.NET. Una vez que haya definido la clase Perro. ladrar y comer. su fecha de nacimiento y un Método que calcula la edad de la persona. 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. 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. pero tendrán sus propios valores específicos para el mismo conjunto de propiedades. 61 . [@ Public Class Persona Private mstrNombre As String Private mdtFechaNacimiento As Date Elaborados por: Lic. como altura. simplemente es un ejemplo de la definición de clase. puede crear objetos con base en esa clase.

utilizar esta descripción en un programa. 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. Estas son:      Abstracción. 62 . pero el uso de clases para gestionar dichas abstracciones en lenguajes de programación ha facilitado considerablemente su aplicación. El elemento clave de la programación orientada a objetos es la clase. Now()) End Function End Class Una clase es un tipo definido por el usuario en contraposición a un tipo proporcionado por el Sistema. Encontrar buenas abstracciones generalmente requiere de un entendimiento muy claro del problema y de su contexto. Crear buenas abstracciones de Software no es fácil. La abstracción es la propiedad que permite representar las características esenciales de un objeto. Abstracción: La abstracción es uno de los medios más importantes. Una buena abstracción elimina todos los detalles poco importantes y le permite enfocarse y concentrarse en los detalles importantes. Una clase se puede definir como una descripción abstracta de un grupo de objetos. Como sugiere Booch. poner o quitar la tapa. mdtFechaNacimiento. Polimorfismo. Definir una abstracción significa describir una entidad del mundo real. Una abstracción se centra en la vista externa de un objeto. mediante el cual nos enfrentamos con la complejidad inherente al Software. Al definir una clase. La idea de escribir programas definiendo una serie de abstracciones no es nueva. a continuación. 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. sin preocuparse de las restantes características (no esenciales).Year. Encapsulamiento. cada uno de los cuales se diferencia por su estado específico y por la posibilidad de realizar una serie de operaciones. de modo que sirva para separar el comportamiento esencial de un objeto de su implementación. si alguno de estos elementos no existe se dice que el modelo no es orientado a objetos. Ahora que ya sabéis todo esto. Elaborados por: Lic. 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. gran claridad de pensamiento y amplia experiencia.). en realidad crea un nuevo tipo en su aplicación. Jerarquía.INSTITUTO TECNOLÓGICO DE JIQUILPAN Apuntes de Fundamentos de Desarrollo de Sistemas Ingeniería en Sistemas Computacionales Plan 2004 Public Function Edad() As Integer Return DateDiff(DateInterval. Modularidad. vamos con os elementos (propiedades) más importantes de este modelo. etc. Por ejemplo. llenar de tinta si está vacía. La abstracción es un principio de Software importante. no importa lo compleja que pueda ser y. Martin Valencia Pág.

INSTITUTO TECNOLÓGICO DE JIQUILPAN Apuntes de Fundamentos de Desarrollo de Sistemas Ingeniería en Sistemas Computacionales Plan 2004

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. 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
Elaborados por: Lic. Martin Valencia Pág. 63

INSTITUTO TECNOLÓGICO DE JIQUILPAN Apuntes de Fundamentos de Desarrollo de Sistemas Ingeniería en Sistemas Computacionales Plan 2004

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.

Elaborados por:

Lic. Martin Valencia

Pág. 64

INSTITUTO TECNOLÓGICO DE JIQUILPAN Apuntes de Fundamentos de Desarrollo de Sistemas Ingeniería en Sistemas Computacionales Plan 2004

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. 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. 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 ¿Cuáles son los beneficios? , Buena pregunta eh …!!!
Elaborados por: Lic. Martin Valencia Pág. 65

INSTITUTO TECNOLÓGICO DE JIQUILPAN Apuntes de Fundamentos de Desarrollo de Sistemas Ingeniería en Sistemas Computacionales Plan 2004

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

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

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:       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. Persistencia: los objetos deben poder ser persistentes; es decir, los objetos han de poder permanecer después de la ejecución del programa 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. 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.

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:    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. 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. 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.

Conceptos de orientación a objetos:
Elaborados por: Lic. Martin Valencia Pág. 66

azul. Una característica puede verse como una relación binaria entre una clase y cierto dominio. 67 . gris. supongamos que una clase Coche tiene un atributo color. Estos algoritmos son llamados operaciones. Atributos: Los atributos están asociados a clases y objetos. un dominio es simplemente un conjunto de valores específicos. 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 Elaborados por: Lic. Las características (valores del dominio) pueden aumentarse asignando un valor por defecto (característica) a un atributo. peso. Nota: Los valores asignados a los atributos de un objeto hacen a ese objeto ser único. 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. Cada uno de los métodos encapsulados por un objeto proporciona una representación de uno de los comportamientos del objeto. Nota: Un objeto encapsula datos (atributos) y los métodos (operaciones. el método Determinar Color?. para el objeto Coche extraerá el color almacenado en el atributo color. métodos o servicios) capaces de manipular los datos de alguna manera. Martin Valencia Pág. La mayoría de los objetos físicos tienen características tales como forma. Por ejemplo. plata. y describen la clase o el objeto de alguna manera. métodos o servicios y pueden ser vistos como módulos en un sentido convencional. el atributo color tiene el valor por defecto negro. rojo. Por ejemplo. nombre y color de los ojos. verde. Las personas tienen características como fecha de nacimiento. métodos y servicios: Un objeto encapsula datos (representados como una colección de atributos) y los algoritmos que procesan estos datos. negro. Por lo tanto. El dominio de valores de color es blanco. En la mayoría de los casos. padres. La “relación” binaria implica que un atributo puede tomar un valor definido por un dominio enumerado. color y tipo de material. métodos o servicios) que manipulan esos datos. Las abstracciones de datos (atributos) que describen la clase están encerradas por una “muralla” de abstracciones procedimentales (llamadas operaciones. 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.INSTITUTO TECNOLÓGICO DE JIQUILPAN Apuntes de Fundamentos de Desarrollo de Sistemas Ingeniería en Sistemas Computacionales Plan 2004 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 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. Esto posibilita la ocultación de información y reduce el impacto de efectos colaterales asociados a cambios. Operaciones. Las entidades de la vida real están a menudo descritas con palabras que indican características estables. la clase encapsula datos (dentro de la muralla) y el proceso que manipula los datos (los métodos que componen la muralla). Por ejemplo. amarillo.

Elaborados por: Lic. Los desarrolladores usan el modelo de análisis. Una operación dentro de un objeto emisor genera un mensaje de la forma: destino. Las actividades del análisis: la identificación de objetos. El comportamiento se realiza cuando se ejecuta un método.2. Conceptos de análisis: Particularmente describimos: Objetos de entidad. Nota: Siempre que un objeto es estimulado por un mensaje. sus relaciones. Los mensajes proporcionan una visión interna del comportamiento de objetos individuales.1 Análisis 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. representado por gráficas de estado y diagramas de secuencia. frontera y control: Los objetos de entidad representan la información persistente rastreada por el Sistema. Un mensaje estimula la ocurrencia de cierto comportamiento en el objeto receptor. éste inicia un cierto comportamiento. 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. Martin Valencia Pág. El modelo de análisis está compuesto por tres modelos individuales: el modelo funcional. inicia algún comportamiento ejecutando un método. Los objetos de frontera representan la interacción entre los actores y el Sistema. y del Sistema Orientado a Objetos como un todo. 68 . representado por diagramas de clase y objeto. Nota: El paso de mensajes mantiene comunicado un Sistema orientado a objetos. su comportamiento. y el modelo dinámico. 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. Los objetos de control representan las tareas realizadas por el usuario y soportadas por el Sistema. junto con los requerimientos no funcionales. Cada vez que un objeto recibe un estímulo.INSTITUTO TECNOLÓGICO DE JIQUILPAN Apuntes de Fundamentos de Desarrollo de Sistemas Ingeniería en Sistemas Computacionales Plan 2004 de una clase. 3. para preparar la arquitectura del Sistema que se desarrolla durante el diseño de alto nivel.operación (parámetros) Donde destino define al objeto receptor el cual es estimulado por el mensaje. su clasificación y su organización. Mensajes: Los mensajes son el medio a través del cual interactúan los objetos. el modelo de objetos de análisis. representado por casos de uso y escenarios.

El análisis para el enfoque orientado a objetos. Con frecuencia. En lugar de considerar el SW desde una perspectiva básica de entrada-proceso-salida como los métodos estructurados se basa en modelar el Sistema mediante los objetos que forman parte de él y las relaciones estáticas (herencia y composición ) o dinámicas(uso entre otros objetos ). n o 1. las interfaces y los componentes la implementación transforma el diseño en código y la pruebas checan tanto la arquitectura como la interfaz y los componentes. Persona y Automóvil) indica composición Una asociación de muchos a muchos tiene una multiplicidad de 0.2 Diseño Durante el diseño de objetos cerramos el hueco entre los objetos de aplicación y los componentes hechos. los objetos del lado de “muchos” pueden distinguirse entre ellos usando un nombre. 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. Sin embargo. un extremo de una asociación puede tener como multiplicidad un conjunto de enteros arbitrarios. identificando objetos de solución adicionales y refinando los objetos existentes. En UML. Martin Valencia Pág. El diseño de objetos incluye: Elaborados por: Lic. en el caso de una asociación de uno a muchos. Las asociaciones que tienen multiplicidad de 0…1 o 1 son más fáciles de comprender que las asociaciones con multiplicidad de 0…n o 1…n.INSTITUTO TECNOLÓGICO DE JIQUILPAN Apuntes de Fundamentos de Desarrollo de Sistemas Ingeniería en Sistemas Computacionales Plan 2004 Multiplicidad de asociación: el extremo de una asociación puede etiquetarse como un conjunto de enteros llamados multiplicidad. 3. en la práctica. . n en ambos extremos. el diseño proporciona detalles sobre la arquitectura. 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. Asociaciones calificadas: La calificación es una técnica para la reducción de la multiplicidad usando claves. 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. 69 . 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.2. El análisis identifica las clases y objetos relativamente en el dominio del problema. Generalización: La generalización nos permite organizar conceptos en jerarquías. . Este es el tipo más complejo de asociación.

El diseño de objetos a veces es difícil distinguir claramente el análisis y el diseño Orientado a Objetos (OO).INSTITUTO TECNOLÓGICO DE JIQUILPAN Apuntes de Fundamentos de Desarrollo de Sistemas Ingeniería en Sistemas Computacionales Plan 2004 • Especificación de servicios. se analiza un problema con el fin de determinar clases de objetos que sea aplicables en el desarrollo de la solución. Elaborados por: Lic. de SW los objetos que se derivan de cada clase de las interrelaciones entre ellos y proporciona una notificación que refleja las relaciones entre los objetos. durante la cual transformamos el modelo de diseño de objetos para tratar criterios de desempeño. 70 . • Reestructuración del modelo de objetos. • Optimización del modelo de objetos. durante la cual transformamos el modelo de diseño de objetos para mejorar su comprensibilidad y extensibilidad. durante la cual identificamos componentes hechos y objetos de solución adicionales. El diseño de objetos. no es algorítmico. • Selección de componentes. El de DOO permite al ing. como el tiempo de respuesta o la utilización de la memoria. Esencialmente AOO es una actividad de clasificación. durante la cual describimos con precisión cada interfaz de clase. al igual que el diseño del Sistema. Martin Valencia Pág.

Modelo en Cascada: El más conocido. por lo tanto. el paradigma del ciclo de vida abarca las siguientes actividades: Elaborados por: Lic.1 Modelo de Cascada: Este enfoque metodológico que ordena rigurosamente las etapas del ciclo de vida del Software. Cada modelo es una descripción de un proceso Software que se presenta desde una perspectiva particular. 4. un modelo de procesos del Software es una simplificación o abstracción de un proceso real. Alternativamente. Martin Valencia Pág. por lo que cada empresa deberá utilizar los métodos. Sin embargo. tenemos diferentes modelos de proceso. ninguno impone un modelo de procesos concreto (modelo de ciclo de vida) ni cómo realizar las diferentes actividades incluidas en cada proceso. está basado en el ciclo convencional de una ingeniería. el esfuerzo necesario para introducir un cambio en las fases más avanzadas de un proyecto. La palabra cascada sugiere. Podemos definir un modelo de procesos del Software como una representación abstracta de alto nivel de un proceso Software.INSTITUTO TECNOLÓGICO DE JIQUILPAN Apuntes de Fundamentos de Desarrollo de Sistemas Ingeniería en Sistemas Computacionales Plan 2004 UNIDAD IV MODELOS DE PROCESO DE SOFTWARE: Introducción: 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. mediante la metáfora de la fuerza de la gravedad. Un modelo es más adecuado que otro para desarrollar un proyecto dependiendo de un conjunto de características de éste. Por su naturaleza. 71 . de forma tal que el inicio de cada etapa debe esperar a la finalización de la inmediatamente anterior. técnicas y herramientas que considere oportuno. los modelos son simplificaciones. Según las fases y el modo en que se produzca este encadenamiento. 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. Existe una gran variedad de modelos diferentes entre los que tenemos los que se describen a continuación.

4. Se lleva a cabo teniendo en cuenta ciertos principios: .Debe presentarse y entenderse el dominio de la información de un problema. Debido a que el Software es siempre parte de un Sistema mayor.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. . así como la manera en que se combinan unos con otros. 3. Traduce los requisitos en una representación del Software con la calidad requerida antes de que comience la codificación.Ingeniería y Análisis del Sistema.INSTITUTO TECNOLÓGICO DE JIQUILPAN Apuntes de Fundamentos de Desarrollo de Sistemas Ingeniería en Sistemas Computacionales Plan 2004 - Ingeniería y Análisis del Sistema Análisis de los Requisitos Diseño Codificación Prueba Mantenimiento 1.. Martin Valencia Pág.. 2. . Se analizan las necesidades de los usuarios finales del Software para determinar qué objetivos debe cubrir.Prueba. .Defina las funciones que debe realizar el Software.Diseño del Sistema: Se descompone y organiza el Sistema en elementos que puedan elaborarse por separado. . aprovechando las ventajas del desarrollo en equipo. el trabajo comienza estableciendo los requisitos de todos los elementos del Sistema y luego asignando algún subconjunto de estos requisitos al Software. Dependiendo del lenguaje de programación 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. 72 . .Codificación El diseño debe traducirse en una forma legible para la máquina. Se implementa el código fuente.Diseño...Análisis de Sistemas de Computación. funciones y comportamiento. Elaborados por: Lic..Represente el comportamiento del Software a consecuencias de acontecimientos externos.Divida en forma jerárquica los modelos que representan la información.

Sumamente sencillo ya que sigue los pasos intuitivos necesarios a la hora de desarrollar el Software. Los resultados y/o mejoras no son visibles. 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. Por el contrario. y a dicha fase de pruebas. Ventajas: Se tiene todo bien organizado y no se mezclan las fases. se ensamblan para componer el Sistema y se comprueba que funciona correctamente antes de ser puesto en explotación. Elaborados por: Lic. ya que este es muy restrictivo y no permite movilizarse entre fases..2 Modelo de Espiral: El Desarrollo en Espiral es un modelo de ciclo de vida desarrollado por Barry Boehm en 1985. el programa no realiza lo que el usuario espera. Se implantan los niveles Software y Hardware que componen el proyecto. Los cambios ocurrirán debidos a que hayan encontrado errores. utilizado generalmente en la Ingeniería de Software. cada bucle es una actividad. dónde se comprueba cada funcionalidad del programa completo en entornos de producción. Finalmente y antes de salir al mercado. Durante la explotación del Sistema Software pueden surgir cambios. Todo ello recoge en los Documentos de Cambios. el producto se ve recién cuando este esté finalizado. o debido a que el cliente requiera ampliaciones funcionales o del rendimiento. por lo que provoca un gran atraso trabajando en este modelo. Es perfecto para proyectos que son rígidos. Desventajas: . Ideal para proyectos en que se conozca muy bien la herramienta a utilizar. Martin Valencia Pág. beta testing. 6. Ideal para proyectos donde se especifiquen muy bien los requerimientos.INSTITUTO TECNOLÓGICO DE JIQUILPAN Apuntes de Fundamentos de Desarrollo de Sistemas Ingeniería en Sistemas Computacionales Plan 2004 Los elementos. En un defecto de forma. bien para corregir errores o bien para introducir mejorar.Implementación. testing o beta testing es un proceso usado para identificar posibles fallos. El Software sufrirá cambios después de que se entrega al cliente.Difícilmente un cliente va a establecer al principio todos los requerimientos necesarios.. 4. A la versión del producto de pruebas y que es anterior a la versión final (o “master”) se denomina beta. Las actividades de este modelo son una espiral. Es una de las fases finales del proyecto. El Software obtenido se pone en producción. es cada vez más habitual que se realice una fase de RTM testing ( Release To Market ). a que el Software deba adaptarse a cambios del entorno externo (Sistema operativo o dispositivos periféricos). un error de programación puede describirse como un fallo en la semántica de un programa de ordenador. ya programados. 7. 73 . En general. Las pruebas de Software.Mantenimiento. los usuarios distinguen entre errores de programación (o “bugs”) y defectos de forma.

INSTITUTO TECNOLÓGICO DE JIQUILPAN Apuntes de Fundamentos de Desarrollo de Sistemas Ingeniería en Sistemas Computacionales Plan 2004

Para cada actividad habrá cuatro tareas: 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. 2.- Análisis de riesgo: Análisis de alternativas e identificación/resolución de riesgos. 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. 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.

Conclusión: 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
Elaborados por: Lic. Martin Valencia Pág. 74

INSTITUTO TECNOLÓGICO DE JIQUILPAN Apuntes de Fundamentos de Desarrollo de Sistemas Ingeniería en Sistemas Computacionales Plan 2004

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. 4.3 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í: 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.

Elaborados por:

Lic. Martin Valencia

Pág. 75

INSTITUTO TECNOLÓGICO DE JIQUILPAN Apuntes de Fundamentos de Desarrollo de Sistemas Ingeniería en Sistemas Computacionales Plan 2004

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. Difícil de evaluar el costo 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.

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 sencillo 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. Requiere de mucha planeación, tanto administrativa como técnica. Requiere de metas claras para conocer el estado del proyecto.

Conclusión: Un modelo incremental lleva a pensar en un desarrollo modular, con entregas parciales del producto de Software denominados “incrementos” del Sistema, que son escogidos en base a prioridades predefinidas de algún modo. El modelo permite una implementación con refinamientos 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 de Software. 4.4Proceso de Desarrollo Unificado:
Elaborados por: Lic. Martin Valencia Pág. 76

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. Por dicho motivo. el Lenguaje Unificado de Modelado. Construcción y Transición. implementación. Grady Booch y James Rumbaugh. Diseño.INSTITUTO TECNOLÓGICO DE JIQUILPAN Apuntes de Fundamentos de Desarrollo de Sistemas Ingeniería en Sistemas Computacionales Plan 2004 El Proceso Unificado de Desarrollo de Software o simplemente Proceso Unificado es un marco de desarrollo de Software iterativo e incremental. Desde entonces los autores que publican libros sobre el tema y que no están afiliados a Rational utilizan el término Proceso Unificado. Implementación y Prueba. 77 . prueba. .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. el proceso dirigido por casos de uso es el RUP. los dos nombres suelen utilizarse para referirse a un mismo concepto. 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. Elaboración. conocidos también por ser los desarrolladores del UML. También permite evitar problemas legales ya que Rational Unific Process o RUP son marcas registradas por IBM (desde su compra de Rational Software Corporation en 2003). . La Elaborados por: Lic. El Proceso Unificado de Desarrollo de Software (ISBN 84–7829–036–2) y fue publicado en 1999 por Ivan Jacobson. por lo que muchas veces resulta imposible decir si un refinamiento particular del proceso ha sido derivado del Proceso Unificado o del RUP. mientras que los autores que pertenecen a Rational favorecen el nombre de Rational Unific Process RUP. etc. sino un marco de trabajo extensible que puede ser adaptado a organizaciones o proyectos específicos. El primer libro sobre el tema se denominó. 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. De la misma forma. Estas iteraciones ofrecen como resultado un incremento del producto desarrollado que añade o mejora las funcionalidades del Sistema en desarrollo.Iterativo e Incremental El Proceso Unificado es un marco de desarrollo iterativo e incremental compuesto de cuatro fases denominadas Inicio. Martin Valencia Pág. Por dicho motivo existen múltiples modelos y vistas que definen la arquitectura de Software de un Sistema.Centrado en la arquitectura El Proceso Unificado asume que no existe un modelo único que cubra todos los aspectos del Sistema. El Proceso Unificado no es simplemente un proceso. el grado de esfuerzo dentro de cada una de ellas varía a lo largo del proyecto. en su versión española. El refinamiento más conocido y documentado del Proceso Unificado es el Rational Unific Process o simplemente RUP. Aunque todas las iteraciones suelen incluir trabajo en casi todas las disciplinas. 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). Características: . el RUP también es un marco de trabajo extensible. Nota: en UP se está dirigido por requisitos y riesgos de acuerdo con el libro UML 2 de ARLOW.

Martin Valencia Pág.5 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. 4. .Control de calidad. . . Fue propuesto por Watts Humphrey en 1995 y estaba dirigido a estudiantes. 78 . En el PSP se excluyen los siguientes temas: Trabajo en equipo. en especial los de la fase de Elaboración. .Ingeniería del producto de Software.Inicial: . etc. 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.Repetible: .Revisión entre colegas.000 líneas de código.Manejo integrado del Software.INSTITUTO TECNOLÓGICO DE JIQUILPAN Apuntes de Fundamentos de Desarrollo de Sistemas Ingeniería en Sistemas Computacionales Plan 2004 analogía con la construcción es clara.Foco del proceso de Software. fontanería. Elaborados por: Lic.Seguimiento y control de proyectos .Definición del proceso de Software. . . deben ser seleccionados en un orden que asegure que los riesgos principales son considerados primero. Nivel 3 . Los siguientes son los niveles y las KPAs que se manejan en cada uno: Nivel 1 .Planeación de los proyectos Nivel 2 . Los resultados de cada iteración. cuando construyes un edificio existen diversos planos que incluyen los distintos servicios del mismo: electricidad. A partir de 1997 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.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.Administración cuantitativa del proyecto.Definido: . 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.

al tercero.El PSP tiene varias fases: PSP0: Proceso Base.Controlado: . administración y mejora de sus habilidades al construir programas.1: Complementos al proceso base. PSP0. atendiéndose en cada nivel un conjunto de aspectos a mejorar del Proceso de Desarrollo de Software. Gran parte de las tareas y actividades definidas en los scripts generará en su realización un conjunto de datos. como nivel 3 o cíclico personal. Considerando aspectos como la planeación. al segundo como nivel 1 o de planeación personal. PSP1 y PSP1. tanto sus fortalezas como sus debilidades. 79 . Al primer nivel se le conoce como 0 o de medición personal. como nivel 2 o de calidad personal. PSP2 y PSP2. proveniente del Instituto de Ingeniería del Software (SEI). fundamentalmente de carácter estadístico. identificados del 0 al 3. Martin Valencia Pág. calidad. estimación de costos y productividad. permitirán al Ingeniero de Software identificar. las actividades establecidas en PSP están orientadas al conocimiento. El Proceso Personal Software. . tiene una versión que los extiende.Administración de los cambios del proceso. 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. con excepción del 3. 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.INSTITUTO TECNOLÓGICO DE JIQUILPAN Apuntes de Fundamentos de Desarrollo de Sistemas Ingeniería en Sistemas Computacionales Plan 2004 Nivel 4 . y el análisis de la información estadística generada en cada uno de éstos. introduciendo tareas y actividades para un mejor manejo de los aspectos de interés en nivel. y al cuarto. que les permite mejorar la forma en la que construyen Software. están puntualmente definidas en un conjunto de documentos conocidos como scripts. Elaborados por: Lic. La aplicación de PSP en varios procesos de desarrollo.1: Planeación personal.Prevención de defectos.1: Control de calidad personal. o bien para incluir nuevos aspectos. . PSP3: Programas más grandes.Administración del cambio tecnológico. . y crecer a través de un proceso de autoaprendizaje y auto-mejora. Cada uno de estos niveles. PSP es una alternativa dirigida a los ingenieros de Sistemas. es una metodología de reciente creación. Los scripts se organizan en cuatro niveles. conocido por sus siglas como PSP. En PSP todas las tareas y actividades que el ingeniero de Software debe realizar durante el proceso de desarrollo de un producto de Software. Los scripts son el punto medular de PSP. ya que de ello dependerá el éxito de la mejora que se busca. por lo que se hace mucho énfasis en que deben ser seguidos en forma disciplinada.

meteorología.) Una definición precisa aún no ha sido contemplada en los diccionarios. 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. medicina. Martin Valencia Pág. 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. derecho. Introducción. banca. Intranet. control de tráfico. 80 . logística. Sistemas operativos. Internet. tales como construcción de compiladores. HERRAMIENTAS Y ESTUDIOS PREVIOS. Esta ingeniería trata con áreas muy diversas de la informática y de las ciencias de la computación. investigación científica. producción. o desarrollos Intranet/Internet. etc. sin embargo se pueden citar las enunciadas por algunos de los más prestigiosos autores: Elaborados por: Lic.INSTITUTO TECNOLÓGICO DE JIQUILPAN Apuntes de Fundamentos de Desarrollo de Sistemas Ingeniería en Sistemas Computacionales Plan 2004 UNIDAD V: TECNICAS.

1972). ambiguos o contradictorios. de esta etapa depende en gran medida el logro de los objetivos finales. operación y mantenimiento del Software. en los Estados Unidos. la aplicación de la ingeniería al Software (IEEE. dentro de etapas como las siguientes: . 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. tales como CMM-I. disciplinado y cuantificable al desarrollo. análisis y especificación de requisitos (incluso pruebas de ellos). Especificación de Requerimientos del Sistema. Se han ideado modelos y diversos procesos de trabajo para estos fines. 1976). Es la aplicación de un enfoque sistemático. la Oficina de Estadísticas del Trabajo (U.Análisis de requisitos: Extraer los requisitos de un producto de Software es la primera etapa para crearlo. En Hispanoamérica el término usado normalmente es el primero de ellos. es decir. Aunque aún no está formalizada. Etapas del proceso La ingeniería de Software requiere llevar a cabo numerosas tareas. . [1] El término “Ingeniero de Software”. 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. se define un diagrama de Entidad/Relación. 830–1998 normaliza la creación de las Especificaciones de Requisitos Software (Software Requirements Specification). Mientras que los clientes piensan que ellos saben lo que el Software tiene que hacer. Asimismo. es una parte crucial. 81 . 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. ya se habla de la Ingeniería de Requisitos. sin embargo. 1978). En el 2004. 1993). La IEEE Std. que sea fiable y trabaje en máquinas reales (Bauer. cuya estructura puede venir definida por varios estándares. Se conoce también como Desarrollo de Software o Producción de Software (Bohem. S. Indistintamente se utilizan los términos Ingeniería de Software o Ingeniería del Software. se requiere de habilidad y experiencia en la ingeniería de Software para reconocer requisitos incompletos. y no todos los ingenieros de Software poseen realmente títulos de Ingeniería de universidades reconocidas.INSTITUTO TECNOLÓGICO DE JIQUILPAN Apuntes de Fundamentos de Desarrollo de Sistemas Ingeniería en Sistemas Computacionales Plan 2004 Ingeniería de Software es el estudio de los principios y metodologías para el desarrollo y mantenimiento de Sistemas Software (Zelkovitz. El resultado del análisis de requisitos con el cliente se plasma en el documento ERS. se utiliza en forma genérica en el ambiente empresarial. 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. operar y mantenerlos.840 ingenieros de Software de computadora. en el que se plasman las principales entidades que participarán en el Desarrollo del Software.Especificación: Elaborados por: Lic. Bureau of Labor Statistics) contó 760. Martin Valencia Pág. La captura.

Documentación: Todo lo concerniente a la documentación del propio Desarrollo del Software y de la gestión del proyecto. El segundo enfoque es tener un área de pruebas conformada por programadores con experiencia. en una forma matemáticamente rigurosa. . manuales técnicos. la red.INSTITUTO TECNOLÓGICO DE JIQUILPAN Apuntes de Fundamentos de Desarrollo de Sistemas Ingeniería en Sistemas Computacionales Plan 2004 Es la tarea de describir detalladamente el Software a ser escrito. 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.Prueba: Consiste en comprobar que el Software realice correctamente las tareas indicadas en la especificación del problema. como el Hardware. que los procesos descritos son tan claros que cualquiera puede entenderlos y el Software hace las cosas tal y como están descritas. .Diseño y arquitectura: Se refiere a determinar cómo funcionará de forma general sin entrar en detalles. que deben permanecer estables. pero no necesariamente es la que demanda mayor trabajo y ni la más complicada. En la realidad. manuales de usuario. mantenimiento futuro y ampliaciones al Sistema. . En general hay dos grandes formas de organizar un área de pruebas. Elaborados por: Lic. de esta forma se evalúa que la documentación entregada sea de calidad. la mayoría de las buenas especificaciones han sido escritas para entender y afinar aplicaciones que ya estaban desarrolladas. Una técnica de prueba es probar por separado cada módulo del Software. Se considera una buena práctica el que las pruebas sean efectuadas por alguien distinto al desarrollador que la programó. y se transforman las entidades definidas en el análisis de requisitos en clases de diseño. etc. Se definen los Casos de Uso para cubrir las funciones que realizará el Sistema. . para así llegar al objetivo. 82 . alrededor de 2/3 de toda la ingeniería civil. la primera es que esté compuesta por personal inexperto y que desconozca el tema de pruebas. Consiste en incorporar consideraciones de la implementación tecnológica. Una pequeña parte de este trabajo consiste en arreglar errores. Alrededor de 2/3 de toda la ingeniería de Software tiene que ver con dar mantenimiento. o bugs. idealmente un área de pruebas. todo con el propósito de eventuales correcciones. La mayor parte consiste en extender el Sistema para hacer nuevas cosas. pruebas. obteniendo un modelo cercano a la programación orientada a objetos. y luego probarlo de forma integral. arquitectura y trabajo de construcción es dar mantenimiento. Las especificaciones son más importantes para las interfaces externas. La complejidad y la duración de esta etapa está íntimamente relacionada al o a los lenguajes de programación utilizados. etc. Martin Valencia Pág. usabilidad. De manera similar. sin perjuicio de lo anterior el programador debe hacer sus propias pruebas. .Programación: Reducir un diseño a código puede ser la parte más obvia del trabajo de ingeniería de Software. Esto puede llevar más tiempo incluso que el desarrollo inicial del Software. diagramas.Mantenimiento: Mantener y mejorar el Software para enfrentar errores descubiertos y nuevos requisitos. pasando por modelaciones (UML). así como al diseño previamente realizado.

y con ello. cuáles serán las áreas del conocimiento que debe reforzar. llevar el control de la entrevista. Quienes responde pueden ser gerentes o empleados. es necesaria la documentación y referencias escritas que el Analista requiere así como el Diseñador de las interfaces finales. además de que es indispensable determinar cómo se va a presentar el proyecto. Se necesitan pensar detenidamente las entrevistas antes de hacerlas. los cuales son usuarios actuales del Sistema. se utilizan dos o tres para complementar el trabajo de cada una y ayudar a asegurar una investigación completa. Además se debe tratar de captar los sentimientos de los entrevistados. pero al mismo tiempo.1 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.INSTITUTO TECNOLÓGICO DE JIQUILPAN Apuntes de Fundamentos de Desarrollo de Sistemas Ingeniería en Sistemas Computacionales Plan 2004 . nosotros debemos de establecer un ambiente de confianza y de entendimiento rápidamente. y dentro de ella. Cada uno tiene ventajas y desventajas. 5. Se debe de tratar de averiguar lo más que se pueda acerca de las metas de la organización por medio de las entrevistas.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. A continuación se verán cada una de ellas. metas organizacionales y personales y procedimientos informales. cuanta información será necesaria para el usuario final. Elaborados por: Lic. etc.1. Necesitamos conocer nuestros prejuicios y cómo afectarán éstos nuestras percepciones.1 Entrevista: Antes de entrevistar a alguien más. También es necesario mencionar que sumado a todos estos conceptos tan necesarios para complementar un Proyecto de Desarrollo de Software. 5. Generalmente. a través de preguntas que propone el analista. Martin Valencia Pág. 83 . En la entrevista necesitamos obtener las opciones de los entrevistados y su parecer acerca del estado actual del sistema. debemos pensar cómo lograremos que la entrevista sea satisfactoria para el individuo al que entrevistemos. cuestionario. inspección de registros y observación. poder entender la cultura de la organización de una manera más compleja. Asimismo. Una entrevista es una conversación dirigida con un propósito específico que utiliza un formato de preguntas y respuestas. como entrevistas. 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 RAD (Rapid Application Development). Las entrevistas se utilizan para recabar información en forma verbal. en las cuales se centrará el usuario final. tenemos que entrevistarnos a nosotros mismos.

PREPARAR AL ENTREVISTADO: Esto es preparar a la persona a ser entrevistada. una estructura de embudo o una estructura de diamante (iniciar con preguntas generales y abiertas. para redactar las preguntas de la entrevista de forma que sea comprensible para el entrevistado. Las entrevistas deben durar de 45 minutos a una hora. Su ventaja es construir un vocabulario común. a lo mucho. La estructura de las preguntas deben de ser como una pirámide (empezar con preguntas a menudo cerradas. Si las entrevistas tienen una larga duración.INSTITUTO TECNOLÓGICO DE JIQUILPAN Apuntes de Fundamentos de Desarrollo de Sistemas Ingeniería en Sistemas Computacionales Plan 2004 existen usuarios potenciales del Sistema propuesto o aquellos que proporcionaran datos o serán afectadas por la aplicación propuesta. Establecer los objetivos de la entrevista: Debe de haber áreas claves referentes al procesamiento de la información y al comportamiento relacionado con la toma de decisiones acerca de las cuales tendremos que hacer preguntas. Elaborados por: Lic. Decidir el tipo de preguntas y la estructura: Se deben de escribir preguntas que abarquen las áreas de la toma de decisiones que haya descubierto la terminar los objetivos de la entrevista. Los dos tipos básicos de preguntas son: 1. PLANEACION PARA LA ENTREVISTA Hay cinco pasos principales para la preparación de la entrevista:      LECTURA DE MATERIAL DE FONDO: Esto es leer y comprender la información acerca del entrevistado. y concluir limitando las respuestas con preguntas cerradas). y continuar con preguntas abiertas y más generalizadas). En la entrevista se quiere obtener la opinión del entrevistado y sus sentimientos acerca del estado actual del Sistema. llamándole con anticipación y permitiendo que el entrevistado tenga tiempo para pensar acerca de la entrevista._ Cerradas. ESTABLECIMIENTO DE LOS OBJETIVOS DE LA ENTREVISTA: Requiere usar la información que se recopiló. El analista puede entrevistar al personal en forma individual o en grupos. Martin Valencia Pág. Preparar al entrevistado: Se realiza hablándole por anticipado o enviándole un mensaje por correo electrónico. 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.      Leer los antecedentes: El propósito es crear un vocabulario común que en un futuro le permita expresar preguntas de la entrevista de una manera comprensible para su entrevistado. Decidir a quién entrevistar: Se debe incluir a la gente clave en todos niveles que vayan a ser afectadas por el sistema de alguna manera. 2. La entrevista es una conversación dirigida que usa un formato de preguntas y respuestas. 84 . es posible que los entrevistados se enfaden. así como la experiencia para establecer los objetivos de la entrevista. pero lo pueden ocultar._ Abiertas. DECIDA SOBRE TIPOS DE PREGUNTAS Y ESTRUCTURAS: Esto es escribir preguntas para tratar las áreas principales de la toma de decisiones descubiertas cuando se averiguaron los objetivos de la entrevista.

Con las preguntas para respuestas cerradas se proporciona al usuario un conjunto de respuestas que se pueda seleccionar. Mucha gente incapaz de expresarse por escrito puede discutir sus ideas en forma verbal. La confiabilidad es solo una consideración en la selección del método de entrevista. La atmósfera abierta y de fácil flujo de esta modalidad proporciona una mayor oportunidad para conocer las actitudes. A menudo las entrevistas dan la mejor fuente de información cualitativa. Recabar datos mediante la entrevista. 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. que pedirles que llenen cuestionarios. más aún a menudo es más fácil calendarizar una entrevista con los gerentes del alto nivel. es conveniente elaborar una serie de preguntas sin estructura. los otros métodos tienden a ser más útiles en la recolección de datos cuantitativos. con una sección de preguntas y respuestas libres. ¡no interrogación! Al analizar las características de los Sistemas con personal seleccionado cuidadosamente por sus conocimientos sobre el Sistema los analistas pueden conocer los datos que no están disponibles en ninguna otra forma. Las entrevistas estructuradas utilizan preguntas estandarizadas.INSTITUTO TECNOLÓGICO DE JIQUILPAN Apuntes de Fundamentos de Desarrollo de Sistemas Ingeniería en Sistemas Computacionales Plan 2004 Cada tipo de pregunta puede lograr algo diferente y cada una tiene sus beneficios y desventajas. 85 . analizar las respuestas después de las entrevistas lleva más tiempo que con las entrevistas estructuradas. porque no se necesita tener por anticipado las palabras precisas de las preguntas. Sin embargo. De cualquier manera. La estructura de las entrevistas varía. Así. opiniones y conocer cómo 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. Dado que un número de personas se seleccionara para la entrevista. Las entrevistas no estructuradas requieren menos tiempo de preparación. las entrevistas estructuradas son mejores. el mayor costo radica en la preparación. El formato de respuestas para las preguntas puede ser abierto o cerrado. administración y análisis de las entrevistas estructuradas para preguntas cerradas. Si el objetivo de la entrevista radica en adquirir información general. frecuencia o cantidades. políticas y descripciones cuantitativas tratan con números. Sin embargo. falsas expectativas o incluso resistencia potencial para las aplicaciones en desarrollo. durante la investigación detallada en donde el objetivo es descubrir hechos específicos. La información cualitativa está relacionada con opiniones. Como resultado de esto las entrevistas pueden descubrir rápidamente malos entendidos. los analistas que estudian a la Elaborados por: Lic. con frecuencia las entrevistas solo se aplican a la gerencia o personal de supervisión. Sin embargo. La entrevista es una forma de conversación. Martin Valencia Pág. Todas las personas que responden se basan en un mismo conjunto de posibles respuestas. las formas cualitativas y cuantitativas de la información son importantes. Determinación del tipo de entrevista. los analistas deben tener cuidado de incluir aquellas personas que tienen información que no se podrá conseguir de otra forma. cuando los analistas determinan La factibilidad del proyecto. En las investigaciones de Sistemas. Los analistas también deben dividir su tiempo entre desarrollar preguntas para entrevistas y analizar las respuestas. ideas y creencias de quien responde. las preguntas para respuesta abierta permiten a los entrevistados dar cualquier respuesta que parezca apropiada. Durante las primeras etapas de un estudio de Sistemas.

las características anteriores también son desventajas de los cuestionarios. También las preguntas estandarizadas pueden proporcionar datos más confiables. Para los analistas los cuestionarios pueden ser la única forma posible de relacionarse con un gran número de personas para conocer varios aspectos del Sistema. Puede necesitarse algún seguimiento de los cuestionarios para motivar al personal que responda. Realización de la entrevista. no es posible observar las expresiones o relaciones de quienes responden a los cuestionarios. es muy rara una respuesta total. El tacto. sin embargo. aquellas personas que realmente trabajan en el almacén. 5. O la introducción: “Estamos aquí para resolver su problema”. Los cuestionarios proporcionan una alternativa muy útil para las entrevistas. La habilidad del entrevistador es vital para el éxito en la búsqueda de hechos por medio de la entrevista. A través de la entrevista. es decir. Por supuesto. “hola. los analistas tendrán más conocimientos no solamente de la información adquirida sino también de su importancia. todas las respuestas se encontraran en una proporción entre el 25 o 35%. Por ejemplo. Martin Valencia Pág. fui enviado para encontrar una forma de mojar el rendimiento y de reducir los errores que presentan aquí. si dijera. Aunque su aplicación puede realizarse con un mayor número de individuos.2 Cuestionario. 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. se puede distribuir los cuestionarios a todas las personas apropiadas para recabar hechos con relación al Sistema. la imparcialidad e incluso la vestimenta apropiada ayudan a asegurar una entrevista exitosa. Selección de formas para cuestionarios. también entrevistaran a los agentes más importantes. 86 . Es imaginable la rapidez con la que va a responder ser irrita y se molesta con un enfoque de este tipo.1. Cuando se llevan a cabo largos estudios en varios departamentos. es igualmente mala. Elaborados por: Lic. que es lo más común. Por otra parte. por ejemplo. los analistas deben preguntarse a sí mismos las siguientes interrogantes:     ¿Qué es lo que me está diciendo la persona? ¿Por qué me lo está diciendo a mí? ¿Qué se está olvidando? ¿Qué espera esta persona que haga yo? Si se considera cada elemento de la información contra estas preguntas. existen ciertas características que pueden ser apropiadas en algunas situaciones e inapropiadas en otras.INSTITUTO TECNOLÓGICO DE JIQUILPAN Apuntes de Fundamentos de Desarrollo de Sistemas Ingeniería en Sistemas Computacionales Plan 2004 administración de inventarios pueden entrevistar a los trabajadores del embarque y de recepción. La falta de estos factores puede reducir cualquier oportunidad de éxito. Las buenas entrevistas dependen del conocimiento del analista tanto de la preparación del objetivo de una entrevista específica como de las preguntas por realizar a una persona determinada. al personal del almacén y a los supervisores de los diferentes turnos. Recolección de datos mediante cuestionarios.

el analista puede controlar el marco de referencia.INSTITUTO TECNOLÓGICO DE JIQUILPAN Apuntes de Fundamentos de Desarrollo de Sistemas Ingeniería en Sistemas Computacionales Plan 2004 El desarrollo y distribución de los cuestionarios es caro. un analista que utiliza cuestionarios para estudiar los métodos de verificación de crédito. opiniones y experiencias generales. también son útiles al explorar el problema básico. La realización de esto también es desgastante y cara. ¿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 más útil para el estudio y la más sencilla de entender por parte de los interrogados. Al igual. También fuerza a los individuos para que tomen una posición y forma de opinión sobre los aspectos importantes. el tiempo invertido en esto debe utilizarse en una forma inteligente. podría recabar más 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. Existen dos formas de cuestionarios para recabar datos. Martin Valencia Pág. Selección de quienes recibirán el cuestionario. Aquellas personas que reciban el cuestionario deben seleccionarse de acuerdo con la información que puedan proporcionar. Elaborados por: Lic. Con frecuencia se utilizan ambas formas en los estudios de Sistemas. La primera consideración se encuentra en determinar el objetivo del cuestionario. los cuestionarios pueden ser abiertos y se aplican cuando se quieren conocer los sentimientos. que las entrevistas. Los cuestionarios bien hechos no se desarrollan rápidamente. antes de que imprima una forma final y se distribuya. Cuestionarios abiertos. Este formato es el mejor método para obtener información sobre los hechos. 87 . Lo pueden contestar personas no calificadas y si el cuestionario no es anónimo. Escribir o imprimir un cuestionario no significa que se pueda distribuir ampliamente sin un análisis previo. en un medio ambiente de ventas al a menudeo. Por medio de un cuidadoso estilo en la pregunta. También es importante el formato y contenido de las preguntas en la recopilación de hechos significativos. por ejemplo. cuestionario abierto y cerrados. Lleva tiempo desarrollar preguntas bien elaboradas y deben siempre probarse y modificarse. y no será posible retirar sus respuestas de la muestra. llevan tiempo y mucho trabajo. si es necesario. y se aplican dependiendo de si los analistas conocen de antemano todas las posibles respuestas de las preguntas y pueden incluirlos. por lo tanto. El cuestionario cerrado limita las respuestas posibles del interrogado. Etapas en el desarrollo de un cuestionario.

Martin Valencia Pág. Consiste en recopilar. Los diagramas de flujo son la representación gráfica de un proceso administrativo. 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. Una regla general que debe tomarse en cuenta al realizar los registros. examinar y formular los requisitos del cliente y examinar cualquier restricción que se pueda aplicar. Cuadros de Distribución de Trabajo: Describe las actividades de cada unidad de la estructura de un departamento. el responsable del estudio presentará a los usuarios un documento final. Da las bases para escribir un informe lógico y claro. Como último paso del proceso de la investigación sobre la forma actual de operar del sistema. A través de esta técnica se obtiene una visión de las unidades de trabajo. el analista deberá auxiliarse del uso de diagramas para el registro de las actividades. Es esencial obtener copias de los documentos utilizados en el sistema. Objetivos del procedimiento. Fluxogramas de procedimientos de diagramas de flujo: Representa el flujo de información de un procedimiento y satisfacen 3 funciones principales: - Permite al analista asegurarse que se ha desarrollado todos los aspectos del procedimiento. A través del diagrama de flujo puede graficarse cualquier situación administrativa u operativa. a fin de cubrir posteriormente la fase de análisis y crítica del mismo. el analista o grupo de analistas procederán a organizar y documentar todo el material escrito.INSTITUTO TECNOLÓGICO DE JIQUILPAN Apuntes de Fundamentos de Desarrollo de Sistemas Ingeniería en Sistemas Computacionales Plan 2004 5. Su valor residen destacar los niveles de autoridad. La presentación del documento debe presentarse bajo la siguiente estructura: 1. Es importante la adopción de un método mediante el cual se registrarán los hechos del estudio. representada en forma objetiva para mostrar procedimientos. Elaborados por: Lic. Es un medio para establecer un enlace con el personal que eventualmente operará el nuevo procedimiento. Introducción. Existen fundamentalmente tres tipos de diagramas: Organigramas: Muestran la estructura orgánica y/o funcional de una organización. determinando qué hace cada puesto. es hacerlo con la debida calidad para que cualquier persona pueda entenderlos. con el objeto de ultimar detalles que no hayan sido comprendidos por el analista. Durante el curso de investigación. es de exigencia general. 2. Señalan las funciones de línea y dan idea de las responsabilidades del personal de esa organización.3 Recopilación y Análisis de Documentos. Una vez que se ha reunido toda la información relativa a la forma actual de operar del sistema.1. Registrar ordenadamente la información recopilada de cualquier investigación que se realice. 88 .

Formas e instructivos. Descripción literaria del sistema. 5. 4. comparten y usan la información para hacer que el trabajo se realice. La observación proporciona información de primera mano en relación con la forma en que se llevan a cabo las actividades. pueden contestarse rápidamente si se observan las operaciones. la manera en la que se realizan las tareas y si ocurren los pasos específicos como se pre-establecieron. 7. Las preguntas sobre el uso de documentos. Hojas de operaciones. ” Kendall & Kendall (Pág.1. 8. ¡Ver es creer! Observar las operaciones le proporciona la analista hechos que no podría obtener de otra forma. procesan. Sin embargo la observación permite que el analista vea de primera mano cómo los gerentes recopilan. también le ayuda y le dice algo más.INSTITUTO TECNOLÓGICO DE JIQUILPAN Apuntes de Fundamentos de Desarrollo de Sistemas Ingeniería en Sistemas Computacionales Plan 2004 3. Leer en relación con una actividad del negocio le proporciona al analista una dimensión de las actividades del Sistema. 89 . Entrevistar personal. leer en relación con un viaje en jet no reproduce la experiencia de volar a unos 30 mil pies de altura. Recopilación de datos mediante la observación. 181). Existen siete elementos concretos que son fácilmente observables por el analista de Sistemas. tal como se dijo anteriormente. Diagramas del flujo de actividades. 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. procesa. Apéndices. ya sea directamente o a través de cuestionarios. Ninguno de los dos métodos da una información completa. por ejemplo. 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. Una vez documentado el sistema actual se procederá a obtener la aprobación de los responsables de su operación. Cuadros comparativos. Estos elementos pueden revelar mucho acerca de la forma en que el tomador de decisiones recopila. 9. 6. “El método para la observación estructurada del ambiente es llamado STROBE. Conclusiones generales. Elaborados por: Lic. 5. Martin Valencia Pág.4 Observación y Técnica “STROBE”.

es probable que el tomador de decisiones guarde pocos conceptos de información personalmente. Si hay abundancia de equipo. Un ejecutivo en una oficina iluminada cálidamente. Revistas y periódicos del negocio. procesan.INSTITUTO TECNOLÓGICO DE JIQUILPAN Apuntes de Fundamentos de Desarrollo de Sistemas Ingeniería en Sistemas Computacionales Plan 2004 guarda y comparte información. 4. Martin Valencia Pág. 90 . Mediante el uso de STROBE el analista de Sistemas puede obtener una mejor comprensión sobre la manera en que los gerentes recopilan. Ubicación del escritorio del tomador de decisiones. recopilará más información informalmente y. Equipo de oficina fijo. etc. representan la máxima autoridad de acuerdo con algunos investigadores que han estudiado la percepción de la apariencia de los ejecutivos. Las oficinas distribuidas dan como resultado la demora de reportes o memos en alguna de ellas. es presumible que el tomador de decisiones almacene y valore mucha información. 2. en cambio. en una oficina brillantemente iluminada y coloreada se recolecta información mediante memorándums más formales y reportes oficiales. Propiedades. pantallas de video. Elaborados por: Lic. Todo el equipo pequeño que se usa para procesar información calculadoras. almacenan y usan información. 6. etc). Se conforma de archiveros. manuales de políticas. 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. Las oficinas accesibles tienden a incrementar la interacción y los mensajes informales. así como acerca de la credibilidad del tomador de decisiones en el espacio de trabajo: 1. Nos indica la manera en que el tomador de decisiones recopila información. Iluminación y color de la oficina. Vestimenta usada por los tomadores de decisiones. los grupos de oficinas motivan que se comparta la información. 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. lápices. 3. Proporciona pistas sobre el ejercicio de poder por el tomador de decisiones. El traje formal de tres piezas para un hombre o el traje sastre para mujer. 7. libreros. Ubicación de la oficina.) 5. Alternativas de aplicación. Las oficinas inaccesibles disminuyen la frecuencia de interacción e incrementan los mensajes orientados a la tarea. en cambio. Si no hay equipo. etc.

Saber que buscar y como guiar su significado. Sirve para evaluar los elementos STROBE en comparación con la narración organizacional generada por medio de entrevistas. o Elaborados por: Lic. La observación es muy útil cuando el analista necesita ver de primera mano. 91 . Los manuales que documentan o describen las operaciones para los procesos de datos existentes.INSTITUTO TECNOLÓGICO DE JIQUILPAN Apuntes de Fundamentos de Desarrollo de Sistemas Ingeniería en Sistemas Computacionales Plan 2004 Existen estrategias para llevar a cabo los pasos antes mencionados:    Análisis de fotografías. acerca de la recopilación. Esta forma de encontrar datos puede servir como presentación del analista. también requiere de experiencia. Se compara la narrativa y las acciones. 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. Se construye una matriz. 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. procesamiento. almacenamiento y compartición de la información (los renglones) y elementos STROBE (columnas). Enfoque de las listas de verificación/escala LIKERT. Consiste en fotografiar el ambiente de los tomadores de decisiones y análisis posterior de las mismas sobre los elementos STROBE. si se realiza al iniciar el estudio. 3. también están alertas para detectar documentos o registros que no se utilizan. 4. Martin Valencia Pág. 2. Determinar los temas organizacionales principales que se desprenden de las entrevistas. regulaciones y procedimientos de operaciones estándar que la mayoría de las empresas mantienen como guía para gerentes y empleados. Recopilación de datos por medio de la inspección ocular de registros. se usa uno de los cinco símbolos adecuados para caracterizar la relación entre la narración y el elemento relevante. Consiste en usar analistas de verificación anecdótica con símbolos de abreviaturas significativas. En la revisión de registros. Con frecuencia. El término “registro” se refiere a los manuales escritos sobre políticas. El analista crea una tabla que primero documenta y luego ayuda en el análisis de las observaciones. Es menos estructurada. Muchos tipos de registros e informes son accesibles si el analista sabe dónde buscar. cómo se manejan los documentos. Los observadores con experiencia captan quien utiliza los documentos y si encuentran dificultades. como se llevan a cabo los procesos y si ocurren los pasos especificados. 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. que liste las ideas principales a partir de la narrativa organizacional. Cuando observar. en muchas empresas la información ya se encuentra disponible para que el analista conozca las actividades u operaciones con las cuales no está familiarizado. Lista anecdótica con símbolos Es menos estructurada. Muestreo. o como un término de comparación de lo que sucede en el departamento con lo que los registros presentan como lo que debería suceder.

Las Herramientas CASE fueron desarrolladas para automatizar esos procesos y facilitar las tareas de coordinación de los eventos que necesitan ser mejorados en el ciclo de desarrollo de software. donde se ubica el poder verdadero para las decisiones.INSTITUTO TECNOLÓGICO DE JIQUILPAN Apuntes de Fundamentos de Desarrollo de Sistemas Ingeniería en Sistemas Computacionales Plan 2004 Sistemas de información que entran dentro del área de investigación. No obstante. pero muchas no reflejan las operaciones actuales. 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. documentación o detección de errores entre otras. durante todos los pasos del Ciclo de Vida de desarrollo de un Software. 5. Implementación e Instalación Una innovación en la organización. ingenieros de software y desarrolladores. Martin Valencia Pág. también proporcionan una visión sobre la forma en la que el negocio debería conducirse. 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. Los registros permiten que los analistas se familiaricen con algunas operaciones. 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). Selección de los registros para revisión. Se puede ver al CASE como la unión de las herramientas automáticas de software y las metodologías de desarrollo de software formales. las compañías pudieron desarrollar sistemas sin encarar el problema de tener cambios en las necesidades del negocio. 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. Los diagramas de organización muestran como las diferentes unidades deberían relacionarse con otras. 92 . los estados en el Ciclo de Vida de desarrollo de un Software son: Investigación Preliminar. Las herramientas CASE (Computer Aided Software Engineering. cálculo de costes. no muestran como producen de hecho las actividades. La mejor razón para la creación de estas herramientas fue el incremento en la velocidad de desarrollo de los sistemas. Diseño. 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. a menudo no se mantienen al corriente lo suficiente para señalar los procedimientos existentes. Elaborados por: Lic. compilación automática. Análisis. En la mayor parte de las empresas los manuales de estándares sobre procedimientos de operación usualmente son obsoletos. oficinas de la compañía y relaciones formales a las que debe darse apoyo. un concepto avanzado en la evolución de tecnología con un potencial efecto profundo en la organización. La realización de un nuevo software requiere que las tareas sean organizadas y completadas en forma correcta y eficiente. Historia. Como es sabido. Por esto. 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). implementación de parte del código automáticamente con el diseño dado. antes de finalizar el proceso de desarrollo.2 Herramientas CASE. Se puede definir a las Herramientas CASE como un conjunto de programas y ayudas que dan asistencia a los analistas.

usando. Middle CASE (M-CASE). Martin Valencia Pág.INSTITUTO TECNOLÓGICO DE JIQUILPAN Apuntes de Fundamentos de Desarrollo de Sistemas Ingeniería en Sistemas Computacionales Plan 2004 Aunque ésos son los inicios de las herramientas informáticas que ayudan a crear nuevos proyectos informáticos. Objetivos. pruebas de errores y gestión del proyecto. Aumentar la calidad del Software. Las herramientas CASE alcanzaron su techo a principios de los años 90. Además automatizan la documentación completa de la aplicación. Facilitar el uso de las distintas metodologías propias de la ingeniería del Software. Mejorar la planificación de un proyecto Aumentar la biblioteca de conocimiento informático de una empresa ayudando a la búsqueda de soluciones para los requisitos. 7. Las fases del ciclo de vida del desarrollo de Sistemas que cubren. 8. análisis de requisitos y estrategia del desarrollo. documentación. Lower CASE (L-CASE). En la época en la que IBM había conseguido una alianza con la empresa de Software AD/Cycle para trabajar con sus mainframes. generación de código. Mejorar el tiempo y coste de desarrollo y mantenimiento de los Sistemas informáticos. ni con la anterior: Elaborados por: Lic. 2. y que no es una clasificación excluyente entre sí. Mejorar la productividad en el desarrollo y mantenimiento del Software. 9. desarrollo del Software. la primera herramienta CASE fue Excelerator que salió a la luz en el año 1984 y trabajaba bajo una plataforma PC. estos dos gigantes trabajaban con herramientas CASE que abarcaban todo el ciclo de vida del Software. Su funcionalidad. las herramientas CASE se pueden clasificar teniendo en cuenta los siguientes parámetros: 1. herramientas para automatizar tareas en el análisis y diseño de la aplicación. soportan la depuración de programas y pruebas. crean programas de detección de errores. herramientas que ayudan en las fases de planificación. Aquí pueden incluirse las herramientas de Desarrollo Rápido de Aplicaciones. Clasificación. Automatizar. 1. 5. entre otros diagramas UML. Ayuda a la reutilización del Software. Las plataformas que soportan. 3. 93 . 4. 3. Aunque no es fácil y no existe una forma única de clasificarlas. La siguiente clasificación es la más habitual basada en las fases del ciclo de desarrollo que cubren:    Upper CASE (U-CASE). 2. 4. La arquitectura de las aplicaciones que producen. herramientas que semiautomatizan la generación de código. 6. portabilidad y estandarización de la documentación Gestión global en todas las fases de desarrollo de Software con una misma herramienta. Existen otros nombres que se le dan a este tipo de herramientas. 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.

Herramientas de mantenimiento como los Sistemas de control de versiones• TIPOS DE HERRAMIENTAS CASE No existe una única clasificación de herramientas CASE. La arquitectura de las aplicaciones que produce. Las herramientas I-CASE se basan en una metodología. Una estrategia posible es utilizar una U-CASE para análisis y diseño.INSTITUTO TECNOLÓGICO DE JIQUILPAN Apuntes de Fundamentos de Desarrollo de Sistemas Ingeniería en Sistemas Computacionales Plan 2004     Integrated CASE (I-CASE). U-CASE (Upper CASE . Son llamadas también CASE workbench. herramientas que soportan todo el ciclo de vida. Las herramientas CASE. Editores UML. es difícil incluirlas en una clase determinada. Tienen un repositorio y aportan técnicas estructuradas para todas las fases del ciclo de vida. En este caso. herramientas que permiten la definición de nuestra propia técnica de modelado. 94 . se pueden agrupar de la forma siguiente:  Herramientas integradas. Martin Valencia Pág.  Herramientas de alto nivel. Herramientas de Refactorización de código. orientadas a la automatización y soporte de las actividades desarrolladas durante las primeras fases del desarrollo: análisis y diseño. los elementos permitidos del metamodelo generado se guardan en un repositorio y pueden ser usados por otros analistas. Por funcionalidad podríamos diferenciar algunas como:     Herramientas de generación semiautomática de código. Su funcionalidad. Elaborados por: Lic. I-CASE (Integrated CASE. incluyen componentes para la gestión de proyectos y gestión de la configuración. desde análisis hasta implementación. restricciones y relaciones posibles. Estas son las características que les confieren su mayor ventaja: una mejora de la calidad de los desarrollos. no todas ellas son modernas en el sentido de aprovechar la potencia de las estaciones de trabajo o la utilización de lenguajes de alto nivel o técnicas de prototipo. IPSE (Integrated Programming Support Environment). es como si definiéramos nuestro propio UML. CASE integrado): abarcan todas las fases del ciclo de vida del desarrollo de sistemas. herramientas de soporte a la prueba de Software. CAST (Computer-Aided Software Testing). en función de las fases del ciclo de vida abarcadas. es decir. Podrían clasificarse atendiendo a:     Las plataformas que soportan. con nuestros elementos. habría que vigilar cuidadosamente la integración entre las distintas herramientas. Sin embargo. herramientas que engloban todo el proceso de desarrollo Software. Meta CASE. combinada con otras herramientas más modernas para las fases de construcción y pruebas. Las fases del ciclo de vida del desarrollo de sistemas que abarca.CASE superior) o front-end.

Herramientas de seguimiento de requisitos: Cuando se desarrollan grandes sistemas. L-CASE (Lower CASE . El objetivo de las herramientas de seguimiento de requisitos es proporcionar un enfoque sistemático para el aislamiento de requisitos. estimar la productividad y la calidad. orientadas a la fase de mantenimiento. proyectos y características del producto. la duración del proyecto y el número recomendado de personas. HERRAMIENTAS DE GESTION DE PROYECTOS: La mayoría de herramientas CASE de gestión de proyectos. 95 . con un sistema de gestión de bases de datos que almacena y categoría todos y cada uno de los requisitos del sistema que se "analizan" a partir de las especificaciones originales. hacer un seguimiento continuo del proyecto. Planificación de proyectos Capacitan al administrador para definir todas las áreas del proyecto (la estructura de desglose de tareas). para representar las interdependencias entre tareas y para modelar la cantidad de paralelismo que sea posible para ese proyecto. Las herramientas de trazado de requisitos típicos combinan una evaluación de textos por interacción humana. para crear una red de tareas (normalmente empleando una entrada gráfica).CASE inferior) o back-end. defectos por punto de función) que proporcionan una indicación global de productividad o de calidad. Elaborados por: Lic. hacer un seguimiento que va desde requisitos del pliego de condiciones técnicas inicial hasta el trabajo de desarrollo que convierte estos requisitos en un producto final. son el tipo más simple de herramientas CASE. Las herramientas orientadas técnicamente determinan métricas técnicas que proporcionan una mejor visión de la calidad del diseño o del código. Dentro de este grupo se encontrarían las herramientas de reingeniería. Martin Valencia Pág. Las herramientas orientadas a la gestión capturan métricas especificas del proyecto (por ejemplo: LDC/personamos. Utilizando un conjunto seleccionado de la misma. se centran en un elemento especifico de la gestión del proyecto. se puede: realizar estimaciones de esfuerzo. costo y duración. el sistema proporcionado suele no satisfacer los requisitos especificados por el cliente. comenzando por las especificaciones del cliente. Se incluye dentro de las herramientas de control de proyectos las siguientes:      Herramientas de planificación de proyectos: Las herramientas de esta categoría se concentran en dos áreas primordiales: Estimación de esfuerzos de proyecto y de costes de software: Calculan el esfuerzo estimado. Las herramientas métricas actuales se centran en procesos. dirigidas a las últimas fases del desarrollo: construcción e implantación. Herramientas de gestión y métricas: Las métricas del software mejoran la capacidad del administrador para controlar y coordinar el proceso del software y la capacidad del ingeniero para mejorar la calidad del software que se produce. Existen también herramientas que permite al comprador del desarrollo de un sistema. Juegos de herramientas o toolkits. Muchas de las herramientas métricas avanzadas mantienen una base de datos de medidas de medias de la industria. Automatizan una fase dentro del ciclo de vida.INSTITUTO TECNOLÓGICO DE JIQUILPAN Apuntes de Fundamentos de Desarrollo de Sistemas Ingeniería en Sistemas Computacionales Plan 2004   Herramientas de bajo nivel. en lugar de proporcionar un soporte global para la actividad de gestión.

mecanismos de desplazamiento. de la función y del comportamiento (en el nivel de análisis). Herramientas para desarrollo y diseño de interfaces: Las herramientas de desarrollo y diseño de interfaz son en realidad un conjunto de primitivas de componente de programas tales como menús. Herramientas de creación de prototipos y simulación: Las herramientas PRO/SIM (de prototipos y simulación) proporcionan al ingeniero del software la capacidad de predecir el comportamiento de un sistema en tiempo real antes de llegar a construirlo. etc. controladores de dispositivos. Entre las más utilizadas esta:  Herramientas de análisis estático: Las herramientas de análisis estático prestan su asistencia al ingeniero del software a efectos de derivar casos prácticos. Proporcionan un grado de confianza en la representación del análisis y ayudan a eliminar errores con anticipación. lenguajes de comprobación especializados. Las herramientas de comprobación basadas en código admiten un código fuente (o PDL) como entrada y efectúan un cierto número de análisis que can lugar a la generación de casos de prueba. simulación y prueba de los equipos lógicos desarrollados. 96 Elaborados por: . Sin embargo. Estas herramientas utilizan un sistema experto para sugerir el orden en el que se debe llevar a cabo un proyecto. Se utilizan tres tipos distintos de herramientas estáticas de comprobación en la industria: herramientas de comprobación basadas en código.INSTITUTO TECNOLÓGICO DE JIQUILPAN Apuntes de Fundamentos de Desarrollo de Sistemas Ingeniería en Sistemas Computacionales Plan 2004 Basándose en características de proyectos y de productos proporcionados por el usuario. botones. medición. HERRAMIENTAS DE ANALISIS Y DISEÑO: Permiten al desarrollador crear un modelo del sistema que se va a construir y también la elaboración de la validez y constancia de este modelo. las herramientas de análisis y diseño proporcionan al ingeniero del software un cierto grado de visión en lo tocante a la representación del análisis. iconos. Además. y le ayudan a eliminar errores antes de que se propaguen al diseño. estas herramientas califican los números locales frente a los valore medios de la industria (y frente al rendimiento local anterior) y sugieren estrategias para llegar a mejoras. a la propia implementación. capacitan al ingeniero del software para desarrollar simulaciones del sistema de tiempo real que permitirán al cliente obtener ideas acerca de su funcionamiento. o lo que es peor. comportamiento y respuesta antes de la verdadera implementación. Al efectuar una comprobación de la consistencia y validez del modelo. Martin Valencia Pág. estos conjuntos de herramientas se están viendo sustituidos por herramientas de generación de prototipos de interfaz que permiten una rápida creación en pantalla de sofisticadas interfaces de usuario. que se ajustan al estándar de interfaz que se haya adoptado para el software. arquitectura. así como caracterizaciones del diseño de datos. y herramientas de comprobación basadas en requisitos. Entre ellos podemos encontrar:  Herramientas de análisis y diseño (modelado): Las herramientas de análisis y diseño capacitan al ingeniero del software para crear modelos del sistema que haya que construir. Los modelos contienen una representación de los datos. Los lenguajes de comprobación especializados (por ejemplo: ATLAS) capacitan al ingeniero del software para escribir detalladas especificaciones de comprobación que describirán todos los casos de prueba y la logística de su ejecución.   HERRAMIENTAS DE INTEGRACION Y PRUEBA: Sirven de ayuda a la adquisición.. estructuras de ventanas. procedimientos e interfaz. Las herramientas de comprobación basadas en Lic.

un conjunto de reglas de descomposición que se aplicarían a todos los programas de una cierta zona de aplicación tal como el control de fabricación o la aviónica). Las herramientas intrusivas modifican el software que hay que comprobar mediante sondas que se insertan (instrucciones adicionales) y que efectúan las actividades mencionadas anteriormente. Las herramientas de comprobación no intrusivas utilizan un procesador hardware por separado que funciona en paralelo con el procesador que contenga el programa que se está comprobando. Martin Valencia Pág. Herramientas de análisis dinámico: Las herramientas de análisis dinámico interactúan con un programa que se esté ejecutando. comprueban las afirmaciones acerca del valor de variables especificas y en general instrumentan el flujo de ejecución del programa. Herramientas de reestructuración y análisis de código: se analiza la sintaxis del programa. Las herramientas de ingeniería inversa y progresiva de la próxima generación harán un uso mucho mayor de técnicas de inteligencia artificial. efectúan comparaciones que determinan las diferencia s entre la salida real y la esperada. pero seguirá requiriendo una interacción con un ingeniero de software a lo largo del ciclo de la reingeniería. El componente de inteligencia artificial asistirá en la descomposición y reconstrucción de los sistemas. Un controlador de comprobación lee uno o más casos de prueba de algún archivo de pruebas. Elaborados por: Lic. aplicando una base de conocimientos que se a especifica del dominio de la aplicación (esto es. Herramientas de comprobación clientes/servidor: El entorno C/S existe unas herramientas de comprobación especializadas que ejerciten la interfaz gráfica de usuario y los requisitos de comunicaciones en red para el cliente y el servidor. Herramientas de gestión de comprobación: Las herramientas de gestión de comprobación se utilizan para comprobar y coordinar la comprobación de software para cada uno de los pasos principales de comprobación. Muchas de las herramientas anteriores están limitadas a lenguajes de programación específicos (aun cuando se abarcan la mayoría de los lenguajes principales) y requieren un cierto grado de interacción con un ingeniero del software. se genera una gráfica de control de flujo y se genera automáticamente un programa estructurado. 97 . Además de las funciones indicadas anteriormente. da formato a los datos de prueba para que se ajusten a las necesidades del software que se está probando. bien no intrusivas. Herramientas de reingeniería para sistemas en línea: se utilizan para modificar sistemas de bases de datos en línea (por ejemplo: para convertir archivos IDMS o DB2 traduciéndolos a un formato de entidades y relaciones). Herramientas de reingeniería: La categoría de herramientas de reingeniería se pueden subdividir en las funciones siguientes: Herramientas de ingeniería inversa para producir especificaciones: se toma el código fuente como entrada y se generan modelos gráficos de análisis y diseño estructurados. y efectúan comprobaciones por lotes de programas con interfaces interactivas entre hombre y maquina. listos de utilización y otras informaciones de diseño.INSTITUTO TECNOLÓGICO DE JIQUILPAN Apuntes de Fundamentos de Desarrollo de Sistemas Ingeniería en Sistemas Computacionales Plan 2004        requisitos aíslan requisitos específicos del usuario y sugieren casos de prueba (o clases de comprobaciones) que ejerciten estos requisitos. e invoca entonces al software que sea preciso comprobar. Las herramientas dinámicas pueden ser bien intrusivas. muchas herramientas de gestión de comprobaciones sirven también como controladores de comprobación genéricos. comprueban la cobertura de rutas. Las herramientas de esta categoría administran y coordinan la comprobación de regresiones.

Relacionar el Sistema al mundo real. las herramientas de documentación suponen una oportunidad importante para mejorar la productividad. Por esta razón. 98 . Las herramientas deberían facilitar el modelamiento en términos de eventos. las herramientas de gestión de bases de datos para CASE pueden evolucionar a partir de los sistemas de gestión de bases de datos relacionales (SGBDR) para transformarse en sistemas de gestión de bases de datos orientadas a objetos (SGBDOO).2 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. y representan una importante oportunidad de aprovechamiento para todos los desarrolladores del software.INSTITUTO TECNOLÓGICO DE JIQUILPAN Apuntes de Fundamentos de Desarrollo de Sistemas Ingeniería en Sistemas Computacionales Plan 2004 HERRAMIENTAS DE SOPORTE: Se engloban en esta categoría las herramientas que recojan las actividades aplicables en todo el proceso de desarrollo. basados en repositorios que generan códigos. Dado el énfasis acerca de los objetos de configuración. el entorno CASE debe adaptase a un software de sistema en redes de alta calidad.2. estado de los objetos. triggers (iniciadores). a los boletines electrónicos y a otras capacidades de comunicaciones. Martin Valencia Pág. Herramientas de control de Calidad: La mayor parte de las herramientas CASE que afirman que tiene como principal interés el control de calidad son en realidad herramientas métricas que hace una auditoria del código fuente para determinar si es justa o no a ciertos estándares del lenguaje.2. Por tanto. 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. Otras herramientas extraen métricas técnicas como base para medir la calidad del software que se está construyendo. al correo electrónico. No es raro que una organización de desarrollo de software invierta hasta en un 20 o 30 pro ciento de su esfuerzo global de desarrollo de software en la documentación. y para utilizar objetos existentes adaptados en nuevas aplicaciones. Elaborados por: Lic. Herramientas para software de sistemas: CASE es una tecnología de estaciones de trabajo. Permite crear Sistemas más complejos. Las herramientas deberán ser diseñadas para estimular la máxima creatividad y continuo refinamiento del diseño durante la construcción. La mayor parte de las organizaciones dedicadas al desarrollo de software invierte una cantidad de tiempo considerable en el desarrollo de documentos. como las que se relacionan a continuación:  Herramientas de documentación: Las herramientas de producción de documentos y autoedición prestan su apoyo a casi todos los aspectos de la ingeniería del software. 5.    5. Herramientas gestión de base de datos: El software de gestión de bases de datos sirve como fundamentos para establecer una base de datos CASE.1 Estructuradas Las herramientas Case utilizarán técnicas gráficas para diseñar las clases y sus interacciones. Fomenta la reutilización y extensión del código. etc. y en muchos casos el proceso de documentación en si resulta bastante deficiente.

Los objetos se construyen fuera de los objetos.... El tiene un entendimiento del comportamiento de la caja negra y cómo comunicarse con ella. Técnicas para verificar y garantizar la operación correcta de una clase. Estabilidad.INSTITUTO TECNOLÓGICO DE JIQUILPAN Apuntes de Fundamentos de Desarrollo de Sistemas Ingeniería en Sistemas Computacionales Plan 2004 Facilita la creación de programas visuales. puedan ser observados. Confiabilidad. Construcción de Objetos de complejidad Creciente.. Elaborados por: Lic. 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.Las aplicaciones son creadas tomando componentes preexistentes..EL Software construido a partir de una librería de clases estables. deberían proporcionar librerías de clases para áreas específicas. es conseguir la reutilización masiva en la construcción de Software. Los componentes pueden ser vistos. para un diseño particular. Un repositorio debería ser cargado con una colección de clases reutilizables. Reutilización. Las clases son semejantes a las cajas negras.Las clases diseñadas para la reutilización repetida. respecto a construir Software desde el inicio. 99 .Las compañías de Software.. Una buena manera de fabricar es construir tomando una lista de materiales de partes y subpartes existentes. 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. probablemente estén disponibles en nuevas generaciones de herramientas CASE Orientadas a Objetos. es probable que se encuentre libre de errores. Diseño Rápido.. Verificación de Correcciones. Cada método en una clase es en sí mismo simple y diseñado para ser confiable. Para maximizar la reutilización las clases deben ser construidas de manera que puedan ser personalizadas. El Diseñador piensa de Comportamiento de Objeto. Esto posibilita construir componentes de Software complejos y los mismos se utilizarán para construir otros bloques de Software más complejos. Muchos componentes son construidos de tal forma que. personalizados. Nuevos Mercados de Software. Un objetivo permanente de las técnicas Orientadas a Objetos. Martin Valencia Pág. El encapsulamiento oculta los detalles y hace fácil el uso de clases complejas. puede generar potencialmente Software de alta confiabilidad.El Diseño Orientado a Objetos con técnica formal para la creación de métodos. fácilmente adaptables a las necesidades de la organización. no en Niveles de Detalle. El desarrollador utiliza la caja negra sin mirar su interior. La era de los paquetes monolíticos está siendo reemplazada por Software que incorpora clases y encapsula paquetes de diferentes vendedores.Las clases son diseñadas de tal manera que ellas puedan ser reutilizadas en muchos Sistemas. customizados y enlazados en la pantalla de la herramienta CASE.

En técnicas convencionales.. Con técnicas de Análisis.Las personas creativas cambian constantemente el diseño de su trabajo mientras se está implementando. El análisis se traslada directamente al diseño e implementación..Software de diferentes vendedores pueden trabajar juntos. el entorno del problema cambia cuando vamos del análisis al diseño y del diseño a la programación. Esto es particularmente importante en Sistemas distribuidos y Sistemas CLIENTE/SERVIDOR.Los programas de mantenimiento generalmente cambiarán los métodos correspondientes a una clase. Computación Cliente / Servidor.Implementadores hábiles en poderosas herramientas CASE Orientadas a Objetos laborando sobre estaciones de trabajo.. Martin Valencia Pág.Los objetivos de desarrollo de un Sistema. Diseño e Implementación Orientados a Objetos utiliza el mismo paradigma y lo refinan sucesivamente. Cada clase realiza sus operaciones independientemente de otras clases. Hardware o Software.Las estructuras de Datos pueden ser utilizadas solamente con métodos específicos. hacen los cambios durante el ciclo de vida rápidamente.Los diseños son a menudo de alta calidad.. La genialidad individual puede ser más creativa. Una clase Elaborados por: Lic.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. Las herramientas estimulan la creación e implementan las invenciones.Las clases son diseñadas independientemente de plataforma de operación.. a menudo cambian durante la implementación. manejadores de redes. Esto permite a los diseñadores de Sistemas satisfacer mejor a los usuarios finales.Se debería utilizar interfaces gráficas para usuarios. donde usuarios desconocidos pueden tratar de accesar al Sistema. deberían ser capaces de trabajar juntos y presentarse como una unidad simple al usuario.. Interoperactividad. encuentran que puede generar rápidamente muchas ideas. ya que ellos se construyen a partir de componentes que han sido aprobados y refinados repetidamente. Ciclo de Vida Dinámico.. son una y otra vez refinados. Modelamiento más realístico. Facilidad de Programación. 100 . La Interoperactividad de Software de diferentes vendedores es uno de los objetivos más importantes de los estándares de la Orientación a Objetos. Un vendedor puede utilizar clase de otros vendedores. Las clases emplean requerimientos y respuestas de forma. adaptarse a los cambios. Creatividad.. Refinamiento durante la Construcción. Esto permite que ellos sean utilizados con múltiples Sistemas operativos.Los programas son construidos utilizando pequeñas plazas de Software las cuales son generalmente fáciles de crear. etc. Esto conduce a más y mejores resultados. interfaces gráficas para usuarios. Software desarrollado independientemente en lugares separados. Las herramientas CASE Orientadas a Objetos proporcionan a los constructores de Software la capacidad para refinar el diseño durante la implementación. refinar los objetivos y mejorar constantemente el diseño durante la implementación... tal que ésta apunte al icono que relacione al objeto. Fácil Mantenimiento. las clases en el Software cliente deberían enviar sus requerimientos a las clases de Software servidor y recibir respuestas. DBMS. Los trabajos creativos objetivos.INSTITUTO TECNOLÓGICO DE JIQUILPAN Apuntes de Fundamentos de Desarrollo de Sistemas Ingeniería en Sistemas Computacionales Plan 2004 Diseño de Alta Calidad.En el Sistema Cliente / Servidor. Integridad... Interface Gráfica Seductiva al Usuario. Las herramientas CASE Orientadas a Objetos. Independencia de Diseño.

Las herramientas deberán ser diseñadas para estimular la máxima creatividad y continuo refinamiento del diseño durante la construcción. Mejores herramientas CASE... Los diferentes beneficios afectan a diferentes desarrolladores de diversas maneras. Martin Valencia Pág.. serán también importantes y éstas serán proporcionadas como facilidades de herramientas CASE (VIC). Examinaremos los beneficios percibidos por: Un Inventor. Alto Nivel de Automatización de Bases de datos..El inventor de Software requiere el conjunto de herramientas del CASE Orientadas a Objetos.Existiendo o no aplicaciones orientadas a objetos..INSTITUTO TECNOLÓGICO DE JIQUILPAN Apuntes de Fundamentos de Desarrollo de Sistemas Ingeniería en Sistemas Computacionales Plan 2004 servidor puede ser utilizada por muchos clientes. Migración. Ellas envían y reciben mensajes en formatos estándares. Las bases de datos Orientados a Objetos. Emplearán servidores de Base de Datos concurrentes y orientadas al objeto. Computación Paralela. estado de los objetos. es la clave para la computación masivamente distribuida. Librerías de Clases Corporativas. La identificación TOP-DOWN de los OBJETOS del negocio. Las librerías de clases independientes de las aplicaciones. es un aspecto importante de la ingeniería de la Información.Las estructuras en Base de Datos OO.Las compañías de Software comercializarán librerías para diferentes áreas de aplicación. ellos pueden ser preservados convenientemente con una cobertura Orientada a Objetos. un chip puede tener muchos procesadores). Las herramientas deberían facilitar el modelamiento en términos de eventos. 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. comunicándose entre ellos mediante mensajes estándares Orientados a Objetos. tiene su inteligencia construida en la forma de métodos. etc.Redes alrededor del mundo emplearán directorios de Software de objetos accesibles. crearán sus propias librerías de clases que reflejen sus estándares internos y requerimientos de aplicación.Las corporaciones. sin necesidad de saber dónde residen. cada uno de ellos actuando independientemente.. 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. Industriales de Librerías de Clases. mientras que otras bases de datos no. Elaborados por: Lic. pueden ser ampliamente mejoradas mediante la instalación de computadoras en paralelo. para generar códigos tan rápidos como él sobre la pantalla. Objetos en diferentes procesadores se ejecutarán simultáneamente.La velocidad de las máquinas. Se pueden tener procesamientos simultáneos y concurrentes en múltiples chips de procesadores (eventualmente.. triggers (iniciadores). Performance de Máquinas. y para utilizar objetos existentes adaptados en nuevas aplicaciones.. Esto puede accesar al Software únicamente a través de los métodos (así los datos se protegen de corrupciones).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. El diseño orientado al objeto. Computación masivamente Distribuida. Una Base de Datos OO. están ligadas a métodos que toman acciones automáticas. Las clases en una máquina interactuarán con cualquier otra..Las herramientas Case utilizarán técnicas gráficas para diseñar las clases y sus interacciones. 101 .

. es buscar que los Software de los diferentes vendedores trabajen juntos. Un problema mayúsculo. el profesional considera los siguientes factores:      Problemas no estructurados. donde la inversión involucra gran cantidad de recursos financieros y humanos. donde no está dispuesta examinar modelos en papel. Altos riesgo. la falta de experiencia en el uso de dichas tecnologías. de información personalizada del usuario. Jefe de Informática. Martin Valencia Pág.Para crear productos ricos e interesantes.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. 2. Construir Software tomando componentes (clases) que ya existen. novedosos y complejos.3 Desarrollo de Prototipos Para decidir si el prototipo debe incluirse o no Ciclo de Desarrollo de Sistema de Información. Problemas de ambiente Inestable. Experiencia en diseños similares. junto con el deseo de instalar nuevas tecnología hace que sea propicio el uso del prototipo. el fabricante de Software requiere incorporar Software de otros vendedores en sus propios diseños.. tan fielmente como sean posibles. 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. 5.Un integrador de Sistemas tiene que ver con:    Construcción del Sistema de Redes. Crear clases modificadas utilizando herencia que les permite reutilizar métodos y estructuras de datos de clases de nivel superior.El objetivo es ensamblar aplicaciones de alta calidad tomando partes reutilizables y utilizando un generador para todo código nuevo. Un Integrador de Sistemas. Máquinas y Software de diferentes vendedores.INSTITUTO TECNOLÓGICO DE JIQUILPAN Apuntes de Fundamentos de Desarrollo de Sistemas Ingeniería en Sistemas Computacionales Plan 2004 Fábrica de Software. Tecnologías Nuevas..     Elaborados por: Lic. Uno de los beneficios más importantes de la Orientación a Objetos es su nivel de reutilización. Un Equipo de Proyecto de Sistemas de Información. Las técnicas Orientadas a Objetos permiten alcanzar la reutilización de dos maneras: 1. la evaluación inexacta de los requerimientos o el desarrollo incorrecto ponen en peligro a la organización. el profesional también debe evaluar el contexto del Sistema. se conocen los requerimientos aparentes de información pero es necesario verificarlos y evaluarlos Costos altos. No se conocen los requerimientos. El usuario. Los requerimientos deben evaluarse. o no sabe lo que quiere pero lo reconocerá cuando lo vea.. 102 . ya que sus salidas no son predecibles y definidas.

o características esenciales y determina el propósito del prototipo de la aplicación.INSTITUTO TECNOLÓGICO DE JIQUILPAN Apuntes de Fundamentos de Desarrollo de Sistemas Ingeniería en Sistemas Computacionales Plan 2004 Etapas del Prototipo. El profesional de Sistema para construcción inicial del prototipo emplea cualquier herramienta. o también la eliminación de características innecesarias. la cual se presenta modificada. como Lenguajes de Cuarta Generación. generales. 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 más no traerá beneficios adicionales. Es responsabilidad del usuario trabajar con el prototipo y evaluar sus características y operación. identifica los requerimientos conocidos. 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. Iteración. 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 captura la información sobre lo que le gusta y lo que le desagrada a los usuarios. refinada. Martin Valencia Pág. Esta información tiene influencia en la siguiente versión del prototipo. Generadores de Pantallas En el desarrollo de un prototipo se preparan los siguientes componentes:     El lenguaje para el diálogo o conversación entre el usuario y el Sistema Pantallas y formatos para la entrada de datos Módulos esenciales de procesamientos 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. El profesional de Sistema en esta etapa. La experiencia con el Sistema bajo condiciones reales permite la familiaridad indispensable para determinar los cambios o mejoras que sean necesarios. 103 . Generadores de Reportes. Prototipo Terminado. Desarrollo de un Modelo. El desarrollo de un prototipo se lleva a cabo en forma ordenada a través de las siguientes etapas: Identificación de Requerimientos Conocidos. Elaborados por: Lic. Revisión del Prototipo.

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: Elaborados por:  Aspectos conceptuales Lic. 2006). vehículos. 2006):  Beneficios tácticos de ingeniería: .INSTITUTO TECNOLÓGICO DE JIQUILPAN Apuntes de Fundamentos de Desarrollo de Sistemas Ingeniería en Sistemas Computacionales Plan 2004 Cuando el prototipo está terminado.Reducción en el costo promedio de producción de los productos .  Asume la existencia de una industria de partes Definición: Se refieren a técnicas de ingeniería para crear un portafolio de Sistemas de Software similares. Diseño y Arquitectura de Productos de Software. La idea básica:  Ensamblaje de partes de Software previamente elaboradas. aparatos electrónicos.Reducción de las tasas de defectos. usando un medio común de producción” (Krueger. Beneficios: La entrega de productos de Software de una manera más rápida. computadores.  Producción de aviones. tenemos la información que buscamos seguimos en el punto donde habíamos quedado dentro del Ciclo de Desarrollo de Sistema. 104 . . etc. 2002). es decir. económica y con una mejor calidad.Tamaño del portafolio de productos.Tiempo de entrega del producto (time to market) . . .Costos de ingeniería. 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. a partir de un conjunto compartido de activos de Software.Reducción en el esfuerzo promedio requerido para desarrollar y mantener los productos . Martin Valencia Pág. Consiste de una familia de Sistemas de Software que tienen una funcionalidad común y alguna funcionalidad variable” (Gomma.  Fundamentada en la Reutilización de Software.Calidad de los productos.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 .  Inspirada en los procesos de producción de Sistemas físicos.  Las LPS producen mejoras en: .  Beneficios tácticos y estratégicos (Krueger. 2004).

105 .INSTITUTO TECNOLÓGICO DE JIQUILPAN Apuntes de Fundamentos de Desarrollo de Sistemas Ingeniería en Sistemas Computacionales Plan 2004 - 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 UNIDAD VI: DISEÑO Y ARQUITECTURA DE PRODUCTOS DE SOFTWARE. Martin Valencia Pág. Descomposición Modular DESCOMPOSICION MODULAR Elaborados por: Lic.

Identificar los módulos 2. se emplea una zona común de datos a la que tienen acceso varios módulos. Martin Valencia Pág. El grado de acoplamiento mide la interrelación entre dos módulos. cuando desde un módulo se puede cambiar datos locales de otro. Cohesión 4. reducción de costos y reutilización Los pasos a seguir son: 1.Por contenido. pero por lo general se tiende a que el acoplamiento sea lo menor posible. Acoplamiento 3. 106 . esto es a reducir las interconexiones entre los distintos módulos en que se estructure nuestra aplicación. 1. .INSTITUTO TECNOLÓGICO DE JIQUILPAN Apuntes de Fundamentos de Desarrollo de Sistemas Ingeniería en Sistemas Computacionales Plan 2004 El diseño modular propone dividir el Sistema en partes diferenciadas y definir sus interfaces. Moderado . Para medir la independencia funcional hay dos criterios: acoplamiento y cohesión b) Acoplamiento El acoplamiento es una medida de la interconexión entre módulos en la estructura del programa. Adaptabilidad a) Independencia funcional Cada módulo debe realizar una función concreta o un conjunto de funciones afines. sus ventajas: claridad. esto implica que un cambio en el formato de datos los afecta a todos. según el tipo de conexión y la complejidad de la interface: Fuerte . Es recomendable reducir las relaciones entre módulos al mínimo. Elaborados por: Lic. Comprensibilidad 5.Común. Describir las relaciones entre módulos Una descomposición modular debe poseer ciertas cualidades mínimas para que se pueda considerar suficientemente válida. la zona común es un dispositivo externo al que estan ligados los módulos.De control. Describir cada módulo 3. Independencia funcional 2. Podemos graduar en un amplio espectro.

árbol. los elementos del módulo trabajan de forma secuencial Cohesión de comunicación. se agrupan elementos que se ejecutan en el mismo momento. se agrupan elementos que realizan funciones similares.De datos. Todos los errores). . Podemos decir que un módulo coherente es aquel que intenta realizar solamente una cosa. Para que n° de módulos no sea demasiado elevado y complique el diseño se tratan de agrupar elementos afines y relacionados en un mismo módulo. pila. será temporal o secuencial . Cohesión lógica. . Martin Valencia Pág.INSTITUTO TECNOLÓGICO DE JIQUILPAN Apuntes de Fundamentos de Desarrollo de Sistemas Ingeniería en Sistemas Computacionales Plan 2004 .Por etiqueta. 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 contiene expresiones secuenciales (primero. el módulo realiza una función concreta y específica  MEDIA Cohesión secuencial. Ej.Sin acoplamiento directo. viene dado por los datos que intercambian los módulos.  ALTA Cohesión abstraccional. entonces. cuando…).…) Débil . Cohesión coincidental. Es el mejor. 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. se logra cuando se diseña el módulo como tipo abstracto de datos o como una clase de objetos Cohesión funcional. 107 . grafo.Si es una frase compuesta y contiene más de un verbo la cohesión será MEDIA . cohesión lógica Elaborados por: Lic. en intercambio de datos se realiza mediante una referencia a la estructura completa de datos(vector. Arrancar o parar dispositivos  BAJA . elementos que operan con el mismo conjunto de datos de entrada o de salida Cohesión temporal.Si la descripción no se refiere a algo específico (Ej.

d) Comprensibilidad Para facilitar los cambios. La distribución soportada es. después de cualquier adaptación se debe mantener la consistencia del Sistema. y cuando el diseño es poco comprensible. con alto acoplamiento y baja cohesión.SIMPLICIDAD. intraorganizacional. al mismo tiempo. No hay distinción entre un proveedor de servicios y el usuario de estos servicios. pero la distribución de las aplicaciones generalmente tiene lugar dentro de una única organización. Es necesario comprender las ventajas y desventajas de las diferentes arquitecturas de sistemas distribuidos.Previsión. pero además es deseable: .Si aparece “inicializar”. 108 . debe aclarar todos los detalles de diseño e implementación que no queden de manifiesto en el propio código . Para esta arquitectura no hay distinción entre servidores y clientes. es decir. es necesario prever que aspectos del Sistema pueden ser susceptibles de cambios en el futuro. y el sistema puede ser visto como un conjunto de objetos que interaccionan cuya localización es irrelevante. debe resultar sencillo el acceso a los documentos de especificación. por lo tanto.INSTITUTO TECNOLÓGICO DE JIQUILPAN Apuntes de Fundamentos de Desarrollo de Sistemas Ingeniería en Sistemas Computacionales Plan 2004 . diseño. el mantenimiento y la reutilización de módulos es necesario que cada uno sea comprensible de forma aislada. las soluciones sencillas son siempre las mejores e) Adaptabilidad La adaptación de un Sistema resulta más difícil cuando no hay independencia funcional. “preparar”.2 Arquitectura de dominio específico. Otros factores para facilitar la adaptabilidad: . incluidos los documentos afectados 6. Arquitecturas de objetos distribuidos.Consistencia. “configurar”.Identificación. Para ello es bueno que posea independencia funcional. Martin Valencia Pág. Aquí se tratan dos tipos genéricos de arquitecturas de sistemas distribuidos: Arquitectura cliente-servidor. e implementación para obtener un conocimiento suficiente del Sistema antes de proceder a su adaptación. de manera que su modificación afecte al menor número de módulos posibles. 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. El reto para el diseño es diseñar el software y hardware para proporcionar características deseables a los sistemas distribuidos y. minimizar los problemas propios a estos sistemas. -Accesibilidad. También se pueden tomar dos tipos más de arquitecturas distribuidas que son más Elaborados por: Lic. probablemente sea temporal. Ambas arquitecturas se usan ampliamente en la industria.Documentación. . y poner estos elementos en módulos independientes. el nombre debe ser adecuado y descriptivo .

se ubica en medio de los diferentes componentes distribuidos del sistema. El reto para el diseño es diseñar el Software y Hardware para proporcionar Características deseables a los Sistemas distribuidos y. La Arquitectura de Software constituye una disciplina de reciente aparición y forma parte del paradigma de la Ingeniería del Software. 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. Tal Sistema puede ser utilizado como un elemento en un Sistema más grande. Los sistemas peer-to-peer han sido usados principalmente para sistemas personales. Bernstein (Bernstein. las propiedades visibles externas de dichos componentes y las relaciones entre ellos. interacciones entre esos elementos. Clements y Kazman 1998). Representa la versión moderna de un diseño Software y es apta para describir Sistemas complejos.INSTITUTO TECNOLÓGICO DE JIQUILPAN Apuntes de Fundamentos de Desarrollo de Sistemas Ingeniería en Sistemas Computacionales Plan 2004 adecuadas para la distribución interorganizacional: arquitectura de sistemas peer-to-peer (p2p) y arquitecturas orientadas a servicios. 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. Definición: Arquitectura de Software  “Una arquitectura de Software es un conjunto de elementos arquitectónicos que tiene una determinada forma. 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. Los sistemas distribuidos se desarrollan normalmente utilizando una aproximación orientada a objetos. En general. Un sistema distribuido. Martin Valencia Pág. requiere software que pueda gestionar estas partes distintas. Algunas partes del sistema pueden tener que responder a eventos independientes. Los modelos de datos. pero están comenzando a usarse para aplicaciones de empresa. la representación de la información y los protocolos de comunicación pueden ser todos diferentes. un Sistema de Software particular se define en términos de una colección de componentes e interacciones entre dichos componentes. patrones que guían la composición y restricciones sobre esos patrones. El término middleware se usa para hacer referencia a ese software.”(Garlan y Shaw 1996) “Una arquitectura de Software de un programa o Sistema de computación es la estructura o estructuras del Sistema. Los objetos software reflejan estas características. por lo tanto. Es necesario comprender las ventajas y desventajas de las diferentes arquitecturas de Elaborados por: Lic. por lo tanto. y asegurar que dichas partes se puedan comunicar e intercambiar datos. Ejemplos de middleware son software para gestionar comunicaciones con bases de datos. el cual comprende componentes. Los componentes en un sistema distribuido pueden implementarse en diferentes lenguajes de programación y pueden ejecutarse en tipos de procesadores completamente diferentes. 109 . al mismo tiempo. administradores de transacciones.” (Perry y Wolf 1992)   “Una arquitectura de Software incluye la descripción de elementos a partir de los cuales se constituyen los Sistemas de Software. 1996) resume los tipos de middleware disponibles para soportar computación distribuida. son abstracciones naturales para los componentes de sistemas distribuidos.”(Bass. convertidores de datos y controladores de comunicación. minimizar los problemas propios a estos Sistemas.

pero la distribución de las aplicaciones generalmente tiene lugar dentro de una única organización. por lo tanto.2. Arquitecturas de objetos distribuidos. la representación de la información y los protocolos de comunicación pueden ser todos diferentes. Los Sistemas distribuidos se desarrollan normalmente utilizando una aproximación orientada a objetos. y el Sistema puede ser visto como un conjunto de objetos que interaccionan cuya localización es irrelevante. convertidores de datos y controladores de comunicación. Martin Valencia Pág.1 Diseño de Software de Arquitectura Multiprocesador Un Sistema multiproceso o multitarea es aquel que permite ejecutar varios procesos de forma concurrente. 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. 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. Diseño de Software de Arquitectura Multiprocesador 6. La distribución soportada es. cada una de las cuales puede interaccionar directamente con los usuarios o con otras partes del Sistema. Ambas arquitecturas se usan ampliamente en la industria.INSTITUTO TECNOLÓGICO DE JIQUILPAN Apuntes de Fundamentos de Desarrollo de Sistemas Ingeniería en Sistemas Computacionales Plan 2004 Sistemas distribuidos. No hay distinción entre un proveedor de servicios y el usuario de estos servicios. Los modelos de datos. Un Sistema distribuido. 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. La ventaja de un Sistema multiproceso reside en la operación llamada cambio de contexto. 110 . interorganizacional. 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 componentes en un Sistema distribuido pueden implementarse en diferentes lenguajes de programación y pueden ejecutarse en tipos de procesadores completamente diferentes. Para esta arquitectura no hay distinción entre servidores y clientes. y asegurar que dichas partes se puedan comunicar e intercambiar datos. 1996) resume los tipos de middleware disponibles para soportar computación distribuida. ejecutar otro proceso y volver a colocar el primero sin que se entere de nada. Los Sistemas peer-to-peer han sido usados principalmente para Sistemas personales. en un Sistema distribuido. se ubica en medio de los diferentes componentes distribuidos del Sistema. Los objetos Software reflejan estas características. Elaborados por: Lic. la razón es porque actualmente la mayoría de las CPU’s sólo pueden ejecutar un proceso cada vez. Los servidores y los clientes se tratan de forma diferente en estos Sistemas. por lo tanto. Ejemplos de middleware son Software para gestionar comunicaciones con bases de datos. Bernstein (Bernstein. pero están comenzando a usarse para aplicaciones de empresa. Estos Sistemas están formados por partes independientes pobremente integradas. Algunas partes del Sistema pueden tener que responder a eventos independientes. administradores de transacciones. Esta operación consiste en quitar a un proceso de la CPU. Aquí se tratan dos tipos genéricos de arquitecturas de Sistemas distribuidos: Arquitectura cliente-servidor. El término middleware se usa para hacer referencia a ese Software. por lo tanto. requiere Software que pueda gestionar estas partes distintas. son abstracciones naturales para los componentes de Sistemas distribuidos.

Ventajas • Es económica. • Adicionalmente. Un ejemplo de este tipo de Sistema se muestra en la figura 6. la organización del código de las propias aplicaciones. 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. Un conjunto de tareas puede ser completado más rápidamente si hay varias unidades de proceso ejecutándolas en paralelo. 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.INSTITUTO TECNOLÓGICO DE JIQUILPAN Apuntes de Fundamentos de Desarrollo de Sistemas Ingeniería en Sistemas Computacionales Plan 2004 El multiproceso no es algo difícil de entender: más procesadores significa más potencia computacional. permite ofrecer mayor rendimiento. Desventajas • En ocasiones se menciona también la limitante física. Si más de un procesador está disponible. Se configuran dos computadoras de gran capacidad interconectados electrónicamente entre si. El enfoque de diseño para este tipo de Sistemas es esencialmente el mismo que para los de tiempo real. las computadoras paralelas son inherentemente escalables. 111 . En este ejemplo existen varios procesos lógicos para administrar los sensores. Elaborados por: Lic. pero los diseñadores del Sistema no siempre consideran lo puntos de distribución durante el proceso de diseño. Estos procesos lógicos son procesos sencillos a un grupo de procesos. permitiendo actualizarlas para adecuarlas a una necesidad creciente. así como los lenguajes de programación. independientemente del factor económico. Martin Valencia Pág. 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). en grandes cantidades. • Las arquitecturas “tradicionales” se actualizan haciendo los procesadores existentes obsoletos por la introducción de nueva tecnología a un costo posiblemente elevado. pero otra historia es la práctica. 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. Éste es un modelo sencillo de un Sistema de control de tráfico aéreo. es necesario modificar varias facetas del Sistema operativo. lo que requiere unos profundos conocimientos tanto del Hardware como del Software. • El uso de componentes comúnmente disponibles. una arquitectura paralela se puede actualizar en términos de rendimiento simplemente agregando más procesadores. el cuarto de control y las luces de tráfico. Es necesario conocer ampliamente como están interconectados dichos procesadores. Los Sistemas de Software compuestos de procesos múltiples no necesariamente son Sistemas distribuidos. Por otro lado. Para lograrlo. En este ejemplo se ejecutan en procesadores diferentes. entonces se puede implementar la distribución. existen factores que limitan la velocidad máxima de un procesador. Esa es la teoría. como hacer funcionar el multiproceso.3. Los operadores toman decisiones utilizando esta información y dan instrucciones a un proceso de control de diversas luces de tráfico.

Por lo general. puede conectase a varios servidores a la vez. y espera hasta que el servidor de respuesta. restringen la capacidad máxima de un Sistema Uniprocesador. Martin Valencia Pág. Escalabilidad: Se puede aumentar la capacidad de clientes y servidores por separado. desempeñan entonces un papel pasivo en la comunicación (dispositivo esclavo).  La congestión del tráfico (a mayor número de clientes. Fácil mantenimiento Desventajas. Sus características son:     Al iniciarse esperan a que lleguen las solicitudes de los clientes. tales como la velocidad de la luz. Ventajas. Tras la recepción de una solicitud. Normalmente interactúa directamente con los usuarios finales mediante una interfaz gráfica de usuario. El funcionamiento básico de este modelo consiste en que un programa cliente realiza peticiones a un programa servidor. 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.    Centralización del control: Los accesos.2 Diseño de Software de 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.2. 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. y problemas causados por fenómenos eléctricos a pequeñas escalas. 112 Elaborados por: . 6. dejando la opción obvia de colocar muchos procesadores para realizar cálculos cooperativamente. tienen por tanto un papel activo en la comunicación (dispositivo maestro o amo). 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. Características de un cliente En la arquitectura C/S el remitente de una solicitud es conocido como cliente. efectos cuánticos al reducir el tamaño de los elementos de los procesadores. Lic. Espera y recibe las respuestas del servidor. la procesan y luego envían la respuesta al cliente.INSTITUTO TECNOLÓGICO DE JIQUILPAN Apuntes de Fundamentos de Desarrollo de Sistemas Ingeniería en Sistemas Computacionales Plan 2004 • Barreras físicas infranqueables. Por lo general. Características de un servidor En los Sistemas C/S el receptor de la solicitud enviada por cliente se conoce como servidor. más problemas para el servidor). Sus características son:     Es quien inicia solicitudes o peticiones.

Los sistemas distribuidos se implementan en diversas plataformas hardware. El abanico se extiende desde componentes hardware como discos e impresoras hasta elementos software como ficheros. Las aplicaciones de los sistemas distribuidos varían desde la provisión de capacidad de computo a grupos de usuarios. Se trata de compartición de recursos. Este software permite a los ordenadores coordinar sus actividades y compartir los recursos del sistema . El término 'recurso' es bastante abstracto. concurrencia. la disponibilidad de computadoras personales de altas prestaciones. Características clave de los sistemas distribuidos. seguridad contra interferencias externas y privacidad de la información que el sistema mantiene. [ Colouris 1994 ] El desarrollo de los sistemas distribuidos vino de la mano de las redes locales de alta velocidad a principios de 1970. Elaborados por: Lic. hasta Internet. tolerancia a fallos y transparencia. Un Hardware regular de un ordenador personal puede no poder servir a cierta cantidad de clientes. estaciones de trabajo y ordenadores servidores ha resultado en un mayor desplazamiento hacia los sistemas distribuidos en detrimento de los ordenadores centralizados multiusuario. Esta tendencia se ha acelerado por el desarrollo de software para sistemas distribuidos. pero es el que mejor caracteriza el abanico de entidades que pueden compartirse en un sistema distribuido. Los requisitos de dichas aplicaciones incluyen un alto nivel de fiabilidad.2. diseñado para soportar el desarrollo de aplicaciones distribuidas. desde unas pocas estaciones de trabajo conectadas por una red de área local. ventanas. para satisfacer el trabajo. comunicaciones multimedia y abarcan prácticamente todas las aplicaciones comerciales y técnicas de los ordenadores. escalabilidad.INSTITUTO TECNOLÓGICO DE JIQUILPAN Apuntes de Fundamentos de Desarrollo de Sistemas Ingeniería en Sistemas Computacionales Plan 2004  El Software y el Hardware de un servidor son generalmente muy determinantes. Un sistema distribuido se define como una colección de computadores autónomos conectados por una red. esto aumentará el costo 6. Se deben proveer accesos concurrentes a bases de datos por parte de muchos usuarios. Martin Valencia Pág. [Colouris 1994] establece que son seis las características principales responsables de la utilidad de los sistemas distribuidos. apertura (openness). potencial para el crecimiento del sistema para acomodar la expansión del negocio y un marco para la integración de sistema usados por diferentes compañías y organizaciones de usuarios. software y datos. Más recientemente. Compartición de Recursos. que en lazan millones de ordenadores. y con el software distribuido adecuado para que el sistema sea visto por los usuarios como una única entidad capaz de proporcionar facilidades de computación. Normalmente se necesita Software y Hardware específico. proveer puntos de acceso al servicio que están distribuidos geográficamente. bases de datos y otros objetos de datos. una colección de redes de área local y de área extensa interconectados. sobre todo en el lado del servidor. garantizar tiempos de respuesta. 113 . En las siguientes líneas trataremos de abordar cada una de ellas. hasta sistemas bancarios. Por supuesto.3 Diseño de Software Distribuido Introducción.hardware.

Los sistemas distribuidos abiertos se basan en la provisión de un mecanismo uniforme de comunicación entre procesos e interfaces publicados para acceder a recursos compartidos. Por el contrario. manipulado y actualizado de una manera fiable y consistente. Cada tipo de recurso requiere algunas políticas y métodos específicos junto con requisitos comunes para todos ellos. ) o con respecto a las extensiones software ( añadir características al sistema operativo. Sin embargo. los usuarios de estaciones de trabajo monousuario o computadoras personales dentro de un sistema distribuido no obtienen automáticamente los beneficios de la compartición de recursos. memoria o interfaces de comunicación. la traslación de nombre de recurso a direcciones de comunicación y la coordinación de los accesos concurrentes que cambian el estado de los recursos compartidos para mantener la consistencia. Los usuarios de los recursos se comunican con los gestores de los recursos para acceder a los recursos compartidos del sistema. Un sistema distribuido puede verse de manera abstracta como un conjunto de gestores de recursos y un conjunto de programas que usan los recursos. protocolos de comunicación y servicios de compartición de recursos. Los sistemas distribuidos abiertos pueden construirse a partir de hardware y software heterogéneo. Los sistemas multiusuario clásicos desde siempre han provisto compartición de recursos entre sus usuarios. permitir que los recursos individuales sean accedidos desde cualquier localización. Un sistema puede ser abierto o cerrado con respecto a extensiones hardware (añadir periféricos. Martin Valencia Pág. posiblemente proveniente de vendedores diferentes. Esta perspectiva nos lleva a dos modelos de sistemas distribuidos: el modelo cliente-servidor y el modelo basado en objetos. ésta debe ser manejada por un programa que ofrezca un interfaz de comunicación permitiendo que el recurso sea accedido. En una palabra. ). Básicamente los sistemas distribuidos cumplen una serie de características: 1.INSTITUTO TECNOLÓGICO DE JIQUILPAN Apuntes de Fundamentos de Desarrollo de Sistemas Ingeniería en Sistemas Computacionales Plan 2004 La idea de compartición de recursos no es nueva ni aparece en el marco de los sistemas distribuidos. los recursos de una computadora multiusuario se comparten de manera natural entre todos sus usuarios.. etc. Éstos incluyen la provisión de un esquema de nombres para cada clase de recurso. Para que la compartición de recursos sea efectiva. Cuando existen varios procesos en una única maquina decimos que se están ejecutando concurrentemente. etc. Pero la conformidad de cada componente con el estándar publicado debe ser cuidadosamente comprobada y certificada si se quiere evitar tener problemas de integración.. 2. Los interfaces software clave del sistema están claramente especificados y se ponen a disposición de los desarrolladores.. 3. Apertura (opennesss). Los recursos en un sistema distribuido están físicamente encapsulados en una de las computadoras y sólo pueden ser accedidos por otras computadoras mediante las comunicaciones (la red). La apertura de los sistemas distribuidos se determina primariamente por el grado hacia el que nuevos servicios de compartición de recursos se pueden añadir sin perjudicar ni duplicar a los ya existentes. Concurrencia. Surge el término genérico de gestor de recursos. los interfaces se hacen públicos. Un gestor de recursos es un módulo software que maneja un conjunto de recursos de un tipo en particular. Si el ordenador está equipado con un único procesador central. la concurrencia tiene lugar entrelazando la Elaborados por: Lic. Un sistema informático es abierto si el sistema puede ser extendido de diversas maneras.. 114 .

Muchos usuarios interactúan simultáneamente con programas de aplicación. Entonces. 2. Estos procesos se ejecutan en distintas máquinas. La sincronización debe ser cuidadosamente planeada para asegurar que no se pierden los beneficios de la concurrencia. si hay M ordenadores en un sistema distribuido con un procesador central cada una entonces hasta M procesos estar ejecutándose en paralelo. debería ser posible extender el sistema para darla servicio. de manera que se están ejecutando en paralelo diversos servidores. Tanto el software de sistema como el de aplicación no deberían cambiar cuando la escala del sistema se incrementa. La demanda de escalabilidad en los sistemas distribuidos ha conducido a una filosofía de diseño en que cualquier recurso simple -hardware o software. El caso (2) surge debido a la existencia de uno o más procesos servidores para cada tipo de recurso. 115 . ya que normalmente las aplicaciones de interacción se ejecutan aisladamente en la estación de trabajo del usuario y no entran en conflicto con las aplicaciones ejecutadas en las estaciones de trabajo de otros usuarios. Cuando esto ocurre los procesos servidores deben sincronizar sus acciones para asegurarse de que no existen conflictos. la posibilidad de ejecución paralela ocurre por dos razones: 1. y éstas podrían contener muchos miles de ordenadores que forman un único sistema distribuido. la frecuencia con la que se accede a los ficheros crece cuando se incrementa el número de usuarios y estaciones de trabajo en un sistema distribuido. si la demanda de un recurso crece. Escalabilidad. El diseño del sistema debe reconocer explícitamente la necesidad de escalabilidad o de lo contrario aparecerán serias limitaciones.INSTITUTO TECNOLÓGICO DE JIQUILPAN Apuntes de Fundamentos de Desarrollo de Sistemas Ingeniería en Sistemas Computacionales Plan 2004 ejecución de los distintos procesos. cada una con uno o más procesadores centrales. Martin Valencia Pág.puede extenderse para proporcionar servicio a tantos usuarios como se quiera. En los sistemas distribuidos hay muchas máquinas. Si la computadora tiene N procesadores. entonces se pueden estar ejecutando estrictamente a la vez hasta N procesos. Muchos procesos servidores se ejecutan concurrentemente. varios servidores de ficheros. servidores de impresión y otros servidores de propósito específico. sino que está íntimamente ligada con todos los aspectos del diseño de los sistemas distribuidos. Esto es. Es decir. La necesidad de escalabilidad no es solo un problema de prestaciones de red o de hardware. Los sistemas distribuidos operan de manera efectiva y eficiente a muchas escalas diferentes. La escala más pequeña consiste en dos estaciones de trabajo y un servidor de ficheros. En un sistema distribuido que está basado en el modelo de compartición de recursos. A menudo se conectan varias redes de área local para formar internet. cada uno respondiendo a diferentes peticiones de los procesos clientes. El caso (1) es menos conflictivo. mientras que un sistema distribuido construido alrededor de una red de área local simple podría contener varios cientos de estaciones de trabajo. Por ejemplo. Las peticiones para acceder a los recursos de un servidor dado pueden ser encoladas en el servidor y ser procesadas secuencialmente o bien pueden ser procesadas varias concurrentemente por múltiples instancias del proceso gestor de recursos. debe ser posible añadir ordenadores servidores para evitar el cuello de botella que se produciría si un solo servidor Elaborados por: Lic. permitiendo que los recursos sean compartidos entre todos ellos. junto con diversos programas de aplicación.

Un fallo simple en una maquina multiusuario resulta en la no disponibilidad del sistema para todos los usuarios. La recuperación del software tiene relación con el diseño de software que sea capaz de recuperar (rollback) el estado de los datos permanentes antes de que se produjera el fallo. Cuando se producen fallos en el software o en el hardware. Los sistemas distribuidos también proveen un alto grado de disponibilidad en la vertiente de fallos hardware. Martin Valencia Pág. de manera que el sistema se percibe como un todo. aprovechando la concurrencia para permitir una mayor productividad. Una explicación completa de estas técnicas puede encontrarse en [ Colouris 1994 ]. Cuando uno de los componentes de un sistema distribuidos falla. Un usuario podría desplazarse a otra estación de trabajo. solo se ve afectado el trabajo que estaba realizando el componente averiado. 116 Elaborados por: . y el uso de múltiples servidores para manejar ciertas tareas. La transparencia se define como la ocultación al usuario y al programador de aplicaciones de la separación de los componentes de un sistema distribuido.INSTITUTO TECNOLÓGICO DE JIQUILPAN Apuntes de Fundamentos de Desarrollo de Sistemas Ingeniería en Sistemas Computacionales Plan 2004 de ficheros tuviera que manejar todas las peticiones de acceso a los ficheros. complementarias entre sí: Redundancia hardware (uso de componentes redundantes) y recuperación del software (diseño de programas que sean capaces de recuperarse de los fallos). Estas proveen un resumen útil de la motivación y metas de los sistemas distribuidos. Lic. un proceso servidor podría ejecutarse en otra máquina. Transparencia. la técnica asociada de caching. en vez de una colección de componentes independientes. En este caso el sistema deberá estar diseñado de manera que permita trabajar con ficheros replicados en distintos servidores. Las transparencias definidas son:  Transparencia de Acceso: Permite el acceso a los objetos de información remotos de la misma forma que a los objetos de información locales. Tolerancia a Fallos. La disponibilidad de un sistema es una medida de la proporción de tiempo que está disponible para su uso. Los sistemas informáticos a veces fallan. Las técnicas necesarias para conseguir estos objetivos incluyen el uso de datos replicados. el trabajo necesario para procesar una petición simple para acceder a un recurso compartido debería ser prácticamente independiente del tamaño de la red. pueden replicarse los servidores individuales que son esenciales para la operación continuada de aplicaciones críticas. La transparencia ejerce una gran influencia en el diseño del software de sistema. los programas podrían producir resultados incorrectos o podrían pararse antes de terminar la computación que estaban realizando. Cuando el tamaño y complejidad de las redes de ordenadores crece. El manual de referencia RM-ODP [ISO 1996a] identifica ocho formas de transparencia. es un objetivo primordial diseñar software de sistema distribuido que seguirá siendo eficiente y útil con esas nuevas configuraciones de la red. con las consideraciones de consistencias que ello conlleva. El diseño de sistemas tolerantes a fallos se basa en dos cuestiones. Resumiendo. En los sistemas distribuidos la redundancia puede plantearse en un grano más fino que el hardware.

el Software de tiempo real debe responder al ámbito del problema en un tiempo dictado por el ámbito del problema. optimizar el gasto de gasolina de nuestras últimas generaciones de coches y programar a nuestros aparatos. su presencia o ausencia afecta fuertemente a la utilización de los recursos distribuidos. Transparencia de Escalado: Permite la expansión del sistema y de las aplicaciones sin cambiar la estructura del sistema o los algoritmos de la aplicación. La transparencia de red provee un grado similar de anonimato en los recursos al que se encuentra en los sistemas centralizados. Martin Valencia debe reaccionar a eventos generados emitir señales de control como respuesta Elaborados por: Pág. 117 . El Software de tiempo real está muy acoplado con el mundo externo. Todas estas interacciones con las computadoras sean útiles o intrusivas son ejemplos de computación de tiempo real. el tiempo es la esencia de la interacción Las computadoras se utilizan para controlar una amplia variedad de sistemas que van desde máquinas domésticas sencillas hasta plantas enteras de fabricación.INSTITUTO TECNOLÓGICO DE JIQUILPAN Apuntes de Fundamentos de Desarrollo de Sistemas Ingeniería en Sistemas Computacionales Plan 2004        Transparencia de Localización: Permite el acceso a los objetos de información sin conocimiento de su localización Transparencia de Concurrencia: Permite que varios procesos operen concurrentemente utilizando objetos de información compartidos y de forma que no exista interferencia entre ellos. A menudo se las denomina a ambas transparencias de red.4 Diseño de Software de Tiempo Real. por los requisitos de la aplicación y tanto por los extras del lenguaje de programación como prospectos de diseño. La computadora está controlando algo que interactúa con la realidad sobre una base de tiempo de hecho. esto es. Lic. La computadora digital se ha convertido en una maquina omnipresente en al vida diaria de todos nosotros. Transparencia de Prestaciones: Permite que el sistema sea reconfigurado para mejorar las prestaciones mientras la carga varia.2. Debido a que el Software de tiempo real debe operar bajo restricciones de rendimiento muy rigurosas. el diseño del Software esta conducido frecuentemente. Transparencia de Replicación: Permite utilizar múltiples instancias de los objetos de información para incrementar la fiabilidad y las prestaciones sin que los usuarios o los programas de aplicación tengan por que conoces la existencia de las réplicas. así como contar el tiempo. Transparencia de Migración: Permite el movimiento de objetos de información dentro de un sistema sin afectar a los usuarios o a los programas de aplicación. Transparencia de Fallos: Permite a los usuarios y programas de aplicación completar sus tareas a pesar de la ocurrencia de fallos en el hardware o en el software. tanto por la arquitectura del Hardware como por la del Software. Las computadoras nos permiten ver juegos. Las dos más importantes son las transparencias de acceso y de localización. El software de dichos tiemporeal por a sistemas es software de el embebido que hardware y estos eventos. por las características del Sistema operativo. 6.

Martin Valencia Pág. software de del cuyo los instante correcto funcionamiento resultados producidos por el de tiempo en el que se producen estos Elaborados por: Lic. 118 .INSTITUTO TECNOLÓGICO DE JIQUILPAN Apuntes de Fundamentos de Desarrollo de Sistemas Ingeniería en Sistemas Computacionales Plan 2004 Sistema de tiempo real Sistema de depende mismo y resultados.

119 .INSTITUTO TECNOLÓGICO DE JIQUILPAN Apuntes de Fundamentos de Desarrollo de Sistemas Ingeniería en Sistemas Computacionales Plan 2004 Sistema de tiempo real blando (software) Es un sistema cuyo funcionamiento se degrada si los resultados no se producen de acuerdo con los requerimientos temporales especificados. Martin Valencia Pág. Elaborados por: Lic.

120 . Elaborados por: Lic. Martin Valencia Pág.INSTITUTO TECNOLÓGICO DE JIQUILPAN Apuntes de Fundamentos de Desarrollo de Sistemas Ingeniería en Sistemas Computacionales Plan 2004 Sistema de tiempo real duro (hardware) Es un sistema resultados no se cuyo funcionamiento es incorrecto si los producen de acuerdo con la especificación temporal.

pero. 121 . una respuesta muy rápida. Martin Valencia Pág. en algunos casos. no es Elaborados por: Lic.INSTITUTO TECNOLÓGICO DE JIQUILPAN Apuntes de Fundamentos de Desarrollo de Sistemas Ingeniería en Sistemas Computacionales Plan 2004 Una respuesta a tiempo es un factor importante en todos los necesaria sistemas embebidos.

Ocurren de forma irregular.Ocurren a intervalos de tiempo predecibles. 122 . Martin Valencia Pág. Estímulos aperiódicos.. 2. Estímulos periódicos.. Elaborados por: Lic.INSTITUTO TECNOLÓGICO DE JIQUILPAN Apuntes de Fundamentos de Desarrollo de Sistemas Ingeniería en Sistemas Computacionales Plan 2004 Estímulos asociados a sistema de tiempo real 1.

123 . Martin Valencia procesos concurrentes que Pág. Los sistemas de tiempo real se diseñan como un conjunto de cooperan entre sí. Elaborados por: Lic.INSTITUTO TECNOLÓGICO DE JIQUILPAN Apuntes de Fundamentos de Desarrollo de Sistemas Ingeniería en Sistemas Computacionales Plan 2004 Un sistema de tiempo real tiene que responder a estímulos que ocurren en diferentes instantes de tiempo.

Martin Valencia Pág. Elaborados por: Lic. 124 . y debería ser posible predecir duración de operaciones particulares realizadas en estos lenguajes.INSTITUTO TECNOLÓGICO DE JIQUILPAN Apuntes de Fundamentos de Desarrollo de Sistemas Ingeniería en Sistemas Computacionales Plan 2004 Los lenguajes de programación desarrollados al la para sistemas de tiempo real tienen que incluir facilidades para acceder hardware del sistema.

125 .INSTITUTO TECNOLÓGICO DE JIQUILPAN Apuntes de Fundamentos de Desarrollo de Sistemas Ingeniería en Sistemas Computacionales Plan 2004 Diseño del sistema Parte del proceso de diseño implica decidir qué capacidades del implementarse en hardware. sistema software tie y Elaborados por: Lic. Martin Valencia Pág.

Martin Valencia Pág. 126 . Elaborados por: Lic.INSTITUTO TECNOLÓGICO DE JIQUILPAN Apuntes de Fundamentos de Desarrollo de Sistemas Ingeniería en Sistemas Computacionales Plan 2004 Los eventos (estímulos) deberían ser elementos centrales del proceso de diseño de software de tiempo real en lugar de los objetos o funciones.

Identificar los estímulos 2. 127 .INSTITUTO TECNOLÓGICO DE JIQUILPAN Apuntes de Fundamentos de Desarrollo de Sistemas Ingeniería en Sistemas Computacionales Plan 2004 Etapas en el proceso de diseño: 1. Procesamiento de estímulos y respuestas a procesos concurrentes 5. Elegir una plataforma de ejecución para el sistema 4. Martin Valencia Pág. Diseñar algoritmos para llevar a cabo los cálculos Elaborados por: Lic. Identificar las restricciones temporales 3.

128 . Diseñar un sistema de planificación de procesos Elaborados por: Lic.INSTITUTO TECNOLÓGICO DE JIQUILPAN Apuntes de Fundamentos de Desarrollo de Sistemas Ingeniería en Sistemas Computacionales Plan 2004 6. Martin Valencia Pág.

INSTITUTO TECNOLÓGICO DE JIQUILPAN Apuntes de Fundamentos de Desarrollo de Sistemas Ingeniería en Sistemas Computacionales Plan 2004 El orden de estas actividades de de en el proceso esté desarrollando y de los depende del tipo requerimientos sistema que se su proceso y plataforma. Martin Valencia Pág. Elaborados por: Lic. 129 .

INSTITUTO TECNOLÓGICO DE JIQUILPAN Apuntes de Fundamentos de Desarrollo de Sistemas Ingeniería en Sistemas Computacionales Plan 2004 Los procesos en un sistema de tiempo real tienen que coordinarse. 130 . Elaborados por: Lic. Martin Valencia Pág.

131 .INSTITUTO TECNOLÓGICO DE JIQUILPAN Apuntes de Fundamentos de Desarrollo de Sistemas Ingeniería en Sistemas Computacionales Plan 2004 El análisis temporal para sistemas de tiempo real es difícil. Elaborados por: Lic. Martin Valencia Pág.

Martin Valencia Pág. 132 .INSTITUTO TECNOLÓGICO DE JIQUILPAN Apuntes de Fundamentos de Desarrollo de Sistemas Ingeniería en Sistemas Computacionales Plan 2004 Modelado de sistemas de tiempo real Los sistemas de tiempo real deben responder a eventos irregulares. que tienen lugar a intervalos Elaborados por: Lic.

133 . el modelado de máquina de estados se utiliza a menudo para modelar sistemas de tiempo real.INSTITUTO TECNOLÓGICO DE JIQUILPAN Apuntes de Fundamentos de Desarrollo de Sistemas Ingeniería en Sistemas Computacionales Plan 2004 Estos eventos (o estímulos) a menudo hacen que el sistema cambie a un estado diferente. Martin Valencia Pág. Elaborados por: Lic. por esta razón.

Martin Valencia Pág. en cualquier momento. 134 . Cuando se recibe puede producir una transición a un estado diferente. modelo de estadosde un sistema supone en uno de un estímulo. el sistema está varios estadosposibles.INSTITUTO TECNOLÓGICO DE JIQUILPAN Apuntes de Fundamentos de Desarrollo de Sistemas Ingeniería en Sistemas Computacionales Plan 2004 Un que. éste Elaborados por: Lic.

Martin Valencia Pág. incluso hasta lossistemas embebidos trabajan hoy en día conjuntamente con operativo de tiempo real (RTOS) más un sencillos.INSTITUTO TECNOLÓGICO DE JIQUILPAN Apuntes de Fundamentos de Desarrollo de Sistemas Ingeniería en Sistemas Computacionales Plan 2004 Sistemas operativos de tiempo real Todos los sistemas de tiempo real. sistema Elaborados por: Lic. 135 .

Martin Valencia Pág. Lanza y detiene los estímulos puedan ser manejados y recursos del procesador. Elaborados por: Lic.INSTITUTO TECNOLÓGICO DE JIQUILPAN Apuntes de Fundamentos de Desarrollo de Sistemas Ingeniería en Sistemas Computacionales Plan 2004 Un los sistema operativo de tiempo real gestiona en un sistema los procesos para asigna memoria y de que procesos y asignación de recursos tiempo real. 136 .

Martin Valencia Pág.INSTITUTO TECNOLÓGICO DE JIQUILPAN Apuntes de Fundamentos de Desarrollo de Sistemas Ingeniería en Sistemas Computacionales Plan 2004 Los componentes de un RTOS dependen sistema de del tiempo real que se esté desarrollando. tamañoy complejidad del Elaborados por: Lic. 137 .

Un despachador Elaborados por: Lic. Un reloj de tiempo real 2. Un planificador 4. Martin Valencia Pág. Un gestor de recursos 5.INSTITUTO TECNOLÓGICO DE JIQUILPAN Apuntes de Fundamentos de Desarrollo de Sistemas Ingeniería en Sistemas Computacionales Plan 2004 Los sistemas de tiempo real incluyen: 1. 138 . Un manejador de interrupciones 3.

INSTITUTO TECNOLÓGICO DE JIQUILPAN Apuntes de Fundamentos de Desarrollo de Sistemas Ingeniería en Sistemas Computacionales Plan 2004 Componentes de tiempo real: un sistema operativo de Elaborados por: Lic. 139 . Martin Valencia Pág.

140 . de que y llevan monitorización y control comprueban los proporcionan información sobre el entorno a cabo acciones dependiendo de del la Elaborados por: Lic.INSTITUTO TECNOLÓGICO DE JIQUILPAN Apuntes de Fundamentos de Desarrollo de Sistemas Ingeniería en Sistemas Computacionales Plan 2004 Sistemas de monitorización y control Los sistemas sensores sistema lectura del sensor. Martin Valencia Pág.

141 . Martin Valencia Pág. Elaborados por: Lic. Los sistemas de control controlan continuamentelos actuadores hardware dependiendo del valor de los sensores asociados.INSTITUTO TECNOLÓGICO DE JIQUILPAN Apuntes de Fundamentos de Desarrollo de Sistemas Ingeniería en Sistemas Computacionales Plan 2004 Los sistemas de monitorización realizan una acción cuando se detecta algún valor excepcional del sensor.

Elaborados por: Lic. 142 .INSTITUTO TECNOLÓGICO DE JIQUILPAN Apuntes de Fundamentos de Desarrollo de Sistemas Ingeniería en Sistemas Computacionales Plan 2004 El proceso de diseño comienza identificando los estímulos aperiódicos que recibe el sistema y sus respuestas asociadas. Martin Valencia Pág.

INSTITUTO TECNOLÓGICO DE JIQUILPAN Apuntes de Fundamentos de Desarrollo de Sistemas Ingeniería en Sistemas Computacionales Plan 2004

Sistemas de adquisición de datos

Los

sistemas para

de su

adquisición de datos posterior procesamiento y análisis.

recogen datos de

sensores

Elaborados por:

Lic. Martin Valencia

Pág. 143

INSTITUTO TECNOLÓGICO DE JIQUILPAN Apuntes de Fundamentos de Desarrollo de Sistemas Ingeniería en Sistemas Computacionales Plan 2004

Los

sistemas

de

adquisición

de

datos se

usan y sistemas de físicos, tales como control de una

normalmente en experimentos científicos procesos en los que los procesos reacción química, ocurren muy rápidamente.

Elaborados por:

Lic. Martin Valencia

Pág. 144

INSTITUTO TECNOLÓGICO DE JIQUILPAN Apuntes de Fundamentos de Desarrollo de Sistemas Ingeniería en Sistemas Computacionales Plan 2004

En

los

sistemas

de

adquisición

de

datos, los problema

sensores pueden estar principal es

generando datos muy rápidamente, el asegurar que una lectura del sensor es recogida antes.

Elaborados por:

Lic. Martin Valencia

Pág. 145

INSTITUTO TECNOLÓGICO DE JIQUILPAN Apuntes de Fundamentos de Desarrollo de Sistemas Ingeniería en Sistemas Computacionales Plan 2004 Puntos clave Un los sistema sistema software en tiempo resultados que el que de que real. Martin Valencia Pág. se real debe responder Su corrección no sólo produce sino también producen tiempo es a depende del momento dichos resultados. un eventos de en Elaborados por: Lic. 146 .

También procesos adicionales de coordinación. 147 . Martin Valencia Pág.INSTITUTO TECNOLÓGICO DE JIQUILPAN Apuntes de Fundamentos de Desarrollo de Sistemas Ingeniería en Sistemas Computacionales Plan 2004 Un modelo generalpara la arquitectura de asociar un proceso con cada clase de se requieren sistemas de tiempo real implica el dispositivo sensor y actuador. Elaborados por: Lic.

Martin Valencia Pág. Elaborados por: Lic.INSTITUTO TECNOLÓGICO DE JIQUILPAN Apuntes de Fundamentos de Desarrollo de Sistemas Ingeniería en Sistemas Computacionales Plan 2004 El diseño arquitectónico de un sistema de del sistema tiempo real implica como un conjunto normalmente la organización de procesos concurrentes que interactúan. 148 .

INSTITUTO TECNOLÓGICO DE JIQUILPAN Apuntes de Fundamentos de Desarrollo de Sistemas Ingeniería en Sistemas Computacionales Plan 2004 Un sistema operativo de tiempo real es los recursos. Martin Valencia Pág. 149 . Siempre responsable de responsable del proceso y la gestión de incluye un planificador. Elaborados por: Lic. que es el componente decidir qué proceso debería seleccionarse para su ejecución.

INSTITUTO TECNOLÓGICO DE JIQUILPAN Apuntes de Fundamentos de Desarrollo de Sistemas Ingeniería en Sistemas Computacionales Plan 2004 Los sistemas de monitorización y control consultan periódicamente información del entorno del sistema. y envían órdenes a los Elaborados por: Lic. los sensores. Martin Valencia Pág. Éstos dependiendo de las lecturas de actuadores. 150 . un conjunto de sensores que captan llevan a cabo acciones.

INSTITUTO TECNOLÓGICO DE JIQUILPAN Fundamentos de Desarrollo de Sistemas Ingeniería en Sistemas Computacionales Plan 2004 Los sistemas de adquisición de datos se modelo productor-consumidor. los datos en un consumidos búfer también se eliminar los conflictos organizan normalmente según un El proceso productor coloca búfer circular. desde donde son por el proceso consumidor. 151 . Recopilación de Información: Lic. Estas computadoras interactúan directamente con dispositivos de hardware. El implementa como un proceso para entre el productor y el consumidor. Martin Valencia Pág.

es/docencia/barzana/IAGP/IAGP2-Ingenieria-Software-introduccion. Ediciones Contabilidad Moderna S.A. Hermida.um. Percy Reyes Paredes Recopilación de Información: Lic. Yourdon. Ediciones Larousse. Héctor Felipe. Alvarez.com Fecha: 13/Jul/2005 (07/07/2005) Autor: A. una introducción al estudio de la Administración. Jorge A. Ciencia de la administración. carpeta del año 1994 curso 1k8.INSTITUTO TECNOLÓGICO DE JIQUILPAN Fundamentos de Desarrollo de Sistemas Ingeniería en Sistemas Computacionales Plan 2004 BIBLIOGRAFIA CONSULTADA Fotocopias y apuntes facilitados por la cátedra.A. Pequeño Larousse Ilustrado (diccionario).html Blog: http://percyreyes.C.blogspot. Prentice-Hall Panamericana. México 1989. 152 . Córdoba 1987. Martin Valencia Pág. Edward. Francia 1977. Buenos Aires mayo de 1983. S. Sociedad para Estudios Pedagógicos Argentinos. http://www.I. Análisis estructurado moderno. Estructura de las Organizaciones. Ramón García-Pelayo y Gross. Administración.

Sign up to vote on this title
UsefulNot useful