Contratos y requisitos organizacion del proyecto, roles(o)

GESTION DE PROYECTO SOFTWARE

ICA – PERU

2013

1 LOS CONTRATOS Y LOS REQUISITOS

LA ORGANIZACIÓN DEL PROYECTO LOS ROLES

DISEÑO E IMPLEMENTACION

DE SISTEMAS

ELIAS PALLIN, FABIOLA

MISAICO PALOMINO, CHRISTIAN

QUINTEROS TUMBA, EDUARDO

CICLO VIII – S1

INGENIERIA DE SISTEMAS




DE SISTEMAS

Este trabajo fue realizado con arduo esfuerzo y

apoyo de nuestros padres que gracias a ellos

nos inculcaron la enseñanza que nos llevara a

ser exitosos profesionales.




DE SISTEMAS

El principal objetivo del presente trabajo es dar a conocer y poner en

práctica los conocimientos sobre la organización de los proyectos, roles,

sus contratos y requisitos también la relación que existen entre estos

términos.

Nuestra investigación, evolución, comprensión y trabajo parten de las definiciones Diseño e

implementación del sistema y de todos los puntos que integran estos términos. Ya que

actualmente están complementadas en los proyectos.

En la actualidad, la organización de los proyectos es una forma de organizar de una manera

adecuada para facilitar un mejor trabajo en la empresa que nos permite brindar mejores

facilidades al usuario.

Es uno de los principales objetivos estratégicos de las organizaciones, debido a que cada vez

más, los procesos principales de las organizaciones llegan a depender de los sistemas

informáticos para su buen funcionamiento y desarrollo.

Los cambios y evolución por la que ha pasado organización de los proyectos se han convertido

en requisitos dispensables en las empresas para una mejor calidad de diseño e implementación

de sistemas. Últimamente existen publicaciones de diversos estudios en los que se expone los

principios que se deben seguir para la mejora tanto de productos como de procesos de software.

Interviniendo en la calidad que proponen las organizaciones.




DE SISTEMAS

1. Contratos y Requisitos.

1.1. Contratos

Un contrato es un acuerdo mutuamente litigante que obliga al vendedor a proveer el

producto especificado y obliga al comprador a pagar por él. Un contrato es una relación

legal sujeta a mejoras en las cortes. El acuerdo puede ser simple o complejo,

usualmente (pero no siempre) reflejando la simplicidad o complejidad del producto. Se

puede llamar, entre otras cosas, un contrato, un acuerdo, un subcontrato, una orden de

compra, o un memorando de acuerdo. La mayoría de las organizaciones tienen políticas

documentadas y procedimientos que definen quienes pueden suscribir tales acuerdos

de parte de las organizaciones.

1.1.1. Administración del Contrato

La administración del contrato es el proceso de asegurar que el desempeño del

vendedor cumplirá con los requerimientos contractuales. En los grandes proyectos con

múltiples proveedores de productos o servicios, el aspecto clave de la administración

del contrato es manejar las interfaces entre los varios proveedores. La naturaleza legal

de las relaciones contractuales hace que sea imperativo que el equipo del proyecto esté




DE SISTEMAS

atento de las implicaciones legales de las acciones que se toman cuando se administre

el contrato.

La administración del contrato incluye la aplicación de los procesos administrativos de

proyecto adecuados a las relación(es) contractuales y a la integración de las salidas de

esos procesos en la administración general del proyecto. Esta integración y

coordinación ocurrirá muchas veces en múltiples niveles en los que hay múltiples

proveedores y múltiples productos involucrados. Los procesos administrativos de

proyectos que deben ser aplicados incluyen:

Ejecución del plan de proyecto, para autorizar el trabajo del contratista en el momento adecuado.

Reportes de desempeño, para monitorear el costo, programación, y desempeño técnico del contratista.

Control de calidad, para inspeccionar y verificar lo adecuado del producto del contratista.

Control de cambios, para asegurar que los cambios son aprobados de manera adecuada, y que aquellas personas con necesidad de conocer dichos cambios se enteran de estos de manera oportuna.

La administración de contratos también tiene una componente administrativa financiera.

Los términos de pago deben ser identificados dentro del contrato y deben proveer una

relación específica entre el progreso alcanzado y su pago de compensación.

1.1.1.1. Entradas a la Administración de Contratos

a) Contrato. Los contratos están descritos en la Sección 1.1 b) Resultados de trabajo. Los resultados del trabajo del vendedor – que entregas

han sido completadas y cuáles no, hasta qué punto los estándar de calidad se

han cumplido, en que costos se ha incurrido o se ha comprometido, etc.) son

recolectados como parte de la ejecución del plan del proyecto

c) Requisiciones de cambio. Las requisiciones de cambio pueden incluir

modificaciones a los términos del contrato o a la descripción de los productos o

servicios que serán proveídos. Si el trabajo del vendedor no resulta satisfactorio,

una decisión de terminación de contrato también seria manejada como una




DE SISTEMAS

requisición de cambio. Los cambios contestados, aquellos donde el vendedor y

el equipo administrativos de proyecto no se pueden poner de acuerdo sobre la

compensación para el cambio, son llamadas de varias maneras: reclamos,

disputas, o apelaciones.

d) Facturas del vendedor. El vendedor

debe elaborar facturas de tiempo en

tiempo solicitando pago por el trabajo

ejecutado. Los requerimientos de

facturación, incluyendo la

documentación de soporte necesaria,

están usualmente definidas en el

contrato.

1.1.1.2. Herramientas y Técnicas para la Administración de Contratos

a) Sistema de control de cambios al contrato. Un sistema de control de cambios

al contrato define los procesos por los cuales el contrato puede ser modificado.

Este incluye el papeleo, sistemas de seguimiento, procedimientos de resolución

de disputas, y niveles de aprobación necesarios para la autorización de cambios.

El sistema de control de cambios al contrato deberá estar integrado con el

sistema general de control de cambios (la Sección 4.3 describe el sistema

general de control de cambios)

b) Reportes de desempeño. Los reportes de desempeño proveen a la

administración con información sobre qué tan efectivamente el vendedor está

logrando los objetivos contractuales. Los reportes de desempeño del contrato

deberán estar integrados con los reportes generales de desempeño del

proyecto.

c) Sistemas de pago. Los pagos al vendedor son generalmente manejados por el

sistema de cuantas a pagar de la

organización ejecutora. En proyectos más

grandes con muchos o muy complejos

requerimientos de procuración, el proyecto

puede desarrollar su propio sistema. En

cualquier caso, el sistema debe incluir las

revisiones y aprobaciones del equipo

administrativo del proyecto.




DE SISTEMAS

1.1.1.3. Salidas de la Administración de Contratos

I. Correspondencia. Las condiciones y términos de contrato muchas veces

requieren de documentación escrita de ciertos aspectos de la comunicación

comprador/vendedor, tales como advertencias de ejecuciones insatisfactorias y

de cambios o clarificaciones en el contrato.

II. Cambios al contrato. Los cambios (aprobados o no) son retroalimentados a

través de los procesos apropiados de planeación y procuración de proyecto, y

del plan del proyecto y otros documentos relevantes a medida que estos son

actualizados como sea necesario.

III. Requisiciones de pago. Esto asume que el proyecto está usando un sistema

externo de pago. Si el proyecto tiene su sistema interno, la salida aquí seria

simplemente "pagos".

1.1.2. Cierre del Contrato

El cierre del contrato es similar al cierre administrativo (descrito en la Sección 10.4) en

que involucra tanto la verificación del producto (Fue todo el trabajo terminado de

manera correcta y satisfactoria) y el cierre administrativo (la actualización de archivos

para reflejar los resultados finales y la activación de tal información para uso futuro). Los

términos y condiciones del contrato pueden prescribir procedimientos específicos para

el cierre del contrato. La terminación temprana de un contrato es un caso especial del

cierre de un contrato.

1.1.2.1. Entradas al Cierre de Contratos

1. Documentación contractual. La documentación contractual incluye, pero no

está limitada a, el contrato en si con todos sus cronogramas de soporte, los

cambios aprobados y propuestos de contrato, cualquier documentación técnica

desarrolladas por proveedor, los reportes del desempeño del proveedor,

documentos financieros tales como facturas o registros de pagos, y los

resultados de cualquier inspección relacionada con el contrato.

2.- Auditorías de procuración. Una auditoría de procuración es una revisión

estructurada de los procesos de procuración desde la planeación de la procuración

hasta la administración del contrato. El objetivo de una auditoría de procuración es

identificar los logros y fracasos que obligan a la transferencia a otros ítems de

procuración en este proyecto o a otros proyectos dentro de la organización

ejecutora.




DE SISTEMAS

1.1.2.2. Salidas del Cierre de Contratos

1. Archivos de contrato. Un juego completo indexado de archivos deberá ser

preparado para su inclusión con los archivos finales del proyecto (véase la

Sección 10.4.3.1 para una discusión más detallada del cierre administrativo).

2. Aceptación formal y cierre. La

persona o organización responsable por

la administración del contrato deberá

proveer al vendedor con la notificación

escrita de que el contrato ha sido

completado. Los requerimientos para la

aceptación formal y cierre están

usualmente definidos en el contrato.

1.2. Requisitos

En la ingeniería de sistemas, la Ingeniería de requisitos o Ingeniería de

requerimientos comprende todas las tareas relacionadas con la determinación de las

necesidades o de las condiciones a satisfacer para un software nuevo o modificado,

tomando en cuenta los diversos requisitos de los inversores, que pueden entrar en

conflicto entre ellos.

Muchas veces se habla de requerimientos en vez de requisitos; esto se debe a una

mala traducción del inglés. La palabra requirement debe ser traducida como requisito,

mientras que requerimiento se traduce al inglés

como request.

El propósito de la ingeniería de requisitos es

hacer que los mismos alcancen un estado óptimo

antes de alcanzar la fase de diseño en el

proyecto. Los buenos requisitos deben ser

medibles, comprobables, sin ambigüedades o

contradicciones, etc.

1.2.1. Implicaciones

Los Requisitos implica todas las actividades del ciclo de vida dedicadas a:

La educción (a veces llamada "elicitación", debido a una mala

traducción de "elicitation") de los requisitos de usuario.

http://es.wikipedia.org/wiki/Requisito_%28sistemas%29




DE SISTEMAS

El análisis y negociación de requisitos para derivar requisitos

adicionales.

La documentación de los requisitos como especificación.

La validación de los requisitos documentados contra las

necesidades de usuario.

Así como los procesos que apoyan estas actividades.

1.2.2. Fases de Implementación

Desde un punto de vista conceptual, las actividades son de cinco clases.

Obtener requisitos: a través de entrevistas o comunicación con clientes o

futuros usuarios, para saber cuáles son sus expectativas.

Analizar requisitos: detectar y corregir las carencias o falencias comunicativas,

transformando los requisitos obtenidos de entrevistas y requisitos, en

condiciones apropiadas para ser tratados en el diseño.

Documentar requisitos: igual que todas las etapas, los requisitos deben estar

debidamente documentados.

Verificar los requisitos: consiste en comprobar el correcto funcionamiento de

un requisito en la aplicación.

Validar los requisitos: comprobar

que los requisitos implementados se

corresponden con lo que inicialmente

se pretendía.

1.2.3. Técnicas Principales

1. Entrevistas

Las entrevistas son un método común. Por lo

general no se entrevista a toda la gente que se

relacionará con el sistema, sino a una selección

de personas que represente a todos los

sectores críticos de la organización, con el

énfasis puesto en los sectores más afectados o

que harán un uso más frecuente del nuevo

sistema.




DE SISTEMAS

2. Talleres

Existen dos técnicas de este tipo que son las más utilizadas: Brainstorming (Lluvia de

ideas) y JAD (Joint Application Development, Diseño de Aplicación Conjunta). La

diferencia que existe entre ambas técnicas es que

durante la tormenta de ideas se tiene como

objetivo generar una gran cantidad de ideas, es

desestructurada y la información que se obtiene

puede ser visual, textual o coloquial; mientras que

en el JAD el taller es ordenado, la información

que se obtiene es visual y su objetivo es generar

requisitos y la interfaz del sistema

3. Forma de Contrato

En lugar de una entrevista, se pueden llenar formularios o contratos indicando los

requisitos. En sistemas muy complejos éstos pueden tener centenares de páginas.

4. Objetivos Medibles

Los requisitos formulados por los usuarios se toman como objetivos generales, a

largo plazo, y en cambio se los debe analizar una y otra vez desde el punto de

vista del sistema hasta determinar los objetivos críticos del funcionamiento

interno que luego darán forma a los comportamientos apreciables por el usuario.

Luego, se establecen formas de medir el progreso en la construcción, para

evaluar en cualquier momento qué tan avanzado se encuentra el proyecto

5. Prototipos y Caso de Uso

Un prototipo es una pequeña muestra, de funcionalidad limitada, de cómo sería el

producto final una vez terminado. Ayudan a conocer la opinión de los usuarios y

rectificar algunos aspectos antes de llegar al producto terminado.

Un caso de uso es una técnica para documentar

posibles requisitos, graficando la relación del

sistema con los usuarios u otros sistemas. Dado

que el propio sistema aparece como una caja

negra, y sólo se representa su interacción con

entidades externas, permite omitir dichos

aspectos y determinar los que realmente

corresponden a las entidades externas. El

objetivo de esta práctica es mejorar la

comunicación entre los usuarios y los

desarrolladores, mediante la prueba temprana de

http://es.wikipedia.org/wiki/Lluvia_de_ideas

http://es.wikipedia.org/wiki/Lluvia_de_ideas




DE SISTEMAS

prototipos para minimizar cambios hacia el final del proyecto y reducir los costes finales.

1.2.4. Especificación de Requisitos del Software

Una especificación de requisitos del software es una descripción completa del

comportamiento del sistema a desarrollar. Incluye un conjunto de casos de uso que

describen todas las interacciones que se prevén que los usuarios tendrán con el

software.

Los requisitos se dividen en tres:

Funcionales: son los que el usuario necesita que efectúe el software. Ej:

el sistema debe emitir un comprobante al asentar la entrega de

mercadería.

No funcionales: son los "recursos" para que trabaje el sistema de

información (redes, tecnología). Ej: el soporte de almacenamiento a usar

debe ser MySQL.

Empresariales u Organizacionales: son el marco contextual en el cual

se implantará el sistema para conseguir un objetivo macro. Ej: abaratar

costos de expedición.

1.2.5. Identificación de las personas involucradas

Debido a que los cambios que introduce un sistema nuevo tienden a afectar a más de

un tipo de usuario, los analistas de requisitos han de tomar en consideración a todos los

implicados para que se obtengan y depuren sus requisitos de la forma más adecuada

posible. Entre las personas implicadas hay que considerar:

Organizaciones que integran la organización del analista que está

diseñando el sistema

Organizaciones o sistemas

de respaldo

Dirección

Usuarios




DE SISTEMAS

1.2.6. Problemas

a) Relacionados con las personas involucradas

Las vías que pueden dificultar la determinación de los requisitos son:

Los usuarios no tienen claro lo que desean

Los usuarios no se involucran en la elaboración de requisitos escritos

Los usuarios insisten en nuevos requisitos después de que el coste y la

programación se hayan fijado.

La comunicación con los usuarios es lenta

Los usuarios no participan en revisiones o son incapaces de hacerlo.

Los usuarios no comprenden los problemas técnicos

Los usuarios no entienden el proceso del desarrollo

b) Relacionados con los analistas

La correcta redacción de las Especificaciones de requisitos del Software es

imprescindible para el correcto desarrollo del proyecto. Por ello, en su redacción hay

que evitar:

Uso de terminología ambigua en la redacción de los documentos de

requisitos

Sobre especificación de los requisitos

Escritura poco legible, voz pasiva, abuso de negaciones

Uso de verbos en condicional, expresiones subjetivas

Ausencia de términos y verbos del dominio de la aplicación

c) Relacionados con los desarrolladores

Los problemas posibles causados por los desarrolladores durante análisis de requisitos

son:

El personal técnico y los usuarios finales pueden tener diversos vocabularios y

pueden llegar a creer incorrectamente que están de acuerdo, no dándose cuenta

del desacuerdo hasta que se provee el producto final.

Los desarrolladores pueden intentar encajar el sistema en un modelo existente,

en vez de desarrollar un sistema adaptado a las necesidades del cliente.

El análisis de requisitos se puede realizar a menudo por los ingenieros o

programadores, en vez de personal con las habilidades de relación con la gente

y el conocimiento apropiados para entender las necesidades de un cliente

correctamente.




DE SISTEMAS

1.2.7. Soluciones Aplicadas

Una solución aplicada en los problemas de comunicaciones ha sido emplear a

especialistas en análisis del negocio o del sistema.

Las técnicas introducidas en los años 90 tienden al uso de prototipos, lenguaje unificado

de modelado, casos de uso, y el desarrollo ágil de software.

Otros tipos de herramientas aplicadas para salvar las diferencias entre los usuarios y las

organizaciones de tecnología de la información y que permiten la comprobación de las

aplicaciones son:

Pizarras electrónicas para bosquejar los algoritmos y para probar

alternativas

Capacidad de capturar la lógica del negocio y los datos necesarios

Capacidad de generar los prototipos que imitan fielmente el producto final

Interactividad

La capacidad para agregar requisitos contextuales y otro comentarios

Capacidad para que usuarios remotos y distribuidos operen con el

prototipo

Por último, se requieren herramientas que permitan medir, de forma objetiva, la calidad

de una especificación de requisitos.




DE SISTEMAS

ORGANIZACIÓN DEL PROYECTO

Organizar es crear una estructura de relación y después controlar que se cumpla y

funcione, para que se consiga el objetivo deseado.

Se muestran 3 objetivos específicos que deberían cumplirse en la fase de dirección y

gestión de la ejecución de un proyecto:

Lograr la mejor calidad técnica de las instalaciones, alcanzando su mayor

relación de valor.

Mantener los costes de

materialización del proyecto

dentro de los márgenes

establecidos por el presupuesto

disponible, dentro de la calidad

ya definida.

Cumplir con el cronograma de

ejecución de actividades,

haciendo posible la partida de los

programas de puesta en marcha

en los plazos establecidos.

La siguiente tarea consiste en definir e

implementar el esquema organizacional

que nos permita alcanzar en la forma

más eficiente posible los objetivos de

nuestro proyecto.

1. Definición de la organización del proyecto

La identificación y análisis de los factores relevantes para la organización del proyecto,

corresponderá a 5 agrupaciones o categorías interrelacionadas entre sí, ellas son:

Participación de los directivos y su equipo en la organización del proyecto en

general

Relación con la organización permanente de la empresa




DE SISTEMAS

Características propias del proyecto en cuestión

Análisis de fortalezas, debilidades y participación de terceros

Costes incrementales o marginales

2. Soluciones organizacionales

Con las técnicas de desarrollo organizacional que existen en la actualidad, no hay una

estructura óptima para todo tipo de proyectos, solamente existen mejores y peores

soluciones, dependiendo de cada situación en particular.

La relación entre el proyecto y la

organización en el cuál éste se ejecuta

dependerá de factores como:

Tamaño del proyecto

Impacto en el medio ambiente

Tipo de cliente (interno o

externo)

Cultura

Complejidad

Recursos disponibles

Modalidad contractual

Circunstancias

Otros factores relevantes

Ventajas de la organización por proyectos

El administrador del proyecto tiene total responsabilidad y un mayor grado de autoridad

sobre el proyecto.

Se acortan las líneas de comunicación, mejorando la coordinación y tiempo de

respuesta al cliente.

Proyectos repetitivos aumentan

la eficiencia y capacidades de

los especialistas.

Mayor nivel de compromiso y

motivación.

Existe unidad de mando (un

solo jefe).

Es simple y flexible, lo que

facilita su comprensión e

implementación.

Mejora la dirección integrada

del proyecto.




DE SISTEMAS

Desventajas de la organización por proyectos

Varios proyectos simultáneos implican un aumento considerable de recursos

(básicos y especializados).

Necesidad de asegurar la disponibilidad de recursos críticos, incrementa los

costes.

Difícil acceso a la base tecnológica de las áreas

funcionales cuando se requieren soluciones que

escapan al conocimiento de los especialistas.

Tendencias a no respetar los procedimientos y

políticas generales de la organización.

Tendencia a una fuerte división entre el equipo

del proyecto y el resto de la organización.

Incertidumbre respecto al futuro de las personas

una vez terminado el proyecto.

¿Dónde aplicarlo?

En una organización que se relacionan con proyectos de empresas nuevas y se desea

a toda costa el control de la ejecución con el fin de ganar el Know-how, o impulsar el

desarrollo de proyectos con tecnologías nuevas y complejas. Una organización puede

contratar a terceros los trabajos de ingeniería, servicios de materiales o compras y la

ejecución de la obra. Sin embargo, rara vez traspasará la responsabilidad de

actividades eminentemente controladoras o bien de dirección, con dotaciones reducidas

en actividades como la contabilidad o el manejo financiero, por razones obvias.

Roles en proyectos

Los miembros de tu equipo podrán adoptar dos tipos de roles en tus proyectos,

asimismo:

Los Administradores del proyecto pueden gestionar las preferencias del

proyecto, invitar a nuevos usuarios, eliminar usuarios existentes y también

elementos.

Los Participantes del proyecto tienen todos los permisos de colaboración pero

no pueden eliminar ni contenidos ni usuarios.

Tanto administradores como participantes pueden

instalar la herramienta Helpdesk para el proyecto

siguiendo las instrucciones que se encuentran en

Configuración. También pueden comprobar la dirección

de correo electrónico para gestionar tareas y

conversaciones a vía email.




DE SISTEMAS

Definir roles de usuario a medida que se invitan usuarios al proyecto.

Puedes invitar a tus compañeros desde un proyecto. Teambox no permite invitar a

nuevos usuarios a todos los proyectos de una organización por el momento, tendrás

que seleccionar cada uno de los proyectos a los que quieras invitarlos y decidir si

quieres invitarlos también a la organización (de modo que puedan crear nuevos

proyectos) o que participen en los como colaboradores externos.

Define los roles de cada usuario

Selecciona la primera opción si quieres que sean Administradores del proyecto.

Selecciona la segunda opción si quieres añadirlos también a la organización

como participantes. Si no seleccionas esta opción, continuarán como usuarios

externos de la organización (incluso si son administradores de un proyecto

perteneciente a la misma).

Selecciona la tercera opción para nombrarlos Administradores de la

organización.

Siempre puedes administrar los roles para proyectos específicos en la sección de

preferencias del proyecto.

Como administrador de proyecto puedes cambiar los roles de tus compañeros de

equipo así como borrar a otros miembros en la sección Gente y Permisos.




DE SISTEMAS

La Organización de los proyectos es una forma de trabajar de una manera eficacia y

con arduo trabajo para un exitoso proyecto. No se trata solo de trabajar bien sino

de tener un proyecto de calidad de acuerdo a la necesidad del cliente. Su

implantación supone una garantía tanto para la administración que, en la mayoría

de los casos es una de las principales formas efectivas para la organización en

ámbitos diferentes.

La satisfacción de las necesidades y expectativas del cliente constituye el elemento

más importante de la gestión de la calidad y la base del éxito de una empresa. Por

este motivo es imprescindible tener perfectamente el concepto de satisfacción de

sus clientes desarrollando sistemas de medición de satisfacción del cliente y

creando modelos de respuesta inmediata ante la posible insatisfacción a todo

servicio siempre se le debe estar incrementando continuamente un valor agregado.




DE SISTEMAS

http://www.monografias.com/trabajos12/pmbok/pmbok2.shtml

http://es.wikipedia.org/wiki/Ingenier%C3%ADa_de_requisitos

http://www.slideshare.net/cotorrito/roles-y-funciones-12849484

http://tesis.uson.mx/digital/tesis/docs/681/Capitulo4.pdf

http://fido.palermo.edu/servicios_dyc/proyectograduacion/archivos/564.pdf

https://sites.google.com/site/ivangarciasanchez90/objetivos/gestion-tema-5/1o

http://ocw.unican.es/ensenanzas-tecnicas/organizacion-y-gestion-del-proyecto/material-de-

clase-2/L1.pdf

http://www.monografias.com/trabajos12/pmbok/pmbok2.shtml

http://es.wikipedia.org/wiki/Ingenier%C3%ADa_de_requisitos

http://www.slideshare.net/cotorrito/roles-y-funciones-12849484

http://tesis.uson.mx/digital/tesis/docs/681/Capitulo4.pdf

http://fido.palermo.edu/servicios_dyc/proyectograduacion/archivos/564.pdf

https://sites.google.com/site/ivangarciasanchez90/objetivos/gestion-tema-5/1o

http://ocw.unican.es/ensenanzas-tecnicas/organizacion-y-gestion-del-proyecto/material-de-clase-2/L1.pdf

http://ocw.unican.es/ensenanzas-tecnicas/organizacion-y-gestion-del-proyecto/material-de-clase-2/L1.pdf

Education

Contratos y requisitos organizacion del proyecto, roles(o)