Instituto Privado Tecnológico Spencer W. Kimball
Bachiller Industrial y Perito en Computación
Quinto Grado
Curso: Análisis...
Introducción.
En el siguiente trabajo veremos la utilidad de las metodologías las cuales se
basan en una combinación de lo...
Contenido
METODOLOGÍAS PARADESARROLLO DE SOFTWARE ...........................................1
Ciclo de vida del software ...
INSTITUTO TECNOLOGICO SPENCERW.KIMBALL PROFESOR: ALVSRO MRTINEZ
1
DELVIN ESTUARDO FELIX TORRES
METODOLOGÍAS PARA DESARROLL...
INSTITUTO TECNOLOGICO SPENCERW.KIMBALL PROFESOR: ALVSRO MRTINEZ
2
DELVIN ESTUARDO FELIX TORRES
actualmente Java o C# de Mi...
INSTITUTO TECNOLOGICO SPENCERW.KIMBALL PROFESOR: ALVSRO MRTINEZ
3
DELVIN ESTUARDO FELIX TORRES
SCRUM
Como se explicó en el...
INSTITUTO TECNOLOGICO SPENCERW.KIMBALL PROFESOR: ALVSRO MRTINEZ
4
DELVIN ESTUARDO FELIX TORRES
A. El modelo en cascada
Seg...
INSTITUTO TECNOLOGICO SPENCERW.KIMBALL PROFESOR: ALVSRO MRTINEZ
5
DELVIN ESTUARDO FELIX TORRES
desarrollo empieza con las ...
INSTITUTO TECNOLOGICO SPENCERW.KIMBALL PROFESOR: ALVSRO MRTINEZ
6
DELVIN ESTUARDO FELIX TORRES
en la reutilización. Este e...
INSTITUTO TECNOLOGICO SPENCERW.KIMBALL PROFESOR: ALVSRO MRTINEZ
7
DELVIN ESTUARDO FELIX TORRES
Estos programas se originan...
INSTITUTO TECNOLOGICO SPENCERW.KIMBALL PROFESOR: ALVSRO MRTINEZ
8
DELVIN ESTUARDO FELIX TORRES
llamado modelo en cascada (...
INSTITUTO TECNOLOGICO SPENCERW.KIMBALL PROFESOR: ALVSRO MRTINEZ
9
DELVIN ESTUARDO FELIX TORRES
METODOLOGÍA RUP
El Proceso ...
INSTITUTO TECNOLOGICO SPENCERW.KIMBALL PROFESOR: ALVSRO MRTINEZ
10
DELVIN ESTUARDO FELIX TORRES
Fases de desarrollo del so...
INSTITUTO TECNOLOGICO SPENCERW.KIMBALL PROFESOR: ALVSRO MRTINEZ
11
DELVIN ESTUARDO FELIX TORRES
TIPOS
El modelo espiral tu...
INSTITUTO TECNOLOGICO SPENCERW.KIMBALL PROFESOR: ALVSRO MRTINEZ
12
DELVIN ESTUARDO FELIX TORRES
vigente en algunos desarro...
INSTITUTO TECNOLOGICOSPENCER W.KIMBALL PROFESOR: ALVARO MARTINEZ
DELVIN ESTUARDO FELIX TORRES
Conclusión.
El desarrollo de...
INSTITUTO TECNOLOGICOSPENCER W.KIMBALL PROFESOR: ALVARO MARTINEZ
DELVIN ESTUARDO FELIX TORRES
Recomendación.
Lo único que ...
INSTITUTO TECNOLOGICOSPENCER W.KIMBALL PROFESOR: ALVARO MARTINEZ
DELVIN ESTUARDO FELIX TORRES
E- GRAFIAS.
http://www.acade...
Próxima SlideShare
Cargando en…5
×

Metodologías para desarrollo de software

541 visualizaciones

Publicado el

Mi tarea

Publicado en: Educación
0 comentarios
0 recomendaciones
Estadísticas
Notas
  • Sé el primero en comentar

  • Sé el primero en recomendar esto

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

No hay notas en la diapositiva.

Metodologías para desarrollo de software

  1. 1. Instituto Privado Tecnológico Spencer W. Kimball Bachiller Industrial y Perito en Computación Quinto Grado Curso: Análisis de Sistemas. Cat: Álvaro Martínez Tema: Metodologías para el desarrollo de software Nombre: Delvin Estuardo Félix Torres Sección: Única Clave: 4 Carnet: 21CP Fecha: 20/05/2015
  2. 2. Introducción. En el siguiente trabajo veremos la utilidad de las metodologías las cuales se basan en una combinación de los modelos de proceso genéricos (cascada, evolutivo, incremental, espiral entre otros).los cuales no son de mucha utilidad para la precisión los artefactos, roles y actividades involucrados en el desarrollo de software.
  3. 3. Contenido METODOLOGÍAS PARADESARROLLO DE SOFTWARE ...........................................1 Ciclo de vida del software ..............................................................................................6 Modelos de ciclo de vida...................................................................................................7 Modelo en cascada......................................................................................................7 Modelo V....................................................................................................................... 8 METODOLOGÍARUP...................................................................................................... 9 Fases de desarrollo del software…………………………………………………………9 TIPOS………………………………………………………………………………………….10
  4. 4. INSTITUTO TECNOLOGICO SPENCERW.KIMBALL PROFESOR: ALVSRO MRTINEZ 1 DELVIN ESTUARDO FELIX TORRES METODOLOGÍAS PARA DESARROLLO DE SOFTWARE Un proceso de software detallado y completo suele denominarse “Metodología”. Las metodologías se basan en una combinación de los modelos de proceso genéricos (cascada, evolutivo, incremental, espiral entre otros). Adicionalmente una metodología debería definir con precisión los artefactos, roles y actividades involucrados, junto con prácticas y técnicas recomendadas, guías de adaptación de la metodología al proyecto, guías para uso de herramientas de apoyo, etc. Habitualmente se utiliza el término “método” para referirse a técnicas, notaciones y guías asociadas, que son aplicables a una (o algunas) actividades del proceso de desarrollo, por ejemplo, suele hablarse de métodos de análisis y/o diseño. La comparación y/o clasificación de metodologías no es una tarea sencilla debido a la diversidad de propuestas y diferencias en el grado de detalle, información disponible y alcance de cada una de ellas. A grandes rasgos, si tomamos como criterio las notaciones utilizadas para especificar artefactos producidos en actividades de análisis y diseño, podemos clasificar las metodologías en dos grupos: Metodologías Estructuradas y Metodologías Orientadas a Objetos. Por otra parte, considerando su filosofía de desarrollo, aquellas metodologías con mayor énfasis en la planificación y control del proyecto, en especificación precisa de requisitos y modelado, reciben el apelativo de Metodologías Tradicionales (o también denominadas Metodologías Pesadas, o Peso Pesado). Otras metodologías, denominadas Metodologías Ágiles, están más orientadas a la generación de código con ciclos muy cortos de desarrollo, se dirigen a equipos de desarrollo pequeños, hacen especial hincapié en aspectos humanos asociados al trabajo en equipo e involucran activamente al cliente en el proceso. A continuación se revisan brevemente cada una de estas categorías de metodologías: METODOLOGÍAS ESTRUCTURADAS Los métodos estructurados comenzaron a desarrollarse a fines de los 70’s con la Programación Estructurada, luego a mediados de los 70’s aparecieron técnicas para el Diseño (por ejemplo: el diagrama de Estructura) primero y posteriormente para el Análisis (por ejemplo: Diagramas de Flujo de Datos). Estas metodologías son particularmente apropiadas en proyectos que utilizan para la implementación lenguajes de 3ra y 4ta generación. Ejemplos de metodologías estructuradas de ámbito gubernamental: MERISE (Francia), MÉTRICA (España), SSADM (Reino Unido). Ejemplos de propuestas de métodos estructurados en el ámbito académico: Gane & Sarson, Ward & Mellor, Yourdon & Demarco e Information Engineering. METODOLOGÍAS ORIENTADAS A OBJETOS Su historia va unida a la evolución de los lenguajes de programación orientada a objeto, los más representativos: a fines de los 60’s SIMULA, a fines de los 70’s Smalltalk-80, la primera versión de C++ por Bjarne Stroustrup en 1981 y
  5. 5. INSTITUTO TECNOLOGICO SPENCERW.KIMBALL PROFESOR: ALVSRO MRTINEZ 2 DELVIN ESTUARDO FELIX TORRES actualmente Java o C# de Microsoft. A fines de los 80’s comenzaron a consolidarse algunos métodos Orientadas a Objeto. En 1995 Booch y Rumbaugh proponen el Método Unificado con la ambiciosa idea de conseguir una unificación de sus métodos y notaciones, que posteriormente se reorienta a un objetivo más modesto, para dar lugar al Unified Modeling Language (UML), la notación Orientada a Objetos más popular en la actualidad. Algunas metodologías orientadas a objetos que utilizan la notación UML son: Rational Unified Process (RUP), OPEN, MÉTRICA (que también soporta la notación estructurada). METODOLOGÍAS TRADICIONALES Las metodologías no ágiles son aquellas que están guiadas por una fuerte planificación durante todo el proceso de desarrollo; llamadas también metodologías tradicionales o clásicas, donde se realiza una intensa etapa de análisis y diseño antes de la construcción del sistema. Todas las propuestas metodológicas antes indicadas pueden considerarse como metodologías tradicionales. Aunque en el caso particular de RUP, por el especial énfasis que presenta en cuanto a su adaptación a las condiciones del proyecto (mediante su configuración previa a aplicarse), realizando una configuración adecuada, podría considerarse Ágil. METODOLOGÍAS ÁGILES Un proceso es ágil cuando el desarrollo de software es incremental (entregas pequeñas de software, con ciclos rápidos), cooperativo (cliente y desarrolladores trabajan juntos constantemente con una cercana comunicación), sencillo (el método en sí mismo es fácil de aprender y modificar, bien documentado), y adaptable (permite realizar cambios de último momento). Entre las metodologías ágiles identificadas son: Extreme Programming Scrum Familia de Metodologías Crystal Feature Driven Development Proceso Unificado Rational, una configuración ágil Dynamic Systems Development Method Adaptive Software Development Open Source Software Development SEGUIDAMENTE DETALLAREMOS LAS SIGUIENTES METODOLOGÍAS PARA DESARROLLO DE SOFTWARE: Rational Unified Process (RUP) Extreme Programming (XP)
  6. 6. INSTITUTO TECNOLOGICO SPENCERW.KIMBALL PROFESOR: ALVSRO MRTINEZ 3 DELVIN ESTUARDO FELIX TORRES SCRUM Como se explicó en el concepto anterior, un modelo para el desarrollo de software es una representación abstracta de un proceso. Cada modelo representa un proceso desde una perspectiva particular y así proporcione información parcial sobre el proceso. Éstos modelos generales no son descripciones definitivas de los procesos del software más bien son abstracciones de los procesos que se pueden utilizar para el desarrollo del software. Puede pensarse en ellos como marcos de trabajo del proceso y que pueden ser adaptados para crear procesos más específicos. Los modelos que mencionaremos en este punto son: 1) El modelo en cascada. Considera las actividades fundamentales del proceso especificación, desarrollo, validación y evolución. Los representa como fases separadas del proceso, tales como la especificación de requerimientos, el diseño del software, la implementación, las pruebas, etcétera. 2) El modelo de desarrollo evolutivo (espiral). Este enfoque entrelaza las actividades especificación, desarrollo y validación. Es decir surge de un sistema inicial que se desarrolla rápidamente a partir de especificaciones abstractas. Basándose en las peticiones del cliente para producir un sistema que satisfaga sus necesidades. 3) El modelo de desarrollo basado en componentes. Éste enfoque se basa en la existencia de un número significativo de componentes reutilizables. El proceso de desarrollo se enfoca en integrar estos componentes en el sistema más que en desarrollarlos desde cero. Estos tres modelos se utilizan ampliamente en la práctica actual de la ingeniería del software, no se excluyen mutuamente y a menudo se utilizan juntos especialmente para el desarrollo de grandes sistemas.
  7. 7. INSTITUTO TECNOLOGICO SPENCERW.KIMBALL PROFESOR: ALVSRO MRTINEZ 4 DELVIN ESTUARDO FELIX TORRES A. El modelo en cascada Según Royce (1970), el modelo de cascada se derivó de procesos de sistemas más generales. Éste modelo se muestra en la figura 2.22 y sus principales etapas se transforman en actividades fundamentales del desarrollo: 1) Análisis y definición de requerimientos. Los servicios restricciones y metas del sistema se definen a partir de las consultas con los usuarios. Entonces, se definen en detalle y sirven de manera específica al sistema. 2) Diseño del sistema y del software. El proceso de diseño del sistema divide los requerimientos en sistemas ya sea hardware Soto. Establece una arquitectura completa del sistema, el diseño del software identifique describe los elementos abstractos que son fundamentales para el software y sus relaciones. 3) Implementaciones prueba de unidades. Durante esta etapa el diseño del software se lleva a cabo como un conjunto de unidades de programas, la prueba de unidades implica verificar que cada una cumpla con su función específica. 4) Integración y prueba del sistema. Los programas o las unidades individuales de programas se integran y se prueban como un sistema completo para así asegurar que se cumplan los requerimientos del software, después se entrega al cliente. 5) Funcionamiento y mantenimiento. En esta fase el sistema se instala y se pone en funcionamiento práctico el mantenimiento implica corregir errores no descubiertos en las etapas anteriores del ciclo de vida, mejorar la implementación de las unidades del sistema y resaltar los servicios del sistema una vez que se descubren en nuevos requerimientos. B. El modelo de desarrollo evolutivo (espiral) El modelo en espiral que Boehm propuso es un modelo de proceso de software evolutivo que conjuga la naturaleza iterativa de la construcción de prototipos con los aspectos controlados y sistemáticos del modelo en cascada. Cuando se aplica este modelo en espiral, el software se desarrolla en una serie de entregas evolutivas. Cada una de las actividades del marco de trabajo representa un segmento de la ruta en espiral. Este modelo se basa en la idea de desarrollar una implementación inicial, exponiéndola a los comentarios del usuario y refinándola a través de las diferentes versiones que se generan hasta que se desarrolle un sistema adecuado. Las actividades de especificación, desarrollo y validación se entrelazan en vez de separarse, con una rápida retroalimentación entre estas. Existen dos tipos de desarrollo evolutivo: 1) Desarrollo exploratorio, en este caso el objetivo del proceso es trabajar con el cliente para explorar sus requerimientos y entregar un sistema final. El
  8. 8. INSTITUTO TECNOLOGICO SPENCERW.KIMBALL PROFESOR: ALVSRO MRTINEZ 5 DELVIN ESTUARDO FELIX TORRES desarrollo empieza con las partes del sistema que se comprenden mejor. El sistema evoluciona agregando nuevos atributos propuestos por el cliente. 2) Prototipos desechables, el objetivo de este proceso de desarrollo evolutivo es comprender los requerimientos del cliente para así desarrollar una definición mejorada de los requerimientos para el sistema. El prototipo se centra en experimentar los requerimientos del cliente que no se comprenden del todo. Haciendo referencia a la producción del software, un enfoque evolutivo suele ser más efectivo que el enfoque en cascada, ya que satisface las necesidades inmediatas de los clientes. La ventaja de un software que se basa en un enfoque evolutivo es que las especificaciones se pueden desarrollar de forma creciente. Tan pronto como los usuarios desarrollen un mejor entendimiento de su problema, esto se puede reflejar en el software. Sin embargo, desde la perspectiva de ingeniería y de gestión, el enfoque evolutivo tiene dos problemas: 1) El proceso no es visible. Esto significa que los administradores tienen que hacer entregas regulares para medir el progreso del producto. Si los sistemas se desarrollan rápidamente, no es rentable producir documentos que reflejen cada versión del sistema. 2) A menudo los sistemas tienen una estructura deficiente. Esto hace referencia que los cambios continuos tienden a corromper la estructura del software. Incorporar cambios en él se convierte cada vez más en una tarea difícil y costosa. Para sistemas pequeños y de tamaño medio (hasta 500,000 líneas de código), el enfoque evolutivo de desarrollo es el mejor. Los problemas del desarrollo evolutivo se hacen particularmente agudos para sistemas grandes y complejos con un período de vida largo, donde diferentes equipos desarrollan distintas partes del sistema. Es difícil establecer una arquitectura del sistema usando este enfoque, ya que hace difícil integrar las contribuciones de los equipos. Para sistemas grandes se recomienda un proceso mixto es decir que incorpore las mejores características del modelo en cascada y del desarrollo evolutivo. Esto implica desarrollar un prototipo desechable, utilizando un enfoque evolutivo para resolver incertidumbres en la especificación del sistema. Puede entonces no implementarse utilizando un enfoque más estructurado. C. El modelo de desarrollo basado en componentes En la mayoría de los proyectos de desarrollo de software existe la reutilización. Por lo general esto sucede informalmente cuando las personas conocen diseños o códigos similares al requerido. Los buscan, los modifican según lo creen necesario y los incorporan en un nuevo sistema. El enfoque evolutivo, la reutilización es indispensable para el desarrollo más ágil de un sistema. Esta reutilización es independiente del proceso de desarrollo que se utilice. Sin embargo, en los últimos años ha surgido un enfoque de desarrollo de software denominado " ingeniería de software basada en componentes", el cual se basa
  9. 9. INSTITUTO TECNOLOGICO SPENCERW.KIMBALL PROFESOR: ALVSRO MRTINEZ 6 DELVIN ESTUARDO FELIX TORRES en la reutilización. Este enfoque se basa en la reutilización y se compone de una gran base de componentes de software que son reutilizables. Aunque la etapa de especificación de requerimientos y la revalidación son comparables con otros procesos, las etapas intermedias en el proceso orientado a la reutilización son diferentes. Estas etapas son: 1) Análisis de componentes. En esta se buscan los componentes para implementar los con base en su especificación. Por lo general, no existe una concordancia exacta y los componentes que se utilizan sólo proporcionan parte de la funcionalidad requerida. 2) Modificación de requerimientos. En esta etapa los requerimientos se analizan utilizando información acerca de los componentes que se han descubierto. Entonces dichos componentes se modifican para reflejar los componentes disponibles, la actividad de análisis de componentes se puede llevar a cabo para buscar soluciones alternativas. 3) Diseño del sistema con reutilización. En esta fase los diseñadores tienen en cuenta los componentes que se reutiliza y que se organizan el marco de trabajo para que los satisfaga. Si dichos componentes no están disponibles se puede diseñar nuevos software. 4) Desarrollo e integración. El software que no se puede adquirir externamente se desarrolla y se integra a los componentes. En este modelo, la integración del sistema es parte del proceso de desarrollo, más que una actividad separada. El modelo de desarrollo de software basado en componentes creado por Boehm (1988), tiene la ventaja de reducir la cantidad de software que se debe desarrollar y por ende reduce los costos y los riesgos. También permite una entrega más rápida del software. Sin embargo, los compromisos a los requerimientos son inevitables y esto da lugar a un sistema que no cumpla con las necesidades reales de los usuarios. Pressman (2006), detecto que: “El software de computadoras moderno se caracteriza por el cambio con tiempos de entrega son muy reducidos y una necesidad intensa de satisfacer al cliente/usuario. En muchos casos, el tiempo de llegada al mercado es el requisito de gestión más importante. Si se pierde una ventana del mercado, el mismo proyecto de software puede perder su significado”. Ciclo de vida del software El término ciclo de vida del software describe el desarrollo de software, desde la fase inicial hasta la fase final. El propósito de este programa es definir las distintas fases intermedias que se requieren para validar el desarrollo de la aplicación, es decir, para garantizar que el software cumpla los requisitos para la aplicación y verificación de los procedimientos de desarrollo: se asegura de que los métodos utilizados son apropiados.
  10. 10. INSTITUTO TECNOLOGICO SPENCERW.KIMBALL PROFESOR: ALVSRO MRTINEZ 7 DELVIN ESTUARDO FELIX TORRES Estos programas se originan en el hecho de que es muy costoso rectificar los errores que se detectan tarde dentro de la fase de implementación. El ciclo de vida permite que los errores se detecten lo antes posible y por lo tanto, permite a los desarrolladores concentrarse en la calidad del software, en los plazos de implementación y en los costos asociados. El ciclo de vida básico de un software consta de los siguientes procedimientos: Definición de objetivos: definir el resultado del proyecto y su papel en la estrategia global. Análisis de los requisitos y su viabilidad: recopilar, examinar y formular los requisitos del cliente y examinar cualquier restricción que se pueda aplicar. Diseño general: requisitos generales de la arquitectura de la aplicación. Diseño en detalle: definición precisa de cada subconjunto de la aplicación. Programación (programación e implementación): es la implementación de un lenguaje de programación para crear las funciones definidas durante la etapa de diseño. Prueba de unidad: prueba individual de cada subconjunto de la aplicación para garantizar que se implementaron de acuerdo con las especificaciones. Integración: para garantizar que los diferentes módulos se integren con la aplicación. Éste es el propósito de la prueba de integración que está cuidadosamente documentada. Prueba beta (o validación), para garantizar que el software cumple con las especificaciones originales. Documentación: sirve para documentar información necesaria para los usuarios del software y para desarrollos futuros. Implementación Mantenimiento: para todos los procedimientos correctivos (mantenimiento correctivo) y las actualizaciones secundarias del software (mantenimiento continuo). El orden y la presencia de cada uno de estos procedimientos en el ciclo de vida de una aplicación dependen del tipo de modelo de ciclo de vida acordado entre el cliente y el equipo de desarrolladores. Modelos de ciclo de vida Para facilitar una metodología común entre el cliente y la compañía de software, los modelos de ciclo de vida se han actualizado para reflejar las etapas de desarrollo involucradas y la documentación requerida, de manera que cada etapa se valide antes de continuar con la siguiente etapa. Al final de cada etapa se arreglan las revisiones de manera que (texto faltante). Modelo en cascada Se define como una secuencia de fases en la que al final de cada una de ellas se reúne la documentación para garantizar que cumple las especificaciones y los requisitos antes de pasar a la fase siguiente: En Ingeniería de software el desarrollo en cascada, también
  11. 11. INSTITUTO TECNOLOGICO SPENCERW.KIMBALL PROFESOR: ALVSRO MRTINEZ 8 DELVIN ESTUARDO FELIX TORRES llamado modelo en cascada (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 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. Modelo V El modelo de ciclo de vida V proviene del principio que establece que los procedimientos utilizados para probar si la aplicación cumple las especificaciones ya deben haberse creado en la fase de diseño.
  12. 12. INSTITUTO TECNOLOGICO SPENCERW.KIMBALL PROFESOR: ALVSRO MRTINEZ 9 DELVIN ESTUARDO FELIX TORRES METODOLOGÍA RUP El Proceso Unificado Racional, Rational Unified Process en inglés, y sus siglas RUP, es un proceso de desarrollo de software y junto con el Lenguaje Unificado de Modelado UML, constituye la metodología estándar más utilizada para el análisis, implementación y documentación de sistemas orientados a objetos. El RUP no es un sistema con pasos firmemente establecidos, sino que trata de un conjunto de metodologías adaptables al contexto y necesidades de cada organización, donde el software es organizado como una colección de unidades atómicas llamados objetos, constituidos por datos y funciones, que interactúan entre sí. RUP es un proceso para el desarrollo de un proyecto de un software que define claramente quien, cómo, cuándo y qué debe hacerse en el proyecto RUP como proceso de desarrollo • RUP es explícito en la definición de software y su trazabilidad, es decir, contempla en relación causal de los programas creados desde los requerimientos hasta la implementación y pruebas. • RUP identifica claramente a los profesionales (actores) involucrados en el desarrollo del software y sus responsabilidades en cada una de las actividades.
  13. 13. INSTITUTO TECNOLOGICO SPENCERW.KIMBALL PROFESOR: ALVSRO MRTINEZ 10 DELVIN ESTUARDO FELIX TORRES Fases de desarrollo del software · Inicio · Elaboración · Construcción · Transición El MODELO en espiral, propuesto originalmente por BOEHM en 1976, es un modelo de proceso de software evolutivo donde se conjuga la naturaleza de construcción de prototipos con los aspectos controlados y sistemáticos del MODELO LINEAL y SECUENCIAL. Proporciona el potencial para el desarrollo rápido de versiones incrementales del software que no se basa en fases claramente definidas y separadas para crear un sistema. En el modelo espiral, el software se desarrolla en una serie de versiones incrementales. Durante las primeras iteraciones la versión incremental podría ser un modelo en papel o un prototipo, durante las últimas iteraciones se producen versiones cada vez más completas del sistema diseñado. EL modelo en espiral se divide en un número de actividades de marco de trabajo, también llamadas REGIONES DE TAREAS , Cada una de las regiones están compuestas por un conjunto de tareas del trabajo llamado CONJUNTO DE TAREAS que se adaptan a las características del proyecto que va a emprenderse en todos los casos se aplican actividades de protección.
  14. 14. INSTITUTO TECNOLOGICO SPENCERW.KIMBALL PROFESOR: ALVSRO MRTINEZ 11 DELVIN ESTUARDO FELIX TORRES TIPOS El modelo espiral tuvo varias modificaciones que son: Modelo Original de Boehm. Modelo Típico de Seis Regiones. Modelo WINWIN. Publicado por Grupo Espiral Php en 9:27 No hay comentarios: MODELO ORIGINAL DE BOEHM No hay un número definido de iteraciones. Las iteraciones debe decidirlas el equipo de gestión de proyecto Cada vuelta se divide en 4 sectores: Planeación: determinación de los objetivos, alternativas y restricciones Análisis de riesgo: análisis de alternativas e identificación/resolución de riesgos Ingeniería: desarrollo del producto hasta "el siguiente nivel". Evaluación: valoración por parte del cliente de los resultados obtenidos. El movimiento de la espiral, ampliando con cada iteración su amplitud radial, indica que cada vez se van construyendo versiones sucesivas del software, cada vez más completas. Uno de los puntos más interesantes del modelo, es la introducción al proceso de desarrollo a las actividades de análisis de los riesgos asociados al desarrollo y a la evaluación por parte del cliente de los resultados del software. El modelo de la cascada es uno de los primeros modelos empleados en el desarrollo de software, se popularizo en 1970 por Winston Royce y aún está
  15. 15. INSTITUTO TECNOLOGICO SPENCERW.KIMBALL PROFESOR: ALVSRO MRTINEZ 12 DELVIN ESTUARDO FELIX TORRES vigente en algunos desarrollos. Éste modelo se define como una secuencia de actividades a ser seguidas en orden, donde la estrategia principal es definir y seguir el progreso del desarrollo de software hacia puntos de revisión bien definidos, es decir, se codifica y reparan los errores; es un proceso continuo de codificación y reparación. Sus características principales son: -Es lineal -Las actividades están relacionadas secuencialmente -Cada etapa tiene una entrada y una salida -Es rígido y sistemático: La entrada de una actividad es la salida de la etapa - anterior, por lo cual no se puede dar inicio a la siguiente fase. -Es monolítico: Existe una única fecha de entrega. -La implementación se pospone hasta que no se comprendan los objetivos. -Los documentos a entregar rigen el proceso de software
  16. 16. INSTITUTO TECNOLOGICOSPENCER W.KIMBALL PROFESOR: ALVARO MARTINEZ DELVIN ESTUARDO FELIX TORRES Conclusión. El desarrollo del software y la programación es uno de los pilares fundamentales de la informática y al cual se dedican muchas horas de esfuerzos en empresas, colegios, academias y universidades. Conforme a la tecnología va avanzando, van apareciendo nuevas soluciones, nuevas formas de programación, nuevos lenguajes y un sin fin de herramientas que intentan realizar el trabajo del desarrollador un poco más fácil.
  17. 17. INSTITUTO TECNOLOGICOSPENCER W.KIMBALL PROFESOR: ALVARO MARTINEZ DELVIN ESTUARDO FELIX TORRES Recomendación. Lo único que puedo recomendar es que se nos sigan implementando nuevas técnicas de aprendizaje ya bien darnos a conocer más sobre estos temas ya que para nosotros como estudiantes de la carrera de computación se nos tienen que dar a conocer estos conocimientos para aplicarlos en el campo de estudio o en la vida diaria para salir adelante sabiendocómo hayque realizar cualquiertipo de problema que se nos presenta en cuanto a computación.
  18. 18. INSTITUTO TECNOLOGICOSPENCER W.KIMBALL PROFESOR: ALVARO MARTINEZ DELVIN ESTUARDO FELIX TORRES E- GRAFIAS. http://www.academia.edu/6362716/METODO_EN_CASCADA http://modeloespiral.blogspot.com/ http://ingenieriadesoftwarerigo.blogspot.com/2012/09/software-libre-para-generar-uml- y.html http://es.kioskea.net/contents/223-ciclo-de-vida-del-software http://procesosdesoftware.wikispaces.com/METODOLOGIAS+PARA+DESARROLLO+DE+SOFTW ARE http://www.eumed.net/tesis-doctorales/2014/jlcv/software.htm http://es.wikipedia.org/wiki/Metodolog%C3%ADa_de_desarrollo_de_software

×