Informe 5% II corte

1. Instituto universitario Politecnico Santiago Mariño
Escuela: Ingeniería de Sistemas.
Extensión Porlamar
4A Análisis y diseño de sistemas
Metodologías para el Análisis y Diseño de Sistemas
Realizado por:
Domingo García CI: 19.896.287
Prof. Lcdo. Jhonatan
Porlamar, Mayo 2015

2. 1. Definición de:
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.
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).
• 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

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

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

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

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

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

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

9. 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.
• Metodología de Kendall y Kendall.

10. “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.
FASE II: 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.

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

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

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

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

15. Implementación. Las clases de objetos y relaciones desarrolladas
durante el análisis de objetos se traducen finalmente a una implementación
• 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.
• 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.

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

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

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

19. Referencias Bibliográficas y Electrónicas Completas
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://franklinmorillouba.blogspot.com/2010/11/metodologia-orientada-
objetos-fases-y.html
http://mundoinformatico321.blogspot.com/2012/12/metodologia-del-software-
educativo-por.html
http://www.softeng.es/es-es/empresa/metodologias-de-trabajo/metodologia-
scrum.html