Está en la página 1de 5

Actividad 2 - Visualización de métodos y ciclos de vida del sistema

Héctor Giovanny Enríquez Delgado

Sol Eugenia Pardo Lancheros

Cristian Eduardo Arenas Ávila

Julio de 2021.

Corporación universitaria Iberoamericana

Facultad de ingeniería

Ingeniería de Software

Semestre 1

Asignatura

Introducción a la ingeniería de software

Adán Beltrán Gomez


INTRODUCCIÓN.

En este documento se describe las etapas necesarias para el desarrollo de soluciones tecnológicas

basándose en el ciclo de vida clásico del sistema, de tal forma que el estudiante pueda tener claridad en

las actividades necesarias en cada una de las etapas de creación de sistemas.


ARGUMENTO
METODOLOGÍAS DE DESARROLLO DE SOFTWARE TRADICIONALES y AGILES

MODELO EN CASCADA PROTOTIPADO INCREMENTAL ESPIRAL RAD

Recolección de requisitos: El ingeniero de Planificación: la estimación del costo, el Planificación de necesidades: En esta
Requerimientos: son los objetivos
Análisis: Esta es la etapa de preparación software y el cliente definen los objetivos calendario y los recursos para la iteración. primera fase, lo que habrá que hacer será
centrales y específicos que persigue el
de tu proyecto. globales del software, y aquéllos más La comunicación continua entre el sentar las bases de las necesidades del
proyecto.
específicos. analista de requerimientos y el cliente. proyecto.

Diseño y feedback con el usuario: Los


usuarios aportarán comentarios que
Definición de las tareas y las iteraciones: Análisis del riesgo: se realiza mientras se serán determinantes a la hora de diseñar
Diseño: Esta etapa del modelo o mientras Diseño rápido: por ejemplo, interfaz de
lista de tareas y agruparlas en las planifica y finaliza la estrategia de la arquitectura del sistema. este paso se
diseñas el desarrollo de tu software usuario, entradas y salidas
iteraciones que tendrá el proyecto. mitigación de riesgos. podrá repetir tantas veces como se
considere necesario según avance el
proyecto.
Implementación: En la etapa de Diseño de los incrementos: Es cuando se
Ingeniería: Incluye la codificación, Construcción: Codificación, pruebas e
implementación y realizando pruebas para Construcción del prototipo define cuál será la evolución del producto
pruebas y el despliegue del software. integración reales de la aplicación.
verificar que no existan errores. en cada una de ellas
Transición: La última fase, también
Desarrollo del incremento: posteriormente conocida como “cutover”, permitirá al
Verificación: En esta etapa es donde se Evaluación del prototipo: Se realiza por el se realizan las tareas previstas y se equipo de desarrollo pasar los
Etapas del ciclo de Evaluación: por parte del cliente.
debe probar y ejecutar el código final cliente y usuarios. desarrollan los incrementos establecidos componentes a un entorno de producción
vida. en la etapa anterior. en vivo, para realizar todas las pruebas
que sean necesarias.
Validación de incrementos: al término de
Refinamiento del prototipo: Se ajusta para cada iteración, los responsables de la
Mantenimiento: es donde se analiza todo satisfacer las necesidades del cliente, al gestión del proyecto debe decir Si no son
lo realizado para su mejoramiento. tiempo que facilita al ingeniero de software los esperados o si ha habido algún
un mejor conocimiento del sistema. retroceso, es necesario volver la vista
atrás y buscar las causas de ello.

Integración de incrementos: una vez son


Producto: En la mayoría de los casos este
validados, los incrementos dan forma a lo
sistema refinado (piloto) hay que
que se denomina línea incremental o
desecharlo y hacer uno nuevo.
evolución del proyecto en su conjunto.

Entrega del producto: cuando el producto


en su conjunto ha sido validado y se
confirma su correspondencia con los
objetivos iniciales, se procede a su
entrega final.
El producto va evolucionando con cada Crear softwares de forma rápida y barata
Por lo general son usados en proyectos Este diseño conduce a la construcción de una de las entregas previstas hasta que para satisfacer las necesidades
Se usa cuando el proyecto es grande.
de softwares más sencillos y organizados. un prototipo. se amolda a lo requerido por el cliente o empresariales sin invertir tanto tiempo y
destinatario. dinero.

Según Royce, el modelo se debería


ejecutar en, al menos, dos ocasiones: Se trata de un modelo de desarrollo de
El prototipo se prueba y modifica cuando El producto debe mostrar una evolución
primero para elaborar un prototipo y, a Aplica la creación de un prototipo. aplicaciones ágil. Es decir, hablamos del
es necesario. con respecto a la fecha anterior.
continuación, para desarrollar el producto proceso de desarrollo de software.
de software en sí.

Los tipos de prototipo son:


Características de 1. Desechables: sirve para eliminar dudas
los métodos. Es muy útil si no tienes demasiada sobre lo que quiere el cliente. Es primordial un control de riesgos y La creación de prototipos y el empleo de
Nunca puede ser igual
experiencia. 2. Evolucionario: modelo parcialmente costos utilidades CASE
construido que pasa de ser prototipo a ser
el software
Deben analizar si los resultados parciales
En proyectos catalogados de riesgo medio-
son los esperados y si, sobre todo,
alto y alto.
apuntan al objetivo principal.

Funciona de manera óptima en la mayoría Hay un alto grado de cambios y estos


de los dispositivos pueden aparecer en cualquier momento.
El compromiso de proyecto a largo plazo
está comprometido, bien sea por razones
económicas u otras.
Avances medibles: podrá medir y evaluar
Una estructura sencilla gracias a unas Con un paradigma incremental se reduce
Permite la construcción del sistema con La funcionalidad adicional o los cambios de forma sencilla el desarrollo del
fases de proyecto claramente el tiempo de desarrollo inicial, ya que se
requisitos poco claros o cambiantes se pueden hacer en una etapa posterior. proyecto y, así, cumplir con los
diferenciadas. implementa la funcionalidad parcial
presupuestos.
El cliente recibe una versión del sistema También provee un impacto ventajoso Productivos más pronto: roles
Buena documentación del proceso de La estimación del coste se hace fácil, ya
en muy poco tiempo, por lo que lo puede frente al cliente, que es la entrega multidisciplinares que creen prototipos y
desarrollo a través de unos hitos bien que la construcción del prototipo se hace
evaluar, probar e, incluso, empezar a temprana de partes operativas del códigos de trabajo de forma rápida, lo que
definidos. en pequeños fragmentos.
utilizarlo Software. supone ser productivos más rápido.

Separación de los componentes del


El modelo proporciona todas las ventajas sistema: exige a los diseñadores y
Se pueden introducir cambios en las
Los costes y la carga de trabajo se del modelo en cascada realimentado, El desarrollo continuo o repetido ayuda en desarrolladores a generar componentes
funcionalidades del sistema en cualquier
Fortalezas pueden estimar al comenzar el proyecto. reduciendo sus desventajas sólo al la gestión de riesgos. funcionales e independientes por sí
momento
ámbito de cada incremento. mismos, y así poder usarlos en una
versión o prototipo iterativo.
Comentarios constantes de los usuarios:
Aquellos proyectos que se estructuran en
Permite entregar al cliente un producto El desarrollo es rápido y las Al poder lanzar prototipos e iteraciones
base al modelo en cascada se pueden
más rápido en comparación del modelo de características se añaden de forma ágilmente, obtendremos un feedback muy
representar cronológicamente de forma
cascada. sistemática. valioso por parte de los usuarios de forma
sencilla.
continuada.
Integración temprana de sistemas: podrán
Siempre hay espacio para atender los ser integrados casi desde el comienzo con
comentarios de los clientes. otros sistemas. A diferencia de los
softwares desarrollados en cascada.

Requiere sistemas modulares: cada


Por norma general, los proyectos más El cliente puede quedar convencido con No es recomendable para casos de
componente del sistema debe ser iterable
complejos o de varios niveles no permiten las primeras versiones y, quizás, no vea la sistemas de tiempo real, de alto nivel de Riesgo de no cumplir con la planificación
y constatable por sí mismo, para poder ser
su división en fases de proyecto necesidad de completar el sistema o seguridad, de procesamiento distribuido, o el presupuesto.
modificados o intercambiados por
claramente diferenciadas. rediseñarlo con la calidad necesaria. y/o de alto índice de riesgos.
cualquier miembro del equipo.

Dificultad dentro de proyectos a gran


escala: Cuando estemos ante un proyecto
Poco margen para realizar ajustes a lo Requiere trabajo del cliente para evaluar Funciona mejor para proyectos grandes, que implique muchas personas y
Requiere de mucha planeación, tanto
largo del proyecto debido a un cambio en los distintos prototipos y traducirlo en aunque en estos también requiera de una aplicaciones, la flexibilidad puede llegar a
administrativa como técnica.
las exigencias. nuevos requisitos. estricta evaluación de riesgos. ser un problema puesto que perderemos
ligeramente el control sobre el diseño y el
desarrollo.

Exige mucha interactividad del usuario:


Conseguir feedback del usuario desde
Debilidades una etapa temprana es muy útil pero, a la
El usuario final no se integra en el Para su buen funcionamiento, el protocolo
Requiere un tiempo adicional para definir Requiere de metas claras para conocer el vez, puede ser una espada de doble filo
proceso de producción hasta que no del modelo en espiral debe ser seguido
adecuadamente el sistema. estado del proyecto. ya que tendremos que aceptar todo tipo
termina la programación. estrictamente.
de críticas constructivas y ser competente
a la hora de comunicarse con los
usuarios.

Necesidad de desarrolladores senior:


Aplicar la metodología RAD no es tan fácil
En ocasiones, los fallos solo se detectan
Involucra al usuario en la evaluación de la Se genera más documentación al tener como parece, por lo que en el equipo
una vez finalizado el proceso de
interfaz de usuario. fases intermedias. serán necesarios desarrolladores hábiles
desarrollo.
que sean capaces de aplicar y adaptarse
a cualquier necesidad o cambio.

No es aconsejable para proyectos


pequeños, la ratio coste beneficio no es
rentable.
VINCULO HOJA DE CALCULO

https://laiberocol-

my.sharepoint.com/:x:/g/personal/carenas1_ibero_edu_co/ESGEuFKG_olIiFN4fjDk6UUBYSM0yXjIxQEy

RG7VkxOtiw?e=fKlmI3

REFERENCIAS BIBLIOGRÁFICAS ADICIONALES

https://www.incentro.com/es-es/blog/stories/metodologia-rad-desarrollo-rapido- aplicaciones/

https://www2.deloitte.com/es/es/pages/technology/articles/que-es-el-desarrollo-en- espiral.html

https://blog.becas-santander.com/es/metodologias-desarrollo-software.html

https://sites.google.com/site/metdlgsddesarrollodesoftware/modelo-contractual/4-2-planeacion-1

REFERENCIAS BIBLIOGRÁFICAS

Recursos de revisión básica

Bourque, P. & Fairley, R. E. (2014). Swebok. Guide to the Software Engineering Body of Knowledge -

Version 3.0. IEEE Computer Society. Recuperado de https://www.computer.org/web/swebok/v3

Campderrich Falgueras, B. (2013). Ingeniería del software. Editorial UOC.

Recuperado de la base de datos E-libro. Para consultarlo, revise la carpeta "Herramientas de apoyo"

(Manual bibliotecas virtuales)https://elibro.net/es/lc/biblioibero/titulos/56294

Lis, G, Pantaleo, L. (2018). Ingeniería de Software (1ª Ed.).

Recuperado de la base de datos Alfaomega Cloud. Para consultarlo, revise la carpeta "Herramientas de

apoyo" (Manual bibliotecas virtuales) https://www-alfaomegacloud

com.ibero.basesdedatosezproxy.com/auth/ip?intended_url=https://www-alfaomegacloud-

com.ibero.basesdedatosezproxy.com/library/publication/ingenieria-de-software

Polansky, J., & Sinclair, M. (2014). La importancia de formar en métodos formales en Ingeniería de

Software. Revista Antioqueña de Las Ciencias Computacionales, 4(2), 52–56.


Recuperado de https://search-ebscohost-

com.ibero.basesdedatosezproxy.com/login.aspx?direct=true&db=a9h&AN=100605550&lang=es

&site=ehost-live