1

PROPUESTA METODOLGICA PARA DETERMINAR EL SERVICIO DESEADO Y LAS CONDICIONES DE PRESTACIN EN UN PROYECTO.
Luz Moreno-Martn(p)(1)(2)(6), Olga Cap-Iturrieta(2)(3), Santos Gracia-Villar(2)(4), Christian Estay-Niculcar(4)(5) (1) Universidad de los Andes. Mrida, Venezuela. (2) Universidad Politcnica de Catalua. Departamento de Proyectos de Ingeniera. Barcelona, Espaa. (3) Instituto de Investigaciones Agropecuarias INIA. Santiago, Chile. (4) Fundacin Universitaria Iberoamericana FUNIBER. Barcelona, Espaa. (5) Universidad Santa Mara. Guayaquil, Ecuador. (6) Con el apoyo del Programa Alan, Programa de becas de alto nivel de la Unin Europea para Amrica Latina, n de identificacin E03D05438VE. SUMMARY A methodology proposal is presented in this paper, its allows to determinate the desired service and conditions as well, making easier and systematic the solution to process the huge information collected by the designer to propose an appropriate technical answer to the conflict that give origin to the project development. The methodology was obtained from projects analysis presented by the UPC engineering students using the Blasco methodology. RESUMEN Se presenta una propuesta metodolgica para determinar tanto el servicio deseado como las condiciones de prestacin en el diseo de un proyecto, y as facilitar de manera sistemtica el problema al que se enfrenta el proyectista, que es el procesar gran cantidad de informacin recopilada para proponer una respuesta tcnica apropiada al conflicto que ha motivado la ejecucin del proyecto. Dicha metodologa se obtuvo a partir del anlisis de los proyectos presentados por los alumnos de la carrera de ingeniera de la UPC usando la metodologa Blasco. 1. SERVICIO

Un servicio en el mbito de los proyectos se define, como la relacin o convenio entre un sistema ofertante que proporciona unas salidas, y un sistema receptor que las admite como entradas [Blasco, 2002], lo que se esquematiza en la siguiente figura:

Sistema ofertante del servicio

Servicio Objeto

Sistema solicitante del servicio

Medio ambiente Figura 1. El Servicio a prestar.

769

Los sistemas artificiales se inventan y construyen por unas personas, o sistema ofertante del servicio, para conseguir, directa o indirectamente, unas mejoras individuales y colectivas, del sistema solicitante. Esta intencionalidad se refleja en el servicio a conseguir y en el objetivo inmediato del proyecto [Blasco, 2002]. La operacin proyecto responde a la actividad de proyectar un sistema artificial y real que tiene por finalidad conseguir el sistema artificial y real proyectado, en cuyas consecucin se hace uso de unos sistemas mentales que son unos significantes que lo tienen por referente. Y en la operacin proyecto, hay que [Blasco, 2002]: Definir el objetivo o sea la solucin que se busca al problema. Planificar las formas y manera de conseguir la resolucin. Llevar a cabo con xito la consecucin.

Para llevar a cabo el primer paso es indispensable que se definan claramente el servicio prestado por el sistema, sus restricciones, constricciones y las condiciones de prestacin, as como las personas involucradas en dicho sistema. Esta resolucin del conflicto se puede resumir en cuatro hitos: 1. Hallar un cambio que suprima el conflicto y un objeto que desencadene el cambio. 2. Hallar un sistema que pueda proporcionar el objeto. 3. Definir el servicio a suministrar por el sistema. 4. Construir un sistema que proporcione el servicio. Para que una relacin de servicio tenga xito, la transferencia, se debe ofrecer en determinadas condiciones propias del sistema ofertante y se debe aceptar bajo determinadas condiciones propias del sistema receptor. Y las condiciones del sistema ofertante han de ser compatibles con las del sistema receptor. En otras palabras, la causa y motivo de un proyecto reside en la prestacin de un servicio a un sistema solicitante de forma que le resuelvan los conflictos que presenta. El servicio deseado por el usuario ser el beneficio que espera este obtener del sistema artificial, el cual se puede concentrar en el mundo biolgico, fsico, ergonmico y social. Y para realizar la descripcin predictiva del servicio deseado por los usuarios que son relevantes para el xito del proyecto, tanto el sistema solicitante como el ofertante debe responder detallada y concienzudamente las siguientes preguntas [Blasco, 1988]: A quin. Qu y para qu. Por qu. Cmo. Dnde y cuando. A qu coste.

770

2.

DESCRIPCIN DEL SERVICIO A CONSEGUIR

Cada usuario relevante valorar un servicio de diferente manera dependiendo de muchas variables [Blasco, 1988]. Dependiendo de la naturaleza de la aportacin: se puede valorar por su contenido, calidad, cantidad y alcance del suministro. Dependiendo de la oportunidad de la utilizacin: se puede valorar por su lugar, momento, confianza, riesgos y peligros. Dependiendo de su coste econmico. Dependiendo de su contraprestaciones y molestias.

A pesar de esto, se debe determinar las prestaciones del suministro material con detalle racionalizado y cuantificable de las principales magnitudes o funciones componentes, y sus rangos de valores, mediante la determinacin de lo que se espera del servicio. 2.1. Naturaleza del servicio

Se entiende por Naturaleza del Servicio a una descripcin en lenguaje tcnico de las prestaciones del suministro, con detalle y cuantificadas, o con un rango de valores posibles. 2.2. Exigencias respecto a la forma y manera de suministro

Para cada usuario relevante, se debe ser capaz de definir los requisitos del suministro de manera predictiva, y cuantitativa referente a: a) b) c) d) 2.3. Disponibilidad espacial (lugar) Disponibilidad temporal (tiempo) Seguridad del servicio Continuidad el servicio

Finalidad y causalidad del servicio

La finalidad del servicio, como Sistema Solucin global, se puede explicar desde tres aspectos diferentes y complementarios. En primer lugar sealar el para qu se est creando este servicio, es decir, debe ser el obtener una solucin del problema que crea el conflicto y motiva la ejecucin del proyecto, siempre con el enfoque de una solucin para el usuario. En segundo lugar, aclarar por qu este servicio es el ms conveniente para dar solucin a dicho problema, cul ser su utilidad. Y finalmente, el cmo, es decir una especificacin clara de la forma y el modo en que el servicio descrito cumplir su objetivo.

771

2.4.

Recopilacin de requisitos

Es necesario describir claramente y en lenguaje tcnico los requisitos, analizando las solicitudes de cada usuario relevante para hacer una recopilacin de requisitos compatible y factible, dejando claro cuales son los requisitos particulares de los usuarios que s quedarn incluidos y los que quedarn fuera del diseo final. Es conveniente, cuando se trata de muchos los requisitos (y usuarios) en anlisis, seguir ayudndose por tablas de doble entrada (matrices) para explicitar estos requisitos. De igual modo conviene agrupar los que son similares para un mejor anlisis y para tener una visin ms estructurada del sistema solucin. 2.5. Constricciones restrictivas del servicio

El servicio que recibir el sistema receptor, estar limitado por unas series de constricciones propias, sobre el suministro y suministracin, que son ajenas a los usuarios, que repercuten sobre las prestaciones, y hay que tener presente en el planteamiento y en la resolucin del problema tcnico.
Expectativas del sistema receptor Alrededores Servicio Disponibilidad del sistema ofertante

Modo

Lugar

Tiempo

Figura 2. Constricciones del Servicio

3. METODOLOGIA PARA LA DETERMINACION DE LOS REQUISITOS DEL SISTEMA SOLUCION El sistematizar un procedimiento para llegar a determinar cules son los requisitos factibles de implementar en el Sistema Solucin, lleva consigo muchas dificultades, puesto que los proyectos son de muy diversa ndole, y el anlisis debe realizarse tanto para su fase de construccin como de explotacin y retiro, es decir, considerando todo el ciclo de vida del proyecto. Tambin es relevante en este anlisis considerar cul es el tipo de Proyecto, si es un servicio, un producto o un proyecto industrial. A continuacin se presenta en forma simplificada y esquematizada algunos pasos que permitirn estructurar la informacin, para que, cualquiera sea el caso, se pueda llegar a una conclusin que indique la mejor forma de realizar el Proyecto La metodologa consta de algunas tablas y matrices de doble entrada, que permitirn al proyectista ir vaciando y organizando toda la informacin que recopile

772

acerca de las condiciones que son deseadas y/o restringen al proyecto, siguiendo el orden siguiente: 3.1. Usuarios Relevantes

El primer paso de la metodologa lo definen los usuarios relevantes del sistema, que son las personas involucradas en la resolucin del conflicto.
Usuarios relevantes Posicin en el Sistema Externos Tipo Consumidores Explotadores Internos Operadores Propietarios Ajenos al sistema Terceros USUARIO

TABLA 1. Usuarios Relevantes

3.2.

Deseos de Servicio

El segundo paso es que para cada usuario se analizan todos los deseos que tienen respecto del sistema que se construir. Para esto se deben tener en consideracin todos los deseos de todos los usuarios, los mismos usuarios que ya fueron definidos en el apartado anterior.
DESEOS DE SERVICIO SEGN LOS USUARIOS USUARIO Naturaleza Forma y manera Presiones Finalidad y Causalidad

TABLA 2. Deseos de Servicio segn los Usuarios

3.3.

Recopilacin de Requisitos

El tercer paso es hacer un listado de requisitos. La forma de hacerlo es tomar la columna naturaleza de la tabla 2 y clasificar cada requisito que all se haya descrito en un rea temtica que permita ir agrupando deseos, que aunque sean de usuarios distintos su naturaleza es la misma. Esto permitir un mejor anlisis de la informacin.
REQUISITOS DEL SERVICIO SEGN LOS USUARIOS rea Temtica Requisitos Valores Seguimiento Comentarios

TABLA 3. Recopilacin de los Requisitos del Servicio segn los Usuarios

773

Para que esta transformacin de la tabla 2 a la 3 sea ms sistemtica, la clave est en agrupar los deseos que se repiten, ordenarlos segn las reas que se elijan, ordenarlos y finalmente redactarlos bien y de forma coherente. Una buena redaccin ser siempre en positivo, lo que debe ser no lo que no debe ser. Esta recopilacin de requisitos es un proceso iterativo de aproximaciones sucesivas, es un anlisis que permite identificar los deseos que pudiesen estar duplicados, para escribirlos slo una vez, esto requiere revisar ambas tablas reiteradas veces para llegar a un listado final de requisitos. Finalizado este proceso, y cuando se tenga un listado de requisitos bien estructurado y bien redactado, se tomara como una tabla de slo una columna que se utilizar ms adelante y que se llamar A, por ahora para diferenciarla, y que tan solo para clarificar se muestra en la tabla 4.
REQUISITOS Requisitos 1. Requisitos 2. Requisitos n. TABLA 4. Tabla A, REQUISITOS

3.4.

Constricciones y Restricciones del Servicio

Se deber analizar tanto las constricciones y restricciones de los alrededores y las constricciones y restricciones tecnolgicas. stas debern ser analizadas desde la perspectiva del Suministro y la Suministracin.
Constricciones y Restricciones de los Alrededores mbito Constriccin Criterio Mercado Sociales Legales Econmicas Ecolgicas Ergonoma, seguridad e higiene Alrededores inmediatos Etc. TABLA 5: Constricciones y Restricciones de los Alrededores Constricciones y Restricciones Tecnolgicas Constriccin Variables Comentarios Constrictor

TABLA 6: Constricciones y Restricciones Tecnolgicas

Una vez que se tengan las dos tablas anteriores (tabla 5 y tabla 6), se realizar una tabla resumen de Constricciones que sume tanto las de los alrededores como las tecnolgicas. Se esquematiza en la tabla 7 y se llamar B.
774

RESTRICCIONES Restriccin 1. Restriccin n. TABLA 7: Tabla B, RESTRICCIONES

3.5.

Anlisis de compatibilidad entre los requisitos de los usuarios

Requisito 1 Requisito 2 Requisito 3

REQUISITOS (A) (A) REQUISITOS Requisito 1

Requisito n TABLA 8: Anlisis de compatibilidad entre los Requisitos de los Usuarios (A/A)

En esta matriz se comparan los mismos valores en ambos ejes por lo tanto basta con llenar un tringulo base de informacin En esta matriz, se pondr en cada celda una sobre compatibilidad: I = Requisitos (deseos) independientes o muy poco relacionados C = Requisitos (deseos) complementarios O = Requisitos (deseos) opuestos y discordantes en todo o en parte Lo que se clasifique como C significa que las mejoras y empeoramientos en la consecucin son concordantes y van emparejadas. Las calificaciones I y C son aplicables a requisitos compatibles entre s, sin embargo una calificacin O significa la incompatibilidad, por lo tanto la necesidad de optar por uno u otro. 3.6. Anlisis de interferencias entre los requisitos y las restricciones
Restriccin 1 Restriccin 2 Restriccin 3 Restriccin n
775

CONSTRICCIONES (B) (A) REQUISITOS Requisito 1 ..

Requisito n TABLA 9: Anlisis de interferencia entre los requisitos y las restricciones (A/B)

Con este anlisis ser posible delimitar lo que es posible hacer y lo que no, con el proyecto. Aqu se ver cules son los requisitos que se cumplen y con cuales restricciones se enmarcan. Tambin es posible enumerar los requisitos que no son posibles de cumplir. Tambin es posible concluir que no se puede hacer de determinada forma por causa de una restriccin imposible de cumplir.

Requisito n

3.7.

Conclusiones sobre el servicio deseado y las condiciones de prestacin

En resumen, se tiene una serie de deseos asociados a personas, y otras constricciones tcnicas, como asociadas a un marco legal, social, administrativo, etc. Con la ayuda de ellas se puede llegar a unas determinadas conclusiones acerca del servicio deseado y las condiciones de prestacin, como lo indica la siguiente figura.

Figura 3. Conclusiones del Proyecto a partir de los deseos, constricciones y restricciones.

Esta metodologa fue obtenida y validada por medio de los ejercicios que los alumnos de la carrera de ingeniera de la UPC han realizado usando la metodologa Blasco. Se tomaron casos exitosos en que los alumnos pudieron llegar a conclusiones acertadas. De este modo se encontr que era posible procesar la informacin recopilada desde los usuarios del proyecto a tablas, con un cierto orden y con una serie de pasos que permiten concluir, luego de aproximaciones sucesivas, la mejor manera de realizar un proyecto. BIBLIOGRAFIA
Blasco, J. Comentarios al Proyecto (De Omni Re Scibili) 1 Edicin. Ediciones UPC. Barcelona, Espaa. 1988. Blasco, J. Introduccin al Proyecto. Presentacin dinmica por ordenador. UPC. Barcelona, Espaa 1988. Blasco, J. Los Artefactos y sus Proyectos. 1 Edicin. Ediciones UPC. Barcelona, Espaa. 2000. Blasco, J. Los Proyectos de Sistemas Artificiales: El Proyectar y lo Proyectado. 1 Edicin. Ediciones UPC. Barcelona, Espaa. 2002. Estay-Niculcar, C. and J. Blasco. El Universo de Proyectos: una Epistemologa Sistmica para Proyectos. V Congreso Internacional de Ingeniera de Proyectos. Lrida, Espaa. 2000.

CORRESPONDENCIA. Luz Moreno Martn Departamento de Proyectos de Ingeniera, UPC. Diagonal 647, planta 10, 08028, Barcelona, Espaa. stellaluzm@yahoo.es

776