MENU

INTRODUCCION



Tabla de contenido.



. 1.     Introducción
Dentro de cualquier institución, los recursos humanos juegan un papel muy importante. Para ello, es necesario contar con un buen sistema de adquisición de recursos. Dentro de la universidad se trabajan cientos de personas, con roles muy diversos. Sin duda todos ellos fueron contratados por medio de alguna convocatoria.
Siendo más especifico, cada carrera se encarga de la adquisición de docentes y auxiliares de docencia, según sus necesidades. Por lo general, este procedimiento se lo realiza anual y semestralmente. Pero no siempre se obtienen los prospectos que la carrera desea, y por eso es necesario emitir más de una convocatoria.
22.      Antecedentes
Dentro de la carrera de Informática, el proceso de convocatorias es una tarea llevada a cabo por varias personas: director académico, personal de kardex, jefatura de carrera, tribunales docente y estudiantil.
Actualmente este proceso es muy laborioso y tardío. Especialmente a principios de año, cuando se requiere más personal. Aparte, que si no se llegan a cubrir los ITEMS disponibles, de debe realizar todo el proceso nuevamente.
Cabe resaltar, que la carrera se encarga de dos tipos de convocatorias, una para docentes y otra para auxiliares de docencia. Los pasos de adquisición de los mismos no difieren en gran manera, salvo en los prerrequisitos solicitados y las evaluaciones. En este documento nos adentraremos más al proceso de convocatorias docentes.
33.      Árbol de problemas

 ARBOL DE PROBLEMAS
EFECTO


































                   
CAUSA

-       Elegir tribunales, tanto docente como estudiantil
-       Programar el cronograma
-       Registrar postulantes
-       Asignar los temas a exponer
-       Evaluar los meritos
-       Revisar y verificar la autenticidad de certificados
-       Demora de la publicación de notas
55.      Propósito de estudio

Desarrollar una plataforma de gestión de convocatorias, que ayude a minimizar tiempo en el proceso de adquisición de personal para la carrera de informática.

·         Llevar un control estricto de las convocatorias lanzadas.
·         Guardar un historial sobre los docentes y estudiantes que fueron elegidos tribunales.
·         Registrar a todos los postulantes de las convocatorias.


Xp (Extreme Programming) nuevo método de desarrollo de software, es un método ligero en contraposición a los métodos pesados como métrica. Este método se descubrió hace 5 años por KENT BECK en Damlerchrysler, después de haber trabajado por varios años con Ward Cunningham en busca de una nueva aproximación al problema de desarrollo de software que hiciera las cosas más simples de lo que tenían acostumbrados los métodos existentes.

Xp define 4 variables para cualquier proyecto de software: el costo, tiempo, calidad y alcance.

En el año 2001, 17 personas redactaron el
manifiesto ágil, en el que expresaron los siguientes puntos principales:

-     Individuos e interacciones en lugar de procesos y herramientas
-     Desarrollo de software en lugar de documentación exhaustiva
-     Trabajo con el cliente en lugar de negociaciones contractuales
-     Apertura para los cambios en lugar de cumplimiento de planes poco flexibles.

La Programación extrema se basa en los siguientes conceptos:

-     Los equipos de desarrollo trabajan directamente con el cliente durante
Ciclos cortos de una o dos semanas como máximo.
-     La entrega de las versiones del software ocurre muy temprano y en
intervalos muy cortos para maximizar la interacción con el usuario.
-     Existe una fuerte colaboración entre el equipo de desarrollo mientras
trabaja en el código.
-     El código se prueba y depura a lo largo del proceso de desarrollo.
-     Existen indicadores que miden el progreso del proyecto para poder
actualizar el plan de desarrollo.

Características

Las características fundamentales del método son:

  • Desarrollo iterativo e incremental: pequeñas mejoras, unas tras otras.
  • Pruebas unitarias continuas, frecuentemente repetidas y automatizadas, incluyendo pruebas de regresión. Se aconseja escribir el código de la prueba antes de la codificación. Véase, por ejemplo, las herramientas de prueba JUnit orientada a Java, DUnit orientada a Delphi y NUnit para la plataforma.NET. Estas dos últimas inspiradas en JUnit.
  • Programación en parejas: se recomienda que las tareas de desarrollo se lleven a cabo por dos personas en un mismo puesto. Se supone que la mayor calidad del código escrito de esta manera -el código es revisado y discutido mientras se escribe- es más importante que la posible pérdida de productividad inmediata.
  • Frecuente integración del equipo de programación con el cliente o usuario. Se recomienda que un representante del cliente trabaje junto al equipo de desarrollo.
  • Corrección de todos los errores antes de añadir nueva funcionalidad. Hacer entregas frecuentes.
  • Refactorización del código, es decir, reescribir ciertas partes del código para aumentar su legibilidad y mantenibilidad pero sin modificar su comportamiento. Las pruebas han de garantizar que en la refactorización no se ha introducido ningún fallo.
  • Propiedad del código compartida: en vez de dividir la responsabilidad en el desarrollo de cada módulo en grupos de trabajo distintos, este método promueve el que todo el personal pueda corregir y extender cualquier parte del proyecto. Las frecuentes pruebas de regresión garantizan que los posibles errores serán detectados.
  • Simplicidad en el código: es la mejor manera de que las cosas funcionen. Cuando todo funcione se podrá añadir funcionalidad si es necesario. La programación extrema apuesta que es más sencillo hacer algo simple y tener un poco de trabajo extra para cambiarlo si se requiere, que realizar algo complicado y quizás nunca utilizarlo.
La simplicidad y la comunicación son extraordinariamente complementarias. Con más comunicación resulta más fácil identificar qué se debe y qué no se debe hacer. Mientras más simple es el sistema, menos tendrá que comunicar sobre este, lo que lleva a una comunicación más completa, especialmente si se puede reducir el equipo de programadores.




7



No hay comentarios:

Publicar un comentario