División de Ingeniería

Ingeniería de Sistemas de Información

Trabajo 1
Materia: Ingeniería de Software
Maestra: Pesantes Espinoza Mery Helen
Semestre: 2019-2

Integrantes:
Acosta Báez Bryan Alan
Martínez Lemas Lucía del Carmen
Herrera Armenta Vivian Ileana
Palafox Muñoz Aileen
Alvarado Pérez Pablo Fernando
González Munguía José Antonio
Wong González Emilio Israel

Fecha: 19 de agosto del 2019

Hermosillo, Sonora, México
 Introducción:
Este es un trabajo para la materia de ingeniería de Software en el semestre 2019-2
de la universidad de Sonora, consiste en generar un cuadro comparativo entre los
siguientes modelos de procesos de la ingeniería de software:

1. Modelo Cascada o Clásico

2. Modelo evolutivo (se considera la técnica de prototipo)
3. Desarrollo basado en componentes
4. Desarrollo basado en aspectos
5. Modelo de métodos formales.

Las características que se detectaron en la lectura y que aparecen en el cuadro son:

definición, fases producto de trabajo, experiencia, entre otras.

La información consultada para la generación del cuadro se obtuvo de tres libros

cuya bibliografía aparece al final del trabajo.

En la siguiente página se encuentra el cuadro comparativo.

Modelo Definición Fases Producto de Experiencia Roles Cuando se Técnicas Ventajas Desventajas
trabajo recomienda
usar
1. Sugiere un -Análisis Entrega un Se requiere Los roles Se debe usar En este modelo -Todo está -Rara vez los
Cascad enfoque -Diseño sistema una gran varían cuando los se debe bien proyectos
a sistemático, -Codificación completo una experiencia y dependiendo requerimientos documentar organizado siguen una
secuencial, -Pruebas vez que la altos de las se entiendan cada fase (las secuencia lineal.
para el - secuencia conocimientos necesidades bien y sea cuales van de -No se
desarrollo Mantenimiento lineal haya para recabar del software a improbable el forma mezclan -Difícil d-e
del software. finalizado. los realizar, pero cambio radical secuencial) y se las fases. establecer todos
Esto debido requerimientos para la etapa durante el debe terminar los requisitos al
que se tienen del software de análisis se desarrollo del una para poder -Simple y fácil principio.
los (fase de requiere de un sistema. pasar a la otra. de llevar a la
requerimient análisis), ya analista quien Cada fase práctica y fácil -No se
os que es vital es debe retroalimenta a de gestionar. dispondrá de
necesarios para este comprender el la otra. una versión
definidos. modelo tener dominio de Las otras funcional del
También se bien definidos información del técnicas varían (los)
entrega una estos, para software, por ejemplo programa(s)
documentaci comprender la función diagramado hasta que el
ón detallada naturaleza del requerida, UML para la fase proyecto esté
de cada fase. (los) comportamient de diseño, etc. muy avanzado.
programa(s) a o, rendimiento
construirse e
interconexión.

2. Es un - Entrega un Este modelo Los roles Este modelo Un flujo de -La -Proceso no
Evolutiv modelo Comunicación prototipo que requiere de varían es efectivo en proceso especificación visible
o iterativo. Se -Plan rápido sirve como experiencia en dependiendo proyectos evolutivo realiza puede
caracteriza -Modelado, “el primer la del proyecto, pequeños o las actividades desarrollarse -Sistemas
por la diseño rápido sistema” el identificación ya que este medianos con en forma de forma pobremente
manera en la -Construcción cual se de riesgos, modelo ayuda poco tiempo “circular”. A creciente. estructurados
que permite del Prototipo recomienda debido a los a definir los para su través de las
desarrollar -Desarrollo, desecharlo, riesgos que requisitos no desarrollo. cinco -Los usuarios y -Se requieren
versiones entrega y aunque este pueden definidos por el actividades, desarrolladore técnicas y
cada vez retroalimentaci puede ser aparecer en cliente y esto cada circuito s logran un herramientas
más ón evolutivo, es cada etapa de ayuda al lleva a una mejor que pueden ser
decir, poco a desarrollo. desarrollador a versión más incompatibles o
 completas poco se comprenderlos completa del entendimiento con otras o que
del software. transforman . software. del sistema. poca gente sabe
en el sistema usar,
real. -Es más
efectivo que el
modelo de
cascada, ya
que cumple
con las
necesidades
inmediatas del
cliente.
3. Sienta las -Investigación Generación Se requiere de Los roles de Se utiliza para -Incorpora -Reutilización -No siempre un
Desarro bases para y evaluación de una gran los grupos de reducir costos, muchas de las de software. componente
llo el diseño y del tipo de aplicaciones comunicación desarrolladore tiempos y características -Reduce los cumple con
basado desarrollo aplicación, y a partir de con el equipo y s varían esfuerzos de del modelo en ciclos de todos los
en de componentes fragmentos los clientes dependiendo desarrollo de espiral, y tiene desarrollo. requerimientos.
compon aplicaciones disponibles. de software para poder del tipo de software. un enfoque -Reduce el -Certificación de
entes distribuidas prefabricado realizar software que iterativo. costo del los procesos.
basadas en - s. eficientemente se vaya a proyecto. -Esta tecnología
componente Consideración el software crear. - Simplificación requiere
s software de los deseado de Pruebas y robustez ya que
reutilizables. aspectos de corrigiendo o mantenimiento los
integración de mejorando su componentes
los desempeño y deben operar en
componentes. también entornos más
reduciendo su heterogéneos.
tiempo de
-Se diseña
entrega
arquitectura
del software
para que
reciba los
componentes.

-Integración
de
componentes
 a la
arquitectura.

-Pruebas
4. Es Un -Captura de Sistemas Es necesario Como es una Se puede usar Separación de - - Paradigma
Desarro paradigma requerimiento complejos tener extensión de cuando se competencias o Modularizació difícil de
llo que s con experiencia OOP, los roles necesita tener aspectos: se n del código entender,
basado proporciona subsistemas con la son un software debe organizar debido a que es
s en un proceso y -Análisis o módulos, traducción de exactamente con módulos el software de -Fácil tiene diferencias
aspecto enfoque que son requisitos o los mismos, no enteramente modo que cada mantenimiento fundamentales
s metodológic sumamente requerimientos es necesario independiente elemento en el de software en la manera de
-Diseño
o para fáciles de a lenguaje de tener un s que pueden programa estructurar el
definir, mantener y sistema, experto en un ser usados en (clase, método, -Módulos código y sus
especificar, - reutilizar, que además de área cualquier parte procedimiento, reutilizables en pertinentes
diseñar y Implementació tienen muy tener específica; del código y de etcétera) realice otro software llamadas entre
construir n bien definida experiencia puede variar manera una función y módulos.
aspectos. su función. con el como por separada sólo una función.
paradigma de ejemplo Entonces podrá
OOP, puesto programadore enfocarse en
que ambos s, DBA, etc. ese elemento sin
comparten considerar los
mucho en otros elementos
común en el programa.
5. Utilización -Especificar. Los Debido a la No se tiene Aunque no es OML:Diagramas - Es ventajoso - Se requiere un
Modelo de lenguaje -Diseñar. productos utilización de predeterminad exclusivo de UML con lógica cuando los personal más
de matemático -Verificar. resultados de lenguaje o un modelo de casos matemática para procesos del especializado
método para -Desarrollar. este ciclo de matemático en roles para los científicos se expresar software tienen con lenguajes
s expresar -Validar. vida suelen este ciclo de métodos recomienda funciones y mucha matemáticos y
formale procesos y ser productos vida es formales así utilizar cuando propiedades. ambigüedad al con mayor
s propiedades matemáticos necesario un que se los procesos Lenguaje Z: ser experiencia
con giro en conocimiento recomiendo requieren Notación especificados sobre temas de
las ciencias mayor al aplicar roles eliminar matemática con lenguaje matemática
exactas, promedio para según cada ambigüedad y rígida para natural, este discreta.
aunque no poder caso en dejar un expresar ciclo de vida da
tienen que desarrollarse particular. análisis los comportamiento gran énfasis en -El desarrollo de
ser apropiadament explicito del software el análisis y procesos
obligatoriame e. posible. diseño del formales
nte de este sistema a consume mucho
giro. desarrollar tiempo
Como se puede ver en el cuadro de comparación cada modelo de proceso de
ingeniería de software lo que realmente diferencia dichos modelos es cuando se
debe usar cada uno, para cada modelo se definieron una serie de ventajas y
desventajas en base a las lecturas ya que el equipo considera que es importante
señalar cada una.
1. Modelo en cascada:

El modelo en cascada es el paradigma más antiguo de la ingeniería de software y

durante las últimas décadas ha recibido críticas que han ocasionado que hasta sus
defensores se cuestionan la eficacia de este modelo.

Entre sus principales ventajas se encuentran que todo está bien organizado, no se
mezclan las fases, simple y fácil de llevar a la práctica y fácil de gestionar.

Entre sus principales desventajas se encuentran: rara vez los proyectos siguen una
secuencia lineal, difícil d-e establecer todos los requisitos al principio, No se
dispondrá de una versión funcional del (los) programa(s) hasta que el proyecto esté
muy avanzado.

2. Modelo evolutivo:

Entre sus principales ventajas se encuentran la especificación puede desarrollarse

de forma creciente, los usuarios y desarrolladores logran un mejor entendimiento
del sistema, esto se refleja en una mejora de la calidad del software, y es más
efectivo que el modelo de cascada, ya que cumple con las necesidades inmediatas
del cliente.

Entre sus principales desventajas se tenemos proceso no Visible: Los

administradores necesitan entregas para medir el progreso. Si el sistema se
necesita desarrollar rápido, no es efectivo producir documentos que reflejen cada
versión del sistema, Sistemas pobremente estructurados: Los cambios continuos
pueden ser perjudiciales para la estructura del software haciendo costoso el
mantenimiento, se requieren técnicas y herramientas: Para el rápido desarrollo se
necesitan herramientas que pueden ser incompatibles con otras o que poca gente
sabe utilizar

3. Desarrollo basado en componentes

Las principales ventajas son la funcionalidad mejorada, reduce los costes y tiempos,
reutilización del software, simplifica las pruebas, simplifica el mantenimiento del
sistema, mayor calidad y ciclos de desarrollo más costos.
Entre sus desventajas se encuentran generan tiempos largos, trabajo adicional, y la
confiabilidad de los componentes ya que estos son cajas negras de unidades de
programas, puede que el código de los componentes no esté disponible para los
usuarios.

4. Desarrollo basados en aspectos:

Entre sus principales ventajas se encuentran la modularizarían del código,

independización de los módulos entre los mismos, fácil mantenimiento de software,
módulos reutilizables en otro software.

Su principal desventaja es que es un paradigma difícil de entender, debido a que es

tiene diferencias fundamentales en la manera de estructurar el código y sus
pertinentes llamadas entre módulos.

5. Métodos Formales

La utilización de métodos formales es ventajosa cuando los procesos del software

tienen mucha ambigüedad al ser especificados con lenguaje natural, este ciclo de
vida da gran énfasis en el análisis y diseño del sistema a desarrollar, la gran
desventaja es que se requiere un personal más especializado con lenguajes
matemáticos y con mayor experiencia sobre temas de matemática discreta.

Conclusiones
Como se pudo observar tanto en las lecturas realizadas por el equipo como en la
elaboración del cuadro, la ingeniería de software es una diciplina que se basa en
procesos, herramientas y métodos. A lo largo de la historia se han propuesto y
creado nuevos modelos con características diferentes, estos se pueden aplicar en
diferentes tipos de proyectos según sean las necesidades del sistema y requisitos
que el cliente pida.

Cada modelo tiene sus ventajas y desventajas, algunos son mejores para proyectos
pequeños, otro nos permite afinar requisitos durante el mismo desarrollo, mientras
que algunos ofrecen un sistema completo como producto final o incluso funcionan
como base para la creación de un nuevo modelo.

Lo que tienen en común estos modelos es el conjunto de actividades estructurales

en general. Con el paso del tiempo algunos modelos se han quedado algo obsoletos
ya que en los tiempos modernos la rapidez, plazos ajustados, y cambios continuos
no permiten aplicarlos al pie de la letra; tal es el caso de modelo de cascada que,
dada su rigidez es difícil seguir fase por fase sin regresar, pero sigue siendo una
buena referencia para el desarrollo clásico de sistemas y, junto con los otros
modelos, ayuda a mejorar constantemente el proceso de creación de sistemas.

Bibliografía
R. Pressman, Software engineering, 5th ed. Boston: McGraw Hill, 2002.
R. Pressman, Ingeniería del software, 7th ed. México: McGraw-Hill, 2010.

́ , Ingeniería de software, 9th ed. México:

Sommerville and V. Campos Olguin
PEARSON EDUCACIÓN, 2011.