Contenido

1. Metodología SCRUM ........................................................................................ 1

2. Metodología MeRinde ....................................................................................... 1
2.1. Fase de inicio: ............................................................................................ 1
2.2. Fase de Elaboración: ................................................................................. 1
2.3. Fase de Construcción: ............................................................................... 2
2.4. Fase de Transición: .................................................................................... 2
3. Lenguaje Unificado de Modelado (UML)........................................................... 2
4. Metodología de Jeffrey Whitten. ....................................................................... 3
5. Metodología del Proceso Unificado de Desarrollo de Software ........................ 4
6. Metodología del Ciclo de Vida de un Sistema de James Martín ....................... 5
1.1. Fases o Etapas de Metodología RAD de James Martin. ............................ 5
7. Metodología de Kendall y Kendall. ................................................................... 5
7.1. Identificación de problemas, oportunidades y objetivos: ............................ 5
7.2. Determinación de los requerimientos de información: ............................... 6
7.3. Análisis de las necesidades del sistema: ................................................... 6
7.4. Diseño del sistema recomendado: ............................................................. 6
8. Metodología de Administración de Relaciones (RMM). .................................... 7
9. Metodología de Sistemas Blandos (SSM) de Peter Checkland. ....................... 8
Estadio 1: La Situación Problema no Estructurada: ............................................. 8
Estadio 2: La Situación Problema Expresada: ..................................................... 8
Estadio 3: Definiciones Raíz de Sistemas Pertinentes: ....................................... 8
Estadio 4: Confección y Verificación de Modelos Conceptuales: ........................ 8
Estadio 5: Comparación de los modelos conceptuales con la realidad: .............. 9
Estadio 6: Diseño de Cambios Deseables, Viables: ............................................ 9
Estadio 7: Acciones para Mejorar la Situación Problema .................................... 9
10. Metodología Orientada a Objetos .................................................................. 9
11. Metodología de Sistemas Expertos por David Rolston. ............................... 10
12. Metodología del Software Educativo por Álvaro Galvis (ISE). ..................... 10
Etapa 1: Análisis ................................................................................................ 10
Etapa 2: Diseño ................................................................................................. 10
Etapa 3: Desarrollo ............................................................................................ 11
Etapa 4: Prueba Piloto ....................................................................................... 11
Etapa 5: Prueba de Campo: .............................................................................. 11
1. Metodología SCRUM
Scrum es una metodología ágil y flexible para gestionar el desarrollo de software, cuyo
principal objetivo es maximizar el retorno de la inversión para su empresa (ROI). Se basa en
construir primero la funcionalidad de mayor valor para el cliente y en los principios de
inspección continua, adaptación, auto-gestión e innovación.

Con la metodología Scrum el cliente se entusiasma y se compromete con el proyecto dado

que lo ve crecer iteración a iteración. Asimismo le permite en cualquier momento realinear
el software con los objetivos de negocio de su empresa, ya que puede introducir cambios
funcionales o de prioridad en el inicio de cada nueva iteración sin ningún problema.

Esta metódica de trabajo promueve la innovación, motivación y compromiso del equipo que
forma parte del proyecto, por lo que los profesionales encuentran un ámbito propicio para
desarrollar sus capacidades.

2. Metodología MeRinde
Es un proyecto que propone un estándar abierto para el proceso de desarrollo de software
orientado a planes que se estructura en dos dimensiones o ejes.

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.

2.1. Fase de inicio: En esta fase se plantea la visión que tiene el equipo o desarrollador
en cuanto a lo que será el sistema, se fijan los propósitos o fines principales para el
ciclo de vida del producto. Durante la fase de inicio se establece el mecanismo por el
cual el producto le proveerá beneficios al usuario final o bien sea al cliente. Se
describen todos los actores y casos de usos del producto y además se debe crear o
implementar un plan de negocio para definir los recursos que se asignaran al proyecto.
Para finalizar esta fase se debe haber tomado en cuenta los costos en recursos, el
tiempo total del proyecto, los riesgos e incertidumbres que pueda generar, además
de su viabilidad.

2.2. Fase de Elaboración: El propósito específico que tiene la fase de elaboración es

proyectar la manera en que se va a realizar la arquitectura para el ciclo de vida del
producto, es decir, para su evolución durante su uso o bien sea su permanencia en
cuanto a funcionamiento, se elabora una arquitectura en diversas interacciones hasta
lograr el producto deseado. Esta fase debe seguir el patrón de todos los casos de uso
planteados en la fase de inicio.

1
 Además se deben considerar la mayoría de las exigencias funcionales, tomando en
cuenta los riesgos que puedan afectar los fines del sistema para que de esta manera
pueda hacerse realizable el producto en cuestión.

La fase de elaboración concluye cuando el equipo del proyecto tiene en claro los
riesgos principales que puedan afectar al producto, de manera de saber cuáles son los
requerimientos en cuanto a la realización de este, además de la evolución que este
tendrá.

2.3. Fase de Construcción: Una vez que el equipo este en esta fase deben tener como
meta o finalidad lograr la disposición o capacidad operativa del producto,
considerando que en dicho producto deben de estar incluidas todas las propiedades,
elementos, requisitos y/o exigencias, las cuales previamente deben haber sido
evaluadas y probadas totalmente, obteniendo de esta manera una versión del
producto que sea aprobada o admisible para quien vaya a hacer uso de esta.

En conclusión, el objetivo de esta fase es el desarrollo total del sistema ya preparado

para la fase de transición, debe haber sido probada toda su funcionalidad y aplicación
de manera de evitar que sea pospuesta la fase de transición por incumplimiento de
los criterios de esta fase.

2.4. Fase de Transición: Ya en esta fase, el producto debe de estar en manos de los
usuarios finales en su forma funcional, luego de que haya sido probado y aceptado en
su totalidad por dichos usuarios, además se deberá doctrinar a los usuarios en cuanto
al empleo o manipulación del sistema, y principalmente en lo que se refiere a la
configuración usabilidad e instalación del producto. Es decir, se debe avalar o
confirmar que el usuario aprenda a operar el producto final, el cual debe cumplir con
todos los requerimientos establecidos en el proceso de realización del mismo.

En resumen, en esta fase se debe determinar si todos los propósitos en cuanto al

proyecto fueron logrados, además se debe confirmar que el cliente haya aceptado,
observado y verificado el producto final que le fue proporcionado.

3. Lenguaje Unificado de Modelado (UML)

Es un lenguaje para hacer modelos y es independiente de los métodos de análisis y diseño.

Existen diferencias importantes entre un método y un lenguaje de modelado. Un método

es una manera explícita de estructurar el pensamiento y las acciones de cada individuo.

Además, el método le dice al usuario qué hacer, cómo hacerlo, cuándo hacerlo y por qué
hacerlo; mientras que el lenguaje de modelado carece de estas instrucciones. Los métodos
contienen modelos y esos modelos son utilizados para describir algo y comunicar los
resultados del uso del método.

2
 Con UML podemos modelar distintos tipos de sistemas: sistemas de software, sistemas de
hardware, y también se puede modelar sistemas que no son informáticos, como flujos de
trabajo (workflow) en una empresa, diseño de la estructura de una organización y por
supuesto, en el diseño de hardware. UML entrega una forma de modelar cosas conceptuales
como lo son procesos de negocio y funciones de sistema, además de cosas concretas como
lo son escribir clases en un lenguaje determinado, esquemas de base de datos y
componentes de software reusables.

4. Metodología de Jeffrey Whitten.

Teniendo entonces una idea clara de los conceptos, relaciones y diferencias entre datos,
información y conocimiento, se hace entonces importante, mencionar algunos conceptos
tales como “sistema”, “sistema de información” y “sistema de información informático” ya
que aunque sus definiciones puedan parecerse e incluso superponerse, poseen mínimos
detalles que marcan la diferencia.

La palabra sistema significa “Conjunto de cosas que relacionadas entre sí ordenadamente

contribuyen a determinado objeto”. Es importante enfocarnos en una palabra determinante
en este concepto: ordenadamente, este vocablo se define como “la forma en que están
organizados o dispuestos los distintos elementos de un sistema, a esto se le llama también
configuración” y más tarde “conocer el propósito o resultado que se desea obtener de un
sistema es el primer paso en la definición de la manera en que se configurarán sus
elementos” por lo tanto la salida de un sistema estará intrínsecamente relacionada con la
configuración del mismo.

3
 Tomando como base este simple pero general concepto de lo que es un sistema podemos
centrarnos en dialogar sobre que es un sistema de información, y aunque su definición
quizás no diste mucho de la anterior y nos ofrece una idea más específica de lo que en
realidad estamos buscando.

Los Sistemas de Información han sido conceptualizados por distintos investigadores y

expertos del área, los definen como “un conjunto de componentes interrelacionados que
recolectan o recuperan, procesan, almacenan y distribuyen información para apoyar la toma
de decisiones y el control de una organización”. Una definición mucho más concreta se
podría dilucidar como “un conjunto de personas, datos, procesos y tecnología de la
información que interactúan para recoger, procesar, almacenar y proveer la información
necesaria para el correcto funcionamiento de la organización”.

5. Metodología del Proceso Unificado de Desarrollo de Software

Es una metodología de desarrollo de software que está basado en componentes e interfaces
bien definidas, y junto con el Lenguaje Unificado de Modelado (UML), constituye la
metodología estándar más utilizada para el análisis, implementación y documentación de
sistemas orientados a objetos.

Es un proceso que puede especializarse para una gran variedad de sistemas de software, en
diferentes áreas de aplicación, diferentes tipos de organizaciones, diferentes niveles de
aptitud y diferentes tamaños de proyecto.

RUP no es un sistema con pasos firmemente establecidos, sino un conjunto de metodologías

adaptables al contexto y necesidades de cada organización.

Es el resultado de varios años de desarrollo y uso práctico en el que se han unificado técnicas
de desarrollo, a través del UML, y trabajo de muchas metodologías utilizadas por los
clientes. La versión que se ha estandarizado vio la luz en 1998 y se conoció en sus inicios
como Proceso Unificado de Rational 5.0; de ahí las siglas con las que se identifica a este
proceso de desarrollo.

Algunos aspectos que diferencian a RUP de las demás metodologías y lo que lo hace único
son que en RUP, los casos de uso no son sólo una herramienta para especificar los requisitos
del sistema, sino que también guían su diseño, implementación y prueba. Los casos de uso
constituyen un elemento integrador y una guía del trabajo.

Además de utilizar los casos de uso para guiar el proceso; se presta especial atención al
establecimiento temprano de una buena arquitectura que no se vea fuertemente impactada
ante cambios posteriores durante la construcción y el mantenimiento. También este
propone que cada fase se desarrolle en iteraciones.

4
6. 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.1. Fases o Etapas de Metodología RAD de James Martin.

a) Planificación de Requisitos
b) Etapa de Diseño
c) Construcción
d) Implementación

7. Metodología de Kendall y Kendall.

La metodología de Kendall y Kendall es un ciclo de desarrollo de los sistemas, y se desarrolla
en siete etapas las cuales son:

7.1. Identificación de problemas, oportunidades y objetivos:

5
 Esta fase es crucial para el éxito del resto del proyecto requiere que se observe de
forma objetiva lo que ocurre en una organización, luego en conjunto con otros
miembros de la organización hacer notar los problemas. Las oportunidades son
aquellas situaciones que se considera que pueden mejorarse, perfeccionarse
mediante el uso de los sistemas de información. También es un componente
importante de la primera fase, en esta etapa se deberá descubrir lo que la
organización intenta realizar, luego determinar si el uso de los sistemas de
información apoyaría a la organización para alcanzar sus metas.

7.2. Determinación de los requerimientos de información:

Esto se hace a partir de los usuarios particularmente involucrados, para determinar

los requerimientos de información dentro de una organización pueden utilizarse
diversos instrumentos, los cuales incluyen: muestreo, el estudio de los datos y formas
usadas para la organización, la entrevista, los cuestionarios; la observación de la
conducta de quien tomo las decisiones, así como de su ambiente. Se hace todo lo
posible por identificar qué información requiere el usuario para desempeñar sus
tareas.

7.3. Análisis de las necesidades del sistema:

Se analizan las necesidades propias del sistema, para ello existen herramientas y
técnicas diseñadas para tal fin, estas incluyen entre otras el uso de los diagramas de
flujo de datos que cuentan con una técnica estructurada para representar en forma
gráfica la entrada de datos a la organización, los procesos y la salida de información.
También se analizan las decisiones estructuradas por realizar, que son decisiones
donde las condiciones, condiciones alternativas, acciones y reglas de acción podrán
determinarse.

7.4. Diseño del sistema recomendado:

Se usa la información recolectada con anterioridad y se elabora el diseño lógico de

sistemas de información, se diseña también procedimiento es precisos de captura de
datos, con la finalidad de que los datos que se introducen en el sistema de
información, sean los correctos. Esta etapa también incluye el diseño de los archivos
o la base de datos que almacenará aquellos datos requeridos por quien toma las
decisiones en la organización.

 Desarrollo y documentación del software: Dentro de las técnicas estructuradas

para el diseño y documentación del software se tienen: el método HIPO, los
diagramas de flujo, los diagramas Nassi.Schneiderman, los diagramas Warnier-

6
 Orr y el pseudocódigo es aquí donde se transmite al programador los
requerimientos de programación.

 Pruebas y mantenimiento del sistema: Todo sistema de información debe

probarse antes de ser utilizado, ya que el costo es menor si se detectan los
problemas antes de que entre en funcionamiento. En un principio, se hace una
serie de pruebas, con datos tipo, para identificar las posibles fallas del sistema,
más adelante, se utilizarán los datos del sistema real.

 Implantación y evaluación del sistema: Esta es la última etapa del desarrollo

del sistema, esto incluye el adiestramiento que el usuario requerirá. Aunque la
evaluación del sistema se plantea como parte integrante de la última etapa del
ciclo de desarrollo de los sistemas; realmente la evaluación toma parte de cada
una de las etapas.

Uno de los criterios fundamentales que debe satisfacerse, es que el futuro usuario utilice el
sistema desarrollado

8. Metodología de Administración de Relaciones (RMM).

Es un proceso de análisis, diseño y desarrollo de aplicaciones hipermedia. Los elementos
principales de esta metodología son:

 Modelo E-R (Entidad-Relación)

 Modelo RMDM (Relationship Management Data Model).
 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 definidos, y con claras relaciones entre esas clases.

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 con el fin de modelizar los aspectos
unidos a la presentación de las entidades.

Ante las limitaciones que ofrecía RMM, sus creadores analizaron la estructura de
navegación de RMM y propusieron añadir dos nuevos y tipos de Slices:

 Slice Híbridos: permiten combinar atributos de diferentes entidades y

estructuras de acceso.

 Slice Mínimos: es la mínima parte de una entidad que es necesaria para

identificar uno de sus elementos y que se utilizara como ancla.

7
  M-Slice: permiten combinar primitivas de acceso con otros slices de otras
entidades para crear un m-slice.

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

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

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

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.

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.

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

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

11. Metodología de Sistemas Expertos por David Rolston.

Un Sistema Experto (SE), es básicamente un programa de computadora basado en
conocimientos y raciocinio que lleva a cabo tareas que generalmente sólo realiza un experto
humano; es decir, es un programa que imita el comportamiento humano en el sentido de
que utiliza la información que le es proporcionada para poder dar una opinión sobre un
tema en especial.

Se puede decir que los Sistemas Expertos son el primer resultado operacional de la
Inteligencia artificial, pues logran resolver problemas a través del conocimiento y raciocinio
de igual forma que lo hace el experto humano.

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

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.

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

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

11