1) El documento presenta una metodología para el desarrollo de sistemas de información global que aborde las orientaciones de proceso, producto y técnicas. 2) Se comparan quince propuestas metodológicas existentes y se concluye que no cubren todos los aspectos requeridos por estos sistemas. 3) Se propone un marco de desarrollo que indique el proceso, técnicas y productos requeridos en cada fase para asegurar un producto de calidad.

1. Metodología de Desarrollo Análisis de Sistemas I Miguel Ángel Delgado Estrada Juan Pablo García Cavazos Edgar Othoniel Vázquez Mercado Edgar Eduardo González Elizondo Agosto/Septiembre 2011

2. Introducción Se selecciona un modelo de proceso según la naturaleza del proyecto y de la aplicación, los métodos y las herramientas a utilizarse, y los controles y entregas que se requieren.

3. Objetivos La Fase de Diseño de Sistemas tiene como objetivo describir como se va a desarrollar el sistema desde un punto de vista físico, donde se contemplará : El Diseño de la Arquitectura del Sistema. Diseño de la Estructura Física de Datos.

4. Introducción Todo desarrollo del software se puede desarrollar cono un bucle ( o ciclo ) de resolución de problemas, en el que se encuentran 4 etapas distintas… Status Quo Definición de problemas Desarrollo Técnico Integración de Soluciones

5. Introducción Antes de desarrollar un sistema se debe cuestionar y responder las siguientes preguntas ¿Cual es el problema a resolver? ¿Cuáles son las características de la entidad que se utiliza para resolver un problema? ¿Cómo se realizara la entidad (y solución)?

6. Introducción ¿Cómo se construirá la entidad? ¿Qué enfoque se va a utilizar para no contemplar los errores que se cometieron en el diseño y en la construcción de la entidad? Como se apoyara la entidad cuando usuarios soliciten correcciones, adaptaciones y mejoras de la entidad?

7. Introducción Status Quo: Representa el estado actual del suceso. Definición del Problema: Identifica el problema especifico a resolverse. Desarrollo Técnico : Resuelve el problema a travez de la aplicación de alguna tecnología. Integración de Soluciones : Ofrece los resultados a las que solicitan la solución en primer lugar…

9. Introducción Racoon sugiere un “modelo del Caos” que describe el desarrollo del software como una extensión desde el usuario hasta el desarrollador y la tecnología. Conforme progresa el trabajo hacia un sistema completo, las etapas descritas anteriormente se aplican recursivamente a las necesidades del usuario y a la especificación técnica del desarrollo del software.

10. Introducción En la ingeniería de software se puede dividir en 3 fases genéricas: Fase de definición. Fase de desarrollo. Fase de mantenimiento.

11. Proceso de software Se establece como un marco común del proceso definiendo un pequeño número de actividades del marco de trabajo que son aplicables a todos los proyectos de software sin importar tamaño o complejidad.

12. PLANTEAMIENTO DEL PROBLEMA YA HEMOS ANALIZADO EL ÁMBITO EN QUE NOS VAMOS A MOVER: LOS SISTEMAS DE INFORMACION GLOBAL. EL PROBLEMA QUE SE PLANTEA RESOLVER ES EL DE ELABORAR UN MARCO METODOLOGICO PARA EL DESARROLLO DE ESTE TIPO DE SISTEMAS UNA METODOLOGÍA PARA EL DESARROLLO DE SISTEMAS DE INFORMACIÓN GLOBAL: DEBE OFRECER LAS HERRAMIENTAS Y TÉCNICAS SUFICIENTES COMO PARA CUBRIR TODOS ESOS ASPECTOS QUE SE PUEDEN ENCONTRAR EL UN SISTEMA DE ESTE TIPO. ASÍ, EN LA FIGURA 1 ENCONTRAMOS UN ESQUEMA CON LAS CARACTERÍSTICAS QUE DEBE CONTEMPLAR Y ESTUDIAR EL PROCESO METODOLÓGICO DE LA PROPUESTA

13. FIGURA 1: ASPECTOS DE LOS SISTEMAS DE INFORMACIÓN GLOBAL PERO, ¿QUÉ DEBE OFRECER LA METODOLOGÍA?. PROPUESTAS METODOLÓGICAS PARA DIFERENTES ENTORNOS YA QUE NINGUNA DE ELLAS VA A ADECUARSE AL CIEN POR CIEN A LOS SISTEMAS DE INFORMACIÓN GLOBAL, PRINCIPALMENTE PORQUE ESTÁN ORIENTADOS A UN TIPO DE SISTEMA CONCRETO.

15. LAS ORIENTADAS AL PRODUCTO, QUE SE PREOCUPAN ESENCIALMENTE POR LO QUE HAY QUE ENTREGAR AL REALIZAR LAS FASES.

17. A LA HORA DE SU DESARROLLO EL EQUIPO DE TRABAJO SE ENCUENTRA CON EL PROBLEMA DE QUÉ METODOLOGÍA USAR. LAS METODOLOGÍAS ACTUALES, TANTO EL MARCO DE LOS SISTEMAS MULTIMEDIA COMO EL MARCO DE LA WEB, NO CONTEMPLAN TODAS LAS NECESIDADES DE ESTOS SISTEMAS CON LA PROFUNDIDAD ADECUADA. ES NECESARIO OFRECER UN MARCO DE DESARROLLO QUE INDIQUE QUÉ HACER, CÓMO HACERLO Y QUÉ PRESENTAR EN CADA MOMENTO PARA ASEGURAR UN PRODUCTO QUE SE ADECUE A LAS NECESIDADES Y QUE SEA DE FÁCIL MANTENIMIENTO, EN DEFINITIVA QUE SEA DE CALIDAD.

18. ASPECTOS RESUELTOS Y POR RESOLVER EL PROCESO DE TRABAJO QUE SE ESTÁ SIGUIENDO EN DICHO PROYECTO ES EL QUE SE MUESTRA EN LA FIGURA 2.

19. LA PRIMERA TAREA A REALIZAR FUE ESTUDIAR QUÉ PROPUESTAS METODOLÓGICAS SE PODRÍAN USAR EN EL DESARROLLO DE UN SISTEMA SOFTWARE. TRAS ESTE ESTUDIO, SE CONCLUYO QUE: 1.- LAS METODOLOGÍAS ACTUALES NO CUBRÍAN TODOS LOS ASPECTOS QUE REQUIEREN ESTOS SISTEMAS. 2- ESTAS PROPUESTAS NO OFRECÍAN UN MARCO QUE INDICARA EL PROCESO A SEGUIR, LAS TÉCNICAS A APLICAR Y LOS PRODUCTOS A OBTENER. 3- LA MAYORÍA DE ELLAS COINCIDEN EN MUCHOS ASPECTOS QUE SON ADECUADOS Y QUE HAY QUE TENER EN CUENTA PARA LA PROPUESTA DE NUESTRA METODOLOGÍA

20. COMPARATIVA DE PROPUESTAS ANTES DE COMENZAR CON DICHO EJEMPLO Y CON EL ESTUDIOVCOMPARATIVO, ES NECESARIO INTRODUCIR EL ÁMBITO EN EL QUE NOS MOVEMOS. SE VAN A PRESENTAR UN TOTAL DE QUINCE PROPUESTAS. ALGUNA DE ELLAS SE MUEVEN EN EL ENTORNO DE LA MULTIMEDIA, OTRAS EN EL ENTORNO DE LA WEB Y OTRAS SON MUCHO MÁS GENÉRICAS. MUCHAS DE LAS METODOLOGÍAS QUE SE VAN A ESTUDIAR HACEN USO DE MODELOS COMO LOS ERDS, DIAGRAMAS DE CLASES, DIAGRAMAS DE CASOS DE USO, ETC. Y DE LENGUAJES DE MODELADO COMO UML O LAS PROPUESTAS DE OMT, QUE NO SE EXPLICAN EN ESTE DOCUMENTO.

22. HDM- A MODEL-BASED APPROACH TO HYPERTEXT APLICATION DESIGN HDM (HYPERMEDIA DESIGN MODEL) [GARZOTTO 1993] ES UNO DE LOS PRIMEROS MÉTODOS DESARROLLADO PARA DEFINIR LA ESTRUCTURA Y LA NAVEGACIÓN PROPIA DE LAS APLICACIONES MULTIMEDIA. HDM SE BASA EN EL MODELO ENTIDAD-RELACIÓN, AUNQUE AMPLÍA EL CONCEPTO DE ENTIDAD E INTRODUCE NUEVOS ELEMENTOS, COMO LAS UNIDADES O LOS ENLACES HDM PROPONE UN CONJUNTO DE ELEMENTOS QUE PERMITEN AL DISEÑADOR ESPECIFICAR UNA APLICACIÓN. ESTOS ELEMENTOS SON LAS ENTIDADES, LOS COMPONENTES, LAS PERSPECTIVAS, LAS UNIDADES Y LOS ENLACES. TODOS ESTOS ELEMENTOS PUEDEN INCORPORARSE EN LA SEMÁNTICA DEL CLÁSICO MODELO ENTIDAD-RELACIÓN

23. RMM- RELATIONSHIP MANAGEMENT METHOGOLOGY RMM ES PROPUESTA EN 1995 POR TOMAS IZSAKOWITZ, ARNOLD KAMIS Y MARIOS KOUNFARIS [ISAKOWITZ 1995]. SE PUEDE CONSIDERAR UNA METODOLOGÍA PUES ASUME LAS ETAPAS DE ANÁLISIS Y DISEÑO. RMM PROPONE UN PROCESO BASADO EN 7 FASES O ETAPAS EN LAS QUE EL DISEÑADOR VA MODELANDO LA ESTRUCTURA DE LA APLICACIÓN Y LAS POSIBILIDADES DE NAVEGACIÓN DE LA MISMA 1.CONCEPTOS BÁSICOS DE RMM RMM ASUME LAS EXTENSIONES QUE HDM INCLUYE EN LOS CLÁSICOS E-R Y AÑADE UN NUEVO CONCEPTO QUE DENOMINA SLICE. UN SLICE ES UN SUBCONJUNTO DE ATRIBUTOS DE UNA ENTIDAD QUE VAN A SER PRESENTADOS DE FORMA AGRUPADA AL USUARIO. DE ESTA FORMA, UNA APLICACIÓN ESTARÁ FORMADA POR ENTIDADES CUYOS ATRIBUTOS SON AGRUPADOS EN SLICES.

24. Basándose en la técnica de los casos de uso, tal y como la propone UML [Jacobson 1999], esta metodología propone capturar los requerimientos del sistema que servirán para realizar el posterior diseño de la aplicación. En la figura 20 vemos uno de los posibles casos de uso para nuestro ejemplo. Mediante este caso de uso representaríamos la opción del usuario a dar de alta. Diseño conceptual Partiendo de los casos de uso, se debe modelar la aplicación sin entrar en aspectos de interfaz o de navegación. Se pretende conseguir un modelo de clases que represente al sistema. Para ello, se deben aplicar las técnicas de la orientación a objetos. En este caso, el resultado aplicado a nuestro ejemplo sería equivalente al que se mostró en la figura 7.Fase 3- Diseño de colaboración En esta fase es necesario aplicar la técnica de los diagramas de colaboración propuesta por UML [Jacobson 1999], para representar las relaciones entre las clases del sistema.

25. EL PROCESO UNIFICADO CONCEPTOS BÁSICOS DEL PROCESO UNIFICADO COMO YA SE HA COMENTADO, UML ES UNA PROPUESTA DE LENGUAJE DE MODELADO DE DATOS REALIZADA POR BOOCH, RUMBAUGH Y JACOBSON, ENTRE OTROS. LA PRIMERA VERSIÓN DE UML NACE EN 1997. UML ES UN LENGUAJE GRÁFICO PARA MODELAR SISTEMAS SOFTWARE SEGÚN LA ORIENTACIÓN A OBJETOS, EN ÉL SE DESCRIBEN UNA SERIE DE MODELOS QUE NOS PERMITEN REPRESENTAR DIFERENTES ASPECTOS DE NUESTROS SISTEMAS SOFTWARE. NO ES OBJETIVO DE ESTE TRABAJO EL DESCRIBIR LAS POSIBILIDADES DE MODELADO QUE OFRECE UML [BOOCH 1999] [RUMBAUGH 1999]. EN BASE A UML, LOS MISMOS AUTORES REALIZAN UNA PROPUESTA DE METODOLOGÍA DENOMINADA PROCESO UNIFICADO [JACOBSON 1999], QUE ES LA QUE SE VERÁ EN ESTE DOCUMENTO. EL PROCESO UNIFICADO COMPRENDE UN CONJUNTO DE ACTIVIDADES QUE HAY REALIZAR PARA LLEVAR A CABO EL DESARROLLO DE PRODUCTO SOFTWARE. A CONTINUACIÓN VAMOS A DESCRIBIR ESTA PROPUESTA.

26. Método Lineal Secuencial

27. Método Lineal Secuencial También llamado “Ciclo de vida básico” o “Método de Cascada”, es un modelo que sugiere un enfoque sistemático, secuencial, para el desarrollo del software que comienza en un nivel de sistemas y progresa con el análisis, diseño, codificación, pruebas y mantenimiento.

28. Ingeniería de Sistemas / Información

29. Ingeniería de Sistemas / Información Como el software siempre forma parte de un sistema mas grande, el trabajo comienza estableciendo requisitos de todos los elementos del sistema y asignando al software algún subgrupo de estos requisitos. Esto es esencial cuando el software se debe interconectar con otros elementos como hardware, base de datos, personas. La ingeniería y el análisis de sistemas comprende los requisitos que se recogen en el nivel de sistemas con una pequeña parte de análisis y diseño. Esto abarca los requisitos que se recogen en el nivel de empresa estratégico, y en el nivel de área de negocio.

30. Análisis de los requisitos del Software El proceso de reunión de requisitos se intensifica y se centra en el software. Para comprender la naturaleza del sistema a construirse, el analista de software debe comprender el dominio de información del software, así como la función requerida, comportamiento, rendimiento e interconexión.

31. Diseño El diseño del software es realmente un proceso de muchos pasos que se centra en cuatro atributos distintos de programas : Estructura de Datos Arquitectura de Software Representación de Interfaz Algoritmos. El proceso del diseño traduce requisitos en una representación del software donde se puede evaluar su calidad antes de que comience la codificación.

32. Generación de Código El diseño debe de traducir en una forma legible por la maquina. El paso de generación de código lleva a cabo esta tarea. Si se lleva a cabo el diseño de una forma detallada, la generación de código se realiza mecánicamente.

33. Pruebas Una vez que se ha generado el código, comienzan las pruebas del programa. Este proceso se centra en los procesos lógicos internos del software, asegurando que todas las sentencias se han comprobado, u en los procesos externos funcionales; es decir, realizar las pruebas para la detección de errores, y asegurar que la entrada definida produce resultados reales de acuerdo con los resultados requeridos.

34. Mantenimiento El software indudablemente sufrirá cambios después de ser entregado al cliente. Se producirán cambios porque se han encontrado errores, porque el software debe acoplarse a los cambios de su entorno externo. El soporte o Mantenimiento del software vuelve a aplicar cada una de las fases precedentes a un programa ya existente y no a uno nuevo.

35. Método Lineal Secuencial Desventajas : Los proyectos reales rara vez siguen erl modelo secuencial que propone el modelo. A menudo es difícil que el cliente exponga explícitamente todos los requisitos. El cliente debe de tener paciencia. Una versión de trabajo de los programadores no estará disponible hasta que el proyecto este muy avanzado. Un grave error puede ser desastroso si no se detecta hasta que se revisa el programa.

36. Modelo de Construcción de Prototipos

37. Modelo de Construcción de Prototipos Un cliente, define un conjunto de objetivos generales para el software, pero no se identifica los requisitos detallados de entrada, proceso o salida. En otros casos, el responsable del desarrollo del software puede no estar seguro de la eficacia de un algoritmo, de la capacidad de adaptación de un sistema operativo, o de la forma en que se debería tomarse la interacción hombre-maquina. En estas y en otras muchas situaciones, un paradigma de construcción de prototipos puede ofrecer el mejor enfoque.

38. Modelo de Construcción de Prototipos Este proceso comienza con la recolección de requisitos. El desarrollador y el cliente encuentran y definen los objetivos globales para el software, identifican los requisitos conocidos y aéreas de esquemas de donde es obligatoria mas definición. Entonces aparece un “diseño rápido”. El diseño rápido se centra en una representación de esos aspectos del software que serán visibles para el usuario/cliente. El diseño rápido lleva a la construcción del prototipo.

39. Modelo de Construcción de Prototipos El prototipo lo evalúa el cliente/usuario y se utiliza para refinar los requisitos del software a desarrollar. La iteración ocurre cuando el prototipo se pone a punto de satisfacer las necesidades del cliente, permitiendo al mismo tiempo que el desarrollador comprenda mejor lo que se necesita hacer.

40. Modelo de Construcción de Prototipos Lo ideal seria que el prototipo sirviera como un mecanismo para identificar los requisitos del software. Si se construye un prototipo de trabajo, el desarrollador intenta hacer uso de los fragmentos del programa ya existente o aplica herramientas que permiten generar rápidamente programas de trabajo.

41. Modelo de Construcción de Prototipos

43. Modelo DRA

44. El Modelo DRA El Desarrollo Rápido de Aplicaciones (Rapid Application Development : RAD ) es un modelo de proceso del desarrollo del software lineal secuencial que enfatiza un ciclo de desarrollo extremadamente corto. Este modelo es una adaptación a “ alta velocidad” del modelo lineal secuencial en el que se logra el desarrollo rápido utilizando una construcción basada en componentes.

45. El Modelo DRA Si se comprende bien los requisitos y se limita el ámbito del proyecto, el proceso DRA permite al equipo de desarrollo crear un “sistema completamente funcional” dentro de periodos cortos de tiempo ( por ejemplo, de 60 o 90 días )

47. Modelado de Datos

48. Modelado del Proceso

49. Generación de Aplicaciones

51. El Modelo DRA Modelado de Gestión :El flujo de información entre las funciones de gestión se modela de forma que responda a las siguientes preguntas : ¿Qué Información conduce el proceso de gestión? Que información se genera? ¿Quién la genera? ¿A dónde va la información? ¿Quién la procesa?

52. El Modelo DRA Modelado de Datos : El flujo de información definido como parte de la fase de modelado de gestión refine como un conjunto de objetos de datos necesarios para apoyar la empresa. Se definen las características de cada uno de los objetos y las relaciones entre estos objetos.

53. El Modelo DRA Modelado del Proceso : Los objetos de datos definidos en la fase de modelado de datos quedan transformados para lograr el flujo de información necesario para implementar una función de gestión. Las descripciones del proceso se crean para añadir, modificar, suprimir o recuperar un objeto de datos.

54. El Modelo DRA Generación de Aplicaciones: El DRA asume la utilización de técnicas de cuarta generación. En lugar de crear software con lenguajes de programación de tercera generación, el proceso DRA trabaja para volver a utilizar componentes de programas ya existentes ( cuando es posible ) o a crear componentes reutilizables ( cuando sea necesario ). En todos los casos se utilizaban herramientas para facilitar la construcción del software.

55. El Modelo DRA Pruebas y entrega: Como el proceso DRA enfatiza la reutilización, ya se han comprobado muchos de los componentes de los programas. Esto reduce tiempo de pruebas, sin embargo, se deben probar todos los componentes nuevos y se deben ejecutar todas las interfaces a fondo.

58. El Modelo DRA Desventajas: DRA no es adecuado cuando los riesgos técnicos son altos. Esto ocurre cuando una nueva aplicación hace uso de tecnologías nuevas, o cuando el software nuevo requiere un alto grado de interoperativiad con programas de computadora ya existentes.