Successfully reported this slideshow.
We use your LinkedIn profile and activity data to personalize ads and to show you more relevant ads. You can change your ad preferences anytime.

Trabajo analisis y diseño de sistemas

1,620 views

Published on

TRabajo

Published in: Education
  • Comprueba la fuente ⇒ www.EddyHelp.com ⇐. Este sitio me ha ayudado a escribir artículos científicos en inglés y español.
       Reply 
    Are you sure you want to  Yes  No
    Your message goes here
  • Be the first to like this

Trabajo analisis y diseño de sistemas

  1. 1. Análisis y Diseño de Sistemas Autor: Juan Manuel Velásquez Canache C.I: 23.770.791
  2. 2. Introducción Un sistema es un objeto complejo cuyos componentes se relacionan con al menos algún otro componente; puede ser material o conceptual.1 Todos los sistemas tienen composición, estructura y entorno, pero sólo los sistemas materiales tienen mecanismo, y sólo algunos sistemas materiales tienen figura (forma). Existe una gran variedad de sistema y una amplia gama de tipologías para clasificarlos, de acuerdo con ciertas características básicas., En cuanto a su constitución, los sistemas pueden ser físicos o abstractos. El término “lenguaje” ha generado bastante confusión respecto a lo que es UML. En realidad el término lenguaje quizás no es el más apropiado, ya que no es un lenguaje propiamente dicho, sino una serie de normas y estándares gráficos respecto a cómo se deben representar los esquemas relativos al software. Mucha gente piensa por confusión que UML es un lenguaje de programación y esta idea es errónea: UML no es un lenguaje de programación. Como decimos, UML son una serie de normas y estándares que dicen cómo se debe representar algo.
  3. 3. 1. Definición Método: Es un modo, manera o forma de realizar algo de forma sistemática, organizada y/o estructurada. Hace referencia a una técnica o conjunto de tareas para desarrollar la misma. En algún caso se entiende también como la forma habitualde realizar algo por una persona basada en la experiencia, costumbre y preferencias personales. Metodología: Como metodología se denomina la serie de métodos y técnicas de rigor científico que se aplican sistemáticamente durante un proceso de investigación para alcanzar un resultado teóricamente válido. En este sentido, la metodología funciona como el soporte conceptual que rige la manera en que aplicamos los procedimientos en una investigación. La palabra, como tal, proviene del griego μέθοδος (méthodos), que significa ‘método’, y el sufijo -logía, que deriva de λóγος (lógos) y traduce ‘ciencia, estudio, tratado’. De allí que también sea definida como la ciencia del método. Podemos encontrar metodología en distintas áreas de estudio, como lametodología didáctica en Educación, o la jurídica en Derecho, del mismo modo como para la solución de problemas determinados podemos aplicar una serie de pasos específicos que, en suma, funcionan como una metodología. Metodología de la investigación: La metodología de la investigación es una disciplina de conocimiento encargada de elaborar, definir y sistematizar el conjunto de técnicas, métodos y procedimientos que se deben seguir durante el desarrollo de un proceso de investigación para la producción de conocimiento. Orienta la manera en que vamos a enfocar una investigación 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 estándares de exigencia científica. La metodología de la investigación, en este sentido, es también la parte de un proyecto de investigación donde se exponen y describen razonadamente los criterios adoptados en la elección de la metodología, sea esta cuantitativa o cualitativa. 2. Metodologías para el Análisis y Diseño de Sistemas. 2.1 Lenguaje Unificado de Modelado (UML) Se trata de un estándar que se ha adoptado a nivel internacional por numerosos organismos y empresas para crear esquemas, diagramas y documentación relativa a los desarrollos de software (programas informáticos).
  4. 4. El término “lenguaje” ha generado bastante confusión respecto a lo que es UML. En realidad el término lenguaje quizás no es el más apropiado, ya que no es un lenguaje propiamente dicho, sino una serie de normas y estándares gráficos respecto a cómo se deben representar los esquemas relativos al software. Mucha gente piensa por confusión que UML es un lenguaje de programación y esta idea es errónea: UML no es un lenguaje de programación. Como decimos, UML son una serie de normas y estándares que dicen cómo se debe representar algo. UML es una herramienta propia de personas que tienen conocimientos relativamente avanzados de programación y es frecuentemente usada por analistas funcionales (aquellos que definen qué debe hacer un programa sin entrar a escribir el código) y analistas-programadores (aquellos que dado un problema, lo estudian y escriben el código informático para resolverlo en un lenguaje como Java, C#, Python o cualquier otro). Por tanto si estás dando tus primeros pasos en programación, te recomendaríamos que te olvides de UML hasta que tengas unos conocimientos mínimos como uso de condicionales, bucles, y conocimiento de la programación orientada a objetos. Esto es solo una recomendación, en realidad prácticamente cualquier persona puede usar UML, incluso podría usarse para realizar esquemas o documentación de procesos que no tengan que ver con la informática. Hemos dicho que UML es un estándar. Vamos a aclarar primero qué es un estándar. Supongamos que vamos a definir un estándar llamado “LMAPR” o lenguaje de modelado de aprenderaprogramar.com. Ahora definimos dentro de nuestro estándar estas normas: Un animal debe representarse con su nombre escrito enteramente en minúsculas enmarcado dentro de un rectángulo doble. Encima del nombre debe etiquetarse el tipo de animal así: <<Tipo de Animal>>. Por ejemplo, <<Gato>>. Si un animal envía un mensaje a otro animal deben conectarse los dos animales con una línea 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 ratón y tráemelo aquí por favor”. Veamos formas de representar esto:
  5. 5. Esta es una forma de representación. Sin embargo, no se adapta al estándar que hemos definido por varios motivos: no indica <<Gato>> encima de los nombres de los animales, no escribe los nombres en minúsculas, no representa los animales con un rectángulo, etc. Veamos la representación que sí se adaptaría al estándar definido: ¿Cuáles son las versiones de UML? Los antecedentes de UML se sitúan en la década de los 90 con distintos estándares 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 estándar UML. En los años sucesivos fueron apareciendo nuevas versiones que introducían 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 versión de UML a la que podemos denominar UML 2.X. Comprenden varias revisiones.  UML 3.X: evolución que se espera para UML 2.X. Hay que tener en cuenta que UML es un conjunto muy amplio de normas. Prácticamente nadie las conoce todas. Según la empresa o universidad, institución o centro de trabajo se usan determinados programas para crear diagramas y se conocen ciertas partes de UML, pero no el conjunto de UML.
  6. 6. ¿Qué versión usar? Para generar diagramas UML se usan programas informáticos. Usa un programa actualizado pero no te preocupes en exceso por qué versión de UML usar, lo importante es que en tu grupo de trabajo o personas a las que se les vaya a enviar documentación sobre un proyecto software sepan interpretar lo que se les envía. A nivel profesional no se le presta demasiada atención a que se cumpla estrictamente con las normas de una determinada versión de UML, sino a que los esquemas estén bien construidos y razonados. 2.2. Metodología del Ciclo de Vida de un SistemadeJames Martín. Esta metodología de desarrollo de Software es mejor conocida como Metodología RAD (Rapid ApplicationDevelopment) o Desarrollo rápido de Aplicaciones, y fue creada por el gurú de computación James Martin en 1991. Está orientada a disminuir radicalmente el tiempo necesario para diseñar e implementar Sistemas de Información, el RAD cuenta con una participación intensa del usuario, sesiones JAD, prototipaje, herramientas CSE integradas y generadores de código. El Rad requiere cuatro ingredientes esenciales: gerencia, gente, metodologías y herramientas. 1) Etapa de Planificación de Requisitos: Esta etapa requiere que los usuarios con un vasto conocimiento de los procesos de la compañía determinen cuáles serán las funciones del sistema. Debe darse una discusión estructurada sobre los problemas de la compañía que necesitan solución. 2) Etapa de Diseño: Esta consiste de un análisis detallado de las actividades de la compañía en relación al sistema propuesto. Los usuarios participan activamente en talleres bajo la tutela de los profesionales de la informática. En ellos descomponen funciones y definen entidades asociadas con el sistema. Una vez se completa el análisis se crean los diagramas que definen las alteraciones entre los procesos y la data. 3) Construcción: En la etapa de construcción el equipo de desarrolladores trabajando de cerca con los usuarios finalizan el diseño y la construcción del sistema. La construcción de la aplicación consiste de una serie de pasos donde los usuarios tienen la oportunidad de afirmar los requisitos y repasar los resultados. 4) Implementación: Esta etapa envuelve la implementación del nuevo producto y el manejo de cambio del viejo al nuevo sistema. Se hacen pruebas comprensivas y se adiestran los usuarios.
  7. 7. 2.3 Metodología del Proceso Unificado de Desarrollo de Software El Proceso Unificado de Desarrollo Software o simplemente Proceso Unificado es un marco de desarrollo de software que se caracteriza por estar dirigido por casos de uso, centrado en la arquitectura y por ser iterativo e incremental. El refinamiento más conocido y documentado del Proceso Unificado es el Proceso Unificado de Rational o simplemente RUP. El Proceso Unificado no es simplemente un proceso, sino un marco de trabajo extensible que puede ser adaptado a organizaciones o proyectos específicos. De la misma forma, el Proceso Unificado de Rational, también 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 nombre Proceso Unificado se usa para describir el proceso genérico que incluye aquellos elementos que son comunes a la mayoría de los refinamientos existentes. También permite evitar problemas legales ya que Proceso Unificado de Rational o RUP son marcas registradas por IBM (desde su compra de Rational Software Corporation en 2003). El primer libro sobre el tema se denominó, en su versión española, El Proceso Unificado de Desarrollo de Software (ISBN 84-7829-036-2) y fue publicado en 1999 por Ivar Jacobson, Grady Booch y James Rumbaugh, conocidos también por ser los desarrolladores del UML, el Lenguaje Unificado de Modelado. Desde entonces los autores que publican libros sobre el tema y que no están afiliados a Rational utilizan el término Proceso Unificado, mientras que los autores que pertenecen a Rational favorecen el nombre de Proceso Unificado de Rational. ¿Por qué Analizar y Diseñar? En resumidas cuentas, la cuestión fundamental del desarrollo del software es la escritura del código. Después de todo, los diagramas son solo imágenes bonitas. Ningún usuario va a agradecer la belleza de los dibujos; lo que el usuario quiere es software que funcione (UML Gota a Gota, Addison Wesley, pág. 7). Por lo tanto, cuando considere usar el UML es importante preguntarse por qué lo hará y cómo le ayudará a usted cuando llegue el momento de escribir el código. No existe una evidencia empírica adecuada que demuestre si estas técnicas son buenas o malas;
  8. 8. 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 elaboración como a la resolución de problemas. 1. Inicio En la fase de inicio se define el negocio: facilidad de realizar el proyecto, se presenta un modelo, visión, metas, deseos del usuario, plazos, costos y viabilidad. 2. Elaboración En esta fase se obtiene la visión refinada del proyecto a realizar, la implementación iterativa del núcleo de la aplicación, la resolución de riesgos altos, nuevos requisitos y se ajustan las estimaciones. 3. Construcción Esta abarca la evolución hasta convertirse en producto listo incluyendo requisitos mínimos. Aquí se afinan los detalles menores como los diferentes tipos de casos o los riesgos menores. 4. Transición En esta fase final, el programa debe estar listo para ser probado, instalado y utilizado por el cliente sin ningún problema. Una vez finalizada esta fase, se debe comenzar a pensar en futuras novedades para la misma. Desde el punto de vista Técnico: el proyecto está formado por los flujos de trabajo fundamentales: captura de requerimientos, análisis, diseño, implementación y pruebas. Tantos el punto de vista Gerencial como el Técnico concuerdan en: La iteración. 2.4 Metodología de Kendall y Kendall. “El ciclo de vida de vida del desarrollo de sistemas es un enfoque por fases para el análisis y el diseño cuya premisa principal consiste en que los sistemas se desarrollan mejor utilizando un ciclo especifico de actividades del analista y el usuario.” (Kendall & Kendall) Según la metodología de Kendall & Kendall el ciclo de vida de un sistema consta de siete partes: siendo la primera la identificación del problema, la segunda identificación de requisitos de información, la tercera es el análisis de las necesidades del sistema, la cuarta es el diseño del sistema recomendado, la quinta desarrollo y documentación del sistema, la sexta prueba y mantenimiento y la última implementación y evaluación. Cada fase se explica por separado pero nunca se realizan
  9. 9. como pasos aislados, más bien es posible que algunas actividades se realicen de manera simultánea, y algunas de ellas podrían repetirse. FASE I: Identificación de problemas, oportunidades y objetivos.  Observación directa del entorno.  Aplicación de entrevista para recolectar información.  Sintetizar la información 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 organización, detallarlos, examinar, evaluar las oportunidades y objetivos. El analista debe identificar y evaluar los problemas existentes en la organización de manera crítica y precisa. Mayormente los problemas son detectados por alguien más 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 información computarizados, lo cual le da mayor seguridad y eficacia a las organizaciones además 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 información pueden contribuir a que el negocio alcance sus objetivos aplicándolas a problemas u oportunidades específicos. 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 definición del problema y un resumen de los objetivos. La administración debe decidir si se sigue adelante o si se cancela el proyecto propuesto. FASE II: Determinación de los requerimientos de información.  Revisión de los objetivos.  Identificar el dominio.  Investigar la razón por la cual se implementa el sistema actual.
  10. 10.  Recolectar información sobre los procedimientos y operaciones que se desempeñan actualmente.  Detallar específicamente: Quiénes son los involucrados, cuál es la actividad, regla y restricciones del negocio, entorno de desarrollo de las actividades, momentos oportunos de desarrollo de cada función, la manera en que se desempeñan 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 información. En esta fase el analista se esfuerza por comprender la información que necesitan los usuarios para llevar a cabo sus actividades. Entre las herramientas que se utilizan para determinar los requerimientos de información de un negocio se encuentran métodos interactivos como las entrevistas, los muestreos, la investigación de datos impresos y la aplicación de cuestionarios; métodos que no interfieren con el usuario como la observación del comportamiento de los encargados de tomar las decisiones y sus entornos e oficina, al igual que métodos de amplio alcance como la elaboración de prototipos. Esta fase es útil para que el analista confirme la idea que tiene de la organización 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 quién (la gente involucrada), el qué (la actividad del negocio), el dónde (el entorno donde se desarrollan las actividades), el cuándo (el momento oportuno) y el cómo (la manera en que se realizan los procedimientos actuales) del negocio que se estudia. Al término de esta fase, el analista debe conocer el funcionamiento del negocio y poseer información muy completa acerca de la gente, los objetivos, los datos y los procedimientos implicados. FASE III: Análisis de las necesidades.  Evaluar las dos fases anteriores.  Modelar las entradas, los procesos y las salidas de las funciones ya identificadas.
  11. 11.  Elaborar diccionario de datos y sus especificaciones.  Elaborar diagramas de procesos de cada función.  Elaborar propuesta del sistema con todos los diagramas de operaciones y de procesos.  Realizar el análisis del riesgo sobre el realizado en las fases anteriores, tomando en cuenta el aspecto económico, técnico y operacional (estudio de factibilidad)  Estimar en un diagrama de Gantt el tiempo que tomará desarrollar el sistema. En esta fase el analista evalúa las dos fases anteriores, usa herramientas y técnicas 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 gráfica 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 análisis de costo/beneficio de las alternativas y ofrece, en su caso, recomendaciones sobre lo que se debe hacer. FASE IV: Diseño del sistema recomendado.  Evaluar las tres fases anteriores.  Realizar el diseño lógico de todo el sistema.  Elaborar procedimientos precisos para la captura de los datos que van a ingresar al sistema de información.  Elaborar el diseño de la base de datos.  Diseñar las diferentes interfaces de usuarios de cada operación, procedimiento y/o función.  Diseñar controles y procedimientos de respaldos que protejan al sistema y a los datos.  Producir los paquetes específicos de programas para los programadores.  Elaborar una lista de las funciones genéricas y de las que será obligatorio crear. En esta fase el analista utiliza la información recopilada en las primeras fases para realizar el diseño lógico del sistema de información. El analista diseña procedimientos precisos para la captura de datos que aseguran que los datos que ingresen al sistema de información sean correctos.
  12. 12. Facilita la entrada eficiente de datos al sistema de información mediantes técnicas adecuadas de diseño de formularios y pantallas. La concepción de la interfaz de usuario forma parte del diseño lógico del sistema de información. La interfaz conecta al usuario con el sistema y por tanto es sumamente importante. También incluye el diseño de archivos o bases de datos que almacenarán gran parte delos datos indispensables para los encargados de tomar las decisiones en la organización. En esta fase el analista interactúa con los usuarios para diseñar la salida (en pantalla o impresa) que satisfaga las necesidades de información de estos últimos. Finalmente el analista debe diseñar 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 documentación del software.  Evaluar los procedimientos que va a ser desarrollados por el programador.  Mostrar y explicar cada procedimiento, función y operación 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 interacción 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 técnicas estructuradas para diseñar y documentar software se encuentran los diagramas de estructuras, los diagramas de Nassi-Shneiderman y el pseudocódigo.
  13. 13. Durante esta fase el analista trabaja con los usuarios para desarrollar documentación efectiva para el software, como manuales de procedimientos, ayuda en línea y sitios web que incluyan respuestas a preguntas frecuentes en archivos “léame” que se integrarán al nuevo software. La documentación indica a los usuarios cómo utilizar el sistema y qué hacer en caso de que surjan problemas derivados de este uso. Los programadores desempeñan un rol clave en esta fase porque diseñan, codifican y eliminan errores sintácticos de los programas de cómputo. FASE VI: Prueba y mantenimiento del sistema.  Realizar la programación de las pruebas del sistema.  Realizar un instrumento para evaluar el sistema de información.  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 planificación de las horas del mantenimiento del sistema. Elaborar la lista de las operaciones que pudieran sufrir modificaciones de códigos. 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 precisión cuáles son los problemas y posteriormente se realiza otra con datos reales del sistema actual. El mantenimiento del sistema de información y su documentación empiezan en esta fase y se llevan de manera rutinaria durante toda su vida útil. FASE VII: Implementación y evaluación del sistema.  Planificar gradualmente la conversión 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.
  14. 14.  Evaluar la adaptabilidad de los usuarios al sistema. Esta es la última fase del desarrollo de sistemas, y aquí el analista participa en la implementación del sistema de información. En esta fase se capacita a los usuarios en el manejo del sistema. Parte de la capacitación la imparten los fabricantes, pero la supervisión de ésta es responsabilidad del analista de sistemas. Se menciona la evaluación como la fase final del ciclo de vida del desarrollo de sistemas principalmente en áreas del debate. En realidad, la evaluación se lleva a cabo durante cada una de las fases. El trabajo de sistemas es cíclico, cuando un analista termina una fase del desarrollo de sistemas y pasa a la siguiente, el surgimiento de un problema podría obligar a regresar a la fase previa y modificar el trabajo realizado. 2.5 Metodología de Administración de Relaciones (RMM). La Metodología de Gestión de Relaciones (Relationship Management Methodology, en adelante RMM) para el diseño hipermedia fue introducida por primera vez en 1995, y desde entonces ha evolucionado en muchos aspectos para dar respuesta al rápido incremento de la demanda de aplicaciones en la World Wide Web. La mejora de la metodología está demostrada por el diseño de complejas aplicaciones web. Trataremos cuestiones de Diseño e Implementación, incluyendo integración de bases de datos, así como las aproximaciones “top-down” (descendente) frente a “bottomup” (ascendente) para el desarrollo de aplicaciones WIS (Web InformationSystem). Presentamos también la notación gráfica y de lenguaje de programación para las nuevas construcciones (o “constructores") creadas para RMM. Esta metodología fomenta un diseño correcto y un desarrollo mantenible de la hipermedia. La RMM o Relationship Management Methodology se define como un proceso de análisis, diseño y desarrollo de aplicaciones hipermedia. Los elementos principales de este método son el modelo E-R (Entidad-Relación) y el modelo RMDM (Relationship Management Data Model) basado en el modelo HDM. La metodología fue creada por Isakowitz, Stohr y Balasubramanian. Esta metodología es apropiada para dominios con estructuras regulares (es decir, con clases de objetos bien definidas, y con claras relaciones entre esas clases). Por ejemplo, catálogos o "frentes" de bases de datos tradicionales. Según sus autores, está orientada a problemas con datos dinámicos que cambian con mucha frecuencia, más que a entornos estáticos.
  15. 15. El modelo propone un lenguaje que permite describir los objetos del dominio, sus interrelaciones y los mecanismos de navegación hipermedia de la aplicación. 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 presentación de las entidades. Un slice corresponde a un subconjunto de atributos de una misma entidad destinados a ser presentados de forma agrupada. La navegación se modeliza con la ayuda de primitivas de acceso, enlaces estructurales (unidireccional y bidireccional) que permiten especificar la navegación entre slices, y visita guiada condicional, índice condicional y agrupación, que permiten especificar la navegación entre entidades. El esquema completo del dominio y de la navegación de la aplicación se denomina esquema RMDM y se obtiene como resultado de las tres primeras etapas del método. Las etapas son: Primera Etapa: representar los objetos del dominio con la ayuda del modelo Entidad- Relación ampliado con relaciones asociativas (aquéllas que permiten representar caminos navegacionales entre entidades puestos en evidencia en la fase de análisis). Segunda Etapa: determinar la presentación del contenido de las entidades de la aplicación 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-Relación 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 navegación inducidos por las relaciones asociativas del esquema E-R+. A continuación, es posible definir estructuras de acceso de alto nivel (agrupaciones), lo que permite dotar a la aplicación de accesos jerárquicos a niveles diferentes de los trozos de información. El esquema RMDM resultante se obtiene añadiendo al esquema E-R+ las agrupaciones y caminos navegacionales definidos en esta etapa. Las cuatro etapas restantes consisten en:  Definición del protocolo de conversión de elementos del diagrama RMDM en objetos de la plataforma de desarrollo.  Concepción del interfaz usuario.  Concepción del comportamiento en ejecución.  Construcción del sistema y test. La metodología RMM permite hacer explícita la navegación al hacer el análisis, lo que permite, teóricamente, obtener una navegación más estructurada e intuitiva, y lo hace de una forma muy sencilla, como es añadir unas primitivas a un modelo entidad-
  16. 16. relación tradicional. El concepto de slice es muy útil, ya que permite agrupar datos de una entidad en diferentes pantallas. Se utilizaría, por ejemplo, para mostrar dos vídeos en dos pantallas diferentes sobre un mismo fenómeno. También es interesante la primitiva de grupo, que permite mostrar la jerarquía de menús. RMM representa el primer caso en el que se crea una metodología completa definiendo las distintas fases y no únicamente un modelo de datos. Además, se basa en un modelo de datos relacional, ajustándose así a la gran mayoría de las aplicaciones existentes. Sin embargo, los mecanismos de acceso a la información son excesivamente simples y valen para un problema con pocas entidades, pero el modelo se queda corto si hay gran número de ellas. 2.6 Metodología Orientada a Objetos. La metodología orientada a objetos ha derivado de las metodologías anteriores a éste. Así como los métodos de diseño estructurado realizados guían a los desarrolladores que tratan de construir sistemas complejos utilizando algoritmos como sus bloques fundamentales de construcción, similarmente los métodos de diseño orientado a objetos han evolucionado para ayudar a los desarrolladores a explotar el poder de los lenguajes de programación basados en objetos y orientados a objetos, utilizando las clases y objetos como bloques de construcción básicos. Actualmente el modelo de objetos ha sido influencia por un numero de factores no solo de programación orientada a objetos (ObjectOrientedProgramming, OOP por sus siglas en inglés). Además, el modelo de objetos ha probado ser un concepto uniforme en las ciencias de la computación, aplicable no sólo a los lenguajes de programación sino también al diseño de interfaces de usuario, bases de datos y arquitectura de computadoras por completo. La razón de ello es, simplemente, que una orientación 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 métodos 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 relación con otros objetos de manera apropiada a este objeto. Actualmente, el Análisis Orientado a Objetos (AOO) va progresando como método de análisis de requisitos por derecho propio y como complemento de otros métodos de análisis. En lugar de examinar un problema mediante el modelo clásico de entrada- proceso-salida (flujo de información) o mediante un modelo derivado exclusivamente de estructuras jerárquicas de información, el AOO introduce varios conceptos nuevos.
  17. 17. Estos conceptos nuevos le parecen inusuales a mucha gente, pero son bastante naturales. Una clase es una plantilla para objetos múltiples con características similares. Las clases comprenden todas esas características 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. Una instancia de una clase es otro término para un objeto real. Si la clase es la representación general de un objeto, una instancia es su representación 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) y métodos (comportamiento o conducta). Los atributos son las características 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 información sobre su estado. Los métodos 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 métodos se encuentran en la parte externa del objeto Para definir el comportamiento de un objeto, se crean métodos, los cuales tienen una apariencia y un comportamiento igual al de las funciones en otros lenguajes de programación, los lenguajes estructurados, pero se definen dentro de una clase. Los métodos no siempre afectan a un solo objeto; los objetos también se comunican entre sí mediante el uso de métodos. Una clase u objeto puede llamar métodos 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. Además, como se puede observar de los diagramas, las variables del objeto se localizan en el centro o núcleo del objeto. Los métodos rodean y esconden el núcleo del objeto de otros objetos en el programa. Al empaquetamiento de las variables de un objeto con la protección de sus métodos se le llama encapsulamiento. Típicamente, el encapsulamiento es utilizado para esconder detalles de la puesta en práctica no importantes de otros objetos. Entonces, los detalles de la puesta en práctica pueden cambiar en cualquier tiempo sin afectar otras partes del programa. Esta imagen conceptual de un objeto —un núcleo de variables empaquetadas en una membrana protectora de métodos— es una representación ideal de un objeto y es el ideal por el que los diseñadores de sistemas orientados a objetos luchan. Sin embargo, no lo es todo: a menudo, por razones de eficiencia o la puesta en práctica, un objeto puede querer exponer algunas de sus variables o esconder algunos de sus métodos.
  18. 18. El encapsulamiento de variables y métodos en un componente de software ordenado es, todavía, una simple idea poderosa que provee dos principales beneficios a los desarrolladores de software:  Modularidad, esto es, el código fuente de un objeto puede ser escrito, así como darle mantenimiento, independientemente del código fuente de otros objetos. Así mismo, un objeto puede ser transferido alrededor del sistema sin alterar su estado y conducta.  Ocultamiento de la información, es decir, un objeto tiene una "interfaz publica" que otros objetos pueden utilizar para comunicarse con él. Pero el objeto puede mantener información y métodos 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 información. Las clases proveen el beneficio de la reutilización. Los programadores de software utilizan la misma clase, y por lo tanto el mismo código, 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 métodos 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 demás objetos. Los métodos, por su parte, pertenecen a la clase y no se almacenan en cada objeto, puesto que sería un desperdicio almacenar el mismo procedimiento varias veces y ello va contra el principio de reutilización de código. Otro concepto muy importante en la metodología orientada a objetos es el de herencia. La herencia es un mecanismo poderoso con el cual se puede definir una clase en términos de otra clase; lo que significa que cuando se escribe una clase, sólo se tiene que especificar la diferencia de esa clase con otra, con lo cual, la herencia dará acceso automático a la información contenida en esa otra clase. Con la herencia, todas las clases están arregladas dentro de una jerarquía estricta. Cada clase tiene una superclase (la clase superior en la jerarquía) y puede tener una o más subclases (las clases que se encuentran debajo de esa clase en la jerarquía). Se dice que las clases inferiores en la jerarquía, las clases hijas, heredan de las clases más altas, las clases padres. Las subclases heredan todos los métodos 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 código de la clase padre De esta manera, se puede pensar en una jerarquía de clase como la definición de conceptos demasiado abstractos en lo alto de la jerarquía y esas ideas se convierten en algo más concreto conforme se desciende por la cadena de la superclase.
  19. 19. Sin embargo, las clases hijas no están limitadas al estado y conducta provistos por sus superclases; pueden agregar variables y métodos además de los que ya heredan de sus clases padres. Las clases hijas pueden, también, sobre escribir los métodos que heredan por implementaciones especializadas para esos métodos. De igual manera, no hay limitación a un sólo nivel de herencia por lo que se tiene un árbol de herencia en el que se puede heredar varios niveles hacia abajo y mientras más niveles descienda una clase, más 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 través del uso de herencia, los programadores pueden reutilizar el código de la superclase muchas veces.  Los programadores pueden implementar superclases llamadas clases abstractas que definen conductas "genéricas". Las superclases abstractas definen, y pueden implementar parcialmente, la conducta pero gran parte de la clase no está definida ni implementada. Otros programadores concluirán esos detalles con subclases especializadas. 2.7. Metodología del Software Educativo por Álvaro Galvis (ISE). Es una metodología de desarrollo de software que contempla una serie de fases o etapas de un proceso sistemático atendiendo a: análisis, diseño, desarrollo, prueba y ajuste, y por último implementación. Etapas: Etapa 1: Análisis Características de la población objetivo: edad (física y mental), sexo, características físicas 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, físico o psicológico, entorno familiar y escolar, etc. Problema o necesidad a atender: Para establecer la necesidad se puede recurrir a los mecanismos de análisis de necesidades educativas en. Estos mecanismos usan entrevistas, análisis de resultados académicos, 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, económicas, sociales, normativas, etc.
  20. 20. Principios pedagógicos y didácticos aplicables: se debe analizar cómo se ha llevado a cabo el proceso de enseñanza-aprendizaje para establecer cómo debe enfocarse el ambiente, qué factores tomar en cuenta, qué objetivos debe cumplir. Justificación de uso de los medios interactivos: Para cada problema o necesidad encontrada se debe establecer una estrategia de solución contemplando diferentes posibilidades. El apoyo informático 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 académicas, cambios en metodologías de clase; mejoras a los medios y materiales de enseñanza contemplando el uso de medios informáticos. Una vez que se han analizado todas las alternativas se puede decir por qué el uso de medios informáticos es una buena solución. La justificación se puede basar en la no existencia de otro medio mejor y en la relación costo-beneficio para la institución pues puede ser que exista una mejor solución pero que demande mayor tiempo y esfuerzo o un mayor costo económico, etc. Diagramas de interacción: Permiten ver secuencias de interacción entre el usuario y la aplicación, representando lo que se espera del diálogo y dando más detalle a la descripción textual de la descripción de la aplicación. Los diagramas de interacción son un formalismo que permite ver la secuencia de acciones entre diferentes partes de la aplicación involucrada en llevar a cabo determinada actividad. Es importante ver la secuencia de acciones para cada escenario de interacción. Con base en estos diagramas se pueden ver cuáles pueden ser las necesidades de información en cada escenario de interacción y se puede ir pensando en cuáles pueden ser los algoritmos que serán usados. Etapa 2: Diseño 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 interacción entre usuario y máquina, 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).
  21. 21. Etapa 3: Desarrollo En esta fase se implementa la aplicación usando la información obtenida anteriormente. Tomando en cuenta las restricciones que se tengan. Etapa 4: Prueba Piloto En esta etapa se pretende ayudar a la depuración del Sistema Educativo a partir de su utilización por una muestra representativa de los tipos de destinatarios para los que se hizo y la consiguiente evaluación formativa. Es imprescindible realizar ciertas validaciones (efectuadas por expertos) de los prototipos durante las etapas de diseño y prueba en uno a uno de los módulos desarrollados, a medida que estos están funcionales. Etapa 5: Prueba de Campo La prueba de campo de un Sistema Educativo es mucho más que usarlo con toda la población 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 parecía tener sentido, lo sigue teniendo, es decir, si efectivamente la aplicación satisface las necesidades y cumple la funcionalidad requerida. 2.8. Metodología de Sistemas Blandos (SSM) de Peter Checkland. La SSM de Peter Checkland es una metodología sistémica fundamentada en el concepto de perspectiva o en el lenguaje de la metodología “Weltanschauung”. Un “weltanschauung” representa la visión propia de un observador, o grupo de ellos, sobre un objeto de estudio, visión é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 idealización de estos “weltanschauung” para proponer cambios sobre el sistema que en teoría deberían tender a mejorar su funcionamiento. En este punto es conveniente aclarar la noción de “weltanschauung”, para ello se puede considerar como ejemplo, las diferencias que entre un observador y otro presenta el propósito 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
  22. 22. donde tomar experiencia en la diatriba política, 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 enseñanza donde acuden a laborar impartiendo conocimientos entre sus estudiantes, para otros son centros de docencia e investigación donde, a través del desarrollo de la investigación, nutren su actividad de docencia, siempre con la intención 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 enseñanza aprendizaje, etc. Como se puede ver, en ambos casos, estudiantes y profesores, la visión 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 erróneos, ni unos son mejores que otros, todos son igualmente válidos e incluso complementarios. Otro concepto importante para la SSM es el de sistema blando, según Checkland, un sistema blando es aquel que está conformado por actividades humanas, tiene un fin perdurable en el tiempo y presenta problemáticas in-estructuradas o blandas; es decir aquellas problemáticas de difícil definición y carentes de estructura, en las que los fines, metas, propósitos, son problemáticos en sí. La SSM está conformada por siete (7) estadios cuyo orden puede variar de acuerdo a las características del estudio, a continuación se describen brevemente estos estadios. Estadio 1: La Situación Problema no Estructurada: en este estadio se pretende lograr una descripción de la situación donde se percibe la existencia de un problema, sin hacer hincapié en el problema en sí, esto es sin dar ningún tipo de estructura a la situación. Estadio 2: La Situación Problema Expresada: se da forma a la situación describiendo su estructura organizativa, actividades e interrelación de éstas, flujos de entrada y salida, etc. Estadio 3: Definiciones Raíz de Sistemas Pertinentes: se elaboran definiciones de lo que, idealmente, según los diferentes “weltanschauung” involucrados, es el sistema. La construcción de estas definiciones se fundamenta en seis factores que deben aparecer
  23. 23. explícitos en todas ellas, estos se agrupan bajo el nemónico de sus siglas en ingles CATWOE (Bergvall-Kåreborn et. al. 2004), a saber: consumidores, actores, proceso de transformación, weltanschauung, poseedor y restricción del ambiente. Estadio 4: Confección y Verificación de Modelos Conceptuales: partiendo de los verbos de acción presentes en las definiciones raíz, se elaboran modelos conceptuales que representen, idealmente, las actividades que, según la definición raíz en cuestión, se deban realizar en el sistema (Ramírez 1983). Existirán tantos modelos conceptuales como definiciones raíz……………………………………………………………………. 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 sistémico que, dadas las particularidades del problema, pueda ser conveniente. Estadio 5: Comparación de los modelos conceptuales con la realidad: se comparan los modelos conceptuales con la situación actual del sistema expresada, dicha comparación 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: Diseño de Cambios Deseables, Viables: de las diferencias emergidas entre la situación 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.
  24. 24. Estadio 7: Acciones para Mejorar la Situación Problema: finalmente este estadio comprende la puesta en marcha de los cambios diseñados, tendientes a solucionar la situación problema, y el control de los mismos. Este estadio no representa el fin de la aplicación de la metodología, pues en su aplicación se transforma en un ciclo de continua conceptualización y habilitación de cambios, siempre tendiendo a mejorar la situación. 2.9. Metodología MERINDE. La Metodología MeRinde surge de la combinación y adaptación de modelos y metodologías ampliamente utilizadas para el desarrollo de software y la reingeniería de procesos del negocio. Esta metodología está fuertemente fundamentada en los requerimientos del Centro Nacional de Tecnología de Información (CNTI) y en varias metodologías 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 documentación 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 máximos y deberá adaptarse y dimensionarse en cada momento de acuerdo a las características particulares de cada proyecto. Dada la adaptabilidad que puede sufrir la metodología, esta puede llegarse a aplicar bajo un enfoque ágil, lo cual no se detalla en la presente versión, pero no se descarta su empleo. Así mismo, esta permite producir y mantener una librería de plantillas reutilizables para ingeniería de software. Está basada en componentes, lo cual quiere decir que el sistema software en construcción está formado por componentes software interconectados a través de interfaces bien definidas. Además, la metodología 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 metodología 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 códigos de los sistemas sino que también se compartan la documentación como guía de referencia para mejoras por terceros al sistema o para que sirva como modelo a otras comunidades para el desarrollo de sus propios sistemas.
  25. 25. 2.10. Metodología 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 planificación y ejecución completa del producto. Basar la calidad del resultado más en el conocimiento tácito 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 reacción ante los cambiantes requerimientos generados por las necesidades del cliente o la evolución del mercado. El marco de trabajo está diseñado para adecuarse a las nuevas exigencias que implican proyectos complejos.  Reducción del Time to Market. El cliente puede empezar a utilizar las características más importantes del proyecto antes de que esté completamente terminado.  Mayor calidad del software. El trabajo metódico y la necesidad de obtener una versión de trabajo funcional después de cada iteración, ayuda a la obtención de un software de alta calidad.  Mayor productividad. Se logra, entre otras razones, debido a la eliminación de la burocracia y la motivación del equipo proporcionado por el hecho de que pueden estructurarse de manera autónoma.  Maximiza el retorno de la inversión (ROI). Creación de software solamente con las prestaciones que contribuyen a un mayor valor de negocio gracias a la priorización por retorno de inversión.  Predicciones de tiempos. A través de este marco de trabajo se conoce la velocidad media del equipo por sprint, con lo que es posible estimar de manera fácil cuando se podrá hacer uso de una determinada funcionalidad que todavía está en el Backlog.  Reducción de riesgos El 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.
  26. 26. Conclusión 1. Para generar diagramas UML se usan programas informáticos. Usa un programa actualizado pero no te preocupes en exceso por qué versión de UML usar, lo importante es que en tu grupo de trabajo o personas a las que se les vaya a enviar documentación sobre un proyecto software sepan interpretar lo que se les envía. A nivel profesional no se le presta demasiada atención a que se cumpla estrictamente con las normas de una determinada versión de UML, sino a que los esquemas estén bien construidos y razonados. 2. El analista necesita conocer los detalles de las funciones del sistema actual: El quién (la gente involucrada), el qué (la actividad del negocio), el dónde (el entorno donde se desarrollan las actividades), el cuándo (el momento oportuno) y el cómo (la manera en que se realizan los procedimientos actuales) del negocio que se estudia. 3. La Metodología MeRinde surge de la combinación y adaptación de modelos y metodologías ampliamente utilizadas para el desarrollo de software y la reingeniería de procesos del negocio. Esta metodología está fuertemente fundamentada en los requerimientos del Centro Nacional de Tecnología de Información (CNTI) y en varias metodologías como el Proceso Unificado (UP) especialmente. 4. “El ciclo de vida de vida del desarrollo de sistemas es un enfoque por fases para el análisis y el diseño 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 diseña procedimientos precisos para la captura de datos que aseguran que los datos que ingresen al sistema de información sean correctos.
  27. 27. Bibliografía http://www.significados.com/metodo/ http://www.significados.com/metodologia/ http://aprenderaprogramar.com/index.php?option=com_content&view=article&id=688:i que-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.html https://es.wikipedia.org/wiki/Scrum http://www.merinde.net/ http://mundoinformatico321.blogspot.com/2012/12/metodologia-del-software- educativo-por.html

×