Вы находитесь на странице: 1из 26

CICLO DE DESARROLLO

DEL SOFTWARE
CONCEPTO
El software nace, crece y muere
Es su ciclo de vida
Nace con sus requerimientos y diseo
Crece con su desarrollo y mantenimiento
Muere cuando se reemplaza por otro
Software obsoleto
SOFTWARE OBSOLETO
Razones
Crecimiento de la empresa
Cambio de los requerimientos originales
Nmero de usuarios
Nmero de transacciones
Distribucin del software
Cambio de operaciones
Ampliacin
Integracin con otros sistemas
DEFINICIN FORMAL
Un marco de referencia que contiene los
procesos, las actividades y las tareas
involucradas en el desarrollo, la
explotacin y el mantenimiento de un
producto de software, abarcando la vida
del sistema desde la definicin de los
requisitos hasta la finalizacin de su uso.
Las etapas del proceso de
desarrollo de software
Cualquier sistema de informacin va pasando por una serie
de fases a lo largo de su vida. Su ciclo de vida comprende
una serie de etapas entre las que se encuentran las
siguientes:
Planificacin
Anlisis
Diseo
Implementacin
Pruebas
Instalacin o despliegue
Uso y mantenimiento
PLANIFICACIN
Antes de que se le de oficialmente el pistoletazo de salida a un
proyecto de desarrollo de un sistema de informacin, es
necesario realizar una serie de tareas previas que influirn
decisivamente en la finalizacin con xito del proyecto. Estas
tareas se conocen popularmente como el fuzzy front-end del
proyecto al no estar sujetas a plazos.
Las tareas iniciales que se realizarn esta fase inicial del
proyecto incluyen actividades tales como la determinacin del
mbito del proyecto, la realizacin de un estudio de viabilidad,
el anlisis de los riesgos asociados al proyecto, una estimacin
del coste del proyecto, su planificacin temporal y la asignacin
de recursos a las distintas etapas del proyecto.
Delimitacin del mbito del proyecto
Estudio de viabilidad
Anlisis de riesgos
Estimacin
Planificacin temporal y asignacin de recursos
Algunos errores comunes
Abreviar las etapas iniciales del proceso de desarrollo de software
(planificacin y anlisis, generalmente) para pasar directamente a la
"construccin" del sistema.
Los errores cometidos en las fases iniciales de un proyecto son mucho
ms costosos de corregir a la larga, por lo que abreviar las etapas
iniciales tiene graves consecuencias.
No gestionar adecuadamente los cambios que inevitablemente ocurren
durante el proyecto. Tan malo es permitir cualquier cambio de forma
indiscriminada como ser excesivamente rgidos a la hora de no admitir
cambios aunque stos sean razonables.
Reducir la interaccin con el cliente, ya que aparentemente slo se
dedica a entorpecer nuestro trabajo con sus continuos cambios de
opinin y sus expectativas poco realistas. Craso error. Al fin y al cabo,
el cliente es la persona cuyas necesidades hemos de descubrir y
satisfacer.
Hacer trabajar horas extra a los miembros del equipo de
desarrollo slo sirve para disminuir su productividad (trabajo
realizado por unidad de tiempo). Tras un larga jornada de trabajo,
la mente pierde su frescura y comete errores que luego tendrn
que corregirse. Adivina cmo? Con ms horas extra.
No informar de pequeos retrasos pensando que ms tarde se
recuperar el tiempo perdido. La planificacin temporal del
proyecto debe ir ajustndose conforme vamos aprendiendo ms
cosas acerca del problema al que nos enfrentamos. En el peor de
los casos, se deben negociar algunos recortes con el cliente si ste
desea mantener los plazos estipulados al comienzo del proyecto.
Olvidar que aadir personal a un proyecto retrasado, por lo
general, slo lo retrasa ms (la ley de Brooks). La curva de
aprendizaje que se necesita para comenzar a ser productivo ha de
tenerse siempre en cuenta. Adems, quin le resuelve las dudas
al recin incorporado? El tiempo que empleen los dems miembros
del equipo ser tiempo que no podrn utilizar en otras cosas.

ANLISIS
Lo primero que debemos hacer para construir un sistema de
informacin es averiguar qu es exactamente lo que tiene que
hacer el sistema. La etapa de anlisis en el ciclo de vida del
software corresponde al proceso mediante el cual se intenta
descubrir qu es lo que realmente se necesita y se llega a una
comprensin adecuada de los requerimientos del sistema (las
caractersticas que el sistema debe poseer).
La inestabilidad de los requerimientos de un sistema es
inevitable. Se estima que un 25% de los requerimientos
iniciales de un sistema cambian antes de que el sistema
comience a utilizarse. Muchas prcticas resultan efectivas
para gestionar adecuadamente los requerimientos de un
sistema y, en cierto modo, controlar su evolucin. Un buen
analista debera tener una formacin adecuada en:
- Tcnicas de elicitacin de requerimientos.
- Herramientas de modelado de sistemas.
- Metodologas de anlisis de requerimientos.
Tcnicas de elicitacin de requerimientos
La elicitacin de requerimientos requiere previamente la
identificacin de las personas afectadas por el proyecto,
sus stakeholders (literalmente, los que apuestan algo), lo
que incluye desde el cliente que paga el proyecto hasta los
usuarios finales de la aplicacin, sin olvidarse de terceras
personas y organizaciones relacionadas indirectamente con
el sistema que se va a desarrollar (por ejemplo, empresas
competidoras y organismos reguladores).
Herramientas de modelado de sistemas
Un modelo, bsicamente, no es ms que una
simplificacin de la realidad
En resumidas cuentas, los modelos, entre otras cosas,
facilitan el anlisis de los requerimientos del sistema,
as como su posterior diseo e implementacin. Un
modelo, en definitiva, proporciona "los planos" de un
sistema. El modelo ha de capturar "lo esencial desde
determinado punto de vista. En funcin de para qu
queramos el modelo, lo haremos ms o menos
detallado, siempre de acuerdo a su relevancia y
utilidad.
Metodologas de anlisis de requerimientos
Una metodologa no es ms que un conjunto de
convenciones que han resultado tiles en la prctica y cuyo
uso combinado se recomienda.
Las metodologas de anlisis particulares, de las que hay
muchas, usualmente estn ligadas, o bien al uso de
determinadas herramientas (por lo que el vendedor de la
herramienta se convierte, muchas veces, en el nico
promotor de la metodologa), o bien a empresas de
consultora concretas (que ofrecen cursos de aprendizaje
de la metodologa que proponen).
DISEO
Un software bien diseado debe exhibir determinadas
caractersticas. Su diseo debera ser modular en vez de
monoltico.
En la fase de diseo se han de estudiar posibles alternativas
de implementacin para el sistema de informacin que hemos
de construir y se ha de decidir la estructura general que
tendr el sistema (su diseo arquitectnico). El diseo de un
sistema es complejo y el proceso de diseo ha de realizarse
de forma iterativa. La solucin inicial que propongamos
probablemente no resulte la ms adecuada para nuestro
sistema de informacin, por lo que deberemos refinarla.
Afortunadamente, tampoco es necesario que empecemos
desde cero.
Existen autnticos catlogos de patrones de diseo que nos
pueden servir para aprender de los errores que otros han
cometido sin que nosotros tengamos que repetirlos.
IMPLEMENTACIN
Para la fase de implementacin hemos de seleccionar las
herramientas adecuadas, un entorno de desarrollo que facilite
nuestro trabajo y un lenguaje de programacin apropiado para
el tipo de sistema que vayamos a construir. La eleccin de estas
herramientas depender en gran parte de las decisiones de
diseo que hayamos tomado hasta el momento y del entorno en
el que nuestro sistema deber funcionar.
A la hora de programar, deberemos procurar que nuestro cdigo
no resulte indescifrable. Para que nuestro cdigo sea legible,
hemos de evitar estructuras de control no estructuradas, elegir
cuidadosamente los identificadores de nuestras variables,
seleccionar algoritmos y estructuras de datos adecuadas para
nuestro problema, mantener la lgica de nuestra aplicacin lo
ms sencilla posible, comentar adecuadamente el texto de
nuestros programas y, por ltimo, facilitar la interpretacin
visual de nuestro cdigo mediante el uso de sangras y lneas en
blanco que separen distintos bloques de cdigo.
PRUEBAS
La bsqueda de errores que se realiza en la etapa de pruebas
puede adaptar distintas formas, en funcin del contexto y de la
fase del proyecto en la que nos encontremos:
Las pruebas de unidad sirven para comprobar el correcto
funcionamiento de un componente concreto de nuestro
sistema. Es este tipo de pruebas, el "probador debe buscar
situaciones lmite que expongan las limitaciones de la
implementacin del componente, ya sea tratando ste como
una caja negra ("pruebas de caja negra") o fijndonos en su
estructura interna ("pruebas de caja blanca")
Las pruebas de integracin son las que se realizan cuando
vamos juntando los componentes que conforman nuestro
sistema y sirven para detectar errores en sus interfaces. En
algunas empresas, como Microsoft, se hace una compilacin
diaria utilizando los componentes del sistema tal como estn en
ese momento (daily build) y se somete al sistema a una serie
de pruebas bsicas (la prueba de humo, smoke test) que
garanticen que el proyecto podr seguir avanzando al da
INSTALACIN / DESPLIEGUE
Para asegurar el correcto funcionamiento del sistema, resulta
esencial que tengamos en cuenta las dependencias que pueden
existir entre los distintos componentes del sistema y sus
versiones. Una aplicacin puede que slo funcione con una
versin concreta de una biblioteca auxiliar. Un disco duro puede
que slo rinda al nivel deseado si instalamos un controlador
concreto. Componentes que por separado funcionaran
correctamente, combinados causan problemas, por lo que
deberemos utilizar slo combinaciones conocidas que no
presenten problemas de compatibilidad.
Si nuestro sistema reemplaza a un Si nuestro sistema reemplaza
a un sistema anterior o se despliega paulatinamente en distintas
fases, tambin hemos de planificar cuidadosamente la transicin
del sistema antiguo al nuevo de forma que sus usuarios no sufran
una disrupcin en el funcionamiento del sistema
USO Y MANTENIMIENTO
La etapa de mantenimiento consume tpicamente del 40 al 80 por
ciento de los recursos de una empresa de desarrollo de software.
De hecho, con un 60% de media, es probablemente la etapa ms
importante del ciclo de vida del software.
Fases:
Eliminar los defectos que se detecten durante su vida til
(mantenimiento correctivo), lo primero que a uno se le viene a
la cabeza cuando piensa en el mantenimiento de cualquier cosa.
Adaptarlo a nuevas necesidades (mantenimiento adaptativo),
cuando el sistema ha de funcionar sobre una nueva versin del
sistema operativo o en un entorno hardware diferente, por
ejemplo.
Aadirle nueva funcionalidad (mantenimiento perfectivo),
cuando se proponen caractersticas deseables que supondran
una mejora del sistema ya existente.
ACTIVIDADES
Modelo en cascada
Anlisis
Diseo
Codificacin
Integracin
Mantenimiento
MODELO EN CASCADA
Inconveniencias
Rgido, difcil de rectificar
Documentacin inicial se vuelve obsoleta
Desarrollo evolutivo
Ciclo de vida en espiral
Uso de prototipos (de diversa fidelidad)
Extreme Programming
RAD (Rappid Application Development)
Cambia el proceso pero no las
actividades
MODELO EN ESPIRAL
Anlisis
Diseo
Construccin
Evaluacin
A
D
C
E
A
D
C
E
A
D
E
A
D
C
E
C
Prototipado Iterativo
o Diseo Espiral
Solucin
DISEO CENTRADO EN EL USUARIO
ANLISIS
Entrada
Conocimiento del dominio de la aplicacin,
actividades de los usuarios, mercado, etc.
Actividades
Identificar las necesidades del usuario
Anlisis de viabilidad
Determinar los requerimientos de la aplicacin
Salida
Documento de requerimientos del software
DISEO
Entrada
Documento de requerimientos del software
Actividades
Establecer estrategia de solucin
Anlisis de alternativas. Formalizar la solucin
Descomponer y organizar la aplicacin
Fijar descripciones de cada mdulo
Salida
Documento de diseo del software
UML (Universal Modeling Language)
CODIFICACIN
Entrada
Documento de diseo del software
Actividades
Creacin del cdigo fuente
Pruebas de unidades
Salida
Cdigo de mdulos, probado

INTEGRACIN. VALIDACIN
Entrada
Cdigo de mdulos, probado
Documento de requerimientos del
software (validacin)
Actividades
Pruebas de integracin
Pruebas de validacin
Salida
Aplicacin completa, lista para usar
MANTENIMIENTO
Entrada
Software listo para usar
Actividades
Instalacin
Uso en paralelo
Implementacin
Nuevos requerimientos, correcciones y
modificaciones
Soporte de usuarios
Salida
Aplicacin respondiendo a las necesidades
actuales

Вам также может понравиться