TRabajo

1. Análisis y Diseño de
Sistemas
Autor:
Juan Manuel Velásquez Canache
C.I: 23.770.791

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. 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. 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. 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. ¿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. 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. 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. 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.  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.  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. 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. 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.  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. 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. 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. 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. 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. 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. 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. 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. 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. 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. 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. 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. 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. 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