Universidad Tecnolgica de Puebla

Ingeniera en Tecnologas de la Informacin y Comunicacin

Materia:

INTEGRADORA I Metodologa de aprendizaje basada en proyectos de TI

3er cuatrimestre

Mayo Agosto 2010 1

Colaboradores:
- M.M. Guillermo Garca Pimentel

NDICE Unidad 1 Metodologa de aprendizaje basada en Proyectos.

1.1 Introduccin
1.1.1 Definicin de proyecto 1.1.2 Caractersticas de un proyecto 1.1.3 Pasos para empezar un proyecto 1.2 Roles y actividades 1.2.1 Lder del proyecto 1.2.2 Analista 1.2.3 Diseador 1.2.4 Programador 1.3 Fases de un proyecto 1.3.1 Fase 1: Identificar una necesidad o problema a resolver 1.3.2 Fase 2: Desarrollo de una solucin 1.3.3 Fase 3: Puesta en Marcha 1.3.4 Fase 4: Cierre del proyecto 1.4 Bitcoras

Unidad II Fases del proyecto

2.1 Definicin del proyecto 2.1.1 Request For Proposal (Solicitud de propuesta) 2.1.2 Establecimiento de un contrato 2.1.3 Determinar los roles y actividades 2.2 Desarrollo del proyecto 2.2.1 Tipos de diseo 2.2.3 Anlisis de requerimientos 2.2.4 Ciclo de vida de desarrollo de SW 2.2.5 Trabajo del equipo 3

2.2.6 Interfaz de usuario 2.3 Puesta en marcha 2.3.1 Pruebas del sistema 2.3.2 Instalacin de software 2.3.3 Cierre del proyecto

Unidad I Metodologa de aprendizaje basada en Proyectos

1.1 Introduccin
La administracin profesional de proyectos ha tomado gran relevancia en los ltimos aos en todo tipo de organizaciones. Esto se debe a que toda organizacin desarrolla proyectos, ya sea para mejorar su competitividad o para entregar productos o servicios a sus clientes. Por lo anterior es necesario el conocimiento y aplicacin de tcnicas y herramientas profesionales para planear, ejecutar y controlar los proyectos asegurando que estos terminen en el tiempo establecido, con la calidad requerida y en el presupuesto aprobado. En cada proyecto, por similar que sean las actividades y los alcances, se tornan diferentes porque las circunstancias cambian, y las cosas siempre son distintas cuando se trabaja con personas. Una de las funciones primordiales de los administradores de proyectos es administrar los procesos internos del mismo donde realmente se efecta el trabajo. Por pequeo que sea el proyecto, se requieren habilidades de administracin del mismo para sortear las diferentes situaciones que se presenten, y adems garantizar el cumplimiento de los objetivos dentro de los tiempos estipulados. Estas habilidades van desde la definicin del proyecto, hasta la administracin de las medidas de avance del mismo.

1.1.1 Definicin de proyecto

Un proyecto es un intento por lograr un objetivo especfico mediante un grupo nico de tareas interrelacionadas y la utilizacin efectiva de los recursos. Tiene un objetivo bien definido, un resultado o producto esperado. Por lo general el objetivo de un proyecto se define en trminos de alcance, programa y costo. Un proyecto es un esfuerzo temporal que se lleva a cabo para crear un producto, servicio o resultado nico. El proyecto es una empresa planificada con un conjunto de actividades para alcanzar un objetivo, con un presupuesto y un tiempo previamente determinados, que como la mayora de los procesos 5

humanos tienen carcter cclico, y la clave de su dinmica es la transformacin de la realidad y el avanzar hacia un estadio superior del desarrollo. Los proyectos "nacen" cuando el cliente identifica una necesidad, las personas o la organizacin estn dispuestas a proporcionar los fondos para satisfacer esa necesidad. En ocasiones el problema se identifica con rapidez, como en el caso de un desastre, como pueden ser un terremoto o una explosin. En otras situaciones, quiz se requieran meses para que el cliente identifique con claridad una necesidad, recopile informacin sobre el problema y defina ciertos requisitos que tiene que cumplir la persona, el equipo del proyecto o el contratista que solucionar el problema.

1.1.2 Caractersticas de un proyecto

Consta de tres caractersticas fundamentales: *Es un proceso temporal, cuanta con un inicio y fin, es decir que se cuenta con un periodo de tiempo determinado para alcanzar el objetivo. *Cuenta con un presupuesto preestablecido para alcanzar el objetivo. *Es un proceso nico (no repetitivo) en que las actividades van ligadas por requerimientos de secuencias y por tanto en que cada etapa las actividades son diferentes.

1.1.3 Pasos para empezar un proyecto

Primer paso para empezar un proyecto Todos los proyectos se inician con una idea temtica. Estas ideas pueden desenvolverse en una investigacin y preguntas experimentales capaces de ser probadas. Algunas ideas seguramente habrn sido discutidas en clase. Otras ideas pueden surgir de la televisin, de pasatiempos, revistas, peridicos, libros, u otras personas. Pueden conceptos nuevos ledos de revistas y manuales cientficos ser usados para ideas y convertirse en proyectos para feria cientfica? El aspecto ms importante de un tema para un proyecto es que el estudiante este interesado en ese tema! Cualquier actividad en donde un estudiante diga Me pregunto cmo es que esto funciona? Me pregunto qu pasara si...? es muy probable que estas sean muy buenas ideas para un proyecto. Un proyecto de la feria cientfica es la ltima respuesta a la pregunta que a menudo hacen los estudiantes: Por qu tengo que aprender todas estas cosas?. El proyecto integra, en una actividad funcional, prcticamente todas las destrezas y artes que se ensean por separado en muchas escuelas (que algunas veces ni siquiera las ensean o las ensean sin un propsito evidente). Cuando se termina un proyecto, este es una alianza de lectura, escritura, ortografa, gramtica, matemtica, estadstica, tica, lgica, pensamiento crtico, ciencia de computadora, artes grficas, metodologa cientfica, aprendizaje a solas en uno o ms campos tcnicos o especializados. Y si el proyecto califica para una competencia formal, oratoria en pblico y defensa del proyecto en frente de los jueces. Quizs es la nica actividad educacional que permite a los estudiantes a auto-instruirse, extraer desde la informacin establecida lo que necesitan para descubrir algo excitante y nuevo, e identificar y seleccionar las herramientas que necesitan para llevar a cabo y concluir su proyecto. Cuando un estudiante termina un proyecto de la feria cientfica, ao tras ao, a travs de la escuela superior, el proceso de la feria cientfica produce lderes maduros, confidentes, preparados, y competitivos que tiene sus metas de carrera adems de la preparacin, disciplina, y empuje para lograrlas. Un proyecto de feria cientfica puede ser auto-validativo y emocionante porque no slo es prctica sino que requiere la aplicacin de los conocimientos de uno mismo y envuelve el descubrimiento autntico desde informacin poco conocida o hasta no conocida. Desarrolla la importancia del poder personal de los estudiantes, donde quizs antes haba poco o ninguno. El proyecto comnmente se basa en cuestiones cientficas o intereses que los estudiantes ya tenan y les permite desarrollar preguntas independientemente de problemas formales, capaces de ser probados, y solventes. Cuando tales estudios se emprenden en serio, los estudiantes a veces son impulsados por los proyectos. 7

Descubrir el desenvolvimiento final y encontrar la respuesta a la pregunta puede ser para el estudiante un momento intensamente poderoso. Ello prueba al estudiante, y a otros, que l fue un xito y que lo hizo por sus propios recursos! Cul es el resultado? Un estudiante promedio se convierte en un estudiante excelente, y un estudiante excelente se convierte en un acadmico. Est netamente probado que de todos los programas que una escuela puede ofrecer al estudiante para mejorar su auto-estima, el valor de participacin en una feria cientfica es superior. Finalmente, proyectos de feria cientfica pueden rendir dinero en efectivo y adems abrir puertas de oportunidades acadmicas. Proyectos bien realizados generalmente llevan a competencias y premios en la Feria Cientfica Regional. Los ganadores de los primeros premios en la feria regional comnmente tienen la oportunidad de competir para premios adicionales en la Feria Cientfica Estatal. Los ganadores de los mejores primeros lugares en las divisiones intermedias y superiores en muchas ferias se seleccionan como ganadores de gran-premio y reciben dinero en efectivo. Adems, los seleccionados como los mejores de los mejores van a competir con otros del mundo entero para premios sustanciales en efectivo y de becas como la Feria Internacional de Ciencia e Ingeniera que Intel celebra anualmente. EJEMPLOS DE PROYECTOS 1. 2. 3. 4. 5. 6. 7. 8. 9. 10. 11. 12. 13. Poner en escena una produccin teatral. Desarrollar e introducir un nuevo producto. Planear una boda. Disear y poner en prctica un sistema de computacin. Emitir una nueva moneda. Modernizar una fbrica. Consolidar dos plantas industriales. Convertir un stano en una sala. Ser anfitrin de una conferencia. Disear y producir un folleto. Llevar a cabo la limpieza ambiental de un lugar contaminado. Celebrar una reunin en una escuela. Construir un centro comercial.

Seleccionar el tema del proyecto Seleccionar un tema para un proyecto a menudo es la parte ms difcil del proceso entero. Aqu hay algunas sugerencias que te pueden ayudar: La mejor idea es la que t mismo creas. El mejor proyecto es uno que te interesa. El que se enfoca en pasa-tiempos, deportes, o cosas que seran divertidas para ti. La ciencia tiene que ver con plantas, animales, informtica, medicina, fsica, qumicos, pero tambin con la televisin, msica, baloncesto, aerbicos y de todas otras partes de la vida. El mejor proyecto es uno en el cual t puedes llegar a compilar toneladas de informacin. Un proyecto de ciencia empieza haciendo una pregunta. T ya eres un excelente cientfico desde que naciste y has estado curioso del mundo y te ha gustado hacer preguntas.

El Segundo Paso de un proyecto La mayora de los estudios que hacen los cientficos son hechos en un intento de contestar preguntas que el cientfico tiene. Dnde encuentran los cientficos estas preguntas? Generalmente las preguntas vienen de observaciones que los cientficos hacen sobre algo del mundo que los rodea. Ve si t puedes tratar de contestar las siguientes preguntas: 1. Fueron visibles las estrellas anoche? 2. De qu color son los ojos de tu madre? 3. Donde est la luz roja de los semforos de trfico, en la posicin superior o inferior? 4. De qu color es la llave de tu casa? 5. El viento sopl hoy, o no?

El Programa de trabajo de Doce Semanas Una de las mayores trampas en un trabajo de larga duracin es la tendencia de dejar las cosas para el ltimo minuto. Esta tendencia de dejar las cosas para el ltimo minuto no slo es un problema para los estudiantes, muchas personas tienen que batallar con este problema en su adultez. Un programa con fechas fijas para entregar partes del proyecto puede ayudar a evitar la acumulacin de trabajo al final del proyecto y provee al estudiante una sensacin de progreso continuo al estar logrando sus metas mientras que el proyecto va avanzado. Un bosquejo del

programa de doce semanas se sugiere abajo. Si el estudiante tiene menos de doce semanas antes que el proyecto tenga que ser entregado, el proyecto se puede ajustar al tiempo disponible.

Fecha de la feria cientfica:_________________________________ Fecha de empezar el proyecto:______________________________ Fecha de someter el proyecto a aprobacin: ____________________ Fecha programada de haber terminado: ________________________ Fecha efectiva al terminar: __________________________________

1.2 Roles y actividades

Un rol es una funcin encomendada a una persona, la cual desempea ciertas actividades y tiene responsabilidades. Para un proyecto que involucre tecnologas de la informacin, podemos considerar los siguientes roles:

1.2.1 Lder del proyecto.

Es la persona que tiene la responsabilidad total del planeamiento y la ejecucin acertados de cualquier proyecto. Este ttulo se utiliza en la industria de la construccin, la arquitectura, el desarrollo de software y diversas ocupaciones que se basan en la generacin o manutencin de un producto. El lder de proyecto debe poseer una combinacin de habilidades incluyendo una gran capacidad inquisitiva, de detectar asunciones sin especificar y de resolver conflictos interpersonales. Una de sus tareas ms importantes es el reconocimiento de los riesgos que afectan directamente las probabilidades de xito del proyecto, y la constante medicin, formal e informalmente de dicho riesgo a lo largo del ciclo de vida del proyecto.

1.2.2 Analista
Es aquel individuo responsable de investigar, planear, coordinar y recomendar opciones de software y sistemas para cumplir los requerimientos de una empresa de negocios. El analista de sistemas juega un rol vital en el proceso de desarrollo de los sistemas. Un analista de sistemas 10

exitoso debe adquirir cuatro habilidades: analtica, tcnica, gerencial, e interpersonal. Las habilidades analticas permiten al analista de sistemas entender a la organizacin y sus funciones, las cuales le ayudan a identificar oportunidades, analizar y resolver problemas. Las habilidades tcnicas ayudan al analista de sistemas a entender el potencial y las limitaciones de las tecnologas de la informacin.

1.2.3 Diseador
El Diseador de Sistemas debe 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 y realizacin fsica

1.2.4 Programador
Un programador es aquel que escribe, depura y mantiene el cdigo fuente de un programa informtico, es decir, el conjunto de instrucciones que ejecuta el hardware de una computadora para realizar una tarea determinada

1.3 Fases de un proyecto

Las fases del proyecto se dividen en:

1.3.1 Fase 1: Identificar una necesidad o problema a resolver

Determinar el Anlisis del problema Al analizar el problema podemos seguir cuatro etapas que nos ayudan a la reflexin de lo que se quiere hacer: Etapa a) Una revisin de posibles situaciones, El hecho de que sea posible explorar soluciones diversas nos habla de que el proceso tecnolgico es rico en oportunidades.
1.

Preguntas orientadas
Cules son las oportunidades que el proceso tecnolgico ofrece en este campo? Qu es lo que la tecnologa ha hecho posible en campos relacionados?

2.

b) Una definicin de parmetros que se

3.

Qu caractersticas tendr el producto?

11

determinan es un sentido social, sujetos a las restricciones de la etapa c). c) Las restricciones que se imponen a la realizacin de la solucin incluyen los conceptos de costo, utilidades, efectividad, factores polticos, aspectos sociales. d) la solucin propuesta a la luz del anlisis, se especifica luego en relacin con el problema planteado.

4. 5.

Qu tamao es el ideal? Qu cantidad producir?

6.

7. 8. 9.

La solucin propuesta es factible en este ambiente sociopoltico determinado? Por qu? La solucin es efectiva? Por qu? Se resuelve el problema planteado a bajo costo? Haz el anlisis de costos Hay relacin entre la solucin y la situaron problemtica? Explcalo.

El anlisis del problema es la parte importante para poder obtener el producto deseado por el cliente, si no se entiende lo que se quiere hacer podemos desarrollar algo totalmente diferente a lo que quiere el cliente.

Como lo desarroll el equipo

Cmo lo quera el cliente

Formulacin del problema

12

El problema podr ser externo o interno. Se plantea como externo cuando surge de una necesidad social, real o no, en campos tan diversos como la produccin, la comunicacin, el transporte, la energa, el cambio climtico, la ciencia misma. Un problema interno es el que engendra el proceso tecnolgico mismo. La ndole incompleta de toda solucin tecnolgica, constituye una fuente abundante para plantear de manera continua nuevos problemas. En el caso de los alumnos esta etapa pretende que elijan el proyecto a desarrollar: el profesor procurara orientarles, brindndoles su ayuda y las sugerencias necesarias para provocar un autentico inters por el proyecto de manera que precisen la pregunta denotada de su investigacin.

Determinar los Roles y actividades El hecho de que en un grupo de desarrollo no se tengan claro los roles y sus responsabilidades y actividades asociadas, hace que se produzcan problemas. Por un lado, es posible que una o ms actividades no estn asociadas a ningn rol, con lo que el proyecto sufrir. Por otro lado, es posible que una o ms actividades estn asociadas a ms de un rol. Esto ltimo producir problemas entre los miembros afectados, lo que tambin redunda en problemas en el desarrollo del sistema. Por eso es necesario que cada miembro conozca muy bien su rol dentro del proyecto, as como las responsabilidades y actividades asignadas. Es posible que no se requieran todos los roles en un desarrollo, eso depender del tamao y del tipo del desarrollo. Es posible tambin que una persona realice las labores de ms de un rol al mismo tiempo. Esto, sobre todo en proyectos de desarrollo pequeos. Tambin es posible la situacin de tener ms de una persona con un mismo rol en un equipo de desarrollo. Por ejemplo, en sistemas de complejidad mediana. Es muy poco probable que un miembro no capacitado pueda estar comprometido con los objetivos del proyecto. Este presentar claras deficiencias en el momento de participar en el proceso. Como ejemplo, se mencionan algunas: 1. Un miembro no capacitado no entender el lenguaje tcnico utilizado por el resto de los miembros. Muchas veces, entender una cosa diferente a la expresada por sus pares. Esto es comn debido a diferencias en el lenguaje. 2. Un miembro no capacitado, no conoce el ciclo de vida del desarrollo, ni los problemas que se presentan durante el desarrollo. Sera muy bueno que el miembro pudiera aportar sus conocimientos en su dominio del problema durante todo el ciclo de desarrollo del proyecto. Saber cundo exigir y cuando ceder. Conocer los estndares de desarrollo, de documentacin, de aseguramiento de la calidad. 13

3. Un miembro no capacitado no presupuesta su involucracin en el proyecto, slo su participacin. Este solo hecho reduce las posibilidades de xito del proyecto. Tambin aumenta los tiempos de desarrollo, disminuye la calidad del sistema, aumentan los riesgos de rechazo del sistema por parte de la comunidad de clientes, etc.

Definicin del proyecto Consiste en hacer la formulacin adecuada de los objetivos de un proyecto de TI, de tal manera que sea posible darle un seguimiento eficaz y que garantice el desarrollo y conclusin exitosa del proyecto, tener una definicin correcta, ayuda a que se reduzcan factores de riesgo como visibilidad, tamao, alcance, complejidad tcnica, tiempo asignado, habilidades requeridas, apoyo gerencial y del usuario, subcontratacin de terceros. Un objetivo un propsito o meta que se propone a cumplir en un lapso definido de tiempo

Fijacin de lmites Para conocer los lmites del proyecto debemos especificar el alcance del mismo Algunas recomendaciones tiles al momento de elaborar el alcance son: Desarrollar un escrito o documento formal. Detallar claramente qu actividades y procesos son parte del proyecto, es decir, el trabajo que debe ser realizado con el fin de entregar un producto con las caractersticas y especificaciones solicitadas. De ser necesario, dividir el proyecto o entregable principal en fases ms pequeas. Esto facilitar la administracin. Definir los criterios que se utilizarn para determinar si el proyecto o fase ha finalizado exitosamente, es decir, los criterios de aceptacin. Tomar como base el RFP (Request For Proposal) o propuesta comercial, as como otros documentos relativos al proyecto definidos previamente. Al definir el alcance, tener en mente que lo que no est en el alcance est fuera del proyecto. Formalizar la aceptacin del alcance con el cliente. El alcance marca la pauta para la toma de decisiones futuras y realizacin de actividades a nivel operativo y nos ayuda a: Mejorar la precisin en las estimaciones de tiempo, costo y recursos. Facilitar la asignacin clara de responsabilidades. 14

 Definir la lnea base para la medicin del desempeo y control. Es necesario especificar hasta a donde va a llegar un proyecto, el equipo debe saber que se va a hacer, y que no se va a hacer dentro del desarrollo del proyecto. Se pueden realizar las siguientes preguntas que nos ayudan a fijar lmites: Cul es el sector de la poblacin que resulta beneficiado con este proyecto? Cul es la relevancia del proyecto? Cul es el impacto social y tecnolgico del proyecto? Se trata de aportar datos objetivos al respecto.

1.3.2 Fase 2 Desarrollo de una solucin

En esta fase se presenta al cliente solicitud de propuesta, donde se estiman costos, tiempos, descripcin del trabajo a realizar, con el fin de poderla desarrollar, se pueden presentar varias propuestas al cliente, donde el escoger una. Si el cliente acepta la solicitud de propuesta, se establece un contrato, y se comienza a desarrollar la solucin que tardar varias semanas o ms en estar lista, segn el tamao del proyecto,

1.3.3 Fase 3: Puesta en Marcha

En esta fase se incluye una planeacin detallada del proyecto que realiza el lder del proyecto junto con los diferentes roles, se establecen objetivos, se asignan actividades segn los roles establecidos y se hace un estimado de costos segn cada actividad, se realizan juntas de trabajo, se hacen minutas, bitcoras, y se comienza a desarrollar el proyecto, donde el fin es llegar al buen trmino del mismo.

1.3.4 Fase 4: Cierre del proyecto

Cuando un proyecto est terminado se necesita realizar ciertas actividades de cierre, por ejemplo, confirmar que todas las entregas se han hecho al cliente y han sido aceptadas por l, que se han cobrado todos los pagos y que se han pagado todas las facturas. Durante esta fase, una tarea importante es evaluar el desempeo del proyecto con el fin de aprender qu se pudiera mejorar si se llevara a cabo un proyecto similar en el futuro.

15

1.4 Bitcoras
Una bitcora es un registro oficial donde se anotan las incidencias diarias y algunos datos obligatorios. En los barcos la bitcora sirve para anotar datos de localizacin, da y hora y situaciones extraas, anormales o incidentes, as como que todo marcha bien, etc. En el desarrollo de un proyecto la bitcora es un complemento de informacin a la planeacin realizada, donde se puede ver con detalle tiempos muertos, tiempos productivos y el tiempo que se invierte en las diferentes actividades que realizan los involucrados del proyecto, la bitcora nos ayuda para tener un conteo real de las horas trabajadas en el proyecto.

16

Unidad II Fases del proyecto

En esa unidad se revisarn las actividades y procesos que se realizan en un proyecto, revisando las fases del proyecto de forma desglosada y tomando en cuenta las sugerencias de buenas prcticas que se realizan en la actualidad.

2.1 Definicin del proyecto

Cuando el equipo del proyecto agrega funcionalidades al producto sin saber que no estaban pactadas en la definicin original, o cuando acepta nuevas funcionalidades pedidas por el cliente porque no sabe decir que no, o porque no se da cuenta de que eso causar problemas en el futuro. Se debe tomar en cuenta que siempre Habr cambios al alcance. Esto es un supuesto del proyecto. La responsabilidad del lder de proyecto es definir e implementar un proceso para analizar y rechazar o aceptar esos cambios Para resolver la necesidad del cliente, es necesario realizar una entrevista inicial para identificar que es lo que quiere resolver, y despus utilizar tcnicas de anlisis de requerimientos para poder presentar el Request For Proposal que incluye entre otras cosas el objetivo del proyecto, tiempos, costos.

2.1.1 Request For Proposal (Solicitud de propuesta)

La Solicitud de Propuesta (RFP) es un tipo de documento de adquisicin que se utiliza para describir lo que se pretende realizar, y solicitar propuestas de posibles vendedores de productos o servicios para el proyecto. Si se decide en el proyecto comprar una parte del trabajo, se convoca a proveedores a travs de este documento. Es all donde se describen el tipo de trabajo a cotizar, las condiciones de contratacin y el tipo de requerimientos adicionales que cada proveedor potencial debe entregar, como su experiencia con el tipo de trabajo solicitado, una lista de sus clientes, informacin financiera, etc. Se puede usar una solicitud de propuesta para establecer con el cliente aspectos del sistema a entregar ejemplo:

El propsito de preparar una solicitud de propuesta es exponer, en forma amplia y detallada, lo que se requiere, desde el punto de vista del cliente. Una SDP debe ser amplia y proporcionar informacin suficientemente detallada para que el equipo del
17

proyecto pueda preparar una propuesta inteligente que corresponda a las necesidades del cliente.

Estructura de un RFP Datos generales de la empresa Contiene la informacin relevante del cliente para poner en contexto al proveedor de un bien o servicio que vamos a necesitar para el proyecto. Incluye entre otras cosas: * Nombre de la empresa * Giro/sector de la empresa * Antecedentes de la empresa (Algunos o todos los siguientes: Cuando fue fundada, presencia en el pas, presencia en otras partes del mundo, nmero de empleados) Datos del producto o servicio Informacin sobre el producto o servicio requerido, incluyendo para el caso de productos: * Protocolos/ algoritmos (ej. en el caso de requerimientos criptogrficos) * Caractersticas tcnicas (tamao, consumo de energa, anchos de banda, puertos, etc.) * Cantidad requerida * Compatibilidad (plataformas, bases de datos, consolas de administracin) * Estndares (ej. ISO, FIPS) En el caso de servicios se suele incluir informacin como: * Rangos de tiempo estimados para el inicio y fin del servicio * Alcance (cantidad de elementos as como nivel de detalle) * Objetivos * Habilidades/experiencia/certificaciones de consultores * Otras restricciones (algunas fechas u horarios, limitaciones tcnicas para hacer el trabajo, limitaciones legales como permisos de trabajo para extranjeros, etc.) * Herramientas Entre ms informacin se proporcione en esta seccin es ms fcil para los proveedores determinar un precio adecuado pero sobre todo cumplir con las expectativas del cliente. Por ejemplo, pedir slo un firewall es muy distinto a pedir un firewall de red capa 7 con capacidad de 4 puertos Giga bit que soporte protocolos HTTP y SMTP. Criterios de aceptacin y seleccin Es la informacin sobre el proceso para escoger al servicio o producto, as como las caractersticas que debe cumplir para ser aceptado (por ejemplo, cuales entregables para dar como concluido de forma satisfactoria un servicio). Estos criterios son importantes porque le indican a la empresa los factores ms importantes en los que debe hacer nfasis dentro de su propuesta para obtener el contrato (ejemplo: calidad, precio, experiencia, prestigio).
18

Un criterio de aceptacin puede incluir cosas como: * Tiempos de entrega de avances * Desempeo (para hardware) * Experiencia (para software) *Cumplimiento con requerimientos tcnicos * Reportes de resultados (para servicios) * Soporte * Precio Un entregable es el producto del trabajo que se puede medir y verificar, los entregables pueden ser contratos, documentos que se entregan al cliente, especificaciones, pantallas, casos de uso, diagramas, avances del sistema, etc. Es importante dejar claro el orden de importancia cuando hay varios criterios. Usualmente el criterio de precio se suele dejar al ltimo, poniendo primero al de cumplimiento y despus de ste a otros criterios de calidad como desempeo y soporte. En otras palabras: primero se suele elegir a aquellas propuestas que cumplen con nuestras expectativas y nos dan mayor calidad, y luego se escoge a la ms barata de entre estas propuestas.

Informacin de contacto Esta seccin contiene la informacin necesaria para que los proveedores enven sus propuestas y resuelvan dudas que pudieran tener al respecto. Incluye: * Nombre del responsable por parte de la empresa * Puesto del responsable * Telfono/ correo electrnico/ fax * Direccin fsica de la empresa * Pgina web de la empresa Para ver un ejemplo del formato RFP consultar el Anexo 1.

2.1.2 Establecimiento de un contrato

Un contrato es un acuerdo mutuo que obliga a una parte llamada el vendedor a proveer un producto, servicio o resultado especficos, y a la otra parte, llamada el comprador, a pagar por ellos.
19

Esta definicin es muy fcil de comprender si las cosas van bien. Si las cosas van mal, alguna de las condiciones descriptas arriba no se cumplen. Un contrato puede finalizar por 3 razones 1. Porque se complet: en este caso el vendedor y el comprador cumplieron con sus obligaciones. 2. Por comn acuerdo, a pesar de que no se complet: el vendedor no termin de entregar su producto, servicio o resultado, o el comprador no pag lo que se haba acordado. Ambos estn de acuerdo con esta situacin. 3. Por no cumplimiento: alguna de las dos partes no cumpli con sus obligaciones. No olvidar: que el lder de proyecto es responsable por los contratos, aunque la administracin de stos la realice el departamento de compras o el departamento legal de la empresa.
Se puede ver un modelo de contrato en el Anexo 6.

2.1.3 Determinar los roles y actividades

Para identificar los roles se puede seguir la tcnica del anlisis de los interesados que consiste en tres pasos que son: 1. Identificar a todos los posibles interesados en el proyecto y asociar a cada uno su rol, departamento, intereses, nivel de conocimiento, expectativas y poder de influencia. 2. Identificar el impacto o apoyo potencial que cada interesado podra generar, y clasificarlos para definir una estrategia de acercamiento. 3. Evaluar el modo en que los interesados clave pueden reaccionar o responder en diferentes situaciones, a fin de planificar como influir en ellos para mejorar su apoyo.

Roles ms comunes en un proyecto de TI Puesto: Lder del proyecto Perfil Es responsable del proyecto Responsabilidades Coordinar la ejecucin de las tareas

20

No debe ordenar, sino guiar

Agilizar los procesos de cada uno de los integrantes del proyecto Gestionar las actividades realizadas por los integrantes Hacer los tratos directos con el clientes

Debe hacer un equipo con los integrantes del proyecto Involucrar a los integrantes en toma de decisiones Hacer los tratos directos con el cliente

Se encarga de llevar al cliente los avances del proyecto Dar soluciones a casos imprevistos Verificar riesgos

Puesto: Analista Perfil Analizar las necesidades del negocio Evaluar los procesos en la mejora del negocio Responsabilidades Evala el funcionamiento del negocio Recopilar informacin de entradas y salidas para mejorar el proceso de la organizacin Establece los lmites junto con los integrantes del equipo Integrar graficas de tiempo y avances del proyecto Ver las necesidades a implementar segn el modelo

Redactar las especificaciones tcnicas

Planificacin y ejecucin

Puesto: Diseador Perfil Responsabilidades 21

Disea en base a los requerimientos del proyecto

Genera pantallas del sistema

Expone cual es la funcin de cada uno de los botones del interfaz.

Realiza Diagramas de flujo

Puesto: Programador Perfil Desarrollo Responsabilidades Determinar en colaboracin con los Analistas informticos los objetivos perseguidos con los distintos programas, la naturaleza y fuentes de datos que habr que introducir y ordenar, y establecer los controles necesarios Mantener actualizados los programas

Mantenimiento de sistemas

2.2 Desarrollo del proyecto

El desarrollo de la solucin del proyecto consiste en realizar lo que nos pide el cliente, para esto se debe conocer cmo se realizan los procesos dentro de la empresa, identificar las personas involucradas, proponer un modelo de desarrollo de software que se adapte al problema que deseamos resolver.

2.2.1 Tipos de diseo

El diseo conceptual se considera como un anlisis de actividades y consiste en la solucin de negocios de los procesos que realiza la empresa. Consta de las siguientes tareas:
22

Identificar los usuarios y sus roles Obtener datos de los usuarios Evaluar la informacin Documentar los escenarios de uso Validar con los usuarios

Una vez que se ha entrevistado al cliente y se conoce los procesos que maneja la empresa se puede hacer un diagrama de flujo con el proceso actual de cmo hace las cosas la empresa, para tener una mayor compresin de lo que se realiza. El diseo lgico traduce los escenarios de uso creados en el diseo conceptual en una especificacin funcional que se usa para el diseo fsico. El diseo lgico es independiente de la tecnologa y plataformas que se vayan a utilizar. El diseo lgico refina, organiza y detalla la solucin de negocios y define formalmente las reglas y polticas especficas del modelado del negocio. El analista y diseador se coordinan para trabajar activamente en este proceso. El diseo lgico comprende las siguientes tareas:
Identificar y definir los objetos de negocio y sus servicios Definir las interfaces Identificar las dependencias entre objetos Validar contra los escenarios de uso Comparar con la arquitectura de la empresa Revisar y refinar tanto como sea necesario

El diseo fsico traduce el diseo lgico en una solucin implementable, donde el programador se coordina con el analista para realizar el desarrollo de la solucin. El diseo fsico est ntimamente ligado a una alternativa tecnolgica. La tendencia actual al manejar muchas necesidades es a travs de Internet con una arquitectura cliente-servidor donde el backend (sistema en el servidor) debe ser robusto, multitareas y el frontend (interfaz del usuario) debe ser un programa cliente muy ligero que no acapare al servidor, comunicndose entre s en una plataforma Internet con protocolos estndar en redes heterogneas. El diseo fsico tambin incluye la especificacin de bases de datos y estndares como normalizacin, diagramas E-R, segn el lenguaje de programacin y el sistema gestor de base de datos (SGBD) a utilizar.
23

Durante el anlisis del problema, se realizan una serie de pasos para garantizar un acuerdo entre los involucrados, basados en los problemas reales del negocio. Estos pasos son los siguientes: 1. Comprender el problema que se est resolviendo : Es importante determinar quin tiene el problema realmente, considerar dicho problema desde una variedad de perspectivas y explorar muchas soluciones desde diferentes puntos de vista. Veamos la siguiente necesidad: "El cliente se queja mucho por la enorme fila que debe formar para realizar una transaccin bancaria". Perspectiva del cliente = Prdida de tiempo Perspectiva del banco = Posibles prdidas de clientes 2. Posibles soluciones pueden ser, determinar por qu demoran los cajeros, colocar una nueva caja (implica contratacin de nuevos cajeros), abrir una nueva sucursal (involucra personal nuevo y estudio de mercado), realizar transacciones por otros medios (telfono, internet, mediante cajeros automticos, autobancos, etc.) Como puede verse, mltiples soluciones aplican para el mismo problema, sin embargo, slo una de ellas ser la ms factible. Las soluciones iniciales, deben ser definidas tomando en cuenta tanto la perspectiva tcnica como la del negocio. 3. Construir un vocabulario comn: Debe confeccionarse un glosario en dnde se definan todos los trminos que tengan significados comunes (sinnimos) y que sern utilizados durante el proyecto. Por ejemplo, las palabras pignoracin, retencin, valor en suspenso, custodia, garanta, entre otras, son utilizadas para referirse a la accin de dejar una prenda (puede ser cualquier forma de ahorros) como garanta de una deuda adquirida. La creacin de un glosario es sumamente beneficiosa ya que reduce los trminos ambiguos desde el principio, ahorra tiempo, asegura que todos los participantes de una reunin estn en la misma pgina, adems de ser reutilizable en otros proyectos. 4. Identificar a los afectados por el sistema: Identificar a todos los afectados evita que existan sorpresas a medida que avanza el proyecto. Las necesidades de cada afectado, son discutidas y sometidas a debate durante de ingeniera de requerimientos, aunque esto no garantiza que vaya a estar disponible toda la informacin necesaria para especificar un sistema adecuado. Para saber quines son las personas, departamentos, organizaciones internas o externas que se vern afectadas por el sistema, debemos realizar algunas preguntas.
24

 Quin usar el sistema que se va a construir? Quin desarrollar el sistema? Quin probar el sistema? Quin documentar el sistema? Quin dar soporte al sistema? Quin dar mantenimiento al sistema?

2.2.3 Anlisis de requerimientos

Dentro del diseo conceptual debemos hacer un anlisis de requerimientos, para esto se pueden utilizar diferentes tcnicas, entre las cuales estn: Entrevistas y cuestionarios Casos de uso (UML) Lluvia de ideas

Entrevistas y Cuestionarios Las entrevistas y cuestionarios se emplean para reunir informacin proveniente de personas o de grupos. Durante la entrevista, el analista conversa con el encuestado; el cuestionario consiste en una serie de preguntas relacionadas con varios aspectos de un sistema. Por lo comn, los encuestados son usuarios de los sistemas existentes o usuarios en potencia del sistema propuesto. En algunos casos, son gerentes o empleados que proporcionan datos para el sistema propuesto o que sern afectados por l. Las preguntas que deben realizarse en esta tcnica, deben ser preguntas de alto nivel y abstractas que pueden realizarse al inicio del proyecto para obtener informacin sobre aspectos globales del problema del usuario y soluciones potenciales. Con frecuencia, se utilizan preguntas abiertas para descubrir sentimientos, opiniones y experiencias generales, o para explorar un proceso o problema. Este tipo de preguntas son siempre apropiadas, adems que ayudan a entender la perspectiva del afectado y no estn influenciadas por el conocimiento de la solucin. Las preguntas pueden ser enfocadas a un elemento del sistema, tales como usuarios, procesos, etc. El siguiente ejemplo muestra algunos tipos de preguntas abiertas. Del Usuario Quin es el cliente? 25

 Quin es el usuario? Son sus necesidades diferentes? Cules son sus habilidades, capacidades, ambiente? Del Proceso Cul es la razn por la que se quiere resolver este problema? Cul es el valor de una solucin exitosa? Cmo usted resuelve el problema actualmente? Qu retrasos ocurren o pueden ocurrir? Del Producto Qu problemas podra causar este producto en el negocio? En qu ambiente se usar el producto? Cules son sus expectativas para los conceptos fcil de usar, confiable, rendimiento? Qu obstculos afectan la eficiencia del sistema? El xito de esta tcnica combinada, depende de la habilidad del entrevistador y de su preparacin para la misma. Los analistas necesitan ser sensibles las dificultades que algunos entrevistados crean durante la entrevista y saber cmo tratar con problemas potenciales. Asimismo, necesitan considerar no slo la informacin que adquieren a travs del cuestionario y la entrevista, sino tambin, su significancia. Para ver un ejemplo de una entrevista se puede consultar el Anexo 4.

Lluvia de Ideas Este mtodo comenz en el mbito de las empresas, aplicndose a temas tan variados como la productividad, la necesidad de encontrar nuevas ideas y soluciones para los productos del mercado, encontrar nuevos mtodos que desarrollen el pensamiento creativo a todos los niveles, etc. Pero pronto se extendi a otros mbitos, incluyendo el mundo de desarrollo de sistemas; bsicamente se busca que los involucrados en un proyecto desarrollen su creatividad. A esta tcnica se le conoce tambin como torbellino de ideas, tormenta de ideas, desencadenamiento de ideas, movilizacin verbal, bombardeo de ideas, sacudidas de cerebros, promocin de ideas, tormenta cerebral, avalancha de ideas, tempestad en el cerebro y tempestad de ideas, entre otras. 26

Principios de la lluvia de ideas Aplazar el juicio y no realizar crticas, hasta que no agoten las ideas, ya que actuara como un inhibidor. Se ha de crear una atmsfera de trabajo en la que nadie se sienta amenazado. Cuantas ms ideas se sugieren, mejores resultados se conseguirn: "la cantidad produce la calidad". Las mejores ideas aparecen tarde en el periodo de produccin de ideas, ser ms fcil que encontremos las soluciones y tendremos ms variedad sobre la que elegir. La produccin de ideas en grupos puede ser ms efectiva que la individual. Tampoco debemos olvidar que durante las sesiones, las ideas de una persona, sern asociadas de manera distinta por cada miembro, y har que aparezcan otras por contacto. El equipo en una lluvia de ideas debe estar formado por: El lder es la figura principal y el encargado de dirigir la sesin. Debe ser un experto en pensamiento creador. Su funcin es formular claramente el problema y que todos se familiaricen con l. Cuando lo haga, debe estimular ideas y hacer que se rompa el hielo en el grupo. Es el encargado de que se cumplan las normas, no permitiendo las crticas. Debe permanecer callado e intervenir cuando se corte la afluencia de ideas, por lo que le ser til llevar ya un listado de ideas. Debe hacer que todos participen y den ideas. Adems, es la persona que da concede la palabra y da por finalizada la sesin. Posteriormente, clasificar las ideas de la lista que le proporciona el secretario. Una persona que funge como secretario: registra por escrito las ideas segn van surgiendo. Las enumera, las reproduce fielmente, las redacta y se asegura que todos estn de acuerdo con lo escrito. Por ltimo realizar una lista de ideas. Los participantes: pueden ser habituales o invitados; cualquier involucrado en el proyecto entra en esta categora. Su funcin es producir ideas. Conviene que entre ellos no haya diferencias jerrquicas. Las personas que componen el grupo deben estar motivadas para solucionar el problema, y con un ambiente que propicie la participacin de todos. Todos pueden sentirse confiados y con la sensacin de que pueden hablar sin que se produzcan crticas. Todas las ideas en principio deben tener el mismo valor, pues cualquiera de ellas puede ser la clave para la solucin. Es necesario prestar mucha atencin a las frases que pueden coartar la produccin de ideas. Adems durante la celebracin no deben asistir espectadores. Debemos evitar todos los bloqueos que paralizan la ideacin: como son nuestros hbitos o ideas preconcebidas, el desnimo o falta de confianza en s mismo, el temor y la timidez. Las fases de aplicacin en la lluvia de ideas son: Descubrir hechos al menos con un da de antelacin, el lder comunica por escrito a los miembros del grupo sobre los temas a tratar. El lder explica los principios de la lluvia de ideas e insiste en la importancia de tenerlos en cuenta. La sesin comienza con una ambientacin de unos 10 minutos, tratando un tema sencillo y no 27

comprometido. Es una fase especialmente importante para los miembros sin experiencia. Se determina el problema, delimitndolo, precisndolo y clarificndolo. Despus se plantea el problema, recogiendo las experiencias que se poseen o consultando documentacin. Cuando es complejo, conviene dividirlo en partes. Aqu es importante la utilizacin del anlisis, desmenuzando el problema en pequeas partes para conectar lo nuevo y lo desconocido. Producir ideas (es la fase de tormenta de ideas propiamente dicha) Se van aplicando alternativas. Se busca producir una gran cantidad de ideas, aplicando los principios que hemos visto. Adems, es til cuando se ha trabajado mucho, alejarse del problema, pues es un buen momento para que se produzcan asociaciones. Muchas de las nuevas ideas sern ideas antiguas, mejoradas o combinadas con varias ya conocidas. Al final de la reunin, el lder da las gracias a los asistentes y les ruega que no se olviden del problema, ya que al da siguiente se le pedir una lista de ideas que les puedan haber surgido. Se incorporan las ideas surgidas despus de la reunin. Para descubrir soluciones se elabora una lista definitiva de ideas, para seleccionar las ms interesantes. La seleccin se realiza desechando las ideas que no tienen valor y se estudia si son vlidas las que se consideran interesantes. Lo mejor es establecer una lista de criterios de conveniencia para cada idea. Se seleccionan las ideas ms tiles y si es necesario se ponderarn. Pueden realizarlo los mismos miembros del grupo o crear otros para esta tarea; la clasificacin debe hacerse por categoras. Se presentan las ideas de forma atractiva, haciendo uso de soportes visuales.

Administracin de requerimientos con casos de uso Los casos de uso son una tcnica para especificar el comportamiento de un sistema: "Un caso de uso es una secuencia de interacciones entre un sistema y alguien o algo que usa alguno de sus servicios." Todo sistema de software ofrece a su entorno una serie de servicios. Un caso de uso es una forma de expresar cmo alguien o algo externo a un sistema lo usa. Cuando decimos "alguien o algo" hacemos referencia a que los sistemas son usados no slo por personas, sino tambin por otros sistemas de hardware y software. Por ejemplo, un sistema de ventas, si pretende tener xito, debe ofrecer un servicio para ingresar un nuevo pedido de un cliente. Cuando un usuario accede a este servicio, podemos decir que est "ejecutando" el caso de uso ingresando pedido. Dentro del caso de uso se manejan eventos, un evento es algo que ocurre fuera de los lmites del sistema, ante lo cual el sistema debe responder. 28

Existen algunas diferencias entre los casos de uso y los eventos. Las principales son: Los eventos se centran en describir qu hace el sistema cuando el evento ocurre, mientras que los casos de uso se centran en describir cmo es el dilogo entre el usuario y el sistema. Los eventos son "atmicos": se recibe una entrada, se la procesa, y se genera una salida, mientras que los casos de uso se prolongan a lo largo del tiempo mientras dure la interaccin del usuario con el sistema. De esta forma, un caso de uso puede agrupar a varios eventos. Para los eventos, lo importante es qu datos ingresan al sistema o salen de l cuando ocurre el evento (estos datos se llaman datos esenciales), mientras que para los casos de uso la importancia del detalle sobre la informacin que se intercambia es secundaria. Segn esta tcnica, ya habr tiempo ms adelante en el desarrollo del sistema para ocuparse de este tema. Cmo se realiza el caso de uso Un caso de uso es iniciado por un actor. A partir de ese momento, ese actor, junto con otros actores intercambia datos o control con el sistema, participando de ese caso de uso. El nombre de un caso de uso se expresa con un verbo en gerundio, seguido generalmente por el principal objeto o entidad del sistema que es afectado por el caso. Grficamente, los casos de uso se representan con un valo, con el nombre del caso en su interior. Los casos de uso tienen las siguientes caractersticas:

Estn expresados desde el punto de vista del actor. Se documentan con texto informal. Describen tanto lo que hace el actor como lo que hace el sistema cuando interacta con l, aunque el nfasis est puesto en la interaccin. Son iniciados por un nico actor.
Estn acotados al uso de una determinada funcionalidad del sistema, claramente diferenciada.

El empleado de ventas es un actor del sistema ventas Algunas preguntas que nos debemos hacer para establecer la interaccin entre el actor y el sistema son: 29

 Cules son las tareas del actor? Necesita el actor estar informado de ciertas ocurrencias del sistema? Necesita el actor informar al sistema de cambios externos sbitos? Proporciona el sistema el comportamiento correcto al negocio? Pueden ser todos los requerimientos funcionales, desarrollados por los casos de uso? Qu casos de uso soportarn y mantendrn al sistema? Qu informacin debe ser modificada o creada? El contenido tpico de un documento de caso de uso sera: Describir cmo comienza el caso de uso y cmo termina. Realizar un flujo normal de eventos. Realizar un flujo alterno de eventos. Detallar las excepciones al flujo de eventos.

Para ver el ejemplo de 1 caso de uso desarrollado, consultar el Anexo 3 Requisitos Funcionales y no funcionales Una vez levantados los requerimientos, se redactan los requisitos funcionales que definen el comportamiento interno del software: clculos, detalles tcnicos, manipulacin de datos y otras funcionalidades especficas que muestran cmo los casos de uso sern llevados a la prctica. Los requisitos no funcionales complementan a los funcionales, se enfocan en el diseo y la implementacin, donde se tiene una condicin o capacidad de un sistema para satisfacer un estndar. Por ejemplo para la implementacin se necesitan servidores con ciertas caractersticas en tamao de disco y memoria.

Ciclo de vida de desarrollo de SW El lder del proyecto debe elegir junto con los integrantes del equipo el ciclo que de vida de desarrollo de SW que se adapte a las caractersticas problema a resolver y a la experiencia que tiene el equipo de desarrollo, esto se hace a la par del anlisis de requerimientos Los ciclos de vida que se utilizan estn para el desarrollo son el de cascada, evolutivo, iterativo, proceso unificado (RUP), prototipos, extreme programing (XP), entre otros.

30

Algunos ciclos de vida ya incluyen estndares de documentacin y procesos definidos con roles y actividades especficas, lo cual se debe de llevar lo ms apegado a como lo marca el ciclo de vida, aunque se pueden hacer modificaciones a los formatos estndar que se manejan para adaptarlos a la forma de trabajo de la empresa de desarrollo. El uso de estndares ayuda a que en caso de cambiar de un integrante del equipo de desarrollo, los nuevos integrantes comprendan el problema y el modelo del negocio que se va a resolver.

2.2.5 Trabajo del equipo

Una vez que se han definido roles y requerimientos, el equipo de trabajo comenzar a realizar sus actividades en base a un cronograma que se haya elaborado previamente, estimando tiempos para cada actividad a realizar, incluyendo reuniones del equipo de trabajo para revisar avances, reuniones con el cliente para presentar entregables, etc. El lder del proyecto debe utilizar cronogramas y bitcoras para tener conocimiento del avance del proyecto y poder tomar decisiones, en el caso del uso de bitcoras, es importante saber cules son los tiempos muertos dentro del proyecto y cuanto tiempo se delega a otras actividades como comer, tomar cursos de capacitacin, etc. Para ver un ejemplo del formato de bitcora consultar el Anexo 2.

Cronograma Tambin conocido como Grafica o diagrama de Gantt, es una popular herramienta grfica cuyo objetivo es mostrar el tiempo de dedicacin previsto para diferentes tareas o actividades a lo largo de un tiempo total determinado. A pesar de que, en principio, el diagrama de Gantt no indica las relaciones existentes entre actividades, la posicin de cada tarea a lo largo del tiempo hace que se puedan identificar dichas relaciones e interdependencias. Bsicamente el diagrama est compuesto por un eje vertical donde se establecen las actividades que constituyen el trabajo que se va a ejecutar, y un eje horizontal que muestra en un calendario la duracin de cada una de ellas. Ejemplo de Grfica de Gantt

Reuniones de trabajo con el equipo del proyecto Las reuniones de trabajo son una herramienta utilizada para elaborar planes, disear estrategias, evaluar desempeos, fomentar la participacin de los integrantes del equipo. 31

Siempre debemos tener en mente que las reuniones son actividades costosas si no llegan a ser efectivas, esto implica que las mismas deben de enfocarse como todas las dems actividades importantes de la empresa. Una agenda debe contener: Lugar de reunin, qu debern llevar los asistentes, se debe leer previo a la misma, los puntos que sern cubiertos, fecha y hora en que ser realizada, lista de participantes y duracin de la misma. Si la agenda no pudo entregarse con anticipacin se puede distribuir al comienzo de la reunin y tambin se les puede preguntar a los participantes si desean incluir algn tema adicional. Algunos expertos recomiendan invitar solamente a las personas directamente envueltas en el logro de la meta que se desea alcanzar en la reunin. Si tenemos invitados que no ven nuestra reunin como una prioridad se sugiere el asignarles algn tema de la agenda e incluso el que lleven alguna informacin a la reunin sobre uno de los primeros temas a tratar. Cuando se ha planificado una reunin a la misma hora de la nuestra, una de las dos debe reprogramarse y asegurarnos que todos los invitados puedan asistir a ambas. Si tenemos invitados que llegan tarde se recomienda enviar un e-mail diciendo que hagan el esfuerzo de llegar temprano porque no se repetir lo que se ha dicho. Para convocar a la reunin: Realizar una Agenda / Contenidos con Objetivos de la reunin Tema Fecha Hora de inicio y fin Lugar de la reunin Participantes Quien convoca la reunin Puntos de la reunin o Tiempo aproximado o Responsable o Que se har Observaciones (preparacin previa necesaria) Convocar a los participantes

Requerimientos Establecer reglas para las reuniones, por ejemplo: Horarios Puntualidad Mtodos para decidir Interrupciones permitidas 32

 Confidencialidad Dichas reglas, deben ser establecidas por todos los participantes.

Ejecucin de la reunin: Llegue antes de empezar la reunin Prepare el lugar fsico Adecue el lugar para el objetivo de la reunin (Presentacin frontal, Reunin de discusin, etc.) Si utiliza equipamiento Compruebe que todo funciona correctamente Tenga una contingencia prevista Repase los objetivos de la reunin Llegan los participantes Distribuir copias de la agenda a los que no tienen Leer la agenda antes de comenzar La reunin no deber durar ms de 2 horas Apegarse al temario y a los tiempos Respetar las reglas de equipo Alentar a los participantes a plantear sus opiniones Moderar las discusiones para que se permita escuchar las opiniones de cada participante

Cierre de la reunin: Esboce la agenda de la prxima reunin Antes de terminar, haga una recapitulacin de los temas tratados (insistir en las conclusiones, tareas lanzadas, responsables) Deben quedar claras las tareas distribuidas a sus responsables Evaluar la reunin y registrar las conclusiones

Tareas post reunin: Minuta de acuerdos e informacin previa Si se generan compromisos durante la reunin, estos deben quedar asignados e incluidos en un documento donde se establezca cmo mnimo el responsable y la fecha estimada de trmino. Lo ideal en este aspecto sera que cada participante tenga asignado uno de los puntos para que todos se envuelvan en la dinmica de la reunin. Las decisiones a que ha llegado el equipo deben ser documentadas. 33

Pasar en limpio el acta (minuta) de la reunin Redactarla lo antes posible para no perder informacin Ordenarla por unidades temticas y no por orden cronolgico de la discusin Identificar las tareas lanzadas, con responsable y fecha de finalizacin Elaborar un listado de asuntos pendientes Las acciones despus de la reunin hasta la prxima es algo crucial para el logro de los puntos del plan de accin. Las minutas deben publicarse a ms tardar 24 horas despus de sostenida la reunin.

Las reuniones son necesarias para mantener la comunicacin en la empresa, realizar el trabajo en equipo y son de tanta importancia como cualquier otra actividad clave de la empresa ya que en ellas: se toman decisiones, se solucionan problemas, intercambia informacin, se planifica, entre otras. Para ver un formato de minuta consultar el Anexo 5 Las reuniones de trabajo se pueden hacer cada semana, o segn lo indique el lder en base a las necesidades del proyecto.

2.2.6 Interfaz de usuario

La interfaz de usuario es el medio con que el usuario puede comunicarse con una mquina, un equipo o una computadora, y comprende todos los puntos de contacto entre el usuario y el equipo, normalmente suelen ser fciles de entender y fciles de accionar. Las interfaces bsicas de usuario son aquellas que incluyen cosas como mens, ventanas, teclado, ratn, los beeps y algunos otros sonidos que la computadora hace, en general, todos aquellos canales por los cuales se permite la comunicacin entre el ser humano y la computadora. La mejor interaccin humano-mquina a travs de una adecuada interfaz (Interfaz de Usuario), que le brinde tanto comodidad, como eficiencia Dentro del diseo fsico del sistema, el diseador debe tener gran comunicacin con el analista y programador para crear las pantallas que es la interfaz grfica con la que va a interactuar el usuario, tomando en cuenta los requerimientos analizados, especificaciones de color, colores institucionales de la empresa, cantidad de informacin a mostrar, etc.

Metas del diseo de interfaces Reducir el trabajo visual Reducir el trabajo intelectual Reducir el trabajo de la memoria Reducir el trabajo motor 34

Minimizar o eliminar cargas o instrucciones impuestas por la tecnologas

Los elementos de la pantalla deben tener un significado para el usuario, para ordenar los datos se debe: Dividir informacin en unidades que sean lgicas, significativas y sensatas Organizar en funcin del grado de interrelacin entre datos e informacin Proporcionar ordenacin de unidades de pantalla de informacin y elementos priorizados segn las expectativas de usuario y sus necesidades Posibles esquemas de ordenacin: secuencia de uso, frecuencia de uso, funcin, importancia, de lo general a lo especfico Formar grupos que cubren todas las posibilidades Asegurar que toda la informacin a comparar es visible al mismo tiempo Asegurar que slo se muestra informacin relativa a las tareas o necesidades de los usuarios

Para la navegacin y flujo de pantalla se recomienda: Proporcionar ordenacin de la informacin y elementos de forma que: Gue al ojo del usuario Favorece movimientos naturales Minimiza distancias entre puntero y movimiento de ojos Situar los elementos y controles ms importantes y usados con mayor frecuencia arriba a la izquierda Ayudar en la navegacin mediante: Alineacin de elementos Agrupamiento de elementos Uso de bordes de lnea Dirigir la atencin hacia tems: Crticos Importantes Secundarios Perifricos

35

2.3 Puesta en marcha

La puesta en marcha va ligada al desarrollo de la solucin, aqu se sigue trabajando en el proyecto que se comenz en la fase anterior, y el lder de proyecto se encarga de realizar juntas de trabajo para ver avances, solucionar contingencias y presentar el proyecto haciendo las pruebas y correcciones necesarias hasta terminarlo.

2.3.1 Pruebas del sistema

Uno de los objetivos de la fase de pruebas del sistema es verificar que el comportamiento externo del sistema software satisface los requisitos establecidos por los clientes y futuros usuarios del mismo. A medida que aumenta la complejidad de los sistemas software y aumenta la demanda de calidad, se hacen necesarios procesos y mtodos que permitan obtener buenos conjuntos de pruebas del sistema. Toda prueba consta tradicionalmente de tres elementos: interacciones entre el sistema y la prueba, valores de prueba y resultados esperados. Los dos primeros elementos permiten realizar la prueba y el tercer elemento permite evaluar si la prueba se super con xito o no. Un proceso de pruebas consta generalmente de cuatro fases: la fase de diseo de pruebas, la fase de codificacin, la fase de ejecucin y la fase de anlisis de los resultados. Dentro de las pruebas pueden desarrollarse varios tipos distintos de pruebas en funcin de los objetivos de las mismas. Algunos tipos son pruebas de funcionalidad, pruebas de usabilidad, pruebas de rendimiento, pruebas de seguridad, etc.

a) Pruebas de funcionalidad El objetivo de esta prueba es que asegura el trabajo apropiado de los requisitos funcionales, incluyendo la navegacin, entrada de datos, procesamiento y obtencin de resultados.

Metas de las pruebas de funcionalidad: Verificar el procesamiento, recuperacin e implementacin adecuada de las reglas del negocio, y verificar la apropiada aceptacin de datos. El enfoque se da en los requisitos funcionales (Casos de Uso) y las reglas del negocio. Tcnica de prueba funcional: Caja Negra.

36

Se ejecuta cada caso de uso, flujo de caso de uso, o funcin, usando datos vlidos e invlidos, para verificar lo siguiente: Que se aplique apropiadamente cada regla de negocio. Que los resultados esperados ocurran cuando se usen datos vlidos. Que sean desplegados los mensajes apropiados de error y precaucin cuando se usan datos invlidos.

b) Pruebas de usabilidad Usabilidad Segn Jacob Nielsen, la usabilidad es un atributo de calidad que mide lo fciles de usar que son las interfaces, se entiende la usabilidad como una atributo de calidad que determina la facilidad de un producto, y pretende asegurar la satisfaccin de nuestros usuarios. Teniendo una idea ms clara de lo que es la usabilidad y su importancia , podemos establecer que si los productos de software que desarrollamos no son usables estamos arriesgando a nuestros clientes, ya que defraudamos la confianza que ellos tienen al adquirir nuestros productos ya que lo mnimo que esperan es que sea adecuado, fcil de manejar y que le solucione sus necesidades ; La idea es realizar productos "fciles de usar", si nuestros productos no lo son estamos colocando problemas a los usuarios finales en el manejo de nuestras aplicaciones en vez de proveerles soluciones por esta razn los usuarios prefieren comprar, o rentar software de empresas que ofrezcan productos sencillos de utilizar, productos intuitivos . A partir de la conceptualizacin llevada a cabo por la ISO, se infieren los principios bsicos en los que se basa la usabilidad Facilidad de Aprendizaje: facilidad con la que nuevos usuarios desarrollan una interaccin efectiva con el sistema o producto. Est relacionada con la predictibilidad, sintetizacin, familiaridad, la generalizacin de los conocimientos previos y la consistencia. Flexibilidad: relativa a la variedad de posibilidades con las que el usuario y el sistema pueden intercambiar informacin. Tambin abarca la posibilidad de dilogo, la multiplicidad de vas para realizar la tarea, similitud con tareas anteriores y la optimizacin entre el usuario y el sistema. Robustez: es el nivel de apoyo al usuario que facilita el cumplimiento de sus objetivos. Est relacionada con la capacidad de observacin del usuario, de recuperacin de informacin y de ajuste de la tarea al usuario. Pueden los usuarios realizar fcilmente sus tareas previstas? Por ejemplo, pueden los usuarios realizar las tareas previstas a la velocidad esperada? 37

Cunta preparacin necesitan los usuarios? Qu documentacin u otro material de apoyo estn disponibles para ayudar al usuario? Puede ste hallar las respuestas que buscan en estos medios? Cules y cuntos errores cometen los usuarios cuando interactan con el producto? Puede el usuario recuperarse de los errores? Qu han de hacer los usuarios para recuperarse de los errores? Ayuda el producto a los usuarios a recuperarse de los errores? Por ejemplo, muestra el software mensajes de error informativos y no amenazantes? Se han tomado medidas para cubrir las necesidades especiales de los usuarios con discapacidades? (Es decir, se ha tenido en cuenta la accesibilidad?) Las pruebas de usabilidad Estas pruebas consisten en seleccionar a un grupo de usuarios de una aplicacin y solicitarles que lleven a cabo las tareas para las cuales fue diseada, en tanto el equipo de diseo, desarrollo y otros involucrados toman nota de la interaccin, particularmente de los errores y dificultades con las que se encuentren los usuarios. No es necesario que se trate de una aplicacin completamente terminada, pudiendo tratarse de un prototipo Mtricas de usabilidad Exactitud: Nmero de errores cometidos por los sujetos de prueba y si estos fueron recuperables o no al usar los datos o procedimientos adecuados. Tiempo requerido para concluir la actividad. Recuerdo: Qu tanto recuerda el usuario despus de un periodo sin usar la aplicacin. Respuesta emocional: Cmo se siente el usuario al terminar la tarea (bajo tensin, satisfecho, molesto, etctera). Algunas preguntas que se contestas con estas pruebas son: Pueden los usuarios realizar fcilmente sus tareas previstas? Por ejemplo, pueden los usuarios realizar las tareas previstas a la velocidad esperada? Cunta preparacin necesitan los usuarios? Qu documentacin u otro material de apoyo estn disponible para ayudar al usuario? Puede ste hallar las respuestas que buscan en estos medios? Cules y cuntos errores cometen los usuarios cuando interactan con el producto? Puede el usuario recuperarse de los errores? Qu han de hacer los usuarios para recuperarse de los errores? Ayuda el producto a los usuarios a recuperarse de los 38

errores? Por ejemplo, muestra el software mensajes de error informativos y no amenazantes? Se han tomado medidas para cubrir las necesidades especiales de los usuarios con discapacidades? (Es decir, se ha tenido en cuenta la accesibilidad?)

c) Pruebas de rendimiento Las pruebas de rendimiento son las pruebas que se realizan, desde una perspectiva, para determinar lo rpido que realiza una tarea un sistema en condiciones particulares de trabajo. Tambin puede servir para validar y verificar otros atributos de la calidad del sistema, tales como la escalabilidad, fiabilidad y uso de los recursos. En las pruebas de rendimiento, a menudo es crucial (y con frecuencia difcil de conseguir) que las condiciones de prueba sean similares a las esperadas en el uso real. Esto es, sin embargo, casi imposible en la prctica. La razn es que los sistemas en produccin tienen un carcter aleatorio de la carga de trabajo y aunque en las pruebas se intente dar lo mejor de s para imitar el volumen de trabajo que pueda tener el entorno de produccin, es imposible reproducir exactamente la variabilidad de ese trabajo, salvo en el sistema ms simple.

Las tareas para realizar una prueba de este tipo seran las siguientes: Decidir usar recursos internos o externos para ejecutar las pruebas, en funcin de la experiencia (o falta de ella). Reunir u obtener requisitos de rendimiento (especificaciones) de los usuarios y/o analistas. Desarrollar un plan de alto nivel, incluyendo los requisitos, recursos, plazos e *hitos. Elaborar un plan de pruebas de rendimiento detallado (incluyendo los escenarios detallados y casos de prueba, cargas de trabajo, informacin del entorno, etc.). Elegir la/s herramienta/s de prueba. Especificar los datos de prueba necesarios y la distribucin de ellos (a menudo pasado por alto, y a menudo el fracaso de una prueba de rendimiento vlida). Desarrollar scripts de prueba de concepto para cada aplicacin/componente sometido a la prueba, utilizando la herramienta de prueba elegida y estrategias. Desarrollar un plan de prueba de rendimiento detallado, incluyendo todas las dependencias y los plazos. Configurar el entorno de prueba (lo ideal es que sea idntico hardware a la plataforma de produccin), configurar los router, aislar la red (no queremos alterar los resultados por parte de otros usuarios), desplegar la aplicacin en el servidor, desarrollar la base de datos de prueba, etc. 39

Ejecutar las pruebas, probablemente en repetidas ocasiones (iterativamente), a fin de ver si el desconocimiento de cualquier factor podra afectar a los resultados. Analizar los resultados - ya sea de aceptando/rechazando, o investigacin el camino crtico y recomendando medidas correctivas.

* Hito es una tarea de duracin cero que simboliza el haber conseguido un logro importante en el proyecto. Los hitos son una forma de conocer el avance del proyecto sin estar familiarizado con el proyecto y constituyen un trabajo de duracin cero porque simbolizan un logro, un punto, un momento en el proyecto. Algunas pruebas de rendimiento son las siguientes: Pruebas de carga Este es el tipo ms sencillo de pruebas de rendimiento. Una prueba de carga se realiza generalmente para observar el comportamiento de una aplicacin bajo una cantidad de peticiones esperada. Esta carga puede ser el nmero esperado de usuarios concurrentes utilizando la aplicacin y que realizan un nmero especfico de transacciones durante el tiempo que dura la carga. Esta prueba puede mostrar los tiempos de respuesta de todas las transacciones importantes de la aplicacin. Si la base de datos, el servidor de aplicaciones, etc. tambin se monitorizan, entonces esta prueba puede mostrar el cuello de botella en la aplicacin. Prueba de estrs Esta prueba se utiliza normalmente para romper la aplicacin. Se va doblando el nmero de usuarios que se agregan a la aplicacin y se ejecuta una prueba de carga hasta que se rompe. Este tipo de prueba se realiza para determinar la solidez de la aplicacin en los momentos de carga extrema y ayuda a los administradores para determinar si la aplicacin rendir lo suficiente en caso de que la carga real supere a la carga esperada. Prueba de estabilidad (soak testing) Esta prueba normalmente se hace para determinar si la aplicacin puede aguantar una carga esperada continuada. Generalmente esta prueba se realiza para determinar si hay alguna fuga de memoria en la aplicacin. Pruebas de picos (spike testing) La prueba de picos, como el nombre sugiere, trata de observar el comportamiento del sistema variando el nmero de usuarios, tanto cuando bajan, como cuando tiene cambios drsticos en su carga. Esta prueba se recomienda que sea realizada con un software automatizado que permita realizar cambios en el nmero de usuarios mientras que los administradores llevan un registro de los valores a ser monitoreados.

40

d) pruebas de seguridad Garantiza que los usuarios estn restringidos a funciones especficas o su acceso est limitado nicamente a los datos que estn autorizados a acceder. Garantiza que solo aquellos usuarios autorizados a acceder al sistema son capaces de ejecutar las funciones del sistema. Garantiza los objetivos especficos de seguridad de cada sistema. La seguridad se puede enfocar en 2 niveles: 1. Nivel de Seguridad de la Aplicacin: Verifica que un actor solo pueda acceder a las funciones y datos que su usuario tiene permitido. 2. Nivel de Seguridad del Sistema: Verificar que solo los actores con acceso al sistema y a la aplicacin estn habilitados para accederla.

reas donde tiene influencia: Seguridad del sistema, incluyendo acceso a datos o Funciones de negocios. Seguridad del sistema, incluyendo ingresos y accesos remotos al sistema.

Tcnicas de pruebas de seguridad: Identificar cada tipo de usuario y las funciones y datos a los que se debe autorizar. Crear pruebas para cada tipo de usuario y verificar cada permiso, creando transacciones especficas para cada tipo de usuario. Modificar tipos de usuarios y volver a ejecutar las pruebas. Crear pruebas para cada tipo de usuario y verificar cada permiso, creando transacciones especficas para cada tipo de usuario. Modificar tipos de usuarios y volver a ejecutar las pruebas. Para cada tipo de usuario conocido, las funciones y datos apropiados y todas las transacciones funcionan como se esperaba. Una vez realizadas las pruebas del sistema se toman acciones correctivas para componer y cambiar lo que se necesite, cuando est terminado el sistema se procede a su instalacin.

2.3.2 Instalacin de software

41

La instalacin de programas computacionales (software) es el proceso por el cual nuevos programas son transferidos a la computadora y eventualmente configurados para ser usados con el fin para el cual fueron desarrollados. Una instalacin exitosa es una condicin necesaria para el funcionamiento de cualquier software. Mientras ms complejo sea el software, es decir, entre otras caractersticas, mientras ms archivos contenga, mientras mayor la dispersin de los archivos y mientras mayor sea la interdependencia con otro software, mayor es el riesgo de alguna falla durante la instalacin. Si la instalacin falla aunque sea solo parcialmente, el fin que persigue la instalacin posiblemente no podr ser alcanzado. Por esa razn, sobre todo en casos de software complejo, el desarrollo de un proceso de instalacin confiable y seguro es una parte fundamental del desarrollo del software. En los ltimos aos se han desarrollado normas y tcnicas cada vez ms potentes para simplificar y estandarizar el proceso de instalacin de software. Ver Sistema de gestin de paquetes. Para la instalacin de software se pueden aplicar las siguientes tcnicas bsicas: Los archivos son simplemente copiados en algn lugar del directorio. Este sistema es fcil e intuitivo, y el preferido en Mac OS X. Un riesgo es que versiones ms antiguas hayan quedado abandonadas en algn otro lugar sin que nos demos cuenta. Se instala primero un instalador, el que posteriormente instala el software deseado. El sistema operativo o algn software permanente se ocupan de instalar un paquete de software con todos los archivos requeridos. Esto es un Sistema de gestin de paquetes. Pasos de la instalacin Verificacin de la compatibilidad: Se debe comprobar si se cumplen los requisitos para la instalacin en cuanto a hardware y software. Creacin de los directorios requeridos: Para mantener el orden en el directorio cada sistema operativo puede tener un estndar para la instalacin de ciertos archivos en ciertos directorios. Creacin de los usuarios requeridos: Para deslindar responsabilidades y tareas se pueden o deben usar diferentes usuarios para el uso del software. Copia de archivos que pueden ser: o Archivos principales, sean de fuente o binarios. o Archivos de datos, por ejemplo datos, imgenes, modelos, documentos XML, etc. o Documentacin o Archivos de configuracin o Bibliotecas o Enlaces a otros archivos Configuracin: Por medio de archivos de configuracin se le da a conocer al software con que parmetros debe trabajar. Por ejemplo, los nombres de las personas que pueden usar 42

el software, como verificar su clave de ingreso, la ruta donde se encuentran los archivos con datos o la direccin de nuestro proveedor de correo electrnico. En caso de que algunas bibliotecas del sistema operativo hayan sido cambiadas durante la instalacin, es necesario reiniciar el sistema operativo o el software nuevamente para hacer efectivos los cambios.

2.3.3 Cierre del proyecto

El proceso de cierre del proyecto incluye, a satisfaccin del cliente, la entrega formal y recepcin de los entregables y productos del proyecto, verificando y documentando los resultados del proyecto. El cierre considera la entrega ordenada de todos los documentos generados durante el desarrollo del proyecto, as como el cierre profesional de todos los acuerdos legales y evaluaciones de desempeo. Dicho proceso comienza despus de que el proyecto o su etapa cumplen con sus objetivos o es suspendido o cancelado por otras razones. El cierre del proyecto incluye un cierre contractual y un cierre administrativo. Cierre Contractual Conclusin profesional de los acuerdos legales, incluyendo documentos tales como: finanzas, garantas, manuales, comunicados, etc. Involucra de la verificacin del producto y el cierre administrativo de cada contrato. Cierre Administrativo Consiste en verificar y documentar los resultados del proyecto para formalizar la aceptacin del producto por parte del cliente, incluye la recoleccin de documentos con las especificaciones finales, anlisis de efectividad, el xito del proyecto y el archivo de toda esa informacin para su uso futuro.

Pasos del proceso de cierre del proyecto 1. El equipo del proyecto comunica que finaliz los entregables, sealando que los criterios de prueba fueron aprobados. 2. El lder del proyecto debe llamar al patrocinador y/o al cliente para solicitarles que validen los entregables. En ocasiones, se redacta un documento formal para que se aprueben dichos entregables, pero por falta de costumbre en proyectos, no es lo usual en el mercado latinoamericano. 3. El lder de proyecto debe cerrar formalmente el proceso de administracin de las contrataciones, pero, generalmente, en Latinoamrica esa responsabilidad se halla bajo el mbito 43

del rea de compras y no del gerente. En EE.UU, en cambio, ocurre lo contrario: es ms frecuente que el gerente de proyecto se ocupe de todos los contratos con los proveedores, negociaciones de contratacin, licitaciones. Como gerentes, somos responsables de este proceso y, por lo tanto, cuando finaliza el proyecto, debemos verificar todos los contratos que se pactaron, si se cumplieron y constatar el desempeo del proveedor. Por ejemplo, si cumpli con las clusulas o con las condiciones y, adems, si se le abon en tiempo y forma. Es decir, debemos estar presentes hasta ltimo momento y unir todos los cabos sueltos en este proceso de cierre. En tal sentido, aun cuando el proyecto hubiese sido interrumpido o detenido, o se hayan retirado los proveedores, debemos efectuar el trmite administrativo de cierre de contratos. Se recomienda llevar una carpeta que incluya todos los contratos del proyecto y su verificacin, as como la descripcin del desempeo de los proveedores. Asimismo, debemos proporcionarle al proveedor una hoja firmada, informndole que su contrato ha finalizado, y recin a continuacin realizar el cierre administrativo. 4. El cierre formal de las obligaciones con los proveedores implica que debemos supervisar que el rea de compras tambin haya cerrado los contratos con dichos proveedores (si esto aplica en la organizacin). 5. Junto con el equipo, llevaremos a cabo un anlisis de las lecciones aprendidas durante el desarrollo del proyecto, no con la intencin de criticar, sino para que esta experiencia pueda ser aprovechada en proyectos futuros. Por ejemplo, un miembro del equipo que cuente acerca de algn obstculo que encontr en el proyecto y de cmo lo solucion. O de cuestiones importantes a tener en cuenta para proyectos similares. Cmo lograr que el equipo se exprese, que no se sienta inhibido? Es responsabilidad del gerente de proyecto crear un clima propicio para esto, quizs sacando al equipo de la oficina, o coordinando una actividad especial para lecciones aprendidas. Las lecciones aprendidas conllevan una actividad que se realiza en el cierre de todo proyecto, cuyo objetivo es analizar con el equipo qu sali bien, qu sali mal, qu conclusiones, consejos, advertencias, podemos rescatar para proyectos futuros. Las Lecciones Aprendidas es la ltima oportunidad que tiene el gerente de proyecto de intercambiar opiniones y vivencias del proyecto con su equipo, antes que este se disuelva. Es una actividad que podra llevar solamente unas horas al final del proyecto, pero que sus frutos son inmensamente valiosos para los proyectos futuros en la organizacin. 6. Se hace una evaluacin del desempeo del equipo de trabajo, sobre todo si se extendi considerablemente el proyecto o si nos encontramos en una organizacin matricial, en la que 44

como se ha mencionado- los integrantes del proyecto reportan al gerente de proyecto y al gerente funcional. 7. Debemos archivar los documentos del proyecto para poder volver a utilizarlos. Es decir, procuraremos que cada miembro del equipo vuelque la informacin en un repositorio comn, que en realidad debera ser el resultado de la recopilacin de todos los documentos que se han ido elaborando en el desarrollo de los trabajos. Debemos impedir que a la finalizacin del proyecto la informacin quede en cada una de las PCs de los miembros del equipo y, por eso, debemos impulsar una cultura de compartir los documentos y colocarlos en un solo repositorio. 8. Despus de archivar los documentos con la colaboracin de nuestro equipo, realizamos un proceso de transferencia de conocimiento, que servir para la operacin del producto que hemos creado, lo que ms adelante realizar otro equipo. Es indispensable realizar este paso, porque si no lo efectuamos, significar que el proyecto no se finaliz en forma adecuada y que nadie sabr cmo se usa lo que construimos.

Un Informe de Cierre debe incluir al menos la siguiente informacin: Aspectos Generales del Proyecto o Productividad o Calidad o Feedback de los Clientes Aspectos Metodolgicos o Metodologa usada o Herramientas usadas Diferencias o Duracin del Proyecto o Utilizacin del Presupuesto o Riesgos Conclusiones Generales Recomendaciones

45

ANEXO 1 Formato de Propuesta (Request For Proposal)

Datos generales de la empresa Nombre de la empresa: Giro/sector de la empresa: Antecedentes de la empresa: Datos del producto o servicio Caractersticas tcnicas: Alcance del producto o servicio: Cantidad: Plataformas: Estndares a manejar: Criterios de aceptacin y seleccin Tiempos de entrega Requisitos tcnicos: Soporte que se dar: Precio convenido: Entregable Descripcin Criterio de aceptacin

Observaciones:
NOTA: Este formato se puede adaptar de acuerdo al problema a resolver.

46

ANEXO 2 FORMATO DE BITACORA

Actividad

Fecha

Hora inicio

Hora fin

Lugar

Responsable

47

ANEXO 3 Ejemplo de caso de uso

CASO DE USO: QUEJAS

PROPIEDAD Nombre DESCRIPCIN QUEJAS

Breve descripcin

Buzn de Quejas: El visitante utilizar el buzn de quejas para interponer quejas ante el organismo por presuntas violaciones a los derechos humanos. El sistema enviara copia de la queja al buzn del visitante, una vez que el abogado responsable de leer el buzn de quejas del organismo lo especifique explcitamente, y sta haya sido registrada en la base de datos.

Flujo se eventos El visitante interpone quejas en el buzn de quejas. El abogado lee el buzn de quejas y mediante la opcin link Enviar una copia de las quejas al buzn electrnico del visitante. Registrar las quejas en la base de datos. Requerimientos especiales

Al interponer la queja el visitante deber indicar los siguientes datos: Nombre Direccin Telfono Email Fecha de recepcin (automticamente) Autoridad responsable de la violacin (si es que la conoce) Hechos violatorios a derechos humanos (narracin de cmo ocurrieron los hechos). En la queja recibida por el abogado en el buzn de quejas, deber incluir una opcin link.

Precondiciones Poscondiciones Puntos de extensin Relaciones -

Solo los visitantes pueden interponer quejas. El visitante recibir en su buzn electrnico una copia de las quejas una vez ledas por el abogado correspondiente.

48

Diagrama de caso de uso

49

ANEXO 4 Ejemplo de entrevista Entrevista realizada al restaurante mi sabor, para identificar el proceso de negocio cuando se sirve al cliente. Analista
Gracias por atendernos Es un placer Empecemos con una sencilla transaccin de negocios, Qu sucede cuando un cliente entra en el restaurante?

Restaurantero
Qu es exactamente lo que desea saber? Bueno, si el cliente tiene un abrigo o chaqueta, le ayudamos a quitrsela, lo almacenamos en un guardarropa y le damos un boleto para que pueda solicitarlo posteriormente. Esto mismo hacemos con un sombrero. Luego nosotros No, intentamos que se sientan tan cmodos como sea posible desde su llegada, luego nos preocupamos por la lnea de espera en caso de haber alguna. De hecho si hay una lnea de espera, le preguntamos al cliente si hizo alguna reservacin. Si la hizo intentamos honrarlos de forma oportuna y darles asiento tan pronto como sea posible. Si no hay una reservacin, deja su nombre y puede ir a nuestro bar para tomar algo antes de comer. Claro que no es obligatorio que lo hagan, pueden tan solo sentarse en el rea de espera indicada.

Un momento Suponga que hay otros clientes esperando Primero se forma, o da su nombre al capitn o?

Interesante, an no se han sentado a comer y ya se han logrando algunos puntos decisivos. Hagamos una pausa para determinar a dnde llegamos. Bien, cuando llegue al turno al cliente, o que haya llegado un cliente que hizo reservacin, ser hora de sentarlo, no?

Lo llama?

S, pero ahora que lo pienso no es tan sencillo, la mesa deber estar lista; para ello, deber ser limitada. Un mozo de piso debe cambiar el mantel usado por el cliente anterior, y acomodar la mesa. Cuando esta lista, el capitn de meseros lleva al cliente a su mesa y luego llama a un mesero. S. No es muy complicado dado que los meseros tienen sus reas asignadas de servicio y, por lo general, saben cuando est lista una mesa. Normalmente circundan su rea y estn atentos a las expresiones del capitn. 50

Analista
Luego qu ocurre?

Restaurantero
Bueno, el mesero llega a la mesa, entrega un men a casa comensal y les preguntan si desean una bebida mientras se deciden. Luego llamara a un asistente, quien coloca una charola con pan y mantequilla, llenara un vaso con agua para cada persona en la mesa. Si alguien ha pedido una bebida el mesero la traer. No, hablo de el mesero por hbito. Lo siento. Sirviente no es una palabra que usemos en el mbito restaurantero. Es mejor que usemos mesero indistintamente para hombres y mujeres. Es cierto, si el cliente est en espera de una mesa y pas al bar, puede llevarse su bebida a la mesa si no se la ha terminado una vez que se la asignen; a propsito, siempre nos reservamos el derecho a negar el servicio a quien ha consumido demasiado alcohol. S, siempre tenemos sugerencias del da que no estn en el men, y el mesero se las propone a los clientes. Sabe que es lo que el he visto que pasa?, la gente le pide al mesero las recomendaciones y los meseros por lo general parecen ser sinceros: les dicen si un platillo es mejor que otro. As es, ciertamente nuestros meseros comen en el restaurante y tiene sus opiniones de lo que les gusta y lo que no. Si a ellos realmente no les gusta un platillo, en particular, queremos que lo digan al chef antes que a los clientes; aunque no tengo inconveniente que expresen su preferencia. Claro que no quiero que los meseros les digan a los comensales que la comida es terrible, pero expresar una preferencia por un platillo no est mal. As es. El mesero regresa con una bebida y los clientes la beben mientras ven el men. El mesero les da de cinco a diez minutos para hacer su eleccin y, luego, regresa. El mesero regresa antes s, claro, los comensales hacen
51

Un momento, Dijo, el mesero, la persona siempre es un hombre Bien, que tal si utilizamos el termino neutral sirviente.

Bien. Vi que el cliente tiene un par de oportunidades para pedir una bebida.

Es bueno saberlo, regresemos a la mesa donde los clientes deciden que van a consumir.

Es algo que usted aliente a hacer?

Bien. Vamos a resumir. El cliente o comensal deja sus abrigos, entra en el bar, aguarda una mesa, se sienta el ella, posiblemente ordena una bebida, se le sirve pan y agua y mira el men.

Analista
Cmo saben que deben regresar antes?

Restaurantero
su eleccin antes. Bien, los clientes llaman la atencin del mesero. Por lo general est cerca del rea de la mesa, a menos que haya tenido que ir a la cocina a traer un pedido o necesitara hablar con los chefs por alguna razn. S, a cada mesero se le asigna un rea que consta de varias mesas. Hay una seccin asignada como rea de fumadores, y el resto es para quienes no fuman. Alternamos a los meseros en las diferentes reas. Y luego, notifica al chef. Esto lo hace mediante la trascripcin de la eleccin de un formulario, llamado comanda que le da al chef. La mesa, la eleccin y, muy importante, la hora Debido a que generalmente la cocina est (espero) muy ocupada, y el chef tiene que dar prioridad a los comensales en el orden en que hayan llegado. Es realidad, se complica ms de acuerdo con su naturaleza. La mayora de las comidas incluyen un entrems antes del plato principal. A la mayora de la gente le gusta comer el plato fuerte caliente, as que el chef prepara el entrems, muchos de ellos ya estn preparados, como algunas ensaladas, y el mesero se los lleva al cliente. El reto est el llevar el plato fuerte, caliente, a todos los comensales al mismo tiempo. Digo reto porque las personas en la mesa se terminan el entrems en diferentes momentos. Todo el asunto debe estar coordinado. De acuerdo, es una buena idea.

rea?

Cmo determinan quin atiende un rea? Bueno, volvamos al proceso de servir. Los comensales hacen su eleccin, los meseros toman la orden en su comanda y luego Qu hay en la comanda? Por qu es tan importante?

Eso es complicado? Cmo est eso?

Hmmm. Esto suena a un proceso separado. Tomaremos eso en una reunin por separado desde el punto de vista del chef. Estamos en el punto, donde el chef prepara el plato fuerte.

El chef preparar el plato fuerte y el mesero lo recoger cuando se d cuenta de que los comensales han terminado con el entrems; posteriormente, el mesero llevar el plato fuerte a la mesa. Los comensales ingerirn sus alimentos y el mesero regresar al menos una
52

Analista
Suponga que a un cliente no le ha satisfecho algo de la comida, Qu ocurre?

Restaurantero
vez para verificar si todo est bien. Bueno. Hacemos nuestro mejor esfuerzo para que le satisfaga, an cuando nos cueste algo de dinero. Es mejor perder algo de dinero que a un cliente. Gracias. Cuando los comensales terminan con sus alimentos, el mesero regresa y pregunta si desean un postre. En tal caso, el mesero dar el men de postres y tomar las rdenes. En caso de que no deseen postre, preguntar si desean un caf. Si es el caso, traer caf y tazas y les servir. Si no desean nada, traer la cuenta. Luego de unos instantes, regresar y obtendr el pago en efectivo o con tarjeta de crdito. Luego traer el cambio o los Boucher, los clientes dejarn su propina, recogern sus abrigos y se irn. No necesariamente, el mesero llamara al mozo de piso para que limpie la mesa, la prepara y la deja lista para los siguientes comensales. l permanece en su rea, y echa una mirada a cada mesa. La experiencia le dicta cuanto le toma a los comensales ingerir sus alimentos, de forma que se pude anticipar a ello cuando est cerca de una mesa. Otra pregunta? En ocasiones el cliente necesita saber cunto tardar la preparacin de un alimento. En tales casos, el cliente llama al mesero, quien le pregunta al chef, una vez que se informa, regresa y le responde al cliente. Es curioso que lo diga, hasta que me pidi que le describiera los pasos, yo tampoco lo haba analizado mucho.

Buen concepto

Es todo?

Dado que ello no tiene que ver con el cliente, voy a considerarlo dentro de un proceso por separado, aunque sea breve. Quiero hacerle un par de preguntas. La primera, Cmo sabe el mesero que la gente ha terminado? S, dijo que el mesero podra estar en la cocina para hablar con el chef por alguna razn, cul sera tal razn?

Sabe?, nunca me haba dado cuenta de todo lo que ocurre para servir a un cliente en un restaurante.

53

ANEXO 5 FORMATO DE MINUTA

Fecha: Participantes:
Minuta

No: 01

Lugar de Reunin:

Agenda

Asunto
Leer la minuta de la junta anterior Revisar seguimiento del proyecto Hacer casos de uso por Se resolvi hacer una junta cada semana con el cliente El encargado de publicar las minutas es Resumen de acuerdos El encargado de disear la portada es

Tiempo

Asuntos pendientes:

Fecha de la prxima reunin:

Nombre y firma del lder del proyecto

Nombre del Secretario 54

ANEXO 6 Ejemplo de contrato de desarrollo de SW

CONTRATO DE DESARROLLO DEL PROGRAMA DE COMPUTO: (________________________________________________________) QUE EN LO SUCESIVO SE DENOMINARA SISTEMA, QUE CELEBRAN POR UNA PARTE: __________________________________________________________________________, COMO PRESTADOR DEL SERVICIO, A QUIEN EN LO SUCESIVO SE LE DENOMINARA PROVEEDOR Y POR OTRA PARTE: __________________________________________________________________, A QUIEN EN LO SUCESIVO SE LE DENOMINARA COMO CLIENTE, CONTRATO QUE CELEBRAN AMBAS PARTES DE CONFORMIDAD CON LAS SIGUIENTES DECLARACIONES Y CLAUSULAS: DECLARA EL PROVEEDOR: 1. SER UNA EMPRESA CONSTITUIDA AL AMPARO DE LA LEGISLACION MEXICANA, CON DOMICILIO EN ______________________________________________________ Y DEBIDAMENTE INSCRITA ANTE LA SECRETARIA DE HACIENDA Y CREDITO PUBLICO DE ESTA CIUDAD, CON REGISTRO FEDERAL DE CONTRIBUYENTES ___________________________ Y ES SU VOLUNTAD CELEBRAR ESTE CONTRATO. 2. QUE DISEARA Y DESARROLLARA EL SISTEMA EN EL LENGUAJE _ ________________________ BAJO EL SISTEMA OPERATIVO ____________________________________ 3. EL SISTEMA ESTARA COMPUESTO DE MODULOS Y PROGRAMAS QUE SE DESCRIBEN EN EL DOCUMENTO PROPUESTA DEL PROYECTO, QUE CONSTITUYE EL ANEXO A DEL PRESENTE CONTRATO Y EL CUAL FORMA PARTE INTEGRAL DEL MISMO. 4. QUE SE ENTREGARA EL SISTEMA EN MEDIOS ADECUADOS QUE PERMITA SU DEBIDA UTILIZACION POR PARTE DEL CLIENTE. 5. QUE CUENTA CON LOS RECURSOS TECNICOS Y HUMANOS PARA REALIZAR EL OBJETO DEL PRESENTE CONTRATO.

DECLARA EL CLIENTE: 1. SER UNA EMPRESA CONSTITUIDA AL AMPARO DE LA LEGISLACION MEXICANA, CON DOMICILIO EN _________________________________________________________ Y DEBIDAMENTE INSCRITA ANTE LA SECRETARIA DE HACIENDA Y CREDITO PUBLICO DE ESTA CIUDAD, CON REGISTRO FEDERAL DE CONTRIBUYENTES ____________________________ Y ES SU VOLUNTAD CELEBRAR ESTE CONTRATO. 2. QUE COMPARECE A TRAVES DE SU REPRESENTANTE ____________________________________________________________________, LEGAL QUE 55

CUENTA CON LA SUFICIENTE CAPACIDAD Y FACULTADES PARA CELEBRAR EL PRESENTE CONTRATO.

CELEBRAN LAS PARTES: RECONOCERSE MUTUAMENTE LA PERSONALIDAD Y CARACTER CON QUE COMPARECEN A CELEBRAR EL PRESENTE CONTRATO Y QUE ES SU DESEO CELEBRARLO AL TENOR DE LAS SIGUIENTES CLAUSULAS. CL A U S U L A S 1. PROPIEDAD: POR VIRTUD DEL PRESENTE CONTRATO, EL PROVEEDOR OTORGA A FAVOR DEL CLIENTE LA PROPIEDAD EXCLUSIVA DE ARCHIVOS EJECUTABLES DEL SISTEMA NO INCLUYENDO LOS ARCHIVOS DE CODIGO FUENTE, CUYOS MODULOS Y FUNCIONES SERAN DESARROLLADAS Y QUE SE DESCRIBEN EN EL DOCUMENTO PANORAMA DEL PROYECTO, QUE CONSTITUYE EL ANEXO A DEL PRESENTE CONTRATO. 2. SISTEMA: EL SISTEMA SE ENTREGARA EN DISCO COMPACTO, EL CUAL CONTENDRA EL MANUAL DE OPERACION DEL USUARIO, LA DOCUMENTACION TECNICA NECESARIA PARA PONERLO EN FUNCIONAMIENTO Y LOS PROGRAMAS DE COMPUTO REQUERIDOS PARA SU INSTALACION. 3. FECHA DE ENTREGA: QUEDA EXPRESAMENTE CONVENIDO QUE EL SISTEMA SERA ENTREGADO AL CLIENTE EL _________________________________, DE ACUERDO CON EL CALENDARIO QUE SE DESCRIBE EN EL DOCUMENTO CRONOGRAMA DE ACTIVIDADES, QUE CONSTITUYE EL ANEXO B DEL PRESENTE CONTRATO. 4. CAPACITACION: A) EL PROVEEDOR PROPORCIONARA AL CLIENTE LA CAPACITACION EXCLUSIVA PARA EL USO DEL SISTEMA MEDIANTE _______ CURSOS CONSISTENTES EN ______ HORAS, IMPARTIDOS A _______ PERSONAS POR CURSO. B) LA CAPACITACION NO INCLUYE IMPARTIR CONOCIMIENTO DE LA OPERACION DEL EQUIPO NI DEL SISTEMA OPERATIVO, SI ESTO FUERA NECESARIO SERIA MOTIVO DE UNA COTIZACION ESPECIAL. C) EL CLIENTE DESIGNARA AL PERSONAL QUE ASISTIRA A LOS CURSOS DE CAPACITACION 5. PROCEDIMIENTO DE INSTALACION: A) EL PROVEEDOR SE OBLIGA A INSTALAR DICHO SISTEMA EN EL EQUIPO DE COMPUTO DESIGNADO POR EL CLIENTE B) EL CLIENTE. ES RESPONSABLE DE INTRODUCIR TODOS LOS DATOS NECESARIOS PARA LA PUESTA EN MARCHA DEL SISTEMA. 6. PRECIO: EL CLIENTE SE OBLIGA A PAGAR AL PROVEEDOR POR EL DESARROLLO DEL SISTEMA, LA CANTIDAD DE ( $______________ ) PESOS M. N., LA CUAL SERA PAGADA MEDIANTE UN PAGO INICIAL DEL ________ % AL INICIO DEL DESARROLLO DEL SISTEMA Y POR _________ PAGO(S) RESTANTES BASADOS EN LOS SIGUIENTES MONTOS Y FECHAS: ________________________________________________ ________________________________________________ ________________________________________________ 56

7. GARANTIAS:
A) EL PROVEEDOR GARANTIZA QUE EL SISTEMA SE ENCUENTRA LIBRE DE ERRORES O DEFECTOS Y QUE EJECUTA SUS FUNCIONES DE ACUERDO A LO ESPECIFICADO POR EL CLIENTE.

B)

8.

9.

10.

11.

EL CLIENTE CUENTA CON _________ MESES A PARTIR DE LA FECHA DE TERMINACION E INSTALACION DEL SISTEMA PARA REPORTAR FALLAS O ERRORES EXCLUSIVOS DEL SISTEMA, EN ESTE CASO EL PROVEEDOR ATENDERA INMEDIATAMENTE LAS RECLAMACIONES DEL CLIENTE Y EFECTUARA LAS CORRECCIONES QUE RESULTEN NECESARIAS, SIN CARGO ADICIONAL. MANTENIMIENTO: AL VENCIMIENTO DEL PERIODO DE GARANTIA, EL CLIENTE PODRA CELEBRAR CON EL PROVEEDOR UN CONTRATO DE MANTENIMIENTO QUE LE PERMITE SOLICITAR NUEVAS VERSIONES O ACTUALIZACIONES, DE CONFORMIDAD CON LOS TERMINOS, CONDICIONES Y PRECIOS QUE AMBAS PARTES DETERMINEN EN ESE MOMENTO. CONFIDENCIALIDAD: AMBAS PARTES CONVIENEN Y SE OBLIGAN A NO DIVULGAR A TERCEROS NINGUNA INFORMACION CONCERNIENTE A SUS NEGOCIOS, CLIENTES, SECRETOS INDUSTRIALES Y COMERCIALES, METODOS, PROCESOS, PROCEDIMIENTOS O CUALQUIER OTRA INFORMACION CONFIDENCIAL. CAUSAS DE RECISION DE CONTRATO: EL PRESENTE CONTRATO SERA CANCELADO EN CASO DEL INCUMPLIMIENTO POR PARTE DEL CLIENTE DE LOS SIGUIENTES TERMINOS: A) NO CUMPLIR CON ALGUNO DE LOS PAGOS ESTIPULADOS EN LA CLAUSULA 6 B) NO PROPORCIONAR LA INFORMACION NECESARIA PARA EL DESARROLLO DEL SISTEMA C) NO ASISTIR A LAS REUNIONES DE REVISION DE AVANCES ESTIPULADAS EN EL DOCUMENTO CRONOGRAMA DE ACTIVIDADES, QUE CONSTITUYE EL ANEXO B DEL PRESENTE CONTRATO LEYES Y TRIBULACIONES COMPETENTES: PARA LA INTERPRETACION Y CUMPLIMIENTO DEL PRESENTE CONTRATO LAS PARTES SE SOMETEN EXPRESAMENTE A LA JURISDICCION Y LEYES DEL ESTADO DE PUEBLA, RENUNCIANDO AL FUERO QUE PUDIERE CORRESPONDERLE POR RAZON, DOMICILIO PRESENTE O FUTUROS.

LEIDO QUE FUE EL PRESENTE CONTRATO, POR LAS PARTES QUE EN EL INTERVIENEN, LO FIRMA DE COMUN ACUERDO EN LA CIUDAD DE PUEBA, PUE., EL DIA ______DEL MES ______ DE _______.

FIRMAS DE CONFORMIDAD

PROVEEDOR REPRESENTADO POR:

CLIENTE REPRESENTADO POR:

57

BIBLIOGRAFIA

Trujillo, M. M. (2010), Innovacin y desarrollo Tecnolgico: Un espacio con rostro humano. Mxico: Trillas. Yamal, C. (2002) Administracin Profesional de Proyectos: La Gua. Mxico: Mc Graw Hill. PMI. (2004), Gua de los Fundamentos de la Direccin de Proyectos. E.U.: Project Management Institute Inc. Henry, J. (2006). Teaching Through Projects. Reino Unido: Routledge. Markham, T. (2008). Project Based Learning Handbook. E.U.: Buck Inst for Education. Moursund. D. (2008). Project Based Learning- using information technology (Second edition). E.U.: International Society for Technology in education (ISTE). Tcnicas de investigacin y anlisis de problemas. Recuperado el 11 de enero de 2010, de http://www.matematicasypoesia.com.es/monografias/tecinvest.htm Formulacin del problema. Recuperado el 15 de enero de 2010, de cursa.ihmc.us/rid=1177277211154_1735896367_5225/formulacion.pdf Alcance del proyecto. Recuperado el 17 de febrero de 2010, de http://www.tress.com.mx/esp/Portals/0/Documentos%20varios/Bolet%C 3%ADn%20mensual/Abril/Alcance%20proyecto.pdf Planeacin y elaboracin de un centro de cmputo. Recuperado el 20 de abril de 2010, de http://www.scribd.com/doc/16253152/PLANEACION-YELABORACION-DE-UN-CENTRO-DE-COMPUTO

58