ESCUELA MILITAR DE INGENIERA

MCAL. ANTONIO JOS DE SUCRE

BOLIVIA


PROYECTO DE CURSO


Sistema de gestin de Malla Curricular
Chambi Torrez Omar
Flores Salazar Diego
Orellana Ramrez Ariel




LA PAZ, 2012
Chambi Torrez Omar A8796-3 6899300 LP
Flores Salazar Diego A9853-1 8342679 LP
Orellana Ramrez Ariel A9460-9 5961525 LP


Sistema de Gestin de Malla Curricular

Modalidad: PROYECTO PRESENTADO COMO
REQUISITO PARCIAL PARA APROBAR
INGENIERIA DE SOFTWARE
Y CONTINUAR EN LA CARRERA.

CAPTULO I: GENERALIDADES 1
1.1 INTRODUCCIN 1
1.2 ANTECEDENTES 1
1.2.1 ANTECEDENTES GENERALES 1
1.2.2 ANTECEDENTES ACADMICOS 1
1.3 DESCRIPCIN DEL OBJETO DE ESTUDIO 2
1.4 PLANTEAMIENTO DEL PROBLEMA 2
1.4.1 PROBLEMA PRINCIPAL 2
1.4.2 PROBLEMAS SECUNDARIOS 2
1.5 OBJETIVOS 3
1.5.1 OBJETIVO GENERAL 3
1.5.2 OBJETIVOS ESPECFICOS 3
1.6 JUSTIFICACIN 3
1.6.1 JUSTIFICACIN METODOLGICA 3
1.6.2 JUSTIFICACIN TERICA 3
1.6.3 JUSTIFICACIN SOCIAL 3
1.7 ALCANCES 4
CAPTULO II: ESTUDIO DE FACTIBILIDAD 5
2.1 FACTIBILIDAD TCNICA 5
2.1.1 REQUERIMIENTOS DEL SOFTWARE 5
2.2 FACTIBILIDAD OPERATIVA 5
2.3 FACTIBILIDAD ECONMICA 6
2.4 COSTO DE DESARROLLO DE SOFTWARE COCOMO 9
CAPTULO III: MARCO TERICO 13
3.1 INGENIERA DE SOFTWARE 14
3.1.1 INTRODUCCIN 14
3.1.2 OBJETIVOS DE LA INGENIERA DE SOFTWARE 14
3.1.3 COMPETITIVIDAD 16
3.1.4 ESTRATEGIAS PARA SU DESARROLLO 17
3.1.5 MTODO DEL CICLO DE VIDA CLSICO 18
1) INVESTIGACIN PRELIMINAR 18
2) DETERMINACIN DE LOS REQUISITOS DEL SISTEMA. 19
3) DISEO DEL SISTEMA (DISEO LGICO) 19
4) DESARROLLO DE SOFTWARE (DISEO FSICO). 20
5) PRUEBA DE SISTEMAS. 20
6) IMPLANTACIN Y EVALUACIN. 20
RUP:RATIONAL UNIFIED PROCESS 21
CICLO DE VIDA ITERATIVO INCREMENTAL 23
MPR: METODOLOGA DE PROTOTIPADO RPIDO 26
DEFINICIN DE MPR 26
REPRESENTACIN GRFICA DE MPR 27
FASE 1: DEFINICIN DE ESPECIFICACIONES 27
FASE 2: DISEO CONCEPTUAL 28
FASE 3: DESARROLLO DEL PROTOTIPO 28
FASE 4: PRUEBAS DEL USUARIO 28
FASE 5: IMPLANTACIN 28
FASE 6: AUDITORA Y SEGUIMIENTO 29
MPR: RESUMEN DE FASES, ACTIVIDADES Y TAREAS ERROR! BOOKMARK NOT DEFINED.
CAPTULO IV: INGENIERIA DEL PROYECTO 30
4.1 PLAN DE DESARROLLO DE SOFTWARE SEGN MPR 31
4.2 PLAN DE DESARROLLO DE SOFTWARE SEGN RUP 33
4.2.1.1 RESULTADOS DE LAS ENTREVISTAS Y LAS VISITAS. 35
4.2.1.2 TABLA DE IDENTIFICACIN DE ROLES DE LOS INVOLUCRADOS 35
4.2.1.3 DIAGRAMA DE PAQUETES DEL MODELADO 36
4.2.1.4 DIAGRAMAS DE FLUJO DE DATOS DE LOS PROCESOS ACTUALESERROR! BOOKMARK
NOT DEFINED.
4.2.2.1 TABLA DE DETERMINACIN DE REQUERIMIENTOS 37
4.2.2.2 TABLA DE ESPECIFICACIN DE REQUERIMIENTOS 38
4.2.3.1 DIAGRAMAS DE CASOS DE USO DE ALTO NIVEL 41
4.2.3.2 DIAGRAMAS DE EXPANDIDO 37
4.2.3.3 DIAGRAMA DE SECUENCIA DE DISEO 43
CAPTULO V: CONCLUSIONES Y RECOMENDACIONES 44
5.1 CONCLUSIONES 44
5.2 RECOMENDACIONES 44
ANEXOS 44


ndice de Tablas
Tabla 1 .............................................................................................................................. 5
Tabla 2 .............................................................................................................................. 5
Tabla 3 .............................................................................................................................. 6
Tabla 4 .............................................................................................................................. 6
Tabla 5 .............................................................................................................................. 7
Tabla 6 .............................................................................................................................. 7
Tabla 7 .............................................................................................................................. 8
Tabla 8 .............................................................................................................................. 8
Tabla 9 .............................................................................................................................. 9
Tabla 10........................................................................................................................... 10
Tabla 11........................................................................................................................... 31
Tabla 12........................................................................................................................... 33



1

Captulo I: GENERALIDADES
1.1 Introduccin
En los ltimos aos, se puede apreciar un avance tecnolgico sorprendente, ordenadores
porttiles, celulares ms inteligentes que sus usuarios, etc. Es imposible ser parte de este
avance tecnolgico, pues el hombre, desde sus inicios ha utilizado su medio para su beneficio,
considerando las herramientas, muchas de ellas para su supervivencia, otras, para su
entretenimiento.
La tecnologa ha alcanzado un punto tal en el que la administracin diferentes documentos son
tarea de minutos, tal vez horas, y el transporte es mas cmodo, en lugar de llevar una pila de
documentos se transporta una pequea capacidad de memoria digital.
El presente proyecto pretende generar software que sea accesible para generar, modificar o
alterar una malla curricular de alguna carrera universitaria, en especfico, la malla curricular de
cualquier carrera de la Escuela Militar de Ingeniera, con el fin de mantener organizada y
actualizada la informacin propuesta por los diferentes jefes de carrera.
1.2 Antecedentes
1.2.1 Antecedentes generales
Debido a que este es un proyecto poco comn no se tienen muchos registros de mallas
curriculares ya que la mayor parte de las instituciones simplemente programas como Word o
Excel para esta tarea, en anteriores mallas curriculares u otras que existen en la red se puede
observar que cada una est estructurada de distintas formas siguiendo un formato segn sea la
institucin en nuestro caso de la misma manera el sistema propuesto plantea dar soluciones a
ciertos inconvenientes que puedan tener en la gestin y/u organizacin de estas mallas.
1.2.2 Antecedentes Acadmicos
Se denomina malla curricular al componente del plan de estudios que buscar responder
a dos preguntas estructurales:
tudiantes?

La alegora de malla se hace porque al disearse la organizacin de problemas, mbitos
conceptuales e incluso los contenidos posibles, las metodologas, los procedimientos y los
criterios de evaluacin que se manejaran en el aula de clase, fueron pensados, tejidos y
estructurados con una trama tanto vertical como horizontal.
La malla curricular es la estructura que da cuenta de la forma como los maestros abordan el
conocimiento desde preescolar hasta undcimo grado. Es un instrumento que les permite, de
manera comunitaria integrar las reas desde diferentes enfoques, propiciando el dilogo entre
saberes; es decir, una buena malla curricular conduce a los maestros a realizar su labor
2

pedaggica articulada e integrada. Por lo tanto, la malla curricular proporciona una visin de
conjunto sobre la estructura general de un rea.
La carrera como se ha visto no cuenta con un sistema de malla curricular muy desarrollado y es
demasiado escaso no se tiene un registro en digital que no sea en documento Word de la malla
curricular u horario de clases, los sistemas de informacin son utilizados en muchos mbitos y
tareas tiene el fin de administrar la informacin que se tiene para que esta sea organizada y
confiable lo cual queremos plasmar en el proyecto que se est desarrollando
1.3 Descripcin del objeto de estudio

La implementacin de un sistema de gestin de malla curricular no es una idea que podamos
decir nueva, existen diferentes tipos de sistemas de esta clase con la diferencia que estos son
de un tipo de sistema manual, el sistema planteado por nuestro cliente o empleador Coronel
Narvez pretende innovar un sistema de gestin de malla curricular digital, en el que la
modificacin sea sencilla tanto para el personal acadmico docente como para el mismo jefe de
carrera.
El sistema planteado pretende establecer la carrera por especialidades, que la modificacin
de estos no represente un problema en si, adems que el sistema indique la carga horaria por
materia, por otra parte, los docentes deben poder ser cambiados o especificados en dicho
sistema y en las materias que dictan, as mismo, ellos deben ser capaces de incluir el
contenido mnimo de la o las materias de su especialidad, la bibliografa e inclusive las fechas
de exmenes.
Finalmente, el sistema no debe ser exclusivo de la carrera de Ingeniera de sistemas, sino debe
ser aplicable a todas las carreras de la Escuela Militar de Ingeniera, la exclusividad est en
que pertenezca a la universidad.
Por otra parte, como ya se haba mencionado, el sistema en si debe ser del tipo web, esto para
la facilidad en la conexin por parte de toda el rea administrativa, de esa manera el personal
docente podra cambiar fcilmente diferente informacin.
1.4 Planteamiento del problema
1.4.1 Problema principal
La inexistencia de un sistema de informacin digital y automatizada de gestin de la malla
curricular a un nivel profesional de forma efectiva y fcil provoca deficiencia en la
administracin de la misma
1.4.2 Problemas secundarios
Herramientas necesarias para llevar a cabo el desarrollo a cabalidad
Adaptacin del sistema dentro de las necesidades exigidas
Tiempo de desarrollo
3

1.5 Objetivos
1.5.1 Objetivo General
Desarrollar un sistema de gestin de malla curricular para el seguimiento detallado, la
organizacin y actualizacin de las mallas curriculares de las diferentes carreras propuestas
por la Escuela Militar de Ingeniera.
1.5.2 Objetivos Especficos
Registrar e identificar a los docentes y las materias dictadas por los mismos
Utilizar las herramientas necesarias para desarrollar el sistema de manera eficiente
Lograr realizar el sistema de forma que el manejo sea de manera fcil y que sea
satisfactoria para el cliente final
Terminar el proyecto dentro del tiempo determinado
1.6 Justificacin
1.6.1 Justificacin metodolgica
La metodologa utilizada en este proyecto se basa en OOHDM esto es debido a que ofrece una
mayor facilidad al momento de realizar cambios en proyecto y facilidades en su construccin ya
que los otros mtodos son demasiado rgidos al momentos de tratar de cambiar el diseo y la
implementacin requerimiento por el cual el proyecto se ve obligado a realizar cambios segn
sea el gusto del cliente
1.6.2 Justificacin terica
El proyecto desarrollado servir para mayor facilidad de administracin de horarios en la
Escuela Militar de Ingeniera razn por la cual los docentes y/o estudiantes podrn observar
sus horarios de clases adems de que tambin los jefes de carrera podrn administrar su
malla curricular segn sea el caso dado, horarios, clases, das, etc. siendo esta herramienta
muy utilizada en varios mbitos de la malla curricular
1.6.3 Justificacin social
El proyecto realizado no solo servir para Escuela Militar de Ingeniera sino para otras
instituciones de Educacin, por supuesto realizando algunos cambios segn las reglas de la
institucin.
Es un proyecto basado en la implementacin sencilla de cambios en el horario y malla
curricular segn sea el caso, socialmente es muy til dado que puede ser utilizado en cualquier
mbito educativo con algunos pequeos cambios en las materias y/u horarios.
Est diseado para ser flexible frente a las exigencias del usuario final.


4

1.7 Alcances
Los alcances del sistema gestor comprenden el anlisis, diseo y desarrollo del sistema para la
gestin de Mallas curriculares que abarca los siguientes mdulos:
Gestin de Usuarios
Interfaz con el sistema de registro del personal (Privilegiado) encargado de la gestin de
las mallas curriculares.
Interfaz con el sistema de registro del personal (Docente) encargado de la gestin del
contenido curricular de las materias dictadas y los horarios de evaluacin.

Edicin y Evaluacin de la Malla Curricular
Evaluacin y Edicin de la malla curricular
Evaluacin y Edicin de las horas por materia asignada
Evaluacin y Edicin del personal docente a cargo por las materias existentes en la
malla curricular
Edicin y Evaluacin de las Materias
Evaluacin y edicin del contenido y de los tipos de clases (Teora, Prctica o
Laboratorio) a cursar en una Carrera dictada por uno o ms docentes.

Como contenido extra (an considerndose debido al escaso tiempo y la inclusin de nuevos
costos) se tiene en consideracin la edicin y evaluacin de los horarios de clases para los
distintos semestres.

5

CAPTULO II: ESTUDIO DE FACTIBILIDAD
2.1 Factibilidad tcnica
Para poder realizar la factibilidad tcnica a cabalidad se requiere de la siguiente tabla de
necesidades tcnicas
Tabla 1
SQL Server Express 2008
Visual Studio 2010
Fuente: Elaboracin Propia
2.1.1 Requerimientos del Software
Tabla 2
Software Requerimientos
Sistema operativo Windows XP o superior
Software Base de datos SQL Server Express
Software Lenguaje del Mtodo Visual Basic .NET
Fuente: Elaboracin Propia

2.2 Factibilidad operativa
Los usuarios finales deben ser capaces de poder utilizar el software segn las necesidades que
ellos requieran para esto el software desarrollado debe ser sencillo de operar, lo podrn utilizar
tanto usuarios expertos como novatos teniendo una seccin dedicada, como un manual o gua
de usuario especficamente para esta tarea tanto implementada en la misma pgina como en
una pgina wiki en la red la cual proporcionara como utilizar el software desarrollado de una
manera sencilla y eficiente.

6

2.3 Factibilidad econmica
Tabla 3
Costos de Software para el PC a utilizar (en Bs.)
Detalle Producto Precio Cantidad Precio Total
Sistema Operativo Windows XP o
Superior
1035 Bs. 1 1035 Bs.
SGBD SQL Server 207 Bs. 1 207 Bs.
Lenguaje de
programacin de
Interfaces
Visual Studio
2010
875 Bs. 1 875 Bs.
Servidor de BD SQL SQL Server 207 Bs. 2 207 Bs.
Total 2117 Bs.
Fuente: Elaboracin Propia
Tabla 4
Costos de Hardware para el PC a utilizar (en $us.)
Detalle Producto Precio Unitario Cantidad Precio Total
Microprocesador Micro. intelpentium
dual core g620,
lga 1155, 2.6 ghz,
3MB l2, 64 bit, in
box
53 $us. 1 53 $us.
RAM PC3-10600 DDR3,
1333 MHz 8Gb
90 $us. 2 180 $us.
Tarjeta Madre Intel LGA1155
DH67BL
108 $us. 1 108 $us.
Lector de DVD- LG DH16NS10 12 $us. 1 12 $us.
7

ROM
Disco Duro IbmHddSas
40k1044 146gb
15k Rpm 3.5 Hot-
swap
124 $us. 2 248 $us.
Monitor LCD Samsung
SyncMaster
B1940W 19
55 $us. 1 55 $us.
Total 656 $us.
Fuente: Elaboracin Propia

Tabla 5
Costos de Perifricos (en $us)
Detalle Producto Precio Unitario Cantidad Precio Total
Impresora Canon Pixma
MP450
350 Bs. 1 350 Bs.
Teclado Genius Logitech
600
70 Bs. 1 70 Bs.
Mouse Genius Micro 330
LS
50 Bs. 1 50 Bs.
Total 470 Bs.
Fuente: Elaboracin Propia
Tabla 6
Costo Total Factibilidad Tcnica
Software para el Servidor 2117 Bs.
8

Costo




Fuente: Elaboracin Propia

Factibilidad operativa:

Tabla 7
Costo: Capacitacin
Usuario Nva.
Capacitacin
Horas de
Capacitacin
Precio por
hora
Precio total
Secretaria Manejo del
Sistema
2 0 $us 0 $us
Total 0 $us
[Fuente]Elaboracin Propia

Tabla 8




[Fuente]Elaboracin Propia

Hardware para el Servidor 4526.40 Bs.
Perifricos 470 Bs.
Total 7113.4 bs
Costo Total Factibilidad Operativa
Costo: Capacitacin 0 $us
Total 0 $us
9



Costo Total del Proyecto:

Costo Total Factibilidad Tcnica + Costo Total Factibilidad Operativa

1030.92 $us + 0 $us = 1030.92 + (11 $us anuales)
2.4 Costo de desarrollo de software COCOMO
Para el proyecto en cuestin se utilizara para la estimacin del costo de desarrollo de
software el modelo Cocomo las formulas utilizadas para la estimacin son las
siguientes:
E = Esfuerzo = a KLDC
e
* FAE (persona x mes)
T = Tiempo de duracin del desarrollo = c Esfuerzo
d
(meses)
P= Personal = E/T (personas)
Tabla 9
Componente Bajo Medio Alto Total
Entradas 3 4 0 7
Salidas 8 5 7 20
Consultas 0 4 6 10
Archivos 28 30 0 58
Interfaces 50 28 10 88
183
[Fuente]Elaboracin Propia
PFA=PFSA* (0.65 + (0.01*ACT))
10

PFA=183* (0.65 + (0.01*32))

Puntos de Funcin Ajustados=177.5

KLDC = (PF * Lneas de cdigo por cada PF)/1000
= (177.5*32)/1000 = 5.7 KDLC

Se tomara el tipo orgnico ya que el numero de KDLC es menor a 50 KDLC, para hallar
el FAE (persona x mes) se realizara el clculo en base conductores de costo.
Tabla 10
Conductores de coste Valoracin
Fiabilidad requerida del software 1.15
Tamao de la Base de Datos 1.16
Complejidad del producto 0.85
Restricciones del tiempo de ejecucin 1.00
Restricciones del almacenamiento principal 1.00
Volatilidad de la Maquina virtual 1.00
Tiempo de respuesta del ordenador 1.07
Capacidad del analista 0.71
Experiencia en la aplicacin 1.00
Capacidad de los programadores 0.7
Experiencia en S.O. utilizado 1.00
Experiencia en el lenguaje de programacin 0.95
Practicas de programacin modernas 1.00
11

Utilizacin de herramientas software 0.91
Limitaciones de planificacin del proyecto 1.00
[Fuente]Elaboracin Propia

FAE=0.52129063

Clculo del esfuerzo del desarrollo:
E = a KLDC
e
* FAE = 3.2 * (5.7) ^1,05 * 0.52129063 = 10.37 personas/mes
Clculo tiempo de desarrollo:
T = c Esfuerzo
d
= 2,5 * (10.37) ^0,38 = 6 meses
Productividad:
PR = LDC/Esfuerzo = 5700/10.37 = 549.6 LDC/personas mes
Personal promedio:
P = E/T = 10.37/6 = 1.72 personas
Ser necesario un equipo de 2 personas trabajando alrededor de 6 meses, para realizar el
proyecto en el plazo establecido se deber optimizar el tiempo de LDC por mes.
Por el momento las 2 personas trabajan como analistas y programadores, siendo a su
vez un jefe de proyecto y el otro coordinador.
Para el costo Promedio tomamos un sueldo del personal por mes de 2000 Bs. Entonces
tenemos:
CD = T * P * S
CD = 6 * 1.72 * 2000 = 20640 Bs.
Como costos adicionales tenemos:
Impuesto al valor agregado
13% sobre el costo total del desarrollo de software
IVA=CD*0.13=20640*0.13=2683.2 Bs.
12

Impuesto a las transacciones
3% sobre el costo total de desarrollo de software
IT=CD*0.03=20640*0.03=619.2 Bs.
AFP
14.5 % sobre el costo total de desarrollo de software
AFP=CD*0.145=20640*0.145=2992.8 Bs.
El costo total de implantacin del software se genera a travs de la formula:

Costo Hadware/software + Costo desarrollo + IVA + IT + AFP
15115+ 20640+2683.2 +619.2 +2992.8 = 42050.2 Bs.
Por lo tanto, el costo total del proyecto para el cliente es de 42050.2 Bs.

13

CAPTULO III: MARCO TERICO

14

3.1 Ingeniera de Software
3.1.1 Introduccin
Este trmino fue introducido a finales de los 60 a raz de la crisis del software.
Esta crisis fue el resultado de la introduccin de la tercera generacin del hardware. El
hardware dejo de ser un impedimento para el desarrollo de la informtica; redujo los costos y
mejoro la calidad y eficiencia en el software producido La crisis se caracterizo por los siguientes
problemas: Imprecisin en la planificacin del proyecto y estimacin de los costos. Baja calidad
del software. Dificultad de mantenimiento de programas con un diseo poco estructurado, etc.
Por otra parte se exige que el software sea eficaz y barato tanto en el desarrollo como en la
compra. Tambin se requiere una serie de caractersticas como fiabilidad, facilidad de
mantenimiento y de uso, eficiencia, etc.
3.1.2 Objetivos de la Ingeniera de Software
En la construccin y desarrollo de proyectos se aplican mtodos y tcnicas para resolver los problemas,
la informtica aporta herramientas y procedimientos sobre los que se apoya la ingeniera de software.
Mejorar la calidad de los productos de software aumentar la productividad y trabajo de los ingenieros del
software. Facilitar el control del proceso de desarrollo de software. Suministrar a los desarrolladores las
bases para construir software de alta calidad en una forma eficiente. Definir una disciplina que garantice
la produccin y el mantenimiento de los productos software desarrollados en el plazo fijado y dentro
del costo estimado. Objetivos de los proyectos de sistemas Para que los objetivos se cumplan
las empresas emprenden proyectos por las siguientes razones: "Las cinco C " Capacidad Las actividades
de la organizacin estn influenciadas por la capacidad de sta para procesar transacciones con rapidez
y eficiencia. Los sistemas de informacin mejoran esta capacidad en tres formas. * Aumentan
la velocidad de procesamiento: Los sistemas basados en computadora pueden ser de ayuda para
eliminar la necesidad de clculos tediosos y comparaciones repetitivas. Un sistema automatizado puede
ser de gran utilidad si lo que se necesita es un procesamiento acelerado. *Aumento en el volumen: La
incapacidad para mantener el ritmo de procesamiento no significa el abandono de los procedimientos
existentes. Quiz stos resulten inadecuados para satisfacer las demandas actuales. En estas
situaciones el analista de sistemas considera el impacto que tiene la introduccin de procesamiento
computarizado, si el sistema existente es manual. Es poco probable que nicamente el aumento de la
velocidad sea la respuesta. El tiempo de procesamiento por transaccin aumenta si se considera la
cantidad de actividades comerciales de la empresa junto con su patrn de crecimiento.
* Recuperacin ms rpida de la informacin: Las organizaciones almacenan grandes cantidades
de datos, por eso, debe tenerse en cuenta donde almacenarlos y como recuperarlos cuando se los
necesita. Cuando un sistema se desarrolla en forma apropiada, se puede recuperar en forma rpida la
informacin.
15

* Vigilancia de los costos:
Para determinar si la compaa evoluciona en la forma esperada, de acuerdo con lo presupuestado, se
debe llevar a cabo el seguimiento de los costos de mano de obra, bienes y gastos generales. La
creciente competitividad del mercado crea la necesidad de mejores mtodos para seguir los costos y
relacionarlos con la productividad individual y organizacional.
* Reduccin de costos:
Los diseos de sistemas ayudan a disminuir los costos, ya que toman ventaja de las capacidades
de clculo automtico y de recuperacin de datos que estn incluidos en procedimientos de programas
en computadora. Muchas tareas son realizadas por programas de cmputo, lo cual deja un nmero muy
reducido de stas para su ejecucin manual, disminuyendo al personal.
*Mayor seguridad de informacin:
Algunas veces el hecho de que los datos puedan ser guardados en una forma adecuada para
su lectura por medio de una mquina, es una seguridad difcil de alcanzar en un medio ambiente donde
no existen computadoras.
Para aumentar la seguridad, generalmente se desarrollan sistemas de informacin automatizados. El
acceso a la informacin puede estar controlado por un complejo sistemas de contraseas, limitado a
ciertas reas o personal, si est bien protegido, es difcil de acceder.
*Menor margen de error: (mejora de la exactitud y la consistencia)
Esto se puede lograr por medio del uso de procedimientos de control por lotes, tratando de que siempre
se siga el mismo procedimiento. Cada paso se lleva a cabo de la misma manera, consistencia y con
exactitud: por otra parte se efectan todos los pasos para cada lote de transacciones. A diferencia del ser
humano, el sistema no se distrae con llamadas telefnicas, ni olvidos e interrupciones que sufre el ser
humano. Si no se omiten etapas, es probable que no se produzcan errores. Comunicacin La falta
de comunicacin es una fuente comn de dificultades que afectan tanto a cliente como a empleados. Sin
embargo, los sistemas de informacin bien desarrollados amplan la comunicacin y facilitan
la integracin de funciones individuales.


* Interconexin: (aumento en la comunicacin)
16

Muchas empresas aumentan sus vas de comunicacin por medio del desarrollo de redes para este fin,
dichas vas abarcan todo el pas y les permiten acelerar el flujo de informacin dentro de sus oficinas y
otras instalaciones que no se encuentran en la misma localidad. Una de las caractersticas ms
importantes de los sistemas de informacin para oficinas es la transmisin electrnica de informacin,
como por ejemplo, los mensajes y los documentos.
* Integracin de reas en las empresas:
Con frecuencia las actividades de las empresas abarcan varias reas de la organizacin, la informacin
que surge en un rea se necesita en otra rea, por ejemplo. Los sistemas de informacin ayudan a
comunicar los detalles del diseo a los diferentes grupos, mantienen las especificaciones esenciales en
un sitio de fcil acceso y calculan factores tales como el estrs y el nivel de costos a partir de detalles
proporcionados por otros grupos.
3.1.3 Competitividad
Los sistemas de informacin computacionales son un arma estratgica, capaz de cambiar la forma en
que la compaa compite en el mercado, en consecuencia stos sistemas mejoran la organizacin y la
ayudan a ganar "ventaja competitiva", sin embargo, si los competidores de la compaa tienen
capacidades mas avanzadas para el procesamiento de informacin, entonces los sistemas de
informacin pueden convertirse en una "desventaja competitiva". Una organizacin puede ganar ventaja
competitiva a travs de sus sistemas de informacin de diferentes formas.
* Asegurar clientes:
Como los clientes son los ms importante para una organizacin, los directivos buscan diferentes formas
para conseguir nuevos clientes y mantener los que tienen. Para eso las empresas proporcionan:
1- Mejores precios
2- Servicios exclusivos.
3- Productos diferentes.
La ventaja en precios se observa continuamente en la actividad comercial (s el producto es exclusivo o
distinto entonces tener el liderazgo en precios bajos quizs no sea el objetivo a alcanzar).
La estrategia eficaz de precios a menudo se alcanza al desarrollar sistemas de informacin por razones
tales como reduccin de costos y ganancia en la exactitud.

17

Generalmente cuando una compaa puede ofrecer servicios exclusivos y atraer clientes, es posible que
los competidores no sean capaces de atraer a los clientes de la compaa.
* Dejar fuera a los competidores:
Pasar sobre los competidores puede ser un inconveniente si ellos se encuentran la forma para duplicar
los logros de la compaa, los sistemas de informacin pueden ser la base para dejar fuera del mercado
a la competencia ya sea el disuadir sus intentos por ingresar al mercado o crendoles obstculo para su
entrada.
*Mejores acuerdos con los proveedores:
En los negocios, los proveedores tambin tienen importancia estratgica. Una manera de utilizar los
sistemas de informacin para favorecer arreglos con los proveedores es ofreciendo un mejor precio.
Disminuyendo los costos.
*Formar bases para nuevos productos
Los sistemas de informacin tambin forman la base de muchos productos y servicios nuevos. Los
servicios de base de datos experimentan un crecimiento comn en todas las industrias.
Productos que van desde programas personales hasta planes de construccin pueden hacerse a la
medida del cliente gracias al procesamiento de informacin.
Una cosa es clara, es necesario que los sistemas entren en operacin y que trabajen de manera
confiable.
3.1.4 Estrategias para su desarrollo

Los sistemas de informacin basados en computadoras sirven para diversas finalidades que van desde
el procesamiento de las transacciones de una empresa hasta proveer de la informacin necesaria para
decidir sobre asuntos que se presentan con frecuencia. En algunos casos los factores que deben
considerarse en un proyecto de sistema de informacin, como el aspecto ms apropiado de la
computadora o la tecnologa de comunicaciones que se va a utilizar, el impacto del nuevo sistema sobre
los empleados de la empresa y las caractersticas especficas que el sistema debe tener se pueden
determinar de manera secuencial. Todas estas situaciones estn determinadas por tres mtodos bsicos:


18


3.1.5 Mtodo del ciclo de vida clsico
El mtodo del ciclo de vida para 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 las siguientes actividades:
1) Investigacin preliminar
La solicitud para recibir ayuda de un sistema de informacin pueden originarse por una persona, cuando
se formula la solicitud comienza la primera actividad del sistema. Esta actividad tiene tres partes:
*Aclaracin de la solicitud
Antes de considerar cualquier investigacin de sistemas, la solicitud de proyecto debe examinarse para
determinar con precisin lo que el solicitante desea; ya que muchas solicitudes que provienen de
empleados y usuarios no estn formuladas de manera clara.
*Estudio de factibilidad
En la investigacin preliminar un punto importante es determinar que el sistema solicitado sea factible.
Existen tres aspectos relacionados con el estudio de factibilidad, que son realizados por los general por
analistas capacitados o directivos:
-Factibilidad tcnica.
Estudia si el trabajo para el proyecto, puede desarrollarse con el software y el personal existente, y si en
caso de necesitar nueva tecnologa, cuales son las posibilidades de desarrollarla (no solo el hardware).
-Factibilidad econmica.
Investiga si los costos se justifican con los beneficios que se obtienen, y si se ha invertido demasiado,
como para no crear el sistema si se cree necesario.
-Factibilidad operacional:
Investiga si ser utilizado el sistema, si los usuarios usaran el sistema, como para obtener beneficios.
* Aprobacin de la solicitud
Algunas organizaciones reciben tantas solicitudes de sus empleados que slo es posible atender unas
cuantas. Sin embargo, aquellos proyectos que son deseables y factibles deben incorporarse en los
planes. En algunos casos el desarrollo puede comenzar inmediatamente, aunque lo comn es que los
19

miembros del equipo de sistemas estn ocupados en otros proyectos. Cuando esto ocurre, la
administracin decide que proyectos son los ms importantes y el orden en que se llevarn a cabo.
Despus de aprobar la solicitud de un proyecto se estima su costo, el tiempo necesario para terminarlo y
las necesidades de personal

2) Determinacin de los requisitos del sistema.
Los analistas, al trabajar con los empleados y administradores, deben estudiar los procesos de una
empresa para dar respuesta a ciertas preguntas claves.
Para contestar estas preguntas, el analista conversa con varias personas para reunir detalles
relacionados con los procesos de la empresa. Cuando no es posible entrevistar, en forma personal a los
miembros de grupos grandes dentro de la organizacin, se emplean cuestionarios para obtener esta
informacin.
Las investigaciones detalladas requieren el estudio de manuales y reportes, la observacin en
condiciones reales de las actividades del trabajo y, en algunas ocasiones, muestras de formas y
documentos con el fin de comprender el proceso en su totalidad.
Reunidos los detalles, los analistas estudian los datos sobre requerimientos con la finalidad de identificar
las caractersticas que debe tener el nuevo sistema.
3) Diseo del sistema (diseo lgico)
El diseo de un sistema de informacin responde a la forma en la que el sistema cumplir con los
requerimientos identificados durante la fase de anlisis.
Es comn que los diseadores hagan un esquema del formato o pantalla que esperan que aparezca
cuando el sistema est terminado, se realiza en papel o en la pantalla de una terminal utilizando algunas
de las herramientas automatizadas disponibles para el desarrollo de sistemas.
Tambin se indican los datos de entrada, los que sern calculados y los que deben ser almacenados.
Los diseadores seleccionan las estructuras de archivo y los dispositivos de almacenamiento. Los
procedimientos que se escriben indican cmo procesar los datos y producir salidas.
Los documentos que contienen las especificaciones de diseo representan a ste mediante diagramas,
tablas y smbolos especiales.
La informacin detallada del diseo se proporciona al equipo de programacin para comenzar la fase de
desarrollo de software.
20

Los diseadores son responsables de dar a los programadores las especificaciones de software
completas y claramente delineadas.
4) Desarrollo de software (diseo fsico).
Los encargados de desarrollar software pueden instalar software comprado 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.
Los programadores son responsables de la documentacin de los programas y de explicar
su codificacin, esta documentacin es esencial para probar el programa y hacer el mantenimiento.
5) Prueba de sistemas.
Durante esta fase, el sistema se emplea de manera experimental para asegurarse 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 conjuntos de datos de prueba para su procesamiento
y despus se examinan los resultados. En ocasiones se permite que varios usuarios utilicen el sistema,
para que los analistas observen si tratan de emplearlo en formas no previstas, antes de que la
organizacin implante el sistema y dependa de l.
En muchas organizaciones, las pruebas son conducidas por personas ajenas al grupo que escribi los
programas originales; para asegurarse de que las pruebas sean completas e imparciales y, por otra, que
el software sea ms confiable.
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.
Cada estrategia de implantacin tiene sus mritos de acuerdo con la situacin que se considere dentro
de la empresa. Sin importar cul sea la estrategia utilizada, los encargados de desarrollar el sistema
procuran que el uso inicial del sistema se encuentre libre de problemas.
Los sistemas de informacin deben mantenerse siempre al da, la implantacin es un proceso de
constante evolucin.
La evaluacin de un sistema se lleva a cabo para identificar puntos dbiles y fuertes. La evaluacin
ocurre a lo largo de cualquiera de las siguientes dimensiones:
Evaluacin operacional.- Valoracin de la forma en que funciona el sistema, incluyendo su
facilidad de uso, tiempo de respuesta, lo adecuado de los formatos de informacin,
confiabilidad global y nivel de utilizacin.
21

Impacto organizacional.- Identificacin y medicin de los beneficios para la organizacin en
reas como finanzas (costos, ingresos y ganancias), eficiencia operacional e impacto
competitivo.
- Opinin de los administradores
Evaluacin de las actitudes de directivos y administradores dentro de la organizacin as como de los
usuarios finales.
RUP:Rational Unified Process
Las siglas RUP en ingles significa Rational Unified Process (Proceso Unificado de Rational) es un
producto del proceso de ingeniera de software que proporciona un enfoque disciplinado para asignar
tareas y responsabilidades dentro de una organizacin del desarrollo. Su meta es asegurar la produccin
del software de alta calidad que resuelve las necesidades de los usuarios dentro de un presupuesto y
tiempo establecidos
1.1.1. Dimensiones del RUP
El RUP tiene dos dimensiones:
El eje horizontal representa tiempo y demuestra los aspectos del ciclo de vida del proceso.
El eje vertical representa las disciplinas, que agrupan actividades definidas lgicamente por la
naturaleza.
La primera dimensin representa el aspecto dinmico del proceso y se expresa en trminos de fases, de
iteraciones, y la finalizacin de las fases. La segunda dimensin representa el aspecto esttico del
proceso: cmo se describe en trminos de componentes de proceso, las disciplinas, las actividades, los
flujos de trabajo, los artefactos, y los roles.2 En la figura 1 se puede observar como vara el nfasis de
cada disciplina en un cierto plazo en el tiempo, y durante cada una de las fases. Por ejemplo, en
iteraciones tempranas, pasamos ms tiempo en requerimientos, y en las ltimas iteraciones pasamos
ms tiempo en poner en prctica la realizacin del proyecto en si.
1.1.2. Fases
Figura 2. Fases del RUP
El ciclo de vida del software del RUP se descompone en cuatro fases secuenciales (figura 2). En cada
extremo de una fase se realiza una evaluacin (actividad: Revisin del ciclo de vida de la finalizacin de
22

fase) para determinar si los objetivos de la fase se han cumplido. Una evaluacin satisfactoria permite
que el proyecto se mueva a la prxima fase.
Planeando las fases
El ciclo de vida consiste en una serie de ciclos, cada uno de los cuales produce una nueva versin del
producto, cada ciclo est compuesto por fases y cada una de estas fases est compuesta por un nmero
de iteraciones, estas
fases son:
1. Concepcin, Inicio o Estudio de oportunidad
Define el mbito y objetivos del proyecto Se define la funcionalidad y capacidades del producto
2. Elaboracin
Tanto la funcionalidad como el dominio del problema se estudian en profundidad Se define una
arquitectura bsica Se planifica el proyecto considerando recursos disponibles
3. Construccin
El producto se desarrolla a travs de iteraciones donde cada iteracin involucra tareas de anlisis,
diseo e implementacin Las fases de estudio y anlisis slo dieron una arquitectura bsica que es aqu
refinada de manera incremental conforme se construye (se permiten cambios en la estructura)
Gran parte del trabajo es programacin y pruebas
Se documenta tanto el sistema construido como el manejo del mismo
Esta fase proporciona un producto construido junto con la documentacin
4. Transicin
Se libera el producto y se entrega al usuario para un uso real
Se incluyen tareas de marketing, empaquetado atractivo, instalacin, configuracin, entrenamiento,
soporte, mantenimiento, etc.
Los manuales de usuario se completan y refinan con la informacin anterior
Estas tareas se realizan tambin en iteraciones
23

Todas las fases no son idnticas en trminos de tiempo y esfuerzo.
Aunque esto vara considerablemente dependiendo del proyecto, un ciclo de desarrollo inicial tpico para
un proyecto de tamao mediano debe anticipar la distribucin siguiente el esfuerzo y horario:
Concepcin Elaboracin Construccin Transicin
Esfuerzo ~5 % 20 % 65 % 10%
Horario 10 % 30 % 50 % 10%
Lo cul se puede representar grficamente como se muestra en la figura 3:
En un ciclo evolutivo, las fases de concepcin y elaboracin seran considerablemente ms pequeas.
Algunas herramientas que pueden automatizar una cierta porcin del esfuerzo de la fase de
Construccin pueden atenuar esto, haciendo que la fase de construccin sea mucho ms pequea que
las fases de concepcin y elaboracin juntas. Este es precisamente el objetivo del trabajo.
Proceso Iterativo e Incremental
Este proceso se refiere a la realizacin de un ciclo de vida de un proyecto y se basa en la evolucin de
prototipos ejecutables que se muestran a los usuarios y clientes. En este ciclo de vida iterativo a cada
iteracin se reproduce el ciclo de vida en cascada a menor escala, estableciendo los objetivos de una
iteracin en funcin de la evaluacin de las iteraciones precedentes y las actividades se encadenan en
una mini-cascada con un alcance limitado por los objetivos de la iteracin. En la figura 7 se muestran los
pasos a realizar para seguir el ciclo de vida iterativo incremental, hasta la realizacin de una fase.
Ciclo de vida Iterativo incremental
Para la realizacin de cada iteracin se tiene que tomar en cuenta la planificacin de la iteracin,
estudiando los riesgos que conlleva su realizacin, tambin incluye el anlisis de los casos de uso y
escenarios, el diseo de opciones arquitectnicas, la codificacin y pruebas, la integracin gradual
durante la construccin del nuevo cdigo con el existente de iteraciones anteriores, la evaluacin de la
entrega ejecutable (evaluacin del prototipo en funcin de las pruebas y de los criterios definidos) y la
preparacin de la entrega (documentacin e instalacin del prototipo). Algunos de estos elementos no se
realizan en todas las fases.
A continuacin se presenta una comparacin entre 2 enfoques de un ciclo de vida del desarrollo de
software, el primero consiste en el ciclo comn, el de Cascada (figura 8), en el cual cada disciplina se
realiza al finalizar su predecesora y solo al finalizar la nueva se empieza la sucesora y as hasta terminar
con las disciplinas necesarias.
24

En la figura siguiente se muestra el ciclo de vida de un software siguiendo el enfoque Iterativo
Incremental (utilizado por el RUP), en el cual se puede observar que en cada iteracin se realiza una
pequea parte de cada disciplina en paralelo, aumentando as poco a poco hasta concluir con la
realizacin de todas las disciplinas con un numero de iteraciones prudente. En la grfica siguiente se
habla de ingeniera del negocio y en la siguiente seccin de modelado del negocio, es necesario
conservar la consistencia de esto en todo el trabajo, una u otra.
Ciclo de vida de un software con un enfoque iterativo incremental
Disciplinas
Las disciplinas conllevan los flujos de trabajo, los cuales son una secuencia de pasos para la culminacin
de cada disciplina, estas disciplinas se dividen en dos grupos: las primarias y las de apoyo. Las primarias
son las necesarias para la realizacin de un proyecto de software, aunque para proyectos no muy
grandes se pueden omitir algunas; entre ellas se tienen:
Modelado del Negocio, Requerimientos, Anlisis y Diseo, Implementacin, Pruebas, Despliegue. Las de
apoyo son las que como su nombre lo indica sirven de apoyo a las primarias y especifican otras
caractersticas en la realizacin de un proyecto de software; entre estas se tienen: Entorno, Gestin del
Proyecto, Gestin de Configuracin y Cambios. A continuacin se describe rpidamente cada una de
estas disciplinas.
Modelado del negocio
Esta disciplina tiene como objetivos comprender la estructura y la dinmica de la organizacin,
comprender problemas actuales e identificar posibles mejoras, comprender los procesos de negocio.
Utiliza el Modelo de CU del Negocio para describir los procesos del negocio y los clientes, el Modelo de
Objetos del Negocio para describir cada CU del Negocio con los Trabajadores, adems utilizan los
Diagramas de Actividad y de Clases.
Requerimientos
Esta disciplina tiene como objetivos establecer lo que el sistema debe hacer (Especificar Requisitos),
definir los lmites del sistema, y una interfaz de usuario, realizar una estimacin del costo y tiempo de
desarrollo. Utiliza el Modelo de CU para modelar el Sistema que comprenden los CU, Actores y
Relaciones, adems utiliza los diagramas de Estados de cada CU y las especificaciones suplementarias.
Anlisis y diseo
25

Esta disciplina define la arquitectura del sistema y tiene como objetivos trasladar requisitos en
especificaciones de implementacin, al decir anlisis se refiere a transformar CU en clases, y al decir
diseo se refiere a refinar el anlisis para poder implementar los diagramas de clases de anlisis de cada
CU, los diagramas de colaboracin de de cada CU, el de clases de diseo de cada CU, el de secuencia
de diseo de CU, el de estados de las clases, el modelo de despliegue de la arquitectura.
Implementacin
Esta disciplina tiene como objetivos implementar las clases de diseo como componentes (ej. fichero
fuente), asignar los componentes a los nodos, probar los componentes individualmente, integrar los
componentes en un sistema ejecutable (enfoque incremental). Utiliza el Modelo de Implementacin,
conjuntamente los Diagramas de Componentes para comprender cmo se organizan los Componentes y
dependen unos de otros.
Pruebas
Esta disciplina tiene como objetivos verificar la integracin de los componentes (prueba de integracin),
verificar que todos los requisitos han sido implementados (pruebas del sistema), asegurar que los
defectos detectados han sido resueltos antes de la distribucin
Despliegue
Esta disciplina tiene como objetivos asegurar que el producto est preparado para el cliente, proceder a
su entrega y recepcin por el cliente. En esta disciplina se realizan las actividades de probar el software
en su entorno final (Prueba Beta), empaquetarlo, distribuirlo e instalarlo, as como la tarea de ensear al
usuario.
Gestin y configuracin de cambios
Es esencial para controlar el nmero de artefactos producidos por la cantidad de personal que trabajan
en un proyecto conjuntamente. Los controles sobre los cambios son de mucha ayuda ya que evitan
confusiones costosas como la compostura de algo que ya se haba arreglado etc., y aseguran que los
resultados de los artefactos no entren en conflicto con algunos de los siguientes tipos de problemas:
Actualizacin simultnea: Es la actualizacin de algo elaborado con anterioridad, sin saber que alguien
ms lo est actualizando.
Notificacin limitada: Al realizar alguna modificacin, no se deja informacin sobre lo que se hizo, por lo
tanto no se sabe quien, como, y cuando se hizo.
26

Versiones mltiples: No saber con exactitud, cual es la ltima versin, y al final no se tiene un orden
sobre que modificaciones se han realizado a las diversas versiones.
Gestin del proyecto
Su objetivo es equilibrar los objetivos competitivos, administrar el riesgo, y superar restricciones para
entregar un producto que satisface las necesidades de ambos clientes con xito (los que pagan el
dinero) y los usuarios. Con la Gestin del Proyecto se logra una mejora en el manejo de una entrega
exitoso de software. En resumen su propsito consiste en proveer pautas para:
Administrar proyectos de software intensivos.
Planear, dirigir personal, ejecutar acciones y supervisar proyectos.
Administrar el riesgo.
Sin embargo, esta disciplina no intenta cubrir todos los aspectos de direccin del proyecto. Por ejemplo,
no cubre problemas como:
Administracin de personal: contratando, entrenando, enseando.
Administracin del presupuesto: definiendo, asignando.
Administracin de los contratos con proveedores y clientes.
Entorno
Esta disciplina se enfoca sobre las actividades necesarias para configurar el proceso que engloba el
desarrollo de un proyecto y describe las actividades requeridas para el desarrollo de las pautas que
apoyan un proyecto.
Su propsito es proveer a la organizacin que desarrollar el software, un ambiente en el cual basarse,
el cual provee procesos y herramientas para poder desarrollar el software.

MPR: Metodologa de Prototipado Rpido

Definicin de MPR
La Metodologa de Prototipado Rpido, MPR, est orientada al desarrollo de prototipos y
fuertemente apoyada en tecnologa de Bases de Datos y herramientas visuales para Desarrollo
Orientado a Objetos. En MPR se concentra un gran esfuerzo en la involucracin del Usuario en
27

dos fases fundamentales: la definicin del problema que se va a abordar y en la ejecucin de
las pruebas, donde adems se potencia el uso de lenguajes de cuarta generacin utilizados
como lenguajes de consulta para verificar la estructura y funcionalidad del prototipo
desarrollado, asegurndose de que su diseo responde a las definiciones especificadas.

Como se ha expuesto, la idea fundamental de MPR es el desarrollo de prototipos. Un prototipo
es un modelo inicial de lo que al final se corresponder con la Base de Datos definitiva y sus
procedimientos asociados. Este prototipo se someter a pruebas para comprobar su
funcionalidad, de las que surgirn modificaciones que darn origen a un segundo prototipo,
versin mejorada y posiblemente ampliada del primero, el cual se volver a probar,
repitindose sucesivamente el proceso hasta alcanzar el prototipo definitivo.

La responsabilidad y ejecucin de estas pruebas fundamentalmente recae, como ya se ha
mencionado, en el propio usuario, quien deber de comprobar que el prototipo resultante es
capaz de resolver todos los problemas planteados en el momento de la definicin de las
especificaciones del proyecto.

Representacin grfica de MPR
Para representar MPR en su mayor grado de abstraccin, se hace uso de un diagrama SADT
en el que se muestran las seis fases de las que se compone.

La simbologa empleada en el diagrama es la siguiente: cada una de las cajas representa algo
que hay que hacer, en este caso una fase de la Metodologa. A una caja pueden llegar flechas
por su lado izquierdo (entradas necesarias para ejecutar la fase), por su parte superior (causas
por las que se realiza una fase) y por su parte inferior (herramientas y tcnicas con las que se
hace lo indicado en la fase). Asimismo, por su parte derecha salen flechas que muestran algo
que se ha obtenido en la fase y que pasa normalmente a la fase siguiente o sale directamente
fuera del sistema, indicando un producto ya terminado y que no necesita ms procesos.

Desde cada fase de la Metodologa se puede volver a cualquiera de las fases anteriores. En el
diagrama SADT se han omitido voluntariamente estas conexiones para facilitar su estudio.
Fase 1: Definicin de especificaciones
Esta primera fase tiene por objeto auditar la informacin de relativa al problema, con el fin de
recabar todos los datos necesarios para su resolucin.

Como primera tarea podr ser necesario realizar un estudio de la viabilidad del proyecto, para
determinar y justificar la necesidad del mismo. A continuacin se har un anlisis previo con el
fin de establecer la amplitud y el calendario del proyecto, estimndose el esfuerzo necesario y
el tiempo de desarrollo, e identificando los procesos involucrados en el mismo.

A continuacin se construir un prototipo inicial, no necesariamente operativo, construyndose
macro modelos de actividad para cada uno de los procesos identificados en la actividad
anterior. La intencin es disponer de la informacin necesaria para recabar la aprobacin
necesaria para comenzar el desarrollo.

Se trata, en suma, de obtener la mayor cantidad de informacin posible sobre el problema que
se intenta resolver, para obtener un tiempo estimado de desarrollo del proyecto y sus costes
asociados, con el fin de obtener la aprobacin necesaria para llevarlo a cabo. Como final de
esta fase, y de todas las dems fases, se emitir un informe para la Direccin del Proyecto.
28


Fase 2: Diseo Conceptual
El objetivo de esta fase es construir un modelo de informacin que refleje el esquema
conceptual del prototipo. Es muy importante que este modelo est lo ms ajustado posible a la
realidad para que el diseo posterior de la Base de Datos pueda cumplir con sus objetivos.

Se realizarn entrevistas a los Usuarios y se estudiar y disear el primer prototipo operativo,
determinando sus puntos fuertes y sus puntos dbiles, y se documentarn todas sus
funcionalidades.

Tambin en esta fase se prepararn los planes de implantacin, formacin y pruebas, y se
desarrollar el Manual del Usuario y el Manual Tcnico.

Fase 3: Desarrollo del Prototipo
Como su nombre indica, esta fase tiene por objeto la construccin del primer prototipo
operativo de la Aplicacin.

Esta fase consta de dos actividades principales, una de desarrollo tcnico propiamente dicho y
otra para desarrollar la documentacin asociada.

Al finalizar esta fase se dispondr de un prototipo totalmente funcional y operativo, que ser
sometido a mltiples pruebas en la siguiente fase para comprobar su validez.

Fase 4: Pruebas del Usuario
En esta fase se realizarn todas las pruebas necesarias para validar el prototipo desarrollado
en la fase anterior. Si como resultado de estas pruebas se detectara la necesidad de modificar
el prototipo, para corregir defectos o para aadirle funcionalidad, se volver a la fase anterior y
se realizarn todas las iteraciones necesarias hasta que el Usuario se sienta satisfecho con el
prototipo, y compruebe que responde a las especificaciones que se haban alcanzado
inicialmente.

Las pruebas en esta fase pueden ser de dos tipos: pruebas dirigidas, donde los desarrolladores
guan y asesoran al usuario durante las mismas, y pruebas no dirigidas, donde el Usuario acta
libremente y sin la presencia de los desarrolladores.

Fase 5: Implantacin
En esta fase se ejecutar el Plan de Formacin de los Usuarios y se llevar a cabo el proceso
de migracin al entorno de ejecucin real de la aplicacin. Una vez completada la migracin, se
realizarn las pruebas finales y se llevarn a cabo las actividades correctoras finales,
revisndose de paso toda la documentacin del proyecto.

Como final de esta fase se deber de obtener la aceptacin del Usuario y se emitir un informe
para la Direccin del Proyecto.

29

Fase 6: Auditora y Seguimiento
La ltima de las fases de MPR consiste en realizar una Auditora del rendimiento y la calidad de
la Aplicacin, y de determinar y canalizar los mecanismos necesarios para realizar peticiones
de modificacin y para que estas sean llevadas a cabo por los Equipos de Mantenimiento.

Se debern de identificar parmetros de rendimiento, compromisos de uso / respuesta, verificar
la calidad global de la aplicacin y efectuar las medidas correctoras oportunas. Como fin de
fase, se comprobar que toda la documentacin es la adecuada, y se obtendr la aprobacin
definitiva del Usuario.



















30


CAPTULO IV: INGENIERIA DEL PROYECTO

31

4.1 Plan de desarrollo de software segn MPR
Tabla 11
Fase Objetivo Tareas Entregables
Definicin de
especificaciones
Disear las pantallas del primer
prototipo no operativo para el
diseo de pantallas y logos.
Determinacin de los roles que
van ha desempear los usuarios
mediante una tabla de
determinacin de roles.
Se emitir un informe de esta fase
para analizar los resultados
obtenidos hasta el momento.
Diseo de pantallas


Identificacin de
roles de usuario


Revisin de fin de fase
Disear la interfaz de usuario
Diseo de Logos

Tabla de determinacin de
roles

Diseo
conceptual
Se realizara entrevistas a los
usuarios y se estudiara y diseara
el primer prototipo operativo,
determinando sus puntos fuertes y
puntos dbiles y se documentaran
todas sus funcionalidades.

En esta fase se prepararan los
planes de implantacin, formacin,
pruebas y se desarrollara el
manual del usuario y el manual
tcnico.

Se emitir un informe de esta fase
para analizar los resultados
obtenidos hasta el momento.
Entrevista a los
usuarios
Revisin del primer
prototipo

Planes de la
aplicacin

Revisin de fin de fase
Estudiar el Diseo del Primer
Prototipo Operativo
Determinar Puntos Fuertes /
Puntos Dbiles
Preparar el Manual del
Usuario y el Manual Tcnico
Desarrollo del Esta fase consta de dos Desarrollo tcnico Desarrollar el Prototipo
32

prototipo actividades principales, una de
desarrollo tcnico y otra para
desarrollar la documentacin
asociada.
Al finalizar esta fase se dispondr
de un prototipo totalmente
funcional y operativo.
Se emitir un informe de esta fase
para analizar los resultados
obtenidos hasta el momento

Desarrollo de la
documentacin


Revisin de fin de
fase
Operativo
Desarrollar Documentos de
Ayuda

Pruebas de
usuario
En esta fase se realizarn todas
las pruebas necesarias para
validar el prototipo desarrollado
en la fase anterior esto con el fin
de detectar la necesidad de
efectuar cambios en el prototipo o
para corregir defectos o aadir le
funcionalidades nuevas.

Se emitir un informe de esta fase
para analizar los resultados
obtenidos y obtener la aceptacin
del usuario
Pruebas dirigidas


Pruebas no dirigidas

Revisin del
prototipo


Revisin de fin de
fase
Ejecutar las pruebas
Documentar resultados
Documentar resultados
Afinar el Prototipo segn los
resultados de las pruebas
Documentar los cambios
realizados

Implantacin En esta fase se ejecutar el Plan
de Formacin de los Usuarios y se
migrara al entorno de ejecucin
real de la aplicacin.
Despus se realizarn las pruebas
finales y se llevarn a cabo las
actividades correctoras finales con
el fin de revisar paso a paso toda
la documentacin del proyecto.

Formacin de los
usuarios
Migracin a
produccin
Revisin de post-
implantacin
Revisin de fin de
fase
Migrar la aplicacin al entorno
de produccin
Efectuar pruebas finales
Realizar actividades
correctoras finales
Revisar la documentacin

33

4.2 Plan de desarrollo de software segn RUP
Tabla 12
Fase Flujos Objetivo Tareas Entregables
Inicio Modelado del
Negocio
Comprender la estructura y
la dinmica de la
organizacin, comprender
problemas actuales e
identificar posibles mejoras,
comprender los procesos
del sistema actual y los
propuestos por el cliente
final y los involucrados
Anlisis de la
interaccin de la malla
curricular con los
involucrados
Identificacin de
involucrados
Identificacin de
procesos del sistema
Resultados de las
entrevistas y las
visitas.
Tabla de
identificacin de
roles de los
involucrados
Diagrama de
paquetes del
modelado
Diagramas de flujo
de datos de los
procesos actuales


Requerimientos Esta disciplina tiene como
objetivos establecer lo que
el sistema debe hacer,
definir los lmites del
sistema a desarrollar, y una
interfaz de usuario.
Anlisis de la
situacin actual
Determinacin de
requerimientos

Divisin en mdulos

Tabla de
determinacin de
requerimientos
Tabla de
especificacin de
requerimientos
Elaboracin Anlisis Trasladar requisitos en
especificaciones de
implementacin
Anlisis del sistema
propuesto
Definicin de la
arquitectura del
Diagramas de
Casos de uso de
alto Nivel
Diagramas de
34

sistema Expandido
Diagrama de
Secuencia de
diseo
Diseo Diseo de Interfaces Diagrama de
Estados
Diagramas
Colaboracin
Diagrama de
actividades
Diagrama de Red
Diagrama E-R para
Base de Datos
Construccin Implementacin Implementar las clases de
diseo como componentes
asignar los
componentes a los
nodos,
probar los
componentes
individualmente,
integrar los
componentes en un
sistema ejecutable
Diagramas de
implementacin
Diagrama de
Componentes
Diagrama de
despliegue
Gua de Usuario
Pruebas Verificacin del correcto
funcionamiento del sistema
Verificacin de la
integracin de los
componentes
Verificacin de los
requisitos
implementados
Pruebas de
Integracin
Pruebas de sistema
Plan de Pruebas

35

Fase de Inicio
4.2.1.1 Resultados de las entrevistas y las visitas.
Como resultados de la entrevista tomada al jefe de carrera de sistemas se logro obtener
informacin
Respecto al problema principal:

Se requiere un sistema de informacin automatizado para administrar la malla curricular

Respecto al objetivo general:

Se requiere Desarrollar un sistema de gestin de malla curricular para la organizacin y
actualizacin de las mallas curriculares de las diferentes carreras

Respecto a los requisitos del sistema:

Se requiere un Registro de asignaturas de cada carrera a si mismo tambin que de
la opcin de poner los componentes de cada asignatura tales como ser teora,
practica, laboratorio y tambin las horas acadmicas para cada asignatura, y su
respectiva temario y biografa del contenido de las mismas.

Que muestre los prerrequisitos que deben cumplirse para poder cursar una
determinada asignatura y que muestre tambin las cargas horarias para teora,
laboratorio, prctica de cada asignatura.

Poder asignar a los docentes las asignaturas que dicta y muestre esta
informacin.

La entrevista se la puede encontraren la parte de ANEXOS

4.2.1.2 Tabla de identificacin de roles de los involucrados

Agente Tareas Posibles conflictos
Jefe de la unidad
acadmica
-Realiza en control de
todos los procesos
dentro de la institucin
-administra las tomas
de decisiones
generales de la
institucin
-realizar algunos cambios
dentro del pensum o
malla curricular
demasiado extravagantes
Jefe de carrera -Realiza control interno
de la carrera
-Toma decisiones
dentro del rea de la
carrera
- conflictos al momento
de realizar la
administracin del
sistema
-cambios extra del
36

sistema en ltima
instancia
Secretaria -Suministra las notas
de servicio
-Administra ciertas
tareas dentro de la
carrera
-conflictos al momento de
realizar la administracin
del sistema
Docentes -realizan la docimasia
dentro de la institucin
-proporcionan la
calificacin
-posibles conflictos con la
administracin de los
horarios de los docentes

4.2.1.3 Diagrama de paquetes del modelado
Para la realizacin de empaquetado se consideraron los mdulos anteriormente propuestos
(ver captulo I Alcances), construyendo as la siguiente divisin y el uso de los mismos.
Por otra parte, cabe considerar que este diagrama de paquetes es del sistema propuesto.

Evaluacin
Edicin
Control de Horas Por Materia
Malla
<<Access>>

<<Access>>
Registro de Usuario
Gestin de Cuentas
Usuarios

Evaluacin del contenido de
materia
Edicin del contenido por
materia

Materias
<<Access>>



37


4.2.2.1 Tabla de Determinacin de requerimientos
REF FUNCION TIPO
R.1
Gestin de malla curricular Evidente
R.2
Registro de tiempo de vigencia de malla curricular Evidente
R.3
Registro de asignaturas Evidente
R.4
Registro de componentes de la asignatura Evidente
R.5
Registro de horas acadmicas por asignatura Evidente
R.6
Control de los registros realizados Oculto
R.7
Contenido temtico de la asignatura Evidente
R.8
Bibliografa de contenido temtico de la asignatura Oculto
R.9
Prerrequisitos de la asignatura Oculto
R.10
Carga horaria de teora por semana de la asignatura Evidente
R.11
Carga horaria de laboratorio por semana de la asignatura Evidente
R.12
Carga horaria de prctica por semana de la asignatura Evidente
R.13
Registro de docentes Evidente
R.14
Registro de asignaturas que dicta el docente Evidente




38

4.2.2.2 Tabla de Especificacin de Requerimientos
REF REQUERIMIENTO ESPECIFICACION
R.1
Gestin de malla curricular El usuario debe ser capaz de
gestionar y disear una nueva
malla curricular cada cierto
tiempo determinado.
R.2
Registro de tiempo de vigencia de malla
curricular

El usuario debe ser capaz de
una vez almacenada cada
malla curricular poderle dar a
la misma un tiempo de
vigencia o valides en (desde
que ao es vlida hasta que
ao es vlida).
R.3
Registro de asignaturas

El usuario debe tener la
opcin de agregar nuevos
registros de nuevas
asignaturas y tambin de
borrar asignaturas que tendr
la malla curricular.
R.4
Registro de componentes de la asignatura

El usuario debe tener la
opcin de registrar los
componentes de cada una de
las asignaturas.
R.5
Registro de horas acadmicas por asignatura

El usuario debe tener la
opcin de registrar las horas
acadmicas designadas para
cada componente de cada
39

asignatura.
R.6
Control de los registros realizados

El sistema debe ser capaz de
controlar cada registro hecho
por el usuario y controlar la
integridad de los mismos.
R.7
Contenido temtico de la asignatura

El usuario debe tener la
opcin de agregar y modificar
el contenido temtico de cada
asignatura y as tener un
contenido bien organizado de
la temtica que debe
avanzar el docente que dicta
la asignatura.
R.8
Bibliografa de contenido temtico de la
asignatura

El usuario debe tener la
opcin de poder aadir y
modificar en un pequeo
espacio referido a la
bibliografa para el contenido
temtico de cada una de las
asignaturas.
R.9
Prerrequisitos de la asignatura El usuario del sistema debe
tener la opcin de poner los
prerrequisitos que debe
cumplir para poder cursar una
determinada asignatura.
R.10
Carga horaria de teora por semana de la
asignatura
El usuario debe poder colocar
la carga horaria semanal de
teora designada para una
40

determinada asignatura.
R.11
Carga horaria de laboratorio por semana de la
asignatura
El usuario debe poder colocar
la carga horaria semanal de
laboratorio designado para
una determinada asignatura.
R.12
Carga horaria de prctica por semana de la
asignatura
El usuario debe poder colocar
la carga horaria semanal de
prctica designada para una
determinada asignatura.
R.13
Registro de docentes

El usuario debe poder
registrar a los docentes que
ser capaz de registrar y
administrar las propiedades
de los nuevos docentes
R.14
Registro de asignaturas que dicta el docente El usuario debe poder
registrar la(s)asignaturas que
dicta un determinado docente

Fase de Elaboracin
41

4.2.3.1 Diagramas de Casos de uso de alto Nivel

Casos de uso: Sistemas de gestin de malla curricular
Actores: administrador, docente
Tipo: primario
Descripcin:




El sistema de gestin de malla curricular tiene como procesos la
gestin de malla curricular el cual abarca el registro de tiempo de
vigencia de malla curricular, tambin tiene el registro de docentes y
registro de asignaturas que dicta el docente, tambin tiene el registro
de asignaturas el cual est relacionado con los procesos de registro de
componentes de la asignatura, registro de horas acadmicas por
asignatura, contenido temtico de la asignatura y bibliografa del
contenido temtico.

uc Casos de uso de alto nivel gestion de malla curricular
GESTION DE MALLA CURRICULAR
GESTION DE MALLA
CURRICULAR
ADMINISTRADOR
El l mi te del si stema muestra l a
i nterfaz l gi ca entre usuari os y el
si stema que se descri be.
REGISTRO DE TIEMPO DE
VIGENCIA DE MALLA
CURRICULAR
DOCENTE
REGISTRO DE
COMPONENTES DE
LA ASIGNATURA
REGISTRO DE
ASIGNATURAS
REGISTRO DE HORAS
ACADEMICAS POR
ASIGNATURA
CONTENIDO
TEMATICO DE LA
ASIGNATURA
BIBLIOGRAFIA DEL
CONTENIDO
TEMATICO
REGISTRO DE
DOCENTES
REGISTRO DE
ASIGNATURAS QUE
DICTA EL DOCENTE
REGISTRO DE
USUARIOS
i ncl ude
extend
extend
i ncl ude
i ncl ude
i ncl ude
i ncl ude
42


4.2.3.3 Diagramas de Expansin


Diagrama de caso de uso expandido de registro de carreras



Diagrama de caso de uso expandido de registro de docentes

jefe de la unidad academica
se registra la nueva carrera
se agrega una nueva malla curricular de la nueva carrera
Nueva carrera
base de datos
<<extends>>
<<extends>>
jefe de carrera
se le asigna una cuenta
se le asigna materias a dictar
se registra los datos de los docentes
base de datos
<<extends>>
<<extends>>
validar datos
<<extends>>
43

4.2.3.4 Diagrama de Secuencia de diseo

44

CAPTULO V: CONCLUSIONES Y RECOMENDACIONES
5.1 Conclusiones
5.2 Recomendaciones
ANEXOS
Pegar aqu encuesta
Capturas de Pantalla Prototipo No Operativo

45




46

ANEXOS
ENTREVISTA
1. Cul es el problema principal para la gestin de malla curricular?
Rpta. La falta de un sistema de informacin automatizado para administrar la
malla curricular de forma efectiva y fcil.

2. segn usted cual es el objetivo general de la gestin de malla curricular?
Rpta. Desarrollar un sistema de gestin de malla curricular para la organizacin
y actualizacin de las mallas curriculares del las diferentes carreras de la E.M.I.

3. Qu funciones debera tener el sistema de gestin de malla curricular
principalmente?
Rpta. Debera tener la opcin de poder aadir carreras nuevas, dar la posibilidad
de aadir la pertenencia de a que aos pertenece la malla curricular.

4. Qu otra procesos debera poder dar el sistema de gestin de malla curricular?
Rpta. Que de las opciones de tener un registro de las asignaturas de cada
carrera a si mismo tambin que de la opcin de poner los componentes de cada
asignatura tales como ser teora, practica, laboratorio y tambin las horas
acadmicas para cada asignatura, y su respectiva temario y biografa del
contenido de las mismas.

5. Qu funciones adicionales le pondra a cada asignatura?
Rpta. Que muestre los prerrequisitos que deben cumplirse para poder cursar
una determinada asignatura y que muestre tambin las cargas horarias para
teora, laboratorio, practica de cada asignatura.

6. que funcionalidad mas debera ofrecer el sistema de gestin de malla curricular
en cuanto a los docentes se refiere ?
Rpta. Poder asignar a los docentes las asignaturas que dicta y muestre esta
informacin.

47

Diagramas de caso de uso alto nivel revisin en pruebas.