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 2

“MODELOS DE PROCESOS PRESCRIPTIVOS”

INTRODUCCIÓN

Cuando se trabaja en la construcción de un producto es necesario realizar tareas

que permitan alcanzar el objetivo, el software como tal es un producto que
desarrollan los ingenieros con la intención de agilizar los procesos. Para
desarrollar software es necesario responder algunas interrogantes sobre el
funcionamiento y desarrollo; es importante definir los requisitos funcionales desde
primera instancia ya que evitara problemas en su futuro desarrollo.

Los desarrolladores de software para poder garantizar la calidad de su

producto utilizan metodologías de desarrollo, estas pueden ser ágiles (implica el
rediseño del producto si llegara a darse por cambios en los requisitos funcionales)
o prescriptivas (se realiza una serie de pasos para alcanzar el desarrollo de la
aplicación a través de un análisis completo de los requisitos).

Independientemente del tipo de metodología que se esté utilizando en la

ejecución del proyecto, esta cuenta con actividades estructurales tales como:
comunicación, planeación, modelado, construcción y despliegue, que pertenecen
a un modelado general de proceso y estructura de desarrollo. A continuación, se
detalla lo anteriormente expuesto.

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.

OBJETIVO DE LA INVESTIGACIÓN

Conocer sobre los modelos de procesos utilizados para desarrollar software de

calidad en la ingeniería de software.
 Modelos de procesos prescriptivos del desarrollo de
software

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. [1]

Los modelos de proceso prescriptivo fueron propuestos originalmente para

poner orden en el caos del desarrollo de software. La historia indica que estos
modelos tradicionales han dado cierta estructura útil al trabajo de ingeniería de
software y que constituyen un mapa razonablemente eficaz para los equipos de
software.

Todos los modelos del proceso del software pueden incluir las actividades
estructurales generales, pero cada una pone distinto énfasis en ellas y define en
forma diferente el flujo de proceso que invoca cada actividad estructural (así como
acciones y tareas de ingeniería de software). [2]

Los modelos de procesos intentan dar una descripción particular y no

definitiva de un proceso software. Son abstracciones que se pueden utilizar para
abordar el desarrollo software y que a lo largo del tiempo han demostrado su
efectividad en muchos proyectos.

Se puede pensar en ellos como marcos de trabajo del proceso que pueden
ser ampliados con mecanismos y que son adaptados a las necesidades
específicas de cada sistema. [3]

Dentro de los modelos de proceso prescriptivo tenemos: cascada, incremental,

evolutivo y concurrentes, a continuación, se detallan sus características.
MODELO EN CASCADA

Hay veces en las que los requerimientos para cierto problema se comprenden
bien: cuando el trabajo desde la comunicación hasta el despliegue fluye en forma
razonablemente lineal. Esta situación se encuentra en ocasiones cuando deben
hacerse adaptaciones o mejoras bien definidas a un sistema ya existente.
También ocurre en cierto número limitado de nuevos esfuerzos de desarrollo, pero
sólo cuando los requerimientos están bien definidos y tienen una estabilidad
razonable.

El modelo de la cascada, a veces llamado ciclo de vida clásico, sugiere un

enfoque sistemático y secuencial para el desarrollo del software, que comienza
con la especificación de los requerimientos por parte del cliente y avanza a través
de planeación, modelado, construcción y despliegue, para concluir con el apoyo
del software terminado. [4]

Este modelo utiliza un proceso lineal secuencial, las actividades son

ejecutadas en secuencia, es decir no puede iniciar una actividad sin antes haber
terminado la anterior, su desarrollo comienza desde la comunicación hasta el
despliegue. [1]

El modelo de la cascada es el paradigma más

antiguo de la ingeniería de software, es por esto que
en el momento de utilizarlo aparecen ciertos
problemas que se detallan a continuación. Este
modelo es aplicable para proyectos que tienen bien
establecidos los requerimientos o a proyectos a los
que se le va a realizar alguna modificación ya que generalmente en esos casos se
sabe que es lo que se va a hacer.

MODELO EN PROCESO INCREMENTAL

Hay muchas situaciones en las que los requerimientos iniciales del software están
razonablemente bien definidos, pero el alcance general del esfuerzo de desarrollo
imposibilita un proceso lineal. Además, tal vez haya una necesidad imperiosa de
dar rápidamente cierta funcionalidad limitada de software a los usuarios y
aumentarla en las entregas posteriores de software. En tales casos, se elige un
modelo de proceso diseñado para producir el software en incrementos. [2]

El modelo de proceso incremental se utiliza cuando no es factible llevar un

desarrollo secuencial a pesar de que ya se hayan establecido bien los
requerimientos, este proceso avanza de forma escalonada secuencial de acuerdo
al calendario de actividades combinando el proceso lineal y paralelo para realizar
incrementos (versiones) y hacer entrega de pequeñas partes del software, estas
partes son entregadas totalmente funcionales, lo cual permite mantener contento
al cliente. Este modelo utiliza las cinco actividades generales de la ingeniería en
software, pero el flujo de los procesos es distinto. [1]

Por ejemplo, un
software para
procesar textos que
se elabore con el
paradigma
incremental

quizá entregue en
el primer
incremento las funciones básicas de administración de archivos, edición y
producción del documento; en el segundo dará herramientas más sofisticadas de
edición y producción de documentos; en el tercero habrá separación de palabras y
revisión de la ortografía; y en el cuarto se proporcionará la capacidad para dar
formato avanzado a las páginas. Debe observarse que el flujo de proceso para
cualquier incremento puede incorporar el paradigma del prototipo. [4]

MODELO EVOLUTIVO

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; los plazos apretados del mercado hacen que sea
imposible la terminación de un software perfecto, pero debe lanzarse una versión
limitada a fin de aliviar la presión de la competencia o del negocio; 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. En estas situaciones y
otras parecidas se necesita un modelo de proceso diseñado explícitamente para
adaptarse a un producto que evoluciona con el tiempo.

Hacer prototipos. Es frecuente

que un cliente defina un conjunto de
objetivos generales para el software,
pero que no identifique los
requerimientos detallados para las
funciones y características. En otros
casos, el desarrollador tal vez no esté
seguro de la eficiencia de un algoritmo,
de la adaptabilidad de un sistema
operativo o de la forma que debe
adoptar la interacción entre el humano y
la máquina. En estas situaciones, y muchas otras, el paradigma de hacer
prototipos tal vez ofrezca el mejor enfoque.
 El modelo espiral. Propuesto en primer lugar por Barry Boehm [Boe88], el
modelo espiral es un modelo evolutivo del proceso del software y se acopla con la
naturaleza iterativa de hacer prototipos con los aspectos controlados y sistémicos
del modelo de cascada. Tiene el potencial para hacer un desarrollo rápido de
versiones cada vez más completas. [4]
MODELOS CONCURRENTES

El modelo de desarrollo concurrente, en ocasiones llamado ingeniería concurrente,

permite que un equipo de software represente elementos iterativos y concurrentes
de cualquiera de los modelos de proceso descritos en este capítulo. Por ejemplo,
la actividad de modelado definida para el modelo espiral se logra por medio de
invocar una o más de las siguientes acciones de software: hacer prototipos,
análisis y diseño. [4]

Permite presentar elementos iterativos y concurrentes de cualquiera de los

otros modelos iterativos, son adaptables para cualquier tipo de proyecto siempre y
cuando involucre equipos de trabajo.

Este modelo maneja estados para saber exactamente el estado actual de

desarrollo del producto, los estados que maneja son bajo desarrollo, cambios en
espera, bajo modificación, bajo revisión, en línea base y realizado, estos estados
permiten los integrantes del equipo de desarrollo conozcan el estado actual de
cada actividad ya que en este modelo el proceso puede iniciar desde cualquier
parte. [1]

Por ejemplo, la actividad de

comunicación (no se muestra en
la figura) termina su primera
iteración al principio de un
proyecto y existe en el estado de
cambios en espera. La actividad
de modelado (que existía en
estado inactivo mientras concluía
la comunicación inicial, ahora
hace una transición al estado en desarrollo. Sin embargo, si el cliente indica que
deben hacerse cambios en los requerimientos, la actividad de modelado pasa del
estado en desarrollo al de cambios en espera.
CONCLUSIÓN

Los modelos de proceso nos permiten llevar un control en el desarrollo del

software a través de actividades estructurales como: comunicación, planeación,
modelado, construcción y despliegue.

Las actividades estructurales definen las tareas que deben ser

desarrolladas por el equipo para garantizar el éxito del proyecto, sin embargo,
dentro de estas pueden existir varias actividades sombrillas. Las actividades
sombrillas aseguran la calidad del producto que se está realizando, es por esto
que una actividad sombrilla común seria “seguimiento y control del proyecto”.

Puedo mencionar que los modelos de procesos prescriptivos permiten

establecer métodos, actividades, y herramientas para llevar a cabo el desarrollo de
un software, y es muy importante ya que permite llevar un control de las
actividades puesto que ofrece una secuencia de pasos ya sea esta lineal, iterativa,
o evolutiva.

Los modelos de procesos prescriptivos se utilizan cuando los

requerimientos se encuentran bien definidos desde el inicio, es el caso del proceso
cascada que se utiliza cuando los requerimientos no cambian o para la mejora de
un producto ya realizado donde los requerimientos ya fueron definidos, el modelo
incremental permite entregar software en cada incremento con nuevas
funcionalidades que fueran especificadas en los requerimientos, el proceso
evolutivo por así decirlo muestra cómo evoluciona a través del tiempo y los
modelos concurrentes permiten realizar varios análisis de los requerimientos al
combinar varios procesos de desarrollo y mantener las actividades en un estado
(inactivo, en desarrollo, ejecutado, etc.).
BIBLIOGRAFÍA

[1] A. NATHALY, «Ingeniería en software,» 24 Abril 2015. [En línea]. Available:

https://ingenieriaensoftwarenathalyalava.wordpress.com/2015/04/25/modelos-de-
procesos-prescriptivos/. [Último acceso: 25 Noviembre 2022].

[2] C. Karla, «Ingeniería del software (Portafolio Digital),» 20 abril 2015. [En línea].

Available: https://ingsotfwarekarlacevallos.wordpress.com/2015/04/22/modelos-de-
procesos/. [Último acceso: 25 noviembre 2022].

[3] V. R. J. Luis, Desaarrollo y optimización de componentes software para tareas

administrativas de sistemas., 1ra Edición ed., ic editorial,, 2014.

[4] «www.FreeLibros.me,» [En línea]. Available:

https://www.ecotec.edu.ec/material/material_2019F1_COM335_02_124797.pdf.
[Último acceso: 25 Noviembre 2022].