Proceso de aseguramiento de la calidad para un modelo de la calidad en Cuba
Process quality assurance for a model of quality in Cuba
Yoandy Lazo Alvarado1*, Clariannis Gómez Barroso1, Yaima Mariño Zayas1, Mariela M. Bony Fernández2, Eleydis Agramonte Díaz1, Damaris Batista González1
1Centro Nacional de Calidad de Software (CALISOFT). Calle 17 # 506 entre D y E, Plaza de la Revolución, La Habana. Cuba. C.P.: 10400. {yoandy.lazo, clariannis.gomez, yaima.marino, eleidis.agramontes, damaris.batista}@calisoft.cu
2Universidad de las Ciencias Informáticas (UCI). Carretera a San Antonio Km 2 ½. Torrens. Boyeros. La Habana. Cuba. C.P.: 10400. mmbony@uci.cu ]]>
*Autor para la correspondencia: yoandy.lazo@calisoft.cu
RESUMEN
El aseguramiento de la calidad como parte del proceso de desarrollo de software transmite al equipo de proyecto y al cliente la seguridad y confianza de que el producto final será exitoso. La presente investigación propone un conjunto de requisitos que sintetizan las buenas prácticas de modelos, estándares y normas internacionales además de adecuarse a lo planteado en el Decreto Ley de Perfeccionamiento Empresarial y la Resolución de Control Interno emitida en Cuba. El proceso Aseguramiento de la Calidad (AC) que se obtiene está enfocado a las necesidades actuales de las entidades desarrolladoras de software en Cuba, debido a que puede ser implantado en entidades sin importar su tamaño. Fue diseñado para formar parte de la categoría de soporte del Modelo de la Calidad para el Desarrollo de Aplicaciones Informáticas (MCDAI). La propuesta incluye una descripción gráfica y textual del proceso, que facilita el cumplimiento de los requisitos, así como los roles involucrados y productos de trabajo que se generan de la ejecución del mismo. Se define un sistema de indicadores que permite medir la eficacia y utilidad, además de otros que pueden ser utilizados para brindar una información objetiva al equipo de proyecto y dirección. Este proceso fue sometido a criterio de expertos para comprobar que es una propuesta apta para extender a la industria cubana de software.
Palabras clave: calidad, calidad de software, gestión de la calidad, aseguramiento de la calidad, modelo de la calidad.
ABSTRACT
The quality assurance as part of the software development process transmits the project team and customer safety and confidence that the final product will be successful. This research proposes a set of requirements that summarize good practice models, standards and regulations in addition to adapt to the issues raised by the Decree of Business Improvement and Internal Control issued resolution in Cuba. The Quality Assurance process (AC) obtained is focused on the current needs of software development companies in Cuba because it can be implemented in companies regardless of their size. It was designed to be part of the category of Quality Model for Application Development (MCDAI) support. The proposal includes a graphical and textual description of the process that facilitates compliance with the requirements and the roles involved and work products that are generated from the process execution. A system of indicators to measure the effectiveness and usefulness of the process, along with others that can be used to provide objective information to project teams and address defined. This process was subjected to expert judgment to verify that a suitable to extend to Cuban software industry proposal.
Key words: quality, software quality, quality management, quality assurance, quality model, process.
INTRODUCCIÓN
La industria del software alcanza una posición relevante en el contexto social actual, por su característica de controlar o hacer accesible los adelantos tecnológicos (Hernández, 2009). Destacan los aportes económicos que en el año 2012 sobrepasaron los US $ 255 billones a nivel global (McCaffrey, 2014). También es significativo el aumento del éxito en los proyectos de desarrollo de software a nivel internacional, de un 16% al 39% en el período del 1994 al 2014, pero todavía es relevante el porciento de proyectos cancelados con un 43% y un 18% fallidos (Clancy, 2014).
Cuba no ha estado ajena a este desarrollo por lo que ha realizado varios esfuerzos para potenciar la producción de software. Entre dichos esfuerzos destacan la formación de personal calificado y la creación de organizaciones productoras de software tales como: GET en 1995, deSoft en 1995, TranSoft en 1996, Universidad de la Ciencias Informáticas (UCI) en 2002 y Datys en el 2006, entre otras (GET, 2015; deSoft, 2015; TranSoft, 2015; UCI, 2015; Datys, 2015; (JCCE), 2015)
El desarrollo de software en Cuba hoy en día, está marcado por la actualización del modelo económico y social que vive el país, expresado en los lineamientos 83 y 131 de la política económica y social de la Revolución ((PCC), 2011). En ambos lineamientos se compromete a las organizaciones a brindar mayores aportes a la sociedad. Para ello, los autores de esta investigación concuerdan con Tardío (Tardío et al., 2011) en asegurar, que se requiere organizaciones que tengan ordenados sus procesos, de forma tal que garanticen la eficiencia de sus indicadores de desempeño y satisfaga los requisitos de los clientes con productos y servicios informáticos en el tiempo y con la calidad requerida.
La experiencia alcanzada en estos años permite a los trabajadores del sector preguntarse ¿cómo aumentar la calidad de sus productos de software para insertarse en el mercado internacional y satisfacer la creciente demanda del país? Para solucionar esta interrogante han nacido iniciativas como la materializada por la UCI, para certificar tres centros productivos con el nivel dos de CMMI (Blanco et al., 2012) y la de las empresas AICROS y TranSoft de certificar el Sistema de Gestión de la Calidad según la ISO 9001 ((NC), 2015). Con la misma intención se crea el Centro Nacional de Calidad de Software (CALISOFT) en el año 2012 ((MINCOM), 2012). También sobresale el proyecto de investigación “Modelo de mejora de procesos de software para la industria cubana del software” desarrollado entre la UCI y CALISOFT ((MINCOM), 2015), donde el resultado esperado es la obtención de un Modelo de la Calidad para el Desarrollo de Aplicaciones Informáticas (MCDAI).
Con el objetivo de caracterizar las organizaciones productoras de software en Cuba según su estructura organizativa, los procesos en los cuales basan su gestión y las herramientas que utilizan, se realizó en el año 2014 un diagnóstico a una muestra de catorce (14) entidades. Los resultados obtenidos permiten afirmar que las mismas tienen ((CALISOFT), 2014):
• Bajos niveles de estandarización, por no contar con normas regulatorias de obligado cumplimiento que rijan la producción del software.
• Poca utilización de modelos y normas internacionales. ]]>
• Bajos niveles de madurez de los procesos que a nivel internacional se implementan.
Los autores de esta investigación concuerdan con Montalván (Montalván, 2014) al decir que la Industria Cubana de Software (ICSW) está conformada por pequeñas y medianas empresas (PYME), las que representan más del 50%.
El análisis de los resultados del diagnóstico también permite afirmar que el 85,7% de las entidades diagnosticadas tienen organizada la producción de software con un enfoque a procesos ((CALISOFT), 2014), elemento positivo, aunque no todas alcanzan implementar las mismas áreas de conocimiento. Los procesos que más se siguen en las entidades son: Gestión de proyectos (78,57%), Pruebas de software (71,43%), Ingeniería de requisitos (64,29%), Desarrollo de la solución (64,29%) y Mantenimiento (64,29%). Se identificó además que la menor cantidad de empresas implementan los procesos: Gestión del conocimiento (7.14%), Gestión de adquisiciones (14, 29%), Medición y mejoras (21,43%) y Aseguramiento de la Calidad (AC) (28.57%) ((CALISOFT), 2014).
Teniendo en cuenta lo expuesto anteriormente, se puede afirmar que las áreas técnicas y de gestión de proyecto son las que alcanzan mayores niveles de implementación, mientras que las de soporte y gestión de proceso de la organización son las menos maduras.
Con la intención de profundizar en el área de AC perteneciente a la categoría de soporte, en el diagnóstico mencionado anteriormente se identificaron las actividades que menos se realizan, donde sobresalen: evaluar la adherencia a los procesos definidos (14.29%), evaluar la adherencia de los productos de trabajo que se generan como resultado de la ejecución de los procesos definidos (14,29%), evaluar técnicamente los productos de trabajo antes de formar una línea base (28,57%) y evaluar técnicamente las salidas del diseño del producto (42,86%) ((CALISOFT), 2014).
En base a lo anteriormente descrito se plantea el siguiente problema a resolver: ¿Cómo asegurar la calidad de los procesos y productos de trabajo durante el desarrollo de soluciones ICSW?
Para resolver el problema se plantea como objetivo: Desarrollar el proceso base de AC para el MCDAI, que permita aumentar la calidad de los procesos y productos de trabajo que se generen y brinde una visión objetiva, sobre los mismos, al personal del proyecto y la dirección de la entidad.
MATERIALES Y MÉTODOS
Con el objetivo de identificar las buenas prácticas en la gestión de la calidad en el desarrollo de software se analizaron: la norma ISO 90003 dictadas por la Organización Internacional para la Estandarización, el Modelo de Capacidad de Madurez Integrado para Desarrollo (CMMI-DEV por sus siglas en inglés) desarrollado en Estados Unidos, la Guía de Fundamentos para la Dirección de Proyectos (PMBoK) propuesto por el Instituto de Dirección de Proyectos (PMI por sus siglas en inglés) así como varias iniciativas latinoamericanas como: el Modelo de Procesos para la Industria del Software (MoProSoft) de México, Mejora de Proceso de Software Brasileño (MPS.Br) y la Mejora de Procesos para Fomentar la Competitividad de la Pequeña y Me-diana Industria del Software de Iberoamérica (COMPETISOFT). En la Tabla 1 se muestra el resultado del análisis, constituyendo esta la base para la propuesta de la presente investigación.
]]> En opinión de los autores se requiere elaborar un proceso de AC propio para la ICSW debido a las siguientes razones: en la NC ISO 90003 los requisitos no están asociados a las áreas de conocimiento de la ingeniería de software lo cual dificulta su entendimiento. CMMI-DEV propone las auditorías de la configuración, el control de inconsistencias y las revisiones técnicas en otras áreas de proceso que al implementarlas provocan re-trabajo porque sería necesario definir procesos similares donde intervendrían los mismos involucrados. En los casos de MPS.BR, MoProSoft y COMPETISOFT, al igual que en los anteriormente analizados no se define una propuesta de proceso con los roles asociados, ni las técnicas o herramientas que pueden utilizarse para apoyar el proceso y no existe una propuesta de indicadores a medir. Presentan además un alto costo para la organización en temas de consultoría especializada, esfuerzo necesario para la implementación de las actividades de mejora y la certificación.Con el propósito de que la propuesta se adaptara a las regulaciones vigentes en el país, se hizo necesario analizar el Decreto Ley No. 281/07 – Perfeccionamiento empresarial y la Resolución No. 60/11 – Sistema de Control Interno.
La empresa que quiera implantar el Sistema de Dirección y Gestión (SDG) que define el Perfeccionamiento Empresarial deberá desarrollar 18 sistemas, entre los que se encuentran: el Sistema de Gestión de la Calidad según lo que planeta la ISO 9001 vigente y el Sistema de Control Interno teniendo en cuanta la Resolución No. 60/11. En ambas sobresale la importancia de las auditorías de la calidad, como parte del control y autocontrol, además se indica la necesidad de elaborar un plan para corregir las insuficiencias. Se establece que se deberá realizar un seguimiento adecuado para velar por el correcto cumplimiento del plan y comunicar los resultados al nivel superior y rendir cuenta a los trabajadores (MINISTROS, 2013; CONTRALORÍA GENERAL DE LA REPÚBLICA DE CUBA, 2011).
Como parte de la investigación se analizó la Guía General del MCDAI, la cual plantea que el modelo está conformado por doce (12) proceso bases agrupados en las categorías: Gestión de proceso de la organización, Gestión de proyecto, Ingeniería y Soporte. Cada proceso base tiene requisitos y otros elementos de apoyo (definición del proceso, sistema de indicadores, propuesta de herramientas y mapa de compatibilidad) (Montalván, 2014).
Los requisitos a implementar por cada proceso base dependerán del nivel de madurez que desee alcanzar cada entidad, a continuación, se mencionan los tres niveles posibles (Montalván, 2014):
• Básico: Los proyectos definen los procesos y procedimientos a ejecutar según sus objetivos. Las actividades y productos de trabajo son los indispensables para organizar el proyecto.
• Intermedio: Se analizan los procesos y procedimientos establecidos en los proyectos para su institucionalización en la organización. Se gestionan cuantitativamente los procesos usando técnicas estadísticas y otras de carácter cuantitativo. Se gestiona la capacitación y el conocimiento en toda la organización.
• Avanzado: Se mide el rendimiento de los procesos. La organización mejora continuamente sus procesos basándose en una comprensión cuantitativa de las causas de variación de los mismos. Se gestiona el conocimiento de forma inteligente. Se establecen mejoras tecnológicas.
]]> RESULTADOS Y DISCUSIÓN
Como fruto de la investigación se elaboró el proceso base AC, que tiene como propósito: Proporcionar al personal de un proyecto y a la dirección de una organización, una visión objetiva de los procesos y productos de trabajo asociados, indicando si están en conformidad con los planes, procedimientos y estándares establecidos.
Para cumplir con este propósito se definieron los siguientes requisitos separados por niveles de madurez.
Requisitos para el nivel básico
D 1 Establecer criterios para las evaluaciones.
D 2.2 Evaluar objetivamente los procesos en el proyecto.
D 3.2 Evaluar objetivamente los productos de trabajo en el proyecto.
D 7.1 Registrar y comunicar las no conformidades.
D 7.4 Asegurar la resolución de las no conformidades.
Requisitos para el nivel Intermedio
]]> D 2 Evaluar objetivamente los procesos.Requisitos para el nivel Avanzado
D 6 Evaluar técnicamente los productos de trabajo. ]]> D 6.2 Evaluar técnicamente los productos de trabajo por un grupo externo al proyecto.
Proceso de AC
Como parte de la solución se propone un proceso que facilita a las entidades la implementación de los requisitos; no es de obligatorio cumplimiento sino una guía que se puede adecuar a las condiciones de cada entidad. Figura 1
Descripción textual del proceso AC
1. AC-Planear evaluaciones. Se ejecuta el subproceso AC-Planear evaluaciones. Se obtiene como resultado el Plan de evaluaciones (organización) y el Plan de aseguramiento de la calidad (proyecto).
2. Elaborar/actualizar herramientas para las evaluaciones. El Equipo evaluador/Administrador de la calidad elabora y actualiza las herramientas que utilizará durante la ejecución de cada evaluación, obteniéndose como evidencia las entrevistas, encuestas, listas de chequeo, guía de observación, entre otras.
3. ¿Corresponde ejecutar una evaluación? Si corresponde ejecutar una evaluación ir a la actividad 4 si no se mantiene en la actividad 3.
4. AC-Ejecutar evaluación. Se ejecuta el subproceso AC-Ejecutar evaluación. Se obtiene como resultado el Expediente de la evaluación y el Registro de incidencias y acciones (organización).
5. Identificar causas. El Jefe de proyecto y los Evaluados identifican las causas de las no conformidades, inconsistencias o errores, obteniéndose como evidencia el Registro de incidencias y acciones del proyecto actualizado.
6. Asignar acciones. El Jefe de proyecto establece las acciones necesarias para resolver las no conformidades, inconsistencias y errores. A estas se les asigna el responsable de ejecutarla y la fecha de cumplimiento. Las acciones pueden ser: correctivas, cuando eliminan la causa que le dio origen al problema y lo resuelve, de mejora, cuando se obtiene una mejora de un producto de trabajo o proceso para prever nuevas no conformidades, inconsistencias o errores, de corrección, cuando solamente resuelven el problema, sin tener en cuenta la causa que le dio ori-gen al mismo.
]]> 7. Comunicar causas y acciones. En las evaluaciones internas, el Administrador de la calidad le comunica al Representante de la calidad las causas de las no conformidades, inconsistencias o errores, así como las acciones que las solventarán. En las evaluaciones por terceros al proyecto, el Administrador de la calidad le comunica al Equipo evaluador las causas de las no conformidades, inconsistencias o errores, así como las acciones que las solventarán, y este a su vez, se las debe comunicar al Representante de la calidad. El Representante de la calidad actualiza el Registro de incidencias y acciones de la organización.Se obtiene como evidencia el Registro de incidencias y acciones del proyecto actualizado.
8. ¿Corresponde seguimiento? Si corresponde ejecutar el seguimiento ir a la actividad 9 si no se mantiene en la actividad 8.
9. AC-Seguimiento. Se ejecuta el subproceso AC-Seguimiento. Se obtiene como resultado de la ejecución de esta actividad el Registro de incidencias y acciones (proyecto), el Permiso y el Registro de incidencias y acciones (organización).
10. ¿Corresponde elaborar reporte? Si corresponde elaborar el Reporte de la calidad ir a la actividad 11. Si no ir al Fin.
11. Elaborar reporte. El Representante de la calidad elabora el Reporte de la calidad del período correspondiente basándose en el Registro de incidencias y acciones de la organización.
12. Entregar reporte. El Representante de la Calidad entrega a la Dirección el Reporte de la calidad.
Sistema de indicadores
Para poder brindar al personal de un proyecto y a la dirección de una organización una visión objetiva de los procesos y productos de trabajo asociados, se hace necesario contar con un sistema de indicadores capaz de mostrar la conformidad de los mismos con lo establecido en la institución. El análisis de resultados históricos permitirá conocer el avance alcanzado, así como identificar las dificultades que surjan para tomar las acciones correctivas necesarias. También permitirá conocer la eficacia del proceso base AC.
Indicador 1: Nivel de implementación de los procesos bases. El objetivo del indicador es determinar los niveles de ejecución de los procesos bases implementados en el proyecto. ]]>
Indicador 2: Tipos de no conformidades y su impacto. El objetivo del indicador es comparar el resultado de la última evaluación ejecutada al proyecto, con el promedio histórico de no conformidades detectadas de acuerdo a su tipo e impacto.
Indicador 3: Adherencia a los criterios de evaluación. El objetivo del indicador es mostrar el nivel de adherencia que tienen los procesos y productos según los criterios de evaluación.
Indicador 4: Evaluación de un proyecto de desarrollo de software. El objetivo del indicador es mostrar la evaluación de un proyecto de desarrollo de software, según la cantidad de no conformidades detectadas durante una auditoría.
Indicador 5: Cantidad de inconsistencias por producto de trabajo. El objetivo del indicador es mostrar la cantidad de inconsistencias por cada producto de trabajo evaluado.
Indicador 6: Cantidad de no conformidades por proyecto. El objetivo del indicador es mostrar la cantidad de no conformidades por proyectos.
Indicador 7: Incidencias de las causas de las no conformidades. El objetivo del indicador es mostrar la frecuencia en que aparecen las causas asociadas a las no conformidades detectadas en las evaluaciones.
Indicador 8: Cantidad de no conformidades por proceso base. El objetivo del indicador es analizar en un período determinado, la cantidad de no conformidades que se encontraron por cada proceso base evaluado y su impacto.
Indicador 9: Resolución de no conformidades por proyecto. El objetivo del indicador es analizar la cantidad de no conformidades que fueron resueltas y las que persisten en un período determinado.
Indicador 10: Utilidad del proceso AC. El objetivo del indicador es analizar la utilidad de cada actividad del proceso Aseguramiento de la calidad.
Validación
]]> Con la intención de validar los requisitos que componen el proceso de AC, se aplicó en el mes de marzo de 2014 una encuesta a 37 especialistas de las siguientes organizaciones: veinte (20) de la UCI, once (11) de CALISOFT, tres (3) de la XETID, uno (1) de Joven Club, de deSoft y la de CUJAE – Facultad de Informática respectivamente. Los encuestados tuvieron la posibilidad de emitir una evaluación entre 0 y 5 puntos según el nivel de utilidad de cada requisito. Se les permitió además proponer nuevos requisitos y emitir un criterio final.Como se aprecia en la Figura 2, más del 85% de las evaluaciones emitidas a cada requisito oscilan entre cuatro (4) y cinco (5) puntos con una preponderancia de las evaluaciones máximas. Los encuestados además hicieron saber sus recomendaciones (doce (12) en total). Después de analizar las recomendaciones y las evaluaciones emitidas se realizaron las correcciones necesarias. En la Tabla 2 se muestra la trazabilidad de los requisitos actuales con los sometidos al criterio de especialistas del tema.
Los autores de la presente investigación consideran que los grupos focales constituyen una técnica valiosa y muy utilizada en la última década para obtener información. Por tal motivo decidieron su uso para corroborar que los cambios realizados a los requisitos fueron correctos y validar el resto de los elementos que componen el proceso base AC. Para su conformación se tuvo en cuenta los criterios emitidos por Aigneren y Méndez (Aigneren, 2009; Méndez, 2007), al decir que el tamaño del grupo debe oscilar entre cuatro (4) y doce (12) participantes; asegurando que todos puedan emitir sus criterios y que haya riqueza de ideas. Además, debe ser homogéneo determinado por el propósito del estudio.
Para cumplir con lo antes expuesto se convocó a varios especialistas de la ICSW, dedicados a realizar tareas relacionadas con la gestión de la calidad, para analizar los resultados de esta investigación en siete (7) encuentros. Las entidades que participaron fueron: CALISOFT con tres (3) especialistas, XETID y deSoft con dos (2), UCI, DATYS, TranSoft, ETECSA y ARTEX con uno (1); en total sumaron 12 profesionales.
En el último encuentro al exponer el resultado final del proceso base AC fue aprobado por todo el equipo participante. En dicho encuentro predominó el criterio: “El proceso base es una propuesta que se ajusta a las necesidades de la ICSW, a la vez que es ligera para su implementación. Los elementos de apoyo que lo componen, como son: la descripción gráfica y textual del proceso, el sistema de indicadores y los productos de trabajo, facilitarán la implantación de los requisitos en cada entidad sin necesidad de invertir mucho tiempo y recursos.”
CONCLUSIONES
Se realizó un análisis crítico de los modelos CMMI-DEV, MPS.Br, MoProSoft, COMPETISOFT y la norma, ISO 90003 lo cual permitió identificar los requisitos del proceso base AC y separarlas por niveles de madurez. La propuesta fue enriquecida con las particularidades cubanas identificadas a partir del análisis del decreto ley No. 281/07 y la Resolución No. 60/11.
Se propone que el proceso AC del MCDAI asuma las Auditorías de la configuración y las Revisiones de inconsistencia que en los modelos CMMI-DEV y MPS las ejecutan los procesos de Gestión de la Configuración y Administración de Requisitos respectivamente, por ser estas actividades de control de la calidad.
]]> Se definieron las descripciones gráficas de los procesos separados por niveles de madurez para cumplir con los requisitos propuestos.La validación de la propuesta, con el objetivo de garantizar la confiabilidad en los resultados, constató la convergencia de los resultados obtenidos y evidenció que la solución propuesta es adecuada y resuelve el problema de la investigación.
REFERENCIAS BIBLIOGRÁFICAS
Hernández, V.S. La Industria Del Software. Estudio A Nivel Global Y América Latina. Observatorio de la Economía Latinoamericana. 2009 (116).
McCaffrey, M. PwC Global 100 Software Leaders. PricewaterhouseCoopers; 2014.
Clancy, T. The Standish Group CHAOS Report. Project Smart. 2014.
]]> GET. ¿Quiénes somos? [En Línea: 2016] Available from: http://get.tur.cu/page/6deSoft. ¿Quiénes somos? [En Línea: 2016] Available from: http://www.desoft.es/index.php/desoft
TranSoft. ¿Quiénes somos? [En Línea: 2016] Available from: http://www.transoft.transnet.cu/?controlador=Items&accion=indexQuienes
UCI. Historia. [En Línea: 2016] Available from: http://www.uci.cu/?q=historia
Datys. ¿Quiénes somos? [En Línea: 2016] Available from: http://www.datys.cu/spa/site/index#about_us
(JCCE), J.C.d.C.y.E. ¿Quiénes somos? ; [cited 2015 02/10/2015]. Available from: http://www.jovenclub.cu/index.php?option=com_content&view=article&id=69:quienes-somos&catid=77:informacion-fija&Itemid=483
(PCC), P.C.d.C. Lineamientos de la Política Económica y Social del Partido y la Revolución; 2011.
]]>Tardío, M.A.; Estrada, A.F.; Montalván, D.P. Primeras ideas de un Modelo cubano de referencia para el desarrollo de aplicaciones informáticas. Revista Cubana de Ciencias Informáticas. 2011.
(NC), O.N.d.N. Listado de empresas con Sistema de Gestión Certificados. Available from: http://www.nc.cubaindustria.cu/certificacion.html
(MINCOM), M.d.l.C. Resolución No. 444/2012. 2012.
(CALISOFT), C.N.d.C.d.S. CS-03-D (14-001) LIBRO DE DIAGNÓSTICO; 2014.
Montalván, D.P. GUÍA GENERAL PARA UN MODELO CUBANO DE DESARROLLO DE APLICACIONES INFORMÁTICAS: Universidad de las Ciencias Informáticas (UCI); 2014.
(NC), O.N.d.N.: "Ingeniería de Software - Directrices para la Aplicación de la NC ISO 9001:2001 al Software de Computación (ISO/IEC 90003:2004, IDT), in NC ISO/IEC 90003:2004". 2006, Oficina Nacional de Normalización (NC). p. 26-28, 38-44, 62, 68-69.
(NC), O.N.d.N. NC ISO 9001:2008. Sistema de Gestión de la Calidad — Requisitos. 2008.
Team, C.P. CMMI® for Development, Version 1.3, Improving processes for developing better products and services. no CMU/SEI-2010-TR-033 Software Engineering Institute. 2010.
Rose, K.H. A Guide to the Project Management Body of Knowledge (PMBOK® Guide)—Fifth Edition. Project Management Journal. 2013;44(3):e1-e1.
Oktaba, H. Modelo de Procesos para la Industria de Software-MoproSoft-Versión 1.3, Agosto de 2005. NMX-059/01-NYCE-2005; 2005.
COMPETISOFT, P. COMPETISOFT-Mejora de Procesos para Fomentar la Competitividad de la Pequeña y Mediana Industria del Software de Iberoamérica. Versión 0.2. Diciembre. 2006.
Montoni, M.A.; Rocha, A.R.; Weber, K.C. MPS. BR: a successful program for software process improvement in Brazil. Software Process: Improvement and Practice. 2009;14(5):289-300
Aigneren, M., La técnica de recolección de información mediante grupos focales. La Sociología en sus escenarios, 2009(6).
Méndez, A.L.d. La entrevista y los grupos focales. 2007
Recibido: 15/04/2016 ]]> Aceptado: 05/05/2016
]]>