DR. MIGUEL LIMÓN ROJA S

DRDR. MIGUEL LIMÓN ROJA. MIGUEL LIMÓN ROJA SS

SECRETARIO DE EDUCACIÓN PÚBLICA

DRDR. DANIEL RESENDIZ NÚÑEZ. DANIEL RESENDIZ NÚÑEZ

SUBSECRETARIO DE EDUCACIÓN SUPERIOR E INVESTIGACIÓN CIENTÍFICA

DRDR. EUGENIO CETINA V. EUGENIO CETINA VADILLADILLOO

DIRECTOR GENERAL DE EDUCACIÓN SUPERIOR

MTROMTRO. JOSÉ L. JOSÉ LUIS LEÓN RAMÍREZUIS 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

P R O N A DP R O N A D

Participantes

Universidad Autónoma del Estado de MorelosRodolfo 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 Despachode Consultoría ÍntegraMarcelo Sada Villarreal

Adolfo Salazar VargasDiseñador y programador de

sistemas administrativos

Í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

11

Introducción


Especificaciones técnicas del SIIA

INTRODUCCIÓN

En el marco de las acciones del Plan nacional de desarrollo educativo, tendientes aimpulsar 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 Generalde Educación Superior, a través del Programa para la Normalización de la InformaciónAdministrativa, se ha propuesto la implantación en 34 universidades públicas estatales deun Sistema Integral de Información Administrativa (SIIA); para lograr este cometido haimpulsado la realización de documentos que constituyan una guía a la vez que un parámetropara aquellas instituciones que hoy tienen la tarea de insertar en sus actividades deadministració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 lasuniversidades en la definición, construcción, administración y mantenimiento de un sistemaintegral de información financiero-administrativa que, desarrollado e implantado de acuerdocon las características y necesidades de cada institución, cumpla a la vez con altosniveles de integración, calidad y seguridad.

El propósito fundamental de la definición de los principios conceptuales contenidos eneste documento es establecer una visión clara y sencilla de las actividades implícitas enel proceso de cambio que se pretende fortalecer con la estandarización de la informacióngenerada, básicamente, en las áreas administrativas y financieras en que se apoya elfuncionamiento operativo de las instituciones académicas.

Lo anterior significa que el contenido de este trabajo está dirigido tanto a losdesarrolladores como a los usuarios y administradores del sistema de informaciónnormalizada, de acuerdo con un análisis nacional efectuado en 1995, refleja que no seencuentran en la mayoría de la base de datos instalada en las instituciones de educaciónsuperior un sistema integral de información administrativa, que no fueron anticipadas lasespecificaciones de un sistema de las características requeridas por los diseñadores desistemas, y es la razón de carecer de un sistema de información de este tipo en lasUPES.

Por ello, presenta una conceptualización de los esquemas básicos de funcionamientoadministrativo 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óno conceptualización del SIIA.

El documento consta de cuatro grandes apartados. La primera parte describe losantecedentes del Programa para la Normalización de la Información Administrativa; lasegunda 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 delsistema computacional y por último se incluye un bloque con los anexos y apéndices deldocumento.

12

Programa para la Normalización de la Información Administrativa


Estas especificaciones técnicas para el SIIA son el resultado del trabajo colegiado deun grupo de universidades que, convocadas por el PRONAD, han vertido en él la experienciade cada institución, así como la que han adquirido al desarrollar un sistema de informaciónadministrativa basado en el modelo de la contabilidad de fondos. Las universidadesparticipantes forman un grupo de apoyo especializado tecnológico, el cual se pretendeque brinde asesoría y sea un vínculo entre las universidades para que su conjunto se veabeneficiado y enriquecido con los resultados y aportaciones de las experiencias másavanzadas que cumplen con los criterios que PRONAD ha marcado.

Se trata de que desde una fase temprana en el proyecto, la institución debe determinarcómo esta definición técnica tendrá lugar, ejem.: si se cuenta con la infraestructura paraun eficaz desarrollo o adquirir un sistema que cumpla las necesidades descritas. Estadecisión no sólo debe depender de la conveniencia de tal integración, sino en la habilidadde la institución de manejar el alcance del proyecto en su totalidad y complejidad sobrelas que semejante decisión traería eficazmente.

La integración tiene un costo determinado, por lo cual los sistemas integrados tiendena ser mucho más complejos que los sistemas aislados y, por consiguiente, exige másrecursos para diseñar, desarrollar y apoyar. Esto, agregado a la complejidad natural, tambiénpuede hacerlo más difícil al emigrar o personalizar sistemas ya existentes y adoptararquitectura de tecnología en el futuro.

Los sistemas financieros flexibles deben ser capaces de proporcionar los mediosasociados a un nivel apropiado de integración, por ejemplo, cuando las instituciones alhacer el nuevo rediseño de los procesos de las cuentas por cobrar a estudiantes, querránhacer 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 financierocon 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 épocade grandes cambios en el campo de la tecnología, un reto y un desafío, pues la adopciónde 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 demandansistemas trasparentes, flexibles y eficaces, capaces de proporcionar los medios asociadospara cada nivel de toma de decisiones en las diferentes áreas administrativas, así comolos adecuados niveles de seguridad.

Los reclamos para una mayor eficacia han encontrado expresión en una variedad decambios en muchas universidades, principalmente en los procesos financieros y en lasprácticas reales. Tales cambios incluyen las reestructuraciones orgánicas, programas dejubilación, trasparencia presupuestal, etc. Estos cambios han agregado urgencia a lossistemas de información financieros y académicos. En muchos campus o instituciones,las jubilaciones tempranas y otras reducciones del personal han vaciado la piscina detalento de personal. En casos donde no se ha cambiado a los empleados mayores de

13

Introducción



edad, la actividad financiera ha permanecido constante y si no han evolucionado, tampocose han deteriorado los flujos de información.

De manera que mientras no se logre un equilibrio eficaz entre los servicios del usuarioy el tomador de decisiones en un sistema que satisfaga a ambos, la colaboración, ycomunicación serán los elementos que aseguren el éxito del proyecto ya que se consideraque 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 institucionespúblicas de educación superior y la Dirección General de Educación Superior e InvestigaciónCientífica de la Secretaría de Educación Pública, así como de la necesidad de adoptar unlenguaje común en el manejo de la información administrativa y financiera1, a principios de1996 se iniciaron los trabajos en el ámbito de la Subsecretaría de Educación Superior eInvestigación Científica de la SEP, de un proyecto de alcance nacional tendiente a lanormalización y estandarización de los sistemas de información administrativa de lasinstituciones de educación superior. Así pues, en este año se tuvo un primer acercamiento delas propias UPES con el modelo de NACUBO y se generó el primer bosquejo para esteproyecto.

Como resultado del programa, la mayoría de las instituciones participantes han tenidoavances 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 etapafinal, en la cual se pretende asegurar la calidad de los sistemas implantados; que lasinstituciones cuenten con mejor información, más confiable, oportuna y homogénea apartir 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 sediseñó 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 lainformación generada por las UPES, una carencia de bases consistentes para la evaluación del desempeño administrativo financieroe insuficiencias en la estandarización de los criterios de registro, agrupación y reporte de la información administrativo-financiera

14



15

Marco de referencia conceptual del SIIA



I. MARCO DE REFERENCIA CONCEPTUAL DEL SISTEMA INTEGRALDE INFORMACIÓN ADMINISTRATIVA (SIIA)

El sistema tiene como propósito fundamental organizar el flujo de la información decarácter administrativo que generan las diferentes unidades orgánicas dentro de lasinstituciones educativas, con el objeto de que los datos que se obtienen lleguen conoportunidad, eficiencia y calidad suficientes para la adecuada toma de decisiones en losdiversos niveles jerárquicos de destino de las instituciones. El Sistema Integral deInformación Administrativa tiene como eje nodal la adopción de un modelo de contabilidadde fondos, adaptado a las necesidades específicas de cada institución, y permite registrar,agrupar y presentar los estados financieros bajo un enfoque integral, normalizadonacionalmente y compatible con estándares internacionales que mejoran sustantivamentela operación, administración y control de los recursos institucionales.

Para el diseño del Sistema Institucional de Información Administrativo-Financiera setomó como base la definición y contenido de la función administrativa general propuestapor la mayoría de los teóricos de la materia, es decir, que esta función se realizageneralmente 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, seadoptó el sistema modular, toda vez que permite la organización independiente de cadaproceso 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 lanormalización de la información contable financiera, pues abarca componentes igualmenteimportantes 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 lastareas de planeación y evaluación institucional.

En este contexto se conformaron los módulos de recursos humanos, recursos financierosy control escolar. Cada uno de los módulos generará indicadores de eficiencia operativade las funciones que implica. Asimismo, a partir de cruces matriciales de la informaciónadministrativa, el sistema permitirá evaluar el desempeño institucional a través de laconstrucción de indicadores específicos, elaborados con base en costos unitarios, deaplicación a las diversas áreas académicas y administrativas involucradas, y alimentarconsecuentemente la toma de decisiones tanto en el ámbito interno, en diversos nivelesde decisión institucional.

Para efectos del presente estudio se entiende por unidad administrativa al conjunto deelementos humanos, físicos, financieros y materiales que, ordenados como un todoorgánico, son los responsables del desarrollo de determinadas funciones; por ejemplopuede ser una secretaría, una dirección, departamento, unidad, centro, escuela o cualquierotra expresión funcional.

La desconcentración administrativa es la forma de organización que permite una mayoreficacia y eficiencia en la operación, por lo que las propuestas que subyacen en estedocumento la consideran como condición sine qua non para la efectividad de la

16



instrumentación del esquema modular de automatización de información, toda vez queesta 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 estarsujeto 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 deestandarización para la integración de la propuesta global, la que será la manifestación delas 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 untodo que puede existir de manera independiente uno de otro, pero que sumados constituyenel 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ónde los recursos financieros y económicos2 y materiales utilizados en la ejecución de losprogramas a cargo de las diversas unidades orgánicas de las instituciones educativas.

También se incluyen las actividades de adquisiciones, almacén, control de inventariosde planta física y activo fijo, la contratación de servicios y arrendamientos, y elmantenimiento de equipos e instalaciones.

Resalta, por su importancia, el manejo y control de la información financiera contable alservicio de las necesidades internas y externas de la administración con orientaciónpragmática destinada a facilitar las funciones administrativas internas de planeación ycontrol, así como a la toma de decisiones.

Requerimientos institucionales

El desarrollo de las instituciones educativas exige que la planeación estratégica serealice 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 formalizadosse 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 participativacon 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).

17




Los diagnósticos y pronósticos que se elaboren deben reflejar situaciones reales, paraque las etapas de diseño de instrumentos sean acordes con las posibilidades de ejecucióny 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 frentea situaciones imponderables, cuando las circunstancias lo ameriten.

En este sentido, se deberá elaborar el diseño conceptual de un sistema de planeacióninstitucional, organizando en el mismo la forma en que se llevará a cabo una planeaciónestratégica y participativa de las acciones universitarias en todos los ámbitos, es decir, lossustantivos y apoyo administrativo a los mismos. Cada una de las unidades orgánicasestarán obligadas a aportar los datos necesarios, y que les correspondan informar deacuerdo con sus funciones, para que sea posible el diseño del plan y los programas quese deriven del mismo.

Se deberá asegurar la congruencia y coherencia entre el plan y los programas quepresenten todas las unidades orgánicas, con el objeto de no contravenir los principios ypropósitos contenidos en el plan institucional.

Uno de los mecanismos más utilizados para poner en marcha lo referido anteriormentepuede ser que la unidad encargada de la elaboración de dicho plan elabore y difundamanuales y guías técnicas de formulación de programas y proyectos, donde se establezcande forma clara y sencilla los lineamientos útiles para retroalimentar su función planeadoray evaluadora de resultados.

La medición de los resultados de ejecución de programas a cargo de las unidadesorgá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 avancesobtenidos y, en su caso, se determinen las medidas correctivas necesarias.

Dentro de los principales productos que se obtienen del funcionamiento de módulofinanciero, y que derivan de planes y programas, se encuentra el presupuesto, el cualconstituye 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 laadministració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 dedifusión de la cultura.

El cumplimiento del objetivo se expresa concretamente en la elaboración de losprogramas presupuestos de ingresos y egresos, donde detalladamente deben quedarestablecidos, de acuerdo con los programas aprobados, el destino de los recursos porobjeto 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 financierode los programas.

18



El programa presupuesto de egresos anual deberá integrarse de manera institucional ypor centro de costos a fin de facilitar el control y seguimiento en su ejecución. Dichaestructura presupuestal deberá organizarse de acuerdo con los principios señalados en elpárrafo anterior.

Se deberán integrar manuales de presupuestación donde se establezcan la políticasde gasto universitario, así como los mecanismos de control y seguimiento en el ejerciciodel presupuesto.

En este orden de ideas se requiere de la implantación de un sistema de programacióny presupuestación que contenga los principios y elementos necesarios para que todas lasacciones que se vayan a desarrollar queden contempladas en dicho sistema. Laorganización, en primer término, deberá sujetarse a la normatividad federal y estatal relativaal presupuesto y gasto público en el sentido de que la estructura programática que seadopte 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 conocerlas políticas y procedimientos administrativos a los que se sujetará la elaboración depresupuestos.

La integración presupuestal deberá realizarse en forma centralizada con el objeto de aplicarel criterio de uniformidad en su conformación. El diseño habrá de señalar en forma clara losrubros de gastos de la manera más adecuada para que una vez autorizado por el órganoadministrativo o de gobierno que corresponda, se dé a conocer a cada área el total de recursosautorizados 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 oportunidadindispensable se reporten periódicamente la ejecución de los programas y presupuestos paraevaluar los resultados presentados y en caso de ser necesario aplicar las medidas correctivasque se requieran.

Es importante mencionar que la instrumentación del sistema de programación ypresupuestación referido, requiere de un ajuste en las funciones de registro y control delejercicio, por lo que la forma de contabilizar las operaciones deberá adecuarse a la forma deprogramar y presupuestar.

Para el funcionamiento sistemático de este módulo, cabe señalar como un componenteimportante el modelo de contabilidad estandarizado conocido como contabilidad de fondos, elcual constituye el marco de referencia para la realización de la aplicación del propio modeloadecuado a las particularidades que presenta la función operativa en el ámbito de cadainstitución. Lo anterior requiere de un adecuado sistema de información para el registro de lasoperaciones contables, la definición de métodos de trabajo más eficientes para organizar lafunción contable y la capacidad técnica del personal encargado de operar y desarrollar elsubsistema financiero contable.

19




Bajo este contexto, para que la información financiera sea útil, es necesario que el contenidoque pretende comunicar sea relevante, significativo, cierto, y a la vez comparable, y que reúnaprincipalmente las características de utilidad4 y confiabilidad5.

La readecuación de la información financiera, tendiente a mejorar la administración de losrecursos, 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 loconforman: 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 expedirseclaramente las normas y procedimientos para su elaboración y ejecución, ya que de ellodepende 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íticade administración de recursos materiales manejada centralizadamente6, con el objetivode conocer el valor de la inversión en activos de consumo y fijos con que cuenta launiversidad. 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 finalde bienes muebles.

• De igual forma se debe regular la baja de bienes muebles por inutilidad o inaplicaciónen 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 mantenimientode 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 estanormatividad podrá realizarse de forma desconcentrada, por lo que el área responsabledeberá funcionar como la unidad administrativa normativa y concentradora de la informacióncorrespondiente a fin de llevar un solo registro. Además de supervisar y evaluar eldesempeñ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 centrosde costos que previamente se hayan establecido para que los registros de contabilidad defondos 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 sucontenido 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. Laconfianza 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 elusuario o solicitudes de servicio, la contraloría interna, un miembro del consejo universitario del área administrativa, y el queadquiere el bien o servicio y el área jurídica.

20



Para coordinar las compras y vigilar el estricto cumplimiento de la normatividad aplicabledeberá constituirse un comité de adquisiciones que sea capaz de definir normas yprocedimientos para las compras y que garantice que las mismas se realicen en las mejorescondiciones de oportunidad técnica y económica a fin de asegurar la más alta calidad enlos artículos que se compran o la calidad de los servicios que se contratan, de acuerdocon la disponibilidad de recursos financieros de que se disponga.

El comité de adquisiciones tendrá como función principal, de acuerdo con las prioridadesque se establezcan, realizar los actos de adjudicación de contratos a los proveedores queofrezcan las mejores propuestas técnicas y económicas. Deberá estar integrado por losusuarios directamente involucrados en cada caso concreto para que sus funciones seanacordes con los planteamientos programáticos de las diversas áreas.

La adquisición de bienes y la contratación de servicios es una función administrativaque requiere una programación eficiente en su ejecución, debido al involucramiento delos recursos financieros que se destinan, por lo que es indispensable establecer la técnicade presupuestos por programas para que las compras se lleven a cabo de una maneramás racional. En esta labor deben estar involucradas todas las áreas de la institución, yaque 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ónde un catálogo de todos los activos fijos que actualmente administra la universidad, elcual podría diseñarse de acuerdo con el tipo de bien del que se trate, estableciendo unaclasificación global a fin de identificarlos según su uso.

Una vez catalogados todos los bienes, se requiere establecer un procedimiento demanejo y control de bienes, por lo que se deberá llevar a cabo un inventario pormenorizadode todos los activos fijos con que cuenta cada una de las áreas que conforman launiversidad, estableciendo resguardos de los mismos, a fin de controlar su existencia yrotación.

Para administrar adecuadamente los activos fijos deberán designarse titulares de loscentros de costos con una responsabilidad directa del usuario, identificados con anticipaciónpara organizar un sistema computarizado de resguardos que asignará la responsabilidaden la custodia de los bienes. Cada centro de costos está obligado a cumplir con losprocedimientos administrativos en su manejo, por lo que deberán reportarse oportunamentelos cambios que se presenten.

Cuando se trate de bienes de activo fijo de reciente adquisición se efectuará una entradaa almacén y el departamento responsable del control de inventarios tendrá que identificarlosy 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 datosque conforman el inventario de la institución.

Respecto al almacén, se requiere el establecimiento de un sistema de kardex de losartículos que se resguardan en las bodegas en el cual habrá de designársele una clave deidentificación, una descripción del bien, su fecha de ingreso al almacén, la existenciaactual, su costo unitario, fecha de la última salida y el valor de la existencia actual.

21




Cabe señalar que se requiere el sistema de kardex, ya que por el almacén tienen quepasar todos los bienes que se adquieran. Sus movimientos de entrada y salida se debenrealizar a través de vales de almacén donde queden expresados todos los datos referentesa los bienes que se entreguen a los usuarios, además de quedar asentados el número oclave del centro de costos al que se refiera, así como el nombre del responsable delalmacén, el nombre del usuario que recibe el bien y el nombre del titular de encargado delalmacén.

Todos lo movimientos mensuales del almacén deberán ser reportados en forma mensualal Departamento de Contabilidad a fin de que lleven a cabo los registros contables que serequieran.

Asimismo, al concluir el ejercicio fiscal deberá llevarse a cabo un inventario de las existenciasen el almacén, cuyos resultados deberán ser informados al Departamento de Contabilidadpara la realización de los cierres correspondientes.

Todas las actividades relacionadas con la administración de recursos materiales deberánquedar 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 serviciose inventarios de activo fijo y de bienes de consumo.

Productos

De dichos procesos se obtienen varios tipos de documentos que habrán de normarse yestandarizarse. 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.

22



• 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 lasactividades 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


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 ylíneas de acción en el corto, mediano y largo plazo. Esta política deberá definir en formasistemática los principales lineamientos de cada institución en materia de las actividadesreferidas al factor humano para cada tipo de trabajador. Ello hará posible mejorarsustancialmente 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 maneracentralizada por la dirección correspondiente a fin de llevar sólo un control sobre eltotal de la plantilla del personal adscrito a cada institución educativa. Para estosefectos se debe considerar la posibilidad del funcionamiento desconcentrado de losaspectos operativos, estableciendo con claridad el tipo de información que habránde 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 loreferente al componente de contabilidad de fondos, deberá establecersecoordinadamente con los responsables de las acciones de programación ypresupuestación, una organización de centros de costos que deberá identificar acada una de las áreas que la componen asignándole un centro de costos, con el

23




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 ladistribución asignada por el centro de costos para que las nóminas quincenalesreflejen el valor correspondiente.

• La comunicación administrativa del área encargada de los recursos humanos conlas demás áreas de las instituciones educativas debe ser de manera eficiente yoportuna para poder dar respuesta inmediata a los requerimientos institucionales,por ello para poder funcionar adecuadamente deberán darse a conocer los principaleslineamientos establecidos en estos asuntos a todos los posibles clientes internos deesta función, es decir, que quien tenga que llevar a cabo una actividad relacionadacon la función de recursos humanos al interior de cada institución tendrá que conocerpreviamente los requisitos que debe cumplir, para que de esta manera quedegarantizada la respuesta que corresponde otorgar al área de recursos humanos.

De lo anterior se desprende que es necesaria la elaboración de manuales deorganización y procedimientos que definan claramente cuáles son las facultades yobligaciones 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 ingresoy egreso del personal de cualquier tipo, es necesario conformar expedientesindividuales con un formato único de movimientos de personal, donde se cuente contodos los datos generales de la persona de que se trate, en el cual quede expresadala información correspondiente a la plaza que se va a ocupar, la temporalidad de lamisma y la codificación presupuestal y de contabilidad de fondos.

• Los movimientos de la plaza, derivados de promociones, renuncias, altas y bajasdeberán integrarse al expediente del personal a fin de mantenerlos permanentementeactualizados. Los documentos que acrediten capacitación con valor curricular debenintegrarse al expediente antes señalado.

• Por lo que respecta al control del personal es necesario instrumentar mecanismosque garanticen la asistencia y permanencia de los trabajadores, toda vez que laproductividad de la institución se ve afectada por la relación existente entre ausencialaboral y pago de tiempos muertos en el trabajo.

Del Contrato Colectivo del Trabajo deberán desprenderse condiciones generales detrabajo que expresen los derechos y obligaciones de las autoridades y trabajadores decada institución, las cuales constituirán la principal norma para realizar la función deadministración de recursos humanos. En ellas deberán quedar asentados los asuntoscorrespondientes 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 ladimensió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 deque sea el propio sistema quien realice las operaciones de los cálculos necesarios para laimpresión de las nóminas ordinarias y extraordinarias.

24



Para ello es importante la comunicación permanente con los responsables del controldel personal administrativo y docente de las escuelas, ya que en el primer caso presentarelativa permanencia y en el segundo los movimientos son frecuentes sobre todo en loscambios semestrales.

Otro aspecto importante a considerar será la tendencia a unificar los archivos públicosde 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 elmanejo 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 controlde alumnos, docentes y las relaciones que surgen entre éstos. Entre otros objetivos sepropone organizar, en forma sistemática y ordenada los datos correspondientes a lamatrícula de alumnos y la plantilla de personal docente.


El archivo central debe concentrar toda la información referente a la totalidad de alumnosde 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 deegresados, 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 elcomportamiento estadístico de los alumnos que han cursado estudios en todos los nivelesque ofrezca la institución.

25




Asimismo, se deberá accesar la información referente al personal docente con quecuente 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 reportesque se emitan lleguen con oportunidad a los usuarios y funcionen como herramientaseficaces 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 recursoshumanos y recursos financieros para que en cada ámbito de funcionamiento la informaciónretroalimente al SIIA.

Productos

• 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

26



27

Especificaciones generales para la construcción del sistema computacional



II. ESPECIFICACIONES GENERALES PARA LA CONSTRUCCIÓN DELSISTEMA COMPUTACIONAL

Introducción

Este apartado presenta el diseño del sistema computacional para el Sistema Integralde Información Administrativa (SIIA) definido en el capítulo anterior, así como lasespecificaciones técnicas para su construcción.

Para las especificaciones técnicas de construcción se han buscado aquellas tecnologíasque, 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 serequiere implantar así como la flexibilidad que deberá tener para adaptarse a cambiosinstitucionales o a los posibles cambios de reingeniería que se requieran a través deltiempo.

Objetivos del sistema

Objetivo general

Construir un sistema de información que de manera integral permita la administracióneficiente y confiable de los recursos humanos, financieros y de control escolar, de lasinstituciones 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 porla evidente debilidad de las bases que le dan fundamento. (Ver anexo correspondiente).

28



Esta discusión se centra en dos aspectos fundamentales, el primero que tiene que vercon una epistemología basada en el principio de autoridad ya que la mayoría de los tratadosde ingeniería de software están basados en una combinación de experiencia anecdóticay autoridad humana, raramente se acompañan de evidencia lógica o experimental. Estoprovoca la carencia de una base sólida que le dé un carácter científico a la ingeniería desoftware.

El segundo tiene que ver con un principio práctico aplicado de manera generalizada enla ingeniería de software y es el famoso precepto de “divide y vencerás”, es decir, se havenido aplicando dogmáticamente este principio, separando las actividades propias delanálisis de las actividades de diseño.

Por otra parte, se presupone que una vez establecido el algoritmo que se obtiene de ladivisión del proceso de desarrollo de software en diversas etapas, se asume que es factibledesarrollarlo sin considerar la posibilidad de llevar a cabo la construcción de un algoritmoque 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 lasactividades de diseño y las de análisis. Dado lo anterior se puede establecer que durantela etapa de análisis se constituye el problema, pues no se obtiene un problema, sólohechos, y justamente este paso de constitución del problema está necesariamente referidoa 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óndel diseño computacional del sistema no puede ser tajante ni rígida, por el contrario, sólopuede limitarse a enunciar un par de ellas, con el propósito de que cada institución valorey determine conforme a sus características, la más adecuada a sus necesidades, o lacombinación de diferentes modelos y metodologías de la ingeniería de software en unintento de robustecer (en la medida de lo posible, pues es un problema muy complejo) eldiseñ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 sonla comúnmente conocida como “modelo lineal secuencial” y la del “modelo de construcciónpor 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 primerasetapas: análisis y diseño) lo cual permitirá establecer ciertas funciones y procesos de unamanera formal así como documentar una gran cantidad de funciones y procesos que nose encuentren en documentos de manera formal; y el modelo por prototipos9 para laconstrucción del sistema.

8 El modelo lineal secuencial sugiere un enfoque sistemático secuencial del desarrollo del software que comienza en un nivel desistemas (conceptual) y progresa con el análisis, diseño, codificación, pruebas y mantenimiento.

29




Consideraciones generales sobre el diseño del SIIA

A continuación se detalla una serie de consideraciones que se recomienda tomar encuenta 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 secapturan una sola vez. En el caso de la base de datos se garantizará que no existainformación redundante.

• Para cada uno de los sistemas que componen el sistema integral, se deberán construirlos mecanismos que hagan posible el seguimiento y control de gestión. Esto espoder monitorear el estatus en que se encuentra un movimiento.

• El sistema deberá contemplar los filtros y sistemas de validación necesarios paragarantizar la calidad de la información.

• El sistema deberá contemplar los mecanismos y políticas de acceso (ver anexo) yseguridad que garanticen la confiabilidad e integridad de la misma.

• El sistema deberá evitar en la medida de lo posible que se realicen movimientos nopermitidos (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 laconstrucción del sistema, en virtud de la eficiencia que ha demostrado en aplicaciones detamaño intermedio y de gran escala, las facilidades que las plataformas actuales de cómputotienen, facilitan la implantación de aplicaciones cliente-servidor, flexibles y de fácilmantenimiento.

Capas

Una manera de potenciar la arquitectura cliente-servidor y que responde a lascaracterísticas que debe tener un sistema de esta naturaleza es la arquitectura de trescapas, la idea fundamental de esta tecnología es dividir las funcionalidades del sistemaen tres grandes grupos: los servicios de usuarios, esta primera capa se encarga deidentificar los objetos necesarios que interactúan con la interfaz de la aplicación; los serviciosde 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 sucedeen el modelo lineal secuencial donde el cliente conoce el resultado del trabajo hasta el final de su desarrollo.

30



internos del negocio y los servicios de datos que son una colección de objetos quemanipulan decisiones de los datos independientes de las reglas de negocio, esto seconvierte directamente en un sistema para el manejo de base de datos. En la mayoría delos casos estas operaciones se realizan con instrucciones SQL.

Se recomienda usar arquitectura de tres capas por tratarse de un sistema de un altovolumen de usuarios concurrentes, una esperanza de vida de la aplicación mayor a tresaños, la necesidad de autentificar usuarios individualmente de acuerdo con su acceso ala base de datos y una fácil implantación de componentes sin impactar de manera sustancialal sistema lo que permite flexibilidad en los cambios que se requieran producto de laevolución del mismo.

Niveles de acceso

Aunque podría considerarse tratado el tema de nivel de acceso de los usuarios en elpunto anterior, conviene establecer de manera muy clara la necesidad de precisar en estesistema los niveles de acceso adecuados para cada componente del mismo. Estoevidentemente requerirá de la participación de la universidad en la definición de los nivelesde acceso adecuados para cada usuario del sistema.

Para el control de los accesos se deberá construir un módulo especial en donde paracada usuario o grupo de usuarios se deberán especificar los privilegios que tienen paraejecutar, accesar o modificar determinado proceso, subsistema o tipo de dato.

Respecto al manejador de base de datos deberá existir un control estricto sobre quiéntiene 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ónde 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 detipo CASE. En el caso del desarrollo se propone el uso de alguna herramienta que permitala generación de código y documentación de manera semiautomática, con facilidades dereingeniería e ingeniería en reversa y que permita transportabilidad a diferentes plataformasy arquitecturas. También es importante mencionar que el uso de este tipo de herramientasapoyan de manera sustancial las actividades del desarrollo del sistema. Sin embargo, esla participación del usuario lo que garantizará un correcto desarrollo y desempeño delsistema.

31




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úmeroimportante de usuarios concurrentes; que sea tolerante a fallas y que permita su rápidarecuperació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 serviciosde negocios y un cliente de tipo visual o cualquier otro asociado a la base de datosseleccionada para la capa de servicios de usuarios. Es pertinente mencionar que una solaherramienta puede ser utilizada para el desarrollo de estas dos capas, sin embargo resultamuy eficiente usar la herramienta orientada a objetos para los servicios de negocios por ladefinición tecnológica de componente que éstos tienen.

Digitalización

Para todas las tareas de digitalización de documentos se propone el uso de escanersde alta velocidad con un motor de administración y recuperación de imágenes que permitala conexión natural a la base de datos seleccionada. Adicionalmente deberá permitir laincorporació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 desistemas tradicionales, principalmente por los costos adicionales que implica, debido a lamagnitud del proyecto en cuestión, se considera pertinente que las instituciones que esténen condiciones implanten esta metodología.

Este análisis consiste en llevar a cabo una evaluación cuantitativa y cualitativa deldesarrollo del proyecto con la finalidad de sistematizar el conocimiento adquirido durantesu desarrollo, formalizar recomendaciones para hacer mejoras a las metodologíasempleadas y la determinación del nivel de éxito y la calidad alcanzada en el desarrollo delproyecto.

Esta información pasará a formar parte de la base de conocimientos de la universidady coadyuvará a mejorar la calidad y el éxito de los futuros proyectos que se emprendan.

32



Infraestructura computacional

El dimensionamiento es uno de los aspectos que requieren mayor atención, ya quenormalmente olvidamos que la infraestructura tiene un costo y el proyecto debe tenermetas o acciones muy definidas, por lo que es necesario determinar los alcances delproyecto y los recursos que se requieren para tener un servicio con niveles aceptables enun tiempo aceptable. Normalmente la inexperiencia en este sentido incrementa los costosdel 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 yla 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, enasesores de experiencia, se debe diseñar una estrategia robusta y un estudio del costo-beneficio, más aún, cuestionarnos objetivamente si el momento para el módulo es primeroo cuál depende del otro para no duplicar la tarea.

Descripción del sistema computacional integralEspecificaciones técnicas del SIIA

33P R O N A DP R O N A DP R O N A DP R O N A D

III. DESCRIPCIÓN DEL SISTEMA COMPUTACIONAL INTEGRAL

Este apartado contiene una descripción general de la funcionalidad y componentes decada uno de los sistemas que integran al Sistema Integral de Información Administrativay Financiera (SIIA). En algunos casos se precisan los datos de entrada para cada uno delos 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 actividadesfinancieras realizadas por las instituciones públicas o privadas.

En la actualidad, los métodos contables brindan con mayor facilidad y flexibilidad informaciónfinanciera más completa y detallada.

Esta información financiera es valiosa porque permite evaluar acciones pasadas y ayuda apreparar planes para el futuro por medio de los cuales se puedan alcanzar objetivos y metasfinancieras.

La calidad de la información financiera ha sido fuertemente criticada por los directivos quesuelen tomar decisiones estratégicas. Lo anterior ha propiciado que se hayan venidoproponiendo 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 necesidadesinternas y externas de la administración con orientación pragmática destinada a facilitar lasfunciones 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 mismascaracterísticas que para una empresa comercial:

a) Proveer información para la planeación y la elaboración del presupuesto, instrumentosa través de los cuales, se espera que el uso de los recursos disponibles sea máseficiente.

b) Proporcionar información financiera para el control de las operaciones institucionales adiferentes 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.


34P R O N A DP R O N A D

Respecto a sus objetivos organizacionales, éstos presentan diferencia con las empresascomerciales.

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 financiamientoque 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 unade ellas. Mientras que para la empresa comercial el efectivo es producto de venta de bienes yservicios y son su principal fuente de recursos, y sus ganancias, están determinadas por larelación que guardan sus ingresos respecto a sus gastos, para una institución de educaciónmás del 80% de sus ingresos provienen del subsidio, y sus recursos son controlados deacuerdo 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 acuerdocon los principios de contabilidad generalmente aceptados.

Sin embargo, en contabilidad, como en muchas disciplinas, hay desacuerdos en la manerade presentar situaciones especiales. En tales situaciones la metodología contable difiere deun campus a otro.

El diseño de un sistema contable se puede determinar, en parte, por la naturaleza de lainstitución, así como de su historia.

Un sistema de contabilidad no necesariamente refleja todas las operaciones financierasque 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 aalumnos 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 incluidosen los estados financieros.

Esto nos lleva a pensar que el sistema de contabilidad de la institución puede no proporcionaruna realidad completa de la situación financiera.

Las organizaciones no lucrativas como grupo difieren de las empresas en cuanto a queaquéllas son receptoras del subsidio, donativos, contribuciones y apropiaciones, que estánrestringidas para su uso, ya que su utilización está asociada a propósitos, funciones y actividadesen particular.



Un donante, por ejemplo, puede especificar que su aportación sea utilizada exclusivamentepara becas.

Bajo este sentido, la institución no tiene ninguna otra autoridad para disponer del recursoque no sea para el fin para lo que fue dado.

Dada esta característica en particular, que distingue la contabilidad que debe seguir unainstitució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 financierossean manejados de acuerdo con las restricciones que se les han impuesto.

La contabilidad universitaria permite la separación de los recursos con restricciones externaspara 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 casosson utilizados para propósitos específicos, el sistema contable debe estar diseñado pararegistrar, clasificar y reportar la situación que guarda cada una de las fuentes de los recursosrestringidos.

Requerimientos

Dentro de la fase del proceso del subsistema financiero contable, existen consideracionesimportantes, 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 cuentasautobalanceables, esto es, tienen sus propias cuentas de activo, pasivo y patrimonio, ademásde las cuentas de resultados, ingresos y gastos.

Se establecen fondos separados para contabilizar las actividades financieras relacionadascon 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 utilizadosde acuerdo con las restricciones impuestas, en este caso, por el otorgante del subsidio, obien, por la junta de gobierno.

Consideraciones organizacionales

Las consideraciones organizacionales son aspectos que no necesariamente correspondena tópicos contables y que tienen que ver más bien con la definición de funciones y con ladisponibilidad de recursos computacionales, tanto de software como de hardware, para laadecuada operación de sistema.



Infraestructura contable

La infraestructura contable se refiere a aquellos elementos esenciales para generarinformación financiera con las especificaciones de calidad y eficiencia que demandan losusuarios.

Entre los aspectos más importantes destaca un adecuado sistema de información para elregistro de las operaciones contables, la definición de métodos de trabajo más eficientes paraorganizar la función contable y la capacidad técnica del personal encargado de operar ydesarrollar el subsistema financiero contable.

Para que la información financiera sea útil, es necesario que el contenido que pretendecomunicar sea relevante, significativo, cierto y a la vez comparable y que reúna principalmentedos 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. Lautilidad 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 valorintrínseco que posee dicha información, basada en significación, relevación, veracidad ycomparabilidad.

Oportunidad: esta cualidad de la información se refiere a que ésta llegue a manos delusuario 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 yutiliza para tomar decisiones basándose en ella. La confianza que el usuario de la informacióncontable 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 losrecursos es un proceso de cambio que requiere la voluntad y participación activa de lacomunidad universitaria, desarrollándose bajo la filosofía de la comunicación integral, esdecir, debe existir una interacción sumamente estrecha entre las instancias administrativasque lo conforman, como son:



Por esta razón, es de suma importancia que todas éstas lleven a cabo las funcionesque tienen a su cargo, ya que la información que emane de ellas podrá ser utilizada porlos departamentos restantes, evitando de esta manera la duplicidad de actividades y porconsiguiente 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 queson: fondo, función, unidad responsable y cuenta contable, por lo tanto deben existir cuatrocatálogos que hagan referencia a estos datos.

Catálogo de fondos

1 0 0 0 Fondo de operación1 1 0 0 Fondo de operación genérico1 2 0 0 Fondo de operación específico1 2 1 0 FOMES1 2 3 0 PROMEP

Catálogo de funciones

1 04 00 00 Educación superior1 04 01 00 Tronco común1 04 15 00 Lic. en psicología1 04 18 00 Contador público

Catálogo de dependencias

001 Facultad de Arquitectura003 Facultad de Ciencias Agropecuarias005 Facultad de Ciencias Biológicas007 Facultad de Comunicación Humana009 Facultad de Ciencias Químicas e Ingeniería

Cátalogo de cuentas

102 Bancos102 01 Bancos fondo op. genérico102 10 Bancos fondo FOMES120 Activos fijos120 00 00023 Equipo de procesamiento de datos420 00 00000 Ingresos académicos420 01 00001 Cuotas por inscripción420 01 00002 Cuotas por colegiatura



También consideramos una tabla con todos los registros contables y un encabezadode esos registros que lo consideraríamos como la póliza, o el encabezado de la póliza, porlo 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 lasacciones encaminadas a fortalecer y consolidar tanto el flujo de información como latransparencia 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 matricialpropuesta por el Sistema Integral de Información Administrativa (SIIA).

Donde las tablas de fondos, UR, cuentas y funciones tienen la estructura básica declave y descripción, la de pólizas tiene además de su clave y descripción identificadoresde 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 debeestar cuadrado en fondo, esto es, que todas las pólizas que se registren en el sistemadeben estar validadas en el sentido de que la suma de abonos y cargos por cada fondodeban ser iguales.

Naturalmente es alimentado por el registro natural de pólizas, pero en su operaciónnormal debe ser alimentado por pólizas automáticas que deben ser generadas a partir dela operación de los otros módulos, esto es, que los movimientos de almacén registrenpó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ínimaspara su conexión con los otros módulos, por ejemplo: debe tener una cuenta de bancospara su control de bancos, una cuenta de cuentas por pagar para su control de cuentaspor pagar, y así sucesivamente, estas cuentas son mencionadas en cada uno de losmódulos a los que correspondan.



Reservado

La estructura del reservado es prácticamente igual al contable, su uso se puede orientarhacia presupuesto, esto es que sirve para registrar los movimientos que aún no soncontables, pero están en vías de serlo, por lo tanto, presupuestalmente deben sercontrolados. Para su esquema ver el libro contable.

El manejo de este registro es prácticamente automático, ya que su control está enfunción de los movimientos generados por los otros módulos, aunque sería convenientedejar 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 puededefinir en dos partes presupuesto de ingresos y presupuesto de egresos, que se llenanrespectivamente con entrada o salida de recursos.

El objetivo de este módulo es controlar la disponibilidad de recursos que no se destinena 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, lacomparación es automática.

El presupuesto se maneja en dos fases, primero se da de alta el presupuesto anual, atravé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 asignacionespresupuestales.

Los módulos de detalle presupuestal y detalle de asignación presupuestal nos indicanprecisamente 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 seespecifican 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 Presupuestalcon el proceso Asigna Presupuesto, aquí se teclea cuanto presupuesto se quiere asignary se asigna.

Si se quieren asignar cuentas a los renglones presupuestales, entonces en el módulode Control Presupuestal, con el proceso Asignar Cuentas, se asignan las cuentaspresupuestales.



Si incluye cuenta y auxiliar, entonces el presupuesto queda directo apuntando a lacuenta y auxiliar, si no se le pone auxiliar, entonces sólo queda apuntando a la cuenta demayor, 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 eserengló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 odisminuir el presupuesto se hace a través de este módulo, para aumentar sólo se pone lacantidad que se desea aumentar/disminuir en el renglón de monto, de cada registro quese capture, para disminuir la cantidad se pone en negativo. Recordar que la aplicación serefiere a cómo se checa el presupuesto, esto es que si ponen aplicación 1 debe capturarprograma 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 UnidadResponsable, en todos los casos los campos de Aplicación y Subfondo son requeridos.



Control presupuestal

Este es el módulo donde se checa qué tal va el presupuesto, a continuación se describenlos 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 dereservado, etcétera.

Por pagar:

Es el pasivo, cuenta 211, cada que se registre un pasivo este campo aumenta, y cuandose paga disminuye, afectándose la cuenta.

Ejercido:

Es el total ejercido, se llena con los gastos, cuando existe un gasto este campo seafecta, si es un gasto provisionado, se afecta y el pasivo lo disminuye, y en cuanto sepaga 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



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, éstasse 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 laaplicación.

Las aplicaciones 1 y 2 vienen por default, donde 1 checa siempre U Responsable yPrograma, y la 2 checa programa sin importar U Responsable, las demás aplicacionesque 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 laoperación financiera.



Periodos fiscales

Meses que se abren dentro de un año fiscal, se manejan los meses naturales, del 01 al12 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 dela gráfica.

En el módulo de catálogo de cuentas podemos ver las cuentas que están registradasen 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 fijosGastos 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 campopredecesor, 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 correspondea si se permite o no meter datos a la cuenta correspondiente.



Pólizas contables

Contiene todas las pólizas contables, tanto las generadas automáticamente como lascapturadas en este mismo módulo, las que se capturan en este módulo son las tipo PD, elresto 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), parapoder modificar las otras es necesario hacerlo desde el módulo donde se crearon, pero sipuede ver los detalles contables de los otros documentos, con seleccionar el documentocorrespondiente. A continuación se describen los campos:

Documento

Es el número de documento. Es un número único para todos los documentos, por cadapóliza que se crea, ya sea contable o de reservado, se le asigna un número y este es elnú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



Núm.

Número consecutivo, por cada TDoc-Año-Mes se genera un consecutivo, este es elnú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á canceladoen el mismo mes o periodo fiscal, si fue cancelado con una póliza de reversa entonces noaparece como cancelado.

Docum cancel

Nos indica el número de documento que lo cancela, si el documento se cancela en elmismo mes entonces nos dice el mismo número del documento y el campo cancel está enS ; si está cancelado con una póliza de reversa en diferente mes entonces nos indica eldocumento que lo cancela, y el campo cancel está en N, obviamente si no tiene datosentonces el documento no está cancelado.



Estados financieros

Este es un módulo de reportes, aquí se generan los reportes indicados en el periodoespecificado 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 puedenespecificar todos, para sacar un consolidado y algún fondo y/o subfondo específico segúnse requiera el reporte.

La opción de auxiliar nos genera un auxiliar en forma de árbol de la cuenta seleccionadaen el combo de auxiliar, tomando en cuenta también los parámetros de selecciónespecificados 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 indicadosen la parte superior, ya sea los ingresos o los gastos generados, tanto de forma tabularcomo gráfica, estos ingresos/gastos se pueden generar por cada uno de los botonesindicados en parte superior, por subfondo / cuenta / programa / ures, y una vez generadopor alguno de estos factores, se puede sacar su desagregado por cada uno de estosfactores, esto es:

Si queremos el total gastado por programa pulsamos el botón “programa”, de algunode los registros seleccionados deseamos su desglose por U Responsable, pulsamos el



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 delrenglón, y la cruz desaparece en modo tabular, y cuando seleccionamos gráfico no apareceel renglón marcado, para volver a ponerlo sólo tecleamos doble clic en donde estaba lacruz 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 depago, es necesario tener las oficinas de compra capturadas, ya que las compras siemprese refieren a este campo.

El orden normal para hacer una compra es hacer la requisición, posteriormente sehace la orden de compra, cuando el proveedor entrega la mercancía se corre el procesode recepción de mercancía de órdenes de compra, y cuando la oficina entrega la mercancíaa las dependencias corre el proceso de entrega de mercancía, esto se detalla más en elmódulo de órdenes de compra.

Los módulos relacionados con compras son los siguientes:

• Oficinas de compra

• Requisición de compra



• Orden de compra

• Ítems pendientes

Oficinas de compra

En un catálogo, cuando se vaya a comprar o se requiera comprar algo, se debeespecificar 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 renglonescontables 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 larequisición, junto con los datos de la póliza.

Descripción:



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 larequisició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 nopodrá 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énse entrega la mercancía a las unidades responsables o personas que requirieron los



bienes, es posible hacer una sola orden de compra para muchas requisiciones, la únicacondició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álogode personas, y a la persona que va a ser proveedor se le pone la marca de proveedor, vercatá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



Descripción del bien a comprar

Cuenta-auxiliar

Cuenta contable y auxiliar del bien, este par de campos se comparan contra el pedidopor la requisición, si no corresponden entonces marcará error.

Precio

Precio de compra del proveedor, recordar que el precio unitario del ítem no puede sermayor 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 preciounitario del ítem no puede ser mayor al autorizado en la requisición.



Procesos de órdenes de compra

Recepción de mercancía

Este proceso se ejecuta cuando el proveedor entrega la mercancía a la oficina decompras, se captura la fecha de recepción de la mercancía y el nombre de la persona quela 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 ordende 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 entregarde una en una, o en partes, para hacerlo se debe marcar en el renglón correspondiente derequisiciones 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ó lamercancía que requirió.

Ítems de pendientes

Esta tabla muestra los renglones de requisiciones que están pendientes por surtir, elcampo “Pendiente” indica precisamente la cantidad pendiente, los demás son datosreferentes al renglón de la requisición que falta por ser atendida.



Subsistema de almacén

Es el control del almacén, sus entradas y salidas, todos los movimientos quedanregistrados 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 elcampo tipo. El real es cuando existe una entrada o salida real del inventario. El requeridose usa cuando es entrada que hubo una requisición; cuando es salida es que se cancelaese 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 susefectos en contabilidad.

Las entradas al almacén naturalmente se registran cuando existen compras directaspara el almacén, a través de una orden de compra, en cuanto se recibe la mercancía de laorden se afectan tanto los inventarios como los precios en el almacén, calculados al costopromedio.

La generación de los movimientos contables correspondientes se reflejan en cuantose registra la factura de la compra, con cargo al almacén que se surte con la compra, yabono cuentas por pagar, que se salda en cuanto se hace el pago :

El bloque de almacén está formado por los siguientes módulos

• Artículos

• Existencias

• Requisiciones de almacén

• Artículos pendientes de entrega

• Entregas de almacén

• Devoluciones de almacén

• Ajuste de almacén



Flujo de control en almacén

En la gráfica podemos observar que hay dos líneas de flujo: el control de almacén ypagos a proveedores.

En el control de almacén, primero creamos una requisición de almacén, posteriormenteel 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 desearegresarlo 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 proveedorcon 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 sehace a través del módulo de entregas de almacén. Inicialmente hay una requisición dealmacén, iniciada por la dependencia, que es la que afecta el tipo requerido en losmovimientos 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 secancela la requisición de almacén.

La requisición afecta el libro de Reservado al FUCP (Fondo-Unidad Responsable-Cuenta-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:



Además de permitir ajustes de almacén, este módulo sirve para ajustar el almacén aexistencias y precios reales, normalmente se utiliza al inicio de la operación, o cuando sehacen conteos físicos o simplemente cuando se quieran reajustar los valores tanto deinventarios como en libros.

Los movimientos que se hacen cuando se realiza este ajuste son de almacén, el cualda una salida a la existencia actual y una entrada a la nueva existencia ajustándose comose requiera; en contabilidad se refleja la salida como un abono al almacén y cargo a lacuenta 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 deajuste de almacén

Adquisiciones

Este módulo corresponde al de compras, que se hacen por dos vías: cuando ladependencia 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, seaumentan y actualizan las existencias en almacén.

El primer caso, de compra por pedido, supone que debe existir presupuesto suficientepara que la dependencia compre, y esto se verifica porque desde la requisición de comprahay movimientos en el libro de reservado.

Una vez que se hace la requisición, se alimenta la tabla de ítems por comprar, queestaría revisando el cliente para ver qué artículo les hace falta, de ahí procede la orden decompra, donde ésta asociaría todas las requisiciones que vienen de ítems comunes; porejemplo, si varias dependencias piden computadoras, con una sola orden de compra seasocian estas requisiciones.

Con la orden de compra capturada proceden dos acciones: pagar anticipos, en el módulode anticipo a proveedores, o recibir la mercancía, donde no se pueden pagar anticipos yaque 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 dealmacén y en el de facturas de compra.



Artículos

En este módulo se dan de alta todos los artículos que vayan a ser manejados por losalmacenes.

Es importante seleccionar correctamente la cuenta que se va a vincular con el artículo.



Requisiciones de almacén

Este documento se utiliza cuando una dependencia necesita algún bien que se encuentradisponible 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 inferiorcada 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 delalmacén, por lo que todos los artículos se cancelan.

Las cancelaciones parciales se dan cuando ya hemos recibido parte de lo que pedimosy 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 undocumento 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 entregade un artículo de cualquier requisición que una dependencia haya hecho al almacén, perono podemos mezclar requisiciones de distintas dependencias.



La forma de detalle de este módulo es la siguiente:


En la parte superior se capturan los datos generales de la entrega y en la inferior cadaartí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 dealmacé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:


En la parte superior se capturan los datos generales de la devolución y en la inferiorcada artículo que se devuelve al almacén.



Facturas de almacén

Aquí se capturan las facturas que van directamente al almacén, el movimiento contableque se realiza es cargo a éste (113) con abono a documentos por pagar (216); capturar lafactura automáticamente incrementa la disponibilidad del artículo adquirido y también elprecio, según se haya registrado, obviamente en caso de cancelación se eliminan losartículos registrados.

Facturas de compra directa

Es la facturación de las órdenes de compra, para poder capturar en este módulo debeexistir una orden de compra anterior.

En caso de que la orden de compra tenga un anticipo sin pagar pendiente, se eliminaese pendiente de pago del anticipo, pasando a por pagar de la factura, cancelando elmovimiento 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 elcorrespondiente 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.



Subsistema de cuentas por pagar

Todos los pagos que se hagan o que se vayan a hacer, deben entrar a cuentas porpagar, y dependiendo del tipo de cuenta por pagar es el movimiento contable que serealiza, normalmente el abono se hace a cuentas por pagar, cuando el cargo correspondea cuentas de egresos, y si el cargo corresponde a otro tipo de cuentas que no seanegresos el abono se hace a documentos por pagar.

En cuanto se hace el registro de la cuenta por pagar, cualquiera que sea, ésta apareceen el módulo de pagos pendientes esperando ser pagada.

A continuación se describen cada uno de los tipos de cuentas por pagar quecorresponden a cada uno de los documentos por pagar que se manejan, cada uno deestos 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 recibidoni 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 nopermitirá cambios en la orden de compra correspondiente.

Esta cuenta por pagar se alimenta desde la orden de compra, por cada orden de compraque se haga, siempre que no se haya recibido, y por lo tanto tampoco esté facturada, sepuede hacer un anticipo de la misma, los movimientos contables que se realizan soncargo a anticipo a proveedores con abono a documentos por pagar.



Facturas de compras

El paso normal después de la orden de compra es la factura de la compra, por cadaorden 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 decompra, una factura.

El monto a pagar de la factura depende de si hubo antes anticipo o no, en caso de quehaya algún anticipo, éste se disminuye del total a pagar, y se hacen los movimientoscontables correspondientes, otro factor que entra es cuando se quieren hacer retenciones,estas retenciones apuntan a las cuentas de impuestos, y cuando se capturan se puedenmover 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 losmovimientos de la orden de compra que se generaron, siempre y cuando las compras nosean 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 dealmacé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únmovimiento.



Cuando se compran ítems que no son de almacén, es decir, cuando se surtenrequisiciones de compra, entonces el cargo sería a la distribución contable de la requisición-orden de compra que se está surtiendo, y que normalmente son cuentas de gastos, con elabono a cuentas por pagar. También en reservado hay movimientos, como la orden decompra generó algunos movimientos la factura los elimina y éste es el caso en el que lafactura tiene presencia en el libro de reservado, por otro lado también se actualizan en elmó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 anticipoa 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, losmovimientos normales que aplicarían en la retención serían de un cargo a documentospor pagar, si es un ítem de artículos de almacén, o a cuentas por pagar, si el ítem pertenecea 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óno almacén, se puede decir que éste es una factura abierta, el movimiento contable naturales de cargo al FUCP, capturado en el mismo documento, con abono a cuentas por pagarsi es que la cuenta que se captura pertenece a gastos, o a documentos por pagar en casocontrario que la cuenta no pertenezca a gastos, se capturan las unidades porque en elmomento de hacer la factura, si es que la cuenta que se pone es de activos fijos, entonceslas unidades capturadas automáticamente se cargan en la tabla de inventarios.



Vales

Vales o cuentas por comprobar, el vale se carga directamente a gastos por comprobaral 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 losmovimientos contables correspondientes, en cuanto se paga, la cantidad que se pagaespera 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 (vermódulos de comprobaciones), el documento contablemente se maneja como cargo acuentas 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 sepaga o emite el cheque se cancela el pago pendiente, el movimiento contable es, por lotanto, el cargo a cuentas o documentos por pagar, con el abono a la cuenta de banco ocaja correspondiente, en todos los casos de cuentas por pagar (ver módulo) se presentael mismo esquema:



El pago, naturalmente, es la cancelación del pago pendiente o contablemente se puedeinterpretar como que el documento por pagar se provisiona, y el pago es la cancelaciónde la provisión o del pasivo.

Otros pagos

Se refiere a cualquier otro tipo de pago que se quiera hacer, que no sea gasto, comopagos de impuestos, regresos de dinero, etcétera.

El movimiento contable es cargo a la cuenta que se quiera pagar (xx) y abono adocumentos por pagar (216).



Subsistema de pagos

Todos los documentos que se capturan en cuentas por pagar pasan a pagos, en estaparte 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 bancocon el que se va a hacer el pago, en el campo “nombre” se captura a nombre de quién sedesea que sea el pago, o el cheque si es un cheque, después se registra documento pordocumento que se está pagando.

El movimiento contable depende de cuál documento sea el que se esté pagando, si esanticipo a proveedores, factura de almacén u otros pagos, entonces el movimiento contablesería documentos por pagar (216) contra bancos (112), si fueran vales o facturas decompra sería cuentas por pagar (211) contra bancos, cada renglón se procesaindividualmente.

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 paraotra impresión, para cancelar todo el pago es necesario usar la opción de “borrar” delmismo menú de pagos.



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ónse selecciona la opción detalle y se siguen las instrucciones, para poder imprimir debenseleccionarse siempre cheques del mismo banco, si no el sistema marcará error, se puedenseleccionar los cheques que se deseen para imprimirse.

Pagos pendientes

En esta tabla aparece cada uno de los pagos pendientes, por renglón, son losdocumentos que se han capturado en cuentas por pagar y aun no para su pago, esto espara 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 tablasó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 uncargo a cuenta por comprobar con abono a cuenta por pagar (ver vales), por lo que lacomprobación debe corresponder a un abono a la cuenta por comprobar con el cargo a lacuenta que se está comprobando, esta cuenta viene especificada con el documento decomprobación que se presenta y se captura precisamente en este módulo.



Debe existir un registro de comprobaciones donde se tenga el estado de cuenta porcomprobar de los empleados, esto es que cada empleado debe saber qué vales debecomprobar 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, estemó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 deberegistrar el bien que se está adquiriendo. Cuando se registre algún bien, la manera comoel sistema lo sabría es porque el bien corresponde a algún activo fijo, y los documentosque alimentan este módulo deben ser los módulos de compras y comprobaciones, aunquetambién este módulo permite el registro de bienes sin necesidad de ser generadosautomáticamente, debe mantenerse el valor de los bienes igual al valor en libros, paraque 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 delmismo, (resguardo), y también las reasignaciones junto con los históricos de esasreasignaciones, y por último cuando el bien muere, la posibilidad de dar de baja el bien.



Cuentas por cobrar-pagos

En esta tabla se registran las cuentas por cobrar, aquí también viene la conexión con elmódulo de escolar, ya que siendo una universidad, los servicios que presta sonprecisamente 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 indiquenquié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 dependencia4. 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ícula2. Alumno 112343. Facultad de Ingeniería4. Ciclo escolar 99-15. $220.00 O si se cobrara por materia tendríamos:

1. Matrícula2. Alumno 112343. Facultad de Ingeniería4. Matemáticas I, Ciclo escolar 99’15. $220.00

Como podemos ver, los datos correspondientes al módulo de Escolar se reflejan en elcampo 4, donde debemos tener los catálogos de materias, ciclos, carreras, y en el campo2, donde esperamos una liga con un catálogo de alumnos.

Aunque podríamos interpretar el catálogo de carreras como un subconjunto del catálogode programas, esto es, las carreras deben ser todos los programas que pertenezcan a lafunción 01 (docencia), y aquí es donde tenemos la otra liga a escolar, a través de loscatálogos de funciones.

Interpretado como un E-R el esquema de cuentas por cobrar seria como sigue:



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 dependenciasfinancieras 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 queal revés, aquí se espera cobrar, en vez de pagar, por lo que los movimientos contablesnaturales serían de abono a ingresos con cargo a cuentas por cobrar, en cuanto existe elregistro, y una vez pagado sería el abono a cuentas por cobrar con el cargo, por lo tanto elesquema final contable para ingresos se reflejaría como sigue:



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 dedos formas, ya sea por cuentas por cobrar, que sería los adeudos de los estudiantes y/oclientes, y la de varios, donde se captura cualquier cosa que ingrese, a continuación sedescriben 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 alprimero, 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 ingresopor clasificar) al módulo de ingresos por clasificar.

Caja



Este es el módulo de caja, para poder entrar a este módulo el usuario debe estardefinido 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 nuncapodrá entrar al módulo de caja.

Cuando entra a caja automáticamente se abre un nuevo corte si es que no había ningúnprevio sin cerrar, en caso de que exista un corte abierto para ese cajero, entonces se abreel 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 cuentacancelando sus pendientes, o varios, donde se captura los que no sean clasificados comoclientes.

Para cancelar los movimientos, borrar, en caso de equivocación del cajero, esto debehacerlo una persona autorizada, para autorizar esta persona, también en el módulo depersonas, se le debe dar el derecho de que pueda cancelar caja, y sólo si esta personaentra con su cuenta y contraseña se podrá eliminar el movimiento, una vez entrado elmovimiento 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 laopción del menú, ahora bien, cerrarlo lo puede hacer el mismo cajero, pero para cancelarlosólo podrá hacer la persona autorizada.

Si se cancela no pasa nada, si se cierra o termina, automáticamente se crea la pólizacon 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 escliente, entonces el abono corresponde a la cuenta del cliente que se salda (ver cuentaspor 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 tienealgún valor, entonces corresponde a un pago de clientes, si no corresponde a un ingresode 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.



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 verquién pago o no una materia, un ciclo, etc., según la política de la institución, los camposde 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, funcionandocon 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ántosy 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 losgastos a comprobar, éstos se hacen por renglón, y son precisamente éstos los que aparecenen la lista.

Comprobaciones



Aquí se capturan las comprobaciones, es necesario capturarlas por el detalle decomprobación, ver módulo de detalle por comprobar, las opciones de proveedor y facturade proveedor son opcionales, la póliza sólo hace la reversa del detalle de comprobar, yvuelve a cargar a la cuenta que se requiera, esto es: cargo negativo a 531 y nuevo cargoa 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 llenandoen cuanto se adquieren activos fijos, ya sea a través de compras o cuando se compruebanlas compras (vales) se pueden agregar directamente los bienes, el campo tipo nos indicael tipo de activo que se está manejando, y el inventario es el número que se desee ponercomo consecutivo, de todos modos internamente se maneja un consecutivo, campoconsecutivo, que mantiene el registro del bien.

Cuando se vuelve a asignar el bien a otra unidad responsable, sólo se cambia launidad responsable y se vuelve a reasignar el bien, el histórico se guarda en el detalle delbien.

74



Módulo de recursos humanos

Las funciones fueron agrupadas en cuatro subsistemas; el primero se refiere a todasaquellas funciones exclusivas para el personal docente, en el siguiente se agrupan aquellasfunciones exclusivas para el personal administrativo y/o trabajadores, el tercer subsistemaincluye todos los procedimientos y funciones para la elaboración de la nómina y el últimoabarca todas aquellas prestaciones de carácter general para quienes laboran dentro de lainstitución. Cabe aclarar que este agrupamiento no es el único válido y que dependerá delas 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 delos diferentes campos que integran la base de datos de personal administrativo conformea los procedimientos que establezca cada institución.

A continuación se describen algunos de los movimientos que permitirá registrar elsubsistema:

• Altas de personal administrativo (eventuales)

Consiste en otorgar una plaza eventual para efecto de una obra determinada duranteun periodo de tiempo determinado. Una vez autorizado este movimiento el trabajadordeberá ser dado de alta en la base de datos de la institución, así también el contrato detrabajo 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 almomento de su contratación queda establecido el periodo del contrato por lo que al arribara 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 debase.

Aun cuando este tipo de movimiento no resulta muy común, en ocasiones se llega apresentar. Estos movimientos habrán de generar pagos extraordinarios por concepto deliquidación.

75



Descripción del sistema computacional integral

• Prejubilación

Este tipo de movimientos sólo se presenta en aquellas instituciones en dónde dentrodel 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ónpara jubilarse, mas no la cantidad de años señalada por el ISSSTE. Por lo que a pesar dealcanzar 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 aquellostrabajadores eventuales cuyo contrato hubiera concluido.

• Cambios de adscripción

Se refiere al proceso mediante el cual un trabajador cambia de lugar de adscripción alque 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 recibenlos trabajadores por los riesgos de laborar en unidades orgánicas con lugares insalubresy laboratorios donde se manejen sustancias químicas tóxicas que pudieran atentar contrala salud y el bienestar de los trabajadores.

• Primas especiales

Este tipo de beneficios lo otorgan algunas instituciones a aquellos trabajadores quecumplen alguna condición de trabajo especial. Por ejemplo, la prima sabatina y dominicalque se ofrece en algunas instituciones para aquellos trabajadores que laboran los finesde 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 serequieran conforme al tipo de movimiento.

Este sistema deberá contemplar las siguientes facilidades:

1. Confirmación de movimientos

76



2. Mantener un control estricto sobre todos los movimientos que afecten la base dedatos. Cada uno de estos movimientos deberá ser registrado, almacenándose, entreotros 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 ciertosvalores, las modificaciones se deberán realizar a través de menues de tipo “combo-box” que desplegarán los catálogos correspondientes.

4. Los movimientos de baja deberán reflejarse en una base de datos “histórica” endonde queden registrados los datos de aquellos docentes dados de baja.

5. El sistema deberá garantizar que los movimientos de altas no generen registrosduplicados. De preferencia se deberá utilizar la CURP como llave de acceso a lasbases de datos de personas.

6. Para cada uno de los movimientos el sistema deberá garantizar la completez de losdatos requeridos para el mismo. Se sugiere que siempre quede registrado quiénrealizó 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 através de los cuales se acote el universo de empleados. Los criterios podrán ser tanestrechos como lo requiera el usuario, por ejemplo, podrá seleccionar todos aquellosempleados 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 obtenidosu 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 cadauno de los trabajadores administrativos.

Expedientes del personal

El sistema deberá registrar los documentos que ingresan al archivo de personaladministrativo, tales como acta de nacimiento, título, oficios, nombramientos, etc. Paraesto se recomienda la digitalización de los documentos.

Subsistema de personal docente

La funcionalidad y características de este subsistema deberá ser semejante al delsubsistema de personal administrativo, sólo que referente a los movimientos y datos delpersonal docente. A continuación describimos algunas de las funciones y procesos a loscuales deberá hacer referencia este subsistema:

10 El registro de los movimientos permitirá auditar todos aquellos movimientos realizados sobre la base de datos

77




• Asignación de cargas de trabajo a docentes

Se refiere al proceso mediante el cual se determinan las cargas de trabajo de losdocentes de todas las unidades orgánicas de la institución. Para cada uno de los docenteshabrá 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 controlescolar y asuntos financieros. Las horas de clase y/o laboratorio que se asignen en elmó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 financieropresupuestado 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 casoajustadas por la unidad orgánica responsable.

• Basificación de docentes

Procedimiento mediante el cual un docente pasa a formar parte de la planta permanentede profesores de una institución. Desde el punto de vista de este módulo la operaciónresulta 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 Esteprocedimiento se aplica sólo en aquellas instituciones en las cuales las basificaciones seasignan 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 losdocentes. Así también controlar qué documentos se encuentran físicamente en poder dela universidad. Estos expedientes deberán actualizarse siendo lo más deseable que losdocumentos 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

78



• Proyectos e investigaciones• Becas y estímulos• Especialidad

Además de esta información se podrán consultar todos los datos laborales de losdocentes, 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 instanciacorrespondiente, se modifica el grupo laboral, categoría o nivel del docente. Cualquierade las anteriores modificaciones resultan de gran relevancia ya que se reflejarán en lanómina. El sistema deberá registrar la fecha del movimiento, la vigencia, el responsablede 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 lasatribuciones para autorizarlo podrá revisar, a través del sistema, que éste cumpla losrequisitos 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 otorgamientode becas a sus docentes, una vez aprobadas por el área correspondiente, se tendrá queingresar el movimiento al sistema, señalando entre otros el monto, periodo, fondo dedonde proviene, etcétera.

• Proyectos de investigación

Este procedimiento se refiere a la asignación de un docente a algún proyecto deinvestigació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 vezexpedida la convocatoria y evaluados los docentes que hicieron el trámite, se ingresará

79




en el sistema el monto y periodo de los estímulos para aquellos docentes que se hubieranvisto beneficiados.

En aquellas instituciones en donde además de personal administrativo (trabajadores) ypersonal docente exista otra clasificación (por ejemplo empleados de confianza), se deberáagregar un subsistema adicional, en donde se den los movimientos conforme a lascaracterí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 detabuladores, estímulos y descuentos, los procesos para el cálculo y aplicación dedescuentos 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 queen muchas de las universidades el porcentaje más alto de recursos lo constituye el pagode este rubro.

La generación de la nómina es un procedimiento ligado de manera muy especial con elmódulo financiero. Conforme a la contabilidad de fondos el sistema tendrá que dejarperfectamente establecido el desglose por unidad responsable y fondo, así como corroborarque 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 oen 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, querecibirán su pago. El usuario entrará a una pantalla, donde podrá teclear el periodo para lanómina que se elaborará. Tendrá la opción de generar una nómina en forma general o porunidad 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 lageneración de la nómina realizarán diferentes tipos de movimientos para las cuales seutilizará 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 (estesalario será con base en la categoría nivel de los trabajadores, el cual existe en tablas yadeterminadas y calculadas por cada institución). Estos movimientos se registrarán a nivelsistema en la base de datos de movimientos, el cual almacenará cada uno de losmovimientos que se realizaron para cada trabajador. Cuando se llegue a la quincena y

80



sea necesario elaborar la prenómina o nómina, a cada trabajador se le calculará su sueldofinal, una vez que se haya sumado (o restado, según sea el caso) el monto de cada unode los movimientos en los que participó a lo largo de la quincena. El Catálogo dePercepciones y Deducciones se caracteriza porque se aplica de manera general a todoslos 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 basede datos de movimientos se transferirán a una tabla histórica de movimientos, la cualcontendrá la información de todas las nóminas que ha generado la institución. En la tablade movimientos se borrará toda la información, por lo cual ya estará lista para que durantela 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 unestatus (cerrado, abierto), lo cual para poder realizar los movimientos es necesario queeste “Abierta”, ya que a la quincena a la hora de generar la nómina, se cerrará la base dedatos, 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ána 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

81




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á registradoen 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, parala revisión de los diferentes departamentos involucrados con esta actividad. Ademásde la nómina, la cual permitirá efectuar los pagos correspondientes por parte detesorerí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 prestacionesa las que tiene derecho todo el personal, como pueden ser préstamos en efectivo, enespecie, 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 delcatá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 delsalario.

82



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 depercepciones 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 empleadosde la universidad (docentes, administrativos y trabajadores) ya sea que se trate deprestaciones 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.

83




Se refiere al proceso de asignar al trabajador las prestaciones que se merece. A travésde una pantalla, se tecleará la clave del docente y de la prestación, y al relacionarla (alpresionar el botón de Actualizar) quedará la asignación registrada en la base de datos delsistema.

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 quepermitan tener un control sobre el personal de la institución. Entre otros los que acontinuación se describen:

Se requiere que el sistema muestre una pantalla de reportes, en donde se puedaseleccionar el tipo de consulta o reporte que se desea. Con base en el tipo de reporte enla 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 sehagan las consultas, los departamentos que tengan acceso a realizar modificaciones enel sistema podrán efectuar los cambios de algún registro en particular con sólo dar dobleclick 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 susdatos

El sistema generará un reporte que permita verificar todos los movimientos que sehubieran 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 aspirantesa ingresar a cada institución. En caso de que se requiera de un pago para realizar estetrámite el sistema deberá verificar que exista o se deberá presentar una ficha del banco ola tesorería que avale el mismo.

84



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 seleccionadosestos 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 aun nuevo ciclo escolar. Este procedimiento deberá ir acompañado con el o los pagoscorrespondientes, 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 escogidosiempre y cuando haya cupo, el plan de estudios lo permita y haya realizado los pagoscorrespondientes.

Revalidaciones

Aquí se dan de alta todos los alumnos que ingresan a la institución sin el proceso deselecció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 oreconocimiento).

Control de grupos

Mediante este procedimiento se asigna una materia/grupo a un salón y a un profesordeterminado.

• El encargado de Control Escolar de la escuela revisa la lista de salones/inmueblesdisponibles.

• A cada salón se le asigna una materia/grupo, señalando el número de horas que seocuparán.

• Cada materia/grupo, asignada previamente a un salón y a un horario, es destinada aun profesor, relacionándola con la lista de profesores activos disponibles, ingresadaa 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 alfinal 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 cuentecon las características necesarias de acuerdo con el tipo de curso a impartir.

85




• Se imprime la lista de cada materia impartida por el maestro. La impresión se realizaen formatos para lectura óptica14 (acta de calificaciones).

• El profesor registra las calificaciones en las actas rellenando los ovalitoscorrespondientes. Firma la hoja y la regresa a la oficina de Control Escolar de laescuela.

• El Departamento de Servicios Escolares recibe las actas de calificaciones firmadasy llenadas por los profesores.

• Se capturan las actas en el sistema a través del lector óptico, se encuadernan y searchivan.

• En caso de que el acta no pueda ser leída correctamente, se regresa al profesorpara que la vuelva a llenar y a firmar.

Control de expedientes

Procedimiento mediante el cual se mantienen actualizados los expedientes de todoslos alumnos de cada institución. Este expediente estará conformado con toda la informaciónexistente 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 dedocumentos 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 yfotografía)

86



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, entreotros aspectos, para cada una de las materias cursadas, el número de acta en la queapareció 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ísticadetallada o total. El detalle es un listado con datos, asimismo permitirá almacenar lasestadísticas por si alguna de ellas se quisiera comparar en una gráfica.

87




Para poder graficar estadísticas, éstas se debieron haber grabado con anterioridad, seasignan las estadísticas que se encuentran almacenadas y que se quieran graficar y elsistema la ejecuta inmediatamente poniendo en el espacio el resultado. Pueden hacersecomparaciones hasta de 24 columnas, esto es, que se pueden crear 24 estadísticasdiferentes, grabarlas y compararlas en una gráfica. Una vez que se asignan todas lasestadísticas, se presiona el botón graficar y se obtiene el resultado, que puede mandarsea 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 siguientesdocumentos:

• 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óny 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.

88



Expedición de credencial

Es recomendable que los sistemas de control escolar contemplen la credencializacióncomo 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 financieroy de recursos humanos. La información de los docentes se obtendrá, partir de ligas con labase de datos de recursos humanos. Todos los movimientos de control escolar querequieran de la realización de un pago se tendrán que reflejar conforme a la cuenta, fondoy función que se maneja en el módulo de financiero.


89

Contabilidad matricial

P R O N A D

IV. CONTABILIDAD MATRICIAL

Introducción

La contabilidad es un medio para brindar información en relación con las actividadesfinancieras realizadas por las instituciones públicas o privadas.

En la actualidad, los métodos contables brindan con mayor facilidad y flexibilidadinformación financiera más completa y detallada.

Esta información financiera es valiosa porque permite evaluar acciones pasadas y ayudaa preparar planes para el futuro por medio de los cuales se puedan alcanzar objetivos ymetas financieras.

La calidad de la información financiera ha sido fuertemente criticada por los directivosque suelen tomar decisiones estratégicas. Lo anterior ha propiciado que se hayan propuestoy 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 necesidadesinternas y externas de la administración con orientación pragmática, destinada a facilitar lasfunciones 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 mismascaracterísticas que para una empresa comercial:

a) Proveer información para la planeación y la elaboración del presupuesto, instrumentosa través de los cuales se espera que el uso de los recursos disponibles sea máseficiente.

b) Proporcionar información financiera para el control de las operaciones institucionalesa 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 principiosde contabilidad generalmente aceptados.

Respecto a sus objetivos organizacionales, éstos presentan diferencia con las empresascomerciales.

a) Las empresas comerciales tienen fines de lucro.


90P R O N A D

b) Las instituciones de educación pública persiguen fines de servicio, por lo que no tienenincentivos de lucro, y requieren cada vez de manejar, de una manera más eficiente, elfinanciamiento 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 unade ellas. Mientras que para la empresa comercial el efectivo es producto de venta de bienesy servicios y son su principal fuente de recursos, y sus ganancias están determinadas por larelación que guardan sus ingresos respecto a sus gastos, para una institución de educaciónmás del 80% de sus ingresos provienen del subsidio, y sus recursos son controlados deacuerdo 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 deacuerdo con los principios de contabilidad generalmente aceptados.

Sin embargo, en contabilidad, como en muchas disciplinas, hay desacuerdos en lamanera de presentar situaciones especiales. En tales situaciones la metodología contabledifiere de un campus a otro.

El diseño de un sistema contable se puede determinar, en parte, por la naturaleza de lainstitución, así como de su historia.

Un sistema de contabilidad no necesariamente refleja todas las operaciones financierasque 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 legadosa 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 incluidosen los estados financieros.

Esto nos lleva a pensar que el sistema de contabilidad de la institución puede noproporcionar una realidad completa de la situación financiera.

Las organizaciones no lucrativas como grupo difieren de las empresas en cuanto a queaquéllas son receptoras del subsidio, donativos, contribuciones y apropiaciones, queestán restringidas para su uso, ya que su utilización está asociada a propósitos, funciones yactividades en particular.

Un donante, por ejemplo, puede especificar que su aportación sea utilizada exclusivamentepara becas.


91


P R O N A D

Bajo este sentido, la institución no tiene ninguna otra autoridad para disponer del recursoque no sea para el fin que fue dado.

Dada esta característica en particular, que distingue la contabilidad que debe seguir unainstitució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 debase para la codificación de una operación financiera. Para estructurar el código, esnecesario haber diseñado ya los catálogos. El código a utilizar debe tener los siguientesdatos:

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 ydentro del patrimonio lo relativo a sus adiciones y/o disminuciones, es decir, ingresos ygastos.

El número de dígitos que se estimen para cada componente, dependerá de lasnecesidades de información de cada institución. Por otro lado, no es necesario seguir elorden presentado, ya que cada institución lo puede adaptar a su sistema actual. Lo importantees el nivel de agrupamiento y lo que cada posición signifique. La única condicionante es queel código inicie con el fondo.

Fondo

Es una entidad contable que tiene un grupo de cuentas autobalanceables, es decir, quetiene 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 relacionadascon subsidios que tengan restricciones particulares para su uso, fuentes de recursosrestringidos, o importes designados que han sido establecidos por la junta de gobierno de lainstitución. Esas entidades contables se establecen para asegurarse de que los recursosserán utilizados de acuerdo con las restricciones impuestas, en este caso, por el otorgante


92P R O N A D

del recurso o bien por la junta de gobierno. Los fondos utilizados en contabilidad matricialson:

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óninstitucional. 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óneducativa, que tiene a su cargo una o varias de las funciones que realiza la institución, o bienen las que participa.

Cuenta

Identifica al conjunto homogéneo y ordenado de bienes y servicios, el cual, de acuerdocon 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.


93


P R O N A D

• Compatibilidad entre el presupuesto y el desempeño real, lo cual permite generarinformación de avance presupuestal por unidad orgánica.

Los retos

El gran reto para la universidad es, sin lugar a dudas, eficientar sus procesosadministrativos para a su vez eficientar la operación de la universidad. Para lo cual, entreotras cosas, es necesario contar con información acerca del desempeño financiero deinstituciones similares. Contribuir a la homologación y estandarización del sistema deinformación financiera de las universidades, indudablemente proporcionará un mejor usode los recursos y una participación mas útil en el esfuerzo de la educación superior en elpaís.


95

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 entidadesque se refieran a personas. Lo anterior en función de que existe una disposición a unificartodos 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ónque se asigna a todas las personas que viven en el territorio nacional, así como a losmexicanos que residen en el extranjero. El Registro Nacional de Población (RENAPO) es lainstancia 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, quese generan a partir de los datos contenidos en el documento probatorio de identidad (actade 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 sucorrecta integración.

¿Qué datos contiene la CURP?

Un ejemplo de esto sería el siguiente: tenemos a una persona con nombre Ricardo AlamánPérez, que nació en el Distrito Federal, el 21 de marzo de 1963, su CURP sería AAPR630321 H DF LRC 09

• Las primeras cuatro letras, AAPR, se refieren a la inicial y primera vocal interna delprimer 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 ydí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



¿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 lasinstituciones públicas.

La CURP se incorporará paulatinamente a todos los documentos oficiales, como sedescribe a continuación como ejemplo, a fin de fortalecer las condiciones de seguridadjurídica de la población; mejorar los vínculos entre ésta y las instancias de gobierno, parafacilitar la prestación de los bienes y servicios, y simplificar la administración pública al eliminarla diversidad de claves de registro de personas, entre otros.

En materia de Tipo de documento

• Registro civil Acta de nacimiento, matrimonio, adopción, etcétera.• Salud Cartilla de vacunación, expediente médico, identificación,

etcétera.• Educación Registro escolar, constancia y certificado de estudios,

identificación, etcétera.• Prestación de

servicios (trabajo) Solicitud de empleo, registro individual, expediente, nómina,recibo de pago, identificación, etcétera.

• Seguridad social Cuenta individual del sistema de ahorro para el retiro,expediente, identificación

• Desarrollo social Registro individual, identificación, etc., así como en elpasaporte, 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 laatribución para registrar y acreditar la identidad de todas las personas residentes en el paísy 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.


97

La clave única de registro poblacional (CURP)


El 23 de octubre de 1999, se publicó en el Diario Oficial de la Federación el AcuerdoPresidencial 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 elterritorio 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 deintegrar 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 cualquierregistro de personas.


98P R O N A D


99

Consideraciones generales sobre la ingeniería de software

P R O N A D

VI. CONSIDERACIONES GENERALES SOBRE LA INGENIERÍA DE SOFTWARE

La ingeniería de software es una disciplina que integra proceso, método y herramientaspara el desarrollo del software de computadoras. Sobre ésta, se está llevando a cabo unafuerte 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 vercon una epistemología basada en el principio de autoridad, ya que la mayoría de los tratadosde ingeniería de software están basados en una combinación de experiencia anecdótica yautoridad humana, raramente se acompañan de evidencia lógica o experimental. Estoprovoca la carencia de una base sólida que le dé un carácter científico a la ingeniería desoftware.

El segundo tiene que ver con un principio práctico aplicado de manera generalizada en laingeniería de software y es el famoso precepto de divide y vencerás, es decir, se ha venidoaplicando dogmáticamente este principio, separando las actividades propias del análisisde las actividades de diseño.

Por otra parte se presupone que una vez establecido el algoritmo, que se obtiene de ladivisión del proceso de desarrollo de software en diversas etapas, se asume que es factibledesarrollarlo sin considerar la posibilidad de llevar a cabo la construcción de un algoritmoque 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 lasactividades de diseño y las de análisis. Dado lo anterior se puede entonces establecerque 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á necesariamentereferido 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 porla 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 deun sistema de información no puede ser tajante ni rígida. A continuación describimos deforma muy general algunos modelos y metodología para la construcción de un sistema. Cadaparadigma exhibe ventajas y desventajas, sin embargo, mantiene una serie de fasesgené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 linealsecuencial es un enfoque sistemático, secuencial del desarrollo del software que comienzaen un nivel de sistemas y progresa con el análisis, diseño, codificación, pruebas y



mantenimiento. Modelo según el ciclo de ingeniería convencional, el modelo lineal secuencialacompaña a las actividades siguientes:

Ingeniería y modelado de sistemas/información. Como software siempre forma parte deun sistema más grande (o empresa), el trabajo comienza estableciendo requisitos de todoslos elementos del sistema y asignando al software algún subgrupo de estos requisitos. Estavisión del sistema es esencial cuando el software se debe interconectar con otros elementoscomo hardware, personas y bases de datos. La ingeniería y el análisis de sistemas acompañaa los requisitos que se recogen en el nivel del sistema con una pequeña parte de análisis yde diseño. La ingeniería de información acompaña a los requisitos que se recogen en elnivel 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 intensificay 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 deinformació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 yde software.

Diseño. El diseño del software es realmente un proceso de muchos pasos que se centraen cuatro atributos distintos de un programa: estructura de datos, representaciones de interfazy detalle procedimental (algoritmo). El proceso de diseño traduce requisitos en unarepresentación del software que se pueda evaluar por calidad antes de que comience lageneración del código. Al igual que los requisitos, el diseño se documenta y se hace partede la configuración del software.

Generación de código. El diseño se debe traducir en forma legible por la máquina. Elpaso de generación de código lleva a cabo esta tarea. Si se lleva a cabo el diseño de unaforma 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, asegurandoque todas las sentencias se han comprobado, en los procesos externos funcionales, esdecir, que la realización de las pruebas para la detección de errores y sentirse seguro de laentrada definida produzca resultados reales de acuerdo con los resultados requeridos.

Mantenimiento. El software individualmente sufrirá cambios después de ser entregado alcliente (una excepción posible es el software empotrado). Se producirán cambios porque sehan encontrado errores, porque el software debe adaptarse para acoplarse a los cambiosde su entorno externo ( p. ej.: se requiere un cambio debido a un sistema operativo o dispositivoperiférico nuevo), o porque el cliente requiere mejoras funcionales o de rendimiento. Elmantenimiento vuelve a aplicar cada una de las fases precedentes a un programa ya existentey no a uno nuevo.

El modelo lineal secuencial es el paradigma más antiguo y más extensamente utilizadoen la ingeniería del software. Sin embargo, la crítica del paradigma ha puesto en duda su


101


P R O N A D

eficacia. Entre los problemas que se encuentran algunas veces en el modelo lineal secuencialse 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. Comoresultado, los cambios pueden causar confusión cuando el equipo del proyectocomienza.

2. A menudo es difícil que el usuario exponga explícitamente todos los requisitos. El modelolineal secuencial lo requiere y tiene dificultades a la hora de acomodar la incertidumbrenatural 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 serdesastroso 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 deciclo de vida clásico lleva a “estados de bloqueo” en el que algunos miembros delequipo del proyecto deben esperar a otros miembros del mismo para completar tareasdependientes. En efecto, el tiempo que se pasa esperando puede sobrepasar el tiempoque se emplea en el trabajo productivo. Los estados de bloqueo tienden a ser másimportantes 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ásicotiene un lugar definido e importante en el trabajo de la ingeniería de software. Proporcionauna plantilla en la que se encuentran métodos para análisis, diseño, codificación, pruebasy mantenimiento. El ciclo de vida clásico sigue siendo el modelo de proceso másextensamente utilizado por la ingeniería del software. Pese a tener debilidades, essignificativamente 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 noidentifica los requisitos detallados de entrada, procesamiento o salida. En otros casos, elresponsable 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 tomarsela interacción hombre-máquina. En éstas y en muchas otras situaciones, un paradigma deconstrucción de prototipos puede ofrecer el mejor enfoque.

El paradigma de construcción de prototipos comienza con la recolección de requisitos. Eldesarrollador 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ásdefinición. Entonces aparece un “diseño rápido”. El diseño rápido se centra en unarepresentació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



prototipo. El prototipo lo evalúa el usuario y lo utiliza para refinar los requisitos de software adesarrollar. 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 requisitosdel software. Si se construye un prototipo de trabajo, el desarrollador intenta hacer uso delos fragmentos del programa ya existentes o aplica herramientas (p.ej.: generadores deinformes, 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 alternativasino comenzar de nuevo y construir una versión rediseñada en la que se resuelvan estosproblemas. Cuando se utiliza un concepto nuevo de sistema o de una tecnología nueva, setiene que construir un sistema que no sirva y se tenga que tirar, incluso la mejor planificaciónno es omnisciente como para que esté perfecta la primera vez. Por tanto, la pregunta sobrela gestión no es si construir un sistema piloto y tirarlo. La única pregunta es si planificar deantemano 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 tenerconocimiento 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 calidaddel software global o la facilidad de mantenimiento a largo plazo. Cuando se informaque el producto se debe construir otra vez para que se puedan mantener los nivelesaltos 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 frecuentela gestión de desarrollo del software es muy lenta.

2. El desarrollador a menudo hace compromisos de implementación para hacer que elprototipo funcione rápidamente. Se puede utilizar un sistema operativo o lenguaje deprogramació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, yolvidarse de las razones por las que son inadecuadas. La selección menos ideal ahoraes una parte integral del sistema.

Aunque pueden surgir problemas, la construcción de prototipos puede ser un paradigmaefectivo 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 paraservir como un mecanismo de definición de requisitos. Entonces se descarta (al menos enpartes) y se realiza la ingeniería del software con una visión hacia la calidad y facilidad demantenimiento.


103


P R O N A D

El modelo DRA

El Desarrollo Rápido de Aplicaciones (DRA) (Rapid Application Development, RDA) esun modelo de proceso del desarrollo del software lineal secuencial que enfatiza un ciclo dedesarrollo extremadamente corto. El modelo DRA es una adaptación a “alta velocidad” delmodelo lineal secuencial en el que se logra el desarrollo rápido, utilizando un enfoque deconstrucció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 “sistemacompletamente 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 enfoqueDRA comprende las siguientes fases.

Modelado de gestión. El flujo de información entre las funciones de gestión se modela deforma que responda a las siguientes preguntas: ¿Qué información conduce al proceso degestión? ¿Qué información se genera? ¿Quién la genera? ¿Adónde va la información? ¿Quiénla procesa?

Modelado de datos. El flujo de información definido como la parte de la fase de modeladode 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 relacionesentre estos objetos.

Modelado de proceso. Los objetos de datos definidos en la fase de modelado de datosquedan transformados para lograr el flujo de información necesario para implementar unafunció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 cuartageneració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 todoslos 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 comprobadomuchos 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 detiempo impuestas en un proyecto DRA demandan “ámbito en escalas”. Si una aplicación degestión puede modularse de forma que permita completarse cada una de las funcionesprincipales en menos de tres meses (utilizando el enfoque descrito anteriormente), es uncandidato del DRA. Cada una de las funciones pueden ser afrontadas por un equipo delDRA 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 humanossuficientes como para crear el número correcto de equipos DRA.



• DRA requiere clientes y desarrolladores comprometidos en las rápidas actividadesnecesarias para completar un sistema en un marco de tiempo abreviado. Si no haycompromiso, 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 puedemodularizar adecuadamente, la construcción de los componentes necesarios paraDRA será problemática. Si está en juego el alto rendimiento, y se va a conseguir elrendimiento convirtiendo interfaces en componentes de sistemas, puede suceder queel enfoque DRA no funcione. DRA no es adecuado cuando los riesgos técnicos sonaltos. Esto ocurre cuando una nueva aplicación hace uso de las tecnologías nuevas, ocuando el nuevo software requiere un alto grado de interoperatividad con programasde computadoras ya existentes.

Técnicas de cuarta generación

El término “técnicas de cuarta generación” (T4G) abarca un amplio espectro deherramientas de software y la especificación de algunas características del software de altonivel. Luego, la herramienta genera automáticamente el código fuente basándose en laespecificación del técnico. Cada vez parece más evidente que cuanto mayor sea el nivel enel que se especifique el software, más rápido se podrá construir el programa. El paradigmaT4G para la ingeniería del software se orienta hacia la posibilidad de especificar éste usandoformas de lenguaje especializado o notaciones gráficas que describan el problema que sedebe resolver en términos entendibles para el cliente. Actualmente, un entorno para eldesarrollo de software que soporte el paradigma T4G puede incluir todas o algunas de lassiguientes 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 deaplicación muy específicos, aunque actualmente los entornos T4G se han extendido a todasla 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 directamentea un prototipo operativo. Sin embargo, en la práctica no se puede hacer eso. El clientepuede no estar seguro de lo que necesita; ser ambiguo en la especificación de hechos quele son conocidos, y no ser capaz o no estar dispuesto a especificar la información en laforma en que se puede utilizar una herramienta T4. Por esta razón, el diálogo usuario-desarrollador, descrito por los otros paradigmas, sigue siendo una parte esencial del enfoqueT4G.

Para aplicaciones pequeñas, se puede ir directamente desde el paso de recolección derequisitos al paso de implementación, usando un lenguaje de cuarta generación noprocedimental ( L4G). Sin embargo, es necesario un mayor esfuerzo para desarrollar unaestrategia 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 desarrollasoftware mediante los enfoques convencionales.


105


P R O N A D

La implementación mediante L4G permite, al que desarrolla el software, centrarse en larepresentación de los resultados deseados, lo que se traduce automáticamente en un códigofuente que produce dichos resultados.

Obviamente, debe existir una estructura de datos con información relevante y a la que elL4G pueda acceder rápidamente.

Para transformar una implementación T4G en un producto, el que lo desarrolla debeapoyarse 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 softwaredesarrollado con T4G debe ser construido de modo que facilite la realización delmantenimiento de forma expeditiva.

Al igual que todos los paradigmas del software, el modelo T4G tiene ventajas einconvenientes. Los defensores aducen reducciones drásticas en el tiempo de desarrollodel 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 utilizarque los lenguajes de programación, que el código fuente producido por tales herramientases “ineficiente” y que el mantenimiento de grandes sistemas de software desarrolladosmediante T4G, es cuestionable.

1. El uso de T4G ha crecido considerablemente en la última década y ahora es un enfoqueviable para muchas de las diferentes áreas de aplicación. Junto con las herramientasde ingeniería de software asistida por computadora (Computer-Aided SoftwareEngineering, CASE) los generadores de código T4G ofrecen una solución fiable amuchos problemas de software.

2. Los datos recogidos en compañías que usan T4G parecen indicar que el tiemporequerido para producir software se reduce mucho para aplicaciones pequeñas ytamañ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 elmismo o más tiempo de análisis, diseño y prueba (actividades de ingeniería delsoftware), perdiéndose así un tiempo sustancial que se ahorra mediante la eliminaciónde la codificación.

Resumiendo, las técnicas de cuarta generación ya se han convertido en una parteimportante del desarrollo del software. Cuando se combinan con enfoques de ensamblajede componentes, el paradigma T4G se puede convertir en el enfoque dominante hacia eldesarrollo 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 durantelas tres primeras décadas. Antiguamente el diseño se centraba en los criterios de desarrollode programas modulares y métodos para refinar la arquitectura software de una maneradescendente en la jerarquía. Los aspectos procedimentales de la definición del diseño del



modelo evolucionaron hacia una filosofía denominada programación estructurada. Algunostrabajos posteriores proponían métodos para la transformación de flujo de datos o de laestructura 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 anteriormentese aplican en la industria. Al igual que los métodos de análisis, todos los métodos de diseñode software presentan unas heurísticas y notaciones únicas. Así como una visión algo particularde cómo lograr la calidad del diseño. Sin embargo, todos estos métodos tienen unascaracterísticas comunes: (1) un mecanismo para la transformación de un modelo de análisisen una representación del diseño, (2) una notación para representar componentes funcionalesy sus interfaces, (3) heurísticas para el refinamiento y la participación y (4) consejos paramejorar la calidad .

Independientemente del método del diseño que se emplee, un ingeniero de softwaredebería aplicar un conjunto de principios fundamentales y conceptos básicos al diseño dedatos, arquitectónico, de interfaz y procedimental. Estos principios y conceptos se consideranen las siguientes secciones.

El diseño del software es un proceso y un modelo a la vez. El proceso de diseño es unconjunto de pasos repetitivos que permiten al diseñador describir todos los aspectos delsoftware a construir. Hay que aclarar, sin embargo, que el proceso del diseño no es unsimple “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. Empiezarepresentando la totalidad de lo que se va construir (p.ej.: una representación tridimensionalde la casa) y lentamente lo va refinando para proporcionar una directriz y construir cadadetalle (p.ej.: el plano de las cañerías ). Similarmente, el modelo de diseño creado para elsoftware proporciona varias visiones diferentes del programa de computadora.

Los principios básicos del diseño permiten al ingeniero del software navegar en el procesode diseño. Davis sugiere un conjunto de principios para el diseño del software que hansido adaptados y ampliados en la siguiente lista:

• El proceso de diseño no debería ponerse “orejeras”. Un buen diseñador deberíaconsiderar enfoques alternativos, juzgando cada uno con base en los requisitos delproblema, 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 solomodelo del elemento de diseño se refiere a menudo a múltiples requisitos, es necesariotener los medios para hacer un seguimiento de cómo ha satisfecho los requisitos dichomodelo.

• El diseño no debe inventar nada que ya esté inventado. Los sistemas se construyenusando un conjunto de estructuras de diseño, de las cuales muchas se han utilizadoanteriormente. Estas estructuras, a menudo denominadas componentes de diseñoreutilizables, deben considerarse siempre antes que reinventar nada. ¡El tiempo es


107


P R O N A D

corto y los recursos limitados! El tiempo invertido en diseño debe concentrarse enpresentar 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 delsoftware (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 pareceque sólo una persona desarrolló todo el conjunto. Se deberían definir normas de estiloy 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 loscomponentes del diseño.

• El diseño debería estructurase para admitir cambios. Muchos de los conceptos dediseño permite a éste conseguir este principio.

• El diseño debería estructurarse para degradarse poco a poco, incluso cuando seenfrentan a datos, sucesos o condiciones operativas aberrantes. Un programa biendiseñado no debería “explotar” nunca. Debería diseñarse para aceptar circunstanciasinusuales, 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 secrean diseños procedimentales detallados para los componentes de un programa, elnivel 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ñosdetalles 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 paraayudar al diseñador en la valoración de la calidad .

• Se debería revisar el diseño para minimizar los errores conceptuales (semánticos). Aveces hay tendencia a concentrarse en minucias cundo se revisa el diseño, no dejandolos árboles ver el bosque. El diseñador debe asegurarse de que se revisen los elementosconceptuales principales del diseño (omisiones, ambigüedades, inconsistencias) antesde preocuparse por la sintaxis del modelo de diseño.

Cuando se aplican apropiadamente los principios del diseño señalados anteriormente, elingeniero 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 observarlos usuarios (p. ej.: velocidad, fiabilidad, corrección, utilidad). Los factores de calidad internosson importantes para los ingenieros del software, permiten un diseño de alta calidad desdela perspectiva técnica. Para conseguir los factores de calidad interna, el diseñador debeentender los conceptos básicos de diseño.


109

Conceptos básicos sobre las bases de datos relacionales

P R O N A D

VII. CONCEPTOS BÁSICOS SOBRE LAS BASES DE DATOSRELACIONALES

El modelo relacional es un modelo muy elegante y claro, ha constituido los cimientos de laindustria de las bases de datos durante casi 20 años. El relativamente pequeño número deconceptos existentes en la teoría relacional ha ayudado a convertir esta técnica en un estándarindustrial. Los diseñadores relacionales han sido capaces de aislar la complejidad deldesarrollo físico de las bases de datos respecto al diseño lógico del sistema, proporcionandoasí una interfaz sencilla para los diseñadores de aplicación.

Durante las dos últimas décadas hemos madurado como industria. Muchos de nosotroshemos sentido la necesidad de contar con un entorno de modelización más rico que seadaptara 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íanintroducirse en el mundo de las bases de datos y que podrían mejorar la eficiencia de lasmismas.

Las bases de datos relacionales cuentan con un vocabulario relativamente limitado. Hemosimplementado estructuras utilizando archivos planos diseñados juiciosamente yposteriormente, hemos introducido algunos tipos de índices distintos en varios campos deesos archivos. En lo referente al acceso, los vínculos entre tablas sólo se especificaban deforma lógica, por lo que los punteros de referencia se llevaban a cabo mediante clavesexternas. No necesitábamos contar con vínculos explícitos entre las tablas. Las limitacionesde integridad referencial eran, simplemente pequeños trozos de código que evitaban laintroducció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ícitamentealguna actividad cuando se insertaba, actualizaba o borraba algún registro, y se almacenabanunidades de programa en la base de datos. Finalmente, podíamos agrupar tablas para mejorarel rendimiento. Todas estas estrategias limitaban nuestra forma de pensar. En una base dedatos relacional, cada tabla es virtualmente una estructura independiente.

En la creación de modelos de relaciones lógicas de entidades (ER) teníamos entidadesque eran subconjuntos de otras entidades. Por ejemplo, los empleados asalariados eranun subconjunto de todos los empleados. De la misma forma, teníamos entidades quedependían de otras entidades, tales como detalles OC, que dependían de órdenes decompra. Sin embargo, nuestra capacidad para representar estas estructuras utilizandobases de datos es limitada . Paradójicamente las bases de datos orientadas a objetosretienen 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 deobjetivo 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 listasvinculadas y los punteros. Tenemos que recordar cómo era el mundo de las bases de datosantes de la aparición de la metodología relacional a principios de la década de los años



ochenta. Todavía siguen existiendo (al menos hasta que el problema del año 2000 acabecon ellas) bases de alto rendimiento que utilizan archivos CODASYL, ISAM y VSAM escritosen COBOL. Las modificaciones a las bases de datos CODASYL suelen exigir meses deesfuerzo. Hace ya algunos años nos encontramos con un antiguo proyecto COBOL en el quesurgió un nuevo requisito, cambiar la anchura de un campo de 10 a 12 caracteres. Estapequeñ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 algunosdías de trabajo. Si la aplicación se generó con una herramienta CASE integrada, la realizaciónde 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ónde informes era una tarea muy difícil. Si un determinado informe no había sido tomado encuenta durante las especificaciones originales del diseño, podría exigir semanas de trabajoescribir un nuevo informe (suponiendo que fuera posible escribirlo). Las modificaciones alas estructuras de datos subyacentes eran muy engorrosas. Los cambios más pequeñosparecían exigir un rediseño importante del sistema. No estamos afirmando que todos estosproblemas 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 dearchivos planos. La normalización se consideraba como una curiosidad académica. Contiempo, al menos con la tercera forma normal, se pudo constatar que la normalización no erauna idea tan mala. En la era de las desnormalizaciones, ocurrida en la década de los añosochenta, tuvimos los mismos problemas con las estructuras relacionales que con los archivosplanos. Modificar una estructura de datos seguía siendo una labor difícil y cara, lo mismoocurría si se deseaba modificar una aplicación. En la década de los noventa, la mayoría delos diseñadores de datos habían podido comprobar que las fuertes desnormalizacionesefectuadas en los ochenta estaban pasando factura, causando problemas de forma masivaen 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 aobjeto comenzaron a introducirse en las bases de datos relacionales. Este tema implicó lageneralización de modelos creando estructuras abstractas, a la vez que todavía seguíamostrabajando en el entorno de bases de datos relacionales. En los últimos años, parte de lacomunidad de diseñadores de base de datos relacionales han abrazado ya la metodologíaorientada a objeto.

En la actualidad, es frecuente ver cierto nivel de modelización genérica en la mayoría delos sistemas. Por ejemplo, existe un estándar industrial para representar las unidadesorganizativas como una simple estructura recursiva, en lugar de utilizar tablasindependientes para regiones, divisiones y departamentos (o sea cual sea la estructura parauna determinada empresa).

Incluso, cada vez son más frecuentes los modelos más abstractos. En una conferenciacelebrada recientemente, alguien que diseñaba una base de datos de cuestionarios mepreguntó cómo podría manejar una tabla como varios cientos de columnas. Cada cuestionarioconsta de cientos de preguntas. Varias personas que se encontraban entre los asistentes


111


P R O N A D

respondieron que se debía modelizar el cuestionario introduciendo las preguntas en unatabla 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 estabaencontrando 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 funcionesorientadas a objeto. En segundo lugar, disponemos de un nuevo lenguaje de modelizaciónmás rico; nos referimos a UML frente al antiguo ERD. Como mencionamos anteriormente,estos nuevos conceptos incluyen realmente algunos de los viejos conceptos del pensamientoprerrelacional con listas vinculadas y punteros. Esta nueva integración de lo nuevo y de loviejo representa una gran oportunidad, pero también se debe tomar con precaución. En laactualidad, podemos construir estructuras relacionales que funcionan de manera más eficaz.Pero si no somos cuidadosos, podremos perder parte de la flexibilidad de las estructurasque 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 datosfrente al físico. El modelo lógico de datos representa el diseño de la base de datos, mientrasque el modelo físico representa la realización del diseño. Se utilizan palabras distintas paracomparar el diseño lógico y el diseño físico. Todo esto puede ser algo confuso. El siguienteesquema ayuda a clarificar esta terminología para poder seguir con nuestro debate:

Lógico relacional Lógico objeto FísicoEntidad Clase TablaAtributo Atributo Columna, campoInstancia Objeto Fila

Para asegurar la consistencia es importante clarificar las definiciones que son importantespara este análisis:

Entidad. Se trata de algo que tiene interés para la empresa, tal como un empleado, undepartamento 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 pensaren entidades. Es mejor pensar que una entidad es algo que tiene correspondencia en elmundo real. Cada instancia de la entidad departamento, por ejemplo, se corresponde conun departamento específico en la organización (o en el caso de la entidad persona, a unapersona específica). Existe una correspondencia directa entre entidades e instancias de lateoría relacional y clases y objetos, respectivamente, en teoría de objetos. Por ejemplo, parala entidad departamento podemos hablar de la clase departamento, que incluirá el objetocontabilidad.

Atributo. Se trata de una pieza de información que podemos extraer de un objeto o instanciade 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.



Clave primaria. Se trata de un concepto de teoría relacional que describe los atributos deuna 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 apropiadapara 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 hansido 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 datosrelacionales. 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 puedaservir 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 clavescandidatas.

Creación de un diagrama entidad-relación

El diagrama de entidad-relación permite que un ingeniero de software especifique losobjetos de datos que entran y salen de sistema, y las relaciones entre los objetos. Al igualque la mayoría de elementos del modelo de análisis y las relaciones entre objetos, el DERconstruye de una forma interactiva. Se toma el enfoque siguiente:

1. Durante la recopilación de requisitos, se pide que los clientes listen las “cosas” queafronta el proceso de aplicación y/o del negocio. Estas “cosas” evolucionan en unalista de objetos de datos de entrada y de salida así como entidades externas queproducen o consumen información.

2. Tomando un objeto cada vez, el analista y el cliente definen si existe una conexión (sinespecificarlo 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 deobjeto-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 todaslas parejas objeto-relación. Es normal descubrir omisiones a medida que el procesocontinúa. Objetos y relaciones nuevos se añadirán invariablemente a medida que crezcael 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.


113


P R O N A D

Reglas de normalización

Cuando decimos que una base de datos ha sido normalizada, no nos estamos refiriendoa normal en el sentido de regular u ordinario. En este contexto, normalizado (adjetivo derivadode la notación matemática de normal) significa ortogonal. Volviendo a nuestras olvidadasclases de álgebra lineal, recuerde que el término normalizado se utilizaba conjuntamentecon los vectores ortogonales en un espacio vectorial y en análisis del tipo: ¿puede unacombinació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, eneste caso, se está intentando desarrollar un conjunto de tablas en la base de datos que no sesuperpongan de manera inapropiada y que nos permitan almacenar toda la información quepueda contener la base de datos en la misma forma en que tres vectores unitarios ortogonalespueden generar un espacio de tres dimensiones.

No vamos a entrar en discusiones formales sobre normalización. Podrá encontrar estetipo 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 losnumerosos libros académicos que analizan las bases de datos. Iremos presentandodefiniciones de normalización con un sentido más práctico y más apropiado para los objetivosperseguidos por este libro.

¿Por qué queremos construir bases de datos normalizadas? La normalización nació enconjunción con el lenguaje de programación denominado SEQUEL. El teorema fundamentalde la teoría relacional es que si su base de datos se encuentra normalizada, podrá extraercualquier subconjunto de datos de ella utilizando operadores básicos de SEQUEL. Por estemotivo la normalización es tan importante. Puede ser muy complicado extraer informaciónde una base de datos no normalizada sin tener que desarrollar un código complejo, estasreglas de normalización fueron importantes en los modelos relacionales y siguen siendoimportantes en los modelos objeto-relacionales.

Todavía seguimos utilizando SQL+ o una extensión orientada a objeto de SQL (una versiónde SEQUEL) para manipular la información contenida en las bases de datos. Si no trabajamoscon bases de datos normalizadas, SQL puede no funcionar. Aunque una persona hayatrabajado durante toda su carrera profesional en entornos de DBMS, puede no conocer losentornos existentes antes de la aparición de las bases de datos racionales. El cambio deorientación del papel en la impresión de un informe llevaba, al menos, dos semanas. Confrecuencia, los intentos de realizar pequeñas modificaciones en una estructura de datosllevaban meses e incluso años de tiempo de desarrollo. Si la intención era incluir nuevasfunciones, nos encontrábamos con miradas vacías, movimientos de cabeza y respuestasdel tipo “dada la actual arquitectura del sistema, las modificaciones que usted propone no sepueden llevar a cabo”. Si abandonamos las reglas de normalización para la creación debases de datos orientadas a objeto, corremos el riesgo de dar un paso de gigante haciaatrás en términos de flexibilidad de los sistemas que desarrollaremos.


114P R O N A D

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 primeraforma 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 mostradaen 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ículosutilizando esta estructura. Naturalmente, siempre podemos añadir más columnas parapermitir la petición de más artículos. Podemos añadir suficientes columnas como para notener 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 conocerel número de veces que se ha solicitado un determinado artículo sería mirar en todas lascolumnas de artículos. Incluso, calcular el valor total de alguna factura exigirá mirar en varioslugares.

En el modelo relacional existe una forma de satisfacer la primera forma normal. Laestructura necesaria para resolver las violaciones contra la primera forma normal.

Es posible construir buenas bases de datos sin tener que adherirse a la primera formanormal. Los teóricos relacionales resolvieron hace mucho tiempo qué extensiones a la teoríarelacional son necesarias para poder trabajar con bases de datos que no cumplan la primeraforma normal. La idea es permitir que los arrays sean un tipo de datos. De esta forma sepueden obtener mejores rendimientos que en el caso de utilizar una base de datos relacionalestá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 primeraforma normal es incluso deseable. Simplemente, no puede coger una base de datos relacionalestándar y violar la primera forma normal sin un costo negativo. Sigue habiendo una preguntatrascendental: ¿existe alguna ocasión en la que desee estructurar una tabla en la que una desus columnas sea realmente un array o un conjunto de valores o registros? La respuesta esun “sí” incondicional.

Existen ocasiones en las que se necesita de manera inherente e inexcusable la utilizaciónde estructuras que no cumplan la primera forma normal. Hace años Cobb desarrolló lasextensiones 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 primeraforma normal es más complejo, pero es una decisión de cada diseñador determinar si deseadesarrollar estructuras de este tipo.

Esta tecnología es actualmente demasiado nueva como para que podamos proporcionardirectrices 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 deestructuras que no cumplan la primera forma normal y que los diseñadores acaparen másexperiencia en el manejo de este tipo de estructuras.


115


P R O N A D

Segunda forma normal

La segunda forma normal surge cuando cuenta con una clave primaria multiatributo. Estehecho 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 ciertoconocimiento del concepto de dependencia.

Dependencia

Dependencia es un concepto sutil relacionado con los datos. Si un atributo B depende deun atributo A, entonces, si se conoce el valor de A, sabremos lo suficiente para encontrar elvalor 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 contamoscon un ID único para cada persona, cómo un número de la seguridad social, también podremosconocer la estatura de la persona, empresa para la que trabaja, color de ojos, etc. Todosestos 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 estaturade la persona. Desde el punto de vista de bases de datos relacionales, la estatura no dependede 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 elejemplo de persona, si se conoce a la persona, entonces también podremos conocer suestatura, peso y cualquier otra característica. La clave primaria actúa como un sustituto de laque representa la instancia de la entidad.

Si sólo existe dependencia de una parte de la clave primaria, entonces se está violando lasegunda forma normal. Por ejemplo, si estamos analizando una entidad, tal como las llamadastelefónicas, identificar de forma única una llamada telefónica requiere tanto del número deteléfono que origina la llamada como la hora en que comenzó dicha llamada. Podríamosutilizar otras claves candidatas como claves primarias, pero éstas son correctas.

En esta entidad, podemos asumir que contamos con un atributo denominado ubicacióntelefónica. Dependiendo de lo que estemos modelando, esta situación puede ser o nouna violación de la segunda forma normal. Si el teléfono está situado sobre una mesa dedespacho, habremos violado la segunda forma normal porque la ubicación sólo dependedel número de teléfono. Sin embargo, si estamos modelando un teléfono móvil, cada llamadapuede haberse realizado desde una ubicación distinta, y no existirá una violación de la segundaforma normal. Este ejemplo subraya la necesidad de comprender claramente las reglas deljuego 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 especificacorrectamente la clave primaria. Por ejemplo, tenemos el siempre popular ejemplo del videoclub donde el objetivo es determinar una entidad que represente el alquiler de una cinta devideo. Incluso en muchos libros de texto, podrá encontrar que se han asignado como clavesprimarias 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 sepuede alquilar una misma cinta dos veces en el mismo día. De esta forma, cualquiera de losatributos asociados con los alquileres (facturas, etc.) sólo dependerán del ID de la cinta y de



la fecha de alquiler. Si se incluye el ID del cliente en la clave primaria, se estará violando lasegunda forma normal. Sin embargo, en este caso, esta violación no es particularmenteseria.

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 dependientede otro atributo que no forma parte de la clave primaria ni de las claves candidatas. Lasviolaciones de la tercera forma normal siempre son extremadamente serias. Cualquierviolació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. Nuestroprimer ejemplo de una base de datos diseñada pobremente (mostrada anteriormente en elapartado del ejemplo 1) es el clásico caso de una violación de la tercera forma normal. Es devital importancia que todo atributo que pertenezca a una entidad o tabla dependa de la claveprimaria o de alguna de las claves candidatas y no de ningún otro atributo de la tabla. Cuandoesto es así siempre se cumple que el atributo se encuentra en la tabla equivocada, o bien,que el modelo de datos no es correcto.


117

Políticas de seguridad para el control del acceso a la información

P R O N A D

VIII. POLÍTICAS DE SEGURIDAD PARA EL CONTROL DEL ACCESO ALA INFORMACIÓN

Dentro de las diferentes organizaciones resulta necesario que éstas cuenten con políticasde 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 quetrata 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 deuna 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 elpaso a ciertas partes conocidas como sensibles.

Pensemos en barreras de control como nombre de usuario/contraseñas en los sistemasUNIX; muros de seguridad (firewalls) en las redes.

Tener todo bajo llave y sólo después de verificar minuciosamente la identidad del usuarioy 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 alternativaes similar a tener todo bajo llave en el almacén y tener que mostrar su credencial o identificaciónpara entrar, esto sería la política de la prohibición.

El inconveniente fundamental es la afectación sensible de la sencillez, rapidez y serviciosque 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ólolas actividades sospechosas o más sensibles.

Permitir el acceso “libre” a todo usuario de los recursos del sistema tiene la ventaja de lalibre 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 constanteejecución) y el peligro más latente de encontrarse con problemas y fallas.


118P R O N A D

Respecto a esto podemos indicar que la programación en shell, awk y perl sonherramientas 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 delalmacé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 ciertosdepartamentos 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 ponemoscontroles de acceso, pero estando dentro sólo se supervisan algunas actividades. Cada unade estas políticas tiene sus ventajas e inconvenientes. La ventaja de esta política híbridaprohibir/supervisar es que permite la libre circulación en casi todos los departamentos y sóloanaliza 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 elcaso de realizarse un copia no permitida de datos, la información será inutilizable ya que seencuentra cifrada. La ventaja mayor es la libre circulación de la información que permite unmayor flujo y distribución.

Sin embargo, su desventaja es el desconocimiento y poca utilización en los corporativosde 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.

IX CASO PRÁCTICO

Introducción.

La computación, está considerada como uno de los pilares fundamentalesde finales de siglo que nos ayuda a crear valor, administrar, organizar y simplificarel proceso cotidiano. Sin embargo, adoptar una nueva tecnología, dada la inmensaproliferación de conceptos y herramientas computacionales existentes, muchasveces 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 masatecnológica nos está indigestando. No tenemos tiempo para procesarla. Noterminamos 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 esla excepción. Si se refiere a las áreas administrativas se aprecia mayordesarticulació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 integralde información administrativa de acuerdo a los estándares que PRONAD amarcado, deberá contará con la asignación de profesionales de tecnología de lainformación para trabajar con usuario en los departamentos involucrados, disponerde una base de datos de acuerdo a las características que marca el documento“Términos de Referencia” propuesto por PRONAD, con programas decapacitación en nuevas y avanzadas tecnologías, para brindar soluciones rápidasy efectivas, en áreas tales como: desarrollo, soporte, redes y telecomunicaciones.

El caso práctico que ofrece la Universidad Autónoma de Nayarit y laUniversidad Autónoma de San Luis Potosí, es de ejemplificar el esfuerzo deldiseñ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 decomprobación y que requiere mucho mayor esfuerzo para arreglarlo, de ahí laimportancia de tenerlos previstos desde el diseño.

La metodología utilizada en las instituciones que presentan en el casopráctico comprende primero un análisis conceptual.

Con una descripción detallada de la metodología a emplear como el análisisde requerimientos, incluyendo el análisis de estructurado de datos, métodos paracrear el modelo del sistema integral de información administrativa como diagramade clases, diagramas de flujo de datos, diagramas de entidad relación, etc.

Dentro del análisis se enfoca a la construcción de miniespecificaciones parala definición de los resultados obtenidos del diseño y la documentación requeridacomo producto final del análisis efectuado.

De definen los pasos importantes para la construcción del sistema integralde 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 delas consideraciones del diseño, propias del dominio de la aplicación administrativaque 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 tenganque rescribir las principales partes del sistema; los malos métodos de construcciónno se pueden forzar a que se tenga que hacer esto, sin embargo estos errorespueden introducir errores sutiles que pueden requerir días o incluso semanas paraencontrarlos y corregirlos, de manera que el diseño es básico para armar unmétodo de construcción.

En la parte de descripción de las miniespecificiones técnicas se aplica a lanómina en la institución e inicia desde la descripción del “Nombramiento” y susmovimientos de Altas, Bajas, Consultas, Modificaciones y Reportes, además desus variables estándares para su programación, esto mismo es para los módulode “Empleados”, y “Control de Plazas”.

La UAN presenta el diseño que son representados por el modelo decontexto y el modelo de eventos:

El modelo de contexto en el módulo general del subsistema financierorepresenta las ligas entre las Dependencias y la Caja por medio de una solicitudde reposición de cheques, los recibos a cobrar y los cheques generados asimismode 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 deIngresos, Caja, Contabilidad, Egresos, Programación del Pago, Reposición decheques, 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 escenarioscomo:

- La Dependencia programa un pago, aquí se presentan las 4 fasesdel proceso;

1. Diagrama de Estados que representa en forma de diagramasde flujo el proceso administrativo.

2. El Diagrama de transición de Estados analiza el estado actualen cada uno de los procesos involucrados

3. Diagrama de flujo de Objetos se crea un escenario completode la Programación de un pago,

4. Seguimiento de sucesos se revisa que los procesos internossean 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 aldiseño de la Base de Datos, y que a partir de los esquemas denominadosdiagramas de entidad relación para los procesos mencionados anteriormente.

Esto solo representan una parte de los procesos que pertenecen al sistemaen 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 CARGAINICIAL.

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 finde encontrar cómo trabaja y dónde debe mejorarse. Para realizar un buenanálisis se debe hacer hincapié en la investigación y las preguntas paraaprender como opera un sistema actualmente y para identificar losrequerimientos de información que todos los usuarios a todos los niveles tienenpara uno nuevo o modificado.

El análisis de sistemas funciona a través de la aplicación de unametodología o estrategia general cuyas actividades específicas bien podríanser diferentes de un caso a otro de acuerdo a las necesidades del sistema, auncuando los objetivos del proyecto fueran los mismos en ambos casos.

El análisis de sistemas implica un enfoque que toma una perspectivaglobal en el estudio y solución de un problema, por lo siguiente:

• Porque tiende a analizar la totalidad de los componentes oaspectos bajo estudio, así como sus interrelaciones.

• Porque no aborda detalladamente un subsistema o aspectoespecífico del sistema si no cuenta previamente con un panorama delambiente externo del mismo.

Esto significa que no se analiza un módulo o aspecto específico delsistema 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óndel analista al proceso del sistema le permite obtener información de primeramano en relación con la forma en que se llevan a cabo las actividades en elsistema. Al término de esta actividad el analista debe haber adquirido unconocimiento real de la información y los procesos que se realizan dentro delos alcances del sistema.

1.2. DOCUMENTACION DEL ANALISIS.

Definición de requerimientos y descripción de procesos del sistemausando análisis estructurado. Conforme el analista conoce el funcionamiento yflujos de información del sistema, este llevará a cabo la descripción yrepresentación de los mismos utilizando la metodología de AnálisisEstructurado.

La finalidad de esta actividad es que el analista conozca y analice elproceso, flujo de información y requerimientos a detalle del sistema y realice undocumento que pueda ser entendido y revisado por usuarios y desarrolladores.

La recomendación de efectuar la documentación a todo el sistemaintegral de información administrativa, es importante que cada programa deuna aplicación debe documentarse exhaustivamente con el fin de facilitar sufuturo 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 ysalida que utiliza el programa.

• �Diagrama de correspondencias entre ficheros de entrada ysalida.

• �Estructura del programa una vez integradas las estructurasde 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 deoperaciones.

o �Lógica esquemática (pseudocódigo).

o �Listado del programa fuente, compilado y sin errores.

o �Listado de referencias cruzadas para facilitar labúsqueda de variables y entidades a lo largo del programa, cuandosea necesario efectuar su mantenimiento.

o �Listado de ocupación de memoria.

o �Cualquier otro listado que proporcione el compilador osistema operativo.

Documentación de la prueba definitiva que se realizó para obtener laaceptación del programa, adjuntando juegos de ensayo, condiciones deprueba, 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ónde procesos para revisión y aprobación. Es conveniente que conforme elanalista avanza en la definición de requerimientos y descripción del proceso,también realice revisiones periódicas con el usuario, para evitar posiblesconfusiones y omisiones de requerimientos de información importantes porparte del analista.

Las actividades 1.1, 1.2, y 1.3 se llevan a cabo en forma repetitiva hastaque, tanto los usuarios como los analistas estén de acuerdo con la definición derequerimientos importantes por parte del analista.

2. DISEÑO.

El diseño es la tarea de llevar la presentación del modelo del mundo realal computacional y es un tanto difícil, ya que la información que se obtiene delusuario es imprecisa, parte de la intuición y esta en algunos casosdesordenada, tanto que de la máquina obtenemos la información de maneraprecisa, predecible y exacta por lo que el analista tiene que realizar estatransferencia 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 laDocumentación arrojada en el análisis.

Una de las metodologías de desarrollo de sistemas que permite asociarlas técnicas de análisis con el Diseño de Bases de Datos utilizando un modelode Datos para la obtención de tal diseño a partir de la especificación de análisisdel Sistema de Información es la SAER( Structured Analysis – EntityRelationship).

La metodología de diseño se lleva a cabo mediante los tres siguientespasos:

PRIMERO:

Utilizar la metodología de Análisis para producir un conjunto deespecificaciones 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 deDatos). La modelación conceptual de la Base de Datos se va a obtenermediante la utilización del modelo Entidad-Relación, cuyo objetivo es facilitar eldiseño de la Base de Datos por medio de diagramas.

Este modelo se basa en una percepción del mundo real que consiste deun conjunto de objetos básicos llamados entidades y de las relaciones enteesos objetos.

• Una Entidad es un objeto que puede distinguirse de otros. Ladistinción se logra asociando a cada entidad un conjunto de atributos quedescriben el objeto.

• Una relación es una asociación entre varias entidades.

TERCERO:

Generación del esquema global mediante el uso de técnicas deintegración de vistas. Para lograr el diagrama completo del diseño de la Basede Datos, se debe obtener del análisis todas las vistas de Proceso; e identificarlas vistas del usuario y vistas de almacenamiento.

Una vista de Proceso es el conjunto de datos que están involucradosen un proceso.

Una vista de usuario es el conjunto de datos que un usuariodeterminado desea consultar. NO es conveniente que todos los usuariospuedan ver el modelo conceptual completo. Las consideraciones de seguridadpueden 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:

Diagrama de Entidad Relación


Entidades que se involucran en el modulo de Ingresos


Entidades que se involucran en el modulo de Egresos

2.2. MODELACION DE PROCESOS.

Se valida a detalle con el modelo E-R todos los requerimientospresentados en el análisis sin omitir nada. En esta etapa el equipo dedesarrollo valida en forma contundente el diseño del modelo E-R a partir delaná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 estarealizando.

2.3. DISEÑO DE LA B.D.

Una vez que se aprueba la validación del diagrama Entidad-Relación elequipo de desarrollo transforma cada elemento del modelo E-R a tablas, deacuerdo 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 detablas relacionales que permitan almacenar la información con un mínimo deredundancia 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. Lafase de programación involucra la creación de los Archivos de almacenamiento(Bases de Datos) y la escritura de instrucciones en algún lenguaje deprogramación (programas) para implantar lo que el analista ha especificado y eldiseñ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 Directorios de Desarrollo yalmacenamiento de Datos.

• Definición e Inicialización de Carpetas de Documentación dela 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 acatálogos, que son necesarios para realizar los procesos de almacenamientode datos y de reportes. Son los que se programan primero por lo comentadoanteriormente, que son necesarios para programar los demás procesos delsistema.

3.4. PROCESOS DE TRANSACCIONES.

Son los procesos que involucran cálculos o registro masivo detransacciones e información.

3.5. REPORTES.

Son todos lo procesos que involucran la generación ó explotación deinformació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 lamitad del tiempo programado para su desarrollo, dependiendo de qué tancuidadosamente se hayan hecho las actividades iniciales de análisis, diseño yprogramació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ósitoes 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 (ylos resultados de los archivos actualizados) se examinan para ver si soncorrectos.

Prueba de recuperación. El propósito de este tipo de prueba esasegurar que el sistema pueda recuperarse adecuadamente de diversos tiposde 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 elproyecto simule (o provoque) fallas de hardware, fallas de corriente, etc.

Prueba de desempeño. El propósito de este tipo de prueba es asegurarque el sistema pueda manejar el volumen de datos y transacciones de entradaespecificados en el modelo de implantación del usuario, además de asegurarque tenga el tiempo de respuesta requerido.

3.7. PROGRAMACION PROCESOS DE CARGA INICIAL.

Cuando el sistema se desarrolla tomando como base unocomputacional, la mayoría de las veces el usuario requiere que la informacióncontenida en su sistema anterior sea traspasada al nuevo sistema, por lo queserá necesario programar los procesos que realicen dicho traspaso. Tambiénes necesario que la información contenida en tablas del sistema anterior seatraspasada al nuevo sistema, para evitar que el usuario la vuelva a capturar enel nuevo sistema.

4. IMPLEMENTACION.

Es la puesta en marcha del nuevo sistema, en algunos casos estapuesta en marcha del nuevo sistema puede significar simplemente un cambiode la noche a la mañana del nuevo sistema, en otros casos, la instalaciónpuediera ser un proceso gradual, en el que un grupo tras otro de usuarios vanrecibiendo manuales y entrenamiento y comenzando a usar el nuevo sistemamodularmente. 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. (Capturadapor 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 delsistema.

Definición de requerimientos y descripciónde procesos del sistema actual usando unametología de Análisis.

Presentación a usuarios de la definiciónde requerimientos y descripción deprocesos para revisión y aprobación

Revisado yAprobado?

Integración del módulo al SistemaIntegral.

Diseño.

NO

SI

DIAGRAMA DE ACTIVIDADES EN EL PROCESO DE DISEÑO.

Generación del modelo Entidad-Relación.

Modelación a detalle de los requerimientosde Información.

Modelación de la Integridad de procesos enel diagrama Entidad-Relación.

Revisión y Aseguramiento por parte dedesarrolladores.

Revisado yAprobado?

Transformación del modelo Relacionala Tablas. Normalización del diseño eIntegración del Diseño al sistemaIntegral.

Realización de miniespecificacionesComputaciones y definición deProcesos de Carga Inicial.

NO

SI

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


Rechazarsolicitud

Enviar solicitud

Programar fecha de pago

Autorizar solicitud

Verificar contenido de la solicitud

Orden de pagoElaborada

Orden de pagoEnviada

Orden de pagoRechazada

Orden de pagoVerificada

Orden de pagoAutorizada

Orden de pagoProgramada

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


Dependencia

Solicitaautorización depresupuestos

Presupuestos

Caja General

ProgramaciónDel pago

Creación depasivos

Envía solicitudautorizada

Asigna una fechapara pago

Se crea pasivo yse elabora póliza

de diario

Solicitud revisada

Egresos

Ventanilla


Cancelación de Pago

Envía documentode cancelación

Envía solicitudpara cancelar pago

Identifica enque etapa seencuentra el

pago

Dependencia

Ventanilla

Egresos

Notificaciónpara cancelar

cheque

Cancela pasivocreado

Cancela pasivocreado y fecha depago programada

Caja General

Programaciónde Pago

Integración dePasivo


Reposición de Cheque

Dependencia

BancoContabilidad

Caja General

Solicita lareposición de

cheque

Certifica lareposición de

cheque

Notifica para quese cancele el

cheque emitido

Tramita lasolicitud dereposición

Aviso de chequecancelado


Comprobación de gasto

Dependencia

ContabilidadDependencia

Analista deVentanilla

Ventanilla

Envía documentopara

comprobación

Envía formato de“ingreso por

Existe saldo encontra

Sí existen saldos iguales, se

envía ladocumentacióncomprobatoria

Verifica si se tratade saldos iguales,saldo a favor o en

contra delinteresado

Programacióndel pago

Existe saldo afavor

Egresos

Envía la fechapara emitir el

cheque de pago

Caja General


Solicitud de Recibos de Ingresos

Dependencia

Caja General

Ingresos

Envía solicitud de“Recibos de Ingresos

Académicos y/o varios”

Envía los foliosasignados a los recibos

solicitados por laDependencia para su

cobro


Registro de Ingresos

Caja General

Envía la documentacióncomprobatoria de los

ingresos

Jefe delDepartamento

Contabilidad

Captura

Recepción

Solicita el subsidioFederal y Estatal

Documentos originadospor el ingreso por subsidio

con la ficha de depósito

Envía toda ladocumentación

comprobaria de losingresos registrados

Turna los documentos deingresos para que seafecten las partidascorrespondientes

Ingresos

Secretaria deGobierno del

Estado

Emite el cheque para elsubsidio Federal ó Estatal

Diagrama de Estados

Cancelación de Pago

Rechaza el documento

Autoriza la cancelación

Verifica el contenido del documento

Envía documento de cancelación

Documento paracancelar pago

elaborado


enviado


verificado


rechazado

Cancela el pago solicitado


autorizado

Pago Cancelado

Diagrama de Estados

Reposición de Cheque

Documento dereposición de cheque

Elaborado


Rechazado


Autorizado


Verificado


Enviado

Cheque repuesto

Diagrama de Estados

Comprobación de Gasto

Rechaza documento

Autoriza la comprobación

Verifica el contenido de documentación

Envía documento para comprobar pago

Comprobación deGasto

Elaborada


Rechazada


Autorizada


Verificada


Enviada

Procede a comprobar el gasto

Gasto Comprobado

Diagrama de Estados

Solicitud de Recibos de Ingresos

Rechaza solicitud

Asignación de folios a los recibos

Autoriza la solicitud

Verifica el contenido de la solicitud

Envía la solicitud

Solicitud de recibosde ingresoElaborada

Solicitud de recibosde ingresoRechazada

Recibos entregados

Solicitud de recibosde ingreso

Autorizada

Solicitud de recibosde ingresoVerificada

Solicitud de recibosde ingresoEnviada

Diagrama de Estados

Registro de Ingresos

Rechaza ingreso

Cobro del ingreso

Autoriza el ingreso

Verifica el recibo de ingresos ó la solicitud de subsidios

Ingreso Rechazado

IngresoAutorizado

IngresoVerificado

Ingreso registrado

DOCUMENTACION DE MINIESPECIFICACIONESCOMPUTACIONALES.

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.

Universidad Autònoma de San Luis Potosí Fecha: 17/05/1999Sistema de Plazas Programa: N__________

1.10. ABC NOMBRAMIENTOS.

No.Nombr. Descripción Fecha Alta Fecha baja _______ ___________________________ __/__/____ __/__/___________ ___________________________ __/__/____ __/__/___________ ___________________________ __/__/____ __/__/___________ ___________________________ __/__/____ __/__/___________ ___________________________ __/__/____ __/__/___________ ___________________________ __/__/____ __/__/___________ ___________________________ __/__/____ __/__/___________ ___________________________ __/__/____ __/__/____

ABC Nombramientos.

Alta Baja Modificar Consulta 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)

Alta Nombramientos.

1.10. ABC NOMBRAMIENTOS.

MINIESPECIFICACIONES.

ARCHIVO: NNOM_Tnom tbuasl perm_empalme_ocnom_desc tipoant usuarionom_desco tipopla fecha_alta scatuaslp nivaca usuariofacsdo pdifjor termjorm tabpanti fecha_ususind recsueldo fecha_bajatbsep perm_oc_plaza_evol

ALTA.• Se captura nom - No.Nombramiento. Validar que NO exista el No. De Nombramiento Tecleado en NNOM_T.• Se captura nom_desc la 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émicosNNIVACA_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 losveladores 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 existenciaen el archivo NTABPANTI_T (Debe existir al menos un registro en el archivo NTABPANTI_T con el tabpanticapturado).•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. Esrequerido 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-altausuarioterm

BAJA.•Se selecciona el nombramiento a dar de baja. - nom.• Se despliegan los datos del nombramiento:

nom tbuaslnom-desc tipoantscatuaslp tipoplafacsdo nivacajorm pdifjorsind tabpantitbsep

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 archivoOCUPANTES 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 = todayNNOM_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 tbsep termnom-desc tbuasl perm_oc_plaza_evolnom_desco tipoant perm_empalme_ocscatuaslp tipoplafacsdo nivacajorm pdifjorsind tabpanti

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 UASLPfacsdo - Factor de Sueldotbuaslp - Tabulador de UASLPtipoant - Tipo de Antiguedadtipopla - Tipo de plazanivaca - Nivel Académicotabpanti - 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 = todayusuario = usuario que realiza la modificación.Term = No. estación de trabajo en donde se realiza la modificación.

Universidad Autónoma de San Luis Potosí Fecha: 17/05/1999Sistema de Plazas Programa: N__________

1.14. EMPLEADOS.

RPE Nombre _______ __________________________________ __________________________________ __________________________________ __________________________________ __________________________________ __________________________________ ___________________________

ABC Empleados.

Alta Baja Modificar Consulta Reporte Salir.

RPE: _____Nombre: __________________________________

Apellido Matern o: __________________Apellido Paterno : _________________

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:

Alta Empleados.

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_usuusuarioterm

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 facsanapellmat curpapellpat fecha_nacnombres fecdefunrfc localidad_nacsexo mpio_nacgrusan edo_nac

pais_nacnacionalidad

Se actualizan los datos modificados en el archivo NEMP_T y se graban los siguientes datos de actualización:fecha-usuusuarioterm

2. CONTROL DE PLAZAS.

2.1. PLAZAS UASLP.

2.1.1. CREACION DE PLAZAS.

Universidad Autónoma de San Luis Potosí Fecha: 17/05/1999Sistema de Plazas Programa: N__________

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: ____ _______*_____________ Sueldo Base: ______*_______Jornada Semanal: ____ _______*_____________ Premio por Nivel: ______*_______

Premio por Antigüedad: ______*_______Motivo Creación u Origen: ____ _________*___________

Fecha Creación : __/__/____

Perfil de la Plaza: ______ ________*__________

Creación de Plazas.

Se crea la plaza con los datos capturados SI/NO?

Si se captura un tipo de periodo. Se tendrán que capturar los periodos para el tipo de periodo en la siguienteforma:

No. Periodo Descripción___ _____________________________ ___ ________________________________ ________________________________ _____________________________

Alta Baja Salir

<Enter> para continuar

Se despliega el No. De la plaza, y el usuario podrá registrar una nueva plaza tecleando <Enter>.

Cuando el Motivo de Creación o alta de la plaza actual dice que la plaza se debe relacionar con otra u otras plazasque 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.

Cve. Plaza Ori. Fus/Fracc./Red. SUOrg. Nom Nivel Edo.Plaza Cau.Mov. Descr. _____ _*__ _*___ _*___ __*___ ___*__ ____*__________ _*__ _*___ _*___ __*___ ___*__ ____*__________ _*__ _*___ _*___ __*___ ___*__ ____*__________ _*__ _*___ _*___ __*___ ___*__ ____*__________ _*__ _*___ _*___ __*___ ___*__ ____*__________ _*__ _*___ _*___ __*___ ___*__ ____*__________ _*__ _*___ _*___ __*___ ___*__ ____*_____

Alta Baja Salir

Plaza : ____ Fecha Creación: __/__/__*__RPE Titular: __*__ ____________*___________________

Estado: __*__ ____________*___________________

Plaza Relacionada por el Estado de la Plaza.

Plazas Origen.

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_Tsin 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 sepermite el departamento.•Se despliega uorga - Unidad Organizacional de la que depende el departamento de la Plaza. Se obtiene delregistro 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 latabla 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óntiene 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_Tsin 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 Nivelestabulados, 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ónde 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ándecimales, 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 - niveljorsem - 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

Subscriber Line

Línea digital asimétrica de abonado. Sistema

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

Standard Institute

Instituto Nacional Americano de Estándar.

API Aplication Program

Interface.

Interfaces de aplicación del programa. Es el conjunto

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

Projects Agency Network.

Red de la Agencia de Proyectos de Investigación

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

Code for Information

Interchange.

Estándar americano para intercambio de

información. La tabla básica de caracteres ASCII

está compuesta por 128 caracteres incluyendo

símbolos y caracteres de control. Existe una versión

extendida de 256.

ASN Autonomus System

Number.

Número de sistema autónomo. Grupo de Routers y

redes controlados por una única autoridad

administrativa.

ATM Asyncronous Transmision

Mode.

Modo 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

System.

Sistema básico de entrada/salida. Programa

residente normalmente en Eprom que controla las

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 problemas para entregarlo a su

destinatario.

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

Consultative Committee on

Telegraphy and Telephony.

Comité Consultivo de Telegrafía y Telefonía.

Organización que establece estándares

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

ROM.

CDA Comunications Decency

Act. Acta de decencia en las

Telecomunicaciones.

Proyecto de ley americano que pretendía a ejercer

una especie de censura sobre Internet. Por el

momento ha sido declarado anticonstitucional.

CERN Conseil Europeen pour

la Recherche Nucleaire.

Consejo Europeo para la Investigación Nuclear.

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.

Interface de Acceso Común. Programas usados para

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

Rate.

Es el caudal mínimo de información que garantiza el

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

Exchange.

Intercambio Comercial Internet.

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

Investigaciones Científicas.

El organismo público encargado de las

investigaciones científicas en España.

CSLIP Compressed Serial Line

Protocol. Protocolo de Línea

Es una versión mejorada del SLIP desarrollada por

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

Access.

Acceso múltiple por detección de portadora.

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

Multifrecuency.

Multifrecuencia de doble tono. Son los tonos que se

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

DUPLEX: 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

Coded Decimal Interchange

Code.

Código extendido de binario codificado decimal.

Sistema mejorado de empaquetamiento de números

decimales en sistema binario.

ECC Error Checking and

Correction

.

Chequeo y corrección de errores.

EFF Electronic Frontier

Foundation.

Fundación Frontera Electrónica. Organización para

la defensa de los derechos en el cyberespacio.

EDI Electronical Data

Interchange.

Intercambio electrónico de datos.

ETSI European

Telecommunication Standars

Intitute

.

Instituto Europeo de Estándares en

Telecomunicaciones.

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

Interface.

Dispositivo Interface de fibra (óptica) digital.

Finger Literalmente "dedo". Facilidad que permite averiguar

información básica sobre usuarios de Internet o Unix.

FIX Federal Interagency

Exchange.

Interagencia federal de Intercambio.

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

ventanas 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

Format.

Formato gráfico de intercambio.

GIX Global Internet Exchange. Intercambio global Internet.

GMT Greenwich Mean Time. Hora de referencia de Greenwich. Equivalente a UT.

GSM Global System Mobile

comunications.

Sistema global de comunicaciones móviles. Sistema

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.

Control de enlace de datos de alto nivel.

HDSL Hight bit rate Digital

Subscriber Line.

Línea digital de abonado de alta velocidad. Sistema

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

System.

Sistema de archivos de alto rendimiento. Sistema

que utiliza el OS/2 opcionalmente para organizar el

disco duro en lugar del habitual de FAT.

HTML HyperText Markup

Language.

Lenguaje de marcas de hypertexto. Lenguaje para

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

Protocol.

Protocolo de transferencia de hypertexto. Protocolo

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

Number Authority.

Autoridad de asignación de números en Internet. Se

trata de la entidad que gestiona la asignación de

direcciones IP en Internet.

ICMP Internet Control Message

Protocol.

Protocolo Internet de control de mensajes.

IEEE Institute of Electrical and

Electronics Engineers.

Instituto de Ingenieros Eléctricos y Electrónicos.

Asociación norteamericana.

IETF Internet Engineering Task

Force.

Grupo 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

Técnica Aeroespacial.

Como la NASA pero español.

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.

Interface inteligente de periféricos. En ATM: Initial

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

Digital Network.

Red Digital de Servicios Integrados. En español

RDSI.

ISO International Standard

Organization.

Organización Internacional de Standard.

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

Group.

Unión de grupo de expertos fotográficos. Formato

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

for Modems.

Procedimiento de acceso a enlace para 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

conocido systema operativo

Unix.

Es un sistema multitarea multiusuario de 32 bits para

PC.

LU Logic Unit. Unidad lógica.

Lock Cerrado. Bloqueado.

MAN Metropolitan Area

Network.

Red de área metropolitana.

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

Mail Extensions.

Extensiones multipropósito de correo Internet.

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

Protocol.

Protocolo de redes de Microcom. Protocolo de

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

Modulator/Demodulator.

Modulador/demodulador. Dispositivo que adapta las

señales digitales para su transmisión a través de una

línea analógica. Normalmente telefónica.

MPEG Motion Pictures Expert

Group.

Grupo de expertos en imagen en movimiento.

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

Operating System.

Sistema operativo en disco de Microsoft. Sistema

operativo muy extendido en PC del tipo de línea de

comandos.

MTU Maximum Transmission

Unit.

Unidad máxima de transmisión. Tamaño máximo de

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

Request.

Petición de participación en la red. Es la petición de

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.

Network Basic Input/Output

System.

Bios de una red, es decir, Sistema básico de

entrada/salida de red.

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

Fundation.

Fundación Nacional de Ciencia. Fundación

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

Manufactured.

Manufactura de equipo original. Institución que

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

Interconnection.

Interconexión de sistemas abiertos. Modelo de

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

Protocol.

Protocolo de autentificación por password. Protocolo

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

Number.

Número personal de identificación. Número secreto

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

Graphics.

Gráficos portables de red. Formato gráfico muy

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.

AutoTest de Encendido.

Serie de comprobaciones que hace un ordenador de

sus dispositivos al ser encendido.

POTS Plain Old Telephone

Services.

Servicios telefónicos planos antiguos.

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

Modulation.

Modulación de amplitud en cuadratura. Sistema de

modulación para transmisión de datos y

telecomunicaciones.

RARP Reverse Address

Resolution Protocol.

Protocolo de resolución de dirección de retorno.

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

Integrados.

Red de telefónica con anchos de banda desde

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

Protocol.

Protocolo de información de routing.

ROOT Raíz. En sistemas de ficheros se refiere al directorio raíz.

En Unix se refiere al usuario principal.

RSA Rivest, Shamir, Adelman

[public key encryption

algorithm].

Algoritmo de encriptación de clave pública

desarrollado por Rivest, Shamir y Adelman.

RTC Red Telefónica

Conmutada.

Red telefónica para la transmisión de voz.

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

for Auditing Networks.

Herramienta de análisis de seguridad para la

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

Controller.

Controlador de enlace de datos síncrono. También

se trata de un protocolo para enlace sincrono a

través de línea telefónica.

SDSL Symmetric Digital

Subscriber Line.

Línea digital simétrica de abonado. Sistema de

transferencia de datos de alta velocidad en líneas

telefónicas normales.

SEPP Secure Electronic

Payment Protocol.

Protocolo de pago electrónico seguro. Sistema de

pago a través de Internet desarrollado por Netscape

y Mastercard.

SGML Standard Generalized

Markup Language.

Lenguaje de anotaciones generales. Lenguaje del

que deriva el HTML.

SMPT Simple Mail Transfer

Protocol.

Protocolo de transferencia simple de correo. Es el

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

Arquitecture.

Arquitectura de sistemas de redes. Arquitectura de

red exclusiva de IBM. Principalmente orientada a

Mainframes.

SQL Structured Query

Language.

Lenguaje de petición estructurada. Lenguaje para

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

Technology.

Tecnología de transacción segura. Sistema

desarrollado por Microsoft y Visa para el comercio

electrónico en Internet.

Sniffer Literalmente

"Husmeador".

Pequeño programa que busca una cadena numérica

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

Module.

Modulo simple de identificación. Normalmente se

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

Protocol.

Protocolo de control de Transmisión. Uno de los

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

Datos.

División de telefónica para la transmisión de 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 y Routers unicast. Los paquetes

multicast se encuentran 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

Locator.

Localizador uniforme de recursos. Denominación

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

Communication Protocol.

Protocolo de comunicaciones de Unix a Unix. Uno de

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

Language.

Lenguaje para modelado de realidad virtual.

Lenguaje para crear mundos virtuales en la Web.

WAN Wide Area Network. Red de área extensa.

WINDOWS Pseudo sistema

operativo.

Más bien se trata de un entorno gráfico con algunas

capacidades multitarea. La versión actual

WINDOWS 95 funciona parcialmente a 32 bits.

WWW, WEB o W3 World Wide

Web.

Telaraña mundial, para muchos la WWW es Internet,

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.

DR. MIGUEL LIMÓN ROJA S

Documents

Transcript of DR. MIGUEL LIMÓN ROJA S