MODELOS DE PROCESOS DE DESARROLLO DE SOFTWARE

Análisis del Modelo de Procesos

Juan Felipe Aldana Chaparro. Código: 2011982209

Omar Rodolfo Gutiérrez Salinas. Código: 1721021764
Cindy Johana López Poveda. Código: 1311960061
Carlos Augusto Cortes Serna. Código: 1821021026
Daniel Ricardo Gómez Riveros. Código: 1520010641
William David Chalial Meza. Código: 1821023166
Sandra Milena Bolívar Cárdenas. Código: 1621022496

Politécnico Grancolombiano

Facultad de Ingeniería, Diseño e Innovación

Ingeniería de Software
 ii

Resumen

En el desarrollo de un producto software se debe cumplir a cabalidad y tener en cuenta ciertos

requisitos, uno de ellos es el modelo de proceso para el desarrollo del mismo, actualmente

existen diversos modelos y metodologías para el correcto desarrollo del producto final. Entre

ellas, la metodología Scrum. Metodología que permite la gestión y el desarrollo de un producto

ágil y flexible, teniendo como principios fundamentales, la adaptación, auto-gestión, innovación

e inspección continua del Software.

De esta manera y luego de realizar el respectivo estudio y análisis sobre de los diferentes

modelos de procesos y metodologías para el desarrollo de software. Plasmamos en el documento

actual, los resultados de dicho estudio, como también la justificación de la elección del mismo y

la justificación sobre las razones por las cuales se descarta un modelo o metodología diferente

para el desarrollo del proyecto. Así mismo, veremos reflejadas las razones por las cuales se opta

por un modelo de procesos especifico, veremos también reflejado en el documento los

principales riesgos que se asocian a la selección del modelo de proceso seleccionado y la

propuesta para la mitigación de estos riesgos.

 iii

Contenido
Justificación de Selección de Modelo de Procesos..............................................................1

Metodología Scrum..........................................................................................................1

Por qué elegir scrum....................................................................................................1

Riesgos y propuesta.....................................................................................................2

Ciclo de vida scrum.....................................................................................................4

Modelos de Procesos Existentes..........................................................................................5

Modelo Incremental.........................................................................................................5

Ventajas........................................................................................................................6

Desventajas..................................................................................................................6

Modelo en Espiral............................................................................................................7

Ventajas........................................................................................................................7

Desventajas..................................................................................................................7

Modelo en Prototipos.......................................................................................................8

Modelo en Cascada..........................................................................................................9

Ventajas......................................................................................................................10

Desventajas................................................................................................................10

Lista de Referencias.......................................................................................................11
 1

A continuación, encontramos la justificación sobre la elección del modelo de procesos

que se aplicará para el desarrollo del proyecto

Metodología Scrum

Usa Según el planteamiento se pide desarrollar un software que permita hacer varios tipos

de procesos, consultas y generaciones de BD con la información suministrada y que se vaya

generando por las actividades y relaciones entre profesionales y clientes, entre estos se destacan:

 Usuarios con login para profesionales proveedores de servicio y clientes

 De los clientes datos personales y de ubicación

 De los profesionales se debe conocer datos personales, especialidad, horarios,

entres otro

 Robotización de todo el proceso de gestión de citas médicas para los clientes

 Robotización de procesos para la prestación de servicios médicos por parte de los

profesionales proveedores de servicio.

 Consultas y gestiones de BD para clientes y profesionales proveedores del

servicio, ajustadas a cada uno de los usuarios, los perfiles y permisos con los que

cuenten.

Por qué elegir scrum.

Por el planteamiento del problema, se evidencia que en la actualidad la empresa

prestadora de salud no cuenta con un software que le permite realizar una gestión completa de

cada uno de los procesos que maneja en el área de la prestación de servicios.

Se tienen definidos cada uno de los actores de la actividad del negocio, así como las

actividades que se deben tener en cuenta para la creación de la herramienta que solicitan.
 2

Se sugiere que para implementar una robotización completa de cada uno de los procesos

se tengan entregas en un tiempo definido y de poca duración (dos semanas por sprint), que

permita una interacción constante con el cliente para realizar entregas parciales, que facilite la

implementación de cada una de las funcionalidades, y que se puedan integrar de manera

paulatina sin generar alguna demora o falla en la prestación de los servicios.

Scrum ofrece desarrollo en entorno funcional, colaborativo, flexible y adaptable al

cambio.

Es importante desatacar que la adaptación al cambio es una de las principales

características para elegir esta metodología dadas las entregas parciales; lo que se plantea al

cliente es constante interacción entre el product Owner, Stakeholder, Development team, donde

se evidenciara si el Software cumple con lo requerido por el cliente o si es necesario modificar

alguna de las funcionalidades; con esto los cambios se hacen en el momento indicado, sin esperar

a que todo el software esté en funcionamiento y minimizando los costos de implementación.

Scrum permite tomar el planteamiento global de la robotización y dividirlos en partes

pequeñas, donde se puede ir abordando por partes, es decir, desarrollar e implementar por

funcionalidades, lo que permite que desde los primeros días de iniciar el proyecto se pueda estar

generando ganancias.

Riesgos y propuesta.

 En ocasiones al no tener los perfiles bien definidos se puede caer en pérdidas de

tiempo.

 Las reuniones diarias pueden hacer caer al equipo de trabajo en desgastes no

justificados, por lo que se sugiere que las Scrum daily meeting no sean diarias,
 3

que tengan intervalos de 3 días, donde se puede mejorar la productividad de los

grupos de desarrolladores.

 Al no definir bien las tareas al inicio del proyecto puede generar poca exactitud en

el costo y el tiempo que se va a invertir, por esta razón se pide que las tareas sean

específicas y bien definidas.

 Los miembros del equipo de trabajo pueden caer en desgastes incensarios, esto

puede disminuir la productividad y aumentar los costos del proceso, se sugiere

que el equipo de trabajo este motivado todo el tiempo, con esto se garantiza una

mayor productividad en un menor tiempo del planeado al inicio.

 Al no contar el equipo con la experiencia necesaria se pueden aumentar los

tiempos de cada entrega del Sprint, se sugiere que el equipo de trabajo cuente con

la experiencia y el conocimiento idóneo para el desarrollo de las tareas, en dado

caso que no se pueda evidenciar esta falencia al inicio, es acorde implementar

herramientas de comunicación para minimizar la falta de información y

conocimiento del grupo de trabajo, es decir dinamizar el trabajo colaborativo.

 En sector de las TI es muy frecuente la rotación del personal, por esta razón se

puede ver afectado el tiempo de entrega, se sugiere que todos los integrantes del

grupo de trabajo tengan conocimiento del todo el proceso que desarrollan las

demás personas, para en caso de que exista alguna deserción, no se vaya a ver

afectada la productividad por falta de conocimiento general o del proceso que se

adelantaba por la otra persona.

 4

La metodología Scrum se fundamenta en el conjunto de buenas prácticas para trabajar de

manera conjunta, para obtener los mejores resultados posibles. En esta metodología, se da una

gran importancia a la experiencia, habilidades, e inteligencia del grupo de trabajo, en lo que

respecta a la resolución del problema. Cada una de las tareas se realizan en ciclos cortos

llamados sprints, sencillos de controlar y priorizados de manera correcta, que permiten ver los

avances de manera sencilla. Especialmente para proyectos grandes, esta metodología benéfica el

desarrollo porque las metas concretas y alcanzables, hacen el personal involucrado sea más

responsable y aplique la celebra frase, “divide y vencerás”.

Ciclo de vida scrum

La metodología Scrum, es una de las metodologías agiles más populares en lo que

respecta a los proyectos de software, especialmente por su adaptabilidad en diferentes escenarios.

El ciclo de vida de Scrum está compuesto por tres roles principales: Product Owner (dueño del

producto), Scrum Master y development Team (equipo de desarrollo)

 Product Owner: es la persona que representa al cliente, quien se va a encargar de

levantar la información e indagar respecto a lo que este desea. También será el

encargado de mostrar lo recopilado al Scrum master y al development team.

 Scrum Master: Es el moderador del equipo de trabajo, su tarea principal es hacer

que el development team comprenda los requerimientos del cliente, de acuerdo a

lo que el product owner ha indicado.

 Development Team: Es el equipo de desarrollo, son todas las personas que

mediante sus habilidades se encargaran de dar solución a los requerimientos

planteados en este clico, el product owner debe generar un documento que

continente, punto a punto, lo que el cliente desea respecto a sus necesidades,

 5

llamado product backlog, que tiene todos los requisitos que tendrán como objetivo

cumplir las solicitudes el cliente.

Hecho lo anterior, esta información deberá ser comunicada al scrum master y al

development team, por medio de una reunión llamada, sprint planning meeting, en donde se

habla la manera de solucionar la primera fase del proyecto. La idea es extraer una lista de

funcionalidades (spint backlog), que hacen referencia a los requisitos a cumplir en un tiempo de

1 a 4 semanas. El tiempo es llamado el sprint, que representa el centro del scrum, porque es el

proceso de desarrollo de lo que desea el cliente, dividido en un módulo funcional.

Por último, las reuniones diarias en la metodología scrum son fundamentales, ya que

buscan que, en un corto periodo de tiempo, entre 10 a 15 minutos, se resuelvan todas las dudas o

inconvenientes, y a su vez se vaya viendo el avance del sprint respecto al proyecto.

Una vez terminado el sprint, iniciamos un nuevo sprint, hasta tener el producto funcional

o finalizar el proyecto.

Scrum busca que todos puedan aportar, y nos podamos ayudar unos a otros para cumplir

los objetivos y la entrega del proyecto.

Modelos de Procesos Existentes

Modelo Incremental

No escogimos el modelo incremental para este proyecto, a pesar de que contaba con las

cualidades para desarrollar lo que el cliente espera de la aplicación, nos decidimos por el modelo

SCRUM ya que está enfocado en una serie de pasos que se deben llevar a cabo de manera

ordenada, permitiendo trabajar como equipo para lograr la satisfacción del cliente, una de sus

características es que implementa el modelo incremental.

 6

A continuación, explicamos las ventajas y desventajas respecto al proyecto, si

hubiéramos elegido el modelo Incremental

Ventajas.

 Permite iniciar el desarrollo sin contar con los requerimientos en su totalidad, las

entregas se pueden presentar en pequeños lapsos de tiempo permitiéndonos

presentarle al cliente una idea de lo que será el resultado final por medio de un

producto inicial.

 El cual se caracteriza por contar con funcionalidades básicas o mínimas, a medida

que lo involucramos nos permite entender y proyectar en cada entrega lo que

espera, es de vital importancia cada aporte, ya que el más mínimo detalle en

cuanto información nos permite avanzar de manera efectiva, minimizando el

riesgo de contrariedad puesto que cada cambio o mejora a la estructura del

proyecto son realizadas con el aval de este.

 En cada entrega se tendrán funcionalidades que satisfagan los requisitos

anteriormente expuestos, y lo mejor de todo, es que en caso de obtener una

respuesta de desaprobación simplemente lo arreglamos partiendo de la entrega

anterior y no desde el inicio.

En resumen, si no contáramos con el método SCRUM este sería uno de los modelos que

funcionarían para el proyecto ya que es propicio para cambios o modificaciones.

Desventajas.

 Debido a que no es un método tan planificado como el SCRUM, el producto final

puede tardar mucho más tiempo del esperado, ocasionando incertidumbre en el

costo final, teniendo en cuenta que pueden surgir inconvenientes si en el momento

 7

de unir los incrementos no están desarrollados de manera proporcionada o falta

alguno.

 Este modelo requiere de mucha experiencia, para lograr que cada mejora quede

perfectamente vinculada, con el fin de obtener un proyecto 100% funcional.

Modelo en Espiral

El modelo espiral es un modelo de software evolutivo que tiene forma de caracol, la cual

inicia del centro y se va expandiendo a medida que se realizan una serie de iteraciones o ciclos

que representan ciertas actividades, la cual tiene la intención de llegar a una meta deseada, este

modelo requiere un alto análisis de riesgos, y es el más utilizado para el desarrollo de proyectos

complejos, requiriendo el acompañamiento del cliente en todas las fases para la recopilación de

información durante el proyecto.

Ventajas.

 Es un modelo de enfoque realista del desarrollo de sistema.

 Es un modelo adaptable

 Aplicable a lo largo del ciclo de vida del software, donde el desarrollador y el

cliente comprenden los riegos en cada evolución del sistema

 Este modelo permite el enfoque de cualquier etapa en la evolución del software

Desventajas.

 Que es un modelo muy costoso y de muy largo tiempo

 Que un error en cualquier etapa del desarrollo que no fue detectado se debe iniciar

de nuevo

 Por su grande complejidad no se debe utilizar para pequeños sistemas y que

requiere de mucha experiencia por el equipo desarrollador

 8

La razón por el cual se rechaza o no es viable el método espiral para el proyecto, es

porque es un método para un proyecto más complejo, donde el proyecto requiere una

investigación continua durante el desarrollo del software, teniendo una serie de modificación o

una nueva versión, también por costos y tiempo de desarrollo. El proyecto a desarrollar requiere

de un modelo ágil ya que es un proyecto pequeño y se tiene toda la información requerida para

su diseño

Modelo en Prototipos

Modelo de prototipos, no utilizado en el grupo para el desarrollo de proyectos de

software, teniendo en cuenta que es un modelo evolutivo, y que se pueden encontrar varias

desventajas en la utilización de este modelo, puesto que la presentación de un prototipo no

avanzado con herramientas de desarrollo de software que no se ajusten a los requerimientos

puede causar que:

 El cliente en su afán de querer un producto rápido pierda la noción de muchos

requerimientos de lo que tendría en si un software con más detalles y calidad.

 Que el desarrollador quiera sacar el producto más rápido para atender otros

requerimientos, y utilizaría al final el prototipo como un producto final, a lo que

en un futuro tendría que realizar muchos cambios debido al constante

mantenimiento de este por su poca eficiencia.

 El cliente no identifica los detalles y el desarrollador no se encontrará seguro si el

producto mantiene una buena interfaz hombre-máquina.

 Los prototipos son construidos en poco tiempo, con muy pocos recursos.

 Puede suceder que la temprana familiarización con el cliente y lo que va a ser el

producto hagan que el entusiasmo acelere su desarrollo y el programador utilice

 9

herramientas que no sean acordes para los requerimientos del producto final de un

excelente software.

En conclusión, para el grupo no fue de nuestra consideración este modelo ya que las

expectativas del cliente se pueden ver afectadas por un prototipo temprano que causaría

desaciertos en la misma construcción del software.

Modelo en Cascada

Considerado el modelo clásico dentro de la ingeniera de software consiste en un proceso

de flujo lineal en que es necesario primero cumplir con los requisitos y objeticos de una actividad

para poder iniciar la siguiente. Este modelo cuenta con las siguientes fases de acuerdo con

Presman (2010)

 Comunicación

 Planeación

 Modelado

 Construcción

 Despliegue

Este modelo requiere de un análisis detallado de los requerimientos y una planificación

que debe cumplirse con rigurosidad para que el proyecto tenga éxito, además de una

documentación completa.

Debido a que en la actualidad los clientes desean conocer avances de sus requerimientos

y deseamos que así sea, no elegimos este modelo, adicionalmente porque analizamos que los

requerimientos del cliente pueden variar en el transcurso del proyecto y el modelo en cascada

dificulta en gran manera poder reaccionar a un cambio de las necesidades del cliente.
 10

Ventajas.

 Exige una documentación detallada del proceso, esto nos permite que, si algún

miembro del equipo abandona el proyecto, este pueda continuar sin mayores

dificultades.

 Al existir una planificación detallada del proyecto, se puede organizar de manera

más sencilla los calendaros y actividades, pudiendo cumplir con las fechas

estipuladas para la entrega

 Con una especificación correcta de requerimientos se evita que haya muchos

cambios en el transcurso del ciclo de vida del software

Desventajas.

 Debido a que en el mundo real una especificación perfecta de los requerimientos

es casi imposible, este modelo no se ajusta a nuestras necesidades ya que después

de que se culmina una actividad resulta demasiado difícil hacer un cambio.

 Es difícil ejecutar pruebas ya que debemos esperar que se cumplan varias etapas

para poder llegar a ese punto y en caso de ubicar un error es difícil y costosa su

corrección

 No es posible realizar entregas parciales al cliente para que pueda aprobar y

cumplir con la satisfacción del cliente

 Debido a que nuestro objetivo es hacer entregas funcionales al cliente, poder

reaccionar rápidamente a un cambio en los requerimientos, poder hacer pruebas

de las funcionalidades del software y superar las expectativas del cliente. No

elegimos el modelo en cascada.

 11

Lista de Referencias

 https://obsbusiness.school/es/blog-project-management/metodologias-agiles/los-
5-modelos-de-desarrollo-de-software-que-elegiras

 https://www.youtube.com/watch?v=HhC75IonpOU

 https://www.grupocibernos.com/blog/agile-vs-scrum-cual-eliges

 https://sites.google.com/site/programacion1electronica/metodologias-de-
desarrollo-de-software/modelo-incremental-o-evolutivo

 http://isw-udistrital.blogspot.com/2012/09/ingenieria-de-software-i.html 

 https://obsbusiness.school/es/blog-project-management/metodologias-
agiles/caracteristicas-y-fases-del-modelo-incremental

 https://obsbusiness.school/es/blog-project-management/metodologia-agile/pros-y-
contras-de-la-metodologia-en-cascada

 http://cotana.informatica.edu.bo/downloads/ld-
Ingenieria.de.software.enfoque.practico.7ed.Pressman.PDF

 https://www.monografias.com/trabajos108/modelos-del-proceso-del-
software/modelos-del-proceso-del-software.shtml