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 DesarrolloAnálisis de Sistemas IMiguel Ángel Delgado EstradaJuan Pablo García CavazosEdgar Othoniel Vázquez MercadoEdgar Eduardo González ElizondoAgosto/Septiembre 2011

2. IntroducciónSe 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. ObjetivosLa 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ónTodo 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 QuoDefinición de problemasDesarrollo TécnicoIntegración de Soluciones

5. IntroducciónAntes 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ónStatus 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ónRacoon 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ónEn 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 softwareSe 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 PROBLEMAYA 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 SISTEMASUNA 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 GLOBALPERO, ¿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.

14. PERO OTRO PROBLEMA QUE VAMOS A OBSERVAR MUY A MENUDO ES QUE ESTAS METODOLOGÍAS ESTÁN AGRUPADAS EN TRES GRANDES GRUPOS:LAS ORIENTADAS AL PROCESO, INDICAN QUÉ SECUENCIA DE PASOS HAY QUE SEGUIR PARA EL DESARROLLO DEL SISTEMA.

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

16. LAS ORIENTADAS A LAS TÉCNICAS, SON PROPUESTAS QUE SE PREOCUPAN POR EXPONER NUEVAS TÉCNICAS, O AMPLIAR LAS YA EXISTENTES, PARA ADECUARLAS A LAS NECESIDADES QUE EXISTAN.UNA PROPUESTA METODOLÓGICA PARA EL DESARROLLO DE SISTEMAS DE INFORMACIÓN GLOBAL DEBE ABORDAR LAS TRES ORIENTACIONES PUESTO QUE DEBE INDICAR AL DESARROLLADOR QUÉ HACER, CÓMO HACERLO Y QUÉ DEBE CONSEGUIRRELEVANCIA DEL PROBLEMAEL DESARROLLO DE UN SISTEMA DE INFORMACIÓN GLOBAL ES UNA TAREA COMPLICADA. NORMALMENTE REQUIERE TENER UN AMPLIO CONOCIMIENTO INFORMÁTICO, PUESTO QUE SUS NECESIDADES DE INFORMACIÓN, FUNCIONALIDAD Y DIFUSIÓN SUELEN SER MUY COMPLEJAS. DEBE OFRECER UN MARCO DE DESARROLLO, QUE SEA LO SUFICIENTEMENTE COMPLETO COMO PARA DAR SOPORTE A LOS DESARROLLADORES INFORMÁTICOS Y A LA VEZ SUFICIENTEMENTE INTUITIVO COMO PARA QUE, AL MENOS EN LAS PRIMERAS FASES DEL DESARROLLO, SEA FÁCIL DE ENTENDER POR LOS EXPERTOS EN LA MATERIA

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 RESOLVEREL 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 PROPUESTASANTES 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 DESIGNHDM (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 ENLACESHDM 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 METHOGOLOGYRMM 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 MISMA1.CONCEPTOS BÁSICOS DE RMMRMM 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 UNIFICADOCONCEPTOS 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 SecuencialTambié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ónComo 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 SoftwareEl 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ñoEl diseño del software es realmente un proceso de muchos pasos que se centra en cuatro atributos distintos de programas :Estructura de DatosArquitectura de SoftwareRepresentación de InterfazAlgoritmos.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ódigoEl 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. PruebasUna 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. MantenimientoEl 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 PrototiposUn 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 PrototiposEste 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 PrototiposEl 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 PrototiposLo 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

42. Modelo de Construcción de PrototiposDesventajas:El cliente ve lo que parece ser una versión de trabajo del software, sin tener conocimiento de que el prototipo, también esta junto con el “chicle y el cable de embalar” sin saber que con la prisa de hacer que funcione no se ha tenido en cuenta la calidad del software global o la facilidad de mantenimiento a largo plazo. Cuando se informa de que el producto se debe de construir otra vez para que se pueda hacer el prototipo un producto final. De forma demasiado frecuente la gestión del software es muy lenta.Modelo de Construcción de PrototiposDesventajas:El desarrollador, a menudo, hace compromisos de implementación para hacer que el prototipo funcione rápidamente. Se puede utilizar un sistema operativo o lenguaje de programación inadecuado simplemente porque esta disponible y es conocido; un algoritmo eficiente se puede implementar simplemente para demostrar la capacidad. Después de algún tiempo, el desarrollador debe familiarizarse con estas selecciones, y olvidarse de las razones por las que son inadecuadas. La selección menos ideal ahora es una parte integral del sistema.Modelo de Construcción de PrototiposAunque pueden surgir problemas, la construcción de prototipos puede ser un paradigma efectivo para la ingeniería del software. La clave es definir las reglas del juego al comienzo; es decir, el cliente y el desarrollador se deben de poner de acuerdo en que el prototipo se construya para servir como un mecanismo de definición de requisitos.

43. Modelo DRA

44. El Modelo DRAEl 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 DRASi 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 )

46. El Modelo DRACuando se utiliza principalmente para aplicaciones de sistemas de información, el enfoque DRA comprende las siguientes fases:Modelado de Gestión

47. Modelado de Datos

48. Modelado del Proceso

49. Generación de Aplicaciones

50. Pruebas y EntregaEl Modelo DRA

51. El Modelo DRAModelado 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 DRAModelado 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 DRAModelado 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 DRAGeneració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 DRAPruebas 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.

56. El Modelo DRADesventajas:Para proyectos grandes aunque por escalas, el DRA requiere recursos humanos suficientes como para crear el numero correcto de equipos DRA.