Las actividades típicas del ciclo de vida son:

1- Estudio de factibilidad :

Un resultado importante de la investigación preliminar es la determinación de que el

sistema solicitado sea factible. En la investigación preliminar existen tres aspectos

relacionados con el estudio de factibilidad. 

1. Factibilidad Técnica. El trabajo para el proyecto, ¿puede realizarse en el equipo

actual, la tecnología existente del software y el personal disponible? Si se necesita

nueva tecnología ¿cuál es la posibilidad de desarrollarla? 

2. Factibilidad Económica. Que los beneficios (tangibles e intangibles) y horros

superen a los costos; que los índices financieros que se calculen sean aceptables, de

acuerdo con políticas y estándares generales y específicos; que el proyecto tenga

contenido económico y esté contemplado en el presupuesto respectivo. 

Como mínimo deben calcularse las siguientes razones: 

a. Tasa Interna de Retorno. 

b. Valor Neto Presente.

c. Período de Recuperación.

d. Y, el total de los beneficios netos. 

Dependiendo de los resultados de este estudio se determinará si se continúa o no con el

proyecto. 

3. Factibilidad Operacional. Si se desarrolla e implanta, ¿será utilizado el sistema?,

¿existirá cierta resistencia al cambio por parte de los usuarios que de cómo resultado

una disminución de los posibles beneficios de la aplicación? 

El estudio de factibilidad lo lleva a cabo un pequeño equipo de personas (en ocasiones

una o dos) que está familiarizado con técnicas de sistemas de información; dicho equipo

comprende la parte de la empresa u organización que participará se verá afectada por el

proyecto y es gente experta en los procesos de análisis y diseño de sistemas. En general,

las personas que son responsables de evaluar la factibilidad son análisis capacitados o

directivos. 

2- Análisis (de requerimientos):

El aspecto fundamental del análisis de sistemas es comprender todas las facetas

importantes de la parte de la empresa que se encuentra bajo estudio. Los analistas, al

trabajar con los empleados y administradores, deben estudiar los procesos de una

empresa para dar respuesta a las siguientes preguntas: 

1. ¿Qué es lo que hace? 

2. ¿Cómo se hace? 

3. ¿Con qué frecuencia se presenta? 

4. ¿Qué tan grande es el volumen de transacciones o de decisiones? 

5. ¿Cuál es el grado de eficiencia con el que se efectúan las tareas? 

6. ¿Existe algún problema? 

7. Si existe un problema. ¿Qué tan serio es? 

8. Si existe un problema. ¿Cuál es la causa de lo que origina? 

Para contestar estas preguntas, el analista conversa con varias personas para reunir

detalles relacionados con los procesos de la empresa, sus opiniones sobre porque

ocurren las cosas, las soluciones que proponen y sus ideas para cambiar el proceso. Se

emplea cuestionarios para obtener esta información cuando no es posible entrevistar, en

forma personal, a los miembros de grupos grandes dentro de la organización. 

Así mismo, las investigaciones detalladas requieren el estudio de manuales y reportes,

la observación en condiciones reales de las actividades de trabajo y, en algunas

ocasiones, muestras de formas y documentos con el fin de comprender el proceso en su

totalidad. 

Conforme se reúnen los detalles, los analistas estudian los datos sobre requerimientos

con la finalidad de identificar las características que debe tener el nuevo sistema,

incluyendo la información que deben producir los sistemas junto con características

operacionales tales como controles de procesamiento, tiempos de respuesta y métodos

de entrada y salida. 

3- Diseño:

El diseño de un sistema de información produce los detalles que establecen 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 de desarrollo del software, a la que denominan diseño

físico. Los analistas de sistemas comienzan el proceso de diseño identificando los

reportes y demás salidas que debe producir el sistema. Hecho lo anterior se determinan

con toda precisión los datos específicos para cada reporte y salida. Es común que los

diseñadores hagan un bosquejo del formato o pantalla que esperan que aparezca cuando

el sistema esté terminado. Lo anterior se efectúa en papel o en la pantalla de una

terminal utilizando para ello algunas de las herramientas automatizadas disponibles para

el desarrollo de sistemas.

Los documentos que contienen las especificaciones de diseño representan a éste de

muchas maneras (diagramas, tablas y símbolos especiales). La información detallada

del diseño se proporciona al equipo de programación para comenzar la fase de

desarrollo de software .

Los diseñadores son los responsables de dar a los programadores las especificaciones de

software completas y claramente delineadas. Una vez comenzada la fase de

programación, los diseñadores contestan preguntas, aclaran dudas y manejan los

problemas que enfrentan los programadores cuando utilizan las especificaciones de

diseño

4.1- Creación de prototipos (modelos)

Qué es el Modelo Espiral?

Desarrollado por B. Boehm, básicamente, la idea es Desarrollo Evolutivo, usando el Modelo de Cascada para cada etapa; esta orientado a evitar riesgos de trabajo. No define en detalle el sistema completo a la primera. Los desarrollares deberían solamente definir las mas altas prioridades. Definir e implementarlas y entonces obtener un feedback de los usuarios (tal y como feedback distingue desarrollo "evolutivo" de "incremental"). Con este conocimiento, deberían entonces retroceder o volver al punto de partida para definir e implementar más y mejores partes.

El Modelo Espiral mejora el Modelo de Cascada enfatizando la naturaleza iterativa del proceso de diseño. Eso introduce un ciclo de prototipo iterativo. En cada iteración, las nuevas expresiones que son obtenidas transformando otras dadas son examinadas para ver si representan progresos hacia el objetivo.

Este método esta basado en dos importantes principios:

la practica de diseñó profesional es caracterizar en términos de conocer, actuar en situaciones, conversación con la situación y reflexión en acción. Hay un distinto medio de proceso - orientación en esta aproximación al diseño. Es raro que el diseñador tenga el diseño en su cabeza por adelantado y que después meramente lo transcriba. Gran parte del tiempo del diseñador esta inmiscuido en una progresiva relación con su entorno. Una buena metáfora para describirlo es "la conversación con el material", como un escultor, quien esta ocupado en una conversación con el medio. El escultor modela arcilla y luego mira y siente la escultura para ver lo que ha llegado a ser.

la necesidad para diseñadores de tomar la practica de trabajo seriamente, de supervisar las formas en las que el trabajo se esta haciendo, en el sentido de una solución abierta y desplegada para aumentar la complejidad de una situación que el diseñador solo entiende parcialmente. El hecho por el cual se esta tratando con "actores humanos". Los sistemas necesitan tratar o estar en contacto con las preocupaciones del usuario. Es, definitiva, el reconocimiento de que el trabajo es fundamentalmente social, envolviendo cooperación y comunicación.

Una visión general del Modelo de Cascada puede ser la siguiente:

4.2- Implementación

El objetivo de esta fase es realizar las actividades necesarias para poner a disposición de los usuarios el sistema de información.En primer lugar, se revisa la formulación del proyecto. Se estudia su alcance y, en función de sus características, se define un plan de implantación y se especifica quienes del Equipo de trabajo lo van a llevar a caboLas actividades previas al inicio de la producción incluyen la preparación de la infraestructura necesaria para configurar el entorno, la instalación de los componentes, la activación de los procedimientos manuales y automáticos asociados y, cuando proceda, la migración o carga inicial de datos. Para ello se toman como punto de partida los productos de software probados, obtenidos en la fase Construcción y Pruebas del Sistema de Información (CPS) y su documentación asociada.Conviene señalar que la implantación puede ser un proceso iterativo que se realiza de acuerdo al plan establecido para el comienzo de la producción del sistema en su entorno de operación. Para establecer este plan se tiene en cuenta:• El cumplimiento de los requerimientos de implantación definidos en el Catalogo de Requerimientos y especificados en la actividad Establecimiento de Requerimientos de Implantación (DSI 10)• La estrategia de transición del sistema antiguo al nuevo.Finalmente, se realizan las acciones necesarias para el inicio de la puesta en producción del sistema de información.

5 - Validación y prueba

Pruebas

El objetivo de estas pruebas es garantizar que el sistema ha sido desarrollado correctamente, sin errores de diseño y/o programación. Es conveniente que sean planteadas al menos tanto a nivel de cada módulo (aislado del resto), como de integración del sistema (según sea la naturaleza del proyecto en cuestión se podrán tener en cuenta pruebas adicionales, p.ej. de rendimiento).

Validación

Esta etapa tiene como objetivo la verificación de que el sistema desarrollado cumple con los

requisitos expresados inicialmente por el cliente y que han dado lugar al presente proyecto (para

esta fase también es interesante contar con los use cases, generados a través de las

correspondientes fases previas, que servirán de guía para la verificación de que el sistema

cumple con lo descrito por estos).

6 - Operación y mantenimiento:

Finalmente la aplicación resultante se encuentra ya en fase de producción (en funcionamiento

para el cliente, cumpliendo ya los objetivos para los que ha sido creada). A partir de este

momento se entra en la etapa de mantenimiento, que supondrá ya pequeñas operaciones tanto de

corrección como de mejora de la aplicación (p.ej. mejora del rendimiento), así como otras de

mayor importancia, fruto de la propia evolución (p.ej. nuevas opciones para el usuario debidas a

nuevas operaciones contempladas para el producto). 

La mayoría de las veces en que se desarrolla una nueva aplicación, se piensa sólamente en un

ciclo de vida para su creación, olvidando la posibilidad de que esta deba sufrir modificaciones

futuras (que tendrán que producirse con casi completa seguridad para la mayor parte de los

casos).