Un proceso para el desarrollo de software, tambin denominado ciclo de vida del

desarrollo de software es una estructura aplicada al desarrollo de un producto de software.

Hay varios modelos a seguir para el establecimiento de un proceso para el desarrollo de
software, cada uno de los cuales describe un enfoque diferente para diferentes actividades
que tienen lugar durante el proceso. Algunos autores consideran un modelo de ciclo de vida
un trmino ms general que un determinado proceso para el desarrollo de software. Por
ejemplo, hay varios procesos de desarrollo de software especficos que se ajustan a un
modelo de ciclo de vida de espiral.
La gran cantidad de organizaciones de desarrollo de software implementan metodologas
para el proceso de desarrollo. Muchas de estas organizaciones pertenecen a la industria
armamentstica, que en los Estados Unidos necesita un certificado basado en su modelo de
procesos para poder obtener un contrato.
El estndar internacional que regula el mtodo de seleccin, implementacin y monitoreo
del ciclo de vida del software es ISO 12207.
Durante dcadas se ha perseguido la meta de encontrar procesos reproducibles y
predecibles que mejoren la productividad y la calidad. Algunas de estas soluciones intentan
sistematizar o formalizar la aparentemente desorganizada tarea de desarrollar software.
Otros aplican tcnicas de gestin de proyectos para la creacin del software. Sin una
gestin del proyecto, los proyectos de software corren el riesgo de demorarse o consumir
un presupuesto mayor que el planeado. Dada la cantidad de proyectos de software que no
cumplen sus metas en trminos de funcionalidad, costes o tiempo de entrega, una gestin de
proyectos efectiva es algo que a menudo falta.
Algunas organizaciones crean un grupo propio (Software Engineering Process Group,
abreviado SEPG) encargado de mejorar los procesos para el desarrollo de software en la
organizacin.

Actividades del desarrollo de software

Planificacin
La importante tarea a la hora de crear un producto de software es obtener los requisitos o
el anlisis de los requisitos. Los clientes suelen tener una idea ms bien abstracta del
resultado final, pero no sobre las funciones que debera cumplir el software.
Una vez que se hayan recopilado los requisitos del cliente, se debe realizar un anlisis del
mbito del desarrollo. Este documento se conoce como especificacin funcional.

Implementacin, pruebas y documentacin

La implementacin es parte del proceso en el que los ingenieros de software programan el
cdigo para el proyecto.
Las pruebas de software son parte esencial del proceso de desarrollo del software. Esta
parte del proceso tiene la funcin de detectar los errores de software lo antes posible.

La documentacin del diseo interno del software con el objetivo de facilitar su mejora y su
mantenimiento se realiza a lo largo del proyecto. Esto puede incluir la documentacin de
un API, tanto interior como exterior.

Despliegue y mantenimiento
El despliegue comienza cuando el cdigo ha sido suficientemente probado, ha sido
aprobado para su liberacin y ha sido distribuido en el entorno de produccin.
Entrenamiento y soporte para el software es de suma importancia y algo que muchos
desarrolladores de software descuidan. Los usuarios, por naturaleza, se oponen al cambio
porque conlleva una cierta inseguridad, es por ello que es fundamental instruir de forma
adecuada a los futuros usuarios del software.
El mantenimiento o mejora del software de un software con problemas recientemente
desplegado, puede requerir ms tiempo que el desarrollo inicial del software. Es posible
que haya que incorporar cdigo que no se ajusta al diseo original con el objetivo de
solucionar un problema o ampliar la funcionalidad para un cliente. Si los costes de
mantenimiento son muy elevados puede que sea oportuno redisear el sistema para poder
contener los costes de mantenimiento.
Modelos de Desarrollo de Software
Los modelos de desarrollo de software son una representacin abstracta de una manera en
particular. Realmente no representa cmo se debe desarrollar el software, sino de un
enfoque comn. Puede ser modificado y adaptado de acuerdo a las necesidades del software
en proceso de desarrollo. 1 Hay varios modelos para perfilar el proceso de desarrollo, cada
uno de las cuales cuenta con pros y contras. El proyecto debera escoger el ms apropiado
para sus necesidades. En ocasiones puede que una combinacin de varios modelos sea
apropiado. Existen tres paradigmas de los modelos de desarrollo de software:
1. Paradigma Tradicional:
Es uno de los paradigmas ms antiguo, se invent durante la creacin del mtodo
estructurado. Si se elige un proyecto, el mtodo varia en etapas.2 Como todo modelo,
existen sus pros y contras al usar este paradigmas:

Si se aplica este paradigma, unos de los principales problemas , es que las etapas realizadas
no son autnomas de las siguientes, creando una dependencia estructural y en el acaso de
un error atrasara todo el proyecto. Se tiene que tener pautas bien definidas, y que no se
incurra a modificacin porque implicara en que el software no cumpla con su ciclo de vida.
Tener en cuenta que el cliente no se vea afectado por la impaciencia.3
2. Paradigma Orientado a Objetos: Estos modelos se basan en la Programacin orientada a
objetos; por lo tanto, se refiere al concepto de clase, el anlisis de requisitos y el diseo. El
modelo o paradigma orientado a objetos posee dos caractersticas principales, las cuales
son:

Permite la re-utilizacin de software.

Facilita el desarrollo de herramientas informticas de apoyo al desarrollo, el cual es

simple al implementarla en una notacin orientado a objetos llamado UML.4

3. Paradigma de Desarrollo gil: Es un paradigma de las Metodologas De

Desarrollo basado en procesos giles. Estos intentan evitar los tediosos caminos de las
metodologas tradicionales enfocndose en las personas y los resultados. Usa un enfoque
basado en el Valor para construir software, colaborando con el cliente e incorporando los
cambios continuamente.5

Modelo de cascada
El modelo de cascada define las siguientes etapas que deben cumplirse de forma sucesiva:
1. Especificacin de requisitos
2. Diseo del software
3. Construccin o Implementacin del software
4. Integracin

5. Pruebas (o validacin)
6. Despliegue (o instalacin)
7. Mantenimiento
Siguiendo el modelo de cascada de forma estricta, slo cuando se finaliza una fase,
comienza la otra. En ocasiones se realiza una revisin antes de iniciar la siguiente fase, lo
que permite la posibilidad de cambios (lo que puede incluir un proceso de control formal de
cambio). Las revisiones tambin se utilizan para asegurar que la fase anterior ha sido
totalmente finalizada; los criterios para completar una fase se conocen frecuentemente con
el trmino ingls "gate" (puerta). Este modelo desaconseja revisitar y revisar fases que ya
se han completado. Esta falta de flexibilidad en un modelo de cascada puro ha sido fuente
de crtica de los defensores de modelos ms flexibles.

Modelo de espiral
La principal caractersticas del modelo en espiral es la gestin de riesgos de forma
peridica en el ciclo de desarrollo. Este modelo fue creado en 1988 por Barry Boehm,
combinando algunos aspectos clave de las metodologas del modelo de cascada y
del desarrollo rpido de aplicaciones, pero dando nfasis en un rea que para muchos no
jug el papel que requiere en otros modelos: un anlisis iterativo y concienzudo de los
riesgos, especialmente en el caso de sistema complejos de gran escala.
La espiral se visualiza como un proceso que pasa a travs de algunas interaciones con el
diagrama de los cuatro cuadrantes representativos de las siguientes actividades:
crear planes con el propsito de identificar los objetivos del software, seleccionados para
implementar el programa y clarificar las restricciones en el desarrollo del software;
Anlisis de riesgos: una evaluacin analtica de programas seleccionados, para evaluar
como identificar y eliminar el riesgo;
la implementacin del proyecto: implementacin del desarrollo del software y su pertinente
verificacin;
Modelo de espiral con nfasis en los riesgos, haciendo hincapi en las condiciones de las
opciones y limitaciones para facilitar la reutilizacin de software, la calidad del software
puede ayudar como una meta propia en la integracin en el desarrollo del producto. Sin
embargo, el modelo en espiral tiene algunas limitaciones, entre las que destacan:
El nfasis se sita en el anlisis de riesgo, y por lo tanto requiere de clientes que acepten
este anlisis y acten en consecuencia. Para ello es necesaria confianza en los
desarrolladores as como la predisposicin a gastar ms para solventar los temas, por lo
cual este modelo se utiliza frecuentemente en desarrollo interno de software a gran escala.
Si la implementacin del riesgo de anlisis afectar de forma esencial los beneficios del
proyecto, no debera utilizarse este modelo.
Los desarrolladores de software han de buscar de forma explcita riesgos y analizarlos de
forma exhaustiva para que este modelo funcione.

La primera fase es la bsqueda de un plan para conseguir los objetivos con las limitaciones
del proyecto para as buscar y eliminar todos los riesgos potenciales por medio de un
cuidadoso anlisis, y si fuera necesario incluyendo la fabricacin de un prototipo. Si es
imposible descartar algunos riesgos, el cliente ha de decidir si es conveniente terminar el
proyecto o seguir adelante ignorando los riesgos. Por ltimo, se evalan los resultados y se
inicia el diseo de la siguiente fase.

Desarrollo iterativo e incremental

El desarrollo iterativo recomienda la construccin de secciones reducidas de software que
irn ganando en tamao para facilitar as la deteccin de problemas de importancia antes de
que sea demasiado tarde. Los procesos iterativos pueden ayudar a desvelar metas del diseo
en el caso de clientes que no saben cmo definir lo que quieren.6

Desarrollo gil
El desarrollo gil de software utiliza un desarrollo iterativo como base para abogar por un
punto de vista ms ligero y ms centrado en las personas que en el caso de las soluciones
tradicionales. Los procesos giles utilizan retroalimentacin en lugar de planificacin,
como principal mecanismo de control. La retroalimentacin se canaliza por medio de
pruebas peridicas y frecuentes versiones del software.
Hay muchas variantes de los procesos giles:
En el caso de la programacin extrema (XP), las fases se realizan en pasos muy cortos (o
"continuos") con respecto al anterior. El primer paso (intencionalmente incompleto) por los
pasos puede ocurrir en un da o en una semana, en lugar de los meses o aos de cada paso
completo en el modelo en cascada. En primer lugar, se crean pruebas automatizadas para
proveer metas concretas al desarrollo. Despus se programa el cdigo, que ser completo
cuando todas las pruebas se superan sin errores, y los desarrolladores ya no sabran como
mejorar el conjunto de pruebas necesario. El diseo y la arquitectura emergen a partir de
la refactorizacin del cdigo, y se da despus de programar. El diseo lo realizan los
propios desarrolladores del cdigo. El sistema, incompleto, pero funcional se despliega para
su demostracin a los usuarios (al menos uno de los cuales pertenece al equipo de
desarrollo). Llegado este punto, los profesionales comienzan a escribir las pruebas para la
siguiente parte del sistema de ms importancia.

Codificacin y correccin
El desarrollo de codificacin y correccin (en ingls "Code and fix") es, ms que una
estrategia predeterminada, el resultado de una falta de experiencia o presin que se ejerce
sobre los desarrolladores para cumplir con una fecha de entrega.7 Sin dedicar tiempo de
forma explcita para el diseo, los programadores comienzan de forma inmediata a
producircdigo. Antes o despus comienza la fase de pruebas de software (a menudo de
forma tarda) y los inevitables errores que se encuentran han de eliminarse antes de poder
entregar el software.

Orientado a la Reutilizacin
La reutilizacin de software es un proceso donde se recurre al uso de activos de software en
las especificaciones de anlisis, diseos, implementacin y pruebas de una aplicacin o
sistemas de software.8

La reutilizacin tiene ciertos Indicadores por ejemplo:

1. Entre el 40% y 60% de una aplicacin es reutilizable en otra.
2. Aproximadamente el 60% de una aplicacin administrativa es reutilizable.
3. Aproximademente el 75% de las funciones son comunes a ms de un programa.
4. Solo el 15% del cdigo encontrado en muchos sistemas es unico y novedoso a una
aplicacin especifica.
El rango general de uso recurrente esta entre el 15% y 85%.9
La reutilizacin tiene Principios como la existencia de parecidos en distintos sistemas de un
mismo dominio, donde el software puede representarse como una combinacin de mdulos
y los sistemas nuevos se puede caracterizar por diferencias respecto a los antiguos
sistemas.10