CENTRO DE BACHILLERATO TECNOLOGICO INDUSTRIAL Y SERVICIOS NOM.180 SUBMODULO 1.- Aplica la metodología espiral con programación orientada a objetos SUBMODULO 2.- Aplica la metodología de desarrollo rápido de aplicaciones con programación orientada a eventos Alumno: David Ramírez Aguilar Profesora: Tania Yosselin Juárez Rodríguez Semestre: 3° Grupo: “C” Especialidad: Programación Índice Introducción………………………………………………………………………………. 3 Metodología espiral……………………………………………………………………… 4 Metodología RAD………………………………………………………………………… 6 Metodología de Desarrollo en cascada………………………………………………... 8 Metodología de prototipos…………………………………………………………….. 10 Metodología incremental………………………………………………………………. 12 Bibliografía………………………………………………………………………………. 14 Conclusiones……………………………………………………………………………..14 INTRODUCCION La razón por la que se llevó a cabo esta investigación sobre los tipos de metodologías es para dar a entender lo que significa cada uno y sus funciones sobre la programación orientada a eventos u objetos CONCEPTO DE METODOLOGIA La metodología hace referencia al conjunto de procedimientos racionales utilizados para alcanzar el objetivo o la gama de objetivos que rige una investigación científica, una exposición doctrinal o tareas que requieran habilidades, conocimientos o cuidados específicos. Con frecuencia puede definirse la metodología como el estudio o elección de un método pertinente o adecuadamente aplicable a determinado objeto. No debe llamarse metodología a cualquier procedimiento, pues se trata de un concepto que en la gran mayoría de los casos resulta demasiado amplio, siendo preferible usar el vocablo método. También es de saber que existe una posición ametódica e incluso una tendencia de matizado: anarquismo epistemológico Metodología en espiral El desarrollo en espiral es un modelo de ciclo de vida del software definido por primera vez por Barry Boehm en 1986,1 utilizado generalmente en la ingeniería de software. Las actividades de este modelo se conforman en una espiral, en la que cada bucle o iteración representa un conjunto de actividades. Las actividades no están fijadas a ninguna prioridad, sino que las siguientes se eligen en función del análisis de riesgo, comenzando por el bucle interior ventajas El análisis del riesgo se hace de forma explícita y clara. Une los mejores elementos de los restantes modelos. Reduce riesgos del proyecto. Incorpora objetivos de calidad. Integra el desarrollo con el mantenimiento, etc. Añade la posibilidad de tener en cuenta mejoras y nuevos requerimientos sin romper con la metodología, ya que este ciclo de vida no es rígido ni estático. DESVENTAJAS Genera mucho tiempo en el desarrollo del sistema Modelo costoso Requiere experiencia en la identificación de riesgos CICLOS E ITERACIONES En cada vuelta o iteración hay que tener en cuenta: Los Objetivos: qué necesidad debe cubrir el producto. Alternativas: las diferentes formas de conseguir los objetivos de forma exitosa, desde diferentes puntos de vista como pueden ser: 1. Características: experiencia del personal, requisitos a cumplir, etc. 2. Formas de gestión del sistema. 3. Riesgo asumido con cada alternativa. Desarrollar y Verificar: Programar y probar el software. Si el resultado no es el adecuado o se necesita implementar mejoras o funcionalidades: Se planificaran los siguientes pasos y se comienza un nuevo ciclo de la espiral. La espiral tiene una forma de caracola y se dice que mantiene dos dimensiones, la radial y la angular: 1. Angular: Indica el avance del proyecto del software dentro de un ciclo. 2. Radial: Indica el aumento del coste del proyecto, ya que con cada nueva iteración se pasa más tiempo desarrollando. Este sistema es muy utilizado en proyectos grandes y complejos como puede ser, por ejemplo, la creación de un Sistema Operativo. Al ser un modelo de Ciclo de Vida orientado a la gestión de riesgo se dice que uno de los aspectos fundamentales de su éxito radica en que el equipo que lo aplique tenga la necesaria experiencia y habilidad para detectar y catalogar correctamente los riesgos. METODOLOGIA RAD La metodología RAD o DRA (por sus siglas en inglés Rapid Application Development y en castellano Desarrollo Rápido de Aplicaciones), se trata de un modelo de desarrollo de aplicaciones ágil. Es decir, hablamos del proceso de desarrollo de software. Este método abarca el desarrollo interactivo, la creación de prototipos y el empleo de utilidades CASE (Computer Aided Software Engineering). Además, la metodología RAD suele englobar también la usabilidad, utilidad y la rapidez de ejecución. Profundizando en qué es una metodología RAD, tenemos que tener claros cuales son sus premisas básicas. La primera persona que habló del método RAD fue James Martin a finales de los 80 y, actualmente, estamos ante uno de los métodos de desarrollo más populares, dentro de las técnicas de desarrollo ágil. James Martin consideró que para aplicar de forma correcta la metodología RAD tenemos que tener en cuenta 4 componentes: Personas, herramientas, metodología y gestión. En la actualidad, las empresas invierten gran parte de sus recursos en desarrollar aplicaciones que les permitan trabajar de forma más eficiente. Con la aparición de los modelos de desarrollo rápido de aplicaciones, podremos crear softwares de forma rápida y barata para satisfacer las necesidades empresariales sin invertir tanto tiempo y dinero. VENTAJAS Avances medibles: Al contar con numerosas iteraciones, componentes y prototipos desplegados cada cierto tiempo, se podrá medir y evaluar de forma sencilla el desarrollo del proyecto y, así, cumplir con los presupuestos. Productivos más pronto: La metodología DRA permitirá a los desarrolladores adoptar roles multidisciplinares que creen prototipos y códigos de trabajo de forma rápida, lo que supone ser productivos más rápido. Separación de los componentes del sistema: La metodología RAD exige a los diseñadores y desarrolladores a generar componentes funcionales e independientes por sí mismos, y así poder usarlos en en una versión o prototipo iterativo. De esta manera, cada elemento se reparte en compartimentos y se podrá modificar según evolucionen las necesidades del software y/o usuario. DESVENTAJAS Requiere sistemas modulares: Cuando aplicamos el método RAD, cada componente del sistema debe ser iterable y constatable por sí mismo, para poder ser modificados o intercambiados por cualquier miembro del equipo. Dificultad dentro de proyectos a gran escala: Cuando estemos ante un proyecto que implique muchas personas y aplicaciones, la flexibilidad puede llegar a ser un problema puesto que perderemos ligeramente el control sobre el diseño y el desarrollo. Exige mucha interactividad del usuario: Conseguir feedback del usuario desde una etapa temprana es muy útil pero, a la vez, puede ser una espada de doble filo ya que tendremos que aceptar todo tipo de críticas constructivas y ser competente a la hora de comunicarse con los usuarios. Metodología de desarrollo en cascada En Ingeniería de software el desarrollo en cascada, también llamado secuencial o ciclo de vida de un programa (denominado así por la posición de las fases en el desarrollo de esta, que parecen caer en cascada “por gravedad” hacia las siguientes fases), es el enfoque metodológico que ordena rigurosamente las etapas del proceso para el desarrollo de software, de tal forma que el inicio de cada etapa debe esperar a la finalización de la etapa anterior. 1 Al final de cada etapa, el modelo está diseñado para llevar a cabo una revisión final, que se encarga de determinar si el proyecto está listo para avanzar a la siguiente fase. Este modelo fue el primero en originarse y es la base de todos los demás modelos de ciclo de vida. La versión original fue propuesta por Winston W. Royce en 1970 y posteriormente revisada por Barry Boehm en 1980 e Ian Sommerville en 1985.2 Un ejemplo de una metodología de desarrollo en cascada es: 1. 2. 3. 4. 5. 6. 7. Análisis de requisitos. Diseño del sistema. Diseño del programa. Codificación. Pruebas. Despliegue del programa. Mantenimiento. De esta forma, cualquier error de diseño detectado en la etapa de prueba conduce necesariamente al rediseño y nueva programación del código afectado, aumentando los costos del desarrollo. La palabra cascada sugiere, mediante la metáfora de la fuerza de la gravedad, el esfuerzo necesario para introducir un cambio en las fases más avanzadas de un proyecto. Si bien ha sido ampliamente criticado desde el ámbito académico y la industria, sigue siendo el paradigma más seguido al día de hoy. VENTAJAS Realiza un buen funcionamiento en equipos débiles y productos maduros, por lo que se requiere de menos capital y herramientas para hacerlo funcionar de manera óptima. Es un modelo fácil de implementar y entender. Está orientado a documentos. Es un modelo conocido y utilizado con frecuencia. Promueve una metodología de trabajo efectiva: Definir antes que diseñar, diseñar antes que codificar. DESVENTAJAS En la vida real, un proyecto rara vez sigue una secuencia lineal, esto crea una mala implementación del modelo, lo cual hace que lo lleve al fracaso. El proceso de creación del software tarda mucho tiempo ya que debe pasar por el proceso de prueba y hasta que el software no esté completo no se opera. Esto es la base para que funcione bien. Cualquier error de diseño detectado en la etapa de prueba conduce necesariamente al rediseño y nueva programación del código afectado, aumentando los costos del desarrollo. Una etapa determinada del proyecto no se puede llevar a cabo a menos de que se haya culminado la etapa anterior. Metodología de modelo de prototipo El Modelo de prototipos, en Ingeniería de software, pertenece a los modelos de desarrollo evolutivo. El prototipo debe ser construido en poco tiempo, usando los programas adecuados y no se debe utilizar muchos recursos. El diseño rápido se centra en una representación de aquellos aspectos del software que serán visibles para el cliente o el usuario final. Este diseño conduce a la construcción de un prototipo, el cual es evaluado por el cliente para una retroalimentación; gracias a esta se refinan los requisitos del software que se desarrollará. La interacción ocurre cuando el prototipo se ajusta para satisfacer las necesidades del cliente. Esto permite que al mismo tiempo el desarrollador entienda mejor lo que se debe hacer y el cliente vea resultados a corto plazo. ETAPAS Comunicación Analogía Plan rápido. Modelado, diseño rápido Construcción del Prototipo Desarrollo, entrega y retroalimentación Entrega del final VENTAJAS Este modelo es útil cuando el cliente conoce los objetivos generales para el software, pero no identifica los requisitos detallados de entrada, procesamiento o salida. También ofrece un mejor enfoque cuando el responsable del desarrollo del software está inseguro de la eficacia de un algoritmo, de la adaptabilidad de un sistema operativo o de la forma que debería tomar la interacción humanomáquina Se puede reutilizar el código.. La construcción de prototipos se puede utilizar como un modelo del proceso independiente, se emplea más comúnmente como una técnica susceptible de implementarse dentro del contexto de cualquiera de los modelos del proceso expuestos. Sin importar la forma en que este se aplique, el paradigma de construcción de prototipos ayuda al desarrollado de software y al cliente a entender de mejor manera cuál será el resultado de la construcción cuando los requisitos estén satisfechos. De esta manera, este ciclo de vida en particular, involucra al cliente más profundamente para adquirir el producto. Inconvenientes El usuario tiende a crearse unas expectativas cuando ve el prototipo de cara al sistema final. A causa de la intención de crear un prototipo de forma rápida, se suelen desatender aspectos importantes, tales como la calidad y el mantenimiento a largo plazo, lo que obliga en la mayor parte de los casos a reconstruirlo una vez que el prototipo ha cumplido su función. Es frecuente que el usuario se muestre reacio a ello y pida que sobre ese prototipo se construya el sistema final, lo que lo convertiría en un prototipo evolutivo, pero partiendo de un estado poco recomendado. En aras de desarrollar rápidamente el prototipo, el desarrollador suele tomar algunas decisiones de implementación poco convenientes (por ejemplo, elegir un lenguaje de programación incorrecto porque proporcione un desarrollo más rápido). Con el paso del tiempo, el desarrollador puede olvidarse de la razón que le llevó a tomar tales decisiones, con lo que se corre el riesgo de que dichas elecciones pasen a formar parte del sistema final. Metodología de modelo incremental El modelo incremental de gestión de proyectos tiene como objetivo un crecimiento progresivo de la funcionalidad. Es decir, el producto va evolucionando con cada una de las entregas previstas hasta que se amolda a lo requerido por el cliente o destinatario. Este enfoque, que se usó inicialmente para proyectos de software aunque más tarde se aplicó a otros sectores, establece entregas parciales mediante un calendario de plazos. En cada una de ellas, el producto debe mostrar una evolución con respecto a la fecha anterior; nunca puede ser igual. La principal diferencia del modelo incremental con los modelos tradicionales es que las tareas están divididas en iteraciones, es decir, pequeños lapsos en los cuales se trabaja para conseguir objetivos específicos. Con los modelos tradicionales no pasaba esto; era necesario esperar hasta el final del proceso. Sin embargo, no se trata de iteraciones independientes. Por el contrario, están vinculadas de forma que cada una suponga un avance con respecto a la anterior. Otras características esenciales de este modelo son: Los incrementos son pequeños. Permite una fácil administración de las tareas en cada iteración. La inversión se materializa a corto plazo. Es un modelo propicio a cambios o modificaciones. Se adapta a las necesidades que surjan. Para que esto sea posible, se debe tener en cuenta que las iteraciones no pueden ser demasiado rígidas y que no existan tareas simultáneas. El modelo incremental exige un encadenamiento progresivo de cada tarea. Scrum y Kanban son las herramientas más conocidas que emplean este modelo de gestión. FASES 1. Requerimientos: son los objetivos centrales y específicos que persigue el proyecto. 2. Definición de las tareas y las iteraciones: teniendo en cuenta lo que se busca, el siguiente paso es hacer una lista de tareas y agruparlas en las iteraciones que tendrá el proyecto. Esta agrupación no puede ser aleatoria. Cada una debe perseguir objetivos específicos que la definan como tal. 3. Diseño de los incrementos: establecidas las iteraciones, es preciso definir cuál será la evolución del producto en cada una de ellas. Cada iteración debe superar a la que le ha precedido. Esto es lo que se denomina incremento. 4. Desarrollo del incremento: posteriormente se realizan las tareas previstas y se desarrollan los incrementos establecidos en la etapa anterior. 5. Validación de incrementos: al término de cada iteración, los responsables de la gestión del proyecto deben dar por buenos los incrementos que cada una de ellas ha arrojado. Si no son los esperados o si ha habido algún retroceso, es necesario volver la vista atrás y buscar las causas de ello. 6. Integración de incrementos: una vez son validados, los incrementos dan forma a lo que se denomina línea incremental o evolución del proyecto en su conjunto. Cada incremento ha contribuido al resultado final. 7. Entrega del producto: cuando el producto en su conjunto ha sido validado y se confirma su correspondencia con los objetivos iniciales, se procede a su entrega final. CONCLUSIONES La Programación Orientada a Objetos es actualmente el paradigma que más se utiliza para diseñar aplicaciones y programas informáticos. Son muchas sus ventajas, principalmente cuando necesitas resolver desafíos de programación complejos. Permite una mejor estructura de datos y reutilización del código, lo que facilita el ahorro de tiempo a largo plazo. Eso sí, para ello se requiere pensar bien en la estructura del programa, planificar al comienzo de la codificación, así como analizar los requisitos en clases simples y reutilizables que se pueden usar para diseñar instancias de objetos. BIBLIOGRAFIA https://es.wikipedia.org/wiki/Desarrollo_en_espiral https://www.incentro.com/es-es/blog/stories/metodologia-rad-desarrollo-rapidoaplicaciones/#:~:text=El%20Desarrollo%20R%C3%A1pido%20de%20Aplicaciones .&text=Este%20m%C3%A9todo%20abarca%20el%20desarrollo,y%20la%20rapide z%20de%20ejecuci%C3%B3n. https://es.wikipedia.org/wiki/Desarrollo_en_cascada https://es.wikipedia.org/wiki/Modelo_de_prototipos https://www.obsbusiness.school/blog/caracteristicas-y-fases-del-modeloincremental https://www.obsbusiness.school/blog/caracteristicas-y-fases-del-modeloincremental#:~:text=El%20modelo%20incremental%20de%20gesti%C3%B3n,por %20el%20cliente%20o%20destinatario.
