Metodología de Desarrollo<br />Análisis de Sistemas I<br />Miguel Ángel Delgado Estrada<br />Juan Pablo García Cavazos<br ...
Introducción<br />Se selecciona un modelo de proceso según la naturaleza del proyecto y de la aplicación, los métodos y la...
Objetivos<br />La Fase de Diseño de Sistemas tiene como objetivo describir como se va a desarrollar el sistema desde un pu...
Introducción<br />Todo desarrollo del software se puede desarrollar cono un bucle ( o ciclo ) de resolución de problemas, ...
Introducción<br />Antes de desarrollar un sistema se debe cuestionar y responder las siguientes preguntas<br />¿Cual es el...
Introducción<br />¿Cómo se construirá la entidad?<br />¿Qué enfoque se va a utilizar para no contemplar los errores que se...
Introducción<br />Status Quo:  Representa el estado actual del suceso.<br />Definición del Problema: Identifica el problem...
Introducción<br />Racoon sugiere un “modelo del Caos” que describe el desarrollo del software como una extensión desde el ...
Introducción<br />En la ingeniería de software se puede dividir en 3 fases genéricas:<br />Fase de definición.<br />Fase d...
Proceso de software<br />Se establece como un marco común del proceso definiendo un pequeño número de actividades del marc...
PLANTEAMIENTO DEL PROBLEMA<br />YA HEMOS ANALIZADO EL ÁMBITO EN QUE NOS VAMOS A MOVER: LOS SISTEMAS DE INFORMACION GLOBAL....
FIGURA 1: ASPECTOS DE LOS SISTEMAS DE INFORMACIÓN GLOBAL<br />PERO, ¿QUÉ DEBE OFRECER LA METODOLOGÍA?. PROPUESTAS METODOLÓ...
PERO OTRO PROBLEMA QUE VAMOS A OBSERVAR MUY A MENUDO ES QUE ESTAS METODOLOGÍAS ESTÁN AGRUPADAS EN TRES GRANDES GRUPOS:<br ...
LAS ORIENTADAS AL PRODUCTO, QUE SE PREOCUPAN ESENCIALMENTE POR LO QUE HAY QUE ENTREGAR AL REALIZAR LAS FASES.
LAS ORIENTADAS A LAS TÉCNICAS, SON PROPUESTAS QUE SE PREOCUPAN POR EXPONER NUEVAS TÉCNICAS, O AMPLIAR LAS YA EXISTENTES, P...
A LA HORA DE SU DESARROLLO EL EQUIPO DE TRABAJO SE ENCUENTRA CON EL PROBLEMA DE QUÉ METODOLOGÍA USAR. <br />LAS METODOLOGÍ...
ASPECTOS RESUELTOS Y POR RESOLVER<br />EL PROCESO DE TRABAJO QUE SE ESTÁ SIGUIENDO EN DICHO PROYECTO ES EL QUE SE MUESTRA ...
LA PRIMERA TAREA A REALIZAR FUE ESTUDIAR QUÉ PROPUESTAS METODOLÓGICAS SE PODRÍAN USAR EN EL DESARROLLO DE UN SISTEMA SOFTW...
COMPARATIVA DE PROPUESTAS<br />ANTES DE COMENZAR CON DICHO EJEMPLO Y CON EL ESTUDIOVCOMPARATIVO, ES NECESARIO INTRODUCIR E...
 HDM- A MODEL-BASED APPROACH TO HYPERTEXT APLICATION DESIGN<br />HDM (HYPERMEDIA DESIGN MODEL) [GARZOTTO 1993] ES UNO DE L...
 RMM- RELATIONSHIP MANAGEMENT METHOGOLOGY<br />RMM ES PROPUESTA EN 1995 POR TOMAS IZSAKOWITZ, ARNOLD KAMIS Y MARIOS KOUNFA...
Basándose en la técnica de los casos de uso, tal y como la propone UML [Jacobson <br />1999], esta metodología propone cap...
EL PROCESO UNIFICADO<br />CONCEPTOS BÁSICOS DEL PROCESO UNIFICADO <br />COMO YA SE HA COMENTADO, UML ES UNA PROPUESTA DE L...
Método Lineal Secuencial<br />
Método Lineal Secuencial<br />También llamado “Ciclo de vida básico” o “Método de Cascada”, es un modelo que sugiere un en...
Ingeniería de Sistemas / Información<br />
Ingeniería de Sistemas / Información<br />Como el software siempre forma parte de un sistema mas grande, el trabajo comien...
Análisis de los requisitos del Software<br />El proceso de reunión de requisitos se intensifica y se centra en el software...
Diseño<br />El diseño del software es realmente un proceso de muchos pasos que se centra en cuatro atributos distintos de ...
Generación de Código<br />El diseño debe de traducir en una forma legible por la maquina. El paso de generación de código ...
Pruebas<br />Una vez que se ha generado el código, comienzan las pruebas del programa. Este proceso se centra en los proce...
Mantenimiento<br />El software indudablemente sufrirá cambios después de ser entregado al cliente. Se producirán cambios p...
Método Lineal Secuencial <br />Desventajas :<br />Los proyectos reales rara vez siguen erl modelo secuencial que propone e...
Modelo de Construcción de Prototipos<br />
Modelo de Construcción de Prototipos<br />Un cliente, define un conjunto de objetivos generales para el software, pero no ...
Modelo de Construcción de Prototipos<br />Este proceso comienza con la recolección de requisitos. El desarrollador y el cl...
Modelo de Construcción de Prototipos<br />El prototipo lo evalúa el cliente/usuario y se utiliza para refinar los requisit...
Modelo de Construcción de Prototipos<br />Lo ideal seria que el prototipo sirviera como un mecanismo para identificar los ...
Modelo de Construcción de Prototipos<br />
Modelo de Construcción de Prototipos<br />Desventajas:<br /><ul><li>El cliente ve lo que parece ser una versión de trabajo...
Modelo  DRA<br />
El Modelo DRA<br />El Desarrollo Rápido de Aplicaciones (Rapid Application Development : RAD ) es un modelo de proceso del...
El Modelo DRA<br />Si se comprende bien los requisitos y se limita el ámbito del proyecto, el proceso DRA permite al equip...
El Modelo DRA<br />Cuando se utiliza principalmente para aplicaciones de sistemas de información, el enfoque DRA comprende...
Modelado de Datos
Modelado del Proceso
Generación de Aplicaciones
Pruebas y Entrega</li></li></ul><li>El Modelo DRA<br />
El Modelo DRA<br />Modelado de Gestión :El flujo de información entre las funciones de gestión se modela de forma que resp...
El Modelo DRA<br />Modelado de Datos :<br />El flujo de información definido como parte de la fase de modelado de gestión ...
El Modelo DRA<br />Modelado del Proceso :<br />Los objetos de datos definidos en la fase de modelado de datos quedan trans...
El Modelo DRA<br />Generación de Aplicaciones:<br />El DRA asume la utilización de técnicas de cuarta generación. En lugar...
El Modelo DRA<br />Pruebas y entrega:<br />Como el proceso DRA enfatiza la reutilización, ya se han comprobado muchos de l...
El Modelo DRA<br />Desventajas:<br /><ul><li>Para proyectos grandes aunque por escalas, el DRA requiere recursos humanos s...
Próxima SlideShare
Cargando en…5
×

Equipo2

428 visualizaciones

Publicado el

0 comentarios
0 recomendaciones
Estadísticas
Notas
  • Sé el primero en comentar

  • Sé el primero en recomendar esto

Sin descargas
Visualizaciones
Visualizaciones totales
428
En SlideShare
0
De insertados
0
Número de insertados
3
Acciones
Compartido
0
Descargas
5
Comentarios
0
Recomendaciones
0
Insertados 0
No insertados

No hay notas en la diapositiva.

Equipo2

  1. 1. Metodología de Desarrollo<br />Análisis de Sistemas I<br />Miguel Ángel Delgado Estrada<br />Juan Pablo García Cavazos<br />Edgar Othoniel Vázquez Mercado<br />Edgar Eduardo González Elizondo<br />Agosto/Septiembre 2011<br />
  2. 2. Introducción<br />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.<br />
  3. 3. Objetivos<br />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á :<br />El Diseño de la Arquitectura del Sistema. <br />Diseño de la Estructura Física de Datos. <br />
  4. 4. Introducción<br />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…<br />Status Quo<br />Definición de problemas<br />Desarrollo Técnico<br />Integración de Soluciones<br />
  5. 5. Introducción<br />Antes de desarrollar un sistema se debe cuestionar y responder las siguientes preguntas<br />¿Cual es el problema a resolver?<br />¿Cuáles son las características de la entidad que se utiliza para resolver un problema?<br />¿Cómo se realizara la entidad (y solución)?<br />
  6. 6. Introducción<br />¿Cómo se construirá la entidad?<br />¿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?<br />Como se apoyara la entidad cuando usuarios soliciten correcciones, adaptaciones y mejoras de la entidad?<br />
  7. 7. Introducción<br />Status Quo: Representa el estado actual del suceso.<br />Definición del Problema: Identifica el problema especifico a resolverse.<br />Desarrollo Técnico : Resuelve el problema a travez de la aplicación de alguna tecnología.<br />Integración de Soluciones : Ofrece los resultados a las que solicitan la solución en primer lugar…<br />
  8. 8.
  9. 9. Introducción<br />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.<br />
  10. 10. Introducción<br />En la ingeniería de software se puede dividir en 3 fases genéricas:<br />Fase de definición.<br />Fase de desarrollo.<br />Fase de mantenimiento.<br />
  11. 11. Proceso de software<br />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.<br />
  12. 12. PLANTEAMIENTO DEL PROBLEMA<br />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<br />UNA METODOLOGÍA PARA EL DESARROLLO DE SISTEMAS DE INFORMACIÓN GLOBAL: <br />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<br />
  13. 13. FIGURA 1: ASPECTOS DE LOS SISTEMAS DE INFORMACIÓN GLOBAL<br />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.<br />
  14. 14. PERO OTRO PROBLEMA QUE VAMOS A OBSERVAR MUY A MENUDO ES QUE ESTAS METODOLOGÍAS ESTÁN AGRUPADAS EN TRES GRANDES GRUPOS:<br /><ul><li>LAS ORIENTADAS AL PROCESO, INDICAN QUÉ SECUENCIA DE PASOS HAY QUE SEGUIR PARA EL DESARROLLO DEL SISTEMA.
  15. 15. LAS ORIENTADAS AL PRODUCTO, QUE SE PREOCUPAN ESENCIALMENTE POR LO QUE HAY QUE ENTREGAR AL REALIZAR LAS FASES.
  16. 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.</li></li></ul><li>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 CONSEGUIR<br />RELEVANCIA DEL PROBLEMA<br />EL DESARROLLO DE UN SISTEMA DE <br />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. <br />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<br />
  17. 17. A LA HORA DE SU DESARROLLO EL EQUIPO DE TRABAJO SE ENCUENTRA CON EL PROBLEMA DE QUÉ METODOLOGÍA USAR. <br />LAS METODOLOGÍAS ACTUALES, TANTO EL MARCO DE LOS SISTEMAS MULTIMEDIA <br />COMO EL MARCO DE LA WEB, NO CONTEMPLAN TODAS LAS NECESIDADES DE ESTOS SISTEMAS CON LA PROFUNDIDAD ADECUADA. <br />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.<br />
  18. 18. ASPECTOS RESUELTOS Y POR RESOLVER<br />EL PROCESO DE TRABAJO QUE SE ESTÁ SIGUIENDO EN DICHO PROYECTO ES EL QUE SE MUESTRA EN LA FIGURA 2.<br />
  19. 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: <br />1.- LAS METODOLOGÍAS ACTUALES NO CUBRÍAN TODOS LOS ASPECTOS QUE REQUIEREN ESTOS SISTEMAS.<br />2- ESTAS PROPUESTAS NO OFRECÍAN UN MARCO QUE INDICARA EL PROCESO A SEGUIR, LAS TÉCNICAS A APLICAR Y LOS PRODUCTOS A OBTENER.<br />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<br />
  20. 20. COMPARATIVA DE PROPUESTAS<br />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. <br />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.<br />
  21. 21.
  22. 22. HDM- A MODEL-BASED APPROACH TO HYPERTEXT APLICATION DESIGN<br />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<br />HDM PROPONE UN CONJUNTO DE ELEMENTOS QUE PERMITEN AL DISEÑADOR ESPECIFICAR UNA <br />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<br />
  23. 23. RMM- RELATIONSHIP MANAGEMENT METHOGOLOGY<br />RMM ES PROPUESTA EN 1995 POR TOMAS IZSAKOWITZ, ARNOLD KAMIS Y MARIOS KOUNFARIS <br />[ISAKOWITZ 1995]. SE PUEDE CONSIDERAR UNA METODOLOGÍA PUES ASUME LAS ETAPAS DE <br />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<br />1.CONCEPTOS BÁSICOS DE RMM<br />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. <br />
  24. 24. Basándose en la técnica de los casos de uso, tal y como la propone UML [Jacobson <br />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.<br />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.<br />
  25. 25. EL PROCESO UNIFICADO<br />CONCEPTOS BÁSICOS DEL PROCESO UNIFICADO <br />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. <br />
  26. 26. Método Lineal Secuencial<br />
  27. 27. Método Lineal Secuencial<br />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.<br />
  28. 28. Ingeniería de Sistemas / Información<br />
  29. 29. Ingeniería de Sistemas / Información<br />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.<br />
  30. 30. Análisis de los requisitos del Software<br />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.<br />
  31. 31. Diseño<br />El diseño del software es realmente un proceso de muchos pasos que se centra en cuatro atributos distintos de programas :<br />Estructura de Datos<br />Arquitectura de Software<br />Representación de Interfaz<br />Algoritmos.<br />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.<br />
  32. 32. Generación de Código<br />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.<br />
  33. 33. Pruebas<br />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.<br />
  34. 34. Mantenimiento<br />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.<br />
  35. 35. Método Lineal Secuencial <br />Desventajas :<br />Los proyectos reales rara vez siguen erl modelo secuencial que propone el modelo.<br />A menudo es difícil que el cliente exponga explícitamente todos los requisitos.<br />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.<br />
  36. 36. Modelo de Construcción de Prototipos<br />
  37. 37. Modelo de Construcción de Prototipos<br />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.<br />
  38. 38. Modelo de Construcción de Prototipos<br />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.<br />
  39. 39. Modelo de Construcción de Prototipos<br />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.<br />
  40. 40. Modelo de Construcción de Prototipos<br />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.<br />
  41. 41. Modelo de Construcción de Prototipos<br />
  42. 42. Modelo de Construcción de Prototipos<br />Desventajas:<br /><ul><li>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.</li></li></ul><li>Modelo de Construcción de Prototipos<br />Desventajas:<br /><ul><li>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.</li></li></ul><li>Modelo de Construcción de Prototipos<br />Aunque 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.<br />
  43. 43. Modelo DRA<br />
  44. 44. El Modelo DRA<br />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.<br />
  45. 45. El Modelo DRA<br />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 )<br />
  46. 46. El Modelo DRA<br />Cuando se utiliza principalmente para aplicaciones de sistemas de información, el enfoque DRA comprende las siguientes fases:<br /><ul><li>Modelado de Gestión
  47. 47. Modelado de Datos
  48. 48. Modelado del Proceso
  49. 49. Generación de Aplicaciones
  50. 50. Pruebas y Entrega</li></li></ul><li>El Modelo DRA<br />
  51. 51. El Modelo DRA<br />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 : <br />¿Qué Información conduce el proceso de gestión?<br />Que información se genera?<br />¿Quién la genera?<br />¿A dónde va la información?<br />¿Quién la procesa?<br />
  52. 52. El Modelo DRA<br />Modelado de Datos :<br />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.<br />
  53. 53. El Modelo DRA<br />Modelado del Proceso :<br />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.<br />
  54. 54. El Modelo DRA<br />Generación de Aplicaciones:<br />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.<br />
  55. 55. El Modelo DRA<br />Pruebas y entrega:<br />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.<br />
  56. 56. El Modelo DRA<br />Desventajas:<br /><ul><li>Para proyectos grandes aunque por escalas, el DRA requiere recursos humanos suficientes como para crear el numero correcto de equipos DRA.
  57. 57. DRA requiere clientes y desarrolladores comprometidos en las rápidas actividades necesarias para completar un sistema en un marco de tiempo abreviado. Si no hay un compromiso por ninguna de las partes constituyentes, los proyectos fracasaran.</li></li></ul><li>El Modelo DRA<br />Desventajas:<br />No todos los tipos de aplicaciones son apropiados para DRA. Si un sistema no se puede modularizar adecuadamente, la construcción de los componentes necesarios para DRA será problemático. Si esta en juego el alto rendimiento, y se va a conseguir el rendimiento convirtiendo interfaces en componentes de sistemas, el enfoque DRA puede que no funcione.<br />
  58. 58. El Modelo DRA<br />Desventajas:<br />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.<br />

×