Inf 162
- 1. MODELOS DE PROCESOS DE SOFTWARE INTEGRANTES: • Mamani Vichini Marco Antonio • Limachi Zurita Naira • Delgado Vera Jose Luis • Torrez Leon Jorge Ruben • Mayta Tapia Richard • Guarachi Choque Jorge Luis • Chura Siñani Brian Miguel • Quispe Mamani Cenobio
- 2. METODOS DE PROCESO DE SOFTWARE Una metodología de desarrollo de software se refiere a un framework (entorno o marco de trabajo) que es usado para estructurar, planear y controlar el proceso de desarrollo en sistemas de información. Existe la creencia extendida de que los programas software tienen que ver solamente con los ordenadores y las grandes computadoras. Sin embargo, la ingeniería del software va mucho más allá. Se trata del proceso cuya finalidad es desarrollar productos o soluciones para un cliente o mercado en particular, teniendo en cuenta factores como los costes, la planificación, la calidad y las dificultades asociadas. A todo esto es a lo que denominamos metodologías de desarrollo de software. Es decir, se trata del proceso que se suele seguir a la hora de diseñar una solución o un programa específico. Tiene que ver, por tanto, con la comunicación, la manipulación de modelos y el intercambio de información y datos entre las partes involucradas. O para ser más precisos, las metodologías de desarrollo de software son enfoques de carácter estructurado y estratégico que permiten el desarrollo de programas con base a modelos de sistemas, reglas, sugerencias de diseño y guías.
- 3. METODOS SECUENCIALES Modelo lineal secuencial También llamado “Ciclo de vida básico” tiene su origen en el “Modelo de cascada” basado en el modelo en cascada de Winston Royce, sugiere un enfoque sistemático o más bien secuencial del desarrollo de software que comienza en un nivel de sistemas y progresa con el análisis, diseño codificación, pruebas y mantenimiento.
- 4. Ingeniería y Análisis de Sistema: Debido a que el software pertenece siempre a un sistema mayor el trabajo empieza estableciendo los requisitos de todos los elementos del sistema y luego proporcionando algún subconjunto de estos requisitos a software. Análisis de los requisitos del Software: La manera en que se hace la recopilación de los requisitos se enfoca e intensifica en el software. Los analistas deben entender el ámbito de la información del software, así como también la función, rendimiento e interfaces requeridas. Diseño: El diseño del software se centra en cuatro atributos diferentes del programa: la estructura de los datos, la arquitectura del software, el detalle procedimental y la caracterización de la interfaz. El proceso de diseño modifica requisitos en una representación del software con la calidad necesitada antes de que empiece la codificación. Codificación: El diseño debe traducirse en una forma entendible para la máquina. Prueba: Una vez que se ha creado el código empieza la prueba del programa. La prueba se enfoca en la lógica interna del software, en las funciones externas, haciendo pruebas que aseguren que la entrada definida consigue los resultados que se necesitan. Existen varios tipos de pruebas: • Pruebas de unidad • Pruebas de integración • Pruebas de sistema • Pruebas de aceptación
- 5. Modelo Secuencial por Etapas Este modelo es similar al Modelo de prototipos ya que se presenta al cliente el software en diferentes estados continuos de desarrollo, existe diferencia en que las especificaciones no son conocidas en detalle al empiezo del proyecto entonces se van desarrollando paralelamente con las diferentes versiones del código existente. Es un modelo en que el software se presenta al cliente en etapas mejoradas sucesivamente. Definición del problema. Es una situación por resolver, algo que debe ser mejorado. Es típico decir que no existe investigación sin un “problema” y que un problema bien planteado es mejor que cualquier solución gratuita. Análisis de Requerimientos. En esta parte se logra claridad sobre lo que quiere el usuario y la forma en la cual se le va a presentar la solución de esta. Un requerimiento es una declaración abstracta de alto nivel de un servicio que debe brindar el sistema o una restricción de este. Diseño Global Es un diseño general del problema que está planteado, es también la elaboración en la búsqueda de una solución en cualquier campo, tomando en cuenta los parámetros y análisis de requerimientos que se hayan conseguido para el desarrollo de un resultado que debe estar relacionado con el problema.
- 6. METODOS EVOLUTIVOS Desarrollo en Cascada - Evolutivo 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
- 7. Ingeniería y Análisis del Sistema. Debido a que el software es siempre parte de un sistema mayor, el trabajo comienza estableciendo los requisitos de todos los elementos del sistema y luego asignando algún subconjunto de estos requisitos al software. Análisis de los requisitos del software Análisis: Se analizan las necesidades de los usuarios finales del software para determinar qué objetivos debe cubrir. De esta fase surge una memoria llamada SRD (Documento de Especificación de Requisitos), que contiene la especificación completa de lo que debe hacer el sistema sin entrar en detalles internos (debe comprender el ámbito de la información del software, así como la función, el rendimiento y las interfaces requeridas). Diseño El diseño del software se enfoca en cuatro atributos distintos del programa: la estructura de los datos, la arquitectura del software, el detalle procedimental y la caracterización de la interfaz. El proceso de diseño traduce los requisitos en una representación del software con la calidad requerida antes de que comience la codificación. Como resultado surge el SDD (Documento de Diseño del Software), que contiene la descripción de la estructura global del sistema y la especificación de lo que debe hacer cada una de sus partes, así como la manera en que se combinan unas con otras. Codificación Es la fase de programación. Aquí se desarrolla el código fuente, el diseño debe traducirse en una forma legible para la máquina, haciendo uso de prototipos así como pruebas y ensayos para corregir errores. El paso de codificación realiza esta tarea. Si el diseño se realiza de una manera detallada la codificación puede realizarse mecánicamente. Prueba Una vez que se ha generado el código comienza la prueba del programa. La prueba se centra en la lógica interna del software, y en las funciones externas, realizando pruebas que aseguren que la entrada definida produce los resultados que realmente se requieren. Se comprueba que funciona correctamente antes de ser puesto en explotación. Mantenimiento El software sufrirá cambios después de que se entrega al cliente. Los cambios ocurrirán cuando se hayan encontrado errores, esto en lugar de que el software debe adaptarse a cambios del entorno externo (sistema operativo o dispositivos periféricos), o debido a que el cliente requiera ampliaciones funcionales o del rendimiento.
- 8. Modelo Espiral 3.2.1 Modelo Original de Boehm Los evolutivos son los modelos iterativos, permiten realizar versiones cada vez más completas y complejas, hasta llegar al objetivo final que se desea; incluso evolucionar más allá,durante la etapa de operación. Los modelos “Iterativo incremental” y “Espiral” (entre otros) son dos de los que más se conocen y utilizan del tipo evolutivo. La idea que existe detrás de este modelo es la elaboración de una implantación del sistema inicial, exponerla a los comentarios del usuario, mejorarla en N versiones hasta que se realice el sistema adecuado.Una de las ventajas de este modelo es que se obtiene una rápida realimentación del usuario, dado que las actividades de especificación, desarrollo y pruebas se ejecutan en cada iteración.
- 9. METODOS AGILES SCRUM Este modelo fue identificado y definido por Ikujiro Nonaka y Takeuchi a principios de los 80, al analizar cómo desarrollaban los nuevos productos las principales empresas de manufactura tecnológica: Fuji-Xerox, Canon, Honda, NEC, Epson, Brother, 3M y Hewlett-Packard (Nonaka & Takeuchi, The New New Product Development Game, 1986). En su estudio, Nonaka y Takeuchi compararon la nueva forma de trabajo en equipo, con el avance en formación de melé (scrum en inglés) de los jugadores de Rugby, a raíz de lo cual quedó acuñado el término “scrum” para referirse a ella. Aunque esta forma de trabajo surgió en empresas de productos tecnológicos, es apropiada para cualquier tipo de proyecto con requisitos inestables y para los que requieren rapidez y flexibilidad, situaciones frecuentes en el desarrollo de determinados sistemas de software.
- 10. Kanban El término japonés Kanban, fue el empleado por Taiichi Onho (Toyota), para referirse al sistema de visualización empleado en los procesos de producción que coordinan en una cadena de montaje la entrega a tiempo de cada parte en el momento que se necesita, evitando sobreproducción y almacenamiento innecesario de producto. Se puede traducir como tablero o tarjeta de señalización, y su origen se remonta finales de los cuarenta o principio de los cincuenta. Kanban en el sector TIC El uso de tableros kanban muestra y gestiona el flujo de avance y entrega, y ayuda a evitar los dos problemas más importantes: cuellos de botella y tiempos muertos. El desarrollo ágil de software emplea prácticas de gestión visual por ser las que mejor sirven a los principios de comunicación directa y simplicidad en la documentación y gestión. Desde 2005 es cada vez más frecuente reemplazar los formatos de lista para las pilas de producto y de sprint por notas adhesivas en tableros, que resultan más versátiles al poder cambiar su posición, bien para reordenar las prioridades de las historias de una pila de producto, o para reflejar a través de su posición en, cuáles se están programando, probando, o se encuentran terminadas. Las prácticas kanban son válidas para gestión evolutiva con entrega continua. Deben emplearse con criterios de flexibilidad, sin considerar prescripciones ni excepciones en el método de trabajo, para lograr la implementación personalizada, que dé la mejor respuesta a los principios ágiles, de ingeniería concurrente, o de síntesis de ambos, con los que trabaja la organización.
- 11. PROGRAMACIÓN EXTREMA XP La programación extrema o eXtreme Programming (XP) es un enfoque de la ingeniería de software formulado por Kent Beck, autor del primer libro sobre la materia, Extreme Programming Explained: Embrace Change (1999). Es el más destacado de los procesos ágiles de desarrollo de software. Al igual que éstos, la programación extrema se diferencia de las metodologías tradicionales principalmente en que pone más énfasis en la adaptabilidad que en la previsibilidad. Los defensores de XP consideran que los cambios de requisitos sobre la marcha son un aspecto natural, inevitable e incluso deseable del desarrollo de proyectos. Creen que ser capaz de adaptarse a los cambios de requisitos en cualquier punto de la vida del proyecto es una aproximación mejor y más realista que intentar definir todos los requisitos al comienzo del proyecto e invertir esfuerzos después en controlar los cambios en los requisitos. Características Las características fundamentales del método son: Se valora al individuo y las interacciones del equipo de desarrollo sobre el proceso y las herramientas. La gente es el principal factor de éxito de un proyecto software. Desarrollar software que funciona más que conseguir una buena documentación. La colaboración con el cliente. Se propone que exista una interacción constante entre el cliente y el equipo de desarrollo. Responder a los cambios. La habilidad de responder a los cambios que puedan surgir a lo largo del proyecto determina también el éxito o fracaso del mismo. La planificación no debe ser estricta sino flexible y abierta.