6.

CICLO DE VIDA DEL DESARROLLO DE SOFTWARE (SDLC)

Secuencia estructurada y bien definida de las etapas en Ingeniería de software para
desarrollar un producto donde en nuestro caso la finalidad es facilitar la información a la
comunidad universitaria de la Manuela Beltrán.

Actividades del SDLC: Aporta los pasos a seguir con la finalidad de diseñar y desarrollar
un producto software de manera eficiente el cual incluye:

Comunicación: El usuario hace la petición de un producto software determinado a un

proveedor y se negocia las condiciones, donde la finalidad es instalar puntos de
información para cada usuario según sus intereses y desempeño en la Universidad.

Recolección de solicitudes: De acuerdo a la solicitud del usuario el equipo de desarrollo

software inicia el proyecto, donde se consigue la máxima cantidad de información posible
sobre lo que requiere. 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 continuación

 Estudiando el software y el sistema actual u 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; donde se 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: Los desarrolladores trazan su plan, proyectan el mejor y más
conveniente modelo de software para el proyecto; el cual incluye: entendimiento de las
limitaciones del producto Software, aprendizaje de los problemas relacionados con el
sistema, cambios que se requieren en sistemas ya existentes, 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
donde en nuestro caso es la información a la comunidad universitaria la cual se clasifica de
la siguiente manera:

 Información general: Actividades culturales y extra-académicas de la Universidad por

cada una de las diferentes facultades.
 Información administrativa: Plazos de matrículas, fecha de exámenes, normativas y
avisos.
 Información privada: La cual variará según el tipo de usuario final que se identifique.
 Profesores: Información de los docentes de cada facultad y asignación académica.
 Alumnos: Información de la carrera que curse y su malla curricular.

Diseño de Software: Contempla el diseñar del producto de software con toda la

información recogida sobre requisitos y análisis para así iniciar con el diseño lógico y el
diseño físico, donde los ingenieros crean todo lo que requiere el software para su
funcionamiento en el campo real o utilidad a la población como son diagramas dilógicos,
diagramas de flujo de datos, y en algunos casos pseudocódigos; para lo cual se requiere un
sistema informático que pueda ser utilizado por.

 Administrador: Responsable inicial de la carga inicial de los puntos de información de

las diferentes facultades de la Universidad.
 Gestor: Encargado del funcionamiento o desconexión de cada punto de información.
 Operador: Responsable de verificar el funcionamiento global de la red de puntos con
la información.
 Usuarios finales: Conformado por los profesores y estudiosos de acuerdo a sus
solicitudes o servicios de información.

Codificación: “Fase de programación”. Se implementa el diseño de software con el

lenguaje de programación más conveniente, y desarrollando programas ejecutables y sin
errores de manera eficiente.

Pruebas: Se debe evaluar el 50% de todos los procesos de desarrollo de software ya que
los errores pueden arruinar el software a nivel crítico o incluso a eliminarlo lo cual hacen
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 corrección a tiempo es
la clave 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 que requiera para su buen funcionamiento.

Implementación: Es la instalación del software o instalación de configuraciones para el

consumidor final que en nuestro caso sería un sistema informático que facilite la
información a la comunidad universitaria.

Mantenimiento y Funcionamiento: Aquí se 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 tiempo, puede que el software falle en su ejecución, se vuelva obsoleto
o que necesite actualizaciones. Por lo tanto, se deben hacer los ajustes requeridos
eliminando, agregando o terminando el sistema según las necesidades.
7. MODELO DE DESARROLLO DE SOFWARE
Cascada: Llamado así por la posición de las fases en el desarrollo de esta, es el enfoque
metodológico que ordena rigurosamente las etapas del proceso para el desarrollo de
software, de tal forma que el inicio de cada etapa debe esperar la finalización de la etapa
anterior. Al final de cada etapa, el modelo está diseñado para llevar a cabo una revisión
final, que se encarga de determinar si el proyecto está listo para avanzar a la siguiente fase.
Fue el primero en originarse y es la base de todos los demás modelos de ciclo de vida.

Modelo repetitivo: 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. Primero se desarrolla en menor escala y se sigue teniendo en cuenta
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 software completo,
con más características y capacidad que los previos lo que permite facilidad para gestionar
el proceso de desarrollo, pero a la vez se consumen más recursos.
Espiral: Definido por Barry Boehm en 1986, utilizado generalmente en la Ingeniería de
software, es una combinación del repetitivo y del SDLC. Las actividades de este modelo se
conforman en una espiral, en la que cada bucle o iteración representa un conjunto de
actividades, las cuales no están fijadas a ninguna prioridad, sino que las siguientes se eligen
en función del análisis de riesgo, comenzando por el bucle interior. El modelo empieza
determinando los objetivos y las limitaciones del software al inicio de cada repetición. En
la siguiente etapa se crean los modelos de prototipo del software. Esto incluye el análisis de
riesgos. Luego un modelo estándar de SDLC se usa para construir el software. En la cuarta
etapa es donde se prepara el plan de la siguiente repetición.
Modelo V: Define un procedimiento uniforme para el desarrollo de productos para las TIC.
Es el estándar utilizado para los proyectos de la Administración Federal alemana y de
defensa. Como está disponible públicamente muchas compañías lo usan. Es un método de
gestión de proyectos comparable a PRINCE2 y describe tanto métodos para la gestión
como para el desarrollo de sistemas. El Modelo V aporta opciones de evaluación del
software en cada etapa de manera inversa; en cada etapa, se crea la planificación de las
pruebas y los casos de pruebas para verificar y validar el producto según los requisitos de la
etapa, permitiendo así, que tanto la verificación como la validación vayan en paralelo.

Prototipos: Pertenece a los modelos de desarrollo evolutivo; usando los programas

adecuados no se debe utilizar muchos recursos. El diseño se centra en una representación
de los aspectos del software que serán visibles para el cliente o el usuario final. El cual
conduce a la construcción de un prototipo y es evaluado por el cliente para una retro
alimentación; gracias a ésta se depuran los requisitos del software que se desarrollará. La
interacción ocurre cuando el prototipo se ajusta para satisfacer las necesidades del cliente,
permitiendo que al mismo tiempo el desarrollador entienda mejor lo que se debe hacer y el
cliente vea resultados a corto plazo.
Proceso unificado de desarrollo: Marco de trabajo extensible que puede ser adaptado a
organizaciones o proyectos específicos; por lo que muchas veces resulta imposible decir si
un refinamiento particular del proceso ha sido derivado del Proceso Unificado o del RUP.

Modelo Big Bang: Modelo con la forma más simple; requiere poca planificación, mucha
programación y muchos fondos ya que, si logramos reunir esto, quizá, podemos conseguir
el mejor producto de software. No es recomendable para grandes proyectos de software,
pero es bueno para aprender y experimentar.
8 DIMENSIONES DE LOS REQUERIMIENTOS
Los calificativos que se aplican al término requerimiento muestran distintos aspectos
ortogonales y se realiza un esfuerzo por agruparlos en tres dimensiones:

Ámbito: indica en qué ámbito se debe entender el requerimiento el debe cumplirse a nivel
sistema que se entiende como un conjunto de hardware y software.
Característica: clasifica los requerimientos en función de la naturaleza de la característica
del sistema deseado que se especifica y esta es:
1) Requerimientos funcionales.
2) Requerimientos de información: Información que debe almacenar el sistema por ser
relevante para las necesidades y objetivos de clientes y usuarios que en nuestro caso es la
información general, administrativa, privada, profesores y estudiosos de la Universidad
Manuela Beltrán.
3) Requerimientos no funcionales.
Audiencia: es la audiencia a la que está dirigido el requerimiento, es decir, las personas
que deben ser capaces de entenderlo y son:
1) Los clientes y usuarios, no tienen por qué tener formación en ingeniería de software
requerimientos-C como son los administrativos, docentes, estudiantes de las diferentes
facultades de la Universidad
2) Los desarrolladores de software requerimientos-D que en nuestro caso son el
departamento de investigación y desarrollo quienes elaboraran un sistema informático que
facilite la información a la comunidad de la Universidad.