CICLO DE VIDA DE UN SOFTWARE

Proceso para el desarrollo de software

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.

ndice
[ocultar]

1Generalidades
2Actividades del desarrollo de software
o 2.1Planificacin
o 2.2Implementacin, pruebas y documentacin
o 2.3Despliegue y mantenimiento
3Modelos de Desarrollo de Software
o 3.1Modelo de cascada
o 3.2Modelo de espiral
o 3.3Desarrollo iterativo e incremental
o 3.4Desarrollo gil
o 3.5Codificacin y correccin
o 3.6Orientado a la Reutilizacin
4Modelos de mejora de procesos
5Mtodos formales
6Principales Roles en el proceso de Desarrollo de Software
o 6.1Descripcin de roles en el Proceso de Desarrollo de Software
6.1.1Gerente de proyecto
6.1.2Analista de requerimientos
6.1.3Desarrollador de software o programador
6.1.4Testeador
6.1.5Arquitecto de software
7Vase tambin
8Referencias
9Enlaces externos

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

Actividades del proceso de desarrollo de software representados en el desarrollo en cascada. Hay

algunos modelos ms para representar este proceso.

Planificacin[editar]
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[editar]
La implementacin es parte del proceso en el que los ingenieros de software programan el
cdigo para el proyecto de trabajo que est en relacin de las demanda del software, en esta
etapa se realizan las pruebas de caja blanca y caja negra.
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. Prcticamente es como una receta de cocina
Despliegue y mantenimiento[editar]
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 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[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.4
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 interacciones 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.5
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.6 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.7

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 est entre el 15% y 85%.8
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.9

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