Académique Documents
Professionnel Documents
Culture Documents
UNIDAD 1: CONCEPTOS INTRODUCTORIOS Introduccin General. Seguramente si comprendemos algo de la teora General de Sistemas nos ayudar a entender mejor un Sistema computarizado de informacin. 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 aos en esta sociedad. Comencemos entonces con algunas definiciones bsicas de Sistemas del New Collegiate Dictionary de Webster: Grupo de elementos interdependientes o que interactan regularmente formando un todo (Ej.: el Sistema numrico). Juego organizado de doctrinas, ideas o principios, usualmente con la intencin de explicar el acomodo o el trabajo de un todo sistemtico (Ej.: el Sistema newtoniano de la mecnica). Patrn 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 categoras: Sistemas Naturales: Ej. : Sistema geolgico: ros, cordilleras, etc. Sistemas Hechos Por El Hombre: Ej. : Sistema de comunicacin: telfono, seales de humo, etc. En la actualidad la mayora de los Sistemas incluyen computadoras y muchos no podran vivir sin ellas, pero sin duda muchos Sistemas existen antes de que las mismas se inventaran; algunos continan por completo sin computarizar y otros la contienen como componente pero tambin 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 tecnologa 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 podramos preguntarnos porque no deberan automatizarse algunos Sistemas de procesamiento de informacin?, pueden existir muchas razones para esto como por ejemplo: Costo: podra resultar ms barato continuar llevando a cabo las funciones y almacenando la informacin del Sistema en forma manual. Poltica: la comunidad usuaria podra 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:
Pg. 1
INSTITUTO TECNOLGICO DE JIQUILPAN Apuntes de Fundamentos de Desarrollo de Sistemas Ingeniera en Sistemas Computacionales Plan 2004
Pero ahora nos ocuparemos de los Sistemas automatizados, aquellos hechos por el hombre que interactan con o son controlados por una o ms 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: informacin que el Sistema recuerda durante un perodo, etc. Procedimientos: polticas formales e instrucciones de operacin del Sistema. Los Sistemas automatizados. Pueden recibir una divisin en categoras como ser: Sistemas en lnea. Sistemas de tiempo Real. Sistemas de apoyo a decisiones. Sistemas basados en el conocimiento. Sistemas en lnea: Son aquellos que acepta material de entrada directamente del rea donde se cre. Tambin es aquel en el que el material de salida o resultado de la computacin se devuelve directamente a donde es requerido. Una caracterstica comn 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 interactan con la computadora desde terminales que pueden estar localizadas a cientos de kilmetros de la computadora misma. Otra caracterstica es que sus datos almacenados usualmente se organizan de modo de que los componentes individuales de informacin puedan ser recuperados, modificados o ambas cosas en forma rpida y sin tener que efectuar necesariamente accesos a otros componentes de informacin del Sistema. Ejemplo: Sistema de reservacin area, etc. Sistemas de tiempo Real. Puede definirse como aquel que controla un ambiente recibiendo datos, procesndolos y devolvindolos con la suficiente rapidez como para influir en dicho ambiente en ese momento.
Elaborados por:
Pg. 2
INSTITUTO TECNOLGICO DE JIQUILPAN Apuntes de Fundamentos de Desarrollo de Sistemas Ingeniera en Sistemas Computacionales Plan 2004
Una de sus caractersticas son la velocidad de respuesta y su interaccin tanto con personas como con un ambiente generalmente autnomo y hostil. Ejemplo: Sistemas de cajeros automticos, etc. Sistemas de apoyo a decisiones. Son utilizados por gerentes y jefes para evaluar y analizar la misin de la organizacin. En lugar de consejos sobre una decisin de negocio en forma aislada, estos Sistemas ofrecen consejos ms amplios y generales acerca de la naturaleza del mercado, preferencia del consumidor, comportamiento de la competencia, etc.
Sistemas basados en el conocimiento. Tambin conocidos como Sistemas expertos, son asociados al campo de la inteligencia artificial. La meta de los cientficos de la computacin que trabajan en este campo, es producir programas capaces de imitar el desempeo humano en una gran variedad de tareas inteligentes. Son programas que contienen conocimientos y capacidades necesarias para desempearse en un nivel de experto. Desempeo experto significa por ejemplo nivel de desempeo de mdicos que llevan a cabo diagnsticos y procesos teraputicos
1.1. Introduccin a los Sistemas La teora de la organizacin y la prctica administrativa han experimentado cambios sustanciales en aos recientes. La informacin proporcionada por las ciencias de la administracin y la conducta ha enriquecido a la teora tradicional. Estos esfuerzos de investigacin y de conceptualizacin 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 unificacin de muchos campos del conocimiento. Dicho enfoque ha sido usado por las ciencias fsicas, biolgicas y sociales, como marco de referencia para la integracin de la teora organizacional moderna. El primer expositor de la Teora General de los Sistemas fue Ludwing von Bertalanffy, en el intento de lograr una metodologa integradora para el tratamiento de problemas cientficos. La meta de la Teora General de los Sistemas no es buscar analogas entre las ciencias, sino tratar de evitar la superficialidad cientfica que ha estancado a las ciencias. Para ello emplea como instrumento, modelos utilizables y transferibles entre varios continentes cientficos, toda vez que dicha extrapolacin sea posible e integrable a las respectivas disciplinas. La Teora General de los Sistemas se basa en dos pilares bsicos: aportes semnticos y aportes metodolgicos.
Elaborados por: Lic. Martin Valencia Pg. 3
INSTITUTO TECNOLGICO DE JIQUILPAN Apuntes de Fundamentos de Desarrollo de Sistemas Ingeniera en Sistemas Computacionales Plan 2004
Aportes Semnticos: Las sucesivas especializaciones de las ciencias obligan a la creacin de nuevas palabras, estas se acumulan durante sucesivas especializaciones, llegando a formar casi un verdadero lenguaje que slo es manejado por los especialistas. De esta forma surgen problemas al tratarse de proyectos interdisciplinarios, ya que los participantes del proyecto son especialistas de diferentes ramas de la ciencia y cada uno de ellos maneja una semntica diferente a los dems. La Teora de los Sistemas, para solucionar estos inconvenientes, pretende introducir una semntica cientfica de utilizacin universal. Sistema: Es un conjunto organizado de cosas o partes interactuantes e interdependientes, que se relacionan formando un todo unitario y complejo. Cabe aclarar que las cosas o partes que componen al Sistema, no se refieren al campo fsico (objetos), sino ms bien al funcional. De este modo las cosas o partes pasan a ser funciones bsicas realizadas por el Sistema. Podemos enumerarlas en: entradas, procesos y salidas.
Entradas: Las entradas son los ingresos del Sistema que pueden ser recursos materiales, recursos humanos o informacin. Las entradas constituyen la fuerza de arranque que suministra al Sistema sus necesidades operativas. Las entradas pueden ser: - En serie: es el resultado o la salida de un Sistema anterior con el cual el Sistema en estudio est relacionado en forma directa. - Aleatoria: es decir, al azar, donde el trmino azar se utiliza en el sentido estadstico. Las entradas aleatorias representan entradas potenciales para un Sistema. - Retroaccin: es la reintroduccin de una parte de las salidas del Sistema en s mismo. Clasificacin extrada de apunte de ctedra. Proceso: El proceso es lo que transforma una entrada en salida, como tal puede ser una mquina, un individuo, una computadora, un producto qumico, una tarea realizada por un miembro de la organizacin, etc.
Elaborados por:
Pg. 4
INSTITUTO TECNOLGICO DE JIQUILPAN Apuntes de Fundamentos de Desarrollo de Sistemas Ingeniera en Sistemas Computacionales Plan 2004
En la transformacin de entradas en salidas debemos saber siempre cmo se efecta esa transformacin. Con frecuencia el procesador puede ser diseado por el administrador. En tal caso, este proceso se denomina caja blanca. No obstante, en la mayor parte de las situaciones no se conoce en sus detalles el proceso mediante el cual las entradas se transforman en salidas, porque esta transformacin es demasiado compleja. Diferentes combinaciones de entradas o su combinacin en diferentes rdenes de secuencia pueden originar diferentes situaciones de salida. En tal caso la funcin de proceso se denomina una caja negra. Caja Negra: La caja negra se utiliza para representar a los Sistemas cuando no sabemos qu elementos o cosas componen al Sistema o proceso, pero sabemos que a determinadas corresponden determinadas salidas y con ello poder inducir, presumiendo que a determinados estmulos, las variables funcionaran en cierto sentido. Salidas: Las salidas de los Sistemas son los resultados que se obtienen de procesar las entradas. Al igual que las entradas estas pueden adoptar la forma de productos, servicios e informacin. Las mismas son el resultado del funcionamiento del Sistema o, alternativamente, el propsito para el cual existe el Sistema. Las salidas de un Sistema se convierte en entrada de otro, que la procesar para convertirla en otra salida, repitindose este ciclo indefinidamente. Relaciones: Las relaciones son los enlaces que vinculan entre s a los objetos o SubSistemas que componen a un Sistema complejo.
Podemos clasificarlas en: - Simbiticas: es aquella en que los Sistemas conectados no pueden seguir funcionando solos. A su vez puede subdividirse en unipolar o parasitaria, que es cuando un Sistema (parsito) no puede vivir sin el otro Sistema (planta); y bipolar o mutual, que es cuando ambos Sistemas dependen entre si. - Sinrgica: es una relacin que no es necesaria para el funcionamiento pero que resulta til, ya que su desempeo mejora sustancialmente al desempeo del Sistema. Sinergia significa accin combinada. Sin embargo, para la teora de los Sistemas el trmino significa algo ms que el esfuerzo cooperativo. En las relaciones sinrgicas la accin cooperativa de subSistemas semi-independientes, tomados en forma conjunta, origina un producto total mayor que la suma de sus productos tomados de una manera independiente. - Superflua: Son las que repiten otras relaciones. La razn de las relaciones superfluas es la confiabilidad. Las relaciones superfluas aumentan la probabilidad de que un Sistema funcione todo el tiempo y no una
Elaborados por: Lic. Martin Valencia Pg. 5
INSTITUTO TECNOLGICO DE JIQUILPAN Apuntes de Fundamentos de Desarrollo de Sistemas Ingeniera en Sistemas Computacionales Plan 2004
parte del mismo. Estas relaciones tienen un problema que es su costo, que se suma al costo del Sistema que sin ellas puede funcionar. Clasificacin obtenida de apunte de ctedra. Atributos: Los atributos de los Sistemas, definen al Sistema tal como lo conocemos u observamos. Los atributos pueden ser definidores o concomitantes: los atributos definidores son aquellos sin los cuales una entidad no sera 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 trmino que describe la unidad. Contexto: Un Sistema siempre estar relacionado con el contexto que lo rodea, o sea, el conjunto de objetos exteriores al Sistema, pero que influyen decididamente a ste, y a su vez el Sistema influye, aunque en una menor proporcin, influye sobre el contexto; se trata de una relacin mutua de contexto-Sistema. Tanto en la Teora de los Sistemas como en el mtodo cientfico, existe un concepto que es comn a ambos: el foco de atencin, el elemento que se asla para estudiar. El contexto a analizar depende fundamentalmente del foco de atencin que se fije. Ese foco de atencin, en trminos de Sistemas, se llama lmite de inters. Para determinar este lmite se consideraran dos etapas por separado: a) La determinacin del contexto de inters. b) La determinacin del alcance del lmite de inters entre el contexto y el Sistema. a) Se suele representar como un crculo que encierra al Sistema, y que deja afuera del lmite de inters a la parte del contexto que no interesa al analista. d) En lo que hace a las relaciones entre el contexto y los Sistemas y viceversa. Es posible que slo interesen algunas de estas relaciones, con lo que habr un lmite de inters relacional. Determinar el lmite de inters es fundamental para marcar el foco de anlisis, puesto que slo ser considerado lo que quede dentro de ese lmite. Entre el Sistema y el contexto, determinado con un lmite de inters, existen infinitas relaciones. Generalmente no se toman todas, sino aquellas que interesan al anlisis, o aquellas que probabilsticamente presentan las mejores caractersticas de prediccin cientfica. Rango: En el universo existen distintas estructuras de Sistemas y es factible ejercitar en ellas un proceso de definicin de rango relativo. Esto producira una jerarquizacin de las distintas estructuras en funcin de su grado de complejidad.
Elaborados por: Lic. Martin Valencia Pg. 6
INSTITUTO TECNOLGICO DE JIQUILPAN Apuntes de Fundamentos de Desarrollo de Sistemas Ingeniera en Sistemas Computacionales Plan 2004
Cada rango o jerarqua marca con claridad una dimensin que acta como un indicador claro de las diferencias que existen entre los subSistemas respectivos. Esta concepcin denota que un Sistema de nivel 1 es diferente de otro de nivel 8 y que, en consecuencia, no pueden aplicarse los mismos modelos, ni mtodos anlogos a riesgo de cometer evidentes falacias metodolgicas y cientficas. Para aplicar el concepto de rango, el foco de atencin 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. Refirindonos a los rangos hay que establecer los distintos subSistemas. Cada Sistema puede ser fraccionado en partes sobre la base de un elemento comn o en funcin de un mtodo lgico de deteccin. El concepto de rango indica la jerarqua de los respectivos subSistemas entre s y su nivel de relacin con el Sistema mayor.
SubSistemas: En la misma definicin de Sistema, 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. Estos conjuntos o partes pueden ser a su vez Sistemas (en este caso seran subSistemas del Sistema de definicin), ya que conforman un todo en s mismos y estos seran de un rango inferior al del Sistema que componen. Estos subSistemas forman o componen un Sistema de un rango mayor, el cual para los primeros se denomina macroSistema. Variables: Cada Sistema y subSistema contiene un proceso interno que se desarrolla sobre la base de la accin, interaccin y reaccin de distintos elementos que deben necesariamente conocerse. Dado que dicho proceso es dinmico, suele denominarse como variable, a cada elemento que compone o existe dentro de los Sistemas y subSistemas. Pero no todo es tan fcil como parece a simple vista ya que no todas las variables tienen el mismo comportamiento sino que, por lo contrario, segn el proceso y las caractersticas del mismo, asumen comportamientos diferentes dentro del mismo proceso de acuerdo al momento y las circunstancias que las rodean. Parmetro: Uno de los comportamientos que puede tener una variable es el de parmetro, que es cuando una variable no tiene cambios ante alguna circunstancia especfica, no quiere decir que la variable es esttica ni mucho menos, ya que slo permanece inactiva o esttica frente a una situacin determinada.
Elaborados por: Lic. Martin Valencia Pg. 7
INSTITUTO TECNOLGICO DE JIQUILPAN Apuntes de Fundamentos de Desarrollo de Sistemas Ingeniera en Sistemas Computacionales Plan 2004
Operadores: Otro comportamiento es el de operador, que son las variables que activan a las dems y logran influir decisivamente en el proceso para que este se ponga en marcha. Se puede decir que estas variables actan como lderes de las restantes y por consiguiente son privilegiadas respecto a las dems variables. Cabe aqu una aclaracin: las restantes variables no solamente son influidas por los operadores, sino que tambin son influenciadas por el resto de las variables y estas tienen tambin influencia sobre los operadores. Retroalimentacin: La retroalimentacin se produce cuando las salidas del Sistema o la influencia de stas en el contexto, vuelven a ingresar al Sistema como recursos o informacin. La retroalimentacin permite el control de un Sistema y que el mismo tome medidas de correccin en base a la informacin retroalimentada. Feed-forward o alimentacin delantera: Es una forma de control de los Sistemas, donde dicho control se realiza a la entrada del Sistema, de tal manera que el mismo no tenga entradas corruptas o malas, de esta forma al no haber entradas malas en el Sistema, las fallas no sern consecuencia de las entradas sino de los proceso mismos que componen al Sistema. Homeostasis y entropa: La homeostasis es la propiedad de un Sistema que define su nivel de respuesta y de adaptacin al contexto. Es el nivel de adaptacin permanente del Sistema o su tendencia a la supervivencia dinmica. Los Sistemas altamente homeostticos sufren transformaciones estructurales en igual medida que el contexto sufre transformaciones, ambos actan como condicionantes del nivel de evolucin. La entropa de un Sistema es el desgaste que el Sistema presenta por el transcurso del tiempo o por el funcionamiento del mismo. Los Sistemas altamente entrpicos tienden a desaparecer por el desgaste generado por su proceso sistmico. Los mismos deben tener rigurosos Sistemas de control y mecanismos de revisin, reelaboracin y cambio permanente, para evitar su desaparicin a travs del tiempo. En un Sistema cerrado la entropa siempre debe ser positiva. Sin embargo en los Sistemas abiertos biolgicos o sociales, la entropa puede ser reducida o mejor an transformarse en entropa negativa, es decir, un proceso de organizacin ms completa y de capacidad para transformar los recursos. Esto es posible porque en los Sistemas abiertos los recursos utilizados para reducir el proceso de entropa se toman del medio externo. Asimismo, los Sistemas vivientes se mantienen en un estado estable y pueden evitar el incremento de la entropa y aun desarrollarse hacia estados de orden y de organizacin creciente. Permeabilidad: La permeabilidad de un Sistema mide la interaccin que este recibe del medio, se dice que a mayor o menor permeabilidad del Sistema el mismo ser ms o menos abierto.
Elaborados por: Lic. Martin Valencia Pg. 8
INSTITUTO TECNOLGICO DE JIQUILPAN Apuntes de Fundamentos de Desarrollo de Sistemas Ingeniera en Sistemas Computacionales Plan 2004
Los Sistemas que tienen mucha relacin con el medio en el cul se desarrollan son Sistemas altamente permeables, estos y los de permeabilidad media son los llamados Sistemas abiertos. Por el contrario los Sistemas de permeabilidad casi nula se denominan Sistemas cerrados. Integracin 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 dems subSistemas y hasta en el Sistema mismo. Un Sistema es independiente cuando un cambio que se produce en l, no afecta a otros Sistemas. Centralizacin y descentralizacin: Un Sistema se dice centralizado cuando tiene un ncleo que comanda a todos los dems, y estos dependen para su activacin del primero, ya que por s solos no son capaces de generar ningn proceso. Por el contrario los Sistemas descentralizados son aquellos donde el ncleo de comando y decisin est formado por varios subSistemas. En dicho caso el Sistema no es tan dependiente, sino que puede llegar a contar con subSistemas que actan de reserva y que slo se ponen en funcionamiento cuando falla el Sistema que debera actuar en dicho caso. Los Sistemas centralizados se controlan ms fcilmente que los descentralizados, son ms sumisos, requieren menos recursos, pero son ms lentos en su adaptacin al contexto. Por el contrario los Sistemas descentralizados tienen una mayor velocidad de respuesta al medio ambiente pero requieren mayor cantidad de recursos y mtodos de coordinacin y de control ms elaborados y complejos. Adaptabilidad: Es la propiedad que tiene un Sistema de aprender y modificar un proceso, un estado o una caracterstica de acuerdo a las modificaciones que sufre el contexto. Esto se logra a travs de un mecanismo de adaptacin que permita responder a los cambios internos y externos a travs del tiempo. Para que un Sistema pueda ser adaptable debe tener un fluido intercambio con el medio en el que se desarrolla. Mantenibilidad: Es la propiedad que tiene un Sistema de mantenerse constantemente en funcionamiento. Para ello utiliza un mecanismo de mantenimiento que asegure que los distintos subSistemas estn balanceados y que el Sistema total se mantiene en equilibrio con su medio. Estabilidad: Un Sistema se dice estable cuando puede mantenerse en equilibrio a travs del flujo continuo de materiales, energa e informacin.
Elaborados por:
Pg. 9
INSTITUTO TECNOLGICO DE JIQUILPAN Apuntes de Fundamentos de Desarrollo de Sistemas Ingeniera en Sistemas Computacionales Plan 2004
La estabilidad de los Sistemas ocurre mientras los mismos pueden mantener su funcionamiento y trabajen de manera efectiva (mantenibilidad). Armona: Es la propiedad de los Sistemas que mide el nivel de compatibilidad con su medio o contexto. Un Sistema altamente armnico es aquel que sufre modificaciones en su estructura, proceso o caractersticas en la medida que el medio se lo exige y es esttico cuando el medio tambin lo es. Optimizacin y sub-optimizacin: Optimizacin modificar el Sistema para lograr el alcance de los objetivos. Suboptimizacin en cambio es el proceso inverso, se presenta cuando un Sistema no alcanza sus objetivos por las restricciones del medio o porque el Sistema tiene varios objetivos y los mismos son excluyentes, en dicho caso se deben restringir los alcances de los objetivos o eliminar los de menor importancia si estos son excluyentes con otros ms importantes. xito: El xito de los Sistemas es la medida en que los mismos alcanzan sus objetivos. La falta de xito exige una revisin del Sistema ya que no cumple con los objetivos propuestos para el mismo, de modo que se modifique dicho Sistema de forma tal que el mismo pueda alcanzar los objetivos determinados. Aportes Metodolgicos: Jerarqua de los Sistemas Al considerar los distintos tipos de Sistemas del universo Kennet Boulding proporciona una clasificacin til de los Sistemas donde establece los siguientes niveles jerrquicos: 1. Primer nivel, estructura esttica. Se le puede llamar nivel de los marcos de referencia. 2. Segundo nivel, Sistema dinmico simple. Considera movimientos necesarios y predeterminados. Se puede denominar reloj de trabajo. 3. Tercer nivel, mecanismo de control o Sistema ciberntico. El Sistema se autorregula para mantener su equilibrio. 4. Cuarto nivel, Sistema abierto o autoestructurado. En este nivel se comienza a diferenciar la vida. Puede de considerarse nivel de clula. 5. Quinto nivel, gentico-social. Est caracterizado por las plantas. 6. Sexto nivel, Sistema animal. Se caracteriza por su creciente movilidad, comportamiento teleolgico y su autoconciencia.
Elaborados por: Lic. Martin Valencia Pg. 10
INSTITUTO TECNOLGICO DE JIQUILPAN Apuntes de Fundamentos de Desarrollo de Sistemas Ingeniera en Sistemas Computacionales Plan 2004
7. Sptimo nivel, Sistema humano. Es el nivel del ser individual, considerado como un Sistema con conciencia y habilidad para utilizar el lenguaje y smbolos. 8. Octavo nivel, Sistema social o Sistema de organizaciones humanas constituye el siguiente nivel, y considera el contenido y significado de mensajes, la naturaleza y dimensiones del Sistema de valores, la transcripcin de imgenes en registros histricos, sutiles simbolizaciones artsticas, msica, poesa y la compleja gama de emociones humanas. 9. Noveno nivel, Sistemas trascendentales. Completan los niveles de clasificacin: estos son los ltimos y absolutos, los ineludibles y desconocidos, los cuales tambin presentan estructuras sistemticas e interrelaciones. Teora analgica o modelo de isomorfismo sistmico: Este modelo busca integrar las relaciones entre fenmenos de las distintas ciencias. La deteccin de estos fenmenos permite el armado de modelos de aplicacin para distintas reas de las ciencias. Esto, que se repite en forma permanente, exige un anlisis iterativo que responde a la idea de modularidad que la teora de los Sistemas desarrolla en sus contenidos. Se pretende por comparaciones sucesivas, una aproximacin metodolgica, a la vez que facilitar la identificacin de los elementos equivalentes o comunes, y permitir una correspondencia biunvoca entre las distintas ciencias. Como evidencia de que existen propiedades generales entre distintos Sistemas, se identifican y extraen sus similitudes estructurales. Estos elementos son la esencia de la aplicacin del modelo de isomorfismo, es decir, la correspondencia entre principios que rigen el comportamiento de objetos que, si bien intrnsecamente son diferentes, en algunos aspectos registran efectos que pueden necesitar un mismo procedimiento. 1.1.1 Descripcin General de Sistemas: Es un conjunto organizado de cosas o partes interactuantes e interdependientes, que se relacionan formando un todo unitario y complejo. Cabe aclarar que las cosas o partes que componen al Sistema, no se refieren al campo fsico (objetos), sino ms bien al funcional. De este modo las cosas o partes pasan a ser funciones bsicas realizadas por el Sistema. Podemos enumerarlas en: entradas, Procesos y Salidas. CONCEPTO DE SISTEMAS 1. Un conjunto de elementos 2. Dinmicamente relacionados 3. Formando una actividad 4. Para alcanzar un objetivo
Elaborados por: Lic. Martin Valencia Pg. 11
INSTITUTO TECNOLGICO DE JIQUILPAN Apuntes de Fundamentos de Desarrollo de Sistemas Ingeniera en Sistemas Computacionales Plan 2004
5. Operando sobre datos/energa/materia 6. Para proveer informacin/energa/materia Entradas: Las entradas son los ingresos del Sistema que pueden ser recursos materiales, recursos humanos o informacin. Las entradas constituyen la fuerza de arranque que suministra al Sistema sus necesidades operativas. Las entradas pueden ser: - en serie: es el resultado o la salida de un Sistema anterior con el cual el Sistema en estudio est relacionado en forma directa. - aleatoria: es decir, al azar, donde el trmino azar se utiliza en el sentido estadstico. Las entradas aleatorias representan entradas potenciales para un Sistema. - retroaccin: es la reintroduccin de una parte de las salidas del Sistema en s mismo. Clasificacin extrada de apunte de ctedra. Proceso: El proceso es lo que transforma una entrada en salida, como tal puede ser una mquina, un individuo, una computadora, un producto qumico, una tarea realizada por un miembro de la organizacin, etc. En la transformacin de entradas en salidas debemos saber siempre como se efecta esa transformacin. Con frecuencia el procesador puede ser diseado por el administrador. En tal caso, este proceso se denomina caja blanca. No obstante, en la mayor parte de las situaciones no se conoce en sus detalles el proceso mediante el cual las entradas se transforman en salidas, porque esta transformacin es demasiado compleja. Diferentes combinaciones de entradas o su combinacin en diferentes rdenes de secuencia pueden originar diferentes situaciones de salida. En tal caso la funcin de proceso se denomina una caja negra. Caja Negra: La caja negra se utiliza para representar a los Sistemas cuando no sabemos que elementos o cosas componen al Sistema o proceso, pero sabemos que a determinadas corresponden determinadas salidas y con ello poder inducir, presumiendo que a determinados estmulos, las variables funcionaran en cierto sentido. Salidas: Las salidas de los Sistemas son los resultados que se obtienen de procesar las entradas. Al igual que las entradas estas pueden adoptar la forma de productos, servicios e informacin. Las mismas son el resultado del funcionamiento del Sistema o, alternativamente, el propsito para el cual existe el Sistema.
Elaborados por:
Pg. 12
INSTITUTO TECNOLGICO DE JIQUILPAN Apuntes de Fundamentos de Desarrollo de Sistemas Ingeniera en Sistemas Computacionales Plan 2004
Las salidas de un Sistema se convierte en entrada de otro, que la procesar para convertirla en otra salida, repitindose este ciclo indefinidamente. Relaciones: Las relaciones son los enlaces que vinculan entre s a los objetos o subSistemas que componen a un Sistema complejo. Podemos clasificarlas en: - Simbiticas: es aquella en que los Sistemas conectados no pueden seguir funcionando solos. A su vez puede subdividirse en unipolar o parasitaria, que es cuando un Sistema (parsito) no puede vivir sin el otro Sistema (planta); y bipolar o mutual, que es cuando ambos Sistemas dependen entre si. - Sinrgica: es una relacin que no es necesaria para el funcionamiento pero que resulta til, ya que su desempeo mejora sustancialmente al desempeo del Sistema. Sinergia significa accin combinada. Sin embargo, para la teora de los Sistemas el trmino significa algo ms que el esfuerzo cooperativo. En las relaciones sinrgicas la accin cooperativa de subSistemas semi-independientes, tomados en forma conjunta, origina un producto total mayor que la suma de sus productos tomados de una manera independiente. - Superflua: Son las que repiten otras relaciones. La razn de las relaciones superfluas es la confiabilidad. Las relaciones superfluas aumentan la probabilidad de que un Sistema funcione todo el tiempo y no una parte del mismo. Estas relaciones tienen un problema que es su costo, que se suma al costo del Sistema que sin ellas puede funcionar. Clasificacin obtenida de apunte de ctedra. Atributos: Los atributos de los Sistemas, definen al Sistema tal como lo conocemos u observamos. Los atributos pueden ser definidores o concomitantes: los atributos definidores son aquellos sin los cuales una entidad no sera 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 trmino que describe la unidad. Contexto: Un Sistema siempre estar relacionado con el contexto que lo rodea, o sea, el conjunto de objetos exteriores al Sistema, pero que influyen decididamente a ste, y a su vez el Sistema influye, aunque en una menor proporcin, influye sobre el contexto; se trata de una relacin mutua de contexto-Sistema. Tanto en la Teora de los Sistemas como en el mtodo cientfico, existe un concepto que es comn a ambos: el foco de atencin, el elemento que se asla para estudiar. El contexto a analizar depende fundamentalmente del foco de atencin que se fije. Ese foco de atencin, en trminos de Sistemas, se llama lmite de inters. Para determinar este lmite se consideraran dos etapas por separado:
Elaborados por: Lic. Martin Valencia Pg. 13
INSTITUTO TECNOLGICO DE JIQUILPAN Apuntes de Fundamentos de Desarrollo de Sistemas Ingeniera en Sistemas Computacionales Plan 2004
a) La determinacin del contexto de inters. b) La determinacin del alcance del lmite de inters entre el contexto y el Sistema. a) Se suele representar como un crculo que encierra al Sistema, y que deja afuera del lmite de inters a la parte del contexto que no interesa al analista. d) En lo que hace a las relaciones entre el contexto y los Sistemas y viceversa. Es posible que slo interesen algunas de estas relaciones, con lo que habr un lmite de inters relacional. Determinar el lmite de inters es fundamental para marcar el foco de anlisis, puesto que slo ser considerado lo que quede dentro de ese lmite. Entre el Sistema y el contexto, determinado con un lmite de inters, existen infinitas relaciones. Generalmente no se toman todas, sino aquellas que interesan al anlisis, o aquellas que probabilsticamente presentan las mejores caractersticas de prediccin cientfica. Rango: En el universo existen distintas estructuras de Sistemas y es factible ejercitar en ellas un proceso de definicin de rango relativo. Esto producira una jerarquizacin de las distintas estructuras en funcin de su grado de complejidad. Cada rango o jerarqua marca con claridad una dimensin que acta como un indicador claro de las diferencias que existen entre los subSistemas respectivos. Esta concepcin denota que un Sistema de nivel 1 es diferente de otro de nivel 8 y que, en consecuencia, no pueden aplicarse los mismos modelos, ni mtodos anlogos a riesgo de cometer evidentes falacias metodolgicas y cientficas. Para aplicar el concepto de rango, el foco de atencin 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. Refirindonos a los rangos hay que establecer los distintos subSistemas. Cada Sistema puede ser fraccionado en partes sobre la base de un elemento comn o en funcin de un mtodo lgico de deteccin. El concepto de rango indica la jerarqua de los respectivos subSistemas entre s y su nivel de relacin con el Sistema mayor.
SubSistemas: En la misma definicin de Sistema, 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. Estos conjuntos o partes pueden ser a su vez Sistemas (en este caso seran subSistemas del Sistema de definicin), ya que conforman un todo en s mismos y estos seran de un rango inferior al del Sistema que componen.
Elaborados por: Lic. Martin Valencia Pg. 14
INSTITUTO TECNOLGICO DE JIQUILPAN Apuntes de Fundamentos de Desarrollo de Sistemas Ingeniera en Sistemas Computacionales Plan 2004
Estos subSistemas forman o componen un Sistema de un rango mayor, el cual para los primeros se denomina macroSistema. Variables: Cada Sistema y subSistema contiene un proceso interno que se desarrolla sobre la base de la accin, interaccin y reaccin de distintos elementos que deben necesariamente conocerse. Dado que dicho proceso es dinmico, suele denominarse como variable, a cada elemento que compone o existe dentro de los Sistemas y subSistemas. Pero no todo es tan fcil como parece a simple vista ya que no todas las variables tienen el mismo comportamiento sino que, por lo contrario, segn el proceso y las caractersticas del mismo, asumen comportamientos diferentes dentro del mismo proceso de acuerdo al momento y las circunstancias que las rodean. Parmetro: Uno de los comportamientos que puede tener una variable es el de parmetro, que es cuando una variable no tiene cambios ante alguna circunstancia especfica, no quiere decir que la variable es esttica ni mucho menos, ya que slo permanece inactiva o esttica frente a una situacin determinada. Operadores: Otro comportamiento es el de operador, que son las variables que activan a las dems y logran influir decisivamente en el proceso para que este se ponga en marcha. Se puede decir que estas variables actan como lderes de las restantes y por consiguiente son privilegiadas respecto a las dems variables. Cabe aqu una aclaracin: las restantes variables no solamente son influidas por los operadores, sino que tambin son influenciadas por el resto de las variables y estas tienen tambin influencia sobre los operadores. Retroalimentacin: La retroalimentacin se produce cuando las salidas del Sistema o la influencia de las salidas del Sistema en el contexto, vuelven a ingresar al Sistema como recursos o informacin. La retroalimentacin permite el control de un Sistema y que el mismo tome medidas de correccin en base a la informacin retroalimentada. Feed-forward o alimentacin delantera: Es una forma de control de los Sistemas, donde dicho control se realiza a la entrada del Sistema, de tal manera que el mismo no tenga entradas corruptas o malas, de esta forma al no haber entradas malas en el Sistema, las fallas no sern consecuencia de las entradas sino de los proceso mismos que componen al Sistema. Homeostasis y entropa:
Elaborados por:
Pg. 15
INSTITUTO TECNOLGICO DE JIQUILPAN Apuntes de Fundamentos de Desarrollo de Sistemas Ingeniera en Sistemas Computacionales Plan 2004
La homeostasis es la propiedad de un Sistema que define su nivel de respuesta y de adaptacin al contexto. Es el nivel de adaptacin permanente del Sistema o su tendencia a la supervivencia dinmica. Los Sistemas altamente homeostticos sufren transformaciones estructurales en igual medida que el contexto sufre transformaciones, ambos actan como condicionantes del nivel de evolucin. La entropa de un Sistema es el desgaste que el Sistema presenta por el transcurso del tiempo o por el funcionamiento del mismo. Los Sistemas altamente entrpicos tienden a desaparecer por el desgaste generado por su proceso sistmico. Los mismos deben tener rigurosos Sistemas de control y mecanismos de revisin, reelaboracin y cambio permanente, para evitar su desaparicin a travs del tiempo. En un Sistema cerrado la entropa siempre debe ser positiva. Sin embargo en los Sistemas abiertos biolgicos o sociales, la entropa puede ser reducida o mejor an transformarse en entropa negativa, es decir, un proceso de organizacin ms completa y de capacidad para transformar los recursos. Esto es posible porque en los Sistemas abiertos los recursos utilizados para reducir el proceso de entropa se toman del medio externo. Asimismo, los Sistemas vivientes se mantienen en un estado estable y pueden evitar el incremento de la entropa y aun desarrollarse hacia estados de orden y de organizacin creciente. Permeabilidad: La permeabilidad de un Sistema mide la interaccin que este recibe del medio, se dice que a mayor o menor permeabilidad del Sistema el mismo ser ms o menos abierto. Los Sistemas que tienen mucha relacin con el medio en el cul se desarrollan son Sistemas altamente permeables, estos y los de permeabilidad media son los llamados Sistemas abiertos. Por el contrario los Sistemas de permeabilidad casi nula se denominan Sistemas cerrados. Integracin 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 dems subSistemas y hasta en el Sistema mismo. Un Sistema es independiente cuando un cambio que se produce en l, no afecta a otros Sistemas. Centralizacin y descentralizacin: Un Sistema se dice centralizado cuando tiene un ncleo que comanda a todos los dems, y estos dependen para su activacin del primero, ya que por s solos no son capaces de generar ningn proceso. Por el contrario los Sistemas descentralizados son aquellos donde el ncleo de comando y decisin est formado por varios subSistemas. En dicho caso el Sistema no es tan dependiente, sino que puede llegar a contar con subSistemas que actan de reserva y que slo se ponen en funcionamiento cuando falla el Sistema que debera actuar en dicho caso. Los Sistemas centralizados se controlan ms fcilmente que los descentralizados, son ms sumisos, requieren menos recursos, pero son ms lentos en su adaptacin al contexto. Por el contrario los Sistemas
Elaborados por: Lic. Martin Valencia Pg. 16
INSTITUTO TECNOLGICO DE JIQUILPAN Apuntes de Fundamentos de Desarrollo de Sistemas Ingeniera en Sistemas Computacionales Plan 2004
descentralizados tienen una mayor velocidad de respuesta al medio ambiente pero requieren mayor cantidad de recursos y mtodos de coordinacin y de control ms elaborados y complejos. Adaptabilidad: Es la propiedad que tiene un Sistema de aprender y modificar un proceso, un estado o una caracterstica de acuerdo a las modificaciones que sufre el contexto. Esto se logra a travs de un mecanismo de adaptacin que permita responder a los cambios internos y externos a travs del tiempo. Para que un Sistema pueda ser adaptable debe tener un fluido intercambio con el medio en el que se desarrolla. Mantenibilidad: Es la propiedad que tiene un Sistema de mantenerse constantemente en funcionamiento. Para ello utiliza un mecanismo de mantenimiento que asegure que los distintos subSistemas estn balanceados y que el Sistema total se mantiene en equilibrio con su medio. Estabilidad: Un Sistema se dice estable cuando puede mantenerse en equilibrio a travs del flujo continuo de materiales, energa e informacin. La estabilidad de los Sistemas ocurre mientras los mismos pueden mantener su funcionamiento y trabajen de manera efectiva (mantenibilidad). Armona: Es la propiedad de los Sistemas que mide el nivel de compatibilidad con su medio o contexto. Un Sistema altamente armnico es aquel que sufre modificaciones en su estructura, proceso o caractersticas en la medida que el medio se lo exige y es esttico cuando el medio tambin lo es. Optimizacin y sub-optimizacin: Optimizacin modificar el Sistema para lograr el alcance de los objetivos. Suboptimizacin en cambio es el proceso inverso, se presenta cuando un Sistema no alcanza sus objetivos por las restricciones del medio o porque el Sistema tiene varios objetivos y los mismos son excluyentes, en dicho caso se deben restringir los alcances de los objetivos o eliminar los de menor importancia si estos son excluyentes con otros ms importantes. xito: El xito de los Sistemas es la medida en que los mismos alcanzan sus objetivos. La falta de xito exige una revisin del Sistema ya que no cumple con los objetivos propuestos para el mismo, de modo que se modifique dicho Sistema de forma tal que el mismo pueda alcanzar los objetivos determinados.
Elaborados por: Lic. Martin Valencia Pg. 17
INSTITUTO TECNOLGICO DE JIQUILPAN Apuntes de Fundamentos de Desarrollo de Sistemas Ingeniera en Sistemas Computacionales Plan 2004
1.1.2 Tipos de Sistemas Sistemas de Transacciones: Son llamados TPS cuyas siglas corresponden a Transaction Processing System, o Sistemas de procesamiento de transacciones. Un ejemplo es la Corporacin Financiera Internacional (CFI), filial del Banco Internacional para la Reconstruccin y el Desarrollo, cuyo Sistema de transacciones funciona de la siguiente manera: El CFI busca inversores interesados en los pases ms desarrollados y el capital provedo por stos, es transferido a empresas privadas de pases subdesarrollados cuyo capital privado no basta. Otro ejemplo es el de la industria naviera, el cual por medio de su Sistema de transacciones internacionales transportan diferentes tipos de carga de acuerdo a pedidos en diferentes pases, siendo uno de los ms transportados el petrleo, cuyos pedidos pueden ser ya sea privado o por contrato. Los barcos transportan el petrleo desde los campos petrolferos a las refineras, siguiendo una serie de tratados y convenciones internacionales. Sistemas de Conocimiento: KWS, knowledge work system, o Sistema de manejo de conocimiento. Un ejemplo es el de aplicaciones como Photoshop, la cual ayuda a diseadores grficos en crear su arte publicitario por medio de poderosas herramientas con las cuales se puede manipular y modificar distintos tipos de grficos y fotografas.
Sistemas Expertos: AI, artificial intelligence, o inteligencia artificial. Un famoso Sistema experto es MYCIN, el cual es un Sistema experto para la realizacin de diagnsticos, el cual aconseja a los mdicos en la investigacin y determinacin de diagnsticos en el campo de las enfermedades infecciosas de la sangre. El Sistema MYCIN, al ser consultado por el mdico, solicita primero datos generales sobre el paciente: nombre, edad, sntomas, etc. Una vez conocida esta informacin por parte del Sistema, el Sistema Experto plantea unas hiptesis. Para verificar la hiptesis el Sistema consulta a la base de conocimientos, y tambin haciendo una serie de preguntas al usuario. Con las respuestas que recibe, el MYCIN verifica o rechaza las hiptesis planteadas. Otro Sistema experto es el XCON el cual es un Sistema experto de configuraciones el cual, segn las especificaciones del cliente, configura redes de ordenadores VAX. Tiene como base de su funcionamiento las siguientes dos preguntas: 1. Pueden conjugarse los componentes solicitados por el cliente de forma conveniente y razonable? 2. Los componentes de Sistema especificados son compatibles y completos?
Elaborados por: Lic. Martin Valencia Pg. 18
INSTITUTO TECNOLGICO DE JIQUILPAN Apuntes de Fundamentos de Desarrollo de Sistemas Ingeniera en Sistemas Computacionales Plan 2004
Las respuestas a estas preguntas son muy detalladas. XCON es capaz de comprobar y completar los pedidos entrantes mucho ms rpido y mejor que las personas encargadas hasta ahora de esa labor. Sistemas de Apoyo a Grupos: GDSS, group decission support system, o Sistemas de apoyo a decisiones de grupo. Un Sistema GDSS es el Vision Quest, el cual permite realizar junta electrnicas. Entre sus ventajas se encuentra su facilidad de uso. Cualquiera puede conducir una junta electrnica y el Sistema puede ser usado de manera distribuida. Las juntas se pueden realizar con los participantes en el mismo lugar o diferentes lugares, al mismo tiempo o a distintos tiempos. Aunque no pretende reemplazar las juntas cara a cara, su uso permite reducir los costos de viaje, la rapidez de toma de decisiones lo que resulta en una mejor eficiencia y productividad de las juntas. El Sistema funciona en terminales de trabajo que pueden estar o no en el mismo lugar, la interaccin se realiza a travs del teclado y el monitor de la computadora. Otro Sistema es el CRUISER cuyas siglas son para Computer Supported Spontaneous Interaction. La importancia de este Sistema se basa en la interaccin informal. CRUISER est diseado alrededor del concepto de comunidad o grupo virtual que existe slo en un mundo virtual, donde las distancias geogrficas entre los participantes no son importantes. Por sus caractersticas este Sistema provee acceso instantneo a cualquier persona y cualquier lugar. La importancia del Sistema est basada en dos ideas. La primera, los usuarios pueden navegar a travs del mundo virtual en bsqueda de encuentros sociales. La segunda, el mundo virtual es independiente del mundo fsico y puede ser organizado de acuerdo a las necesidades del usuario. En la prctica el usuario recorre pasillos, oficinas y reas comunes, todas ellas generadas por computadora. Los usuarios se comunican a travs de audio y video. CRUISER ataca uno de los problemas de los trabajos en equipo, reconoce la importancia de la comunicacin informal. Provee adems caractersticas de la prctica de trabajo permitindole diferentes niveles de privacidad. Sistemas de ejecutivos: ESS, executive support system, o Sistemas de apoyo a ejecutivos. Un ejemplo es el Sistema comprado por Pratt & Whitney, una corporacin que se dedica a la produccin de motores de propulsin a chorro. Ellos compraron el Sistema denominado Commander EIS que permite representaciones a todo color y un men imaginativo que puede aprenderse intuitivamente, con variaciones y excepciones que son destacadas mediante colores. Los usuarios pueden accesar datos mediante una pantalla tctil, ratn o teclado y pueden agrandar las imgenes para mayores niveles de detalle, ya sea navegando por s mismos o siguiendo caminos previamente definidos. El Commnander EIS permite a la organizacin hacer el seguimiento de los parmetros de la calidad y factibilidad de las medidas tomadas para cada motor a reaccin por tipo de cliente. Los datos aparecen de los Sistemas actuales de produccin y proporcionan informacin sobre la confiabilidad, disponibilidad de motores y partes, y sobre las entregas. Otro ejemplo es el Sistema implantado por la New York State Office of General Services que es responsable de dar servicio a otras dependencias en Nueva York. El Sistema permite que los ejecutivos verifiquen el estado por programa, comparando el presupuesto con el gasto real y mostrando el gasto estimado hasta el final del ao fiscal. La administracin puede bajar para ver los detalles especficos en
Elaborados por: Lic. Martin Valencia Pg. 19
INSTITUTO TECNOLGICO DE JIQUILPAN Apuntes de Fundamentos de Desarrollo de Sistemas Ingeniera en Sistemas Computacionales Plan 2004
cada categora. El Sistema slo contiene datos crudos, permitiendo a los usuarios una gran flexibilidad para agregarlos y analizarlos para satisfacer sus necesidades. El Sistema es operado por medio de un men muy fcil de usar. Los nuevos usuarios son capacitados mediante una demostracin que dura media hora, y la experiencia ha demostrado que es todo lo que necesitan. No se cuenta con un manual del usuario.
1.1.3 Clasificacin En este mdulo algunas de las clasificaciones bsicas de Sistemas sern temporalmente introducidas mientras que las propiedades ms importantes de Sistemas sern explicadas. Como puede ser visto, las propiedades de los Sistemas proveen una manera sencilla de separar un Sistema de otro. Entender la diferencia bsica entre Sistemas, y sus propiedades, ser un concepto fundamental utilizado en todos los cursos de seales y Sistemas, as como de procesamiento digital de seales (Digital Signal Processing) DSP. Una vez que el conjunto de seales puede ser identificado por compartir propiedades particulares, uno ya no tiene que proveer ciertas caractersticas del Sistema cada vez, pero pueden ser aceptadas debido a la clasificacin de los Sistemas. Tambin cabe recordar que las clasificaciones presentadas aqu pueden no ser exclusivas (los Sistemas pueden pertenecer a diferentes clasificaciones) ni nicas (hay otros mtodos de clasificacin). Algunos ejemplos de Sistemas simples se podrn encontrar aqu. Clasificacin de los Sistemas A travs de la siguiente clasificacin, tambin es importante entender otras Clasificaciones de Seales y se clasifican de la siguiente forma.
a) Por su naturaleza: b) Naturales: Sistemas creados en los que el hombre no interviene en su creacin. 1.-Artificiales: Sistemas creados por el hombre. c) Por su relacin con el Medio Ambiente:
Elaborados por: Lic. Martin Valencia Pg. 20
INSTITUTO TECNOLGICO DE JIQUILPAN Apuntes de Fundamentos de Desarrollo de Sistemas Ingeniera en Sistemas Computacionales Plan 2004
1.-Abierto: Sistemas que interactan con el contexto, intercambiando elementos, sin esta interaccin no podran existir. 2.-Cerrado: Sistemas aislados, no interaccionan con el contexto. d) Por su dependencia del Medio Ambiente 1.-Adaptable (dinmico): Sistemas que ante un cambio en el contexto reaccionan en forma adecuada, teniendo en cuenta la finalidad para la que fueron creados. 2.-No adaptable (esttico): no modifican su conducta y/o estructura a pesar de cambios en el medio ambiente.
e) Caractersticas de los Sistemas f) Todo Sistema cualquiera sea su naturaleza tiene las siguientes caractersticas bsicas: 1.-Todo Sistema contiene otros Sistemas y/o subSistemas y a la vez est contenido en otros Sistemas de carcter superior. Esto da como resultado una autntica categorizacin de supraSistemas (medio ambiente), Sistemas y subSistemas. 2.-Todos los componentes de un Sistema, as como sus interrelaciones, actan y operan en funcin de los objetivos del Sistema. Se dice que los objetivos constituyen el factor o elemento que aglutina e integra a todas las partes del conjunto. g) La alteracin o variacin de una de las partes o de sus relaciones, incide en las dems y en el conjunto. Elementos de los Sistemas Entradas Salidas Procesos Retroalimentacin Medio Ambiente
Entrada/Insumo/Input: Constituye los componentes que ingresan al Sistema, los cuales sern objeto de operaciones y/o procesos hasta transformarse en salidas. Salida/Producto/Output: Son la expresin material de los objetivos del Sistema, son los fines y las metas del Sistema. Proceso/Transformacin: Es el componente que transforma el estado original de las entradas en salidas. La transformacin es una serie de operaciones, reglas, procedimientos, que responden a una lgica y orden. Retroalimentacin: Son aquellas salidas del Sistema que se convierte en entradas del mismo. En general, la retroalimentacin se asocia al concepto de control, ya sea porque la salida es errnea o posee fallas o porque se puede mejorar el Sistema. Medio Ambiente (Contexto): En los Sistemas abiertos y adaptables, el Medio Ambiente tiene un papel preponderante, ya que el Sistema est permanentemente interactuando con l para lograr sus objetivos.
Lic. Martin Valencia Pg. 21
Elaborados por:
INSTITUTO TECNOLGICO DE JIQUILPAN Apuntes de Fundamentos de Desarrollo de Sistemas Ingeniera en Sistemas Computacionales Plan 2004
En general el medio ambiente es cambiante lo que ocasiona que el Sistema deba ser dinmico, revisarse y ajustarse a los cambios para poder lograr sus objetivos. El Medio Ambiente influye en forma determinante en el Sistema, mientras que el Sistema influye dbilmente en el Medio Ambiente. 1.2 Ciclo de Vida de un proyecto de Software. El mtodo de ciclo de vida para el desarrollo de Sistemas es el conjunto de actividades que los analistas, diseadores y usuarios realizan para desarrollar e implantar un Sistema de informacin. El mtodo del ciclo de vida para el desarrollo de Sistemas consta de 6 fases: 1). Investigacin Preliminar: La solicitud para recibir ayuda de un Sistema de informacin puede originarse por varias razones: sin importar cuales sean estas, el proceso se inicia siempre con la peticin de una persona. 2). Determinacin de los requerimientos del Sistema: El aspecto fundamental del anlisis de Sistemas es comprender todas las facetas importantes de la parte de la empresa que se encuentra bajo estudio. Los analistas, al trabajar con los empleados y administradores, deben estudiar los procesos de una empresa para dar respuesta a las siguientes preguntas clave: Qu es lo que hace? Cmo se hace? Con que frecuencia se presenta? Qu tan grande es el volumen de transacciones o decisiones? Cul es el grado de eficiencia con el que se efectan las tareas? Existe algn problema? Qu tan serio es? Cul es la causa que lo origina? 3). Diseo del Sistema: El diseo de un Sistema de informacin produce los detalles que establecen la forma en la que el Sistema cumplir con los requerimientos identificados durante la fase de anlisis. Los especialistas en Sistemas se refieren, con frecuencia, a esta etapa como diseo lgico en contraste con la del desarrollo del Software, a la que denominan diseo fsico. 4). Desarrollo del Software: Los encargados de desarrollar Software pueden instalar Software comprobando a terceros o escribir programas diseados a la medida del solicitante. La eleccin depende del costo de cada alternativa, del tiempo disponible para escribir el Software y de la disponibilidad de los programadores. Por lo general, los programadores que trabajan en las grandes organizaciones pertenecen a un grupo permanente de profesionales. 5). Prueba de Sistemas: Durante la prueba de Sistemas, el Sistema se emplea de manera experimental para asegurarse de que el Software no tenga fallas, es decir, que funciona de acuerdo con las especificaciones y en la forma en que los usuarios esperan que lo haga.
Elaborados por: Lic. Martin Valencia Pg. 22
INSTITUTO TECNOLGICO DE JIQUILPAN Apuntes de Fundamentos de Desarrollo de Sistemas Ingeniera en Sistemas Computacionales Plan 2004
Se alimentan como entradas conjunto de datos de prueba para su procesamiento y despus se examinan los resultados. 6). Implantacin y evaluacin: La implantacin es el proceso de verificar e instalar nuevo equipo, entrenar a los usuarios, instalar la aplicacin y construir todos los archivos de datos necesarios para utilizarla. Una vez instaladas, las aplicaciones se emplean durante muchos aos. Sin embargo, las organizaciones y los usuarios cambian con el paso del tiempo, incluso el ambiente es diferente con el paso de las semanas y los meses. Por consiguiente, es indudable que debe darse mantenimiento a las aplicaciones. La evaluacin de un Sistema se lleva a cabo para identificar puntos dbiles y fuertes. La evaluacin ocurre a lo largo de cualquiera de las siguientes dimensiones: *Evaluacin operacional: Valoracin de la forma en que funciona el Sistema, incluyendo su facilidad de uso, tiempo de respuesta, lo adecuado de los formatos de informacin, confiabilidad global y nivel de utilizacin. *Impacto organizacional: Identificacin y medicin de los beneficios para la organizacin en reas tales como finanzas, eficiencia operacional e impacto competitivo. Tambin se incluye el impacto sobre el flujo de informacin externo e interno. *Opinin de loa administradores: evaluacin de las actividades de directivos y administradores dentro de la organizacin as como de los usuarios finales. *Desempeo del desarrollo: La evaluacin de proceso de desarrollo de acuerdo con criterios tales como tiempo y esfuerzo de desarrollo, concuerdan con presupuestos y estndares, y otros criterios de administracin de proyectos. Tambin se incluye la valoracin de los mtodos y herramientas utilizados en el desarrollo. El desarrollo de Software va unido a un ciclo de vida compuesto por una serie de etapas que comprenden todas las actividades, desde el momento en que surge la idea de crear un nuevo producto Software, hasta aquel en que el producto deja definitivamente de ser utilizado por el ltimo de sus usuarios. Etapas en el ciclo. A grandes rasgos, una pequea descripcin de etapas con que podemos contar a lo largo del ciclo de vida del Software; una vez delimitadas en cierta manera las etapas, habr que ver la forma en que estas se afrontan (existen diversos modelos de ciclo de vida, y la eleccin de un cierto modelo para un determinado tipo de proyecto puede ser de vital importancia; el orden de las etapas es un factor importante, p.ej. tener una etapa de validacin al final del proyecto, tal como sugiere el modelo en cascada o lineal, puede implicar serios problemas sobre la gestin de determinados proyectos; hay que tener en cuenta que retomar etapas previas es costoso, y cuanto ms tarde se haga ms costoso resultar, por tanto el hecho de contar con una etapa de validacin tarda tiene su riesgo y, por su situacin en el ciclo, un posible tiempo de reaccin mnimo en caso de tener que retornar a fases previas): Expresin de necesidades Esta etapa tiene como objetivo la consecucin de un primer documento en que queden reflejados los requerimientos y funcionalidades que ofrecer al usuario del Sistema a desarrollar (qu, y no cmo, se va a desarrollar). Dado que normalmente se trata de necesidades del cliente para el que se crear la aplicacin, el documento resultante suele tener como origen una serie de entrevistas cliente-proveedor situadas en el contexto de una relacin comercial, siendo que debe ser comprendido por ambas partes (puede incluso tomarse como base para el propio acuerdo comercial).
Elaborados por: Lic. Martin Valencia Pg. 23
INSTITUTO TECNOLGICO DE JIQUILPAN Apuntes de Fundamentos de Desarrollo de Sistemas Ingeniera en Sistemas Computacionales Plan 2004
Especificaciones Ahora se trata de formalizar los requerimientos; el documento obtenido en la etapa anterior se tomar como punto de partida para esta fase. Su contenido es an insuficiente y lleno de imprecisiones que ser necesario completar y depurar. Por medio de esta etapa se obtendr un nuevo documento que definir con ms precisin el Sistema requerido por el cliente (el empleo de los casos de uso, use cases, de Jacobson es una muy buena eleccin para llevar a cabo la especificacin del Sistema). Lo ms normal ser que no resulte posible obtener una buena especificacin del Sistema a la primera; sern necesarias sucesivas versiones del documento en que irn quedando reflejada la evolucin de las necesidades del cliente (por una parte no siempre sabe en los primeros contactos todo lo que quiere realmente, y por otra parte pueden surgir cambios externos que supongan requerimientos nuevos o modificaciones de los ya contemplados). Anlisis Es necesario determinar que elementos intervienen en el Sistema a desarrollar, as como su estructura, relaciones, evolucin en el tiempo, detalle de sus funcionalidades, que van a dar una descripcin clara de qu Sistema vamos a construir, qu funcionalidades va a aportar y qu comportamiento va a tener. Para ello se enfocar el Sistema desde tres puntos de vista relacionados pero diferentes: Funcional. Esttico. Dinmico. Diseo Tras la etapa anterior ya se tiene claro que debe hacer el Sistema, ahora tenemos que determinar como va a hacerlo (cmo debe ser construido el Sistema?; aqu se definirn en detalle entidades y relaciones de las bases de datos, se pasar de casos de uso esenciales a su definicin como casos expandidos reales, se seleccionar el lenguaje ms adecuado, el Sistema Gestor de Bases de Datos a utilizar en su caso, libreras, configuraciones Hardware, redes, etc.). Observacin: Aunque todo debe ser tratado a su tiempo, y sera muy deseable que las decisiones correspondientes en esta etapa fueran tomadas precisamente en esta etapa, muchas veces nos vamos a encontrar con unas decisiones previamente impuestas sobre lenguaje, plataforma, etc. Unas veces se dirn justificadas en simple poltica de empresa y por mantener compatibilidad en lo que respecta a los dems proyectos de la propia empresa, y en otras ocasiones por rumores de que tal o cual herramienta mejorara la velocidad de desarrollo u otro aspecto de inters (en parte de los casos no sern rumores con fundamento o estudios previos realizados al efecto, sino ms bien debidos a la propia publicidad como consejera). Implementacin legado este punto se empieza a codificar algoritmos y estructuras de datos, definidos en las etapas anteriores, en el correspondiente lenguaje de programacin y/o para un determinado Sistema gestor de bases de datos. Observacin: Lamentablemente en la actualidad, ao 2.000, quedan bastantes empresas en las que, tras una reunin comercial en que tan solo se ha conseguido recabar una breve lista de requerimientos, a pesar de tener que enfrentarse a proyectos grandes-medios, se pasa directamente a la etapa de implementacin; 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, anlisis y diseo con la consiguiente prdida de control sobre la gestin del proyecto. Pruebas El objetivo de estas pruebas es garantizar que el Sistema ha sido desarrollado correctamente, sin errores de diseo y/o programacin. Es conveniente que sean planteadas al menos tanto a nivel de cada
Elaborados por:
Pg. 24
INSTITUTO TECNOLGICO DE JIQUILPAN Apuntes de Fundamentos de Desarrollo de Sistemas Ingeniera en Sistemas Computacionales Plan 2004
mdulo (aislado del resto), como de integracin del Sistema (segn sea la naturaleza del proyecto en cuestin se podrn tener en cuenta pruebas adicionales, p.ej. de rendimiento). Validacin Esta etapa tiene como objetivo la verificacin 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 tambin es interesante contar con los use cases, generados a travs de las correspondientes fases previas, que servirn de gua para la verificacin de que el Sistema cumple con lo descrito por estos). Mantenimiento y evolucin Finalmente la aplicacin resultante se encuentra ya en fase de produccin (en funcionamiento para el cliente, cumpliendo ya los objetivos para los que ha sido creada). A partir de este momento se entra en la etapa de mantenimiento, que supondr ya pequeas operaciones tanto de correccin como de mejora de la aplicacin (p.ej. mejora del rendimiento), as como otras de mayor importancia, fruto de la propia evolucin (p.ej. nuevas opciones para el usuario debidas a nuevas operaciones contempladas para el producto). La mayora de las veces en que se desarrolla una nueva aplicacin, se piensa solamente en un ciclo de vida para su creacin, olvidando la posibilidad de que esta deba sufrir modificaciones futuras (que tendrn que producirse con casi completa seguridad para la mayor parte de los casos). ELEMENTOS DEL CICLO DE VIDA Un ciclo de vida para un proyecto se compone de fases sucesivas compuestas por tareas planificables. Segn el modelo de ciclo de vida, la sucesin de fases puede ampliarse con bucles de realimentacin, de manera que lo que conceptualmente se considera una misma fase se pueda ejecutar ms de una vez a lo largo de un proyecto, recibiendo en cada pasada de ejecucin aportaciones de los resultados intermedios que se van produciendo (realimentacin). OBJETIVOS DE CADA FASE Dentro de cada fase general de un modelo de ciclo de vida, se pueden establecer una serie de objetivos y tareas que lo caracterizan. Fase de definicin (qu hacer?) Estudio de viabilidad. Conocer los requisitos que debe satisfacer el Sistema (funciones y limitaciones de contexto). Asegurar que los requisitos son alcanzables. Formalizar el acuerdo con los usuarios. Realizar una planificacin detallada. Fase de diseo (cmo hacerlo? Soluciones en coste, tiempo y calidad) Identificar soluciones tecnolgicas para cada una de las funciones del Sistema. Asignar recursos materiales para cada una de las funciones. Proponer (identificar y seleccionar) subcontratas. Establecer mtodos de validacin del diseo. Ajustar las especificaciones del producto. Fase de construccin Generar el producto o servicio pretendido con el proyecto.
Elaborados por: Lic. Martin Valencia Pg. 25
INSTITUTO TECNOLGICO DE JIQUILPAN Apuntes de Fundamentos de Desarrollo de Sistemas Ingeniera en Sistemas Computacionales Plan 2004
Integrar los elementos subcontratados o adquiridos externamente. Validar que el producto obtenido satisface los requisitos de diseo previamente definidos y realizar, si es necesario, los ajustes necesarios en dicho diseo para corregir posibles lagunas, errores o inconsistencias.
Fase de mantenimiento y operacin Operacin: asegurar que el uso del proyecto es el pretendido. Mantenimiento (nos referimos a un mantenimiento no habitual, es decir, aquel que no se limita a reparar averas o desgastes habituales -este es el caso del mantenimiento en producto.
La gestin de proyectos es la disciplina de Planificar, organizar y administrar recursos de manera tal que se pueda culminar todo el trabajo requerido en el proyecto dentro del alcance, el tiempo, y coste definidos. Un proyecto es un esfuerzo temporal, nico y progresivo, emprendido para crear un producto o un servicio tambin nico. Las caractersticas o atributos comunes a la mayora de los proyectos: Objetivo (poner los pies en la tierra; la naturaleza del proyecto debe ser real, sustentable y medible). Calendario de Actividades (debe tener un programa de actividades o plan de trabajo). Complejo (no es nada sencillo y est compuesto por mltiples elementos) Demanda recursos (Requiere habilidades, conocimientos, capital y esfuerzo humano de diversas reas de una organizacin o comunidad). Estructura organizacional (tiene roles y responsabilidades, ej. gerente de proyecto, lder de proyecto, sponsor, clientes, etc). Sistema de Control e Informacin (por lo menos un Sistema manual o automatizado de registrar la documentacin e informacin relacionada al proyecto).
Aspectos del seguimiento en la gestin de los proyectos El seguimiento es parte fundamental de la Gestin de Proyectos se basa en proveer una adecuada visibilidad a la administracin sobre la situacin del proyecto, para identificar oportunamente cualquier desviacin sobre lo planificado con el objetivo de tomar decisiones oportunas para corregirlas. VISIBILIDAD: Hace referencia a la actitud del lder, de cara a estar siempre enterado de cmo va el proyecto y su posible desviacin de los parmetros establecidos. DESVIACIONES: Si hay desviaciones, se deben cuantificar, en funcin del tiempo, dinero y recursos, adems se debe cuantificar el grado de desviacin, para conocer si es posible volver al camino correcto y cunto costara.
Lic. Martin Valencia Pg. 26
Elaborados por:
INSTITUTO TECNOLGICO DE JIQUILPAN Apuntes de Fundamentos de Desarrollo de Sistemas Ingeniera en Sistemas Computacionales Plan 2004
FRECUENCIA: Cuanto ms rpido se identifique una deficiencia en el proyecto ms fcil ser enmendarlo por eso se recomiendan anlisis y revisiones semanales, para conocer el estado del proyecto. TOMA DE DECISIONES: Despus de ver en que se falla hay que tomar decisiones, para solventar el problema, se debe tener cuidado en la identificacin de los causantes del retraso, pues a veces se esconden detrs de otros. TECNICAS DE SEGUIMIENTO: Las herramientas ms usadas, en la Gestin de Proyectos son reuniones, revisiones, reportes, y Software administrativo. Conviene que todo el equipo enve reportes del grado de avance de sus tareas y actividades, de la manera ms sencilla y eficaz de entender. Los reportes deben dar fe de: Progreso, Alcance, Tiempos, Costes, Rentabilidad, Riesgos, Problemas, Calidad, Recursos Humanos y Recursos Materiales entre otros.
1.2.2 Determinacin de Requerimientos. Conjunto de actividades encaminadas a obtener las caractersticas necesarias que deber poseer el nuevo Sistema, es el estudio de un Sistema, actividad o proceso, para comprender cmo trabaja y dnde es necesario efectuar mejoras o cambios considerables. Los analistas estructuran su investigacin al buscar respuestas a las siguientes cuatro importantes preguntas: Cul es el proceso bsico de la empresa? Qu datos utiliza o produce esta empresa? Cules son los lmites impuestos por el tiempo y la carga de trabajo? Qu controles de desempeo utiliza? Existen tres tipos de requerimientos. Un requerimiento funcional puede ser una descripcin de lo que un Sistema debe hacer. Este tipo de requerimiento especfica algo que el Sistema entregado debe ser capaz de realizar. Un requerimiento no funcional: de rendimiento, de calidad, etc.; especifica algo sobre el propio Sistema, y cmo debe realizar sus funciones. Algunos ejemplos de aspectos solicitables son la disponibilidad, el testeo, el mantenimiento, la facilidad de uso, etc. Otros tipos de limitaciones externas, que afectan en una forma indirecta al producto. Estas pueden ir desde la compatibilidad con cierto Sistema operativo hasta la adecuacin a leyes o regulaciones aplicables al producto Una coleccin de requerimientos describe las caractersticas o atributos del Sistema deseado. Se omite el cmo debe lograrse su implementacin, ya que esto debe ser decidido en la etapa de diseo por los diseadores.
Lic. Martin Valencia Pg. 27
Elaborados por:
INSTITUTO TECNOLGICO DE JIQUILPAN Apuntes de Fundamentos de Desarrollo de Sistemas Ingeniera en Sistemas Computacionales Plan 2004
En la ingeniera de Software se aplica el mismo significado, slo que el nfasis est puesto en el propio Software.
Los requerimientos bien formulados deben satisfacer varias caractersticas. Si no lo hacen, deben ser reformulados hasta hacerlo. Necesario: Lo que pida un requerimiento debe ser necesario para el producto. No ambiguo: El texto debe ser claro, preciso y tener una nica interpretacin posible. Conciso: Debe redactarse en un lenguaje comprensible por los inversores en lugar de uno de tipo tcnico y especializado, aunque aun as debe referenciar los aspectos importantes Consistente: Ningn requerimiento debe entrar en conflicto con otro requerimiento diferente, ni con parte de otro. Asimismo, el lenguaje empleado entre los distintos requerimientos debe ser consistente tambin. Completo: Los requerimientos deben contener en s mismos toda la informacin necesaria, y no remitir a otras fuentes externas que los expliquen con ms detalle. Alcanzable: Un requerimiento debe ser un objetivo realista, posible de ser alcanzado con el dinero, el tiempo y los recursos disponibles. Verificable: Se debe poder verificar con absoluta certeza, si el requerimiento fue satisfecho o no. Esta verificacin puede lograrse mediante inspeccin, anlisis, demostracin o testeo.
Estas caractersticas suelen ser subjetivas, es decir, no pueden ser calculadas de forma automtica por ningn Sistema. Por ello, se tiende a medir otras mtricas o indicadores que s pueden ser calculados de forma automtica y que, de algn modo, pueden sustituir o mapear con esta lista de caractersticas. Los Sistemas a nivel de transacciones, capturan, procesan datos por alguna razn por ejemplo: en un Sistema de pedidos los clientes son procesados de forma tal que sean artculos indicados. Los analistas seleccionados para trabajar en un Sistema de pedidos deben conocer todo lo relacionado cundo procesan estas transacciones. Requerimiento de decisin de los usuarios: A diferencia de las actividades de transaccin las relacionadas con decisiones no siguen un procedimiento especifico las rutinas son muy claras y es posible que los controles vagos. Es probable que los Sistemas de decisin tengan que ver con el pasado, presente o el futuro. Algunos brindan su porte para decisiones recurrentes mientras que otros son nicos y no recurrentes, estos Sistemas pueden utilizar datos que se originan dentro de empresas como los generados por el procesamiento de transacciones fuera de ella, por ejemplo asociaciones o fuentes comerciales en algunos casos se procesan los datos de transaccin para generar
Elaborados por:
Pg. 28
INSTITUTO TECNOLGICO DE JIQUILPAN Apuntes de Fundamentos de Desarrollo de Sistemas Ingeniera en Sistemas Computacionales Plan 2004
nueva informacin para la toma de decisiones. Requerimiento de toda la organizacin: En las empresas los departamentos dependen de uno de otro para brindar servicios para fabricar productos y satisfacer a los clientes. Por consiguiente el trabajo hecho en un depto. Afecta al de los otros. Cuando los analistas estudian Sistemas para un departamento tambin deben evaluar las implicaciones. Algunas veces los Sistemas abarcan los trabajos de varios deptos. La recepcin 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 accin da origen a una serie de actividades que afectan a las dems reas. Es probable que los analistas que tiene inters en el proceso de recepcin de pedidos no trabaje al mismo tiempo sobre el Sistema de facturacin, sin embargo deben tener conocimientos de cualquier requerimiento en cualquier otra parte de la organizacin, si el proceso de recepcin de pedidos no captura la direccin de los clientes para el cobro o el lugar donde deben enviar los productos entonces cmo enviar los artculos o las facturas por correo a su lugar de destino? Entonces es importante estar al tanto de otros requerimientos de la organizacin.
1.2.3 Anlisis y Diseo. QU ES EL ANLISIS DE SISTEMAS? Ciencia encargada del anlisis de Sistemas grandes y complejos y la interaccin entre esos Sistemas. Esta rea se encuentra muy relacionada con la Investigacin de operaciones. Tambin se denomina anlisis de Sistemas a una de las etapas de construccin de un Sistema informtico, que consiste en relevar la informacin actual y proponer los rasgos generales de la solucin futura. LO QUE NO ES EL ANLISIS DE SISTEMAS No es profesional en mantenimiento de computadores. No es desarrollador de Hardware. No es especialista en redes. No es un ensamblador de computadores.
Elaborados por:
Pg. 29
INSTITUTO TECNOLGICO DE JIQUILPAN Apuntes de Fundamentos de Desarrollo de Sistemas Ingeniera en Sistemas Computacionales Plan 2004
No es especialista en electrnica. EL TRABAJO DEL ANALISTA DE SISTEMAS El analista de Sistemas evala de manera sistemtica el funcionamiento de un negocio mediante el examen de la entrada y el procesamiento de datos y su consiguiente produccin de informacin, con el propsito de mejorar los procesos de una organizacin. Muchas mejoras incluyen un mayor apoyo a las funciones de negocios a travs del uso de Sistemas de informacin computarizados. El analista debe tener la capacidad de trabajar con todo tipo de gente y contar con suficiente experiencia en computadoras. El analista desempea diversos roles, en ocasiones varios de ellos al mismo tiempo. Los tres roles principales del analista de Sistemas son el de consultor, experto en soporte tcnico y agente de cambio. Diseo Conceptual El diseo conceptual se considera como un anlisis de actividades y consiste en la solucin de negocios para el usuario y se expresa con los casos de uso. El diseo lgico es la solucin 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 informacin 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, encuestas y/o visitas a los usuarios, de tal manera que se obtenga quin, qu, cundo, dnde y por qu de la solucin.
Diseo Lgico El diseo lgico traduce los escenarios de uso creados en el diseo conceptual en un conjunto de objetos de negocio y sus servicios. El diseo lgico se convierte en parte en la especificacin funcional que se usa en el diseo fsico. El diseo lgico es independiente de la tecnologa. El diseo lgico refina, organiza y detalla la solucin de negocios y define formalmente las reglas y polticas especficas de negocios. Un objeto de negocios es la encapsulacin de un servicio que abstrae las cualidades esenciales de algo de inters. Un servicio es una unidad con capacidad de cmputo. Un servicio debe satisfacer lo siguiente:
Ser seguro, lo que equivale a un uso correcto y con autorizacin Ser vlido, qu tareas o reglas se pueden aplicar Manejar excepciones, informando al cliente
Lic. Martin Valencia Pg. 30
Elaborados por:
INSTITUTO TECNOLGICO DE JIQUILPAN Apuntes de Fundamentos de Desarrollo de Sistemas Ingeniera en Sistemas Computacionales Plan 2004
Los objetos de negocio deben verificarse y probarse de tal manera que asegure que los mdulos operen como unidades completas de trabajo. Las tareas de verificacin incluyen:
Una verificacin independiente: o Pre y post condiciones o Lgica y funcionalidad individual Una verificacin dependiente: o Verificacin de dependencias o Que operan como una unidad especfica de trabajo
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 tcnica de anlisis nombre-verbo de los escenarios de uso. Tambin se puede emplear la tcnica sujeto-verbo-objeto directo. En estas tcnicas los sujetos y el objeto directo son los candidatos a objetos de negocio y los verbos activos son los candidatos a servicios. Una interface tiene las siguientes partes:
Nombre Precondiciones, lo que debe estar presente antes de ejecutarse Postcondiciones, estado final Capacidad o funcionalidad (SQL, pseudocdigo, funcin matemtica) Dependencias
La tarea de identificar las dependencias entre objetos permite identificar eventos, sucesos o condiciones que permitan la realizacin de tareas de negocios coordinadamente o transaccionalmente. 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 regulacin de tiempo crtica Considerar algn problema organizacional (transacciones) Identificar y auditar los requerimientos de control Determinar lugares y dependencias a travs de la ubicacin Determinar cuando el servicio que controla la transaccin es dependiente de los servicios contenidos en otros objetos de negocio
La validacin del modelo lgico debe ser tal que ste sea:
Elaborados por: Lic. Martin Valencia Pg. 31
INSTITUTO TECNOLGICO DE JIQUILPAN Apuntes de Fundamentos de Desarrollo de Sistemas Ingeniera en Sistemas Computacionales Plan 2004
Completo debe representar todos los escenarios de uso, Correcto el comportamiento lgico debe corresponder con el comportamiento conceptual, y Claro los objetos de negocio y servicios no deben ser ambiguos
En el diseo lgico conceptualmente se divide en tres niveles de servicios con el fin de que la aplicacin resulte flexible ante los cambios de requerimientos y/o de tecnologa cambiando nicamente la capa o capas necesarias. Los tres niveles son: servicios de usuario, servicios de negocio y servicios de datos. Los servicios de usuario (user services) controlan la interaccin. Un servicio de usuario son personas, aplicaciones, otros servicios o la combinacin de stos. Generalmente involucra una interfase grfica de usuario (GUI) o pude ser no visual (mensajes o funciones), maneja todos los aspectos de la interaccin con la aplicacin. El objetivo central es minimizar el esfuerzo de conocimiento requerido para interpretar la informacin. Un servicio de usuario incluye un contenido (qu se necesita comunicar al usuario) y una forma (cmo se comunica el contenido) cuando es necesaria la comunicacin. Los servicios de negocio (bussines services) convierten datos recibidos de los servicios de datos y de usuario en informacin (datos + regla de negocio) y pueden usar otros servicios de negocio para completar su tarea. 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 informacin Validar los datos inmediatamente en el contexto o en forma diferida una vez terminada la transaccin.
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 categoras como las siguientes:
Declaracin del esquema y su evolucin (estructuras de datos, tipos, acceso indexado, SQL, APIs) Respaldo y recuperacin (recuperacin de datos si un evento falla) Bsqueda y Lectura (bsquedas, compilacin, optimizacin y ejecucin de solicitudes, formacin de un conjunto de resultados) Insercin, actualizacin y borrado (procesar modificaciones consistentemente transaccional). Una transaccin es atmica (ocurre o no), consistente (preserva integridad), aislada (otras transacciones ocurren antes o despus) y durable (una vez completada, sta sobrevive). Bloqueo (permite al acceso concurrente a los datos) Validacin de datos (verifica la integridad del dominio, triggers y gateways para verificar el estado de los datos antes de aceptarlos, manejo de errores) Seguridad (acceso seguro a los objetos, operaciones, permisos a usuario y grupos y servicios) Administracin de la conexin (mecanismos bsicos para establecer una sesin de los servicios de datos). Establecer una conexin involucra: una identificacin, la colocacin y provisin de datos, tiempo de sesin, el tipo de interaccin (conversacional, transaccional, multiusuario, monousuario). Distribucin de datos (Distribuye informacin, a mltiples unidades de recuperacin, bases de datos heterogneas, segn la topologas de la red).
Elaborados por:
Pg. 32
INSTITUTO TECNOLGICO DE JIQUILPAN Apuntes de Fundamentos de Desarrollo de Sistemas Ingeniera en Sistemas Computacionales Plan 2004
Diseo fsico El diseo fsico traduce el diseo lgico en una solucin implementable y costo-efectiva o econmica. El componente es la unidad de construccin elemental del diseo fsico. Las caractersticas de un componente son:
Se define segn cmo interacta con otros Encapsula sus funciones y sus datos Es reusable a travs de las aplicaciones Puede verse como una caja negra Puede contener otros componentes
En el diseo fsico se debe cuidar el nivel de granularidad (un componente puede ser tan grande o tan pequeo segn su funcionalidad, es decir, del tamao tal que pueda proveer de una funcionalidad compleja pero de control genrico) y la agregacin y contencin (un componente puede reusar utilizando tcnicas de agregacin y contencin, sin duplicar cdigo). El diseo fsico debe involucrar:
El diseo para distribucin debe minimizarse la cantidad de datos que pasan como parmetros entre los componentes y stos deben enviarse de manera segura por la red. El diseo para multitarea debe disearse en trminos de la administracin concurrente de dos o ms tareas distintas por una computadora y el multithreading o mltiples hilos de un mismo proceso) El diseo para uso concurrente el desempeo de un componente remoto depende de si est corriendo mientras recibe una solicitud. El diseo con el manejo de errores y prueba de eventos: o Validando los parmetros- a la entrada antes de continuar con cualquier proceso. o Protegiendo recursos crticos manejar excepciones para evitar la falla o terminacin sin cerrar archivos, liberar objetos sincronizados o memoria. o Protegiendo datos importantes contar con una excepcin a la mitad de la actuacin en las bases de datos. o Debugging crear una versin para limpiar errores. o Proteccin integral de transacciones de negocios los errores deben regresarse al componente que llama.
Elaborados por:
Pg. 33
INSTITUTO TECNOLGICO DE JIQUILPAN Apuntes de Fundamentos de Desarrollo de Sistemas Ingeniera en Sistemas Computacionales Plan 2004
Definir los componentes Refinar el empaquetamiento y distribucin de componentes Especificar las interfaces de los componentes Distribuir los componentes en la red Distribuir los repositorios fsicos de datos Examinar la tolerancia a fallas y la recuperacin de errores Validar el diseo fsico
De las tareas anteriores la ms importante es la distribucin de los datos que pueden ser centralizados, una particin, un extracto o una rplica. Los datos centralizados equivalen a una base de datos maestra ubicada en un lugar central. No hay copias de los datos. Una particin de datos es una segmentacin de la base de datos maestra. Es til cuando los datos se pueden fragmentar fcilmente y actualizarse en un sitio local con cambios frecuentes. No hay sobreposicin entre particiones. En una particin horizontal cada hilera existe en una sola base de datos. En una particin vertical cada columna es contenida en una y solo una base de datos. Un extracto de datos es una copia de toda o una porcin de la base de datos maestra. No se permite la actualizacin. Se usa un timestamp o etiqueta de tiempo para indicar qu tan viejos son los datos. Una rplica de datos es un fragmento de la bases de datos maestra que se puede actualizar. Una rplica de datos es cuando el sitio de actualizacin cambia a un sitio local. No se permiten actualizaciones en la base
Elaborados por: Lic. Martin Valencia Pg. 34
INSTITUTO TECNOLGICO DE JIQUILPAN Apuntes de Fundamentos de Desarrollo de Sistemas Ingeniera en Sistemas Computacionales Plan 2004
de datos rplica y en la base de datos maestra a la vez, por lo que debe de haber sincronizacin entre ambas. El diseo fsico est ntimamente ligado a una alternativa tecnolgica. Ante la acelerada evolucin tecnolgica es importante considerar los estndares del momento y las tendencias ya que una mala decisin 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 comunicndose entre s en una plataforma internet con protocolos estndar en redes heterogneas. 1.2.4 Programacin. Desarrollo del Software: Los encargados de desarrollar Software pueden instalar Software comprobando a terceros o escribir programas diseados a la medida del solicitante. La eleccin depende del costo de cada alternativa, del tiempo disponible para escribir el Software y de la disponibilidad de los programadores. Por lo general, los programadores que trabajan en las grandes organizaciones pertenecen a un grupo permanente de profesionales. Los encargados de desarrollar Software pueden instalar Software comprobando a terceros o escribir programas diseados a la medida del solicitante. La eleccin depende del costo de cada alternativa, del tiempo disponible para escribir el Software y de la disponibilidad de los programadores. Por lo general, los programadores que trabajan en las grandes organizaciones pertenecen a un grupo permanente de profesionales. 1.2.5 Prueba e Implantacin Durante la prueba de Sistemas, el Sistema se emplea de manera experimental para asegurarse de que el Software no tenga fallas, es decir, que funciona de acuerdo con las especificaciones y en la forma en que los usuarios esperan que lo haga. Se alimentan como entradas conjunto de datos de prueba para su procesamiento y despus se examinan los resultados. Implantacin y evaluacin La implantacin es el proceso de verificar e instalar nuevo equipo, entrenar a los usuarios, instalar la aplicacin y construir todos los archivos de datos necesarios para utilizarla. Una vez instaladas, las aplicaciones se emplean durante muchos aos. Sin embargo, las organizaciones y los usuarios cambian con el paso del tiempo, incluso el ambiente es diferente con el paso de las semanas y los meses. Por consiguiente, es indudable que debe darse mantenimiento a las aplicaciones. La evaluacin de un Sistema se lleva a cabo para identificar puntos dbiles y fuertes. La evaluacin ocurre a lo largo de cualquiera de las siguientes dimensiones:
Evaluacin operacional: Valoracin de la forma en que funciona el Sistema, incluyendo su facilidad de uso, tiempo de respuesta, lo adecuado de los formatos de informacin, confiabilidad global y nivel de utilizacin.
Lic. Martin Valencia Pg. 35
Elaborados por:
INSTITUTO TECNOLGICO DE JIQUILPAN Apuntes de Fundamentos de Desarrollo de Sistemas Ingeniera en Sistemas Computacionales Plan 2004
Impacto organizacional: Identificacin y medicin de los beneficios para la organizacin en reas tales como finanzas, eficiencia operacional e impacto competitivo. Tambin se incluye el impacto sobre el flujo de informacin externo e interno. Opinin de loa administradores: evaluacin de las actividades de directivos y administradores dentro de la organizacin as como de los usuarios finales. Desempeo del desarrollo: La evaluacin de proceso de desarrollo de acuerdo con criterios tales como tiempo y esfuerzo de desarrollo, concuerdan con presupuestos y estndares, y otros criterios de administracin de proyectos. Tambin se incluye la valoracin de los mtodos y herramientas utilizados en el desarrollo.
UNIDAD II INTRODUCCION A LA INGENIERIA DEL SOFTWARE 2.1 Definicin de Ingeniera de Software Es una disciplina o rea de la informacin o ciencias de la computacin, que ofrece mtodos o tcnicas para desarrollar y mantener Software de calidad que resuelven problemas de todo tipo. Hoy da es cada vez ms frecuente la consideracin de la Ingeniera del Software como una nueva rea de la Ingeniera y el Ingeniero de Software comienza a ser una profesin implantada en el mundo natural, laboral, internacional con derechos. La Ingeniera del Software trata de reas muy diversas de la informtica y de las ciencias computacionales, tales como constantes de compiladores, Sistemas operativos o desarrollos de Internet.
Elaborados por: Lic. Martin Valencia Pg. 36
INSTITUTO TECNOLGICO DE JIQUILPAN Apuntes de Fundamentos de Desarrollo de Sistemas Ingeniera en Sistemas Computacionales Plan 2004
La ingeniera de Software es el establecimiento y uso de principios slidos de la ingeniera para obtener econmicamente un Software confiable y que funcione de modo eficiente en mquinas reales (Fritz Baver) La IEEE la define como la aplicacin de un enfoque sistemtico, disciplinado y cuantificable al desarrollo, operacin y mantenimiento de Software, es decir, la aplicacin de la ingeniera al Software. 2.2 Historia de la Ingeniera del Software La Ingeniera del Software, trmino utilizado por primera vez por Fritz Bauer en la primera conferencia sobre desarrollo de Software patrocinada por el Comit de Ciencia de la OTAN celebrada en Garmisch, Alemania, en octubre de 1968, puede definirse segn Alan Davis como la aplicacin inteligente de principios probados, tcnicas, lenguajes y herramientas para la creacin y mantenimiento, dentro de un coste razonable, de Software que satisfaga las necesidades de los usuarios Fuente Wikipedia.. El trmino ingeniera del Software empez a usarse a finales de la dcada de los sesenta, para expresar el rea de conocimiento que se estaba desarrollando en torno a las problemticas que ofreca el Software en ese momento. En esa poca, el crecimiento espectacular de la demanda de Sistemas de computacin cada vez ms y ms complejos, asociado a la inmadurez del propio sector informtico (totalmente ligado al electrnico) y a la falta de mtodos y recursos, provoc lo que se llam la crisis del Software (en palabras de Edsger Dijkstra) entre los aos 1965 y 1985. Durante esa poca muchos proyectos importantes superaban con creces los presupuestos y fechas estimados, algunos de ellos eran tan crticos (Sistemas de control de aeropuertos, equipos para medicina, entre otros) que sus implicaciones iban ms all de las prdidas millonarias que causaban. La crisis del Software pas, no tanto por la mejora en la gestin de los proyectos, sino en parte porque no es razonable estar en crisis ms de veinte aos, y en parte porque se estaban haciendo progresos en los procesos de diseo y metodologas. As pues, desde 1985 hasta el presente, han ido apareciendo herramientas, metodologas y tecnologas que se presentaban como la solucin definitiva al problema de la planificacin, previsin de costes y aseguramiento de la calidad en el desarrollo de Software. Entre las que se encuentran la programacin estructurada, la programacin orientada a objetos, a los aspectos, las herramientas CASE, el lenguaje de programacin ADA, la documentacin, los estndares, CORBA, los servicios web y el lenguaje UML (entre otros) fueron todos anunciados en su momento como la solucin a los problemas de la ingeniera del Software, la llamada bala de plata (por silver bullet). Y lo que es ms, cada ao surgen nuevas ideas e iniciativas encaminadas a ello. En combinacin con las herramientas, tambin se han hecho esfuerzos por incorporar los mtodos formales al desarrollo de Software, argumentando que si se probaba formalmente que los desarrollos hacan lo que se les requera, la industria del Software sera tan predecible como lo son otras ramas de la ingeniera. Evolucin del Software Primeros aos 50s a los 60s:
Elaborados por:
INSTITUTO TECNOLGICO DE JIQUILPAN Apuntes de Fundamentos de Desarrollo de Sistemas Ingeniera en Sistemas Computacionales Plan 2004
Distribucin limitada Software a medida Segunda era 70s: Multiusuario Tiempo real Bases de datos Software como producto Sistemas distribuidos Incorporacin de inteligencia Hardware bajo coste Impacto en el consumo Cuarta era 90s al 2000 Potentes Sistemas de sobremesa Tecnologas orientadas a objetos Sistemas expertos Redes neuronales Computacin paralela 2.3 Caractersticas del Software 1. El Software se desarrolla o construye; no se manufactura en el sentido clsico. A pesar de que existen similitudes entre el desarrollo del Software y la manufactura del Hardware, las dos actividades serian diferentes en lo fundamental. En ambas la alta calidad se alcanza por medio del buen diseo, la fase de manufactura del Hardware puede incluir problemas de calidad existentes en el Software. 2. El Software no se desgasta. El Software es inmune a los males ambientales que desgasten el Hardware. Por lo tanto la curva de tasas de fallas para el Software debera tener la forma de la curva idealizada. Los defectos sin descubrir causan tasas de fallas altas en las primeras etapas de vida de un programa. Sin embargo, los errores se corrigen y la curva se aplana: el Software no se desgasta, pero si se deteriora. 3. A pesar de que la industria tiene una tendencia hacia la construccin por componentes, la mayora del Software an se construye a la medida. Un componente de Software se debe disear e implementar de forma que puede utilizarse en muchos programas diferentes.
Elaborados por: Lic. Martin Valencia Pg. 38
INSTITUTO TECNOLGICO DE JIQUILPAN Apuntes de Fundamentos de Desarrollo de Sistemas Ingeniera en Sistemas Computacionales Plan 2004
Los componentes reutilizables modernos encapsulan tanto los datos como el proceso se aplican a estos, lo que permite al ingeniero de Software crear nuevas aplicaciones nuevas a partir de partes reutilizables y que cumplan con estos atributos. 1.- Funcionabilidad. 2.- Confiabilidad, Disponibilidad y Rendimiento. 3.- Seguridad. 4.- Usabilidad y Reusabilidad. 5.- Utilidad. 6.- Oportunidad e Innovacin.
Paradigma Los Sistemas informticos (Software) desde su concepcin hasta su desaparicin pasan por una serie de etapas o fases. Desde que surge la necesidad, pasando por su propia construccin, puesta en marcha y continas revisiones hasta su abandono, pasa por una serie de etapas que constituyen su ciclo de vida. Las actividades para la construccin de un Sistema se realizan de acuerdo a un mtodo. Una metodologa es una manera ordenada y sistemtica de proceder para obtener algn fin. Se llevara a cabo a travs de una serie de normas o reglas precisas, cuyo cumplimiento ser ms o menos estricto, constituyendo el cuerpo formal de la metodologa. El conjunto de normas incluye adems un Sistema de documentacin donde se ir reflejando el trabajo realizado, siendo el aspecto ms visible del mtodo.
Elaborados por: Lic. Martin Valencia Pg. 39
INSTITUTO TECNOLGICO DE JIQUILPAN Apuntes de Fundamentos de Desarrollo de Sistemas Ingeniera en Sistemas Computacionales Plan 2004
Una metodologa es un enfoque para organizar, dirigir y realizar las actividades del ciclo de vida de un Sistema de informacin. Existen varias metodologas: clsica, prototipos, oo, merisse, etc. Los Sistemas de informacin se desarrollan en una serie de pasos: esta secuencia se conoce como el ciclo de vida. Se utiliza por varias razones: A) Para organizar el gran nmero de actividades necesarias en la construccin de un Sistema y especificar la secuencia en que se deben tratar esas actividades para su desarrollo. B) El ciclo de vida ayuda a los analistas a resolver problemas que surjan durante el desarrollo del Sistema, marcando la direccin del proyecto y proporcionando una gua sobre lo que se debera obtener como resultado del mismo. C) El ciclo de vida ayuda tambin a producir informes del estado del proyecto, permitiendo un seguimiento de las necesidades de recursos. El ciclo de vida se define como una secuencia de fases. Cada fase se compone de actividades ms detalladas, cada una de las cuales tienen un objetivo especfico. Cada fase se revisa cuando se completa. Esta revisin produce un informe como resultado y define el objetivo y un plan detallado para la siguiente fase. Metodologa Estructurada Principales exponentes: De Marco, Yourdon, Gane & Sarson. En el CDV clsico era muy importante partir de unos requerimientos claros, completos y bien definidos, el analista estaba seguro de conocer perfectamente lo que el usuario quera que haga el Sistema. Cuando las necesidades del usuario simples, determinar y definir requerimientos puede ser relativamente fcil, pero cuando las necesidades del usuario crecen, o son complejas, o difciles de definir, si adems la aplicacin debe servir a varios usuarios con necesidades e intereses diferentes y a veces opuestos, el anlisis de los requerimientos se complica y se convierte en el principal problema en el desarrollo de un Sistema de informacin. En los aos 70 esta situacin hizo que el ciclo de vida clsico entrara en crisis. El CDV estructurado surge as como una superacin del CDVC en entornos grandes y complejos. En la actualidad se conocen como anlisis estructurado, diseo estructurado y programacin estructurada, pero este mtodo es bastante ms que esto. El CDVE es un ciclo lineal o en cascada, que provee tcnicas y herramientas adecuadas para cada fase del proyecto. Es una metodologa que ofrece mayores puntos de control para el proyecto. Es ms flexible, lo que facilita el mantenimiento (modificacin y adaptacin del Sistema), entre otras ventajas. Junto con esta metodologa aparecen nuevos conceptos como la modularizacin y el diseo descendente.
2.4 Mitos del Software: Los mitos del Software-creencias acerca del Software y de los procesos empleados para construirlo- se pueden rastrear hasta los primeros das de la computacin. Los mitos tienen ciertos atributos que los convierten en insidiosos.
Elaborados por: Lic. Martin Valencia Pg. 40
INSTITUTO TECNOLGICO DE JIQUILPAN Apuntes de Fundamentos de Desarrollo de Sistemas Ingeniera en Sistemas Computacionales Plan 2004
Mitos de la administracin. Los gestores con responsabilidad sobre el Software, como los gestores en la mayora de las disciplinas, estn normalmente bajo la presin de cumplir las propuestas, hacer que no se retrase el proyecto y mejorar la calidad. Un gestor de Software se agarra frecuentemente a un mito del Software. Mito: Si se falla en la planificacin, se puede aadir ms programadores y adelantar el tiempo perdido.
Mitos del cliente. En muchos casos, el cliente cree en los mitos que existen sobre el Software, debido a que los gestores y desarrolladores de Software hacen muy poco para corregir la mala informacin. Los mitos conducen a que el cliente se cree una falsa expectativa y, finalmente, quede insatisfecho con el desarrollador del Software. Mito: Si los requisitos del proyecto cambian continuamente, los cambios pueden acomodarse fcilmente, ya que el Software es flexible. Mitos de los desarrolladores. Los mitos en los que an creen muchos desarrolladores se han ido fomentando durante 50 aos de cultura informtica. Durante los primeros das del desarrollo del Software, la programacin se vea como un arte. Las viejas formas y actitudes tardan en morir. Mito: Una vez que escribimos el programa y hacemos que funcione, nuestro trabajo ha terminado.
2.5 Capas de la Ingeniera del Software La ingeniera de Software es una tecnologa multicapa, cualquier enfoque de ingeniera debe apoyarse sobre un compromiso de organizacin de calidad. El fundamento de la ingeniera de Software es la capa del proceso. El proceso de la ingeniera de Software es la unin que mantiene juntas las capas de tecnologa y que permiten un desarrollo racional y oportuno de la ingeniera de Software. El proceso define un marco de trabajo para un conjunto de reas clave de proceso que se deben establecer para la entrega de la tecnologa de la ingeniera de Software. Los mtodos abarcan una gran gama de tareas que incluyen anlisis de requisitos, diseo, construccin de programas, pruebas y mantenimiento. Las herramientas de la ingeniera de Software proporcionan un enfoque automtico o semiautomtico para el proceso y para los mtodos.
Elaborados por: Lic. Martin Valencia Pg. 41
INSTITUTO TECNOLGICO DE JIQUILPAN Apuntes de Fundamentos de Desarrollo de Sistemas Ingeniera en Sistemas Computacionales Plan 2004
Enfoque en capas Herramientas.- proporcionan un soporte automtico o semi automtico a los procesos y a los mtodos. Mtodos.- indican cmo construir tcnicamente el Software Procesos.-son el fundamento de la ingeniera de Software. Un enfoque de Calidad.- son la base o cimientos de la ingeniera de Software.
Herramientas: Las herramientas de la ingeniera del Software proporcionan un soporte automtico o semi-automtico para el proceso y los mtodos, a estas herramientas se les llama herramientas CASE (Computer-Aided Software Engineering). Mtodos: Los mtodos de la ingeniera de Software indican cmo construir tcnicamente el Software. Los mtodos abarcan una gran gama de tareas que incluyen anlisis de requisitos, diseo, construccin de programas, pruebas y mantenimiento. Estos mtodos dependen de un conjunto de principios bsicos que gobiernan cada rea de la tecnologa e incluyen actividades de modelado y otras tcnicas descriptivas. Procesos: El fundamento de la ingeniera de Software es la capa proceso. El proceso define un marco de trabajo para un conjunto de reas clave, las cuales forman la base del control de gestin de proyectos de Software y establecen el contexto en el cual: se aplican los mtodos tcnicos, se producen resultados de trabajo, se establecen hitos, se asegura la calidad y el cambio se gestiona adecuadamente.
Elaborados por: Lic. Martin Valencia Pg. 42
INSTITUTO TECNOLGICO DE JIQUILPAN Apuntes de Fundamentos de Desarrollo de Sistemas Ingeniera en Sistemas Computacionales Plan 2004
Un enfoque de calidad: Son la base o cimientos de la ingeniera de Software. Cualquier disciplina de ingeniera (incluida la ingeniera del Software) debe descansar sobre un esfuerzo de organizacin de calidad. La gestin total de la calidad y las filosofas similares fomentan una cultura continua de mejoras de procesos que conduce al desarrollo de enfoques cada vez ms robustos para la ingeniera 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.
Qu es el Software? Es un conjunto de elementos u objetos Que conforman una configuracin e Incluye: Programas Documentos Datos
Se puede decir que hoy en da se encuentra en casi todas las diferentes reas de trabajo y ocio como son la Ingeniera, Educacin, salud, Juegos, Vida Social, Telecomunicaciones, Etc., y se encuentra dividida en las siguientes aplicaciones; Software de Sistema. Software de Tiempo Real. Software de Negocios. Software de Ingeniera/Cientfico. Software Incrustrado. Software de PC. Software de IA. Aplicaciones Web.
Un proceso de desarrollo de Software tiene como propsito la produccin eficaz y eficiente de un producto Software que rena los requisitos del cliente. Dicho proceso, Este proceso es intensamente intelectual, afectado por la creatividad y juicio de las personas involucradas .Aunque un proyecto de desarrollo de Software es equiparable en muchos aspectos a cualquier otro proyecto de ingeniera, en el desarrollo de Software hay una serie de desafos adicionales, relativos esencialmente a la naturaleza del producto obtenido. A continuacin se explican algunas particularidades asociadas al desarrollo de Software y que influyen en su proceso de construccin. Perspectiva histrica del desarrollo de Software Dcada 50-60:
Elaborados por: Lic. Martin Valencia Pg. 43
INSTITUTO TECNOLGICO DE JIQUILPAN Apuntes de Fundamentos de Desarrollo de Sistemas Ingeniera en Sistemas Computacionales Plan 2004
Software como un aadido. Desarrollo artesanal, a medida. Lenguajes de bajo nivel. Dcada 60-70: Software como producto. Dcada lenguajes y compilacin. Crisis del Software. Dcada 70-80: Programacin estructurada. Ingeniera del Software. Primeros mtodos estructurados. Dcada 80-90: Nuevos paradigmas de programacin y de produccin de programas: OO C/S 90s en la actualidad: Anlisis/Diseo OO. Tecnologa CASE Componentes y reutilizacin Interoperabilidad (CORBA, .NET...) Internet - ISW. Distribuida - Repositorios de componentes reutilizables - e-business; e-commerce Estas son algunas consideraciones que se deben tener en cuenta al momento de elegir o disear algn Software. El Software es un elemento del Sistema que es lgico, en lugar de fsico. El Software se desarrolla no se fbrica en un sentido clsico. El Software no se estropea. Pero se deteriora!. La mayora del Software se construye a medida. usar todo o nada (poco ensamblaje de componentes: reutilizacin).
2.7 Software de Alta Calidad Las inspecciones de Software surgen a partir de la necesidad de producir Software de alta calidad. Algunos grupos de desarrollo creen que la calidad del Software es algo en lo que deben preocuparse una vez que se ha generado el cdigo. Error La garanta de la calidad del Software es una actividad de proteccin que se aplica a lo largo de todo el proceso de ingeniera de Software. La SQA (Software Quality Assurance) engloba: Un enfoque de gestin de calidad Tecnologa de Ingeniera de Software efectiva (mtodos y herramientas)
Lic. Martin Valencia Pg. 44
Elaborados por:
INSTITUTO TECNOLGICO DE JIQUILPAN Apuntes de Fundamentos de Desarrollo de Sistemas Ingeniera en Sistemas Computacionales Plan 2004
Revisiones tcnicas formales que se aplican durante el proceso del Software Una estrategia de prueba multiescalada Un control de la documentacin del Software y de los cambios realizados Un procedimiento que asegure un ajuste a los estndares de desarrollo de Software Mecanismos de medicin y de generacin de informes.
El control de la calidad es una serie de revisiones, y pruebas utilizados a los largo del ciclo de desarrollo para asegurar que cada producto cumple con los requisitos que le han sido asignados. La principal meta de un equipo desarrollador de Software debera ser siempre producir Software catalogado como de alta calidad. Pero para ello se deben tener en cuenta algunas ideas previas: - Productos Software son realizados por personas para personas. As, las personas desarrolladoras deben tener en cuenta claramente que son otras personas las que utilizarn sus productos, los que pueden estar sujetos a fallos constantes. An a pesar de los avances actuales en Inteligencia Artificial, los asistentes Software para el desarrollo de Software no son demasiado confiables como para que la mano humana no intervenga en este proceso. El desarrollo de productos Software es una actividad sujeta a muchos factores que la pueden hacer poco confiable. Todas las metodologas y herramientas tienen un nico fin producir Software de gran calidad Definiciones de calidad del Software. Concordancia con los requisitos funcionales y de rendimiento explcitamente establecidos con los estndares de desarrollo explcitamente documentados y con las caractersticas implcitas que se espera de todo Software desarrollado profesionalmente R. S. Pressman (1992). El conjunto de caractersticas de una entidad que le confieren su aptitud para satisfacer las necesidades expresadas y las implcitas ISO 8402 (UNE 66-001-92). Los requisitos del Software son la base de las medidas de calidad. La falta de concordancia con los requisitos es una falta de calidad. Los estndares o metodologas definen un conjunto de criterios de desarrollo que guan la forma en que se aplica la ingeniera del Software. Si no se sigue ninguna metodologa siempre habr falta de calidad. Existen algunos requisitos implcitos o expectativas que a menudo no se mencionan, o se mencionan de forma incompleta (por ejemplo el deseo de un buen mantenimiento) que tambin pueden implicar una falta de calidad. El aseguramiento de calidad del Software es el conjunto de actividades planificadas y sistemticas necesarias para aportar la confianza en que el producto (Software) satisfar los requisitos dados de calidad. El aseguramiento de calidad del Software se disea para cada aplicacin antes de comenzar a desarrollarla y no despus.
Elaborados por: Lic. Martin Valencia Pg. 45
INSTITUTO TECNOLGICO DE JIQUILPAN Apuntes de Fundamentos de Desarrollo de Sistemas Ingeniera en Sistemas Computacionales Plan 2004
Algunos autores prefieren decir garanta de calidad en vez de aseguramiento. Garanta, puede confundir con garanta de productos. Aseguramiento pretende dar confianza en que el producto tiene calidad. El aseguramiento de calidad del Software est presente en: Mtodos y herramientas de anlisis, diseo, programacin y prueba. Inspecciones tcnicas formales en todos los pasos del proceso de desarrollo del Software. Estrategias de prueba multiescala. Control de la documentacin del Software y de los cambios realizados Procedimientos para ajustarse a los estndares (y dejar claro cuando se est fuera de ellos) Mecanismos de medida (mtricas) Registro de auditoras y realizacin de informes. Actividades para el aseguramiento- de calidad del Software Mtricas de Software para el control del proyecto Verificacin y validacin del Software a lo largo del ciclo de vida Incluye las pruebas y los procesos de revisin e inspeccin La gestin de la configuracin del Software El instituto de la ingeniera 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, con el fin de alcanzar la calidaden el desarrollo de cualquier proyecto de Software. Modelo de Capacidad de Madurez (IMCM). Nivel 0: Incompleto. El rea del proceso (por ejemplo, la gestin de requisitos) an no se realiza o todava no alcanza todas las metas y objetivos definidos para el nivel 1 de capacidad. Nivel 1: Realizado. Todas las metas especficas de rea del proceso (como las defini la IMCM) han sido satisfechas. Las tareas de trabajo requeridas para producir el producto especfico han sido realizadas. Nivel 2: Administrado. Todos los criterios del nivel 1 han sido satisfechos. Adems, todo el trabajo asociado con el rea de proceso se ajusta a una poltica organizacional definida; toda la gente que ejecuta el trabajo tiene acceso a recurso adecuados para realizar su labor; los clientes estn implicados de manera
Elaborados por: Lic. Martin Valencia Pg. 46
INSTITUTO TECNOLGICO DE JIQUILPAN Apuntes de Fundamentos de Desarrollo de Sistemas Ingeniera en Sistemas Computacionales Plan 2004
activa en el rea de proceso, cuando esto se requiere; todas las tareas de trabajo y productos estn monitoreadas, controlados y revisados; y son evaluados en apego a la descripcin del proceso Nivel 3: Definido. Todos los criterios del nivel 2 se han cumplido. Adems, el proceso est adaptado al conjunto de procesos de estndar de la organizacin, de acuerdo con las polticas de adaptacin de esta misma, y contribuye a la informacin de los productos del trabajo, mediciones y otras mejoras del proceso para los activos del proceso organizacional. Nivel 4: Administrativo en forma cuantitativa. Todos los criterios del nivel 3 han sido cumplidos. Adems, el rea del proceso se controla y mejora mediante mediciones y evaluacin cuantitativa. Los objetivos cuantitativos para la calidad y el desempeo del proceso estn establecidos y se utilizan como un criterio para administrar el proceso. Nivel 5: Mejorado. Todos los criterios del nivel 4 han sido satisfechos. Adems, el rea del proceso se adapta y mejora mediante el uso de medios cuantitativos (estadsticos) para conocer las necesidades cambiantes del cliente y mejorar de manera continua la eficacia del rea del proceso que se est considerando.
2.8 Factores de Calidad y productividad Como bien sabrn ustedes, actualmente estudiar cualquier Ingeniera basada en los Sistemas Informticos, o como tal, es decir, como Ingeniero, siempre es preocupante el incrementar la calidad del Software, buscando la calidad; la ingeniera del Software es la produccin de Software de calidad. Todos deseamos que nuestros Sistemas de Software sean rpidos, fiables, fciles de usar, legibles, modulares, estructurados y as sucesivamente. Pero estos adjetivos describen dos tipos de cualidades diferentes. Por una parte, se consideran cualidades tales como la velocidad o la facilidad de uso, cuya presencia o ausencia en un producto de Software puede ser detectada por sus usuarios. Estas propiedades pueden ser denominadas factores de calidad externos. Otras cualidades aplicables a un producto de Software, como la Modularidad o legibilidad son factores internos, perceptibles slo por profesionales de la informtica que tienen acceso al cdigo fuente. En ltima instancia, slo importan los factores externos. Si se una un navegador Web o se vive cerca de una planta nuclear controlada por computadora, importa poco que el Software sea legible o modular si los grficos tardan aos en cargarse o si la introduccin de datos errneos hace explotar la planta. La clave para obtener los factores externos radica en los internos: para que los usuarios disfruten de las cualidades visibles, los diseadores y los implementadores deben aplicar tcnicas internas que aseguren las cualidades ocultas como se sugieren a continuacin: Correccin. La correccin es la cualidad principal. Si un Sistema no hace lo que se supone que debe hacer, poco importan el resto de consideraciones que hagamos sobre l, si es rpido, si tiene una bonita interfaz de usuario, etc. Pero esto es ms fcil de decir que de lograr. Incluso el primer paso hacia la correccin es ya difcil: debemos ser capaces de especificar los requisitos del Sistema de una forma precisa, lo que es en s una ardua tarea.
Elaborados por: Lic. Martin Valencia Pg. 47
INSTITUTO TECNOLGICO DE JIQUILPAN Apuntes de Fundamentos de Desarrollo de Sistemas Ingeniera en Sistemas Computacionales Plan 2004
Los mtodos que aseguran la correccin son usualmente condicionales. Un Sistema de Software importante, incluso uno pequeo segn los estndares de hoy, implica a tantas reas que sera imposible garantizar su correccin manejando todas las componentes y propiedades en un solo nivel. En cambio, es necesaria una solucin multinivel, en la que cada nivel confa en la correccin de los inferiores: Hardware ----> Sistema Operativo----> Compilador ----> Sistema de Aplicacin En la solucin condicional de la correccin, slo hay que preocuparse en garantizar que cada nivel sea correcto bajo el supuesto de que los niveles inferiores son correctos. Robustez La robustez complementa la correccin. La correccin tiene que ver con el comportamiento de un Sistema en los casos previstos por su especificacin; la robustez caracteriza lo que sucede fuera de tal especificacin. La robustez es por naturaleza una nocin ms difusa que la correccin. Puesto que tiene que ver aqu con casos no previstos por la especificacin, no es posible decir, como con la correccin, que el Sistema debera realizar sus tareas en tal caso; donde las tareas son conocidas, el caso excepcional formara parte de la especificacin y regresaramos al terreno de la correccin. Siempre habr casos que la especificacin no contemple explcitamente. El papel del requisito de robustez es asegurar que si tal caso surgiese el Sistema no causar eventos catastrficos; debera producir mensajes de error apropiados, terminar su ejecucin limpiamente en lo posible. Extensibilidad El Software se supone que es Software (blando), y realmente lo es en un principio; nada es ms fcil de cambiar que un programa si se tiene acceso a su cdigo fuente. El problema de extensibilidad es un problema de escala. Para programas pequeos realizar cambios no es normalmente una tarea difcil; pero a medida que el Software crece comienza a ser cada vez ms difcil de adaptar. La extensibilidad es necesaria porque en la base de todo Software encontramos algn fenmeno humano y de ah su volatilidad. El cambio es omnipresente en el desarrollo del Software: cambios en los requisitos, de nuestra comprensin de los requisitos, de los algoritmos, de la representacin de los datos, de las tcnicas de implementacin. Ofrecer soporte para los cambios es un objetivo bsico de la tecnologa de objetos. Aunque muchas de las tcnicas que mejoran la extensibilidad se pueden aplicar con pequeos ejemplos, su relevancia slo se ve con claridad en los grandes proyectos. Hay dos principios esenciales para mejorar la extensibilidad: Simplicidad del diseo: una arquitectura simple siempre ser ms fcil de adaptar a los cambios que una compleja. Descentralizacin: cuanto ms autnomos sean los mdulos, ms alta es la probabilidad de que un cambio afecte a un solo mdulo, o a un nmero pequeo de mdulos, en lugar de provocar una reaccin en cadena de cambios en el Sistema completo.
Elaborados por: Lic. Martin Valencia Pg. 48
INSTITUTO TECNOLGICO DE JIQUILPAN Apuntes de Fundamentos de Desarrollo de Sistemas Ingeniera en Sistemas Computacionales Plan 2004
Reutilizacin La necesidad de la reutilizacin surge de la observacin de que los Sistemas de Software a menudo siguen patrones similares; debera ser posible explotar esta similitud y evitar reinventar soluciones a problemas que ya han sido encontradas con anterioridad. Capturando tal patrn, un elemento de Software reutilizable se podr aplicar en muchos desarrollos diferentes. La reutilizacin tiene una influencia sobre todos los dems aspectos de la Calidad del Software, ya que al resolver el problema de la reutilizacin se tendr que escribir menos Software y en consecuencia se podrn dedicar entonces mayores esfuerzos a mejorar los otros factores, tales como la correccin y la robustez. Compatibilidad La compatibilidad es importante debido a que los Sistemas Software no se desarrollan en el vaco: necesitan interactuar con otros. Pero con mucha frecuencia los Sistemas tienen dificultades para interactuar porque hacen suposiciones contradictorias sobre el resto del mundo. Un ejemplo es la amplia variedad de formatos de archivos soportados por muchos Sistemas operativos. Un programa puede usar directamente como entrada los resultados de otro slo si los formatos de archivos son compatibles. La clave de la compatibilidad recae en la homogeneidad del diseo y en acordar convenciones estndares para la comunicacin entre programas. Los enfoques incluyen: Formatos de archivos estndares, como en el Sistema Unix, donde cualquier archivo de texto es simplemente una secuencia de caracteres. Estructuras de datos estndares como en los Sistemas Lisp, donde tanto los datos como los programas, se representan mediante rboles binarios. Interfaces de usuario estndares, como en las diferentes versiones de Windows donde todas las herramientas utilizan un solo paradigma para la comunicacin con el usuario, basado en componentes estndares tales como ventanas, conos, mens, etc.
Eficiencia Casi sinnimo de eficiencia es la palabra rendimiento. La comunidad del Software muestra dos tipos de actitud con relacin a la eficiencia: Algunos desarrolladores tienen una obsesin con las cuestiones de rendimiento y le dedican gran cantidad de esfuerzos a presuntas optimizaciones. Por otro lado, existe la tendencia de soslayar las cuestiones de eficiencia, como se evidencia en las frases de la industria hgalo correcto antes de hacerlo rpido y de todos modos los modelos de computadoras del ao que viene van a ser un 50% ms rpidos. De manera ms general, la preocupacin por la eficiencia debe sopesarse con otros objetivos tales como la extensibilidad y la reutilizacin; optimizaciones extremas pueden hacer al Software tan especializado que limite el cambio y la reutilizacin. Es ms, la potencia creciente del Hardware de las computadoras nos permite tener una actitud ms relajada con respecto a tratar de ganar hasta el ltimo byte o microsegundo.
Elaborados por: Lic. Martin Valencia Pg. 49
INSTITUTO TECNOLGICO DE JIQUILPAN Apuntes de Fundamentos de Desarrollo de Sistemas Ingeniera en Sistemas Computacionales Plan 2004
Portabilidad (transportabilidad) La portabilidad tiene que ver con las variaciones no slo del Hardware fsico sino ms generalmente de la mquina Hardware-Software, la que realmente programamos y que incluye el Sistema operativo, el Sistema de ventanas y otras herramientas fundamentales. Muchas de las incompatibilidades existentes entre las plataformas son injustificadas, y convierte a la portabilidad en un asunto primordial tanto para los que desarrollan como para los que usan el Software. Facilidad de uso La definicin insiste en los diferentes niveles de experiencia de los posibles usuarios. Este requisito plantea uno de los mayores retos de los diseadores de Software preocupados por la facilidad de uso: cmo proporcionar explicaciones y guas detalladas a los usuarios novatos sin fastidiar a los usuarios expertos que quieren ir directo al grano. Una de las claves de la facilidad de uso es la simplicidad estructural. Un Sistema bien diseado, construido de acuerdo a una estructura clara y bien pensada, tiende a ser ms fcil de aprender y usar que uno confuso. Los buenos diseadores de interfaces siguen una poltica prudente. Hacen las menos suposiciones posibles sobre los usuarios. Cuando se disea un Sistema interactivo, se debe esperar que los usuarios sean miembros de la raza humana y que sepan leer, mover un ratn, presionar un botn y teclear (lentamente); no mucho ms. Si el Software est dirigido a un rea especializada de aplicacin, se puede dar por supuesto que los usuarios estn familiarizados con sus conceptos bsicos. Pero incluso esto es arriesgado.
Funcionalidad Uno de los problemas ms difciles a los que se enfrenta un jefe de proyecto es conocer cuanta funcionalidad es suficiente. La presin para ofrecer ms facilidades (conocida como featurism), est constantemente presente. Sus consecuencias son malas para los proyectos internos, donde las presiones vienen de los usuarios de la misma compaa, y son peores para los productos comerciales, ya que la parte ms destacada de los anlisis comparativos suele ser una tabla donde se enumeran una por una las propiedades que ofrecen los distintos productos analizados. El featurism, es realmente la combinacin de dos problemas, uno ms difcil que el otro. El problema ms fcil es la prdida de consistencia como consecuencia de estar aadiendo nuevas propiedades, lo que puede afectar a su facilidad de uso. Los usuarios se quejan con razn de que toda la parafernalia que acompaa a una nueva versin de un producto lo hace tremendamente complejo. Tales comentarios no deberan preocuparnos en exceso, puesto que las nuevas propiedades no surgen de la nada: la mayor parte de las veces han sido solicitadas por los usuarios finales. Lo que a unos les puede resultar algo superfluo puede ser una facilidad indispensable para otros. La solucin aqu es trabajar una y otra vez sobre la consistencia del producto global, tratando de que todo encaje en un molde general. Un buen producto Software est basado en un nmero pequeo de potentes ideas; incluso si tiene muchas propiedades especializadas, stas deberan explicarse como consecuencia de los conceptos bsicos. El gran plan debe estar visible y todo debera ocupar su sitio dentro de l.
Elaborados por: Lic. Martin Valencia Pg. 50
INSTITUTO TECNOLGICO DE JIQUILPAN Apuntes de Fundamentos de Desarrollo de Sistemas Ingeniera en Sistemas Computacionales Plan 2004
Oportunidad La oportunidad es una de las mayores frustraciones de nuestra industria. Un gran producto Software que aparece demasiado tarde puede no alcanzar su objetivo. Esto es cierto en otras industrias tambin, pero pocas evolucionan tan rpidamente como el Software. La oportunidad es todava, para grandes proyectos, un fenmeno poco comn. Cuando Microsoft anunci que la ltima versin de su principal Sistema operativo, que llevaba realizando varios aos, saldra al mercado un mes antes de lo previsto, el suceso fue lo suficientemente relevante como para encabezar los titulares de Computer World. Otras cualidades: Adems de las cualidades analizadas, existen otras que afectan a los usuarios de Sistemas Software y a la gente que compra estos Sistemas o encarga su desarrollo. En particular: Verificabilidad: es la facilidad para preparar procedimientos de aceptacin, especialmente datos de prueba y procedimientos para detectar fallos y localizar errores durante las fases de validacin y operacin. Integridad: es la capacidad de los Sistemas Software de proteger sus diversos componentes (programas, datos, etc.) contra modificaciones y accesos no autorizados. Reparabilidad: es la capacidad para facilitar la reparacin de los defectos. Economa: junto con la oportunidad, es la capacidad que un Sistema tiene de completarse con el presupuesto asignado o por debajo del mismo. Sobre la documentacin: En una lista de factores de Calidad del Software, uno podra esperar encontrar la presencia de una buena documentacin como uno de los requisitos. Pero ste no es un factor de calidad separado; la necesidad de documentacin es una consecuencia de otros factores de calidad vistos anteriormente. Se pueden distinguir tres tipos de documentacin: La necesidad de documentacin externa, que permite a los usuarios conocer la potencia de un Sistema y usarlo convenientemente, es una consecuencia de la definicin de facilidad de uso. La necesidad de documentacin interna, que permite a los desarrolladores de Software comprender la estructura e implementacin de un Sistema, es una consecuencia del requisito de extensibilidad. La necesidad de documentacin de la interfaz de un mdulo, que permite a los desarrolladores de Software comprender las funciones proporcionadas por un mdulo sin tener que comprender su implementacin, es una consecuencia del requisito de reutilizacin. Tambin se desprende de la extensibilidad, ya que una documentacin de la interfaz de un mdulo permite determinar cundo cierto cambio afecta a un determinado mdulo. En lugar de tratar la documentacin como un producto propio del Software, es preferible producir Software lo ms autodocumentado posible. Esto se aplica a los tres tipos de documentacin:
Elaborados por:
Pg. 51
INSTITUTO TECNOLGICO DE JIQUILPAN Apuntes de Fundamentos de Desarrollo de Sistemas Ingeniera en Sistemas Computacionales Plan 2004
Incluyendo facilidades de ayuda en lnea y siguiendo normas para interfaces claras y consistentes, se alivia la tarea de los autores de los manuales de usuario y de otras formas de documentacin externa. Un buen lenguaje de implementacin puede eliminar muchas de las necesidades de documentacin interna si favorece la claridad y la estructura. La notacin soportar la ocultacin de informacin y otras tcnicas para separar la interfaz de los mdulos de su implementacin. Ser posible entonces utilizar herramientas para producir automticamente documentacin de la interfaz del mdulo a partir del texto de los mdulos.
UNIDAD III PARADIGMAS DE LA INGENIERIA DE SOFTWARE Introduccin: a los Paradigmas de la Ingeniera del Software La ingeniera de Software surge de la ingeniera de Sistemas y de Hardware. Abarca un conjunto de tres elementos que facilitan el control sobre el proceso de desarrollo de Software y suministran las bases para construir Software de calidad de una forma productiva: Mtodos Herramientas Procedimientos Mtodos que indican cmo construir el Software tcnicamente e incluyen un amplio espectro de mtodos para la planificacin, la estimacin, el anlisis, el diseo, codificacin, prueba y mantenimiento. Herramientas automticas y semiautomticas que apoyan a la aplicacin de los mtodos. Cuando se integran las herramientas de forma que la informacin creada por una herramienta puede ser usada por otra, se establece un Sistema para el soporte del desarrollo de Software, llamado Ingeniera de Software Asistida por Computadora ( CASE ). Procedimientos que definen la secuencia en la que se aplican los mtodos, las entregas, los controles de calidad y guas para evaluacin del progreso. La Ingeniera de Software est compuesta por una serie de pasos que abarcan los mtodos, herramientas y procedimientos mencionados, a los que se denominan Paradigmas de la Ingeniera de Software.
Elaborados por: Lic. Martin Valencia Pg. 52
INSTITUTO TECNOLGICO DE JIQUILPAN Apuntes de Fundamentos de Desarrollo de Sistemas Ingeniera en Sistemas Computacionales Plan 2004
a) Los que soportan tcnicas de programacin de bajo nivel (copia de ficheros frente estructuras de datos compartidos) b) Los que soportan mtodos de diseo de algoritmos (programacin dinmica) c) Los que soportan soluciones de programacin de alto nivel. La ingeniera de Software est compuesta por una serie de pasos de abarcan los mtodos, las herramientas y los procedimientos antes mencionados. Estos pasos se denominan frecuentemente paradigmas de la ingeniera de Software. La eleccin de un paradigma para la ingeniera de Software se lleva a cabo de acuerdo con la naturaleza del proyecto y de la aplicacin, los mtodos, herramientas a usar, los controles y entregas requeridos.
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 cdigo fuente. DFD es un diagrama en el q participan procesos (mtodos), flujo de datos (argumentos) y archivos (base de datos). Hay de diferentes niveles dependiendo la complejidad del Sistema que analiza. Hablando de lenguajes Tiene muchas diferencias con la OO. Un mnimo cambio en el cdigo puede llegar alterar al resto del programa cosa que en uno OO bien encarado eso no sucede lo cual es una ventaja porque as no se pierde tiempo en arreglar cosas ya hechas. Otra desventaja es que una porcin de cdigo en lenguaje estructurado es difcil que pueda servir en otros proyectos, esto s es habitual en lenguajes OO, con solo importar clases ya hechas se escribe menos cdigo y se ahorra tiempo. 3.1.1 Diagramas de Flujo de Datos Un diagrama de flujo de datos (DFD) es un modelo lgico-grfico para representar el funcionamiento de un Sistema en un proyecto Software. Sus elementos grficos son crculos, flechas, y rectngulos cerrados o abiertos. Los cerrados representan entidades externas mientras que los abiertos describen almacenes o archivos. Los crculos significan procesos y las flechas flujos de datos desde, o hacia, un proceso. En un DFD tambin se utiliza la escritura. Los flujos, entidades externas y los almacenes se etiquetan con un nombre. Los procesos se etiquetan con un nmero y un verbo en infinitivo con objeto directo. Un diagrama de flujo de datos puede ser profundizado expandiendo algunos de sus procesos en subprocesos, en este caso la etiqueta tendr un nmero adicional. No hay un lmite para el nmero de procesos. Un diagrama de flujo de datos (DFD por sus siglas en espaol e ingls) es una representacin grfica del flujo de datos a travs de un Sistema de informacin. Un diagrama de flujo de datos tambin se puede utilizar para la visualizacin de procesamiento de datos (diseo estructurado). Es una prctica comn para un diseador dibujar un contexto a nivel de DFD que primero muestra la interaccin entre el Sistema y las
Elaborados por: Lic. Martin Valencia Pg. 53
INSTITUTO TECNOLGICO DE JIQUILPAN Apuntes de Fundamentos de Desarrollo de Sistemas Ingeniera en Sistemas Computacionales Plan 2004
entidades externas. Este contexto a nivel de DFD se explot para mostrar ms detalles del Sistema que se est modelando. Los diagramas de flujo de datos fueron inventados por Larry Constantine, el desarrollador original del diseo estructurado, basado en el modelo de computacin de Martin y Estrin: flujo grfico de datos. Los diagramas de flujo de datos (DFDs) son una de las tres perspectivas esenciales de Anlisis de Sistemas Estructurados y Diseo por Mtodo SSADM. El patrocinador de un proyecto y los usuarios finales tendrn que ser informados y consultados en todas las etapas de una evolucin del Sistema. Con un diagrama de flujo de datos, los usuarios van a poder visualizar la forma en que el Sistema funcione, lo que el Sistema va a lograr, y cmo el Sistema se pondr en prctica. 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 ms eficiente. Los diagramas de flujo de datos pueden ser usados para proporcionar al usuario final una idea fsica de cmo resultarn los datos a ltima instancia, y cmo tienen un efecto sobre la estructura de todo el Sistema. La manera en que cualquier Sistema es desarrollado puede determinarse a travs de un diagrama de flujo de datos. El desarrollo de un DFD ayuda en la identificacin de los datos de la transaccin en el modelo de datos.
Los diagramas derivados de los procesos principales se clasifican en niveles, los cuales son: Nivel 0: Diagrama de contexto. Nivel 1: Diagrama de nivel superior. Nivel 2: Diagrama de detalle o expansin.
3.1.2 Diccionario de datos El diccionario de datos es un listado organizado de todos los datos que pertenecen a un Sistema. El objetivo de un diccionario de datos es dar precisin sobre los datos que se manejan en un Sistema, evitando as malas interpretaciones o ambigedades. Define con precisin los datos de entrada, salida, componentes de almacenes, flujos, detalles de las relaciones entre almacenes, etc. Los diccionarios de datos son buenos complementos a los diagramas de flujo de datos, los diagramas de entidad-relacin, etc. Un diccionario de datos es un conjunto de metadatos que contiene las caractersticas lgicas de los datos que se van a utilizar en el Sistema que se programa, incluyendo nombre, descripcin, alias, contenido y organizacin. Estos diccionarios se desarrollan durante el anlisis de flujo de datos y ayuda a los analistas que participan en la determinacin de los requerimientos del Sistema, su contenido tambin se emplea durante el diseo del proyecto.
Elaborados por: Lic. Martin Valencia Pg. 54
INSTITUTO TECNOLGICO DE JIQUILPAN Apuntes de Fundamentos de Desarrollo de Sistemas Ingeniera en Sistemas Computacionales Plan 2004
Identifica los procesos donde se emplean los datos y los sitios donde se necesita el acceso inmediato a la informacin, se desarrolla durante el anlisis de flujo de datos y auxilia a los analistas que participan en la determinacin de los requerimientos del Sistema, su contenido tambin se emplea durante el diseo. En un diccionario de datos se encuentra la lista de todos los elementos que forman parte del flujo de datos de todo el Sistema. Los elementos ms importantes son flujos de datos, almacenes de datos y procesos. El diccionario de datos guarda los detalles y descripcin de todos estos elementos. NOTACIN Las estructuras de datos son descritas por lo general usando notacin algebraica. La notacin algebraica usa los siguientes smbolos: 1. Un signo de igual (=) significa est compuesto de. 2. Un signo de ms (+) significa y. 3. Las llaves { } indican elementos repetidos, tambin llamados grupos repetidos o tablas. Puede haber uno o varios elementos repetidos dentro del grupo. El grupo repetido puede tener condiciones, tales como una cantidad fija de repeticiones o lmites, superior e inferior para la cantidad de repeticiones. 4. Los corchetes [ ] representan una situacin disyuntiva. Puede estar presente un elemento u otro, pero no ambos. Los elementos listados entre corchetes son mutuamente excluyentes, y se separan mediante barras ( | ). 5. Los parntesis ( ) representan un elemento opcional. Los elementos opcionales pueden ser dejados en blanco en las pantallas de captura, y pueden contener espacios o ceros para los campos numricos en las estructuras de archivo. 6. La @ (o una definicin subrayada) identifica la llave para un almacn de datos. 7. Una frase entre asteriscos es un comentario (* *). EJEMPLO: Nombre = Ttulo + Primer-nombre + Apellido-paterno + Apellido-materno Ttulo = [ Sr | Sra | Dr | Ing] Primer-nombre = {caracter} Apellido-paterno = {caracter} Apellido-materno = {caracter} caracter = [A-Z|a-z| |] a DEFINICIONES
Elaborados por: Lic. Martin Valencia Pg. 55
INSTITUTO TECNOLGICO DE JIQUILPAN Apuntes de Fundamentos de Desarrollo de Sistemas Ingeniera en Sistemas Computacionales Plan 2004
Una definicin de un dato se introduce mediante el smbolo =; en este contexto el = se lee como est definido por, o est compuesto de, o significa. Para definir un dato completamente, la definicin debe incluir: El significado del dato en el contexto de la aplicacin. Esto se documenta en forma de comentario. La composicin del dato, si es que est compuesto de otros elementos significativos. Los valores que el dato puede tomar, si se trata de un dato elemental que ya no puede ser descompuesto. DATOS ELEMENTALES Son aquellos para los cuales no hay una descomposicin significativa. Por ejemplo, puede ser que no se requiera descomponer el nombre de una persona en primer-nombre, apellido-materno y apellido-paterno; esto depende del contexto del Sistema que se est modelando. Cuando se han identificado los datos elementales, deben ser introducidos en el DD y proveer una breve descripcin que describa el significado del dato. En el caso de que el dato tenga un nombre significativo, se puede omitir la descripcin, sin embargo, es importante especificar las unidades de medida que el dato puede tomar. Ejemplo: Peso = * peso del paciente al ingresar al hospital * Unidad: kilo, rango:2150 * Altura = * unidad: cm, rango: 100200 * Sexo = * valores : [F|M] * APGR Ingeniera de Software I Anlisis Estructurado 24 DATOS OPCIONALES Un dato opcional es aquel que puede o no estar presente como componente de un dato compuesto. Ejemplo: Direccin = calle + nmero + (ciudad) + (pas) + (cdigo-postal) SELECCIN Indica que un elemento consiste de exactamente una opcin de un conjunto de alternativas. Ejemplos: Sexo = [Femenino | Masculino] Tipo-de-cliente = [Gubernamental | Acadmico | Industria | Otros] ITERACIN Se usa para indicar ocurrencias repetidas de un componente en un elemento compuesto. Ejemplo: Ordende compra = nombre-cliente + direccin-de-envo + {artculo} significa que una orden de compra siempre debe contener un nombre de cliente, una direccin de envo y cero o ms ocurrencias de un artculo. Ejemplo: Se pueden especificar lmites superiores e inferiores a las iteraciones. Orden-de compra = nombre-cliente + direccin-de-envo + 1{artculo} 10 significa que una orden de compra siempre debe contener un nombre de cliente, una direccin de envo y de 1 a 10 artculos. APGR Ingeniera de Software I Anlisis Estructurado 25 Ejemplos de iteraciones con lmites: a = 1{b} a = {b} 10 a = 1{b}10 a = {b}
Elaborados por:
Pg. 56
INSTITUTO TECNOLGICO DE JIQUILPAN Apuntes de Fundamentos de Desarrollo de Sistemas Ingeniera en Sistemas Computacionales Plan 2004
Un modelo de datos es un lenguaje orientado a describir una Base de Datos. Tpicamente un Modelo de Datos permite describir: Las estructuras de datos de la base: El tipo de los datos que hay en la base y la forma en que se relacionan. Las restricciones de integridad: Un conjunto de condiciones que deben cumplir los datos para reflejar correctamente la realidad deseada. Operaciones de manipulacin de los datos: tpicamente, operaciones de agregado, borrado, modificacin y recuperacin de los datos de la base. Otro enfoque es pensar que un modelo de datos permite describir los elementos de la realidad que intervienen en un problema dado y la forma en que se relacionan esos elementos entre s. No hay que perder de vista que una Base de Datos siempre est orientada a resolver un problema determinado, por lo que los dos enfoques propuestos son necesarios en cualquier desarrollo de Software. Una opcin bastante usada a la hora de clasificar los modelos de datos es hacerlo de acuerdo al nivel de abstraccin que presentan: Modelos de Datos Conceptuales Son los orientados a la descripcin de estructuras de datos y restricciones de integridad. Se usan fundamentalmente durante la etapa de Anlisis de un problema dado y estn orientados a representar los elementos que intervienen en ese problema y sus relaciones. El ejemplo ms tpico es el Modelo EntidadRelacin. Modelos de Datos Lgicos Son orientados a las operaciones ms que a la descripcin de una realidad. Usualmente estn implementados en algn Manejador de Base de Datos. El ejemplo ms tpico es el Modelo Relacional, que cuenta con la particularidad de contar tambin con buenas caractersticas conceptuales (Normalizacin de bases de datos). Modelos de Datos Fsicos Son estructuras de datos a bajo nivel implementadas dentro del propio manejador. Ejemplos tpicos de estas estructuras son los rboles B+, las estructuras de Hash, etc. Un (DFD) presenta ser subdividido en diferentes partes, que llamaremos mdulos conteniendo cada uno de ellos procedimientos manuales o automatizados, a fin de que el Sistema pueda ser desarrollado y ejecutado en unidades menores, ms fciles de implementar manejar y controlar. Estos mdulos pueden ser un programa, un procedimiento, una relacin de operaciones o comandos 3.1.4 Descomposicin En Procesos. Las organizaciones, funcionales, desarrollan mltiples actividades el componente bsico de estas corresponde a la tarea, entendida como una microactividad que se responsabiliza a una sola persona.
Elaborados por: Lic. Martin Valencia Pg. 57
INSTITUTO TECNOLGICO DE JIQUILPAN Apuntes de Fundamentos de Desarrollo de Sistemas Ingeniera en Sistemas Computacionales Plan 2004
Grupos de tareas conforman actividades ms complejas que se denominan procesos. Todos los procesos tienen entradas (recursos humanos, tecnolgicos materiales, etc.) para el desarrollo de las actividades que lo conforman; como salidas se esperan productos, servicios, informacin, activos financieros, etc. Entiende todo proceso como un : CONJUNTO DE TAREAS LOGICAMENTE RELACIONADAS QUE EXISTEN PARA OBTENER UN RESULTADO BIEN DEFINIDO DENTRO DE UN NEGOCIO.
3.2 Enfoque Orientado a Objetos. Historia: Vivimos en un mundo de objetos. Estos objetos existen en la naturaleza, en entidades hechas por el hombre, en los negocios y en los productos que usamos. Pueden ser clasificados, descritos, organizados, combinados, manipulados y creados. Por eso no es sorprendente que se proponga una visin orientada a objetos para la creacin de Software de computadora, una abstraccin que modela el mundo de forma tal que nos ayuda a entenderlo y gobernarlo mejor. La primera vez que se propuso un enfoque orientado a objetos para el desarrollo de Software fue a finales de los aos sesenta. Sin embargo, las tecnologas de objetos han necesitado casi veinte aos para llegar a ser ampliamente usadas. Durante los aos 90, la ingeniera del Software orientada a objetos se convirti en el paradigma de eleccin para muchos productores de Software y para un creciente nmero de Sistemas de informacin y profesionales de la ingeniera. Las tecnologas de objetos llevan a reutilizar, y la reutilizacin (de componente de Software) lleva a un desarrollo de Software ms rpido y a programas de mejor calidad. El Software orientado a objetos es ms fcil de mantener debido a que su estructura es inherentemente poco acoplada. Esto lleva a menores efectos colaterales cuando se deben hacer cambios. Los Sistemas orientados a objetos son ms fciles de adaptar y ms fcilmente escalables (pueden crearse grandes Sistemas ensamblando subSistemas reutilizables). Hacia mediados de los 80, los beneficios de la programacin orientada a objetos empezaron a obtener reconocimiento, y el diseo de objetos pareci ser un enfoque sensato para la gente que deseaba utilizar el lenguaje de programacin orientada a objetos. Un enfoque orientado a objetos para programar ofrece muchos beneficios sobre un enfoque estructurado. El anlisis orientado a objetos y su diseo se enfoca en los objetos. Los objetos tienen ciertos comportamientos y atributos que determinan la manera en que interactan y funcionan. No se intenta proporcionar un orden para las acciones al momento del diseo debido a que los objetos funcionan basados en la manera en que funcionan otros objetos. La programacin orientada a objetos ayuda a los desarrolladores a crear objetos que reflejan escenarios del mundo real. Las implementaciones orientadas a objetos ocultan datos, lo cual significa que muestran nicamente los comportamientos a los usuarios y ocultan el cdigo subyacente de un objeto. Los comportamientos que el programador expone son nicamente aquellos elementos que el usuario de un objeto puede afectar.
Elaborados por: Lic. Martin Valencia Pg. 58
INSTITUTO TECNOLGICO DE JIQUILPAN Apuntes de Fundamentos de Desarrollo de Sistemas Ingeniera en Sistemas Computacionales Plan 2004
El enfoque orientado a objetos permite que los objetos estn autocontenidos. Los objetos existen por s mismos, con una funcionalidad para invocar comportamientos de otros objetos. Al utilizar un enfoque orientado a objetos, los desarrolladores pueden crear aplicaciones que reflejan objetos del mundo real, como rectngulos, elipses y tringulos, adems de dinero, nmeros de partes y elementos en un inventario. En un enfoque orientado a objetos, los objetos, por definicin, son modulares en su construccin. Esto quiere decir que son entidades completas y, por lo tanto, tienden a ser altamente reutilizables. Las aplicaciones orientadas a objetos se construyen sobre el paradigma de los mensajes o de los eventos en donde los objetos envan mensajes a otros objetos, como el Sistema operativo Microsoft Windows. a. El paradigma orientado a objetos Durante muchos aos el trmino 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, C++, Eiffel, Smalltalk, etc.). En el libro The Structure of Scientific Revolutions, el historiador Thomas K describa un paradigma como un conjunto de teoras, estndar y mtodos que juntos representan un medio de organizacin del conocimiento: es decir, un medio de visualizar el mundo. En este sentido, la programacin orientada a objetos es un nuevo paradigma. La orientacin a objetos fuerza a reconsiderar nuestro pensamiento sobre la computacin, sobre lo que significa realizar computacin y sobre cmo se estructura la informacin dentro de la computadora. Jenkins y Glasgow observan que la mayora de los programadores trabajan en un lenguaje y utilizan slo un estilo de programacin. Ellos programan en un paradigma forzado por el lenguaje que utilizan. Con frecuencia, no se enfrentan a mtodos alternativos de resolucin de un problema, y por consiguiente tienen dificultad en ver la ventaja de elegir un estilo ms apropiado al problema a manejar. Bobrow y Stefik sugieren que existen cuatro clases de estilos de programacin:
Orientados a procedimientos: Algoritmos. Orientados a objetos: Clases y Objetos. Orientados a lgica: Expresado en clculo de predicados. Orientados a reglas: Reglas if-then.
No existe ningn estilo de programacin idneo para todas las clases de programacin. La orientacin a objetos se acopla a la simulacin de situaciones del mundo real. b. Orientacin a Objetos La orientacin a objetos puede describirse como el conjunto de disciplinas que desarrollan y modelan Software, que facilitan la construccin de Sistemas complejos a partir de componentes. El atractivo intuitivo de la orientacin a objetos es que proporciona conceptos y herramientas con las cuales se modela y representa el mundo real tan fielmente como sea posible. Estos conceptos y herramientas orientados a objetos son tecnologas que permiten que los problemas del mundo real sean expresados de modo fcil y natural. Las tcnicas orientadas a objetos proporcionan mejoras y metodologas para construir Sistemas de Software complejos a partir de unidades de Software modularizado y reutilizable. Se necesita un nuevo enfoque para construir Software en la actualidad. Este nuevo enfoque debe ser capaz de manipular tanto
Elaborados por: Lic. Martin Valencia Pg. 59
INSTITUTO TECNOLGICO DE JIQUILPAN Apuntes de Fundamentos de Desarrollo de Sistemas Ingeniera en Sistemas Computacionales Plan 2004
Sistemas grandes como pequeos y debe crear Sistemas fiables que sean flexibles, mantenibles y capaces de evolucionar para cumplir las necesidades del cambio. La orientacin a objetos trata de cubrir las necesidades de los usuarios finales, as como las propias de los desarrolladores de productos Software. Estas tareas se realizan mediante la modelizacin del mundo real. El soporte fundamental es el modelo objeto. Un objeto es la instancia de una clase. Una clase es la representacin abstracta de un concepto en el mundo real, y proporciona la base a partir de la cual creamos instancias de objetos especficos. Como ejemplo, puede crear una clase que defina a un cliente. Despus puede crear una nueva instancia de la clase cliente para tener un objeto utilizable de Cliente. Para poder crear un objeto de la clase cliente, debe crear una nueva instancia basada en esa clase. Por ejemplo: Private Objeto Customer? as Clase Customer? Objeto Customer = New Clase Customer() Cada objeto es un elemento nico de la clase en la que se basa. Si una clase es como un molde, entonces un objeto es lo que se crea a partir del molde. La clase es la definicin de un elemento; el objeto es el elemento. El molde para una figura de cermica en particular, es como una clase; la figura es el objeto. Todos los objetos estn compuestos de tres cosas: Interfaz: La Interfaz es el conjunto de mtodos, propiedades, eventos y atributos que se declaran como pblicos en su alcance y que pueden invocar los programas escritos para usar nuestro objeto. Implementacin: Al cdigo dentro de los mtodos se le llama Implementacin. Algunas veces tambin se le llama comportamiento, ya que este cdigo es el que efectivamente logra que el objeto haga un trabajo til. Es importante entender que las aplicaciones del cliente pueden utilizar nuestro objeto aunque cambiemos la implementacin, siempre que no cambiemos la interfaz. Siempre que se mantengan sin cambio nuestro nombre de mtodo, su lista de parmetro y el tipo de datos de devolucin, podremos cambiar la implementacin totalmente. Estado: El estado o los datos de un objeto es lo que lo hace diferente de otros objetos de la misma clase. El estado se describe a travs de las variables del Miembro o de la Instancia. Las variables del miembro son aquellas declaradas, de tal manera que estn disponibles para todo el cdigo dentro de la clase. Por lo general, las variables del miembro son Privadas en su alcance. Algunas veces, se les conoce como variables de la instancia o como atributos. Observe que las propiedades no son variables del Miembro, ya que son un tipo de mtodo que funciona para recuperar y establecer valores.
Elaborados por:
Pg. 60
INSTITUTO TECNOLGICO DE JIQUILPAN Apuntes de Fundamentos de Desarrollo de Sistemas Ingeniera en Sistemas Computacionales Plan 2004
Qu es una clase? Una clase es esencialmente un proyecto, a partir del cual puede crear objetos. Una clase define las caractersticas de un objeto, incluyendo las propiedades que definen los tipos de datos que ese objeto puede contener y los mtodos que describen el comportamiento del objeto. Estas caractersticas determinan la manera en que otros objetos pueden acceder y trabajar con los datos que se incluyen en el objeto. Para definir una clase, se coloca la palabra clave Class antes del nombre de su clase, y despus se insertan los miembros de la clase (datos y mtodos) entre la definicin del nombre de la clase y la instruccin End Class. Si incluye los mtodos, entonces el cdigo de cada mtodo tambin se debe incluir entre la declaracin del mtodo y el final del mismo. Por ejemplo, si desea construir objetos que representen perros, puede definir una clase Perro con ciertos comportamientos, como caminar, ladrar y comer, y propiedades especficas, como altura, peso y color. Una vez que haya definido la clase Perro, puede crear objetos con base en esa clase. Es importante observar que todos los objetos Perro creados con base en la clase perro compartirn los mismos comportamientos, pero tendrn sus propios valores especficos para el mismo conjunto de propiedades. El siguiente ejemplo representa la definicin de la clase Perro. Tome en consideracin que sta no es una sintaxis estricta de VB.NET; simplemente es un ejemplo de la definicin de clase. Public Class Perro Dim Altura As Decimal Dim Peso As Decimal Dim Color As String Sub Caminar(ByVal Pasos As Integer) End Sub Sub Ladrar() End Sub Sub Comer() End Sub End Class #] Vamos con otro ejemplo. El siguiente ejemplo define una nueva clase, Persona, con dos partes de informacin relevante asociadas: el nombre de la persona, su fecha de nacimiento y un Mtodo que calcula la edad de la persona. A pesar de que la clase Persona se define en el ejemplo, no existe an el objeto Persona. Debern ser creados. [@ Public Class Persona Private mstrNombre As String Private mdtFechaNacimiento As Date
Elaborados por:
Pg. 61
INSTITUTO TECNOLGICO DE JIQUILPAN Apuntes de Fundamentos de Desarrollo de Sistemas Ingeniera en Sistemas Computacionales Plan 2004
Public Function Edad() As Integer Return DateDiff(DateInterval.Year, mdtFechaNacimiento, Now()) End Function End Class Una clase es un tipo definido por el usuario en contraposicin a un tipo proporcionado por el Sistema. Al definir una clase, en realidad crea un nuevo tipo en su aplicacin. Ahora que ya sabis todo esto, vamos con os elementos (propiedades) ms importantes de este modelo. Estas son:
Como sugiere Booch, si alguno de estos elementos no existe se dice que el modelo no es orientado a objetos. Abstraccin: La abstraccin es uno de los medios ms importantes, mediante el cual nos enfrentamos con la complejidad inherente al Software. La abstraccin es la propiedad que permite representar las caractersticas esenciales de un objeto, sin preocuparse de las restantes caractersticas (no esenciales). Abstraccin es la tcnica de quitarle a una idea o a un objeto todos los acompaamientos innecesarios hasta que los deja en una forma esencial y mnima. Una buena abstraccin elimina todos los detalles poco importantes y le permite enfocarse y concentrarse en los detalles importantes. Una abstraccin se centra en la vista externa de un objeto, de modo que sirva para separar el comportamiento esencial de un objeto de su implementacin. Definir una abstraccin significa describir una entidad del mundo real, no importa lo compleja que pueda ser y, a continuacin, utilizar esta descripcin en un programa. El elemento clave de la programacin orientada a objetos es la clase. Una clase se puede definir como una descripcin abstracta de un grupo de objetos, cada uno de los cuales se diferencia por su estado especfico y por la posibilidad de realizar una serie de operaciones. Por ejemplo, una pluma estilogrfica es un objeto que tiene un estado (llena de tinta o vaca) y sobre la cual se pueden realizar algunas operaciones (escribir, poner o quitar la tapa, llenar de tinta si est vaca, etc.). La idea de escribir programas definiendo una serie de abstracciones no es nueva, pero el uso de clases para gestionar dichas abstracciones en lenguajes de programacin ha facilitado considerablemente su aplicacin. La abstraccin es un principio de Software importante. Una clase bien diseada expone un conjunto mnimo de mtodos cuidadosamente considerados que proporcionan el comportamiento esencial de una clase en una forma fcil de usar. Crear buenas abstracciones de Software no es fcil. Encontrar buenas abstracciones generalmente requiere de un entendimiento muy claro del problema y de su contexto, gran claridad de pensamiento y amplia experiencia.
Elaborados por: Lic. Martin Valencia Pg. 62
INSTITUTO TECNOLGICO DE JIQUILPAN Apuntes de Fundamentos de Desarrollo de Sistemas Ingeniera en Sistemas Computacionales Plan 2004
Existe un principio muy importante relacionado con la abstraccin, y esta es, la Dependencia mnima. 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 mnima es lo que hace que la abstraccin 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 Encapsulacin. La encapsulacin se puede utilizar para aplicar el concepto de Abstraccin. Encapsulamiento El Encapsulamiento o encapsulacin es la propiedad que permite asegurar que el contenido de la informacin de un objeto est oculta al mundo exterior: el objeto A no conoce lo que hace el objeto B, y viceversa. La encapsulacin (tambin se conoce como ocultacin de la informacin), en esencia, es el proceso de ocultar todos los secretos de un objeto que no contribuyen a sus caractersticas esenciales. La encapsulacin permite la divisin de un programa en mdulos. Estos mdulos se implementan mediante clases, de forma que una clase representa la encapsulacin de una abstraccin. En la prctica, esto significa que cada clase debe tener dos partes: una interfaz y una implementacin. La interfaz de una clase captura slo su vista externa y la implementacin contiene la representacin de la abstraccin, as como los mecanismos que realizan el comportamiento adecuado. Encapsulacin es la capacidad de contener y controlar el acceso a un grupo de elementos asociados. Las clases proporcionan una de las formas ms comunes para encapsular elementos. En el siguiente ejemplo, la clase Bank Account? Encapsula los mtodos, campos y propiedades que se describen en una cuenta bancaria. Sin una encapsulacin, usted necesitara declarar procedimientos y variables por separado para almacenar y administrar informacin para la cuenta bancaria, y sera difcil trabajar con ms de una cuenta bancaria a la vez. La encapsulacin 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 confusin, debido a que cada cuenta est representada por una instancia nica de la clase. La encapsulacin tambin 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 mtodos 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 tcnica se le llama ocultamiento de datos. En la clase Bank Account, la informacin del cliente, como el saldo de la cuenta, se protege de esta forma. Una de las reglas bsicas de la encapsulacin es que los datos de la clase slo se pueden modificar o recuperar a travs de los procedimientos o mtodos Property. Ocultar los detalles de implementacin 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 ms adelante, podran cambiar el tipo de datos del campo Account Balance?, sin peligro de daar la aplicacin que depende de que este campo tenga un tipo de dato especfico. Class BankAccount Private AccountNumber As String Private AccountBalance As Decimal
Elaborados por: Lic. Martin Valencia Pg. 63
INSTITUTO TECNOLGICO DE JIQUILPAN Apuntes de Fundamentos de Desarrollo de Sistemas Ingeniera 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 aplicacin en partes ms pequeas (llamadas mdulos), cada una de las cuales debe ser tan independiente como sea posible de la aplicacin en s y de las restantes partes. La modularizacin consiste en dividir un programa en mdulos que se puedan compilar por separado, pero que tienen conexiones con otros mdulos. Al igual que la encapsulacin, los lenguajes soportan la Modularidad de diversas formas. La Modularidad es la propiedad de un Sistema que permite su descomposicin en un conjunto de mdulos cohesivos y dbilmente acoplados. Por supuesto no todos los mdulos son iguales: tomar un programa monoltico y separarlo de forma aleatoria en archivos no es ptimo. Se debe tener en cuenta los conceptos asociados de dependencia, acoplamiento, cohesin, interfaz, encapsulacin y abstraccin. Una vez identificado lo que es un buen mdulo, se puede contemplar la reutilizacin de un buen mdulo como componente. El Mdulo A depende del Mdulo B si cualquier cambio en el Mdulo B implica que el Mdulo A tambin tenga que ser modificado. A veces se dice que el Mdulo A es un cliente del Mdulo B, o que el Mdulo B acta como servidor del Mdulo A. En general, es normal que un mismo mdulo sea tanto cliente como servidor. Esto significa, que depende de algunos mdulos, mientras que otros mdulos dependen de l. Incluso es posible que un par de mdulos 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 reutilizacin. La dependencia a veces se conoce como acoplamiento. Un Sistema con muchas dependencias tiene fuerte acoplamiento. Los buenos Sistemas tienen dbil acoplamiento, porque en ese caso los cambios en una parte del Sistema son menos probables de propagarse a travs del Sistema. Los mdulos correctos a menudo tienen la propiedad de que sus interfaces proporcionan una abstraccin de algn elemento conocido de manera intuitiva que puede, no obstante, ser difcil de implementar. Este tipo de mdulos se dice que tienen una fuerte cohesin. El mdulo realiza un conjunto coherente de cosas, pero dentro de lo posible el desarrollador del cliente est protegido de la informacin irrelevante relativa a cmo el mdulo hace lo que hace.
Elaborados por:
Pg. 64
INSTITUTO TECNOLGICO DE JIQUILPAN Apuntes de Fundamentos de Desarrollo de Sistemas Ingeniera en Sistemas Computacionales Plan 2004
Resumiendo: Abstraccin es cuando un cliente de un mdulo no necesita saber ms de lo que hay en la interfaz. Encapsulacin es cuando un cliente de un mdulo no es capaz de saber ms de lo que hay en la interfaz. Si un mdulo, de cualquier tamao y complejidad, es una buena abstraccin (tiene fuerte cohesin y dbil acoplamiento) puede ser factible reutilizarlo en Sistemas posteriores, o sustituirlo en el Sistema existente. Jerarqua La Jerarqua es una propiedad que permite la ordenacin de las abstracciones. Las dos jerarquas ms importantes de un Sistema complejo son: estructura de clases (jerarqua es-un (is-a): generalizacin/especializacin) y estructura de objetos (jerarqua parte-de (part-of): agregacin). Las jerarquas de generalizacin/especializacin se conocen como herencia. Bsicamente, la herencia define una relacin entre clases, en donde una clase comparte la estructura o comportamiento definido en una o ms clases (herencia simple y herencia mltiple, respectivamente). La agregacin es el concepto que permite el agrupamiento fsico de estructuras relacionadas lgicamente. As, un camin se compone de ruedas, motor, Sistema de transmisin y chasis; en consecuencia, camin es una agregacin, y ruedas, motor, transmisin y chasis son agregados de camin. Polimorfismo La quinta propiedad significativa de los lenguajes de programacin orientados a objetos es el polimorfismo. Es la propiedad que indica, literalmente, la posibilidad de que una entidad tome muchas formas. En trminos prcticos, el polimorfismo permite referirse a objetos de clases diferentes mediante el mismo elemento de programa y realizar la misma operacin de diferentes formas, segn sea el objeto que se referencia en ese momento. Por ejemplo, cuando se describe la clase mamferos se puede observar que la operacin comer es una operacin fundamental en la vida de los mamferos, de modo que cada tipo de mamfero debe poder realizar la operacin o funcin comer. Por otra parte, una cabra o una vaca que pastan en un campo, un nio que se come un caramelo y un len que devora a otro animal, son diferentes formas que utilizan diferentes mamferos para realizar la misma funcin (comer). El polimorfismo adquiere su mxima expresin en la derivacin o extensin de clases, es decir, cuando se obtiene una clase a partir de una clase ya existente, mediante la propiedad de derivacin de clases o herencia. El polimorfismo requiere ligadura tarda o postergada (tambin llamada dinmica), y esto slo se puede producir en lenguajes de programacin orientados a objetos. Los lenguajes no orientados a objetos soportan ligadura temprana o anterior (tambin llamada esttica), esto significa que el compilador genera una llamada a un nombre especfico de funcin y el enlazador (linker) resuelve la llamada a la direccin absoluta del cdigo que se ha de ejecutar. En POO, el programa no puede determinar la direccin del cdigo hasta el momento de la ejecucin. Cuando se enva un mensaje a un objeto, el cdigo que se llama no se determina hasta el momento de la ejecucin. El compilador asegura que la funcin existe y realiza verificacin de tipos de los argumentos y del valor de retorno, pero no conoce el cdigo exacto a ejecutar. y Cules son los beneficios? , Buena pregunta eh !!!
Elaborados por: Lic. Martin Valencia Pg. 65
INSTITUTO TECNOLGICO DE JIQUILPAN Apuntes de Fundamentos de Desarrollo de Sistemas Ingeniera en Sistemas Computacionales Plan 2004
Los programas son fciles de disear debido a que los objetos reflejan elementos del mundo real. Las aplicaciones son ms sencillas para los usuarios debido a que los datos innecesarios estn ocultos. Los objetos son unidades autocontenidas. La productividad se incrementa debido a que puede reutilizar el cdigo. Los Sistemas son fciles de mantener y se adaptan a las cambiantes necesidades de negocios. Es ms fcil crear nuevos tipos de objetos a partir de los ya existentes. Simplifica los datos complejos. Reduce la complejidad de la transaccin. Confiabilidad. Robustez. Capacidad de ampliacin.
Otras propiedades: El modelo objeto ideal no slo tiene las propiedades anteriormente citadas sino que es conveniente que soporte, adems, estas otras propiedades: Concurrencia (multitarea): el lenguaje soporta la creacin 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 despus de la ejecucin del programa Genericidad: las clases parametrizadas (mediante plantillas o unidades genricas) sirven para soportar un alto grado de reutilizacin. Estos elementos genricos se disean con parmetros formales, que se instanciarn con parmetros reales, para crear instancias de mdulos 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 aadida al soporte de tolerancia a fallos del Software permitir una estrategia de diseo eficiente.
Taxonoma de lenguajes orientados a objetos Una taxonoma de lenguajes de programacin con propiedades de orientacin a objetos fue creada por Wegner. La clasificacin incluye los siguientes grupos: Basado en objetos: Un lenguaje de programacin es basado en objetos si su sintaxis y semntica soportan la creacin 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 programacin es basado en objetos y soporta adems la creacin de clases, se considera basado en clases. Por ejemplo: Clu. Orientacin a objetos: Un lenguaje de programacin orientado a objetos es un lenguaje basado en clases que soporta tambin herencia. Por ejemplo: Visual Basic .NET, C# .NET, C++, Java, Delphi, Eiffel, Simula.
INSTITUTO TECNOLGICO DE JIQUILPAN Apuntes de Fundamentos de Desarrollo de Sistemas Ingeniera en Sistemas Computacionales Plan 2004
Coad y Yourdon definen el trmino Orientacin a Objetos de la siguiente forma: Orientacin a Objetos = objetos + clasificacin + herencia + comunicacin Clases y Objetos: Un modelo Orientado a Objetos de Software de computadora debe exhibir abstracciones de datos y procedimientos que conducen a una Modularidad eficaz. Una clase es un concepto Orientado a Objetos que encapsula las abstracciones de datos y procedimientos que se requieren para describir el contenido y comportamiento de alguna entidad del mundo real. Las abstracciones de datos (atributos) que describen la clase estn encerradas por una muralla de abstracciones procedimentales (llamadas operaciones, mtodos o servicios) capaces de manipular los datos de alguna manera. La nica forma de alcanzar los atributos (y operar sobre ellos) es ir a travs de alguno de los mtodos que forman la muralla. Por lo tanto, la clase encapsula datos (dentro de la muralla) y el proceso que manipula los datos (los mtodos que componen la muralla). Esto posibilita la ocultacin de informacin y reduce el impacto de efectos colaterales asociados a cambios. Nota: Un objeto encapsula datos (atributos) y los mtodos (operaciones, mtodos o servicios) que manipulan esos datos. Atributos: Los atributos estn asociados a clases y objetos, y describen la clase o el objeto de alguna manera. Las entidades de la vida real estn a menudo descritas con palabras que indican caractersticas estables. La mayora de los objetos fsicos tienen caractersticas tales como forma, peso, color y tipo de material. Las personas tienen caractersticas como fecha de nacimiento, padres, nombre y color de los ojos. Una caracterstica puede verse como una relacin binaria entre una clase y cierto dominio. La relacin binaria implica que un atributo puede tomar un valor definido por un dominio enumerado. En la mayora de los casos, un dominio es simplemente un conjunto de valores especficos. Por ejemplo, supongamos que una clase Coche tiene un atributo color. El dominio de valores de color es blanco, negro, plata, gris, azul, rojo, amarillo, verde. Las caractersticas (valores del dominio) pueden aumentarse asignando un valor por defecto (caracterstica) a un atributo. Por ejemplo, el atributo color tiene el valor por defecto negro. Nota: Los valores asignados a los atributos de un objeto hacen a ese objeto ser nico. Operaciones, mtodos y servicios: Un objeto encapsula datos (representados como una coleccin de atributos) y los algoritmos que procesan estos datos. Estos algoritmos son llamados operaciones, mtodos o servicios y pueden ser vistos como mdulos en un sentido convencional. Cada uno de los mtodos encapsulados por un objeto proporciona una representacin de uno de los comportamientos del objeto. Por ejemplo, el mtodo Determinar Color?, para el objeto Coche extraer el color almacenado en el atributo color. La consecuencia de la existencia de ese mtodo es que la clase coche ha sido diseada para recibir un estmulo (mensaje) que requiere el color de una instancia particular
Elaborados por: Lic. Martin Valencia Pg. 67
INSTITUTO TECNOLGICO DE JIQUILPAN Apuntes de Fundamentos de Desarrollo de Sistemas Ingeniera en Sistemas Computacionales Plan 2004
de una clase. Cada vez que un objeto recibe un estmulo, ste inicia un cierto comportamiento, que puede ser tan simple como determinar el color del coche o tan complejo como la iniciacin de una cadena de estmulos que se pasan entre una variedad e objetos diferentes. Nota: Siempre que un objeto es estimulado por un mensaje, inicia algn comportamiento ejecutando un mtodo. Mensajes: Los mensajes son el medio a travs del cual interactan los objetos. Un mensaje estimula la ocurrencia de cierto comportamiento en el objeto receptor. El comportamiento se realiza cuando se ejecuta un mtodo. Una operacin dentro de un objeto emisor genera un mensaje de la forma: destino.operacin (parmetros) Donde destino define al objeto receptor el cual es estimulado por el mensaje, operacin se refiere al mtodo que recibe el mensaje y parmetros proporciona informacin requerida para el xito de la operacin. Los mensajes proporcionan una visin interna del comportamiento de objetos individuales, y del Sistema Orientado a Objetos como un todo. Nota: El paso de mensajes mantiene comunicado un Sistema orientado a objetos. 3.2.1 Anlisis El modelo de anlisis se extiende luego para describir la manera en que interactan los actores y el Sistema para manipular el modelo del dominio de aplicacin. Los desarrolladores usan el modelo de anlisis, junto con los requerimientos no funcionales, para preparar la arquitectura del Sistema que se desarrolla durante el diseo de alto nivel. Las actividades del anlisis: la identificacin de objetos, su comportamiento, sus relaciones, su clasificacin y su organizacin. El modelo de anlisis est compuesto por tres modelos individuales: el modelo funcional, representado por casos de uso y escenarios, el modelo de objetos de anlisis, representado por diagramas de clase y objeto, y el modelo dinmico, representado por grficas de estado y diagramas de secuencia. Conceptos de anlisis: Particularmente describimos: Objetos de entidad, frontera y control: Los objetos de entidad representan la informacin persistente rastreada por el Sistema. Los objetos de frontera representan la interaccin entre los actores y el Sistema. Los objetos de control representan las tareas realizadas por el usuario y soportadas por el Sistema.
Elaborados por:
Pg. 68
INSTITUTO TECNOLGICO DE JIQUILPAN Apuntes de Fundamentos de Desarrollo de Sistemas Ingeniera en Sistemas Computacionales Plan 2004
Multiplicidad de asociacin: el extremo de una asociacin puede etiquetarse como un conjunto de enteros llamados multiplicidad. La multiplicidad indica la cantidad de vnculos que pueden originarse legtimamente desde una instancia de la clase conectada al extremo de la asociacin. En UML, un extremo de una asociacin puede tener como multiplicidad un conjunto de enteros arbitrarios. Sin embargo, en la prctica, la mayora de las asociaciones que encontramos pertenece a alguno de los siguientes tres tipos: Una asociacin de uno a uno tiene una multiplicidad de 1 a cada extremo. Una asociacin de uno a uno entre dos clases significa que existe solamente un vnculo entre instancias de cada clase. Una asociacin de uno a muchos tiene una multiplicidad de 1 en un extremo y 0n Una asociacin de uno a muchos entre dos clases (por ejemplo, Persona y Automvil) indica composicin Una asociacin de muchos a muchos tiene una multiplicidad de 0. . n o 1. . n en ambos extremos. Una asociacin de muchos a muchos entre dos clases indica que puede existir una cantidad arbitraria de vnculos entre instancias de las dos clases. Este es el tipo ms complejo de asociacin.
Asociaciones calificadas: La calificacin es una tcnica para la reduccin de la multiplicidad usando claves. Las asociaciones que tienen multiplicidad de 01 o 1 son ms fciles de comprender que las asociaciones con multiplicidad de 0n o 1n. Con frecuencia, en el caso de una asociacin de uno a muchos, los objetos del lado de muchos pueden distinguirse entre ellos usando un nombre. Generalizacin: La generalizacin nos permite organizar conceptos en jerarquas. El anlisis para el enfoque orientado a objetos; En lugar de considerar el SW desde una perspectiva bsica de entrada-proceso-salida como los mtodos estructurados se basa en modelar el Sistema mediante los objetos que forman parte de l y las relaciones estticas (herencia y composicin ) o dinmicas(uso entre otros objetos ). El anlisis identifica las clases y objetos relativamente en el dominio del problema, el diseo proporciona detalles sobre la arquitectura, las interfaces y los componentes la implementacin transforma el diseo en cdigo y la pruebas checan tanto la arquitectura como la interfaz y los componentes. 3.2.2 Diseo Durante el diseo de objetos cerramos el hueco entre los objetos de aplicacin y los componentes hechos, identificando objetos de solucin adicionales y refinando los objetos existentes. El diseo de objetos incluye:
Elaborados por: Lic. Martin Valencia Pg. 69
INSTITUTO TECNOLGICO DE JIQUILPAN Apuntes de Fundamentos de Desarrollo de Sistemas Ingeniera en Sistemas Computacionales Plan 2004
Especificacin de servicios, durante la cual describimos con precisin cada interfaz de clase. Seleccin de componentes, durante la cual identificamos componentes hechos y objetos de solucin adicionales. Reestructuracin del modelo de objetos, durante la cual transformamos el modelo de diseo de objetos para mejorar su comprensibilidad y extensibilidad. Optimizacin del modelo de objetos, durante la cual transformamos el modelo de diseo de objetos para tratar criterios de desempeo, como el tiempo de respuesta o la utilizacin de la memoria. El diseo de objetos, al igual que el diseo del Sistema, no es algortmico. El diseo de objetos a veces es difcil distinguir claramente el anlisis y el diseo Orientado a Objetos (OO). Esencialmente AOO es una actividad de clasificacin, se analiza un problema con el fin de determinar clases de objetos que sea aplicables en el desarrollo de la solucin. El de DOO permite al ing. de SW los objetos que se derivan de cada clase de las interrelaciones entre ellos y proporciona una notificacin que refleja las relaciones entre los objetos.
Elaborados por:
Pg. 70
INSTITUTO TECNOLGICO DE JIQUILPAN Apuntes de Fundamentos de Desarrollo de Sistemas Ingeniera en Sistemas Computacionales Plan 2004
UNIDAD IV MODELOS DE PROCESO DE SOFTWARE: Introduccin: Los estndares 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 explotacin. Sin embargo, ninguno impone un modelo de procesos concreto (modelo de ciclo de vida) ni cmo realizar las diferentes actividades incluidas en cada proceso, por lo que cada empresa deber utilizar los mtodos, tcnicas y herramientas que considere oportuno. Por su naturaleza, los modelos son simplificaciones; por lo tanto, un modelo de procesos del Software es una simplificacin o abstraccin de un proceso real. Podemos definir un modelo de procesos del Software como una representacin abstracta de alto nivel de un proceso Software. Cada modelo es una descripcin de un proceso Software que se presenta desde una perspectiva particular. Alternativamente, a veces se usan los trminos Ciclo de Vida y Modelo de Ciclo de Vida. Cada modelo describe una sucesin de fases y un encadenamiento entre ellas. Segn las fases y el modo en que se produzca este encadenamiento, tenemos diferentes modelos de proceso. Un modelo es ms adecuado que otro para desarrollar un proyecto dependiendo de un conjunto de caractersticas de ste. Existe una gran variedad de modelos diferentes entre los que tenemos los que se describen a continuacin.
4.1 Modelo de Cascada: Este enfoque metodolgico que ordena rigurosamente las etapas del ciclo de vida del Software, de forma tal que el inicio de cada etapa debe esperar a la finalizacin de la inmediatamente anterior. La palabra cascada sugiere, mediante la metfora de la fuerza de la gravedad, el esfuerzo necesario para introducir un cambio en las fases ms avanzadas de un proyecto. Modelo en Cascada: El ms conocido, est basado en el ciclo convencional de una ingeniera, el paradigma del ciclo de vida abarca las siguientes actividades:
Elaborados por: Lic. Martin Valencia Pg. 71
INSTITUTO TECNOLGICO DE JIQUILPAN Apuntes de Fundamentos de Desarrollo de Sistemas Ingeniera en Sistemas Computacionales Plan 2004
Ingeniera y Anlisis del Sistema Anlisis de los Requisitos Diseo Codificacin Prueba Mantenimiento
1.- Ingeniera y Anlisis del Sistema. Debido a que el Software es siempre parte de un Sistema mayor, el trabajo comienza estableciendo los requisitos de todos los elementos del Sistema y luego asignando algn subconjunto de estos requisitos al Software. 2.- Anlisis de Sistemas de Computacin. Se lleva a cabo teniendo en cuenta ciertos principios: - Debe presentarse y entenderse el dominio de la informacin de un problema. - Defina las funciones que debe realizar el Software. - Represente el comportamiento del Software a consecuencias de acontecimientos externos. - Divida en forma jerrquica los modelos que representan la informacin, funciones y comportamiento. Se analizan las necesidades de los usuarios finales del Software para determinar qu objetivos debe cubrir. 3.- Diseo. Traduce los requisitos en una representacin del Software con la calidad requerida antes de que comience la codificacin. - Diseo del Sistema: Se descompone y organiza el Sistema en elementos que puedan elaborarse por separado, aprovechando las ventajas del desarrollo en equipo, as como la manera en que se combinan unos con otros. - Diseo del Programa: Es la fase en donde se realizan los algoritmos necesarios para el cumplimiento de los requerimientos del usuario as como tambin los anlisis necesarios para saber que herramientas usar en la etapa de Codificacin. 4.- Codificacin El diseo debe traducirse en una forma legible para la mquina. Se implementa el cdigo fuente. Dependiendo del lenguaje de programacin y su versin se crean las libreras y componentes reutilizables dentro del mismo proyecto para hacer que la programacin sea un proceso mucha ms rpido. 5.- Prueba.
Elaborados por:
Pg. 72
INSTITUTO TECNOLGICO DE JIQUILPAN Apuntes de Fundamentos de Desarrollo de Sistemas Ingeniera en Sistemas Computacionales Plan 2004
Los elementos, ya programados, se ensamblan para componer el Sistema y se comprueba que funciona correctamente antes de ser puesto en explotacin. Las pruebas de Software, testing o beta testing es un proceso usado para identificar posibles fallos. En general, los usuarios distinguen entre errores de programacin (o bugs) y defectos de forma. En un defecto de forma, el programa no realiza lo que el usuario espera. Por el contrario, un error de programacin puede describirse como un fallo en la semntica de un programa de ordenador. A la versin del producto de pruebas y que es anterior a la versin final (o master) se denomina beta, y a dicha fase de pruebas, beta testing. Finalmente y antes de salir al mercado, es cada vez ms habitual que se realice una fase de RTM testing ( Release To Market ), dnde se comprueba cada funcionalidad del programa completo en entornos de produccin. 6.- Implementacin. El Software obtenido se pone en produccin. Se implantan los niveles Software y Hardware que componen el proyecto. La implantacin es la fase con ms duracin y con ms cambios en el ciclo de elaboracin de un proyecto. Es una de las fases finales del proyecto. Durante la explotacin del Sistema Software pueden surgir cambios, bien para corregir errores o bien para introducir mejorar. Todo ello recoge en los Documentos de Cambios. 7.- Mantenimiento. El Software sufrir cambios despus de que se entrega al cliente. Los cambios ocurrirn debidos a que hayan encontrado errores, a que el Software deba adaptarse a cambios del entorno externo (Sistema operativo o dispositivos perifricos), o debido a que el cliente requiera ampliaciones funcionales o del rendimiento. Ventajas: Se tiene todo bien organizado y no se mezclan las fases. Es perfecto para proyectos que son rgidos. Ideal para proyectos donde se especifiquen muy bien los requerimientos. Ideal para proyectos en que se conozca muy bien la herramienta a utilizar. Sumamente sencillo ya que sigue los pasos intuitivos necesarios a la hora de desarrollar el Software.
Desventajas: - Difcilmente un cliente va a establecer al principio todos los requerimientos necesarios, por lo que provoca un gran atraso trabajando en este modelo, ya que este es muy restrictivo y no permite movilizarse entre fases. Los resultados y/o mejoras no son visibles, el producto se ve recin cuando este est finalizado.
4.2 Modelo de Espiral: El Desarrollo en Espiral es un modelo de ciclo de vida desarrollado por Barry Boehm en 1985, utilizado generalmente en la Ingeniera de Software. Las actividades de este modelo son una espiral, cada bucle es una actividad.
Elaborados por: Lic. Martin Valencia Pg. 73
INSTITUTO TECNOLGICO DE JIQUILPAN Apuntes de Fundamentos de Desarrollo de Sistemas Ingeniera en Sistemas Computacionales Plan 2004
Para cada actividad habr cuatro tareas: 1.- Planificacin: Determinacin de objetivos, alternativas y restricciones. Revisamos todo lo hecho, evalundolo, y con ello decidimos si continuamos con las fases siguientes y planificamos la prxima actividad. 2.- Anlisis de riesgo: Anlisis de alternativas e identificacin/resolucin de riesgos. 3.- Ingeniera: Desarrollo del producto del siguiente nivel Tareas de la actividad propia y se prueba. Anlisis de alternativas e identificacin resolucin de riesgos. 4.- Evaluacin del cliente: Valorizacin de los resultados de la ingeniera. Ventajas: El anlisis del riesgo se hace de forma explcita 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. Adems es posible tener en cuenta mejoras y nuevos requerimientos sin romper con la metodologa, ya que este ciclo de vida no es rgido ni esttico.
Desventajas: Genera mucho tiempo en el desarrollo del Sistema. Modelo costoso. Requiere experiencia en la identificacin de riesgos.
Conclusin: El paradigma del modelo en espiral para la ingeniera de Software es actualmente el enfoque ms realista para el desarrollo de Software y de Sistemas a gran escala. Utiliza un enfoque evolutivo para la ingeniera de Software, permitiendo al desarrollador y al cliente entender y reaccionar a los riesgos en cada nivel evolutivo. Utiliza la creacin de prototipos como un mecanismo de reduccin de riesgo, pero, lo que es
Elaborados por: Lic. Martin Valencia Pg. 74
INSTITUTO TECNOLGICO DE JIQUILPAN Apuntes de Fundamentos de Desarrollo de Sistemas Ingeniera en Sistemas Computacionales Plan 2004
ms importante permite a quien lo desarrolla aplicar el enfoque de creacin de prototipos en cualquier etapa de la evolucin de prototipos. 4.3 Modelo Incremental: El Modelo Incremental combina elementos del MLS con la filosofa interactiva de construccin de prototipos. En una visin genrica, el proceso se divide en 4 partes: Anlisis, Diseo, Cdigo y Prueba. Sin embargo, para la produccin del Software, se usa el principio de trabajo en cadena o Pipeline, utilizado en muchas otras formas de programacin. 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 mtodos 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 dotacin de personal suficiente. Los primeros pasos los pueden realizar un grupo reducido de personas y en cada incremento se aadir personal, de ser necesario. Por otro lado los incrementos se pueden planear para gestionar riesgos tcnicos. 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 ms. Difcil de evaluar el coste total. Difcil 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 comn en el desarrollo de programas para el intrprete de comandos, ya que se pueden concatenar comandos fcilmente con tuberas (pipe). Tambin es una arquitectura muy natural en el paradigma de programacin funcional, ya que equivale a la composicin de funciones matemticas.
Elaborados por:
Pg. 75
INSTITUTO TECNOLGICO DE JIQUILPAN Apuntes de Fundamentos de Desarrollo de Sistemas Ingeniera en Sistemas Computacionales Plan 2004
Interprete de comandos. Parte fundamental de un Sistema Operativo que ordena la ejecucin de mandatos obtenidos del usuario por medio de una interfaz alfanumrica. Caractersticas. Se evitan proyectos largos y se entrega algo de valor a los usuarios con cierta frecuencia. El usuario se involucre ms. Difcil de evaluar el costo total. Difcil 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. Tambin 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 slo al mbito de cada incremento. Permite entregar al cliente un producto ms rpido en comparacin del modelo de cascada. Resulta ms sencillo acomodar cambios al acotar el tamao de los incrementos. Por su versatilidad requiere de una planeacin cuidadosa tanto a nivel administrativo como tcnico.
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 planeacin, tanto administrativa como tcnica. Requiere de metas claras para conocer el estado del proyecto.
Conclusin: 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 algn modo. El modelo permite una implementacin con refinamientos sucesivos (ampliacin y/o mejora). Con cada incremento se agrega nueva funcionalidad o se cubren nuevos requisitos o bien se mejora la versin previamente implementada del producto de Software. 4.4Proceso de Desarrollo Unificado:
Elaborados por: Lic. Martin Valencia Pg. 76
INSTITUTO TECNOLGICO DE JIQUILPAN Apuntes de Fundamentos de Desarrollo de Sistemas Ingeniera 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 ms conocido y documentado del Proceso Unificado es el Rational Unific Process o simplemente RUP. El Proceso Unificado no es simplemente un proceso, sino un marco de trabajo extensible que puede ser adaptado a organizaciones o proyectos especficos. De la misma forma, el RUP tambin es un marco de trabajo extensible, por lo que muchas veces resulta imposible decir si un refinamiento particular del proceso ha sido derivado del Proceso Unificado o del RUP. Por dicho motivo, los dos nombres suelen utilizarse para referirse a un mismo concepto. El nombre Proceso Unificado se usa para describir el proceso genrico que incluye aquellos elementos que son comunes a la mayora de los refinamientos existentes. Tambin 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 primer libro sobre el tema se denomin, en su versin espaola, El Proceso Unificado de Desarrollo de Software (ISBN 8478290362) y fue publicado en 1999 por Ivan Jacobson, Grady Booch y James Rumbaugh, conocidos tambin por ser los desarrolladores del UML, el Lenguaje Unificado de Modelado. Desde entonces los autores que publican libros sobre el tema y que no estn afiliados a Rational utilizan el trmino Proceso Unificado, mientras que los autores que pertenecen a Rational favorecen el nombre de Rational Unific Process RUP. Caractersticas: - Iterativo e Incremental El Proceso Unificado es un marco de desarrollo iterativo e incremental compuesto de cuatro fases denominadas Inicio, Elaboracin, Construccin y Transicin. Cada una de estas fases es a su vez dividida en una serie de iteraciones (la de inicio slo consta de varias iteraciones en proyectos grandes). Estas iteraciones ofrecen como resultado un incremento del producto desarrollado que aade o mejora las funcionalidades del Sistema en desarrollo. Cada una de estas iteraciones se divide a su vez en una serie de disciplinas que recuerdan a las definidas en el ciclo de vida clsico o en cascada: Anlisis de requisitos, Diseo, Implementacin y Prueba. Aunque todas las iteraciones suelen incluir trabajo en casi todas las disciplinas, el grado de esfuerzo dentro de cada una de ellas vara a lo largo del proyecto. - Dirigido por los casos de uso En el Proceso Unificado los casos de uso se utilizan para capturar los requisitos funcionales y para definir los contenidos de las iteraciones. La idea es que cada iteracin tome un conjunto de casos de uso o escenarios y desarrolle todo el camino a travs de las distintas disciplinas: diseo, implementacin, prueba, etc. el proceso dirigido por casos de uso es el RUP. Nota: en UP se est dirigido por requisitos y riesgos de acuerdo con el libro UML 2 de ARLOW.
- Centrado en la arquitectura El Proceso Unificado asume que no existe un modelo nico que cubra todos los aspectos del Sistema. Por dicho motivo existen mltiples modelos y vistas que definen la arquitectura de Software de un Sistema. La
Elaborados por: Lic. Martin Valencia Pg. 77
INSTITUTO TECNOLGICO DE JIQUILPAN Apuntes de Fundamentos de Desarrollo de Sistemas Ingeniera en Sistemas Computacionales Plan 2004
analoga con la construccin es clara, cuando construyes un edificio existen diversos planos que incluyen los distintos servicios del mismo: electricidad, fontanera, etc. - Enfocado en los riesgos El Proceso Unificado requiere que el equipo del proyecto se centre en identificar los riesgos crticos en una etapa temprana del ciclo de vida. Los resultados de cada iteracin, en especial los de la fase de Elaboracin, deben ser seleccionados en un orden que asegure que los riesgos principales son considerados primero.
4.5 Proceso Software Personal: El Proceso Personal de Software es una versin pequea de CMM donde se preocupa solo por un conjunto de las KPAs. Fue propuesto por Watts Humphrey en 1995 y estaba dirigido a estudiantes. A partir de 1997 con el lanzamiento del libro An introduction to the Personal Software Process se dirige ahora a ingenieros principiantes. El PSP se caracteriza porque es de uso personal y se aplica a programas pequeos de menos de 10.000 lneas de cdigo. Se centra en la administracin del tiempo y en la administracin de la calidad a travs de la eliminacin temprana de defectos. En el PSP se excluyen los siguientes temas: Trabajo en equipo, Administracin de configuraciones y Administracin de requerimientos. El PSP se orienta el conjunto de reas clave del proceso que debe manejar un desarrollador cuando trabaja de forma individual. Los siguientes son los niveles y las KPAs que se manejan en cada uno: Nivel 1 - Inicial: - Seguimiento y control de proyectos - Planeacin de los proyectos Nivel 2 - Repetible: - Revisin entre colegas. - Ingeniera del producto de Software. - Manejo integrado del Software. - Definicin del proceso de Software. - Foco del proceso de Software. Nivel 3 - Definido: - Control de calidad. - Administracin cuantitativa del proyecto.
Elaborados por: Lic. Martin Valencia Pg. 78
INSTITUTO TECNOLGICO DE JIQUILPAN Apuntes de Fundamentos de Desarrollo de Sistemas Ingeniera en Sistemas Computacionales Plan 2004
Nivel 4 - Controlado: - Administracin de los cambios del proceso. - Administracin del cambio tecnolgico. - Prevencin de defectos. - El PSP tiene varias fases: PSP0: Proceso Base. PSP0.1: Complementos al proceso base. PSP1 y PSP1.1: Planeacin personal. PSP2 y PSP2.1: Control de calidad personal. PSP3: Programas ms grandes. El Proceso Personal Software, conocido por sus siglas como PSP, es una metodologa de reciente creacin, proveniente del Instituto de Ingeniera del Software (SEI). PSP es una alternativa dirigida a los ingenieros de Sistemas, que les permite mejorar la forma en la que construyen Software. Considerando aspectos como la planeacin, calidad, estimacin de costos y productividad, PSP es una metodologa 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 relacin entre las habilidades de los ingenieros de Software y la calidad de los productos que desarrollan, las actividades establecidas en PSP estn orientadas al conocimiento, administracin y mejora de sus habilidades al construir programas. En PSP todas las tareas y actividades que el ingeniero de Software debe realizar durante el proceso de desarrollo de un producto de Software, estn puntualmente definidas en un conjunto de documentos conocidos como scripts. Los scripts son el punto medular de PSP, por lo que se hace mucho nfasis en que deben ser seguidos en forma disciplinada, ya que de ello depender el xito de la mejora que se busca. Gran parte de las tareas y actividades definidas en los scripts generar en su realizacin un conjunto de datos, fundamentalmente de carcter estadstico. La aplicacin de PSP en varios procesos de desarrollo, y el anlisis de la informacin estadstica generada en cada uno de stos, permitirn al Ingeniero de Software identificar, tanto sus fortalezas como sus debilidades, y crecer a travs de un proceso de autoaprendizaje y auto-mejora. Los scripts se organizan en cuatro niveles, identificados del 0 al 3, atendindose en cada nivel un conjunto de aspectos a mejorar del Proceso de Desarrollo de Software. Al primer nivel se le conoce como 0 o de medicin personal, al segundo como nivel 1 o de planeacin personal, al tercero, como nivel 2 o de calidad personal, y al cuarto, como nivel 3 o cclico personal. Cada uno de estos niveles, con excepcin del 3, tiene una versin que los extiende, introduciendo tareas y actividades para un mejor manejo de los aspectos de inters en nivel, o bien para incluir nuevos aspectos.
Elaborados por:
Pg. 79
INSTITUTO TECNOLGICO DE JIQUILPAN Apuntes de Fundamentos de Desarrollo de Sistemas Ingeniera en Sistemas Computacionales Plan 2004
UNIDAD V: TECNICAS, HERRAMIENTAS Y ESTUDIOS PREVIOS. Introduccin. Ingeniera de Software es la disciplina o rea de la informtica que ofrece mtodos y tcnicas para desarrollar y mantener Software de calidad. Esta ingeniera trata con reas muy diversas de la informtica y de las ciencias de la computacin, tales como construccin de compiladores, Sistemas operativos, o desarrollos Intranet/Internet, abordando todas las fases del ciclo de vida del desarrollo de cualquier tipo de Sistemas de informacin y aplicables a infinidad de reas (negocios, investigacin cientfica, medicina, produccin, logstica, banca, control de trfico, meteorologa, derecho, Internet, Intranet, etc.) Una definicin precisa an no ha sido contemplada en los diccionarios, sin embargo se pueden citar las enunciadas por algunos de los ms prestigiosos autores:
Elaborados por: Lic. Martin Valencia Pg. 80
INSTITUTO TECNOLGICO DE JIQUILPAN Apuntes de Fundamentos de Desarrollo de Sistemas Ingeniera en Sistemas Computacionales Plan 2004
Ingeniera de Software es el estudio de los principios y metodologas para el desarrollo y mantenimiento de Sistemas Software (Zelkovitz, 1978). Ingeniera de Software es la aplicacin prctica del conocimiento cientfico al diseo y construccin de programas de computadora y a la documentacin asociada requerida para desarrollar, operar y mantenerlos. Se conoce tambin como Desarrollo de Software o Produccin de Software (Bohem, 1976). Ingeniera de Software trata del establecimiento de los principios y mtodos de la ingeniera a fin de obtener Software de modo rentable, que sea fiable y trabaje en mquinas reales (Bauer, 1972). Es la aplicacin de un enfoque sistemtico, disciplinado y cuantificable al desarrollo, operacin y mantenimiento del Software; es decir, la aplicacin de la ingeniera al Software (IEEE, 1993). En el 2004, en los Estados Unidos, la Oficina de Estadsticas del Trabajo (U. S. Bureau of Labor Statistics) cont 760.840 ingenieros de Software de computadora. [1] El trmino Ingeniero de Software, sin embargo, se utiliza en forma genrica en el ambiente empresarial, y no todos los ingenieros de Software poseen realmente ttulos de Ingeniera de universidades reconocidas. Algunos autores consideran que Desarrollo de Software es un trmino ms apropiado que Ingeniera de Software (IS) para el proceso de crear Software. Personas como Pete McBreen (Autor de Software Craftmanship) cree que el trmino IS implica niveles de rigor y prueba de procesos que no son apropiados para todo tipo de Desarrollo de Software. Indistintamente se utilizan los trminos Ingeniera de Software o Ingeniera del Software. En Hispanoamrica el trmino usado normalmente es el primero de ellos. Etapas del proceso La ingeniera de Software requiere llevar a cabo numerosas tareas, dentro de etapas como las siguientes: - Anlisis de requisitos: Extraer los requisitos de un producto de Software es la primera etapa para crearlo. Mientras que los clientes piensan que ellos saben lo que el Software tiene que hacer, se requiere de habilidad y experiencia en la ingeniera de Software para reconocer requisitos incompletos, ambiguos o contradictorios. El resultado del anlisis de requisitos con el cliente se plasma en el documento ERS, Especificacin de Requerimientos del Sistema, cuya estructura puede venir definida por varios estndares, tales como CMM-I. Asimismo, se define un diagrama de Entidad/Relacin, en el que se plasman las principales entidades que participarn en el Desarrollo del Software. La captura, anlisis y especificacin de requisitos (incluso pruebas de ellos), es una parte crucial; de esta etapa depende en gran medida el logro de los objetivos finales. Se han ideado modelos y diversos procesos de trabajo para estos fines. Aunque an no est formalizada, ya se habla de la Ingeniera de Requisitos. La IEEE Std. 8301998 normaliza la creacin de las Especificaciones de Requisitos Software (Software Requirements Specification). - Especificacin:
Elaborados por: Lic. Martin Valencia Pg. 81
INSTITUTO TECNOLGICO DE JIQUILPAN Apuntes de Fundamentos de Desarrollo de Sistemas Ingeniera en Sistemas Computacionales Plan 2004
Es la tarea de describir detalladamente el Software a ser escrito, en una forma matemticamente rigurosa. En la realidad, la mayora de las buenas especificaciones han sido escritas para entender y afinar aplicaciones que ya estaban desarrolladas. Las especificaciones son ms importantes para las interfaces externas, que deben permanecer estables. - Diseo y arquitectura: Se refiere a determinar cmo funcionar de forma general sin entrar en detalles. Consiste en incorporar consideraciones de la implementacin tecnolgica, como el Hardware, la red, etc. Se definen los Casos de Uso para cubrir las funciones que realizar el Sistema, y se transforman las entidades definidas en el anlisis de requisitos en clases de diseo, obteniendo un modelo cercano a la programacin orientada a objetos. - Programacin: Reducir un diseo a cdigo puede ser la parte ms obvia del trabajo de ingeniera de Software, pero no necesariamente es la que demanda mayor trabajo y ni la ms complicada. La complejidad y la duracin de esta etapa est ntimamente relacionada al o a los lenguajes de programacin utilizados, as como al diseo previamente realizado. - Prueba: Consiste en comprobar que el Software realice correctamente las tareas indicadas en la especificacin del problema. Una tcnica de prueba es probar por separado cada mdulo del Software, y luego probarlo de forma integral, para as llegar al objetivo. Se considera una buena prctica el que las pruebas sean efectuadas por alguien distinto al desarrollador que la program, idealmente un rea de pruebas; sin perjuicio de lo anterior el programador debe hacer sus propias pruebas. En general hay dos grandes formas de organizar un rea de pruebas, la primera es que est compuesta por personal inexperto y que desconozca el tema de pruebas, de esta forma se evala que la documentacin entregada sea de calidad, que los procesos descritos son tan claros que cualquiera puede entenderlos y el Software hace las cosas tal y como estn descritas. El segundo enfoque es tener un rea de pruebas conformada por programadores con experiencia, personas que saben sin mayores indicaciones en qu condiciones puede fallar una aplicacin y que pueden poner atencin en detalles que personal inexperto no considerara. - Documentacin: Todo lo concerniente a la documentacin del propio Desarrollo del Software y de la gestin del proyecto, pasando por modelaciones (UML), diagramas, pruebas, manuales de usuario, manuales tcnicos, etc; todo con el propsito de eventuales correcciones, usabilidad, mantenimiento futuro y ampliaciones al Sistema. - Mantenimiento: Mantener y mejorar el Software para enfrentar errores descubiertos y nuevos requisitos. Esto puede llevar ms tiempo incluso que el desarrollo inicial del Software. Alrededor de 2/3 de toda la ingeniera de Software tiene que ver con dar mantenimiento. Una pequea parte de este trabajo consiste en arreglar errores, o bugs. La mayor parte consiste en extender el Sistema para hacer nuevas cosas. De manera similar, alrededor de 2/3 de toda la ingeniera civil, arquitectura y trabajo de construccin es dar mantenimiento.
Elaborados por: Lic. Martin Valencia Pg. 82
INSTITUTO TECNOLGICO DE JIQUILPAN Apuntes de Fundamentos de Desarrollo de Sistemas Ingeniera en Sistemas Computacionales Plan 2004
- Modelos de desarrollo de Software: La ingeniera de Software tiene varios modelos o paradigmas de desarrollo en los cuales se puede apoyar para la realizacin de Software, de los cuales podemos destacar a stos por ser los ms utilizados y los ms completos: Modelo en cascada o Clsico (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).
Tambin es necesario mencionar que sumado a todos estos conceptos tan necesarios para complementar un Proyecto de Desarrollo de Software, es necesaria la documentacin y referencias escritas que el Analista requiere as como el Diseador de las interfaces finales, en las cuales se centrar el usuario final, adems de que es indispensable determinar cmo se va a presentar el proyecto, cules sern las reas del conocimiento que debe reforzar, cuanta informacin ser necesaria para el usuario final, etc.
5.1 Tcnicas de Recopilacin de Informacin: Los analistas utilizan una variable de mtodos a fin de recopilar los datos sobre una situacin existente, como entrevistas, cuestionario, inspeccin de registros y observacin. Cada uno tiene ventajas y desventajas. Generalmente, se utilizan dos o tres para complementar el trabajo de cada una y ayudar a asegurar una investigacin completa. A continuacin se vern cada una de ellas. 5.1.1 Entrevista: Antes de entrevistar a alguien ms, tenemos que entrevistarnos a nosotros mismos. Necesitamos conocer nuestros prejuicios y cmo afectarn stos nuestras percepciones. Se necesitan pensar detenidamente las entrevistas antes de hacerlas. Asimismo, debemos pensar cmo lograremos que la entrevista sea satisfactoria para el individuo al que entrevistemos. Una entrevista es una conversacin dirigida con un propsito especfico que utiliza un formato de preguntas y respuestas. En la entrevista necesitamos obtener las opciones de los entrevistados y su parecer acerca del estado actual del sistema, metas organizacionales y personales y procedimientos informales. Adems se debe tratar de captar los sentimientos de los entrevistados, y con ello, poder entender la cultura de la organizacin de una manera ms compleja. Se debe de tratar de averiguar lo ms que se pueda acerca de las metas de la organizacin por medio de las entrevistas; y dentro de ella, nosotros debemos de establecer un ambiente de confianza y de entendimiento rpidamente, pero al mismo tiempo, llevar el control de la entrevista. Las entrevistas se utilizan para recabar informacin en forma verbal, a travs de preguntas que propone el analista. Quienes responde pueden ser gerentes o empleados, los cuales son usuarios actuales del Sistema,
Elaborados por: Lic. Martin Valencia Pg. 83
INSTITUTO TECNOLGICO DE JIQUILPAN Apuntes de Fundamentos de Desarrollo de Sistemas Ingeniera en Sistemas Computacionales Plan 2004
existen usuarios potenciales del Sistema propuesto o aquellos que proporcionaran datos o sern afectadas por la aplicacin propuesta. El analista puede entrevistar al personal en forma individual o en grupos. La entrevista es una conversacin dirigida que usa un formato de preguntas y respuestas. En la entrevista se quiere obtener la opinin del entrevistado y sus sentimientos acerca del estado actual del Sistema. Leer los antecedentes: El propsito es crear un vocabulario comn que en un futuro le permita expresar preguntas de la entrevista de una manera comprensible para su entrevistado. Establecer los objetivos de la entrevista: Debe de haber reas claves referentes al procesamiento de la informacin y al comportamiento relacionado con la toma de decisiones acerca de las cuales tendremos que hacer preguntas. Decidir a quin entrevistar: Se debe incluir a la gente clave en todos niveles que vayan a ser afectadas por el sistema de alguna manera. Preparar al entrevistado: Se realiza hablndole por anticipado o envindole un mensaje por correo electrnico. Si las entrevistas tienen una larga duracin, es posible que los entrevistados se enfaden, pero lo pueden ocultar. 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. La estructura de las preguntas deben de ser como una pirmide (empezar con preguntas a menudo cerradas, y continuar con preguntas abiertas y ms generalizadas), una estructura de embudo o una estructura de diamante (iniciar con preguntas generales y abiertas, y concluir limitando las respuestas con preguntas cerradas).
PLANEACION PARA LA ENTREVISTA Hay cinco pasos principales para la preparacin de la entrevista: LECTURA DE MATERIAL DE FONDO: Esto es leer y comprender la informacin acerca del entrevistado. Su ventaja es construir un vocabulario comn, para redactar las preguntas de la entrevista de forma que sea comprensible para el entrevistado. ESTABLECIMIENTO DE LOS OBJETIVOS DE LA ENTREVISTA: Requiere usar la informacin que se recopil, 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. PREPARAR AL ENTREVISTADO: Esto es preparar a la persona a ser entrevistada, llamndole con anticipacin y permitiendo que el entrevistado tenga tiempo para pensar acerca de la entrevista. Las entrevistas deben durar de 45 minutos a una hora, a lo mucho. 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.
Los dos tipos bsicos de preguntas son: 1._ Abiertas. 2._ Cerradas.
Elaborados por: Lic. Martin Valencia Pg. 84
INSTITUTO TECNOLGICO DE JIQUILPAN Apuntes de Fundamentos de Desarrollo de Sistemas Ingeniera en Sistemas Computacionales Plan 2004
Cada tipo de pregunta puede lograr algo diferente y cada una tiene sus beneficios y desventajas. Recabar datos mediante la entrevista. La entrevista es una forma de conversacin, no interrogacin! Al analizar las caractersticas de los Sistemas con personal seleccionado cuidadosamente por sus conocimientos sobre el Sistema los analistas pueden conocer los datos que no estn disponibles en ninguna otra forma. En las investigaciones de Sistemas, las formas cualitativas y cuantitativas de la informacin son importantes. La informacin cualitativa est relacionada con opiniones, polticas y descripciones cuantitativas tratan con nmeros, frecuencia o cantidades. A menudo las entrevistas dan la mejor fuente de informacin cualitativa; los otros mtodos tienden a ser ms tiles en la recoleccin de datos cuantitativos. Mucha gente incapaz de expresarse por escrito puede discutir sus ideas en forma verbal. Como resultado de esto las entrevistas pueden descubrir rpidamente malos entendidos, falsas expectativas o incluso resistencia potencial para las aplicaciones en desarrollo; ms an a menudo es ms fcil calendarizar una entrevista con los gerentes del alto nivel, que pedirles que llenen cuestionarios. Determinacin del tipo de entrevista. La estructura de las entrevistas vara. Si el objetivo de la entrevista radica en adquirir informacin general, es conveniente elaborar una serie de preguntas sin estructura, con una seccin de preguntas y respuestas libres. La atmsfera abierta y de fcil flujo de esta modalidad proporciona una mayor oportunidad para conocer las actitudes, ideas y creencias de quien responde. Sin embargo, cuando los analistas necesitan adquirir datos ms especficos sobre la aplicacin o desean asegurar una alta confiabilidad en las respuestas a las preguntas que han propuesto a sus entrevistados, las entrevistas estructuradas son mejores. Las entrevistas estructuradas utilizan preguntas estandarizadas. El formato de respuestas para las preguntas puede ser abierto o cerrado; las preguntas para respuesta abierta permiten a los entrevistados dar cualquier respuesta que parezca apropiada. Con las preguntas para respuestas cerradas se proporciona al usuario un conjunto de respuestas que se pueda seleccionar. Todas las personas que responden se basan en un mismo conjunto de posibles respuestas. La confiabilidad es solo una consideracin en la seleccin del mtodo de entrevista. Los analistas tambin deben dividir su tiempo entre desarrollar preguntas para entrevistas y analizar las respuestas. Las entrevistas no estructuradas requieren menos tiempo de preparacin, porque no se necesita tener por anticipado las palabras precisas de las preguntas. Sin embargo, analizar las respuestas despus de las entrevistas lleva ms tiempo que con las entrevistas estructuradas. De cualquier manera, el mayor costo radica en la preparacin, administracin y anlisis de las entrevistas estructuradas para preguntas cerradas. Dado que un nmero de personas se seleccionara para la entrevista, los analistas deben tener cuidado de incluir aquellas personas que tienen informacin que no se podr conseguir de otra forma. Durante las primeras etapas de un estudio de Sistemas, cuando los analistas determinan La factibilidad del proyecto, con frecuencia las entrevistas solo se aplican a la gerencia o personal de supervisin. Sin embargo, durante la investigacin detallada en donde el objetivo es descubrir hechos especficos, opiniones y conocer cmo se manejan las operaciones desempeadas actualmente, las entrevistas se aplican en todos los niveles gerenciales y de empleados y dependen de quien pueda proporcionar la mayor parte de la informacin til para el estudio. As, los analistas que estudian a la
Elaborados por: Lic. Martin Valencia Pg. 85
INSTITUTO TECNOLGICO DE JIQUILPAN Apuntes de Fundamentos de Desarrollo de Sistemas Ingeniera en Sistemas Computacionales Plan 2004
administracin de inventarios pueden entrevistar a los trabajadores del embarque y de recepcin, al personal del almacn y a los supervisores de los diferentes turnos, es decir, aquellas personas que realmente trabajan en el almacn; tambin entrevistaran a los agentes ms importantes. Realizacin de la entrevista. La habilidad del entrevistador es vital para el xito en la bsqueda de hechos por medio de la entrevista. Las buenas entrevistas dependen del conocimiento del analista tanto de la preparacin del objetivo de una entrevista especfica como de las preguntas por realizar a una persona determinada. El tacto, la imparcialidad e incluso la vestimenta apropiada ayudan a asegurar una entrevista exitosa. La falta de estos factores puede reducir cualquier oportunidad de xito. Por ejemplo, un analista que trabaja en la aplicacin enfocada a la reduccin de errores probablemente no tendra xito si llegar a una oficina de gerencia de nivel medio con la presentacin equivocada, por ejemplo, si dijera, hola, fui enviado para encontrar una forma de mojar el rendimiento y de reducir los errores que presentan aqu. O la introduccin: Estamos aqu para resolver su problema, es igualmente mala. Es imaginable la rapidez con la que va a responder ser irrita y se molesta con un enfoque de este tipo. A travs de la entrevista, 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 informacin contra estas preguntas, los analistas tendrn ms conocimientos no solamente de la informacin adquirida sino tambin de su importancia.
5.1.2 Cuestionario. Los cuestionarios proporcionan una alternativa muy til para las entrevistas; sin embargo, existen ciertas caractersticas que pueden ser apropiadas en algunas situaciones e inapropiadas en otras. Recoleccin de datos mediante cuestionarios. Para los analistas los cuestionarios pueden ser la nica forma posible de relacionarse con un gran nmero de personas para conocer varios aspectos del Sistema. Cuando se llevan a cabo largos estudios en varios departamentos, se puede distribuir los cuestionarios a todas las personas apropiadas para recabar hechos con relacin al Sistema. Por supuesto, no es posible observar las expresiones o relaciones de quienes responden a los cuestionarios. Tambin las preguntas estandarizadas pueden proporcionar datos ms confiables. Por otra parte, las caractersticas anteriores tambin son desventajas de los cuestionarios. Aunque su aplicacin puede realizarse con un mayor nmero de individuos, es muy rara una respuesta total. Puede necesitarse algn seguimiento de los cuestionarios para motivar al personal que responda; todas las respuestas se encontraran en una proporcin entre el 25 o 35%, que es lo ms comn. Seleccin de formas para cuestionarios.
Elaborados por: Lic. Martin Valencia Pg. 86
INSTITUTO TECNOLGICO DE JIQUILPAN Apuntes de Fundamentos de Desarrollo de Sistemas Ingeniera en Sistemas Computacionales Plan 2004
El desarrollo y distribucin de los cuestionarios es caro; por lo tanto, el tiempo invertido en esto debe utilizarse en una forma inteligente. Tambin es importante el formato y contenido de las preguntas en la recopilacin de hechos significativos. Existen dos formas de cuestionarios para recabar datos; cuestionario abierto y cerrados, y se aplican dependiendo de si los analistas conocen de antemano todas las posibles respuestas de las preguntas y pueden incluirlos. Con frecuencia se utilizan ambas formas en los estudios de Sistemas. Cuestionarios abiertos. Al igual, que las entrevistas, los cuestionarios pueden ser abiertos y se aplican cuando se quieren conocer los sentimientos, opiniones y experiencias generales; tambin son tiles al explorar el problema bsico, por ejemplo, un analista que utiliza cuestionarios para estudiar los mtodos de verificacin de crdito, en un medio ambiente de ventas al a menudeo, podra recabar ms informacin provechosa de una pregunta abierta de este tipo: Cmo podra simplificarse y mejorarse el proceso de verificacin de crdito para los clientes? Cuestionarios cerrados. El cuestionario cerrado limita las respuestas posibles del interrogado. Por medio de un cuidadoso estilo en la pregunta, el analista puede controlar el marco de referencia. Este formato es el mejor mtodo para obtener informacin sobre los hechos. Tambin fuerza a los individuos para que tomen una posicin y forma de opinin sobre los aspectos importantes. Etapas en el desarrollo de un cuestionario. Los cuestionarios bien hechos no se desarrollan rpidamente, llevan tiempo y mucho trabajo. La primera consideracin se encuentra en determinar el objetivo del cuestionario. Qu datos quiere conocer el analista a travs de su uso? El analista define como utilizar los cuestionarios a fin de obtener los hechos al considerar la estructura ms til para el estudio y la ms sencilla de entender por parte de los interrogados. Lleva tiempo desarrollar preguntas bien elaboradas y deben siempre probarse y modificarse, si es necesario, antes de que imprima una forma final y se distribuya. Seleccin de quienes recibirn el cuestionario. Aquellas personas que reciban el cuestionario deben seleccionarse de acuerdo con la informacin que puedan proporcionar. Escribir o imprimir un cuestionario no significa que se pueda distribuir ampliamente sin un anlisis previo. Lo pueden contestar personas no calificadas y si el cuestionario no es annimo, y no ser posible retirar sus respuestas de la muestra. La realizacin de esto tambin es desgastante y cara.
Elaborados por:
Pg. 87
INSTITUTO TECNOLGICO DE JIQUILPAN Apuntes de Fundamentos de Desarrollo de Sistemas Ingeniera en Sistemas Computacionales Plan 2004
5.1.3 Recopilacin y Anlisis de Documentos. Consiste en recopilar, examinar y formular los requisitos del cliente y examinar cualquier restriccin que se pueda aplicar. Para llevar a cabo este tipo de anlisis 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 adopcin de un mtodo mediante el cual se registrarn los hechos del estudio. Registrar ordenadamente la informacin recopilada de cualquier investigacin que se realice, es de exigencia general. Una regla general que debe tomarse en cuenta al realizar los registros, es hacerlo con la debida calidad para que cualquier persona pueda entenderlos. Es esencial obtener copias de los documentos utilizados en el sistema. Durante el curso de investigacin, el analista deber auxiliarse del uso de diagramas para el registro de las actividades. Existen fundamentalmente tres tipos de diagramas: Organigramas: Muestran la estructura orgnica y/o funcional de una organizacin. Sealan las funciones de lnea y dan idea de las responsabilidades del personal de esa organizacin. Su valor residen destacar los niveles de autoridad. Cuadros de Distribucin de Trabajo: Describe las actividades de cada unidad de la estructura de un departamento, determinando qu hace cada puesto. A travs de esta tcnica se obtiene una visin de las unidades de trabajo. Fluxogramas de procedimientos de diagramas de flujo: Representa el flujo de informacin de un procedimiento y satisfacen 3 funciones principales:
Permite al analista asegurarse que se ha desarrollado todos los aspectos del procedimiento. Da las bases para escribir un informe lgico y claro. Es un medio para establecer un enlace con el personal que eventualmente operar el nuevo procedimiento.
Los diagramas de flujo son la representacin grfica de un proceso administrativo. A travs del diagrama de flujo puede graficarse cualquier situacin administrativa u operativa, representada en forma objetiva para mostrar procedimientos. Una vez que se ha reunido toda la informacin relativa a la forma actual de operar del sistema, el analista o grupo de analistas procedern a organizar y documentar todo el material escrito, a fin de cubrir posteriormente la fase de anlisis y crtica del mismo. Como ltimo paso del proceso de la investigacin sobre la forma actual de operar del sistema, el responsable del estudio presentar a los usuarios un documento final, con el objeto de ultimar detalles que no hayan sido comprendidos por el analista. La presentacin del documento debe presentarse bajo la siguiente estructura: 1. Introduccin. 2. Objetivos del procedimiento.
Elaborados por: Lic. Martin Valencia Pg. 88
INSTITUTO TECNOLGICO DE JIQUILPAN Apuntes de Fundamentos de Desarrollo de Sistemas Ingeniera en Sistemas Computacionales Plan 2004
3. 4. 5. 6. 7. 8. 9.
Diagramas del flujo de actividades. Descripcin literaria del sistema. Formas e instructivos. Apndices. Hojas de operaciones. Cuadros comparativos. Conclusiones generales.
Una vez documentado el sistema actual se proceder a obtener la aprobacin de los responsables de su operacin.
5.1.4 Observacin y Tcnica STROBE. Ver es creer! Observar las operaciones le proporciona la analista hechos que no podra obtener de otra forma. Recopilacin de datos mediante la observacin. Leer en relacin con una actividad del negocio le proporciona al analista una dimensin de las actividades del Sistema. Entrevistar personal, ya sea directamente o a travs de cuestionarios, tambin le ayuda y le dice algo ms. Ninguno de los dos mtodos da una informacin completa; por ejemplo, leer en relacin con un viaje en jet no reproduce la experiencia de volar a unos 30 mil pies de altura. La observacin proporciona informacin de primera mano en relacin con la forma en que se llevan a cabo las actividades. Las preguntas sobre el uso de documentos, la manera en la que se realizan las tareas y si ocurren los pasos especficos como se pre-establecieron, pueden contestarse rpidamente si se observan las operaciones. OBSERVACION ESTRUCTURADA DEL AMBIENTE (STROBE) Para que el analista de Sistemas aprecie la forma en que los gerentes caracterizan su trabajo se usan las entrevistas y cuestionarios, tal como se dijo anteriormente. Sin embargo la observacin permite que el analista vea de primera mano cmo los gerentes recopilan, procesan, comparten y usan la informacin para hacer que el trabajo se realice. El mtodo para la observacin estructurada del ambiente es llamado STROBE. Es sistemtico debido a que: (1) Proporciona una metodologa estndar y una clasificacin estndar para el anlisis de los elementos organizacionales que influencian la toma de decisiones (2) Permite que otros analistas de Sistemas apliquen el mismo marco de trabajo analtico a la misma organizacin (3) Limita el anlisis a la organizacin a como existe durante la etapa actual de su ciclo de vida. Kendall & Kendall (Pg. 181). Existen siete elementos concretos que son fcilmente observables por el analista de Sistemas. Estos elementos pueden revelar mucho acerca de la forma en que el tomador de decisiones recopila, procesa,
Elaborados por: Lic. Martin Valencia Pg. 89
INSTITUTO TECNOLGICO DE JIQUILPAN Apuntes de Fundamentos de Desarrollo de Sistemas Ingeniera en Sistemas Computacionales Plan 2004
guarda y comparte informacin, as como acerca de la credibilidad del tomador de decisiones en el espacio de trabajo: 1. Ubicacin de la oficina. Las oficinas accesibles tienden a incrementar la interaccin y los mensajes informales. Las oficinas inaccesibles disminuyen la frecuencia de interaccin e incrementan los mensajes orientados a la tarea. Las oficinas distribuidas dan como resultado la demora de reportes o memos en alguna de ellas, en cambio, los grupos de oficinas motivan que se comparta la informacin. 2. Ubicacin del escritorio del tomador de decisiones. Proporciona pistas sobre el ejercicio de poder por el tomador de decisiones. 3. Equipo de oficina fijo. Se conforma de archiveros, libreros, etc. Si no hay equipo, es probable que el tomador de decisiones guarde pocos conceptos de informacin personalmente. Si hay abundancia de equipo, es presumible que el tomador de decisiones almacene y valore mucha informacin. 4. Propiedades. Todo el equipo pequeo que se usa para procesar informacin calculadoras, pantallas de video, lpices, etc.) 5. Revistas y peridicos del negocio. Estas revelan si el tomador de decisiones busca informacin externa o se apoya ms en informacin interna (reportes de la compaa, manuales de polticas, etc). 6. Iluminacin y color de la oficina. Nos indica la manera en que el tomador de decisiones recopila informacin. Un ejecutivo en una oficina iluminada clidamente, recopilar ms informacin informalmente y, en cambio, en una oficina brillantemente iluminada y coloreada se recolecta informacin mediante memorndums ms formales y reportes oficiales. 7. Vestimenta usada por los tomadores de decisiones. El analista de Sistemas puede obtener una comprensin de la credibilidad exhibida por los gerentes de la organizacin observando la vestimenta que usan en el trabajo. El traje formal de tres piezas para un hombre o el traje sastre para mujer, representan la mxima autoridad de acuerdo con algunos investigadores que han estudiado la percepcin de la apariencia de los ejecutivos. Mediante el uso de STROBE el analista de Sistemas puede obtener una mejor comprensin sobre la manera en que los gerentes recopilan, procesan, almacenan y usan informacin. Alternativas de aplicacin.
Elaborados por: Lic. Martin Valencia Pg. 90
INSTITUTO TECNOLGICO DE JIQUILPAN Apuntes de Fundamentos de Desarrollo de Sistemas Ingeniera en Sistemas Computacionales Plan 2004
Anlisis de fotografas. Consiste en fotografiar el ambiente de los tomadores de decisiones y anlisis posterior de las mismas sobre los elementos STROBE. Enfoque de las listas de verificacin/escala LIKERT. Es menos estructurada. Son listas con escalas en relacin con caractersticas del tomador de decisiones que fueron observables por medio de elementos fsicos en los ambientes organizacionales de los tomadores de decisiones y existen rangos para la evaluacin. Lista anecdtica con smbolos
Es menos estructurada. Consiste en usar analistas de verificacin anecdtica con smbolos de abreviaturas significativas. Sirve para evaluar los elementos STROBE en comparacin con la narracin organizacional generada por medio de entrevistas. smbolos (es una lista con situaciones especificas y diversas respuestas que son dadas a travs de smbolos) Para usar esta tcnica: 1. Determinar los temas organizacionales principales que se desprenden de las entrevistas. 2. Se construye una matriz, que liste las ideas principales a partir de la narrativa organizacional, acerca de la recopilacin, procesamiento, almacenamiento y comparticin de la informacin (los renglones) y elementos STROBE (columnas). 3. Se compara la narrativa y las acciones, se usa uno de los cinco smbolos adecuados para caracterizar la relacin entre la narracin y el elemento relevante. 4. El analista crea una tabla que primero documenta y luego ayuda en el anlisis de las observaciones. Cuando observar. La observacin es muy til cuando el analista necesita ver de primera mano, cmo se manejan los documentos, como se llevan a cabo los procesos y si ocurren los pasos especificados. Saber que buscar y como guiar su significado, tambin requiere de experiencia. Los observadores con experiencia captan quien utiliza los documentos y si encuentran dificultades; tambin estn alertas para detectar documentos o registros que no se utilizan. Muestreo. Con frecuencia, en muchas empresas la informacin ya se encuentra disponible para que el analista conozca las actividades u operaciones con las cuales no est familiarizado. Muchos tipos de registros e informes son accesibles si el analista sabe dnde buscar. En la revisin de registros, los analistas examinan datos y descripciones que ya estn escritos o registrados y en relacin con el Sistema y los departamentos de usuarios. Esta forma de encontrar datos puede servir como presentacin del analista, si se realiza al iniciar el estudio, o como un trmino de comparacin de lo que sucede en el departamento con lo que los registros presentan como lo que debera suceder. Recopilacin de datos por medio de la inspeccin ocular de registros. El trmino registro se refiere a los manuales escritos sobre polticas, regulaciones y procedimientos de operaciones estndar que la mayora de las empresas mantienen como gua para gerentes y empleados. Los manuales que documentan o describen las operaciones para los procesos de datos existentes, o
Elaborados por: Lic. Martin Valencia Pg. 91
INSTITUTO TECNOLGICO DE JIQUILPAN Apuntes de Fundamentos de Desarrollo de Sistemas Ingeniera en Sistemas Computacionales Plan 2004
Sistemas de informacin que entran dentro del rea de investigacin, tambin proporcionan una visin sobre la forma en la que el negocio debera conducirse. Normalmente muestran los requerimientos y restricciones del Sistema (como cantidad de transacciones o capacidad de almacenamiento de datos) y caractersticas de diseo (controles y verificacin del procesamiento). Los registros permiten que los analistas se familiaricen con algunas operaciones, oficinas de la compaa y relaciones formales a las que debe darse apoyo. No obstante, no muestran como producen de hecho las actividades, donde se ubica el poder verdadero para las decisiones, o como se realizan las tareas en la actualidad. Los otros mtodos con objeto de encontrar datos estudiados en esta seccin son ms eficaces para proporcionar al analista este tipo de informacin. Seleccin de los registros para revisin. En la mayor parte de las empresas los manuales de estndares sobre procedimientos de operacin usualmente son obsoletos; a menudo no se mantienen al corriente lo suficiente para sealar los procedimientos existentes. Los diagramas de organizacin muestran como las diferentes unidades deberan relacionarse con otras; pero muchas no reflejan las operaciones actuales. 5.2 Herramientas CASE. Se puede definir a las Herramientas CASE como un conjunto de programas y ayudas que dan asistencia a los analistas, ingenieros de software y desarrolladores, durante todos los pasos del Ciclo de Vida de desarrollo de un Software. Como es sabido, los estados en el Ciclo de Vida de desarrollo de un Software son: Investigacin Preliminar, Anlisis, Diseo, Implementacin e Instalacin Una innovacin en la organizacin, un concepto avanzado en la evolucin de tecnologa con un potencial efecto profundo en la organizacin. Se puede ver al CASE como la unin de las herramientas automticas de software y las metodologas de desarrollo de software formales. La realizacin de un nuevo software requiere que las tareas sean organizadas y completadas en forma correcta y eficiente. Las Herramientas CASE fueron desarrolladas para automatizar esos procesos y facilitar las tareas de coordinacin de los eventos que necesitan ser mejorados en el ciclo de desarrollo de software. La mejor razn para la creacin de estas herramientas fue el incremento en la velocidad de desarrollo de los sistemas. Por esto, las compaas pudieron desarrollar sistemas sin encarar el problema de tener cambios en las necesidades del negocio, antes de finalizar el proceso de desarrollo. Las herramientas CASE (Computer Aided Software Engineering, Ingeniera de Software Asistida por Ordenador) son diversas aplicaciones informticas destinadas a aumentar la productividad en el desarrollo de Software reduciendo el coste de las mismas en trminos de tiempo y de dinero. Estas herramientas nos pueden ayudar en todos los aspectos del ciclo de vida de desarrollo del Software en tareas como el proceso de realizar un diseo del proyecto, clculo de costes, implementacin de parte del cdigo automticamente con el diseo dado, compilacin automtica, documentacin o deteccin de errores entre otras. Historia. Ya en los aos 70 un proyecto llamado ISDOS dise un lenguaje y por lo tanto un producto que analizaba la relacin existente entre los requisitos de un problema y las necesidades que stos generaban, el lenguaje en cuestin se denominaba PSL (Problem Statement Language) y la aplicacin que ayudaba a buscar las necesidades de los diseadores PSA (Problem Statemente Analyzer).
Elaborados por:
Pg. 92
INSTITUTO TECNOLGICO DE JIQUILPAN Apuntes de Fundamentos de Desarrollo de Sistemas Ingeniera en Sistemas Computacionales Plan 2004
Aunque sos son los inicios de las herramientas informticas que ayudan a crear nuevos proyectos informticos, la primera herramienta CASE fue Excelerator que sali a la luz en el ao 1984 y trabajaba bajo una plataforma PC. Las herramientas CASE alcanzaron su techo a principios de los aos 90. En la poca en la que IBM haba conseguido una alianza con la empresa de Software AD/Cycle para trabajar con sus mainframes, estos dos gigantes trabajaban con herramientas CASE que abarcaban todo el ciclo de vida del Software. Pero poco a poco los mainframes han ido siendo menos utilizados y actualmente el mercado de las Big CASE ha muerto completamente abriendo el mercado de diversas herramientas ms especficas para cada fase del ciclo de vida del Software. Objetivos. 1. 2. 3. 4. 5. 6. 7. 8. 9. Clasificacin. Aunque no es fcil y no existe una forma nica de clasificarlas, las herramientas CASE se pueden clasificar teniendo en cuenta los siguientes parmetros: 1. 2. 3. 4. Las plataformas que soportan. Las fases del ciclo de vida del desarrollo de Sistemas que cubren. La arquitectura de las aplicaciones que producen. Su funcionalidad. Mejorar la productividad en el desarrollo y mantenimiento del Software. Aumentar la calidad del Software. Mejorar el tiempo y coste de desarrollo y mantenimiento de los Sistemas informticos. Mejorar la planificacin de un proyecto Aumentar la biblioteca de conocimiento informtico de una empresa ayudando a la bsqueda de soluciones para los requisitos. Automatizar, desarrollo del Software, documentacin, generacin de cdigo, pruebas de errores y gestin del proyecto. Ayuda a la reutilizacin del Software, portabilidad y estandarizacin de la documentacin Gestin global en todas las fases de desarrollo de Software con una misma herramienta. Facilitar el uso de las distintas metodologas propias de la ingeniera del Software.
La siguiente clasificacin es la ms habitual basada en las fases del ciclo de desarrollo que cubren: Upper CASE (U-CASE), herramientas que ayudan en las fases de planificacin, anlisis de requisitos y estrategia del desarrollo, usando, entre otros diagramas UML. Middle CASE (M-CASE), herramientas para automatizar tareas en el anlisis y diseo de la aplicacin. Lower CASE (L-CASE), herramientas que semiautomatizan la generacin de cdigo, crean programas de deteccin de errores, soportan la depuracin de programas y pruebas. Adems automatizan la documentacin completa de la aplicacin. Aqu pueden incluirse las herramientas de Desarrollo Rpido de Aplicaciones.
Existen otros nombres que se le dan a este tipo de herramientas, y que no es una clasificacin excluyente entre s, ni con la anterior:
Elaborados por: Lic. Martin Valencia Pg. 93
INSTITUTO TECNOLGICO DE JIQUILPAN Apuntes de Fundamentos de Desarrollo de Sistemas Ingeniera en Sistemas Computacionales Plan 2004
Integrated CASE (I-CASE), herramientas que engloban todo el proceso de desarrollo Software, desde anlisis hasta implementacin. Meta CASE, herramientas que permiten la definicin de nuestra propia tcnica de modelado, los elementos permitidos del metamodelo generado se guardan en un repositorio y pueden ser usados por otros analistas, es decir, es como si definiramos nuestro propio UML, con nuestros elementos, restricciones y relaciones posibles. CAST (Computer-Aided Software Testing), herramientas de soporte a la prueba de Software. IPSE (Integrated Programming Support Environment), herramientas que soportan todo el ciclo de vida, incluyen componentes para la gestin de proyectos y gestin de la configuracin.
Por funcionalidad podramos diferenciar algunas como: Herramientas de generacin semiautomtica de cdigo. Editores UML. Herramientas de Refactorizacin de cdigo. Herramientas de mantenimiento como los Sistemas de control de versiones
TIPOS DE HERRAMIENTAS CASE No existe una nica clasificacin de herramientas CASE, es difcil incluirlas en una clase determinada. Podran clasificarse atendiendo a: Las plataformas que soportan. Las fases del ciclo de vida del desarrollo de sistemas que abarca. La arquitectura de las aplicaciones que produce. Su funcionalidad.
Las herramientas CASE, en funcin de las fases del ciclo de vida abarcadas, se pueden agrupar de la forma siguiente: Herramientas integradas, I-CASE (Integrated CASE, CASE integrado): abarcan todas las fases del ciclo de vida del desarrollo de sistemas. Son llamadas tambin CASE workbench.
Las herramientas I-CASE se basan en una metodologa. Tienen un repositorio y aportan tcnicas estructuradas para todas las fases del ciclo de vida. Estas son las caractersticas que les confieren su mayor ventaja: una mejora de la calidad de los desarrollos. Sin embargo, no todas ellas son modernas en el sentido de aprovechar la potencia de las estaciones de trabajo o la utilizacin de lenguajes de alto nivel o tcnicas de prototipo. Herramientas de alto nivel, U-CASE (Upper CASE - CASE superior) o front-end, orientadas a la automatizacin y soporte de las actividades desarrolladas durante las primeras fases del desarrollo: anlisis y diseo.
Una estrategia posible es utilizar una U-CASE para anlisis y diseo, combinada con otras herramientas ms modernas para las fases de construccin y pruebas. En este caso, habra que vigilar cuidadosamente la integracin entre las distintas herramientas.
Elaborados por: Lic. Martin Valencia Pg. 94
INSTITUTO TECNOLGICO DE JIQUILPAN Apuntes de Fundamentos de Desarrollo de Sistemas Ingeniera en Sistemas Computacionales Plan 2004
Herramientas de bajo nivel, L-CASE (Lower CASE - CASE inferior) o back-end, dirigidas a las ltimas fases del desarrollo: construccin e implantacin. Juegos de herramientas o toolkits, son el tipo ms simple de herramientas CASE. Automatizan una fase dentro del ciclo de vida. Dentro de este grupo se encontraran las herramientas de reingeniera, orientadas a la fase de mantenimiento.
HERRAMIENTAS DE GESTION DE PROYECTOS: La mayora de herramientas CASE de gestin de proyectos, se centran en un elemento especifico de la gestin del proyecto, en lugar de proporcionar un soporte global para la actividad de gestin. Utilizando un conjunto seleccionado de la misma, se puede: realizar estimaciones de esfuerzo, costo y duracin, hacer un seguimiento continuo del proyecto, estimar la productividad y la calidad. Existen tambin herramientas que permite al comprador del desarrollo de un sistema, hacer un seguimiento que va desde requisitos del pliego de condiciones tcnicas inicial hasta el trabajo de desarrollo que convierte estos requisitos en un producto final. Se incluye dentro de las herramientas de control de proyectos las siguientes:
Herramientas de planificacin de proyectos: Las herramientas de esta categora se concentran en dos reas primordiales: Estimacin de esfuerzos de proyecto y de costes de software: Calculan el esfuerzo estimado, la duracin del proyecto y el nmero recomendado de personas. Planificacin de proyectos Capacitan al administrador para definir todas las reas del proyecto (la estructura de desglose de tareas), para crear una red de tareas (normalmente empleando una entrada grfica), para representar las interdependencias entre tareas y para modelar la cantidad de paralelismo que sea posible para ese proyecto. Herramientas de seguimiento de requisitos: Cuando se desarrollan grandes sistemas, el sistema proporcionado suele no satisfacer los requisitos especificados por el cliente. El objetivo de las herramientas de seguimiento de requisitos es proporcionar un enfoque sistemtico para el aislamiento de requisitos, comenzando por las especificaciones del cliente. Las herramientas de trazado de requisitos tpicos combinan una evaluacin de textos por interaccin humana, con un sistema de gestin de bases de datos que almacena y categora todos y cada uno de los requisitos del sistema que se "analizan" a partir de las especificaciones originales. Herramientas de gestin y mtricas: Las mtricas 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. Las herramientas mtricas actuales se centran en procesos, proyectos y caractersticas del producto. Las herramientas orientadas a la gestin capturan mtricas especificas del proyecto (por ejemplo: LDC/personamos, defectos por punto de funcin) que proporcionan una indicacin global de productividad o de calidad. Las herramientas orientadas tcnicamente determinan mtricas tcnicas que proporcionan una mejor visin de la calidad del diseo o del cdigo. Muchas de las herramientas mtricas avanzadas mantienen una base de datos de medidas de medias de la industria.
Elaborados por:
Pg. 95
INSTITUTO TECNOLGICO DE JIQUILPAN Apuntes de Fundamentos de Desarrollo de Sistemas Ingeniera en Sistemas Computacionales Plan 2004
Basndose en caractersticas de proyectos y de productos proporcionados por el usuario, estas herramientas califican los nmeros locales frente a los valore medios de la industria (y frente al rendimiento local anterior) y sugieren estrategias para llegar a mejoras. Estas herramientas utilizan un sistema experto para sugerir el orden en el que se debe llevar a cabo un proyecto. HERRAMIENTAS DE ANALISIS Y DISEO: Permiten al desarrollador crear un modelo del sistema que se va a construir y tambin la elaboracin de la validez y constancia de este modelo. Proporcionan un grado de confianza en la representacin del anlisis y ayudan a eliminar errores con anticipacin. Entre ellos podemos encontrar: Herramientas de anlisis y diseo (modelado): Las herramientas de anlisis y diseo capacitan al ingeniero del software para crear modelos del sistema que haya que construir. Los modelos contienen una representacin de los datos, de la funcin y del comportamiento (en el nivel de anlisis), as como caracterizaciones del diseo de datos, arquitectura, procedimientos e interfaz. Al efectuar una comprobacin de la consistencia y validez del modelo, las herramientas de anlisis y diseo proporcionan al ingeniero del software un cierto grado de visin en lo tocante a la representacin del anlisis, y le ayudan a eliminar errores antes de que se propaguen al diseo, o lo que es peor, a la propia implementacin. Herramientas de creacin de prototipos y simulacin: Las herramientas PRO/SIM (de prototipos y simulacin) proporcionan al ingeniero del software la capacidad de predecir el comportamiento de un sistema en tiempo real antes de llegar a construirlo. Adems, capacitan al ingeniero del software para desarrollar simulaciones del sistema de tiempo real que permitirn al cliente obtener ideas acerca de su funcionamiento, comportamiento y respuesta antes de la verdadera implementacin. Herramientas para desarrollo y diseo de interfaces: Las herramientas de desarrollo y diseo de interfaz son en realidad un conjunto de primitivas de componente de programas tales como mens, botones, estructuras de ventanas, iconos, mecanismos de desplazamiento, controladores de dispositivos, etc., Sin embargo, estos conjuntos de herramientas se estn viendo sustituidos por herramientas de generacin de prototipos de interfaz que permiten una rpida creacin en pantalla de sofisticadas interfaces de usuario, que se ajustan al estndar de interfaz que se haya adoptado para el software.
HERRAMIENTAS DE INTEGRACION Y PRUEBA: Sirven de ayuda a la adquisicin, medicin, simulacin y prueba de los equipos lgicos desarrollados. Entre las ms utilizadas esta: Herramientas de anlisis esttico: Las herramientas de anlisis esttico prestan su asistencia al ingeniero del software a efectos de derivar casos prcticos. Se utilizan tres tipos distintos de herramientas estticas de comprobacin en la industria: herramientas de comprobacin basadas en cdigo, lenguajes de comprobacin especializados, y herramientas de comprobacin basadas en requisitos. Las herramientas de comprobacin basadas en cdigo admiten un cdigo fuente (o PDL) como entrada y efectan un cierto nmero de anlisis que can lugar a la generacin de casos de prueba. Los lenguajes de comprobacin especializados (por ejemplo: ATLAS) capacitan al ingeniero del software para escribir detalladas especificaciones de comprobacin que describirn todos los casos de prueba y la logstica de su ejecucin. Las herramientas de comprobacin basadas en
Lic. Martin Valencia Pg. 96
Elaborados por:
INSTITUTO TECNOLGICO DE JIQUILPAN Apuntes de Fundamentos de Desarrollo de Sistemas Ingeniera en Sistemas Computacionales Plan 2004
requisitos aslan requisitos especficos del usuario y sugieren casos de prueba (o clases de comprobaciones) que ejerciten estos requisitos. Herramientas de anlisis dinmico: Las herramientas de anlisis dinmico interactan con un programa que se est ejecutando, comprueban la cobertura de rutas, comprueban las afirmaciones acerca del valor de variables especificas y en general instrumentan el flujo de ejecucin del programa. Las herramientas dinmicas pueden ser bien intrusivas, bien no intrusivas. Las herramientas intrusivas modifican el software que hay que comprobar mediante sondas que se insertan (instrucciones adicionales) y que efectan las actividades mencionadas anteriormente. Las herramientas de comprobacin no intrusivas utilizan un procesador hardware por separado que funciona en paralelo con el procesador que contenga el programa que se est comprobando. Herramientas de gestin de comprobacin: Las herramientas de gestin de comprobacin se utilizan para comprobar y coordinar la comprobacin de software para cada uno de los pasos principales de comprobacin. Las herramientas de esta categora administran y coordinan la comprobacin de regresiones, efectan comparaciones que determinan las diferencia s entre la salida real y la esperada, y efectan comprobaciones por lotes de programas con interfaces interactivas entre hombre y maquina. Adems de las funciones indicadas anteriormente, muchas herramientas de gestin de comprobaciones sirven tambin como controladores de comprobacin genricos. Un controlador de comprobacin lee uno o ms casos de prueba de algn archivo de pruebas, da formato a los datos de prueba para que se ajusten a las necesidades del software que se est probando, e invoca entonces al software que sea preciso comprobar. Herramientas de comprobacin clientes/servidor: El entorno C/S existe unas herramientas de comprobacin especializadas que ejerciten la interfaz grfica de usuario y los requisitos de comunicaciones en red para el cliente y el servidor. Herramientas de reingeniera: La categora de herramientas de reingeniera se pueden subdividir en las funciones siguientes: Herramientas de ingeniera inversa para producir especificaciones: se toma el cdigo fuente como entrada y se generan modelos grficos de anlisis y diseo estructurados, listos de utilizacin y otras informaciones de diseo. Herramientas de reestructuracin y anlisis de cdigo: se analiza la sintaxis del programa, se genera una grfica de control de flujo y se genera automticamente un programa estructurado. Herramientas de reingeniera para sistemas en lnea: se utilizan para modificar sistemas de bases de datos en lnea (por ejemplo: para convertir archivos IDMS o DB2 traducindolos a un formato de entidades y relaciones).
Muchas de las herramientas anteriores estn limitadas a lenguajes de programacin especficos (aun cuando se abarcan la mayora de los lenguajes principales) y requieren un cierto grado de interaccin con un ingeniero del software. Las herramientas de ingeniera inversa y progresiva de la prxima generacin harn un uso mucho mayor de tcnicas de inteligencia artificial, aplicando una base de conocimientos que se a especifica del dominio de la aplicacin (esto es, un conjunto de reglas de descomposicin que se aplicaran a todos los programas de una cierta zona de aplicacin tal como el control de fabricacin o la avinica). El componente de inteligencia artificial asistir en la descomposicin y reconstruccin de los sistemas, pero seguir requiriendo una interaccin con un ingeniero de software a lo largo del ciclo de la reingeniera.
Elaborados por:
Pg. 97
INSTITUTO TECNOLGICO DE JIQUILPAN Apuntes de Fundamentos de Desarrollo de Sistemas Ingeniera en Sistemas Computacionales Plan 2004
HERRAMIENTAS DE SOPORTE: Se engloban en esta categora las herramientas que recojan las actividades aplicables en todo el proceso de desarrollo, como las que se relacionan a continuacin: Herramientas de documentacin: Las herramientas de produccin de documentos y autoedicin prestan su apoyo a casi todos los aspectos de la ingeniera del software, y representan una importante oportunidad de aprovechamiento para todos los desarrolladores del software. La mayor parte de las organizaciones dedicadas al desarrollo de software invierte una cantidad de tiempo considerable en el desarrollo de documentos, y en muchos casos el proceso de documentacin en si resulta bastante deficiente. No es raro que una organizacin de desarrollo de software invierta hasta en un 20 o 30 pro ciento de su esfuerzo global de desarrollo de software en la documentacin. Por esta razn, las herramientas de documentacin suponen una oportunidad importante para mejorar la productividad. Herramientas para software de sistemas: CASE es una tecnologa de estaciones de trabajo. Por tanto, el entorno CASE debe adaptase a un software de sistema en redes de alta calidad, al correo electrnico, a los boletines electrnicos y a otras capacidades de comunicaciones. Herramientas de control de Calidad: La mayor parte de las herramientas CASE que afirman que tiene como principal inters el control de calidad son en realidad herramientas mtricas que hace una auditoria del cdigo fuente para determinar si es justa o no a ciertos estndares del lenguaje. Otras herramientas extraen mtricas tcnicas como base para medir la calidad del software que se est construyendo. Herramientas gestin de base de datos: El software de gestin de bases de datos sirve como fundamentos para establecer una base de datos CASE. Dado el nfasis acerca de los objetos de configuracin, las herramientas de gestin de bases de datos para CASE pueden evolucionar a partir de los sistemas de gestin de bases de datos relacionales (SGBDR) para transformarse en sistemas de gestin de bases de datos orientadas a objetos (SGBDOO).
5.2.1 Estructuradas Las herramientas Case utilizarn tcnicas grficas para disear las clases y sus interacciones, y para utilizar objetos existentes adaptados en nuevas aplicaciones. Las herramientas deberan facilitar el modelamiento en trminos de eventos, triggers (iniciadores), estado de los objetos, etc. Las herramientas de los CASE Orientados a Objetos generan cdigos tan pronto como una clase sea definida y permitir al diseador probar y utilizar el mtodo creado. Las herramientas debern ser diseadas para estimular la mxima creatividad y continuo refinamiento del diseo durante la construccin. 5.2.2 Herramientas CASE Orientadas a Objetos Muchos de los beneficios son alcanzados nicamente cuando el Anlisis y Diseo son utilizados con herramientas CASE Orientadas a Objetos, basados en repositorios que generan cdigos. Fomenta la reutilizacin y extensin del cdigo. Permite crear Sistemas ms complejos. Relacionar el Sistema al mundo real.
Elaborados por: Lic. Martin Valencia Pg. 98
INSTITUTO TECNOLGICO DE JIQUILPAN Apuntes de Fundamentos de Desarrollo de Sistemas Ingeniera en Sistemas Computacionales Plan 2004
Facilita la creacin de programas visuales. Construccin de prototipos Agiliza el desarrollo de Software Facilita el trabajo en equipo Facilita el mantenimiento del Software Lo interesante de la Programacin Orientada a Objetos es que proporciona conceptos y herramientas con las cuales se modela y representa el mundo real tan fielmente como sea posible. Reutilizacin.- Las clases son diseadas de tal manera que ellas puedan ser reutilizadas en muchos Sistemas. Para maximizar la reutilizacin las clases deben ser construidas de manera que puedan ser personalizadas. Un repositorio debera ser cargado con una coleccin de clases reutilizables. Un objetivo permanente de las tcnicas Orientadas a Objetos, es conseguir la reutilizacin masiva en la construccin de Software. Estabilidad.- Las clases diseadas para la reutilizacin repetida, llegan a ser estables de la misma manera que los microprocesadores y otros chips que son bastante estables. Las aplicaciones sern construidas utilizando chips de Software. El Diseador piensa de Comportamiento de Objeto, no en Niveles de Detalle. El encapsulamiento oculta los detalles y hace fcil el uso de clases complejas. Las clases son semejantes a las cajas negras. El desarrollador utiliza la caja negra sin mirar su interior. El tiene un entendimiento del comportamiento de la caja negra y cmo comunicarse con ella. Construccin de Objetos de complejidad Creciente.- Los objetos se construyen fuera de los objetos. Una buena manera de fabricar es construir tomando una lista de materiales de partes y subpartes existentes. Esto posibilita construir componentes de Software complejos y los mismos se utilizarn para construir otros bloques de Software ms complejos. Confiabilidad.- EL Software construido a partir de una librera de clases estables, es probable que se encuentre libre de errores, respecto a construir Software desde el inicio. Cada mtodo en una clase es en s mismo simple y diseado para ser confiable. Verificacin de Correcciones.- El Diseo Orientado a Objetos con tcnica formal para la creacin de mtodos, puede generar potencialmente Software de alta confiabilidad. Tcnicas para verificar y garantizar la operacin correcta de una clase, probablemente estn disponibles en nuevas generaciones de herramientas CASE Orientadas a Objetos. Diseo Rpido.- Las aplicaciones son creadas tomando componentes preexistentes. Muchos componentes son construidos de tal forma que, puedan ser observados, personalizados, para un diseo particular. Los componentes pueden ser vistos, customizados y enlazados en la pantalla de la herramienta CASE. Nuevos Mercados de Software.- Las compaas de Software, deberan proporcionar libreras de clases para reas especficas, fcilmente adaptables a las necesidades de la organizacin. La era de los paquetes monolticos est siendo reemplazada por Software que incorpora clases y encapsula paquetes de diferentes vendedores.
Elaborados por: Lic. Martin Valencia Pg. 99
INSTITUTO TECNOLGICO DE JIQUILPAN Apuntes de Fundamentos de Desarrollo de Sistemas Ingeniera en Sistemas Computacionales Plan 2004
Diseo de Alta Calidad.- Los diseos son a menudo de alta calidad, ya que ellos se construyen a partir de componentes que han sido aprobados y refinados repetidamente. Integridad.- Las estructuras de Datos pueden ser utilizadas solamente con mtodos especficos. Esto es particularmente importante en Sistemas distribuidos y Sistemas CLIENTE/SERVIDOR, donde usuarios desconocidos pueden tratar de accesar al Sistema. Facilidad de Programacin.- Los programas son construidos utilizando pequeas plazas de Software las cuales son generalmente fciles de crear. Fcil Mantenimiento.- Los programas de mantenimiento generalmente cambiarn los mtodos correspondientes a una clase. Cada clase realiza sus operaciones independientemente de otras clases. Creatividad.- Implementadores hbiles en poderosas herramientas CASE Orientadas a Objetos laborando sobre estaciones de trabajo, encuentran que puede generar rpidamente muchas ideas. Las herramientas estimulan la creacin e implementan las invenciones. La genialidad individual puede ser ms creativa. Ciclo de Vida Dinmico.- Los objetivos de desarrollo de un Sistema, a menudo cambian durante la implementacin. Las herramientas CASE Orientadas a Objetos, hacen los cambios durante el ciclo de vida rpidamente. Esto permite a los diseadores de Sistemas satisfacer mejor a los usuarios finales, adaptarse a los cambios, refinar los objetivos y mejorar constantemente el diseo durante la implementacin. Refinamiento durante la Construccin.- Las personas creativas cambian constantemente el diseo de su trabajo mientras se est implementando. Esto conduce a ms y mejores resultados. Los trabajos creativos objetivos, son una y otra vez refinados. Las herramientas CASE Orientadas a Objetos proporcionan a los constructores de Software la capacidad para refinar el diseo durante la implementacin. Modelamiento ms realstico.- El Anlisis Orientado a Objetos modela la empresa o rea de negocio de una manera ms coherente y minuciosa que los mtodos tradicionales de anlisis. El anlisis se traslada directamente al diseo e implementacin. En tcnicas convencionales, el entorno del problema cambia cuando vamos del anlisis al diseo y del diseo a la programacin. Con tcnicas de Anlisis, Diseo e Implementacin Orientados a Objetos utiliza el mismo paradigma y lo refinan sucesivamente. Interface Grfica Seductiva al Usuario.- Se debera utilizar interfaces grficas para usuarios, tal que sta apunte al icono que relacione al objeto. Independencia de Diseo.- Las clases son diseadas independientemente de plataforma de operacin, Hardware o Software. Las clases emplean requerimientos y respuestas de forma. Esto permite que ellos sean utilizados con mltiples Sistemas operativos, DBMS, manejadores de redes, interfaces grficas para usuarios, etc. Interoperactividad.- Software de diferentes vendedores pueden trabajar juntos. Un vendedor puede utilizar clase de otros vendedores. La Interoperactividad de Software de diferentes vendedores es uno de los objetivos ms importantes de los estndares de la Orientacin a Objetos. Software desarrollado independientemente en lugares separados, deberan ser capaces de trabajar juntos y presentarse como una unidad simple al usuario. Computacin Cliente / Servidor.- En el Sistema Cliente / Servidor, las clases en el Software cliente deberan enviar sus requerimientos a las clases de Software servidor y recibir respuestas. Una clase
Elaborados por: Lic. Martin Valencia Pg. 100
INSTITUTO TECNOLGICO DE JIQUILPAN Apuntes de Fundamentos de Desarrollo de Sistemas Ingeniera en Sistemas Computacionales Plan 2004
servidor puede ser utilizada por muchos clientes. Esto puede accesar al Software nicamente a travs de los mtodos (as los datos se protegen de corrupciones). Computacin masivamente Distribuida.- Redes alrededor del mundo emplearn directorios de Software de objetos accesibles. El diseo orientado al objeto, es la clave para la computacin masivamente distribuida. Las clases en una mquina interactuarn con cualquier otra, sin necesidad de saber dnde residen. Ellas envan y reciben mensajes en formatos estndares. Computacin Paralela.- La velocidad de las mquinas, pueden ser ampliamente mejoradas mediante la instalacin de computadoras en paralelo. Se pueden tener procesamientos simultneos y concurrentes en mltiples chips de procesadores (eventualmente, un chip puede tener muchos procesadores). Objetos en diferentes procesadores se ejecutarn simultneamente, cada uno de ellos actuando independientemente. Alto Nivel de Automatizacin de Bases de datos.- Las estructuras en Base de Datos OO, estn ligadas a mtodos que toman acciones automticas. Una Base de Datos OO, tiene su inteligencia construida en la forma de mtodos, mientras que otras bases de datos no. Performance de Mquinas.- 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 ms complejas. Las bases de datos Orientados a Objetos, la computacin concurrente y el diseo Orientado a Objetos prometen mayores saltos en la performance de las mquinas LANS basadas en Sistemas Cliente/Servidor. Emplearn servidores de Base de Datos concurrentes y orientadas al objeto. Migracin.- Existiendo o no aplicaciones orientadas a objetos, ellos pueden ser preservados convenientemente con una cobertura Orientada a Objetos, comunicndose entre ellos mediante mensajes estndares Orientados a Objetos. Mejores herramientas CASE.- Las herramientas Case utilizarn tcnicas grficas para disear las clases y sus interacciones, y para utilizar objetos existentes adaptados en nuevas aplicaciones. Las herramientas deberan facilitar el modelamiento en trminos de eventos, triggers (iniciadores), estado de los objetos, etc. Las herramientas de los CASE Orientados a Objetos generan cdigos tan pronto como una clase sea definida y permitir al diseador probar y utilizar el mtodo creado. Las herramientas debern ser diseadas para estimular la mxima creatividad y continuo refinamiento del diseo durante la construccin. Industriales de Libreras de Clases.- Las compaas de Software comercializarn libreras para diferentes reas de aplicacin. Las libreras de clases independientes de las aplicaciones, sern tambin importantes y stas sern proporcionadas como facilidades de herramientas CASE (VIC). Libreras de Clases Corporativas.- Las corporaciones, crearn sus propias libreras de clases que reflejen sus estndares internos y requerimientos de aplicacin. La identificacin TOP-DOWN de los OBJETOS del negocio, es un aspecto importante de la ingeniera de la Informacin. Los diferentes beneficios afectan a diferentes desarrolladores de diversas maneras. Examinaremos los beneficios percibidos por: Un Inventor.- El inventor de Software requiere el conjunto de herramientas del CASE Orientadas a Objetos, para generar cdigos tan rpidos como l sobre la pantalla.
Elaborados por: Lic. Martin Valencia Pg. 101
INSTITUTO TECNOLGICO DE JIQUILPAN Apuntes de Fundamentos de Desarrollo de Sistemas Ingeniera en Sistemas Computacionales Plan 2004
Fbrica de Software.- Para crear productos ricos e interesantes, el fabricante de Software requiere incorporar Software de otros vendedores en sus propios diseos. Jefe de Informtica.- El objetivo es ensamblar aplicaciones de alta calidad tomando partes reutilizables y utilizando un generador para todo cdigo nuevo. Un Equipo de Proyecto de Sistemas de Informacin.- Las herramientas CASE Orientadas a Objetos posibilitan al equipo ajustar continuamente o disear la aplicacin mientras se est construyendo para satisfacer las necesidades del usuario, tan fielmente como sean posibles. Un Integrador de Sistemas.- Un integrador de Sistemas tiene que ver con: Construccin del Sistema de Redes. Mquinas y Software de diferentes vendedores. Un problema maysculo, es buscar que los Software de los diferentes vendedores trabajen juntos.
Uno de los beneficios ms importantes de la Orientacin a Objetos es su nivel de reutilizacin. Las tcnicas Orientadas a Objetos permiten alcanzar la reutilizacin de dos maneras: 1. Construir Software tomando componentes (clases) que ya existen. 2. Crear clases modificadas utilizando herencia que les permite reutilizar mtodos y estructuras de datos de clases de nivel superior.
5.3 Desarrollo de Prototipos Para decidir si el prototipo debe incluirse o no Ciclo de Desarrollo de Sistema de Informacin, el profesional considera los siguientes factores:
Problemas no estructurados, novedosos y complejos, de informacin personalizada del usuario, ya que sus salidas no son predecibles y definidas. Problemas de ambiente Inestable, el profesional tambin debe evaluar el contexto del Sistema. Experiencia en diseos similares. No se conocen los requerimientos, la naturaleza del Sistema es tal que existe poca informacin con respecto a las caractersticas que debe tener el nuevo Sistema para satisfacer las necesidades del usuario. Los requerimientos deben evaluarse, se conocen los requerimientos aparentes de informacin pero es necesario verificarlos y evaluarlos Costos altos, donde la inversin involucra gran cantidad de recursos financieros y humanos. Altos riesgo, la evaluacin inexacta de los requerimientos o el desarrollo incorrecto ponen en peligro a la organizacin. El usuario, donde no est dispuesta examinar modelos en papel, o no sabe lo que quiere pero lo reconocer cuando lo vea. Tecnologas Nuevas, la falta de experiencia en el uso de dichas tecnologas, junto con el deseo de instalar nuevas tecnologa hace que sea propicio el uso del prototipo.
Elaborados por:
Pg. 102
INSTITUTO TECNOLGICO DE JIQUILPAN Apuntes de Fundamentos de Desarrollo de Sistemas Ingeniera en Sistemas Computacionales Plan 2004
Etapas del Prototipo. El desarrollo de un prototipo se lleva a cabo en forma ordenada a travs de las siguientes etapas: Identificacin de Requerimientos Conocidos. El profesional de Sistema en esta etapa, identifica los requerimientos conocidos, generales, o caractersticas esenciales y determina el propsito del prototipo de la aplicacin. Desarrollo de un Modelo. En esta etapa se explica el mtodo iterativo y las responsabilidades a los usuarios ya que el usuario participa directamente en todo el proceso. La rapidez con la que se genera el Sistema es esencial para que no se pierda el estado de nimo sobre el proyecto y los usuarios puedan comenzar a evaluar la aplicacin con la mayor brevedad posible. El profesional de Sistema para construccin inicial del prototipo emplea cualquier herramienta, como Lenguajes de Cuarta Generacin, Generadores de Reportes, Generadores de Pantallas En el desarrollo de un prototipo se preparan los siguientes componentes:
El lenguaje para el dilogo o conversacin entre el usuario y el Sistema Pantallas y formatos para la entrada de datos Mdulos esenciales de procesamientos Salida del Sistema
La incorporacin en la interfaz de entrada/salida de caractersticas representativas de las que sern incluidas en el Sistema final permite una mayor exactitud en el proceso de evaluacin. Revisin del Prototipo. Es responsabilidad del usuario trabajar con el prototipo y evaluar sus caractersticas y operacin. La experiencia con el Sistema bajo condiciones reales permite la familiaridad indispensable para determinar los cambios o mejoras que sean necesarios, o tambin la eliminacin de caractersticas innecesarias. El profesional de Sistema captura la informacin sobre lo que le gusta y lo que le desagrada a los usuarios. Esta informacin tiene influencia en la siguiente versin del prototipo, la cual se presenta modificada, refinada. Iteracin. Los dos ltimos etapas descriptas anteriormente se repiten varias veces hasta que estn usuarios y profesionales de Sistema de acuerdo en que el prototipo ha evolucionado lo suficiente o que una iteracin ms no traer beneficios adicionales.
Prototipo Terminado.
Elaborados por:
Pg. 103
INSTITUTO TECNOLGICO DE JIQUILPAN Apuntes de Fundamentos de Desarrollo de Sistemas Ingeniera en Sistemas Computacionales Plan 2004
Cuando el prototipo est terminado, es decir, tenemos la informacin que buscamos seguimos en el punto donde habamos quedado dentro del Ciclo de Desarrollo de Sistema. Diseo y Arquitectura de Productos de Software. La idea bsica: Ensamblaje de partes de Software previamente elaboradas. Inspirada en los procesos de produccin de Sistemas fsicos. Produccin de aviones, vehculos, computadores, aparatos electrnicos, etc. Fundamentada en la Reutilizacin de Software. Asume la existencia de una industria de partes Definicin: Se refieren a tcnicas de ingeniera para crear un portafolio de Sistemas de Software similares, a partir de un conjunto compartido de activos de Software, usando un medio comn de produccin (Krueger, 2006). Es un conjunto de Sistemas de Software que comparten un conjunto comn y gestionado de aspectos que satisfacen las necesidades especficas de un segmento de mercado o misin y que son desarrollados a partir de un conjunto comn de activos fundamentales [de Software] de una manera preescrita (Clements and Northrop, 2002). Consiste de una familia de Sistemas de Software que tienen una funcionalidad comn y alguna funcionalidad variable (Gomma, 2004). Beneficios: La entrega de productos de Software de una manera ms rpida, econmica y con una mejor calidad. Las LPS producen mejoras en: - Tiempo de entrega del producto (time to market) - Costos de ingeniera. - Tamao del portafolio de productos. - Reduccin de las tasas de defectos. - Calidad de los productos. Beneficios tcticos y estratgicos (Krueger, 2006): Beneficios tcticos de ingeniera: - Reduccin en el tiempo promedio de creacin y entrega de nuevos productos - Reduccin en el nmero promedio de defectos por producto - Reduccin en el esfuerzo promedio requerido para desarrollar y mantener los productos - Reduccin en el costo promedio de produccin de los productos - Incremento en el nmero 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. Martin Valencia Pg. 104
INSTITUTO TECNOLGICO DE JIQUILPAN Apuntes de Fundamentos de Desarrollo de Sistemas Ingeniera en Sistemas Computacionales Plan 2004
Conceptos en los que las LPS se fundamentan Aspectos tecnolgicos Qu tecnologas son fundamentales para desarrollar y mantener activos y productos de Software Aspectos metodolgicos Cmo desarrollar y mantener los activos y productos de Software Aspectos organizativos Cmo debe la empresa organizarse internamente Aspectos gerenciales Cmo gestionar los proyectos de desarrollo de activos y productos
INSTITUTO TECNOLGICO DE JIQUILPAN Apuntes de Fundamentos de Desarrollo de Sistemas Ingeniera en Sistemas Computacionales Plan 2004
El diseo modular propone dividir el Sistema en partes diferenciadas y definir sus interfaces. sus ventajas: claridad, reduccin de costos y reutilizacin Los pasos a seguir son: 1. Identificar los mdulos 2. Describir cada mdulo 3. Describir las relaciones entre mdulos Una descomposicin modular debe poseer ciertas cualidades mnimas para que se pueda considerar suficientemente vlida. 1. Independencia funcional 2. Acoplamiento 3. Cohesin 4. Comprensibilidad 5. Adaptabilidad a) Independencia funcional Cada mdulo debe realizar una funcin concreta o un conjunto de funciones afines. Es recomendable reducir las relaciones entre mdulos al mnimo. Para medir la independencia funcional hay dos criterios: acoplamiento y cohesin b) Acoplamiento El acoplamiento es una medida de la interconexin entre mdulos en la estructura del programa. Podemos graduar en un amplio espectro, pero por lo general se tiende a que el acoplamiento sea lo menor posible, esto es a reducir las interconexiones entre los distintos mdulos en que se estructure nuestra aplicacin. El grado de acoplamiento mide la interrelacin entre dos mdulos, segn el tipo de conexin y la complejidad de la interface: Fuerte - Por contenido, cuando desde un mdulo se puede cambiar datos locales de otro. - Comn, se emplea una zona comn de datos a la que tienen acceso varios mdulos. Moderado - De control, la zona comn es un dispositivo externo al que estan ligados los mdulos, esto implica que un cambio en el formato de datos los afecta a todos.
Elaborados por: Lic. Martin Valencia Pg. 106
INSTITUTO TECNOLGICO DE JIQUILPAN Apuntes de Fundamentos de Desarrollo de Sistemas Ingeniera en Sistemas Computacionales Plan 2004
- Por etiqueta, en intercambio de datos se realiza mediante una referencia a la estructura completa de datos(vector, pila, rbol, grafo,) Dbil - De datos, viene dado por los datos que intercambian los mdulos. Es el mejor. - Sin acoplamiento directo, es el acoplamiento que no existe c) Cohesin Un mdulo coherente ejecuta una tarea sencilla en un procedimiento de SW y requiere poca interaccin con procedimientos que se ejecutan en otras partes de un programa. Podemos decir que un mdulo coherente es aquel que intenta realizar solamente una cosa. Para que n de mdulos no sea demasiado elevado y complique el diseo se tratan de agrupar elementos afines y relacionados en un mismo mdulo.
ALTA
Cohesin abstraccional, se logra cuando se disea el mdulo como tipo abstracto de datos o como una clase de objetos Cohesin funcional, el mdulo realiza una funcin concreta y especfica
MEDIA
Cohesin secuencial, los elementos del mdulo trabajan de forma secuencial Cohesin de comunicacin, elementos que operan con el mismo conjunto de datos de entrada o de salida Cohesin temporal, se agrupan elementos que se ejecutan en el mismo momento. Ej. Arrancar o parar dispositivos
BAJA
. Cohesin lgica, se agrupan elementos que realizan funciones similares. . Cohesin coincidental, es la peor y se produce cuando los elementos de un mdulo no guardan relacin alguna La descripcin del comportamiento de un mdulo permite establecer el grado de cohesin: - Si es una frase compuesta y contiene ms de un verbo la cohesin ser MEDIA - Si contiene expresiones secuenciales (primero, entonces, cuando), ser temporal o secuencial - Si la descripcin no se refiere a algo especfico (Ej. Todos los errores), cohesin lgica
Elaborados por: Lic. Martin Valencia Pg. 107
INSTITUTO TECNOLGICO DE JIQUILPAN Apuntes de Fundamentos de Desarrollo de Sistemas Ingeniera en Sistemas Computacionales Plan 2004
- Si aparece inicializar, preparar, configurar, probablemente sea temporal. d) Comprensibilidad Para facilitar los cambios, el mantenimiento y la reutilizacin de mdulos es necesario que cada uno sea comprensible de forma aislada. Para ello es bueno que posea independencia funcional, pero adems es deseable: - Identificacin, el nombre debe ser adecuado y descriptivo - Documentacin, debe aclarar todos los detalles de diseo e implementacin que no queden de manifiesto en el propio cdigo - SIMPLICIDAD, las soluciones sencillas son siempre las mejores e) Adaptabilidad La adaptacin de un Sistema resulta ms difcil cuando no hay independencia funcional, es decir, con alto acoplamiento y baja cohesin, y cuando el diseo es poco comprensible. Otros factores para facilitar la adaptabilidad: - Previsin, es necesario prever que aspectos del Sistema pueden ser susceptibles de cambios en el futuro, y poner estos elementos en mdulos independientes, de manera que su modificacin afecte al menor nmero de mdulos posibles. -Accesibilidad, debe resultar sencillo el acceso a los documentos de especificacin, diseo, e implementacin para obtener un conocimiento suficiente del Sistema antes de proceder a su adaptacin. - Consistencia, despus de cualquier adaptacin se debe mantener la consistencia del Sistema, incluidos los documentos afectados
6.2 Arquitectura de dominio especfico. El reto para el diseo es disear el software y hardware para proporcionar caractersticas deseables a los sistemas distribuidos y, al mismo tiempo, minimizar los problemas propios a estos sistemas. Es necesario comprender las ventajas y desventajas de las diferentes arquitecturas de sistemas distribuidos. Aqu se tratan dos tipos genricos de arquitecturas de sistemas distribuidos: Arquitectura cliente-servidor. En este caso el sistema puede ser visto como un conjunto de servicios que se proporcionan a los clientes que hacen uso de dichos servicios. Los servidores y los clientes se tratan de forma diferente en estos sistemas. Arquitecturas de objetos distribuidos. Para esta arquitectura no hay distincin entre servidores y clientes, y el sistema puede ser visto como un conjunto de objetos que interaccionan cuya localizacin es irrelevante. No hay distincin entre un proveedor de servicios y el usuario de estos servicios. Ambas arquitecturas se usan ampliamente en la industria, pero la distribucin de las aplicaciones generalmente tiene lugar dentro de una nica organizacin. La distribucin soportada es, por lo tanto, intraorganizacional. Tambin se pueden tomar dos tipos ms de arquitecturas distribuidas que son ms
Elaborados por: Lic. Martin Valencia Pg. 108
INSTITUTO TECNOLGICO DE JIQUILPAN Apuntes de Fundamentos de Desarrollo de Sistemas Ingeniera en Sistemas Computacionales Plan 2004
adecuadas para la distribucin interorganizacional: arquitectura de sistemas peer-to-peer (p2p) y arquitecturas orientadas a servicios. Los sistemas peer-to-peer han sido usados principalmente para sistemas personales, pero estn comenzando a usarse para aplicaciones de empresa. Los componentes en un sistema distribuido pueden implementarse en diferentes lenguajes de programacin y pueden ejecutarse en tipos de procesadores completamente diferentes. Los modelos de datos, la representacin de la informacin y los protocolos de comunicacin pueden ser todos diferentes. Un sistema distribuido, por lo tanto, requiere software que pueda gestionar estas partes distintas, y asegurar que dichas partes se puedan comunicar e intercambiar datos. El trmino middleware se usa para hacer referencia a ese software; se ubica en medio de los diferentes componentes distribuidos del sistema. Bernstein (Bernstein, 1996) resume los tipos de middleware disponibles para soportar computacin distribuida. El middleware es un software de propsito general que normalmente se compra como un componente comercial ms que escribirse especialmente por los desarrolladores de la aplicacin. Ejemplos de middleware son software para gestionar comunicaciones con bases de datos, administradores de transacciones, convertidores de datos y controladores de comunicacin. Los sistemas distribuidos se desarrollan normalmente utilizando una aproximacin orientada a objetos. Estos sistemas estn formados por partes independientes pobremente integradas, cada una de las cuales puede interaccionar directamente con los usuarios o con otras partes del sistema. Algunas partes del sistema pueden tener que responder a eventos independientes. Los objetos software reflejan estas caractersticas; por lo tanto, son abstracciones naturales para los componentes de sistemas distribuidos.
La Arquitectura de Software constituye una disciplina de reciente aparicin y forma parte del paradigma de la Ingeniera del Software. Representa la versin moderna de un diseo Software y es apta para describir Sistemas complejos. Definicin: Arquitectura de Software
Una arquitectura de Software es un conjunto de elementos arquitectnicos que tiene una determinada forma. Las propiedades restringen la eleccin de los elementos de la arquitectura mientras que la lgica captura la motivacin de la eleccin de los elemetos y la forma.
Una arquitectura de Software incluye la descripcin de elementos a partir de los cuales se constituyen los Sistemas de Software, interacciones entre esos elementos, patrones que guan la composicin y restricciones sobre esos patrones. En general, un Sistema de Software particular se define en trminos de una coleccin de componentes e interacciones entre dichos componentes. Tal Sistema puede ser utilizado como un elemento en un Sistema ms grande.(Garlan y Shaw 1996) Una arquitectura de Software de un programa o Sistema de computacin es la estructura o estructuras del Sistema, el cual comprende componentes, las propiedades visibles externas de dichos componentes y las relaciones entre ellos.(Bass, Clements y Kazman 1998).
El reto para el diseo es disear el Software y Hardware para proporcionar Caractersticas deseables a los Sistemas distribuidos y, al mismo tiempo, minimizar los problemas propios a estos Sistemas. Es necesario comprender las ventajas y desventajas de las diferentes arquitecturas de
Elaborados por: Lic. Martin Valencia Pg. 109
INSTITUTO TECNOLGICO DE JIQUILPAN Apuntes de Fundamentos de Desarrollo de Sistemas Ingeniera en Sistemas Computacionales Plan 2004
Sistemas distribuidos. Aqu se tratan dos tipos genricos de arquitecturas de Sistemas distribuidos: Arquitectura cliente-servidor. En este caso el Sistema puede ser visto como un conjunto de servicios que se proporcionan a los clientes que hacen uso de dichos servicios. Los servidores y los clientes se tratan de forma diferente en estos Sistemas. Arquitecturas de objetos distribuidos. Para esta arquitectura no hay distincin entre servidores y clientes, y el Sistema puede ser visto como un conjunto de objetos que interaccionan cuya localizacin es irrelevante. No hay distincin entre un proveedor de servicios y el usuario de estos servicios. Ambas arquitecturas se usan ampliamente en la industria, pero la distribucin de las aplicaciones generalmente tiene lugar dentro de una nica organizacin. La distribucin soportada es, por lo tanto, interorganizacional. Tambin se pueden tomar dos tipos ms de arquitecturas distribuidas que son ms adecuadas para la distribucin interorganizacional: arquitectura de Sistemas peer-to-peer (p2p) y arquitecturas orientadas a servicios. Los Sistemas peer-to-peer han sido usados principalmente para Sistemas personales, pero estn comenzando a usarse para aplicaciones de empresa. Los componentes en un Sistema distribuido pueden implementarse en diferentes lenguajes de programacin y pueden ejecutarse en tipos de procesadores completamente diferentes. Los modelos de datos, la representacin de la informacin y los protocolos de comunicacin pueden ser todos diferentes. Un Sistema distribuido, por lo tanto, requiere Software que pueda gestionar estas partes distintas, y asegurar que dichas partes se puedan comunicar e intercambiar datos. El trmino middleware se usa para hacer referencia a ese Software; se ubica en medio de los diferentes componentes distribuidos del Sistema. Bernstein (Bernstein, 1996) resume los tipos de middleware disponibles para soportar computacin distribuida. El middleware es un Software de propsito general que normalmente se compra como un componente comercial ms que escribirse especialmente por los desarrolladores de la aplicacin. Ejemplos de middleware son Software para gestionar comunicaciones con bases de datos, administradores de transacciones, convertidores de datos y controladores de comunicacin. Los Sistemas distribuidos se desarrollan normalmente utilizando una aproximacin orientada a objetos. Estos Sistemas estn formados por partes independientes pobremente integradas, cada una de las cuales puede interaccionar directamente con los usuarios o con otras partes del Sistema. Algunas partes del Sistema pueden tener que responder a eventos independientes. Los objetos Software reflejan estas caractersticas; por lo tanto, son abstracciones naturales para los componentes de Sistemas distribuidos.
Diseo de Software de Arquitectura Multiprocesador 6.2.1 Diseo de Software de Arquitectura Multiprocesador Un Sistema multiproceso o multitarea es aquel que permite ejecutar varios procesos de forma concurrente, la razn es porque actualmente la mayora de las CPUs slo pueden ejecutar un proceso cada vez. La nica forma de que se ejecuten de forma simultnea varios procesos es tener varias CPUs (ya sea en una mquina o en varias, en un Sistema distribuido. La ventaja de un Sistema multiproceso reside en la operacin llamada cambio de contexto. Esta operacin consiste en quitar a un proceso de la CPU, ejecutar otro proceso y volver a colocar el primero sin que se entere de nada.
Elaborados por:
Pg. 110
INSTITUTO TECNOLGICO DE JIQUILPAN Apuntes de Fundamentos de Desarrollo de Sistemas Ingeniera en Sistemas Computacionales Plan 2004
El multiproceso no es algo difcil de entender: ms procesadores significa ms potencia computacional. Un conjunto de tareas puede ser completado ms rpidamente si hay varias unidades de proceso ejecutndolas en paralelo. Esa es la teora, pero otra historia es la prctica, como hacer funcionar el multiproceso, lo que requiere unos profundos conocimientos tanto del Hardware como del Software. Es necesario conocer ampliamente como estn interconectados dichos procesadores, y la forma en que el cdigo que se ejecuta en los mismos ha sido escrito para escribir aplicaciones y Software que aproveche al mximo sus prestaciones. Para lograrlo, es necesario modificar varias facetas del Sistema operativo, la organizacin del cdigo de las propias aplicaciones, as como los lenguajes de programacin. Se configuran dos computadoras de gran capacidad interconectados electrnicamente entre si. Esta configuracin recibe el nombre de multiproceso y se caracteriza porque permite proceso de datos continuo an en el caso de que surjan problemas de funcionamiento en alguno de las computadoras. Un ejemplo de este tipo de Sistema se muestra en la figura 6.3. ste es un modelo sencillo de un Sistema de control de trfico areo. Un conjunto de sensores distribuidos recolecta la informacin del flujo de trfico y la procesa localmente antes de enviarla al cuarto de control. Los operadores toman decisiones utilizando esta informacin y dan instrucciones a un proceso de control de diversas luces de trfico. En este ejemplo existen varios procesos lgicos para administrar los sensores, el cuarto de control y las luces de trfico. Estos procesos lgicos son procesos sencillos a un grupo de procesos. En este ejemplo se ejecutan en procesadores diferentes. Los Sistemas de Software compuestos de procesos mltiples no necesariamente son Sistemas distribuidos. Si ms de un procesador est disponible, entonces se puede implementar la distribucin, pero los diseadores del Sistema no siempre consideran lo puntos de distribucin durante el proceso de diseo. El enfoque de diseo para este tipo de Sistemas es esencialmente el mismo que para los de tiempo real. Ventajas Es econmica. El uso de componentes comnmente disponibles, en grandes cantidades, permite ofrecer mayor rendimiento, a un precio menor que el de mquinas con procesadores especialmente diseados (como por ejemplo las mquinas de procesadores vectoriales y de propsito especfico). Adicionalmente, las computadoras paralelas son inherentemente escalables, permitiendo actualizarlas para adecuarlas a una necesidad creciente. Las arquitecturas tradicionales se actualizan haciendo los procesadores existentes obsoletos por la introduccin de nueva tecnologa a un costo posiblemente elevado. Por otro lado, una arquitectura paralela se puede actualizar en trminos de rendimiento simplemente agregando ms procesadores. Desventajas En ocasiones se menciona tambin la limitante fsica; existen factores que limitan la velocidad mxima de un procesador, independientemente del factor econmico.
Elaborados por:
Pg. 111
INSTITUTO TECNOLGICO DE JIQUILPAN Apuntes de Fundamentos de Desarrollo de Sistemas Ingeniera en Sistemas Computacionales Plan 2004
Barreras fsicas infranqueables, tales como la velocidad de la luz, efectos cunticos al reducir el tamao de los elementos de los procesadores, y problemas causados por fenmenos elctricos a pequeas escalas, restringen la capacidad mxima de un Sistema Uniprocesador, dejando la opcin obvia de colocar muchos procesadores para realizar clculos cooperativamente.
6.2.2 Diseo 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. Es una forma de dividir las responsabilidades de un Sistema de informacin separando la interfaz del usuario de la gestin de la informacin. El funcionamiento bsico de este modelo consiste en que un programa cliente realiza peticiones a un programa servidor, y espera hasta que el servidor de respuesta. Caractersticas de un cliente En la arquitectura C/S el remitente de una solicitud es conocido como cliente. Sus caractersticas son: Es quien inicia solicitudes o peticiones, tienen por tanto un papel activo en la comunicacin (dispositivo maestro o amo). Espera y recibe las respuestas del servidor. Por lo general, puede conectase a varios servidores a la vez. Normalmente interacta directamente con los usuarios finales mediante una interfaz grfica de usuario.
Caractersticas de un servidor En los Sistemas C/S el receptor de la solicitud enviada por cliente se conoce como servidor. Sus caractersticas son: Al iniciarse esperan a que lleguen las solicitudes de los clientes, desempean entonces un papel pasivo en la comunicacin (dispositivo esclavo). Tras la recepcin de una solicitud, la procesan y luego envan la respuesta al cliente. Por lo general, aceptan conexiones desde un gran nmero de clientes (en ciertos casos el nmero mximo de peticiones puede estar limitado). No es frecuente que interacten directamente con los usuarios finales. Ventajas. Centralizacin del control: Los accesos, recursos y la integridad de los datos son controlados por el servidor de forma que un programa cliente defectuoso o no autorizado no pueda daar el Sistema. Escalabilidad: Se puede aumentar la capacidad de clientes y servidores por separado. Fcil mantenimiento Desventajas. La congestin del trfico (a mayor nmero de clientes, ms problemas para el servidor).
Lic. Martin Valencia Pg. 112
Elaborados por:
INSTITUTO TECNOLGICO DE JIQUILPAN Apuntes de Fundamentos de Desarrollo de Sistemas Ingeniera en Sistemas Computacionales Plan 2004
El Software y el Hardware de un servidor son generalmente muy determinantes. Un Hardware regular de un ordenador personal puede no poder servir a cierta cantidad de clientes. Normalmente se necesita Software y Hardware especfico, sobre todo en el lado del servidor, para satisfacer el trabajo. Por supuesto, esto aumentar el costo
6.2.3 Diseo de Software Distribuido Introduccin. Un sistema distribuido se define como una coleccin de computadores autnomos conectados por una red, y con el software distribuido adecuado para que el sistema sea visto por los usuarios como una nica entidad capaz de proporcionar facilidades de computacin. [ Colouris 1994 ] El desarrollo de los sistemas distribuidos vino de la mano de las redes locales de alta velocidad a principios de 1970. Ms recientemente, la disponibilidad de computadoras personales de altas prestaciones, estaciones de trabajo y ordenadores servidores ha resultado en un mayor desplazamiento hacia los sistemas distribuidos en detrimento de los ordenadores centralizados multiusuario. Esta tendencia se ha acelerado por el desarrollo de software para sistemas distribuidos, diseado para soportar el desarrollo de aplicaciones distribuidas. Este software permite a los ordenadores coordinar sus actividades y compartir los recursos del sistema - hardware, software y datos. Los sistemas distribuidos se implementan en diversas plataformas hardware, desde unas pocas estaciones de trabajo conectadas por una red de rea local, hasta Internet, una coleccin de redes de rea local y de rea extensa interconectados, que en lazan millones de ordenadores. Las aplicaciones de los sistemas distribuidos varan desde la provisin de capacidad de computo a grupos de usuarios, hasta sistemas bancarios, comunicaciones multimedia y abarcan prcticamente todas las aplicaciones comerciales y tcnicas de los ordenadores. Los requisitos de dichas aplicaciones incluyen un alto nivel de fiabilidad, seguridad contra interferencias externas y privacidad de la informacin que el sistema mantiene. Se deben proveer accesos concurrentes a bases de datos por parte de muchos usuarios, garantizar tiempos de respuesta, proveer puntos de acceso al servicio que estn distribuidos geogrficamente, potencial para el crecimiento del sistema para acomodar la expansin del negocio y un marco para la integracin de sistema usados por diferentes compaas y organizaciones de usuarios. Caractersticas clave de los sistemas distribuidos. [Colouris 1994] establece que son seis las caractersticas principales responsables de la utilidad de los sistemas distribuidos. Se trata de comparticin de recursos, apertura (openness), concurrencia, escalabilidad, tolerancia a fallos y transparencia. En las siguientes lneas trataremos de abordar cada una de ellas. Comparticin de Recursos. El trmino 'recurso' es bastante abstracto, pero es el que mejor caracteriza el abanico de entidades que pueden compartirse en un sistema distribuido. El abanico se extiende desde componentes hardware como discos e impresoras hasta elementos software como ficheros, ventanas, bases de datos y otros objetos de datos.
Elaborados por: Lic. Martin Valencia Pg. 113
INSTITUTO TECNOLGICO DE JIQUILPAN Apuntes de Fundamentos de Desarrollo de Sistemas Ingeniera en Sistemas Computacionales Plan 2004
La idea de comparticin de recursos no es nueva ni aparece en el marco de los sistemas distribuidos. Los sistemas multiusuario clsicos desde siempre han provisto comparticin de recursos entre sus usuarios. Sin embargo, los recursos de una computadora multiusuario se comparten de manera natural entre todos sus usuarios. Por el contrario, los usuarios de estaciones de trabajo monousuario o computadoras personales dentro de un sistema distribuido no obtienen automticamente los beneficios de la comparticin de recursos. Los recursos en un sistema distribuido estn fsicamente encapsulados en una de las computadoras y slo pueden ser accedidos por otras computadoras mediante las comunicaciones (la red). Para que la comparticin de recursos sea efectiva, sta debe ser manejada por un programa que ofrezca un interfaz de comunicacin permitiendo que el recurso sea accedido, manipulado y actualizado de una manera fiable y consistente. Surge el trmino genrico de gestor de recursos. Un gestor de recursos es un mdulo software que maneja un conjunto de recursos de un tipo en particular. Cada tipo de recurso requiere algunas polticas y mtodos especficos junto con requisitos comunes para todos ellos. stos incluyen la provisin de un esquema de nombres para cada clase de recurso, permitir que los recursos individuales sean accedidos desde cualquier localizacin; la traslacin de nombre de recurso a direcciones de comunicacin y la coordinacin de los accesos concurrentes que cambian el estado de los recursos compartidos para mantener la consistencia. Un sistema distribuido puede verse de manera abstracta como un conjunto de gestores de recursos y un conjunto de programas que usan los recursos. Los usuarios de los recursos se comunican con los gestores de los recursos para acceder a los recursos compartidos del sistema. Esta perspectiva nos lleva a dos modelos de sistemas distribuidos: el modelo cliente-servidor y el modelo basado en objetos. Apertura (opennesss). Un sistema informtico es abierto si el sistema puede ser extendido de diversas maneras. Un sistema puede ser abierto o cerrado con respecto a extensiones hardware (aadir perifricos, memoria o interfaces de comunicacin, etc... ) o con respecto a las extensiones software ( aadir caractersticas al sistema operativo, protocolos de comunicacin y servicios de comparticin de recursos, etc... ). La apertura de los sistemas distribuidos se determina primariamente por el grado hacia el que nuevos servicios de comparticin de recursos se pueden aadir sin perjudicar ni duplicar a los ya existentes. Bsicamente los sistemas distribuidos cumplen una serie de caractersticas: 1. Los interfaces software clave del sistema estn claramente especificados y se ponen a disposicin de los desarrolladores. En una palabra, los interfaces se hacen pblicos. 2. Los sistemas distribuidos abiertos se basan en la provisin de un mecanismo uniforme de comunicacin entre procesos e interfaces publicados para acceder a recursos compartidos. 3. Los sistemas distribuidos abiertos pueden construirse a partir de hardware y software heterogneo, posiblemente proveniente de vendedores diferentes. Pero la conformidad de cada componente con el estndar publicado debe ser cuidadosamente comprobada y certificada si se quiere evitar tener problemas de integracin. Concurrencia. Cuando existen varios procesos en una nica maquina decimos que se estn ejecutando concurrentemente. Si el ordenador est equipado con un nico procesador central, la concurrencia tiene lugar entrelazando la
Elaborados por: Lic. Martin Valencia Pg. 114
INSTITUTO TECNOLGICO DE JIQUILPAN Apuntes de Fundamentos de Desarrollo de Sistemas Ingeniera en Sistemas Computacionales Plan 2004
ejecucin de los distintos procesos. Si la computadora tiene N procesadores, entonces se pueden estar ejecutando estrictamente a la vez hasta N procesos. En los sistemas distribuidos hay muchas mquinas, cada una con uno o ms procesadores centrales. Es decir, si hay M ordenadores en un sistema distribuido con un procesador central cada una entonces hasta M procesos estar ejecutndose en paralelo. En un sistema distribuido que est basado en el modelo de comparticin de recursos, la posibilidad de ejecucin paralela ocurre por dos razones: 1. Muchos usuarios interactan simultneamente con programas de aplicacin. 2. Muchos procesos servidores se ejecutan concurrentemente, cada uno respondiendo a diferentes peticiones de los procesos clientes. El caso (1) es menos conflictivo, ya que normalmente las aplicaciones de interaccin se ejecutan aisladamente en la estacin de trabajo del usuario y no entran en conflicto con las aplicaciones ejecutadas en las estaciones de trabajo de otros usuarios. El caso (2) surge debido a la existencia de uno o ms procesos servidores para cada tipo de recurso. Estos procesos se ejecutan en distintas mquinas, de manera que se estn ejecutando en paralelo diversos servidores, junto con diversos programas de aplicacin. 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 mltiples instancias del proceso gestor de recursos. Cuando esto ocurre los procesos servidores deben sincronizar sus acciones para asegurarse de que no existen conflictos. La sincronizacin debe ser cuidadosamente planeada para asegurar que no se pierden los beneficios de la concurrencia. Escalabilidad. Los sistemas distribuidos operan de manera efectiva y eficiente a muchas escalas diferentes. La escala ms pequea consiste en dos estaciones de trabajo y un servidor de ficheros, mientras que un sistema distribuido construido alrededor de una red de rea local simple podra contener varios cientos de estaciones de trabajo, varios servidores de ficheros, servidores de impresin y otros servidores de propsito especfico. A menudo se conectan varias redes de rea local para formar internet, y stas podran contener muchos miles de ordenadores que forman un nico sistema distribuido, permitiendo que los recursos sean compartidos entre todos ellos. Tanto el software de sistema como el de aplicacin no deberan cambiar cuando la escala del sistema se incrementa. La necesidad de escalabilidad no es solo un problema de prestaciones de red o de hardware, sino que est ntimamente ligada con todos los aspectos del diseo de los sistemas distribuidos. El diseo del sistema debe reconocer explcitamente la necesidad de escalabilidad o de lo contrario aparecern serias limitaciones. La demanda de escalabilidad en los sistemas distribuidos ha conducido a una filosofa de diseo en que cualquier recurso simple -hardware o software- puede extenderse para proporcionar servicio a tantos usuarios como se quiera. Esto es, si la demanda de un recurso crece, debera ser posible extender el sistema para darla servicio. Por ejemplo, la frecuencia con la que se accede a los ficheros crece cuando se incrementa el nmero de usuarios y estaciones de trabajo en un sistema distribuido. Entonces, debe ser posible aadir ordenadores servidores para evitar el cuello de botella que se producira si un solo servidor
Elaborados por: Lic. Martin Valencia Pg. 115
INSTITUTO TECNOLGICO DE JIQUILPAN Apuntes de Fundamentos de Desarrollo de Sistemas Ingeniera en Sistemas Computacionales Plan 2004
de ficheros tuviera que manejar todas las peticiones de acceso a los ficheros. En este caso el sistema deber estar diseado de manera que permita trabajar con ficheros replicados en distintos servidores, con las consideraciones de consistencias que ello conlleva. Cuando el tamao y complejidad de las redes de ordenadores crece, es un objetivo primordial disear software de sistema distribuido que seguir siendo eficiente y til con esas nuevas configuraciones de la red. Resumiendo, el trabajo necesario para procesar una peticin simple para acceder a un recurso compartido debera ser prcticamente independiente del tamao de la red. Las tcnicas necesarias para conseguir estos objetivos incluyen el uso de datos replicados, la tcnica asociada de caching, y el uso de mltiples servidores para manejar ciertas tareas, aprovechando la concurrencia para permitir una mayor productividad. Una explicacin completa de estas tcnicas puede encontrarse en [ Colouris 1994 ]. Tolerancia a Fallos. Los sistemas informticos a veces fallan. Cuando se producen fallos en el software o en el hardware, los programas podran producir resultados incorrectos o podran pararse antes de terminar la computacin que estaban realizando. El diseo de sistemas tolerantes a fallos se basa en dos cuestiones, complementarias entre s: Redundancia hardware (uso de componentes redundantes) y recuperacin del software (diseo de programas que sean capaces de recuperarse de los fallos). En los sistemas distribuidos la redundancia puede plantearse en un grano ms fino que el hardware, pueden replicarse los servidores individuales que son esenciales para la operacin continuada de aplicaciones crticas. La recuperacin del software tiene relacin con el diseo de software que sea capaz de recuperar (rollback) el estado de los datos permanentes antes de que se produjera el fallo. Los sistemas distribuidos tambin proveen un alto grado de disponibilidad en la vertiente de fallos hardware. La disponibilidad de un sistema es una medida de la proporcin de tiempo que est disponible para su uso. Un fallo simple en una maquina multiusuario resulta en la no disponibilidad del sistema para todos los usuarios. Cuando uno de los componentes de un sistema distribuidos falla, solo se ve afectado el trabajo que estaba realizando el componente averiado. Un usuario podra desplazarse a otra estacin de trabajo; un proceso servidor podra ejecutarse en otra mquina. Transparencia. La transparencia se define como la ocultacin al usuario y al programador de aplicaciones de la separacin de los componentes de un sistema distribuido, de manera que el sistema se percibe como un todo, en vez de una coleccin de componentes independientes. La transparencia ejerce una gran influencia en el diseo del software de sistema. El manual de referencia RM-ODP [ISO 1996a] identifica ocho formas de transparencia. Estas proveen un resumen til de la motivacin y metas de los sistemas distribuidos. Las transparencias definidas son:
Transparencia de Acceso: Permite el acceso a los objetos de informacin remotos de la misma forma que a los objetos de informacin locales.
Lic. Martin Valencia Pg. 116
Elaborados por:
INSTITUTO TECNOLGICO DE JIQUILPAN Apuntes de Fundamentos de Desarrollo de Sistemas Ingeniera en Sistemas Computacionales Plan 2004
Transparencia de Localizacin: Permite el acceso a los objetos de informacin sin conocimiento de su localizacin Transparencia de Concurrencia: Permite que varios procesos operen concurrentemente utilizando objetos de informacin compartidos y de forma que no exista interferencia entre ellos. Transparencia de Replicacin: Permite utilizar mltiples instancias de los objetos de informacin para incrementar la fiabilidad y las prestaciones sin que los usuarios o los programas de aplicacin tengan por que conoces la existencia de las rplicas. Transparencia de Fallos: Permite a los usuarios y programas de aplicacin completar sus tareas a pesar de la ocurrencia de fallos en el hardware o en el software. Transparencia de Migracin: Permite el movimiento de objetos de informacin dentro de un sistema sin afectar a los usuarios o a los programas de aplicacin. Transparencia de Prestaciones: Permite que el sistema sea reconfigurado para mejorar las prestaciones mientras la carga varia. Transparencia de Escalado: Permite la expansin del sistema y de las aplicaciones sin cambiar la estructura del sistema o los algoritmos de la aplicacin.
Las dos ms importantes son las transparencias de acceso y de localizacin; su presencia o ausencia afecta fuertemente a la utilizacin de los recursos distribuidos. A menudo se las denomina a ambas transparencias de red. La transparencia de red provee un grado similar de anonimato en los recursos al que se encuentra en los sistemas centralizados.
6.2.4 Diseo de Software de Tiempo Real. El Software de tiempo real est muy acoplado con el mundo externo, esto es, el Software de tiempo real debe responder al mbito del problema en un tiempo dictado por el mbito del problema. Debido a que el Software de tiempo real debe operar bajo restricciones de rendimiento muy rigurosas, el diseo del Software esta conducido frecuentemente, tanto por la arquitectura del Hardware como por la del Software, por las caractersticas del Sistema operativo, por los requisitos de la aplicacin y tanto por los extras del lenguaje de programacin como prospectos de diseo. La computadora digital se ha convertido en una maquina omnipresente en al vida diaria de todos nosotros. Las computadoras nos permiten ver juegos, as como contar el tiempo, optimizar el gasto de gasolina de nuestras ltimas generaciones de coches y programar a nuestros aparatos. Todas estas interacciones con las computadoras sean tiles o intrusivas son ejemplos de computacin de tiempo real. La computadora est controlando algo que interacta con la realidad sobre una base de tiempo de hecho, el tiempo es la esencia de la interaccin Las computadoras se utilizan para controlar una amplia variedad de sistemas que van desde mquinas domsticas sencillas hasta plantas enteras de fabricacin. El software de dichos tiemporeal por a sistemas es software de
el
Elaborados por:
Pg. 117
INSTITUTO TECNOLGICO DE JIQUILPAN Apuntes de Fundamentos de Desarrollo de Sistemas Ingeniera en Sistemas Computacionales Plan 2004
Sistema
software de del
Elaborados por:
Pg. 118
INSTITUTO TECNOLGICO DE JIQUILPAN Apuntes de Fundamentos de Desarrollo de Sistemas Ingeniera en Sistemas Computacionales Plan 2004
Es un sistema cuyo funcionamiento se degrada si los resultados no se producen de acuerdo con los requerimientos temporales especificados.
Elaborados por:
Pg. 119
INSTITUTO TECNOLGICO DE JIQUILPAN Apuntes de Fundamentos de Desarrollo de Sistemas Ingeniera en Sistemas Computacionales Plan 2004
Es
un sistema resultados no
se
Elaborados por:
Pg. 120
INSTITUTO TECNOLGICO DE JIQUILPAN Apuntes de Fundamentos de Desarrollo de Sistemas Ingeniera en Sistemas Computacionales Plan 2004
Una respuesta a tiempo es un factor importante en todos los necesaria sistemas embebidos, una respuesta muy rpida. pero, en algunos casos, no es
Elaborados por:
Pg. 121
INSTITUTO TECNOLGICO DE JIQUILPAN Apuntes de Fundamentos de Desarrollo de Sistemas Ingeniera en Sistemas Computacionales Plan 2004
1.
Estmulos
peridicos.- Ocurren
2.
Elaborados por:
Pg. 122
INSTITUTO TECNOLGICO DE JIQUILPAN Apuntes de Fundamentos de Desarrollo de Sistemas Ingeniera en Sistemas Computacionales Plan 2004
Un sistema de tiempo real tiene que responder a estmulos que ocurren en diferentes instantes de tiempo.
procesos
concurrentes que
Pg. 123
INSTITUTO TECNOLGICO DE JIQUILPAN Apuntes de Fundamentos de Desarrollo de Sistemas Ingeniera en Sistemas Computacionales Plan 2004
Los
lenguajes
de
programacin desarrollados al la
para sistemas de tiempo real tienen que incluir facilidades para acceder hardware del sistema, y debera ser posible predecir duracin de operaciones particulares realizadas en estos lenguajes.
Elaborados por:
Pg. 124
INSTITUTO TECNOLGICO DE JIQUILPAN Apuntes de Fundamentos de Desarrollo de Sistemas Ingeniera en Sistemas Computacionales Plan 2004
sistema software
tie
Elaborados por:
Pg. 125
INSTITUTO TECNOLGICO DE JIQUILPAN Apuntes de Fundamentos de Desarrollo de Sistemas Ingeniera en Sistemas Computacionales Plan 2004
Los eventos (estmulos) deberan ser elementos centrales del proceso de diseo de software de tiempo real en lugar de los objetos o funciones.
Elaborados por:
Pg. 126
INSTITUTO TECNOLGICO DE JIQUILPAN Apuntes de Fundamentos de Desarrollo de Sistemas Ingeniera en Sistemas Computacionales Plan 2004
1.
2.
3.
4.
5.
Elaborados por:
Pg. 127
INSTITUTO TECNOLGICO DE JIQUILPAN Apuntes de Fundamentos de Desarrollo de Sistemas Ingeniera en Sistemas Computacionales Plan 2004
6.
Elaborados por:
Pg. 128
INSTITUTO TECNOLGICO DE JIQUILPAN Apuntes de Fundamentos de Desarrollo de Sistemas Ingeniera en Sistemas Computacionales Plan 2004
El
orden de
estas
actividades de de
en
el
Elaborados por:
Pg. 129
INSTITUTO TECNOLGICO DE JIQUILPAN Apuntes de Fundamentos de Desarrollo de Sistemas Ingeniera en Sistemas Computacionales Plan 2004
Los
procesos
en
un
sistema
de
tiempo real
Elaborados por:
Pg. 130
INSTITUTO TECNOLGICO DE JIQUILPAN Apuntes de Fundamentos de Desarrollo de Sistemas Ingeniera en Sistemas Computacionales Plan 2004
El
anlisis
temporal
para
sistemas
de
tiempo
real es difcil.
Elaborados por:
Pg. 131
INSTITUTO TECNOLGICO DE JIQUILPAN Apuntes de Fundamentos de Desarrollo de Sistemas Ingeniera en Sistemas Computacionales Plan 2004
que
tienen lugar a
intervalos
Elaborados por:
Pg. 132
INSTITUTO TECNOLGICO DE JIQUILPAN Apuntes de Fundamentos de Desarrollo de Sistemas Ingeniera en Sistemas Computacionales Plan 2004
Estos eventos
(o
estmulos)
menudo
hacen
que el sistema cambie a un estado diferente, por esta razn, el modelado de mquina de estados se utiliza a menudo para modelar sistemas de tiempo real.
Elaborados por:
Pg. 133
INSTITUTO TECNOLGICO DE JIQUILPAN Apuntes de Fundamentos de Desarrollo de Sistemas Ingeniera en Sistemas Computacionales Plan 2004
Un que,
modelo
de
estadosde
un
sistema
en cualquier momento, el sistema est varios estadosposibles. Cuando se recibe puede producir una transicin a un estado diferente.
ste
Elaborados por:
Pg. 134
INSTITUTO TECNOLGICO DE JIQUILPAN Apuntes de Fundamentos de Desarrollo de Sistemas Ingeniera en Sistemas Computacionales Plan 2004
Todos los sistemas de tiempo real, incluso hasta lossistemas embebidos trabajan hoy en da conjuntamente con operativo de tiempo real (RTOS)
ms un
sencillos, sistema
Elaborados por:
Pg. 135
INSTITUTO TECNOLGICO DE JIQUILPAN Apuntes de Fundamentos de Desarrollo de Sistemas Ingeniera en Sistemas Computacionales Plan 2004
Un los
sistema
operativo
de
tiempo real
procesos y asignacin de recursos tiempo real. Lanza y detiene los estmulos puedan ser manejados y recursos del procesador.
Elaborados por:
Pg. 136
INSTITUTO TECNOLGICO DE JIQUILPAN Apuntes de Fundamentos de Desarrollo de Sistemas Ingeniera en Sistemas Computacionales Plan 2004
Los
componentes de
un
tamaoy
complejidad del
Elaborados por:
Pg. 137
INSTITUTO TECNOLGICO DE JIQUILPAN Apuntes de Fundamentos de Desarrollo de Sistemas Ingeniera en Sistemas Computacionales Plan 2004
1.
Un
2.
Un
manejador de interrupciones
3.
Un
planificador
4.
Un
gestor de recursos
5.
Un
despachador
Elaborados por:
Pg. 138
INSTITUTO TECNOLGICO DE JIQUILPAN Apuntes de Fundamentos de Desarrollo de Sistemas Ingeniera en Sistemas Computacionales Plan 2004
un
sistema
operativo
de
Elaborados por:
Pg. 139
INSTITUTO TECNOLGICO DE JIQUILPAN Apuntes de Fundamentos de Desarrollo de Sistemas Ingeniera en Sistemas Computacionales Plan 2004
Los
de que y llevan
monitorizacin y control comprueban los proporcionan informacin sobre el entorno a cabo acciones dependiendo de
del la
Elaborados por:
Pg. 140
INSTITUTO TECNOLGICO DE JIQUILPAN Apuntes de Fundamentos de Desarrollo de Sistemas Ingeniera en Sistemas Computacionales Plan 2004
Los
sistemas
de
monitorizacin
realizan
una
accin cuando se detecta algn valor excepcional del sensor. Los sistemas de control controlan continuamentelos actuadores hardware dependiendo del valor de los sensores asociados.
Elaborados por:
Pg. 141
INSTITUTO TECNOLGICO DE JIQUILPAN Apuntes de Fundamentos de Desarrollo de Sistemas Ingeniera en Sistemas Computacionales Plan 2004
El
proceso
de
diseo comienza
identificando
Elaborados por:
Pg. 142
INSTITUTO TECNOLGICO DE JIQUILPAN Apuntes de Fundamentos de Desarrollo de Sistemas Ingeniera en Sistemas Computacionales Plan 2004
Los
sistemas para
de su
recogen datos de
sensores
Elaborados por:
Pg. 143
INSTITUTO TECNOLGICO DE JIQUILPAN Apuntes de Fundamentos de Desarrollo de Sistemas Ingeniera en Sistemas Computacionales Plan 2004
Los
sistemas
de
adquisicin
de
datos se
normalmente en experimentos cientficos procesos en los que los procesos reaccin qumica, ocurren muy rpidamente.
Elaborados por:
Pg. 144
INSTITUTO TECNOLGICO DE JIQUILPAN Apuntes de Fundamentos de Desarrollo de Sistemas Ingeniera en Sistemas Computacionales Plan 2004
En
los
sistemas
de
adquisicin
de
generando datos muy rpidamente, el asegurar que una lectura del sensor es recogida antes.
Elaborados por:
Pg. 145
INSTITUTO TECNOLGICO DE JIQUILPAN Apuntes de Fundamentos de Desarrollo de Sistemas Ingeniera en Sistemas Computacionales Plan 2004
Puntos clave
Un
los
de que real. se
tiempo
un eventos de en
Elaborados por:
Pg. 146
INSTITUTO TECNOLGICO DE JIQUILPAN Apuntes de Fundamentos de Desarrollo de Sistemas Ingeniera en Sistemas Computacionales Plan 2004
Un
modelo
generalpara
la
arquitectura
sistemas de tiempo real implica el dispositivo sensor y actuador. Tambin procesos adicionales de coordinacin.
Elaborados por:
Pg. 147
INSTITUTO TECNOLGICO DE JIQUILPAN Apuntes de Fundamentos de Desarrollo de Sistemas Ingeniera en Sistemas Computacionales Plan 2004
El
diseo arquitectnico de
un
sistema
de del sistema
Elaborados por:
Pg. 148
INSTITUTO TECNOLGICO DE JIQUILPAN Apuntes de Fundamentos de Desarrollo de Sistemas Ingeniera en Sistemas Computacionales Plan 2004
Un
sistema
operativo
de
tiempo real
responsable del proceso y la gestin de incluye un planificador, que es el componente decidir qu proceso debera seleccionarse para su ejecucin.
Elaborados por:
Pg. 149
INSTITUTO TECNOLGICO DE JIQUILPAN Apuntes de Fundamentos de Desarrollo de Sistemas Ingeniera en Sistemas Computacionales Plan 2004
Los
sistemas
de
monitorizacin
control
consultan peridicamente informacin del entorno del sistema. stos dependiendo de las lecturas de actuadores.
un conjunto de sensores que captan llevan a cabo acciones, los sensores, y envan rdenes a los
Elaborados por:
Pg. 150
INSTITUTO TECNOLGICO DE JIQUILPAN Fundamentos de Desarrollo de Sistemas Ingeniera en Sistemas Computacionales Plan 2004
Los
sistemas
de
adquisicin
de
datos se modelo productor-consumidor. los datos en un consumidos bfer tambin se eliminar los conflictos
organizan
normalmente segn un El proceso productor coloca bfer circular, desde donde son por el proceso consumidor. El implementa como un proceso para entre el productor y el consumidor.
Recopilacin de Informacin:
Pg. 151
INSTITUTO TECNOLGICO DE JIQUILPAN Fundamentos de Desarrollo de Sistemas Ingeniera en Sistemas Computacionales Plan 2004
Hermida, Jorge A. Ciencia de la administracin. Ediciones Contabilidad Moderna S.A.I.C. Buenos Aires mayo de 1983. Alvarez, Hctor Felipe. Administracin, una introduccin al estudio de la Administracin. Sociedad para Estudios Pedaggicos Argentinos. Crdoba 1987. Yourdon, Edward. Anlisis estructurado moderno. Prentice-Hall Panamericana, S.A. Mxico 1989. Ramn Garca-Pelayo y Gross. Pequeo Larousse Ilustrado (diccionario). Ediciones Larousse. Francia 1977. Estructura de las Organizaciones, carpeta del ao 1994 curso 1k8. http://www.um.es/docencia/barzana/IAGP/IAGP2-Ingenieria-Software-introduccion.html
Blog: http://percyreyes.blogspot.com Fecha: 13/Jul/2005 (07/07/2005) Autor: A. Percy Reyes Paredes
Recopilacin de Informacin:
Pg. 152