análisis, diseño, sistema

1. Instituto Universitario Politécnico
“Santiago Mariño”
Extensión Porlamar
Escuela: Ingeniería de Sistemas
Asignatura: Análisis y Diseño de Sistemas
Profesor: Ing. Diógenes Rodríguez Brito
Autor:
José Marcano
C.I.: 26.243.992
Porlamar, Julio 2017

2. En la actualidad para muchas organizaciones, los sistemas
de información basados en computadoras son el corazón
de las actividades cotidianas y objeto de gran consideración
en la toma de decisiones, las empresas consideran 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. 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, por eso se presenta un breve informe sobre los
métodos para el análisis y diseños de sistemas, esta
información se obtuvo mediante el análisis de información
electrónica y bibliográfica.

3. Es un modo, manera o forma de
realizar algo de forma sistemática,
organizada y/o estructurada. Hace
referencia a una técnica o conjunto de
Método
tareas para desarrollar una tarea.
En algunos casos se entiende también como la forma
habitual de realizar algo por una persona basada en la
experiencia, costumbre y preferencias personales.
Procede del latín methŏdus, que a su vez deriva del griego
μέθοδος.
Disponible en: https://www.significados.com/metodo/

4. 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.
Disponible en: https://nosotos.wordpress.com/metodologia/
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.

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

9. En UML 2.0 hay 13 tipos diferentes de diagramas. Para comprenderlos de
manera concreta, a veces es útil categorizarlos jerárquicamente, como se
muestra en la figura de la derecha. Los Diagramas de Estructura enfatizan
en los elementos que deben existir en el sistema modelado:
* Diagrama de clases
* Diagrama de componentes
* Diagrama de objetos
* Diagrama de estructura compuesta (UML 2.0)
* Diagrama de despliegue
* Diagrama de paquetes

10. Los Diagramas de Comportamiento enfatizan en lo que debe
suceder en el sistema modelado:
* * Diagrama de actividades
* Diagrama de casos de uso
* Diagrama de estados
Los Diagramas de Interacción son un subtipo de diagramas de
comportamiento, que enfatiza sobre el flujo de control y de datos entre los
elementos del sistema modelado:
Diagrama de secuencia
* Diagrama de comunicación, que es una versión simplificada del
Diagrama de colaboración (UML 1.x)
* Diagrama de tiempos (UML 2.0)
* Diagrama global de interacciones o Diagrama de vista de interacción
(UML 2.0)

11. Las fases del desarrollo de sistemas que soporta uml son: análisis de
requerimientos, análisis, diseño, programación y pruebas.
UML tiene casos de uso (use-cases) para capturar los
requerimientos del cliente. A través del modelado de casos de
uso, los actores externos que tienen interés en el sistema son
modelados con la funcionalidad que ellos requieren del sistema
(los casos de uso). Los actores y los casos de uso son
modelados con relaciones y tienen asociaciones entre ellos o
éstas son divididas en jerarquías. Los actores y casos de uso
son descritos en un diagrama use-case. Cada use-case es
descrito en texto y especifica los requerimientos del cliente: lo
que él (o ella) espera del sistema sin considerar la
funcionalidad que se implementará. Un análisis de
requerimientos puede ser realizado también para procesos de
negocios, no solamente para sistemas de software.

12. La fase de análisis abarca las abstracciones primarias (clases y objetos) y
mecanismos que están presentes en el dominio del problema. Las clases
que se modelan son identificadas, con sus relaciones y descritas en un
diagrama de clases. Las colaboraciones entre las clases para ejecutar los
casos de uso también se consideran en esta fase a través de los modelos
dinámicos en uml. Es importante notar que sólo se consideran clases que
están en el dominio del problema (conceptos del mundo real) y todavía no
se consideran clases que definen detalles y soluciones en el sistema de
software, tales como clases para interfaces de usuario, bases de datos,
comunicaciones, concurrencia, etc.
En la fase de diseño, el resultado del análisis es expandido a una solución
técnica. Se agregan nuevas clases que proveen de la infraestructura
técnica: interfaces de usuario, manejo de bases de datos para almacenar
objetos en una base de datos, comunicaciones con otros sistemas, etc. las
clases de dominio del problema del análisis son agregadas en esta fase.
El diseño resulta en especificaciones detalladas para la fase de
programación.

13. En esta fase las clases del diseño son convertidas a código en un lenguaje
de programación orientado a objetos. Cuando se crean los modelos de
análisis y diseño en UML, lo más aconsejable es trasladar mentalmente
esos modelos a código.
Normalmente, un sistema es tratado en pruebas de unidades, pruebas de
integración, pruebas de sistema, pruebas de aceptación, etc. las pruebas
de unidades se realizan a clases individuales o a un grupo de clases y son
típicamente ejecutadas por el programador. Las pruebas de integración
integran componentes y clases en orden para verificar que se ejecutan
como se especificó. Las pruebas de sistema ven al sistema como una
"caja negra" y validan que el sistema tenga la funcionalidad final que le
usuario final espera. Las pruebas de aceptación conducidas por el cliente
verifican que el sistema satisface los requerimientos y son similares a las
pruebas de sistema.

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

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

17. Según el Diccionario de la Real Academia de la Lengua Española en su
edición vigésimo segunda la palabra sistema significa “Conjunto de cosas
que relacionadas entre sí ordenadamente contribuyen a determinado
objeto”.
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 es
más acorde con los objetivos de este trabajo 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, Laudon y Laudon (2004) 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”.

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

19. • Hardware: Todas las piezas físicas de la computadora y sus periféricos,
dígase teclado, monitor, tarjeta madre, y los demás elementos que
conforman el equipo. Este equipamiento es utilizado para llevar a cabo
las tareas de entrada, procesamiento y salida.
• Software: Son los programas de computación mediante los cuales se
dirige las operaciones de una computadora.
• Bases de Datos: Una Base de Datos es una colección de datos
organizados en celdas. Este elemento se encuentra entre los más
importantes de un sistema de información informático.
• Redes: Se denomina así a la interconexión entre computadoras u otros
equipos informáticos para hacer posible la comunicación electrónica,
este elemento es muy importante ya que puede ser determinante en la
efectividad del sistema de información informático.

20. Un proceso de software detallado y completo suele denominarse
“Metodología”. Las metodologías se basan en una combinación de los
modelos de proceso genéricos (cascada, evolutivo, incremental,). El
Proceso Unificado se usa para describir el proceso genérico que incluye
aquellos elementos que son comunes a la mayoría de los refinamientos
existentes.
El Proceso Unificado de desarrollo puede ser dividido en cuatro fases:
Fase de Inicio.
Fase de Elaboración.
Fase de Construcción.
Fase de Transición.

21. En la ingeniería del software el término fases de desarrollo expresa cómo
ha progresado el desarrollo de un software y cuánto desarrollo puede
requerir. Cada versión importante de un producto pasa generalmente a
través de una etapa en la que se agregan las nuevas características (etapa
alfa), después una etapa donde se eliminan errores activamente (etapa
beta), y finalmente una etapa en donde se han quitado todos los bugs
importantes (etapa estable). Las etapas intermedias pueden también ser
reconocidas. Las etapas se pueden anunciar y regular formalmente por los
desarrolladores del producto, pero los términos se utilizan a veces de
manera informal para describir el estado de un producto. Normalmente
muchas compañías usan nombres en clave para las versiones antes del
lanzamiento de un producto, aunque el producto y las características reales
son raramente secretas

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

23. 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.
• Estimar el alcance del proyecto.
• Identificar si existe una necesidad,
problema u oportunidad
argumentada.
• Documentar resultados.
• Estudiar los riesgos del proyecto.
• Presentar un informe de vialidad.
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.
• Recolectar información sobre los
procedimientos y operaciones que
se desempeñan actualmente.

24. 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.
• Elaborar el diseño de la base de
datos.
• Diseñar las diferentes interfaces de
usuarios de cada operación,
procedimiento y/o función.
• Diseñar controles y procedimientos de
respaldos que protejan al sistema y a
los datos.
• Producir los paquetes específicos de
programas para los programadores.
• Elaborar una lista de las funciones
genéricas y de las que será
obligatorio crear.
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.
• Elaborar diagramas de procesos de
cada función.
• Elaborar propuesta del sistema con
todos los diagramas de operaciones y
de procesos.
• Realizar el análisis del riesgo sobre el
realizado en las fases anteriores,
tomando en cuenta el aspecto
económico, técnico y operacional
(estudio de factibilidad)
• Estimar en un diagrama de Gantt el
tiempo que tomará desarrollar el
sistema.

25. 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.
• El analista deberá realizar un informe
de sus pruebas y discutirlo con el
programador.
• Elaborar la planificación de las horas
del mantenimiento del sistema.
Elaborar la lista de las operaciones
que pudieran sufrir modificaciones de
códigos.
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.
• Elaborar manuales externos de
ayuda a los usuarios del sistema.
• Elaborar demostraciones para los
usuarios y la interacción con
distintas interfaces.
• Elaborar actualizaciones para los
diferentes procedimientos. Elaborar
un informe con el tiempo que se
llevó construir cada procedimiento.

26. 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.
• Evaluar la adaptabilidad de los usuarios al sistema.
• 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.

27. 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 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
(trozo) con el fin de modelizar los aspectos unidos a la presentación de las
entidades. Un slice corresponde a un subconjunto de atributos de una misma
entidad destinados a ser presentados de forma agrupada.

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

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

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

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

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

33. Los Sistemas Expertos se han definido como aquellos
programas que se basan en el conocimiento y tratan de imitar el
razonamiento de un experto para resolver un problema de un tópico
definido. Su comportamiento se basa generalmente en reglas, es
decir, se basa en conocimientos previamente definidos, y mediante
estos conocimientos, los SE son capaces de tomar decisiones.
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.

34. Para que un sistema experto sea herramienta efectiva, los usuarios
deben interactuar de una forma fácil, reuniendo dos capacidades para poder
cumplirlo:
1. Explicar sus razonamientos o base del conocimiento: los sistemas
expertos se deben realizar siguiendo ciertas reglas o pasos comprensibles de
manera que se pueda generar la explicación para cada una de estas reglas,
que a la vez se basan en hechos.
2. Adquisición de nuevos conocimientos o integrador del sistema: son
mecanismos de razonamiento que sirven para modificar los conocimientos
anteriores. Sobre la base de lo anterior se puede decir que los sistemas
expertos son el producto de investigaciones en el campo de la inteligencia
artificial ya que ésta no intenta sustituir a los expertos humanos, sino que se
desea ayudarlos a realizar con más rapidez y eficacia todas las tareas que
realiza.
Debido a esto en la actualidad se están mezclando diferentes técnicas o
aplicaciones aprovechando las ventajas que cada una de estas ofrece para
poder tener empresas más seguras. Un ejemplo de estas técnicas sería los
agentes que tienen la capacidad de negociar y navegar a través de recursos
en línea; y es por eso que en la actualidad juega un papel preponderante en
los sistemas expertos.

35. Es una metodología de desarrollo de software que contempla una
serie de fases o etapas de un proceso sistemático atendiendo a: análisis,
diseño, desarrollo, prueba y ajuste, y por último implementación.
• Etapa 1: Análisis. Características de la población objetivo: edad (física y
mental), sexo, características físicas y mentales (si son relevantes),
experiencias previas, expectativas, actitudes, aptitudes, intereses o
motivadores por aprender. Conducta de entrada y campo vital: nivel escolar,
desarrollo mental, físico o psicológico, entorno familiar y escolar, etc.
• Etapa 2: Diseño:
 Educativo (este debe resolver las interrogantes que se refieren al
alcance, contenido y tratamiento que debe ser capaz de apoyar el
Sistema Educativo).
 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).

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

37. SSM de Peter Checkland es una metodología sistémica fundamentada
en el concepto de perspectiva o en el lenguaje de la metodología
“Weltanschauung”. Un “weltanschauung” representa la visión propia de un
observador, o grupo de ellos, sobre un objeto de estudio, visión ésta que afecta
las decisiones que el(los) observador(es) pueda(n) tomar en un momento dado
sobre su accionar con el objeto. La SSM toma como punto de partida la
idealización de estos “weltanschauung” para proponer cambios sobre el
sistema que en teoría deberían tender a mejorar su funcionamiento.

38. 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.
La metodología propuesta MeRinde se organiza en disciplinas. Las disciplinas
poseen flujos de trabajos en donde cada uno conlleva a actividades (ver
primera figura) que a su vez están compuestos por un conjunto de tareas (ver
segunda figura) realizadas en un área determinada, las cuales tienen como
objetivo producir artefactos. A su vez, en MeRinde existen actividades que se
dividen en subactividades (ver tercera figura) con el fin de facilitar la agrupación
de tareas relacionadas. Las disciplinas que conforman esta metodología se
fundamentan en las propuestas por RUP, las cuales se dividirán en dos grupos.
El primero comprende las disciplinas fundamentales asociadas con las áreas de
ingeniería:

39. •Modelado del Negocio
•Requerimientos
•Análisis y Diseño
•Implementación
•Pruebas
•Implantación
El segundo grupo lo integran aquellas
disciplinas llamadas de soporte o gestión:
•Gestión de Configuración y Cambios
•Gestión del Proyecto
•Gestión del Ambiente
Fases:
•Fase de Inicio
•Fase de Elaboración
•Fase de Construcción
•Fase de Transición

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

43. Un proyecto de desarrollo de un Sistema de Información comprende
varios componentes o pasos llevados a cabo durante la etapa del
análisis, el cual ayuda a traducir las necesidades del cliente en un
modelo de Sistema que utiliza uno más de los componentes: Software,
hardware, personas, base de datos, documentación y procedimientos.
La función del Análisis puede ser dar soporte a las actividades de un
negocio, o desarrollar un producto que pueda venderse para generar
beneficios.

44. (s/f). Método. Recuperado el 04/07/2017. Disponible en:
http://www.significados.com/metodo/
(s/f). Metodología. Recuperado el 04/07/2017. Disponible en:
https://nosotos.wordpress.com/metodologia/
(s/f). Métodos de Sistemas. Recuperado el 04/07/2017. Disponible en:
http://articulacion.simonrodriguez.org.ve/lval/index.php/Metodologia
(s/f). Programación Extrema XP. Recuperado el 04/07/2017. Disponible en:
http://ingenieriadesoftware.mex.tl/52753_xp---extreme-programing.html