Captulo 2 - El ciclo vital de desarrollo de sistemasEstructurado Anlisis y Diseo de SistemasYJ.B. DixitRaj KumarLaxmiPublications 2007CitationCaptulo 2: El ciclo vital de desarrollo de sistemas2.1 INTRODUCCINUn sistemase define como un conjunto de componentes relacionados que interactan para realizar una tarea con el fin de alcanzar un objetivo. Un sistema no puede funcionar muy bien, pero que sin embargo es un sistema. El punto de diseo y anlisis de sistemas es determinar cmo el sistema funciona y tomar las medidas necesarias para hacer que funcione mejor.El ordenador de la empresa de un sistema de informacin consiste en el hardware, software, personas, procedimientos y datos, as como las comunicaciones. Estos trabajan juntos para proporcionar a las personas con la informacin de funcionamiento de la organizacin.Una organizacin puede sentir la necesidad de un sistema debido a una variedad de razones.Algunos ejemplosson: Una sola persona a la que cree que hay que cambiar algo mal es todo lo que se necesita para tener el proyecto. Un empleado puede influir en el supervisor. Un cliente o proveedor puede tener la atencin de alguien de alta direccin. Alta direccin pueden decidir independientemente para que echara un vistazo a un sistema que se parece ineficaz. Un comit de direccin puede ser formado para decidir que de los muchos posibles los proyectos deben ser trabajadas.Tres tipos de participantes hay en el proyecto como se indica a continuacin: Los Usuarios .El sistema que se est examinando debeestar siemprepreparado en consulta con los usuarios, si barren los pisos, a los investigadores, o a los clientes. De hecho, si el usuario participacin en el anlisis y diseo es insuficiente; el sistema puede fracasar por falta de aceptacin. Gestin. Los administradores de la organizacin tambin debe ser consultado sobre el sistema. Personal tcnico. Los miembros de los sistemas de informacin de la compaa (ES) departamento, que consta de los analistas de sistemas y programadores, deben participar en el proceso. Para una cosa,es posible que tengan que ejecutar el proyecto. Incluso si no lo hacen, tendrn que trabajar con el exterior es que la gente contratada para hacer el trabajo.Proyectos complejos que requieren uno o varios analistas de sistemas. Un analista de sistemasespecialista de informacin que realiza anlisis de sistemas, diseo y ejecucin de la misma.La labor del analista es el estudio de las necesidades de informacin y comunicaciones de una organizacin con el fin de determinar qu cambios son necesarios para ofrecer una mejor informacin a las personas que la necesitan. "Mejor" informacin significa que la informacin que se resume en el acrnimo "CARRO", completa, precisa, pertinente y oportuna. El analista de sistemas logra este objetivo mediante la solucin de problemas de diseo y anlisis de sistemas.

2.2LAS SEIS FASES DE DISEO Y ANLISIS DE SISTEMASDiseo y anlisis de sistemases un seis a la fase procedimiento de solucin de problemas de un sistema de informacin y de mejorar.Las seis fases conforman lo que se conoce como el ciclo vital de desarrollo de sistemas. Elciclo vital de desarrollo de sistemas (SDLC) es elproceso paso a paso que muchas organizaciones siguen en diseo y anlisis de sistemas.Ya sea que se apliquen a una gran empresa o una de tres personas actividades de ingeniera y las seis fases de diseo y anlisis de sistemas son como se muestra en la Figura 2.1 . Las fases se solapan a menudo, y una nueva uno puede comenzar antes de que la vieja est terminado. Despus de las primeras cuatro fases, la gerencia debe decidir si ha de proceder a la siguiente fase.Datos proporcionados por el usuario y el examen es una parte esencial de cada fase.

Fig. 2.1 : Elciclo vital de desarrollo de sistemas (SDLC)2.2.1Investigacin PreliminarEl objetivo de la Fase 1,investigacin preliminar,es el de realizar un anlisis preliminar, proponer soluciones alternativas, describir los costos y los beneficios, y presentar un plan preliminar de las recomendaciones.2.2.1Investigacin PreliminarEl objetivo de la Fase 1,investigacin preliminar,es el de realizar un anlisis preliminar, proponer soluciones alternativas, describir los costos y los beneficios, y presentar un plan preliminar de las recomendaciones.Estos pasosse indican a continuacin:i. Realizar anlisis preliminar. Incluye los objetivos, naturaleza y alcance del problema.ii. Proponer alternativas de solucin: dejar solo el sistema, hacerlo ms eficiente, o construir un nuevo sistema.iii. Describir los costos y los beneficios de cada solucin.iv. Presentar un plan preliminar de las recomendaciones.Vamos a explicar en detalle: Realizar el anlisis preliminar. En este paso, usted necesita saber qu los objetivos de la organizacin y la naturaleza y el alcance del problema en estudio. Incluso si un problema se refiere slo a un pequeo segmento de la organizacin, puede estudiar de manera aislada. Usted tiene que averiguar cules son los objetivos de la propia organizacin. Entonces usted necesidad de ver cmo el problema que se est estudiando se ajusta a ellos. Proponer alternativas de solucin. Al ahondar en los objetivos de la organizacin y el problema especfico, puede ya han descubierto algunas soluciones. Otras posibles soluciones pueden venir de entrevistar a las personas dentro de la organizacin, los clientes o los clientes afectados, proveedores y consultores. Tambin se puede estudiar lo que sus competidores estn haciendo hoy en da. Con estos datos, entonces, usted tiene tres opciones. Se puede dejar el sistema tal como est, mejorar, o desarrollar un sistema nuevo. Describir los costos y los beneficios. Cualquiera de las tres alternativas es elegido, tendr los costos y beneficios. En este paso, es necesario indicar cules. Los costos pueden depender de los beneficios, que pueden ofrecer ahorros. Un amplio espectro de beneficios puede ser derivado. Un proceso puede ser acelerado y gil a travs de la eliminacin de pasos innecesarios, o en combinacin con otros procesos. Errores de entrada o salida redundante puede ser reducido. Sistemas y subsistemas pueden ser mejor integrados. Los usuarios pueden estar ms contentos con el sistema. Los clientes o proveedores de las interacciones con el sistema puede ser ms satisfactorio.Seguridadpuede ser mejorado. Los costos pueden ser cortados. Presentar un plan preliminar. Ahora, usted tiene que concluir todos sus conclusiones en un informe escrito. Los lectores de este informe sern los ejecutivos que estn en condiciones de decidir en qu direccin seguir de no hacer cambios, cambie un poco, o cambiar las cosas y cunto dinero para permitir que el proyecto. Usted debe describir las posibles soluciones, los costos y los beneficios y mencionar sus recomendaciones.2.2.2Anlisis de sistemaEl objetivo de la Fase 2,anlisis del sistema,es la de recopilar y analizar los datos y redactar un informe. En esta segunda fase del SDLC, usted podr seguir el curso que la administracin ha indicado despus de haber ledo su Fase 1 informe de viabilidad. Estamos suponiendo que hayan pedido a realizar Fase 2-para hacer un cuidadoso anlisis o estudio sobre el sistema actual, a fin deentender cmo el nuevo sistema que se propone sera diferente. Este anlisis se deben tener en cuenta tambin cmo las posiciones y tareas tendr que cambiar si se quiere que el nuevo sistema entre en vigor.Los pasos se dana continuacin:i. Recopilar datos mediante el uso de herramientas de documentos escritos, entrevistas, cuestionarios y observaciones.ii. Anlisis de los datos, utilizandoherramientas de modelado: grid los grficos, tablas de decisin, los diagramas de flujo de datos, los sistemas grficos de flujo, diagramas de conectividad.iii. Escribir un informe.Vamos a explicar en detalle: Recopilacin de datos. En la recoleccin de datos, revisar los documentos escritos, los empleados y directivos entrevista, elaboracin de cuestionarios y observar a la gente y los procesos de su lugar de trabajo. Analizar los datos.Una vez que la informacin ha sido recopilada, usted tiene que venir a solucionar y lo analicen. Muchas herramientas de anlisis, o las herramientas de modelacin, estn disponibles.Herramientas de creacin de modelos permiten queun analista de sistemas para grfico actual, o de la ilustracin, las representaciones de un sistema.Un ejemplo de una herramienta de modeladoes undiagrama de flujo de datos(DFD), el cualmuestra grficamente el flujo de datos a travs de un sistema-es decir, los procesos esenciales de un sistema, junto con las entradas, salidas y archivos.(VerFigura 2.2 ).

Fig. 2.2 :Diagrama de flujo de datos Escribir un informe. Despus de completar el anlisis, es necesario que el documento la primera fase.Este informe de gestin debe tener tres partes:Se debe explicar cmo funciona el sistema existente.Debe explicar los problemas con el sistema existente.Debe describir los requisitos para el nuevo sistema y formular recomendaciones sobre qu hacer a continuacin.En esta etapa, no un montn de dinero que se han gastado en el diseo y anlisis de sistemas. Si los costos de ir hacia adelante parece prohibitivo, este es un buen momento para que los administradores leer el informe de poner fin. De lo contrario, se le pedir que vaya adelante con la Fase 3.2.2.3Diseo del sistemaEl objetivo de la Fase 3,diseo de sistemases hacer un diseo preliminar y, a continuacin, un detalle del diseo, y escribir un informe.Los pasos se dana continuacin:i. Hacer un diseo preliminar, mediante el estudio de casos (Computer Aided Software Engineering) herramientas, desarrollo de prototipos herramientas y software de gestin de proyectos, entre otros.ii. Hacer un diseo de detalle, definicin de los requisitos de salida, entrada, almacenamiento y procesamiento y controles del sistema y copia de seguridad .iii. Escribir un informe.En esta tercera fase del SDLC, esencialmente crear un "borrador" y, a continuacin, un "detalle" del proyecto sistema de informacin propuesto.Vamos a explicar los pasos mencionados anteriormente en detalle: Hacer un diseo preliminar. Un diseo preliminardescribe el general las capacidades funcionales de un sistema de informacin propuesto. Tambin se examinan los requisitos del sistema y, a continuacin, considere los componentes principales del sistema bajo consideracin. Por lo general varios sistemas alternativos (llamados los candidatos) son considerados, y de los costes y beneficios de cada uno son evaluados.Algunas de las herramientas que se pueden utilizar en el diseo sonherramientas ysoftware de gestin de proyectos.CASO (Computer Aided Software Engineering) herramientasson programas que automatizan diversas actividades del SDLC en varias fases. Esta tecnologa est diseada para acelerar el proceso de desarrollo de sistemas y para mejorar la calidad de los sistemas resultantes. Estas herramientas, que tambin se conocen comoherramientas de diseo automatizado, puede utilizarse enotras etapas del SDLC. Algunos ejemplos de este tipo de programas sonExcelerator, Iconix, Arquitecto de sistemas, y Powerbuilder.Se refiere al uso de prototipos las estaciones de trabajo, herramientas CASE y otras aplicaciones de software para construir modelos de trabajo de los componentes del sistema, de manera que puedan ser rpidamente probado y evaluado. Por lo tanto, un prototipo es unlimitado sistema de trabajo desarrollado para probar conceptos de diseo. Un prototipo, que se pueden construir en pocos das, permite a los usuarios encontrar de inmediato cmo un cambio en el sistema podran beneficiarse ellos. Por ejemplo, un analista de sistemas puede desarrollar un men comoposible visualizar en pantalla, que los usuarios puedan probar. El men puede ser rediseado o afinar, si es necesario.Software de gestin de proyectosconsta de programas utilizados para planificar, programar y controlar a las personas, los costes y los recursos necesarios para completar el proyecto a tiempo. Hacer un diseo de detalle: undiseo de detallese describe cmo un sistema de informacin propuesto ofrecer las capacidades generales descritos en el diseo preliminar. El diseo de detalle, por lo general considera los siguientes componentes del sistema en este orden:Requisitos de salidaRequisitos de entradaRequisitos de almacenamientoRequisitos de procesamiento, yControl del sistema y copia de seguridad. Escribir un informe. Todo el trabajo de los diseos preliminares y detalle en un amplio y detallado informe. Cuando pase este informe a la administracin superior, probablemente tambin hacer algn tipo de presentacin o discurso.2.2.4Desarrollo del SistemaEn la Fase 4,desarrollo de sistemas,el analista de sistemas o a otros miembros de la organizacin a desarrollar o adquirir el software, adquirir el hardware y, a continuacin, probar el sistema.Los pasos se dana continuacin:i. Adquirir el software.ii. Adquirirhardware .iii. Pruebe el sistema.Dependiendo del tamao del proyecto, esta fase probablemente a la organizacin los gastos considerables sumas de dinero. Tambin podra implicar pasar un montn de tiempo. Sin embargo, al final, debera tener un sistema viable.Vamos a explicar los pasos mencionados anteriormente en detalle: Desarrollar o adquirir el software .Durante la fase de diseo el analista de sistemas que han tenido que hacer frente a lo que se denomina "hacer o comprar" decisin, pero sin duda que la decisin no puede ser evitado en esta etapa. En lacreacin o destruccin de comprar,usted podr decidir si tiene que crear un programa personalizado que han escrito o comprar, es decir basta con adquirir un paquete de software existentes. A veces los programadores deciden que puede comprar un programa existente y modificar, en vez de escribir desde el principio.Si se decide crear un nuevo programa, entonces la pregunta es si se va a utilizar la organizacin del propio personal de programadores o contratar a programadores contratados (subcontratacin). Cualquiera que sea la forma que se vaya, la tarea podra llevar varios meses. Adquirir hardware .Una vez que el software ha sido elegido, el hardware para ejecutar debe ser adquirido o actualizado. Es posible que el nuevo sistema no requiere ningn hardware nuevo. Tambin es posible que el nuevo hardware a un precio enorme y muchos elementos: las microcomputadoras, mainframes, monitores, mdems, y muchos otros dispositivos. La organizacin podr encontrar es mejor que alquilar en lugar de comprar algunos de los equipos, sobre todo porque, como sabemos, la ley de Moore), chip capacidad tradicionalmente se ha duplicado cada 18 meses. Pruebe el sistema. Con el software y el hardware adquirido, ahora puede comenzar a probar el sistema. Las pruebas se realiza generalmente en dos etapas:pruebas unitarias,pruebas de sistema, a continuacin,.En las pruebas unitarias, el rendimiento de cada una de las partes, utilizando el test (, o muestra) los datos. Si el programa est escrito como un esfuerzo de colaboracin de varios programadores, cada parte del programa se evala por separado.En las pruebas del sistema, las piezas estn enlazados entre s y los datos de prueba se utiliza para ver si las partes trabajen juntas. En este punto, los datos de la empresa pueden ser utilizados para probar el sistema. El sistema tambin est probado con errneas y las enormes cantidades de datos para ver si el sistema puede hacerse a fallar ( "crash".Al final de este largo proceso, la organizacin tendr un sistema de informacin factible, uno est listo para la fase de ejecucin.2.2.5Aplicacin de los sistemasSi el nuevo sistema de informacin trata de algunos equipos de mano, una elaborada red de telecomunicaciones, ni costosos mainframes, la quinta fase contar con la participacin de unos una estrecha coordinacin a fin de que el sistema no slo viable sino un xito.Fase 5,implementacin de sistemas,consiste en convertir el hardware, el software y los archivos al nuevo sistema y formacin de los usuarios.Los pasos se dana continuacin:i. Convertir hardware, software y de los archivos a travs de uno de los cuatro tipos de conversiones: directo, paralelo, por etapas, o piloto.ii. Recopilar documentacin final.iii. Capacitar a losusuarios .Vamos a explicar los pasos mencionados anteriormente en detalle: Convertir al nuevo sistema. Conversin,el proceso de transicin del antiguo sistema de informacin para una nueva, requiere convertir hardware, software y archivos. Hay cuatro estrategias de conversin del control: directo,paralelo, escalonados, ypiloto . Aplicacin directasignifica que el usuario simplemente se detiene con el antiguo sistema y comienza a usar el nuevo. El riesgo de este mtodo debera ser evidente: Qu pasa si el nuevo sistema no funciona? En caso de que el antiguo sistema ha sido verdaderamente abandonado, no hay nada en que apoyarse.Medios de ejecucin paralelaque los viejos y nuevos sistemas son operados al lado hasta que el nuevo sistema ha demostrado que es fiable y en ese momento el antiguo sistema se suspendi. Por supuesto, hay ventajas en tomar este enfoque cauteloso. Si el nuevo sistema falla, por lo que la organizacin puede cambiar de nuevo a la antigua. La dificultad de este mtodo es la costa de pagar por el equipo y a la gente a mantener dos sistemas funcionando al mismo tiempo.Fases de implementacinsignifica que algunas partes de las nuevas fases de sistema por separado, ya sea en distintos momentos (paralelo) o todos a la vez en grupos (directo).Aplicacin Experimentalsignifica que todo el sistema est probado pero slo para algunos usuarios. Una vez que la confiabilidad se ha demostrado, el sistema se lleva a cabo con el resto de los usuarios previstos. El enfoque experimental an tiene sus riesgos, ya que la totalidad de los usuarios de un grupo determinado se encuentren fuera del sistema antiguo. Sin embargo, los riesgos se limita a una pequea parte de la organizacin. Recopilar documentacin final. Documentacin de un sistema consta de descripcin por escrito de especificacin del sistema, su diseo, cdigo, los procedimientos de operacin, etc. es muy til para los usuarios y el mantenimiento los programadores. Documentacin se pueden clasificar en dos tipos:Documentacin para los usuarios-en l se describe cmo utilizar el sistema.Documentacin de mantenimiento Programadores-tambin se denomina documentacin tcnica y se utiliza para modificacin del sistema en algunas etapas posteriores. Documentacin de un sistema debe comenzar con la definicin del sistema. Es muy difcil pensar en la documentacin que se encuentra en el extremo. Capacitar a los usuarios .Estn disponibles varias herramientas para familiarizar a los usuarios con un nuevo sistema de documentacin (manuales de instrucciones) a los vdeos de clases en vivo a uno-a-uno, al lado de maestro-alumno. A veces, el entrenamiento se lleva a cabo por la organizacin de los empleados, en otras ocasiones, se lleva a cabo en rgimen de subcontratacin.2.2.6Mantenimiento de los sistemasFase 6,mantenimiento de los sistemas,ajusta y mejora el sistema de auditoras del sistema y las evaluaciones peridicas y haciendo cambios basados en las nuevas condiciones.La sexta fase es para mantener en funcionamiento el sistema a travs del sistema auditoras y evaluaciones peridicas.Incluso con la conversin realizada y los usuarios capacitados, el sistema no slo su propio funcionamiento. Existe una sexta y nunca termina de fase en la que el sistema de informacin debe ser supervisada para garantizar que se lleva a cabo con xito. Mantenimiento incluye no slo mantener la maquinaria en funcionamiento sino tambin actualizar y mejorar el sistema para mantener el ritmo de los nuevos productos, servicios, clientes, reglamentos del gobierno y de otros requisitos.As que podemos concluir que "el mejor mantenimiento del sistema, el mejor satisfaccin del usuario".2.3DOCUMENTACIN DEL SISTEMA CONSIDERACIONES2.3.1Principios de Documentacin del sistemaCon frecuencia se pasa por alto una parte e infravalorado de un sistema es su documentacin.Documentacin es unaparte integral de las distintas fases del ciclo de vida y se produce como parte de la fase. Por desgracia, muchas personas ver documentacin como una formalidad que se realiza al final de la etapa en lugar de trabajo a realizar como parte integrante de una etapa. Este resultado ineficaz, mal escrito y documentacin incompleta, con lo que no es til.Documentacin es uno de los principales medios de comunicacin. Es el medio de comunicacin, que sobrevive en el tiempo una vez que el analista ha abandonado el proyecto, y el equipo se ha disuelto de la documentacin es lo que queda. Es a travs de los documentos que los usuarios a conocer el sistema y que es necesario hacer referencia a los documentos a utilizar el sistema. Documentacin constituye un registro escrito para el trabajo; establece diseo y los criterios de funcionamiento de las etapas del proyecto.Hay que tener cuidado cuando se crea una buena y eficaz documentacin.Documentacin debera ser creados como parte del proceso y no se escriben despus del hecho. Documentacin es el producto de todas las fases. Debe ser un trabajo de producto a lo largo de todo el ciclo de vida. La tendencia a "postdocument" (documento despus del hecho) debe ser evitado.Toda la documentacin debe seguir ciertas normas que se prescriben para el proyecto o la organizacin.Documentacin debera ser examinado y aprobado para su liberacin. Debe estar disponible para todas las personas autorizadas que pueda necesitar para hacer referencia a l. Documentos obsoletos no deberan estar en circulacin para evitar confusiones.El procedimiento que se utilizar para peticin de cambio en la documentacin, a fin de evaluar y procesar dichos cambios, con el fin de examinar los cambios realizados y en la liberacin de la documentos modificados deben estar claramente establecidas. Las personas no autorizadas no debera ser capaz de cambiar la documentacin. Todos los cambios realizados en los documentos y las razones por las que se hicieron hay que sealar como parte de los documentos.Estndar utilizado para crear documentos suelen tratar los siguientes: Ttulo de la pgina y los documentos, junto con otros identificadores, como nombre de proyecto Las versionesde control de la informacin Los nombres deautor, revisor, aprobador Fecha de lanzamiento Nmero de versin Historia control de cambios Tabla de contenidos, figuras y tablas Alcance de los documentos Perfil lector Espera Definiciones yacrnimos Otros documentos para consultar (referencias especficas) Resumen/introduccin Resumen y conclusiones como resumen ejecutivo, si procede Cuerpo principalde los documentos Los apndices.El estilo que se utiliza debe asegurar que cada arte de los documentos se puede hacer referencia a algn identificador (ha).El idioma debe ser El lector atento a perfil Claro Conciso Amplio Corts Precisa Simple Fluye correctamente Fcil de leer y de entender Mantener la continuidad.Los documentos deben incluir todas las ilustraciones y tablas. Las referencias deben ser proporcionados por la facilidad del usuario.El estilo debe ser coherenteLas partidas, el estilo y la apariencia general debe ser coherente. La jerarqua de los documentos debe ser clara para el lector.Los editores tcnicos a veces se utilizan para garantizar que los documentos estn bien escritas.Por lo general, las organizaciones tienen normas para cada tipo de documentos. Por ejemplo, la organizacin puede tener un estndar de especificacin de requisitos que a cada uno de los temas que se han de tratar y el orden en el que se van a poner en los documentos. Estas normas son estndares de la industria derivada de las organizaciones basadas en los modelos de calidad experiencias anteriores y las opiniones de los directivos de la organizacin.2.3.2Tipos de documentacin y su importanciaDocumentacin se crea en cada fase de un proyecto. Los principales tipos de documentacin y su importancia se tabulan en la Tabla 2.1 .Tabla 2.1 :Tipos principales de la documentacin y su importancia

DocumentoImportancia

Solicitud de proyecto/Informacin Solicitud de servicio/Sistema de Informacin SolicitudInicia el proyecto y establece el primer "alcance" del sistema requerido.

ProyectoDirectivaCrea normalmente al final de investigacin inicial; es una clara declaracin de problema; constituye la base de la continuacin de los trabajos sobre el sistema.

Informe de ViabilidadPreparado como parte del estudio de viabilidad, que nos da los detalles del estudio, las opciones consideradas; ayuda a la administracin decidir si seguir adelante con una organizacin del sistema o no.

Las especificaciones de requisitos Sistema/ Anlisis de requisitos/Informe de AnlisisCreado durante el anlisis, lo que le proporciona al usuario, as como el diseador con un "qu" del sistema constituye la base para obtener retroalimentacin de los usuarios y su aprobacin. El pliego de condiciones aprobado constituye la entrada para la fase de diseo.

Sistema Plan de Seleccin/requisitos de tecnologaCreado en fase de estudio de viabilidad y modificado durante fase de anlisis; especifica el hardware y el software para que pueda adquirir para el sistema que se desarroll para ser; constituye la base para el proceso de adquisicin.

Las especificaciones de rendimientoCreado durante fase de anlisis como parte de las especificaciones de requisitos del sistema y, a veces, en un documento separado; especifica las especificaciones de rendimiento del sistema y es una aportacin importante para el diseo y las actividades de ensayo.

Las especificaciones de diseoDocumentos del alto nivel y diseo de nivel detallado. Constituye la base para el desarrollo real, por ejemplo, las especificaciones del mdulo se usa para escribir los programas y el diseo de datos de la construccin de la base de datos/estructura de archivos.

Las especificaciones del sistemaA veces ha creado al final de la fase de diseo como un documento consolidado que contenga los requisitos, diseo y seleccin del sistema.

Planes y especificaciones de pruebasEspecifica el enfoque de prueba y las pruebas reales que se va a realizar, constituye una de las bases para realizar las pruebas, tanto en tiempo de desarrollo y cuando el sistema est en mantenimiento.

Manual del usuarioCreado en la fase de desarrollo de los operadores cmo el sistema va a ser utilizado. UN amigable y fcil de usar hace que el uso del manual sistema de forma ms sencilla y ms prctico para el usuario.

Manual de OperacionesCreado en la fase de desarrollo para decirle al operador la forma de operar el sistema. Los operadores pueden no saber mucho sobre el sistema y esto debe ser lo suficientemente amplia como paracuidar de las dos operaciones normales y las condiciones de error.

Registros de los ProyectosLos registros creados por el trabajo en el proyecto y utilizar el sistema como Informes de revisin Registros de pruebas Las peticiones de cambio Los informes de evaluacin, etc.

Los documentos que forman las entradas al proceso de desarrollo, no se crean no se incluyen aqu.A menudo, documentos del plan son ignorados como son utilizadas principalmente en el equipo. Sin embargo, tambin son importantes los documentos de un proyecto para que funcione correctamente. Ejemplos de los principales documentos del plan y sus usos estn tabulados en la tabla 2.2 se muestra debajo:Tabla 2.2: Principalesdocumentos del Plan y sus usosOpen table as spreadsheet

PlanDescripcin

Plan de proyecto/Plan de CalidadUtilizado para planificar el uso de los recursos, programas, controles etc. de la realizacin de un proyecto con el tiempo, costo y calidad. Incluye revisiones y auditoras. Es necesario que peridicamente se refiere yactualizado por el director del proyecto en funcin de la evolucin de las situaciones.Tambin utilizadas por la direccin para revisar el proyecto.

Plan de Administracin de la configuracinUsa para asegurar el desarrollo de procedimientos de gestin de la configuracin se definen y utilizan. Establece lo que se necesita para controlar las versiones y temas relacionados con gestin de la configuracin.

Enfoque del Plan de pruebasEstablece la estrategia del plan general de la prueba que se utiliza a continuacin para ms detalles de las especificaciones de la prueba, los planes y paquetes de prueba.

Plan de mantenimientoEl enfoque de las actividades de mantenimiento y de control de los cambios y las necesidades de recursos correspondientes y los procedimientos de presentacin de informes son expuestas en este: se utiliza para gestionar las actividades de mantenimiento.

2.3.3Aplicar Disciplina Documentacin en una organizacinComo se mencion anteriormente, por desgracia, la documentacin se realiza generalmente despus de los hechos. De hecho, algunos de los equipos que tienen una "fase de documentacin" despus de que el resto de la obra, en la que los documentos son generados.La disciplina de la documentacin ha de ser aplicadas en una organizacin.Para asegurarse de que la cultura de la documentacin es una parte integral del sistema de trabajo equipo hbito, es necesario que la documentacin se considera una parte integral del trabajo.Esto significa que: Los presupuestos deben incluir documentacin. Se establezcan procedimientos para crear, revisar los documentos. No digo "tal y como est acabando el tiempo, simplemente se crea el sistema.Vamos a crear el documento ms tarde".Para reforzar el aspecto integral de la documentacin, "conclusin" de una actividad debe incluir la realizacin del documento asociado.Por ejemplo, Una fase no debe considerarse completa a menos que la documentacin est completa. Un programa no debe ser considerado como completo a menos que se ha requerido las lneas de comentarios. Prueba de la unidad de actividad no debe considerarse completa a menos que la prueba los paquetes correctamente y los registros estn disponibles.Tambin, en la siguiente fase no deben iniciarse a menos que una fase es "completa" con la documentacin.Documentacin (de la calidad necesaria) debe ser uno de los aspectos que se consideran al evaluar el trabajo.Para que la documentacin, la tarea de documentacin debera ser fcil.Para permitir que las personas documento fcil y adecuadamente organizacin deber tener en su lugar las normas que permiten que el personal sabe cmo el documento debe ser escrito. Esto asegura que la buena calidad de los documentos se crean fcilmente.Formacin en redaccin tcnica y talleres sistema de ayuda las personas escribir mejor. Un editor tcnico tambin se puede utilizar para proporcionar un aspecto ms profesional.Las herramientas deben estar disponibles para simplificar la tarea. Los procesadores de textos adecuados y las herramientas de dibujo, con plantillas configurado de forma adecuada para hacer la tarea ms fcil y a la reduccin de la resistencia.2.4MODELOS DE CICLO VITALDiferentes organizaciones y autores no se han puesto de acuerdo sobre un nico Sun. Consideremos diferentes modelos para ella.El SDLC tradicional en cascadaHay varias crticas al tradicional enfoque de ciclo de vida de desarrollo de sistemas. Una crtica se refiere a la forma en que el ciclo de vida est organizada. Para entender mejor estas crticas, lo mejor es ver la forma en que el ciclo de vida ha sido tradicionalmente descrita, la denominadacascada(vase la figura 2.3 ). Nota cmo el flujo del proyecto comienza en la fase de investigacin preliminar y de all se ejecuta "hacia abajo", a cada etapa posterior, al igual que un arroyo que se ejecuta desde un acantilado. A pesar de que el desarrollador original delmodelo cascada, W. W. Royce, llamado de retroalimentacin entre las fases de la cascada, esta informacin lleg a ser ignorado en su aplicacin. Se convirti en demasiado tentadora como para hacer caso omiso de la necesidad de retroalimentacin y para tratar cada una de las fases como completa en s, nunca una vez que haya terminado.

Fig. 2.3 : UNACascada tradicional SDLCTradicionalmente, una etapa termin y comenz otra vez se trata de un hito. El hito por lo general tom la forma de una entrega oespecificadasen la fase de salida. Por ejemplo, el diseo del producto es el conjunto de fsica detallada las especificaciones de diseo. Una vez que el hito se haba alcanzado y la nueva etapa iniciada, se hizo difcil para volver. Aun cuando las condiciones de la actividad empresarial sigue a cambio de bloqueo durante de los usuarios de los requisitos que se haban determinado previamente, aunque dichas necesidades han cambiado.Otra crtica a la tradicional en cascada SDLC es que el papel de los usuarios del sistema o los clientes se define de manera restrictiva. Las funciones de usuario a menudo se deleg en la determinacin de requisitos o las fases de anlisis del proyecto, en el que se supone que todos los requisitos se puede especificar con antelacin. Este tipo de hiptesis, junto con la limitada participacin de los usuarios, ha reforzado la tendencia de la cascada modelo para bloquear en los requisitos demasiado pronto, incluso despus de los negocios las condiciones haban cambiado.Adems, en virtud del enfoque tradicional en cascada, nebulosa y procesos inmateriales, tales como el anlisis y diseo se dan duro y rpido las fechas de realizacin, y el xito es medido en su inmensa mayora por si se cumplen las fechas. El enfoque de hito los plazos, en lugar de en la obtencin e interpretacin de informacin sobre el proceso de desarrollo, conduce a una concentracin insuficiente para hacer buenos anlisis y diseo. El enfoque en los plazos los resultados en los sistemas que no coinciden con las necesidades de los usuarios y que requieren mantenimiento, incrementando innecesariamente los costos de desarrollo. Diagnstico y solucin de un problema de software despus de la entrega del sistema a menudo es 100 veces ms caro que encontrar y arreglar lo que durante el anlisisy el diseo. El hecho de concentrarse en los plazos en lugar de sobre la buena prctica es necesario rectificar y esfuerzo de mantenimiento, que son caros. Segn algunas estimaciones, los gastos de mantenimiento de 40 a 70 por ciento de los gastos relativos al desarrollo de los sistemas. Frente a estos problemas, la gente que trabaja en el desarrollo de sistemas comenz a buscar la mejor forma de realizar diseo y anlisis de sistemas.Modelo evolutivo SDLCAlgunas personas consideran el ciclo de vida de una espiral,en la que estamos en constante ciclo a travs de las fases a diferentes niveles de detalle como se muestra en la Figura 2.4 .

Fig. 2.4 :El modelo espiralEl modelo espiral del ciclo de vida incorpora los elementos de riesgo. Tiene cuatro actividades principales que estn representados en los cuatro cuadrantes, que trabaja en pos de un sistema completo.Las cuatro actividadesson: Planificacin Anlisis de Riesgos Ingeniera Evaluacin de las necesidades del clienteSin embargo, el ciclo vital de desarrollo de sistemas utilizados en una organizacin es un conjunto ordenado de actividades realizadas y previstas para cada uno de los proyectos de desarrollo. Software es el ms evidente producto final del ciclo de vida; otros productos incluyen documentacin acerca del sistema y la forma en que se desarroll, as como a la capacitacin de los usuarios.Cada medio a grandes empresas y software personalizado cada productor tendr su propio ciclo de vida o metodologa de desarrollo de sistemas en su lugar.Por ejemplo, Merrill Lynch para la metodologa de desarrollocomo se indica a continuacin: Reunir los requisitos de los usuarios finales. Comenzar con diseo de alto nivel. Crear un plan para probar el software. Construir y probar un prototipo de aplicacin. Comienzan grandes obras de desarrollo.Incluso si una metodologa particular no parece ser un ciclo, en este sentido, probablemente descubrir que muchos de los pasos se realizan descargas DESCARGAS y las tcnicas y herramientas utilizadas. Aprender sobre diseo y anlisis de sistemas en el enfoque de ciclo de vida le servirn bien no importa que metodologa de desarrollo de sistemas que utilice.2.5DIFERENTES ENFOQUES DE MEJORA DE LAS CONDICIONES DE DESARROLLOEn un esfuerzo continuo para mejorar el diseo y anlisis de sistemas, diferentes enfoques se han desarrollado. Vamos a describir algunos importantes enfoques aqu. Los intentos de hacer desarrollo de sistemas menos de un arte, y ms de una ciencia por lo general se conoce comoingeniera de sistemasoingeniera de software. Como indican los nombres y las rigurosas tcnicas de ingeniera se han aplicado al desarrollo de los sistemas. A pesar de que la aplicacin de algunos procesos de ingeniera de desarrollo de software, como el estricto enfoque cascada SDLC, han sido objeto de crticas, una prctica muy influyente de prstamo con xito se llama ingenierade prototipos. Vamos a hablar de prototipos en primer lugar, seguida de una introduccin al diseo de la Aplicacin Conjunta (JAD) y herramientas CASE. Ambos prototipos y JAD incorporar componentes estndar de los sistemas tpicos anlisis y proceso de diseo, CAJA y relacionados con herramientas de software para apoyar el proceso de desarrollo tambin estn ampliamente disponibles. Prototipos, JAD, y herramientas CASE son todos los componentes necesarios de RAD (Rapid Application Development).2.5.1Creacin de prototiposDiseo y construccin de una escala reducida pero funcional versin de un sistema deseado es conocida como la fabricacin de prototipos. Un prototipo puede ser construido con cualquier lenguaje de ordenador o de una herramienta de desarrollo de prototipos, sino que adems se han desarrollado herramientas para simplificar el proceso. Un prototipo puede ser desarrollado con herramientas de desarrollo visual; con la consulta, la pantalla y herramientas de diseo de un sistema de gestin de bases; y con herramientas CASE.Utilizando prototipos como una tcnica de desarrollo (vase la figura 2.5 ); el analista trabaja con los usuarios para determinar la inicial o requisitos bsicos para el sistema. El analista crea rpidamente un prototipo. Cuando el prototipo se ha completado, el trabajo de los usuarios con ella y decirle al analista lo que gusta y lo que no gusta de l. El analista utiliza esta informacin para mejorar el prototipo y toma la nueva versin a los usuarios. Este proceso interactivo contina hasta que los usuarios estn relativamente satisfechos con lo que han visto.Dos ventajas fundamentales de la tcnica de prototipos son la gran cantidad de prototipos que implica al usuario en el anlisis y diseo y su capacidad para captar las necesidades de hormign, en lugar de verbal o abstracto, de .Adems de ser utilizado como un proceso independiente, desarrollo de prototipos tambin se puede utilizar para aumentar el Centro de descargas de Sun. Por ejemplo, un prototipo del sistema final puede ser desarrollado a principios de anlisis para ayudar a los analistas identificar lo que quieren los usuarios. A continuacin, el sistema final se ha desarrollado en base a las especificaciones del prototipo.

Fig. 2.5 :Metodologa El desarrollo de prototipos2.5.2Herramientas CASEOtros esfuerzos encaminados a mejorar el proceso de desarrollo de los sistemas han tomado ventaja de los beneficios ofrecidos por tecnologa informtica. El resultado ha sido la creacin y un uso considerable decomputer-aided software engineering, oCASO, herramientas. CASO se han desarrollado herramientas para uso interno y para la venta de varias empresas lderes, entre los que se incluyen Oracle (diseador), Computer Associates (Partido Gen), e IBM (Rational Rose).Herramientas CASE estn construidas alrededor de un repositorio central de descripciones de los sistemas y las especificaciones, incluyendo informacin sobre nombres de datos, el formato, los usos y ubicaciones. La idea de un repositorio central de informacin acerca de un proyecto no es nuevo (el manual forma de tal depsito se denominaproyecto diccionario olibro .La diferencia es que herramientas CASE automatizar el repositorio de actualizaciones de forma ms sencilla y la coherencia. CASO herramientas tambin incluyen herramientas para diagramas los diagramas de flujo de datos y otras ayudas grficas, pantalla y herramientas de diseo, y otras herramientas especiales. CASO ayuda a los programadores y analistas hacer su trabajo ms eficiente y ms eficaz mediante la automatizacin de las tareas rutinarias. En algunas organizaciones, ha sido muy exitoso, mientras que en otros no ha sido as.2.5.3Diseo de la aplicacin conjuntaA finales de la dcada de 1970, el desarrollo de sistemas personal de IBM desarroll un nuevo proceso de recoleccin de informacin y los requisitos del sistema revisar diseos de sistemas. Este proceso se denominaDiseo de la Aplicacin Conjunta (JAD). La idea bsica detrs de JAD es llevar a estructura de los requisitos de fase determinacin de anlisis y a las crticas que se presentan como parte del diseo. Los usuarios, administradores y desarrolladores de sistemas se reuni para realizar una serie de intensas reuniones, estructurado por un coordinador de la sesin JAD que mantiene la estructura y se adhiere a la agenda. Con la reunin de los pueblos directamente afectados por un sistema de informacin en una habitacin al mismo tiempo que trabajar juntos a fin de llegar a un acuerdo sobre los requisitos del sistema, por lo que los detalles de diseo, el tiempo y los recursos de la organizacin son mejor manejadas. Como ventaja adicional, los miembros del grupo son ms propensas a desarrollar un entendimiento comn de lo que el sistema de informacin se supone que debe hacer.2.5.4Desarrollo rpido de aplicacionesDesarrollo rpido de aplicaciones (RAD) es unenfoque de desarrollo de sistemas de informacin que promete mejores y ms baratos y ms rpidos sistemas implementacin mediante el uso de los desarrolladores de sistemas y los usuarios finales trabajan conjuntamente en tiempo real para desarrollar sistemas.RADcreci a partir dela convergencia de dos tendencias:1. El aumento de la velocidad y turbulencia de los negocios a finales del decenio de 1980 y principios de la dcada de 1990 y2. La disponibilidad de alta potencia y de herramientas informticas para desarrollo de sistemas de apoyo y de la facilidad de mantenimiento.Como las condiciones de los negocios en un cambiante y competitivo entorno mundial se torn ms turbulento, la gestin de las organizaciones comenzaron a cuestionar si, tiene sentido esperar de 2 a 3 aos con el fin de desarrollar sistemas (en un sistema metdico, controles de proceso) que se quedan obsoletos despus de finalizar el proceso.La disponibilidad de cada vez ms potentes herramientas de software creado para apoyar RAD tambin un creciente inters por este enfoque. RAD se est convirtiendo cada vez ms en una forma legtima de desarrollar sistemas de informacin. Estos das, la atencin se ha centrado sobre el rpido desarrollo de sistemas basados en Web. Herramientas RAD y el software creado para apoyar el rpido desarrollo, casi todos de la rpida creacin de aplicaciones basadas en Web. Por ejemplo, IBM ha desarrollado un conjunto de herramientas que permiten el rpido desarrollo de aplicaciones e-business. Estas herramientas incluyenVisualAgeGenerator, VisualAgefor Java,WebSphere Studio, yWebSphere Application Server.Tal como se muestra en la figura 2.6 se muestran, las mismas fases que se siguen en el tradicional SDLC se sigui tambin en RAD, pero las fases se acorta y se han combinado con unos a otros a producir una mayor racionalizacin tcnica de desarrollo. Investigacin preliminar y de una fase de diseoen RAD se acortan por centrar la labor en funcin del sistema y la interfaz de usuario requisitos a expensas de los anlisis y preocupacin para los problemas de rendimiento del sistema. Adems, RAD se ve generalmente en el sistema que se est elaborando en forma aislada de otros sistemas, con lo que se elimina la prdida de tiempo las actividades de coordinacin con las normas existentes y de los sistemas durante el diseo y el desarrollo.El nfasis en RAD es, por lo general, menos en la secuencia y la estructura de los procesos en el ciclo de vida y ms en realizar diferentes tareas en paralelo con los dems y sobre el uso de prototipos ampliamente. Tenga en cuenta tambin que la iteracin en el RAD ciclo de vida se limita a las fases de diseo y desarrollo. Este es el lugar donde la mayor parte de la labor de un enfoque RAD tiene lugar.

Fig. 2.6 :RAD ciclo de vidaPara tener xito, RAD se basa en reunir a varios sistemas componentes de desarrollo. RAD depende de una amplia participacin de los usuarios. Los usuarios finales estn implicados desde el principio en el proceso de desarrollo, cuando participan en planificacin de la aplicacin, a travs de requisitos determinacin, cuando trabajan con los analistas en sistema de prototipos; y, a continuacin, en el diseo y la ejecucin, cuando trabajan con los desarrolladores de sistemas para validar elementos finales de el diseo del sistema. Gran participacin de los usuarios se lleva a cabo en el proceso de prototipos, cuando los usuarios y analistas trabajan juntos para disear interfaces y los informes para los nuevos sistemas. El desarrollo del prototipo se lleva a cabo en las sesiones tradicionales que se asemejan a las sesiones JAD. La diferencia principal es que en RAD el prototipo se convierte en la base para el nuevo sistema de pantallas de prototipos diseados en convertirse en las pantallas del sistema de produccin. Esto se logra mediante la utilizacin de herramientas CASE integradas, que incluyen generadores de cdigo para crear el cdigo de los diseos los usuarios finales y los analistas cree durante de prototipos. El cdigo incluye las interfaces, as como los programas de aplicacin que lo utilizan. Como alternativa, puede emplear RAD entornos de desarrollo visual en lugar de herramientas CASE con generadores de cdigo, pero los beneficios de prototipado rpido son los mismos. En muchos casos, la base para el sistema de produccin se est construyendo, ya que los usuarios estn hablando del sistema durante los talleres de desarrollo. En muchos casos, los usuarios finales pueden obtener experiencia prctica con el sistema antes de que el desarrollo en talleres de diseo. Para ayudar a acelerar el proceso, la reutilizacin de plantillas, componentes o sistemas anteriores se describe en el caso de repositorio es altamente recomendable.2.5.5Metodologas gilesRAD es slo una reaccin a los problemas con la metodologa tradicional en cascada para el desarrollo de sistemas. Como se puede imaginar, muchos otros mtodos de diseo y anlisis de sistemas se han desarrollado a lo largo de los aos. En el mes de febrero de 2001, muchos de los defensores de estos enfoques alternativos se reunieron en Utah y llegaron a un acuerdo por consenso sobre varios de los principios que sustentan los distintos enfoques. Este consenso se convirti en un documento llamado "ElAgile Manifesto"(Cuadro 2.3 ). Segn Fowler, metodologas giles compartir tres principios fundamentales:1. Un foco en la adaptacin en lugar de mtodos predictivos,2. Centrarse en las personas en lugar de funciones, y3. Se centrarn en la adaptacin de los procesos.Tabla2.3 : ElAgile Manifesto

El Manifesto for Agile Software Development

Diecisiete anarquistas coinciden:Estamos descubriendo mejores maneras de desarrollar software, hacindolo y ayudando a otros.A travs de este trabajo hemosllegado a valorar: Los individuos y las interacciones sobre los procesos y herramientas. Software de documentacin completa. Colaboracin con el cliente sobre negociacin contractual. Responder a los cambios en el plan.A pesar de que los elementos de la derecha, valoramos los elementos de ms a la izquierda.Seguimos los siguientes principios: Nuestra prioridad es satisfacer al cliente mediante la entrega continua y software valioso. Bienvenido requisitos cambiantes, incluso a fines de desarrollo. Los procesos giles cambio del cableado para el cliente de la ventaja competitiva. Trabajo ofrecen software frecuentemente, desde un par de semanas hasta un par de meses, con preferencia a los plazos ms cortos. Gente de Negocios y desarrolladores trabajan juntos diariamente a lo largo de todo el proyecto. Crear proyectos en torno a individuos motivados. Les dan el medio ambiente y el apoyo que necesitan, y confiar en ellos para hacer el trabajo. El ms eficiente y eficaz mtodo para transmitir informacin a y dentro de un equipo de desarrollo est conversacin cara a cara. Software es la principal medida de progreso. Los procesos giles promueven el desarrollo sostenible. Los patrocinadores, desarrolladores y usuarios deberan ser capaces de mantener un ritmo constante indefinidamente. Atencin Continua en excelencia tcnica y buen diseo mejora la agilidad. Simplicidad - el arte de maximizar la cantidad de trabajo no realizado, es esencial. Las mejores arquitecturas, requisitos y diseos surgen de la auto-organizacin de equipos. A intervalos regulares, el equipo reflexiona sobre cmo ser ms eficaz, canciones y ajusta su conducta en consecuencia. -Kent Beck, MikeBeedle, ArievanBennekum, Alistair Cockburn, Ward Cunningham, Martin Fowler, James Grenning, Jim Highsmith, Andrew Hunt, Ron Jeffries, Jon Kern, cerebro Marick Ngueradjim, Robert C. Martin, Steve Mellor, Ken Schwaber, Jeff Sutherland y Dave Thomas.

Las metodologas giles grupo argumenta que adaptar metodologas de desarrollo de software de ingeniera, por lo general, no encajan con la elaboracin de programas informticos. En las disciplinas de la ingeniera, tales como ingeniera civil, requisitos tienden a ser bien comprendidos. Una vez que elcreativo y difcil trabajo de diseo es completado, la construccin se vuelve muy predecible. Adems, la construccin de tanto como 90 por ciento del total del proyecto. En cuanto al software, por otro lado, las exigencias son rara vez bien entendido, y cambia continuamente durante la vida til del proyecto. Construccin de tan slo 15 por ciento de la total del proyecto, con un diseo que constituyen tanto como 50 por ciento. Aplicacin de tcnicas que funcionan bien para predecible y estable los proyectos, tales como construccin de puentes, tienden a no funcionar bien en el caso de fluidos, diseo de proyectos, tales como software de grabacin, dicen que la metodologa gil proponentes. Lo que se necesita son metodologas que abrazar el cambio y que son capaces de hacer frente a la falta de previsibilidad. Uno de los mecanismos para hacer frente a la falta deprevisibilidad, metodologas giles que todos compartimos, es desarrollo iterativo. Desarrollo iterativo se centra en la produccin frecuente de versiones de un sistema que tiene un subconjunto del nmero total de caractersticas requeridas. Desarrollo iterativo proporciona informacin a los clientes y desarrolladores.Las metodologas giles" se centran en las personas, es una de las personas ms que en los papeles de las personas. Las funciones que la gente llene, analista de sistemas o probador o manager, no son tan importantes como las personas que llenar esos papeles. Fowler sostiene que la aplicacin de principios de ingeniera para el desarrollo de sistemas ha dado lugar a una vista de las personas como unidades intercambiables en lugar de una vista de las personas como individuos talentosos, cada uno de ellos aporta algo nico para el equipo de desarrollo.Las metodologas giles promover una auto-adaptativa proceso de desarrollo de software. Como se ha desarrollado un software, el proceso que se usa para desarrollar debe ser mejorado y perfeccionado. Los equipos de desarrollo pueden hacerlo a travs de un proceso de revisin, a menudo asociado con la realizacin de iteraciones. La consecuencia es que, como de los procesos se adaptan, uno no esperara encontrar un nico y monoltico metodologa dentro de una determinada sociedad o empresa. En cambio, uno puede encontrar muchas variaciones de la metodologa, cada uno de los cuales refleja el talento y la experiencia del equipo.Metodologas giles no son para cada proyecto. Fowler recomienda un proceso de adaptacin gil o si su proyecto incluye: Imprevisibles o los requisitos dinmicos Los desarrolladores responsables y motivados Los clientes que puedan comprender el proceso y participenUNA ms ingenieril, previsible proceso de si el equipo de desarrollo es superior a 100 personas, o si el proyecto est funcionando bajo un precio fijo o de alcance contrato. As pues, las organizaciones necesitan diversos enfoques para desarrollar los sistemas de informacin, en funcin de las caractersticas del sistema y el equipo de desarrollo.Muchos diferentes metodologas en el marco de metodologas giles. Fowler enumera los Crystal familia metodologas, Desarrollo de Software adaptable, Scrum, Desarrollo controlado por funciones, y otro como metodologas giles. Quizs el ms conocido de estos mtodos, sin embargo, esProgramacin extrema.2.5.6Programacin extremaProgramacin extremaes un mtodo de desarrollo de software por Beck.Se distingue por su ciclo corto, enfoque de planificacin incremental, centrarse en pruebas automatizadas escrito por programadores y clientes a supervisar el proceso de desarrollo, y una dependencia de un enfoque evolutivo de desarrollo que dura toda la vida til del sistema. Elementos clave deProgramacin extremason el uso de dos personas y equipos de programacin y tener un cliente en el sitio durante el proceso de desarrollo. Las partes pertinentes deProgramacin extremaque se refieren a las especificaciones de diseo estn1. La planificacin, anlisis, diseo y construccin son todos fusionados en una sola fase de actividad y2. Su peculiar manera de capturar y presentar requisitos del sistema y las especificaciones de diseo.Conprogramacin extrema, todas las fases del ciclo de vida convergen en una serie de actividades sobre la base de los procesos bsicos de la codificacin, pruebas, escuchar y diseo.Bajo este enfoque, codificacin y pruebas estn ntimamente relacionados con las piezas de un mismo proceso. Los programadores que escriben el cdigo tambin desarrollar las pruebas. El nfasis est en las pruebas esas cosas que se puedan romper o ir mal, no por prueba todo. Cdigo se ha probado muy pronto despus de que se ha escrito. La filosofa general deprogramacin extremaes que el cdigo se integrar en el sistema en el que est siendo desarrollada y probada en unas pocas horas despus de que se ha escrito. Si todas las pruebas se ejecutan correctamente, a continuacin, avanza el desarrollo. Si no, el cdigo se ha rectificado hasta que las pruebas son satisfactorias.Otra parte deProgramacin extremaque hace que el cdigo de trabajo de los procesos de prueba ms fcilmente es la prctica de programacin de a pares. Codificacin y todas las pruebas se llevan a cabo en dos personas que trabajan juntas que escribir cdigo y desarrollar pruebas. Beck afirma que la programaci en pares no es una persona que escribe y la otra vela. Ms bien, los dos los programadores trabajan juntos en el problema que estn tratando de resolver, en el intercambio de informacin y conocimientos y compartir conocimientos. En comparacin con las tradicionales prcticas de codificacin, las ventajas de programacin de a pares incluyen:1. Ms (y mejores) comunicacin entre desarrolladores,2. Los niveles ms altos de productividad,3. Cdigo de mayor calidad, y4. Refuerzo de las otras prcticas enProgramacin extrema, como el cdigo y de disciplina.A pesar de que elproceso de programacin extrema tiene sus ventajas, al igual que con cualquier otro enfoque para el desarrollo de sistemas, no es para todos y no es aplicable a todos los proyectos2.6 ANLISIS Y DISEO DE APLICACIONES ORIENTADO A OBJETOSNo hay duda de queanlisis y el diseo orientado a objetos (OO) es cada vez msy ms popular. OO es a menudo llamado el tercer enfoque para el desarrollo de sistemas, despus de que el proceso de orientacin y orientadas a datos. El enfoque orientado a objetos combina datos y procesos (llamados mtodos) en una sola entidad denominadaobjetos .Por lo general corresponden a objetos las cosas reales un sistema de informacin se ocupa, como clientes, proveedores, contratos y acuerdos de arrendamiento. Poner los datos y procesos en un mismo lugar reconoce el hecho de que hay un nmero limitado de operaciones de cualquier estructura de datos, y tiene sentido, aunque tpico desarrollo sistemas mantiene los datos y procesos independientes el uno del otro.El objetivo de OO es para hacer que los sistemas ms elementos reutilizables, mejorando as la calidad del sistema y la productividad de diseo y anlisis de sistemas.Otra idea clave detrs de orientacin a objetos es la herencia. Los objetos se organizan enclases de objetos, los cuales son grupos decompartir objetos estructurales y las caractersticas de su comportamiento. Herencia permite la creacin de nuevas clases que comparten algunas de las caractersticas de las clases existentes. Por ejemplo, desde una clase de objetos llamados "persona", se puede utilizar la herencia para definir otra clase de objetos denominados "cliente", objetos de la clase "cliente" que comparte ciertas caractersticas con objetos de la clase "persona": ambos tienen nombres, direcciones, nmeros de telfono, y as sucesivamente. Porque "persona" es la clase ms general y "cliente" es ms especfico, cada cliente es una persona pero no todas las personas es un cliente.Recuerde que un lenguaje de programacin informtica es necesario para que pueda crear y manipular objetos y clases de objetos con el fin de crear de la programacin orientada a objetos sistemas de informacin. Varios lenguajes de programacin orientados a objetos se han creado (p. ej.,., C++, Java, Eiffel yObjectPAL). De hecho, los lenguajes orientados a objetos se desarrollaron y orientado a objetos anlisis y tcnicas de diseo. OO porque todava es relativamente nuevo, existe poco consenso o uniformidad entre los muchos OO tcnicas disponibles.En general, la tarea de anlisis orientado a objetos. es identificar objetos y definir su estructura y el comportamiento y sus relaciones. Las tareas principales de diseo orientado a objetos modelo los detalles de los objetos y los comportamientos y la comunicacin con otros objetos de manera que se cumplen los requisitos del sistema, y replantear y redefinir objetos para aprovechar mejor de herencia y otros beneficios de orientacin a objetos.El enfoque orientado a objetos para el desarrollo de sistemas comparte el enfoque de desarrollo iterativo de las metodologas giles. Algunos dicen que la actual, que se centra en la agilidad en el desarrollo de sistemas no es ms que la aceptacin de la programacin orientada a objetos los mtodos que han sido germinando durante aos, por lo que esta similitud no es ninguna sorpresa. Una de las realizaciones ms populares de el mtodo iterativo para el desarrollo orientado a objetos es elRational Unified Process (RUP), que se basa en unenfoque iterativo e incremental para el desarrollo de sistemas. RUP tiene cuatro fases:inicio, elaboracin, construccinytransicin (vase la figura 2.7 ).

Fig. 2.7 : Ilustracin de las fases de desarrollo de base OOSADEn la fase inicial, los analistas definir el alcance, determinar la factibilidad del proyecto, entender las necesidades de los usuarios, y preparar un plan de desarrollo software.En la fase de elaboracin, los analistas detalle las necesidades de los usuarios y el desarrollo de una arquitectura de lnea. Anlisis y diseo de las actividades constituyen el grueso de la fase de elaboracin.En la fase de construccin, el software se est codificado, probados y documentados. En la fase de transicin, el sistema est implementado y los usuarios sean entrenados y apoyados. Como es evidente en la Figura 2.7 , la fase de construccin es generalmente la ms larga y ms intensivo de los recursos. La fase de elaboracin tambin es larga, pero menos intensivo en el uso de recursos.La fase de transicin es intensa pero breve de recursos. La fase inicial es breve y menos intensivo en el uso de recursos.Las reas de los rectngulos de la Figura 2.7 muestran una estimacin de los recursos generales asignados a cada una de las fases.Cada fase puede ser dividido en iteraciones. El software se desarrolla gradualmente en una serie de iteraciones. La fase inicialse implican en general una sola iteracin. El alcance y la viabilidad del proyecto se determina en la presente etapa. La fase de elaboracinpuede tener uno o dos iteraciones y en general est considerada como la parte ms crtica de las cuatro fases. La fase de elaboracin es principalmente de diseo y anlisis de sistemas, aunque otras actividades tambin estn involucrados. Al final de la fase de elaboracin, la arquitectura del proyecto debera haber desarrollado. La arquitectura incluye una visin del producto, un archivo ejecutable demostracin de las piezas crticas, un glosario detallado y un manual de usuario preliminar, un plan detallado de la construccin, y una estimacin revisada de los gastos previstos.A pesar de que lafase de construccinimplica principalmente codificacin, que se realiza en varias iteraciones, revis las necesidades de los usuarios podran requerir anlisis y diseo. Los componentes se han desarrollado o adquirido y utilizado en el cdigo. Como cada ejecutable se haya completado, es probado e integrado. Al final de la fase de construccin, una versin beta del proyecto es que debe tener las capacidades operacionales. La fase de transicinimplica corregir los problemas, las pruebas de la fase beta, la capacitacin de los usuarios, y a la conversin del producto. La fase de transicin se completa cuando los objetivos del proyecto cumplen con los criterios de aceptacin. Criterios de aceptacin una vez se han cumplido, a continuacin, el producto puede ser entregado para su distribucin a las organizaciones o personas que lo necesitan.RESUMEN Un sistemase define como un conjunto de componentes relacionados que interactan para realizar una tarea con el fin de alcanzar un objetivo. Los participantes en los proyectos son de tres tipos: los usuarios,personal tcnico y de gestin. Un analista de sistemasespecialista de informacin que realiza anlisis de sistemas, diseo y aplicacin. Anlisis y diseo de sistemases un seis a la fase procedimiento de solucin de problemas para examinar un sistema de informacin y el mejoramiento de sta. Elciclo vital de desarrollo de sistemas (SDLC) es elproceso paso a paso que muchas organizaciones siguen en diseo y anlisis de sistemas. El Centro de descargas es una completa herramienta para resolver problemas de organizacin, en particular las relativas a la circulacin de informacin basados en computadoras. Datos proporcionados por el usuario y el examen es una parte esencial de cada fase(es decir,seis fases de diseo y anlisis de sistemas.) El objetivo de la investigacin preliminarde realizar un anlisis preliminar, proponer soluciones alternativas, describir los costos y los beneficios, y presentar un plan preliminar de las recomendaciones. La investigacin preliminar se sientan las bases para las dems fases de Sun. El propsito de anlisis de sistemases el de recopilar datos, analizar los datos y redactar un informe. El resultado de anlisis de los sistemas informticos para determinar si el sistema debe ser rediseado. Diagrama de Flujo de Datos (DFD) esuna herramienta de modelado quemuestra grficamente el flujo de datos a travs de un sistema. El objetivo deldiseo de los sistemases el de hacer un diseo preliminar y, a continuacin, un detalle del diseo, y escribir un informe. Diseo de los sistemas es una de las fases ms importantes de Sun. Prototiposimplica la construccin de un modelo o versin experimental de todos o una parte de un sistema que se puede hacer rpidamente probadas y evaluadas. En el desarrollo de sistemas, el hardware y el softwarepara el nuevo sistema se adquieren y probado. Los sistemas fase de desarrollo puede asociar a la organizacin a invertir mucho tiempo y dinero. Aplicacin de los sistemasconsiste en convertir el hardware, el software y los archivos al nuevo sistema y formacin de los usuarios. Implementacin del sistema es importante porque implica poner ideas de diseo en funcionamiento. Conversines el proceso de transicin de un viejo sistema de informacin para una nueva. Aplicacin directasignifica que el usuario simplemente se detiene con el antiguo sistema y comienza a usar el nuevo. Medios de ejecucin paralelaque los viejos y nuevos sistemas son operados al ladohasta que el nuevo sistema ha demostrado que es fiable y en ese momento el antiguo sistema se suspendi. Fases de implementacinsignifica que algunas partes de las nuevas fases de sistema por separado, ya sea en distintos momentos (paralelo) o todos a la vez en grupos (directo). Aplicacin Experimentalsignifica que todo el sistema est probado pero slo para algunos usuarios. Mantenimiento del sistemaconsiste en mantener el sistema de auditoras del sistema y las evaluaciones peridicas. Mantenimiento del sistema es importante para mantener un nuevo sistema funcional y til. Documentacin es unaparte integral de las distintas fases del ciclo de vida y se produce como parte de la fase. Documentacin debera ser creados como parte del proceso y no se escriben despus del hecho. Toda la documentacin debe seguir ciertas normas que se prescriben para el proyecto o la organizacin. Los editores tcnicos, a veces, se utilizan para garantizar que los documentos estn bien escritos. La espiralmodelo deciclo de vida tambin incorpora los elementos de riesgo. Prototipo esun proceso iterativo de desarrollo de sistemas para los que se convierten en un sistema de trabajo que es revisado continuamente a travs de una estrecha colaboracin entre el analista y los usuarios. Computer-aided software Engineering (CASE) herramientas sonherramientas de software que proporcionan soporte automatizado para una parte del proceso de desarrollo de sistemas. Herramientas CASE se utiliza para automatizar el Centro de descargas de Sun. Diseo de la Aplicacin Conjunta (JAD) esun proceso estructurado en el que los usuarios, administradores y analista trabajan juntos durante varios das en una serie de reuniones intensivas para especificar o revise los requisitos del sistema. Desarrollo de Accin Rpida (RAD) esmetodologa para el desarrollo de sistemas creados para reducir radicalmente el tiempo necesario para disear e implementar sistemas de informacin. RAD se vale de una amplia participacin de los usuarios, las sesiones JAD, desarrollo de prototipos, integrado herramientas y generadores de cdigo. Anlisis y diseo de aplicaciones orientado a objetoses una metodologa de desarrollo de sistemas y tcnica basada en objetos, en vez de datos o procesos. Un objetoes una estructura que encierra (o paquetes) de atributos y mtodos que funcionan en esos atributos. Un objeto es una abstraccin de un mundo real de lo que los datos y los procesos se colocan para modelar la estructura y el comportamiento del objeto del mundo real. Herenciaes la propiedad que se produce cuando tipos de entidad o clases de objetos se organizan en una jerarqua y cada tipo de entidad o una clase de objeto asume los atributos y mtodos de sus antepasados, es decir, la de aquellos ms arriba en la jerarqua. Herencia permite a los nuevos, pero que se relaciona con las clases que se derivan de las clases existentes. Clase de objetoes una agrupacin lgica de los objetos que tienen la misma (o similar) atributos y comportamientos (mtodos). Rational Unified Process (RUP) es un objetode metodologa de desarrollo de sistemas. RUP establece cuatro fases de desarrollo: iniciacin, elaboracin, construccin y transicin. Cada fase est organizada en una serie de iteraciones independientes.PREGUNTAS DE REPASO Y EJERCICIOS1.Describir los distintos tipos de participantes en cualquier tipo de proyecto.

2.Cules son las seis fases del ciclo vital de desarrollo de sistemas (SDLC)?

3.Qu es la documentacin? Explicar.

4.Cules son las diversas crticas a tradicional en cascada DE TRANSMISIN DE DATOS, SLDC?Explicar.

5.Qu es desarrollo de prototipos? Cules son sus ventajas? Cmo puede un prototipo?

6.Qu es JAD? Cmo es ayudar a los miembros del grupo?

7.Escribir notas breves sobre los siguientes puntos:i. Herramientas CASEii. RADiii. Metodologas gilesiv. Programacin extrema.

8.Cules son los diferentes enfoques que se han desarrollado durante el curso del tiempo para mejorar sistemas tradicionales anlisis y proceso de diseo?

9.Cmo difiere de OO orientada al proceso, y enfoques orientados a datos?Explicar.

10.Lista diferentes fases en el Centro de descargas de Sun.

11.Es necesario seguir anlisis de sistemas y metodologas de diseo para crear un sistema de informacin? Por qu no se puede construir el sistema en cualquier forma aleatoria?Qu pasara?

12.Cules son las variaciones en EL SDLC modelo?Explicar.

13.Explicar cmo funciona anlisis y diseo de aplicaciones orientado a objetos distintos de los tradicionales. Por qu es RUP no estn representados en forma de ciclo? Es bueno o malo?Explicar.

14.EstadoVerdadero o Falso:i. Un estudio de factibilidad se lleva a cabo para ver si el sistema es viable o no.ii. Fase de anlisis no es relevante en el estudio detallado del sistema existente.iii. El SDLC no es una secuencia estructurada de las fases para implementar un sistema de informacin.iv. La fase de mantenimiento es normalmente el ms largo proceso en el ciclo de vida.v. Prototipo es un proceso iterativo de desarrollo de sistemas para los quese convierten en un sistema de trabajo que es revisado continuamente a travs de una estrecha colaboracin entre el analista y los usuarios.vi. Herramientas CASE no se pueden utilizar para automatizar el Centro de descargas de Sun.vii. JAD es un proceso estructurado en el que los usuarios, administradores y analistas trabajan juntos durante varios das en una serie de intensas reuniones para especificar o revise los requisitos del sistema.viii. Rational Unified Process (RUP) es un objeto de metodologa de desarrollo de sistemas.

15.Llene los espacios en blanco:i. UN es un especialista de la informacin que realiza anlisis de sistemas, diseo e implementacin.ii. El propsito de es hacer un diseo preliminar y, a continuacin, un detalle del diseo, y escribir un informe.iii. consiste en mantener el sistema de auditoras del sistema y las evaluaciones peridicas.iv. es una parte integral de las distintas fases del ciclo de vida y se produce como parte de la fase.v. El modelo del ciclo de vida incorpora los elementos de riesgo.vi. Los intentos de hacer desarrollo de sistemas menos de un arte, y ms de una ciencia se suele hacer referencia a como .vii. las metodologas no estn para cada proyecto.viii. Metodologa para el desarrollo de sistemas y tcnica basada en objetos, en vez de datos o procesos se llama .