El Ciclo de Vida Del Desarrollo de Sistemas

Nancy Elizabeth Aguilar Hernndez Joanna Karina Morales Morales
Fundamentos de Ingeniera de Software Equipo 8
El Ciclo de Vida del Desarrollo de Sistemas (KENDALL & KENDALL)
El ciclo de vida del desarrollo de sistemas (SDELC, Systems Development Life Cycle). El SDLC es un enfoque por fases para el anlisis y el diseo cuya premisa principal consiste en que los sistemas se desarrollan mejor utilizando un ciclo especifico de actividades del analista y el usuario. Aqu hemos dividido el ciclo en siete fases. A pesar de que cada fase se explica por separado, nunca se realiza como un paso aislado. Es mas practico considerar que el SDLC se realiza por fases y no en pasos aislados.
Identificacin de Problemas, Oportunidades y Objetivos. En esta primera fase del ciclo de vida del desarrollo de sistemas, el analista se ocupa de identificar problemas, oportunidades y objetivos. Esta etapa es crtica para el xito del resto del proyecto. La primera fase requiere que el analista observe objetivamente lo que sucede en un negocio. A continuacin, en conjunto con otros miembros de la organizacin, el analista determina con precisin cuales son los problemas. Con frecuencia los problemas son detectados por alguien ms, y esta es la razn de la llamada inicial al analista. Las oportunidades son situaciones que el analista considera susceptibles de mejorar utilizando sistemas de informacin computarizados. El aprovechamiento de las oportunidades podra permitir a la empresa obtener una ventaja competitiva o establecer un estndar para industria. La identificacin de objetivos tambin es una parte importante de la primera fase. En primer lugar, el analista debe averiguar lo que la empresa trata de conseguir. A continuacin, podr determinar si algunas funciones de las aplicaciones de los sistemas de informacin pueden contribuir a que el negocio alcance sus objetivos aplicndolas a problemas u oportunidades especficos. Los usuarios, los analistas y los administradores de sistemas que coordinan el proyecto son los involucrados en la primera fase. Las
actividades de esta fase consisten en entrevistar a los encargados de coordinar a los usuarios, sintetizar el conocimiento obtenido, estimar el alcance del proyecto y documentar los resultados. El resultado de esta fase es un informe de viabilidad que incluye una definicin del problema y un resumen de os objetivos. A continuacin, la administracin debe decidir si se sigue adelante con el proyecto propuesto. Si el grupo de usuarios no cuenta con fondos suficientes, si desea atacar problemas distintos, o si la solucin a estos problemas no amerita un sistema de cmputo.
Determinacin de los Requerimientos de Informacin. La siguiente fase, es la determinacin de los requerimientos de informacin de los usuarios. Entre las herramientas que se utilizan para determinar los requerimientos de informacin de un negocio se encuentran mtodos interactivos como las entrevistas, los muestreos, la investigacin de datos impresos y la aplicacin de cuestionarios; mtodos que no interfieren con el usuario como la observacin del comportamiento de los encargados de tomar las decisiones y sus entornos de oficina, al igual que mtodos de amplio alcance como la elaboracin de prototipos. El desarrollo rpido de aplicaciones (RAD, Rapid Application Development) es un enfoque orientado a objetos para el desarrollo de sistemas que incluye un mtodo de desarrollo y herramientas de software. En la fase de determinacin de los requerimientos de informacin del SDLC, el analista se esfuerza por comprender la informacin que necesitan los usuarios para llevar a cabo sus actividades. Esta fase es til para que el analista confirme la idea que tiene de la organizacin y sus objetivos. Los implicados en esta fase son el analista y los usuarios, por lo general trabajadores y gerentes del rea de operaciones. El analista de sistemas necesita conocer los detalles de las funciones del sistema actual: el quien (la gente involucrada), el que (la actividad del negocio), el donde (el entorno donde se desarrollan las actividades), el cuando (el momento oportuno) y el como (la manera en que se realizan los procedimientos actuales) del negocio que se estudia. Al trmino de esta fase, el analista debe conocer el
funcionamiento del negocio y poseer informacin muy completa acerca de la gente, los objetivos, los datos y los procedimientos implicados.
Anlisis de las Necesidades del Sistema. La siguiente fase es el anlisis de las necesidades del sistema. De nueva cuenta, herramientas y tcnicas especiales auxilian al analista en la determinacin de los requerimientos. Una de estas herramientas es el uso de diagramas de flujo de datos para grafica estructurada. A partir de los diagramas de flujo de datos se desarrolla un diccionario de datos que enlista todos los datos utilizados en el sistema, as como sus respectivas especificaciones. Durante esta fase el analista de sistemas analiza tambin las decisiones estructuradas que se hayan tomado. Las decisiones estructuradas son aquellas en las cuales se pueden determinar las condiciones, las alternativas de condicin, las acciones y las reglas de accin. Existen tres mtodos principales para el anlisis de decisiones estructuradas: espaol estructurado, tablas y arboles de decisin. En este punto del ciclo de vida del desarrollo de sistemas, el analista prepara una propuesta de sistemas que sintetiza sus hallazgos, proporciona un anlisis de costo/beneficio de las alternativas recomendaciones sobre lo que se debe hacer. y ofrece, en su caso,
Diseo del Sistema Recomendado. En esta fase el analista utiliza la informacin recopilada en las primaras fases para realizar el diseo lgico del sistema de informacin. El analista disea procedimientos precisos para la captura de datos que aseguran que los datos que ingresen al sistema de informacin sean correctos. Adems, el analista facilita la entrada eficiente de datos al sistema de informacin mediante tcnicas adecuadas de diseo de formularios y pantallas. La concepcin de la interfaz de usuario forma parte del diseo lgico del sistema informacin. La interfaz conecta al usuario con el sistema y por tanto es sumamente importante. La fase de diseo tambin incluye el diseo de archivos o bases de datos que almacenarn gran parte de los datos
indispensables para los encargados de tomar las decisiones en la organizacin. Una base de datos bien organizada es el cimiento de cualquier sistema de informacin. En esta fase el analista tambin interacta con los usuarios para disear la salida que satisfaga las necesidades de informacin de estos ltimos. Finalmente, el analista debe disear controles y procedimientos de respaldo que protejan al sistema y a los datos, y producir paquetes de especificaciones de programa para los programadores. Cada paquete debe contener esquemas para la entrada y salida, especificaciones de archivos y detalles del procesamiento; tambin podra incluir arboles o tablas de decisin, diagramas de flujo0 de datos, un diagrama de flujo de sistema, y los nombres y funciones de cualquier rutina de cdigo previamente escrita.
Desarrollo y Documentacin del Software. En esta fase, el analista trabaja de manera conjunta con los programadores para desarrollar cualquier software original necesario. Entre las tcnicas estructuradas para disear y documentar software original necesario. Entre las tcnicas estructuradas para disear y documentar software se encuentran los diagramas de estructura, los diagramas de NassiShneiderman y el pseudocdigo. El analista se vale de una o ms de estas herramientas para comunicar al programador lo que se requiere programar. Durante esta fase el analista tambin trabaja con los usuarios para desarrollar documentacin efectiva para el software, como manuales de procedimientos, ayuda en lnea y sitios Web que incluyan respuestas a preguntas frecuentes, que se integraran en el nuevo software. La documentacin indica a los usuarios como utilizar el software y lo que deben hacer en caso de que surjan problemas derivados de este uso. Los programadores desempean un rol clave en esta fase porque disean, codifican y elimina errores sintcticos de los programas de cmputo. Si el programa se ejecutar en un entorno de mainframe, se debe crear un lenguaje de control de trabajos (JCL, Job Control Language). Para garantizar la calidad, un programador podra efectuar un repaso estructurado del diseo o del cdigo con el propsito de explicar las partes complejas del programa a otro equipo de programadores.
Prueba y Mantenimiento del Sistema. Antes de poner el sistema en funcionamiento es necesario probarlo. Es mucho menos costoso encontrar los problemas antes que el sistema se entregue a los usuarios. Una parte de las pruebas las realizan los programadores solos, y otra la llevan a cabo de manera conjunta con los analistas de sistemas. Primero se realiza una serie de pruebas con datos de muestra para determinar con precisin cuales son los problemas y posteriormente se realiza otra con datos reales del sistema actual. El mantenimiento del sistema de informacin y su documentacin empiezan en esta fase y se llevan a cabo de manera rutinaria durante toda su vida til. Gran parte del trabajo habitual del programador consiste en el mantenimiento, y las empresas invierten enormes sumas de dinero en esta actividad. Parte del mantenimiento, como las actualizaciones de programas, se pueden realizar de manera automtica a travs de un sitio Web. Muchos de los procedimientos sistemticos que el analista emplea durante el ciclo de vida del desarrollo de sistemas pueden contribuir a garantizar que el mantenimiento se mantendr al mnimo.
Implementacin y Evaluacin del Sistema. Esta es la ultima fase del desarrollo de sistemas, y aqu el analista participa en la implementacin del sistema de informacin. En esta fase se capacita a los usuarios en el manejo del sistema. Parte de la capacitacin la imparten los fabricantes, pero la supervisin de esta es responsabilidad del analista de sistemas. Adems, el analista tiene que planear una conversin gradual del sistema anterior al actual. Este proceso incluye la conversin de archivos de formatos anteriores a los nuevos, o la construccin de una base de datos, la instalacin de equipo y la puesta en produccin del nuevo sistema. Se menciona la evaluacin como la fase final del ciclo de vida del desarrollo de sistemas principalmente en reas del debate. En realidad, la evaluacin se lleva a cabo durante cada una de las fases. Un criterio clave que se debe cumplir es si los usuarios a quienes va dirigido el sistema lo estn utilizando realmente. Debe hacerse hincapi en que, con frecuencia, el trabajo se sistemas es cclico. Cuando un analista termina una fase del desarrollo de sistemas y pasa a la siguiente, el surgimiento de un problema podra obligar al analista a regresar a la fase previa y modificar el trabajo realizado.
El Ciclo de Vida del Desarrollo de Sistemas (Roger S. Pressman)
El Modelo en Cascada. Algunas veces llamado el "Ciclo de Vida Clsico", sugiere un enfoque sistemtico, secuencial hacia el desarrollo del software, que se inicia con la especificacin de requerimientos del cliente y que continua con la planeacin, el modelado, la construccin y el despliegue para culminar en el soporte del software terminado. Dentro de los problemas que algunas veces se encuentran al aplicar el modelo en cascada estn: 1. Es muy raro que los proyectos reales sigan el flujo secuencial que propone el modelo. A pesar de que el modelo lineal incluye iteraciones, lo hace de manera indirecta. Como resultado, los cambios confunden mientras el equipo de proyecto acta. 2. Con frecuencia es difcil para el cliente establecer todos los requisitos de manera explicita. El modelo en cascada lo requiere y se enfrentan dificultades al incorporar la incertidumbre natural presente en el inicio de muchos proyectos. 3. El cliente debe tener paciencia. Una versin que funcione de los programas estar disponible cuando el proyecto este muy avanzado. Un error grave ser desastroso si no se detecta antes de la revisin del programa. En un anlisis interesante de proyectos reales, Bradac (BRA94) concluyo que la naturaleza lineal del modelo en cascada conduce a estados de bloqueo en los cuales algunos miembros del equipo del proyecto deben esperar a otros para terminar tareas pendientes. De hecho, el tiempo de espera puede superar el que se aplica en el trabajo productivo. El estado de bloqueo tiende a ser ms comn al principio y al final del proceso secuencial. En la actualidad, el trabajo del software esta acelerado y sujeto a una cadena infinita de cambios (caractersticas, funciones y contenido de la informacin). Con frecuencia el modelo en cascada no es apropiado para
dicho trabajo. Sin embargo, puede servir como un modelo de proceso til en situaciones donde los requerimientos estn fijos y donde el trabajo se realiza. Hasta su conclusin de una manera lineal.
Modelos de Proceso Incrementales. En muchas situaciones los requisitos iniciales del software estn bien definidos en forma razonable, pero el enfoque global del esfuerzo de desarrollo excluye un proceso puramente lineal. Adems, quiz haya una necesidad imperiosa de proporcionar de manera rpida un conjunto limitado de funcionalidad para el usuario y despus refinarla y expandirla en las entregas posteriores del software. En estos casos se elige un modelo de proceso diseado para producir el software en forma incremental. - El Modelo Incremental. Combina elementos del modelo en cascada aplicado en forma iterativa. Este modelo aplica secuencias lineales de manera escalonada conforme avanza el tiempo en el calendario. Cada secuencia lineal produce Incrementos del software (MCD93). Por ejemplo, el software procesador de texto, desarrollado con el paradigma incremental en su primer incremento, podra realizar funciones bsicas de administracin de archivos, edicin y produccin de documentos; en el segundo incremento, ediciones mas sofisticadas, y tendra funciones mas complejas de produccin de documentos; en el tercer incremento, funciones de correccin ortogrfica y gramatical; y en el cuarto, capacidades avanzadas de configuracin de pagina. Por lo general, al utilizar un modelo incremental el primer incremento es un producto esencial. Es decir, se incorporan los requisitos bsicos, pero muchas caractersticas suplementarias no se incorporan. El producto esencial queda en manos del cliente. Como resultado de la evaluacin se desarrolla un plan para el incremento siguiente. El plan afronta la modificacin del producto esencial con el fin de satisfacer de mejor manera las necesidades del cliente y la entrega de caractersticas y funcionalidades adicionales. Este proceso se repite despus de la entrega de cada incremento mientras no se haya elaborado el producto completo. El modelo de proceso incremental, al igual que la
construccin de prototipos y otros enfoques evolutivos, es iterativo por naturaleza. Pero a diferencia de la construccin de prototipos, el modelo incremental se enfoca en la entrega de un producto operacional con cada incremento. Los primeros incrementos son versiones incompletas del producto final, pero proporcionan al usuario la funcionalidad que necesita y una plataforma para evaluarlo. - El Modelo DRA. El Desarrollo Rpido de Aplicaciones (DRA) es un modelo de proceso de software incremental que resalta un ciclo de desarrollo corto. El modelo DRA es una adaptacin a alta velocidad del modelo en cascada en el que se logra el desarrollo rpido mediante un enfoque de construccin basado en componentes. Si se entienden bien los requisitos y se limita el mbito del proyecto, el proceso DRA permite que un equipo de desarrollo cree un Sistema Completamente Funcional dentro de un periodo muy corto. Como otros modelos de proceso, el enfoque DRA cumple con las actividades genricas del marco de trabajo que ya se han presentado. La Comunicacin trabaja para entender el problema de negocios y las caractersticas de informacin que debe incluir el Software. La Planeacin es esencial porque varios equipos de software trabajan en paralelo sobre diferentes funciones del sistema. El Modelado incluye tres grandes fases Modelado de Negocios, Modelado de Datos y el Modelado del Proceso, y establece representaciones del diseo que sirven como base para la actividad de construccin del modelo DRA. La Construccin resalta el empleo de componentes de software existente y la aplicacin de la generacin automtica de cdigo. Por ultimo, el Despliegue establece una base para las iteraciones subsecuentes, si estas son necesarias.
Modelos Especializados de Proceso Los modelos especializados de proceso adoptan muchas caracteristicas de uno o ms de los modelos convencionales. de las
- Desarrollo basado en Componentes. El Modelo de Desarrollo Basado en Componentes (DBC) incorpora muchas de las caracteristicas del modelo en espiral. Es evolutivo por naturaleza y exige un enfoque iterativo para la creacin del software. Las actividades de modelado y construccin comienzan con la identificacin de los componentes candidatos. Estos componentes se pueden disear como mdulos de software convencionales o como clases o paquetes de clases orientados a objetos. Sin importar la tecnologa que se aplique en la creacin de los componentes, el modelo de desarrollo basado en componentes incorpora los siguientes pasos (implementados mediante un enfoque evolutivo): Los productos basados en componentes disponibles se investigan y evalan para el dominio de aplicacin en cuestin. Se consideran los aspectos de integracin de componentes.
Se disea una arquitectura de software, para adaptar los componentes. Los componentes se integran a la arquitectura. Se realizan pruebas detalladas, para asegurar una funcionalidad apropiada.
El modelo de desarrollo basado en componentes conduce a la reutilizacin del software, la cual proporciona beneficios a los ingenieros de software. Con base en estudios de reutilizacin. - El modelo de mtodos formales. Este modelo comprende un conjunto de actividades que conducen a la especificacin matemtica del software de computadora. Los mtodos formales permiten que un ingeniero de software especifique, desarrolle y verifique un sistema basado en computadora al aplicar una notacin matemtica rigurosa. Cuando los mtodos formales se utilizan durante el diseo sirven como base para la verificacin de programas y, por consiguiente, permiten que el ingeniero de software descubra y corrija errores que de otra manera podran no haberse detectado. A pesar de que aun no existe un enfoque establecido, los modelos de mtodos formales ofrecen la promesa de un software libre de defectos. Sin embargo, se ha mencionado una gran preocupacin acerca de su aplicabilidad en su entorno de gestin: En la actualidad, el desarrollo de modelos formales es muy caro y consume mucho tiempo. Se requiere una capacitacin detallada, debido a que pocos responsables del desarrollo de software cuentan con los antecedentes necesarios para aplicar mtodos formales. Es difcil la utilizacin de estos modelos como un mecanismo de comunicacin con clientes que no tienen muchos conocimientos tcnicos. - Desarrollo del Software Orientado a Aspectos. Sin importar el proceso de software que se elija, los constructores de software complejo implementan de manera invariable un conjunto especfico de caracteristicas, funciones y contenido de informacin. Estas caracteristicas especficas del software se modelan como componentes y despus se construyen dentro del contexto de una
arquitectura
de
sistema.
Conforme
los
sistemas
basados
en
computadora se vuelven mas elaborados, ciertos intereses, propiedades requeridas para el cliente o reas de inters tcnico abarcan toda la arquitectura. Algunos intereses son propiedades de alto nivel de un sistema (seguridad, falta de tolerancia). Otros intereses afectan las funciones, mientras que otros son sistemticos. Cuando los intereses se relacionan con mltiples funciones, caracteristicas e informacin del sistema, con frecuencia se denominan Intereses Generales. Los requerimientos de aspectos definen estos intereses generales que ejercen un impacto a travs de la arquitectura del software. El desarrollo de software orientado a aspectos (POA), es un paradigma de la ingeniera del software relativamente nuevo que proporciona un proceso y enfoque metodolgico para definir, especificar, disear y construir aspectos, mecanismos ms all de subrutinas y legados para localizar la expresin de un inters general.
El Proceso Unificado. De alguna manera, el proceso unificado (PU) es un intento encaminado a reunir los mejores rasgos y caracteristicas de modelos de procesos de software, pero los caracteriza de manera que implementa muchos de los mejores principios del desarrollo gil de software. El proceso unificado reconoce la importancia de la comunicacin con el cliente y los mtodos encaminados a describir el punto de vista del cliente con respecto a un sistema. El PU enfatiza el importante papel de la arquitectura de software, y ayuda al arquitecto a enfocar la reutilizacin. Sugiere un flujo de proceso iterativo e incremental y que proporciona el sentido evolutivo esencial en el desarrollo del software moderno. - Fases del Proceso Unificado. Se han finalizado cinco actividades genricas del marco de trabajo y se ha explicado que estas se pueden aplicar para describir cualquier modelo de proceso del software.
La fase de inicio. Del PU abarca la comunicacin con el cliente y las actividades de planeacin. Al colaborar con los clientes y usuarios finales se identifican los requisitos de negocios para el software, se propone una arquitectura aproximada para el sistema, y se desarrolla un plan para la naturaleza iterativa e incremental del sistema subsiguiente. Los requisitos fundamentales de negocios se describen a travs de un conjunto preliminar de casos de uso que describen cuales caracteristicas y funciones son deseables para cada clase importante de usuarios. La fase de elaboracin. Abarca la comunicacin del cliente y las actividades de modelado del modelo genrico del proceso. La elaboracin refina y expande los casos de uso preliminares que se desarrollaron como la parte de la fase de inicio adems, expande la representacin arquitectnica para incluir cinco visiones diferentes del software el modelo de caso de uso, el modelo de anlisis, el modelo de diseo, el modelo de implementacin y el modelo de despliegue. La fase de construccin. Es idntica a la actividad de construccin definida para el proceso genrico del software. Si se utiliza el modelo arquitectnico como entrada, la fase de construccin desarrolla o adquiere los componentes del software que harn que cada caso de uso sea operativo para los usuarios finales. Lograr esto requiere que los modelos de anlisis y diseo iniciaron durante la fase de elaboracin se completen para
reflejar la versin final del incremento del software. La fase de transicin. Abarca las ltimas etapas de la actividad genrica de construccin y la primera parte de la actividad genrica de despliegue. El software se entrega a los usuarios finales para realizar pruebas beta, y la retroalimentacin del usuario reporta tanto defectos como cambio necesarios. Adems, el equipo de software crea la informacin de soportes necesaria para el lanzamiento.
La fase de produccin. Coincide con la actividad de despliegue

del proceso genrico. Durante esta fase se monitorea el uso subsiguiente del software, se proporciona el soporte para el ambiente operativo, y se reciben y evalan los informes de
defectos y los requerimientos de cambio.es probable que mientras se realizan las fases de construccin, transicin y produccin ya se hayan iniciado los trabajos para el siguiente incremento del software.
El Ciclo de Vida del Desarrollo de Sistemas (James Seen)
El desarrollo de sistemas, un proceso formado por las etapas de anlisis y diseo, comienza cuando la administracin o algunos miembros del personal encargado de desarrollar sistemas, detectan un sistema de la empresa que necesita mejoras. El mtodo del ciclo de vida para desarrollo de sistemas (SDCL) es el conjunto de actividades que los analistas, diseadores y usuarios realizan para desarrollar e implantar un sistema de informacin. El ciclo de vida de desarrollo de un sistema segn James Seen consta de seis funciones que se explican de la siguiente manera:
Investigacin Preliminar La solicitud para recibir ayuda de un sistema de informacin puede originarse por varias razones; sin importar cuales sean 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 investigacin de sistemas, la solicitud de proyecto debe examinarse para determinar con precisin lo que el solicitante desea. Estudio de factibilidad: Un resultado importante de la investigacin preliminar es la determinacin de que el sistema solicitado sea factible. Aprobacin de la solicitud: No todos los proyectos solicitados son deseables o factibles. Algunas organizaciones reciben tantas solicitudes de sus empleados que solo es posible atender unas cuantas. Sin embargo, aquellos proyectos que son deseables y factibles deben incorporarse en los planes. En algunos casos el desarrollo puede comenzar inmediatamente, aunque lo comn es que los miembros del equipo de sistemas se encuentren ocupados con otros proyectos.
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 encuentran 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. 2. 3. 4. 5. Qu es lo que se hace? Cmo se hace? Con que frecuencia se presenta? Qu tan grande es el volumen de transacciones o de decisiones? 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 que lo origina? Para contestar estas preguntas, el analista conversa con varias personas para reunir detalles relacionados con los procesos de la empresa, sus
opiniones sobre por qu ocurren las cosas, las soluciones que proponen y sus ideas para cambiar el proceso. Conforme se renen los detalles, los analistas estudian los datos sobre requerimientos con la finalidad de identificar las caractersticas que deben 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 denomina diseo fsico. Los analistas de sistemas comienzan el proceso de diseo identificando los reportes y dems salidas que deben producir el sistema. El diseo de un sistema tambin indica los datos de entrada, aquellos que sern calculados y los que deben ser almacenados. As mismo se escriben con todo detalle los procedimientos de clculo y los datos individuales. Los diseadores seleccionan las estructuras de archivos y los dispositivos de almacenamiento, tales como disco y cintas magnticos o incluso archivos en papel. Los diseadores son los responsables de dar a los programadores las especificaciones de software completa 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 regla general, los programadores (o analistas programadores) que trabajan en las grandes organizaciones pertenecen a un grupo permanente de profesionales, tal como se indica en
la narracin del captulo. En empresas pequeas que 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 que ciertos procedimientos se codifican en determinada forma.
Prueba de 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 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 despus se examinan los resultados. En ocasiones se permiten que varios utilicen el sistema para que los analistas observen si tratan de emplearlos en formas no previstas. Es preferible descubrir cualquier sorpresa antes de que la organizacin implante el sistema y depende de l. En muchas organizaciones, las pruebas son conducidas por personas ajenas al grupo que escribieron los programadores 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 utilizarlas. Dependiendo del tamao de la organizacin que se empleara la aplicacin y el riesgo asociado con su uso, puede elegirse comenzar la operacin del sistema solo en un rea de la empresa, por ejemplo en un departamento o con una o dos personas. Algunas veces se deja que los dos 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.
Clasificacin Propia: 1. 2. 3. 4. 5. 6. 7. Identificacin de las necesidades Estudio de viabilidad Anlisis econmico Anlisis tcnico Desarrollo y Documentacin del Software Prueba y Mantenimiento del Sistema Implementacin y Evaluacin del Sistema
Bibliografa:
Anlisis y Diseo de Sistemas de Informacin (2. Edicin) James A. Seen Editorial McGRAW-HILL INTERAMERICANA DE MEXICO, DF. S.A DE C.V Atlacomulco, Pag. 499-501 ISBN 0-07-05623-9 Ingeniera del Software. Un enfoque practico (6. Edicin)
Nancy Elizabeth Aguilar Hernndez Joanna Karina Morales Morales Roger S. Pressman
Editorial McGRAW-HILL INTERAMERICANA DE ESPAA, S.A. DE C.V ISBN: 0-07-052182-4 ISBN 84-481-1186-9 Mxico, DF. Pag, 48-73 Anlisis y Diseo de Sistemas (6. Edicin) Kenneth E. Kendall & Julie E. Kendall Editorial Pearson Educacin ISBN 970-26-0577-6 Mxico, Pag, 10-13

El Ciclo de Vida Del Desarrollo de Sistemas

Uploaded by

Document Information

Copyright

Available Formats

Share this document

Share or Embed Document

Sharing Options

Did you find this document useful?

Is this content inappropriate?

Copyright:

Available Formats

El Ciclo de Vida Del Desarrollo de Sistemas

Uploaded by

Copyright:

Available Formats

Nancy Elizabeth Aguilar Hernndez Joanna Karina Morales Morales

Fundamentos de Ingeniera de Software Equipo 8