Un problema fundamental en la comunidad de ingeniera del software es cmo lograr un estado de mejora continua.

Durante los ltimos diez aos una serie de estudios se han realizado sobre diversas herramientas, mtodos y modelos de procesos de software proyecto de mejora del ciclo de vida, pero el problema persiste y en muchos casos el proceso del software programa de mejora muere dentro de un ao. Esta tesis toma la hiptesis de que la respuesta no puede reducirse a una sola herramienta o mtodo, ya que no hay soluciones mgicas a problemas complejos. En lugar de todo el sistema de Ingeniera de Procesos de Software deben ser estudiados para saber qu elementos son necesarios para el sostenimiento de la mejora actividad a largo plazo. Mediante la comprensin de los elementos fundamentales de un sistema de software de ingeniera de procesos, la organizacin puede gestionar y mejorar el sistema, ajustarlo al medio ambiente y que sea eficiente y eficaz. Cuando el sistema est en funcionamiento, el proceso del software programa de mejora, que es una parte del sistema, se puede sostener. Estos estudios de investigacin de un caso en el que se revis el sistema de Ingeniera de Procesos de Software de una gran empresa, las telecomunicaciones multi-sitio con xito para enfrentar los retos de mejora en aumento. La revisin del sistema ha demostrado ser capaz de sostener la mejora continua y el caso se utiliza aqu para obtener modelos de diseo arquitectnico de un sistema de software de ingeniera de procesos. Dos modelos se han establecido aqu. Se trata de un modelo de sistema que es independiente de la aplicacin e identifica los principales elementos de un sistema de software de ingeniera de procesos. Con la ayuda de este modelo, los responsables de la mejora de procesos en sus organizaciones pueden disear, evaluar y revisar completa de Procesos de Software Ingeniera de Sistemas. El otro modelo es un diseo de una organizacin multi-sitio de software de ingeniera de procesos, e identifica no slo la parte dispositiva de la organizacin, sino tambin los elementos clave no quirrgico que una Ingeniera de Procesos de Software sistema necesita para trabajar. Con la ayuda de este modelo de una organizacin multi-sitio puede configurar el operativo de Procesos de Software Ingeniera de organizacin y un plan de estrategias para la gestin de la cooperacin con las entidades de interfaz en la delantera, en lugar de terminar la gestin de estos contactos de manera reactiva. Prefacio Este estudio se ha llevado a cabo en paralelo con mi trabajo como investigador de Nokia Mobile Phones. Me gustara expresar mi ms profundo agradecimiento a mi empleador, especialmente a la Dra. Pekka Isomursu, por lo que me permite utilizar una parte sustancial de mi tiempo de trabajo de esta tesis, y para el estmulo y apoyo que he recibido de l y de mis colegas y amigos en el NMP y NRC. Tambin quiero dar las gracias al profesor Samuli Saukkonen, el supervisor de esta tesis, para impulsar en m. Pero sobre todo mi agradecimiento pertenecen a mi familia por la cantidad extraordinaria de la comprensin y el apoyo que he recibido. Este trabajo est dedicado a mi familia, que ha sufrido mucho, a los globales de SPE Equipo de Coordinacin, sin la cual no habra sido muy poco que escribir, y finalmente a todos los que pasan demasiado tiempo transcribir pensamientos - el suyo u otros - para la gente a leer. Para el ltimo grupo, el nico consuelo viene del hecho de que no siempre han sido aquellos que tienen esta suerte y que todos compartimos la misma

sensacin que una vez que el trabajo ha sido completado, ya que esta nota al margen testimonio annimo: Aqu termina la segunda parte del ttulo de la obra de fray Toms de Aquino de la Orden Dominicana, muy largo, muy detallado, y muy tedioso el escriba, gracias a Dios, gracias a Dios y otra vez gracias a Dios. Un breve comentario (explcito) escrito por un escriba despus de terminar copiar un texto largo Toms de Aquino en el siglo 14. (Drogin 1980, 12) Introduccin En la ltima dcada, la humanidad ha sido testigo de un crecimiento exponencial de la industria del software y el uso de software. Hoy en da, el software tiene un uso mucho ms amplio que los procesadores de texto solo o en otras aplicaciones de PC. En un grado cada vez mayor tambin es oculta, incrustado en otros productos electrnicos, tales como automviles, electrodomsticos, sistemas de airtraffic de control, dispositivos de comunicaciones, etc Lo que muchos no saben es que ya hoy en da, los controles de software y afecta a nuestras rutinas diarias en la medida en que un fallo de software es la mayor amenaza para nuestras vidas (Ebert 1997, Gray & Smith, 1998). A medida que el mundo se dirige hacia la computacin ubicua, el papel del software ser an mayor que en la actualidad. La visin de entorno inteligente que es la ms simple pieza de equipo o la ropa, incluso tiene la capacidad de proceso de datos y de interactuar con su entorno, de forma independiente. Las mquinas se vuelven ms inteligentes, auto-guiados y consciente. Computadoras y el procesamiento de datos existen en todas partes, desde tostadoras a los zapatos de tenis. Maana la chaqueta podra llevar a que la potencia de procesamiento ms que su porttil tiene hoy en da e incluso ms. (Negroponte, 1995.) La necesidad de software se ha incrementado dramticamente, y la era ubicua pondr una demanda an mayor en ella. La necesidad de reducir el ciclo de desarrollo de software se convertir en ms pronunciada, mientras que tambin habr demanda de una mayor funcionalidad. Ambas tendencias se lamentablemente tambin aumentan las posibilidades de errores en el software, y los estudios indican que la tasa de defectos no es una funcin lineal del tamao, en cambio el aumento de tasa de defectos de forma exponencial (Brown 1996). Sin embargo, al mismo tiempo, la demanda es para el software mejor y ms fiable (Collier y Collofello 1996). Especialmente en los mercados de electrnica de consumo, los fabricantes deben esforzarse por cero defectos, como la retirada de cientos de miles de productos que el producto haya sido puesto en marcha ser muy costoso, tanto econmicamente y como una imagen negativa de la empresa (Roojimans et al. 1996). Como resultado, cuando los bienes de consumo obtener ms programas integrados en ellos, la capacidad de producir software de forma rpida y confiable para mantener una calidad uniforme en todos los productos se convierte en un factor clave para el xito o el fracaso de las empresas en todo el mundo. Todo esto ya es bastante visible para la industria y las empresas estn buscando soluciones para afrontar el reto. Varios enfoques estn siendo juzgados, pero que comparten la comn objetivos de desarrollo de productos de mejor calidad, disminuir el tiempo de ciclo de desarrollo y aumentar la eficacia y la eficiencia de los recursos de desarrollo. Una solucin que ha sido muy popular durante los ltimos diez aos ha sido mejorar el proceso de desarrollo de software. El paradigma que se acepta es que la calidad del proceso influye en la calidad del producto. Tambin hay evidencia de que la mejora del

proceso aumentar la velocidad, eficacia y eficiencia del desarrollo de software (al Wesner et al. 1994). Como consecuencia, la gestin y mejora de procesos de software se ha convertido en una tarea que no puede ser ignorado por ninguna compaa que produce software. Lo que no es por lo general se dio cuenta, sin embargo, es que la mejora del proceso tambin conlleva un riesgo para la organizacin que lo utiliza. En primer lugar, que consume recursos que podran ser utilizados en el desarrollo de productos. En segundo lugar, cualquiera que sea el software de mejora de las actividades del proceso son, siempre tienen un impacto - ya sea para bien o para mal. Esto se convierte en un gran riesgo cuando la mejora de procesos se aplica al proceso de desarrollo de productos, que es el elemento ms importante de una empresa comercial. Por esta razn, desde el punto de vista de la industria, mejora de procesos no es una tarea trivial y la forma en que los procesos se cambian y administrado es un tema crtico. Para reducir al mnimo los riesgos para la organizacin de acogida, actividades de software relacionadas con los procesos necesidad de aplicar un enfoque de ingeniera y la disciplina - al igual que el desarrollo del producto lo hace. Proceso de trabajo es un proceso, tambin, y es necesario mejorar de manera sistemtica para lograr una mayor madurez - es decir, para que el proceso sea ms previsible, eficaz y eficiente, y mejorar la calidad de la produccin. El proceso de las comunidades de software en las empresas deberan tener una mirada introspectiva a la forma de mejora de procesos de software que se est haciendo y esforzarse por software de ingeniera de procesos, es decir, un enfoque disciplinado para los procesos de gestin y un mayor desarrollo y activos de los procesos. Un buen punto de partida para esto es comprender el sistema de Ingeniera de Procesos de Software en s - definir cules son las actividades que deben llevarse a cabo y establecer una infraestructura completa para apoyarlos. Adems, para mantener el sistema de Ingeniera de Procesos de Software eficiente y eficaz, la infraestructura, as como el enfoque de la ingeniera de procesos en general tiene que ser conscientemente administrado, mejorado y adaptado para reflejar los cambios en el entorno en el que tiene que operar. Antecedentes En este captulo se establece la motivacin para esta investigacin, ofrece una visin general del asunto que se ha estudiado, y define el alcance de la tesis Motivacin En los ltimos aos la comunidad de ingeniera de software en general ha adquirido ms experiencia en la realizacin del proceso de trabajo, y artculos de las lecciones aprendidas son ahora fcilmente disponibles en ambas revistas y conferencias. Hay tambin varias conferencias anuales dedicadas exclusivamente a problemas de software de mejora de procesos, el ms destacado de ellos es la SEPG (Software Engineering Process Group) de conferencias patrocinado por el Software Engineering Institute (SEI). A pesar de esto, todava hay cuestiones importantes que deber resolver en el mbito de trabajo de procesos de software (en adelante SPE, Ingeniera de Procesos de Software). Estamos haciendo un trabajo razonablemente bueno de las organizaciones de la evaluacin y la efectividad de sus prcticas tcnicas y de organizacin. Hay varios mtodos ... para conseguir las organizaciones para reconocer los problemas que debe resolver para mejorar. El problema de investigacin interesante es ahora pasar a lo que se necesita para una organizacin para mantener un programa de mejora de graves, de modo que sean capaces de darse cuenta de los beneficios prometidos

-muchos abandonan la pelota en sus actividades de mejora dentro de un ao. "- Bill Curtis Un estudio de la literatura revela que gran parte de la investigacin realizada en el mbito de la SPE desde 1987 se ha concentrado en el desarrollo y la descripcin de los mtodos especficos, modelos e instrumentos de diferentes aspectos del proceso de trabajo, sobre todo para los de la definicin, evaluacin y mejora de procesos software. Por el contrario, existen pocos estudios del sistema de SPE s mismo, es decir, el proceso de SPE y la infraestructura que tiene que ser creado para apoyar y sostener las actividades de la SPE. Por otra parte, lo que ha sido publicada se centra principalmente en sistemas de un solo sitio y las cuestiones relacionadas con los sistemas multi-sitio de la SPE no se abordan. Estos estudios son importantes por varias razones. En primer lugar, las personas responsables de establecer y gestionar un sistema de SPE en su organizacin necesita tener una comprensin de todo el sistema, no slo un conocimiento detallado de los mtodos particulares o herramientas. En segundo lugar, una buena comprensin del sistema es necesaria con el fin de mejorar, de manera que el proceso de SPE puede ser eficaz y eficiente. A medida que la empresa de acogida que ya tenga - o en el futuro convertirse en - un entorno multi-sitio, los retos especficos de estos entornos necesitan ser estudiados para proporcionar la informacin que los gerentes de la SPE sobre cmo construir un sistema de SPE multi-sitio. Ninguna de las publicaciones actuales, presenta un modelo integral de todo el sistema de SPE. Los modelos de procesos ms notables de referencia que definen las actividades relacionadas con los procesos de trabajo son la norma ISO 12207 (ISO / IEC 1995), ISO 15504 (ISO / IEC 1998a, b, c), y IDEALSM 1.0 (McFeeley 1996). Las principales referencias para la infraestructura de la SPE, es decir, los elementos necesarios para apoyar las actividades son los IDEALSM 1.0, ISO 15504-7 (ISO / IEC 1998c), Fbrica de experiencia (por ejemplo, Basili y McGarry, 1998), SW-CMM 1.1 (Paulk et al. -93 bis, b), y el libro "Software Process Improvement: Gua prctica para el xito empresarial" por Zahran (1998). Sin embargo, estas publicaciones dan slo la ejecucin del modelos en lugar de explicar las construcciones fundamentales, es decir, la arquitectura, de la infraestructura. Por otra parte los modelos estn destinados para el establecimiento de locales (de un solo sitio) infraestructuras y tienden a centrarse en las organizaciones operativas. Esto deja a otros aspectos de infraestructura, tales como herramientas, las cuestiones de conocimiento, habilidades, etc, y entidades organizativas en gran medida ignorado. Caso Esta tesis presenta el caso de la revisin del sistema de SPE en Nokia Mobile Phones, Ltd. (en adelante NMP). El caso es estudiado para extraer y publicar el diseo arquitectnico modelos para sistemas multi-sitio de la SPE. El objetivo de la tesis es sobre el perodo comprendido entre finales de 1996 y mediados de 1997, tiempo durante el cual los requisitos para el nuevo sistema de SPE se han especificado, el sistema diseado y implementado, y el nuevo Software Process Improvement (en adelante SPI) puesto en marcha y puso en marcha. El sistema de la SPE ha estado en operacin desde 1997 y la tesis del incluye los resultados de una evaluacin del sistema, que se llev a cabo a finales de 1998. mbito

Esta tesis se centrar en el tema de la Ingeniera de Procesos de Software, la exploracin de temas que ayudan a mantener un proceso continuo de la SPE, especialmente en un entorno multi-sitio. Los procesos de desarrollo de software, tales como la especificacin, diseo, implementacin, pruebas, etc, no se discuten en este estudio. Sin embargo, como el propsito del sistema de SPE en NMP es apoyar el mejoramiento y mantenimiento de los procesos de desarrollo de software, la relacin entre el sistema de SPE y los procesos de estos se encuentra dentro del mbito de aplicacin de esta tesis. El estudio aborda el tema desde un punto de vista de la gestin operativa y tiene por objeto establecer una comprensin de la arquitectura de un sistema de SPE en toda la organizacin, donde la organizacin contiene mltiples unidades en el desarrollo de software. El objetivo de esta tesis es el diseo arquitectnico del sistema de software de ingeniera de procesos, en lugar de en su diseo detallado y la aplicacin. Por esta razn, las cuestiones tales como la forma en las actividades de la SPE se deben llevarse a cabo, y los diversos mtodos, herramientas, procesos, etc utilizados en el trabajo de la SPE no se describen en detalle. Cuando se discuten estos temas, el propsito es proporcionar una mejor comprensin de los elementos arquitectnicos, dando ejemplos de la aplicacin. Investigacin Las dos primeras secciones de este captulo el problema de investigacin, dar una visin general de los resultados, y describir el aporte de esta investigacin, la tercera seccin se describen la investigacin de proceso en s. La cuarta seccin se enumeran los problemas especficos y las limitaciones inherentes a este caso particular, la investigacin y las medidas adoptadas para superar y la lucha contra ellos. La ltima seccin describe la participacin de personal del autor y su contribucin en el caso. Investigacin de problemas y resultados La ltima inspiracin de esta tesis es el problema de cmo lograr el estado de la mejora continua de procesos. Una forma de esta pregunta es la siguiente: Qu se necesita para una organizacin para mantener un serio programa de mejoramiento, de modo que sean capaces de darse cuenta de los beneficios prometidos? "- Bill Curtis Esta pregunta no puede y no se resolver en esta tesis. El problema en s es muy fundamental para la comunidad de ingeniera del software en general y, sin duda, tiene una respuesta muy compleja en lugar de ser algo que podra resolverse con la bala de plata infame (Brooks 1987). Lo que esta tesis pretende es dar a conocer algunas partes importantes de esta respuesta compleja. Un sistema de Ingeniera de Procesos de Software es uno de los factores clave para determinar si el estado de la mejora continua se puede lograr o no. Un inoperable y sistema ineficaz no puede alcanzar y mantener las mejoras, no importa lo buena voluntad de una gestin mucho ms hay en la organizacin hacia los procesos de trabajo. As, la cuestin no es si debe o no tener un sistema, sino cmo construir un sistema SPE que est en funcionamiento y capaz de cumplir sus objetivos. Por otra parte, en un entorno cambiante del sistema puede necesitar ser revisado para asegurarse

de que sigue siendo compatible con el medio ambiente tiene que parpadea, por tanto los propsitos es importante para entender lo que un sistema de SPE debe contener y cules son los elementos esenciales de tales un sistema. De esto podemos derivar el problema de investigacin: Que es una arquitectura utilizable de un sistema de ingeniera de Procesos de Software? El sistema de SPE desarrollado en el marco de esta investigacin se basa en un conjunto de modelos abstractos que definen los elementos de arquitectura para dicho sistema. Como la evaluacin mostrar, el sistema se ha encontrado en funcionamiento y ha demostrado ser capaz de sostener un continuo programa de SPI. Esto indica que el sistema tiene los elementos necesarios, es decir, su arquitectura es completa y utilizable. La pregunta de investigacin lo que se puede responder mediante el estudio de los eventos, actividades, modelos y construcciones (el sistema de SPE s mismo) de este estudio de caso, y mediante el refinado de la serie original de los modelos con la ayuda de las lecciones aprendidas de su utilizacin y de las ideas formadas en la literatura de software de mejora de procesos. Contribucin La principal aportacin de esta tesis es el establecimiento de dos nuevos modelos de diseo arquitectnico para un sistema de software de ingeniera de procesos. El primer modelo incluye el sistema de toda la SPE y la segunda analiza la organizacin de la SPE, que es una parte importante del sistema de SPE. La arquitectura a nivel de sistema tiene tres elementos principales. El primer elemento describe los propsitos y los insumos, as como las principales actividades del proceso de SPE. El segundo elemento a su vez, se describen los elementos de apoyo necesarios para que el proceso operativo de la SPE. El tercer elemento a continuacin se describen los niveles de organizacin a travs del cual el sistema debe abarcar SPE y define el alcance de las actividades de la SPE de cada una de las capas. La arquitectura para la organizacin de la SPE cubre todos los niveles de organizacin e incluye el elemento operativo y tres elementos no operativos - el patrocinio de redes, el Proveedor y la Red de Cooperacin, y los profesionales de software Los modelos de ampliar los resultados de estudios previos de la siguiente manera. En primer lugar, no ha habido un nico modelo que se publica el diseo arquitectnico de todo SPE, (o proceso de software mejora, SPI) del sistema que combine las actividades, el apoyo a los elementos y las jerarquas de la organizacin. En segundo lugar, los modelos actuales para la mayor parte de describir un diseo detallado (cerca de ejecucin), en lugar de identificar los elementos esenciales de arquitectura que son independientes de la aplicacin y por lo tanto se puede utilizar para guiar el diseo detallado, para comparar diseos diferentes por su amplitud, etc . La arquitectura a nivel del sistema establecido en el presente estudio abarca todos los aspectos antes mencionados y es independiente de la implementacin. En tercer lugar, los modelos actuales en la literatura que describir las organizaciones de la SPE se centran en la parte dispositiva de la organizacin. Las experiencias de funcionamiento de un sistema de SPE en NMP sugieren, sin embargo, que los modelos deben ampliarse ms all de la organizacin operativa para ayudar al sistema de la SPE para construir interfaces de organizaciones relacionadas, no operativas. En consecuencia, la estructura organizativa establecida en la presente investigacin identifica las ms importantes no operativas entidades que deben tenerse en cuenta a la

hora de establecer estrategias para la SPE. En cuarto lugar, el aspecto multi-sitio es por lo general carecen de las referencias de la literatura, pero es un importante parte de este estudio y ha sido construido especficamente para los modelos establecidos aqu. La arquitectura del sistema puede ser utilizado como un marco para el estudio de los sistemas de Ingeniera de Procesos de Software, pero, como tal, los modelos desarrollados se destinan principalmente como herramientas para SPE administradores. La arquitectura del sistema es una herramienta para el diseo de un sistema de SPE, para revisar su estado y para la revisin de la misma. La arquitectura de la organizacin en el otro lado se puede utilizar como punto de partida para el diseo o la adaptacin de una organizacin de la SPE para una organizacin multi-sitio. Metodologa de la investigacin El estudio presentado aqu es la investigacin constructiva, donde los artefactos resultantes son modelos abstractos que definen la arquitectura de un sistema de software de ingeniera de procesos en general y la parte de organizacin del sistema en particular. Sin embargo, la investigacin tiene tambin elementos de la construccin de teora, ya que los modelos tambin pueden ser consideradas teoras (marzo y Smith, 1995, 256). El mtodo de investigacin de fondo es un estudio retrospectivo de casos longitudinal. Aunque el estudio tiene caractersticas de la investigacin-accin, no cumple con un criterio clave y por esa razn no se considera dentro del mbito de la ciencia de la accin. Si bien el autor ha participado como actor en el caso, que era una accin de cambio que apuntaba a resolver un problema prctico, la investigacin no se llev a cabo en paralelo con la accin misma. En la investigacin-accin, el problema de investigacin debe ser claramente formulada en el comienzo de la accin. El investigador trabaja en una mano para solucionar el problema y en la otra mano para crear y adquirir informacin cientfica relacionada con la solucin del problema. Adems, debe haber un ciclo de retroalimentacin inmediata de la investigacin a la accin en la resolucin de problemas (Jrvinen y Jrvinen 1996, 79). En este estudio el problema de investigacin fue formulado slo despus de que la accin haba sido concluido y la investigacin sobre los hechos del pasado, por lo tanto, el estudio retrospectivo de casos. March y Smith sugieren que en la investigacin constructiva cada salida se construy, evalu, teoriz y justific. Las salidas son constructores (por ejemplo, la terminologa), modelo, mtodo y de instancias (March y Smith, 1995). El proceso de construccin de una teora de la investigacin del estudio de caso por Eisenhardt incluye los siguientes pasos: Introduccin (definicin de la pregunta de investigacin), Seleccin de los casos, la elaboracin de instrumentos y protocolos (de recogida de datos), entrar en el campo, anlisis de datos, sharping hiptesis, Envolvente la literatura, y el cierre Llegar (Eisenhardt, 1989). Como se dijo anteriormente, la principal aportacin de esta investigacin son los modelos, y por lo tanto la atencin se centra en la produccin del modelo en trminos de la March y el marco de Smith. El primer estudio de seguimiento de las actividades histricas que llevaron al sistema actual de la SPE, de la definicin de los modelos originales (Build), para la creacin de instancias y el funcionamiento de la ingeniera de procesos sistema en el caso de la organizacin (Evaluacin en marzo y Smith, pero tambin Anlisis de datos en Eisenhardt). En este punto se inicia la construccin de teoras, todas las conclusiones relativas a la integridad y la relevancia de los modelos de la evaluacin se utilizan para refinar los modelos (hiptesis sharping), junto con las

aportaciones de la literatura (literatura Envolvente), produciendo un modelo de arquitectura que permita la SPE sistema y un modelo revisado para la organizacin de la SPE (Alcanzando el cierre). La parte de construccin de la teora de la investigacin en su totalidad puede tambin ser visto como el Theoretize-participar en la Marcha y el marco de Smith. El primer estudio de seguimiento de las actividades histricas que llevaron al sistema actual de la SPE, de la definicin de los modelos originales (Build), para la creacin de instancias y el funcionamiento de la ingeniera de procesos sistema en el caso de la organizacin (Evaluacin en marzo y Smith, pero tambin Anlisis de datos en Eisenhardt). En este punto se inicia la construccin de teoras, todas las conclusiones relativas a la integridad y la relevancia de los modelos de la evaluacin se utilizan para refinar los modelos (hiptesis sharping), junto con las aportaciones de la literatura (literatura Envolvente), produciendo un modelo de arquitectura que permita la SPE sistema y un modelo revisado para la organizacin de la SPE (Alcanzando el cierre). La parte de construccin de la teora de la investigacin en su totalidad puede tambin ser visto como Teorizado en parte de March y el marco de Smith. Proceso de investigacin y limitaciones El caso examinado en esta tesis abarca el perodo comprendido entre finales de 1996 hasta mediados de 1997 y, desde el punto de vista de la investigacin, se lleg a la conclusin, cuando se inici el estudio y el problema de investigacin formulado. Por esta razn el caso se estudia desde una perspectiva histrica. Como se trata de un estudio de un solo caso, los resultados no cumplen con los requisitos teoras tan firmemente establecidos. En su lugar, se puede considerar como hiptesis bien estudiado, lo que sugiere que la teora podra parecer. La propuesta de investigacin, o una idea, se formul en marzo de 1998, cuando el autor fue la gestin del programa mundial de SPI en la organizacin de caso, pero ya haba decidido pasar a otros retos como parte del desarrollo personal. Dado que el autor haba acumulado una experiencia y unos conocimientos sobre el software de proceso del sistema de ingeniera, sus problemas y estructuras, y se haba dado cuenta de que los informes relacionados con muy poca experiencia haba sido publicada, la idea de publicar los resultados del trabajo del autor como tesis de doctorado fue un paso natural. La idea tambin fue apoyada por el director del autor de la propia lnea, desde la captura de dichos conocimientos y experiencia benefician a la empresa tambin. A medida que el caso ya haba sido concluido la estrategia consista en reunir pruebas de la poca y respondiendo a los problemas de investigacin mediante el anlisis y la interpretacin de la misma. Adicionales ventaja era que ya que el autor ha participado activamente en todos los eventos y actividades relacionadas con el caso, haba ideas que de otro modo sera difcil de obtener. Esto, sin embargo, se reconoci tambin como un riesgo para la investigacin, la implicacin personal siempre inyecta una cierta cantidad de sesgo en el estudio. Para minimizar los efectos de la el sesgo y mantener una visin objetiva del caso, el mtodo de triangulacin de datos se ha utilizado. Segn Miettinen triangulacin de datos "consiste en comprobar las inferencias a partir de un conjunto de datos con otros datos del mismo fenmeno e independiente de la primer set "(Miettinen 1998, 44). En este estudio el tipo especfico de la triangulacin de datos es la tcnica de triangulacin, donde los datos recogidos por diferentes mtodos se comparan para obtener una imagen veraz del caso. En primer lugar, la investigacin depende en gran medida en la documentacin creada como un sub-productos o resultados de las actividades de la SPE. El material fue creado

antes de la poca en que haba una idea de hacer una investigacin de este tema. Aunque el material no fue creado con fines de investigacin, no obstante, captura los puntos de vista, ideas, problemas y actividades como lo fueron en el momento y por lo tanto proporciona visin amplia y objetiva de los acontecimientos y actividades. Todo el material de los proyectos que implement el cambio en el SPE enfoque ha sido almacenados y guardados y, salvo algunos casos aislados, no se ha eliminado. El principal problema con el material es que en gran medida refleja slo las acciones y los resultados finales de, por ejemplo talleres de anlisis, pero por lo general no documenta los resultados intermedios, las razones detrs de las decisiones y as sucesivamente. Adems, el material no est estructurado, es en realidad muy fragmentada, si bien extenso. Por esta razn, los hechos tuvieron que ser reconstruida utilizando varias fuentes y unirse a las distintas fuentes con el autor el conocimiento personal de las relaciones entre las diferentes piezas de informacin. El hecho de que la posicin de un gerente para el sistema de proceso de ingeniera proporcionan una vista privilegiada para las actividades y eventos tambin ha apoyado este trabajo. El autor tiene un acceso completo a todo el material antes mencionado (vase tambin el Apndice 2: NMP fuentes internas para el estudio), que incluye: Satisfacer las agendas y los minutos, de todos los niveles de organizacin de la SPE Accin elementos para todo el personal de la SPE Operativo y material patrocinio de gestin, incluyendo presupuestos, planes, etc. Discusiones en "SW Foro un foro de debate electrnico (un foro electrnico abierto / sistema de gestin del proyecto se centr en cuestiones de tecnologa de software) Proceso de documentacin Presentacin de materiales, informes provisionales (por lo general presentada mensuales), proyecto o planes de accin y los resultados. Taller de notas y documentos de trabajo interno del proyecto. Adems, el propio autor tiene material adicional, incluyendo Memos / notas / folletos: El autor ha conservado todas las tareas directamente o proyecto - documentacin relacionada no electrnicos (en carpetas). Personal de registro incluyendo: Agenda de trabajo personal Calendario de notas: Los artculos personales de accin, notas marginales, anotaciones de calendario. Email de Personal: El autor ha conservado casi todos los directamente tareas y de intercambio de correo relacionada con el proyecto de la poca del caso entero (en el servidor de correo) Reportes de viaje: El autor ha conservado copias de todos los planes de viaje y los informes de facturacin. Estas son las formas administrativas necesarias para ser llenado en NMP para obtener billetes de viaje y los reembolsos (respectivamente). Los formularios requieren una descripcin de la ruta de viaje, destino, y el motivo del viaje (en una planificacin de viaje electrnica y sistema de facturacin 'Trace'). En segundo lugar, las personas clave que han estado involucrados con el sistema de SPE en NMP han sido entrevistados para aumentar el material catalogado. Muchos de los entrevistados tienen experiencia de desarrollo de productos como

ingenieros de software o los directores de proyectos y as han sido capaces de proporcionar no slo la ingeniera de procesos, sino tambin puntos de vista de ingeniera de productos para este estudio. Adems, las personas involucradas han examinado y aprobado las partes que se ocupan de las cuestiones que se han centrado en, as como los resultados finales y conclusiones que se presentan en esta tesis. El material de la caja y la literatura se recogi durante la primavera de 1998, y el estudio de la literatura realizada en el verano de 1998, el autor tambin ha seguido la encuesta la literatura en todo el periodo de investigacin. Las publicaciones ms notables de la poca de 1988 a 1998 se estudiaron para ver que se ha publicado sobre el establecimiento, gestin y mejora del sistema de SPE en s. Las principales publicaciones se presentan en el captulo 4 de este estudio. Los temas de investigacin actuales se formularon despus de que el estudio de la literatura. En ese momento el autor tambin entreg la posicin del director del programa de SPI y se centr en la tesis. El material de los casos que haban sido recogidos hasta el momento se ha procesado, el caso documentado en agosto-octubre de 1998, el anlisis y la sntesis realizada en septiembre-diciembre de 1998. El autor tambin sigui recogiendo el material del caso durante todo este perodo, pero el final del ao fue seleccionado como punto de corte como la tesis es que debe concluirse en 1999. Participacin del actor y contribucin a los resultados Aunque el caso se estudia desde la perspectiva histrica, la participacin del autor en esta investigacin no se limita a la mera documentacin de los acontecimientos y el anlisis de ellos. En cambio, el autor ha sido una figura clave en el proceso de cambio en s mismo, por ejemplo, el autor es el arquitecto principal del sistema actual de la SPE y dirigi el proyecto que revis el sistema. Adems, el autor tiene experiencias personales a largo plazo como parte del sistema de SPE en NMP y ha visto su evolucin durante el crecimiento y la globalizacin. El autor tambin ha experiencias de primera mano de los problemas en el sistema a travs de la SPE y la promocin profesional se ha visto el sistema de todo el "nivel de base" el camino hasta el punto de vista de la alta gerencia operativa. La participacin del autor con el software de ingeniera de procesos comenz en 1993 cuando fue contratado como experto en procesos de software de NMP, en el sitio que tiene la responsabilidad global para la investigacin de tecnologa de software y mejora. La comunidad de software de proceso de NMP en ese momento era relativamente pequeo y la empresa no haba tenido anteriormente como cualquier persona con amplia experiencia en temas de proceso de software como el autor. Por esta razn, el autor se convirti de hecho responsables del cuidado de los procesos de software y para proporcionar la consulta a la calidad global, Mtodos y Herramientas de equipo lder en materia de proceso. Los primeros trabajos del autor incluye la adaptacin del modelo de ciclo de vida principal de los programas de desarrollo de productos para adaptarse a los subproyectos de software, el apoyo a los proyectos de software en los posibles problemas relacionados con el proceso, recogida y anlisis de resultados de la autoevaluacin en toda la organizacin, lo que representa NMP en ISO 15504 de trabajo, y as sucesivamente. En este trabajo el autor haba funciones tanto a nivel local y mundial, ganando

experiencia en el trabajo de la SPE, tanto el "nivel de base y de los problemas de nivel mundial acciones de SPI. Cuando la poltica de la SPE de NMP fue modificada en 1995 y comenz la aplicacin del nuevo enfoque, el autor fue uno de los tres miembros y el nico representante de NMP en el primero de los proyectos destinados a aplicar el cambio, los otros dos miembros que se Centro de Investigacin de Nokia. Este proyecto estableci las bases de la revisin del enfoque de la SPE. A continuacin, particip activamente como externos (al proyecto) consultor para el segundo de los proyectos de cambio que se implement el nuevo sistema para gestionar la documentacin de procesos de software, y particip activamente en la preparacin de la iniciativa Nokia proceso de mejora en toda la empresa como representante de facto del NMP. A finales de 1996 el autor fue nominado como el lder del proyecto del ltimo de los proyectos de cambio que se revisa el Software NMP Proceso de Ingeniera de Sistemas e inici el nuevo programa de SPI. Por ltimo, cuando el nuevo sistema estaba siendo operado, el autor fue nombrado como Gerente de SPI de Nokia Mobile Phones, responsable de toda la SPE sistema, el programa mundial de SPI y las estrategias de SPE en NMP. El autor estuvo en este cargo hasta agosto de 1998, cuando cumpli la tarea ms al director de programa nuevo Para ser capaz de concentrarse en la escritura de esta tesis. Sin embargo, el autor ha seguido participando activamente en la planificacin del nuevo programa de SPI y ha contribuido tambin a las estrategias de Nokia software corporativo. Trabajos relacionados Las referencias clave relacionados con los sistemas de SPE son los varios modelos de software de proceso y SPI modelos de proyectos de infraestructura presentados en la literatura. Varios modelos se han publicado a lo largo de los ltimos diez aos, cada uno de explorar el tema desde su particular punto de vista. Adems de los modelos, la literatura tambin ofrece algunos informes de experiencia en el sector que describen un sistema de SPE o cmo un determinado programa de SPI se ha creado y operado. Los modelos que aqu se ha dividido en dos grandes clases de acuerdo con su contenido. Estos son los modelos de proceso de SPE (ver seccin 4.1) y los modelos de SPE infraestructura (ver seccin 4.2). La primera clase incluye los modelos que identifican actividades como el proceso y dar definiciones para ellos. La segunda clase contiene modelos o descripciones similares de los elementos estructurales o de apoyo, tales como la organizacin, que son necesarios para que el sistema operativo de SPE y el apoyo a las actividades. Los informes de experiencia en el sector se presentan en la seccin 4.3 Las publicaciones de investigaciones anteriores han sido presentados aqu en una forma muy concisa. Los modelos principales son identificados y un resumen comparativo de los modelos de similar para sealar sus puntos fuertes y dbiles. Los informes de experiencia en la industria tambin son presentados como un breve resumen. Hay dos razones por la brevedad: en primer lugar, todas las lecturas son muy recomendables por su propio derecho para los interesados en o trabajando con el tema de esta tesis, y en segundo lugar, un resumen ms detallado podra estar en desproporcin con el resto de esta tesis.

En la seccin 4.4 los trabajos correspondientes se resumen y analizan sealar qu reas todava no se han investigado y qu tipo de informacin no ha sido previamente publicado. SPE modelo de procesos El modelo de proceso de trmino es usado aqu para referirse a los modelos que identifican las actividades, proporcionar una descripcin de la finalidad para la que la actividad, y posiblemente tambin de la indicacin de cmo llevar a cabo dicha actividad. El modelo puede o no tener una jerarqua estructurada de procesos y / o vincular los diversos procesos en una secuencia o (la vida) del ciclo. Varios de estos modelos existen en la literatura, algunos de ellos disponibles para cualquier persona y han existido por casi una dcada, mientras que otros son ms difciles de obtener. La razn de este ltimo es ya sea porque el modelo todava no se ha hecho pblica, o no hay publicacin definitiva o de referencia para ellos y la nica forma prctica de obtener el material para asistir a un curso, tutorial o un seminario donde el modelo dijo que se presenta. Todos los ms conocidos modelos de procesos se presentan a continuacin. Modelos claves de proceso El mayor de los modelos que aqu se presenta es el SW-CMM 1.1 (Paulk et al. 1993b). El modelo est diseado para apoyar la capacidad de proceso de software y las evaluaciones de madurez y, para ello cuenta con un modelo de madurez del proceso software que se puede utilizar para identificar las entidades, como en procesos. El modelo tiene tres niveles de jerarqua, donde cuatro proceso de "niveles de madurez" (el ms alto nivel) se han dividido en "reas clave del proceso" (KPA), que a su vez han sido divididos en "caractersticas comunes". Hay un total de cinco niveles de madurez, pero el primer nivel no se ha dividido an ms en las reas de proceso clave, ya que se considera que el estado inicial. El modelo ha sido pensado principalmente como un mapa o gua hacia niveles ms altos proceso de madurez y presenta las caractersticas de cada nivel de madurez con la descripcin de los procesos que tienen ciertos elementos en un nivel determinado. Por esta razn, el mismo proceso (por ejemplo, gestin de proyectos) pueden aparecer como diferentes instancias (toma formas diferentes) en diferentes niveles de madurez. Actividades relacionadas con el SPE se pueden encontrar niveles de madurez de dos a cinco. El Trillium-mtodo (Coallier et al. 1994) ha sido desarrollado por Bell Canada para los fines de las evaluaciones de software de madurez de los procesos y proporcionar una gua para software de mejora de procesos. En gran medida sobre la base de SW-CMM 1.1 modelo, se ha desarrollado especialmente para la industria de las telecomunicaciones. El modelo de proceso incorporado en el modelo Trillium tiene una jerarqua de tres niveles, donde las actividades se han agrupado en "reas de capacidad", dividido en "hojas de ruta", que se describe a continuacin, mediante la presentacin de sus caractersticas en diferentes "niveles de madurez". El rea de capacidad "3: Proceso" se ha dedicado a las actividades relacionadas con los procesos y prcticas. El IDEALSM 1.0 modelo de proceso de software de mejora del programa del ciclo de vida (McFeeley 1996) contiene un modelo de proceso dedicada para las actividades de mejora de procesos software. El IDEALSM 1.0 modelo est diseado como una gua para la ejecucin de un programa de mejora y por esa razn las actividades se agrupan segn el momento en que tendr lugar en la secuencia desde el inicio hasta la finalizacin del programa. Todas las actividades identificadas en el modelo estn relacionados con la SPE.

La ISO 12207 (ISO / IEC 1995) es una norma vigente para los procesos de ingeniera de software. Este modelo pretende ser un modelo de referencia de arquitectura comn y tiene como objetivo proporcionar un conjunto completo de software para los procesos de ciclo de vida. No especifica cmo las actividades se llevan a cabo. El modelo proporciona una visin esttica de los procesos y tiene cuatro niveles de arquitectura, que son de arriba hacia abajo: Categoras de procesos, procesos, actividades y tareas. Los procesos relacionados con el SPE se han agrupado en categora "Procesos en la organizacin del Ciclo de Vida", en "mejorar " el proceso. El Manos a la Obra-el mtodo para la evaluacin de proceso de software incluye una arquitectura de procesos de software para apoyar las actividades de evaluacin. La ltima versin - versin 3.0 - de este mtodo (Manos a la Obra Instituto 1997) no est disponible en cualquier publicacin en particular a partir de este escrito. Un modelo anterior ha sido publicada en un libro "Software Proceso de Evaluacin y Mejora - El enfoque de Manos a la Obra "(. Kuvaja et al 1994), pero el modelo de proceso ha sido objeto de una extensa revisin, ya que se ha alineado con una versin borrador de la norma ISO 15504 modelo de referencia de proceso a partir de 1996 (ISO 15504-2 v. 2.0 (ISO / IEC 1996a), pero ver tambin ms adelante para el anlisis de la versin de 1998 de la norma ISO 15504 (ISO / IEC 1998a)). El modelo de Manos a la Obra para los procesos de software es un modelo de proceso de arquitectura de capas que proporciona una visin esttica de los procesos, en lugar de describir un flujo de proceso o una secuencia de los procesos identificados. La arquitectura de procesos divide en tres categoras, dos de los cuales (Organizacin, Tecnologa) tienen una capa debajo de ellos y la tercera (metodologa) tiene dos capas. Procesos relacionados con el SPE existen en las tres categoras, especialmente en los "procedimientos relacionadas con el proceso", bajo la subcategora "Metodologa" de categora. La norma ISO prxima para la evaluacin de proceso de software, ISO 15504, contiene un amplio proceso de software de modelo de referencia, que se presenta en la norma ISO 15504-2: Un modelo de referencia para los procesos y la capacidad del proceso (ISO / IEC 1998a) detalle, y ms en la norma ISO 15504-5: Un modelo de evaluacin y orientacin indicador (ISO / IEC 1998b). El material no tiene en el momento de escribir estas lneas ha publicado como una norma ISO oficial, por lo que el anlisis est basado en una propuesta de 1998, que ha estado disponible para fines de investigacin y comentarios de las instituciones que participan en los trabajos de normalizacin. El modelo proporciona una arquitectura esttica, el proceso de tres capas, donde las capas son (de mayor a menor) Categora, Proceso, y la base de la prctica. La intencin implcita es cubrir todos los procesos de ingeniera de software con el fin de proporcionar una buena base para la comparacin de diferentes mtodos de evaluacin de software de proceso. Est destinado a ser utilizado como una referencia que identifica los procesos elementales que se pueden combinar y vinculados en una serie de formas y por esta razn no crear conexiones entre los procesos para definir algn tipo de flujo del proceso. El modelo de referencia ISO 15504 se ha alineado con el del modelo ISO 12207, y con el fin de establecer un sistema de SPE estos dos modelos se puede considerar la misma. Los procesos relacionados con el SPE se han agrupado en la categora Organizacin de Procesos. La futura norma ISO 15504 contiene tambin otro modelo de proceso de software, presentado en la norma ISO 15504-7: Gua para su uso en mejora de procesos (ISO / IEC 1998c). Este modelo est pensado para guiar la ejecucin de un programa de software de mejora de procesos y define un conjunto de actividades de mejora de procesos que tienen lugar en el ciclo de vida del programa. El modelo ha sido en gran

parte basado en el modelo 1.0 IDEALSM con fines similares y al igual que su parangn, tambin la norma ISO 15504-7 modelo de actividad se describen las actividades de acuerdo a su lugar en el flujo de los acontecimientos desde el principio hasta el final del programa. Todas las actividades identificadas se relacionan con la SPE. Tambin hay una serie de modelos destinados principalmente para orientar la ejecucin de un nico recurso de SPI. Al igual que IDEALSM 1.0 e ISO 15504 a 7 (por tanto, ver arriba) en la forma, estos modelos de accin de mejora del ciclo tienden a ser mucho ms simple y poner menos nfasis en cuestiones como la gestin de la iniciativa de mejora en s o el establecimiento de planes a largo plazo. Ellos no se preocupan por el alcance de las actividades de mejora de mltiples y no apoyar la iniciacin y mantenimiento del programa de SPI (Debou 1997). Estos modelos suelen identificar por lo menos las tres actividades principales siguientes: Evaluacin, Planificacin, y efectuar. El orden de las actividades, as como la forma en cmo las actividades se han dividido o combinado o difiere de un modelo a otro. Evaluar el proceso se determina cules son los problemas, cmo ha afectado a la mejora del proceso, o lo que es el marco para la implementacin de los modelos existentes. La planificacin de las mejoras que incluye tanto la definicin de objetivos a largo plazo para el rendimiento del proceso, as como los planes de mejora en particular. Efectuar el cambio en el proceso incluye el diseo, implementacin y mantenimiento del cambio. Dado que estos modelos slo tienen una visin muy limitada para las actividades de la SPE, que no se consideran como referencias clave, pero el Los ms notables son los siguientes en aras de la exhaustividad. La lista no es en ningn orden en particular: Plan-Do-Check-Act (PDCA) (Shewhart 1931) Paradigma del Mejoramiento de la Calidad (PMC) (por ejemplo, Basili y McGarry 1998) Proceso de cambio efectivo (Humphrey, 1989) El enfoque de IAM (Pulford et al. 1996) Primer proceso (Karjalainen et al. 1996) Mejora de procesos Paradigma (Dion, 1993). Resumen comparativo de modelos de procesos Si bien una serie de modelos de procesos de software existentes, que abordan el tema desde ngulos muy diferentes. Cada modelo est estructurado de acuerdo a su finalidad prevista, y por esa razn una comparacin entre los modelos es difcil. Hay dos objetivos principales para los modelos que figuran en el captulo anterior: las destinadas a proporcionar una gua para la realizacin de un proyecto de mejora, ya sea un programa o una sola accin, y las destinadas a apoyar las evaluaciones de proceso. Los modelos incluidos en el primer grupo son los IDEALSM 1.0, ISO 15504-7, y los modelos de accin de mejora del ciclo. Los modelos pertenecientes a este ltimo grupo son los SW-CMM 1.1, Trillium 3.0, 3.0 Manos a la Obra, y la ISO 15504 modelo de proceso de referencia. Adems, la ISO 12207 se puede considerar que representan un tercer propsito, ya que est previsto como una norma que defina las actividades de un sistema de desarrollo de software tiene que establecer. Sin embargo, como se mencion anteriormente la norma ISO 15504 se ha alineado con la norma ISO 12207 y ISO 15504 ya que es ms reciente y tiene un modelo de proceso ms amplio, se considera aqu un superconjunto de la norma ISO 12207 y el ltimo no es objeto de mayor anlisis. Los modelos que tienen la intencin de guiar a un objetivo del proyecto de mejora en la definicin de la forma de proceder en la ejecucin del proyecto, y por esa razn

hincapi en la secuencia de actividades y el flujo de informacin de una actividad a otra. Los modelos de proceso de apoyo a estas directrices tienen el objetivo principal de definir los procesos que pertenecen a ese ciclo de la accin y los modelos de siempre agrupar las actividades segn su lugar en el ciclo. Estos modelos suelen ser tambin acompaada con una descripcin de la infraestructura para un proyecto. Los mtodos de evaluacin de proceso como objetivo determinar la madurez del proceso de la organizacin de destino de ingeniera de software. Los modelos de proceso de apoyo a estos mtodos tienen el objetivo principal de definir los procesos que son esenciales para la ingeniera de software, y por esa razn deben ser evaluados (Kinnula 1995a, 28-30). Como tales, tienden a centrarse en la identificacin de procesos como entidades estticas, en lugar de construir vnculos entre los diferentes procesos y la definicin de un flujo de actividades. Cmo los procesos se han presentado vara. Por ejemplo, los enfoques SW-CMM 1.1 los procesos desde la perspectiva de la madurez y se divide el mismo proceso en diferentes niveles de madurez, mientras que las caractersticas en el modelo de referencia ISO 15504 de la arquitectura de procesos y la madurez se han separado de los dems, ambos modelos estn en su derecho propio. Trillium 3.0 est ms cerca de SW-CMM 1.1 en este sentido, mientras que Manos a la Obra 3.0 est ms cerca de la norma ISO 15504. Como los modelos de procesos genricos, estos no suelen describir una infraestructura necesaria para hacerlos operativos. Desde el punto de vista se establece un sistema de SPE, la fuerza del primer grupo es su enfoque en las actividades de la SPE, y el vnculo con los modelos de infraestructura. Sin embargo, suponiendo que la ingeniera de proceso puede incluir tambin algo ms all de la mejora de los modelos son potencialmente un enfoque demasiado estrecho. Con los modelos de ciclo de mejora de accin esto ya es claramente el caso y el riesgo que existe con los modelos del programa del ciclo de vida tambin. Otro problema es que un sistema de SPE es ms como una organizacin permanente como una unidad de desarrollo de software - y proyectos de mejora son las actividades dentro de ese sistema, una vez ms, como los proyectos de desarrollo de productos dentro de una unidad de desarrollo de software. As, los modelos en el primer grupo no slo son potencialmente estrecho, pero tambin tienen alcance equivocado y arquitecturas inadecuado proceso, ya que describir un flujo de acciones y asumir un sistema con una vida finita-ciclo. Los modelos de procesos en el segundo grupo estn ms cerca de lo que se necesita cuando la creacin de un sistema de SPE. Sin embargo, hay claras diferencias entre los modelos de procesos en este grupo. La arquitectura de los SW-CMM 1.1 y 3.0 Trillium hace difcil de usar, ya que no se identifican los procesos, sino ms bien caractersticas de un sistema en diferentes etapas de madurez, lo que hace a veces difcil decidir cules son los procesos que hay. El bootstrap 3.0 y ISO 15504 modelos de referencia que, por otra parte, una muy adecuada enfoque arquitectnico, ya que las actividades grupales de acuerdo al propsito de la actividad. El problema principal con los modelos de procesos que apoyan las evaluaciones proceso es que es probable que se identifican slo aquellos que se consideran importantes desde la perspectiva de la madurez determinacin. La razn de esto es que el nmero de elementos para medir tiene que ser limitado con el fin de ejecutar la accin de medicin en un tiempo razonable (Kinnula 1995a, 28-33).

Puesto que el propsito de las evaluaciones es determinar el estado del proceso de desarrollo de productos, el riesgo es que pasan por alto las actividades de la SPE. Otro problema es el hecho de que estos modelos tratan de cubrir el campo de ingeniera de software completo y las actividades de la SPE deben ser filtradas del modelo. Tambin la falta de un vnculo a un modelo de infraestructura de apoyo es una debilidad desde la perspectiva de establecer un sistema de SPE. Comparando todos los modelos desde la perspectiva de establecer un sistema de SPE, el modelo de referencia ISO 15504 proceso es quizs el ms adecuado para el propsito. Es el ms reciente y ms extenso de todos los modelos de procesos figuran en esta lista, al igual que en la prctica todas las organizaciones detrs de los modelos de otros procesos han estado participando en el esfuerzo de definir el estndar ISO 15504. Tambin se ha alineado con el estndar ISO 12207 y por lo tanto se puede considerar que incorporar todo lo que est en la norma ISO 12207. Sin embargo, la falta de un enlace a cualquier modelo de infraestructura significa que la persona responsable de establecer el sistema debe buscar en otra parte y combinar varios modelos. Modelos de infraestructura SPE El modelo de infraestructura a largo plazo se utiliza aqu para referirse a los modelos que identifican y describen los elementos que son necesarios para apoyar la ejecucin de las actividades en un sistema de SPE. El modelo puede o no puede describir las actividades que apoya, pero cuando lo hace puede ser considerado como un modelo del sistema. En la prctica todos los modelos figuran en esta lista, con la excepcin de SW-CMM e ISO 15504-7 1.1, son los modelos de sistema, pero, como se ver, estn limitados en su alcance. Aparte de la norma ISO 15504 a 7 de materiales, los modelos que figuran en este captulo se han hecho pblicos, aunque el modelo de fbrica La experiencia no tiene una publicacin definitiva y el lector puede ser necesario utilizar varios artculos para obtener una imagen clara de l. Todos los modelos conocidos se presentan a continuacin. Modelos de las principales infraestructuras El modelo Experience Factory (e.g. Basili & McGarry 1998) tiene quizs el ms largo de la historia de los modelos presentados aqu. Se trata principalmente de un modelo de organizacin, sino que tambin identifica ciertas herramientas y mtodos necesarios para apoyar las actividades, y define el proceso (QIP - Mejoramiento de la Calidad paradigma, que es una accin de mejora del modelo de ciclo), que el sistema de fbrica experiencia ejecuta. El modelo de organizacin identifica tanto el elemento operativo y el elemento de los clientes del sistema. El modelo en s es presenta como un modelo de implementacin, es decir, se describe el diseo del sistema, en lugar de identificar los elementos fundamentales de un sistema de SPE y en una fuente de apoyo elemento tambin se identifica como una entidad separada (Basili y McGarry 1998, 51). Los estados de material explcitamente, que la fbrica de experiencia es de apoyo a la reutilizacin de la experiencia local (Basili 1994, 47, 49) y pretende ser un modelo para la infraestructura local, a diferencia de la infraestructura en toda la empresa. Ya que incorpora el ciclo de proyectos de efecto rpido, tambin puede ser considerada como objetivo principal apoyar las acciones individuales de mejora. El modelo de sistema de SPE se presentan en versin IDEALSM 1.0 (McFeeley 1996) describe un ciclo de programacin SPI (modelo de proceso), junto con un modelo de una organizacin de la SPE.

El modelo de organizacin describe los elementos operativos del programa de mejoramiento, incluyendo la gestin. El modelo tambin proporciona algunas indicaciones sobre las caractersticas y competencias que se esperan de los individuos que participan en las actividades de la SPE. El modelo se centra en la descripcin de un programa de proceso (individual) y la mejora de su ejecucin y es claramente un modelo de implementacin, que describe el diseo de dicho programa. El material declara explcitamente que el modelo est destinado a los programas a nivel de organizacin (local) (McFeeley 1996, 8), aunque el modelo de organizacin identifica corporativa (global) las entidades de nivel tambin. La prxima serie ISO 15504 incluye un programa de SPI del ciclo de vida del modelo, en parte, 15504-7 (ISO / IEC 1998c). Esta parte de la norma tambin se dan algunas indicaciones de qu tipo de entidades organizativas participan en dicho programa. Las entidades, sin embargo, describe desde la perspectiva de la responsabilidad de gestin nica, y la descripcin no es destinados a ser utilizados como un modelo de organizacin. Por esta razn, es posible que el material no identifica todas las entidades organizativas indispensables, pero que reconoce algunos de los elementos ms all de la parte dispositiva del programa de mejora. Otros elementos de apoyo posible, no se discuten en el material y el modelo es fundamentalmente un modelo de proceso en lugar de un sistema o modelo de infraestructura. Al igual que con IDEALSM 1.0, la norma ISO 15504-7 tambin se centra en un programa de mejoramiento (individual) y no describe la infraestructura de SPE o los procesos ms all del mbito de aplicacin de dicho programa. El SW-CMM 1.1 (Paulk et al. 1993a, b) no tiene una infraestructura independiente o modelo de proceso para las cuestiones de la SPE, pero s identificar los factores de proceso de institucionalizacin. Estas son descripciones abstractas de los elementos necesarios para apoyar el funcionamiento de cualquier proceso, lo que lgicamente tambin los procesos de la SPE. Los factores de institucionalizacin se describen a travs de caractersticas comunes. La "capacidad de realizar" caracterstica comn tiene la mayora se centran en entidades como la infraestructura-, pero todas las caractersticas comunes de otros tambin identificar algunos elementos necesarios para apoyar las actividades del proceso. El SW-CMM 1.1 no es un modelo de implementacin, ya que no presenta un diseo para, por ejemplo organizacin, sino ms bien un modelo ms abstracto, ya que identifica "las funciones y responsabilidades" (equivalente a la organizacin) como un elemento necesario. Sin embargo, no es un modelo de arquitectura genrica para un sistema de SPE, puesto que la modelo no tiene por objeto apoyar el establecimiento de un sistema, sino para describir los diferentes niveles de madurez de la ingeniera de procesos de software en general. El libro "Software Process Improvement - Gua prctica para el xito Empresarial" (Zahran 1998) contiene un modelo de una infraestructura para la mejora efectiva del proceso software. Aunque tal vez menos conocido que los otros modelos, el libro se centra en el establecimiento de un sistema de SPE y por esa razn, es una referencia importante. El libro aborda el tema en primer lugar, describir los elementos de

infraestructura fundamental y por eso se acerca mucho a ser un modelo de arquitectura genrica para el sistema de SPE. Adems, incluye un modelo de implementacin para el sistema de SPE. El modelo presentado en el libro describe la organizacin y la infraestructura tcnica, los cuales estn fuertemente influenciados por los modelos CMM-relacionados. El mbito de aplicacin del modelo de organizacin se limita a la organizacin operativa. El modelo tambin identifica los niveles de organizacin en la que un sistema de SPE debe residir, y describe las caractersticas y objetivos de las actividades de la SPE de las diferentes capas. Tambin hay algunos indicios de las actividades que el sistema debe admitir, pero estos han sido slo brevemente la lista y no se describe, por lo que no se puede considerar que son un modelo de proceso. Resumen comparativo de modelos de infraestructura Casi todos los modelos presentados anteriormente son en realidad modelos de sistemas de SPE, pero la mayora de ellos tienen un alcance muy limitado ya que se centran en proyectos de mejora solamente, y no en el sistema entero de la SPE. Estos modelos estn tan estrechamente ligado al proceso de mejora del ciclo de vida que son difciles de utilizar para la creacin de un sistema de SPE, que se parece ms a una organizacin permanente de una entidad en proyectos similares. Modelos de organizacin en su mayor parte slo se describen los elementos operativos, es decir, aquellos particip activa y directamente en la labor de la SPE. Los modelos tambin suelen ofrecer slo un modelo de implementacin, pero los bloques de construccin ms fundamental se puede discernir mediante el anlisis de los modelos y el aumento del nivel de abstraccin. Cuando se hace esto, parece que los modelos tienen diferencias incluso en el nivel ms fundamental. Casi todos los modelos presentados anteriormente son en realidad modelos de sistemas de SPE, pero la mayora de ellos tienen un alcance muy limitado ya que se centran en proyectos de mejora solamente, y no en el sistema entero de la SPE. Estos modelos estn tan estrechamente ligado al proceso de mejora del ciclo de vida que son difciles de utilizar para la creacin de un sistema de SPE, que se parece ms a una organizacin permanente de una entidad en proyectos similares. Modelos de organizacin en su mayor parte slo se describen los elementos operativos, es decir, aquellos particip activa y directamente en la labor de la SPE. Los modelos tambin suelen ofrecer slo un modelo de implementacin, pero los bloques de construccin ms fundamental se puede discernir mediante el anlisis de los modelos y el aumento del nivel de abstraccin. Cuando se hace esto, parece que los modelos tienen diferencias incluso en el nivel ms fundamental. La Experience Factory La Fbrica de experiencia identifica proceso, organizacin y tecnologas (herramientas y mtodos). Sin embargo, la parte de tecnologa se describe en un lugar poco a poco la moda y la falta de una publicacin definitiva dificulta an ms la accesibilidad y la utilizacin de este modelo en el establecimiento de un sistema de SPE. El modelo tambin se destina para uso local, principalmente para acciones individuales de mejora, y es un modelo de implementacin. Todo esto hace que en lugar de poco alcance para los fines de establecer un sistema de la SPE, especialmente en entornos multi-sitio. El modelo de organizacin se centra en la organizacin operativa, pero se puede considerar para identificar dos organizaciones no-operativa (de los clientes,

organizacin de apoyo) as, aunque el primero se discute slo en la medida de sus responsabilidades de la SPE. El IDEALSM 1.0 modelo identifica de procesos, organizacin, competencias y requisitos de fondo para la dotacin de personal las personas del sistema de SPE. Las tecnologas no se discuten, pero el modelo se reconocen dos niveles de organizacin (nivel de organizacin - a nivel corporativo). Se trata de un modelo de aplicacin, destinada a un programa de mejora en lugar de un sistema de SPE todo, y por eso es demasiado estrecho en su alcance a los fines de establecer un sistema de SPE. Tambin se destina para uso a nivel local, lo que reduce an ms su utilidad para la creacin de un sistema multi-sitio de la SPE. El modelo de organizacin identifica slo la organizacin operativa. La norma ISO 15504-7 modelo identifica proceso y da algunos, pero muy limitado, para la organizacin. Otros aspectos de la infraestructura no se discuten. El modelo de alegaciones para ser escalable (es decir, aplicables tambin en entornos multi-sitio). Sin embargo, como IDEALSM 1.0, sigue siendo destinado a un programa de mejora solamente, y tiene los mismos inconvenientes para los fines de establecer un sistema de SPE. La atencin se centra en una organizacin operativa, sino una entidad de cliente se puede discernir tambin. El SW-CMM 1.1 da las indicaciones de ambos procesos y elementos de la infraestructura, el ltimo de los cuales incluye la organizacin, las herramientas y mtodos, habilidades y otros aspectos relacionados con las personas, y documentacin de procesos. Sin embargo, todos estos se describen muy brevemente y no hay ni un modelo de proceso propiamente dicho ni un modelo de infraestructura adecuada. El SW-CMM tiene como objetivo proporcionar un plan de mejora y la forma en que se ha estructurado hace difcil que se utilizarn en el establecimiento de un sistema de SPE. No existen modelos de organizacin en SW-CMM 1.1. El nico modelo que se ha desarrollado con todo el sistema de SPE en cuenta es presentada por Sami Zahran. Este modelo identifica la organizacin, las herramientas y mtodos, y documentacin de procesos, y tiene un modelo muy claro y bueno de las capas de organizacin en la que el sistema de la SPE debe residir. Tambin proporciona una arquitectura abstracta de un sistema de SPE, as como un modelo de implementacin o el diseo para este sistema. Sin embargo, el material carece de un modelo de proceso y el diseo de la herramienta y el mtodo de parte de la infraestructura es un tanto confusa. Tambin hay algunas discrepancias internas en el modelo de aplicacin para la organizacin de la SPE, as, y lo identifican slo las entidades operativas.