CAPITULO I

PLANTEAMIENTO METODOLÓGICO

-1-
1.1 PROBLEMA

1.1.1 REALIDAD PROBLEMÁTICA

Debido a los cambios administrativos que se presentan en el sector salud,

estos ocasionan frecuentemente rotación del personal en los diferentes puestos. Muchos de
los cuales son asignados debido a la experiencia acumulada o retribución de favores
políticos (cargos de confianza), ocasionado que el nuevo personal entrante desconozca
donde empieza sus funciones y responsabilidades y donde termina las mismas.
Presentándose problemas de coordinación entre el personal y las diferentes áreas
produciendo disminución de la efectividad del personal en sus diferentes actividades,
provocando una mayor duración en los procesos.
Algunos Casos que se presentan:
- Al producirse un cambio de personal en el área, no se le proporciona toda la
información referente a sus funciones y/o obligaciones, en la mayoría de los casos
es proporcionado por el personal saliente de forma verbal, ocasionando un mal
desempeño para el personal que ocupara el puesto.
- El personal asume responsabilidades no competentes a su función como la
recepción de documentos desconociendo el tramite de los mismos, ocasionando
demora, perdida, traspapelación de la documentación y que otras áreas integradas a
estos procesos no culminen con sus actividades, por ejemplo provocando el
incumplimiento de pagos a tiempo a proveedores y personal contratado.
- El Área de Planificación incumple con su responsabilidad de informar, distribuir y
mantener actualizado el Manual de Organización y Funciones al personal, de
acuerdo a las resoluciones Legislativas y Directorales.
- Creación de puestos sin previo análisis de los procesos y actividades, sin previa
coordinación con el área de planificación.

-2-
 1.1.2 ENUNCIADO DEL PROBLEMA

¿De qué manera la implementación de un manual de organización y funciones

virtual ayudará al personal del Hospital Huacho y SBS a ser más eficientes en el desarrollo
y el cumplimiento de sus responsabilidades en el puesto asignado?

1.2 ALCANCES

Todas las Áreas y personal del Hospital Huacho-Huaura-Oyon, contribuyendo de esta

manera a que otros hospitales tengan como modelo la implementación del MOF virtual
para la mejora de sus actividades.

1.3 JUSTIFICACIÓN DE LA INVESTIGACIÓN

CONVENIENCIA: Permitirá una mejor relación y comunicación del personal dentro de

las áreas del Hospital, logrando así un eficiente desempeño.

RELEVANCIA SOCIAL: Permitirá un mejor desempeño y eficiencia del personal,

mediante el conocimiento actualizado de sus funciones y responsabilidades dentro del
hospital contribuyendo a que otros hospitales tengan como modelo la implementación del
MOF virtual para la mejora de sus actividades.

VALOR TEÓRICO: No se aportará ningún valor teórico, porque sólo se aplicarán

conocimientos adquiridos para la solución del problema planteado.

IMPLICACIONES PRÁCTICAS: Permitirá resolver el problema de la falta de

coordinación entre el área de planificación y de las distintas áreas brindando la información
necesaria al personal de sus responsabilidades para mejor desarrollo de sus actividades.

-3-
UTILIDAD METODOLÓGICA: No se va a crear un nuevo instrumento sin embargo se
recolectarán y analizarán los datos mediante las tecnologías de información que se
implanten en el desarrollo del MOF virtual.

1.4 ANTECEDENTES BIBLIOGRAFICAS DEL PROBLEMA

GUIA PARA LA ELABORACIÓN DEL MANUAL DE ORGANIZACION DE LAS

INSTITUCIONES CENTRALIZADAS Y DESCONCENTRADAS DEL PODER
EJECUTIVO.
Ing. Alberto Barberena Molina, M.A. Managua, junio del 2001.- REPUBLICA DE
NICARAGUA.

la Vice Presidencia, a través de la Unidad Coordinadora para la Reforma y Modernización

del Sector Público (UCRESEP), ha iniciado acciones de orden macroinstitucional
orientadas a fortalecer la institucionalidad del Estado Nicaragüense.
Su objetivo principal es presentar una guía técnica que permita de manera ágil, sencilla y
ordenada elaborar un manual de organización para las instituciones centralizadas y
desconcentradas del poder ejecutivo, con criterios de calidad, eficiencia y efectividad para
su empleo, y aceptado en cada institución del Estado en cumplimiento del Artículo 315 del
Reglamento de la Ley 290, la existencia de Homogeneidad en los manuales del Estado,
Reducción de costos y Facilitar la funcionalidad del Estado.
Alcanzando una guía para la elaboración del manual de organización, presenta los
elementos básicos de referencia para contribuir a la elaboración de manuales homogéneos
en los entes centralizados y desconcentrados del Poder Ejecutivo, así mismo para los entes
descentralizados del Estado a menos que su ley orgánica especifique lo contrario.
En consecuencia, se define para el análisis y elaboración de manuales de organización debe
abarcar desde la Dirección Superior de la Institución hasta el nivel de Departamento u
Oficina. Cuando la entidad así lo determine, el alcance de su Manual de Organización
incluirá un nivel jerárquico menor.

-4-
1.5 APORTES

Este estudio y desarrollo del Manual y Organización de Funciones Virtual permitirá

mejorar la eficiencia de los empleados que laboran en las distintas áreas del Hospital
permitiendo así la aplicación en otros Centros de Salud que vendría hacer un aporte a la
sociedad facilitando y encaminando a posteriores trabajos con sistemas similares.

1.6 OBJETIVOS

1.6.1 OBJETIVO GENERAL

Desarrollo de un MOF virtual mediante la metodología de la Métrica y
UML, para ayudar al conocimiento de funciones y responsabilidades en el Hospital
Huacho-Huaura-Oyon y SBS.

1.6.2 OBJETIVOS ESPECIFICOS

a) Conocer la situación actual de la organización observando los procesos y

actividades que se desarrollan en cada área que nos permitan recopilar un
conjunto de información para obtener el conocimiento a cerca de la estructura
orgánica y funcional existente.

b) Dotar a la institución de una estructura de organización basada en los principios

de administración moderna que facilite la planificación, dirección y control de
las operaciones.

c) Analizar los diversos procesos de la organización permitiendo detectar la

naturaleza de las áreas funcionales, entendiendo como tales: " El conjunto de
unidades administrativas interrelacionadas, que realizan funciones de naturaleza
similar para el logro de un objetivo común " .

-5-
d) Redefinir e identificar las funciones por cada puesto correspondiente en la
organización eliminando a su vez, duplicidad y sobrecargas de trabajo.

e) Emplear estándares de programación, patrones de informes para la elaboración

del MOF Virtual

f) Presentar una visión de la estructura organizacional de la Entidad, mostrando

sus principales funciones, niveles jerárquicos, clase de unidades que la
conforman y de la estructura de puestos.

g) Coadyuvar a la capacitación del personal y especialmente, del personal de nuevo

ingreso, al facilitarle una visión global de toda la institución, y al mostrarle la
relación entre su unidad y las demás unidades.

h) Permitir una mejor promoción de las oportunidades de empleo y una selección

científica de los empleados, al proporcionar los requerimientos de idoneidad
exigidos por el cargo.

i) Permitir una mejor ubicación del empleado, a tono con sus conocimientos y
aptitudes.

-6-
1.7 HIPÒTESIS
1.7.1 HIPÒTESIS INICIAL
El Desarrollo y utilización de un Manual de Organización y Funciones
Virtual, utilizando la metodología métrica y UML, permitirá mejorar la
Productividad en el Hospital Huacho–Huaura-Oyon.
Hipótesis Alternativa
Ha: La aplicación de un rediseño organizacional en la asignación de
funciones a puesto de trabajo que permitirá mejorar la productividad en el
Hospital Huacho–Huaura-Oyon.

(Desarrollar un) (Mejorar) la

Manual de Organización y productividad en la
Funciones Virtual Empresa

Metodología Métrica
y UML

1.7.2 VARIABLES
1. Variable Independiente
Manual de Organización y Funciones Virtual
2. Variable Interviniente
Metodología Métrica y Unified Modeling Language (UML)
3. Variable Dependiente
(Mejorar) la productividad de la empresa.

-7-
 VARIABLE INDICADORES
INDEPENDIENTE CONCEPTO DEL MOF
(DESARROLLAR) UN OBJETIVOS DEL MOF
MANUAL DE CONTENIDO Y ALCANCE
ORAGANIZACION Y LOGICA PARA ELABORAR UN MOF
FUNCIONES VIRTUAL) BASE TÉCNICA PARA ELABORAR UN MOF

NÚMERO DE PECOSAS
NÚMERO DE ORDENES DE COMPRAS
INGRESADAS PROCESADAS AL MES
NÚMERO DE EMISIONES DE ORDENES DE
DEPENDIENTE COMPRA PROCESADAS AL MES
(MEJORAR) EN LA NÚMERO DE ORDENES COMPROMETIDAS
PRODUCTIVIDAD DE LA PARA EL PAGO.
EMPRESA NÚMERO DE FALTAS
NÚMERO DE METAS CUMPLIDAS
NÚMERO DE ACTIVIDADES DE ACUERDO AL
PUESTO REALIZADAS AL MES
NÚMERO DE TARDANZAS AL MES

FLEXIBILIDAD EN ADAPTACIÓN A CUALQUIER

PROYECTO
METODOLOGÍA DE FACIL MANEJO.
INTERVINIENTE
NUMERO DE PRUEBAS
MÉTRICA Y UML
NUMERO DE FASES APLICADAS
SATISFACCIÓN DE LOS REQUISITOS.
AUMENTO DE LA CALIDAD DE LOS SISTEMAS

-8-
1.8 UNIDADES DE OBSERVACIÓN, UNIVERSO, MUESTRA
1.8.1 I ETAPA
UNIDADES DE OBSERVACIÓN
HOSPITALES
UNIVERSO
Todos los Hospitales del Mundo.
UNIDAD MUESTRAL
HOSPITAL HUACHO HUAURA – OYON
TIPO DE MUESTREO
No Aleatorio

1.8.2 II ETAPA
UNIVERSO
Todos las Áreas del Hospital Huacho – Huaura - Oyon
UNIDAD MUESTRAL
Un área de un Hospital nacional.
TIPO DE MUESTREO
No Aleatorio.

1.8.3 III ETAPA

UNIVERSO
Area Administrativa del Hospital Huacho – Huaura – Oyon.
UNIDAD MUESTRAL
Para un error estandar del 5% y una probabilidad de ocurrencia del
4% (n=12)
TIPO DE MUESTREO
Probabilístico

-9-
1.9 LA METODOLOGIA

1.10 LOCALIDAD E INSTITUCIÓN DONDE SE DESARROLLA LA TESIS

Nombre o Razón Social del Negocio :

HOSPITAL HUACHO - HUAURA – OYON SERVICIOS BÁSICOS DE SALUD

Ubicación :

El Hospital de apoyo Huacho se encuentra ubicado a 150 Km. al norte de

Lima, fue fundado el 02 de Octubre de 1,970 siendo un Hospital Centro de Salud
con solo las 4 especialidades Básicas. En su evolución, es en 1998 un Hospital
Funcionalmente de Referencia, Centro de una red de Hospitales y Centros de Salud
del Norte Chico con influencia directa en las provincias del Sur del Departamento
de Ancash, tanto de la Sierra como de la Costa.

- 10 -
Distribución Geográfica de los Servicios Básicos de Salud Huaura – Oyón :

ServiciosBásicosdeSaludHuauraOyónpor
Escenarios

OYON
CAU AN
JUL DA
AMBAR CO JES PACHAN
CHA NAVAN CHECR GARA
MAR AS
CA
VEGUETA PACCHO STA.
HUAURA LEONOR
CARQUIN L.PRADO
STA.MARIA
HUALMAY SAYAN
URBANO
HUACHO URBANORURAL
SIERRA

Giro del Negocio:

Prestación de servicios en el área de salud.
Somos una Red de Servicios de Salud constituida por un Hospital Referencial y
Establecimientos Periféricos, que atendemos problemas de Salud en cumplimiento
de nuestro deber como parte del Ministerio de Salud, realizando además docencia e
investigación, impulsando el desarrollo de la Salud Pública.

Sector Económico:
Sector Salud – Pública

- 11 -
 CAPITULO II
MARCO REFERENCIAL
- 12 -
2.1 MANUAL DE ORGANIZACIÓN Y FUNCIONES

2.1.1 MANUAL DE ORGANIZACIÓN

Es un libro que presenta la información básica sobre la estructura y
funcionamiento de una institución, asegurando que las responsabilidades son
comprendidas por los interesados y por los demás miembros de la institución.
Además, se puede afirmar que es un documento administrativo que define la
división del trabajo en la institución, estableciendo los limites de autoridad y
responsabilidad, determinando las funciones de las Unidades Administrativas que la
forman y las relaciones internas y externas de cada una.

El Manual de Organización y Funciones (MOF) es el documento

normativo básico que expresa en detalle la estructura orgánica y la descripción de
las funciones más importantes, relaciones, líneas de autoridad y responsabilidad de
cada uno de los distintos niveles, funcionarios y jefes responsables de cada una de
las unidades orgánicas de las organizaciones.

- 13 -
 La estructura orgánica que se detalla en cada manual son aprobadas
mediante Resolución Presidencial, Resoluciones Directorales. Los gerentes y jefes
de unidad de cada área son responsables de divulgar y mantener actualizado el
contenido del Manual de Organización y Funciones (MOF) con el personal
asignado a su unidad, estableciéndose un canal permanente de comunicación, con el
propósito de que cada persona que ocupa un cargo tenga pleno conocimiento de la
función que cumple y lo que significa en la consecución de los objetivos y planes.
Se debe prever que cada nivel de jefatura cuente con un ejemplar completo del
Manual de Organización y Funciones, independientemente de la distribución de las
funciones específicas que le corresponda a los otros cargos.

2.1.2 OBJETIVOS DEL MANUAL DE ORGANIZACIÓN Y FUNCIONES

Los objetivos a lograrse son los siguientes:

a. Normar la organización interna mediante la definición de su estructura orgánica,

relaciones jerárquicas, funciones y especificaciones para ocupar los puestos de
trabajo.
b. Orientar al personal en lo referente a sus obligaciones, líneas de autoridad y
responsabilidad como sobre los canales de comunicación que debe observar en el
cumplimiento de sus funciones.
c. Proporcionar elementos de juicio en materia de organización y funciones que
sirvan de base para la ejecución de estudios, orientados a optimizar la
administración del recurso humano y de los sistemas y procedimientos de trabajo.
d. Establecer las bases de un sólido y efectivo sistema de control interno, facilitando
la ejecución de auditorias.
e. Facilitar la coordinación y las líneas de comunicación de todos los niveles,

- 14 -
eliminando la duplicación de esfuerzos, confusión e incertidumbre en el manejo de
las actividades de cada nivel, contribuyendo a lograr mayor eficiencia y eficacia de
las áreas orgánicas y del personal.
f. Servir como medio de adiestramiento y orientación permanente al personal,
propiciando una efectiva supervisión.

2.1.3 CONTENIDO Y ALCANCE

El Manual de Organización y Funciones (MOF) describe la organización

interna de una empresa, el objetivo y las funciones generales y específicas de cada
uno de sus niveles jerárquicos con el propósito de lograr objetividad y mayor
comprensión en la descripción, tanto de la estructura orgánica como de las
funciones de los distintos niveles, está diseñado de tal forma para que cada
trabajador conozca su rol dentro de la organización y desempeñe su puesto con
plena responsabilidad, conociendo sus deberes y los límites de su acción, respete el
nivel de competencia de los demás y contribuya con mayor eficiencia al
cumplimiento de los objetivos, estrategias y planes de la institución.

2.1.4 LÓGICA PARA ELABORAR UN MANUAL DE ORGANIZACIÓN

- 15 -
 Para la elaboración de un Manual de Organización, es necesario realizar una
serie de actividades previas, iniciando con un listado de los componentes del
Manual, e investigación documental, archivos y entrevistas preliminares, que
permitan la recopilación de toda la información disponible correspondiente a cada
componente del manual, a continuación y siguiendo las sugerencias de la guía, se va
desarrollando cada uno de estos componentes, al llegar a las políticas, es necesario
realizar consultas especiales a las autoridades y funcionarios relacionados con la
planificación para definir con mucho cuidado las políticas de la institución, debido a
que generalmente las políticas no se encuentran definidas.
En el caso de las funciones, primeramente es importante conocer las
funciones que esten Reglamentadas por Leyes, Decretos y Resoluciones de cada
organización y/o Instituciones , para ello es necesario realizar entrevistas o utilizar
cuestionarios que permitan conocer de fuente primaria la información sobre las
funciones que estan desarrollando en la practica y posteriormente, se determina su
respectiva base legal, de lo contrario será revisada con el titular del área.
Adicionalmente, como insumo se podrá contar con los manuales de descripción de
cargos. Las funciones se ordenarán en orden de importancia y se presentarán
conforme el organigrama, en orden jerárquico y de izquierda a derecha.

2.1.5 BASE TÉCNICA PARA LA ELABORACIÓN DEL MANUAL DE

ORGANIZACIÓN

El manual de organización esta constituido por una serie de componentes

los cuales se enlistan a continuación y se ilustra gráficamente su diseño del manual
en la figura adjunta.
Es importante señalar que los primeros componentes (del 1 al 10)
corresponden al contexto institucional, posteriormente, se abre un espacio para el
contexto de las Unidades Administrativas de la institución en orden jerárquico
(componente 11) y concluye nuevamente en el contexto institucional los
componentes 12 y 13.

- 16 -
Identificación
Índice o contenido
Introducción
Directorio de la institución
Antecedentes
Base Legal
Atribuciones de la Institución
Objetivos
Políticas
Estructura Orgánica: Organigrama maestro hasta el nivel de Departamento u
Oficina o Listado en orden jerárquico de la institución.
Para cada Unidad Administrativa de Dirección o División General:
Organigrama Suplementario detallando la estructura interna de la Dirección o
División, hasta su nivel de Departamento u Oficina. Cuando la entidad así lo estime
conveniente, el alcance del manual de organización incluirá un nivel jerárquico
menor. Además, deberá incluir el objetivo general de la Dirección o División
General.
Funciones específicas para cada Unidad Administrativa que la conforman.
Índice de procedimientos
Glosario de Términos

- 17 -
 Para mayor comodidad y uniformidad, se recomienda que los manuales se
elaboren en hojas de tamaño carta y se use letra tipo Arial tamaño 12.
A continuación se describe como desarrollar cada uno de estos componentes
del manual:

1. Identificación

Es el componente o capítulos que permite conocer los datos relacionados con

el organismo, institución, dirección o división a que se refiere el manual, el
contenido de este componente es el siguiente:
Escudo, Logotipo de la Institución

- 18 -
Nombre oficial del organismo o unidad a que se refiere.
Título y extensión del manual (general o específico).
Niveles jerárquicos que comprenden.
Lugar y fecha de elaboración.
Número de revisión, en su caso.
Unidades responsables de su elaboración.
Cantidad de ejemplares impresos.
Su distribución será así:
El escudo a la izquierda y el logotipo institucional a la derecha, cada uno a 6
cm del borde superior y a 9 cm de los bordes de los lados, con un diámetro o altura
máxima de 3 cm.
La leyenda institucional irá tres cm mas debajo de la línea del escudo y el
logotipo, con letras color negro y fuente tamaño 18.
Seguidamente y en orden descendente a 2 cms. de distancia de la leyenda
institucional irá el título del manual, con letras color negro y fuente tamaño 16.
Continuando en orden descendente y a una distancia proporcional irá el resto
de información con letras color negro y fuente tamaño 14.

2. Índice o contenido

Es una relación de los capítulos que constituyen la estructura del documento.

Se sugiere el formato a continuación, el cual se repetirá para todo el contexto
institucional y solamente variará para las Unidades Administrativas y para el
directorio. Los organigramas por efecto de espacio, podrán ir fuera del formato, es
decir, en hoja blanca.

3. Presentación o introducción

Consiste en una explicación acerca de lo que es el documento, de la ocasión

que da origen a su elaboración o revisión, y de los propósitos básicos que se
pretenden cumplir a través de él. Además, incluye información sobre el ámbito de

- 19 -
su aplicación, a quién va dirigido, cómo se usará y cómo y cuándo se harán las
revisiones y actualizaciones. Es conveniente que contenga un mensaje y la
autorización de la más alta autoridad del área comprendida en el manual.
Observaciones y aclaraciones que deseen incluirse.

4. Directorio

Relación de los funcionarios y de los cargos que ocupan dentro de la

estructura de organización de una Institución. El director deberá ubicarse de acuerdo
con los niveles jerárquicos y siguiendo el orden del organigrama de izquierda a
derecha, es opcional su ubicación, en el actual orden o bien puede ir al final del
documento.
Debe incluirse hasta el nivel de menor jerarquía en la organización. Las
unidades de asesoría se incluyen después de la unidad de que depende.

5. Antecedentes históricos

Breve descripción histórica sobre la Institución.

Origen. Causas que dieron lugar a su creación.
Desarrollo. Señalar modificaciones que se hayan efectuado en cuanto a estructura,
funciones, etc.
(Enunciación. Deberán agotarse todas las fuentes informativas para cubrir este
capítulo: investigación documental, archivos, etc. Se debe anexar al final copia de la
documentación consultada.)

6. Legislación o base legal (marco legal)

Consiste en una relación de los títulos de los principales ordenamientos

jurídicos, de los cuales se derivan las atribuciones de la entidad o de las unidades
administrativas comprendidas en ella; es recompensable de relacionar las

- 20 -
disposiciones jurídicas siguiendo un orden jurídico descendente, según se muestra a
continuación:

Constitución política.
Tratados.
Leyes.
Reglamentos.
Decretos.
Acuerdos Ministeriales y
Circulares u oficios.

7. Atribuciones

Consiste en una trascripción textual y completa de las facultades conferidas a

la entidad, de acuerdo con las disposiciones jurídicas que dan base legal a sus
actividades. Debe señalarse el título completo de los ordenamientos y el capítulo,
artículo y texto de éste.

8. Objetivo

Es el fin que debe alcanzar una Institución a través de las atribuciones

otorgadas por las disposiciones legales.
Objetivos. Son los fines que debe alcanzar la Institución de que se trate. (Si
los objetivos de la institución no están explícitamente determinados en las
disposiciones legales, se determinarán mediante el análisis de diferentes elementos
tales como: exposiciones de motivos de las leyes, atribuciones, funciones y
programas de trabajo).

9. Políticas

Las políticas de la institución son una parte de la planeación y ayudan a ella.

- 21 -
Las políticas dan significado a los objetivos. Por medio de ellas las metas adquieren
una expresión significativa e individual.
Además, son las guías, pautas o lineamientos generales que determinan el
marco de acción o ámbito para la toma de decisiones en la ejecución de programas
estratégicos. En síntesis, son instrumentos que fijan los limites o fronteras a las
acciones administrativas y clarifican la responsabilidad en la ejecución de la
estrategia.
Una política no es lo mismo que una regla. Una regla dice con exactitud qué
no se debe hacer. En contraste, una política es relativamente amplia, general e
indica los límites dentro de los cuales debe desarrollarse la actividad.
La aplicación de las políticas requiere iniciativa, descripción y juicio de
quienes tengan que decidir qué es lo que debe hacerse en situaciones específicas.

10. Estructura orgánica de la institución

Es la forma en que están ordenadas las unidades que componen una entidad
administrativa para la toma de decisiones y la relación que guardan entre sí sus
unidades internas.
Hay dos formas de describir la estructura orgánica:

Listado
Se listan en orden jerárquico cada una de las unidades administrativas
dependencia, a la cual se circunscribe el manual iniciando por los órganos
superiores. Las unidades administrativas se colocan el lugar inmediato inferior al
que dependen. Para facilitar su identificación se utiliza una clave numérica en orden
progresivo, para efectos prácticos, la codificación de las Unidades Administrativas
del Presupuesto General de la República.

Organigrama

- 22 -
 Es la representación gráfica del ordenamiento de las unidades, sus
relaciones, sus niveles jerárquicos, los canales de comunicación, las líneas de
autoridad y supervisión, así como las unidades de categoría especial.
Debe ser de tipo vertical en función de la facilidad de comprensión, ya que
en la parte superior van las unidades directivas, y las líneas de autoridad y
responsabilidad van de arriba hacia abajo.
Las normas a seguir para la elaboración del organigrama, serán dictadas por la
Dirección Administrativa o el Área de planificación teniendo en cuenta las normas
vigentes de cada institución u organización como se indica:

 Principales puestos y unidades que dependen de ella.

 Líneas de autoridad y responsabilidad.
 Relaciones entre las diferentes unidades.
 Definición de las áreas funcionales y sus niveles jerárquicos.

11. Organización y Funciones por Dirección o División General.

Este componente se ordenará conforme la jerarquía que establece el

organigrama general de la institución, y se constituye de información particular de
cada Unidad Administrativa de la institución, mismas que deberán repetirse para
cada una de ellas y que se encuentren dentro de los alcances del manual, detallando
al inicio de cada una su nombre, dependencia orgánica y Unidades Administrativas
subalternas, además deberá detallar para cada uno lo siguiente:

- 23 -
 Elaborar un organigrama suplementario, el cual debe mostrar una sola
dirección o división general con sus componentes principales y ofrecer detalles
sobre relaciones, autoridades y obligaciones de esa dirección o división y su
objetivo general.
Una función es un conjunto de actividades relacionadas entre sí, necesarias
para lograr los objetivos de una institución y de cuya ejecución es responsable una
Unidad Administrativa, siempre que exista entre sus atributos y responsabilidades
un mandato legal.

Por lo tanto, la función siempre se asigna a una Unidad Administrativa, con

el objeto de que las labores sean ejecutadas por las personas que la integran.
En consecuencia, las funciones de cada Unidad Administrativa deben listarse
en orden de importancia en el manual de organización cada una de las actividades
que desempeñan las diversas unidades administrativas objeto de análisis, hasta su
nivel de menor jerarquía en la organización.

12. Índice de procedimientos

Se anotarán los principales procedimientos que se ejecutan en las unidades

administrativas que comprenda el manual. Esta lista servirá como índice de los
manuales de procedimientos que se formulen, en consecuencia, deberá ser
priorizados por las autoridades de las unidades administrativas.

- 24 -
 13. Glosario de términos

Se recomienda que los manuales de organización incluyan una lista de

aquellos términos técnicos que auxilien en la comprensión del texto formulado.
Procesos para la Elaboración, Aprobación y Actualización de los Manuales
de Organización y los roles de las Instancias de las organizaciones e instituciones,
para Formular, Conciliar, Aprobar, Difundir y Evaluar los Manuales.
Para este punto es importante tener presente que todas las instituciones u
organizaciones, deberán designar o contar con una unidad especializada en la
elaboración y revisión de manuales de organización y procedimientos.
Esta Unidad Especializada podrá estar ubicada en el nivel de apoyo en las
Instituciones, y será la única responsable de elaborar y revisar sus propios manuales.

2.2 METODOLOGIA MÉTRICA

Métrica es una metodología propuesta por el Ministerio de las

Administraciones Públicas de España para que todas las organizaciones en ese país
sigan el mismo modelo y unificar los criterios para mayor homogeneidad y
eficiencia en las aplicaciones informáticas.

El grupo considera que se debe implantar METRICA como metodología de

desarrollo de sistemas de información para crear un entorno que permita al equipo
de trabajo construir Sistemas, que:

 Den solución a los objetivos considerados prioritarios en la Administración.

 Se desarrollen cuando el usuario los necesite y de acuerdo con los presupuestos
y duración estimados.
 De calidad que se mantengan fácilmente para soportar los cambios futuros de la
organización.

- 25 -
 Todo ello utilizando un vocabulario común y un conjunto completo de tareas y
productos finales que ayuden a construir con éxito Sistemas de Información.

Esta metodología es una guía formal, aunque flexible en su utilización, para la

Planificación, Análisis, Diseño y Construcción e Implantación de Sistemas de
Información empleando conceptos y técnicas de Ingeniería de Sistemas de
Información y Tecnología de la Información.

La presente metodología ofrece un marco de trabajo en el que se define:

Una estructura de proyecto que sirva de guía al equipo de trabajo e involucre a los
usuarios en su desarrollo y en sus puntos decisivos.

Un conjunto de productos finales a desarrollar.

Un conjunto de técnicas para obtener los productos finales.

Las diferentes responsabilidades y funciones de los miembros del equipo de

proyecto y de los usuarios.

Con este fin, se describe en detalle la sucesión de pasos, estructurados en Fases,

Módulos, Actividades y Tareas, que se han de seguir en el desarrollo de sistemas
informáticos, así como los productos que se obtienen en cada uno de dichos pasos.
Estos productos pueden ser, productos finales o bien productos intermedios que
servirán para la realización de algún paso posterior. Por último se describirá la
estructura final de la documentación obtenida. Las razones que han llevado a definir
esta estructura de Fases y Módulos son las siguientes:

El término Fase conlleva la idea de secuencia, y presenta las características que a

continuación se indican:

Establece un conjunto formal de Productos que deben ser entregados por el equipo
de trabajo antes de que se inicie la siguiente Fase. De esta forma, se pueden dividir

- 26 -
los proyectos en una serie de hitos preestablecidos, que facilitarán las labores de
Planificación y Control de Proyectos.

El final de cada Fase requiere una aceptación formal de las conclusiones a

las que se ha llegado al término de la misma. El producto final obtenido en cada
Fase es un documento que se utiliza para el inicio de la siguiente fase.

La división en Módulos obedece a razones de homogeneidad: Un módulo es

un grupo de actividades y tareas que se realizan para producir un conjunto
específico de productos finales.

La metodología MÉTRICA está dividida en cinco Fases que se

descomponen en siete Módulos. Los Módulos, a su vez, se descomponen en
Actividades y éstas en Tareas. Las fases en las que se divide son:

FASE 0: PLAN DE SISTEMAS DE INFORMACIÓN

FASE 1: ANÁLISIS DE SISTEMAS

FASE 2: DISEÑO DE SISTEMAS

FASE 3: CONSTRUCCIÓN DE SISTEMAS

FASE 4: IMPLANTACIÓN DE SISTEMAS

La estructura de esta metodología no está asociada al modelo de desarrollo

de ciclo de vida en cascada. Ya que prescribe gran cantidad de retornos a nivel de
actividades, módulos e incluso de fases. Además la metodología incluye la
utilización de técnicas de prototipado y otras propias de desarrollos de tipo
evolutivo e incremental.

MÉTRICA está apoyada en una serie de técnicas que dan el soporte práctico
necesario para el desarrollo óptimo de las Actividades definidas en ella, y permite el

- 27 -
empleo de herramientas tecnológicas avanzadas (CASE, Lenguajes 4 Generación,
etc.) que facilitan dicho desarrollo.

A continuación se describen con más detalle cada una de las fases de la

Metodología MÉTRICA.

FASE 0: PLAN DE SISTEMAS DE INFORMACIÓN

La realización de un Plan de Sistemas de Información dentro de cualquier

Organización, tiene como finalidad asegurar la adecuación entre los objetivos
estratégicos de la misma y la información necesaria para soportar dichos grandes
objetivos. Esto hace que una metodología de planificación de sistemas abarque a
toda la organización y exige tener en cuenta una serie de conceptos, en cuanto a
planificación de estrategias que desbordan el marco específico de una Metodología
de Desarrollo de Sistemas.
Conscientes de esta diferencia en cuanto al ámbito que se pretende cubrir con una
Metodología de Planificación de Sistemas, es necesario, sin embargo, establecer una
relación directa entre ambas metodologías, con el fin de que la información obtenida
con una concepción estratégica sirva de entrada y punto de partida para la
especificación de los sistemas concretos a desarrollar.
Para ello, se ha definido la Fase 0 de la Metodología MÉTRICA, con los siguientes
objetivos:

 Definir la información necesaria que se debe obtener con la realización de una

Metodología de Planificación, en cuanto a objetivos estratégicos de la
Organización y factores críticos de éxito para satisfacer estos objetivos.
 Definir la Arquitectura de la Información (procesos y datos) que satisfará los
objetivos estratégicos de la Organización.
 Definir los nuevos sistemas a desarrollar que permitan implantar dicha
Arquitectura. La información obtenida servirá de punto de partida para el
desarrollo de cada uno de estos sistemas con MÉTRICA.

- 28 -
Para el desarrollo de un sistema aislado, cuya necesidad no se derive de un Plan de
Sistemas, no se utilizará la Fase 0 de la Metodología.

FASE 1: ANÁLISIS DE SISTEMAS

El propósito de esta Fase será, en primer lugar, describir el alcance, los objetivos y
los requisitos del Sistema. Basándose en todo esto, el equipo del proyecto puede
examinar distintas alternativas que podrían solucionar el problema y recomendar
una de ellas. Con la finalización del primer módulo de esta Fase, Análisis de
requisitos del Sistema, se obtendrá, como producto final, un documento donde se
establecerá:

 El alcance del Proyecto.

 El Modelo Lógico Actual de Procesos y el Esquema Lógico Actual de
Datos.
 Los requisitos de usuario.
 El análisis de alternativas, y la solución propuesta.

El segundo objetivo de esta Fase es elaborar un conjunto de especificaciones

formales que describan la funcionalidad del Sistema para su aprobación por parte
del usuario. Esta descripción se documentará en el módulo siguiente de esta Fase,
Especificación Funcional del Sistema, que deberá incluir:

 Definición de los Subsistemas.

 Definición de los datos del Sistema.
 Interfases de usuario y prototipos.
 Especificación de la entrega.

FASE 2: DISEÑO DE SISTEMAS

El propósito de esta Fase de Diseño de Sistemas será obtener un conjunto de

especificaciones físicas que constituirán el punto de partida para la construcción del
Sistema.

- 29 -
Durante el desarrollo de las actividades definidas en esta Fase, se deberá tener en
cuenta el entorno tecnológico donde se implantará el sistema.

Este aspecto específico hace necesaria una adaptación muy especial de esta Fase de
MÉTRICA al entorno físico que posea el Departamento o Unidad de la
Administración que comience a utilizar en sus proyectos los estándares aquí
representados.

FASE 3: CONSTRUCCIÓN DE SISTEMAS

El propósito de esta Fase será construir el sistema partiendo del conjunto de

especificaciones físicas del mismo, obtenidas durante la Fase anterior. (Módulo de
desarrollo de Componentes del Sistema)

Asimismo, se contemplará la realización de las pruebas unitarias necesarias para

asegurar el perfecto funcionamiento de los programas desarrollados.

Durante esta Fase se establecerá la estrategia para desarrollar los procedimientos de

usuario y el plan de formación a usuario, identificando los recursos para su
realización. (Módulo de desarrollo de Procedimientos de Usuario)

FASE 4: IMPLANTACIÓN DE SISTEMAS

El propósito de la Fase de Pruebas e Implantación es probar el equipo lógico,

los procedimientos de usuario y la efectividad de la formación para que, una vez
aceptado el sistema, se implante y pase a funcionar en un entorno real de
producción.
El objetivo fundamental es conseguir la aceptación final del sistema por parte de
los usuarios del mismo, para ello:

 Se combinarán por primera vez todo el equipo lógico y los procedimientos

para un trabajo del sistema real.

- 30 -
  Se realizarán las pruebas de aceptación, las cuales constituyen un
procedimiento formal ejecutado por los usuarios que permite verificar que el
sistema producido es totalmente funcional y satisface los requisitos iniciales,
como un paso previo a su implantación.
 Se realizarán los procedimientos necesarios para la implantación y puesta en
producción del sistema.

Las técnicas de la metodología son:

 Diagramas de flujo de datos

 Modelado de datos
 Historia de la vida de las entidades
 Entrevistas
 Diseño estructurado
 Análisis Coste-Beneficio
 Pruebas
 Factores críticos de éxito

2.2.3 METODOLOGIA UML

UML (Unified Modeling Language) es un lenguaje para especificar,

visualizar, construir y documentar los elementos de un sistema software, así como
para modelado de procesos de negocio u otros sistemas no-software. UML reune
una colección de las mejores prácticas en la ingeniería que han sido utilizadas con
éxito para modelar sistemas grandes y complejos.

El Unified Modeling Language (UML) es una notación que evolucionó a

partir del diseño basado en Booch, OMT (Rumbaugh), OOSE (Jacobson) y de los
métodos orientados a objetos. UML ha sido creado por los expertos en metodología
Grady Booch, Ivar Jacobson, y Jim Rumbaugh en Rational Software, utilizando
información de otros importantes expertos en metodología, vendedores de software,

- 31 -
y usuarios finales. Su objetivo era unificar los diversos sistemas que había y crear
un lenguaje de modelado con las mejores características de cada uno.

UML (Unified Modeling Language),es la metodología más avanzada en la

actualidad.
Esta metodología introduce los Casos de Uso, una poderosa herramienta para
reducir los riesgos en la definición de requerimientos de sistemas nuevos. Los Casos
de Uso sirven como columna vertebral del proceso de desarrollo de aplicaciones y
tienen como objetivo garantizar que los resultados se apeguen completamente a las
expectativas de los usuarios finales.

2.2.4 OBJETIVOS

Sensibilizar al personal de las empresas en la importancia de ser parte

integral del proceso de desarrollo de aplicaciones
Reducir los riesgos en la definición de requerimientos de nuevas aplicaciones
Brindar un medio de comunicación concreta de requerimientos a los usuarios finales
de las aplicaciones
Acelerar el proceso de desarrollo de aplicaciones nuevas al integrar a los
usuarios al proceso y la metodología orientada a objetos
Permitir el dominio de los usuarios finales de las técnicas básicas de elaboración y
lectura de casos de uso.
Las metas claves para el desarrollo del UML están en:
Integrar la mejor práctica en la industria del software en una notación y
terminología aceptada comúnmente;
Proporcionar la habilidad para representar todo de los conceptos generalmente
relevantes para los sistemas de software, y;
Preparar Software Avanzado que proporcione los siguientes diagramas gráficos
para el diseño del software:
o Diagrama de Uso de Casos (Use Case Diagram).
o Diagrama de la Estructura de Clases (Class Structure Diagram).
o Diagrama de Comportamiento (Behavior Diagrams):

- 32 -
 o Diagrama de Estado (State Diagram).
o Diagrama de Secuencia (Sequence Diagram).
o Diagrama de Colaboración (Collaboration Diagram):
o Diagrama de Actividad (Activity Diagram).
o Diagramas de Implementación (Implementation Diagrams).
o Diagrama de Componentes (Component Diagram)
o Diagrama de Despliegue (Deployment Diagram).

Modelado del Uso de Casos con UML

Es una técnica orientada al uso de casos y al manejo de los requerimientos
necesarios durante el progreso de un proyecto. El modelado de uso de casos fue
introducido por primera vez por Ivar Jacobson en el Object Oriented Software
Engineering (OOSE).
Requerimientos
Análisis
Uso de casos
Diagrama de Clases
Diagramas de Estado
Diseño
Diagramas de Interacción
Diagramas de Colaboración
Diagramas de Secuencia
Diagramas de Actividad
Diagramas del Detalle de Clases
Implementación
Diagramas de Componentes
Diagramas de Despliegue

Diseño
- Diagrama de Secuencia (Sequence Diagram): En este diagrama se muestra el
tiempo de secuencia de la interacción, así como de la participación de los objetos.

- 33 -
Además contiene dos dimensiones de secuencia que consisten en una dimensión
vertical (tiempo), y horizontal (objetos diferentes).
- Diagrama de Colaboración (Collaboration Diagram): Este diagrama muestra una
interacción organizada alrededor de los objetos en la interacción y sus ligas (links)
entre otros. Además de las relaciones entre los objetos, no en tiempo, pero la
secuencia de números son utilizados para mostrar la secuencia de mensajes.

- Diagrama de Actividad (Activity Diagram): Este es un diagrama especial de un

diagrama de estados (state diagram)donde todos los estados o al menos la mayoría
de ellos, son estados de acción y gran parte de las transiciones son activadas por la
realización de acciones en los estados fuente. Todo el diagrama de actividad es
ligado (a través del modelo) a las clases o a la implementación de una operación o
un uso de casos. La propuesta de este diagrama es enfocarse en el manejo de flujos
por procesamiento interno. Se utiliza los diagramas de actividad en situaciones
donde todo o la mayoría de los eventos representan la realización de acciones
generadas internamente
(procedimientos de flujo de control).

Implementación
- Diagramas de Implementación (Implementation Diagrams): Las dos formas son
los diagramas de componentes, los cuales muestran la estructura de su código, y
diagramas de despliegue, los cuales muestran la estructura del tiempo de ejecución
del sistema.

- Diagrama de Componentes (Component Diagram): Dependencias entre los

componentes del software muestran componentes del código fuente, componentes
del código binario, y componentes ejecutables. Algunos componentes existen en
tiempos de compilación, tiempos de enlace, tiempos de ejecución, y otros existen en
más de un tiempo.

- Diagrama de Despliegue (Deployment Diagram): Los diagramas de despliegue

muestran la configuración del tiempo de ejecución del procesamiento de elementos

- 34 -
y de componentes de software, procesos, y objetos que viven en ellos. Instancias de
los componentes del software representan la manifestación del tiempo de ejecución
de las unidades de código.

Integración de UML en el ciclo de vida de MÉTRICA

Como afirman, UML es un lenguaje (notación) para el modelado de objetos

y no una metodología de desarrollo orientado a objetos; por lo tanto, ha sido
concebida de manera que sea indiferente al método OO que se utilice.
En el caso de MÉTRICA, al no tratarse de una metodología orientada a
objetos, la aplicación de UML precisaría previamente la re-definición de algunas de
sus fases, módulos, actividades y tareas. En la tabla Nº 1 se especifica con detalle
una posible modificación del ciclo de vida de MÉTRICA para convertirla en una
metodología OO, realizando el mínimo numero de cambios sobre el ciclo de vida
original, para evitar a los usuarios una transición traumática de uno a otro enfoque.
La mayor parte de los cambios propuestos se refieren a las actividades de análisis y
diseño indicadas en la tabla 1. Las técnicas de UML que se utilizarían en estas
actividades y tareas son las que se muestran en la tabla 2.

Actividades MÉTRICA v2.1 (Estructurada) MÉTRICA OO

y Tareas
ARS 3.1 Construcción del Modelo Lógico Construcción del Modelo de
actual de Procesos Comportamiento del Sistema
actual
ARS 3.2 Construcción del Modelo Lógico Construcción del Modelo de
actual de Datos Estructura de Objetos del Sistema
actual
EFS 1 Construir el Modelo de Procesos Construir el Modelo de
del nuevo Sistema Comportamiento del nuevo
Sistema
EFS 2 Construir el Esquema Lógico de Construir el Modelo de Estructura
Datos del nuevo Sistema de Objetos del nuevo Sistema
EFS 3.1 Construcción del Modelo Construcción de los Modelos de
Entidad-Evento Interacción y Estados
EFS 3.2 Consolidación de los Modelos de Consolidación de los Modelos de
Datos y Procesos Comportamiento y Estructura de

- 35 -
 Objetos
DTS 1 Diseñar la Arquitectura Física Diseñar la Arquitectura Lógica del
del Sistema Sistema
DTS 2 Diseñar la Estructura Física de Diseñar la Arquitectura Física del
Datos del Sistema Sistema

Tabla Nº 1 Principales actividades y tareas que se verían afectadas

por la incorporación del enfoque OO en MÉTRICA

Actividades Técnicas de UML

y Tareas
ARS 3.1 Diagrama de Casos de Uso, [Diagrama de Interacción (Secuencia o
Colaboración), Diagrama de Actividad, Diagrama de Estados]
ARS 3.2 Diagrama de Clases
EFS 1 Diagrama de Casos de Uso, [Diagrama de Interacción (Secuencia o
Colaboración), Diagrama de Actividad, Diagrama de Estados]
EFS 2 Diagrama de Clases
EFS 3.1 Diagrama de Interacción (Secuencia o Colaboración), Diagrama de
Estados
EFS 3.2 Diagrama de Clases, Diagrama de Interacción (Secuencia o
Colaboración), Diagrama de Estados, [Diagrama de Actividad]
DTS 1 Diagrama de Clases, Diagrama de Interacción (Secuencia o
Colaboración), Diagrama de Estados, [Diagrama de Actividad]
DTS 2 Diagrama de Componentes, Diagrama de Despliegue, Diagrama de
Clases, Diagrama de Interacción (Secuencia o Colaboración),
Diagrama de Estados, [Diagrama de Actividad]

Tabla Nº 2 Integración de las técnicas de UML en las actividades y tareas de

MÉTRICA

Integración de UML en la documentación de MÉTRICA

Al integrar UML en la metodología MÉTRICA se produce una serie de

cambios en la documentación que se genera al final de cada fase como resultado de
la realización de las distintas actividades y tareas. Los documentos de MÉTRICA
que se verán afectados en mayor medida serán el Documento de Diseño Funcional
(DDF), generado al final de la fase de Análisis; y el Documento de Diseño Técnico
(DDT), que se genera al final de la fase de Diseño.
En las figuras 1 y 2 se representa la estructura de estos documentos. Las
diferencias con respecto a los documentos originales de MÉTRICA se han resaltado

- 36 -
como zonas sombreadas. En el Documento de Diseño Funcional, son los apartados
2 y 3 los que deben sufrir los mayores cambios; así, los apartados originales
denominados “2.1 Modelo de Procesos de cada Subsistema”, “2.2 Modelo de
Procesos de las Funciones de cada Subsistema” y “2.3 Modelo de Procesos de las
Subfunciones de cada Función”, que contenían los modelos funcionales en forma de
Diagramas de Flujo de Datos, han sido substituidos por un único apartado con el
nombre de “2.1 Modelo de Comportamiento de cada Subsistema”, que incluye
Diagramas de Casos de Uso, Diagramas de Interacción y Diagramas de Actividad
establecidos por UML. También el apartado “3. Modelo de Datos del Sistema” de
MÉTRICA, que contenía Diagramas de Entidad-Relación, ha sido substituido por el
titulado “3. Modelo de Estructura de Objetos del Sistema”, que incluye el diagrama,
o diagramas, de Clases del Sistema según la notación UML.
En el caso del Documento de Diseño Técnico, la integración de UML
supone una modificación substancial del apartado “1. Diseño de la Arquitectura del
Sistema”, ya que la técnica utilizada en MÉTRICA, conocida como Diagrama de
Estructura de Cuadros, basada en un enfoque de diseño que considera una
descomposición funcional, e independiente de los datos, del Sistema de Información
a construir, es substituida por los Diagramas Clases, Diagramas de Componentes y
Diagramas de Despliegue de UML, basados en el enfoque de objetos que considera
la integración de las funciones del sistema en el interior de los objetos junto con los
datos.
En este documento se mantiene el modelo de clases del Sistema incluido en
el Documento de Diseño Funcional, que ha debido ser completado durante la fase
de Diseño con clases de interfase, de gestión de datos, de gestión de procesos o
tareas, y de utilidad; asimismo, también se habrá refinado la especificación de las
clases del dominio del problema establecidas durante la fase de Análisis, ofreciendo
este documento toda la información necesaria para proceder a la construcción del
Sistema.

DOCUMENTO DE DISEÑO FUNCIONAL (DDF)

1. Especificación del Sistema Propuesto.

- 37 -
 1.1 Diagrama de Casos de Uso del Sistema
1.2 Diseño de Subsistemas.
1.2.1 Diagramas de Casos de Uso
1.2.2 Descripción de los Componentes.
2. Especificación de Subsistemas.
2.1 Modelo de Comportamiento de cada Subsistema.
2.1.1 Diagrama de Casos de Uso (DCU) de cada Subsistema.
2.1.2 Descripción de los Componentes de los DCU.
2.1.3 Diagramas de Interacción (DI) de cada Caso de Uso.
2.1.4 Diagrama de Actividad de cada DI.
2.1.5 Descripción de los Componentes de los DI.
3. Modelo de Estructura de Objetos del Sistema.
3.1 Diagrama de Clases.
3.2 Descripción de Clases.
3.2.1 Atributos (descripción y formato).
3.2.2 Operaciones (descripción).
3.2.3 Diagrama de Estados.
3.3 Descripción de relaciones.
4. Interfaces de usuario.
4.1 Pantallas.
4.1.1 Diálogo de Pantallas.
4.1.2 Mapa de Pantallas.
4.1.3 Elementos asociados.
4.1.4 Identificación de diálogos críticos.
4.2 Informes.
4.2.1 Formato de Informe.
4.2.2 Elementos asociados.
5. Otras Especificaciones no funcionales del Sistema.
5.1 Especificación de Requisitos de Seguridad y Control.
5.2 Especificación de Requisitos de Respaldo y Recuperación de Errores.
5.3 Especificación de Requisitos de Rendimiento.
6. Especificaciones de la Entrega.
6.1 Plan de Desarrollo y Entrega del nuevo Sistema.
6.2 Revisión del Plan del Proyecto.
7. Control de Calidad de la Especificación Funcional.
7.1 Validación del Modelo de Comportamiento.
7.2 Validación del Modelo de Estructura de Objetos.
7.3 Seguimiento de los Requisitos de Usuario.

Fig 1. Resultado de la integración de UML en el Documento de Diseño Funcional

DOCUMENTO DE DISEÑO TÉCNICO (DDT)

1. Diseño de la Arquitectura del Sistema.

1.1 Diagramas de Clases y Componentes del Sistema.
1.2 Diseño del Componente del Dominio del Problema (CDP).
1.2.1 Diseño de cada Clase del CDP.
1.2.1.1 Atributos.
1.2.1.2 Especificación de Operaciones.
1.2.1.3 Pantallas e Informes asociados.
1.2.2.4 Diagrama de Estados.
1.2.2 Diagramas de Interacción.
1.3 Diseño del Componente de Interface con el Usuario (CIU).
1.3.1 Diseño de cada Clase del CIU.
1.3.2 Diagramas de Interacción.
1.4 Diseño del Componente de Interface con Sistemas Externos (CSE)

- 38 -
 1.4.1 Diseño de cada Clase del CSE.
1.4.2 Diagramas de Interacción.
1.5 Diseño del Componente de Gestión de Datos (CGD)
1.5.1 Diseño de cada Clase del CGD.
1.5.2 Diagramas de Interacción.
1.6 Diseño del Componente de Gestión de Tareas (CGT).
1.6.1 Diseño de cada Clase del CGT.
1.6.2 Diagramas de Interacción.
1.7 Diseño del Componente de Servicios de Utilidad (CSU).
1.7.1 Diseño de cada Clase del CSU.
1.7.2 Diagramas de Interacción.
1.8 Diseño del Despliegue del Software en el Hardware.
2. Diseño Físico de Datos.
2.1 Estructura Física de la Base de Datos o de los Ficheros.
2.2 Estructura de Tablas y Vistas.
2.3 Ficheros Auxiliares.
2.4 Descripción de atributos.
3. Entorno Tecnológico del Sistema.
3.1 Especificaciones del Entorno Tecnológico.
3.1.1 Equipo Físico.
3.1.2 Equipo Lógico.
3.1.3 Comunicaciones
3.2 Restricciones Técnicas.
4. Especificación del Plan de Desarrollo e Implantación.
5. Control de Calidad del diseño Técnico
5.1 Revisión del Diseño Técnico.
5.1 Validación del Diseño Técnico.

Fig. 2. Resultado de la integración de UML en el Documento de Diseño Técnico

Análisis y Diseño Orientado a Objetos usando la notación UML

UML = Unified Modeling Language

Un lenguaje de propósito general para el modelado orientado a objetos
Documento “OMG Unified Modeling Language Specification”
UML combina notaciones provenientes desde:
Modelado Orientado a Objetos
Modelado de Datos
Modelado de Componentes
Modelado de Flujos de Trabajo (Workflows)
Comenzó como el “Método Unificado”, con la participación de Grady Booch y Jim
Rumbaugh. Se presentó en el OOPSLA’95. El mismo año se unió Ivar Jacobson. Los “Tres
Amigos” son socios en la compañía Rational Software. Herramienta CASE Rational Rose

- 39 -
Inconvenientes en UML

Definición del proceso de desarrollo usando UML.

UML no es una metodología.
Falta integración con respecto de otras técnicas tales como patrones de diseño, interfaces
de usuario, documentación, etc.
Ejemplos aislados
“Monopolio de conceptos, técnicas y métodos en torno a UML”.

Perspectivas de UML

UML será el lenguaje de modelado orientado a objetos estándar predominante los próximos
años
Razones:
Participación de metodólogos influyentes
Participación de importantes empresas
Aceptación del OMG como notación estándar
Evidencias:
Herramientas que proveen la notación UML
“Edición” de libros

Diagramas de UML

- 40 -
 Diagrams
Diagramas de
Diagramas de Clases
ams de
Diagramas
Diagramas de Casos de Uso
Objetos
Secuencia

Diagramas de Diagramas de
Colaboración Componentes
Modelo

Scenario Diagrams
Diagramas de Diagramas de
Diagrams Distribución
Estados
Diagramas de
Actividad

Diagrama de Casos de Uso

Diagrama de Clase (incluyendo Diagrama de Objetos)
Diagramas de Comportamiento
Diagrama de Estados
Diagrama de Actividad
Diagramas de Interacción
Diagrama de Secuencia
Diagrama de Colaboración
Diagramas de implementación
Diagrama de Componentes
Diagrama de Despliegue

Paquetes en UML

- 41 -
Los paquetes ofrecen un mecanismo general para la organización de los modelos agrupando
elementos de modelado Se representan gráficamente como cada paquete corresponde a un
subconjunto del modelo y contiene, según el modelo, clases, objetos, relaciones,
componentes y diagramas asociados.

Nombre de
paquete

Un paquete puede contener otros paquetes, sin límite de anidamiento pero cada elemento
pertenece a (está definido en) sólo un paquete.
Una clase de un paquete puede aparecer en otro paquete por la importación a través de una
relación de dependencia entre paquetes
Todas las clases no son necesariamente visibles desde el exterior del paquete, es decir, un
paquete encapsula a la vez que agrupa
El operador “::” permite designar una clase definida en un contexto distinto del actual
Por ejemplo, la expresión Ventas::Producto designa la clase Producto definida en el
paquete Ventas.

Diagramas de Casos de Uso

Casos de Uso es una técnica para capturar información de cómo un sistema o negocio
trabaja actualmente, o de cómo se desea que trabaje

- 42 -
 Verificar Situación
Vendedor

Cliente

Establecer Crédito
Supervisor

Preparar Catálogo
Secretaria

Tipos de Venta

No pertenece estrictamente al enfoque orientado a objeto, es una técnica para

captura de requisitos.
Ejemplos
En el paquete tipos de venta

Venta Normal

Venta en Rebajas
Cliente Vendedor

Venta en Oferta

- 43 -
 Reintegro cuenta corriente <<uses>>

Cliente Validar operación

<<uses>>

Reintegro cuenta crédito

- 44 -
Diagramas de Secuencia

: Libro : Ficha socio : Ficha libro : Préstamo

: Socio : Encargado

Coger libro

Solicitar préstamo

Verificar situación socio

Situación socio ok

Verificar situación libro

Situación libro ok

Introducir préstamo

Autorizar préstamo

Diagramas de Colaboración

Son útiles en la fase exploratoria para identificar objetos

La distribución de los objetos en el diagrama permite observar adecuadamente la
interacción de un objeto con respecto de los demás
La estructura estática viene dada por los enlaces; la dinámica por el envío de mensajes por
los enlaces

- 45 -
 1: Coger libro : Libro

: Socio 2: Solicitar préstamo : Ficha s

ocio
3: Verificar situación socio

8: Autorizar préstamo
4: Situación socio ok

6: Situación libro ok : Encargado

: Présta
7: Introducir préstamo mo

5: Verificar situación libro

: Ficha li
bro

Diagramas de Clases (y objetos)

El Diagrama de Clases es el diagrama principal para el análisis y diseño

Un diagrama de clases presenta las clases y objetos del sistema con sus relaciones
estructurales y de herencia
La definición de clase u objeto incluye definiciones para atributos y operaciones
El trabajo realizado en los D. de Casos de Uso, D. de Secuencia y D. de Colaboración
aporta información para establecer las clases, objetos, atributos y operaciones

Ejemplos (Clase y Visibilidad)

- 46 -
Ejemplos (Asociación)

dirige director
Departamento Profesor
0..1 1

Ejemplos (Clase Asociación)

… Ejemplos (Generalización)

- 47 -
 Empleado

{disjunta, completa}

Directivo Administrativo Obrero

… Ejemplos

Motor Piloto Vendedor de billetes

1..4 1..2 1

1 * *
Avión 1 * Vuelo 1 * Reserva

*
{ disjunta, completa }

1
Avión militar Avión comercial Línea aérea

{ disjunta, completa }

Avión de carga Avión de pasajeros

- 48 -
Diagramas de Estados
Los Diagramas de Estados representan autómatas de estados finitos, desde el p.d.v. de los
estados y las transiciones
Son útiles sólo para los objetos con un comportamiento significativo
El resto de objetos se puede considerar que tienen un único estado
El formalismo utilizado proviene de los Statecharts (Harel)
Cada objeto está en un estado en cierto instante
El estado está caracterizado parcialmente por los valores de los atributos del objeto
El estado en el que se encuentra un objeto determina su comportamiento
Cada objeto sigue el comportamiento descrito en el D. de Estados asociado a su clase
Los D. De Estados y escenarios son complementarios
Los D. de Estados son autómatas jerárquicos que permiten expresar concurrencia,
sincronización y jerarquías de objetos
Los Diagramas de Estados son grafos dirigidos
Los D. De Estados de UML son deterministas
Los estados inicial y final están diferenciados del resto
La transición entre estados es instantánea y se debe a la ocurrencia de un evento

alta baja

número_préstamos = 0
sin préstamos

prestar devolver[ número_préstamos = 1 ]

número_préstamos > 0

con préstamos

prestar

devolver[ número_préstamos > 1 ]

- 49 -
Diagramas de Actividad

El Diagrama de Actividades es una variante de los Diagramas de Estados, organizado

respecto de las acciones y principalmente destinado a representar el comportamiento
interno de un método (la realización de una operación), de un caso de uso o de un proceso
de negocio (Workflow)
Una actividad puede considerarse un estereotipo de estado
Las actividades se enlazan por transiciones automáticas
Cuando una actividad termina se desencadena el paso a la siguiente actividad
Las actividades no poseen transiciones internas ni transiciones desencadenadas por eventos.

[no hay café] [no zumo]

Buscar Bebida

[hay café [hay zumo]

Poner café en filtro Añadir agua al depósito Coger

taza

Poner filtro en máquina Coger zumo

Encender máquina

^cafetera.On
Café en preparación

indicador de fin
Servir café
Beber

- 50 -
Diagramas Componentes
Los diagramas de componentes describen los elementos físicos del sistema y sus relaciones
Muestran las opciones de realización incluyendo código fuente, binario y ejecutable
Los componentes representan todos los tipos de elementos software que entran en la
fabricación de aplicaciones informáticas. Pueden ser simples archivos, paquetes de Ada,
bibliotecas cargadas dinámicamente, etc.
Cada clase del modelo lógico se realiza en dos componentes: la especificación y el cuerpo

Control y Análisis
Interfaz de Terminal Comment
Comment

Gestión de Cuentas
Rutinas de Coneccion Acceso a BD
Comment Comment Comment

La representación gráfica es la siguiente:

Especificación Cuerpo Genérico

Package Package Generic

specification body package

- 51 -
Diagramas de Distribución

Los Diagramas de Distribución muestran la disposición física de los distintos nodos que
componen un sistema y el reparto de los componentes sobre dichos nodos
Los estereotipos permiten precisar la naturaleza del equipo:
Dispositivos
Procesadores
Memoria
Los nodos se interconectan mediante soportes bidireccionales (en principio) que pueden a
su vez estereotiparse.

Servidor Central Control y Análisis

Acceso a BD Comment
Comment

Rutinas de Coneccion
Comment

Terminal de Consulta
Interfaz de Terminal
Rutinas de Coneccion
Comment Comment

Punto de Venta
Rutinas de Coneccion
Comment
Gestión de Cuentas Interfaz de Terminal
Comment Comment

- 52 -
RESUMEN

Captura de Requisitos Análisis y Diseño Implementación

Diagramas de
Estados

Diagramas de
Secuencia Diagramas de
Distribución

Diagramas de Diagramas
Casos de Uso De Clases

Diagramas de Diagramas de
Colaboración Componentes

Diagramas de Diagramas de
Actividad Actividad

Proceso de Desarrollo de SW con UML

Un proceso de desarrollo de programas tiene como objetivo la formalización de las

actividades relacionadas con la elaboración de sistemas informáticos
Debe ser:
Reproducible
Definido
Medible en cuanto a rendimiento
Optimizable

UML no incorpora por sí mismo el modelo de proceso

Los autores destacan las siguientes características de UML como esenciales para
determinar el proceso de desarrollo:
Está dirigido por los casos de uso: desde la especificación hasta el mantenimiento

- 53 -
 Se centra en la arquitectura: reutilizable y como guía hasta la solución
Iterativo e incremental: el trabajo se divide en iteraciones pequeñas en función de la
importancia de los casos de uso y el estudio de riesgos

Ciclo de Vida Iterativo e Incremental

El ciclo de vida iterativo se basa en la evolución de prototipos ejecutables que se muestran

a los usuarios y clientes
En el ciclo de vida iterativo a cada iteración se reproduce el ciclo de vida en cascada a
menor escala
Los objetivos de una iteración se establecen en función de la evaluación de las iteraciones
precedentes
Las actividades se encadenan en una mini-cascada con un alcance limitado por los
objetivos de la iteración.

¡Error!
Análisis

Diseño

Codific.

Pruebas e
Integración

n veces

- 54 -
Cada iteración comprende:
Planificar la iteración (estudio de riesgos)
Análisis de los Casos de Uso y escenarios
Diseño de opciones arquitectónicas
Codificación y pruebas. La integración del nuevo código con el existente de
iteraciones anteriores se hace gradualmente durante la construcción
Evaluación de la entrega ejecutable (evaluación del prototipo en función de las
pruebas y de los criterios definidos)
Preparación de la entrega (documentación e instalación del prototipo)

Fases del Ciclo de Vida

El ciclo de vida para UML consiste en una serie de ciclos cada uno de los cuales produce
una nueva versión del producto
Cada ciclo está compuesto por fases y cada una de estas fases está compuesta por un
número de iteraciones
Las fases son:
Estudio de oportunidad
Elaboración
Construcción
Transición
Estudio de oportunidad (inception)
Define el ámbito y objetivos del proyecto
Se define la funcionalidad y capacidades del producto
Elaboración
Tanto la funcionalidad como el dominio del problema se estudian en profundidad
Se define una arquitectura básica
Se planifica el proyecto considerando recursos disponibles

- 55 -
Construcción
El producto se desarrolla a través de iteraciones donde cada iteración involucra
tareas de análisis, diseño e implementación
Las fases de estudio y análisis sólo dieron una arquitectura básica que es aquí
refinada de manera incremental conforme se construye (se permiten cambios en la
estructura)
Gran parte del trabajo es programación y pruebas
Se documenta tanto el sistema construido como el manejo del mismo
Esta fase proporciona un producto construido junto con la documentación
Transición
Se libera el producto y se entrega al usuario para un uso real
Se incluyen tareas de marketing, empaquetado atractivo, instalación, configuración,
entrenamiento, soporte, mantenimiento, etc.
Los manuales de usuario se completan y refinan con la información anterior
Estas tareas se realizan también en iteraciones

- 56 -
2.3 LA PRODUCTIVIDAD

A lo largo de los años se ha intentado hacer cada vez mas eficiente a las
Organizaciones, dado a esto se han reformulado muchos datos y antecedentes, o
simplemente se han mejorado. El tema de los Recursos Humanos que preocupa y
esta pendiente en cada Organización, para optimizar los niveles Jerárquicos de esta
y lograr así el buen funcionamiento.

Integrar es obtener y articular los elementos materiales humanos de la

organización y la planeación sentaran como elementos necesarios para el adecuado
funcionamiento de una organización.
Las personas que han de desempeñar cualquier función dentro de un
organismo social, deben buscarse siempre bajo el criterio de que reúnan los
requisitos mínimos para desempatarla adecuadamente en otros términos: debe
procurarse adaptar las personas a las funciones, y no las funciones a las personas.
Es claro que quienes carezcan de los requisitos físicos mínimos,
intelectuales, sociales o morales para desempeñar un puesto o función, por sencillo
que parezcan, lo realizará mal, de ahí “El personal adecuado para el puesto
adecuado”.

Dentro de una Organización se presenta cada puesto para facilitar el logro de

los objetivos de la organización, esto se logra coordinando el contenido de los
puestos para llevar a cabo funciones o actividades en particular.

2.3.1 Productividad

Se dice que una organización es productiva cuando finaliza sus metas.

Transforma Inputs en Outputs ( productos, servicios ) con el menor coste posible; es
eficaz y eficiente.
Eficaz: Consigue el objetivo.
Eficiente: Consigue el objetivo con el menor coste posible.

- 57 -
Eficacia a nivel individual: Objetivos del propio puesto de trabajo. El ajuste
persona / puesto nos da información sobre la eficacia / eficiencia del sujeto. Un
sujeto que consigue los objetivos es eficaz por definición. Cuando tengamos más
información podremos decir si es eficiente o no.

2.3.2. LA VALORACIÓN DEL RENDIMIENTO

El proceso de valoración es conjunto de procedimientos que permite recoger,

comprobar, compartir, ofrecer y utilizar información recabada de y sobre las
personas en el trabajo, con ánimo de mejorar su actuación en él.
La valoración es un concepto dinámico. Las técnicas de valoración juzgan a
posteriori la idoneidad del trabajador.
Debe ser un procedimiento continuo, sistemático, orgánico y en cascada, de
expresión de juicios acerca del personal de la empresa, en relación con su trabajo
habitual, que pretende sustituir a los juicios ocasionales y formulados de acuerdo
con los más variados criterios.

Finalidades de la valoración

Como base para el establecimiento de un correcto sistema de retribuciones.

Como instrumento para la identificación y desarrollo del potencial de los
empleados. Una vez que se han identificado cuales son los potenciales que se
poseen, es cuando se está en condiciones de desarrollar los planes de formación
necesarios.
Un correcto sistema de valoración permite determinar la eficacia de otras
herramientas de este campo de dirección. Por medio de la valoración, se puede
comprobar si los pronósticos que se efectuaros cuando se aplicaban las
anteriores técnicas se cumplieron o no.
Como instrumento para la mejora de las relaciones entre la dirección y los
subordinados.

- 58 -
2.3.3 LA RESPONSABILIDAD EN EL TRABAJO

Responsabilidad es una palabra compuesta: RESPONS; es respuesta, con

opción propia, HABILIDAD; es capacidad por acción. Tiene 3 vertientes o
dimensiones:

Individual: un LÍDER RESPONSABLE es una persona con capacidad de

respuesta, una persona que se visualiza a sí misma como protagonista de sus
acciones y resultados, por lo tanto su acto es libre, consciente y consecuencial,
impresión externa, ante "presión o vigilancia".
Un LÍDER RESPONSABLE responde, primero que todo, ante sí mismo, sin
duda es un punto coordinador e integrador de gente, recursos, procesos y resultados,
depende de ser un "controlador" de responsabilidades.
Un líder responsable de sí mismo es lo que hace la diferencia, esté o no un
superior, exija éste o no responsabilidad. En este sentido EL CRECIMIENTO
PSICOLÓGICO DE LA PERSONA, es la base. Siendo LA AUTOESTIMA el
centro direccionador de una persona responsable y autoactivada. La autoestima le
proporciona al sujeto los valores: confianza en sí mismo, autonomía, respeto y
criterio propio (autoeficacia y autodignidad).
Colectiva: es la capacidad de influir, en lo posible, en las decisiones de una
colectividad, "de que se pega se pega", responder sin dañar el colectivo al mismo
tiempo que respondemos de las decisiones que se toman como grupo social en
donde estamos incluidos.
Generacional: Hay responsabilidad colectiva, generacional; yo debo
responder por mis hijos y mi generación, debe preocuparme qué hijos les dejo al
mundo. Intentaremos reflexionar sobre estos aspectos A NIVEL EMPRESARIAL.

La responsabilidad en el trabajo determina

Puntualidad, presencia adecuada, disposición.

- 59 -
 Realización del trabajo a conciencia tanto en la dedicación de tiempo como
en la calidad de ejecución.
Esforzarse por obtener una capacitación que permita desempeñarse
adecuadamente en el oficio.
Colaborar con las medidas de seguridad que resguarden base de datos,
espacio físico, etc.
En resumen: dedicación a las tareas asignadas, eficiencia y rendimiento,
atención a las indicaciones y observaciones, desarrollo de la iniciativa y la
creatividad.
La responsabilidad tiene una vertiente individual, por lo que
responsabilizamos al líder de ir a su trabajo bien presentable, que tenga buena
autoestima, elementos de comunicación eficaz, capacidad de armonizar el clima
organizacional, que proponga acertadas tomas de decisiones (actitud hacia sí mismo
y conocimientos).
En la vertiente colectiva, le responsabilizamos de ser responsable de las
decisiones colectivas (que se tomen en el grupo), responsabilizarse junto al grupo o
equipo en las tareas del trabajo para que exista una buena relación y mayor
productividad.
Tiene que aprender a ser responsable de cumplir las normas que le marca el
colectivo u organización donde se desempeñan, así como respetar el entorno.
ASUMIR LA RESPONSABILIDAD, PASE LO QUE PASE; es una
creencia de éxito, en el entendido que define el poder y la madurez de una
personalidad y que capacita al individuo para no quedar a merced de las
circunstancias. Si no se cree en el fracaso y si se asume la responsabilidad, no se
tiene nada que perder, pero sí mucho que ganar.

- 60 -
 CAPITULO III
DESARROLLO DEL MOF VIRTUAL

- 61 -
CAPITULO IV
RESULTADOS

- 62 -
4.4 REFERENCIAS BIBLIOGRAFICAS

BIBLIOGRAFÍA BÁSICA

1. [ SAM03] Roberto Hernández Sampieri, Carlos Fernández Collado, Pilar Baptista Lucio
– “Metodología de la Investigación” , 3ra edición, México, McGraw Hill.
2003.

2. [JAC98] Gregory, A. J, and Michael Jackson, "Evaluation Methodologies:

A System for Use", se, USA, J. OPL RES SOC, 1998.

3. [HIL98] José R. Hilera, Javier Martínez, Salvador Otón, José A. Gutiérrez

“Estándares en la Ingeniería del Software”, Departamento de Ciencias de la
Computación, Universidad de Alcalá, España, 1998.

BIBLIOGRAFÍA ESPECIALIZADA

1. [BAR01] Ing. Alberto Barberena Molina, M.A “Guía para la Elaboración del Manual
de Organización de las Instituciones Centralizadas y Desconcentradas del
Poder Ejecutivo” s.e, Managua, junio del 2001.

DIRECCIONES ELECTRÓNICAS

1. [www 01] Webmaster@revistainterforum.com

2. [www 02] http://mis.upv.es
3. [www 03] http://concytec.gob.pe/ias/index.htm
4. [www 04] http://web.madritel.es/personales3/edcollado/ingsw/tema2/2-4.htm
5. [www 05] http://www.csi.map.es/csi/metrica3/index.html
6. [www 06] http://norba.unex.es/polo/web0203/Metrica3/index.htm
7. [www 07] http://www.rational.com/uml/resources/documentation
8. [www 08] http://davinci2.csn.net/~jefscot/umljump.html
9. [www 09] http://cswww.vuse.vanderbilt.edu/~anuar/uml/intro.html

- 63 -
2.8.2 SUPUESTOS Y PRESUPUESTO

SUPUESTOS

El MOF está relacionado estrechamente con el rubro al que pertenece la

empresa.
La implantación de tecnologías de Información dentro de una organización
ayudaría a mejorar la productividad reduciendo tiempo en los procesos.
El personal de la organización no mostrará resistencia en la utilización del
MOF virtual.
La Implantación de las tecnologías e información dentro de una organización
tiene un conocimiento mínimo acerca de sus funciones o responsabilidades para
un puesto especifico

PRESUPUESTOS

El uso de las nuevas tecnologías ayuda a mejorar el rendimiento de las

organizaciones
El uso de los Sistemas de Información y las Tecnologías de Información son un
valor agregado para las empresas.
La empresa exitosa es producto de la organización y el conocimiento de las
funciones y responsabilidades de su personal.

- 64 -
BENEFICIOS EMPRESARIALES DESPUÉS DE LA IMPLANTACIÓN DEL MOF
VIRTUAL

a) Garantizar el libre ejercicio de los derechos laborales de empleadores y trabajadores

preservando el orden establecido por las Leyes, Reglamentos, Normas y Convenios
Laborales.

b) Divulgar las Leyes, Normas y Reglamentos de Trabajo, para que los trabajadores y
los empleadores conozcan sus deberes y derechos.

c) Promover y fortalecer la participación y cooperación institucional, en lo referente al

desarrollo laboral.

f) Garantizar el cumplimiento de la legislación laboral.

g) Regular el funcionamiento de las organizaciones sindicales.

2.14 DISEÑOS EXPERIMENTALES Y NO EXPERIMENTALES

DISEÑO EXPERIMENTAL
Utilizaremos el Diseño experimental, con preprueba-postprueba y grupo de control. Este
diseño incluye dos grupos usando ausencia y presencia del MOF virtual (Variable
Independiente).
Las unidades de Observación ( Área Administrativa ) son asignadas a los grupos de manera
aleatoria, al azar.
El Diagrama de Diseño queda como sigue:
RG1 O1 X O2
RG2 O3 - O4

- 65 -
1.9.1 TECNICAS E INSTRUMENTOS PARA OBTENER INFORMACIÓN

VARIABLE TÉCNICA INSTRUMENTOS

COMPUTADORAS
REVISIÓN DE: FICHAS
LIBROS FOTOCOPIAS
MOF VIRTUAL
DOCUMENTOS CD’S
INTERNET DISKETTES
LIBROS
- USO DE GRUPOS
EXPERIMENTALES
(TRABAJADORES) FORMATOS DE CUESTIONARIO
PRODUCTIVIDAD
- SEGUIMIENTO DE LA GRABADORA
EFICIENCIA Y EFICACIA
MEDIANTE ENCUESTAS
COMPUTADORES
FICHAS
REVISIÓN DE: FOTOCOPIAS
METODOLOGÍA
LIBROS CD’S
MÉTRICA Y UML
DISKETTES DISKETTES
MATERIALES DE OFICINA
(LAPIZ, LAPICERO, HOJAS)

- 66 -
 HOSPITAL HUACHO – HUAURA – OYON ( SERVICIOS BÁSICOS DE SALUD )
Amay s/n – Huaura
www.hdhuacho@hdhuacho.gob.pe

Identificación del Empleado :

Nombre ..................................................................................................................................
Área ................................................................ Puesto / Cargo .............................................
Tiempo que ocupa el puesto ..................................................................................................

1. ¿ Cuánto tiempo lleva laborando en la institución?.............................

2. ¿ Cuánto tiempo en promedio te lleva en realizar una actividad cotidiana
normalmente? ______________hrs.
3. ¿ El tiempo que demoras esta relacionado directamente a las funciones que
conoces? a) si b) no
4. ¿Conoces las funciones todas que afectan a tu puesto de trabajo en el Hospital?
a)Si conozco todas b)Conozco lo básico c) Me falta conocer todas
d)No conozco ninguna.
5. ¿Cuáles son los problemas mas frecuentes para el cumplimiento de sus funciones?
a) Falta de coordinación. b) Cruce de funciones con personal de otro puesto
c) Falta de información. d).............................................................................
6. ¿Sabe usted o conoce que es un Manual de Organización y Funciones? A)si b)no
7. ¿De que marea Ud. Llego a conocer las funciones del puesto de trabajo?
a)El jefe inmediato. b) Por el personal anterior al puesto c)Mediante algún
documento. E)..........................................................................
8. ¿Sabe quién es el responsable de informar al personal acerca de sus Funciones y
Responsabilidades? a) si b)no

9. Sabes que es un manual de organización y funciones? a ) si b)no

- 67 -
10. ¿Sabe si existe un Manual de Organización y Funciones en la Institución? a) si
b)no
11. ¿Cuanto conoces de computación ? a) Nivel Básico b)Intermedio c)Avanzado
d)No conoces.
12. Para todas las respuestas excepto D Que aplicaciones o programas de computación
conoces y trabajas en ellos?
......................................................................................................................................
......................................................................................................................................
13. ¿Conoce que es un MOF Virtual o una aplicación computacional relacionado a un
MOF? A)si b)No
14. ¿Existe cooperación o coordinación con un Área responsable para la distribución
del MOF?
15. ¿Cuándo Ingreso a laborar le explicaron de las funciones que debía cumplir?
a)Si b)No
16. Si la respuesta es Si.....¿De que manera le informaron a Ud. De las funciones que
debía cumplir ? a) Oralmente b) Mediante Documento c)Documentes
Digitalizados
17. Si la respuesta es No...¿Cuál cree el motivo que no le informaron de las funciones
que debía cumplir?
a) No hay un Departamento o área encargada b) No existe un manual de funciones
c) No disponían de tiempo para explicarte.
18. ¿Crees que una aplicación de Información puede mejorar la eficiencia del personal
dándole a conocer sus funciones y responsabilidades?
PARA LOS RESPONSALES DEL AREA DE SISTEMAS

19. ¿Todas las áreas de la empresa tienen computadoras?...............................................

20. ¿Cuántas computadoras hay en la empresa?..................
21. ¿Cuántas computadoras en promedio hay por personal?....................
22. ¿Tienen servidores de archivos y de base de datos?............................
23. ¿Que Motores de base de datos hay en la empresa?..............................................
.....................................................................................................................................

- 68 -
 24. Que arquitectura de red se usa para la comunicación entre las PC.
25. Hay una política de mantenimiento para los dispositivos de computación en la
organización.
26. Que sistemas de información tiene la institución?.
.......................................................................................................................................
.......................................................................................................................................

1.9.2 RECURSOS
HUMANOS
cinco personas

MATERIALES

Materiales de oficina diverso (lápiz, papeles, fólder, etc )

Libros
Fotocopias
Hojas

TÉCNICOS

Se emplearon lo siguientes medios:

Computadoras (5)
Impresora (1)
Herramientas Case ( Rational Rose )
Herramientas de Desarrollo ( Power Builder )
Herramientas de Productividad ( Office 2000 )
Ms - Project
Teléfonos
Grabadora

- 69 -
1.9.3 PRESUPUESTO

RECURSOS COSTOS

HUMANOS:
Chavez Arenaza, Lourdes 80.00
Machuca Fernández, Hebert 80.00
Muñoz Lino, Carlos 80.00
Pizarro Huaranga, Deyer 80.00
Zapata Rojas, Jenny 80.00
MATERIALES
Hojas 40.00
Lapiceros 3.00
Libros 60.00
Fotocopias 30.00
TÉCNICOS
Internet 30.00
Computadores 30.00
Impresoras ( Tinta ) 40.00
Software 28.00
Diskettes 10.00
CD’S 6.00

TOTAL 677.00

- 70 -