Instituto universitario Politecnico Santiago Mariño

Escuela: Ingeniería de Sistemas.

Extensión Porlamar

Análisis y diseño de sistemas

Metodologías para el Análisis y Diseño de Sistemas

Realizado por:

Klenni Pino CI: 24.089.030

Prof. Lcdo. Jhonatan Fernandez

Porlamar, Mayo 2015

Introducción

El presente informe de investigación que trata sobre la “Metodología

para el Análisis” En la actualidad la mayoría de los usuarios de

microcomputadoras tienen acceso a un sistema de información o forman

parte del mismo. Todas las organizaciones cuentan con un sistema de

información de algún tipo, que sus empleados deben utilizar.

Cuando en cualquier organización se desea implantar un nuevo

sistema, de tal forma que sus miembros sean más productivos, obteniendo

un mayor provecho y apoyo del mismo, se requiere realizar una serie de

acciones y previsiones.

De tal modo que en este informe daremos a conocer algunos

métodos para el mejoramiento de las computadoras, en una investigación

ardua y precisa para, que los usuarios sepan un poco más para la utilización

de estos en la vida cotidiana…

1. Definición de:

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

1.2. Metodología: Una metodología es el conjunto de métodos por los

cuales se regirá una investigación científica por ejemplo, en tanto, para

aclarar mejor el concepto, vale aclarar que un método es el procedimiento

que se llevará a cabo en orden a la consecución de determinados objetivos.

Entonces, lo que preeminentemente hace la metodología es estudiar los

métodos para luego determinar cuál es el más adecuado a aplicar o

sistematizar en una investigación o trabajo.

2. Metodologías para el Análisis y Diseño de Sistemas (Explicar Etapas,

Fases, Actividades y ejemplos).

2.1. Lenguaje Unificado de Modelado (UML) (Diagramas).

UML son las siglas de “Unified Modeling Language” o “Lenguaje

Unificado de Modelado”. 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).

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 msg (“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:

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:

 Con este ejemplo sencillo hemos tratado de hacer explícito qué es y para

qué sirve UML: un conjunto de normas que nos dicen cómo hay que

representar esquemas de software. En el caso del software orientado a

objetos, en vez de gatos tendremos clases u objetos instanciados, y

dispondremos de numerosos tipos de esquemas y diagramas para

representar distintas cosas.

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

Fases o Etapas de Metodología RAD de James Martin.

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

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.

2.3. Metodología de Jeffrey Whitten.

Metodología Para el Desarrollo de Sistemas de Información y

Comunicación Según 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.

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

Entonces, podemos extraer de dichos conceptos los elementos

fundamentales de un sistema de información:

- Información: La información es la base, la materia prima sobre la cual

se mueve todo el engranaje de un sistema de información, es todo lo

almacenado, procesado y distribuido en la organización por el sistema.

- Las personas: Son los encargados de interactuar con la información,

quienes la introducen, utilizan y valoran su importancia en las distintas tareas

relacionadas con esta.

- Medios para la interacción con la información: Activos tangibles e

intangibles de interacción con los usuarios para el tratamiento de la

información, pueden ser archivos, documentos, hardware, software, redes de

comunicación, intranets, etcétera.

- Normas y/o técnicas de trabajo: Métodos utilizados por las personas

y las tecnologías para desarrollar sus actividades.

Este último concepto expresa también la síntesis de un sistema de

información informático, o basado en computadora cuando coloca como

parte de sus elementos la utilización de las ventajas ofrecidas por las

Tecnologías de la Información y las Comunicaciones (TIC) para dar un

tratamiento automático a los procesos de entrada, procesamiento y

distribución de la información.

A continuación se detallan las fases de esta metodología para el desarrollo

de los sistemas de información.

Fase I: Identificación del Problema El primer paso en toda

investigación es saber identificar el problema, es decir, saber con qué se va a

trabajar, qué es lo que se va a resolver o mejorar. Pero este problema debe

ser factible y en realidad cubrir con las expectativas de relevancia, para ser

luego resuelto con ingenio mediante la utilización de personas expertas en la

materia.

Fase II. Análisis del sistema actual. Bien se describe en el libro

haciendo alusión a un viejo proverbio que dice "No intentes arreglarlo a

menos que lo hayas comprendido". Esta fase consiste en estudiar y analizar

el sistema actual. Se identificaran sus problemas, cómo se maneja, con

quién se interrelaciona y cómo podría solventarse el mismo. Qué es lo que

se necesita para que el sistema trabaje de manera eficiente. Como parte del

análisis del sistema de información se encuentra el análisis de los

requerimientos, de viabilidad, el modelado de datos, procesos, redes y el

diccionario de datos.

Fase III. Diseño o Modelado El diseño del prototipo de los sistemas de

información consta de dos etapas: un diseño lógico y el desarrollo físico del

mismo. El primero se refiere a la descripción de salidas, entradas, archivos,

bases de datos, procedimientos y el segundo consta de la Programación del

sistema y la creación de archivos. El prototipo proporcionara información con

relación a la factibilidad del concepto. Se tomara como un plan piloto o

prueba del sistema. El prototipo diseñado podrá ser modificado con facilidad

y en el momento que así lo requiera según sea el caso.

Fase IV. Diseño de la topología y de los servicios. A partir de los

usuarios involucrados con el sistema, y utilizando diversos instrumentos y

técnicas de recolección de datos, el estudio de datos y formas usadas por la

organización, se ubicaran los requerimientos del sistema a proponer. Esto

permite obtener opiniones y requerimientos sobre el sistema necesario a

implantar. Las causas posibles por las cuales suceden las cosas y algunas

ideas en relación con las posibles modificaciones. La versión modificada se

tomará, a su vez, como prueba para obtener información valiosa en el diseño

final.

Fase V. Desarrollo y Documentación Se elabora lo que realmente es

la solución del problema basándose en el prototipo anterior y del diseño del

sistema propuesto a fin de solventarlo. Para poder lograr esto, se necesitan

una serie de pasos como lo son: revisión del prototipo, desarrollo de la

infraestructura del sistema, integración interna, verificación de las salidas, y

documentación paralela de todos estos pasos.

Fase VI. Implantación El término de implantación de sistemas se

refiere a la entrega del mismo a los usuarios finales que habrán de utilizarlo.

Se colocara el sistema en funcionamiento para que el problema pueda ser

resuelto de una manera práctica y fácil. Se debe instruir a los usuarios finales

que estarán directamente relacionados con el mismo a fin de que puedan

entender el nuevo sistema y hacer modificaciones del software y/o resolver

problemas en caso que ocurrieran.

Fase VII. Pruebas. Una fase muy importante en el desarrollo de todo

sistema de información es la fase de prueba, la cual permite obtener un

indicador de que el esfuerzo desempeñado no fue en vano. Su filosofía es la

detección de errores. Aunque el sistema es probado arduamente por los

analistas, diseñadores y programadores del sistema, es necesario realizar

pruebas con los usuarios finales. Durante estas pruebas, además de hacer

las observaciones necesarias durante algunas consultas reales se usara del

sistema de información, también se llenara una bitácora con errores,

comentarios, sugerencias a fin de obtener retroalimentación de la usabilidad,

utilidad y fallas del mismo.

Fase VIII Depuración. La depuración es el proceso metodológico para

encontrar y reducir errores o defectos en un sistema de información o en una

pieza de hardware. Esta fase En general, las tareas de la depuración de

errores, suelen ser engorrosas y agotadoras. Existen aplicaciones que

permiten ayudar a analistas, programadores y diseñadores en estas tareas,

pero es la habilidad del mismo el factor más determinante para la efectividad

y eficiencia del proceso de depuración.

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

El proceso de desarrollo constituye un marco metodológico que define en

términos de metas estratégicas, objetivos, actividades y artefactos

(documentación) requerido en cada fase de desarrollo. Esto permite enfocar

esfuerzo de los recursos humanos en términos de habilidades, competencias

y capacidades a asumir roles específicos con responsabilidades bien

definidas.

Estructura del ciclo de vida del proceso de desarrollo unificado

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.

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.

Este tipo de metodología no ha sido aplicada probablemente por su

complejidad de administración o desconocimiento de la misma,

desaprovechando sus considerables ventajas respecto a los métodos

tradicionales. Por esto, es necesario entonces desarrollar mecanismos de

apropiación tecnológica más eficaces, que permitan mantener actualizadas

las prácticas organizacionales y los marcos de referencia aquí mencionados. 

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

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.

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.

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.

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.

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.

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.

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.

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

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.

Muestra de un diagrama entidad-relación (las entidades se representan con

un recuadro y las relaciones mediante un símbolo en forma de tridente).

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

No tiene sentido que utilicemos AOO y DOO de forma que potenciemos la

reutilización de código y la correspondencia entre el dominio del problema y

el sistema informático, si luego perdemos todas estas ventajas con una

implementación de mala calidad.

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

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.

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

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.

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.10. Metodología de Sistemas Blandos (SSM) de Peter Checkland.

La Metodología de Sistemas Blandos (Soft System Methodology

(SSM)), que parte del concepto de Weltanschauung (del alemán: visión,

perspectiva o imagen particular del mundo) de Peter Checkland, que es una

técnica cualitativa, en donde aborda problemas no estructurados. Las

percepciones de las personas son distintas, a veces contradictorias, y

muchas veces confusas. Esta Metodología se ocupa de problemas donde

existe un alto componente social, político y humano. A comparación de los

sistemas duros, que se ocupan más de la tecnología. Es decir, La

Metodología de Sistema Blandos es una manera muy útil de acercar

situaciones complejas sociales, y encontrar sus respuestas

correspondientes.

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

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.

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.

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.

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

Conclusión

Ya conociendo los métodos antes mencionados podemos decir que

para el mejor funcionamiento de las computadoras debemos tener en

cuentas algunas de las pautas que salen en distintos de ello, ya conociendo

de qué trata podemos aplicarlo en la vida diaria y así tratar un mejoramiento

en la sociedad.

Los métodos realizados por varios personajes relevantes para el estudio de

la información de los sistemas son de suma importancia, ya que mucha

personas no toman en cuenta que existen.

Referencias Bibliográficas y Electrónicas Completas

http://www.megatareas.com/doc/1163/Metodo-Metodologia.html

http://aprenderaprogramar.com/index.php?

option=com_content&view=article&id=688:ique-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

http://es.slideshare.net/travesuras79/metodologa-para-el-desarrollo-del-

sistemas-de-informacin-y-comunicacin-segn-jeffrey-whitten

http://www.utvm.edu.mx/OrganoInformativo/orgJul07/RUP.htm

http://franklinmorillouba.blogspot.com/2010/11/metodologia-orientada-

objetos-fases-y.html

http://mundoinformatico321.blogspot.com/2012/11/metodologia-kendall-

kendall.html

http://mundoinformatico321.blogspot.com/2012/12/metodologia-del-software-

educativo-por.html

http://es.slideshare.net/DunoHerreraM/metodologia-de-checkland-para-

sistemas-suaves

http://www.softeng.es/es-es/empresa/metodologias-de-trabajo/metodologia-

scrum.html