jueves, 17 de noviembre de 2011

LEY 30 ¿ VALE LA PENA ?

Reforma a la Ley 30: por qué sí, por qué no

 
Foto: Archivo Semana.

 Naciòn Gobierno y rectores chocan en torno a varias propuestas de la reforma a la educación superior. Estos son cuatro de los puntos que más generan polémica.



La propuesta del Gobierno para reformar la ley de Educación Superior (Ley 30 de 1992) causó malestar y deja inquietudes en la comunidad universitaria. Y aunque todos coinciden en que es hora de reformar la norma, existen posiciones del Gobierno y el sector universitario que chocan y motivan, con y sin fundamentos, lamentables y costosos disturbios como los vistos esta semana en varias instituciones públicas.

Han pasado 18 años desde que se expidió la Ley 30 de 1992 y el sector ha cambiado sustancialmente. Para ese entonces, no existía el Viceministerio de Educación Superior, el ICFES no era un instituto dedicado a la evaluación de la educación y el ICETEX no era un banco de segundo piso, por mencionar algunos cambios.

Aunque la reforma se venía preparando desde la administración pasada, en un trabajo conjunto con el Ministerio de Educación y los rectores de las universidades, la que presentó hace algunas semanas el presidente Juan Manuel Santos es más amplia y con propuestas polémicas.

Semana.com seleccionó cuatro de los temas más polémicos de esta iniciativa de 144 artículos.

1. La empresa privada podrá invertir en las universidades públicas

Para el presidente Juan Manuel Santos, si la educación pública quiere ser competitiva y de buena calidad no puede negarse a la posibilidad de tener fuentes de inversión privada. “Esta propuesta no significa de ninguna manera privatizar la educación pública, ni va a implicar mayores costos para los estudiantes”.

El Gobierno advirtió que los recursos son limitados, por eso, aliarse con la empresa privada es una alternativa.“Hoy un empresario contrata servicios con la universidad, pero queremos que no solo contrate, sino que invierta capital para desarrollar proyectos específicos, que se meta la mano al bolsillo y genere innovación con las universidades (...) que pongan la plata, vendan servicios, desarrollen conocimiento y ojalá ganen bastante”, explicó la ministra de Educación, María Fernanda Campo.

Moisés Wasserman, rector de la Universidad Nacional, no ve clara la propuesta. “El ingreso del dinero del sector privado para investigación no es una novedad. Las universidades trabajamos con la empresa desde hace 40 o 50 años. Hay comités universidad-empresa-Estado en todas las regiones del país”, dice.

Según los rectores una empresa invierte si puede obtener rendimientos o beneficios. La pregunta para las universidades es: ¿qué tanto ese interés privado puede chocar con la misión y con la verdadera función de las universidades?

2. Más plata para la universidad pública

El Gobierno propone aumentar recursos para las universidades públicas en un 1 por ciento adicional al IPC en el 2012, un 2 por ciento en el 2013 y un 3 por ciento entre el 2014 y el 2019. Sin embargo, para las universidades, no es suficiente para sobrevivir con el número de alumnos que tienen y tendrán en el futuro.

La molestia de las universidades públicas está en que el proyecto de ley no incluyó el reconocimiento y el reembolso del dinero que invirtieron en los últimos 13 años para aumentar la cobertura y mejorar la calidad.

En ese tiempo “nuestro presupuesto se ha mantenido fijo con el Índice de Precios al Consumidor (...) En el año 2009 se hizo una adición de 70.000 millones de pesos, que es muy poco para el sistema de 32 universidades públicas con 600.000 estudiantes. Ese dinero no se ha terminado de pagar y es la única adición que han hecho en ese tiempo”, aseguró el rector de la Universidad Nacional, Moisés Wasserman.

3. Se crearán universidades con ánimo de lucro

Es una figura que no existe en el país, incluso paras las universidades privadas, cuyas ganancias deben ser reinvertidas en la institución. Con la propuesta del Gobierno se abre esta puerta que genera inquietudes entre las instituciones públicas y privadas, por el riesgo de que se ponga en peligro la calidad de la formación superior.

Según el gobierno, Brasil recurrió a este modelo que le permitió el aumento de la cobertura. “En 12 años pasaron de 1’800.000 estudiantes a casi 6’000.000, teniendo un 75 por ciento de instituciones con ánimo de lucro”, resaltó el presidente Santos.

Para el rector de la Universidad Nacional el tema debe ir más allá de las cifras. “El fin social de la empresa es el lucro. Ha funcionado en países como Brasil, pero hay que ver los dos lados. No son universidades verdaderas; funcionan en forma muy eficiente dando el mínimo posible logrando cobrar el máximo posible, como buena empresa. En Brasil tuvieron un impacto fuerte en cobertura, pero nulo en calidad”.

Agrega Wasserman que si se plantea crear este modelo, tiene que ser muy equilibrado, como también ocurrió en Brasil. “Hay que fortalecer a las universidades públicas, las que realmente hacen la calidad, dan el impulso y lideran el desarrollo del país”.

4. Autonomía universitaria

Es tal vez el tema que más preocupa al sector. Para el Gobierno el proyecto fortalece el aseguramiento de la calidad, la acreditación y la evaluación de la educación superior. Pero para los rectores, el Ministerio de Educación tendría más poder para vigilar y sancionar, lo que algunos ven como una lesión enorme a la autonomía universitaria.

“Es peligroso para la democracia que se le entregue tanto poder a un organismo ejecutivo, sin controles por parte de los órganos judiciales. La propuesta le da una fuerte capacidad sancionatoria al Ministerio, pero hay que tener cuidado porque realmente puede llevar a abusos”, afirma el rector de la universidad Jorge Tadeo Lozano y presidente de ASCUN, José Fernando Isaza.
Extractado de la Revista Semana.
MIS COMENTARIOS
Por amor a Dios....de verdad que seguimos siendo ciegos, y es verdad que "en el pais de los ciegos el Tuerto es el Rey".
Todavía no podemos separar los tristes episodios de la clase dirigente repartiendose la Torta ( Instituciones del Estado )para poder pagar favores y poder tener cierta Caja Menor para poder saciar sus necesidades...
Es triste ver como disfrazan las leyes que por derecho deben ser para el beneficio del pueblo en leyes que atentan contra lo mas sagrado que pueda tener una sociedad que es el derecho al estudio, el derecho a preparase, el derecho a saber.
Ver como han sido capaces de modificar el sistema de estudio desde los niveles mas primarios con el fin de poder ver como llegan los aspirantes  universitarios sin niveles adecuados de preparación y asi poder tener profesionales mediocres, y esto con el fin de poder hacer avanzada en las especializaciones , postgrados, doctorados etc, que en su momento eran equivalentes a los estudiantes mas aventajados y profesionales mas profesionales en el sentido de la palabra.
Claro que todo esto redunda en que va a ser a corto plazo UN NEGOCIO y uno bien bueno ya que van a jugar con la necesidad de gente que solo aspira a poder mejorar su calidad de vida y ahora solom podrán aspirar a ver si en un futuro podrán tener un avida laboral digna.
Es mi concepto y aunque no estoy totalmente en desacuerdo lo que si seria bueno es que en esta formulacion de esta ley estuvieran involucrados todos los factores vivos de la sociedad que puedan implementarla para el benficio de un sufrido pueblo; pensar que en Brasil ya funciona este modelo hacer varios años y vemos como este nación ya es potencia a nivel del continente.
He dicho.


UML - LENGUAJE DE MODELADO UNIFICADO

EL LENGUAJE UNIFICADO DE MODELADO (UML)

En todas las disciplinas de la Ingeniería se hace evidente la importancia de los modelos ya que describen el aspecto y la conducta de "algo". Ese "algo" puede existir, estar en un estado de desarrollo o estar, todavía, en un estado de planeación. Es en este momento cuando los diseñadores del modelo deben investigar los requerimientos del producto terminado y dichos requerimientos pueden incluir áreas tales como funcionalidad, performance y confiabilidad. Además, a menudo, el modelo es dividido en un número de vistas, cada una de las cuales describe un aspecto específico del producto o sistema en construcción.

El modelado sirve no solamente para los grandes sistemas, aun en aplicaciones de pequeño tamaño se obtienen beneficios de modelado, sin embargo es un hecho que entre más grande y más complejo es el sistema, más importante es el papel de que juega el modelado por una simple razón: "El hombre hace modelos de sistemas complejos porque no puede entenderlos en su totalidad".

UML es una técnica para la especificación sistemas en todas sus fases. Nació en 1994 cubriendo los aspectos principales de todos los métodos de diseño antecesores y, precisamente, los padres de UML son Grady Booch, autor del método Booch; James Rumbaugh, autor del método OMT e Ivar Jacobson, autor de los métodos OOSE y Objectory. La versión 1.0 de UML fue liberada en Enero de 1997 y ha sido utilizado con éxito en sistemas construidos para toda clase de industrias alrededor del mundo: hospitales, bancos, comunicaciones, aeronáutica, finanzas, etc.

Los principales beneficios de UML son:

  • Mejores tiempos totales de desarrollo (de 50 % o más).
  • Modelar sistemas (y no sólo de software) utilizando conceptos orientados a objetos.
  • Establecer conceptos y artefactos ejecutables.
  • Encaminar el desarrollo del escalamiento en sistemas complejos de misión crítica.
  • Crear un lenguaje de modelado utilizado tanto por humanos como por máquinas.
  • Mejor soporte a la planeación y al control de proyectos.
  • Alta reutilización y minimización de costos.

UML, ¿Método o Lenguaje de Modelado?

UML es un lenguaje para hacer modelos y es independiente de los métodos de análisis y diseño. Existen diferencias importantes entre un método y un lenguaje de modelado. Un método es una manera explícita de estructurar el pensamiento y las acciones de cada individuo. Además, el método le dice al usuario qué hacer, cómo hacerlo, cuándo hacerlo y por qué hacerlo; mientras que el lenguaje de modelado carece de estas instrucciones. Los métodos contienen modelos y esos modelos son utilizados para describir algo y comunicar los resultados del uso del método.

Un modelo es expresado en un lenguaje de modelado. Un lenguaje de modelado consiste de vistas, diagramas, elementos de modelo los símbolos utilizados en los modelos y un conjunto de mecanismos generales o reglas que indican cómo utilizar los elementos. Las reglas son sintácticas, semánticas y pragmáticas (figura 1).

 
figura 1

Vistas: Las vistas muestran diferentes aspectos del sistema modelado. Una vista no es una gráfica, pero sí una abstracción que consiste en un número de diagramas y todos esos diagramas juntos muestran una "fotografía" completa del sistema. Las vistas también ligan el lenguaje de modelado a los métodos o procesos elegidos para el desarrollo. Las diferentes vistas que UML tiene son:

  • Vista Use-Case: Una vista que muestra la funcionalidad del sistema como la perciben los actores externos.

  • Vista Lógica: Muestra cómo se diseña la funcionalidad dentro del sistema, en términos de la estructura estática y la conducta dinámica del sistema.

  • Vista de Componentes: Muestra la organización de los componentes de código.

  • Vista Concurrente: Muestra la concurrencia en el sistema, direccionando los problemas con la comunicación y sincronización que están presentes en un sistema concurrente.

  • Vista de Distribución: muestra la distribución del sistema en la arquitectura física con computadoras y dispositivos llamados nodos.



Diagramas: Los diagramas son las gráficas que describen el contenido de una vista. UML tiene nueve tipos de diagramas que son utilizados en combinación para proveer todas las vistas de un sistema: diagramas de caso de uso, de clases, de objetos, de estados, de secuencia, de colaboración, de actividad, de componentes y de distribución.

Símbolos o Elementos de modelo: Los conceptos utilizados en los diagramas son los elementos de modelo que representan conceptos comunes orientados a objetos, tales como clases, objetos y mensajes, y las relaciones entre estos conceptos incluyendo la asociación, dependencia y generalización. Un elemento de modelo es utilizado en varios diagramas diferentes, pero siempre tiene el mismo significado y simbología.

Reglas o Mecanismos generales: Proveen comentarios extras, información o semántica acerca del elemento de modelo; además proveen mecanismos de extensión para adaptar o extender UML a un método o proceso específico, organización o usuario.

FASES DEL DESARROLLO DE UN SISTEMA

Las fases del desarrollo de sistemas que soporta UML son: Análisis de requerimientos, Análisis, Diseño, Programación y Pruebas.

Análisis de Requerimientos

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

Análisis

La fase de análisis abarca las abstracciones primarias (clases y objetos) y mecanismos que están presentes en el dominio del problema. Las clases que se modelan son identificadas, con sus relaciones y descritas en un diagrama de clases. Las colaboraciones entre las clases para ejecutar los casos de uso también se consideran en esta fase a través de los modelos dinámicos en UML. Es importante notar que sólo se consideran clases que están en el dominio del problema (conceptos del mundo real) y todavía no se consideran clases que definen detalles y soluciones en el sistema de software, tales como clases para interfaces de usuario, bases de datos, comunicaciones, concurrencia, etc.

Diseño

En la fase de diseño, el resultado del análisis es expandido a una solución técnica. Se agregan nuevas clases que proveen de la infraestructura técnica: interfaces de usuario, manejo de bases de datos para almacenar objetos en una base de datos, comunicaciones con otros sistemas, etc. Las clases de dominio del problema del análisis son agregadas en esta fase. El diseño resulta en especificaciones detalladas para la fase de programación.

Programación

En esta fase las clases del diseño son convertidas a código en un lenguaje de programación orientado a objetos. Cuando se crean los modelos de análisis y diseño en UML, lo más aconsejable es trasladar mentalmente esos modelos a código.

Pruebas

Normalmente, un sistema es tratado en pruebas de unidades, pruebas de integración, pruebas de sistema, pruebas de aceptación, etc. Las pruebas de unidades se realizan a clases individuales o a un grupo de clases y son típicamente ejecutadas por el programador. Las pruebas de integración integran componentes y clases en orden para verificar que se ejecutan como se especificó. Las pruebas de sistema ven al sistema como una "caja negra" y validan que el sistema tenga la funcionalidad final que le usuario final espera. Las pruebas de aceptación conducidas por el cliente verifican que el sistema satisface los requerimientos y son similares a las pruebas de sistema.

EJEMPLO DE UML
Terminal de Punto De Venta (TPDV)
Diagrama de casos de uso
Diagrama de clases
Descripción
·        Nuestro caso de uso es un sistema de
          terminal de punto de venta (TPDV).
·        Este terminal es un sistema computarizado
          con el que se registran las ventas y se
          realizan los pagos; normalmente se utiliza
          por las tiendas al detalle. Abarca
          componentes de hardware (una
          computadora y un lector de código de
          barras) y software para el sistema.
Requerimientos
·        Este proyecto tiene por objeto crear un sistema de
           terminal para el punto de venta que se utilizará en
           las ventas al minorista.
·        En términos generales, la meta es una mayor
           automatización del pago en las cajas registradoras,
           dar soporte a servicios rápidos, más baratos y
           mejores y a los procesos de negocios. Más
           concretamente, la meta incluye:
               􀁺 Pago rápido de clientes.
               􀁺 Análisis rápido y exacto de las ventas.
               􀁺 Control automático de inventario.
Funciones del sistema
·        Registra la venta en proceso (actual): los productos
          comprados.
·        Calcula el total de la venta actual; se incluyen el
          impuesto y los cálculos del recibo.
·        Captura la información sobre el objeto comprado usando
          su código de barras y un lector o usando una captura
          manual de un código del producto; código universal de
          producto (CUP).
·        Actualiza las cantidades del inventario cuando se realiza
          una venta.
·        Se registran las ventas efectuadas.
·        Ofrece un mecanismo de almacenamiento persistente.
·        Ofrece mecanismos de comunicación entre los procesos
          y entre los sistemas.
·        Muestra la descripción y el precio del producto registrado


Simplificaciones
·        Pagos en efectivo exclusivamente.
·        Sin mantenimiento de inventario.
·        Tienda independiente.
·         Captura manual del código universal de producto
           (CUP).
·         No se calculan los impuestos.
·        Sin cupones.
·        El cajero no tiene que registrar las ventas.
·        No se lleva un registro de los clientes individuales ni
          de sus hábitos de compra.
·        No se controla la caja de efectivo.
·         Las ventas se almacenan en un documento histórico.
Uso del sistema
Casos de uso y actores


ACTORES
ACCIONES
CAJERO
Registra productos
Entrega el cambio
CLIENTE
Compra productos
Paga productos
GERENTE
Inicia
Cierra


Uso del sistema
Diagrama de casos de uso

Uso del sistema
Diagrama de casos de uso simplificado

Uso del sistema
Especificación de los casos de uso
·        Caso de uso: Inicia
·        Actores: Gerente (iniciador)
·        Propósito: Inicializar el sistema
·        Resumen: El gerente enciende el terminal
          de punto de venta e inicializa el sistema.
·        Curso normal de los eventos:
·         Este caso de uso comienza cuando el
           gerente llega a un TPDV y lo enciende
·         El software del punto de venta se ejecuta y
           queda iniciado el sistema.
·         Caso de uso: Comprar productos
·        Actores: Cliente (iniciador), Cajero
·        Propósito: Capturar una venta y su pago
           en efectivo.
·        Resumen: Un cliente llega a la caja con los
          productos que desea comprar. El cajero
          registra los productos comprados y recibe
          el pago en efectivo. Al terminar la
          transacción, el cliente se marcha con los
          productos.
·        Curso normal de los eventos:
1. Este caso de uso comienza cuando un cliente llega a
              una caja de TPDV con productos que desea comprar.
           2. El cajero registra el código universal de producto
              (CUP) en cada producto. Si el producto se repite, el
              cajero tambien puede introducir libremente la
              cantidad.
           3. El sistema determina el precio del producto y agrega
              la información correspondiente a la transacción
              actual. Presenta la descripción y el precio del
              producto en cuestión.
           4. Al terminar de introducir los productos, el cajero
              indica al TPDV que ya concluyó la captura.


Principales clases y relaciones
Identificación de las frases nominales
·        Curso normal de los eventos:
1.    El sistema calcula el total de la venta y se lo
           presenta al cliente.
2.    El cajero le indica al cliente el total.
3.    El cliente da un pago en efectivo (monto),
           posiblemente mayor que el total de la venta.
4.    El cajero registra el efectivo recibido.
5.    El sistema muestra al cliente la diferencia. Genera
          un recibo.
6.    El cajero deposita el efectivo recibido y extrae la
          diferencia. El cajero entrega el cambio y el recibo
          impreso.
7.    .El sistema registra la venta terminada.
8.    .El cliente se marcha con los productos comprados

Principales clases y relaciones
Identificación de las frases nominales
·        Lista de posibles clases:
·         TPDV
·        Producto
·        Tienda
·        Venta
·        Especificación de productos
·        Línea de productos vendidos
·        Cajero
·        Cliente
·        Gerente
·        Pago
·        Catálogo de productos

Principales clases y relaciones
Identificación de relaciones

CATEGORIA
EJEMPLOS
A es una parte física de B

A es una parte lógica de B
LineaDeProductoVendido-Venta
A está contenido físicamente en B
TPDV-Tienda
Producto-Tienda
A está contenido lógicamente en B
EspecificaciónDeProducto-
CatalogoDeProductos
CatalogoDeProductos-Tienda
A es una descripción de B
EspecificaciónDeProducto-Producto
A es un elemento de línea en una transacción B
LineaDeProductoVendido-Venta
A se conoce / introduce / registra /
presenta / captura en B
Ventas(Terminadas)-Tienda
Venta(Actual)-TPDV


Principales clases y relaciones
Identificación de relaciones

CATEGORIA
EJEMPLOS
A es miembro de B
Cajero-Tienda
A es una subunidad
organizacional de B

A usa o dirige B
Cajero-TPDV
Gerente-TPDV
A se comunica con B
Cliente-Cajero
A se relaciona con una
transacción B
Cliente-Pago
Cajero-Pago
A es una transacción relacionada
con otra transacción B
Pago-Venta
A está contiguo a B

A es una propiedad de B
TPDV-Tienda






Principales clases y relaciones
Identificación de relaciones
·        Relaciones que “deben conocerse”
·         TPDV captura venta: para conocer la venta
            actual genera un total, e imprime el recibo.
·         Venta pagada en efectivo: para saber si se
           pagó la venta, relaciona la cantidad ofrecida
           con el total de la venta e imprime un recibo.
·         Catalogo de productos registra
           especificación de productos: para
           recuperar una especificación de producto
           con un código universal de producto.

Principales clases y relaciones
Identificación de relaciones
Estudio de algunas relaciones

RELACION
EEEEEEEEXPLICACION
Venta capturada-por cajero
Los requerimientos no indican la
necesidad de conocer ni de registrar
al cajero actual. Además, es
derivable si existe la asociación
TPDV usado-por cajero.
TPDV usado-por cajero
Los requerimientos no indican la
necesidad de registrar o conocer el
cajero actual.
TPDV iniciado-por gerente
Los requerimientos no indican la
necesidad de conocer ni registrar al
gerente que inició un TPDV
Venta iniciada-por cliente
Los requerimientos no indican la
necesidad de conocer ni registrar al
cliente actual que inició una venta
Tienda almacena producto
Los requerimientos no indican la
necesidad de conocer o mantener la
información de inventario
Linea de producto vendido registra
venta de producto
Los requerimientos no indican la
necesidad de mantener la
información de inventario



Principales clases y relaciones
Identificación de los atributos
·        Pago: importe.
·        Especificación de producto: descripción,
           CUP y precio.
·        Venta: fecha y hora.
·        Venta de línea de producto: cantidad.
·        Tienda: nombre y dirección.

Diagrama de clases