El 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.

Modelos de Desarrollo de Software[editar]

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 paradigma:
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[editar]
Artculo principal: Desarrollo en 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[editar]
Artculo principal: Desarrollo en espiral

La principal caracterstica 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:

1. 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;
 2. Anlisis de riesgos: una evaluacin analtica de programas seleccionados, para
evaluar como identificar y eliminar el riesgo;

3. 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:

1. 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.

2. Si la implementacin del riesgo de anlisis afectar de forma esencial los

beneficios del proyecto, no debera utilizarse este modelo.

3. 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[editar]

Artculo principal: 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[editar]
Artculo principal: Desarrollo gil de software
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[editar]

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 producir cdigo. 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[editar]

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 re-utilizable en otra.

2. Aproximadamente el 0% de una aplicacin administrativa es re-utilizable.

3. Aproximadamente el 75% de las funciones son comunes a ms de un programa.

4. Solo el 15% del cdigo encontrado en muchos sistemas es nico 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

Modelos de mejora de procesos[editar]

Capability Maturity Model Integration
El Capability Maturity Model Integration (CMMI), en espaol Integracin
de Modelos de Madurez de Capacidades es uno de los modelos lderes
basados en mejores prcticas. Son evaluaciones independientes las que
confirman el grado con el que una organizacin siguen sus propios procesos,
que no evala la calidad de los procesos o del software que se produce. CMMI
ha reemplazado a CMM y tiene un mbito global, no slo en procesos
destinados al desarrollo del software.
ISO 9000
ISO 9000 describe estndares para un proceso organizado formalmente para
resultar en un producto y los mtodos de gestin y monitoreo del progreso.
Aunque este estndar se cre inicialmente para el sector de produccin, los
estndares de ISO 9000 tambin se han aplicado al desarrollo del software. Al
igual que CMMI, que una organizacin est certificada con el ISO 9000 no
garantiza la calidad del resultado final, slo confirma que se ha seguido los
procesos establecidos.
ISO 15504
ISO 15504, tambin conocido como Software Process Improvement
Capability Determination (SPICE), en espaol Determinacin de la
Capacidad de Mejora del Proceso de Software es un marco para la
evaluacin de procesos de software. Este estndar tiene como objetivo un
modelo claro para poder comparar procesos. SPICE se utiliza como en el caso
de CMMI. Modela procesos para gestionar, controlar, guiar y monitorear el
desarrollo del software. Este modelo se utiliza entonces para medir lo que una
organizacin o proyecto hace durante el desarrollo del software. Esta
informacin se analiza para identificar puntos dbiles y definir acciones para
subsanarlos. Tambin identifica puntos fuertes que pueden adoptarse en el
resto de la organizacin.
Mtodos formales[editar]
Los mtodos formales son soluciones matemticas para resolver problemas de
software y hardware a nivel de requisitos, especificacin y diseo. Ejemplos de
mtodos formales incluyen el Mtodo B, la red de Petri, la demostracin automtica
de teoremas, RAISE y el VDM. Hay varias notaciones de especificaciones formales,
tales como el lenguaje Z. Ms generalmente, se puede utilizar la teora de autmatas
para aumentar y validar el comportamiento de la aplicacin diseando un sistema de
autmata finito.

Las metodologas basadas en los autmatas finitos permiten especificacin de

software ejecutable y evitar la creacin convencional de cdigo.

Los mtodos formales se suelen aplicar en software de aviacin, especialmente si es

software de seguridad crtico. Los estndares de aseguramiento del software de
seguridad, tales como DO178B demandan mtodos formales en el nivel ms alto de
categorizacin (Nivel A).

La formalizacin del desarrollo de software est ganando en fuerza poco a poco, en

otros mbitos, con la aplicacin del lenguaje de especificacin OCL2.0 (y
especializaciones tales como Java Modeling Language) y particularmente con Model-
driven Architecture, que permite la ejecucin de diseos, incluso especificaciones.

Otra tendencia que est surgiendo en el desarrollo de software es la redaccin de

especificaciones en algn tipo de lgica (normalmente una variacin de FOL), para
acto seguido ejecutar esa lgica como si se tratase de un programa. El lenguaje OWL,
basado en lgica descriptiva, es un buen ejemplo. Tambin se est trabajando en
enlazar un idioma natural de forma automtica con lgica, lgica que puede
ejecutarse. Ejemplo en este campo es el Attempto Controlled English, una lgica de
negocios de Internet, que no busca controlar el vocabulario o la sintaxis. Una
caractersticas de los sistemas que apoyan el vnculo bidireccional ingls-lgica y
ejecucin directa de la lgica es que pueden explicar sus resultados en ingls en un
nivel de negocios o cientfico.

Principales Roles en el proceso de Desarrollo de

Software[editar]
Un Rol se define como una Funcin que alguien o algo cumple (Abstracta
Academy, 2016).

Cada uno de los roles aportar al grupo parte del total necesario para tener xito en el
desarrollo. Los roles son necesarios para cubrir todas las especificaciones necesarias
para cumplir un proceso ya que no todos tenemos las mismas cualidades y
experiencias. Adems al asignar roles, se definen objetivos y actividades para cada
uno; lo anterior evitando que alguna actividad no sea asignada o que dos personas
realicen el mismo trabajo.

Descripcin de roles en el Proceso de Desarrollo de Software[editar]

El software se construye en equipo y hay muchas metodologas diferentes. Los roles

se asignan de acuerdo a las capacidades de cada persona, as como tambin su
especializacin, experiencia e inters. Los roles ms comunes son:

Gerente de proyecto[editar]

Tiene por funcin presentar informes sobre las litigaciones de riesgos, hacer cumplir
los plazos y lleva el control de los costos. Tambin organiza el equipo, realiza
planificacin y estima el tiempo de las actividades. En conclusin, resuelve
problemas.

Analista de requerimientos[editar]

Se encarga del revelamiento de los requerimientos esenciales para el desarrollo del

Software, la documentacin de los requerimientos para as el resto del equipo lo
pueda consulta en cualquier momento. Debe ser una persona con capacidad de
abstraccin y anlisis.

Desarrollador de software o programador[editar]

Encargado de la concepcin y el diseo, escribe el cdigo, prueba lo que construye y

se encarga de hacer el mantenimiento del cdigo.

Testeador[editar]

Disea y ejecuta las pruebas, para ello requiere conocer el producto a probar claro
esta, estudiar funcionalidad del producto y desarrollar las pruebas que revelen
incidentes crticos. Reporta los incidentes y provee informacin sobre la calidad del
sistema.

Arquitecto de software[editar]

Determina las estructuras de la aplicacin y las tecnologas con las que se construir
la aplicacin. Esta encargado del aseguramiento de la calidad, mejorar continuamente
la arquitectura. Gestiona los requerimientos no funcionales, asume la direccin
tcnica para asegurar que todos los aspectos de la arquitectura se estn desarrollando
de manera correcta.
Debe ser una persona con un innato sentido de liderazgo, dispuesto a formar a los
integrantes del equipo, dispuesto a recibir y aplicar abiertamente recomendaciones.