MODELOS DEL PROCESO DE SOFTWARE

conjunto de actividades y resultados iddliddtftasoc iados que conducen a la

creacin de un producto software

Los modelos de proceso

Un modelo de proceso es un conjunto de actividades, tareas y acciones que se
realizan con el fin de alcanzar el desarrollo completo de un proyecto de
software.
Existen diferentes modelos de proceso tales como los prescriptivos que se
utilizan cuando los requerimientos de software se encuentran bien definidos,
los especializados que incluyen las caractersticas de uno o ms modelos
tradicionales y se utilizan cuando el enfoque del proyecto se encuentra bien
definido
Modelos de procesos prescriptivos
-

Los modelos de proceso prescriptivos denen un conjunto claro de

actividades, acciones, tareas, y productos de trabajo requeridos para
construir software de alta calidad.
se adaptan para alcanzar las necesidades de los ingenieros y gestores
de sw para un proyecto especco.
Porque es importante
porque proporciona estabilidad.control y organizacion a una actividad
que si no se controla puede volverse catica.
1.Modelo prescriptivos

Modelo en Cascada:

algunas veces llamado el ciclo de vida clsico,sugiere un enfoque

sistemtico,secuencial hacia el desarrollo del software,
es el enfoque metodolgico 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 finalizacin de la etapa anterior. [1] Al final de cada etapa, el
modelo est diseado para llevar a cabo una revisin final, que se encarga de
determinar si el proyecto est listo para avanzar a la siguiente fase. Este
modelo fue el primero en originarse y es la base de todos los dems modelos
de ciclo de vida.

Ventajas
Realiza un buen funcionamiento en equipos dbiles y productos maduros, por
lo que se requiere de menos capital y herramientas para hacerlo funcionar de
manera ptima.
Es un modelo fcil de implementar y entender.
Est orientado a documentos.
Es un modelo conocido y utilizado con frecuencia.
Promueve una metodologa de trabajo efectiva: Definir antes que disear,
disear antes que codificar
Desventajas
En la vida real, un proyecto rara vez sigue una secuencia lineal, esto crea una
mala implementacin del modelo, lo cual hace que lo lleve al fracaso.
El proceso de creacin del software tarda mucho tiempo ya que debe pasar por
el proceso de prueba y hasta que el software no est completo no se opera.
Esto es la base para que funcione bien.
Cualquier error de diseo detectado en la etapa de prueba conduce
necesariamente al rediseo y nueva programacin del cdigo afectado,
aumentando los costos del desarrollo.
Una etapa determinada del proyecto no se puede llevar a cabo a menos de que
se haya culminado la etapa anterior.
Modelos de proceso especializados
DESARROLLO BASADO EN COMPONENTES.

el modelo de desarollo basado en componentes incorpora muchas de las

caractersticas del modelo espiral. Es evolutivo por naturaleza y exige un
enfoque interactivo para la creacin del software. El modelo basado en
componente configura aplicaciones desde componentes preparados software.El
modelo de desarrollo basado en componentes conduce a la reutilizacin del
software, y la reutilizacin proporciona beneficios a los ingenieros de
software.Sin importar la tecnologa usada para crear los componentes, el
modelo de desarrollo basado en componentes incorpora las etapas siguientes.
1. Se investigan y evalan, para el tipo de aplicacin de que se trate,
productos disponibles basados en componentes.

2. Se consideran los aspectos de integracin de los componentes.

3. Se disea una
componentes.

arquitectura

del

software

para

que

reciba

los

4. Se integran los componentes en la arquitectura.

5. Se efectan pruebas exhaustivas para asegurar la funcionalidad
apropiada.
El modelo del desarrollo basado en componentes lleva a la reutilizacin del
software, y eso da a los ingenieros de software varios beneficios en cuanto a la
mensurabilidad. Si la reutilizacin de componentes se vuelve parte de la
cultura, el equipo de ingeniera de software tiene la posibilidad
tanto de reducir el ciclo de tiempo del desarrollo como el costo del proyecto.
El modelo de mtodos formales
acompaa a un conjunto de actividades que conducen a la especificacin
matemtica del software de computadora. Los mtodos formales permiten que
un ingeniero del software especifique, desarrolle y verifique un sistema basado
en computadora aplicando una notacin rigurosa y matemtica.
La ambigedad, lo incompleto y la inconsistencia se descubren y se corrigen
ms fcilmente, no mediante una revisin a propsito para el caso, sino
mediante la aplicacin del anlisis matemtico. Cuando se utilizan mtodos
formales durante el diseo, sirven como base para la verificacin de programas
y por consiguiente permiten que el ingeniero del software descubra y corrija
errores que no se pudieron detectar de otra manera.
Aunque el modelo de los mtodos formales no es el ms seguido, promete un
software libre de defectos. Sin embargo, se han expresado preocupaciones
acerca de su aplicabilidad en un ambiente de negocios:

El desarrollo de modelos formales consume mucho tiempo y es caro.

Debido a que pocos desarrolladores de software tienen la formacin

necesaria para aplicar mtodos formales, se requiere mucha
capacitacin.

Es difcil utilizar los modelos como mecanismo de comunicacin para

clientes sin complejidad tcnica.

A pesar de estas preocupaciones, el enfoque de los mtodos formales ha

ganado partidarios entre los desarrolladores que deben construir software de
primera calidad en seguridad.
DESARROLLO DE SOFTWARE ORIENTADO A ASPECTO

Sin importar el proceso del software que se elija, los constructores de software
complejo implementan de manera invariable un conjunto de caractersticas,
funciones y contenido de informacin localizados. Estas caractersticas
localizadas del software se modelan como componentes (clases orientadas a
objetos) y luego se construyen dentro del contexto de una arquitectura de
sistemas. A medida que los sistemas modernos basados en computadora se
hacen ms sofisticados (y complejos), ciertas preocupaciones propiedades
que requiere el cliente o reas de inters tcnico se extienden a toda la
arquitectura. Algunas de ellas son las propiedades de alto nivel de un sistema
(por ejemplo, seguridad y tolerancia a fallas). Otras afectan a funciones
(aplicacin de las reglas de negocios), mientras que otras ms son sistmicas
(sincronizacin de la tarea o administracin de la memoria).
Cuando las preocupaciones afectan mltiples funciones, caractersticas e
informacin del sistema, es frecuente que se les llame preocupaciones
globales. Los requerimientos del aspecto definen aquellas preocupaciones
globales que tienen algn efecto a travs de la arquitectura del software. El
desarrollo de software orientado a aspectos (DSOA), conocido tambin como
programacinorientada a aspectos (POA), es un paradigma de ingeniera de
software relativamente nuevo que proporciona un proceso y enfoque
metodolgico para definir, especificar, disear y construir aspectos:
mecanismos ms all de subrutinas y herencia para localizar la expresin de
una preocupacin global.

El Proceso Software Personal

El PSP se desarroll para ayudar a los ingenieros en software a hacer bien su
trabajo. En ste se ensea al ingeniero a aplicar mtodos avanzados de
ingeniera a sus tareas diarias. Este proceso proporciona mtodos detallados de
planificacin y estimacin donde el ingeniero aprende a tener mayor control
sobre su trabajo con respecto a planes que previamente establece as como le
ayuda a producir productos de calidad, reduciendo su nmero de defectos
inyectados (Humphrey, 1995).
De acuerdo a los principios de planificacin del PSP, para que los ingenieros
sean eficaces deben seguir procesos definidos que sean medibles as como
planificar su trabajo. Por otra parte, los principios de calidad del PSP
promueven que cada ingeniero realice trabajo de calidad. Para alcanzar esta
calidad los ingenieros son responsables de la calidad de los productos que

producen, previniendo defectos y haciendo su trabajo de manera correcta

(Nichols y Salazar, 2009). Estas mejoras se logran a travs de la introduccin
gradual de nuevos elementos o versiones a la lnea base del proceso software
personal (Abrahamsson y Kautz, 2002b). La progresin de las distintas
versiones del PSP se muestra en la Figura 1

Proceso Del Equipo Del Software (PES)

El objetivo de este es construir un equipo "autodirigido" para el proyecto,
que se organiza para producir software de alta calidad Humphrey define
los objetivos siguientes:
-Formar equipos autodirigidos que planeen y den seguimiento a su
trabajo.
-Mostrar a los gerentes como dirigir y motivar a sus equipos y como
ayudarlos a mantener un rendimiento mximo.
-Acelerar la mejora del proceso del software.
-Brindar a los organizaciones muy maduras una guia para la mejora.
-Facilitar la enseanza universitaria de aptitudes de equipo con grado
industrial.
El PES define las siguientes actividades estructurales : Inicio del
proyecto, Diseo de alto nivel, implementacin, integracin y pruebas, y
post mortem. Como sus contra partes del PPS, estas actividades
permiten que el equipo planee, disee y construya software en forma
disciplinada.
Ventajas:
-La idea que ganamos en talento y habilidad
-La estimulacion por nuevas ideas
-Una estructura de trabajo de mejoramiento personal.

Tecnologas De Proceso Las herramientas de tecnologa de procesos

permiten que una organizacin de software construya un modelo
automatizado del marco de trabajo comn deproceso, conjuntos de
tareas y actividades de proteccin. La herramienta de tecnologa de
proceso tambin se puede utilizar para coordinar el uso de otras
herramientas de ingeniera del software asistida por computadora
adecuadas para una tarea de trabajo en particular.
Otros
Modelos de proceso en espiral
Las actividades de este modelo se conforman en una espiral, en la que
cada bucle o iteracin representa un conjunto de actividades. Las
actividades no estn fijadas a ninguna prioridad, sino que las siguientes
se eligen en funcin del anlisis de riesgo, comenzando por el bucle
interior.

Determinar o fijar objetivos[editar]

Fijar tambin los productos definidos a obtener: requisitos,

especificacin, manual de usuario.

Fijar las restricciones.

Identificacin de riesgos del proyecto y estrategias alternativas para

evitarlos.

Hay una cosa que solo se hace una vez: planificacin inicial.

Desarrollar, verificar y validar(probar)[editar]

Tareas de la actividad propia y de prueba.

Anlisis de alternativas e identificacin resolucin de riesgos.

Dependiendo del resultado de la evaluacin de los riesgos, se elige un

modelo para el desarrollo, el que puede ser cualquiera de los otros
existentes, como formal, evolutivo, cascada, etc. As si por ejemplo si los

riesgos en la interfaz de usuario son dominantes, un modelo de

desarrollo apropiado podra ser la construccin de prototipos evolutivos.
Si lo riesgos de proteccin son la principal consideracin, un desarrollo
basado en transformaciones formales podra ser el ms apropiado.
Anlisis del riesgo[editar

Se lleva a cabo el estudio de las causas de las posibles amenazas y

probables eventos no deseados y los daos y consecuencias que stas
puedan producir. Se evalan alternativas. Se debe tener un prototipo
antes de comenzar a desarrollar y probar
Ventajas

Reduce riesgos del proyecto

Incorpora objetivos de calidad

Integra el desarrollo con el mantenimiento, etc

Desventajas

Genera mucho tiempo en el desarrollo del sistema

Modelo costoso

Requiere experiencia en la identificacin de riesgos