Ciclo de vida del desarrollo de sistemas

Es el conjunto de actividades que los analistas, diseadores y usuarios realizan para desarrollar e implantar un sistema de informacin. Esta seccin examina cada una de las seis actividades que constituyen el ciclo de vida de desarrollo de sistemas. En la mayor parte de las situaciones dentro de una empresa todas las actividades estn muy relacionadas, en general son inseparables, y quiz sea difcil determinar el orden de los pasos que se siguen para efectuarlas. Las diversas partes del proyecto pueden encontrarse al mismo tiempo en distintas fases de desarrollo; algunos componentes en la fase de anlisis, mientras que otros, en etapas avanzadas de diseo. El mtodo de ciclo de vida para desarrollo de sistemas consta de las siguientes actividades: 1. Investigacin preliminar. 2. Determinacin de los requerimientos sistema. 3. Diseo del sistema. 4. Desarrollo de software. 5. Prueba de los sistemas. 6. Implantacin y evaluacin del

Investigacin preliminar. La solicitud para recibir ayuda de un sistema de informacin puede originarse por varias razones; sin importar cuales son estas, el proceso se inicia siempre con la peticin de una persona

administrador, empleado o especialista en sistemas. Cuando se formula la solicitud comienza la primera actividad de sistemas: la investigacin preliminar. Esta actividad tiene tres partes: aclaracin de la solicitud, estudio de factibilidad y aprobacin de la solicitud. Aclaracin de la solicitud. Muchas solicitudes que provienen de empleados y usuarios, no estn formuladas de manera clara. Por consiguiente, antes de considerar cualquier aclaracin de sistemas, la solicitud de proyecto, debe examinarse para determinar con precisin lo que el solicitante desea. Si ste tiene una buena idea de lo que necesita, pero no esta seguro, como expresarlo, entonces bastar con hacer una llamada telefnica. Por otro lado, si el solicitante pide ayuda sin saber, que es lo que esta mal o donde se encuentra el problema, la aclaracin del mismo se vuelve ms difcil. En cualquier caso, antes de seguir adelante, la solicitud del proyecto debe estar claramente planteada. Estudio de factibilidad. Un resultado importante de la investigacin preliminar es la determinacin de que el sistema solicitado sea factible. En la investigacin preliminar existen tres aspectos relacionados con el estudio de factibilidad. 1. FACTIBILIDAD TCNICA. El trabajo para el proyecto, puede realizarse en el equipo actual, la tecnologa existente del software y el personal disponible? Si

se necesita nueva tecnologa cul es la posibilidad de desarrollarla? 2. FACTIBILIDAD ECONMICA. Al crear el sistema, los beneficios que se obtienen sern suficientes para aceptar los costos?, los costos asociados con la decisin de no crear el sistema son tan grandes que se debe aceptar 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 cmo resultado una disminucin de los posibles beneficios de la aplicacin? El estudio de factibilidad lo lleva a cabo un pequeo equipo de personas (en ocasiones una o dos) que est familiarizado con tcnicas de sistemas de informacin; dicho equipo comprende la parte de la empresa u organizacin que participar se ver afectada por el proyecto y es gente experta en los procesos de anlisis y diseo de sistemas. En general, las personas que son responsables de evaluar la factibilidad son anlisis capacitados o directivos. Aprobacin de la solicitud No todos los proyectos solicitados son deseables o factibles. Algunas organizaciones reciben tantas solicitudes de sus empleados que slo es posible atender unas cuantas. Sin embargo, aquellos proyectos que son deseables o factibles deben incorporarse en los planes, en algunos casos, el desarrollo

puede comenzar inmediatamente, aunque lo comn es que los miembros de equipos de sistemas se encuentran ocupados en otros proyectos. Cuando esto ocurre, la administracin decide que proyectos son los ms importantes y decide el orden en que se llevara a cabo, muchas organizaciones desarrollan sus planes para sistemas de informacin con el mismo cuidado con los que clarifican nuevos productos y programas de la fabricacin o la expansin de sus instalaciones. Despus de aprobar la solicitud de un proyecto se estima su costo, el tiempo necesario para terminarlo y las necesidades del personal: con esta informacin se determina donde ubicarlo dentro una lista de proyectos que existen de proyectos. Ms adelante cuando los dems proyectos se han completados, se inicia el desarrollo de la aplicacin del proyecto. Determinacin de los requerimientos del sistema. El aspecto fundamental del anlisis de sistemas es comprender todas las facetas importantes de la parte de la empresa que se encuentra bajo estudio. (Es por esta razn que el proceso de adquirir informacin se denomina, con frecuencia, Investigacin detallada). 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. Cmo se hace? 3. Con qu frecuencia se presenta?

4. Qu tan grande es el volumen de transacciones o de decisiones? 5. Cul es el grado de eficiencia con el que se efectan las tareas? 6. Existe algn problema? 7. Si existe un problema. Qu tan serio es? 8. Si existe un problema. Cul 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 informacin cuando no es posible entrevistar, en forma personal, a los miembros de grupos grandes dentro de la organizacin. As mismo, las investigaciones detalladas requieren el estudio de manuales y reportes, la observacin 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 renen los detalles, los analistas estudian los datos sobre requerimientos con la finalidad de identificar las caractersticas que debe tener el nuevo sistema, incluyendo la informacin que deben producir los sistemas junto con caractersticas operacionales tales como controles de procesamiento, tiempos de respuesta y mtodos de entrada y salida. Diseo del sistema. El diseo de un sistema de informacin produce los detalles que establecen la forma en la que el sistema cumplir con los requerimientos identificados durante la fase de anlisis. Los

especialistas en sistemas se refieren, con frecuencia, a esta etapa como diseo lgico en contraste con la de desarrollo del software, a la que denominan diseo fsico. Los analistas de sistemas comienzan el proceso de diseo identificando los reportes y dems salidas que debe producir el sistema. Hecho lo anterior se determinan con toda precisin los datos especficos para cada reporte y salida. Es comn que los diseadores hagan un bosquejo del formato o pantalla que esperan que aparezca cuando el sistema est terminado. Lo anterior se efecta en papel o en la pantalla de una terminal utilizando para ello algunas de las herramientas automatizadas disponibles para el desarrollo de sistemas. El diseo de un sistema tambin indica los datos de entrada, aquellos que sern calculados y los que deben ser almacenados. Asimismo, se escriben con todo detalle los procedimientos de clculo y los datos individuales. Los diseadores seleccionan las estructuras de archivo y los dispositivos de almacenamiento, tales como discos y cintas magnticas o incluso archivos en papel. Los procedimientos que se escriben indican cmo procesar los datos y producir las salidas. Los documentos que contienen las especificaciones de diseo representan a ste de muchas maneras (diagramas, tablas y smbolos especiales). La informacin detallada del diseo se proporciona al equipo de programacin para comenzar la fase de desarrollo de software. Los diseadores son los responsables de dar a los programadores las especificaciones de software completas y claramente delineadas. Una vez comenzada la fase de programacin, los

diseadores contestan preguntas, aclaran dudas y manejan los problemas que enfrentan los programadores cuando utilizan las especificaciones de diseo. Desarrollo de software. Los encargados de desarrollar software pueden instalar (o modificar y despus instalar) software comprado a terceros o escribir programas diseados a la medida del solicitante. La eleccin depende del costo de cada alternativa, del tiempo disponible para escribir el software y de la disponibilidad de los programadores. Por esta regla general, los programadores (o analistas programadores) que trabajan en las grandes organizaciones pertenecen a un grupo permanente de profesionales. En empresas pequeas, donde no hay programadores, se pueden contratar servicios externos de programacin. Los programadores tambin son responsables de la documentacin de los programas y de proporcionar una explicacin de cmo y por qu ciertos procedimientos se codifican en determinada forma. La documentacin es esencial para probar el programa y llevar acabo el mantenimiento una vez que la aplicacin se encuentra instalada. Prueba de los sistemas. Durante la fase de prueba de sistemas, el sistema se emplea de manera experimental para asegurarse de que el software no tenga fallas, es decir que funcione 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 despus 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. Es preferible descubrir cualquier sorpresa antes de que la organizacin implante el sistema y dependa de l. En muchas organizaciones, las pruebas son conducidas por personas ajenas al grupo que escribi los programas originales; con esto se persigue asegurar, por una parte, que las pruebas sean completas e imparciales y, por otra, que el software sea ms confiable. Implantacin y evaluacin La implantacin es el proceso de verificar e instalar nuevo equipo entrenar a los usuarios, instalar la aplicacin y construir todos los archivos de datos necesarios para utilizarla. Dependiendo del tamao de la organizacin que emplear la aplicacin y el riesgo asociado con su uso, puede elegirse comenzar la operacin del sistema slo en un rea de la empresa (prueba piloto), por ejemplo en un sistema en un departamento o con una o dos personas. Algunas veces se deja que los sistemas, el viejo y el nuevo, trabajen en forma paralela con la finalidad de comparar los resultados. En otras circunstancias, el viejo sistema deja de utilizarse determinado da para comenzar a emplear el nuevo al da siguiente. Cada estrategia de implantacin tiene sus mritos de acuerdo con la situacin que se considere dentro de la empresa. Sin importar cul 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 aos. 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. Por consiguiente, es indudable que debe darse mantenimiento a las aplicaciones, realizar cambios y modificaciones en el software, archivos o procedimientos para satisfacer las nuevas necesidades de los usuarios. Dado que los sistemas de las organizaciones junto con el ambiente de las empresas experimentan cambios de manera continua, los sistemas de informacin deben mantenerse siempre al da. En este sentido la implantacin es un proceso en constante evolucin. La evolucin de un sistema se lleva a cabo para identificar puntos dbiles y fuertes. La evaluacin ocurre a lo largo de cualquiera de las siguientes dimensiones: Evaluacin operacional Impacto organizacional Opinin de los administradores Desempeo del desarrollo Desafortunadamente la evaluacin de sistemas no siempre recibe la atencin que merece. Sin embargo, cuando se conduce en forma adecuada proporciona mucha informacin que puede ayudar a mejorar la efectividad de los esfuerzos de desarrollo de aplicaciones subsecuentes. PLANIFICACIN DEL CICLO DE VIDA El modelo del ciclo de vida escogido es un factor principal para conseguir los objetivos

buscados, una mala eleccin del modelo del ciclo de vida puede que se nos retrase el trabajo enormemente o que tengamos una planificacin perfecta del trabajo. TIPOS DE MODELOS: Cascada pura Codificar y corregir Espiral Cascadas modificadas Prototipo evolutivo Entrega por etapas Diseo por planificacin Entrega evolutiva Diseo por herramientas CASCADA PURA Es el ms antiguo de todos los modelos de ciclo de vida y sirve de modelo para otros modelos de ciclos de vida. En un modelo de cascada un proyecto progresa a travs de una secuencia ordenada de pasos que son: Concepto del software Anlisis de requerimientos Diseo global Diseo detallado Codificacin y depuracin Prueba del sistema. El modelo contiene una serie de etapas que no se solapan, y el proyecto se va revisando tras cada una de las etapas. Para poder pasar a la siguiente etapa se tiene que haber conseguido todos los objetivos de la etapa anterior, es un proceso secuencial. Tiene una buena aplicacin cuando el problema es estable y cuando se trabaja con metodologa

tcnicas conocidas. Este modelo ser apropiado para la migracin de una aplicacin o a una versin de mantenimiento bien definida. Con este modelo se tiene un seguimiento de todas las fases del proyecto y del cumplimiento de todas las fases del proyecto y del cumplimiento de todos los objetivos marcados en cada etapa tanto de costes, fecha de entrega y lo ms importante que pueden comprobar al final de cada etapa si el proyecto cumple todas las necesidades del usuario. A su vez este es un problema ya que si el usuario se da cuenta de que falta una tarea de la empresa en el proyecto una vez pasada esta etapa, el trabajo que hay que realizar se retrasa en fechas de entrega y el coste es mayor. Por lo tanto esto produce un fracaso en la industria a las modificaciones de ltima hora. Por este motivo se puede modificar el modelo en cascada pudiendo pasar de una etapa a la anterior, pero suele ser difcil ya que hay que rehacer la etapa anterior, este modelo es el ciclo de vida del salmn. Por lo tanto este es un modelo poco apropiado para proyectos con fecha de entrega corta, pero su rendimiento puede mejorar notablemente variando el modelo de cascada pura. Variaciones sobre el ciclo de vida en cascada El ciclo de vida en Cascada puede sufrir una serie de modificaciones para aumentar su eficiencia. Una de estas variaciones puede ser EL SASHIMI o CASCADA CON FASES SOLAPADAS, en el que para evitar algunos inconvenientes del modelo en cascada solapando sus etapas, pero este enfoque genera nuevos problemas ya que debido al solapamiento los hitos resultan ms ambiguos y

esto hace ms difcil trazar el proceso correctamente. Otra variacin sobre el ciclo de vida en Cascada con Subproyectos, en el que permite la ejecucin de algunas de las tareas de la cascada en paralelo, pero esta modificacin tiene el problema que la planificacin tiene que ser mucho ms cuidadosa, aunque se gana velocidad. CODIFICAR Y CORREGIR Es el modelo utilizado cuando no nos paramos en busca del modelo ms idneo para nuestro proyecto. Es decir en este modelo no se pierde el tiempo en la planificacin, en la calidad, en los documentos que hay que realizar cuando se terminan etapas o en cualquier otra actividad que no sea la codificacin. Por lo tanto este modelo no necesita tener experiencia y una gran cantidad de conocimientos. Al no seguir ningn modelo no tenemos ningn medio de ver si se cumplen las expectativas creadas, lo cual es un problema si encontramos un error casi al finalizar el proyecto ya que hay que empezar de nuevo. Por consiguiente tardamos ms en ver los errores que en otro modelo que sigue un mnimo de planificacin. ESPIRAL El modelo de la espiral es un modelo orientado a riesgo que divide el proyecto software en miniproyectos. Cada proyecto se encargar de resolver uno o varios riesgos hasta que estn todos controlados. Una vez que estn los riesgos ms importantes controlados se finaliza igual que el ciclo de vida en cascada. En el ciclo de vida en espiral localizan los

riesgos, genera un plan para manejarlos y establece una aproximacin a la siguiente iteracin. Con cada iteracin se produce una aproximacin al producto final. En el modelo en espiral se comienza con una parte pequea del proyecto y se expande tras reducir los riesgos para la siguiente iteracin. En cada iteracin seguimos los siguientes pasos: Determinar objetivos, alternativas y lmites. Identificar y resolver riesgos. Evaluar las alternativas Generar entregas de esta iteracin, y comprobar que son correctas. Planificar la siguiente iteracin. Si se decide ejecutar la siguiente iteracin, hay que establecer un enfoque para ella. En este modelo las primeras iteraciones son menos costosas y a medida que se avanza aumenta el coste. Las ventajas de este modelo son: Se disminuyen los riesgos. Al final de cada iteracin se obtienen los puntos de verificacin. Se obtiene con anterioridad indicaciones de cualquier riesgo insuperable. Las desventajas de este modelo son: Un aumento de costes. Es un modelo complicado de llevar a cabo porque exige una gestin concienzuda, atenta y unos conocimientos profundos. PROTOTIPO EVOLUTIVO Se comienza diseando y construyendo las partes ms importantes de la aplicacin en un prototipo que posteriormente se refinar y ampliar hasta que el prototipo se termine. Este

prototipo ser el software que se entregar al final. Se utiliza cuando los requerimientos cambian con celeridad, cuando el cliente es contrario a facilitar los requerimientos y especificaciones o cuando no est clara la forma del rea de aplicacin. Las ventajas son: Se generan signos visibles de progreso. Permite la modificacin sobre la marcha. El cliente se va familiarizando con el nuevo entorno. Las desventajas son: Imposibilidad de conocer a prioridad el tiempo desarrollado. La aproximacin puede convertirse en excusa para realizar el desarrollo con el modelo de codificar y corregir. ENTREGA POR ETAPAS En este modelo se evita el problema del modelo en cascada de no terminar ninguna etapa del modelo hasta que este completamente finalizado. Tras el diseo global implementar y entregar la aplicacin en etapas. La diferencia de este modelo con el prototipo evolutivo es que en este modelo conocemos exactamente lo que se va a construir. Este modelo funciona exactamente igual que el de cascada en las tres primeras fases y en el diseo detallado se divide por etapas. Sus ventajas son: Permite proporcionar una funcionalidad til en manos del cliente sin tener la aplicacin finalizada. Proporciona signos tangibles de progreso.

Su principal desventaja es que en este modelo no es viable sin una planificacin adecuada. DISEO POR PLANIFICACIN Es similar al modelo de entrega por etapas y es til cuando el proyecto tiene un plazo concreto. Este modelo se utiliza cuando no se conoce si el producto se tendr para la ltima entrega. A diferencia del modelo de entrega por etapas, estas estn ordenadas por orden de prioridad, as que la fecha tope aunque no hayamos terminado el proyecto estamos seguros de haber cubierto las funcionalidades ms importantes. ENTREGA EVOLUTIVA El modelo de entrega evolutiva ofrece el control que se obtiene con la entrega por etapas y la flexibilidad que se obtiene con el prototipo evolutivo. Este modelo puede ajustarse para proporcionar el control y la flexibilidad que se necesita. Este modelo realmente se encuentra entre el prototipo evolutivo y la entrega por etapas ya que se van desarrollando versiones aadiendo funcionalidad a las anteriores y se le van mostrando al cliente. Este proceso se repetir hasta agotar el tiempo, es presupuesto o hasta que el cliente este satisfecho.

BIBLIOGRAFA http://web.madritel.es/personales3/edcollado

Anlisis y Diseo de sistemas de Informacin James A. Senn Segunda edicin Mc Graw Hill 1998 Ingeniera del Software Un enfoque prctico Quinta edicin. Roger S. Pressman Mc Graw Hill 2002