El ciclo de vida del desarrollo de sistemas es el conjunto de actividades de los analistas, diseñadores y usuarios, que necesitan llevarse a cabo para desarrollar y poner en marcha un sistema de información. Se debe tener presente que en la mayoría de las situaciones del negocio, las actividades están íntimamente relacionadas y son inseparables.
El ciclo de vida del desarrollo de sistemas consiste en las siguientes actividades:
1. Investigación preliminar
2. Determinación de requerimientos
3. Desarrollo de sistema prototipo
4. Diseño de sistema
5. Desarrollo de software
6. Prueba de los sistemas
7. Puesta en marcha
Investigaciones preliminares
¿Cuantas veces se está en situaciones en donde se pregunta si no existe una mejor manera de hacer algo? Por ejemplo, abrir una tienda departamental adicional que creará una necesidad para nuevos procedimientos de facturación, cuando un alto porcentaje de clientes utiliza la cuenta de crédito de esta compañía de esta compañía y compra en todas las tiendas. Duplicar el número de clientas para agrandar las instalaciones y la introducción de muchos nuevos productos, puede traer nuevos requerimientos de pago e cuentas. Un cambio en las áreas de los gerentes departamentales puede guiarlos hacia nuevas formas para registrar las ventas, con implicaciones para el sistema de entrada de pedidos basado en computadora. Una compañía en crecimiento, puede contemplara los sistemas de información computarizados como una forma para hacer posible el crecimiento continuo, sin tener dificultades en el proceso de los pedidos de los clientes.
Se puede inicias una petición por muchas razones, pero la clave es que alguien, ya sea gerente, un empleado o un especialista de sistemas, inicie un requerimiento para recibir ayuda de un sistema de información. Cuando ese requerimiento se realiza, la primera actividad de sistemas, es decir, la investigación preliminar, se inicia. Esta actividad tiene tres partes: clasificación de requerimiento, estudio de la factibilidad y aprobación del requerimiento. El resultado será aprobar el requerimiento para la atención posterior o rechazarlo como no factible para un desarrollo futuro.
Clarificación del requerimiento
En las empresas muchos requerimientos de los empleados y usuarios no están establecidos claramente; por lo tanto, antes de que pueda considerarse la investigación del sistema, le proyecto requerido debe examinarse para determinar para determinar precisamente lo que desea la empresa. Una simple llamada telefónica puede ser suficiente si la persona que requiere el servicio tiene una idea clara, pero no sabe cómo establecerla. Por otro lado, la persona que hace el requerimiento puede estar simplemente pidiendo ayuda sin saber qué es lo que está mal o por qué existe un problema. La clarificación del problema es este caso, antes de poder llagar a otro paso, el requerimiento de proyecto debe estar claramente establecido.
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 en el estudio de factibilidad de la investigación preliminar:
1. Factibilidad técnica. ¿Puede realizarse el trabajo para el proyecto con el equipo actual, tecnología de software y el personal disponible? Si se requiere nueva tecnología, ¿qué probabilidades hay de que pueda desarrollarse?
2. factibilidad económica. ¿Existen suficientes beneficios en la creación del sistema para hacer que los costos sean aceptables? O, en forma inversa, ¿son tan altos los costos como para que el proyecto no deba llevarse a cabo?
3. Factibilidad operativa. ¿Se utilizará el sistema si se desarrolla y pone en marcha? Habrá resistencia de los usuarios, que los posibles beneficios reducirán del sistema.
El estudio de factibilidad se lleva a cabo con un pequeño grupo de gente, familiarizada con las técnicas de los sistemas de información, que entienden la parte de la empresa que será afectada por el proyecto y tienen los conocimientos suficientes del proceso de análisis y diseño de sistemas.
Aprobación del requerimiento
No todos los proyectos requeridos son deseables o factibles. Sin embargo, aquellos que son tanto factibles como deseables deben anotarse para tomarlos en cuenta. En algunos casos, el desarrollo puede comenzar inmediatamente, pero en la mayor parte, los miembros del departamento de sistemas están ocupados en otros proyectos que se encuentran en marcha. Cuando esto sucede, la gerencia decide que los proyectos son más importantes y entonces los programas. Después de que se aprueba la requisición de un proyecto, se estima su costo, la prioridad, el tiempo de terminación y los requerimientos del personal que se utilizan, para determinar qué lista existente los proyectos se incluirá.
Posteriormente, cuando se terminan algunos proyectos anteriores, puede iniciarse el desarrollo de la aplicación propuesta. En este momento, comienza la recabación de datos y la determinación de los requerimientos.
Determinación de requerimientos
El punto clave de análisis de sistemas se consigue al adquirir un conocimiento detallado de todas las facetas importantes dentro del área de negocios que se investiga. (Por esta razón, a menudo esta actividad se conoce como investigación detallada.) Los analistas, al trabajar con los empleados y gerentes, deben estudiar el proceso que actualmente se efectúa para contestar estas preguntas clave:
1. ¿Qué se está haciendo?
2. ¿Cómo se está haciendo?
3. ¿Qué tan frecuentemente ocurre?
4. ¿Qué tan grande es la cantidad de transacciones o decisiones?
5. ¿Qué tan bien se lleva acabo la tarea?
6. ¿Existe algún problema?
7. ¿Si el problema existe, qué tan serio es?
8. ¿Si el problema existe, cuál es la causa principal?
Para contestar estas preguntas, los analistas de sistemas hablarán con diferentes personas para recabar los detalles en relación con el proceso, así como sus opiniones sobre las causas por las cuales suceden las cosas de esa manera y algunas ideas en relación a modificarlas. Se utilizan cuestionarios para recopilar esta información, aplicándolos a grandes que no pueden entrevistarse en forma individual. Las investigaciones detalladas también requieren el estudio de manuales y reportes, la observación real de las actividades de las actividades de trabajo y algunas veces la recabación de formas y documentos para entender completamente el proceso.
Conforme se recopilan los elementos, los analistas estudian los requerimientos de datos para identificar las características que tendrá el nuevo sistema, incluyendo la información que el sistema debe producir y las características operativas, como son controles de procesamiento, tiempos de respuesta y métodos de entrada y salida.
Desarrollo del sistema prototipo
La preparación de prototipos es el proceso de crear, desarrollar y refinar un modelo funcional del sistema final. Se puede crear un modelo prototipo preliminar durante la etapa de definición del problema. Un miembro del equipo de reconocimiento -suponga que se trata de un especialista en el procesamiento de datos- puede construir un modelo de este tipo que muestre la composición de las pantallas y los formatos de los informes. Durante una sesión de requerimientos, otros miembros del equipo y usuarios del futuro sistema examinan esta muestra en la forma con el constructor del modelo entiende en principio el problema y los resultado que debe producir el sistema.
En este momento puede iniciarse un proceso de refinación si los usuarios señalan omisiones y equivocas.
Durante este proceso de refinación, cuyo objetivo es definir la necesidad que existe, uno o más miembros del equipo pueden utilizar una computadora personal y un paquete de programas de prototipos a fin de crear una serie de pantallas en la computadora personal. Estas pantallas no son las salidas que producen los programas ya terminados, pero pueden parecerse mucho a esos resultados. Es posible exhibir en el monitor de la computadora, como una secuencia de diapositivas, menús de captura de datos, la interfaz con el usuario debe servir para buscar, consultar y manipular datos y el formato de los informes de salida. Por ejemplo, se pueden simular los resultados de una serie de selecciones hechas en menús para que los usuarios tengan una idea más clara de la forma como el constructor o los constructores del sistema están interpretando el problema. Si los usuarios no están convencidos de lo que se exhibe define con precisión sus necesidades, pueden modificar fácilmente las plantillas prototipo hasta que estén satisfechos. La creación de un modelo preliminar de prototipo en este punto produce varios beneficios: los usuarios pueden ver que se está avanzado, se les motiva para que participen activamente en la definición del problema, se mejora la comunicación 4entre todas las partes interesadas y se aclaran los equívocos en una etapa temprana del estudio de sistemas, antes de que se conviertan en costosos errores.
Como se acaba e ver, puede ser necesario un proceso repetitivo (o interactivo) para terminar el paso de definición del problema. No existe un procedimiento definido que se deba seguir antes de que se pueda iniciarse el análisis detallado del sistema. Un alto ejecutivo puede creer que existen diferencias de información. Puede preparar una declaración general de los objetivos y nombrar a un gerente para que realice un reconocimiento. Pueden realizarse varias sesiones de requerimientos para traducir los deseos generales a objetivos más específicos. Asimismo, pueden crearse y refinarse modelos preliminares de prototipo; se puede ampliar o reducir el alcance del estudio y es posible también que cambien los objetivos conforme se reúnan los datos. Una vez que parezca haberse logrado la aprobación en cuanto a la definición del problema, el equipo de reconocimiento deberá poner la definición detallada por escrito y enviarla a todas las personas interesadas, las cuáles deberán aprobarla también por escrito. Si persisten diferencias, deberán resolverse en sesiones adicionales de requerimientos. Hay quienes se impacientan con los “retrasos” en el desarrollo del sistema causados por estas sesiones adicionales. Sin embargo, las personas más prudentes saben que los retrasos verdaderamente largos y costosos se presentan cuando los usuarios descubren, ya muy avanzados el proceso del desarrollo, que el sistema diseñado no es satisfactorio por haberse pasado por alto algunos requerimientos.
Diseño del sistema
El diseño de un sistema de información produce los elementos que establecen cómo el sistema cumplirá los requerimientos indicados durante el análisis de sistemas. A menudo los especialistas de sistemas se refieren a esta etapa como en diseño lógico, encontraste con desarrollo del software de programas, que se conoce como diseño físico.
Los analistas de sistemas comienzan por identificar los informes y otras salidas que el sistema producirá. A continuación los datos específicos con éstos se señalan, incluyendo su localización exacta sobre el papel, la pantalla de despliegue u otro medio. Usualmente, los diseñadores dibujan la forma o la visualización como la esperan cuando el sistema esta terminado.
El diseño del sistema también describe los datos calculados o almacenados que se introducirán. Los grupos de datos individuales y los procedimientos de calculo se describen con detalle. Los diseñadores seleccionan las estructuras de los archivos y los dispositivos de almacenamiento, como son discos magnéticos, cintas magnéticas o incluso archivos en papel. Los procedimientos que ellos escriben muestran cómo se van a procesar los datos y a producir la salida.
Los documentos que contienen las especificaciones de diseño utilizan muchas formas para representar los diseños, diagramas, tablas y símbolos especiales, algunos de los cuales el lector puede haber utilizado ya y otros que pudieran ser totalmente nuevos. La información del diseño detallado se pasa al grupo de programación para que pueda comenzar el desarrollo del software.
Los diseñadores son responsables de proporcionar a los programadores las especificaciones completas y escritas con claridad, que establezcan lo que debe hacer el software. Conforme comienza la programación, los diseñadores están pendientes para contestar preguntas, esclarecer ideas confusas y manejar los problemas que confronten los programadores cuando utilicen las especificaciones de diseño.
Desarrollo del Software
Los desarrollares del software pueden instalar o modificar; por ejemplo, software comercial que se haya comprado, o pueden escribir programas nuevos diseñados a la medida. La decisión de qué se va a hacer depende del costo de cada una de las opciones, el tiempo disponible para describir el software y la disponibilidad de programadores. En forma usual, en las grandes empresas los programadores de computadoras (o la combinación de analistas-programadores) son parte del grupo profesional permanente. Las compañías más pequeñas en donde los programadores permanentes no se han contratado, pueden obtener servicios externos de programación con base en un contrato.
Los programadores también son responsables de documentar el programa e incluir los comentarios que expliquen tanto cómo y por qué se utilizo cierto procedimiento conforma se codifico de cierta forma. La documentación es esencial para probar el programa y darle mantenimiento una vez que la aplicación se ha puesto en marcha.
Prueba de los sistemas
Durante la prueba, el sistema se utiliza en forma experimental para asegurar que el software no falle; es decir, Que corra de acuerdo a sus especificaciones y a la manera que los usuarios esperan que lo haga. Se examinan datos especiales de prueba en la entrada del procesamiento y los resultados para localizar algunos problemas inesperados. Puede permitirse también a un grupo limitado de usuarios que utilice el sistema, de manera que los analistas puedan captar si tratan de utilizarlo en forma no planeadas. Es preferible detectar cualquier anomalía antes de que la empresa ponga en marcha el sistema y dependa de él.
En muchas compañías la prueba se lleva a cabo por personas diferentes a aquellos que los escriben en forma original; es decir si se utilizan personas que no conocen como se diseñaron ciertas partes de los programas, se asegura una mayor y más completa prueba, además de ser imparcial, lo que da a un software más confiable.
Puesta en marcha
Cuando el personal de sistemas verifica y pone en uso el nuevo equipo, entrena al personal usuario; instala la nueva aplicación y constituye los archivos de datos que se necesiten, entonces el sistema está puesto en marcha.
De acuerdo con el tamaño de la empresa que empleará la aplicación y el riesgo asociado con su uso, los desarrolladores del sistema pueden escoger una prueba piloto para la operación del sistema solamente en un área de la compañía; por ejemplo, en un departamento o sólo con una o dos personas. A veces correrán en forma paralela tanto el sistema anterior como el nuevo para comparar los resultados de ambos; en otras situaciones, los desarrolladores pararán por completo el sistema anterior un día y al siguiente empezarán a utilizar el nuevo. Como se puede apreciar, cada estrategia para la puesta en marcha tiene sus méritos, que dependen de la situación del negocio considerado. Sin importar la estrategia para la puesta en marcha que se haya utilizado, los desarrolladores tendrán que asegurarse que el uso inicial del sistema esté libre de problemas.
Una vez instalada, con frecuencia la aplicación se utiliza por muchos años; sin embargo, tanto la empresa como los usuarios cambiarán, y el medio ambiente será diferente también a través del tiempo. Por lo tanto, la aplicación indudable mente necesitará mantenimiento; es decir, se harán cambios y modificaciones al software, y a los archivos o procedimientos para cubrir los requerimientos nuevos de los usuarios.
Los sistemas de la empresa y el medio ambiente de los negocios están en continuo cambio. Los sistemas de información deben mantenerse de la misma forma; es este sentido, la propuesta en marcha es un proceso continuo.
Fuente: Ernesto Jesús Gómez Vázquez