Presente trabajo, encontraremos varios métodos de Análisis y Diseños de Sistemas.

1. República Bolivariana de Venezuela
Ministerio del Poder Popular para la Educación
I.U.P. “Santiago Mariño”
Porlamar-Estado Nueva Esparta.
Metodología para el Análisis y Diseños
De Sistemas
Elaborado Por:
FREDDY RAMOS
C.I 20326663
SEC: “3A”
ING: SISTEMAS
Profesor:
ING.RODRIGUEZ BRITO, DIOGENES
Porlamar 05 de julio de 2017

2. INTRODUCCIÓN
El análisis y diseños de sistemas se refieren al proceso de examinar la
situación de una empresa con el propósito de mejorar con métodos y procedimiento
más adecuados. El desarrollo de sistemas tienes dos componentes. Sistema de
información conjunto u ordenación de elementos organizados para llevar a cabo algún
método, procedimiento o control mediante el proceso de información.
En la actualidad para muchos organizaciones, los sistemas de información
basadas en computadoras son el corazón de las actividades cotidianas u objeto de
gran consideración en la toma de decisiones, la empresa considera con mucho
cuidado las capacidades de sus sistemas de información cuando deciden ingresar o no
, en nuevos mercados o cuando planean la respuesta que darán a la competencia.
Al establecer los sistemas de información basadas en computadoras deben
tener la certeza de que se loga dos objetivos principales que sea un sistema correcto y
que este correcto el sistemas. Ningún sistema que deje satisfacer ambos objetivos será
completamente útil para la gerencia u organización.

3. 1. Definición de:
1.1 Método.
En términos generales, método es la vía o camino que se utiliza para llegar a un
fin o para un objetivo.
En el campo de la investigación, se considera método al modo general o manera
que se emplea para abordar un problema, y aunque resulte redundante, el camino
fundamental empleado en la investigación científica para obtener conocimiento
científico es el método científico, que se define a continuación:
El método científico es el conjunto de pasos técnicas y procedimientos que se
emplean para formular y resolver problemas de investigación mediante la prueba o
verificación de hipótesis.
Aun cuando este método no es el único camino para la obtención del conocimiento
científico, surge como vía flexible utilizada por la mayoría de las ciencias fácticas en
la actualidad.
Prácticamente, se le considera como el método general de la ciencia.
Tipos de métodos:
 Observación: consiste en la percepción de hecho o fenómeno.
 Formulación del problema: se basa en la elaboración de una pregunta o
interrogación acerca del hecho observado
 Análisis: los datos obtenidos son procesados para así determinar cuáles
confirman o niega la hipótesis

4. 1.2 Metodología:
El concepto hace referencia al plan de investigación que permite cumplir ciertos
objetivos en el marco de una ciencia. Cabe resaltar que la metodología también puede
ser aplicada en el ámbito artístico, cuando se lleva a cabo una observación rigurosa.
Por lo tanto, puede entenderse a la metodología como el conjunto
de procedimientos que determinan una investigación de tipo científico o marcan el
rumbo de una exposición doctrinal.
En el ámbito de las ciencias sociales, el recurso de la metodología se enfoca en la
realidad de una sociedad para arribar a una conclusión cierta y contundente acerca de
un episodio valiéndose de la observación y el trabajo práctico típico de toda ciencia.
Es importante la distinción entre el método (nombre que recibe cada plan
seleccionado para alcanzar un objetivo) y la metodología (rama que estudia el
método). El metodólogo no se dedica a analizar ni a verificar conocimiento ya
obtenido y aceptado por la ciencia: su tarea es rastrear y adoptar estrategias válidas
para incrementar dicho conocimiento.
La metodología es una pieza esencial de toda investigación (método científico)
que sigue a la propedéutica ya que permite sistematizar los procedimientos y técnicas
que se requieren para concretar el desafío.

5. 2. Metodología para el Análisis y Diseño de sistemas.
En una organización o empresa, el análisis y diseño de sistemas de información
incluye el estudio de la situación de dicho sistema, con la finalidad de observar cómo
trabaja actualmente y a partir de ello decidir si es necesaria una mejora; el encargado
de llevar a cabo esta acción es el analista de sistemas. Antes de comenzar con el
desarrollo de cualquier proyecto se lleva a cabo un estudio de sistemas para
determinar todos los aspectos de la situación actual de la empresa. La información
resultante del estudio sirve de base para la formulación de distintas estrategias de
diseño. Los administradores decidirán que estrategias adoptar. Los usuarios finales
del sistema son los que, en gran parte, ayudarán al análisis y desarrollo de dicha
propuesta para así cumplir, de forma cabal, cada uno de los objetivos planteados.
El análisis y diseño de sistemas se refiere al proceso de examinar la situación
de una empresa con el propósito de mejorar con métodos y procedimientos más
adecuados. El desarrollo de sistemas tiene dos componentes. SISTEMA DE
INFORMACIÓN Conjunto u ordenación de elementos organizados para llevar a cabo
algún método, procedimiento o control mediante el proceso de información.
Análisis: Es el proceso de clasificación e interpretación de
hechos, diagnóstico de problemas y empleo de la información para recomendar
mejoras al sistemas. Diseño: Especifica las características del producto terminado.
2.1 Lenguaje Unificado de Modelado (UML) (Diagramas).
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),

6. incluyendo aspectos conceptuales tales como procesos, 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 especifica en sí mismo qué metodología o proceso usar.
UML no puede compararse con la programación estructurada, pues UML
significa Lenguaje Unificado de Modelado, no es programación, solo se diagrama la
realidad de una utilización en un requerimiento. Mientras que, programación
estructurada, es una forma de programar como lo es la orientación a objetos, la
programación orientada a objetos viene siendo un complemento perfecto de UML,
pero no por eso se toma UML solo para lenguajes orientados a objetos.
2.2 Metodología del ciclo de vida de un Sistemas James Martin.
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.

7. Fases o Etapas de Metodología RAD de James Martin
 Planificación de requisitos
 Etapa de Diseño
 Construcción
 Implementación
2.3 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

8. 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.
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.
2.4 Metodología del Proceso Unificado de desarrollo se software.
Proceso Unificado de Desarrollo (RUP): 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.

9. 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 Racional 5.0; de ahí las siglas con
las que se identifica a este proceso de desarrollo.
2.5 Metodología de Kendall y Kendall.
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.
La en metodología empleada en el desarrollo del sistema de información fue la
planteada por Kendall y Kendall (1997), el cual “es un enfoque por fases de análisis y
diseño que sostiene que los sistemas son desarrollados de mejor manera mediante el
uso de un ciclo específico de actividades del analista y del usuario”. Este Ciclo de
Vida de Desarrollo de Sistema describe en pocas palabras lo que abarca el método de
área aplicada. 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. Define seis fase entre ellas están:

10.  Identificación de problemas, oportunidades y objetivos.
 Determinación de requerimientos.
 Análisis de necesidades.
 Diseño del sistema.
 Prueba y mantenimiento.
 Implementación y evaluación.
2.6 Metodología de administración de relaciones (RMM).
Es un proceso de análisis, diseño y desarrollo de aplicaciones hipermedio. 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 modernizar 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:

11.  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.
 M-Slice: permiten combinar primitivas de acceso con otros slices de otras
entidades para crear un m-slice.
2.7 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.

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

13. 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.
2.8 Metodología de sistemas Expertos por David Rolston.
Un Sistema Experto (SE), es básicamente un programa de computadora basado
en conocimiento y raciocino que lleva a cabo que tareas que generalmente solo
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 proporcionad 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 problema a través del conocimiento y
raciocino 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.
Es una referencia bastante completa y hoy en día representa una guía para el
desarrollo de software, la cual está compuesta por cinco etapas (análisis, diseño,

14. desarrollo, pruebas y ajustes) las mismas le otorgan énfasis a los siguientes aspectos:
la solidez del análisis, como punto de partida; el dominio de teorías sustantivas sobre
el aprendizaje y la comunicación humana como fundamento para el diseño de los
ambientes educativos computarizados; la evaluación permanente bajo criterios
predefinidos, a lo largo de todas las etapas del proceso, como medio del
perfeccionamiento continuo de material; la documentación adecuada y suficiente de
lo que se realiza en cada etapa, como base para el mantenimiento que requerirá el
material a lo largo de su vida útil.
Según el ciclo propuesto por Álvaro Galvis. Los MECs deben ser verificados por
expertos en metodología a fin de garantizar la efectividad correspondiente a los
contenidos en relación con su aplicabilidad tendiente a la población objeto de estudio
y al logro de tales metas. Expertos de informática a objeto de verificar la
optimización de los equipos con respecto al sistema o software propuesto. De
cumplirse estas revisiones, el ciclo culminaría y por ende el software puede ser
aplicado o ejecutado. En caso contrario, el ciclo realizaría un seguimiento pertinente a
las etapas donde se presentaron debilidades a fin de rediseñarlas y ajustarlas a las
necesidades.
 Análisis:
El objeto de esta etapa es determinar el contexto en el cual se va a crear la
aplicación y derivar de allí los requerimientos que deberá atender la solución
interactiva como complemento a otras soluciones basadas en uso de otros medios
(personales, audio-visuales, impresos, exponenciales), teniendo claro el rol de cada
uno de los medios educativos seleccionados y la vialidad de usuarios.
 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).

15. 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).
 Desarrollo:
En esta fase se implementa la aplicación usando la información obtenida
anteriormente. Tomando en cuenta las restricciones que se tengan.
 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.
 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.

16. 2.10 Metodología de Sistema Blando (SSM) de Peter Checkland.
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.
Acerca de Peter Checkland…: En el año 2002 la Universidad Checa de Economía
le concedió al Profesor Peter Checkland, ser uno de los académicos más reconocidos
de la Universidad de Lancaster, por su trayectoria, sus teorías, que lo han llevado a
tener varios doctorados.
La trayectoria de Checkland es que ha enseñado en la Universidad de Lancaster
por más de 30 años, después de 25 años que trabajó como encargado de una industria,
es aquí en donde observa su alrededor y comienza a crear la Metodología de Sistemas
Blandos (SSM).
La SSM está conformada por 7 etapas, cuyo orden puede variar de acuerdo a las
características de lo que queremos estudiar. Aquí construiremos una imagen lo más
clara posible del problema, y no tratar de representarla mediante sistemas
cuantitativos:
1. Investigar el problema no estructurado:
Es decir encontrar hechos de la situación del problema, es decir, investigar
básicamente el problema, por ejemplo: ¿Quiénes son los que juegan bien?, ¿Cómo
trabaja el proceso ahora?, etc. Para así lograr una descripción en donde existe dicho
problema, y sin darle ninguna estructura.

17. 2. Expresar la situación del problema:
Aquí nos encontramos con una situación más estructurada, haciendo una
descripción del pasado, presente y su consecuencia en el futuro, y viendo las
aspiraciones, intereses y necesidades en donde se contiene mi problema, se hace casi
siempre un diagrama (que puede ser un organigrama, cuadro pictográfico, etc), que
mostrará los límites, la estructura, flujos de información, los canales de
comunicación, y principalmente muestra el sistema humano en actividad, que serán
relevante en la definición del problema.
3. Seleccionar una visión de la situación y producir una definición raíz:
El propósito de la definición de la raíz es expresar la función central de un cierto
sistema de actividad, esta raíz se expresa como un proceso de transformación que
toma una entidad como entrada de información, cambia o transforma a esa entidad, y
produce una nueva forma de entidad.
4. Confección y verificación de modelos conceptuales:
Partiendo de la definición de la raíz, se elaboran modelos conceptuales que
representen, idealmente las actividades que, según la definición de la raíz en cuestión,
se deban realizar en el sistema, así existirán tantos modelos conceptuales como
definiciones de raíz, se puede realizar en un gráfico “PERT”, siendo los nodos
actividades que se harán, la estructuración de basa en la dependencia lógica, siendo
esta los arcos en el gráfico.

18. 5. Comparación de los modelos conceptuales con la realidad, es decir etapa
4 con la etapa 2:
En esta etapa los modelos construidos en al etapa 4 (elaboración de modelos
conceptuales, a través de una malla “PERT”) serán comparados con la expresión real
del mundo, de la etapa 2 (diagrama), se verán las diferencias y similitudes entre los
modelos conceptuales y lo que existe en la actualidad del sistema.
6. Diseño de cambios deseables, viables y factibles:
Se detectan los cambios que con posible llevar a cabo en la realidad y en la etapa
siguiente. Estos cambios se detectan 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 aprobado por las personas, que conforman el
sistema humano, para garantizar que sean deseables y viables.
7. Acciones para mejorar la situación del problema:
Es decir la implantación de cambios, que fueron detectados en la etapa 6. Acá se
comprende la puesta en marcha de los cambios diseñados, tendiente a solucionar la
situación del problema, y el control de los mismos, pero no representa el fin de la
metodología, pues en su aplicación se transforma en un ciclo de continua
conceptualización y habilitación de cambios, siempre tendiendo a mejorar la
situación.
2.11 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.

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

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

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

22. 2.12 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.
Scrum también se utiliza para resolver situaciones en que no se está entregando al
cliente lo que necesita, cuando las entregas se alargan demasiado, los costes se
disparan o la calidad no es aceptable, cuando se necesita capacidad de reacción ante
la competencia, cuando la moral de los equipos es baja y la rotación alta, cuando es
necesario identificar y solucionar ineficiencias sistemáticamente o cuando se quiere
trabajar utilizando un proceso especializado en el desarrollo de producto.
2.13 Metodología XP.
La programación extrema o eXtreme Programming (XP) es un enfoque de la
ingeniería de software formulado por Kent Beck, autor del primer libro sobre la
materia, Extreme Programming Explained: Embrace Change (1999). Es el más
destacado de los procesos ágiles de desarrollo de software. Al igual que éstos, la

23. programación extrema se diferencia de las metodologías tradicionales principalmente
en que pone más énfasis en la adaptabilidad que en la previsibilidad. Los defensores
de XP consideran que los cambios de requisitos sobre la marcha son un aspecto
natural, inevitable e incluso deseable del desarrollo de proyectos. Creen que ser capaz
de adaptarse a los cambios de requisitos en cualquier punto de la vida del proyecto es
una aproximación mejor y más realista que intentar definir todos los requisitos al
comienzo del proyecto e invertir esfuerzos después en controlar los cambios en los
requisitos.
¿QUÉ ES PROGRAMACIÓN EXTREMA O XP?
 Metodología liviana de desarrollo de software
 Conjunto de prácticas y reglas empleadas para desarrollar software
 Basada en diferentes ideas acerca de cómo enfrentar ambientes muy
cambiantes
 Originada en el proyecto C3 para Chrysler
 En vez de planificar, analizar y diseñar para el futuro distante, hacer todo esto
un poco cada vez, a través de todo el proceso de desarrollo
OBJETIVOS.
 Establecer las mejores prácticas de Ingeniería de Software en los desarrollo de
proyectos.
 Mejorar la productividad de los proyectos.
 Garantizar la Calidad del Software desarrollando, haciendo que este supere las
expectativas del cliente.
CONTEXTO XP
 Cliente bien definido
 Los requisitos pueden (y van a) cambiar
 Grupo pequeño y muy integrado (máximo 12 personas

24.  Equipo con formación elevada y capacidad de aprender
CARACTERÍSTICAS XP
 Metodología basada en prueba y error
 Fundamentada en Valores y Prácticas
 Expresada en forma de 12 Prácticas–Conjunto completo–Se soportan unas a
otras–Son conocidas desde hace tiempo. La novedad es juntarlas
VALORES XP
 Simplicidad XP propone el principio de hacer la cosa más simple que pueda
funcionar, en relación al proceso y la codificación. Es mejor hacer hoy algo
simple, que hacerlo complicado y probablemente nunca usarlo mañana.
 Comunicación Algunos problemas en los proyectos tienen origen en que
alguien no dijo algo importante en algún momento. XP hace casi imposible la
falta de comunicación.
 Realimentación Retroalimentación concreta y frecuente del cliente, del
equipo y de los usuarios finales da una mayor oportunidad de dirigir el
esfuerzo eficientemente.
 Coraje El coraje (valor) existe en el contexto de los otros 3 valores.(si
funciona…mejóralo)
EL ESTILO XP
 Está orientada hacia quien produce y usa el software
 Reduce el costo del cambio en todas las etapas del ciclo de vida del sistema.
 Combina las que han demostrado ser las mejores prácticas para desarrollar
software, y las lleva al extremo.
PRÁCTICAS BÁSICAS DE LA PROGRAMACIÓN EXTREMA
Para que todo esto funcione, la programación extrema se basa en doce "prácticas
básicas" que deben seguirse al pie de la letra. Dichas prácticas están definidas (en

25. perfecto inglés) en www.xprogramming.com/xpmag/whatisxp.htm. Aquí tienes un
pequeño resumen de ellas.
 Equipo completo: Forman parte del equipo todas las personas que tienen
algo que ver con el proyecto, incluido el cliente y el responsable del proyecto.
 Planificación: Se hacen las historias de usuario y se planifica en qué orden se
van a hacer y las mini-versiones. La planificación se revisa continuamente.
 Test del cliente: El cliente, con la ayuda de los desarrolladores, propone sus
propias pruebas para validar las mini-versiones.
 Versiones pequeñas: Las mini-versiones deben ser lo suficientemente
pequeñas como para poder hacer una cada pocas semanas. Deben ser
versiones que ofrezcan algo útil al usuario final y no trozos de código que no
pueda ver funcionando.
 Diseño simple: Hacer siempre lo mínimo imprescindible de la forma más
sencilla posible. Mantener siempre sencillo el código.
 Pareja de programadores: Los programadores trabajan por parejas (dos
delante del mismo ordenador) y se intercambian las parejas con frecuencia (un
cambio diario).
 Desarrollo guiado por las pruebas automáticas: Se deben realizar
programas de prueba automática y deben ejecutarse con mucha frecuencia.
Cuantas más pruebas se hagan, mejor.
 Integración continua: Deben tenerse siempre un ejecutable del proyecto que
funcione y en cuanto se tenga una nueva pequeña funcionalidad, debe
recompilarse y probarse. Es un error mantener una versión congelada dos
meses mientras se hacen mejoras y luego integrarlas todas de golpe. Cuando
falle algo, no se sabe qué es lo que falla de todo lo que hemos metido.
 El código es de todos: Cualquiera puede y debe tocar y conocer cualquier
parte del código. Para eso se hacen las pruebas automáticas.

26.  Normas de codificación: Debe haber un estilo común de codificación (no
importa cual), de forma que parezca que ha sido realizado por una única
persona.
 Metáforas: Hay que buscar unas frases o nombres que definan cómo
funcionan las distintas partes del programa, de forma que sólo con los
nombres se pueda uno hacer una idea de qué es lo que hace cada parte del
programa. Un ejemplo claro es el "recolector de basura" de java. Ayuda a que
todos los programadores (y el cliente) sepan de qué estamos hablando y que
no haya mal entendidos.
 Ritmo sostenible: Se debe trabajar a un ritmo que se pueda mantener
indefinidamente. Esto quiere decir que no debe haber días muertos en que no
se sabe qué hacer y que no se deben hacer un exceso de horas otros días. Al
tener claro semana a semana lo que debe hacerse, hay que trabajar duro en
ello para conseguir el objetivo cercano de terminar una historia de usuario o
mini-versión.
MANEJO COLECTIVO DEL CÓDIGO
VENTAJAS Y DESVENTAJAS DE EXTREME PROGRAMMING
Ventajas:
 Programación organizada.
 Menor taza de errores.
 Satisfacción del programador.
Desventajas:
 Es recomendable emplearlo solo en proyectos a corto plazo.
 Altas comisiones en caso de fallar.

27. CONCLUSIÓN
La función de análisis dar soporte a las actividades de un negocio, o
desarrollo de un producto que puede venderse para generar beneficios. Para conseguir
este objetivo, un sistema basado en computadoras hace uso de seis elementos
fundamentales.
Hardware, que son los dispositivos electrónicos y electrodomésticos que
proporcionan capacidad de cálculos y función rápida.
Software, que so programas de computadoras, con estructuras de datos u su
documentación que hacen efectiva la logística metodología de información o
controles de requerimientos del programa.
Personas, son los operadores o usuarios directos de las herramientas de los
sistemas y recolección de información.
Bases de Datos, una gran colección de información organizada y alcanzada a
los sistemas a las que se accede por medio del Software.
Documentación, manuales, formularios y otra información descriptiva que
detalla o da instrucciones sobre el empleo y operación del programa.
Procedimientos, o pasos que define el uso específico de cada uno de los
elementos componentes de los sistemas y reglas de su manejo y mantenimiento.

28. BIBLIOGRAFIA
 https://sisteminformacii.wikispaces.com/Analisis+y+dise%C3%B1o+de+sist
ema+de+informacion
 Leer más: http://www.monografias.com/trabajos94/metodologia-analisis-
sistemas-informacion/metodologia-analisis-sistemas-
informacion.shtml#ixzz4PG8S9Th9
 https://es.wikipedia.org/wiki/Lenguaje_unificado_de_modelado
 http://dsingsistemasunefa.blogspot.com/2015/10/metodologia-de-james-
martin-y-uml.html
 http://myslide.es/design/metodologia-para-el-desarrollo-de-sistema-de-
informacion-segun-jeffrey-whitten.html
 https://www.ecured.cu/Proceso_unificado_de_desarrollo
 http://blogs.unellez.edu.ve/dsilva/files/2014/07/Kendall-y-Kendall.pdf
 adelsistema.blogspot.com/p/blog-page.html
 http://lametodologiarmm.blogspot.com/
 http://profesores.fi-b.unam.mx/carlos/aydoo/conceptos_oo.html
 http://salonvirtual.upel.edu.ve/mod/resource/view.php?id=6627&redirect=1
 http://mundoinformatico321.blogspot.com/2012/12/metodologia-del-
software-educativo-por.html
 http://www.clasey.260mb.com/teoriasis/ssm.pdf?i=1
 Leer más: http://www.monografias.com/trabajos91/fases-metodologia-
merinde-y-metodologia-moomh/fases-metodologia-merinde-y-metodologia-
moomh.shtml#ixzz4PGhyfPlO
 http://analisystems.blogspot.com/2010/12/merinde.html
 https://proyectosagiles.org/que-es-scrum/
 http://ingenieriadesoftware.mex.tl/52753_XP---Extreme-Programing.html