Presentación realizada para Sistema Académico a Distancia

1. REPUBLICA BOLIVARIANA DE VENEZUELA
MINISTERIO DEL PODER POPULAR PARA LA EDUCACION SUPERIOR
I.U.P “SANTIAGO MARIÑO”
MARACAIBO - ZULIA
MARACAIBO, AGOSTO DEL 2019
AUTOR:
MANUEL JIMENEZ
27.180.096
CARRERA: ING. DE SISTEMAS #47
CATEDRA: TEORIA DE LA INFORMACIÓN
SECCION: SAIA
TUTORA: PROF. MARIA MORÓN
CICLO DE VIDA DEL
SOFTWARE

2. I. CICLO DE VIDA DEL SOFTWARE
También denominado como el proceso del desarrollo de software, se trata de
una sucesión de distintas fases por las que atraviese un software durante su
desarrollo, desde el punto de partida donde se concibe la idea hasta el final del
ciclo donde el sistema se vuelve obsoleto. Cada una de estas fases o etapas está
asociada a una serie de actividades y tareas que se deben realizar, y a
documentos que serán la salida de cada una de estas fases y que fungirán de
entrada a la fase siguiente. .
Según la norma ISO (International Organization for Standardization): “Es un
marco de referencia que contiene los procesos, las actividades y las tareas
involucradas en el desarrollo, explotación y mantenimiento de un producto
software, abarcando la vida del sistema desde la definición de requisitos hasta
que se deja de utilizar”. .

3. II. ACTIVIDADES QUE SE PUEDEN LLEVAR A CABO DURANTE
EL CICLO DE VIDA DEL SOFTWARE
Como se indicó anteriormente, cada una de las fases que tiene cabida en el
ciclo de vida de un software contiene en sí misma una serie de procesos a realizar.
Estos pueden ser: .

4. Investigación
Preliminar
Sin importar cual sea la solicitud con la que se origina, el proceso se inicia siempre con la
petición de una persona .
Determinación de
los
Requerimientos
Comprender las facetas relevantes de la porción de la empresa que se encuentra bajo estudio.
Se debe dar respuesta a preguntas clave: ¿Qué es lo que hace?, ¿Cómo se hace?, ¿Con que
frecuencia se presenta?, ¿Cuál es el grado de eficiencia con el que se efectúan las tareas?,
¿Existe algún problema?, ¿Cuál es la causa que lo origina?, ect .
Diseño
Producir los detalles que determinan la forma en la que el sistema cumplirá con los
requerimientos identificados durante la fase de análisis. Los especialistas en sistemas se
refieren, con frecuencia, a esta etapa como diseño lógico en contraste con la del desarrollo
del software, a la que denominan diseño físico .
Desarrollo
Los encargados de desarrollar pueden instalar software comprobando a terceros o escribir
programas diseñados a la medida del solicitante. La elección depende del costo de cada
alternativa, del tiempo disponible para escribir el software y de la disponibilidad de los
programadores .
Pruebas
El sistema se emplea de manera experimental para asegurarse de que el software no posea
errores, es decir, que funciona de acuerdo con las especificaciones y en la forma en que los
usuarios esperan que lo haga. Se alimentan, como entradas, un conjunto de datos de prueba
para su procesamiento y después se examinan los resultados. .
Implantación
y evaluación
La implantación es la actividad de instalar nuevo equipo, entrenar a los usuarios, instalar la
aplicación y construir todos los archivos de datos necesarios para utilizarla. Una vez
instaladas, las aplicaciones pueden llegar a emplearse por un periodo indeterminado. Sin
embargo, las organizaciones y los usuarios cambian con el paso del tiempo. Por consiguiente,
es indudable que debe darse mantenimiento a las aplicaciones. La evaluación de un sistema
se lleva a cabo para identificar puntos débiles y fuertes. .
III. CICLO DE VIDA CLÁSICO DEL SOFTWARE

5. IV. PARADIGMAS DE LOS MODELOS DEL CICLO DE VIDA DEL SOFTWARE
Paradigma se utiliza en la vida cotidiana como sinónimo de “ejemplo” o para hacer referencia en caso de algo que
se toma como “modelo digno de seguir”. Con el tiempo, se han elaborado numerosos modelos distintos de desarrollo
de software. .
Paradigma Tradicional .
Hoy en día se tiene a disposición gran cantidad de metodologías del ciclo de vida de desarrollo de sistemas,
algunas de estas, como el modelo lineal, se encuentran chapadas a la vieja usanza, y se les conoce de igual forma
como paradigmas tradicionales. Lo que el modelo lineal indica es descomponer la actividad global del proyecto en
fases separadas independientes entre sí (que no generen retroalimentación, por más que puedan admitirse ciertos
supuestos de realimentación correctiva) y que se llevan a cabo linealmente, esto quiere decir que, cada una de estas
etapas se realiza una vez. .
Estos paradigmas razonablemente más sencillos que los actuales, se caracterizan por finalizar un proceso de
principio a fin antes de saltar al siguiente. Si bien se destaca como ventaja la sencillez de su gestión tanto económica
como temporal, puesto que acopla muy bien a proyectos internos muy pequeños de ABM, tienen como desventaja
principal que no son aptos para desarrollos que superen requerimientos de retroalimentación entre entapas, pues
resultaría muy costoso en cuanto a tiempo y dinero regresar a una fase anterior si se detecta alguna falla. Esto último
quiere decir que, se deberá pasar nuevamente por las etapas que el modelo ya ha pasado antes y reconstruir todo el
sistema de acuerdo a las alteraciones necesarias. .
Ejemplo del Modelo Lineal, que a pesar de la invención de nuevos modelos más eficientes, no ha sido desplazado
en su totalidad: .

6. Paradigma Orientado a Objetos .
Sin lugar a dudas, este paradigma presentado en los años 90’s del siglo pasado, se le
considera una de las mejores, fungiendo como un digno sustituto al arcaico paradigma
tradicional. Aquí, cada funcionalidad, o requerimiento solicitado por el usuario, es
considerado como un objeto. Así mismo, dichos objetos se encuentran representados por un
conjunto de propiedades, a las cuales se le denominan como atributos. Ejemplo:
.
.
Cabe destacar que, se le conoce muy buen por qué el código fuente de un proyecto se
puede llegar a reutiliza para otros proyectos relacionados más pequeños. También, se
caracteriza por la abstracción de los requerimientos del usuario, lo que permite analizar y
desarrollar atributos esenciales de un objeto y determinar tanto los costos finales del
proyecto como la duración del desarrollo del mismo, soportando mejor la incertidumbre que
paradigmas anteriores, aunque no garantizan la ausencia de los riesgos. .
.

7. Paradigma de Desarrollo Ágil
Son ciclos de vida evolutivos con iteraciones de corta duración (2 semanas a 2 meses)
para favorecer la comunicación entre clientes y usuarios. En cada iteración se incorporan
nuevas peticiones de clientes y usuarios (a esto se le conoce como requisitos).
.
A diferencia de anteriores
paradigmas, el cliente se ve
involucrado de principio a fin,
ya que es él el principal factor
de éxito, interaccionando
constantemente con el equipo
de desarrollo acerca de
procesos, herramientas y
negociaciones de contratos.
De igual manera, se halla especialmente preparado para cambios durante el proyecto,
dando respuestas a las alteraciones sobre el seguimiento de un plan. La regla a seguir es la
de no producir documentos a menos que sean necesarios de forma inmediata para tomar un
decisión importante, estos documentos deben ser cortos y centrarse en lo fundamental.
Además, considera más importante construir un buen equipo que construir el entorno, ya
que es mejor crear el equipo y que éste configure su propio entorno de desarrollo en base a
sus necesidades. .

8. V. CICLO DE VIDA DEL SOFTWARE EN LAS DISTINTAS METODOLOGÍAS
(MODELOS DE DESARROLLO)
El Modelo de desarrollo consiste en una representación abstracta de un proceso del software y/o estrategias de
desarrollo que ayudan a organizar las diferentes etapas y actividades del ciclo de vida del software. Así mismo, estos
modelos ayudan al control y a la coordinación del proyecto. Cabe acotar que, el modelo a utilizar depende del tipo de
proyecto. .
El Modelo de Cascada .
También llamado ciclo de vida básico o modelo lineal-secuencial, aunque admite iteraciones, es el modelo más
antiguo y más utilizado, que a servido como base para muchos otros modelos. Divide el proceso de desarrollo en un
conjunto de etapas secuenciales. Después de cada etapa, se realizan una o varias revisiones con el fin de comprobar si
se es posible pasar a la siguiente. De modo similar, una etapa no puede empezar hasta que no haya terminado la
anterior. Y al final de cada fase, el personal de desarrollo y los usuarios revisan el progreso del proyecto En cada fase se
genera todo un conjunto de documentos, de allí que se dice que es un modelo dirigido por documentos, puesto que son
los productos principales en cada etapa. .
.
Una de sus ventajas, aparte de ser el más fácil de planificar, es la de proveer un producto con un elevado grado de
calidad sin necesidad de un personal altamente calificado. No obstante, se debe tener en cuenta que no refleja
realmente el proceso de desarrollo del software, que se tarda mucho tiempo en pasar por todo el ciclo, y que perpetua el
fracaso de la industria del software en su comunicación con el usuario final. Además, los resultados se podrán apreciar
hasta que no se esté en las etapas finales, por lo que cualquier error detectado trae consigo un considerable retraso y
aumenta el desarrollo. .

9. Lo descrito en la figura, desglosado es: .
Análisis y Especificación de Requisitos: Especifica la información sobre la cual el software se va a desarrollar.
Diseño: Permite describir cómo el software va a satisfacer los requerimientos. .
Implementación: Aquí es donde el Software a ser desarrollado se codifica. .
Validación y verificación: Etapa donde el software es probado para verificar que es consistente con las definiciones.
Mantenimiento: Modificaciones al software producto de errores, adecuaciones, etc. .

10. El Modelo Por Prototipos .
En primer lugar, prototipo se define como una versión limitada del producto que permite a las partes responsables
de su creación probarlo en situaciones reales y explorar su uso. En segundo lugar, con este modelo hay un
acercamiento al cliente. Gracias al prototipo, el cliente puede hacerse una idea de cómo está evolucionando el
producto y esto ayuda a refinar los requisitos del sistema. Se suele aplicar a desarrollos en los que los requisitos no
están claros. .
Al término de cada ciclo, se entrega una
versión completa del software mejorada
respecto a la anterior. Si bien las primeras
versiones pueden ser prototipos no
satisfactorios, estos se desechan
posteriormente. Así mismo, los usuarios
deben evaluar el producto en cada iteración
y proponer mejoras. Los ciclos se repiten
hasta obtener un producto satisfactorio. Al
mismo tiempo, estos prototipos se pueden
usar como una herramienta para obtener y
validar los requisitos de clientes y usuarios
en cualquier ciclo de vida. Por ello, es
fundamental la implicación de los usuarios.
.
Las desventajas con las que se cuentan van desde el diseño rápido del prototipo hace que los desarrolladores
utilicen herramientas que faciliten la rápida generación de código, dejando a un lado aspectos de calidad
(eficiencia, fiabilidad, ect.), hasta la exigencia de disponer herramientas adecuadas. El primero de estos
inconvenientes provoca que probablemente no se obtenga un código óptimo. Sin embargo, se recomienda para
clientes que quieren ver resultados a corto plaza, para reducir costos y aumenta la probabilidad de éxito, cuando los
requisitos evolucionan muy rápidamente, y para sistemas on-line donde es más importante la parte de la interfaz
con el usuario que las funcionalidades del sistema. . .

11. El Modelo en Espiral .
Es un modelo evolutivo de desarrollo, formado por un conjunto de vueltas de espiral para ir ganando madurez en
el producto final. En cada iteración el proyecto se va completando. En las primeras vueltas el software es un modelo
en papel, la especificación de un producto. En las sucesivas vueltas, se desarrolla un prototipo. En las últimas
iteraciones se obtienen versiones completas del producto. Los ciclos se repiten hasta obtener un producto completo,
no si antes pasar por la evaluación del cliente, para ver si está de acuerdo, o no, con los resultados obtenidos. Si todo
va bien, se pasa a la siguiente fase. En la revisión participan todas las personas y organizaciones que tienen relación
con el producto. Después, se planifica la siguiente vuelta (Revisión de los recursos necesarios). Cabe resaltar que,
cada ciclo de la espiral representa una fase del proyecto software. En este modelo hay cuatro actividades que
envuelven a las etapas: .
» Definición de Objetivos. .
» Evaluación y reducción de riesgos. .
» Desarrollo y Validación. .
» Planificación. .
Al final de cada ciclo se entrega una versión
parcial del software incrementada con cierta
funcionalidad nueva respecto a las anteriores,
por consiguiente, la evaluación de cada fase
permite cambios. Los usuarios disponen antes
del software, aunque no sea completo y pueden
sugerir mejoras. Con este modelo se obtendrá el
producto final a partir de piezas más pequeñas.
La ventaja más notoria de este modelo de
desarrollo de software es que puede comenzarse
el proyecto con un alto grada de incertidumbre.
En virtud de esto, incorpora el factor Riesgo,
puesto que es un modelo orientado a riesgos, que
tiene como objetivo vital pensar en las cosas que
pueden ir mal en el desarrollo del software y
saber cómo resolverlas. .

12. El Modelo Incremental .
Este modelo se basa en la filosofía de construir incrementando las funcionalidades del programa. Se realiza
construyendo módulos que cumplen las diferentes funciones del sistema. Esto permite ir aumentando
gradualmente las capacidades del software. Es un tipo de modelo evolutivo, aunque también es iterativo, ya que:
» Permite a los ingenieros desarrollar versiones cada vez más completas .
» Combina elementos del modelo en cascada (aplicados repetidamente) con la filosofía interactiva de la
construcción de prototipos .
» Cada secuencia lineal produce un incremento. .
» Las entregas de los incrementos se definen al principio del proceso software. .
» Cada entrega constituye un producto operacional. .
Este ciclo de vida facilita la tarea del desarrollo, permitiendo que cada miembro del equipo elaborar un
modulo particular, en el caso de que el proyecto sea realizado por un equipo de programadores. Es útil cuando
el personal o los recursos no están disponibles hasta cierto tiempo dentro del proceso de desarrollo y se adapta a
entornos de alta incertidumbre. Pero lamentablemente, el proceso no es visible, la documentación es costosa y la
planificación resulta compleja. .

13. Este modelo de ciclo de vida no está pensado para cierto tipo de aplicaciones, sino a cierto tipo de usuarios o
clientes. Aún así, genera algunos beneficios en el desarrollo tales como si se detecta un error, sea grave o leve, sólo
se desechará la última iteración, y que es sencillo revelar los requerimientos del usuario, teniendo en cuenta que se
desarrollan las funcionalidades independientemente. En cuanto a los módulos, construir un sistema conformado por
subsistemas pequeños siempre es menos riesgoso que desarrollar un sistema enorme. .
Otros Modelos .
» Métodos formales (síntesis automática del Software). .
» Desarrollo orientado a la reutilización (basado en componentes). .
» DRA (Desarrollo Rápido de Aplicaciones). .
» Espiral WINWIN. .
» Desarrollo concurrente. .
» El Modelo en V. .
» Modelo Scrum. .