Trabajo

1. Metodo:
Método es una palabra que proviene del término griego methodos (“camino” o “vía”) y
que se refiere al medio utilizado para llegar a un fin. Su significado original señala el camino
que conduce a un lugar.
La palabra método puede referirse a diversos conceptos. Por ejemplo, a los métodos
de clasificación científica. Esta es la disciplina que permite a los biólogos agrupar y separar
en categorías a los diversos organismos y conjuntos.
El método científico, por su parte, es la serie de pasos que sigue una ciencia para
obtener saberes válidos (es decir, que pueden verificarse a través de un instrumento fiable).
Gracias al respeto por un método científico, un investigador logra apartar su subjetividad y
obtiene resultados más cercanos a la objetividad o a lo empírico.
Metodologia:
La metodología (del griego μέθοδος de μετά metá 'más allá, después, con', οδως odós
'camino' y λογος logos 'razón, estudio'),1
hace referencia al conjunto de procedimientos
racionales utilizados para alcanzar una gama de objetivos que rigen una investigación
científica, una exposición doctrinal2
o tareas que requieran habilidades, conocimientos o
cuidados específicos. Alternativamente puede definirse la metodología como el estudio o
elección de un método pertinente para un determinado objetivo.3
No debe llamarse metodología a cualquier procedimiento, ya que es un concepto que
en la gran mayoría de los casos resulta demasiado amplio, siendo preferible usar el vocablo
método.
Lenguaje Unificado de Modelado
Lenguaje Unificado de Modelado (LUM o UML, por sus siglas en inglés, Unified
Modeling Language) es el lenguaje de modelado de sistemas de software más conocido y
utilizado en la actualidad; está respaldado por el OMG (Object Management Group). Es un
lenguaje gráfico para visualizar, especificar, construir y documentar un sistema. UML ofrece
un estándar para describir un "plano" del sistema (modelo), incluyendo aspectos conceptuales
tales como procesos de negocio, funciones del sistema, y aspectos concretos como
expresiones de lenguajes de programación, esquemas de bases de datos y compuestos
reciclados.
Es importante remarcar que UML es un "lenguaje de modelado" para especificar o
para describir métodos o procesos. Se utiliza para definir un sistema, para detallar los
artefactos en el sistema y para documentar y construir. En otras palabras, es el lenguaje en
el que está descrito el modelo.
Se puede aplicar en el desarrollo de software gran variedad de formas para dar
soporte a una metodología de desarrollo de software (tal como el Proceso Unificado Racional
o RUP), pero no específica en sí mismo qué metodología o proceso usar.

2. Metodología del Ciclo de Vida de un Sistema de James Martín
Esta metodología de desarrollo de Software es mejor conocida como Metodología
RAD (Rapid Application Development) 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

3. 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.
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
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.
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.
Elaboración
En esta fase se obtiene la visión refinada del proyecto a realizar, la implementación
iterativa del núcleo del de la aplicación, la resolución de riesgos altos, nuevos requisitos y se
ajustan las estimaciones.
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.
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.

4. 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.
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 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.

5. 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.
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.
Elaborar diccionario de datos y sus especificaciones.
Elaborar diagramas de procesos de cada función.

6. 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.
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.

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

8. 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.
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.
Metodología de Administración de Relaciones
.
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.
El modelo propone un lenguaje que permite describirlos 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)

9. 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
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 influenciado por un número de factores no
sólo de la Programación Orientada a Objetos, POO (Object Oriented Programming, 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".

10. 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. 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.
Metodología del software educativo por Álvaro Galvis
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.

11. 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).
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.

12. 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.
Metodología de Sistemas Blandos
La Metodología de sistemas blandos (SSM por sus siglas en inglés) de Peter
Checkland es una técnicacualitativa que se puede utilizar para aplicar los sistemas
estructurados a las situaciones asistémicas. Esuna manera de ocuparse de problemas
situacionales en los cuales hay una actividad con unaltocomponente social, político y humano.
Esto distingue el SSM de otras metodologías que se ocupan de losproblemas DUROS que
están a menudo más orientados a la tecnología.El SSM aplica los sistemas estructurados al
mundoactual de las organizaciones humanas.Pero crucialmente sinasumir que el tema de la
investigación es en sí mismo es un sistema simple. El SSMpor lo tanto es una manera útil de
acercarse a situaciones complejas y a las preguntas desordenadas correspondientes.
Metodología MERINDE
Metodología de la Red Nacional de Integración y Desarrollo de Software Libre
(MeRinde) Una Propuesta Metodológica para Elaborar Software Libre con el Uso de
Estándares Abiertos y con un Enfoque de Calidad.
Es un proyecto de Software Libre (SL) que propone un estándar para el proceso de
desarrollo de software que puede ser empleado y adaptado según los requerimientos de
cualquier comunidad u organización, con la finalidad del desarrollo de sistemas y además
para producir y mantener una librería de plantillas reutilizables para la ingeniería de software.
Estas plantillas proveen un punto partida para los documentos utilizados en proyectos de
desarrollo de software, con lo que pueden ayudar a los desarrolladores a trabajar más rápido
y evitar pasar por alto aspectos importantes del proceso de desarrollo.
Este proyecto pretende entre sus principales objetivos apoyar a las comunidades de
desarrollo de SL en sus proyectos, suministrando las herramientas necesarias para que estos
cumplan con un proceso de desarrollo y documentación de sus sistemas. Se aclara que el
proceso propuesto y las plantillas no son universales y no intentan proveer guías prescriptivas
en el proceso general de desarrollo de sistemas.
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.

13. Metodología SCRUM
Scrum es un modelo de desarrollo ágil caracterizado 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 autoorganizados, 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.