Christian A. Estay-Niculcar's research blog

Espacio de reflexión personal dedicado a la investigación aplicada cuando se vincula la ciencia proyectual con la disciplina informática, y se aplican al desarrollo de las personas y de la gestión empresarial.

Ingeniería del Proyecto: DEFINICIÓN DE LOS ESCENARIOS PARA PROYECTOS DE MEJORA AL PROCESO DE SOFTWARE: PERSPECTIVA ORGANIZACIONAL

Paper publicado en:

______________________________________Definición de los escenarios para proyectos de mejora al proceso de software: perspetiva organizacional

Abstract

Software companies are provided in the Software Process Improvement (SPI), a strategy to enter global markets more competitive. However, SPI projects are introduced in companies without considering the organizational context and the motives behind this initiative. This study aims to define the characteristics that describe the stages of software companies, from the organizational point of view, before the project proposals to the Process Improvement Software. We review the paradigms and organizational models that have influenced the scenarios to implement the Change Management Process Software, studies and trends considering the property of software companies with a focus on Small and Medium Enterprises (SMEs) of software. It develops an argument for the creation of an organizational structure to serve as a basis for both companies have initiated, such as addressing themselves to make the formalization of a proposed change to the process of software development process. The conclusions and references end the paper.

Keywords: Software Process Improvement; Organizational setting; Project Software Process Improvement

Resumen

Las empresas de software han previsto en la Mejora al Proceso de Software (MPS), una estrategia para entrar en los mercados globales con mayor competitividad. Sin embargo, los proyectos MPS son introducidos en las empresas sin considerar el contexto organizacional y los motivos que impulsan esta iniciativa. Este estudio pretende definir las características que describen los escenarios de las  empresas productoras de software, desde el punto de vista organizacional, ante las propuestas de proyectos de Mejora al Proceso de Software. Se revisan los paradigmas y modelos organizacionales que han tenido influencia en los escenarios para implantar la Gestión del Cambio al Proceso de Software, los estudios realizados y las tendencias actuales considerando la característica de empresas de software con especial atención a las Pequeñas y Medianas Empresas (PyMEs) de software. Se desarrolla una discusión para la conformación de una estructura organizacional que sirva de fundamento para las empresas que tanto han iniciado, como las que se avocan a realizar la formalización de una propuesta de proceso de cambio al proceso de desarrollo de software. Las conclusiones y las referencias finalizan el documento.

Palabras clave: Mejora al Proceso de Software; Escenario organizacional; Proyectos de Mejora al Proceso de Software

1. Introducción

Las empresas de software son un componente altamente relevante en la cadena productiva global de la sociedad basada en la información, el conocimiento y la comunicación (Begg y Caira, 2012). Dentro de ellas, las pequeñas y medianas empresas (PyMEs) constituyen un eslabón importante en el tejido económico mundial. Una revisión anual de desempeño de la estrategia EUROPA 2020 (EC, 2010) para el año 2009 reveló que el 99,8% de todas las empresas europeas son PyMEs, y son responsables de contribuir más de la mitad del valor agregado bruto total de las empresas en la Unión Europea. En muchos países, las empresas de software son clasificadas como PyMEs por lo tanto es necesario fortalecerlas con  prácticas adecuadas para gestionar las tecnologías que aporten valor a sus procesos de software (Kautz, 2000; Bjrønson, 2007).

Las empresas dedicadas a la industria del software mantienen revisiones de su proceso de desarrollo de software por la presión de dos factores  (Humphrey, 2001; Bru et. al., 2009):

  • Exigencias propias del proceso y/o,
  • Condiciones del entorno.

Estas revisiones, llamadas ajustes, se realizan mediante diferentes figuras tanto operativas como estratégicas, denominadas:

  • Mejora al Proceso de Software (SPI, Software Process Improvement),
  • Certificación mediante modelo de la industria (Certification Process), y
  • Proceso de Cambio al Proceso de Software (PdC al PdS).

En décadas pasadas, la gestión del cambio al Proceso de Software se ha realizado mediante la Dirección de Informática a través de diferentes estructuras organizacionales (Allison y Merali, 2007). Los enfoques que prevalecen son los dirigidos desde el Proceso de Negocios (Berrocal, García y Murillo, 2007).  No obstante, la gestión de un programa de cambio para el Proceso tiene sus orígenes en las estructuras de administración empresarial, ampliamente experimentadas en las grandes, medianas y pequeñas empresas.

El trabajo se organiza de la siguiente manera:

  • Se revisan los paradigmas y modelos organizacionales que han tenido influencia en los escenarios para implantar la Gestión del Cambio al Proceso de Software, con el fin de mostrar cómo se puede formalizar y cómo se puede introducir en empresas en general y en PyMEs en particular.
  • Se discute sobre los criterios de conformación de una estructura organizacional que sirva de fundamento para las empresas que tanto han iniciado, como las que se avocan a realizar la formalización de una propuesta de proceso de cambio al proceso de desarrollo de software.
  • Se aportan conclusiones y referencias.

2. De la Gestión del Proceso de Cambio (PdC) al Proceso de Software (PdS)

En 1989, Watts Humphrey aseguró que la gestión de un plan de Mejora al Proceso de Software (SPI, Software Process Improvement) debe ser asignado a una unidad de la organización. Posteriormente, estudios realizados por Krasner y Ziehe (1995) concluyen y delimitan los factores que condicionan el éxito de la gestión del cambio:

  • Carencia de ingenieros  y administradores del proceso de cambio
  • La falta de compromiso de los directivos
  • La definición y coordinación de metas de calidad
  • La falta de prioridad del proceso de cambio
  • Falta de enfoque en el cambio
  • Falta de voluntad y disciplina en el cambio
  • El seguimiento característico para la evaluación del cambio.

Más tarde, se promovió la idea que SPI debía ser organizada como un proyecto con los detalles y la organización necesaria para llevarlo a cabo (Johansen y Mathiassen, 1998).

2.1. Modelos de mejora de procesos

Un modelo genérico para el cambio organizacional en un Proyecto de Mejora al Proceso de Software fue propuesto  por  Stelzer y Mellis (1999).  El análisis efectuado se fundamenta en el ciclo “Plan-Do-Check-Act” (Planificar-Hacer-Controlar-Actuar) descrito por Edward Deming. El análisis inicia con una evaluación de la situación actual (Análisis del Proceso) de la organización, establece un plan (Proceso Planeado), se llevan a cabo las mejoras (Cambio del Proceso) y se miden los resultados. Este proceso se realiza de forma iterativa hasta alcanzar el objetivo deseado (Proceso Nuevo) (ver Figura 1).

Figura 1. Modelo genérico de cambio organizacional en un SPI (Fuente: adaptado de  Stelzer y Mellis, 1999)

Figura 1. Modelo genérico de cambio organizacional en un SPI (Fuente: adaptado de  Stelzer y Mellis, 1999)

Figura 1. Modelo genérico de cambio organizacional en un SPI (Fuente: adaptado de Stelzer y Mellis, 1999)

Goldenson y Herbleb (1995) realizan un estudio a partir de que algunas empresas se quejan de necesitar más guía al momento de implementar un paso de PdC al PdS.  En el estudio citado se presentan hallazgos y necesidades que simplemente denotan la falta de la estructura organizativa:

  • Monitoreo de la alta gerencia de la iniciativa de cambio
  • Una asignación clara y compensada de responsabilidades en el proceso de mejora
  • Promover la participación  de las personas involucradas en el proceso de cambio
  • La participación del personal técnico.

En la búsqueda los factores de éxito para la gestión de cambio, Stelzer  y Mellis (1999) incluye la participación del personal técnico. Esto genera el conflicto que si a las tareas, actividades y responsabilidades que ya se tienen se les agrega el cambio a un proceso, el compromiso es mínimo. Surge la alternativa de hacer un balance en el tiempo dedicado a las tareas cotidianas y las de gestión del PdC al PdS.  De otra manera,  se incrementa el rechazo a toda actividad relacionada al proceso de mejora.

El Instituto de Ingeniería de Software de la Universidad Carnegie Mellon propuso IDEAL (Initiating, Diagnosing, Establishing, Actioning y Leveraging), un modelo que provee un ciclo continuo a través de los pasos necesarios para implantar una mejora al proceso de software (McFeeley, 1996). Este modelo incluye una ruta de acciones para llevar a cabo el cambio mediante el Modelo de las Capacidades de la Madurez [1] (CMM, Capabilities Maturity Model). El modelo IDEAL, considera de igual importancia, tanto  la infraestructura para la implementación como el papel de la gente en el éxito o falla de una iniciativa de Mejora al Proceso de Software.

Figura 2. Modelo IDEAL para la gestión del Cambio (Fuente:  McFeeley, 1996)

Figura 2. Modelo IDEAL para la gestión del Cambio (Fuente:  McFeeley, 1996)

Figura 2. Modelo IDEAL para la gestión del Cambio (Fuente: McFeeley, 1996)

En la actualidad, la formalización de la propuesta de un Proceso de Cambio (PdC) al Proceso de Software (PdS) sigue siendo una situación que genera incertidumbre, especialmente en la delegación de responsabilidades y asignación de los recursos.

2.2. Formalización del cambio en las organizaciones

Las organizaciones de software han sostenido una estructura de trabajo en la cual intervienen y se combinan 3 equipos de trabajo con el fin de realizar revisiones y ajustes al Proceso de Software: SEPG[2] (Software Engineering Process Group, SCM [3] (Software Configuration Management) y  SQA[4] (Software Quality Assurance).  La Figura 3 muestra tres posibles estructuras organizacionales (A, B, C), en las cuales la Dirección de Informática es la dirección ejecutiva a la que responde cualquiera entidad bajo su responsabilidad.

Figura no. 3. Estructuras para la Gestión del Cambio al Proceso de Software

Figura no. 3. Estructuras para la Gestión del Cambio al Proceso de Software - (c) Nilda Yanguez  & Christian A. Estay-Niculcar

Figura no. 3. Estructuras para la Gestión del Cambio al Proceso de Software – (c) Nilda Yanguez & Christian A. Estay-Niculcar

Estudios diversos han analizado el rol de SEPG, SCM y SQA para mejorar el funcionamiento y valor añadido del PdC.

A.- SEPG (Software Engineering Process Group)

De la revisión de literatura se observa en general que un equipo de SEPG es más adecuado para liderar el trabajo en cualquier estructura organizacional. Esto ya lo reportaba Humphrey (1990) quien señaló que era relevante contar con una oficina central del SEPG respondiendo a la Gerencia General, con pequeñas oficinas de enlace bajo la responsabilidad de cada gestor de negocios, asumiendo su propio plan de mejora. Según el estudio de Humphrey, la  incorporación del  SEPG al organigrama departamental sería factible para grandes corporaciones que casi siempre poseen presupuestos para hacerlo.

Para una PyME este escenario sería costoso y una estructura difícil de sostener. En cambio, se puede mantener la oficina de SEPG rindiendo cuentas a la gerencia general y una persona de contacto en cada área de negocios, si fuera necesario, estableciendo el mecanismo de coordinación adecuado para llevar a cabo un plan general de mejora, integrado, de toda  la empresa (ver Figura 4).

Figura 4. El Grupo de Proceso de Ingeniería de Software (SEPG) y las Áreas de Negocio

 

Figura 4. El Grupo de Proceso de Ingeniería de Software (SEPG) y las Áreas de Negocio - (c) Nilda Yanguez & Christian A. Estay-Niculcar

Figura 4. El Grupo de Proceso de Ingeniería de Software (SEPG) y las Áreas de Negocio – (c) Nilda Yanguez & Christian A. Estay-Niculcar

B.- SCM (Software Configuration Management)

En otro sentido, una oficina de SCM es vista tradicionalmente como la  idónea para manejar los cambios en los proyectos de software y aportar un mapa de ruta para el control de la evolución de sistemas y procesos.  Para efectos de aplicarlo en un proceso de cambio al proceso de software,  SCM puede ser visto como una acción de monitoreo, de identificación y seguimiento en la evolución del proceso de software (PdS0, PdS1, PdS t+1) a fin de documentar y obtener una propuesta de Cambio al Proceso de Software (ver Figura 5).

Figura 5. La Gestión de la Configuración del Software y el monitoreo en la evolución del Proceso de Software - Nilda Yanguez & Christian A. Estay-Niculcar

Figura 5. La Gestión de la Configuración del Software y el monitoreo en la evolución del Proceso de Software – Nilda Yanguez & Christian A. Estay-Niculcar

C.- SQA (Software Quality Assurance)

El Aseguramiento de la Calidad del Software es la función de la calidad del software que asegura que las normas, procesos y procedimientos son adecuados para el proyecto y se ejecutan correctamente. Puede operar en coordinación y colaboración con el equipo de Gestión de la Configuración del Software (ver Figura 6), coordinando el monitoreo y la bitácora de los cambios hasta obtener suficientes evidencias para advertir de la necesidad de algún cambio al Proceso de Software.

Figura 6. Aseguramiento de la Calidad y  la Gestión de la Configuración del Software

 

Figura 6. Aseguramiento de la Calidad y  la Gestión de la Configuración del Software - (c) Nilda Yanguez & Christian A. Estay-Niculcar

Figura 6. Aseguramiento de la Calidad y la Gestión de la Configuración del Software – (c) Nilda Yanguez & Christian A. Estay-Niculcar

D.- PMO (Project Management Office)

Adicionalmente, se ve importante establecer o considerar una Oficina de de Gestión de Proyectos (PMO, Project Management Office) como una alternativa para la gestión de los procesos de cambio en empresas de software.   Es la fuente de documentación de las mejores prácticas para consolidar procesos, y estándares de trabajo. Si se establece la Mejora al proceso de Software como un proyecto, será competencia y responsabilidad de la PMO llevar la iniciativa, control y seguimiento del Proceso de Cambio al Proceso de Software.  La PMO proporciona información a directores de Proyectos, a la Dirección de Informática y a los ejecutivos encargados de la ejecución del proyecto PdC.

La empresa normalizadora Best Business Service ha creado la norma referencia internacional SGE 900:2011 para la Gestión Experta de empresas (Contreras, 2011). Para esta norma  la identificación de los procesos críticos del negocio es vital para la consecución del éxito sostenido de la empresa.  La aplicación de esta norma a las empresas de software pone en evidencia que el proceso de software, crítico para este tipo de negocio, y su proceso de cambio deben disponer de los recursos y la organización apropiados para su gestión.

Los escenarios organizacionales para la Gestión de un Proceso de Cambio al Proceso de Software, son múltiples y variados, sin embargo, la estructura establecida por la empresa debe adherirse a las buenas prácticas de formalizar el proceso, repetible con otros productos y herramientas, reproducible en otros entornos (globalizados), y de fácil adaptabilidad a la cultura organizacional.

3. Discusión sobre el cambio y su impacto en las organizaciones

Para emprender un plan de mejora a un proceso de software, se precisa de  una estructura organizativa que proporcione apoyo a la gestión de cambio.  Los factores que inducen a seleccionar una estructura organizacional específica dependerán de la estructura organizacional de la empresa, las políticas y la visión de sus directivos (Coleman, 2005). Un factor importante es la cultura empresarial, en ella convergen una serie de actitudes y comportamiento de los colaboradores, la percepción que tienen de  los objetivos y metas del negocio, sin restar importancia a la política establecida.

La estructura servirá de apoyo al establecimiento de los mecanismos de coordinación, roles y responsabilidades y  la comunicación entre los involucrados antes, durante y después de la implementación de un Proceso de Cambio al Proceso de Software.  Algunos criterios de preparación para los esfuerzos de un PdC a un PdS señalan claramente la necesidad de un equipo que se encargue de la formalización, gestión, evaluación y validación de un Proceso de Cambio al Proceso de Software (Dyba, 2005) cuya responsabilidad y compromiso se basa en la visión del negocio.

En el caso de que no se cuente con experiencia dentro de la empresa,  es importante la voluntad y la asignación de recursos por parte de  los directivos para la contratación de un proveedor de servicios de mejora al proceso de software. Esto no va en detrimento de la estructura organizativa deseable para la gestión del PdC, en el cual subyacen otro tipo de criterios de preparación: la interacción con el proveedor y con los clientes, las evaluaciones en la búsqueda de ese proveedor, la toma de decisiones y la formación del equipo evaluador.

Las empresas de software deben partir de la premisa que el compromiso y la participación de los afectados en el PdC al Proceso de Software, son las características idóneas para formar parte de la estructura de gestión de esta actividad. Es tarea también de la estructura organizativa, adaptar las iniciativas de mejora a cada departamento (Fowler y Rifkin,  1990) y equipo dentro de la empresa, es decir, qué influencia tendrá el cambio en cada departamento y cómo realimenta la participación de este departamento en el éxito de ese cambio.

La estructura organizacional, para la formalización e implementación de la Mejora al proceso de Software, debe armonizar las acciones correspondientes con las directrices obtenidas de los proceso de cambio, y responder a los diversos enfoques de la necesidad del cambio.  Para empresas de software, por su naturaleza y composición,  es casi nula la evolución de las estructuras organizacionales dispuestas al cambio. La oficina de Gestión del PdC al PdS, es  un escenario ausente en las empresas de software, a pesar que  el modelo estratégico para la gerencia del cambio muestra su importancia debido a la influencia de las fuerzas internas y externas  que impulsan su adopción a corto plazo.

Las estructuras planteadas por el Instituto de Ingeniería de Software generalmente se adecuan a las grandes empresas, a pesar de los múltiples reportes de la escasa viabilidad para las empresas. La estructura funcional y multifuncional (Khokhar, Zeshan y Aamir, 2010), dificulta la introducción de un Proceso formal de Cambio al Proceso de Software. De forma repetida, la figura del consultor externo con muy poca intervención de los involucrados, reemplaza la estrategia de una oficina propia, aunque sea de enlace y dedicada a tiempo completo a la gestión del cambio.

Una empresa hoy en día acepta y reconoce la importancia de los activos informacionales y computacionales. También es cierto que gestionan estos activos como materiales en bruto, no como agentes de cambio y que por tanto debe gestionarse este cambio como un proceso y que el propio proceso de cambio implica cambios en los procesos decisionales. Incorporar estas funciones, tiene un coste organizacional alto en varios niveles:

  • a nivel de recursos humanos pues se incrementa en las personas las variables de decisión y el proceso decisional es un nuevo proceso a considerar;
  • a nivel técnico pues se requiere monitorear los procesos de manera cada vez más automatizada;
  • a nivel económico y financiero pues por un lado se precisan recursos adicionales y por otro lado se deben incluir variables económicas y financieras en decisiones informáticas y computacionales, y,
  • a nivel operativo, pues aparecen procesos de cambio.

Si se habla en concreto de empresas de software, este impacto organizacional adquiere costes que pueden conocerse y beneficios aún insospechados. En PyMEs claramente, es un lujo contar con procesos de cambio pues requieren inversiones que en muchas ocasiones no pueden permitirse.

4. Conclusiones

Una empresa de software requiere de una estructura que abarque la gestión del Proyecto de Cambio  al Proceso de Software, la Gestión de la Configuración, el Aseguramiento de la Calidad al igual que la solución de problemas. De igual importancia son las consideraciones situacionales, económicas y financieras de la empresa al momento de seleccionar la estructura para el cambio.

Para formalizar una estructura organizacional para el PdC al PDS, sus integrantes y sus roles, las empresas de software deben considerar:

  • El liderazgo de su personal
  • Estructura financiera para operar la gestión de cambio
  • Ambiente abierto al cambio o un plan para procurarlo
  • Participación y compromiso de los involucrados
  • Consideración de los factores situacionales de la empresa: experiencias, tamaño del equipo colaborador, costos
  • Modelos de procesos de cambio

Una estructura que se adapte a las características particulares de cada empresa tendrá un gran impacto en el éxito del PdC produciendo un efecto motivador en los colaboradores e impulsándolos a participar en las actividades para alcanzar los beneficios detectados.

5.    Referencias

  • Allison I., Merali Y.(2007). Software Process Improvement as Emergent change: A Structurational Analysis. Disponible en: [https://www. opneair.rgu.ac.uk/bitstream/10059/22011/Allisson*and+Meral*ISTJ+paper+final.pdf]. Consultado el : [22 de marzo de 2012].
  • Begg, C and Caira, T.(2012). “Exploring the SME Quandary: Data Governance in Practise in     the Small to Medium-Sized Enterprise Sector” The Electronic Journal Information Systems Evaluation Volume 15 Issue 1 2012, (pp01 -12), available online at http://www.ejise.com
  • Berrocal J., García J.M., Murillo J.M. (2007). Hacia una gestión del proceso de software dirigida por el proceso de negocios. Disponible en: [http://alarcos.inf-cr.uclm.es/pnis/articulos/pnis-07-Berrocal-GPSDPN.pdf] Consultado el: [15 de julio de 2011].
  • Bjørnson F.(2007).  Knowledge Management in Software Process Improvement. Doctoral Thesis. Norwegian University Of Science and Technology, Norway.
  • Bru F., Frappin G., Legrand L., Merrer E., Piteau S., Salou G., Saliou P., Ribaud V. (2009).    Building and Observatory of Course-of-Action in Software Engineering: Towards a Link between ISO/IEC Software Engineering Standard and a Reflective Practice. EuroSPI, 2009, CCIS 42 pp. 185-200, 2009.Springer-Verlag Berlin Heidelberg.
  • Coleman G., (2005). An Empirical Study of Software Process in Practice, Proceeding of the 38th Hawaii International Conference on system Sciences.
  • Contreras J. (2011). Norma referencial internacional SGE: 900: 2011: Para la Gestión Experta de empresas. Foment del Treball Nacional, Vol. 04 no.2135, 30-36.
  • Dybå T. (2005).  An Empirical Investigation of the Key Factors for Success in Software Process Improvement. IEEE TRANSACTIONS ON SOFTWARE ENGINEERING, vol. 31, no. 5 pp. 410-424.
  • Eaton D. (2002). Configuration Management Frequently Asked Questions. Disponible en: [ http:// http://www.daveeaton.com/scm/CMFAQ.html%5D. Consultado el: [21 de agosto de 2011].
  • EC (European Commission) 2010. European SMEs Under Pressure: Annual Report on EU Small and Medium-Sized Enterprises 2009, Brussels, Belgium: European Commission.
  • EC (European Commission), 2003. Commission Recommendation 2003/361/EC of May 6,   2003. http://europa.eu.int.
  • EC (European Commission), 2010, Europe 2020. A strategy for smart, sustainable and inclusive growth, Communication COM(2010) 2020, Brussels: European Commission.
  • Fowler P., Rifkin S. (1990). Software Engineering Process Group Guide. Technical Report CMU/SEI 90-TR-024 ESD90-TR-225. Software Engineering Institute, Carniege Mellon University, USA.
  • Goldenson D., Herbsleb J. (1995). After the appraisal: A systematic survey of Process Improvement, Its benefits, And Factors That Influence success. SEI, CMU/SEI-95- TR-009 Software Engineering Institute, Carniege Mellon University, USA.
  • Humphrey W. (1989). Managing the Software Process. SEI Series in Software Engineering. Addison Wesley Professional. USA.
  • Humphrey W. (2001). Justifying a Process Improvement. Disponible en: [http://www.sei.cmu.edu/library/abstracts/news-at-sei/wattsmar00.cfm]. Consultado el [10 de diciembre de 2011].
  • Johansen J.; Mathiassen L. (1998).  Lessons learned in a National SPI Effort. EuroSPI’98. Gothenburg, Sweden, 1998.
  • Kautz K.(2000).  Software Process Improvement in Very Small Enterprises: Does it Pay Off? Software Process-Improvement and Practice Software. Pract.  4, 209-226. Disponible en: [http://www3.interscience.wiley.com/cgi   bin/fulltext/70002886/PDFSTART].   Consultado el : [16 de agosto de 2011].
  • Khokhar M., Zeshan K., Aamir J. (2010). Literature Review on the Software Process Improvement Factor in the Small Organizations. Disponible en: [http://ieeexplore.ieee.org/xpl/login.jsp?tp=&arnumber=5488547&url=http%3A%2F%2Fieeexplore.ieee.org%2Fxpls%2Fabs_all.jsp%3Farnumber%3D5488547] Consultado el: [20 de marzo de 2012].
  • Krasner y Ziehe, (1995). Lessons Learned from the Semiconductor Industry Initiative for Improving Software Process, Quality, and Reliability. World Congress for Software Quality, June 20-22, 1995, San Francisco, CA, Vol. 1, No. 0, June 1995, pp. 1-20
  • McFeeley, (1996).   IDEAL SM: A User’s Guide for Software Process Improvement Handbook CMU/SEI-96-HB-001. Software Engineering Institute Carnegie Mellon University Pittsburgh, Pennsylvania 15213, USA. SCAMPI Upgrade Team (2006). Standard CMMI® Appraisal Method for Process Improvement (SCAMPISM) A Version 1.2: Method Definition Document. Software Engineering Institute, Carniege Mellon University, USA.
  • Software Quality Assurance (2005). Software Quality Assurance Definition. Disponible en: [http://www.spa.nasa.gov/office/codeq/software/umbrella.defs.htm]. Consultado el: [21 de agosto de 2011].
  • Stelzer. D., Mellis, W. (1999). Success Factors of Organizational Change in Software Process Improvement, Software Process Improvement Practice, No 4, pp. 227–250.

Para más información contacte con:

Nilda Yangüez Cervantes nilda.yanguez@utp.ac.pa

Christian Estay Niculcar christian.estay.niculcar@gmail.com

Nota Final: La  investigación propuesta en este documento forma parte del proyecto de tesis doctoral de uno de sus autores. La investigación de tesis doctoral es patrocinada por la Secretaría Nacional de Ciencia, Tecnología e Innovación SENACYT de Panamá, República de Panamá.


[1] SCAMPI Upgrade Team (2006). Standard CMMI® Appraisal Method for Process Improvement (SCAMPISM) A Version 1.2: Method Definition Document. Software Engineering Institute, Carniege Mellon University, USA.

[2] Humphrey W. (2001). Justifying a Process Improvement. Disponible en: [http://www.sei.cmu.edu/library/abstracts/news-at-sei/wattsmar00.cfm]. Consultado el: [10 de diciembre de 2010].

[3] Eaton D. (2002). Configuration Management Frequently Asked Questions. Disponible en:[ http:// http://www.daveeaton.com/scm/CMFAQ.html%5D. Consultado el: [21 de agosto de 2011].

[4] Software Quality Assurance (2005). Software Quality Assurance Definition. Dsiponible en: [http://www.spa.nasa.gov/office/codeq/software/umbrella.defs.htm]. Consultado el: [21 de agosto de 2011].

Responder

Introduce tus datos o haz clic en un icono para iniciar sesión:

Logo de WordPress.com

Estás comentando usando tu cuenta de WordPress.com. Cerrar sesión / Cambiar )

Imagen de Twitter

Estás comentando usando tu cuenta de Twitter. Cerrar sesión / Cambiar )

Foto de Facebook

Estás comentando usando tu cuenta de Facebook. Cerrar sesión / Cambiar )

Google+ photo

Estás comentando usando tu cuenta de Google+. Cerrar sesión / Cambiar )

Conectando a %s

CEO & Co-Founder de EstayConsulting – Consultoría Estratégica

Miembro de Red

//pagead2.googlesyndication.com/pagead/js/adsbygoogle.js (adsbygoogle = window.adsbygoogle || []).push({});

Categorías

A %d blogueros les gusta esto: