En esta presentación resumimos los puntos importantes de nuestra investigación

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.