Buenas Practicas Proyectos Informaticos

Editorial de la Universidad Tecnolgica Nacional
ISBN: 978-987-1896-01-1 FacultadRegionalTucumn UniversidadTecnolgicaNacionalU.T.N. Argentina 2012
Editorial de la Universidad Tecnolgica Nacional edUTecNe http://www.edutecne.utn.edu.ar edutecne@utn.edu.ar

[Copyright]LaEditorialdelaU.T.N.recuerdaquelasobraspublicadasensusitiowebsonde libreaccesoparafinesacadmicosycomounmediodedifundirelconocimientogeneradopor autoresuniversitarios,peroquelosmismosyedUTecNesereservanelderechodeautoraa todoslosfinesquecorrespondan.
A mis hijos, Ulises y Gabriel, fuente inagotable de inspiracin constante. Muchas gracias por ser parte de mi vida. Gustavo Gabriel Maigua
Para que mi hijo lo asimile y promueva en el futuro. Emmanuel Fernando Lpez
Contenido
PREFACIO CAPTULO I. INTRODUCCIN A LA DIRECCIN DE PROYECTOS CAPTULO II. FASES DE UN PROYECTO CAPTULO III. FASE DE PLANEACIN CAPTULO IV. FASE PRODUCTIVA CAPTULO V. GESTIN DE RIESGOS CAPTULO VI. RECURSOS HUMANOS CAPTULO VII. REDMINE, SOFTWARE LIBRE DE GESTIN DE PROYECTOS CONCLUSIONES NOTAS BIBLIOGRAFA Y REFERENCIAS WEB ANEXO I: Casos De xito ANEXO II: Herramientas De Financiamiento De Proyectos ANEXO III: ndice De Figuras
PRLOGO
Ante la demanda mundial de formacin de Ingenieros en todas sus especialidades y en particular los ingenieros orientados a la informtica, existe un problema ms, que es la necesidad de formar (preparar) lideres de equipos en cualquier Direccin de Gestin de Proyectos Informticos. Esto implica que no tan solo se necesita al ingeniero formado en la especialidad para ocupar un puesto de trabajo sino que tambin se necesita a un ingeniero que sepa liderar y/o trabajar en equipo para alcanzar el Objetivo que se plantee en una Organizacin. Este libro busca llegar mediante una lectura fcil, con los mecanismos y pasos que debe seguir el lder, no tan solo de la Direccin de Gestin Informtica, sino tambin el lder de grupos por debajo de la Direccin. Es evidente esta falta de formacin y es por ello que las Universidades estn apuntando en sus diseos curriculares, la enseanza de emprendedurismo, trabajo en equipo, planes de negocios, formacin en Recursos Humanos, etc. En el seno del Consejo Mundial de Decanos de Ingeniera, (Global Engineering Dean Council) uno de los debates fue precisamente este tema. Y la conclusin a la que se llego despus de un importante intercambio de ideas fue que, adems de saber identificar todos los parmetros que puedan surgir en el desarrollo de un Proyecto, los Lderes deben tener una fuerte dosis de INNOVACION para alcanzar el Objetivo. Es por ello que resulta necesario que los egresados adquieran estos conocimientos durante la formacin acadmica y un factor, no menor es, la capacitacin de los docentes en estos temas actuales. Estimo entonces que este libro puede ser de gran ayuda no tan solo para alumnos, ingenieros o estudiantes avanzados que requieran esta tcnica de trabajo sino tambin como lectura de referencia para profesores que deseen involucrarse en estos conceptos. Por ltimo, quiero felicitar a los jvenes autores, a quienes tuve la oportunidad de ser su profesor y conocerlos ms de cerca, por el nivel de compromiso y profesionalismo que signific el desafo de escribir este Libro. Los xitos no llegan por azar, uno los construye da a da a partir del momento que elige trabajar sobre el mismo.
Ing. Walter Fabin Soria Decano de la Facultad Regional Tucumn de la Universidad Tecnolgica Nacional Miembro del Comit Ejecutivo del Consejo Mundial de Decanos de Ingeniera
BUENAS PRCTICAS EN LA DIRECCIN Y GESTIN DE PROYECTOS INFORMATICOS
PREFACIO
Objetivos
Se intent escribir un libro de fcil lectura en el que el lector va a encontrar definiciones sencillas pero concisas sobre los aspectos ms importantes de la direccin y gestin de proyectos informticos. Hemos tomado como documentacin de referencia desde estndares tcnicos reconocidos como PMI (PMBOK) o Mtrica v3, hasta principios universales de liderazgo y conduccin de equipos. Esta obra incluye un caso de estudio de ejemplo para que el lector tenga una referencia prctica sobre los diferentes conceptos tericos que se van desarrollando. Esperamos que este libro sea una gran ayuda para quienes deseen incorporar herramientas efectivas en la direccin y gestin de proyectos informticos.
A Quin Se Dirige Este Libro?

La obra Buenas Prcticas en la Direccin y Gestin de Proyectos Informticos va dirigida a todos aquellos que pretendan introducirse en el arte de la Direccin y Gestin de Proyectos Informticos, as como para todos aquellos profesionales con experiencia que necesiten un curso de actualizacin de conocimientos. Est especialmente recomendado por sus autores para: Estudiantes. Tecnlogos. Directores de Proyectos. Responsables de Proyectos con mayor o menos responsabilidad en los mismos. Staff en Project Management. Y en general entusiastas de la Direccin y Gestin de Proyectos Informticos con una formacin limitada en gestin de proyectos o que empiecen de cero.
Organizacin Del Libro

Los contenidos de este libro fueron divididos en siete captulos que van introduciendo paulatinamente al lector en la Direccin de Proyectos Informticos. Se agreg un caso de estudio para explicar de manera prctica los contenidos de los captulos III, IV y V.
En captulo I nos centramos en la definicin de conceptos bsicos que le servirn al lector para abordar la lectura de los restantes captulos del libro. En este mismo captulo se realiza un anlisis sobre la necesidad de la direccin y gestin de proyectos fundamentado en conceptos tericos y experiencia de los autores.
En el captulo II, se definen las principales fases de un proyecto estndar como Planeacin, Ejecucin y Mantenimiento. Las mismas son explicadas en un alto nivel de abstraccin para que el lector pueda diferenciar entre una y otra fase.
En el captulo III se desarrolla a un nivel ms detallado la Fase de Planeacin. Se incluye la concepcin inicial, la definicin del problema y la planificacin del proyecto. Como resultado final de esta fase se obtendr el estudio de viabilidad que permitir determinar si un proyecto es factible o no. Tambin se agrego, al finalizar este captulo, una breve explicacin sobre los Contratos Informticos.
En el captulo IV se desarrolla la Fase Productiva. En la primera parte de este captulo se divide el contenido en las etapas de Anlisis, Diseo, Implementacin y Pruebas. En este captulo el lector podr encontrar detalles puntuales que le permitirn una ejecucin, seguimiento y control ms preciso para dirigir un proyecto informtico. En la segunda parte de este captulo se desarrolla la Fase de Mantenimiento del proyecto. Esta fase representa el proceso de mejora y optimizacin del software despus de su entrega al usuario final, as como tambin la correccin y prevencin de los defectos. Se define claramente los diferentes tipos de mantenimiento y su distribucin del coste.
Luego de hacer una descripcin detallada de las principales Fases de un Proyecto, en el capitulo V se describen los detalles ms importantes de la Gestin de Riesgo y los principales beneficios de realizar un control y seguimientos de los eventos que pueden afectar el alcance de los objetivos del proyecto.
En el capitulo VI, detallamos las principales caractersticas de un equipo de personas que llevaran a cabo un proyecto informtico. Es sabido que un Director de Proyecto tiene a su equipo como herramienta principal para el xito, por eso se detallan las principales caractersticas y habilidades requeridas en el recurso humano involucrado en un proyecto informtico, tanto desde el punto de vista tcnico como as tambin del emocional.
BUENA AS PRCTICAS EN LA DIRECCIN Y GESTIN G DE PROYE ECTOS INFORMATICOS
almente, en el captulo VII, se agre eg documentacin de una u herramiienta libre para la Fina gesti n de proyectos llamada a Redmine. Se consider ro oportuno comentar c a los lectores sobre las p potencialidades que le pueda dar un na herramienta informtica de gestiin a un pro oyecto inform mtico y Red dmine es un buen ejempl o para comp partir.
Com mo elemento os extras a los contenido os, se agreg go documentacin import tante en form ma de Anex xos que brind daran mayor r detalle de a algunos tema as significativ vos referidos s a los conte enidos del lib bro.
Co onvencio ones Utilizadas

Al f final de los captulos c se presentar un depurado o conjunto de d conclusion nes acerca de d las Buen nas Prcticas s en la Direcc cin y Gesti n de Proyec ctos presenta adas. Ade ems, en est te manual se e aade un f formato de notas n especiales a modo o de explicacin y de re esalte de la in nformacin e ideas ms iimportantes:
IMPORTAN NTE Es importan te resaltar que q podremo os encontrar estos o largo del libro. Pueden aparecer a resalltando cuadros a lo puntos impo ortantes de aprendizaje; con inform macin complementa aria; o des stacando cie ertas tcnica as o recomendacio ones tiles.
gradecim mientos Ag
Al I Ing. Gustavo o Rego por sus aportes en el contenido terico, al Ing. Dan niel Talebi por p los casos s de estudio os referenciados y al Ing g. Joaqun Igon I por la informacin provista sob bre las lneas s de financia amiento de proyecto.
CAPTULO I. INTRODUCCIN A LA DIRECCIN DE PROYECTOS
Cristaliza tus metas. Elabora un plan para alcanzarlas. Fjate una fecha lmite. Entonces, con suprema confianza, lleva adelante tu proyecto. (Paul J. Mayer)
1.1
Por qu es necesaria la direccin y gestin de proyectos?
1.1.1 Lo nico constante es el cambio Durante la ltima dcada, la informtica en su conjunto se ha ido simplificando, sin embargo, los entornos de desarrollo han seguido un camino contrario y son cada da ms complejos. Hace algn tiempo, un desarrollo tpico estaba formado por un par de docenas de transacciones, algunos utilitarios y poco ms. Todo era sencillo porque haba pocas cosas donde elegir, casi siempre la eleccin dependa del propio suministrador del hardware y tales plataformas de desarrollo eran estables y no se producan cambios durante algn tiempo importante. El trabajo era realizado de manera artesanal por un programador, que interactuaba directamente con el cliente, y obtena por el mismo la retroalimentacin para medir la calidad. Hoy en da todo esto ha cambiado; las plataformas de desarrollo proliferan y ofrecen nuevas posibilidades que hacen que la oferta sea ms atractiva y se cambia de entornos en funcin de las nuevas posibilidades que los mismos ofrecen. Los usuarios son mucho ms exigentes, demandan unas prestaciones antiguamente no soadas, desde nuevos dispositivos mviles, y esto hace que en muchas ocasiones el diseo grfico y su interfaz genere ms trabajo de programacin que los propios algoritmos para los que se concibe el programa. La necesidad de desarrollar un software normalmente multiplataforma dificulta, no slo el propio desarrollo sino tambin las pruebas de aceptacin del mismo. Hoy no basta con que una aplicacin funcione, sino que debe funcionar en diferentes sistemas operativos y bajo diferentes condiciones. Como si no tuviramos demasiado con tener que solucionar los problemas de hoy, aparecen las preguntas sobre la tecnologa del maana: Qu sistemas tendremos dentro de unos aos?, cmo conseguir un entorno de desarrollo del que se pueda migrar fcilmente al acontecer futuro?, Qu haremos con las aplicaciones existentes en un futuro?, Sern obsoletas?. Estas preguntas que nos formulamos ahora mismo debern ser consideradas por el director del proyecto para conocer el grado de realizacin del software con vistas a un mantenimiento futuro. 1.1.2 Evolucin histrica del concepto de calidad en la industria del software
7
La industria del software es una industria joven que ha evolucionado rpidamente, aunque no tanto como para alcanzar la madurez que tiene la industria tradicional. Es importante recordar que es evidente la influencia de la industria tradicional sobre la industria del software. La siguiente tabla propuesta por Marciniak, pone de manifiesto esta relacin, comparando las diferentes fases superadas por el control de calidad:
Etapa Artesanos Inspeccin Control estadstico del proceso Aseguramiento de la calidad Conformidad con la calidad Calidad dirigida al cliente Calidad dirigida al mercado
Descripcin
Se fan de la creatividad y del buen trabajo artesanal Supervisores inspeccionan la calidad antes de la liberacin de producto Cuantificacin de la calidad del producto, tcnicas de muestreo Uso de estndares en los sistemas de calidad para los procesos Calidad total: se eliminan derroches y minimizan costes Calidad total dirigida hacia el cuidado del cliente y del servicio Calidad total dirigida hacia el cliente existente as como a clientes en potencia
Industria del Software

Aos sesenta Aos setenta
Industria en general
Antes del siglo XIX Siglo XIX
Pocas evidencias de uso
Aos treinta
Aos ochenta
Aos cincuenta
Aos noventa Pocas evidencias de uso Pocas evidencias de uso
Aos ochenta
Aos noventa
Algunas evidencias de uso
Figura 1. Evolucin histrica del concepto de calidad en la industria del software
1.1.3 Tomar el timn del barco Podramos comparar un proyecto software con un barco que est zarpando. Si no se han planificado bien los recursos previamente, ser muy difcil que se pueda llegar a destino. Se deben detectar y organizar todas las tareas. A cada tarea se le debe asignar recursos materiales y humanos para que pueda ser ejecutada en un determinado periodo, considerando siempre un uso eficiente de los recursos. En el caso de que la planificacin haya sido correcta y el proyecto comenz (el barco ha zarpado), ser muy importante un control y seguimiento continuo de los recursos humanos y materiales en el transcurso del tiempo. Una mala administracin de los mismos podr hacer que los recursos se acaben antes de llegar a destino. Esto dejar al barco (proyecto) varado en medio del ocano. Existen diferentes tcnicas para hacer el seguimiento de un proyecto y por lo tanto es importante que el capitn del barco, es decir el director del proyecto, las conozca y las aplique. Generalmente estas tcnicas son tiles y necesarias, casi tanto como una brjula en el mar. En el mejor caso en que la planificacin, el seguimiento y el control sean ejecutados efectivamente, nada nos libra de que una noche cualquiera nos llegue una tormenta que pueda desestabilizar el viaje y el barco se hunda, es decir que el proyecto pueda fracasar. Estas
podran ser todas las variables externas que podran afectar el proyecto: como un aumento inflacionario, una huelga general, aumento excesivo en los precios de producto, etc. En este caso se deber tener un buen anlisis de riesgo para actuar ante cualquier evento con un plan de contingencia apropiado. Es importante que un director de proyectos informticos incorpor herramientas gerenciales para poder planificar y ejecutar el proyecto de una manera profesional.
1.1.4 Demanda laboral en Argentina El "mundo" tecnolgico en la Argentina ya emplea casi a la misma cantidad de personas que la industria automotriz. El fuerte crecimiento que el sector informtico experiment en los ltimos aos lo posicion "cabeza a cabeza" con la industria automotriz en cuanto a la creacin de empleos registrados. As, mientras la industria automotriz (entre terminales y autopartistas) cuenta con 77.362 empleos registrados, las actividades de Informtica (desarrollo e implementacin de software, consultora, suministros de programas, servicios relacionados con bases de datos, procesamiento de datos y servicios de soporte, mantenimiento y reparacin) les dan trabajo a unas 76.500 personas, sealan los datos del Ministerio de Trabajo al primer trimestre de 2010. Hasta noviembre del 2010, la incorporacin de perfiles "tecnolgicos" no par de crecer. La bsqueda de profesionales en el rea de IT se increment entre un 40 y un 50% entre enero y octubre del 2010 en comparacin con el mismo perodo de 2009, segn estimaciones de la consultora Michael Page International Argentina. La contracara del fenmeno Sin embargo, la contracara es la falta de recursos calificados para cubrir los diferentes puestos que requieren las empresas, ya sean multinacionales o Pymes. El siguiente grfico detalla que el grueso de los empleados de esta industria cuenta con un nivel universitario completo (38%) o incompleto (31%).
Figura 2. E Estructura ocupacional real
Los m ms buscad dos En la actualida ad, las emp presas busca an profesion nales no slo orientado os a lo tcn nico y ativo, sino que tambin estn en nfocados al negocio, con c la habillidad de vincular opera conoc cimientos es specializados con aspe ectos referen ntes al presupuesto y lla perspectiv va de crecim miento econ mico de una compaa. . Seg gn (Michael Page), el perf rfil ms solici itado en este momento m es el de los espec cialistas que ocupen o cargo os gerenciales s en el rea de e IT; y por e eso es tan im mportante rec cibir formaci n en la disc ciplina de la Direccin y Gestin de Proyectos. P
ndo aptitude es gerencial es a Informticos 1.1.5 Formalizan mente, casi n no existe un na mesa de decisin do onde no par rticipe Se podra decir que, actualm experto en informtica a como mie embro estrat tgico en la a implement tacin de nuevas un e tecno ologas para obtener un crecimiento c en la organiz zacin. Esta forma sistem abajar mtica de tra exige e el establec cimiento de un u conjunto de mtodos, procedimie entos, herram mientas y tc cnicas que hagan posib ble la realizacin del p royecto seg gn las etap pas y activid dades previs stas y ten su contro ol por parte del d responsab ble del mism mo. facilit Hoy y en da dirig gir un proyec cto de softwa are exige mu ucho ms qu ue conocimie entos tcnico os. Se neces sita tener ca apacidades de d planificaciin y liderazg go. Entre la as cualidades s que se deb beran busca ar para el Director del Pr royecto cabe en destacar la as siguientes s: mente estr ructurada y lgica, lidera azgo y acep ptacin por el e grupo de trabajo, con nocimiento del d sector de ad del e la activida proye ecto, y madurez y formac cin especfic ca en aspect tos gerenciales (direccin n por objetivos).
10
Las universidades del primer mundo han comenzado a ver la necesidad de proveer herramientas gerenciales a los directores de proyectos informticos, ya que esta rama de la industria viene generando numerosos puestos de trabajo. Esto ha comenzado verse plasmado en nuevas ofertas de postgrado de mster en Direccin de Proyectos Informticos.
1.1.6 Necesidad de la direccin y gestin del software Podra decirse que la industria del software ha crecido de manera exponencial en los ltimos aos. Este crecimiento se dio tambin con la cantidad de puestos de trabajo generados. Los roles fueron cambiando durante este crecimiento desde un producto artesanal a un producto profesional. El artesano informtico se convirti en Director de Proyectos, y ahora tiene la responsabilidad de adquirir aptitudes gerenciales para afrontar los desafos futuros.
1.2
Conceptos bsicos
1.2.1 Proyecto 1.2.1.1 Definicin
Un proyecto es un esfuerzo temporal acometido para crear un nico servicio o producto.
Conjunto de actividades planificadas, ejecutadas y supervisadas con el fin de alcanzar un fin comn con recursos finitos
Hay que recordar que uno de los recursos finitos ms importante es el tiempo. La naturaleza temporal de los proyectos indica un principio y un final definidos. El final se alcanza cuando se logran los objetivos del proyecto o cuando se termina el proyecto porque sus objetivos no se cumplirn o no pueden ser cumplidos, o cuando ya no existe la necesidad que dio origen al proyecto. 1.2.1.2 Caractersticas de un proyecto
Es imprescindible, para llevar a cabo un proyecto con xito, discernir claramente un objetivo a cumplir. Para ello es necesaria la intervencin de personas especialistas que se encarguen de desarrollar cada una de las fases de las que consta. 1.2.1.3 Tipos de proyectos
Los proyectos pueden ser de diversa ndole, existen mltiples clasificaciones y entre ellas podemos considerar:
11
1. Tcnicos y no tcnicos. 2. Unipersonales y multipersonales. 3. Monodisciplinares y multidisciplinares. 4. Monocontrato o multicontrato. 5. Resultados: tangibles o intangibles. 6. Rentabilidad econmica o rentabilidad social. 7. Con fines claros: proyectos espaciales. 8. Proactivos y Reactivos. 9. Internos y Externos. 10. De mayor o menor envergadura. 11. Inversin propia o externa (privada/pblica) o mixta. 12. De investigacin y desarrollo. 1.2.1.4 Entorno del proyecto
El conjunto de condiciones en las que se va a realizar el proyecto se conoce como entorno. El entorno del proyecto puede cambiar fcilmente, en especial el contexto socio-econmico. La influencia del entorno sobre el proyecto ser ms intensa cuanto ms duras sean las condiciones econmicas y sociales. A continuacin se muestra una imagen ilustrativa:
Entorno
Condiciones sociales y econmicas duras
Proyecto
Figura 3. Influencia del Entorno en el Proyecto
Las pocas de crisis que traen condiciones sociales y econmicas duras terminan haciendo que el entorno influya en el proyecto de diferentes maneras. Por otra parte, tambin es importante tener en cuenta que la influencia del proyecto sobre el entorno ser ms intensa cuanto mayor sea la masa del proyecto y su grado de innovacin.
Proyecto
Masa del Proyecto Innovacin
Entorno
Figura 4. Influencia del Proyecto en el Entorno
12
Un ejemplo de esta influencia pueden ser los telfonos mviles, que fueron insertados en el entorno, produciendo una gran influencia en el mismo.
1.2.2 Direccin de Proyectos La direccin de proyectos es la aplicacin de conocimientos, habilidades, herramientas y tcnicas a las actividades del proyecto para cumplir con los requisitos del mismo. Evidentemente, supone gozar de una visibilidad ms amplia sobre los recursos y los objetivos, y difcilmente estaremos dispuestos a renunciar a la gestin de nuestros propios recursos aunque, en muchos casos, implique cierta responsabilidad adicional y, por qu no decirlo, algn que otro dolor de cabeza. Asumido lo anterior, por qu los jvenes profesionales son tan reacios a dirigir y a gestionar los proyectos en los que participan? Es evidente que al optar por una carrera profesional no vinculada con la gestin, el individuo se decanta por actividades tcnicas, pero eso no ha de significar renunciar a la perspectiva que supone participar en las tareas de direccin y gestin de los proyectos en los que trabaje. Participar en la gestin y direccin de un proyecto supone conocer los recursos y objetivos del mismo, as como las limitaciones a tener en cuenta, y este conocimiento nos permite optimizar nuestro trabajo y adaptarlo a los requisitos ms especficos y ms relevantes del proyecto. La direccin pasa de ser una tarea aislada a constituirse en una herramienta para mejorar el desarrollo de las actividades tcnicas. El cumplimiento de los requisitos del proyecto se logra mediante la aplicacin e integracin adecuadas de procesos de la direccin de proyectos agrupados lgicamente en lo que se determina FASE. Las FASEs principales de un proyecto son: Iniciacin Planificacin Ejecucin Seguimiento y Control Cierre.
1.2.3 Proyecto Informtico Un Proyecto Informtico es un sistema de cursos de acciones simultneas y/o secuenciales que incluye personas, equipamientos de hardware, software y comunicaciones, enfocadas en obtener uno o ms resultados deseables sobre un sistema de informacin.
13
Los recursos ms frecuentemente utilizados que caracterizan a un sistema de informacin, son los componentes de la Tecnologa de la Informacin (TI) como puede ser el uso de Hardware, Software y Comunicaciones. Considerando entonces, la importancia que la informtica tiene en los planes estratgicos de cualquier empresa moderna, no solamente se debe tener en cuenta la evolucin de los recursos de la tecnologa de la informacin, sino tambin las distintas metodologas para el desarrollo de los sistemas de informacin.
1.2.4 Tipos de Proyectos Informticos Existen diferentes clasificaciones de los tipos de proyectos informticos. A continuacin listamos los principales tipos de proyectos informticos: Software o o Metodologas, Ingeniera del software, etc. Software empotrado.
Hardware o Velocidad de Proceso, S.O., Servicios, etc.
Comunicaciones y Redes o Protocolos, Buses, Cableado, etc.
Instalaciones de Hardware o Peso de los equipos, Instalacin de aire acondicionado, Suelo flotante, Extincin de incendios, Conectividad externa, etc. o CPDs, Sites de Internet, etc.
Sistemas de Misin Crtica o o Industrial, Mdica, Nuclear, Militar, Aeronutica, etc. Tiempo real, Esquemas productivos, etc.
Auditoras o Sistemas, Seguridad, Calidad, Legislacin
Peritajes o Civiles, Penales, Laborales
Consultora y Asesora o Sobre cualquier actividad.
Seguridad Informtica (ISO 17799) o Seguridad de la Informacin.
Reingeniera de Proyectos
14
BUE ENAS PRCTICAS EN E LA DIRECCIN Y GESTIN DE PRO OYECTOS INFORMA ATICOS
De cualquiera de d los tipos.
s proyectos de d desarrollo o de softwar re se diferen ncian de los otros proyec ctos de inge eniera Los tradic cional en la naturaleza n l gica del pro oducto softw ware.
El s software se desarrolla d ordemos que el e software se desarrolla, Reco no se e fabrica en un n sentido clsi ico.
oyectos de ingeniera la buena calidad se adquie ere mediante e un buen diseo, En todos los pro pero en el caso del d software la etapa de construccin n incide pobremente en su calidad, no n as a construcci n de hardwa are o de una a obra civil. Otra diferen ncia es que el software no se en la estropea, el paso o del tiempo o males del e entorno no in nciden en el aumento de la tasa de fa allos. , no se pued de gestionar r un proyecto o de desarro ollo de softw ware como s si se tratara de un As, proye ecto de fabric cacin. La g gestin del proyecto p de software es el primer niv vel del proce eso de ingen niera de soft tware, porqu ue cubre tod do el proceso o de desarro ollo. Para conseguir un proyecto p de s software fruc ctfero se de ebe compren nder el mbito del trabajjo a realizar, , los riesgos en los que se puede in ncurrir, los re ecursos requ ueridos, las tareas t a llev var a cabo, el e esfuerzo (coste) ( a con nsumir y el plan p a segui ir.
1.2.5 Direccin y Gestin de e Proyectos s Informtico os La direccin y gestin de e proyectos es la aplicacin del enfoque e de sistemas pa ara la e tareas tecn nolgicas com e proyectos cuyos objetiv vos se estab blecen admin nistracin de mplejas o de explc citamente en n trminos de e tiempo, cos stes y parm metros de rea alizacin. Sin entrar en metodologa as de traba ajo concreta as, podemo os decir que e para ges stionar uadamente un proyecto o de desarr rollo de soft tware es recomendable e disponer de d las adecu siguie entes herram mientas: 1. Un sist tema de pla anificacin q que nos per rmita organiz zar el proyec cto en funcin de hitos, ta areas y subta areas, con as signacin y control c de tie empos y recu ursos materiales y humano os. Idealmen nte el sistem ma de planific cacin debe permitirnos tambin ha acer el seguimi iento y reaju ustar la plani ficacin en funcin f de la a evolucin d del proyecto. Este compon nente debe permitir p defin nir un proyec cto como un na sucesin de hitos que e a su vez se descompong gan en tarea as y subtarea as, con asign nacin de tie empo y recur rsos a u Adem s de defin nir la planif ficacin, el sistema de ebe proporcionar cada una. mecanis smos para hacer el se eguimiento de d la misma a y modifica ar la planific cacin
15
cuando sea necesario. Para que esto sea posible es recomendable disponer de herramientas para llevar el control de los tiempos estimados y empleados para cada tarea; para poder controlar de verdad la evolucin del proyecto es importante que las personas que trabajan en el proyecto vayan reportando el tiempo que dedican a cada tarea y actualicen el estado de las mismas con relativa frecuencia. Para un proyecto normal puede ser suficiente con actualizar semanalmente, aunque el control de tiempos siempre es ms fiable si se completa diariamente. 2. Un sistema de gestin documental, que nos servir para almacenar y mantener los documentos obtenidos o generados durante el desarrollo del proyecto y acceder a ellos cmodamente. Cada hito, tarea o subtarea puede implicar la obtencin o generacin de documentacin (actas de reuniones, documentos de diseo, etc.). Idealmente, el sistema de gestin de proyectos debe permitir que almacenemos esa documentacin en el propio sistema. 3. Un sistema de control de versiones, que se utilizar para permitir el desarrollo concurrente y para mantener la historia del cdigo fuente y parte de la documentacin producida en el proyecto. Al tratarse de proyectos informticos lo normal es que se trabaje con cdigo fuente y con documentos que van evolucionando a lo largo del desarrollo y que deben ser modificados por mltiples personas, por lo que resulta casi imprescindible disponer de un sistema de control de versiones que permita mantener la historia de los ficheros generados y que ms de una persona trabaje concurrentemente sobre el mismo cdigo. 4. Un sistema de gestin de incidencias que se emplear para hacer el seguimiento de los errores detectados y sus correcciones, tanto aquellos reportados por los responsables de la prueba del software como por los desarrolladores o los usuarios finales. Este tipo de sistema tambin se puede utilizar como sistema de seguimiento de tareas de corta duracin asociadas a fases del proyecto, a errores detectados o a cambios relacionados con solicitudes de mejora solicitadas por el cliente.
1.2.6 Rol del Director del Proyecto El director del proyecto es la persona asignada por la organizacin ejecutante para alcanzar los objetivos del proyecto. Varias de las herramientas y tcnicas para dirigir proyectos son especficas a la direccin de proyectos. Sin embargo, comprender y aplicar los conocimientos, herramientas y tcnicas que se reconocen como buenas prcticas no es suficiente para gestionar los proyectos de un modo eficaz y eficiente. Adems de las habilidades especficas a un rea y de las competencias generales en materia de gestin requeridas para el proyecto, la direccin de proyectos efectiva requiere que el director del proyecto cuente con las siguientes caractersticas:
16
Con nocimiento y habilidad des gerenc ciales. Se refiere r a lo que directo or del proy yecto sabe sobre s la direc ccin de proy yectos.
Des sempeo. Se S refiere a lo o que el dire ector del pro oyecto puede e hacer o log grar si aplica los conoc cimientos en direccin de e proyectos.
Liderazgo. Esta ablecer la un nidad de prop psito y la or rientacin de e la direccin n de la orga anizacin. Crear C y mante ener un amb biente interno o, en el cual el personal pueda p llegar a involucr rarse totalme ente en el log gro de los ob bjetivos de la a organizaci n.
gir un proyec cto por lo general implica a: Dirig Abordar r las diversa as necesida ades, inquiet tudes y exp pectativas de e los interesados segn se s planifica y efecta el p proyecto. Liderar efectivamen nte un grupo humano. Equilibr rar las restr ricciones co ontrapuestas del proyec cto que se relacionan, entre calidad, , costes y du uracin. Identific car y gestiona ar riesgos.
o), en el libr ro Direccin n y Gestin de Proyecto os, hizo un na de las mejores (Domingo Ajenjo repre esentaciones s de la labor del d Director d de Proyecto. . La siguiente e figura 5 lo muestra:
17
Figura 5. La Labor del Director de Proyectos
Esta imagen representa que el camino del director de proyecto es dificultoso, que tiene un objetivo, pero el alcance del mismo puede ser afectado por contingencias e imprevistos. Un buen Director de Proyectos puede minimizar posibles problemas de contingencias e imprevistos realizando un correcto Anlisis de Riesgos, como se indica en el capitulo V del libro. Esta imagen tambin muestra que el Director de Proyectos avanzar en el tiempo teniendo en cuenta siempre los plazos y costes, los cuales deber ser controlados constantemente. Con recursos materiales y humanos, un director de proyectos podr alcanzar sus objetivos, por eso la importancia de hacer una seleccin correcta de los mismos antes de comenzar el proyecto. Finalmente, el grafico muestra que un director de proyectos siempre ser juzgado, por lo que tiene que estar preparado para recibir los resultados finales y hacer un anlisis correcto del mismo.
1.2.7 Gestin
Articular el mtodo para alcanzar un objetivo nico y no repetitivo en un plazo con principio y fin claros utilizando las tcnicas que nos proporciona la gestin.
Las principales tareas a realizar son: planificar y establecer estrategias adecuadas, organizar a los miembros y equipos para lograr los objetivos que queremos alcanzar, y controlar y comprobar si se estn alcanzando dichos objetivos. La organizacin de un proyecto consiste en disear la estructura con la que vamos a establecer las dependencias entre individuos, departamentos, cosas... dentro del proyecto. Asimismo, debemos asignar las tareas ms idneas para esas capacidades y el tiempo estimado para cumplir las tareas o funciones.
1.2.8 La empresa 1.2.8.1 Definicin de empresa Una empresa es el ejercicio profesional de una actividad econmica planificada con el objetivo de ofrecer un producto o servicio.
Para crear una empresa se necesita: Negocio: cierta actividad comercial que genera beneficios.
18
Sociedad mercantil: sociedad que tiene por objeto la realizacin de uno o ms actos de comercio. Es reconocida como una unidad jurdica, y cuenta con un patrimonio propio.
Explotacin: conjunto de procesos tecnolgicos por los que a partir de unos elementos se obtienen ciertos productos o resultados.
Planta o establecimiento: unidad espacial o fsica donde se localiza la actividad econmica o comercial.
1.2.8.2 Dimensiones de la empresa Dimensin funcional: actividad organizada y alternativa al mercado con nimo de lucro. Dimensin tcnico-econmica: actividad productiva de bienes y servicios. Se encarga de la transformacin de productos. Dimensin econmico-financiera: actividad econmica que genera valor y dinero. Dimensin jurdico-mercantil: actividad generadora de relaciones. Dimensin social: actividad compuesta por relaciones humanas y de poder. Se ocupa de la comunicacin y la relacin entre las personas que forman la empresa.
1.2.8.3 El empresario Podemos encontrar varias definiciones para empresario: Persona que asume riesgos. Persona que cede el capital para iniciar la actividad empresarial. Persona que establece cmo se realiza la combinacin de factores dentro de la empresa. Persona que fija objetivos a conseguir, establece los medios que llevarn a conseguir esos objetivos y plantea las medidas econmicas oportunas y ms favorables para ello.
1.2.8.4 El directivo Se encarga de la direccin de la empresa. Se ocupar, entre otras, de las siguientes cuestiones: Globalizacin de la economa (eliminacin de barreras polticas, aduaneras,...). Descentralizacin a nivel de pases y de estructura de la propia empresa.
19
Orientacin hacia procesos y no hacia funciones. Divisin del trabajo: cada vez ms y ms rpido. Trabajo en red: mejora la coordinacin y se asimilan ms fcilmente los cambios. Trabajo en grupo: mejora la eficiencia y la productividad. Definicin de objetivos y del camino a seguir para conseguirlos (management).
C CAPTU ULO II. F FASES DE D UN PROYEC P CTO
Lo os hombres no n viven junto os porque s , sino para acometer a juntos grandes empresas. (Jos Or rtega y Gass set)
Ante es de comenzar el desa arrollo de un proyecto ha ay que tener r en cuenta y estudiar to odas y cada una de las s fases por las que pas sa. Segn el PMBOK, Las fases del proyect to son divisi iones dentro o del mismo proyecto, d donde es ne ecesario ejer rcer un cont trol adicional para gestio onar eficazm mente la conc clusin de un n entregable mayor En este captul lo vamos a redactar un na descripci n bsica de las difere entes fases de d un ecto. Sin entrar en discusin con la as diferentes s metodologas que exis sten actualm mente, proye nosot tros preferim mos simplific car la explic cacin al lec ctor diciendo o que en la a mayora de d los proye ectos se pue eden distinguir tres gran ndes seccion nes de traba ajo: planeac cin, ejecuc cin y mant tenimiento.
Figura 6. Fase es Principales de d un Proyecto o
m en la a figura 6, la a planeacin n es donde est la fase e de definici n del Tal como se muestra ecto y donde e entra la plan nificacin de el proyecto. proye Planeac cin o o Def finicin del problema. Planificacin de el proyecto.
21
ando finaliza amos la Plan neacin, nos s tenemos que q hacer la siguiente p pregunta obligada: Cua Es v viable el proy yecto?
Figura 7 7. Secuencia de d Fases
sta en marc nsecuenteme ente con la figura 7, la ejecucin es s donde se trata la pues cha, la Con fase p productiva y la conclusi n del proyec cto. Ejecuci n del proyecto o o o Pue esta en marc cha. Fas se productiva a. Con nclusin del proyecto.
a vez realiza ado y entregado el proye ecto, se inic cializa la fase e de Manten nimiento, que trae Una carac ctersticas pr ropias del pro oyecto y el e entorno en el que fue implantado.
2.1 P Planeacin
n de un pro oyecto es imp portante tene er claro tanto o el problema a que se pre etende En la planeaci cionar, el producto que se e quiere obte ener, como el e servicio qu ue se pretend de proporcionar. A soluc su ve ez es necesa ario evaluar ta anto los cost tes econmic cos como los s recursos hu umanos. Fas ses de la plan neacin: Inicio y Definicin del Problem ma, es decir, clarificar el producto o s servicio a obt tener.
22
Planific cacin del Proyecto P ; ate ender a las necesidades n que aparece ern a lo larg go del desarro ollo, anticipando el curso o de las tareas a realizar, la secu uencia en que se llevarn n a cabo, los recursos y e el momento en e que sern n necesarios s.
Esta a fase es exp plicada detalladamente e en el captulo o III del libro.
2.1.1 Inicio y Def finicin del problema El o origen de un proyecto suele s surgir r a partir de e una necesidad que se e convierte en un problema. En es ste punto hay y que trabaja ar con los usuarios, dire ectores de em mpresa y clientes, ue ser de el llos de quien n tendremos que obtener r la informacin para sabe side el ya qu er donde res problema y donde est la opo ortunidad. A la definicin n del problem ma muchas v veces no se e le da portancia que se merece e. la imp Hay y que tener en cuenta que todo el p proyecto se basar en esta e definici n y es mejo or que quede clara. Deb be ser revisa ada por todo os los usuar rios, directore es de empre esa y cliente es. En fase se defin nen, entre otr ras cosas, lo os lmites del proyecto. esta f
Act ta de Constitu ucin de Proy yecto Es altamente re ecomendable crear un Ac cta de Cons stitucin del ecto, basado e en PMI, que autorice a formal lmente un pro oyecto o una Proye fase, y en la misma a, documentar los requisitos iniciales que e satisfacen n vas de los interesados. Para ms las necesidades y expectativ inform macion ver el c caso de estud dio presentado o en esta obra a.
2.1.2 Planificaci n del Proye ecto entificar toda as las cosas necesarias para p poder a lcanzar el ob bjetivo En esta fase se debern ide marcado, conside erando las tr res dimensio ones sobre lo os que se ap poyar el des sarrollo de to odo el ecto: proye Calidad d: viene dada a por las esp pecificaciones. Coste, valorado en el presupue sto. Duraci n: asignada a en el calen dario de trab bajo.
23
Figura a 8. Relacin de e Calidad, Cos sto y Duracin de un Proyecto o
y quien sepa ara el anlisis s de la aplica acin de la propia p planificacin, por e entenderse que q la Hay prime era es una ta area tcnica, mientras qu ue la planifica acin es una a tarea de ge estin. Aun siendo s as, ti ienen que re ealizarse de forma f simult nea. Hay y que planif ficar el traba ajo antes de e llevarlo a cabo, c antes de realizar el anlisis de d los trabaj ajos asociados a ste, pero difcilm mente se po odr realizar la planific cacin de to odo el proye ecto.
ar en la etapa a definicin d del problema a: Tareas a realiza Estimar el tamao de d la aplicac cin a desarr rollar. Estudia ar el sistema a actual. Discutir r y analizar lo o que se des sea obtener. Identific car las tareas s a realizar. Asigna ar recursos a cada tarea . Crear un calendario o de las tare eas. Realizar un estudio o econmico o.
Pr resentacin d de Oferta al Cliente C Es importante re esaltar que podremos p pre esentar una O Oferta de man nera responsa able al cliente solo cuando tengamos t reallizada una plan nificacion corre ecta del proye ecto.
24 Ejecucin 2.2 E
ecto, se trata a de llevar a cabo el plan n previo. La ejecucin se e ver En la ejecucin de un proye fuerte emente influida por la planificacin, es decir, un na mala planificacin su upondr una a mala ejecu ucin. Fas ses de la ejec cucin: Puesta en marcha. Fase pr roductiva. Conclus sin del proy yecto. Esta f fase es explicada detalla adamente en n el captulo IV del libro.
m 2.2.1 Puesta en marcha po de desarr e ha de organ nizar el equip rollo, los mecanismos de e comunicacin, la En esta fase se nacin de role es y de responsabilidade es a cada pe ersona. asign Las s principales tareas son: nal de la fase de Ajustar a las dispo onibilidades a actuales las necesidade es de person acin. planifica Establecimiento de la estructura a organizativa a. Definir responsabilid r dades y auto oridad. n muchas oc Organiz zar el lugar de d trabajo. En casiones el comienzo c de e un proyecto o tiene tareas como c instalacin de equi pamientos, acondicionam a miento de loc cales, etc. Puesta en funciona amiento del e equipo. Orga anizar reunio ones ms o menos informales ue se conozc can las pers sonas del eq quipo en el caso c de que e esto no se ea as; para qu esto evi itar malente endidos y co nflictos durante la ejecuc cin del proy yecto. Divulgacin de los estndares de trabajo y sistemas de informes s. Al comenzar el ms receptiva as y esta es una razn p proyecto, las personas estn m para introducir los nuevos mtodos de trabajo.
Ajustar P Proyecto Es estrat gico ajustar r los requisitos, recursos s y personas a las disponib bilidades actu uales para ev vitar inconvenien ntes y desperdicios de rec curso en la F Fase Productiva. .
25
2.2.2 Fase productiva En esta fase se realiza la actividad gruesa del proyecto. En la misma se realizarn actividades de anlisis, diseo, implementacin y pruebas. Todo el equipo de trabajo asignado al proyecto estar abocado a las diferentes actividades designadas. En esta fase productiva ya no debera existir alguna duda respecto a las especificaciones, recursos y personas en situacin de trabajo. stas deben llevar a cabo cada una de las tareas que se les ha asignado. Aunque esta ltima frase es correcta, tambin lo es saber que existen riesgos en todos los proyectos, por lo tanto, es muy importante hacer un seguimiento del mismo y actuar rpidamente ante cada evento que pueda alterar el curso normal del proyecto. El responsable del proyecto debe tomar medidas de rendimiento, revisar los informes de los empleados, mantener reuniones para identificar los problemas antes de que aparezcan y en este caso poner en prctica las acciones correctivas y preventivas necesarias.
2.2.3 Conclusin del Proyecto En esta fase se trata de dar por finalizado el proyecto y entregar el producto definitivamente al cliente. Las principales actividades a realizar son stas: Revisar las desviaciones del proyecto e identificarlas para evitarlas en futuros proyectos. Reasignar el personal a los nuevos proyectos o reintegrarlos en los departamentos de partida. Es interesante documentar las relaciones entre los empleados para futuros proyectos.
2.3 Fase de Mantenimiento
Es el proceso de mejora y optimizacin del software despus de su entrega al usuario final (es decir; revisin del programa), as como tambin la correccin y prevencin de los defectos. La fase de mantenimiento es la fase que viene despus de la implantacin. Esta fase es explicada detalladamente en la seccin 4.8 de este libro.
CAPTULO III. . FASE DE PLA ANEACI N
q importa, sino la plani ificacin. (Dr. Graeme E Edwards) No es el plan lo que
Descripci n de la Fase de Pla aneacin 3.1 D
e incluye la concepcin c iinicial, la def finicin del problema p y la a planificaci n del En esta fase se ecto. Como resultado r final de esta fa ase se obten ndr el estud dio de viabiliidad que per rmitir proye deter rminar si un n proyecto es e factible o no. En es ste libro se detallarn h herramientas s para deter rminar una factibilidad f t cnica, de g gestin y econmica. Un n proyecto p podra ser fa actible tcnic camente, es s decir que se puede re ealizar con los recursos adquiridos para el proyecto. Tamb bin podra tener factibilid dad de gesti n, es decir, , que los tiem mpos estimad neos y dos son idn que los recursos asignados estarn e dispo onibles para afrontar el esfuerzo e estiimado. Por ltimo, os decir que e un proyecto o es factible econmicam mente si el p precio obtenido es tambin podramo e pago deter rminada por el plan finan nciero no pro oduce afrontable por el cliente, y si la forma de una prdida. . Estas tres s variantes son sumam mente import tantes en la a mayora de d los ningu proye ectos, pero es e importante e recalcar qu ue no son las nicas. Po or ejemplo, u un proyecto podra p ser fa actible en lo os tres punto os anteriores s, pero no serlo s a nivel poltico en el mbito que se desem mpea. Es decir, d si el pr royecto tiene e intereses po olticos y est tos no son cu umplimentad dos, el proye ecto dejara de d ser factibl le.
Figura 9. La L fase de plan neacin genera a el Estudio de e Viabilidad
27
3.2 Inicio del Proyecto
Un proyecto siempre comienza cuando se descubre una necesidad en el entorno. Esta necesidad puede venir desde un potencial cliente. Esta necesidad puede generar un proyecto nuevo o una nueva versin de un proyecto (producto) ya existente. Pero que exista esa necesidad no quiere decir que directamente comenzaremos a trabajar en el proyecto sin realizar un anlisis previo. Lo primero que tenemos que analizar es si tenemos capacidades tcnicas, recursos (fsicos, temporales y humanos) para poder realizar un proyecto que pueda satisfacer esa necesidad. Sin dejar de considerar siempre, si el proyecto es de nuestro inters o no. Para esto, antes que nada, tenemos que realizar un relevamiento de informacin pertinente para definir algunos puntos claves: Objetivos del proyecto. Potencial Cliente. Sector del mercado que se beneficiara con el proyecto. Necesidad de Negocio. Oportunidades de Negocio que justifiquen la inversin. Beneficios cuantitativos y cualitativos que brindara el proyecto. Identificacin del producto o servicio que se brindar. Responsable del proyecto. Principales Hitos y Eventos del proyecto (previo a la planificacin). Interesados en el proyecto. Suposicin o restricciones que se puedan identificar del proyecto.
Esta informacin se plasma en el Acta de Constitucin del Proyecto y registro de interesados. Cuando el acta de constitucin del proyecto recibe aprobacin, el proyecto se considera autorizado oficialmente. Aunque el equipo de direccin del proyecto pueda colaborar en la redaccin de este acta, la aprobacin y el financiamiento se manejan fuera de los lmites del proyecto.
28
Act ta de Constitu tucin de Pro oyecto Es altamente re ecomendable formalizar esto en un doc cumento. El Acta a de Constituc cin de Proyec cto de PMI, es s un herramie enta til para esta formalizacin n. Para apre ender cmo desarrollar u un Acta de Cons stitucin de p proyecto reco omendamos revisar r la sec ccin 3.3.1 Desa arrollar el Acta a de Constituci in del Proyec cto del PMBO OK.
estratgico involucrar a los l clientes y a otros inte eresados dur rante la inicia acin, ya que e esto Es e mejor ra la proba abilidad de contar con propiedad compartida, con la ac ceptacin de d los entre egables y con n la satisfacc cin del clien te y dems interesados. nstitucin de e Proyecto re epresenta un na documentacin forma al de la nece esidad Un Acta de Con egocio que el proyecto se compro ometi a abo ordar. Adem ms esto per rmite verificar los de ne criterios de xito y revisar la influencia y los objetivo os de los inte eresados en n el proyecto o. Con ede tomar una decisi n sobre la l necesida ad de cont tinuar, este documento ya se pue poner o susp pender el pr royecto. posp
3.3 D Definicin n del Problema
mo se dijo anteriormente e, el origen d de un proyec cto suele surgir a partir d de una nece esidad Com que s se convierte en un proble ema. Mucha as veces el cliente c cree que q puede n ecesitar algo o pero no ha a identificado o claramente e cul es su u problema. Es responsa abilidad del equipo de tr rabajo ayuda ar a encontr rar y definir el e problema que est inc citando el de esarrollo del proyecto. En n este punto o hay que tra abajar con los usuarios, d directores de e empresa, clientes y todo os los interesados en el proyecto, ya a que sern ellos de quie enes tendrem mos que obte ener la inform macin para saber es el problem ma. cul e Una a adecuada definicin d de el problema r requiere de la a capacidad para diferen nciar entre ca ausas, sntom mas y neces sidades para ser resuelta as tcnicame ente. El p problema pe ermite conoc cer y delimita ar el terreno o de lo desc conocido, y es decisivo en el result tado final: un na definicin n incorrecta nos lleva a encontrar e un na posible so olucin incor rrecta. Su p planteamiento o adecuado o es necesa ario para de eterminar el alcance de el proyecto y las posib bles vas de solucin. s Hay y que tener en cuenta que todo el p proyecto se basar en esta e definici n y es mejo or que quede bien clarific cada. Debe ser s revisada a por todos lo os interesado os en el proy yecto. ar en la fase definicin de el problema: Tareas a realiza Estudia ar el sistema a y contexto a actual. Discutir r y analizar lo o que se des sea obtener.
29
Clarifica ar las reas de la empre esa que se vern afectad das. onentes, aclarando: Definir el problema y sus compo o o o Que es fund damental. Que es deseable. Que es opcional.
car al/los responsable/s del proyecto o. Identific Crear una declarac cin clara de e lo que se va a soluciona ar. Validar r la definicin n inicial del p problema con n los interesa ados en el pr royecto.
Definici n del Proble ema en tiempo y forma Es recom mendable real lizar la definici in del proble ema como prim mera actividad en un proyec cto. Es preferi rible zar las activid no comenz dades posteri iores si no se e si tiene una d definicin clar ra del problem ma y validada p por el cliente.
3.3.1 Caso de Es studio: Defin nicin del P Problema uacin actua al. Situ oratorios de anlisis cln Un gran problem ma que aque eja a los labo nicos de gran n envergadura (en ovincia de Tu ucumn) no es la limitac cin en la infr raestructura de los mism mos, sino ms bien la pro es la a incompleta administrac cin de la in nformacin necesaria n pa ara el desarr rollo operativ vo del ndose estos s problemas en un factor r limitante pa ara su crecim miento. negocio. Convirti a problemt tica de informacin enc cuentra su origen, de forma parc cial, en la amplia a Esta imple ementacin de d sistemas informticos s en las orga anizaciones desde d hace aproximadam mente 15 aos atrs (1 1995), los cuales c estab ban caracter rizados por carecer de metodologas de rrollo que pe ermitiesen re ealizar un an nlisis y dise eo profesion nal, y en dn nde gran parte de desar las organizacione es de Tucum mn tuvieron acceso a un n software a bajo coste que gestiona ase la macin de su negocio, lo que no im mplica la sati isfaccin de las necesid dades reales. Esto inform condu ujo a una ma ala gestin de d la informa acin, resulta ando en dism minucin del nivel de efic ciencia de las organizaciones y carencia de satis sfaccin gen neral. Como alternativa a esto, hoy en e da nuevas tecno ologas perm miten la inte egracin de servicios re elacionados a la informacin, las n brindando una nueva n gama a de funcion nalidades que aumenta a la satisfac ccin genera al del rio. El Sistema de Gest tin Bioqum mica se analiza y disea a para soluc cionar este factor usuar limita ante, considerndose como c un sis stema aboc cado a las necesidade es reales de d los Laboratorios Bioq qumicos y por lo tanto o de comerc cializacin fa actible. El siiguiente diag grama a como las diferentes d causas interact tan generando el proble ema. ilustra
30
Figura 10. . Diagrama Cau usa-Efecto
Tom mando como o referencia las caracter sticas de un no de los mejores sistem mas del mer rcado, realiz zamos la sigu uiente compa arativa:
31
Figura 11. Di iferencia contr ra Soluciones
os son solo algunos parmetros de comparacin n, no debe considerarse c una comparacin Esto exhau ustiva, ya qu ue se deben realizar pru uebas comple etas de func cionales, de c stema, carga de sis de us sabilidad, de seguridad, y de integrida ad entre otra as.
32
Si bien se observa que Omega 3000 es un producto que ofrece una gran gama de funcionalidades que nuestra propuesta no iguala, observamos que al ser tan general se pierde lo particular y los requerimientos menores pero necesarias, tal como lo es la posibilidad de facturacin de anlisis al Colegio de Bioqumicos de Tucumn. Esto evidencia la insatisfaccin de las necesidades reales de los laboratorios, ya que no se adapta realmente a lo que el laboratorio necesita. Otro ejemplo de esta situacin es el llamado a sala de extraccin de paciente de estudios de VIH. Normalmente, los sistemas no contemplan que se les asigne un nmero de turno para la extraccin, por lo que los pacientes son llamados por sus nombres. Ahora esto crea un potencial conflicto ya que la realizacin de anlisis de VIH es confidencial segn lo establece la Ley 23.798 en su artculo 2 inciso E. Y para el registro del paciente Se utilizar, exclusivamente, un sistema que combine las iniciales del nombre y del apellido, da y ao de nacimiento. Los das y meses de un solo dgito sern antepuestos de nmero cero segn lo establece el DECRETO REGLAMENTARIO N 1.244/91 DE LA LEY N 23.798 art. 2 inciso E.
3.3.2 Entregable Acta de Constitucin del Proyecto Consiste en desarrollar un documento que autoriza formalmente un proyecto, y en documentar los requisitos iniciales que satisfacen las necesidades y expectativas de los interesados. Se define el alcance inicial y se comprometen los recursos financieros iniciales. Se identifican los interesados internos y externos que van a interactuar y ejercer alguna influencia sobre el resultado global del proyecto, y se documenta informacin relevante relativa a sus intereses. Este es uno de los procesos de ms importantes de esta fase y ya nos permitir definir una estrategia de gestin de estos interesados, intentando disminuir el impacto negativo que puedan ocasionar en el proyecto. Si an no fue nombrado, se seleccionar el director del proyecto. Este documento establece una relacin de cooperacin entre la organizacin ejecutante y la organizacin solicitante (o cliente, en el caso de proyectos externos). De preferencia se asigna un Director de Proyecto durante la elaboracin del acta de constitucin del proyecto, pero siempre antes de comenzar la planificacin. Se recomienda que el director del proyecto participe en la elaboracin del acta de constitucin del proyecto, ya que sta le otorga la autoridad para asignar los recursos a las actividades del proyecto. Los proyectos son autorizados por alguien externo al proyecto, tal como un patrocinador, una oficina de direccin de proyectos (PMO) o un comit ejecutivo del portafolio. El iniciador del proyecto o el patrocinador debe encontrarse a un nivel apropiado para financiar el proyecto. Cualquiera de ellos elaborar el acta de constitucin del proyecto o delegar esta tarea al director del proyecto (generalmente ocurre lo segundo). El proyecto queda autorizado con la firma del iniciador en el acta. Los proyectos se autorizan en funcin de las necesidades internas de la empresa o de influencias externas. Esto normalmente desencadena la realizacin de un anlisis de necesidades, de un caso de negocio o la descripcin de la situacin que el proyecto
33
abord dar. La ela aboracin de el acta de c constitucin de un proy yecto vincul a el proyec cto en cuest tin con la es strategia y el trabajo en c curso de la organizacin o .
figura 12 mu uestra los factores que iintervienen en e la genera acin del Act ta de Constitucin La f del P Proyecto.
Figura 12. . Factores que intervienen en n la generacin n del Acta de Constitucin C de el Proyecto
jetivos que persigue: Obj Autoriza ar formalmen nte el proyec cto. Nombra ar el Director r de Proyecto o. Describ bir la necesidad de negoc cio y su justif ficacin. A partir de la necesidad de nego ocio, identific car los objetiv vos del proye ecto. Identific car las areas involucrad as y recurso os necesarios s.
ntenido del Acta de Con nstitucin d del Proyecto o: Con Necesid dades del ne egocio y opor rtunidades de negocio qu ue justifiquen n la inversin n. Finalida ad del proyec cto (justificac cin) Presu upuesto resumido. Descrip pcin del prod ducto o serv icio. Objetivo os del proy yecto propia amente dicho en trmin nos de TIE EMPO, COS STE Y CALIDA AD. Director r de proyecto o nombrado. Participacin de reas funcio onales y miembros del equipo / Influencia de d los ados. interesa Cronograma de Hito os resumido y Supuestos s y Restriccio ones.
34
3.3.3 Caso de Es studio: Acta a de Constitu ucin
35
36
BUE ENAS PRCTICAS EN LA DIRECCIN Y GESTIN DE PRO OYECTOS INFORMA ATICOS
37
38
BUE ENAS PRCTICAS EN LA DIRECCIN Y GESTIN DE PRO OYECTOS INFORMA ATICOS
39
40 3.4 Estudio de Viabilidad
Como ya hemos enunciado en los apartados Inicio y definicin del problema, debemos analizar la informacin con la que contamos y determinar cul es el problema, as como detectar la oportunidad. Entonces habiendo pasado por este propsito, nos planteamos determinar hasta qu punto nos resulta interesante este trabajo. Puede que el futuro proyecto no encaje adecuadamente en el tipo de actividad que desempea la empresa, o puede que las condiciones de alcance, plazo o precio del mismo no se adecuen a nosotros. Antes de ponerse a preparar una oferta para el cliente hay que tener en cuenta que Preparar una oferta supone tiempo, esfuerzo y, por tanto: Dinero. Y no estn solo el coste laboral y material de asignar recursos a preparar una oferta. Tambin hay que avaluar el coste de oportunidad de las personas y medios que, de no estar preparando esa oferta, posiblemente estaran trabajando en algn proyecto s remunerado. Por eso hay que considerar, a grosso modo, posibilidades de conseguir el trabajo. 1. Disponemos de los conocimientos necesarios para realizar los trabajos en cuestin y, en caso negativo, podemos obtenerlos a tiempo y a coste razonable? 2. Disponemos de los recursos materiales y humanos necesarios para realizar los trabajos, o podemos adquirirlos o subcontratarlos a un coste razonable? 3. Somos competitivos en el mercado, y podemos ofrecer al menos lo mismo, o ms, que otros posibles ofertantes? 4. Tiene el cliente algn proveedor favorito, candidato principal a adjudicarse el contrato?. En caso afirmativo, tenemos alguna posibilidad de batirle, en precio o condiciones (tcnicas, financieras, temporales, etc.), y que el proyecto siga siendo rentable? 5. El contrato, en el precio y las condiciones previstas, es consistente y econmicamente rentable?, es decir, si en dichas condiciones es posible obtener un beneficio de su realizacin. 6. Concurrir a la oferta y obtener el contrato, qu coste de oportunidad tiene?, puede impedirnos atender a otros clientes o a otros proyectos ms interesantes? si realmente nos interesa y tenemos
Aunque alguna de las preguntas anteriores nos pudiera hacer desistir de ofertar, hay que considerar tambin si: Obtener el contrato dotara a nuestra empresa de una mejora competitiva, en trminos de adquisicin de nuevos conocimientos, nuevas tecnologas, o mejora de la reputacin que luego pueda facilitar acceder a nuevos contratos?
41
La evaluacin de d dicha opo ortunidad se e denomina Estudio de Viabilidad, y es este el e que ne el xito o fracaso de el proyecto; en cierta manera m es un n proceso d e aproximac ciones supon suces sivas, donde e se define el e tipo de tra abajo a realizar, el coste e que supon ndr realizarlo y el tiemp po que se pr recisar para a ello. Y de a ah se extrae e el potencia al precio de v venta y, por tanto, el ma argen comerc cial resultant te.
Importan ncia del Estud dio de Viabilid dad Se parte de supuestos, pronsticos s y estimacio ones, por lo que el grado de preparacin p de e la informaciin y e de la profun ndidad con qu ue se su confiabillidad depende realicen los s estudios.
Si b bien dependi iendo de la metodologa m utilizada, de e las caracte ersticas del proyecto y dems d variab bles, el lect tor puede co onsiderar re ealizar nume erosos estud dios que le significarn o no result tados ms precisos p de esa e evaluaci n exhaustiva de la oport tunidad, para a los fines de e este libro s solo veremos los estudio os de: dad tcnica a, en la q que analiza aremos si estamos lo o suficientem mente 1. Viabilid cualifica ados, desde el punto de vista tcnico o, y que sabe emos cmo realizar las tareas t necesar rias, y como o resolver los s posibles pr roblemas que puedan ap parecer dura ante el trabajo. 2.
Viabilid dad
de gesti in, pregunt ndonos si seremos s capaces de term minar el traba ajo en
el periodo de tiempo o adecuado, , organizando las tareas oportuname ente y gestion nando los recu ursos (human nos y materia ales) de la manera m correcta. 3. Viabilid dad econm mica, establec ciendo si tod do lo anterior r lo realizare mos por un precio adecuado, con que e mrgenes d de ganancia a, cunto cos stara el proy yecto, a cu nto lo emos, y cmo ser el pla an financiero. vendere
os tres estud dios devenga arn en sus respectivos documentos s de oferta t cnica, de gestin Esto y eco onmica, los cuales se desarrollan d e en los siguien ntes apartados. No obsta ante, cabe aclarar a que u una oferta co orrecta, basa ada en un es studio de via abilidad, puede variar mu ucho en alca ance y esfue erzo. Hay ofe ertas que se e transmiten verbalmente, en cuestin de segun ndos o minu utos, y otras pueden llev var meses, in ncluso aos, e involucran n a docenas de personas s y miles de horas abajo con mucha m docum mentacin. Por lo que es importan nte consider rar la decisin de de tra oferta ar o no, ya que detrs de e una oferta h t a realizar, que en n la mayora de los hay mucho trabajo casos s es absorbid do por la empresa que de esarrollara el e producto y no por el clie ente. Si s se decidi of fertar, es imp portante rem marcar que la a correcta rea alizacin de estos estudios es funda amental ya que q nos prov veer de info ormacin vit tal, adems habr que te enta la ener en cue
42
inform macin subje etiva, aspect tos ms sutilles sobre las s relaciones con los acto ores del proyecto, client tes y dems, , y los interes ses de la em mpresa. El e estudio de viabilidad tie ene por objjetivo servir r de herram mienta a niv vel de dire eccin tcni ica de proy yecto para la toma de e decisiones s ejecutivas s en el clim ma en el cu ual el proye ecto se des sarrollar, de manera d de determina ar la conven niencia o no o de presen ntar la oferta y competi ir por el con ntrato. El e estudio de viabilidad lleva a a imaginar r varias situa aciones ("cas sos de utiliza acin"). Cada a caso permite la evaluacin de los riesgos r del p royecto.
Estudi io de Viabilid dad: un tema de d expertos Es rec comendable la a participacin de experto os en el Estudio de e Viabilidad, , donde s su conocimiiento emprico o ser de gra an importanciia en el res sultado final ge enerado por dicho d estudio.
Figura a 13. Procedim miento de prepa aracin de una a oferta
43
3.4.1 Oferta Tcn nica Oferta Tcnica describe el problema a resolver, cmo c pensam mos resolver rlo, qu riesg gos se La O antici ipan, y cmo o se abordar n llegado ell caso. Pod demos estab blecer que una forma de e desarrollar r este docum mento, ms all de que vare consi iderablemente de un pro oyecto a otro o, es comen nzando por una u descripc cin sintetiza ada de nuest tra interpreta acin del pro oblema, una descripcin sucinta de en e qu cons istir el traba ajo; la descr ripcin de la as actividades previstas s. A partir de d la experie encia podem mos decir que es recom mendable pre esentarla gr ficamente y ya que permi ite una visin n rpida y cla ara de todo lo que se re ealizar, de escripcin de e los recur rsos involuc crados en la a ejecucin de los tra abajos (mate eriales, herra amientas y sistemas), s lis star los entre egables, los que pueden n ser documentos, produ uctos y cualq quier otra co osa que se g genere como o resultado de d la realizac cin de una tarea, una b breve resea a de los potenciales rie esgos que estn fuertem mente relacio onados a factores externos que puedan compr rometer el xito. Finalm mente sobre el escenariio mostrar cuales c tisfechos y cules no. requisitos son sat s vale excederse ligeram mente en extensin y det talle que que edarse corto y dar En general ms d tcnica. No o obstante el e exceso ta mbin es malo, m y la sensacin de descuido o incapacidad a cliente con n detalles de muy bajo ni ivel, que lueg go pueden n no correspon nderse puede abrumar al os reales, qu ue surgen du urante la ejec cucin del pr royecto. con lo El p propsito de esta parte de el document to de oferta es e mltiple: Mostrar r al potencial cliente que hemos entendido su problema, sus n necesidades s y sus requisito os especfico os. Anticipa arle una pot tencial soluc cin (sin lleg gar a resolv ver el proble ema, eso se e har durante e el contrato), para mostra arle nuestra capacidad t cnica. Identific car los puntos conflictivos s del trabajo a realizar, y anticipar pos sibles soluciones. ue considera cutar el proy Justifica ar el tiempo y el dinero qu amos necesa ario para ejec yecto.
3.4.1.1 Pasos pa ara alcanzar r una oferta tcnica Con nsiderando la figura 13, en este pun nto nos enco ontraramos elaborando el documen nto de oferta a, habiendo decidido d ofer rtar. La primera apr roximacin a lo que ser r el docum mento de ofe erta tcnica surge a par rtir de jo a realizar r, dicho anli sis es prelim minar. analizar el trabaj
Ed ducir Requisi itos El verbo educir r se define como sacar una cosa de otra y se ha adoptado por la dificu ultad que supone s iden ntificar los requ uisitos de un sistema s de info ormacin.
44
manera ms s habitual de realizar dich ho anlisis es descomponer el proyec cto en activid dades La m indep pendientes, compuestos por tareas y, si es preciso, sub-tareas. Esta a descompo osicin permite: ar detallada y organizad damente el trabajo a re ealizar, defin niendo el alcance 1. Analiza tcnico del proyecto o en base a l a definicin del problema a. s en base a la informacin del proyec cto obtenida. 2. Educir Requisitos preliminares equisitos pr revios y los s resultados a obtene er de cada tarea 3. Formalizar los re endo docume entacin, tare eas interrela acionadas, medios m mater riales, etc.) en e una (incluye Especif ficacin de Requisitos R de e Software pr reliminar. 4. Validar r la Especifi icacin de R Requisitos de d Software preliminar generada con c el cliente. ar un respon nsable a cad da tarea. 5. Asigna
En la figura 14 4 observamo os (marcado o con el circ culo) la relacin entre lla estimaci n de os / costes y el precio o del proyec cto y el doc cumento de oferta tcnic ca que dete ermina gasto claram ance del pro oyecto. mente el alca
Figura a 14. Evaluaci n de Tareas y Paquetes de Trabajo T
a oferta tcnica debe con ntener esta in nformacin como c mnimo o: Una Introduc ccin, donde e se sintetice nuestra com mpresin del problema. El alcan nce del proye ecto, donde d describa en qu consistir r el trabajo. .
45
pcin prelimin nar de los req quisitos func cionales y no o funcionales s del proyecto o, que Descrip definan claramente lo que el sis tema va a re ealizar. Descrip pcin clara de d lo que NO O realizar el sistema, para evitar c confusiones en el futuro. Lista de e entregables s que genera ar esta oferta tcnica. Identific cacin de ries sgos potenc iales, suposi iciones y dep pendencias.
Espe ecificacin de e Requisitos de d Software Es a altamente rec comendable formalizar la a oferta tcnica en un u documento o. La norma a IEEE 8 830 para la especificacin de requisitos s de soft tware, es una herramienta til para esta a formaliz zacin.
3.4.2 Oferta de Gestin G 3.4.2 2.1 Descripci in La Oferta de Gestin G descr ribe la organ nizacin, la metodologa a y los proce edimientos que q se segui irn para lle evar a cabo el proyecto, , indicando claramente c las actividad des a realiza ar, los recur rsos involucr rados y el tie empo que se e estimar para cada actividad. Este e documento o debe incluir la informac cin necesar ria para justif ficar la solve encia organiz zativa y de g gestin de nu uestra uesta. Gener ralmente con ntendr: propu Descrip pcin de paqu uetes de trab bajo, y respo onsable de ca ada uno de e ellos. Lista de e resultados entregables del proyecto o. Planifica acin temporal propuesta a: Gantt y/o PERT. Plan de e reuniones. Equipo de trabajo. Perfil profes sional del pe ersonal con mayor resp ponsabilidad en el proyecto. ncias de la empresa en p proyectos sim milares. Referen
n respecto a los criterios s de valorac cin de las ofertas, o por lo general s suele valorar rse en Con trminos de la so olvencia tcn nica del equip po de trabajo o propuesto, la experienc cia de la em mpresa abajos simila ares y el plaz zo de ejecuciin de los tra abajos, entre otros factore res. en tra
46
3.4.2.2 Pasos preliminares para alcanzar una oferta de gestin Considerando las implicaciones de la oferta de gestin, analizaremos la informacin con la que contamos previamente para generar dicho documento, la cual surge a partir de estimar el esfuerzo requerido, dicha estimacin es preliminar. La estimacin de horas permite conocer cul ser una de las partidas del coste de la realizacin del trabajo ofertado. Permite consolidar la informacin de esfuerzo derivada de la descripcin de tareas a sub-tareas que, junto con los dems gastos de proyecto conforma el coste total del mismo. A la hora de dimensionar el esfuerzo, es conveniente clasificar el mismo segn las distintas categoras profesionales del equipo de trabajo, pues el coste real es muy distinto para cada una de ellas (una hora de secretaria nos cuesta mucho menos que una hora ingeniero senior). Tambin es conveniente valorar el esfuerzo teniendo en cuenta las heterogeneidades del equipo de trabajo (no todas las personas rinden igual), y los posibles problemas que pueden surgir, y que hagan que el coste se incremente. Generalmente se utiliza una planilla tipo matricial la cual permite estimar por separado cada categora y reducir el error global. Adems con ello se facilita simultneamente el control del avance de las diferentes tareas y la deteccin de sobreesfuerzos en cualquiera de las actividades. Este tipo de estimacin permite realizar comprobacin adicional sobre las hiptesis manejadas, que puedan proporcionar una indicacin de que alguno de los pasos realizados no fue correcto. As por ejemplo: El nmero total de horas resultante tiene que ser consistente con el equipo de trabajo previsto y con la duracin del proyecto. Como regla general, el esfuerzo total debe de ser comparable o ligeramente inferior al producto del nmero de horas de trabajo disponibles en el periodo de ejecucin del contrato, multiplicado por el nmero de personas que componen el equipo de trabajo. La distribucin de la carga de trabajo entre categoras tiene que ser consistente con el tipo y alcance del proyecto. En un proyecto de desarrollo de software, la mayor parte puede y debe hacerla personal de categora IJ (ingeniero junior) o inferior. Algo mucho ms complejo y sutil de determinar, es la proporcin de esfuerzo entre tareas o, ms concretamente entre areas funcionales del proyecto. Empricamente podemos entender que un proyecto dedicado a desarrollar un producto concreto, debera tener asignado la mayor parte del esfuerzo a los paquetes de trabajo relacionados al desarrollo del producto en s; una valoracin muy apartada de esto podra indicar una estimacin incorrecta.
47
Una a vez definid das las tareas en la Ofer rta Tcnica, es necesario o realizar los s siguientes pasos para desarrollar una u Oferta de e Gestin: 1. Se estim ma el tiempo o necesario p para realizar r cada tarea. 2. Se clas sifica el equipo de trab bajo (respon nsables asig gnados a ca ada tarea) en e las diferent tes categora as profesiona ales. 3. Se agrupan las tareas (ut tilizando alg gn criterio, pudiendo relacion nadas, o alg n otro). 4. Se gene era una mat triz la cual tie ene dos entr radas, las tar reas y los res sponsables de las mismas s y en cada interseccin asigna el valor estimado o. La matriz g generada describe el tiemp po necesario o (total y pa arcial) en ca ada caso. A continuaci n se muest tra un ejemplo o de dicha matriz. agrupar tareas t
Figura 1 5. Matriz de Es stimacin
5. Se definen las fech has de comie enzo y fin pa ara cada tare ea. e las tareas. 6. Se definen dependencias entre era un docum mento de pla anificacin temporal t (ge eneralmente e grfico, Gantt y/o 7. Se gene PERT). man los rec cursos nece sarios para la realizacin de todas la as tareas. 8. Se estim 9. Se revi isa el proye ecto para lo ograr su opt timizacin ut tilizando tc cnicas aprop piadas (ejemplo: camino cr rtico, distribu ucin equitat tiva de recurs sos, minimiza zar gastos, et tc.)
48
Com mo ya se det tall previam mente, para o obtener el pre ecio del proy yecto, se deb be sumar el coste del p proyecto y el e beneficio proyectado o. Pero a su u vez para obtener el co oste del pro oyecto debemos sumar la carga de e trabajo y el presupuesto de gas stos. En la oferta de gestin ajamos en es stimar dicha carga c de tra abajo. trabaj
Figura a 16. Estimaci n del Esfuerzo o y Carga de Trabajo T
3.4.3 Oferta Econmica in 3.4.3.1 Descripci nmica es uno de los pu untos crtico os del proyecto desde e el lado del cliente. La Oferta Econ Desd de la primera a entrevista, el cliente no os dejar sab ber sus inten nciones sobr re el conocim miento del m monto total del proyecto o. Recin en n esta etapa estaremos s en condic ciones de pr roveer inform macin vlida a y bien fund damentada s sobre el coste e de un prod ducto o servic cio. En este docume ento se pued de saber cu nto costar realizar el proyecto, en c cuanto podramos erlo y cul es la estrate egia financie era para la recuperacin n de la inve ersin, entre otros vende punto os importante es. Hay y que tener en e cuenta qu ue muchas o ofertas se de esechan directamente, siin llegar a mirar m el docum mento tcnico ni de gestin, po orque el pre ecio no se e considera adecuado. Este razon namiento lo puede cons siderar un clliente si no tiene una oferta o tcnica a o de gest tin lo suficientemente convincente c como c para fu undamentar el desembolso econmic co. rticularmente e, los anlis sis de viab bilidad econmica pued den ser de carcter previo, p Par simul ltneo o prolongado. Los s anlisis de carcter previo se limitan n al objeto es sencial de la a toma de de ecisiones con nteniendo un n pronstico de viabilidad d. No obstante, en la may yora de los casos
49
el an nlisis es sim multneo; en l no sl o se realiza a un prons stico, sino q que se realiz za un segui imiento del desarrollo del d proyecto o incluyendo o la propuesta y ejecu ucin de me edidas paliat tivas y correctoras duran nte la ejecuc in del proye ecto. Esta se egunda fase de los anlisis de viabilidad corresp ponde a un nivel n que func ciona de dire eccin ejecutiva. Incluso , en determinados s el anlisis s econmico o alcanza al seguimiento o del proyecto finalizad do, incluyend do los casos gasto os de conser rvacin, y ma antenimiento o. Es de mucha utilidad u hace er un clculo o estimativo de la invers sin y del co oste operativ vo del ecto (en trminos de re ecursos mat teriales y hu umanos), los plazos co onsiderados y las proye event tuales ganan ncias genera adas por la iinversin. Ba asndose en n estos clcu ulos aproxim mados, se pu uede determi inar si se deb be continuar r con el proye ecto.
Consejo e recomendab ble no brindar r informacin sobre el Es altamente pr recio del proy yecto hasta que q no est presentada lla oferta tcnica y de g gestin. Con esta informac cin el cliente e podra tener una noci n ms clara de d la complejid dad del proye ecto y as lograr una mejo or predisposici in para aceptar el precio fin inal.
a Oferta Econmica debe e contener u na estimaci n econmica a que a su v vez contiene: Una El precio de venta del d proyecto b bsico. Precio de d las mejora as adicionale es al proyect to bsico. La form ma de pago, incluyendo: o o o n. Distribucin Medio. Financiacin.
mal es que sea s vlida po or un periodo o dado). Validez de la oferta (lo ms norm n o no de de eterminados impuestos, entre e ellos el l IVA. Inclusi Precio al a que se fa acturarn, los s recursos adicionales a que q el Client te pueda so olicitar, como co omplemento a los neces arios para la a realizacin del proyecto o.
Par ra obtener el precio del proyecto, se e debe sum mar el coste del proyec cto y el ben neficio espe erado. Pero a su vez pa ara obtener el coste de el proyecto debemos su umar la carg ga de traba ajo y el pres supuesto de d gastos. E En la oferta econmica trabajamos en establec cer los montos que configuraran el precio total d del proyecto o.
50
Figura 17. 1 Estimacin n de Gastos y Presupuesto P de e Gastos
3.4.3.2 Pasos pr reliminares para p alcanza ar una ofert ta econmic ca ntro del desa arrollo del do ocumento de oferta econmica se inc cluye la estim macin econmica Den dentr ro de la que e habiendo ya definido la estimaci in del esfu uerzo, podre emos estima ar los coste es. Dicha estimacin es preliminar. Eva aluar el cos ste de ejecu utar un desa arrollo de software s es una tarea compleja. El E alto valor aadido de el proceso, el e carcter intangible del producto, y la dificult tad para ad decuar proce esos inform ticos a nece esidades de usuarios (co on cierta dos sis de subjet tividad en muchos casos s) hacen qu ue la valoracin econm mica en este tipo de proyectos pu ueda resultar r ms comp pleja que en otros entorno os proyectua ales. La e estimacin econmica e in ncluye los co ostes tanto de e materiales y bienes a a adquirir a ter rceros como o por viajes y desplaza amientos, co omidas, gast tos financier ros, uso y m mantenimien nto de orden nadores, etc c. Cada organizacin e estructura de e manera diferente esto os costes, por p lo general por el tipo de proyect tos que realiiza, definiend do con ms nivel de deta alle aquellos s tipos ostes ms sig gnificativos de d sus activid dades. de co 3.4.3.3 Seccione es de la Estim macin Eco onmica A c continuacin desarrollare emos tres de e las partidas que propo one, como cllasificacin de d los difere entes costes, Domingo Aj jenjo en su l ibro Direccin y Gestin n de Proyect tos. Cabe aclarar a que la cuarta par rtida referente a los coste es de person nal perteneci iente a la org ganizacin, ya y fue eada en el apartado a de Oferta O de Ge estin. plante s de persona Subcon ntrataciones s: Son costes al, ajeno a la a empresa pe ero que interviene, bajo nu uestra respo onsabilidad ante el cli iente. Por lo l general se utilizan n dos
51
modalidades de subcontratacin: volumen de trabajo a un precio fijo, o un trabajo concreto a un determinado precio por hora. En cualquier caso, al personal subcontratado no le son aplicables los gastos de la empresa. Costes internos: Costes de consumibles, servicios informticos, etc., que son proporcionales al esfuerzo real que se dedique y al consumo de recursos concretos. Otros costes: En esta partida se incluyen todos los dems costes y gastos que no tienen cabida en los tipos anteriores. Dentro de ella, cada empresa har las clasificaciones que estime oportunas, como por ejemplo: o Material y equipos: Son los elementos fsicos necesarios para completar el proyecto. Pueden ser para uso propio, o suministros que, por lo general, se le entregan al cliente al terminar el proyecto. o Viajes y estancias: Son costes en los que incurre el personal para realizar el trabajo, incluyendo los desplazamientos a la oficina del cliente o a cualquier otro sitio que sea necesario, las dietas correspondientes, etc. o Otros gastos: Se incluyen aqu, por ltimo, los gastos adicionales que no tenan cabida en los apartados anteriores.
El detalle de estos tems representados en la figura 18, se muestra como estimacin econmica de la siguiente manera: 1. Considerando los valores obtenidos (#1), por categoras, en la matriz de estimacin de esfuerzo (que fue mostrada en la figura del apartado anterior de Oferta de Gestin), agregaremos los costes unitarios por categora profesional (#2). Obtendremos el coste de cada categora de manera individual, durante el proyecto. El error de valoracin cometido parcialmente ser siempre menor que el error de una valoracin global. 2. Al agregar los costes parciales de cada categora se obtiene una valoracin global del desarrollo del proyecto (#3). 3. Al punto anterior debe sumrsele costes asociados (#4,#5 y #6) de gestin y direccin, subcontrataciones, materiales y bienes a adquirir a terceros como por viajes y desplazamientos, comidas, gastos financieros, uso y mantenimiento de ordenadores, etc. 4. Al coste del proyecto alcanzado en el punto anterior deberemos sumarle un porcentaje de beneficio esperado (#7), as como aplicarle porcentajes de tasas del mercado (ejemplo.: I.V.A), con lo que obtendremos el precio final del producto (#8).
52
Figura 18 8. Estimacin Econmica E
Gen neralmente se s utilizan plantillas pred definidas pa ara realizar la a carga de e estos valore es, las cuale es realizan es stos clculos s de forma au utomtica.
Consejo C Es E altamente recomendabl le contar con el asesoram miento de pro ofesionales es specializados en el tema, ya y que hay cu uestiones su ubyacentes qu ue no se ver n en profund didad en esta a obra, y co omo dijimos es ste es un punt to crtico para el xito del pr royecto.
3.4.3.4 Entregab ble Documento de la O Oferta Si h hemos llegad do hasta ac , es que he emos decidid do presentar la oferta al Cliente y, de e esta mane era, optar por la adjudicacin del cont trato.
53
El documento de oferta es aquel que se remite al potencial Cliente ofrecindole un bien o servicio a cambio de una contraprestacin econmica. Por lo general, responde a una solicitud del propio Cliente (mediante peticin directa o restringida, etc.), aunque tambin puede ser una oferta no solicitada (si se detecta que el Cliente tiene una necesidad no cubierta, y estamos en condiciones de satisfacerla. En este caso es interesante evaluar la capacidad real de contratacin que tenga el Cliente antes de prepara la oferta). Llegado el momento de compilar el documento de oferta, de lo que se trata es de mostrar al potencial Cliente que somos el equipo ms idneo para realizar el proyecto, es decir: Que estamos suficientemente capacitados, desde el punto de vista tcnico, y que sabemos cmo ejecutar las tareas necesarias, y cmo resolver los posibles problemas que puedan aparecer durante el trabajo. sta es la oferta tcnica. Que seremos capaces de terminar el trabajo en el periodo de tiempo adecuado, organizando las reuniones intermedias oportunas y gestionando los recursos (humanos y materiales) de la manera correcta. sta es la oferta de gestin. Que todo lo haremos por un precio adecuado. sta es la oferta econmica.
El documento de oferta tambin sirve como referencia contractual. Todo lo que se dice en el documento de oferta que se va a hacer, incluido en el precio propuesto, despus hay que hacerlo. Debe adecuarse en estructura a lo solicitado (verbalmente o mediante escrito de peticin de oferta) por el Cliente pero, en general, es de esperar que contenga, al menos: Una introduccin. Los antecedentes y propsito del trabajo ofertado. El alcance prctico del mismo (indicando claramente qu no forma parte del alcance). La oferta tcnica, que mostrar al Cliente la capacidad tcnica del ofertante. La oferta de gestin, incluyendo planificacin temporal de la ejecucin del trabajo, esfuerzo a utilizar y personal clave. La oferta econmica, indicando claramente cul es el precio final para el contratante, los dems gastos que pudieran derivarse, as como el momento y la forma de pago del proyecto.
En cuanto a la extensin del documento de oferta, vara enormemente en funcin del tipo de Cliente, la relacin mantenida con l en el pasado y, sobre todo, el tipo y volumen del contrato.
54
En general, es conveniente no dedicar a la preparacin de la oferta un esfuerzo excesivo (pues significa coste de oportunidad para otros proyectos). Una regla general puede ser no dedicar ms del 5% del volumen del contrato, aunque el carcter estratgico, el inters o las relaciones con el Cliente pueden modificar significativamente el alza dicho umbral.
3.4.4 Caso de Estudio: Estudio de Viabilidad 3.4.4.1 Oferta Tcnica Introduccin y Propsito. El propsito de esta especificacin es definir de forma preliminar todas las funcionalidades, restricciones y caractersticas que se desean implementar para el Sistema de Gestin Bioqumica que se desarrollar para Clinical Lab. Este documento est sujeto a revisiones sucesivas por el grupo de usuarios hasta alcanzar la aprobacin del mismo, con lo que servir de base para la realizacin de las ofertas Tcnicas, de Gestin y Econmica incluidas Estudio de Factibilidad que se lleva a cabo a pedido de Clinical Lab. Alcance. El Sistema se llamar Sistema de Gestin Bioqumica. El mismo permitir administrar los recursos, procesos e informacin que Clinical Lab utiliza para brindar servicios a sus clientes. El Sistema de Gestin Bioqumica permitir administrar la recepcin de muestras biolgicas provenientes de los clientes, a continuacin, ser posible administrar la informacin en los procesos de anlisis e interpretacin. Finalmente, se podr gestionar la validacin de resultados y entrega de los mismos de forma impresa, verbal (solo como excepcin y bajo registro) o digital. En todos los procesos se pondr especial nfasis en el registro de modificacin de la informacin. El objetivo del Sistema es gestionar de forma eficaz y eficiente los recursos e informacin, permitiendo un seguimiento detallado de los procesos a medida que avanzan por las distintas etapas. El Sistema no incluye la entrega de otro producto que no sea el software desarrollado junto a sus manuales correspondientes y el cdigo fuente, tampoco incluye el mantenimiento continuo ni instalacin de algn servicio extra. Se incluir solo la correspondiente Capacitacin en Uso del Sistema. Definiciones, acrnimos y abreviaturas.
55
Trmino SGB CL Usuario Cliente Muestra Prctica Protocolo Procedencia Tarea Significado Sistema de Gestin Bioqumica Clinical Lab Personal de CL que interactuar con el Sistema Persona o Entidad que utiliza los servicios de CL Muestra biolgica utilizada como elemento de estudio en los anlisis clnicos Es la orden de determinacin de los valores de parmetros definidos, utilizando un mtodo especfico, sobre una muestra determinada brindada por el paciente. Conjunto de prcticas en una fecha determinada y para un paciente especfico Lugar de donde proviene una muestra. Utilizada para identificar al laboratorio derivante o centro de dilisis. Actividades a desarrollar por personal del laboratorio de manera tal de realizar una prctica sobre una muestra
Resumen. Este documento posee informacin de requerimientos del SGB, define de forma preliminar funcionalidades, caractersticas principales de usuarios, restricciones, suposiciones,
dependencias y requisitos futuros del sistema que se desea construir. Tambin define todos los requisitos necesarios en esta versin preliminar, categorizndolos por funcionalidad, rendimiento, desarrollo, etc. Este documento est basado segn el Standard de IEEE 830 -1999 para la definicin de requisitos de software. Descripcin General Perspectiva del producto. El Sistema de Gestin Bioqumica no forma parte de ningn sistema mayor, se proyecta que el mismo cubra todas las necesidades internas de Laboratorio Tucumn solicitadas y validadas durante los meses de Abril y Mayo del 2010. Descripcin General Funcionalidad del producto. El Nuevo Sistema de Gestin Bioqumica realizar la administracin de los anlisis clnicos, gestin de usuarios de tipo empleado y clientes (particulares, laboratorios y centros de dilisis), cuenta corriente de clientes, y facturacin, control de stock, registro de novedades y agenda. En lo referente a los anlisis clnicos, el sistema ser capaz de registrar la recepcin de muestras y su transicin a lo largo del procesamiento hasta que los resultados estn disponibles para ser informados a los clientes, mediante un informe impreso o publicndolos en Internet. Para los laboratorios clientes se ofrecer la posibilidad de cargar las prcticas que desean derivar de forma remota (posiblemente mediante internet). Estos anlisis generarn un registro en los movimientos diarios del registro de caja, as como en la cuenta asociada a cada cliente, los cuales el sistema se encargar de registrar. Adems deber contar con un sistema de alertas, en el cual si los resultados de las prcticas evidencian un riesgo en la salud del paciente se comunicar de forma urgente, a quien corresponda dicha informacin, y en lo posible de forma automtica. El sistema deber registrar todas aquellas novedades asociadas a un protocolo o de carcter general.
56
Es necesario que el sistema cuente con manejo de recordatorios, como medio de ayuda en la realizacin de las actividades de los empleados. As mismo el sistema se encargar de gestionar a los tres tipos de clientes: Particulares (con y sin Obra Social), Laboratorios y Centros de Dilisis, manejando no tan solo la informacin filiatoria de cada uno de ellos, sino tambin informacin sobre su cuenta econmica. As los dos tipos de usuarios, empleados y clientes, accedern al sistema utilizando nombre identificatorio y clave. La utilizacin de las distintas funcionalidades podr configurarse segn los permisos que se desee otorgar a cada usuario, tambin ser posible crear perfiles de usuarios. El registro de los movimientos de caja deber incluir la emisin y recepcin de facturas y otros tipos de comprobantes. Del mismo modo, el sistema deber realizar el manejo de listas de precios para cada prctica de acuerdo a la procedencia que la solicite, y administrar los precios que las obras sociales (que tienen convenio con Laboratorio Tucumn) pagan por las prcticas. Otra de las funcionalidades del sistema ser la asignacin de tareas segn distintos criterios, a los tcnicos o bioqumicos, y el seguimiento del estado de las mismas, el control de stock de los insumos y sus consumos, registro bsico de los mdicos que ordenan los anlisis. En la parte de comunicacin con equipos, se deber proveer de los medios (interfaz) para permitir la carga automtica de datos provenientes de los equipos que procesan las muestras, ya sea por conexin directa o indirecta. As los equipos (o sus intermediarios) debern cargar los datos en el sistema, y no que el sistema extraiga los datos de los equipos. En todos los procesos se pondr especial nfasis en la flexibilidad del sistema ante nuevos cambios. Igualmente es importante realizar un control de trazabilidad, por lo que se registrar toda operacin en la que se modifiquen los datos del sistema, como as tambin es importante proveer estadsticas para el Sistema de Gestin de Calidad del Laboratorio Tucumn. Como parte del Sistema, se brindar una capacitacin en el uso del software y se entregar los manuales de usuario correspondientes y cdigo fuente. Caractersticas de los Usuarios.
Tipo de usuario Formacin Actividades Tipo de usuario Formacin Actividades Gerente General Ttulo de grado en Bioqumica. Conocimientos de informtica, administracin de empresas y contabilidad. Validacin de resultados de anlisis. Control General. Gerente de Calidad Conocimientos bsicos de Bioqumica. Conocimientos en Administracin de Empresas y Administracin de Recursos. Control de Calidad de los Procesos y Personal.
57
Tipo de usuario Formacin Actividades Bioqumico Ttulo de grado en Bioqumica. Procesamiento de muestras. Realizacin de anlisis. Interpretacin de resultados
Tipo de usuario Formacin Actividades

Tipo de usuario Formacin Actividades
Tcnico Conocimientos de Bioqumica. Preparacin y procesamiento de muestras.

Secretaria Secundario Completo. Conocimientos bsicos de bioqumica. Recepcin de clientes y muestras. Informacin de anlisis y resultados. Cobros y reintegros de prcticas.
Restricciones. El Sistema no realizar: Liquidacin de sueldos de los empleados. Control de asistencia. Manejo de informacin impositiva de la actividad econmica (clculos de impuestos, I.V.A, ingresos brutos y dems). Llamadas telefnicas ni envo de mensajes de textos, pero si se podr registrar manualmente la realizacin de las mismas.
Otras consideraciones: No poseer la base de datos de clientes de las obras sociales. El control de stock requerir que un empleado registre en el sistema el consumo de un insumo (previamente cargado en el Sistema), con excepcin del control de impresiones. Los equipos de anlisis (o sus intermediarios) debern cargar los datos en el sistema, y no que el sistema extraiga los datos de los equipos. Al importar los datos de una base de datos de un sistema anterior, se solicitar al cliente exportarla en un formato de campos el cual ser especificado debidamente en su momento.
El Sistema no incluye la entrega de otro producto que no sea el software desarrollado junto a sus manuales correspondientes y cdigo fuente, tampoco incluye el mantenimiento continuo ni instalacin de algn servicio extra. La configuracin del
58
softw ware con lo os parmetr ros especfi icos de la actividad a a realizar es star a carg go del cliente. Se incluir solo un curso c de Ca apacitacin en Uso del Sistema.
Sup posiciones y dependencias. El b buen funcionamiento de servicios s dis sponibles a tr ravs de inte ernet estar lligado a la calidad de la conexin en ntregada por el proveedo or de Internet t. En caso que se e considere necesario n qu ue el sistema a enve corre eos electrn nicos, se sup pondr que el proveedor del serv vicio de co orreo electr nico brinda a un servic cio ptimo y sin rupciones. interr trnicos utilizados La integridad de e los datos proveniente de los distin ntos equipam mientos elect el procesami iento y an lisis de mu uestras depe ender en cada c caso d de la interfa az de en e unicacin ent tre el SGB y el equipo o su intermed diario. Alguna as de las inte erfaces exist tentes comu fuero on diseadas s por el fabric cante, otras s se disearon n a medida. Evo olucin prev visible del sistema. En sta versin preliminar r del docum mento no se registran re equisitos futu turos referen ntes a dise o, desarrollo o, metodolog gas, lenguaje es, normas, hardware o software. s Req quisitos com munes de las interfaces s. El S Sistema de Gestin G Bioq qumica inter ractuar con distintos sis stemas media ante interfac ces de comu unicacin que e se especificarn en las s siguientes sub-seccione s es. Inte erfaces de Usuario. U
59
Inte erfaces de hardware. h
Inte erfaces de software. s
Inte erfaces de comunicaci c n.
Req quisitos Fun ncionales.
60
3.4.4.2 Oferta de e Gestin Infr raestructura a Organizativ va. La E Entidad Ejec cutora es una a organizaci n matricial, dedicada a la ejecucin de Proyecto os, por tal m motivo no exi iste una estr ructura fija d del personal, sino por el e contrario lo os grupos se s van confo ormando a medida m que son s necesari os, dependie endo de la envergadura e del proyecto o y los plazo os de ejecuc cin. Aun as, en cada p proyecto se pueden iden ntificar mnim mamente dis stintos grupo os de trabajo o que conform man el equip po del proyec cto.
Figura 19. Grupos G de traba ajo que conforman el equipo del proyecto
Gru upo de Direc ccin y Gestin.

-
1 Direc ctor de Proy yecto: Es el responsable mximo de d la ejecuc cin del proyecto, tendr a su cargo o todas las s cuestiones s globales del d proyecto o, tales com mo la
61
coordinacin de los equipos de desarrollo y la gestin en la obtencin de los recursos necesarios para el proyecto. 1 Lder de Proyecto: es el responsable del equipo de desarrollo, tendr a su cargo la labor de gestin de los recursos y la asignacin de tareas. Es el segundo en la jerarqua de responsabilidad. Manejar la planificacin temporal y econmica del proyecto. Grupo de Desarrollo. 1 Ingeniero Senior: es el profesional que cuenta con los conocimientos y experiencia necesaria para desarrollar todas las actividades en un proyecto. 3 Ingenieros Juniors: son aquellos que siendo profesionales no cuentan con los conocimientos y experiencia necesaria para ser un Senior, pero estn en proceso de aprendizaje. Grupo de Anlisis. 2 Analistas Funcionales: son aquellos que se encargarn de realizar el anlisis de la situacin actual y relevar cules son las necesidades del cliente. Grupo de Calidad. 1 QualityAssurance: es el responsable de realizar las pruebas de calidad en el desarrollo de software, configurando los escenarios de prueba e informando los resultados de dichas pruebas. Otros. 1 Diseador: es el encargado de realizar el diseo grfico de la interfaz del sistema. 1 IT Junior: es el encargado de asesorar de la configuracin de la infraestructura tecnolgica existente y de la futura.
En esta configuracin mnima planificada para este proyecto se estima que se requerir un total de 11 profesionales en los 8 puestos de trabajo.
Proceso Productivo. El proceso de desarrollo del Proyecto comprende las etapas del ciclo de vida de un Proyecto, cumpliendo con las etapas de: Inicio, Planificacin, Ejecucin, Seguimiento y Control, y Cierre, a la cual se le suma una etapa de Capacitacin realizada entre la Ejecucin y Control y el Cierre.
62
Figura 20. C Ciclo de vida del d proyecto
Etapas. Iniciaci n: Desarroll lar el trmino o de abertur ra del proyecto. Desarro ollar la declaracin del alca ance prelimin nar del proye ecto. Planifica acin: Desar rrollar el plan n de administracin del proyecto. Ejecuci n: Orientar y administra ar la ejecuci n del proyec cto. Seguim miento y Control: C Insp peccionar y controlar el Control integrado de e cambios. Capacit tacin: Desarrollar un Cu urso de Capa acitacin de las funcione es del sistem ma que se imple ementaron. Cierre: Finalizar el proyecto. p trabajo o del proy yecto.
Las s etapas que componen al a proyecto s se basan en lo establecid do por el Pro oject Manage ement Institu ute (PMI). Deb bido a que el proyecto o es de gra an envergad dura, se div vidir en fas ses de ejec cucin secue enciales y co on solapamie ento.
63
Figura 21. Fas es de ejecuci n de proyectos s
Fas ses. El P Proyecto se encontrar divido en fa ases, de ma anera tal de realizar los s avances de una mane era organizad da y complet ta. As se en ncontrar divido en 4 Fase: 1. Fase 1: Mdulos de e Usuarios y Seguridad. o D Duracin Apr roximada: 95 5 Das Hbile es.
2. Fase 2: Mdulo de Anlisis A Cln icos. o D Duracin Apr roximada: 17 76 Das Hbiles.
3. Fase 3: Mdulos de e Facturacin n y Control de Stock. o D Duracin Apr roximada: 69 9 Das Hbile es.
4. Fase 4: Mdulo de Funciones F V Varias. o D Duracin Apr roximada: 18 8 Das Hbile es.
Cad da Mdulo ser s entregado al cliente e para que realice r las pruebas p corre respondiente es que asegu uren que el producto p cum mple con tod as sus exige encias.
64
Figur ra 22. Estructu ura de Desglose de Trabajo (p para mejorar la a visualizacin se suprimi la as fases Iniciac cin y Planificac cin de la prese ente figura)
ntt. Gan Las s actividades s descriptas s en la Est tructura de Desglose de d Trabajo son organizadas temporalmente co onsiderando los criterios establecidos s, generalme ente es ilustr rado a partir de un rama de Gan ntt. diagr
conmica 3.4.4.3 Oferta Ec Precio de Venta: o o o Precio Final U$D 115.23 34. VA U$D 95.2 236. Precio sin IV IVA U$D 20 0.000.
Validez z de Oferta: 30 Das Forma de Pago y Financiacin F n: A definir durante d la negociacin.
65
Figura 23. Oferta Eco onmica
3.5 C Contrato Informtic co
Una U vez que e la viabilidad d de nuestro proyecto es st demostra ada, el sig guiente paso o ser crear un contrato o que formal ice el trabajo que va amos a rea lizar. Hay que q recorda ar que no h to sin hay proyect co ontrato. En e este moment to del libro vamos a desa arrollar conc ceptos b sicos de co ontratos info ormticos qu ue un Direc ctor de Proy yectos de ebera conoc cer.
66
3.5.1 Definicin de Contrato o Informtico o contrato infor rmtico es un na contratac in cuyo obje eto son bienes y servicio os informtico os. El c
Bie enes informt ticos: Todos aq quellos eleme entos que en n conjunto co onforman el sopor rte fsico del e elemento infor rmtico (hardw ware). Los biene es inmateriales s que proporc cionan las rde enes, datos, proce edimientos e instrucciones s, y que en conjunto co onforman el sopor rte lgico del e elemento informtico (softw ware).
Se ervicios inform mticos: Todo os aquellos s servicios que sirven de apo oyo y comple emento a la activ vidad informtiica en una rela acin de afinid dad directa co on ella.
s contratos in nformticos estn forma ados por ele ementos disp pares que ex xigen la mez zcla o Los unin n de dos o ms tipo de e contratos para poder configurar sus s caracter sticas, siendo su objeto o mltiple y diversifica ado, pudiend do darse multitud m de figuras que e desequilib braran cualq quier relacin n tipo que se e pueda pens sar. Todo ell lo debido a la pluralidad de las parte es que interv vienen y la a dispersin de interes ses entre ellas, e as como a la particularida ad de deter rminadas clusulas que forman f parte e de este tipo o de contratos. Asim mismo, el de esconocimiento por el u suario, en t rminos gen nerales, de la as posibilida ades y lmite es de la infor rmtica, hace e que no tod o en el contrato pueda estar e basado o en el principio de la aut tonoma de la voluntad de d los contrat tantes. En muchas oca asiones, son n contratos de adhesin n, en los qu ue una de llas partes fi ija las sulas del con ntrato y lo otra o se adhie ere a las mismas, m sin tener t posibillidad de modificar clus ningu una de ellas. . Estos contratos de adh hesin son producto p de la contratac cin en masa a que, frecuentemente, violan v los de erechos de lo os consumido ores de bienes y servicio os informtico os por an desequilib brio que se produce p al fa altar la emisin libre de voluntad v por una de las partes p el gra en la fijacin de la as clusulas del contrato o. cidas contrat taciones llave en mano, sera adecua ada la En algunos casos, como el de las conoc acin de la teora t del resultado en la a contrataci n informtic ca, en un cla aro arrendam miento aplica de ob bra. Ahora bien, b ello imp plica que los s resultados se especifiquen en el co ontrato defin niendo cuale es son, dentr ro de unos lmites razona ables, o dich ho de otra forma, cuando o la funcin bsica b de tra atamiento de e la informacin sea cum plida aunque e se puedan dar algunos s comportamientos de la misma que, sin tener gran g carga s sobre la aplic cacin, no se ean los adec cuados o cu uenten algunos error res o fallos. con a
67
En definitiva, la contratacin informtica en general, adolece de determinadas caractersticas que la hacen extremadamente complicada en la redaccin de los contratos y en la fijacin de los derechos y obligaciones de las partes. A ello hay que aadir a inexistencia de una normativa adecuada a los mismos y la dificultad en la fijacin del objeto cuando son contratos complejos. Es por ello, que se deben redactar teniendo en cuenta un equilibrio de prestaciones y evitar en lo posible la existencia de clusulas oscuras.
3.5.2 Partes de un contrato informtico En la contratacin informtica se ven involucrados varios elementos, a los que podemos denominar complementarios, que se interrelacionan entre s. Existen cuatro partes principales en un contrato informtico: 1. Contratantes. 2. Parte expositiva. 3. Clusulas o pactos. 4. Anexos. A continuacin se detallan estas partes principales de un contrato informtico. 3.5.2.1 Los contratantes Los contratantes son las personas fsicas o jurdicas interesadas en realizar el proyecto. No es lo mismo la contratacin informtica realizada entre profesionales de la informtica, que la contratacin informtica realizada entre un profesional de la informtica y un tercero. Por ello, la identificacin y situacin profesional de los intervinientes reviste gran importancia, debiendo fijar, no solamente quien adquiere cada responsabilidad proveniente de la contratacin y a quien representa, sino tambin qu conocimientos o formacin profesional, o empresarial, relacionada con el tema objeto del contrato, tiene cada uno debido a la obligacin existente, desde la ptica de una buena fe contractual, de informar correctamente a la otra parte y de proporcionar claridad a las clusulas y obligaciones del contrato. La formacin de la voluntad y las responsabilidades de cada una de las partes, tienen una relacin con la identificacin personal y profesional de las mismas, que la convierten en dato de gran importancia en este tipo de contratos. 3.5.2.2 Parta expositiva En esta parte se expone, de forma clara y concreta, el por qu y el para qu del contrato. Es importante sealar que dentro de los contratos informticos es imprescindible fijar de forma sencilla, el por qu se realiza el contrato y cules han sido los condicionantes o circunstancias que han movido a las partes a unirse mediante esta relacin contractual.
68
Para ello, se fijarn los intereses de cada cual, especificando las necesidades de uno y la oferta del otro; dejando bien claro que es lo que ofrece una parte y que es lo que acepta la otra y debiendo existir una coincidencia real sobre el objeto, o concepto que de l y de su utilidad respecto al fin perseguido, tienen cada una de las partes. Por otro lado es de especial inters establecer claramente el negocio jurdico en el cual luego, de acuerdo con la teora general para ese negocio en el ordenamiento, se pueda subsumir el caso e interpretar el contrato. 3.5.2.3 Clusulas o Pactos Partiremos del principio de buena fe y, estableceremos una "obligacin" de colaboracin en ambos sentidos; el suministrador debe colaborar con el usuario y, lo que es igual de importante, el usuario debe colaborar con el suministrador. Es altamente recomendable destacar la participacin activa de ambas partes como requisito fundamental para alcanzar los tiempos estimados. Adems, el usuario debe respetar y seguir las directrices que, respecto al bien contratado y su implementacin en el circuito de informacin, le indique el suministrador y,
consecuentemente, utilizar el equipo informtico o los programas, siguiendo las instrucciones que, para su ptima utilizacin, le seale. El suministrador, por su parte, se exonera de responsabilidad en el caso de que exista una anomala consecuencia del incumplimiento por parte del usuario de estas instrucciones de funcionamiento o manejo. Estas clusulas o pactos han de cumplir los siguientes requisitos, aunque son orientativos: Obligaciones de las partes, claras y concisas. El deber de asesoramiento. El cumplimiento del plazo. La formacin del usuario. Prohibicin de subarrendar. Sustitucin del equipo. Definicin de trminos o conceptos oscuros. El mantenimiento preventivo. Clusulas de garanta.
3.5.2.4 Los Anexos Es fundamental que los contratos informticos vayan acompaados de unos Anexos que incorporados a ellos y con la misma fuerza de obligar, contengan diferentes desarrollos de elementos que forman parte sustancial del contrato.
69
Es altamente recomendable agregar como anexo el Acta de Constitucin del Proyecto y el Plan de Gestin del Proyecto.
3.5.3 Tipos de Contratos Informticos Ante la gran diversidad de contratos informticos que existen en la actualidad, dividiremos su estudio en dos grupos diferenciados. El primero, respecto al objeto, debido a las caractersticas especiales de los distintos objetos sobre los que pueden versar estos contratos -ya sea hardware, software, servicios de mantenimiento y formacin, o llave en mano- que llevan a la necesidad de su estudio y tratamiento individualizado. El segundo, respecto al negocio jurdico, debido a que los contratos informticos, ms comnmente realizados, se han llevado a cabo bajo el paraguas protector de una determinada figura jurdica en la que han encontrado acomodo; pero casi todos los casos, ha sido necesario adecuar el objeto del contrato al negocio jurdico realizado. 3.5.3.1 Por el Objeto Por el objeto del contrato distinguiremos contratos de hardware, contratos de software, contratos de instalacin llave en mano y contratos de servicios auxiliares. 1. Contratos de Hardware. En los que hay que conceptuar como hardware todo aquello que, fsicamente, forme parte del equipo, considerando como tal, tambin, a los equipos de comunicaciones u otros elementos auxiliares para el funcionamiento del sistema que se va a implementar. 2. Contratos de Software. Hay que diferenciar en el momento de analizar una contratacin de software, si se trata de un software de base o de sistema, o se trata de un software de utilidad, o de aplicacin o usuario, ya que este ltimo, debe responder a unas necesidades particulares, las del propio usuario, el que encarga la aplicacin, y que, por tanto, tendrn que quedar claramente especificadas en el contrato; sin embargo, el software de base o sistema y el software de utilidad responden a unas caractersticas generales que son las del propio sistema o las de la utilidad a la que sirven y es un producto ya conformado de antemano que no se somete a peticiones o particularidades del usuario. 3. Contratos de instalacin llave en mano. En los que irn incluidos tanto el hardware como el software, as como determinados servicios de mantenimiento y de formacin del usuario. 4. Contratos de servicios auxiliares. Como pueden ser, el mantenimiento de equipos y programas o la formacin de las personas que van a utilizar la aplicacin respecto a equipos, sistemas o aplicaciones. 3.5.3.2 Por el Negocio Jurdico
70
De acuerdo con el negocio jurdico del contrato, existirn tantos tipos de contratos como negocios jurdicos se realicen sobre este objeto. As, algunos de los ms utilizados en el campo de la informtica son los llamados de venta, de arrendamiento financiero, de alquiler, de opcin de compra, de mantenimiento, de prestacin de servicios, de arrendamiento de obra, de prstamo, o de depsito. 1. De venta. Cuando sea un contrato en el que el suministrador, o vendedor en este caso, se obliga a entregar una cosa determinada, un bien informtico, y la otra parte, comprador, a pagar por l a un precio cierto (art. 1445 CC). La venta tambin puede ser de servicios. 2. De arrendamiento financiero. Mediante el que se requiera que participen tres partes, el suministrador, vendedor del equipo informtico, una entidad o intermediario financiero que compra el bien, para un tercero que es el usuario, y el usuario del bien que lo poseer, pero lo tendr en rgimen de arrendamiento financiero hasta que haya cumplido con unas determinadas caractersticas o requisitos. 3. De alquiler. El arrendamiento sobre bienes informticos es un arrendamiento tipo de los regulados en el Cdigo Civil, art. 1543 y ss., caracterizado porque el suministrador se obliga a dar al usuario el goce o uso de un bien informtico durante un tiempo determinado y por un precio cierto. 4. De opcin de compra. Aunque la opcin de compra no est definida en nuestro ordenamiento y solamente se recoge para bienes inmuebles en la legislacin hipotecaria (art.14), nuestra doctrina y jurisprudencia la tienen bien delimitada exigiendo que para que exista este tipo de contrato, tienen que darse tres requisitos principales: Respecto al optante, que le debe conceder la decisin unilateral de la realizacin de la opcin de compra. Precio de compraventa, que debe quedar perfectamente sealado para el caso de que el optante decida acceder a dicha compraventa. Plazo del ejercicio de la opcin de compra, Debe quedar determinado con claridad en el acuerdo de las partes. 5. De mantenimiento. Puede ser tanto de equipos como de programas, o incluso, mantenimiento integral en el que se puede incluir un servicio de formacin, asesoramiento y consulta. 6. De prestacin de servicios. En los que incluiramos anlisis, especificaciones, horas mquina, tiempo compartido, programas, etc., que los podramos clasificar como unos contratos de arrendamientos de servicios. El arrendamiento de servicios se da cuando una parte se obliga con la otra a prestarle unos determinados servicios, con independencia del resultado que se obtenga mediante la prestacin.
71
7. De ejecucin de obra, consistente en el compromiso de una de las partes, en nuestro caso el suministrador del bien o servicio informtico, a ejecutar una obra, y de la otra parte realizar una contraprestacin en pago por la obra llevada a cabo. 8. De prstamo, caracterizado porque una parte entrega a otra el bien informtico para que use de l durante un tiempo determinado y lo devuelva una vez cumplido ese tiempo y de Comodato, consistente en un tipo de contrato de prstamo en el que el suministrador transfiere el uso del bien informtico prestado. El Cdigo Civil (art. 1740), se refiere al comodato como un contrato de prstamo, en el que una de las partes entrega a la otra alguna cosa no fungible para que use de ella por cierto tiempo y se la devuelva, indicando que es esencialmente gratuito. En el caso de que se acuerde entre las partes una retribucin, deja de ser comodato para pasar a ser un arrendamiento de cosas. 9. De depsito, que se constituye de acuerdo con lo establecido en el Cdigo Civil (art. 1758), desde que una persona recibe una cosa ajena con la obligacin de guardarla y restituirla, siendo un contrato gratuito, salvo pacto contrario (art.1760), pero que en el caso de cumplirse los requisitos establecidos en el Cdigo de Comercio (art.303), se trata de un deposito mercantil, en el que el depositario tendr derecho a exigir retribucin por el depsito, salvo pacto contrario (art.304), con las obligaciones para el depositario de conservacin de la cosa, en este caso, del bien informtico, de acuerdo con lo establecido en los arts.306 y concordantes del mismo cuerpo legal.
CAP TULO IV. FASE E PROD DUCTIVA VA
N Nadar siempr re es fcil cu uando uno es st fuera del agua. (PhD D Ing. Alexan nder Prieto Le en)
4.1 D Descripci n de la Fase Produ uctiva

Esta a es la Fase de desarroll lo del trabajo o en s. Esta fase se divid de en cuatro o etapas las cuales c deben ser ejecuta adas segn el modelo e legido que puede p ir desd de un modello en cascad da (no frecuente en n la actualida ad) hasta un n modelo iter rativo e incre emental, inclu uso un mode elo de muy f metodologa gil como puede e ser Scrum. . Estas etapa as son Anlisis, Diseo, Implementacin y bas. Todas estas e etapas son desarro olladas en las s siguientes secciones de ulo. Prueb e este captu
Scrum Scrum es una met todologa par ra la gestin n y desarrollo o de softwar re basada en e un proce eso iterativo e incrementa al utilizado comnmente c en entornos b basados en el l desarrollo g gil de software e.
rante la ejec cucin del proyecto, p se debe poner r nfasis en la comunic cacin para tomar Dur decis siones lo m s rpido po osible en ca aso de que surjan prob blemas. Ade ems, se de ebern organ nizar regular rmente (una vez por sem mana preferentemente) reuniones p para administrar el gularmente el progreso del proyecto equip po del proyecto, es decir r, discutir reg o y determin nar las prioridades para las siguien ntes semana as. Existen diferentes formatos f pa ara represen ntar el rte semanal. . En la figura siguiente se muestra a un ejemplo del forma ato de un re eporte repor sema anal.
73
Figura 24. F ormato de reporte semanal
En e esta fase se ejecutarn aquellos a proc cesos neces sarios para co ompletar el t trabajo definido en el pla an para la dir reccin del proyecto p a fin n de cumplir r con las esp pecificaciones o. Este s del mismo grupo o de proces so implica coordinar pe rsonas y re ecursos, as como integ grar y realizar las actividades del pr royecto de co onformidad c con el plan para p la direcc cin del proye ecto. rante la ejec cucin del proyecto, p los s resultados (desempeo o hasta el m momento) pu ueden Dur reque erir que se actualice a la planificacin n y que se vuelvan a definir las fec chas claves. Esto puede incluir cam mbios en la duracin d prev vista de las actividades, a cambios en la disponibilidad y uctividad de recursos, as s como en los riesgos no anticipados. Tales va ariaciones pu ueden produ afecta ar el plan pa ara la direccin del proye ecto o los do ocumentos de el proyecto, y pueden re equerir un an nlisis detallado y el des sarrollo de re espuestas de direccin de proyectos s apropiadas s. Los result tados del an nlisis pueden generar la a solicitud de e cambios qu ue, en caso d de ser aprob bados, podr an modificar r el plan para a la direccin n del proyecto u otros doc cumentos de el proyecto.
Dirigir r y Gestionar la Ejecucin del Proyecto o Es el p proceso que co onsiste en eje ecutar el traba ajo definido en el plan pa ara la direccin del proyectto, mplir con los objetivos del mismo. para cum
74
Las s actividades que abarcan n la Direcci n y Gestin de la Ejecuc cin del proy yecto son: Realizar las activida rias para cum ades necesar mplir con los requisitos d del proyecto. Crear lo os entregable es del proyec cto. Reunir, capacitar y dirigir d a los m miembros de el equipo asig gnado al proy yecto. Obtener, gestionar r y utilizar los recurso os, incluyend do materiale es, herramie entas, equipos s e instalacio ones. Implementar los m todos y norm mas planifica ados. Establecer y gestio onar los can nales de co omunicacin del proyect to, tanto ext ternos como in nternos al equipo del proy yecto. Generar la informac cin relevan te del proye ecto, tal com mo coste, cro onograma, avance tcnico y de calidad d y el estado, , a fin de facilitar las proy yecciones. Emitir la as solicitude es de cambio o y adaptar los cambios s aprobados s al alcance, a los planes y al entorno del proyecto o. Gestion nar los riesgo os e impleme entar las activ vidades de respuesta r a llos mismos. Recopilar y docum mentar las le ecciones ap prendidas e implementa ar las activid dades das de mejor ra del proces so. aprobad
El d director del proyecto p dirige el desem mpeo de las s actividades s planificada as del proyec cto. El proce eso Dirigir y Gestionar la a Ejecucin d del Proyecto o se ve direc ctamente afe ectado por el e rea de aplicacin de el mismo. Lo os entregab bles se pro oducen com mo salidas d de los proc cesos utados para cumplir con el trabajo planificado o y programa ado. ejecu En las prximas s secciones se detallar n todas las etapas y actividades inc cluidas en la a Fase de Ejecucin.
Expe eriencia Proy yectos
en n
la
Direc ccin
de
onocimiento emprico e es un n elemento El co muy importante para la dir reccin de proye yectos efectiva a.
75 4.2 Anlisis: Ingeniera de Requisitos
4.2.1
Descripcin
Aqu comienza el desarrollo propiamente dicho. En esta primera etapa se realiza un anlisis profundo del sistema para determinar claramente QU es lo que va a hacer el sistema. La Fase de Anlisis consiste en el estudio del sistema de informacin, en el contexto en que se encuentra en ese momento, y la definicin de las necesidades que poseen los usuarios, y que debern ser satisfechas por medio del software a desarrollar. Se debern buscar las respuestas para preguntas tales como: Qu es lo que debe hacer el sistema? Qu es lo que debe hacer el software a desarrollar? En qu condiciones debe funcionar? Qu limitaciones tendr? Cmo se implantar? Qu recursos materiales, temporales y humanos hacen falta para ello? Cmo se verificar que el sistema funciona correctamente?
Ingeniera de requisitos comprende todas las tareas relacionadas con la determinacin de las necesidades o de las condiciones a satisfacer para un software nuevo o modificado. Su principal propsito es hacer que los requisitos mismos alcancen un estado ptimo antes de llegar a la fase de diseo en el proyecto. Los requisitos deben ser medibles, comprobables, sin ambigedades o contradicciones, etc. El sentido comn dice que no puedo disear si no conozco claramente QU va a hacer el sistema. Desde un punto de vista conceptual, las actividades en la etapa de anlisis son cinco: 1. Extraccin/Educcin de requisitos: consiste en hallar e identificar los requisitos que debe satisfacer un determinado sistema de informacin. Esto se realiza por medio de entrevistas o comunicacin con clientes o usuarios, para saber cules son sus deseos. El verbo educir se define como sacar una cosa de otra y se ha adoptado por la dificultad que supone identificar los requisitos de un sistema de informacin. Aunque aparentemente dichos requisitos vienen dados por el cliente, la realidad es que la mayora de ellos deben ser investigados por el analista. 2. Analizar requisitos: detectar y corregir las falencias comunicativas, transformando los requisitos obtenidos de entrevistas y cuestionarios, en condiciones apropiadas para ser tratados por el diseo.
76
3. Docum mentar requi isitos: igua l que todas s las etapas s, los requis sitos deben estar debidam mente docum mentados. 4. Verifica ar los requi isitos: cons siste en com mprobar el co orrecto func ionamiento de un requisito o en la aplica acin. 5. Validar r los requ uisitos: co omprobar que los requisitos im mplementado os se
corresponden con lo o que inicialm mente se pre etenda.
Un analista de sistemas es e aquel indiividuo responsable de in nvestigar, pla anear, coord dinar y mendar opcio ones de soft tware y siste emas para cu umplir los requerimientos s de una em mpresa recom de ne egocios. Jue ega un rol vital v en el pr roceso de de esarrollo de los sistema as. Un analis sta de sistem mas exitoso debe adquir rir cuatro hab bilidades: an naltica, tcni ica, gerencia al, e interper rsonal. Las h habilidades analticas a pe ermiten al an nalista de sistemas ente ender a la o organizacin y sus funcio ones, las cuales le ayudan a identific dades, analizar y resolve er problemas s. Las car oportunid habili idades tcnic cas ayudan al analista d de sistemas a entender el potencial y las limitac ciones de la as tecnologa as de la informacin. El analista de sistemas de ebe ser capa az de trabaja ar con s lenguajes s de progr ramacin, s sistemas op perativos, y plataforma as hardwar re de varios comp putadoras. Las L habilidad des gerenci ales ayudan n al analista a de sistem mas a admin nistrar proye ectos, recurs sos, riesgos, y cambio. L Las habilidad des interpers sonales ayud dan al analis sta de sistem mas a trabaj jar con los usuarios fina ales as com mo con analistas, progra amadores, y otros profe esionales de los sistemas s.
Analista Funcio onal El an nlisis de un n sistema info formtico debe ser realiza ado por una perso ona con exp periencia y capacidad de anlisis y e educcin de requi isitos. Para este rol se requiere de habilidades y aptitudes omprender e inferir los req especiales para co quisitos del siistema. Este rol es s comnmente e conocido co omo Analista Funcional. F
Es muy comn encontrar ta ambin el tr rmino Analist ta Orgnico, que se difer rencia del An nalista Funcional. El ana alista se encarga del est tudio de los requisitos, objetivos y fu unciones a re ealizar por e do todos es el sistema, documentan d stos aspecto os segn la metodolog a establecid da. El Analista Funciona al es el que se encarga d de la fase de e anlisis pro opiamente d dicha, y el An nalista carga de la a fase de d diseo, por lo que en algunos m edios se emplea Orgnico se enc lemente el t rmino Diseador para esta categor ra. simpl
Analista Orgnic co El ana alista orgnico o est ms ce erca del desar rrollo, del dise eo. Su labor es dis sear lo definid ido por el ana alista funcional l. Documenta su trabajo y el res sultado de s su trabajo es s lo que em mplean direct ctamente los progra amadores.
77
4.2.2 Tcnicas principales para la Educcin de Requisitos
La Educcin de requisitos puede ser un proceso largo y arduo para el que se requiere de habilidades y aptitudes especiales para poder obtener los requisitos. Los nuevos sistemas cambian el entorno y las relaciones entre la gente, as que es importante identificar a todas las personas implicadas, considerar sus necesidades y asegurar que entienden las implicaciones de los nuevos sistemas. Los analistas pueden emplear varias tcnicas para obtener los requisitos del cliente.
Tcnicas de Educcin
Descripcin
Entrevistas
Las entrevistas son un mtodo comn. Por lo general no se entrevista a toda la gente que se relacionar con el sistema, sino a una seleccin de personas que represente a todos los sectores crticos de la organizacin, con el nfasis puesto en los sectores ms afectados o que harn un uso ms frecuente del nuevo sistema. Los requisitos que surgen de las entrevistas a menudo se contradicen unos a otros o se formulan desde la ignorancia de los detalles del funcionamiento del sistema, sus potencialidades, interdependencias o limitaciones; por lo que se debe trabajar con los mismos para corregir sus fallos. Las entrevistas pueden ser personales o grupales. Tambin puede ser abiertas o cerradas. Esta tcnica consiste en elaborar un conjunto de preguntas para obtener informacin sobre un determinado tema. Las preguntas podrn ser abiertas o cerradas. Es importante determinar claramente las personas que deberan responder al cuestionario, estas deberan ser una muestra representativa del todo. Esta tcnica consiste en estudiar los documentos existentes tales como formularios, archivos de auditora (logs) y la documentacin del sistema informtico. Toda documentacin sobre la cual podran surgir requisitos, deber ser cuidadosamente estudiada por los analistas. Esta tcnica consiste en juntar a un grupo de personas idneas sobre un determinado tema, crear un ambiente de estimulacin y provocar que las ideas fluyan. Es importante no criticar las ideas cuando se aplica esta tcnica. En primera instancia se documentan todas las ideas, luego se las analiza y finalmente se documentan las ideas que tengan buen fundamento para ser consideradas. Esta tarea consiste en la observacin de las tareas que realiza el usuario, estos no son siempre conscientes de las tareas que realizan y como las realizan. Esta tcnica consume tiempo, pero puede ser muy til cuando se quiere discernir sobre la complejidad de la tarea en un rea. El observador acta pasivamente sin tener intervencin en el sistema. Es una variante de la entrevista y la Observacin. Se le pide a un usuario que muestre como realiza una tarea especfica. El Observador puede consultar lo que crea conveniente durante la demostracin, es decir que tiene una aptitud activa con respecto al sistema. Esta tcnica consiste en desarrollar una versin simple de una parte del sistema. El usuario validar los requisitos por medio de interaccin con el prototipo. Es importante que el usuario sepa que el prototipo no es el producto final, sino slo la representacin de una parte del mismo. El prototipo podr ser: Incremental: que luego podr mejorarse hasta convertirse en la solucin final. Desechable: que ser parte de la solucin final, solo una herramienta para validar requisitos
Figura 25. Tcnicas de educcin
Cuestionarios
Estudio de Documentacin
Lluvia de Ideas
Observacin
Demostraci n de tareas
Prototipos
78
Educcion de Req quisitos fiere a la capt tura y descubr rimiento de los requisitos. E Es una tarea Se ref ms humana h que t cnica, en la que q se identif fica a los inter resados y se estable ecen las pr rimeras relac ciones entre ellos y el equipo de desarr rolladores.
ando sea ne ecesario, el analista a emp plear una combinacin c de las tcn nicas de Edu uccin Cua para establecer lo os requisitos s exactos de las personas implicadas s, para produ ucir as un sis stema resuelva las necesidades s del negocio o. que r
Pre eguntas Abie ertas y Cerrad das Una pregunta ab bierta es una a pregunta que q admite un nmero ilimitado de res spuestas. Por r ejemplo: Cmo cree usted que debe era funcionar el sistema? Una pregunta c cerrada es una pregunta que admite un nmero tado de resp puestas. Por ejemplo: C Cuntas opcio ones deben limit estar r disponibles e en el submen Ayuda?
4.2.3
Especific cacin de re equisitos de el software o ERS
a especificac cin de requ uisitos softwa are es una descripcin d completa de el comportam miento Una del s sistema a desarrollar. In ncluye un c conjunto de casos de uso u que des scriben toda as las intera acciones que se prev que los us suarios tend drn con el software. T Tambin contiene requisitos no funcionales (o suplementar rios). Los requisitos no funcionales f uisitos son los requ stricciones al a diseo o funcionamie ento del sist tema (tal co omo requisitos de que imponen res onamiento, estndares e de d calidad, o requisitos de el diseo). funcio
Fo ormalizar los R Requisitos en n la IEEE-830 0 Las s estrategias s recomendadas para la especificaci in de los requ uisitos del soft ftware estn descritas d por el IEEE 830-1998. Este estn ndar describe e las estructu uras posibles, , contenido d deseable, y calid dades de una e especificacin n de requisitos s del software..
ncipalmente, los requisito os se dividen n en: Prin Funcionales: son lo os que el us suario necesita que efect te el softwa are. Ej: el sis stema autorizado para realizar ventas. deber validar si el usuario est No func cionales: es specifican cu uan bien un n sistema de ebe realizar sus funcione es: Ej: el siste ema deber imprimir 20 r registros por segundo.
79
a mala Espe ecificacin de e Requisitos provoca: Una Que el sistema s no satisfaga s a lo os usuarios. Desacu uerdo entre usuarios u y de esarrolladores. Puede ser s imposible e demostrar r si el software cumple o no los requ isitos. Esto puede p traer co onsecuencias s legales. Gastos innecesarios s en tiempo y dinero en construir c un software s no idneo.
anlisis es un na tarea crtica dentro de el desarrollo de software e, no existe o otra tarea qu ue con El a mayo or capacidad de afectar al a sistema cu uando se hac ce mal. Es cr rtico encontr rar aqu lo er rrores, ya qu ue si no son n encontrado os en esta fa ase, se pude e propagar por p todo el c ciclo de desa arrollo aume entando los costes para reparar. C Cuanto ms s tarde se descubren llos errores en la Espe ecificacin de e requisitos, ms m crecen los costes de e forma expo onencial.
Figura 26. Coste e por encontrar r un error en ERS
4.2.4
Identifica acin de las s personas i involucrada as
bido a que lo os cambios que q introduce e un sistema a nuevo tiend den a afectar r a ms de un u tipo Deb de us suario, los analistas a de requisitos ha an de tomar r en consideracin a tod dos los implicados para que se obte engan y dep puren sus re equisitos de e la forma ms m exacta p posible. Entre los cados hay qu ue considera ar: implic
80
Organizaciones que integran la organizacin del analista que est diseando el sistema.
Organizaciones o sistemas de respaldo. Direccin. Usuarios.
4.2.5 4.2.5.1
Problemas para obtener los requisitos Relacionados con las personas involucradas
Estos son algunos de los tpicos problemas que podrn dificultar la determinacin de los requisitos: Los usuarios no tienen claro lo que desean. Los usuarios no se involucran en la elaboracin de requisitos escritos. La comunicacin con los usuarios es lenta. Los usuarios no participan en revisiones o son incapaces de hacerlo. Los usuarios no comprenden los problemas tcnicos. Los usuarios no entienden el proceso del desarrollo. Los usuarios insisten en nuevos requisitos despus de que el coste y la programacin se hayan fijado. Esto puede conducir a la situacin donde las exigencias del consumidor cambian, incluso cuando el desarrollo del producto ya est en marcha. 4.2.5.2 Relacionados con los analistas
La correcta redaccin de las Especificaciones de requisitos Software es imprescindible para el correcto desarrollo del proyecto. Por ello, en su redaccin hay que evitar: Uso de terminologa ambigua en la redaccin de los documentos de requisitos. Sobre especificacin de los requisitos. Escritura poco legible, voz pasiva, abuso de negaciones. Uso de verbos en condicional, expresiones subjetivas. Ausencia de trminos y verbos del dominio de la aplicacin. Que el personal tcnico y los usuarios finales puedan tener diversos vocabularios y puedan llegar a creer incorrectamente que estn de acuerdo, no dndose cuenta del desacuerdo hasta que se provee el producto final.
81
4.2.5.3 Relacionados con los desarrolladores
Los problemas posibles causados por los desarrolladores durante el anlisis de requisitos son: Los desarrolladores pueden intentar encajar el sistema en un modelo existente, en vez de desarrollar un sistema adaptado a las necesidades del cliente. El anlisis de requisitos se puede realizar a menudo por los ingenieros o programadores, en vez de personal con las habilidades de relacin con la gente y el conocimiento apropiados para entender las necesidades de un cliente correctamente.
4.2.6 4.2.6.1
Entregable Especificacin de Requisitos de Software Introduccin
Se presenta el formato de Especificacin de Requisitos Software segn la versin de 1998 del estndar IEEE 830. En la IEEE se indica que un buen documento de requisitos debe contemplar toda la informacin presentada en el estndar y, aunque propone una organizacin de dicha informacin, no exige estrictamente este formado. Como resultado de esta fase se debe producir un documento de especificacin de requisitos en el que se describa lo que el futuro sistema debe hacer. Por tanto, no se trata simplemente de una actividad de anlisis, sino tambin de sntesis. Asimismo, se define requisito como una condicin o capacidad que necesita el usuario para resolver un problema o conseguir un objetivo determinado. Esta definicin se extiende y se aplica a las condiciones que debe cumplir o poseer un sistema o uno de sus componentes para satisfacer un contrato, una norma o una especificacin. En la determinacin de los requisitos no slo deben actuar los analistas, es muy importante la participacin de los propios usuarios, porque son stos los que mejor conocen el sistema que se va a automatizar. As pues, el documento de especificacin de requisitos debe ser legible por el cliente, con lo que se evita el malentendido de determinadas situaciones, ya que el cliente participa activamente de la extraccin de dichos requisitos. Basndose en estos requisitos, el ingeniero de software proceder al modelado de la futura aplicacin. 4.2.6.2 Objetivos de la ERS
Los principales objetivos que se identifican en la especificacin de requisitos software son: Ayudar a los clientes a describir claramente lo que se desea obtener mediante un determinado software: El cliente debe participar activamente en la especificacin de requisitos, ya que ste tiene una visin mucho ms detallada de los procesos que se llevan a cabo. Asimismo, el cliente se siente partcipe del propio desarrollo. Ayudar a los desarrolladores a entender qu quiere exactamente el cliente: En muchas ocasiones el cliente no sabe exactamente qu es lo que quiere. La ERS
82
permite al cliente definir todos los requisitos que desea y al mismo tiempo los desarrolladores tienen una base fija en la que trabajar. Si no se realiza una buena especificacin de requisitos, los costes de desarrollo pueden incrementarse considerablemente, ya que se deben hacer cambios durante la creacin de la aplicacin. Servir de base para desarrollos de estndares de ERS particulares para cada organizacin: o Cada entidad puede desarrollar sus propios estndares para definir sus necesidades. Una buena especificacin de requisitos software ofrece una serie de ventajas entre las que destacan el contrato entre cliente y desarrolladores (como ya se ha indicado con anterioridad), la reduccin del esfuerzo en el desarrollo, una buena base para la estimacin de costes y planificacin, un punto de referencia para procesos de verificacin y validacin, y una base para la identificacin de posibles mejoras en los procesos analizados. o La ERS es una descripcin que debe decir ciertas cosas y al mismo tiempo debe decirlas de una determinada manera. Una ERS forma parte de la documentacin asociada al software que se est desarrollando, por tanto debe definir correctamente todos los requerimientos, pero no ms de los necesarios. Esta documentacin no debera describir ningn detalle de diseo, modo de implementacin o gestin del proyecto, ya que los requisitos se deben describir de forma que el usuario pueda entenderlos. Al mismo tiempo, se da una mayor flexibilidad a los desarrolladores para la implementacin. As pues, el grado y el lenguaje utilizado para la documentacin de los requisitos estarn en funcin del nivel que el usuario tenga para entender dichas especificaciones. 4.2.6.3 Caractersticas de una buena ERS
Las caractersticas deseables para una buena especificacin de requisitos software que se indican en el IEEE son las siguientes: Correcta. o La ERS es correcta si y slo si todo requisito que figura en ella refleja alguna necesidad real. La correccin de la ERS implica que el sistema implementado ser el sistema deseado. No ambigua. o Un documento es no ambiguo si y solo si cada requisito descrito tiene una nica interpretacin. Cada caracterstica del producto final debe ser descrita utilizando un trmino nico y, en caso de que se utilicen trminos similares en
83
distintos contextos, se deben indicar claramente las diferencias entre ellos. Incluso se puede incluir un glosario en el que indicar cada significado especficamente. Los analistas deben poner un cuidado especial a la hora de especificar los requisitos. El hecho de utilizar el lenguaje natural para hacer la ERS comprensible a los usuarios supone un riesgo muy elevado, porque el lenguaje natural puede llegar a ser muy ambiguo. Completa. o Debe incluir todos los requisitos significativos del software (relacionados con la funcionalidad, ejecucin, diseo, atributos de calidad o interfaces externas). o Debe existir una definicin de respuestas a todas las posibles entradas, tanto vlidas como invlidas, en todas las posibles situaciones. o Debe cumplir con el estndar utilizado. Si hay alguna parte del estndar que no se utiliza, se debe razonar suficientemente el porqu no se ha utilizado dicho apartado. o Deben aparecer etiquetadas todas las figuras, tablas, diagramas, etc, as como definidos todos los trminos y unidades de medida empleados. La ERS debe ser siempre completa, aunque en ocasiones esto no ser posible. Por ejemplo si todava no se han determinado los formatos de los informes finales o por cualquier razn se est esperando la publicacin de un reglamento sobre impuestos. Verificable. o Un requisito se dice que es verificable si existe algn proceso no excesivamente costoso por el cual una persona o una mquina pueda chequear que el software satisface dicho requerimiento. o Ejemplos:
No verificables
El producto debera funcionar bien. El producto debera tener una buena interfaz de usuario. La salida se suministra dentro de los 20 segundos siguientes al evento E el 60% de las veces, y en los 30 segundos siguientes en el 100%.
Figura 27. Ejemplo de atributos Verificables/No verificables
Verificable
Consistente. o Es consistente si y solo s ningn conjunto de requisitos descritos en ella son contradictorios o entran en conflicto. Se pueden dar tres casos:
84
1. Requisitos que describen el mismo objeto real utilizando distintos trminos. 2. Las caractersticas especificadas de objetos reales. Ejemplo: Un requisito establece que todas las luces son verdes y otro que son azules. 3. Conflicto lgico o temporal entre dos acciones determinadas. Se llega a un punto en el que dos acciones seran perfectamente vlidas. Ejemplo: sumar o multiplicar? Clasificada. o Los requisitos deben estar clasificados en la ERS. No todos los requisitos son igual de importantes. Los requisitos pueden clasificarse por diversos criterios: o Importancia: Pueden ser esenciales, condicionales u opcionales. Estabilidad: Cambios que pueden afectar al requisito.
Lo ideal es el establecimiento de prioridades, de modo que la implementacin de un requisito de menor prioridad no emplee excesivos recursos.
Modificable. o El documento debe permitir que cualquier cambio pueda realizarse de manera fcil, completa y consistente. Para ello, es deseable tener una organizacin coherente y fcil de usar en la que aparezca el ndice o una tabla de contenidos fcilmente accesible. Tambin es deseable evitar la redundancia, es decir que no aparezca un mismo requisito en ms de un lugar de la ERS. No es un error, pero si se tiene que modificar alguna cosa ser mucho ms cmodo si no tenemos que buscar el mismo requisito en varios lugares.
Explorable (trazabilidad). o El documento debe permitir determinar el origen de cada requisito de manera clara tanto hacia atrs (origen que puede ser un documento, una persona etc.) como hacia delante (componentes del sistema que realizan dicho requisito). Cuando un requisito de la ERS representa un desglose o una derivacin de otro requisito, se debe facilitar tanto las referencias hacia atrs como hacia adelante en el ciclo de vida. Las referencias hacia adelante de la ERS son especialmente importantes para el mantenimiento del software. Cuando el cdigo y los documentos son modificados, es esencial poder comparar el conjunto total de requisitos que puedan verse afectados por estas modificaciones.
Utilizable.
85
o En la ERS S tambin se deben tener en cuenta las necesidade es de mantenimie ento. El per rsonal que no ha inte ervenido dire rectamente en el desarrollo debe d ser ca paz de enca argarse de su mantenim miento. As, dicha ERS acta a a modo de plano de la aplicacin, per ncluso rmitiendo in modificacion nes que no requieran un u cambio en n el diseo. En ocasion nes, el equipo de desarrollo s supone unos s conocimien ntos que el personal que se d mantenim miento no tiene t por qu u tener. Po or esta raz n es encargue del necesaria una u correcta a documenta acin de las s funciones, ya que si no se conoce en detalle d su oriigen, difcilm mente podrn ser modifica adas. 4.2.6 6.4 Esqu uema de la ERS E definida da en el IEEE E 830-1998
figura 28 muestra la estru uctura de la ERS propue esta por el IE EEE en su es stndar 830 [IEEE, [ La f 1998]:
Figura 28. E Estructura de ERS E IEEE 830
86
Pro ofundizar en la IEEE-830 Es altamente r recomendable e profundizar r en cada u uno de los apar rtados que se definen en el l estndar est tudiado. Para lo cual una lectu ura detallada de las esp pecificaciones de los req quisitos del softw ware que se e encuentran descritas por p IEEE 83 30-1998 es mene ester.
4.2.7
Conclusin del Anlisis
La Etapa de Anlisis es s una etapa a muy imp portante en el proyect to. Es altam mente mendable tr rabajar con Analistas Funcionales s experimen ntados que permitan definir d recom claram mente QUE E es lo que el sistema d debera hace er. Todo esto o debe estar plasmado en e una Espe ecificacin de e Requisitos de Software e. Es muy im mportante ut tilizar un doc cumento est tndar L IEEE 830 es una muy buena opci n. para registrar los requisitos. La El a anlisis y la especificaci e n de los requ uisitos puede e parecer un na tarea relat tivamente se encilla, pero, en realidad, el contenido del anlisi s es muy de enso y abund dan las mala as interpretac ciones alta de inform macin. Es muy m difcil ev vitar la ambig gedad. o la fa Fina almente el equipo e desar rrollador deb ber entregar la Especificacin de R Requisitos co omo el entre egable principal de esta etapa. Esta a ser la entrada princip pal para que e los disea adores ar a trabajar en e la Etapa d de Diseo. puedan comenza documento de d especifica acin de requ uisitos softwa are supone una especie e de contrato o entre El d client te y desarrolladores en el que unos s indican sus s necesidade es, mientras s que los otr ros se limita an a impleme entar lo que se indica e en el docume ento. Princip palmente por r esta razn n tiene tanta importancia a la fase de anlisis a de re equisitos. Po or tanto, de la l calidad de el documen nto de ucto final. La L existencia a de un est ndar, ERS depender el desarrollo y calida d del produ como o la ERS (IEE EE 830) permite la cohe erencia en la especificacin de requis sitos y ayuda a a no dejar r cabos suelto os.
87
4.2.8 4.2.8.1 Caso de Estudio: An nlisis uisito n33: ABMC A de Pr Protocolos Requ
4.2.8.2
Caso o de Uso: Re egistrar Nue evo Protoco olo a Cliente e
88
tradas: Ent DNI o apellido a y nom mbre del pac ciente. Cdigos s de Prctica as. Cdigo de Autorizac cin de Obra a Social y C digo de Obra Social. Cdigo de muestras s. Observa acin.
Pro ocesos: Validar los datos ing gresados. Calcular el precio to otal del Proto ocolo. Generar el nmero identificador r del Protocolo. Imprimir cdigo de barras del n nmero de protocolo p para rotular a los tubos co on las muestra as biolgicas s. Generar el nmero identificador r de cada Pr ctica de un Protocolo. Asociar r cada Prctic ca de un Pro otocolo con dicho d Protoco olo. Generar el nmero identificador r de cada Mu uestra de un Protocolo. Asociar r cada Muest tra de un Pro otocolo con dicho d Protoco olo.
89
Calcular Fecha y Hora. Asociar el Protocolo al Cliente. Verificar que las muestras requeridas para realizar las prcticas han sido recepcionadas. Almacenar los datos. Asignar Estado Inicial del Flujo de Estados a Protocolo, Prcticas de Protocolo y Muestras de Protocolo.
Salidas: Nmero de Protocolo. Fecha de Recepcin. Hora de Recepcin. Nmero de cada Prctica del Protocolo. Nmero de cada Muestra del Protocolo. Fecha Estimada de Finalizacin.
4.3 Diseo
4.3.1
Descripcin
Es el proceso de aplicar ciertas tcnicas y principios con el propsito de definir un dispositivo, un proceso o un sistema, con suficientes detalles como para permitir su interpretacin, a fin de proporcionar una completa descripcin de cmo se realizar el software. En el anlisis nos centrbamos en qu se tiene que hacer, mientras que en el diseo nos centramos en cmo se tiene que realizar. Por lo tanto, en esta etapa se ver cmo almacenar los datos, cmo se van a implementar los procesos y cmo se van a disear las interfaces; todas estas cuestiones definidas en el anlisis. El Diseo del Software es un proceso y un modelado a la vez. Es un conjunto de pasos repetitivos que permiten al diseador describir todos los aspectos del Sistema a construir. A lo largo del diseo se evala la calidad del desarrollo del proyecto con un conjunto de revisiones tcnicas: El diseo debe implementar todos los requisitos explcitos contenidos en el modelo de anlisis y debe acumular todos los requisitos implcitos que desea el cliente. Debe ser una gua que puedan leer y entender los que construyan, prueben y mantengan el Software.
90
El Diseo debe proporcionar un na completa idea de lo que q es el Sof ftware, enfoc cando minios de da atos, funcion nal y compo ortamiento desde el pun nto de vista de la los dom Implementacin.
Par ra evaluar la calidad en el e diseo, se deben estab blecer criterio os tcnicos c como son: Debe presentar p una a organizaci n jerrquica que haga un uso intelligente del control c entre los componen ntes del softw ware. Debe ser s modular, es decir, s se debe hac cer una part ticin lgica a del Softwa are en element tos que realicen funcione es y subfunc ciones especficas. Debe co ontener abst tracciones de e datos y pro ocedimientos s. Debe producir mdulos m qu ue presente en caractersticas de e funcionam miento
ndiente. indepen Debe co onducir a int terfaces que e reduzcan la a complejidad de las con nexiones ent tre los mdulos y el entorno exterior. Debe producir p un diseo usa ando un mtodo m que pudiera re epetirse segn la informacin obtenida durante el anlisis de requisitos r de e Software.
Calida ad de diseo El proc ceso de Dise o del Softwa are exige bue na calidad, es recomendable realizarlo o a travs de la n de principio os fundamentales de Dise o, aplicaci Metodolo oga sistemti ica y una revis sin exhaustiv va.
fase de dise eo comienza a con la apro obacin form mal de los re equisitos del sistema por r parte La f del us suario o cliente. Tiene por objeto def finir la estruc ctura del soft tware a desa arrollar a par rtir del mode elo establec cido en la fase de an nlisis. Lo que q se obtiene asigna ando funcion nes a comp ponentes de e software, y definiend do los flujos s de datos y de con ntrol entre dichas d comp ponentes. Co omo resultado de esta fas se se obtiene e el documento de dise o. Enc cierra las sigu uientes etapas: El diseo de los datos. d Trasfo orma el mod delo de dominio de la inf formacin, creado c e el anlisis, en las es structuras de e datos nec cesarios par ra implemen ntar el durante Softwar re. El Dise eo Arquite ectnico. D efine la rela acin entre cada uno d de los elem mentos estructu urales del pro ograma.
91
eo de la In nterfaz. Desc cribe como se comunica a el Software re consigo mismo, m El Dise con los sistemas qu ue operan co n l y con los operadores s y usuarios que lo emplean.
fase de dise A co ontinuacin se detallan algunos a aspe ectos de inte ers aplicables a la sub-f eo de alto n nivel: e el diseo de la arq uitectura se e adoptar y comenzar r a utilizar una 1. Durante metodologa de dise eo de softw ware concreta a y reconocid da. enor comple uitectura del software se e descompon ndr en unid dades de me ejidad. 2. La arqu Preferentemente se s implemen ntar una metodologa a tipo top-d down, de diseo d dente. descend 3. Para ca ada elemento o o compone ente del softw ware se indic carn y desc cribirn, al menos, m los dato os de entrada a, las funcion nes que dese empea y los s datos de sa alida. 4. Se estim marn duran nte esta sub -fase los req quisitos com mputacionales s (CPU, mem moria, disco, etc.) e para el entorno e de d esarrollo y el e entorno operativo. 5. El resultado de esta sub-fase ser revisa ado formalme ente durante e una reuni n de revisin n. 6. El resul ltado de esta a sub-fase s se plasmar en el docum mento de dis seo de alto nivel, que con ntendr, al menos, m los p principales componentes c s del softwar re y las interfaces entre ellos. spondencia entre ocumento in ncluir una tabla donde e se muest tre la corres 7. Este do requisito os de softwa are y elemen tos del dise o de alto niv vel.
Metodologa M de Diseo de e Sistemas Es altamente recomendabl le utilizar una metodologa concreta y reconocida p para el dise o del sistema de informa acin, as co omo para la as dems fa ases del des sarrollo del software. MTRICA versiin 3 puede ser s utilizada libremente con n la nica restriccin de ciitar la fuente de d su propieda ad intelectual.
4.3.2
Fallos en n el Diseo de d Sistemas s
diseo real de d un sistem ma falla al no o captar los requerimien ntos esencialles del cliente. La El d inform macin pued de no ser pro oporcionada lo suficientemente rpida para ser til, tambin puede p venir en un forma ato imposible e de digerir y usar, o pued de represent tar los eleme entos equivocados atos. Un sist tema puede ser diseado o con una in nterface pobr re. Un sistem ma de inform macin de da ser j juzgado com mo un fracaso si su dise o no es com mpatible con la estructur ra, cultura y metas de la institucin cliente. c
92
4.3.3 4.3.3.1
Entregable Fase de Diseo Introduccin
El Lenguaje Unificado de Modelado (LUM o UML, por sus siglas en ingls, Unified Modeling Language) es el lenguaje de modelado de sistemas de software ms conocido y utilizado en la actualidad; est respaldado por el OMG (Object Management Group). Es un lenguaje grfico para visualizar, especificar, construir y documentar un sistema. UML ofrece un estndar para describir un "plano" del sistema (modelo), incluyendo aspectos conceptuales tales como procesos de negocio y funciones del sistema, y aspectos concretos como expresiones de lenguajes de programacin, esquemas de bases de datos y componentes reutilizables. Es importante resaltar que UML es un "lenguaje de modelado" para especificar o para describir mtodos o procesos. Se utiliza para definir un sistema, para detallar los artefactos en el sistema y para documentar y construir. En otras palabras, es el lenguaje en el que est descrito el modelo. Se puede aplicar en el desarrollo de software entregando gran variedad de formas para dar soporte a una metodologa de desarrollo de software (tal como el Proceso Unificado Racional o RUP), pero no especifica en s mismo qu metodologa o proceso usar. UML no puede compararse con la programacin estructurada, pues UML significa Lenguaje Unificado de Modelado, no es programacin, solo se diagrama la realidad de una utilizacin en un requerimiento. Mientras que, programacin estructurada, es una forma de programar como lo es la orientacin a objetos, sin embargo, la programacin orientada a objetos viene siendo un complemento perfecto de UML, pero no por eso se toma UML slo para lenguajes orientados a objetos. 4.3.3.2 Relaciones de los artefactos del Diseo con los del Anlisis
El trmino Artefacto, en conexin con el desarrollo de software, est mayormente asociado a mtodos o procesos de desarrollo especficos, como el Proceso Unificado. Un artefacto es un producto tangible resultante del proceso de desarrollo de software. Algunos artefactos como los casos de uso, diagrama de clases u otros modelos UML ayudan a la descripcin de la funcin, la arquitectura o el diseo del software. Otros se enfocan en el proceso de desarrollo en s mismo, como planes de proyecto, casos de negocios o enfoque de riesgos. El cdigo fuente compilado para el testeo se suele considerar un artefacto, ya que el ejecutable es necesario para el plan de testeo. En ocasiones un artefacto puede referirse a un producto terminado, como el cdigo o el ejecutable, pero ms habitualmente se refiere a la documentacin generada a lo largo del desarrollo del producto en lugar del producto en s. Los artefactos pueden variar en su necesidad de mantenimiento y actualizacin.
93
Figu ura 29. Fases d de ciclo de des sarrollo de software
mo podemos s observar en e la figura 2 29, UML y Patrones P presenta las dif ferentes fase es del Com ciclo de vida de e desarrollo iterativo de e software a partir de artefactos interrelacion nados. cularmente en e las fases s de Anlisis s y Diseo existen e cues stiones vincu uladas, si bie en los Partic Caso os Esenciales s de Uso so on desarrolla ados en la fa ase de Anlis sis, este enf foque propon ne los Caso os Reales de Uso en la fa ase de Dise o, esto muestra la intima a interrelaci n entre fases. Presenta numer rosos artefac ctos, pero si nos imagina amos UML co omo una caja a de herramientas con s su martillo, destornillado d or, alicates, e etc., siguiend do con la an naloga, si va vamos a colg gar un cuadr ro no usaremos todas las herramie entas de nuestra caja, posiblemente p e slo usem mos el martillo para cla avar el clav vo. Lo mism mo pasa co on UML, una vez que conozcamo os las amientas usa aremos en ca ada momento o las ms ad decuadas a nuestras n nec cesidades. De esta herra mane era podemos s indicar que e los artefact tos ms utiliz zados en la fase de An lisis, sin que e esto signif fique la exce epcin de los s dems, son n los Casos de Uso y en n la de Dise o El Diagram ma de Clase es, que para a los fines de d este libro o se conside erar como el entregablle necesario o para contin nuar con la fase f de Imple ementacin. 4.3.3.3 De la a ERS al Dia agrama de C Clases
sta el momento hemos s definido u un entregab ble en la fa ase de An lisis denom minado Has Espe ecificacin de e Requisitos s de Softwar re (ERS) a travs t del estndar IEE E 830, que como s en su estru uctura, los diferentes usu uarios se def finen en el apartado 2.3 C cas de vimos Caracterstic
94
Usuarios, y seguidamente identifica requisitos en la forma El sistema deber en el apartado 3 Requisitos Especficos. Si consideramos por otro lado el UML podemos notar que realiza a travs de Casos de Uso una especificacin de requisitos funcionales de software muy similar al del estndar IEEE 830, o que en esencia cumple con identificar, validar y documentar los requisitos de software. Seala el uso de dos elementos: el actor (usuario) y el caso de uso (requisito). El actor representa una entidad externa que interacta con el sistema. Las entidades externas podrn ser personas u otros sistemas, mientras que el caso de uso hace referencia al/los requisito/s del sistema a construir, detallando su comportamiento, el cual se traduce en resultados que pueden ser observados por el actor. Los casos de uso describen las cosas que los actores quieren que el sistema haga El sistema deber, por lo que un caso de uso debera ser una tarea completa desde la perspectiva del actor. Los resultados de la especificacin de requisitos son dos productos: el catalogo de requisitos y el documento de especificacin de requisitos de software. El primero de ellos contiene la lista de requisitos de software clasificada por tipo y prioridad; y el segundo de ellos, especifica el comportamiento del sistema a un grado de detalle mayor.
La figura 30 muestra la relacin existente entre la Especificacin de Requisitos de Software (ERS) segn IEEE 830 y UML.
ERS IEEE 830
UML
Nmero de requisito Requisito
1. El Sistema deber administrar Consultas de Bibliografa. Cada Consulta deber tener relacionada uno o ms Libros. Un mismo Libro puede ser utilizado para varias Consultas. Baja/ Opcional
Descripcin
Prioridad del Alta/Esen Media/Des requisito cial eado
Nombre Consultar Bibligrafa Autor Joaquin Garca Fecha xx/xx/xxxx Descripcin: Permite consultar Bibliografa en la Biblioteca Actores: Usuario logueado Precondiciones: El usuario debe haberse logueado en el sistema Flujo normal: El actor pulsa el botn consultar bibliografa El sistema muestra una caja de texto para introducir el titulo de la obra y otra zona de mayor tamao para introducir una descripcin breve. El actor introduce el titulo de la obra y una descripcin breve. El sistema comprueba la validez de los datos y muestra la obra. Flujo alternativo: El sistema comprueba la validez de los datos, si los datos no son correctos, se avisa al actor de ello permitindole que los corrija. Poscondiciones: La consulta a sido almacenad en el sistema.
Figura 30. Comparativo ERS IEEE 830 y UML
95
De esta manera y salvando las distancias de ambos enfoques podemos encontrar relaciones muy fuertes que le permiten al Director de Proyecto contar con informacin suficiente como para ingresar a la Fase de Diseo con elementos suficientes como para generar el Diagrama de Clases (entregable). En este libro se mostr como entregable de la fase de Anlisis a la ERS IEEE 830, porque su formato con una pequea labor de sntesis es ideal para acompaar al contrato, adems de ser un estndar internacional reconocido que da prestigio a nuestro equipo de trabajo a la hora de negociar con el Cliente.
4.3.3.4
Diagrama de Clases
Si bien siguiendo UML y Patrones podemos decir que una vez en la Fase de Diseo definiremos los Casos Reales de Uso, prepararemos los Diagramas de Colaboracin (Diagramas de Comunicacin en otras versiones), asignaremos responsabilidades GRASP y estableceremos la Visibilidad entre Objetos para recin crear el Diagrama de Clases, para los fines de este libro, es ste ltimo el documento principal que servir de entregable para la fase de Implementacin, sin dejar de lado que pueda complementarse con los dems. Clases Representa un conjunto de entidades que tienen en comn propiedades, operaciones, relaciones y semntica. Una clase es un constructor que define la estructura y comportamiento de una coleccin de objetos denominados instancias de la clase. En UML la clase est representada por un rectngulo con tres divisiones internas, son los elementos fundamentales del diagrama: Nombre: Identifica a la clase. Atributo: Representa una propiedad de una entidad. Cada atributo de un objeto tiene un valor que pertenece a un dominio de valores determinado. o Sintaxis del atributo es: Visibilidad <nombre>: tipo = valor {propiedades}. Donde visibilidad es +pblico, #protegido o privado. Mtodos: El conjunto de operaciones que describen el comportamiento de los objetos de una clase. o Sintaxis de una operacin es: Visibilidad nombre (lista de parmetros): tipo que retorna {propiedades}.
96
Figura a 31. Ejemplo de Clase
Car ractersticas s: El lenguaje utilizad do para esp ecificar las clases es el e mismo qu ue el lengua aje de macin (UML L). program Visibilid dad de atributos y operac ciones de la clase. c Las clas ses se mape ean directam ente en el le enguaje de programacin n. Las relaciones en ntre clases tienen un significado directo en el lenguaj je de macin. Por ejemplo, e la g generalizaci n se implem menta como un mecanism mo de program Herenci ia. Los mt todos de una a clase de diiseo son los s mtodos de e una clase iimplementad da. Las clases que pro ovean interfa aces pueden n implementa arse directam mente en alg gunos lenguaje es de programacin. P Por ejemplo, una clase e de diseo o en Java puede p impleme entar una int terfaz. Una cla ase de diseo puede ser r activa, en el e sentido de e que los objjetos instanc ciados pueden mantener su s propio hillo de ejecuc cin (thread) ) concurrente emente con otros objetos.
4.3.3.5
s de Clases s del Diseo Crear Diagramas
ra elaborar un u diagrama de clases s del diseo o, aplique la siguiente e estrategia co on su Par equip po: que todas la as clases qu ue participan en la solucin de so oftware. Par ra ello 1. Identifiq analice los diagrama as de interac ccin. as en un diag grama de cla ases. 2. Dibjela 3. Dupliqu ue los atrib butos prove nientes de los conceptos asocia ados del modelo m concept tual.
97
4. Agregue e los nombre es de los m todos analiz zando los diagramas de in nteraccin. 5. Incorpore la informa acin sobre lo os tipos a los s atributos y a los mtod dos. e las asociac ciones neces sarias para dar d soporte a la visibilidad 6. Agregue d requerida de los atributos. e flechas de e navegabilid dad a las as sociaciones para p indicar la direccin de la 7. Agregue visibilida ad de los atr ributos. 8. Agregue e las lneas s de relacio ones de dep pendencia para p indicar la visibilida ad no relacion nada con los atributos.
Figur ra 32. Ejemplo de Diagrama de d Clases del Diseo D
4.3.4
Resumen n
e documento o generado ser el entr regable para a la fase de implementa acin, se pre esent ste ac p por considera arse el ms relevante, p ero generalm mente se encuentra acom mpaado de el Plan de Pr ruebas de Programas P en ntre otros qu ue permitirn n al equipo de d la siguien nte fase com menzar con s su trabajo. Asimismo A cabe aclarar q que al tratars se de un pro oceso de des sarrollo itera ativo e increm mental pres senta como ventaja la posibilidad de introducir los resulta ados de un n ciclo anter rior al iniciar el siguiente.
98
Figura 33. Modelo M iterativo o e incrementa al de desarrollo o de sistemas
4.3.5
Conclusin de la Fa ase de Dise o
Ante e debe condu ucir un estud dio de es de comenzar con el desarrollo de e cualquier proyecto, se Sistemas para de etectar todos s los detalles s de la situac cin actual de d la empres sa. La inform macin e estudio sirve como b base para crear c varias estrategias s de Diseo o. Los reunida con este admin nistradores deciden ento onces qu e estrategias seguir. s Los Gerentes, e empleados y otros usuar rios finales que q se familia arizan con ell uso del sist tema tienen un papel mu uy importante e en el desar rrollo de siste emas.
99
4.3.6 6.1 4.3.6 Caso de Estudio: Diseo Caso o de Uso Real: Registra ar Nuevo Pro otocolo
100
BU UENAS PRCTICAS S EN LA DIRECCIN N Y GESTIN DE PR ROYECTOS INFORM MATICOS
4.3.6 6.2
Diagr rama de Sec cuencia
Figura 34. Diagrama de d Secuencia p para el caso de e estudio que se s viene desarr rollando
101
4.3.6 6.3
Diagr rama de Comunicacin n
Contina C en 2
Contina en 1
Figura 35. Diagrama de c comunicacin para el caso de e estudio (I)
102
Continua acin 1
Figura 36. Diagrama D de c comunicacin para p el caso de e estudio (II)
103
Continua n2 cin
Figura 37. Diagrama D de co omunicacin para p el caso de e estudio (III)
104
4.3.6 6.4
Diagr rama de Cla ases
Contina en 1
Figura 38. Diagrama d de Clases para a el caso de estudio (I)
105
Contina a en 2
Continu uacin 1
Figura 39. Diagrama d de Clases para a el caso de est tudio (II)
106
Contina en 4
Continu uacin 2
Co ontina en e 3
Figura 40. 4 Diagrama d de Clases para el caso de est tudio (III)
107
Continua n3 cin
Continua cin 4
Figura 41. 4 Diagrama d de Clases para el caso de estudio (IV)
108
Continua cin 4
Continu ua cin 4
Figura 42. 4 Diagrama d de Clases para a el caso de est tudio (V)
109 4.4 Implementacin

4.4.1 Descripcin
En este proceso se genera el cdigo de los componentes del Sistema de Informacin, se desarrollan todos los procedimientos de operacin y seguridad, y se elaboran los manuales de usuario final y de explotacin con el objetivo de asegurar el correcto funcionamiento del sistema para su posterior implantacin. Para conseguir dicho objetivo, se realizan las pruebas unitarias, las pruebas de integracin de los subsistemas y componentes y las pruebas del sistema, de acuerdo al plan de pruebas establecido. Esto se encuentra desarrollado en la seccin 4.5 Pruebas. As mismo, se define la formacin del usuario final y, si es necesario, se construyen los procedimientos de migracin y carga inicial de datos. En las tareas desarrolladas en esta fase se asegura la disponibilidad de la infraestructura necesaria para la generacin del cdigo de los componentes y procedimientos del sistema de informacin. Una vez configurado el entorno de construccin, se realiza la codificacin y las pruebas de los distintos componentes que conforman el sistema de informacin, en las actividades: Generacin del Cdigo de los Componentes y Procedimientos, que se hace segn las especificaciones de construccin del sistema de informacin, y conforme al plan de integracin del sistema de informacin. Ejecucin de las Pruebas Unitarias, dnde se llevan a cabo las verificaciones definidas en el plan de pruebas para cada uno de los componentes.
Una
vez
construido
el
sistema
de
informacin
realizadas
las
verificaciones
correspondientes, se lleva a cabo la integracin final del sistema de informacin, comprobando tanto las interfaces entre subsistemas y sistemas externos como los requisitos, de acuerdo a las verificaciones establecidas en el plan de pruebas para el nivel de pruebas del sistema. En esta fase tambin se genera la documentacin del usuario final. Se trata de la formacin necesaria para que los usuarios finales sean capaces de utilizar el sistema de forma satisfactoria; se especifica en la actividad Definicin de la Formacin de Usuarios Finales. Si se ha establecido la necesidad de realizar una migracin de datos, la construccin y pruebas de los componentes y procedimientos relativos a dicha migracin y a la carga inicial de datos se realiza en la actividad Construccin de los Componentes y Procedimientos de Migracin y Carga Inicial de Datos. La codificacin debe hacerse ateniendo a estndares de codificacin ya creados. Programar bajo estndares mantiene el cdigo consistente y facilita su comprensin y escalabilidad, as como su posible reutilizacin.
110
4.4.2
Preparacin del entorno de generacin y construccin
El objetivo de esta actividad es asegurar la disponibilidad de todos los medios y facilidades para que se pueda llevar a cabo la construccin del sistema de informacin. Entre estos medios, cabe destacar la preparacin de los puestos de trabajo, equipos fsicos y lgicos, gestores de bases de datos, bibliotecas de programas, herramientas de generacin de cdigo, bases de datos o ficheros de prueba, entre otros. Las caractersticas del entorno de construccin y sus requisitos de operacin y seguridad, as como las especificaciones de construccin de la estructura fsica de datos, se establecen en la actividad Generacin de Especificaciones de Construccin, y constituyen el punto de partida para la realizacin de esta actividad. 4.4.2.1 Implantacin de la Base de Datos Fsica o Ficheros
La implementacin de la base de datos fsica, es una tarea muy importante en esta fase. Estas son las actividades a desarrollar: Crear los elementos del sistema gestor de base de datos o sistema de ficheros. Reservar el espacio de almacenamiento, definiendo, entre otros, los dispositivos fsicos a emplear, tamao de los bloques, tipo de registro fsico, zona de desbordamiento, opciones de almacenamiento de datos, etc. Inicializar la base de datos o ficheros, cargando los datos considerados necesarios en el espacio de almacenamiento previamente definido. 4.4.2.2 Preparacin del Entorno de Construccin
En esta tarea se prepara el entorno en el que se construirn los componentes del sistema de informacin, contemplando aspectos tales como: Bibliotecas o libreras a utilizar. Herramientas: generadores de cdigo, editores, compiladores, verificadores
sintcticos, montadores de enlace. Puestos de trabajo. Implementacin de los procedimientos de operacin y seguridad propios del entorno de construccin, de acuerdo a los requisitos de seguridad y operacin establecidos.
4.4.3
Generacin del cdigo de los componentes y procedimientos
El objetivo de esta actividad es la codificacin de los componentes del sistema de informacin, a partir de las especificaciones de construccin obtenidas en la fase de Diseo,
111
as co omo la cons struccin de los procedim mientos de operacin y seguridad s es stablecidos para p el mism mo.
Generacin G del pro ocedimientos s cdig go de los s compone entes y
En E paralelo a esta activid dad, se desa arrollan las a actividades rela acionadas con n las pruebas unitarias y de integracin d del sistema de informacin. Esto permite una construc ccin incremen ental, en el so de que as se haya espe ecificado en el plan de prueb bas y en el cas plan de integraciin del sistema de informac cin.
4.4.3.1
Gene eracin del Cdigo de l los Compon nentes
En esta tarea se genera el e cdigo co orrespondien nte a cada uno de los componente es del ma de inform macin. Para a generar el cdigo fuen nte se tienen en cuenta llos estndar res de sistem nome enclatura, co odificacin y calidad utiliz zados por la a organizaci n y recogid dos en el cat tlogo de no ormas. Con n el fin de verificar que el cdigo fu uente especif fica de forma correcta e el componen nte, se realiz za su ensam mblaje o com mpilacin, v verificando y corrigiendo o los errores s sintcticos s, y el enlac ce del cdigo o objeto obtenido con las correspondi ientes bibliot tecas.
Codificacin C En E este paso s se traduce el algoritmo ya estructurado, verificado y comprobado c a mano, al len nguaje de pro ogramacin qu ue vaya a util lizarse. Slo se convierte en las accio ones del algo oritmo en ins strucciones de e computadora ra usando la sintaxis s de un n lenguaje par rticular, pero r requiere de co onocimientos del lenguaje y de sumo cui idado en la c colocacin de e las instrucc ciones, las q que deben ape egarse y se eguir fielment te a la lgic ca del algoriitmo y la semntica a y sintaxis de el lenguaje.
Compilacin C Compilacin C o correccin de e los errores sintcticos s y se emnticos del cdigo, es la a eliminacin de los errore es "gramaticale les" segn las s reglas de co onstruccin de e instrucciones s particulares del propio len nguaje (la sin taxis). Puede hacerse a medida m que se e traduce, pero es mejor r al final par ra no perder la secuenc cia de la dificacin. All terminar de ebe tenerse el e cdigo libr re de los cod errores an ntes menciona ados.
ra realizar la a compilacin n puede hac cerse uso de e un compila ador, el cua al es un prog grama Par espec cial que an naliza todo el cdigo fuente y detecta d los errores ant tes mencionados ocasi ionados dura ante la codif ficacin o la digitacin. Los L fallos de e lgica que puedan exis stir en nuest tro programa a no son de etectados po r este software. Los erro ores que s son evidenc ciados por e el compilador r deben corre egirse modifi cando el pro ograma fuent te.
112
Este trabajo de correccin de los errores sintcticos y semnticos del cdigo, que deriva en un cdigo libre de errores, puede efectuarse tambin mediante un intrprete, en lugar de con el empleo de un compilador. Un traductor intrprete toma un programa fuente, y lo traduce y ejecuta lnea a lnea, instruccin a instruccin, segn sea necesario, y normalmente sin guardar el resultado de la traduccin. El compilador realiza la traduccin completa y a continuacin ejecuta el cdigo. A la hora de depurar la aplicacin, puede resultar ms interesante el trabajo con un intrprete antes que con un compilador, de ah la observacin realizada. 4.4.3.2 Generacin del Cdigo de los Procedimientos de Operacin y Seguridad
El objetivo de esta tarea es generar los procedimientos de operacin y administracin del sistema de informacin, as como los procedimientos de seguridad y control de acceso, necesarios para ejecutar el sistema una vez que se haya implantado y est en produccin. Para la generacin de dichos procedimientos se tienen en cuenta, tambin, los estndares y normas de la instalacin recogidos en el catlogo de normas.
4.4.4
Construccin de los componentes y procedimientos de Migracin y Carga Inicial de datos
El objetivo de esta actividad es la codificacin y prueba de los componentes y procedimientos de migracin y carga inicial de datos, a partir de las especificaciones recogidas en el plan de migracin y carga inicial de datos obtenidos en el proceso Diseo del Sistema de Informacin. Previamente a la generacin del cdigo, se prepara la infraestructura tecnolgica necesaria para realizar la codificacin y las pruebas de los distintos componentes y procedimientos asociados, de acuerdo a las caractersticas del entorno de migracin especificado en el plan de migracin y carga inicial de datos. Finalmente, se llevan a cabo las verificaciones establecidas en la especificacin tcnica del plan de pruebas propio de la migracin. 4.4.4.1 Preparacin del Entorno de Migracin y Carga Inicial de datos
Se dispone el entorno en el que se van a construir los componentes y procedimientos de migracin y carga inicial de datos, considerando las bibliotecas o libreras a utilizar, herramientas o utilidades especficas para la conversin, y compiladores, entre otros. Se determinan los datos necesarios para realizar las pruebas de los componentes y procedimientos asociados y se configura el entorno de acuerdo a dichas necesidades. 4.4.4.2 Generacin del cdigo de los componentes y procedimientos de Migracin y Carga Inicial de Datos El objetivo de esta tarea es la generacin del cdigo correspondiente a los procedimientos y componentes necesarios para llevar a cabo la migracin, definidos en el plan de migracin y carga inicial de datos. Para generar el cdigo fuente se tienen en cuenta los estndares de
113
nomenclatura y codificacin utilizados por la organizacin y recogidos en el catlogo de normas para este tipo de componentes. 4.4.4.3 Realizacin y Evaluacin de las Pruebas de Migracin y Carga Inicial de Datos El objetivo de esta tarea es efectuar las pruebas de los distintos componentes y procedimientos de migracin y evaluar su resultado. Esta evaluacin recoge el grado de cumplimiento de las mismas, y consiste en: Comparar los resultados obtenidos con los esperados Identificar el origen de cada problema detectado para poder remitirlo a quien proceda, determinar la envergadura de las modificaciones y qu acciones deben llevarse a cabo para resolverlo de forma satisfactoria. Indicar si el plan de pruebas debe volver a realizarse total o parcialmente, y si ser necesario contemplar nuevos casos de prueba no considerados anteriormente.
4.4.5
Elaboracin de los Manuales de Usuario
El objetivo de esta tarea es elaborar la documentacin de usuario, tanto usuario final como de explotacin, de acuerdo a los requisitos establecidos y recogidos en la Especificacin de Requisitos de Software. Se deben especificar aspectos relativos a los tipos de documentos a elaborar y estndares a seguir en la generacin de los mismos, y para cada uno de ellos: Formato y soporte en el que se desarrollarn. Estructura. Distribucin y mantenimiento de la documentacin y nmero de copias a editar.
4.4.6
Definicin de la formacin de usuarios finales
En esta actividad se establecen las necesidades de formacin del usuario final, con el objetivo de conseguir la explotacin eficaz del nuevo sistema. Para la definicin de la formacin hay que tener en cuenta las caractersticas funcionales y tcnicas propias del sistema de informacin, as como los requisitos relacionados con la formacin del usuario final. El producto resultante de esta actividad es la especificacin de la formacin de usuarios finales, que consta de los siguientes elementos: Esquema de formacin. Materiales y entornos de formacin
114
4.4.7 4.4.7.1
Entregable Fase de Implementacin Introduccin
Una vez concluidos los diagramas de clases del diseo destinados al ciclo de desarrollo actual en la aplicacin dispondremos de suficientes detalles para generar un cdigo que utilizaremos en la capa del dominio de los objetos. Los artefactos del UML creados en la fase de diseo los diagramas de colaboracin y los de clases del diseo- servirn de entrada en el proceso de generacin de cdigo. 4.4.7.2 La programacin y el proceso de desarrollo
Si se quiere reducir el riesgo y aumentar la probabilidad de conseguir una aplicacin adecuada, el desarrollo debera basarse en un suficiente modelado del anlisis y diseo antes de iniciar la codificacin. Ello no significa que durante la programacin no tengan cabida los prototipos ni el diseo: las modernas herramientas de desarrollo ofrecen un excelente ambiente para examinar rpidamente mtodos alternos, normalmente vale la pena dedicar poco o mucho tiempo al diseo por la codificacin. Pero la parte esencial de la aplicacin por ejemplo el modelo conceptual bsico, las capas arquitectnicas, las principales asignaciones de responsabilidades y las interacciones ms importantes de los objetos- se determina ms satisfactoriamente en una investigacin formal y en el proceso de diseo que apresurndose a codificar. Esto origina sistemas que son ms difciles de entender, ampliar y de darle mantenimiento, sin que brinden soporte a un proceso susceptible de repetirse eficazmente. Dicho lo anterior, a menudo lo ms conveniente es omitir la fase de diseo para realizar un poco de programacin exploratoria a fin de describir un diseo funcional y luego regresar a la fase formal de diseo. La creacin de cdigo en un lenguaje orientado a objetos no forma parte del anlisis ni del diseo orientado a objetos; es meta final en s misma. Una ventaja del anlisis, del diseo y la programacin orientados a objetos cuando se emplean junto con un proceso de desarrollo como el que hemos recomendado- es que ofrece una gua completa de principio a fin para realizar la codificacin a partir de los requerimientos. Los artefactos que se introducen en otros posteriores en una forma rastreable y til culminarn finalmente en una aplicacin funcional. Con ello no queremos decir que el camino sea fcil ni que podamos seguirlo mecnicamente, pues existen demasiadas variables. Pero la gua constituye un punto de partida para experimentar e intercambiar opiniones. Creatividad y cambio durante la fase de construccin.
115
La toma de decisiones y el trabajo creativo se realizan en gran medida durante las fases de anlisis y diseo. Veremos que la generacin de cdigo es un proceso de traduccin bastante mecnico. No obstante, en general la fase de programacin no es un paso fcil de la generacin de cdigo, todo lo contrario. En realidad los resultados obtenidos durante el diseo son un primer paso incompleto; en la programacin y en las pruebas se efectuar multitud de cambios y se descubrirn y resolvern problemas detallados. Los artefactos del diseo cuando estn bien hechos, producen un ncleo flexible que crece con elegancia y fuerza para atender los problemas que surjan en la programacin. Cambios de cdigo, las herramientas CASE y la ingeniera inversa. Es conveniente que los diagramas generados en la fase de diseo sean actualizados semiautomaticamente para que incluyan los cambios en la siguiente fase de codificacin. En teora esto deberas hacerse con una herramienta CASE (Computer-aided software engineering, ingeniera de software asistida por computadora), la cual puede leer el cdigo fuente y producir automticamente por ejemplo- los diagramas de clases y de colaboracin. Este es un aspecto de la ingeniera inversa, o sea la actividad consistente en generar modelos lgicos partiendo de un cdigo fuente ejecutable. 4.4.7.3 Mapeo de diseos para codificacin
Para implementar un lenguaje de programacin orientado a objetos se requiere escribir un cdigo fuente para: Definiciones de Clases. Definiciones de Mtodos.
Creacin de las definiciones de clases a partir de los diagramas de clases del diseo. Los diagramas de clases del diseo describen por lo menos el nombre de las clases, las superclases, las etiquetas de los mtodos y los atributos simples de una clase. Esa informacin es suficiente para formular una definicin bsica de una clase en un lenguaje orientado a objetos. Creacin de mtodos a partir de los diagramas de colaboracin. Un diagrama de colaboracin muestra los mensajes que se envan en respuesta a una llamada al mtodo. La secuencia de los mensajes se traduce en una serie de enunciados en la definicin del mtodo. 4.4.7.4 Orden de la implementacin
Es necesario implementar las clases (y, en teora probarlas totalmente de manera individual), de la menos acoplada a la ms acoplada. Por ejemplo, si observamos la figura 43, las clases posibles para implementar son Pago o EspecificaciondeProducto vienen despus de las clases
116
que dependen nicamente de las im mplementacio ones anterio ores: Catalo ogodeProduc ctos o Venta asLineadePr roducto.
Fig gura 43. Ejemp plo de orden de e implementacin
4.4.7 7.5
Resu umen
Es muy sencillo o el proceso o de traducir r a definicion nes de clase es los diagra amas del dis seo y eso de traducir a mto odos los dia agramas de colaboraci n. En la fase de tambin el proce ramacin tod dava puede en tomarse muchas dec cisiones, efe ectuarse mu uchos cambios de progr dise o y realizars se una explo oracin muy y extensa; pe ero, en teor a, la arquite ectura global l y las decis siones ms importantes ya se estab blecieron tot talmente ant tes que com mience la fase de codifi icacin. 4.4.7 7.6 Conc clusin de la a Implemen tacin
Una a vez codific cado, docum mentado y pa asados los te ests en cada a ciclo de d esarrollo iterativo, habie endo realizad do las prueba as unitarias y los test de e integracin; con toda es sta informacin se debe confeccion nar un Doc cumento de e diseo de d Program mas y Codi ificacin el l cual mpaara a los s Manuales de Operado or y Usuario o as como lo os de Forma acin. Los mismos acom config gurarn los elementos e ms m importan tes del paqu uete de entre egable que se ervirn de en ntrada a la s siguiente fase e.
117
4.4.8 Caso de Estudio: Im mplementaci in
a est desarr uerdo a la re esponsabilidad de La arquitectura del sistema rollada en capas de acu cada una de ellas s. Tambin vale v aclarar que se estru uctur el sist tema para q que sea fcilm mente table a otra base de dato os (que sea soportada por Hibernate e) o a otra int terfaz grfica a (que adapt sea c compatible co on web servi ices).
Figura a 44. Arquitectu e estudio presentado ura del caso de
4.4.8.1
Estru uctura de C digo
Figura 45. Estructura del l cdigo del ca aso de estudio presentado
118
Figura 46. Ba asesDeDatos.C Controlador (1)
Figura 4 47. LogicaDeNe egocio (2)
119
Figura F 48. Log icaDeNegocio. .Controlador (3 3)
Figu ura 49. WebSe ervices/WebSer rvicesWrapper rs (4)
120
4.4.8.2 Clase Protocolo.java
Nota: El siguiente cdigo de la clase Protocolo se presenta solo con fines demostrativos, por motivo no se incluyen ciertos atributos, mtodos, importaciones y anotaciones necesarios para el funcionamiento adecuado de la clase.
/** * Sistema de Gestin Bioqumica * Autores: Daniel Talebi - Pablo Javier Ortiz * Universidad Tecnolgica Nacional * Facultad Regional Tucumn * 2011 * Prohibida su copia, distribucin parcial o total a ttulo oneroso o gratuito */ package LogicaDeNegocio; /** * @author Daniel Talebi Pablo Ortiz */ @Entity public class Protocolo{ private long id; private String fechaDeRecepcion; private String horaDeRecepcion; private String medico; private String fechaDeEntrega; private boolean impreso; private float total; private float deuda; private String observacion; private boolean eliminado; private boolean informado; @ManyToOne private Cliente cliente; @OneToMany private List<MuestraDeProtocolo> muestrasDelProtocolo; @OneToMany private List<LineaDeProtocolo> lineasDelProtocolo;
public Protocolo(Cliente cliente, Empleado empleado,String medico, String observacion, ArrayList<LineaDeProtocolo> lineas, ArrayList<MuestraDeProtocolo> muestras) { this.cliente = cliente; this.medico = medico; this.observacion = observacion; this.lineasDelProtocolo = lineas; this.muestrasDelProtocolo = muestras;
121
this.impreso = false; this.eliminado = false; this.informado = false; //Calculamos el total for(LineaDeProtocolo indice:this.lineasDelProtocolo){ this.total += indice.getPractica().getPrecio(); } this.deuda = this.total; } }
4.4.8.3 /**
Clase ControladorProcolo.java Mtodo Registrar Protocolo
* * @param idObraSocial_NumeroOrden_nbuPractica * @param idCliente * @param fechaDeRecepcion * @param horaDeRecepcion * @param medico * @param fechaDeEntrega * @param observacion * @return * @throws ProtocoloAlredyExistsException * El array idObraSocial_NumeroOrden_nbuPractica tiene el siguiente formato: * ----------------------------------------------------------* |int idObraSocial | String NumeroOrden | long nbuPractica | * |-----------------------------------------------------------| * | | | | * ----------------------------------------------------------*/ public static Protocolo registrarProtocolo(String idObraSocial_NumeroOrden_nbuPractica[][], int idMuestras[], int idCliente, String medico, String observacion, int idEmpleado) throws ProtocoloCreationException{ Protocolo protocolo = null; try { //Validar Datos //Verificar que los arrays tengan datos //Buscar al cliente Cliente cliente = ControladorCliente.getClienteById(idCliente); //Bucle para recorrer todas los ids de prctica //HACER LA CLASE LDP Y MDP protocolo = new Protocolo(cliente, medico, observacion); //Iteramos para crear las lneas de protocolo
122
for (int i = 0; i < idObraSocial_NumeroOrden_nbuPractica.length; i++) { //Buscamos los ids del array int idObraSocial = Integer.parseInt(idObraSocial_NumeroOrden_nbuPractica[i][0]); String numeroOrden = idObraSocial_NumeroOrden_nbuPractica[i][1]; long nbuPractica = Long.parseLong(idObraSocial_NumeroOrden_nbuPractica[i][2]); //Recuperamos la Obra Social mediante el id ObraSocial obraSocial = ControladorObraSocial.getObraSocialById(idObraSocial); //Recuperamos la Prctica mediante el nbu Practica practica = ControladorPractica.getPracticaByNbu(nbuPractica); //Creamos la Lnea de Protocolo LineaDeProtocolo linea = new LineaDeProtocolo(protocolo, practica, obraSocial, numeroOrden); //Agregamos esa lnea a la lista de lneas del protocol protocolo.addLineaDeProtocolo(linea); } //Recuperamos las muestras y la agregamos al ArrayList for (int i=0;i<idMuestras.length;i++){ Muestra muestra = ControladorMuestra.getMuestraById(idMuestras[i]); MuestraDeProtocolo muestraDeProtocolo = new MuestraDeProtocolo(protocolo, muestra); protocolo.addMuestraDeProtocolo(muestraDeProtocolo); } Protocolo resultado = null; resultado = ProtocoloDAO.saveProtocolo(protocolo); //Mandamos el registro al Historial de Protocolo ControladorHistorialProtocolo.registrarHistorialProtocoloDeNuevoProtoc olo(protocolo, idEmpleado); //Volvemos a buscar y asignar el cliente, ya que necesitamos que se //carguen el arraylist de AsociacionesAPerfil en los objetos usuarios try { resultado.setCliente(ControladorCliente.getClienteById(resultado.getCl iente().getId())); } catch (ClienteNotFoundException ex) { System.out.println(ex); Logger.getLogger(ProtocoloDAO.class.getName()).log(Level.SEVERE, null, ex); } return protocolo; } catch (ClienteNotFoundException ex) {
123
Logger.getLogger(ControladorProtocolo.class.getName()).log(Level.SEVER E, null, ex); throw new ProtocoloCreationException(ex.getMessage()); }catch (ObraSocialNotFoundException ex) { Logger.getLogger(ControladorProtocolo.class.getName()).log(Level.SEVER E, null, ex); throw new ProtocoloCreationException(ex.getMessage()); } catch (PracticaNotFoundException ex) { Logger.getLogger(ControladorProtocolo.class.getName()).log(Level.SEVER E, null, ex); throw new ProtocoloCreationException(ex.getMessage()); } catch (MuestraNotFoundException ex) { Logger.getLogger(ControladorProtocolo.class.getName()).log(Level.SEVER E, null, ex); throw new ProtocoloCreationException(ex.getMessage()); } finally{ return protocolo; } }
4.4.8.4
Clase ProtocoloDAO Mtodo saveProtocolo
public static Protocolo saveProtocolo(Protocolo objeto){ Protocolo resultado = null; try{ session = HibernateUtil.iniciarOperacion(); long idProtocolo = (Long) session.save(objeto); session.beginTransaction().commit(); resultado = (Protocolo) session.createQuery("from Protocolo where id = " + idProtocolo).uniqueResult(); ArrayList<MuestraDeProtocolo> muestrasDelProtocolo = (ArrayList<MuestraDeProtocolo>) session.createQuery("from MuestraDeProtocolo where protocolo_id = " + resultado.getId()).list(); resultado.setMuestrasDelProtocolo(muestrasDelProtocolo); }catch(HibernateException ex){ System.out.println(ex); session.getTransaction().rollback(); throw new HibernateException("ProtocoloDAO.saveProtocolo(objeto): Ocurri un eror en la capa de acceso a Datos.\n" + ex); }finally{ session.close(); return resultado; } }
124
4.4.8.5 /**
Clase ProtocoloWs.java Mtodo registrarProtocolo
* Web service operation */ @WebMethod(operationName = "registrarProtocolo") public ProtocoloWrapper registrarProtocolo(@WebParam(name = "idObraSocial_NumeroOrden_NbuPractica") String idObraSocial_NumeroOrden_NbuPractica, @WebParam(name = "idMuestras") int stringMuestras[], @WebParam(name = "idCliente") int idCliente, @WebParam(name = "medico") String medico, @WebParam(name = "observacion") String observacion, @WebParam(name = "idEmpleado") int idEmpleado) { Protocolo protocolo = null; ProtocoloWrapper resultado = null; //long resultado = -1; try { //Para armar el array de las obras sociales con numero de orden //autorizando a una prctica determinada, usamos un string[] //que tiene como separador de campo el "-" //Creamos un array con tantas filas como indique la variable filas //y con 3 columnas, ya que es el idObraSocial, NumeroOrden y NbuPractica System.out.println("La longitud del array es: " + idObraSocial_NumeroOrden_NbuPractica); String filas[] = idObraSocial_NumeroOrden_NbuPractica.split("#"); String datos[][] = new String[filas.length][3]; for (int i=0;i<filas.length;i++){ String columna[] = filas[i].split("-"); datos[i][0] = columna[0]; datos[i][1] = columna[1]; datos[i][2] = columna[2]; } /*System.out.println("La longitud de datos es: " + datos.length); for(int i=0;i<datos.length;i++){ for(int j=0;i<3;j++){ System.out.println(datos[i][j]); } }*/ /*String auxiliar[] = stringMuestras.split("#"); int idMuestras[] = new int[auxiliar.length];
125
for (int i=0;i<auxiliar.length;i++){ idMuestras[i] = Integer.parseInt(auxiliar[i]); }*/ protocolo = ControladorProtocolo.registrarProtocolo(datos, stringMuestras, idCliente, medico, observacion, idEmpleado); /** * Eliminamos todas las referencias adcionales que no tienen sentido * mostrar ahora */ protocolo.getCliente().setListaDeAsociacionAPerfiles(null); for(LineaDeProtocolo lineaActual : protocolo.getLineasDelProtocolo()){ lineaActual.setProtocolo(null); } for(MuestraDeProtocolo muestraActual : protocolo.getMuestrasDelProtocolo()){ muestraActual.setProtocolo(null); } //Envolvemos al protocolo recin creado resultado = new ProtocoloWrapper(true, null, protocolo); } catch (Exception e) { System.out.println(e); resultado = new ProtocoloWrapper(false, e.toString(), null); return resultado; } return resultado; }
126 4.5 Pruebas
El testing puede probar la presencia de errores, pero no la ausencia de ellos. (Edsger Dijkstra)
4.5.1
Descripcin
Segn Wikipedia, las pruebas de software (en ingls testing) son los procesos que permiten verificar y revelar la calidad de un producto software. Son utilizadas para identificar posibles fallos de implementacin, calidad, o usabilidad de un software. Es una fase del desarrollo de software consistente en probar las aplicaciones construidas. Las Pruebas de Software consisten en ejecutar un programa y mediante tcnicas experimentales descubrir que errores tiene. Para determinar el nivel de calidad se deben efectuar unas medidas o pruebas que permitan comprobar el grado de cumplimiento respecto de las especificaciones iniciales del sistema. Hay muchos planteamientos a la hora de abordar el proceso de pruebas de software, pero para verificar productos complejos de forma efectiva se requiere de un proceso de investigacin ms que seguir un procedimiento al pie de la letra. Una definicin de "testing" es: proceso de evaluacin de un producto desde un punto de vista crtico, donde el "tester" (persona que realiza las pruebas) somete el producto a una serie de acciones inquisitivas, y el producto responde con su comportamiento como reaccin. Es necesario realizar las pruebas en un entorno de pruebas separado fsicamente del de produccin. Para crear un entorno de pruebas en una mquina independiente de la mquina de produccin es necesario crear las mismas condiciones que en la mquina de produccin. En general, los informticos distinguen entre errores de programacin (o "bugs") y defectos de forma. Defecto de forma: el programa no realiza lo que el usuario espera. Error de programacin: fallo en la semntica de un programa de ordenador. ste podra presentarse, o no, como un defecto de forma si se llegan a dar ciertas condiciones.
Una prctica comn es que el proceso de pruebas de un programa sea realizado por un grupo independiente de "testers" al finalizar su desarrollo y antes de sacarlo al mercado. Actualmente, viene siendo muy popular distribuir de forma gratuita una versin no final del producto para que sean los propios consumidores los que la prueben. En ambos casos, a la versin del producto en pruebas y que es anterior a la versin final, se le denomina Beta o Demo.
127
Pue ede adems existir una versin v anter rior en el proceso de desarrollo llama ada Alpha, en la que e el programa, aunque inco ompleto, disp pone de func cionalidad b sica y puede e ser testado o.
4.5.2
La impor rtancia de la a deteccin oportuna
En la cadena de e valor del desarrollo de un software especfico, el proceso d de prueba es clave hora de dete ectar errores s o fallos. Co onceptos co omo estabilid dad, escalabiilidad, eficiencia y a la h segur ridad se rela acionan con la calidad d de un produc cto bien desa arrollado. La as aplicacion nes de softw ware han crec cido en com mplejidad y ta amao, y por consiguiente tambin e en costes. Hoy H en da e es crucial ve erificar y eva aluar la calid c pa ara minimiza ar el coste de su dad de lo construido repar racin. Cuanto antes se detecte d un fa allo, ms bar rato ser su correccin. c
Proceso P de P Prueba realiza ado por exper rtos El E proceso de e prueba es un proceso tc cnico especia lizado, de inv vestigacin, que requie ere de pro ofesionales altamente capacitados en lenguajes de e desarrollo, mtodos m y tc cnicas de pru uebas y herr ramientas es specializadas. El conocimiiento que de ebe manejar u un ingeniero de d prueba es muchas m veces s superior al del desarrolla ador de softwa are.
4.5.3
Tipos de e Pruebas
El nico instrumento adec cuado para determinar el status de e la calidad d de un pro oducto softw ware es el proceso de pruebas. E oceso se ejecutan e pru uebas dirigid das a En este pro comp ponentes del software o al sistema d de software en e su totalida ad, con el ob bjetivo de me edir el grado o en que el software cu umple con lo os requerimie entos. En la as pruebas s se usan cas sos de prueb ba, especific cados de forma estructu urada media ante Tcnica as de prueb ba. El proceso de prueb bas, sus obje etivos y los mtodos m y tc cnicas usado os se describ ben en un pla an de prueba as. Par ra esto existe en diferentes s tipos de pru uebas tales como: c Pruebas s unitarias. Pruebas s funcionales s. Pruebas s de integrac cin. Pruebas s de validacin. Pruebas s de sistema a. Caja bla anca (sistem mas). Caja ne egra (sistema as). Pruebas s de aceptac cin. Pruebas s de regresi n. Pruebas s de carga. Pruebas s de prestaciones. Pruebas s de recorrid do.
128
Pruebas s de mutaci n. Pruebas s concurrent tes.
En este libro so olo se va a desarrollar d u na introducc cin sobre la as Pruebas U Unitarias, Pruebas tegracin, Pruebas de Sistemas y Pr ruebas de Re egresin. de Int
4.5.4
Ejecuci n de las Pru uebas Unita arias
En esta actividad se realiz zan las prue ebas unitaria as de cada uno de los componente es del ma de inform macin, una vez codificad dos, con el objeto o de co omprobar que e su estructu ura es sistem corre ecta y que se e ajustan a la a funcionalida ad establecid da. ruebas se ha a definido el entorno necesario para la l realizacin n de cada nivel de En el plan de pr prueb ba, as com mo las verific caciones as sociadas a las pruebas unitarias, lla coordinac cin y secue encia a segu uir en la ejecucin de las mismas, y los criterios de d registro y aceptacin de los result tados.
Pru uebas Unitari ias Son n Pruebas de unidades ind dividuales o de g grupos de unidades relacio onadas de hardw ware o softwa are.
4.5.4.1
paracin del Entorno de e las Prueba as Unitarias Prep
En e esta tarea se e preparan to odos los recu ursos necesa arios para re ealizar las pru uebas unitar rias de cada uno de los componentes c s del sistema a de informacin. ra ello, se as segura la disponibilidad del entorno o y de los da atos necesa arios para eje ecutar Par estas s pruebas, se s preparan las bibliote cas o libreras oportuna as para la r realizacin de d las mism mas, as com mo los proce edimientos manuales o automtico os necesario os, conforme e a la espec cificacin de el entorno def finida en el p plan de prueb bas. 4.5.4.2 Reali izacin y Ev valuacin de e las Prueba as Unitarias s
objetivo de esta e tarea es comproba r el correcto o funcionamiento de los componente es del El o sistem ma de inform macin, codif ficados previ amente, con nforme a las verificacione es establecid das en el pla an de prueba as para el niv vel de prueba as unitarias. Par ra cada ver rificacin est tablecida, se l pruebas con los ca asos de pruebas e realizan las asoci iados, efectu uando el corr respondiente e anlisis y evaluacin e de los resulta ados, y gene erando un re egistro confor rme a los crit terios estable ecidos en el plan de prue ebas. guidamente, se analizan los resultad dos de las pr ruebas unitarias, evalun ndose las mismas Seg para comprobar que q los resultados son lo os esperado os. Si los res sultados no s son los espe erados que proceder r a realizar la as correccion nes pertinent tes. hay q
129
4.5.5 Ejecucin de las Pruebas de Integracin
El objetivo de las pruebas de integracin es verificar si los componentes o subsistemas interactan correctamente a travs de sus interfaces, tanto internas como externas, cubren la funcionalidad establecida, y se ajustan a los requisitos especificados en las verificaciones correspondientes. La estrategia a seguir en las pruebas de integracin se establece en el plan de pruebas, donde se habr tenido en cuenta el plan de integracin del sistema de informacin. 4.5.5.1 Preparacin del Entorno de las Pruebas de Integracin
En esta tarea se disponen todos los recursos necesarios para realizar las pruebas de integracin de los componentes y subsistemas que conforman el sistema de informacin. Para ello, se asegura la disponibilidad del entorno y de los datos necesarios para ejecutar estas pruebas, se preparan las bibliotecas o libreras que se estimen oportunas para la realizacin de las mismas, as como los procedimientos manuales o automticos asociados, conforme a la especificacin del entorno definida en el plan de pruebas. 4.5.5.2 Realizacin de las Pruebas de Integracin
El objetivo de esta tarea es verificar el correcto funcionamiento de las interfaces existentes entre los distintos componentes y subsistemas, conforme a las verificaciones establecidas para el nivel de pruebas de integracin. Para cada verificacin establecida, se realizan las pruebas con los casos de pruebas asociados, efectuando el correspondiente anlisis e informe de los resultados de cada verificacin, y generando un registro conforme a los criterios establecidos en el plan de pruebas. 4.5.5.3 Evaluacin del Resultado de las Pruebas de Integracin
El objetivo de esta tarea es analizar los resultados de las pruebas de integracin y efectuar su evaluacin. Dicha evaluacin recoge el grado de cumplimiento de las pruebas y consiste en: Comparar los resultados obtenidos con los esperados. Identificar el origen de cada problema detectado para poder remitirlo a quien proceda, determinar la envergadura de las modificaciones y qu acciones deben llevarse a cabo para resolverlo de forma satisfactoria. Indicar si el plan de pruebas debe volver a realizarse total o parcialmente, y si ser necesario contemplar nuevos casos de prueba no considerados anteriormente.
4.5.6
Ejecucin de las Pruebas del Sistema
El objetivo de las pruebas del sistema es comprobar la integracin del sistema de informacin globalmente, verificando el funcionamiento correcto de las interfaces entre los distintos
130
subsi istemas que e lo compon nen y con e el resto de sistemas s de informacin n con los que se comu unica. En la realizaci n de estas pruebas es importante comprobar la cobertura de los requ uisitos, umplimiento puede com prometer la aceptacin del sistema por el equipo de dado que su incu acin respon nsable de realizar las pru uebas de im mplantacin del d sistema, que se lleva arn a opera cabo en el proces so Implantac cin y Acepta acin del Sist tema. 4.5.6 6.1 Prep paracin del Entorno de e las Prueba as del Sistem ma
En esta tarea se preparan n todos los recursos necesarios n para p realizar r las prueba as del ma, de acuerdo a las car ractersticas del entorno establecidas e s en el plan d de pruebas. sistem Par ra ello se as segura la dis sponibilidad del entorno y de los da atos necesar ecutar rios para eje estas s pruebas, se s preparan n las bibliote ecas o libre eras que se e estimen o oportunas pa ara la realiz zacin de las s mismas, as s como los p procedimiento os manuales s o automtic cos asociado os. 4.5.6 6.2 Reali izacin de la as Pruebas del Sistema a
e esta tarea a es comp robar la integracin de todos los s subsistem mas y El objetivo de ponentes del sistema de informacin, , as como la a interaccin del mismo c con otros sist temas comp de informacin co on los que se s relaciona, , de acuerdo o a las verificaciones est tablecidas para p el nivel de pruebas del sistema. ra cada ver rificacin est tablecida, se e realizan las l pruebas con los ca asos de pruebas Par asoci iados, efectu uando el correspondiente e anlisis e informe de lo os resultado os y generan ndo un regist tro conforme e a los criterio os establecid dos en el pla an de pruebas. 4.5.6 6.3 Evalu uacin del Resultado R d de las Pruebas del Siste ema
objetivo de esta activid dad es anallizar los res sultados de las pruebas s del sistem ma de El o inform macin y efe ectuar su eva aluacin. Dic cha evaluaci n recoge el grado de cu umplimiento de las mism mas, y consiste en: Compar rar los result tados obtenid dos con los esperados e Identific car el origen de cada pro blema detec ctado para po oder remitirlo o a quien pro oceda, determinar la envergadura de las modifica aciones y qu u acciones deben lleva arse a ara resolverlo o de forma s atisfactoria. cabo pa Indicar si el plan de e pruebas de ebe volver a realizarse total t o parcia almente, y si s ser rio contemplar nuevos ca asos de prue eba no consid derados ante eriormente. necesar
Formalizaci ion de las pru uebas Es altamen nte recomend dable utilizar r una metod dologa concreta c y re econocida pa ara las prueb bas del siste ema de informacin, i a as como para a las dems fases del des sarrollo del d software. El modulo Construcci n del Sistem ma de Informacin I d de MTRICA versin v 3 pued de ser utilizad do.
131
4.5.7 Pruebas de Regresin
Se denominan Pruebas de Regresin a cualquier tipo de pruebas de software que intentan descubrir las causas de nuevos errores, carencias de funcionalidad, o divergencias funcionales con respecto al comportamiento esperado del software, inducidos por cambios recientemente realizados en partes de la aplicacin que anteriormente al citado cambio no eran propensas a este tipo de error. Esto implica que el error tratado se reproduce como consecuencia inesperada del citado cambio en el programa. Este tipo de cambio puede ser debido a prcticas no adecuadas de control de versiones, falta de consideracin acerca del mbito o contexto de produccin final y extensibilidad del error que fue corregido (fragilidad de la correccin), o simplemente una consecuencia del rediseo de la aplicacin. Por lo tanto, en la mayora de las situaciones del desarrollo de software se considera una buena prctica que cuando se localiza y corrige un bug, se grabe una prueba que exponga el bug y se vuelvan a probar regularmente despus de los cambios subsiguientes que experimente el programa. Existen herramientas de software que permiten detectar este tipo de errores de manera parcial o totalmente automatizada, la prctica habitual en programacin extrema es que este tipo de pruebas se ejecuten en cada uno de los pasos del ciclo de vida del desarrollo del software. Cuando se lleva a cabo un cambio en un producto software, se deben realizar estas Pruebas de Regresin para evitar el efecto onda. Con ellas, se comprueba que los cambios sobre un componente del software no introduzcan un comportamiento no deseado o errores en otros componentes no modificados. Tipos de regresin: Clasificacin de mbito o o o Local; los cambios introducen nuevos errores. Desenmascarada; los cambios revelan errores propios. Remota; los cambios vinculan algunas partes del programa (mdulo) e introducen errores en ella. Clasificacin temporal o Nueva caracterstica; los cambios realizados con respecto a nuevas funcionalidades en la versin, introducen errores en otras novedades de la misma versin del software. o Caracterstica preexistente; los cambios realizados con respecto a nuevas funcionalidades introducen errores en funcionalidad existentes de previas versiones.
132
4.5.8 4.5.8.1 Entregab ble Fase de Pruebas Intro oduccin
a fase, da in nicio luego de que las dif ferentes unid dades de dis seo han sid do desarrolla adas y Esta proba adas por sep parado. Dura ante el desa arrollo del sis stema se em mplean de fo orma experim mental para asegurar que q el soft tware no f falle, es de ecir, que fu uncione de acuerdo a sus cificaciones y a la mane era que los u usuarios esp peran que lo haga, y de esta forma poder espec detec ctar cualquier anomala, antes a de que e el sistema sea puesto en e marcha. Si e el sistema cu umple de form ma satisfacto oria con las pruebas, p se procede a re ealizar la car rga de los ar rchivos, base e de datos y tablas del n uevo sistema, para de esta forma da ar inicio al pr roceso de a aceptacin final, f durant te el cual, el sistema comenzar a funcion ar por un lapso deter rminado de ti iempo llamad do Periodo d de Aceptaci n. Finalizado o el Periodo de Aceptaci n, se le dar r al sistema a la aprobacin final, para a que pase a ser el sistema oficial. 4.5.8.2 Tipos s de Prueba as
director de proyecto de ebe conocer r que tipos de pruebas se realizar rn al sistem ma ya El d imple ementado, y la utilidad de e cada una d de ellas. Las pruebas de unidades so on el primer tipo de prueb ba que se ap plica. El sigu uiente nivel c consiste en las pruebas de integraciin. Esto valida la funcio onalidad global de cada etapa de la aplicacin parcial. p Por ltimo las pru uebas de sis stema y de a aceptacin validan v el pro oducto final, c como lo mue estra la siguiente figura 5 50:
Figura 50. Pruebas de visin global
4.5.8.3
Docu umentos m s usuales e en cada fase e
A to odos estos documentos hay h que aa adir documen ntos con la estimacin y planificacin n de la prxim ambin habr r que ir actualizando el ndice de to odo el ma fase y del resto del proyecto. Ta material relaciona ado. Vamos a listar los m ms importantes:
133
Plan de pruebas del sistema (actualizado). Informe de los resultados de las pruebas. Descripcin de las pruebas, el resultado esperado, resultado obtenido y acciones a tomar para corregir las desviaciones.
Plan de Pruebas El propsito del plan de pruebas es explicitar el alcance, enfoque, recursos requeridos, calendario, responsables y manejo de riesgos de un proceso de pruebas. Note que puede haber un plan global que explicite el nfasis a realizar sobre los distintos tipos de pruebas (verificacin, integracin e integracin). Luego de haber ejecutado las pruebas se actualizar los elementos contenidos en el mismo.
Un plan de pruebas incluye: Identificador nico del documento. Introduccin y resumen de elementos y caractersticas a probar. Elementos software a probar. Caractersticas a probar. Caractersticas que no se probarn. Enfoque general de la prueba. Criterios de paso/fallo para cada elemento. Criterios de suspensin y requisitos de reanudacin. Documentos a entregar. Actividades de preparacin y ejecucin de pruebas. Necesidades de entorno. Responsabilidades en la organizacin y realizacin de las pruebas. Necesidades de personal y formacin. Esquema de tiempos. Riesgos asumidos por el plan y planes de contingencias. Aprobaciones y firmas con nombre y puesto desempeado.
134
Informes de los resultados de las pruebas Una vez ejecutadas las pruebas se documentar los resultados a partir de la generacin de: 1. El histrico de pruebas (test log) documenta todos los hechos relevantes ocurridos durante la ejecucin de las pruebas, con los siguientes elementos: Identificador. Descripcin de la prueba: elementos probados y entorno de la prueba. Anotacin de datos sobre cada hecho ocurrido (incluido el comienzo y el final de la prueba). Fecha y hora. Identificador de informe de incidente. Otras informaciones.
2. El informe de incidente (test incident report) documenta cada incidente (por ejemplo, una interrupcin en las pruebas debido a un corte de electricidad, bloqueo del teclado, etc.) ocurrido en la prueba y que requiera una posterior investigacin. Su estructura se define as: Identificador. Resumen del incidente. Descripcin de datos objetivos (fecha/hora, entradas, resultados esperados, etc.). Impacto que tendr sobre las pruebas.
3. El informe resumen (test summary report) resume los resultados de las actividades de prueba (las sealadas en el propio informe) y aporta una evaluacin del software basada en dichos resultados. Incluye: Identificador. Resumen de la evaluacin de los elementos probados. Variaciones del software respecto a su especificacin de diseo, as como las variaciones en las pruebas. Valoracin de la extensin de la prueba (cobertura lgica, funcional, de requisitos, etc.). Resumen de los resultados obtenidos en las pruebas. Evaluacin de cada elemento software sometido a prueba (evaluacin general del software incluyendo las limitaciones del mismo). Firmas y aprobaciones de quienes deban supervisar el informe.
135
Comparativo de los resultados de las pruebas Una vez realizadas las pruebas se deben registrar los resultados y comparar con la planificacin, de manera que se identifiquen las posibles desviaciones y establezcan acciones concretas a realizar, las que generaran nuevos requerimientos o modificarn los existentes, para que los desarrolladores los implementen.
4.5.9
Conclusin de la fase de Pruebas
Aunque se han desarrollado miles de herramientas de soporte de esta fase, todas han limitado su xito a entornos muy concretos, frecuentemente slo sirviendo para el producto para el que se desarrollaron. Slo herramientas muy generales como analizadores de complejidad, sistemas de ejecucin simblica y medidores de cobertura han mostrado su utilidad en un marco ms amplio. Pero al final sigue siendo imprescindible un artista humano que sepa manejarlas.
4.5.10 Caso de Estudio: Pruebas 4.5.10.1 Pruebas Unitarias
Debido a que el software desarrollado es un prototipo cuyo fin es demostrar el objetivo del presente proyecto, la codificacin del mismo no evidencia necesariamente las tcnicas adecuadas de programacin, por tal motivo se opta por no realizar esta prueba, ya que se pueden detectar errores cuya presencia estn justificados por la necesidad de simplificacin del cdigo. 4.5.10.2 Pruebas de Integracin
Basndonos en la antes mencionada, no es posible desarrollar estas pruebas ya que no se realizaron las pruebas unitarias 4.5.10.3 Pruebas del Sistema
Se realiza este tipo de prueba considerando al sistema como una caja negra, a la cual se le proveen entradas y se esperan salidas determinadas, de acuerdo a la funcionalidad propuesta por el requisito desarrollado. Tal como lo establece el Caso de Uso Real, se proveen dos conjuntos de datos de entrada, especificados en la tabla de pruebas I (figura 51) y la tabla de pruebas II (figura 52), los cuales luego se vern reflejados en las figuras 53 y 54 que demuestran el ingreso de los mismos en el sistema. Los datos de salida esperados estn descriptos como sigue en la tabla de pruebas III (figura 55) y en la figura 56, se puede corroborar que la prueba se realiz correctamente:
136
Figura 51. Tabla de pruebas I
Figura 5 52. Tabla de pr ruebas II
137
Fi igura 53. Ingre eso de datos, ta abla de prueba as I
Figura 54. Ingres so de datos, ta abla de pruebas s II
138
Figura 5 55. Tabla de pr ruebas III
139
Figura 56. . Actividad de pruebas III
4.6 Implantacin
4.6.1
Descripc cin
a vez analiza ado, disead do, codificado o y probado el software, ste est lis sto para entrar en Una la fas se de Impla antacin. En n esta fase s se instala el software so obre la plata aforma (hard dware) final, se llevan a cabo los tes st de acepta acin especif ficados, y se e comprueba a que el prog grama face los requ uisitos para los l que fue c concebido. En E tales condiciones, el software rec cibe la satisf acept tacin provis sional, y com mienza su ope eracin y uso o. Dur rante la fase de implantacin se gene era el docum mento de imp plantacin, do onde se describen las a actualizacion nes de insta alacin y v verificacin realizadas, r as como e el documento de acept tacin provis sional.
140
A co ontinuacin se s resean algunos a aspe ectos de inte ers aplicable es a esta fas se: esarrollo. En las tcnicas t de aceptacin a p articipar el usuario y el equipo de de o del softwa Las pruebas de ace eptacin fallid das darn lug gar a cambio os en el dise are. La verif ficacin de que el softw ware cumple e los requis sitos definido os derivar en la aceptac cin provision nal del mism mo. El resul ltado de esta a fase incluir r el conjunt to de informe es de acepta acin, junto con c la docume entacin asociada a los c cambios realizados duran nte la fase.
Al im mplantar un Sistema de Informacin lo primero que q debemos s hacer es as segurarnos que q el Sistema sea oper racional, es decir, que fu uncione de acuerdo a a los s requerimie ntos del an lisis y dan operarlo o. permitir que los usuarios pued n, pero en cualquiera de Exis sten varios enfoques e de Implantacin e ellos se de ben mnimam mente consi iderar: Usar dif ferentes estr rategias para a el entrenam miento de los s usuarios. El Analista necesita a ponderar la a situacin y proponer un plan de co onversin qu ue sea adecuado para la or rganizacin. El Analista necesita a formular m medidas de desempeo con las cua ales evaluar a los Usuario os. Debe co onvertir fsica amente el sis stema de inf formacin antiguo, al nue evo modificad do. En la preparacin p de la Impl antacin, au unque el sis stema est bien disea ado y desarro ollado correc ctamente, su u xito depe ender de su u implantaci n por lo que es importante capacitar al usuario c con respecto o a su uso y mantenimien nto.
4.6.2
Capacita acin de Usu uarios del S Sistema
La c capacitacin n de usuarios s del sistema a es ensear r el manejo del d sistema a los usuario os que se relacionan u operan en un proceso de implantacin n
Capacitacin C d de Usuarios No N se debe in ncluir en una a misma capa acitacin a pe ersonas de dife erentes niveles s de habilidad d e intereses de d trabajo; deb bido a que si en e una Empre esa existen tr rabajadores in nexpertos no s se pueden incl luir en la mism ma seccin de d los expertos s ya que amb bos grupos que edarn perdid dos. "Es com mo querer con nducir dos B Barcos con dife erentes destin nos, con un mismo m Mapa de d rutas o con n el mismo timn".
141
Aun y cuando la Empresa pueda contratar los Servicios de Instructores externos, el analista es la persona que puede ofrecer la mejor capacitacin debido a que conoce el personal y el sistema mejor que cualquier otro. A la falta o imposibilidad del analista la organizacin puede contratar otros servicios de capacitacin como son: Vendedores: Son aquellos que proporcionan capacitacin gratuita fuera de la Empresa de uno o dos das. Instructor pagado externamente: Son aquellos que pueden ensear todo acerca de las computadoras pero para algunos usuarios esta no es una capacitacin necesaria. Instructores en casa: Estn familiarizados con el personal y pueden adecuar los materiales a sus necesidades, pero les falta experiencia en Sistemas de Informacin que es realmente la necesidad del usuario.
4.6.3
Objetivos de la Capacitacin
Es lograr que los usuarios tengan el dominio necesario de las cosas bsicas acerca de los procesos que se emplean para la operacin de manera eficiente y segura del sistema.
4.6.4
La Evaluacin del Sistema
Se lleva a cabo para identificar puntos dbiles y fuertes del Sistema implantado. La evaluacin ocurre a lo largo de cualquiera de las siguientes cuatro dimensiones: Evaluacin operacional: Se evala la manera en que funciona el Sistema, esto incluye su facilidad de uso, Tiempo de respuesta ante una necesidad o proceso, como se adecuan los formatos en que se presenta la Informacin, contabilidad global y su nivel de Utilidad. Impacto Organizacional: Identifica y mide los beneficios operacionales para la Empresa en reas tales como, Finanzas (Costes, Ingresos y Ganancias), eficiencia en el desempeo laboral e impacto competitivo, rapidez y organizacin en el flujo de informacin interna y externa. Desempeo del Desarrollo: Es la evaluacin del proceso de desarrollo adecuado tomando en cuenta ciertos criterios, como tiempo y esfuerzo que concuerden con presupuesto y estndares y otros criterios de Administracin de Proyectos. Adems se incluyen la valoracin de los mtodos y las herramientas utilizados durante el desarrollo del Sistema.
142
4.6.5
Control de configuracin en la fase de implantacin
En un proyecto de este tipo, todos los elementos y componentes relacionados con el desarrollo del software deben ser objeto de control de configuracin, y estar sometidos a los procedimientos y normas relacionados con el mismo. Cada elemento de configuracin estar identificado unvocamente, y definido por su propsito, su funcionalidad, sus requisitos y sus interfaces, indicando para cada uno el nmero de versin (y revisin) actual. Como se dijo ya en esta fase: Las pruebas de aceptacin fallidas darn lugar a cambios. ... , cada vez que alguna de las partes (cliente, equipo de trabajo, usuarios) detecte algn fallo o disconformidad en el software o en la documentacin generada. Es conveniente generar, como parte de las actividades de control de configuracin, una hoja de notificacin de disconformidad, donde se refleje y describa la misma, la solucin recomendada y la solucin adoptada. La figura 57 muestra un modelo de notificacin utilizado.
Notificacin de disconformidad
Nota N Fecha : Autor :
PROYECTO
Elemento : Referencia : Edicin-versin / revisin: Localizacin del problema :
Descripcin del problema :
Solucin reco mendada :
Respuesta del autor :
Estado de la disconfo rmidad CERRAR SEGUIR ACCION
Figura 57. Notificacin de disconformidad
La notificacin de una incidencia o disconformidad dar lugar, por lo general, a una actuacin que responda y (en su caso) resuelva la misma. A menudo pasar por introducir cambios en
143
alguno de los elementos de configuracin (cdigo o documentacin). Considerar
adecuadamente dichos cambios es vital. Como respuesta al cambio mismo, se generar un documento en el que se documenten los cambios realizados, informe de modificacin, el responsable y la fecha, as como las razones y el esfuerzo asociado a las mismas.
En la figura 58 se muestra un posible formato para dicho informe.

Informe de Modificacin del Software
Inf. N Fecha : Autor :
PROYECTO
Elemento : Referencia : Edicin-versin / revisin: Cambios implantados :
Razones del cambio :
Fechas de comienzo y fin del cambio, y esfuerzo necesario :
Documentacin adjunta Cdigo fuente Resultados de test Procedimiento de prueba Documentacin adicional Datos test Otros
Figura 58. Informe de modificacin de software
Junto con el software, tambin los documentos del proyecto sufrirn modificaciones. Un cambio en el software originado por una notificacin de disconformidad puede obligar a revisar y actualizar todo el rbol de documentacin del proyecto. Cada elemento objeto de control de configuracin es acompaado por una hoja de control de configuracin, y sirve para reflejar qu versin se est manejando actualmente, y qu cambios y modificaciones incluye con respecto a ediciones anteriores.
En esta figura 59 se muestra el posible formato de dicho documento:
144
Hoja de d estado del doc cumento
PROYEC CTO : DOCU UMENTO

Referencia : Ttulo :
Pg. . 1 de n
Edicin
Revisin
Fe echa
Pgina(s) Afectad da(s)
Razn del d cambio
Figura 59. Ho oja de estado del d documento
Ap probacin de cambios incorporados onsensuada y aprobada La documentaciin presentada debe ser co por el e responsable e de la empres sa del proyect to, de manera a que: o Plasme la a evolucin de e las diferente es versiones y revisiones de cada element to configurable e. o bilidades der rivadas de Dirimir a posteriori las responsab cam mbios (o no ca ambios) llevad dos adelante. o Controlar todas las disconformida d ades y docu umentar el proceso y resoluc cin de las mi ismas.
4.6.6
Tareas Usuales U de la a Implantac cin del Sist tema Instalac cin del hardw ware y softw ware nuevo. Formar a los primer ros usuarios y operadores. gencia, recuperacin y cada. Desarro ollar los plane es de conting Desarro ollar los procedimientos d de mantenim miento y versiones. Establecer procedim mientos para : o o Versiones regulares. d emergenc cia. Versiones de
145
o Versin por configuracin (hardware o estaciones de trabajo).
Llevar a cabo cualquier conversin de datos necesaria. Llevar a cabo la instalacin del sistema nuevo a produccin. o o o Instalacin completa desde cero. Instalacin en paralelo. Instalacin por fases.
Comenzar el uso de los acuerdos de nivel de servicio. Planificar y programar las revisiones post-instalacin: o Establecer los criterios de: Rendimiento del sistema. Calidad del sistema. Satisfaccin del usuario. Calidad y facilidad de manejo de: Manuales de usuario y operador. Formacin de usuarios y operadores. Informacin y datos producidos.
Fluidez de la instalacin. Costes de desarrollo, instalacin, operaciones y mantenimiento. Establecer la planificacin y calendario para las revisiones. Asegurar la disponibilidad de: Personal requerido. Documentacin requerida.
Llevar a cabo las revisiones post-instalacin: o o Crear el informe de la revisin post-instalacin. Obtener la aprobacin firmada de los informes de: Usuarios finales del sistema. Operadores del sistema. Auditora y garanta de la calidad. Desarrollo de sistemas. Soporte de sistemas y mantenimiento.
146
o Finanzas.
Obtener la carta de aprobacin del sistema.
Establecer el calendario para otras revisiones post-instalacin si es necesario.
4.7 Conclusin del Proyecto

4.7.1 Descripcin
Una vez finalizado el proyecto, parece evidente la necesidad de analizar los resultados y recapitular el curso de los hechos para hacerse una idea clara de los objetivos cumplidos, de los que no se han alcanzado, y de la utilidad futura en otros proyectos, del trabajo realizado.
4.7.2
Objetivos del cierre del Proyecto
Segn Domingo Ajenjo, a grandes rasgos el cierre del proyecto tiene como objetivo principal: Analizar desde la perspectiva econmica el resultado del proyecto, es decir, hacer balance de los recursos consumidos y los beneficios alcanzados. Diagnosticar el funcionamiento de la empresa, identificando las desviaciones entre el resultado y las previsiones iniciales, y encontrando las razones de dichas desviaciones. Corregir, para futuros proyectos, las actuaciones inadecuadas que dieron lugar a las desviaciones anteriores.
Y como objetivos secundarios: Consolidar como parte del know-how de la empresa los resultados tcnicos del proyecto, incluyendo los conocimientos adquiridos, la tecnologa utilizada, la documentacin y los productos desarrollados., etc. Identificar las nuevas oportunidades comerciales nacidas de la ejecucin del proyecto recin terminado, y organizar las actividades comerciales precisas para dar continuidad, mediante nuevos contratos, al proyecto anterior.
Asimismo para alcanzar la conclusin efectiva del proyecto se debe considerar: 1) La ACEPTACION: El proyecto no puede darse por terminado hasta que el Cliente revise y acepte el resultado del mismo. 2) Se debe crear un INFORME DE CIERRE DEL PROYECTO: Es en teora la ltima documentacin del proyecto. Es como una foto de fin de curso en la que se aprecia
147
quin termina y quin no (adems, por las caras uno puede llegar a intuir si el curso fue bueno o malo). 3) Realizar un anlisis de INDICADORES OBJETIVOS DEL RESULTADO DEL PROYECTO: Lo ms probable es que la documentacin de cierre del proyecto se curse, de oficio, a los responsables de la empresa, quienes la analizarn en busca de estos indicadores para evaluar la marcha de los proyectos.
En esta fase se trata de dar por finalizado el proyecto y entregar el producto definitivamente al cliente. Las principales actividades a realizar son estas: Revisar las desviaciones del proyecto e identificarlas para evitarlas en futuros proyectos. Reasignar el personal a los nuevos proyectos o reintegrarlos en los departamentos de partida. Es interesante documentar las relaciones entre los empleados para futuros proyectos.
4.7.3
Acciones a seguir por el director del proyecto para efectivamente concluir con el proyecto 1. El director deber ir cancelando relaciones con proveedores. 2. Respecto de los recursos humanos, deber ir dejando sin efecto los vnculos generados entre dichos recursos y las actividades asignadas en este proyecto, liberndolos para otros proyectos. 3. Una vez realizado el punto anterior el director solicitar al cliente la aceptacin del proyecto. 4. Deber adems poner a disposicin del cliente de forma ordenada y accesible toda la informacin relativa al proyecto. 5. El director de proyecto llevar adelante una reunin, con informe final, aceptacin y algn documento para formalizar esta fase del proyecto (tipo acta de cierre). En esta reunin se firmar este documento aceptando ambas partes que se cumpli con lo establecido. 6. Se darn por finalizadas las relaciones internas y externas vinculadas al proyecto.
J.Meredith y S. Mantel en 1989 describen en su trabajo tres formas de concluir un proyecto: Por extincin, donde el proyecto ah sido llevado a cabo, de forma exitosa o habiendo fracasado y se ah acordado su finalizacin.
148
Por inc clusin, gen neralmente se supone que el proy yecto ah sid do un xito y se institucionaliza en la organizac cin. En este caso el proyecto es s visto como o una transfor rmacin. Cob bra mucha im mportancia el proceso de e transicin d del proyecto.
Por int tegracin, supone s gene eralmente la distribucin del person nal, el equipo o y el material en la organ nizacin princ cipal.
La labor del Di irector de Proyectos en cuanto a la a conclusin n es muy int tensa, as que es rtante tener presente el tipo de conc clusin para poder anticiparse a las tareas. Asim mismo impor no de ebe conform marse con haber finaliza ado el proye ecto, siempre e debe pens sar cmo hacerlo mejor r, ya sea po orque existen nuevas op portunidad siguiendo s la evolucin d del proyecto en la organ nizacin donde se ah imp plantado, o b bien porque otros o clientes s pueden so olicitar algo similar. Adem ms siempre e debe ser creativo, a aplicando nu uevos mode elo y tecnollogas adap ptando difere entes solucio ones a los problemas q que surjan, cualquier cosa que ha aga mejor la a idea origin nal, ms efic caz y ms rentable (m mejores resultados a un n menor cos sto), le perm mitirn desar rrollar sus co ompetencias al mximo p preparndolo o para los vertiginosos fu uturos desafo os.
Concluir C el pr royecto sin so obresaltos Es E altamente r recomendable e dejar bien establecidos, e d de manera con ncreta y sin n ambigedad des los requ uisitos de la a solucin ado optada, y su a aprobacin po or parte del cl liente de man nera escrita por r medio de alg gn documen nto. Sin este re equisito sera muy difcil llev var adelante una conclusi in efectiva del d proyecto, ya que el clie ente podra so olicitar mejoras s de manera in nfinita.
4.8 M Mantenimiento
4.8.1
Descripc cin
mantenimien nto del software es una de las activi idades ms comunes en n la ingenier ra del El m softw ware. Es el proceso p de mejora y op ptimizacin del software e despus d de su entre ega al usuar rio final (es decir; d revisi n del progra ama), as como tambin la correccin n y prevenci in de los de efectos. Es importante re ecordar:
El proyecto no finaliza cuan ndo se entre ega el produc cto, sino cuan ndo el cliente e est satisfe echo. (C Craig Larman)
Des sarrollar un mantenimien m nto efectivo d del software es una de la as bases pa ra obtener un u alto grado o de satisfac ccin del clie ente. El mant tenimiento de software es e una de las s fases en el e ciclo de vida de desa arrollo de sistemas, qu ue se aplica a al desarro ollo de softw ware. La fas se de s la fase que e viene despu us de la imp plantacin. mantenimiento es
149
Mantenimien M nto del softwa are El mantenimiiento del sof ftware puede entenderse como el "p proceso de m modificar un sistema o componente software de espus de la a entrega al l cliente o usuario, u para corregir de efectos, mejo orar el rendim miento o atrib butos, adapta arlo a un ca ambio de ento orno, o ampliar r su funcionali idad" [IEEE, 19 990].
Dur rante este ca aptulo vamo os a describir r la informac cin ms imp portante a te ener en cuenta por un Director de Pr royectos Info ormticos en n la fase de mantenimien nto. No se pr rofundizar en e las cas o meto odologas para p realiza ar el mante enimiento del software , sino que solo tcnic consi iderarn los puntos ms importantes para la Direccin de Pro oyectos Infor rmticos.
Un na vez que un n sistema pa asa a formar r parte de la vida diaria de la empresa a, cada prog grama, cada procedimien nto y cada estructura e de e datos, se convierte en n una pieza del negocio o que, o tal, deber funcionar en e forma con nstante, exacta y confiab ble. La oper racin del ne egocio como ahora a depender del funcion namiento de el sistema, por p lo que las tareas d de mantenim miento cobra an vital impo ortancia. Dur rante la fase e de manten nimiento, se ponen en p prctica toda as las poltic cas y los pr rocedimientos destinados s a garantiz zar la operac cin contina a de los sistemas para asegurar su u uso efectivo, con el fin de que stos se co onstituyan e en una verd dadera herra amienta de ap poyo al logro o de los obje etivos estrat gicos de la empresa. e (L Lloren Fbreg gas)
a vez que el nuevo siste ema est op perativo, el auditor a de sistemas inde ependiente de d las Una otras fases de la vida del siste ema, revisar r lo siguiente e:
-
Determinar si el programa ha logrado los requerimientos de los o objetivos; se debe encin a la u utilizacin y la satisfaccin de los us suarios finale es, ya prestar especial ate os constituir n un indicad dor excelente e. que ello
Verificar que se miden, m anali zan e infor rman adecuadamente a la gerencia los ios identificados con el e estudio de fac ctibilidad. benefici
Revisar r las solicitu udes de cam mbios a los programas que se ha an realizado, , para evaluar el tipo de ca ambios que s se exigen al sistema, el tipo de camb bios puede indicar mas de diseo, programa acin o interp pretacin de los requerim mientos de us suario. problem
antenimiento o involucra c cambios en el software e con el obj bjetivo de co orregir La fase de ma ctos y dependencias enc contradas du rante su uso o, aadir nue eva funcionallidad para mejorar m defec la usa abilidad y ap plicabilidad del software. En un ambiente formal de desarrollo de software e, la organizacin o equ uipo de desa arrollo r algn mec canismo par ra document tar y rastrea ar defectos y deficiencia as. El softwa are, al tendr igual que otros productos, generalmen nte es entregado con un conjunto to de defec ctos y iencias. Las s deficiencias s conocidas s son norma almente doc cumentadas en una car rta de defici consi ideraciones operacionale es o notas d de entrega. As que los s usuarios d del software sern
150
capac ces de trab bajar evitand do las defic ciencias conocidas y co onocern cu undo el us so del softw ware sera ina adecuado pa ara tareas es specficas. Las s personas involucradas en la fase de mantenimiento del software es peran trabaj jar en estos s defectos co onocidos, ubi icarlos, y pre eparar una nueva entrega a del softwar re, conocido como una v versin de mantenimiento o, la cual res solver los te emas pendientes.
4.8.2
Tipos de e Mantenimie ento
A c continuacin se sealan los tipos de e mantenimie entos existentes, definid dos tal y com mo se espec cifican para la metodolog ga MTRICA A v3: Perfect tivo: son las s acciones lle evadas a ca abo para mejorar la calid dad interna de d los sistema as en cualquiera de sus aspectos: re eestructuraci in del cdig go, definicin n ms clara de el sistema y optimizacin o n del rendimie ento y eficien ncia. Evolutivo: son las incorporacio ones, modific caciones y eliminaciones necesarias en un to software para p cubrir la expansin o cambio en las necesida ades del usuario. product Adapta ativo: son las s modificacio ones que afe ectan a los entornos e en llos que el sis stema opera, por ejemplo o, cambios de configur racin del hardware, h so oftware de base, gestores de base de e datos, com municaciones s, etc. Correct tivo: son aquellos a cam mbios precis sos para corregir erro res del pro oducto software e. Cab be sealar que, de estos s 4 tipos de mantenimiento, solamen nte el correc ctivo y el evo olutivo entra an en el mbito de MT TRICA versiin 3, ya qu ue los otros dos requie eren activida ades y perfile es distintos a los del proc ceso de desa arrollo.
Figura 60. Costes rela ativos a cada tipo t de manten nimiento
151
Segn la definicin anterior existen diferentes tipos de mantenimiento, como se puede apreciar en figura anterior, la cual representa los tipos de mantenimiento y los costes relativos. Si dentro de los costes globales de mantenimiento hacemos un estudio de los costes asociados a cada tipo de mantenimiento, comprobamos que el mantenimiento correctivo no es la actividad que consume ms recursos. La mayora de los estudios han identificado el mantenimiento perfectivo como la actividad dominante en los centros de proceso de datos. Si analizamos las actividades que deben realizar los programadores, podemos fijarnos en las siguientes: Estudiar las peticiones. Estudiar la documentacin. Estudiar el cdigo. Implementar el cambio. Realizar Pruebas. Actualizar la documentacin del programa.
4.8.3
Distribucin del Coste
Vamos a ver la importancia de la fase de mantenimiento. Los modelos del ciclo de vida tradicionales representan el mantenimiento como una fase que comienza una vez que se han finalizado las pruebas. Multitud de estudios indican que es la fase ms costosa del ciclo de vida del software, lo que da lugar a que la mayor parte del presupuesto de los centros de proceso de datos (CPD) se destine a mantener los sistemas existentes. Algunos estudios ya sealaban, en 1987, que el 80% del presupuesto de los CPD se dedicaba a actividades de mantenimiento, y que en 1995 poda alcanzar el 95%. Algunas empresas han sobrepasado este porcentaje hasta llegar al lmite de recursos (lo que se ha denominado barrera de mantenimiento), imposibilitando nuevos desarrollos. Por ello, podemos asegurar que el mantenimiento es la fase dominante del ciclo de vida.
152
Figura 61. C Costes relativos s a cada fase
4.8.4
Factores s que afectan al coste
Vea amos alguno os factores qu ue afectan d irectamente a estos cost tes: Inexiste encia de los mtodos, tcnicas y herramientas que pue edan proporc cionar una solucin global de mantenim miento. Los ciclos de vida del softwa are y, por lo tanto t , etodologas de desarrol lo que los siguen, no o reflejan la a importanci ia del las me mantenimiento en trminos de e c necesa arios ni de la as actividade es que esfuerzo y coste e realizar dur rante esta fa ase. En la actualidad, pr cticamente t todos los m todos hay que existent tes se centr ran en el d esarrollo de e nuevos sis stemas en v vez de repa arar o mejorar r los sistemas existentes. . La com mplejidad de los sistema as se increm menta paulatinamente po or la realizaci in de continua as modificac ciones. Adem ms, durante la vida de un u sistema ha ay una prdi ida de informacin, puesto que cada ve ez hay meno os personas que conocen n el software e. La documentacin n del sistem ma es defectuosa o inex xistente. En el caso de existir, e s veces no se s actualiza a medida qu ue cambia el sistema. La a programacin es muchas de baja a calidad; muchas m vec ces no es estructurada e y/o no sig gue ningn estilo estanda arizado. Se con nsidera el mantenimien m nto como un na actividad d poco crea ativa; a diferencia del desarrollo, y, po or lo tanto, m ms sencilla y menos imp portante, que e puede realizarse rsonal con menor expe eriencia, me enor soporte e de herram mientas y menor m por per esfuerzo de gestin n. No es rar ro descubrir que la prime era actividad d que realiza an los ores contrata ados por las empresas suele s ser el mantenimien nto de nuevos programado as, a pesar del desconociimiento de lo os mismos. sistema Las act tividades del mantenim miento se suelen s realiz zar bajo pre esin de tie empo. Normalm mente los pr rogramadore es (ya que el e mantenimie ento siempre e se realiza sobre cdigo) tienen poco o tiempo para a realizar las s modificacio ones, por lo q que a veces no se
153
actualiz za la docum mentacin. L Las correcc ciones imper rfectas dan lugar a nuevos esfuerzos de correc ccin de futur ro. Poca participacin p n del usuar rio durante el desarro ollo del sist tema. Cuando se entrega a el sistema al a usuario, no o satisface sus s necesidades, lo que d da lugar a un n gran esfuerzo de manten nimiento post terior.
Ef fecto Iceberg g Es importante te ener en cuent ta el Efecto Iceberg, es d decir, en el mento que se e hace el mantenimiento m no se cuentta muchas mom vece es con el fac ctor econmic co (Cunto dinero d se inve ertir en el man ntenimiento?), , y una vez se s comienza a desarrollar la fase de man ntenimiento e en la aplica acin, comien nzan a surg gir nuevos requerimie entos, el efecto del iceberg g (en la super rficie se ve solo una parte e de lo que realmente es su tamao o).
4.8.5
Distribuc cin del Tiem mpo
s actividades pueden agruparse en fu unciones ms s genricas, como: Las Compre ensin del software y de e los cambio os que hay que realizar r: un program mador que qu uiera cambia ar el softwa re necesita comprenderlo (conocer r el propsito, la estructu ura interna, los requisito os de operac cin...). En caso c contrari rio, existe un n gran riesgo de d introducir nuevos defe ectos que, adems, a son los ms cos stosos de re eparar. Como veremos v en la figura sigu uiente gran parte p del tiem mpo se dedic ca al estudio o para comprender el softw ware, por lo que la utiliza acin de cua alquier herram mienta que ayude a ble la prod uctividad de los a este propsito aumentar de forma considerab madores. program Modifica acin del software in ncorporando los cambios: implica a la creaci in y modifica acin de estructuras de datos, lgica a de proceso o, interfaces, , etc., as co omo la actualiz zacin de la documentaci d in. Los prog gramadores se deben as segurar de que los cambios s no afectarn a la co oherencia de el programa y que no incrementar n su complej jidad. En de efinitiva, deb ben conocer su impacto sobre el sis stema para evitar posibles s efectos late erales. Realizacin de prue ebas para v validar los ca ambios: se debe d compro obar la corre eccin ware despu s de realiza ar cualquier cambio c mediante la realiz zacin de pruebas del softw selectiv vas. Pensar que un peq queo cambio no neces sita la realiza acin de pruebas puede acarrear a grav ves problema as de calidad d y de fiabilid dad.
154
Figura 62. Distribuc cin del tiempo de Mantenim miento
4.8.6
Tareas Usuales U en la a fase de Ma antenimient to Implementar los cam mbios del sis stema: o o edimientos d de implementacin de versiones, o Utilizar los proce plementar ve ersiones de emergencia y despus utilizar los p procedimient tos de Imp vers siones forma ales de forma a retroactiva. ontina solucionando las Asegura arse de que el sistema co s necesidade es de los usu uarios: o o o o o Utilizar los acue erdos de nive eles de soportes. visiones regu ulares de req querimientos del nivel de acuerdo. Rev Rev visiones regu ulares de cm mo el sistema est alcanzando sus o objetivos. Llev var a cabo re evisiones reg gulares del sistema. Utilizar los proce edimientos y contenido de d las revisio ones post ins stalacin.
CAPTULO V. GESTIN DE RIESGOS
El significado de la vida no es la seguridad, las grandes oportunidades son arriesgadas. (Shirley Hufstedler)
5.1 Descripcin
La Gestin de los Riesgos del Proyecto incluye los procesos relacionados con llevar a cabo la planificacin de la gestin, la identificacin, el anlisis, la planificacin de respuesta a los riesgos, as como su monitoreo y control en el proyecto. Los objetivos de la Gestin de los Riesgos del Proyecto son aumentar la probabilidad y el impacto de eventos positivos, y disminuir la probabilidad y el impacto de eventos negativos en el proyecto.
Actividad Planificar la Gestin de Riesgos Identificar Riesgos Descripcin Proceso por el cual se define cmo realizar las actividades de gestin de riesgos para un proyecto. Proceso por el cual se determinan los riesgos que pueden afectar al proyecto y se documentan sus caractersticas. Proceso que consiste en priorizar los riesgos para realizar otros anlisis o acciones posteriores, evaluando y combinando la probabilidad de ocurrencia y el impacto de dichos riesgos. El anlisis deber ser cualitativo en todos los casos, y en algunos casos tambin deber ser cuantitativo. Proceso por el cual se desarrollan opciones y acciones para mejorar las oportunidades y reducir las amenazas a los objetivos del proyecto. Proceso por el cual se implementan planes de respuesta a los riesgos, se rastrean los riesgos identificados, se monitorean los riesgos residuales, se identifican nuevos riesgos y se evala la efectividad del proceso contra riesgos a travs del proyecto.
Figura 63. Actividades en la gestin de riesgos
Realizar Anlisis de Riesgos
Planificar la Respuesta a los Riesgos Seguimiento y Control de los Riesgos
Estos procesos interactan entre s y con los procesos de las otras reas de conocimiento. Cada proceso puede implicar el esfuerzo de una o ms personas, dependiendo de las necesidades del proyecto. Cada proceso se ejecuta por lo menos una vez en cada proyecto y en una o ms fases del proyecto, en caso de que el mismo est dividido en fases. Aunque los procesos se presentan aqu como elementos diferenciados con interfaces bien definidas, en la prctica se superponen e interactan de formas que no se detallan aqu.
157
Riesgo Un riesgo es s un evento o condicin inc cierta que, si sucede, tie ene un efect to en por lo menos uno de los objetiivos del proyecto. Los riesgos de un n proyecto se ubican siemp pre en el fu uturo. Los obje jetivos pueden n incluir el alcance, el crono ograma, el coste y la ca alidad.
e tener una o ms causa as y, si suced de, uno o m s impactos. Una causa puede p Un riesgo puede un requisito, un supues sto, una rest triccin o una condicin n que crea la posibilida ad de ser u conse ecuencias ta anto negativa as como pos itivas. Por ejemplo, la causa podra s ser contar co on una cantid dad limitada de personal asignado pa ara el anlisi is del proyec cto. El evento o de riesgo es e que un an nalista funcio onal abandon ne el proyec cto, y por con nsiguiente la cantidad lim mitada de personal dispo onible asigna ado al proyec cto sea meno or a la planif ficada, afecta ando a los tie empos destinados al an lisis del pro oyecto. Si a alguno de estos e eventos inciertos s se produce, puede habe er un impact cto en el cos ste, el crono ograma o en e el desem mpeo del p proyecto. La as condiciones de riesg go podran incluir aspec ctos del ento orno del proy yecto o de la a organizaci n que puede en contribuir a poner en riesgo el pro oyecto, tales s como prcticas deficien ntes de direc ccin de proy yectos, la fallta de sistem mas de gesti n integrado os, la concu urrencia de varios proye ectos o la dependencia d a de particip pantes externos que no pueden p ser controlados. c s riesgos de el proyecto o tienen su origen en la l incertidumbre que e est presen nte en Los todos s los proye ectos. Los riesgos con nocidos son n aqullos que q han sid do identificad dos y analiz zados, lo que q hace posible p plan nificar respu uestas para tales riesg gos. Los riesgos desco onocidos especficos no pueden ges stionarse de e manera pro oactiva, lo q ue sugiere que q el equip po del proye ecto debe crear c un pla n de contin ngencia. Un riesgo del proyecto, qu ue ha ocurr rido, tambin n puede cons siderarse un problema. Exis ste un ambie ente de ince ertidumbre cuando falta a el conocim miento seguro o y claro res specto del desenlace o consecuenci c ias futuras d de alguna ac ccin o situacin, lo que puede deriv var en o cuando se s aprecia la a perspectiv va de una contingencia c a con posibiilidad de ge enerar riesgo prdidas o la prox ximidad de un u dao. La i incertidumb bre supone cuantificar c h hechos med diante maciones pa ara reducir riesgos futu uros, y aunq que su estim macin sea d difcil no justificar estim su fal lta de informacin. El r riesgo supo one un hec cho externo o, que pued de acontece er o no en algn mom mento deter rminado. Po or lo que el riesgo pued de ser conte emplado com mo elemento o de incertidu umbre que p puede afecta ar a la activ vidad empres sarial, pudie endo ser motivado por c causas exter rnas o intern nas a la emp presa. La incertidumbr re vara para a cada sujeto o y para cad da actividad a desarrolla ar. Esta diferencia tativa y cuan ntitativa de intensidad d de la incertid dumbre se encuentra e re elacionada con c el cualit grado o de informa acin e identificacin de el problema. La nica fo orma de redu ucir el riesgo o o al
158
meno os sus conse ecuencias, se consigue m mediante su identificaci n lo ms cla ara posible, lo l que permite poner en e marcha todas aquelllas accione es necesaria as para inte entar anular rlos o mizarlos con el uso de lo os conocimie entos y de las tcnicas que han serviido para con nvertir, minim en algn grado, los riesgos en e previsibles s. Por lo que e riesgo tambin se pued de definir co omo la acin econmica de la in ncertidumbre e. valora
La as organizacio iones y el ries sgo as organizacio ones perciben n los riesgos s como el efe fecto de la La incertidumbre sob bre los objetivo os del proyect to y de la orga anizacin.
Las s personas y los grupos adoptan a actiitudes frente e al riesgo qu ue influencia an la forma en e que respo onden a ello os. Estas actitudes fren nte al riesgo o son motiv vadas por la a percepcin, las tolera ancias y otras predisposic ciones, que d deben hacer rse explcitas s siempre qu ue sea posibl le. Deb be desarrolla arse un mtodo coheren nte en mate eria de riesgo os para cad da proyecto o, y la comu unicacin sobre el riesgo o y su gesti n debe ser r abierta y honesta. h Las s respuestas a los riesgo os reflejan el equilibrio percibido por una organiza acin entre tomar t y evita ar los riesgos s.
Tolerancia de e riesgo Las organiza aciones y lo os interesado os estn disp puestos a ceptar diferent tes niveles de e riesgo. Los riesgos que c constituyen ac un na amenaza p para el proyect to pueden ace eptarse si se e encuentran de entro de los l mites de tolerancia y si es stn en equilib brio con el be eneficio que puede obten nerse al tomarlos. Por ej ejemplo, la ad dopcin de un n cronograma de ejecucin rpida es un riesgo que se corre para p obtener el e beneficio de e una fecha de e finalizacin ms m temprana a.
Par ra tener xito o, la organiz zacin debe compromete erse a tratar la gestin d de riesgos de una mane era proactiva a y consistente a lo largo del proyecto o. Debe hace erse una elec ccin conscie ente a todos s los niveles de la organizacin para identificar activamente a y perseguir u una gestin eficaz duran nte la vida del d proyecto. Los riesgo os existen desde el mom mento en qu ue se concibe un proye ecto. Avanza ar en un proyecto sin ad doptar un enfoque proactivo en mate eria de gestin de riesgo os aumenta el impacto que q puede te ener la mater rializacin de e un riesgo s sobre el proyecto y que, potencialmente, podra conducirlo c al fracaso.
5.2 P Planificacin de la Gestin G de e Riesgos s
nificar la Ge estin de Riesgos R es e el proceso por el cual se define c cmo realiza ar las Plan actividades de gestin de rie esgos para un proyecto o. Una planif ficacin cuid dadosa y ex xplcita
159
mejor ra la probabilidad de xit to de los otro os procesos de gestin de d riesgos. L La planificacin de los p procesos de gestin de riesgos es importante para asegurar que el n o y la nivel, el tipo visibilidad de ges stin de riesgos sean ac cordes tanto con los ries sgos como c con la impor rtancia royecto para a la organizac cin. del pr
Im mportancia d de la planifica acion de la Ge estion de Rie esgos
La planificaci n de los pr rocesos de gestin g de r riesgos es imp portante para asegurar qu ue el nivel, el tipo y la visi sibilidad de ges stin de riesgo os sean acord des tanto con los riesgos co omo con la imp portancia del proyecto pa ara la organiz zacin. La pla lanificacin tam mbin es impo ortante para proporcionar p lo os recursos y el tiempo suficientes s para las ac ctividades de gestin de riesgos r y par ra establecer una base acordada para evaluar los riesgos.
El p proceso Pla anificar la Gestin de R Riesgos debe iniciarse tan t pronto c como se co oncibe el pro oyecto y debe completa arse en las f ranas de pla anificacin d del mismo. fases tempr En la Planificac cin de la Ge estin de Rie esgos se es stablecen los s criterios qu ue sern utilizados d Riesgos y la forma en n que sern llevados ade elante los de ems proces sos de para la Gestin de in de Riesgos durante el e proyecto. Gesti La p planificacin de la Gesti n del Riesgo o incluye la definicin d de: Metodologa. Respon nsables. Frecuen ncia. Categor ras de Riesg gos. Definicin de probabilidad e imp pacto. Toleran ncia de riesgo os.
5.3 I Identificac cin de Riesgos
ntificar los Riesgos R es el proceso por r el cual se determinan d lo os riesgos qu ue pueden afectar a Iden el pro oyecto y se e documenta an sus cara ctersticas. Entre las pe ersonas que e participan en la identi ificacin de riesgos r se pueden incluir o, los miemb bros del equipo del r: el director del proyecto proye ecto, el equipo de gesti n de riesgo os (si est as signado), clientes, exper m rtos en la materia externos al equip po del proyecto, usuarios s finales, otr ros directore es del proyec cto, interesa ados y rtos en gesti in de riesgo os. Si bien es stas persona as son a menudo particip pantes clave e en la exper
160
identificacin de riesgos, se debera fomentar la identificacin de riesgos por parte de todo el personal del proyecto. Identificar los Riesgos es un proceso iterativo debido a que se pueden descubrir nuevos riesgos o pueden evolucionar conforme el proyecto avanza a lo largo de su ciclo de vida. La frecuencia de iteracin y quines participan en cada ciclo vara de una situacin a otra. El formato de las declaraciones de riesgos debe ser consistente para asegurar la capacidad de comparar el efecto relativo de un evento de riesgo con otros eventos en el marco del proyecto. El proceso debe involucrar al equipo del proyecto de modo que pueda desarrollar y mantener un sentido de propiedad y responsabilidad por los riesgos y las acciones de respuesta asociadas. Los interesados externos al equipo del proyecto pueden proporcionar informacin objetiva adicional. Para favorecer un proceso completo y sistemtico de identificacin de riesgos se sugiere el uso de una estructura de categora de riesgos como las que se detalla en la figura 64: Categora De la Organizacin Descripcin Dependencias del Proyecto Recursos Financiacin Priorizacin Estimacin Planificacin Control Comunicacin Requisitos Tecnologa Complejidad e interfaces Rendimiento y Fiabilidad Calidad Subcontratistas y Proveedores Regulatorio Mercado Cliente Condiciones Climticas
Direccin de Proyectos
Tcnico
Externo
Figura 64. Estructura de categora de riesgos
5.4 Anlisis de Riesgos
Los riesgos pueden ser analizados de manera cualitativa o cuantitativa. Realizar el Anlisis Cualitativo de Riesgos es el proceso que consiste en priorizar los riesgos para realizar otros anlisis o acciones posteriores, evaluando y combinando la probabilidad de ocurrencia y el impacto de dichos riesgos.
161
Figura 6 65. Anlisis de Riesgos
s organizacio ones pueden mejorar e el desempeo del proy yecto conce ntrndose en e los Las riesgo os de alta prioridad. El l proceso R Realizar el Anlisis A Cualitativo de R Riesgos evala la prioridad de los riesgos r ident tificados usa ando la probabilidad relativa de ocur rrencia, el im mpacto espondiente sobre los ob bjetivos del proyecto si los riesgos se s presentan n, as como otros corre factor res, tales como el plazo de respuest ta y la tolerancia al riesgo por parte d de la organiz zacin asoci iados con la as restriccio ones del pro oyecto en cuanto c a costes, cronog grama, alcance y calida ad. Estas evaluaciones reflejan r la act ctitud frente a los riesgos, tanto del eq quipo del pro oyecto como o de otros interesados. Por lo tan nto, una eva aluacin efic caz requiere e la identific cacin explc cita y la gestin de las actitudes a fren nte al riesgo por parte de e los particip pantes clave e en el marco del proces so Realizar el e Anlisis Cu ualitativo de Riesgos. Cu uando estas actitudes fre ente al riesgo o introducen n parcialidad des en la ev valuacin de e los riesgos s identificado os, debe po onerse atenc cin en evalu uar dicha par rcialidad y en n corregirla. La definicin de niveles de probab bilidad e im mpacto pued de reducir la influencia de alidades. La criticidad te emporal de a acciones rela acionadas co on riesgos pu uede magnificar la parcia impor rtancia de un riesgo. Un na evaluacin n de la calid dad de la info ormacin dis sponible sob bre los riesgo os del proye ecto tambin ayuda a cla arificar la eva aluacin de la importanc cia del riesgo o para el pro oyecto.
162
Figura F 66. Prob babilidad de Impacto de Riesg go
v claramen nte cmo se e puede cla asificar los riesgos seg gn la En la figura anterior se ve proba abilidad de ocurrencia o e impacto en l a organizacin. Un riesgo muy frecue ente que ten nga un impac cto muy alto en la organizacin, seg uramente se er valuado con c una pun ntuacin alta (zona roja e en la figura), lo que indica a que deber ser tratado o de alguna manera. m
Beneficios B de el Analisis Cu ualitativo de Riesgos R Realizar R el An nlisis Cualitat tivo de Riesgo os es por lo g general un me edio rpido y econmico de establecer prioridade es para la pla anificacin de la respuesta a los riesgos, y sienta las b bases para rea alizar el anllisis cuantitat tivo de riesgos, si se re equiere. El pro oceso Realiza ar el Anlisis s Cualitativo de Riesgos debe ser revisado durante el ciclo c de vida del proyecto o para mante enerlo actuallizado con respecto a los cambios en los riesgos s del proyecto o.
Rea alizar el An lisis Cualita ativo de Ries sgos puede conducir al proceso Re ealizar el An nlisis Cuan ntitativo de Riesgos R o dire ectamente all proceso Pla anificar la Re espuesta a lo os Riesgos.
Analisis A Cuan ntitativo de Ri iesgos
Realizar R el An nlisis Cuantit tativo de Ries sgos es el pro oceso que con nsiste en an alizar numri ricamente el efecto de lo os riesgos identificados sob bre los objetivo os generales del d proyecto.
5.5. Planificar r la respue esta a los riesgos
nificar la Re espuesta a lo os Riesgos es el proceso por el cu ual se desar rrollan opcio ones y Plan accio ones para me ejorar las op portunidades s y reducir la as amenazas s a los objet tivos del proyecto.
163
Se re ealiza despu us del proc ceso Realiza ar el Anlisis de Riesgo os. Incluye lla identificac cin y asign nacin de un na persona (el propietar rio de la respuesta a los s riesgos) pa ara que asu uma la respo onsabilidad de d cada resp puesta a los riesgos acor rdada y finan nciada. El pro oceso Planif ficar la Resp puesta a los Riesgos abo orda los riesg gos en funci n de su prio oridad, introd duciendo rec cursos y acti sto, el crono ograma y el plan p para la direccin de el proyecto, segn ividades en el presupues se requiera. Las s respuestas a los riesgo os planificad das deben adaptarse a a la importanc cia del riesgo, ser renta ables con re elacin al desafo por c cumplir, rea alistas dentro o del conte exto del proyecto, dadas por todas t las partes p involu ucradas y deben estar a cargo de una pe ersona acord respo onsable. Tam mbin deben n ser oportun nas. A menu udo, se requ uiere seleccio onar la mejo or respuesta a los riesgo os de entre varias opcio ones. Los rie esgos incluye en las amenazas y las o oportunidade es que pueden afectar el l xito del pro oyecto, y se debaten las respuestas para cada un na de ellas.
Figur ra 67. Planifica acin de la resp puesta a los rie esgos
da riesgo ten ndr alguna de d las siguie ntes respues stas: Cad EVITAR R: cambiar la as acciones d del proyecto para evitar el e riesgo. REDUC CIR/MITIGAR R: minimizar la posibilidad de ocurren ncia. TRANS SFERIR: a un n tercero. No o lo elimina, solo s es trans sferido. ACEPT TAR: pasiva a o activam mente. En este caso es necesa ario un Pla an de Conting gencia.
164
siguiente tab bla muestra claramente c c cules son la as respuestas s que se deb ben adoptar segn s La s la cla asificacin de e cada riesgo o:
PROBABILIDA AD BAJA PROBABILIDAD ALTA
IMPACTO BAJO
NO CONSIDE ERAR
ACEPTAR R (CONTINGEN NCIA)
IMPACTO ALTO
RIESGOS AS SEGURABLES (TRASNFERIR) ( )
EVITAR MITIGAR M
Figura 68. Clasific cacin de respuestas a un rie esgo
5.6 S Seguimien nto y cont trol de ries sgos
a vez identif ficados los riesgos r del p proyecto, es necesario realizar r un s seguimiento sobre Una estos s, adems de e supervisar los riesgos residuales, identificar nu uevos riesgo os, ejecutar planes p de re espuesta a lo os riesgos, y evaluar su e efectividad a lo largo del ciclo c de vida del proyecto o. os como deb bemos realiz zar un seguimiento estri cto a los Riesgos En la siguiente figura vemo ficados en fo orma Acepta ables con ate encin, y com mo debemos s realizar un seguimiento o a los Clasif Riesg gos Clasifica ados en form ma Aceptable es. Para los s riesgos Ina aceptables, d debemos ten ner un plan d de respuesta a, que debe ser s evaluado o previament te.
Figura 69. Seg guimiento y con ntrol de riesgos
165
5.7 Beneficios de la Gestin de Riesgos
Una gestin de riesgos puede ser costosa de implantar al principio, pero si es realizada correctamente, trae importantes beneficios para el proyecto y el equipo de trabajo. A continuacin se detallan los principales beneficios: Incrementa la probabilidad de xito del proyecto. Provee una visin general de los riesgos, desafos y problemas del proyecto. Reduce los costes del proyecto (planes de accin mantienen relacin coste/beneficio adecuada). Reduce los tiempos del proyecto. Minimiza sorpresas y problemas. Evita que ocurran problemas, o si ocurren, evita su propagacin. Genera ventaja competitiva. Aumenta rentabilidad. Incrementa el nivel de confianza de los interesados del proyecto, al conocer las debilidades y fortalezas.
En resumen se puede concluir que una buena gestin de riesgos es fundamental para que el proyecto tenga altas probabilidades de xito.
CAPTULO VI. . RECURSOS HUMAN H NOS
6.1 I Introducci in
gn el PMBO OK, la Gesti n de Proyec ctos es una disciplina or rganizada en n diferentes reas Seg de Co onocimiento, , y una de ellas es la Ges stin de los Recursos R Hu umanos del P Proyecto. La Gestin de los Recurso os Humanos s del Proyec cto incluye lo os procesos s que organi izan y en el equipo o del proyec cto. El equip po del proye ecto est co ompuesto po or las personas a dirige quien nes se han asignado a role es y respons abilidades para concluir el proyecto. Si bien es comn c habla ar de la asi ignacin de roles y res sponsabilidades, los miembros del equipo deb beran partic cipar en gran n parte de la a planificaci n y toma de e decisiones del proyecto o. La particip pacin temprana de los miembros m de el equipo apo orta experie encia durante e el proceso o de planificacin y fortalece el comp promiso con el proyecto c como veremos.
Intereses co omunes Es E muy import rtante identific car los interes ses de cada m miembro del d equipo y d determinar si se alinean con c los intere eses del proyecto. Si es sto sucede, te endremos un equipo e compr rometido y motivado con n los objetivos s del proyecto.
ipo y el nmero de miem mbros del equ uipo del proy yecto a menu udo pueden cambiar a medida m El ti que a avanza el pro oyecto. Los miembros de el equipo de el proyecto pueden deno minarse personal del pr royecto. Lo os procesos de d Gestin d de los Recurs sos Humanos del Proyec cto incluyen:
167
En este captulo se va a presentar un estudio diferente de los Recursos Humanos de un proyecto. Nos vamos a centrar primero en la figura del Director del Proyecto y vamos a demostrar la necesidad e importancia de un buen Project Manager en la actualidad. A continuacin, vamos a tratar de ofrecerle al lector, personificado como Director de Proyectos presente o futuro, una gua para gestionar eficazmente su equipo de trabajo, sacando el mayor provecho del mismo haciendo uso de sus capacidades interpersonales a travs de la Inteligencia Emocional. Presentaremos este concepto y su importancia en la gestin, y a continuacin veremos cmo desarrollarlo y ponerlo en prctica para llegar a conseguir equipos de alto rendimiento, utilizando principios y tcnicas a travs de la Direccin, el Liderazgo y la Comunicacin en el Proyecto. Nuestro objetivo final ser conseguir, para el conjunto de Recursos Humanos de nuestro proyecto, y de forma constante: Entusiasmo. Motivacin. Compromiso. Y determinacin para lograr y cumplir con las metas.
A lo largo del captulo se podrn encontrar referencias a diferentes autores, los cuales son eminencias en las disciplinas que vamos a presentar, y que aqu slo pretendemos introducir y descubrir para el lector. Los autores de esta obra recomendamos el estudio aadido de los trabajos de estos autores si se pretende profundizar en los mismos.
6.2 Perfiles ms comunes en un Proyecto Informtico
El objetivo de este apartado es presentar al lector una enumeracin de los perfiles que aparecen a lo largo del desarrollo de un Proyecto Informtico, como introduccin previa a la figura del Director de Proyectos que despus se tratar en detalle. Aunque el nmero, estructura y funciones de los agentes participantes en el desarrollo de un sistema van a depender del tamao, complejidad y caractersticas particulares de dicho sistema, as como del tipo del proyecto, pueden establecerse de forma general los perfiles de los integrantes siguientes, que pueden corresponder cada uno de ellos a distintas personas o a una misma (por ejemplo, en proyectos pequeos una misma persona puede hacer la funcin de analista y de programador). En primer lugar, en todo desarrollo estn implicados dos grupos de personas:
168
Los pertenecientes a la organizacin usuaria o promotora del proyecto. Ser la organizacin que use el sistema cuando ste est construido.
Las pertenecientes a la organizacin de desarrollo o empresa contratista. Es la organizacin encargada de la realizacin del sistema.
Existen dos particularidades destacables siempre que exista un proyecto: Desarrollo interno. Ocurre cuando la organizacin usuaria y la de desarrollo coinciden. En este caso, el departamento de Sistemas de Informacin o el departamento de Informtica es el encargado de realizar un desarrollo para otro departamento o departamentos de su empresa. Auditores externos. Ocurre cuando la empresa promotora del proyecto y la contratista deciden de mutuo acuerdo contratar a una tercera firma, especialista en auditora informtica e independiente de ambas, que intervenga en aquellos casos en los que se hayan previsto procedimientos extraordinarios de control (auditoras).
Es muy probable que la composicin del personal perteneciente a las organizaciones participantes (cliente, desarrolladora y auditora si la hubiera) sea la siguiente: 1. Comit de Direccin. Constituido por los responsables (directivos) de la organizacin usuaria o promotora del proyecto y de la organizacin u organizaciones encargadas de su desarrollo. Al frente de este comit se encontrar el Director del Proyecto. 2. Director del Proyecto o Project Manager (usados indistintamente en adelante).
3. Comit de Garanta de Calidad. Est integrado por personal con conocimientos y experiencia en metodologas de desarrollo del departamento de Informtica de la organizacin usuaria o, en caso de que no existiera dicho departamento o as se quisiera, de una organizacin externa, independiente de la que desarrolla el sistema (empresa auditora). Este comit se encargar de controlar la evolucin del proyecto a travs del anlisis de los productos generados a lo largo de las diferentes fases de desarrollo, determinando si el producto obtenido es el adecuado a los requerimientos especificados. Desarrolla su trabajo de forma independiente, realizando comprobaciones y anlisis de los productos generados. En ningn caso el personal de este comit compaginar labores de direccin, desarrollo, etc. en el mismo proyecto, ya que perdera su independencia y no se podra asegurar la imparcialidad.
169
4. Equipo de Desarrollo Tcnico. Formado por las personas que se van a encargar directamente del desarrollo. Dichas personas pertenecern a la organizacin contratada para desarrollar el sistema, aunque si la organizacin promotora dispone de departamento de Informtica y lo desea, podran formar tambin parte de este equipo personal dicho departamento de la organizacin promotora. Al frente del equipo se sita el Jefe del Proyecto, siendo el resto de personal implicado en el desarrollo: los Analistas, Diseadores, Programadores y Tcnicos de Sistemas. 5. Personal del rea de Explotacin. Se trata de personas del departamento de Informtica de la organizacin usuaria con conocimientos sobre el entorno en que se explotar el sistema cuando se instale. Estas personas colaborarn con el equipo de desarrollo para concretar determinados aspectos, relacionados principalmente con la definicin del entorno tecnolgico del sistema (equipos, software de base, etc.) y con la construccin de la base de datos que posiblemente utilizar el sistema. En este ltimo caso conviene destacar la conveniencia de la existencia de un Administrador de tal base de datos, que ser una persona del rea de explotacin experta en esta labor y que se responsabilizar de la seguridad, confidencialidad y ajustes de dicha base de datos, de forma que se pueda asegurar un rendimiento ptimo cuando el sistema funcione en explotacin. 6. Personal del rea de Usuario Final. Estar formado por personas que utilizarn el sistema una vez terminado. Se recurre a ellas para determinar con detalle las funciones que deber realizar el sistema. Normalmente hay, al menos, dos categoras de usuarios: Usuario responsable: encargado de fijar requisitos generales y de dar el visto bueno al software final y a los manuales. Usuario final: en el que delegar el responsable para definir los requisitos detallados.
Vamos a ver ahora, de una forma ms formal, la relacin de participantes que define la metodologa MTRICA versin 3, del Ministerio de Administraciones Pblicas de Espaa. Recordamos que esta metodologa ha sido concebida para abarcar el desarrollo completo de Sistemas de Informacin sea cual sea su complejidad y magnitud, por lo cual su estructura y los perfiles de los participantes que intervienen debern adaptarse y dimensionarse en cada momento de acuerdo a las caractersticas particulares de cada proyecto. Los perfiles establecidos se muestran en la siguiente tabla:
170
Figura 70. Participantes e en cada perfil definido d segn n Mtrica V3
6.3 E El Director del Proy yecto
6.3.1
Definicio ones
Se trata de un directivo de alto nivel, co on amplia ex xperiencia en planificac cin y gestin de ormacin, nombrado po or lo genera al por acuerdo entre la as organizac ciones Sistemas de Info cadas. Norm malmente, se trata de un directivo de e la organizacin encarga ada del desa arrollo implic del sistema. Es el e responsab ble de los as spectos tcnicos, contractuales, a administrativos y
171
finan ncieros del proyecto. p Dirige y super rvisa la realizacin comp pleta y corre ecta de las tareas t asign nadas. Este e responsab ble mximo del proyecto o, debe ser una persona con ampliios conocimientos inform mticos y ex xperiencia en n el desarrolllo del tipo de e sistemas al a que perten nezca el proyecto. Defin ne y dirige la as tareas eje ecutadas po or los miemb bros del equipo, incluyen ndo las fech has de terminacin de ta areas o subt tareas. Propo orciona gua a y asistencia, y coordina a que el pro oducto final s sea el adecu uado. Dep pendiendo de d la magnitud de los d desarrollos y de su esca alabilidad, e en nuestra carrera profe esional podre emos encont trar que el D Director del Proyecto de elegue respo onsables en reas (calid dad, segurida ad, mantenim miento, etc.) ) segn la necesidad de el proyecto, o por el con ntrario, que e el propio Jef fe del Proyec cto sea cons siderado y llamado tamb bin Director r del Proyect to. No obsta ante, debemos recordar que se trat ta de perfiles s diferentes con sus res sponsabilida ades y actividades indep pendientes. gn MTRIC CA v3 (Espa a, MAP, 20 000), el Direc ctor del Proy yecto realiza a la estimaci n del Seg esfue erzo necesario para llev var a cabo el proyecto o, selecciona a la estrateg gia de desa arrollo, deter rmina la estructura del mismo m selecc cionando los procesos pr rincipales de e la metodolo oga a emple ear (como MTRICA), M fij ja el calenda ario de hitos y entregas y establece lla planificaci n del proye ecto. Es el en ncargado de e dirigir el pro oyecto, realiz zando las lab bores de seg guimiento y control c del m mismo, revisi in y evalua acin de resu ultados y co oordinacin del d equipo d el proyecto. Tal y como o indica tamb bin MTRIV VA v3, se oc cupa tambin n de la gesti n y resoluc cin de incide encias que puedan surg gir durante el desarrollo o del proye ecto as com mo de la ac ctualizacin de la planif ficacin inicial. Entre su us funciones s se encuen ntran la elaboracin de e los informe es de segui ntacin de gestin del proyecto una a vez que es ste ha imiento y el archivo de la documen finaliz zado.
Cualidades q que debe ten ner un Directo or de Proyect to Entre las cua alidades que se s deberan buscar b para ell Director del d Proyecto ca aben destacar r las siguiente es: mente estr ructurada y lgica, lider razgo y acep ptacin por el grupo de trabajo, conocimiento d del sector de la l actividad de el proyecto, m madurez y fo ormacin esp pecfica en aspectos a gere enciales (por ejemplo direccin d por o objetivos).
6.3.2
Por qu un Project t Manager?
Dr. Engineer ring Manage ement Luis J Jos Amend dola (2006), prcticamen nte logra da ar una El D respu uesta a esta a pregunta cuando c nos explica en su obra cmo entende er la Direcci n de Proye ectos. El P Project Mana agement, en n el entorno industrial, aplica a tcnicas y herram mientas de Project P Mana agement par ra gestionar los proyecto os dentro de la estrategia a del negociio y demostr rar los logros que con es stas se consiguen.
172
Un proyecto opera bajo plaz zos, costes, riesgo, calid dad, y factor r humano. C Como observ vamos L Jos Am mendola, los s proyectos son cada ve ez ms gran ndes y da a da, y como defiende Luis ms complejos. Hay H gente que desde el papel del director d del proyecto p ha pasado de ser s un rto tcnico a un integrador de factore es donde hoy y en da jueg ga un papel muy importa ante la exper condu ucta humana a y el sentido o comn.
Project M Management El mundo d de los negocio os ha reconoc cido la importtancia del Project Management tanto para el l futuro como o para el presente. (Luis Jos Amendola) A
Por r esta necesidad del fact tor humano, de un tiemp po a esta pa arte, se viene e demostran ndo un camb bio en el esti ilo de direcc cin que ha v venido predo ominando ha asta cierto tie empo atrs. En la actua alidad, si queremos una direccin d de proyectos s eficaz, est demostrad do que el flu ujo de trabaj ajo debe ser horizontal. Con una org ganizacin vertical v tradic cional y cad denas estrict tas de mand do, los trabaj jadores no tienen ningun na oportunid dad de partic cipar en la to oma de decis siones ni en n otras rea as funcionale es de la em mpresa, lo que les impide sentirse ms partcipes y motiv vados. Sin embargo, empleando una a direccin horizontal, el e trabajo se organiza a travs t de gr rupos funcion nales de trab bajo en el qu ue existe la colaboracin c n inherente d de unos con otros, posib bilitando adem ms una me ejora en cuan nto a la coord dinacin y co omunicacin n entre direct tivos y emple eados. El flujo de trabajo horizon ntal genera productividad, eficienc cia y efectiv vidad, adem ms de por supuesto s rentabilidad. Po or qu result ta importante e esto? Porq que se neces sita a una pe ersona, un p perfil nuevo, capaz de en ntender toda as las unidad des funciona ales de la em mpresa y la interaccin entre s, para ser capaz z de llevar adelante un na direccin n eficaz a travs de un flujo de t trabajo horiz zontal. Antiguamente, es sta figura no exista, y los s responsables de los pr royectos slo o deban ocu uparse de en ntender las operaciones o de d su unidad d independie ente. Aho ora nos enco ontramos con n la necesida ad del mane ejo de una gran cantidad d de informacin y conoc cimiento. Po odemos simp plificar a la d direccin de proyectos co omo conocim mientos, grf ficos e intuic cin, segn la l mayora de d los autore es contrastad dos. Es prim mordial que t tengamos clara la misi n, el alcance e, los objetiv vos y el repa arto de cada proyecto antes de come enzar. El xito del Proje ect Manager r requiere compromiso, c da a da de d las dedicacin, entrega y aprender d metodologas, tc cnicas y herr ramientas nu uevas. Slo as, a desplegando los prin ncipios del Project P agement, aseguraremos la igualdad y consisten ncia en la eje ecucin de llos proyecto os que Mana llevem mos a cabo o. En el com mplejo y com mpetitivo mu undo en el que q nos mo ovemos, deb bemos busca ar constante emente la excelencia co omo directores de proy yectos, y co omo dice un n viejo prove erbio chino, la excelencia a debe ser un n hbito, no un acto.
173
El c claro cambio necesario de d la direcci n vertical po or la direcci n horizontal, , nos ofrece ya un buen argumento que justifica a la existenc cia del Project Manager o Director d del Proyecto en la resa. empr
Figura 71. Com mparativa entre re Estilos de Di ireccin y sus caractersticas s
ro no es el nico. Nuestr ra disciplina, la Industria Informtica, , est en con nstante evolucin, Per se de esarrolla y cr rece sin para ar, y cada da a nuevos conocimientos nos inundan n. Esto nos lleva a lo sig guiente: las Tecnologas T de la Inform macin y la Comunicaci C n requieren n del conocim miento exper rto de much ha gente; se eguro que e el lector est de acuerdo con esta idea. Aqu no es suficiente ni vlid do el genio de d una perso ona trabajan ndo sola, com mo pueda se er el caso de otra cia en la que e un trabajad dor en armon na desarrolla su trabajo para cumpllir un determ minado cienc objeti ivo. A qu nos lleva esto? A la ne ecesidad del trabajo en equipo. Y e esta tendenc cia del trabaj ajo en equipo o para la gestin de la tec cnologa, con n frecuencia, necesita un n gestor, un gestor g del pr royecto, un Project P Man nager. Por r todo esto, y como decamos al priincipio del lib bro, el nme ero de empr resas que us san la direcc cin y gesti n de proyec ctos en los lltimos aos ha h aumentad do, especialm mente en el sector s de las TI. Ya no existe la des spreocupaci n de poner r al frente de e los proyect tos a alguien n que o a alguien n con exper riencia en ell desarrollo de d proyectos s. Ahora, nu uestra discip plina y sepa las em mpresas req quieren y exig gen de direct tores de proy yectos forma ados como ta al, con nume erosas habili idades, de to odo tipo.
6.3.3
Habilidad des y Carac ctersticas
e de las TI, las ha abilidades requeridas r para los P Project Mana agers, En la nueva era blecidos ya como c una pro ofesin, son: estab
174
-
Alta sen nsibilidad para los peque eos detalles. Capacid dad de integracin de fac ctores. Generacin de planes viables co on xito. Persuas sin. Capacid dad de influe enciar. Capacid dad de inspir rar. Habilida ad negociado ora.
Otra as caracters sticas bsicas deseables , de entre las s que deben sobresalir:
-
Capacid dad de soluc cionar proble mas, enfrent tndose a ellos de cara. Capacid dades de ges stin empres sarial. Compet tencias tcni icas. s. Dotes comunicativa c Liderazgo. Desarro ollado sentido o comn. Alta tole erancia hacia a la ambige edad. Buena comprensin c n del contexto o.
6.3.4 Errores com munes de lo os Directore es de Proyec ctos: Es importante que q tambin comprendam mos los error res en los qu ue podemos caer, ya que e esto ayudar a ce entrar los esfu uerzos y a ev vitar fallar en n los proyect tos. nos a
Un lder d debe saber cl laramente que NO debe ha acer Jim Collins, en el libro Em mpresas que Sobresalen, S de etalla portante que tener una lista a de las cosas s que que ms imp hay que ha acer, es tener r una lista de las cosas qu ue no hay que hac cer.
autor Grego ory M. Horine (2010) of frece la sigu uiente clasificacin para a los errores s ms El a comu unes que com menten ms frecuenteme ente los direc ctores de pro oyectos: 1. No com mprender exa actamente lo os objetivos de d la organiz zacin para con el proye ecto ni asegura arse de que se s cumplen e esos objetivo os.
175
nejar bien la as expectativ vas de los implicados a lo largo de e la ejecuci n del 2. No man proyecto. gar a un acu uerdo ni log grar la adsc cripcin de los l implicado os principales en 3. No lleg relacin n a los objetiv vos y los crit terios del xit to del proyec cto. 4. No desarrollar un n calendario o realista que incluya a todos los s esfuerzos s, las aciones de las tareas, la as estimacio ones comple etas y los re ecursos asignados interrela por nive eles. 5. No cons seguir la ace eptacin y la adscripcin al calendario o del proyect to. 6. No dec cidir firmeme ente ni com municar qui n es el re esponsable de determinados asuntos s. 7. No utiliz zar los proc cedimientos d de control de d cambios para gestion nar el alcanc ce del proyecto. municarse de d forma e eficiente y consistente con todos s los implicados 8. No com importantes. cutar el plan del d proyecto . 9. No ejec 10. No ataja ar a tiempo los riesgos q ue puede ha aber en el pro oyecto. 11. No iden ntificar los rie esgos a tiem mpo ni desarrollar planes de continge encia (respuestas) para esos riesgos. ener los recursos adecua ados con las caracterstic cas apropiad das en el mom mento 12. No obte oportun no. 13. No busc car la resoluc cin de los p problemas de e forma contu undente. 14. Mala de efinicin de lo os requisitos s y de la gest tin. 15. Gestin n insuficiente y falta de lid derazgo del equipo e del pr royecto.
El aprendi izaje en buen nas prcticas Ser conscien ntes y aprende er buenas prcticas en la Direccin y G Gestin de Pro royectos Inform mticos es fundamentall, de ah la imp portante de textos como el q que tiene delante e el lector, par ra tratar de ay yudarle en lo q que podamos en n el desarrollo de su carrera profesional.
176
onal aplica ada a la Di ireccin de d Proyect tos 6.4 Inteligencia Emocio
6.4.1
Introduccin
eligencia Emocional es una frase que e se viene escuchando mucho m en los s ltimos tiempos. Inte Es co omo una res spuesta glob bal a mucho os problemas relacionad dos al recurs so humano. Pero, qu es la Intelig gencia Emoc cional?, Po or qu es im mportante pa ara un Direct tor de Proye ectos? mo sacarle partido para a lograr equ uipos de alto rendimien nto? Vamos s a tratar de dar Cm respu uestas a esta as y otras pre eguntas a lo largo de los siguientes apartados. a
Inte eligencia Emocional La in nteligencia em mocional es la a capacidad para reconocer sentimientos propios y ajeno os, y la habilid dad para mane ejarlos.
o padre de este conce epto es Dan niel Golema an, que en 1995 public c su El considerado E Intelligence. S Sin embargo, , otros autores en el pas sado ya se haban h prestigioso libro Emotional dea, a este concepto. c Th horndike, en 1920, utiliz el trmino inteligencia social referido a esta id l habilidad de compre nder y mot tivar a otras s personas. En 1983, Howard para referirse a la T de las Inteligencias s Mltiples, tambin t intro odujo la idea a de incluir ta anto la Gardner, en su Teora gencia interp personal (la capacidad p para compr render las intenciones, , motivaciones y intelig dese eos de otras s personas) y la intelige encia intrapersonal (la ca apacidad de comprende erse a s os, temores y motivaciones prop pias). Otro de d los uno mismo, apreciar los sentimiento enes de la int teligencia em mocional est t en Joseph h Ledoux, co omo influenciia ms recie ente, a orge r de su libro El cerebro emocional ( 1996), en el que divulga a sus hallazg gos acerca de d los partir circui itos neuronales del cereb bro.
Emocin, p pensamiento y razn La L emocin pr recede al pensamiento. Las L emocione es son importa antes para el ejercicio e de la razn.
niel Golema an estima que q la inte eligencia em mocional se puede org ganizar en cinco Dan capac cidades: er las emocio ones y sentim mientos propios. 1. Conoce 2. Manejarlos.
177
3. Recono ocerlos. 4. Crear la a propia moti ivacin. 5. Y a part tir de ah, ge estionar las re elaciones, in nfluyendo y manejando m en n los dems.
Importanci ia de aprender y desar rrollar Intelig gencia Emocional s importante recibir r formac cin en Intelig gencia Por qu es Emocional, y ponerla en n prctica co omo Directore res de Proyectos? P Por la gran rel levancia de las emociones en los resultados de el trabajo.
s caracterst ticas de la lla amada intelig gencia emoc cional son imprescindible es para un Di irector Las de P Proyectos qu ue es tamb bin un ges stor de recu ursos humanos, y que responsabl le del rendimiento y de los resultado os profesiona ales de los mismos. m as caracters sticas son: la a capacidad de motivarn nos a nosotros mismos y a los dem s, de Esta perse everar en el empeo a pesar p de las s posibles fru ustraciones, de controlar r los impulso os, de diferir r las gratific caciones, de e regular nu uestros prop pios estados de nimo, de evitar que q la angustia interfiera a con nuestr ras facultade es racionales s, y la capac cidad de em mpatizar y co onfiar os dems, lo ogrando que e los dems tambin co onfen en no osotros. en lo El c concepto de e "Inteligencia Emociona al" enfatiza el papel preponderante e que ejerce en las emoc ciones dentr ro del func cionamiento psicolgico de una persona p cua ando sta se s ve enfre entada a mom mentos difc ciles y tareas s importantes: los peligro os, las prd idas doloros sas, la stencia hacia a una meta a pesar de los fracasos s, el enfrenta ar riesgos, o los conflicto os con persis un co ompaero en n el trabajo. En todas es stas situaciones hay una a involucraci n emociona al que puede resultar en n una accin que culmine e de modo ex xitoso o bien n interferir ne egativamente e en el mpeo final. . Cada emo ocin ofrece e una dispo osicin defin nida a la ac ccin, de manera desem que e el repertorio o emocional de la pers sona y su fo orma de ope erar, influir n decisivam mente en e el xito o fracaso f que e obtenga en las tare eas profesionales (y personales) ) que empr renda. ltim mamente, se e les ha dado a los facto ores emocion nales la impo ortancia deb ida en el tiem mpo y en el espacio, inc cluyndolos en el ptimo o desempeo de las actividades pro ofesionales, donde d os, como ge erentes y com mo lderes, tienen cada uno de ello os sus las personas, como individuo encias en muchos aspec ctos y reas s, pero que como c seres humanos es stn dentro de d los difere Princ cipios de la In nteligencia Emocional. Las s condicione es intelectual les no son la a nica garan nta de xito en el mbito o profesional, sino tan s slo un facto or, que unid do a las nec cesidades emocionales e del persona al cubiertas como equip po, desarroll lar el dese empeo y lo os resultados s de todo l der y trabajjador motiv ndolo emoc cionalmente a ser produc ctivo. (Danie el Goleman).
178
Num merosos aut tores, y tam mbin Golem man, nos hablan de las Competenc cias Emocionales. Estos s autores definen el xito o de gerente es lderes y trabajadores t , en persona as de alto niv vel de desem e s bien desar rrolladas; que han mpeo, con destrezas, habilidades tcnicas y emocionales alcan nzando la ca apacidad de e dar sentim mientos que cada vez se s hacen m s competiti ivos y neces sarios en la familia, f en la a sociedad, y en el trabajo (gerencia). Las s competenc cias emocion nales que m ms se repit tieron como decisivas e en el xito de d los ldere es y sus emp presas, fuero on clasificada as en cuatro categoras:
Figura a 72. Clasificac cin de Compe etencias Emocionales
179
6.4.2 go Liderazg
mos a ver en n primer lugar varias defin niciones sobre Liderazgo o. Vam Seg gn Wikipedi ia, el lideraz zgo es el co onjunto de capacidades c s que una p persona tiene e para influi ir en un grupo de pe ersonas dete erminado, haciendo h qu ue este equ uipo trabaje e con entus siasmo en el e logro de metas y ob bjetivos. Tambin se en ntiende como o la capacidad de tomar la iniciativa a, gestionar, , convocar, p promover, in ncentivar, mo otivar y evalluar a un gr rupo o equip po. En la ad dministracin n de empre esas y proye ectos, el lid derazgo es e el ejercicio de la actividad ejecutiv va en un pro oyecto, de fo orma eficaz y eficiente, sea s ste pers rsonal, geren ncial o ucional (dent tro del proce eso administr rativo de la organizacin) o ). institu
Lid derazgo El lid derazgo es el e proceso de e dirigir las activi vidades labora ales de los mi iembros de un gr rupo y de influ uir en ellas.
a ltima defi inicin tiene cuatro impliicaciones im mportantes. Im mplica que h haya una pe ersona Esta (lder r o no) que pueda p influir r y motivar a los dems (seguidores). De ah qu ue en los estudios sobre e liderazgo se s haga nfa asis en la ca pacidad de persuasin p e influencia. Tradicionalm mente, a la s suma de es stas dos vari iables se le ha denomin nado carism ma. Sin emba argo, los estudios actua ales en psico ologa y soci iologa, han concluido qu ue el carism ma no tiene la a importanci ia que histr ricamente se e le haba oto orgado y que e tambin ha ay otros factores (habilid dades direc ctivas) que s son ms determinantes a la hora d de construir el verdadero o liderazgo. El autor Ste ephen Cove ey define Lid derazgo es la creacin c de nu uevas realidades. Luis s Jos Amen ndola (2006), , nos aporta tambin una a definicin de d Liderazgo o en su genia al obra Estra ategias y T cticas en la Direccin y Gestin de Proyectos P ", y despus n nos alienta a llegar al concepto de COACHING C , ampliament te difundido por los estudiosos del L Liderazgo. Para P el Amendola, el rol del liderazgo trabaja a constantem mente en la expansin e de e su rol, e in ncluye Dr. A actividades tales como:
-
S un mode Ser elo para los d dems. A Amplitud de mente a la h hora de comp prender y analizar el neg gocio. S Superar las barreras b del proyecto y anular a las posibles interfe erencias. A Agente facilit tador de la c comunicacin n dentro del equipo. e O Orientacin del d equipo all cliente. M Motivar para la excelenc ia.
180
Seg gn este auto or, un lder efectivo, e que e es lo que buscamos, b tiene muy cla ara la direcci in de su or rganizacin, y est enfoc cado a alcan nzar su visin, entiende lo que esto s significa para a cada ona individua almente, as como la nec cesidad de modelar m esa necesidad n ye enfocarla. perso
Liderazg go Liiderazgo es la l creacion de d nuevas r realidades. (Stephen Co ovey).
Tal y como mu uy bien dice Amendola, tradicionalm mente, el eslabn de c competencia a ms l del directivo de proy yectos siem mpre ha sid do la gesti n del rend dimiento de e sus dbil colab boradores. La correcta form macin tcni ica contrasta a con la falta a de habilida ades emocio onales y por r tanto relaci ionales. El coaching, c def fiende Amen ndola, media ante una met todologa est tructurada, lleva a cabo aproximacio ones que nos s permiten tr rabajar en la a mejora del rendimiento y en el desa arrollo del po otencial del equipo e del proyecto. El c coaching es por tanto, como c dice e el autor que venimos re eferenciando, , un mode elo de lidera azgo que ti iene la finalidad de de esarrollar el potencial de las pers sonas, y que se apoya a en los sigu uientes princi ipios: Hay que centrarse en el rendim miento futuro o, y no en el actual o pa asado. Slo en e las dades futuras s. posibilid Hay que e creer en los miembros del equipo del d proyecto. Si nosotros creemos en ellos, est de emostrado qu ue esto tend dr un impac cto muy positivo en su d esempeo. Por lo que obt tendremos lo o mejor de la s personas. La conf fianza es la gran g apuesta a del coachin ng. Los mie embros del equipo e no a prenden del lder, apren nden de ello os mismos y de la experiencia.
Lder coa ch Un lder co oach consigue e que los mie embros del eq quipo vayan ms all de las lim mitaciones qu ue ellos mismo os se ponen, y les s estimula y gua g constante emente para s sacar el mximo p potencial y ren ndimiento.
coaching est siendo apl licado por nu umerosas or rganizaciones en los ltim mos tiempos s, y se El c est empezando a aceptar como una ve entaja compe etitiva. Tanto o es as, que e algunos au utores,
181
como Hendricks (1996), ya se atreven a citar las caractersticas ms importantes de este modelo de liderazgo: 1. Claridad en la comunicacin. 2. Apoyo integral al equipo. 3. Confianza y reconocimiento al equipo. 4. Visin clara de las metas comunes. 5. Empata. 6. Control del riesgo y seguridad de los miembros del equipo. 7. Paciencia. 8. Confidencialidad. 9. Y respeto.
Volviendo al concepto puro de Liderazgo, en la literatura podemos encontrar gran variedad de clasificaciones de tipos de lderes. Nos vamos a quedar con la siguiente clasificacin de Estilos de Liderazgo y sus caractersticas, sobre la que trabajaremos despus: o o o o o o o o o o o Lder Visionario. Empata. Confianza en s mismo. Agente de cambio. Lder Afiliativo. Empata. Creacin de relaciones. Resolucin de conflictos. Lder Democrtico. Fomento del trabajo en equipo. Gran comunicador. Lder Orientativo. Empata. Dominio del potencial de los dems. Autoconsciente. Lder Coactivo.
182
o o o o o o o Confianza en s mismo.
Ordena a los dems que ejecuten sus deseos. Carece de empata. Lder que Marca La pauta. Implanta calidad. Iniciativa. Motivacin. No ayuda a mejorar, crtica a los que no logran sus objetivos.
Dice Gregory M. Horine (2010), que en la Capacidad de Liderazgo se incluyen capacidades bsicas como las habilidades interpersonales y generales, como forma de tratar a la gente, la adaptabilidad, la flexibilidad, la gestin de personas, el grado de orientacin al cliente, capacidades analticas, de resolucin de problemas, y el talento de tener siempre en mente la perspectiva general. Esto acerca la Inteligencia Emocional, de la que venimos hablando, al Liderazgo. Y estas caractersticas nos llevan tambin a un importante concepto: el clima de trabajo, lo que se conoce como clima organizativo de la organizacin. El clima organizativo tiene una importancia predominante en el cmo desempean su trabajo los miembros del equipo, y refleja el sentido de las personas acerca de su capacidad. Necesitamos un clima que favorezca el entusiasmo, la motivacin, el compromiso, y la determinacin. Existen indicadores del clima, e incluyen el grado en el que la comunicacin es clara, la flexibilidad con la que cuentan los empleados para realizar sus trabajos como mencionaba Horine, la capacidad para innovar, y el sentido de la responsabilidad para llevar a cabo las tareas. Daniel Goleman y Cary Cherniss, en su obra The Emotionally Intelligent Workplace (2005), defienden la importancia del liderazgo, y justifican la importancia de un liderazgo
emocionalmente inteligente para crear un clima de trabajo prspero que derive en una consecucin de los objetivos a travs del rendimiento de todos los empleados, y nos brindan una serie de argumentos muy tiles para nosotros, Directores de Proyectos: En su obra, ponen de manifiesto el resultado de estudios que revelan que los lderes emocionalmente inteligentes, con grandes competencias emocionales, sobrepasan los objetivos en trminos de rendimiento, entre en un 15 y un 20 %. La relacin entre puntos fuertes en Inteligencia Emocional en un lder, y el rendimiento de la unidad, parecer estar mediatizado por el clima creado por el lder.
183
Sus s estudios, han revelad do la import rtancia del clima c en la relacin co on la intelig gencia emoc cional de lo os individuos s que ocupa an puestos de Direcci n de Proy yectos, y es sto ha condu ucido a reco onocer el des stacado pape el de las com mpetencias en Inteligenci a Emocional en la eficac cia del lidera azgo. La sigu uiente tabla, e elaborada po or Goleman y Cherniss, r recoge los efectos de es sta relacin:
Figu ura 73. Estilo de e Liderazgo, In nteligencia Emo ocional (IE) y efectividad e organizativa, de G Goleman y Che erniss (2005)
6.4.3
La Comu unicacin en n el proyect to
o participan un grupo de e personas que interactan entre s en busca de un En un proyecto ivo comn y con recu ursos limitad dos. Esta interaccin se s realiza p por medio de la objeti comu unicacin. Por P tal motivo, se con sidera esen ncial agrega ar contenido os referidos a la comu unicacin en el Proyecto. Las s comunicac ciones del proyecto p son n todos los medios y formas de que un pro oyecto intera acte con to odos sus imp plicados. Es to no slo incluye los elementos e de e comunicac ciones
184
forma ales y estndar, sino que tambi n incluye comunicacio c nes de ges stin del cambio organ nizacional.
Im mportancia seg n PMI de d la com municacin
Seg s directores de e proyectos n el PMI, los debe en pasar el 90 0% de su tiemp po com municndose.
6.4.3.1
mportancia de d la Gesti n de las Co omunicacion nes en el Pro oyecto La im
Nos s encontramo os ante una nueva rea de Conocim miento de la Gestin de P Proyectos. In ncluye los procesos requeridos para egurar ase la generacin, recopilaciin, distribucin,
almac cenamiento, recuperaci n y disposic cin final opo ortuna y apro opiada de la a informaci n del proye ecto. Los procesos p de Gestin de e las Comun nicaciones del Proyecto proporciona an los enlac ces cruciales s entre las personas y la informa acin, que son s necesar rios para qu ue las comu unicaciones sean exitosa as. Los direc ctores del proyecto p pue eden dedicar r una cantidad de tiemp po excesiva a la comunicacin con e el equipo de el proyecto, los interesad dos, el client te y el patro ocinador. Tod das las perso onas involuc radas en el proyecto p deb ben compren nder cmo af fectan las c comunicacio ones al pro oyecto en su conjunt to. Los pro ocesos de Gestin de las Comu unicaciones del Proyecto o incluyen:
s comunicaciones del pro oyecto son im mportantes no n slo por una u razn ob s la de bvia, que es Las mantener adecua adamente y constanteme c ente informad dos a los miembros del e estado y pro ogreso
185
del p proyecto, sino que tambin son un f factor determ minante para a el xito ge eneral del mismo. m Por qu? ad de las co omunicaciones tendr un n enorme im mpacto Porque la calidad y la efectivida s implicados s en relacin n al proyect to y al papel del sobre las percepciones de los r del proyecto o de lder de l mismo. director Porque la capacida ad del direc ctor del proy yecto para comunicar, es el factor r ms sobresa aliente que afecta a al niv vel de gesti n y direcci n del ncle eo del equip po del proyecto. Porque ya hay sufic cientes probllemas en la ejecucin de el proyecto, como para aadir a adems s conflictos como c resulta ado de las malas m percepc ciones, la fa alta de inform macin o los problemas no existentes, y todo esto consecuencia c a de una malla comunicac cin.
Organizacin O n y comunicac cin Cu ualquier direct tor de proyec ctos con expe eriencia, sabe e que hay do os competenciias que le salv varn casi siem mpre: la organ nizacin y la comunicaci in. Si se sobresale en estos campos, especialmente en las co omunicaciones s del proye ecto, se compensarn la as flaquezas en los dems.
6.4.3.2
Competencias in nterpersona ales
Las s siguientes tcnicas t son n probableme s importante es porque afe fectan a la calidad ente las ms de todas las com municaciones del proyecto o, aquellas fo ormales y las ms frecue entes que oc curren l da a da del d proyecto entre el eq uipo del pro oyecto y los implicados. La siguiente e lista en el mues stra las com mpetencias in nterpersonale es claves que los buen nos comunic cadores poseen o deben esforzarse e en alcanzar r: Escuchar con un pro opsito cons structivo. ad; ser humilde y transm itir esa humildad. Humilda Pensar con calma antes a de resp ponder, y nun nca hacerlo en caliente. e en el lugar del otro, y s si es posible, que el otro se s d cuenta a de ello. Ponerse No juzg gar, y evitar trminos t y to onos que im mpliquen juicio, culpa o m malas accion nes de otras pa artes. Interesa arse por los dems. d Intentar r comprender lo que hace en, por qu lo hacen y qu u problemas s estn pasa ando. Validar las percepciones antes d de responder. r apreciacin n por su tiemp po y el esfue erzo de comp prensin. Mostrar Resumi ir lo que ha dicho d el habla ante.
186

Hacer que la gente se sienta escuchada. Centrarse en construir relaciones. Tener bajo control las emociones propias. No asumir que una respuesta negativa est causada por temas personales, la mayor parte de las veces no ser as.
Siempre que sea posible, evitar interrumpir. Asegurarnos de que estamos siendo comprendidos.
6.4.3.3
La dificultad de comunicarse
Barreras de la comunicacin efectiva: Filtracin. Percepcin selectiva. Emociones. Lenguaje. Cultura nacional.
Buenas prcticas para lograr la superacin de las barreras: Emplear retroalimentacin. Hacer nfasis en comportamientos especficos. Mantener la retroalimentacin impersonal. Mantener la retroalimentacin orientada a las metas. Dar un tiempo oportuno a la retroalimentacin. Asegurarse de que lo entiendan. Dirigir la retroalimentacin negativa hacia un comportamiento que quien lo recibe pueda controlar. Simplificar el lenguaje. Escuchar activamente. Empata. Aceptacin. Intensidad. Disposicin de asumir la responsabilidad de escuchar el mensaje completo.
187
6.4.3.4 Establecer contacto visual. Asentir con la cabeza y mostrar una expresin facial adecuada. Evitar acciones o gestos que los distraigan. Hacer preguntas. Parafrasear. Evitar interrumpir al orador. No hablar de ms. Hacer transiciones suaves entre los papeles del orador y escucha.
Restringir las emociones. Vigilar los indicativos no verbales. Manejo de conflictos en la comunicacin
Los conflictos son las diferencias incompatibles percibidas que dan como resultado interferencia u oposicin. Un conflicto que no pudo ser resuelto a tiempo puede costar el fracaso del proyecto. Por tal motivo, es muy importante que el Director del Proyecto tengo los medios necesarios para identificar conflictos, y habilidad para resolverlos a tiempo. Prcticas efectivas para la resolucin de conflictos: Establecer un estilo para manejar el conflicto. Tener cuidado al seleccionar los conflictos que se quieren manejar. Evaluar a los participantes en el conflicto. Evaluar la fuente del conflicto. Conocer las opciones.
6.4.4
Potenciar el rendimiento del equipo del proyecto
Una direccin eficaz, y contar con buenas competencias de comunicacin, son ingredientes claves para conseguir el xito de un proyecto. Pero no es suficiente, debemos ir ms all en la bsqueda de la excelencia empresarial, y en busca de nuestras aptitudes y capacidades como lderes y buenos gestores de recursos humanos. Para ello, debemos comprender los principios y tcnicas especficas que podemos aplicar para potenciar al mximo el rendimiento del equipo de un proyecto, y de esto nos vamos a ocupar a continuacin. 6.4.4.1 Principios de Gestin
Ahora ya conocemos qu es un equipo de alto rendimiento, qu le caracteriza. El siguiente paso tiene que ser lograr el mximo rendimiento de nuestro equipo de trabajo, llegar a alcanzar ese nivel. Y para conseguirlo, conviene revisar varios principios fundamentales de gestin,
188
primordiales para guiar a nuestro equipo, que tambin nos ofrece el Sr. Horine en la obra indicada como fuente de este subapartado: 1. Adaptar el estilo de gestin; dependiendo de la fase del proyecto, las necesidades particulares del equipo y el entorno del proyecto. 2. Reclutar a los ms preparados. Para un director de proyectos, tener a la gente adecuada representa el 80% de la batalla. En este sentido, siempre que sea posible, debe ser el propio director de proyectos el que se encargue de la seleccin del personal, y en la misma medida, ser muy importante conseguir la participacin de personas con una carrera plagada de xitos, y con grandes competencias para aportar en el proyecto. 3. Planificar como equipo. Este es un factor fundamental, ya que si conseguimos implicar e involucrar a todos los miembros en la planificacin del desarrollo, la planificacin pasa a ser su plan, y su calendario. Con esto logramos un mayor compromiso, aceptacin y un mayor nivel de responsabilidad. Como vemos, poco a poco vamos obteniendo, siguiendo estos principios, las caractersticas de lo que sin duda ser un equipo eficaz, un equipo de alto rendimiento. 4. Proteger al equipo y mantenerlo centrado. El director del proyecto debe ser quin proteja al equipo de las polticas, ruido y otros factores que puedan distraerlo y ralentizar su progreso; y debe asegurarse tambin de que los miembros del equipo se mantengan centrados durante todo el tiempo, sin perder nunca de vista el marco general del proyecto: misin, objetivos y prioridades. 5. Potenciar la productividad. Tal y como defienden todos los autores del mundo, pocas cosas hay ms importantes que asegurarse de que cada miembro del equipo tenga claro qu es lo que tiene que hacer. De cara a la productividad, la importancia es mxima. 6. Mejorar las competencias comerciales. Una meta fundamental que pretendemos obtener con cualquier persona del equipo es mejorar sus cualidades comerciales mediante sus experiencias en el proyecto. Debemos buscar formas de mejorar las cualidades de nuestros miembros, y ayudarles a crecer como profesionales. 7. Aplicar los talentos individuales. Consta de: a. Buscar y encontrar los talentos de cada persona, los que se pueden aplicar al proyecto. b. Entender tambin sus flaquezas. c. Analizar las emociones y comprender qu es lo que lleva a moverse a cada persona, sus factores de motivacin, lo que les importa. Una vez conocido esto, ser posible no slo posicionar mejor a la gente, sino que nos permitir
189
recompensar y reconocer mejor a los individuos. Con el tiempo, esto se convertir en un hbito de vida. d. Alinear las funciones y responsabilidades con el punto fuerte de cada miembro del equipo en la medida que sea posible. El punto fuerte es la combinacin de los talentos naturales y las motivaciones personales. 8. Reconocer y recompensar. Formas de realizarlo, no de conseguirlo: a. El director del proyecto debe hacer como si fuese el representante o relaciones pblicas de cada miembro del equipo. No slo debemos ofrecer respuestas oportunas, debemos ofrecer apreciacin por cada miembro personalmente. Y es ms efectivo si se realiza durante todo el desarrollo del proyecto, segn avanza, y no solamente como revisin anual o final del proyecto. Necesitamos y debemos mantener vivo el compromiso, la motivacin y el espritu profesional de los miembros. b. Celebrar los xitos del equipo. Esto conseguir un gran impulso. c. Recompensa.
9. Cohesionar al equipo. Todo lo visto anteriormente tiene sentido si facilitamos y conseguimos la sinergia del equipo. La mayor parte de los equipos pasan por las fases de Integracin, Normalizacin, Agitacin y Realizacin, pero se pueden poner en marcha muchas acciones para influir positivamente en este proceso, y es recomendable centrarse en lo siguiente: a. Construir relaciones. Por ejemplo, establecer excursiones o salidas de equipo, comidas, reuniones y otras cosas para que las relaciones puedan evolucionar y los miembros se conozcan y ganen confianza unos en otros. Esto es una prctica habitual adoptada por la Direccin de Proyectos Informticos (DPI) de la Universidad Tecnolgica Nacional, en la Facultad Regional de Tucumn, y ha venido cosechando muy buenos resultados en los ltimos tiempos. b. Establecer procedimientos de equipo. Determinando las reglas, directrices y protocolos que sean necesarias para establecer una productividad de equipo.
6.4.4.2
Tcnicas para potenciar el rendimiento de los equipos
Una vez que conocemos los principios primordiales para guiar el rendimiento del equipo, observemos unas cuantas tcnicas contrastadas para conseguir nuestro objetivo (Horine, 2010): Llevar a cabo reuniones de apertura para el equipo, al principio de cada fase. Es una excelente forma de restablecer las expectativas sobre el contexto del proyecto. Y es
190
conveniente utilizar tambin minireuniones de apertura al principio de cada fase del proyecto, no slo al comienzo del proyecto, para restablecer las expectativas. Crear grupos de trabajo, permitiendo compartir ideas y experiencias, solucionar problemas y aumentar la sinergia del equipo. Utilizar sabiamente el tiempo de las reuniones. Desarrollar la descripcin de los componentes del equipo. Lo importante de esta cuestin no es perder el tiempo en documentar esto, sino el hecho de realizarlo con el equipo para desarrollar estas directrices y procedimientos. De este modo, al igual que con el plan general del proyecto y el calendario, formar parte de su trabajo, es decir, ser suyo tambin. Desarrollar, establecer y comunicar normas, aplicando el conocimiento experto. Utilizar la experiencia. Resolver los conflictos al instante. Los equipos de alto rendimiento no permiten que persistan los conflictos o los problemas, porque si ocurre puede afectar a la productividad del equipo. Como director de proyectos necesita facilitar la resolucin de esos problemas inmediatamente. Esto no quiere decir que no escuche y que haga juicios precipitados, significa que se traten, no que se eviten. Preparar al equipo para las interacciones directas con el cliente. Establecer un repositorio del proyecto. Por ejemplo, a travs de una Wiki que permita mejorar y facilitar la productividad del equipo, compartiendo conocimientos y protegiendo a la vez los activos del proyecto. Desarrollar costumbres de equipo para crear unidad. Un buen ejemplo podra ser ir a comer todos juntos un da de la semana. Asignar tareas efectivas con aceptacin clara de responsabilidad y calendario. Planificar para la orientacin. Existe un perodo inicial de orientacin para cada miembro del equipo que se une al proyecto. El objetivo del director del proyecto debe ser acelerar ese perodo y obtener la mxima productividad por su parte lo antes posible.
CAP TULO VII. V RED DMINE, SOFTW WARE LI IBRE DE N DE PROYEC GESTI G CTOS
La construccin exitosa de toda mq quina depend de de la perf feccin de la as herramientas empleada as. (Charles Babbage)
7.1 D Descripci n
alquier organ nizacin en crecimiento o, que mane eje una cier rta cantidad de proyectos de Cua divers sa ndole, ne ecesita una herramienta a que le perm mita la gesti n eficiente de sus proyectos. En e este captulo o se presentar una so olucin basa ada en la herramienta h de software e libre REDM MINE. A trav vs de esta herramienta h cada equipo o de trabajo podr p darle s seguimiento a sus actividades, acce ediendo desd de un navega ador web.
Red dmine Red dmine es un g gestor y planifi icador de proy yectos con intterface web, orienta ado a la coord dinacin de ta areas, comunic cacin de par rticipantes, y que puede p espec cializarse en proyectos de d desarrollo gracias a herram mientas como la integracin n en un reposi itorio de cdig go.
Red dmine es un na herramien nta de gesti n de proyec ctos software e con interfa ace web. Un na vez instal lada, el adm ministrador da a de alta los proyectos a travs de la a interface w web, puede dar d de alta a los desarro olladores y je efes de proye ecto (o pueden darse de alta ellos m mismos a trav vs de la inte erface web). Una a vez dados de alta los proyectos p ys sus jefes, es stos pueden definir los hiitos del proyecto y las ta areas a realiz zar para cada a uno de est tos hitos. Los s desarrollad dores tienen en su pg gina de entr rada una lis sta de las t tareas que tienen t asign nadas. Es una nica lis sta conjunta a de las tare eas de todo os los proye ectos. Segn van trabaj ajando en las s tareas, pue eden ir marca ando el tiempo que estim man que les llevar la tar rea, el tiemp po que han tr rabajado en ella y/o el po orcentaje que e creen que tienen realiz zado. Con n esta inform macin, en el hito corre espondiente del proyect to se muest tra una "bar rra de progr reso" horizon ntal, en la que q una par rte aparece en color ve erde, indican ndo el nme ero de tarea as terminadas s, mientras que q el resto aparece sin n color, indica ando lo que queda pend diente. ogreso da un na idea bast tante aproxim mada de cu nto llevamo os hecho y cunto c Esta barra de pro s aproximada a si nos mole estamos en meter los tie empos queda por hacer. Por supuesto, ser ms mados en las tareas y estimamos bien n. estim
193
7.2 F Funcionalidades
7.2.1 Gestin de e mltiples proyectos p Se pueden ges stionar mltiples proyec ctos desde una sola in nterface con una ventan na de gador. La navegacin n es muy sen ncilla y se puede saltar y cambiar r de proyec cto en naveg cualq quier momento. Adems, cada proyec cto puede tener una conf figuracin tot otalmente dife erente y el u usuario tener r un rol distin nto en cada uno. Los pro oyectos pued des definirse e como priva ados o pblic cos, visibles para todo el e mundo. E s el adminis strador quien n da acceso a cada mie embro. Tamb bin dentro de d cada proy yecto pueden n definirse va arios subproy yectos.
Figura 74. N uevo Proyecto o en Redmine
7.2.2 Personaliza acin de pro oyectos ada proyecto es totalmen nte personali izable, pudie endo encontr rar proyectos s muy En Redmine ca ntos entre s segn sus objetivos. L Lo ms importante son los mdulos s que se pu ueden distin desac ctivar o acti ivar para ca ada proyecto o: wiki, foro, , noticias, peticiones, co ontrol del tie empo, docum mentos, ficheros o repos sitorio, aunqu ue hay mdu ulos comune es a todos lo os proyectos como el de e actividad y vistazo. Si S un proyec cto est enf focado a no otificar incide encias, se puede p config gurar para in ncluir solo peticiones, si se busca un proyecto ms m colabora ativo, la wiki y las
194
notici ias son una buena opci n, e incluso o se puede habilitar un proyecto sollo con un foro. La perso onalizacin de d un proyecto puede ser r realizada co omo se indic ca en la figur ra anterior. 7.2.3 Gestin de e roles da usuario de e Redmine puede p perten necer a un determinado rol, r con el cu ual interactua ar en Cad el pro oyecto pudie endo accede er a diversas s funcionalid dades determ minadas por r un adminis strador del gestor. Es de ecir, que un usuario pos ee un rol en n cada proye ecto. Con es se rol puede tener acces so a diferent tes funcionalidades del s sistema, seg n sea la con nfiguracin d determinada sobre los permisos de ese rol. Una a persona pu uede accede er con ms permisos p au un proyecto que a plemente en un proyecto o tenga un rol r distinto que en otro. A continuaci in se otro, porque simp stra una imag gen ilustrativ va de la conf figuracin de e permisos de d un determ minado rol, en n este mues caso el Rol del An nalista Funci ional.
Figura F 75. Perm misos del rol an nalista-funcion nal
7.3 S Sistema flexible de seguimie nto de tar reas
a de las me ecnicas m s tiles para a el desarro ollo de un proyecto p en Redmine so on las Una petici iones y su visualizacin. v . Por defecto o, el sistema a tiene tres tipos t de peti ciones: tipo Error, tipo T Tarea y tipo o Soporte. El E Administra ador del sistema puede e crear cualq quier otro tipo de petici in que dese ee. cto. Adems, las Las s peticiones deben asig gnarse a un n determinado miembro o del proyec petici iones tienen informacin n que son pr ropias de cu ualquier activ vidad que se e desarrolle en un proye ecto, como por p ejemplo: una fecha d de inicio y fin n para esa peticin, p con ntrol del tiem mpo en las horas utilizad das, porcenta aje realizado o, prioridad, etc. El sistema tambi n permite que se
195
pueda enlazar co on la subida de d un fichero o, y encajar en e una categ gora (se pue eden definir tantas t o se quiera an). A continuacin se e muestra una u imagen n con una peticin de e tipo como Requ uerimiento de e ejemplo:
Figura 76 6. Detalle de un na peticin
Con n todos est tos datos, pueden vis ualizarse la as peticiones de mane era personalizada estab bleciendo filtros, y servir r as de info ormes de tar reas o incide encias. Adem ms dentro de un proye ecto pueden n establecerse versione es y asignar r tareas a determinada as versiones s; as, confo orme se ma arquen tarea as completa das, las ve ersiones irn n completand do su porce entaje autom mticamente e. A continuacin se mue stra un ejem mplo de una consulta c de p peticiones filt tradas segn n un determi inado valor.
Figu ura 77. Tareas organizadas por p medio de filtros
196
entes consult tas que el s sistema perm mite realizar, se encuent tra la consulta de Entre las difere Tiem mpo dedicado o que perm mite consulta r las horas de d trabajo re egistradas p por cada mie embro. Esta consulta pue ede ser optim mizada inclu so, consultando las hora as trabajadas s en cada pe eticin asign nada. Esto pe ermite al Dire ector del Pro oyecto tener informacin correcta sob bre la particip pacin de ca ada miembro o del equipo en e el proyect to.
Figura a 78. Tiempo de edicado de los s miembros a un u proyecto, dividido por petiiciones
7.4 U Uso de ca alendario y Diagram ma de Gant tt
dmine incluy ye un calend dario para v visualizar tod das las petic ciones a lo largo de un n mes Red elegid do, indicando o claramente e el da de in nicio y de fin de cada peticin.
197
Fig gura 79. Calend dario de actividades mensua ales
do, Redmine e ofrece una a vista en diagrama d de e Gantt, que e va marcan ndo el Del mismo mod porce entaje completado conforme avanzan n los das. Las peticiones que se vis sualizan en ambos a casos s estn suje etas a los filtros definidos s por el usuario. Redmin ne utiliza una a combinacin de colore es que perm mite al usuario tener infor rmacin rpid da sobre cua alquier anom mala. Una de emora en un na determina ada actividad d ser refleja ada con el co olor rojo. El azul a indica q ue las activid dades se de esarrollan no ormalmente.
Figura F 80. Diag grama de Gantt t de un proyect to
198
7.5 N Notificacio ones
nfigurando previamente el e servidor de e correo SMTP, Redmine e permite en nviar notificac ciones Con por c correo electr nico en tod dos los proye ectos, definie endo antes los l eventos que activan estos aviso os. Adems cada usuario en su c configuracin n puede ele egir recibir notificacione es de cualq quier evento, o solo las s relacionad as con l (por ( ejemplo o uno de los s campos de d las petici iones son las s personas en e seguimien nto). Puede configurarse c adems el s servidor de correo c entra ante, permitie endo as act tualizar petic ciones simplemente por email e inclluso crear nuevas iones. Toda la actividad de cada pr royecto tamb bin puede exportarse e e en Atom, para ser petici ida desde un segui n lector RSS S. Si ninguna a de estas op pciones es fa avorita, en to odos los proy yectos existe e el mdulo de "Actividad d", que reflejja todo el flu ujo por das en e el proyect to y lo mues stra en ista. una li
Figura 81. Notificacin n de una tarea en e el correo ele ectrnico
7.6 A Administr racin de noticias, n d documentos, archiv vos y fiche eros
A tr ravs de la herramienta h se pueden g generar noticias en los proyectos, v visibles para todos los m miembros, as simismo les permite a los usuarios s autorizado os del proye ecto gestionar los docum mentos, con n la subida de los mismo os. Esta mism ma funcionalidad se pue ede utilizar para p la subid da de archivo os particulare es y ficheros de distinto formatos; f est tos ltimos s se utilizan pa ara ser index xados en las peticiones y secciones d del gestor.
199 Presupues sto del pro oyecto 7.7 P
a provee una plugin lllamado Bu udget Modu ule que pe ermite calcular el La herramienta otras cosas, esto presu upuesto del proyecto se egn el uso de los recursos utilizados. Entre o permite cotizar la a hora de ca ada recurso o humano ut tilizada, para a que el dire ector del pro oyecto dispo onga de form ma clara sobr re los gastos del proyecto o realizados hasta una d eterminada fecha, f y de esta forma contrastarlo c con c la planifi ficacin realiz zada. A cont tinuacin se muestra una a hoja resupuesto de d un proyect to indicando claramente los costes de cada etapa a. de pr
Fig gura 82. Hola d de presupuesto os de un proye ecto
7.8 E Exportaci n a distin ntos forma atos
s informes de e peticiones que pueden generarse aadiendo a filtros, y que p permiten visu ualizar Los las diferentes tare eas de un proyecto, pue eden exporta arse en PDF o formato C CSV, pudiend do as mirlos posteriormente en n un formato o organizado o. Esto permite a un Dire ector de Proyecto, imprim dispo oner rpidam mente de info ormacin gen nerada por el e proyecto pa ara ser prese entada ante quien lo sol licite. Otro o punto inter resante es que q las pgin nas de la wiki tambin pueden p expo ortarse en HT TML o TXT.
7.9 A Anlisis grfico
sistema perm mite realizar anlisis a grfi cos de la ge estin de proyectos seg n sea su act tividad El s en el transcurso del tiempo. Esta E informa acin presen ntada en form ma de grfico os puede se er muy
200
til pa ara hacer un n anlisis cor rrecto de la s situacin. A continuacin c se muestran n algunas gr raficas generadas por el sistema:
Figura 83. Peticiones creadas comparadas con c las peticiones actualizad das
ura 84. Crecim iento de activid dades en el tie empo Figu
7.10 0 Otras car racterstic cas
r razones de e contenido no se puede en detallar todas t las fun ncionalidade es de Redmine en Por este captulo. Por tal motivo es e important te comentar como otras funcionalidad ntes a des importan acar: desta la pgi ina persona al de cada usuario, que ofrece una u vista pe ersonalizable e con informacin de todos los proy yectos donde e est partic cipando, com mo un calen ndario global, o peticiones asignadas.
201
la integ gracin con Repositorio os como CM MS, Subversi n, etc. la posib bilidad de def finir campos s personaliz zados para cada c mdulo o. la barra a de bsque eda global. la posib bilidad de am mpliar la funciionalidad con n decenas de d extension nes. la integ gracin con diferentes b bases de da atos MySQL, , SQLite y Po ostgreSQL.
7.10.1 Usabilidad d d la interfa ace 7.10.1.1 Diseo de diseo de la aplicacin tie ene una inte erface web muy m sencilla y que la hace e fcil de ma anejar. El d Para cada proyec cto existen una u serie de pestaas fij jas en la par rte superior q que organiza an los difere entes mdulos. Dentro de cada m dulo se mu uestra la informacin co orrespondien nte de forma a limpia y ord denada, y a la derecha s se suelen inc cluir una serie e de opcione es variables segn s la ve entana. El uso es muy simple y de estaca la fa acilidad para a configurar los proyect tos, la visibilidad del m dulo de "Ac ctividad", y l os colores elegidos e que e no recarga an la herram mienta. Adem ms incluye algunos a tema as o skins y o otros que pu ueden descar rgarse.
Figura 85. Interfaz de Re edmine con su men de funcionalidades
7.10.1.2 Facilidad de uso La a aplicacin es s muy sencilla de usar y aunque el mbito princip pal puede se er el empresa arial o el de desarrollo de d software, cualquier c usu uario medio podra usar Redmine pa ara administrar sus s o tareas. La navegaci n web se ha ace muy intuitiva, e inclus so puede rec cordar propios proyectos de algunos blogs. a la d
202
La estructura, y la profundidad de las opciones y configuracin estn muy bien elegidas, encontrando cada cosa en su lugar indicado. Puede requerir varios minutos conocer todo en profundidad, pero la funcionalidad principal es palpable.
7.10.2 Accesibilidad Redmine no est dotado con funciones de fcil acceso para personas con problemas de accesibilidad de cualquier tipo. De todas formas la aplicacin puede integrarse perfectamente con cualquier tecnologa de asistencia del sistema operativo, y con cualquier opcin relacionada con el navegador de internet. 7.10.3 Portabilidad/Adaptabilidad 7.10.3.1 Plataformas disponibles Redmine es una aplicacin servidor multiplataforma basada en Ruby on Rails. Los nicos requisitos para instalar Redmine en una mquina son: una base de datos (que puede ser MySQL, PostgreSQL o SQLite), y Ruby y Ruby on Rails en sus versiones apropiadas. Si una mquina sostiene esto, puede instalarse Redmine independientemente de la plataforma. Rails funcionar sobre cualquier sistema operativo. A nivel de cliente, Redmine puede ser accedido desde cualquier plataforma o sistema operativo, tan solo hace falta conexin a la red apropiada y un navegador de internet.
7.11 Plugins
Redmine dispone de un gran nmero de plugins que rondan la cifra de 100 extensiones. Estos plugis estn disponibles en la siguiente direccin web:
www.redmine.org/wiki/redmine/Plugin_List En la lista del anterior enlace vienen los autores de cada uno, una pequea descripcin, versin compatible y de dnde obtenerlo. Pinchando en cada uno se visualiza una ficha especfica para cada plugin, con informacin adicional como la instalacin, la actualizacin o capturas. Son muy variados y se adaptan a distintas necesidades. Se pueden destacar algunos dedicados a generar grficos (Charts), a establecer tiempos para cada tarea (Timesheet) o a crear salas de chat (Chat). Para ms informacin sobre los plugin, como por ejemplo tutoriales y guas de desarrollo para crear propios, hay una pgina especfica en la wiki de Redmine:
www.redmine.org/wiki/redmine/Plugins
203
Tam mbin son interesantes lo os plugins de e terceros, extensiones e que q utilizan o otras aplicac ciones para grarse integ con Redmine de algun a ma anera:
g/wiki/redmine/ThirdParty yTools www.redmine.org r ejemplo hay y disponibles s del entorno o de desarro ollo Eclipse, el e navegado or Firefox o para p el Por telfo ono iPhone.
7.12 2 Licencia/ /Distribucin
v2 (GNU Ge eneral Public License, v version 2), cuyos La licencia de la aplicacin es GPL v trminos se pueden consultar r en el siguie ente enlace: www.gnu.org w g/licenses/gp pl-2.0.html sumidamente e define a la aplicacin c como softwar re libre, con libertad de u uso, modifica acin y Res distrib bucin.
Descarga D de R Redmine Redmine R pued de descargars se de forma lib bre y gratuita desde su pg gina oficial ( (que a su vez est montada en R Redmine): ww ww.redmine.org rg/wiki/redmine e/Download
sde el enlace e estn dispo onibles las ltimas desca argas, entre ellas la ltim ma versin estable Des de la a herramienta a, siempre en e cdigo fu uente. Existe en paquetes para Debia an y distribuc ciones deriva adas, e insta aladores par ra otras plata aformas, per ro no se prop porcionan dir rectamente desde la pla ataforma de Redmine, si i no que se consideran paquetes de e terceros. E Estos paquet tes no tienen e actualizado os con la lt tima versin, pero en co oncreto la ve ersin n por qu estar siempre para este anlisis s proviene de e un paquete e .deb de una versin de Redmine co on solo un mes m de edad. antig Des sde la propia pgina no se ofrece en servicios o soporte sobre Redm mine porque e est mantenido por un na comunida ad de volunta arios, pero existe e una gran cantidad de empresa as que ajan con ella y ofrecen ins stalaciones, s soporte, form macin o des sarrollos. trabaj Se puede robar pr Redm mine en una demo online habilitada desde d la propia p
demo.redmin ne.org web:d

Demo D online de Redmine Se S puede pr robar Redmin ne en una demo online h habilitada de esde la propia demo.redmin ne.org
204
Licencia de mdulos/extensiones: Los plugins de Redmine pueden o no tener la misma licencia de la aplicacin. De hecho, hay algunos con licencia MIT. Aunque todos se pueden considerar libres, se recomienda leer la licencia de cada caso particular. La herramienta debe ir acompaada de un completo plan de mejoras de informacin, para que los miembros de la organizacin aprendan a manejar la herramienta de forma rpida y eficaz. Esto se ofrece a partir de un servicio completo.
7.13 Comparacin con otras aplicaciones de Gestin de Proyectos
En este captulo se presentaron las principales funcionalidades de utilizar Redmine como herramienta de gestin de proyecto. El uso de dichas funcionalidades se convierte en ventajas competitivas para un Director de Proyectos. Es importante recordar que los autores del libro se basaron en esta herramienta debido a su experiencia en el uso de la misma. Con la intencin de que el lector no conozca solamente esta herramienta, se agrega una comparacin entre Redmine y otras herramientas similares. En la tabla siguiente se muestra una comparacin entre las principales aplicaciones, de cdigo abierto bajo plataforma WEB, para gestin de proyectos de Software.
Administracin de Docume ntacin
Aplicacin
Se guimie nto Administracin Administracin Colaborativo de pe ticione s de Re cursos de Proye cto

X X X X X X X X X X X X X X X X
do tP ro je c t e Gro puWa re P ro je c t.ne t R e dm ine Tra c R e a dys e t
X X X
Figura 86. Principales aplicaciones, de cdigo abierto bajo plataforma Web, para gestin de proyectos de software
7.14 Conclusin del empleo de Redmine
Las bondades de disponer una herramienta para la gestin de proyectos como Redmine, hacen que sea una alternativa vlida para que un director de proyectos decida gestionar su proyecto por medio de una herramienta informtica. Redmine es una herramienta eficiente para cualquier organizacin en crecimiento, que maneje una cierta cantidad de proyectos de diversa ndole.
205
La experiencia en el uso de la misma y su posibilidad de adaptacin a los procesos de cualquier organizacin, hacen que esta herramienta sea til para un equipo de trabajo. Utilizar una herramienta correcta para la gestin de proyectos permitir tener una mejor planificacin, seguimiento y control de un proyecto, y con todo esto, un producto o servicio de mejor calidad.
CONCLUSIONES
A diario, en diferentes organizaciones, muchas personas asumen el papel de directores de proyectos. No todas las personas estn preparadas para dirigir un proyecto. Resulta clave saber implicar a la direccin para dotar al gestor de proyectos de la relevancia que realmente tienen en los resultados de la organizacin. Cada vez se requiere ms formacin para un director de proyecto. Actualmente, la gestin de los proyectos depende en exceso de la experiencia del gestor de proyectos, por lo que es necesario disponer de un conjunto de buenas prcticas para la gestin de proyectos. Una mala gestin de proyectos desemboca a menudo en la no definicin de necesidades de usuario final, en excesos de costes y en retrasos en la entrega de los proyectos. En otras palabras, la calidad del proyecto no ser buena. Las causas de estos problemas pueden ser omisiones realizadas durante el desarrollo de sistemas, definicin imprecisa de objetivos, estimaciones de costes prematuras, deficientes tcnicas de estimacin, mala gestin de tiempo, falta de liderazgo y comunicacin, etc. Entre las funciones bsicas de la direccin de proyectos se incluyen la planificacin de las tareas de proyecto, la eleccin del equipo de proyecto, la organizacin y la planificacin de los esfuerzos del proyecto, la direccin del equipo y el control de la evaluacin del proyecto. El director del proyecto es el mximo responsable del proyecto. Las Metodologas en la Gestin de Proyectos se empieza a aplicar en empresas u organizaciones que adquieren un tamao o complejidad elevados, o cuando la empresa est en un punto de madurez empresarial en el que ya no est tan preocupada por su subsistencia sino por su productividad y su analtica para mejorar. Hay muchos tipos de Metodologas (giles, ligeras, pesadas), un buen Gestor de Proyectos debe conocer unas cuantas en profundidad (modo de aplicacin, cmo, por qu) para poder elegir la adecuada para su Proyecto. El Gestor de Proyectos elegir la Metodologa adecuada en funcin del Proyecto, de las necesidades y de las Personas que participen en el desarrollo de ese proyecto. El director de proyectos es un equilibrista que tiene que balancearse siempre entre recursos humanos y materiales, tratando de equilibrar costes y plazos, previniendo riesgos y eventos que puedan afectar el curso normal del proyecto. Un director de proyectos debe ser un facilitador de soluciones constantemente. Dirigir un proyecto informtico es un arte que requiere conocimientos, habilidades y experiencia. En el transcurso de este libro, hemos intentado proveer al lector de un conjunto de conocimientos bsicos para la gestin de proyectos, basado en las principales bibliografas disponibles en el mercado. Muchas veces hicimos nfasis en la importancia de adquirir ciertas habilidades que permitan resolver determinas situaciones de la manera ms eficiente posible.
207
Algunas habilidades pueden ser innatas, como la capacidad de liderazgo, y otras podrn ser adquiridas con un buen entrenamiento, como la capacidad de comunicar eficazmente. Tambin, hemos intentando agregar contenidos de experiencia de los autores en cada uno de los temas abordados, y aunque nuestra intencin es la mejor, y el lector repasara este libro varias veces, tenemos que prevenir que la experiencia se la hace andando, acertando y cometiendo errores. Solo el tiempo puede brindarnos esta herramienta de manera eficaz. Recomendamos al lector, seguir esta bibliografa, pero tambin aprender de su ejercicio diario. Durante este libro hemos desarrollado las principales fases de un proyecto informtico, detallando las actividades comnmente llevadas a cabo en cada fase y los puntos ms importantes a tener en cuenta por el director de proyectos. Adems se ha desarrollado un caso de estudio para clarificar los conceptos tericos descritos. Tambin hemos redactado informacin adicional sobre sistemas informticos para la direccin de proyectos, haciendo nfasis en la tecnologa disponible por la comunidad del software libre. Las herramientas para Gestin de Proyectos deben adaptarse a los niveles de desarrollo de los grupos, servir como gua en la gestin, facilitar el seguimiento continuo, integrarse con el resto de la empresa, ser entornos colaborativos con acceso desde cualquier lugar y permitir la Gestin del Conocimiento, de Tareas y de Personas. Podramos concluir que hemos reunido un conjunto de Buenas Prcticas en Direccin y Gestin de Proyectos Informticos, y que las mismas han sido plasmadas en este libro en los diferentes captulos desarrollados con el fin de proveer de herramientas que permitan al lector gestionar y dirigir un proyecto con calidad.
NOTAS
Casos
Cary Cherniss ............................................................................................................................ 189 Charles Babbage ....................................................................................................................... 199 Craig Larman ............................................................................................................................. 154 Daniel Goleman ......................................................................................................... 183, 184, 189 Domingo Ajenjo ............................................................................................................. 22, 53, 152 Dr. Graeme Edwards ................................................................................................................... 31 Edsger Dijkstra .......................................................................................................................... 130 Gregory M. Horine ............................................................................................................. 180, 189 Howard Gardner ........................................................................................................................ 182 Jim Collins ................................................................................................................................. 180 Jos Ortega y Gasset .................................................................................................................. 25 Lloren Fbregas ........................................................................................................................ 154 Luis Jos Amendola .......................................................................................................... 177, 186 Michael Page ............................................................................................................................... 14 Paul J. Mayer............................................................................................................................... 11 PhD Ing. Alexander Prieto Len .................................................................................................. 74 Shirley Hufstedler ...................................................................................................................... 160 Stephen Covey .......................................................................................................................... 186 Thorndike................................................................................................................................... 182
BIBLIOGRAFA Y REFERENCIAS WEB
Recopilacin de fuentes: AJENJO, DOMINGO ALBERTO. 2005. Direccin y gestin de proyectos; Un enfoque prctico. 2 ed. Espaa, RA-MA. PROJECT MANAGEMENT INSTITUTE. 2008. Gua De Los Fundamentos Para La Direccin De Proyectos (PMBOK Guide). 2 ed. Estados Unidos, ANSI. GUTIRREZ DE MESA, JOS ANTONIO - PAGS ARVALO, CARMEN. 2008. Planificacin y gestin de proyectos informticos 2 ed. Espaa. Universidad de Alcal COLLINS, JIM. 2002. Empresas que sobresalen. 2 ed. Estados Unidos, Grupo Editorial Norma. PRESSMAN, ROGER. 2005. Ingeniera del Software, un enfoque prctico. 6 ed. Estados Unidos, McGraw-Hill. WIEGERS, KARL. 1999. Software Requirements. 2 ed. Estados Unidos, Microsoft Press. JACOBSON, IVAR; BOOCH, GRADY; RUMBAUGH, JAMES. 2000. El Proceso Unificado de Desarrollo de Software; La gua completa del Proceso Unificado escrita por sus creadores. Madrid, Editorial PEARSON EDUCACION. PETERS, THOMAS; WATERMAN, ROBERT. 1992. En busca de la EXCELENCIA; Experiencias de las empresas mejor gerenciadas de los Estados Unidos. 5 ed. Estados Unidos, Grupo Editorial Norma. MINISTERIO DE ADMINISTRACIONES PBLICAS DEL GOBIERNO DE ESPAA. 2006. Mtrica V3; Metodologa de Planificacin, Desarrollo y Mantenimiento de sistemas de informacin. 1 ed. Espaa. COVEY, STEPHEN R. 2005. Los siete hbitos de las personas altamente efectivas. 2 ed. Estados Unidos, PAIDOS. AMENDOLA, LUIS JOSE. 2006. Estrategias y Tcticas en la Direccin y Gestin de Proyectos. 1 ed. Espaa. Editorial UPV. HORINE, GREGORY. 2009. Gestin de Proyectos. 1 ed. Espaa, Editorial Anaya Multimedia. GOLEMAN, DANIEL. 1996. Inteligencia Emocional. 1 ed. Estados Unidos, Editorial Kairs.
211
GOLEMAN, DANIEL; CHERNISS, CARY. 2001. Inteligencia Emocional en el Trabajo. 1 ed. Estados Unidos, Editorial Kairs. LARMAN, CRAIG. 2003. UML y Patrones. Introduccin al anlisis y diseo orientado a objetos y proceso. 2 Ed. Espaa, Editorial Pearson FRANCES, MONICA; VERNA ETCHERBER, ROBERTO; SCARAFFIA ,CRISTINA. 2011. Promover / Dinamizar verbos de la vinculacin. 1ra Edicin. Buenos Aires, Editorial edUTecNe PAE Portal de Administracin Electrnica del Gobierno de Espaa
http://administracionelectronica.gob.es
ANEXO I: Casos De xito
1. Introduccin
En este anexo I intentaremos mostrar las empresas que ya sea en el desarrollo del proyecto de constitucin de s mismas como entidades de facturacin, como en el transcurso de la serie de operaciones que incluyen sus procesos de negocios, gestionaron eficientemente los factores claves para convertirse en exitosas, y lo que es ms importante an, lograron mantenerse. Puntualmente se realizar un seguimiento al caso de xito de tres de ellas, que podran considerarse las ms reconocidas a nivel mundial Google, Apple y Amazon.
2. Empresas exitosas a nivel mundial

A nivel mundial existe un ranking que realiza la revista Fortune de EEUU cada ao. Como se puede comprobar en este ranking, el volumen econmico de las principales empresas del mundo supera con creces al PIB de la mayora de los pases de la Tierra. En cuanto a la fuente de esta informacin, Fortune es una publicacin de negocios (dependiente de Time Warner) fundada en 1.930, cuatro meses despus del "crack "de Wall Street. La revista Fortune es conocida por su elaboracin de rankings de riqueza, mejores compaas para trabajar y todo tipo de estudios relacionados con el mundo de las finanzas.
213
Figura 87. Clasific cacin de las 10 empresas co on mayor factu uracin bruta de d todo el plane eta en el ao 2010, 2 segn datos ex xtrados de la revista Fortune e
Com mo observam mos en el top p ten solo en ncontramos una u empresa a del sector i nformtico, HP H en el puesto N 10. Es tambin sabido que e conseguir informacin relacionada a las activid dades cieras de las s empresas informticas s es difcil, an a para est ta importante e revista. As s que financ vamo os a ver info ormacin filtr rada por otr ras variables s, ms repre esentativas q que la facturacin bruta a.
Ran nking de la as empresa as con may yor precio por accin n en el Nas sdaq Comp posite (Febr rero 2011). Este e informe contiene c los datos de t todas las empresas que participan n en el promedio comp puesto del Nasdaq. N Este ndice, ta nocido como o Nasdaq C Composite, es e un ambin con impor rtante indica ador burstil l de Estado os Unidos. Este E indicad dor burstil incluye todo os los valore es (tanto nac cionales com mo extranjero os) que cotiza an en el mer rcado Nasda aq, un total de ms de 50 000 empresa as. El peso de las empr resas en el ndice se ba asa en la ca apitalizacin de su mercado, con det terminadas normas n de lim mitacin de la influencia de los mayo ores compone entes. ta ponderacin de valore es tecnolgic cos dentro del mercado Nasdaq, ha hecho este ndice La alt muy popular. En este listado o se muestra an las comp paas con mayor m precio o por accin en el
214
momento del cie erre mensua al a febrero de 2011, informacin muy valiosa a para el an nlisis rico. histr
Figura 88. Listado co on las compa as con mayor precio por acc cin a Febrero de 2011
p obs servar que c cuando cons sideramos un ndice tan importante como En este caso podemos daq Composite, que en su composic cin es muc cho ms aba arcativo nos encontramo os con Nasd much has ms em mpresas del sector infor rmtico ocup pando lugare es de privile egio. El mon nstruo Goog gle a la cabe eza, siguind dolo Apple, y como quer riendo entrar r al top ten, A Amazon. Ah hora si nos e enfocamos en una regin n y puntualm ente dentro de un sector r, podemos d darnos cuent ta que la sup premaca se mantiene, con c pequeas s. s diferencias Cu ul es la me ejor empresa a tecnolgic ca de Estado os Unidos? En esta encue esta figuran todas las empresas de d tecnologa que cotiz zan en el ndice DAQ. Desde e empresas de d hardware e, software, in nternet, ener rgas renova ables, automocin, NASD biotec cnolgicas... . Estados Un nidos es hoy y en da la mayor fuente de compaa as revolucionarias que tiene La Humanidad. H La cuna d de las grandes compaas tecnol gicas se centra c cialmente en n zonas como Silicn Vallley o el rea a de Boston, sometidas a la gran influ uencia espec de un niversidades de prestigio como Stanf ford o el Insti ituto Tecnol gico de Mas ssachusetts (MIT). Sin duda, un ento orno difcil de e repetir en o otros lugares s.
215
Figura a 89. Principale es Empresas Te ecnolgicas de e EEUU
Aho ora si bien cambiaron los compet tidores, cont tinuamos ob bservando la a tendencia a, con algun nos mejores posicionamie entos, el cas so de Apple y Amazon.
Ran nking de las s empresas ms admira adas del mundo segn la revista Fo ortune (2010 0) Anu ualmente la revista Fortune hace una encue esta entre empresarios e para evalu uar la reput tacin de las s empresas de todo el mundo. Sin n importar el sector de p procedencia, este rankin ng muestra las 10 empr resas ms va aloradas y admiradas a po or los empre esarios que fueron f encue estados.
216
Fig gura 90. Empre esas ms valor radas y admiradas
3. Casos de e xito
A p partir de lo expuesto trataremos t d de mostrar particularme ente las ca aractersticas s ms sobre esalientes de e cada una de estas e empresas qu ue las llevaron a alcanz zar y mantener la supre emaca.
C corp porativa + in nnovacin 3.1 GOOGLE: Cultura uso del busc cador Google e est tan ex xtendido que e la edicin 2007 del dic ccionario Me erriamEl u Webs ster contiene e el verbo tra ansitivo "to g google": busc car una infor rmacin conc creta en Inte ernet a travs de un bus scador, partic cularmente G Google. C mo ha cons seguido Goog gle este lide erazgo e los buscad dores?, y c mo espera mantenerlo? Pues, sob bre todo, gracias a en el mercado de ultura de emp presa y su co onstante apu uesta por la innovacin. su cu Par ra analizar la a trayectoria de esta emp presa, nos re emontamos al a ao 1995. Por entonce es, los busca adores respo ondan a la filosofa f de d directorio, y eran person nas quienes principalmen nte se encar rgaban de la a categorizac cin de las p pginas web b. Pero la ing gente cantida ad de inform macin online e hizo impra acticable la indexacin manual. En n diciembre de 1995 a apareci el primer p busca ador basado o en la exploracin autom mtica y exhaustiva de la a web, AltaV Vista. Unos meses m antes s, Sergey Br rin y Larry Page P se hab ban conocid do en la Univ versidad de Stanford. Juntos, desar rrollaron un algoritmo para la bsqu ueda de info ormacin en n grandes ba ases de datos. El motor de bsque eda de Brin y Page orde enaba las p ginas con contenidos c s similares seg gn el
217
nmero de enlaces que les apuntaban; en su opinin, cunto ms apuntada era una pgina, ms popular resultaba y, por tanto, ms arriba en la lista de resultados mereca estar. Durante 1998, los estudiantes de Stanford rechazaron varias ofertas de compra de su tecnologa y, finalmente, decidieron crear su propia empresa con dinero de amigos y familiares. En verano de ese ao, el cofundador de Sun Microsystems, Andy Bechtolsheim, les firm un cheque por valor de 100.000 dlares a nombre de Google Inc., y los dos jvenes emprendedores constituyeron una empresa en una cochera de Menlo Park, en la ciudad Silicn Valley en California. Fue entonces cuando la empresa qued registrada como tal. En 1999, los grandes fondos de capital riesgo pusieron sus ojos en la empresa y, con la financiacin apropiada, le dieron el empujn definitivo, que la ha convertido en el lder de las bsquedas en Internet. En el ao 2000, Google ya superaba en trfico al buscador AltaVista y, en 2002, AOL (America OnLine) lo eligi como motor de bsqueda por defecto para sus ms de 34 millones de miembros. En agosto de 2004, Google sali a bolsa con un precio de 85 dlares por accin y obtuvo un capital total de 1.200 millones de dlares. Desde entonces, el valor de la empresa en bolsa no ha dejado de crecer hasta superar la barrera psicolgica de los 500 euros el 21 de noviembre de 2006.
A cualquier usuario que se le pregunte y t porque usas Google? va a contestar algo parecido a: Casi siempre encuentro lo que busco sin tener que perder tiempo en visitar sitios que no me interesan. Es muy rpido. Es muy fcil de usar.
Algo ms que publicidad A mediados de los aos noventa, la mayora de buscadores obtenan sus ingresos de la publicidad que insertaban en sus pginas de resultados de bsquedas. Google decidi diferenciar totalmente entre los resultados de una bsqueda y los anuncios pagados; as, los resultados de una bsqueda en Google aparecen en una lista situada a la izquierda y los anuncios "breves textos sin imgenes" aparecen a la derecha de la pgina. Dichos anuncios presentan cierta relevancia para los internautas, ya que estn relacionados con sus bsquedas. Pero los ingresos de Google procedan principalmente de la concesin de licencias de su tecnologa de bsqueda a terceras pginas.
218
Al poco tiempo el buscador lanz AdWords, un programa de publicidad "autoservicio" que se puede activar online con una tarjeta de crdito en cuestin de minutos. Google slo cobra al anunciante cuando un navegante haga clic en el anuncio, independientemente del nmero de veces que ste aparezca en la pgina de Google. Cada vez que un internauta utiliza una palabra, Google decide qu anuncio publica de entre los anunciantes que han apostado por dicha palabra. Esta decisin es fruto de la puja y su estimacin de las posibilidades de clic y, por tanto, de su ingreso. AdWords permite crear una campaa desde cinco euros, lo que ha conseguido atraer a pequeos negocios. En 2003, Google introdujo Adsense. Este programa permite a cualquier pgina web de terceros incorporar anuncios que Google haya concertado siguiendo la filosofa AdWords. Al convertirse en mayorista de publicidad, Google ofrece a cualquier pgina con trfico la posibilidad de cobrar por publicidad, quedndose con una comisin. El marketing de bsqueda funciona tan bien que, en enero de 2007, el cobro de licencias de su tecnologa supuso menos del 1% de los ingresos totales de Google, que ya en 2005 ascendieron a 6.139 millones de dlares. Pero Google no ha limitado su negocio al segmento de la bsqueda, sino que ha entrado en el escritorio de los usuarios de la mano de aplicaciones como Google Pack. Siguiendo con la filosofa de no cobrar al usuario y de que la monetizacin ya aparecer con el tiempo, todos estos servicios son gratuitos. Otro de los segmentos en los que Google ha entrado es en el de los servicios dirigidos a desarrolladores de pginas web, entre ellos herramientas de ayuda para la gestin de campaas publicitarias.
Organizarse para innovar. Una de las claves del xito de Google ha sido su capacidad para poner en prctica rpidamente ideas innovadoras sin dejar de ser el mejor motor de bsqueda del mercado. As, la cultura corporativa de Google puede resumirse en cinco puntos: 1) Pensar al revs. La empresa est convencida de que los modelos de negocio aparecern sobre la marcha y prioriza la tecnologa por encima del negocio. 2) Actuar permanentemente en beta. De esta forma, los clientes se convierten en aliados en el aprendizaje del producto. 3) Innovacin continua y ejecucin veloz, en lugar de la perfeccin absoluta. 4) Renuncia al marketing formal. 5) Creacin de reglas propias, como demostr con su salida a bolsa en una subasta en Internet.
219
Con n esta filosof fa, Google ha h implantad do una serie de iniciativas para fome entar la creat tividad de su us ingenieros s, presionado os por el da a da. Para ello ha instit tucionalizado o la regla del l 20%, que p permite a lo os ingenieros s dedicar el 20% de su u tiempo a trabajar en p proyectos qu ue les apete ezca e ilusio one. Productos como Go oogle News, Gmail o la red social O Orkut son fru uto de esta i iniciativa.
3.2 GOOGLE Y APPLE Po or qu Goog gle y Apple tienen t negoc cios rentable es y exitosos s y yo no pu uedo ganar dinero d con m mi idea de ne egocios?
Idea as de negoc cios.
a imagen re esume muy claramente uno de Esta los fa actores del xito de Go oogle y Applle como mode elos de negocios. Ambo os se conce entraron en lanzar al merc cado productos simples para no undir a sus potenciales p clientes c y as s poder confu vende er sus produ uctos y ganar r dinero con ellos. En el extremo superior de e la imagen est el conce epto de los productos Apple A que ra adica en que simplement te con un botn se podra acced der a todo un n mundo de tecnologa. La f foto siguient te es la simp plicidad de la a pgina de b bsquedas de d Google, podemos r recordar otros motores de bsqueda a como Yah hoo que eran ms complic cados. Al fin nal de la foto o est el produ ucto comple ejo en con ntraposicin de la simpl licidad de Go oogle y Apple e. La f foto evidente emente tiene e un toque de e humor pero refleja con claridad c el co oncepto de q que toda resa debe de e seguir que e cuanto m s fcil y empr simpl le sea su pro oducto, ms fcil ser tr ransmitir su ide ea de negoc cios a sus po otenciales cllientes y as po odr vender ms y ganar ms dinero o.
Figura 91. Simplicidad S de Google y Applle
ANEXO II: Herramientas De Financiamiento De Proyectos
1. Introduccin
En este anexo se intentar dar un panorama general de las herramientas para la financiacin de proyectos que existen en el medio pblico y privado, sus objetivos y alcances. Cabe precisar que en el contexto habitual donde se desarrollaron y se adquirieron la mayor parte de las experiencias volcadas al presente libro, el trmino PYMES identifica a Pequeas y Medianas Empresas que son el motor del desarrollo regional y fuente de trabajo e innovacin permanente, las cuales tienen un volumen de produccin y plantillas de RRHH menor al de las empresas constituidas, y estn directamente relacionadas a la gestin de proyectos. El director de proyectos en su proceso de desarrollo profesional incursiona inicialmente en proyectos desarrollados por estas pymes, principalmente porque es requisito fundamental para que las mismas puedan posicionarse con una con una oferta competitiva importante, que sus proyectos sean planeados, ejecutados y mantenidos como lo venimos mostrando en este libro. Asimismo financiar dichos proyectos requiere de la aplicacin de las competencias con las que cuenta un director de proyectos, que en definitiva debe lograr alcanzar los objetivos con recursos limitados, como lo son los econmicos. Por lo que este anexo se desarrollar entre estos contenidos. Primeramente podemos decir que en general el sector financiero privado en Argentina no se ha mostrado demasiado predispuesto a ofrecer crditos blandos para el desarrollo de proyectos innovadores y/o para la financiacin de capital de riesgo. En ese marco, una herramienta clave de financiamiento est representada por los bancos, siendo una de las principales fuentes de financiacin externa para las pymes (Pequeas y Medianas Empresas); en particular cuando superaron la etapa de iniciacin y las utilidades no son suficientes para autofinanciarse. La mayora consisten en prstamos bancarios cuyas tasas de inters suelen ser ms altas que las que se ofrecen en las lneas de los Estados nacional o provincial, y uno de los inconvenientes que tienen los pequeos empresarios para acceder al crdito es la dificultad para presentar garantas reales que respalden la operacin; es decir, estn limitadas en su capacidad de obtener prstamos, porque el valor de sus activos o el monto de su capital societario, no cubre los requisitos de patrimonio computable en relacin con el crdito solicitado. En cuanto a las herramientas financieras del Gobierno, se ofrecen alternativas de financiamiento a partir de sus polticas de apoyo a las micro y pequeas empresas. En general son programas que tienden a dar soporte a la inversin en bienes de capital, activos de trabajo, incorporacin de procesos de calidad e innovacin y modernizacin tecnolgica. Estos programas, adems de crditos, ofrecen bajo ciertas circunstancias que son especficas de la lnea, la posibilidad de subsidios o Aportes No Reembolsables (ANR) y crdito fiscal.
221
Es para destacar que tanto los subsidios que se otorgan como el crdito fiscal, en todos los casos e independientemente del organismo que lo otorgue, deben contar, para su realizacin, con una efectiva rendicin de gastos. Por lo tanto, es una ayuda para financiar nuevos proyectos o emprendimientos, fomentando la modernizacin y la innovacin tecnolgica, pero no puede ser utilizado para quien no dispone de capital para comenzar con el proyecto. En estos casos, se sugiere tratar de tomar crditos dentro del mismo sistema de apoyo a empresas por parte del Gobierno, pues se otorgan a tasas de inters subsidiadas, notablemente inferiores a la que ofrecen los bancos privados. Tanto en uno como en otro caso, es importante mantenerse atento a las actualizaciones que ao a ao se van produciendo en las lneas o programas, sobre todo en los que del Gobierno depende. De acuerdo con la dinmica de las realidades empresarias del medio y del mundo laboral, se contemplan nuevas situaciones como, es el caso de los emprendedores que no estaban contenidos en las lneas tradicionales de financiamiento en la actualidad fueron incorporados. Es importante tener un breve conocimiento de la existencia de estas lneas de financiamiento que ofrece el gobierno nacional Argentino, para poder aprovechar estas oportunidades de financiamiento de proyectos.
2. Organismos proyectos
nacionales
con
herramientas
de
financiacin
de
Todos los organismos nacionales tienen como requisito indispensable, para la solicitud ya sea de crditos, subsidios o aportes no reembolsables, la presentacin de un documento de proyecto, que debe ajustarse a los trminos y condiciones fijadas en las bases de la lnea y en los formularios diseados a tal fin. Las bases, como los formularios mencionados, estn disponibles en las pginas web de cada organismo. Es importante tener en cuenta bajo que modalidad se presentan los proyectos. As podemos encontrar las siguientes modalidades: Ventanilla permanente: los proyectos a financiar no tienen fecha lmite. Por lo tanto, sin plazos determinados, el proyecto puede presentarse en cualquier momento. Ventanilla no permanente o convocatoria pblica: Las bases y condiciones de la convocatoria fijan una fecha de cierre, esta fecha constituye el lmite para la presentacin del proyecto. En general, hay una convocatoria por ao.
Tambin hay que destacar que las lneas de financiamiento se destinan en su gran mayora a pymes. El criterio que se utiliza para saber si una empresa es o no pyme y cul es su
222
clasif ficacin es la Resoluc cin SEPYM ME 21/2010 (la que puede ser c consultada desde d www. .sepyme.gob b.ar/legislacio on/): Se ern consideradas micro, , pequeas y medianas s empresas aquellas a cuy yas ventas totales t esadas en pesos argenti inos ($) no s superen los valores esta ablecidos en el cuadro que q se expre detall la a continua acin:
Figura 92. C Clasificacin de d empresas
Se entender por ventas tot tales anuales s, el valor de e las ventas que surja de el promedio de los ltimo os tres bala ances o informacin c contable equ uivalente ad decuadamen nte documen ntada, exclu uidos el Imp puesto al Va alor Agregad do, el impue esto interno que pudier ra correspon nder y deducidas las ex xportaciones que surjan de los menc cionados bal lances o info ormacin con ntable a un mximo del treinta y cinco por ciiento (35%) de dichas ve entas. hasta En los casos de e las empresas cuya an ntigedad se ea menor que la requerid da para el clculo c estab blecido en el l prrafo ant terior, se con nsiderar el promedio pr roporcional d de ventas an nuales verific cado desde su s puesta en n marcha.
Ent tre los organ nismos para a tener acce eso a fondos s en Argentina encontra ramos: 2.1 Ministerio de d Ciencia, Tecnologa T e Innovaci n Productiv va (MinCyT) ) Este ministe erio tiene en n su mbito las siguientes reparticio ones, que so on las que operan o con n las lneas de financiamiento que se presentan en su pgina: www.mincy yt.gov.ar.
-
Agencia a
Nacional
de
omocin Pro
Cientfica C
Tecnolg gica
(ANP PCYT).
www.ag gencia.gov.ar.
223
Figur ra 93. Portal AN NPCYT
Es un organismo descentralizad do que, au unque depende adminis strativament te del st goberna ado por un directorio propio p que se renueva a peridicam mente. MinCyT, es Dispone de e fondos de el Tesoro N Nacional, Prestamos de el Banco In nteramerican no de Desarrollo (BIRF), del recupero d del financiam miento reem mbolsable y proveniente es de d cooperac cin con orga anismos o in nstituciones nacionales e internacionales. convenios de ministracin como Los recurso os pblicos son s en parte otorgados a la Agencia para su adm responsable e de la aplica acin de la L Ley 23877 de e Promocin de la Innova acin Tecnolgica; y de la Ley 25922 de Pr romocin de la Industria del d Software e. as de finan nciamiento de la Age encia cubren una amp plia varieda ad de Las lnea destinatario os; desde cientficos de edicados a la l investigac cin bsica, hasta emp presas interesadas s en mejorar su competitiv vidad a parti ir de la innov vacin tecnollgica. Promueve e el financiam miento de pro oyectos tend dientes a mejorar las con ndiciones soc ciales, econmicas s y culturales s en la Argen ntina a travs s de cuatro fondos: f o Fondo pa ara la Inves stigacin Cientfica y Tecnolgica (FONCyT). Tiene como misin apoyar r a actividad des cuya fin nalidad es la generaci n de onocimientos s cientficos y tecnolgico os, tanto en temticas b sicas nuevos co como ap plicadas, de esarrollados por inves stigadores p pertenecient tes a institucion nes pblicas y privadas sin s fines de lu ucro radicad as en el pas s. o Fondo Fiduciario F de Promo ocin de la l Industria a del Sof ftware (FONSOF FT). Se cre a partir de la sancin de la Ley 259 922 de Prom mocin de la Indu ustria del So oftware. Esta a sostenido por el presu upuesto nacio onal y financia diferentes d a actividades a travs de convocatoriias de crditos y subsidios s:
224
Proyectos
de
investigacin
desarrollo
relacionados
con
actividades comprendidas en el rgimen de promocin (creacin, diseo, desarrollo, produccin e implementacin y puesta a punto de sistemas de software). Programas de nivel terciario o superior para la capacitacin de recursos humanos. Programas para la mejora de la calidad de los procesos de creacin, diseo, desarrollo y produccin de software. Programas de asistencia para la constitucin de nuevos
emprendimientos. o Fondo Argentino Sectorial (FONARSEC). Apoya proyectos y actividades cuyo objetivo sea desarrollar capacidades criticas en reas de alto impacto potencial y transferencia permanente al sector productivo: salud, energa, agroindustria, desarrollo social, TI, nanotecnologa, biotecnologa. El objetivo es acelerar el desarrollo de proyectos pblicos-privados; crear o expandir centros de investigacin orientados al sector productivo, desarrollando una fuerte plataforma local que pueda ser compartida por varias empresas y/o instituciones. o Fondo Tecnolgico Argentino (FONTAR). Financia proyectos dirigidos al mejoramiento de la productividad del sector privado a partir de la innovacin tecnolgica. Entre las lneas de FONTAR que se utilizan mencionamos: CONVOCATORIA PBLICA Aportes No Reembolsables ANR Programa de Crdito Fiscal Crditos Regionales
VENTANILLA PERMANENTE ANR Patentes. Crditos a Empresas (CAE) Fontar-Bice. Aportes Reembolsables a Instituciones (ARAI). Artculo 2 - Crditos para proyectos de Modernizacin. Proyectos Integrados de Aglomerados Productivos (PITEC).
Consejo Federal de Ciencia y Tecnologa (COFECyT).
225
Figura 94. P Portal www.cofecyt.gob.ar
s un cuerp nsejo Feder ral de Cien ncia y Tecn nologa (CO OFECYT), es po de El Con elaboracin, asesora amiento y articulacin estratgica de poltica as y priorid dades es y regiona ales que pro omueven el desarrollo armnico d de las activid dades nacionale cientficas s, tecnolgic cas e innovad doras en todo el pas. Su presidencia es ejercida po or el ministr ro de Cienc cia, Tecnolo oga e Innov vacin va. Es coordinado por su u secretaria general y es st integrado o por las mximas Productiv autoridad des de las pro ovincias y la a Ciudad Aut noma de Buenos Aires, , con competencia en temas s de ciencia, tecnologa e innovacin productiva que q adhieren n a la Ley 25 55467 de Cienci ia, Tecnologa e Innovac cin. Las lne eas de financiamiento de el COFECYT T son todas por convoca atoria pblica a y los recursos administrados a travs s de ellas so on aportes no reembols sables (ANR R). En aso estas subvenciones p pueden exce eder el 70% del coste tot tal del proyec cto. El ningn ca resto de los costes debe ser ap portado com mo contrapar rtida por los s beneficiario os y/o terceros.
encionan a c continuacin: : Dichas lneas se me o PFIP Proyectos Fe ederales de Innovacin n Productiva a. Esta lnea a tiene tivo dar solu ucin, a par rtir de la ge eneracin y transferencia del por objet conocimie ento, a prob blemas socia ales y produ uctivos conc cretos, de alcance municipal l, provincial o regional, identificado os como pr or las rioritarios po autoridades provincia ales en Cie encia y Tec cnologa acr reditadas an nte el YT. COFECY o ASETUR Apoyo o Tecnolg gico al Sector Turism mo. Lne ea de
miento desar rrollada especialmente para dar im mpulso a ce entros financiam tursticos regionales q que requieran innovacin n tecnolgica a y que hayan sido
226
seleccionados conjun ntamente po or las autorid dades de ap plicacin de cada de Turismo, en consona ancia con ell Plan Estratgico provincia y el rea d ble 2006-20 016. Los pr royectos fin nanciados s son aquellos s que Sustentab requieren n de mejoras s tecnolgica as con las qu ue marcar un na diferenciacin y mejor ofe erta turstica. . Los proyec ctos deben beneficiar b a lla mayor cantidad de actores implicados s en el centro o turstico correspondient te. o DETEM Proyectos s de Desarrollo Tecnolgico Muni cipal. Su ob bjetivo general es e jerarquiz zar la calida ad de vida del municiipio a trav s del desarrollo o tecnolgico o a nivel loca al y mejores prcticas p de gestin, con n el fin de dar re espuesta a la as demanda as y necesid dades sociale es, para ase egurar as el desarrollo d s sustentable, en concordancia con n las poltic cas y estrategia as provinciale es. o PFIP-ESP PRO Pr royectos Federales de d Innovac cin ProductivaEslabona amientos Pr roductivos. Destinado a fomentar e l acercamien nto de la ciencia a y la tecno ologa a las necesidades s concretas de la produ uccin nacional. El principall objetivo es s apoyar el desarrollo c competitivo de d las torio naciona al en corresp pondencia co on las cadenas de valor de todo el territ as de desar rrollo regiona al. En este sentido, s la s superacin de d las estrategia debilidade es y desafo os tecnolgic cos represen ntan un gran n impulso para el crecimien nto productiv vo desde un na perspectiva especfic camente sec ctorial. Paralelam mente, se bu usca articula ar el funciona amiento de diversas cad denas de valor a partir de la capitaliza acin y poten nciacin de los efectos de la ovacin tecno olgica en una cadena s sobre el desa arrollo incorporacin de inno de otra.
2.2 Ministerio de Industria a, Secretaria a de la Peq quea y Med diana Empr resa y Desa arrollo Regio onal (SEPYM ME)
Figura 95. P Portal www.sep pyme.gob.ar
227
Esta secretaria orientada a las PYMES tiene un conjunto de lneas de financiamiento que son interesantes en el momento de llevar adelante un proyecto, ya sea para la creacin de una nueva empresa o para modernizar tecnolgicamente una existente. Podemos nombrar: o Programa de Acceso al Crdito y la Competitividad PACC Apoyo a empresas: Es un programa por el que las pymes que invierten en asistencia tcnica para lograr mejoras en la competitividad, innovacin de productos y procesos, ascenso en la escala tecnolgica y certificaciones de calidad, pueden obtener un reintegro, por parte de la SEPYME, de hasta el 60% u 80 % y hasta $130.000. o Programa de Desarrollo Emprendedor Capital Semilla: El programa para el Desarrollo de Jvenes Emprendedores apoya a jvenes de 18 a 35 aos, que tengan una idea proyecto o un Plan de Negocios en los sectores de industria, servicios industriales, TI e investigacin y desarrollo con el aporte de Capital Semilla (Prstamo de Honor), el cual funciona en la modalidad de concurso de proyectos. o Programa de Fomento Financiero para Jvenes Emprendedores-Empresas Madrinas: Uno de los mayores impedimentos para la constitucin o consolidacin de emprendimientos de jvenes consiste en la dificultad para conseguir financiacin. El programa Madrinas, es una herramienta que promueve la constitucin de alianzas entre jvenes emprendedores y empresas consolidadas, la empresa madrina financia hasta el 100% del Proyecto y la SEPYME le restituye el 50 % de la inversin mediante un bono de crdito fiscal; sobre el 50% restante la ley propone: Que la empresa realice al emprendedor una cesin a fondo perdido. Que la Madrina obtenga una participacin accionaria del emprendimiento (Hasta el 49%) o Que la Madrina otorgue al joven emprendedor un crdito blando.
PACC Emprendedores. Componente de Apoyo a la Actividad Emprendedora del Programa de Acceso al Crdito y la Competitividad: Los destinatarios de esta lnea son emprendedores con proyectos prximos a iniciarse, o pymes de menos de dos aos de existencia desde la fecha de la primera venta realizada. Excluye a aquellas empresas cuyas actividades sean de intermediacin, financieras, de seguros o servicios jurdicos o contables. Puede recuperar hasta el 85% del coste de la elaboracin de su plan de negocios, estudio de mercado, diseo de procesos operativos o administrativos, inscripciones y certificaciones, adquisicin de
equipamiento e insumos, diseo y adquisicin de packaging y comunicacin institucional, entre otras actividades. Puede recibir hasta un monto mximo de $110.000.
228 Conclusin
Como vimos en este anexo, existe una amplia gama de alternativas a la hora de buscar financiamiento para los proyectos en los que estar involucrado el director de proyectos, ya sean proyectos puntuales dentro de una pyme o la constitucin de la pyme como proyecto en s. Es importante que el director de proyectos logre combinar sus competencias y habilidades profesionales, as como los contenidos tcnicos expuestos en captulos anteriores con el aprovechamiento de las oportunidades mostradas en materia de financiamiento de proyectos, ya que es fundamental para que los proyectos concluyan exitosamente que el arte de Direccin y Gestin de Proyectos Informticos sea dinamizada en todas sus dimensiones.
230
ANEXO III: ndice De Figuras
Figura 1. Evolucin histrica del concepto de calidad en la industria del software ................... 7 Figura 2. Estructura ocupacional real ......................................................................................... 9 Figura 3. Influencia del Entorno en el Proyecto........................................................................ 11 Figura 4. Influencia del Proyecto en el Entorno........................................................................ 11 Fugura 5. La Labor del Director de Proyectos .......................................................................... 17 Figura 6. Fases Principales de un Proyecto ............................................................................. 20 Figura 7. Secuencia de Fases .................................................................................................. 21 Figura 8. Relacin de Calidad, Costo y Duracin de un Proyecto ........................................... 23 Figura 9. La fase de planeacin genera el Estudio de Viabilidad ............................................ 26 Figura 10. Diagrama Causa-Efecto .......................................................................................... 30 Figura 11. Diferencia contra Soluciones ................................................................................... 31 Figura 12. Factores que intervienen en la generacin del Acta de Constitucin del Proyecto 33 Figura 13. Procedimiento de preparacin de una oferta .......................................................... 42 Figura 14. Evaluacin de Tareas y Paquetes de Trabajo ........................................................ 44 Figura 15. Matriz de Estimacin ............................................................................................... 47 Figura 16. Estimacin del Esfuerzo y Carga de Trabajo .......................................................... 48 Figura 17. Estimacin de Gastos y Presupuesto de Gastos .................................................... 50 Figura 18. Estimacin Econmica ............................................................................................ 52 Figura 19. Grupos de trabajo que conforman el equipo del proyecto ...................................... 60 Figura 20. Ciclo de vida del proyecto ....................................................................................... 62 Figura 21. Fases de ejecucin de proyectos ............................................................................ 63 Figura 22. Estructura de Desglose de Trabajo ......................................................................... 64 Figura 23. Oferta Econmica .................................................................................................... 65 Figura 24. Formato de reporte semanal ................................................................................... 73 Figura 25. Tcnicas de educcin .............................................................................................. 77 Figura 26. Coste por encontrar un error en ERS...................................................................... 79 Figura 27. Ejemplo de atributos Verificables/No verificables ................................................... 83 Figura 28. Estructura de ERS IEEE 830 .................................................................................. 85 Figura 29. Fases de ciclo de desarrollo de software ................................................................ 93 Figura 30. Comparativo ERS IEEE 830 y UML ........................................................................ 94 Figura 31. Ejemplo de Clase .................................................................................................... 96 Figura 32. Ejemplo de Diagrama de Clases del Diseo ........................................................... 97 Figura 33. Modelo iterativo e incremental de desarrollo de sistemas ...................................... 98 Figura 34. Diagrama de Secuencia para el caso de estudio que se viene desarrollando ..... 100 Figura 35. Diagrama de comunicacin para el caso de estudio (I) ........................................ 101 Figura 36. Diagrama de comunicacin para el caso de estudio (II) ....................................... 102
231
Figura 37. Diagrama de comunicacin para el caso de estudio (III) ...................................... 103 Figura 38. Diagrama de Clases para el caso de estudio (I) ................................................... 104 Figura 39. Diagrama de Clases para el caso de estudio (II) .................................................. 105 Figura 40. Diagrama de Clases para el caso de estudio (III) ................................................. 106 Figura 41. Diagrama de Clases para el caso de estudio (IV) ................................................. 107 Figura 42. Diagrama de Clases para el caso de estudio (V) .................................................. 108 Figura 43. Ejemplo de orden de implementacin ................................................................... 116 Figura 44. Arquitectura del caso de estudio presentado ........................................................ 117 Figura 45. Estructura del cdigo del caso de estudio presentado ......................................... 117 Figura 46. BasesDeDatos.Controlador (1) ............................................................................. 118 Figura 47. LogicaDeNegocio (2) ............................................................................................. 118 Figura 48. LogicaDeNegocio.Controlador (3) ......................................................................... 119 Figura 49. WebServices/WebServicesWrappers (4) .............................................................. 119 Figura 50. Pruebas de visin global ....................................................................................... 132 Figura 51. Tabla de pruebas I................................................................................................. 136 Figura 52. Tabla de pruebas II................................................................................................ 136 Figura 53. Tabla de pruebas III............................................................................................... 138 Figura 54. Actividad de pruebas I ........................................................................................... 137 Figura 55. Actividad de pruebas II .......................................................................................... 137 Figura 56. Actividad de pruebas III ......................................................................................... 139 Figura 57. Notificacin de disconformidad ............................................................................. 142 Figura 58. Informe de modificacin de software..................................................................... 143 Figura 59. Hoja de estado del documento .............................................................................. 144 Figura 60. Costes relativos a cada tipo de mantenimiento .................................................... 150 Figura 61. Costes relativos a cada fase ................................................................................. 152 Figura 62. Distribucin del tiempo de Mantenimiento ............................................................ 154 Figura 63. Actividades en la gestin de riesgos ..................................................................... 156 Figura 64. Estructura de categora de riesgos ....................................................................... 160 Figura 65. Anlisis de Riesgos ............................................................................................... 161 Figura 66. Probabilidad de Impacto de Riesgo ...................................................................... 162 Figura 67. Planificacin de la respuesta a los riesgos ........................................................... 163 Figura 68. Clasificacin de respuestas a un riesgo ................................................................ 164 Figura 69. Seguimiento y control de riesgos .......................................................................... 164 Figura 70. Participantes en cada perfil definido segn Mtrica V3 ........................................ 170 Figura 71. Comparativa entre Estilos de Direccin y sus caractersticas .............................. 173 Figura 72. Clasificacin de Competencias Emocionales........................................................ 178 Figura 73. Estilo de Liderazgo, Inteligencia Emocional (IE) y efectividad organizativa, de Goleman y Cherniss (2005) ...................................................................................................... 183 Figura 74. Nuevo Proyecto en Redmine ................................................................................ 193 Figura 75. Permisos del rol analista-funcional........................................................................ 194
232
Figura 76. Detalle de una peticin .......................................................................................... 195 Figura 77. Tareas organizadas por medio de filtros ............................................................... 195 Figura 78. Tiempo dedicado de los miembros a un proyecto, dividido por peticiones........... 196 Figura 79. Calendario de actividades mensuales................................................................... 197 Figura 80. Diagrama de Gantt de un proyecto ....................................................................... 197 Figura 81. Notificacin de una tarea en el correo electrnico ................................................ 198 Figura 82. Hola de presupuestos de un proyecto................................................................... 199 Figura 83. Peticiones creadas comparadas con las peticiones actualizadas ........................ 200 Figura 84. Crecimiento de actividades en el tiempo............................................................... 200 Figura 85. Interfaz de Redmine con su men de funcionalidades ......................................... 201 Figura 86. Principales aplicaciones, de cdigo abierto bajo plataforma Web, para gestin de proyectos de software ............................................................................................................... 204 Figura 87. Clasificacin de las 10 empresas con mayor facturacin bruta de todo el planeta en el ao 2010, segn datos extrados de la revista Fortune ........................................................ 213 Figura 88. Listado con las compaas con mayor precio por accin a Febrero de 2011....... 214 Figura 89. Principales Empresas Tecnolgicas de EEUU ..................................................... 215 Figura 90. Empresas ms valoradas y admiradas ................................................................. 216 Figura 91. Simplicidad de Google y Apple ............................................................................. 219 Figura 92. Clasificacin de empresas..................................................................................... 222 Figura 93. Portal ANPCYT...................................................................................................... 223 Figura 94. Portal www.cofecyt.gob.ar ..................................................................................... 225 Figura 95. Portal www.sepyme.gob.ar ................................................................................... 226
NDICE GENERAL
CAPTULO I. INTRODUCCIN A LA DIRECCIN DE PROYECTOS ..................................... 6
1.1
Por qu es necesaria la direccin y gestin de proyectos? ..................................... 6 1.1.1 Lo nico constante es el cambio ............................................................................. 6 1.1.2 Evolucin histrica del concepto de calidad en la industria del software .............. 6 1.1.3 Tomar el timn del barco ........................................................................................ 7 1.1.4 Demanda laboral en Argentina ............................................................................... 8 1.1.5 Formalizando aptitudes gerenciales a Informticos ............................................... 9 1.1.6 Necesidad de la direccin y gestin del software ................................................. 10
1.2
Conceptos bsicos ................................................................................................... 10 1.2.1 Proyecto ................................................................................................................ 10 1.2.1.1 1.2.1.2 1.2.1.3 1.2.1.4 Definicin .................................................................................................... 10 Caractersticas de un proyecto .................................................................... 10 Tipos de proyectos ...................................................................................... 10 Entorno del proyecto .................................................................................. 11
1.2.2 Direccin de Proyectos .......................................................................................... 12 1.2.3 Proyecto Informtico............................................................................................. 12 1.2.4 Tipos de Proyectos Informticos ........................................................................... 13 1.2.5 Direccin y Gestin de Proyectos Informticos .................................................... 14 1.2.6 Rol del Director del Proyecto ................................................................................ 15 1.2.7 Gestin .................................................................................................................. 17 1.2.8 La empresa ............................................................................................................ 17 1.2.8.1 Definicin de empresa ....................................................................................... 17 1.2.8.2 Dimensiones de la empresa ............................................................................... 18 1.2.8.3 El empresario...................................................................................................... 18 1.2.8.4 El directivo .......................................................................................................... 18
CAPTULO II. FASES DE UN PROYECTO ............................................................................. 20
2.1 Planeacin ...................................................................................................................... 21 2.1.1 Inicio y Definicin del problema ............................................................................ 22 2.1.2 Planificacin del Proyecto ..................................................................................... 22 2.2 Ejecucin ........................................................................................................................ 24 2.2.1 Puesta en marcha .................................................................................................. 24 2.2.2 Fase productiva ..................................................................................................... 25
235
2.2.3 Conclusin del Proyecto ........................................................................................ 25 2.3 Fase de Mantenimiento ................................................................................................. 25
CAPTULO III. FASE DE PLANEACIN ................................................................................. 26
3.1 Descripcin de la Fase de Planeacin............................................................................. 26 3.2 Inicio del Proyecto .......................................................................................................... 27 3.3 Definicin del Problema ................................................................................................. 28 3.3.1 Caso de Estudio: Definicin del Problema ............................................................ 29 3.3.2 Entregable Acta de Constitucin del Proyecto ................................................... 32 3.3.3 Caso de Estudio: Acta de Constitucin .................................................................. 34 3.4 Estudio de Viabilidad ...................................................................................................... 40 3.4.1 Oferta Tcnica ....................................................................................................... 43 3.4.1.1 Pasos para alcanzar una oferta tcnica .............................................................. 43 3.4.2 Oferta de Gestin .................................................................................................. 45 3.4.2.1 Descripcin ......................................................................................................... 45 3.4.2.2 Pasos preliminares para alcanzar una oferta de gestin ................................... 46 3.4.3 Oferta Econmica .................................................................................................. 48 3.4.3.1 Descripcin ......................................................................................................... 48 3.4.3.2 Pasos preliminares para alcanzar una oferta econmica................................... 50 3.4.3.3 Secciones de la Estimacin Econmica .............................................................. 50 3.4.3.4 Entregable Documento de la Oferta ............................................................... 52 3.4.4 Caso de Estudio: Estudio de Viabilidad ................................................................. 54 3.4.4.1 Oferta Tcnica .................................................................................................... 54 3.4.4.2 Oferta de Gestin ............................................................................................... 60 3.4.4.3 Oferta Econmica ............................................................................................... 64 3.5 Contrato Informtico...................................................................................................... 65 3.5.1 Definicin de Contrato Informtico ...................................................................... 66 3.5.2 Partes de un contrato informtico ........................................................................ 67 3.5.2.1 Los contratantes ................................................................................................. 67 3.5.2.2 Parta expositiva .................................................................................................. 67 3.5.2.3 Clusulas o Pactos .............................................................................................. 68 3.5.2.4 Los Anexos .......................................................................................................... 68 3.5.3 Tipos de Contratos Informticos ........................................................................... 69 3.5.3.1 Por el Objeto ...................................................................................................... 69 3.5.3.2 Por el Negocio Jurdico ....................................................................................... 69
CAPTULO IV. FASE PRODUCTIVA....................................................................................... 72
236
4.1 4.2
Descripcin de la Fase Productiva ........................................................................... 72 Anlisis: Ingeniera de Requisitos ............................................................................ 75 4.2.1 4.2.2 4.2.3 4.2.4 4.2.5 4.2.5.1 4.2.5.2 4.2.5.3 4.2.6 4.2.6.1 4.2.6.2 4.2.6.3 4.2.6.4 4.2.7 4.2.8 4.2.8.1 4.2.8.2 Descripcin ...................................................................................................... 75 Tcnicas principales para la Educcin de Requisitos....................................... 77 Especificacin de requisitos del software o ERS ............................................. 78 Identificacin de las personas involucradas .................................................... 79 Problemas para obtener los requisitos ........................................................... 80 Relacionados con las personas involucradas .............................................. 80 Relacionados con los analistas .................................................................... 80 Relacionados con los desarrolladores ......................................................... 81 Entregable Especificacin de Requisitos de Software .................................. 81 Introduccin ................................................................................................ 81 Objetivos de la ERS ...................................................................................... 81 Caractersticas de una buena ERS ............................................................... 82 Esquema de la ERS definida en el IEEE 830-1998........................................ 85 Conclusin del Anlisis .................................................................................... 86 Caso de Estudio: Anlisis ................................................................................. 87 Requisito n33: ABMC de Protocolos .......................................................... 87 Caso de Uso: Registrar Nuevo Protocolo a Cliente ..................................... 87
4.3
Diseo ...................................................................................................................... 89 4.3.1 4.3.2 4.3.3 4.3.3.1 4.3.3.2 4.3.3.3 4.3.3.4 4.3.3.5 4.3.4 4.3.5 4.3.6 4.3.6.1 4.3.6.2 4.3.6.3 4.3.6.4 Descripcin ...................................................................................................... 89 Fallos en el Diseo de Sistemas....................................................................... 91 Entregable Fase de Diseo ........................................................................... 92 Introduccin ................................................................................................ 92 Relaciones de los artefactos del Diseo con los del Anlisis....................... 92 De la ERS al Diagrama de Clases .................................................................. 93 Diagrama de Clases ..................................................................................... 95 Crear Diagramas de Clases del Diseo ........................................................ 96 Resumen .......................................................................................................... 97 Conclusin de la Fase de Diseo ..................................................................... 98 Caso de Estudio: Diseo .................................................................................. 99 Caso de Uso Real: Registrar Nuevo Protocolo ............................................ 99 Diagrama de Secuencia ............................................................................. 100 Diagrama de Comunicacin ...................................................................... 101 Diagrama de Clases ................................................................................... 104
4.4
Implementacin .................................................................................................... 109
237
4.4.1 4.4.2 4.4.2.1 4.4.2.2 4.4.3 4.4.3.1 4.4.3.2 Descripcin .................................................................................................... 109 Preparacin del entorno de generacin y construccin ............................... 110 Implantacin de la Base de Datos Fsica o Ficheros .................................. 110 Preparacin del Entorno de Construccin ................................................ 110 Generacin del cdigo de los componentes y procedimientos .................... 110 Generacin del Cdigo de los Componentes ............................................ 111 Generacin del Cdigo de los Procedimientos de Operacin y Seguridad 112
4.4.4 Construccin de los componentes y procedimientos de Migracin y Carga Inicial de datos.............................................................................................................. 112 4.4.4.1 Preparacin del Entorno de Migracin y Carga Inicial de datos ............... 112
4.4.4.2 Generacin del cdigo de los componentes y procedimientos de Migracin y Carga Inicial de Datos ................................................................................................ 112 4.4.4.3 Realizacin y Evaluacin de las Pruebas de Migracin y Carga Inicial de Datos ................................................................................................................. 113 4.4.5 4.4.6 4.4.7 4.4.7.1 4.4.7.2 4.4.7.3 4.4.7.4 4.4.7.5 4.4.7.6 4.4.8 4.4.8.1 4.4.8.2 4.4.8.3 4.4.8.4 4.4.8.5 4.5 Elaboracin de los Manuales de Usuario ...................................................... 113 Definicin de la formacin de usuarios finales ............................................. 113 Entregable Fase de Implementacin .......................................................... 114 Introduccin .............................................................................................. 114 La programacin y el proceso de desarrollo ............................................. 114 Mapeo de diseos para codificacin ......................................................... 115 Orden de la implementacin..................................................................... 115 Resumen .................................................................................................... 116 Conclusin de la Implementacin ............................................................. 116 Caso de Estudio: Implementacin ................................................................. 117 Estructura de Cdigo ................................................................................. 117 Clase Protocolo.java .................................................................................. 120 Clase ControladorProcolo.java Mtodo Registrar Protocolo ................. 121 Clase ProtocoloDAO Mtodo saveProtocolo ......................................... 123 Clase ProtocoloWs.java Mtodo registrarProtocolo .............................. 124
Pruebas .................................................................................................................. 126 4.5.1 4.5.2 4.5.3 4.5.4 4.5.4.1 4.5.4.2 4.5.5 Descripcin .................................................................................................... 126 La importancia de la deteccin oportuna ..................................................... 127 Tipos de Pruebas ........................................................................................... 127 Ejecucin de las Pruebas Unitarias................................................................ 128 Preparacin del Entorno de las Pruebas Unitarias .................................... 128 Realizacin y Evaluacin de las Pruebas Unitarias .................................... 128 Ejecucin de las Pruebas de Integracin ....................................................... 129
238
4.5.5.1 4.5.5.2 4.5.5.3 4.5.6 4.5.6.1 4.5.6.2 4.5.6.3 4.5.7 4.5.8 4.5.8.1 4.5.8.2 4.5.8.3 4.5.9 4.5.10 4.5.10.1 4.5.10.2 4.5.10.3 4.6
Preparacin del Entorno de las Pruebas de Integracin ........................... 129 Realizacin de las Pruebas de Integracin ................................................ 129 Evaluacin del Resultado de las Pruebas de Integracin .......................... 129 Ejecucin de las Pruebas del Sistema............................................................ 129 Preparacin del Entorno de las Pruebas del Sistema ................................ 130 Realizacin de las Pruebas del Sistema ..................................................... 130 Evaluacin del Resultado de las Pruebas del Sistema ............................... 130 Pruebas de Regresin .................................................................................... 131 Entregable Fase de Pruebas ....................................................................... 132 Introduccin .............................................................................................. 132 Tipos de Pruebas ....................................................................................... 132 Documentos ms usuales en cada fase..................................................... 132 Conclusin de la fase de Pruebas .................................................................. 135 Caso de Estudio: Pruebas .............................................................................. 135 Pruebas Unitarias ...................................................................................... 135 Pruebas de Integracin ............................................................................. 135 Pruebas del Sistema .................................................................................. 135
Implantacin.......................................................................................................... 139 4.6.1 4.6.2 4.6.3 4.6.4 4.6.5 4.6.6 Descripcin .................................................................................................... 139 Capacitacin de Usuarios del Sistema ........................................................... 140 Objetivos de la Capacitacin ......................................................................... 141 La Evaluacin del Sistema ............................................................................. 141 Control de configuracin en la fase de implantacin ................................... 142 Tareas Usuales de la Implantacin del Sistema ............................................ 144
4.7
Conclusin del Proyecto ........................................................................................ 146 4.7.1 4.7.2 Descripcin .................................................................................................... 146 Objetivos del cierre del Proyecto .................................................................. 146
4.7.3 Acciones a seguir por el director del proyecto para efectivamente concluir con el proyecto ............................................................................................................. 147 4.8 Mantenimiento ..................................................................................................... 148 4.8.1 4.8.2 4.8.3 4.8.4 4.8.5 4.8.6 Descripcin .................................................................................................... 148 Tipos de Mantenimiento ............................................................................... 150 Distribucin del Coste ................................................................................... 151 Factores que afectan al coste........................................................................ 152 Distribucin del Tiempo ................................................................................ 153 Tareas Usuales en la fase de Mantenimiento ............................................... 154
239
CAPTULO V. GESTIN DE RIESGOS ................................................................................ 156
5.1 Descripcin ................................................................................................................... 156 5.2 Planificacin de la Gestin de Riesgos ......................................................................... 158 5.3 Identificacin de Riesgos .............................................................................................. 159 5.4 Anlisis de Riesgos ........................................................................................................ 160 5.5. Planificar la respuesta a los riesgos ............................................................................. 162 5.6 Seguimiento y control de riesgos ................................................................................. 164 5.7 Beneficios de la Gestin de Riesgos ............................................................................. 165
CAPTULO VI. RECURSOS HUMANOS ............................................................................... 166
6.1 Introduccin ................................................................................................................. 166 6.2 Perfiles ms comunes en un Proyecto Informtico ..................................................... 167 6.3 El Director del Proyecto ........................................................................................ 170 6.3.1 6.3.2 6.3.3 Definiciones ................................................................................................... 170 Por qu un Project Manager?...................................................................... 171 Habilidades y Caractersticas ......................................................................... 173
6.3.4 Errores comunes de los Directores de Proyectos: .............................................. 174 6.4 Inteligencia Emocional aplicada a la Direccin de Proyectos ............................... 176 6.4.1 6.4.2 6.4.3 6.4.3.1 6.4.3.2 6.4.3.3 6.4.3.4 6.4.4 6.4.4.1 6.4.4.2 Introduccin .................................................................................................. 176 Liderazgo ....................................................................................................... 179 La Comunicacin en el proyecto ................................................................... 183 La importancia de la Gestin de las Comunicaciones en el Proyecto ....... 184 Competencias interpersonales.................................................................. 185 La dificultad de comunicarse ..................................................................... 186 Manejo de conflictos en la comunicacin ................................................. 187 Potenciar el rendimiento del equipo del proyecto ....................................... 187 Principios de Gestin ................................................................................. 187 Tcnicas para potenciar el rendimiento de los equipos ........................... 189
CAPTULO VII. REDMINE, SOFTWARE LIBRE DE GESTIN DE PROYECTOS .............. 192
7.1 Descripcin ................................................................................................................... 192 7.2 Funcionalidades ............................................................................................................ 193 7.2.1 Gestin de mltiples proyectos........................................................................... 193 7.2.2 Personalizacin de proyectos .............................................................................. 193 7.2.3 Gestin de roles................................................................................................... 194 7.3 Sistema flexible de seguimiento de tareas................................................................... 194 7.4 Uso de calendario y Diagrama de Gantt....................................................................... 196 7.5 Notificaciones ............................................................................................................... 198
240
7.6 Administracin de noticias, documentos, archivos y ficheros ..................................... 198 7.7 Presupuesto del proyecto ............................................................................................ 199 7.8 Exportacin a distintos formatos ................................................................................. 199 7.9 Anlisis grfico .............................................................................................................. 199 7.10 Otras caractersticas ................................................................................................... 200 7.10.1 Usabilidad .......................................................................................................... 201 7.10.1.1 Diseo de la interface..................................................................................... 201 7.10.1.2 Facilidad de uso .............................................................................................. 201 7.10.2 Accesibilidad ...................................................................................................... 202 7.10.3 Portabilidad/Adaptabilidad ............................................................................... 202 7.10.3.1 Plataformas disponibles ................................................................................. 202 7.11 Plugins ........................................................................................................................ 202 7.12 Licencia/Distribucin .................................................................................................. 203 7.13 Comparacin con otras aplicaciones de Gestin de Proyectos ................................. 204 7.14 Conclusin del empleo de Redmine ........................................................................... 204
CONCLUSIONES ................................................................................................................... 206 NOTAS ................................................................................................................................... 208 BIBLIOGRAFA Y REFERENCIAS WEB .............................................................................. 210 ANEXO I: Casos De xito ..................................................................................................... 212 ANEXO II: Herramientas De Financiamiento De Proyectos ............................................. 220 ANEXO III: ndice De Figuras ............................................................................................... 230
BuenasPrcticasenlaDireccinyGestindeProyectos Autores: GustavoGabrielMaigua

[verCV] [verCV]
EmmanuelFernandoLpez
DiseodeTapa:Lic.LorenaMilani DiseodeInterior:Ing.GustavoGabrielMaigua CorreccindeEstilo:Ing.GustavoRego ISBN978987 UniversidadTecnolgicaNacionalRepblicaArgentina Rector:Ing.HctorC.Brotto Vicerrector:Ing.CarlosE.Fantini FacultadRegionalTucumnU.T.N.: Decano:Ing.WalterFabinSoria edUTecNeEditorialdelaUniversidadTecnolgicaNacional CoordinadorGeneral:Ing.UlisesJ.P.Cejas DirectordeEdiciones:Ing.EduardoCosso CoordinadoresdelComitEditorial:Ing.JuanCarlosBarberisyDr.JaimeMoragues(a.c.) reasPreprensayProduccin:Tec:BernardoH.BanegaeIng.CarlosBusqued reaComercializacin:FernandoHoracioCejas BuenosAires 2012

Buenas Practicas Proyectos Informaticos

Uploaded by

Document Information

Copyright

Available Formats

Share this document

Share or Embed Document

Sharing Options

Did you find this document useful?

Is this content inappropriate?

Copyright:

Available Formats

Buenas Practicas Proyectos Informaticos

Uploaded by

Copyright:

Available Formats

Editorial de la Universidad Tecnolgica Nacional

ISBN: 978-987-1896-01-1 FacultadRegionalTucumn UniversidadTecnolgicaNacionalU.T.N. Argentina 2012

Editorial de la Universidad Tecnolgica Nacional edUTecNe http://www.edutecne.utn.edu.ar edutecne@utn.edu.ar

Para que mi hijo lo asimile y promueva en el futuro. Emmanuel Fernando Lpez

BUENAS PRCTICAS EN LA DIRECCIN Y GESTIN DE PROYECTOS INFORMATICOS

A Quin Se Dirige Este Libro?

Organizacin Del Libro

BUENA AS PRCTICAS EN LA DIRECCIN Y GESTIN G DE PROYE ECTOS INFORMATICOS

Co onvencio ones Utilizadas

CAPTULO I. INTRODUCCIN A LA DIRECCIN DE PROYECTOS

Por qu es necesaria la direccin y gestin de proyectos?

Industria del Software

Pocas evidencias de uso

Aos noventa Pocas evidencias de uso Pocas evidencias de uso

Algunas evidencias de uso

Figura 1. Evolucin histrica del concepto de calidad en la industria del software

BUENAS PRCTICAS EN LA DIRECCIN Y GESTIN DE PROYECTOS INFORMATICOS

Figura 2. E Estructura ocupacional real

BUENAS PRCTICAS EN LA DIRECCIN Y GESTIN DE PROYECTOS INFORMATICOS

1.2.1 Proyecto 1.2.1.1 Definicin

Un proyecto es un esfuerzo temporal acometido para crear un nico servicio o producto.

Condiciones sociales y econmicas duras

Figura 3. Influencia del Entorno en el Proyecto

Masa del Proyecto Innovacin

Figura 4. Influencia del Proyecto en el Entorno

BUENAS PRCTICAS EN LA DIRECCIN Y GESTIN DE PROYECTOS INFORMATICOS

Hardware o Velocidad de Proceso, S.O., Servicios, etc.

Comunicaciones y Redes o Protocolos, Buses, Cableado, etc.

Auditoras o Sistemas, Seguridad, Calidad, Legislacin

Peritajes o Civiles, Penales, Laborales

Consultora y Asesora o Sobre cualquier actividad.

Seguridad Informtica (ISO 17799) o Seguridad de la Informacin.

BUE ENAS PRCTICAS EN E LA DIRECCIN Y GESTIN DE PRO OYECTOS INFORMA ATICOS

De cualquiera de d los tipos.

BUE ENAS PRCTICAS EN E LA DIRECCIN Y GESTIN DE PRO OYECTOS INFORMA ATICOS

BUENAS PRCTICAS EN LA DIRECCIN Y GESTIN DE PROYECTOS INFORMATICOS

C CAPTU ULO II. F FASES DE D UN PROYEC P CTO

Figura 6. Fase es Principales de d un Proyecto o

Figura 7 7. Secuencia de d Fases

BUE ENAS PRCTICAS EN E LA DIRECCIN Y GESTIN DE PRO OYECTOS INFORMA ATICOS

Esta a fase es exp plicada detalladamente e en el captulo o III del libro.

Figura a 8. Relacin de e Calidad, Cos sto y Duracin de un Proyecto o

BUE ENAS PRCTICAS EN E LA DIRECCIN Y GESTIN DE PRO OYECTOS INFORMA ATICOS

2.3 Fase de Mantenimiento

CAPTULO III. . FASE DE PLA ANEACI N

q importa, sino la plani ificacin. (Dr. Graeme E Edwards) No es el plan lo que

Descripci n de la Fase de Pla aneacin 3.1 D

Figura 9. La L fase de plan neacin genera a el Estudio de e Viabilidad

3.2 Inicio del Proyecto

BUE ENAS PRCTICAS EN E LA DIRECCIN Y GESTIN DE PRO OYECTOS INFORMA ATICOS

3.3 D Definicin n del Problema

BUE ENAS PRCTICAS EN E LA DIRECCIN Y GESTIN DE PRO OYECTOS INFORMA ATICOS

Figura 10. . Diagrama Cau usa-Efecto

Figura 11. Di iferencia contr ra Soluciones

BUENAS PRCTICAS EN LA DIRECCIN Y GESTIN DE PROYECTOS INFORMATICOS

BUE ENAS PRCTICAS EN E LA DIRECCIN Y GESTIN DE PRO OYECTOS INFORMA ATICOS

3.3.3 Caso de Es studio: Acta a de Constitu ucin

BUE ENAS PRCTICAS EN LA DIRECCIN Y GESTIN DE PRO OYECTOS INFORMA ATICOS

BUE ENAS PRCTICAS EN LA DIRECCIN Y GESTIN DE PRO OYECTOS INFORMA ATICOS

40 3.4 Estudio de Viabilidad

BUENAS PRCTICAS EN LA DIRECCIN Y GESTIN DE PROYECTOS INFORMATICOS

BUE ENAS PRCTICAS EN E LA DIRECCIN Y GESTIN DE PRO OYECTOS INFORMA ATICOS

Figura a 13. Procedim miento de prepa aracin de una a oferta

BUE ENAS PRCTICAS EN E LA DIRECCIN Y GESTIN DE PRO OYECTOS INFORMA ATICOS