RUP

RESUMEN
Durante mucho tiempo se ha utiliza¬do el tradicional modelo en cascada, el cual ha demostrado que no refleja adecuadamente la complejidad inhe¬rente al proceso de desarrollo de soft¬ware. Los problemas que presenta este modelo nacen de su propia estructu¬ra, al ser una secuencia de grandes etapas que requieren como hitos la documentación completa antes de con¬tinuar con la siguiente etapa.
Para solucionar este problema se debe hacer uso de métodos iterativos e incrementales, que unidos a otras prácticas claves como la orientación al man ejo de riesgos y la planeación adaptable, permiten de forma natu¬ral guiar adecuadamente el proceso
de desarrollo de software. En espe¬cial se considerará el RUP1 de IBM, basado en el modelo en espiral que organ iza las iteraciones por etapas y fases para obtener una estructura más sólida, clara y ajustable a las necesidades particulares de cada or¬ganización.
Este artículo tiene como objetivo des¬cribir en forma general el desarrollo iterativo, y las ventajas que ofrece su utilización en los procesos de desarro¬llo de software.
PALABRAS CLAVES
Modelo en espiral, desarrollo iterati¬vo, proceso unificado de rational
INTRO D U CCI ÓN
En los proyectos de tecnología se han incorporado paulatinamente los cam¬bios en los métodos de ingeniería, pero, desafortunadamente, no se ha hecho lo mismo en su administración. A continuación se mostrará una vi¬sión general de los cambios en los ci¬clos de vida de los proyectos, señalan¬do sus ventajas, desventajas y el por qué de dicha evolución.
Existe un conjunto de modelos de ci¬clo de vida en la gerencia de proyec¬tos que han evolucionado desde el tra¬dicional modelo en cascada, pasando por algunas propuestas de mejora¬miento como son el caso de cascadas con fases solapadas o cascada con subproyectos. Estos modelos no per¬miten una identificación temprana de los riesgos, los cuales pueden apare¬cer en las etapas finales del desarro¬llo o implantación, momento en que un cambio en el diseño del producto, en la arquitectura del sistema o en la infraestructura de software y hard¬ware puede llevar al fracaso comple¬to del proyecto.
Estos modelos son muy prácticos para proyectos pequeños y con muy bajos niveles de riesgos, tales como proyec¬tos de nuevas versiones de algún soft¬ware existente, donde haya requeri¬mientos claros y cuya arquitectura e infraestructura de software y hard¬ware no van a cambiar mucho respec¬to a la versión anterior.
Como respuesta al problema presen¬tado por los modelos anteriores, los ciclos de vida evolucionaron y se han presentado propuestas como el mode- lo de entrega por etapas y el de en¬trega evolutiva. Cada uno de ellos adicionó mayores niveles de comple¬jidad a la administración, pero ase¬guran poseer un marco de trabajo más sólido y ajustado para el desarro¬llo de proyectos con niveles modera¬dos de riesgo. Se requería de todas for¬mas un modelo de ciclo de vida de pro¬yectos que trabajara adecuadamente con niveles altos de riesgo, así que se desarrolló el modelo en espiral. Este modelo tiene como objetivos la identi¬ficación de los riesgos para determi¬nar la viabilidad del proyecto y defi¬nir planes de manejo para garantizar desde las fases iniciales la eliminación o mitigación de los riesgos donde es menos costoso y la entrega desde las faces iniciales de productos probados, lo que permite un proceso continuo de pruebas y retroalimentación.
PRÁCTICAS CLAVES DEL PROCESO DE DESARROLLO DE SOFTWARE
• Desarrollo iterativo
El desarrollo iterativo es un método de con strucción de productos cuyo ci¬clo de vida está compuesto por un con- junto de iteraciones, las cuales tienen como objetivo entregar versiones del software. Cada iteración se conside¬ra un subproyecto que genera produc¬tos de software y no sólo documenta¬ción, permitiendo al usuario tener puntos de verificación y control más rápidos e induciendo un proceso con¬tinuo de pruebas y de integración desde las primeras iteraciones.
Las iteraciones están compuestas por el conjunto de disciplinas o activida¬des ya conocidas en el proceso de de¬sarrollo de software. Estas son la es¬pecificación de requerimientos, el análisis y diseño, las pruebas, la ad¬ministración de la configuración y el proceso de gerencia de proyectos. En la Figura 1 se muestra gráficamente la relación existente entre las disci¬plinas o actividades y las iteraciones.
Figura 1. Disciplinas a través de las iteraciones.



Fuente: IBM RUP Rational Unified Process® Versión 2002.05.00. Rational Software Corporation.









A través del tiempo se han formali¬zado algunos métodos de desarrollo iterativo, tales como Evo, Microsoft Solution Framework, modelo en es¬piral WinWin y UP. Este artículo se centrará en el método de desarrollo iterativo conocido como Proceso Uni¬ficado o UP.
• Orientación al manejo del riesgo Cada proyecto tiene asociado intrín¬secamente un conjunto de riesgos que requieren un plan de manejo clara¬mente establecido, documentado y con una implementación eficaz. De esta manera se pretende evitar posi¬bles retrasos en los tiempos de entre¬ga, problemas de calidad en el pro¬ducto o en el peor de los casos, que puedan afectar la culminación del proyecto. Estos procesos pueden ser tan complejos y elaborados como la importancia del proyecto lo requiera.
En las etapas iniciales se implemen¬tan las funcionalidades con mayor exposición al riesgo y las de mayor complejidad, mejorando la posibilidad de éxito del proyecto.
Figura 2. Perfiles de riesgo.

Fuente: Principles of Managing Iterative Development v.2.0 Rational Software Cor¬poration.
En la fase inicial del proyecto, el ni¬vel de exposición al riesgo en ambos modelos es casi igual, pero en las fa¬ses siguientes es completamente di¬ferente para cada modelo (Ver Figu¬ra 2). Este comportamiento se debe al período de exploración de riesgos del modelo en espiral, donde se iden¬tifican los riesgos, se priorizan y se define un plan de man ejo para miti¬garlos. Se procede a la fase de elabo¬ración donde se implementan aque¬llos casos de uso que atacan los ries¬gos de más alta prioridad, lo cual se denomina período de resolución de riesgos. Al final de esta fase se debe tener definida la arquitectura del sis¬tema, así como la infraestructura en la que se soportará.
• Orientación al cliente
Cuando se inicia un proyecto de desarrollo de software se conoce la im¬portancia de la participación del cliente para lograr su terminación exitosa, pero usualmente cometemos el error de olvidar esta norma bási¬ca, lo que implica que la participación del cliente se restringe al inicio y fi¬nalización del proyecto, lo que en la mayoría de los casos produce un alto grado de insatisfacción en el usuario, al no obtener el producto con las especificaciones esperadas.
El cliente es quien realmente con oce el valor que aportará el producto que está siendo desarrollado y puede de¬finir las prioridades desde la perspec¬tiva organizacional. Esto quiere de cir que es necesario contar con su participación en el proceso de plani¬ficación de las fases y de las iteracio¬nes. Posteriormente se requiere su participación en cada iteración para proveer retroalimentación temprana al equipo de desarrolladores, garan¬tizando el cumplimiento de las expec¬tativas que tiene, además de ofrecer¬le una visibilidad permanente del estado del proyecto, asegurando su compromiso para terminarlo exitosa¬m ent e.
Se debe tener en cuenta que el clien¬te no se interesa por los aspectos téc¬nicos de alta complejidad y riesgo, razón por la cual se debe combinar esta práctica con una orientación al manejo del riesgo.
• Desarrollo evolutivo
Cuando se trabaja con una especifi¬cación de requerimientos monolítica, se cae en el error de creer que se com¬prende completamente el concepto del producto sin haberlo validado con el cliente con algo más que documen¬tos y modelos abstractos. Este proce¬so inicia con un concepto poco claro del producto a construir, y sólo se tie¬ne claridad en la medida que se vaya desarrollando y verificando el produc¬to con el cliente. Este tipo de proyec¬tos se asemejan más al patrón que siguen los proyectos de investigación y desarrollo de nuevos productos.
Estas prácticas claves en el desarro¬llo de software son implementadas en algunos métodos tales como Evo2, el modelo en espiral y el proceso unifi¬cado (UP), siendo los dos últimos los que mayor trascendencia han tenido y serán explicados a continuación.

MODELO EN ESPIRAL
El modelo en espiral se centra en al¬gunas prácticas fundamentales del desarrollo de software, tales como la orientación al manejo de riesgos, la orientación al cliente y el desarrollo iterativo (Ver Figura 3). El modelo se organiza en un conjunto de iteracio¬nes que pueden con siderarse a sí mis¬mas como pequeños proyectos que siguen el ciclo de vida completo. Las primeras iteraciones tienen como ob¬jetivo identificar los riesgos del pro¬yecto para determinar su viabilidad, y en caso de seguir adelante, definir un plan de manejo para mitigarlos o eliminarlos. Adicionalmente, el usua¬rio participa activamente en la prio¬rización de los casos de uso a desa¬rrollar y en el proceso de pruebas, con lo cual se logra obtener una funcio¬nalidad estable y operativa desde las primeras iteraciones del proyecto.





Figura 3. Mapa conceptual del modelo en espiral.



Fuente: Barry Boehm, “A Spiral Model of Software Development and Enhancement
El modelo en espiral tiene muchas ventajas respecto a los modelos ante¬riores por su orientación a la resolu¬ción temprana de riesgos, por la defi¬nición de la








En términos generales este mo¬delo tiene un nivel alto de compleji¬dad y requiere mucha destreza admi¬nistrativa y experiencia por parte del gerente del proyecto y su grupo de trabajo para manejarlo adecuada¬m ent e.
Este modelo es ideal para manejar proyectos que requieran la incorporación de nuevas tecnologías, o para desarrollar productos completamen¬te nuevos o con un nivel alto de ines¬tabilidad de los requerimientos. Tí¬picamente se maneja una iteración inicial donde se define el alcance del proyecto, se identifican y priorizan los riesgos y se realiza el modelo de ca¬sos de uso inicial para determinar qué casos de uso definirán la arquitectu¬ra del sistema. Con la información anterior se procede a definir el plan de manejo de riesgos según su priori- dad, así como los casos de uso que serán implementados en las siguien¬tes iteraciones (Ver Figura 4).

Figura 4. Modelo en espiral.



















Fuente: Desarrollo y Gestión de Proyectos Informáticos. Steve McConnell, McGraw
ITERACION ES
Una iteración es una secuencia de actividades dentro de un plan esta¬blecido, con unos criterios claros de evaluación, que se organiza con el propósito de entregar parte de la fun¬cionalidad del producto. En las pri¬meras iteraciones se desarrollan o implementan los casos de uso que tie¬nen mayor complejidad y que llevan inherente un alto nivel de riesgo que puede afectar el éxito del proyecto. De esta forma, con cada iteración que se realiza, los riesgos del proyecto se re¬ducen acorde con el plan establecido, el cual está en permanente revisión para monitorear la posible aparición de nuevos riesgos y ajustarlo si es necesario.
La selección de los casos de uso para cada iteración se hace teniendo en cuenta cuál es el mínimo conjunto de ellos que se requiere para implemen¬tar la funcionalidad que mayor ries¬go tenga. Se debe realizar este proce¬so hasta que la lista de riesgos haya sido cubierta completamente.
Cada iteración puede tener uno o va¬rios propósitos, lo cual determina la duración de la misma; a su vez se eje¬cutan varios procesos que van desde
la especificación de requerimientos hasta las pruebas de unidad e inte¬gración, lo cual se asimila a un ciclo de vida en cascada. Adicionalmente, al final de cada iteración se deben evaluar los resultados del trabajo y se planea detalladamente la siguien¬te iteración.
INCORPORANDO EL PROCESO UNIFICADO DE DESARROLLO DE RATIONAL
La concepción de un sistema de infor¬mación va mucho más allá de levan¬tar los requerimientos, elaborar un conjunto de modelos y comenzar a pro¬gramar. Esta concepción limitada ha permitido que durante años no poda¬mos hacer uso adecuado de los concep¬tos y las herramientas con los que con¬tamos. En este punto podemos consi¬derar que la definición de la arquitec¬tura del software se convierte en el eje orientador que permite controlar el desarrollo iterativo e incremental del sistema, a través de su ciclo de vida. Esta arquitectura se define en las pri¬meras fases del proyecto, básicamen¬te en la de elaboración, y se refina a través de todo el proyecto.
El RUP se fundamenta en seis prác¬ticas: el desarrollo iterativo, la admi¬nistración de requerimientos, la ar¬quitectura basada en componentes, en el modelamiento visual, en la ve¬rificación continua de la calidad y la administración del cambio. Estas seis prácticas orientan el modelo y con ellas se pretende solucionar muchos de los problemas asociados al soft¬ware. Adicionalmente hay muchos aspectos de diseño que son bien co¬nocidos, pero que en realidad han sido muy poco implementados en los pro¬yectos de software; estos son: facili dad de uso, modularidad, encapsu¬lamiento y facilidad de manteni¬miento. Es necesario entonces defi¬nir una arquitectura sólida basada en componentes, para construir me¬jores y más flexibles soluciones de software para las necesidades orga¬nizacionales.
Los cambios en un proyecto no pue¬den ser detenidos dado que la evolu¬ción del entorno de cada organización es continua, pero sí pueden ser ad¬ministrados de manera que su impac¬to pueda ser estimado para determi¬nar si dicho cambio se incluye o no y si el proyecto debe ser reajustado. Cada cambio en el proyecto debe te¬ner especificado cuándo y cómo se va a realizar, quién lo va a hacer y qué productos se ven involucrados en ese cambio. En ese punto es donde el con¬trol de cambios y la trazabilidad de los componentes a través de los di- versos modelos adquieren una gran importancia.
Existen algunos aspectos que se de- ben tener en cuenta para desarrollar exitosamente un proyecto. A conti¬nuación se enumeran algunos de ellos:
1. Se debe tener definida claramen¬te la metodología de trabajo de cada fase del proceso del desarro¬llo de software, en especial las fa¬ses de administración de requeri¬mientos y control de cambios, los cuales son los eslabones más dé¬biles del proceso de desarrollo de software en nuestras organizacio¬nes. La responsabilidad de defi¬nir, documentar y velar que se cumpla a cabalidad la metodolo¬gía de trabajo es del grupo de in¬geniería de procesos.
2. La participación activa de los usuarios y los acuerdos en los tiem¬pos pactados, teniendo en cuenta los datos generados de los proce¬sos de estimación y planificación, son responsabilidad del jefe del proyecto, pero deben ser elabora¬dos con integrantes claves del equi¬po del proyecto.
3. El Grupo SQA3 debe definir, docu¬mentar y actualizar el proceso de aseguramiento de la calidad del software, gestionar los recursos ne¬cesarios para que sea operativo desde el comienzo del proyecto, entregar el plan de calidad y velar por su cumplimiento a lo largo del ciclo de vida del proyecto.
El proceso de incorporación y uti¬lización de nuevas tecnologías es quizás uno de los aspectos más críticos dentro del proyecto y de ma¬yores riesgos. La definición de una metodología de administración del cambio tecnológico, clara y muy práctica, facilitaría considerable¬mente el trabajo realizado en la fase de elaboración, lo cual permi¬tiría determinar la viabilidad de la incorporación de dicha tecnología en el proyecto.
Teniendo en cuenta los aspectos men¬cionados previamente, Rational que recientemente fue comprada por IBM, elaboró un marco de referencia para el proceso de desarrollo de software basado en el modelo en espiral. Este método se conoce como RUP “Ratio¬nal Unified Process”. Para una mejor organización, el RUP agrupa las ite¬raciones en etapas y fases que facili¬tan facili¬tan la administración del proyecto.
1. Etapa de ingeniería
Esta etapa agrupa las fases de con¬cepción y de elaboración, lo que bá¬sicamente le da por objetivos la con¬ceptualización del sistema y el di¬seño inicial de la solución del pro¬blema.
Se inicia el proceso de administración de los requerimientos con la identifi¬cación y especificación de casos de usos, así como el proceso de asegura¬miento de la calidad a través de los casos de prueba.
Se identifican los riesgos y se esta¬blece su plan de manejo, se ajusta ese plan según la tabla de priorización de riesgos y la de casos de usos vs. ries¬gos, para determinar en qué orden y en qué iteraciones se desarrollarán los artefactos de software que son la solución a los casos de uso.
Se identifican los recursos necesa¬rios, tanto económicos como huma¬nos, acordes con las necesidades del proyecto. Se da comienzo al proceso de estimación y planificación inicial a un nivel macro para todo el pro¬yecto y posteriormente se realiza una estimación detallada de tiempos y recursos de las fases de concepción y elaboración.
1.1. Fase de concepción
Esta fase tiene como propósito defi¬nir y acordar el alcance del proyec¬to con los patrocinadores, identifi¬car los riesgos asociados al proyec¬to, proponer una visión muy gene¬ral de la arquitectura de software y producir el plan de las fases y el de iteraciones.
A partir del modelo de casos de uso y de la lista de riesgos, se puede deter¬minar qué casos de uso deben imple¬mentarse primero para atacar los riesgos de mayor exposición. Con base en la información previa se realiza el proceso de planificación general y un plan de trabajo detallado para la si¬guiente fase, así como el plan para la siguiente iteración.
Se debe establecer una relación cla¬ra y directa entre los casos de uso y los casos de prueba para facilitar que el proceso de aseguramiento de la calidad del software se ejecute ade¬cuadamente. El plan de pruebas debe planearse en esta fase, ejecutarse desde la primera iteración de la fase de elaboración y refinarse sucesiva¬mente durante el ciclo de vida del proyecto.
1.2. Fase de elaboración
Los casos de uso seleccionados para desarrollarse en esta fase permiten definir la arquitectura del sistema, se realiza la especificación de los casos de uso seleccionados y el primer aná¬lisis del dominio del problema, se di¬seña la solución preliminar del pro¬blema y comienza la ejecución del plan de manejo de riesgos, según las prioridades definidas en él.
Al final de la fase se determina la via¬bilidad de continuar el proyecto y si se decide proseguir, dado que la ma¬yor parte de los riesgos han sido mi¬tigados, se escriben los planes de tra¬bajo de las etapas de con strucción y transición y se detalla el plan de tra¬bajo de la primera iteración de la fase de construcción.
2. Etapa de producción
En esta etapa se realiza un proceso de refinamiento de las estimaciones de tiempos y recursos para las fases de construcción y transición, se de¬fine un plan de mantenimiento para los productos entregados en la eta- pa de ingeniería, se implementan los casos de uso pendientes y se entre¬ga el producto al cliente, garantizan¬do la capacitación y el soporte ade¬cu a dos.
2.1. Fase de construcción
El propósito de esta fase es comple¬tar la funcionalidad del sistema, para ello se deben clarificar los requeri¬mientos pendientes, administrar el cambio de los art efactos con struidos, ejecutar el plan de administración de recursos y mejoras en el proceso de desarrollo para el proyecto.
2.2. Fase de transición
El propósito de esta fase es asegurar que el software esté disponible para los usuarios finales, aju star los erro¬res y defectos encontrados, capacitar a los usuarios y proveer el soporte técnico necesario. Se debe verificar que el producto cumpla con las espe¬cificaciones entregadas por las perso¬nas involucradas en el proyecto al inicio del mismo.
CONCLUSION ES
En este artículo se presenta una vi¬sión general de algunos métodos orientados por las prácticas de desa¬rrollo iterativo y manejo del riesgo.
Este tipo de métodos no han sido apli¬cados en muchas de las empresas lo¬cales, probablemente por su comple¬jidad de administración, desaprove¬ desaprove¬chando sus considerables ventajas respecto a los métodos tradicionales. Es necesario entonces desarrollar mecanismos de apropiación tecnoló¬gica más eficaces, que permitan man¬tener actualizadas nuestras prácticas organ iza cion ales.
Los marcos de referencia aquí men¬cionados definen qué debe hacerse y en algunos casos cómo hacerlo. El tra¬bajo del gerente de proyectos con sis¬te en identificar cuál marco de refe¬rencia se ajusta a su organización y realizar el proceso de apropiación de la metodología y asimilación de las guías de trabajo al interior del equi¬po del proyecto y del área de infor¬mát ica.
BIBLIOGRAFÍA
Craig Larman. Agile and iterative development: a manager’s guide. Addison Wesley, 2004.
Ivar Jacobson, Grady Booch y James Rumbaugh. The Unified Software Development Process. Rational Soft¬ware Corporation. Addison-Wesley, 1999.
Steve McConnell. Desarrollo y Ges¬tión de Proyectos Inform áticos. McGraw Hill, 1996.
Rational Software Corporation. Prin¬ciples of Managing Iterative Develo¬pm ent v.2.0. 2001.
Project Management Institute PMI. A Guide to the Project Management Body of Knowledge PMB OK® Guide. 2000 Edition.
Rational Software Corporation. RUP Rational Unified Process® Version 2002.05.00, 2002.
Sandra Victoria Hurtado Gil. Representación de la arquitectura de software usando UML. Revista Sistemas & Telemática No. 1 - Enero-Junio 2003. Universidad ICE SI.
Robin Alberto Castro Gil es Inge¬niero de la Universidad Icesi, realizó la especialización en Gerencia de la Producción en la Universidad Icesi. Actualmente es Jefe de la Oficina de Desarro¬llo de Sistemas de la Universi¬dad Icesi y presidente de la Aso¬ciación de Usuarios de Oracle de Colombia-ASUOC.

Lo que publico hoy no me pertenece, le agradezco al Prof. Julio Hernan Morales, colega y gran amigo, a quien aprecio por lo que es ....
También motiva esta publicación a una cuantas solicitudes de cibernautas que me han preguntado si tengo esquemas de desarrollo de trabajos de investigación en el área de informatica, para todos aquí me permito darles este material.

METODOLOGIA PARA PROYECTOS DE GRADO

PROPOSITO.

Un Proyecto de Grado debe constituirse no solo en el mecanismo que facilite la “Obtención de un título, representado en un cartón”, sino en un PROYECTO DE VIDA, del cual cada uno pueda sentirse orgulloso. Debe ser el resultado de un proceso juicioso de Investigación que permita “ La identificación y descripción detallada de los aspectos técnicos, administrativos, de control y de personal, necesarios para resolver un problema”[1]. Debe tener como objetivo “ Presentar y describir detalladamente lo que se va a investigar, la base teórica, conceptual, los componentes metodológicos y los recursos humanos, técnicos y económicos, necesarios para realizar la Investigación”[2].

Por ésta razón y conscientes de su importancia, Asesores Científicos y Metodológicos del Programa, proponen una metodología consecuente con estos aspectos, donde cada investigador (Estudiante y Tutor), comprometan su esfuerzo, conocimientos y entusiasmo en construir una solución real y efectiva a una necesidad específica. Será aplicable de acuerdo a las características del proyecto y a los puntos de vista del investigador.

FASES DEL PROYECTO

FASE I.

1 ASPECTOS DE LA INVESTIGACION.

1.1 DESCRIPCION DEL PROBLEMA.

Es el punto de partida de todo proyecto. Se origina a partir de una necesidad no satisfecha ya sea en el plano teórico, humano, administrativo, político, científico, etc.. Consiste en mostrar los hechos pertinentes o aspectos que requieren de una solución. Es la identificación de las características del problema en términos concretos y explícitos. Debe ser expresado en términos claros. Es relacionarlo con situaciones, personas, instituciones o elementos que lo originan:

§ Grupos de población afectados

§ Areas geográficas afectadas.

§ Factores involucrados

§ Magnitud del problema.

§ Frecuencia

§ Personas o instituciones involucradas en el asunto a tratar.

1.2 JUSTIFICACION DEL PROYECTO DE INVESTIGACION.

Es presentar los argumentos por los cuales es imprescindible realizar el proyecto. La claridad y precisión de ellos permitirá visualizar con objetividad las metas que se pretender alcanzar. Debe reflejar la importancia de solucionar el problema, las razones por las cuales la realización del proyecto será vital para resolver el problema planteado. Se tendrán en cuenta (las que apliquen):

1.2.1 Razones Sociales.

1.2.2 Razones jurídicas.

1.2.3 Razones Económicas.

1.2.4 Razones Técnicas

1.2.5 Razones Organizacionales

1.2.6 Razones Metodológicas.

1.3 DELIMITACION.

Es identificar los límites y restricciones dentro de los cuales van a moverse el proyecto o la investigación.

1.3.1 Espacial. Descripción de la ubicación en donde se va a desarrollar el proyecto. Ente Físico en su entorno. Brevemente, no de manera detallada, una reseña histórica de la Institución, población o sector donde se realizará la investigación. Es necesario incluir a la UMB, como gestora y facilitadora del proyecto. Mostrar dónde va a ser aplicable el producto de la investigación.

1.3.2 Cronológica. Indica el tiempo que el proyecto requiere para ser realizado en todas sus Fases. Consiste en dividir la realización del proyecto en etapas, con su correspondiente descripción de actividades y el tiempo de duración de cada una de ellas debidamente calculado, empleando herramientas que permitan visualizar los avances alcanzados. Ejemplo de una de ellas es PROJECT, con sus opciones: Diagramas de Gannt y Pert.

1.3.3 Conceptual. Muestra los aspectos que cubre y que no cubre la investigación. Corresponde al alcance del proyecto.

1.3.4 Financiera. Se calculan los recursos requeridos, el presupuesto que se va a invertir en el proyecto. Es importante considerar los aspectos de Factibilidad económica, el VPN (Valor presente neto), el punto de equilibrio.

1.3.5 Metodológica. Expresar cuál va a ser la metodología propia a utilizar. Para Sistemas, debe estar basada en alguna metodología tal como: CVDS (Ciclo de vida del desarrollo de sistemas), empleando herramientas específicas como UML (UNIFIED MODELING LANGUAJE), RAD (), RUP, etc..

1.4 OBJETIVOS.

Son los resultados observables que se obtendrán para resolver el problema formulado. “ Son especificaciones del objeto desde el punto de vista del nivel de conocimiento que se quiere alcanzar en la investigación”.[3] Su formulación debe comprender resultados concretos en el desarrollo del proyecto; el alcance de estos objetivos debe estar dentro de las posibilidades del investigador.

1.4.1 General. Tiene como fin señalar el resultado que se desea obtener de la investigación y del proyecto o TEG. Su redacción debe emplear verbos en infinitivo y ser alcanzable en el tiempo y con los recursos asignados.

1.4.2 Específicos. Tienen como propósito mostrar los resultados o metas parciales que deben ejecutarse y concluirse para obtener el logro del objetivo general. También deben enunciarse con verbos en infinitivo. Cada objetivo específico debe incluir un solo logro, indicando lo que realmente se desea alcanzar.

1.5 PROPOSITO.

Muestra los beneficios a nivel de la comunidad, la sociedad y la economía que se obtendrán del proyecto. Es el PARA QUE se va a hacer el proyecto o la investigación.

FASE II.

2 MARCO TEORICO.

Contextualiza, sustenta y explica teóricamente el problema de investigación o del proyecto. Es una descripción detallada de cada uno de los elementos esenciales de la teoría, de tal manera que la formulación del problema y su solución sean una deducción lógica de ella. Tiene como función principal prevenir errores que se han cometido en otros proyectos o investigaciones anteriores, orientar y ampliar el horizonte de la investigación, evitando desviaciones. Un buen marco teórico no es aquel que contiene muchas páginas, sino el que trata con profundidad únicamente los aspectos que se relacionan con el problema y que vincula lógica y coherentemente los conceptos y proposiciones existentes en estudios anteriores con el problema planteado. No se trata de hacer una sumatoria de conceptos, sino que permita la construcción de nuevas teorías sobre la solución del problema de investigación; como mínimo debe contemplar los siguientes pasos:

2.1 ANTECEDENTES.

2.1.1 HISTORICOS.

Debe mostrar la evolución del objeto en estudio, revisando aspectos puntuales de él.

2.1.2 LEGALES.

Normatividad y Jurisprudencia con respecto al objeto de estudio. Relacionar los Decretos, leyes, normas y demás aspectos legales Y jurídicos que tengan relación con el objeto de estudio.

2.1.3 INVESTIGATIVOS.

Mostrar brevemente otras investigaciones, trabajos, proyectos, desarrollos similares o relacionados con el proyecto u objeto de estudio.

2.2 BASES TEORICAS.

Corresponde a la revisión literaria, bibliográfica, relevante, con el objeto de estudio. Es necesario aclarar que se trata de una síntesis conceptual y no de un tratado producto de una “transcripción textual” de los conceptos.

2.3 TEORIAS GENERICAS BASADAS EN INGENIERIA.

Corresponde a toda la narrativa literaria técnica de ingeniería, de las herramientas a utilizar en el proyecto ( Bases de Datos, Redes Neuronales, Plataformas, etc.).

2.4 CONSTRUCCION DEL MARCO CONCEPTUAL.

Es la elaboración teórica de la posible solución del problema. En él aparecen el esquema conceptual, las definiciones propias del investigador de acuerdo a su criterio, explicando y prediciendo cuál será el estado de su proyecto..

2.4.1 METAS A ALCANZAR.

Con todos los conocimientos adquiridos a esta etapa del proyecto, el Alumno esta en capacidad de identificar las metas que desea conseguir a corto, mediano y largo plazo, de manera más concreta y específica.

2.4.2 PRINCIPIOS.

Son las características que debe reunir el producto final y que garanticen su operatividad (Integridad referencial, consistencia, argumental, etc., Portabilidad, Calidad, Recursividad, etc.).

2.4.3 ENFOQUE.

Dirección que se le va a dar al proceso en el desarrollo: puntual, integral, global.

2.4.4 NECESIDADES A SATISFACER.

El desarrollo el proyecto debe solucionar una serie de inconvenientes, reflejados en su momento en la descripción del problema. Es mostrar el beneficio que producirá el proyecto en términos de suplir unas necesidades. Ej.: En un proyecto de control de cartera, un requerimiento a cubrir es el Estado de Cuenta de cada usuario.

2.4.5 PRODUCTOS DEL MODELO.

En este aparte se idean los productos a obtener y que estarán disponibles al terminar el proyecto. Ej.: Para el mismo caso de Cartera, el Liquidador de Vencimientos.

2.4.6 SERVICIO.

Se refleja la utilidad que va a prestar el desarrollo. Ej.: Control de fechas de vencimiento de cada cuota en Cartera, Identificador de sanciones por mora, etc.

2.4.7 FUNCIONES.

Conjunto de procesos individuales que se deben ejecutar para obtener un servicio. Ej.: Sysdate, rangos de fechas, rangos de números, límites, etc.).

2.4.8 CONTROLES.

Medidas de seguridad que va a tener el modelo a desarrollar.

2.4.9 OBSERVACIONES.

Aquí se documentarán otros aspectos relevantes para el modelo, que no han podido reflejarse en otras instancias.

2.5 DEFINICION DE TERMINOS BASICOS.

Breve Glosario con la definición de palabras claves utilizadas permanentemente en el contenido del proyecto.

NOTA. Es importante tener en cuenta que para modelos, prototipos, sistemas de información y software en general, no se requiere del planteamiento de Hipótesis, aspecto relevante en estudios e investigaciones.

FASE III.

3 DISEÑO METODOLOGICO.

Tiene como fin establecer cómo se llevará a cabo la investigación, diseñando detalladamente la estrategia para obtener la información, puntualizando las actividades necesarias para darle respuesta a los objetivos planteados. Es la parte del proceso de investigación que hace referencia a los procedimientos que deben utilizarse para lograr en forma precisa y exacta el objetivo que persigue el proyecto de investigación.

3.1 TIPO DE INVESTIGACION.

Para proyectos de ingeniería, normalmente puede hablarse de Investigación Cuantitativa ya que parte de un problema y unos objetivos bien definidos por el investigador, utiliza técnicas estadísticas muy estructuradas para la recolección y el análisis de la información. En esta clase de investigación se pueden mencionar diferentes tipos[4]:

· DESCRIPTIVA. Su objetivo es referir e interpretar minuciosamente lo observado, describir el estado, las características, factores y procedimientos del objeto en estudio. Ej.: Sistematización del área de cartera. Interpretación de lo que es, "Comprende la descripción, registro, análisis e interpretación de la naturaleza actual, composición o procesos de los fenómenos. El enfoque se hace sobre conclusiones dominantes, o sobre una persona, grupo o cosa, que conduce a interpretar realidades de hecho. se efectúa cuando se desea describir, en todos sus componentes principales, una realidad.

· EXPLORATORIA. Es considerada como el primer acercamiento científico a un problema. Se utiliza cuando éste aún no ha sido abordado o no ha sido suficientemente estudiado y las condiciones existentes no son aún determinantes.

· EXPLICATIVA. Es aquella que tiene relación causal; no sólo persigue describir o acercarse a un problema, sino que intenta encontrar las causas del mismo.

Es conveniente mencionar el otro tipo de investigación que es la Cualitativa que se refiere a los estudios sobre el quehacer cotidiano de las personas o de grupos pequeños. En este tipo de investigación interesa lo que la gente dice, piensa, siente o hace. Su función puede ser la de describir o la de generar una teoría a partir de los datos obtenidos. Los investigadores desarrollan conceptos, intelecciones y comprensiones y comprensiones, partiendo de los datos y no recogiendo datos para evaluar modelos, hipótesis o teorías preconcebidas. Es de índole interpretativa.

3.2 ANALISIS.

3.2.1 DESCRIPCION DEL SISTEMA ACTUAL.

Permite establecer cómo funciona el objeto en estudio actualmente, teniendo en cuenta: las condiciones prevalecientes, puntos de vista de implicados, actividades, procesos, tendencias, requerimientos, eventos que ocurren en el ciclo de vida del objeto en estudio; se describe a través de diagramas que apliquen a cada caso (Diagramas de Contexto, DFD, Eventos, etc..). Este conocimiento debe ser adquirido con base en observación, entrevistas, investigación del entorno y demás.

3.2.2 DIAGNOSTICO DE LA SITUACION ACTUAL.

Es vislumbrar claramente el problema planteado al inicio del proyecto. De él emanarán los requerimientos del sistema propuesto. (Técnicos, de datos, de usuario, de conectividad, etc.).

3.2.3 METODOLOGÍAS PARA EL ANALISIS.

Con los años se han propuesto muchos métodos para el modelado del análisis. Algunos de ellos son:

3.2.3.1 Análisis Estructurado[5]. Es una actividad de construcción de modelos, que tiene como centro el Diccionario de Datos y entre otras las siguientes actividades:

§ Diagrama de Flujo de Datos

§ Modelo Entidad – Relación

§ Especificaciones de Procesos

§ Especificaciones de Control

3.2.3.2 Análisis Orientado a Objetos. Permiten al Ingeniero de Software modelar un problema a través de la representación de objetos, atributos y operaciones como las componentes primarias del modelado. Existen una gran variedad de métodos de Análisis orientado a objetos[6]:

§ El Método de Booch

§ El Método de Coad y Yourdon.

§ El Método de Jacobson

§ El Método de Rumbaugh

§ El Método de Wirfs – Brock

§ Unified Modeling Languaje. UML. Lenguaje Unificado de Modelado.

Todos poseen un conjunto de características comunes:

§ Representación de clases o jerarquías de clases

§ Creación de modelos de Objeto – Relación

§ Derivación de Modelos Objeto – Comportamiento.

3.2.4 ALTERNATIVAS DE SOLUCION, EVALUACION Y SELECCIÓN DE LA MEJOR.

El problema tendrá una serie de soluciones, que serán analizadas una a una, en todos sus aspectos: económicos, técnicos, humanos, legales y demás, con el propósito de optar por la mejor. Esta selección estará sustentada por escrito, para desde este instante asumir la responsabilidad de todo el proceso adelantado hasta esta parte y el que se ejecutará para lograr el resultado final.

3.3 DISEÑO

El Diseño se ha descrito como un proceso multifase en el que se sintetizan representaciones de la estructura de datos, estructura del programa, estructura de la interfaz y detalles procedimentales desde los requisitos de la información. Existen diversos Métodos de diseño, todos aplicables y válidos, dependiendo específicamente del enfoque del proyecto.

§ Diseño Estructural

§ El Diseño Orientado a Objetos (DOO)

3.3.1 DISEÑO LOGICO.

3.3.1.1 DISEÑO DE PROCESOS

Se hará énfasis en cambios que se presenten a todos los niveles: procesos, normas, procedimientos, aspectos Organizacionales, etc., empleando metodologías apropiadas (Gráficas).

3.3.1.2 DISEÑO DE DATOS.

Facilita establecer los datos que va a procesar el sistema, su composición, atributos, donde van a residir, sus relaciones. Puede ser expresado por medio de:

3.3.1.2.1 Modelo Entidad – Relación. (E – R). Entidades y sus Relaciones.

3.3.1.2.2 Modelo de Datos. (Modelo E – R normalizado mínimo hasta 3FN).

3.3.1.2.3 Diseño de Tablas. (Estructura, llaves).

3.3.1.2.4 Diseño Semántico. (Reglas del negocio. Es la condición semántica de los datos). Ej.: Para realizar un pago a Proveedor, es regla, que exista una factura o una cuenta de cobro.

3.3.1.3 DISEÑO ARQUITECTONICO.

Define la relación entre los principales elementos estructurales del programa

3.3.1.3.1 Modelo Funcional. Módulos que van a conformar el software teniendo en cuenta sus encadenamientos. Es la estructura jerárquica de los componentes del programa (módulos), la manera de interactuar de estos componentes y la estructura de los datos usados por estos componentes.

3.3.1.3.2 Especificaciones de Programas. Debe nombrarse cada programa, relacionando: Objetivo, Entrada, Proceso, Salida, tabla o proceso que afecta, etc.

3.3.1.3.3 Diseño de Interfaz de Usuario. Es la interacción entre el usuario y el aplicativo. Debe tenerse en cuenta tanto para las entradas como para las salidas.

3.3.1.3.4 Diseño de Ayudas. Es necesario recordar que las ayudas estén disponibles para todas las funciones del sistema y en todo momento durante la interacción con el sistema. (Incluir Manuales).

3.3.2 DISEÑO FISICO.

3.3.2.1 DISEÑO DE LA BASE DE DATOS.

Por tratarse del lugar en el que reposará la información, su diseño es vital para el buen uso de los datos.

3.3.2.1.1 Aspectos físicos de la Base de Datos. Longitudes, Rangos (dominios), índices, secuencias.

3.3.2.1.2 Procedimientos. Trigger, Storage Procedure,

3.3.2.2 Pantallas e informes.

3.3.3 DISEÑO DE SEGURIDAD Y CONTROLES.

Todo proyecto debe ofrecer seguridad y controles, garantizando de esta manera Integridad en la información.

3.3.3.1 De la Base de Datos

3.3.3.2 Matriz de Funciones Vs. Usuarios

3.3.3.3 Niveles de seguridad

3.3.3.4 Roles.

3.3.3.5 Perfiles.

3.3.3.6 Permisos

FASE IV.

4 ANALISIS DE RESULTADOS Y CONCLUSIONES.

4.1 CODIFICACION DE PROGRAMAS.

4.2 BANCOS DE PRUEBA.

4.2.1 Pruebas de Función

4.2.2 Pruebas Modulares

4.2.3 Pruebas del Sistema

4.2.4 Prueba de Interfaz

4.2.5 Prueba de Documentación y de ayuda

4.2.6 Prueba de Seguridad y Control

4.2.7 Prueba de Calidad

4.3 Informe de Pruebas (Resultados)

4.4 Aceptación (cartas de aprobación)

4.5 Análisis de Resultados

4.6 Conclusiones.

4.7 Recomendaciones

BIBLIOGRAFIA. En lo posible hacer una breve descripción del tema del libro consultado. Cuando sea una dirección de Internet, describir el tema del sitio consultado.

MANUALES DE USUARIO Y TECNICO.

1. De usuario.

§ Presentación del Manual

§ Explicación General de la aplicación o del sistema

§ Descripción de teclas de función a utilizar

§ Por cada módulo, explicar todas y cada una de las pantallas, opciones, botones, listas de valores

§ Descripción de informes, con una muestra real de cada uno.

§ Explicación de parámetros del sistema

§ Explicación de la estructura de ayudas.

§ Glosario

2. Técnico.

§ Presentación del Manual

§ Características de máquina

§ Estructura o procedimiento técnico de instalación, haciendo énfasis en que todos deben ser booteables, documentando éstas estrategias.

Autoboteo de Código. Adjuntar código con sus principales comentarios.

Autoboteo de Utilitarios del sistema. Se deben colocar iconos, comandos que se utilizan paso a paso para producir el objeto ejecutable.

§ Copias de seguridad

§ Entrada al programa

§ Estructura del árbol general del programa (Diagrama estructural)

§ Especificaciones funcionales de los programas

§ Estructura de Uso de la base de datos. Programación que permite alimentar la base de datos a través de pantallas de captura (Formas)

§ Consulta y extracción de resultados, informes todos representados por código. Cuando la base de datos es creada con una herramienta diferente a las formas con que se alimentan los reportes, debe enunciarse la herramienta de conexión (OBDC (a la base de datos), ASP (a la web), PHP (funciones)).

§ Estructura de conectividad cuando el sistema es distribuido o cuando tiene salida a Internet. Enunciar herramientas y describir paso a paso.

§ Mensajes de error del sistema

RESUMEN. Apoyo para Jurados. Ver Guía Investigaciones.

---

[1] Tamayo, 1995, 26.

[2] Metodología de la Investigación: Propuesta, Anteproyecto y Proyecto”. Hector Daniel Lerma.

[3] BRIONES, (92).

[4] Metodología de la Investigación. Hector Daniel Lerma (2.001)

[5] Ingeniería de Software. Un Enfoque Práctico. Roger Pressman.

[6] Ingeniería de Software. Un Enfoque Práctico. Roger Pressman.