Anlisis y Diseo de Sistemas

Autor:Juan Manuel Velsquez CanacheC.I: 23.770.791Introduccin

Unsistemaes unobjeto complejo cuyos componentes se relacionan con al menos algn otro componente; puede sermaterialoconceptual.1Todos los sistemas tienen composicin, estructura y entorno, pero slo los sistemas materiales tienen mecanismo, y slo algunos sistemas materiales tienenfigura (forma).

Existe una gran variedad de sistema y una amplia gama de tipologas para clasificarlos, de acuerdo con ciertas caractersticas bsicas., En cuanto a su constitucin, los sistemas pueden ser fsicos o abstractos. El trmino lenguaje ha generado bastante confusin respecto a lo que es UML. En realidad el trmino lenguaje quizs no es el ms apropiado, ya que no es un lenguaje propiamente dicho, sino una serie de normas y estndares grficos respecto a cmo se deben representar los esquemas relativos al software. Mucha gente piensa por confusin que UML es un lenguaje de programacin y esta idea es errnea: UML no es un lenguaje de programacin. Como decimos, UML son una serie de normas y estndares que dicen cmo se debe representar algo.

1. Definicin

Mtodo:

Es un modo, manerao formade realizar algo de forma sistemtica, organizaday/o estructurada.Hace referencia a una tcnicao conjunto de tareas para desarrollar la misma.

En algn caso se entiende tambin como la forma habitualde realizar algo por una persona basada en la experiencia, costumbre y preferencias personales.

Metodologa:

Comometodologase denomina laserie de mtodos y tcnicas de rigor cientfico que se aplican sistemticamente durante un proceso de investigacinpara alcanzar un resultado tericamente vlido. En este sentido, la metodologa funciona como el soporte conceptual que rige la manera en que aplicamos los procedimientos en una investigacin.

La palabra, como tal, proviene del griego(mthodos), que significa mtodo, y el sufijo-loga, que deriva de(lgos) y traduce ciencia, estudio, tratado. De all que tambin sea definida como la ciencia del mtodo.

Podemos encontrarmetodologaen distintas reas de estudio, como lametodologa didcticaen Educacin, o lajurdicaen Derecho, del mismo modo como para lasolucin de problemasdeterminados podemos aplicar una serie de pasos especficos que, en suma, funcionan como una metodologa.

Metodologa de la investigacin:

Lametodologa de la investigacines una disciplina de conocimiento encargada de elaborar, definir y sistematizar el conjunto de tcnicas, mtodos y procedimientos que se deben seguir durante el desarrollo de un proceso de investigacin para la produccin de conocimiento. Orienta la manera en que vamos a enfocar una investigacin y la forma en que vamos a recolectar, analizar y clasificar los datos, con el objetivo de que nuestros resultados tengan validez y pertinencia, y cumplan con los estndares de exigencia cientfica. Lametodologa de la investigacin, en este sentido, es tambin la parte de unproyecto de investigacindonde se exponen y describen razonadamente los criterios adoptados en la eleccin de lametodologa, sea estacuantitativaocualitativa.

2. Metodologas para el Anlisis y Diseo de Sistemas.

2.1 Lenguaje Unificado de Modelado (UML)

Se trata de un estndar que se ha adoptado a nivel internacional por numerosos organismos y empresas para crear esquemas, diagramas y documentacin relativa a los desarrollos de software (programas informticos). El trmino lenguaje ha generado bastante confusin respecto a lo que es UML. En realidad el trmino lenguaje quizs no es el ms apropiado, ya que no es un lenguaje propiamente dicho, sino una serie de normas y estndares grficos respecto a cmo se deben representar los esquemas relativos al software. Mucha gente piensa por confusin que UML es un lenguaje de programacin y esta idea es errnea: UML no es un lenguaje de programacin. Como decimos, UML son una serie de normas y estndares que dicen cmo se debe representar algo. UML es una herramienta propia de personas que tienen conocimientos relativamente avanzados de programacin y es frecuentemente usada por analistas funcionales (aquellos que definen qu debe hacer un programa sin entrar a escribir el cdigo) y analistas-programadores (aquellos que dado un problema, lo estudian y escriben el cdigo informtico para resolverlo en un lenguaje como Java, C#, Python o cualquier otro). Por tanto si ests dando tus primeros pasos en programacin, te recomendaramos que te olvides de UML hasta que tengas unos conocimientos mnimos como uso de condicionales, bucles, y conocimiento de la programacin orientada a objetos. Esto es solo una recomendacin, en realidad prcticamente cualquier persona puede usar UML, incluso podra usarse para realizar esquemas o documentacin de procesos que no tengan que ver con la informtica. Hemos dicho que UML es un estndar. Vamos a aclarar primero qu es un estndar. Supongamos que vamos a definir un estndar llamado LMAPR o lenguaje de modelado de aprenderaprogramar.com. Ahora definimos dentro de nuestro estndar estas normas: Un animal debe representarse con su nombre escrito enteramente en minsculas enmarcado dentro de un rectngulo doble. Encima del nombre debe etiquetarse el tipo de animal as: . Por ejemplo, . Si un animal enva un mensaje a otro animal deben conectarse los dos animales con una lnea punteada terminada en flecha encima de la cual debe figurar el texto mensaje (Contenido del mensaje). Ahora supongamos que tenemos dos gatos, uno de los cuales le dice al otro Caza un ratn y tremelo aqu por favor. Veamos formas de representar esto:

Esta es una forma de representacin. Sin embargo, no se adapta al estndar que hemos definido por varios motivos: no indica encima de los nombres de los animales, no escribe los nombres en minsculas, no representa los animales con un rectngulo, etc.Veamos la representacin que s se adaptara al estndar definido:

Cules son las versiones de UML? Los antecedentes de UML se sitan en la dcada de los 90 con distintos estndares para modelado de software, no obstante podemos hablar de dos grandes versiones: UML 1.X (comprende UML 1.1, 1.2, 1.3, 1.4, 1.5): desde finales de los 90 se empez a trabajar con el estndar UML. En los aos sucesivos fueron apareciendo nuevas versiones que introducan mejoras o ampliaban a las anteriores. UML 2.X (comprende UML 2.1 hasta UML 2.5, 2.6, etc.): en torno a 2005 se difundi una nueva versin de UML a la que podemos denominar UML 2.X. Comprenden varias revisiones. UML 3.X: evolucin que se espera para UML 2.X. Hay que tener en cuenta que UML es un conjunto muy amplio de normas. Prcticamente nadie las conoce todas. Segn la empresa o universidad, institucin o centro de trabajo se usan determinados programas para crear diagramas y se conocen ciertas partes de UML, pero no el conjunto de UML.Qu versin usar? Para generar diagramas UML se usan programas informticos. Usa un programa actualizado pero no te preocupes en exceso por qu versin de UML usar, lo importante es que en tu grupo de trabajo o personas a las que se les vaya a enviar documentacin sobre un proyecto software sepan interpretar lo que se les enva. A nivel profesional no se le presta demasiada atencin a que se cumpla estrictamente con las normas de una determinada versin de UML, sino a que los esquemas estn bien construidos y razonados.2.2. Metodologa del Ciclo de Vida de un SistemadeJames Martn. Esta metodologa de desarrollo de Software es mejor conocida como Metodologa RAD (Rapid ApplicationDevelopment) o Desarrollo rpido de Aplicaciones, y fue creada por el gur de computacin James Martin en 1991. Est orientada a disminuir radicalmente el tiempo necesario para disear e implementar Sistemas de Informacin, el RAD cuenta con una participacin intensa del usuario, sesiones JAD, prototipaje, herramientas CSE integradas y generadores de cdigo. El Rad requiere cuatro ingredientes esenciales: gerencia, gente, metodologas y herramientas.

1) Etapa de Planificacin de Requisitos: Esta etapa requiere que los usuarios con un vasto conocimiento de los procesos de la compaa determinen cules sern las funciones del sistema. Debe darse una discusin estructurada sobre los problemas de la compaa que necesitan solucin.

2) Etapa de Diseo: Esta consiste de un anlisis detallado de las actividades de la compaa en relacin al sistema propuesto. Los usuarios participan activamente en talleres bajo la tutela de los profesionales de la informtica. En ellos descomponen funciones y definen entidades asociadas con el sistema. Una vez se completa el anlisis se crean los diagramas que definen las alteraciones entre los procesos y la data.

3) Construccin: En la etapa de construccin el equipo de desarrolladores trabajando de cerca con los usuarios finalizan el diseo y la construccin del sistema. La construccin de la aplicacin consistede una serie de pasos donde los usuarios tienen la oportunidad de afirmar los requisitos y repasar los resultados.

4) Implementacin: Esta etapa envuelve la implementacin del nuevo producto y el manejo de cambio del viejo al nuevo sistema. Se hacen pruebas comprensivas y se adiestran los usuarios.

2.3 Metodologa del Proceso Unificado de Desarrollo de Software

ElProceso Unificado de Desarrollo Softwareo simplementeProceso Unificadoes unmarco de desarrollo de softwareque se caracteriza por estar dirigido porcasos de uso, centrado en la arquitectura y por seriterativo e incremental. El refinamiento ms conocido y documentado del Proceso Unificado es elProceso Unificado de Rationalo simplementeRUP.

El Proceso Unificado no es simplemente un proceso, sino un marco de trabajo extensible que puede ser adaptado a organizaciones o proyectos especficos. De la misma forma, elProceso Unificado de Rational, tambin es un marco de trabajo extensible, por lo que muchas veces resulta imposible decir si un refinamiento particular del proceso ha sido derivado del Proceso Unificado o del RUP. Por dicho motivo, los dos nombres suelen utilizarse para referirse a un mismo concepto.

El nombreProceso Unificadose usa para describir el proceso genrico que incluye aquellos elementos que son comunes a la mayora de los refinamientos existentes. Tambin permite evitar problemas legales ya queProceso Unificado de RationaloRUPson marcas registradas porIBM(desde su compra deRational Software Corporationen 2003). El primer libro sobre el tema se denomin, en su versin espaola,El Proceso Unificado de Desarrollo de Software(ISBN 84-7829-036-2) y fue publicado en 1999 porIvar Jacobson,Grady BoochyJames Rumbaugh, conocidos tambin por ser los desarrolladores del UML, elLenguaje Unificado de Modelado. Desde entonces los autores que publican libros sobre el tema y que no estn afiliados a Rational utilizan el trminoProceso Unificado, mientras que los autores que pertenecen a Rational favorecen el nombre deProceso Unificado de Rational.

Por qu Analizar y Disear?

En resumidas cuentas, la cuestin fundamental del desarrollo del software es la escritura del cdigo. Despus de todo, los diagramas son solo imgenes bonitas. Ningn usuario va a agradecer la belleza de los dibujos; lo que el usuario quiere es software que funcione (UML Gota a Gota, Addison Wesley, pg. 7). Por lo tanto, cuando considere usar el UML es importante preguntarse por qu lo har y cmo le ayudar a usted cuando llegue el momento de escribir el cdigo. No existe una evidencia emprica adecuada que demuestre si estas tcnicas son buenas o malas; pero lo que s es cierto es que es de considerable ayuda para las etapas de mantenimiento en proyectos de mediana/avanzada envergadura.

Fases: El Proceso Unificado de desarrollo puede ser dividido en cuatro fases para su mejor desarrollo. Estas fases ayudando tanto a la elaboracin como a la resolucin de problemas.1. Inicio En la fase de inicio se define el negocio: facilidad de realizar el proyecto, se presenta un modelo, visin, metas, deseos del usuario, plazos, costos y viabilidad.2. Elaboracin En esta fase se obtiene la visin refinada del proyecto a realizar, la implementacin iterativa del ncleo de la aplicacin, la resolucin de riesgos altos, nuevos requisitos y se ajustan las estimaciones.3. Construccin Esta abarca la evolucin hasta convertirse en producto listo incluyendo requisitos mnimos. Aqu se afinan los detalles menores como los diferentes tipos de casos o los riesgos menores.4. Transicin En esta fase final, el programa debe estar listo para ser probado, instalado y utilizado por el cliente sin ningn problema. Una vez finalizada esta fase, se debe comenzar a pensar en futuras novedades para la misma.

Desde el punto de vistaTcnico: el proyecto est formado por los flujos de trabajo fundamentales: captura de requerimientos, anlisis, diseo, implementacin y pruebas.

Tantos el punto de vistaGerencialcomo elTcnicoconcuerdan en:La iteracin.

2.4 Metodologa de Kendall y Kendall.

El ciclo de vida de vida del desarrollo de sistemas es un enfoque por fases para el anlisis y el diseo cuya premisa principal consiste en que los sistemas se desarrollan mejor utilizando un ciclo especifico de actividades del analista y el usuario. (Kendall & Kendall) Segn la metodologa de Kendall & Kendall el ciclo de vida de un sistema consta de siete partes: siendo la primera la identificacin del problema, la segunda identificacin de requisitos de informacin, la tercera es el anlisis de las necesidades del sistema, la cuarta es el diseo del sistema recomendado, la quinta desarrollo y documentacin del sistema, la sexta prueba y mantenimiento y la ltima implementacin y evaluacin. Cada fase se explica por separado pero nunca se realizan como pasos aislados, ms bien es posible que algunas actividades se realicen de manera simultnea, y algunas de ellas podran repetirse.

FASE I: Identificacin de problemas, oportunidades y objetivos.

Observacin directa del entorno. Aplicacin de entrevista para recolectar informacin. Sintetizar la informacin recolectada para construir objetivos. Estimar el alcance del proyecto. Identificar si existe una necesidad, problema u oportunidad argumentada. Documentar resultados. Estudiar los riesgos del proyecto. Presentar un informe de vialidad.

En la primera fase el analista es el encargado de identificar los problemas de la organizacin, detallarlos, examinar, evaluar las oportunidades y objetivos.

El analista debe identificar y evaluar los problemas existentes en la organizacin de manera crtica y precisa. Mayormente los problemas son detectados por alguien ms y es cuando el analista es solicitado a fin de precisarlos. Las oportunidades son situaciones que el analista considera susceptibles de mejorar utilizando sistemas de informacin computarizados, lo cual le da mayor seguridad y eficacia a las organizaciones adems de obtener una ventaja competitiva. El analista debe identificar los objetivos, es decir, el analista debe averiguar lo que la empresa trata de conseguir, se podr determinar si algunas funciones de as aplicaciones de los sistemas de informacin pueden contribuir a que el negocio alcance sus objetivos aplicndolas a problemas u oportunidades especficos. Los usuarios, los analistas y los administradores de sistemas que coordinan el proyecto son los involucrados en la primera fase. Las actividades de esta fase son las entrevistas a los encargados de coordinar a los usuarios, sintetizar el conocimiento obtenido, estimar el alcance del proyecto y documentar los resultados. El resultado de esta fase en un informe de viabilidad que incluye la definicin del problema y un resumen de los objetivos. La administracin debe decidir si se sigue adelante o si se cancela el proyecto propuesto.

FASE II: Determinacin de los requerimientos de informacin.

Revisin de los objetivos. Identificar el dominio. Investigar la razn por la cual se implementa el sistema actual. Recolectar informacin sobre los procedimientos y operaciones que se desempean actualmente. Detallar especficamente: Quines son los involucrados, cul es la actividad, regla y restricciones del negocio, entorno de desarrollo de las actividades, momentos oportunos de desarrollo de cada funcin, la manera en que se desempean los procedimientos actuales. Elaborar una lista detallada y organizada de todos los procedimientos. Separar requerimientos funcionales y no funcionales. Adicionar al informe de la primera fase, esta nueva informacin.

En esta fase el analista se esfuerza por comprender la informacin que necesitan los usuarios para llevar a cabo sus actividades. Entre las herramientas que se utilizan para determinar los requerimientos de informacin de un negocio se encuentran mtodos interactivos como las entrevistas, los muestreos, la investigacin de datos impresos y la aplicacin de cuestionarios; mtodos que no interfieren con el usuario como la observacin del comportamiento de los encargados de tomar las decisiones y sus entornos e oficina, al igual que mtodos de amplio alcance como la elaboracin de prototipos.

Esta fase es til para que el analista confirme la idea que tiene de la organizacin y sus objetivos.

Los implicados en esta fase son el analista y los usuarios, por lo general los trabajadores y gerentes del rea de operaciones.

El analista necesita conocer los detalles de las funciones del sistema actual:El quin (la gente involucrada), el qu (la actividad del negocio), el dnde (el entorno donde se desarrollan las actividades), el cundo (el momento oportuno) y el cmo (la manera en que se realizan los procedimientos actuales) del negocio que se estudia.

Al trmino de esta fase, el analista debe conocer el funcionamiento del negocio y poseer informacin muy completa acerca de la gente, los objetivos, los datos y los procedimientos implicados.

FASE III: Anlisis de las necesidades.

Evaluar las dos fases anteriores. Modelar las entradas, los procesos y las salidas de las funciones ya identificadas. Elaborar diccionario de datos y sus especificaciones. Elaborar diagramas de procesos de cada funcin. Elaborar propuesta del sistema con todos los diagramas de operaciones y de procesos. Realizar el anlisis del riesgo sobre el realizado en las fases anteriores, tomando en cuenta el aspecto econmico, tcnico y operacional (estudio de factibilidad) Estimar en un diagrama de Gantt el tiempo que tomar desarrollar el sistema.

En esta fase el analista evala las dos fases anteriores, usa herramientas y tcnicas como el uso de diagramas de flujo de datos para graficar las entradas, los procesos y las salidas de las funciones del negocio en una forma grfica estructurada.

A partir de los diagramas de flujo de datos se desarrolla un diccionario de datos que enlista todos los datos utilizados en el sistema as como sus respectivas especificaciones.

El analista prepara en esta fase, una propuesta de sistemas que sintetiza sus hallazgos, proporciona un anlisis de costo/beneficio de las alternativas y ofrece, en su caso, recomendaciones sobre lo que se debe hacer.

FASE IV: Diseo del sistema recomendado.

Evaluar las tres fases anteriores. Realizar el diseo lgico de todo el sistema. Elaborar procedimientos precisos para la captura de los datos que van a ingresar al sistema de informacin. Elaborar el diseo de la base de datos. Disear las diferentes interfaces de usuarios de cada operacin, procedimiento y/o funcin. Disear controles y procedimientos de respaldos que protejan al sistema y a los datos. Producir los paquetes especficos de programas para los programadores. Elaborar una lista de las funciones genricas y de las que ser obligatorio crear.

En esta fase el analista utiliza la informacin recopilada en las primeras fases para realizar el diseo lgico del sistema de informacin.

El analista disea procedimientos precisos para la captura de datos que aseguran que los datos que ingresen al sistema de informacin sean correctos.

Facilita la entrada eficiente de datos al sistema de informacin mediantes tcnicas adecuadas de diseo de formularios y pantallas.

La concepcin de la interfaz de usuario forma parte del diseo lgico del sistema de informacin.

La interfaz conecta al usuario con el sistema y por tanto es sumamente importante.

Tambin incluye el diseo de archivos o bases de datos que almacenarn gran parte delos datos indispensables para los encargados de tomar las decisiones en la organizacin.

En esta fase el analista interacta con los usuarios para disear la salida (en pantalla o impresa) que satisfaga las necesidades de informacin de estos ltimos.

Finalmente el analista debe disear controles y procedimientos de respaldo que protejan al sistema y a los datos y producir paquetes de especificaciones de programa para los programadores.

Cada paquete debe contener esquemas para la entrada y la salida, especificaciones de archivos y detalles del procesamiento.

FASE V: Desarrollo y documentacin del software.

Evaluar los procedimientos que va a ser desarrollados por el programador. Mostrar y explicar cada procedimiento, funcin y operacin al programador. Elaborar manuales de procedimientos internos del sistema. Elaborar manuales externos de ayuda a los usuarios del sistema. Elaborar demostraciones para los usuarios y la interaccin con distintas interfaces. Elaborar actualizaciones para los diferentes procedimientos. Elaborar un informe con el tiempo que se llev construir cada procedimiento.

En la quinta fase del ciclo del desarrollo de sistemas, el analista trabaja de manera conjunta con los programadores para desarrollar cualquier software original necesario. Entre las tcnicas estructuradas para disear y documentar software se encuentran los diagramas de estructuras, los diagramas de Nassi-Shneiderman y el pseudocdigo.

Durante esta fase el analista trabaja con los usuarios para desarrollar documentacin efectiva para el software, como manuales de procedimientos, ayuda en lnea y sitios web que incluyan respuestas a preguntas frecuentes en archivos lame que se integrarn al nuevo software.

La documentacin indica a los usuarios cmo utilizar el sistema y qu hacer en caso de que surjan problemas derivados de este uso. Los programadores desempean un rol clave en esta fase porque disean, codifican y eliminan errores sintcticos de los programas de cmputo.

FASE VI: Prueba y mantenimiento del sistema.

Realizar la programacin de las pruebas del sistema. Realizar un instrumento para evaluar el sistema de informacin. El programador deber elaborar un resumen de las pruebas del sistema. El analista deber realizar un informe de sus pruebas y discutirlo con el programador. Elaborar la planificacin de las horas del mantenimiento del sistema. Elaborar la lista de las operaciones que pudieran sufrir modificaciones de cdigos.

Antes de poner en funcionamiento el sistema es necesario probarlo es mucho menos costoso encontrar los problemas antes que el sistema se entregue a los usuarios.

Una parte de la pruebas la realizan los programadores solos, y otra la llevan a cabo de manera conjunta con los analistas de sistemas. Primero se realizan las pruebas con datos de muestra para determinar con precisin cules son los problemas y posteriormente se realiza otra con datos reales del sistema actual.

El mantenimiento del sistema de informacin y su documentacin empiezan en esta fase y se llevan de manera rutinaria durante toda su vida til.

FASE VII: Implementacin y evaluacin del sistema.

Planificar gradualmente la conversin del sistema anterior. Instalar los equipos de hardware necesarios para el funcionamiento del software creado. Capacitar por medio de talleres a los usuarios en el manejo de equipos y software creados. Evaluar la adaptabilidad de los usuarios al sistema.

Esta es la ltima fase del desarrollo de sistemas, y aqu el analista participa en la implementacin del sistema de informacin. En esta fase se capacita a los usuarios en el manejo del sistema. Parte de la capacitacin la imparten los fabricantes, pero la supervisin de sta es responsabilidad del analista de sistemas.

Se menciona la evaluacin como la fase final del ciclo de vida del desarrollo de sistemas principalmente en reas del debate. En realidad, la evaluacin se lleva a cabo durante cada una de las fases.

El trabajo de sistemas es cclico, cuando un analista termina una fase del desarrollo de sistemas y pasa a la siguiente, el surgimiento de un problema podra obligar a regresar a la fase previa y modificar el trabajo realizado.

2.5 Metodologa de Administracin de Relaciones (RMM).

La Metodologa de Gestin de Relaciones (Relationship Management Methodology, en adelante RMM) para el diseo hipermedia fue introducida por primera vez en 1995, y desde entonces ha evolucionado en muchos aspectos para dar respuesta al rpido incremento de la demanda de aplicaciones en la World Wide Web. La mejora de la metodologa est demostrada por el diseo de complejas aplicaciones web. Trataremos cuestiones de Diseo e Implementacin, incluyendo integracin de bases de datos, as como las aproximaciones top-down (descendente) frente a bottomup (ascendente) para el desarrollo de aplicaciones WIS (Web InformationSystem). Presentamos tambin la notacin grfica y de lenguaje de programacin para las nuevas construcciones (o constructores") creadas para RMM. Esta metodologa fomenta un diseo correcto y un desarrollo mantenible de la hipermedia.

La RMM o Relationship Management Methodology se define como un proceso de anlisis, diseo y desarrollo de aplicaciones hipermedia. Los elementos principales de este mtodo son el modelo E-R (Entidad-Relacin) y el modelo RMDM (Relationship Management Data Model) basado en el modelo HDM. La metodologa fue creada por Isakowitz, Stohr y Balasubramanian. Esta metodologa es apropiada para dominios con estructuras regulares (es decir, con clases de objetos bien definidas, y con claras relaciones entre esas clases). Por ejemplo, catlogos o "frentes" de bases de datos tradicionales. Segn sus autores, est orientada a problemas con datos dinmicos que cambian con mucha frecuencia, ms que a entornos estticos.

El modelo propone un lenguaje que permite describir los objetos del dominio, sus interrelaciones y los mecanismos de navegacin hipermedia de la aplicacin. Los objetos del dominio se definen con la ayuda de entidades, atributos y relaciones asociativas. El modelo introduce el concepto de slice (trozo) con el fin de modelizar los aspectos unidos a la presentacin de las entidades. Un slice corresponde a un subconjunto de atributos de una misma entidad destinados a ser presentados de forma agrupada. La navegacin se modeliza con la ayuda de primitivas de acceso, enlaces estructurales (unidireccional y bidireccional) que permiten especificar la navegacin entre slices, y visita guiada condicional, ndice condicional y agrupacin, que permiten especificar la navegacin entre entidades. El esquema completo del dominio y de la navegacin de la aplicacin se denomina esquema RMDM y se obtiene como resultado de las tres primeras etapas del mtodo. Las etapas son:

Primera Etapa:representar los objetos del dominio con la ayuda del modelo Entidad-Relacin ampliado con relaciones asociativas (aqullas que permiten representar caminos navegacionales entre entidades puestos en evidencia en la fase de anlisis).

Segunda Etapa:determinar la presentacin del contenido de las entidades de la aplicacin as como su modo de acceso. El esquema obtenido como resultado de esta etapa se denomina esquema E.R+. Se trata de un esquema Entidad-Relacin en el que cada entidad ha sido reemplazada por su esquema de entidad. Un esquema de entidad est constituido por nodos (los trozos o slides) unidos por relaciones estructurales.

Tercera Etapa:definir los caminos de navegacin inducidos por las relaciones asociativas del esquema E-R+. A continuacin, es posible definir estructuras de acceso de alto nivel (agrupaciones), lo que permite dotar a la aplicacin de accesos jerrquicos a niveles diferentes de los trozos de informacin. El esquema RMDM resultante se obtiene aadiendo al esquema E-R+ las agrupaciones y caminos navegacionales definidos en esta etapa.

Las cuatro etapas restantes consisten en:

Definicin del protocolo de conversin de elementos del diagrama RMDM en objetos de la plataforma de desarrollo. Concepcin del interfaz usuario. Concepcin del comportamiento en ejecucin. Construccin del sistema y test.

La metodologa RMM permite hacer explcita la navegacin al hacer el anlisis, lo que permite, tericamente, obtener una navegacin ms estructurada e intuitiva, y lo hace de una forma muy sencilla, como es aadir unas primitivas a un modelo entidad-relacin tradicional. El concepto de slice es muy til, ya que permite agrupar datos de una entidad en diferentes pantallas. Se utilizara, por ejemplo, para mostrar dos vdeos en dos pantallas diferentes sobre un mismo fenmeno. Tambin es interesante la primitiva de grupo, que permite mostrar la jerarqua de mens.

RMM representa el primer caso en el que se crea una metodologa completa definiendo las distintas fases y no nicamente un modelo de datos. Adems, se basa en un modelo de datos relacional, ajustndose as a la gran mayora de las aplicaciones existentes. Sin embargo, los mecanismos de acceso a la informacin son excesivamente simples y valen para un problema con pocas entidades, pero el modelo se queda corto si hay gran nmero de ellas.

2.6 Metodologa Orientada a Objetos.

La metodologa orientada a objetos ha derivado de las metodologas anteriores a ste. As como los mtodos de diseo estructurado realizados guan a los desarrolladores que tratan de construir sistemas complejos utilizando algoritmos como sus bloques fundamentales de construccin, similarmente los mtodos de diseo orientado a objetos han evolucionado para ayudar a los desarrolladores a explotar el poder de los lenguajes de programacin basados en objetos y orientados a objetos, utilizando las clases y objetos como bloques de construccin bsicos. Actualmente el modelo de objetos ha sido influencia por un numero de factores no solo de programacin orientada a objetos (ObjectOrientedProgramming,OOPpor sus siglas en ingls). Adems, el modelo de objetos ha probado ser un concepto uniforme en las ciencias de la computacin, aplicable no slo a los lenguajes de programacin sino tambin al diseo de interfaces de usuario, bases de datos y arquitectura de computadoras por completo. La razn de ello es, simplemente, que una orientacin a objetos nos ayuda a hacer frente a la inherente complejidad de muchos tipos de sistemas. Se define a un objeto como "una entidad tangible que muestra alguna conducta bien definida". Un objeto "es cualquier cosa, real o abstracta, acerca de la cual almacenamos datos y los mtodos que controlan dichos datos". Los objetos tienen una cierta "integridad" la cual no deber ser violada. En particular, un objeto puede solamente cambiar estado, conducta, ser manipulado o estar en relacin con otros objetos de manera apropiada a este objeto. Actualmente, elAnlisis Orientado a Objetos(AOO) va progresando como mtodo de anlisis de requisitos por derecho propio y como complemento de otros mtodos de anlisis. En lugar de examinar un problema mediante el modelo clsico de entrada-proceso-salida (flujo de informacin) o mediante un modelo derivado exclusivamente de estructuras jerrquicas de informacin, el AOO introduce varios conceptos nuevos. Estos conceptos nuevos le parecen inusuales a mucha gente, pero son bastante naturales. Unaclasees una plantilla para objetos mltiples con caractersticas similares. Las clases comprenden todas esas caractersticas de un conjunto particular de objetos. Cuando se escribe un programa en lenguaje orientado a objetos, no se definen objetos verdaderos sino se definen clases de objetos. Unainstanciade una clase es otro trmino para un objeto real. Si la clase es la representacin general de un objeto, una instancia es su representacin concreta. A menudo se utiliza indistintamente la palabra objeto o instancia para referirse, precisamente, a un objeto. En los lenguajes orientados a objetos, cada clase est compuesta de dos cualidades:atributos(estado) ymtodos(comportamiento o conducta). Los atributos son las caractersticas individuales que diferencian a un objeto de otro (ambos de la misma clase) y determinan la apariencia, estado u otras cualidades de ese objeto. Los atributos de un objeto incluyen informacin sobre su estado. Los mtodos de una clase determinan el comportamiento o conducta que requiere esa clase para que sus instancias puedan cambiar su estado interno o cuando dichas instancias son llamadas para realizar algo por otra clase o instancia. El comportamiento es la nica manera en que las instancias pueden hacerse algo a s mismas o tener que hacerles algo. Los atributos se encuentran en la parte interna mientras que los mtodos se encuentran en la parte externa del objeto Para definir el comportamiento de un objeto, se crean mtodos, los cuales tienen una apariencia y un comportamiento igual al de las funciones en otros lenguajes de programacin, los lenguajes estructurados, pero se definen dentro de una clase. Los mtodos no siempre afectan a un solo objeto; los objetos tambin se comunican entre s mediante el uso de mtodos. Una clase u objeto puede llamar mtodos en otra clase u objeto para avisar sobre los cambios en el ambiente o para solicitarle a ese objeto que cambie su estado. Cualquier cosa que un objeto no sabe, o no puede hacer, es excluida del objeto. Adems, como se puede observar de los diagramas, las variables del objeto se localizan en el centro o ncleo del objeto. Los mtodos rodean y esconden el ncleo del objeto de otros objetos en el programa. Al empaquetamiento de las variables de un objeto con la proteccin de sus mtodos se le llamaencapsulamiento. Tpicamente, el encapsulamiento es utilizado para esconder detalles de la puesta en prctica no importantes de otros objetos. Entonces, los detalles de la puesta en prctica pueden cambiar en cualquier tiempo sin afectar otras partes del programa. Esta imagen conceptual de un objeto un ncleo de variables empaquetadas en una membrana protectora de mtodos es una representacin ideal de un objeto y es el ideal por el que los diseadores de sistemas orientados a objetos luchan. Sin embargo, no lo es todo: a menudo, por razones de eficiencia o la puesta en prctica, un objeto puede querer exponer algunas de sus variables o esconder algunos de sus mtodos. El encapsulamiento de variables y mtodos en un componente de software ordenado es, todava, una simple idea poderosa que provee dos principales beneficios a los desarrolladores de software: Modularidad, esto es, el cdigo fuente de un objeto puede ser escrito, as como darle mantenimiento, independientemente del cdigo fuente de otros objetos. As mismo, un objeto puede ser transferido alrededor del sistema sin alterar su estado y conducta. Ocultamiento de la informacin, es decir, un objeto tiene una "interfaz publica" que otros objetos pueden utilizar para comunicarse con l. Pero el objeto puede mantener informacin y mtodos privados que pueden ser cambiados en cualquier tiempo sin afectar a los otros objetos que dependan de ello. Los objetos proveen el beneficio de la modularidad y el ocultamiento de la informacin. Las clases proveen el beneficio de la reutilizacin. Los programadores de software utilizan la misma clase, y por lo tanto el mismo cdigo, una y otra vez para crear muchos objetos. En las implantaciones orientadas a objetos se percibe un objeto como un paquete de datos y procedimientos que se pueden llevar a cabo con estos datos. Esto encapsula los datos y los procedimientos. La realidad es diferente: los atributos se relacionan al objeto o instancia y los mtodos a la clase. Por qu se hace as? Los atributos son variables comunes en cada objeto de una clase y cada uno de ellos puede tener un valor asociado, para cada variable, diferente al que tienen para esa misma variable los dems objetos. Los mtodos, por su parte, pertenecen a la clase y no se almacenan en cada objeto, puesto que sera un desperdicio almacenar el mismo procedimiento varias veces y ello va contra el principio de reutilizacin de cdigo. Otro concepto muy importante en la metodologa orientada a objetos es el deherencia. La herencia es un mecanismo poderoso con el cual se puede definir una clase en trminos de otra clase; lo que significa que cuando se escribe una clase, slo se tiene que especificar la diferencia de esa clase con otra, con lo cual, la herencia dar acceso automtico a la informacin contenida en esa otra clase. Con la herencia, todas las clases estn arregladas dentro de una jerarqua estricta. Cada clase tiene una superclase (la clase superior en la jerarqua) y puede tener una o ms subclases (las clases que se encuentran debajo de esa clase en la jerarqua). Se dice que las clases inferiores en la jerarqua, las clases hijas, heredan de las clases ms altas, las clases padres. Las subclases heredan todos los mtodos y variables de las superclases. Es decir, en alguna clase, si la superclase define un comportamiento que la clase hija necesita, no se tendr que redefinir o copiar ese cdigo de la clase padre De esta manera, se puede pensar en una jerarqua de clase como la definicin de conceptos demasiado abstractos en lo alto de la jerarqua y esas ideas se convierten en algo ms concreto conforme se desciende por la cadena de la superclase. Sin embargo, las clases hijas no estn limitadas al estado y conducta provistos por sus superclases; pueden agregar variables y mtodos adems de los que ya heredan de sus clases padres. Las clases hijas pueden, tambin, sobre escribir los mtodos que heredan por implementaciones especializadas para esos mtodos. De igual manera, no hay limitacin a un slo nivel de herencia por lo que se tiene un rbol de herencia en el que se puede heredar varios niveles hacia abajo y mientras ms niveles descienda una clase, ms especializada ser su conducta. La herencia presenta los siguientes beneficios: Las subclases proveen conductas especializadas sobre la base de elementos comunes provistos por la superclase. A travs del uso de herencia, los programadores pueden reutilizar el cdigo de la superclase muchas veces. Los programadores pueden implementar superclases llamadas clases abstractas que definen conductas "genricas". Las superclases abstractas definen, y pueden implementar parcialmente, la conducta pero gran parte de la clase no est definida ni implementada. Otros programadores concluirn esos detalles con subclases especializadas.2.7. Metodologa del Software Educativo por lvaro Galvis (ISE). Es una metodologa de desarrollo de software que contempla una serie de fases o etapas de un proceso sistemtico atendiendo a: anlisis, diseo, desarrollo, prueba y ajuste, y por ltimo implementacin.

Etapas:

Etapa 1:Anlisis

Caractersticas de la poblacin objetivo: edad (fsica y mental), sexo, caractersticas fsicas y mentales (si son relevantes), experiencias previas, expectativas, actitudes, aptitudes, intereses o motivadores por aprender.

Conducta de entrada y campo vital: nivel escolar, desarrollo mental, fsico o psicolgico, entorno familiar y escolar, etc.

Problema o necesidad a atender: Para establecer la necesidad se puede recurrir a los mecanismos de anlisis de necesidades educativas en. Estos mecanismos usan entrevistas, anlisis de resultados acadmicos, etc. para detectar los problemas o posibles necesidades que deben ser atendidas. El problema o necesidad no tiene que estar necesariamente relacionado con el sistema educativo formal, pueden ser necesidades sentidas, econmicas, sociales, normativas, etc.

Principios pedaggicos y didcticos aplicables: se debe analizar cmo se ha llevado a cabo el proceso de enseanza-aprendizaje para establecer cmo debe enfocarse el ambiente, qu factores tomar en cuenta, qu objetivos debe cumplir.

Justificacin de uso de los medios interactivos: Para cada problema o necesidad encontrada se debe establecer una estrategia de solucin contemplando diferentes posibilidades. El apoyo informtico debe ser tomado en cuenta siempre y cuando no exista un mecanismo mejor para resolver el problema: soluciones administrativas, ver si el problema se soluciona al tomar decisiones de tipo administrativo; soluciones acadmicas, cambios en metodologas de clase; mejoras a los medios y materiales de enseanza contemplando el uso de medios informticos. Una vez que se han analizado todas las alternativas se puede decir por qu el uso de medios informticos es una buena solucin. La justificacin se puede basar en la no existencia de otro medio mejor y en la relacin costo-beneficio para la institucin pues puede ser que exista una mejor solucin pero que demande mayor tiempo y esfuerzo o un mayor costo econmico,etc.

Diagramas de interaccin: Permiten ver secuencias de interaccin entre el usuario y la aplicacin, representando lo que se espera del dilogo y dando ms detalle a la descripcin textual de la descripcin de la aplicacin. Los diagramas de interaccin son un formalismo que permite ver la secuencia de acciones entre diferentes partes de la aplicacin involucrada en llevar a cabo determinada actividad. Es importante ver la secuencia de acciones para cada escenario de interaccin. Con base en estos diagramas se pueden ver cules pueden ser las necesidades de informacin en cada escenario de interaccin y se puede ir pensando en cules pueden ser los algoritmos que sern usados.

Etapa 2:Diseo

Educativo (este debe resolver las interrogantes que se refieren al alcance, contenido y tratamiento que debe ser capaz de apoyar el Sistema Educativo).

Comunicacional (es donde se maneja la interaccin entre usuario y mquina, se denomina interfaz).

Computacional (con base a las necesidades se establece qu funciones es deseable que cumpla el Sistemas Educativo en apoyo de sus usuarios, el docente y los estudiantes).

Etapa 3:Desarrollo

En esta fase se implementa la aplicacin usando la informacin obtenida anteriormente. Tomando en cuenta las restricciones que se tengan.

Etapa 4:Prueba Piloto

En esta etapa se pretende ayudar a la depuracin del Sistema Educativo a partir de su utilizacin por una muestra representativa de los tipos de destinatarios para los que se hizo y la consiguiente evaluacin formativa. Es imprescindible realizar ciertas validaciones (efectuadas por expertos) de los prototipos durante las etapas de diseo y prueba en uno a uno de los mdulos desarrollados, a medida que estos estn funcionales.

Etapa 5:

Prueba de Campo La prueba de campo de un Sistema Educativo es mucho ms que usarlo con toda la poblacin objeto.Si se exige, pero no se limita a esto. Es importante que dentro del ciclo de desarrollo hay que buscar la oportunidad de comprobar, en la vida real, que aquello que a nivel experimental pareca tener sentido, lo sigue teniendo, es decir, si efectivamente la aplicacin satisface las necesidades y cumple la funcionalidad requerida.

2.8. Metodologa de Sistemas Blandos (SSM) de Peter Checkland. La SSM de Peter Checkland es una metodologa sistmica fundamentada en el concepto de perspectiva o en el lenguaje de la metodologa Weltanschauung. Un weltanschauung representa la visin propia de un observador, o grupo de ellos, sobre un objeto de estudio, visin sta que afecta las decisiones que el(los) observador(es) pueda(n) tomar en un momento dado sobre su accionar con el objeto. La SSM toma como punto de partida la idealizacin de estos weltanschauung para proponer cambios sobre el sistema que en teora deberan tender a mejorar su funcionamiento. En este punto es conveniente aclarar la nocin de weltanschauung, para ello se puede considerar como ejemplo, las diferencias que entre un observador y otro presenta el propsito de las universidades: Para algunos estudiantes pueden ser centros de estudio donde asisten para formarse con miras a ingresar a un mercado de trabajo profesional, para otros pueden ser centros donde tomar experiencia en la diatriba poltica, para otro grupo pueden ser centros donde converge el conocimiento universal y acuden a entrar en contacto con l, etc. Para algunos profesores pueden ser centros de enseanza donde acuden a laborar impartiendo conocimientos entre sus estudiantes, para otros son centros de docencia e investigacin donde, a travs del desarrollo de la investigacin, nutren su actividad de docencia, siempre con la intencin de brindar lo mejor posible de sus conocimientos a sus estudiantes, as mismo para otro grupo de profesores la universidad puede ser un centro donde ellos y los estudiantes acuden a intercambiar experiencias dentro de un proceso interactivo de enseanza aprendizaje, etc. Como se puede ver, en ambos casos, estudiantes y profesores, la visin que se tiene sobre las universidades es diferente, e incluso entre estudiantes y profesores se pueden tener diferentes visiones. Estas visiones son los weltanschauung sobre las universidades, es importante hacer notar que stos no son correctos o errneos, ni unos son mejores que otros, todos son igualmente vlidos e incluso complementarios. Otro concepto importante para la SSM es el de sistema blando, segn Checkland, un sistema blando es aquel que est conformado por actividades humanas, tiene un fin perdurable en el tiempo y presenta problemticas in-estructuradas o blandas; es decir aquellas problemticas de difcil definicin y carentes de estructura, en las que los fines, metas, propsitos, son problemticos en s.

La SSM est conformada por siete (7) estadios cuyo orden puede variar de acuerdo a las caractersticas del estudio, a continuacin se describen brevemente estos estadios.

Estadio 1:

La Situacin Problema no Estructurada: en este estadio se pretende lograr una descripcin de la situacin donde se percibe la existencia de un problema, sin hacer hincapi en el problema en s, esto es sin dar ningn tipo de estructura a la situacin.

Estadio 2:

La Situacin Problema Expresada: se da forma a la situacin describiendo su estructura organizativa, actividades e interrelacin de stas, flujos de entrada y salida, etc.

Estadio 3:

Definiciones Raz de Sistemas Pertinentes: se elaboran definiciones de lo que, idealmente, segn los diferentes weltanschauung involucrados, es el sistema. La construccin de estas definiciones se fundamenta en seis factores que deben aparecer explcitos en todas ellas, estos se agrupan bajo el nemnico de sus siglas en ingles CATWOE (Bergvall-Kreborn et. al. 2004), a saber: consumidores, actores, proceso de transformacin, weltanschauung, poseedor y restriccin del ambiente.

Estadio 4:

Confeccin y Verificacin de Modelos Conceptuales: partiendo de los verbos de accin presentes en las definiciones raz, se elaboran modelos conceptuales que representen, idealmente, las actividades que, segn la definicin raz en cuestin, se deban realizar en el sistema (Ramrez 1983). Existirn tantos modelos conceptuales como definiciones raz.

Este estadio se asiste de los sub-estadios 4a y 4b.

Estadio 4a:

Concepto de Sistema Formal: este consiste en el uso de un modelo general de sistema de la actividad humana que se puede usar para verificar que los modelos construidos no sean fundamentalmente deficientes.

Estadio 4b:

Otros Pensamientos de Sistemas: consiste en transformar el modelo obtenido en alguna otra forma de pensamiento sistmico que, dadas las particularidades del problema, pueda ser conveniente.

Estadio 5:

Comparacin de los modelos conceptuales con la realidad: se comparan los modelos conceptuales con la situacin actual del sistema expresada, dicha comparacin pretende hacer emerger las diferencias existentes entre lo descrito en los modelos conceptuales y lo que existe en la actualidad en el sistema.

Estadio 6:

Diseo de Cambios Deseables, Viables: de las diferencias emergidas entre la situacin actual y los modelos conceptuales, se proponen cambios tendientes a superarlas, dichos cambios deben ser evaluados y aprobados por las personas que conforman el sistema humano, para garantizar con esto que sean deseables y viables.

Estadio 7:

Acciones para Mejorar la Situacin Problema: finalmente este estadio comprende la puesta en marcha de los cambios diseados, tendientes a solucionar la situacin problema, y el control de los mismos. Este estadio no representa el fin de la aplicacin de la metodologa, pues en su aplicacin se transforma en un ciclo de continua conceptualizacin y habilitacin de cambios, siempre tendiendo a mejorar la situacin.

2.9. Metodologa MERINDE. La Metodologa MeRinde surge de la combinacin y adaptacin de modelos y metodologas ampliamente utilizadas para el desarrollo de software y la reingeniera de procesos del negocio. Esta metodologa est fuertemente fundamentada en los requerimientos del Centro Nacional de Tecnologa de Informacin (CNTI) y en varias metodologas como el Proceso Unificado (UP) especialmente. Pretende entre sus principales objetivos apoyar a las comunidades de desarrollo de software libre en sus proyectos, suministrando las herramientas necesarias para que estos cumplan con un proceso de desarrollo y documentacin de sus sistemas. MeRinde es concebida para abarcar el desarrollo completo de sistemas de software de diversa complejidad y magnitud, por lo cual su estructura responde a desarrollos mximos y deber adaptarse y dimensionarse en cada momento de acuerdo a las caractersticas particulares de cada proyecto. Dada la adaptabilidad que puede sufrir la metodologa, esta puede llegarse a aplicar bajo un enfoque gil, lo cual no se detalla en la presente versin, pero no se descarta su empleo.

As mismo, esta permite producir y mantener una librera de plantillas reutilizables para ingeniera de software. Est basada en componentes, lo cual quiere decir que el sistema software en construccin est formado por componentes software interconectados a travs de interfaces bien definidas. Adems, la metodologa utiliza el Lenguaje Unificado de Modelado (Unified Modeling Language, UML) para preparar todos los diagramas de un sistema software. Con el proceso de desarrollo y con las plantillas de esta metodologa se busca a su vez estimular con la transferencia del conocimiento entre las comunidades desarrolladoras de software libre, con lo cual no solo se pretende que sea compartido los cdigos de los sistemas sino que tambin se compartan la documentacin como gua de referencia para mejoras por terceros al sistema o para que sirva como modelo a otras comunidades para el desarrollo de sus propios sistemas.

2.10. Metodologa SCRUM.

SCRUM es el nombre con el que se denomina a los marcos de desarrollo giles caracterizados por:

Adoptar una estrategia de desarrollo incremental, en lugar de la planificacin y ejecucin completa del producto.Basar la calidad del resultado ms en el conocimiento tcito de las personas en equipos auto-organizados, que en la calidad de los procesos empleados.Solapamiento de las diferentes fases del desarrollo, en lugar de realizar una tras otra en un ciclo secuencial o de cascada.

Beneficios de SCRUM

Flexibilidad a cambios.Gran capacidad de reaccin ante los cambiantes requerimientos generados por las necesidades del cliente o la evolucin del mercado. El marco de trabajo est diseado para adecuarse a las nuevas exigencias que implican proyectos complejos.

Reduccin del Time to Market.El cliente puede empezar a utilizar las caractersticas ms importantes del proyecto antes de que est completamente terminado. Mayor calidad del software.El trabajo metdico y la necesidad de obtener una versin de trabajo funcional despus de cada iteracin, ayuda a la obtencin de un software de alta calidad. Mayor productividad.Se logra, entre otras razones, debido a la eliminacin de la burocracia y la motivacin del equipo proporcionado por el hecho de que pueden estructurarse de manera autnoma. Maximiza el retorno de la inversin (ROI).Creacin de software solamente con las prestaciones que contribuyen a un mayor valor de negocio gracias a la priorizacin por retorno de inversin. Predicciones de tiempos.A travs de este marco de trabajo se conoce la velocidad media del equipo por sprint, con lo que es posible estimar de manera fcil cuando se podr hacer uso de una determinada funcionalidad que todava est en el Backlog. Reduccin de riesgosEl hecho de llevar a cabo las funcionalidades de mayor valor en primer lugar y de saber la velocidad a la que el equipo avanza en el proyecto, permite despejar riesgos efectivamente de manera anticipada.

Conclusin

1. Para generar diagramas UML se usan programas informticos. Usa un programa actualizado pero no te preocupes en exceso por qu versin de UML usar, lo importante es que en tu grupo de trabajo o personas a las que se les vaya a enviar documentacin sobre un proyecto software sepan interpretar lo que se les enva. A nivel profesional no se le presta demasiada atencin a que se cumpla estrictamente con las normas de una determinada versin de UML, sino a que los esquemas estn bien construidos y razonados.2. El analista necesita conocer los detalles de las funciones del sistema actual:El quin (la gente involucrada), el qu (la actividad del negocio), el dnde (el entorno donde se desarrollan las actividades), el cundo (el momento oportuno) y el cmo (la manera en que se realizan los procedimientos actuales) del negocio que se estudia.3. La Metodologa MeRinde surge de la combinacin y adaptacin de modelos y metodologas ampliamente utilizadas para el desarrollo de software y la reingeniera de procesos del negocio. Esta metodologa est fuertemente fundamentada en los requerimientos del Centro Nacional de Tecnologa de Informacin (CNTI) y en varias metodologas como el Proceso Unificado (UP) especialmente.4. El ciclo de vida de vida del desarrollo de sistemas es un enfoque por fases para el anlisis y el diseo cuya premisa principal consiste en que los sistemas se desarrollan mejor utilizando un ciclo especifico de actividades del analista y el usuario.5. El analista disea procedimientos precisos para la captura de datos que aseguran que los datos que ingresen al sistema de informacin sean correctos.

Bibliografa

http://www.significados.com/metodo/

http://www.significados.com/metodologia/

http://aprenderaprogramar.com/index.php?option=com_content&view=article&id=688:ique-es-y-para-que-sirve-uml-versiones-de-uml-lenguaje-unificado-de-modelado-tipos-de-diagramas-uml&catid=46:lenguajes-y-entornos&Itemid=163

http://mundoinformatico321.blogspot.com/2012/12/metodologia-de-james-martin-y-uml.html

https://es.wikipedia.org/wiki/Proceso_unificado

http://mundoinformatico321.blogspot.com/2012/11/metodologia-kendall-kendall.html

http://www.infor.uva.es/~jmrr/tgp/rmm/e_rmm.pdf

http://mundoinformatico321.blogspot.com/2012_12_01_archive.html

http://profesores.fi-b.unam.mx/carlos/aydoo/conceptos_oo.htmlhttps://es.wikipedia.org/wiki/Scrum

http://www.merinde.net/

http://mundoinformatico321.blogspot.com/2012/12/metodologia-del-software-educativo-por.html