UNIVERSIDAD VERACRUZANA

Facultad de Contadura y Administracin

Anlisis y Diseo del Sistema de Apoyo a la Toma
de Decisiones para Asignacin de Sinodales de
Exmenes Profesionales en La Facultad de
Contadura y Administracin

TESINA
para obtener el Ttulo de:

Licenciado en Sistemas
Computacionales Administrativos
Presenta:

Diego Antonio Barbabosa Suanes

Asesor:

M.T.E. Mara Luisa Velasco Ramrez

Co-asesor:

M.E. Patricia Arieta Melgarejo

Cuerpo Acadmico:

Tecnologas de la Informacin y las

Organizaciones Inteligentes en la Sociedad del
Conocimiento
Xalapa-Enrquez, Veracruz

Agosto 2009

UNIVERSIDAD VERACRUZANA
Facultad de Contadura y Administracin
Anlisis y Diseo del Sistema de Apoyo a la Toma
de Decisiones para Asignacin de Sinodales de
Exmenes Profesionales en La Facultad de
Contadura y Administracin

TESINA
para obtener el Ttulo de:

Licenciado en Sistemas
Computacionales Administrativos
Presenta:

Diego Antonio Barbabosa Suanes

Asesor:

M.T.E. Mara Luisa Velasco Ramrez

Co-asesor:

M.E. Patricia Arieta Melgarejo

Cuerpo Acadmico:

Tecnologas de la Informacin y las

Organizaciones Inteligentes en la Sociedad del
Conocimiento
Xalapa-Enrquez, Veracruz

Agosto 2009

DEDICATORIA

A mis padres y hermanos por su gran amor y

comprensin, sin ellos no hubiera podido lograr lo que
soy ni cumplir mis metas, a ellos les debo todo mi
respeto, mi vida y mi amor. Dios los bendiga tanto
como a m me llen de bendiciones al darme la familia
que tengo.

II

AGRADECIMIENTOS

A la maestra Mara Luisa que con su disposicin y

paciencia me apoy en la realizacin de este trabajo y a
lo largo de mis estudios de la licenciatura.
A la maestra Paty que tanto me apoy a lo largo de la
carrera y en este trabajo de investigacin, por su cario
y comprensin.
Y por ltimo pero no menos importante, a mi flaquita
que con su amor, cario, comprensin y mucha
paciencia, me ha llenado de felicidad, me ha ayudado a
salir adelante y a crecer como persona, a ti mi vida
gracias y gracias a dios por ponerte en mi camino, te
amo.
III

NDICE
Pgina
RESUMEN 1
INTRODUCCIN..... 2

Captulo I: MARCO TERICO . 6

1.1 Planteamiento del problema. 7
1.2 Enunciado del problema ...... 8
1.3 Propuesta de solucin . 8
1.4 Justificacin de la investigacin...... 9
1.5 Delimitaciones.10
1.6 Limitaciones de la investigacin...... 11
1.7 Alcances de la investigacin ... 11
1.8 Objetivos de la investigacin 11
1.8.1 General. 11
1.8.2 Especficos... 12

Captulo II: MARCO TERICO CONCEPTUAL DE REFERENCIA.. 13

2.1 Marco Legal.14
2.2 Base terica 16
2.2.1 Conceptos bsicos. 16
2.2.2 Metodologa de desarrollo. 27
2.2.2.1 Ciclo de vida. 27
2.2.2.2 Modelo de prototipos... 30
2.2.2.3 Metodologas giles. 33
2.2.2.4 Programacin extrema 33
2.2.2.5 SCRUM. 38
2.2.2.6 Desarrollo rpido de aplicaciones (RAD). 41
2.2.3 Toma de decisiones 48
2.2.3.1 rboles de decisin. 49
IV

Pgina

Captulo III: ANLISIS DEL SISTEMA54

3.1 Resumen ejecutivo 55
3.2 Anlisis de sistemas de apoyo a la toma de decisiones. 58
3.3 Factibilidad del sistema. 59
3.4 Contexto del dominio del problema. 62
3.5 Requisitos del sistema.. 64
3.5.1 Requisitos funcionales... 65
3.5.2 Requisitos de implementacin.. 67
3.5.3 Requisitos de seguridad 67
3.6 Modelo conceptual. 68

Captulo IV: DISEO.. 69

4.1 Diseo del sistema. 70
4.2 Modelo lgico.. 71
4.3 Modelo fsico... 73
4.4 Diseo de rboles de decisin. 75
4.5 Diccionario de datos.. 79

CONCLUSIONES. 83
FUENTES DE INFORMACIN.. 87
GLOSARIO 89

RESUMEN

El aseguramiento de la calidad y el mejoramiento permanente de los

procesos acadmicos y de gestin, han sido la prioridad de la Universidad
Veracruzana en los ltimos aos, incorporando las tecnologas de informacin que
permiten la automatizacin de los mismos, y que a su vez, le dan a la informacin
un enfoque global que aseguran un mejor aprovechamiento de la sta.

El Sistema de Apoyo a la Toma de Decisiones para Asignacin de Sinodales de

Exmenes Profesionales en la Facultad de Contadura y Administracin, se
desarrollo en sus etapas de anlisis y diseo, utilizando el modelo de Desarrollo
Rpido de aplicaciones (RAD); haciendo uso de herramientas para la
documentacin, con una orientacin a objetos a travs de UML (Lenguaje de
Modelado Unificado), con diagramas de clase; todo esto para definir un sistema
integral que apoye a la coordinacin de la experiencia educativa Experiencia
Recepcional, en la asignacin de sinodales a sus estudiantes inscritos.

INTRODUCCIN

Este trabajo de investigacin surgi a travs de una propuesta de la

Facultad de Contadura y Administracin, a unos estudiantes de la misma, de
realizar un sistema de apoyo a toma de decisiones que ayudar a la direccin, en
conjunto con la Coordinacin de Experiencia Recepcional, en la asignacin de los
maestros que fungen como jurado en los exmenes profesionales.
Tras una entrevista con los encargados de asesorar el proyecto, se decidi llevarlo
a cabo como una propuesta de solucin, tomando como muestra a la generacin
de estudiantes 2005-2009, de la licenciatura en Sistemas Computacionales
Administrativos de la Facultad de Contadura y Administracin campus Xalapa.
La propuesta consista bsicamente en el desarrollo de un sistema de informacin
de apoyo a la toma de decisiones que controlara la inscripcin de los estudiantes a
la experiencia recepcional y capturara el perfil de los trabajos recepcionales con el
fin de proponer a los sinodales ms idneos para fungir como jurado de los
mismos, ya que la informacin de el perfil de los maestros y de los trabajos
recepcionales no se tiene en ninguna base de datos, por lo que aunque se cuenta
con ella, sera ms fcil si contar con un sistema de informacin para
manipularla.
Un sistema de informacin es un conjunto de elementos que interactan entre s
con el fin de apoyar las actividades de una empresa o negocio.
Los sistemas de Apoyo de las Decisiones se definen como un conjunto de
programas y herramientas que permiten obtener oportunamente la informacin
requerida durante el proceso de la toma de decisiones, en un ambiente de
incertidumbre.

Las principales caractersticas de estos son: introducirse despus de haber

implantado los Sistemas Transaccionales ms relevantes de la empresa, ya que
estos ltimos constituyen su plataforma de informacin.
La informacin que generan sirve de apoyo a los mandos intermedios y a la alta
administracin en el proceso de toma de decisiones.
Suelen ser intensivos en clculos y escasos en entradas y salidas de informacin.
As, por ejemplo, un modelo de planeacin financiera requiere poca informacin de
entrada, genera poca informacin como resultado, pero puede realizar muchos
clculos durante su proceso.
No suelen ahorrar mano de obra. Debido a ello, la justificacin econmica para el
desarrollo de estos sistemas es difcil, ya que no se conocen los ingresos del
proyecto de inversin.
Suelen ser Sistemas de Informacin interactivos y amigables, con altos estndares
de diseo grfico y visual, ya que estn dirigidos al usuario final.
Apoyan la toma de decisiones que, por su misma naturaleza son repetitivos y de
decisiones no estructuradas que no suelen repetirse. Por ejemplo, un Sistema de
Compra de Materiales que indique cundo debe hacerse un pedido al proveedor o
un Sistema de Simulacin de Negocios que apoye la decisin de introducir un
nuevo producto al mercado.
Estos sistemas pueden ser desarrollados directamente por el usuario final sin la
participacin operativa de los analistas y programadores del rea de informtica.
Este tipo de sistemas puede incluir la programacin de la produccin, compra de
materiales, flujo de fondos, proyecciones financieras, modelos de simulacin de
negocios, modelos de inventarios, etc.
La elaboracin de este proyecto se realizar con el modelo de Desarrollo Rpido
de Aplicaciones (RAD), el cual contempla las siguientes etapas: necesidad,
planeacin, anlisis, diseo, desarrollo, implementacin de un prototipo, si el
4

prototipo es incorrecto, se regresa a la etapa de anlisis, y si es correcto, se

implementa el sistema.
En especfico este trabajo contempla las primeras etapas hasta la de diseo,
haciendo especial nfasis en el anlisis y la antes mencionada etapa de diseo.
El Desarrollo Rpido de Aplicaciones (DRA) (rapid application Development RAD)
es un modelo de proceso del desarrollo del software lineal secuencial que enfatiza
un ciclo de desarrollo extremadamente corto. DRA es una adaptacin a "Alta
velocidad" en el que se logra el desarrollo rpido utilizando un enfoque de
construccin basado en componentes. Si se comprenden bien los requisitos y se
limita el mbito del proyecto, el proceso DRA permite al equipo de desarrollo crear
un "sistema completamente funcional" dentro de periodos cortos de tiempo.
Un Anlisis de Sistema se lleva a cabo teniendo en cuenta los siguientes objetivos
en mente:

Identifique las necesidades del Cliente.

Evale que conceptos tiene el cliente del sistema para establecer su

viabilidad.

Realice un Anlisis Tcnico y econmico.

Asigne funciones al Hardware, Software, personal, base de datos, y otros

elementos del Sistema.

Establezca las restricciones de presupuestos y planificacin temporal.

Cree una definicin del sistema que forme el fundamento de todo el trabajo
de Ingeniera.

Y el Diseo de Sistemas se define el proceso de aplicar ciertas tcnicas y

principios con el propsito de definir un dispositivo, un proceso o un Sistema, con
suficientes detalles como para permitir su interpretacin y realizacin fsica.

CAPTULO I. MARCO TERICO

1.1 Planteamiento del problema

En la Facultad de Contadura y Administracin existe un Centro de apoyo a la
titulacin (CAT), a travs del cual los estudiantes tienen la oportunidad de escoger
a su jurado para su examen profesional.
Actualmente, el CAT cuenta con un sistema que ofrece a cada uno de los
estudiantes inscritos en l, la opcin de elegir a dos sinodales propietarios y dos
sinodales suplentes. Dichos sinodales deben pertenecer a una academia
relacionada con el rea de inters, las asignaciones son revisadas por el Director
de la Facultad de Contadura y Administracin el cual es el encargado de aceptar
o rechazar las solicitudes.
En caso de que la solicitud del interesado fuera rechazada se le hace saber para
que cambie a sus sinodales, este caso se dar cuando el profesor no pertenezca
al rea de inters del trabajo recepcional o ste tenga el nmero mximo de
trabajos recepcionales.
Una vez aprobada la asignacin a los estudiantes o egresados de asesores y
sinodales inscritos en el CAT, el Director procede a la asignacin de sinodales de
los estudiantes o egresados que no estn inscritos en el CAT.
El proceso de asignacin de sinodales para los estudiantes que no estn inscritos
al CAT es el siguiente:
Se toma como referencia el rea del trabajo recepcional realizado con la finalidad
de asignar sinodales que pertenecen a la academia de dicha rea, adems se
debe revisar el nmero de asignaciones que tiene, ya que un sinodal no puede
tener ms de seis tesistas, con la finalidad de tener mayor acercamiento con los
trabajos a revisar, pero si as lo desea puede asignrsele ms de seis. A cada
alumno debern asignarle dos sinodales y dos suplentes.
7

Estas decisiones las lleva a cabo el Director de la Facultad con la ayuda de la

Coordinacin de Experiencia Recepcional.

1.2 Enunciado del problema

La informacin con la que se cuenta en el proceso de asignacin de sinodales, no
cumple con las caractersticas ms convenientes para un eficiente proceso de
toma de decisiones.

1.3 Propuesta de solucin

Desarrollar e Implementar un sistema de apoyo a la toma de decisiones en el
proceso de asignacin de jurado a los estudiantes inscritos en la experiencia
recepcional en su modalidad de trabajo recepcional.
Etapas para el desarrollo e implementacin:
Anlisis
Diseo
Implementacin
Pruebas

Debido a la limitacin de tiempo y a la complejidad del proyecto, el mismo se

dividir en dos partes, por lo tanto este trabajo comprender solo las etapas de
anlisis y diseo.

El anlisis abarcar desde la investigacin de los antecedentes de la experiencia

educativa Experiencia Recepcional, el CAT, entrevistas con los actores de los
procesos y la recopilacin de toda la informacin posible para observarla y
revisarla.

La etapa de diseo comprender la realizacin del modelo conceptual, lgico y

fsico, y el modelado de la base de datos, terminando con la documentacin del
sistema de informacin, todo esto con base en el anlisis de la informacin antes
recopilada.

1.4 Justificacin de la investigacin

El anlisis y el diseo son dos etapas imprescindibles en el desarrollo de un
sistema, debido a que la investigacin se basa en el desarrollo de un sistema de
apoyo a la toma de decisiones como herramienta para facilitar el proceso de
asignacin del jurado a los tesistas inscritos en la experiencia recepcional, es
necesario hacer un anlisis previo el cual contemple la problemtica, los usuarios,
la metodologa y todos los requerimientos necesarios para el diseo de la
solucin.
El presente trabajo tiene su fundamentacin en facilitar la toma de decisiones en la
asignacin del jurado para los exmenes profesionales de los estudiantes que
presentan su trabajo recepcional.
El proceso de asignacin del jurado se lleva a cabo mediante un conjunto de
reglas que ayudan a la eleccin de los mismos, evaluando la experiencia de los
maestros en el tema, es como se seleccionan los dos sinodales titulares y los dos
suplentes.
El propsito es facilitarle, al encargado de experiencia recepcional, el proceso de
evaluacin del perfil de los maestros, dndole a conocer como resultado quienes
son los maestros ms aptos para fungir como sinodales en los exmenes
profesionales. Tomando como referencia el perfil tanto del maestro como del
trabajo recepcional.
Para la elaboracin de este sistema de apoyo a la toma de decisiones se utilizar
el modelo rboles de decisin, el cual nos ayudar a arrojar el resultado ms
ptimo comparando el perfil del trabajo con el de los maestros.
9

Es un sistema flexible, ya que adems de proponer las opciones ms ptimas, le

permite al encargado de la asignacin, hacerlo de manera manual, pudiendo elegir
a cualquier profesor perteneciente a la propia facultad.
Adems de la toma de decisiones, el sistema ayuda a controlar las peticiones de
los estudiantes llevando un registro de los trabajos recepcionales, siendo los
propios estudiantes quienes introducen el perfil de su trabajo al sistema, en lugar
de el encargado de la experiencia recepcional, ste solo atiende las peticiones
aceptndolas o rechazndolas segn su criterio, luego de aceptarlas les asigna a
sus sinodales, con la ayuda antes mencionada que proporciona el sistema. De
esta manera le facilitamos el trabajo de asignacin y el tiempo que se llevara en
hacerlo manualmente.
Por otro lado tambin se le ofrecen ventajas al alumno, ya que no tiene que
trasladarse al lugar fsico para hacer la solicitud, sino que la puede hacer desde
cualquier equipo de cmputo dentro de la facultad que tenga acceso a internet y a
cualquier hora, dndole una gran ventaja de tiempo.
Por lo antes mencionado y ms ventajas, ste sistema es una muy buena opcin
para el mejoramiento de los trmites y el control de la experiencia recepcional.

1.5 Delimitaciones
Espacio: La investigacin se delimitara a la Facultad de Contadura y
Administracin, enfocndose al control y seguimiento de la asignacin de
directores, sinodales titulares y suplentes.
Tiempo: Un periodo de cuatro meses (Marzo Junio 2009).
Poblacin: Estudiantes inscritos en la experiencia educativa Experiencia
Recepcional, especficamente en la modalidad de trabajo recepcional.

10

Muestra: Las pruebas a realizar se harn con los datos de estudiantes en

sistemas computacionales administrativos de la generacin 2005 que en
este momento estn cursando esta modalidad de experiencia recepcional.

1.6 Limitaciones de la investigacin

El sistema estar albergado en el servidor de la Facultad de Contadura y
Administracin, y disponible de manera local. Se realizar el diseo conceptual,
lgico y fsico de la base de datos del sistema as como los mdulos que
comprender.

1.7 Alcances de la investigacin

El sistema dar seguimiento a los estudiantes desde que se inscriben en
experiencia recepcional en la modalidad de trabajo recepcional hasta que se les
asignan sus sinodales. Pasando por un anlisis del perfil de su trabajo y de los
profesores actualmente activos, disponibles y que cumplan en mayor parte con el
perfil del trabajo.

1.8 Objetivos de la investigacin

1.8.1 Objetivo general
Disear y desarrollar una propuesta de solucin que permita, al coordinador
de

la

experiencia

recepcional

de

la

Facultad

de

Contadura

Administracin, la seleccin y asignacin de sinodales, tomando en cuenta

las variables necesarias para determinarlos y que se adecuen de acuerdo al
rea del trabajo recepcional de cada estudiante, con la finalidad de tener un
control ms detallado de este proceso.
11

1.8.2 Objetivos especficos

Revisar las bases tericas de diseo de sistemas de Apoyo a la Toma de
Decisiones
Definir la problemtica
Definir el alcance de la investigacin
Determinar la viabilidad del sistema
Distinguir entre los antecedentes y trabajos actuales (CAT)
Delimitar las actividades de Experiencia Recepcional y sus actores
Entrevistar a los usuarios tentativos
Identificacin de requerimientos
Analizar la solucin
Realizar las correcciones necesarias
Documentar el diseo de la solucin

12

CAPTULO II. MARCO TERICO CONCEPTUAL DE

REFERENCIA

2.1 Marco legal

La Experiencia Recepcional, es una experiencia educativa que se rige bajo los
lineamientos para el control escolar del Modelo Educativo, Integral y Flexible
(MEIF) de la Universidad Veracruzana, del artculo 50 al 58:

50. La Experiencia Recepcional es una actividad acadmica integradora de

conocimientos. Cada programa acadmico establecer los antecedentes o prerequisitos acadmicos que se requieren para inscribirse en ella. En estos
antecedentes deber contemplarse el que los estudiantes hayan cubierto al menos
el 70% de los crditos del programa acadmico. Es una de carcter obligatorio y,
por su naturaleza, no es susceptible de ser acreditada mediante equivalencia
revalidacin o examen de competencia.
51. La experiencia recepcional se considera como experiencia educativa cursativa,
por lo que su acreditacin tendr que realizarse con carcter de ordinario, y se
sujetara a los lineamientos establecidos para las dems experiencias educativas
de esta naturaleza.
52. Las caractersticas de la experiencia recepcional sern establecidas por la
Junta Acadmica en el Reglamento Interno de la entidad acadmica respectiva.
53. La experiencia recepcional es responsabilidad de los docentes encargados de
la misma, tanto en sus aspectos acadmicos, como en lo relativo a la
programacin, el seguimiento y la evaluacin, sujetndose a los lineamientos
establecidos para las dems experiencias educativas. Podr haber un programa
que se desprenda de las Lneas de generacin y aplicacin del conocimiento
(LGAC).

14

54. La experiencia recepcional puede adoptar las modalidades de: Tesis; Tesina;
monografa; reporte tcnico; memoria; presentacin de trabajos prcticos de tipo
cientfico, educativo, artstico o tcnico; obtencin de 1,000 o ms puntos en el
Examen General de Egreso de la Licenciatura del CENEVAL; aprobacin, con
carcter de ordinario en primera inscripcin y con promedio general mnimo de
nueve, en las de ms experiencias educativas establecidas en el programa
acadmico correspondiente; aprobacin del Examen General de Conocimientos,
automticamente si mantiene un promedio de 9 en todo, aprueba la experiencia
recepcional.
55. La evaluacin de la experiencia recepcional estar a cargo de un jurado de 3 a
5 sinodales, designado por el Director de la entidad acadmica, a propuesta del
Consejo Tcnico, y en el que se incluir al acadmico responsable de la misma y
al asesor del trabajo final.
56. Con la finalidad de obtener una calificacin numrica, los resultados del
Examen General de Egreso de la Licenciatura sern registrados de la siguiente
manera:
De 1,000 a 1,099 puntos = 8
De 1,000 a 1,199 puntos = 9
De 1,200 a 1,300 puntos = 10
57. Para la acreditacin de la experiencia recepcional por medio, la calificacin
numrica se obtendr de la siguiente manera:
Promedio de 9.0 a 9.4 = 9
Promedio de 9.5 a 10 = 10
58. La mencin honorfica es el reconocimiento que la Universidad Veracruzana
otorga a los egresados cuando cumplen algunos de los siguientes requisitos:

15

I. Que obtengan un promedio general mnimo de nueve en exmenes ordinarios

de primera inscripcin.
II. Que presenten un trabajo recepcional en cualquier modalidad, que represente
una aportacin relevante en el terreno de la disciplina correspondiente.
III. Que obtengan testimonio de alto rendimiento en la presentacin del Examen
General de Egreso de la Licenciatura (EGEL). (Lineamientos para el control
escolar, 2002)

2.2 Base terica

2.2.1 Conceptos bsicos

Las experiencias educativas deben ser entendidas no slo como las que se
realizan en el aula, sino como aqullas que promueven aprendizajes,
independientemente del mbito donde se lleven a cabo. El logro de una formacin
integral para el alumno depender no slo de los conocimientos recibidos en el
aula, sino de la ampliacin de los lmites de los contextos de aprendizaje a
diferentes mbitos de la labor profesional y del desarrollo social y personal.
Sistema de informacin es un conjunto de elementos que interactan entre s
con el fin de apoyar las actividades de una empresa o negocio.
El equipo computacional: el hardware necesario para que el sistema de
informacin pueda operar.
El recurso humano que interacta con el Sistema de Informacin, el cual est
formado por las personas que utilizan el sistema.
Un sistema de informacin realiza cuatro actividades bsicas: entrada,
almacenamiento, procesamiento y salida de informacin. (Peralta, 2009)
16

Entrada de Informacin: Es el proceso mediante el cual el Sistema de

Informacin toma los datos que requiere para procesar la informacin. Las
entradas pueden ser manuales o automticas. Las manuales son aquellas que se
proporcionan en forma directa por el usuario, mientras que las automticas son
datos o informacin que provienen o son tomados de otros sistemas o mdulos.
Esto ltimo se denomina interfaces automticas.
Las unidades tpicas de entrada de datos a las computadoras son las terminales,
las cintas magnticas, las unidades de diskette, los cdigos de barras, los
escners, la voz, los monitores sensibles al tacto, el teclado y el mouse, entre
otras. (Peralta, 2009)
Almacenamiento de informacin: El almacenamiento es una de las actividades
o capacidades ms importantes que tiene una computadora, ya que a travs de
esta propiedad el sistema puede recordar la informacin guardada en la seccin o
proceso anterior. Esta informacin suele ser almacenada en estructuras de
informacin denominadas archivos. La unidad tpica de almacenamiento son los
discos magnticos o discos duros, los discos flexibles o diskettes y los discos
compactos (CD-ROM). (Peralta, 2009)
Procesamiento de Informacin: Es la capacidad del Sistema de Informacin
para efectuar clculos de acuerdo con una secuencia de operaciones
preestablecida. Estos clculos pueden efectuarse con datos introducidos
recientemente en el sistema o bien con datos que estn almacenados. Esta
caracterstica de los sistemas permite la transformacin de datos fuente en
informacin que puede ser utilizada para la toma de decisiones, lo que hace
posible, entre otras cosas, que un tomador de decisiones genere una proyeccin
financiera a partir de los datos que contiene un estado de resultados o un balance
general de un ao base. (Peralta, 2009)
Salida de Informacin: La salida es la capacidad de un Sistema de Informacin
para sacar la informacin procesada o bien datos de entrada al exterior. Las
unidades tpicas de salida son las impresoras, terminales, diskettes, cintas
17

magnticas, la voz, los graficadores y los plotters, entre otros. Es importante

aclarar que la salida de un Sistema de Informacin puede constituir la entrada a
otro Sistema de Informacin o mdulo. En este caso, tambin existe una interface
automtica de salida. Por ejemplo, el Sistema de Control de Clientes tiene una
interface automtica de salida con el Sistema de Contabilidad, ya que genera las
plizas contables de los movimientos procesales de los clientes. (Ver figura 2.1)

Entrada
de
Datos

Reportes
e
informes
Proceso

Interface
Automtico
de entrada

Almacenamiento

Interface
Automtico
de salida

.
Figura 2.1 Etapas de los sistemas de informacin.

Tipos y Usos de los Sistemas de Informacin

Durante los prximos aos, los Sistemas de Informacin cumplirn tres objetivos
bsicos dentro de las organizaciones:
1. Automatizacin de procesos operativos.
2. Proporcionar informacin que sirva de apoyo al proceso de toma de
decisiones.
3. Lograr ventajas competitivas a travs de su implantacin y uso.

18

Los Sistemas de Informacin que logran la automatizacin de procesos operativos

dentro

de

una

organizacin,

son

llamados

frecuentemente

Sistemas

Transaccionales, ya que su funcin primordial consiste en procesar transacciones

tales como pagos, cobros, plizas, entradas, salidas, etc. Por otra parte, los
Sistemas de Informacin que apoyan el proceso de toma de decisiones son los
Sistemas de Soporte a la Toma de Decisiones, Sistemas para la Toma de
Decisin de Grupo, Sistemas Expertos de Soporte a la Toma de Decisiones y
Sistema de Informacin para Ejecutivos. El tercer tipo de sistema, de acuerdo con
su uso u objetivos que cumplen, es el de los Sistemas Estratgicos, los cuales se
desarrollan en las organizaciones con el fin de lograr ventajas competitivas, a
travs del uso de la tecnologa de informacin. (Ver figura 2.2)

Clientes
Sistemas
Estrategias

Sistemas de
Apoyo a las
Decisiones
(Nivel
gerencial)
Sistemas Estratgicos
(Ejecutivos)

Clientes
Sistemas
Estrategias

Sistemas Estratgicos
(Nivel operativo)

Competencia

Figura 2.2 Tipos de sistemas de informacin.

A continuacin se mencionan las principales caractersticas de estos tipos de

Sistemas de Informacin.
19

Sistemas Transaccionales. Sus principales caractersticas son:

A travs de stos suelen lograrse ahorros significativos de mano de obra,

debido a que automatizan tareas operativas de la organizacin.

Con frecuencia son el primer tipo de Sistemas de Informacin que se

implanta en las organizaciones. Se empieza apoyando las tareas a nivel
operativo de la organizacin.

Son intensivos en entrada y salid de informacin; sus clculos y procesos

suelen ser simples y poco sofisticados.

Tienen la propiedad de ser recolectores de informacin, es decir, a travs

de estos sistemas se cargan las grandes bases de informacin para su
explotacin posterior.

Son fciles de justificar ante la direccin general, ya que sus beneficios son
visibles y palpables. (Peralta, 2009)

Sistemas de Apoyo de las Decisiones. Las principales caractersticas de estos

son:

Suelen

introducirse

despus

de

haber

implantado

los

Sistemas

Transaccionales ms relevantes de la empresa, ya que estos ltimos

constituyen su plataforma de informacin.

La informacin que generan sirve de apoyo a los mandos intermedios y a la

alta administracin en el proceso de toma de decisiones.

Suelen ser intensivos en clculos y escasos en entradas y salidas de

informacin. As, por ejemplo, un modelo de planeacin financiera requiere
poca informacin de entrada, genera poca informacin como resultado,
pero puede realizar muchos clculos durante su proceso.

20

No suelen ahorrar mano de obra. Debido a ello, la justificacin econmica

para el desarrollo de estos sistemas es difcil, ya que no se conocen los
ingresos del proyecto de inversin.

Suelen ser Sistemas de Informacin interactivos y amigables, con altos

estndares de diseo grfico y visual, ya que estn dirigidos al usuario final.

Apoyan la toma de decisiones que, por su misma naturaleza son repetitivos

y de decisiones no estructuradas que no suelen repetirse. Por ejemplo, un
Sistema de Compra de Materiales que indique cundo debe hacerse un
pedido al proveedor o un Sistema de Simulacin de Negocios que apoye la
decisin de introducir un nuevo producto al mercado.

Estos sistemas pueden ser desarrollados directamente por el usuario final

sin la participacin operativa de los analistas y programadores del rea de
informtica.

Este tipo de sistemas puede incluir la programacin de la produccin, compra de

materiales, flujo de fondos, proyecciones financieras, modelos de simulacin de
negocios, modelos de inventarios, etc. (Peralta Manuel, 2009)
Sistemas Estratgicos. Sus principales caractersticas son:

Su funcin primordial no es apoyar la automatizacin de procesos

operativos ni proporcionar informacin para apoyar la toma de decisiones.

Suelen desarrollarse in house, es decir, dentro de la organizacin, por lo

tanto no pueden adaptarse fcilmente a paquetes disponibles en el
mercado.

Tpicamente su forma de desarrollo es a base de incrementos y a travs de

su evolucin dentro de la organizacin. Se inicia con un proceso o funcin
en particular y a partir de ah se van agregando nuevas funciones o
procesos.

21

Su funcin es lograr ventajas que los competidores no posean, tales como

ventajas en costos y servicios diferenciados con clientes y proveedores. En
este contexto, los Sistema Estratgicos son creadores de barreras de
entrada al negocio. Por ejemplo, el uso de cajeros automticos en los
bancos en un Sistema Estratgico, ya que brinda ventaja sobre un banco
que no posee tal servicio. Si un banco nuevo decide abrir sus puertas al
pblico, tendr que dar este servicio para tener un nivel similar al de sus
competidores.

Apoyan el proceso de innovacin de productos y proceso dentro de la

empresa debido a que buscan ventajas respecto a los competidores y una
forma de hacerlo en innovando o creando productos y procesos.

Un ejemplo de estos Sistemas de Informacin dentro de la empresa puede ser un

sistema

MRP

(Manufacturing

Resource

Planning)

enfocado

reducir

sustancialmente el desperdicio en el proceso productivo, o bien, un Centro de

Informacin que proporcione todo tipo de informacin; como situacin de crditos,
embarques, tiempos de entrega, etc. En este contexto los ejemplos anteriores
constituyen un Sistema de Informacin Estratgico si y slo s, apoyan o dan
forma a la estructura competitiva de la empresa.
Por ltimo, es importante aclarar que algunos autores consideran un cuarto tipo de
sistemas de informacin denominado Sistemas Personales de Informacin, el cual
est enfocado a incrementar la productividad de sus usuarios. (Peralta Manuel,
2009)
Evolucin de los Sistemas de Informacin
De la seccin anterior se desprende la evolucin que tienen los Sistemas de
Informacin en las organizaciones. Con frecuencia se implantan en forma inicial
los Sistemas Transaccionales y, posteriormente, se introducen los Sistemas de
Apoyo a las Decisiones. Por ltimo, se desarrollan los Sistemas Estratgicos que
dan forma a la estructura competitiva de la empresa.

22

En la dcada de los setenta, Richard Nolan, un conocido autor y profesor de la

Escuela de Negocios de Harvard, desarroll una teora que impact el proceso de
planeacin de los recursos y las actividades de la informtica.
Segn Nolan, la funcin de la Informtica en las organizaciones evoluciona a
travs de ciertas etapas de crecimiento, las cuales se explican a continuacin:

Comienza con la adquisicin de la primera computadora y normalmente se

justifica por el ahorro de mano de obra y el exceso de papeles.

Las

aplicaciones

tpicas

que

se

implantan

son

los

Sistemas

Transaccionales tales como nminas o contabilidad.

El pequeo Departamento de Sistemas depende en la mayora de los casos

del rea de contabilidad.

El tipo de administracin empleada es escaso y la funcin de los sistemas

suele ser manejada por un administrador que no posee una preparacin
formal en el rea de computacin.

El personal que labora en este pequeo departamento consta a lo sumo de

un operador y/o un programador. Este ltimo podr estar bajo el rgimen de
honorarios, o bien, puede recibirse el soporte de algn fabricante local de
programas de aplicacin.

En esta etapa es importante estar consciente de la resistencia al cambio del

personal y usuario (ciberfobia) que estn involucrados en los primeros
sistemas que se desarrollan, ya que estos sistemas son importantes en el
ahorro de mano de obra.

Esta etapa termina con la implantacin exitosa del primer Sistema de

Informacin. Cabe recalcar que algunas organizaciones pueden vivir varias
etapas de inicio en las que la resistencia al cambio por parte de los
primeros usuarios involucrados aborta el intento de introducir la
computadora a la empresa.
23

Etapa de contagio o expansin. Los aspectos sobresalientes que permiten

diagnosticar rpido que una empresa se encuentra en esta etapa son:

Se inicia con la implantacin exitosa del primer Sistema de Informacin en

la organizacin. Como consecuencia de lo anterior, el primer ejecutivo
usuario se transforma en el paradigma o persona que se habr que imitar.

Las aplicaciones que con frecuencia se implantan en esta etapa son el

resto de los Sistemas Transaccionales no desarrollados en la etapa de
inicio, tales como facturacin, inventarios, control de pedidos de clientes y
proveedores, cheques, etc.

El pequeo departamento es promovido a una categora superior, donde

depende de la Gerencia Administrativa o Contralora.

El tipo de administracin empleado est orientado hacia la venta de

aplicaciones a todos los usuarios de la organizacin; en este punto suele
contratarse a un especialista de la funcin con preparacin acadmica en el
rea de sistemas.

Se inicia la contratacin de personal especializado y nacen puestos tales

como analista de sistemas, analista-programador, programador de
sistemas, jefe de desarrollo, jefe de soporte tcnico, etc.

Las aplicaciones desarrolladas carecen de interfaces automticas entre

ellas, de tal forma que las salidas que produce un sistema se tienen que
alimentar en forma manual a otro sistema, con la consecuente irritacin de
los usuarios.

Los gastos por concepto de sistemas empiezan a crecer en forma

importante, lo que marca la pauta para iniciar la racionalizacin en el uso de
los recursos computacionales dentro de la empresa. Este problema y el
inicio de su solucin marcan el paso a la siguiente etapa.

24

Etapa de control o formalizacin. Para identificar a una empresa que transita por
esta etapa es necesario considerar los siguientes elementos:

Esta etapa de evolucin de la Informtica dentro de las empresas se inicia

con la necesidad de controlar el uso de los recursos computacionales a
travs de las tcnicas de presupuestacin base cero (partiendo de que no
se tienen nada) y la implantacin de sistemas de cargos a usuarios (por el
servicio que se presta).

Las aplicaciones estn orientadas a facilitar el control de las operaciones

del negocio para hacerlas ms eficaces, tales como sistemas para control
de flujo de fondos, control de rdenes de compra a proveedores, control de
inventarios, control y manejo de proyectos, etc.

El departamento de sistemas de la empresa suele ubicarse en una posicin

gerencial, dependiendo del organigrama de la Direccin de Administracin
o Finanzas.

El tipo de administracin empleado dentro del rea de Informtica se

orienta al control administrativo y a la justificacin econmica de las
aplicaciones a desarrollar. Nace la necesidad de establecer criterios para
las prioridades en el desarrollo de nuevas aplicaciones. La cartera de
aplicaciones pendientes por desarrollar empieza a crecer.

En esta etapa se inician el desarrollo y la implantacin de estndares de

trabajo

dentro

del

departamento,

tales

como:

estndares

de

documentacin, control de proyectos, desarrollo y diseo de sistemas,

auditora de sistemas y programacin.

Se integra a la organizacin del departamento de sistemas, personal con

habilidades administrativas y preparado tcnicamente.

Se inicia el desarrollo de interfaces automticas entre los diferentes

sistemas.

25

Etapa de integracin. Las caractersticas de esta etapa son las siguientes:

La integracin de los datos y de los sistemas surge como un resultado

directo de la centralizacin del departamento de sistemas bajo una sola
estructura administrativa.

Las nuevas tecnologas relacionadas con base de datos, sistemas

administradores de bases de datos y lenguajes de cuarta generacin,
hicieron posible la integracin.

En esta etapa surge la primera hoja electrnica de clculo comercial y los

usuarios inician haciendo sus propias aplicaciones. Esta herramienta ayud
mucho a que los usuarios hicieran su propio trabajo y no tuvieran que
esperar a que sus propuestas de sistemas fueran cumplidas.

El costo del equipo y del software disminuy por lo cual estuvo al alcance
de ms usuarios.

En forma paralela a los cambios tecnolgicos, cambi el rol del usuario y

del departamento de Sistemas de Informacin. El departamento de
sistemas evolucion hacia una estructura descentralizada, permitiendo al
usuario utilizar herramientas para el desarrollo de sistemas.

Los usuarios y el departamento de sistema iniciaron el desarrollo de nuevos

sistemas, reemplazando los sistemas antiguos, en beneficio de la
organizacin.

Etapa de administracin de datos. Entre las caractersticas que destacan en esta

etapa estn las siguientes:

El departamento de Sistemas de Informacin reconoce que la informacin

es un recurso muy valioso que debe estar accesible para todos los
usuarios.

26

Para poder cumplir con lo anterior resulta necesario administrar los datos
en forma apropiada, es decir, almacenarlos y mantenerlos en forma
adecuada para que los usuarios puedan utilizar y compartir este recurso.

El usuario de la informacin adquiere la responsabilidad de la integridad de

la misma y debe manejar niveles de acceso diferentes.

Etapa de madurez. Entre los aspectos sobresalientes que indican que una
empresa se encuentra en esta etapa, se incluyen los siguientes:

Al llegar a esta etapa, la Informtica dentro de la organizacin se encuentra

definida como una funcin bsica y se ubica en los primeros niveles del
organigrama (direccin).

Los sistemas que se desarrollan son Sistemas de Manufactura Integrados

por Computadora, Sistemas Basados en el Conocimiento y Sistemas
Expertos, Sistemas de Soporte a las Decisiones, Sistemas Estratgicos y,
en general, aplicaciones que proporcionan informacin para las decisiones
de alta administracin y aplicaciones de carcter estratgico.

En esta etapa se tienen las aplicaciones desarrolladas en la tecnologa de

base de datos y se logra la integracin de redes de comunicaciones con
terminales

en

lugares

remotos,

travs

del

uso

de

recursos

computacionales.

2.2.2 Metodologa de desarrollo

2.2.2.1 Ciclo de vida
El ciclo de vida de un sistema de informacin es un enfoque por fases del
anlisis y diseo que sostiene que los sistemas son desarrollados de mejor

27

manera mediante el uso de un ciclo especifico de actividades del analista y del

usuario.
Segn James Senn, existen tres estrategias para el desarrollo de sistemas: el
mtodo clsico del ciclo de vida de desarrollo de sistemas, el mtodo de desarrollo
por anlisis estructurado y el mtodo de construccin de prototipos de sistemas.
Cada una de estas estrategias tiene un uso amplio en cada una de los diversos
tipos de empresas que existen, y resultan efectivas si son aplicadas de manera
adecuada. (Senn, 1992)
El mtodo de ciclo de vida para el desarrollo de sistemas es el conjunto de
actividades que los analistas, diseadores y usuarios realizan para desarrollar e
implantar un sistema de informacin. El mtodo del ciclo de vida para el desarrollo
de sistemas consta de 6 fases:
1. Investigacin Preliminar: La solicitud para recibir ayuda de un sistema
de informacin puede originarse por varias razones: sin importar cuales
sean estas, el proceso se inicia siempre con la peticin de una persona.
2. Determinacin de los requerimientos del sistema: El aspecto
fundamental del anlisis de sistemas es comprender todas las facetas
importantes de la parte de la empresa que se encuentra bajo estudio. Los
analistas, al trabajar con los empleados y administradores, deben estudiar
los procesos de una empresa para dar respuesta a las siguientes preguntas
clave:
Qu es lo que hace?
Cmo se hace?
Con que frecuencia se presenta?
Qu tan grande es el volumen de transacciones o decisiones?
Cul es el grado de eficiencia con el que se efectan las tareas?

28

Existe algn problema? Qu tan serio es? Cul es la causa que lo

origina?
3. Diseo del sistema: El diseo de un sistema de informacin produce los
que establecen la forma en la que el sistema cumplir con los
requerimientos identificados durante la fase de anlisis. Los especialistas
en sistemas se refieren, con frecuencia, a esta etapa como diseo lgico en
contraste con la del desarrollo del software, a la que denominan diseo
fsico.
4. Desarrollo del software: Los encargados de desarrollar software
pueden instalar software comprobando a terceros o escribir programas
diseados a la medida del solicitante. La eleccin depende del costo de
cada alternativa, del tiempo disponible para escribir el software y de la
disponibilidad de los programadores.
Por lo general, los programadores que trabajan en las grandes
organizaciones pertenecen a un grupo permanente de profesionales.
5. Prueba de sistemas: Durante la prueba de sistemas, el sistema se
emplea de manera experimental para asegurarse de que el software no
tenga fallas, es decir, que funciona de acuerdo con las especificaciones y
en la forma en que los usuarios esperan que lo haga.
Se alimentan como entradas conjunto de datos de prueba para su
procesamiento y despus se examinan los resultados.
6. Implantacin y evaluacin: La implantacin es el proceso de verificar e
instalar nuevo equipo, entrenar a los usuarios, instalar la aplicacin y
construir todos los archivos de datos necesarios para utilizarla. Una vez
instaladas, las aplicaciones se emplean durante muchos aos. Sin
embargo, las organizaciones y los usuarios cambian con el paso del tiempo,
incluso el ambiente es diferente con el paso de las semanas y los meses.
(Senn, 1992)
29

2.2.2.2 Modelo de prototipos

Este modelo consiste en un procedimiento que permite al equipo de
desarrollo disear y analizar una aplicacin que representa el sistema que ser
implementado. Dicha aplicacin, llamada prototipo, est compuesta por los
componentes que se desean evaluar (las funciones principales) y una de sus
principales caractersticas es que su desarrollo es iterativo e incremental, es decir
que se le van haciendo mejoras continuamente, caracterstica que comparte con
las metodologas giles por ello este modelo es su precedente. Las etapas del
modelo son:
- Investigacin preliminar.
- Colecta y refinamiento de los requerimientos y proyecto rpido:
- Anlisis y especificacin del prototipo.
- Diseo y construccin del prototipo.
- Evaluacin del prototipo por el cliente.
- Renacimiento del prototipo.
- Diseo tcnico
- Programacin y pruebas
- Operacin y mantenimiento

Se inicia con la definicin de los objetivos globales para el software, luego se

identifican los requisitos conocidos y las reas del esquema en donde es
necesaria ms definicin.
Entonces se plantea con rapidez una iteracin de construccin de prototipos y se
presenta el modelado (en forma de un diseo rpido).

30

El diseo rpido se centra en una representacin de aquellos aspectos del

software que sern visibles para el cliente o el usuario final (por ejemplo, la
configuracin de la interfaz con el usuario y el formato de los despliegues de
salida). El diseo rpido conduce a la construccin de un prototipo, el cual es
evaluado por el cliente o el usuario para una retroalimentacin; gracias a sta se
refinan los requisitos del software que se desarrollar. La iteracin ocurre cuando
el prototipo se ajusta para satisfacer las necesidades del cliente. Esto permite que
al mismo tiempo el desarrollador entienda mejor lo que se debe hacer y el cliente
vea resultados a corto plazo.
Ventajas:

Este modelo es til cuando el cliente conoce los objetivos generales para el
software, pero no identifica los requisitos detallados de entrada,
procesamiento o salida.

Tambin ofrece un mejor enfoque cuando el responsable del desarrollo del

software est inseguro de la eficacia de un algoritmo, de la adaptabilidad de
un sistema operativo o de la forma que debera tomar la interaccin
humano-mquina.

La construccin de prototipos se puede utilizar como un modelo del proceso

independiente, se emplea ms comnmente como una tcnica susceptible de
implementarse dentro del contexto de cualquiera de los modelos del proceso
expuestos. Sin importar la forma en que ste se aplique, el paradigma de
construccin de prototipos ayuda al desarrollador de software y al cliente a
entender de mejor manera cul ser el resultado de la construccin cuando los
requisitos estn satisfechos. De esta manera, este ciclo de vida en particular,
involucra al cliente ms profundamente para adquirir el producto.

31

Desventajas:

El usuario tiende a crearse unas expectativas cuando ve el prototipo de

cara al sistema final. A causa de la intencin de crear un prototipo de forma
rpida, se suelen desatender aspectos importantes, tales como la calidad y
el mantenimiento a largo plazo, lo que obliga en la mayor parte de los casos
a reconstruirlo una vez que el prototipo ha cumplido su funcin. Es
frecuente que el usuario se muestre reacio a ello y pida que sobre ese
prototipo se construya el sistema final, lo que lo convertira en un prototipo
evolutivo, pero partiendo de un estado poco recomendado.

En aras de desarrollar rpidamente el prototipo, el desarrollador suele

tomar algunas decisiones de implementacin poco convenientes (por
ejemplo, elegir un lenguaje de programacin incorrecto porque proporcione
un desarrollo ms rpido). Con el paso del tiempo, el desarrollador puede
olvidarse de la razn que le llev a tomar tales decisiones, con lo que se
corre el riesgo de que dichas elecciones pasen a formar parte del sistema
final, porque es muy difcil y complejo realizarlo.

Para concluir:
A pesar de que tal vez surjan problemas, la construccin de prototipos puede ser
un paradigma efectivo para la ingeniera del software. La clave es definir las reglas
del juego desde el principio; es decir, el cliente y el desarrollador se deben poner
de acuerdo en:

Que el prototipo se construya y sirva como un mecanismo para la definicin

de requisitos.

Que el prototipo se descarte, al menos en parte.

Que despus se desarrolle el software real con un enfoque hacia la calidad.

32

2.2.2.3 Metodologas giles

Se entiende como Desarrollo gil de software a un paradigma de Desarrollo de
Software basado en procesos giles. Los procesos giles de desarrollo de
software, conocidos anteriormente como metodologas livianas, intentan evitar los
tortuosos y burocrticos caminos de las metodologas tradicionales enfocndose
en la gente y los resultados.
Existen muchos mtodos de desarrollo gil; la mayora minimiza riesgos
desarrollando software en cortos lapsos de tiempo. El software desarrollado en
una unidad de tiempo es llamado una iteracin, la cual debe durar de una a cuatro
semanas. Cada iteracin del ciclo de vida incluye: planificacin, anlisis de
requerimientos, diseo, codificacin, revisin y documentacin. Una iteracin no
debe agregar demasiada funcionalidad para justificar el lanzamiento del producto
al mercado, pero la meta es tener un demo (sin errores) al final de cada iteracin.
Al final de cada iteracin el equipo vuelve a evaluar las prioridades del proyecto.
Los mtodos giles enfatizan las comunicaciones cara a cara en vez de la
documentacin. La mayora de los equipos giles estn localizados en una simple
oficina abierta, a veces llamadas "plataformas de lanzamiento" (bullpen en ingls).
La oficina debe incluir revisores, diseadores de iteracin, escritores de
documentacin y ayuda y directores de proyecto. Los mtodos giles tambin
enfatizan que el software funcional es la primera medida del progreso. Combinado
con la preferencia por las comunicaciones cara a cara, generalmente los mtodos
giles son criticados y tratados como "indisciplinados" por la falta de
documentacin tcnica.

2.2.2.4 Programacin extrema

La programacin extrema o eXtreme Programming (XP) es un enfoque de la
ingeniera de software formulado por Kent Beck, autor del primer libro sobre la
materia, Extreme Programming Explained: Embrace Change (1999). Es el ms
33

destacado de los procesos giles de desarrollo de software. Al igual que stos, la

programacin

extrema

se

diferencia

de

las

metodologas

tradicionales

principalmente en que pone ms nfasis en la adaptabilidad que en la

previsibilidad. Los defensores de XP consideran que los cambios de requisitos
sobre la marcha son un aspecto natural, inevitable e incluso deseable del
desarrollo de proyectos. Creen que ser capaz de adaptarse a los cambios de
requisitos en cualquier punto de la vida del proyecto es una aproximacin mejor y
ms realista que intentar definir todos los requisitos al comienzo del proyecto e
invertir esfuerzos despus en controlar los cambios en los requisitos.
Se puede considerar la programacin extrema como la adopcin de las mejores
metodologas de desarrollo de acuerdo a lo que se pretende llevar a cabo con el
proyecto, y aplicarlo de manera dinmica durante el ciclo de vida del software.
Los principios originales

de la programacin extrema son: simplicidad,

comunicacin, retroalimentacin (feedback) y coraje. Un quinto principio, respeto,

fue aadido en la segunda edicin de Extreme Programming Explained. Los cinco
principios se detallan a continuacin:

Simplicidad: La simplicidad es la base de la programacin extrema. Se

simplifica el diseo para agilizar el desarrollo y facilitar el mantenimiento. Un
diseo complejo del cdigo junto a sucesivas modificaciones por parte de
diferentes

desarrolladores

exponencialmente.

Para

hacen

mantener

que
la

la

complejidad

simplicidad

es

aumente

necesaria

la

refactorizacin del cdigo, sta es la manera de mantener el cdigo simple

a medida que crece. Tambin se aplica la simplicidad en la documentacin,
de esta manera el cdigo debe comentarse en su justa medida, intentando
eso s que el cdigo est autodocumentado. Para ello se deben elegir
adecuadamente los nombres de las variables, mtodos y clases. Los
nombres largos no decrementan la eficiencia del cdigo ni el tiempo de
desarrollo gracias a las herramientas de autocompletado y refactorizacin
que existen actualmente. Aplicando la simplicidad junto con la autora
colectiva del cdigo y la programacin por parejas se asegura que cuanto
34

ms grande se haga el proyecto, todo el equipo conocer ms y mejor el

sistema completo.

Comunicacin: La comunicacin se realiza de diferentes formas. Para los

programadores el cdigo comunica mejor cuanto ms simple sea. Si el
cdigo es complejo hay que esforzarse para hacerlo inteligible. El cdigo
autodocumentado es ms fiable que los comentarios ya que stos ltimos
pronto quedan desfasados con el cdigo a medida que es modificado. Debe
comentarse slo aquello que no va a variar, por ejemplo el objetivo de una
clase o la funcionalidad de un mtodo. Las pruebas unitarias son otra forma
de comunicacin ya que describen el diseo de las clases y los mtodos al
mostrar ejemplos concretos de cmo utilizar su funcionalidad. Los
programadores se comunican constantemente gracias a la programacin
por parejas. La comunicacin con el cliente es fluida ya que el cliente forma
parte del equipo de desarrollo. El cliente decide que caractersticas tienen
prioridad y siempre debe estar disponible para solucionar dudas.

Retroalimentacin (feedback): Al estar el cliente integrado en el proyecto,

su opinin sobre el estado del proyecto se conoce en tiempo real. Al
realizarse ciclos muy cortos tras los cuales se muestran resultados, se
minimiza el tener que rehacer partes que no cumplen con los requisitos y
ayuda a los programadores a centrarse en lo que es ms importante.
Considrense los problemas que derivan de tener ciclos muy largos. Meses
de trabajo pueden tirarse por la borda debido a cambios en los criterios del
cliente o malentendidos por parte del equipo de desarrollo. El cdigo
tambin es una fuente de retroalimentacin gracias a las herramientas de
desarrollo. Por ejemplo, las pruebas unitarias informan sobre el estado de
salud del cdigo. Ejecutar las pruebas unitarias frecuentemente permite
descubrir fallos debidos a cambios recientes en el cdigo.

Coraje o valenta: Los puntos anteriores parecen tener sentido comn,

entonces, por qu coraje?. Para los gerentes la programacin en parejas
puede ser difcil de aceptar, porque les parece como si la productividad se
35

fuese a reducir a la mitad ya que solo la mitad de los programadores est

escribiendo cdigo. Hay que ser valiente para confiar en que la
programacin por parejas beneficia la calidad del cdigo sin repercutir
negativamente en la productividad. La simplicidad es uno de los principios
ms difciles de adoptar. Se requiere coraje para implementar las
caractersticas que el cliente quiere ahora sin caer en la tentacin de optar
por un enfoque ms flexible que permita futuras modificaciones. No se debe
emprender el desarrollo de grandes marcos de trabajo (frameworks)
mientras el cliente espera. En ese tiempo el cliente no recibe noticias sobre
los

avances

del

proyecto

el

equipo

de

desarrollo

no

recibe

retroalimentacin para saber si va en la direccin correcta. La forma de

construir marcos de trabajo es mediante la refactorizacin del cdigo en
sucesivas aproximaciones.

Respeto: El respeto se manifiesta de varias formas. Los miembros del

equipo se respetan los unos a otros, porque los programadores no pueden
realizar cambios que hacen que las pruebas existentes fallen o que demore
el trabajo de sus compaeros. Los miembros se respetan su trabajo porque
siempre estn luchando por la alta calidad en el producto y buscando el
diseo ptimo o ms eficiente para la solucin a travs de la refactorizacin
del cdigo.

Las caractersticas fundamentales del mtodo son:

Desarrollo iterativo e incremental: pequeas mejoras, unas tras otras.

Pruebas unitarias continuas: frecuentemente repetidas y automatizadas,

incluyendo pruebas de regresin. Se aconseja escribir el cdigo de la
prueba antes de la codificacin. Vase, 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.

Programacin en parejas: se recomienda que las tareas de desarrollo se

lleven a cabo por dos personas en un mismo puesto. Se supone que la
36

mayor calidad del cdigo escrito de esta manera -el cdigo es revisado y
discutido mientras se escribe- es ms importante que la posible prdida de
productividad inmediata.

Frecuente integracin del equipo de programacin con el cliente o

usuario. Se recomienda que un representante del cliente trabaje junto al
equipo de desarrollo.

Correccin de todos los errores antes de aadir nueva funcionalidad.

Hacer entregas frecuentes.

Refactorizacin del cdigo, es decir, reescribir ciertas partes del cdigo

para aumentar su legibilidad y mantenibilidad pero sin modificar su
comportamiento. Las pruebas han de garantizar que en la refactorizacin
no se ha introducido ningn fallo.

Propiedad del cdigo compartida: en vez de dividir la responsabilidad en

el desarrollo de cada mdulo en grupos de trabajo distintos, este mtodo
promueve el que todo el personal pueda corregir y extender cualquier parte
del proyecto. Las frecuentes pruebas de regresin garantizan que los
posibles errores sern detectados.

Simplicidad en el cdigo: es la mejor manera de que las cosas funcionen.

Cuando todo funcione se podr aadir funcionalidad si es necesario. La
programacin extrema apuesta que es ms sencillo hacer algo simple y
tener un poco de trabajo extra para cambiarlo si se requiere, que realizar
algo complicado y quizs nunca utilizarlo.

La simplicidad y la comunicacin son extraordinariamente complementarias. Con

ms comunicacin resulta ms fcil identificar qu se debe y qu no se debe
hacer. Cuanto ms simple es el sistema, menos tendr que comunicar sobre ste,
lo que lleva a una comunicacin ms completa, especialmente si se puede reducir
el equipo de programadores.

37

2.2.2.5 SCRUM
Scrum es un modelo de referencia que define un conjunto de prcticas y roles, y
que puede tomarse como punto de partida para definir el proceso de desarrollo
que se ejecutar durante un proyecto. Los roles principales en Scrum son el
ScrumMaster, que mantiene los procesos y trabaja de forma similar al Director de
proyecto, el ProductOwner, que representa a los stakeholders (clientes externos o
internos), y el Team que incluye a los desarrolladores.
Durante cada sprint, un periodo entre 15 y 30 das (la magnitud es definida por el
equipo), el equipo crea un incremento de software potencialmente entregable
(utilizable). El conjunto de caractersticas que forma parte de cada sprint viene del
Product Backlog, que es un conjunto de requisitos de alto nivel priorizados que
definen el trabajo a realizar. Los elementos del Product Backlog que forman parte
del sprint se determinan durante la reunin de Sprint Planning. Durante esta
reunin, el Product Owner identifica los elementos del Product Backlog que quiere
ver completados y los hace del conocimiento del equipo. Entonces, el equipo
determina la cantidad de ese trabajo que puede comprometerse a completar
durante el siguiente sprint. Durante el sprint, nadie puede cambiar el Sprint
Backlog, lo que significa que los requisitos estn congelados durante el sprint.
Existen varias implementaciones de sistemas para gestionar el proceso de Scrum,
que van desde notas amarillas "post-it" y pizarras hasta paquetes de software.
Una de las mayores ventajas de Scrum es que es muy fcil de aprender, y
requiere muy poco esfuerzo para comenzarse a utilizar. (Schwaber, 2006)
En Scrum se definen varios roles, estos estn divididos en dos grupos: cerdos y
gallinas. Los nombres de los grupos estn inspirados en el chiste sobre un cerdo y
una gallina que se relata a continuacin.
Un cerdo y una gallina se encuentran en la calle. La gallina mira al cerdo y dice:
"Hey, por qu no abrimos un restaurante?" El cerdo mira a la gallina y le dice:
"Buena idea, cmo se llamara el restaurante?" La gallina piensa un poco y

38

contesta: "Por qu no lo llamamos "Huevos con jamn?" "Lo siento pero no", dice
el cerdo, "Yo estara comprometido pero t solamente estaras involucrada".
De esta forma, los cerdos estn comprometidos a construir software de manera
regular y frecuente, mientras que el resto son gallinas: interesados en el proyecto
pero realmente irrelevantes porque, si ste falla, no son un cerdo, es decir, no son
los que se haban comprometido a sacarlo adelante. Las necesidades, deseos,
ideas e influencias de los roles gallina se tienen en cuenta, pero no de forma que
pueda afectar, distorsionar o entorpecer el proyecto Scrum.
Los Cerdos son los que estn comprometidos con el proyecto y el proceso Scrum;
ellos son los que "ponen el jamn en el plato".
El Product Owner representa la voz del cliente. Se asegura de que el equipo
Scrum trabaja de forma adecuada desde la perspectiva del negocio. El Product
Owner escribe historias de usuario, las prioriza, y las coloca en el Product
Backlog.
El Scrum es facilitado por un ScrumMaster, cuyo trabajo primario es eliminar los
obstculos que impiden que el equipo alcance el objetivo del sprint. El
ScrumMaster no es el lder del equipo (porque ellos se auto-organizan), sino que
acta como una proteccin entre el equipo y cualquier influencia que le distraiga.
El ScrumMaster se asegura de que el proceso Scrum se utiliza como es debido. El
ScrumMaster es el que hace que las reglas se cumplan. (Schwaber, 2006)
El equipo tiene la responsabilidad de entregar el producto. Un pequeo equipo de
5 a 9 personas con las habilidades transversales necesarias para realizar el
trabajo (diseador, desarrollador, etc).
Los roles gallina en realidad no son parte del proceso Scrum, pero deben tenerse
en cuenta. Un aspecto importante de una aproximacin gil es la prctica de
involucrar en el proceso a los usuarios, expertos del negocio y otros interesados
(stakeholders). Es importante que esa gente participe y entregue retroalimentacin
con respecto a la salida del proceso a fin de revisar y planear de cada sprint.
39

Stakeholders (Clientes, Proveedores), se refiere a la gente que hace posible el

proyecto y para quienes el proyecto producir el beneficio acordado que lo
justifica. Slo participan directamente durante las revisiones del sprint.
Managers, es la gente que establece el ambiente para el desarrollo del producto.
Reuniones en SCRUM
Cada da de un sprint, se realiza la reunin sobre el estado de un proyecto. Esto
se llama "daily standup". El scrum tiene unas guas especficas:

La reunin comienza puntualmente a su hora. A menudo hay castigos decididos por el equipo- para quin llega tarde (por ejemplo: dinero,
flexiones, llevar colgando una gallina de plstico del cuello)

Todos son bienvenidos, pero solo los "cerdos" pueden hablar

La reunin tiene una duracin fija de 15 minutos, de forma independiente

del tamao del equipo.

Todos los asistentes deben mantenerse de pie (esto ayuda a mantener la

reunin corta)

La reunin debe ocurrir en la misma ubicacin y a la misma hora todos los

das.

Durante la reunin, cada miembro del equipo contesta a tres preguntas:

Qu has hecho desde ayer?

Qu es lo que ests planeando hacer hoy?

Has tenido algn problema que te haya impedido alcanzar tu objetivo? (Es
el papel del ScrumMaster recordar estos impedimentos).

40

Despus de cada sprint, se lleva a cabo una retrospectiva del sprint, en la cual
todos los miembros del equipo dejan sus impresiones sobre el sprint recin
superado. El propsito de la retrospectiva es realizar una mejora continua del
proceso. Esta reunin tiene un tiempo fijo de cuatro horas.
Scrum permite la creacin de equipos auto-organizados impulsando la colocalizacin de todos los miembros del equipo, y la comunicacin verbal entre
todos los miembros y disciplinas involucrados en el proyecto.
Un principio clave de Scrum es el reconocimiento de que durante un proyecto los
clientes pueden cambiar de idea sobre lo que quieren y necesitan (a menudo
llamado requirements churn), y que los desafos impredecibles no pueden ser
fcilmente enfrentados de una forma predictiva y planificada. Por lo tanto, Scrum
adopta una aproximacin pragmtica, aceptando que el problema no puede ser
completamente entendido o definido, y centrndose en maximizar la capacidad del
equipo de entregar rpidamente y responder a requisitos emergentes. (Schwaber,
2006)

2.2.2.6 Desarrollo Rpido de Aplicaciones (RAD)

Se trata de un proceso de desarrollo de software que permite construir sistemas
utilizables en poco tiempo, normalmente de 60 a 90 das, frecuentemente con
algunas concesiones. Ver figura 2.3

41

SISTEMADEAPOYOALA
TOMADEDECISIONES

Necesidad

Planeacin

Anlisis

Diseo

Implementacin

Prototipo
PROTOTIPOMAL
PROTOTIPOBIEN
Implementacin

Sistema

Figura 2.3 Proceso de desarrollo de prototipos: mtodo para un rpido desarrollo

de aplicaciones (RAD). (Turban, 2005)

En ciertas situaciones:

Una solucin utilizable al 80% puede producirse en el 20% de tiempo que

se hubiera requerido para la solucin completa.

Los requisitos de negocio de un sistema pueden satisfacerse aun cuando

algunos de sus requisitos operacionales no se satisfagan.

La aceptabilidad de un sistema puede determinarse en base a un conjunto

mnimo de requisitos consensados en lugar de la totalidad de los requisitos.

42

Este mtodo atiende los siguientes problemas:

Con los mtodos convencionales pasa un gran lapso de tiempo antes de

que el cliente vea resultados.

Con los mtodos convencionales el desarrollo llega a tardar tanto que para
cuando el sistema est listo para utilizarse los procesos del cliente han
cambiado radicalmente.

Con los mtodos convencionales no hay nada hasta que el 100% del
proceso de desarrollo se ha realizado, entonces se entrega el 100% del
software.

Por qu utilizar RAD?

Malas razones

Prevenir presupuestos rebasados (RAD necesita un equipo disciplinado en

manejo de costos).

Prevenir incumplimiento de fechas (RAD necesita un equipo disciplinado en

manejo de tiempo).

Buenas razones

Convergir tempranamente en un diseo aceptable para el cliente y posible

para los desarrolladores.

Limitar la exposicin del proyecto a las fuerzas de cambio.

Ahorrar tiempo de desarrollo, posiblemente a expensas de dinero o de

calidad del trabajo.

Las concesiones determinan el ritmo de desarrollo, los cuales pueden ser:

Desarrollo eficiente: equilibra calendario, presupuesto y calidad.

43

Calendario: ms rpido que el promedio

Presupuesto: cuesta menos que el promedio

Calidad: mejor calidad que el promedio

RAD razonable: inclina la balanza hacia el tiempo ms corto.

o

Calendario: mucho ms rpido que el promedio

Presupuesto: cuesta poco menos que el promedio

Calidad: calidad poco mejor que el promedio

RAD a fondo: "programar a lo bestia".

o

Calendario: ms corto posible

Presupuesto: cuesta ms que el promedio

Calidad: menor calidad que el promedio

RAD tiene una buena posibilidad de xito si el cliente est dispuesto a negociar
precio o calidad. Una mejor posibilidad de xito si el cliente est dispuesto a
negociar precio y calidad. La calidad no significa una mayor tasa de fallas sino un
producto con menos funciones o menos eficiente.
Cuando se utiliza principalmente para aplicaciones de sistemas de informacin, el
enfoque DRA comprende las siguientes fases:

Modelado de gestin: el flujo de informacin entre las funciones de

gestin se modela de forma que responda a las siguientes preguntas: Qu
informacin conduce el proceso de gestin? Qu informacin se genera?
Quin la genera? A dnde va la informacin? Quin la proceso?

Modelado de datos: el flujo de informacin definido como parte de la fase

de modelado de gestin se refina como un conjunto de objetos de datos
44

necesarios para apoyar la empresa. Se definen las caractersticas

(llamadas atributos) de cada uno de los objetos y las relaciones entre estos
objetos.

Modelado de proceso: los objetos de datos definidos en la fase de

modelado de datos quedan transformados para lograr el flujo de
informacin necesario para implementar una funcin de gestin. Las
descripciones del proceso se crean para aadir, modificar, suprimir, o
recuperar un objeto de datos. Es la comunicacin entre los objetos.

Generacin de aplicaciones: El DRA asume la utilizacin de tcnicas de

cuarta generacin. En lugar de crear software con lenguajes de
programacin de tercera generacin, el proceso DRA trabaja para volver a
utilizar componentes de programas ya existentes (cuando es posible) o a
crear componentes reutilizables (cuando sea necesario). En todos los casos
se utilizan herramientas automticas para facilitar la construccin del
software.

Pruebas de entrega: Como el proceso DRA enfatiza la reutilizacin, ya se

han comprobado muchos de los componentes de los programas. Esto
reduce tiempo de pruebas. Sin embargo, se deben probar todos los
componentes nuevos y se deben ejercitar todas las interfaces a fondo.

Obviamente la limitacin de tiempo impuesta en un proyecto DRA demanda

"mbito en escalas". Si una aplicacin de gestin puede modularse se forma que
permita completarse cada una de las funciones principales en menos de tres
meses (utilizando el enfoque descrito anteriormente), es un candidato del DRA.
Cada una de las funciones pueden ser afrontadas por un equipo DRA diferente y
ser integradas en un solo conjunto.

45

Al igual que todos los modelos de proceso, el enfoque DRA tiene inconvenientes:

Para proyectos grandes aunque por escalas, el DRA requiere recursos

humanos suficientes como para crear el nmero correcto de equipos DRA.

DRA requiere clientes y desarrolladores comprometidos en las rpidas

actividades necesarias para completar un sistema en un marco de tiempo
abreviado. Si no hay compromiso, por ninguna de las partes constituyentes,
los proyectos DRA fracasaran.

No todos los tipos de aplicaciones son apropiados para DRA. Si un sistema no se

puede modulizar adecuadamente. La construccin de los componentes necesarios
para DRA ser problemtico. Si est en juego el alto rendimiento, y se va a
conseguir el rendimiento convirtiendo interfaces en componentes de sistema, el
enfoque DRA puede que no funcione. DRA no es adecuado cuando los riesgos
tcnicos son altos. Esto ocurre cuando una nueva aplicacin hace uso de
tecnologas nuevas, o cuando el nuevo software requiere un alto grado de
interoperabilidad con programas de computadora ya existentes.
En resumen, con el fin de asegurar gran interaccin, los proyectos se disean con
calendarios fijos y se sacrifica la funcionalidad si es necesario. Esto permite que el
equipo de desarrollo se enfoque en las piezas de funcionalidad que tienen el
mayor valor de negocio y en entregar dicha funcionalidad rpidamente. Los
cambios son frecuentemente la razn de los retrasos en el desarrollo de una
aplicacin. En los largos procesos lineales de desarrollo, los cambios en los
requisitos funcionales o en el alcance del proyecto, particularmente cuando gran
cantidad de tiempo se ha invertido en la planeacin, diseo, desarrollo y pruebas,
provocan que se pierdan meses de trabajo y se incurra en grandes gastos por
rediseo y redesarrollo. RAD ataca la infiltracin de cambios de alcance y
requisitos al limitar la exposicin del proyecto al cambio, acortando el ciclo de
desarrollo y limitando el costo de los cambios al incorporarlos desde el inicio,
antes de que grandes inversiones se hayan hecho en desarrollo y pruebas.

46

Por todas las ventajas que esta metodologa gil brinda y debido a las
circunstancias de tiempo y recursos con los que cuentan los desarrolladores del
proyecto, el mtodo de desarrollo rpido de aplicaciones, es el ms recomendable
para llevar a cabo el desarrollo del sistema de apoyo a la toma de decisiones para
asignacin de sinodales en la Facultad de Contadura y Administracin.
En la tabla 2.1 se muestran los procedimientos para el desarrollo del sistema de
apoyo a la toma de decisiones.

Fases
1

Etapa
Anlisis

Procedimiento
Anlisis de la organizacin
Factibilidad del sistema
Requerimientos
Modelado conceptual

Diseo

Modelado lgico
Modelado fsico
Diccionario de datos

Implementacin

Creacin de la base de datos

Configuracin de requerimientos
Codificar mdulo de alumno
Codificar

mdulo

de

coordinacin

de

experiencia recepcional
Documentar
Entrega
prototipo

del

primer Caso de uso: alumno

Caso de uso: coordinacin de experiencia
recepcional
Obtencin de resultados
Conclusiones
47

Aplicar mtricas
Evaluar pruebas

Tabla 2.1 Procedimientos por etapa para el desarrollo de sistemas de apoyo a la

toma de decisiones.

2.2.3 Toma de decisiones

La toma de decisiones es el proceso mediante el cual se realiza una
eleccin entre las alternativas o formas para resolver diferentes situaciones de la
vida, estas se pueden presentar en diferentes contextos: a nivel laboral, familiar,
sentimental, empresarial, etc., es decir, en todo momento se toman decisiones, la
diferencia entre cada una de estas es el proceso o la forma en la cual se llega a
ellas. La toma de decisiones consiste, bsicamente, en elegir una alternativa entre
las disponibles, a los efectos de resolver un problema actual o potencial, (an
cuando no se evidencie un conflicto latente).

La toma de decisiones a nivel individual es caracterizada por que una persona

haga uso de su razonamiento y pensamiento para elegir una decisin a un
problema que se le presente en la vida; es decir, si una persona tiene un
problema, sta deber ser capaz de resolverlo individualmente a travs de tomar
decisiones con ese especifico motivo. En la toma de decisiones importa la eleccin
de un camino a seguir, por lo que en un estadio anterior deben evaluarse
alternativas de accin. Si estas ltimas no estn presentes, no existir decisin.

Para tomar una decisin, no importa su naturaleza, es necesario conocer,

comprender, analizar un problema, para as poder darle solucin; en algunos
casos por ser tan simples y cotidianos, este proceso se realiza de forma implcita y
se soluciona muy rpidamente, pero existen otros casos en los cuales las
consecuencias de una mala o buena eleccin puede tener repercusiones en la
vida y si es en un contexto laboral en el xito o fracaso de la organizacin, para los
cuales es necesario realizar un proceso ms estructurado que puede dar ms
seguridad e informacin para resolver el problema. Las decisiones nos ataen a
todos ya que gracias a ellas podemos tener una opinin crtica. (Kendall, 2006)

48

2.2.3.1 rboles de decisin

Un rbol de decisin es un modelo de prediccin que expresa, en orden
cronolgico las acciones alternativas viables para el tomado de decisiones y las
opciones que la suerte o el azar determina, es utilizado en el mbito de la
inteligencia artificial, dada una base de datos se construyen diagramas de
construcciones lgicas, muy similares a los sistemas de prediccin basados en
reglas, que sirven para representar y categorizar una serie de condiciones que
ocurren de forma sucesiva, para la resolucin de un problema.
Un rbol de decisin tiene unas entradas las cuales pueden ser un objeto o
una situacin descrita por medio de un conjunto de atributos y a partir de esto
devuelve una respuesta la cual en ltimas es una decisin que es tomada a partir
de las entradas. Los valores que pueden tomar las entradas y las salidas pueden
ser valores discretos o continuos. Se utilizan ms los valores discretos por
simplicidad, cuando se utilizan valores discretos en las funciones de una
aplicacin se denomina clasificacin y cuando se utilizan los continuos se
denomina regresin.
Un rbol de decisin lleva a cabo un test a medida que este se recorre hacia las
hojas para alcanzar as una decisin. El rbol de decisin suele contener nodos
internos, nodos de probabilidad, nodos hojas y arcos. Un nodo interno contiene un
test sobre algn valor de una de las propiedades. Un nodo de probabilidad indica
que debe ocurrir un evento aleatorio de acuerdo a la naturaleza del problema, este
tipo de nodos es redondo, los dems son cuadrados. Un nodo hoja representa el
valor que devolver el rbol de decisin. Y finalmente la ramas brindan los
posibles caminos que se tienen de acuerdo a la decisin tomada.

VENTAJAS DE UN RBOL DE DECISIN

Los rboles de decisin proveen un mtodo efectivo para la toma de decisiones
debido a que:
49

Claramente plantean el problema para que todas las opciones sean

analizadas.
Permiten analizar totalmente las posibles consecuencias de tomar una
decisin.
Proveen un esquema para cuantificar el costo de un resultado y la
probabilidad de que suceda.
Nos ayuda a realizar las mejores decisiones sobre la base de la informacin
existente y de las mejores suposiciones.
Resume los ejemplos de partida, permitiendo la clasificacin de nuevos
casos siempre y cuando no existan modificaciones sustanciales en las
condiciones bajo las cuales se generaron los ejemplos que sirvieron para su
construccin.
Facilita la interpretacin de la decisin adoptada.
Proporciona un alto grado de comprensin del conocimiento utilizado en la
toma de decisiones.
Explica el comportamiento respecto a una determinada tarea de decisin.
Reduce el nmero de variables independientes.
DESVENTAJAS DE UN RBOL DE DECISIN
Una de las desventajas de los rboles de decisin es su dificultad cuando se
presentan muchas alternativas, lo cual es probable que ocurra si se desea que el
modelo se aproxime a la realidad. En este caso el nmero de clculos puede
crecer en forma desproporcionada. El nmero de puntos finales crece rpidamente
en cuanto el nmero de nodos crece. Esto induce al analista a reducir
intencionalmente el nmero de puntos terminales y los estimativos de las
probabilidades son muy escasos y pobres. Por lo tanto el uso de este enfoque
puede dar unos resultados inadecuados.
50

SIMBOLOGA Y ESTRUCTURA
Los arboles de decisin poseen (Tabla 2.2):
Smbolo

Nombre

Descripcin

Ramas

Se representan con lneas

Nodos de decisin

De ellos salen las ramas de decisin

Nodos de incertidumbre

De ellos salen las ramas de los eventos

Tabla 2.2 Simbologa de los rboles de decisin.

Figura 2.4 Estructura de un rbol de decisin.

En un rbol de Decisiones hay nodos y ramas. En la imagen anterior (figura 2.4),
se puede observar que hay lneas rectas que son las ramas, hay cuadrados que
son los nodos o puntos de decisin y crculos que son nodos o puntos de azar.
Las ramas que se extienden de los nodos indican las alternativas que se pueden
tomar, en el caso de nodos de decisin o los diferentes resultados de un evento en
el caso de los nodos de azar. En este ltimo caso cada rama tiene asociada una
probabilidad de ocurrencia. Esta probabilidad es una medida de la posibilidad de
que ese evento ocurra. La suma de las probabilidades de las ramas que parten de
cada nodo del evento es igual a uno. O sea, que se supone que los eventos son
exhaustivos; a los nodos de decisin no se les asigna probabilidades, ya que en
esos puntos quien decide tiene el control y no es un evento aleatorio, sujeto al
azar.
51

La secuencia ptima de decisiones se encuentra comenzando a la derecha y

avanzando hacia el origen del rbol. En cada nodo se debe calcular un VPN (valor
probable neto), esperado. Si el nodo es un evento este VPN se calcula para todas
las ramas que salen de ese nodo. Si el nodo es un punto de decisin el VPN
esperado se calcula para cada una de las ramas y se selecciona el ms elevado.
En cualquiera de los dos casos el VPN esperado se lleva hasta el siguiente
evento multiplicado por la probabilidad asociada a la rama por donde se viaja.
La tcnica de anlisis de decisiones con rboles de decisin consiste en efectuar
clculos en cada nodo de azar para encontrar el valor esperado. Ese valor
reemplaza al nodo de azar y se compara con cada uno de los dems que parten
de un nodo de decisin y se selecciona el mayor. Este valor se asigna el nodo de
decisin correspondiente y se llama valor de posicin del nodo de decisin.

CUNDO SE DETIENE LA CONSTRUCCIN DEL RBOL DE DECISIN?

Las reglas de parada tratan de predecir si merece la pena seguir construyendo el
rbol por la rama actual o no. Lo usual es detener la construccin del rbol de
decisin cuando se ha llegado a un nodo puro, entendiendo por nodo puro aquel
que contiene ejemplos de una nica clase. No obstante, se pueden utilizar otros
criterios de parada adems del anterior. A continuacin se describen dos posibles
reglas:
Pureza del nodo. Cuando un nodo solamente contiene ejemplos de una
clase, obviamente, el proceso de construccin del rbol de decisin ha
finalizado. Sin embargo, tambin puede utilizarse un umbral de pureza para
detener la construccin del rbol de decisin cuando la ramificacin del
rbol no suponga una disminucin significativa de la impureza del mismo
(segn alguna medida estadstica de impureza). En la prctica, esto no
suele resultar totalmente satisfactorio y se puede optar por construir el rbol
de decisin completo para despus realizar una poda a posteriori.

52

Cota de profundidad. Independientemente de la pureza del nodo, se

puede establecer de antemano una cota de profundidad para no construir
rboles excesivamente complejos. Cuando un nodo se halle a ms de cierta
profundidad, se detiene el proceso de generacin del rbol.

Estas reglas tambin se denominan reglas de pre-poda porque reducen la

complejidad del rbol durante su construccin, en contraste con las reglas usuales
de post-poda que simplifican el rbol de decisin una vez ste ha sido construido
por completo.

USOS GENERALES DE ANLISIS BASADOS EN RBOLES

Segmentacin. Identifica personas que probablemente sean miembros de
una clase particular de sujeto
Estratificacin. Asigna casos a una de las categoras, como grupo con
grado de riesgo alto, medio y bajo.
Prediccin. Crea reglas y las usa para predecir futuros eventos. La
prediccin tambin puede hacer referencia al intento de establecer atributos
predictivos.
Reduccin de datos y seleccin de predictores. Selecciona un
subconjunto de predictores de una larga lista, til en la construccin de un
modelo formal paramtrico.
Interaccin-identificacin. Identificar relaciones que pertenecen slo a
subgrupos especficos y especificar stos en un modelo formal paramtrico.

53

CAPTULO III. ANLISIS DEL SISTEMA

3.1 Resumen ejecutivo de la Facultad de Contadura y

Administracin
La Universidad Veracruzana inici su existencia formal el 11 de septiembre
de 1944. Su creacin recoge los antecedentes de la educacin superior en el
estado de Veracruz al hacerse cargo de las escuelas oficiales artsticas,
profesionales, especiales y de estudios superiores existentes en ese entonces
dentro de la entidad.
Se ha convertido en la principal institucin de educacin superior en el estado de
Veracruz. Lo que naci como un pequeo grupo de escuelas y facultades es ahora
una universidad grande y compleja, con presencia en cinco campus universitarios
y en veintids localidades a lo largo del territorio veracruzano.
La Universidad Veracruzana ha experimentado importantes cambios a lo largo de
su evolucin. Cambios que se manifiestan principalmente en una diversificacin de
los campos abordados, en el nmero de reas de formacin y carreras que ofrece,
en la cantidad y calidad de sus programas relacionados con las actividades de
investigacin, extensin universitaria y difusin cultural.
La cobertura institucional abarca las reas acadmicas de Humanidades, Tcnica,
Econmico-Administrativa, Ciencias de la Salud, Biolgico-Agropecuaria y Artes.
Los grados acadmicos que se otorgan son los de tcnico profesional de nivel
medio, tcnico superior universitario, licenciatura, maestra y doctorado.
Dentro del rea Econmico-Administrativa se encuentra la Facultad de Contadura
y Administracin en la cual se imparten tres programas de licenciatura los cuales
son: Contadura, Administracin y Sistemas Computacionales Administrativos.
Cada una cuenta con su misin, visin y objetivos, a continuacin se presentan:
55

Misin
Generar

conocimientos

contables,

administrativos

de

sistemas

computacionales administrativos tiles y pertinentes a la sociedad; ensear y

aprender para formar profesionales en el rea de Contadura, Administracin y
Sistemas Computacionales Administrativos en un contexto globalizado y de
avances tecnolgicos.
Visin
Ser una institucin de excelencia y certificacin acadmica que forme
profesionistas con las competencias necesarias que les permitan integrarse de
manera proactiva con otras disciplinas profesionales en un contexto globalizado;
que contribuya a lograr cambios en el manejo de la informacin y apoye al proceso
de toma de decisiones; integrado en grupos de trabajo acadmico donde se
desarrollen actividades de investigacin, extensin y difusin con base a un plan
de estudios actualizado y dinmico que responda al vertiginoso avance
tecnolgico, promoviendo el crecimiento profesional y comprometidos con los
valores de nuestro ideario.
Coordinacin de la Experiencia Recepcional
sta es un rea perteneciente a la Facultad de contadura y Administracin,
no reconocida como oficial pero de suma importancia para el control de los
estudiantes inscritos a la experiencia educativa Experiencia Recepcional, ya que
en ella se lleva un control de todos ellos, y se les da seguimiento a sus trabajos
mediante los siguientes procedimientos:
Registro de la experiencia educativa Experiencia Recepcional
Inicio de la Experiencia Recepcional
Elaboracin y Revisin del Trabajo Recepcional o Antologa

Preparacin y presentacin del Examen Profesional en la modalidad de

Trabajo Recepcional, EGEL-CENEVAL, o Titulacin por Promedio
56

Organigrama
Junta
Acadmica
Direccin
Consejo
Tcnico

Secretara
Acadmica

Jefatura de
carrera
Contadura

Jefatura de
carrera
Administracin

Jefatura de
carrera
Sistemas

Coordinacin de
Academias de
Conocimiento

Coordinacin de
Academias de
Conocimiento

Coordinacin de
Academias de
Conocimiento

Administracin

Administracin

Coordinacin de
Posgrado

Biblioteca

Almacn

Coordinacin del Centro

de Apoyo a la Titulacin

Archivo

Vigilancia

Coordinacin del
Bussines English Center

Mantenimiento
Coordinacin
de personal
administrativo

Intendencia

Coordinacin de Centros
de Cmputo
Coordinacin de Tutoras
Coordinacin de Ceneval
Coordinacin de Servicio
Social
Coordinacin de
Educacin Continua
Coordinacin Financiera
de Eventos
cofinanciable

Figura 3.1 Organigrama de la Facultad de Contadura y Administracin campus

Xalapa de la Universidad Veracruzana.
57

3.2 Anlisis de sistemas de apoyo a la toma de

decisiones
El Anlisis de Sistemas trata bsicamente de determinar los objetivos y
lmites del sistema objeto de anlisis, caracterizar su estructura y funcionamiento,
marcar las directrices que permitan alcanzar los objetivos propuestos y evaluar
sus consecuencias.
Los sistemas de apoyo a la toma de decisiones poseen caractersticas que lo
diferencian de los dems sistemas que manejan informacin y que son
tradicionales. Los usuarios finales de los DSS (sistemas de apoyo a decisiones)
poseen caractersticas especiales que merecen ser tomadas en cuenta.
Debemos tener en cuenta que un sistema de apoyo a decisiones lo definiremos
como la manera de organizacin de informacin que se pretende usar en la toma
de decisiones. Para lo cual al presentar la informacin debe estar diseada
basndose en la solucin de problemas y esto debe darse ya que el usuario no
debe tomar la decisin, sino el DSS.
Un DSS permite al tomador de decisiones interactuar con l, y esto debe verse en
la interfaz del usuario.
Un DSS puede ser construido para dar soporte a decisiones de una sola vez y son
aquellas que son poco frecuentes a otras que suceden rutinariamente.
Un DSS debe ser diseado tpicamente para decisiones de un particular o para un
grupo, es decir que el usuario entienda mejor las soluciones por medio de grficas,
tablas u otro medio de presentacin y que sea de interfaz para el usuario.
Debemos saber utilizar las diferentes herramientas que generan DSS, as como en
la construccin de DSS especficos, y generadores de DSS.
Para el DSS, el proceso trabajar para la transformacin del usuario, el tomador
de decisiones y debe dar como resultado un cambio y mejora del desempeo en la
toma de decisiones.
58

Dentro de las organizaciones existen tres niveles, el estratgico, el administrativo y

el operacional, es por eso que a nivel operacional las decisiones se pueden tomar
y ser automatizadas satisfactoria y completamente.
Los tipos de problemas que ayuda a solucionar un DSS son complejos y
semiestructurados ya que este tipo de problemas los ve registrados en los niveles
estratgico y administrativo.
Es importante que si el usuario final est muy ocupado o preocupado por la
interaccin con el DSS, este puede ser utilizado por un intermediario tcnico o
ayudante que interacte con la computadora y as las decisiones sern tomadas
de una forma desde el proceso y no desde la mecnica.

3.3 Factibilidad del sistema

Empezando por las definiciones de las palabras factibilidad y viabilidad;
tomndolas del diccionario de la Real Academia Espaola. Factibilidad: cualidad
o condicin de factible, Factible: que se puede hacer; Viabilidad: cualidad de
viable, Viable: Que, por sus circunstancias, tiene probabilidades de poderse
llevar a cabo.
Un proyecto factible, es decir que se puede ejecutar, es el que ha aprobado cuatro
evaluaciones bsicas:
Evaluacin Tcnica
Evaluacin Operativa
Evaluacin Financiera
Evaluacin Socio-econmica
La aprobacin de cada evaluacin ser llamada viabilidad; estas viabilidades se
deben dar al mismo tiempo para alcanzar la factibilidad de un proyecto; por

59

ejemplo un proyecto puede ser viable tcnicamente pero puede ser no viable
financieramente, y as las otras posibles combinaciones; entonces con una
evaluacin que resulte no viable, el proyecto no ser factible.
En la evaluacin tcnica se analizan los tpicos referentes al comportamiento del
mercado, la tecnologa disponible, los aspectos legales y la posible estructura
organizacional.
Se puede tomar por separado de esta evaluacin el estudio del mercado y
realizar su anlisis independientemente; debido a que sus resultados marcan
trascendentalmente varios aspectos no slo de la evaluacin tcnica (tamao,
localizacin, entre otros) sino de la financiera (proyecciones de ventas,
rentabilidad, entre otros).
La evaluacin operativa hace referencia a los resultados del estudio realizado a
los participantes y personal de la institucin a quienes impacta el proyecto al
insertarlo en su entorno, para cuantificar y cualificar la aceptacin y disposicin de
adoptar el mismo; y puede ser que el impacto sea positivo o negativo.
En el caso que sea negativo tambin debe plantear el cmo encaminar el
proyecto dentro de los parmetros de la legislacin operativa vigente y cul es su
plan de sostenibilidad y adaptacin del entorno afectado.
En los proyectos que buscamos la factibilidad, son proyectos que buscan producir
un bien o servicio para satisfacer una necesidad o colmar una expectativa; para lo
cual se necesita definir su rentabilidad o no, que es el objetivo de la evaluacin
financiera.

Para terminar, tenemos la evaluacin socio-econmica; y la mencionamos as

haciendo referencia, y nfasis, en el impacto social del proyecto, aunque en un
anlisis ms profundo sonara algo redundante teniendo en cuenta que la
economa, por definicin, es una ciencia social que busca satisfacer las
necesidades humanas materiales.

60

Aqu se analizarn la poblacin afectada (cobertura del proyecto), sus impactos

(beneficios o perjuicios) y su relacin con las variables econmicas de una regin
(pas) por ejemplo: empleo generado, contribucin al PIB, relacin con el plan de
desarrollo, entre otras.
En conclusin, un proyecto factible es el que tcnica, operativa, financiera y socioeconmicamente es viable. (Bustos, 2008)
Tcnicamente, la Facultad de Contadura y Administracin cuenta con un servidor
web sobre el cual se podr montar el sistema, adems de proporcionar internet en
sus tres laboratorios de cmputo y de forma inalmbrica dentro de la institucin, lo
cual fsicamente es lo necesario para poder montar el sistema y acceder a l
desde cualquier computadora que tenga acceso a internet dentro de la Facultad
conectado a la RIUV (Red Inalmbrica de la Universidad Veracruzana)
Con respecto al software, se cuenta que con los programas necesarios tanto para
la documentacin como para la programacin del sistema de informacin. Para la
documentacin se cuenta con programas como: procesadores de texto,
herramientas CASE (Computer Aided Software Engineering, Ingeniera de
Software Asistida por Computadora) que son diversas aplicaciones informticas
destinadas a aumentar la productividad en el desarrollo de software reduciendo el
coste de las mismas en trminos de tiempo y de dinero, adems de programas
manejadores de bases de datos y programas para codificar la aplicacin, es decir,
programar el sistema.
Operativamente, la direccin de la Facultad, al igual que los actores del proceso
de la experiencia educativa Experiencia Recepcional, estn en la mejor
disposicin de colaborar con el proyecto. No existen factores que entorpezcan el
desarrollo del mismo, por lo tanto el factor ambiental es viable.
Financieramente, el proyecto no requiere de mayor costo, ya que se cuenta con
toda la infraestructura para montar el sistema, y el anlisis, diseo, desarrollo e
implementacin no tendrn costo alguno debido a que se elaboraran como
trabajos recepcionales para la titulacin de estudiantes pertenecientes a la propia
61

facultad. Debido a todo lo antes mencionado, financieramente el proyecto es

viable.
Socio-econmicamente, debido a que el proyecto es interno de la Facultad de
Contadura y Administracin, no tiene repercusiones en la sociedad, solo al interior
de la institucin. El proyecto pretende facilitar el control y seguimiento de un
segmento de estudiantes, por lo tanto repercute en ellos de manera positiva,
convirtiendo este factor en viable.
Por ltimos los resultados de los factores analizados, determinan que el proyecto
es totalmente factible.

3.4 Contexto del dominio del problema

La Coordinacin de Experiencia Recepcional (CER), encargada de dicha
experiencia educativa, lleva a cabo un conjunto de procedimientos ordenados para
controlar y dar seguimiento a los estudiantes inscritos en ella, para el caso
particular de este trabajo de investigacin se sealar el proceso de los
estudiantes que se inscriben en la modalidad de Trabajo Recepcional, el cual se
describe a continuacin:
1. Registro de la experiencia educativa Experiencia Recepcional (ER): El
estudiante ya inscrito en la Facultad de Contadura y Administracin (FCA),
realiza su inscripcin acadmica seleccionando en su carga acadmica la
experiencia educativa Experiencia Recepcional, la Secretara de la FCA
proporcionar a la CER un listado de estudiantes inscritos a la ER en el
periodo, el cual debe incluir los siguientes datos: matrcula, estudiante,
licenciatura, seccin y modalidad de ER, la CER registrar en una Base de
Datos (BD), la informacin recabada en el mtodo anterior. El estudiante
asiste a una pltica informativa de inicio de ER, en la fecha establecida por
la CER entrega el formato de registro de Director de Trabajo Recepcional,
para que sea revisado, aprobado y posteriormente asignado por la CER.
62

Para finalizar la CER registra en una base de datos la informacin recabada

en el Control de Inicio.
2. Inicio de la Experiencia Recepcional: El estudiante entrega le protocolo de
investigacin de su trabajo recepcional, previamente revisado y aprobado
por su asesor, para despus registrar el trabajo recepcional en la CER
llenando el formato Registro de Experiencia Recepcional.
3. Elaboracin y revisin del Trabajo Recepcional: El estudiante con apoyo de
su asesor realiza el trabajo correspondiente, posteriormente entrega un
informa de avance con un estimado porcentual y un anlisis general del
avance realizado, la CER agrega el avance al expediente interno del
estudiante. El estudiante entrega el voto aprobatorio del Director de su
Trabajo Recepcional, una vez terminado y revisado su trabajo, la CER
archiva el voto aprobatorio en el expediente del alumno y elabora un reporte
de los alumnos para la Direccin de la Facultad de Contadura y
Administracin, con los siguientes datos:
a. Matrcula y Nombre del Alumno
b. Ttulo del Trabajo Recepcional y Asesor
c. Cuerpo Acadmico al que pertenece el Trabajo Recepcional, en su caso.
La Direccin de la FCA asigna a los sinodales que revisarn el Trabajo
Recepcional del estudiante en un periodo de una semana, elabora lo oficios
correspondientes para informar a los Sinodales de su nueva encomienda y la CER
entrega los oficios a los estudiantes, ellos entregan los oficios a sus sinodales con
su trabajo correspondiente para ser revisado y, si as lo considera el Sinodal,
aprobado mediante un oficio dirigido a la Direccin de la FCA.

4. Preparacin y presentacin del Examen Profesional en la modalidad de

Trabajo Recepcional: La CER se encarga de la aprobacin del expediente
del alumno por parte de Archivo, ste revisa que cuente con los requisitos
necesarios para la presentacin de su Examen Profesional en su

63

Expediente General. El estudiante se presenta con el Coordinador de

Seguimiento de Egresados para obtener la firma de su aprobacin en un
formato especfico, despus entrega a la CER un paquete de documentos
para elaborar oficios de invitacin a Examen Profesional. Para finalizar el
Estudiante presenta su Examen Profesional entregando una serie de
documentos a la Secretara de la FCA y a la CER para que sta ltima
anexe los formatos al expediente interno del estudiante.
Este es, en resumen, el proceso que sigue el estudiante desde su inscripcin a la
ER hasta la presentacin de su Examen Profesional, basado en ste, se
determinaron los requisitos del sistema.

3.5 Requisitos del sistema

La especificacin de requisitos es una parte fundamental del desarrollo de
los sistemas de informacin, ya que dentro de esta etapa el usuario final nos
especifica las funciones que desea que realice su sistema, los formatos que debe
generar, la terminologa que se maneja dentro del negocio o rea de aplicacin del
sistema, las personas o pblico hacia quienes va orientado, la cantidad de
usuarios que tendr el sistema y las polticas de la empresa que debern ser
tomadas en cuenta por el sistema para la realizacin de los procesos.
En esta especificacin de requisitos se muestra la forma ms precisa de la
naturaleza del sistema, ya que se determina el contenido tanto visual como
informativo de las diferentes interfaces de diseo. Adems de determinar las
diferentes funciones que realizar el sistema y las que no, delimitacin.
Uno de los principales problemas que se representan dentro de esta fase es el
hecho de que generalmente el usuario no es capaz de poder proporcionar
claramente lo que desea o necesita debido a que no ha aterrizado sus
requerimientos o no cuenta con el tiempo suficiente para poder proporcionar los

64

datos o se presenta una mala comunicacin con intermediarios del usuario final,
generando errores de diseo y programacin.

3.5.1 Requisitos funcionales

El coordinador de experiencia recepcional requiere un sistema para el
control y seguimiento de los estudiantes inscritos a la experiencia educativa en la
modalidad de trabajo recepcional, desde la inscripcin de los estudiantes a la
experiencia educativa, as como el registro de los trabajos recepcionales, la
atencin de las solicitudes de los estudiantes, una propuesta de maestros para
que la direccin asigne sinodales y las notificaciones a los estudiantes de los
estados de sus solicitudes as como los nombres de sus sinodales.
Descripcin de requisitos:
1. Requisitos generales
a. Solo personal autorizado podr acceder al sistema.
b. Se podr acceder al sistema desde cualquier lugar y horario.
c.

Se manejarn fechas de apertura de inscripciones.

d. Las consultas sern generales, por carrera y por estado de la

solicitud del alumno

e. El sistema mantendr la informacin del alumno para su

consulta hasta que los administradores lo decidan.

f.

Todos los datos tanto del alumno como de sus trabajos

recepcionales, quedarn guardados en la base de datos.

g. El sistema deber mostrar a los sinodales ms capacitados en

el rea a la que pertenece el trabajo recepcional de cada

alumno.
65

2. Requisitos del alumno

a. La llave general ser su matrcula externa, la cual lo

relacionar con todos los datos.

b. La asignacin de sus sinodales ser en relacin a las reas

de conocimiento a las que pertenezca su trabajo recepcional y

la especialidad de cada maestro.
3. Requisitos del sinodal
a. La llave principal es su nmero de personal.
b. Estar vinculado al alumno del cual ser sinodal.

4. Manejo de usuarios
a. Registro de usuarios
i.

Los estudiantes debern registrarse por medio de la

interfaz del alumno o por medio del administrador.

ii.

Los sinodales solo podrn ser dado de alta por el

administrador.

iii.

Debern incluir todos los datos solicitados para darse

de alta en el sistema.

b. Modificacin y eliminacin de usuarios

i.

Solamente el administrador podr realizar estas

acciones.

ii.

Los usuarios tendrn que notificar al administrador para

que ste realice la accin.

66

3.5.2 Requisitos de implementacin

Para la implementacin del sistema de apoyo a la toma de decisiones de la
coordinacin de experiencia recepcional, se determinaron las siguientes
herramientas de software, hardware y otros recursos.
Base de datos para almacenar la informacin de los estudiantes, el perfil de
sus trabajos recepcionales y los sinodales que el sistema asigne.
Lenguaje de programacin seguro y robusto para el desarrollo de
aplicaciones Web.
IDE de desarrollo que permita pruebas a nivel local y conexin con bases
de datos.
Servidor de aplicaciones Web para realizar las pruebas e implementar el
producto final.
Conexin a internet para poder conectarse al servidor de aplicaciones.
Diseador y programador, equipo de desarrollo.
Un servidor dedicado.
Informacin relativa a estudiantes y profesores.

3.5.3 Requisitos de seguridad

El sistema al ser parte del Sistema Integral de Gestin Administrativa (SIGA),
deber contener el mismo nivel de seguridad que maneja el SIGA, ya que contiene
informacin importante sobre los estudiantes y maestros que se encuentran en su
base de datos, debern establecerse niveles de acceso a la informacin as como
la modificacin y eliminacin de la informacin por alguno de los usuarios, basado
en esto se considera lo siguiente:

67


a. Solo el administrador podr tener acceso a toda la informacin del sistema.
b. Cada usuario del sistema deber ingresar desde la pantalla de login para

verificar su nivel de acceso.

c.

La sesin de un usuario solo podr ser iniciada una vez.

3.6 Modelo conceptual

Se trata de obtener el esquema conceptual de la base de datos a partir de
la lista descriptiva de objetos y asociaciones identificadas en

la organizacin

durante el anlisis. A continuacin se muestra el modelo conceptual del sistema

de apoyo a la toma de decisiones que se presenta en este proyecto. Ver figura 3.1

Figura 3.2 Modelo conceptual del sistema de apoyo a la toma de decisiones para
asignacin de sinodales de exmenes profesionales en la Facultad de Contadura
y Administracin.

68

CAPTULO IV: DISEO DEL SISTEMA

4.1 Diseo del sistema

El Diseo de Sistemas se define el proceso de aplicar ciertas tcnicas y
principios con el propsito de definir un dispositivo, un proceso o un Sistema, con
suficientes detalles como para permitir su interpretacin y realizacin fsica.
La etapa del Diseo del Sistema encierra cuatro etapas:
El diseo de los datos: Trasforma el modelo de dominio de la informacin,
creado durante el anlisis, en las estructuras de datos necesarios para
implementar el Software.
El Diseo Arquitectnico: Define la relacin entre cada uno de los
elementos estructurales del programa.
El Diseo de la Interfaz: Describe como se comunica el Software consigo
mismo, con los sistemas que operan junto con el y con los operadores y
usuarios que lo emplean.
El Diseo de procedimientos: Transforma elementos estructurales de la
arquitectura del programa. La importancia del Diseo del Software se puede
definir en una sola palabra Calidad, dentro del diseo es donde se fomenta
la calidad del Proyecto. El Diseo es la nica manera de materializar con
precisin los requerimientos del cliente.

70

4.2 Modelo lgico

El diseo lgico es el proceso de construir un esquema de la informacin
que utiliza la empresa, basndose en un modelo de base de datos especfico,
independiente del SGBD concreto que se vaya a utilizar y de cualquier otra
consideracin fsica.
En esta etapa, se transforma el esquema conceptual en un esquema lgico
que utilizar las estructuras de datos del modelo de base de datos en el que se
basa el SGBD que se vaya a utilizar, como puede ser el modelo relacional, el
modelo de red, el modelo jerrquico o el modelo orientado a objetos. Conforme
se va desarrollando el esquema lgico, ste se va probando y validando con
los requisitos de usuario.
La normalizacin es una tcnica que se utiliza para comprobar la validez de los
esquemas lgicos basados en el modelo relacional, ya que asegura que las
relaciones (tablas) obtenidas no tienen datos redundantes. Esta tcnica se
presenta en el captulo dedicado al diseo lgico de bases de datos.
El esquema lgico es una fuente de informacin para el diseo fsico. Adems,
juega un papel importante durante la etapa de mantenimiento del sistema, ya
que permite que los futuros cambios que se realicen sobre los programas de
aplicacin o sobre los datos, se representen correctamente en la base de
datos.
Tanto el diseo conceptual, como el diseo lgico, son procesos iterativos,
tienen un punto de inicio y se van refinando continuamente. Ambos se deben
ver como un proceso de aprendizaje en el que el diseador va comprendiendo
el funcionamiento de la empresa y el significado de los datos que maneja. El
diseo conceptual y el diseo lgico son etapas clave para conseguir un
sistema que funcione correctamente. Si el esquema no es una representacin
fiel de la empresa, ser difcil, sino imposible, definir todas las vistas de usuario
(esquemas externos), o mantener la integridad de la base de datos. Tambin
puede ser difcil definir la implementacin fsica o el mantener unas
prestaciones aceptables del sistema. Adems, hay que tener en cuenta que la
capacidad de ajustarse a futuros cambios es un sello que identifica a los
71

buenos diseos de bases de datos. Por todo esto, es fundamental dedicar el

tiempo y las energas necesarias para producir el mejor esquema que sea
posible. Ver Figura 4.1

Figura 4.1 Diseo lgico del sistema de apoyo a la toma de decisiones para la
asignacin de sinodales de exmenes profesionales en la Facultad de
Contadura y Administracin.
72

4.3 Modelo fsico

El diseo fsico es el proceso de producir la descripcin de la
implementacin de la base de datos en memoria secundaria: estructuras de
almacenamiento y mtodos de acceso que garanticen un acceso eficiente a los
datos.
Para llevar a cabo esta etapa, se debe haber decidido cul es el SGBD que se va
a utilizar, ya que el esquema fsico se adapta a l. Entre el diseo fsico y el diseo
lgico hay una realimentacin, ya que algunas de las decisiones que se tomen
durante el diseo fsico para mejorar las prestaciones, pueden afectar a la
estructura del esquema lgico.
En general, el propsito del diseo fsico es describir cmo se va a implementar
fsicamente el esquema lgico obtenido en la fase anterior. Concretamente, en el
modelo relacional, esto consiste en:

Obtener un conjunto de relaciones (tablas) y las restricciones que se deben

cumplir sobre ellas.

Determinar las estructuras de almacenamiento y los mtodos de acceso

que se van a utilizar para conseguir unas prestaciones ptimas.

Disear el modelo de seguridad del sistema.

Diseo fsico del sistema de apoyo a la toma de decisiones para la asignacin de

sinodales

de exmenes profesionales en la Facultad de Contadura y

Administracin. Ver figura 4.2

73

Figura 4.2 Diseo fsico del sistema de apoyo a la toma de decisiones.

74

4.4 Diseo de rboles de decisin

A continuacin se presenta el rbol de decisin aplicado al problema que
nos compete.
Para su creacin se considero dividirlo en 3 rboles para llevar a cabo una mejor
representacin de la Toma de Decisiones de los sinodales de acuerdo al perfil del
trabajo recepcional realizado por el alumno.
En el primer rbol de decisin se ven todas las ramificaciones hasta las cuales el
sinodal se considera como una buena eleccin dada en porcentaje (%). Primero
se selecciona la carrera (Sistemas Computacionales Administrativos), luego el
rea a la que pertenece el Trabajo Recepcional (Sistemas de Informacin,
Matemticas-Contabilidad o Econmico-Administrativo) a continuacin una sub
rea y por ltimo una especializacin, con esos tres filtros se obtendr al maestro
mejor preparado en el rea de conocimiento a la que pertenece cada trabajo
recepcional, en este caso se considera el 100%. Ver figura 4.3
En el segundo rbol de decisin se puede ver que la seleccin de sinodal ser de
un 75% para lo cual ya no se toma el ultimo criterio del rbol anterior. Ver figura
4.4
Y por ultimo en el tercer rbol se muestra una seleccin de sinodal con un
porcentaje del 50%. Lo cual representa que aun es considerado como una buena
opcin a elegir como jurado responsable de evaluar el trabajo recepcional del
alumno. Todo lo anterior considerando el perfil del trabajo y las reas especificas a
las cuales pertenece. Ver figura 4.5
Todas stas reas, sub reas y especialidades fueron tomadas conforme a las
academias y los cuerpos acadmicos que existen dentro de la Facultad de
Contadura y Administracin.

75

Figura 4.3 Seleccin de Sinodal ms adecuado para realizar revisin del trabajo
recepcional, de acuerdo a las reas especficas del trabajo.
76

Figura 4.4 Considerando las academias a las cuales pertenece el trabajo

recepcional.

77

Figura 4.5 Considerando nicamente las reas generales.

78

4.5 Diccionario de datos

Un diccionario de datos es un conjunto de metadatos que contiene las
caractersticas lgicas y puntuales de los datos que se van a utilizar en el sistema
que se programa, incluyendo nombre, tipo de dato y longitud de mismo.
Estos diccionarios se desarrollan durante el anlisis de flujo de datos y ayuda a los
analistas que participan en la determinacin de los requerimientos del sistema, su
contenido tambin se emplea durante el diseo del proyecto.
Identifica los procesos donde se emplean los datos y los sitios donde se necesita
el acceso inmediato a la informacin, se desarrolla durante el anlisis de flujo de
datos y auxilia a los analistas que participan en la determinacin de los
requerimientos del sistema, su contenido tambin se emplea durante el diseo.
En un diccionario de datos se encuentra la lista de todos los elementos que
forman parte del flujo de datos de todo el sistema. Los elementos ms importantes
son flujos de datos, almacenes de datos y procesos. El diccionario de datos
guarda los detalles y descripcin de todos estos elementos.

Tablas

Tabla: Academias

Nombre del campo

id_academia
nom_academia
area_academica

Tipo de dato
Int
Varchar
Int

Longitud
2
20
2

79

Tabla: Alumnos
Nombre del campo
matricula_externa
apellido_paterno
apellido_materno
nombre
calle
colonia
ciudad
codigo_postal
estado
carrera
tel_emergencia
matricula_interna
sexo
email
usuario
contrasena

Tipo de dato
Varchar
Varchar
Varchar
Varchar
Varchar
Varchar
Varchar
Varchar
Varchar
Char
Varchar
Varchar
Char
Varchar
Varchar
Varchar

Longitud
9
15
15
20
20
20
20
5
15
2
10
8
1
35
15
15

Tabla: Area_academica
Nombre del campo
id_nombre
nombre

Tipo de dato
int
varchar

Longitud
2
20

Tabla: Area_trabajo
Nombre del campo
no_area
nombre_area

Tipo de dato
int
varchar

Longitud
2
20

Tabla: Cat_profesor
Nombre del campo
nombre_area
apellido_paterno
apellido_materno
nombre
email
telefono
Sexo
Activo
Num_asesorados

Tipo de dato
int
Varchar
Varchar
Varchar
Varchar
varchar
Char
int
int

Longitud
2
15
15
15
35
10
1
1
1

80

Tabla: Contenido_trabajorec
Nombre del campo
clave_trabajo
num_capitulo
nom_capitulo

Tipo de dato
varchar
int
varchar

Longitud
9
1
30

Tabla: Cuerpo_academico
Nombre del campo
no_cuerpo
nombre_cuerpo

Tipo de dato
int
varchar

Longitud
1
30

Tabla: Materias
Nombre del campo
id_materia
nombre
id_academia
no_area

Tipo de dato
int
varchar
int
int

Longitud
2
15
2
2

Tabla: Prof_cuerpo_acad
Nombre del campo
no_personal
nombre_prof
no_cuerpo

Tipo de dato
int
varchar
int

Longitud
5
40
2

Tabla: Profesor
Nombre del campo
no_personal
no_area
id_academia
id_materia

Tipo de dato
int
int
int
int

Longitud
5
2
2
2

Tabla: Sesiones
Nombre del campo
usuario
nivel_acceso
fecha_acceso

Tipo de dato
varchar
char
date

Longitud
20
2

81

Tabla: Sinodal_alumno
Nombre del campo
matricula_externa
director
sinodal1
Sinodal2
suplente1
Suplente2

Tipo de dato
Varchar
Int
Int
Int
Int
Int

Longitud
9
5
5
5
5
5

Tabla: Trabajo_recep
Nombre del campo
clave_trabajo
nombre
estado
Modalidad
area1
Area2
cuerpo_academico
observaciones

Tipo de dato
varchar
varchar
Int
Int
Int
Int
int
varchar

Longitud
9
50
1
1
2
2
2
200

82

CONCLUSIONES

El aseguramiento de la calidad es un aspecto importante en cualquier

organizacin y se puede definir como el esfuerzo total para planear, organizar,
dirigir y controlar la calidad de los procesos con el objetivo de ofrecer al cliente la
mayor satisfaccin posible. ste es uno de los objetivos primordiales de la
Universidad Veracruzana, en particular de la Facultad de Contadura y
Administracin regin Xalapa. La cual se ha dado a la tarea de mejorar sus
procesos permanentemente apoyada de las tecnologas de informacin.
Para el caso de este trabajo de investigacin, la Coordinacin de Experiencia
Recepcional (ER), en busca de mejorar los tiempos de respuesta a sus
estudiantes inscritos, y con el fin de asignar de manera objetiva a los maestros
ms aptos para fungir como jurado de los trabajos recepcionales, extern la
necesidad de una herramienta que apoyara a la coordinacin de ER realizando
tareas que son repetitivas, de manera automtica mediante un sistema de
informacin que adems le brindara un listado de los maestros mejor preparados
en las reas de conocimiento a las que cada trabajo recepcional pertenece.
Optimizando as los tiempos de respuesta y la asignacin de sinodales para los
exmenes profesionales de los estudiantes con derecho a titulacin, en la
modalidad de Trabajo Recepcional.
La creacin de ste sistema de apoyo a la toma de decisiones para la
Coordinacin de ER se inicia con la deteccin de una necesidad, la cual en este
caso es que no se tiene un control de los perfiles de conocimiento de los maestros
de la Facultad de Contadura y Administracin, ni de los perfiles de cada trabajo
de recepcional que llegan a manos de la coordinacin y por lo tanto al momento
de elegir el jurado para los exmenes profesionales se toman decisiones en la
asignacin de sinodales sin contar con la suficiente informacin para que las
mismas puedan estar bien respaldadas, por falta del conocimiento necesario.
84

A continuacin se determin que la metodologa ms idnea para el desarrollo de

este sistema, es la de Desarrollo Rpido de Aplicaciones, debido a que sta ofrece
las mejores ventajas con respecto a las limitaciones de tiempo que se tienen.
Estas ventajas son las siguientes:

El cliente ve resultados en un corto tiempo. Con los mtodos

convencionales pasa un gran lapso de tiempo antes de que el cliente vea
resultados.

El desarrollador completa el sistema en un tiempo razonable para el cliente

con la intencin de conservar los objetivos previamente planteados. Con los
mtodos convencionales el desarrollo llega a tardar tanto que para cuando
el sistema est listo para utilizarse los procesos del cliente han cambiado
radicalmente.

Se entregan partes del sistema como prototipo, hasta que se completan

todos los mdulos y se integra en su totalidad el sistema, de tal manera el
cliente va recibiendo partes del producto final. Con los mtodos
convencionales no hay nada hasta que el 100% del proceso de desarrollo
se ha realizado, entonces se entrega el 100% del software.

Al realizar el anlisis se encontr que los estudiantes que no pertenecen al Centro

de apoyo a la Titulacin (CAT), pasa por el siguiente proceso para la asignacin
de sus sinodales:
El Director tiene la lista de las asignaciones realizadas en el CAT y la lista
de profesores de acuerdo a la academia que corresponden.
Teniendo como referencia las listas mencionadas anteriormente, asigna
sinodales a los dems estudiantes bajo lo siguiente:
o Se debe tomar en cuenta el rea a la que pertenece el trabajo para
seleccionar profesores que pertenezcan a la misma rea.

85

Se toman dos sinodales propietarios y dos suplentes por cada trabajo o

alumno bajo las siguientes condiciones:
o Los sinodales deben pertenecer a la misma rea que el trabajo.
o El horario de presentacin de cada trabajo influye en los sinodales,
ya que un sinodal no puede presentarse con dos estudiantes en la
misma fecha y hora.

Para el diseo del sistema se ocuparon rboles de decisin los cuales son un
modelo de prediccin que expresa, en orden cronolgico las acciones alternativas
viables para el tomado de decisiones y las opciones que la suerte o el azar
determina, es utilizado en el mbito de la inteligencia artificial, dada una base de
datos se construyen diagramas de construcciones lgicas, muy similares a los
sistemas de prediccin basados en reglas, que sirven para representar y
categorizar una serie de condiciones que ocurren de forma sucesiva, para la
resolucin de un problema.
Para la base de datos se utilizar la base de datos del SIGA, pero adems se ha
considerado agregar otras tablas mas que son las que nos permiten almacenar los
datos que permitirn tomar la decisin acerca de la asignacin de sinodales, las
cuales menciono a continuacin: Academias, Alumno, rea Academia, Catlogo
de profesores, Contenido de Trabajo Recepcional, Cuerpo Acadmico, Sinodal del
Alumno, Experiencias educativas, Catlogo de Profesores, Sesiones, Trabajo
Recepcional y Usuario.
Con estas tablas qued elaborado el diseo conceptual, lgico y fsico para
finalizar con un diccionario de datos que describir la estructura de este sistema
de apoyo a la toma de decisiones para la coordinacin de Experiencia
Recepcional.

86

FUENTES DE INFORMACIN

Anlisis de sistemas. Consultado en Junio, 12, 2009, en

http://www.daedalus.es/inteligencia-de-negocio/sistemascomplejos/ingenieria-de-sistemas/analisis-de-sistemas/
Bustos Coral, Holman Daro. Proyectos factibles o proyectos viables.
Consultado en Abril 25, 2009 en
http://www.gestiopolis.com/canales6/emp/proyectos-factibles-o-viables.htm
Desarrollo gil de software. Consultado en Junio , 3, 2009, en
http://es.wikipedia.org/wiki/Desarrollo_%C3%A1gil_de_software#Metodolog.
C3.ADas_.C3.A1giles
Kendall & Kendall. Anlisis y Diseo de Sistemas. 3 Edicin. Pearson
Educacin.
Lineamientos para el control escolar. Universidad Veracruzana, 2002.
Modelo DRA. Consultado en Junio, 14, 2009, en
http://148.202.148.5/cursos/cc321/fundamentos/unidad1/dra.htm
Peralta, Manuel. Sistemas de informacin. Consultado en Abril 22, 2009 en
http://www.monografias.com/trabajos7/sisinf/sisinf.shtml
Pressman, Roger S. Ingeniera del Software. 4 Edicin. Mc Graw Hill
Programacin extrema. Consultado en Junio, 5, 2009, en
http://es.wikipedia.org/wiki/Programaci%C3%B3n_Extrema
RAD: Desarrollo Rpido de Aplicaciones. Consultado en Junio, 14, 2009, en
http://www.mena.com.mx/gonzalo/maestria/ingsoft/presenta/rad/

87

Schwaber, K. Advanced Development Methods. SCRUM Development

Process(PDF), 2006. Consultado en Junio 5, 2009 en
http://jeffsutherland.com/oopsla/schwapub.pdf
SCRUM. Consultado en Junio, 5, 2009, en
http://es.wikipedia.org/wiki/Scrum
Senn, James. Anlisis y Diseo de Sistemas de Informacin, Segunda
Edicin, Mc Graw Hill, Abril 2000.
Senn, James. Sistemas de Informacin para la Administracin. Grupo
Editorial Iberoamrica.
Turban, Efraim (2005). Decision Support Systems and Intelligent Systems.
Ed. Prentice Hall. 7 Edicin.

88

GLOSARIO DE TRMINOS

.NET Proyecto de Microsoft para crear una nueva plataforma de desarrollo de

software con nfasis en transparencia de redes, con independencia de plataforma
de hardware y que permita un rpido desarrollo de aplicaciones.
Anlisis Es un conjunto o disposicin de procedimientos o programas
relacionados de manera que juntos forman una sola unidad.
Automatizacin Sistema donde se trasfieren tareas de produccin, realizadas
habitualmente por operadores humanos a un conjunto de elementos tecnolgicos.
Campo Corresponde al nombre de la columna. Debe ser nico y adems de
tener un tipo de dato asociado.
CAT Centro de Apoyo a la Titulacin.
CENEVAL Centro Nacional de Evaluacin para la Educacin Superior.
Codificacin Transformar un contenido a un cdigo.
Cdigo Se refiere a cdigo fuente: conjunto de lneas de texto que son las
instrucciones que debe seguir la computadora para ejecutar dicho programa.
Daily standup Da de un sprint en el que se realiza una reunin sobre el estado
del proyecto en el modelo SCRUM.
Dato Es una representacin simblica (numrica, alfabtica, algortmica etc.),
atributo o caracterstica de una entidad.
Delphi Entorno de desarrollo de software diseado para la programacin de
propsito general con nfasis en la programacin visual.
Diseo Proceso de aplicar ciertas tcnicas y principios con el propsito de
definir un dispositivo, un proceso o un Sistema, con suficientes detalles como para
permitir su interpretacin y realizacin fsica.
90

DSS (Decision Support System) Sistema de apoyo a decisiones.

EGEL Examen General de Egreso de la Licenciatura.
Experiencia educativa

Curso de informacin en el que se imparten

conocimientos acerca de un tema en especfico.

Experiencia Recepcional Actividad acadmica integradora de conocimientos.
Factibilidad Significa que puede ser hecho, que es posible llevarlo a cabo o
que es realizable en la realidad y se espera que su resultado sea exitoso o
satisfaga las necesidades.
Feedback Retroalimentacin.
Framework estructura de soporte definida, mediante la cual otro proyecto de
software puede ser organizado y desarrollado.
Hardware Todas las partes fsicas y tangibles de una computadora.
In house Dentro de la organizacin.
Interfaz Parte de un programa que permite el flujo de informacin entre un
usuario y la aplicacin, o entre la aplicacin y otros programas o perifricos. Esa
parte de un programa est constituida por un conjunto de comandos y mtodos
que permiten estas intercomunicaciones.
Java

Lenguaje de programacin orientado a objetos desarrollado por Sun

Microsystems.
JUnit Conjunto de bibliotecas creadas por Erich Gamma y Kent Beck que son
utilizadas en programacin para hacer pruebas unitarias de aplicaciones Java.
MEIF Modelo Educativo Integral y Flexible.
Metadatos Son datos que describen otros datos.

91

Mtodo Dirigido a modelar el objeto mediante la determinacin de sus

componentes, as como las relaciones entre ellos. Esas relaciones determinan por
un lado la estructura del objeto y por otro su dinmica.
Modelado Tcnica cognitiva que consiste en crear una representacin ideal de
un objeto real mediante un conjunto de simplificaciones y abstracciones, cuya
validez se pretende constatar.
Modulizar Dividir en partes o mdulos un sistema.
MRP (Manufacturing Resource Planning) Fabricacin de planeacin de recursos.
Normalizacin tcnica que se utiliza para comprobar la validez de los
esquemas lgicos basados en el modelo relacional, ya que asegura que las
relaciones (tablas) obtenidas no tienen datos redundantes.
NUnit Framework open source de Pruebas de unidad para Microsoft .NET y
Mono.
Product Backlog conjunto de requisitos de alto nivel priorizados que definen el
trabajo a realizar.
ProductOwner Rol del modelo SCRUM que representa a los stakeholders.
Programacin Proceso por el cual se escribe (en un lenguaje de programacin),
se prueba, se depura y se mantiene el cdigo fuente de un programa informtico.
Prototipo Modelo a escala de lo real, pero no tan funcional como para que
equivalga a un producto final, ya que no lleva a cabo la totalidad de las funciones
necesarias del sistema final, proporcionando una retroalimentacin temprana por
parte de los usuarios acerca del sistema.
RAD (Rapid Applications Development) Desarrollo rpido de aplicaciones.
SATD Sistema de Apoyo a la Toma de Decisiones.

92

Scrum modelo de referencia que define un conjunto de prcticas y roles, y que

puede tomarse como punto de partida para definir el proceso de desarrollo que se
ejecutar durante un proyecto.
ScrumMaster Rol del modelo SCRUM que mantiene los procesos y trabaja de
forma similar al Director de proyecto.
SGBD Sistema de Gestin de Bases de Datos
Sistemas de informacin Conjunto de elementos que interactan entre s con
el fin de apoyar las actividades de una empresa o negocio.
Software Es el conjunto de los programas de cmputo, procedimientos, reglas,
documentacin y datos asociados que forman parte de las operaciones de un
sistema de computacin.
Sprint Periodo de tiempo de trabajo constante en el modelo SCRUM.
Stakeholders Clientes externos o internos, propietarios del producto.
Tablas Tipo de modelado de datos, donde se guardan los datos recogidos por
un programa. Su estructura general se asemeja a la vista general de un programa
de Hoja de clculo.
Team Rol del modelo SCRUM que incluye a los desarrolladores.
Viabilidad Condicin que hace posible el funcionamiento de una parte de un
sistema.
XP (Extreme Programming) Programacin Extrema.

93