mhjhjkj,n m

1. Unidad 3 Los modelos de procesos de software
Los modelos de procesos de software
Para resolver los problemas reales de una industria, un ingeniero del software debe incorporar una
estrategia de desarrollo que acompañe al proceso, métodos y tenga herramientas. Esta estrategia se
llama modelo de proceso o paradigma de ingeniería del software. Se selecciona un modelo de
proceso para la ingeniería del software según la naturaleza del proyecto y de la aplicación, los
métodos y las herramientas a utilizarse, los controles y entregas que se requieren.
Cada modelo es una descripción de un proceso software que se presenta desde una perspectiva
particular. Alternativamente, a veces se usan los términos ciclo de vida y Modelo de ciclo de vida.
Cada modelo describe una sucesión de fases y un encadenamiento entre ellas así como un bucle de
resoluciones de problemas y estos se encuentran en distintas etapas. Según las fases y el modo en
que se produzca este encadenamiento, tenemos diferentes modelos de proceso. Un modelo es más
adecuado que otro para desarrollar un proyecto dependiendo de un conjunto de características de
éste. Existe una gran variedad de modelos diferentes entre los que tenemos los que se describen a
continuación.
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:
 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.

2.  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.
 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.
 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.
 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.
 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
 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:

3.  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.
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).
Modelo Incremental
El proceso se divide en 4 partes: Análisis, Diseño, Código y Prueba. Sin embargo, para la
producción del Software, se usa el principio de trabajo en cadena o “Pipeline”, utilizado en muchas
otras formas de programación. Con esto se mantiene al cliente en constante contacto con los
resultados obtenidos en cada incremento.Es el mismo cliente el que incluye o desecha elementos al
final de cada incremento a fin de que el software se adapte mejor a sus necesidades reales. El proceso
se repite hasta que se elabore el producto completo.
De esta forma el tiempo de entrega se reduce considerablemente.
Al igual que los otros métodos de modelado, el Modelo Incremental es de naturaleza interactiva
pero se diferencia de aquellos en que al final de cada incremento se entrega un producto
completamente operacional.
El Modelo Incremental es particularmente útil cuando no se cuenta con una dotación de personal
suficiente. Los primeros pasos los pueden realizar un grupo reducido de personas y en cada
incremento se añadir• personal, de ser necesario. Por otro lado los incrementos se pueden planear

4. para gestionar riesgos técnicos.
El Modelo Incremental se puede ver aquí en forma grafica:
 Se evitan proyectos largos y se entrega algo de valor a los usuarios con cierta frecuencia.
 El usuario se involucra más.
 Difícil de evaluar el coste total.
 Difícil de aplicar a los sistemas transaccionales que tienden a ser integrados y a operar como
un todo.
 Requiere gestores experimentados.
 Los errores en los requisitos se detectan tarde.
 El resultado puede ser muy positivo.
El modelo proporciona todas las ventajas del modelo en cascada realimentado, reduciendo sus
desventajas sólo al ámbito de cada incremento.
 · Permite entregar al cliente un producto más rápido en comparación del modelo de cascada.
 · Resulta más sencillo acomodar cambios al acotar el tamaño de los incrementos.
 · Por su versatilidad requiere de una planeación cuidadosa tanto a nivel administrativo
como técnico.
Desventajas:
 El modelo Incremental no es recomendable para casos de sistemas de tiempo real, de alto
nivel de seguridad, de procesamiento distribuido, y/o de alto índice de riesgos.
 Requiere de mucha planeación, tanto administrativa como técnica.
 Requiere de metas claras para conocer el estado del proyecto.
El Proceso Unificado de Desarrollo de Software (RUP)
El Proceso Unificado es un proceso de software genérico que puede ser utilizado para una gran
cantidad de tipos de sistemas de software, para diferentes áreas de aplicación, diferentes tipos de

5. organizaciones, diferentes niveles de competencia y diferentes tamaños de proyectos.
Provee un enfoque disciplinado en la asignación de tareas y resposabilidades dentro de una
organización de desarrollo. Su meta es asegurar la producción de software de muy alta calidad que
satisfaga las necesidades de los usuarios finales, dentro de un calendario y presupuesto predecible.
El Proceso Unificado tiene dos dimensiones :
 Un eje horizontal que representa el tiempo y muestra los aspectos del ciclo de vida del
proceso a lo largo de su desenvolvimiento
 Un eje vertical que representa las disciplinas, las cuales agrupan actividades de una manera
lógica de acuerdo a su naturaleza.
 La primera dimensión representa el aspecto dinámico del proceso conforme se va
desarrollando, se expresa en términos de fases, iteraciones e hitos (milestones).
 La segunda dimensión representa el aspecto estático del proceso: cómo es descrito en
términos de componentes del proceso, disciplinas, actividades, flujos de trabajo, artefactos y roles.
El Proceso Unificado se basa en componentes (component-based), lo que significa que el sistema en
construcción está hecho de componentes de software interconectados por medio de interfaces bien
definidas (well-defined interfaces).El Proceso Unificado usa el Lenguaje de Modelado Unificado
(UML) en la preparación de todos los planos del sistema. De hecho, UML es una parte integral del
Proceso Unificado, fueron desarrollados a la par.
El Proceso Unificado es dirigido por casos de uso.
Un sistema de software se crea para servir a sus usuarios. Por lo tanto, para construir un sistema
exitoso se debe conocer qué es lo que quieren y necesitan los usuarios prospectos. El término usuario
se refiere no solamente a los usuarios humanos, sino a otros sistemas. En este contexto, el término
usuario representa algo o alguien que interactúa con el sistema por desarrollar.
Un caso de uso es una pieza en la funcionalidad del sistema que le da al usuario un resultado de
valor. Los casos de uso capturan los requerimientos funcionales. Todos los casos de uso juntos
constituyen el modelo de casos de uso el cual describe la funcionalidad completa del sistema. Este
modelo reemplaza la tradicional especificación funcional del sistema. Una especificación funcional
tradicional se concentra en responder la pregunta: ¿Qué se supone que el sistema debe hacer? La
estrategia de casos de uso puede ser definida agregando tres palabras al final de la pregunta: ¿por
cada usuario? Estas tres palabras tienen una implicación importante, nos fuerzan a pensar en

6. términos del valor a los usuarios y no solamente en términos de las funciones que sería bueno que
tuviera. Sin embargo, los casos de uso no son solamente una herramienta para especificar los
requerimientos del sistema, también dirigen su diseño, implementación y pruebas, esto es, dirigen
el proceso de desarrollo.
Aún y cuando los casos de uso dirigen el proceso, no son elegidos de manera aislada. Son
desarrollados a la par con la arquitectura del sistema, esto es, los casos de uso dirigen la arquitectura
del sistema y la arquitectura del sistema influencia la elección de los casos de uso. Por lo tanto, al
arquitectura del sistema y los casos de uso maduran conforme avanza el ciclo de vida.
Proceso de Software Personal
Proceso de Software Personal. Se puede considerar como la guía de trabajo personal para ingenieros
de software en organizaciones que emplean un modelo CMMI con nivel de madurez o de capacidad
de procesos que implica la medición cualitativa y mejora de procesos. El Personal Software Process,
conocido por sus siglas como PSP, es una metodología de reciente creación, proveniente del Instituto
de Ingeniería del Software(SEI). PSP es una alternativa dirigida a los ingenieros de sistemas, que les
permite mejorar la forma en la que construyen software. Considerando aspectos como la
planeación, calidad, estimación de costos y productividad, PSP es una metodología que vale la pena
revisar cuando el ingeniero de software está interesado en aumentar la calidad de los productos de
software que desarrolla dentro de un contexto de trabajo individual.
En PSP todas las tareas y actividades que el ingeniero de software debe realizar durante el proceso
de desarrollo de un producto de software, están puntualmente definidas en un conjunto de
documentos conocidos como scripts. Los scripts son el punto medular de PSP, por lo que se hace
mucho énfasis en que deben ser seguidos en forma disciplinada, ya que de ello dependerá el éxito
de la mejora que se busca. Gran parte de las tareas y actividades definidas en los scripts generará
en su realización un conjunto de datos, fundamentalmente de carácter estadístico. La aplicación de
PSP en varios procesos de desarrollo, y el análisis de la información estadística generada en cada
uno de éstos, permitirán al ingeniero de software identificar, tanto sus fortalezas como sus

7. debilidades, y crecer a través de un proceso de autoaprendizaje y auto mejora.
La calidad en PSP, es un aspecto fuertemente relacionado con la cantidad de defectos que el producto
de software contiene.
En este nivel se introducen algunos métodos aplicables al proceso de desarrollo de software, dentro
de un enfoque de proyectos a gran escala, pero sin lidiar con problemas de comunicación y
coordinación de los equipos de trabajo.
ventajas y desventajas
 PSP es una alternativa, de las muchas que han surgido recientemente, para mejorar el
proceso de desarrollo de software. Más que clasificar un conjunto de sentencias como ventajas o
desventajas, a continuación se citan algunas características:
 PSP es una metodología basada en estimación. La estimación permite saber cuándo y cómo
se desarrollan las tareas de un proceso, por lo que podría citarse como un aspecto importante de
esta metodología el estar basada en métricas y estimaciones.
 La información de las métricas y estimaciones se utiliza para evaluar y mejorar procesos
futuros. PSP parte de la premisa que, si el ingeniero de software conoce sus fortalezas y debilidades,
puede establecer las acciones necesarias para erradicar o explotar los aspectos identificados en la
forma en que desarrolla software.Aunque lo mencionado en el punto anterior podría sonar bastante
atractivo, la forma de llegar a ese auto conocimiento puede resultar tediosa y, en el peor de los casos,
una pesadilla para el desarrollador. Salvo muy pocas excepciones, los ingenieros de software nunca
realizan procedimientos formales para conocer la forma en que trabajan, no saben con exactitud
cuántas líneas de código generan por hora, cuánto tiempo invierten al corregir un error, cuánto
tiempo invierten en pruebas, etcétera.
 Los pasos de registro de información a detalle en el nivel de medición pueden resultar
frustrantes cuando se tiene presión de tiempo.
 Aún no existe una herramienta automatizada que facilite el registro y análisis de datos
generados por la aplicación de PSP.
Conclusion:
En este temas comprendi y apendi a como poder implementar un método adecuado para el
desarrollo de un software. Ya que el desarrollo del software al igual que la codificación es muy
importante ya que conello podremos seguir de manera adecuada el procesó de su desarrollo.

8. Publicado por andhy h palma en 11:29