Un Modelo general de proceso

Se puede definir a un proceso como la colección de actividades de trabajo,

acciones y tareas que se realizan cuando va a crearse algún producto terminado.
Cada una de las actividades, acciones y tareas se encuentra dentro de una
estructura o modelo que define su relación tanto con el proceso como entre sí
(Pressman, R. 2010).
Cada actividad estructural está formada por un conjunto de acciones de
ingeniería de software y cada una de éstas se encuentra definida por un conjunto
de tareas que identifica las tareas del trabajo que deben realizarse:

Figura 1: Características que deben tomarce en cuenta dentro del desarrollo

del software
El flujo de un modelo general de proceso normalmente utiliza las 5 actividades
estructurales descritas en la unidad anterior, como son: comunicación,
planeación, modelado, construcción, despliegue. Las mismas que pueden tener
varias actividades sombrillas que se llevan a cabo para asegurar la calidad del
software.
 Figura 2: Conjunto de actividades que se deben realizar para elaborar
software de calidad
A continuación se definen algunos de los términos más utilizados en cualquier
modelo de proceso de desarrollo de software.
 Figura 3: Términos mas utilizados en cualquier modelo de proceso
3.2. Modelos de proceso Prescriptivo
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) ( López , P y Francisco, R.
s/f).
Dentro de los modelos de proceso prescriptivo tenemos: cascada, incremental,
evolutivo y concurrentes, a continuación se detallan sus características.
 Figura 4: Modelos de proceso Prescriptivos
3.2.1. Modelo de la cascada
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 (Pressman, R. 2010)
Este tipo de modelo es utilizado cuando 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 (por ejemplo, una adaptación para software de contabilidad
que es obligatorio hacer debido a cambios en las regulaciones
gubernamentales). 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.

Figura 5: Modelo Cascada

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.
 Figura 5: Problemas en el desarrollo de una metodología en cascada
3.2.2. Modelos de 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.
Cuando se utiliza un modelo incremental, es frecuente que el primer incremento
sea el producto fundamental. Es decir, se abordan los requerimientos básicos,
pero no se proporcionan muchas características suplementarias (algunas
conocidas y otras no). El cliente usa el producto fundamental (o lo somete a una
evaluación detallada). Como resultado del uso y/o evaluación, se desarrolla un
plan para el incremento que sigue. El plan incluye la modificación del producto
fundamental para cumplir mejor las necesidades del cliente, así como la entrega
de características adicionales y más funcionalidad. Este proceso se repite
después de entregar cada incremento, hasta terminar el producto final
(Pressman, R. 2010).
 Figura 6: Modelo Incremental
3.2.3. Modelos de proceso Evolutivo
Los modelos evolutivos son iterativos. Se caracterizan por la manera en la que
permiten desarrollar versiones cada vez más completas del software.
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.
Dentro del proceso evolutivo encontramos dos modelos: prototipos y modelo
espiral que se detallan a continuación:
 Figura 7: Modelos de proceso Evolutivo
3.2.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.
Todas las actividades de ingeniería de software existen de manera concurrente,
pero se hallan en diferentes estados. 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 acerse cambios en los requerimientos, la actividad de modelado pasa
del estado en desarrollo al de cambios en espera (Pacheco, I y García, J.
2008).
 Figura 8: Modelos de proceso Concurrentes
4. CONCLUSIONES
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”.
Aunque el desarrollo de un proyecto de software utilice modelos de proceso,
esto no garantiza que el proyecto sea entregado a tiempo, ya que las
metodologías de desarrollo prescriptivas (cascadas, incrementales, evolutivas y
concurrentes) no permiten adaptarse a la situación del mundo real en la que se
está desenvolviendo la construcción del producto.
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).
5. BIBLIOGRAFÍA
López , P y Francisco, R. s/f. INGENIERÍA DEL SOFTWARE. (En línea). VE.
Consultado, 14 de abril de 2015. Formato PDF. Disponible
en: http://ocw.unican.es/ensenanzas-tecnicas/ingenieria-del-software-
i/materiales-de-clase-1/is1-t02-trans.pdf
Pacheco, I y García, J. 2008. Una Metodología Basada en Prácticas Efectivas
para Desarrollar Software Educativo.MX. Postgraduate Department,
Technological University of the Mixtec Region. vol.11 no.4 . (En línea).
Consultado, 14 de abril de 2015. Formato PDF. Disponible
en: http://www.scielo.org.ve/scielo.php?script=sci_arttext&pid=S0798-
40652010000400003&lang=pt
Pressman, R. 2010. Ingeniería del Software Un Enfoque Práctico. 7ma ed.
University ofConnecticut. McGraw-Hill Interamericana Editores, S.A.

MODELO LINEAL SECUENCIAL (CASCADA)

También llamado "Ciclo de vida básico" o "Modelo de cascada" tiene su origen en el "Modelo de
cascada" ingeniado por Winston Royce, aunque omite los muchos bucles de este último. El
Modelo Lineal Secuencial sugiere un enfoque sistemático o más bien secuencial del desarrollo
de software que comienza en un nivel de sistemas y progresa con el análisis, diseño, codificación,
pruebas y mantenimiento. El Modelo Lineal Secuencial acompaña las siguientes actividades:

GRÁFICO DEL MODELO LINEAL SECUENCIA

"CASCADA"

IMAGEN:https://upload.wikimedia.org/wikipedia/commons/thumb/0/01/Modelo_Cascada_Secuencial.jpg/350px-
Modelo_Cascada_Secuencial.jpg

Análisis de los requerimientos del software:

Es la fase en la cual se reúnen todos los requisitos que debe cumplir el software. En esta etapa
es fundamental la presencia del cliente que documenta y repasa dichos requisitos.
IMAGEN: http://www.culturareviu.com/img/webupload/articulos/estudio-aprendizaje-consejos-analizar
textocualquiera_4286193e862e091f872b36c5b40b3ddc.jpg

Diseño:
Es una etapa dirigida hacia la estructura de datos, la arquitectura del software, las
representaciones de la interfaz y el detalle procedimental (algoritmo). En forma general se hace
un esbozo de lo solicitado y se documenta haciéndose parte del software.

IMAGEN: http://www.simonbolivarcft.cl/img/informatico.jpg

Generación del código:

Es la etapa en la cual se traduce el diseño para que sea comprensible por la máquina. Esta
etapa va a depender estrechamente de lo detallado del diseño.

IMAGEN: http://2.bp.blogspot.com/_b9MIx5ZGEAM/S-Dgubjak3I/AAAAAAAAAJ0/JPMHOgvjva4/s320/Digital.gif

Pruebas:
Esta etapa se centra en los procesos lógicos internos del software, asegurando que todas las
sentencias se han comprobado, y en la detección de errores.

IMAGEN:http://3.bp.blogspot.com/-vWQ_-kelOPk/Tb36n0Qvv2I/AAAAAAAAACs/e60lOBMoG44/s1600/pruebas.jpg

Mantenimiento:
Debido a que el programa puede tener errores, puede no ser del completo agrado del cliente o
puede necesitar, eventualmente acoplarse a los cambios en su entorno. Esto quiere decir que
no se rehace el programa, sino que sobre la base de uno ya existente se realizan algunos
cambios.

IMAGEN: http://ayudawordpress.com/wp-content/uploads/2011/05/mantenimiento.jpg

El Modelo Lineal Secuencial es el paradigma de desarrollo de software más antiguo que existe,
sin embargo esto no ha impedido que se haya creado una desconfianza alrededor de él basada
en los siguientes errores reales:
 Los proyectos raramente siguen el paradigma secuencial que propone el proyecto.
 A menudo es difícil que el cliente exponga exactamente todos los requisitos.
 El cliente debe tener paciencia.
Los responsables del desarrollo de software siempre se retrasan innecesariamente. Todo lo
anteriormente expuesto es cierto pero este paradigma tiene un lugar bien definido e importante
en el trabajo de la Ingeniería de Software aparte de proporcionar una plantilla en la que se
encuentran métodos para análisis, diseño, codificación, pruebas y mantenimiento. Con todo y
sus errores, sigue siendo el paradigma más utilizado en el desarrollo del software, siendo
mucho mejor que un enfoque al azar.

Características del modelo

 Primer modelo empleado (Royce, 1970), también denominado ciclo de vida clásico y
modelo lineal secuencial.
 Consiste en la ejecución secuencial de una serie de fases que se suceden, lo que da
nombre al modelo.
 Cada fase genera documentación para la siguiente. Esta documentación debe ser
aprobada.
 Una fase no comienza hasta que la anterior ha terminado.
 Requiere disponer de unos requisitos completos y precisos al principio del desarrollo.
 Se disponga de unos requisitos completos y consistentes al principio del desarrollo.
 Sea un proyecto pequeño, en el que el período de congelación de los requisitos es
corto, o un proyecto con unos requisitos bastante estables.

Ventajas:
 Se debe tener en cuenta que fue el primer modelo empleado, y por lo tanto es mejor
que ninguno.
 Facilita la gestión del desarrollo.

Desventajas:
 En general, establecer todos los requisitos al principio del proceso de desarrollo es un
mito inalcanzable, Los usuarios no pueden imaginarse lo que quieren hasta que no ven un
sistema funcionando.
 Los requisitos no se pueden congelar mientras dura el desarrollo. El mercado cambia,
todo cambia.
 El usuario debe esperar mucho tiempo hasta ver los resultados
 Los errores de análisis y diseño son costosos de eliminar, y se propagan a las fases
siguientes con un efecto conocido como bola de nieve.
 Se genera mucho mantenimiento inicial debido al período de congelación de requisitos
y éste recae, en su mayor parte
IMAGEN:http://1.bp.blogspot.com/_dNj9up-_ZvI/TGnDgT_ojHI/AAAAAAAAABQ/h_sRHcp8ioo/s1600/ModeloCascada.jpg

Ejemplos
 Este modelo es ampliamente utilizado en los sistemas gubernamentales de gran
tamaño, en especial en el Departamento de Defensa de los Estados Unidos (DOD).
 Es utilizado en la NASA.

¿Por qué a veces falla el modelo Lineal?

 Los proyectos reales raras veces siguen el modelo secuencial que propone el modelo.
 A menudo es difícil que el cliente exponga explícitamente todos los requerimientos.
 El cliente debe tener paciencia. Un grave error puede ser desastroso
 Cada uno de estos errores es real. Sin embargo el paradigma del ciclo de vida clásico
tiene lugar definido e importante trabajo de la ingeniería del software.

IMAGEN:http://3.bp.blogspot.com/_xX1yHbd4EX4/SgPpnk8z7aI/AAAAAAAAAtM/tMBrmQSKqTk/s320/pensador.jpg

Conclusión

La metodología de cascada ordena rigurosamente las etapas del ciclo del software, es decir en
este modelo se tienen que terminar las fases en un orden, Lo que puedo mencionar es que el
modelo cascada es un modelo que al llevarse a cabo se debe de llevar fase por fase para
poder pasar a la siguiente etapa.

El modelo de cascada es exitoso cuando se tienen bien especificados los requerimientos del
software y se conozcan las herramientas a utilizar, este modelo también nos permite realizar una
organización más fácil de comprender tratando de no mezclar las diferentes fases del modelo y
así nos permite organizar el tipo de proyecto que pretende solucionar es decir donde se conozcan
todos los requisitos especificados durante su ejecución

MODELO DE DESARROLLO RAPIDO DE

APLICACIONES(DRA)
Este es un modelo de proceso de desarrollo del software lineal, secuencias que enfatiza un
ciclo de desarrollo extremadamente corto. El modelo DRA es una adaptación a del modelo
lineal secuencial en el que se logra el desarrollo rápido utilizando un enfoque de construcción
basado en componentes. Si se comprenden bien los requisitos y se limita el ámbito del
proyecto, el proceso DRA permite al equipo de desarrollo crear un sistema completamente
funcional dentro de periodos cortos de tiempo
 GRÁFICO DEL MODELO DRA

IMAGEN: http://1.bp.blogspot.com/_68ePP0Wp3lo/TL4aszGa03I/AAAAAAAAACg/GcG8z5lnOcE/s1600/dra.png

Modelado de Gestión:

El flujo de información entre las funciones de gestión se modela de forma que responda a las
siguientes preguntas: ¿Qué información conduce el proceso de gestión?, ¿Qué información se
genera?, ¿Quién la genera?, ¿A dónde va la información?, ¿Quién la procesa?.

IMAGEN:http://1.bp.blogspot.com/qnXMnHA3vVM/Tr0EIaJf_JI/AAAAAAAAABc/n5R92LeK95w/s1600/Etapas_de_la_gestio
n_del_cambio.jpg
Modelado de Datos:

El flujo de información definido como parte de la fase de modelado de gestión se refina como
un conjunto de objetos de datos necesarios para apoyar la empresa. Se definen las
características (llamadas atributos) de cada uno de los objetos y las relaciones entre estos
objetos.

IMAGEN:http://www.fundacion.telefonica.com/es/que_hacemos/convocatorias/sociedad_informacion/2012/noviembre/img/1
d1f911ab76ccb07e74c6b3756cf1b02.jpg

Modelado de Proceso:

Los objetos de datos definidos en la fase de modelado de datos quedan transformados para
lograr el flujo de información necesario para implementar una función de gestión. Las
descripciones del proceso se crean para añadir, modificar, suprimir o recuperar un objeto de
datos.

IMAGEN: http://us.123rf.com/400wm/400/400/michaeldb/michaeldb1011/michaeldb101100020/8220609-un-genie-de-nerd-
cartoon-programmes-un-systeme-de-gestion-des-processus-de-smart-organigramme.jpg

Generación de Aplicaciones:

El modelo asume la utilización de técnicas de cuarta generación. En lugar de crear software

con lenguajes de programación de tercera generación, el proceso DRA trabaja para volver a
utilizar componentes de programas ya existentes (cuando es posible) o a crear componentes
reutilizables (cuando sea necesario). En todos los casos se utilizan herramientas automáticas
para facilitar la construcción del software.
 Modelos de métodos formales
El modelo de métodos formales acompaña a un conjunto de actividades que conducen a la
especificación matemática del software de computadora. Los métodos formales permiten que un
ingeniero del software especifique, desarrolle y verifique un sistema basado en computadora
aplicando una notación rigurosa y matemática.

La ambigüedad, lo incompleto y la inconsistencia se descubren y se corrigen más fácilmente, no

mediante una revisión a propósito para el caso, sino mediante la aplicación del análisis
matemático. Cuando se utilizan métodos formales durante el diseño, sirven como base para la
verificación de programas y por consiguiente permiten que el ingeniero del software descubra y
corrija errores que no se pudieron detectar de otra manera.

Aunque todavía no hay un enfoque establecido, los modelos de métodos formales ofrecen la
promesa de un software libre de defectos. Sin embargo, se ha hablado de una gran preocupación
sobre su aplicabilidad en un entorno de gestión

Gráfico de los modelos de métodos formales