PROYECTO

|
UNIVERSIDAD PERUANA LOS ANDES

INGENIERIA DE SISTEMAS Y COMPUTACION
Proyecto
Aprobacin de Actividad Productiva - CETPRO
Integrante
Flix Cuya Mamani
Carlos Boris Carrasco Infanzon
Zuly Susana Yupanqui Mucharo
Docente
Ing. Flix Richar Mendoza Pumacahua
Asignatura
Ingeniera de Software
Ayacucho Julio
2016
Asignatura: Ingeniera de Software 0
INDICE GENERAL
Tabla de contenido
INTRODUCCIN
1. CAPITULO 1: OBJETIVO Y ALCANCE DELPROYECTO.................................................................................. 5
1.1. OBJETIVO DEL PROYECTO.................................................................................................................... 5
1.2. ALCANCES DEL PROYECTO .................................................................................................................. 5
1.2.1. ALCANCES FUNCIONALES .................................................................................................................... 5
1.2.2. ALCANCES TCNICOS ........................................................................................................................... 5
1.3. BENEFICIOS DE AUTOMATIZAR LA APROBACION DE .ACTIVIDADES PRODUCTIVAS ........................... 6
2. CAPITULO 2: MARCO TEORICO .............................................................................................................. 7
2.1. METODOS Y TECNOLOGIA ................................................................................................................... 7
2.1.1. PROCESO UNIFICADO DE RATIONAL ................................................................................................... 7
2.1.2. UNIFIED MODELING LANGUAJE ( UML )............................................................................................ 12
2.1.3. APLICACIONES WEB .............................................................................. Error! Bookmark not defined.
2.1.4. SQL SERVER 2008 R2 EXPRESS............................................................... Error! Bookmark not defined.
2.2. MARCO CONTEXTUAL DE LOS CENTROS DE EDUCACION ..TECNICO PRODUCTIVA .......................... 31
2.2.1. CARACTERSTICAS ............................................................................................................................. 31
2.2.2. OBJETIVOS ....................................................................................................................................... 322
2.2.3. VISIN ............................................................................................................................................... 32
2.2.4. MISIN .............................................................................................................................................. 33
2.2.5. ORGANIZACIN ACADEMICA ............................................................................................................ 32
2.3. TECNOLOGAS DE LA INFORMACIN EN EL CETPRO Y ..OTROS DE LA LOCALIDAD........................... 34
3. CAPITULO 3: MARCO CONCEPTUAL ..................................................................................................... 35
3.1. ACTIVIDAD PRODUCTIVA .................................................................................................................. 35
3.1.1. PRINCIPALES PUNTOS CRITICOS EN LA APROBACION DE ACTIVIDADES PRODUCTIVAS .............. 36
3.2. COSTOS ............................................................................................................................................. 36

3.2.1. COSTOS DE PRODUCCIN ................................................................................................................. 37
3.2.2. COSTOS ADMINISTRATIVOS .............................................................................................................. 37
3.2.3. COSTOS DE COMERCIALIZACIN ....................................................................................................... 37
3.2.4. COSTOS DE FINANCIACIN ............................................................................................................... 37
3.2.5. OPERACIONES ................................................................................................................................... 38
4. CAPITULO 4: ANLISIS ......................................................................................................................... 39
4.1. OBTENCIN DE REQUERIMIENTOS ................................................................................................... 39
4.1.1. ESPECIFICACIN DE REQUERIMIENTOS ............................................................................................ 39
4.1.1.1. REQUERIMIENTOS DE MANTENIMIENTOS ................................................................................... 39
4.1.1.2. REQUERIMIENTOS DE RETIRO Y ASIGNACIN .............................................................................. 40
4.1.1.3. REQUERIMIENTO DE GENERACIN DE COSTO DE PRODUCCIN................................................. 40
4.1.1.4. REQUERIMIENTOS DE REPORTES ................................................................................................. 41
4.1.1.5. REQUERIMIENTOS DE CONFIGURACIN ...................................................................................... 41
4.1.2. DIAGRAMAS DE CASOS DE USO ........................................................................................................ 41
4.1.3. ESPECIFICACIONES DE CASOS DE USO .............................................................................................. 43
4.1.3.1. REQUERIMIENTO DE MANTENIMIENTO ....................................................................................... 43
4.1.3.2. REQUERIMIENTO DE RETIRO Y ASIGNACIN ............................................................................... 53
4.1.3.3. REQUERIMIENTO DE COSTOS DE PRODUCCIN .......................................................................... 59
4.1.3.4. REQUERIMIENTO DE CONFIGURACIN ........................................................................................ 60
4.2. DIAGRAMA DE CLASES ...................................................................................................................... 61
4.3. DIAGRAMA DE SECUENCIA ................................................................................................................ 62
5. CAPITULO 5 : DISEO ........................................................................................................................... 65
5.1. DIAGRAMA DE BASE DE DATOS......................................................................................................... 65
5.2. PROTOTIPO DE PANTALLAS ............................................................................................................... 66
6. CAPITULO 6: CONCLUSIONES ............................................................................................................. 72
BIBLIOGRAFA

Dedicatoria: A mi querida madre y hermanas

INTRODUCCION
La Aprobacin de Actividad Productiva busca recopilar, crear y analizar en

forma sistemtica un conjunto de antecedentes econmicos que permitan juzgar
cualitativamente y cuantitativamente las ventajas y desventajas de asignar
recursos a una determinada iniciativa.
Uno de los principales intereses del Centro de Educacin Tcnico Productivo

(CETPRO) es contestar la interrogante de si es o no conveniente realizar la
inversin. Esta recomendacin slo ser posible si se dispone de todos los
elementos de juicio necesarios para tomar la decisin. Con este objeto, el estudio
de viabilidad debe intentar simular con el mximo de precisin lo que suceder al
proyecto si fuese implementado, aunque difcilmente pueda lograrse con exactitud
el resultado que se lograr en su implementacin. Adems, se requiere lograr una
trazabilidad por producto, el cual constituye una buena prctica en las actividades
econmicas y que sin la herramienta y los procedimientos adecuados es difcil de
alcanzar.
En el mercado del software existen varias herramientas orientadas a la

contabilidad de costos, no a la medida de los requerimientos por cada entidad.
Por consiguiente, es necesario adaptar una herramienta que pueda responder a
las operaciones transaccionales que forman parte del proceso productivo que se
inicia desde la adquisicin de bienes y culmina con el armado de productos
terminados para la venta. Sin embargo, esta opcin es poco viable en el contexto
de los CETPRO debido a que son muy pocas las que estn dispuestas a invertir
en un software que respalde sus operaciones del da a da.
El presente trabajo plantea el anlisis y diseo de un sistema de informacin

que ayude a la Aprobacin de Actividades Productivas. De implantarse esta
solucin permitir obtener el costo real de produccin, llevar a cabo una gestin
de costos ms eficiente y obtener informacin real de las utilidades y los recursos
usados.

1. CAPITULO 1: OBJETIVO
En este captulo se detallan el objetivo y los alcances de este trabajo, adems

de los beneficios obtenidos al automatizar el proceso de la Aprobacin de
Actividades Productivas.
1.1. OBJETIVO DEL PROYECTO
El objetivo de este proyecto es realizar el anlisis y diseo de un sistema de

informacin que ayude a la Aprobacin de Actividades Productivas en el CETPRO
Joaqun Lpez Antay, utilizando el patrn de arquitectura modelovista
controlador (MVC).
1.2. ALCANCES DEL PROYECTO
A continuacin, se detallan los alcances de proyectos, clasificados en funcionales

y tcnicos.
1.2.1. ALCANCES FUNCIONALES
Disear un sistema de informacin que permita obtener la rentabilidad de

la inversin en el proyecto.
Disear un sistema de informacin que permita lograr la trazabilidad de los
productos terminados.
Brindar al usuario la herramienta para administrar recursos: materiales,
maquinas, talleres, financieros.
Permitir al usuario administrar la participacin de sus educandos en
proyectos productivos aprobados, requisito indispensable para obtener el
certificado de Tcnico que brinda la entidad.
1.2.2. ALCANCES TCNICOS
Utilizar una metodologa orientada a objetos, utilizando clases de objetos

que permitir disear programas y mdulos fciles de escribir mantener y
reutilizar.
Utilizar el lenguaje UML (Unified Modeling Language) para el anlisis y
diseo.

Emplear la tecnologa ASP.Net MVC como Framework para la elaboracin
de los prototipos de pantallas.
Emplear IDE NetBeans 7, plataforma para el desarrollo de aplicaciones de
escritorio con lenguaje de programacin Java.
Emplear el motor de base de datos SQL Server 2008 R2 SP2.
Disear un sistema de informacin parametrizable, flexible y modular, y de
fcil integracin.
1.3. BENEFICIOS DE AUTOMATIZAR LA APROBACION DE

.ACTIVIDADES PRODUCTIVAS
Automatizar la evaluacin de un proyecto en el CETPRO otorga muchos

beneficios, entre los cuales cabe destacar:
Permitir obtener los costos de produccin de manera oportuna y exacta de

todos y cada uno de los proyectos productivos al contemplar la asignacin
de los costos directos (insumos y mano de obra) e indirectos de
fabricacin.
Conocer qu bienes o servicios producen utilidades o prdidas, y en que
magnitud.
Guiar las decisiones de inversin.

2. CAPITULO 2: MARCO TEORICO
2.1. METODOS Y TECNOLOGIA

2.1.1. PROCESO UNIFICADO DE RATIONAL
El Proceso Unificado Racional (Rational Unified Process RUP) es un proceso

de desarrollo de software y junto con el Lenguaje Unificado de Modelado (UML),
constituye la metodologa estndar ms utilizada para el anlisis, implementacin
y documentacin de sistemas orientados a objetos.
RUP no es un sistema con pasos firmemente establecidos, sino un conjunto

de metodologas adaptables al contexto y necesidades de cada organizacin.
A. MEJORES PRCTICAS
RUP describe como utilizar de forma efectiva procedimientos comerciales

probados en el desarrollo de software para equipos de desarrollo de software,
conocidos como mejores prcticas.
ADMINISTRACION DE REQUERIMIENTOS
Licitar, organizar, y documentar la funcionalidad y restricciones requeridas.

Llevar un registro y documentacin de cambios y decisiones.
Los requerimientos de negocio son fcilmente capturados y comunicados
a travs de casos de uso.
Los casos de uso son instrumentos importantes de planeacin.

DESARROLLO ITERATIVO DE SOFTWARE
Dados los sistemas de software sofisticados de la actualidad, no es posible

hacer de manera secuencial la definicin completa del problema, disear la
solucin completa, construir el software y por ltimo probarlo. El descubrimiento
de defectos en fases posteriores de diseo dan como resultado un aumento en
los costos y/ la cancelacin del proyecto.
Caractersticas del desarrollo iterativo
Permite un entendimiento incremental del problema a travs de

refinamientos sucesivos.
Habilita una fcil retroalimentacin de usuario.
Metas especficas permiten que el equipo de desarrollo mantenga su
atencin en producir resultados.
El progreso es medido conforme avanzan las implementaciones.
ARQUITECTURA BASADA EN COMPONENTES
Se enfoca en el pronto desarrollo de una arquitectura ejecutable robusta.
Resistente al cambio mediante el uso de interfaces bien definidas.

Intuitivamente comprensible.
Promueve un reso ms efectivo de software.
Es derivada a partir de los casos de uso ms importantes.

MODELACION VISUAL DE SOFTWARE
Captura la estructura y comportamiento de arquitecturas y componentes.

Muestra como encajan de forma conjunta los elementos del sistema.
Mantiene la consistencia entre un diseo y su implementacin.
Promueve una comunicacin no ambigua.
VERIFICACION DE LA CALIDAD DEL SOFTWARE
Crea pruebas para cada escenario (casos de uso) para asegurar que todos
los requerimientos estn propiamente implementados.
Verifica la calidad del software con respecto a los requerimientos basados
en la confiabilidad, funcionalidad, desempeo de la aplicacin y del
sistema.
Prueba cada iteracin
CONTROL DE CAMBIOS DEL SOFTWARE
Controlar, llevar un registro y monitorear cambios para permitir un desarrollo

iterativo.
Establece espacios de trabajo seguros para cada desarrollador

Provee aislamiento de cambios hechos en otros espacios de trabajo
Controla todos los artefactos de software modelos, cdigo, documentos,
etc.
B. ESTRUCTURA RUP
El proceso puede describirse en dos dimensiones, o a lo largo de dos ejes:
El eje horizontal representa tiempo y muestra el aspecto dinmico del

proceso, expresado en trminos de ciclos, fases, iteraciones, y metas.
El eje vertical representa el aspecto esttico del proceso; como est
descrito en trminos de actividades, artefactos, trabajadores y flujos de
trabajo.

FASES EN RUP
Inicio Define el alcance del proyecto

Elaboracin Plan del proyecto, especificacin de caractersticas,
arquitectura base
Construccin Construir el producto
Transicin Transicin del producto a la comunidad del usuario
FASE DE INICIO
Propsito
Establecer casos de negocios para un nuevo sistema o para alguna

actualizacin importante de un sistema existente
Especificar el alcance del proyecto
Resultado
Una visin general de los requerimientos del proyecto, los requerimientos

principales

Un modelo inicial de casos de uso y modelo del dominio (10-20%)
Un caso de negocios inicial, incluyendo:
- Evaluacin inicial de riesgos
- Una estimacin de los recursos requeridos
FASE DE ELABORACION
Propsito
Analizar el dominio del problema

Establecer una buena arquitectura
Lidiar con los elementos de riesgo ms altos del proyecto
Desarrollar un plan comprensivo mostrando como el proyecto ser
completado
Resultado
Un modelo del dominio y de casos de uso 80% completo

Requerimientos suplementarios que capturen los requerimientos no
funcionales y cualesquiera requerimientos que no estn asociados con un
caso de uso especfico
Una lista de riesgos revisada
FASE DE CONSTRUCCION
Propsito
Desarrollar incrementalmente producto de software completo el cual estar

listo para ser transferido al usuario
Productos
Un modelo completo de diseo y casos de uso

Liberaciones de productos ejecutables de funcionalidad incremental
Documentacin de usuario
Una liberacin beta del producto

FASE DE TRANSICION
Hacer la transicin final del producto de software al usuario
Productos
Liberaciones ejecutables de producto

Pruebas beta para validar el nuevo sistema vs. las expectaciones del
usuario
Manuales de usuario actualizados
Documentacin de desarrollo actualizada
Est el usuario satisfecho?
Gastos reales de los recursos vs. Gastos previstos Aceptables?
2.1.2. UNIFIED MODELING LANGUAJE ( UML )
El Lenguaje Unificado de Modelado preescribe un conjunto de notaciones y

diagramas estndar para modelar sistemas orientados a objetos, y describe la
semntica esencial de lo que estos diagramas y smbolos significan. UML se
puede usar para modelar distintos tipos de sistemas: sistemas de software,
sistemas de hardware, y organizaciones del mundo real. UML ofrece nueve
diagramas en los cuales modelar sistemas.
Diagramas de Casos de Uso para modelar los procesos business.

Diagramas de Secuencia para modelar el paso de mensajes entre objetos.
Diagramas de Colaboracin para modelar interacciones entre objetos.
Diagramas de Estado para modelar el comportamiento de los objetos en
el sistema.
Diagramas de Actividad para modelar el comportamiento de los Casos de
Uso, objetos u operaciones.
Diagramas de Clases para modelar la estructura esttica de las clases en
el sistema.
Diagramas de Objetos para modelar la estructura esttica de los objetos
en el sistema.
Diagramas de Componentes para modelar componentes.
Diagramas de Implementacin para modelar la distribucin del sistema.

UML es una consolidacin de muchas de las notaciones y conceptos ms
usadas orientados a objetos. Empez como una consolidacin del trabajo de
Grade Booch, James Rumbaugh, e Ivar Jacobson, creadores de tres de las
metodologas orientadas a objetos ms populares. En 1996, el Object
Management Group (OMG), un pilar estndar para la comunidad del diseo
orientado a objetos, public una peticin con propsito de un metamodelo
orientado a objetos de semntica y notacin estndares. UML, en su versin 1.0,
fue propuesto como una respuesta a esta peticin en enero de 1997. Hubo otras
cinco propuestas rivales. Durante el transcurso de 1997, los seis promotores de
las propuestas, unieron su trabajo y presentaron al OMG un documento revisado
de UML, llamado UML versin 1.1. Este documento fue aprobado por el OMG en
noviembre de 1997.
DIAGRAMA DE CASO DE USO
El modelado de Casos de Uso es la tcnica ms efectiva y a la vez la ms

simple para modelar los requisitos del sistema desde la perspectiva del usuario.
Los Casos de Uso se utilizan para modelar cmo un sistema o negocio funciona
actualmente, o cmo los usuarios desean que funcione. No es realmente una
aproximacin a la orientacin a objetos; es realmente una forma de modelar
procesos. Es, sin embargo, una manera muy buena de dirigirse hacia el anlisis
de sistemas orientado a objetos. Los casos de uso son generalmente el punto de
partida del anlisis orientado a objetos con UML.
El modelo de casos de uso consiste en actores y casos de uso. Los actores

representan usuarios y otros sistemas que interaccionan con el sistema. Se
dibujan como "muecos" de palo. Actualmente representan el tipo de usuario, no
una instancia de usuario. Los casos de uso representan el comportamiento del
sistema, los escenarios que el sistema atraviesa en respuesta a un estmulo desde
un actor. Se dibujan como elipses.

DIAGRAMA DE SECUENCIA
El Diagrama de Secuencia es uno de los diagramas ms efectivos para

modelar interaccin entre objetos en un sistema. Un diagrama de secuencia se
modela para cada caso de uso. Mientras que el diagrama de caso de uso permite
el modelado de una vista business del escenario, el diagrama de secuencia
contiene detalles de implementacin del escenario, incluyendo los objetos y clases
que se usan para implementar el escenario, y mensajes pasados entre los objetos.
Tpicamente uno examina la descripcin de un caso de uso para determinar

qu objetos son necesarios para la implementacin del escenario. Si tienes
modelada la descripcin de cada caso de uso como una secuencia de varios
pasos, entonces puedes "caminar sobre" esos pasos para descubrir qu objetos
son necesarios para que se puedan seguir los pasos. Un diagrama de secuencia
muestra los objetos que intervienen en el escenario con lneas discontinuas
verticales, y los mensajes pasados entre los objetos como vectores horizontales.
Los mensajes se dibujan cronolgicamente desde la parte superior del diagrama
a la parte inferior; la distribucin horizontal de los objetos es arbitraria.
DIAGRAMA DE COLABORACION
El Diagrama de Colaboracin presenta una alternativa al diagrama de

secuencia para modelar interacciones entre objetos en el sistema. Mientras que
el diagrama de secuencia se centra en la secuencia cronolgica del escenario que
estamos modelando, el diagrama de colaboracin se centra en estudiar todos los
efectos de un objeto dado durante un escenario. Los objetos se conectan por
medio de enlaces, cada enlace representa una instancia de una asociacin entre
las clases implicadas. El enlace muestra los mensajes enviados entre los objetos,
el tipo de mensaje (sincrnico, asincrnico, simple, blanking, y time-out), y la
visibilidad de un objeto con respecto a los otros.
DIAGRAMA DE CLASES
El Diagrama de Clase es el diagrama principal de diseo y anlisis para un

sistema. En l, la estructura de clases del sistema se especifica, con relaciones
entre clases y estructuras de herencia. Durante el anlisis del sistema, el diagrama
se desarrolla buscando una solucin ideal. Durante el diseo, se usa el mismo
diagrama, y se modifica para satisfacer los detalles de las implementaciones.
DIAGRAMA DE ACTVIDADES
El Diagrama de Actividad es un diagrama de flujo del proceso multi-propsito

que se usa para modelar el comportamiento del sistema. Los diagramas de
actividad se pueden usar para modelar un Caso de Uso, o una clase, o un mtodo
complicado. Un diagrama de actividad es parecido a un diagrama de flujo; la
diferencia clave es que los diagramas de actividad pueden mostrar procesado
paralelo (parallel processing). Esto es importante cuando se usan diagramas de
actividad para modelar procesos bussiness algunos de los cuales pueden actuar
en paralelo, y para modelar varios hilos en los programas concurrentes.

DIAGRAMA DE COMPONENTES
El Diagrama de Componentes se usa para modelar la estructura del software,

incluyendo las dependencias entre los componentes de software, los
componentes de cdigo binario, y los componentes ejecutables. En el Diagrama
de Componentes modelas componentes del sistema, a veces agrupados por
paquetes, y las dependencias que existen entre componentes (y paquetes de
componentes).
DIAGRAMA DE IMPLEMENTACION
Los Diagramas de Implementacin se usan para modelar la configuracin de

los elementos de procesado en tiempo de ejecucin (run-time processing
elements) y de los componentes, procesos y objetos de software que viven en
ellos. En el diagrama deployment, empiezas modelando nodos fsicos y las
asociaciones de comunicacin que existen entre ellos. Para cada nodo, puedes
indicar qu instancias de componentes viven o corren (se ejecutan) en el nodo.
Tambin puedes modelar los objetos que contiene el componente.

2.1.3. APLICACIONES WEB
En este inciso se darn a conocer algunos conceptos bsicos del

contexto de este trabajo, con la finalidad de situar al problema dentro de
un conjunto de conocimientos. Dentro de estos conocimientos se darn
algunos conceptos acerca de patrones de diseo, dentro de ellos el patrn
MVC, sus partes y caractersticas, despus se hablar acerca de los
frameworks, un breve comparativo entre estos y los patrones de diseo y
finalmente se hace un pequeo y breve anlisis de algunos otros
frameworks para web existentes.
Patrones de diseo
Definicin e historia
Para comenzar es importante definir lo que un patrn de diseo es, aunque

existen varias definiciones al respecto, un patrn de diseo es una solucin
de calidad para un problema recurrente de diseo. Pero no son aplicables
nicamente en el campo computacional, tambin existen patrones para
varias actividades de la vida cotidiana, aunque con algunas diferencias,
pero tienen el mismo propsito que en el mbito computacional,
proporcionar una base para poder realizar una actividad, mejorando la
calidad del producto que esa actividad de como resultado [Freeman, 2004].
Hay patrones que abarcan las distintas etapas del desarrollo; desde el
anlisis hasta el diseo y desde la arquitectura hasta la implementacin.
En el caso de los patrones computacionales un software estructurado,
modulado posee una mejor calidad y es ms sencillo corregir errores,
implementar mejoras y actualizaciones, ya que un software que posee
algn patrn de diseo es ms sencillo de modificar que un software que
no posee en absoluto un patrn. Pero Cmo se debe escoger el patrn
adecuado?, esta es una pregunta un poco difcil de responder ya que la
mayora de las actividades de desarrollo o produccin no se ajustan
perfectamente a un patrn definido, por eso es importante llevar acabo un
anlisis para poder visualizar cual ser el patrn que mejor se ajuste a las
necesidades de desarrollo. En s "un patrn de diseo puede verse como

una plantilla que puede ser aplicada en muchas situaciones diferentes"
[Gamma, 1995], para dar una buena solucin.
Los patrones se descubren como una forma indispensable de enfrentarse

a la programacin a raz del libro "Design Patterns - Elements of Reusable
Software" de Erich Gamma, Richard Helm, Ralph Jonson y John Vlissides,
a partir de entonces los patrones de diseo que aparecen en ese libro son
conocidos como los patrones de la pandilla de los cuatro (GoF, gang of
four), y comienzan a desarrollarse variaciones y nuevos patrones, en poco
tiempo se multiplicaron por 100 y no se limitaban a patrones de diseo sino
que cubran todo los que se entiende por ingeniera del software (desde el
anlisis hasta la implementacin)[Gamma, 1995].
Elementos esenciales
En general un patrn tiene cuatro elementos esenciales:
El nombre del patrn: que se utiliza para describir un problema de diseo,

sus soluciones y sus consecuencias, en una palabra, o dos. Este nombre
ayuda a que sea ms sencillo de identificarlo, al hablar o escribir de l e
incluso puede dar una idea general o una descripcin de dicho patrn.
El problema: describe cuando aplicar el patrn, tambin puede incluir

detalles especficos que se deben cumplir o problemas un poco ms
detallados, los cuales en conjunto engloban el problema central a
solucionar.
La solucin: describe los elementos que forman el diseo, sus relaciones,

sus responsabilidades y sus colaboraciones. La solucin no describe un
diseo o implementacin en particular ya que un patrn de diseo puede
verse como una plantilla que se aplica a un problema especfico.
Las consecuencias: son los resultados y desventajas de haber aplicado

el patrn. Estas consecuencias implican un impacto en las caractersticas
del sistema como: flexibilidad, portabilidad y extensin. Adems de que
ayudan a medir el desempeo del sistema.

Clasificacin
El grupo de GoF clasific los patrones en 3 grandes categoras basadas

en su propsito: creacionales, estructurales y de comportamiento [Gamma,
1995].
Creacionales: tratan con las formas de crear instancias de objetos. El

objetivo de estos patrones es de abstraer el proceso de instanciacin y
ocultar los detalles de cmo los objetos son creados o inicializados.
Estructurales: Los patrones estructurales describen como las clases y

objetos pueden ser combinados para formar grandes estructuras y
proporcionar nuevas funcionalidades. Estos objetos adicionados pueden
ser incluso objetos simples u objetos compuestos.
Comportamiento: Los patrones de comportamiento ayudan a definir la

comunicacin e iteracin entre los objetos de un sistema. El propsito de
este patrn es reducir el acoplamiento entre los objetos.
Patrn de diseo Model View Controller (MVC)
Una vez establecidas las bases de los patrones de diseo, se puede ya

comenzar a hablar ms del patrn que se utiliz durante este trabajo: el
patrn MVC. Estas son las siglas de Model View Controller, en espaol
Modelo Vista Controlador. Esto tambin se ve reflejado en que cada una
de estas palabras representa cada uno de los 3 componentes del patrn
MVC. Cada parte juega un rol fundamental para la completa integracin
del sistema.
Definicin e historia
"El propsito de este patrn es simplificar la implementacin de

aplicaciones de acuerdo a las peticiones de los usuarios y los datos a
desplegar" [Harrop, 2005]. La definicin un poco ms formal sera: MVC es
un patrn de diseo de software que separa los datos de una aplicacin,
la interfaz de usuario, y la lgica de control en tres componentes distintos
de forma que las modificaciones al componente de la vista, o a cualquier
parte del sistema puedan ser hechas con un mnimo impacto en el
componente del modelo de datos o en los otros componentes del sistema.
Este patrn cumple perfectamente el cometido de modularizar un sistema.
El patrn MVC fue descrito por primera vez en 1979 por Trygve
Reenskaug, quin trabajaba en Smalltalk en los laboratorios de
investigacin de la Xerox. Este patrn se ve frecuentemente utilizado en
aplicaciones web, donde la vista es la pgina HTML y el cdigo provee de
datos dinmicos a la pgina. Las aplicaciones web complejas continan
siendo ms difciles de disear que las aplicaciones tradicionales de
escritorio, el patrn MVC se presenta como una solucin para ayudar a
disminuir dicha complejidad.
Componentes
Los 3 principales componentes del patrn MVC son:
Modelo: Representa los datos que el usuario est esperando ver, en

algunos casos el Modelo consiste de Java Beans.
Vista: es la responsable de transformar el modelo para que sea

visualizada por el usuario, ya sea en un archivo de texto normal o en una
pgina web (HTML o JSP) que el navegador pueda desplegar. En s el
propsito de la vista es convertir los datos para que al usuario le sean
significativos y los pueda interpretar fcilmente. La vista no debe trabajar
directamente con los parmetros del request, debe delegar esta
responsabilidad al controlador.
Controlador: es la parte lgica que es responsable del procesamiento y

comportamiento de acuerdo a las peticiones (requests) del usuario,
construyendo un modelo apropiado, y pasndolo a la vista para su correcta
visualizacin. En el caso de una aplicacin web Java en la mayora de los
casos el controlador es implementado por un servlet.
Tipos de patrones MVC
Actualmente existen dos tipos de patrn MVC:

Servidor Web/Aplicacin
Fuente: Walls, 2005
Como se muestra en el Grfico 4 en el Tipo 1 de MVC las pginas JSP

estn en el centro de la aplicacin, y contienen tanto la lgica de control
como la de presentacin. Este tipo de arquitectura funciona de la siguiente
manera: el cliente hace una peticin a una pgina JSP; se construye la
lgica de la pgina, generalmente en objetos Java o como se les conoce
en Ingls Plain Old Java Objects (POJOs) y se transforma el modelo para
ser desplegado una vez ms.
Servidor Web/Aplicacin
Fuente: Walls, 2005
En el modelo de Tipo 2 de MVC, que se aprecia en el Grfico 5, se puede

observar que ya existe una clara separacin entre el controlador y la vista,
ya que ahora es directamente el controlador quien recibe la peticin,

prepara el modelo y lo transforma para que sea desplegado en la vista.
Este tipo de arquitectura MVC es el que se utiliza para aplicaciones ms
complejas, ya que para una aplicacin sencilla puede utilizarse el Tipo 1.
La tecnologa JSP no es la nica que se puede emplear para las vistas,
existen otro tipo de tecnologas que pueden servir como vistas.
Frameworks
Un framework es un trmino utilizado en la computacin en general, para

referirse a un conjunto de bibliotecas, utilizadas para implementar la
estructura estndar de una aplicacin. Todo esto se realiza con el
propsito de promover la reutilizacin de cdigo, con el fin de ahorrarle
trabajo al desarrollador al no tener que rescribir ese cdigo para cada
nueva aplicacin que desee crear. Existen diferentes frameworks para
diferentes propsitos, algunos orientados al desarrollo de aplicaciones
web, otros para desarrollar aplicaciones multiplataforma, para un sistema
operativo o lenguaje de programacin en especfico, entre otros.
Segn Gamma, el framework determina la arquitectura de una aplicacin

[Gamma, 1995]. Este es un buen enfoque, ya que el framework se encarga
de definir la estructura general, sus particiones en clases y objetos, las
responsabilidades clave, as como la colaboracin entre dichas clases y
objetos. Todos estos parmetros son definidos por el framework, evitando
que el usuario tenga que definirlos y se pueda enfocar en cosas especficas
de su aplicacin.
"El framework captura las decisiones de diseo que son comunes a su

dominio de aplicacin" [Gamma, 1995]. Un framework no slo promueve
la reutilizacin de cdigo sino tambin la reutilizacin de diseo.
Un framework ayuda a que se desarrolle una aplicacin de una manera

ms rpida, ya que se no pierde tiempo en algunos detalles de diseo que
muchas veces quitan ms tiempo del que tomo construir en s la lgica de
la aplicacin. Adems las aplicaciones que se construyen tienen
estructuras similares, son ms fciles de mantener y consistentes para los

usuarios. Pero esto tiene como consecuencia una mnima perdida de
libertad en las cuestiones de diseo.
En algunas ocasiones un desarrollador tiene algunas dificultades para

disear una aplicacin, esto todava es ms difcil para el desarrollador del
framework, ya que desarrollar un framework requiere de muchos cuidados,
porque cuando se lanza uno nuevo, se espera que pueda servir para
muchos tipos de aplicaciones, pero con arquitecturas y requerimientos
similares. Es decir, trata de englobar toda una gamma de aplicaciones
dentro de un solo estndar, lo cual puede ser el xito o el fracaso del
mismo, por eso se intenta crear frameworks lo ms extensibles y flexibles
posibles, para que con algunos cambios mnimos se pueda actualizar o
corregir. Las aplicaciones que se desarrollan a partir de un framework, est
ligada al mismo, por eso las aplicaciones deben de evolucionar y crecer al
mismo tiempo que crece el framework, ya que un cambio en alguna interfaz
del mismo significar un cambio de la aplicacin, dependiendo de qu tan
drstico sea el cambio.
Relacin entre patrones de diseo y frameworks
Los frameworks utilizan un variado nmero de patrones de diseo, ya que

as logran soportar aplicaciones de ms alto nivel y que reutilizan una
mayor cantidad de cdigo, que uno que no utiliza dichos patrones. "Los
patrones ayudan a hacer la arquitectura de los frameworks ms adecuada
para muchas y diferentes aplicaciones sin necesidad de rediseo"
[Gamma, 1995]. Por esta razn es importante que se documenten que
patrones utiliza el framework para que los que se encuentren familiarizados
con dichos patrones puedan tener una mejor visin y poder adentrarse en
el framework ms fcilmente.
Aunque muchas personas cometen el error de confundir a los frameworks

con los patrones de diseo, segn los cuatro autores del libro "Design
Patterns - Elements of Reusable" existen 3 diferencias fundamentales
entre ellos [Gamma, 1995]:

Los patrones de diseo son ms abstractos que los frameworks: el
cdigo del framework se escribe una vez, en cambio cada vez que se
requiere un patrn de diseo se debe de codificar con respecto a la
aplicacin. Una fortaleza de los frameworks es que pueden ser escritos en
un lenguaje de programacin, pueden ser reutilizados e incluso
ejecutados, esto tambin podra considerarse una debilidad dependiendo
del punto de vista (siempre y cuando no sean multiplataforma o se
encuentre en diferentes versiones por lenguaje de programacin), ya que
estn enfocados a un slo lenguaje de programacin, en cambio un patrn
de diseo puede ser aplicado a cualquier lenguaje de programacin, pero
se tiene que reescribir desde cero.
Los patrones de diseo son elementos arquitectnicos ms

pequeos que los frameworks: un solo framework contiene varios
patrones de diseo, pero jams es, al contrario.
Los patrones de diseo son menos especializados que los

frameworks: existen frameworks con un dominio especfico, adems los
patrones son un poco ms generales debido a que pueden ser utilizados
en un mayor nmero de aplicaciones de varios tipos.
Frameworks para aplicaciones web
Actualmente existen algunos frameworks para desarrollar aplicaciones

web, que es de las ramas ms importantes en las que se usan los
frameworks. La mayora de ellos utilizan el patrn de diseo MVC del cual
se habl previamente. Todos los frameworks tienen caractersticas
especiales que los hacen nicos para sobresalir y poder seguir en el
mercado, adems de poseer las siguientes caractersticas comunes
[Johnson, 2003]:
Utilizan un solo servlet que tiene la funcin de controlador, para toda la

aplicacin o gran parte de ella. Se configura el deployment descriptor
"web.xml" para que todas las URL's tengan que pasar forzosamente por
dicho servlet.

Una configuracin, generalmente escrita en un archivo XML, en donde se
le indicar al servlet controlador, a travs de propiedades, a quien delegar
la responsabilidad de atender la peticin entrante. Algunas veces esas
propiedades estn indicadas de acuerdo a los URL's y de acuerdo al URL
entrante es como se delega la responsabilidad.
Las vistas pueden tener nombres claves, sin necesidad que exista una
relacin con el nombre del archivo de la vista. El framework se encarga de
realizar dicha conversin para poder obtener el nombre de la vista que se
tiene que cargar para que sea desplegada. La implementacin de una vista
con un nombre en particular puede cambiar sin afectar cdigo del
controlador.
Cuando se va a desarrollar una aplicacin web, el desarrollador se debe

fijar en si desea realizar una aplicacin extremadamente sencilla o si quiere
desarrollar una verdadera aplicacin web, que tendr actualizaciones,
correcciones y mejoras a futuro. Para esto es recomendable que se elija
un framework de aplicacin web que utilice el patrn web MVC. Con el fin
de que se pueda hacer la separacin entre los 3 elementos principales y
pueda aprovechar todas las ventajas que brinda este patrn de diseo.
Para poder aprovechar tambin las ventajas adicionales que brinda el
framework para la integracin con otras herramientas u otros servicios.
A continuacin se enlistan algunos de los frameworks para aplicaciones

web ms populares: Struts, WebWork, Maverick y Spring, el framework
sobre el cual se basa esta tesis, ser analizado con mayor detalle ms
adelante en este documento. Este listado y anlisis sencillo de cada uno
de estos frameworks se da con la razn de poder saber cuales son los
frameworks contra los que compite Spring, dentro del mismo mbito, as
como sus caractersticas principales, ventajas y desventajas.
Struts
Struts es uno de los frameworks MVC ms utilizados, ya que fue uno de

los pioneros en el campo, fue creado por Craig McClanahan, creador del
famoso motor servlet Tomcat, ambos son distribuidos por Apache. Este

framework fue lanzado a mediados del ao 2000, y a partir de esta fecha
comenz a tener popularidad, y en la actualidad existen algunos
componentes extra que se adaptan a Struts, lo que le da un mayor campo
de accin. Struts es open source, por lo que no requiere licencia para su
uso [Johnson, 2003].
Adems, cumple una de las funcionalidades bsicas que se mencionaron

acerca de los frameworks para aplicaciones web, ya que implementa un
solo controlador (ActionServlet) que evala las peticiones del usuario
mediante un archivo configurable (struts-config.xml) para poder dirigirlas a
un action que procesa el request. El lenguaje de programacin que utiliza
es Java, as como Java Beans como modelo.
Algunas de las ventajas que Struts brinda son: que existe un variado
nmero de trabajos y proyectos ya hechos lo que brinda un mayor nmero
de ejemplos para poder tomar un punto de partida y de referencia; otra
ventaja es que brinda libreras de tags para HTML bastante tiles. Entre
las desventajas de framework se puede observar que muchas veces puede
ser difcil trabajar con los ActionForms, adems de que el proyecto
posiblemente desaparezca en los aos venideros, otra de las desventajas
de Struts es que muy ligado con la tecnologa JSP, por lo que muchas
veces se dificulta integrarlo con alguna otra tecnologa para las vistas.
Maverick
Este es otro framework MVC open source que existe en el mercado, pero
a diferencia de los dems este no cuenta con sus propias libreras de tags.
Sin embargo, cumple con las funcionalidades tpicas mencionadas, como
el de tener un solo servlet controlador central como punto de entrada, el
cual lleva el nombre de Dispatcher, que est definido en el Deployment
Descriptor de la aplicacin web (web.xml). Maverick cuenta con un archivo
XML en el que se guarda toda la configuracin del mismo (maverick.xml).
Una caracterstica de Maverick es que nicamente acepta un solo
controlador central y un archivo de configuracin por aplicacin web, lo que
muchas veces al desarrollar aplicaciones ms grandes y complejas se
puede volver confuso y difcil de configurar. [Johnson, 2003]
Maverick es un framework mucho ms configurable que Struts, lo que
brinda cierta flexibilidad, tambin incluye varias clases para poder extender
y cambiar el flujo del trabajo o workflow en Ingls. Maverick es usualmente
usado para crear nuevos controladores que sean capaces de procesar
nuevas peticiones. Los controladores son Java Beans, y el framework pone
de manera transparente las propiedades de los beans.
Una caracterstica interesante de Maverick es el bsico y fcil uso de la

funcionalidad del dispatcher. Tambin es multiplataforma ya que ha sido
adaptado para los lenguajes .NET y PHP.
WebWork
Este es un framework ms reciente ya que fue lanzado a mediados del ao

2002, una de las personas que ha trabajado en este proyecto fue Rickard
Oberg, quien ha participado en proyectos como JBoss, entre otros.
"WebWork, a pesar de su nombre, no es puramente un framework para
aplicaciones web. Adopta un acercamiento prctico que minimiza la
dependencia del cdigo de la aplicacin de los conceptos web."[Johnson,
2003].
El framework WebWork est basado en el patrn de diseo de Comandos

o CommandPattern. Cada accin es un comando, que es creado para
manejar un request, sus propiedades son puestas de manera transparente,
ya que cada accin es un Java Bean.
WebWork cuenta, al igual que Struts y Spring con su propia librera de tags
para JSP, las cuales ayudan a realizar distintas tareas de una manera ms
gil, pero no es la nica tecnologa para vista que soporta, tambin incluye
soporte para Velocity.
Una de las ventajas de WebWork es que cuenta con una arquitectura

simple y las clases son fciles de extender. Pero como todo, tiene sus
desventajas, la creacin de una accin (action) por cada request puede
llegar a ser algo confuso cuando no se tiene muchos datos en el request;
impone el patrn de diseo Command en cada interaccin del usuario, ya

sea bueno o malo utilizarlo en dicha interaccin; es difcil saber de que tipo
son las excepciones que se lanzan. Como este framework es relativamente
reciente no existe mucha documentacin y ejemplos al respecto lo que
puede resultar a veces frustrante cuando se requiere buscar algn ejemplo
o tutorial que pueda servir.
Spring
Es un framework de aplicacin, que a diferencia de otros single-tier como

Struts, Spring propone estructurar toda una aplicacin de una manera
consistente y productiva, conjuntando lo mejor de cada uno de los
frameworks single-tier para crear una arquitectura coherente. En s Spring
ha surgido como una solucin para poder disfrutar de los beneficios clave
de J2EE, mientras que minimiza la complejidad encontrada en el cdigo
de la aplicacin. [Johnson, 2005]
Spring est basado en la filosofa de que un framework debe proveer una

gua hacia una buena prctica, es decir debe hacer la cosa correcta
sencilla de hacer. Mezclando la correcta combinacin de flexibilidad y
restriccin, la cual es la clave en el buen diseo de un framework.
Spring tambin cuenta con algunas de las caractersticas generales de los

frameworks web, ya que cuenta con un mdulo para poder desarrollar
aplicaciones web de manera sencilla, utilizando el patrn de diseo MVC
antes mencionado. Contando con un controlador central
(DispatcherServlet), adems de la capacidad de tener varios controladores
secundarios para el procesamiento de cada una de las peticiones.
Tambin se basa en el diseo de las clases extendiendo o implementando

interfaces, lo cual es un mejor diseo orientado a objetos, ya que promueve
la reutilizacin de cdigo. Adems, Spring cuenta con algunos tags para
las diferentes tecnologas para vista que existen. Las cuales tienen
funciones diferentes como vincular formularios, validacin, despliegue de
informacin, entre otras.

Uno de los aspectos clave y ventajas de Spring, es que cuenta con una
arquitectura modularizada, y se pueden utilizar cada uno de estos mdulos
de manera independiente. Cada uno est enfocado en una tarea
especfica, y algunos de ellos son para la integracin con alguna
herramienta o incluso cuenta con la posibilidad de integrase con los otros
frameworks mencionados anteriormente. Esto con el propsito de
proponer la filosofa de "no intentar reinventar la rueda", la cual quiere decir
que si ya existe en el mercado una herramienta que realice una tarea de
manera eficiente en un mbito o rea en particular se debe conjuntar con
Spring para llevar a cabo un mejor desempeo y poder sacar as un mejor
resultado y una aplicacin de mayor calidad.
En conclusin, cada framework tiene sus ventajas y desventajas, escoger

uno es una decisin del desarrollador, dependiendo de sus necesidades y
requerimientos, del tamao del proyecto a desarrollar, as como de su
experiencia con tecnologas existentes que se integren fcilmente con el
framework que haya elegido. Esto con el fin de aprovechar algunas
tecnologas que estn enfocadas en un rea especfica, para que brinde
una mejor y ms sencilla forma de llevar a cabo la tarea. Esta fue una de
las razones por la cual se decidi incursar dentro de las caractersticas de
Spring, y despus de un anlisis se lleg a la conclusin de que es un buen
framework que cumple con la mayora de las caractersticas, de las cuales
otros frameworks escasean.
Una de las cuestiones que ha hecho a Spring evolucionar de manera muy

rpida en tan poco tiempo, es que se han incrementado de una manera
increble el nmero de proyectos que utilizan esta herramienta a travs del
ltimo ao. Esto conlleva a que la cantidad de personas interesadas en
este framework aumente, as como el soporte, el nmero de foros de
opinin y la publicacin de un mayor nmero de libros y tutoriales.
2.1.4. SQL SERVER 2008 R2 EXPRESS
Microsoft SQL Server 2008 R2 Express con Service Pack 2 es una

edicin gratuita y con muchas caractersticas de SQL Server que resulta
idnea para aprender, desarrollar y activar pequeas aplicaciones de

servidor, web y de escritorio, as como para su redistribucin a travs de
ISV.
Caractersticas clave que ofrece SQL Server 2008 R2 SP2 Express:
Admite los procedimientos, desencadenadores, funciones y vistas

almacenados
Almacene todo tipo de datos empresariales con soporte nativo para
datos relacionales, XML, FILESTREAM y datos espaciales
Rendimiento mejorado, facilidad de uso y visualizacin adems de la
integracin con el sistema de Microsoft 2007 Office en SQL Server
Reporting Services
Simplifique las tareas de desarrollo mediante el aprovechamiento de
las capacidades existentes de T-SQL, ADON.NET Entity Framework y
LINQ.
Estrecha integracin con Visual Studio y Visual Web Developer.
SQL Server 2008 R2 SP2 Express puede instalarse en mquinas host de

cualquier tamao con cualquier cantidad de CPUs (una base de datos por
mquina), no obstante, almacenar hasta 4GB de datos de usuarios, utilizar
hasta 1GB de memoria, y utilizar una sola CPU en la mquina host.
2.2. MARCO CONTEXTUAL DE LOS CENTROS DE EDUCACION

..TECNICO PRODUCTIVA
Segn D.S. N 003-2005-ED se dio la conversin progresiva de Centros de

Educacin Ocupacional (CEO) y Programa de Educacin Ocupacional a Centros
de Educacin Tcnico-Productiva (CETPRO), inici en agosto del 2005, y culmin
el ao 2006.
Los CETPRO a pesar de estar dentro de la jurisdiccin de las Direccin

Regional de Educacin (DRE) y UGEL, cuentan con autonoma pedaggica,
institucional y administrativa de dichas instituciones. La autonoma pedaggica se
concreta en la capacidad de las Instituciones Educativas para formular, ejecutar y
evaluar su currculo diversificado que responda a las caractersticas de los

estudiantes, de la Institucin Educativa, as como su entorno, teniendo en cuenta
las orientaciones del diseo curricular nacional. La autonoma institucional se
sustenta en que las Instituciones Educativas formulen, ejecuten y evalen su Plan
Estratgico Institucional (PEI), como instrumento de planificacin estratgica para
el mediano plazo. La autonoma administrativa se afirma en las capacidades de
las Instituciones Educativas para generar y administrar con eficiencia el personal
y sus recursos materiales, econmicos y tecnolgicos.
La Educacin Tcnico-Productiva es la forma de educacin orientada a la

adquisicin y desarrollo de competencias laborales y empresariales en una
perspectiva de desarrollo sostenible, competitivo y humano, as como a la
promocin de la cultura innovadora que responda a la demanda del sector
productivo y a los avances de la tecnologa, del desarrollo local, regional y
nacional, as como a las necesidades educativas de los estudiantes en sus
respectivos entornos.
Asimismo, contribuye a un mejor desempeo de la persona que trabaja, a

mejorar su nivel de empleabilidad y a su desarrollo personal. Est destinada a las
personas que buscan una insercin o reinsercin en el mercado laboral y a
alumnos de la Educacin Bsica. La educacin Tcnico-Productiva que se brinda
en las Instituciones Pblicas es gratuita, prioriza la atencin a la poblacin de
menores recursos, especialmente en el mbito rural, brinda oportunidades para la
inclusin de las personas con necesidades educativas especiales.
2.2.1. CARACTERSTICAS
a) Pertinente, porque oferta capacitacin tcnica orientada a la produccin de

bienes y servicios con demanda en el mercado laboral local, regional,
nacional y/o internacional.
b) Flexible, porque la organizacin de los servicios educativos responde a la
heterogeneidad de los estudiantes y a la peculiaridad de sus contextos, y
se organiza en diferentes mdulos ocupacionales.
c) Innovadora, porque promueve y desarrolla cambios de gestin institucional
y pedaggica, orientndose hacia el desarrollo cientfico y tecnolgico.
d) Desarrolla actividades productivas y de servicios empresariales

2.2.2. OBJETIVOS
a) Desarrollar competencias laborales y capacidades emprendedoras para el

trabajo dependiente o independiente.
b) Motivar y preparar a los estudiantes para aplicar lo aprendido en algn
campo especfico de la produccin o los servicios, con visin empresarial.
c) Actualizar las competencias de trabajadores en actividad o desocupados,
segn las exigencias del mercado laboral.
d) Promover una cultura emprendedora e innovadora que facilite la insercin
laboral de los egresados y que los habilite para generar su propio empleo.
2.2.3. VISIN
Ser Lder al ao 2016, en la formacin de profesional Tcnico y Tcnico

productivo, identificados con el desarrollo local, regional y nacional; con perfiles
verificables que contribuyan a su realizacin personal y profesional para garantizar
su insercin al mercado laboral.
2.2.4. MISIN
Formar y capacitar a jvenes y adultos en carreras Tecnolgicas y Tcnico

Productivas para el logro de competencias laborales y capacidades
empresariales, que contribuya a un mejor desempeo de la persona que trabaja,
mejorando su posibilidad de empleo y su desarrollo personal; buscando una
insercin o reinsercin en el mercado laboral.
Desarrollar la investigacin e innovacin en nivel de especializacin y

perfeccionamiento en el campo de la educacin, el arte, la cultura, la ciencia y la
tecnologa a fin de cubrir las demandas, que el fenmeno de globalizacin ha
generado en nuestro pas; produciendo cambios en la organizacin del trabajo y
la productividad en el conjunto de nuestra poblacin.
2.2.5. ORGANIZACIN ACADEMICA
La Educacin Tcnico-Productiva est organizada en ciclos determinados por

las caractersticas y complejidades de los perfiles tcnico-profesionales y por
requerimientos acadmicos especficos. Los ciclos se organizan en mdulos

segn competencias productivas con valor para el empleo, debidamente
certificadas. No son sucesivos ni propeduticos. Las particularidades de cada ciclo
son las siguientes:
CICLO BSICO
El Ciclo Bsico de la Educacin Tcnico-Productiva provee al estudiante de

las competencias necesarias para ejecutar trabajos de menor complejidad que le
permitan incorporarse al mercado laboral. Se accede a dicho ciclo sin el requisito
de nivel educativo formal anterior. Cada mdulo es bloque coherente de
aprendizajes especficos y complementarios. Tiene carcter terminal y est
orientado a una opcin laboral especfica. Los estudiantes del Ciclo Bsico que
aprueben mdulos convergentes que correspondan, como mnimo, a un total de
1000 horas de estudio, respondan a un perfil tcnico profesional y cumplan los
requisitos para la titulacin, tienen derecho al ttulo de Auxiliar Tcnico.
CICLO MEDIO
Ciclo Medio de la Educacin Tcnico-Productiva provee al estudiante de las

competencias necesarias para el ejercicio de una actividad ocupacional
especializada. Para acceder a dicho ciclo se requieren competencias equivalentes
al segundo nivel de la Educacin Bsica.
Los estudiantes del Ciclo Medio que aprueben los mdulos de una especialidad
tcnico-productiva del Perfil Profesional que correspondan como mnimo a un total
de 2000 horas de estudio y cumplan los requisitos para la titulacin, tienen derecho
al Ttulo de Tcnico con mencin en la especialidad respectiva. Certificacin y
Titulacin.
Actualmente existen en el Per 1744 CETPRO.
2.3. TECNOLOGAS DE LA INFORMACIN EN EL CETPRO Y

..OTROS DE LA LOCALIDAD
Las tecnologas de informacin en el CETPRO, se encuentran en un estado

inicial presentando las siguientes caractersticas:

Son pocos los CETPRO estn dispuestas a invertir en un software que les
permita gestionar las diferentes etapas del proceso de produccin.
La hoja de clculo Excel es la principal herramienta para registrar, analizar
y comparar los movimientos de almacenes, insumos y mquinas.
El costo de produccin es obtenido de manera manual a partir de todos los
movimientos de almacenes directamente relacionados con el proceso
productivo. Una vez ms, la hoja de clculo Excel es empleada para
obtener el costo de produccin, lo cual deja abierta la posibilidad de
cometer toda clase de error humano.

3. CAPITULO 3: MARCO CONCEPTUAL
El presente captulo presenta una descripcin detallada de todos los

procesos productivos que intervienen durante la evaluacin de una actividad
productiva.
3.1. ACTIVIDAD PRODUCTIVA
Se denomina actividades productivas y empresariales a la produccin de

bienes o prestacin de servicios que realiza la institucin, en concordancia con la
capacidad instalada, potencial humano calificado y los ejes de desarrollo de la
localidad, en un marco de gestin empresarial.
La formulacin de actividades productivas y empresariales se realiza a travs

de proyectos productivos y de inversin, que son elaborados por los docentes,
estudiantes y otros agentes educativos, quienes presentan ante el Comit para su
evaluacin, aprobacin e inclusin en el Plan de Actividades Productivas y
Empresariales, teniendo en cuenta su dimensin y los requerimientos de las
fuentes de financiamiento.
Estas actividades productivas se planifican y ejecutan en base al D.S.N 028-

2007-ED, Reglamento de Gestin de Recursos Propios y Actividades Productivas
Empresariales en las Instituciones Educativas Pblicas.
A continuacin se extrae del D.S.N 028-2007-ED, relacionado al desarrollo de

actividades productivas.
Artculo 25.- Etapas de las Actividades Productivas y Empresariales. Las etapas

de actividades deben considerar lo siguiente:
a) Formulacin
b) Aprobacin
c) Ejecucin
d) Evaluacin
e) Informe final al comit

3.1.1. PRINCIPALES PUNTOS CRITICOS EN LA
APROBACION DE ACTIVIDADES PRODUCTIVAS
Para la ejecucin de cualquier actividad productiva es necesario que se

tomen en cuenta ciertos puntos crticos, si faltase alguno de ellos, lo ms probable
es que no se logre ejecutar la actividad productiva. Ellos son:
Materia Prima: Cantidad, calidad, precio.

Maquinaria, equipos y herramientas existentes en buen estado.
Recursos humanos (docentes y participantes capacitados).
Recursos econmicos (costos y financiamiento).
Infraestructura: Acorde para ejecutar la actividad productiva.
Tipos de financiamiento:
Prstamos con entidades financieras u otras de la comunidad sin afectar

el patrimonio institucional.
Contratos de produccin con instituciones del mismo sector u otros
sectores de la actividad pblica o privada.
Convenios con personas naturales o jurdicas, pblicas o privadas,
nacionales o internacionales.
Donaciones de instituciones pblicas o privadas para el financiamiento de
actividades productivas, como fondo rotatorio o capital inicial.
3.2. COSTOS
Costos es el sacrificio, o esfuerzo econmico que se debe realizar para lograr

un objetivo.
Los objetivos son aquellos de tipo operativos como, por ejemplo: pagar los
sueldos al personal de produccin, comprar materiales, fabricar un producto,
vender, prestar un servicio, obtener fondos para financiar, etc.
Si no se logra el objetivo deseado, decimos que tenemos una prdida.
Los costos se clasifican de acuerdo a categoras o grupos, de manera tal que

posean ciertas caractersticas comunes para poder realizar los clculos, el anlisis
y presentar la informacin que puede ser utilizada para la toma de decisiones:
Segn la funcin que cumplen: Costos de produccin, costos de
comercializacin, costos administrativos, costos de financiacin
Segn su grado de variabilidad: Costos fijos, costos variables
Segn su asignacin: Costos directos, costos indirectos
Segn su comportamiento: Costo variable unitario, costo variable total,
costo total fijo, costo fijo unitario, costo total
3.2.1. COSTOS DE PRODUCCIN
Costos de materia prima y materiales que intervienen en la produccin.

Costo de depreciacin
Hora de funcionamiento de la mquina = ((Precio de la mquina / Tiempo de

vida til) / 12) / Horas laborales al mes
Costos de agua, luz (dependiendo del proceso)

Costo de mano de obra.
Hora mano de obra = (costo de mano obra / das laborales al mes) / 8
3.2.2. COSTOS ADMINISTRATIVOS
Costos de transporte
Costos de agua, luz, telfono.
3.2.3. COSTOS DE COMERCIALIZACIN
Costos de propaganda, publicidad (volantes, afiches, etc.), bolsas, etc.
3.2.4. COSTOS DE FINANCIACIN
Intereses pagados por prstamos.

3.2.5. OPERACIONES
COSTO TOTAL = COSTO DE MATERIAS PRIMAS + COSTOS DE PRODUCCION

+ COSTOS ADMINISTRATIVOS + COSTOS DE
FINANCIACION.
COSTO UNITARIO = COSTO TOTAL / NUMERO DE UNIDADES PRODUCIDAS.
UTILIDAD TOTAL = ((% DE UTILIDAD)100) * COSTO TOTAL
UTILIDAD UNITARIA = UTILIDAD TOTAL / NUMERO DE UNIDADES PRODUCIDAS.
UTILIDAD NETA = UTILIDAD TOTAL (%IR * UTILIDAD TOTAL)
COSTO DE VENTA = COSTO TOTAL + UTILIDAD
PRECIO DE VENTA = COSTO DE VENTA + (COSTO DE VENTA * %IGV)

4. CAPITULO 4: ANLISIS
En este captulo se detalla la solucin informtica planteada en el marco

terico, para lo cual se sigue la metodologa RUP (Rational Unified Proccess), en
lo concerniente a la especificacin de requerimientos, anlisis y diseo del
sistema.
4.1. OBTENCIN DE REQUERIMIENTOS
El objetivo de esta etapa consiste en generar un listado de la especificacin

de requisitos del sistema que ayudarn a la Aprobacin de Actividades
Productivas. A partir de esta especificacin se podr detallar el anlisis y diseo
de la aplicacin que se ajuste a los requerimientos aqu expuestos.
4.1.1. ESPECIFICACIN DE REQUERIMIENTOS
A continuacin, se presentan los requisitos planteados para este proyecto,

clasificados de acuerdo a la funcionalidad.
4.1.1.1. REQUERIMIENTOS DE MANTENIMIENTOS
Estos requerimientos detallan lo correspondiente al mantenimiento del sistema:

(crear nuevo, eliminar) materiales, talleres, maquinas, turnos, responsables,
capital (dinero en efectivo), mdulos educativos.
REQ01 El sistema permitir crear un nuevo material de acuerdo a la necesidad

de los proyectos para ser actualizado posteriormente o eliminarlo.
REQ02 El sistema permitir crear nuevos talleres disponibles o cambiar de

cdigo.
REQ03 El sistema debe crear y eliminar responsables determinando su

participacin en algn proyecto.
REQ04 El sistema debe crear y eliminar nuevos mdulos educativos.
REQ05 El sistema debe actualizar o eliminar proyectos aprobados.

REQ06 El sistema permitir actualizar o eliminar capital (dinero) disponible.
REQ07 El sistema permitir actualizar o eliminar mquinas obtenidas.
REQ08 El sistema crear nuevos turnos para los proyectos aprobados.
REQ09 El sistema permitir actualizar o eliminar los turnos creados en la

asignacin a los proyectos
4.1.1.2. REQUERIMIENTOS DE RETIRO Y ASIGNACIN
Estos requerimientos describen el retiro y asignacin de recursos.
REQ10 El sistema asignar las mquinas de acuerdo a la necesidad del

proyecto.
REQ11 El sistema permitir registrar el retiro de artculos de almacn y

actualizar el stock.
REQ12 El sistema actualizar la disponibilidad de capital si necesitase algn

proyecto.
REQ13 El sistema asignar comisiones a los responsables que no participen en

otro proyecto.
REQ14 El sistema registrar el ingreso de nuevos capitales (dinero).
REQ15 El sistema asignar los talleres a los proyectos.
REQ16 El sistema debe ayudar a evaluar la viabilidad de un proyecto en funcin

a las utilidades que reporten.
4.1.1.3. REQUERIMIENTO DE GENERACIN DE COSTO

DE PRODUCCIN
Estos requerimientos describen las operaciones correspondientes a la

generacin automtica de costos, utilidades y valor de venta.
REQ17 El sistema permitir calcular el costo de produccin de proyectos

productivos.
4.1.1.4. REQUERIMIENTOS DE REPORTES
REQ18 El sistema permitir consultar y generar reportes de proyectos

aprobados.
4.1.1.5. REQUERIMIENTOS DE CONFIGURACIN
Estos requerimientos corresponden a todo lo concerniente con la

configuracin inicial del sistema de informacin.
REQ19 El sistema permitir configurar el porcentaje de aplicado a las

utilidades (impuesto a la renta).
REQ20 El sistema permitir configurar el porcentaje aplicado al precio de

venta (IGV).
REQ21 El sistema permitir configurar el monto a pagar de mano de obra

si necesitase adicionar como un costo.
4.1.2. DIAGRAMAS DE CASOS DE USO
Los diagramas de caso de uso muestran los distintos requisitos funcionales

que se esperan de una aplicacin o sistema y muestra cmo se relacionan con su
entorno (usuarios u otras aplicaciones). En la siguiente figura se muestran los
casos de uso concernientes a los requerimientos de mantenimiento.
Mantenimiento de mquinas
Mantenimiento de talleres
Mantenimiento de Proyecto
Personal de
Mantenimiento de artculos Operaciones
Mantenimiento de turnos
Mantenimiento de responsables
Mantenimiento de mdulos
FIGURA # 1 - Casos de uso requerimientos de mantenimiento.

En la siguiente figura se muestran los casos de uso concernientes a los
requerimientos de: Retiro, Asignacin y Configuracin.
Configuracion del sistema

Validar proyecto
Verificar disponibilidad de talleres Asignar comisin a responsables
Personal de
Produccin
Crear turno
Evaluar costos
Verificar disponibilidad de capital Verificar disponibilidad de

maquinas
Asignar Materiales
FIGURA # 2 - Casos de uso de: Retiro, Asignacin y Configuracin.
En la siguiente figura se muestran los casos de uso concernientes a los

requerimientos de reporte.
Personal de Personal de
Operaciones Produccin
Generacin de consultas y
reportes
FIGURA # 3 Caso de uso: Generacin de consultas y reportes
4.1.3. ESPECIFICACIONES DE CASOS DE USO

Las especificaciones de casos de uso sern abordadas en tres frentes de
acuerdo a la funcionalidad que realizan cada uno de estos frentes:
mantenimientos, transacciones, reportes y configuracin.
4.1.3.1. REQUERIMIENTO DE MANTENIMIENTO
Caso de Uso: Mantenimiento de Materiales
Requerimiento: REQ01
ID: CU01
Actor: Personal de Operaciones
Precondiciones:
1. El usuario deber estar logueado.

Flujo de eventos:
1. El caso de uso se inicia cuando el personal de operaciones ingresa al men

y selecciona la opcin Edicin / Actualizaciones / Materiales.
2. El sistema muestra botones: nuevo, actualizar, eliminar. Si es nuevo oprime

el botn nuevo.
3. El personal de operaciones ingresa los datos del material: Nombre, unidad

de medida.
Los valores de precio se ingresarn al momento del registro, el stock se

actualizar automticamente cada vez se ingrese nuevos materiales del
mismo tipo.
4. El sistema valida y guarda los datos ingresados.
Pos condiciones:
1. Artculo creado.
Flujo alternativo:
1. El personal tiene la opcin de modificar algn dato del artculo creado

o eliminarlo por completo de la Base de Datos. De querer realizar estas
operaciones, debe activar los botones necesarios.
2. Si existe un artculo con el mismo ID, el sistema reconocer esta
duplicidad no permitiendo crearlo.
Caso de Uso: Mantenimiento de Talleres

ID: CU02
Precondiciones:
Flujo de eventos:

y selecciona la opcin Edicin / Actualizaciones / Taller.

el botn nuevo.
3. El personal de operaciones ingresa los datos del taller: nmero, capacidad

y dimensin.
Pos condiciones:
1. Taller creado.
Flujo alternativo:
1. El personal tiene la opcin de modificar algn dato del taller creado o

eliminarlo por completo de la Base de Datos. De querer realizar estas
2. La duplicacin de ID de los talleres reconocer el sistema, no permitir
crearlo.
Caso de Uso: Mantenimiento de Responsables

ID: CU03
Precondiciones:
Flujo de eventos:

y selecciona la opcin Edicin / Actualizaciones / Responsables.
el botn nuevo.
3. El personal de operaciones ingresa los datos del responsable: DN,
nombres, apellido paterno, apellido materno, fecha de nacimiento,
direccin, telfono (opcional), actividad (Profesor, Alumno, si son otros
debe especificar).
Pos condiciones:
1. Responsable creado.
Flujo alternativo:
1. El personal tiene la opcin de modificar algn dato del responsable o

eliminar al responsable por completo de la Base de Datos. De querer
realizar estas operaciones, debe activar los botones necesarios.

Caso de Uso: Mantenimiento de Mdulos
ID: CU04
Precondiciones:
Flujo de eventos:

y selecciona la opcin Edicin / Actualizaciones / Mdulo.

el botn nuevo.
3. El personal de operaciones ingresa los datos del mdulo educativo:

Nombre, cdigo, ciclo (medio o bsico).
Pos condiciones:
1. Mdulo educativo creado.
Flujo alternativo:
1. El personal tiene la opcin de modificar algn dato del mdulo creado o


Caso de Uso: Mantenimiento de Proyectos
ID: CU05
Precondiciones:
Flujo de eventos:

y selecciona la opcin Edicin / Actualizaciones / Proyecto.
2. El sistema muestra botones: actualizar, eliminar.
El personal de operaciones solo tiene la autorizacin de actualizar y eliminar:
3. El personal elije un nmero de proyecto al cual quiere actualizar algunos

datos del proyecto aprobado.
4. El sistema valida y guarda los datos actualizados.
Pos condiciones:
1. Proyecto Actualizado.
Flujo alternativo:
1. El personal tiene la opcin de eliminar por completo de la Base de Datos

algunos proyectos que por algn motivo no se ejecutaron, el sistema debe
regresar los recursos empleados para actualizarlo en sus respectivas
tablas.

Caso de Uso: Mantenimiento de Capital
ID: CU06
Precondiciones:
Flujo de eventos:

y selecciona la opcin Edicin / Actualizaciones / Capital.
2. El sistema muestra botones: nuevo, actualizar, eliminar. Para ingresar un

nuevo capital (dinero) debe presionar el botn nuevo.
3. El personal ingresa los datos del nuevo capital: tipo (elige entre; prstamo,
donacin, contrato, convenio).
4. El personal ingresa nombre de la institucin, nmero de cuenta, direccin,

telfono, capital disponible, fecha de ingreso.
4. El sistema valida y guarda los datos actualizados.
Pos condiciones:
1. Proyecto Actualizado.
Flujo alternativo:
1. El personal tiene la opcin de eliminar por completo de la Base de Datos o

actualizar algunos datos.

Caso de Uso: Mantenimiento de Mquinas
ID: CU07
Precondiciones:
Flujo de eventos:

y selecciona la opcin Edicin / Actualizaciones / Mquinas.

el botn nuevo.
3. El personal de operaciones ingresa los datos mquina: Nombre, nmero

de mquina, ao de compra, precio, depreciacin, stock.
Las mquinas ingresadas con el mismo nmero actualizarn su stock
Pos condiciones:
1. Mquina creada.
Flujo alternativo:
1. El personal tiene la opcin de modificar algn dato de la mquina creada o

2. Si existe un artculo con el mismo ID, el sistema reconocer esta duplicidad
no permitiendo crearlo.

Caso de Uso: Crear turno
ID: CU08
Actor: Personal de Produccin
Precondiciones:
2. Haber ejecutado el caso de uso asignar talleres CU16.
Flujo de eventos:
La creacin de un nuevo turno esta de en funcin al proyecto que se est

evaluando, tambin en funcin a la disponibilidad de talleres y mquinas.
1. El caso de uso se inicia cuando el personal de produccin ingresa al men

y selecciona la opcin Archivo /Nuevo Proyecto , elige al opcin talleres.
El sistema muestra una ventana donde puede elegir los talleres, mquinas,
mdulo que estn disponibles.
2. El personal acepta estos recursos disponibles oprimiendo el botn aceptar.
3. Oprime el botn nuevo para crear el nuevo turno: ingresa horas, das.
Pos condiciones:
1. Turno creado.
Flujo alternativo:

Caso de Uso: Mantenimiento de Turno
ID: CU09
Precondiciones:
Flujo de eventos:

y selecciona la opcin Edicin / Actualizaciones / Turno.
2. El personal ingresa el cdigo de turno, el sistema muestra una tabla que

muestra: el mdulo, das, horas, numero de taller.
3. El personal elige el cdigo de turno para actualizar, ingresa los nuevos

datos.
Pos condiciones:
1. Turno modificado.
Flujo alternativo:
1. El personal tiene la opcin de eliminarlo por completo de la Base de Datos.

De querer realizar esta operacin debe activar los botones necesarios.

Caso de Uso: Asignar mquina a proyecto
ID: CU10
Precondiciones:
2. Haber ejecutado el caso de uso CU17, evaluar costos.
Flujo de eventos:
Este caso de uso se genera en el proceso de evaluacin del proyecto.
La asignacin de las mquinas a los proyectos est en funcin al stock de

estas, disponibilidad en horarios y necesidad de cada proyecto.

y selecciona la opcin Archivo /Nuevo Proyecto / costos.
Presentar una ventana de evaluacin de costos.
2. El sistema muestra botn Mquinas, la ventana siguiente le muestra una

tabla con el nombre de los proyectos donde estn siendo utilizados, el
horario, los das, talleres y stock.
3. El personal ingresa la cantidad de mquinas a utilizar en el proyecto.
4. Oprime el botn aceptar, el sistema valida y guarda los datos ingresados.
Pos condiciones:
1. Mquina asignada.

4.1.1.1. REQUERIMIENTO DE RETIRO Y ASIGNACIN
Caso de Uso: Verificar disponibilidad de Materiales
ID: CU11
Precondiciones:
2. Haber ejecutado el caso de uso CU17 correspondiente a evaluar costos.

Flujo de eventos:

y selecciona la opcin Archivo / Nuevo Proyecto, selecciona el botn
COSTOS.
Visualiza una ventana de costos, para el cual debe iniciar asignando los
materiales que emplear en el proyecto.
2. El personal de seleccionar el botn MATERIALES, visualiza la ventana con

la relacin de materiales con que se cuenta.
3. El personal selecciona los materiales una a una ingresando la cantidad a

emplearse en el proyecto,
4. Al salir de la ventana de seleccin de materiales calcular el costo de lo

seleccionado.
5. Al oprimir el botn ACEPTAR, el sistema actualizar el stock de la lista de

materiales seleccionados.
Pos condiciones:
1. Stock de Material actualizado.
Flujo alternativo:
1. El personal tiene la opcin de volver a rectificar o adicionar materiales antes

de registrar la actualizacin del stock.
2. Si el retiro de materiales es mayor al stock, el sistema automticamente
emitir un mensaje de exceso en el pedido anulando este pedido
permitindole ingresar nuevos valores de acorde al stock existente.

Caso de Uso: Verificar disponibilidad de capital
ID: CU12
Precondiciones:
Flujo de eventos:
La verificacin de capital (dinero) si algn proyecto necesitara un adicional

para efectuar el proyecto productivo.

y selecciona la opcin Archivo /Nuevo Proyecto, y oprime el botn
CAPITAL.
2. El personal tiene la posibilidad de seleccionar entre cuatro alternativas:

prstamo, donacin, contrato, convenio. Selecciona prstamo.
3. El sistema le muestra la relacin de entidades financieras del cual debe

elegir uno de ellos. Selecciona una entidad.
4. El sistema muestra los datos de la entidad seleccionada adems del monto

disponible. El personal ingresa la cantidad a retirar para emplearse en la
ejecucin del proyecto.
La disponibilidad de los montos de capital se actualizar al momento de

aprobar el proyecto, de este modo quedar registrado el monto de retiro por
cada proyecto.
Pos condiciones:
1. Retiro de capital.
Flujo alternativo:
1. Si el proyecto no necesitase un adicional en dinero para ejecutarse, el

personal debe presionar el botn SIN CAPITAL.

Caso de Uso: Asignar comisin a responsables
ID: CU10
Precondiciones:
2. Haber ejecutado el caso de uso CU17, correspondiente: Validacin de

proyecto.
Para asignar comisin al responsable debe existir en la base de datos
proyectos aprobados.
Flujo de eventos:

y selecciona la opcin Archivo /Asignar Comisin.
Presentar una ventana para la bsqueda de los responsables.
2. El personal ingresa el DNI del responsable que se desea asignarle un

proyecto.
El sistema emite un mensaje si el responsable est asignado a algn proyecto.
3. El personal luego de la verificacin oprime el botn AGREGAR

RESPONSABLE.
Al agregar responsables a un determinado proyecto, el sistema crea una

lista, esta se actualiza al momento de aprobar el proyecto
Pos condiciones:
1. Responsable asignado a un proyecto.
Flujo alternativo:
1. Si desea agregar, presiona el botn CANCELAR.

Caso de Uso: Asignar mquina a proyecto
ID: CU14
Precondiciones:
2. Haber ejecutado los casos de uso CU17 correspondiente: Evaluacin de

costos.
Flujo de eventos:
La asignacin de las mquinas a los proyectos est en funcin al stock de

estas y a la disponibilidad en horarios.

y selecciona la opcin Archivo /Nuevo Proyecto / Costos.
Presentar una ventana de la evaluacin de costos.
2. El sistema muestra botn maquinas, la ventana siguiente le muestra una

tabla con los nombre de los proyectos donde estn siendo utilizados, el
horario, los das , talleres y stock.
3. El personal selecciona la maquina y la cantidad de mquinas a utilizar en el

proyecto.
El sistema totaliza el costo de la depreciacin del grupo de mquinas que

se hayan seleccionado, y los enva a la hoja anterior para la evaluacin de
costos.
4. Oprime el botn aceptar, el sistema valida y guarda los datos ingresados.
Pos condiciones:
1. Mquina asignada.
Flujo alternativo:

Caso de Uso: Verificar disponibilidad de talleres
ID: CU15
Precondiciones:
Flujo de eventos:
Este caso de uso se realiza en el proceso de evaluacin de un proyecto.

y selecciona la opcin Archivo / Nuevo Proyecto, oprime el botn
TALLER.
2. El sistema muestra una lista del cdigo de los talleres disponibles, el

personal elige uno de ellos asignndole un turno.
El cdigo de turno debe ser nico.
Pos condiciones:
1. Taller asignado.
Flujo alternativo:

Caso de Uso: Validar Proyecto
ID: CU16
Precondiciones:
2. Haber ejecutado los casos de uso CU17, CU12, CU15 correspondientes:

Evaluar costos, Verificar disponibilidad de talleres, Verificar disponibilidad
de capital, respectivamente
Flujo de eventos:
Luego que le personal de produccin haya verificado que el proyecto

genera buena utilidad, adems la disponibilidad de: talleres, mquinas y
capital si lo necesitase, procede a:
1. Ingresa el nombre del proyecto, nmero de proyecto, selecciona Aprobado.
2. El sistema valida, actualiza los datos de la lista: Materiales (que se

seleccionaron), capital que se utilizar, taller a usarse, asignacin de
mquinas, costos y utilidad.
Pos condiciones:
1. Proyecto aprobado.
Flujo alternativo:
1. El personal tiene la opcin de CANCELAR, el sistema limpia la lista de

recursos seleccionados para el uso en el proyecto.

4.1.1.2. REQUERIMIENTO DE COSTOS DE PRODUCCIN
Caso de Uso: Evaluar Costos
ID: CU17
Precondiciones:
Flujo de eventos:
1. El caso de uso inicia ingresando al men Archivo / Nuevo Proyecto,

oprime el botn COSTOS.
Para iniciar con el clculo de costos, inicialmente debe configurar el

sistema (porcentaje del impuesto a la renta, porcentaje de igv, costo
de mano de obra, costo total de los servicios).
2. Ingresa la fecha de inicio y fin del proyecto.

3. Selecciona si el proyecto se desarrollar en uno o varios turnos (cada turno
se desarrolla en 4 horas).
Iniciamos calculando el costo de materia prima.
4. Oprime el botn MATERIALES, el cual le permite seleccionar de la lista

de materiales con que se cuenta. Vuelve a la ventana anterior luego de
seleccionar los materiales.
5. Presiona el botn COSTO TOTAL DE MATERIA PRIMA, El sistema

imprime en la casilla de materiales el costo total de los materiales
seleccionados.
Calculamos el costo de la depreciacin de las mquinas a emplearse.
6. El personal oprime el botn MAQUINAS, se muestra una lista con el nombre

del proyecto, das, horario.
7. Selecciona las mquinas a emplearse en el proyecto. (El sistema evaluar
el costo total de depreciacin de las mquinas y lo enviar a la ventana
anterior). Terminada la operacin regresa a la ventana anterior.
8. El personal presiona el botn CAPITAL para adicionar dinero si necesita el
proyecto. (El sistema debe adicionar inters al monto retirado si es un
prstamo; ningn inters si el retiro corresponde a una donacin, convenio,
contrato). Terminada la operacin regresa a la ventana anterior.
9. Ingresa el porcentaje del costo de servicios que le corresponde al proyecto.

10. Ingresa la cantidad de personal remunerado que trabajarn en dicho
proyecto.
11. Ingresa el precio de venta por producto.
12. Ingresa las unidades a producir.
13. Presiona UTILIDAD.
El sistema debe evaluar el costo total, utilidad total, precio de venta

ms IGV.

Pos condiciones:
1. Costo evaluado.
Flujo alternativo:
1. El personal tiene la opcin de CANCELAR, el sistema limpia la lista de

materiales seleccionados y dems valores.
4.1.1.3. REQUERIMIENTO DE CONFIGURACIN
Caso de Uso: Actualizacin Impuesto a la Renta
ID: CU19
Precondiciones:
Flujo de eventos:
Este caso de uso se realiza en el proceso de evaluacin de un proyecto.

y selecciona la opcin Edicin / Configuraciones.
El sistema muestra una ventana.
2. El personal ingresa valores a Costo de mano de obra por persona,

porcentaje impuesto a la renta, porcentaje de IGV, costo de los servicios
(luz, agua, telfono).
3. Presiona el botn actualizar.

4.2. DIAGRAMA DE CLASES
La etapa de anlisis consiste en obtener un modelo preciso y comprensible,

aplicable al CETPRO. Esto se logra luego de entender cada uno de los
requerimientos planteados y de especificarlos en casos de usos. En esta etapa se
detallan los diagramas de clases de anlisis y de secuencia de los casos de usos
especificados en el punto anterior. A continuacin, se presenta el diagrama de
clases de anlisis correspondiente a los casos de uso especificados.
FIGURA # 4 Diagrama de Clases

4.3. DIAGRAMA DE SECUENCIA
Los diagramas de secuencia muestran los objetos que intervienen para cada
caso de uso con lneas discontinuas verticales, y los mensajes pasados entre los
objetos como vectores horizontales. Los mensajes se dibujan cronolgicamente
desde la parte superior del diagrama a la parte inferior; la distribucin horizontal
de los objetos es arbitraria. A continuacin, se mostrarn los diagramas de
secuencia correspondiente a los casos de uso descritos.
:interfaz :taller :turno
:Personal de
Produccion : NewClass
1: Ingreso a verificar taller
2: solicitud de talleres disponibles
3: relacion de talleres
4: ingreso datos para nuevo turno
5: confirmacion de turno creado
6: confirmacion taller creado
FIGURA # 5 Diagrama de Secuencia asignacin de turno a talleres segn su

disponibilidad.

:interfaz :responsable
: Personal de
Produccin 1: ingreso a asignar responsable
2: solicitud datos responsable
3: respuesta a solicitud
4: respuesta a solicitud
5: asignar comisin
6: actualiza responsable
7: actualizacin registrada
8: confirmaci de actualizacin
FIGURA # 6 Diagrama de Secuencia en la asignacin de responsabilidades a

los participantes en el desarrollo de un proyecto productivo.

:interfaz :proyecto ;gestor de ;material :maquina :capital
costos
: Personal
Produccion
1: pedido evaluar costos
2: pedido ingreso a costos
3: respuesta de solicitud
4: ingreso periodo de duracion proyecto
5: consulta relacion materiales
6: respuesta con relacion de materiales
7: selecciona materiales y cantidad a emplearse
8: costo material
9: consulta relacion de maquinas
10: respuesta con relacion de maquinas
11: selecciona maquina y cantidad a emplearse
12: costo depreciacion
13: consulta relacin disponibilidad de capital
14: respuesta con relacion de entidades de capital
15: selecciona el tipo de financiamiento
16: monto a emplearse
17: suma parciales de costo
18: ingreso de costos faltantes
19: resultado de costos
20: confirmacion de costos
FIGURA # 7 Diagrama de Secuencia en el proceso de costeo de un proyecto

productivo

5. CAPITULO 5: DISEO
5.1. DIAGRAMA DE BASE DE DATOS

5.2. PROTOTIPO DE PANTALLAS
A continuacin, se presentarn el diseo de las pantallas correspondientes a los casos

de uso ms significativos del presente proyecto.
1. Pantalla inicial.
Ventana de acceso al sistema
Men Principal

Caso de Uso: Evaluar Costos
ID CU17
Descripcin:
A travs de este mdulo el personal evaluar el costo de produccin, que luego permitir
aprobar el proyecto en estudio.
El personal primero debe ingresar la fecha de inicio y fin de ejecucin del proyecto, este
dato nos permitir calcular al sistema el costo de mano de obra, depreciacin y los intereses
por pagar si el financiamiento se realiz por prstamo. Segundo debe seleccionar en cuantos
turnos se ejecutar el proyecto. Se procede a asignar los recursos necesarios para el proyecto
en el orden que los botones muestran. Finalmente ingresa valores: el porcentaje del total de
servicios que corresponde a este proyecto, cuantos remunerados participarn en el proyecto,
otros gastos, unidades a producir, precio de venta sugerido.

Caso de Uso: Mantenimiento de Responsables
ID CU03
ACTOR: Personal de Operaciones
DESCRIPCION:
Con este mdulo el personal inscribe nuevos responsables para la ejecucin de los
proyectos, puede actualizarlos o eliminarlos

Caso de Uso: Crear turno
ID CU08
ACTOR: Personal de Produccin

DESCRIPCION:
Con este mdulo el personal crea un turno para el taller donde se ejecutar el proyecto.
Tiene la posibilidad de observar los talleres ocupados segn los turnos por mdulo educativo.

Caso de uso: Asignar mquina a proyecto
ID CU10
DESCRIPCION:
Este mdulo permite asignar maquinas al proyecto segn su necesidad. Muestra una tabla
de los proyectos donde estn haciendo uso de estas mquinas.

Caso de Uso: Verificar disponibilidad de Materiales
ID: CU11
DESCRIPCION:
Este mdulo permite retirar los materiales que emplear el proyecto.

6. CAPITULO 6: CONCLUSIONES
El empleo del RUP y UML ha sido muy eficaz para definir las pautas de la
construccin del software y para modelar los principales diagramas de las fases
de anlisis y diseo del sistema de informacin de evaluacin y costeo de las
Actividades Productivas.
ASP.Net MVC y SQL Server son herramientas potentes y al alcance (en cuestin
de costos y disponibilidad) de instituciones pblicas, debido a que soportan de
manera ptima el nmero de transacciones.
Con la implementacin del sistema de informacin de evaluacin y costos la
trazabilidad del producto terminado, la cual es necesaria para cumplir con las
exigencias de los clientes y consumidores.
De implementarse esta solucin mejora la obtencin de costos exactos y de
manera oportuna.

BIBLIOGRAFA
1. Stephen R. Schach Anlisis y diseo orientado a objetos con UML y el proceso

unificado. Mc Graw Hill
2. M. Prez Microsoft SQL Server 2008 R2

Motor de Base de Datos y Administracin
3. Hernaldo Gonzles Candia

MVC 4 con. NET Desde Cero
4. Guerin Brice Arnaud

ASP.Net 4.5 en C#
Diseo y desarrollo de aplicaciones Web
5. Nassir Sapag Chain

Preparacin y Evaluacin de Proyectos
Mc Graw Hill

PROYECTO

Transféré par

Informations du document

Copyright

Formats disponibles

Partager ce document

Partager ou intégrer le document

Options de partage

Avez-vous trouvé ce document utile ?

Ce contenu est-il inapproprié ?

Droits d'auteur :

Formats disponibles

PROYECTO

Transféré par

Droits d'auteur :

Formats disponibles

|

UNIVERSIDAD PERUANA LOS ANDES

Aprobacin de Actividad Productiva - CETPRO

Flix Cuya Mamani

Carlos Boris Carrasco Infanzon

Zuly Susana Yupanqui Mucharo

Ing. Flix Richar Mendoza Pumacahua

1. CAPITULO 1: OBJETIVO Y ALCANCE DELPROYECTO.................................................................................. 5

1.1. OBJETIVO DEL PROYECTO.................................................................................................................... 5

1.2. ALCANCES DEL PROYECTO .................................................................................................................. 5

1.2.1. ALCANCES FUNCIONALES .................................................................................................................... 5

1.2.2. ALCANCES TCNICOS ........................................................................................................................... 5

1.3. BENEFICIOS DE AUTOMATIZAR LA APROBACION DE .ACTIVIDADES PRODUCTIVAS ........................... 6

2. CAPITULO 2: MARCO TEORICO .............................................................................................................. 7

2.1. METODOS Y TECNOLOGIA ................................................................................................................... 7

2.1.1. PROCESO UNIFICADO DE RATIONAL ................................................................................................... 7

2.1.2. UNIFIED MODELING LANGUAJE ( UML )............................................................................................ 12

2.1.3. APLICACIONES WEB .............................................................................. Error! Bookmark not defined.

2.1.4. SQL SERVER 2008 R2 EXPRESS............................................................... Error! Bookmark not defined.

2.2. MARCO CONTEXTUAL DE LOS CENTROS DE EDUCACION ..TECNICO PRODUCTIVA .......................... 31

2.2.1. CARACTERSTICAS ............................................................................................................................. 31

2.2.2. OBJETIVOS ....................................................................................................................................... 322

2.2.3. VISIN ............................................................................................................................................... 32

2.2.4. MISIN .............................................................................................................................................. 33

2.2.5. ORGANIZACIN ACADEMICA ............................................................................................................ 32

2.3. TECNOLOGAS DE LA INFORMACIN EN EL CETPRO Y ..OTROS DE LA LOCALIDAD........................... 34

3. CAPITULO 3: MARCO CONCEPTUAL ..................................................................................................... 35

3.1. ACTIVIDAD PRODUCTIVA .................................................................................................................. 35

3.1.1. PRINCIPALES PUNTOS CRITICOS EN LA APROBACION DE ACTIVIDADES PRODUCTIVAS .............. 36

3.2. COSTOS ............................................................................................................................................. 36

Asignatura: Ingeniera de Software 1

3.2.2. COSTOS ADMINISTRATIVOS .............................................................................................................. 37

3.2.3. COSTOS DE COMERCIALIZACIN ....................................................................................................... 37

3.2.4. COSTOS DE FINANCIACIN ............................................................................................................... 37

3.2.5. OPERACIONES ................................................................................................................................... 38

4. CAPITULO 4: ANLISIS ......................................................................................................................... 39

4.1. OBTENCIN DE REQUERIMIENTOS ................................................................................................... 39

4.1.1. ESPECIFICACIN DE REQUERIMIENTOS ............................................................................................ 39

4.1.1.1. REQUERIMIENTOS DE MANTENIMIENTOS ................................................................................... 39

4.1.1.2. REQUERIMIENTOS DE RETIRO Y ASIGNACIN .............................................................................. 40

4.1.1.3. REQUERIMIENTO DE GENERACIN DE COSTO DE PRODUCCIN................................................. 40

4.1.1.4. REQUERIMIENTOS DE REPORTES ................................................................................................. 41

4.1.1.5. REQUERIMIENTOS DE CONFIGURACIN ...................................................................................... 41

4.1.2. DIAGRAMAS DE CASOS DE USO ........................................................................................................ 41

4.1.3. ESPECIFICACIONES DE CASOS DE USO .............................................................................................. 43

4.1.3.1. REQUERIMIENTO DE MANTENIMIENTO ....................................................................................... 43

4.1.3.2. REQUERIMIENTO DE RETIRO Y ASIGNACIN ............................................................................... 53

4.1.3.3. REQUERIMIENTO DE COSTOS DE PRODUCCIN .......................................................................... 59

4.1.3.4. REQUERIMIENTO DE CONFIGURACIN ........................................................................................ 60

4.2. DIAGRAMA DE CLASES ...................................................................................................................... 61

4.3. DIAGRAMA DE SECUENCIA ................................................................................................................ 62

5. CAPITULO 5 : DISEO ........................................................................................................................... 65

5.1. DIAGRAMA DE BASE DE DATOS......................................................................................................... 65

5.2. PROTOTIPO DE PANTALLAS ............................................................................................................... 66

6. CAPITULO 6: CONCLUSIONES ............................................................................................................. 72

Asignatura: Ingeniera de Software 2

Asignatura: Ingeniera de Software 3

La Aprobacin de Actividad Productiva busca recopilar, crear y analizar en

Uno de los principales intereses del Centro de Educacin Tcnico Productivo

En el mercado del software existen varias herramientas orientadas a la

El presente trabajo plantea el anlisis y diseo de un sistema de informacin

Asignatura: Ingeniera de Software 4

En este captulo se detallan el objetivo y los alcances de este trabajo, adems

1.1. OBJETIVO DEL PROYECTO