![UNIDAD I CONCEPTOS INTRODUCTORIOS<br />1.1.Introducción a los sistemas<br />SISTEMA: Conjunto organizado de partesinterdependientes que interactúan entre sí formando un todo unitario y complejo. <br />Descripción general <br />Las partes forman las funciones básicas realizadas por el sistema de las cuales podemos enumerarlas en:<br />Las salidas de un sistema se convierten en entrada de otro, que la procesará para convertirla en otra salida, repitiéndose este ciclo indefinidamente. <br />Tipos<br />Sistemas de Soporte para la Toma de Decisiones (DSS: DecisionSupportSystems): apoyar la toma de decisiones mediante la generación y evaluación sistemática de diferentes alternativas o escenarios de decisión. Un DSS no soluciona problemas, ya que solo apoya al proceso de toma de decisiones. <br />Sistemas de Soporte para la Toma de Decisiones de Grupo (GroupDecisionSupportSystems): cubren el objetivo de lograr la participación de un grupo de personas durante la toma de decisiones en ambientes de anonimato y consenso, apoyando decisiones simultáneas. <br />Sistemas Expertos de Soporte para la Toma de Decisiones (DEss: ExpertDecisionSupprtSystems): permiten cargar bases de conocimiento que se integran por una serie de reglas de sentido común para que diferentes usuarios las consulten, apoyen la toma de decisiones, la capacitación. <br />Sistemas de Información para Ejecutivos (EIS: ExecutiveinformationSystems): están dirigidos a apoyar el proceso de toma de decisiones de los altos ejecutivos de una organización, presentado información relevante y usando recursos visuales de fácil interpretación, con el ejecutivo de mantenerlos informados. <br />Clasificación<br />Abiertos: Son los que intercambian información, materiales y energía con su ambiente. <br />Cerrados: Son auto contenido, no interactúan con el medio ambiente. <br />Probabilístico: No se conoce con certeza su comportamiento. <br />Deterministico: Cualquier estado futuro que adopten puede preciarse con antelación.<br />ciclo de vida de un proyecto de software<br />Definición.- Conjunto de etapas que se han de llevar a cabo para crear, explotar y mantener un Sistema Informático. <br /> <br />Fases del Ciclo <br />1) Definición de requerimientos2) Análisis y diseño del sistema 3) Implementación (codificación)4) Integración y pruebas<br />5) Explotación y mantenimiento <br />1. Definición de requerimientosEstudio detallado de la situación actual del problema a tratar, definición de los requerimientos que debe cumplir el sistema. <br />2. Análisis y diseño del sistemaDescomposición modular de toda la aplicación, descripción detallada de cada uno de los módulos y sus inter-relaciones, todo ello para poder facilitar al máximo la fase de codificación. <br />3. Implementación (codificación)Cada módulo como resultado de la fase anterior es traducido a la herramienta o lenguaje apropiado. <br />4. Integración y pruebasVerificación del correcto funcionamiento de cada módulo y todo el sistema una vez ha sido integrado, detectar errores en la codificación, definiciones de requerimientos y de diseño. <br />5. Explotación y mantenimientoGarantizar el mantenimiento del sistema, corrección de errores detectados en esta fase, adaptación del sistema a nuevos entornos. <br />Expresión de necesidades Esta etapa tiene como objetivo la consecución de un primer documento en que queden reflejados los requerimientos y funcionalidades que ofrecerá al usuario del sistema a desarrollar (qué, y no cómo, se va a desarrollar).<br />Especificaciones<br />Ahora se trata de formalizar los requerimientos; el documento obtenido en la etapa anterior se tomará como punto de partida para esta fase. Su contenido es aún insuficiente y lleno de imprecisiones que será necesario completar y depurar. Análisis Es necesario determinar qué elementos intervienen en el sistema a desarrollar, así como su estructura, relaciones, evolución en el tiempo, detalle de sus funcionalidades. Para ello se enfocará el sistema desde tres puntos de vista relacionados pero diferentes: Diseño Tras la etapa anterior ya se tiene claro que debe hacer el sistema, ahora tenemos que determinar cómo va a hacerlo (¿cómo debe ser construido el sistema?; aquí se definirán en detalle entidades y relaciones de las bases de datos, se pasará de casos de uso esenciales a su definición como casos expandidos reales, se seleccionará el lenguaje más adecuado, el Sistema Gestor de Bases de Datos a utilizar en su caso, librerías, configuraciones hardware, redes). Implementación Llegado este punto se empieza a codificar algoritmos y estructuras de datos, definidos en las etapas anteriores, en el correspondiente lenguaje de programación y/o para un determinado sistema gestor de bases de datos. Funcional. Estático. Dinámico.<br />Pruebas El objetivo de estas pruebas es garantizar que el sistema ha sido desarrollado correctamente, sin errores de diseño y/o programación. Es conveniente que sean planteadas al menos tanto a nivel de cada módulo (aislado del resto), como de integración del sistema (según sea la naturaleza del proyecto en cuestión se podrán tener en cuenta pruebas adicionales, p.ej. de rendimiento).<br />Validación Esta etapa tiene como objetivo la verificación de que el sistema desarrollado cumple con los requisitos expresados inicialmente por el cliente y que han dado lugar al presente proyecto (para esta fase también es interesante contar con los use cases, generados a través de las correspondientes fases previas, que servirán de guía para la verificación de que el sistema cumple con lo descrito por estos).<br />Mantenimiento y evolución.<br />Finalmente la aplicación resultante se encuentra ya en fase de producción (en funcionamiento para el cliente, cumpliendo ya los objetivos para los que ha sido creada). A partir de este momento se entra en la etapa de mantenimiento, que supondrá ya pequeñas operaciones tanto de corrección como de mejora de la aplicación (p.ej. mejora del rendimiento), así como otras de mayor importancia, fruto de la propia evolución (p.ej. nuevas opciones para el usuario debidas a nuevas operaciones contempladas para el producto). <br />1.2.1 Planificación y gestión del proyecto <br />La gestión de proyectos busca las técnicas necesarias para planificar, organizar, supervisar y controlar proyectos de software. El objetivo de gestionar proyectos es tener un producto de alta calidad. Cuando se planifica un proyecto se tiene que obtener estimaciones del costo y esfuerzo humano requerido por medio de las mediciones de software que se utilizan para recolectar los datos cualitativos acerca del software y sus procesos para aumentar su calidad. La gestión de un proyecto de software se centra en tres partes como son: Personal, Problema, Proceso.<br />-Personal: El factor humano es importante en la ingeniería de software. (Es importante tener la capacidad de gestión del personal con el fin de aumentar la preparación en la organización del software). <br />-Problema: Se establecen los objetivos y se deben considerar soluciones alternativas e identificar las dificultades técnicas y de gestión. (Con esta información es posible definir unas estimaciones razonables del costo, una valoración efectiva del riesgo, una subdivisión realista de las tareas del proyecto o una planificación del proyecto asequible que proporcione una indicación fiable del progreso). <br />-Proceso: Proporciona la estructura desde la que se puede establecer un detallado plan para el desarrollo del software. (Las actividades estructurales se pueden aplicar a todos los proyectos de software, sin tener en cuenta su tamaño o complejidad). El proceso de software lo componen participantes que pueden clasificarse en cinco categorías: <br />Gestores superiores: definen los aspectos de negocios que a menudo tienen una significativa influencia en el proyecto. <br />Gestores técnicos del proyecto: deben planificar, organizar y controlar a los profesionales que realizan el trabajo del software. <br />Profesionales: proporcionan las capacidades técnicas para la ingeniería de un producto <br />Clientes: especifica los requisitos para la ingeniería de software. <br />Usuarios finales: interaccionan con el software una vez que se ha entregado para la producción.<br />En la mayoría de los desafíos técnicos, las métricas nos ayudan a entender tanto el proceso técnico que se utiliza para desarrollar un producto, como el propio producto. (El proceso para intentar mejorarlo, el producto se mide para intentar aumentar su calidad).<br />Métricas del software.<br />Existen diferentes métricas están relacionadas con el desarrollo del software para medir su funcionalidad, complejidad, y eficiencia. <br />Métricas técnicas: Se centran en las características de software. (Por ejemplo: la complejidad lógica, el grado de modularidad. Mide la estructura del sistema, el cómo está hecho). <br />Métricas de calidad: proporcionan una indicación de cómo se ajusta el software a los requisitos implícitos y explícitos del cliente. (Es decir cómo voy a medir para que mi sistema se adapte a los requisitos que me pide el cliente).<br />Métricas de productividad: Se centran en el rendimiento del proceso de la ingeniería del software. (Es decir que tan productivo va a ser el software que voy a diseñar). <br />Métricas orientadas a la persona: Proporcionan medidas e información sobre la forma que la gente desarrolla el software de computadoras y sobre todo el punto de vista humano de la efectividad de las herramientas y métodos. (Son las medidas que voy a hacer de mi personal que hará el sistema). <br />Métricas orientadas al tamaño: Es para saber en qué tiempo voy a terminar elsoftware y cuantas personas voy a necesitar. (Son medidas directas al software y el proceso porel cual se desarrolla). <br />1.2.3 Análisis y diseño. <br />El análisis de coste-beneficio es complicado porque los criterios varían según las características del sistema a desarrollar, el tamaño relativo del proyecto y la recuperación esperada de la inversión como parte del plan estratégico de la compañía. Además, muchos beneficios obtenidos de los sistemas basados en computadora son intangibles. <br />Análisis: Es indispensable determinar qué elementos van a intervenir en el sistemas a desarrollar, su estructura, relaciones, evolución a corto o largo plazo, su funcionalidad, los que nos dará una descripción clara de que sistema vamos a desarrollar, qué funcionalidades va a aportar y qué comportamiento va a tener. Es importante realizar un análisis económico y técnico (análisis de costos beneficios), significa una valoración de la inversión económica comparado con los beneficios que se obtendrán en la comercialización y utilidad del producto o sistema. <br />Diseño: Realizada la etapa anterior ya se tiene claro que debe hacer el sistema,ahora tenemos que plantear como va a hacerlo (¿cómo debe ser construido el sistema?;aquí se definirán en detalle entidades y relaciones de las bases de datos, se pasará de casos de uso esenciales a su definición como casos expandidos reales, se<br />seleccionara el lenguaje más adecuado, el Sistema Gestor de Base de Datos a utilizar en un caso, librerías, configuraciones hardware, redes, y demás condiciones para el desarrollo del sistema). Para ello nos enfocamos en cuatro etapas: El diseño de los datos. Trasforma el modelo de dominio de la información, creado durante el análisis, en las estructuras de datos necesarios para implementar el Software. El Diseño Arquitectónico. Define la relación entre cada uno de los elementos estructurales del programa. El Diseño de la Interfaz. Describe como se comunica el Software consigo mismo, con los sistemas que operan junto con él y con los operadores y usuarios que lo emplean. El Diseño de procedimientos. Transforma elementos estructurales de la arquitectura del programa. La importancia del Diseño del Software se puede definir en una sola palabra Calidad. El Diseño es la única manera de materializar con precisión los requerimientos del cliente.<br /> <br />Unidad 2 Introducción a la ingeniería de software.<br />Según la definición del IEEE, citada por [Lewis 1994] \"
software: es la suma total de los programas de computadora, procedimientos, reglas, la documentación asociada y los datos que pertenecen a un sistema de cómputo\"
. Según el mismo autor, \"
un producto de software es un producto diseñado para un usuario\"
. En este contexto, la Ingeniería de Software (SE del inglés Software Engineering): es un enfoque sistemático del desarrollo, operación, mantenimiento y retiro del software\"
, que en palabras más llanas, se considera que \"
la Ingeniería de Software: es la rama de la ingeniería que aplica los principios de la ciencia de la computación y las matemáticas para lograr soluciones costo-efectivas (eficaces en costo o económicas) a los problemas de desarrollo de software\"
, es decir, \"
permite elaborar consistentemente productos correctos, utilizables y costo-efectivos\"
[Cota 1994].<br />El proceso de ingeniería de software: se define como \"
un conjunto de etapas parcialmente ordenadas con la intención de logra un objetivo, en este caso, la obtención de un producto de software de calidad\"
[Jacobson 1998].El proceso de desarrollo de software \"
es aquel en que las necesidades del usuario son traducidas en requerimientos de software, estos requerimientos transformados en diseño y el diseño implementado en código, el código es probado, documentado y certificado para su uso operativo\"
. Concretamente \"
define quién está haciendo qué, cuándo hacerlo y cómo alcanzar un cierto objetivo\"
[Jacobson 1998]. <br />El proceso de desarrollo de software requiere por un lado un conjunto de conceptos, una metodología y un lenguaje propio. A este proceso también se le llama el ciclo de vida del software que comprende cuatro grandes fases: concepción, elaboración, construcción y transición. <br />La concepción: define le alcance del proyecto y desarrolla un caso de negocio. <br />La elaboración: define un plan del proyecto, especifica las características y fundamenta la arquitectura. <br />La construcción: crea el producto y la transición transfiere el producto a los usuarios.<br />Actualmente se encuentra en una etapa de madurez el enfoque Orientado a Objetos (OO) como paradigma del desarrollo de sistemas de información. El Object Management Group (OMG) es un consorcio a nivel internacional que integra a los principales representantes de la industria de la tecnología de información OO. El OMG tiene como objetivo central la promoción, fortalecimiento e impulso de la industria OO. El OMG propone y adopta por consenso especificaciones entorno a la tecnología OO. Una de las especificaciones más importantes es la adopción en 1998 del Lenguaje de Modelado Unificado o UML (del inglés Unified Modeling Language) como un estándar, que junto con el Proceso Unificado están consolidando la tecnología OO.<br />Unidad 4 Modelos de proceso de software.<br />Modelos de proceso software<br />Sommerville [4] define modelo de proceso de software como “Una representación simplificada de un proceso de software, representada desde una perspectiva específica. Por su naturaleza los modelos son simplificados, por lo tanto un modelo de procesos del software es una abstracción de un proceso real.” <br />Los modelos genéricos no son descripciones definitivas de procesos de software; sin embargo, son abstracciones útiles que pueden ser utilizadas para explicar diferentes enfoques del desarrollo de software. <br />Modelos que se van a discutir a continuación:<br />Codificar y corregir<br />Modelo en cascada<br />Desarrollo evolutivo<br />Desarrollo formal de sistemas<br />Desarrollo basado en reutilización<br />Desarrollo incremental<br />Desarrollo en espiral<br />Codificar y corregir (Code-and-Fix)<br />Este es el modelo básico utilizado en los inicios del desarrollo de software. Contiene dos pasos:<br />Escribir código.<br />Corregir problemas en el código.<br />Se trata de primero implementar algo de código y luego pensar acerca de requisitos, diseño, validación, y mantenimiento. <br />Este modelo tiene tres problemas principales:<br />Después de un número de correcciones, el código puede tener una muy mala estructura, hace que los arreglos sean muy costosos. <br />Frecuentemente, aún el software bien diseñado, no se ajusta a las necesidades del usuario, por lo que es rechazado o su reconstrucción es muy cara.<br />El código es difícil de reparar por su pobre preparación para probar y modificar.<br />Modelo en cascada<br />El primer modelo de desarrollo de software que se publicó se derivó de otros procesos de ingeniería [8]. Éste toma las actividades fundamentales del proceso de especificación, desarrollo, validación y evolución y las representa como fases separadas del proceso.<br />El modelo en cascada consta de las siguientes fases:<br />Definición de los requisitos: Los servicios, restricciones y objetivos son establecidos con los usuarios del sistema. Se busca hacer esta definición en detalle.<br />Diseño de software: Se particiona el sistema en sistemas de software o hardware. Se establece la arquitectura total del sistema. Se identifican y describen las abstracciones y relaciones de los componentes del sistema.<br />Implementación y pruebas unitarias: Construcción de los módulos y unidades de software. Se realizan pruebas de cada unidad.<br />Integración y pruebas del sistema: Se integran todas las unidades. Se prueban en conjunto. Se entrega el conjunto probado al cliente.<br />Operación y mantenimiento: Generalmente es la fase más larga. El sistema es puesto en marcha y se realiza la corrección de errores descubiertos. Se realizan mejoras de implementación. Se identifican nuevos requisitos.<br />La interacción entre fases puede observarse en la Figura 5. Cada fase tiene como resultado documentos que deben ser aprobados por el usuario. <br />Una fase no comienza hasta que termine la fase anterior y generalmente se incluye la corrección de los problemas encontrados en fases previas.<br />Figura SEQ Figura \* ARABIC 5: Modelo de desarrollo en cascada.<br />En la práctica, este modelo no es lineal, e involucra varias iteraciones e interacción entre las distintas fases de desarrollo. Algunos problemas que se observan en el modelo de cascada son:<br />Las iteraciones son costosas e implican rehacer trabajo debido a la producción y aprobación de documentos.<br />Aunque son pocas iteraciones, es normal congelar parte del desarrollo y continuar con las siguientes fases.<br />Los problemas se dejan para su posterior resolución, lo que lleva a que estos sean ignorados o corregidos de una forma poco elegante.<br />Existe una alta probabilidad de que el software no cumpla con los requisitos del usuario por el largo tiempo de entrega del producto.<br />Es inflexible a la hora de evolucionar para incorporar nuevos requisitos. Es difícil responder a cambios en los requisitos.<br />Este modelo sólo debe usarse si se entienden a plenitud los requisitos. Aún se utiliza como parte de proyectos grandes.<br />Desarrollo evolutivo<br />La idea detrás de este modelo es el desarrollo de una implantación del sistema inicial, exponerla a los comentarios del usuario, refinarla en N versiones hasta que se desarrolle el sistema adecuado. En la Figura 6 se observa cómo las actividades concurrentes: especificación, desarrollo y validación, se realizan durante el desarrollo de las versiones hasta llegar al producto final.<br />Una ventaja de este modelo es que se obtiene una rápida realimentación del usuario, ya que las actividades de especificación, desarrollo y pruebas se ejecutan en cada iteración.<br />Figura SEQ Figura \* ARABIC 6: Modelo de desarrollo evolutivo.<br />Existen dos tipos de desarrollo evolutivo:<br />Desarrollo Exploratorio: El objetivo de este enfoque es explorar con el usuario los requisitos hasta llegar a un sistema final. El desarrollo comienza con las partes que se tiene más claras. El sistema evoluciona conforme se añaden nuevas características propuestas por el usuario.<br />Enfoque utilizando prototipos: El objetivo es entender los requisitos del usuario y trabajar para mejorar la calidad de los requisitos. A diferencia del desarrollo exploratorio, se comienza por definir los requisitos que no están claros para el usuario y se utiliza un prototipo para experimentar con ellos. El prototipo ayuda a terminar de definir estos requisitos.<br />Entre los puntos favorables de este modelo están:<br />La especificación puede desarrollarse de forma creciente.<br />Los usuarios y desarrolladores logran un mejor entendimiento del sistema. Esto se refleja en una mejora de la calidad del software.<br />Es más efectivo que el modelo de cascada, ya que cumple con las necesidades inmediatas del cliente.<br />Desde una perspectiva de ingeniería y administración se identifican los siguientes problemas:<br />Proceso no Visible: Los administradores necesitan entregas para medir el progreso. Si el sistema se necesita desarrollar rápido, no es efectivo producir documentos que reflejen cada versión del sistema.<br />Sistemas pobremente estructurados: Los cambios continuos pueden ser perjudiciales para la estructura del software haciendo costoso el mantenimiento.<br />Se requieren técnicas y herramientas: Para el rápido desarrollo se necesitan herramientas que pueden ser incompatibles con otras o que poca gente sabe utilizar.<br />Este modelo es efectivo en proyectos pequeños (menos de 100.000 líneas de código) o medianos (hasta 500.000 líneas de código) con poco tiempo para su desarrollo y sin generar documentación para cada versión.<br />Para proyectos largos es mejor combinar lo mejor del modelo de cascada y evolutivo: se puede hacer un prototipo global del sistema y posteriormente reimplementarlo con un acercamiento más estructurado. Los subsistemas con requisitos bien definidos y estables se pueden programar utilizando cascada y la interfaz de usuario se puede especificar utilizando un enfoque exploratorio.<br />Desarrollo formal de sistemas<br />Este modelo se basa en transformaciones formales de los requisitos hasta llegar a un programa ejecutable. <br />Figura SEQ Figura \* ARABIC 7: Paradigma de programación automática.<br />La Figura 7 (obtenida desde [20]) ilustra un paradigma ideal de programación automática. Se distinguen dos fases globales: especificación (incluyendo validación) y transformación. Las características principales de este paradigma son: la especificación es formal y ejecutable constituye el primer prototipo del sistema), la especificación es validada mediante prototipación. Posteriormente, a través de transformaciones formales la especificación se convierte en la implementación del sistema, en el último paso de transformación se obtiene una implementación en un lenguaje de programación determinado. , el mantenimiento se realiza sobre la especificación (no sobre el código fuente), la documentación es generada automáticamente y el mantenimiento es realizado por repetición del proceso (no mediante parches sobre la implementación).<br />Observaciones sobre el desarrollo formal de sistemas:<br />Permite demostrar la corrección del sistema durante el proceso de transformación. Así, las pruebas que verifican la correspondencia con la especificación no son necesarias.<br />Es atractivo sobre todo para sistemas donde hay requisitos de seguridad y confiabilidad importantes.<br />Requiere desarrolladores especializados y experimentados en este proceso para llevarse a cabo.<br />Desarrollo basado en reutilización<br />Como su nombre lo indica, es un modelo fuertemente orientado a la reutilización. Este modelo consta de 4 fases ilustradas en la Figura 9. A continuación se describe cada fase:<br />Análisis de componentes: Se determina qué componentes pueden ser utilizados para el sistema en cuestión. Casi siempre hay que hacer ajustes para adecuarlos.<br />Modificación de requisitos: Se adaptan (en lo posible) los requisitos para concordar con los componentes de la etapa anterior. Si no se puede realizar modificaciones en los requisitos, hay que seguir buscando componentes más adecuados (fase 1).<br />Diseño del sistema con reutilización: Se diseña o reutiliza el marco de trabajo para el sistema. Se debe tener en cuenta los componentes localizados en la fase 2 para diseñar o determinar este marco.<br />Desarrollo e integración: El software que no puede comprarse, se desarrolla. Se integran los componentes y subsistemas. La integración es parte del desarrollo en lugar de una actividad separada.<br />Las ventajas de este modelo son:<br />Disminuye el costo y esfuerzo de desarrollo.<br />Reduce el tiempo de entrega.<br />Disminuye los riesgos durante el desarrollo.<br />Figura SEQ Figura \* ARABIC 8: Desarrollo basado en reutilización de componentes<br />Desventajas de este modelo:<br />Los “compromisos” en los requisitos son inevitables, por lo cual puede que el software no cumpla las expectativas del cliente.<br />Las actualizaciones de los componentes adquiridos no están en manos de los desarrolladores del sistema.<br />Procesos iterativos<br />A continuación se expondrán dos enfoques híbridos, especialmente diseñados para el soporte de las iteraciones:<br />Desarrollo Incremental.<br />Desarrollo en Espiral.<br />Desarrollo incremental<br />Mills [9] sugirió el enfoque incremental de desarrollo como una forma de reducir la repetición del trabajo en el proceso de desarrollo y dar oportunidad de retrasar la toma de decisiones en los requisitos hasta adquirir experiencia con el sistema (ver Figura 10). Es una combinación del Modelo de Cascada y Modelo Evolutivo.<br />Reduce el rehacer trabajo durante el proceso de desarrollo y da oportunidad para retrasar las decisiones hasta tener experiencia en el sistema. <br />Durante el desarrollo de cada incremento se puede utilizar el modelo de cascada o evolutivo, dependiendo del conocimiento que se tenga sobre los requisitos a implementar. Si se tiene un buen conocimiento, se puede optar por cascada, si es dudoso, evolutivo.<br />Figura SEQ Figura \* ARABIC 9: Modelo de desarrollo iterativo incremental.<br />Entre las ventajas del modelo incremental se encuentran:<br />Los clientes no esperan hasta el fin del desarrollo para utilizar el sistema. Pueden empezar a usarlo desde el primer incremento.<br />Los clientes pueden aclarar los requisitos que no tengan claros conforme ven las entregas del sistema.<br />Se disminuye el riesgo de fracaso de todo el proyecto, ya que se puede distribuir en cada incremento.<br />Las partes más importantes del sistema son entregadas primero, por lo cual se realizan más pruebas en estos módulos y se disminuye el riesgo de fallos.<br />Algunas de las desventajas identificadas para este modelo son:<br />Cada incremento debe ser pequeño para limitar el riesgo (menos de 20.000 líneas).<br />Cada incremento debe aumentar la funcionalidad.<br />Es difícil establecer las correspondencias de los requisitos contra los incrementos.<br />Es difícil detectar las unidades o servicios genéricos para todo el sistema.<br />Desarrollo en espiral<br />El modelo de desarrollo en espiral (ver Figura 11) es actualmente uno de los más conocidos y fue propuesto por Boehm [7]. El ciclo de desarrollo se representa como una espiral, en lugar de una serie de actividades sucesivas con retrospectiva de una actividad a otra.<br />Cada ciclo de desarrollo se divide en cuatro fases:<br />Definición de objetivos: Se definen los objetivos. Se definen las restricciones del proceso y del producto. Se realiza un diseño detallado del plan administrativo. Se identifican los riesgos y se elaboran estrategias alternativas dependiendo de estos.<br />Evaluación y reducción de riesgos: Se realiza un análisis detallado de cada riesgo identificado. Pueden desarrollarse prototipos para disminuir el riesgo de requisitos dudosos. Se llevan a cabo los pasos para reducir los riesgos.<br />Desarrollo y validación: Se escoge el modelo de desarrollo después de la evaluación del riesgo. El modelo que se utilizará (cascada, sistemas formales, evolutivo, etc.) depende del riesgo identificado para esa fase.<br />Planificación: Se determina si continuar con otro ciclo. Se planea la siguiente fase del proyecto.<br />Este modelo a diferencia de los otros toma en consideración explícitamente el riesgo, esta es una actividad importante en la administración del proyecto.<br />El ciclo de vida inicia con la definición de los objetivos. De acuerdo a las restricciones se determinan distintas alternativas. Se identifican los riesgos al sopesar los objetivos contra las alternativas. Se evalúan los riesgos con actividades como análisis detallado, simulación, prototipos, etc. Se desarrolla un poco el sistema. Se planifica la siguiente fase.<br />36766522225<br />Modelo de procesoFunciona con requisitos y arquitectura no predefinidosProduce software altamente fiableGestión de riesgosPermite correcciones sobre la marchaVisión del progreso por el Cliente y el Jefe del proyectoCodificar y corregirBajo BajoBajoAltoMedioCascadaBajoAltoBajoBajoBajo EvolutivoexploratorioMedio o AltoMedio o AltoMedio Medio o AltoMedio o AltoEvolutivoprototipadoAltoMedioMedioAltoAltoDesarrollo formal de sistemasBajoAltoBajo a MedioBajoBajoDesarrollo orientado a reutilizaciónMedioBajo a AltoBajo a MedioAltoAltoIncrementalBajoAltoMedioBajoBajoEspiralAltoAltoAltoMedioMedio<br />Unidad 5<br />TÉCNICAS DE RECOPILACIÓN DE INFORMACIÓN <br />Los analistas utilizan una variable de métodos a fin de recopilar los datos sobre una situación existente, como entrevistas, cuestionario, inspección de registros y observación. Cada uno tiene ventajas y desventajas. Generalmente, se utilizan dos o tres para complementar el trabajo de cada una y ayudar a asegurar una investigación completa. A continuación se verán cada una de ellas. <br />E N T R E V I S T A <br />Las entrevistas se utilizan para recabar información en forma verbal, a través de preguntas que propone el analista. Quienes responde pueden ser gerentes o empleados, los cuales son usuarios actuales del sistema, existen usuarios potenciales del sistema propuesto o aquellos que proporcionaran datos o serán afectadas por la aplicación propuesta. El analista puede entrevistar al personal en forma individual o en grupos. <br />Recabar datos mediante la entrevista. <br />La entrevista es una forma de conversación, ¡no interrogación! Al analizar las características de los sistemas con personal seleccionado cuidadosamente por sus conocimientos sobre es sistema los analistas pueden conocerlos datos que no están disponibles en ninguna otra forma. <br />En las investigaciones de sistemas, las formas cualitativas y cuantitativas de la información son importantes. La información cualitativa esta relacionada con opiniones, políticas y descripciones cuantitativas tratan con números, frecuencia o cantidades. A menudo las entrevistas dan la mejor fuente de información cualitativa; los otros métodos tienden a ser mas útiles en la recabación de datos cuantitativos. <br />Mucha gente incapaz de expresarse por escrito puede discutir sus ideas en forma verbal. Como resultado de esto las entrevistas pueden descubrir rápidamente malos entendidos, falsas expectativas o incluso resistencia potencial para las aplicaciones en desarrollo; mas aun a menudo es más fácil calendarizar una entrevista con los gerentes del alto nivel, que pedirles que llenen cuestionarios. <br />Determinación del tipo de entrevista. <br />La estructura de las entrevistas varia. Si el objetivo de la entrevista radica en adquirir información general, es conveniente elaborar una serie de preguntas sin estructura, con una sección de preguntas y respuestas libres. La atmósfera abierta y de fácil flujo de esta modalidad proporciona una mayor oportunidad para conocer las actitudes, ideas y creencias de quien responde. Sin embargo, cuando los analistas necesitan adquirir datos más específicos sobre la aplicación o desean asegurar una alta confiabilidad en las respuestas a las preguntas que han propuesto a sus entrevistados, las entrevistas estructuradas son mejores. <br />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. <br />La confiabilidad es solo una consideración en la selección del método de entrevista. Los analistas también deben dividir su tiempo entre desarrollar preguntas para entrevistas y analizar las respuestas. Las entrevistas no estructuradas requieren menos tiempo de preparación, porque no se necesita tener por anticipado las palabras precisas de las preguntas. Sin embargo, analizar las respuestas después de las entrevistas lleva más tiempo que con las entrevistas estructuradas. De cualquier manera, el mayor costo radica en la preparación, administración y análisis de las entrevistas estructuradas para preguntas cerradas. <br />Dado que un numero de personas se seleccionara para la entrevista, los analistas deben tener cuidado de incluir aquellas personas que tienen información que no se podrá conseguir de otra forma. Durante las primeras etapas de un estudio de sistemas, cuando los analistas determinan <br />La factibilidad del proyecto, con frecuencia las entrevistas solo se aplican a la gerencia o personal de supervisión. Sin embargo, durante la investigación detallada en donde el objetivo es descubrir hechos específicos, opiniones y conocer como se manejan las operaciones desempeñadas actualmente, las entrevistas se aplican en todos los niveles gerenciales y de empleados y dependen de quien pueda proporcionar la mayor parte de la información útil para el estudio. Así, los analistas que estudian ala administración de inventarios pueden entrevistar a los trabajadores del embarque y de recepción, al personal del almacén y a los supervisores de los diferentes turnos, es decir, aquellas personas que realmente trabajan en el almacén; también entrevistaran a los agentes más importantes. <br />Realización de la entrevista. <br />La habilidad del entrevistador es vital para el éxito en la búsqueda de hechos por medio de la entrevista. Las buenas entrevistas dependen del conocimiento del analista tanto de la preparación del objetivo de una entrevista especifica como de las preguntas por realizar a una persona determinada. <br />El tacto, la imparcialidad e incluso la vestimenta apropiada ayudan a asegurar una entrevista exitosa. La falta de estos factores puede reducir cualquier oportunidad de éxito. Por ejemplo, un analista que trabaja en la aplicación enfocada a la reducción de errores probablemente no tendría éxito si llegar a una oficina de gerencia de nivel medio con la presentación equivocada, por ejemplo, si dijera, “hola, fui enviado para encontrar una forma de mojar el rendimiento y de reducir los errores que presentan aquí. O la introducción: “Estamos aquí para resolver su problema”, es igualmente mala. Es imaginable la rapidez con la que va a responder ser irrita y se molesta con un enfoque de este tipo. <br />A través de la entrevista, los analistas deben preguntarse así mismos las siguientes interrogantes: <br />¿Qué es lo que me esta diciendo la persona? <br />¿Por qué me lo esta diciendo a mí? <br />¿Qué se esta olvidando? <br />¿Qué espera esta persona que haga yo? <br />Si se considera cada elemento de la información contra estas preguntas, los analistas tendrán mas conocimientos no solamente de la información adquirida sino también de su importancia. <br />C U E S T I O N A R I O . <br />Los cuestionarios proporcionan una alternativa muy útil para las entrevistas; sin embargo, existen ciertas características que pueden ser apropiadas en algunas situaciones e inapropiadas en otras. <br />Recabación de datos mediante cuestionarios <br />Para los analistas los cuestionarios pueden ser la única forma posible de relacionarse con un gran numero de personas para conocer varios aspectos del sistema. Cuando se llevan a cabo largos estudios en varios departamentos, se puede distribuir los cuestionarios a todas las personas apropiadas para recabar hechos con relación al sistema. Por supuesto, no es posible observar las expresiones o relaciones de quienes responden a los cuestionarios. <br />También las preguntas estandarizadas pueden proporcionar datos más confiables. Por otra parte, las características anteriores también son desventajas de los cuestionarios. Aunque su aplicación puede realizarse con un mayor numero de individuos, es muy rara una respuesta total. Puede necesitarse algún seguimiento de los cuestionarios para motivar al personal que responda; todas las respuestas se encontraran en una proporción entre el 25 o 35%, que es lo más común. <br />Selección de formas para cuestionarios. <br />El desarrollo y distribución de los cuestionarios es caro; por lo tanto, el tiempo invertido en esto debe utilizarse en una forma inteligente. También es importante el formato y contenido de las preguntas en la recopilación de hechos significativos. <br />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. <br />Cuestionarios abiertos. <br />Al igual, que las entrevistas, los cuestionarios pueden ser abiertos y se aplican cuando se quieren conocer los sentimientos, opiniones y experiencias generales; también son útiles al explorar el problema básico, por ejemplo, un analista que utiliza cuestionarios para estudiar los métodos de verificación de crédito, en un medio ambiente de ventas al a menudeo, podría recabar mas información provechosa de una pregunta abierta de este tipo: ¿Cómo podría simplificarse y mejorarse el proceso de verificación de crédito para los clientes? <br />Cuestionarios cerrados. <br />El cuestionario cerrado limita las respuestas posibles del interrogado. Por medio de un cuidadoso estilo en la pregunta, el analista puede controlar el marco de referencia. Este formato es el mejor método para obtener información sobre los hechos. También fuerza a los individuos para que tomen una posición y forma de opinión sobre los aspectos importantes. <br />Etapas en el desarrollo de un cuestionario <br />Los cuestionarios bien hechos no se desarrollan rápidamente, llevan tiempo y mucho trabajo. La primera consideración se encuentra en determinar el objetivo del cuestionario. ¿Qué datos quiere conocer el analista a través de su uso? El analista define como utilizar los cuestionarios a fin de obtener los hechos al considerar la estructura mas útil para el estudio y la más sencilla de entender por parte de los interrogados. <br />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. <br />Selección de quienes recibirán el cuestionario <br />Aquellas personas que reciban el cuestionario deben seleccionarse de a cuerdo con la información que puedan proporcionar. Escribir o imprimir un cuestionario no significa que se pueda distribuir ampliamente sin un análisis previo. Lo pueden contestar personas no calificadas y si el cuestionario no es anónimo, y no será posible retirar sus respuestas de la muestra. La realización de esto también es desgastante y cara. <br /> O B S E R V A C I O N<br />¡Ver es creer! Observar las operaciones le proporciona la analista hechos que no podría obtener de otra forma. <br />Recopilación de datos mediante la observación <br />Leer en relación con una actividad del negocio le proporciona al analista una dimensión de las actividades del sistema. Entrevistar personal, ya sea directamente o a través de cuestionarios, también le ayuda y le dice algo más. Ninguno de los dos métodos da una información completa; por ejemplo, leer en relación con un viaje en jet no reproduce la experiencia de volar a unos 30 mil pies de altura. <br />La observación proporciona información de primera mano en relación con la forma en que se llevan a cabo las actividades. Las preguntas sobre el uso de documentos, la manera en la que se realizan las tareas y si ocurren los pasos específicos como se pre-establecierón, pueden contestarse rápidamente si se observan las operaciones. <br />Cuando observar <br />La observación es muy útil cuando el analista necesita ver de primera mano como se manejan los documentos, como se llevan a cabo los procesos y si ocurren los pasos especificados. Saber que buscar y como guiar su significado, también requiere de experiencia. Los observadores con experiencia captan quien utiliza los documentos y si encuentran dificultades; también están alertas para detectar documentos o registros que no se utilizan. <br />M U E S T R E O <br />Con frecuencia, en muchas empresas la información ya se encuentra disponible para que el analista conozca las actividades u operaciones con las cuales no esta familiarizado. Muchos tipos de registros e informes son accesibles si el analista sabe donde buscar. En la revisión de registros, los analistas examinan datos y descripciones que ya están escritos o registrados y en relación con el sistema y los departamentos de usuarios. Esta forma de encontrar datos puede servir como presentación del analista, si se realiza al iniciar el estudio, o como un termino de comparación de lo que sucede en el departamento con lo que los registros presentan como lo que debería suceder. <br />Recopilación de datos por medio de la inspección de registros. <br />El termino “registro” se refiere a los manuales escritos sobre políticas, regulaciones y procedimientos de operaciones estándar que la mayoría de las empresas mantienen como guía para gerentes y empleados. Los manuales que documentan o describen las operaciones para los procesos de datos existente, o sistemas de información que entran dentro del área de investigación, también proporcionan una visión sobre la forma en la que el negocio debería conducirse. Normalmente muestran los requerimientos y restricciones del sistema (como cantidad de transacciones o capacidad de almacenamiento de datos) y características de diseño (controles y verificación del procesamiento). <br />Los registro permiten que los analistas se familiaricen con algunas operaciones, oficinas de la compañía y relaciones formales a las que debe darse apoyo. No obstante, no muestran como producen de hecho las actividades, donde se ubica el poder verdadero para las decisiones, o como se realizan las tareas en la actualidad. Los otros métodos con objeto de encontrar datos estudiados en esta sección son más eficaces para proporcionar al analista este tipo de información. <br />Selección de los registros para revisión <br />En la mayor parte de las empresas los manuales de estándares sobre procedimientos de operación usualmente son obsoletos; a menudo no se mantienen al corriente lo suficiente para señalar los procedimientos existentes. Los diagramas de organización muestran como las diferentes unidades deberían relacionarse con otras; pero muchas no reflejan las operaciones actuales. <br />Actividades obligatorias: <br />Explique brevemente la realización de la entrevista <br />Liste cuatro situaciones que hagan adecuado el uso de cuestionarios. <br />¿Cómo debe ser la selección de quien recibirá el cuestionario? Defina lo que significa muestreo <br />Actividades sugeridas: <br />Liste tres razones sobre el porqué la observación es útil para el analista de sistemas en la organización Explique brevemente la fase de muestreo. <br />¿Qué tipos de información deben ser buscados en las entrevistas? <br />Recursos para ampliar el tema <br />Pags. 79–82, 109–123, 147–163, 175–181, Análisis y diseño de sistemas, Kendall & Kendall, 3ª edición, ed. Pearson educación, 1997. <br />UNIDAD 6<br />El objetivo primordial de esta unidad es darnos a conocer algunas de las ventajas, desventajas y las cualidades para que pueda ser valida la descomposición modular como son:<br />Independencia funcional<br />Acoplamiento<br />Cohesión<br />Comprensibilidad<br />Adaptabilidad<br /> <br /> El diseño modular es una metodología de desarrollo de programas complejos, que utiliza la filosofía top-down, conocida también como diseño descendente o refinamiento por pasos sucesivos<br />Sin dejar a un lado la arquitectura de dominio especifico en el cual se les dará una breve pero significativa introducción a los modelos genéricos y de referencia así como también alos distintos tipos que posee cada uno.<br />Esperando que la información contenida en esta investigación sea de vital ayuda no solo para nosotros sino también para todas las demás personas que necesiten saber acerca de estos temas y su contenido.<br /> <br />6.1 DESCOMPOSICION MODULAR<br />El diseño modular es una metodología de desarrollo de programas complejos, que utiliza la filosofía TOP-DOWN, conocida también como diseño descendente o refinamiento por pasos sucesivos; o comúnmente conocido por los programadores como “Divide y Vencerás”; puesto que enfrenta un problema desde lo abstracto (TOP) hacia lo particular (DOWN).<br />Esta técnica consiste en dividir el problema en un conjunto de subproblemas, y estos a su vez en otros de mayor facilidad de trabajo; generando los Módulos Funcionales.<br />La descomposición modular contribuye a las características deseables para la programación estructurada (y aplicable a nuestro quehacer diario); y que permite resolver cada módulo de forma independiente y, si no se sabe resolver alguno de ellos, puede asignársele un nombre y pasar al desarrollo de otro módulo y, más adelante retomar el módulo incompleto para darle solución al obtener mayor conocimiento sobre dicho proceso, es decir, la solución del problema no se detiene por falta de conocimiento de algún proceso en particular, esta técnica se conoce como Estrategia de scarlata O’hara.<br />Por lo consiguiente, podemos concluir que esta metodología presenta las siguientes ventajas:<br />Facilita el trabajo en grupos, puesto que la resolución del problema puede llevarse a cabo por varios programadores en forma paralela, gracias a la división del problema en diferentes módulos.<br />Contribuye a la comprensión y eleva el grado de legibilidad de los algoritmos.<br />Reduce el tiempo y el coste del desarrollo del software al permitir la reutilización de módulos anteriormente desarrollados en nuevos proyectos, que necesiten trabajar con estos módulos.<br />Agiliza el mantenimiento de los programas, al permitir la depuración de errores de forma independiente, con lo cual el software se adapta en mejor forma a su entorno cambiante.<br />Una descomposición modular debe poseer ciertas cualidades mínimas para que se pueda considerar suficientemente válid<br />Independencia funcional<br />Acoplamiento<br />Cohesión<br />Comprensibilidad<br />Adaptabilidad<br /> <br />INDEPENDENCIA FUNCIONAL<br />Al final de los documentos ADD y DDD debe haber una matriz REQUISITOS/COMPONNETES. En principio, cada función será realizada en un módulo distinto. Si las funciones son independientes los módulos tendrán independencia funcional.<br />Cada módulo debe realizar una función concreta o un conjunto de funciones afines. Es recomendable reducir las relaciones entre módulos al mínimo.<br />Para medir la independencia funcional hay dos criterios: acoplamiento y cohesión.<br />ACOPLAMIENTO<br />El grado de acoplamiento mide la interrelación entre dos módulos, según el tipo de conexión y la complejidad de la interface:<br />FUERTE,<br />POR CONTENIDO, cuando desde un módulo se pueden cambiar datos locales de otro<br />COMÚN, se emplea una zona común de datos a la que tienen acceso varios módulos<br />MODERADO,<br />DE CONTROL, la zona común es un dispositivo externo al que están ligados los módulos, esto implica que un cambio en el formato de datos afecta a todos estos módulos<br />POR ETIQUETA, en ontercambio de datos se realiza mediante una referencia a la estructura completa de datos (vector, pila, árbol, grafo, …)<br /> <br />DÉBIL,<br />DE DATOS, viene dado por los datos que intercambian los módulos. Es el mejor posible<br />SIN ACOPLAMIENTO DIRECTO, es el acoplamiento que no existe<br /> <br />COHESIÓN<br />Es necesario lograr que el contenido de cada módulo tenga la máxima coherencia. Para que el nº de módulos no sea demasiado elevado y complique el diseño se tratan de agrupar elementos afines y relacionados en un mismo módulo<br />ALTA<br />COHESIÓN ABSTRACCIONAL, se logra cuando se diseña el módulo como tipo abstracto de datos o como una clase de objetos<br />COHESIÓN FUNCIONAL, el módulo realiza una función concreta y específica<br />MEDIA<br />COHESIÓN SECUENCIAL, los elementos del módulo trabajan de forma secuencial<br />COHESIÓN DE COMUNICACIÓN, elementos que operan con le mismo conjunto de datos de entrada o de salida<br />COHESIÓN TEMPORAL, se agrupan elementos que se ejecutan en el mismo momento. Ej. Arrancar o parar dispositivos<br />BAJA<br />COHESIÓN LÓGICA, se agrupan elementos que realizan funciones similares. Ejs.: módulos de E/S o de tratamiento de errores<br />COHESIÓN COINCIDENTAL, es la peor y se produce cuando los elementos de un módulo no guardan relación alguna.<br /> <br />COMPRENSIBILIDAD<br />Para facilitar los cambios, el mantenimiento y la reutilización de módulos es necesario que cada uno sea comprensible de forma aislada. Para ello es bueno que posea independencia funcional, pero además es deseable:<br />IDENTIFICACIÓN: el nombre debe ser adecuado y descriptivo<br />DOCUMENTACIÓN: debe aclarar todos los detalles de diseño e implementación que no queden de manifiesto en el propio código<br />SIMPLICIDAD:las soluciones sencillas son siempre las mejores<br /> <br />ADAPTABILIDAD<br />La adaptación de un sistema resulta más dificil cuando no hay independencia funcional, es decir, con alto acoplamiento y baja cohesión, y cuando el diseño es poco comprensible. Otros factores para facilitar la adaptabilidad<br />PREVISIÓN, es necesario prever que aspectos del sistema pueden ser susceptibles de cambios en el futuro, y poner estos elementos en módulos independientes, de manera que su modificación afecte al menor número de módulos posible<br />ACCESIBILIDAD, debe resultar sencillo el acceso a los documentos de especificación, diseño, e implementación para obtener un conocimiento suficiente del sistema antes de proceder a su adaptación<br />CONSISTENCIA, después de cualquier adaptación se debe mantener la consistencia del sistema, incluidos los documentos afectados<br /> <br />DIAGRAMAS DE ESTRUCTURA MODULAR<br />La estructura modular, es decir, el conjunto de módulos de un programa y la forma en que se invocan unos a otros, se puede representar gráficamente mediante un diagrama de estructura modular. Esto es particularmente útil si el programa es complejo y consta de muchos módulos con relaciones complicadas entre sí.<br />En el diagrama se representan los módulos mediante cajas, en cuyo interior figura el nombre del módulo, unidos por líneas, que representan las interconexiones entre ellos. En cada línea se pueden escribir los parámetros de invocación y los datos devueltos por el módulo invocado.<br />El diagrama de estructura siempre tiene forma de árbol invertido. En la raíz figura el módulo principal, y de él “cuelgan” el resto de módulos en uno o varios niveles.<br />En el diagrama también se puede representar el tipo de relación entre los módulos. Las relaciones posibles se corresponden exactamente con los tres tipos de estructuras básicas de la programación estructurada:<br />Estructura secuencial: cuando un módulo llama a otro, después a otro, después a otro, etc.<br /> <br />Estructura selectiva: cuando un módulo llama a uno o a otro dependiendo de alguna condición<br /> <br /> <br />Estructura iterativa: cuando un módulo llama a otro (o a otros) en repetidas ocasiones<br />Las tres estructuras de llamadas entre módulos se representan con tres símbolos diferentes:<br /> <br /> <br /> <br /> <br /> <br />6.2 ARQUITECTURAS DE DOMINIO ESPECÍFICO<br /> <br />El reto para el diseño es diseñar el software y hardware para proporcionar características deseables a los sistemas distribuidos y, al mismo tiempo, minimizar los problemas propios a estos sistemas. Es necesario comprender las ventajas y desventajas de las diferentes arquitecturas de sistemas distribuidos. Aquí se tratan dos tipos genéricos de arquitecturas de sistemas distribuidos: Arquitectura cliente-servidor. En este caso el sistema puede ser visto como un conjunto de servicios que se proporcionan a los clientes que hacen uso de dichos servicios. Los servidores y los clientes se tratan de forma diferente en estos sistemas.<br />Arquitecturas de objetos distribuidos. Para esta arquitectura no hay distinción entre servidores y clientes, y el sistema puede ser visto como un conjunto de objetos que interaccionan cuya localización es irrelevante. No hay distinción entre un proveedor de servicios y el usuario de estos servicios. Ambas arquitecturas se usan ampliamente en la industria, pero la distribución de las aplicaciones generalmente tiene lugar dentro de una única organización. La distribución soportada es, por lo tanto, intraorganizacional. También se pueden tomar dos tipos más de arquitecturas distribuidas que son más adecuadas para la distribución interorganizacional: arquitectura de sistemas peer-to-peer (p2p) y arquitecturas orientadas a servicios. Los sistemas peer-to-peer han sido usados principalmente para sistemas personales, pero están comenzando a usarse para aplicaciones de empresa.<br />Los componentes en un sistema distribuido pueden implementarse en diferentes lenguajes de programación y pueden ejecutarse en tipos de procesadores completamente diferentes. Los modelos de datos, la representación de la información y los protocolos de comunicación pueden ser todos diferentes. Un sistema distribuido, por lo tanto, requiere software que pueda gestionar estas partes distintas, y asegurar que dichas partes se puedan comunicar e intercambiar datos. El término middleware se usa para hacer referencia a ese software; se ubica en medio de los diferentes componentes distribuidos del sistema. Bernstein (Bernstein, 1996) resume los tipos de middleware disponibles para soportar computación distribuida. El middleware es un software de propósito general que normalmente se compra como un componente comercial más que escribirse especialmente por los desarrolladores de la aplicación. Ejemplos de middleware son software para gestionar comunicaciones con bases de datos, administradores de transacciones, convertidores de datos y controladores de comunicación. Los sistemas distribuidos se desarrollan normalmente utilizando una aproximación orientada a objetos. Estos sistemas están formados por partes independientes pobremente integradas, cada una de las cuales puede interaccionar directamente con los usuarios o con otras partes del sistema. Algunas partes del sistema pueden tener que responder a eventos independientes. <br /> <br />Son modelos de arquitectura los cuales son específicos para algún dominio de aplicación.<br />Dos tipos de modelos de dominio específico son:<br />Modelos Genéricos. Estos son abstracciones de un número de sistemas reales y que encapsulan las características principales de estos sistemas.<br />Modelos de Referencia. Estos son más abstractos, son modelos idealistas. Proporcionan un significado de información con respecto a sistemas de clases y comparación de diversas arquitecturas.<br />Los modelos genéricos usualmente surgen de manera bottom-up… surgen de la práctica.<br />Los modelos de referencia son modelos top-down … surgen de estudios teóricos muy profundos.<br /> <br />MODELOS GENÉRICOS (1)<br />Un modelo de Compilador es un ejemplo conocido a través de otros modelos que existen en dominios de aplicaciones especializadas:<br />Analizador Léxico<br />Tabla de Símbolos<br />Analizador de Sintáxis<br />Analizador Semántico<br />Generador/Optimizador de Código<br />Un modelo de compilador genérico puede ser organizado de acuerdo a diversos modelos de arquitectura.<br /> <br /> <br />ARQUITECTURAS DE REFERENCIA (1)<br /> <br />Los modelos de referencias son derivados del estudio del dominio de una aplicación, en lugar del estudio de sistemas existentes.<br />Pueden ser utilizados como una base para… la implementación de un sistema o para comparar sistemas diversos.<br />Actúan como un estándar, contra el cual los sistemas que pueden ser evaluados.<br />El modelo OSI es un modelo en capas para sistemas de comunicación, y además, es un modelo de referencia.<br /> <br />La arquitectura de software es la responsable de la derivación de un modelo de sistema estructural, un modelo de control y un modelo de descomposición en subsistemas.<br />Los sistemas grandes rara vez conforman un modelo simple de arquitectura.<br />Los modelos de estructuración de un sistema incluyen modelos repositorios, los modelos cliente-servidor y los modelos de máquina abstracta.<br />Los modelos de control incluyen control centralizado y modelos manejadores de eventos.<br />Los modelos de descomposición modular incluyen los modelos orientados a<br />objetos y los modelos de flujo de datos.<br />Los modelos de dominio específico son abstracciones sobre el dominio de una aplicación.<br />Estos pueden ser construidos mediante la abstracción de sistemas existentes o pueden estar<br />basados en modelos de referencia (ideales).<br /> <br /> <br />CONCLUSION<br />En conclusión podemos decir que algo muy importante y de mucho realce en nuestra investigación fueron algunas de las ventajas de descomposición modular que son:<br />Facilita el trabajo en grupos, puesto que la resolución del problema puede llevarse a cabo por varios programadores en forma paralela, gracias a la división del problema en diferentes módulos.<br />Contribuye a la comprensión y eleva el grado de legibilidad de los algoritmos.<br />Reduce el tiempo y el coste del desarrollo del software al permitir la reutilización de módulos anteriormente desarrollados en nuevos proyectos, que necesiten trabajar con estos módulos.<br />Agiliza el mantenimiento de los programas, al permitir la depuración de errores de forma independiente, con lo cual el software se adapta en mejor forma a su entorno cambiante.<br /> <br />En cuanto a la estructura de dominio especifico podemos decir que no hay distinción entre servidores y clientes, y el sistema puede ser visto como un conjunto de objetos que interaccionan cuya localización es irrelevante.<br />No hay distinción entre un proveedor de servicios y el usuario de estos servicios. Ambas arquitecturas se usan ampliamente en la industria, pero la distribución de las aplicaciones generalmente tiene lugar dentro de una única organización.<br />](https://image.slidesharecdn.com/fundamentosdedesarrollodesistemas-110824134427-phpapp02/85/Fundamentos-de-desarrollo-de-sistemas-1-320.jpg)
Fundamentos de desarrollo de sistemas
- 1. UNIDAD I CONCEPTOS INTRODUCTORIOS<br />1.1.Introducción a los sistemas<br />SISTEMA: Conjunto organizado de partesinterdependientes que interactúan entre sí formando un todo unitario y complejo. <br />Descripción general <br />Las partes forman las funciones básicas realizadas por el sistema de las cuales podemos enumerarlas en:<br />Las salidas de un sistema se convierten en entrada de otro, que la procesará para convertirla en otra salida, repitiéndose este ciclo indefinidamente. <br />Tipos<br />Sistemas de Soporte para la Toma de Decisiones (DSS: DecisionSupportSystems): apoyar la toma de decisiones mediante la generación y evaluación sistemática de diferentes alternativas o escenarios de decisión. Un DSS no soluciona problemas, ya que solo apoya al proceso de toma de decisiones. <br />Sistemas de Soporte para la Toma de Decisiones de Grupo (GroupDecisionSupportSystems): cubren el objetivo de lograr la participación de un grupo de personas durante la toma de decisiones en ambientes de anonimato y consenso, apoyando decisiones simultáneas. <br />Sistemas Expertos de Soporte para la Toma de Decisiones (DEss: ExpertDecisionSupprtSystems): permiten cargar bases de conocimiento que se integran por una serie de reglas de sentido común para que diferentes usuarios las consulten, apoyen la toma de decisiones, la capacitación. <br />Sistemas de Información para Ejecutivos (EIS: ExecutiveinformationSystems): están dirigidos a apoyar el proceso de toma de decisiones de los altos ejecutivos de una organización, presentado información relevante y usando recursos visuales de fácil interpretación, con el ejecutivo de mantenerlos informados. <br />Clasificación<br />Abiertos: Son los que intercambian información, materiales y energía con su ambiente. <br />Cerrados: Son auto contenido, no interactúan con el medio ambiente. <br />Probabilístico: No se conoce con certeza su comportamiento. <br />Deterministico: Cualquier estado futuro que adopten puede preciarse con antelación.<br />ciclo de vida de un proyecto de software<br />Definición.- Conjunto de etapas que se han de llevar a cabo para crear, explotar y mantener un Sistema Informático. <br /> <br />Fases del Ciclo <br />1) Definición de requerimientos2) Análisis y diseño del sistema 3) Implementación (codificación)4) Integración y pruebas<br />5) Explotación y mantenimiento <br />1. Definición de requerimientosEstudio detallado de la situación actual del problema a tratar, definición de los requerimientos que debe cumplir el sistema. <br />2. Análisis y diseño del sistemaDescomposición modular de toda la aplicación, descripción detallada de cada uno de los módulos y sus inter-relaciones, todo ello para poder facilitar al máximo la fase de codificación. <br />3. Implementación (codificación)Cada módulo como resultado de la fase anterior es traducido a la herramienta o lenguaje apropiado. <br />4. Integración y pruebasVerificación del correcto funcionamiento de cada módulo y todo el sistema una vez ha sido integrado, detectar errores en la codificación, definiciones de requerimientos y de diseño. <br />5. Explotación y mantenimientoGarantizar el mantenimiento del sistema, corrección de errores detectados en esta fase, adaptación del sistema a nuevos entornos. <br />Expresión de necesidades Esta etapa tiene como objetivo la consecución de un primer documento en que queden reflejados los requerimientos y funcionalidades que ofrecerá al usuario del sistema a desarrollar (qué, y no cómo, se va a desarrollar).<br />Especificaciones<br />Ahora se trata de formalizar los requerimientos; el documento obtenido en la etapa anterior se tomará como punto de partida para esta fase. Su contenido es aún insuficiente y lleno de imprecisiones que será necesario completar y depurar. Análisis Es necesario determinar qué elementos intervienen en el sistema a desarrollar, así como su estructura, relaciones, evolución en el tiempo, detalle de sus funcionalidades. Para ello se enfocará el sistema desde tres puntos de vista relacionados pero diferentes: Diseño Tras la etapa anterior ya se tiene claro que debe hacer el sistema, ahora tenemos que determinar cómo va a hacerlo (¿cómo debe ser construido el sistema?; aquí se definirán en detalle entidades y relaciones de las bases de datos, se pasará de casos de uso esenciales a su definición como casos expandidos reales, se seleccionará el lenguaje más adecuado, el Sistema Gestor de Bases de Datos a utilizar en su caso, librerías, configuraciones hardware, redes). Implementación Llegado este punto se empieza a codificar algoritmos y estructuras de datos, definidos en las etapas anteriores, en el correspondiente lenguaje de programación y/o para un determinado sistema gestor de bases de datos. Funcional. Estático. Dinámico.<br />Pruebas El objetivo de estas pruebas es garantizar que el sistema ha sido desarrollado correctamente, sin errores de diseño y/o programación. Es conveniente que sean planteadas al menos tanto a nivel de cada módulo (aislado del resto), como de integración del sistema (según sea la naturaleza del proyecto en cuestión se podrán tener en cuenta pruebas adicionales, p.ej. de rendimiento).<br />Validación Esta etapa tiene como objetivo la verificación de que el sistema desarrollado cumple con los requisitos expresados inicialmente por el cliente y que han dado lugar al presente proyecto (para esta fase también es interesante contar con los use cases, generados a través de las correspondientes fases previas, que servirán de guía para la verificación de que el sistema cumple con lo descrito por estos).<br />Mantenimiento y evolución.<br />Finalmente la aplicación resultante se encuentra ya en fase de producción (en funcionamiento para el cliente, cumpliendo ya los objetivos para los que ha sido creada). A partir de este momento se entra en la etapa de mantenimiento, que supondrá ya pequeñas operaciones tanto de corrección como de mejora de la aplicación (p.ej. mejora del rendimiento), así como otras de mayor importancia, fruto de la propia evolución (p.ej. nuevas opciones para el usuario debidas a nuevas operaciones contempladas para el producto). <br />1.2.1 Planificación y gestión del proyecto <br />La gestión de proyectos busca las técnicas necesarias para planificar, organizar, supervisar y controlar proyectos de software. El objetivo de gestionar proyectos es tener un producto de alta calidad. Cuando se planifica un proyecto se tiene que obtener estimaciones del costo y esfuerzo humano requerido por medio de las mediciones de software que se utilizan para recolectar los datos cualitativos acerca del software y sus procesos para aumentar su calidad. La gestión de un proyecto de software se centra en tres partes como son: Personal, Problema, Proceso.<br />-Personal: El factor humano es importante en la ingeniería de software. (Es importante tener la capacidad de gestión del personal con el fin de aumentar la preparación en la organización del software). <br />-Problema: Se establecen los objetivos y se deben considerar soluciones alternativas e identificar las dificultades técnicas y de gestión. (Con esta información es posible definir unas estimaciones razonables del costo, una valoración efectiva del riesgo, una subdivisión realista de las tareas del proyecto o una planificación del proyecto asequible que proporcione una indicación fiable del progreso). <br />-Proceso: Proporciona la estructura desde la que se puede establecer un detallado plan para el desarrollo del software. (Las actividades estructurales se pueden aplicar a todos los proyectos de software, sin tener en cuenta su tamaño o complejidad). El proceso de software lo componen participantes que pueden clasificarse en cinco categorías: <br />Gestores superiores: definen los aspectos de negocios que a menudo tienen una significativa influencia en el proyecto. <br />Gestores técnicos del proyecto: deben planificar, organizar y controlar a los profesionales que realizan el trabajo del software. <br />Profesionales: proporcionan las capacidades técnicas para la ingeniería de un producto <br />Clientes: especifica los requisitos para la ingeniería de software. <br />Usuarios finales: interaccionan con el software una vez que se ha entregado para la producción.<br />En la mayoría de los desafíos técnicos, las métricas nos ayudan a entender tanto el proceso técnico que se utiliza para desarrollar un producto, como el propio producto. (El proceso para intentar mejorarlo, el producto se mide para intentar aumentar su calidad).<br />Métricas del software.<br />Existen diferentes métricas están relacionadas con el desarrollo del software para medir su funcionalidad, complejidad, y eficiencia. <br />Métricas técnicas: Se centran en las características de software. (Por ejemplo: la complejidad lógica, el grado de modularidad. Mide la estructura del sistema, el cómo está hecho). <br />Métricas de calidad: proporcionan una indicación de cómo se ajusta el software a los requisitos implícitos y explícitos del cliente. (Es decir cómo voy a medir para que mi sistema se adapte a los requisitos que me pide el cliente).<br />Métricas de productividad: Se centran en el rendimiento del proceso de la ingeniería del software. (Es decir que tan productivo va a ser el software que voy a diseñar). <br />Métricas orientadas a la persona: Proporcionan medidas e información sobre la forma que la gente desarrolla el software de computadoras y sobre todo el punto de vista humano de la efectividad de las herramientas y métodos. (Son las medidas que voy a hacer de mi personal que hará el sistema). <br />Métricas orientadas al tamaño: Es para saber en qué tiempo voy a terminar elsoftware y cuantas personas voy a necesitar. (Son medidas directas al software y el proceso porel cual se desarrolla). <br />1.2.3 Análisis y diseño. <br />El análisis de coste-beneficio es complicado porque los criterios varían según las características del sistema a desarrollar, el tamaño relativo del proyecto y la recuperación esperada de la inversión como parte del plan estratégico de la compañía. Además, muchos beneficios obtenidos de los sistemas basados en computadora son intangibles. <br />Análisis: Es indispensable determinar qué elementos van a intervenir en el sistemas a desarrollar, su estructura, relaciones, evolución a corto o largo plazo, su funcionalidad, los que nos dará una descripción clara de que sistema vamos a desarrollar, qué funcionalidades va a aportar y qué comportamiento va a tener. Es importante realizar un análisis económico y técnico (análisis de costos beneficios), significa una valoración de la inversión económica comparado con los beneficios que se obtendrán en la comercialización y utilidad del producto o sistema. <br />Diseño: Realizada la etapa anterior ya se tiene claro que debe hacer el sistema,ahora tenemos que plantear como va a hacerlo (¿cómo debe ser construido el sistema?;aquí se definirán en detalle entidades y relaciones de las bases de datos, se pasará de casos de uso esenciales a su definición como casos expandidos reales, se<br />seleccionara el lenguaje más adecuado, el Sistema Gestor de Base de Datos a utilizar en un caso, librerías, configuraciones hardware, redes, y demás condiciones para el desarrollo del sistema). Para ello nos enfocamos en cuatro etapas: El diseño de los datos. Trasforma el modelo de dominio de la información, creado durante el análisis, en las estructuras de datos necesarios para implementar el Software. El Diseño Arquitectónico. Define la relación entre cada uno de los elementos estructurales del programa. El Diseño de la Interfaz. Describe como se comunica el Software consigo mismo, con los sistemas que operan junto con él y con los operadores y usuarios que lo emplean. El Diseño de procedimientos. Transforma elementos estructurales de la arquitectura del programa. La importancia del Diseño del Software se puede definir en una sola palabra Calidad. El Diseño es la única manera de materializar con precisión los requerimientos del cliente.<br /> <br />Unidad 2 Introducción a la ingeniería de software.<br />Según la definición del IEEE, citada por [Lewis 1994] \" software: es la suma total de los programas de computadora, procedimientos, reglas, la documentación asociada y los datos que pertenecen a un sistema de cómputo\" . Según el mismo autor, \" un producto de software es un producto diseñado para un usuario\" . En este contexto, la Ingeniería de Software (SE del inglés Software Engineering): es un enfoque sistemático del desarrollo, operación, mantenimiento y retiro del software\" , que en palabras más llanas, se considera que \" la Ingeniería de Software: es la rama de la ingeniería que aplica los principios de la ciencia de la computación y las matemáticas para lograr soluciones costo-efectivas (eficaces en costo o económicas) a los problemas de desarrollo de software\" , es decir, \" permite elaborar consistentemente productos correctos, utilizables y costo-efectivos\" [Cota 1994].<br />El proceso de ingeniería de software: se define como \" un conjunto de etapas parcialmente ordenadas con la intención de logra un objetivo, en este caso, la obtención de un producto de software de calidad\" [Jacobson 1998].El proceso de desarrollo de software \" es aquel en que las necesidades del usuario son traducidas en requerimientos de software, estos requerimientos transformados en diseño y el diseño implementado en código, el código es probado, documentado y certificado para su uso operativo\" . Concretamente \" define quién está haciendo qué, cuándo hacerlo y cómo alcanzar un cierto objetivo\" [Jacobson 1998]. <br />El proceso de desarrollo de software requiere por un lado un conjunto de conceptos, una metodología y un lenguaje propio. A este proceso también se le llama el ciclo de vida del software que comprende cuatro grandes fases: concepción, elaboración, construcción y transición. <br />La concepción: define le alcance del proyecto y desarrolla un caso de negocio. <br />La elaboración: define un plan del proyecto, especifica las características y fundamenta la arquitectura. <br />La construcción: crea el producto y la transición transfiere el producto a los usuarios.<br />Actualmente se encuentra en una etapa de madurez el enfoque Orientado a Objetos (OO) como paradigma del desarrollo de sistemas de información. El Object Management Group (OMG) es un consorcio a nivel internacional que integra a los principales representantes de la industria de la tecnología de información OO. El OMG tiene como objetivo central la promoción, fortalecimiento e impulso de la industria OO. El OMG propone y adopta por consenso especificaciones entorno a la tecnología OO. Una de las especificaciones más importantes es la adopción en 1998 del Lenguaje de Modelado Unificado o UML (del inglés Unified Modeling Language) como un estándar, que junto con el Proceso Unificado están consolidando la tecnología OO.<br />Unidad 4 Modelos de proceso de software.<br />Modelos de proceso software<br />Sommerville [4] define modelo de proceso de software como “Una representación simplificada de un proceso de software, representada desde una perspectiva específica. Por su naturaleza los modelos son simplificados, por lo tanto un modelo de procesos del software es una abstracción de un proceso real.” <br />Los modelos genéricos no son descripciones definitivas de procesos de software; sin embargo, son abstracciones útiles que pueden ser utilizadas para explicar diferentes enfoques del desarrollo de software. <br />Modelos que se van a discutir a continuación:<br />Codificar y corregir<br />Modelo en cascada<br />Desarrollo evolutivo<br />Desarrollo formal de sistemas<br />Desarrollo basado en reutilización<br />Desarrollo incremental<br />Desarrollo en espiral<br />Codificar y corregir (Code-and-Fix)<br />Este es el modelo básico utilizado en los inicios del desarrollo de software. Contiene dos pasos:<br />Escribir código.<br />Corregir problemas en el código.<br />Se trata de primero implementar algo de código y luego pensar acerca de requisitos, diseño, validación, y mantenimiento. <br />Este modelo tiene tres problemas principales:<br />Después de un número de correcciones, el código puede tener una muy mala estructura, hace que los arreglos sean muy costosos. <br />Frecuentemente, aún el software bien diseñado, no se ajusta a las necesidades del usuario, por lo que es rechazado o su reconstrucción es muy cara.<br />El código es difícil de reparar por su pobre preparación para probar y modificar.<br />Modelo en cascada<br />El primer modelo de desarrollo de software que se publicó se derivó de otros procesos de ingeniería [8]. Éste toma las actividades fundamentales del proceso de especificación, desarrollo, validación y evolución y las representa como fases separadas del proceso.<br />El modelo en cascada consta de las siguientes fases:<br />Definición de los requisitos: Los servicios, restricciones y objetivos son establecidos con los usuarios del sistema. Se busca hacer esta definición en detalle.<br />Diseño de software: Se particiona el sistema en sistemas de software o hardware. Se establece la arquitectura total del sistema. Se identifican y describen las abstracciones y relaciones de los componentes del sistema.<br />Implementación y pruebas unitarias: Construcción de los módulos y unidades de software. Se realizan pruebas de cada unidad.<br />Integración y pruebas del sistema: Se integran todas las unidades. Se prueban en conjunto. Se entrega el conjunto probado al cliente.<br />Operación y mantenimiento: Generalmente es la fase más larga. El sistema es puesto en marcha y se realiza la corrección de errores descubiertos. Se realizan mejoras de implementación. Se identifican nuevos requisitos.<br />La interacción entre fases puede observarse en la Figura 5. Cada fase tiene como resultado documentos que deben ser aprobados por el usuario. <br />Una fase no comienza hasta que termine la fase anterior y generalmente se incluye la corrección de los problemas encontrados en fases previas.<br />Figura SEQ Figura \* ARABIC 5: Modelo de desarrollo en cascada.<br />En la práctica, este modelo no es lineal, e involucra varias iteraciones e interacción entre las distintas fases de desarrollo. Algunos problemas que se observan en el modelo de cascada son:<br />Las iteraciones son costosas e implican rehacer trabajo debido a la producción y aprobación de documentos.<br />Aunque son pocas iteraciones, es normal congelar parte del desarrollo y continuar con las siguientes fases.<br />Los problemas se dejan para su posterior resolución, lo que lleva a que estos sean ignorados o corregidos de una forma poco elegante.<br />Existe una alta probabilidad de que el software no cumpla con los requisitos del usuario por el largo tiempo de entrega del producto.<br />Es inflexible a la hora de evolucionar para incorporar nuevos requisitos. Es difícil responder a cambios en los requisitos.<br />Este modelo sólo debe usarse si se entienden a plenitud los requisitos. Aún se utiliza como parte de proyectos grandes.<br />Desarrollo evolutivo<br />La idea detrás de este modelo es el desarrollo de una implantación del sistema inicial, exponerla a los comentarios del usuario, refinarla en N versiones hasta que se desarrolle el sistema adecuado. En la Figura 6 se observa cómo las actividades concurrentes: especificación, desarrollo y validación, se realizan durante el desarrollo de las versiones hasta llegar al producto final.<br />Una ventaja de este modelo es que se obtiene una rápida realimentación del usuario, ya que las actividades de especificación, desarrollo y pruebas se ejecutan en cada iteración.<br />Figura SEQ Figura \* ARABIC 6: Modelo de desarrollo evolutivo.<br />Existen dos tipos de desarrollo evolutivo:<br />Desarrollo Exploratorio: El objetivo de este enfoque es explorar con el usuario los requisitos hasta llegar a un sistema final. El desarrollo comienza con las partes que se tiene más claras. El sistema evoluciona conforme se añaden nuevas características propuestas por el usuario.<br />Enfoque utilizando prototipos: El objetivo es entender los requisitos del usuario y trabajar para mejorar la calidad de los requisitos. A diferencia del desarrollo exploratorio, se comienza por definir los requisitos que no están claros para el usuario y se utiliza un prototipo para experimentar con ellos. El prototipo ayuda a terminar de definir estos requisitos.<br />Entre los puntos favorables de este modelo están:<br />La especificación puede desarrollarse de forma creciente.<br />Los usuarios y desarrolladores logran un mejor entendimiento del sistema. Esto se refleja en una mejora de la calidad del software.<br />Es más efectivo que el modelo de cascada, ya que cumple con las necesidades inmediatas del cliente.<br />Desde una perspectiva de ingeniería y administración se identifican los siguientes problemas:<br />Proceso no Visible: Los administradores necesitan entregas para medir el progreso. Si el sistema se necesita desarrollar rápido, no es efectivo producir documentos que reflejen cada versión del sistema.<br />Sistemas pobremente estructurados: Los cambios continuos pueden ser perjudiciales para la estructura del software haciendo costoso el mantenimiento.<br />Se requieren técnicas y herramientas: Para el rápido desarrollo se necesitan herramientas que pueden ser incompatibles con otras o que poca gente sabe utilizar.<br />Este modelo es efectivo en proyectos pequeños (menos de 100.000 líneas de código) o medianos (hasta 500.000 líneas de código) con poco tiempo para su desarrollo y sin generar documentación para cada versión.<br />Para proyectos largos es mejor combinar lo mejor del modelo de cascada y evolutivo: se puede hacer un prototipo global del sistema y posteriormente reimplementarlo con un acercamiento más estructurado. Los subsistemas con requisitos bien definidos y estables se pueden programar utilizando cascada y la interfaz de usuario se puede especificar utilizando un enfoque exploratorio.<br />Desarrollo formal de sistemas<br />Este modelo se basa en transformaciones formales de los requisitos hasta llegar a un programa ejecutable. <br />Figura SEQ Figura \* ARABIC 7: Paradigma de programación automática.<br />La Figura 7 (obtenida desde [20]) ilustra un paradigma ideal de programación automática. Se distinguen dos fases globales: especificación (incluyendo validación) y transformación. Las características principales de este paradigma son: la especificación es formal y ejecutable constituye el primer prototipo del sistema), la especificación es validada mediante prototipación. Posteriormente, a través de transformaciones formales la especificación se convierte en la implementación del sistema, en el último paso de transformación se obtiene una implementación en un lenguaje de programación determinado. , el mantenimiento se realiza sobre la especificación (no sobre el código fuente), la documentación es generada automáticamente y el mantenimiento es realizado por repetición del proceso (no mediante parches sobre la implementación).<br />Observaciones sobre el desarrollo formal de sistemas:<br />Permite demostrar la corrección del sistema durante el proceso de transformación. Así, las pruebas que verifican la correspondencia con la especificación no son necesarias.<br />Es atractivo sobre todo para sistemas donde hay requisitos de seguridad y confiabilidad importantes.<br />Requiere desarrolladores especializados y experimentados en este proceso para llevarse a cabo.<br />Desarrollo basado en reutilización<br />Como su nombre lo indica, es un modelo fuertemente orientado a la reutilización. Este modelo consta de 4 fases ilustradas en la Figura 9. A continuación se describe cada fase:<br />Análisis de componentes: Se determina qué componentes pueden ser utilizados para el sistema en cuestión. Casi siempre hay que hacer ajustes para adecuarlos.<br />Modificación de requisitos: Se adaptan (en lo posible) los requisitos para concordar con los componentes de la etapa anterior. Si no se puede realizar modificaciones en los requisitos, hay que seguir buscando componentes más adecuados (fase 1).<br />Diseño del sistema con reutilización: Se diseña o reutiliza el marco de trabajo para el sistema. Se debe tener en cuenta los componentes localizados en la fase 2 para diseñar o determinar este marco.<br />Desarrollo e integración: El software que no puede comprarse, se desarrolla. Se integran los componentes y subsistemas. La integración es parte del desarrollo en lugar de una actividad separada.<br />Las ventajas de este modelo son:<br />Disminuye el costo y esfuerzo de desarrollo.<br />Reduce el tiempo de entrega.<br />Disminuye los riesgos durante el desarrollo.<br />Figura SEQ Figura \* ARABIC 8: Desarrollo basado en reutilización de componentes<br />Desventajas de este modelo:<br />Los “compromisos” en los requisitos son inevitables, por lo cual puede que el software no cumpla las expectativas del cliente.<br />Las actualizaciones de los componentes adquiridos no están en manos de los desarrolladores del sistema.<br />Procesos iterativos<br />A continuación se expondrán dos enfoques híbridos, especialmente diseñados para el soporte de las iteraciones:<br />Desarrollo Incremental.<br />Desarrollo en Espiral.<br />Desarrollo incremental<br />Mills [9] sugirió el enfoque incremental de desarrollo como una forma de reducir la repetición del trabajo en el proceso de desarrollo y dar oportunidad de retrasar la toma de decisiones en los requisitos hasta adquirir experiencia con el sistema (ver Figura 10). Es una combinación del Modelo de Cascada y Modelo Evolutivo.<br />Reduce el rehacer trabajo durante el proceso de desarrollo y da oportunidad para retrasar las decisiones hasta tener experiencia en el sistema. <br />Durante el desarrollo de cada incremento se puede utilizar el modelo de cascada o evolutivo, dependiendo del conocimiento que se tenga sobre los requisitos a implementar. Si se tiene un buen conocimiento, se puede optar por cascada, si es dudoso, evolutivo.<br />Figura SEQ Figura \* ARABIC 9: Modelo de desarrollo iterativo incremental.<br />Entre las ventajas del modelo incremental se encuentran:<br />Los clientes no esperan hasta el fin del desarrollo para utilizar el sistema. Pueden empezar a usarlo desde el primer incremento.<br />Los clientes pueden aclarar los requisitos que no tengan claros conforme ven las entregas del sistema.<br />Se disminuye el riesgo de fracaso de todo el proyecto, ya que se puede distribuir en cada incremento.<br />Las partes más importantes del sistema son entregadas primero, por lo cual se realizan más pruebas en estos módulos y se disminuye el riesgo de fallos.<br />Algunas de las desventajas identificadas para este modelo son:<br />Cada incremento debe ser pequeño para limitar el riesgo (menos de 20.000 líneas).<br />Cada incremento debe aumentar la funcionalidad.<br />Es difícil establecer las correspondencias de los requisitos contra los incrementos.<br />Es difícil detectar las unidades o servicios genéricos para todo el sistema.<br />Desarrollo en espiral<br />El modelo de desarrollo en espiral (ver Figura 11) es actualmente uno de los más conocidos y fue propuesto por Boehm [7]. El ciclo de desarrollo se representa como una espiral, en lugar de una serie de actividades sucesivas con retrospectiva de una actividad a otra.<br />Cada ciclo de desarrollo se divide en cuatro fases:<br />Definición de objetivos: Se definen los objetivos. Se definen las restricciones del proceso y del producto. Se realiza un diseño detallado del plan administrativo. Se identifican los riesgos y se elaboran estrategias alternativas dependiendo de estos.<br />Evaluación y reducción de riesgos: Se realiza un análisis detallado de cada riesgo identificado. Pueden desarrollarse prototipos para disminuir el riesgo de requisitos dudosos. Se llevan a cabo los pasos para reducir los riesgos.<br />Desarrollo y validación: Se escoge el modelo de desarrollo después de la evaluación del riesgo. El modelo que se utilizará (cascada, sistemas formales, evolutivo, etc.) depende del riesgo identificado para esa fase.<br />Planificación: Se determina si continuar con otro ciclo. Se planea la siguiente fase del proyecto.<br />Este modelo a diferencia de los otros toma en consideración explícitamente el riesgo, esta es una actividad importante en la administración del proyecto.<br />El ciclo de vida inicia con la definición de los objetivos. De acuerdo a las restricciones se determinan distintas alternativas. Se identifican los riesgos al sopesar los objetivos contra las alternativas. Se evalúan los riesgos con actividades como análisis detallado, simulación, prototipos, etc. Se desarrolla un poco el sistema. Se planifica la siguiente fase.<br />36766522225<br />Modelo de procesoFunciona con requisitos y arquitectura no predefinidosProduce software altamente fiableGestión de riesgosPermite correcciones sobre la marchaVisión del progreso por el Cliente y el Jefe del proyectoCodificar y corregirBajo BajoBajoAltoMedioCascadaBajoAltoBajoBajoBajo EvolutivoexploratorioMedio o AltoMedio o AltoMedio Medio o AltoMedio o AltoEvolutivoprototipadoAltoMedioMedioAltoAltoDesarrollo formal de sistemasBajoAltoBajo a MedioBajoBajoDesarrollo orientado a reutilizaciónMedioBajo a AltoBajo a MedioAltoAltoIncrementalBajoAltoMedioBajoBajoEspiralAltoAltoAltoMedioMedio<br />Unidad 5<br />TÉCNICAS DE RECOPILACIÓN DE INFORMACIÓN <br />Los analistas utilizan una variable de métodos a fin de recopilar los datos sobre una situación existente, como entrevistas, cuestionario, inspección de registros y observación. Cada uno tiene ventajas y desventajas. Generalmente, se utilizan dos o tres para complementar el trabajo de cada una y ayudar a asegurar una investigación completa. A continuación se verán cada una de ellas. <br />E N T R E V I S T A <br />Las entrevistas se utilizan para recabar información en forma verbal, a través de preguntas que propone el analista. Quienes responde pueden ser gerentes o empleados, los cuales son usuarios actuales del sistema, existen usuarios potenciales del sistema propuesto o aquellos que proporcionaran datos o serán afectadas por la aplicación propuesta. El analista puede entrevistar al personal en forma individual o en grupos. <br />Recabar datos mediante la entrevista. <br />La entrevista es una forma de conversación, ¡no interrogación! Al analizar las características de los sistemas con personal seleccionado cuidadosamente por sus conocimientos sobre es sistema los analistas pueden conocerlos datos que no están disponibles en ninguna otra forma. <br />En las investigaciones de sistemas, las formas cualitativas y cuantitativas de la información son importantes. La información cualitativa esta relacionada con opiniones, políticas y descripciones cuantitativas tratan con números, frecuencia o cantidades. A menudo las entrevistas dan la mejor fuente de información cualitativa; los otros métodos tienden a ser mas útiles en la recabación de datos cuantitativos. <br />Mucha gente incapaz de expresarse por escrito puede discutir sus ideas en forma verbal. Como resultado de esto las entrevistas pueden descubrir rápidamente malos entendidos, falsas expectativas o incluso resistencia potencial para las aplicaciones en desarrollo; mas aun a menudo es más fácil calendarizar una entrevista con los gerentes del alto nivel, que pedirles que llenen cuestionarios. <br />Determinación del tipo de entrevista. <br />La estructura de las entrevistas varia. Si el objetivo de la entrevista radica en adquirir información general, es conveniente elaborar una serie de preguntas sin estructura, con una sección de preguntas y respuestas libres. La atmósfera abierta y de fácil flujo de esta modalidad proporciona una mayor oportunidad para conocer las actitudes, ideas y creencias de quien responde. Sin embargo, cuando los analistas necesitan adquirir datos más específicos sobre la aplicación o desean asegurar una alta confiabilidad en las respuestas a las preguntas que han propuesto a sus entrevistados, las entrevistas estructuradas son mejores. <br />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. <br />La confiabilidad es solo una consideración en la selección del método de entrevista. Los analistas también deben dividir su tiempo entre desarrollar preguntas para entrevistas y analizar las respuestas. Las entrevistas no estructuradas requieren menos tiempo de preparación, porque no se necesita tener por anticipado las palabras precisas de las preguntas. Sin embargo, analizar las respuestas después de las entrevistas lleva más tiempo que con las entrevistas estructuradas. De cualquier manera, el mayor costo radica en la preparación, administración y análisis de las entrevistas estructuradas para preguntas cerradas. <br />Dado que un numero de personas se seleccionara para la entrevista, los analistas deben tener cuidado de incluir aquellas personas que tienen información que no se podrá conseguir de otra forma. Durante las primeras etapas de un estudio de sistemas, cuando los analistas determinan <br />La factibilidad del proyecto, con frecuencia las entrevistas solo se aplican a la gerencia o personal de supervisión. Sin embargo, durante la investigación detallada en donde el objetivo es descubrir hechos específicos, opiniones y conocer como se manejan las operaciones desempeñadas actualmente, las entrevistas se aplican en todos los niveles gerenciales y de empleados y dependen de quien pueda proporcionar la mayor parte de la información útil para el estudio. Así, los analistas que estudian ala administración de inventarios pueden entrevistar a los trabajadores del embarque y de recepción, al personal del almacén y a los supervisores de los diferentes turnos, es decir, aquellas personas que realmente trabajan en el almacén; también entrevistaran a los agentes más importantes. <br />Realización de la entrevista. <br />La habilidad del entrevistador es vital para el éxito en la búsqueda de hechos por medio de la entrevista. Las buenas entrevistas dependen del conocimiento del analista tanto de la preparación del objetivo de una entrevista especifica como de las preguntas por realizar a una persona determinada. <br />El tacto, la imparcialidad e incluso la vestimenta apropiada ayudan a asegurar una entrevista exitosa. La falta de estos factores puede reducir cualquier oportunidad de éxito. Por ejemplo, un analista que trabaja en la aplicación enfocada a la reducción de errores probablemente no tendría éxito si llegar a una oficina de gerencia de nivel medio con la presentación equivocada, por ejemplo, si dijera, “hola, fui enviado para encontrar una forma de mojar el rendimiento y de reducir los errores que presentan aquí. O la introducción: “Estamos aquí para resolver su problema”, es igualmente mala. Es imaginable la rapidez con la que va a responder ser irrita y se molesta con un enfoque de este tipo. <br />A través de la entrevista, los analistas deben preguntarse así mismos las siguientes interrogantes: <br />¿Qué es lo que me esta diciendo la persona? <br />¿Por qué me lo esta diciendo a mí? <br />¿Qué se esta olvidando? <br />¿Qué espera esta persona que haga yo? <br />Si se considera cada elemento de la información contra estas preguntas, los analistas tendrán mas conocimientos no solamente de la información adquirida sino también de su importancia. <br />C U E S T I O N A R I O . <br />Los cuestionarios proporcionan una alternativa muy útil para las entrevistas; sin embargo, existen ciertas características que pueden ser apropiadas en algunas situaciones e inapropiadas en otras. <br />Recabación de datos mediante cuestionarios <br />Para los analistas los cuestionarios pueden ser la única forma posible de relacionarse con un gran numero de personas para conocer varios aspectos del sistema. Cuando se llevan a cabo largos estudios en varios departamentos, se puede distribuir los cuestionarios a todas las personas apropiadas para recabar hechos con relación al sistema. Por supuesto, no es posible observar las expresiones o relaciones de quienes responden a los cuestionarios. <br />También las preguntas estandarizadas pueden proporcionar datos más confiables. Por otra parte, las características anteriores también son desventajas de los cuestionarios. Aunque su aplicación puede realizarse con un mayor numero de individuos, es muy rara una respuesta total. Puede necesitarse algún seguimiento de los cuestionarios para motivar al personal que responda; todas las respuestas se encontraran en una proporción entre el 25 o 35%, que es lo más común. <br />Selección de formas para cuestionarios. <br />El desarrollo y distribución de los cuestionarios es caro; por lo tanto, el tiempo invertido en esto debe utilizarse en una forma inteligente. También es importante el formato y contenido de las preguntas en la recopilación de hechos significativos. <br />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. <br />Cuestionarios abiertos. <br />Al igual, que las entrevistas, los cuestionarios pueden ser abiertos y se aplican cuando se quieren conocer los sentimientos, opiniones y experiencias generales; también son útiles al explorar el problema básico, por ejemplo, un analista que utiliza cuestionarios para estudiar los métodos de verificación de crédito, en un medio ambiente de ventas al a menudeo, podría recabar mas información provechosa de una pregunta abierta de este tipo: ¿Cómo podría simplificarse y mejorarse el proceso de verificación de crédito para los clientes? <br />Cuestionarios cerrados. <br />El cuestionario cerrado limita las respuestas posibles del interrogado. Por medio de un cuidadoso estilo en la pregunta, el analista puede controlar el marco de referencia. Este formato es el mejor método para obtener información sobre los hechos. También fuerza a los individuos para que tomen una posición y forma de opinión sobre los aspectos importantes. <br />Etapas en el desarrollo de un cuestionario <br />Los cuestionarios bien hechos no se desarrollan rápidamente, llevan tiempo y mucho trabajo. La primera consideración se encuentra en determinar el objetivo del cuestionario. ¿Qué datos quiere conocer el analista a través de su uso? El analista define como utilizar los cuestionarios a fin de obtener los hechos al considerar la estructura mas útil para el estudio y la más sencilla de entender por parte de los interrogados. <br />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. <br />Selección de quienes recibirán el cuestionario <br />Aquellas personas que reciban el cuestionario deben seleccionarse de a cuerdo con la información que puedan proporcionar. Escribir o imprimir un cuestionario no significa que se pueda distribuir ampliamente sin un análisis previo. Lo pueden contestar personas no calificadas y si el cuestionario no es anónimo, y no será posible retirar sus respuestas de la muestra. La realización de esto también es desgastante y cara. <br /> O B S E R V A C I O N<br />¡Ver es creer! Observar las operaciones le proporciona la analista hechos que no podría obtener de otra forma. <br />Recopilación de datos mediante la observación <br />Leer en relación con una actividad del negocio le proporciona al analista una dimensión de las actividades del sistema. Entrevistar personal, ya sea directamente o a través de cuestionarios, también le ayuda y le dice algo más. Ninguno de los dos métodos da una información completa; por ejemplo, leer en relación con un viaje en jet no reproduce la experiencia de volar a unos 30 mil pies de altura. <br />La observación proporciona información de primera mano en relación con la forma en que se llevan a cabo las actividades. Las preguntas sobre el uso de documentos, la manera en la que se realizan las tareas y si ocurren los pasos específicos como se pre-establecierón, pueden contestarse rápidamente si se observan las operaciones. <br />Cuando observar <br />La observación es muy útil cuando el analista necesita ver de primera mano como se manejan los documentos, como se llevan a cabo los procesos y si ocurren los pasos especificados. Saber que buscar y como guiar su significado, también requiere de experiencia. Los observadores con experiencia captan quien utiliza los documentos y si encuentran dificultades; también están alertas para detectar documentos o registros que no se utilizan. <br />M U E S T R E O <br />Con frecuencia, en muchas empresas la información ya se encuentra disponible para que el analista conozca las actividades u operaciones con las cuales no esta familiarizado. Muchos tipos de registros e informes son accesibles si el analista sabe donde buscar. En la revisión de registros, los analistas examinan datos y descripciones que ya están escritos o registrados y en relación con el sistema y los departamentos de usuarios. Esta forma de encontrar datos puede servir como presentación del analista, si se realiza al iniciar el estudio, o como un termino de comparación de lo que sucede en el departamento con lo que los registros presentan como lo que debería suceder. <br />Recopilación de datos por medio de la inspección de registros. <br />El termino “registro” se refiere a los manuales escritos sobre políticas, regulaciones y procedimientos de operaciones estándar que la mayoría de las empresas mantienen como guía para gerentes y empleados. Los manuales que documentan o describen las operaciones para los procesos de datos existente, o sistemas de información que entran dentro del área de investigación, también proporcionan una visión sobre la forma en la que el negocio debería conducirse. Normalmente muestran los requerimientos y restricciones del sistema (como cantidad de transacciones o capacidad de almacenamiento de datos) y características de diseño (controles y verificación del procesamiento). <br />Los registro permiten que los analistas se familiaricen con algunas operaciones, oficinas de la compañía y relaciones formales a las que debe darse apoyo. No obstante, no muestran como producen de hecho las actividades, donde se ubica el poder verdadero para las decisiones, o como se realizan las tareas en la actualidad. Los otros métodos con objeto de encontrar datos estudiados en esta sección son más eficaces para proporcionar al analista este tipo de información. <br />Selección de los registros para revisión <br />En la mayor parte de las empresas los manuales de estándares sobre procedimientos de operación usualmente son obsoletos; a menudo no se mantienen al corriente lo suficiente para señalar los procedimientos existentes. Los diagramas de organización muestran como las diferentes unidades deberían relacionarse con otras; pero muchas no reflejan las operaciones actuales. <br />Actividades obligatorias: <br />Explique brevemente la realización de la entrevista <br />Liste cuatro situaciones que hagan adecuado el uso de cuestionarios. <br />¿Cómo debe ser la selección de quien recibirá el cuestionario? Defina lo que significa muestreo <br />Actividades sugeridas: <br />Liste tres razones sobre el porqué la observación es útil para el analista de sistemas en la organización Explique brevemente la fase de muestreo. <br />¿Qué tipos de información deben ser buscados en las entrevistas? <br />Recursos para ampliar el tema <br />Pags. 79–82, 109–123, 147–163, 175–181, Análisis y diseño de sistemas, Kendall & Kendall, 3ª edición, ed. Pearson educación, 1997. <br />UNIDAD 6<br />El objetivo primordial de esta unidad es darnos a conocer algunas de las ventajas, desventajas y las cualidades para que pueda ser valida la descomposición modular como son:<br />Independencia funcional<br />Acoplamiento<br />Cohesión<br />Comprensibilidad<br />Adaptabilidad<br /> <br /> El diseño modular es una metodología de desarrollo de programas complejos, que utiliza la filosofía top-down, conocida también como diseño descendente o refinamiento por pasos sucesivos<br />Sin dejar a un lado la arquitectura de dominio especifico en el cual se les dará una breve pero significativa introducción a los modelos genéricos y de referencia así como también alos distintos tipos que posee cada uno.<br />Esperando que la información contenida en esta investigación sea de vital ayuda no solo para nosotros sino también para todas las demás personas que necesiten saber acerca de estos temas y su contenido.<br /> <br />6.1 DESCOMPOSICION MODULAR<br />El diseño modular es una metodología de desarrollo de programas complejos, que utiliza la filosofía TOP-DOWN, conocida también como diseño descendente o refinamiento por pasos sucesivos; o comúnmente conocido por los programadores como “Divide y Vencerás”; puesto que enfrenta un problema desde lo abstracto (TOP) hacia lo particular (DOWN).<br />Esta técnica consiste en dividir el problema en un conjunto de subproblemas, y estos a su vez en otros de mayor facilidad de trabajo; generando los Módulos Funcionales.<br />La descomposición modular contribuye a las características deseables para la programación estructurada (y aplicable a nuestro quehacer diario); y que permite resolver cada módulo de forma independiente y, si no se sabe resolver alguno de ellos, puede asignársele un nombre y pasar al desarrollo de otro módulo y, más adelante retomar el módulo incompleto para darle solución al obtener mayor conocimiento sobre dicho proceso, es decir, la solución del problema no se detiene por falta de conocimiento de algún proceso en particular, esta técnica se conoce como Estrategia de scarlata O’hara.<br />Por lo consiguiente, podemos concluir que esta metodología presenta las siguientes ventajas:<br />Facilita el trabajo en grupos, puesto que la resolución del problema puede llevarse a cabo por varios programadores en forma paralela, gracias a la división del problema en diferentes módulos.<br />Contribuye a la comprensión y eleva el grado de legibilidad de los algoritmos.<br />Reduce el tiempo y el coste del desarrollo del software al permitir la reutilización de módulos anteriormente desarrollados en nuevos proyectos, que necesiten trabajar con estos módulos.<br />Agiliza el mantenimiento de los programas, al permitir la depuración de errores de forma independiente, con lo cual el software se adapta en mejor forma a su entorno cambiante.<br />Una descomposición modular debe poseer ciertas cualidades mínimas para que se pueda considerar suficientemente válid<br />Independencia funcional<br />Acoplamiento<br />Cohesión<br />Comprensibilidad<br />Adaptabilidad<br /> <br />INDEPENDENCIA FUNCIONAL<br />Al final de los documentos ADD y DDD debe haber una matriz REQUISITOS/COMPONNETES. En principio, cada función será realizada en un módulo distinto. Si las funciones son independientes los módulos tendrán independencia funcional.<br />Cada módulo debe realizar una función concreta o un conjunto de funciones afines. Es recomendable reducir las relaciones entre módulos al mínimo.<br />Para medir la independencia funcional hay dos criterios: acoplamiento y cohesión.<br />ACOPLAMIENTO<br />El grado de acoplamiento mide la interrelación entre dos módulos, según el tipo de conexión y la complejidad de la interface:<br />FUERTE,<br />POR CONTENIDO, cuando desde un módulo se pueden cambiar datos locales de otro<br />COMÚN, se emplea una zona común de datos a la que tienen acceso varios módulos<br />MODERADO,<br />DE CONTROL, la zona común es un dispositivo externo al que están ligados los módulos, esto implica que un cambio en el formato de datos afecta a todos estos módulos<br />POR ETIQUETA, en ontercambio de datos se realiza mediante una referencia a la estructura completa de datos (vector, pila, árbol, grafo, …)<br /> <br />DÉBIL,<br />DE DATOS, viene dado por los datos que intercambian los módulos. Es el mejor posible<br />SIN ACOPLAMIENTO DIRECTO, es el acoplamiento que no existe<br /> <br />COHESIÓN<br />Es necesario lograr que el contenido de cada módulo tenga la máxima coherencia. Para que el nº de módulos no sea demasiado elevado y complique el diseño se tratan de agrupar elementos afines y relacionados en un mismo módulo<br />ALTA<br />COHESIÓN ABSTRACCIONAL, se logra cuando se diseña el módulo como tipo abstracto de datos o como una clase de objetos<br />COHESIÓN FUNCIONAL, el módulo realiza una función concreta y específica<br />MEDIA<br />COHESIÓN SECUENCIAL, los elementos del módulo trabajan de forma secuencial<br />COHESIÓN DE COMUNICACIÓN, elementos que operan con le mismo conjunto de datos de entrada o de salida<br />COHESIÓN TEMPORAL, se agrupan elementos que se ejecutan en el mismo momento. Ej. Arrancar o parar dispositivos<br />BAJA<br />COHESIÓN LÓGICA, se agrupan elementos que realizan funciones similares. Ejs.: módulos de E/S o de tratamiento de errores<br />COHESIÓN COINCIDENTAL, es la peor y se produce cuando los elementos de un módulo no guardan relación alguna.<br /> <br />COMPRENSIBILIDAD<br />Para facilitar los cambios, el mantenimiento y la reutilización de módulos es necesario que cada uno sea comprensible de forma aislada. Para ello es bueno que posea independencia funcional, pero además es deseable:<br />IDENTIFICACIÓN: el nombre debe ser adecuado y descriptivo<br />DOCUMENTACIÓN: debe aclarar todos los detalles de diseño e implementación que no queden de manifiesto en el propio código<br />SIMPLICIDAD:las soluciones sencillas son siempre las mejores<br /> <br />ADAPTABILIDAD<br />La adaptación de un sistema resulta más dificil cuando no hay independencia funcional, es decir, con alto acoplamiento y baja cohesión, y cuando el diseño es poco comprensible. Otros factores para facilitar la adaptabilidad<br />PREVISIÓN, es necesario prever que aspectos del sistema pueden ser susceptibles de cambios en el futuro, y poner estos elementos en módulos independientes, de manera que su modificación afecte al menor número de módulos posible<br />ACCESIBILIDAD, debe resultar sencillo el acceso a los documentos de especificación, diseño, e implementación para obtener un conocimiento suficiente del sistema antes de proceder a su adaptación<br />CONSISTENCIA, después de cualquier adaptación se debe mantener la consistencia del sistema, incluidos los documentos afectados<br /> <br />DIAGRAMAS DE ESTRUCTURA MODULAR<br />La estructura modular, es decir, el conjunto de módulos de un programa y la forma en que se invocan unos a otros, se puede representar gráficamente mediante un diagrama de estructura modular. Esto es particularmente útil si el programa es complejo y consta de muchos módulos con relaciones complicadas entre sí.<br />En el diagrama se representan los módulos mediante cajas, en cuyo interior figura el nombre del módulo, unidos por líneas, que representan las interconexiones entre ellos. En cada línea se pueden escribir los parámetros de invocación y los datos devueltos por el módulo invocado.<br />El diagrama de estructura siempre tiene forma de árbol invertido. En la raíz figura el módulo principal, y de él “cuelgan” el resto de módulos en uno o varios niveles.<br />En el diagrama también se puede representar el tipo de relación entre los módulos. Las relaciones posibles se corresponden exactamente con los tres tipos de estructuras básicas de la programación estructurada:<br />Estructura secuencial: cuando un módulo llama a otro, después a otro, después a otro, etc.<br /> <br />Estructura selectiva: cuando un módulo llama a uno o a otro dependiendo de alguna condición<br /> <br /> <br />Estructura iterativa: cuando un módulo llama a otro (o a otros) en repetidas ocasiones<br />Las tres estructuras de llamadas entre módulos se representan con tres símbolos diferentes:<br /> <br /> <br /> <br /> <br /> <br />6.2 ARQUITECTURAS DE DOMINIO ESPECÍFICO<br /> <br />El reto para el diseño es diseñar el software y hardware para proporcionar características deseables a los sistemas distribuidos y, al mismo tiempo, minimizar los problemas propios a estos sistemas. Es necesario comprender las ventajas y desventajas de las diferentes arquitecturas de sistemas distribuidos. Aquí se tratan dos tipos genéricos de arquitecturas de sistemas distribuidos: Arquitectura cliente-servidor. En este caso el sistema puede ser visto como un conjunto de servicios que se proporcionan a los clientes que hacen uso de dichos servicios. Los servidores y los clientes se tratan de forma diferente en estos sistemas.<br />Arquitecturas de objetos distribuidos. Para esta arquitectura no hay distinción entre servidores y clientes, y el sistema puede ser visto como un conjunto de objetos que interaccionan cuya localización es irrelevante. No hay distinción entre un proveedor de servicios y el usuario de estos servicios. Ambas arquitecturas se usan ampliamente en la industria, pero la distribución de las aplicaciones generalmente tiene lugar dentro de una única organización. La distribución soportada es, por lo tanto, intraorganizacional. También se pueden tomar dos tipos más de arquitecturas distribuidas que son más adecuadas para la distribución interorganizacional: arquitectura de sistemas peer-to-peer (p2p) y arquitecturas orientadas a servicios. Los sistemas peer-to-peer han sido usados principalmente para sistemas personales, pero están comenzando a usarse para aplicaciones de empresa.<br />Los componentes en un sistema distribuido pueden implementarse en diferentes lenguajes de programación y pueden ejecutarse en tipos de procesadores completamente diferentes. Los modelos de datos, la representación de la información y los protocolos de comunicación pueden ser todos diferentes. Un sistema distribuido, por lo tanto, requiere software que pueda gestionar estas partes distintas, y asegurar que dichas partes se puedan comunicar e intercambiar datos. El término middleware se usa para hacer referencia a ese software; se ubica en medio de los diferentes componentes distribuidos del sistema. Bernstein (Bernstein, 1996) resume los tipos de middleware disponibles para soportar computación distribuida. El middleware es un software de propósito general que normalmente se compra como un componente comercial más que escribirse especialmente por los desarrolladores de la aplicación. Ejemplos de middleware son software para gestionar comunicaciones con bases de datos, administradores de transacciones, convertidores de datos y controladores de comunicación. Los sistemas distribuidos se desarrollan normalmente utilizando una aproximación orientada a objetos. Estos sistemas están formados por partes independientes pobremente integradas, cada una de las cuales puede interaccionar directamente con los usuarios o con otras partes del sistema. Algunas partes del sistema pueden tener que responder a eventos independientes. <br /> <br />Son modelos de arquitectura los cuales son específicos para algún dominio de aplicación.<br />Dos tipos de modelos de dominio específico son:<br />Modelos Genéricos. Estos son abstracciones de un número de sistemas reales y que encapsulan las características principales de estos sistemas.<br />Modelos de Referencia. Estos son más abstractos, son modelos idealistas. Proporcionan un significado de información con respecto a sistemas de clases y comparación de diversas arquitecturas.<br />Los modelos genéricos usualmente surgen de manera bottom-up… surgen de la práctica.<br />Los modelos de referencia son modelos top-down … surgen de estudios teóricos muy profundos.<br /> <br />MODELOS GENÉRICOS (1)<br />Un modelo de Compilador es un ejemplo conocido a través de otros modelos que existen en dominios de aplicaciones especializadas:<br />Analizador Léxico<br />Tabla de Símbolos<br />Analizador de Sintáxis<br />Analizador Semántico<br />Generador/Optimizador de Código<br />Un modelo de compilador genérico puede ser organizado de acuerdo a diversos modelos de arquitectura.<br /> <br /> <br />ARQUITECTURAS DE REFERENCIA (1)<br /> <br />Los modelos de referencias son derivados del estudio del dominio de una aplicación, en lugar del estudio de sistemas existentes.<br />Pueden ser utilizados como una base para… la implementación de un sistema o para comparar sistemas diversos.<br />Actúan como un estándar, contra el cual los sistemas que pueden ser evaluados.<br />El modelo OSI es un modelo en capas para sistemas de comunicación, y además, es un modelo de referencia.<br /> <br />La arquitectura de software es la responsable de la derivación de un modelo de sistema estructural, un modelo de control y un modelo de descomposición en subsistemas.<br />Los sistemas grandes rara vez conforman un modelo simple de arquitectura.<br />Los modelos de estructuración de un sistema incluyen modelos repositorios, los modelos cliente-servidor y los modelos de máquina abstracta.<br />Los modelos de control incluyen control centralizado y modelos manejadores de eventos.<br />Los modelos de descomposición modular incluyen los modelos orientados a<br />objetos y los modelos de flujo de datos.<br />Los modelos de dominio específico son abstracciones sobre el dominio de una aplicación.<br />Estos pueden ser construidos mediante la abstracción de sistemas existentes o pueden estar<br />basados en modelos de referencia (ideales).<br /> <br /> <br />CONCLUSION<br />En conclusión podemos decir que algo muy importante y de mucho realce en nuestra investigación fueron algunas de las ventajas de descomposición modular que son:<br />Facilita el trabajo en grupos, puesto que la resolución del problema puede llevarse a cabo por varios programadores en forma paralela, gracias a la división del problema en diferentes módulos.<br />Contribuye a la comprensión y eleva el grado de legibilidad de los algoritmos.<br />Reduce el tiempo y el coste del desarrollo del software al permitir la reutilización de módulos anteriormente desarrollados en nuevos proyectos, que necesiten trabajar con estos módulos.<br />Agiliza el mantenimiento de los programas, al permitir la depuración de errores de forma independiente, con lo cual el software se adapta en mejor forma a su entorno cambiante.<br /> <br />En cuanto a la estructura de dominio especifico podemos decir que no hay distinción entre servidores y clientes, y el sistema puede ser visto como un conjunto de objetos que interaccionan cuya localización es irrelevante.<br />No hay distinción entre un proveedor de servicios y el usuario de estos servicios. Ambas arquitecturas se usan ampliamente en la industria, pero la distribución de las aplicaciones generalmente tiene lugar dentro de una única organización.<br />