Este documento presenta varias metodologías para el análisis y diseño de sistemas. Describe brevemente el método, la metodología del ciclo de vida de un sistema, el proceso unificado de desarrollo de software, la metodología de Kendall y Kendall, la metodología de administración de relaciones y la metodología orientada a objetos. Explica las diferentes fases de cada metodología y los pasos involucrados en el análisis y diseño de sistemas de información.

1. República Bolivariana de Venezuela.
Ministerio del Poder Popular para la Educación Superior.
I.U.P.”Santiago Mariño”.
Extensión-Porlamar.
Informe
Integrante:
Oblitas, Christian.
C.I. 20.350.155

2. MÉTODO
Un método es una serie de pasos sucesivos, conducen a una meta. El
objetivo del profesionista es llegar a tomar las decisiones y una teoría que
permita generalizar y resolver de la misma forma problemas semejantes en el
futuro. El método es un orden que debe imponer a los diferentes procesos
necesarios apara lograr un fin dado o resultados. Por ende es necesario que
siga el método más apropiado a su problema, lo que equivale a decir que debe
seguir el camino que lo conduzca a su objetivo.
METODOLOGÍA:
Se denomina metodología al estudio de los métodos de investigación que
luego se aplican en el ámbito científico. La metodología de la investigación
supone la sistematización, es decir, la organización de los pasos a través de
los cuales se ejecutará una investigación científica.
METODOLOGÍAS PARA ANÁLISIS Y DISEÑO DE SISTEMAS:
En una organización o empresa, el análisis y diseño de sistemas es el
proceso de estudiar su situación con la finalidad de observar como trabaja y
decir si es necesario realizar una mejora; el encargado de realizar estas tareas
es el analista de sistemas. Antes de comenzar el desarrollo de cualquier
proyecto, se conoce un estudio de sistemas para detectar todos los detalles de
la situación actual en la empresa. La información reunida con este estudio sirve
como base para crear varias estrategias de diseño.
LENGUAJE UNIFICADO DE MODELADO (UML) (Diagramas):
Lenguaje Unificado de Modelado (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; 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.
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.

3. 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 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.
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.
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.
Esta metodología consta de 4 etapas a saber:
1) Etapa de Planificación de Requisitos: Esta etapa requiere que los
usuarios con un vasto conocimiento de los procesos de la compañía

4. 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.
Metodología del Proceso Unificado de Desarrollo de Software.
El proceso unificado conocido como RUP, es un modelo de software que
permite el desarrollo de software a gran escala, mediante un proceso continuo
de pruebas y retroalimentación, garantizando el cumplimiento de ciertos
estándares de calidad. Aunque con el inconveniente de generar mayor
complejidad en los controles de administración del mismo. Sin embargo, los
beneficios obtenidos recompensan el esfuerzo invertido en este aspecto.
Fase de concepción:
Esta fase tiene como propósito definir y acordar el alcance del proyecto con
los patrocinadores, identificar los riesgos potenciales asociados al proyecto,
proponer una visión muy general de la arquitectura de software y producir el
plan de las fases y el de iteraciones.
Fase de elaboración:
En la fase de elaboración se seleccionan los casos de uso que permiten
definir la arquitectura base del sistema y se desarrollaran en esta fase, se
realiza la especificación de los casos de uso seleccionados y el primer análisis
del dominio del problema, se diseña la solución preliminar.

5. Fase de construcción:
El propósito de esta fase es completar la funcionalidad del sistema, para ello
se deben clarificar los requerimientos pendientes, administrar los cambios de
acuerdo a las evaluaciones realizados por los usuarios y se realizan las
mejoras para el proyecto.
Fase de transición:
El propósito de esta fase es asegurar que el software esté disponible para
los usuarios finales, ajustar los errores y defectos encontrados en las pruebas
de aceptación, capacitar a los usuarios y proveer el soporte técnico necesario.
Se debe verificar que el producto cumpla con las especificaciones entregadas
por las personas involucradas en el proyecto.
Metodología de Kendall y Kendall:
Es un ciclo de desarrollo de los sistemas, y se desarrolla en siete etapas las
cuales son:
 Identificación de problemas, oportunidades y objetivos: 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.
 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 la
decisiones, así como de su ambiente. Se hace todo lo posible por
identificar qué información requiere el usuario para desempeñar sus
tareas.
 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

6. 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.
 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-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.
Metodología de Administración de Relaciones (RMM):
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.
Las etapas son:
 Primera etapa: representar los objetos del dominio con la ayuda del
modelo Entidad-Relación ampliado con relaciones asociativas (aquéllas

7. 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 OMT (Object Modeling Technique) fue creada por James
Rumbaugh y Michael Blaha en 1991, mientras James dirigía un equipo de
investigación de los laboratorios General Electric.
OMT es una de las metodologías de análisis y diseño orientada a objetos,
más madura y eficiente que existe en la actualidad. La gran virtud que aporta
esta metodología es su carácter de abierta (no propietaria), que le permite ser
de dominio público y , en consecuencia, sobrevivir con enorme vitalidad. Esto
facilita su evolución para acoplarse a todas las necesidades actuales y futuras
de la ingeniería de software.
Las fases que conforman a la metodología OMT son:
1. Análisis: El analista construye un modelo del dominio del problema,
mostrando sus propiedades más importantes. El modelo de análisis es una
abstracción resumida y precisa de lo que debe de hacer el sistema deseado y
no de la forma en que se hará. Los elementos del modelo deben ser conceptos
del dominio de aplicación y no conceptos informáticos tales como estructuras

8. de datos. Un buen modelo debe poder ser entendido y criticado por expertos en
el dominio del problema que no tengan conocimientos informáticos.
2. Diseño del sistema: El diseñador del sistema toma decisiones de alto
nivel sobre la arquitectura del mismo. Durante esta fase el sistema se organiza
en subsistemas basándose tanto en la estructura del análisis como en la
arquitectura propuesta. Se selecciona una estrategia para afrontar el
problema.
3. Diseño de objetos: El diseñador de objetos construye un modelo de
diseño basándose en el modelo de análisis, pero incorporando detalles de
implementación. El diseño de objetos se centra en las estructuras de datos y
algoritmos que son necesarios para implementar cada clase. OMT describe la
forma en que el diseño puede ser implementado en distintos lenguajes
(orientados y no orientados a objetos, bases de datos, etc.).
4. Implementación: Las clases de objetos y relaciones desarrolladas
durante el análisis de objetos se traducen finalmente a una implementación
concreta. Durante la fase de implementación es importante tener en cuenta los
principios de la ingeniería del software de forma que la correspondencia con el
diseño sea directa y el sistema implementado sea flexible y extensible.
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.

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

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

11. 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 subestadios 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.
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.
Metodología MERINDE:
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.

12. 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 deben 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.
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.
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á.
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.
Fase de Transición:

13. 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.
Metodología SCRUM:
Scrum es un proceso en el que se aplican de manera regular un conjunto
de buenas prácticas para trabajar colaborativamente, en equipo, y obtener el
mejor resultado posible de un proyecto. Estas prácticas se apoyan unas a otras
y su selección tiene origen en un estudio de la manera de trabajar de equipos
altamente productivos.
En Scrum se realizan entregas parciales y regulares del producto final,
priorizadas por el beneficio que aportan al receptor del proyecto. Por ello,
Scrum está especialmente indicado para proyectos en entornos complejos,
donde se necesita obtener resultados pronto, donde los requisitos son
cambiantes o poco definidos, donde la innovación, la competitividad, la
flexibilidad y la productividad son fundamentales.
Las actividades que se llevan a cabo en Scrum son las siguientes:
Planificación de la iteración:
El primer día de la iteración se realiza la reunión de planificación de la
iteración. Tiene dos partes:
 Selección de requisitos (4 horas máximo). El cliente presenta al equipo
la lista de requisitos priorizada del producto o proyecto. El equipo
pregunta al cliente las dudas que surgen y selecciona los requisitos más
prioritarios que se compromete a completar en la iteración, de manera
que puedan ser entregados si el cliente lo solicita.
 Planificación de la iteración (4 horas máximo). El equipo elabora la lista
de tareas de la iteración necesarias para desarrollar los requisitos a que
se ha comprometido. La estimación de esfuerzo se hace de manera
conjunta y los miembros del equipo se autoasignan las tareas.
Ejecución de la iteración:

14. Cada día el equipo realiza una reunión de sincronización (15 minutos
máximo). Cada miembro del equipo inspecciona el trabajo que el resto está
realizando (dependencias entre tareas, progreso hacia el objetivo de la
iteración, obstáculos que pueden impedir este objetivo) para poder hacer las
adaptaciones necesarias que permitan cumplir con el compromiso adquirido.
En la reunión cada miembro del equipo responde a tres preguntas:
 ¿Qué he hecho desde la última reunión de sincronización?
 ¿Qué voy a hacer a partir de este momento?
 ¿Qué impedimentos tengo o voy a tener?
Durante la iteración el Facilitador (Scrum Master) se encarga de que el equipo
pueda cumplir con su compromiso y de que no se merme su productividad.
 Elimina los obstáculos que el equipo no puede resolver por sí mismo.
 Protege al equipo de interrupciones externas que puedan afectar su
compromiso o su productividad.
Inspección y adaptación:
El último día de la iteración se realiza la reunión de revisión de la iteración.
Tiene dos partes:
 Demostración (4 horas máximo). El equipo presenta al cliente los
requisitos completados en la iteración, en forma de incremento de
producto preparado para ser entregado con el mínimo esfuerzo. En
función de los resultados mostrados y de los cambios que haya habido
en el contexto del proyecto, el cliente realiza las adaptaciones
necesarias de manera objetiva, ya desde la primera iteración,
replanificando el proyecto.
 Retrospectiva (4 horas máximo). El equipo analiza cómo ha sido su
manera de trabajar y cuáles son los problemas que podrían impedirle
progresar adecuadamente, mejorando de manera continua su
productividad. El Facilitador se encargará de ir eliminando los obstáculos
identificados.

15. BIBLIOGRAFÍA
BALASUBRAMANIAN, V; BIEBER, M; ISAKOWITZ, T. Systematic hypermedia
design.CRIS Working Paper series 5/10/96 1996.
ISAKOWITZ, T.; KAMIS, A.; KOUFAKIS, M: Extending the capabilities of RMM:
Russian dolls and Hypertext. 1996
ISAKOWITZ, T.; STOHR, E.A.; BALASUBRAMANIAN, P. "RMM: A
methodology for the design of structured hypermedia". Communications of the
ACM, vol. 38, 1995.
https://www.google.co.ve/?gfe_rd=cr&ei=ZOlpVfqONcTHsAfg84DgCw&gws_rd
=ssl#q=DEFINICION+DE+METODo
http://ri.biblioteca.udo.edu.ve/bitstream/123456789/1041/1/04MULTIMEDIA.pdf
http://www.scielo.org.ve/scielo.php?pid=S079840652008000400010&script=sci
arttext