Especificaciones Técnicas del Sistema Integral

DR.
DR. MIGUEL LIMÓN ROJA S
SECRETARIO DE EDUCACIÓN PÚBLICA
DR.
DR. DANIEL RESENDIZ NÚÑEZ
SUBSECRETARIO DE EDUCACIÓN SUPERIOR
E INVESTIGACIÓN CIENTÍFICA
DR.
DR. EUGENIO CETINA VADILL
VADILLO
O
DIRECTOR GENERAL DE EDUCACIÓN SUPERIOR
MTRO.
MTRO. JOSÉ L UIS LEÓN RAMÍREZ
COORDINADOR GENERAL DEL PRONAD
PRONAD
MTRO. JOSÉ LUIS LEÓN RAMÍREZ
COORDINADOR GENERAL DEL PRONAD
MTRA.ROCÍO CHÁVEZ MAYO
ESPECIALISTA CONTABLE
ING. JUAN MANUEL ARCINIEGA DÍAZ
INGENIERO DE PROYECTOS
Participantes
Universidad Autónoma del Estado de Morelos
Rodolfo Arcos Coria
Universidad Autónoma de San Luis Potosí
Rosa Elva Ríos Vázquez
Directora de Recursos Humanos
Universidad Autónoma de Zacatecas y el Despacho
de Consultoría Íntegra
Marcelo Sada Villarreal
Adolfo Salazar Vargas
Diseñador y programador de
sistemas administrativos
P
P R
R O
O N
N A
A D
D
ÍNDICE GENERAL
INTRODUCCIÓN ...............................................................................................................................................................................11
Antecedentes ............................................................................................................................................................................ 13
I. MARCO DE REFERENCIA CONCEPTUAL DEL SISTEMA INTEGRAL DE INFORMACIÓN ADMINISTRATIVA (SIIA) ...... 15
Módulo de recursos financieros ................................................................................................................................................ 16
Módulo de recursos humanos .................................................................................................................................................. 22
Módulo de control escolar ......................................................................................................................................................... 24
II. ESPECIFICACIONES GENERALES PARA LA CONSTRUCCIÓN DEL SISTEMA COMPUTACIONAL. .............................. 27
Introducción .............................................................................................................................................................................. 27
Objetivos del sistema ................................................................................................................................................................. 27
Diseño del sistema ................................................................................................................................................................... 27
Especificaciones de construcción .............................................................................................................................................. 29
Plataforma de construcción ....................................................................................................................................................... 30
Análisis posconstrucción ........................................................................................................................................................... 31
Infraestructura computacional .................................................................................................................................................... 32
III. DESCRIPCIÓN DEL SISTEMA COMPUTACIONAL INTEGRAL ............................................................................................ 33
Módulo financiero ........................................................................................................................................................................... 33
Introducción .............................................................................................................................................................................. 33
Objetivo .................................................................................................................................................................................... 33
Requerimientos ......................................................................................................................................................................... 35
Resumen .................................................................................................................................................................................. 36
Subsistema de presupuestos ................................................................................................................................................... 39
Subsistema de contabilidad ....................................................................................................................................................... 43
Subsistema de compras ............................................................................................................................................................ 47
Subsistema de almacén ............................................................................................................................................................ 53
Subsistema de cuentas por pagar ............................................................................................................................................. 60
Subsistema de pagos ................................................................................................................................................................ 65
Subsistema de ingresos ............................................................................................................................................................ 70
Subsistema de comprobación de gastos ................................................................................................................................... 72
Módulo de recursos humanos ...................................................................................................................................................... 74
Registro y control del personal administrativo ........................................................................................................................... 74
Subsistema de personal docente .............................................................................................................................................. 76
Subsistema de nóminas ............................................................................................................................................................ 79
Subsistema de prestaciones ..................................................................................................................................................... 81
Subsistema de consultas y reportes de personal ...................................................................................................................... 83
Módulo de control escolar ............................................................................................................................................................. 83
Admisiones ............................................................................................................................................................................... 83
Inscripciones ............................................................................................................................................................................ 84
Revalidaciones ......................................................................................................................................................................... 84
Control de grupos .................................................................................................................................................................... 84
Acopio de calificaciones e impresión de actas ........................................................................................................................... 84
Control de expedientes ............................................................................................................................................................ 85
Estadísticas ............................................................................................................................................................................... 86
Expedición de constancias y certificaciones .............................................................................................................................. 87
Registro de planes de estudio .................................................................................................................................................. 87
Expedición de credencial ......................................................................................................................................................... 88
IV. CONTABILIDAD MATRICIAL .................................................................................................................................................... 89
Introducción .............................................................................................................................................................................. 89
Objetivos .................................................................................................................................................................................. 89
Estructura del código. ............................................................................................................................................................... 91
Ventajas del uso de la contabilidad matricial .............................................................................................................................. 92
Los retos .................................................................................................................................................................................. 93
V. LA CLAVE ÚNICA DE REGISTRO POBLACIONAL (CURP) .................................................................................................... 95
¿Qué es la CURP? .................................................................................................................................................................. 95
¿Cómo se integra la CURP? .................................................................................................................................................... 95
¿Qué datos contiene la CURP? ............................................................................................................................................... 95
¿Qué datos se incorporan en la asignación de la CURP? ....................................................................................................... 96
¿Para qué sirve la CURP? ...................................................................................................................................................... 96
¿Con base en qué se asigna y se expide la CURP ? .............................................................................................................. 96
VI. CONSIDERACIONES GENERALES SOBRE LA INGENIERÍA DE SOFTWARE ................................................................. 99
Modelos de ingeniería de software ....................................................................................................................................... 99
VII. CONCEPTOS BÁSICOS SOBRE LAS BASES DE DATOS RELACIONALES .................................................................109
Terminología y conceptos básicos ...................................................................................................................................... 111
Creación de un diagrama entidad-relación ........................................................................................................................ 112
Reglas de normalización ..................................................................................................................................................... 113
VIII. POLÍTICAS DE SEGURIDAD PARA EL CONTROL DEL ACCESO A LA INFORMACIÓN ............................................ 117
La política del impedir .......................................................................................................................................................... 117
La política de vigilar .............................................................................................................................................................. 117
Política prohibir/supervisar. .................................................................................................................................................. 118
Cifrado total o selectivo de información. ............................................................................................................................. 118
IX. CASO PRÁCTICO .................................................................................................................................................................... 119
Introducción ...........................................................................................................................................................................121
1. Análisis .............................................................................................................................................................................125
2. Diseño ..............................................................................................................................................................................127
3. Programación ..................................................................................................................................................................133
4. Implementación ...............................................................................................................................................................135
GLOSARIO .....................................................................................................................................................................................167
BIBLIOGRAFÍA..............................................................................................................................................................................197
P
P R
R O
O N
N A
A D
D
Especificaciones técnicas del SIIA
Introducción
INTRODUCCIÓN
En el marco de las acciones del Plan nacional de desarrollo educativo, tendientes a
impulsar el desarrollo de la gestión universitaria y en ella el uso de la tecnología informática,
la Subsecretaría de Educación Superior e Investigación Científica y la Dirección General
de Educación Superior, a través del Programa para la Normalización de la Información
Administrativa, se ha propuesto la implantación en 34 universidades públicas estatales de
un Sistema Integral de Información Administrativa (SIIA); para lograr este cometido ha
impulsado la realización de documentos que constituyan una guía a la vez que un parámetro
para aquellas instituciones que hoy tienen la tarea de insertar en sus actividades de
administración un sistema de información administrativa.
El propósito de este trabajo, cuya temática general podemos enunciar como
“especificaciones técnicas del SIIA” o “criterios técnicos de los sistemas”, es orientar a las
universidades en la definición, construcción, administración y mantenimiento de un sistema
integral de información financiero-administrativa que, desarrollado e implantado de acuerdo
con las características y necesidades de cada institución, cumpla a la vez con altos
niveles de integración, calidad y seguridad.
El propósito fundamental de la definición de los principios conceptuales contenidos en
este documento es establecer una visión clara y sencilla de las actividades implícitas en
el proceso de cambio que se pretende fortalecer con la estandarización de la información
generada, básicamente, en las áreas administrativas y financieras en que se apoya el
funcionamiento operativo de las instituciones académicas.
Lo anterior significa que el contenido de este trabajo está dirigido tanto a los
desarrolladores como a los usuarios y administradores del sistema de información
normalizada, de acuerdo con un análisis nacional efectuado en 1995, refleja que no se
encuentran en la mayoría de la base de datos instalada en las instituciones de educación
superior un sistema integral de información administrativa, que no fueron anticipadas las
especificaciones de un sistema de las características requeridas por los diseñadores de
sistemas, y es la razón de carecer de un sistema de información de este tipo en las
UPES.
Por ello, presenta una conceptualización de los esquemas básicos de funcionamiento
administrativo así como la definición de especificaciones técnicas de carácter general,
con lo cual se desea presentar un parámetro aplicable a nivel nacional para la construcción
o conceptualización del SIIA.
El documento consta de cuatro grandes apartados. La primera parte describe los
antecedentes del Programa para la Normalización de la Información Administrativa; la
segunda parte incluye el marco de referencia conceptual para el diseño integral del sistema;
el tercer apartado incluye las especificaciones técnicas y características generales del
sistema computacional y por último se incluye un bloque con los anexos y apéndices del
documento.
P
PR
RO
ON
NA
AD
D
11
Programa para la Normalización de la Información Administrativa
Estas especificaciones técnicas para el SIIA son el resultado del trabajo colegiado de
un grupo de universidades que, convocadas por el PRONAD, han vertido en él la experiencia
de cada institución, así como la que han adquirido al desarrollar un sistema de información
administrativa basado en el modelo de la contabilidad de fondos. Las universidades
participantes forman un grupo de apoyo especializado tecnológico, el cual se pretende
que brinde asesoría y sea un vínculo entre las universidades para que su conjunto se vea
beneficiado y enriquecido con los resultados y aportaciones de las experiencias más
avanzadas que cumplen con los criterios que PRONAD ha marcado.
Se trata de que desde una fase temprana en el proyecto, la institución debe determinar
cómo esta definición técnica tendrá lugar, ejem.: si se cuenta con la infraestructura para
un eficaz desarrollo o adquirir un sistema que cumpla las necesidades descritas. Esta
decisión no sólo debe depender de la conveniencia de tal integración, sino en la habilidad
de la institución de manejar el alcance del proyecto en su totalidad y complejidad sobre
las que semejante decisión traería eficazmente.
La integración tiene un costo determinado, por lo cual los sistemas integrados tienden
a ser mucho más complejos que los sistemas aislados y, por consiguiente, exige más
recursos para diseñar, desarrollar y apoyar. Esto, agregado a la complejidad natural, también
puede hacerlo más difícil al emigrar o personalizar sistemas ya existentes y adoptar
arquitectura de tecnología en el futuro.
Los sistemas financieros flexibles deben ser capaces de proporcionar los medios
asociados a un nivel apropiado de integración, por ejemplo, cuando las instituciones al
hacer el nuevo rediseño de los procesos de las cuentas por cobrar a estudiantes, querrán
hacer la integración entre el sistema financiero y el de administración escolar.
Habrá también de proporcionar la flexibilidad necesaria para integrar el sistema financiero
con los sistemas del almacén, librería o telecomunicaciones. La tal integración mejorará
el tiempo perdido y las lagunas de información que se alimentan en el sistema financiero.
Los objetivos implícitos en esta meta representan para las universidades, en esta época
de grandes cambios en el campo de la tecnología, un reto y un desafío, pues la adopción
de nuevos sistemas de información que satisfagan cada vez a un mayor grupo de usuarios,
constituye un proceso complejo, ya que las necesidades actuales de información demandan
sistemas trasparentes, flexibles y eficaces, capaces de proporcionar los medios asociados
para cada nivel de toma de decisiones en las diferentes áreas administrativas, así como
los adecuados niveles de seguridad.
Los reclamos para una mayor eficacia han encontrado expresión en una variedad de
cambios en muchas universidades, principalmente en los procesos financieros y en las
prácticas reales. Tales cambios incluyen las reestructuraciones orgánicas, programas de
jubilación, trasparencia presupuestal, etc. Estos cambios han agregado urgencia a los
sistemas de información financieros y académicos. En muchos campus o instituciones,
las jubilaciones tempranas y otras reducciones del personal han vaciado la piscina de
talento de personal. En casos donde no se ha cambiado a los empleados mayores de
12
P
PR
RO
ON
NA
AD
D
Especificaciones técnicas del SIIA
Introducción
edad, la actividad financiera ha permanecido constante y si no han evolucionado, tampoco
se han deteriorado los flujos de información.
De manera que mientras no se logre un equilibrio eficaz entre los servicios del usuario
y el tomador de decisiones en un sistema que satisfaga a ambos, la colaboración, y
comunicación serán los elementos que aseguren el éxito del proyecto ya que se considera
que la implantación de un sistema de esta envergadura es más arte que ciencia.
Antecedentes
Derivado del reconocimiento compartido entre las autoridades de diversas instituciones
públicas de educación superior y la Dirección General de Educación Superior e Investigación
Científica de la Secretaría de Educación Pública, así como de la necesidad de adoptar un
lenguaje común en el manejo de la información administrativa y financiera 1, a principios de
1996 se iniciaron los trabajos en el ámbito de la Subsecretaría de Educación Superior e
Investigación Científica de la SEP, de un proyecto de alcance nacional tendiente a la
normalización y estandarización de los sistemas de información administrativa de las
instituciones de educación superior. Así pues, en este año se tuvo un primer acercamiento de
las propias UPES con el modelo de NACUBO y se generó el primer bosquejo para este
proyecto.
Como resultado del programa, la mayoría de las instituciones participantes han tenido
avances significativos que se han traducido en grandes beneficios para las mismas.
A más de cuatro años de haber iniciado el programa, éste se encuentra en su etapa
final, en la cual se pretende asegurar la calidad de los sistemas implantados; que las
instituciones cuenten con mejor información, más confiable, oportuna y homogénea a
partir de un sistema integral robusto y eficiente.
1 En 1995 se llevó a cabo la primera reunión binacional de administradores financieros de las UPES. Como resultado de la misma se
diseñó un autoestudio institucional sobre procesos, sistemas administrativos y flujos de información en las instituciones educativas.
Producto de este diagnóstico se identificó una marcada heterogeneidad en los mecanismos de control financiero y en la calidad de la
información generada por las UPES, una carencia de bases consistentes para la evaluación del desempeño administrativo financiero
e insuficiencias en la estandarización de los criterios de registro, agrupación y reporte de la información administrativo-financiera
P
PR
RO
ON
NA
AD
D
13
Programa para la Normalización de la Información Administrativa
14
P
PR
RO
ON
NA
AD
D
Especificaciones técnicas del SIIA
Marco de referencia conceptual del SIIA
I. MARCO DE REFERENCIA CONCEPTUAL DEL SISTEMA INTEGRAL
DE INFORMACIÓN ADMINISTRATIVA (SIIA)
El sistema tiene como propósito fundamental organizar el flujo de la información de
carácter administrativo que generan las diferentes unidades orgánicas dentro de las
instituciones educativas, con el objeto de que los datos que se obtienen lleguen con
oportunidad, eficiencia y calidad suficientes para la adecuada toma de decisiones en los
diversos niveles jerárquicos de destino de las instituciones. El Sistema Integral de
Información Administrativa tiene como eje nodal la adopción de un modelo de contabilidad
de fondos, adaptado a las necesidades específicas de cada institución, y permite registrar,
agrupar y presentar los estados financieros bajo un enfoque integral, normalizado
nacionalmente y compatible con estándares internacionales que mejoran sustantivamente
la operación, administración y control de los recursos institucionales.
Para el diseño del Sistema Institucional de Información Administrativo-Financiera se
tomó como base la definición y contenido de la función administrativa general propuesta
por la mayoría de los teóricos de la materia, es decir, que esta función se realiza
generalmente a través de los procesos de planeación, programación, presupuestación,
organización, ejecución, evaluación y control. Por lo tanto, para facilitar su operación, se
adoptó el sistema modular, toda vez que permite la organización independiente de cada
proceso y a la vez posibilita la interrelación de cada uno de ellos.
Es pertinente señalar que las necesidades de información del SIIA van más allá de la
normalización de la información contable financiera, pues abarca componentes igualmente
importantes como son: la administración de alumnos, cursos, profesores, recursos físicos,
administración de recursos humanos (nómina) e información pertinente al ámbito de las
tareas de planeación y evaluación institucional.
En este contexto se conformaron los módulos de recursos humanos, recursos financieros
y control escolar. Cada uno de los módulos generará indicadores de eficiencia operativa
de las funciones que implica. Asimismo, a partir de cruces matriciales de la información
administrativa, el sistema permitirá evaluar el desempeño institucional a través de la
construcción de indicadores específicos, elaborados con base en costos unitarios, de
aplicación a las diversas áreas académicas y administrativas involucradas, y alimentar
consecuentemente la toma de decisiones tanto en el ámbito interno, en diversos niveles
de decisión institucional.
Para efectos del presente estudio se entiende por unidad administrativa al conjunto de
elementos humanos, físicos, financieros y materiales que, ordenados como un todo
orgánico, son los responsables del desarrollo de determinadas funciones; por ejemplo
puede ser una secretaría, una dirección, departamento, unidad, centro, escuela o cualquier
otra expresión funcional.
La desconcentración administrativa es la forma de organización que permite una mayor
eficacia y eficiencia en la operación, por lo que las propuestas que subyacen en este
documento la consideran como condición sine qua non para la efectividad de la
P
PR
RO
ON
NA
AD
D
15
Programa para la Normalización de la Información Administrativa
instrumentación del esquema modular de automatización de información, toda vez que
esta forma de organización hace posible que la ejecución de acciones se realice en un
ámbito que posee autonomía técnica de realización, pero que obligadamente debe estar
sujeto y subordinado a un orden central que norma, vigila y supervisa su desempeño.
Del conjunto de información que se genera en cada módulo se realizará el proceso de
estandarización para la integración de la propuesta global, la que será la manifestación de
las aportaciones presentadas por los participantes en esta tarea.
Esta propuesta se elaboró considerando la necesidad de darle un enfoque de integridad,
es decir, que cada uno de los elementos contenidos en ella se convierte en parte de un
todo que puede existir de manera independiente uno de otro, pero que sumados constituyen
el sistema óptimo de información.
Módulo de recursos financieros
Concepto
Este módulo comprende las actividades referentes a la programación, presupuestación,
evaluación y control de las funciones sustantivas y adjetivas, así como la administración
de los recursos financieros y económicos2 y materiales utilizados en la ejecución de los
programas a cargo de las diversas unidades orgánicas de las instituciones educativas.
También se incluyen las actividades de adquisiciones, almacén, control de inventarios
de planta física y activo fijo, la contratación de servicios y arrendamientos, y el
mantenimiento de equipos e instalaciones.
Resalta, por su importancia, el manejo y control de la información financiera contable al
servicio de las necesidades internas y externas de la administración con orientación
pragmática destinada a facilitar las funciones administrativas internas de planeación y
control, así como a la toma de decisiones.
Requerimientos institucionales
El desarrollo de las instituciones educativas exige que la planeación estratégica se
realice de manera ordenada y racional a través de un sistema organizado que fije objetivos,
determine estrategias, defina prioridades, establezca líneas de acción, asigne recursos,
responsabilidades y tiempos de ejecución, coordine esfuerzos y evalúe resultados.
La actividad de planeación se refiere al diseño de instrumentos que una vez formalizados
se constituyen en marcos de actuación obligatorios para las diversas unidades orgánicas,
por lo que es importante que esta función se lleve a cabo de manera objetiva y participativa
con los diversos actores involucrados en la integración de planes y programas.
2 Como se señala dentro del marco conceptual se tomará como eje nodal la adopción de un modelo de contabilidad matricial,
adaptado a las necesidades específicas de cada institución. (Ver anexo correspondiente).
16
P
PR
RO
ON
NA
AD
D
Especificaciones técnicas del SIIA
Marco de referencia conceptual del SIIA
Los diagnósticos y pronósticos que se elaboren deben reflejar situaciones reales, para
que las etapas de diseño de instrumentos sean acordes con las posibilidades de ejecución
y no representen posibilidades ajenas a las capacidades de realización.
Además, la planeación debe poseer la característica de la flexibilidad para hacer frente
a situaciones imponderables, cuando las circunstancias lo ameriten.
En este sentido, se deberá elaborar el diseño conceptual de un sistema de planeación
institucional, organizando en el mismo la forma en que se llevará a cabo una planeación
estratégica y participativa de las acciones universitarias en todos los ámbitos, es decir, los
sustantivos y apoyo administrativo a los mismos. Cada una de las unidades orgánicas
estarán obligadas a aportar los datos necesarios, y que les correspondan informar de
acuerdo con sus funciones, para que sea posible el diseño del plan y los programas que
se deriven del mismo.
Se deberá asegurar la congruencia y coherencia entre el plan y los programas que
presenten todas las unidades orgánicas, con el objeto de no contravenir los principios y
propósitos contenidos en el plan institucional.
Uno de los mecanismos más utilizados para poner en marcha lo referido anteriormente
puede ser que la unidad encargada de la elaboración de dicho plan elabore y difunda
manuales y guías técnicas de formulación de programas y proyectos, donde se establezcan
de forma clara y sencilla los lineamientos útiles para retroalimentar su función planeadora
y evaluadora de resultados.
La medición de los resultados de ejecución de programas a cargo de las unidades
orgánicas se realizará a través de informes de avance de los mismos. Para ello, tendrá
que establecerse un mecanismo de información mediante el cual se reporten los avances
obtenidos y, en su caso, se determinen las medidas correctivas necesarias.
Dentro de los principales productos que se obtienen del funcionamiento de módulo
financiero, y que derivan de planes y programas, se encuentra el presupuesto, el cual
constituye a su vez, la materia prima para la operación de este módulo.3
En tal virtud, uno de los principales objetivos de esta función es organizar la
administración de los recursos financieros de la institución para apoyar con oportunidad,
calidad y suficiencia, la ejecución de los programas académicos, de investigación y de
difusión de la cultura.
El cumplimiento del objetivo se expresa concretamente en la elaboración de los
programas presupuestos de ingresos y egresos, donde detalladamente deben quedar
establecidos, de acuerdo con los programas aprobados, el destino de los recursos por
objeto del gasto, nivel y función, así como el calendario de ejecución de los mismos.
3 El presupuesto por programas tiene una estrecha relación con el plan, ya que representa, en términos económicos, el costo financiero
de los programas.
P
PR
RO
ON
NA
AD
D
17
Programa para la Normalización de la Información Administrativa
El programa presupuesto de egresos anual deberá integrarse de manera institucional y
por centro de costos a fin de facilitar el control y seguimiento en su ejecución. Dicha
estructura presupuestal deberá organizarse de acuerdo con los principios señalados en el
párrafo anterior.
Se deberán integrar manuales de presupuestación donde se establezcan la políticas
de gasto universitario, así como los mecanismos de control y seguimiento en el ejercicio
del presupuesto.
En este orden de ideas se requiere de la implantación de un sistema de programación
y presupuestación que contenga los principios y elementos necesarios para que todas las
acciones que se vayan a desarrollar queden contempladas en dicho sistema. La
organización, en primer término, deberá sujetarse a la normatividad federal y estatal relativa
al presupuesto y gasto público en el sentido de que la estructura programática que se
adopte debe coincidir plenamente con las fuentes de ingresos públicos, lo cual facilitará
su control interno y externo.
El programa presupuesto anual debe elaborarse con la participación activa de todas las
áreas de la institución, de tal forma que queden contempladas todas las necesidades principales.
Para ello es preciso que previamente a este proceso las autoridades financieras den a conocer
las políticas y procedimientos administrativos a los que se sujetará la elaboración de
presupuestos.
La integración presupuestal deberá realizarse en forma centralizada con el objeto de aplicar
el criterio de uniformidad en su conformación. El diseño habrá de señalar en forma clara los
rubros de gastos de la manera más adecuada para que una vez autorizado por el órgano
administrativo o de gobierno que corresponda, se dé a conocer a cada área el total de recursos
autorizados para cada ejercicio fiscal, así como el tiempo de ejecución de cada programa.
Aunado a lo anterior se diseñarán mecanismos de control interno para que con la oportunidad
indispensable se reporten periódicamente la ejecución de los programas y presupuestos para
evaluar los resultados presentados y en caso de ser necesario aplicar las medidas correctivas
que se requieran.
Es importante mencionar que la instrumentación del sistema de programación y
presupuestación referido, requiere de un ajuste en las funciones de registro y control del
ejercicio, por lo que la forma de contabilizar las operaciones deberá adecuarse a la forma de
programar y presupuestar.
Para el funcionamiento sistemático de este módulo, cabe señalar como un componente
importante el modelo de contabilidad estandarizado conocido como contabilidad de fondos, el
cual constituye el marco de referencia para la realización de la aplicación del propio modelo
adecuado a las particularidades que presenta la función operativa en el ámbito de cada
institución. Lo anterior requiere de un adecuado sistema de información para el registro de las
operaciones contables, la definición de métodos de trabajo más eficientes para organizar la
función contable y la capacidad técnica del personal encargado de operar y desarrollar el
subsistema financiero contable.
18
P
PR
RO
ON
NA
AD
D
Especificaciones técnicas del SIIA
Marco de referencia conceptual del SIIA
Bajo este contexto, para que la información financiera sea útil, es necesario que el contenido
que pretende comunicar sea relevante, significativo, cierto, y a la vez comparable, y que reúna
principalmente las características de utilidad 4 y confiabilidad 5.
La readecuación de la información financiera, tendiente a mejorar la administración de los
recursos, es un proceso de cambio que requiere la voluntad y participación activa de todas las
áreas involucradas, desarrollándose bajo la filosofía de la comunicación integral, es decir,
debe existir una interacción sumamente estrecha entre las instancias administrativas que lo
conforman: contabilidad, adquisiciones, almacén, cuentas por cobrar, cuentas por pagar,
ingresos, egresos y cuentas por comprobar.
En lo que se refiere al control interno en la gestión del presupuesto, deberán expedirse
claramente las normas y procedimientos para su elaboración y ejecución, ya que de ello
depende la eficiencia en la sistematización de la función financiera.
En relación con los recursos materiales se requiere del establecimiento de una política
de administración de recursos materiales manejada centralizadamente 6, con el objetivo
de conocer el valor de la inversión en activos de consumo y fijos con que cuenta la
universidad. Se deben tomar en cuenta las siguientes consideraciones en su determinación:
• Regular su ingreso por compra, equipamiento, donación, transferencia, permuta,
dación en pago y almacenamiento; para el almacenamiento y la toma de inventarios,
para el registro y control de bienes inmuebles; para la afectación, baja y destino final
de bienes muebles.
• De igual forma se debe regular la baja de bienes muebles por inutilidad o inaplicación
en el servicio; para la baja de bienes muebles por robo, extravío o accidente.
• Asimismo, es necesario definir los lineamientos para llevar a cabo el mantenimiento
de equipos e instalaciones y para la contratación de servicios y arrendamientos.
Como en el caso del módulo de recursos humanos la fase de aplicación de esta
normatividad podrá realizarse de forma desconcentrada, por lo que el área responsable
deberá funcionar como la unidad administrativa normativa y concentradora de la información
correspondiente a fin de llevar un solo registro. Además de supervisar y evaluar el
desempeño y los resultados que presenten las demás áreas de la institución.
Todas los operaciones que se realicen en este módulo deberán aplicarse a los centros
de costos que previamente se hayan establecido para que los registros de contabilidad de
fondos consideren los valores unitarios de cada uno de ellos.
4 Es la cualidad de adecuar la información contable al propósito del usuario. La utilidad de esta información está en función de su
contenido informativo (valor intrínseco que posee dicha información basada en significación, relevación, veracidad y comparabilidad)
y de su oportunidad.
5 Característica de la información contable por la que el usuario la acepta y utiliza para tomar decisiones basándose en ella. La
confianza que el usuario de la información contable le otorga requiere que la operación del sistema sea estable, objetiva y verificable.
6 En el caso de las adquisiciones, las decisiones se tomarán colegiadamente a través de un comité integrado, entre otros, por el
usuario o solicitudes de servicio, la contraloría interna, un miembro del consejo universitario del área administrativa, y el que
adquiere el bien o servicio y el área jurídica.
P
PR
RO
ON
NA
AD
D
19
Programa para la Normalización de la Información Administrativa
Para coordinar las compras y vigilar el estricto cumplimiento de la normatividad aplicable
deberá constituirse un comité de adquisiciones que sea capaz de definir normas y
procedimientos para las compras y que garantice que las mismas se realicen en las mejores
condiciones de oportunidad técnica y económica a fin de asegurar la más alta calidad en
los artículos que se compran o la calidad de los servicios que se contratan, de acuerdo
con la disponibilidad de recursos financieros de que se disponga.
El comité de adquisiciones tendrá como función principal, de acuerdo con las prioridades
que se establezcan, realizar los actos de adjudicación de contratos a los proveedores que
ofrezcan las mejores propuestas técnicas y económicas. Deberá estar integrado por los
usuarios directamente involucrados en cada caso concreto para que sus funciones sean
acordes con los planteamientos programáticos de las diversas áreas.
La adquisición de bienes y la contratación de servicios es una función administrativa
que requiere una programación eficiente en su ejecución, debido al involucramiento de
los recursos financieros que se destinan, por lo que es indispensable establecer la técnica
de presupuestos por programas para que las compras se lleven a cabo de una manera
más racional. En esta labor deben estar involucradas todas las áreas de la institución, ya
que de ello depende la eficiencia y la eficacia de las mismas.
Para el registro y control de los bienes adquiridos y existentes es necesaria la elaboración
de un catálogo de todos los activos fijos que actualmente administra la universidad, el
cual podría diseñarse de acuerdo con el tipo de bien del que se trate, estableciendo una
clasificación global a fin de identificarlos según su uso.
Una vez catalogados todos los bienes, se requiere establecer un procedimiento de
manejo y control de bienes, por lo que se deberá llevar a cabo un inventario pormenorizado
de todos los activos fijos con que cuenta cada una de las áreas que conforman la
universidad, estableciendo resguardos de los mismos, a fin de controlar su existencia y
rotación.
Para administrar adecuadamente los activos fijos deberán designarse titulares de los
centros de costos con una responsabilidad directa del usuario, identificados con anticipación
para organizar un sistema computarizado de resguardos que asignará la responsabilidad
en la custodia de los bienes. Cada centro de costos está obligado a cumplir con los
procedimientos administrativos en su manejo, por lo que deberán reportarse oportunamente
los cambios que se presenten.
Cuando se trate de bienes de activo fijo de reciente adquisición se efectuará una entrada
a almacén y el departamento responsable del control de inventarios tendrá que identificarlos
y plaquearlos para que de origen queden debidamente registrados. En ese momento será
necesario elaborar los resguardos correspondientes y se integrarán a la base de datos
que conforman el inventario de la institución.
Respecto al almacén, se requiere el establecimiento de un sistema de kardex de los
artículos que se resguardan en las bodegas en el cual habrá de designársele una clave de
identificación, una descripción del bien, su fecha de ingreso al almacén, la existencia
actual, su costo unitario, fecha de la última salida y el valor de la existencia actual.
20
P
PR
RO
ON
NA
AD
D
Especificaciones técnicas del SIIA
Marco de referencia conceptual del SIIA
Cabe señalar que se requiere el sistema de kardex, ya que por el almacén tienen que
pasar todos los bienes que se adquieran. Sus movimientos de entrada y salida se deben
realizar a través de vales de almacén donde queden expresados todos los datos referentes
a los bienes que se entreguen a los usuarios, además de quedar asentados el número o
clave del centro de costos al que se refiera, así como el nombre del responsable del
almacén, el nombre del usuario que recibe el bien y el nombre del titular de encargado del
almacén.
Todos lo movimientos mensuales del almacén deberán ser reportados en forma mensual
al Departamento de Contabilidad a fin de que lleven a cabo los registros contables que se
requieran.
Asimismo, al concluir el ejercicio fiscal deberá llevarse a cabo un inventario de las existencias
en el almacén, cuyos resultados deberán ser informados al Departamento de Contabilidad
para la realización de los cierres correspondientes.
Todas las actividades relacionadas con la administración de recursos materiales deberán
quedar debidamente documentadas con el propósito de facilitar su revisión periódicamente.
Sobre todo la relativa a contratos de adquisiciones, arrendamientos y prestación de servicios
e inventarios de activo fijo y de bienes de consumo.
Productos
De dichos procesos se obtienen varios tipos de documentos que habrán de normarse y
estandarizarse. Los principales son:
•
•
•
•
•
•
•
•
•
•
•
El plan institucional de desarrollo.
Los lineamientos de política de ejecución de planes, programas y proyectos.
Los programas de desarrollo derivados del plan.
El mecanismo de evaluación y seguimiento en la ejecución del plan y de los
programas.
Los indicadores y estándares de calidad instrumentados en cada tipo de operación
que se pretenda medir.
Los presupuestos de ingresos y egresos anuales.
Los mecanismos de control presupuestal en el ejercicio del gasto.
El componente de contabilidad de fondos y registro de operaciones. 7
Políticas de adquisiciones.
Bases de licitaciones (de acuerdo con la ley de administración pública en sus distintas
modalidades).
Contratos de adquisiciones, arrendamiento y de servicios.
7 Entre los principales objetivos de la contabilidad dentro de una institución de educación se encuentran:
1. Proveer información para la planeación y la elaboración del presupuesto, instrumentos a través de los cuales se
espera que el uso de los recursos disponibles sea más eficiente.
2. Proporcionar información financiera para el control de las operaciones institucionales a diferentes niveles.
3. Proporcionar información para la salvaguarda y control de los activos.
4. Proporcionar información para la asignación de los recursos.
5. Proporcionar información para la evaluación financiera de las operaciones.
6. Cumplir con los principios de contabilidad generalmente aceptados.
P
PR
RO
ON
NA
AD
D
21
Programa para la Normalización de la Información Administrativa
•
•
•
•
•
•
•
•
Cuadros de cotizaciones.
Orden de compra.
Inventarios de activo fijo.
Resguardos personalizados.
Inventarios de existencias de almacén.
Reportes de entradas y salidas del almacén.
Programas de mantenimiento preventivo y correctivo de instalaciones y equipo.
Registro de operaciones con aplicación del componente contabilidad de fondos.
Módulo de recursos humanos
Concepto
Este módulo comprende la administración del factor humano, la cual incluye las
actividades de reclutamiento, selección, evaluación, contratación, control y capacitación.
La administración de recursos humanos comprende:
•
•
•
•
Mandos medios y superiores
Personal docente
Personal administrativo
Eventuales
Requerimientos institucionales
Para la ejecución del proceso de administración de los recursos humanos se necesita,
en primer término, la definición de una política que establezca objetivos, estrategias y
líneas de acción en el corto, mediano y largo plazo. Esta política deberá definir en forma
sistemática los principales lineamientos de cada institución en materia de las actividades
referidas al factor humano para cada tipo de trabajador. Ello hará posible mejorar
sustancialmente la planeación y la administración de los recursos humanos.
La administración de los recursos humanos de las instituciones educativas deberá
considerar los siguientes puntos:
• La función de administración de los recursos humanos se debe desarrollar de manera
centralizada por la dirección correspondiente a fin de llevar sólo un control sobre el
total de la plantilla del personal adscrito a cada institución educativa. Para estos
efectos se debe considerar la posibilidad del funcionamiento desconcentrado de los
aspectos operativos, estableciendo con claridad el tipo de información que habrán
de manejar las diversas unidades y que retroalimentarán al área central.
• Para facilitar la operación y vincularla posteriormente con el módulo financiero, en lo
referente al componente de contabilidad de fondos, deberá establecerse
coordinadamente con los responsables de las acciones de programación y
presupuestación, una organización de centros de costos que deberá identificar a
cada una de las áreas que la componen asignándole un centro de costos, con el
22
P
PR
RO
ON
NA
AD
D
Especificaciones técnicas del SIIA
Marco de referencia conceptual del SIIA
objeto de conocer el valor de la inversión en recursos humanos de manera específica.
En este sentido, la plantilla de personal tendrá que elaborarse con base en la
distribución asignada por el centro de costos para que las nóminas quincenales
reflejen el valor correspondiente.
• La comunicación administrativa del área encargada de los recursos humanos con
las demás áreas de las instituciones educativas debe ser de manera eficiente y
oportuna para poder dar respuesta inmediata a los requerimientos institucionales,
por ello para poder funcionar adecuadamente deberán darse a conocer los principales
lineamientos establecidos en estos asuntos a todos los posibles clientes internos de
esta función, es decir, que quien tenga que llevar a cabo una actividad relacionada
con la función de recursos humanos al interior de cada institución tendrá que conocer
previamente los requisitos que debe cumplir, para que de esta manera quede
garantizada la respuesta que corresponde otorgar al área de recursos humanos.
De lo anterior se desprende que es necesaria la elaboración de manuales de
organización y procedimientos que definan claramente cuáles son las facultades y
obligaciones de los usuarios internos y externos al área de recursos humanos.
• En cuanto a registro y control, en términos generales en lo correspondiente al ingreso
y egreso del personal de cualquier tipo, es necesario conformar expedientes
individuales con un formato único de movimientos de personal, donde se cuente con
todos los datos generales de la persona de que se trate, en el cual quede expresada
la información correspondiente a la plaza que se va a ocupar, la temporalidad de la
misma y la codificación presupuestal y de contabilidad de fondos.
• Los movimientos de la plaza, derivados de promociones, renuncias, altas y bajas
deberán integrarse al expediente del personal a fin de mantenerlos permanentemente
actualizados. Los documentos que acrediten capacitación con valor curricular deben
integrarse al expediente antes señalado.
• Por lo que respecta al control del personal es necesario instrumentar mecanismos
que garanticen la asistencia y permanencia de los trabajadores, toda vez que la
productividad de la institución se ve afectada por la relación existente entre ausencia
laboral y pago de tiempos muertos en el trabajo.
Del Contrato Colectivo del Trabajo deberán desprenderse condiciones generales de
trabajo que expresen los derechos y obligaciones de las autoridades y trabajadores de
cada institución, las cuales constituirán la principal norma para realizar la función de
administración de recursos humanos. En ellas deberán quedar asentados los asuntos
correspondientes a tiempo de jornadas, asistencia, permanencia, puntualidad,
productividad, estímulos, escalafón, sanciones, entre otras.
La operación continua del área responsable de los recursos humanos requiere, por la
dimensión y complejidad de las instituciones educativas, la automatización de los procesos,
por lo que deberá iniciarse con la actualización quincenal de la plantilla ordinaria a fin de
que sea el propio sistema quien realice las operaciones de los cálculos necesarios para la
impresión de las nóminas ordinarias y extraordinarias.
P
PR
RO
ON
NA
AD
D
23
Programa para la Normalización de la Información Administrativa
Para ello es importante la comunicación permanente con los responsables del control
del personal administrativo y docente de las escuelas, ya que en el primer caso presenta
relativa permanencia y en el segundo los movimientos son frecuentes sobre todo en los
cambios semestrales.
Otro aspecto importante a considerar será la tendencia a unificar los archivos públicos
de personas a través de la utilización de la Clave Única de Registro Poblacional (CURP).
En este sentido, será conveniente contemplar la incorporación de este elemento para el
manejo y control de los archivos de personas.
Productos
Mejoramiento y actualización de los siguientes listados:
•
•
•
•
•
•
•
•
•
Bajas
Altas
Datos personales
Datos generales
Sueldos y salarios
Vacaciones
Incapacidades
Gastos médicos
Prestaciones
Registro de operaciones con aplicaciones del componente contabilidad de fondos.
Módulo de control escolar
Concepto
El presente módulo comprende las actividades relativas a la administración y control
de alumnos, docentes y las relaciones que surgen entre éstos. Entre otros objetivos se
propone organizar, en forma sistemática y ordenada los datos correspondientes a la
matrícula de alumnos y la plantilla de personal docente.
Requerimientos institucionales
El archivo central debe concentrar toda la información referente a la totalidad de alumnos
de cada institución, clasificándolos por escuela, año de inscripción, semestre que cursan,
calificaciones obtenidas, plan de estudios en el que se encuentran inscritos, total de
egresados, total de egresados titulados, egresados en proceso de titulación, así como del
índice de deserción. Asimismo, debe llevar un archivo histórico que refleje el
comportamiento estadístico de los alumnos que han cursado estudios en todos los niveles
que ofrezca la institución.
24
P
PR
RO
ON
NA
AD
D
Especificaciones técnicas del SIIA
Marco de referencia conceptual del SIIA
Asimismo, se deberá accesar la información referente al personal docente con que
cuente cada institución.
En estos registros se consideran todos los niveles de estudio que se ofrezcan
(secundaria, preparatoria, carreras técnicas, licenciaturas, maestrías y doctorados).
El funcionamiento debe ser desconcentrado para que cada centro, escuela o facultad,
opere sus propios registros, los cuales, operando en red, fluyan a la base de datos central.
Es importante señalar que su operación debe estar programada para que los reportes
que se emitan lleguen con oportunidad a los usuarios y funcionen como herramientas
eficaces en la operación de las áreas y en la toma de decisiones de carácter académico.
Además este subsistema debe operar coordinadamente con los módulos de recursos
humanos y recursos financieros para que en cada ámbito de funcionamiento la información
retroalimente al SIIA.
Productos
•
•
•
•
•
•
•
•
•
P
PR
RO
ON
NA
AD
D
Bases de datos de alumnos en todos los niveles académicos
Bases de datos de docentes
Inscripciones de nuevo ingreso
Reingreso
Recopilación de calificaciones
Expedición de cartas de pasantes
Certificaciones
Revalidación de estudios
Expedición de credenciales
25
Programa para la Normalización de la Información Administrativa
26
P
PR
RO
ON
NA
AD
D
Especificaciones técnicas del SIIA
Especificaciones generales para la construcción del sistema computacional
II. ESPECIFICACIONES GENERALES PARA LA CONSTRUCCIÓN DEL
SISTEMA COMPUTACIONAL
Introducción
Este apartado presenta el diseño del sistema computacional para el Sistema Integral
de Información Administrativa (SIIA) definido en el capítulo anterior, así como las
especificaciones técnicas para su construcción.
Para las especificaciones técnicas de construcción se han buscado aquellas tecnologías
que, más allá de ser consideradas como el estado del arte en la ingeniería de sistemas,
respondan a las necesidades de las instituciones en cuanto al tipo de sistema que se
requiere implantar así como la flexibilidad que deberá tener para adaptarse a cambios
institucionales o a los posibles cambios de reingeniería que se requieran a través del
tiempo.
Objetivos del sistema
Objetivo general
Construir un sistema de información que de manera integral permita la administración
eficiente y confiable de los recursos humanos, financieros y de control escolar, de las
instituciones educativas, y que coadyuve a generar información útil para la planeación,
evaluación y toma de decisiones.
Objetivos específicos
Contar con un sistema de información administrativa único e integral.
Que el sistema adopte los principios y criterios de la contabilidad de fondos.
Que el sistema genere información confiable y oportuna.
Que el sistema coadyuve a la toma de decisiones.
Que el sistema presente estados financieros bajo un enfoque integral,
normalizado nacionalmente y compatible con estándares internacionales.
• Que el sistema coadyuve a la modernización y eficientización de los procesos y
estructuras administrativas de las instituciones donde se implante.
•
•
•
•
•
Diseño del sistema
Consideraciones preliminares
Sobre la ingeniería de software se está llevando a cabo una fuerte discusión teórica por
la evidente debilidad de las bases que le dan fundamento. (Ver anexo correspondiente).
P
PR
RO
ON
NA
AD
D
27
Programa para la Normalización de la Información Administrativa
Esta discusión se centra en dos aspectos fundamentales, el primero que tiene que ver
con una epistemología basada en el principio de autoridad ya que la mayoría de los tratados
de ingeniería de software están basados en una combinación de experiencia anecdótica
y autoridad humana, raramente se acompañan de evidencia lógica o experimental. Esto
provoca la carencia de una base sólida que le dé un carácter científico a la ingeniería de
software.
El segundo tiene que ver con un principio práctico aplicado de manera generalizada en
la ingeniería de software y es el famoso precepto de “divide y vencerás”, es decir, se ha
venido aplicando dogmáticamente este principio, separando las actividades propias del
análisis de las actividades de diseño.
Por otra parte, se presupone que una vez establecido el algoritmo que se obtiene de la
división del proceso de desarrollo de software en diversas etapas, se asume que es factible
desarrollarlo sin considerar la posibilidad de llevar a cabo la construcción de un algoritmo
que implique un costo injustificado e irrealizable en la práctica.
Es claro entonces que hay una falta de comprensión de la relación que existe entre las
actividades de diseño y las de análisis. Dado lo anterior se puede establecer que durante
la etapa de análisis se constituye el problema, pues no se obtiene un problema, sólo
hechos, y justamente este paso de constitución del problema está necesariamente referido
a su solución, es decir, a la etapa del diseño.
En este orden de ideas, la estrategia y metodología que se propone para la elaboración
del diseño computacional del sistema no puede ser tajante ni rígida, por el contrario, sólo
puede limitarse a enunciar un par de ellas, con el propósito de que cada institución valore
y determine conforme a sus características, la más adecuada a sus necesidades, o la
combinación de diferentes modelos y metodologías de la ingeniería de software en un
intento de robustecer (en la medida de lo posible, pues es un problema muy complejo) el
diseño y la construcción del SIIA.
Modelo de ingeniería de software
Dos metodologías que pudieran adaptarse perfectamente para el diseño del SIIA son
la comúnmente conocida como “modelo lineal secuencial” y la del “modelo de construcción
por prototipos”.
Así también se pudiera considerar la opción de utilizar la combinación de ambos modelos,
utilizando en primera instancia el modelo lineal secuencial8 (sólo para sus dos primeras
etapas: análisis y diseño) lo cual permitirá establecer ciertas funciones y procesos de una
manera formal así como documentar una gran cantidad de funciones y procesos que no
se encuentren en documentos de manera formal; y el modelo por prototipos9 para la
construcción del sistema.
8 El modelo lineal secuencial sugiere un enfoque sistemático secuencial del desarrollo del software que comienza en un nivel de
sistemas (conceptual) y progresa con el análisis, diseño, codificación, pruebas y mantenimiento.
28
P
PR
RO
ON
NA
AD
D
Especificaciones técnicas del SIIA
Especificaciones generales para la construcción del sistema computacional
Consideraciones generales sobre el diseño del SIIA
A continuación se detalla una serie de consideraciones que se recomienda tomar en
cuenta desde la etapa del diseño y respetarlas a lo largo del ciclo de vida del sistema:
•
El diseño del sistema deberá garantizar que los datos que ingresan al sistema se
capturan una sola vez. En el caso de la base de datos se garantizará que no exista
información redundante.
•
Para cada uno de los sistemas que componen el sistema integral, se deberán construir
los mecanismos que hagan posible el seguimiento y control de gestión. Esto es
poder monitorear el estatus en que se encuentra un movimiento.
•
El sistema deberá contemplar los filtros y sistemas de validación necesarios para
garantizar la calidad de la información.
•
El sistema deberá contemplar los mecanismos y políticas de acceso (ver anexo) y
seguridad que garanticen la confiabilidad e integridad de la misma.
• El sistema deberá evitar en la medida de lo posible que se realicen movimientos no
permitidos (que violen la normatividad de las instituciones). De preferencia deberá
mantener una bitácora de las afectaciones e intentos por alterar la base de datos.
• El sistema deberá estar diseñado para generar información de manera ágil y oportuna,
de tal forma que coadyuve a la toma de decisiones.
Especificaciones de construcción
Arquitectura cliente-servidor
La arquitectura cliente-servidor ha sido seleccionada como la más conveniente para la
construcción del sistema, en virtud de la eficiencia que ha demostrado en aplicaciones de
tamaño intermedio y de gran escala, las facilidades que las plataformas actuales de cómputo
tienen, facilitan la implantación de aplicaciones cliente-servidor, flexibles y de fácil
mantenimiento.
Capas
Una manera de potenciar la arquitectura cliente-servidor y que responde a las
características que debe tener un sistema de esta naturaleza es la arquitectura de tres
capas, la idea fundamental de esta tecnología es dividir las funcionalidades del sistema
en tres grandes grupos: los servicios de usuarios, esta primera capa se encarga de
identificar los objetos necesarios que interactúan con la interfaz de la aplicación; los servicios
de negocios, esta capa agrupa los objetos que trabajan directamente con los procesos
9 Recordemos que el modelo por prototipos permite al cliente valorar permanentemente los avances en el desarrollo lo que no sucede
en el modelo lineal secuencial donde el cliente conoce el resultado del trabajo hasta el final de su desarrollo.
P
PR
RO
ON
NA
AD
D
29
Programa para la Normalización de la Información Administrativa
internos del negocio y los servicios de datos que son una colección de objetos que
manipulan decisiones de los datos independientes de las reglas de negocio, esto se
convierte directamente en un sistema para el manejo de base de datos. En la mayoría de
los casos estas operaciones se realizan con instrucciones SQL.
Se recomienda usar arquitectura de tres capas por tratarse de un sistema de un alto
volumen de usuarios concurrentes, una esperanza de vida de la aplicación mayor a tres
años, la necesidad de autentificar usuarios individualmente de acuerdo con su acceso a
la base de datos y una fácil implantación de componentes sin impactar de manera sustancial
al sistema lo que permite flexibilidad en los cambios que se requieran producto de la
evolución del mismo.
Niveles de acceso
Aunque podría considerarse tratado el tema de nivel de acceso de los usuarios en el
punto anterior, conviene establecer de manera muy clara la necesidad de precisar en este
sistema los niveles de acceso adecuados para cada componente del mismo. Esto
evidentemente requerirá de la participación de la universidad en la definición de los niveles
de acceso adecuados para cada usuario del sistema.
Para el control de los accesos se deberá construir un módulo especial en donde para
cada usuario o grupo de usuarios se deberán especificar los privilegios que tienen para
ejecutar, accesar o modificar determinado proceso, subsistema o tipo de dato.
Respecto al manejador de base de datos deberá existir un control estricto sobre quién
tiene acceso a la base de datos. El administrador de la base de datos se responsabilizará
de esta actividad.
Así también deberá integrarse un programa de respaldos que garantice la reconstrucción
de la base de datos a partir de los mismos.
Plataforma de construcción
Herramienta CASE
Para la definición del modelo entidad-relación se recomienda utilizar herramientas de
tipo CASE. En el caso del desarrollo se propone el uso de alguna herramienta que permita
la generación de código y documentación de manera semiautomática, con facilidades de
reingeniería e ingeniería en reversa y que permita transportabilidad a diferentes plataformas
y arquitecturas. También es importante mencionar que el uso de este tipo de herramientas
apoyan de manera sustancial las actividades del desarrollo del sistema. Sin embargo, es
la participación del usuario lo que garantizará un correcto desarrollo y desempeño del
sistema.
30
P
PR
RO
ON
NA
AD
D
Especificaciones técnicas del SIIA
Especificaciones generales para la construcción del sistema computacional
Base de datos
Se requiere de un manejador de base de datos relacional que soporte el estándar SQL.
Adicionalmente, que soporte un volumen de datos a gran escala, así como un número
importante de usuarios concurrentes; que sea tolerante a fallas y que permita su rápida
recuperación en caso de contingencias. Deberá soportar la arquitectura cliente-servidor.
Cliente de la base de datos
Se puede optar por una herramienta orientada a objetos para el desarrollo de servicios
de negocios y un cliente de tipo visual o cualquier otro asociado a la base de datos
seleccionada para la capa de servicios de usuarios. Es pertinente mencionar que una sola
herramienta puede ser utilizada para el desarrollo de estas dos capas, sin embargo resulta
muy eficiente usar la herramienta orientada a objetos para los servicios de negocios por la
definición tecnológica de componente que éstos tienen.
Digitalización
Para todas las tareas de digitalización de documentos se propone el uso de escaners
de alta velocidad con un motor de administración y recuperación de imágenes que permita
la conexión natural a la base de datos seleccionada. Adicionalmente deberá permitir la
incorporación de un sistema de reconocimiento óptico o inteligente de caracteres.
Análisis posconstrucción
A pesar de que esta metodología no es muy socorrida dentro de los desarrollos de
sistemas tradicionales, principalmente por los costos adicionales que implica, debido a la
magnitud del proyecto en cuestión, se considera pertinente que las instituciones que estén
en condiciones implanten esta metodología.
Este análisis consiste en llevar a cabo una evaluación cuantitativa y cualitativa del
desarrollo del proyecto con la finalidad de sistematizar el conocimiento adquirido durante
su desarrollo, formalizar recomendaciones para hacer mejoras a las metodologías
empleadas y la determinación del nivel de éxito y la calidad alcanzada en el desarrollo del
proyecto.
Esta información pasará a formar parte de la base de conocimientos de la universidad
y coadyuvará a mejorar la calidad y el éxito de los futuros proyectos que se emprendan.
P
PR
RO
ON
NA
AD
D
31
Programa para la Normalización de la Información Administrativa
Infraestructura computacional
El dimensionamiento es uno de los aspectos que requieren mayor atención, ya que
normalmente olvidamos que la infraestructura tiene un costo y el proyecto debe tener
metas o acciones muy definidas, por lo que es necesario determinar los alcances del
proyecto y los recursos que se requieren para tener un servicio con niveles aceptables en
un tiempo aceptable. Normalmente la inexperiencia en este sentido incrementa los costos
del servicio y los tiempos para obtener la solución, esto en el mejor de los casos.
Antes de tomar cualquier decisión es necesario diseñar el servicio que desee obtener y
la forma en la que el servicio se va a soportar. Apoyándose en los usuarios de cada área,
en las herramientas que soportan las tecnologías de información y de ser necesario, en
asesores de experiencia, se debe diseñar una estrategia robusta y un estudio del costobeneficio, más aún, cuestionarnos objetivamente si el momento para el módulo es primero
o cuál depende del otro para no duplicar la tarea.
32
P
PR
RO
ON
NA
AD
D
Especificaciones técnicas del SIIA
Descripción del sistema computacional integral
III. DESCRIPCIÓN DEL SISTEMA COMPUTACIONAL INTEGRAL
Este apartado contiene una descripción general de la funcionalidad y componentes de
cada uno de los sistemas que integran al Sistema Integral de Información Administrativa
y Financiera (SIIA). En algunos casos se precisan los datos de entrada para cada uno de
los procesos y se ejemplifican algunas pantallas que pudiera tener el sistema.
Módulo financiero
Introducción
La contabilidad es un medio para brindar información en relación con las actividades
financieras realizadas por las instituciones públicas o privadas.
En la actualidad, los métodos contables brindan con mayor facilidad y flexibilidad información
financiera más completa y detallada.
Esta información financiera es valiosa porque permite evaluar acciones pasadas y ayuda a
preparar planes para el futuro por medio de los cuales se puedan alcanzar objetivos y metas
financieras.
La calidad de la información financiera ha sido fuertemente criticada por los directivos que
suelen tomar decisiones estratégicas. Lo anterior ha propiciado que se hayan venido
proponiendo y ejecutando acciones específicas para mejorar la calidad de dicha información.
Objetivo
Generar el Subsistema de Información Financiera Contable al servicio de las necesidades
internas y externas de la administración con orientación pragmática destinada a facilitar las
funciones administrativas internas de planeación y control, así como a la toma de decisiones.
Los objetivos de la contabilidad de una institución de educación tienen las mismas
características que para una empresa comercial:
a) Proveer información para la planeación y la elaboración del presupuesto, instrumentos
a través de los cuales, se espera que el uso de los recursos disponibles sea más
eficiente.
b) Proporcionar información financiera para el control de las operaciones institucionales a
diferentes niveles.
c) Proporcionar información para la salvaguarda y control de los activos.
d) Proporcionar información para la asignación de los recursos.
e) Proporcionar información para la evaluación financiera de las operaciones.
f) Por otro lado, se espera que la información que se prepara cumpla con los principios
de contabilidad generalmente aceptados.
P
PR
RO
ON
NA
AD
D
P
PR
RO
ON
NA
AD
D
33
Programa para la Normalización de la Información Administrativa
Respecto a sus objetivos organizacionales, éstos presentan diferencia con las empresas
comerciales.
a) Las empresas comerciales tienen fines de lucro.
b) Las instituciones de educación pública persiguen fines de servicio, por lo que no tienen
intereses de lucro, y requieren manejar de una manera más eficiente el financiamiento
que reciben a través del subsidio, ya sea federal, estatal o municipal.
También se presentan marcadas diferencias en cuanto a la forma de operar de cada una
de ellas. Mientras que para la empresa comercial el efectivo es producto de venta de bienes y
servicios y son su principal fuente de recursos, y sus ganancias, están determinadas por la
relación que guardan sus ingresos respecto a sus gastos, para una institución de educación
más del 80% de sus ingresos provienen del subsidio, y sus recursos son controlados de
acuerdo con las restricciones que se les ha impuesto para su utilización.
Diseñar un sistema de contabilidad es un arte.
El sistema puede esconder información o puede abrirla tanto como se desee.
Algunos sistemas de contabilidad pueden hacer ambas cosas.
La mayoría de los sistemas de contabilidad para universidades están diseñados de acuerdo
con los principios de contabilidad generalmente aceptados.
Sin embargo, en contabilidad, como en muchas disciplinas, hay desacuerdos en la manera
de presentar situaciones especiales. En tales situaciones la metodología contable difiere de
un campus a otro.
El diseño de un sistema contable se puede determinar, en parte, por la naturaleza de la
institución, así como de su historia.
Un sistema de contabilidad no necesariamente refleja todas las operaciones financieras
que pueden influir en el estado financiero de la institución.
Frecuentemente estas transacciones se describen en notas a los estados financieros.
Pueden incluir partidas tales como una adición significativa en la planta.
Partidas que no aparecen en los estados financieros pueden incluir un plan de legados a
alumnos que serán efectivos en un futuro, o una donación de libros raros u objetos de arte.
Estos últimos incrementan el valor de los activos de la institución pero no estarán incluidos
en los estados financieros.
Esto nos lleva a pensar que el sistema de contabilidad de la institución puede no proporcionar
una realidad completa de la situación financiera.
Las organizaciones no lucrativas como grupo difieren de las empresas en cuanto a que
aquéllas son receptoras del subsidio, donativos, contribuciones y apropiaciones, que están
restringidas para su uso, ya que su utilización está asociada a propósitos, funciones y actividades
en particular.
34
P
PR
RO
ON
NA
AD
D
Especificaciones técnicas del SIIA
Descripción del sistema computacional integral
Un donante, por ejemplo, puede especificar que su aportación sea utilizada exclusivamente
para becas.
Bajo este sentido, la institución no tiene ninguna otra autoridad para disponer del recurso
que no sea para el fin para lo que fue dado.
Dada esta característica en particular, que distingue la contabilidad que debe seguir una
institución educativa, es que surge la llamada contabilidad universitaria.
A diferencia de otros sistemas contables típicamente empleados en la industria o el comercio,
el principal propósito de la contabilidad universitaria es asegurarse que los recursos financieros
sean manejados de acuerdo con las restricciones que se les han impuesto.
La contabilidad universitaria permite la separación de los recursos con restricciones externas
para su uso, de aquéllos que no la tienen.
Dado que los recursos otorgados a una institución educativa, en la mayoría de los casos
son utilizados para propósitos específicos, el sistema contable debe estar diseñado para
registrar, clasificar y reportar la situación que guarda cada una de las fuentes de los recursos
restringidos.
Requerimientos
Dentro de la fase del proceso del subsistema financiero contable, existen consideraciones
importantes, mismas que serán explicadas a continuación con mayor detalle.
Qué es un fondo
Un fondo se define como una entidad contable que tiene un grupo de cuentas
autobalanceables, esto es, tienen sus propias cuentas de activo, pasivo y patrimonio, además
de las cuentas de resultados, ingresos y gastos.
Se establecen fondos separados para contabilizar las actividades financieras relacionadas
con subsidios que tengan restricciones particulares para su uso, fuentes de recursos restringidos,
o importes designados que han sido establecidos por la junta de gobierno de la institución.
Estas entidades contables se establecen para asegurarse que los recursos serán utilizados
de acuerdo con las restricciones impuestas, en este caso, por el otorgante del subsidio, o
bien, por la junta de gobierno.
Consideraciones organizacionales
Las consideraciones organizacionales son aspectos que no necesariamente corresponden
a tópicos contables y que tienen que ver más bien con la definición de funciones y con la
disponibilidad de recursos computacionales, tanto de software como de hardware, para la
adecuada operación de sistema.
P
PR
RO
ON
NA
AD
D
P
PR
RO
ON
NA
AD
D
35
Programa para la Normalización de la Información Administrativa
Infraestructura contable
La infraestructura contable se refiere a aquellos elementos esenciales para generar
información financiera con las especificaciones de calidad y eficiencia que demandan los
usuarios.
Entre los aspectos más importantes destaca un adecuado sistema de información para el
registro de las operaciones contables, la definición de métodos de trabajo más eficientes para
organizar la función contable y la capacidad técnica del personal encargado de operar y
desarrollar el subsistema financiero contable.
Para que la información financiera sea útil, es necesario que el contenido que pretende
comunicar sea relevante, significativo, cierto y a la vez comparable y que reúna principalmente
dos características indispensables para que tenga valor:
•
•
La utilidad
La confiabilidad
Características de la información financiera
Utilidad: es la cualidad de adecuar la información contable al propósito del usuario. La
utilidad de esta información está en función de su contenido informativo y de su oportunidad.
Contenido informativo: esta característica de la información contable se refiere al valor
intrínseco que posee dicha información, basada en significación, relevación, veracidad y
comparabilidad.
Oportunidad: esta cualidad de la información se refiere a que ésta llegue a manos del
usuario cuando él pueda usarla para tomar decisiones a tiempo a fin de lograr sus propósitos.
Confiabilidad: la característica de la información contable por la que el usuario la acepta y
utiliza para tomar decisiones basándose en ella. La confianza que el usuario de la información
contable le otorga requiere que la operación del sistema sea estable, objetiva y verificable.
Resumen
La readecuación de la información financiera, tendiente a mejorar la administración de los
recursos es un proceso de cambio que requiere la voluntad y participación activa de la
comunidad universitaria, desarrollándose bajo la filosofía de la comunicación integral, es
decir, debe existir una interacción sumamente estrecha entre las instancias administrativas
que lo conforman, como son:
36
P
PR
RO
ON
NA
AD
D
Especificaciones técnicas del SIIA
Descripción del sistema computacional integral
Por esta razón, es de suma importancia que todas éstas lleven a cabo las funciones
que tienen a su cargo, ya que la información que emane de ellas podrá ser utilizada por
los departamentos restantes, evitando de esta manera la duplicidad de actividades y por
consiguiente el índice tan elevado de errores.
Este módulo principal del sistema, basado en un esquema de contabilidad matricial,
donde el registro de las operaciones contable debe tener cuatro datos principales que
son: fondo, función, unidad responsable y cuenta contable, por lo tanto deben existir cuatro
catálogos que hagan referencia a estos datos.
Catálogo de fondos
1
1
1
1
1
0
1
2
2
2
0
0
0
1
3
0
0
0
0
0
Fondo de operación
Fondo de operación genérico
Fondo de operación específico
FOMES
PROMEP
Catálogo de funciones
1
1
1
1
04
04
04
04
00
01
15
18
00
00
00
00
Educación superior
Tronco común
Lic. en psicología
Contador público
Catálogo de dependencias
001
003
005
007
009
Facultad de Arquitectura
Facultad de Ciencias Agropecuarias
Facultad de Ciencias Biológicas
Facultad de Comunicación Humana
Facultad de Ciencias Químicas e Ingeniería
Cátalogo de cuentas
102
102
102
120
120
420
420
420
P
PR
RO
ON
NA
AD
D
P
PR
RO
ON
NA
AD
D
01
10
00
00
01
01
Bancos
Bancos fondo op. genérico
Bancos fondo FOMES
Activos fijos
00023
Equipo de procesamiento de datos
00000
Ingresos académicos
00001
Cuotas por inscripción
00002
Cuotas por colegiatura
37
Programa para la Normalización de la Información Administrativa
También consideramos una tabla con todos los registros contables y un encabezado
de esos registros que lo consideraríamos como la póliza, o el encabezado de la póliza, por
lo tanto el diagrama E-R básico de la contabilidad debe quedar como sigue :
A efecto de establecer un instrumento de registro y control que permita apoyar las
acciones encaminadas a fortalecer y consolidar tanto el flujo de información como la
transparencia de la aplicación de los recursos financieros con que cuentan las instituciones,
se deberá integrar la guía contabilizadora para la operación de la contabilidad matricial
propuesta por el Sistema Integral de Información Administrativa (SIIA).
Donde las tablas de fondos, UR, cuentas y funciones tienen la estructura básica de
clave y descripción, la de pólizas tiene además de su clave y descripción identificadores
de fecha, tipo, etcétera.
El registro contable debe tener al menos los campos de fondo, cuenta, UR y función,
además de un campo indicativo de cargo–abono y el monto del registro; además debe
estar cuadrado en fondo, esto es, que todas las pólizas que se registren en el sistema
deben estar validadas en el sentido de que la suma de abonos y cargos por cada fondo
deban ser iguales.
Naturalmente es alimentado por el registro natural de pólizas, pero en su operación
normal debe ser alimentado por pólizas automáticas que deben ser generadas a partir de
la operación de los otros módulos, esto es, que los movimientos de almacén registren
pólizas de almacén, los movimientos de pagos registren movimientos de pagos, y así
sucesivamente, por lo que el catálogo de cuentas debe tener algunas cuentas mínimas
para su conexión con los otros módulos, por ejemplo: debe tener una cuenta de bancos
para su control de bancos, una cuenta de cuentas por pagar para su control de cuentas
por pagar, y así sucesivamente, estas cuentas son mencionadas en cada uno de los
módulos a los que correspondan.
38
P
PR
RO
ON
NA
AD
D
Especificaciones técnicas del SIIA
Descripción del sistema computacional integral
Reservado
La estructura del reservado es prácticamente igual al contable, su uso se puede orientar
hacia presupuesto, esto es que sirve para registrar los movimientos que aún no son
contables, pero están en vías de serlo, por lo tanto, presupuestalmente deben ser
controlados. Para su esquema ver el libro contable.
El manejo de este registro es prácticamente automático, ya que su control está en
función de los movimientos generados por los otros módulos, aunque sería conveniente
dejar una entrada manual para ajustes en caso de problemas.
Subsistema de presupuestos
Al igual que el reservado, su esquema es prácticamente igual al contable. Se puede
definir en dos partes presupuesto de ingresos y presupuesto de egresos, que se llenan
respectivamente con entrada o salida de recursos.
El objetivo de este módulo es controlar la disponibilidad de recursos que no se destinen
a actividades diferentes a las proyectadas.
Siendo un esquema igual al contable su comparación se hará naturalmente.
El presupuesto controla además de lo ya ejercido (contabilidad) también lo que está
por ejercerse (reservado), facilitado esto precisamente por la igualdad de estructuras, la
comparación es automática.
El presupuesto se maneja en dos fases, primero se da de alta el presupuesto anual, a
través de pólizas de presupuesto, y después se le va asignando dinero durante el ejercicio,
de acuerdo como haya disponibilidad de recursos a través de las asignaciones
presupuestales.
Los módulos de detalle presupuestal y detalle de asignación presupuestal nos indican
precisamente cada uno de los movimientos que se les va asignando, durante el ejercicio,
a cada una de las fases.
Es necesario dar de alta los renglones presupuestales que se vayan a manejar, si no se
especifican entonces el programa marcará el error de “No existe registro presupuestal”,
cada que se quiera hacer un egreso.
Para asignar recursos para su ejercicio se hace con el módulo Control Presupuestal
con el proceso Asigna Presupuesto, aquí se teclea cuanto presupuesto se quiere asignar
y se asigna.
Si se quieren asignar cuentas a los renglones presupuestales, entonces en el módulo
de Control Presupuestal, con el proceso Asignar Cuentas, se asignan las cuentas
presupuestales.
P
PR
RO
ON
NA
AD
D
P
PR
RO
ON
NA
AD
D
39
Programa para la Normalización de la Información Administrativa
Si incluye cuenta y auxiliar, entonces el presupuesto queda directo apuntando a la
cuenta y auxiliar, si no se le pone auxiliar, entonces sólo queda apuntando a la cuenta de
mayor, sin importar qué auxiliar se designe.
Si se les pone una cantidad específica, entonces el presupuesto controla esa cantidad,
si no se les pone cantidad alguna, entonces el presupuesto sólo checa que para ese
renglón presupuestal sólo se puedan usar las cuentas que se capturen.
Los módulos que se encargan de estos procesos son los siguientes:
•
•
•
•
Pólizas de presupuesto
Control presupuestal
Detalle presupuestal
Detalle asignado
Pólizas de presupuesto
En este módulo se captura el presupuesto anual, cada que se quiera aumentar o
disminuir el presupuesto se hace a través de este módulo, para aumentar sólo se pone la
cantidad que se desea aumentar/disminuir en el renglón de monto, de cada registro que
se capture, para disminuir la cantidad se pone en negativo. Recordar que la aplicación se
refiere a cómo se checa el presupuesto, esto es que si ponen aplicación 1 debe capturar
programa y unidad responsable, en aplicación 2 no se necesita capturar U Responsable,
y en las especificadas por el usuario no necesita ninguna de las dos ni Programa ni Unidad
Responsable, en todos los casos los campos de Aplicación y Subfondo son requeridos.
40
P
PR
RO
ON
NA
AD
D
Especificaciones técnicas del SIIA
Descripción del sistema computacional integral
Control presupuestal
Este es el módulo donde se checa qué tal va el presupuesto, a continuación se describen
los campos:
Presupuesto :
Se va llenando con lo que se capture en pólizas presupuestales.
Asignado:
Se llena cuando se capturan las asignaciones presupuestales.
Reservado:
Contiene el total reservado, se llena con requisiciones, órdenes de compra, pólizas de
reservado, etcétera.
Por pagar:
Es el pasivo, cuenta 211, cada que se registre un pasivo este campo aumenta, y cuando
se paga disminuye, afectándose la cuenta.
Ejercido:
Es el total ejercido, se llena con los gastos, cuando existe un gasto este campo se
afecta, si es un gasto provisionado, se afecta y el pasivo lo disminuye, y en cuanto se
paga se vuelve a afectar.
Conceptos que se crean a partir de una fórmula:
Disponible presupuestal:
Es el disponible anual de acuerdo con:
Presupuesto disponible = presupuesto – reservado – por pagar – ejercido
P
PR
RO
ON
NA
AD
D
P
PR
RO
ON
NA
AD
D
41
Programa para la Normalización de la Información Administrativa
Disponible asignado:
Es el disponible de acuerdo con:
Disponible asignado = asignado – reservado – por pagar – ejercido
El detalle asignado corresponde a cada una de las asignaciones presupuestales, éstas
se capturan en el módulo de control presupuestal.
Aplicación presupuestal
El presupuesto se checa siempre por fondo y cuenta, cuando se define por cuenta,
pero para ver si se va a checar también por U responsable y programa se ponen la
aplicación.
Las aplicaciones 1 y 2 vienen por default, donde 1 checa siempre U Responsable y
Programa, y la 2 checa programa sin importar U Responsable, las demás aplicaciones
que se den de alta se checan directamente, sin importar Programa o U Responsable,
éstas son definidas directamente por el usuario.
Años fiscales
Se refiere al catálogo de años fiscales que se van a manejar; es necesario para la
operación financiera.
42
P
PR
RO
ON
NA
AD
D
Especificaciones técnicas del SIIA
Descripción del sistema computacional integral
Periodos fiscales
Meses que se abren dentro de un año fiscal, se manejan los meses naturales, del 01 al
12 y un 00 para periodo inicial y un 3 para periodo final.
Subsistema de contabilidad
Cuentas contables y auxiliares
Tipo y subtipo ya vienen por default; no se capturan y corresponden a los números de
la gráfica.
En el módulo de catálogo de cuentas podemos ver las cuentas que están registradas
en el sistema. La forma de detalle para este módulo es el siguiente:
Las cuentas de mayor en su mayoría también vienen por default excepto:
Activos fijos
Gastos e ingresos
Estas cuentas de mayor se dan de alta en los módulos de:
• Tipos de activos fijos
• Tipos de gastos
• Tipos de ingresos respectivamente
En los catálogos de auxiliares se construye dinámicamente el árbol al usar el campo
predecesor, esto es, que ese campo corresponde al padre del registro en cuestión.
También es común en los catálogos de auxiliares el campo entra-datos, que corresponde
a si se permite o no meter datos a la cuenta correspondiente.
P
PR
RO
ON
NA
AD
D
P
PR
RO
ON
NA
AD
D
43
Programa para la Normalización de la Información Administrativa
Pólizas contables
Contiene todas las pólizas contables, tanto las generadas automáticamente como las
capturadas en este mismo módulo, las que se capturan en este módulo son las tipo PD, el
resto son generadas automáticamente.
(ver módulo Tipos de Documento bajo Catálogos – Otros Catálogos).
En este módulo sólo se pueden crear/modificar/cancelar pólizas de diario (PD), para
poder modificar las otras es necesario hacerlo desde el módulo donde se crearon, pero si
puede ver los detalles contables de los otros documentos, con seleccionar el documento
correspondiente. A continuación se describen los campos:
Documento
Es el número de documento. Es un número único para todos los documentos, por cada
póliza que se crea, ya sea contable o de reservado, se le asigna un número y este es el
número que se asigna.
TDoc
Se refiere al tipo de documento que genera la póliza, ver la tabla de tipos de documento,
para referencia.
Año
Año fiscal del documento
Mes
Mes o periodo al que corresponde el documento
44
P
PR
RO
ON
NA
AD
D
Especificaciones técnicas del SIIA
Descripción del sistema computacional integral
Núm.
Número consecutivo, por cada TDoc-Año-Mes se genera un consecutivo, este es el
número consecutivo que corresponde a la póliza o documento en cuestión.
Fecha
Fecha del documento
Descripción
Descripción del documento
Cancel
Indica si el documento está cancelado o no, esto es cuando el documento está cancelado
en el mismo mes o periodo fiscal, si fue cancelado con una póliza de reversa entonces no
aparece como cancelado.
Docum cancel
Nos indica el número de documento que lo cancela, si el documento se cancela en el
mismo mes entonces nos dice el mismo número del documento y el campo cancel está en
S ; si está cancelado con una póliza de reversa en diferente mes entonces nos indica el
documento que lo cancela, y el campo cancel está en N, obviamente si no tiene datos
entonces el documento no está cancelado.
P
PR
RO
ON
NA
AD
D
P
PR
RO
ON
NA
AD
D
45
Programa para la Normalización de la Información Administrativa
Estados financieros
Este es un módulo de reportes, aquí se generan los reportes indicados en el periodo
especificado en la parte superior, los campos en tiempo a especificar son los de año,
periodo inicial y periodo final.
Los otros campos a especificar son los de fondo y subfondo, en donde se pueden
especificar todos, para sacar un consolidado y algún fondo y/o subfondo específico según
se requiera el reporte.
La opción de auxiliar nos genera un auxiliar en forma de árbol de la cuenta seleccionada
en el combo de auxiliar, tomando en cuenta también los parámetros de selección
especificados al inicio.
La forma en la que solicitamos el tipo de reporte es el siguiente:
Análisis de ingresos/gastos
Este es un reporte dinámico, genera, también de acuerdo con los parámetros indicados
en la parte superior, ya sea los ingresos o los gastos generados, tanto de forma tabular
como gráfica, estos ingresos/gastos se pueden generar por cada uno de los botones
indicados en parte superior, por subfondo / cuenta / programa / ures, y una vez generado
por alguno de estos factores, se puede sacar su desagregado por cada uno de estos
factores, esto es:
Si queremos el total gastado por programa pulsamos el botón “programa”, de alguno
de los registros seleccionados deseamos su desglose por U Responsable, pulsamos el
46
P
PR
RO
ON
NA
AD
D
Especificaciones técnicas del SIIA
Descripción del sistema computacional integral
botón “U Responsable”, y así sucesivamente, ahora, si deseamos verlo gráficamente,
entonces pulsamos el botón “gráfico” y nos muestra un comparativo en gráfico de barras,
y volviendo a pulsar el botón nos regresa al modo tabular.
Si no deseamos cierto renglón en el gráfico, entonces hacemos doble clic en la cruz del
renglón, y la cruz desaparece en modo tabular, y cuando seleccionamos gráfico no aparece
el renglón marcado, para volver a ponerlo sólo tecleamos doble clic en donde estaba la
cruz y la cruz aparece y vuelve a aparecer.
Ejemplo de gráfica de análisis de ingresos/gastos
Subsistema de compras
En esta sección se capturan las compras, desde las requisiciones hasta las órdenes de
pago, es necesario tener las oficinas de compra capturadas, ya que las compras siempre
se refieren a este campo.
El orden normal para hacer una compra es hacer la requisición, posteriormente se
hace la orden de compra, cuando el proveedor entrega la mercancía se corre el proceso
de recepción de mercancía de órdenes de compra, y cuando la oficina entrega la mercancía
a las dependencias corre el proceso de entrega de mercancía, esto se detalla más en el
módulo de órdenes de compra.
Los módulos relacionados con compras son los siguientes:
• Oficinas de compra
• Requisición de compra
P
PR
RO
ON
NA
AD
D
P
PR
RO
ON
NA
AD
D
47
Programa para la Normalización de la Información Administrativa
• Orden de compra
• Ítems pendientes
Oficinas de compra
En un catálogo, cuando se vaya a comprar o se requiera comprar algo, se debe
especificar la oficina que va a hacer la compra, en este módulo se capturan estas oficinas.
Requisición de compra
Para poder hacer peticiones debe tener presupuesto suficiente en los renglones
contables que se especifiquen, a continuación se describen los campos:
Encabezado
Requisición
Se refiere al número del documento de la requisición, se calcula cuando se graba la
requisición, junto con los datos de la póliza.
Descripción:
48
P
PR
RO
ON
NA
AD
D
Especificaciones técnicas del SIIA
Descripción del sistema computacional integral
Una descripción general de la requisición.
Oficina
La oficina a la cual se hace la petición, capturada en el módulo de Oficinas de Compra.
U Resp
Unidad responsable de la requisición, del catálogo de unidades responsables
Fecha de requisición
Fecha del documento
Teléfono
Teléfono al cual se puede llamar para aclarar datos de la requisición
Texto
Texto descriptivo, aquí se puede poner un texto describiendo a mayor detalle la
requisición.
Detalle
Id
Id único del renglón requerido, con este identificador se hacen las órdenes de compra,
y se identifica todo el renglón, es calculado a la hora de grabar.
Ítem
Consecutivo, descripción del renglón
Cantidad
Cuantas unidades se están requiriendo
Precio unitario
Precio que se está dispuesto a gastar por unidad, el precio de la orden de compra no
podrá ser mayor al especificado en este renglón.
Subfondo, prog, aplicación, cuenta y auxiliar
Distribución contable al cual aplicar el renglón
Órdenes de compra
Orden de compra que se entrega al proveedor para surtir la mercancía que se requirió,
en este módulo se surten las requisiciones, se hacen las órdenes de compra, y también
se entrega la mercancía a las unidades responsables o personas que requirieron los
P
PR
RO
ON
NA
AD
D
P
PR
RO
ON
NA
AD
D
49
Programa para la Normalización de la Información Administrativa
bienes, es posible hacer una sola orden de compra para muchas requisiciones, la única
condición es que sean hechas a la misma oficina de compras.
Campos:
Encabezado
Orden
Número de documento con descripción del mismo
Oficina
Clave de la oficina que va a ser la orden de compra
Proveedor
Clave del proveedor al que se le va a pedir la orden, este dato se captura en el catálogo
de personas, y a la persona que va a ser proveedor se le pone la marca de proveedor, ver
catálogo de personas.
Lugar de entrega
Se refiere a algún lugar específico donde entregar la orden, campo indicativo
Fecha de la orden
Cuando se hace la orden de compra
Texto
Texto descriptivo de la orden de compra
Detalle orden de compra
50
P
PR
RO
ON
NA
AD
D
Especificaciones técnicas del SIIA
Descripción del sistema computacional integral
Descripción del bien a comprar
Cuenta-auxiliar
Cuenta contable y auxiliar del bien, este par de campos se comparan contra el pedido
por la requisición, si no corresponden entonces marcará error.
Precio
Precio de compra del proveedor, recordar que el precio unitario del ítem no puede ser
mayor al autorizado por la requisición.
Entregada
Campo sólo de lectura, indica cuantos ítems ha entregado ya el proveedor.
Cantidad
Campo sólo de lectura, se va llenando cuando se captura el detalle de requisiciones,
indica la cantidad total de ítems a pedir.
Total
Indica el total del renglón
Detalle requisición
Id
Id del renglón de la requisición
Cantidad
Cantidad que se va a comprar de ese renglón
Entregado
Campo sólo de lectura, indica si ya se entregó a la dependencia ese renglón.
Importe
Sólo lectura, indica el importe real de ese renglón de requisición.
Precio unitario autorizado
Sólo lectura indica el precio máximo que se autorizó para el ítem, recordar que el precio
unitario del ítem no puede ser mayor al autorizado en la requisición.
P
PR
RO
ON
NA
AD
D
P
PR
RO
ON
NA
AD
D
51
Programa para la Normalización de la Información Administrativa
Procesos de órdenes de compra
Recepción de mercancía
Este proceso se ejecuta cuando el proveedor entrega la mercancía a la oficina de
compras, se captura la fecha de recepción de la mercancía y el nombre de la persona que
la recibe. Después de realizar este proceso no es posible modificar la orden de compra,
también aquí se hace la afectación de los activos fijos, y no se puede facturar una orden
de compra si este proceso no ha sido terminado.
Entrega de mercancía
Es cuando se entrega la mercancía a las requisiciones originales; se pueden entregar
de una en una, o en partes, para hacerlo se debe marcar en el renglón correspondiente de
requisiciones el campo “Entregado”, de hecho es el único que está activado en este proceso.
Una vez marcado queda automáticamente afectada la requisición como que ya recibió la
mercancía que requirió.
Ítems de pendientes
Esta tabla muestra los renglones de requisiciones que están pendientes por surtir, el
campo “Pendiente” indica precisamente la cantidad pendiente, los demás son datos
referentes al renglón de la requisición que falta por ser atendida.
52
P
PR
RO
ON
NA
AD
D
Especificaciones técnicas del SIIA
Descripción del sistema computacional integral
Subsistema de almacén
Es el control del almacén, sus entradas y salidas, todos los movimientos quedan
registrados y pueden ser revisados en el módulo de Detalle de Movimientos de Almacén.
Estos movimientos tienes dos atributos principales:
El primero indica si es entrada o salida, que se refleja en el campo “Movimiento”.
El segundo si el movimiento es real o requerido (R= real, Q=requerido), reflejados en el
campo tipo. El real es cuando existe una entrada o salida real del inventario. El requerido
se usa cuando es entrada que hubo una requisición; cuando es salida es que se cancela
ese movimiento, ya sea por cancelación de la requisición o por entrega del artículo.
A continuación se describen los procesos naturales de movimientos de almacén y sus
efectos en contabilidad.
Las entradas al almacén naturalmente se registran cuando existen compras directas
para el almacén, a través de una orden de compra, en cuanto se recibe la mercancía de la
orden se afectan tanto los inventarios como los precios en el almacén, calculados al costo
promedio.
La generación de los movimientos contables correspondientes se reflejan en cuanto
se registra la factura de la compra, con cargo al almacén que se surte con la compra, y
abono cuentas por pagar, que se salda en cuanto se hace el pago :
El bloque de almacén está formado por los siguientes módulos
P
PR
RO
ON
NA
AD
D
P
PR
RO
ON
NA
AD
D
•
Artículos
•
Existencias
•
Requisiciones de almacén
•
Artículos pendientes de entrega
•
Entregas de almacén
•
Devoluciones de almacén
•
Ajuste de almacén
53
Programa para la Normalización de la Información Administrativa
Flujo de control en almacén
En la gráfica podemos observar que hay dos líneas de flujo: el control de almacén y
pagos a proveedores.
En el control de almacén, primero creamos una requisición de almacén, posteriormente
el almacén lo revisa y decide surtirlo o no con una entrega de almacén.
El último eslabón se utiliza cuando la dependencia que recibió un artículo desea
regresarlo al almacén, para esto se usa el módulo de devoluciones de almacén.
En el proceso de pagos a proveedores, primero damos de alta la factura del proveedor
con el módulo de Facturas de Almacén y de ahí pasamos al módulo de Pagos.
Las salidas se registran cuando hay una entrega del almacén a la dependencia, esto se
hace a través del módulo de entregas de almacén. Inicialmente hay una requisición de
almacén, iniciada por la dependencia, que es la que afecta el tipo requerido en los
movimientos de almacén, cuando aún no se le surte, esto hace una especie de reservación,
la cual se cancela en cuanto se surte el ítem con una entrega de almacén, o cuando se
cancela la requisición de almacén.
La requisición afecta el libro de Reservado al FUCP (Fondo-Unidad ResponsableCuenta-Programa) de la requisición. Contablemente se afecta en el momento de la entrega,
con el abono al almacén que surte la mercancía y el cargo a la distribución:
54
P
PR
RO
ON
NA
AD
D
Especificaciones técnicas del SIIA
Descripción del sistema computacional integral
Además de permitir ajustes de almacén, este módulo sirve para ajustar el almacén a
existencias y precios reales, normalmente se utiliza al inicio de la operación, o cuando se
hacen conteos físicos o simplemente cuando se quieran reajustar los valores tanto de
inventarios como en libros.
Los movimientos que se hacen cuando se realiza este ajuste son de almacén, el cual
da una salida a la existencia actual y una entrada a la nueva existencia ajustándose como
se requiera; en contabilidad se refleja la salida como un abono al almacén y cargo a la
cuenta de ajustes de almacén con la distribución capturada en el ajuste.
Mientras que la entrada se refleja como un cargo al almacén con abono a la cuenta de
ajuste de almacén
Adquisiciones
Este módulo corresponde al de compras, que se hacen por dos vías: cuando la
dependencia quiere comprar algo, donde se puede decir que es una compra por pedido,
o cuando se quiere comprar para el almacén, en cuyo caso en cuanto se compran, se
aumentan y actualizan las existencias en almacén.
El primer caso, de compra por pedido, supone que debe existir presupuesto suficiente
para que la dependencia compre, y esto se verifica porque desde la requisición de compra
hay movimientos en el libro de reservado.
Una vez que se hace la requisición, se alimenta la tabla de ítems por comprar, que
estaría revisando el cliente para ver qué artículo les hace falta, de ahí procede la orden de
compra, donde ésta asociaría todas las requisiciones que vienen de ítems comunes; por
ejemplo, si varias dependencias piden computadoras, con una sola orden de compra se
asocian estas requisiciones.
Con la orden de compra capturada proceden dos acciones: pagar anticipos, en el módulo
de anticipo a proveedores, o recibir la mercancía, donde no se pueden pagar anticipos ya
que el procedimiento de pago sería a través de la factura.
De la recepción de mercancía viene su entrega a las dependencias que la requirieron,
cerrando así el ciclo de la requisición.
Cuando se compran artículos de almacén, no existen los movimientos en compras,
más bien se hacen los movimientos en almacén, tal y como se explica en el módulo de
almacén y en el de facturas de compra.
P
PR
RO
ON
NA
AD
D
P
PR
RO
ON
NA
AD
D
55
Programa para la Normalización de la Información Administrativa
Artículos
En este módulo se dan de alta todos los artículos que vayan a ser manejados por los
almacenes.
Es importante seleccionar correctamente la cuenta que se va a vincular con el artículo.
56
P
PR
RO
ON
NA
AD
D
Especificaciones técnicas del SIIA
Descripción del sistema computacional integral
Requisiciones de almacén
Este documento se utiliza cuando una dependencia necesita algún bien que se encuentra
disponible en un almacén, por lo que no hay necesidad de hacer una requisición de compra.
La forma de captura de este módulo es la siguiente:
La forma está dividida en dos partes:
En la parte superior se capturan los datos generales de la requisición y en la inferior
cada artículo que se solicita al almacén.
Hay dos tipos de cancelación de requisiciones:
1. Completas y
2. Parciales
Las completas son las que hacemos cuando no hemos recibido ningún artículo del
almacén, por lo que todos los artículos se cancelan.
Las cancelaciones parciales se dan cuando ya hemos recibido parte de lo que pedimos
y sabemos que lo restante ya no se va a surtir.
Entregas de almacén
Una vez que una dependencia ha hecho una requisición es necesario hacer un
documento de entrega de almacén para sacar los artículos y dárselos a la dependencia.
La entrega se hace por dependencia y por almacén, es decir, podemos hacer la entrega
de un artículo de cualquier requisición que una dependencia haya hecho al almacén, pero
no podemos mezclar requisiciones de distintas dependencias.
P
PR
RO
ON
NA
AD
D
P
PR
RO
ON
NA
AD
D
57
Programa para la Normalización de la Información Administrativa
La forma de detalle de este módulo es la siguiente:
La forma está dividida en dos partes:
En la parte superior se capturan los datos generales de la entrega y en la inferior cada
artículo que se entrega a la dependencia.
Una vez creada una entrega no la podemos editar.
Para revertir los efectos que provoca podemos cancelarlo o usar una devolución de
almacén dependiendo de las circunstancias.
Devoluciones al almacén
Después de realizar una entrega, algunas veces vamos a hacer devoluciones al almacén.
Para lograr esto es necesario usar el módulo de devoluciones de almacén.
La siguiente figura muestra la forma de detalle del módulo:
La forma está dividida en dos partes:
En la parte superior se capturan los datos generales de la devolución y en la inferior
cada artículo que se devuelve al almacén.
58
P
PR
RO
ON
NA
AD
D
Especificaciones técnicas del SIIA
Descripción del sistema computacional integral
Facturas de almacén
Aquí se capturan las facturas que van directamente al almacén, el movimiento contable
que se realiza es cargo a éste (113) con abono a documentos por pagar (216); capturar la
factura automáticamente incrementa la disponibilidad del artículo adquirido y también el
precio, según se haya registrado, obviamente en caso de cancelación se eliminan los
artículos registrados.
Facturas de compra directa
Es la facturación de las órdenes de compra, para poder capturar en este módulo debe
existir una orden de compra anterior.
En caso de que la orden de compra tenga un anticipo sin pagar pendiente, se elimina
ese pendiente de pago del anticipo, pasando a por pagar de la factura, cancelando el
movimiento contablemente.
El movimiento normal es de cargo a egresos (5xx) con abono a cuentas por pagar
(211), en caso de que existiera una retención de impuestos, entonces se haría el
correspondiente abono a (211) con cargo al impuesto al que se fuera a retener (213).
La captura de la factura implica que no se pueden mover las órdenes de compra.
P
PR
RO
ON
NA
AD
D
P
PR
RO
ON
NA
AD
D
59
Programa para la Normalización de la Información Administrativa
Subsistema de cuentas por pagar
Todos los pagos que se hagan o que se vayan a hacer, deben entrar a cuentas por
pagar, y dependiendo del tipo de cuenta por pagar es el movimiento contable que se
realiza, normalmente el abono se hace a cuentas por pagar, cuando el cargo corresponde
a cuentas de egresos, y si el cargo corresponde a otro tipo de cuentas que no sean
egresos el abono se hace a documentos por pagar.
En cuanto se hace el registro de la cuenta por pagar, cualquiera que sea, ésta aparece
en el módulo de pagos pendientes esperando ser pagada.
A continuación se describen cada uno de los tipos de cuentas por pagar que
corresponden a cada uno de los documentos por pagar que se manejan, cada uno de
estos documentos se capturan por separado, estos documentos pueden ser:
• Anticipo a proveedores
• Facturas de almacén
• Facturas de compra directa
• Otros pagos
• Vales
Anticipo a proveedores
Este documento apunta directamente a una orden de compra que no se haya recibido
ni facturado, contablemente hace un movimiento de cargo a anticipo a proveedores (151)
y abono a documentos por pagar (216), si existe un anticipo capturado el sistema no
permitirá cambios en la orden de compra correspondiente.
Esta cuenta por pagar se alimenta desde la orden de compra, por cada orden de compra
que se haga, siempre que no se haya recibido, y por lo tanto tampoco esté facturada, se
puede hacer un anticipo de la misma, los movimientos contables que se realizan son
cargo a anticipo a proveedores con abono a documentos por pagar.
60
P
PR
RO
ON
NA
AD
D
Especificaciones técnicas del SIIA
Descripción del sistema computacional integral
Facturas de compras
El paso normal después de la orden de compra es la factura de la compra, por cada
orden de compra, una vez recibida, la factura se registra precisamente en este módulo,
se hace una sola factura por cada orden de compra, no hay agrupaciones, una orden de
compra, una factura.
El monto a pagar de la factura depende de si hubo antes anticipo o no, en caso de que
haya algún anticipo, éste se disminuye del total a pagar, y se hacen los movimientos
contables correspondientes, otro factor que entra es cuando se quieren hacer retenciones,
estas retenciones apuntan a las cuentas de impuestos, y cuando se capturan se pueden
mover a donde se desee.
Los movimientos en contabilidad dependiendo del tipo de compra.
La factura tiene impacto también en movimientos de reservado para cancelar los
movimientos de la orden de compra que se generaron, siempre y cuando las compras no
sean de artículos de almacén, ya que en ese caso no hay registro en reservado.
Si se compran artículos de almacén, entonces por cada ítem de compra de artículo de
almacén, los movimientos son de cargo al almacén, con abono a documentos por pagar,
como no hay movimientos generados en reservado con almacén no se genera ningún
movimiento.
P
PR
RO
ON
NA
AD
D
P
PR
RO
ON
NA
AD
D
61
Programa para la Normalización de la Información Administrativa
Cuando se compran ítems que no son de almacén, es decir, cuando se surten
requisiciones de compra, entonces el cargo sería a la distribución contable de la requisiciónorden de compra que se está surtiendo, y que normalmente son cuentas de gastos, con el
abono a cuentas por pagar. También en reservado hay movimientos, como la orden de
compra generó algunos movimientos la factura los elimina y éste es el caso en el que la
factura tiene presencia en el libro de reservado, por otro lado también se actualizan en el
módulo de ítems por entregar los ítems que falta darle a las dependencias.
Cuando la orden de compra tuvo algún pago por anticipado (anticipo a proveedores),
entonces en el momento de hacer la factura se hace el correspondiente abono a anticipo
a proveedores con el cargo a documentos por pagar, para saldar la cuenta de anticipos.
Por último, en caso de que la orden de compra haya tenido alguna retención, los
movimientos normales que aplicarían en la retención serían de un cargo a documentos
por pagar, si es un ítem de artículos de almacén, o a cuentas por pagar, si el ítem pertenece
a una requisición de compra.
Otros documentos por pagar
Este módulo es para meter cualquier otro tipo de documento que no venga de requisición
o almacén, se puede decir que éste es una factura abierta, el movimiento contable natural
es de cargo al FUCP, capturado en el mismo documento, con abono a cuentas por pagar
si es que la cuenta que se captura pertenece a gastos, o a documentos por pagar en caso
contrario que la cuenta no pertenezca a gastos, se capturan las unidades porque en el
momento de hacer la factura, si es que la cuenta que se pone es de activos fijos, entonces
las unidades capturadas automáticamente se cargan en la tabla de inventarios.
62
P
PR
RO
ON
NA
AD
D
Especificaciones técnicas del SIIA
Descripción del sistema computacional integral
Vales
Vales o cuentas por comprobar, el vale se carga directamente a gastos por comprobar
al empleado que se captura en el vale con el abono a C por pagar, en cuanto es pagado,
la cantidad que se paga espera ser comprobada, esto es que se captura el vale, con los
movimientos contables correspondientes, en cuanto se paga, la cantidad que se paga
espera ser comprobada, por lo que aparece en el módulo de documentos por comprobar,
pero siempre y cuando se haya pagado, si no se paga no aparece ahí.
Son los documentos por comprobar que esperan normalmente una comprobación (ver
módulos de comprobaciones), el documento contablemente se maneja como cargo a
cuentas por comprobar (531), con abono a cuentas por pagar (211).
Pagos
Toda generación de una cuenta por pagar naturalmente genera un pago pendiente,
este pago pendiente queda registrado en el módulo de pagos pendientes, y en cuanto se
paga o emite el cheque se cancela el pago pendiente, el movimiento contable es, por lo
tanto, el cargo a cuentas o documentos por pagar, con el abono a la cuenta de banco o
caja correspondiente, en todos los casos de cuentas por pagar (ver módulo) se presenta
el mismo esquema:
P
PR
RO
ON
NA
AD
D
P
PR
RO
ON
NA
AD
D
63
Programa para la Normalización de la Información Administrativa
El pago, naturalmente, es la cancelación del pago pendiente o contablemente se puede
interpretar como que el documento por pagar se provisiona, y el pago es la cancelación
de la provisión o del pasivo.
Otros pagos
Se refiere a cualquier otro tipo de pago que se quiera hacer, que no sea gasto, como
pagos de impuestos, regresos de dinero, etcétera.
El movimiento contable es cargo a la cuenta que se quiera pagar (xx) y abono a
documentos por pagar (216).
64
P
PR
RO
ON
NA
AD
D
Especificaciones técnicas del SIIA
Descripción del sistema computacional integral
Subsistema de pagos
Todos los documentos que se capturan en cuentas por pagar pasan a pagos, en esta
parte se capturan precisamente los pagos, el control de pagos siempre es por persona,
sin importar qué documento sea (vale, factura, etcétera).
Los módulos de este bloque son:
•
Pagos
•
Cheques por imprimir
•
Pagos pendientes
•
Pagos por documento
Primero se capturan los pagos que se deseen hacer, eligiendo la persona y el banco
con el que se va a hacer el pago, en el campo “nombre” se captura a nombre de quién se
desea que sea el pago, o el cheque si es un cheque, después se registra documento por
documento que se está pagando.
El movimiento contable depende de cuál documento sea el que se esté pagando, si es
anticipo a proveedores, factura de almacén u otros pagos, entonces el movimiento contable
sería documentos por pagar (216) contra bancos (112), si fueran vales o facturas de
compra sería cuentas por pagar (211) contra bancos, cada renglón se procesa
individualmente.
Cancelación cheque
En caso de que el pago ya se haya impreso en un cheque, entonces el proceso de
“cancela cheque” elimina la relación entre el pago y el cheque, dejándolo disponible para
otra impresión, para cancelar todo el pago es necesario usar la opción de “borrar” del
mismo menú de pagos.
P
PR
RO
ON
NA
AD
D
P
PR
RO
ON
NA
AD
D
65
Programa para la Normalización de la Información Administrativa
Cheques por imprimir
Todos los pagos que se hayan registrado como cheques, y aún no hayan sido impresos,
o en los que se canceló el cheque, quedan registrados en esta tabla; para hacer la impresión
se selecciona la opción detalle y se siguen las instrucciones, para poder imprimir deben
seleccionarse siempre cheques del mismo banco, si no el sistema marcará error, se pueden
seleccionar los cheques que se deseen para imprimirse.
Pagos pendientes
En esta tabla aparece cada uno de los pagos pendientes, por renglón, son los
documentos que se han capturado en cuentas por pagar y aun no para su pago, esto es
para que se sepa cuántos documentos o renglones de documentos faltan por pagarse.
Pagos por documentos
Esta es una tabla que nos muestra la relación entre pagos y documentos, esto es, qué
documentos tiene cada pago, y qué cantidad se pagó por cada documento. Es una tabla
sólo de consulta.
Cuentas por comprobar
Cuando se paga un vale, automáticamente se convierte en una cuenta por comprobar,
ya que hay una salida de dinero y necesita ser comprobada, normalmente el vale es un
cargo a cuenta por comprobar con abono a cuenta por pagar (ver vales), por lo que la
comprobación debe corresponder a un abono a la cuenta por comprobar con el cargo a la
cuenta que se está comprobando, esta cuenta viene especificada con el documento de
comprobación que se presenta y se captura precisamente en este módulo.
66
P
PR
RO
ON
NA
AD
D
Especificaciones técnicas del SIIA
Descripción del sistema computacional integral
Debe existir un registro de comprobaciones donde se tenga el estado de cuenta por
comprobar de los empleados, esto es que cada empleado debe saber qué vales debe
comprobar y por cuánto, eso es lo que se menciona en el esquema como comprobaciones,
donde se va registrando y saldando cada vale, cuando se paga y cuando se comprueba.
Bienes patrimoniales
Este es el control de los activos fijos o bienes patrimoniales de la institución, este
módulo no tiene pólizas automáticas como las mencionadas anteriormente, al contrario,
cada una de las pólizas que se generen con cualquiera de los módulos anteriores debe
registrar el bien que se está adquiriendo. Cuando se registre algún bien, la manera como
el sistema lo sabría es porque el bien corresponde a algún activo fijo, y los documentos
que alimentan este módulo deben ser los módulos de compras y comprobaciones, aunque
también este módulo permite el registro de bienes sin necesidad de ser generados
automáticamente, debe mantenerse el valor de los bienes igual al valor en libros, para
que exista una correspondencia auténtica entre los activos fijos y los bienes reales.
Cada registro del bien debe permitir además, asignación de responsabilidad, esto es,
debe saberse qué dependencia lo tiene, y cuál es la persona que se hace responsable del
mismo, (resguardo), y también las reasignaciones junto con los históricos de esas
reasignaciones, y por último cuando el bien muere, la posibilidad de dar de baja el bien.
P
PR
RO
ON
NA
AD
D
P
PR
RO
ON
NA
AD
D
67
Programa para la Normalización de la Información Administrativa
Cuentas por cobrar-pagos
En esta tabla se registran las cuentas por cobrar, aquí también viene la conexión con el
módulo de escolar, ya que siendo una universidad, los servicios que presta son
precisamente servicios escolares, ya sean:
• Matrículas
• Inscripciones
• Documentación, etcétera.
Por lo tanto, estas cuentas por cobrar deben tener los datos de escolar que se cobren,
valga la redundancia, como conceptos de ingresos, y además los datos que nos indiquen
quién pago y qué paga.
Para ser más claro, el registro de cuenta por cobrar debe contener:
1. Concepto de ingreso (ligado a la cuenta contable)
2. Persona a la que se le cobra (en su mayoría la clave del alumno)
3. Unidad responsable o dependencia
4. Materia, carrera y/o curso que paga (datos de ubicación del alumno)
5. Monto que se cobra
Donde una cuenta por cobrar típica sería :
1. Matrícula
2. Alumno 11234
3. Facultad de Ingeniería
4. Ciclo escolar 99-1
5. $220.00
O si se cobrara por materia tendríamos:
1. Matrícula
2. Alumno 11234
3. Facultad de Ingeniería
4. Matemáticas I, Ciclo escolar 99’1
5. $220.00
Como podemos ver, los datos correspondientes al módulo de Escolar se reflejan en el
campo 4, donde debemos tener los catálogos de materias, ciclos, carreras, y en el campo
2, donde esperamos una liga con un catálogo de alumnos.
Aunque podríamos interpretar el catálogo de carreras como un subconjunto del catálogo
de programas, esto es, las carreras deben ser todos los programas que pertenezcan a la
función 01 (docencia), y aquí es donde tenemos la otra liga a escolar, a través de los
catálogos de funciones.
Interpretado como un E-R el esquema de cuentas por cobrar seria como sigue:
68
P
PR
RO
ON
NA
AD
D
Especificaciones técnicas del SIIA
Descripción del sistema computacional integral
Normalmente son las dependencias escolares las que generan estas cuentas por cobrar,
ya que son ellas las que prestan los servicios escolares, mientras que las dependencias
financieras son las que captan los recursos, estas dependencias deben ser las cajas,
donde las cajas están conectadas a la base de datos, por tanto, la recepción del pago, así
como la alimentación de las cuentas por pagar se realiza de forma automática.
El modelo de cuentas por cobrar se puede comparar al de cuentas por pagar, sólo que
al revés, aquí se espera cobrar, en vez de pagar, por lo que los movimientos contables
naturales serían de abono a ingresos con cargo a cuentas por cobrar, en cuanto existe el
registro, y una vez pagado sería el abono a cuentas por cobrar con el cargo, por lo tanto el
esquema final contable para ingresos se reflejaría como sigue:
P
PR
RO
ON
NA
AD
D
P
PR
RO
ON
NA
AD
D
69
Programa para la Normalización de la Información Administrativa
Subsistema de ingresos
La captura de los ingresos se hace siempre a través del módulo denominado Caja,
esto es que todas las entradas de dinero deben ser por este módulo, aquí se capturan de
dos formas, ya sea por cuentas por cobrar, que sería los adeudos de los estudiantes y/o
clientes, y la de varios, donde se captura cualquier cosa que ingrese, a continuación se
describen los módulos:
•
•
•
•
•
Caja
Cortes
Detalle de cortes
Ingresos por clasificar
Cuentas por cobrar
Proceso de ingresos
La gráfica nos muestra que este proceso está basado en el módulo de Cajas.
El origen de las entradas puede ser de tres tipos:
• Cuentas por cobrar
• Otros ingresos e
• Ingresos por clasificar
Los últimos dos tipos se capturan directamente en el módulo de cajas, en cuanto al
primero, el documento por cobrar se genera en el módulo de cuentas por cobrar.
Una vez que recibimos el ingreso éste puede pasar a reclasificarse (si es un ingreso
por clasificar) al módulo de ingresos por clasificar.
Caja
70
P
PR
RO
ON
NA
AD
D
Especificaciones técnicas del SIIA
Descripción del sistema computacional integral
Este es el módulo de caja, para poder entrar a este módulo el usuario debe estar
definido como cajero y ligar su número de persona con su número de cuenta del sistema,
esto se hace en el módulo de personas, si no está definido como cajero, entonces nunca
podrá entrar al módulo de caja.
Cuando entra a caja automáticamente se abre un nuevo corte si es que no había ningún
previo sin cerrar, en caso de que exista un corte abierto para ese cajero, entonces se abre
el corte abierto y siempre se abrirá éste hasta que no se cierre o cancele.
Aquí se captura ya sea clientes, donde lo que entra se abona directamente a su cuenta
cancelando sus pendientes, o varios, donde se captura los que no sean clasificados como
clientes.
Para cancelar los movimientos, borrar, en caso de equivocación del cajero, esto debe
hacerlo una persona autorizada, para autorizar esta persona, también en el módulo de
personas, se le debe dar el derecho de que pueda cancelar caja, y sólo si esta persona
entra con su cuenta y contraseña se podrá eliminar el movimiento, una vez entrado el
movimiento no se puede modificar, sólo cancelar y a través de la persona autorizada.
Cuando no se le pone la cuenta (concepto) al movimiento, éste se registra como varios,
y pasa al módulo de por clasificar, el cual haría la reclasificación a la cuenta correspondiente,
Hay dos maneras de terminar el corte: cerrarlo o cancelarlo, y se hace pulsando la
opción del menú, ahora bien, cerrarlo lo puede hacer el mismo cajero, pero para cancelarlo
sólo podrá hacer la persona autorizada.
Si se cancela no pasa nada, si se cierra o termina, automáticamente se crea la póliza
con cargo a cajas, cuenta 111, y abono a la cuenta de ingresos que se haya seleccionado;
si fue varios, si fue indeterminado a cuenta 421, que es ingresos por clasificar, y si es
cliente, entonces el abono corresponde a la cuenta del cliente que se salda (ver cuentas
por cobrar).
Cortes
Corresponde a un listado de todos los cortes, su total y estado.
Detalles de cortes
Corresponde a los renglones que se capturan en los cortes, si el campo cliente tiene
algún valor, entonces corresponde a un pago de clientes, si no corresponde a un ingreso
de varios.
Ingresos por clasificar
Corresponde a los ingresos que no se clasificaron en caja y esperan ser clasificados,
para poder hacerlo usar el proceso clasificar, y de ahí hacer la clasificación correspondiente.
Cuentas por cobrar
Aquí se capturan las cuentas por cobrar.
P
PR
RO
ON
NA
AD
D
P
PR
RO
ON
NA
AD
D
71
Programa para la Normalización de la Información Administrativa
Notar que aquí aparecen campos del módulo escolar que son:
• Materia
• Ciclo
El campo Programa se puede interpretar como carrera, por lo tanto aquí se puede ver
quién pago o no una materia, un ciclo, etc., según la política de la institución, los campos
de materia y ciclo se llenan en el módulo de escolar.
Subsistema de comprobación de gastos
Cuando un vale se paga entra en vigor el módulo de comprobaciones, funcionando
con los siguientes módulos:
• Documentos por comprobar
• Detalle por comprobar
• Comprobaciones
Documentos por comprobar
Se refiere a los faltantes por comprobar por documento (vale), aquí se puede ver cuántos
y cuánto falta por comprobar por documento.
Detalle por comprobar
Es equivalente al de documentos por comprobar, pero aquí el análisis se hace a detalle,
esto es, aquí es cada renglón del vale por comprobar, de hecho cuando se capturan los
gastos a comprobar, éstos se hacen por renglón, y son precisamente éstos los que aparecen
en la lista.
Comprobaciones
72
P
PR
RO
ON
NA
AD
D
Especificaciones técnicas del SIIA
Descripción del sistema computacional integral
Aquí se capturan las comprobaciones, es necesario capturarlas por el detalle de
comprobación, ver módulo de detalle por comprobar, las opciones de proveedor y factura
de proveedor son opcionales, la póliza sólo hace la reversa del detalle de comprobar, y
vuelve a cargar a la cuenta que se requiera, esto es: cargo negativo a 531 y nuevo cargo
a la cuenta que se seleccione, notar que sólo se pueden usar cuentas de egresos.
Subsistema de inventarios
Aquí está el registro de todos los activos fijos de la institución, esta tabla se va llenando
en cuanto se adquieren activos fijos, ya sea a través de compras o cuando se comprueban
las compras (vales) se pueden agregar directamente los bienes, el campo tipo nos indica
el tipo de activo que se está manejando, y el inventario es el número que se desee poner
como consecutivo, de todos modos internamente se maneja un consecutivo, campo
consecutivo, que mantiene el registro del bien.
Cuando se vuelve a asignar el bien a otra unidad responsable, sólo se cambia la
unidad responsable y se vuelve a reasignar el bien, el histórico se guarda en el detalle del
bien.
P
PR
RO
ON
NA
AD
D
P
PR
RO
ON
NA
AD
D
73
Programa para la Normalización de la Información Administrativa
Módulo de recursos humanos
Las funciones fueron agrupadas en cuatro subsistemas; el primero se refiere a todas
aquellas funciones exclusivas para el personal docente, en el siguiente se agrupan aquellas
funciones exclusivas para el personal administrativo y/o trabajadores, el tercer subsistema
incluye todos los procedimientos y funciones para la elaboración de la nómina y el último
abarca todas aquellas prestaciones de carácter general para quienes laboran dentro de la
institución. Cabe aclarar que este agrupamiento no es el único válido y que dependerá de
las características, funcionamiento y estructura orgánica de cada universidad.
Registro y control del personal administrativo
Movimientos de personal
A través de este proceso el usuario podrá dar altas, bajas y modificar la información de
los diferentes campos que integran la base de datos de personal administrativo conforme
a los procedimientos que establezca cada institución.
A continuación se describen algunos de los movimientos que permitirá registrar el
subsistema:
• Altas de personal administrativo (eventuales)
Consiste en otorgar una plaza eventual para efecto de una obra determinada durante
un periodo de tiempo determinado. Una vez autorizado este movimiento el trabajador
deberá ser dado de alta en la base de datos de la institución, así también el contrato de
trabajo asociado al mismo.
• Basificación
Se refiere a la integración definitiva de un trabajador a una plaza tabulada o de base.
• Bajas de personal eventual
Se refiere a la rescisión o terminación de la relación de trabajo del personal eventual.
En términos del sistema este movimiento tendría que ser automático, esto debido a que al
momento de su contratación queda establecido el periodo del contrato por lo que al arribar
a la fecha de terminación, el sistema automáticamente los excluye de la nómina.
• Bajas del personal administrativo de base
Se refiere a la posible rescisión o terminación de la relación de trabajo del personal de
base.
Aun cuando este tipo de movimiento no resulta muy común, en ocasiones se llega a
presentar. Estos movimientos habrán de generar pagos extraordinarios por concepto de
liquidación.
74
P
PR
RO
ON
NA
AD
D
Especificaciones técnicas del SIIA
Descripción del sistema computacional integral
• Prejubilación
Este tipo de movimientos sólo se presenta en aquellas instituciones en dónde dentro
del contrato colectivo de trabajo, se establecen condiciones para lograr esta prestación.
Los prejubilados son trabajadores que acumulan los años requeridos por dicha institución
para jubilarse, mas no la cantidad de años señalada por el ISSSTE. Por lo que a pesar de
alcanzar el estatus de prejubilados siguen trabajando, pero bajo otras condiciones salariales.
• Jubilación
Se refiere al movimiento que se genera cuando el trabajador alcanza este estatus.
• Recontrataciones
Para la realización de contrataciones bastará con volver a dar de alta a aquellos
trabajadores eventuales cuyo contrato hubiera concluido.
• Cambios de adscripción
Se refiere al proceso mediante el cual un trabajador cambia de lugar de adscripción al
que se encontrará asignado.
• Cambio de categoría y /o nivel
Se refiere al procedimiento mediante el cual un trabajador modifica su nivel y/o categoría.
Para este tipo de movimiento tendrá que quedar registrado quién autorizó y quién ingresó
el movimiento.
• Pago de riesgos
Este beneficio sólo se otorga en algunas instituciones y se refiere al pago que reciben
los trabajadores por los riesgos de laborar en unidades orgánicas con lugares insalubres
y laboratorios donde se manejen sustancias químicas tóxicas que pudieran atentar contra
la salud y el bienestar de los trabajadores.
• Primas especiales
Este tipo de beneficios lo otorgan algunas instituciones a aquellos trabajadores que
cumplen alguna condición de trabajo especial. Por ejemplo, la prima sabatina y dominical
que se ofrece en algunas instituciones para aquellos trabajadores que laboran los fines
de semana.
Seleccionando el registro del trabajador sobre el cual se necesite realizar un movimiento,
el sistema deberá presentar los datos del mismo permitiendo modificar los campos que se
requieran conforme al tipo de movimiento.
Este sistema deberá contemplar las siguientes facilidades:
1. Confirmación de movimientos
P
PR
RO
ON
NA
AD
D
75
Programa para la Normalización de la Información Administrativa
2. Mantener un control estricto sobre todos los movimientos que afecten la base de
datos. Cada uno de estos movimientos deberá ser registrado, almacenándose, entre
otros datos, el RFC, tipo de movimiento, estatus anterior y actual, fecha del movimiento,
persona que autorizó el cambio y el usuario que lo registró en el sistema.10
3. Para aquellos casos en que los valores a ser modificados estén restringidos a ciertos
valores, las modificaciones se deberán realizar a través de menues de tipo “combobox” que desplegarán los catálogos correspondientes.
4. Los movimientos de baja deberán reflejarse en una base de datos “histórica” en
donde queden registrados los datos de aquellos docentes dados de baja.
5. El sistema deberá garantizar que los movimientos de altas no generen registros
duplicados. De preferencia se deberá utilizar la CURP como llave de acceso a las
bases de datos de personas.
6. Para cada uno de los movimientos el sistema deberá garantizar la completez de los
datos requeridos para el mismo. Se sugiere que siempre quede registrado quién
realizó el movimiento y quién autorizó el mismo.
Es conveniente que este subsistema cuente con una herramienta de búsqueda /
selección de los empleados en donde el usuario pueda introducir criterios de selección a
través de los cuales se acote el universo de empleados. Los criterios podrán ser tan
estrechos como lo requiera el usuario, por ejemplo, podrá seleccionar todos aquellos
empleados cuyo RFC sea un valor determinado y obtener como resultado un solo registro,
o seleccionar todos aquellos empleados de apellido “Martínez” y que hubieran obtenido
su basificación antes del “5 de mayo de 1994”.
Control de asistencias
El sistema de recursos humanos deberá permitir registrar el número de faltas de cada
uno de los trabajadores administrativos.
Expedientes del personal
El sistema deberá registrar los documentos que ingresan al archivo de personal
administrativo, tales como acta de nacimiento, título, oficios, nombramientos, etc. Para
esto se recomienda la digitalización de los documentos.
Subsistema de personal docente
La funcionalidad y características de este subsistema deberá ser semejante al del
subsistema de personal administrativo, sólo que referente a los movimientos y datos del
personal docente. A continuación describimos algunas de las funciones y procesos a los
cuales deberá hacer referencia este subsistema:
10 El registro de los movimientos permitirá auditar todos aquellos movimientos realizados sobre la base de datos
76
P
PR
RO
ON
NA
AD
D
Especificaciones técnicas del SIIA
Descripción del sistema computacional integral
• Asignación de cargas de trabajo a docentes
Se refiere al proceso mediante el cual se determinan las cargas de trabajo de los
docentes de todas las unidades orgánicas de la institución. Para cada uno de los docentes
habrá que establecer cuántas horas de clase, investigación, laboratorio, asesoría, etc.,
les corresponden.
Este procedimiento deberá estar perfectamente vinculado con los módulos de control
escolar y asuntos financieros. Las horas de clase y/o laboratorio que se asignen en el
módulo de control escolar tendrán que corresponder con las que aquí se determinen. Así
también, las horas de clase que aquí se asignen no podrán exceder el techo financiero
presupuestado por función “docencia” y ejercicio histórico.
Las cargas de trabajo tendrán que ser validadas a través del sistema y en su caso
ajustadas por la unidad orgánica responsable.
• Basificación de docentes
Procedimiento mediante el cual un docente pasa a formar parte de la planta permanente
de profesores de una institución. Desde el punto de vista de este módulo la operación
resulta importante, ya que incidirá en la nómina y prestaciones que brinda cada institución.
• Cambio de adscripción de docentes
Se refiere al proceso mediante el cual un docente cambia de adscripción.11 Este
procedimiento se aplica sólo en aquellas instituciones en las cuales las basificaciones se
asignan por centro de trabajo.
Actualización de datos y del expediente de personal docente
El sistema deberá integrar los datos personales y curriculares para cada uno de los
docentes. Así también controlar qué documentos se encuentran físicamente en poder de
la universidad. Estos expedientes deberán actualizarse siendo lo más deseable que los
documentos entregados por el docente se encontraran digitalizados.
Entre otros datos se propone la inclusión de la siguiente información:
•
•
•
•
•
•
•
•
Nivel académico
Áreas de conocimiento
Estudios actuales
Congresos
Seminarios
Talleres
Simposios
Publicaciones
11 Cambio de unidad orgánica
P
PR
RO
ON
NA
AD
D
77
Programa para la Normalización de la Información Administrativa
• Proyectos e investigaciones
• Becas y estímulos
• Especialidad
Además de esta información se podrán consultar todos los datos laborales de los
docentes, tales como antigüedad, nivel, cargas laborales, fecha de jubilación, etcétera.
Entre otros, el sistema permitirá manipular y generar reportes como los siguientes:
• Docentes por categorías y áreas de conocimiento próximos a jubilarse.
• Docentes por categorías y áreas de conocimiento que estén en el sistema
nacional de investigadores.
• Docentes de la institución realizando estudios de posgrado con beca (con
descarga, por área del conocimiento).
• Docentes de la institución realizando estudios de posgrado con beca
complementaria de diversos programas (por área del conocimiento).
• Reporte de personal de carrera de tiempo completo con becas al desempeño
académico por centro, escuela o facultad.
• Cambio de grupo laboral, categoría y/o nivel para docentes.
Se refiere al proceso mediante el cual, una vez aprobado el movimiento por la instancia
correspondiente, se modifica el grupo laboral, categoría o nivel del docente. Cualquiera
de las anteriores modificaciones resultan de gran relevancia ya que se reflejarán en la
nómina. El sistema deberá registrar la fecha del movimiento, la vigencia, el responsable
de la autorización y el usuario que ingresa el cambio al sistema.
• Solicitud de año sabático
Ante la solicitud de año sabático por parte de un docente, la instancia que tenga las
atribuciones para autorizarlo podrá revisar, a través del sistema, que éste cumpla los
requisitos y en su caso ingresar el movimiento.
• Asignación de becas a docentes
En aquellos casos en que las instituciones cuenten con programas para el otorgamiento
de becas a sus docentes, una vez aprobadas por el área correspondiente, se tendrá que
ingresar el movimiento al sistema, señalando entre otros el monto, periodo, fondo de
donde proviene, etcétera.
• Proyectos de investigación
Este procedimiento se refiere a la asignación de un docente a algún proyecto de
investigación en que esté participando la institución.
• Otorgamiento de estímulos a docentes
En caso de que exista el otorgamiento de estímulos dentro de la institución, una vez
expedida la convocatoria y evaluados los docentes que hicieron el trámite, se ingresará
78
P
PR
RO
ON
NA
AD
D
Especificaciones técnicas del SIIA
Descripción del sistema computacional integral
en el sistema el monto y periodo de los estímulos para aquellos docentes que se hubieran
visto beneficiados.
En aquellas instituciones en donde además de personal administrativo (trabajadores) y
personal docente exista otra clasificación (por ejemplo empleados de confianza), se deberá
agregar un subsistema adicional, en donde se den los movimientos conforme a las
características propias de la categoría.
Subsistema de nóminas
Comprende la generación de la nómina, creación y actualización de los catálogos de
tabuladores, estímulos y descuentos, los procesos para el cálculo y aplicación de
descuentos al personal de la institución, los reintegros y los retroactivos.
Esta función constituye una de las más importantes de todo el SIIA. Baste pensar que
en muchas de las universidades el porcentaje más alto de recursos lo constituye el pago
de este rubro.
La generación de la nómina es un procedimiento ligado de manera muy especial con el
módulo financiero. Conforme a la contabilidad de fondos el sistema tendrá que dejar
perfectamente establecido el desglose por unidad responsable y fondo, así como corroborar
que no se exceda el presupuesto programado para cada una de éstas.
El sistema tendrá que descontar o pagar de manera automática las cuentas a favor o
en contra para cada uno de los empleados de la institución.
Generación de la nómina
Se refiere al proceso de generar las nóminas y prenóminas de los trabajadores, que
recibirán su pago. El usuario entrará a una pantalla, donde podrá teclear el periodo para la
nómina que se elaborará. Tendrá la opción de generar una nómina en forma general o por
unidad orgánica.
Datos de entrada
• Periodo de la nómina
• Selección de nómina o prenómina
Durante la quincena, las diferentes áreas o departamentos relacionados con la
generación de la nómina realizarán diferentes tipos de movimientos para las cuales se
utilizará el Catálogo de Percepciones y Deducciones. Para cada movimiento, se calculará
(por medio de un algoritmo) un monto, lo cual afectará el salario base del trabajador (este
salario será con base en la categoría nivel de los trabajadores, el cual existe en tablas ya
determinadas y calculadas por cada institución). Estos movimientos se registrarán a nivel
sistema en la base de datos de movimientos, el cual almacenará cada uno de los
movimientos que se realizaron para cada trabajador. Cuando se llegue a la quincena y
P
PR
RO
ON
NA
AD
D
79
Programa para la Normalización de la Información Administrativa
sea necesario elaborar la prenómina o nómina, a cada trabajador se le calculará su sueldo
final, una vez que se haya sumado (o restado, según sea el caso) el monto de cada uno
de los movimientos en los que participó a lo largo de la quincena. El Catálogo de
Percepciones y Deducciones se caracteriza porque se aplica de manera general a todos
los trabajadores.
Una vez que se tiene la prenómina completa, es decir todos los movimientos agrupados,
se generará la nómina. Inmediatamente al generarla, los datos almacenados en la base
de datos de movimientos se transferirán a una tabla histórica de movimientos, la cual
contendrá la información de todas las nóminas que ha generado la institución. En la tabla
de movimientos se borrará toda la información, por lo cual ya estará lista para que durante
la próxima quincena, se realicen los cambios y acciones necesarias para cada trabajador.
Una aclaración pertinente respecto a esto, es que la prenómina y nómina tendrán un
estatus (cerrado, abierto), lo cual para poder realizar los movimientos es necesario que
este “Abierta”, ya que a la quincena a la hora de generar la nómina, se cerrará la base de
datos, para no permitir ninguna modificación y generar la nómina correcta.
Deducciones a largo plazo
A partir de este programa el usuario podrá registrar deducciones, las cuales se aplicarán
a un trabajador a largo plazo.
Datos de entrada
Clave deducción
Tipo
Descripción
Fecha en que autorizó la deducción
Fecha inicio deducción
Fecha fin deducción
Monto total
Algoritmo (para realizar el cálculo determinado)
Número de quincenas
Saldo
estatus
Autorizó (aprobado por)
Fecha en que se dio la alta
80
P
PR
RO
ON
NA
AD
D
Especificaciones técnicas del SIIA
Descripción del sistema computacional integral
Usuario que dio la alta
Fecha de modificación del catálogo
Usuario que realizó la modificación
Asignación de deducciones
A través de esta pantalla, se tecleará la clave del docente, y se seleccionará la deducción
(a través de un combo box cerrado). Una vez confirmado el movimiento quedará registrado
en la base de datos. Así también la información relativa al movimiento.
Datos de entrada
•
• Clave o número del trabajador (docente y administrativo)
• Clave de la deducción
• Autorizó
• Fecha
• Usuario
Emisión de reportes
• El principal reporte que se debe generar en este subsistema es la prenómina, para
la revisión de los diferentes departamentos involucrados con esta actividad. Además
de la nómina, la cual permitirá efectuar los pagos correspondientes por parte de
tesorería, la información de la prenómina podrá ser consultada a través del sistema.
• Se necesitará un reporte de los principales catálogos (bonificaciones, descuentos,
retroactivos, reintegros).
•
Reporte de todos los trabajadores que cuentan con retroactivos, reintegros,
descuentos y bonificaciones.
Subsistema de prestaciones
En este subsistema se habrán de registrar los movimientos de todas las prestaciones
a las que tiene derecho todo el personal, como pueden ser préstamos en efectivo, en
especie, servicio médico, afiliaciones, jubilación, etcétera.
Catálogo de prestaciones generales12
A partir de este programa el usuario podrá realizar altas, bajas o modificaciones del
catálogo de prestaciones generales.
12 Estas prestaciones no requieren ningún tipo de solicitud para su disfrute. Por cuestiones prácticas se consideran como parte del
salario.
P
PR
RO
ON
NA
AD
D
81
Programa para la Normalización de la Información Administrativa
Datos de entrada
• Clave de prestación general
• Descripción de prestación general
• Monto (cantidad fija)
• Algoritmo correspondiente (para realizar el cálculo, cantidad no fija).
• Aplica (todos, docentes, administrativos)
• Autorizó
Catálogo de percepciones y deducciones
A partir de este programa el usuario podrá realizar actualizaciones al catálogo de
percepciones y deducciones.
Datos de entrada
Clave (de la percepción y deducción)
• Tipo
• Descripción
• Gravable
• Acumulado
• Algoritmo (que realice el cálculo)
• Autorizó (aprobado por)
• Fecha de alta de percepción y deducción
• Usuario que dio la alta
• Fecha de modificación del catálogo
• Usuario que realizó la modificación
Asignación de prestaciones
Se refiere al manejo y control de las prestaciones comunes para todos los empleados
de la universidad (docentes, administrativos y trabajadores) ya sea que se trate de
prestaciones en efectivo, especie o a través de vales.
Estas prestaciones se darán de alta a través de los catálogos correspondientes,
señalándose al hacerlo si se trata de una prestación individual o colectiva.
82
P
PR
RO
ON
NA
AD
D
Especificaciones técnicas del SIIA
Descripción del sistema computacional integral
Se refiere al proceso de asignar al trabajador las prestaciones que se merece. A través
de una pantalla, se tecleará la clave del docente y de la prestación, y al relacionarla (al
presionar el botón de Actualizar) quedará la asignación registrada en la base de datos del
sistema.
Datos de entrada:
• Clave o número del trabajador (docente y administrativo)
• Clave de la prestación
Reportes del subsistema de prestaciones
Reporte del catálogo general de prestaciones
Reporte de todos los trabajadores que están asignados a cualquier prestación.
Subsistema de consultas y reportes de personal
A través de este subsistema se habrán de generar las consultas y los reportes que
permitan tener un control sobre el personal de la institución. Entre otros los que a
continuación se describen:
Se requiere que el sistema muestre una pantalla de reportes, en donde se pueda
seleccionar el tipo de consulta o reporte que se desea. Con base en el tipo de reporte en
la pantalla aparecerá una serie de catálogos donde se elegirá la información para el reporte,
así como los agrupamientos y ordenamientos que se requieran. Al tiempo de que se
hagan las consultas, los departamentos que tengan acceso a realizar modificaciones en
el sistema podrán efectuar los cambios de algún registro en particular con sólo dar doble
click en el mismo. Para todo tipo de reporte deberá haber una opción o botón de impresión.
•
Reporte de movimientos de empleados, que han realizado algún cambio en sus
datos
El sistema generará un reporte que permita verificar todos los movimientos que se
hubieran realizado a la base de datos en un período determinado.
Módulo de control escolar
Admisiones
Registro de aspirantes
Se refiere al procedimiento por el cual se registra la información básica de los aspirantes
a ingresar a cada institución. En caso de que se requiera de un pago para realizar este
trámite el sistema deberá verificar que exista o se deberá presentar una ficha del banco o
la tesorería que avale el mismo.
P
PR
RO
ON
NA
AD
D
83
Programa para la Normalización de la Información Administrativa
Selección de aspirantes
Mediante este procedimiento se selecciona a los aspirantes que fueron aceptados.
Esto dependerá de la normatividad de cada una de las instituciones. Una vez seleccionados
estos alumnos el sistema habrá de ingresarlos a la base de datos de alumnos.
Inscripciones
Inscripciones a ciclo escolar
Se refiere al procedimiento mediante el cual los alumnos se inscriben para ingresar a
un nuevo ciclo escolar. Este procedimiento deberá ir acompañado con el o los pagos
correspondientes, ya sea a través de la tesorería o de una institución bancaria.
Inscripciones a materias/grupo
Procedimiento mediante el cual el alumno es registrado en la materia/salón/hora escogido
siempre y cuando haya cupo, el plan de estudios lo permita y haya realizado los pagos
correspondientes.
Revalidaciones
Aquí se dan de alta todos los alumnos que ingresan a la institución sin el proceso de
selección, y se integrarán entre otros, los siguientes datos: matrícula, nombre, escuela,
carrera, plan de estudios, semestre, periodo, grupo, turno y estatus (revalidación o
reconocimiento).
Control de grupos
Mediante este procedimiento se asigna una materia/grupo a un salón y a un profesor
determinado.
•
•
•
El encargado de Control Escolar de la escuela revisa la lista de salones/inmuebles
disponibles.
A cada salón se le asigna una materia/grupo, señalando el número de horas que se
ocuparán.
Cada materia/grupo, asignada previamente a un salón y a un horario, es destinada a
un profesor, relacionándola con la lista de profesores activos disponibles, ingresada
a través del módulo de recursos humanos.13
Acopio de calificaciones e impresión de actas
Proceso por el cual se recopilan las calificaciones entre los profesores universitarios al
final de cada ciclo escolar.
13 El sistema verificará que el salón asignado cuente con la capacidad necesaria para los alumnos a inscribir, además de que cuente
con las características necesarias de acuerdo con el tipo de curso a impartir.
84
P
PR
RO
ON
NA
AD
D
Especificaciones técnicas del SIIA
•
•
•
•
•
Descripción del sistema computacional integral
Se imprime la lista de cada materia impartida por el maestro. La impresión se realiza
en formatos para lectura óptica14 (acta de calificaciones).
El profesor registra las calificaciones en las actas rellenando los ovalitos
correspondientes. Firma la hoja y la regresa a la oficina de Control Escolar de la
escuela.
El Departamento de Servicios Escolares recibe las actas de calificaciones firmadas
y llenadas por los profesores.
Se capturan las actas en el sistema a través del lector óptico, se encuadernan y se
archivan.
En caso de que el acta no pueda ser leída correctamente, se regresa al profesor
para que la vuelva a llenar y a firmar.
Control de expedientes
Procedimiento mediante el cual se mantienen actualizados los expedientes de todos
los alumnos de cada institución. Este expediente estará conformado con toda la información
existente referente a los alumnos. El sistema registrará además de los datos del alumno,
la relación de documentos que entregó y que integran el expediente físico y una serie de
documentos digitalizados.
Entre los datos de los alumnos que deberá integrar el sistema se encuentran:
•
Escolares (escuela, carrera, grupo, generación, matrícula, nombre y CURP)
•
Generales, (estado civil, sexo, dirección, teléfono, estado, municipio, código postal,
fecha y lugar de nacimiento, estado y municipio de nacimiento, nacionalidad y
fotografía)
P
PR
RO
ON
NA
AD
D
85
Programa para la Normalización de la Información Administrativa
Kárdex o historia académica, aquí se encuentran las tiras de materias de los alumnos,
clasificados por semestre o ciclo según sea el caso, el sistema deberá mostrar, entre
otros aspectos, para cada una de las materias cursadas, el número de acta en la que
apareció su calificación, la calificación y fecha de cada una de las oportunidades de examen
(ordinario, extraordinario, a título de suficiencia, etcétera).
Documentos digitalizados
Estadísticas
Deberá realizarse un módulo en donde se realice la selección de datos (alumnos, recibos,
auditoría), se determine la relación que deban tener y se ejecute para obtener la estadística
detallada o total. El detalle es un listado con datos, asimismo permitirá almacenar las
estadísticas por si alguna de ellas se quisiera comparar en una gráfica.
86
P
PR
RO
ON
NA
AD
D
Especificaciones técnicas del SIIA
Descripción del sistema computacional integral
Para poder graficar estadísticas, éstas se debieron haber grabado con anterioridad, se
asignan las estadísticas que se encuentran almacenadas y que se quieran graficar y el
sistema la ejecuta inmediatamente poniendo en el espacio el resultado. Pueden hacerse
comparaciones hasta de 24 columnas, esto es, que se pueden crear 24 estadísticas
diferentes, grabarlas y compararlas en una gráfica. Una vez que se asignan todas las
estadísticas, se presiona el botón graficar y se obtiene el resultado, que puede mandarse
a impresión. La información queda soportada tanto con datos como gráficamente.
Expedición de constancias y certificaciones
Entre otros documentos los sistemas de control escolar deberán expedir los siguientes
documentos:
• Constancias que comprueben que es alumno de la institución, con calificaciones,
de servicio social, etc.
• Certificados (parciales y totales).
• Toma de protesta.
• Cartas de pasante.
• Kárdex (historial académico informal o certificado).
• Títulos.
Registro de planes de estudio
El Departamento de Servicios Escolares recopila la información relativa a la modificación
y la captura. La nueva versión del plan de estudios queda registrada en el sistema,
incluyéndose todos los requisitos o condiciones para cursar cada una de las materias.14
14 El sistema mantendrá el registro histórico de los planes de estudio.
P
PR
RO
ON
NA
AD
D
87
Programa para la Normalización de la Información Administrativa
Expedición de credencial
Es recomendable que los sistemas de control escolar contemplen la credencialización
como un componente de la solución integral. La fotografía correspondiente deberá
digitalizarse e integrarse a la base de datos de alumnos.
El módulo de control escolar guardará una estrecha relación con los módulos financiero
y de recursos humanos. La información de los docentes se obtendrá, partir de ligas con la
base de datos de recursos humanos. Todos los movimientos de control escolar que
requieran de la realización de un pago se tendrán que reflejar conforme a la cuenta, fondo
y función que se maneja en el módulo de financiero.
88
P
PR
RO
ON
NA
AD
D
Especificaciones técnicas del SIIA
Contabilidad matricial
IV. CONTABILIDAD MATRICIAL
Introducción
La contabilidad es un medio para brindar información en relación con las actividades
financieras realizadas por las instituciones públicas o privadas.
En la actualidad, los métodos contables brindan con mayor facilidad y flexibilidad
información financiera más completa y detallada.
Esta información financiera es valiosa porque permite evaluar acciones pasadas y ayuda
a preparar planes para el futuro por medio de los cuales se puedan alcanzar objetivos y
metas financieras.
La calidad de la información financiera ha sido fuertemente criticada por los directivos
que suelen tomar decisiones estratégicas. Lo anterior ha propiciado que se hayan propuesto
y ejecutado acciones específicas para mejorar la calidad de dicha información.
Objetivos
Generar el Subsistema de Información Financiera Contable al servicio de las necesidades
internas y externas de la administración con orientación pragmática, destinada a facilitar las
funciones administrativas internas de planeación y control, así como a la toma de decisiones.
Los objetivos de la contabilidad de una institución de educación tienen las mismas
características que para una empresa comercial:
a) Proveer información para la planeación y la elaboración del presupuesto, instrumentos
a través de los cuales se espera que el uso de los recursos disponibles sea más
eficiente.
b) Proporcionar información financiera para el control de las operaciones institucionales
a diferentes niveles.
c) Proporcionar información para la salvaguarda y control de los activos.
d) Proporcionar información para la asignación de los recursos.
e) Proporcionar información para la evaluación financiera de las operaciones.
f) Por otro lado, se espera que la información que se prepare cumple con los principios
de contabilidad generalmente aceptados.
Respecto a sus objetivos organizacionales, éstos presentan diferencia con las empresas
comerciales.
a) Las empresas comerciales tienen fines de lucro.
P R O N A D
89
Programa para la Normalización de la Información Administrativa
b) Las instituciones de educación pública persiguen fines de servicio, por lo que no tienen
incentivos de lucro, y requieren cada vez de manejar, de una manera más eficiente, el
financiamiento que reciben a través del subsidio, ya sea federal, estatal o municipal.
También se presentan marcadas diferencias en cuanto a la forma de operar de cada una
de ellas. Mientras que para la empresa comercial el efectivo es producto de venta de bienes
y servicios y son su principal fuente de recursos, y sus ganancias están determinadas por la
relación que guardan sus ingresos respecto a sus gastos, para una institución de educación
más del 80% de sus ingresos provienen del subsidio, y sus recursos son controlados de
acuerdo con las restricciones que se les ha impuesto para su utilización.
Diseñar un sistema de contabilidad es un arte.
El sistema puede esconder información o puede abrirla tanto como se desee.
Algunos sistemas de contabilidad pueden hacer ambas cosas.
La mayoría de los sistemas de contabilidad para universidades están diseñados de
acuerdo con los principios de contabilidad generalmente aceptados.
Sin embargo, en contabilidad, como en muchas disciplinas, hay desacuerdos en la
manera de presentar situaciones especiales. En tales situaciones la metodología contable
difiere de un campus a otro.
El diseño de un sistema contable se puede determinar, en parte, por la naturaleza de la
institución, así como de su historia.
Un sistema de contabilidad no necesariamente refleja todas las operaciones financieras
que pueden influir en el estado financiero de la institución.
Frecuentemente estas transacciones se describen en notas a los estados financieros.
Pueden incluir partidas tales como una adición significativa en la planta.
Partidas que no aparecen en los estados financieros pueden incluir un plan de legados
a alumnos que serán efectivos en un futuro, o una donación de libros raros u objetos de arte.
Estos últimos incrementan el valor de los activos de la institución pero no estarán incluidos
en los estados financieros.
Esto nos lleva a pensar que el sistema de contabilidad de la institución puede no
proporcionar una realidad completa de la situación financiera.
Las organizaciones no lucrativas como grupo difieren de las empresas en cuanto a que
aquéllas son receptoras del subsidio, donativos, contribuciones y apropiaciones, que
están restringidas para su uso, ya que su utilización está asociada a propósitos, funciones y
actividades en particular.
Un donante, por ejemplo, puede especificar que su aportación sea utilizada exclusivamente
para becas.
P R O N A D
90
Especificaciones técnicas del SIIA
Contabilidad matricial
Bajo este sentido, la institución no tiene ninguna otra autoridad para disponer del recurso
que no sea para el fin que fue dado.
Dada esta característica en particular, que distingue la contabilidad que debe seguir una
institución educativa, es que surge la llamada contabilidad universitaria o contabilidad matricial.
Estructura del código
Es la forma como se asociarán y relacionarán cada uno de los catálogos que servirán de
base para la codificación de una operación financiera. Para estructurar el código, es
necesario haber diseñado ya los catálogos. El código a utilizar debe tener los siguientes
datos:
I. Datos organizacionales:
Fondo
Función
Programa
Unidad responsable
II. Clasificación genérica de las cuentas:
Cuenta de mayor
Objeto del gasto
En esta parte se consideran las cuentas que forman el activo, el pasivo, el patrimonio y
dentro del patrimonio lo relativo a sus adiciones y/o disminuciones, es decir, ingresos y
gastos.
El número de dígitos que se estimen para cada componente, dependerá de las
necesidades de información de cada institución. Por otro lado, no es necesario seguir el
orden presentado, ya que cada institución lo puede adaptar a su sistema actual. Lo importante
es el nivel de agrupamiento y lo que cada posición signifique. La única condicionante es que
el código inicie con el fondo.
Fondo
Es una entidad contable que tiene un grupo de cuentas autobalanceables, es decir, que
tiene sus propias cuentas de activo, pasivo y patrimonio, además de las cuentas de resultados,
ingresos y gastos.
Se establecen fondos separados para contabilizar las actividades financieras relacionadas
con subsidios que tengan restricciones particulares para su uso, fuentes de recursos
restringidos, o importes designados que han sido establecidos por la junta de gobierno de la
institución. Esas entidades contables se establecen para asegurarse de que los recursos
serán utilizados de acuerdo con las restricciones impuestas, en este caso, por el otorgante
P R O N A D
91
Programa para la Normalización de la Información Administrativa
del recurso o bien por la junta de gobierno. Los fondos utilizados en contabilidad matricial
son:
1. De operación
2. De reservas
3. Activos fijos
4. Otros fondos
Función
Agrupación, clasificación y registro de los gastos asociados al cumplimiento de la misión
institucional. De acuerdo con el modelo matricial son:
- Docencia
- Investigación y desarrollo
- Servicio a la comunidad
- Apoyo académico
- Apoyo institucional
- Operación y mantenimiento de la planta física
- Entidades auxiliares
Unidad orgánica
Es un organismo académico, académico-administrativo o administrativo de una institución
educativa, que tiene a su cargo una o varias de las funciones que realiza la institución, o bien
en las que participa.
Cuenta
Identifica al conjunto homogéneo y ordenado de bienes y servicios, el cual, de acuerdo
con el catálogo por objeto del gasto, se requiere para el logro de las metas establecidas.
Ventajas del uso de la contabilidad matricial
• Comparabilidad con instituciones similares.
• Posibilidad de llegar a sistemas de costeo unitario homogéneos.
• Posibilidad de establecer claramente centros de costos y centros de utilidades.
P R O N A D
92
Especificaciones técnicas del SIIA
Contabilidad matricial
• Compatibilidad entre el presupuesto y el desempeño real, lo cual permite generar
información de avance presupuestal por unidad orgánica.
Los retos
El gran reto para la universidad es, sin lugar a dudas, eficientar sus procesos
administrativos para a su vez eficientar la operación de la universidad. Para lo cual, entre
otras cosas, es necesario contar con información acerca del desempeño financiero de
instituciones similares. Contribuir a la homologación y estandarización del sistema de
información financiera de las universidades, indudablemente proporcionará un mejor uso
de los recursos y una participación mas útil en el esfuerzo de la educación superior en el
país.
P R O N A D
93
Programa para la Normalización de la Información Administrativa
P
P R
R O
O N
N A
A D
D
94
Especificaciones técnicas del SIIA
La clave única de registro poblacional (CURP)
V. LA CLAVE ÚNICA DE REGISTRO POBLACIONAL (CURP)1
Para el diseño de la base de datos, se propone que la CURP sea la llave para las entidades
que se refieran a personas. Lo anterior en función de que existe una disposición a unificar
todos los registros de personas a través de esta clave.
¿Qué es la CURP?
La Clave Única de Registro de Población es un instrumento de registro e identificación
que se asigna a todas las personas que viven en el territorio nacional, así como a los
mexicanos que residen en el extranjero. El Registro Nacional de Población (RENAPO) es la
instancia responsable de asignar la CURP y de expedir la constancia respectiva.
¿Cómo se integra la CURP?
La CURP se integra con dieciocho elementos, representados por letras y números, que
se generan a partir de los datos contenidos en el documento probatorio de identidad (acta
de nacimiento, carta de naturalización o documento migratorio), y que se refieren a:
•
•
•
•
El primero y segundo apellidos, así como el nombre de pila
La fecha de nacimiento
El sexo
La entidad federativa de nacimiento
Los dos últimos elementos de la CURP evitan la duplicidad de la clave y garantizan su
correcta integración.
¿Qué datos contiene la CURP?
Un ejemplo de esto sería el siguiente: tenemos a una persona con nombre Ricardo Alamán
Pérez, que nació en el Distrito Federal, el 21 de marzo de 1963, su CURP sería AAPR
630321 H DF LRC 09
• Las primeras cuatro letras, AAPR, se refieren a la inicial y primera vocal interna del
primer apellido; inicial del segundo apellido e inicial del nombre de pila.
• Los siguientes seis dígitos 630321, se refieren a la fecha de nacimiento: año, mes y
día.
• La siguiente letra H, se refiere al sexo: (H) para hombre y (M) para mujer.
• Las siguientes letras, DF, se refieren a la entidad federativa de nacimiento.
• Las siguientes letras, LRC, se refieren a las primeras consonantes internas del primer
apellido, segundo apellido y del nombre de pila.
• Y los últimas dos dígitos 09, se refieren a la homoclave, que es el elemento para evitar
registros duplicados.
1 Fuente: Boletín de la Dirección General del Registro Nacional de Población e Identificación Personal
P
P R
R O
O N
N A
A D
D
95
Programa para la Normalización de la Información Administrativa
¿Qué datos se incorporan en la asignación de la CURP?
•
•
•
•
•
La clave única de registro de población
Nombre completo
La fecha de inscripción a este sistema
El número de folio de la constancia.
Información que identifica los datos del documento probatorio (acta de nacimiento,
carta de naturalización o documento migratorio).
¿Para qué sirve la CURP?
La clave identificará individualmente a las personas en los registros a cargo de las
instituciones públicas.
La CURP se incorporará paulatinamente a todos los documentos oficiales, como se
describe a continuación como ejemplo, a fin de fortalecer las condiciones de seguridad
jurídica de la población; mejorar los vínculos entre ésta y las instancias de gobierno, para
facilitar la prestación de los bienes y servicios, y simplificar la administración pública al eliminar
la diversidad de claves de registro de personas, entre otros.
En materia de
Tipo de documento
• Registro civil
• Salud
Acta de nacimiento, matrimonio, adopción, etcétera.
Cartilla de vacunación, expediente médico, identificación,
etcétera.
Registro escolar, constancia y certificado de estudios,
identificación, etcétera.
• Educación
• Prestación de
servicios (trabajo)
• Seguridad social
• Desarrollo social
Solicitud de empleo, registro individual, expediente, nómina,
recibo de pago, identificación, etcétera.
Cuenta individual del sistema de ahorro para el retiro,
expediente, identificación
Registro individual, identificación, etc., así como en el
pasaporte, cartilla del servicio militar, licencia para
conducir, etcétera.
¿Con base en qué se asigna y se expide la CURP ?
En nuestro país la Ley General de Población otorga a la Secretaría de Gobernación la
atribución para registrar y acreditar la identidad de todas las personas residentes en el país
y de los nacionales que residan en el extranjero, a través del Registro Nacional de Población.
La propia ley establece al incorporar a una persona en dicho registro, que se le asignará
una clave única de registro de población, para registrarla e identificarla de manera individual.
P
P R
R O
O N
N A
A D
D
96
Especificaciones técnicas del SIIA
La clave única de registro poblacional (CURP)
El 23 de octubre de 1999, se publicó en el Diario Oficial de la Federación el Acuerdo
Presidencial para la Adopción y Uso por la Administración Pública Federal de la Clave
Única de Registro de Población.
El acuerdo establece que la CURP se asignará a todas las personas que viven en el
territorio nacional, así como a los mexicanos residentes en el extranjero.
Por otra parte, señala que las instituciones públicas que lleven o en lo futuro hayan de
integrar algún registro de personas, deben adoptar el uso de la CURP.
Asimismo, el acuerdo dicta que una vez asignada la CURP por el RENAPO, éste expedirá
una constancia por escrito, que su titular deberá presentar para su incorporación en cualquier
registro de personas.
P
P R
R O
O N
N A
A D
D
97
Programa para la Normalización de la Información Administrativa
P R O N A D
98
Especificaciones técnicas del SIIA
Consideraciones generales sobre la ingeniería de software
VI. CONSIDERACIONES GENERALES SOBRE LA INGENIERÍA
DE SOFTWARE
La ingeniería de software es una disciplina que integra proceso, método y herramientas
para el desarrollo del software de computadoras. Sobre ésta, se está llevando a cabo una
fuerte discusión teórica por la evidente debilidad de las bases que le dan fundamento.
Esta discusión se centra en dos aspectos fundamentales, el primero que tiene que ver
con una epistemología basada en el principio de autoridad, ya que la mayoría de los tratados
de ingeniería de software están basados en una combinación de experiencia anecdótica y
autoridad humana, raramente se acompañan de evidencia lógica o experimental. Esto
provoca la carencia de una base sólida que le dé un carácter científico a la ingeniería de
software.
El segundo tiene que ver con un principio práctico aplicado de manera generalizada en la
ingeniería de software y es el famoso precepto de divide y vencerás, es decir, se ha venido
aplicando dogmáticamente este principio, separando las actividades propias del análisis
de las actividades de diseño.
Por otra parte se presupone que una vez establecido el algoritmo, que se obtiene de la
división del proceso de desarrollo de software en diversas etapas, se asume que es factible
desarrollarlo sin considerar la posibilidad de llevar a cabo la construcción de un algoritmo
que implique un costo injustificado e irrealizable en la práctica.
Es claro entonces que hay una falta de comprensión de la relación que existe entre las
actividades de diseño y las de análisis. Dado lo anterior se puede entonces establecer
que durante la etapa de análisis se constituye el problema, pues no se obtiene un problema,
sólo hechos, y justamente este paso de constitución del problema está necesariamente
referido a su solución, es decir, a la etapa del diseño.
Sobre la ingeniería de software, se está llevando a cabo una fuerte discusión teórica por
la evidente debilidad de las bases que le dan fundamento (ver anexo correspondiente).
En este orden de ideas, la estrategia y metodología que se utilice para la construcción de
un sistema de información no puede ser tajante ni rígida. A continuación describimos de
forma muy general algunos modelos y metodología para la construcción de un sistema. Cada
paradigma exhibe ventajas y desventajas, sin embargo, mantiene una serie de fases
genéricas en común.
Modelos de ingeniería de software
El modelo lineal secuencial
Llamado algunas veces “ciclo de vida básico” o “modelo en cascada”, el modelo lineal
secuencial es un enfoque sistemático, secuencial del desarrollo del software que comienza
en un nivel de sistemas y progresa con el análisis, diseño, codificación, pruebas y
P R O N A D
99
Programa para la Normalización de la Información Administrativa
mantenimiento. Modelo según el ciclo de ingeniería convencional, el modelo lineal secuencial
acompaña a las actividades siguientes:
Ingeniería y modelado de sistemas/información. Como software siempre forma parte de
un sistema más grande (o empresa), el trabajo comienza estableciendo requisitos de todos
los elementos del sistema y asignando al software algún subgrupo de estos requisitos. Esta
visión del sistema es esencial cuando el software se debe interconectar con otros elementos
como hardware, personas y bases de datos. La ingeniería y el análisis de sistemas acompaña
a los requisitos que se recogen en el nivel del sistema con una pequeña parte de análisis y
de diseño. La ingeniería de información acompaña a los requisitos que se recogen en el
nivel estratégico de empresa y en el nivel de área de negocio.
Análisis de los requisitos del software. El proceso de reunión de requisitos se intensifica
y se centra especialmente en el software. Para comprender la naturaleza de lo (s) programa(s)
(s) a construirse, el ingeniero (“analista”) del software debe comprender el dominio de
información del software (descrito en el capítulo 11), así como la función requerida,
comportamiento e interconexión. El usuario documenta y repasa los requisitos del sistema y
de software.
Diseño. El diseño del software es realmente un proceso de muchos pasos que se centra
en cuatro atributos distintos de un programa: estructura de datos, representaciones de interfaz
y detalle procedimental (algoritmo). El proceso de diseño traduce requisitos en una
representación del software que se pueda evaluar por calidad antes de que comience la
generación del código. Al igual que los requisitos, el diseño se documenta y se hace parte
de la configuración del software.
Generación de código. El diseño se debe traducir en forma legible por la máquina. El
paso de generación de código lleva a cabo esta tarea. Si se lleva a cabo el diseño de una
forma detallada, la generación de código se realiza mecánicamente.
Pruebas. Una vez que se ha generado un código, comienzan las pruebas del programa.
El proceso de pruebas se centra en los procesos lógicos internos del software, asegurando
que todas las sentencias se han comprobado, en los procesos externos funcionales, es
decir, que la realización de las pruebas para la detección de errores y sentirse seguro de la
entrada definida produzca resultados reales de acuerdo con los resultados requeridos.
Mantenimiento. El software individualmente sufrirá cambios después de ser entregado al
cliente (una excepción posible es el software empotrado). Se producirán cambios porque se
han encontrado errores, porque el software debe adaptarse para acoplarse a los cambios
de su entorno externo ( p. ej.: se requiere un cambio debido a un sistema operativo o dispositivo
periférico nuevo), o porque el cliente requiere mejoras funcionales o de rendimiento. El
mantenimiento vuelve a aplicar cada una de las fases precedentes a un programa ya existente
y no a uno nuevo.
El modelo lineal secuencial es el paradigma más antiguo y más extensamente utilizado
en la ingeniería del software. Sin embargo, la crítica del paradigma ha puesto en duda su
P
P R
R O
O N
N A
A D
D
100
Especificaciones técnicas del SIIA
Consideraciones generales sobre la ingeniería de software
eficacia. Entre los problemas que se encuentran algunas veces en el modelo lineal secuencial
se incluyen:
1. Los proyectos reales raras veces siguen el modelo secuencial que propone el modelo.
Aunque el modelo lineal puede acoplar interacción, lo hace indirectamente. Como
resultado, los cambios pueden causar confusión cuando el equipo del proyecto
comienza.
2. A menudo es difícil que el usuario exponga explícitamente todos los requisitos. El modelo
lineal secuencial lo requiere y tiene dificultades a la hora de acomodar la incertidumbre
natural al comienzo de muchos proyectos.
3. El usuario debe tener paciencia. Una versión de trabajo del (los) programa(s) no estará
disponible hasta que el proyecto esté muy avanzado. Un grave error puede ser
desastroso si no se detecta hasta que se revisa el programa.
4. Los responsables del desarrollo del software siempre se retrasan innecesariamente.
En un interesante análisis de proyectos reales, Bradac dijo que la naturaleza lineal de
ciclo de vida clásico lleva a “estados de bloqueo” en el que algunos miembros del
equipo del proyecto deben esperar a otros miembros del mismo para completar tareas
dependientes. En efecto, el tiempo que se pasa esperando puede sobrepasar el tiempo
que se emplea en el trabajo productivo. Los estados de bloqueo tienden a ser más
importantes al principio y al final de un proceso lineal secuencial.
Cada uno de estos errores es real. Sin embargo, el paradigma del ciclo de vida clásico
tiene un lugar definido e importante en el trabajo de la ingeniería de software. Proporciona
una plantilla en la que se encuentran métodos para análisis, diseño, codificación, pruebas
y mantenimiento. El ciclo de vida clásico sigue siendo el modelo de proceso más
extensamente utilizado por la ingeniería del software. Pese a tener debilidades, es
significativamente mejor que un enfoque hecho al azar el desarrollo del software.
El modelo de construcción de prototipo
Un cliente a menudo define un conjunto de objetivos generales para el software, pero no
identifica los requisitos detallados de entrada, procesamiento o salida. En otros casos, el
responsable del desarrollo del software puede no estar seguro de la eficacia de un algoritmo,
de la capacidad de adaptación de sistema operativo, o de la forma en que debería tomarse
la interacción hombre-máquina. En éstas y en muchas otras situaciones, un paradigma de
construcción de prototipos puede ofrecer el mejor enfoque.
El paradigma de construcción de prototipos comienza con la recolección de requisitos. El
desarrollador y el usuario encuentran y definen los objetivos globales para el software,
identifican los requisitos conocidos, y las áreas del esquema en donde es obligatoria más
definición. Entonces aparece un “diseño rápido”. El diseño rápido se centra en una
representación de esos aspectos del software que serán visibles para el cliente. (p. ej.:
enfoques de entrada y formatos de salida). El diseño rápido lleva la construcción de un
P R O N A D
101
Programa para la Normalización de la Información Administrativa
prototipo. El prototipo lo evalúa el usuario y lo utiliza para refinar los requisitos de software a
desarrollar. La interacción ocurre cuando el prototipo satisface las necesidades del usuario,
a la vez que permite que el desarrollador comprenda mejor lo que se necesita hacer.
Lo ideal sería que el prototipo sirviera como un mecanismo para identificar los requisitos
del software. Si se construye un prototipo de trabajo, el desarrollador intenta hacer uso de
los fragmentos del programa ya existentes o aplica herramientas (p.ej.: generadores de
informes, gestores de ventanas, etc.) que permiten generar rápidamente programas de trabajo.
En la mayoría de los proyectos, el primer sistema construido apenas se puede utilizar.
Puede ser demasiado lento, grande o torpe en su uso, o las tres a la vez. No hay alternativa
sino comenzar de nuevo y construir una versión rediseñada en la que se resuelvan estos
problemas. Cuando se utiliza un concepto nuevo de sistema o de una tecnología nueva, se
tiene que construir un sistema que no sirva y se tenga que tirar, incluso la mejor planificación
no es omnisciente como para que esté perfecta la primera vez. Por tanto, la pregunta sobre
la gestión no es si construir un sistema piloto y tirarlo. La única pregunta es si planificar de
antemano construir un desechable, o prometer entregárselo a los usuarios.
La construcción de prototipos también puede ser problemática por las razones siguientes:
1. El usuario ve lo que parece ser una versión de trabajo del software, sin tener
conocimiento de que el prototipo también está junto con “el chicle y el cable de embalar”,
sin saber que con la prisa de hacer que funcione no se ha tenido en cuenta la calidad
del software global o la facilidad de mantenimiento a largo plazo. Cuando se informa
que el producto se debe construir otra vez para que se puedan mantener los niveles
altos de calidad, el usuario no lo entiende y pide que se apliquen “unos pequeños ajustes”
para que se pueda hacer del prototipo un producto final. De forma demasiado frecuente
la gestión de desarrollo del software es muy lenta.
2. El desarrollador a menudo hace compromisos de implementación para hacer que el
prototipo funcione rápidamente. Se puede utilizar un sistema operativo o lenguaje de
programación inadecuado simplemente porque está disponible y porque es conocido;
un algoritmo eficiente se puede implementar simplemente para demostrar la capacidad.
Después de algún tiempo, el desarrollo debe familiarizarse con estas selecciones, y
olvidarse de las razones por las que son inadecuadas. La selección menos ideal ahora
es una parte integral del sistema.
Aunque pueden surgir problemas, la construcción de prototipos puede ser un paradigma
efectivo para la ingeniería del software. La clave es definir las reglas del juego al comienzo;
el usuario y el desarrollador deben ponerse de acuerdo en que el prototipo se construya para
servir como un mecanismo de definición de requisitos. Entonces se descarta (al menos en
partes) y se realiza la ingeniería del software con una visión hacia la calidad y facilidad de
mantenimiento.
P
P R
R O
O N
N A
A D
D
102
Especificaciones técnicas del SIIA
Consideraciones generales sobre la ingeniería de software
El modelo DRA
El Desarrollo Rápido de Aplicaciones (DRA) (Rapid Application Development, RDA) es
un modelo de proceso del desarrollo del software lineal secuencial que enfatiza un ciclo de
desarrollo extremadamente corto. El modelo DRA es una adaptación a “alta velocidad” del
modelo lineal secuencial en el que se logra el desarrollo rápido, utilizando un enfoque de
construcción basado en componentes. Si se comprenden bien los requisitos y se limita el
ámbito del proyecto, el proceso DRA permite al equipo de desarrollo crear un “sistema
completamente funcional” dentro de los periodos cortos de tiempo (p. ej.: de 60 a 90 días).
Cuando se utilizan principalmente para aplicaciones de sistemas de información, el enfoque
DRA comprende las siguientes fases.
Modelado de gestión. El flujo de información entre las funciones de gestión se modela de
forma que responda a las siguientes preguntas: ¿Qué información conduce al proceso de
gestión? ¿Qué información se genera? ¿Quién la genera? ¿Adónde va la información? ¿Quién
la procesa?
Modelado de datos. El flujo de información definido como la parte de la fase de modelado
de gestión se refina como un conjunto de objetos de datos necesarios para apoyar la empresa.
Se definen las características (llamadas atributos) de cada uno de los objetos y las relaciones
entre estos objetos.
Modelado de proceso. Los objetos de datos definidos en la fase de modelado de datos
quedan transformados para lograr el flujo de información necesario para implementar una
función de gestión . Las descripciones del proceso se crean para añadir, modificar, suprimir.
o recuperar un objeto de datos.
Generación de aplicaciones. EL DRA asume la utilización de técnicas de cuarta
generación. En la creación de software con lenguajes de programación de tercera generación,
el proceso DRA trabaja para volver a utilizar componentes de programas ya existentes
(cuando es posible ) o a crear componentes reutilizables (cuando sea necesario). En todos
los casos se utilizan herramientas automáticas para facilitar la construcción del software.
Pruebas y entrega. Como el proceso DRA enfatiza la reutilización, ya se han comprobado
muchos de los componentes de los programas. Esto reduce tiempo de pruebas, sin embargo,
se deben probar todos los componentes nuevos y ejercitar todas las interfaces a fondo.
El modelo de proceso de DRA se ilustra en la figura 2.6. Obviamente, las limitaciones de
tiempo impuestas en un proyecto DRA demandan “ámbito en escalas”. Si una aplicación de
gestión puede modularse de forma que permita completarse cada una de las funciones
principales en menos de tres meses (utilizando el enfoque descrito anteriormente), es un
candidato del DRA. Cada una de las funciones pueden ser afrontadas por un equipo del
DRA diferente y ser integradas en un solo conjunto.
Al igual que todos los modelos de proceso, el enfoque DRA tiene inconvenientes:
• Para proyectos grandes aunque por escalas, el DRA requiere recursos humanos
suficientes como para crear el número correcto de equipos DRA.
P R O N A D
103
Programa para la Normalización de la Información Administrativa
• DRA requiere clientes y desarrolladores comprometidos en las rápidas actividades
necesarias para completar un sistema en un marco de tiempo abreviado. Si no hay
compromiso, por ninguna de las partes constituyentes, los proyectos DRA fracasarán.
• No todas las aplicaciones son apropiadas para el DRA. Si un sistema no se puede
modularizar adecuadamente, la construcción de los componentes necesarios para
DRA será problemática. Si está en juego el alto rendimiento, y se va a conseguir el
rendimiento convirtiendo interfaces en componentes de sistemas, puede suceder que
el enfoque DRA no funcione. DRA no es adecuado cuando los riesgos técnicos son
altos. Esto ocurre cuando una nueva aplicación hace uso de las tecnologías nuevas, o
cuando el nuevo software requiere un alto grado de interoperatividad con programas
de computadoras ya existentes.
Técnicas de cuarta generación
El término “técnicas de cuarta generación” (T4G) abarca un amplio espectro de
herramientas de software y la especificación de algunas características del software de alto
nivel. Luego, la herramienta genera automáticamente el código fuente basándose en la
especificación del técnico. Cada vez parece más evidente que cuanto mayor sea el nivel en
el que se especifique el software, más rápido se podrá construir el programa. El paradigma
T4G para la ingeniería del software se orienta hacia la posibilidad de especificar éste usando
formas de lenguaje especializado o notaciones gráficas que describan el problema que se
debe resolver en términos entendibles para el cliente. Actualmente, un entorno para el
desarrollo de software que soporte el paradigma T4G puede incluir todas o algunas de las
siguientes herramientas: lenguajes no procedimentales de consulta a base de datos,
generación de códigos, capacidades gráficas de alto nivel y capacidades de hoja de cálculo.
Inicialmente, muchas de estas herramientas están disponibles, pero sólo para ámbitos de
aplicación muy específicos, aunque actualmente los entornos T4G se han extendido a todas
la categorías de aplicaciones del software.
Al igual que otros paradigmas, T4G comienza con el paso de reunión de requisitos.
Idealmente, el cliente describe los requisitos que son continuación, traducidos directamente
a un prototipo operativo. Sin embargo, en la práctica no se puede hacer eso. El cliente
puede no estar seguro de lo que necesita; ser ambiguo en la especificación de hechos que
le son conocidos, y no ser capaz o no estar dispuesto a especificar la información en la
forma en que se puede utilizar una herramienta T4. Por esta razón, el diálogo usuariodesarrollador, descrito por los otros paradigmas, sigue siendo una parte esencial del enfoque
T4G.
Para aplicaciones pequeñas, se puede ir directamente desde el paso de recolección de
requisitos al paso de implementación, usando un lenguaje de cuarta generación no
procedimental ( L4G). Sin embargo, es necesario un mayor esfuerzo para desarrollar una
estrategia de diseño (para grandes proyectos); causará las mismas dificultades (poca calidad,
mantenimiento pobre, mala aceptación por el cliente) que se encuentran cuando se desarrolla
software mediante los enfoques convencionales.
P
P R
R O
O N
N A
A D
D
104
Especificaciones técnicas del SIIA
Consideraciones generales sobre la ingeniería de software
La implementación mediante L4G permite, al que desarrolla el software, centrarse en la
representación de los resultados deseados, lo que se traduce automáticamente en un código
fuente que produce dichos resultados.
Obviamente, debe existir una estructura de datos con información relevante y a la que el
L4G pueda acceder rápidamente.
Para transformar una implementación T4G en un producto, el que lo desarrolla debe
apoyarse en la documentación apropiada y ejecutar el resto de actividades de “integración
“requeridas en los otros paradigmas de ingeniería del software. Además el software
desarrollado con T4G debe ser construido de modo que facilite la realización del
mantenimiento de forma expeditiva.
Al igual que todos los paradigmas del software, el modelo T4G tiene ventajas e
inconvenientes. Los defensores aducen reducciones drásticas en el tiempo de desarrollo
del software y una mejora significativa en la productividad de la gente que construye el mismo.
Los detractores aducen que las herramientas actuales de T4G no son más fáciles de utilizar
que los lenguajes de programación, que el código fuente producido por tales herramientas
es “ineficiente” y que el mantenimiento de grandes sistemas de software desarrollados
mediante T4G, es cuestionable.
1. El uso de T4G ha crecido considerablemente en la última década y ahora es un enfoque
viable para muchas de las diferentes áreas de aplicación. Junto con las herramientas
de ingeniería de software asistida por computadora (Computer-Aided Software
Engineering, CASE) los generadores de código T4G ofrecen una solución fiable a
muchos problemas de software.
2. Los datos recogidos en compañías que usan T4G parecen indicar que el tiempo
requerido para producir software se reduce mucho para aplicaciones pequeñas y
tamaño medio, y que la cantidad de análisis y diseño para las aplicaciones pequeñas,
también se reduce.
3. Sin embargo, el uso de T4G para grandes trabajos de desarrollo de software existe el
mismo o más tiempo de análisis, diseño y prueba (actividades de ingeniería del
software), perdiéndose así un tiempo sustancial que se ahorra mediante la eliminación
de la codificación.
Resumiendo, las técnicas de cuarta generación ya se han convertido en una parte
importante del desarrollo del software. Cuando se combinan con enfoques de ensamblaje
de componentes, el paradigma T4G se puede convertir en el enfoque dominante hacia el
desarrollo del software.
Breves comentarios a cerca del diseño de sistemas
La evolución del diseño del software es un proceso imparable que se ha expandido durante
las tres primeras décadas. Antiguamente el diseño se centraba en los criterios de desarrollo
de programas modulares y métodos para refinar la arquitectura software de una manera
descendente en la jerarquía. Los aspectos procedimentales de la definición del diseño del
P R O N A D
105
Programa para la Normalización de la Información Administrativa
modelo evolucionaron hacia una filosofía denominada programación estructurada. Algunos
trabajos posteriores proponían métodos para la transformación de flujo de datos o de la
estructura de datos en una definición del diseño. Enfoques recientes del diseño proponen,
por ejemplo, un enfoque orientado a objeto para obtención del diseño.
Muchos métodos de diseño que han surgido de los trabajos mencionados anteriormente
se aplican en la industria. Al igual que los métodos de análisis, todos los métodos de diseño
de software presentan unas heurísticas y notaciones únicas. Así como una visión algo particular
de cómo lograr la calidad del diseño. Sin embargo, todos estos métodos tienen unas
características comunes: (1) un mecanismo para la transformación de un modelo de análisis
en una representación del diseño, (2) una notación para representar componentes funcionales
y sus interfaces, (3) heurísticas para el refinamiento y la participación y (4) consejos para
mejorar la calidad .
Independientemente del método del diseño que se emplee, un ingeniero de software
debería aplicar un conjunto de principios fundamentales y conceptos básicos al diseño de
datos, arquitectónico, de interfaz y procedimental. Estos principios y conceptos se consideran
en las siguientes secciones.
El diseño del software es un proceso y un modelo a la vez. El proceso de diseño es un
conjunto de pasos repetitivos que permiten al diseñador describir todos los aspectos del
software a construir. Hay que aclarar, sin embargo, que el proceso del diseño no es un
simple “libro de cocina”. La capacidad creativa, la experiencia acumulada, el sentido del
“buen” software y un empeño global en la calidad, son factores críticos del éxito del diseño.
El modelo del diseño es el equivalente a los planos de una casa para un arquitecto. Empieza
representando la totalidad de lo que se va construir (p.ej.: una representación tridimensional
de la casa) y lentamente lo va refinando para proporcionar una directriz y construir cada
detalle (p.ej.: el plano de las cañerías ). Similarmente, el modelo de diseño creado para el
software proporciona varias visiones diferentes del programa de computadora.
Los principios básicos del diseño permiten al ingeniero del software navegar en el proceso
de diseño. Davis sugiere un conjunto de principios para el diseño del software que han
sido adaptados y ampliados en la siguiente lista:
• El proceso de diseño no debería ponerse “orejeras”. Un buen diseñador debería
considerar enfoques alternativos, juzgando cada uno con base en los requisitos del
problema, los recursos disponibles para hacer el trabajo y los conceptos de diseño.
• Se deberían seguir los pasos del diseño hasta el modelo de análisis. Como un solo
modelo del elemento de diseño se refiere a menudo a múltiples requisitos, es necesario
tener los medios para hacer un seguimiento de cómo ha satisfecho los requisitos dicho
modelo.
• El diseño no debe inventar nada que ya esté inventado. Los sistemas se construyen
usando un conjunto de estructuras de diseño, de las cuales muchas se han utilizado
anteriormente. Estas estructuras, a menudo denominadas componentes de diseño
reutilizables, deben considerarse siempre antes que reinventar nada. ¡El tiempo es
P
P R
R O
O N
N A
A D
D
106
Especificaciones técnicas del SIIA
Consideraciones generales sobre la ingeniería de software
corto y los recursos limitados! El tiempo invertido en diseño debe concentrarse en
presentar ideas verdaderamente nuevas y en integrar aquellas estructuras que ya existen
•
El diseño debería “minimizar la distancia intelectual” entre la estructura del diseño del
software (cuando sea posible) e imitar la estructura del dominio del problema.
• El diseño debería presentar uniformidad e integración. Un diseño es uniforme si parece
que sólo una persona desarrolló todo el conjunto. Se deberían definir normas de estilo
y de formato para un equipo de diseño antes de comenzar el trabajo de diseño.
• Un diseño está integrado si se tiene el cuidado en definir las interfaces entre los
componentes del diseño.
• El diseño debería estructurase para admitir cambios. Muchos de los conceptos de
diseño permite a éste conseguir este principio.
• El diseño debería estructurarse para degradarse poco a poco, incluso cuando se
enfrentan a datos, sucesos o condiciones operativas aberrantes. Un programa bien
diseñado no debería “explotar” nunca. Debería diseñarse para aceptar circunstancias
inusuales, y si debe terminar el procesamiento, hacerlo de una manera suave.
• El diseño no es escribir códigos y escribir códigos no es diseñar. Incluso cuando se
crean diseños procedimentales detallados para los componentes de un programa, el
nivel de abstracción del modelo de diseño es mayor que el del código fuente. Las
únicas decisiones del diseño hechas a nivel de código se refieren a los pequeños
detalles de implementación que permiten codificar el diseño procedimental.
• Se debería valorar la calidad del diseño mientras se crea, no después de terminarlo.
Existe una variedad de conceptos de diseño y medidas de diseño disponibles para
ayudar al diseñador en la valoración de la calidad .
• Se debería revisar el diseño para minimizar los errores conceptuales (semánticos). A
veces hay tendencia a concentrarse en minucias cundo se revisa el diseño, no dejando
los árboles ver el bosque. El diseñador debe asegurarse de que se revisen los elementos
conceptuales principales del diseño (omisiones, ambigüedades, inconsistencias) antes
de preocuparse por la sintaxis del modelo de diseño.
Cuando se aplican apropiadamente los principios del diseño señalados anteriormente, el
ingeniero de software crea un diseño que muestre factores de calidad externos e internos.
Los factores de calidad externos son aquellas propiedades del software que pueden observar
los usuarios (p. ej.: velocidad, fiabilidad, corrección, utilidad). Los factores de calidad internos
son importantes para los ingenieros del software, permiten un diseño de alta calidad desde
la perspectiva técnica. Para conseguir los factores de calidad interna, el diseñador debe
entender los conceptos básicos de diseño.
P R O N A D
107
Programa para la Normalización de la Información Administrativa
P
P R
R O
O N
N A
A D
D
108
Especificaciones técnicas del SIIA
Conceptos básicos sobre las bases de datos relacionales
VII. CONCEPTOS BÁSICOS SOBRE LAS BASES DE DATOS
RELACIONALES
El modelo relacional es un modelo muy elegante y claro, ha constituido los cimientos de la
industria de las bases de datos durante casi 20 años. El relativamente pequeño número de
conceptos existentes en la teoría relacional ha ayudado a convertir esta técnica en un estándar
industrial. Los diseñadores relacionales han sido capaces de aislar la complejidad del
desarrollo físico de las bases de datos respecto al diseño lógico del sistema, proporcionando
así una interfaz sencilla para los diseñadores de aplicación.
Durante las dos últimas décadas hemos madurado como industria. Muchos de nosotros
hemos sentido la necesidad de contar con un entorno de modelización más rico que se
adaptara mejor a los recientes avances que tienden hacia una modelización genérica.
Además, reconocemos que existen conceptos de la teoría orientada a objeto que podrían
introducirse en el mundo de las bases de datos y que podrían mejorar la eficiencia de las
mismas.
Las bases de datos relacionales cuentan con un vocabulario relativamente limitado. Hemos
implementado estructuras utilizando archivos planos diseñados juiciosamente y
posteriormente, hemos introducido algunos tipos de índices distintos en varios campos de
esos archivos. En lo referente al acceso, los vínculos entre tablas sólo se especificaban de
forma lógica, por lo que los punteros de referencia se llevaban a cabo mediante claves
externas. No necesitábamos contar con vínculos explícitos entre las tablas. Las limitaciones
de integridad referencial eran, simplemente pequeños trozos de código que evitaban la
introducción en el modelo de datos de algunos tipos específicos de datos no válidos.
Podíamos agregar desencadenadores (triggers) a nuestras tablas para realizar explícitamente
alguna actividad cuando se insertaba, actualizaba o borraba algún registro, y se almacenaban
unidades de programa en la base de datos. Finalmente, podíamos agrupar tablas para mejorar
el rendimiento. Todas estas estrategias limitaban nuestra forma de pensar. En una base de
datos relacional, cada tabla es virtualmente una estructura independiente.
En la creación de modelos de relaciones lógicas de entidades (ER) teníamos entidades
que eran subconjuntos de otras entidades. Por ejemplo, los empleados asalariados eran
un subconjunto de todos los empleados. De la misma forma, teníamos entidades que
dependían de otras entidades, tales como detalles OC, que dependían de órdenes de
compra. Sin embargo, nuestra capacidad para representar estas estructuras utilizando
bases de datos es limitada . Paradójicamente las bases de datos orientadas a objetos
retienen algunos de los conceptos de la primera teoría de bases de datos.
Al igual que lo que ocurría en los días de CODASYL, cuando introducimos conceptos de
objetivo en el mundo de las bases de datos relacionales, nos volvemos a encontrar con
“viejos amigos”, tales como listas y punteros.
No nos podemos olvidar de por qué en aquella ocasión abandonamos ya las listas
vinculadas y los punteros. Tenemos que recordar cómo era el mundo de las bases de datos
antes de la aparición de la metodología relacional a principios de la década de los años
P R O N A D
109
Programa para la Normalización de la Información Administrativa
ochenta. Todavía siguen existiendo (al menos hasta que el problema del año 2000 acabe
con ellas) bases de alto rendimiento que utilizan archivos CODASYL, ISAM y VSAM escritos
en COBOL. Las modificaciones a las bases de datos CODASYL suelen exigir meses de
esfuerzo. Hace ya algunos años nos encontramos con un antiguo proyecto COBOL en el que
surgió un nuevo requisito, cambiar la anchura de un campo de 10 a 12 caracteres. Esta
pequeña modificación supuso cientos de horas de trabajo de programación. En la actualidad,
con un entorno de base de datos relacional, este tipo de modificaciones sólo exigiría algunos
días de trabajo. Si la aplicación se generó con una herramienta CASE integrada, la realización
de este cambio podría llevar uno o dos días, incluso en un sistema de gran tamaño.
En los días de las bases de datos prerrelacionales, cumplir con los requisitos de elaboración
de informes era una tarea muy difícil. Si un determinado informe no había sido tomado en
cuenta durante las especificaciones originales del diseño, podría exigir semanas de trabajo
escribir un nuevo informe (suponiendo que fuera posible escribirlo). Las modificaciones a
las estructuras de datos subyacentes eran muy engorrosas. Los cambios más pequeños
parecían exigir un rediseño importante del sistema. No estamos afirmando que todos estos
problemas desaparecieran con la llegada de los diagramas de la relación de entidades
(ED) y de las bases de datos relacionales, pero la situación mejoró.
Las primeras bases de datos relacionales se parecían mucho a sus predecesoras de
archivos planos. La normalización se consideraba como una curiosidad académica. Con
tiempo, al menos con la tercera forma normal, se pudo constatar que la normalización no era
una idea tan mala. En la era de las desnormalizaciones, ocurrida en la década de los años
ochenta, tuvimos los mismos problemas con las estructuras relacionales que con los archivos
planos. Modificar una estructura de datos seguía siendo una labor difícil y cara, lo mismo
ocurría si se deseaba modificar una aplicación. En la década de los noventa, la mayoría de
los diseñadores de datos habían podido comprobar que las fuertes desnormalizaciones
efectuadas en los ochenta estaban pasando factura, causando problemas de forma masiva
en aquellos sistemas que necesitaban modificarse. La normalización fue, finalmente, en estilo.
A mediados de los noventa, algunas de las primeras ideas de la metodología orientada a
objeto comenzaron a introducirse en las bases de datos relacionales. Este tema implicó la
generalización de modelos creando estructuras abstractas, a la vez que todavía seguíamos
trabajando en el entorno de bases de datos relacionales. En los últimos años, parte de la
comunidad de diseñadores de base de datos relacionales han abrazado ya la metodología
orientada a objeto.
En la actualidad, es frecuente ver cierto nivel de modelización genérica en la mayoría de
los sistemas. Por ejemplo, existe un estándar industrial para representar las unidades
organizativas como una simple estructura recursiva, en lugar de utilizar tablas
independientes para regiones, divisiones y departamentos (o sea cual sea la estructura para
una determinada empresa).
Incluso, cada vez son más frecuentes los modelos más abstractos. En una conferencia
celebrada recientemente, alguien que diseñaba una base de datos de cuestionarios me
preguntó cómo podría manejar una tabla como varios cientos de columnas. Cada cuestionario
consta de cientos de preguntas. Varias personas que se encontraban entre los asistentes
P
P R
R O
O N
N A
A D
D
110
Conceptos básicos sobre las bases de datos relacionales
Especificaciones técnicas del SIIA
respondieron que se debía modelizar el cuestionario introduciendo las preguntas en una
tabla separada y almacenando la estructura del cuestionario como datos en la base de datos.
Estaba teniendo lugar una revolución silenciosa. La metodología orientada a objeto estaba
encontrando su sitio entre los modelos de datos.
Recientemente, se han dado dos pasos más en la evolución hacia la orientación a objeto.
En primer lugar, las propias bases de datos han comenzado a concluir nuevas funciones
orientadas a objeto. En segundo lugar, disponemos de un nuevo lenguaje de modelización
más rico; nos referimos a UML frente al antiguo ERD. Como mencionamos anteriormente,
estos nuevos conceptos incluyen realmente algunos de los viejos conceptos del pensamiento
prerrelacional con listas vinculadas y punteros. Esta nueva integración de lo nuevo y de lo
viejo representa una gran oportunidad, pero también se debe tomar con precaución. En la
actualidad, podemos construir estructuras relacionales que funcionan de manera más eficaz.
Pero si no somos cuidadosos, podremos perder parte de la flexibilidad de las estructuras
que evolucionaron a partir del paradigma de las bases de datos relacionales.
Terminología y conceptos básicos
En el diseño de base de datos relacionales, analizaremos el modelo lógico de datos
frente al físico. El modelo lógico de datos representa el diseño de la base de datos, mientras
que el modelo físico representa la realización del diseño. Se utilizan palabras distintas para
comparar el diseño lógico y el diseño físico. Todo esto puede ser algo confuso. El siguiente
esquema ayuda a clarificar esta terminología para poder seguir con nuestro debate:
Lógico relacional
Entidad
Atributo
Instancia
Lógico objeto
Clase
Atributo
Objeto
Físico
Tabla
Columna, campo
Fila
Para asegurar la consistencia es importante clarificar las definiciones que son importantes
para este análisis:
Entidad. Se trata de algo que tiene interés para la empresa, tal como un empleado, un
departamento o una venta. Desde una perspectiva teórica, una entidad puede ser,
simplemente, un conjunto de atributos. Sin embargo no se trata de una forma útil de pensar
en entidades. Es mejor pensar que una entidad es algo que tiene correspondencia en el
mundo real. Cada instancia de la entidad departamento, por ejemplo, se corresponde con
un departamento específico en la organización (o en el caso de la entidad persona, a una
persona específica). Existe una correspondencia directa entre entidades e instancias de la
teoría relacional y clases y objetos, respectivamente, en teoría de objetos. Por ejemplo, para
la entidad departamento podemos hablar de la clase departamento, que incluirá el objeto
contabilidad.
Atributo. Se trata de una pieza de información que podemos extraer de un objeto o instancia
de una entidad, tales como los nombres de los departamentos o las edades de los empleados.
Observe que la palabra “atributo” se utiliza tanto en teoría relacional como en teoría de objetos.
P R O N A D
111
Programa para la Normalización de la Información Administrativa
Clave primaria. Se trata de un concepto de teoría relacional que describe los atributos de
una entidad que identifican de manera única a cualquier instancia específica de dicha entidad.
Por ejemplo, el ID de Empleado (identificador de empleado) es una clave primaria apropiada
para la entidad empleado, porque no puede haber dos empleados que tengan el mismo ID.
Las claves primarias deben ser únicas. Ningún componente debe ser nulo y, una vez que han
sido asignadas, no podrán modificarse. Este requisito final es más práctico que teórico,
porque las claves primarias se utilizan en lugar de los punteros en las bases de datos
relacionales. Modificar la clave primaria significaría cambiarla en cualquier lugar a miles o,
incluso, a millones de registros.
Clave candidata. Con frecuencia, en una entidad, es posible que más de un atributo pueda
servir como clave primaria. Una de las claves candidatas se designará como clave primaria.
Otros atributos que pueden actuar como claves primarias se designarán como claves
candidatas.
Creación de un diagrama entidad-relación
El diagrama de entidad-relación permite que un ingeniero de software especifique los
objetos de datos que entran y salen de sistema, y las relaciones entre los objetos. Al igual
que la mayoría de elementos del modelo de análisis y las relaciones entre objetos, el DER
construye de una forma interactiva. Se toma el enfoque siguiente:
1. Durante la recopilación de requisitos, se pide que los clientes listen las “cosas” que
afronta el proceso de aplicación y/o del negocio. Estas “cosas” evolucionan en una
lista de objetos de datos de entrada y de salida así como entidades externas que
producen o consumen información.
2. Tomando un objeto cada vez, el analista y el cliente definen si existe una conexión (sin
especificarlo en ese momento) o no entre ese objeto de datos y otros objetos.
3. Siempre que existe una conexión, el análisis y el cliente crean una o varias parejas de
objeto-relación.
4. Para cada pareja objeto-relación se explora la claridad y la modalidad.
5. Interactivamente se continúan los pasos del 2 al 4 hasta que se hayan definido todas
las parejas objeto-relación. Es normal descubrir omisiones a medida que el proceso
continúa. Objetos y relaciones nuevos se añadirán invariablemente a medida que crezca
el número de interacciones.
6. Se definen los atributos de cada entidad.
7. Se formaliza y revisa el diagrama objeto-relación.
8. Se repiten los pasos del 1 al 7 hasta que se termine el modelado de datos.
P
P R
R O
O N
N A
A D
D
112
Especificaciones técnicas del SIIA
Conceptos básicos sobre las bases de datos relacionales
Reglas de normalización
Cuando decimos que una base de datos ha sido normalizada, no nos estamos refiriendo
a normal en el sentido de regular u ordinario. En este contexto, normalizado (adjetivo derivado
de la notación matemática de normal) significa ortogonal. Volviendo a nuestras olvidadas
clases de álgebra lineal, recuerde que el término normalizado se utilizaba conjuntamente
con los vectores ortogonales en un espacio vectorial y en análisis del tipo: ¿puede una
combinación lineal de un conjunto de vectores constituir un denominado espacio vectorial?
La noción de normalización en una base de datos persigue una idea similar, ya que, en
este caso, se está intentando desarrollar un conjunto de tablas en la base de datos que no se
superpongan de manera inapropiada y que nos permitan almacenar toda la información que
pueda contener la base de datos en la misma forma en que tres vectores unitarios ortogonales
pueden generar un espacio de tres dimensiones.
No vamos a entrar en discusiones formales sobre normalización. Podrá encontrar este
tipo de análisis en libros tales como A First Course in Database Systems1, de Jeffrey D.
Ullman, en numerosos trabajos desarrollados por Chris J. Date, o en cualquier otro de los
numerosos libros académicos que analizan las bases de datos. Iremos presentando
definiciones de normalización con un sentido más práctico y más apropiado para los objetivos
perseguidos por este libro.
¿Por qué queremos construir bases de datos normalizadas? La normalización nació en
conjunción con el lenguaje de programación denominado SEQUEL. El teorema fundamental
de la teoría relacional es que si su base de datos se encuentra normalizada, podrá extraer
cualquier subconjunto de datos de ella utilizando operadores básicos de SEQUEL. Por este
motivo la normalización es tan importante. Puede ser muy complicado extraer información
de una base de datos no normalizada sin tener que desarrollar un código complejo, estas
reglas de normalización fueron importantes en los modelos relacionales y siguen siendo
importantes en los modelos objeto-relacionales.
Todavía seguimos utilizando SQL+ o una extensión orientada a objeto de SQL (una versión
de SEQUEL) para manipular la información contenida en las bases de datos. Si no trabajamos
con bases de datos normalizadas, SQL puede no funcionar. Aunque una persona haya
trabajado durante toda su carrera profesional en entornos de DBMS, puede no conocer los
entornos existentes antes de la aparición de las bases de datos racionales. El cambio de
orientación del papel en la impresión de un informe llevaba, al menos, dos semanas. Con
frecuencia, los intentos de realizar pequeñas modificaciones en una estructura de datos
llevaban meses e incluso años de tiempo de desarrollo. Si la intención era incluir nuevas
funciones, nos encontrábamos con miradas vacías, movimientos de cabeza y respuestas
del tipo “dada la actual arquitectura del sistema, las modificaciones que usted propone no se
pueden llevar a cabo”. Si abandonamos las reglas de normalización para la creación de
bases de datos orientadas a objeto, corremos el riesgo de dar un paso de gigante hacia
atrás en términos de flexibilidad de los sistemas que desarrollaremos.
P R O N A D
113
Programa para la Normalización de la Información Administrativa
Primera forma normal
La primera forma normal se define como aquella que no tiene ningún atributo multivalor.
Ilustraremos este concepto mostrándole una estructura de tabla que va en contra de la primera
forma normal. Por ejemplo, queremos asociar a una entidad denominada orden de compra
(OC) un atributo denominado “elementos pedidos”. Como es posible solicitar varios artículos,
contará con la capacidad de almacenar varios elementos en la entidad. La tabla mostrada
en el ejemplo 2 ilustra este tipo de violación.
El problema surge si existe un tercer artículo. Tan sólo puede solicitar dos artículos
utilizando esta estructura. Naturalmente, siempre podemos añadir más columnas para
permitir la petición de más artículos. Podemos añadir suficientes columnas como para no
tener que preocuparnos nunca sobre la posibilidad de permitir más artículos de lo permitido.
Sin embargo, nos enfrentaríamos con un problema diferente. La única forma de conocer
el número de veces que se ha solicitado un determinado artículo sería mirar en todas las
columnas de artículos. Incluso, calcular el valor total de alguna factura exigirá mirar en varios
lugares.
En el modelo relacional existe una forma de satisfacer la primera forma normal. La
estructura necesaria para resolver las violaciones contra la primera forma normal.
Es posible construir buenas bases de datos sin tener que adherirse a la primera forma
normal. Los teóricos relacionales resolvieron hace mucho tiempo qué extensiones a la teoría
relacional son necesarias para poder trabajar con bases de datos que no cumplan la primera
forma normal. La idea es permitir que los arrays sean un tipo de datos. De esta forma se
pueden obtener mejores rendimientos que en el caso de utilizar una base de datos relacional
estándar, pero hay que elaborar consultas más complejas para extraer los datos.
Durante años la comunidad de bases de datos ha analizado el tema de si la primera
forma normal es incluso deseable. Simplemente, no puede coger una base de datos relacional
estándar y violar la primera forma normal sin un costo negativo. Sigue habiendo una pregunta
trascendental: ¿existe alguna ocasión en la que desee estructurar una tabla en la que una de
sus columnas sea realmente un array o un conjunto de valores o registros? La respuesta es
un “sí” incondicional.
Existen ocasiones en las que se necesita de manera inherente e inexcusable la utilización
de estructuras que no cumplan la primera forma normal. Hace años Cobb desarrolló las
extensiones de SQL necesarias para que los arrays pudieran ser un tipo de datos.
Realmente, el lenguaje SQL necesario para manejar estructuras que no cumplan la primera
forma normal es más complejo, pero es una decisión de cada diseñador determinar si desea
desarrollar estructuras de este tipo.
Esta tecnología es actualmente demasiado nueva como para que podamos proporcionar
directrices explícitas sobre cuáles son las situaciones más adecuadas para poder utilizarla.
Todavía estamos esperando la aparición de herramientas que faciliten en empleo de
estructuras que no cumplan la primera forma normal y que los diseñadores acaparen más
experiencia en el manejo de este tipo de estructuras.
P R O N A D
114
Especificaciones técnicas del SIIA
Conceptos básicos sobre las bases de datos relacionales
Segunda forma normal
La segunda forma normal surge cuando cuenta con una clave primaria multiatributo. Este
hecho significa que los atributos presentes dependen de una parte de la clave primaria.
Comprender la segunda forma normal y la tercera forma normal requiere un cierto
conocimiento del concepto de dependencia.
Dependencia
Dependencia es un concepto sutil relacionado con los datos. Si un atributo B depende de
un atributo A, entonces, si se conoce el valor de A, sabremos lo suficiente para encontrar el
valor de B. Este hecho no significa que podamos obtener el valor de A, significa, simplemente,
que sólo puede existir un valor para B. Por ejemplo, en una entidad persona, si contamos
con un ID único para cada persona, cómo un número de la seguridad social, también podremos
conocer la estatura de la persona, empresa para la que trabaja, color de ojos, etc. Todos
estos atributos dependen de un único identificador que reconoce a cada una de las personas.
Conociendo uno de estos atributos, por ejemplo, la edad, no podremos determinar la estatura
de la persona. Desde el punto de vista de bases de datos relacionales, la estatura no depende
de la edad. Prácticamente, este hecho significa que la clave primaria es el identificador
único de la instancia de la entidad. Por tanto, cuando hablamos de dependencia utilizando el
ejemplo de persona, si se conoce a la persona, entonces también podremos conocer su
estatura, peso y cualquier otra característica. La clave primaria actúa como un sustituto de la
que representa la instancia de la entidad.
Si sólo existe dependencia de una parte de la clave primaria, entonces se está violando la
segunda forma normal. Por ejemplo, si estamos analizando una entidad, tal como las llamadas
telefónicas, identificar de forma única una llamada telefónica requiere tanto del número de
teléfono que origina la llamada como la hora en que comenzó dicha llamada. Podríamos
utilizar otras claves candidatas como claves primarias, pero éstas son correctas.
En esta entidad, podemos asumir que contamos con un atributo denominado ubicación
telefónica. Dependiendo de lo que estemos modelando, esta situación puede ser o no
una violación de la segunda forma normal. Si el teléfono está situado sobre una mesa de
despacho, habremos violado la segunda forma normal porque la ubicación sólo depende
del número de teléfono. Sin embargo, si estamos modelando un teléfono móvil, cada llamada
puede haberse realizado desde una ubicación distinta, y no existirá una violación de la segunda
forma normal. Este ejemplo subraya la necesidad de comprender claramente las reglas del
juego para poder modelar correctamente la organización en la base de datos.
Otra violación de la segunda forma normal se presenta cuando no se especifica
correctamente la clave primaria. Por ejemplo, tenemos el siempre popular ejemplo del video
club donde el objetivo es determinar una entidad que represente el alquiler de una cinta de
video. Incluso en muchos libros de texto, podrá encontrar que se han asignado como claves
primarias el ID del cliente, ID de la cinta y la fecha de alquiler. Podría identificar de manera
única el alquiler de una cinta utilizando el ID de la cinta y la fecha de alquiler porque no se
puede alquilar una misma cinta dos veces en el mismo día. De esta forma, cualquiera de los
atributos asociados con los alquileres (facturas, etc.) sólo dependerán del ID de la cinta y de
P R O N A D
115
Programa para la Normalización de la Información Administrativa
la fecha de alquiler. Si se incluye el ID del cliente en la clave primaria, se estará violando la
segunda forma normal. Sin embargo, en este caso, esta violación no es particularmente
seria.
Tercera forma normal
Se viola la tercera forma normal cuando se presenta una dependencia transitiva.
Operacionalmente, esto se traduce en el hecho de tener un atributo que es dependiente
de otro atributo que no forma parte de la clave primaria ni de las claves candidatas. Las
violaciones de la tercera forma normal siempre son extremadamente serias. Cualquier
violación de la tercera forma normal que se detecte debe ser subsanada inmediatamente.
Lo que indican estas violaciones es que el diseño de la base de datos es erróneo. Nuestro
primer ejemplo de una base de datos diseñada pobremente (mostrada anteriormente en el
apartado del ejemplo 1) es el clásico caso de una violación de la tercera forma normal. Es de
vital importancia que todo atributo que pertenezca a una entidad o tabla dependa de la clave
primaria o de alguna de las claves candidatas y no de ningún otro atributo de la tabla. Cuando
esto es así siempre se cumple que el atributo se encuentra en la tabla equivocada, o bien,
que el modelo de datos no es correcto.
P
P R
R O
O N
N A
A D
D
116
Especificaciones técnicas del SIIA
Políticas de seguridad para el control del acceso a la información
VIII. POLÍTICAS DE SEGURIDAD PARA EL CONTROL DEL ACCESO A
LA INFORMACIÓN
Dentro de las diferentes organizaciones resulta necesario que éstas cuenten con políticas
de seguridad para controlar el acceso a la información de los sistemas.
Es decir, un código de conducta para la utilización de los sistemas de información que
trata de evitar accidentes. Esta política de seguridad detalla:
• Las actividades que se permiten y las que no se permiten
• Los pasos a seguir por los usuarios para protección de sus datos
• Cómo los usuarios pueden acceder a los archivos de otros usuarios
• Los derechos de los administradores del sistema
• La política de seguridad, además debe incluir las penalidades y sanciones en caso de
una violación a las normas de seguridad
La política del impedir
Se puede tomar la política de prohibir. Es decir, podemos poner barreras para impedir el
paso a ciertas partes conocidas como sensibles.
Pensemos en barreras de control como nombre de usuario/contraseñas en los sistemas
UNIX; muros de seguridad (firewalls) en las redes.
Tener todo bajo llave y sólo después de verificar minuciosamente la identidad del usuario
y sus intenciones, dejarle utilizar a éste los recursos sensibles.
Esta política tiene la ventaja de la detección temprana de problemas, esto es, la alternativa
es similar a tener todo bajo llave en el almacén y tener que mostrar su credencial o identificación
para entrar, esto sería la política de la prohibición.
El inconveniente fundamental es la afectación sensible de la sencillez, rapidez y servicios
que ofrece este sistema.
La política de vigilar
También podemos tomar la política de vigilar todas las actividades o en su defecto, sólo
las actividades sospechosas o más sensibles.
Permitir el acceso “libre” a todo usuario de los recursos del sistema tiene la ventaja de la
libre circulación e intercambio de información, rapidez, sencillez y un gran número de servicios.
El inconveniente fundamental es el costo de los supervisores (programas en constante
ejecución) y el peligro más latente de encontrarse con problemas y fallas.
P R O N A D
117
Programa para la Normalización de la Información Administrativa
Respecto a esto podemos indicar que la programación en shell, awk y perl son
herramientas indispensables para la construcción de los demonios o supervisores en UNIX.
Tener todo a la vista y al alcance, pero con agentes supervisores por todos lados del
almacén, o sólo sobre todo en los artículos más costosos y con mayor riesgo de extraerse.
Política prohibir/supervisar
Dejar entrar al almacén libremente, pero pedir credencial de identificación a ciertos
departamentos de éste.
Al interior de este departamento con información sensible, se tienen agentes supervisores.
Esta es una mezcla de la prohibición y supervisión, donde en ciertas zonas ponemos
controles de acceso, pero estando dentro sólo se supervisan algunas actividades. Cada una
de estas políticas tiene sus ventajas e inconvenientes. La ventaja de esta política híbrida
prohibir/supervisar es que permite la libre circulación en casi todos los departamentos y sólo
analiza con detalle los movimientos en la zona sensible, limitando de esta forma los controles.
Cifrado total o selectivo de información
En esta política dejamos la libre circulación por los recursos del sistema, ya que aun en el
caso de realizarse un copia no permitida de datos, la información será inutilizable ya que se
encuentra cifrada. La ventaja mayor es la libre circulación de la información que permite un
mayor flujo y distribución.
Sin embargo, su desventaja es el desconocimiento y poca utilización en los corporativos
de las técnicas de cifrado.
Nota: El riesgo de ambigüedad surge en el caso de uso de fechas con años de dos dígitos, ya que OLEAUT32.DLL
sólo provee soporte para el periodo comprendido entre el 1 de enero de 1930 al 31 de diciembre de 2029.
P R O N A D
118
IX CASO PRÁCTICO
Introducción.
La computación, está considerada como uno de los pilares fundamentales
de finales de siglo que nos ayuda a crear valor, administrar, organizar y simplificar
el proceso cotidiano. Sin embargo, adoptar una nueva tecnología, dada la inmensa
proliferación de conceptos y herramientas computacionales existentes, muchas
veces nos genera inmensa ansiedad y hasta miedo. En los recientes años (1995 1999) hemos visto una proliferación tecnológica como nunca. Una inmensa masa
tecnológica nos está indigestando. No tenemos tiempo para procesarla. No
terminamos de aprenderla cuando ya nos están vendiendo la última generación.
Este fenómeno se encuentra en todos los sectores y en el educativo no es
la excepción. Si se refiere a las áreas administrativas se aprecia mayor
desarticulación en los procesos y en la integración de sistemas que en otras
áreas. Los elementos que se deben establecer para desarrollar un sistema integral
de información administrativa de acuerdo a los estándares que PRONAD a
marcado, deberá contará con la asignación de profesionales de tecnología de la
información para trabajar con usuario en los departamentos involucrados, disponer
de una base de datos de acuerdo a las características que marca el documento
“Términos de Referencia” propuesto por
PRONAD, con programas de
capacitación en nuevas y avanzadas tecnologías, para brindar soluciones rápidas
y efectivas, en áreas tales como: desarrollo, soporte, redes y telecomunicaciones.
El caso práctico que ofrece la Universidad Autónoma de Nayarit y la
Universidad Autónoma de San Luis Potosí, es de ejemplificar el esfuerzo del
diseño y la preparación que requieren los sistemas de información.
Sabemos que un error en el diseño no se detecta hasta la fase de
comprobación y que requiere mucho mayor esfuerzo para arreglarlo, de ahí la
importancia de tenerlos previstos desde el diseño.
La metodología utilizada en las instituciones que presentan en el caso
práctico comprende primero un análisis conceptual.
Con una descripción detallada de la metodología a emplear como el análisis
de requerimientos, incluyendo el análisis de estructurado de datos, métodos para
crear el modelo del sistema integral de información administrativa como diagrama
de clases, diagramas de flujo de datos, diagramas de entidad relación, etc.
Dentro del análisis se enfoca a la construcción de miniespecificaciones para
la definición de los resultados obtenidos del diseño y la documentación requerida
como producto final del análisis efectuado.
De definen los pasos importantes para la construcción del sistema integral
de información administrativa ( SIIA ).
1.- Análisis
2.- Diseño
3.- Programación
4.- Implementación
Descritas en forma simple y breve hablando de los conceptos relevantes de
las consideraciones del diseño, propias del dominio de la aplicación administrativa
que se esta trabajando y el software elegido para la tarea.
Es claro que los malos métodos de diseño pueden forzar a que se tengan
que rescribir las principales partes del sistema; los malos métodos de construcción
no se pueden forzar a que se tenga que hacer esto, sin embargo estos errores
pueden introducir errores sutiles que pueden requerir días o incluso semanas para
encontrarlos y corregirlos, de manera que el diseño es básico para armar un
método de construcción.
En la parte de descripción de las miniespecificiones técnicas se aplica a la
nómina en la institución e inicia desde la descripción del “Nombramiento” y sus
movimientos de Altas, Bajas, Consultas, Modificaciones y Reportes, además de
sus variables estándares para su programación, esto mismo es para los módulo
de “Empleados”, y “Control de Plazas”.
La UAN presenta el diseño que son representados por el modelo de
contexto y el modelo de eventos:
El modelo de contexto en el módulo general del subsistema financiero
representa las ligas entre las Dependencias y la Caja por medio de una solicitud
de reposición de cheques, los recibos a cobrar y los cheques generados asimismo
de las relaciones de la Caja con Egresos y este con las Dependencias.
Esta forma gráfica se encuentra para cada uno de los módulos: el de
Ingresos, Caja, Contabilidad, Egresos, Programación del Pago, Reposición de
cheques, Cancelación de un pago, Elaborar cheques del Programa de Pagos,
Proceso de Comprobación, y el Cobro que se efectúa en la institución.
En el Modelo de Eventos, se mencionan como ejemplos algunos escenarios
como:
- La Dependencia programa un pago, aquí se presentan las 4 fases
del proceso;
1.
Diagrama de Estados que representa en forma de diagramas
de flujo el proceso administrativo.
2.
El Diagrama de transición de Estados analiza el estado actual
en cada uno de los procesos involucrados
3.
Diagrama de flujo de Objetos se crea un escenario completo
de la Programación de un pago,
4.
Seguimiento de sucesos se revisa que los procesos internos
sean definidos conforme a lo establecido por las áreas usuarios.
-
La Dependencia cancela un pago
-
La Dependencia solicita una reposición de cheques
-
Caja registra ingresos de Dependencias
-
Dependencia elabora solicitud de recibos de ingresos
-
La dependencia comprueba gastos
Los escenarios tienen la misma estructura presentada para el primer caso
“La Dependencia programa un pago”.
Con la parte conceptual bien establecida y documentada, da origen al
diseño de la Base de Datos, y que a partir de los esquemas denominados
diagramas de entidad relación para los procesos mencionados anteriormente.
Esto solo representan una parte de los procesos que pertenecen al sistema
en general y que en su forma integral comprenden los tres grandes módulos:
financiero, administración escolar y recursos humanos.
ETAPAS EN EL DESARROLLO DE SISTEMAS.
1. ANALISIS.
1.1. ANALISIS DEL SISTEMA.
1.2. DOCUMENTACION DEL ANALISIS.
1.3. REVISION DE ANALISIS CON EL USUARIO.
2. DISEÑO.
2.1. GENERACION DEL MODELO E-R.
2.2. MODELACION DE PROCESOS.
2.3. DISEÑO DE BASES DE DATOS.
3. PROGRAMACION.
3.1. CREACION DEL AMBIENTE DE PROGRAMACION.
3.2. CREACION DE LA B.D.
3.3. TABLAS DEL SISTEMA.
3.4. PROCESOS
3.5. REPORTES.
3.6. PRUEBAS AL SOFTWARE.
3.7. DEFINICION Y PROGRAMACION PROCESOS DE CARGA
INICIAL.
4. IMPLEMENTACION.
4.1. DOCUMENTACION DEL USUARIO
4.2. CAPACITACION A USUARIOS.
4.3. CARGA INICIAL DE INFORMACION Y ARRANQUE.
1. ANALISIS.
El análisis de Sistemas es el estudio del sistema actual del negocio a fin
de encontrar cómo trabaja y dónde debe mejorarse. Para realizar un buen
análisis se debe hacer hincapié en la investigación y las preguntas para
aprender como opera un sistema actualmente y para identificar los
requerimientos de información que todos los usuarios a todos los niveles tienen
para uno nuevo o modificado.
El análisis de sistemas funciona a través de la aplicación de una
metodología o estrategia general cuyas actividades específicas bien podrían
ser diferentes de un caso a otro de acuerdo a las necesidades del sistema, aun
cuando los objetivos del proyecto fueran los mismos en ambos casos.
El análisis de sistemas implica un enfoque que toma una perspectiva
global en el estudio y solución de un problema, por lo siguiente:
•
Porque tiende a analizar la totalidad de los componentes o
aspectos bajo estudio, así como sus interrelaciones.
•
Porque no aborda detalladamente un subsistema o aspecto
específico del sistema si no cuenta previamente con un panorama del
ambiente externo del mismo.
Esto significa que no se analiza un módulo o aspecto específico del
sistema sin antes haber analizado todos los módulos y sus interrelaciones.
1.1.
ANALISIS DEL SISTEMA.
Obtención de requerimientos de Información del usuario. La integración
del analista al proceso del sistema le permite obtener información de primera
mano en relación con la forma en que se llevan a cabo las actividades en el
sistema. Al término de esta actividad el analista debe haber adquirido un
conocimiento real de la información y los procesos que se realizan dentro de
los alcances del sistema.
1.2.
DOCUMENTACION DEL ANALISIS.
Definición de requerimientos y descripción de procesos del sistema
usando análisis estructurado. Conforme el analista conoce el funcionamiento y
flujos de información del sistema, este llevará a cabo la descripción y
representación de los mismos utilizando la metodología de Análisis
Estructurado.
La finalidad de esta actividad es que el analista conozca y analice el
proceso, flujo de información y requerimientos a detalle del sistema y realice un
documento que pueda ser entendido y revisado por usuarios y desarrolladores.
La recomendación de efectuar la documentación a todo el sistema
integral de información administrativa, es importante que cada programa de
una aplicación debe documentarse exhaustivamente con el fin de facilitar su
futuro mantenimiento por cualquier persona del departamento de desarrollo.
Para ello se deberá disponer de la siguiente información:
•
Estructuras de datos de los distintos archivos de entrada y
salida que utiliza el programa.
•
Diagrama de correspondencias entre ficheros de entrada y
salida.
•
Estructura del programa una vez integradas las estructuras
de entrada y salida.
•
Comentarios sobre el programa, indicando:
o
Colisiones detectadas y forma de resolverlas.
o
Normas especiales de ejecución.
o
Limitaciones.
o
Tablas de decisión.
o
Lista detallada de operaciones.
o
Estructura del programa conteniendo la asignación de
operaciones.
o
Lógica esquemática (pseudocódigo).
o
Listado del programa fuente, compilado y sin errores.
o
Listado de referencias cruzadas para facilitar la
búsqueda de variables y entidades a lo largo del programa, cuando
sea necesario efectuar su mantenimiento.
o
Listado de ocupación de memoria.
o
Cualquier otro listado que proporcione el compilador o
sistema operativo.
Documentación de la prueba definitiva que se realizó para obtener la
aceptación del programa, adjuntando juegos de ensayo, condiciones de
prueba, tiempo invertido, y resultados obtenidos.
1.3.
REVISION DEL ANALISIS CON EL USUARIO.
Presentación a usuarios de la definición de requerimientos y descripción
de procesos para revisión y aprobación. Es conveniente que conforme el
analista avanza en la definición de requerimientos y descripción del proceso,
también realice revisiones periódicas con el usuario, para evitar posibles
confusiones y omisiones de requerimientos de información importantes por
parte del analista.
Las actividades 1.1, 1.2, y 1.3 se llevan a cabo en forma repetitiva hasta
que, tanto los usuarios como los analistas estén de acuerdo con la definición de
requerimientos importantes por parte del analista.
2. DISEÑO.
El diseño es la tarea de llevar la presentación del modelo del mundo real
al computacional y es un tanto difícil, ya que la información que se obtiene del
usuario es imprecisa, parte de la intuición y esta en algunos casos
desordenada, tanto que de la máquina obtenemos la información de manera
precisa, predecible y exacta por lo que el analista tiene que realizar esta
transferencia de la manera más óptima posible.
2.1. DIAGRAMA E-R.
La generación del modelo Entidad-Relación facilita el Diseño de la B.D.
por medio de diagramas. Este Diagrama se obtiene a partir de la
Documentación arrojada en el análisis.
Una de las metodologías de desarrollo de sistemas que permite asociar
las técnicas de análisis con el Diseño de Bases de Datos utilizando un modelo
de Datos para la obtención de tal diseño a partir de la especificación de análisis
del Sistema de Información es la SAER( Structured Analysis – Entity
Relationship).
La metodología de diseño se lleva a cabo mediante los tres siguientes
pasos:
PRIMERO:
Utilizar la metodología de Análisis para producir un conjunto de
especificaciones formales de los requerimientos de información de un sistema.
SEGUNDO:
Realización de la transición de la especificación de requerimientos
(Análisis) a la modelación conceptual de la Base de Datos (Diseño de Base de
Datos). La modelación conceptual de la Base de Datos se va a obtener
mediante la utilización del modelo Entidad-Relación, cuyo objetivo es facilitar el
diseño de la Base de Datos por medio de diagramas.
Este modelo se basa en una percepción del mundo real que consiste de
un conjunto de objetos básicos llamados entidades y de las relaciones ente
esos objetos.
•
Una Entidad es un objeto que puede distinguirse de otros. La
distinción se logra asociando a cada entidad un conjunto de atributos que
describen el objeto.
•
Una relación es una asociación entre varias entidades.
TERCERO:
Generación del esquema global mediante el uso de técnicas de
integración de vistas. Para lograr el diagrama completo del diseño de la Base
de Datos, se debe obtener del análisis todas las vistas de Proceso; e identificar
las vistas del usuario y vistas de almacenamiento.
Una vista de Proceso es el conjunto de datos que están involucrados
en un proceso.
Una vista de usuario es el conjunto de datos que un usuario
determinado desea consultar. NO es conveniente que todos los usuarios
puedan ver el modelo conceptual completo. Las consideraciones de seguridad
pueden requerir que se oculten ciertos datos de ciertos usuarios.
Una vista de almacenamiento permite identificar en que momento será
almacenada la información requerida para la Base de Datos.
Ejemplos:
DiagramadeEntidadRelación
DiagramadeEntidadRelación
EntidadesqueseinvolucranenelmodulodeIngresos
DiagramadeEntidadRelación
EntidadesqueseinvolucranenelmodulodeEgresos
2.2. MODELACION DE PROCESOS.
Se valida a detalle con el modelo E-R todos los requerimientos
presentados en el análisis sin omitir nada. En esta etapa el equipo de
desarrollo valida en forma contundente el diseño del modelo E-R a partir del
análisis obtenido, con el objetivo de integrar los requerimientos de Información
(Registro de Información, Procesos, Reportes, etc.) en el Diseño que se esta
realizando.
2.3. DISEÑO DE LA B.D.
Una vez que se aprueba la validación del diagrama Entidad-Relación el
equipo de desarrollo transforma cada elemento del modelo E-R a tablas, de
acuerdo a varias reglas de integración y normalización del diseño.
El objetivo del Diseño de la Base de datos es generar un conjunto de
tablas relacionales que permitan almacenar la información con un mínimo de
redundancia pero que a la vez facilitan la recuperación de la Información.
3. PROGRAMACION.
La programación comienza, cuando termina la actividad del diseño. La
fase de programación involucra la creación de los Archivos de almacenamiento
(Bases de Datos) y la escritura de instrucciones en algún lenguaje de
programación (programas) para implantar lo que el analista ha especificado y el
diseñador ha organizado en módulos.
3.1. CREACION DEL AMBIENTE DE PROGRAMACION.
Incluye las siguientes actividades:
•
Definición de estándares de Programación.
•
Definición y creación de
almacenamiento de Datos.
Directorios de Desarrollo y
•
Definición e Inicialización de Carpetas de Documentación de
la programación.
3.2. CREACION DE LA BASE DE DATOS.
Crear o dar de alta la Estructura de la Base de Datos definitiva.
3.3 TABLAS DEL SISTEMA.
Se le llaman tablas del sistema a aquella información referente a
catálogos, que son necesarios para realizar los procesos de almacenamiento
de datos y de reportes. Son los que se programan primero por lo comentado
anteriormente, que son necesarios para programar los demás procesos del
sistema.
3.4. PROCESOS DE TRANSACCIONES.
Son los procesos que involucran cálculos o registro masivo de
transacciones e información.
3.5. REPORTES.
Son todos lo procesos que involucran la generación ó explotación de
información ya sea por pantalla, impresora o archivo.
3.6. PRUEBAS A LA PROGRAMACION.
Es probable que el proceso de probar el sistema tome tanto como la
mitad del tiempo programado para su desarrollo, dependiendo de qué tan
cuidadosamente se hayan hecho las actividades iniciales de análisis, diseño y
programación, se debe hacer algún esfuerzo para verificar que no haya errores.
Tipos de prueba:
Prueba funcional. Esta es la forma más común de prueba; su propósito
es asegurar que el sistema realiza sus funciones normales de manera correcta.
Así, los casos de prueba se desarrollan y se alimentan al sistema; las salidas (y
los resultados de los archivos actualizados) se examinan para ver si son
correctos.
Prueba de recuperación. El propósito de este tipo de prueba es
asegurar que el sistema pueda recuperarse adecuadamente de diversos tipos
de fallas. Esto es de particular importancia en los sistemas en línea grandes.
Las pruebas de recuperación pueden requerir que el equipo que realiza el
proyecto simule (o provoque) fallas de hardware, fallas de corriente, etc.
Prueba de desempeño. El propósito de este tipo de prueba es asegurar
que el sistema pueda manejar el volumen de datos y transacciones de entrada
especificados en el modelo de implantación del usuario, además de asegurar
que tenga el tiempo de respuesta requerido.
3.7. PROGRAMACION PROCESOS DE CARGA INICIAL.
Cuando el sistema se desarrolla tomando como base uno
computacional, la mayoría de las veces el usuario requiere que la información
contenida en su sistema anterior sea traspasada al nuevo sistema, por lo que
será necesario programar los procesos que realicen dicho traspaso. También
es necesario que la información contenida en tablas del sistema anterior sea
traspasada al nuevo sistema, para evitar que el usuario la vuelva a capturar en
el nuevo sistema.
4. IMPLEMENTACION.
Es la puesta en marcha del nuevo sistema, en algunos casos esta
puesta en marcha del nuevo sistema puede significar simplemente un cambio
de la noche a la mañana del nuevo sistema, en otros casos, la instalación
puediera ser un proceso gradual, en el que un grupo tras otro de usuarios van
recibiendo manuales y entrenamiento y comenzando a usar el nuevo sistema
modularmente. Esta etapa consta de las siguientes actividades:
•
Documentación para el usuario. (Operación del sistema)
•
Capacitación a usuarios.
•
Carga Inicial de Información y puesta en marcha. (Capturada
por usuarios o por Medio de Descarga del sistema anterior).
DIAGRAMA DE ACTIVIDADES EN EL PROCESO DE ANALISIS.
Definición del Alcance del sistema.
Integración del analista al proceso del
sistema.
Definición de requerimientos y descripción
de procesos del sistema actual usando una
metología de Análisis.
Presentación a usuarios de la definición
de requerimientos y descripción de
procesos para revisión y aprobación
NO
Revisado y
Aprobado?
SI
Integración del módulo al Sistema
Integral.
Diseño.
DIAGRAMA DE ACTIVIDADES EN EL PROCESO DE DISEÑO.
Generación del modelo EntidadRelación.
Modelación a detalle de los requerimientos
de Información.
Modelación de la Integridad de procesos en
el diagrama Entidad-Relación.
Revisión y Aseguramiento por parte de
desarrolladores.
Revisado y
Aprobado?
NO
SI
Transformación del modelo Relacional
a Tablas. Normalización del diseño e
Integración del Diseño al sistema
Integral.
Realización de miniespecificaciones
Computaciones
y definición de
Procesos de Carga Inicial.
Programación
Relación de escenarios
q
La Dependencia programa un pago
q
La Dependencia cancela un pago
q
La Dependencia solicita una reposición de cheques
q
Caja registra ingresos
q
Dependencia elabora solicitud de recibos de ingresos
q
La Dependencia comprueba gastos
Escenario para una Programación de Pago
q
Dependencia solicita folio de autorización a Presupuestos, para
realizar el gasto
q
Presupuestos envía folio de autorización a la Dependencia
q
La Dependencia envía solicitud de “Afectación presupuestal/Orden
de pago”
q
Ventanilla revisa que el llenado de la solicitud este correcto
q
Ventanilla recibe solicitud y verifica si existen solicitudes pendientes
de comprobar
q
Ventanilla turna la afectación a Integración de pasivos
q
Integración de pasivos manda la información correspondiente
a
Programación de Pago
q
Programación de pago programa una fecha para que Caja General
emita el cheque
Diagrama de Estados
Programación de Pago
Orden de pago
Elaborada
Enviar solicitud
Orden de pago
Enviada
Verificar contenido de la solicitud
Orden de pago
Verificada
Autorizar solicitud
Orden de pago
Autorizada
Programar fecha de pago
Orden de pago
Programada
Rechazar
solicitud
Orden de pago
Rechazada
Escenario para la cancelación de pago
q
Dependencia envía solicitud de cancelación de pago
q
Ventanilla envía la solicitud a Integración del pasivo para cancelar la
creación del pasivo y su póliza correspondiente
q
Ventanilla envía la solicitud a Programación del pago para cancelar la
fecha de pago
q
Integración del pasivo notifica a Presupuestos la cancelación para
que libere el presupuesto comprometido
q
Programación de pago envía notificación de cancelación de cheque a
Caja General
q
Caja General envía a Contabilidad toda la documentación generada
por la cancelación
q
Integración de pasivo envía a Contabilidad todos los documentos
generados por la cancelación
Escenario para la reposición de cheques
q
Dependencia solicita la reposición de cheque a Caja General
q
Caja General tramita la solicitud de reposición
q
Caja General envía la solicitud de reposición a Contabilidad para
que este certifique
q
Caja General notifica al banco la cancelación del cheque en caso de
ya haber sido entregado
q
Caja General entrega al Interesado el cheque de reposición
Escenario para la comprobación del gasto
q
Dependencia envía formato de “Afectación presupuestal/orden de
pago” para comprobar el gasto a Ventanilla
q
Ventanilla consulta que el folio a comprobar tenga saldo y que el
importe de la comprobación corresponda al documento de comprobación de lo
contrario lo regresa a la Dependencia
q
Ventanilla envía el formato para verificar si existe una comprobación
con saldo a favor o en contra del interesado al Analista de ventanilla
q
Analista de Ventanilla envía si es un saldo a favor a Programación
del pago para que se le asigne una fecha de pago
q
Analista de Ventanilla si es un saldo en contra solicita el formato de
“Ingreso por reintegro” a la Dependencia
q
Dependencia manda el formato de “Ingreso por reintegro” a Caja
General para que sea cobrado por esta
q
Caja General regresa el formato pagado a la Dependencia
q
Dependencia entrega toda la documentación comprobatoria al
Analista de Ventanilla
q
Analista de Ventanilla
turna al Departamento de Contabilidad
documentación comprobatoria del gasto
Escenario para la solicitud de recibos de ingresos
q
Dependencia Foránea envía “solicitud de recibos de ingresos varios”
y “solicitud de ingresos académicos” al Analista de Ingresos
q
Dependencia Local envía “Solicitud de ingresos varios” al Analista
de Ingresos
q
Dirección de Control Escolar envía relación de los aspirantes
seleccionados de nuevo ingreso así como los de reingreso al Jefe del
Departamento de Ingresos
q
Analista envía los folios asignados a los recibos solicitados por la
Dependencia a Caja General.
Escenario para el registro de ingresos
q
Caja General envía la documentación comprobatoria de los ingresos
al Encargado de Recepción
q
Encargado de Recepción revisa la documentación y si tiene errores
se lo notifica a la Dependencia ó a Caja General
q
Encargado de Recepción envía a Captura los documentos de los
diferentes tipos de ingresos y afecta las partidas correspondientes
q
Captura
turna
al
Departamento
de
Contabilidad
toda
la
documentación que fue originada por los ingresos
q
Jefe del Departamento de Ingresos solicita a la Secretaría de
Gobierno del Estado, los ingresos por subsidios Federales y Estatales
q
Jefe del Departamento de Ingresos envía a Captura copia del recibo
de subsidios junto con la ficha de Deposito.
Diagrama de Flujo de Objetos
Programación de Pago
Dependencia
Solicita
autorización de
presupuestos
Presupuestos
Envía solicitud
autorizada
Egresos
Solicitud revisada
Ventanilla
Programación
Del pago
Asigna una fecha
para pago
Caja General
Creación de
pasivos
Se crea pasivo y
se elabora póliza
de diario
Diagrama de Flujo de Objetos
Cancelación de Pago
Dependencia
Envía documento
de cancelación
Egresos
Ventanilla
Envía solicitud
para cancelar pago
Identifica en
que etapa se
encuentra el
pago
Cancela pasivo
creado y fecha de
pago programada
Cancela pasivo
creado
Integración de
Pasivo
Programación
de Pago
Notificación
para cancelar
cheque
Caja General
Diagrama de Flujo de Objetos
Reposición de Cheque
Dependencia
Solicita la
reposición de
cheque
Caja General
Tramita la
solicitud de
reposición
Certifica la
reposición de
cheque
Notifica para que
se cancele el
cheque emitido
Banco
Contabilidad
Aviso de cheque
cancelado
Diagrama de Flujo de Objetos
Comprobación de gasto
Dependencia
Envía documento
para
comprobación
Egresos
Ventanilla
Verifica si se trata
de saldos iguales,
saldo a favor o en
contra del
interesado
Analista de
Ventanilla
Existe saldo en
contra
Existe saldo a
favor
Sí existen saldos
iguales, se
envía la
documentación
comprobatoria
Programación
del pago
Dependencia
Contabilidad
Envía formato de
“ingreso por
Envía la fecha
para emitir el
cheque de pago
Caja General
Diagrama de Flujo de Objetos
Solicitud de Recibos de Ingresos
Dependencia
Envía solicitud de
“Recibos de Ingresos
Académicos y/o varios”
Ingresos
Envía los folios
asignados a los recibos
solicitados por la
Dependencia para su
cobro
Caja General
Diagrama de Flujo de Objetos
Registro de Ingresos
Caja General
Envía la documentación
comprobatoria de los
ingresos
Ingresos
Recepción
Turna los documentos de
ingresos para que se
afecten las partidas
correspondientes
Jefe del
Departamento
Documentos originados
por el ingreso por subsidio
con la ficha de depósito
Captura
Envía toda la
documentación
comprobaria de los
ingresos registrados
Contabilidad
Solicita el subsidio
Federal y Estatal
Emite el cheque para el
subsidio Federal ó Estatal
Secretaria de
Gobierno del
Estado
Diagrama de Estados
Cancelación de Pago
Documento para
cancelar pago
elaborado
Envía documento de cancelación
Documento para
cancelar pago
enviado
Verifica el contenido del documento
Documento para
cancelar pago
verificado
Autoriza la cancelación
Rechaza el documento
Documento para
cancelar pago
rechazado
Documento para
cancelar pago
autorizado
Cancela el pago solicitado
Pago Cancelado
Diagrama de Estados
Reposición de Cheque
Documento de
reposición de cheque
Elaborado
Documento de
reposición de cheque
Enviado
Documento de
reposición de cheque
Verificado
Documento de
reposición de cheque
Autorizado
Documento de
reposición de cheque
Rechazado
Cheque repuesto
Diagrama de Estados
Comprobación de Gasto
Comprobación de
Gasto
Elaborada
Envía documento para comprobar pago
Comprobación de
Gasto
Enviada
Verifica el contenido de documentación
Comprobación de
Gasto
Verificada
Autoriza la comprobación
Comprobación de
Gasto
Autorizada
Rechaza documento
Comprobación de
Gasto
Rechazada
Procede a comprobar el gasto
Gasto Comprobado
Diagrama de Estados
Solicitud de Recibos de Ingresos
Solicitud de recibos
de ingreso
Elaborada
Envía lade
solicitud
Solicitud
recibos
de ingreso
Enviada
Verifica el contenido de la solicitud
Solicitud de recibos
de ingreso
Verificada
Rechaza solicitud
Autoriza la solicitud
Solicitud de recibos
de ingreso
Autorizada
Asignación de folios a los recibos
Recibos entregados
Solicitud de recibos
de ingreso
Rechazada
Diagrama de Estados
Registro de Ingresos
Verifica el recibo de ingresos ó la solicitud de subsidios
Ingreso
Verificado
Autoriza el ingreso
Ingreso
Autorizado
Cobro del ingreso
Rechaza ingreso
Ingreso
Rechazado
Ingreso registrado
DOCUMENTACION
COMPUTACIONALES.
DE
MINIESPECIFICACIONES
Es la especificación de los procesos o modelación de los procesos del
sistema tomando en cuenta el lenguaje de programación y la estructura final
de la B.D.
La especificación de diseño escrita sirve a varios propósitos, proporciona
un método para documentar y revisar las ideas del equipo de desarrolladores
del SIIA, que es mucho mas rápido y eficaz que la codificación directa aún las
especificaciones de diseño más breve proporciona un gran avance al
cumplimiento de estándares para la apariencia y sensación a lo largo de la
aplicación, y es mucho más barato modificar un modelo que un sistema
parcialmente terminado.
La especificación del diseño también es una herramienta de
administración poderosa. Permite que la aplicación se divida entre varios
programadores del SIIA para la construcción a un nivel de detalle que es
mucho menor que la división requerida para lograr un diseño coherente.
Es la especificación final para el programador del sistema.
1.10. ABC NOMBRAMIENTOS.
Universidad Autònoma de San Luis Potosí
Sistema de Plazas
Fecha: 17/05/1999
Programa: N__________
Alta Nombramientos.
No.Nombr.
_______
_______
_______
_______
_______
_______
_______
_______
Alta
Baja
Descripción
Fecha Alta
___________________________ __/__/____
___________________________ __/__/____
___________________________ __/__/____
ABC Nombramientos.
___________________________ __/__/____
___________________________ __/__/____
___________________________ __/__/____
___________________________ __/__/____
___________________________ __/__/____
Modificar
Consulta
Fecha baja
__/__/____
__/__/____
__/__/____
__/__/____
__/__/____
__/__/____
__/__/____
__/__/____
Reporte
Salir.
No. Nombramiento: _____
Descripción: __________________________________
Descripción corta: ______________
Sub-Categoría UASLP: ______ ________*__________________
Categoría UASLP: __*___________*__________________
Factor de Sueldo: ______
Jornada Mensual para Vale Admivo: ______
Situación Laboral:______ (AD,DO,EL,NO,FU).
No. Tabulador SEP:______ __________*_________________
No. Tabulador UASLP:______
Tipo Antiguedad:_____ ____*_______________________
Tipo de plaza:______ (SF,SH)
Tipo Nivel Académico: ____ _________*____________
Pago de Diferencia Jornada: __ (SI/NO)
Tabulador para Premio x Antigüedad: ___
Permite ocupantes con el Nombr. en Plaza Evolucionada : ___ (SI/NO)
Permite empalme en Vig. De Ocupantes: ___ (SI/NO)
1.10. ABC NOMBRAMIENTOS.
MINIESPECIFICACIONES.
ARCHIVO:
NNOM_T
nom
nom_desc
nom_desco
scatuaslp
facsdo
jorm
sind
tbsep
tbuasl
tipoant
tipopla
nivaca
pdifjor
tabpanti
recsueldo
perm_oc_plaza_evol
perm_empalme_oc
usuario
fecha_alta
usuario
term
fecha_usu
fecha_baja
ALTA.
• Se captura nom - No.Nombramiento. Validar que NO exista el No. De Nombramiento Tecleado en NNOM_T.
• Se captura nom_descla Descripción del Nombramiento.
•Se captura nom_desco. La descripción corta del Nombramiento.
•Se captura scatuaslp - No. Sub-Categoría UASLP. Validar que exista en la Tabla NSCATE_T y que no tenga
fecha de baja. Es requerida.
• Se despliega la catuaslp- Categoría a la que pertenece la sub. categoría. Se obtiene de NSCATE_T.catuaslp
y se toma la descripción de la categoría del archivo de categorías - NCATE_T.catu-desc.
•Se captura factsdo - Factor de Sueldo.Es requerido.
• Se captura jorm- Jornada Mensual p/vale administrativo. No es requerido.
• Se captura sind - Situación Laboral. (AD,DO,EL,NO). Es requerido.
• Se captura tbsep - No. Tabulador SEP. Se valida que exista en la tabla NTABSEP_T y se despliega la
descripción del tabulador. NO es requerido.
• Se captura tbuasl - No. Tabulador UASLP. Se valida que exista al menos un registro con el tabulador de
la uaslp en el archivode tabulador Nivel - NTABNIV_D. Es requerido.
• Se captura tipoant - Tipo de Antigüedad. Se valida que exista en la tabla NTIPOANT_T. Es requerido.
• Se captura tipopla - Tipo de plaza (SF,SH). Es requerido.
•Se captura nivaca - Tipo de Nivel académico. Se valida que exista en la tabla de tipos de Niveles académicos
NNIVACA_T y que no tenga fecha de baja, y se despliega la descripción del Tipo de nivel académico.
No es requerido.
•Se captura pdifjor - Pago diferencia de Jornada (SI/NO). Este campo se utiliza para los nombramientos de los
veladores que cubren el turno de la noche, ya que a las personas con este nombramiento se le debe dar de alta
una percepción que que diga explícitamente “pago de diferencia de jornada”.
•Se captura tabpanti - No. De tabulador para el Premio por Antigüedad. Es requerido y se valida su existencia
en el archivo NTABPANTI_T (Debe existir al menos un registro en el archivo NTABPANTI_T con el tabpanti
capturado).
•Se captura perm_oc_plaza_evol - Si se permiten ocupantes con este Nombramiento en plaza evolucionada. Es
requerido y se debe teclear (SI/NO). Por default es “SI”.
Se captura perm_empalme_oc - Si se permiten empalmes de vigencias de ocupantes con este nombramiento. Es
requerido y se debe teclear (SI/NO). Por default es “NO”.
• Se genera un registro en el archivo de Nombramientos -NNOM_T y se graban los datos capturados y los
siguientes datos:
recsueldo = “NO”
fecha-alta
usuario
term
BAJA.
•Se selecciona el nombramiento a dar de baja. - nom.
• Se despliegan los datos del nombramiento:
nom
nom -desc
scatuaslp
facsdo
jorm
sind
tbsep
tbuasl
tipoant
tipopla
nivaca
pdifjor
tabpanti
Para una baja lógica en el archivo de Nombramientos:
• Se valida que NO exista una plaza activa con vigencias mayores a la fecha de baja, en el archivo PLAZAS
con el nom (nombramiento) a dar de baja.
• Se valida que NO exista un ocupante activo con las vigencias mayores a la fecha de baja, en el archivo
OCUPANTES con el nombramiento - nom a dar de baja.
•Se valida que NO exista una percepción Fija activa en el archivo de PERCEPCIONES -FIJAS con el
nombramiento a dar de baja.
Se graba la fecha de la baja en el registro del nombramiento a dar de baja y el usuario que realiza la baja,
NNOM_T.fecha-baja = today
NNOM_T.usuario = usuario que realiza la baja.
NNOM_T.term = terminal en donde se realia la baja.
MODIFICACION.
• Se selecciona el nombramiento a modificar- nom .
• Se Despliegan todos los datos del registro.
• Se permite modificar los siguientes datos, si el nombramiento No tiene fecha de baja:
nom
nom -desc
nom _desco
scatuaslp
facsdo
jorm
sind
tbsep
tbuasl
tipoant
tipopla
nivaca
pdifjor
tabpanti
term
perm_oc_plaza_evol
perm_empalme_oc
con las validaciones especificadas en la alta para cada uno de los campos.
Si se modifica alguno de los siguientes datos se debe actualizar el dato de recalculo de sueldo - recsueldo = “SI”:
scatuaslp - Sub. Categoria UASLP
facsdo
- Factor de Sueldo
tbuaslp - Tabulador de UASLP
tipoant - Tipo de Antiguedad
tipopla - Tipo de plaza
nivaca - Nivel Académico
tabpanti - Tabulador por premio por antigüedad
En la modificación se actualizan los datos modificados en el registro y se actualizan los siguientes datos:
fecha-usu = today
usuario = usuario que realiza la modificación.
Term = No. estación de trabajo en donde se realiza la modificación.
1.14. EMPLEADOS.
Universidad Autónoma de San Luis Potosí
Sistema de Plazas
RPE
_______
_______
_______
_______
_______
_______
_______
Alta
Baja
Fecha: 17/05/1999
Programa: N__________
Nombre
___________________________
___________________________
___________________________
___________________________
ABC Empleados.
___________________________
___________________________
___________________________
Modificar
Consulta
Reporte
RPE: _____
Nombre: __________________________________
Apellido Matern o: __________________
Apellido Paterno : _________________
Alta Empleados.
Nombres: __________________________
RFC: _____________
Sexo : __ (F/M)
Grupo y Factor Sanguineo: __ ___*_______
Consecutivo de Credencial: __*_____
Fecha Nacimiento: __/__/__*__
Localidad Nacimiento: ____ ______*______________
Municipio Nacimiento: ____ ______*______________
Estado de Nacimiento: ____ ______*______________
Pais de Nacimiento: ____ ______*______________
Nacionalidad : ____ ______*______________
Fecha Defunción: __/__/____
C.U.R.P:
Salir.
BAJA.
•Se selecciona el RPE a dar de baja -rpe - Registro Personal Empleado.
• Se despliegan los datos del Empleado.
Para una baja lógica:
Debe existir al menos un registro en el archivo PLAZAS con el rpe a dar de baja.
Debe existir al menos un registro en el archivo OCUPANTES con el rpe a dar de baja.
Se graban los siguientes datos en el registro de baja lógica:
fecha_usu
usuario
term
MODIFICACION.
Se selecciona el empleado a dar de baja.
• Se Despliegan todos los datos del registro.
• Se permite modificar los siguientes datos con las validaciones de la alta:
nombre
facsan
apellmat
curp
apellpat
fecha_nac
nombres
fecdefun
rfc
localidad_nac
sexo
mpio_nac
grusan
edo_nac
pais_nac
nacionalidad
Se actualizan los datos modificados en el archivo NEMP_T y se graban los siguientes datos de actualización:
fecha-usu
usuario
term
2. CONTROL DE PLAZAS.
2.1. PLAZAS UASLP.
2.1.1. CREACION DE PLAZAS.
Universidad Autónoma de San Luis Potosí
Sistema de Plazas
Fecha: 17/05/1999
Programa: N__________
Creación de Plazas.
Plaza: ___*___
Sub-U. Organizacional : ____ _______*_____________
Edo. Plaza: ____ __________*_____________
U. Organizacional : _*___ _______*_____________
Nombramiento: ____ ______*_____________
Vigencia Inicial : __/__/____
Vigencia Final : __/__/____
RPE titualar : ____ _______*_____________
Tipo Periodo: ____ _______*________
Sub.Sub.Fondo: ____ ________*____________
Sub.Fondo: __*__ _______*____________
Origen del Recurso: __*__ _______*____________
Nivel: ____ _______*_____________
Jornada Semanal: ____ _______*_____________
Sueldo Base: ______*_______
Premio por Nivel: ______*_______
Premio por Antigüedad: ______*_______
Motivo Creación u Origen: ____ _________*___________
Fecha Creación : __/__/____
Perfil de la Plaza: ______ ________*__________
Se crea la plaza con los datos capturados SI/NO?
Se despliega el No. De la plaza, y el usuario podrá registrar una nueva plaza tecleando <Enter>.
<Enter> para continuar
Si se captura un tipo de periodo. Se tendrán que capturar los periodos para el tipo de periodo en la siguiente
forma:
No. Periodo
Descripción
___
_____________________________
___
_____________________________
___
_____________________________
___
_____________________________
Alta
Baja
Salir
Cuando el Motivo de Creación o alta de la plaza actual dice que la plaza se debe relacionar con otra u otras plazas
que dieron origen a la misma (NMOVALT_T.relplaza = “SI”), se requerirán los siguientes datos para registrar las
plazas que se fusionaron, fraccionaron, redistribuyeron, etc. para dar origen a la plaza actual.
Plazas Origen.
Cve. Plaza Ori.
Fus/Fracc./Red.
_____
_____
_____
_____
_____
_____
_____
SUOrg.
_*__
_*__
_*__
_*__
_*__
_*__
_*__
Nom
_*___
_*___
_*___
_*___
_*___
_*___
_*___
Nivel
_*___
_*___
_*___
_*___
_*___
_*___
_*___
Alta
Baja
Edo.Plaza
__*___
__*___
__*___
__*___
__*___
__*___
__*___
Cau.Mov.
Descr.
___*__ ____*_____
___*__ ____*_____
___*__ ____*_____
___*__ ____*_____
___*__ ____*_____
___*__ ____*_____
___*__ ____*_____
Salir
Plaza Relacionada por el Estado de la Plaza.
Plaza : ____
Fecha Creación: __/__/__*__
RPE Titular: __*__ ____________*___________________
Estado: __*__ ____________*___________________
2.1. PLAZAS UASLP.
2.1.1. CREACION DE PLAZAS.
•Se captura suorga - Sub.Unidad Organizacional de la plaza. Se valida su existencia en la tabla NSUORGA_T
sin fecha de baja. Se debe proporcionar una ayuda del catalogo de departamentos para este campo.
Este dato es requerido. Si la sub. Unidad organizacional NO tiene plaza (NSUORGA_T.tiene_pla = “NO”), NO se
permite el departamento.
•Se despliega uorga - Unidad Organizacional de la que depende el departamento de la Plaza. Se obtiene del
registro de la sub. Unidad Organizacional capturada, de la tabla NSUORGA_T del campo NSUORGA_T.uorga.
La descripción se obtiene del archivo (NUORGA_T) y se accesa por medio del campo NSUORGA_T.uorga.
•Se captura nom - Nombramiento de la plaza. Se valida su existencia en la tabla NNOM_T sin fecha de baja.
Se debe proporcionar una ayuda del catalogo de Nombramientos para este campo (browse del catalogo).
Este dato es requerido.
• Se captura Rpe-titular - RPE del titular. NO es un dato requerido si se captura, Se valida su existencia en la
tabla NEMP_T. Se debe proporcionar una ayuda del catalogo de Empleados para este campo (browse del catalogo).
Si la persona a darse de alta como titular, esta en la tabla de liquidados Totales y el motivo de la liquidación
tiene restriccion para reingreso (NMOTLIQ_T.restricc = “SI” ), NO se permite como titular de una plaza.
(El Archivo de liquidados esta en NLIQUIDA_M y se accesa por RPE).
•Se captura ssubfondo -Sub. Sub.Fondo de la Plaza. Es requerido y se valida su existencia en la tabla NSSFONDOS_T
sin fecha de baja. Se debe proporcionar una ayuda del catalogo de Sub.Sub.Fondos para este campo (browse del catalogo).
•Se despliega subfondo -Sub. Fondo y su descripción. (Archivo: NSFONDO_T).
•Se despliega origen - Origen del recurso y su descripción. (Archivo: NORIREC_T).
•Se captura nivel - Nivel de la plaza. Es requerido y se valida su existencia en la tabla de NNIV_T sin fecha de
baja . Se debe proporcionar una ayuda del catalogo de Niveles para este campo. Solo se permiten Niveles
tabulados, esto es, si el nivel es un nivel tabulado (NNIV_T.niv_tabul = “SI”), se debe validar que exista un registro
en el archivo NTABNIV_D el cual se accesa por Nivel - tbuasl (Nivel y tabulador de la Universidad el cual se tiene
en el archivo de Nombramientos - NNOM_T.tbuasl). Para validar lo anterior se debe correr la rutina de “Validación
de tabuladores de Nivel”.
Parametros de Entrada: (nom,nivel) , paramentros de salida: (existe).
•Se captura jorsem - Jornada Semanal de la Plaza. Es requerida y el rango es de 1.00 a 48.00, las fracciones serán
decimales, 30 minutos serán .30 en el sistema, 15 serán 0.15, etc.
* Existe una validación pendiente para este dato, dependiendo de lo definido por R.H.
Una vez capturada la jornada semanal se realizará el calculo del sueldo base, premio por nivel y premio por
antigüedad:
Se ejecuta la rutinas:
“CALCULO DE SUELDO BASE Y PREMIO POR NIVEL”
Parámetros de Entrada :
nom - nombramiento
nivel - nivel
jorsem - jornada semanal
Parámetros de salida:
sueldo_base
premio x nivel
GLOSARIO
AI Artificial Intelligence
Inteligencia artificial. Parte de la informática que
estudia la simulación de la inteligencia.
ACK Acknowledgment
Reconocimiento. Señal de respuesta
ADSL Asymmetric Digital
Línea digital asimétrica de abonado. Sistema
Subscriber Line
asimétrico de transmisión de datos sobre líneas
telefónicas convencionales. Existen sistemas en
funcionamiento que alcanzan velocidades de 1,5 y 6
Megabytes por segundo en un sentido y entre 16 y
576 Kilobytes en el otro
ANSI American National
Instituto Nacional Americano de Estándar.
Standard Institute
API Aplication Program
Interfaces de aplicación del programa. Es el conjunto
Interface.
de rutinas del sistema que se pueden usar en un
programa para la gestión de entrada/salida, gestión
de ficheros etc.
APPLET
Aplicación escrita en JAVA y compilada.
ARPANET Advanced Research Red de la Agencia de Proyectos de Investigación
Projects Agency Network.
Avanzada. Red militar norteamericana a través de
líneas telefónicas de la que posteriormente derivó
Internet.
ASAP As Soon As Possible.
Tan pronto como sea posible. Mandato u opción en
una red o programa que determina la prioridad de
una tarea.
ASCII American Standard
Estándar
americano
para
intercambio
de
Code for Information
información. La tabla básica de caracteres ASCII
Interchange.
está compuesta por 128 caracteres incluyendo
símbolos y caracteres de control. Existe una versión
extendida de 256.
ASN Autonomus System
Número de sistema autónomo. Grupo de Routers y
Number.
redes
controlados
por
una
única
autoridad
administrativa.
ATM Asyncronous Transmision Modo
Mode.
de
transmisión
asíncrona.
Sistema
de
transmisión de datos usado en banda ancha para
aprovechar al máximo la capacidad de una línea. Se
trata de un sistema de conmutación de paquetes que
soporta velocidades de hasta 1,2 Gbps.
AUI
Asociación de usuarios de Internet. Avatar identidad
representada gráficamente que adopta un usuario
que se conecta a un CHAT con capacidades
gráficas.
BBS Bulletin Board System.
Tablero
de
anuncios
electrónico.
Servidor
de
comunicaciones que proporciona a los usuarios
servicios variados como e-mail o transferencia de
ficheros. Originalmente funcionaban a través de
líneas telefónicas normales, en la actualidad se
pueden encontrar también en Internet.
Bandwith Ancho de Banda.
Capacidad de un medio de transmisión.
BIOS Basic Input Output
Sistema
System.
residente normalmente en Eprom que controla las
básico
de
entrada/salida.
Programa
iteraciones básicas entre el hardware y el Software.
BIT Binary Digit. Dígito Binario. Unidad mínima de información, puede tener dos
estados "0" o "1".
BOOTP Bootstrap Protocol.
Protocolo de arranque-asignación. Proporciona a
una máquina una dirección IP. Gateway y Netmask.
Usado en comunicaciones a través de línea
telefónica.
BOT Automatismo.
Programa o script que realiza funciones que de otra
manera habría que hacer de forma manual.
Backbone.
Estructura de transmisión de datos de una red o
conjunto
de
ellas
en
Internet.
Literalmente:
"esqueleto"
Ban Prohibir.
Usado normalmente en IRC. Acto de prohibir la
entrada de un usuario "NICK" a un canal.
Baudio Unidad de medida.
Número de cambios de estado de una señal por
segundo.
Bounce Rebote.
Devolución de un mensaje de correo electrónico
debido
a
destinatario.
problemas
para
entregarlo
a
su
Browser.
Término aplicado normalmente a los programas que
permiten acceder al servicio WWW.
Bookmark Marca.
Anotación normalmente de una dirección WWW o
URL que queda archivada para su posterior uso.
CCIIT International
Comité Consultivo de Telegrafía y Telefonía.
Consultative Committee on
Organización que establece estándares
Telegraphy and Telephony.
internacionales sobre telecomunicaciones.
CD Compact Disc.
Disco compacto. Disco óptico de 12 cm de diámetro
para
almacenamiento
binario.
Su
capacidad
"formateado" es de 660 Mb. Usado en principio para
almacenar
audio.
Cuando
se
usa
para
almacenamiento de datos genéricos es llamado CDROM.
CDA Comunications Decency
Proyecto de ley americano que pretendía a ejercer
Act. Acta de decencia en las
una especie de censura sobre Internet. Por el
Telecomunicaciones.
momento ha sido declarado anticonstitucional.
CERN Conseil Europeen pour
Consejo Europeo para la Investigación Nuclear.
la Recherche Nucleaire.
Institución
europea
que
desarrolló,
para
sus
necesidades internas, el primer navegador y el
primer servidor WWW. Y por tanto el HTTP. Ha
contribuido decisivamente a la difusión de esta
tecnología y es uno de los rectores del W3
Consortium
CERT Computer Emergency
Response Team.
Equipo de respuesta a emergencias informáticas.
CG Computer Graphics.
Gráficos de ordenador.
CGI Common Gateway
Interface de Acceso Común. Programas usados para
Interface.
hacer llamadas a rutinas o controlar otros programas
o bases de datos desde una página Web. También
pueden generar directamente HTML.
CHAT Charla.
Ver IRC.
CIR Commited Information
Es el caudal mínimo de información que garantiza el
Rate.
operador telefónico al usuario (normalmente el
proveedor de acceso) el resto del ancho de banda
está pues sujeto al estado de la red y las
necesidades del operador telefónico.
CIX Comercial Internet
Intercambio Comercial Internet.
Exchange.
COOKIE
Pequeño trozo de datos que entrega el programa
servidor de HTTP al navegado WWW para que éste
lo guarde. Normalmente se trata de información
sobre la conexión o los datos requeridos, de esta
manera puede saber qué hizo el usuario en la última
visita.
CSIC Centro Superior de
El
organismo
público
encargado
Investigaciones Científicas.
investigaciones científicas en España.
de
las
CSLIP Compressed Serial Line Es una versión mejorada del SLIP desarrollada por
Protocol. Protocolo de Línea
Van Jacobson. Principalmente se trata de en lugar
Serie Comprimido.
de enviar las cabeceras completas de los paquetes
enviar solo las diferencias.
CSMA Carrier Sense Multiple
Acceso
múltiple
por
detección
de
portadora.
Access.
Protocolo de Red para compartir un canal. Antes de
transmitir la estación emisora comprueba si el canal
está libre.
Callback
Sistema muy empleado en EE. UU. para llamadas
internacionales consistente en ( previo abono) llamar
a un Tlf. Indicar el número con el que queremos
contactar y colgar. Posteriormente se recibe una
llamada que nos comunica con el número deseado.
Carrier
Operador de telefonía que proporciona conexión a
Internet a alto nivel.
Caudal
Cantidad de ocupación en un ancho de banda. Ej.
En una línea de 1Mbps. puede haber un caudal de
256Kbps. con lo que los 768Kbps. restantes del
ancho de banda permanecen desocupados.
Cracker
Individuo con amplios conocimientos informáticos
que desprotege/piratea programas o produce daños
en sistemas o redes. DATAGRAM Datagrama.
Usualmente se refiere a la estructura interna de un
paquete de datos.
DCD Data Carrier Detected.
Detectada portadora de datos.
DDE Dynamic Data Exchange.
Intercambio
dinámico
de
datos.
Conjunto
de
especificaciones de microsoft para el intercambio de
datos y control de flujo entre aplicaciones.
DES Data Encryption Standard. Algoritmo de encriptación de estándar. Algoritmo
desarrollado por IBM, utiliza bloques de datos de 64
bits y una clave de 56 bits. Es utilizado por el
gobierno americano.
DNS Domain Name System.
Sistema de nombres de dominio. Base de datos
distribuida que gestiona la conversión de direcciones
de Internet expresadas en lenguaje natural a una
dirección numérica IP. Ejemplo: 121.120.10.1
DSP Digital Signal Procesor.
Procesador digital de señal.
DSR Data Set Ready
(MODEM).
DTE Data Terminal Equipment. Equipo terminal de datos. Se refiere por ejemplo al
ordenador conectado a un modem que recibe datos
de éste.
DTMF Dual Tone
Multifrecuencia de doble tono. Son los tonos que se
Multifrecuency.
utilizan en telefonía para marcar un número
telefónico.
DTR Data Transfer Ready.
Preparado para transmitir datos (MODEM).
DUPLEX
Capacidad de un dispositivo para operar de dos
maneras.
En
comunicaciones
se
refiere
normalmente a la capacidad de un dispositivo para
recibir/transmitir. Existen dos modalidades HALFDUPLEX:
Cuando
puede
recibir
y
transmitir
alternativamente y FULL-DUPLEX cuando puede
hacer ambas cosas simultáneamente.
DVB Digital Vídeo Broadcast.
Vídeo digital para emisión. Formato de vídeo digital
que cumple los requisitos para ser considerado
Broadcast, es decir, con calidad para ser emitido en
cualquiera de los sistemas de televisión existentes.
DVD Digital Vídeo Disk.
Nuevo estándar en dispositivos de almacenamiento
masivo con formato de CD pero que llega a 14 GB
de capacidad.
Dialup Marcar.
Establecer una conexión de datos a través de una
línea telefónica.
Domain Dominio.
Sistema de denominación de Hosts en Internet. Los
dominios
van
separados
por
un
punto
y
jerárquicamente están organizados de derecha a
izquierda. ejem: sep.gob.mx
Download
Literalmente "bajar carga". Se refiere al acto de
transferir un fichero/s desde un servidor a nuestro
ordenador. En español: bajarse un programa.
DownStream
Flujo de datos de un ordenador remoto al nuestro.
EBCDIC Extended Bynary
Código extendido de binario codificado decimal.
Coded Decimal Interchange
Sistema mejorado de empaquetamiento de números
Code.
decimales en sistema binario.
ECC Error Checking and
Chequeo y corrección de errores.
Correction
.
EFF Electronic Frontier
Fundación Frontera Electrónica. Organización para
Foundation.
la defensa de los derechos en el cyberespacio.
EDI Electronical Data
Intercambio electrónico de datos.
Interchange.
ETSI European
Instituto
Europeo
Telecommunication Standars
Telecomunicaciones.
de
Estándares
en
Intitute
.
E-ZINE Electronic Magazine.
Revista electrónica. Cualquier revista producida para
su difusión por medios informáticos, principalmente
por Internet.
E-mail Electronic Mail.
Correo
electrónico.
Sistema
de
mensajería
informática similar en muchos aspectos al correo
ordinario pero muchísimo más rápido.
FAQ Frecuent Asked Question. Preguntas formuladas frecuentemente. Las FAQs de
un sistema son archivos con las preguntas y
respuestas más habituales sobre el mismo.
FAT File Allocation Table.
Tabla de localización de ficheros. Sistema de
organización de ficheros en discos duros. Muy usado
en PC.
FDDI Fiber Digital Device
Dispositivo Interface de fibra (óptica) digital.
Interface.
Finger
Literalmente "dedo". Facilidad que permite averiguar
información básica sobre usuarios de Internet o Unix.
FIX Federal Interagency
Interagencia federal de Intercambio.
Exchange.
FTP File Transfer Protocol.
Protocolo de transferencia de ficheros. Uno de los
protocolos de transferencia de ficheros más usado
en Internet.
Firewall
Literalmente " muro de fuego". Se trata de cualquier
programa que protege a una red de otra red. El
firewall da acceso a una máquina en una red local a
Internet pero Internet no ve más allá del firewall.
Frame Estructura.
También trama de datos. En Browsers de WWW
como Netscape se refiere a una estructura de subventanas dentro de un documento HTML.
Frame Relay
Protocolo
de
enlace
mediante
circuito
virtual
permanente muy usado para dar conexión directa a
Internet.
GIF Graphics Interchange
Formato gráfico de intercambio.
Format.
GIX Global Internet Exchange.
Intercambio global Internet.
GMT Greenwich Mean Time.
Hora de referencia de Greenwich. Equivalente a UT.
GSM Global System Mobile
Sistema global de comunicaciones móviles. Sistema
comunications.
digital de telecomunicaciones principalmente usado
para telefonía móvil. Existe compatibilidad entre
redes por tanto un teléfono GSM puede funcionar
teóricamente en todo el mundo. En EE.UU. está
situado en la banda de los 1900MHZ y es llamado
DCS-1900.
GT Global Time.
Tiempo global. Sistema horario de referencia en
Internet.
GUI Graphic User Interface.
Interface gráfico de usuario.
Gateway Puerta de Acceso.
Dispositivo que permite conectar entre sí dos redes
normalmente de distinto protocolo o un Host a una
red. En español: pasarela.
HDLC High-Level Data Link
Control de enlace de datos de alto nivel.
Control.
HDSL Hight bit rate Digital
Línea digital de abonado de alta velocidad. Sistema
Subscriber Line.
de transmisión de datos de alta velocidad que utiliza
dos pares trenzados. Se consiguen velocidades
superiores al Megabit en ambos sentidos.
Header Cabecera.
Primera parte de un paquete de datos que contiene
información sobre las características de éste.
Hit
Literalmente "golpe". Se usa para referirse cada vez
que un link es pulsado en una página WEB.
Homepage
Página principal o inicial de un sitio WEB.
HPFS High Performance File
Sistema de archivos de alto rendimiento. Sistema
System.
que utiliza el OS/2 opcionalmente para organizar el
disco duro en lugar del habitual de FAT.
HTML HyperText Markup
Lenguaje de marcas de hypertexto. Lenguaje para
Language.
elaborar pagina Web actualmente se encuentra en
su versión 3. Fue desarrollado en el CERN (gracias
a él ves esta página).
HTTP HyperText Transfer
Protocolo de transferencia de hypertexto. Protocolo
Protocol.
usado en WWW.
Hacker
Experto en informática capaz de entrar en sistemas
cuyo acceso es restringido. No necesariamente con
malas intenciones.
Hayes
Norma desarrollada por el fabricante Hayes para el
control de modems mediante comandos.
Host
Ordenador conectado a Internet. Ordenador en
general. Literalmente anfitrión.
IANA Internet Assigned
Autoridad de asignación de números en Internet. Se
Number Authority.
trata de la entidad que gestiona la asignación de
direcciones IP en Internet.
ICMP Internet Control Message Protocolo Internet de control de mensajes.
Protocol.
IEEE Institute of Electrical and
Instituto de Ingenieros Eléctricos y Electrónicos.
Electronics Engineers.
Asociación norteamericana.
IETF Internet Engineering Task Grupo
Force.
de
Tareas
de
Ingeniería
de
Internet.
Asociación de técnicos que organizan las tareas de
ingeniería principalmente de telecomunicaciones en
Internet. Por ejemplo: mejorar protocolos o declarar
obsoletos otros.
INTA Instituto Nacional de
Como la NASA pero español.
Técnica Aeroespacial.
INTERNIC
Entidad administrativa de Internet que se encarga de
gestionar los nombres de dominio en EE.UU.
INTRANET
Se llaman así a las redes tipo Internet pero que son
de uso interno, por ejemplo, la red corporativa de
una institución que utilizará protocolo TCP/IP y
servicios similares como WWW.
IP Internet Protocol.
Protocolo de Internet. Bajo éste se agrupan los
protocolos de Internet. También se refiere a las
direcciones de red Internet.
IPI Intelligent Peripheral
Interface inteligente de periféricos. En ATM: Initial
Interface.
Protocol Identifier. Identificador inicial de protocolo.
IPX Internet Packet Exchange.
Intercambio de paquetes entre redes. Inicialmente
protocolo
de
Novell
para
el
intercambio
de
información entre aplicaciones en una red Netware.
IRC Internet Relay Chat.
Canal de Chat de Internet. Sistema para transmisión
de texto multiusuario a través de un servidor IRC.
Usado normalmente para conversar on-line también
sirve para transmitir ficheros.
ISDN Integrated Services
Red Digital de Servicios Integrados. En español
Digital Network.
RDSI.
ISO International Standard
Organización Internacional de Standard.
Organization.
ISP Internet Service Provider.
Proveedor de servicios Internet.
ISS Internet Security Scanner.
Rastreador de seguridad de Internet. Programa que
busca puntos vulnerables de la red con relación a la
seguridad.
Ibernet
Red española gestionada por telefonía con protocolo
IP. Es la subred Internet española.
Iberpac
Red telefónica para la transmisión de datos en forma
de paquetes, (normalmente en X-25) principalmente
de uso corporativo.
InterDic
El diccionario de Internet en español en la Web.
JAVA
Lenguaje de programación orientado a objeto
parecido al C++. Usado en WWW para la telecarga y
telejecución de programas en el ordenador usuario.
Desarrollado por Sun microsystems.
JAVASCRIPT
Programa escrito en el lenguaje script de Java que
es
interpretado
por
la
aplicación
usuario,
normalmente un navegador (Browser).
JPEG Join Photograph Expert
Unión de grupo de expertos fotográficos. Formato
Group.
gráfico con pérdidas que consigue elevados ratios de
compresión.
Kick "Patada".
Usado normalmente en IRC. Acto de echar a un
usuario de un canal.
Knowbot
Robot de conocimiento o robot virtual. Se trata de un
tipo de PDA.
LAN Local Area Network.
Red de área local. Red de ordenadores de reducidas
dimensiones. Por ejemplo una red distribuida en una
planta de un edificio.
LAPM Link Access Procedure
Procedimiento de acceso a enlace para modems.
for Modems.
LCP Link Control Protocol.
Protocolo de control de enlace.
Layer Capa.
En protocolos o en OSI se refiere a los distintos
niveles de estructura de paquete o de enlace
respectivamente.
Link Enlace.
Unión. Se llama así a las partes de una página WEB
que nos llevan a otra parte de la misma o nos enlaza
con otro servidor.
Linux Versión Shareware del
Es un sistema multitarea multiusuario de 32 bits para
conocido systema operativo
PC.
Unix.
LU Logic Unit.
Unidad lógica.
Lock Cerrado.
Bloqueado.
MAN Metropolitan Area
Red de área metropolitana.
Network.
MBONE Multicast Backbone.
Red virtual que utiliza los mismos dispositivos físicos
que la propia Internet con objeto de transmitir datos
con protocolos Multicast.
MIME Multipurpouse Internet
Extensiones
multipropósito
de
correo
Internet.
Mail Extensions.
Extensiones del protocolo de correo de Internet que
permiten incluir información adicional al simple texto.
MMX Multi Media Extensions.
Extensiones multimedia. Juego de instrucciones
extra que incorporan los nuevos microprocesadores
Pentium orientado a conseguir una mayor velocidad
de ejecución de aplicaciones que procesan o
mueven grandes bloques de datos.
MNP Microcom Networking
Protocolo de redes de Microcom. Protocolo de
Protocol.
corrección de errores desarrollado por Microcom
muy usado en comunicaciones con modem. Existen
varios niveles MNP2(asíncrono), MNP3(síncrono) y
MNP4(síncrono).
MODEM
Modulador/demodulador. Dispositivo que adapta las
Modulator/Demodulator.
señales digitales para su transmisión a través de una
línea analógica. Normalmente telefónica.
MPEG Motion Pictures Expert
Grupo de expertos en imagen en movimiento.
Group.
Formato gráfico de almacenamiento de vídeo. Utiliza
como el JPEG compresión con pérdidas alcanzando
ratios muy altos.
MROUTER Multicast Router.
Router que soporta protocolos Multicasting.
MRU Maximum Receive Unit.
Unidad máxima de recepción. En algunos protocolos
de Internet se refiere al máximo tamaño del paquete
de datos.
MS-DOS Microsoft Disk
Sistema operativo en disco de Microsoft. Sistema
Operating System.
operativo muy extendido en PC del tipo de línea de
comandos.
MTU Maximum Transmission
Unidad máxima de transmisión. Tamaño máximo de
Unit.
paquete en protocolos IP como el SLIP.
MUD Multi User Dimension.
Dimensión multi
usuario.
Sistemas
de
juegos
multiusuario de Internet.
MULTICASTING
Técnica de transmisión de datos a través de Internet
en la que se envían paquetes desde un punto a
varios simultáneamente.
NACR Network Announcement Petición de participación en la red. Es la petición de
Request.
alta en Internet para una subred o dominio.
NAP Network Access Point.
Punto de acceso a la red. Normalmente se refiere a
los tres puntos principales por los que se accede a la
red Internet en U.S.
NC Network Computer.
Ordenador de red. Ordenador concebido para
funcionar conectado a Internet. Según muchos el
futuro. Se trata de equipos de hardware muy
reducido (algunos no tienen ni disco duro).
NCP Network Control Protocol. Protocolo de control de red. Es un protocolo del
Network Layer
NET
Red
NETBIOS Network BIOS.
Bios de una red, es decir, Sistema básico de
Network Basic Input/Output
entrada/salida de red.
System.
Netiquette
Etiqueta de la RED. Formas y usos comunes para el
uso de los servicios de Internet. Se podría llamar la
educación de los usuarios de Internet.
NSA National Security Agency. Agencia
Nacional
de
Seguridad.
Organismo
americano para la seguridad entre otras cosas
informática.
NSF National Science
Fundación
Nacional
de
Ciencia.
Fundación
Fundation.
americana que gestiona gran parte de los recursos
de Internet.
Navegador
Aplicado normalmente a programas usados para
conectarse al servicio WWW.
Netizen
Ciudadano de la red.
NEWS Noticias.
Servicio de Internet con una estructura de tablón de
anuncios dividido en temas y piases en los que los
usuarios de determinados grupos de interés dejan o
responden
a
mensajes
relacionados
con
el
mencionado grupo.
Nick
Nombre o seudónimo que utiliza un usuario de IRC.
Nodo
Por definición punto donde convergen más de dos
líneas. A veces se refiere a una única máquina en
Internet. Normalmente se refiere a un punto de
confluencia en una red.
OEM Original Equipament
Manufactura de equipo original. Institución que
Manufactured.
compra un producto a un fabricante y lo integra en
un producto propio. Todos los fabricantes por
ejemplo, que incluyen un Pentium en su equipo
actúan como OEM.
OS2 Operating System 2.
Sistema operativo de 32 bits multitarea creado por
IBM. Creado para PC con entorno gráfico de usuario.
La versión actual es la 4 la cual soporta órdenes
habladas y dictado.
OSI Open Systems
Interconexión de sistemas abiertos. Modelo de
Interconnection.
referencia de interconexión de sistemas abiertos
propuesto por la ISO. Divide las tareas de la red en
siete niveles.
PAN Personal Area Network.
Red de área personal. Sistema de red conectado
directamente a la piel. La transmisión de datos se
realiza por contacto físico.
PAP Password Authentication
Protocolo de autentificación por password. Protocolo
Protocol.
que permite al sistema verificar la identidad del otro
punto de la conexión mediante password.
PEER
En una conexión punto a punto se refiere a cada uno
de los extremos.
PEM Private Enhanced Mail.
Correo privado mejorado. Sistema de correo con
encriptación.
PERL
Lenguaje para manipular textos, ficheros y procesos.
Con estructura de scrip. Desarrollado por Larry Wall,
es multiplataforma ya que funciona en Unix.
PGP Pretty Good Privacity.
Paquete de encriptación basado en clave pública
escrito por Phil Zimmerman.
PIN Personal Identification
Número personal de identificación. Número secreto
Number.
asociado a una persona o usuario de un servicio
mediante el cual se accede al mismo. Se podría
decir que es una password numérica.
PING Packet Internet Gorree.
Rastreador de paquetes Internet. Programa utilizado
para comprobar si un Host está disponible. Envía
paquetes de control para comprobar si el host está
activo y los devuelve.
PNG Portable Network
Gráficos portables de red. Formato gráfico muy
Graphics.
completo especialmente pensado para redes.
POP Post Office Protocol.
Protocolo de oficina de correos. Protocolo usado por
ordenadores personales para manejar el correo
sobre todo en recepción.
POST Power On Self Test.
Serie de comprobaciones que hace un ordenador de
AutoTest de Encendido.
sus dispositivos al ser encendido.
POTS Plain Old Telephone
Servicios telefónicos planos antiguos.
Services.
PPP Point to Point Protocol.
Protocolo punto a punto. Protocolo Internet para
establecer el enlace entre dos puntos.
PPV Pay Per View.
Pagar para ver. Se refiere a las televisiones
llamadas interactivas o televisión a la carta en las
que hay que pagar por cada programa que se
selecciona para ver.
PROXY Servidor Cache.
El proxy es un servidor que conectado normalmente
al servidor de acceso a la WWW de un proveedor de
acceso va almacenando toda la información que los
usuarios reciben de la WEB, por tanto, si otro
usuario accede a través del proxy a un sitio
previamente visitado, recibirá la información del
servidor proxy en lugar del servidor real.
PU Physical Unit.
Unidad física.
PUNTO NEUTRO
Punto de enlace de todos los proveedores de acceso
y conexión a Internet en España. Con este nuevo
nodo todas las conexiones entre hostes españoles
se harán sin que los paquetes tengan que salir del
territorio nacional.
PVC Permanent Virtual Circuit. Circuito virtual permanente. Línea punto a punto
virtual
establecida
normalmente
mediante
conmutaciones de carácter permanente. Es decir a
través de un circuito establecido.
Packet Driver
Pequeño programa situado entre la tarjeta de red y
el programa de TCP de manera que proporciona una
interface estándar que los programas pueden usar
como si se tratase de un driver.
Paquete
Cantidad mínima de datos que se transmite en una
red o entre dispositivos. Tiene una estructura y
longitud
distinta
según
el
protocolo
al
que
pertenezca. También llamado TRAMA.
Phracker
Pirata informático que se vale de las redes
telefónicas para acceder a otros sistemas o
simplemente para no pagar teléfono.
Proveedor de Acceso
Centro servidor que da acceso lógico a Internet, es
decir sirve de pasarela (Gateway) entre el usuario
final e Internet.
Proveedor de Conexión
Entidad que proporciona y gestiona enlace físico a
Internet. Por ejemplo telefónica.
QAM Quadrature Amplitude
Modulación de amplitud en cuadratura. Sistema de
Modulation.
modulación
para
transmisión
de
datos
y
telecomunicaciones.
RARP Reverse Address
Protocolo de resolución de dirección de retorno.
Resolution Protocol.
Protocolo de bajo nivel para la asignación de
direcciones IP a máquina simples desde un servidor
en una red física.
RAS Remote Access Server.
Servidor de acceso remoto.
RDSI Red Digital de Servicios
Red de telefónica con anchos de banda desde
Integrados.
64Kbps. Similar a la red telefónica de voz en cuanto
a necesidades de instalación de cara al abonado,
pero digital. En inglés ISDN.
RFC Request For Comment.
Petición de comentarios. Serie de documentos
iniciada en 1967 que describe el conjunto de
protocolos de Internet. Los RFC son elaborados por
la comunidad Internet.
RIP Routing Information
Protocolo de información de routing.
Protocol.
ROOT Raíz.
En sistemas de ficheros se refiere al directorio raíz.
En Unix se refiere al usuario principal.
RSA Rivest, Shamir, Adelman
Algoritmo
de
encriptación
de
clave
[public key encryption
desarrollado por Rivest, Shamir y Adelman.
pública
algorithm].
RTC Red Telefónica
Red telefónica para la transmisión de voz.
Conmutada.
RTP Real Time Protocol.
Protocolo de tiempo real. Protocolo utilizado para la
transmisión de información en tiempo real como por
ejemplo audio y vídeo en una videoconferencia.
RWIN Receive Window.
Ventana de recepción. Parámetro de TCP que
determina la cantidad máxima de datos que puede
recibir el ordenador que actúa como receptor.
RX
Abreviatura de recepción o recibiendo.
Retrain
Se llama así a la acción que ejecuta un modem para
restablecer el sincronismo con el otro modem
después de una pérdida de comunicación.
Router
Dispositivo conectado a dos o más redes que se
encarga únicamente de tareas de comunicaciones.
SATAN Security Analysis Tool Herramienta de análisis de seguridad para la
for Auditing Networks.
auditoria de redes. Conjunto de programas escritos
por Dan Farmer junto con Wietse Venema para la
detección
de
problemas
relacionados
con
la
seguridad.
SDLC Syncronous Data Link Controlador de enlace de datos síncrono. También
Controller.
se trata de un protocolo para enlace sincrono a
través de línea telefónica.
SDSL
Symmetric
Subscriber Line.
Digital Línea digital simétrica de abonado. Sistema de
transferencia de datos de alta velocidad en líneas
telefónicas normales.
SEPP
Secure
Payment Protocol.
Electronic Protocolo de pago electrónico seguro. Sistema de
pago a través de Internet desarrollado por Netscape
y Mastercard.
SGML Standard Generalized
Lenguaje de anotaciones generales. Lenguaje del
Markup Language.
que deriva el HTML.
SMPT Simple Mail Transfer
Protocolo de transferencia simple de correo. Es el
Protocol.
protocolo usado para transportar el correo a través
de Internet.
SMS Short Message Service.
Servicio de mensajes cortos. Servicio de mensajería
electrónica de texto entre teléfonos GSM. Gracias a
esta capacidad se puede enviar también e-mail
desde un teléfono GSM y recibir mensajes desde
Internet, aunque esta posibilidad parece ser que aún
no funciona en España.
SNA System Network
Arquitectura de sistemas de redes. Arquitectura de
Arquitecture.
red exclusiva de IBM. Principalmente orientada a
Mainframes.
SQL Structured Query
Lenguaje de petición estructurada. Lenguaje para
Language.
base de datos.
SSL Secure Sockets Layer.
Capa de socket segura. Protocolo que ofrece
funciones de seguridad a nivel de la capa de
transporte para TCP.
STT Secure Transaction
Tecnología
de
transacción
segura.
Sistema
Technology.
desarrollado por Microsoft y Visa para el comercio
electrónico en Internet.
Sniffer Literalmente
Pequeño programa que busca una cadena numérica
"Husmeador".
o de caracteres en los paquetes que atraviesan un
nodo con objeto de conseguir alguna información.
Normalmente su uso es ilegal.
Spam / Spammer
Se llama así al bombardeo con correo electrónico, es
decir, mandar grandes cantidades de correo o
mensajes muy largos.
Spider Robot-Web.
Programa que automáticamente recorre la WWW
recogiendo páginas Web y visitando los Links que
éstas contienen.
S-HTTP Secure HTTP.
HTTP
seguro.
Protocolo
HTTP
mejorado
con
funciones de seguridad con clave simétrica.
SIM Single Identification
Modulo simple de identificación. Normalmente se
Module.
refiere a una tarjeta: Tarjeta SIM. Que identifica y a
través de ella da servicio a un usuario, su uso más
común es el de los teléfonos GSM.
SmartCard Tarjeta Inteligente.
Tarjeta del formato estándar de crédito que incorpora
un microchip (EPROM o Microprocesador) que
almacena información y/o la procesa. Por ejemplo
las tarjetas telefónicas (EEPROM) o las tarjetas SIM
de teléfonos móviles (Microprocesador).
TCM
Trellis-Coded Modulation
TCP Transmission Control
Protocolo de control de Transmisión. Uno de los
Protocol.
protocolos mas usados en Internet. Es un protocolo
del Transport Layer.
TELNET Tele Network.
Tele red. Conexión a un host en la que el ordenador
usuario emula un terminal de manera que se
configura como terminal virtual del ordenador
servidor.
TTD Telefónica Transmisión de División de telefónica para la transmisión de datos.
Datos.
TTL Time To Live.
Tiempo de vida. Contador interno que incorporan los
paquetes Multicast y determinan su propagación.
TX
Abreviatura de transmisión o transmitiendo.
Time-out
Parámetro que indica a un programa el tiempo
máximo de espera antes de abortar una tarea o
función. También mensaje de error.
Tunneling
Transporte de paquetes Multicast a través de
dispositivos
multicast
y
se
Routers
unicast.
encuentran
Los
paquetes
encapsulados
como
paquetes normales, de esta manera pueden viajar
por Internet a través de dispositivos que sólo
soportan protocolos unicast.
UDP User Datagram Protocol.
Protocolo de datagrama de usuario. Protocolo
abierto en el que el usuario (programador) define su
propio tipo de paquete.
UNICAST
Se refiere a protocolos o dispositivos que transmiten
los paquetes de datos de una dirección IP a otra
dirección IP.
URL Uniform Resource
Localizador uniforme de recursos. Denominación
Locator.
que no sólo representa una dirección de Internet sino
que apunta a un recurso concreto dentro de esa
dirección.
USB Universal Serial Bus.
Bus serie universal.
UT Universal Time.
Hora universal. Ver GMT.
UUCP Unix to Unix
Protocolo de comunicaciones de Unix a Unix. Uno de
Communication Protocol.
los protocolos que utilizan los sistemas Unix para
comunicarse entre sí.
UNIX
Sistema operativo multitarea, multiusuario. Gran
parte de las características de otros sistemas más
conocidos como MS-DOS están basadas en este
sistema muy extendido para grandes servidores.
Internet no se puede comprender en su totalidad sin
conocer el UNIX, ya que las comunicaciones son
una parte fundamental en UNIX.
VR Virtual Reality.
Realidad virtual.
VRML Virtual Reality Modeling
Lenguaje
Language.
Lenguaje para crear mundos virtuales en la Web.
WAN Wide Area Network.
Red de área extensa.
WINDOWS Pseudo sistema
Más bien se trata de un entorno gráfico con algunas
operativo.
capacidades
para
modelado
multitarea.
de
La
realidad
versión
virtual.
actual
WINDOWS 95 funciona parcialmente a 32 bits.
WWW, WEB o W3 World Wide
Telaraña mundial, para muchos la WWW es Internet,
Web.
para otros es sólo una parte de ésta. Podríamos
decir estrictamente que la WEB es la parte de
Internet a la que accedemos a través del protocolo
HTTP y en consecuencia gracias a Browsers
normalmente gráficos como Netscape.
Wanderer. Robot-Web.
Ver Spider.
Warez Software
Pirata que ha sido desprotegido.
Webcam
Cámara conectada a una página WEB a través de la
cual
los
visitantes
pueden
ver
imágenes
normalmente en directo.
X25
Protocolo de transmisión de datos muy usado en
Iberpac. Establece circuitos virtuales, enlaces y
canales.
ZIP Zone Information Protocol.
Protocolo de información de zona.
BIBLIOGRAFÍA
ANUIES. Tres décadas de políticas de Estado en la Educación Superior, 1998.
F. Korth, Henry; Abraham Silberschatz Hawryszkiewycz, S. Sudarshan Fundamentos de
Bases de Datos 1997.
Mac Connell, Steve. Desarrollo y gestión de proyectos informativos, 1997.
Ruble, David A. Análisis y diseño práctico de sistemas, 2ª. Ed., Simons Schucter
Company.
Senn, James A. Introduction to Systems Analisys and Design. Prentice-Hall, 1986.
Mac Graw-Hill. R. Pressman, 1988.
Yourdon, E. Modern Structured Analysis. Prentice-Hall, 1989.