2.

MODELOS DE PROCESO PRESCRIPTIVO

Un proceso primero que todo define quien hace que, cuando y como lo hace, para alcanzar
objetivos. El éxito de las empresas u organizaciones depende en gran medida de la
definición y seguimiento adecuado de sus procesos. Por ejemplo, si definimos realmente
que es un proceso podemos decir que una empresa dedicada al desarrollo de software
abarca procesos especializados muy complejos que es la creación y administración del
sistema de software.
Un modelo de proceso debe considerar una variedad de aspectos, como el conjunto de
personas, estructuras organizacionales, reglas, políticas, actividades, componentes de
software, metodologías y herramientas utilizadas.
Hay muchos aspectos que definen un proceso, desde su arquitectura, actividades, métodos
y metodologías, estrategias y herramientas para la administración de software. Cada
aspecto para no alargar cada definición lleva al equipo de desarrollo a manejar varios tipos
de estos aspectos para el desarrollo de software. desde su estructura que es el inició para
la creación del software hasta las herramientas utilizadas fundamental para el ciclo de
desarrollo.
Ahora bien, ya tenemos un concepto de proceso, lo que nos lleva a profundizar que hace o
que es un MODELO PRESCRIPTIVO, estos modelos fueron propuestos originalmente para
poner orden en el desarrollo de un sistema o software. Lo que nos indica que antiguamente
un equipo desarrollador presentaba mucho caos a la hora de definir su proceso de
desarrollo. El modelo prescriptivo logra que su proceso vaya bien, pero no por eso mismo
sus resultados se cuidaran de sí mismos, el proceso prescriptivo hay que alimentarlo,
porque, aunque este modelo logra orden en sus desarrollos por algún motivo o
circunstancias el producto que generan siguen al borde del caos, su estructura de ingeniería
que es útil para el equipo desarrollador y que da resultados eficaces, no deja de ser
perfecto.
Todos los modelos del proceso del software pueden incluir las actividades estructurales
generales, pero cada una pone distinto estudio en ellas y define en forma diferente acciones
y tareas de ingeniería de software.

1. MODELO DE CASCADA:
Se le conoce como ciclo básico del software, se usan cuando los problemas que le plantean
son fáciles de entender por lo cual son fácil de solucionar. Describe el orden de las
actividades del modelo, es una secuencia de actividades, en sus inicios este modelo se
orientaba a este proceso que se encaminaba por seguir el progreso de desarrollo de
software hacia puntos de definición bien definidos, a esto se le conoce como checkpoint.
Este modelo original se caracterizaba por no continuar su proceso sin antes terminar cada
actividad en su punto partidario. El modelo se especificaba en terminar la actividad que
empezaba.
Algunas de las creencias del modelo de cascada son que las metas se logran mejor cuando
se tienen puntos de revisión bien preestablecidos y documentados (dividiendo el desarrollo
del software en actividades secuenciales bien definidas), los documentos técnicos son
comprensibles para usuarios y administradores no técnicos, cada detalle de los requisitos
se conoce de antemano antes de desarrollar el software (Dichos detalles son estables
durante el desarrollo) y las pruebas y evaluaciones se realizan de manera eficiente al final
del desarrollo.
El modelo de cascada fue inicialmente bien recibido, dado que las actividades de las etapas
eran razonables y lógicas. Lamentablemente, el modelo no explicaba cómo modificar un
resultado, en especial considerando lo difícil que es definir todos los requisitos de un
sistema desde el inicio y que éstos se mantengan estables y sin cambios durante el
desarrollo. Además, toma demasiado tiempo en obtener resultados, retrasando la
detección de errores hasta el final.
Esa clase de modelo se utiliza más que todo para mantenimiento, y para desarrollo nuevo
que son fácil de comprender. Cuando los requerimientos se comprenden bien este tipo de
modelo enfoca el trabajo desde la comunicación hasta el despliegue en forma lineal.
El modelo de cascada también conocido como Ciclo de vida Clásico, sugiere un enfoque
sistemático que es el conjunto ordenado de normas y procedimientos y secuencial Orden
de una serie de elementos que se suceden unos a otros.
Este método de cascada se representa en 5 etapas.

1.1. Comunicación:
Se hace un listado con el cliente de las necesidades que debe suplir el software de lo que el
cliente necesita, se reúnen, se recoge los requerimientos con el cliente.
1.2. Planeación:
Define y estima como objetivo principal la programación y constante seguimiento del
software a plantear. Se define en tres etapas:
 1.2.1. La estimación: Habla del recurso humano a nivel tecnológico y costos a definir
para la planeación del software.
1.2.2. La programación: Es realizar el debido cronograma del desarrollo en cuanto a la
programación.
1.2.3. Los seguimientos: Son los ajustes que uno debe hacerle a la aplicación, un
cronograma se hace para tener un indicativo que varía en el transcurso del
desarrollo donde se hace más notable realizar estas modificaciones.

1.3. Modelado:
Se realiza el Análisis con los parámetros establecidos y el diseño incremental del software.
1.4. La construcción:
En este nivel se realiza la entrada de códigos por parte del desarrollador y se realizan
pruebas pilotos de lo que se está realizando o simplemente se aplican las pruebas técnicas
requeridas, hay 28 clases de pruebas, dependiendo del software se escoge las clases de
pruebas.
1.5. Despliegue:
Lleva 3 cosas:
1.5.1. La entrega: Es el software o la aplicación que le mandaron a hacer.
1.5.2. Asistencia: Es el tiempo de apoyo limitado (La póliza-cumplimiento).
1.5.3. Retroalimentación: Es el mantenimiento que uno debe hacerle a la aplicación.

Desventajas Modelo Cascada

Este modelo tiene unas desventajas, una de ellas es que lleva muchas restricciones y es
sujeta a cambios relevantes, ejemplo: El cambio de la actualización, toca hacerle cambios al
software. Por x cosas el IVA sube del 16 al 19 hay que cambiar muchas situaciones.
Otra desventaja es que el cliente no dice que es lo que quiere, no queda bien enunciado el
problema y para el equipo desarrollador le es complicado conocer realmente como es el
software requerido.
Una desventaja grande cuando en el equipo hay participantes que no aportan, el software
no se va a cumplir, el analista o gerente debe escoger bien su equipo de trabajo.
Modelo en V:
Una variante de la representación del modelo de la cascada se denomina modelo en V.
Donde se aprecia la relación entre las acciones para el aseguramiento de la calidad y
aquellas asociadas con la comunicación, modelado y construcción temprana. Con este
modelo como variante del modelo clásico de cascada ayuda a que los requerimientos
básicos del problema mejoran hacia representaciones técnicas cada vez más detalladas del
problema y de su solución.
Ventaja se asegura la calidad, este modelo es bueno, cuando se hace la lista de
requerimientos, se analiza de una vez se hacen pruebas, si hace falta algo, se actúa hasta
solucionar sino no continúa con la siguiente fase.
La generación de código, se hacen pruebas unitarias por último es software ejecutable,
entregable como tal.
 2. Modelo de proceso incremental:

Consiste de un desarrollo inicial de la arquitectura completa del sistema, seguida de

incrementos y versiones parciales de éste. Cada incremento tiene su propio ciclo de vida,
típicamente siguiendo el modelo de cascada. Los incrementos pueden construirse de
manera serial o paralela dependiendo de la naturaleza de la dependencia entre versiones y
recursos. Cada incremento agrega funcionalidad adicional o mejorada sobre el sistema.
Conforme se completa cada etapa, se verifica e integra la última versión con las demás
versiones ya completadas del sistema. Durante cada incremento, el sistema se evalúa con
respecto al desarrollo de versiones futuras. Las actividades se dividen en procesos y
subprocesos, dando lugar al término fábrica de software (en inglés, software factory). Para
que la secuencia de desarrollo sea exitosa, es esencial definir etapas que no requieran
cambiar los resultados anteriores al agregar nuevas. Por lo tanto, es importante
comprender al inicio los requisitos completos del sistema, algo que normalmente es muy
difícil de lograr. El desarrollo incremental evita la teoría del “big bang” para el desarrollo de
software, donde una gran explosión de desarrollo se transforma repentinamente en el
sistema final.
Ventaja: El modelo incremental aplica secuencias lineales en forma escalonada a medida
que avanza el calendario de actividades se van haciendo entregas funcionales por pedazos,
al cliente o al usuario que lo va a manejar, esas pruebas funcionales no son 100% optimas,
se hacen entregas posteriores.

3. Modelos de proceso evolutivo

Se extiende al modelo incremental en la que los incrementos se hacen de manera
secuencial o sea por partes, en lugar de en paralelo. Desde el punto de vista del cliente, el
sistema evoluciona según vayan siendo entregados los incrementos. Desde el punto de
vista del desarrollador, los requerimientos que son claros al principio del proyecto dictan
el incremento inicial, mientras que los incrementos para cada uno de los siguientes ciclos
de desarrollo se clarifican a través de la experiencia de los incrementos anteriores. Este
modelo se define en dos modelos internos que son:
3.1. Prototipos:
El modelo evolutivo es también conocido como desarrollo rápido de aplicaciones, que se basa
tradicionalmente en el uso de prototipos, Un prototipo de software se considera como un medio
para especificar los requisitos y un enlace de comunicación entre el usuario final y el diseñador,
ayudando a reducir el riesgo de carecer de requerimientos iniciales completos y estables.
DESVENTAJA: El software se hace caprichosamente por el desarrollador, cada ser humano
piensa diferente, a raíz de eso se hace caprichosamente, cada uno desarrolla a su manera.
En las reglas de juego hay que entregar un prototipo, al entregarlo no se mira que hardware
tiene, cosas que si no hay requerimientos claros el desarrollador hace un prototipo a su
beneficencia.

3.2. Modelo Espiral:

Se hacen versiones rápidas, el modelo espiral se basa en una estrategia para reducir el riesgo del
proyecto en áreas de incertidumbre, como tener requerimientos iniciales incompletos e inestables.

El modelo enfatiza ciclos de trabajo, cada uno de los cuales estudia el riesgo antes de proceder al
siguiente ciclo. Cada ciclo comienza con la identificación de los objetivos, soluciones alternas y
restricciones asociadas con cada alternativa, y finalmente se procede a su evaluación. Cuando se
encuentra que existe cierta incertidumbre, se utilizan diversas técnicas para reducir el riesgo de las
distintas alternativas. Cada ciclo del modelo espiral termina con una revisión que discute los logros
actuales y los planes para el siguiente ciclo

VENTAJAS:
Una de las grandes ventajas que tiene contra otros modelos es que acá se mira el riesgo, y
el riesgo se mira a nivel de fracaso. Se plantea la modulación, el despliegue, comunicación,
mismas etapas trabajan ahí.
Otra ventaja grande es que incorpora una estrategia de uso de prototipos como parte del manejo
del riesgo.

Este modelo considera que el desarrollo de sistemas es un proceso de cambios progresivos

mediante cambios de especificación de requerimientos

4. Modelo Concurrente.
Este modelo se ajusta al ciclo de vida del proceso, donde apoya las diferentes actividades,
donde Involucra varios equipos de trabajo para el desarrollo de un software y se le conoce
como modelo de tipo de red donde las personas actúan simultáneamente y se utiliza para
desarrollos cliente – servidor. “el cliente realiza peticiones de programas y el servidor da
respuesta a estos requerimientos”
CARACTERISTICAS:

 Se puede expresar de manera esquematizada

 Las actividades llevan procesos simultáneos.
 Es aplicable a todo tipo de desarrollo de software
  Es un modelo aplicable para cliente – servidor
 Está dirigido por las necesidades del usuario.

VENTAJAS:

 Excelentes para proyectos en los que se conforman grupos de trabajo

independiente.
 Proporciona la imagen exacta del estado actual de un producto.
 Si no se dan las condiciones adecuadas o señaladas no es aplicable.
 Si no existen grupos de trabajo no se puede trabajar en este método.

5. Modelo de proceso Especializado

Este modelo cobija todas las características de los modelos básicos de la programación,
reúne mismas funcionalidades de los modelos anteriores, dichos modelos tienden a
aplicarse cuando se elige un enfoque de ingeniería de software especializado o definido
muy específicamente
5.1. Desarrollo Basado en Componentes:
Los componentes comerciales de software general desarrollados por vendedores que los
ofrecen como productos, brindan una funcionalidad que se persigue con interfaces bien
definidas que permiten que el componente se integre en el software que se va a construir.
VENTAJAS

 Reutilización del software. Nos lleva a alcanzar un mayor nivel de reutilización de

software.
 Simplifica las pruebas. Permite que las pruebas sean ejecutadas probando cada uno
de los componentes antes de probar el conjunto completo de componentes
ensamblados.
 Simplifica el mantenimiento del sistema. Cuando existe un débil acoplamiento entre
componentes, el desarrollador es libre de actualizar y/o agregar componentes según
sea necesario, sin afectar otras partes del sistema.
 Mayor calidad. Dado que un componente puede ser construido y luego mejorado
continuamente por un experto u organización, la calidad de una aplicación basada
en componentes mejorará con el paso del tiempo.
El modelo de desarrollo basado en componentes incorpora las etapas siguientes:

 Se investigan y evalúan, para el tipo de aplicación de que se trate, productos

disponibles basados en componentes.
 Se consideran los aspectos de integración de los componentes.
  Se diseña una arquitectura del software para que reciba los componentes.
 Se integran los componentes en la arquitectura.
 Se efectúan pruebas exhaustivas para asegurar la funcionalidad apropiada.

6. Modelo de métodos formales

Este modelo se relaciona con las representaciones matemáticas de computo, como su
nombre lo indica este modelo denominado métodos formales se usa para referirse a
cualquier actividad relacionada con representaciones matemáticas del software,
incluyendo la especificación formal de sistemas, análisis y demostración de la
especificación, el desarrollo transformacional y la verificación de programas. Todas estas
actividades dependen de una especificación formal del software.
El modelo de métodos formales agrupa actividades que llevan a la especificación
matemática formal del software de cómputo. Los métodos formales permiten especificar,
desarrollar y verificar un sistema basado en computadora por medio del empleo de una
notación matemática rigurosa.
VENTAJAS

 La comunicación con el cliente mejora ya que se dispone de una descripción clara y

concisa de los requisitos del usuario.
 El sistema se asegura matemáticamente que es correcto según las especificaciones.
 Mayor calidad software respecto al cumplimiento de las especificaciones.
 Mayor productividad

7. Desarrollo a software orientado a objetos

Define un mecanismo que ayuda a resolver problemas complementarios de código disperso
o scattered y código enmarañado o tangled, estos dos códigos los podemos definir como
servicios invocados desde el programa y servicios de acceso desde la operación del
programa.
Provee una unidad modular llamada aspecto y un mecanismo de composición que permite
entremezclar unidades modulares de comportamiento común con otras unidades
modulares básicas del sistema.
Diseñar un sistema basado en aspectos requiere entender qué se debe incluir en el lenguaje
base, qué se debe incluir dentro de los lenguajes de aspectos y qué debe compartirse entre
ambos lenguajes. El lenguaje componente debe proveer la forma de implementar la
funcionalidad básica y asegurar que los programas escritos en ese lenguaje componente no
interfieran con los aspectos.
 BIBLIOGRAFIA.
Pressman, R. 2010. Ingeniería del Software un enfoque Práctico, 7ma. ed. México:Mc
Graw.
Serna, E. 2010. Métodos formales e Ingeniería de Software. “Revista Virtual Universidad
Católica del Norte”. No. 30.
Yépez, S. 2010. Modelo de Orientación a Aspectos. En Linea. Formato PDF.

Conclusiones
Los modelos hacen una mejor funcionalidad de integración del software. Además podemos
decir que esto se inclina más a que la arquitectura del software se acople más a los
componentes.

Que es el modelo, que etapas tiene, donde se implementa, complementar con otros
autores.
Un trabajo con normas para entregar, hacer un folleto
Plegable hacer un Folleto “Que es: ventajas y las fases que tiene.

En la clase de hoy a las 7:00pm, explicaré sobre modelos,

1. Elaborar un trabajo con investigación más profunda sobre cada modelo, del libro
de Roger Pressman, numeral 2.3 y 2.4 con NORMAS ICONTEC (en físico)
2. Se debe diseñar una PLEGABLE explicando qué es, fases que tiene y
ventajas solamente de cada modelo (en físico)
3. ENTREGA MÄXIMA: viernes Marzo 02 de 2018 hora de inicio de la clase
4. Se realizará ese mismo día, un QUIZ sobre los modelos