Etapas del ciclo de vida de una aplicación informática

Share Button

Pto1: Sistemas informáticos, son grandes y complejos. Se hace necesario disponer de: Tiempo y recursos materiales suficientes, lo que obliga a planificar previamente el trabajo a desarrollar. Un equipo de informáticos especializados y jerarquizados (jefes de proyecto, analistas, programadores, etc). Una serie de métodos o técnicas de resolución de problemas para desarrollar los distintos pasos a seguir en todo el proceso de desarrollo del sistema, esto es, el desarrollo de un software apropiado.La ingeniería del software, es convertir el proceso artesanal de construcción de programas informáticos en una ingeniería, para así producir software industrial en serie y de calidad.

Ciclo de vida del Software

Las principales etapas del CV son las siguientes:

Especificación de requisitos

El objetivo es conocer el problema a resolver (carácterísticas, detalles, limitaciones, etc). Una vez concluida se puede estimar el coste del proyecto. 

Análisis



El problema principal se descompone en partes, obteniendo una serie de subproblemas más pequeños y abordables. En esta etapa nos centramos en el QUÉ y no en el CÓMO, esto es, identificar qué funciones realiza el sistema sin entrar en detalle.


Diseño


Para los subproblemas identificados en la fase de análisis se buscan soluciones para posteriormente integrarlas en una solución global. Ahora el interés está en el CÓMO y no en el QUÉ, describiendo cada subproblema obtenido en la etapa de análisis. 

Implementación



En esta etapa se codifica, según uno o varios lenguajes de programación, la solución diseñada. 

Pruebas

Se comprueba el funcionamiento de la aplicación respetando los requisitos y necesidades fijados con el cliente. 

Instalación y mantenimiento

Puesta en funcionamiento en su entorno real.

Ciclo de vida 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, así sólo cuando la primera fase se termina se puede empezar con la segunda, y así progresivamente. La naturaleza secuencial del modelo no permite volver atrás y deshacer o volver a hacer acciones.

Ciclo de vida en cascada con vuelta atrás

El ciclo de vida 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. En una situación así, es necesario dejar dicha etapa sin terminar y pasar a las siguientes, para regresar más tarde a completarla.Las decisiones tomadas en etapas posteriores obligan a modificar otras ya dadas por terminadas o definitivas.

Ciclo de vida basado en prototipos


El problema de no poder completar una etapa por no poder detallar o definir alguna de las partes de dicho problema, puede suponer una gran dificultad para desarrollar una solución definitiva. Los llamados prototipos surgen con la idea ayudar en este sentido.
Un prototipo es un modelo inicial (no la solución final) 
que se irá refinando en sucesivas pasadas, adaptándolo a las necesidades del cliente, hasta evolucionar en la solución definitiva.

Ciclo de vida en Espiral

 El tipo de ciclo de vida en espiral tiene en cuenta el factor riesgo.
Es un CV que intenta aprovechar las ventajas de los modelos anteriores pero dando importancia a los factores económicos.
El CV se divide en cuatro grandes etapas: planificación, análisis de riesgos, ingeniería y evaluación. 
En cada etapa se va pasando de forma circular y creciente a la siguiente, así en cada paso es preciso valorar y considerar más recursos y trabajo (tiempo, dinero, recursos humanos, etc) para acercarse a la solución final.


Pto 2:

Especificación de Requisitos. Definición del problema:

Para intentar resolver el problema planteado en nuestra aplicación previamente es necesario definirlo detalladamente:1.

Definir el ámbito y alcance del proyecto

: de acuerdo con el cliente, debe quedar claro qué se debe resolver y qué queda fuera del alcance de dicho proyecto. Además, se deberán identificar los potenciales tipos de usuarios del sistema.2:

Identificar y definir requisitos

: descomponiendo el problema principal en subproblemas que deben detallarse completamente. Para conseguir esto, se emplearán las técnicas que se especifican a continuación.

Técnicas de definición del problema: Entrevistas:

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.

Cuestionarios:

Se hace necesario emplear un estilo de redacción directo y con un lenguaje claro, que no dé lugar a especulaciones o malentendidos en las preguntas. Productos de la especificación de requisitos.


En el Catálogo de Requisitos se recogen de una forma organizada dos tipos de requisitos:

funcionales

Contienen aspectos relativos al comportamiento del sistema.

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.

Estudio de viabilidad

Los pasos  en líneas generales: 1: Se considerarán las posibles alternativasque solucionen el problema. 2: Se evaluarándesde los puntos de vista técnico, económico y legal las diferentes alternativas consideradas. 3: Se realizará una toma de decisión para seleccionarla alternativa más adecuada.

Pto4:

Diseño

La idea es transformar los modelos construidos durante el análisis en modelos de solución del problema. Así hablaremos de diseño funcional y diseño de datos.En un lenguaje más formal los objetivos del diseño son: 1.Pasar de preguntarse ¿QUÉ hay que hacer? A ¿CÓMO hay que hacerlo?. 2.Obtener una solución correcta. 3.Preparar el camino a la implementación.

La principal técnica usada en el diseño de procesos es Diagramas de Cuadros de Constantine.


Pto3:

Análisis

Nos centramos en QUÉ debe hacer el sistema.El objetivo del Análisis es entender el problema identificando las necesidades del cliente y las restricciones que se deben cumplir. Para ello se deberá:Organizar la información del problema y mostrarlo en un formato gráfico más intuitivo y fácil de manejar.Depurar todo aquello que no interesa y concentrarse en lo que debe hacer el sistema.Resolver posibles conflictos. Dividir el problema principal en subproblemas más fáciles de resolver.

En toda aplicación informática se distinguen principalmente dos partes: los procesos y los datos.

Los procesos son la parte funcional de la aplicación. Reflejan las funciones que debe realizar la aplicación.

 Los datos son la parte estática de la aplicación. Se refieren a la información que se necesita almacenar.

En un lenguaje coloquial, los procesos dicen qué hay que hacer y los datos indican con qué hay que hacerlo. Como resultado del análisis, se obtendrán:

El Modelo de Procesos
: recoge qué funciones, actividades, tareas, acciones, debe realizar la aplicación y cómo manejar los datos.

El Modelo de Datos
: describe la información que maneja la aplicación, los datos que debe almacenar y muestra cómo organizarla

Share Button

Deja una respuesta

Tu dirección de correo electrónico no será publicada.

Este sitio usa Akismet para reducir el spam. Aprende cómo se procesan los datos de tus comentarios.