1. Fundamentos de Sistemas de Información center-5000473710.11000065000.-500080010059000593090007/09/2011495004500007/09/2011445003576955590005930900Juan Manuel Pavon OrtizEn esta unidad el alumno será capaz de analizar, sintetizar, organizar y planificar la información provenientes de diversas fuentes de información, así mismo será tendrá la habilidad para comunicarse de manera oral y escrita con las personas, tendrá la capacidad de toma de decisiones y dar resolución a problemáticas implicadas en la toma de decisiones.6050045000Juan Manuel Pavon OrtizEn esta unidad el alumno será capaz de analizar, sintetizar, organizar y planificar la información provenientes de diversas fuentes de información, así mismo será tendrá la habilidad para comunicarse de manera oral y escrita con las personas, tendrá la capacidad de toma de decisiones y dar resolución a problemáticas implicadas en la toma de decisiones.center5900059309001100004500075000582930049000492823500<br />-603885-490527 Instituto Tecnológico Superior De Acayucan<br />4629155213350054864052133500Ingeniería en Informática <br />Fundamentos de Sistemas de Información <br />Modelos prescriptivos del desarrollo de Sistemas de información<br />Karina Del Milagro Ruiz Vergara<br />III Semestre <br />Juan Manuel Pavon Ortiz<br />45339050673000Septiembre 2011<br />Contenido TOC quot;
1-3quot;
Modelos prescriptivos. PAGEREF _Toc303190327 1El modelo en cascada. PAGEREF _Toc303190328 2Modelo De Desarrollo Incremental PAGEREF _Toc303190329 4Modelos evolutivos PAGEREF _Toc303190330 5Modelos Especializados de Proceso PAGEREF _Toc303190331 7El Proceso Unificado de Desarrollo de software. PAGEREF _Toc303190332 7Centrado en la Arquitectura PAGEREF _Toc303190333 8Modelo de Proceso de Software IEEE PAGEREF _Toc303190334 9Herramienta CASE PAGEREF _Toc303190335 10<br />Modelos prescriptivos.<br />¿Qué es Prescriptivo?<br />Dice que son aquellos textos cuyo mensaje se emite con el fin de regular o guiar el comportamiento del receptor en una situación determinada.<br />Como por ejemplo: un medico nos prescribe un medicamento, o un trabajador nos prescribe una lista de materiales para comenzar a realizar su trabajo.<br />Cualquier organización de ingeniería del software debe describir un conjunto único de actividades dentro del marco de trabajo para el (los) proceso(s) de software que adopte. También debe llenar cada actividad del marco de trabajo con un conjunto de acciones de ingeniería del software, y definir cada acción en cuanto a un conjunto de tareas que identifique el trabajo (y los productos del trabajo) que deben completarse para alcanzar las metas de desarrollo. Después, la organización debe adaptar el modelo de proceso resultante y ajustarlo a la naturaleza específica de cada proyecto, a las personas que lo realizarán, y el ambiente en el que se ejecutará el trabajo. Sin importar el modelo del proceso seleccionado, los ingenieros de software han elegido de manera tradicional un marco de trabajo genérico para el proceso, el cual incluye las siguientes actividades dentro del marco: comunicación, planeación, modelado, construcción y desarrollo.<br />Definen un conjunto de distintas actividades, acciones, tareas fundamentos y productos de trabajo que se requieren para desarrollar software de alta calidad.Es importante porque proporciona estabilidad, control y organización a una actividad. Cualquier organización de ingeniería del software debe describir un conjunto único de actividades dentro del marco de trabajo para el proceso de software que adopte. Cada organización escoge el modelo de proceso que se <br />acondicione a sus necesidades, los ingenieros por su parte dentro del marco de trabajo deben apegarse a las siguientes actividades:<br />Comunicación<br />Planeación <br />Modelado<br />Desarrollo.<br />El modelo en cascada.<br />Existen ocasiones en que los requisitos de un problema se entienden de una manera razonable: cuando el trabajo fluye desde la comunicación a través del despliegue de una manera casi lineal. Esta situación se encuentra a veces cuando es necesario hacer adaptaciones o mejorías bien definidas a un sistema existente (por ejemplo, una adaptación a un software contable debido a los cambios en las regulaciones del gobierno). Esto puede ocurrir también en un número limitado de proyectos de nuevos desarrollos, pero sólo cuando los requerimientos están bien definidos y son estables en forma razonable, -1905212471000El modelo en cascada, algunas veces llamado el ciclo de vida clásico, sugiere un enfoque sistemático, secuencial hacia el desarrollo del software, que se inicia con la especificación de requerimientos del cliente y que continúa con la planeación, el modelado, la construcción y el despliegue para culminar en el soporte del software terminado. El modelo en cascada es el paradigma más antiguo para la ingeniería del software. Sin embargo, en las décadas pasadas, las críticas a este modelo de proceso han ocasionado que aun sus más fervientes practicantes hayan cuestionado su eficacia. Ingeniería y Análisis del SistemaAnálisis de los RequisitosDiseñoCodificaciónPruebaMantenimientoIngeniería y Análisis del SistemaAnálisis de los RequisitosDiseñoCodificaciónPruebaMantenimiento Entre los problemas que algunas veces se encuentran al aplicar el modelo en cascada están:<br />Es muy raro que los proyectos reales sigan el flujo secuencial que propone el modelo. A pesar de que el modelo lineal incluye iteraciones, lo hace de manera indirecta. Como resultado, los cambios confunden mientras el equipo de proyecto actúa. <br />Con frecuencia es difícil para el cliente establecer todos los requisitos de manera explícita. El modelo en cascada lo requiere y se enfrentan dificultades al incorporar la incertidumbre natural presente en el inicio de muchos proyectos. <br />El cliente debe tener paciencia. Una versión que funcione de los programas estará disponible cuando el proyecto esté muy avanzado. Un error grave será desastroso si no se detecta antes de la revisión del programa. En un análisis interesante de proyectos reales, Bradac concluyó que la naturaleza lineal del modelo en cascada conduce a quot;
estados de bloqueoquot;
en los cuales algunos miembros del equipo del proyecto deben esperar a otros para terminar tareas dependientes. De hecho, el tiempo de espera puede superar el que se aplica en el trabajo productivo. El estado de bloqueo tiende a ser más común al principio y al final del proceso secuencial. En la actualidad, el trabajo del software está acelerado y sujeto a una cadena infinita de cambios (de características, funciones y contenido de la información). Con frecuencia, el modelo en cascada no es apropiado para dicho trabajo. Sin embargo, puede servir como un modelo de proceso útil en situaciones donde los requerimientos están fijos y donde el trabajo se realiza, hasta su conclusión, de una manera lineal.<br />Modelo De Desarrollo Incremental<br />Los riesgos asociados con el desarrollo de sistemas largos y complejos son enormes. Una forma de reducir los riesgos es construir sólo una parte del sistema, reservando otros aspectos para niveles posteriores. El desarrollo incremental es el proceso de construcción siempre incrementando subconjuntos de requerimientos del sistema. Típicamente, un documento de requerimientos es escrito al capturar todos los requerimientos para el sistema completo.<br />Note que el desarrollo incremental es 100% compatible con el modelo cascada. El desarrollo incremental no demanda una forma específica de observar el desarrollo de algún otro incremento. Así, el modelo cascada puede ser usado para administrar cada esfuerzo de desarrollo, como se muestra en la figura. -2540106489500<br />El modelo de desarrollo incremental provee algunos beneficios significativos para los proyectos:<br />Construir un sistema pequeño es siempre menos riesgoso que construir un sistema grande.<br />Al ir desarrollando parte de las funcionalidades, es más fácil determinar si los requerimientos planeados para los niveles subsiguientes son correctos.<br />Si un error importante es realizado, sólo la última iteración necesita ser descartada.<br />Reduciendo el tiempo de desarrollo de un sistema (en este caso en incremento del sistema) decrecen las probabilidades que esos requerimientos de usuarios puedan cambiar durante el desarrollo.<br />Si un error importante es realizado, el incremento previo puede ser usado.<br />Los errores de desarrollo realizados en un incremento, pueden ser arreglados antes del comienzo del próximo incremento.<br />En muchas situaciones los requisitos iniciales del software están bien definidos en forma razonable, pero el enfoque global del esfuerzo de desarrollo excluye un proceso puramente lineal. Además, quizá haya una necesidad imperiosa de proporcionar de manera rápida un conjunto limitado de funcionalidad para el usuario y después refinarla y expandirla en las entregas posteriores del software. En estos casos se elige un modelo de proceso diseñado para producir el software en forma incremental.<br />Modelos evolutivos<br />El software evoluciona con el tiempo. Los requisitos del usuario y del producto suelen cambiar conforme se desarrolla el mismo. Las fechas de mercado y la competencia hacen que no sea posible esperar a poner en el mercado un producto absolutamente completo, por lo que se debe introducir una versión funcional limitada de alguna forma para aliviar las presiones competitivas.<br />En esas u otras situaciones similares los desarrolladores necesitan modelos de progreso que estén diseñados para acomodarse a una evolución temporal o progresiva, donde los requisitos centrales son conocidos de antemano, aunque no estén bien definidos a nivel detalle.<br />En el modelo Cascada y Cascada Realimentado no se tiene en cuenta la naturaleza evolutiva del software, se plantea como estático con requisitos bien conocidos y definidos desde el inicio.<br />Los evolutivos son modelos iterativos, permiten desarrollar versiones cada vez más completas y complejas, hasta llegar al objetivo final deseado; incluso evolucionar más allá, durante la fase de operación.<br />Los modelos «iterativo incremental» y «espiral» (entre otros) son dos de los más conocidos y utilizados del tipo evolutivo.<br />En el modelo evolutivo, los requerimientos son cuidadosamente examinados, y sólo esos que son bien comprendidos son seleccionados para el primer incremento. Los desarrolladores construyen una implementación parcial del sistema que recibe sólo estos requerimientos.<br />El sistema es entonces desarrollado, los usuarios lo usan, y proveen retroalimentación a los desarrolladores. Basada en esta retroalimentación, la especificación de requerimientos es actualizada, y una segunda versión del producto es desarrollada y desplegada. El proceso se repite indefinidamente.<br />Note que el desarrollo evolutivo es 100% compatible con el modelo cascada. El desarrollo evolutivo no demanda una forma específica de observar el desarrollo de algún incremento. Así, el modelo cascada puede ser usado para administrar cada esfuerzo de desarrollo. Obviamente, el desarrollo incremental y evolutivo puede ser combinado también.<br />Todo lo que uno tiene que hacer es construir un subconjunto de requerimientos conocidos (incremental), y comprender al principio que muchos nuevos requerimientos es probable que aparezcan cuando el sistema sea desplegado o desarrollado.<br />El desarrollo de software en forma evolutiva requiere un especial cuidado en la manipulación de documentos, programas, datos de test, etc. desarrollados para distintas versiones del software. Cada paso debe ser registrado, la documentación debe ser recuperada con facilidad, los cambios deben ser efectuados de una manera controlada.<br />Características:<br />Se desarrolla una implementación inicial y se refina a través de diferentes versiones, las actividades de especificación, desarrollo y validación se llevan a cabo concurrentemente y con realimentación entre ellas la especificación se puede desarrollar de forma creciente.<br />Problemas:<br />El proceso no es visible, los cambios tienden a corromper la estructura del software, se requieren herramientas y técnicas especiales.<br />Modelos Especializados de Proceso<br />Desarrollo Basado en Componentes: Variación del Modelo en espiral donde las aplicaciones se construyen usando componentes sw previamente empaquetados llamados clases.<br />Métodos Formales: notación matemática rigurosa utilizada para especificar, diseñar y verificar sistemas basados en computadora.<br />Programación Orientada a Aspectos: provee un proceso para definir, especificar, diseñar y construir aspectos de sw como interfaces, seguridad y gestión de memoria que impactan varias partes del sistema en desarrollo.<br />El Proceso Unificado de Desarrollo de software.<br />Representa un número de modelos de desarrollo basados en componentes que han sido propuestos en la industria. Utilizando el Lenguaje de Modelado Unificado (UML), el proceso unificado define los componentes que se utilizarán para construir el sistema y las interfaces que conectarán los componentes. Utilizando una combinación del desarrollo incremental e iterativo, el proceso unificado define la función del sistema aplicando un enfoque basado en escenarios (desde el punto de vista del usuario). Entonces acopla la función con un marco de trabajo arquitectónico que identifica la forma que tomará el software.<br />Proceso que se organiza en cuatro fases: inicio, elaboración, construcción y transición, y que se estructura en torno a cinco flujos de trabajo fundamentales: recopilación de requisitos, análisis, diseño, implementación y pruebas. Proceso que se describe en términos de un modelo de negocio, el cual esta a su vez estructurado en función de tres bloques de construcción primordiales trabajadores, actividades y artefactos.<br />Centrado en la Arquitectura<br />La arquitectura de un sistema software se describe mediante diferentes vistas del sistema en construcción. El concepto de arquitectura software incluye los aspectos estáticos y dinámicos más significativos del sistema. La arquitectura es una vista del diseño completo con las características más importantes resaltadas, dejando los detalles de lado.<br />Arquitectura: Conjunto de decisiones significativas acerca de la organización de un sistema software, la selección de los elementos estructurales a partir de los cuales se compone el sistema, las interfaces entre ellos, su comportamiento, sus colaboraciones, y su composición.<br />Los casos de uso y la arquitectura están profundamente relacionados. Los casos de uso deben encajar en la arquitectura, y a su vez la arquitectura debe permitir el desarrollo de todos los casos de uso requeridos, actualmente y a futuro. El arquitecto desarrolla la forma o arquitectura a partir de la comprensión de un conjunto reducido de casos de uso fundamentales o críticos (usualmente no mas el 10 % del total). En forma resumida, podemos decir que el arquitecto:<br />Crea un esquema en borrador de la arquitectura comenzando por la parte no específica de los casos de uso (por ejemplo la plataforma) pero con una comprensión general de los casos de uso fundamentales.<br />A continuación, trabaja con un conjunto de casos de uso claves o fundamentales. Cada caso de uso es especificado en detalle y realizado en términos de subsistemas, clases, y componentes. <br />A medida que los casos de uso se especifican y maduran, se descubre más de la arquitectura, y esto a su vez lleva a la maduración de más casos de uso.<br />Este proceso continúa hasta que se considere que la arquitectura es estable.<br />Modelo de Proceso de Software IEEE<br />A través de la historia de la ingeniería del software ha evolucionado un conjunto de conceptos fundamentales de diseño de software, aunque el grado de interés en cada concepto ha variado con los años, han pasado la prueba del tiempo ofreciendo cada uno al ingeniero de software fundamentos sobre el cual pueden aplicarse métodos de diseño más elaborados.<br />El diseño de Software juega un papel importante en el desarrollo de software lo cual permite al ingeniero de software producir varios modelos del sistema o producto de que se va a construir el mismo que forman una especie de plan de la solución de la aplicación. <br />Estos modelos puede evaluarse en relación con su calidad y mejorarse antes de generar código, de realizar pruebas y de que los usuarios finales se vean involucrados a gran escala. El diseño es el sitio en el que se establece la calidad del software.<br />Diseño es definido como: quot;
El proceso de definición de la arquitectura, componentes, interfaces y otras características de un sistema o componente que resulta de este procesoquot;
[IEEE610.12-90].<br />Se desarrolla y se centra su el diseño, con una existencia lógica, de instrucciones sobre un soporte. Es un producto que no se gasta con el uso como otros y repararlo no significa restaurarlo al estado original, sino corregir algún defecto de origen lo que significa que el producto entregado posee defectos, que podrán ser solucionados en la etapa de mantenimiento. [Piattini, 1996]<br />El diccionario IEEE estándar de ingeniería del software [IEEE, 1990] dice que son software: “los programas de ordenador, los procedimientos y, posiblemente la documentación asociada y los datos relativos a la operación del sistema informática”, no limitándose al código.<br />El estándar IEEE 6.10-1990 [IEEE,1990] da la definición de calidad como “el grado con el que un sistema, componente o proceso cumple con los requisitos especificados y las necesidades o expectativas del cliente o usuario”.<br />Pressman [1993] la define como “concordancia del software con los requisitos explícitamente establecidos, con los estándares de desarrollo expresamente fijados y con los requisitos implícitos, no establecidos formalmente que desea el usuario”.<br />La aplicación de estándares de desarrollo y de normas para el software permitirá lograr calidad técnica del mismo. La calidad del software se puede ver a nivel empresa como implantación de un sistema de calidad y a nivel de proyecto aplicando las técnicas de evaluación y control de la calidad del software a lo largo del ciclo de vida.<br />Herramienta CASE<br />Las herramientas CASE (Computer Aided SoftwareEngineering, Ingeniería de Software Asistida por Computadora) son diversas aplicaciones informáticas destinadas a aumentar la productividad en el desarrollo de software reduciendo el coste de las mismas en términos de tiempo y de dinero. Estas herramientas nos pueden ayudar en todos los aspectos del ciclo de vida de desarrollo del software en tareas como el proceso de realizar un diseño del proyecto, cálculo de costes, implementación de parte del código automáticamente con el diseño dado, compilación automática, documentación o detección de errores entre otras.<br />Sistema de software que intenta proporcionar ayuda automatizada a las actividades del proceso de software. Los sistemas CASE a menudo se utilizan como apoyo al método.<br />Objetivos<br />Mejorar la productividad en el desarrollo y mantenimiento del software.<br />Aumentar la calidad del software.<br />Reducir el tiempo y coste de desarrollo y mantenimiento de los sistemas Informáticos.<br />Mejorar la planificación de un proyecto<br />Aumentar la biblioteca de conocimiento informático de una empresa ayudando a la búsqueda de soluciones para los requisitos.<br />Automatizar el desarrollo del software, la documentación, la generación de código, las pruebas de errores y la gestión del proyecto.<br />Ayuda a la reutilización del software, portabilidad y estandarización de la documentación<br />Gestión global en todas las fases de desarrollo de software con una misma herramienta.<br />Facilitar el uso de las distintas metodologías propias de la ingeniería del software.<br />Evolución de las Herramientas CASE<br />A inicios de los 80’sAyuda en la documentación por computadora.Diagramación asistida por computadora.Herramientas de análisis y diseño.A mediados de los 80’sDiseño automático de análisis y pruebas.Repositorios automáticos de información deSistemas.Al final de los 80’sGeneración automática de código desdeEspecificaciones de diseño.A inicios de los 90’sMetodología Inteligente.Interface de Usuario reusable como unaMetodología de desarrollo.<br />Bibliografia:<br />1. Laudon K. Laudon, J.; Sistema de Información Gerencial. Administración de la<br />Empresa Digital. 10ª Edición; Ed. Pearson Prentice Hall. 2008.<br />2. Cohen y Asin.; Sistemas de Información un enfoque de toma de decisiones. 3ª<br />Edición. Mc Graw Hill.2000.<br />3. EDWARDS, CHRIS; JOHN WARD y ANDY BYTHEWAY. Fundamentos de Sistemas<br />de Información. 2da. Edición. Ed. Prentice Hall. 1998.<br />4. PRESSMAN, ROGER S.; Ingeniería de software un Enfoque practico; Ed. Mc. Graw<br />Hill. 2007.<br />5. SOMMERVILLE, IAN; Ingeniería de Software, Edit. Addison Wesley; 2005.<br />6. KENDALL, KENNETH E. Y KENDALL, JULIE E. Análisis y Diseño de Sistemas. 6ª<br />Edición; Ed. Pearson Educación México. 2005.<br />7. Van Vliet Hans. Software Engineering. Ed. John Wiley & Sons; 1993.<br />8. Laudon K. Laudon, J.; Sistema de Información Gerencial. Administración de la<br />Empresa Digital. 10ª Edición; Ed. Pearson Prentice Hall. 2008.<br />9. Cohen y Asin.; Sistemas de Información un enfoque de toma de decisiones. 3ª<br />Edición. Mc Graw Hill.2000.<br />10. EDWARDS, CHRIS; JOHN WARD y ANDY BYTHEWAY. Fundamentos de Sistemas<br />de Información. 2da. Edición. Ed. Prentice Hall. 1998.<br />11. PRESSMAN, ROGER S.; Ingeniería de software un Enfoque practico; Ed. Mc. Graw<br />Hill. 2007.<br />12. SOMMERVILLE, IAN; Ingeniería de Software, Edit. Addison Wesley; 2005.<br />13. KENDALL, KENNETH E. Y KENDALL, JULIE E. Análisis y Diseño de Sistemas. 6ª<br />Edición; Ed. Pearson Educación México. 2005.<br />14. van Vliet Hans. Software Engineering. Ed. John Wiley & Sons; 1993.<br />