Want to create interactive content? It’s easy in Genially!

Get started free

Ciclo de Vida del Software

María Arroyo Torrecilla

Created on March 18, 2024

Start designing with a free template

Discover more than 1500 professional designs like these:

Audio tutorial

Pechakucha Presentation

Desktop Workspace

Decades Presentation

Psychology Presentation

Medical Dna Presentation

Geometric Project Presentation

Transcript

Ciclo de Vida del Software

María Arroyo Torrecilla Mercedes Cayuela Barea

Índice

Ciclo de vida de desarrollo de software

Tipos de ciclo de vida

Etapas del ciclo de vida

Especificación de requisitos

Análisis

Diseño

Implementación

Pruebas, implantación y mantenimiento

Ciclo de vida de desarrollo de software

El ciclo de vida de una aplicación o proyecto informático es el conjunto de etapas y estados por los que pasa desde que se plantea como necesidad o problema, por parte del cliente, hasta que se da por terminado y se considera como una solución completa, correcta y estable. Las etapas del ciclo de vida son las siguientes:

Especificación de requisitos
Análisis
Diseño
Implementación
Instalación y mantenimiento
Pruebas

tipos de ciclo de vida

Aunque el ciclo de vida de un proyecto de desarrollo de software contiene las etapas que hemos visto anteriormente, la manera de llevarlas a cabo varía según cada proyecto, ello da lugar a distintos tipos de ciclos de vida. Los principales son:

Ciclo de vida en cascada con vuelta atrás

Ciclo de vida en espiral

Ciclo de vida clásico o en cascada

Ciclo de vida basado en prototipos

+ INFO

+ INFO

+ INFO

+ INFO

ETAPAS DEL CICLO DE VIDA

ESPECIFICACIÓN DE REQUISITOS

Definición del problema

OBJETIVOS:

Técnicas de definición del problema

  • Identificar las necesidades del cliente para definir el problema a resolver.
  • Se realiza un estudio de viabilidad económico y técnico para decidir si son factibles las posibilidades de realización.

Productos de la especificación de requisitos

Estudio der viabilidad

ANÁLISIS

Lo que se pretende es analizar las especificaciones dadas para obtener el problema más definido y más cercano a la solución final. Ahora nos centramos en QUÉ debe hacer el sistema.

ANÁLISI DE DATOS

ANÁLISIS DE PROCESOS

El modelo de procesos

El modelo de datos

Técnicas de análisis estructurado de procesos

Técnicas de análisis y especificación de datos

Diagrama de flujo de datos

Diccionario de datos

DISEÑO

El diseño se enfoca desde el punto de vista funcional y estático del sistema. La idea es transformar los modelos construidos durante el análisis en modelos de solución del problema.

DISEÑO DE DATOS

DISEÑO DE PROCESOS

En la fase de análisis se crea un Modelo Entidad/Relación Simplificado, enfocado en qué datos reflejar. En el diseño, se traduce a estructuras de datos manejables por ordenador. La idea es poder almacenar cada entidad con sus correspondientes atributos en estructuras de datos apropiadas. Según el dato, a almacenar, se optará por estructuras estáticas o dinámicas de datos.

Técnicas del diseño de procesos

Conexiones

Módulos

IMPLEMENTACIÓN

Implementación funcional del sistema

OBJETIVOS:

En esta etapa del ciclo de vida, el objetivo principal es la de construir dicha solución. Por tanto con la implementación se pretende:

  • Programar las funciones del sistema.
  • Crear y rellenar las estructuras de datos.
Como hemos observado en apartados anteriores, los diseños realizados son estructurados, por tanto, las técnicas de implementación que usaremos serán las de programación estructurada.

Implementación de los datos

Pruebas, implantación y mantenimiento

Pruebas del sistema

Implantación del sistema

Mantenimiento del sistema

+ INFO

+ INFO

+ INFO

Muchas Gracias

Ciclo de vida basado en prototipos

Un prototipo es un modelo inicial que se irá refinando en sucesivas pasadas, adaptándolo a las necesidades del cliente, hasta evolucionar en la solución definitiva. En la práctica, se parte de un modelo base inicial aproximado que con la ayuda y aportación del cliente y usuarios se va puliendo desarrollando así el prototipo según dichas especificaciones hasta completar el proyecto software.

Ciclo de vida clásico o en cascada

Es el modelo más simple en desarrollo de software. En él las etapas se llevan a cabo una detrás de otra de forma lineal. La naturaleza secuencial del modelo no permite volver atrás y deshacer o volver a hacer acciones. Son tres las fases en que se agrupan las etapas de este tipo de ciclo de vida: - Definición del problema - Desarrollo - Mantenimiento

Ciclo de vida en cascada con vuelta atrás

El ciclo de vida clásico o en cascada no siempre es la mejor opción a adoptar en el desarrollo de software, hay ocasiones en las que: - Una etapa del CV no puede ser completada por no poder detallar la definición del problema. - Las decisiones tomadas en etapas posteriores obligan a modificar otras ya dadas por terminadas o definitivas. - Pueden detectarse errores cometidos en etapas ya superadas. En estas situaciones podríamos considerar la posibilidad de volver atrás desde cualquier etapa, ello supone una mejora al ciclo de vida clásico.

Ciclo de vida en espiral

El tipo de ciclo de vida en espiral tiene en cuenta además de los aspectos técnicos, el factor riesgo. En este sentido, es un CV que intenta aprovechar las ventajas de los modelos anteriores pero dando importancia a los factores económicos.

  • Definir el ámbito y alcance del proyecto: tiene que quedar claro qué se debe resolver y qué queda fuera del alcance de dicho proyecto. Se deberán identificar los potenciales tipos de usuarios del sistema.
  • Identificar y definir requisitos: descomponiendo el problema principal en subproblemas que deben detallarse completamente. Para ello, se emplearán las técnicas que se especifican a continuación.

1. Entrevistas: es la técnica principal para identificar las necesidades del cliente y, por tanto, poder definir el problema. Consiste en realizar de forma presencial una serie de preguntas al cliente con el fin de recoger la máxima información. Tras finalizar la entrevista, se analizarán las respuestas y se extraerán las conclusiones oportunas. 2. Cuestionarios: a veces no podemos preguntar físicamente de forma directa al cliente, en estos casos la recoger la información se utiliza el cuestionario.

  • Requisitos funcionales: contienen aspectos relativos al comportamiento del sistema.
  • Requisitos no funcionales: contienen propiedades del sistema organizados en tres tipos:
- Restricciones: describen los límites del sistema.- De funcionamiento: especifican el hardware y software necesarios.- Manejo de excepciones: recogen los comportamientos anormales del sistema y sus tratamientos correspondientes.

Pasos a seguir: 1. Se considerarán las posibles alternativas que solucionen el problema. 2. Se evaluarán desde los puntos de vista técnico, económico y legal las diferentes alternativas consideradas. 3. Se realizará una toma de decisión para seleccionar la alternativa más adecuada.

El mantenimiento del sistema supone que este puede estar sujeto a cambios en su estructura, aspecto y funcionamiento durante todo el tiempo que se utilice. Estos cambios son la mejor forma para evitar que el sistema quede obsotelo y tenga que ser reemplazado.Tipos de cambios:

  • Depuración de errores
  • Cambios de requisitos
  • Mejoras y ampliaciones

Aquí se somete a cada módulo a una batería de pruebas, llamados planes de pruebas, para comprobar que todo funciona correctamente.Los tipos de pruebas se pueden clasificar:Según la forma en la que se realizan:

  • pruebas de caja negra
  • Pruebas de caja blanca
Según el momento de realización:
  • Pruebas unitarias
  • Pruebas de integración
  • Pruebas de subsistema y de sistema
  • Pruebas de carga
  • Pruebas de aceptación

Se habla de implantación del sistema las actividades que se realizan para instalar la aplicaciones en las máquinas del cliente y ponerlas en funcionamiento.En esta etapa hay que considerar la posibilidad de un periodo de transición o directamente implantar el sistema, para ello, se cuenta con recursos adicionales. Las últimas pruebas se realizar son necesarias para marcar el cierre del proyecto y considerar así el sistema implantado.

El modelo de procesos es la parte del análisis que recoge la perspectiva funcional de una aplicación. En él se especifica:- Qué procesos y subprocesos hay - Qué realiza cada proceso - Cómo se transforman los datos de entrada en datos de salida Se emplean las siguientes técnicas: - Diagrama de Flujo de Datos - Diccionario de Datos Además, contempla la existencia de entidades externas al sistema sistema relacionadas con él para realizar operaciones y obtener resultados.

Un Diagrama de Flujo de Datos (DFD) consta de 4 elementos principales:1. Procesos: Funciones del sistema identificadas por operaciones descritas en el Catálogo de Requisitos. Se representan como círculos con un nombre y número identificador. 2. Flujos de datos: Representan cómo los datos se mueven dentro del sistema. Se muestran con flechas y nombres descriptivos en minúsculas y en singular. 3. Almacenes: Representan datos en reposo dentro del sistema. Se muestran como nombres entre dos líneas horizontales y paralelas en mayúsculas y en plural. 4. Entidades externas: Usuarios externos del sistema que proporcionan entradas y reciben salidas. Se muestran como rectángulos con un nombre descriptivo en mayúsculas y en singular.

Para recoger las definiciones de los datos manejados en el sistema se usa el diccionario de datos. Se denominan entradas las definiciones contenidas en el DD, y se clasifican en:- Simples: se definen indicando el tipo de dato que representan o enumerando los posibles valores que toman. - Compuestas: se definen indicando los elementos que la componen y la forma en que están combinados.

Un dato es aquella información que la aplicación debe recordar.Así, el modelo de datos refleja la parte estática de la aplicación. Haremos uso de las estructuras de datos para llevar a cabo el modelo de datos, siempre proyectos informáticos profesionales.

Las Bases de Datos Relacionales son usadas para el análisis y la gestión de la información. Estas usan para sus análisis la técnica llamada Modelo Entidad/Relación. Los elementos que forman el modelo E/R simplificado son:- Entidades: son objetos reales o abstractos, de los cuales se quiere obtener información. Pueden ser tangibles o intangibles. Se representan con rectángulos con su nombre dentro. - Atributos: son propiedades asociadas a las entidades, divididos en identificadores descriptores.

  • Un módulo es un programa o subprograma, que puede ser llamado independientemente.
  • Un componente software que admite parámetros de entrada y puede devolver parámetros de salida
  • Un proceso que convierte datos de entrada en datos de salida
Las características del módulo son:
  • Pequeño tamaño
  • Interfaz clara
  • Independencia
  • Máxima cohesión interna

Una conexión entre dos módulos representa la llamada que uno de ellos hacia otro, para que éste ejecute alguna función para él. Se representa por una línea que une al módulo llamador con el módulo llamado. Estructuras de control básicas:

  • Secuencia o iteración
  • Alternativa o bifurcación
  • Bucle o repetición

Consiste en la programación de todas las funciones identificadas y diseñadas. se utiliza el lenguaje pseudocódigo. La técnica de resolución de problemas "divide y vencerás" es la base para construir funciones estructuradas. Tipos de instrucciones: - iterativas - alternativas - repetitivas Tipos de datos: - constantes y variables - datos predefinidos y definidos - dados simples y compuestos - datos estáticos y dinámicos

Implica además de la definición Formal de cada tipo de dato, a considerar, las operaciones básicas, que se pueden hacer sobre ellos, como la creación; lectura; escritura; modificación y borrado.