Metodologia

SISTEMAS DE INFORMACIÓN
▼
lunes, 26 de junio de 2017
METODOLOGÍA MEDSI
UNIVERSIDAD NORORIENTAL PRIVADA

GRAN MARISCAL DE AYACUCHO
EL TIGRE- EDO. ANZOÁTEGUI
Maestría en Ciencias Gerenciales Mención Recursos Humanos

Asignatura: Sistemas de Información y documentación.
Unidad II. Metodología de Medsi.
Facilitador: MSc. Juan Hernández
AUTORES:
Ing. Gómez Jairo C.I 14.517.299
Lcdo. Lista Francisco C.I. 23.512.599
Abg. Marcano Keilymar C.I. 25.268.984
Abg. Mendoza Agustín C.I. 22.862.246
Abg. Ortiz Yarlenis C.I. 12.893.301
Lic. Soto María C.I:19.629.512
El Tigre, Junio del 2017
METODOLOGÍA MEDSI
1.- Definición de la metodología de Medsi.
Es aquella metodología estructurada que se utiliza para desarrollar sistemas de
información en y para organizaciones de cualquier tipo. Dentro de las
características más importantes de esta metodología podemos mencionar:
ü ES ESTRUCTURADA: Se considera estructurada por la utilización de

diferentes métodos y técnicas estructuradas, que son propias de la Ingeniería de la
Programación, y que han demostrado ser las más eficientes y eficaces para el
desarrollo de sistemas programados.
Guía paso a paso de arriba hacia abajo el grupo que la aplica explicando
primero de forma muy general lo que debe hacerse para luego entrar en
los detalles, a medida que se avanza hasta explicar las tareas esenciales que el
grupo debe llevar a cabo para realizar el sistema de información
ü ES COMPLETA. Cubre todas las distintas fases del ciclo de desarrollo de un
sistema de información, desde la definición del proyecto hasta la implantación del
sistema en la organización. Guía al grupo de desarrollo a través de las fases, a un
nivel bastante detallado, explicando las actividades que deben hacerse y en la
mayoría de los casos, enumerando las tareas específicas que los miembros del
grupo deben efectuar.
ü ES PARTICIONADA. Para un mejor manejo de la metodología se divide en
fases, y cada una de las fases está compuesta por pasos los cuales están orientados
a algún tipo de tópicos, aspecto o elemento de un sistema de información. Cada
paso a su vez agrupa a un conjunto de actividades que han de ser realizadas por el
grupo de desarrollo.
2.-Diagramas Utilizados en MEDSI

Los diagramas utilizados en esta metodología, para explicar las diferentes fases
están basados en la técnica de análisis Estructurado de Sistemas, y corresponden
a lo que, en términos de esa técnica, recibe el nombre de diagramas de flujo de
Datos. Además está orientada a proyectos medianos y grandes, que a meriten la
integracion de grupos de desarrollo conformados por tres o más personas que
puedan requerir para su desarrollo varios meses.
3.- Fases de la Metodología.
Fase I. Definición del Proyecto:
Esta fase consiste en determinar si es factible o no el desarrollo del sistema

informativo, se realiza un diagnóstico de acuerdo a los gastos, tiempo y recursos
que genera, de tal manera que se tome la decisión para desarrollar o no el
proyecto. Dentro de esta fase encontramos los siguientes pasos:
Estudio Preliminar del proyecto: este estudio muestra de manera general si se
justifica o no desarrollar un sistema de información para satisfacer las necesidades
de las unidades interesadas. Se deben realizar las siguientes actividades:
1.1.-Reconocer el problema: Se deben efectuar todas las acciones necesarias para
reconocer que existe un problema. Los pasos que deben realizarse en esta actividad
son:
Recopila y analizar aquellos elementos que indiquen la necesidad de un nuevo
sistema.
Realizar reuniones preliminares con el personal de las unidades involucradas para
definir la necesidad de un cambio.
1.2.- Formular el problema. Permite diagnosticar de modo muy general, el sistema
actual, en el caso de que exista, determinando las necesidades preliminares que
puedan o no justificar el desarrollo del nuevo sistema.
2. Elaborar el informe preliminar. Una vez realizado el análisis anterior, el

gerente debe elaborar un informe que resuma los resultados de las actividades
anteriores, el cual debe concluir si existen o no necesidades y problemas actuales
que justifiquen emprender el desarrollo de un nuevo sistema. Dicho informe lo
presentara el gerente a los directivos de las unidades involucradas quienes deciden,
a partir de ese informe, si se emprende el proyecto o no, o si es necesario un mayor
estudio.
3. Discutir el informe Preliminar.
4. Planificar el estudio de factibilidad.
5. El estudio de factibilidad. Se debe estudiar junto con el grupo seleccionado
para este paso, la factibilidad técnica, económica y psicosocial de diferentes
alternativas que puedan constituir soluciones aceptables al problema actual.
6. Determina factibilidad técnica: Para cada sistema alternativo se debe
establecer su factibilidad técnica, planteándose si es posible desarrollar el sistema
propuesto con la tecnología actual o existente, y qué tecnología adicional debe
adquirir la organización. Para ello es necesario:
· Determinar factibilidad económica. Se debe realizar un análisis costo –

beneficio que permita identificar y medir los costos de desarrollo de operación y
los beneficios que obtiene la organización de cada sistema alternativo; para luego
comparar las diferentes alternativas bajo un criterio económico.
· Determinar factibilidad psicosocial. Este informe describe cada sistema
alternativo y resume su factibilidad técnica, económica psicosocial.
7. Elaborar informe de factibilidad:
8. Discutir el informe de factibilidad: El gerente del proyecto presenta el

informe a la comisión de planificación, quienes junto con los otros directivos de las
unidades involucradas discuten la factibilidad de cada alternativa y selecciona la
más conveniente. Planificación del Proyecto.
9. Planificación del Proyecto: Con la decisión de continuar con el proyecto y de
la selección de un enfoque alternativo para el nuevo sistema de información, el
gerente del proyecto se dedica a planificar el mencionado proyecto, tratando de
estimar los costos, tiempos y recursos para llevarlo a cabo. Elaborando un
documento que guíe el desarrollo del proyecto y que denominaremos el PLAN DE
PROYECTO.
Fase II. Análisis del Contexto:

Se hace un análisis de los problemas que presenta y que puedan ser mejorables
con la construcción del sistema automatizado, es decir cambiar el registro manual
que se utiliza actualmente por un registro sistematizado. En el cual se ubicará el
nuevo sistema de información y determinar las deficiencias. En esta fase
encontramos los siguientes pasos:
1. Análisis documental: Desarrollar y disponer de una biblioteca organizada de
documentos relativos al proyecto. Una vez constituida la biblioteca, el grupo se
ocupa de estudiar la documentación propia del sistema con miras a obtener una
primera aproximación al conocimiento del citado sistema y sobre todo al contexto
que lo contiene.
2. Análisis del Contexto: Este paso constituye un estudio formal de todo el
sistema, con un nivel de detalle más profundo que aquellos realizados
anteriormente. Su objetivo es permitirle al grupo de desarrollo conocer el sistema
actual y su contexto para luego modelarlo y sobre el modelo identificare las
situaciones problemáticas que el sistema presenta. Para ello se utiliza la técnica de
análisis estructurado de sistemas que permite elaborar los modelos físicos y lógicos
del sistema de información. Puede realizarse mediante la construcción de los
diagramas de flujo de datos del modelo físico y lógico.
3. Construir el modelo del sistema actual de Información: Para ello se utiliza la
técnica de análisis estructurado de sistemas que permite elaborar los modelos
físicos y lógicos del sistema de información.
4. Elaborar el informe del sistema actual: Este informe resume los resultados de
las actividades anteriores, mediante una descripción del ambiente y del mismo
sistema, la presentación del modelo y la descripción de los problemas que presenta
el actual sistema.
Fase III. Definición de requerimientos:
Se define la información que se tiene de la Empresa, así como las limitaciones y

propiedades que debe ofrecer el sistema. Especificando los requerimientos de los
usuarios y establecer las funciones, restricciones y atributos que el nuevo sistema
de información.
1. Especificación de Requerimientos de Información: El grupo de desarrollo se
encarga de especificar junto con el usuario del nuevo sistema las salidas, las
entradas y las estructuras necesarias de datos. Dichos requerimientos son los de
entrada, salida y de almacenamiento.
2. Construir el libro de requerimientos de información: Los requerimientos se
agrupan e divisiones de acuerdo al tipo señalado en la actividad anterior. La
división de requerimientos de salida se organiza por sesiones. Cada sesión contiene
los requerimientos de información de una unidad funcional que esta involucrada
en el sistema.
3. Especificación de Restricciones y Atributos: En este paso, el grupo de
desarrollo establece junto con los usuarios las restricciones bajo las cuales se deben
desarrollar y debe operar el sistema de información. Así mismo se establece
también, la interaccion que debe haber entre el hombre, el computador y los
atributos de calidad que se la van a imponer al mencionado sistema de
información.
Económica: Que cantidad de dinero se dispone para mantener el sistema.
Técnicas: Que equipo debe o puede utilizarse.
De personal: De que personal se dispone para mantener y operar el sistema.
Legales: Las politicas, reglamentos, normas, leyes, etc, tanto internas como
externas deben acatarse.
4. Determinar interacción hombre – máquina: Esta actividad es esencial pues
define la comunicación que debe haber entre los usuarios y el computador a través
del subsistema programado.
5. Determinar atributos de calidad: Entre algunos de los atributos de calidad se
destacan las siguientes: Confiabilidad, Grado de prueba, Movilidad,
Adaptabilidad, Mantenimiento requerido, Seguridad y privacidad, Eficiencia y
rendimiento y Documentación.
Fase IV. Diseño Preliminar:
Esta fase consiste en elaborar un diseño preliminar del sistema de información

que satisfaga los requerimientos, restricciones y atributos establecidos en la fase
III. El diseño preliminar consta de un prototipo o modelo físico que delinea la
interacción hombre- máquina del sistema de información y describe, en forma
general sus procesos automatizados. Dentro de esta fase encontramos:
1. Definición de prototipos: Se elabora diferentes prototipos que puedan
satisfacer la especificación funcional, las restricciones y los atributos identificados
en la fase anterior, mediante la solicitud de precios y especificaciones técnicas de
los equipos o programas que hagan falta, a los diferentes vendedores del mercado.
Se rige por la estructura o configuración global del sistema de información, en ella
se indica si el diseño del sistema ha de ser independiente, centralizado o
distribuido. Partiendo de este enfoque, se establecen diferentes configuraciones
para el procesamiento y para la interacción que existirá entre el hombre y la
máquina.
1. Elaborar diferentes prototipos alternativos.
2. A partir del modelo lógico del nuevo sistema y de las restricciones y atributos
establecidos anteriormente, el grupo desarrolla diferentes prototipos, el cual va
indicar que procesos son manuales y cuales automáticos. El prototipo muestra
también los procedimientos de activación del subsistema programado, los de
respaldo y recuperación de fallas y los de seguridad de la base de datos.
3. Evaluar configuración técnica existente.
4. Determinar configuración técnica necesaria.
5. Realizar un análisis costo – beneficio.
6. Para cada prototipo se determina sus costos de desarrollo y operaciones y se
estima los beneficios que puedan obtenerse. Se comparan los diferentes prototipos
bajo un criterio económico Discutir informe de prototipos.
7. Adquirir tecnología necesaria.
2. Selección de prototipos: Se realiza un análisis de costo beneficio para los

diferentes prototipos definidos en el paso anterior. De los resultados de este
análisis se presenta y discute con la comisión de planificación, quién decide
posteriormente el prototipo más conveniente y da las instrucciones necesarias para
la adquisición de la tecnología que haga falta.
1. Refinar prototipo.
2. Cada proceso automático del prototipo se refina mediante la descomposición
funcional establecida por la técnica AES. Cada proceso del mas bajo nivel debe
describirse utilizando cualquier de las técnicas siguientes: algoritmos
estructurados, tablas de decisión o árboles de decisión. Los entes del diccionario
de datos que se vean afectados por la automatización deben ser actualizados
durante esta actividad. El modelo o prototipo obtenido en la actividad anterior se
somete a una revisión estructurada o a una inspección de diseño.
3. Revisar Prototipo.
4. Elaborar informe de diseño preliminar.
5. Planificar detalles de la próxima fase.
3. Refinamiento de Prototipo: En este proceso se refinar el prototipo escogido,

es decir, se describen con mayor detalle aquellos procesos del prototipo que sean
automáticos, siguiendo la técnica de análisis estructurado de sistema.
Fase V. Diseño detallado:

Consiste en elaborar un diseño especificando los diferentes componentes del
sistema, tomando como referencia el modelo preliminar el registro manual llevado
actualmente el cual contiene la especificación de todos los datos necesarios para
diseñar el sistema, es decir los datos que serán registrados.
1. Diseño de Entradas y Salidas. Se elabora minuciosamente el diseño de la
interacción entre el hombre y la máquina, la cual ha sido delineada en el prototipo
del sistema. mediante la estructuración o formato de cada pantalla de entrada de
datos al sistema y de salida de información a los usuarios.
2. Diseño de Datos: Este diseño del subsistema de datos del sistema de
información gira en torno a el diseño de la (s) base (s) de datos necesaria (s) para
almacenar los datos de dicho sistema y el diseño de los programas que permitirán
crear y cargar la (s) base (s) de datos, es decir, se realiza el diseño lógico de la base
de datos.
Las tareas que realiza el grupo para elaborar un modelo de datos son:
ü Analizar los flujos de datos que entran y salen de cada archivo del prototipo del
sistema.
ü Derivar la (s) estructura (s) de datos contenida (s) en cada archivo, identificando
las entidades que representa y los atributos que poseen.
ü Establecer las relaciones que existan entre las diferentes entidades y construir el
modelo de entidad-relación correspondiente.
ü Si el SMBD (sistema manejador de base de datos) que se valla a utilizar
manipula base de datos relacionales, entonces cada entidad del modelo entidad-
relación debe ser normalizada hasta por lo menos la tercera forma normal.
ü Verificar si el modelo de datos obtenido satisface todos y cada uno de los
requerimientos detallados en el libro de requerimientos.
3. Diseño de programas y procedimientos. El subsistema programado se diseña

como una estructura jerárquica compuesta por una o más programas, cada uno de
estos se compone a su vez de módulos un módulo se define como una unidad de
programa que se caracteriza por lo siguiente:
Posee un nombre propio y único.
Ejecuta una función claramente especificable.
Puede compilarse y catalogarse en forma catalogada.
Puede definir y mantener un conjunto propio de variables locales se llama o invoca
de otro modulo.
· Diseñar la documentación y los procedimientos manuales.
4. Ensamblaje del paquete de diseño. Este paso se basa en revisar y ensamblar
el conjunto de especificaciones de diseños producidas en los anteriores, con el
propósito de garantizar la consistencia, calidad y exactitud del diseño e integrar lo
que hemos denominado como paquete de diseño. Ensamblar el paquete de diseño
contiene:
Ø El prototipo del sistema.
Ø La configuración y documentación del equipo que se va a emplear.
Ø Las especificaciones de entrada y salida.
Ø La especificación del subsistema programado.
Ø La especificación del subsistema de datos.
Ø Cualquier otro material que fuese necesario
5. Planificación de pruebas. Las actividades concernientes a esta fase se
desarrolla a lo largo de esta metodología, por otro lado es evidente que muchas de
las actividades de prueba se pueden realizar en paralelo con actividades de fase
tales como las de diseño y construcción del sistema. Bajo este criterio, podemos
dividir las actividades generales de las pruebas en: Planificación de las pruebas,
diseño y construcción de las pruebas y ejecución de las pruebas.
Fase VI. Construcción del sistema.

Esta fase permite la Construcción del subsistema de datos y el subsistema
programado del sistema de información de acuerdo a lo planteado en el diseño.
En esta fase se construyen y se prueban los diferentes módulos del subsistema
programado; se construye subsistema de datos y los procedimientos manuales del
sistema.
1.- Diseño y construcción de las pruebas: Se especifican los detalles de cada una de
las pruebas que se han identificado en el plan de prueba y de construir los
mecanismos requeridos para ejecutar cada una de ellas:
Identificación.
Objetivos.
Requerimientos.
Criterio de éxito.
Técnica de procedimientos.
Casos de pruebas.
2.- Realizar una revisión estructurada de las pruebas: Se trata de la codificación
de los programas.
3.- Construir los mecanismos y preparar los datos de pruebas:
Después de realizar las especificaciones de pruebas anteriormente elaboradas,
se construye los ejecutivos y los esqueletos diseñados en cada una de ellas y si el
volumen de datos de prueba, es considerable, entonces prepara los archivos de
datos que ser demandes. Los mecanismos de prueba, junto con los datos, los
almacena el bibliotecario para su uso posterior de su respectiva prueba.
3.1 Creación de la base de datos. Para ello se debe realizar las siguientes
actividades:
· Elaboración de la Documentación y de los procedimientos manuales y de
control de programas. Para ello se deben realizar las siguientes actividades:
· Elaborar los manuales.
· Elaborar las planillas, los instructivos.
· Evaluar la documentación.
· Elaborar los procedimientos de control de programas.
3.2 Prueba de unidades. Las prueba de cada módulo especificado es realizada por
el mismo programador que lo codifico. Las actividades de pruebas de unidades se
dividen en:
· Discutir las especificaciones de prueba.
· Ejecutar las pruebas de unidades.
· Generar automáticamente la librería de programas.
· Almacenar los módulos en la librería.
· Mantener actualizada la librería.
Fase VII. Control de Programas.
Consiste en realizar las pruebas a los diferentes procedimientos de lenguajes de

control de tareas que se hayan utilizado. Entre las diferentes pruebas de los
subsistemas mencionamos:
Prueba del sistema de información: Se verificar el sistema de información, la
prueba de sistema fue diseñada para localizar discrepancias o anomalías entre el
sistema de información recientemente construido, y los objetivos y requerimientos
inicialmente establecidos con los usuarios del sistema. Requiere de los siguientes
pasos:
Ejecutar la prueba del sistema.
Elaborar y discutir el informe de pruebas.
Elaborar el plan de implantación.
Preparación para la implantación: Este plan programa todas las actividades y
tareas que debe llevar a cabo el grupo de desarrollo durante la implantación del
sistema en la organización. Debe contener:
Objetivos.
Calendario de actividades.
Estrategias.
Procedimientos.
3. Preparar el material de adiestramiento Después de identificar el tipo de
adiestramiento que se va a aplicar para capacitar a los usuarios en el uso y
operación del sistema, el grupo de desarrollo debe elaborar planes de capacitación
al personal que labora en la organización.
Fase VIII. Prueba de Aceptación.

Se procede a poner en operación y a efectuar la prueba de aceptación del
sistema respectivamente. Esta prueba se realiza luego que el grupo de desarrollo
ya adiestrado a todos los usuarios en el uso, es decir; se realiza la conversión del
sistema anterior al nuevo, mediante la actualización de la base de datos y el inicio
de las actividades propias del sistema de información. Finalmente se realiza la
entonación y la evaluación del sistema recientemente instalado.
Al realizar estos dos últimos pasos, la labor del todo el personal que participo en
el proyecto puede considerarse terminada, marcando así el fin del proyecto de
desarrollo y el inicio de una nueva etapa del ciclo de vida del sistema de
información: la etapa de operación y mantenimiento.
Adiestramiento de usuarios:
Organizar las sesiones de adiestramiento.
Conducir las sesiones de adiestramiento.
Esta prueba final del sistema la realiza el grupo de prueba con la finalidad de
demostrarle a las unidades involucradas que el sistema desarrollado satisface el
criterio mínimo de aceptación que ellos han establecido.
· Preparar la prueba de aceptación.
· Realizar la Prueba de aceptación.
2. Prueba de aceptación: En esta etapa final consiste en preparar detalles para

la conversión y realizar la conversión del sistema, este es el paso más delicado de
esta fase, de tal manera que se inicia, como tal la operación del nuevo sistema y se
abandona el sistema anterior. Previo al inicio de las actividades rutinarias del
sistema de información.
CASO PRÁCTICO.
Fase I. Definición del proyecto.

SISTEMA DE INFORMACION PARA LA GESTION DE LAS CONSTANCIAS
DE TRABAJO DEL PERSONAL ADMINISTRATIVO, DOCENTE Y OBRERO
DE LA UPTJAA, SEDE EL TIGRE- ESTADO ANZOÁTEGUI.
Tomando en cuenta que en esta fase de la metodología se debe realizar un

estudio general de la unidad donde se requiera aplicar el sistema, analizando la
información suministrada por la misma, a través de un estudio de factibilidad.
Este sistema se aplicara en el Departamento de Recursos Humano de la
Universidad Politécnica Territorial “José Antonio Anzoátegui” sede El Tigre, la
cual se encuentra ubicada en el Km 08, Carretera Nacional El Tigre- Ciudad
Bolívar, está referido a la gestión de las Constancias de Trabajo que se le entrega
al personal, administrativo, docente y obrero de la Institución.
En cuanto a la solicitud de la Constancias de Trabajo por parte del personal de
dicha institución se ha venido presentando dificultades que retrasan este proceso,
ya que al momento de realizar el requerimiento por el solicitante ante el
departamento de RRHH las dificultades más comunes que se presenta en este
caso, en primer lugar ubicar al trabajador específicamente en el área o unidad al
que se encuentra asignado, verificar si es un trabajador fijo o contratado y debido
a la cantidad de solicitudes que se realizan por periodos se retrasa la entrega al
solicitante. Es por ello, la factibilidad de implementar el Sistema que permita
agilizar la entrega de las Constancia del Personal en tiempo requerido.
Actualmente este departamento cuenta con un (1) equipo de computación que
cubre con esta necesidad, por lo tanto se requiere de otra computadora, debido a
que esta no solo es para la emisión de constancia sino que cumple con diferentes
funciones lo que a su vez retrasa este proceso. Tomando en cuenta que la
adquisición de un equipo por parte de la universidad necesita de un tiempo
prolongado, la unidad debe realizar una requisición enviada al Departamento de
Administración para verificar si hay disponibilidad presupuestaria, su aprobación
y luego una vez que se apruebe proceder con la compra, todo esto requiere de
aproximadamente dos meses para adquirir la computadora.
Factibilidad de Personal:
En el departamento de RRHH para el suministro de las constancias se cuenta
con una persona (personal administrativo de la Institución), por lo tanto para la
aplicación del sistema se necesita:
· Un personal Administrativo encargado
· Con un cargo de T1
· Salario básico de 101.218,00 Bs
Factibilidad Psicosocial: Tomando en cuenta las necesidades del departamento

de Recursos humanos de acuerdo a la información suministrada por medio de
entrevista al personal de la misma en cuanto a la aplicación del sistema, se generan
una serie de interrogantes:
¿En qué consiste el sistema?
¿Es necesaria la aplicación de este sistema en el departamento de RRHH?
¿Quiénes se beneficiaran con la aplicación del sistema?
Factibilidad legal: En bases a los principios legales que sustentan este trabajo en la
Ley del Trabajo, Las Trabajadoras y los Trabajadores, en el Capítulo IV referido
a las Invenciones, Innovaciones y mejoras en su artículo 323 establece: ..”Se
considerarán invenciones, innovaciones o mejoras de servicio aquellas realizadas
por trabajadores contratadas por el patrono”….
De tal manera, que las mejoras que se realicen en el departamento para el
bienestar o mejoras del trabajo se encuentra enmarcadas en las leyes por lo tanto
deben seguirse con los lineamientos estipuladas en esta.
Factibilidad Técnica:
Actualmente en el Dpto. de RRHH (Uptjaa)
Aplicación del sistema (Necesidad)
HARDWARE
Procesador: Intel (R) Celeron (R) D CPU3.0 GHz
Memoria: (RAM) 2.5 GB
1 Disco duro de 80GB.
1 Mouse
1teclado
1 monitor de 17”
1 impresora con cable interface
1 UPS
SOFTWARE
Sistema Operativo Windows 7 de 32 bits
Programa Visual Basic
Fase II. Análisis del Contexto.
Se realiza un estudio más formal a través de la descripción detallada del proceso

anterior. El departamento objeto de estudio en la actualidad realiza el proceso
para la entrega de las constancias de la siguiente manera: el solicitante una vez en
el Departamento de RRHH realiza el requerimiento a la persona encargada, donde
debe anotarse de manera manual en una libreta ingresando sus datos (Nombres y
Apellidos, Cédula de identidad, indicar si la constancia es con salario base o
integral y el tipo de personal), luego el funcionario encargado le indicara de
acuerdo a los requerimiento que tenga, el día para retirar la constancia.
Una vez que se tenga los datos del trabajador se van ingresando los datos a través
de un formato en Word. Luego se imprime para ser entregada a la persona
solicitante.
Fase III. Definición de Requerimientos.
?
En esta fase se realiza de manera detallada la especificación de los
Requerimientos de Información, explicando en el nuevo sistema las salidas, las
entradas y las estructuras necesarias de datos. En el caso planteado se presenta de
la siguiente manera:
Requerimientos de Entrada: Cédula de Identidad, cargo, nombres y apellidos del
trabajador, fecha de ingreso, sueldo, grado de instrucción, fecha de ingreso, tipo
de trabajador docente o administrativo, estatus del empleado: contratado, fijo o
jubilado.
Requerimientos de Salida: Son los diferentes tipos de reportes que muestra el

programa estos pueden ser visibles en pantalla o impresos:
· Reportes de Constancias de trabajo.
· Reporte de Consulta de sueldo de Trabajadores docentes y administrativos
en condición fija, jubilado o contratado.
· Reporte de Consulta de cargos de Trabajadores docentes y administrativos
en condición fija, jubilado o contratado.
· Reporte de Consulta de grado de instrucción de Trabajadores docentes y
administrativos en condición fija, jubilado o contratado.
FASE IV. Diseño Preliminar.

Esta fase consiste en elaborar un diseño preliminar del sistema de información que
satisfaga los requerimientos, restricciones y atributos establecidos en la fase III. El
diseño preliminar consta de un prototipo o modelo físico que delinea la interacción
hombre- máquina del sistema de información y describe, en forma general sus
procesos automatizados. Dentro de esta fase encontramos:
satisfacer la especificación funcional, las restricciones y los atributos identificados
en la fase anterior, mediante la solicitud de precios y especificaciones técnicas de
los equipos o programas que hagan falta, a los diferentes vendedores del mercado.
Se rige por la estructura o configuración global del sistema de información, en ella
se indica si el diseño del sistema ha de ser independiente, centralizado o
distribuido. Partiendo de este enfoque, se establecen diferentes configuraciones
para el procesamiento y para la interacción que existirá entre el hombre y la
máquina.
2. A partir del modelo lógico del nuevo sistema y de las restricciones y atributos
establecidos anteriormente, el grupo desarrolla diferentes prototipos, el cual va
indicar que procesos son manuales y cuales automáticos. El prototipo muestra
también los procedimientos de activación del subsistema programado, los de
respaldo y recuperación de fallas y los de seguridad de la base de datos.
6. Para cada prototipo se determina sus costos de desarrollo y operaciones y se
estima los beneficios que puedan obtenerse. Se comparan los diferentes prototipos

diferentes prototipos definidos en el paso anterior. De los resultados de este
análisis se presenta y discute con la comisión de planificación, quién decide
posteriormente el prototipo más conveniente y da las instrucciones necesarias para
la adquisición de la tecnología que haga falta.
2. Cada proceso automático del prototipo se refina mediante la descomposición
funcional establecida por la técnica AES. Cada proceso del mas bajo nivel debe
describirse utilizando cualquier de las técnicas siguientes: algoritmos
estructurados, tablas de decisión o árboles de decisión. Los entes del diccionario
de datos que se vean afectados por la automatización deben ser actualizados
durante esta actividad. El modelo o prototipo obtenido en la actividad anterior se
somete a una revisión estructurada o a una inspección de diseño.
3. Refinamiento de Prototipo: En este proceso se refinar el prototipo escogido,

es decir, se describen con mayor detalle aquellos procesos del prototipo que sean
automáticos, siguiendo la técnica de análisis estructurado de sistema
Fase V. Diseño Detallado.
De manera estándar las pantallas están diseñadas con el nombre del programa
(sistema de constancias de trabajo), los botones minimizar, maximizar y cerrar en
la parte superior de cada pantalla de la siguiente manera
Pantalla de acceso: al acceder al sistema, en la primera pantalla se solicita al

analista su usuario y su clave. Posee un botón de ingreso al sistema. En esta
pantalla se permite al usuario ingresar su al sistema con un máximo de tres
intentos herrados, sino acierta el sistema cancela su ingreso. El propósito de esta
pantalla es restringir el acceso de personas no autorizadas al sistema.
Pantalla General: Contiene en la parte superior el saludo de bienvenida al usuario,
en la parte izquierda de arriba hacia abajo están los menú que conforman el
sistema como lo son: Nuevo Registro, Constancias de Trabajos, Historial,
Mantenimiento y Salir, cada uno de los cuales posee un sub menú.
Pantalla Usuario: Mediante esta pantalla se permite al usuario cargar la data
correspondiente de cada trabajador (obrero, docente o administrativo).
Pantalla Constancias de Trabajo: El Propósito de esta pantalla es que con solo con
introducir la cédula de identidad del trabajador pueda buscarlo y mostrar su
data, para luego ser imprimida.
Pantalla Historial: nos muestra búsqueda de constancias ya realizadas por cédula
del trabajador y por fecha de elaboración.
Mantenimiento: En esta pantalla se le permite al usuario cambiar la clave de
ingreso al sistema, este menú despliega primero una alerta de confirmación que se
desea cambiar la clave y luego despliega el sub menú de nueva clave.
Salir: En esta pantalla el módulo Salir le permite al usuario abandonar el sistema.
Las Fases VI(Construcción del Sistema), VII (Pruebas del Sistema) y VIII
(Implantación del Sistema), no serán desarrolladas para esta investigación.

programado del sistema de información de acuerdo a lo planteado en el diseño.
En esta fase se construyen y se prueban los diferentes módulos del subsistema
sistema.
1.- Diseño y construcción de las pruebas: Se especifican los detalles de cada una de
las pruebas que se han identificado en el plan de prueba y de construir los
Identificación.
Objetivos.
Requerimientos.
Criterio de éxito.
Casos de pruebas.
de los programas.
Después de realizar las especificaciones de pruebas anteriormente elaboradas,
se construye los ejecutivos y los esqueletos diseñados en cada una de ellas y si el
volumen de datos de prueba, es considerable, entonces prepara los archivos de
datos que ser demandes. Los mecanismos de prueba, junto con los datos, los
almacena el bibliotecario para su uso posterior de su respectiva prueba.
actividades:
3.2 Prueba de unidades. Las prueba de cada módulo especificado es realizada por
el mismo programador que lo codifico. Las actividades de pruebas de unidades se
dividen en:
Consiste en realizar las pruebas a los diferentes procedimientos de lenguajes de

control de tareas que se hayan utilizado. Entre las diferentes pruebas de los
pasos:
Objetivos.
Estrategias.
Procedimientos.
adiestramiento que se va a aplicar para capacitar a los usuarios en el uso y
operación del sistema, el grupo de desarrollo debe elaborar planes de capacitación
al personal que labora en la organización.

sistema respectivamente. Esta prueba se realiza luego que el grupo de desarrollo
ya adiestrado a todos los usuarios en el uso, es decir; se realiza la conversión del
sistema anterior al nuevo, mediante la actualización de la base de datos y el inicio
de las actividades propias del sistema de información. Finalmente se realiza la
entonación y la evaluación del sistema recientemente instalado.
Al realizar estos dos últimos pasos, la labor del todo el personal que participo en
el proyecto puede considerarse terminada, marcando así el fin del proyecto de
desarrollo y el inicio de una nueva etapa del ciclo de vida del sistema de
información: la etapa de operación y mantenimiento.
2. Prueba de aceptación: En esta etapa final consiste en preparar detalles para

la conversión y realizar la conversión del sistema, este es el paso más delicado de
abandona el sistema anterior. Previo al inicio de las actividades rutinarias del
sistema de información.
en junio 26, 2017

Compartir
No hay comentarios:
Publicar un comentario
‹
Página principal
Ver versión web
Datos personales
Ver todo mi perfil
Con la tecnología de Blogger.
METODOLOGÍA PARA EL DESARROLLO DE SISTEMAS DE
INFORMACIÓN MEDÍS
https://es.scribd.com/doc/77261040/Fases-de-MEDSI
Existen diferentes metodologías para el desarrollo de sistemas, la
metodología MEDÍS (metodología estructurada para el desarrollo de sistemas
de información), es una metodología estructurada para desarrollar sistemas de
información en y para organizaciones de cualquier tipo. Está ha sido probada
con éxito en el desarrollo de diferentes sistemas de información.
Características
- Es estructurada: Está característica se debe a dos razones esenciales:
a.- Utiliza diferentes métodos y técnicos estructuradas, que son propias de la
Ingeniería de la Programación y que han demostrado ser las más eficientes y
eficaces para el desarrollo de sistemas programados.
b.- Guía paso a paso - de arriba hacia abajo - al grupo que la aplica; explicando
primero, de forma muy general, lo que debe hacerse, para luego entrar en los
detalles, a medida que se avanza, hasta explicar las tareas esenciales que el
grupo debe llevar a cabo para desarrollar un sistema de información.
- Es completa: Cubre todas las distintas fases del ciclo desarrollo de un sistema
de información, desde la definición del proyecto hasta la implantación del
sistema en la organización.
- Es particionada: a fin de manipular mejor la complejidad inherente a un
proyecto de este tipo, la metodología se divide en fases. Cada una de estas
fases se dividen en pasos, los cuales están orientados a algún tipo de tópico,
aspecto o elemento del sistema de información.
- Es modificable y adaptable: el grupo de desarrollo puede modificar fácilmente
la metodología, bien para introducir nuevos elementos como para eliminar
algunos.
Fases de MEDSI.k

Estudio Preliminar del proyecto: este estudio muestra de manera general si
se justifica o no desarrollar un sistema de información para satisfacer las
necesidades de las unidades interesadas. Para ello se realizan las siguientes
actividades:
 Recopila y analiza aquellos elementos que indiquen la necesidad de un
nuevo sistema.
 Realizar reuniones preeliminares con el personal de las unidades
involucradas para definir la necesidad de un cambio.
Esta actividad busca diagnosticar, de modo muy general, el sistema actual,
si es que existe, tratando de responder entre otras cosas, las siguientes
interrogantes:
 ¿Qué hace este sistema actual?
 ¿Qué objetivo persigue? ¿Los logra actualmente? ¿Por qué?
 ¿Qué dificultades o inconvenientes presenta?
 ¿Qué áreas de la organización se ven afectadas?
 ¿Es parte de un problema mayor?
Así mismo se busca determinar las necesidades preliminares que puedan o
no justificar el desarrollo del nuevo sistema. Alguna de las interrogantes que se
han de responder son:
 ¿Qué argumentos justifican un cambio?
 ¿Por qué es importante un cambio?
 ¿Por qué se cree que un nuevo sistema resolverá el problema?
 ¿Qué funciones generales debería ejecutar el nuevo sistema?
Para esta actividad se debe llevar a cabo las siguientes tareas:

 Realizar entrevistas con las personas que sientan la necesidad de un
cambio.
 Recopilar y archivar documentos, notas de las entrevistas y datos
relevantes del sistema actual, sus inconvenientes y la necesidad de
cambio.
 Analizar la documentación archivada.
Fase II. Análisis De Contexto.
En esta fase se busca ganar un sólido conocimiento del sistema
ampliado dentro del cual se ubicará el nuevo sistema de información y
determinar las deficiencias y problemas que presenta el actual sistema de
información (Si existe). Dentro de esta fase encontramos los siguientes pasos:
Análisis documental.
Las actividades que se deben realizar durante ese paso son:
a.- Recopilar documentos.
Con la colaboración de los diferentes usuarios, se recopila toda la
documentación posible a tal sistema.
b.- Analizar el contexto del sistema.
Durante esta actividad se estudia el sistema de actividades dentro del cual
estará enmarcado el sistema de información. Ello debe llevar a determinar los
objetivos de ese sistema, definir su estructura, establecer sus procesos y
determinar su comportamiento.
c.- Construir el modelo del sistema actual de Información.
Para ello se utiliza la técnica de análisis estructurado de sistemas que permite
elaborar los modelos físicos y lógicos del sistema de información.
Fase III. Definición de requerimientos.

Esta fase busca definir los requerimientos de los usuarios y establecer
las funciones, restricciones y atributos que el nuevo sistema de información
debe satisfacer.
Fase IV. Diseño Preliminar.

Esta fase se encarga de elaborar un diseño preliminar del sistema de
información que satisfaga los requerimientos, restricciones y atributos
establecidos en la fase III. El diseño preliminar consta de un prototipo o modelo
físico que delinea la interacción hombre- máquina del sistema de información y
describe, en forma general sus procesos automatizados.
Fase V. Diseñado Detallado
- Diseñar las pantallas de entrada – salida.
Esta actividad consiste en diseñar la estructura o formato de cada
pantalla de entrada de datos al sistema y de salida de información a los
usuarios.
-Diseñar los reportes.
En esta actividad se diseñan aquellos reportes que no fueron
especificados en la actividad anterior. Estos son básicamente, los listados de
papel, los gráficos y los diagramas. Para cada uno de ellos se debe especificar
su estructura o formato, su contenido (registro de datos) y el medio de
producción o salida.
-Diseño de Datos.
El diseño del subsistema de datos del sistema de información gira en
torno a el diseño de la (s) base (s) de datos necesaria (s) para almacenar los
datos de dicho sistema y el diseño de los programas que permitirán crear y
cargar la (s) base (s) de datos.
En este proceso de diseño se elabora un modelo de datos que representa

las entidades, sus atributos y las relaciones existentes entre esas entidades.
 Analizar los flujos de datos que entran y salen de cada archivo del
prototipo del sistema.
 Derivar la (s) estructura (s) de datos contenida (s) en cada archivo,
identificando las entidades que representa y los atributos que poseen.
 Establecer las relaciones que existan entre las diferentes entidades y
construir el modelo de entidad-relación correspondiente.
 Si el SMBD (sistema manejador de base de datos) que se valla a utilizar
manipula base de datos relacionales, entonces cada entidad del modelo
entidad-relación debe ser normalizada hasta por lo menos la tercera
forma normal.
 Verificar si el modelo de datos obtenido satisface todos y cada uno de
los requerimientos detallados en el libro de requerimientos.
 Realizar el diseño físico de la base de datos.
Fase VI. Construcción del sistema
En esta fase se construyen y se prueban los diferentes módulos del
sistema programado; se construye la base de datos y se realizan las
validaciones respectivas.
Fase VII. Control de programas.

Durante esta actividad se realizan pruebas que tienen por finalidad
verificar el sistema de información, esta es diseñada para localizar
discrepancias o anomalías entre el sistema de información recientemente
construido, y los objetivos y requerimientos inicialmente establecidos con los
usuarios del sistema.
Fase VIII. Prueba de aceptación.

Una vez culminada las pruebas se procede a la implantación del mismo,
para lo cual se establece el adiestramiento a los usuarios.
▼
lunes, 26 de junio de 2017
METODOLOGÍA MEDSI
UNIVERSIDAD NORORIENTAL PRIVADA

GRAN MARISCAL DE AYACUCHO
EL TIGRE- EDO. ANZOÁTEGUI
Maestría en Ciencias Gerenciales Mención Recursos Humanos

Asignatura: Sistemas de Información y documentación.
Unidad II. Metodología de Medsi.
Facilitador: MSc. Juan Hernández
AUTORES:
Ing. Gómez Jairo C.I 14.517.299
Lcdo. Lista Francisco C.I. 23.512.599
Abg. Marcano Keilymar C.I. 25.268.984
Abg. Mendoza Agustín C.I. 22.862.246
Abg. Ortiz Yarlenis C.I. 12.893.301
Lic. Soto María C.I:19.629.512
El Tigre, Junio del 2017
METODOLOGÍA MEDSI
1.- Definición de la metodología de Medsi.

Es aquella metodología estructurada que se utiliza para desarrollar sistemas
de información en y para organizaciones de cualquier tipo. Dentro de las
características más importantes de esta metodología podemos mencionar:
ü ES ESTRUCTURADA: Se considera estructurada por la utilización de

diferentes métodos y técnicas estructuradas, que son propias de la Ingeniería de la
Programación, y que han demostrado ser las más eficientes y eficaces para el
desarrollo de sistemas programados.
Guía paso a paso de arriba hacia abajo el grupo que la aplica explicando
primero de forma muy general lo que debe hacerse para luego entrar en los
detalles, a medida que se avanza hasta explicar las tareas esenciales que el grupo debe
llevar a cabo para realizar el sistema de información
ü ES COMPLETA. Cubre todas las distintas fases del ciclo de desarrollo de un
sistema de información, desde la definición del proyecto hasta la implantación del
sistema en la organización. Guía al grupo de desarrollo a través de las fases, a un nivel
bastante detallado, explicando las actividades que deben hacerse y en la mayoría de
los casos, enumerando las tareas específicas que los miembros del grupo deben
efectuar.
ü ES PARTICIONADA. Para un mejor manejo de la metodología se divide en
fases, y cada una de las fases está compuesta por pasos los cuales están orientados a
algún tipo de tópicos, aspecto o elemento de un sistema de información. Cada paso a
su vez agrupa a un conjunto de actividades que han de ser realizadas por el grupo de
desarrollo.
2.-Diagramas Utilizados en MEDSI

Los diagramas utilizados en esta metodología, para explicar las diferentes
fases están basados en la técnica de análisis Estructurado de Sistemas, y
corresponden a lo que, en términos de esa técnica, recibe el nombre de diagramas de
flujo de Datos. Además está orientada a proyectos medianos y grandes, que a meriten
la integracion de grupos de desarrollo conformados por tres o más personas que
puedan requerir para su desarrollo varios meses.
3.- Fases de la Metodología.
Fase I. Definición del Proyecto:
Esta fase consiste en determinar si es factible o no el desarrollo del sistema

informativo, se realiza un diagnóstico de acuerdo a los gastos, tiempo y recursos que
genera, de tal manera que se tome la decisión para desarrollar o no el proyecto.
Dentro de esta fase encontramos los siguientes pasos:
Estudio Preliminar del proyecto: este estudio muestra de manera general si se
justifica o no desarrollar un sistema de información para satisfacer las necesidades de
las unidades interesadas. Se deben realizar las siguientes actividades:
1.1.-Reconocer el problema: Se deben efectuar todas las acciones necesarias
para reconocer que existe un problema. Los pasos que deben realizarse en esta
actividad son:
Recopila y analizar aquellos elementos que indiquen la necesidad de un nuevo
sistema.
Realizar reuniones preliminares con el personal de las unidades involucradas
para definir la necesidad de un cambio.
1.2.- Formular el problema. Permite diagnosticar de modo muy general, el
sistema actual, en el caso de que exista, determinando las necesidades preliminares
que puedan o no justificar el desarrollo del nuevo sistema.
2. Elaborar el informe preliminar. Una vez realizado el análisis anterior, el

gerente debe elaborar un informe que resuma los resultados de las actividades
anteriores, el cual debe concluir si existen o no necesidades y problemas actuales que
justifiquen emprender el desarrollo de un nuevo sistema. Dicho informe lo presentara
el gerente a los directivos de las unidades involucradas quienes deciden, a partir de ese
informe, si se emprende el proyecto o no, o si es necesario un mayor estudio.
3. Discutir el informe Preliminar.

4. Planificar el estudio de factibilidad.
5. El estudio de factibilidad. Se debe estudiar junto con el grupo
seleccionado para este paso, la factibilidad técnica, económica y psicosocial de
diferentes alternativas que puedan constituir soluciones aceptables al problema
actual.
6. Determina factibilidad técnica: Para cada sistema alternativo se debe
establecer su factibilidad técnica, planteándose si es posible desarrollar el sistema
propuesto con la tecnología actual o existente, y qué tecnología adicional debe
adquirir la organización. Para ello es necesario:
· Determinar factibilidad económica. Se debe realizar un análisis costo –
beneficio que permita identificar y medir los costos de desarrollo de operación y los
beneficios que obtiene la organización de cada sistema alternativo; para luego
comparar las diferentes alternativas bajo un criterio económico.
· Determinar factibilidad psicosocial. Este informe describe cada sistema
alternativo y resume su factibilidad técnica, económica psicosocial.
7. Elaborar informe de factibilidad:
8. Discutir el informe de factibilidad: El gerente del proyecto presenta el

informe a la comisión de planificación, quienes junto con los otros directivos de las
unidades involucradas discuten la factibilidad de cada alternativa y selecciona la más
conveniente. Planificación del Proyecto.
9. Planificación del Proyecto: Con la decisión de continuar con el proyecto y
de la selección de un enfoque alternativo para el nuevo sistema de información, el
gerente del proyecto se dedica a planificar el mencionado proyecto, tratando de
estimar los costos, tiempos y recursos para llevarlo a cabo. Elaborando un documento
que guíe el desarrollo del proyecto y que denominaremos el PLAN DE PROYECTO.
Fase II. Análisis del Contexto:

Se hace un análisis de los problemas que presenta y que puedan ser
mejorables con la construcción del sistema automatizado, es decir cambiar el registro
manual que se utiliza actualmente por un registro sistematizado. En el cual se ubicará
el nuevo sistema de información y determinar las deficiencias. En esta fase
encontramos los siguientes pasos:
1. Análisis documental: Desarrollar y disponer de una biblioteca organizada
de documentos relativos al proyecto. Una vez constituida la biblioteca, el grupo se
ocupa de estudiar la documentación propia del sistema con miras a obtener una
primera aproximación al conocimiento del citado sistema y sobre todo al contexto que
lo contiene.
2. Análisis del Contexto: Este paso constituye un estudio formal de todo el
sistema, con un nivel de detalle más profundo que aquellos realizados anteriormente.
Su objetivo es permitirle al grupo de desarrollo conocer el sistema actual y su contexto
para luego modelarlo y sobre el modelo identificare las situaciones problemáticas que
el sistema presenta. Para ello se utiliza la técnica de análisis estructurado de sistemas
que permite elaborar los modelos físicos y lógicos del sistema de información. Puede
realizarse mediante la construcción de los diagramas de flujo de datos del modelo
físico y lógico.
3. Construir el modelo del sistema actual de Información: Para ello se utiliza
la técnica de análisis estructurado de sistemas que permite elaborar los modelos
físicos y lógicos del sistema de información.
4. Elaborar el informe del sistema actual: Este informe resume los resultados
de las actividades anteriores, mediante una descripción del ambiente y del mismo
sistema, la presentación del modelo y la descripción de los problemas que presenta el
actual sistema.
Fase III. Definición de requerimientos:
Se define la información que se tiene de la Empresa, así como las

limitaciones y propiedades que debe ofrecer el sistema. Especificando los
requerimientos de los usuarios y establecer las funciones, restricciones y atributos que
el nuevo sistema de información.
1. Especificación de Requerimientos de Información: El grupo de desarrollo
se encarga de especificar junto con el usuario del nuevo sistema las salidas, las
entradas y las estructuras necesarias de datos. Dichos requerimientos son los de
entrada, salida y de almacenamiento.
2. Construir el libro de requerimientos de información: Los requerimientos
se agrupan e divisiones de acuerdo al tipo señalado en la actividad anterior. La división
de requerimientos de salida se organiza por sesiones. Cada sesión contiene los
requerimientos de información de una unidad funcional que esta involucrada en el
sistema.
3. Especificación de Restricciones y Atributos: En este paso, el grupo de
desarrollo establece junto con los usuarios las restricciones bajo las cuales se deben
desarrollar y debe operar el sistema de información. Así mismo se establece también,
la interaccion que debe haber entre el hombre, el computador y los atributos de
calidad que se la van a imponer al mencionado sistema de información.
Económica: Que cantidad de dinero se dispone para mantener el sistema.
Técnicas: Que equipo debe o puede utilizarse.
De personal: De que personal se dispone para mantener y operar el sistema.
Legales: Las politicas, reglamentos, normas, leyes, etc, tanto internas como
externas deben acatarse.
4. Determinar interacción hombre – máquina: Esta actividad es esencial
pues define la comunicación que debe haber entre los usuarios y el computador a
través del subsistema programado.
5. Determinar atributos de calidad: Entre algunos de los atributos de calidad
se destacan las siguientes: Confiabilidad, Grado de prueba, Movilidad, Adaptabilidad,
Mantenimiento requerido, Seguridad y privacidad, Eficiencia y rendimiento y
Documentación.
Fase IV. Diseño Preliminar:
Esta fase consiste en elaborar un diseño preliminar del sistema de

información que satisfaga los requerimientos, restricciones y atributos establecidos en
la fase III. El diseño preliminar consta de un prototipo o modelo físico que delinea la
interacción hombre- máquina del sistema de información y describe, en forma general
sus procesos automatizados. Dentro de esta fase encontramos:
satisfacer la especificación funcional, las restricciones y los atributos identificados en la
fase anterior, mediante la solicitud de precios y especificaciones técnicas de los
equipos o programas que hagan falta, a los diferentes vendedores del mercado. Se rige
por la estructura o configuración global del sistema de información, en ella se indica si
el diseño del sistema ha de ser independiente, centralizado o distribuido. Partiendo de
este enfoque, se establecen diferentes configuraciones para el procesamiento y para la
interacción que existirá entre el hombre y la máquina.
2. A partir del modelo lógico del nuevo sistema y de las restricciones y
atributos establecidos anteriormente, el grupo desarrolla diferentes prototipos, el cual
va indicar que procesos son manuales y cuales automáticos. El prototipo muestra
también los procedimientos de activación del subsistema programado, los de respaldo
y recuperación de fallas y los de seguridad de la base de datos.
6. Para cada prototipo se determina sus costos de desarrollo y operaciones y
se estima los beneficios que puedan obtenerse. Se comparan los diferentes prototipos

diferentes prototipos definidos en el paso anterior. De los resultados de este análisis
se presenta y discute con la comisión de planificación, quién decide posteriormente el
prototipo más conveniente y da las instrucciones necesarias para la adquisición de la
tecnología que haga falta.
2. Cada proceso automático del prototipo se refina mediante la
descomposición funcional establecida por la técnica AES. Cada proceso del mas bajo
nivel debe describirse utilizando cualquier de las técnicas siguientes: algoritmos
estructurados, tablas de decisión o árboles de decisión. Los entes del diccionario de
datos que se vean afectados por la automatización deben ser actualizados durante
esta actividad. El modelo o prototipo obtenido en la actividad anterior se somete a una
revisión estructurada o a una inspección de diseño.
3. Refinamiento de Prototipo: En este proceso se refinar el prototipo
escogido, es decir, se describen con mayor detalle aquellos procesos del prototipo que
sean automáticos, siguiendo la técnica de análisis estructurado de sistema.
Fase V. Diseño detallado:

Consiste en elaborar un diseño especificando los diferentes componentes
del sistema, tomando como referencia el modelo preliminar el registro manual llevado
actualmente el cual contiene la especificación de todos los datos necesarios para
diseñar el sistema, es decir los datos que serán registrados.
1. Diseño de Entradas y Salidas. Se elabora minuciosamente el diseño de la
interacción entre el hombre y la máquina, la cual ha sido delineada en el prototipo del
sistema. mediante la estructuración o formato de cada pantalla de entrada de datos al
sistema y de salida de información a los usuarios.
2. Diseño de Datos: Este diseño del subsistema de datos del sistema de
información gira en torno a el diseño de la (s) base (s) de datos necesaria (s) para
almacenar los datos de dicho sistema y el diseño de los programas que permitirán
crear y cargar la (s) base (s) de datos, es decir, se realiza el diseño lógico de la base de
datos.
ü Analizar los flujos de datos que entran y salen de cada archivo del prototipo
del sistema.
ü Derivar la (s) estructura (s) de datos contenida (s) en cada archivo,
identificando las entidades que representa y los atributos que poseen.
ü Establecer las relaciones que existan entre las diferentes entidades y
construir el modelo de entidad-relación correspondiente.
ü Si el SMBD (sistema manejador de base de datos) que se valla a utilizar
manipula base de datos relacionales, entonces cada entidad del modelo entidad-
relación debe ser normalizada hasta por lo menos la tercera forma normal.
ü Verificar si el modelo de datos obtenido satisface todos y cada uno de los
requerimientos detallados en el libro de requerimientos.
3. Diseño de programas y procedimientos. El subsistema programado se
diseña como una estructura jerárquica compuesta por una o más programas, cada uno
de estos se compone a su vez de módulos un módulo se define como una unidad de
programa que se caracteriza por lo siguiente:
Posee un nombre propio y único.
Ejecuta una función claramente especificable.
Puede compilarse y catalogarse en forma catalogada.
Puede definir y mantener un conjunto propio de variables locales se llama o
invoca de otro modulo.
· Diseñar la documentación y los procedimientos manuales.
4. Ensamblaje del paquete de diseño. Este paso se basa en revisar y
ensamblar el conjunto de especificaciones de diseños producidas en los anteriores,
con el propósito de garantizar la consistencia, calidad y exactitud del diseño e integrar
lo que hemos denominado como paquete de diseño. Ensamblar el paquete de diseño
contiene:
Ø El prototipo del sistema.
Ø La configuración y documentación del equipo que se va a emplear.
Ø Las especificaciones de entrada y salida.
Ø La especificación del subsistema programado.
Ø La especificación del subsistema de datos.
Ø Cualquier otro material que fuese necesario
5. Planificación de pruebas. Las actividades concernientes a esta fase se
desarrolla a lo largo de esta metodología, por otro lado es evidente que muchas de las
actividades de prueba se pueden realizar en paralelo con actividades de fase tales
como las de diseño y construcción del sistema. Bajo este criterio, podemos dividir las
actividades generales de las pruebas en: Planificación de las pruebas, diseño y
construcción de las pruebas y ejecución de las pruebas.
Fase VI. Construcción del sistema.

programado del sistema de información de acuerdo a lo planteado en el diseño. En
esta fase se construyen y se prueban los diferentes módulos del subsistema
sistema.
1.- Diseño y construcción de las pruebas: Se especifican los detalles de cada una
de las pruebas que se han identificado en el plan de prueba y de construir los
Identificación.
Objetivos.
Requerimientos.
Criterio de éxito.
Casos de pruebas.
de los programas.
Después de realizar las especificaciones de pruebas anteriormente
elaboradas, se construye los ejecutivos y los esqueletos diseñados en cada una de ellas
y si el volumen de datos de prueba, es considerable, entonces prepara los archivos de
datos que ser demandes. Los mecanismos de prueba, junto con los datos, los almacena
el bibliotecario para su uso posterior de su respectiva prueba.
actividades:
3.2 Prueba de unidades. Las prueba de cada módulo especificado es realizada
por el mismo programador que lo codifico. Las actividades de pruebas de unidades se
dividen en:
Consiste en realizar las pruebas a los diferentes procedimientos de lenguajes

de control de tareas que se hayan utilizado. Entre las diferentes pruebas de los
pasos:
Objetivos.
Estrategias.
Procedimientos.
adiestramiento que se va a aplicar para capacitar a los usuarios en el uso y operación
del sistema, el grupo de desarrollo debe elaborar planes de capacitación al personal
que labora en la organización.

sistema respectivamente. Esta prueba se realiza luego que el grupo de desarrollo ya
adiestrado a todos los usuarios en el uso, es decir; se realiza la conversión del sistema
anterior al nuevo, mediante la actualización de la base de datos y el inicio de las
actividades propias del sistema de información. Finalmente se realiza la entonación y
la evaluación del sistema recientemente instalado.
Al realizar estos dos últimos pasos, la labor del todo el personal que participo
en el proyecto puede considerarse terminada, marcando así el fin del proyecto de
desarrollo y el inicio de una nueva etapa del ciclo de vida del sistema de información:
la etapa de operación y mantenimiento.
2. Prueba de aceptación: En esta etapa final consiste en preparar detalles

para la conversión y realizar la conversión del sistema, este es el paso más delicado de
abandona el sistema anterior. Previo al inicio de las actividades rutinarias del sistema
de información.
CASO PRÁCTICO.
SISTEMA DE INFORMACION PARA LA GESTION DE LAS CONSTANCIAS DE

TRABAJO DEL PERSONAL ADMINISTRATIVO, DOCENTE Y OBRERO DE LA UPTJAA, SEDE
EL TIGRE- ESTADO ANZOÁTEGUI.
Tomando en cuenta que en esta fase de la metodología se debe realizar un

estudio general de la unidad donde se requiera aplicar el sistema, analizando la
información suministrada por la misma, a través de un estudio de factibilidad. Este
sistema se aplicara en el Departamento de Recursos Humano de la Universidad
Politécnica Territorial “José Antonio Anzoátegui” sede El Tigre, la cual se encuentra
ubicada en el Km 08, Carretera Nacional El Tigre- Ciudad Bolívar, está referido a la
gestión de las Constancias de Trabajo que se le entrega al personal, administrativo,
docente y obrero de la Institución.
En cuanto a la solicitud de la Constancias de Trabajo por parte del personal
de dicha institución se ha venido presentando dificultades que retrasan este proceso,
ya que al momento de realizar el requerimiento por el solicitante ante el
departamento de RRHH las dificultades más comunes que se presenta en este caso,
en primer lugar ubicar al trabajador específicamente en el área o unidad al que se
encuentra asignado, verificar si es un trabajador fijo o contratado y debido a la
cantidad de solicitudes que se realizan por periodos se retrasa la entrega al solicitante.
Es por ello, la factibilidad de implementar el Sistema que permita agilizar la entrega de
las Constancia del Personal en tiempo requerido.
Actualmente este departamento cuenta con un (1) equipo de computación
que cubre con esta necesidad, por lo tanto se requiere de otra computadora, debido a
que esta no solo es para la emisión de constancia sino que cumple con diferentes
funciones lo que a su vez retrasa este proceso. Tomando en cuenta que la adquisición
de un equipo por parte de la universidad necesita de un tiempo prolongado, la unidad
debe realizar una requisición enviada al Departamento de Administración para
verificar si hay disponibilidad presupuestaria, su aprobación y luego una vez que se
apruebe proceder con la compra, todo esto requiere de aproximadamente dos meses
para adquirir la computadora.
Factibilidad de Personal:
En el departamento de RRHH para el suministro de las constancias se cuenta
con una persona (personal administrativo de la Institución), por lo tanto para la
aplicación del sistema se necesita:
· Un personal Administrativo encargado
· Con un cargo de T1
· Salario básico de 101.218,00 Bs
Factibilidad Psicosocial: Tomando en cuenta las necesidades del

departamento de Recursos humanos de acuerdo a la información suministrada por
medio de entrevista al personal de la misma en cuanto a la aplicación del sistema, se
generan una serie de interrogantes:
¿En qué consiste el sistema?
¿Es necesaria la aplicación de este sistema en el departamento de RRHH?
¿Quiénes se beneficiaran con la aplicación del sistema?
Factibilidad legal: En bases a los principios legales que sustentan este trabajo en
la Ley del Trabajo, Las Trabajadoras y los Trabajadores, en el Capítulo IV referido a las
Invenciones, Innovaciones y mejoras en su artículo 323 establece: ..”Se considerarán
invenciones, innovaciones o mejoras de servicio aquellas realizadas por trabajadores
contratadas por el patrono”….
De tal manera, que las mejoras que se realicen en el departamento para el
bienestar o mejoras del trabajo se encuentra enmarcadas en las leyes por lo tanto
deben seguirse con los lineamientos estipuladas en esta.
Factibilidad Técnica:
Actualmente en el Dpto. de RRHH (Uptjaa)
Aplicación del sistema (Necesidad)
HARDWARE
1 Disco duro de 80GB.
1 Mouse
1teclado
1 monitor de 17”
1 impresora con cable interface
1 UPS
SOFTWARE
Programa Visual Basic
Fase II. Análisis del Contexto.
Se realiza un estudio más formal a través de la descripción detallada del

proceso anterior. El departamento objeto de estudio en la actualidad realiza el proceso
para la entrega de las constancias de la siguiente manera: el solicitante una vez en el
Departamento de RRHH realiza el requerimiento a la persona encargada, donde debe
anotarse de manera manual en una libreta ingresando sus datos (Nombres y Apellidos,
Cédula de identidad, indicar si la constancia es con salario base o integral y el tipo de
personal), luego el funcionario encargado le indicara de acuerdo a los requerimiento
que tenga, el día para retirar la constancia.
Una vez que se tenga los datos del trabajador se van ingresando los datos a
través de un formato en Word. Luego se imprime para ser entregada a la persona
solicitante.
Fase III. Definición de Requerimientos.

En esta fase se realiza de manera detallada la especificación de los
Requerimientos de Información, explicando en el nuevo sistema las salidas, las
entradas y las estructuras necesarias de datos. En el caso planteado se presenta de la
siguiente manera:
Requerimientos de Entrada: Cédula de Identidad, cargo, nombres y apellidos
del trabajador, fecha de ingreso, sueldo, grado de instrucción, fecha de ingreso, tipo
de trabajador docente o administrativo, estatus del empleado: contratado, fijo o
jubilado.
Requerimientos de Salida: Son los diferentes tipos de reportes que muestra el

programa estos pueden ser visibles en pantalla o impresos:
· Reportes de Constancias de trabajo.
· Reporte de Consulta de sueldo de Trabajadores docentes y
· Reporte de Consulta de cargos de Trabajadores docentes y
· Reporte de Consulta de grado de instrucción de Trabajadores docentes y
FASE IV. Diseño Preliminar.
Fase V. Diseño Detallado.
De manera estándar las pantallas están diseñadas con el nombre del

programa (sistema de constancias de trabajo), los botones minimizar, maximizar y
cerrar en la parte superior de cada pantalla de la siguiente manera
Pantalla de acceso: al acceder al sistema, en la primera pantalla se solicita al
analista su usuario y su clave. Posee un botón de ingreso al sistema. En esta pantalla se
permite al usuario ingresar su al sistema con un máximo de tres intentos herrados,
sino acierta el sistema cancela su ingreso. El propósito de esta pantalla es restringir el
acceso de personas no autorizadas al sistema.
Pantalla General: Contiene en la parte superior el saludo de bienvenida al
usuario, en la parte izquierda de arriba hacia abajo están los menú que conforman el
sistema como lo son: Nuevo Registro, Constancias de Trabajos, Historial,
Mantenimiento y Salir, cada uno de los cuales posee un sub menú.
Pantalla Usuario: Mediante esta pantalla se permite al usuario cargar la data
correspondiente de cada trabajador (obrero, docente o administrativo).
Pantalla Constancias de Trabajo: El Propósito de esta pantalla es que con solo
con introducir la cédula de identidad del trabajador pueda buscarlo y mostrar su data,
para luego ser imprimida.
Pantalla Historial: nos muestra búsqueda de constancias ya realizadas por
cédula del trabajador y por fecha de elaboración.
Mantenimiento: En esta pantalla se le permite al usuario cambiar la clave de
ingreso al sistema, este menú despliega primero una alerta de confirmación que se
desea cambiar la clave y luego despliega el sub menú de nueva clave.
Salir: En esta pantalla el módulo Salir le permite al usuario abandonar el
sistema.
Las Fases VI(Construcción del Sistema), VII (Pruebas del Sistema) y VIII
(Implantación del Sistema), no serán desarrolladas para esta investigación.
en junio 26, 2017

Compartir
No hay comentarios:
Publicar un comentario
‹
Página principal
Ver versión web
Datos personales
Ver todo mi perfil
Con la tecnología de Blogger.
http://solotemasderrhh.blogspot.com/2017/06/metodologia-medsi.html?m=1
Metodologia Rup
lunes, 23 de octubre de 2017

METODOLOGÍA RUP
Aquí hablaremos de la metodología RUP, comenzando con una corta

introducción de que es una Metodología Tradicional, después, daremos el concepto de
metodología RUP, ventajas y desventajas, funcionalidad, y fases de la metodología,
pero primero daremos una diferencias entre una Metodología Ágil y una Metodología
Tradicional.
DIFERENCIAS ENTRE UNA METODOLOGÍA ÁGIL Y TRADICIONAL
Metodologías Tradicionales
Metodologías Ágiles
Basadas en normas provenientes de estándares seguidos por el entorno de
desarrollo
Basadas en heurísticas provenientes de prácticas de producción de código
Cierta resistencia a los cambios
Especialmente preparados para cambios durante el proyecto
Impuestas externamente
Impuestas internamente (por el equipo)
Proceso mucho más controlado, con numerosas políticas/normas
Proceso menos controlado, con pocos principios.
El cliente interactúa con el equipo de desarrollo mediante reuniones
El cliente es parte del equipo de desarrollo
Más artefactos
Pocos artefactos
Más roles
Pocos roles
Grupos grandes y posiblemente distribuidos
Grupos pequeños (<10 integrantes) y trabajando en el mismo sitio
La arquitectura del software es esencial y se
expresa mediante modelos
Menos énfasis en la arquitectura del software
Existe un contrato prefijado
No existe contrato tradicional o al menos es bastante flexible
Resultado de imagen para diferencias entre metodologia agil y tradicional
Aquí, unos ejemplos de los dos tipos de metodologías
Imagen relacionada
Imagen relacionada
¿QUÉ ES UNA METODOLOGÍA TRADICIONAL?
Estas metodologías tradicionales imponen una disciplina de trabajo sobre el

proceso de desarrollo, con el fin de conseguir un software. Para ello, se hace énfasis en
la planificación total de todo el trabajo a y una vez que está todo detallado, comienza
el ciclo de desarrollo de software. Se centran especialmente en el control de proceso,
mediante una rigurosa definición de roles, documentación detallada. Además, las
metodologías no se adaptan adecuadamente a los cambios, si se necesita hacer una
cambio en las últimas fases, sería muy complicado ya que tendrían que devolverse al
principio y eso tendría muchos costos y se perdería tiempo valioso, por lo cuales no
son métodos adecuados cuando se trabajan en un entorno, donde los requisitos no
pueden predecirse o bien pueden variar.
¿ QUE ES LA METODOLOGÍA RUP?
Resultado de imagen para rup
La metodología RUP , abreviatura de Rational Unified Process (o Proceso

Unificado Racional), es un proceso propietario de la ingeniería de software creado por
Rational Software , adquirida por IBM , ganando un nuevo nombre Irup que ahora es
una abreviatura Rational Unified Process y lo que es una marca en el área de software,
proporcionando técnicas que deben seguir los miembros del equipo de desarrollo de
software con el fin de aumentar su productividad en el proceso de desarrollo.
Es una metodología cuyo fin es entregar un producto de software. Se

estructura todos los procesos y se mide la eficiencia de la organización.
Es un proceso de desarrollo de software el cual utiliza 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
VENTAJAS Y DESVENTAJAS
VENTAJAS
Está basada totalmente en mejoras prácticas de la metodología:
Reduce riesgos del proyecto.
Incorpora fielmente el objetivo de calidad.
Integra desarrollo con mantenimiento.
DESVENTAJAS
Pretende prever y tener todo el control de antemano

Modelo genera trabajo adicional.
Genera muchos costos.
No recomendable para proyectos pequeños
a la/s octubre 23, 2017 No hay comentarios.:

Enviar esto por correo electrónico
BlogThis!
Compartir en Twitter
Compartir en Facebook
Compartir en Pinterest
PRINCIPIOS O FUNCIONALIDAD DE DESARROLLO DE LA METODOLOGÍA RUP
El RUP está basado en 6 principios clave que son
Adaptar el proceso
El proceso deberá adaptarse a las necesidades del cliente ya que es muy

importante interactuar con él. Las características propias del proyecto u organización.
El tamaño del mismo, así como su tipo o las regulaciones que lo condicionen, influirán
en su diseño específico. También se deberá tener en cuenta el alcance del proyecto en
un área subformal.
Equilibrar prioridades
Los requisitos de los diversos participantes pueden ser diferentes,

contradictorios o disputarse recursos limitados. Debe encontrarse un equilibrio que
satisfaga los deseos de todos. Gracias a este equilibrio se podrán corregir desacuerdos
que surjan en el futuro.
Demostrar valor iteractivamente
Los proyectos se entregan, aunque sea de un modo interno, en etapas iteradas.

En cada iteración se analiza la opinión de los inversores, la estabilidad y calidad del
producto, y se refina la dirección del proyecto así como también los riesgos
involucrados
Colaboración entre equipos
El desarrollo de software no lo hace una única persona sino múltiples equipos.

Debe haber una comunicación fluida para coordinar requisitos, desarrollo,
evaluaciones, planes, resultados, etc.
Elevar el nivel de abstracción
Este principio dominante motiva el uso de conceptos reutilizables tales como

patrón del software, lenguajes 4GL o marcos de referencia (frameworks) por nombrar
algunos. Esto evita que los ingenieros de software vayan directamente de los
requisitos a la codificación de software a la medida del cliente, sin saber con certeza
qué codificar para satisfacer de la mejor manera los requisitos y sin comenzar desde
un principio pensando en la reutilización del código. Un alto nivel de abstracción
también permite discusiones sobre diversos niveles y soluciones arquitectónicas. Éstas
se pueden acompañar por las representaciones visuales de la arquitectura, por
ejemplo con el lenguaje UML.
Resultado de imagen para uml
Enfocarse en la calidad
El control de calidad no debe realizarse al final de cada iteración, sino en todos

los aspectos de la producción. El aseguramiento de la calidad forma parte del proceso
de desarrollo y no de un grupo independiente.
FASES DE LA METODOLOGÍA RUP
Resultado de imagen para FASES RUP
Fases
Establece oportunidad y alcance

Identifica las entidades externas o actores con las que se trata
Identifica los casos de uso
RUP comprende 2 aspectos importantes por los cuales se establecen las

disciplinas:
Proceso:
Las etapas de esta sección son: (revisar nuevamente la gráfica)
Modelado de negocio
Requisitos
Análisis y Diseño
Implementación
Pruebas
Despliegue
Soporte
En esta parte nos encontramos con las siguientes etapas:

Gestión del cambio y configuraciones
Gestión del proyecto
Entorno
La estructura dinámica de RUP es la que permite que éste sea un proceso de

desarrollo fundamentalmente iterativo, y en esta parte se ven inmersas las cuatro
fases descritas anteriormente:
Inicio (también llamado Incepción o Concepción).

Elaboración.
Desarrollo (también llamado Implementación, Construcción).
Cierre (también llamado Transición).
Resultado de imagen para FASES RUP
Fase de Inicio
Esta fase tiene como propósito definir y acordar el alcance del proyecto con los
patrocinadores o alumnos de un proyecto en el cual tenemos que, identificar los
riesgos 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 posteriores.
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 Desarrollo
El propósito de esta fase es completar la funcionalidad del sistema, para ello se
deben clarificar los requisitos 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.
Artefactos
RUP en cada una de sus fases (pertenecientes a la estructura dinámica) realiza

una serie de artefactos que sirven para comprender mejor tanto el análisis como el
diseño del sistema (entre otros). Estos artefactos (entre otros) son los siguientes:
Inicio
Documento Visión
Diagramas de caso de uso
Especificación de Requisitos
Diagrama de Requisitos
Elaboración
Documento Arquitectura que trabaja con las siguientes vistas:
Vista Lógica
Diagrama de clases
Resultado de imagen para diagrama de clases
Modelo E-R (Si el sistema así lo requiere)
Resultado de imagen para modelo er
Vista de Implementación
Diagrama de Secuencia
Resultado de imagen para diagrama de secuencia
Diagrama de estados
Resultado de imagen para diagrama de estados
Diagrama de Colaboración
Resultado de imagen para diagrama de colaboracion
Vista Conceptual
Modelo de dominio
Vista física
Mapa de comportamiento a nivel de hardware.
Diseño y desarrollo de casos de uso, o flujos de casos de uso arquitectónicos
Pruebas de los casos de uso desarrollados, que demuestran que la arquitectura
documentada responde adecuadamente a requerimientos funcionales y no
funcionales.
Construcción
Especificación de requisitos faltantes

Diseño y desarrollo de casos de uso y/o flujos de acuerdo con la planeación
iterativa
Pruebas de los casos de uso desarrollados, y pruebas de regresión según sea el
caso
Transición
Pruebas finales de aceptación

Puesta en producción
Estabilización
a la/s octubre 23, 2017 2 comentarios:

Enviar esto por correo electrónico
BlogThis!
Compartir en Twitter
Compartir en Facebook
Compartir en Pinterest
Página Principal
Suscribirse a: Entradas (Atom)
(sin título)
(sin título)
Buscar este blog
Página Principal
Colaboradores
CARLOS MARIO DIAZ DURAN
Miguel Rubiano
Unknown
Archivo del Blog
▼ 2017 (2)
▼ octubre (2)
METODOLOGÍA RUP Aquí hablaremos de la metodología ...
PRINCIPIOS O FUNCIONALIDAD DE DESARROLLO DE LA MET...
Denunciar abuso
Tema Awesome Inc.. Con tecnología de Blogger.
https://metodolorup.blogspot.com/?m=1
Inicio
Al azar
Cercanos
Acceder
Configuración
Acerca de Wikipedia
Limitación de responsabilidad
Abrir menú principal
Wikipedia
Buscar
Proceso Unificado de Rational
proceso de desarrollo de software
Leer en otro idioma
Descargar en PDF
Vigilar esta página
Editar
El Proceso Unificado de Rational o RUP (por sus siglas en inglés de Rational
Unified Process) es un proceso de desarrollo de software desarrollado por la empresa
Rational Software, actualmente propiedad de IBM.[1] Junto con el Lenguaje Unificado
de Modelado (UML), constituye la metodología estándar más utilizada para el análisis,
diseño, implementación y documentación de sistemas orientados a objetos.
El RUP no es un sistema con pasos firmemente establecidos, sino un conjunto

de metodologías adaptables al contexto y necesidades de cada organización. También
se conoce por este nombre al software, también desarrollado por Rational, que incluye
información entrelazada de diversos artefactos y descripciones de las diversas
actividades. Está incluido en el Rational Method Composer (RMC), que permite la
personalización de acuerdo con las necesidades.
Originalmente se diseñó un proceso genérico y de dominio público, el Proceso

Unificado, y una especificación más detallada, el Rational Unified Process, que se
vendiera como producto independiente.
Principios de desarrollo Editar

La Filosofía del RUP está basado en 6 principios clave que son los siguientes:
Adaptar el proceso Editar

El proceso deberá adaptarse a las necesidades del cliente ya que es muy
importante interactuar con él. Las características propias del proyecto, el tamaño del
mismo, así como su tipo o las regulaciones que lo condicionen, influirán en su diseño
específico. También se deberá tener en cuenta el alcance del proyecto.
Equilibrar prioridades Editar

Los requisitos de los diversos participantes pueden ser diferentes,
contradictorios o disputarse recursos limitados. Debe poder encontrarse un equilibrio
que satisfaga los deseos de todos. Gracias a este equilibrio se podrán corregir
desacuerdos que surjan en el futuro. Al igual esta metodología está acorde con UML,
Unificado Modelo Lenguajes'
Demostrar valor iterativamente Editar
Los proyectos se entregan, aunque sea de un modo interno, en etapas iteradas.
En cada iteración se analiza la opinión de los inversores, la estabilidad y calidad del
producto, y se refina la dirección del proyecto así como también los riesgos
involucrados.
Colaboración entre equipos Editar

El desarrollo de software no lo hace una única persona sino múltiples equipos.
Debe haber una comunicación fluida para coordinar requisitos, desarrollo,
evaluaciones, planes, resultados, etc.
Enfocarse en la calidad Editar

El control de calidad no debe realizarse al final de cada iteración, sino en todos
los aspectos de la producción. El aseguramiento de la calidad forma parte del proceso
de desarrollo y no de un grupo independiente, también es una estrategia de desarrollo
de software.
Elevar el nivel de abstracciónEditar

Artículo principal: Abstracción (informática)
Este principio dominante motiva el uso de conceptos reutilizables tales como
patrones de diseño del software, lenguajes 4GL o esquemas (frameworks) por
nombrar algunos. Estos se pueden acompañar por las representaciones visuales de la
arquitectura, por ejemplo con UML.
Ciclo de vida Editar
Esfuerzo en actividades según fase del proyecto.

El ciclo de vida RUP es una implementación del desarrollo en espiral. Fue
creado ensamblando los elementos en secuencias semi-ordenadas. El ciclo de vida
organiza las tareas en fases e iteraciones.
RUP divide el proceso en cuatro fases, dentro de las cuales se realizan pocas
pero grandes y formales iteraciones en número variable según el proyecto. En la Figura
muestra cómo varía el esfuerzo asociado a las disciplinas según la fase en la que se
encuentre el proyecto RUP.
Las primeras iteraciones (en las fases de Inicio y Elaboración) se enfocan hacia
la comprensión del problema y la tecnología, la delimitación del ámbito del proyecto,
la eliminación de los riesgos críticos, y al establecimiento de una baseline (línea
base)[2] de la arquitectura.
Durante la fase de inicio las iteraciones hacen mayor énfasis en actividades de

modelado del negocio y de requisitos.
En la fase de elaboración, las iteraciones se orientan al desarrollo de la baseline

de la arquitectura, abarcan más los flujos de trabajo de requisitos, modelo de negocios
(refinamiento), análisis, diseño y una parte de implementación orientado a la baseline
de la arquitectura.
En la fase de construcción, se lleva a cabo la construcción del producto por

medio de una serie de iteraciones.
Para cada iteración se seleccionan algunos Casos de Uso, se refinan su análisis y

diseño y se procede a su implementación y pruebas. Se realiza una pequeña cascada
para cada ciclo. Se realizan iteraciones hasta que se termine la implementación de la
nueva versión del producto.
En la fase de transición se pretende garantizar que se tiene un producto

preparado para su entrega a la comunidad de usuarios.
Como se puede observar en cada fase participan todas las disciplinas, pero
dependiendo de la fase el esfuerzo dedicado a una disciplina varía.
Principales características Editar
Desarrollo iterativo
Administración de requisitos
Uso de arquitectura basada en componentes
Control de cambios
Modelado visual del software
Verificación de la calidad del software
Pretende implementar las mejores prácticas en Ingeniería de Software, de
forma que se adapte a cualquier proyecto
El RUP es un producto de Rational (IBM). Se caracteriza por ser iterativo e
incremental, estar centrado en la arquitectura y guiado por los casos de uso. Incluye
artefactos (que son los productos tangibles del proceso como por ejemplo, el modelo
de casos de uso, el código fuente, etc.) y roles (papel que desempeña una persona en
un determinado momento, una persona puede desempeñar distintos roles a lo largo
del proceso).
Fases Editar
Establece oportunidad y alcance
Identifica las entidades externas o actores con las que se trata
Identifica los casos de uso
RUP comprende 2 aspectos importantes por los cuales se establecen las
disciplinas:
Proceso
Las etapas de esta sección son: (revisar nuevamente la gráfica)
Modelado de negocio
Requisitos
Análisis y Diseño
Implementación
Pruebas
Despliegue
Soporte
En esta parte nos encontramos con las siguientes etapas:
Gestión del cambio y configuraciones

Gestión del proyecto
Entorno
La estructura dinámica de RUP es la que permite que éste sea un proceso de
desarrollo fundamentalmente iterativo, y en esta parte se ven inmersas las cuatro
fases descritas anteriormente:
Inicio (también llamado Incepción o Concepción).

Elaboración.
Desarrollo (también llamado Implementación, Construcción).
Cierre (también llamado Transición).
Fase de Inicio Editar
Esta fase tiene como propósito definir y acordar el alcance del proyecto con los
patrocinadores o alumnos de un proyecto en el cual tenemos que, identificar los
riesgos 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 posteriores.
Fase de Elaboración Editar

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 Desarrollo Editar

El propósito de esta fase es completar la funcionalidad del sistema, para ello se
deben clarificar los requisitos 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 Editar

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.
Artefactos Editar
RUP en cada una de sus fases (pertenecientes a la estructura dinámica) realiza
una serie de artefactos que sirven para comprender mejor tanto el análisis como el
diseño del sistema (entre otros). Estos artefactos (entre otros) son los siguientes:
Inicio Editar
Documento Visión.
Diagramas de caso de uso.
Especificación de Requisitos.
Diagrama de Requisitos.
Elaboración Editar
Documento Arquitectura que trabaja con las siguientes vistas:
Vista Lógica
Diagrama de clases
Modelo E-R (Si el sistema así lo requiere)
Vista de Implementación
Diagrama de Secuencia
Diagrama de estados
Diagrama de Colaboración
Vista Conceptual
Modelo de dominio
Vista física
Mapa de comportamiento a nivel de hardware.
Diseño y desarrollo de casos de uso, o flujos de casos de uso arquitectónicos
Pruebas de los casos de uso desarrollados, que demuestran que la arquitectura
documentada responde adecuadamente a requerimientos funcionales y no
funcionales.
Construcción Editar
Especificación de requisitos faltantes
Diseño y desarrollo de casos de uso y/o flujos de acuerdo con la planeación
iterativa
Pruebas de los casos de uso desarrollados, y pruebas de regresión según sea el
caso
Transición Editar
Pruebas finales de aceptación
Puesta en producción
Estabilización
Historia Editar
Los orígenes de RUP se remontan al modelo espiral original de Barry Boehm.
Ken Hartman, uno de los contribuidores claves de RUP colaboró con Boehm en la
investigación. En 1995, Rational Software compró una compañía sueca llamada
Objectory AB, fundada por Ivar Jacobson, famoso por haber incorporado los casos de
uso a los métodos de desarrollo orientados a objetos. El Rational Unified Process fue el
resultado de una convergencia de Rational Approach y Objectory (el proceso de la
empresa Objectory AB). El primer resultado de esta fusión fue el Rational Objectory
Process, la primera versión de RUP, fue puesta en el mercado en 1998, siendo el
arquitecto en jefe Philippe Kruchten.
El primer libro para describir el proceso fue titulado The Unified Software
Development Process[3]
En 2006, IBM creó un subconjunto de RUP ajustado para proyectos de

desarrollo ágil - publicado como un método libre, llamado OpenUP a través del sitio de
Eclipse.[4]
Comentarios sobre Método Editar

Por otro lado, en lo que se refiere a la metodología esta comprende tres
principios claves: Dirigido por los casos de uso, centrado en la arquitectura, iterativo e
incremental.
En lo referente a "dirigido por los casos de uso", significa que los

requerimientos están enfocados a dar valor al cliente y que el proceso debe garantizar
que todo el desarrollo, pruebas, planificación, documentación, etc., está orientado a
cubrir estas expectativas del cliente y asegurar que los requerimientos de valor se
ponen en producción.
En lo referente a "centrado en arquitectura", significa que hay un énfasis a

diseñar una arquitectura de calidad, y es la arquitectura también la que guía la forma
cómo se debe planear y hacer el desarrollo.
En lo referente a "iterativo e incremental", significa que el proyecto se divide en

varios ciclos de vida (llamadas iteraciones) que deben dar como resultado un
ejecutable. Por cada una de las iteraciones se va agregando requerimientos y sobre
todo valor al cliente; por este motivo es incremental..
Referencias
Última edición hace 3 días por SeroBOT
Wikipedia
El contenido está disponible bajo la licencia CC BY-SA 3.0, salvo que se indique
lo contrario.
Términos de
usoPrivacidadEscritoriohttps://es.m.wikipedia.org/wiki/Proceso_Unificado_de_Ration
al
Menú
Buscar
Modelo RUP
Modelo RUP
¿Qué es RUP?
Es un proceso de ingeniería de software, que hace una propuesta orientada por
disciplinas para lograr las tareas y responsabilidades de una organización que
desarrolla software.
Su meta principal es asegurar la producción de software de alta calidad que
cumpla con las necesidades de los usuarios, con una planeación y presupuesto
predecible.
¿Para quién es RUP?

Diseñado para:
–Profesionales en el desarrollo de software.
–Interesados en productos de software.
–Profesionales en la ingeniería y administración de procesos de software.
¿Por qué usar RUP?
–Provee un entorno de proceso de desarrollo configurable, basado en
estándares.
–Permite tener claro y accesible el proceso de desarrollo que se sigue.
–Permite ser configurado a las necesidades de la organización y del proyecto.
–Provee a cada participante con la parte del proceso que le compete
directamente, filtrando el resto.
Características
Dirigido por Casos de Uso: –Los casos de uso son los artefactos primarios para
establecer el comportamiento deseado del sistema
Centrado en la Arquitectura: –La arquitectura es utilizada para conceptualizar,
construir, administrar y evolucionar el sistema en desarrollo
Iterativo e Incremental:
–Maneja una serie de entregas ejecutables
–Integra continuamente la arquitectura para producir nuevas versiones
mejoradas
Conceptualmente amplio y diverso
Enfoque orientado a objetos
En evolución continua
Adaptable
Repetible
Permite mediciones:
–Estimación de costos y tiempo, nivel de avance, etc.
Ciclo de Vida y sus Faces
En cuanto a tiempo el ciclo de vida de RUP se descompone en 4 FASES

secuenciales, cada cual concluye con un producto intermedio.
Al terminar cada fase se realiza una evaluación para determinar si se ha
cumplido o no con los objetivos de la misma.
Las fases son:
Inicio (Inception)
Elaboración
Construcción
Transición.
Inicio (Inception)
El objetivo general de esta fase es establecer un acuerdo entre todos los
interesados acerca de los objetivos del proyecto.
Es significativamente importante para el desarrollo de nuevo software, ya que
se asegura de identificar los riesgos relacionados con el negocio y requerimientos.
Para proyectos de mejora de software existente, esta fase es más breve y se
centra en asegurar la viabilidad de desarrollar el proyecto.
Elaboración
El objetivo en esta fase es establecer la arquitectura base del sistema para
proveer bases estables para el esfuerzo de diseño e implementación en la siguiente
fase.
La arquitectura debe abarcar todas las consideraciones de mayor importancia
de los requerimientos y una evaluación del riesgo.
Construcción
El objetivo de la fase de construcción es clarificar los requerimientos faltantes y
completar el desarrollo del sistema basados en la arquitectura base.
Vista de cierta forma esta fase es un proceso de manufactura, en el cual el
énfasis se torna hacia la administración de recursos y control de la operaciones para
optimizar costos, tiempo y calidad.
Transición
Esta fase se enfoca en asegurar que el software esté disponible para sus
usuarios.
Se puede subdividir en varias iteraciones, además incluye pruebas del producto
para poder hacer el entregable del mismo, así como realizar ajuste menores de
acuerdo a ajuste menores propuestos por el usuario.
En este punto, la retroalimentación de los usuarios se centra en depurar el
producto, configuraciones, instalación y aspectos sobre utilización.
Diagrama General de RUP
¿Cuándo usar RUP?
RUP puede utilizarse:

–En proyectos de nuevos productos de software
–En ciclos de desarrollo subsecuentes
Consideraciones que alteran cuándo y cómo usar partes de RUP:
–El ciclo de vida del proyecto
–Los objetivos del negocio, la visión, el alcance y los riesgos
–El tamaño del esfuerzo de desarrollo
Anuncios
REPORT THIS AD
Share this:
TwitterFacebook
Responder
Tu dirección de correo electrónico no será publicada. Los campos obligatorios
están marcados con *
Comentario
Nombre *
Correo electrónico *
Web
Notificarme los nuevos comentarios por correo electrónico.
Recibir nuevas entradas por email.
Pingback: Rational Unified Process (RUP) – Breve resumen del RUP y sus
principales utilidades | MyCrofT Sistemas & Ingenieria
principales utilidades | My CMS
principales utilidades | MyCroft Sistemas & Ingenieria
Lina Marcela Castro Guevara en 1 abril, 2016 de 12:20 PM

El artículo es bastante bueno, pero le hace falta los datos del autor del mismo,
pues si se quisiera tener como referencia para un documentos es difícil darle el
reconocimiento que se merece.
Gracias.
Responder
54xiro en 21 octubre, 2016 de 3:55 PM
los autores del blog estan en la pestaña acerca de. . .
Responder
Pingback: Gobierno de TI | chmasiunal20161911054
Pingback: Modelo RUP – IBM | DTyOC
Miscret en 11 marzo, 2017 de 11:07 PM

Hola, la información está bastante bien, pero las imágenes no pueden verse.
Por otra parte quisiera preguntar ¿los proyectos de modelo RUP son como
aplicaciones? Tengo esa duda porque tengo un proyecto de clase (con las opciones
anuario, poemario, facebook, entre otras) pero no entiendo muy bien de qué se trata
ya que la materia en Diseño de páginas web.
Responder
Ver sitio completo
Blog de WordPress.com.
Anuncios
REPORT THIS AD
:)https://softwarerecopilation.wordpress.com/modelo-rup/

Metodologia

Cargado por

Información del documento

Título original

Derechos de autor

Formatos disponibles

Compartir este documento

Compartir o incrustar documentos

Opciones para compartir

¿Le pareció útil este documento?

¿Este contenido es inapropiado?

Copyright:

Formatos disponibles

Metodologia

Cargado por

Copyright:

Formatos disponibles

SISTEMAS DE INFORMACIÓN

UNIVERSIDAD NORORIENTAL PRIVADA

Maestría en Ciencias Gerenciales Mención Recursos Humanos

El Tigre, Junio del 2017

ü ES ESTRUCTURADA: Se considera estructurada por la utilización de

2.-Diagramas Utilizados en MEDSI

3.- Fases de la Metodología.

Fase I. Definición del Proyecto:

Esta fase consiste en determinar si es factible o no el desarrollo del sistema

2. Elaborar el informe preliminar. Una vez realizado el análisis anterior, el

· Determinar factibilidad económica. Se debe realizar un análisis costo –

7. Elaborar informe de factibilidad:

8. Discutir el informe de factibilidad: El gerente del proyecto presenta el

Fase II. Análisis del Contexto:

Fase III. Definición de requerimientos:

Se define la información que se tiene de la Empresa, así como las limitaciones y

Fase IV. Diseño Preliminar:

Esta fase consiste en elaborar un diseño preliminar del sistema de información

2. Selección de prototipos: Se realiza un análisis de costo beneficio para los

3. Refinamiento de Prototipo: En este proceso se refinar el prototipo escogido,

Fase V. Diseño detallado:

3. Diseño de programas y procedimientos. El subsistema programado se diseña

Fase VI. Construcción del sistema.

Fase VII. Control de Programas.

Consiste en realizar las pruebas a los diferentes procedimientos de lenguajes de

Fase VIII. Prueba de Aceptación.

2. Prueba de aceptación: En esta etapa final consiste en preparar detalles para

Fase I. Definición del proyecto.

Tomando en cuenta que en esta fase de la metodología se debe realizar un

Factibilidad Psicosocial: Tomando en cuenta las necesidades del departamento

Fase II. Análisis del Contexto.

Se realiza un estudio más formal a través de la descripción detallada del proceso

Fase III. Definición de Requerimientos.

Requerimientos de Salida: Son los diferentes tipos de reportes que muestra el

FASE IV. Diseño Preliminar.

2. Selección de prototipos: Se realiza un análisis de costo beneficio para los

3. Refinamiento de Prototipo: En este proceso se refinar el prototipo escogido,

Pantalla de acceso: al acceder al sistema, en la primera pantalla se solicita al

Esta fase permite la Construcción del subsistema de datos y el subsistema

Fase VII. Control de Programas.

Consiste en realizar las pruebas a los diferentes procedimientos de lenguajes de

Fase VIII. Prueba de Aceptación.

Se procede a poner en operación y a efectuar la prueba de aceptación del

2. Prueba de aceptación: En esta etapa final consiste en preparar detalles para

en junio 26, 2017

Fase I. Definición del proyecto.

Para esta actividad se debe llevar a cabo las siguientes tareas:

Fase III. Definición de requerimientos.

Fase IV. Diseño Preliminar.

En este proceso de diseño se elabora un modelo de datos que representa

Fase VII. Control de programas.

Fase VIII. Prueba de aceptación.

UNIVERSIDAD NORORIENTAL PRIVADA

Maestría en Ciencias Gerenciales Mención Recursos Humanos

Facilitador: MSc. Juan Hernández

1.- Definición de la metodología de Medsi.

ü ES ESTRUCTURADA: Se considera estructurada por la utilización de

2.-Diagramas Utilizados en MEDSI

3.- Fases de la Metodología.

Fase I. Definición del Proyecto:

Esta fase consiste en determinar si es factible o no el desarrollo del sistema

2. Elaborar el informe preliminar. Una vez realizado el análisis anterior, el

3. Discutir el informe Preliminar.