ESCUELA SUPERIOR POLITÉCNICA
AGROPECUARIA DE MANABÍ
MANUEL FÉLIX LÓPEZ
CARRERA INFORMÁTICA
SEMESTRE SÉPTIMO PERIODO ABR 2015/SEP 2015
TEMA:
MODELOS DE PROCESOS PRESCRIPTIVO
MATERIA:
INGENIERÍA DE SOFTWARE
AUTOR:
CARLOS A. ZAMBRANO VIDAL
FACILITADORA:
ING. HIRAIDA SANTANA
CALCETA, ABRIL 2015
INTRODUCCIÓN
Para cualquier suceso en cualquier ámbito siempre se debe de tener un
conjunto de actividades que ayuden a que el trabajo sea más eficiente de esta
manera se trabaja con los modelos de proceso prescriptivos con su conjunto de
tareas, actividades que ayudan a que se obtenga un software de buena calidad, además
solucionen los casos del desarrollo del software y de esta manera complaciendo
a las personas que lo usaran.
MARCO
MODELOS DE PROCESOS
PRESCRIPTIVO
MODELO DE CASCADA
El modelo
de la cascada, a veces llamado ciclo
de vida clásico, es el enfoque metodológico que ordena rigurosamente las
etapas del proceso
para el desarrollo de software, de tal forma que el inicio de cada etapa
debe esperar a la finalización de la etapa anterior. 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.
El modelo de la cascada es el paradigma más
antiguo de la ingeniería de software. Sin embargo, en las últimas tres décadas,
las críticas hechas al modelo han ocasionado que incluso sus defensores más
obstinados cuestionen su eficacia. Entre los problemas que en ocasiones surgen
al aplicar el modelo de la cascada se encuentran los siguientes:
1.
Es raro que los proyectos reales sigan el flujo secuencial propuesto por
el modelo. Aunque el modelo lineal acepta repeticiones, lo hace en forma
indirecta. Como resultado, los cambios generan confusión conforme el equipo del
proyecto avanza.
2.
A menudo, es difícil para el cliente enunciar en forma explícita todos
los requerimientos. El modelo de la cascada necesita que se haga y tiene
dificultades para aceptar la incertidumbre natural que existe al principio de
muchos proyectos.
3.
El cliente debe tener paciencia. No se dispondrá de una versión
funcional del (de los) programa(s) hasta que el proyecto esté muy avanzado. Un
error grande sería desastroso si se detectara hasta revisar el programa en
funcionamiento.
En un análisis interesante de proyectos
reales, la naturaleza lineal del ciclo de vida clásico llega a “estados de bloqueo”
en los que ciertos miembros del equipo de proyecto deben esperar a otros a fin
de terminar tareas interdependientes. En realidad, ¡el tiempo de espera llega a
superar al dedicado al trabajo productivo! Los estados de bloqueo tienden a
ocurrir más al principio y al final de un proceso secuencial lineal.
Hoy en
día, el trabajo de software es acelerado y está sujeto a una corriente sin fin
de cambios (en las características, funciones y contenido de información). El
modelo de la cascada suele ser inapropiado para ese tipo de labor. No obstante,
sirve como un modelo de proceso útil en situaciones en las que los
requerimientos son fijos y el trabajo avanza en forma lineal hacia el final.
MODELO DE PROCESO
INCREMENTAL
El modelo incremental aplica secuencias
lineales en forma escalonada a medida que avanza el calendario de actividades.
Cada secuencia lineal produce “incrementos” de software susceptibles de
entregarse de manera parecida a los incrementos producidos en un flujo de proceso
evolutivo.
La idea principal detrás de mejoramiento
iterativo es desarrollar un sistema de programas de manera incremental,
permitiéndole al desarrollador sacar ventaja de lo que se ha aprendido a lo
largo del desarrollo anterior, incrementando, versiones entregables del
sistema. El aprendizaje viene de dos vertientes: el desarrollo del sistema, y
su uso (mientras sea posible). Los pasos claves en el proceso son comenzar con
una implementación simple de los requerimientos del sistema, e iterativamente mejorar
la secuencia evolutiva de versiones hasta que el sistema completo esté
implementado. En cada iteración, se realizan cambios en el diseño y se agregan
nuevas funcionalidades y capacidades al sistema.
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.
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.
El modelo de proceso incremental se centra en
que en cada incremento se entrega un producto que ya opera. Los primeros
incrementos son versiones desnudas del producto final, pero proporcionan
capacidad que sirve al usuario y también le dan una plataforma de evaluación.
El
desarrollo incremental es útil en particular cuando no se dispone de personal
para la implementación completa del proyecto en el plazo establecido por el negocio.
Los primeros incrementos se desarrollan con pocos trabajadores. Si el producto
básico es bien recibido, entonces se agrega más personal (si se requiere) para
que labore en el siguiente incremento. Además, los incrementos se planean para
administrar riesgos técnicos. Por ejemplo, un sistema grande tal vez requiera
que se disponga de hardware nuevo que se encuentre en desarrollo y cuya fecha de
entrega sea incierta. En este caso, tal vez sea posible planear los primeros
incrementos de forma que eviten el uso de dicho hardware, y así proporcionar una
funcionalidad parcial a los usuarios finales sin un retraso importante.
MODELO DE PROCESO
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.
Los modelos evolutivos son iterativos. Se
caracterizan por la manera en la que permiten desarrollar versiones cada vez
más completas del software. En los párrafos que siguen se presentan dos modelos
comunes de proceso evolutivo.
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.
Aunque es posible hacer prototipos como un
modelo de proceso aislado, es más común usarlo como una técnica que puede
implementarse en el contexto de cualquiera de los modelos.
MODELO PROCESO 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. Describe el
modelo del modo siguiente:
El modelo de desarrollo espiral es un
generador de modelo de proceso impulsado
por el riesgo, que se usa para
guiar la ingeniería concurrente con participantes múltiples de sistemas
intensivos en software.
Tiene dos características distintivas
principales. La primera es el enfoque cíclico
para el crecimiento incremental del grado de definición de un sistema y
su implementación, mientras que disminuye su grado de riesgo. La otra es un
conjunto de puntos de referencia de
anclaje puntual para asegurar el compromiso del participante con
soluciones factibles y mutuamente satisfactorias.
Con el empleo del modelo espiral, el software
se desarrolla en una serie de entregas evolutivas.
Durante las primeras iteraciones, lo que se
entrega puede ser un modelo o prototipo. En las iteraciones posteriores se
producen versiones cada vez más completas del sistema cuya ingeniería se está
haciendo.
Un modelo en espiral es dividido por el
equipo de software en un conjunto de actividades estructurales. Para fines
ilustrativos, se utilizan las actividades estructurales generales ya analizadas.
PROCESO MODELO
CONCURRENTE
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. Es un modelo de tipo de red donde todas las personas actúan
simultáneamente o al mismo tiempo 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
El modelo de desarrollo concurrente se
utiliza a menudo como el paradigma de desarrollo de aplicaciones
cliente/servidor. Un sistema cliente/servidor se compone de un conjunto de componente
funcional.
CONCLUSIONES
Cada uno de estos modelos ayuda a que un software sea de calidad ya que
cumplen con los diferentes requisitos en un orden jerárquico y específico.
El modelo de cascada es uno de los modelos más utilizado pero para
proyectos pequeños porque tiene una desventaja que es que hay que esperar que
se finalice una actividad para empezar con la otra y tomar en cuenta que si no
se toman bien los requerimientos hay que empezar de nuevo y además el cliente
deberá tener mucha paciencia porque el solo vera el software al final. El
modelo incremental va a comienza con una implementación de los requerimientos del sistema, y va
a mejorar secuencialmente hasta que sistema completo esté implementado. En cada
iteración, se harán cambios en el diseño y se agregan nuevas funcionalidades y
capacidades al sistema. Modelo evolutivo en cada negocio
se realizaran cambios y se implementan nuevas ideas de parte del cliente es por
esto que este modelo ayuda de una manera en la que permiten desarrollar versiones
cada vez más completas del software. Modelo espiral es cíclico y de esta manera
colabora con el crecimiento incremental a medida que el sistema y su
implementación disminuyen su grado de riesgo. Modelo concurrente este modelo es de tipo de
red donde todas las personas actúan al mismo tiempo en el desarrollo del
software.
BIBLIOGRAFÍA
Pressman,
R. 2010. INGENIERÍA DEL SOFTWARE. Un enfoque práctico. Séptima edición.
