Captulo VIII.

Cierre de proyecto

Jacobson [JACOBSON et. al. 2000] afirma que antes de dar por terminado el proyecto se debe realizar una entrega formal del mismo los usuarios donde se listen todas las actividades realizadas y comprarlas con los planificado al inicio. A esta entrega formal del producto es a lo que se le llama cierre del proyecto. Por su parte Stephen Schach [SCHACH, 2005] comenta que una parte considerable del esfuerzo de desarrollo de un sistema de informacin es absorbida por la documentacin. No es raro tener que invertir en ella de 150 horas a 200 horas por cada 100 horas que se gastan en la codificacin del sistema. Este esfuerzo tiene su recompensa precisamente en esta fase del mismo. Cuando se entrega un producto de manera informal, sin una documentacin que detalle la construccin del mismo, responsabilidades, riegos y porque no, tambin limitantes, lo nico que respalda el trabajo realizado es un disco compacto con el cdigo ejecutable software desarrollado. Al final de cuentas para el usuario final un CD-ROM o un archivo de cdigo ejecutable no reflejan las horas invertidas en el desarrollo de un proyecto. La construccin de software es muy diferente a los otros tipos de construcciones existentes. Por ejemplo, parar un arquitecto que construye casas, el producto final de su trabajo es un inmueble visible y tangible por el cliente. Aunque este entrega los planos pertinentes del proyecto, es muy posible que el cliente no les de la misma importancia que a lo que sus manos tocan y sienten. Inmediatamente sabr si esa es o no la casa que quera que le construyeran. Debido a la naturaleza intangible del software, esto no sucede con la construccin de sistema de informacin. Es muy comn escuchar a las personas asombrarse por el costo que puede tener un software como un procesador de texto o incluso un sistema operativo argumentando: cmo puede ser tan caro y solo es un CD-ROM?.
305

Una documentacin adecuada de todo el proceso de construccin desde su inicio hasta su terminacin no dar lugar a dudas del esfuerzo realizado adems de delimitar muy puntualmente lo que el software debe hacer pero sobre todo lo que no debe hacer. Si esto se ve desde el punto de vista del constructor de la solucin, tambin sirve de respaldo en caso de que el cliente cambie de parecer al ltimo minuto sobre lo que su sistema debera realizar. Aunque si se ha seguido correctamente la metodologa del proceso unificado trabajando conjuntamente con el cliente, esto no debera de suceder.

8.1 Carta de cierre del proyecto

Toda esta introduccin es el prembulo para presentar de la carta de cierre del proyecto del sistema de informacin de que es objeto este trabajo. Este cierre formal del proyecto se realiz entre la organizacin cliente y la unidad de tecnologa. La Figura 140 muestra esta carta la de cierre la cual se divide en tres partes: Lista de entregables fsicos. Lista de objetivos del proyectos satisfactoriamente cubiertos del proyecto de software. Trabajo realizado en cada una de las etapas del proyecto.

306

INSTITUCIN
Organizacin cliente Minuta de Junta
CIERRE DEL PROYECTO
1. DATOS GENERALES DE LA JUNTA
Fecha: Hora: 9:30 hrs. Lugar: Sala de Juntas de la organizacin cliente

OBJETIVO DE LA JUNTA: ENTREGA DEL SISTEMA DE INFORMACIN

TEMAS A TRATAR
Cierre del proyecto del Sistema de informacin y entrega del producto de manera formal para su funcionamiento en el ambiente de produccin.

2. ACUERDOS 1. Por medio de la presente se hace constar que el Sistema de Informacin est montado en el servidor institucional en la direccin http://dominio/. 2. El sistema de informacin est abierto a la organizacin cliente y a la Unidad de Tecnologa. 3. El sistema se encuentra en su versin1.0 y an en fase beta, por lo que se pueden llegar a encontrar algunos defectos que debern ser notificados y corregidos por la Unidad de Tecnologa. 4. Lo anterior no quiere decir que el sistema este incompleto, simplemente que por su naturaleza de software no es perfecto y puede llegar a fallar. 5. Se establece un periodo de 6 meses antes de continuar con el inicio de actualizaciones al sistema para agregar otras funcionalidades que ya han sido detectadas (como la inclusin de firmas y certificados digitales). 6. La lista de entregables es la siguiente: Entregable Descripcin Manual de usuario Documentacin del sistema CD-ROM con el manual tcnico y de usuario del sistema en formato PDF. CD-ROM con la documentacin del sistema que incluye los artefactos de las cuatro fases de la metodologa de desarrollo del sistema de informacin.

307

INSTITUCIN
Organizacin cliente Minuta de Junta
CIERRE DEL PROYECTO

4. OBJETIVOS DEL PROYECTO Los objetivos perseguidos por el proyecto del sistema de informacin fueron cumplidos de forma satisfactoria y en el tiempo estipulado; mismos que se listan a continuacin: 1. Desarrollo de un sistema de informacin para administrar la correspondencia entre las dependencias de la institucin. En su primera etapa abarcar nicamente la organizacin cliente. 2. El sistema de informacin deber satisfacer los requerimientos de la certificacin ISO-9001:2000 que proporcionar la organizacin cliente. 3. Utilizar la metodologa del proceso unificado por primera vez en un proyecto de la Unidad de Tecnologa para verificar su funcionalidad y eficiencia. 4. Deber alojarse en una direccin url en Internet. Se sugiere una direccin en el servidor Web institucional. 5. El repositorio de datos deber ser confiable y permitir exportacin de la informacin cuando la organizacin cliente lo requiera. 6. Permitir clasificar la correspondencia en atendida, no atendida, sin respuesta y apunto de vender. Cada clasificacin deber tener un color para su fcil interpretacin. 7. Establecer un nmero de das mximo para la respuesta de peticiones de correspondencia. 8. El sistema deber generar un reporte grfico de correspondencia de acuerdo a su clasificacin. 9. El sistema permitir la incorporacin de documentos en papel al proceso de envi de correspondencia. 10. Se requiere que el sistema tenga la capacidad de escanear documentos en papel para su incorporacin como adjuntos. 11. Agrupar varios documentos con un mismo Folio para tener un seguimiento de la comunicacin entre dependencias. 12. Permitir imprimir la correspondencia. 13. Permitir bsquedas de correspondencia por Folio, No. de documento, Asunto, Clasificacin, Prioridad, Fecha de envo, Remitente, Destinatario y combinaciones entre todas. 14. Acceso restringido por contrasea usando la cuenta institucional. 15. Administracin de dependencias y usuarios con permisos de lectura, escritura, envi y actualizacin. 16. Permitir el uso de cuentas delegadas o espejo para delegar la administracin de la correspondencia a los asistentes tal como se hace con la correspondencia en papel. 17. Entregar el sistema de informacin en 10 semanas a partir de la fecha de inicio a establecer por el secretario y el director de la unidad de tecnologa con un mximo de 12 semanas para su entrega.

308

INSTITUCIN
Organizacin cliente Minuta de Junta
CIERRE DEL PROYECTO
5. ACTIVIDADES REALIZADAS A continuacin se presenta un resumen de las actividades realizadas a lo largo del proyecto divididas por fase de la metodologa del proceso unificado: Fase
Fase de iniciacin Alternativa de solucin Identificacin de riesgos (Estudio de factibilidad) Modelo del negocio Modelo del dominio Glosario Modelo de casos de uso Versin preliminar de la arquitectura (vista del modelo de casos de uso) Fase de elaboracin Plan global del proyecto Modelo de casos de uso refinado Diagrama de clases de los casos de uso Diagrama de colaboracin de los casos de uso Escenarios de los casos de uso Diagramas de secuencia de los casos de uso Diagrama de clases global Versin de la arquitectura lgica (vista del modelo del anlisis) Fase de construccin Plan de la fase Diseo conceptual de la base de datos Diagrama Entidad-Relacin Diseo lgico de la base de datos Diagrama relacional Diseo lgico normalizado de la base de datos Diseo fsico de la base de datos Diseo de pantallas Codificacin de los modelos en un lenguaje de programacin 309

Entregable dos tres

Fechas semanas, miembros

del equipo

tres cuatro

semanas, del

miembros equipo

tres cuatro

semanas, del

miembros equipo

Versin actualizada de la arquitectura (capa de presentacin y datos) Fase de transicin Plan de la fase Instalacin de la versin beta Manual de usuario Manual tcnico Programa de capacitacin Verificacin de la especificacin CSS 2.1 Verificacin de la especificacin XHTML 1.0 Verificacin de la accesibilidad del sistema Versin final del sistema Lanzamiento del producto

dos tres

semanas, miembros

del equipo.

6. ASISTENTES
NOMBRE FIRMA

Director Unidad de Tecnologa Jefe de Unidad de Desarrollo Jefe proyecto Unidad de Desarrollo de software Asesor del Secretario
Figura 140. Carta de cierre del proyecto.

8.2 Resumen del captulo

Este captulo tuvo como objetivo realizar el cierre del proyecto de manera formal con la organizacin cliente principal e inmediato interesado en la buena finalizacin del sistema de informacin debido a su certificacin en materia de calidad ISO-9001:2000. Se present la carta de cierre del proyecto de la reunin para la entrega del sistema (de forma simblica pues el sistema est en el Web y no se requiere de un CD-ROM de instalacin) entre la organizacin cliente y la Unidad de Tecnologa de la Institucin. Esta carta est dividida en tres partes: la lista de entregables formales, la lista de objetivos alcanzados con el cierre del proyecto y la lista de las actividades realizadas en cada fase del proceso de construccin. En esta junta tambin se habl sobre las actividades futuras a realizarse sobre el sistema con el objetivo de actualizarlo y de dar u seguimiento formal a los resultados que se vayan obteniendo con el uso
310

del software. En el siguiente y ltimo captulo de este trabajo, se abordan estos temas junto con las conclusiones finales y la comparativa entre los objetivos a alcanzar planeados al inicio y lo realmente alcanzado hasta el momento.

311

Conclusiones

Este trabajo de tesis tuvo la finalidad de mostrar el desarrollo de la solucin implementada a los problemas de comunicacin escrita que se presentan entre los integrantes de una institucin. La solucin propuesta fue el desarrollo de un sistema de informacin para la administracin de los documentos de la institucin. Por qu estudiar este desarrollo? La importancia de la investigacin sobre este proyecto de software radica en que se ha establecido un punto o parmetro de comparacin entre proyectos de la institucin creados usando una metodologa de software y los que no. Adems de que cambia radicalmente la forma de comunicacin entre los integrantes de una comunidad mediante la tecnologa de informacin minimizando el uso del papel y del telfono. Esto implica un cambio total en la forma de trabajar y de pensar entre integrantes de cualquier institucin pues la sustitucin de elementos fsicos (papel) por elementos intangibles o electrnicos no es sencilla de asimilar. Esta resistencia puede compararse con el manejo actual del dinero electrnico. A pesar de que cada vez es ms comn utilizar tarjetas bancarias (dinero plstico) para la realizacin de compras, muchas personas no se sienten cmodas sin ver el papel moneda durante la realizacin de sus transacciones. Estos aspectos fueron tomados en cuenta y se trabaj bajo la premisa de que los usuarios rechazaran el proyecto al inicio por desconocimiento y miedo al cambio, pero que al utilizarlo y experimentar las ventajas ofrecidas por el sistema, su descontento se transformara en aceptacin, exigencias de ms funcionalidades y en algunos casos dependencia del mismo. Mediante la observacin del comportamiento de los usuarios finales del sistema fue muy evidente que las premisas eran ciertas pues el rechazo inicial hacia esta herramienta de software se present en la mayora del personal. Muchos de ellos incluso sin conocer an el sistema de informacin. Pero tambin fue cierto que el sistema que se construy, es el sistema que ellos necesitaban y se ha visto reflejado en una aceptacin cada vez mayor del mismo.

313

Esto quiere decir que dedicarle gran parte del trabajo a la investigacin preliminar para obtener los requerimientos (el qu es lo que se necesita hacer) se tradujo en la elaboracin (el cmo se hace) del producto solicitado. Aunque este enunciado puede sonar muy simple, es una gran aportacin en lo referente a proyectos de software. Hay que tomar en cuenta que varios autores sealan que la mayora de los proyectos de software que se inician no se terminan correctamente88 e incluso algunos ha llegado a afirmar89 que hay una crisis en los desarrollos de las organizaciones pues la mayora de los proyectos no tienen resultados satisfactorios debido a diversos factores como calidad insuficiente del producto final, estimaciones de duracin de proyectos y asignacin de recursos inexactas, retrasos para entregar los productos terminados, costos de desarrollo y mantencin de productos fuera de control, tendencia al crecimiento del volumen y complejidad de los productos, entre otros. La importancia de este trabajo es que puede servir de gua para otros proyectos de software en donde se requiera aplicar una metodologa de desarrollo orientada a objetos donde se garantice con un alto grado de certeza que el producto final ser el producto conceptualizado por el cliente. La razn ms comn por la que los proyectos de software fracasan es debido a la idea de que emplear el tiempo de las etapas previas para codificar un poco ms podra acelerar el proyecto lo que es muy lejano a la verdad. No realizar un anlisis detallado de los requerimientos del cliente para planear exactamente lo que se quiere hacer antes de hacerlo, slo incrementa en gran medida las posibilidades de fracaso del proyecto. Un comentario de parte de un cliente que resume muy bien este punto es: ste no es el sistema de informacin que yo ped. En esta investigacin se pudo observar que los resultados finales al desarrollar un proyecto de software usando una metodologa de desarrollo son mejores que no usar una. En el proyecto de la

88

Salvador Gmez presenta algunos proyectos millonarios que han fracasado recientemente en su documento Por Jess Zavala Ruiz hace una profunda reflexin sobre la crisis del software actual en su ensayo Por qu fallan los

qu fallan los proyectos de software. http://www.osgg.net/omarsite/seminario/ronda_uno/seminario01.pdf

89

proyectos de software?; Un Enfoque Organizacional. http://www.consol.org.mx/2004/material/63/por-que-fallanlos-proy-de-soft.pdf 314

Institucin lo que motiv el uso de una metodologa no fueron los malos resultados en proyectos pasados, sino la necesidad de una documentacin adecuada requerida por la certificacin ISO9001:2000. Pero cul fue el resultado? El proyecto tard el mismo tiempo que cualquier otro proyecto similar sin metodologa, la diferencia es que se redujo enormemente el tiempo de cambios de ltima hora, problemas en la reglas del negocio y parches al software. Haciendo una anlisis a la metodologa del Proceso Unificado (la cual algunos la consideran la metodologa de desarrollo de sistemas de informacin orientados a objetos ms completa, gil y flexible) se puede afirmar que es en efecto, una evolucin de las principales metodologas orientadas a objetos de la dcada de los noventa y puede ser utilizada para cualquier proyecto de software actual. Su ciclo de vida iterativo y por incrementos permite modelar fielmente el trabajo real en donde muchas veces hay que regresar a corregir un artefacto. El problema radica en que al corregir un artefacto anterior, hay que corregir todos los artefactos derivados del mismo lo que se traduce en tiempo y esfuerzo. Slo la experiencia con la misma va enseando que los incrementos en las fases deben ser pequeos para que el impacto de los cambios tambin lo sean. Es muy clara la ventaja de los modelos previos a la codificacin: se sabe exactamente qu programar. De esta forma se puede quitar del programador esas decisiones de el qu programar y dejarlo concentrarse en el cmo que es en lo que es experto. En el captulo dedicado a las pruebas se puede ver el resultado de esto: hubo muy pocos errores de lgica en relacin con otros sistemas desarrollados anteriormente. Sorprendentemente, los procesos programados dentro de formularios Web realizaban lo que la organizacin cliente quera que hicieran. Incluso se tuvo tiempo para efectuar pruebas de stress con el software terminado una semana antes de lo planeado. En lo referente al trabajo en equipo, la metodologa ayuda mucho pues permite definir responsabilidades especficas entre los integrantes del proyecto. Aunque una misma persona puede tomar diferentes roles de trabajo, tener una base de la cual elegir para delimitar responsabilidades realmente ayuda a los lderes del proyecto a delegar mejor el trabajo a realizar sin tener que divagar con las clsicas preguntas y ahora que te pongo a hacer? o quin hizo este mdulo?.
315

No cabe duda que ofrece una gran flexibilidad y tiene varias implementaciones dependiendo del tamao del proyecto y grado de profundidad deseado y quiz esa flexibilidad sea su mayor virtud pero tambin su mayor problema. Debido a que la metodologa se tiene una serie de fases, flujos de trabajo y artefactos a escoger dependiendo del proyecto, toda la responsabilidad de cuales elementos utilizar y cules no recae totalmente en el analista de sistemas. A pesar de que hay autores como Stephen Schach que en su libro Anlisis y diseo orientado a objetos con UML y el proceso unificado propone un enfoque sencillo y sobre todo muy prctico para el desarrollo de proyectos medianos y pequeos, no abarca aspectos como la administracin del proyecto, delegacin de actividades, modelado de bases de datos, codificacin, implementacin y pruebas. Los libros del Proceso Unificado revisados y que son publicados por los creadores de la metodologa Jacobson, Booch y Rumbaugh slo describen los aspectos que abarca la misma pero no cmo aplicarla de forma prctica. Obviamente existen tutoriales, plantillas y manuales extensos sobre cmo aplicar la metodologa del Proceso Unificado publicados por la empresa Rational con el inconveniente de que son accesibles al estudiante promedio. Esta tesis trata de mostrar la aplicacin del Proceso Unificado mostrando un marco de trabajo que sirva como gua para el desarrollo de otros proyectos de software combinando las principales etapas de la metodologa con diseo de bases de datos, arquitectura de software en capas, pruebas del producto e implantacin y capacitacin de usuarios. Cabe sealar que este trabajo tambin ejemplifica que el uso de la plataforma .NET puede traer muchos beneficios en el desarrollo. Ya que el .NET Framework es un desarrollo de la empresa Microsoft, muchas personas piensan que su desarrollo es costoso. Esto est lejos de la verdad pues el .NET Framework adems de ser un desarrollo abierto (su especificacin est disponible para cualquier persona), puede ser descargado e instalado gratuitamente para todas las versiones actuales de Windows. Incluso ofrece para los desarrolladores uno de los mejores IDEs del mercado de forma gratuita tambin que para el desarrollo de proyectos Web es llamado Visual
316

Web Developer. El tiempo de codificacin utilizando este IDE se reduce dramticamente cuando se compara con otros editores de cdigo que no ofrecen capacidades de autocompletar, Web server de desarrollo, compilacin y deteccin de errores en tiempo de diseo. Adems en cuestin de rendimiento, el .NET ofrece un producto muy competitivo respecto a otros en ambientes con alta carga de usuarios como se pudo observar en el captulo 8 en la seccin de pruebas de stress. Para el caso de usuarios o servidores Linux o Mac, la empresa Novell ofrece una implementacin del .NET donde se pueden migrar todas las aplicaciones Windows de manera transparente y en algunos casos sin modificar una sola lnea de cdigo. Para el caso del repositorio de informacin, tambin se puede obtener una copia gratuita del gestor de bases de datos MSSQL Server Express del sitio Web de Microsoft con la nica restriccin de bases de datos de tamao mximo de 4 GB. Por todo lo anterior se observa un cambio en la forma de hacer negocios de la empresa Microsoft y una apertura hacia el software libre o tambin llamado Open Source. Con respecto al trabajo personal, este proyecto ha sido muy enriquecedor en cuestin de conocimientos y forma de trabajar en equipo. Gracias a la forma en que se llev a cabo este proyecto, estoy completamente seguro de que el trabajo en equipo no puede llevarse a cabo sin una planeacin adecuada de actividades, delegacin puntual de responsabilidades y fechas de entrega claras. La incertidumbre de si lo que se est haciendo estar bien es el principal problema que enfrentan los proyectos de software desde mi punto de vista. Hay muchos proyectos que no se debieron haber iniciado pero debido a la falta de anlisis de la factibilidad del mismo, esto se evidencia en fases muy adelantadas lo que lleva a su fracaso o a los llamados proyectos de software interminables. No se debe confundir un proyecto de software que evoluciona o se actualiza a una nueva versin a aquellos que nunca se terminan. Para concluir este apartado me gustara comentar que a pesar del uso de metodologas de desarrollo, de planeacin exhaustiva en el rea de administracin de proyectos, de vasta experiencia en el campo, etc., no existe sistema de informacin perfecto, lo que indica que el

317

software siempre tendr defectos. Lo que s se puede hacer es asegurarse de que estos defectos no sean tan graves que impidan la operacin del software en sus tareas ms importantes. Se puede afirmar que hiptesis de la investigacin ha sido comprobada pues la solucin construida y de acuerdo a los resultados del proyecto abordados en el captulo 9 muestran que se ha mejorado la productividad y efectividad en la toma de decisiones de los integrantes de la organizacin y que el software ofrece lo prometido: capacidades de almacenamiento, administracin, digitalizacin, creacin y seguimiento electrnico de la comunicacin escrita actual lo que se traduce en trminos empresariales como una herramienta de medicin de la productividad, una mejora en el tiempo de atencin de las solicitudes y la reduccin del presupuesto en compra de papel y tinta y en gastos de mensajera. Aunque este proyecto ha llegado a su trmino, an hay trabajo por hacer y estas actividades futuras se abordan en la siguiente seccin de este captulo.

Trabajo futuro
Hay todava trabajo por realizar en materia de esta investigacin. La metodologa del Proceso Unificado y el lenguaje UML estn en constante evolucin. En este trabajo no se trataron los aspectos del desarrollo de software empresarial. Estos aspectos empresariales se traducen en extensiones a la metodologa entre las que destacan: El modelado de negocios empresariales La administracin del portafolio Arquitectura empresarial Reutilizacin estratgica Administracin de personas Procesos de mejora del software

318

Scott W. Ambler90 ha comenzado a identificar claramente estos aspectos empresariales del Proceso Unificado y pueden ser aadidos al trabajo aqu presentado. Debido a que la Web est en constante evolucin, durante el desarrollo de este proyecto han surgido nuevas tendencias y tcnicas de programacin que afectan tanto el rendimiento como la experiencia del usuario, por lo que es necesario revisar la actualizacin de la plataforma .NET versin 3.5, donde se pueden agregar funcionalidades para el soporte de flujos de trabajo, seguimiento de procesos empresariales e interfaces de usuario que incorporan documentos, componentes multimedia, grficos bidimensionales y tridimensionales y animaciones por medio de la Windows Presentation Fundation91 y Windows Workflow Fundation92. Tambin es evidente que falta abordar en la investigacin la parte de certificados que aseguren la identidad de los autores de la correspondencia y el cifrado de la informacin entre el cliente y servidor por medio de protocolos como el SSL. Hasta el momento los resultados en la organizacin cliente son alentadores y slo hacen pensar que la extensin hacia las dems dependencias de la institucin es no slo factible sino inevitable. El trabajo inmediato a realizar es el anlisis financiero de los datos apenas se cumplan los seis meses de plazo pactado. Si estos resultados indican que las proyecciones de ahorro financiero eran correctas, el impacto sobre el presupuesto anual ser muy significativo y abrir la puerta a otros proyectos de automatizacin de este tipo en la institucin.

90

Scott W. Ambler presenta un enfoque empresarial del Proceso Unificado en su libro The Enterprise Unified

Process (EUP). http://www.enterpriseunifiedprocess.com/

91

David Chappell ofrece una descripcin muy detallada a la Windows Presentation Fundation en su articulo

Introduccin a Windows Presentation Foundation. http://www.microsoft.com/spanish/msdn/articulos/archivo/231006/voices/introducingwpf.mspx

92

Robert Green describe cmo funcionan los flujos de trabajo en su artculo Windows Workflow Foundation (WF)

Tutorial - Introduction to State Machine Workflows. http://social.msdn.microsoft.com/content/en-us/msft/netframework/wf/learn/Intro-StateMachineWorkflows

319

Como puede observarse todava queda mucho por hacer para la siguiente versin del sistema, lo que es bueno, pues indica que es funcional, productivo y que est sufriendo una evolucin natural y saludable que todo sistema correctamente implementado suele tener.

320

Bibliografa
ACS SOFTWARE, Inc. AutoEDMS Document Management & Workflow Solution. Data Sheet. Torrance, CA, 2006. http://www.acssoftware.com/AE65_datasheet.pdf ALLIANCE GROUP. Records & Document Management. Southgate St, Winchester. Consultado el 26 de septiembre de 2007. http://www.alliancegroup.co.uk/Record-Document-Content-Management.htm BLANCO, Sergio. Mono: La plataforma .NET libre!. Espaa. 11 de Noviembre de 2003. http://www.marblestation.com/publicaciones/paper-mono.pdf BOOCH, Grady. Anlisis y diseo orientado a objetos con aplicaciones. Segunda Edicin. (J. M. Cueva, A. Cernuda, Trads.). Wilmington, Delawere: Addison-Wesley Iberoamericana, 1996. BOOCH, Grady, Ivar Jacobson, James Rumbaugh. El lenguaje Unificado de Modelado. (J. Sez, Trad.). Primera Edicin. Madrid:Addison Wesley Iberoamericana, 1999. CASTAO, Adoracin de Miguel, Mario Piattini V. Fundamentos y modelos de bases de datos. 2da. Edicin. Mxico:Alfaomega:Ra-Ma, 1999. CASTAO, Adoracin de Miguel, Mario Piattini V., Esperanza Marcos M. Diseo de bases de datos relacionales. Mxico:Alfaomega:Ra-Ma, 2000. CONNOLLY, Thomas M., Carolyn Begg. Sistemas de bases de datos : un enfoque prctico para diseo, implementacion y gestin. 4ta. Edicin. Trad. Vuelapluma. Madrid: AddisonWesley, 2005. CODD, Edgar.F. (1970). A Relational Model of Data for Large Shared Data Banks. Vol. 13 (6): 377 - 387. New York: Communications of the ACM, 1970. Consultado el 21 de agosto de 2008. http://portal.acm.org/citation.cfm?id=362685
321

DATE, C. J. Introduccin a los sistemas de bases de datos. tr., Sergio Luis Mara Ruiz Faudn. 7a Edicin. Mxico:Pearson Educacin, 2001. ELMASRI, R. Navathe. Sistemas de Bases de Datos. Conceptos fundamentales. 3era Edicin. Madrid:Addison-Wesley Iberoamericana:Pearson Educacin, 2002. HP DOCULABS. HP LaserJet 4345mfp Series for Distribuited Capture. 2005. http://www.hp.com/large/ipg/assets/solutions/hp_4345_dl_paper.pdf HURWICZ, Michael, Feature Story: The Paperless Office, Network Computing, CMP, August 1, 1995. Consultado el 17 de junio de 2008. http://www.networkcomputing.com/609/609feature2.html Institute of Electrical and Eelectronic Engineers, IEEE Standar for Software Project Management Plans, IEEE Std. 1058-1998, Nueva York:IEEE, 1998. ISO:9001. ISO 9000 Essentials. Geneva, Switzerland, 2008. Consultado el 17 de junio de 2008. http://www.iso.org/iso/iso_catalogue/management_standards/iso_9000_iso_14000/iso_9000_e ssentials.htm JACOBSON, Ivar. Object-Oriented Software Enginnering. A Use Case Driven Approach. Addison-Wesley, 1992. JACOBSON, Ivar, Grady Booch, James Rumbaugh. El proceso unificado de desarrollo de software. tr., Salvador Snchez. Madrid:Addison Wesley, 2000. JACOBSON, Ivar, Grady Booch, James Rumbaugh. El lenguaje unificado de modelado:manual de referencia. tr., Salvador Snchez, Oscar San Juan, Rafael GarcaBermejo. Madrid:Addison Wesley, 2000. MICROSOFT CORP. Overview of the Microsoft .NET Framework. En: Developing Microsoft ASP.NET Web Applications Using Visual Studio .NET Course 2310. Carvajal S.A. de C.V.:Mxico, 2001.
322

MICROSOFT TECHNET. Introducing Windows SharePoint Services. En: Windows Sharepoint Services Administrators Guide. Julio 30, 2004. http://www.microsoft.com/resources/documentation/wss/2/all/adminguide/enus/stsa01.mspx?mfr=true MICROSOFT TECHNET. Windows SharePoint Services Overview. Publicado en Marzo 10, 2003 Actualizado en Marzo 22, 2005. http://www.microsoft.com/technet/windowsserver/sharepoint/V2/techinfo/overview.mspx MICROSOFT OFFICE ONLINE. Microsoft Office SharePoint Portal Server 2003. Customer Evaluation Guide. Septiembre 2003.http://download.microsoft.com/download/e/0/6/e06e6d91-7d14-44d0-83fb2800fcd3a4fb/SharePointGuide.doc MICROSOFT OFFICE ONLINE. SharePoint Portal Server 2003 Overview. Mayo 31, 2003. http://www.microsoft.com/office/sharepoint/prodinfo/overview.mspx MICROSOFT OFFICE ONLINE. SharePoint Products and Technologies Frequently Asked Questions. Consultado el 12 de Septiembre de 2007. http://www.microsoft.com/office/sharepoint/prodinfo/faq.mspx MICROSOFT OFFICE ONLINE. Windows SharePoint Services 3.0 Evaluation Guide. Microsoft Corp. Abril, 2008. Consultado el 1 de Septiembre de 2008. http://download.microsoft.com/download/B/9/E/B9E27997-7A8E-493C-B23B58EEAA3214C8/WSSGuide.doc MONO. The Mono Project. Consultado el 26 de septiembre de 2007. http://www.mono-project.com/What_is_Mono RJS SOFTWARE SYSTEMS. WebDocs - iSeries & Windows Edition. User Guide. Document Version 1.64.1. 2005. Consultado el 30 de agosto de 2008. http://www.rjssoftware.com/docs/rjsimage/Manuals/RJSIMAGE.pdf
323

RUMBAUGH, James. Modelado y diseo orientados a objetos: Metodologa OMT. tr., Jos Rafael Garca-Bermejo Giner ; con la colab. de Antonio Reus Hungra. Hertfordshire, London; Madrid:Prentice-Hall International, 1997. SCHACH, Stephen R. Anlisis y diseo orientado a objetos con UML y el proceso unificado. tr. Lorena Peralta Rosales. Mxico:McGraw-Hill, 2005. SCHMULLER, Joseph. Aprendiendo UML en 24 horas. tr., A. David Garza Marn. Mxico:Pearson educacin, 2000. SILBERSCHATZ, Abraham, Henry F. Korth, S. Sudarshan. Fundamentos de bases de datos. tr., Fernando Senz Prez. 5a edicin. Madrid:McGraw-Hill, 2006. TWAIN, Working Group. TWAIN Specification. Version 1.9a. January 20, 2001 TWAIN, Working Group. TWAIN: Linking Applications and Images A White Paper. Publicado en Marzo 17, 1992, actualizado en Febrero 6, 2001. http://www.twain.org/docs/whitepaper.htm

324