Estudiante: EMILIANA ARISMENDI 1”F”

INVESTIGACION
Ciclo de vida del 'software'
El término ciclo de vida del software describe el desarrollo de
software, desde la fase inicial hasta la fase final. El propósito de este
programa es definir las distintas fases intermedias que se requieren
para validar el desarrollo de la aplicación, es decir, para garantizar que
el software cumpla los requisitos para la aplicación y verificación de
los procedimientos de desarrollo: se asegura de que los métodos
utilizados son apropiados.

Estos programas se originan en el hecho de que es muy costoso

rectificar los errores que se detectan tarde dentro de la fase de
implementación. El ciclo de vida permite que los errores se detecten lo
antes posible y, por lo tanto, permite a los desarrolladores concentrarse
en la calidad del software, en los plazos de implementación y en los
costos asociados.
El ciclo de vida básico de un software consta de los siguientes
procedimientos:
Definición de objetivos: define la finalidad del proyecto y su papel en
la estrategia global.
Análisis de los requisitos y su viabilidad: recopila, examina y formula
los requisitos del cliente y examina cualquier restricción que se pueda
aplicar.
Diseño general: requisitos generales de la arquitectura de la aplicación.
Diseño en detalle: definición precisa de cada subconjunto de la
aplicación.
Programación (programación e implementación): implementación de un
lenguaje de programación para crear las funciones definidas durante la
etapa de diseño.
Prueba de unidad: prueba individual de cada subconjunto de la
aplicación para garantizar que se implementaron de acuerdo con las
especificaciones.
Integración: garantiza que los diferentes módulos se integren con la
aplicación. Este es el propósito de la prueba de integración que está
cuidadosamente documentada.
Prueba beta (o validación): garantiza que el software cumple con las
especificaciones originales.
Documentación: sirve para documentar información necesaria para los
usuarios del software y para desarrollos futuros.
Implementación
Mantenimiento: comprende todos los procedimientos correctivos
(mantenimiento correctivo) y las actualizaciones secundarias del
software (mantenimiento continuo).
El orden y la presencia de cada uno de estos procedimientos en el ciclo
de vida de una aplicación dependen del tipo de modelo de ciclo de vida
acordado entre el cliente y el equipo de desarrolladores.

Modelos de ciclo de vida del 'software'

Para facilitar una metodología común entre el cliente y la compañía de
software, los modelos de ciclo de vida se han actualizado para reflejar las
etapas de desarrollo involucradas y la documentación requerida, de
manera que cada etapa se valide antes de continuar con la siguiente.

Modelo en cascada

El modelo de ciclo de vida en cascada se comenzó a diseñar en 1966 y se

terminó alrededor de 1970. Se define como una secuencia de fases donde
al final de cada una de ellas se reúne la documentación para garantizar
que cumple las especificaciones y los requisitos antes de pasar a la fase
siguiente:

Modelo V

El modelo de ciclo de vida V proviene del principio que establece que los
procedimientos utilizados para probar si la aplicación cumple las
especificaciones ya deben haberse creado en la fase de diseño.
 Ciclo de vida del 'software'
El ciclo de vida del desarrollo Software (SDLC en sus siglas inglesas), es
una secuencia estructurada y bien definida de las etapas en Ingeniería
de software para desarrollar el producto sofware deseado.

Actividades del SDLC

El SDLC aporta una serie de pasos a seguir con la finalidad de diseñar y
desarrollar un producto software de manera eficiente. El borrador del
SDLC incluye los pasos que veremos a continuación:
 Comunicación

Este es el primer paso donde l usuario inicia la petición de un producto

software determinado. Contacta al proveedor de servicios e intenta
negociar las condiciones. Presenta su solicitud al proveedor de servicios
aportando la organización por escrito.

Recolección de solicitudes

A partir de este paso y en adelante el equipo de desarrollo software

trabaja para tirar adelante el proyecto. El equipo se reúne con varios
depositarios de dominio del problema, e intentan conseguir la máxima
cantidad de información possible sobre lo que requieren. Los requisitos
se contemplan y agrupan en requisitos del usuario, requisitos
funcionales y requisitos del sistema. La recolección de todos los
requisitos se lleva a cabo como se especifica a continación -

 Estudiando el software y el sistema actual o obsoleto,

 Entrevistando a usuarios y a desarrolladores de Software,
 Consultando la base de datos o
  Recogiendo respuestas a través de cuestionarios.

Estudio de viabilidad

Después de la recolección de requisitos, el equipo idea un plan para

procesar el software. En esta fase, el equipo analiza si el software puede
hacerse para cubrir todos los requisitos del usuario y si hay alguna
posibilidad de que el software ya no sea necesario. Se investiga si el
proyecto es viable a nivel financiero, práctico, y a nivel tecnológico para
que la organización acepte la oferta. Hay varios algoritmos disponibles,
los cuales ayudan a los desarrolladores a concluir si el proyecto software
es factible o no.

Análisis del sistema

En este pas los desarrolladores trazan su plan e intentan crear el mejor

y más conveniente modelo de software para el proyecto. El análisis del
sistema inclye el entendimiento de las limitaciones del producto Software;
el aprendizaje de los problemas relacionados con el sistema; los cambios
que se requieren en sistemas ya existentes con antelación, identificando
y dirigiendo el impacto del proyecto a la organización y al personal, etc.
El equipo del proyecto analiza las posibilidades del proyecto y planifica la
temporalización y los recursos correspondientes.

Diseño de Software

El siguiente paso es diseñar el producto software con la ayuda de toda la

información recogida sobre requisitos y análisis. Los inputs (aportacines)
de los usuarios y los resultados de la recogida de información hecha en
la fase anterior seran las aportaciones base de la fase actual. El output
(o resultado) de esta etapa toma la forma de 2 diseños; El diseño lógico y
el diseño físico. Los ingenieros crean meta-data (Metadatos), Diagramas
dilógicos, diagramas de flujo de datos, y en algunos casos pseudocódigos.

Codificación

Esta fase también se puede denominar 'fase de programación'. La

implementación del diseño de software empieza con el lenguaje de
programación más conveniente, y desarrollando programas ejecutables
y sin errores de manera eficiente.

Pruebas

Se estima que el 50% de todos los procesos de desarrollo de software

deberían ser evaluados. Los errores pueden arruinar el software tanto a
nivel crítico y hasta el punto de ser eliminado. Las pruebas de Software
se hacen mientras se codifica y suelen hacerlo los desarrolladores y otros
expertos evaluadores a varios niveles. Esto incluye evaluación de
módulos, evaluación del programa, evaluación del producto, evaluación
interna y finalmente evaluación con el consumidor final. Encontrar
errores y su remedio a tiempo es la llave para conseguir un software
fiable.

Integración

El Software puede necesitar estar integrado con las bibliotecas, Bases de

datos o con otro u otros programas. Esta fase del SDLC se focaliza en la
integración del software con las entidades del mundo exterior.

Implementación

Aquí se instala el software en máquinas de clientes. A veces, el software

necesita instalar configuraciones para el consumidor final con
posterioridad. El Software se evalúa por su adaptabilidad y su
portabilidad, en cuanto a las cuestiones relacionadas con la integración
y conceptos asociados, se resuelven durante la implementación.

Mantenimiento y Funcionamiento

Esta fase confirma el funcionamiento del software en términos de más

eficiencia y menos errores. Si se requiere, los usuarios se forman, o se les
presta documentación sobre como operar y como mantenerlo en
funcionamiento. El software se mantiene de forma temprana
actualizando el código en acorde a los cambios que tienen lugar en
entornos del usuario o tecnológicos. Esta fase puede que tenga que
encarar retos originados por virus ocultos o problemas no identificados
del mundo real.

Disposición

Con el paso del tiempo, puede que el software falle en su ejecución. Puede
que se vuelva totalmente obsoleto o que necesite actualizaciones. De ahí
surge una necesidad urgente de eliminar una parte importante del
sistema. Esta fase incluye archivar datos y componentes software
requeridos, cierre del sistema, planificación de la actividad de disposición
y terminación de sistema en el momento final del sistema.

Paradigma de desarrollo de Software

El Paradigma de desarrollo de Software ayuda al desarrollador a escoger
una estrategia para desarrollar el software. El paradigma de desarrollo
software tiene su propio set de herramientas, métodos y procedimientos,
los cuales son expresados de forma clara, y define el ciclo de vida del
desarrollo del software. Algunos paradigmas de desarrollo de software o
modelos de proceso se definen a continuación:

Modelo de cascada
El modelo de cascada es el modelo de paradigma más simple en desarrollo
de software. Sigue un modelo en que las fases del SDLC funcionarán una
detrás de la otra de forma lineal. Lo que significa que solamente cuando
la primera fase se termina se puede empezar con la segunda, y así

progresivamente.

Este modelo asume que todo se lleva a cabo y tiene lugar tal y como se
había planeado en la fase anterior, y no es necesario pensar en asuntos
pasados que podrían surgir en la siguiente fase. Este modelo no
funcionará correctamente si se dejan asuntos de lado en la fase previa.
La naturaleza secuencial del modelo no permite volver atrás y deshacer o
volver a hacer acciones.

Este modelo es recomendable cuando el desarrollador ya ha diseñado y

desarrollado softwares similares con anterioridad, y por eso está al tanto
de todos sus dominios.

Modelo repetitivo
Este modelo guía el proceso de desarrollo de software en repeticiones.
Proyecta el proceso de desarrollo de forma cíclica repitiendo cada paso
después de cada ciclo en el proceso de SDLC.

El software primero se desarrolla en menor escala y se siguen y tienen en

consideración todos los pasos. Entonces, por cada repetición, más
módulos y características son diseñados, codificados, evaluados y
añadidos al software. Cada ciclo produce un sotware completo, con más
características y capacidad que los previos.

Después de cada repetición, el equipo directivo puede concentrarse en la

gestión de riesgos y prepararse para la siguiente repetición. Como el ciclo
incluye pequeñas porciones de la totalidad del proceso software, es más
fácil gestionar el proceso de desarrollo, pero a la vez se consumen más
recursos.

Modelo en espiral

El modelo espiral en ingeniería del software tiene un enfoque muy

distinto al modelo de cascada, principalmente porque su enfoque
va dirigido hacia el análisis de riesgos. El modelo de ciclo de vida en
espiral, consiste en realizar diversas iteraciones, pasando por cada una
de sus fases una y otra ves. A diferencia del modelo cascada que no
tiene vuelta atrás, en el modelo en espiral se pueden hacer las
iteraciones que se consideren necesarias y estas son sus fases
principales:

1. Determinación de Objetivos
2. Análisis de riesgos
3. Desarrollo y Pruebas
4. Planificación
Entre las principales ventajas de desarrollar un proyecto con el
modelo espiral, es que los riesgos se van disminuyendo conforme
avanzan los ciclos o iteraciones, de hecho no puedes avanzar a un
ciclo nuevo, si no se ha dado solución a todos los riesgos latentes.
Lamentablemente el modelo es realmente costoso y para que puedas
tener un alto nivel de eficacia en la evaluación final de tu proyecto con
este ciclo de vida, necesitas que tu equipo tenga un gran nivel de
conocimientos y si es posible buena experiencia para superar
cualquier riesgo al cual se puedan enfrentar.
 Modelo V

El mayor inconveniente del modelo de cascada es que solo se pasa a la

siguiente fase cuando se completa la anterior, por tanto no es posible
volver atrás si se encuentra algún error en las etapas posteriores. El
Modelo V aporta opciones de evaluación del software en cada etapa de
manera inversa.

En cada etapa, se crea la planificaión de las pruebas y los casos de

pruebas para verificar y validar el producto según los requisitos de la
etapa. Por ejemplo, en la etapa de recogida de requisitos, el equipo de
evaluadores prepara las pruebas de caso correspondientes a los
requisitos. Más tarde, cuando el producto se desarrolla y está preparado
para ser evaluado, las pruebas de caso en esta etapa verifican el software
y su validez sugún sus requisitos.
Esto hace que tanto la verificación como la validación vayan en paralelo.
Este modelo también se conoce como modelo de validación y verificación.

Modelo Big Bang

Este modelo es el modelo con la forma más simple. Requiere poca

planificación, mucha programación y también muchos fondos. Este
modelo se conceptualiza alrededor de la teoría de creación del universo
'Big Bang'. Tal como cuentan los científicos, después del big bang muchas
galaxias, planetas y estrellas evolucionaron. De la misma manera, si
reunimos muchos
fondos y programación,
quizá podemos
conseguir el
mejor producto
de software.

Para este modelo, se requiere poca planificación. No sigue ningún proceso

concreto, y a veces el cliente no está seguro de las futuras necesidades y
requisitos. Por tanto la entrada o input respecto a los requisitos es
arbitraria.

Este modelo no es recomendable para grandes proyectos de software,

pero es bueno para aprender y experimentar.

Modelo Iterativo o por Prototipos

Uno de mis modelos de ciclo de vida de antaño que realmente es de
mis favoritos, es el modelo iterativo. ¿La razón?, se maneja a base
de prototipos, es decir. Es uno de los primeros ciclos de vida que
permitían que el código fuente fuera reutilizable, sin embargo con el
modelo iterativo no solo es utilizable, si no que para muchos, estos
prototipos pueden llegar a ser el producto final que siempre quisieron, lo
cual lo hace realmente relevante y destacable, por encima del resto de los
modelos de antaño que puedas encontrar.

Básicamente, las fases del ciclo de vida del sistema, son las siguientes:

1. Inicialización
2. Iteración
3. Lista de Control

Una de las principales ventajas del modelo iterativo, es que la

retroalimentación a los usuarios se proporciona desde muy
temprano, haciendo que adentrarse en el proyecto sea demasiado
sencillo. Por supuesto que el hecho de contar con iteraciones nos da
ciertas ventajas, pues con cada iteración realizada, se van separando las
partes complejas de el, permitiendo más el acceso al software. Y por
supuesto, un sistema creado mediante el ciclo de vida iterativo, tiende a
no fallar casi, lo cual es garantía de satisfacción para el cliente en este
caso o para la empresa que está implementando esta metodología.

Modelos del Ciclo de Vida del Desarrollo Ágiles

Las tendencias, con el paso del tiempo suelen cambiar para bien y en el
caso de las metodologías del ciclo de vida desarrollo de software no es la
excepción. Y un claro ejemplo de esto, son los modelos de desarrollo ágil.
Estos procesos se caracterizan por estar basados en las etapas del
ciclo de vida del software tradicionales, pero combinándolas con
algunas técnicas y siendo aún mas solapadoras en cuando al orden
que se deben ejecutar. Bueno no les diré más, mejor vamos a ver
brevemente cuales son algunas de ellas, las más conocidas y populares,
claro y la mejor de todas.

Modelo Scrum

El ciclo de vida del sistema, puede agilirse si se utiliza la metodología

Scrum, uno de los modelos del ciclo de vida del desarrollo del
software más populares y mas recientes, bueno no tanto, pero si más
que los de antaño. El modelo Scrum, se encuentra basado en lo que es el
desarrollo incremental, es decir, conforme pasen las fases y las
iteraciones, mayor va a ser el tamaño del proyecto que se esté
desarrollando, es por eso que uno de los principales requisitos para
llevarlo a cabo, es que tu equipo de desarrollo sea de calidad. Teniendo
una alta calidad en el equipo, tendremos garantizado un excelente
funcionamiento.

Como te mencionaba al principio, el modelo Scrum, deja de seguir

metodologías lineales, podemos despedirnos del modelo cascada y
secuencial, pues ahora procedemos a solapar las fases y no importará
en que momento tengas que volver atrás, siempre habrá un equipo de
trabajo de buena calidad, que tenga ese soporte para aguantar los
cambios que son ciertamente normales dentro de la metodología Scrum.
Por último, como ingrediente vital tenemos la comunicación, y es que acá
olvídate de las tendencias de ese jefes que te tienen envuelto en una
burbuja desarrollando. Con el modelo scrum podrás estar comunicado
con tu equipo de trabajo en todo momento, para estar al tanto de los
sucesos.

Ahora veremos brevemente, cuales son los procesos que el modelo Scrum
utiliza:

1. Product Backlog
2. Sprint Backlog
3. Sprint Planning Meeting
4. Daily Scrum o Stand-up Meeting
5. Sprint Review
6. Sprint Retrospective

Estas son las fases del ciclo de vida del software en esta metodología, el
cuál básicamente consiste en realizar un análisis de los
requerimientos del sistema (Product Backlog), señalar cuales serán
los objetivos a corto o mediano plazo dentro de un sprint, osea, la fase
de desarrollo. Posteriormente los desarrolladores harán lo suyo, se
realizan algunas pruebas y se retroalimenta de acuerdo a lo conseguido
al terminar la última fase. Recuerda que aquí, se pueden añadir nuevas
cosas en todo momento, pues el modelo Scrum no se bloquea en ninguna
de sus fases.

Modelo Kanban

El modelo Kanban, es uno de los modelos más visuales de las

metodologías ágiles. Consiste en la creación de un tablero con
etiquetas, donde se seccionan cada una de las fases de su desarrollo,
además se clasifica de acuerdo a los equipos de trabajo y se les asignan
objetivos a corto, mediano y largo plazo.

Entre las ventajas de este modelo del ciclo de vida del software, destaca
el hecho de no tener un orden tal cual, de hecho todas las fases
comienzan a trabajar a la par, no hay tiempos de espera y
básicamente su objetivo es que los desarrolladores y programadores
estén trabajando todo el tiempo. Si concluyes con las fases del proyecto
que te corresponde, seguramente tendrás que avanzar en fases del nuevo
proyecto que está por venir.
Por supuesto, la metodología Kanban, también requiere de un equipo
totalmente capacitado, pues solamente de esta forma se podrán lograr
los objetivos. Así que aquí les muestro las fases del proceso del ciclo de
vida de un sistema, mediante la metodología japonesa Kanban:

1. Definir el Flujo de Trabajo

2. Fases del Ciclo de Producción
3. Stop Starting, start finishing
4. Tener un Control

Si aún no estas seguro de si implementar la metodología Kanban o no, te

cuento. La empresa Toyota, ha sido una de las primeras en implementar
la metodología, incrementando la eficiencia y productividad en un alto
porcentaje. Considera como principal ventaja, que el producto final
quedará terminado en un periodo de tiempo mucho más corto, que con

cualquiera de las metodologías vistas al principio.

 Modelo XP o Programación extrema

Posiblemente la más destacada de las metodologías ágiles para los

ciclos de vida de un software, es la metodología XP o modelo de
programación extrema. A diferencia del resto de las metodología del
mundo, habidas y por haber, esta es adaptable de acuerdo a las
necesidades y requerimientos que se tengan que implementar, con la
ventaja de que podemos hacer uso de cualquier modelo anterior para el
desarrollo y de inmediato salirnos y programar otras cosas, es muy
solapador y permite mucha más libertad en el equipo de trabajo que el
resto de los modelos.

Además, si querías una diferencia aún mayor, en la metodología de

programación extrema, el cliente se encuentra involucrado en el proceso
de desarrollo, lo que hace que al final el producto pueda estar terminado
en un menor tiempo, pues evitamos muchas perdidas de tiempo,
elaborando cosas que no son y que en la revisión al cliente no le
agradarán, acá el cliente va viendo lo que se va desarrollando y tiene la
libertad de proponer cambios, ideas, requerimientos o actualizaciones sin
ningún problema.

Los valores que componen a al modelo de programación extrema, son los

siguientes:

1. Comunicación
2. Simplicidad
3. Retroalimentación
4. Valentía
5. Respeto

Esta serie de valores, son de suma importancia para que se pueda llevar
a cabo un proyecto de alta calidad. Cada uno de ellos, tiene su razón de
ser y existir, por ejemplo, la comunicación, la cual debe estar incluso con
el cliente y ni hablar del resto de los equipos de trabajo. La simplicidad
corresponde al hecho de no hacer cosas que quiten mucho tiempo, la idea
es terminar rápido y las cosas que sean muy tardadas es mejor dejarlas
de lado. La retroalimentación es vital, más cuando los equipos de
trabajo deben ser de dos personas, siempre es bueno aprender cosas
nuevas de nuestro compañero de trabajo y esto seguramente todos lo
hemos vivido alguna ves.
La valentía es un valor integrado como programador, pues deber ser
valiente para afrontar los cambios que se vengan, tomar decisiones
radicales y en todo momento mantener esa fuerza que tanto a ti como a
tu equipo de trabajo los debe mantener a tope. Y por su puesto el respeto,
esto es en todo el equipo de trabajo, hasta el cliente debe tener un margen
de respeto por el equipo de desarrollo. Con estos valores la metodología
tendrá una buena formación, pero vamos a ver cuales son las
características principales de la programación extrema:

1. Tipo de Desarrollo Iterativo e incremental

2. Pruebas Unitarias
3. Trabajo en Equipo
4. Trabajo junto al cliente
5. Corrección de Errores
6. Reetructuración del Código
7. El Código es de todos
8. Código simple es la clave

Como te puedes dar cuenta, pasos como hacer el código simple o las
pruebas unitarias para prevenir errores y tener que darle muchas vueltas
al código, además de que las fases se segmentan en pequeñas porciones,
para que si hay errores, estos puedan ser modificados fácilmente.

Sin embargo seguramente notaste que no hay documentación por ningún

lado, esto es porque con tanta comunicación, en realidad no es necesaria,
sin embargo dentro del código se van dejando comentarios con las cosas
que otro programador no pueda llegar a entender y se utilizan variables
o clases entendibles para que todo el mundo tenga la facilidad de
comprenderlo. Ya solamente en caso muy necesario, se procede a hacer
documentación breve para algunas partes, pero regularmente no se
utiliza de forma tradicional.