1.1 Introduccion Se trata de un libro acerca de la gestin, con nfasis en la gestin del diseo, el desarrollo, y la ingeniera de sistemas.

Se aborda dos cuestiones principales: 1. Qu dice la Gerente de Proyectos (PM) necesito saber? 2. Qu significa el Ingeniero Jefe de Sistemas (CSE) necesita saber? La atencin se centra tanto en los aspectos esenciales de lo que el PM y el CSE debe dominar con el fin de tener xito en la construccin de varios tipos de sistemas y la gestin los equipos de proyecto. Este captulo es en gran parte introductoria, que trata de las definiciones preliminares de los sistemas y proyectos, los problemas encontrados en los sistemas de construccin, los sistemas de enfoque, las responsabilidades de gestin de claves y cuestiones de organizacin que impactan significativamente la forma en que se han previsto sistemas, diseados y construida. 1.2 SYSTEMS AND PROJECTS Hay muchas definiciones de sistemas, una de ellas es simplemente que'' un sistema es cualquier proceso que convierte las entradas a las salidas'' [1,1]. Estamos aqu, en los sistemas de por ejemplo y, a tal efecto, comenzar por examinar un sistema de radar. es sin duda un sistema, la realizacin de las funciones de bsqueda y seguimiento de objetos en el espacio, como en una va de aire o de radar de vigilancia en o cerca de un aeropuerto. sistema normalmente tiene funciones que lleva a cabo (por ejemplo, bsqueda y seguimiento) , y lo hace por medio de sus subsistemas . Al mismo tiempo , tales aeropuerto los sistemas de radar , junto con otros sistemas (por ejemplo, las comunicaciones y el aterrizaje sistemas) , son parte de un sistema ms amplio conocido como control de trfico areo (ATC ) sistema . Examinado desde la perspectiva de un sistema de control del trfico areo, la sistemas de radar en realidad sirven como subsistemas del sistema ms grande. En el mismo vena , el sistema de control del trfico areo puede ser considerado como un subsistema de un mayor sistema aeronutico nacional ( NAS ) , que consiste tambin de los aeropuertos , vehculos areos y otros sistemas relativamente grandes ( por ejemplo, acceso / salida) en su propio derecho . Nuestra vista de los sistemas , por lo tanto , es ms bien amplia . En el contexto anterior , los radares , control de trfico areo y el sistema nacional de aviacin son todos los sistemas. Tales sistemas normalmente se componen de hardware, software , y los elementos humanos , todos los cuales deben interoperar de manera eficiente para el sistema global sea efectiva . Adoptamos esta amplia perspectiva en la definicin de los sistemas , la elaboracin en ejemplos que afectan a nuestra vida cotidiana , tales como los sistemas de automviles , sistemas de telefona , sistemas informticos, sistemas de calefaccin y refrigeracin , trnsito sistemas, y sistemas de informacin . Los proyectos son empresas formales que aborden la cuestin de diseo y el desarrollo de los distintos sistemas que acabamos de citar . Un proyecto es un conjunto de personas y equipo, y es administrado normalmente por un Gerente de Proyecto ( PM ) .

El personal del proyecto trabajan para satisfacer un conjunto de metas, objetivos y requisitos, segn lo establecido por el cliente. Los proyectos tambin pueden tener un alcance limitado de trabajo , que trata slo con , por ejemplo , la fase de diseo de un sistema , en lugar de su construccin o ciclo de vida. El xito de un sistema depende en las habilidades de las personas en un proyecto y lo bien que son capaces de trabajar juntos. En ltima instancia , el xito o la falta de ella , se atribuye a las muchas habilidades que el PM es capaz de llevar a tener en lo que es a menudo un extremadamente complejo situacin y esfuerzo. El primer ministro , en definitiva, no slo debe tener un considerable habilidades tcnicas , sino que tambin deben tener un profundo conocimiento del arte de gestin .
1.2.1 Definitions of Systems Engineering

El Ingeniero Jefe de Sistemas (CSE), normalmente reporta al Gerente de Proyecto y se centra en la construccin del sistema de que se trate. El proceso general que emplea el CSE se conoce como Ingeniera de Sistemas, un tema central en este texto. Vamos a definir Ingeniera de Sistemas en trminos de complejidad creciente y el detalle en varias partes de este libro, comenzando aqu con cinco relativamente simple expresiones, a saber: 1. Elaborado por el Consejo Internacional de Ingeniera de Sistemas (INCOSE) 2. Como articluated por el Departamento de Defensa (DoD) 3. Como se representa en un texto anterior de este autor 4. Segn el resumen de la Defense Systems Management College (CMSD) 5. Como se ve por la Administracin Nacional de Aeronutica y del Espacio (NASA) La definicin INCOSE es que la Ingeniera de Sistemas es [1,2]: Un enfoque interdisciplinario y los medios que la realizacin de xito sistemas. Esta definicin es ms bien escasa y hace hincapi en tres aspectos:'' interdisciplinario'' '' realizacin,'' y'' xito''. Especialmente para sistemas a gran escala, es claramente necesario emplear varias disciplinas (por ejemplo, la ingeniera humana, la fsica, la ingeniera de software y gestin). Realizacin simplemente confirma el hecho de que los procesos de ingeniera de sistemas conducen a la construccin fsica de un sistema de la vida real (es decir, que va ms all de la formulacin de una idea o concepto). Por ltimo, nuestra expectativa es que mediante la utilizacin de las diversas disciplinas de la ingeniera de sistemas, el resultado ser un sistema exitoso, aunque esto resultado es, sin duda no est garantizada. Una definicin proporcionada por el Departamento de Defensa (DoD), un partidario fuerte

as como usuarios de la ingeniera de sistemas como una disciplina fundamental, es que Ingeniera de Sistemas [1,3]: Implica el diseo y gestin de un sistema completo que incluye hardware y de software, as como otros elementos del ciclo de vida del sistema. La ingeniera de sistemas proceso es un esfuerzo tcnico estructurado, disciplinado y documentado a travs que los productos y procesos de los sistemas son al mismo tiempo definidos, desarrollados e integrado. Ingeniera de Sistemas se implementa ms eficaz en el marco de un esfuerzo de desarrollo de productos y procesos integrada global utilizando multidisiplinary trabajo en equipo. Palabras clave de esta definicin son:'' el diseo y la gestin,'''' hardware y software,'''' estructurado, disciplinado y documentado,'' y'' general esfuerzo'''' integrado que implica el trabajo en equipo multidisciplinario.'' Estos importantes nociones se reiterarn y ampliarn en partes posteriores de este libro. Una tercera definicin, formulada por este autor, es que la Ingeniera de Sistemas es un [1,4]: Proceso iterativo de la sntesis de arriba hacia abajo, el desarrollo y operacin de un mundo real sistema que satisface, de una manera casi ptima, toda la gama de los requisitos para el sistema. Aqu, las ideas principales tienen que ver con'' iterativo,'''' sntesis'''' operacin'''' nearoptimal'' y'' satifies los requisitos del sistema.'' Diseo y construccin de un sistema implica generalmente varios bucles de iteracin, por ejemplo, de sntesis el anlisis, desde el concepto hasta el desarrollo, y desde architecting detallado diseo. La nocin de sntesis se hizo hincapi, ya que la esencia de los sistemas engineeering se ve desde la perspectiva del diseo en lugar de anlisis. Diseo precede el anlisis, y si no existe un diseo coherente, no hay nada que analizar. El trmino'''' casi ptima sugiere que la ingeniera de sistemas a gran escala no da lugar a un diseo ptimo demostrable, excepto en circunstancias muy especiales circunstancias. Los casos normales implican todos los intentos de encontrar una adecuada equilibrio entre una variedad de caractersticas deseables. Se utilizan los anlisis de trade-off para moverse en la direccin de un mejor diseo posible''''. Por ltimo, en trminos de la definicin bsica, nos encontramos con la necesidad de satisfacer la gama de necesidades de el sistema. El enfoque en la construccin de un sistema que responda a las necesidades del usuario-cliente es fundamental para lo que la ingeniera de sistemas es todo.

El Sistemas texto Management College Defensa resume Ingeniera de Sistemas como [1,5]: Un proceso de gestin de ingeniera interdisciplinaria para desarrollar y verificar un integrado, el ciclo de vida equilibrado conjunto de soluciones de sistemas que satisfagan las necesidades del cliente. Aqu, las palabras claves enfatizan un proceso de gestin'','''' verificacin,'' a'' equilibrada conjunto de soluciones,'' y'' las necesidades del cliente.'' Esta definicin, por lo tanto, tiende a ver la ingeniera de sistemas a travs de un prisma de gestin'''', requiere una conjunto equilibrado de soluciones, as como la verificacin de las soluciones y la satisfaccin de lo que el cliente establece como un conjunto de necesidades. La ltima definicin citada en este captulo es la representada por la NASA, a saber, que la ingeniera de sistemas es [1,6]: Un slido enfoque para el diseo, la creacin y el funcionamiento de los sistemas. NASA ampla esta breve explicacin, haciendo hincapi en: 1. Identificacin y cuantificacin de los objetivos 2. Creacin de los conceptos de diseo de sistemas alternativos 3. Realizacin de operaciones de diseo 4. Seleccin e implementacin del mejor diseo 5. Verificacin de que el diseo est bien construido e integrado 6. Evaluacin posterior a la ejecucin de lo bien que el sistema cumple con los objetivos declarados Los cinco anteriores definiciones de ingeniera de sistemas, en conjunto, dan nosotros un punto de partida para nuestra futura exploracin de ingeniera de sistemas y la gestin de los mismos. Tambin veremos otras representaciones que tienden a aadir ms detalle y la estructura de estas definiciones de formato corto. Por ejemplo, Captulo 2 cita varias normas que se relacionan con la ingeniera de sistemas. adems1.2 SISTEMAS Y PROYECTOS 7 Captulo 7 define los treinta elementos que este autor considera que son el esencia de la ingeniera de sistemas a gran escala. 1.2.2 Sistema de Costo-Efectividad El equipo del proyecto, dirigido por el primer ministro y el CSE, tambin estn en busca de un rentable solucin para el cliente. Para que este concepto tiene un contenido real, tenemos que estar en condiciones de cuantificar en ltima instancia, tanto el coste del sistema , as como su eficacia. Costo del sistema se puede abordar desde una perspectiva del ciclo de vida. esto significa que con el tiempo se construy un modelo de costos del ciclo de vida (LCCM), con el despus de tres grandes categoras de gastos: 1 . Investigacin, desarrollo, prueba y evaluacin ( RDT & E) 2 . Adquisicin o adquisicin y 3 . Operacin y mantenimiento ( O & M ) La ltima categora, segn nuestra definicin , tambin incluir el costo del sistema de

disposicin cuando es necesario hacerlo. Sistema de costo tambin ser visto como un variable independiente , expresado como costo '' como una variable independiente '' ( CAIV ) . El Departamento de Defensa (DoD ) CAIV ve como una estrategia de '' que implica establecer objetivos agresivos pero realista de costes en la definicin de los requisitos operacionales y la adquisicin y la gestin de los sistemas de defensa logro de estos objetivos '' [ 1,3 ] . Tambin tendr que ser calculada la eficacia del sistema. Una perspectiva sobre efectividad del sistema es que es una funcin de tres factores [ 1,4 ] : 1 . disponibilidad 2 . confianza 3 . capacidad La disponibilidad es a veces llamada la fiabilidad disposicin , mientras que la fiabilidad es la fiabilidad ms convencional que se degrada con el tiempo en el el funcionamiento del sistema . Capacidad tambin se conoce como el rendimiento del sistema . la enfoque adoptado aqu con respecto a la eficacia es algo menos restrictiva , permitiendo que el equipo de la CSE de la flexibilidad para seleccionar las medidas de efectividad que son fundamentales para el diseo del sistema , as como de la especial importancia para el cliente y usuario. Consideraciones de costo-efectividad del sistema pueden por lo tanto ser visualizado como un grfico de la eficacia (ordenada ) conspirado contra costo del ciclo de vida total ( abscisa ) . como por ejemplo , podemos ver que este tipo de grfico implica que varios sistemas se pueden construir , cada uno representando un punto '' '' en esa parcela . Nuestra tarea general como arquitectos y los diseadores de sistemas es encontrar el diseo del punto de que se recomienda 8 SISTEMAS , PROYECTOS Y GESTIN el cliente de entre una serie de posibles soluciones. Esto implica adems que el proceso incluir la exploracin de varias alternativas hasta un se selecciona alternativa preferida . 1.2.3 Errores del sistema En trminos generales , se dice que todos los sistemas a presentar errores fundamentales conocidas como Tipo I y tipo II errores . Estos errores estn relacionados con el campo de la hiptesis prueba mediante el cual los errores se hacen por (a ) rechazar la hiptesis de que es cierto ( Error tipo I ) o ( b ) aceptar una hiptesis falsa ( error tipo II ) . Desde un sistemas de ingeniera perspectiva, una de las principales tareas del equipo de la CSE es reducir

este tipo de errores con el fin de satisfacer los requisitos del sistema . Tres ejemplos de estos errores se discuten brevemente a continuacin. Muchos de nosotros tenemos sistemas de alarma de coche que estn destinados a apagarse cuando una intruso trata de entrar en el coche . No es un error , siempre y cuando la alarma no se apaga cuando se est intentando una entrada forzada (tipo I). Al mismo tiempo, no queremos ser despertado a las 3 de la maana cuando el alarma se dispara desde el coche delante de la casa , sin ningn tipo de intrusin ( Error de tipo II) . En una escala algo mayor , tenemos los sistemas de radar que estn destinados a detectar objetivos a distancias especificadas . Cuando no lo hacen , un error ( Tipo I) se ha cometido . Por otra parte , estos sistemas tambin afirman , de vez al tiempo, que un objetivo est presente cuando no existe tal objetivo. Este ltimo caso ( una Error de tipo II ) se llama una falsa alarma . Estos tipos de errores para un radar de bsqueda se exploran en detalle en los captulos posteriores de este texto. deteccin especfica y las falsas alarmas probabilidades se calculan , y la relacin entre ellos se examina . En una escala an mayor , hemos situaciones presentadas por el aire nacional sistema de transporte . Cuando el sistema no puede llegar a su destino en la hora prevista de llegada ( ETA ) , un error ha sido cometido que todos de nosotros hemos experimentado. Y, si usted est tratando de llegar a Nueva York desde Washington, y terminar en Filadelfia debido al mal tiempo , el sistema est entregando un resultado no deseado . Entender cuando los sistemas son propensos a dejar de hacer lo que se supone hacer, y tambin hacer lo que no se supone que deben hacer , es a menudo un tema central de las actividades de ingeniera de sistemas . Estos, por supuesto , se puede expresar como problemas que deben ser resueltos por el personal directivo y tcnico trabajar en el sistema . Al mismo tiempo , hay muchos problemas que pueden considerar problemas crnicos en la gestin de un proyecto de ingeniera . Una muestra de este tipo de problemas se presentan y discuten en la siguiente seccin . 1.3 PROBLEMAS EN LA GESTIN DE PROYECTOS DE INGENIERA Un artculo en el Washington Post [ 1,7 ] se describe un contrato con la industria la Administracin Federal de Aviacin ( FAA) de los trminos '' fuera de control de con1.3 PROBLEMAS EN LA GESTIN DE PROYECTOS DE INGENIERA 9 tracto '' y'' cmo un buen contrato sale mal . '' Se pas a describir cmo una

'' curar '' carta se remitir al contratista, diciendo que los retrasos '' en un $ 4000 millones contrato para la modernizacin de los equipos utilizados en el control de trfico areo de la nacin sistema fuera inaceptable. '' Aunque esta advertencia se refiri a los retrasos y por lo tanto, podra estar conectada a no conseguir el trabajo hecho en el tiempo, es probable que los retrasos se debieron a problemas de rendimiento y tambin se relacionaron con el coste del programa . En trminos generales , los problemas que surgen en una tpica proyecto por lo general se manifiestan en ltima instancia, en trminos de tres caractersticas principales: 1 . Horario (tiempo) 2 . Costo ( en comparacin con el presupuesto original ) 3 . rendimiento Estos son los tres grandes '' '' de la gestin de proyectos e ingeniera de sistemas gestin . Los proyectos se haba previsto inicialmente para satisfacer los requisitos de rendimiento en el plazo establecido y las limitaciones presupuestarias. Aunque existen muchas razones por qu los proyectos no cumplen estos tres aspectos clave de un desarrollo del sistema [ 1.8 , 1.9, 1.10 ] , varios de los ms tales razones ms comunes son: 1 . Articulacin inadecuada de los requisitos 2 . La mala planificacin 3 . Habilidades tcnicas inadecuadas y la continuidad 4 . La falta de trabajo en equipo 5 . Pobres comunicaciones y la coordinacin 6 . Control insuficiente del progreso 7 . Apoyo corporativo Inferior La siguiente discusin se expande en estas razones para los problemas y la falta de xito. 1.3.1 La articulacin inadecuada de los requisitos Los requisitos para un sistema se definen normalmente por el cliente para la sistema y son a veces referido como '' usuario '' requisitos. Tales sistemas pueden ser completamente nuevo o pueden representar mejoras de los sistemas actuales . especialmente si son nuevos , el cliente a menudo tiene dificultad para expresar estos requisitos de forma completa y coherente , y en trminos que pueden ser utilizado por un desarrollador del sistema . Tambin es el caso que puede ser simplemente demasiado pronto para comprender todos los requisitos del sistema . Requisitos pobres conducen invariablemente a un mal diseo del sistema. Esta situacin sigue siendo un problema si los requisitos no puede ser negociado y modificado por diversos motivos contractuales. Tanto los usuarios

y los desarrolladores se quejan de requisitos , sino de sus propias perspectivas. 10 SISTEMAS , PROYECTOS Y GESTIN Estn de acuerdo en que algo nuevo se tiene que hacer con respecto a cmo los requisitos estn definidos y satisfechos y se han hecho varias propuestas (por ejemplo, la '' modelo '' espiral de desarrollo de software) para mejorar la situacin . flexibilidad se pide en situaciones contractuales que pueden ser bastante formal e inflexible . Los gerentes de proyecto deben tener esto en su lista de posibles reas problemticas . 1.3.2 Planeamiento pobre Proyectos normalmente siguen un plan de proyecto '''' escrito en el inicio de un proyecto. Los ingredientes de tal plan se describen en detalle en el captulo 3 . Estos planes a menudo se bloquea en '' '' como parte de una propuesta y no se puede modificar fcilmente desde el punto de vista del cliente . Debido a la evolucin del sistema son bastante dinmica , la mayora de los planes del proyecto son obsoletas 6 a 12 meses despus de que se han escrito . Por lo tanto, deben actualizarse continuamente para reflejar la comprensin actual y el estado del sistema . comunicaciones Basing y acciones futuras sobre los planes obsoletos o inexistentes pueden llevar a grandes cantidades de problemas. 1.3.3 Habilidades Tcnicas inadecuadas y Continuidad Muchos PMs se quejan de que no son capaces de acceder el personal necesario recursos para ejecutar sus proyectos. En un entorno de empresa, no es obvio la competencia por la mejor gente y algunos proyectos sufren simplemente porque no puede encontrar o contratar a estas personas. Cuando estn en condiciones de contratar desde fuera del empresa , incluso si el nuevo personal son tcnicamente competentes , se necesita tiempo para que puedan subir la curva de aprendizaje en trminos del propio proyecto, as como la cultura corporativa. Otra cara de la moneda es la prdida de la clave tcnica capacidades a otros proyectos '''' ms importantes de una empresa o la posibilidad que varias personas pueden simplemente levantarse e ir a otra empresa . Es de vital importante para un PM para mantener un excelente personal tcnico o de lo contrario se enfrentan a la fuerte posibilidad de rendimiento tcnico insuficiente, lo que tambin mostrar como problemas en el horario y el costo . 1.3.4 La falta de trabajo en equipo Incluso con un grupo de tcnicos buenos , si no funcionan como un equipo, el proyecto est en peligro . Las competencias del Gerente de Proyecto son de suma importancia

aqu, como l o ella debe ser capaz de forjar un espritu de trabajo en equipo y la cooperacin. Los sistemas actuales son muy complejos y requieren interacciones del da a da de la los miembros del proyecto . Si estas interacciones no se producen , o son negativos, el proyecto sufre y pierde terreno . Hay veces , tambin, que un PM debe '' morder la bala '' con un proyecto de persona que no es capaz de formar parte de un equipo, prefiriendo en lugar de aislarse , o actuar con el fin de representar una fuerza de divisin en un esfuerzo de equipo . Esto no debe ser tolerado y no se requiere una accin decisiva para 1.3 PROBLEMAS EN LA GESTIN DE PROYECTOS DE INGENIERA 11 resolver este tipo de problema . Una variedad de temas relacionados con la forma de construir un equipo de produccin se abordan en detalle en el captulo 6 . 1.3.5 pobres comunicaciones y la coordinacin Una de las habilidades clave de un director de proyecto y un lder, es la comunicacin. La comunicacin eficaz es fundamental tanto en el propio proyecto y fuera el proyecto de elementos de apoyo de la empresa (por ejemplo , gestin de la empresa , contabilidad / finanzas , contratos, etc ), as como el cliente. esfuerzos especiales estn obligados a mantener a las personas necesarias continuamente informados sobre lo que est pasando y por qu . Sorpresas , as como datos insuficientes y los tiempos de plomo puede ser mortal en una situacin del proyecto. El personal del proyecto son especialmente sensibles a un PM que no proporciona informacin y retroalimentacin importante. Algunos miembros del personal requiere una cantidad especial de TLC '' '' para que puedan llevar a cabo. Tales son los hechos de la vida en el tratamiento de los proyectos de ingeniera de alta tecnologa. Muchos proyectos fracasan slo por esta razn . Un PM responsable siempre debe ser consciente de la necesidad para la comunicacin y estar dispuesto a dedicar el tiempo necesario para comunicarse y coordinar . 1.3.6 Monitoreo insuficiente de Progreso Por razones que no son particularmente claro , muchos gestores de proyectos arrancan sus proyectos y luego dejar correr '' lazo abierto '' hasta que una revisin crtica del proyecto est prevista . Gestin '' Peters y Waterman caminando alrededor ( MBWA ) '' [ 1.11 ] es algo a tener en cuenta en este sentido. Un buen PM se mantiene en contacto con la gente y progresar cada da , sobre todo por'' caminar

alrededor '' y explorar informalmente cuestiones, problemas y necesidades. incluso altamente personal competente deben controlarse , siempre y cuando se haga en un inobtrusive y de forma til . Por seguimiento cuidadoso y sensible de progreso entre hitos , uno es capaz de mantener el proyecto en marcha y evitar desastres durante la revisin formal del proyecto , cuando la direccin y los clientes son presentar . Esto es especialmente cierto durante los primeros das de un proyecto debido a que uno '' nunca consigue una segunda oportunidad para causar una buena primera impresin. '' consistente y el seguimiento y la retroalimentacin constructiva desde el principio sentar las bases para el xito del proyecto . 1.3.7 Inferior de Apoyo Empresarial Se espera que todas las organizaciones para proporcionar asistencia y apoyo a los proyectos que a menudo son el elemento vital de estas organizaciones. El apoyo debe ser remitidas por el jefe de la PM , as como de las diferentes ayudas designada grupos tales como contabilidad y finanzas, contratos , los grficos , la produccin , la fabricacin, y un surtido de elementos funcionales matriciales (por ejemplo, mecnico diseo, diseo elctrico , ingeniera de software , etc.) Por ejemplo , 12 SISTEMAS , PROYECTOS Y GESTIN Puede esperarse contabilidad / finanzas para proporcionar informes de costos del proyecto a la PM y el equipo del proyecto en forma peridica , como mensual. Si estos informes son tarda o incorrecta la mayor parte del tiempo, el PM est operando en una clara desventaja . El PM no debe permitir que esta situacin contine . A pesar de encontrar soluciones a los apoyos internos inadecuados pueden ser una aventura no trivial , es por lo general vale la pena el tiempo y esfuerzo necesarios para resolver un problema. Sin embargo , incluso un buen PM puede tener que recurrir a los buenos oficios de la gestin de la lnea a hacerlo. En las secciones anteriores presentan slo siete formas en que un proyecto puede ir fuera de pista. Es evidente que hay muchos otros. Si usted es un director de proyecto o sistemas del Ingeniero , tiene sentido para entender estas y otras reas problemticas de manera que usted puede encontrar soluciones antes de que lleven a costar y programar los excesos y rendimiento del sistema insuficientes. Estos problemas claves pueden ser actualizados en trminos de orientacin especfica al Gestor del Proyecto , tal como se describe en el Anexo 1.1 : Anexo 1.1 : Formas seleccionado para el PM para evitar problemas

1 . Revisar y analizar los requisitos de forma continua y en detalle y plantear problemas con los requisitos con su gestin y , en caso necesario, con su cliente. 2 . Preparar el mejor plan de proyecto que pueda y actualizar ese plan , al menos, una vez al trimestre, asegrese de que su plan es concisa y legible por el personal del proyecto. 3 . No acepte intrpretes tcnicas pobres de su proyecto ; insistir en la mejor talento tcnico que cumple con los ms altos estndares de desempeo y creatividad. 4 . Construir un equipo de respuesta de alta energa que es capaz de comunicarse libremente y resolver los problemas del proyecto , el personal de descarga que han demostrado ser incorregibles jugadores nonteam . 5 . Mantener un alto nivel de comunicacin y coordinacin abierta y honesta con su jefe , otras personas de la empresa, el personal del proyecto y la cliente . 6 . Monitorear el estado del proyecto y el progreso a travs MBWA informal , siendo sensibles a los hbitos de trabajo y las necesidades de su gente , establecer ms formales revisiones peridicas de estado . 7 . Establecer mecanismos de apoyo eficientes y productivos dentro de su empresa o de la organizacin a fin de maximizar la eficacia de estas interacciones ; insistir en un alto nivel de rendimiento de apoyo organizaciones . La mayora de las agencias del gobierno desarrollar sistemas y por lo tanto han estado luchando con estos tipos de problemas durante mucho tiempo . A menudo se tratan , por lo tanto , proporcionar orientacin interna y tambin a los contratistas en cuanto a temas y prob1.4 El enfoque de sistemas 13 blemas que se han enfrentado en el pasado . Por ejemplo , la Administracin Nacional de Aeronutica y del Espacio ( NASA) ha sido la construccin de sistemas de alta tecnologa desde su inicio y trat de evitar problemas con la publicacin de un documento titulado Cuestiones en el Programa de la NASA y de Gestin de Proyectos [ 1,12 ] . Los contenidos de este documento son los siguientes : 1 . Una visin general del ciclo de los proyectos 2 . ( SE & I) Gestin de Ingeniera de Sistemas e Integracin para Tripulados Espacio Programas vuelo 3 . Experiencias compartidas de programas y proyecto de la NASA : 1975 4 . Control de costos de Venus Mariner / Mercury '73 5 . El Shuttle: un equilibrio de Diseo y Poltica 6 . Recursos para los administradores de la NASA

Es evidente que la NASA est tratando de aprender de su historia , experiencias y errores y tienen su beneficio contratistas del pasado. Una teora relativamente nueva '''' de hace hincapi en la gestin de la organizacin de aprendizaje '' '' y propone mtodos de asegurar que este tipo de aprendizaje se produce [ 1,13 ] . Aprender de la propia de uno , as errores como de los otros es una razn fundamental de esto, as como otros libros. 1.4 El enfoque de sistemas El enfoque de sistemas '' , '' en los momentos difciles de definir y ejecutar, es bsicamente un reconocimiento de que todos los elementos de un sistema deben interoperar armoniosamente , que , a su vez , requiere un proceso sistemtico y repetible para el diseo , en desarrollo, y la operacin del sistema . La arquitectura de un sistema debe ser sonar , y debe cumplir al menos con todos los requisitos para el sistema en conjunto sucesivamente por el usuario o cliente . Al seguir unos sistemas sistemticos y repetibles '' '' proceso , el desarrollador maximiza las posibilidades de que esto va a ser el caso. Las caractersticas y los resultados de un enfoque de sistemas clave pueden establecerse de la siguiente manera : 1 . Seguir un proceso sistemtico y repetible . 2 . Hacer hincapi en las operaciones del sistema de interoperabilidad y armoniosas . 3 . Proporcionar una solucin costo -efectiva para el problema del cliente . 4 . Asegurar la consideracin de alternativas . 5 . Usar iteraciones como un medio de refinamiento y de convergencia . 6 . Satisfacer todas las necesidades de los clientes y usuarios . 7 . Crear un sistema robusto Figura 1.1 proporciona una visin general de un enfoque de sistemas , los elementos de que se citan brevemente en lo que sigue : 14 Requisitos del proyecto plan funcional diseo de alternativas anlisis de alternativas Preferred sistema arquitectura evaluacin criterios iteracin

iteracin iteracin no no s s satisface requisitos ? anlisis de alternativas Compensacin estudios Preferred subsistema diseos subsistemas / construye Subsistema / construir integracin Subsistema / construir prueba sistema prueba y evaluacin rENTABLE sistema fsico satisface requisitos ? subsistema diseo Hardware Software Human Hardware Software Human cliente / usuario 12 7 8

34 9 10 5 6 11 12 13 14 15 16 17 arquitectura diseo subsistema diseo sistema construccin Figura 1.1 . Informacin general sobre el enfoque de sistemas . 1.4 El enfoque de sistemas 15 Cuadro 1: Requisitos . Los requisitos para el sistema son definidos por el cliente y el usuario y convertirse en la piedra de toque de todo el diseo y el desarrollo esfuerzos . Estos se consideran inviolable a menos que una negociacin conduce a los cambios que deben reflejarse en todos los documentos contractuales. Requerimientos se proporcionan normalmente en unos requisitos formales '' '' documento. A veces , un documento derivado de llama es una especificacin remitidas por el cliente . La especificacin , sin embargo , es a menudo escrito por el desarrollador. Cuadro 2: Plan del proyecto . El PM es capaz de desarrollar un plan de proyecto de la exposicin de las necesidades . Se trata de un plan de trabajo (que se examinan en el Captulo 3 ) para los aspectos importantes del proyecto . Si los miembros clave de la equipo del proyecto ha sido seleccionado, van a trabajar con la PM con el fin para desarrollar el plan. Si no, se tienen que comprar en ltima instancia en el plan como definido por la PM , o modificar de manera apropiada. Cuadro 3: Diseo funcional de las Alternativas . El diseo arquitectnico de la sistema opera en el nivel funcional , es decir, que se concentra en la funciones que el sistema es para llevar a cabo en distincin a cmo estas funciones son para ser implementado en hardware, software , y componentes humanos . Se configuran varios de estos diseos , cada uno representando un alternativa viable . A menudo , estas alternativas abarcan conceptos que van de bajo costo para un alto rendimiento. Cuadro 4: Anlisis de Alternativas . Cada una de las alternativas que se analiza en trminos de coste , el rendimiento y la satisfaccin de las necesidades . Al interactuar ida y vuelta entre la postulacin de alternativas y su anlisis , es posible determinar en ltima instancia, el cuantitativo y cualitativo

atributos de las distintas alternativas viables . A nivel del sistema , tres y cincuenta y ocho alternativas podran considerarse deseable. Cuadro 5: Criterios de Evaluacin . El anlisis de las alternativas no se pudo llevar sin la clara identificacin de criterios con los que la se evalan alternativas . Estos criterios se derivan de los requisitos y puede incluir caractersticas tales como la interoperabilidad potencial , crecimiento, y riesgo social , as como los elementos de rendimiento detallados listados en el documento de requisitos . Un marco de evaluacin formal es normalmente necesario con el fin de llevar a cabo la evaluacin . Cuadro 6: Arquitectura del Sistema Preferentes. Este paso es la seleccin del sistema arquitectura de nivel que es ms rentable . Se representa una opcin entre las alternativas de la competencia . Muchos proyectos se pierden porque saltar a una arquitectura preferida sin la consideracin explcita de alternativas . Como un ejemplo , esto puede constituir la seleccin de timedivision multiplexacin como preferible a una multiplexacin por divisin de frecuencia enfoque para un sistema de comunicaciones . La arquitectura del sistema es un parte importante del enfoque de sistemas y la ingeniera y el sistema de proceso de diseo y se discuti de nuevo en el captulo 9 . Cuadro 7: Cumple con los requisitos ? Hacemos este paso explcita con el fin de enfatizar la importancia de asegurar que el sistema preferido architec16 SISTEMAS , PROYECTOS Y GESTIN tura cumple con todos los requisitos designados. Aun si un solo obligatoria requisito no se cumple completamente , entonces es necesario volver bucle y considerar alternativas adicionales. Si se cumplen todos los requisitos clave , entonces y slo entonces puede el equipo del proyecto pasar a la cuestin de subsistema diseo . Recuadro 8: Diseo del subsistema . Al conocer la arquitectura preferida en la nivel de sistema , entonces es posible mover en el diseo detallado del subsistema . Estos subsistemas implican la interaccin entre hardware, software , y elementos humanos . Los subsistemas son naturalmente divididos en elementos subordinados , que puede ser llamado builds , elementos de configuracin ( CIs) , componentes, u otros nombres que pueden ser mutuamente entendidas. Cuadro 9: Anlisis de Alternativas . Siguiendo un procedimiento similar al utilizado para desarrollar una arquitectura preferida , las alternativas se exponen y se analizaron a nivel de subsistema de diseo . Esto es crtico porque hay numerosas formas de implementar una funcin determinada . Problemas de sincronizacin y tamao suelen ser importante. Casilla 10: Estudios de compensacin . Una gran variedad de soluciones de compromiso se considera generalmente para tratar de optimizar en el nivel de subsistema . Estos pueden ser

- peso - espacio - rendimiento de energa oficios , tratando de encontrar el correcto equilibrio de atributos . Un bucle de iteracin se muestra explcitamente en la cuenta la posible necesidad de postular subsistema alternativa adicional diseos . Casilla 11: Diseos subsistema preferidos . Flujo diseos subsistema Preferred de los pasos anteriores , que representan opciones casi ptimas con toda la informacin pertinente factores considerados explcitamente en los estudios de trade-off . En esta etapa del proceso, la persona est an a nivel de diseo y el sistema no tiene , hasta ahora, ha construido. Hay algunas excepciones a esto, como ocurre con la nocin de creacin rpida de prototipos de subsistemas con el fin de demostrar cierta RIESGO ALTO crtica partes de un sistema . Casilla 12: Cumple con los requisitos ? Nuevamente queremos hacer explcita la comprobacin de los diseos preferidos del subsistema para asegurar que todos los requisitos se han cumplido. Si no es as, un bucle de iteracin se demuestra que significa que estamos '' volver al tablero de dibujo. '' Si es as , se pasa a la construccin fsica del sistema . Casilla 13 : Subsistemas / Construye . La construccin fsica de los subsistemas ahora est en orden, se producen para el hardware , el software y los componentes humanos , y en consonancia con el diseo del subsistema . Se utiliza Builds aqu como un nombre genrico para los elementos de configuracin , componentes, subsubsystems , y as sucesivamente . Los recursos fsicos de la construccin a travs de la diferentes niveles de escritura de emisin definidos en el proceso de diseo . Casilla 14: Subsistema / Construccin Integracin . Despus de una generacin dada ( o CI ) ha sido construido , debe ser integrado con todas las versiones interoperar (o IC). Esto se lleva a cabo en todos los niveles subordinados del sistema . 1.5 LA ORGANIZACIN DEL PROYECTO 17 Casilla 15 : Subsistema / Build Test. Ensayos fsicos se lleva a cabo como compilaciones ( IC) se integran para asegurar que trabajan juntos, son compatibles, y realizar segn se requiera . Si compilaciones integrados fallan estas pruebas , el proceso es iterado hasta las puntas de prueba del xito. Evidentemente, todos los planes y procedimientos de prueba debe basarse en los requisitos originales o derivado . muchos personas han sugerido , especialmente con respecto al software , que un '' construir un poco, probar un poco de orientacin '' es ms probable que conduzca al xito. Casilla 16: Prueba del Sistema y Evaluacin. Una prueba y evaluacin a nivel de sistema final

(T & E) paso confirma que el sistema cumpla con el desarrollo y la requisitos operacionales . Esto puede ser un paso largo y prolongado , especialmente para los sistemas que se van a operar en un ambiente de campo hostil como a bordo de un buque o aeronave . Se representa un extremo a extremo de verificacin el sistema completo y una comprobacin final de que todos los requisitos han sido conocido. Casilla 17 : Sistema de Fsica rentable . El resultado de todo lo anterior pasos , y muchos subpasos implcitas , es un sistema fsico rentable. Aunque estos pasos representan la mayor parte de los elementos del enfoque de sistemas , hay varios que estn implcitos y por lo tanto se examinan ms adelante captulos. Sin embargo , esta revisin se explican los aspectos clave de este enfoque. Su objetivo es llevar a un sistema que cumple con todos los requisitos y es costo - efectiva y robusta . Estos trminos son examinados en los captulos que tratan con la gestin de ingeniera de sistemas. El director del proyecto y el ingeniero jefe de sistemas son actores clave con claridad para asegurar que se realiza el enfoque de sistemas con la disciplina y la buena sentido . Ahora exploraremos ms formalmente sus funciones y responsabilidades en un entorno corporativo . 1.5 LA ORGANIZACIN DEL PROYECTO Un organigrama ilustrativo para un proyecto se muestra en la Figura 1.2 . este grfico muestra slo el proyecto y no la organizacin en la que el proyecto puede ser incorporado, que se abordar ms adelante en este captulo. El Gerente de Proyecto ( PM ) aparece en la parte superior de la tabla con otros dos jugadores clave, el Ingeniero Jefe de Sistemas (CSE ) y el Controlador de proyectos ( PC ) . En este libro , es altamente recomendable que el jefe de mquinas de un proyecto ser llamado el ingeniero jefe de sistemas , haciendo hincapi en que la principal tarea del jefe ingeniero de sistemas es la integridad de todo el sistema . Algunos organizacional estructuras podran incluir el ingeniero lder como el ingeniero jefe y tener la ingeniero de sistemas y la funcin de la ingeniera de sistemas en paralelo con el otro funciones de ingeniera , tales como ingeniera de hardware y software . Algunos proyectos podra ser ms limitado en su alcance y por lo tanto no requieren algunas de las funciones se muestran. Otros podran de hecho ser ms grandes e incluyen func18 adicional 1.7 1,1 1,2 1,3 1,4 1,5 1,6 1.8 1.9 1.10 1.11

1.1.1 1.2.1 1.1.2 1.1.3 1.1.4 1.2.2 1.2.3 1.2.4 1.4.1 1.4.2 1.4.3 1.4.4 1.3.1 1.3.2 1.3.3 1.5.1 1.5.2 1.5.3 1.6.1 1.6.2 1.6.3 proyecto Manager ( PM ) proyecto Controller ( PC) sistema de Jefe ingeniero (CSE ) Programacin Costeo personal asignaciones comodidades contrato enlace Sistemas ingeniera hardware ingeniera Operaciones Requerimientos Especificaciones sistema evaluacin elctrico diseo mecnico

diseo MMI diseo especialidad ingeniera software ingeniera software diseo codificacin software herramientas / mtodos Pruebas prueba planificacin prueba ejecucin Pruebas apoyar Prueba y evaluacin logstica RMA ILS capacitacin calidad garanta calidad configuracin administracin interfaz controlar Figura 1.2 . Organizacin del proyecto ilustrativa. RMA ? fiabilidad , mantenibilidad , disponibilidad, ILS ? apoyo logstico integrado , MMI ? interfaz hombre- mquina. 1.5 LA ORGANIZACIN DEL PROYECTO 19 ciones tales como manufactura , ingeniera de produccin , instalacin , operacin y de mantenimiento , y otros. Ahora vamos a considerar las responsabilidades especficas del Gerente de Proyecto, Ingeniero de Sistemas Jefe, y el Proyecto de Controller . 1.5.1 Responsabilidades del Gerente de Proyecto ( PM ) Claramente, el Gerente de Proyectos ( PM ) es responsable de la totalidad del proyecto ,

en todas sus dimensiones . En el nivel superior , esta se centra en la programacin , costos y rendimiento tcnico del sistema . Una estimacin del tiempo que un PM podra gastar en cada una de estas caractersticas podra ser 20 % horario , coste 30 % , y 50 % rendimiento, asumiendo que se poda dividir a todas las actividades relacionadas con el trabajo en estas tres categoras . Si se incluyen las actividades puramente administrativas como cuarta categora , los porcentajes pueden ser del 15% previsto, costo 25 %, rendimiento del 35%, y 25 % administrativa . El ltimo punto se incluir la materia como personal de entrevista , la preparacin de sus evaluaciones y deberes similares. Las responsabilidades clsicas de un PM se describen generalmente en trminos de cuatro actividades: ( 1 ) planificacin, ( 2 ) la organizacin, ( 3 ) la direccin , y (4 ) el seguimiento . Algunas personas usan la palabra '''' de control en lugar de esta alternativa de control '' , '' para lo cual se subsume todo el control en la direccin '' '' actividad. La actividad de planificacin es dominante en las primeras etapas de un proyecto , especialmente con respecto a la preparacin coherente de un plan de proyecto . La planificacin de estado estacionario consiste en la actualizacin de este plan y pensar y planear cmo manejar los problemas y contingencias especiales. La responsabilidad de la organizacin consiste en decidir cmo organizar el proyecto en s ( por ejemplo , el grfico de la figura 1.2 ) , y la reorganizacin de cundo y dnde necesario . Tambin significa la asignacin de recursos a las diferentes tareas de el proyecto . Esta aparece como la preparacin de tareas, divisin del trabajo inicial estructuras , matrices de responsabilidad para el proyecto, y similares. La actividad de la direccin es el da a da de funcionamiento formal e informal de la proyecto y sus diferentes reuniones , as como la delimitacin de las asignaciones cuando los cambios o de ajuste se requiere para resolver problemas. La obligacin de monitoreo implica la lectura continua de la situacin de todos los aspectos del proyecto en relacin con los requisitos del sistema y el proyecto plan. Si los resultados del monitoreo en el descubrimiento de problemas , la accin correctiva es adoptada en virtud de la actividad de la direccin. Un factor a menudo frustrante, entra en juego cuando las responsabilidades del PM y la autoridad no son congruentes. Debido a que la PM por lo general tiene la plena responsabilidad para el xito o el fracaso del proyecto , que puede ser muy difcil si esta persona no puede, por ejemplo, contratar o despedir , negociar con proveedores externos y subcontratistas , y hacer los arreglos finales con un cliente contraparte . Autoridad inconmensurable es una de las banderas rojas '' '' de la mayora de los PM . Un resumen

se proporciona la lista de las diferentes responsabilidades y los deberes de un jefe de proyecto en el Anexo 1.2 . 20 SISTEMAS , PROYECTOS Y GESTIN Anexo 1.2 : Funciones y responsabilidades de un PM seleccionadas Costo / Presupuesto Confirmacin de que el proyecto puede ser completado dentro del presupuesto Revisin (por ejemplo, mensualmente) los informes peridicos de costos La obtencin de estimaciones de costo- completos vlidos Evaluar y mitigar los riesgos de costos del proyecto Asegurar la validez de los costes del ciclo de vida del sistema programar El establecimiento de un programa maestro hasta al da Asegurar que se cumplan todos los hitos intermedios Determinacin de formas de hacer que el tiempo cuando se produce el deslizamiento La obtencin de estimaciones de tiempo de completar vlidos Programacin internas y las revisiones al cliente Rendimiento tcnico Asegurarse de que el sistema cumple con todos los requisitos tcnicos Confirmacin de la validez del enfoque tcnico El seguimiento continuo del estado de rendimiento tcnico Instalacin de sistemas y mtodos / prcticas de ingeniera de software Obtencin de las herramientas informticas para sistemas e ingeniera de software administrativo La entrevista personal , contratacin y evaluacin Conexin con la gestin empresarial Conexin con los grupos internos de apoyo al proyecto Desarrollo de Coaching y equipo Asegurar la disponibilidad de servicios requeridos 1.5.2 Responsabilidades del Ingeniero Jefe de Sistemas ( CSE ) Segn lo sugerido por el organigrama de la figura 1.2 , los sistemas del Ingeniero (CSE ) es el gestor de claves de todo el trabajo de ingeniera en el proyecto. Por lo tanto , el CSE es a la vez un contribuyente tcnica, as como un administrador . En efecto , el CSE bien podra tener el doble de los informes directos al igual que el PM . El CSE , en el marco del PM , asume la responsabilidad principal de la tcnica rendimiento del sistema . En cuanto a la distribucin del tiempo , el CSE puede experimentar 15 % horario , coste 15 % , y el rendimiento tcnico 70 % . El CSE tiene algunas responsabilidades administrativas , en gran parte tiene que ver con la gestin del equipo tcnico . El CSE es definitivamente un ingeniero de sistemas y debe pasar una gran cantidad de energa en la bsqueda de la solucin tcnica correcta

para el cliente . 1.5 LA ORGANIZACIN DEL PROYECTO 21 El hecho de que tanto el PM y el CSE tienen , hasta cierto punto , la superposicin responsabilidades , sugiere que es muy importante que estas dos personas trabajar juntos de manera productiva y eficiente. La friccin entre estos actores clave pondr en peligro seriamente el xito del proyecto . Deben comunicarse y compartir informacin extremadamente bien, y comprender las debilidades del otro y fortalezas . Uno-a- uno reuniones son estndar, de modo que los problemas potenciales son resuelto antes de que puedan hacer dao a los esfuerzos de todo el equipo. Una lista resumida de las principales responsabilidades y deberes del Jefe de Ingenieros de Sistemas se muestra en el Anexo 1.3 . Anexo 1.3 : Diez Responsabilidades y Deberes de los sistemas del Ingeniero (CSE ) 1 . Establecer el enfoque tcnico global 2 . Evaluar alternativas de diseo de sistemas arquitectnicos 3 . Desarrollar la arquitectura del sistema preferido 4 . Implementar un proceso de ingeniera de sistemas repetible 5 . Implementar un proceso de ingeniera de software repetible 6 . Supervisar el uso de herramientas informticas y ayudas 7 . Sirva como entrenador tcnico y constructor de equipo 8 . Realizar sesiones de revisin tcnica 9 . Intentar minimizar perodo total de tiempo del proyecto 10 . Desarrollar un sistema rentable que satisfaga los requisitos 1.5.3 Responsabilidades del Controlador de proyectos El Controlador de Proyectos ( PC) es el tercer jugador en la gestin de proyectos triunvirato . El PC no tiene responsabilidades de desempeo tcnico , centrndose lugar en la fecha prevista , el coste , la asignacin de personal , las instalaciones, y el contrato de enlace cuestiones . El tiempo dedicado a estas cuestiones se estima en un 25 % previsto, costo 45 %, 10 % del personal , las instalaciones 10 % y 10 % del contrato de enlace. Cuestiones de costos tienen que ver con asegurar que el primer ministro y el CSE reciben los informes de costos que necesitan y tambin que el proyecto en general se mantiene dentro de los costos presupuestados . El Controlador de proyectos es probable que sea el encargado '' '' del programa maestro para el proyecto , a pesar de las entradas son, evidentemente, requiere de personal de ingeniera . El PC no tiene que ser un ingeniero, a pesar de la comprensin de lo ingeniera no es claramente un requisito . Buenas PCs pueden anticipar problemas

por el anlisis en profundidad de los costos del proyecto y datos de programacin . Al examinar las tendencias y los horarios , la PC puede ser capaz de detectar los puntos conflictivos antes de que sean evidente para otros miembros del personal del proyecto. Esta persona por lo tanto, puede ser digno de l o su peso en oro, sobre todo a la PM . Una breve mencin de algunos de los PC de responsabilidades y deberes se proporciona en el Anexo 1.4 . 22 SISTEMAS , PROYECTOS Y GESTIN Anexo 1.4 : Diez Responsabilidades y Deberes del Proyecto Controller ( PC) 1 . Permite mantener el programa general del proyecto 2 . Evaluar los riesgos del cronograma del proyecto 3 . Asegurar la validez y oportunidad de los informes de costos del proyecto 4 . Seguimiento de objetos especiales de costos ( por ejemplo , los viajes, los subcontratistas) 5 . Desarrollar las tendencias de costos del proyecto 6 . Evaluar los riesgos de costos del proyecto 7 . Mantener el modelo de costes de ciclo de vida para el sistema 8 . Verificar y mantener las asignaciones del personal 9 . Asegurar que las instalaciones necesarias estn disponibles 10 . Mantener un enlace adecuado con el departamento de contratos 1.6 AMBIENTES Y FACTORES DE ORGANIZACIN Hay muchos que dicen que el clima organizacional en el que un proyecto se lleva a cabo es el factor crtico en el xito o fracaso de un proyecto [ 1,14 ] . Este artculo se mencion anteriormente en el tema del '' inferior apoyo corporativo . '' Examinamos esta cuestin aqu en algo ms de detalle con respecto a las entidades de sociedades en concreto con el que el Gestor del proyecto (y el Ingeniero y Jefe de Proyecto de Sistemas Controller ) debe interactuar. Las interacciones con el personal del proyecto , en su mayora, estn reservados para los debates en los captulos 5 y 6. 1.6.1 Estructuras de Organizacin Corporativa Aunque en gran medida un proyecto tiene una gran cantidad de estructural interna coherencia, que existe dentro de una estructura de organizacin corporativa de conjunto . Esa estructura corporativa , en funcin de su configuracin y los procesos , puede tener un gran impacto en lo bien que un proyecto pueda funcionar . En general , se puede decir que hay tres tipos genricos de las empresas estructuras , como se ilustra en la Figura 1.3 : ( a) la estructura funcional , ( b ) los estructura del proyecto , y ( c ) la estructura de la matriz . Como se muestra en la figura, la estructura funcional se organiza fundamentalmente por reas funcionales, tales como la ingeniera , marketing, ventas, fabricacin , produccin,

y as sucesivamente . Proyectos , como tal , ya sea para los clientes internos o fuera , se forman dentro de un grupo funcional para la duracin del proyecto y a continuacin, se disuelven . Dado que los proyectos van y vienen, la estructura funcional bsica permanece. Un PM se selecciona entre el grupo funcional que es probable que tenga el ms que ver con el proyecto desde el punto de vista funcional disciplina . dependiente de la forma en lo alto de la PM es en la organizacin funcional , as como otros factores tales como el alcance tcnico de trabajo del proyecto, el PM 23 corporativo administracin corporativo administracin y el apoyo corporativo administracin corporativo administracin y el apoyo Ingeniera de Marketing Ventas Produccin Manufacturera electrnico diseo mecnico diseo software ingeniera integracin y la prueba de especialidad ingeniera programa gerente proyecto la proyecto B proyecto D proyecto C proyecto E proyecto F

Proyecto A ... corporativo administracin corporativo administracin y el apoyo Ingeniera de Marketing Ventas Produccin Manufacturera programa gerente proyecto T proyecto H programa gerente programa gerente director Proyectos Proyecto B Proyecto N ( a) (b) (c) Figura 1.3 . Estructuras de organizacin de negocios . 24 SISTEMAS , PROYECTOS Y GESTIN puede tener que llegar a travs de las lneas funcionales para acceder a los recursos para el proyecto. Esto puede funcionar muy bien porque los gerentes funcionales estn en la misma posicin de requerir recursos de otros grupos de tiempo en tiempo . Proyectos por lo tanto, pueden hacer muy bien en organizaciones estructuradas funcionalmente , pero slo si la gestin de la lnea funcional es de apoyo de las necesidades del proyecto y requisitos . La figura 1.3 muestra el prximos '' estructura del proyecto '' pura , en la que la totalidad organizacin est formada por un conjunto de proyectos . Esta estructura es prevalente en el servicio organizaciones , y especialmente en los servicios profesionales de los contratistas que realizan trabajos para el gobierno federal. En tales casos , cada contrato tiende a establecer una del proyecto, y los proyectos van y vienen como los contratos en virtud de los cuales son operacin se complet sin renovaciones o nuevas exigencias del trabajo. la

PM usualmente comienza un proyecto con el personal clave de un proyecto que est eliminando gradualmente hacia abajo o est completado . Tal orientacin global de la empresa es propicio para proyectar la autonoma y el apoyo , ya que es su nico objetivo . Los proyectos pueden florecer en ese tipo de ambiente , pero de vez en cuando , no tienen acceso a conocimientos especializados que pueden residir en un grupo funcional. El tercer tipo de estructura corporativa global se muestra en la Figura 1.3 es el estructura de la matriz . Esto puede ser visto como un hbrido entre los dos anteriores formas , con la coexistencia de grupos funcionales , junto con el sector formal reconocimiento de un grupo de proyectos. En principio, esta forma social estructural puede proporcionar una mezcla ideal de las ventajas tanto de la autonoma del proyecto y funcionales experiencia. Presiones Sin embargo, en el mundo real y la competencia entre grupos funcionales del proyecto y tambin pueden proporcionar un entorno nonsupportive . Teoras aparte, gran parte del xito de una estructura matricial , en trminos experimentaron por el Director del Proyecto , depende de la calidad de las empresas gestin . 1.6.2 Interacciones con gestin Los informes de PM '' '' hacia arriba a la gestin , como se representa tal vez por un programa gerente o director de una divisin , o uno de los vicepresidentes . El ttulo especfico puede ser menos importante que la naturaleza de la relacin entre el PM y el jefe. Una posicin de direccin del proyecto puede llevar consigo la asuncin que el PM se ejecuta el proyecto, es decir, que el primer ministro tiene la responsabilidad total y autoridad para el proyecto. Esto puede ser cierto para los primeros, pero en la vida real es rara vez es cierto para el segundo. Es decir, la autoridad de la PM es limitado, y que es una cuestin fundamental que debe ser negociado entre el primer ministro y el jefe . Si no se algunos

1 . La contratacin de personal y el establecimiento de los salarios 2 . Dar aumentos y bonos 3 . Negociacin y firma de contratos

4 . Gastos de dinero para diferentes categoras 5 . Firma y verificacin de tarjetas de tiempo y gastos 6 . Negociacin con los clientes Si Una buena

esto implica

contraparte . Gran parte de

y as sucesivamente .

interaccin . PMs que descuidan esta relacin se dirigen a los problemas. Para los propsitos de esta discusin , podemos considerar dos circunstancias . Para el

clientes .

la

requisitos .

Por lo tanto ,

siguiendo : 1 . Reclutamiento con el fin de satisfacer las necesidades del proyecto 2 . La administracin de los programas de beneficios ( seguro mdico, etc ) 3. 4 . Recomendando salario y aumenta la remuneracin total 5 . Asesoramiento en los problemas de personal especiales

personal

Tpicamente , la Los mejores resultados

La Oficina del CIO tiene, entre otras, las siguientes responsabilidades : 1 . Identificar las necesidades de informacin de toda la empresa 2 . Enfoque estas necesidades a nivel de proyecto 3 . Construir o adquirir los sistemas con el fin de satisfacer estas necesidades 4 . Utilice estos sistemas con el fin de prestar apoyo a los diversos proyectos 5 . Reingeniera de los sistemas que cambian las necesidades

exacta .

Las tareas que se llevan a cabo tpicamente dentro de la Oficina del CTO son: 1. 2 . Relacionar estas tecnologas a los programas y proyectos individuales 3 . La inversin y la adquisicin de las tecnologas necesarias 4 . Personal de proyectos de formacin con respecto a estas tecnologas 5.

tal Si esto se puede lograr , el proyecto aumentar sus posibilidades de xito, tanto en lo inmediato y en el futuro . como

clientes .

al

contrato.

Medidas de Desempeo

Prcticas de Manejo

Debilidades administracin

Iniciativas

Dlares

administracin

incierto

de permanecer Dlares

Recursos

riesgo

perspectiva 1. 2. 3. 4. 5. 6. 7. 8. 9. 10 . ingeniera .

1. 2. 3. 4.

problema .

Retos

un . b. c.

enfoque un . b. Hay formas Explique .

un . funcional b . proyecto c . matriz

un . el Gerente de Proyecto b. c. Por qu?

Explique . REFERENCIAS y Diseo . Boca Raton , FL : CRC Press .

Englewood Cliffs, NJ : 17 . Ingeniera de Sistemas Fundamentos . Ft. . 3 .

4.

10 .

Management.

( 1992 ) .

Organizacin. Bass.