software

1. CICLO DE VIDA DEL
SOFTWARE

2. CICLO DE VIDA DEL SOFTWARE
Es la forma mediante la cual se describen los
diferentes pasos que se deben seguir para el
desarrollo de un software, partiendo desde una
necesidad hasta llegar a la puesta en marcha de
una solución y su apropiado mantenimiento.

3. CICLO DE VIDA DEL SOFTWARE
El ciclo de vida para un software comienza
cuando se tiene la necesidad de resolver un
problema, y termina cuando el programa que se
desarrolló para cumplir con los requerimientos
deja de ser utilizado.
El estándar internacional que regula el método
de selección, implementación y monitoreo del
ciclo de vida del software es ISO 12207.

4. ACTIVIDADES DEL DESARROLLO DE
SOFTWARE
 Planificación.
 Implementación, Pruebas y Documentación.
 Despliegue, Entrenamiento y Soporte.
 Mantenimiento

5. PLANIFICACION
La importante tarea a la hora de crear un
producto de software es obtener los requisitos o
el análisis de los requisitos. Los clientes suelen
tener una idea más bien abstracta del resultado
final, pero no sobre las funciones que debería
cumplir el software.
Una vez que se hayan recopilado los requisitos
del cliente, se debe realizar un análisis del
ámbito del desarrollo. Este documento se

6. IMPLEMENTACIÓN, PRUEBAS Y
DOCUMENTACIÓN
La implementación es parte del proceso en el
que los ingenieros de software programan el
código del proyecto.
Las pruebas de software son parte esencial del
proceso de desarrollo del software. Esta parte
del proceso tiene la función de detectar los
errores de software lo antes posible.
La documentación del diseño interno del
software con el objetivo de facilitar su mejora y

7. DESPLIEGUE, ENTRENAMIENTO Y
SOPORTE
El despliegue comienza cuando el código ha sido
suficientemente probado, ha sido probado para
su liberación y ha sido distribuido en el entorno
de producción.
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

8. MANTENIMIENTO
El mantenimiento y mejora del software con
problemas recientemente desplegado puede
requerir mas tiempo que el desarrollo inicial de
software. Es posible que haya que incorporar
código que no se ajusta al diseño con el objetivo
de solucionar o ampliar la funcionalidad para un
cliente.
Si los costos de mantenimiento son muy
elevados puede que sea oportuno rediseñar el

9. MODELOS DE DESARROLLO DE
SOFTWARE
Los modelos de desarrollo de software son una
representación abstracta de una manera en
particular. Realmente no representan cómo se debe
desarrollar el software, sino de un enfoque común.
Puede ser modificado y adaptado de acuerdo a las
necesidades de software en proceso de desarrollo.
Hay varios modelos para perfilar el proceso de
desarrollo, cada uno de las cuales cuenta con pro y
contras. El proyecto debería escoger el mas
apropiado para sus necesidades. Existen tres
paradigmas de los modelos de desarrollo de

10. PARADIGMA TRADICIONAL
Es uno de los paradigmas mas antiguos, se
invento durante la creación del método
estructurado. Si se elige un proyecto el método
varia en etapas.
Como todo modelo existen sus pros y contras al
usar este paradigma:

11. PARADIGMA TRADICIONAL

12. PARADIGMA ORIENTADO A
OBJETOS
Estos modelos se basan en la programación
orientada a objetos; por lo tanto se refiere al
concepto de clase, el análisis de requisitos y el
diseño. El modelo o paradigma orientado a
objetos posee dos características principales las
cuales son:
 Permite la re-utilización de software
 Facilita el desarrollo de herramientas
informáticas de apoyo al desarrollo el cual es
simple al implementarla en una notación

13. PARADIGMA DE DESARROLLO ÁGIL
Es un paradigma de las Metodologías de
Desarrollo basado en procesos ágiles. Estos
intentan evitar los tediosos caminos de las
metodologías tradicionales enfocándose 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.

14. ETAPAS DEL CICLO DE VIDA DEL
SOFTWARE
El ciclo de vida clásico del software siendo uno
de los más utilizados tal como lo plantean
diferentes autores, esta conformado en su
versión ampliada por siete etapas que se pueden
representar mediante un modelo en cascada.

15. ETAPAS DEL CICLO DE VIDA DEL
SOFTWARE

16. INGENIERÍA DE SISTEMAS
En esta etapa el analista luego de un minucioso y
detallado estudio de los sistemas de una
organización detecta un problema o una
necesidad que para su solución y/o satisfacción
es necesario realizar un desarrollo de Software.

17. ANÁLISIS
En esta etapa se debe entender y comprender de
forma detallada cual es la problemática a
resolver, verificando el entorno en el cual se
encuentra dicho problema, de tal manera que se
obtenga la información necesaria y suficiente
para afrontar su respectiva solución.
Esta etapa es conocida como la del QUÉ se va a
solucionar.

18. DISEÑO
Una vez que se tiene la suficiente información
del problema a solucionar, es importante
determinar la estrategia que se va a utilizar para
resolver el problema.
Esta etapa es conocida bajo el nombre de CÓMO
se va a solucionar.

19. IMPLEMENTACIÓN
Partiendo del análisis y diseño de la solución, en
esta etapa se procede a desarrollar el
correspondiente programa que solucione el
problema mediante el uso de una herramienta
computacional determinada.

20. PRUEBAS
Los errores humanos dentro de la programación
de los computadores son muchos y aumentan
considerablemente con la complejidad del
problema.
Cuando se termina de escribir un programa de
computador, es necesario realizar las debidas
pruebas que garanticen el correcto
funcionamiento de dicho programa bajo el
mayor numero de situaciones posibles a las que

21. DOCUMENTACION
Es la guía o comunicación escrita en sus
diferentes formas, ya sea en enunciados,
procedimientos, dibujos o diagramas que se
hace sobre el desarrollo de un programa.
La importancia de la documentación radica en
que a menudo un programa escrito por una
persona, es modificado por otra. Por ello la
documentación sirve para ayudar a comprender
o usar un programa o para facilitar futuras

22. La documentación se compone de tres partes:
 Documentación Interna: Son los comentarios
o mensajes que se añaden al código fuente
para hacer mas claro el entendimiento de los
procesos que lo conforman, incluyendo las pre-
condiciones y las pos-condiciones de cada
función.

23.  Documentación Externa: Se define en un
documento escrito con los siguientes puntos:
 Descripción del Problema
 Datos del Autor
 Algoritmo (Diagrama de flujo o Pseudocódigo)
 Diccionario de Datos
 Código Fuente (Programa)

24.  Manual de Usuario: Describe paso a paso la
manera de como funciona el programa, con el
fin de que el usuario lo pueda manejar para que
obtenga el resultado deseado.

25. MANTENIMIENTO
Una vez instalado un programa y puesto en
marcha para realizar la solución del problema
previamente planteado o satisfacer una
determinada necesidad, es importante mantener
una estructura de actualización, verificación y
validación que permitan a dicho programa ser
útil y mantenerse actualizado según las
necesidades o requerimientos planteados
durante su vida útil. Para realizar un adecuado
mantenimiento, es necesario contar con una

26. MODELO PROTOTIPO
Este modelo servirá para modelar y poder
mostrar al cliente como se va a realizar la E/S de
datos en la aplicación, de forma que éste pueda
hacerse una idea de como va a ser el sistema
final, pudiendo entonces detectar deficiencias o
errores en la especificación aunque el modelo no
se mas que una cáscara vacía.

27. MODELO PROTOTIPO
Según este modelo puede tener alguna de las tres
formas siguientes:
 Un prototipo, en papel o ejecutable en ordenador
que describa la interacción hombre-maquina y los
listados del sistema.
 Un prototipo que implemente algún(os)
subconjunto(s) de la función requerida y que sirva
para evaluar el rendimiento de un algoritmo o las
necesidades de capacidad de almacenamiento y
velocidad de cálculos del sistema final.

28. MODELO PROTOTIPO
 Un programa que realice en todo o en parte la
función deseada pero que tenga características
(rendimiento, consideración de casos
particulares, etc.) que deban ser mejoradas
durante el desarrollo del proyecto.

29. MODELO PROTOTIPO
La secuencia de tareas del paradigma de
construcción de prototipos puede verse en la
siguiente figura:

30. MODELO ESPIRAL
Básicamente, la idea es desarrollo incremental
usando el modelo Cascada para cada paso,
ayudando a administrar los riesgos. No se
define en detalle el sistema completo al
principio; los diseñadores deberían definir e
implementar solamente los rasgos de mayor
prioridad.
Con el conocimiento adquirido, podrían
entonces volver atrás y definir e implementar

31. MODELO ESPIRAL
El modelo Espiral define cuatro actividades
principales en su ciclo de vida:
 Planeamiento: Determinación de los objetivos,
alternativas y limitaciones del proyecto.
 Análisis de Riesgo: Análisis de alternativas e
identificación y solución del riesgo.
 Ingeniería: Desarrollo y testeo del producto.
 Evaluación del Cliente: Tasación de los
resultados de la ingeniería.

32. MODELO ESPIRAL
El modelo está representado por una espiral
divida en cuatro cuadrantes, cada una de las
cuales representa una de las actividades.

33. MODELO ESPIRAL
Puntos Fuertes:
 Evita las dificultades de los modelos existentes a través
de un acercamiento conducido por el riesgo.
 Intenta eliminar errores en las fases tempranas.
 Es el mismo modelo para el desarrollo y el
mantenimiento.
 Provee mecanismos para la aseguración de la calidad
del software.
 La reevaluación después de cada fase permite en las
percepciones de los usuarios, avances tecnológicos o
perspectivas financiera.

34. MODELO ESPIRAL
Puntos Débiles:
 Falta un proceso de guía explícito para
determinar objetivos, limitaciones y
alternativas.
 Provee más flexibilidad que la conveniente
para la mayoría de las aplicaciones.
 La pericia de tasación del riesgo no es una
tarea fácil. El autor declara que es necesaria
mucha experiencia en proyectos de software

35. MODELO ESPIRAL
Aplicación:
 Proyectos complejos
 Proyectos Dinámicos
 Proyectos Innovadores
 Proyectos Ambiciosos
Todos estos proyectos llevados a cabo por
equipos internos (no necesariamente de
software).

36. MODELO CLEANROOM
Cleanroom es un proceso de administración e
ingeniería para el desarrollo de software de alta
calidad con fiabilidad certificada.
Focaliza la atención en la prevención en lugar de
la corrección de errores y la certificación de la
fiabilidad del software para el entorno de uso
para cual fue planeado.
En lugar de realizar pruebas de unidades y
módulos, se especifican formalmente
componentes de software los cuales son

37. MODELO CLEANROOM

38. MODELO CLEANROOM
Este modelo tiene las siguientes características:
 Desarrollo incremental
 Especificación Formal
 Verificación Estática
 Pruebas Estadísticas.

39. MODELO CLEANROOM
Hay tres equipos involucrados en el proceso
cleanroom:
 Equipo de Especificación: Es responsable del
desarrollo y mantenimiento de las
especificaciones del sistema. Ambas
especificaciones son orientadas al cliente.
 Equipo de Desarrollo: Tiene la responsabilidad
de desarrollar y verificar el software.
 Equipo de Certificación: Es responsable del

40. VENTAJAS DEL USO DE
CLEANROOM
 Provee las prácticas de administración e
ingeniería que permiten a los equipos lograr
cero fallos en el campo de uso, cortos ciclos de
desarrollo y una larga vida del producto.
 Reduce los fallos encontrados durante el
proceso de certificación a menos de cinco fallos
por cada mil líneas de código en la primera
ejecución del código del primer proyecto.

41. VENTAJAS DEL USO DE
CLEANROOM
 Equipos nuevos deberían experimentar un
incremento del doble en la productividad con
respecto a su primer proyecto. La productividad
seguirá incrementándose con la experiencia
adquirida.
 Lleva una inversión en bienes tales como
especificaciones detalladas y modelos que
ayudan a mantener un producto viable durante
una vida mas larga.

42. MODELO CLEANROOM
Aplicación:
El método cleanroom es mandatorio para
cualquier sistema de software de misión crítica;
sin embargo es apto para cualquier proyecto de
software, en especial si el proyecto requiere
detección de errores en fases tempranas.

43. COMPARACIÓN ENTRE MODELOS