P. 1
Apuntes de Fundamentos de Desarrollo de Sistemas 2011 Bueno

Apuntes de Fundamentos de Desarrollo de Sistemas 2011 Bueno

|Views: 5.666|Likes:
Publicado porMartin Valencia

More info:

Published by: Martin Valencia on Sep 30, 2011
Copyright:Attribution Non-commercial

Availability:

Read on Scribd mobile: iPhone, iPad and Android.
download as DOCX, PDF, TXT or read online from Scribd
See more
See less

05/12/2013

pdf

text

original

Sections

  • 1.1.1 Descripción General de Sistemas:
  • 1.1.2 Tipos de Sistemas
  • 1.1.3 Clasificación
  • 1.2.1 Planificación y Gestión del Proyecto
  • 1.2.2 Determinación de Requerimientos
  • 1.2.3 Análisis y Diseño
  • 1.2.4 Programación
  • 1.2.5 Prueba e Implantación
  • 2.1 Definición de Ingeniería de Software
  • 2.2 Historia de la Ingeniería del Software
  • 2.3 Características del Software
  • 2.4 Mitos del Software:
  • 2.5 Capas de la Ingeniería del Software
  • 2.6 El Proceso del Software
  • 2.7 Software de Alta Calidad
  • 2.8 Factores de Calidad y productividad
  • 3.1.1 Diagramas de Flujo de Datos
  • 3.1.2 Diccionario de datos
  • 3.1.3 Diseño de Módulos
  • 3.1.4 Descomposición En Procesos
  • 3.2.1 Análisis
  • 3.2.2 Diseño
  • 4.1 Modelo de Cascada:
  • 4.2 Modelo de Espiral:
  • 4.3 Modelo Incremental:
  • 4.4Proceso de Desarrollo Unificado:
  • 4.5 Proceso Software Personal:
  • 5.1.1 Entrevista:
  • 5.1.2 Cuestionario
  • 5.1.3 Recopilación y Análisis de Documentos
  • 5.1.4 Observación y Técnica “STROBE”
  • 5.2.1 Estructuradas
  • 5.2.2 Herramientas CASE Orientadas a Objetos
  • 5.3 Desarrollo de Prototipos
  • 6.2.1 Diseño de Software de Arquitectura Multiprocesador
  • 6.2.2 Diseño de Software de Arquitectura Cliente/Servidor
  • 6.2.3 Diseño de Software Distribuido
  • 6.2.4 Diseño de Software de Tiempo Real

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

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

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

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

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

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

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

Martin Valencia Pág. 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. estructura estática. 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. Quinto nivel. Se caracteriza por su creciente movilidad. En este nivel se comienza a diferenciar la vida. Está caracterizado por las plantas. comportamiento teleológico y su autoconciencia. 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. 3. 6. Sexto nivel. Considera movimientos necesarios y predeterminados. Cuarto nivel. proceso o características en la medida que el medio se lo exige y es estático cuando el medio también lo es. Se le puede llamar nivel de los marcos de referencia. Elaborados por: Lic. 10 .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). El Sistema se autorregula para mantener su equilibrio. Segundo nivel. Tercer nivel. La falta de éxito exige una revisión del Sistema ya que no cumple con los objetivos propuestos para el mismo. Sistema dinámico simple. Puede de considerarse nivel de célula. 2. Primer nivel. Sistema animal. 4. Un Sistema altamente armónico es aquel que sufre modificaciones en su estructura. “Sistema abierto” o autoestructurado. Éxito: El éxito de los Sistemas es la medida en que los mismos alcanzan sus objetivos. Armonía: Es la propiedad de los Sistemas que mide el nivel de compatibilidad con su medio o contexto. mecanismo de control o Sistema cibernético. Se puede denominar reloj de trabajo. 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. Suboptimización en cambio es el proceso inverso. genético-social.

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

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

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

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

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

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

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

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

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

No se cuenta con un manual del usuario. El Sistema sólo contiene datos crudos. las propiedades de los Sistemas proveen una manera sencilla de separar un Sistema de otro. Algunos ejemplos de Sistemas simples se podrán encontrar aquí. Los nuevos usuarios son capacitados mediante una demostración que dura media hora. y sus propiedades.1. 1 Clasificación de Sistemas de Información. 1. Martin Valencia Pág.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. así como de procesamiento digital de señales (Digital Signal Processing) DSP. Clasificación de los Sistemas A través de la siguiente clasificación. Entender la diferencia básica entre Sistemas. uno ya no tiene que proveer ciertas características del Sistema cada vez. permitiendo a los usuarios una gran flexibilidad para agregarlos y analizarlos para satisfacer sus necesidades. Como puede ser visto. Una vez que el conjunto de señales puede ser identificado por compartir propiedades particulares.-Artificiales: Sistemas creados por el hombre.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). también es importante entender otras Clasificaciones de Señales y se clasifican de la siguiente forma. será un concepto fundamental utilizado en todos los cursos de señales y Sistemas. y la experiencia ha demostrado que es todo lo que necesitan. El Sistema es operado por medio de un menú muy fácil de usar. a) Por su naturaleza: b) Naturales: Sistemas creados en los que el hombre no interviene en su creación. 20 . pero pueden ser aceptadas debido a la clasificación de los Sistemas. 1. c) Por su relación con el Medio Ambiente: Elaborados por: Lic. Fig.

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

mientras que el Sistema influye débilmente en el Medio Ambiente. Elaborados por: Lic. 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. 4). 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.2 Ciclo de Vida de un proyecto de Software. Los analistas. con frecuencia. diseñadores y usuarios realizan para desarrollar e implantar un Sistema de información. a la que denominan diseño físico. El método del ciclo de vida para el desarrollo de Sistemas consta de 6 fases: 1). 2). 22 . del tiempo disponible para escribir el Software y de la disponibilidad de los programadores. Los especialistas en Sistemas se refieren. El Medio Ambiente influye en forma determinante en el Sistema. al trabajar con los empleados y administradores. Martin Valencia Pág. que funciona de acuerdo con las especificaciones y en la forma en que los usuarios esperan que lo haga. el Sistema se emplea de manera experimental para asegurarse de que el Software no tenga fallas. Investigación Preliminar: La solicitud para recibir ayuda de un Sistema de información puede originarse por varias razones: sin importar cuales sean estas. a esta etapa como diseño lógico en contraste con la del desarrollo del Software. La elección depende del costo de cada alternativa. Prueba de Sistemas: Durante la prueba de Sistemas. El método de ciclo de vida para el desarrollo de Sistemas es el conjunto de actividades que los analistas.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. Por lo general. revisarse y ajustarse a los cambios para poder lograr sus objetivos. el proceso se inicia siempre con la petición de una persona. 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). Desarrollo del Software: Los encargados de desarrollar Software pueden instalar Software comprobando a terceros o escribir programas diseñados a la medida del solicitante. 5). es decir. los programadores que trabajan en las grandes organizaciones pertenecen a un grupo permanente de profesionales. 1.

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

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

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

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

y Software administrativo. Conjunto de actividades encaminadas a obtener las características necesarias que deberá poseer el nuevo Sistema. para comprender cómo trabaja y dónde es necesario efectuar mejoras o cambios considerables. TECNICAS DE SEGUIMIENTO: Las herramientas más usadas. Rentabilidad. 27    Elaborados por: . Los reportes deben dar fe de: Progreso. Recursos Humanos y Recursos Materiales entre otros. ya que esto debe ser decidido en la etapa de diseño por los diseñadores. es el estudio de un Sistema. en la Gestión de Proyectos son reuniones. Conviene que todo el equipo envíe reportes del grado de avance de sus tareas y actividades. para solventar el problema. que afectan en una forma indirecta al producto. se debe tener cuidado en la identificación de los causantes del retraso. Tiempos. de calidad. revisiones. Otros tipos de limitaciones externas. y cómo debe realizar sus funciones. Riesgos. Problemas.2 Determinación de Requerimientos. el mantenimiento. Martin Valencia Pág. TOMA DE DECISIONES: Después de ver en que se falla hay que tomar decisiones. Se omite el cómo debe lograrse su implementación. reportes. de la manera más sencilla y eficaz de entender. el testeo. para conocer el estado del proyecto. actividad o proceso. especifica algo sobre el propio Sistema.  Un requerimiento funcional puede ser una descripción de lo que un Sistema debe hacer. Costes. Algunos ejemplos de aspectos solicitables son la disponibilidad. pues a veces se esconden detrás de otros. etc. 1. etc.. Lic. Un requerimiento no funcional: de rendimiento. 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. la facilidad de uso.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. Este tipo de requerimiento específica algo que el Sistema entregado debe ser capaz de realizar. 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. Alcance.2. Calidad.

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

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. Cuando los analistas estudian Sistemas para un departamento también deben evaluar las implicaciones. 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. La recepción del pedido ilustra la importancia de considerar las ramificaciones de un tipo de actividad para el resto de las organizaciones. 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. LO QUE NO ES EL ANÁLISIS DE SISTEMAS No es profesional en mantenimiento de computadores. 29 .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. No es especialista en redes.2. Algunas veces los Sistemas abarcan los trabajos de varios deptos. También se denomina análisis de Sistemas a una de las etapas de construcción de un Sistema informático. Martin Valencia Pág. que consiste en relevar la información actual y proponer los rasgos generales de la solución futura. sin embargo deben tener conocimientos de cualquier requerimiento en cualquier otra parte de la organización. Elaborados por: Lic. No es desarrollador de Hardware. ¿QUÉ ES EL ANÁLISIS DE SISTEMAS? Ciencia encargada del análisis de Sistemas grandes y complejos y la interacción entre esos Sistemas. Esta área se encuentra muy relacionada con la Investigación de operaciones.3 Análisis y Diseño. Por consiguiente el trabajo hecho en un depto. No es un ensamblador de computadores. 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. Afecta al de los otros.

qué. El diseño lógico se convierte en parte en la especificación funcional que se usa en el diseño físico. con el propósito de mejorar los procesos de una organización. 30 Elaborados por: . 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. en ocasiones varios de ellos al mismo tiempo. Muchas mejoras incluyen un mayor apoyo a las funciones de negocios a través del uso de Sistemas de información computarizados. El analista debe tener la capacidad de trabajar con todo tipo de gente y contar con suficiente experiencia en computadoras. El diseño lógico es independiente de la tecnología. 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. El diseño lógico refina. qué tareas o reglas se pueden aplicar Manejar excepciones. de tal manera que se obtenga quién. experto en soporte técnico y agente de cambio.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. 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. realizar entrevistas. 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. Un objeto de negocios es la encapsulación de un servicio que abstrae las cualidades esenciales de algo de interés. cuándo. Un servicio debe satisfacer lo siguiente:    Ser seguro. El analista desempeña diversos roles. encuestas y/o visitas a los usuarios. Un servicio es una unidad con capacidad de cómputo. lo que equivale a un uso correcto y con autorización Ser válido. organiza y detalla la solución de negocios y define formalmente las reglas y políticas específicas de negocios. informando al cliente Lic. Martin Valencia Pág. Los tres roles principales del analista de Sistemas son el de consultor. dónde y por qué de la solución.

Martin Valencia Pág. Una interface tiene las siguientes partes:      Nombre Precondiciones. 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. También se puede emplear la técnica sujeto-verbo-objeto directo. 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. lo que debe estar presente antes de ejecutarse Postcondiciones. pseudocódigo. 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. estado final Capacidad o funcionalidad (SQL. 31 . sucesos o condiciones que permitan la realización de tareas de negocios coordinadamente o transaccionalmente.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. 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.

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. aplicaciones. 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. formación de un conjunto de resultados) Inserción. servicios de negocio y servicios de datos. Establecer una conexión involucra: una identificación. aislada (otras transacciones ocurren antes o después) y durable (una vez completada. acceso indexado. operaciones. maneja todos los aspectos de la interacción con la aplicación. 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. la colocación y provisión de datos. Martin Valencia Pág. a múltiples unidades de recuperación. bases de datos heterogéneas. Bloqueo (permite al acceso concurrente a los datos) Validación de datos (verifica la integridad del dominio. transaccional. Un servicio de usuario son personas. optimización y ejecución de solicitudes. Generalmente involucra una interfase gráfica de usuario (GUI) o pude ser no visual (mensajes o funciones). triggers y gateways para verificar el estado de los datos antes de aceptarlos. Elaborados por: Lic. manejo de errores) Seguridad (acceso seguro a los objetos. Los servicios de usuario (user services) controlan la interacción. otros servicios o la combinación de éstos. 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). según la topologías de la red). APIs) Respaldo y recuperación (recuperación de datos si un evento falla) Búsqueda y Lectura (búsquedas. El objetivo central es minimizar el esfuerzo de conocimiento requerido para interpretar la información. Los tres niveles son: servicios de usuario. Distribución de datos (Distribuye información. Una transacción es atómica (ocurre o no). consistente (preserva integridad). el tipo de interacción (conversacional. compilación. 32 . actualización y borrado (procesar modificaciones consistentemente transaccional). 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. multiusuario. SQL.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. tiempo de sesión. ésta sobrevive). monousuario). tipos. 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.

es decir.a la entrada antes de continuar con cualquier proceso. 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. o Debugging – crear una versión para limpiar errores. 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. sin duplicar código). o Protección integral de transacciones de negocios – los errores deben regresarse al componente que llama. El diseño con el manejo de errores y prueba de eventos: o Validando los parámetros.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. 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. Elaborados por: Lic. 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. Martin Valencia Pág. o Protegiendo datos importantes – contar con una excepción a la mitad de la actuación en las bases de datos. El componente es la unidad de construcción elemental del diseño físico. liberar objetos sincronizados o memoria. 33 . o Protegiendo recursos críticos –manejar excepciones para evitar la falla o terminación sin cerrar archivos.

Un extracto de datos es una copia de toda o una porción de la base de datos maestra. 34 . 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. No se permite la actualización. Se usa un timestamp o etiqueta de tiempo para indicar qué tan viejos son los datos. Los datos centralizados equivalen a una base de datos maestra ubicada en un lugar central. una partición. En una partición horizontal cada hilera existe en una sola base de datos. No hay copias de los datos. Una partición de datos es una segmentación de la base de datos maestra. Martin Valencia Pág. No hay sobreposición entre particiones. 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. En una partición vertical cada columna es contenida en una y solo una base de datos. Es útil cuando los datos se pueden fragmentar fácilmente y actualizarse en un sitio local con cambios frecuentes. un extracto o una réplica.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.

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. el Sistema se emplea de manera experimental para asegurarse de que el Software no tenga fallas. incluyendo su facilidad de uso. Por consiguiente. 1. Martin Valencia Pág. entrenar a los usuarios. 35 Elaborados por: . Desarrollo del Software: Los encargados de desarrollar Software pueden instalar Software comprobando a terceros o escribir programas diseñados a la medida del solicitante.2. La elección depende del costo de cada alternativa. La elección depende del costo de cada alternativa. del tiempo disponible para escribir el Software y de la disponibilidad de los programadores. tiempo de respuesta. Por lo general.4 Programación. Sin embargo. El diseño físico está íntimamente ligado a una alternativa tecnológica. La evaluación de un Sistema se lleva a cabo para identificar puntos débiles y fuertes. Por lo general.5 Prueba e Implantación Durante la prueba de Sistemas. es decir. Una vez instaladas. 1. del tiempo disponible para escribir el Software y de la disponibilidad de los programadores. incluso el ambiente es diferente con el paso de las semanas y los meses. es indudable que debe darse mantenimiento a las aplicaciones. los programadores que trabajan en las grandes organizaciones pertenecen a un grupo permanente de profesionales. confiabilidad global y nivel de utilización. los programadores que trabajan en las grandes organizaciones pertenecen a un grupo permanente de profesionales.2. que funciona de acuerdo con las especificaciones y en la forma en que los usuarios esperan que lo haga. instalar la aplicación y construir todos los archivos de datos necesarios para utilizarla. 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 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. por lo que debe de haber sincronización entre ambas. lo adecuado de los formatos de información. Lic.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. Se alimentan como entradas conjunto de datos de prueba para su procesamiento y después se examinan los resultados. Los encargados de desarrollar Software pueden instalar Software comprobando a terceros o escribir programas diseñados a la medida del solicitante. Implantación y evaluación La implantación es el proceso de verificar e instalar nuevo equipo. 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    Impacto organizacional: Identificación y medición de los beneficios para la organización en áreas tales como finanzas. 36 . Elaborados por: Lic. tales como constantes de compiladores. Desempeño del desarrollo: La evaluación de proceso de desarrollo de acuerdo con criterios tales como tiempo y esfuerzo de desarrollo. 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. También se incluye la valoración de los métodos y herramientas utilizados en el desarrollo. eficiencia operacional e impacto competitivo. Martin Valencia Pág. internacional con derechos. concuerdan con presupuestos y estándares. y otros criterios de administración de proyectos. Sistemas operativos o desarrollos de Internet. 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. que ofrece métodos o técnicas para desarrollar y mantener Software de calidad que resuelven problemas de todo tipo. También se incluye el impacto sobre el flujo de información externo e interno.1 Definición de Ingeniería de Software Es una disciplina o área de la información o ciencias de la computación. laboral. La Ingeniería del Software trata de áreas muy diversas de la informática y de las ciencias computacionales. UNIDAD II INTRODUCCION A LA INGENIERIA DEL SOFTWARE 2.

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

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”. 3. El Software se desarrolla o construye. A pesar de que la industria tiene una tendencia hacia la construcción por componentes. los errores se corrigen y la curva se aplana: el Software no se desgasta.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. Un componente de Software se debe diseñar e implementar de forma que puede utilizarse en muchos programas diferentes. pero si se deteriora. El Software no se desgasta. las dos actividades serian diferentes en lo fundamental. la mayoría del Software aún se construye a la medida. Los defectos sin descubrir causan tasas de fallas altas en las primeras etapas de vida de un programa. 38 Tercera era 80´s . Martin Valencia Pág. no se manufactura en el sentido clásico. Elaborados por: Lic. Sin embargo. El Software es inmune a los males ambientales que desgasten el Hardware. 2.3 Características del Software 1. la fase de manufactura del Hardware puede incluir problemas de calidad existentes en el Software. En ambas la alta calidad se alcanza por medio del buen diseño.

2. 5. Una metodología es una manera ordenada y sistemática de proceder para obtener algún fin. pasa por una serie de etapas que constituyen su ciclo de vida. Figura 3. Martin Valencia Pág. 39 ..Confiabilidad. lo que permite al ingeniero de Software crear nuevas aplicaciones nuevas a partir de partes reutilizables y que cumplan con estos atributos.Usabilidad y Reusabilidad. siendo el aspecto más visible del método. pasando por su propia construcción. 3.Utilidad. Disponibilidad y Rendimiento.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. 4. El conjunto de normas incluye además un Sistema de documentación donde se irá reflejando el trabajo realizado.... puesta en marcha y continúas revisiones hasta su abandono.Seguridad. 1.Oportunidad e Innovación. Desde que surge la necesidad. 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.. Se llevara a cabo a través de una serie de normas o reglas precisas. 6. cuyo cumplimiento será más o menos estricto.Funcionabilidad. constituyendo el cuerpo formal de la metodología.. Las actividades para la construcción de un Sistema se realizan de acuerdo a un método. Elaborados por: Lic.

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

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

• • • Métodos. 42 . Martin Valencia Pág. Métodos: Los métodos de la ingeniería de Software indican cómo construir técnicamente el Software. construcción de programas. Procesos: El fundamento de la ingeniería de Software es la capa proceso. pruebas y mantenimiento. El proceso define un marco de trabajo para un conjunto de áreas clave. se producen resultados de trabajo. se asegura la calidad y el cambio se gestiona adecuadamente. se establecen hitos. Los métodos abarcan una gran gama de tareas que incluyen análisis de requisitos. Capas de la Ingeniería de Software.proporcionan un soporte automático o semi automático a los procesos y a los métodos. a estas herramientas se les llama herramientas CASE (Computer-Aided Software Engineering). Un enfoque de Calidad.. 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.INSTITUTO TECNOLÓGICO DE JIQUILPAN Apuntes de Fundamentos de Desarrollo de Sistemas Ingeniería en Sistemas Computacionales Plan 2004 Enfoque en capas • Herramientas. Elaborados por: Lic. diseño.-son el fundamento de la ingeniería de Software. 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.indican cómo construir técnicamente el Software Procesos. 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..son la base o cimientos de la ingeniería de Software..

. Software de IA. Software Incrustrado. Software de Tiempo Real. Software de Ingeniería/Científico. 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. Vida Social. y se encuentra dividida en las siguientes aplicaciones. Cualquier disciplina de ingeniería (incluida la ingeniería del Software) debe descansar sobre un esfuerzo de organización de calidad. Software de PC.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. Etc. Juegos. relativos esencialmente a la naturaleza del producto obtenido. salud. Martin Valencia Pág. 43 .         Software de Sistema. 2. 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. Perspectiva histórica del desarrollo de Software  Década 50-60: Elaborados por: Lic. en el desarrollo de Software hay una serie de desafíos adicionales.Aunque un proyecto de desarrollo de Software es equiparable en muchos aspectos a cualquier otro proyecto de ingeniería. Aplicaciones Web. afectado por la creatividad y juicio de las personas involucradas . Este proceso es intensamente intelectual.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. A continuación se explican algunas particularidades asociadas al desarrollo de Software y que influyen en su proceso de construcción. Telecomunicaciones. Dicho proceso. Software de Negocios. Educación.

Martin Valencia Pág. a medida. Década lenguajes y compilación..  Década 60-70: Software como producto. usar todo o nada (poco ensamblaje de componentes: reutilización).  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. Lenguajes de bajo nivel.INSTITUTO TECNOLÓGICO DE JIQUILPAN Apuntes de Fundamentos de Desarrollo de Sistemas Ingeniería en Sistemas Computacionales Plan 2004 “Software como un añadido”.  Década 70-80: Programación estructurada.ISW. 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. . en lugar de físico. Distribuida .      El Software es un elemento del Sistema que es lógico.. La mayoría del Software se construye a medida.Repositorios de componentes reutilizables . Desarrollo artesanal.7 Software de Alta Calidad Las inspecciones de Software surgen a partir de la necesidad de producir Software de alta calidad.e-business.NET. 44 Elaborados por: . Ingeniería del Software. El Software no se «estropea». El Software se desarrolla no se fábrica en un sentido clásico. 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”. Tecnología CASE Componentes y reutilización Interoperabilidad (CORBA. ¡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. 2.) Internet . ¡Pero se deteriora!. Primeros métodos estructurados. 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.

las personas desarrolladoras deben tener en cuenta claramente que son otras personas las que utilizarán sus productos. – 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.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. o se mencionan de forma incompleta (por ejemplo el deseo de un buen mantenimiento) que también pueden implicar una falta de calidad. El desarrollo de productos Software es una actividad sujeta a muchos factores que la pueden hacer poco confiable. Si no se sigue ninguna metodología siempre habrá falta de calidad. 45 . S. La falta de concordancia con los requisitos es una falta de calidad. Pero para ello se deben tener en cuenta algunas ideas previas: . 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. los asistentes Software para el desarrollo de Software no son demasiado confiables como para que la mano humana no intervenga en este proceso. El control de la calidad es una serie de revisiones. Elaborados por: Lic. Todas las metodologías y herramientas tienen un único fin producir Software de gran calidad Definiciones de calidad del Software. los que pueden estar sujetos a fallos constantes. – “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). El aseguramiento de calidad del Software se diseña para cada aplicación antes de comenzar a desarrollarla y no después. Aún a pesar de los avances actuales en Inteligencia Artificial. Así.Productos Software son realizados por personas para personas. – “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. La principal meta de un equipo desarrollador de Software debería ser siempre producir Software catalogado como de alta calidad. y pruebas utilizados a los largo del ciclo de desarrollo para asegurar que cada producto cumple con los requisitos que le han sido asignados. – Existen algunos requisitos implícitos o expectativas que a menudo no se mencionan. Los requisitos del Software son la base de las medidas de calidad. Martin Valencia Pág. Pressman (1992).

Martin Valencia Pág. – Garantía. 46 .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. la gestión de requisitos) aún no se realiza o todavía no alcanza todas las metas y objetivos definidos para el nivel 1 de capacidad. Nivel 1: Realizado. – 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. Nivel 2: Administrado. Todos los criterios del nivel 1 han sido satisfechos. programación y prueba. Las tareas de trabajo requeridas para producir el producto específico han sido realizadas. Actividades para el aseguramiento.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. diseño. todo el trabajo asociado con el área de proceso se ajusta a una política organizacional definida. El área del proceso (por ejemplo. – Inspecciones técnicas formales en todos los pasos del proceso de desarrollo del Software. toda la gente que ejecuta el trabajo tiene acceso a recurso adecuados para realizar su labor. Modelo de Capacidad de Madurez (IMCM). – Aseguramiento pretende dar confianza en que el producto tiene calidad. los clientes están implicados de manera Elaborados por: Lic. puede confundir con garantía de productos. con el fin de alcanzar la calidaden el desarrollo de cualquier proyecto de Software. – Estrategias de prueba multiescala. Además. Nivel 0: Incompleto. El aseguramiento de calidad del Software está presente en: – Métodos y herramientas de análisis. Todas las metas específicas de área del proceso (como las definió la IMCM) han sido satisfechas.

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

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

Martin Valencia Pág. donde tanto los datos como los programas. 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. Un ejemplo es la amplia variedad de formatos de archivos soportados por muchos Sistemas operativos. Es más. Pero con mucha frecuencia los Sistemas tienen dificultades para interactuar porque hacen suposiciones contradictorias sobre el resto del mundo. 49 . Eficiencia Casi sinónimo de eficiencia es la palabra “rendimiento”. tales como la corrección y la robustez. existe la tendencia de soslayar las cuestiones de eficiencia. De manera más general. menús. Por otro lado. La reutilización tiene una influencia sobre todos los demás aspectos de la Calidad del Software. donde cualquier archivo de texto es simplemente una secuencia de caracteres. Los enfoques incluyen:    Formatos de archivos estándares. como en las diferentes versiones de Windows donde todas las herramientas utilizan un solo paradigma para la comunicación con el usuario. 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”. Un programa puede usar directamente como entrada los resultados de otro sólo si los formatos de archivos son compatibles.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. la preocupación por la eficiencia debe sopesarse con otros objetivos tales como la extensibilidad y la reutilización. como en el Sistema Unix. Interfaces de usuario estándares. Capturando tal patrón. Estructuras de datos estándares como en los Sistemas Lisp. Compatibilidad La compatibilidad es importante debido a que los Sistemas Software no se desarrollan en el vacío: necesitan interactuar con otros. optimizaciones extremas pueden hacer al Software tan especializado que limite el cambio y la reutilización. Elaborados por: Lic. debería ser posible explotar esta similitud y evitar reinventar soluciones a problemas que ya han sido encontradas con anterioridad. La clave de la compatibilidad recae en la homogeneidad del diseño y en acordar convenciones estándares para la comunicación entre programas. se representan mediante árboles binarios. un elemento de Software reutilizable se podrá aplicar en muchos desarrollos diferentes. basado en componentes estándares tales como ventanas. 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. 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. etc. íconos.

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. donde las presiones vienen de los usuarios de la misma compañía. se debe esperar que los usuarios sean miembros de la raza humana y que sepan leer. mover un ratón. Un Sistema bien diseñado. tratando de que todo encaje en un molde general. se puede dar por supuesto que los usuarios están familiarizados con sus conceptos básicos. Tales comentarios no deberían preocuparnos en exceso. Sus consecuencias son malas para los proyectos internos. Lo que a unos les puede resultar algo superfluo puede ser una facilidad indispensable para otros. el Sistema de ventanas y otras herramientas fundamentales. Funcionalidad Uno de los problemas más difíciles a los que se enfrenta un jefe de proyecto es conocer cuanta funcionalidad es suficiente. Cuando se diseña un Sistema interactivo. y son peores para los productos comerciales. Martin Valencia Pág. La presión para ofrecer más facilidades (conocida como featurism). incluso si tiene muchas propiedades especializadas. está constantemente presente. La solución aquí es trabajar una y otra vez sobre la consistencia del producto global. la que realmente programamos y que incluye el Sistema operativo. tiende a ser más fácil de aprender y usar que uno confuso. Un buen producto Software está basado en un número pequeño de potentes ideas. Elaborados por: Lic. lo que puede afectar a su facilidad de uso. Si el Software está dirigido a un área especializada de aplicación. El featurism. El problema más fácil es la pérdida de consistencia como consecuencia de estar añadiendo nuevas propiedades. 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. no mucho más. es realmente la combinación de dos problemas. 50 . construido de acuerdo a una estructura clara y bien pensada. Muchas de las incompatibilidades existentes entre las plataformas son injustificadas. puesto que las nuevas propiedades no surgen de la nada: la mayor parte de las veces han sido solicitadas por los usuarios finales. 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. y convierte a la portabilidad en un asunto primordial tanto para los que desarrollan como para los que usan el Software. uno más difícil que el otro. El “gran plan” debe estar visible y todo debería ocupar su sitio dentro de él. éstas deberían explicarse como consecuencia de los conceptos básicos. presionar un botón y teclear (lentamente). Facilidad de uso La definición insiste en los diferentes niveles de experiencia de los posibles usuarios. Una de las claves de la facilidad de uso es la simplicidad estructural.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. Pero incluso esto es arriesgado. Hacen las menos suposiciones posibles sobre los usuarios. Los buenos diseñadores de interfaces siguen una política prudente.

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

se establece un Sistema para el soporte del desarrollo de Software. Herramientas automáticas y semiautomáticas que apoyan a la aplicación de 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. Elaborados por: Lic. herramientas y procedimientos mencionados. el análisis. la estimación. Un buen lenguaje de implementación puede eliminar muchas de las necesidades de documentación interna si favorece la claridad y la estructura. el diseño. codificación.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. 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. 52 . las entregas. a los que se denominan Paradigmas de la Ingeniería de Software. Martin Valencia Pág. prueba y mantenimiento. La Ingeniería de Software está compuesta por una serie de pasos que abarcan los métodos. se alivia la tarea de los autores de los manuales de usuario y de otras formas de documentación externa. 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. 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. llamado Ingeniería de Software Asistida por Computadora ( CASE ). 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. Cuando se integran las herramientas de forma que la información creada por una herramienta puede ser usada por otra.

1. los controles y entregas requeridos. un proceso. Un diagrama de flujo de datos puede ser profundizado expandiendo algunos de sus procesos en subprocesos. en este caso la etiqueta tendrá un número adicional. Hablando de lenguajes Tiene muchas diferencias con la OO. 53 . La ingeniería de Software está compuesta por una serie de pasos de abarcan los métodos. 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. No hay un límite para el número de procesos. Estos pasos se denominan frecuentemente paradigmas de la ingeniería de Software. los métodos. Los flujos. y rectángulos cerrados o abiertos. flujo de datos (argumentos) y archivos (base de datos). 3.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. En un DFD también se utiliza la escritura. Los procesos se etiquetan con un número y un verbo en infinitivo con objeto directo. 3. Los cerrados representan entidades externas mientras que los abiertos describen almacenes o archivos. o hacia. Martin Valencia Pág. Los círculos significan procesos y las flechas flujos de datos desde. Un diagrama de flujo de datos también se puede utilizar para la visualización de procesamiento de datos (diseño estructurado).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. Sus elementos gráficos son círculos. DFD es un diagrama en el q participan procesos (métodos). con solo importar clases ya hechas se escribe menos código y se ahorra tiempo. herramientas a usar. Hay de diferentes niveles dependiendo la complejidad del Sistema que analiza. 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. 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. 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. flechas. Otra desventaja es que una porción de código en lenguaje estructurado es difícil que pueda servir en otros proyectos.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. entidades externas y los almacenes se etiquetan con un nombre. esto sí es habitual en lenguajes OO. las herramientas y los procedimientos antes mencionados.

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

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

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

Modelos de Datos Físicos Son estructuras de datos a bajo nivel implementadas dentro del propio manejador.4 Descomposición En Procesos. 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.1. El ejemplo más típico es el Modelo Relacional. etc. Ejemplos típicos de estas estructuras son los Árboles B+. 57 . Estos módulos pueden ser un programa.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. un procedimiento. funcionales. que llamaremos módulos conteniendo cada uno de ellos procedimientos manuales o automatizados. • Operaciones de manipulación de los datos: típicamente. El ejemplo más típico es el Modelo EntidadRelación. Martin Valencia Pág. 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í. Una opción bastante usada a la hora de clasificar los modelos de datos es hacerlo de acuerdo al nivel de abstracción que presentan: Modelos de Datos Conceptuales Son los orientados a la descripción de estructuras de datos y restricciones de integridad. Se usan fundamentalmente durante la etapa de Análisis de un problema dado y están orientados a representar los elementos que intervienen en ese problema y sus relaciones. operaciones de agregado. Modelos de Datos Lógicos Son orientados a las operaciones más que a la descripción de una realidad. las estructuras de Hash. Elaborados por: Lic. Usualmente están implementados en algún Manejador de Base de Datos. Las organizaciones. 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. borrado. desarrollan múltiples actividades el componente básico de estas corresponde a la tarea. por lo que los dos enfoques propuestos son necesarios en cualquier desarrollo de Software. a fin de que el Sistema pueda ser desarrollado y ejecutado en unidades menores. que cuenta con la particularidad de contar también con buenas características conceptuales (Normalización de bases de datos). entendida como una microactividad que se responsabiliza a una sola persona. Un (DFD) presenta ser subdividido en diferentes partes. más fáciles de implementar manejar y controlar. modificación y recuperación de los datos de la base. • Las restricciones de integridad: Un conjunto de condiciones que deben cumplir los datos para reflejar correctamente la realidad deseada.

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

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

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

Si incluye los métodos. [@ Public Class Persona Private mstrNombre As String Private mdtFechaNacimiento As Date Elaborados por: Lic. peso y color. no existe aún el objeto Persona. como caminar. A pesar de que la clase Persona se define en el ejemplo. 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. y propiedades específicas. 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. Martin Valencia Pág. El siguiente ejemplo representa la definición de la clase Perro. Tome en consideración que ésta no es una sintaxis estricta de VB. Por ejemplo. 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.NET. su fecha de nacimiento y un Método que calcula la edad de la persona. 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. 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. puede crear objetos con base en esa clase. Estas características determinan la manera en que otros objetos pueden acceder y trabajar con los datos que se incluyen en el objeto. como altura. 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. pero tendrán sus propios valores específicos para el mismo conjunto de propiedades. con dos partes de información relevante asociadas: el nombre de la persona. simplemente es un ejemplo de la definición de clase. puede definir una clase Perro con ciertos comportamientos. ladrar y comer. El siguiente ejemplo define una nueva clase. 61 . a partir del cual puede crear objetos. Persona. si desea construir objetos que representen perros. Una vez que haya definido la clase Perro. Deberán ser creados.

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

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

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

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

en la práctica. 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. un extremo de una asociación puede tener como multiplicidad un conjunto de enteros arbitrarios.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. . Martin Valencia Pág. 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 ). 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. Con frecuencia. Persona y Automóvil) indica composición Una asociación de muchos a muchos tiene una multiplicidad de 0. 69 .2. 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. los objetos del lado de “muchos” pueden distinguirse entre ellos usando un nombre. en el caso de una asociación de uno a muchos. Generalización: La generalización nos permite organizar conceptos en jerarquías. En UML. 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. identificando objetos de solución adicionales y refinando los objetos existentes. Sin embargo. 3. n o 1. Este es el tipo más complejo de asociación. El análisis para el enfoque orientado a objetos. Asociaciones calificadas: La calificación es una técnica para la reducción de la multiplicidad usando claves.2 Diseño Durante el diseño de objetos cerramos el hueco entre los objetos de aplicación y los componentes hechos. n en ambos extremos. El diseño de objetos incluye: Elaborados por: Lic. 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. El análisis identifica las clases y objetos relativamente en el dominio del problema. 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. el diseño proporciona detalles sobre la arquitectura. .

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

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

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

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

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

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

en especial los de la fase de Elaboración.Manejo integrado del Software. . 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.Administración cuantitativa del proyecto. 4. Los resultados de cada iteración. 78 . El PSP se caracteriza porque es de uso personal y se aplica a programas pequeños de menos de 10. . . . Fue propuesto por Watts Humphrey en 1995 y estaba dirigido a estudiantes.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.Seguimiento y control de proyectos . Martin Valencia Pág. .Planeación de los proyectos Nivel 2 . cuando construyes un edificio existen diversos planos que incluyen los distintos servicios del mismo: electricidad. deben ser seleccionados en un orden que asegure que los riesgos principales son considerados primero. El PSP se orienta el conjunto de áreas clave del proceso que debe manejar un desarrollador cuando trabaja de forma individual.Control de calidad.Foco del proceso de Software.Repetible: .Definición del proceso de Software. A partir de 1997 con el lanzamiento del libro “An introduction to the Personal Software Process” se dirige ahora a ingenieros principiantes. En el PSP se excluyen los siguientes temas: Trabajo en equipo. etc.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. Elaborados por: Lic. Los siguientes son los niveles y las KPAs que se manejan en cada uno: Nivel 1 .Inicial: . . Administración de configuraciones y Administración de requerimientos.Ingeniería del producto de Software.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.000 líneas de código. Nivel 3 .Definido: . fontanería.Revisión entre colegas.

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

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

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

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

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

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. En la entrevista se quiere obtener la opinión del entrevistado y sus sentimientos acerca del estado actual del Sistema._ Abiertas. Preparar al entrevistado: Se realiza hablándole por anticipado o enviándole un mensaje por correo electrónico. 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. Si las entrevistas tienen una larga duración. 84 . Elaborados por: Lic. Su ventaja es construir un vocabulario común. 2. Las entrevistas deben durar de 45 minutos a una hora.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. 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. es posible que los entrevistados se enfaden._ Cerradas. para redactar las preguntas de la entrevista de forma que sea comprensible para el entrevistado. PREPARAR AL ENTREVISTADO: Esto es preparar a la persona a ser entrevistada. pero lo pueden ocultar. Martin Valencia Pág. Los dos tipos básicos de preguntas son: 1. y continuar con preguntas abiertas y más generalizadas). 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. llamándole con anticipación y permitiendo que el entrevistado tenga tiempo para pensar acerca de la entrevista. una estructura de embudo o una estructura de diamante (iniciar con preguntas generales y abiertas. a lo mucho. así como la experiencia para establecer los objetivos de la entrevista. 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. y concluir limitando las respuestas con preguntas cerradas).      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. La entrevista es una conversación dirigida que usa un formato de preguntas y respuestas. ESTABLECIMIENTO DE LOS OBJETIVOS DE LA ENTREVISTA: Requiere usar la información que se recopiló. La estructura de las preguntas deben de ser como una pirámide (empezar con preguntas a menudo cerradas. El analista puede entrevistar al personal en forma individual o en grupos.

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

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. se puede distribuir los cuestionarios a todas las personas apropiadas para recabar hechos con relación al Sistema. Los cuestionarios proporcionan una alternativa muy útil para las entrevistas. que es lo más común. El tacto. Elaborados por: Lic. las características anteriores también son desventajas de los cuestionarios. es igualmente mala. fui enviado para encontrar una forma de mojar el rendimiento y de reducir los errores que presentan aquí. al personal del almacén y a los supervisores de los diferentes turnos. Cuando se llevan a cabo largos estudios en varios departamentos. 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. aquellas personas que realmente trabajan en el almacén. por ejemplo. existen ciertas características que pueden ser apropiadas en algunas situaciones e inapropiadas en otras. A través de la entrevista. es decir. Es imaginable la rapidez con la que va a responder ser irrita y se molesta con un enfoque de este tipo. Por supuesto. Puede necesitarse algún seguimiento de los cuestionarios para motivar al personal que responda. 86 . Por otra parte. Recolección de datos mediante cuestionarios. todas las respuestas se encontraran en una proporción entre el 25 o 35%. También las preguntas estandarizadas pueden proporcionar datos más confiables. Martin Valencia Pág.2 Cuestionario. si dijera. Por ejemplo. los analistas tendrán más conocimientos no solamente de la información adquirida sino también de su importancia. La habilidad del entrevistador es vital para el éxito en la búsqueda de hechos por medio de la entrevista. la imparcialidad e incluso la vestimenta apropiada ayudan a asegurar una entrevista exitosa.1. no es posible observar las expresiones o relaciones de quienes responden a los cuestionarios. 5. O la introducción: “Estamos aquí para resolver su problema”. “hola. Selección de formas para cuestionarios. sin embargo. es muy rara una respuesta total. 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. también entrevistaran a los agentes más importantes. La falta de estos factores puede reducir cualquier oportunidad de éxito. Aunque su aplicación puede realizarse con un mayor número de individuos. 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. Realización de la entrevista.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.

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

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

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

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

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

La mejor razón para la creación de estas herramientas fue el incremento en la velocidad de desarrollo de los sistemas. Diseño. cálculo de costes. Como es sabido. 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. Por esto. Implementación e Instalación Una innovación en la organización. antes de finalizar el proceso de desarrollo. Se puede definir a las Herramientas CASE como un conjunto de programas y ayudas que dan asistencia a los analistas. Los diagramas de organización muestran como las diferentes unidades deberían relacionarse con otras.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. Historia. los estados en el Ciclo de Vida de desarrollo de un Software son: Investigación Preliminar.2 Herramientas CASE. 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). 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. La realización de un nuevo software requiere que las tareas sean organizadas y completadas en forma correcta y eficiente. 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). 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. Los registros permiten que los analistas se familiaricen con algunas operaciones. pero muchas no reflejan las operaciones actuales. durante todos los pasos del Ciclo de Vida de desarrollo de un Software. compilación automática. un concepto avanzado en la evolución de tecnología con un potencial efecto profundo en la organización. 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. ingenieros de software y desarrolladores. 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. no muestran como producen de hecho las actividades. No obstante. 92 . 5. Selección de los registros para revisión. o como se realizan las tareas en la actualidad. Elaborados por: Lic. 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. implementación de parte del código automáticamente con el diseño dado. las compañías pudieron desarrollar sistemas sin encarar el problema de tener cambios en las necesidades del negocio. Martin Valencia Pág. a menudo no se mantienen al corriente lo suficiente para señalar los procedimientos existentes. Análisis. donde se ubica el poder verdadero para las decisiones. Las herramientas CASE (Computer Aided Software Engineering. documentación o detección de errores entre otras. también proporcionan una visión sobre la forma en la que el negocio debería conducirse. 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.

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

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

Las herramientas métricas actuales se centran en procesos. 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. en lugar de proporcionar un soporte global para la actividad de gestión. se puede: realizar estimaciones de esfuerzo. se centran en un elemento especifico de la gestión del proyecto. para representar las interdependencias entre tareas y para modelar la cantidad de paralelismo que sea posible para ese proyecto. 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. Las herramientas orientadas a la gestión capturan métricas especificas del proyecto (por ejemplo: LDC/personamos. hacer un seguimiento continuo del proyecto. el sistema proporcionado suele no satisfacer los requisitos especificados por el cliente. L-CASE (Lower CASE .INSTITUTO TECNOLÓGICO DE JIQUILPAN Apuntes de Fundamentos de Desarrollo de Sistemas Ingeniería en Sistemas Computacionales Plan 2004   Herramientas de bajo nivel. para crear una red de tareas (normalmente empleando una entrada gráfica). Muchas de las herramientas métricas avanzadas mantienen una base de datos de medidas de medias de la industria.CASE inferior) o back-end. dirigidas a las últimas fases del desarrollo: construcción e implantación. Juegos de herramientas o toolkits. Existen también herramientas que permite al comprador del desarrollo de un sistema. defectos por punto de función) que proporcionan una indicación global de productividad o de calidad. la duración del proyecto y el número recomendado de personas. costo y duración. 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. comenzando por las especificaciones del cliente. proyectos y características del producto. 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 de trazado de requisitos típicos combinan una evaluación de textos por interacción humana. estimar la productividad y la calidad. Dentro de este grupo se encontrarían las herramientas de reingeniería. Martin Valencia Pág. 95 . Automatizan una fase dentro del ciclo de vida. son el tipo más simple de herramientas CASE. Elaborados por: Lic. orientadas a la fase de mantenimiento. El objetivo de las herramientas de seguimiento de requisitos es proporcionar un enfoque sistemático para el aislamiento de requisitos. Herramientas de seguimiento de requisitos: Cuando se desarrollan grandes sistemas. Planificación de proyectos Capacitan al administrador para definir todas las áreas del proyecto (la estructura de desglose de tareas). 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. Utilizando un conjunto seleccionado de la misma. HERRAMIENTAS DE GESTION DE PROYECTOS: La mayoría de herramientas CASE de gestión de proyectos.

Estas herramientas utilizan un sistema experto para sugerir el orden en el que se debe llevar a cabo un proyecto. medición. 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. y le ayudan a eliminar errores antes de que se propaguen al diseño. arquitectura. 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. estructuras de ventanas. capacitan al ingeniero del software para desarrollar simulaciones del sistema de tiempo real que permitirán al cliente obtener ideas acerca de su funcionamiento. Se utilizan tres tipos distintos de herramientas estáticas de comprobación en la industria: herramientas de comprobación basadas en código. etc. que se ajustan al estándar de interfaz que se haya adoptado para el software. 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.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. Sin embargo.   HERRAMIENTAS DE INTEGRACION Y PRUEBA: Sirven de ayuda a la adquisición. lenguajes de comprobación especializados.. Además. así como caracterizaciones del diseño de datos. Los modelos contienen una representación de los datos. simulación y prueba de los equipos lógicos desarrollados. o lo que es peor. iconos. 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. Proporcionan un grado de confianza en la representación del análisis y ayudan a eliminar errores con anticipación. procedimientos e interfaz. Al efectuar una comprobación de la consistencia y validez del modelo. 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. botones. 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. y herramientas de comprobación basadas en requisitos. a la propia implementación. comportamiento y respuesta antes de la verdadera implementación. Martin Valencia Pág. 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. 96 Elaborados por: . 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. controladores de dispositivos. 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. 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 comprobación basadas en Lic. de la función y del comportamiento (en el nivel de análisis). mecanismos de desplazamiento.

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. 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. Además de las funciones indicadas anteriormente. y efectúan comprobaciones por lotes de programas con interfaces interactivas entre hombre y maquina. 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. da formato a los datos de prueba para que se ajusten a las necesidades del software que se está probando. Herramientas de análisis dinámico: Las herramientas de análisis dinámico interactúan con un programa que se esté ejecutando. 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. listos de utilización y otras informaciones de diseño. 97 . 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. Las herramientas dinámicas pueden ser bien intrusivas. comprueban la cobertura de rutas. e invoca entonces al software que sea preciso comprobar. 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). Las herramientas de esta categoría administran y coordinan la comprobación de regresiones. comprueban las afirmaciones acerca del valor de variables especificas y en general instrumentan el flujo de ejecución del programa. se genera una gráfica de control de flujo y se genera automáticamente un programa estructurado. Un controlador de comprobación lee uno o más casos de prueba de algún archivo de pruebas. 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). aplicando una base de conocimientos que se a especifica del dominio de la aplicación (esto es. Elaborados por: Lic. pero seguirá requiriendo una interacción con un ingeniero de software a lo largo del ciclo de la reingeniería. efectúan comparaciones que determinan las diferencia s entre la salida real y la esperada.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. 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. bien no intrusivas. El componente de inteligencia artificial asistirá en la descomposición y reconstrucción de los sistemas. muchas herramientas de gestión de comprobaciones sirven también como controladores de comprobación genéricos. Herramientas de reestructuración y análisis de código: se analiza la sintaxis del programa. 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. Martin Valencia Pág.

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. 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. y representan una importante oportunidad de aprovechamiento para todos los desarrolladores del software. 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). 5. basados en repositorios que generan códigos.1 Estructuradas Las herramientas Case utilizarán técnicas gráficas para diseñar las clases y sus interacciones. 98 . La mayor parte de las organizaciones dedicadas al desarrollo de software invierte una cantidad de tiempo considerable en el desarrollo de documentos. Dado el énfasis acerca de los objetos de configuración. 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. 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. las herramientas de documentación suponen una oportunidad importante para mejorar la productividad. Permite crear Sistemas más complejos. Otras herramientas extraen métricas técnicas como base para medir la calidad del software que se está construyendo. el entorno CASE debe adaptase a un software de sistema en redes de alta calidad. y para utilizar objetos existentes adaptados en nuevas aplicaciones. Las herramientas deberán ser diseñadas para estimular la máxima creatividad y continuo refinamiento del diseño durante la construcción. Por tanto.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. etc. Las herramientas deberían facilitar el modelamiento en términos de eventos. 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. al correo electrónico. Relacionar el Sistema al mundo real. Fomenta la reutilización y extensión del código. y en muchos casos el proceso de documentación en si resulta bastante deficiente.    5. estado de los objetos. Por esta razón. Elaborados por: Lic. Martin Valencia Pág. Herramientas para software de sistemas: CASE es una tecnología de estaciones de trabajo.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. triggers (iniciadores). a los boletines electrónicos y a otras capacidades de comunicaciones.2.2.

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

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

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

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

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

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

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

sus ventajas: claridad. reducción de costos y reutilización Los pasos a seguir son: 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. Describir las relaciones entre módulos Una descomposición modular debe poseer ciertas cualidades mínimas para que se pueda considerar suficientemente válida. 1. 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. esto es a reducir las interconexiones entre los distintos módulos en que se estructure nuestra aplicación. Elaborados por: Lic.Común. Es recomendable reducir las relaciones entre módulos al mínimo. Martin Valencia Pág. la zona común es un dispositivo externo al que estan ligados los módulos. Podemos graduar en un amplio espectro. Describir cada módulo 3. Independencia funcional 2. 106 . . Cohesión 4. Moderado . El grado de acoplamiento mide la interrelación entre dos módulos. se emplea una zona común de datos a la que tienen acceso varios módulos. cuando desde un módulo se puede cambiar datos locales de otro.De control. Identificar los módulos 2. esto implica que un cambio en el formato de datos los afecta a todos. pero por lo general se tiende a que el acoplamiento sea lo menor posible.Por contenido. Adaptabilidad a) Independencia funcional Cada módulo debe realizar una función concreta o un conjunto de funciones afines. Comprensibilidad 5. Acoplamiento 3. según el tipo de conexión y la complejidad de la interface: Fuerte .

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

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

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

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

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

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

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

memoria o interfaces de comunicación. Un gestor de recursos es un módulo software que maneja un conjunto de recursos de un tipo en particular. Los usuarios de los recursos se comunican con los gestores de los recursos para acceder a los recursos compartidos del sistema. 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.. ésta debe ser manejada por un programa que ofrezca un interfaz de comunicación permitiendo que el recurso sea accedido.. 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). Básicamente los sistemas distribuidos cumplen una serie de características: 1. manipulado y actualizado de una manera fiable y consistente. 114 . 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. Para que la compartición de recursos sea efectiva. ) o con respecto a las extensiones software ( añadir características al sistema operativo. Un sistema puede ser abierto o cerrado con respecto a extensiones hardware (añadir periféricos. 2. etc. Sin embargo. Un sistema distribuido puede verse de manera abstracta como un conjunto de gestores de recursos y un conjunto de programas que usan los recursos. Un sistema informático es abierto si el sistema puede ser extendido de diversas maneras. Concurrencia. Surge el término genérico de gestor de recursos. posiblemente proveniente de vendedores diferentes. En una palabra. Apertura (opennesss)..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. Cuando existen varios procesos en una única maquina decimos que se están ejecutando concurrentemente. Los sistemas distribuidos abiertos pueden construirse a partir de hardware y software heterogéneo. 3. etc. Éstos incluyen la provisión de un esquema de nombres para cada clase de recurso. Los interfaces software clave del sistema están claramente especificados y se ponen a disposición de los desarrolladores. ). Los sistemas multiusuario clásicos desde siempre han provisto compartición de recursos entre sus usuarios. Por el contrario. 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. Cada tipo de recurso requiere algunas políticas y métodos específicos junto con requisitos comunes para todos ellos. protocolos de comunicación y servicios de compartición de recursos. la concurrencia tiene lugar entrelazando la Elaborados por: Lic. Esta perspectiva nos lleva a dos modelos de sistemas distribuidos: el modelo cliente-servidor y el modelo basado en objetos. los recursos de una computadora multiusuario se comparten de manera natural entre todos sus usuarios.. permitir que los recursos individuales sean accedidos desde cualquier localización. 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. 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. Martin Valencia Pág. Si el ordenador está equipado con un único procesador central. los interfaces se hacen públicos.

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

Los sistemas distribuidos también proveen un alto grado de disponibilidad en la vertiente de fallos hardware. Resumiendo. 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. 116 Elaborados por: . Los sistemas informáticos a veces fallan. La disponibilidad de un sistema es una medida de la proporción de tiempo que está disponible para su uso. El diseño de sistemas tolerantes a fallos se basa en dos cuestiones. la técnica asociada de caching. Estas proveen un resumen útil de la motivación y metas de los sistemas distribuidos. Cuando uno de los componentes de un sistema distribuidos falla. 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. El manual de referencia RM-ODP [ISO 1996a] identifica ocho formas de transparencia. de manera que el sistema se percibe como un todo. con las consideraciones de consistencias que ello conlleva. Una explicación completa de estas técnicas puede encontrarse en [ Colouris 1994 ]. Cuando se producen fallos en el software o en el hardware. Transparencia. Las técnicas necesarias para conseguir estos objetivos incluyen el uso de datos replicados. Cuando el tamaño y complejidad de las redes de ordenadores crece.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. un proceso servidor podría ejecutarse en otra máquina. 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. aprovechando la concurrencia para permitir una mayor productividad. en vez de una colección de componentes independientes. y el uso de múltiples servidores para manejar ciertas tareas. 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). es un objetivo primordial diseñar software de sistema distribuido que seguirá siendo eficiente y útil con esas nuevas configuraciones de la red. En los sistemas distribuidos la redundancia puede plantearse en un grano más fino que el hardware. solo se ve afectado el trabajo que estaba realizando el componente averiado. Lic. Un fallo simple en una maquina multiusuario resulta en la no disponibilidad del sistema para todos los usuarios. Tolerancia a Fallos. pueden replicarse los servidores individuales que son esenciales para la operación continuada de aplicaciones críticas. 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. Martin Valencia Pág. 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. En este caso el sistema deberá estar diseñado de manera que permita trabajar con ficheros replicados en distintos servidores. Un usuario podría desplazarse a otra estación de trabajo.

el diseño del Software esta conducido frecuentemente. su presencia o ausencia afecta fuertemente a la utilización de los recursos distribuidos. El software de dichos tiemporeal por a sistemas es software de el embebido que hardware y estos eventos. 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. Las computadoras nos permiten ver juegos. Transparencia de Prestaciones: Permite que el sistema sea reconfigurado para mejorar las prestaciones mientras la carga varia. 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. A menudo se las denomina a ambas transparencias de red.2. tanto por la arquitectura del Hardware como por la del Software. 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. Las dos más importantes son las transparencias de acceso y de localización. El Software de tiempo real está muy acoplado con el mundo externo. Debido a que el Software de tiempo real debe operar bajo restricciones de rendimiento muy rigurosas. 117 .4 Diseño de Software de Tiempo Real. 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. 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. La computadora digital se ha convertido en una maquina omnipresente en al vida diaria de todos nosotros. Todas estas interacciones con las computadoras sean útiles o intrusivas son ejemplos de computación de tiempo real. La computadora está controlando algo que interactúa con la realidad sobre una base de tiempo de hecho. esto es. 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. Lic. 6. por las características del Sistema operativo. optimizar el gasto de gasolina de nuestras últimas generaciones de coches y programar a nuestros aparatos.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. así como contar el tiempo. por los requisitos de la aplicación y tanto por los extras del lenguaje de programación como prospectos de diseño. el Software de tiempo real debe responder al ámbito del problema en un tiempo dictado por el ámbito del problema.

software de del cuyo los instante correcto funcionamiento resultados producidos por el de tiempo en el que se producen estos Elaborados por: Lic. Martin Valencia Pág. 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.

Elaborados por: Lic. 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.

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. Elaborados por: Lic. 120 .

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. en algunos casos. pero. no es Elaborados por: Lic. 121 . Martin Valencia Pág. una respuesta muy rápida.

Ocurren a intervalos de tiempo predecibles.. Estímulos periódicos.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. Martin Valencia Pág. Estímulos aperiódicos.Ocurren de forma irregular. Elaborados por: Lic.. 2. 122 .

Los sistemas de tiempo real se diseñan como un conjunto de cooperan entre sí. 123 .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. Elaborados por: Lic. Martin Valencia procesos concurrentes que Pág.

Martin Valencia Pág.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. 124 . Elaborados por: Lic. y debería ser posible predecir duración de operaciones particulares realizadas en estos lenguajes.

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.

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

Elegir una plataforma de ejecución para el sistema 4. Identificar los estímulos 2. Procesamiento de estímulos y respuestas a procesos concurrentes 5. 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. Martin Valencia Pág. Diseñar algoritmos para llevar a cabo los cálculos Elaborados por: Lic. Identificar las restricciones temporales 3.

Martin Valencia Pág.INSTITUTO TECNOLÓGICO DE JIQUILPAN Apuntes de Fundamentos de Desarrollo de Sistemas Ingeniería en Sistemas Computacionales Plan 2004 6. 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 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. 129 . Elaborados por: Lic.

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 . 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 El análisis temporal para sistemas de tiempo real es difícil.

que tienen lugar a intervalos 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 Modelado de sistemas de tiempo real Los sistemas de tiempo real deben responder a eventos irregulares. 132 .

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

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

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. 135 . incluso hasta lossistemas embebidos trabajan hoy en día conjuntamente con operativo de tiempo real (RTOS) más un sencillos. sistema Elaborados por: Lic. Martin Valencia Pág.

Elaborados por: Lic. 136 . Lanza y detiene los estímulos puedan ser manejados y recursos del procesador. Martin Valencia Pág.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.

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. Martin Valencia Pág. 137 .

Un planificador 4.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. Un despachador Elaborados por: Lic. Un reloj de tiempo real 2. Un manejador de interrupciones 3. Martin Valencia Pág. Un gestor de recursos 5. 138 .

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. Martin Valencia Pág. 139 .

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. 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. Martin Valencia Pág.

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

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

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

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.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. 146 . un eventos de en Elaborados por: Lic.

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. También procesos adicionales de coordinación. 147 . Martin Valencia Pág.

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

Elaborados por: Lic.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. 149 . que es el componente decidir qué proceso debería seleccionarse para su ejecución. Siempre responsable de responsable del proceso y la gestión de incluye un planificador. Martin Valencia Pág.

y envían órdenes a los Elaborados por: Lic. 150 . Martin Valencia Pág.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. los sensores. un conjunto de sensores que captan llevan a cabo acciones. Éstos dependiendo de las lecturas de actuadores.

Estas computadoras interactúan directamente con dispositivos de hardware. El implementa como un proceso para entre el productor y el 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. Recopilación de Información: Lic.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. Martin Valencia Pág. desde donde son por el proceso consumidor. 151 .

una introducción al estudio de la Administración. Sociedad para Estudios Pedagógicos Argentinos.es/docencia/barzana/IAGP/IAGP2-Ingenieria-Software-introduccion. Jorge A. Héctor Felipe. Córdoba 1987. carpeta del año 1994 curso 1k8. Hermida. Ciencia de la administración.A. 152 . Ramón García-Pelayo y Gross.I. Francia 1977. Prentice-Hall Panamericana. http://www.C. Administración.A. Pequeño Larousse Ilustrado (diccionario). Martin Valencia Pág. Alvarez. Análisis estructurado moderno. Estructura de las Organizaciones. Edward. S.blogspot.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. Percy Reyes Paredes Recopilación de Información: Lic. Buenos Aires mayo de 1983. Ediciones Contabilidad Moderna S.html Blog: http://percyreyes. Ediciones Larousse.com Fecha: 13/Jul/2005 (07/07/2005) Autor: A.um. Yourdon. México 1989.

You're Reading a Free Preview

Descarga
scribd
/*********** DO NOT ALTER ANYTHING BELOW THIS LINE ! ************/ var s_code=s.t();if(s_code)document.write(s_code)//-->