Contratos y requisitos organizacion del proyecto, roles(o)

GESTION DE PROYECTO SOFTWARE

ICA – PERU
2013

LOS CONTRATOS Y LOS REQUISITOS
LA ORGANIZACIÓN DEL PROYECTO LOS ROLES

ELIAS PALLIN, FABIOLA
MISAICO PALOMINO, CHRISTIAN
QUINTEROS TUMBA, EDUARDO

INGENIERIA DE SISTEMAS
CICLO VIII – S1
DISEÑO E IMPLEMENTACION
DE SISTEMAS

1


2

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

3


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

4

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

5

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

6


1.1.1.3.
I.

II.

III.

Salidas de la Administración de Contratos

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.
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.
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

7


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.

DE SISTEMAS

8

 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

9

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
DE SISTEMAS

10

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

11


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

12


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

13


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

14

 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

15


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

16


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

17


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

18


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-declase-2/L1.pdf

DE SISTEMAS

19

Contratos y requisitos organizacion del proyecto, roles(o)

Recomendados

Mais conteúdo relacionado

Mais procurados

Mais procurados (20)

Destaque

Destaque (10)

Semelhante a Contratos y requisitos organizacion del proyecto, roles(o)

Semelhante a Contratos y requisitos organizacion del proyecto, roles(o) (20)

Mais de León Leon

Mais de León Leon (20)

Último

Último (20)

Contratos y requisitos organizacion del proyecto, roles(o)