INGENIERIA DEL SOFTWARE I

kelly johana carvajalino sanchez

Miller Fernando Camargo Amado

Sergio David Camargo Hormaza

Yeison Mauricio Carmona Carmona

Politécnico Grancolombiano

Facultad de Ingeniería,

Ingeniería de Software

2021
 Introducción

En el desarrollo del presente proyecto podremos identificar la utilidad que tienen los

conceptos y herramientas ofrecidas en la actualidad para construir un software, partiendo de las

necesidades de determinado cliente para realizar un diseño viable, implementable y que dé

respuesta a las necesidades de un cliente.

En este proyecto se identificarán las utilidades que tienen los métodos vistos en el desarrollo

del módulo de ingeniería de software I, particularmente el modelo de procesos Cascada ya que se

considera el más apropiado, argumentando de forma clara cuáles fueron los motivos, además los

beneficios y carencias que posee este proceso escogido.

El proyecto nos permitirá registrar una serie de profesionales de la salud que ofrecen

diferentes servicios de acuerdo con una agenda definida y permitir a los usuarios en línea buscar

el profesional que más se adapta a sus necesidades y agendar una cita con esta profesional una

vez ha realizado el respectivo pago del servicio.

 Justificación:

El Modelo Escogido para este proyecto es: Cascada

Consideramos que para este proyecto es de las mejores opciones que se pueden implementar,

ya que se tiene definida una necesidad.

Como la necesidad esta bien definida se tiene un alcance claro, el cual se va a ajustar a las

diferentes etapas del ciclo del software, las cuales vamos a mencionar a continuación; estas

ventajas son dadas respecto a la documentación y experiencia que se tiene trabajando en

proyectos.

A continuación, explicamos las fases del proyecto:

Análisis (socialización):

Etapa donde se puede reunir parte o la mayoría del equipo de trabajo, el cliente expone su

necesidad y se van definiendo los requisitos funcionales y no funcionales, además también se

pueden llamar mesas de requisitos donde todos van dando sus opiniones y viabilidades técnicas a

alto nivel, para este proyecto ya tenemos documentación clara con lo que desea el cliente.

Planeación:

Esta etapa se define los tiempos de desarrollo y pruebas, adicionalmente se identifica los

riesgos y como la misma etapa lo define el plan de desarrollo y pruebas, donde se expone de

manera mas clara como se va a trabajar y los tiempos de entrega de las diferentes fases.
 Diseño:

Para esta etapa se definen de forma mas clara las viabilidades o restricciones técnicas del

software, se especifica de forma mas clara las funcionalidades y se le informa al cliente para su

aprobación.

Construcción:

En esta etapa ya se comienza con la construcción del código fuente e implementación en las

herramientas.

Pruebas:

Una de las etapas mas importantes donde se verificará toda la funcionalidad y donde se

identifican los fallos para que no pasen a un ambiente productivo, con el fin que el usuario final

experimentara la menor cantidad de fallos posibles.

Despliegue:

luego de finalizadas las pruebas y aprobación del cliente final se realizará el despliegue y se

pondrá en marcha el funcionamiento de la aplicación.

Con los puntos anteriormente mencionados tenemos las ventajas de identificar de manera

temprana los tiempos de desarrollo del software, los costos y los riesgos, esta facilitara una mejor

estrategia, en este modelo siempre se llevara a cabo el alcance definido en la documentación, lo

que permitiría de forma más clara el desarrollo del software, ya que si se tiene una buena

documentación mejor será el desarrollo(Código fuente) porque todo estará bien definido para las

etapas de construcción y pruebas.

 Ya que tenemos unas definiciones claras de los requisitos funcionales podemos prever los

tiempos de entrega y de este modo tener un mejor control del proyecto, ya que si se presenta

algún fallo se podrán tener tiempo de reacción temprana.

Como el proyecto ya tiene un alcance definido el usuario debe tener muy clara su necesidad,

si en el camino el cliente decide realizar un cambio será muy impactante para el proyecto y

tendremos que devolvernos en varias fases, estoy implicaría un control de cambios para el

proyecto y todo el equipo debe adaptar la funcionalidad a los cambios informados, esto se puede

hacer pero incrementaría los costos y tiempos del proyecto, por eso para este modelo se debe

tener claro lo que se desea desde el principio intentando no dejar nada fuera el alcance, pero

también se puede adaptar a los cambios.

De igual modo todo proyecto siempre tendrá sus riesgos los cuales siempre se procurarán

mitigar, pero siempre van a estar ahí.

El modelo en cascada como los demás, presenta ventajas y desventajas. Las cuales hay que

identificar claramente al inicio de un proyecto, para saber cuál más se ajusta a las necesidades y

requerimientos del cliente.

Hay que tener en cuenta que una actividad riesgo conlleva a sobrecostos y sobresfuerzos de

todo el equipo.

Del modelo elegido (cascada), se identifican varias limitaciones o riesgos, asociados a sus

acciones de mitigación como:

 
 Alterar o modificar el diseño del proyecto en cualquier etapa es complejo, ya

que conllevaría a un rediseño aumentando los costos de desarrollo. Esto se puede mitigar con un

desarrollo iterativo durante la fase de análisis y diseño.

Es vital reunir todos los requerimientos desde el inicio. Para mitigar esto es posible estar

interactuando con el cliente respecto a los requerimientos con el fin de validar y corregir,

adicional también definir un diseño global, 

Dependencia de etapas, hasta que una etapa no culmine con éxito no se puede avanzar a la

siguiente afectando los tiempos del proyecto. Una mitigación acertada puede ser iterar en las

etapas iniciales porque es más sencillo regresar a una etapa previa que llevar el ritmo del

proyecto de un estado final a un estado inicial.

Nombrando estos riesgos es posible adoptar un modelo en cascada con reducción de riesgos,

para obtener robustez en cuanto a los requerimientos y la manera de cómo llevarlos a cabo.

Haciendo énfasis en las primeras fases del modelo, asegurando la reducción sobre las fallas o

riesgos que se podrían reflejar en las fases de pruebas y despliegue.

Nombrando estos riesgos es posible adoptar un modelo en cascada con reducción de riesgos,

para obtener robustez en cuanto a los requerimientos y la manera de cómo llevarlos a cabo.

Haciendo énfasis en las primeras fases del modelo, asegurando la reducción sobre las fallas o

riesgos que se podrían reflejar en las fases de pruebas y despliegue.

 Justificación de los modelos no elegidos:

No se eligieron las siguientes metodologías en nuestro proyecto porque deben seguir una

secuencia en cada etapa y reunir una voluminosa documentación. Por otra parte, si

utilizamos metodologías ágiles se presentan inconvenientes entre los grupos de trabajo, debido a

la diferencia de criterios que no las ven como ventaja sino como pérdida de tiempo, además del

estrés que se genera dentro por la cantidad de tareas y costos que deben cumplir en tan corto

tiempo para desarrollar el software

Metodología de prototipos:

Aunque es una buena alternativa, al poder validar y poder generar los desarrollos con el visto

bueno del cliente, el hacer y entregar estos prototipos tiene el inconveniente del gasto de tiempo

que con lleva, además de no permitir una buena estimación de horas de los desarrollos.

Método de procesos incrementales:

Divide mucho el proyecto al tener en partes las funcionalidades del proyecto, esto en

ocasiones genera problemas al combinar estar partes, además para poder lograr ejecutar este tipo

de modelo es muy necesario personal experimentado con este tipo de trabajo, este modelo al ser

por procesos dificulta la gestión y los aproximados que requiera el cliente.

Metodologías agiles:

Aunque permiten un mejor control de calidad con el cliente y en el desarrollo, este tipo de

metodologías suelen necesitar mucho presupuesto y tiempo, como en el casos de la

metodología Team Software Process , la cual requiere una gran cantidad ed información para

poder hacer un buena documentación , además que esta documentación suele ser larga y tediosa

para los desarrolladores, lo que provoca que algunos desarrolladores no quieran trabajar con esta

metodología.

Metodología Scrum:

Aunque es una de las metodologías más utilizadas por su eficacia y su gestión , tiene sus

dificultades , al ser costosa y al tener que hacer un planteamiento muy preciso para poder repartir

los trabajos de manera adecuada ,además de requerir personal bien experimentado para que la

metodología se ejecute correctamente.

Programación Externa:  
 
-Es recomendable emplearlo solo en proyectos a corto plazo

-Altas comisiones en caso de fallar

-Imposible prever todo antes de programar

-Costo alto

Dynamic systems Development:

-Se necesita una alta participación de los usuarios en el desarrollo, para evitar que los

desarrolladores asuman criterios que no son ciertos.

-No es una metodología de desarrollo común. El proceso es un tanto difícil de comprender

 Modelo Espiral:

Resulta difícil convencer a grandes clientes de que el enfoque evolutivo es controlable.

Debido a su elevada complejidad no se aconseja utilizarlo en pequeños sistemas.

Genera mucho tiempo en el desarrollo del sistema

Modelo costoso

Requiere experiencia en la identificación de riesgos

Crytal Methodologies:

Delimita el alcance del proyecto con el cliente

Puede no ser factible para proyectos muy grandes.

Aún está en desarrollo.

ASD (Adaptive Software Development):

Debido a que es una metodología ágil implica no realizar procesos que son requeridos en las

demás metodologías agiles tradicionales o por lo menos no realizarlos en procesos diferentes,

esto implica que empresas de grandes magnitudes necesiten llevar control a los procesos y a las

personas, tener tareas asignadas a un estado o proceso especifico, y en las cuales un incremento

de procesos no afectaría a grandes rasgos el costo final del producto. Para estas empresas el

elegir una metodología tradicional resulta mucho más rentable por el volumen de recursos

humanos, productos y costos, para los cuales se podrá obtener un mayor control
Los riesgos, errores o cambios que no han sido detectados a tiempo, afectan en su totalidad en la
calidad del proyecto y su costo total

Usado de manera adecuada esta metodología ASD, se puede alcanzar buenos resultados por

las características que maneja, lo cual la hace más factible usarla en proyectos pequeños y

medianos para ganar una curva de aprendizaje respecto a practica y experiencia.