INSTITUTO TECNOLÓGICO
SUPERIOR DE SAN ANDRÉS
TUXTLA
INGENIERÍA INFORMÁTICA
Materia:
FUNDAMENTOS DE SISTEMAS DE INFORMACIÓN
Docente:
MARÍA DE LOS ÁNGELES PELAYO VAQUERO
Grupo:
310-A
Alumno:
LUIS ENRIQUE RIVAS CHAMPALA
U3
INVESTIGACIÓN
“MODELOS”
INTRODUCCIÓN
Los modelos de proceso fueron creados para establecer orden, aunque ya existían
métodos tradicionales, pero sin embargo esto no era suficiente porque seguía
habiendo problemas con el desarrollo del software, la ingeniería de software se ha
encargado de adoptar nuevos modelos que se puedan adaptar a cualquier tipo de
proyecto según su naturaleza.
Todos los modelos de procesos pueden incluir las actividades generales de
ingeniería de software, e incluso los modelos prescriptivos las incluyen, pero sin
embargo cada modelo las utiliza a su modo y pone énfasis en cada una de sus
actividades y la manera en que se relacionan los procesos es diferente para
actividad.
Los modelos prescriptivos son llamados así porque prescriben un conjunto
de métodos, herramientas, tareas de ingeniería de software y actividades
estructurales y cada modelo describe un flujo de datos diferente, a continuación,
estudiaremos los modelos de procesos prescriptivos.
Modelos prescriptivos del desarrollo de sistemas de
información
MODELO EN CASCADA
La metodología Waterfall (Cascada) es un proceso de desarrollo secuencial de
proyectos que suele utilizarse en el desarrollo de software. Esta metodología
concibe el trabajo en un conjunto de etapas que deben ejecutarse una tras otra.
Su nombre viene dado por las diferentes
fases que componen el proyecto, ya que
deben colocarse una encima de otra
siguiendo un orden concreto y estricto de
arriba hacia abajo. No podemos, por
ejemplo, empezar la fase de diseño sin
haber terminado la de los requisitos.
Waterfall impulsa la filosofía paso a paso,
por bloques de tareas. [1]
Esta metodología se remonta al 1970, año en que Winston W. Royce
adaptó la idea del modelo Waterfall tal y como lo conocemos. Royce presentó el
modelo sin establecer todavía un título definitivo a través de su artículo
Gestionando el Desarrollo de Grandes Sistemas de Software.
El Modelo Waterfall original de Royce contenía los siguientes elementos:
- Análisis de requisitos del sistema y del software. A partir de consultas con los
usuarios, se analiza qué servicios, restricciones y metas del sistema existen. Se
detallan y se utilizan como base de la que partir.
- Diseño. Se establece la arquitectura completa del sistema y, a grandes rasgos,
se describen las partes que deben formar el producto o servicio final.
- Implementación y testing de unidades. Se ejecuta el software como un
conjunto o unidad de programas para verificar que cada unidad cumpla con su
especificación.
- Integración y testing del sistema. Cada una de las partes del software que
forman el producto final se integran y prueban como un sistema completo para
asegurar que cumple con todos los requisitos. Tras esta etapa, el producto o
servicio se entrega al cliente.
- Mantenimiento. Suele tratarse de la fase más larga del ciclo de desarrollo. Se
instala el sistema y se pone en marcha. A partir de este punto, el desarrollo se
centra en la corrección de errores no descubiertos en las etapas anteriores, en
mejorar el sistema y adaptar sus servicios si aparecen nuevos requerimientos.
Por lo general, la finalización de cada una de las fases tiene como resultado
la generación de un documento firmado y aprobado. Sin embargo, el proceso de
desarrollo real no es nunca lineal, por lo que pueden darse problemas si no se
aplican una serie de iteraciones entre las diferentes partes del proceso. Por todo
ello, este modelo es recomendable si es poco probable que los requerimientos
vayan a cambiar radicalmente durante el desarrollo del sistema.
MODELOS EVOLUTIVOS
El software evoluciona con el tiempo, los requisitos del usuario y del producto
suelen cambiar conforme se desarrolla el mismo. Las fechas de mercado y la
competencia hacen que no sea posible esperar a poner en el mercado un
producto absolutamente completo, por lo que se aconsejable introducir una
versión funcional limitada de alguna forma para aliviar las presiones competitivas.
En esas u otras situaciones similares los desarrolladores necesitan modelos
de progreso que estén diseñados para acomodarse a una evolución temporal o
progresiva, donde los requisitos centrales son conocidos de antemano, aunque no
estén bien definidos a nivel detalle. [2]
Los modelos de proceso evolutivo tienen su razón de ser en el hecho de
que “el software”, como todos los sistemas complejos, evoluciona en el tiempo. Es
frecuente que los requerimientos del negocio y del producto cambien conforme
avanza el desarrollo, lo que hace que no sea realista trazar una trayectoria
rectilínea hacia el producto final. Se comprende bien el conjunto de requerimientos
o el producto básico, pero los detalles del producto o extensiones del sistema aún
están por definirse. Estos modelos son iterativos y se caracterizan por el desarrollo
de versiones cada vez más completas del software. [3]
A continuación, se presentan dos modelos del proceso evolutivo:
1. Construcción de Prototipos. Un prototipo se puede definir como un
sistema auxiliar que permite probar experimentalmente ciertas soluciones
parciales a las necesidades del usuario o a los requisitos del sistema.
Puede tratarse de un modelo que describa la interacción hombre-máquina,
de manera que facilite al usuario la comprensión de cómo se producirá la
interacción, o un programa que implemente algunos subconjuntos de la
funcionalidad de la aplicación.
En este modelo, se construye el
software a partir de versiones cada vez
más completas, de manera que se
realizan una serie de tareas más
completas.
2. Modelo en Espiral. Este modelo evolutivo fue diseñado para cubrir las
mejoras características tanto del modelo en cascada, como del modelo de
construcción de prototipos, añadiendo un nuevo elemento, que es el
análisis de riesgo, dentro de la actividad estructural de planificación.
Como modelo de desarrollo evolutivo que es, el software se
desarrolla en una serie de entregas que se pueden representar como
iteraciones o vueltas alrededor de una espiral.
- Planificación. Se identifican los objetivos
que se desean conseguir mediante la
iteración, así como las alternativas para la consecución de dichos
objetivos y las restricciones impuestas en cuanto a plazos, costes, etc.
- Análisis de riesgo. Consiste en evaluar las diferentes alternativas para la
realización de la parte del desarrollo elegida, seleccionando la más
ventajosa y tomando precauciones para evitar los inconvenientes o
riesgos previstos.
- Ingeniería. Se desarrolla el producto (análisis, diseño, programación,
etc.). El objetivo es ir obteniendo en cada ciclo una versión más
completa del sistema.
- Evaluación. El resultado del trabajo de ingeniería es evaluado por el
cliente y se decide si se continúa, para lo que se procede a planificar la
siguiente iteración.
La principal ventaja de este modelo es que la consideración de los riesgos o
problemas que pueden afectar al desarrollo del software en diferentes momentos
permite que tanto quienes encargaron el software como los que desarrollan sean
conscientes de los problemas que pueden presentarse y sean capaces de
reaccionar en caso de que estos ocurran
MODELOS ESPECIALES
Modelo iterativo incremental. En términos generales, se puede distinguir, los
pasos generales que sigue el proceso de desarrollo de un producto software. En el
modelo de ciclo de vida seleccionado, se identifican claramente dichos pasos. La
descripción del sistema es esencial para especificar y confeccionar los distintos
incrementos hasta llegar al producto global y final. Las actividades concurrentes
(especificación, desarrollo y validación) sintetizan el desarrollo pormenorizado de
los incrementos, que se hará posteriormente. [4]
Cambian los elementos del modo lineal secuencial (aplicados
repetidamente) con la filosofía interactiva de construcción de prototipos. El modelo
incremental aplica secuencias lineales de forma escalonada mientras progresa el
tiempo en el calendario. Cada secuencia lineal produce un incremento del
software. [5]
Por ejemplo, el software de tratamiento de textos desarrollando con el paradigma
incremental podría extraer funciones de gestión de archivos básicos y de
producción de documentos en el primer incremento; funciones de edición más
sofisticadas y de producción de documentos en el segundo incremento; corrección
ortográfica y gramatical en tercero; y una función avanzada de esquema de página
en el cuarto. Se deberían tener en cuenta que el flujo del proceso de cualquier
incremento puede incorporar el paradigma de construcción de prototipos.
Cuando se utiliza un modelo incremental el primer incremento es un
producto esencial. Es decir, se afrontan requisitos básicos pero muchas funciones
suplementarias (algunas conocidas otras no). Como un resultado de utilización y/o
de evaluación, se desarrolla un plan para el incremento.
El plan afronta la modificación del producto central a fin de cumplir mejor las
necesidades del cliente y la entrega de funciones, y características adicionales.
Este proceso se repite siguiendo la entrega de cada incremento, hasta que se
elabore el producto completo.
El desarrollo incremental es particularmente útil cuando la dotación de
personal no está disponible para una implementación completa en la fecha
limitada que se haya establecido para el proyecto.
Modelo Concurrente. se puede sentar en forma de esquema como una serie de
actividades técnicas importantes, tareas y estados asociados a ellas. Por ejemplo,
la actividad de ingeniería definida para el modelo en espiral, se lleva a cabo
invocando las tareas siguientes: modelado de construcción de prototipos y/o
análisis, especificación de requisitos y diseño.
El modelo de proceso unificado. Proporciona una representación esquemática
de una actividad dentro del modelo de proceso concurrente. La actividad, análisis
se puede encontrar en uno de los estados destacados en cualquier momento
dado. De forma similar, otras actividades (por ejemplo, el diseño o comunicación
con el cliente) se pueden representar de una forma analógica.
Todas las actividades existen concurrentemente, pero residen en estados
diferentes, por ejemplo, al principio del proyecto la actividad de comunicación con
el cliente ha finalizado su primera interacción y está en el estado de cambios en
espera. La actividad de análisis (que está en el estado ninguno mientras que se
iniciaba la comunicación inicial con el cliente) ahora hace una transacción al
estado bajo desarrollo. Sin embargo, si el cliente indica que se deben hacer
cambios en requisitos, la actividad análisis cambia del estado bajo desarrollo al
estado cambios en espera.
El modelo de proceso concurrente. define una serie de acontecimientos que
dispararan transiciones de estado a estado para cada una de las actividades de la
ingeniería del software. Por ejemplo, durante las primeras etapas del diseño, no se
contempla una inconsistencia del modelo de análisis. Esto genera la corrección del
modelo de análisis de sucesos, que dispara la actividad de análisis del estado
hecho al estado cambios en espera.
El modelo de proceso concurrente se utiliza a menudo como el paradigma
de desarrollo de aplicaciones cliente/servidor. Un sistema cliente/servidor se
compone de un conjunto de componentes funcionales. Cuando se aplica a
cliente/servidor, el modelo de proceso concurrente define actividades en dos
dimensiones: una dimensión de sistemas y una dimensión de componentes. Los
aspectos del nivel de sistemas se afrontan mediante tres actividades: diseño,
ensamblaje y uso. Las dimensiones de componentes se afrontan con dos
actividades: diseño y realización. La concurrencia se logra de dos formas.
Bibliografía
[1] D. T. AGENCY, «METODOLOGÍAS DE GESTIÓN DE PROYECTOS,» 1 ed.,
zemsania Global Group.
[2] E. Hernández Pedroza, . E. T. LOZANO ESTRADA y . I. D. J. HERNÁNDEZ
CHAMU, «[Link],» Viernes 04 abril 2014. [En línea]. Available:
[Link]
[Link]. [Último acceso: 06 noviembre 2022].
[3] P. G. J. Manuel, Entornos de Desarrollo, Primera ed., Ediciones Nobel.
[4] [En línea]. Available: [Link]
[Link]. [Último acceso: 06 noviembre 2022].
[5] «[Link],» [En línea]. Available:
[Link] [Último acceso:
06 noviembre 2022].
