Captulo 2 - El ciclo vital de desarrollo de sistemas

Estructurado Anlisis y Diseo de Sistemas

Y J.B. Dixit Raj Kumar
Laxmi Publications 2007 Citation
Captulo 2: El ciclo vital de desarrollo
de sistemas
2.1 INTRODUCCIN
Un sistema se 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 ejemplos son:
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 debe estar siempre preparado 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 sistemas especialista 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.2 LAS SEIS FASES DE DISEO Y ANLISIS DE
SISTEMAS
Diseo y anlisis de sistemas es 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. El ciclo vital de
desarrollo de sistemas (SDLC) es el proceso 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 : El ciclo vital de desarrollo de sistemas (SDLC)
2.2.1 Investigacin Preliminar
El 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.1 Investigacin Preliminar
El 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 pasos se
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. Seguridad puede 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.2 Anlisis de sistema
El 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 de entender 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 dan a continuacin:
i. Recopilar datos mediante el uso de herramientas de documentos escritos, entrevistas, cuestionarios y
observaciones.
ii. Anlisis de los datos, utilizando herramientas 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 que un analista de sistemas para grfico actual, o de la ilustracin, las
representaciones de un sistema.Un ejemplo de una herramienta de modelado es un diagrama de flujo de
datos (DFD), el cual muestra 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. (Ver Figura 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.3 Diseo del sistema
El objetivo de la Fase 3, diseo de sistemas es hacer un diseo preliminar y, a continuacin, un detalle del diseo, y
escribir un informe. Los pasos se dan a 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 preliminar describe 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 son herramientas y software de gestin de
proyectos.
CASO (Computer Aided Software Engineering) herramientas son 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
como herramientas de diseo automatizado, puede utilizarse en otras etapas del SDLC. Algunos ejemplos de este
tipo de programas son Excelerator, 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 un limitado 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
como posible visualizar en pantalla, que los usuarios puedan probar. El men puede ser rediseado o afinar, si es
necesario.
Software de gestin de proyectos consta 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: un diseo de detalle se 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 salida
Requisitos de entrada
Requisitos de almacenamiento
Requisitos de procesamiento, y
Control 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.4 Desarrollo del Sistema
En 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 dan a continuacin:
i. Adquirir el software.
ii. Adquirir hardware .
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 la creacin 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.5 Aplicacin de los sistemas
Si 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 dan a 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 los usuarios .
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, y piloto .
Aplicacin directa significa 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 paralela que 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 implementacin significa 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 Experimental significa 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.6 Mantenimiento de los sistemas
Fase 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.3 DOCUMENTACIN DEL SISTEMA
CONSIDERACIONES
2.3.1 Principios de Documentacin del sistema
Con frecuencia se pasa por alto una parte e infravalorado de un sistema es su documentacin. Documentacin es
una parte 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 versiones de control de la informacin
Los nombres de autor, 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 y acrnimos
Otros documentos para consultar (referencias especficas)
Resumen/introduccin
Resumen y conclusiones como resumen ejecutivo, si procede
Cuerpo principal de 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 coherente
Las 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.2 Tipos de documentacin y su importancia
Documentacin 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

Documento Importancia
Solicitud de proyecto/Informacin
Solicitud de servicio/Sistema de
Informacin Solicitud
Inicia el proyecto y establece el primer "alcance" del sistema requerido.
Proyecto Directiva Crea 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 Viabilidad Preparado 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 Anlisis
Creado 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 tecnologa
Creado 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 rendimiento Creado 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 diseo Documentos 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 sistema A 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
pruebas
Especifica 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 usuario Creado 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 Operaciones Creado 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 para cuidar de las dos operaciones normales y las
condiciones de error.
Registros de los Proyectos Los 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: Principales documentos del Plan y sus usos
Open table as spreadsheet
Plan Descripcin
Plan de
proyecto/ Plan de
Calidad
Utilizado 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 y actualizado por el director del proyecto en funcin de la evolucin de las
Tabla 2.2: Principales documentos del Plan y sus usos
Open table as spreadsheet
Plan Descripcin
situaciones. Tambin utilizadas por la direccin para revisar el proyecto.
Plan de
Administracin de la
configuracin
Usa 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 pruebas
Establece 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
mantenimiento
El 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.3 Aplicar Disciplina Documentacin en una organizacin
Como 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.4 MODELOS DE CICLO VITAL
Diferentes organizaciones y autores no se han puesto de acuerdo sobre un nico Sun. Consideremos diferentes modelos
para ella.
El SDLC tradicional en cascada
Hay 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 denominada cascada (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 del modelo 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 : UNA Cascada tradicional SDLC
Tradicionalmente, una etapa termin y comenz otra vez se trata de un hito. El hito por lo general tom la forma de una
entrega o especificadas en 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 anlisis y 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 SDLC
Algunas 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 espiral
El 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 actividades son:
Planificacin
Anlisis de Riesgos
Ingeniera
Evaluacin de las necesidades del cliente
Sin 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 desarrollo como 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.5 DIFERENTES ENFOQUES DE MEJORA DE LAS
CONDICIONES DE DESARROLLO
En 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 como ingeniera de sistemas o ingeniera 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 ingeniera de 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.1 Creacin de prototipos
Diseo 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 prototipos
2.5.2 Herramientas CASE
Otros 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 de computer-aided software
engineering, o CASO, 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
denomina proyecto diccionario o libro .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.3 Diseo de la aplicacin conjunta
A 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 denomina Diseo 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.4 Desarrollo rpido de aplicaciones
Desarrollo rpido de aplicaciones (RAD) es un enfoque 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. RAD creci a partir de la 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 y
2. 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 incluyen VisualAge Generator, VisualAge for Java, WebSphere Studio , y WebSphere 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 diseo en 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 vida
Para 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.5 Metodologas giles
RAD 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 "El Agile 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, y
3. Se centrarn en la adaptacin de los procesos.
Tabla 2.3 : El Agile 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
hemos llegado 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.
o -Kent Beck, Mike Beedle, Arie van Bennekum, 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 el creativo 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 de previsibilidad, 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 participen
UNA 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, es Programacin extrema.
2.5.6 Programacin extrema
Programacin extrema es 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 de Programacin extrema son el uso de dos personas y equipos de programacin y tener un cliente en el sitio durante
el proceso de desarrollo. Las partes pertinentes de Programacin extrema que se refieren a las especificaciones de diseo
estn
1. La planificacin, anlisis, diseo y construccin son todos fusionados en una sola fase de actividad y
2. Su peculiar manera de capturar y presentar requisitos del sistema y las especificaciones de diseo.
Con programacin 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 de programacin extrema es 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 de Programacin extrema que 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, y
4. Refuerzo de las otras prcticas en Programacin extrema , como el cdigo y de disciplina.
A pesar de que el proceso 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 proyectos
2.6 ANLISIS Y DISEO DE APLICACIONES
ORIENTADO A OBJETOS
No hay duda de que anlisis y el diseo orientado a objetos (OO) es cada vez ms y 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 denominada objetos .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 en clases de objetos, los
cuales son grupos de compartir 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 y ObjectPAL). 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 el Rational Unified Process (RUP), que se basa en un enfoque iterativo e incremental para el desarrollo de
sistemas. RUP tiene cuatro fases: inicio, elaboracin, construccin y transicin ( vase la figura 2.7 ).

Fig. 2.7 : Ilustracin de las fases de desarrollo de base OOSAD
En 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
inicial se implican en general una sola iteracin. El alcance y la viabilidad del proyecto se determina en la presente etapa. La
fase de elaboracin puede 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 la fase de construccin implica 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 transicin implica 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 sistema se 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 sistemas especialista de informacin que realiza anlisis de sistemas, diseo y aplicacin.
Anlisis y diseo de sistemas es un seis a la fase procedimiento de solucin de problemas para examinar un
sistema de informacin y el mejoramiento de sta.
El ciclo vital de desarrollo de sistemas (SDLC) es el proceso 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 preliminar de 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 sistemas es 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) es una herramienta de modelado que muestra grficamente el flujo de
datos a travs de un sistema.
El objetivo del diseo de los sistemas es 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.
Prototipos implica 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 software para 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 sistemas consiste 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.
Conversin es el proceso de transicin de un viejo sistema de informacin para una nueva.
Aplicacin directa significa que el usuario simplemente se detiene con el antiguo sistema y comienza a usar el
nuevo.
Medios de ejecucin paralela que 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.
Fases de implementacin significa 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 Experimental significa que todo el sistema est probado pero slo para algunos usuarios.
Mantenimiento del sistema consiste 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 una parte 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 espiral modelo de ciclo de vida tambin incorpora los elementos de riesgo.
Prototipo es un 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 son herramientas 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) es un 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) es metodologa 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 objetos es una metodologa de desarrollo de sistemas y tcnica
basada en objetos, en vez de datos o procesos.
Un objeto es 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.
Herencia es 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 objeto es una agrupacin lgica de los objetos que tienen la misma (o similar) atributos y
comportamientos (mtodos).
Rational Unified Process (RUP) es un objeto de 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 EJERCICIOS
1.
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 CASE
ii. RAD
iii. Metodologas giles
iv. 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.
Estado Verdadero 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 que se 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 .