Apuntes para INGENIERIA DE SOFTWARE I FACTORES HUMANOS EN INGENIERIA DE SOFTWARE Basado en Software Engineering, de Ian Sommerville

R. Contreras A. - M. A. Pinningho J. Ingenier a Civil Inform atica Segundo Semestre 2013

1.

Introducci on
El estudio de los factores humanos es importante por varias razones: 1. Para ser efectivos los administradores de software deben entender su equipo como individuos, y entender como estos individuos interact uan. Un mejor entendimiento de sus caracter sticas sicol ogicas relevantes ayuda a los administradores a entender las limitaciones humanas y a adecuarse de manera de no intentar llevar a cabo proyectos software irrealizables. 2. Los sistemas de computaci on son usados por personas. Si las capacidades y limitaciones de estas personas no son tomadas en cuenta al dise nar sistemas, seguramente no ser an usadas de la mejor forma posible. 3. La productividad del programador (en su sentido amplio) es un factor cr tico de costo en ingenier a de software. El entendimiento de factores humanos puede ayudar a identicar posibles formas de incrementar la productividad.

2.

Diversidad Humana

El desarrollo de software es una tarea individual, creativa. Es, en alg un sentido, comparable con componer m usica, dise nar edicios y escribir libros. Aunque un ingeniero de software puede trabajar formando parte de un equipo, el equipo s olo es necesario porque el sistema de software requerido es tan grande que no puede ser producido por una sola persona en una cantidad razonable de tiempo. Los sic ologos han identicado un n umero de rasgos de personalidad tales como asertivo/hosco, conado/suspicaz, etc, y han desarrollado tests para permitir la clasicaci on de las personas de acuerdo a esos rasgos. Usando un test de personalidad desarrollado para medir aptitud laboral, Perry y Cannon produjeron un perl de programador. Sin embargo, el perl ideal se obtuvo por matching con los perles de los programadores experimentados, sin referencia a sus habilidades de forma que esta simple elecci on puede bien ser no representativa. La selecci on de ingenieros de software en base a la personalidad puede ser una mala decisi on por varias razones: - La personalidad es din amica, no est atica. La personalidad cambia en el curso de una carrera profesional. - Diferentes personalidades pueden resultar adecuadas a diferentes aspectos de la programaci on, tales como dise no, testing y otras. - Los programadores inteligentes que completan sus tests de personalidad pueden hacer trampas, llenando los formularios, no con los datos reales, sino con aquellos que ellos creen podr an presentar una personalidad m as adecuada al trabajo. Por otra parte, esta caracter stica puede resultar de mucha utilidad en un equipo de desarrollo de software. Es posible que no se pueda identicar una personalidad particular para la buena programaci on, pero lo que si es claro, es que la ausencia de ciertos atributos podr a indicar una personalidad no apta para el trabajo en el area de ingenier a de software. Un ejemplo, es la capacidad de lidiar con una cierta dosis de stress. La naturaleza de los proyectos software es tal, que los plazos imponen una carga considerable al desarrollador, carga que se va incrementando en la medida en 2

que las fechas clave de control se acercan. Esto lleva normalmente a estados de desesperaci on, que aumentan el atraso de los trabajos, generando en la pr actica un c rculo vicioso. Otra caracter stica importante es la capacidad de adaptaci on. La velocidad de cambio, tanto en software como en hardware, es tal que el ingeniero de software debe ser capaz de incorporar los cambios tecnol ogicos y metodol ogicos que permitan evitar la obsolescencia.

3.
3.1.

Procesamiento del Conocimiento

Organizaci on de la memoria

Los sistemas de software son entidades abstractas y los ingenieros deben recordar sus caracter sticas durante el proceso de desarrollo. Los desarrolladores deben entender y recordar las relaciones entre un listado de c odigo fuente y el comportamiento din amico del programa y aplicar este conocimiento almacenado en el desarrollo de futuros programas. La retenci on de informaci on en la memoria depende de la estructura de la memoria. Parece haber tres a reas, jer arquicamente conectadas: Memoria de corta duraci on, capacidad limitada, acceso veloz. La entrada desde los sentidos es recibida aqu para su procesamiento inicial. Esta memoria es comparable con los registros en un computador; es usada para procesar la informaci on y no para almacenarla. Memoria de Trabajo, una mayor capacidad. Esta area de memoria tiene un tiempo de acceso mayor que la memoria de corta duraci on. Es usada para procesar la informaci on, pero puede retener informaci on por per odos m as largos que la memoria de corta duraci on. No es usada para almacenar informaci on por tiempos muy prolongados. Por analog a con el computador, es como el almacenamiento vol atil, donde la informaci on es mantenida mientras dura su procesamiento. Memoria de larga duraci on. Esta memoria tiene una mayor capacidad, un acceso relativamente lento y mecanismos no conables de recuperaci on de informaci on (olvidamos algunas cosas). Esta memoria es usada para almacenar informaci on en forma permanente. Para continuar con la analog a, esta memoria es como la memoria en el disco de un computador. 3

De los sentidos Memoria de corta duracin

Memoria sde trabajo

Memoria de larga duracin (gran capacidad, acceso lento)

Figura 1: Organizaci on de la memoria La informaci on problema es recibida en la memoria de corta duraci on y es integrada con informaci on existente relevante de la memoria de larga duraci on, en la memoria de trabajo. El resultado de esta integraci on es la base para la resoluci on de problemas, que puede almacenarse, nuevamente, en la memoria de larga duraci on para uso posterior. No obstante, informaci on obsoleta, o incluso incorrecta, no es totalmente descartada, de forma de ayudar a prevenir la repetici on de los mismos errores. El tama no limitado de la memoria de corta duraci on restringe nuestro proceso cognitivo. En un experimento cl asico, se encontr o que la memoria de corta duraci on puede almacenar alrededor de 7 quanta de informaci on. Un quantum de informaci on no es un n umero jo de bits; puede ser un n umero telef onico, una funci on o el nombre de una calle. Al proceso de agrupar los quanta de informaci on, se le denomina chunking. Si un problema involucra la entrada de m as informaci on de la que la memoria de corta duraci on puede manejar, debe existir un proceso de transferencia (y procesamiento) de la informaci on durante la entrada. Esto puede resultar en p erdida de informaci on y errores a causa de la imposibilidad de capturar toda la informaci on de entrada. Este es un problema particular cuando se procesa nueva informaci on.

Loop (para el arreglo completo) Loop (procesa la parte no ordenada) Compara elementos adyacentes Intercambia si es necesario

Figura 2: Chunking del Bubblesort Por ejemplo, si se nos presentan dibujos de animales comunes, estos pueden ser procesados r apidamente, porque son conocidos desde la infancia. Por otra parte, si se nos presenta la descripci on de un componente de software nuevo (desconocido), toma mucho m as tiempo desentra nar su signicado. Se cree que el proceso de chunking es usado para entender programas. Al leer un programa, abstraemos la informaci on en chunks los que son construidos en una estructura sem antica interna que representa al programa. Los programas no son entendidos sentencia a sentencia, a menos que las sentencias representen un chunk l ogico. La Figura 2 muestra como un simple programa bubblesort puede ser capturado (chunked) por un lector. Una vez que la estructura sem antica interna, que representa el programa, ha sido establecida, este conocimiento es transferido a la memoria de larga duraci on y normalmente no es olvidada; puede ser reproducida en diferentes notaciones sin gran dicultad. Por ejemplo, consideremos la b usqueda binaria, donde una colecci on ordenada es examinada en la b usqueda de un elemento particular. Esto involucra examinar el punto medio de la colecci on y usar el conocimiento almacenado relativo a las relaciones de orden para chequear si el elemento clave est a en la parte superior o inferior de la colecci on. Un programador que entiende este algoritmo, puede producir versiones del mismo en Ada, C++, Pascal o cualquier otro lenguaje que conozca. Lo obvio es que la informaci on que el programador ha retenido no est a en la forma de descripci on de un programa ya que, si nada m as est a disponible, el puede producir una versi on en lenguaje natural del modelo algor tmico. 5

3.2.

Modelamiento del Conocimiento

Cuando la informaci on es introducida en la memoria de corta duraci on y procesada para su almacenamiento en la memoria de larga duraci on, lo que estamos almacenando realmente son abstracciones que hemos acordado en denominar conocimiento. Aunque la distinci on entre informaci on y conocimiento no es r gida, podemos decir que la informaci on (la antigua, combinada con la nueva) es utilizada para crear conocimiento. El conocimiento adquirido durante el desarrollo de software, y que es almacenado en la memoria de larga duraci on, puede clasicarse en dos categor as: (1) Conocimiento Sem antico. Este es el conocimiento de los conceptos tales como la operaci on de un comando de atribuci on, la noci on de una lista encadenada y en qu e consiste una t ecnica de hash. Este conocimiento es capturado a trav es de la experiencia y el aprendizaje, y es retenido con independencia de su representaci on. (2) Conocimiento Sint actico. Este es el conocimiento del detalle representacional, tal como escribir correctamente una declaraci on de procedure en Pascal, cu ales son las funciones est andar disponibles en un lenguaje de programaci on, o si la asignaci on se escribe := o =, etc. Este conocimiento parece ser retenido de una forma mucho m as cercana a su utilizaci on (en t erminos de su representaci on). El conocimiento sem antico, parece ser capturado por medio de la experiencia y a trav es del aprendizaje activo, donde informaci on nueva es integrada de manera consciente con las estructuras sem anticas existentes. El conocimiento sint actico, por otra parte, parece ser capturado m as por memorizaci on. Las diferentes formas de capturar conocimiento sint actico y sem antico explican la situaci on t pica que tiene lugar cuando programadores experimentados aprenden un nuevo lenguaje. Normalmente, ellos no tienen dicultad con los conceptos tales como atribuci on, loops, sentencias condicionales y otras. La sintaxis del lenguaje, sin embargo, tiende a mezclarse con la sintaxis de lenguajes familiares. Por ejemplo, un programador Fortran que aprende Pascal puede escribir el operador de atribuci on como =, en vez de :=; un programador de Pascal podr a escribir type x = ... en vez de type 6

x is ... cuando est a aprendiendo Ada. Cuando aprenden a programar, los principiantes deben manejarse tanto en la sem antica implicada en el modelo computacional, como en una sintaxis arbitraria. Es dif cil para ellos distinguir entre problemas sem anticos y sint acticos y realizar la integraci on de conocimiento para crear los conceptos sem anticos apropiados. Quienes han comprendido y procesado exitosamente la informaci on sem antica pueden encontrar dif cil de explicar estos conceptos sem anticos en t erminos que los programadores principiantes puedan entender. Este modelo explica el por qu e, para muchas personas, aprender a programar es una habilidad que parece haberse dado de una sola vez, despu es de un per odo de dicultades. La programaci on es entendida cuando los conceptos sem anticos y sint acticos han sido separados y los conceptos sem anticos han sido comprendidos.

3.3.

Implicaciones Pr acticas

Ingenieros de software pragm aticos est an interesados principalmente en c omo el proceso cognitivo afecta el dise no, desarrollo y administraci on del software. El ingeniero de software debe entender el problema, encontrar una estrategia de soluci on y traducirla en un programa. La primera etapa implica llevar la denici on del problema desde la memoria de corta duraci on a la memoria de trabajo. Luego es integrada con conocimiento existente en la memoria de larga duraci on y analizada para encontrar una soluci on general. Finalmente la soluci on general es renada en un programa ejecutable (ver Figura 3). El desarrollo de la soluci on (el programa) involucra la construcci on de un modelo sem antico interno del problema y un modelo de soluci on correspondiente. Cuando este modelo ha sido construido, puede ser representado en cualquier notaci on sint actica apropiada. Un programador experimentado que conoce varios lenguajes de programaci on, tendr a aproximadamente la misma dicultad al escribir un programa, con independencia del lenguaje escogido. El proceso de soluci on de problemas es independiente del lenguaje, y el virtuosismo con un lenguaje particular no es garant a de habilidades de programaci on. Por otra parte, la traducci on desde un modelo de soluci on a un progra7

Problema

Soluciones Parciales

Solucin

Conocimiento nuevo Conocimiento previo

Memoria de Trabajo

Memoria de larga duracin

Figura 3: Esquema de soluci on de problemas ma contendr a menos errores si las facilidades sint acticas de la notaci on est an de acuerdo con las estructuras sem anticas (de menor nivel) usadas. Aunque esto puede variar de un individuo a otro, actualmente las t ecnicas de programaci on enfatizan la atribuci on, los comandos condicionales, los ciclos while y las declaraciones de tipo como el nivel conceptual m as bajo. Un lenguaje de programaci on deber a representar estas abstracciones directamente. Es bueno recordar que la memoria de corta duraci on es de capacidad limitada, que la informaci on es codicada en chunks y que el conocimiento sint actico y sem antico es almacenado. Si un programa debe ser revisado en forma top-down, las abstracciones involucradas en la formaci on de chunks pueden realizarse secuencialmente, sin referencias a otras partes del programa. La memoria de corta duraci on puede dedicarse a una sola secci on de c odigo. No es necesario mantener informaci on sobre varias secciones conectadas por sentencias go to arbitrarias. La idea de la Programaci on Estructurada, es una buena estrategia para dise nar la estructura de control de un programa, ya que no sobrecarga la memoria de corta duraci on; as los programas son m as f aciles de entender y contienen menos errores.

Actividades no productivas 20% Interaccin Trabajo individual 30% 50%

Figura 4: Distribuci on del tiempo de un ingeniero de software

4.

Trabajo Grupal

La imagen popular de la gente de computaci on, es que trabajan como individuos atisbando en terminales o sobre monta nas de papel cubiertos con s mbolos estramb oticos. Por otra parte, la gente de computaci on no tiene una idea muy diferente, sintiendo adem as una necesidad m nima de trabajar con otras personas. De hecho, en la realidad, la mayor a de los ingenieros de software trabaja en equipos cuyo tama no var a desde 2 hasta varios cientos de personas. Un estudio realizado hace algunos a nos por IBM muestra la proporci on de tiempo gastada en diferentes actividades (ver Figura 4). Una comprensi on de la din amica del grupo ayudar a a los administradores de software y a los ingenieros a trabajar en equipo. Los administradores se enfrentan con la dif cil tarea de formar grupos. Deben asegurarse que en el grupo exista un balance entre habilidades t ecnicas, experiencia y en t erminos de personalidades. Se pueden obtener mejores resultados si hay una comprensi on sobre el c omo se producen las interacciones entre los miembros del grupo.

4.1.

Personalidades en grupos

Hay ocasiones en que miembros de un equipo de trabajo pueden trabajar de muy buena manera juntos, y hay otras ocasiones en que pr acticamente ninguna productividad es posible por el exceso de conictos. Intentaremos bosquejar el por qu e las personalidades entran en conicto y c omo puede lograrse un trabajo arm onico. Muy supercialmente, los individuos en una situaci on de trabajo pueden clasicarse en tres tipos: (1) Orientados al trabajo. Este tipo est a motivado por el trabajo mismo. En ingenier a de software, son t ecnicos motivados por el desaf o intelectual del desarrollo de software. (2) Auto-orientados. Este tipo est a motivado principalmente por el exito personal. Est an interesados en el desarrrollo de software como un medio para alcanzar sus propias metas. El alcanzar estas metas puede hacerlos desplazarse desde la parte t ecnica a la parte administrativa. (3) Orientados a la interacci on. Este tipo de personas es motivado por la presencia y acci on de colegas. Hasta hace poco, probablemente no hab a este tipo de personas involucradas en el desarrollo de software a causa de la aparente falta de interacci on humana involucrada en el proceso. Sin embargo, eso ha cambiado en los u ltimos a nos. La motivaci on de cada individuo est a constituida por elementos de cada una de las clases mencionadas, pero un tipo de motivaci on es normalmente el dominante. Sin embargo, las personalidades no son est aticas y los individuos pueden cambiar. Por ejemplo, aquellos t ecnicos que no creen estar siendo recompensados adecuadamente pueden llegar a transformarse de orientadosal-trabajo en auto-orientados. Las personas orientadas al trabajo se describen a si mismas como autosucientes, creativas, solitarias, introvertidas, agresivas, competitivas e independientes. Los orientados a la interacci on se consideran a si mismos como no agresivos, con baja necesidad de autonom a, considerados y serviciales. Preeren trabajar en grupo antes de hacerlo solos. Los individuos auto-orientados se describe a si mismos como desagrad10

ables, dogm aticos, agresivos, competitivos, introvertidos y celosos. Preeren trabajar solos. Los hombres tienden a ser orientados al trabajo, pero las mujeres tienden a ser m as orientadas a la interacci on. No est a claro si esto es un estereotipo o una tendencia natural. Cuando los individuos trabajan en grupos compuestos exclusivamente por miembros pertenecientes a la misma clase de personalidad, s olo el grupo compuesto por personas orientadas a la interacci on ha tenido exito. En los otros dos casos se da una sobrepoblaci on de l deres. Esto sugiere que los grupos m as exitosos ser an aquellos compuestos por individuos de distintas clases, con un l der de grupo orientado al trabajo. La mayor a de los ingenieros de software son, probablemente, orientados al trabajo, motivados principalmente por su trabajo. Por otra parte, los administradores deben ser cuidadosos, ya que una selecci on de individuos con personalidades complementarias puede producir un mejor grupo de trabajo que un grupo seleccionado exclusivamente de acuerdo a su capacidad t ecnica.

4.2.

Programaci on sin ego

La programaci on sin ego, es un estilo de trabajo de un grupo de proyecto, que considera que los programas son de propiedad com un y responsabilidad del grupo completo, independientemente del miembro del grupo que lo gener o. Esta noci on no se restringe s olo a programas; puede ser generalizada para incluir todo el software, incluyendo especicaciones, dise nos y documentaci on del usuario. Weinberg recomienda esta forma de trabajo porque hace de los programas un producto del grupo y no de esfuerzos individuales. Su argumento se basa en la teor a de disonancia cognitiva. Esta teor a argumenta que los individuos que tienen un conjunto de creencias o toman alguna decisi on particular, evitan cualquier cosa que contradiga esas creencias o su decisi on. Por ejemplo, los adherentes de un partido pol tico normalmente pondr an atenci on s olo a los discursos de los miembros de su propio partido. Usuarios de computadores de cierta marca, leer an art culos que argumentan las bondades de ese computador, evitando la lectura de material que pudiera sugerir que otras m aquinas son superiores. Los programadores que se sienten responsables por un programa, tienden a defender su programa de las cr ticas, a un si hay dicultades obvias: el 11

ego del programador est a amarrado a su programa. Si, por otra parte los programadores consideran su trabajo como propiedad del grupo, estar an m as llanos a permitir que otras personan inspeccionen los programas, a aceptar cr ticas y a trabajar en grupo para mejorar el programa.

4.3.

Liderazgo del grupo

El trabajo de un l der de grupo puede (normalmente lo hace) incidir en el exito o fracaso de un proyecto de software. Si bien es cierto la mayor a de los grupos tiene un l der titular (o administrador de proyecto) designado por la administraci on superior, no es menos cierto que ese individuo puede no ser el l der real del grupo en lo que a liderazgo t ecnico se reere. Si es el caso, y dado que la competencia t ecnica y la competencia administrativa no son sin onimos, los roles mencionados pueden ser complementarios. El l der real en un grupo de desarrollo de software es el miembro que tiene m as inuencia sobre los otros miembros. Esta inuencia puede ser el resultado de una gran capacidad t ecnica, status individual o a causa de una personalidad dominante. El l der, adem as, puede ir cambiando en cada etapa de un proyecto debido a la competencia o experiencia en etapas particulares. Debe ser el miembro mejor calicado el que tome el control de cada etapa del desarrollo. Si, como tambi en ocurre, se impone un l der, esto s olo va a introducir tensi on en el grupo. Los miembros pueden no respetar al l der impuesto y pueden volverse contra el grupo, priorizando objetivos individuales. Esto es un gran problema en un campo como la ingenier a de software, donde nuevos miembros pueden estar m as actualizados y mejor formados que l deres experimentados. Una importante implicaci on de esto es que los individuos no deben ser promovidos de la labor de programaci on. Una estructura de carrera diferente es lo que necesitan estas personas. O sea, los individuos t ecnicamente capaces deben ser recompensados debidamente, pero permanecer ligados a la actividad de desarrollo de software (esta estructura ha sido creada por IBM y otras organizaciones en lo que se conoce como chief programmer teams).

12

4.4.

Lealtad del grupo

Los miembros de un grupo bien liderado son leales al grupo; los miembros del grupo se identican con las metas del grupo y con otros miembros del grupo. Tratan de proteger al grupo, como una entidad, de la interferencia externa. La lealtad del grupo implica que hay una coherencia en la toma de decisiones y una aceptaci on universal de las decisiones. Los miembros del grupo piensan que el grupo es m as importante que los individuos. Si hay un fuerte sentido de grupo, cambios eventuales de miembros pueden ser acomodados con facilidad. El grupo puede adaptarse a circunstancias cambiantes en los requerimientos del software, suministrando apoyo mutuo, por ejemplo. No obstante, hay dos desventajas importantes: - Resistencia de los miembros del grupo a cambios de liderazgo, y - P erdida de facultades de cr tica, a causa de que la lealtad al grupo est a por sobre cualquier otra consideraci on Si el l der de un grupo altamente cohesionado debe ser reemplazado, y el nuevo l der no es un miembro del grupo, los miembros existentes del grupo pueden formar una coalici on contra ese nuevo jefe. Este puede intentar revertir la situaci on alterando las metas globales del grupo, y el grupo puede reaccionar resistiendo los cambios, lo que lleva a una p erdida de tiempo que nalmente se traducir a en una baja productividad. La mejor manera de evitar esta situaci on es elegir l deres que ya pertenezcan al grupo. La otra consecuencia negativa se denomina groupthink. Groupthink es el estado en el cual las facultades de cr tica del grupo est an sobrepasadas por las lealtades al grupo. La consideraci on de alternativas es reemplazada por el apego a las normas del grupo y a sus decisiones. Cualquier propuesta apoyada por la mayor a del grupo puede ser adoptada sin una adecuada consideraci on de alternativas. Esto ocurre con mayor frecuencia bajo condiciones de stress, lo que es particularmente grave, ya que es en ese momento cuando se necesita de las decisiones m as razonadas.

13

4.5.

Interacci on del grupo

La comunicaci on al interior de un grupo es esencial (s olo basta imaginar su efecto en la programaci on sin ego mencionada); pero, esta comunicaci on tambi en puede ocurrir a causa de una pobre organizaci on grupal o a la existencia de documentaci on inadecuada. La comunicaci on grupal improductiva debe ser minimizada. Mientras m as comunicaciones est en involucradas en un grupo, m as dif cil ser a su administraci on. Consecuentemente, cuando la norma es un gran n umero de comunicaciones interpersonales, los errores ocurren con mayor frecuencia. La comunicaci on efectiva entre los miembros de un grupo de desarrollo de software es vital si el grupo debe trabajar ecientemente. Algunos de los factores m as importantes que atentan contra la efectividad de las comunicaciones intra-grupo incluyen: - El tama no del grupo. - La estructura del grupo. - El status y personalidad de los miembros del grupo. - El ambiente f sico de trabajo del grupo. A medida que el tama no del grupo aumenta, el n umero de potenciales comunicaciones entre individuos tambi en crece, en proporci on al cuadrado del tama no del grupo. El n umero de potenciales enlaces de comunicaci on en un grupo de n miembros es n (n 1). Las comunicaciones en un grupo pueden estar inuenciadas por el status, personalidad y sexo de los miembros del grupo. A veces es mejor organizar las comunicaciones informalmente. Conversaciones informales compartiendo un caf e o viajando juntos pueden resultar en ocasiones excelentes puentes de intercambio de informaci on. Comunicaciones m as formales pueden estructurarse ya sea con topolog a de estrella o de red. En la organizaci on estrella, el grupo est a estructurado de forma tal que las comunicaciones pasan a trav es de un coordinador central. Es este quien decide a quien se enviar a determinada informaci on (ver Figura 14

Organizacin estrella

Organizacin red

Figura 5: Patrones de comunicaci on grupal 5). En la organizaci on tipo red, los documentos producidos por los miembros del grupo llegan a todos los otros miembros. Esta alternativa parece ser un poco mejor, ya que las personas que componen un grupo preeren trabajar en grupos altamente cohesionados. La alternativa de estrella parece ser adecuada para tareas simples como recolecci on y reparto de informaci on.

5.

Ergonom a

El lugar de trabajo tiene importantes efectos en el comportamiento de las personas. Experimentos sicol ogicos han mostrado que el comportamiento es afectado por el tama no de la ocina, el mobiliario, el equipamiento, la temperatura, la humedad, el brillo y la calidad de la luz, el ruido y el grado de privacidad. En un estudio de los ambientes laborales, se encontr o que las arquitecturas de plano abierto (ambiente compartido), utilizadas en muchas partes, no eran ni populares ni productivas. Los factores m as importantes identicados en ese estudio fueron: (1) Privacidad. Es necesaria un area donde el desarrollador pueda concentrarse y trabajar sin interrupciones.

15

Sala de Reuniones

Oficina Area comn Oficina

Oficina

Oficina

Oficina

Oficina

Oficina

Oficina

Figura 6: Distribuci on de espacio (2) Visi on exterior. La gente preere trabajar en un ambiente de luz natural y con visi on del entorno exterior. (3) Personalizaci on. Los individuos adoptan diferentes pr acticas laborales y tienen opiniones diferentes sobre la decoraci on. La capacidad de reordenar el lugar de trabajo para personalizar el ambiente es importante. La Figura 6, muestra una proposici on de distribuci on del espacio laboral.

16