República Bolivariana De Venezuela
Ministerio Del Poder Popular Para La Defensa
Universidad Nacional Experimental Politécnica De la Fuerza Armada



Introducción

Elpresente trabajo se realizo con la finalidad de darnos a conocer lo que seria los ciclos de vida del sistema dentro de una organización o una empresa y a su ves como funciona este tipo de gerencia en las empresa con lo que ya habíamos visto en materias como analisis y diseño y ahora su funcionalidad ya como organización; tenemos los diferentes conceptos y explicaciones de cómo trabaja ese modelo en una gerencia y del como nos puede ayudar para futuros gerentes en el area de tecnología o de sistemas.


Todo sistema tiene un tiempo de vida útil mediante el cual su funcionalidad se vuelve obsoleta por los grandes avances de la tecnología. Como por ejemplo en los sistemas de información computarizados que entran en la definición de software, el cual nos dice que
El Software son las instrucciones electrónicas que van a indicar al ordenador que es lo que tiene que hacer. También se puede decir que son los programas usados para dirigir las funciones de un sistema de computación o un hardware.
El modelo de ciclo de vida de los sistemas es aquel proceso por el cual los analistas de sistemas, ingenieros de software, programadores etc. Elaboran los sistemas de información y las aplicaciones informaticas.

Los Objetivos del Ciclo de vida de los sistemas son:
* Definir las actividades a ser ejecutadas en un proyecto de procesamiento electrónico de datos
* Introducir coherencia de en proyecto de PED de la misma organización.
* Establecer punto de control de la gerencia para establecer si se debe continuar o no.

El ciclo de vida de los sistemas debe constar de los siguientes aspectos

Técnica:
*Método que aplica herramientas y reglas especificas para completar una o mas fases del desarrollo del ciclo de vida del sistema.
* Se aplican a una parte del ciclo de vida total

Metodología
Versión amplia y detallada de un ciclo de vida completo de desarrollo de sistemas que incluye:

* Reglas, Procedimientos, Métodos y herramientas
* Funciones individuales y en grupo por cada tarea
* Productos Resultantes
* Normas de Calidad.

Etapas principales a realizar en cualquier ciclo de vida
Entre los tipos de técnicas las cuales nos ayudan a realizar los modelos de ciclo de vida de los sistemas los cuales ayudan al desarrollo de un software son los siguientes
1. Analisis: Construye un modelo de los requisitos.
2. Diseño: A partir del modelo de analisis se deducen las estructuras de datos, la estructura en la que descompone el sistema y la interfaz de usuario.
3. Codificación: Construye el sistema. La salida de esta fase es código ejecutable.
4. Pruebas: Se comprueba que se cumplen criterios de corrección y calidad.
5. Mantenimiento: En esta fase, que tiene lugar después de la entrega se asegura que el sistema siga funcionando y adaptandose a nuevos requisitos.

Sistemas de Información

Es un conjunto de subsistemas que incluyen hardware, software, medios de almacenamiento de datos ya sea primarios, secundarios y bases de datos relacionadas entre sí con el fin de procesar entradas para realizar transformaciones a esas entradas y convertirlas en salidas de información importantes en la toma de decisiones.
El objetivo de un sistema de información esayudar al desempeño de las actividades que desarrolla la empresa, suministrando la información adecuada, con la calidad requerida, a la persona o departamento que lo solicita, en el momento y lugar especificados con el formato mas útil para el receptor.

Etapas del Ciclo de vida de un Sistema Clasico

1. Investigación Preliminar
2. Determinación de los requerimientos del sistema.
3. Diseño del sistema
4. Desarrollo de software.
5. Prueba de los sistemas.
6. Implantación y evaluación.

Ciclo de vida de un Sistema Clasico.
El ciclo de vida de un sistema clasico le permite a los programadores, diseñadores, analistas, entre otros especialistas, crear un sistema eficiente para la resolución de un problema dado, por medio de fases de analisis y diseño que sostienen que los sistemas son desarrollados de mejor manera mediante el uso de un ciclo especifico de actividades del analista y del usuario. Existen tres estrategias para el desarrollo de sistemas: el método clasico del ciclo de vida de desarrollo de sistemas, el método de desarrollo por analisis estructurado y el método de construcción de prototipos de sistemas. Cada una de estas estrategias tiene un uso amplio en cada una de los diversos tipos de empresas que existen, y resultan efectivas si son aplicadas de manera adecuada. 

Investigación Preliminar:
La investigación preliminar consiste en realizar la solicitud para recibir ayuda de un sistema que solucionara un problema que existe en la organización. Esta solicitud puede surgir para el desarrollo de un nuevo sistema, la mejora de uno existente o laincorporación de un nuevo requerimiento. Cuando esta se formula, es cuando comienza la primera actividad del sistema que consta de tres partes:

* Aclaración de la solicitud
Primero que cualquier otra investigación de sistemas, es necesario que se examine la solicitud detalladamente para determinar con precisión lo que el solicitante desea para ir estableciendo los límites del mismo y que no haya futuras confusiones.

* Estudio de factibilidad
Un resultado importante de la investigación preliminar es la determinación de que el sistema requerido es factible. Existen tres aspectos, que son realizados por lo general por analistas capacitados o directivos:

* Factibilidad económica.
Investiga si los costos se justifican con los beneficios que se obtienen, y si se ha invertido demasiado, como para no crear el sistema si se cree necesario.
Se debe tomar en cuenta los siguientes puntos:
* El costo para desarrollar el sistema.
* El costo de Hardware y Software.
* El costo del sistema puesto en producción.

* Factibilidad técnica.
El analisis se centra en determinar basicamente si es posible desarrollar el proyecto.
Este evalúa si el equipo  y software estan disponibles (o, en el caso del software, si puede desarrollarse) y si tienen las capacidades técnicas requeridas por cada alternativa del diseño que se esté considerando.
Los estudios de factibilidad técnica también consideran si la organización tiene el personal que posee la experiencia técnica requerida para diseñar, implementar, operar y mantener el sistema propuesto. Si el personal no tiene esta experiencia, puede entrenarsele opueden emplearse nuevos o consultores que la tengan. Sin embargo, una falta de experiencia técnica dentro de la organización puede llevar al rechazo de una alternativa particular.


* Factibilidad operacional.
Esta factibilidad comprende una determinación de la probabilidad de que un nuevo sistema se use como se supone. Se debe tomar en cuenta también lo siguiente
a. Existe apoyo para el proyecto por parte de la dirección superior.
b. El sistema propuesto causara perjuicios, tendra resultados no deseados en algún area, se perdera el control de alguna area, se perdera el acceso de la información
c. Habra resistencia al cambio. Un nuevo sistema puede ser demasiado complejo para los usuarios de la organización o los operadores del sistema. Si lo es, los usuarios pueden ignorar el sistema o bien usarlo en tal forma que cause errores o fallas en el sistema.
d. Reducira la productividad de otras areas.

2) Determinación de los requerimientos del sistema
Los analistas, al trabajar con los empleados y administradores, deben investigar todos los procesos de la empresa para dar respuestas a preguntas claves, tales como:

* ¿Qué es lo que hace?
* ¿Cómo se hace?
* ¿Con que frecuencia se presenta?
* ¿Qué tan grande es el volumen de transacciones o decisiones?
* ¿Cual es el grado de eficiencia con el que se efectúan las tareas?
* ¿Existe algún problema? ¿Qué tan serio es? ¿Cual es la causa que lo origina?

Para contestar estas preguntas, el analista conversa con varias personas para reunir detalles relacionados con los procesos de la empresa. Cuando no esposible entrevistar, en forma personal a los miembros de grupos grandes dentro de la organización, se emplean cuestionarios para obtener esta información.
Reunidos los detalles, los analistas estudian los datos sobre requerimientos con la finalidad de identificar las características que debe tener el nuevo sistema.

3) Diseño del sistema:
El diseño de un sistema de información produce los elementos que establecen cómo el sistema cumplira los requerimientos indicados durante el analisis de sistemas. 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.

a) Diseño del sistema (diseño lógico
El diseño de un sistema de información responde a la forma en la que el sistema cumplira con los requerimientos identificados durante la fase de analisis.
Es común que los diseñadores hagan un esquema del formato o pantalla que esperan que aparezca cuando el sistema esta terminado, se realiza en papel o en la pantalla de una terminal utilizando algunas de las herramientas automatizadas disponibles para el desarrollo de sistemas.
También se indican los datos de entrada, los que seran calculados y los que deben ser almacenados. Los diseñadores seleccionan las estructuras de archivo y los dispositivos de almacenamiento. Los procedimientos que se escriben indican cómo procesar los datos y producir salidas.
Los documentos que contienen las especificaciones de diseño representan a éste mediante diagramas, tablas y símbolos especiales.
La información detallada del diseño se proporciona al equipo deprogramación para comenzar la fase de desarrollo de software.
Los diseñadores son responsables de dar a los programadores las especificaciones de software completas y claramente delineadas.

4) Desarrollo del software:
Los encargados de desarrollar software 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.
Por lo general, los programadores que trabajan en las grandes organizaciones pertenecen a un grupo permanente de profesionales.

a) Desarrollo de software (diseño físico).
Los programadores son responsables de la documentación de los programas y de explicar su codificación, esta documentación es esencial para probar el programa y hacer el mantenimiento.

5) Prueba de sistemas:
Durante esta fase, el sistema se emplea de manera experimental para asegurarse que el software no tenga fallas, 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 conjuntos de datos de prueba para su procesamiento y después se examinan los resultados. En ocasiones se permite que varios usuarios utilicen el sistema, para que los analistas observen si tratan de emplearlo en formas no previstas, antes de que la organización implante el sistema y dependa de él.

6) Implantación y evaluación

La implantación es el proceso de verificar e instalar nuevo equipo, entrenar a los usuarios, instalar la aplicación y construir todos losarchivos de datos necesarios para utilizarla. Sin importar cual sea la estrategia utilizada, los encargados de desarrollar el sistema procuran que el uso inicial del sistema se encuentre libre de problemas. Una vez instaladas, las aplicaciones se emplean durante muchos años. Sin embargo, las organizaciones y los usuarios cambian con el paso del tiempo, incluso el ambiente es diferente con el paso de las semanas y los meses. Los sistemas de información deben mantenerse siempre al día, la implantación es un proceso de constante evolución.

Ciclo De Vida De Los Sistemas De Software
El ciclo de vida de los sistemas de software se puede explicar atendiendo a diferentes modelos, como es:

* Clasico o convencional (Cascada)
* Ciclo de vida en V
* Sashimi
* Incremental
* Prototipo
* Evolutiva
* Espiral
* Orientado a objetos

Para iniciar nuestro estudio sobre la necesidad de elaborar documentación comentemos el ciclo de vida clasico, ya que a partir de él podemos explicar las variantes de ciclos de desarrollo, como el orientado a objetos que veremos al final.

Ciclos de vida en cascada

El ciclo de vida inicialmente propuesto por Royce en 1970, fue adaptado para el software a partir de ciclos de vida de otras ramas de la ingeniería. Es el primero de los propuestos y el mas ampliamente seguido por las organizaciones (se estima que el 90% de los sistemas han sido desarrollados así). La estructura se muestra en la siguiente figura:
|
Ciclo de vida en cascada |

Descripción:

Este modelo admite la posibilidad de hacer iteraciones, es decir, durante las modificaciones que se hacenen el mantenimiento se puede ver por ejemplo la necesidad de cambiar algo en el diseño, lo cual significa que se haran los cambios necesarios en la codificación y se tendran que realizar de nuevo las pruebas, es decir, si se tiene que volver a una de las etapas anteriores al mantenimiento hay que recorrer de nuevo el resto de las etapas.
Después de cada etapa se realiza una revisión para comprobar si se puede pasar a la siguiente.
Trabaja en base a documentos, es decir, la entrada y la salida de cada fase es un tipo de documento específico. Idealmente, cada fase podría hacerla un equipo diferente gracias a la documentación generada entre las fases. Los documentos son:
* Analisis: Toma como entrada una descripción en lenguaje natural de lo que quiere el cliente. Produce el S.R.D. (Software Requirements Document).
* Diseño: Su entrada es el S.R.D. Produce el S.D.D. (Software Design Document)
* Codificación: A partir del S.D.D. produce módulos. En esta fase se hacen también pruebas de unidad.
* Pruebas: A partir de los módulos probados se realiza la integración y pruebas de todo el sistema. El resultado de las pruebas es el producto final listo para entregar.

Ventajas
* La planificación es sencilla.
* La calidad del producto resultante es alta.
* Permite trabajar con personal poco cualificado.

Inconvenientes
* Lo peor es la necesidad de tener todos los requisitos al principio. Lo normal es que el cliente no tenga perfectamente definidas las especificaciones del sistema, o puede ser que surjan necesidades imprevistas.
* Si se han cometido errores en una fase esdifícil volver atras.
* No se tiene el producto hasta el final, esto quiere decir que:
* Si se comete un error en la fase de analisis no lo descubrimos hasta la entrega, con el consiguiente gasto inútil de recursos.
* El cliente no vera resultados hasta el final, con lo que puede impacientarse.
* No se tienen indicadores fiables del progreso del trabajo (síndrome del 90%).
* Es comparativamente mas lento que los demas y el coste es mayor también.

Tipos de proyectos para los que es adecuado:
* Aquellos para los que se dispone de todas las especificaciones desde el principio, por ejemplo, los de reingeniería.
* Se esta desarrollando un tipo de producto que no es novedoso.
* Proyectos complejos que se entienden bien desde el principio.
Como el modelo en cascada ha sido muy popular ha generado algunas variantes. Ahora veremos algunas.

Ciclo de vida en V

Propuesto por Alan Davis, tiene las mismas fases que el anterior pero se considera el nivel de abstracción de cada una. Una fase ademas de utilizarse como entrada para la siguiente, sirve para validar o verificar otras fases posteriores. Su estructura esta representada en la figura 2.
|
Ciclo de vida en V |

Ciclo de vida tipo Sashimi

Según el modelo en cascada puro una fase solo puede empezar cuando ha terminado la anterior. En este caso sin embargo, se permite un solapamiento entre fases. Por ejemplo, sin tener terminado del todo el diseño se comienza a implementar. El nombre ``sashimi'' deriva del modo del estilo de presentación de rodajas de pescado crudo en Japón. Una ventaja de este modelo esque no necesita generar tanta documentación como el ciclo de vida en cascada puro debido a la continuidad del mismo personal entre fases. Los problemas planteados son:
* Es aún mas difícil controlar el progreso del proyecto debido a que los finales de fase ya no son un punto de referencia claro.
* Al hacer cosas en paralelo si hay problemas de comunicación pueden surgir inconsistencias.
La fase de ``concepto'' consiste en definir los objetivos del proyecto, beneficios, tipo de tecnología y el tipo de ciclo de vida. El diseño arquitectónico es el de alto nivel, el detallado el de bajo nivel. En la figura 3 se ha representado la estructura del ciclo de vida Sashimi.

|
Ciclo de vida Sashimi |

Ciclo de vida en cascada incremental

En este caso se va creando el sistema añadiendo pequeñas funcionalidades. Cada uno de los pequeños incrementos es parecido a lo que ocurre dentro de la fase de mantenimiento. La ventaja de este método es que no es necesario tener todos los requisitos en un principio. El inconveniente es que los errores en la detección de requisitos se encuentran tarde.
Hay dos partes en el ciclo de vida, similares al anterior. Por un lado esta el analisis y el diseño global. Por otra parte estan los pequeños incrementos, con las fases de diseño detallado, codificación y mantenimiento. En la figura 4 se puede ver su estructura.
|
Cascada incremental |

Modelo de prototipos

En Ingeniería de software El Modelo de prototipos que pertenece a los modelos de desarrollo evolutivo, El prototipo debe ser construido en poco tiempo, usando los programas adecuados y no se debe utilizarmucho dinero pues a partir de que éste sea aprobado nosotros podemos iniciar el verdadero desarrollo del software.
El diseño rapido se centra en una representación de aquellos aspectos del software que seran visibles para el cliente o el usuario final. Este diseño conduce a la construcción de un prototipo, el cual es evaluado por el cliente para una retroalimentación; gracias a ésta se refinan los requisitos del software que se desarrollara. La interacción ocurre cuando el prototipo se ajusta para satisfacer las necesidades del cliente. Esto permite que al mismo tiempo el desarrollador entienda mejor lo que se debe hacer y el cliente vea resultados a corto plazo.

Etapas
* Plan rapido
* Modelado, diseño rapido
* Construcción del Prototipo
* Desarrollo, entrega y retroalimentación
* Comunicación
Ventajas
* Este modelo es útil cuando el cliente conoce los objetivos generales para el software, pero no identifica los requisitos detallados de entrada, procesamiento o salida.
* También ofrece un mejor enfoque cuando el responsable del desarrollo del software esta inseguro de la eficacia de un algoritmo, de la adaptabilidad de un sistema operativo o de la forma que debería tomar la interacción humano-maquina.
La construcción de prototipos se puede utilizar como un modelo del proceso independiente, se emplea mas comúnmente como una técnica susceptible de implementarse dentro del contexto de cualquiera de los modelos del proceso expuestos.
Sin importar la forma en que éste se aplique, el paradigma de construcción de prototipos ayuda al desarrollador de software y al cliente a entender demejor manera cual sera el resultado de la construcción cuando los requisitos estén satisfechos. De esta manera, este ciclo de vida en particular, involucra al cliente mas profundamente para adquirir el producto.
Inconvenientes
* El usuario tiende a crearse unas expectativas cuando ve el prototipo de cara al sistema final. A causa de la intención de crear un prototipo de forma rapida, se suelen desatender aspectos importantes, tales como la calidad y el mantenimiento a largo plazo, lo que obliga en la mayor parte de los casos a reconstruirlo una vez que el prototipo ha cumplido su función. Es frecuente que el usuario se muestre reacio a ello y pida que sobre ese prototipo se construya el sistema final, lo que lo convertiría en un prototipo evolutivo, pero partiendo de un estado poco recomendado.
* En aras de desarrollar rapidamente el prototipo, el desarrollador suele tomar algunas decisiones de implementación poco convenientes (por ejemplo, elegir un lenguaje de programación incorrecto porque proporcione un desarrollo mas rapido). Con el paso del tiempo, el desarrollador puede olvidarse de la razón que le llevó a tomar tales decisiones, con lo que se corre el riesgo de que dichas elecciones pasen a formar parte del sistema final.

Evolutivo
Se diferencia del modelo por prototipos en que en prototipos se da por hecho que aunque se necesiten varias iteraciones para lograrlo al final se llegara a tener una serie de requisitos completos y sin errores, que no vayan a cambiar mas.
En el modelo evolutivo se asume que los requisitos pueden cambiar en cualquier momento del ciclo de vida y no solo en laetapa de analisis.

Modelo de ciclo de vida en espiral
Propuesto inicialmente por Boehm en 1988. Consiste en una serie de ciclos que se repiten. Cada uno tiene las mismas fases y cuando termina da un producto ampliado con respecto al ciclo anterior. En este sentido es parecido al modelo incremental, la diferencia importante es que tiene en cuenta el concepto de riesgo. Un riesgo puede ser muchas cosas: requisitos no comprendidos, mal diseño, errores en la implementación, etc. Una representación típica de esta estructura se muestra a continuación:
|
Ciclo de vida en espiral |
En cada iteración Boehm recomienda recopilar la siguiente lista de informaciones:
* Objetivos: Se hacen entrevistas a los clientes, se les hace rellenar cuestionarios, etc.
* Alternativas: Son las diferentes formas posibles de conseguir los objetivos. Se consideran desde dos puntos de vista
* Características del producto.
* Formas de gestionar el proyecto.
* Restricciones:
* Desde el punto de vista del producto: Interfaces de tal o cual manera, rendimiento, etc.
* Desde el punto de vista organizativo: Coste, tiempo, personal, etc.
* Riesgos: Lista de riesgos identificados.
* Resolución de riesgos: La técnica mas usada es la construcción de prototipos.
* Resultados: Son lo que realmente ha ocurrido después de la resolución de riesgos.
* Planes: Lo que se va a hacer en la siguiente fase.
* Compromiso: Decisiones de gestión sobre como continuar.
Al terminar una iteración se comprueba que lo que se ha hecho efectivamente cumple con los requisitos establecidos, tambiénse verifica que funciona correctamente. El propio cliente evalúa el producto. No existe una diferencia muy clara entre cuando termina el proyecto y cuando empieza la fase de mantenimiento. Cuando hay que hacer un cambio, este puede consistir en un nuevo ciclo.
Ventajas
* No necesita una definición completa de los requisitos para empezar a funcionar.
* Al entregar productos desde el final de la primera iteración es mas facil validar los requisitos.
* El riesgo en general es menor, porque si todo se hace mal, solo se ha perdido el tiempo y recursos invertidos en una iteración (las anteriores iteraciones estan bien).
* El riesgo de sufrir retrasos es menor, ya que al identificar los problemas en etapas tempranas hay tiempo de subsanarlos.
Inconvenientes
* Es difícil evaluar los riesgos.
* Necesita de la participación continua por parte del cliente.
* Cuando se subcontrata hay que producir previamente una especificación completa de lo que se necesita, y esto lleva tiempo.
Dónde es adecuado:
* Sistemas de gran tamaño.
* Proyectos donde sea importante el factor riesgo.
* Cuando no sea posible definir al principio todos los requisitos.

Ciclos de vida orientados a objetos

Los tipos de ciclos de vida que se han visto hasta ahora son relativos al analisis y diseño estructurados, pero los objetos tienen una particularidad, y es que estan basados en componentes que se relacionan entre ellos a través de interfaces, o lo que es lo mismo, son mas modulares y por lo tanto el trabajo se puede dividir en un conjunto de mini proyectos. Ademas, hoy en día la tendencia es areducir los riesgos, y en este sentido, el ciclo de vida en cascada no proporciona muchas facilidades. Debido a todo esto, el ciclo de vida típico en una metodología de diseño orientado a objetos es iterativo e incremental.
En este texto sólo veremos un tipo de ciclo de vida orientado a objetos, que es ademas el mas representativo, el modelo fuente.

Fases del Ciclo del Desarrollo del Sistema

Todo sistema tiene un ciclo de vida así como los humanos nacemos, crecemos, nos reproducimos y morimos, los sistemas cuentan con un ciclo. Muchos autores manejan menos o mas etapas pero la idea es la misma a continuación sola describiremos el ciclo de vida que desde un punto de vista es el mas entendible.
Fases:
* Fase conceptual.
* Fase de definición.
* Fase de adquisición o de producción.
* Fase operacional.
* Fase de muerte.

Fase Conceptual
'La fase conceptual es aquella en la que la idea se concibe y se le hace una evaluación preliminar'.
En esta fase se examinan el medio se realizan pronósticos se evalúan los objetivos y alternativas, se realiza una evaluación por primera vez de costos y aspectos relacionados con el tiempo del sistema al mismo tiempo se hace la estrategia basica la organización y los requerimientos de recursos.
El propósito fundamental es conducir un estudio sobre papel de los requerimientos para proporcionar la base de una evaluación detallada posterior.

Característica de la Fase Conceptual
1. Determinación de las necesidades existentes o deficiencias potenciales de los sistemas existentes.
2. Establecer los conceptos del sistema que le proporcionanuna guía estratégica inicial para superar las deficiencias existentes o potenciales.
3. Determinar la factibilidad inicial técnica, de ambiente, económica y lo practico del sistema.
4. Examinar modos alternativos de lograr los objetivos del sistema
5. Proporcionar respuestas iníciales a las preguntas siguientes:
* Cuanto costara el sistema.
* Cuando estara disponible el sistema.
* Que hara el sistema.
* Cómo se integrara el sistema dentro de los sistemas existentes.
6. Identificar los recursos humanos y no humanos requeridos para apoyar el proyecto y sistema.
7. Seleccionar un diseño del sistema inicial que satisfaga los objetivos del sistema total.
8. Determinar las interrelaciones del sistema inicial.
9. Establecer una organización inicial del proyecto.

Fase de Definición
El propósito principal de esta fase es definir lo mas pronto posible y exacto, los costos, los programas, la realización y los requerimientos de recursos y si todos estos elementos concordaran económica y técnicamente.
'La fase de definición solo narra con mayor detalle que es lo que queremos hacer, cuando queremos hacerlo, como lo llevaremos.
Permite a la organización concebir y definir de manera completa el sistema antes que empiece a ponerlo físicamente en su medio.
Proporciona la oportunidad de revisar y confirmar la decisión de continuar el desarrollo, crea un sistema prototipo y toma una decisión de producción o instalación.

Característica de la Fase de Definición
1. Identificación por parte de la empresa los recursos humanos y no humanos que se requieren
2.Preparación de los requerimientos de realización para el sistema final
3. Preparación de los planes detallados que se requieren para apoyar el sistema
4. Determinación de los requerimientos realistas de costos, programación y de realización.
5. Identificación de aquellas areas del sistema donde exista alto riesgo de incertidumbre y delineamiento de los planes para investigaciones futuras.
6. Definición de las interrelaciones, intersistemas e intrasistemas.
7. Determinación de los sistemas de apoyo necesarios.
8. Identificación y preparación inicial de la documentación requerida para apoyar el sistema, tales como políticas, procedimientos, descripciones de las actividades, presupuestos y documentos de soporte de la propuesta del proyecto.

Fase de Producción o Adquisición
El proceso de adquisición involucra aspectos tales como la implantación real del sistema, la fabricación del equipo, la asignación de autoridad y de responsabilidad, la construcción de las instalaciones y la conclusión de la documentación de apoyo'.
El propósito de la Fase De Adquisición ó Producción es adquirir y probar los elementos del sistema utilizando los estandares que se desarrollaron durante las fases precedentes.

Características de la Fase de Producción
1. Actualización de los planes detallados que se concibieron y se definieron durante las fases precedentes.
2. Identificación de la administración de los recursos requeridos para facilitar los procesos de producción.
3. Verificación de las especificaciones de producción del sistema.
4. Comienzo de la producción, de la construcción y de la instalación.
5.Preparación final y diseminación de documentos relacionados con las políticas de los procedimientos.
6. Realización de pruebas finales para determinar la adecuación del sistema de tal manera que haga las cosas como se han solicitado.
7. Desarrollo de manuales técnicos y de documentación afiliada que describe cómo va a operar el sistema.
8. Desarrollo de planes para apoyar el sistema durante su fase de operación

Fase Operacional
En esta fase el gerente encargado del sistema es el que provee de todos los recursos necesarios para llevar a cabo los objetivos del sistema. Esta fase es resultado de que el modelo ha sido aprobado desde el punto de vista económico de factibilidad, y el gerente trata de poner mas atención en los elementos humanos del sistema y trata de optimizar los recursos del sistema total.
Durante esta fase el sistema puede perder su identidad y ser asimilado por el marco institucional de la organización.

Características de la Fase Operacional
* Uso de los resultados del sistema por parte del usuario final con el cliente.
* Integración real de los productos o servicios del proyecto dentro de los sistemas organizacionales existentes.
* Evaluación de la suficiencia, técnica, social y económica del proyecto a alcanzar las condiciones operativas reales.
* Provisión de retro- alimentación a los planeadores organizacionales en lo que respecta al desarrollo de los proyectos y sistemas.
* Evaluación de la pertinencia de sistemas de apoyo.

Viabilidad de los sistemas

En la era de la información, los sistemas informaticos de la empresa, susprestaciones y la potencia que precisan para funcionar crecen de forma exponencial, es por ello que los empresarios deben saber elegir un sistema y por ende la viabilidad del mismo.

Estudios de Viabilidad Técnica

¿Hay tecnología para crear el sistema que deseamos?
Un nuevo SI es viable técnicamente si sus componentes existen o pueden crear con las herramientas disponibles. Como sabemos, los SI se componen de hardware, software y en ocasiones, equipo de telecomunicaciones. Los investigadores usan su conocimiento, información extraída de publicaciones especializadas y asesoría de
Proveedores de hardware y software para determinar si puede construirse el sistema propuesto. En ocasiones los posibles usuarios solicitan funciones técnicas que aun no pueden proveerse.
El equipo debe considerar también los compromisos actuales de la organización en cuanto a hardware, software y telecomunicaciones. Por ejemplo, si la empresa adquirió recientemente cientos de unidades de una computadora determinada es poco probable que la administración apruebe la adquisición de otro modelo de computadora para una sola aplicación. Por tanto los investigadores deben averiguar si el sistema propuesto puede ejecutarse en el hardware actual.

Estudio de Viabilidad Económica
¿Que recursos necesitamos implantar al sistema?
¿Pesaran mas los beneficios del sistema que sus costos?

Como cualquier proyecto, el diseño de un nuevo SI debe estar económicamente justificado. Es decir, durante la vida útil del sistema, los beneficios deben sobrepasar los costos; para este fin, los analistas preparan un analisis de Costo/ Beneficio, enuna hoja de calculo que incluya todos los costos en que incurre el sistema y todo los beneficios que se espera de su operación.
El método mas exacto de analisis económico es el de ganancias sobre inversión, un calculo de la diferencia entre el flujo de beneficios y el flujo de gastos sobre la vida del sistema, descontados por la tasa de interés aplicable para encontrar la ganancia sobre inversión, el valor neto presente del sistema se calcula combinando el valor neto presente de los costos del sistema con el valor neto presente de los beneficios del sistema, haciendo calculos basados en costos y beneficios anuales y con la tasa de interés apropiada. Si la ganancia sobre inversión es positiva, el sistema resulta económicamente viable, o de costo justificado; recuerde que durante el tiempo de creación del sistema que puede ser de varios años, no hay beneficios, solo costos de creación; los costos operacionales durante la vida del sistema incluyen personal de mantenimiento, telecomunicaciones, proveedores de equipo de computo (para reemplazo de hardware en caso de problemas y actualización de software y para compra de papel y tinta ) y energía.
Si el sistema incluye un sitio web, el costo de revisión y mejoramiento de este por los webmasters y otros profesionales también debe tomarse en cuenta.
Con frecuencia es difícil justificar el costo de un nuevo SI porque hay demasiados beneficios que son intangibles, es decir, no se cuantifican en términos económicos. La mejora en el servicio al cliente, una mejor toma de decisiones y la creación de un ambiente de trabajo mas adecuado son beneficios que podrían aumentarlos ingresos, pero es muy difícil estimarlos en cifras.
Los ahorros por reducción de personal son, quizas, uno de los beneficios tangibles de los nuevos sistemas, como la automatización de las fuerzas de venta. Pero otros beneficios tangibles de las nuevas tecnologías muchas veces no son reconocidos en los analisis de ganancia sobre inversión de la mayoría de las corporaciones.

Beneficios:

* Un nuevo SI ayuda a un manejo mas rapido de las cuentas por cobrar.

* Un nuevo SI ayuda a reducir los ciclos mensuales de cierre de ciclo mayor.
* Un nuevo SI permite a los administradores realizar analisis del tipo ¨ que pasaría si ¨ en tiempo real durante el ciclo de planeación financiera, probando ideas que mejoraran los negocios.

* Un nuevo SI mejora la eficiencia al reducir errores en facturación.

* Un nuevo SI reduce el tiempo de preparar presupuestos.

* Un nuevo SI permite dar seguimiento y, por tanto, controlar mejor los costos.

Estudio de la Viabilidad Operacional
¿Los usuarios futuros utilizaran apropiadamente el sistema?
¿Se usara el sistema su maxima capacidad?

El propósito del estudio de viabilidad operacional es determinar si el nuevo sistema se usara como esta planeado. De manera mas específica, este analisis responde a las siguientes preguntas:

¿Se adecuara el sistema a la cultura de esta Organización?
¿Usaran todos los usuarios potenciales el sistema a su maxima capacidad?
¿Afectara el sistema las políticas de la compañía o los estatutos?

* ¿Cómo elegir el mejor Sistema Informatico para la empresa del siglo XXI?
*¿De qué disponemos en el siglo XXI?
* Sistemas de Telecomunicación y Redes LAN.
* Hardware.
* Plataformas de Sistemas Operativos.
* Bases de Datos y Lenguajes de Programación Orientados a Objetos.
* Software especializado y garantizado.

* El Dilema del Empresario
Ahora sé que comprar es mejor que desarrollar, que es una inversión mayor y que no debo cometer errores, pero…
* ¿Qué es lo que debo comprar?
* ¿Cómo hago para conocer mis necesidades?
* ¿Quién me puede ayudar?
* ¿Qué herramientas puedo utilizar?
* ¿Cual es procedimiento de selección?
* ¿Cómo lo implemento?

* Antes de decidir sobre el software…

¿Qué necesito para ser competitivo?

* Clientes
* Precio competitivos
* Promoción Empleados
* Capacidad Desempeño Costos
* Planeación Distribución Producción Transacciones Ventas
* Seguimiento Oportunidades Proyecciones
* Eficiencia Operativa

Mantenimiento del Sistema
Después de activar un servicio, también se debera mantenerlo en correcto funcionamiento. Para la mayoría de éstos, sera suficiente con unas pequeñas revisiones, pero para otros servicios, como lo son el correo o las noticias, sera necesario ejecutar rutinas de verificación para mantener el sistema en óptimo estado.
La fase de mantenimiento de software involucra cambios al software en orden de corregir defectos y dependencias encontradas durante su uso tanto como la adición de nueva funcionalidad para mejorar la usabilidad y aplicabilidad del software.
El mantenimiento del software involucra varias técnicas específicas.Una técnica es el rebanamiento estatico, la cual es usada para identificar todo el código de programa que puede modificar alguna variable. Es generalmente útil en la re fabricación del código del programa y fue específicamente útil en asegurar conformidad para el problema del año 2000.
La fase de mantenimiento de software es una parte explícita del modelo en cascada del proceso de desarrollo de software el cual fue desarrollado durante el movimiento de programación estructurada en computadores. El otro gran modelo, el Desarrollo en espiral desarrollado durante el movimiento de ingeniería de software orientada a objeto no hace una mención explícita de la fase de mantenimiento. Sin embargo, esta actividad es notable, considerando el hecho de que dos tercios del coste del tiempo de vida de un sistema de software involucran mantenimiento.
En un ambiente formal de desarrollo de software, la organización o equipo de desarrollo tendran algún mecanismo para documentar y rastrear defectos y deficiencias. El Software tan igual como la mayoría de otros productos, es típicamente lanzado con un conjunto conocido de defectos y deficiencias. El software es lanzado con esos defectos conocidos porque la organización de desarrollo en las utilidades y el valor del software en un determinado nivel de calidad compensan el impacto de los defectos y deficiencias conocidas.
Las deficiencias conocidas son normalmente documentadas en una carta de consideraciones operacionales o notas de lanzamiento (release notes) es así que los usuarios del software seran capaces de trabajar evitando las deficiencias conocidas y conoceran cuando el usodel software sería inadecuado para tareas específicas.
Con el lanzamiento del software (software release), otros defectos y deficiencias no documentados seran descubiertas por los usuarios del software. Tan pronto como estos defectos sean reportados a la organización de desarrollo, seran ingresados en el sistema de rastreo de defectos.
Las personas involucradas en la fase de mantenimiento de software esperan trabajar en estos defectos conocidos, ubicarlos y preparar un nuevo lanzamiento del software, conocido como un lanzamiento de mantenimiento, el cual resolvera los temas pendientes.

Tipos de mantenimiento
* Perfectivo: son las acciones llevadas a cabo para mejorar la calidad interna de los sistemas en cualquiera de sus aspectos: reestructuración del código, definición mas clara del sistema y optimización del rendimiento y eficiencia.
* Evolutivo: son las incorporaciones, modificaciones y eliminaciones necesarias en un producto software para cubrir la expansión o cambio en las necesidades del usuario.
* Adaptativo: son las modificaciones que afectan a los entornos en los que el sistema opera, por ejemplo, cambios de configuración del hardware, software de base, gestores de base de datos, comunicaciones, etc.
* Correctivo: son aquellos cambios precisos para corregir errores del producto software.
* Preventivo: Para evitar posibles problemas del sistema a Futuro.
Cabe señalar que, de estos 4 tipos de mantenimiento, solamente el correctivo y el evolutivo entran en el ambito de MÉTRICA versión 3, ya que los otros dos requieren actividades y perfiles distintos a los del proceso dedesarrollo.
Ejemplos:
* Si un software es entregado desde su fase 0, se desea que el mismo presente todos los errores que contiene haciéndole un bombardeo de tareas para medir cual es su capacidad, y en cuanto aparezcan los errores se le hace un mantenimiento correctivo.
* El software tiene que cubrir las necesidades de los usuarios por lo tanto los requerimientos nuevos que estos puedan obtener debe de añadírsele al sistema y así cumplir una tapa de perfeccionamiento del mismo.
* Todo software debe ser flexible a actualizaciones y parches, de esta forma se reforzara su rendimiento en su etapa de evolución.
* Un sistema debe contener el menor número posible de errores por lo tanto se emplea una estrategia de prevención de fallos para minimizarlos.
Costos
Esta demostrado que la mayor incidencia en los costos de una aplicación esta en su mantenimiento.
Fragilidad del Sistema
Cuando el software esta en etapa de desarrollo o de prueba, es infinitamente maleable; puede ser formado completamente al gusto de sus implementadores.
Pero tan pronto como un proyecto dado crece mas y mas (etapa de producción), y desarrolla una gran base de usuarios con mayor experiencia con el software, se vuelve menos y menos maleable. El software se vuelve un sistema heredado, fragil e incapaz de ser facilmente cambiado sin fracturar el sistema completo.
Razones
* Los usuarios esperan una relativamente constante interfaz de usuario; una vez que una característica ha sido implementada y expuesta a los usuarios, es muy difícil de convencerlos de aceptar cambios mayores a esa característica, incluso si esa característica noestaba bien diseñada en principio o la existencia de la misma bloquea un mayor progreso.
* Demasiada documentación puede describir el comportamiento actual (del software) y sería costoso de cambiar. Ademas, es esencialmente imposible recordar todas las copias de la documentación existente así que es mas probable que los usuarios se refieran de nuevo a los manuales obsoletos de todos modos.
* Los implementadores originales (aquellos que conocían cómo las cosas realmente funcionaban o como se implementaron) pueden no recordar, o haber ido a otra empresa o lugar. Los mismos pueden haber dejado una documentación insuficiente del funcionamiento interno del software. Muchos detalles de implementaciones de tamaño pequeño solamente fueron entendidos a través de la transmisión oral directa del equipo de diseño y muchos de estos detalles se han perdido, o se han podido perder, aunque algunos pueden ser redescubiertos a través de la aplicación diligente de una arqueología de software. Sobre esto Cunningham, Hunt, Marick y Thomas explican :
A los programadores a menudo se les entrega un sistema (de software) de tamaño considerable, construido por gente que no conocen, tocado por muchas personas desde entonces, documentado mínimamente si es que lo fue. Se les dice que lo mejoren. Su tarea debería ser corregir un error, agregar una característica, o una re fabricación completa. Estan bajo la presión del tiempo, así que necesitan minimizar el tiempo total destinado a aprender del sistema y el tiempo gastado en mejorarlo. Cunningham, Hunt, Marick & Thomas
* Los parches software se han efectuado probablemente através de los años, cambiando sutilmente el comportamiento del software. En muchos casos, estos parches corrigen el fallo por el cual fueron efectuados pero introducen otros fallos mas sutiles en el sistema. Estos fallos sutiles hacen cambios subsecuentes al sistema lo que lo vuelve finalmente mas complicado.

Conclusión

De la presente investigación realizada podemos concluir la importancia que tienen los sistemas de in formación para las organizaciones y empresas y la utilidad que la misma presta a los usuarios que laboran en dichas empresas ya que sin los sistemas de información que es el elemento fundamental y su razón de ser .con ellos es que hoy en día podemos tener una respuesta rapida a cualquier problema como por ejemplo Un aeropuerto sin su sistema de información para sus aterrizajes de sus aviones, o una central de trenes sin su sistema de información de rutas alternas en caso de que dos trenes utilizan las mismas rutas ¿cuando avisar para que cambien a rutas alternas para evitar un choque?. Y también que tan importante son los profesionales en el area computacional ya que estos hacen que mediante sus destrezas nuestra tecnología sea mucho mas eficaz y ala ves que se encargan de mantener nuestro sistema de información y otros profesionales el hardware para la ayuda que es de gran utilidad en una organización así como en nuestras vidas cotidiana, donde ellos como analistas saben cómo realiza el modelo de ciclos de vida del sistemas como implantarlo cuando usarlo y cuando llega el momento de su culminación porque tienen conocimiento de la tecnología y sus fases y todo lo que un sistemas conlleva .