• No se han encontrado resultados

Procedimiento para la evaluación de los procesos de software en la UEB ¨Aplicaciones de Redes¨ de la UNE

N/A
N/A
Protected

Academic year: 2020

Share "Procedimiento para la evaluación de los procesos de software en la UEB ¨Aplicaciones de Redes¨ de la UNE"

Copied!
143
0
0

Texto completo

(1)UNIVERSIDAD CENTRAL “MARTA ABREU” DE LAS VILLAS (UCLV) FACULTAD DE INGENIERIA INDUSTRIAL Y TURISMO DEPARTAMENTO DE INGENIERÍA INDUSTRIAL. TESIS DE MAESTRIA EN INGENIERIA INDUSTRIAL. Mención: Calidad. Título: Procedimiento para la evaluación de los procesos de software en la UEB ¨Aplicaciones de Redes¨ de la UNE. Autora: Ing. Kirenia Martín Toledo. Tutora: Dra. C. Ing. Lourdes García Ávila. Sancti Spíritus, 2010.

(2) PENSAMIENTO. PENSAMIENTO. “Cuando se desea poner en práctica algo nuevo, el principal enemigo de este esfuerzo se hallará dentro de la propia empresa y dentro de la propia persona. Si no se puede vencer este enemigo, no habrá progreso”.. K. Ishikawa.

(3) DEDICATORIA. DEDICATORIA. A todas aquellas personas que ven en el conocimiento la consumación de la utopía. A mi familia y a mi esposo por el cariño y la fe que tienen en cada uno de mis proyectos. A todos los que hicieron posible este trabajo..

(4) AGRADECIMIENTOS. AGRADECIMIENTOS. A todos los que creyeron en mí, a los que me ayudaron sin pedir nada a cambio, al colectivo de trabajadores de ATI, a mis compañeros de trabajo, a mis alumnos y en especial a mi tutora Lourdes. A todos: MUCHAS GRACIAS.

(5) RESUM EN. Resumen Cada día se hacen mayores exigencias a la industria del software; medidas en términos de productividad, calidad y mantenibilidad de los sistemas. Para satisfacer esta demanda se han desarrollado una diversidad de modelos y normas entre éstos: CMMI (Capability Matutity Model Integration) e ISO. También están los que se orientan al fortalecimiento de la industria de software en pequeñas y medianas empresas (PyMES), como. Light MECPDS (Modelo de evaluación. colombiano de procesos de desarrollo de Software), MPS-BR(Mejora de Procesos de Software brasileño) y MoProSoft (Modelos de procesos para la industria del software) de México, los que facilitan a estas empresas dar respuestas a dos situaciones: por imagen y por necesidad, para incursionar y mantenerse en un mercado global y hacer de sus proyectos unidades administrativas eficaces y eficientes. Producir software en tiempo y con el menor costo, como requerimiento de calidad, es una estrategia primordial de las PyMES, para ello deben lograr la mejora de los procesos de software. La UEB ¨Aplicaciones de Redes¨ perteneciente a ATI1 de la Unión Eléctrica Cubana (UNE) no está ajena a esta problemática, la clave está en ofrecer un enfoque de ingeniería al desarrollo del software, y proporcionar asistencia práctica a la dirección de la empresa y a las personas que lo desarrollan. En la investigación se evalúan los procesos de software en la organización, se aplica un procedimiento general y sus procedimientos específicos de apoyo, como contribución a la estandarización de sus prácticas, con el establecimiento un plan de acción para el mejoramiento de los procesos en la organización.. 1. Empresa de Tecnologías de la Información y Automática.

(6) SUMMARY. Summary Every day they become bigger demands to the industry of the software; measures in terms of productivity, quality and maintainability of the systems. To satisfy this demand a diversity of models and norms they have been developed among these: CMMI (Capability Matutity Model Integration) and ISO. They are also those that are guided to the invigoration of the software industry in small and medium companies (PyMES), as Light MECPDS (I Model of Colombian evaluation of processes of development of Software), MPS-BR (Improvement of Processes of Brazilian Software) and MoProSoft (Models of processes for the industry of the software) of Mexico, those that facilitate to these companies to give answers to two situations: for image and from necessity, to intrude and to stay in a global market and to make of their projects administrative effective and efficient units. To produce software in time and with the smallest cost, as requirement of quality, it is a primordial strategy of PyMES, for they should achieve it the improvement of the software processes. UEB ¨ Applications of Nets ¨ belonging to ATI1 of the Union Electric Cuban (it UNITES) is not unaware to this problem, the key is in offering an engineering focus to the development of the software, and to provide practical attendance to the address of the company and people that develop it. In the investigation the software processes are evaluated in the organization, it is applied a general procedure and their specific procedures of support, as contribution to the standardization of their practices, with the establishment an action plan for the improvement of the processes in the organization..

(7) TABLA DE CONTENIDOS. TABLA DE CONTENIDOS INTRODUCCIÓN ..................................................................................................................1 CAPÍTULO 1: MARCO TEÓRICO O DE REFERENCIA. ..................................................6 1.1. Introducción ...........................................................................................................6. 1.2. Modelos y Normas de calidad para los procesos de software. ....................7. 1.2.1. Las Normas ISO. ............................................................................................7. 1.2.2. CMMI (Capability Maturity Model Integrated). ...........................................8. 1.2.3. ISO/IEC 15504 (SPICE). .............................................................................10. 1.2.4. Aspectos comunes y comparativos entre los modelos ..........................13. 1.3. Modelos para la evaluación y mejora de los procesos de software para. las pequeñas y medianas empresas (PyMES) .........................................................14 1.3.1. Caracterización de las pequeñas y medianas empresas de software 15. 1.3.2. MoProSoft (México) .....................................................................................17. 1.3.3. MPS (Brasil) ..................................................................................................19. 1.3.4. Light MECPDS (Colombia) ........................................................................21. 1.4. Necesidad de la evaluación de los procesos en la industria del software. cubana .............................................................................................................................23 1.4.1. Las organizaciones de software en Cuba ................................................24. 1.4.2. Situación de las organizaciones de software en la UNE .......................27. 1.5. Conclusiones parciales .....................................................................................28. CAPÍTULO 2: PROCEDIMIENTO DE EVALUACIÓN PARA LOS PROCESOS DE UNA PYME DE SOFTWARE .............................................................................................30 2.1. Introducción .........................................................................................................30. 2.2. Premisas generales para la construcción del procedimiento......................30.

(8) TABLA DE CONTENIDOS. 2.3. Principios en los que se sustenta el procedimiento ......................................31. 2.4. Criterios empleados para la definición del procedimiento de evaluación de. procesos en una PyMe de software ............................................................................32 2.5. Descripción general del procedimiento de evaluación de procesos en una. PyME de software ..........................................................................................................33 2.5.1. Procedimiento/Premisas .............................................................................34. 2.5.2. Procedimiento/Objetivos .............................................................................34. 2.5.3. Procedimiento/Etapas .................................................................................34. 2.5.4. Procedimiento/ Elementos de evaluación ................................................36. 2.5.5. Procedimiento/Entradas y Salidas.............................................................36. 2.6. Descripción detallada del procedimiento ........................................................37. 2.7. Conclusiones Parciales. ....................................................................................52. CAPÍTULO 3: APLICACION DEL PROCEDIMIENTO DE EVALUACIÓN EN LA UEB ¨ APLICACIONES DE REDES¨ DE LA UNE ....................................................................53 3.1. Introducción .........................................................................................................53. 3.2. Caracterización general de la UEB ¨ Aplicaciones de Redes¨ de la UNE 53. 3.3. Aplicación del procedimiento de evaluación en la UEB “Aplicaciones de. Redes” de la UNE ..........................................................................................................54 La descripción de la validación del procedimiento propuesto en la figura 2.2 se realiza ...................................................................................................................................54 3.4. Algunas soluciones a mejoras propuestas.....................................................72. 3.4.1. Componentes básicos en los procesos de formulación estratégica..73. 3.4.2. Proyecto de Plan de Comunicación ..........................................................76. 3.4.3 Instrumentos para medir clima laboral y organizacional en una empresa. 84.

(9) TABLA DE CONTENIDOS. 3.5. Conclusiones parciales. ....................................................................................85. CONCLUSIONES ................................................................................................................86 RECOMENDACIONES .......................................................................................................86 REFERENCIAS BIBLIOGRÁFICAS ..................................................................................87 ANEXOS Anexo 1: Áreas en representación por etapas y en representación continúa Anexo 2: Niveles de capacidad del modelo SPICE Anexo 3: Escalas de valoración del modelo SPICE Anexo 4: Comparativa entre los modelos analizados Anexo 5: Relación entre los procesos considerados en el procedimiento y los estándares ISO 9001:2008 e ISO/IEC 15504. Anexo 6: Relación entre los procesos específicos considerados en el procedimiento y los estándares ISO 9001:2000, CMM v1.1 e ISO/IEC 15504. Anexo 7: Cómo seleccionar los expertos. Fuente: Hurtado de Mendoza (2003) Anexo 8: Roles y Responsabilidades del equipo de evaluación Anexo 9: Condiciones para iniciar una evaluación Anexo 10: Elementos para el patrón de procesos Anexo 11: Coeficiente de competencia de los miembros fijos del equipo de evaluación. Anexo 12: Acuerdo de confidencialidad general sobre el control de la información resultante de la evaluación. Fuente: elaboración propia. Anexo 13: Conceptos claves para la comprensión del instrumento de evaluación Anexo 14: Definición del proceso. Propósito y descripción Anexo 15: Definición del proceso. Objetivos e Indicadores.

(10) TABLA DE CONTENIDOS. Anexo 16: Definición del proceso. Entradas y salidas. Anexo 17: Definición del proceso. Roles involucrados y capacitación. Anexo 18: Diagrama de flujo de trabajo del proceso gestión negocio. Anexo 19: Diagrama de flujo de trabajo del proceso gestión proyectos Anexo 20: Diagrama de flujo de trabajo del proceso gestión recursos. Anexo 21: Lista de Chequeo para Gestión de negocio Anexo 22: Lista de Chequeo para gestión de proyectos. Anexo 23: Lista de Chequeo para gestión de recursos. Anexo 24: Plan de acción de mejoras de Gestión de Negocio Anexo 25: Plan de acción de mejoras de Gestión de Proyectos Anexo 26: Plan de acción de mejoras de Gestión de Recursos. Anexo 27: Valores compartidos. Fuente: elaboración propia Anexo 28: Encuesta para comprobar la satisfacción del cliente. Anexo 29: Encuesta para medir clima laboral Anexo 30: "Cuestionario sobre mi trabajo" para evalúr el clima organizacional. Fuente: Colectivo de autores (2000)..

(11) INTRODUCCIÓN. INTRODUCCIÓN Las empresas de desarrollo de software requieren implementar proyectos de mejoramiento de los procesos de software y de gestión de la calidad, de tal manera que estas puedan incrementar su competitividad. Para satisfacer esta demanda se han desarrollado una diversidad de modelos y normas como CMM I [CMMI, 2002] e ISO [ISO/IEC 15504,1998] y otros para la micro, pequeña y mediana empresa de software como modelo Light MECPDS de Colombia que proporciona un modelo explícito de evaluación ligero [Pino, 2009]; el modelo “MPS” de Brasil [MPS.BR, 2007], q ue tiene como objetivo principal definir e implementar un modelo para la mejora de procesos de software y MoProSoft para el Modelado de los Procesos de Desarrollo de Software [Oktaba, 2005], de México. Todos orientados al fortalecimiento de la industria de software, y con el propósito de fomentar la estandarización de su operación a través de la incorporación de las mejores prácticas en gestión e ingeniería de software, que facilite a estas empresas dar respuestas a dos situaciones: la primera, por imagen, para incursionar y mantenerse en un mercado global; la segunda, por necesidad, para poder hacer de sus proyectos unidades administrativas eficientes y eficaces. Estos modelos o normas se enfocan hacia la mejora de los procesos de software, la certificación de calidad del proceso de desarrollo de software y de los productos de él derivados. Sin embargo, estas empresas se enfrentan al problema de elegir qué modelo o estándar utilizar, precisamente por la tendencia que existe de trasladar los requisitos que imponen los grandes modelos, hacia las empresas de menos desarrollo. Las empresas desarrolladoras de software cubanas tienen como objetivo primordial desarrollar software en tiempo y con el menor costo, requerimientos de calidad, que exigen establecer una estrategia basada en la mejora de los procesos de software. 1.

(12) INTRODUCCIÓN. En este contexto la UEB ¨Aplicaciones de Redes¨ perteneciente a ATI1 de la Unión Eléctrica Cubana (UNE), desarrolla el Sistema Integral de Gestión de Redes (SIGERE) destinado a recoger datos técnicos, económicos y de gestión, para facilitar la operación, explotación, estudios, planificación y gestión de las redes eléctricas del país. Para ello, a UEB requiere disminuir el plazo de entrega de los proyectos que conforman el sistema SIGERE. Estudios realizados, promueven la preocupación de la dirección, ante la necesidad de definir y mejorar los procesos de software que según Piattini 2008 son un conjunto coherente de políticas, estructuras organizacionales, tecnologías, procedimientos y artefactos, que son necesarios para concebir, desarrollar, instalar y mantener un producto de software. Los elementos anteriores sustentan la situación problemática, desde el punto de vista teórico no existe un modelo de referencia cubano que sirva de base a la industria de software, constituida por empresas pequeñas y medianas, que permita elevar la capacidad de las organizaciones para ofrecer servicios en correspondencia con los estándares internacionales. Esto o rigina incertidumbre en la elección del modelo a implementar, debido a la diversidad de estos, los cuales en forma general se enfocan. en el qué hacer, y le corresponde a la. empresa establecer el cómo asegurar el cumplimiento de los objetivos generales medibles y los resultados esperados de la implantació n efectiva de los procesos de software. Por otra parte, estos modelos son difíciles de entender y de aplicar porque manejan grandes volúmenes de información y son costosos en su adopción. Mientras que desde el punto de vista práctico en la UEB ¨Aplicaciones de Redes¨ perteneciente a ATI, no están definidos todos los procesos de software, al no integrarse de manera clara y consistente los elementos indispensables para la definición de los procesos establecidos y las relaciones entre ellos. No existe un enfoque en proceso que apoye a la organización en la estandarización de sus prácticas, y en la integración de la mejora continua. No está documentada la descripción general de las actividades y productos que componen el flujo de. 2.

(13) INTRODUCCIÓN. trabajo de los procesos establecidos ni existen los indicadores para evaluar la efectividad del cumplimiento de los objetivos de los procesos. Lo anterior conduce a plantear el problema científico siguiente: La carencia de instrumentos metodológicos, integradores y con enfoque sistémico que guíen cómo evaluar los procesos de software en la UEB ¨Aplicaciones de Redes¨ de la (UNE), para contribuir a la estandarización de sus prácticas. El objeto de estudio teórico la evaluación de la calidad de los procesos de software, y el objeto de estudio práctico, la revisión de los procesos de software en la UEB ¨Aplicaciones de Redes¨ de la (UNE). Lo expresado anteriormente, así como el análisis bibliográfico de la literatura especializada y otras fuentes, en la construcción del marco teórico o referencial de la investigación, se formuló como resultado adelantado de la investigación la Hipótesis siguiente: Es posible evaluar los procesos de software en la UEB ¨Aplicaciones de Redes¨ de la (UNE), mediante la aplicación de un procedimiento general, que contribuya a la estandarización de sus prácticas. Esta hipótesis se comprueba mediante: 1. El cumplimiento de los principios de pertinencia, consistencia lógica y suficiencia. del. procedimiento. general,. con. sus. correspondientes. procedimientos específicos hacen factible su aplicación racional al objeto de estudio práctico. 2. Los resultados y hallazgos del proceso de evaluación en el objeto de estudio práctico permiten definir el plan de acción para contribuir a la estandarización de los procesos evaluados. Todo lo anterior conduce a plantear en la investigación, el sistema de objetivos siguiente: Objetivo general: Aplicar un procedimiento general para la evaluación de los procesos de software, que contribuya a la estandarización de sus prácticas. Objetivos específicos: 3.

(14) INTRODUCCIÓN. 1. Realizar un análisis de la literatura especializada, que abarque los aspectos teóricos y conceptuales y las experiencias prácticas existentes relacionadas con la evaluación de los procesos de software. 2. Diseñar un procedimiento general procedimiento general para la evaluación de los procesos de software, sobre bases científicas, en la PyME. 3. Implementar el procedimiento general para la evaluación de los procesos de software en el objeto de estudio práctico, como forma de comprobación de los resultados de la investigación, así como de su hipótesis general. Entre los Métodos de trabajo científico utilizados se destacan los siguientes: Métodos generales: El método hipotético-deductivo para la elaboración de la hipótesis central de la investigación y para proponer nuevas líneas de trabajo a partir de los resultados parciales; el método sistémico para lograr que los elementos que forman parte del procedimiento sean un todo que funcione de manera armónica; el método histórico-lógico y el dialéctico para el estudio crítico del los trabajos anteriores, y para utilizar estos como punto de referencia y comparación de los resultados alcanzados. Métodos lógicos: El método analítico-sintético al descomponer el problema de investigación en elementos por separado y profundizar en el estudio de cada uno de ellos, para luego sintetizarlos en la solución de la propuesta. El aporte práctico de la investigación está asociado a los instrumentos utilizados en el procedimiento general que permiten evaluar el nivel de madurez de los procesos de software en la UEB ¨Aplicaciones de Redes¨ de la (UNE), como: las listas de chequeo definidas, las prácticas para evaluar los atributos de los procesos y el establecimiento del plan de acción. El aporte metodológico de la investigación está dado por: 1. Los instrumentos metodológicos que guían a la empresa, de forma unificada, coherente y consistente, a cómo evaluar los procesos de software.. 4.

(15) INTRODUCCIÓN. 2. La integración de manera clara y consistente de los elementos necesarios para establecer los procesos de software o para identificar los elementos a cubrir en los procesos ya definidos, así como las relaciones entre ellos. 3. Los resultados de este trabajo serán utilizados en las asignaturas de la disciplinas de Calidad e Ingeniería de software, de la carrera de Informática para la preparación de futuros profesionales y en el entrenamiento de los actuales de la industria. Los resultados esperados son los siguientes: •. El procedimiento general que integre las mejores prácticas en gestión e ingeniería de software y los instrumentos metodológicos fáciles de entender y aplicar para evaluar el nivel de madurez de los procesos de software y facilitar la adopción de las acciones de mejora que contribuya a la estandarización de las prácticas en la organización.. •. La integración de manera clara y consistente de los elementos necesarios para establecer los procesos de software o para identificar los elementos a cubrir en los procesos ya definidos, así como las relaciones entre ellos.. •. La definición de las prácticas que permiten evaluar los atributos de proceso por cada nivel de madurez de capacidad del proceso.. La investigación se estructura en tres capítulos. El Capítulo I, referido al marco teórico y referencial de la investigación; Capítulo II, donde se plantea el procedimiento general de evaluación de los procesos de software y el Capítulo III que contiene la aplicación del procedimiento en el objeto de estudio práctico.. 5.

(16) CAPÍTULO 1: MARCO TEÓRICO O DE REFERENCIA. CAPÍTULO 1: MARCO TEÓRICO O DE REFERENCIA. 1.1. Introducción. La estrategia que sigue la autora para realizar el análisis bibliográfico y construir el marco teórico o referencial de la investigación, se resume en el esquema de la figura 1.1, que agrupa los aspectos fundamentales del objeto de estudio teórico. En el Capítulo se presenta un estudio sobre el estado actual de la Industria de software en el mundo y específicamente en Cuba. Se realiza un examen crítico sobre los modelos de referencia para el desarrollo y evaluación de los procesos de software y la evaluación de las formas que se utilizan por las PyMES de éxito a nivel mundial en la evaluación y mejoramiento de los procesos de software.. Figura 1.1 Hilo conductor del marco teórico de la investigación. Fuente: Elaboración propia. 6.

(17) CAPÍTULO 1: MARCO TEÓRICO O DE REFERENCIA. 1.2. Modelos y Normas de calidad para los procesos de software.. La evaluación de un proceso en ISO/IEC TR 15504-1 [1998], se define como el examen disciplinado de los procesos, que se usa en una organización junto a un conjunto de criterios para determinar la capacidad de los procesos a realizar, dentro de los objetivos de calidad, coste y planificación. El propósito de la evaluación es caracterizar la práctica actual, identificar debilidades y fortalezas y la habilidad del proceso para controlar o evitar las causas de baja calidad, desviaciones en coste o planificación. De acuerdo con inspecciones y encuestas recientes en todo el mundo [Wang, 1999], el estándar ISO 9001 es el más popular en el mundo de la ingeniería del software, seguido de CMM e ISO/IEC 15504 (SPICE). 1.2.1 Las Normas ISO. La línea que marcan las entidades internacionales de estandarización, impone en la práctica, las directrices marcadas por la ISO (Organización Internacional de Normalización) a través de la serie de normas ISO 9000 para la gestión de la calidad. En el caso del software, es principalmente aplicable la norma ISO 9001 [ISO, 1994], sin embargo, en los últimos años una mayor cantidad de organizaciones de este sector, utilizan la norma ISO 9002 [ISO, 1994]. Situación que se manifiesta, ante la posibilidad de lograr la certificación por esta norma, sin tener que cumplir los apartados sobre el diseño, aunque este se realice. El sector del software difiere por la naturaleza del producto, del resto de sectores productivos, por lo que se requiere de una guía de evaluación específica: la norma ISO 9000-3 [ISO, 1997]. En esta línea se trabaja, bajo el supuesto principal, de asegurar a los clientes la calidad de los productos, a partir de la mejora de la calidad del proceso productivo o de desarrollo. Se concibe como una metodología de procesos basada en una lista de comprobaciones o requisitos a cumplir, umbral de calidad, se valora apto o no apto, esta simplicidad la ha hecho mundialmente extendida. El estándar se basa 7.

(18) CAPÍTULO 1: MARCO TEÓRICO O DE REFERENCIA. en un conjunto de Principios de Gestión de la Calidad: enfoque al cliente, liderazgo, implicación de todo el personal, enfoque a procesos, enfoque del sistema hacia la gestión, mejora continua, enfoque objetivo hacia la toma de decisiones y relaciones mutuamente beneficiosas con los proveedores [ISO 9000, 2000]. La ISO-9000-3 es un estándar de Gestión de la calidad, una guía de aplicación de la ISO 9001 para el desarrollo y mantenimiento del software [ISO 9000-3: 1991], [Achmauch, 1994], [ESE, 1995]. Este contiene veinte requisitos que deben estar presentes en un sistema de gestión de la calidad efectivo. 1.2.2. CMMI (Capability Maturity Model Integrated).. El modelo CMMI es una evolución de CMM, que integra los distintos modelos de calidad, constituye un marco de referencia de la capacidad de las organizaciones de desarrollo de software en el desempeño de sus diferentes procesos, al respecto proporciona una base para la evaluación de la madurez de las mismas y una guía para implementar una estrategia para la mejora continua de los mismos. Otros desarrollos permitieron comenzar la aplicación al software, Humphrey proporciona una descripción de los principios y conceptos básicos en que se basan la mayoría de los modelos de madurez en Humphrey [1989]; Mark Paulk y otros en el SEI crearon el primer modelo de madurez de capacidad, diseñado para organizaciones de desarrollo software y lo publican en Paulk [1995]. En estos modelos aparecen los elementos esenciales de procesos efectivos para una o más disciplinas y describen el camino para evolucionar y mejorar desde procesos inmaduros a procesos disciplinados, maduros con calidad y eficiencia mejorada y probada. CMMI dirige su enfoque a la mejora de procesos en una organización, estudia los procesos de desarrollo y produce una evaluación de la madurez (indicador para medir la capacidad para construir un software de calidad), de la organización según una escala de cinco niveles (inicial, repetible, definido, dirigido y optimizado), ver anexo 1. 8.

(19) CAPÍTULO 1: MARCO TEÓRICO O DE REFERENCIA. El CMMI es un modelo de calidad del software, que clasifica las empresas en niveles de madurez, que permiten conocer la madurez de los procesos que se realizan para desarrollar software, según se describe a continuación: 1. Inicial - Estado inicial donde el desarrollo se basa en la heroicidad y responsabilidad de los individuos. Los procedimientos son inexistentes o localizados a áreas concretas. No existen plantillas definidas a nivel corporativo. 2. Gestionado - Se normalizan las buenas prácticas en el desarrollo de proyectos (en base a la experiencia y al método). En este nivel consolidado, las buenas prácticas se mantienen en los momentos de estrés. Están definidos los productos a realizar. Se definen hitos para la revisión de los productos. 3. Definido - La organización completa participa en el proceso eficiente de proyecto software. Se conoce de antemano los procesos de construcción de software. Existen métodos y plantillas bien definidas y documentados. Los procesos no solo afectan a los equipos de desarrollo sino a toda la organización relacionada. Los proyectos se pueden definir cualitativamente. 4. Cuantitativamente gestionado - Se puede seguir con indicadores numéricos (estadísticos) la evolución de los proyectos. Las estadísticas son almacenadas para aprovechar su aportación en siguientes proyectos. Los proyectos se pueden pedir cuantitativamente. 5. Optimizado - En base a criterios cuantitativos se pueden determinar las desviaciones más comunes y optimizar procesos. En los proyectos siguientes se produce una reducción del costo, gracias a la anticipación de problemas y la continua revisión de procesos conflictivos [CMMI-SW, 2002]. La autora considera este modelo referente importante para la investigación, por constituir. una aplicación de sentido común de los conceptos de gestión de. procesos y mejora de la calidad de los procesos de software y una guía para implementar una estrategia para la mejora continua de los mismos.. 9.

(20) CAPÍTULO 1: MARCO TEÓRICO O DE REFERENCIA. 1.2.3. ISO/IEC 15504 (SPICE).. El proyecto SPICE (Software Process Improvement and Capability Determination) o ISO/IEC 15504, es un estándar internacional de calidad del software, que permite la evaluación y mejora continua de los procesos de ingeniería del software, en procesos de desarrollo que proveen un marco de trabajo uniforme, para la gestión e ingeniería del software de los procesos de ingeniería, gestión, relación cliente-proveedor, de la organización y del soporte. SPICE, se crea por la alta competencia del mercado de desarrollo de software, para la difícil tarea de identificar los riesgos, cumplir con el calendario, controlar los costos y mejorar la eficiencia y calidad. Este engloba un modelo de refe rencia para los procesos y sus potencialidades sobre la base de la experiencia de compañías grandes, medianas y pequeñas. El modelo describe los procesos que una organización puede ejecutar, adquirir, suplir, desarrollar, operar, evolucionar, brindar soporte de software y todas las prácticas genéricas que caracterizan las potencialidades de estos procesos. Un conjunto de prácticas forma el nivel más bajo de la arquitectura. La arquitectura de este modelo:  Organiza las prácticas en un número de categorías para ayudar al personal encargado del software a comprenderlas y utilizarlas para la mejora continua de la gestión de los procesos software , utilizando dos enfoques diferentes que se basa en: - Prácticas base: Son las actividades esenciales de un proceso específico, que se agrupan por categorías de procedimientos y procesos de acuerdo al tipo de actividad que direccionan. - Prácticas genéricas: Aplicables a cualquier proceso, que representa las actividades necesarias para administrar el “proceso” y mejorar su potencialidad. Ayuda al asesor a realizar juicios sobre los procesos de la organización durante una evaluación de un proceso software. [ISO/IEC 15504, Parte 2] 10.

(21) CAPÍTULO 1: MARCO TEÓRICO O DE REFERENCIA. En el modelo, cada proceso se describe en términos de prácticas base, que son sus únicas actividades de gestión o de ingeniería del software. Las categorías de proceso, procesos y prácticas base proporcionan un agrupamiento por tipo de actividad. Estos procesos y actividades caracterizan la ejecución de un proceso, incluso si no es sistemático. La implementación de sólo las prácticas base de un proceso puede ser de mínimo valor y representa sólo el primer paso en la construcción de la capacidad de proceso. Cada proceso se describe mediante prácticas base, que son las actividades esenciales del proceso específico. Los procesos se agrupan en 5 categorías de proceso que se describen en la tabla 1.1. La evolución de la capacidad de proceso se expresa en términos de niveles de capacidad, características comunes y prácticas genéricas. Niveles de capacidad: son un conjunto de características comunes (conjuntos de actividades) que trabajan de forma conjunta para proporcionar una mayor mejora en la capacidad para realizar un proceso. Cada nivel proporciona una mayor mejora en la capacidad que la de su predecesor en la ejecución de un proceso, constituyen un modo racional de progresar mediante las prácticas genéricas. Tabla 1.1 Descripción de las categorías de proceso Categoría de proceso Client e-Suministrador (CUS) Ingeniería (ENG) Proyecto (PRO). Soporte (SUP ) Organización (ORG). Breve descripción Procesos que impactan directamente en el client e, soportan el desarrollo y la transición del soft ware al cliente, y previenen su explotación y uso correcto. Procesos que especifican, implement an o mantienen un sistema y el producto software y su documentación de usuario. Procesos que establecen el proyecto, y coordinar y gestionar s us recursos para producir un producto o proporcionar un servicio que satisfaga al cliente. Procesos que permiten y soportan la ejecución de los otros procesos en un proyecto Procesos que establecen los objetivos del negocio de la organización y el proceso de desarrollo, el producto y los valores de recursos que ayudarán a la organización a alcanzar s us objetivos de negocio. Fuent e: elaboración propia. 11.

(22) CAPÍTULO 1: MARCO TEÓRICO O DE REFERENCIA. Los. niveles. de. capacidad. proporcionan dos. beneficios: reconocen. las. dependencias entre las prácticas de un proceso, y ayudan a una organización a identificar que mejoras debería realizar primero, basado en una secuencia de implementación del proceso. Existen 6 niveles de capacidad en el modelo que se resumen en el anexo 2. El estándar ISO15504 no define una metodología para la realización de una evaluación sino más bien el marco de trabajo y los elementos claves que una metodología de evaluación debe incorporar. La evaluación incluirá todas las prácticas base de cada proceso dentro de su alcance, organizado como una jerarquía, primero por categoría de proceso y después por proceso. Todas las categorías de procesos, procesos y prácticas base tienen un nombre y una descripción. El resultado de la evaluación consiste en un conjunto de valores de adecuación de las prácticas genéricas y los valores del nivel de capacidad del proceso para cada ocurrencia de proceso evaluada junto con el registro de evaluación. Aunque el estándar cubre un rango de procesos aplicables al proceso software, en algunas evaluaciones se selecciona tan solo un subconjunto de los procesos. En una evaluación existen cuatro elementos que son básicos para poder asegurar que los resultados sean consistentes, repetibles y representativos. -. La información de entrada.. -. Las responsabilidades.. -. El proceso de evaluación y valoración.. -. El proceso de registro.. Los factores de éxito para la evaluación del proceso son el compromiso, motivación, confidencialidad, relevancia y la credibilidad. Dimensiones e Indicadores/ Escalas de valoración Existen dos escalas de valoración, una para determinar la existencia y otra para determinar la adecuación de las prácticas, las cuales se muestran en el anexo 3 12.

(23) CAPÍTULO 1: MARCO TEÓRICO O DE REFERENCIA. Se aplicara igual peso a todos los valores de adecuación cuando se han de agregar o derivar valores de. prácticas genéricas, dentro de un proceso dado,. cada práctica genérica se considera de igual importancia, dentro de una característica común, en un nivel de capacidad y a través de múltiples ocurrencias del proceso. 1.2.4 Aspectos comunes y comparativos entre los modelos En cuanto a comparativas y mapeos entre áreas clave, con la desaparición de la dimensión Proceso, esta carece de sentido con SPICE por lo que entre ISO 9001 y CMM se destaca [Mutafelija, 2003] y [Paulk, 1995]. Mutafelija [2003] destaca la sinergia entre ambos y [Sheard, 2001], por lo que cada vez, más compañías consideren el uso conjunto de CMMI e ISO 9000 para aumentar la eficacia del proceso de mejora. A modo de resumen, se presenta un cuadro comparativo con las principales características de cada modelo en el anexo 4. Sin duda, el campo de la mejora y evaluación de procesos es muy prolífico y emergente, un campo muy activo de trabajo. Cabe resaltar cómo las evoluciones de los principales estándares siguen líneas que parecen confluir, y SPICE parece ser desencadenante de esta puesta en común de soluciones, sin embargo, quedan importantes temas abiertos, como el acercamiento de estos estándares a las pequeñas y medianas empresas, como la adecuación para dar soporte a metodologías de desarrollo ligeras, como la creciente necesidad de evidencias que den sostén a la eficacia e impacto de la ingeniería del software y en la industria de software no convencional. [De la Villa, 2008]. Por esta propia naturaleza la autora coincide con lo planteado anteriormente, pues se justifica apostar por el uso del modelado de sistemas dinámicos para la expresión formal de estos modelos tan complejos.. 13.

(24) CAPÍTULO 1: MARCO TEÓRICO O DE REFERENCIA. 1.3. Modelos para la evaluación y mejora de los procesos de software para las pequeñas y medianas empresas (PyMES). La Ingeniería del software ha introducido la premisa que la calidad de un producto de Software esta fundamentalmente determinada por los procesos utilizados en su desarrollo y mantención, según se establece [IEEE, 1998]. Dentro de este marco de referencia, se define como una organización madura aquella que posee la potencialidad para desarrollar y administrar sus proyectos de software en forma consistente y proactiva, así como también la capacidad para mantener y mejorar sus procesos. Una organización madura se caracteriza por mantener procesos consistentes a través de sus distintos proyectos. La aplicación de estos procesos debe resultar en una disminución de la crisis y de los costos anormales que afectan a una organización inmadura. La organización que logra un nivel adecuado de madurez de procesos puede controlar sus proyectos razonablemente y ahorrar los costos inherentes al proceso caótico, de esta forma se aprovechan los beneficios que brinda la calidad. Son necesarios Modelos de Procesos para la Industria de Software, que fomente la estandarización de su operación, a través de la incorporación de las mejores prácticas en gestión e ingeniería de software. La adopción del modelo permitiría elevar la capacidad de las organizaciones para ofrecer servicios con calidad y alcanzar niveles internacionales de competitividad en relativamente corto tiempo y a bajo costo, a partir de la adopción de un modelo fácil de entender y de aplicar. Las pequeñas y medianas empresas desarrolladoras de software experimentan cambio de paradigma, producto de la maduración del mercado del software, y es que ya no basta con aplicar bien la tecnología, o aplicar la tecnología de última generación para obtener un buen producto software, sino que la única forma que tiene una PyME de desarrollo de Software de mejorar su eficiencia y ser productiva para alcanzar los niveles de calidad exigidos por el mercado , es con la. 14.

(25) CAPÍTULO 1: MARCO TEÓRICO O DE REFERENCIA. incorporación de un modelo de calidad, que se ajuste a las necesidades del tipo de organización. [Acuña, 2005] Los diferentes Modelos de Proceso Software y Normas de Calidad existentes en el mercado para medir o certificar los procesos de desarrollo ( ISO/IEC 15504-2, ISO 90003, ISO 9001:2000, CMMI) [ISO/IEC TR 15504,1998], [ISO/IEC 9000-3,1997], [CMMI v1.1, 2002], [Ahern, 2001], incluyen conjuntos de procesos y actividades que responden a los criterios de desarrollo de sistemas complejos, en organizaciones grandes y con estructuras formales muy definidas, sin embargo son tan complejos en su implementación para las PyMES, que deben desarrollar un tipo de práctica que les permita trabajar con normas de calidad adaptadas a su entorno [Pino, 2009]. En este sentido, las PyMES de la industria del software poseen un conjunto de características, que presentan serias dificultades a la hora de adecuar sus actividades para conducir a sus organizaciones en un proceso de certificación con estos Modelos, dado por las pocas facilidades de financiación, los problemas para planear su crecimiento, la falta de gerenciamiento profesional, las dificultades para exportar, y los Sistemas de información, administración y contabilidad deficientes, son expresiones claras de las limitaciones del sector para implementar dichos modelos [Mon, 2006]. 1.3.1 Caracterización de las pequeñas y medianas empresas de software Las organizaciones de software se caracterizan por ser proveedores externos ya sea de software en paquete o de servicios de desarrollo. Por otra parte, existen organizaciones usuarias que tienen departamentos internos de software que producen software para estas entidades y que no se dedican a comercializarlo. La PyME de software promedio es una empresa con una decena de clientes, y una veintena de empleados muy especializados, que tienen gran capacidad de reacción y de adaptación y un invalorable conocimiento de la cultura local. La razón de ser de estas empresas es:. 15.

(26) CAPÍTULO 1: MARCO TEÓRICO O DE REFERENCIA. Las medianas, desarrollan software y servicios informáticos casi siempre en el campo de la gestión empresarial. Las empresas pequeñas, desarrollan distinto tipo de software o proveen servicios informáticos En la "PyME de software", el valor añadido en productos o servicios procede sustancialmente de software original o modificado. Los. problemas. más. infraestructura, mano. frecuentes de. obra. de. las. disponible. PyMES. de. Latinoamérica. y ambiente. para. son:. inversiones.. Lamentablemente este tipo de problema hace que exista escasez de mano de obra, pese a que los recursos huma nos son excelentes y de altísima calidad. El principal activo de estas empresas es el personal. Sin embargo, aquellas PyME que desarrollan software tienen menos de 15 personas dedicadas al software donde cada una tiene varios roles y responsabilidades. Esto trae por consecuencia que si los procesos no están bien definidos, gestionados y en mejoramiento continuo se arriben a problemas tales como proyectos con altos costos, entrega tardía de productos a los clientes, no realización de revisiones al software, no aplicación de sistemas de medición y baja calidad de los productos. Ante esta situación el esfuerzo tiene que ser enfocado hacia la mejora de los procesos de software, de tal manera que les permita a estas empresas incrementar su competitividad. Otro aspecto importante es la no certificación en este tipo de empresa debido a su costo y a que los modelos y normas se formulan para empresas grandes. No obstante, en Latinoamérica hay empresas certificadas en CMMI en Argentina, Colombia y Chile. La certificación de calidad de los procesos de software y de los productos obtenidos es un paso que tarde o temprano las empresas productoras de software deben dar como respuesta a dos situaciones: la primera, por imagen, para incursionar y mantenerse en un mercado global; la segunda, por necesidad, para poder hacer de sus proyectos unidades administrativas eficientes y eficaces [Hurtado, Alegría, 2005]. 16.

(27) CAPÍTULO 1: MARCO TEÓRICO O DE REFERENCIA. 1.3.2 MoProSoft (México) El Modelo de Proceso Mexicano MoProSoft [Oktaba, 2005] está elaborado como un modelo de madurez, con diferentes niveles, que se adapta a las necesidades de las pequeñas y medias empresas para: la estandarización de sus prácticas, evaluación de su efectividad y la integración de la mejora continua. El Modelo MoProSoft se estructura en base a 3 (tres) categorías que abarcan las responsabilidades asociadas con la organización: Alta Dirección, Gerencia y Operación. Dentro de cada categoría se definen un conjunto de procesos que incluyen prácticas y roles específicos. La categoría 1- Alta Dirección, aborda las prácticas relacionadas con la Gestión del Negocio, proporciona los lineamientos a los procesos de la categoría de Gerencia y se retroalimenta con la información generada por ellos. La categoría 2-Gerencia, aborda las prácticas de Gestión de Procesos, Proyectos y Recursos en función de los lineamientos establecidos en el nivel de Alta Dirección y proporciona los elementos para el funcionamiento de los procesos de la categoría de Operación, recibe y evalúa la información generada por éstos y comunica los resultados a la Alta Dirección. La categoría 3- Operación se subdivide en dos procesos, Administración de Proyectos Específicos y Desarrollo y Mantenimiento de software. El primer proceso busca establecer y llevar a cabo sistemáticamente las actividades que permitan cumplir con los objetivos de un proyecto en tiempo y costo esperados. El segundo, apunta a la realización sistemática de las actividades de análisis, diseño, construcción, integración y pruebas de productos de software nuevos o modificados cumpliendo con los requerimientos especificados. En este nivel se realizan las actividades de acuerdo a los elementos proporcionados por el nivel de Gerencia y entrega a ésta la información y productos generados.. 17.

(28) CAPÍTULO 1: MARCO TEÓRICO O DE REFERENCIA. Estas tres categorías se encuentran relacionadas entre sí a través de los diferentes procesos y los productos de entrada que cada uno requiere y de salida que cada uno genera. Para alcanzar diferentes niveles de madurez, MoProSoft propone un esquema de seis niveles de capacidad, alcanzables por una empresa de desarrollo de software (tabla 1.2). Tabla 1.2. Niveles de capacidad, según MoProSoft Nivel 0. Nivel 1. Nivel 2. Nivel 3. Nivel 4. Nivel 5. Sin proceso definido. Realizado. Gestionado. Establecido. Predecible. Optimizado. Fuente: adaptada de Oktaba H. et al (2003) El Modelo identifica cada nivel de capacidad con un color diferente. Los colores sugieren un ordenamiento de la implementación de las prácticas de los procesos de MoProSoft, parte de las actividades básicas, corresponde al nivel 1 realizado, e incorpora sucesivas prácticas que corresponden al resto de los niveles más avanzados. El propósito del Método de Evaluación de procesos para la industria de software EvalProSoft es otorgar a la organización solicitante, un perfil del nivel de capacidad de los procesos implantados y un nivel de madurez de capacidades de la organización. Los posibles usos del Método de Evaluación son los siguientes: • Evaluación para la acreditación de capacidades. • Evaluación de capacidades del proveedor. • Auto-evaluación de capacidades de proceso. Los posibles usos de los resultados de las evaluaciones son: Elementos de Evaluación Los elementos de evaluación se proyectan en un cuestionario [Bertone, 2006], que se orienta a los procesos definidos en el modelo, que tiene por objetivo realizar 18.

(29) CAPÍTULO 1: MARCO TEÓRICO O DE REFERENCIA. una evaluación sobre el cumplimiento de las prácticas, que define MoProSoft, también se establece el nivel en que se encuentra una empresa que comienza a implementar este Modelo de Madurez, y los procesos de mejora necesarios [Estayno, 2006]. Las preguntas del cuestionario se desarrollaron en base a las actividades planteadas en cada proceso, los cuales a su vez se dividen en fases. El cuestionario abarca, para cada práctica, las instancias básicas que deben ser cubiertas; cada práctica definida en el Modelo se integra con un conjunto de preguntas que procura identificar cuánto y cómo se realiza dicha práctica. Asimismo, cada pregunta tiene un nivel de madurez, que se asocia al nivel de madurez del Modelo, que se representa en forma coloreada. Cada pregunta puede tener diferentes tipos de respuestas: Si/No, opciones múltiples o texto libre, para aquellas respuestas que no son conducidas y pueden contemplar diversas opciones. La autora toma como referencia muchos aspectos de este modelo y su método de evaluación para la investigación, pues es un modelo sencillo de aplicar, de entender, además algunos países latinoamericanos lo toman como guía para pequeñas empresas, adaptadas a sus condiciones propias, lo que demuestra flexibilidad, con resultados satisfactorios. Sus principales deficiencias están en que se. requiere un organismo certificador, además involucra roles que no se. consideran relevantes para el desarrollo de la evaluación en el contexto de las empresas de software cubanas, específicamente al objeto de estudio. Plantea las actividades necesarias para cada proceso, pero no los agrupa en atributos para cada nivel de madurez. Como todos los modelos internacionales proveen el qué, pero no el cómo alcanzar los objetivos y resultados esperados de la implantación efectiva de los procesos de software. 1.3.3 MPS (Brasil) Brasil también es participe en trabajos de investigación sobre modelos de calidad de software, y aporta El MPS.BR1 es un programa para Mejora de Proceso del 19.

(30) CAPÍTULO 1: MARCO TEÓRICO O DE REFERENCIA. Software Brasileño, está en desarrollo desde diciembre de 2003, es coordina por la Asociación para Promoción de la Excelencia del Software Brasileño (SOFTEX) y cuenta con el apoyo prestigiosas organizaciones. MPS o Modelo de Procesos de Software basado en las normas ISO/IEC 12207:2002, CMMI e ISO/IEC 15504:2003, tiene como objetivo principal definir e implementar un modelo para la mejora de procesos de software. El enfoque principal del MPS.BR, aunque no de forma exclusiva, busca que sea adecuado al perfil de empresas con diferentes tamaños y características, públicas y privadas, aunque con especial atención a las micro, pequeñas y medianas empresas, a través de la factibilidad en su manejo, costos accesibles y posibilidad de obtener niveles de madurez 2 ó 3 [MPS.BR, 2007]. El MPS.BR se basa en los conceptos de madurez y capacidad de proceso para la evaluación y mejora de la calidad y productividad de productos de software y Servicios correlativos. Dentro de ese contexto, el MPS.BR posee tres componentes: Modelo de Referencia (MR-MPS), Método de Evaluación (MA-MPS) y Modelo de Negocio (MN-MPS). El MPS.BR está descrito por medio de documentos en forma de guías: Guía General; Guía de Adquisición; Guía de Evaluación; Guía de Implementación: La guía de implementación, consta de una serie de siete documentos que proporcionan orientaciones para implementar en las organizaciones los niveles de madurez descritos en el Modelo de Referencia MR-MPS. Se detallan los procesos contemplados en los respectivos niveles de madurez y los resultados esperados con la implementación de los procesos; esta guía está subdividida en 7 partes, que contempla, respectivamente, los niveles de madurez siguientes: G, F, E, D, C, B, A. La guía de evaluación: describe el proceso y el método de evaluación MA-MPS, los requisitos para evaluadores líderes, evaluadores adjuntos e Instituciones Evaluadoras (IA) 20.

(31) CAPÍTULO 1: MARCO TEÓRICO O DE REFERENCIA. Este proyecto desarrolló dos modelos: un Modelo de Referencia para la mejora del proceso del software y un Modelo de Negocio para la mejora del proceso del software. El primero comprende diferentes niveles de madurez y un método de evaluación. Los niveles de madurez están organizados en dos dimensiones: de capacidad y de proceso. El segundo define los elementos e interacciones involucrados para la certificación de la empresa, a través de la implementación del modelo de referencia de dos maneras: personalizada para una empresa o conjunta entre un grupo de empresas. El método de evaluación, a partir de indicadores, asigna un nivel de implementación de una práctica relacionada a un área de proceso. [MPS.BR, 2007] La autora considera que. de este modelo no es aplicable al contexto de las. organizaciones de software cubanas pues la guía general descansa en un conjunto de documentos de apoyo: Guía General [MPS.BR, 2007a]; Guía de Evaluación [MPS.BR, 2007b]; Guía de Adquisición [MPS.BR, 2007c]; y Guía de Implementación (partes 1 a 7), que lo hacen un modelo burocrático, con un costo elevado de adquisición, para ser adaptado a la condiciones actuales de Cuba y específicamente al objeto de estudio. 1.3.4 Light MECPDS (Colombia) Este trabajo de investigación colombiano aporta un modelo denominado Light MECPDS el cual se basa en las normas ISO/IEC 12207:2002 e ISO/IEC 15504:2003, y es aplicable a las pequeñas y medianas empresas de manera fácil y económica, con pocos recursos y en poco tiempo. El modelo proporciona un marco de trabajo ligero de medida de la madurez y cumplimiento del proceso; y un modelo de proceso de referencia. Light MECPDS tiene un modelo de procesos de referencia y un framework de medida a aplicar durante la evaluación de los procesos software de una organización. Light MECPDS tiene como alcance los procesos del ciclo de vida del software definidos en la norma ISO/IEC 12207:2002, la cual es el modelo de referencia; sin embargo, Light MECPDS puede utilizar cualquier modelo de proceso de referencia 21.

(32) CAPÍTULO 1: MARCO TEÓRICO O DE REFERENCIA. siempre que los procesos estén descritos en términos de sus propósitos y sus resultados. El modelo se basa en un conjunto de indicadores que guían los propósitos y resultados de todos los procesos dentro del modelo de evaluación de procesos; es muy similar al Modelo de Procesos de Software de México, que se enfoca a las micro, pequeñas y medianas empresas, aplicables de manera fácil y económica, en poco tiempo, con pocos recursos y basados en las mejores prácticas de normas internacionales como lo son los ISO/IEC 12207:2002 y 15504:2003. [43] El modelo de procesos de referencia, y el framework de Light MECPDS, demuestran el logro de los atributos de proceso, dentro del ámbito del nivel de capacidad del modelo de evaluación. En cuanto a sus niveles cuenta con tres que hacen mención a un Proceso Incompleto, un Proceso Realizado y un Proceso Gestionado. Light MECPDS define un marco de trabajo de medición para dar soporte a la evaluación en las dimensiones de capacidad del proceso y del cumplimiento del proceso. En la dimensión de la capacidad, sólo existen tres niveles de madurez con el fin de aligerar el modelo para que pueda ser aplicado a las pequeñas y medianas empresas. Sus principales propósitos son: establecer los elementos necesarios para evaluar la madurez y el cumplimiento de los procesos de una organización, con respecto a un modelo de procesos de referencia; aportar un modelo de evaluación ligero para que sea aplicable a las empresas pequeñas y medianas, de manera fácil y económica, con pocos recursos y en poco tiempo; fomentar la evaluación de las empresas de desarrollo de software del sur occidente Colombiano, identifica sus puntos fuertes y débiles, para que sirvan de guía en la mejora de los procesos de desarrollo de software de la organización. Los modelos que se analizan describen los procesos, que una organización puede ejecutar, adquirir, suplir, desarrollar, operar, evolucionar, y todas las prácticas genéricas que caracterizan las potencialidades de estos procesos. El considerar todos los componentes en el proceso de desarrollo del software, NO mejora 22.

(33) CAPÍTULO 1: MARCO TEÓRICO O DE REFERENCIA. necesariamente por el simple hecho de adoptar un estándar; es necesario que el proceso de adopción conlleve una gestión del cambio adecuada, tener un estándar como objetivo y referencia del proceso de desarrollo del software, por lo que el modelo que se seleccione no es tan importante como el compromiso de mejora. 1.4. Necesidad de la evaluación de los procesos en la industria del software cubana. Como se observa en la figura 1.2, existen varios factores que determinan la calidad del software y la eficiencia de la organización, entre ellos están la complejidad del producto, las tecnologías y las personas, así como algunas condiciones de entorno que también tienen su impacto, estas puede n ser condiciones de gestión (plazo de entrega, exigencias de la empresa), entorno de desarrollo y características del cliente, sin embargo en el centro de todas ellos se encuentra el proceso, factor directamente controlable por la organización, y garantía para obtener mejores productos [De la Torre,2009].. Figura 1.2. Determinantes de la calidad del software y de la efectividad de la organización. Fuente: de la Torre, 2009.. En este contexto, la calidad del software es un concepto complejo ya que la calidad del producto está estrechamente vinculada a la calidad del proceso de desarrollo. Numerosos estándares de proceso [IEEE, 1997], [ISO/IEC, 2002], proponen ordenar en forma prescriptiva las actividades que deben realizarse a 23.

(34) CAPÍTULO 1: MARCO TEÓRICO O DE REFERENCIA. través del desarrollo [Acuña, 2005]. Las pequeñas y medianas empresas desarrolladoras de software, experimentan cambios de paradigma, producto de la maduración del mercado del software, y es que ya no basta con aplicar bien la tecnología, o aplicar la tecnología de última generación para obtener un buen producto software, sino que la única forma que tiene una PyME de desarrollo de Software de mejorar su eficiencia y ser productiva alcanzando los niveles de calidad exigidos por el comercio exterior, es incorporando un modelo de calidad, que se ajuste a las necesidades del tipo de organización, Cuba, no está ajen a esta problemática ni constituye una excepción. 1.4.1. Las organizaciones de software en Cuba. A un país como Cuba, a pesar del bloqueo económico, comercial y financiero con el que se le impide el acceso a su mercado y lo obliga a invertir varias veces más recursos al tener que recurrir a mercados muy distantes. A pesar de eso, basándose sobre todo en sus recursos humanos y optimizando sus recursos materiales y financieros, Cuba avanza en su informatización, priorizando el uso social y colectivo, de las Tecnologías de la Información y la Comunicaciones (TIC) lo que da al país una connotación diferenciada al resto de los países del mundo en cuanto a Tecnologías de la Información se trata [Santos, Hernández 2009] Dentro de las proyecciones del gobierno cubano se encuentra el fomento de una Industria Cubana del Software (ICSW), que permita diseñar y proveer de equipos electrónicos y sistemas informáticos que beneficien a la sociedad y también con posibilidad de exportarlos para aportar a la base material de todos los programas del país. [SIME, 1997], [Lage, Dávila 2000], [González, Pérez 2003], [Álvarez, 2003]. Para lograr esto, Cuba tiene un gran potencial humano calificado en el área de la informática, distribuidos en alrededor de 250 entidades que bien exportan software, producen software o brindan algún servicio informático. De estas entidades, sólo 46, tienen carácter de empresa de software. A pesar de la potencialidad que poseen, tienen bajo índice de exportación. A partir de 24.

(35) CAPÍTULO 1: MARCO TEÓRICO O DE REFERENCIA. documentos revisados, [García & Álvarez, 1999] [García, Ávila 2000] [Febles, 2000] [Febles, 2002], [GTI, 2002], [Álvarez, 2003], [Moreno, 2003], se destacan problemas relacionados a la dimensión organizacional que inciden en la dimensión técnica del software, entre ellos: Algunas organizaciones no utilizan un enfoque basado en procesos, sino en funciones. Los procesos o no están definidos o no se aseguran y controlan. Las organizaciones no practican la planificación estratégica orientada hacia el mercado. Los trabajadores no han aprendido a mantener satisfechos a sus clientes. No existen procedimientos de trabajo formalizados. No existen herramientas integradas al control de los procesos. Los ejecutivos no cuentan con los datos necesarios para una adecuada toma de decisiones. Insuficiente papel motivador y visionario de la alta dirección. No se establecen acertados mecanismos de coordinación entre las diferentes áreas. Problemas técnicos en el diseño del nuevo producto o en su programación, deficiente calidad y rendimiento del producto, que al final no satisface los requisitos del cliente. Incapacidad para convertir a los nuevos clientes en clientes habituales. Entrega tardía de los proyectos que se aplican. Insuficiente información y comunicación de la cartera de productos que ofrecen las organizaciones, así como la gestión para su comercialización. Deficiente conocimiento por parte. de. los ejecutivos de. la. cultura. organizacional. Muchos de los problemas anteriores corresponden a la deficiente gestión y organización de los procesos, es por ello que el mejoramiento continuo de los. 25.

(36) CAPÍTULO 1: MARCO TEÓRICO O DE REFERENCIA. mismos es el punto de partida para obtener un producto capaz de satisfacer las necesidades de los clientes. Cuba aun no muestra resultados sobresalientes en América latina, a pesar de tener una infraestructura educativa altamente reconocida en la región. En Cuba esta industria es relativamente nueva y su desarrollo se ha visto frenado por las consecuencias de un bloqueo económico, cada vez más recrudecido. Pero a pesar de los contratiempos externos, muchas cosas faltan por hacer, como es la determinación de una estrategia general, que abarque no sólo la informatización del país, sino toda la industria como un factor clave para el desarrollo de la nación. Los avances en este sentido son demasiado tímidos, como para que promuevan el desarrollo vertiginoso de la industria. [Santos, Hernández, 2009]. Según, Guerrero, Llerena, 2008, el desarrollo acelerado. de la ciencia y las. tecnologías de la información, así como la velocidad de cambio en el manejo de los negocios,. ha traído como consecuencia que las empresas informáticas. enfrenten cada día, un reto para brindar una respuesta rápida, y eficaz a los clientes, que cada vez se vuelven más exigentes, no sólo en cuanto al precio sino también en la confiabilidad los productos de software. Cualquier organización que se dedique a la producción o comercialización de software, tiene en cuenta que la organización de sus procesos tiene un rol determinante en la competitividad de la misma. Experiencias como la de la empresa de Tecnologías de la Información y Servicios Telemáticos Avanzados- CITMATEL, se consideraron por la autora para el diseño y aplicación del procedimiento. CITMATEL es una empresa cubana del Ministerio de Ciencia Tecnología y Medio Ambiente, que posee certificado su Sistema de Gestión de la Calidad desde el 2005, bajo la NC ISO 9001:2001 (norma ISO 9001:2000 homologada). Se incluyen 15 procesos, entre los cuales se encuentra el proceso de producción de software. La implantación del proceso de producción de software que muestran, en base a la norma NC ISO 9001:2001 y su relación con otros procesos fundamentales de la empresa se utilizan con la finalidad de 26.

(37) CAPÍTULO 1: MARCO TEÓRICO O DE REFERENCIA. obtener. productos que satisfagan las necesidades y requerimientos de los. clientes. En Cuba, con el llamamiento por el Estado a todos los sectores de la economía, a través de los "Lineamientos estratégicos para la informatización de la sociedad cubana", del Comité Ejecutivo del Consejo de Ministros (1997), se trazaron las pautas para un abordaje integral que materialicen sus elementos esenciales: redes de comunicación, los ordenadores, la información, los servicios y las personas, en el marco de la mayor seguridad, protección, legalidad y además garantizar las normas claras para el desarrollo informático del Estado, evitar aplicar productos incompatibles, obsoletos e insostenibles que no permitan un desarrollo armónico e integrado de la sociedad pudiendo propiciar ineficacia en los procesos. [Santos Hernández, 2009]. 1.4.2 Situación de las organizaciones de software en la UNE En cualquier organización moderna la información está en el centro de la vida institucional de la misma. En la UNE tras algunos intentos de importar los sistemas funcionales que se necesitaban, la dirección apoyó activamente idea de desarrollar un Sistema de Gestión. en el 2000 la. Empresarial (SIGE) que estaba. compuesto de varios sistemas uno por cada proceso fundamental. Dado que no existía ninguna organización con capacidad para asumir centralmente estos desarrollos fueron asignados a varias entidades que tenían desarrollos previos. La mayor parte de los sistemas fracasaron lo que ha obligado a soluciones emergentes. Los problemas claves que influyeron son: . La mayor parte de los equipos eran pequeños (de 2 a 4 personas) inadecuados para un desarrollo sostenible de los proyectos.. . Personal poco motivado provocó una gran inestabilidad en los equipos.. . Las entidades a las que pertenecían estos equipos no tenían entre sus objetivos el desarrollo de software.. . Debido a los problemas que existían en el sistema electroenergético nacional, la dirección no pudo dedicarle la misma atención y recursos a este tema. 27.

(38) CAPÍTULO 1: MARCO TEÓRICO O DE REFERENCIA. En el 2006, coincidiendo con las propuestas de reorganizar la estructura empresarial de la UNE, la que incluía formar una. empresa para atender. las. tecnologías de la Información en la UNE, se hace una propuesta de crear una fábrica de software a partir del personal en el Grupo de Desarrollo de la OBE Sancti-Spíritus que ha estado a cargo del desarrollo del SIGERE desde 1999 basados en que: . Era el Grupo de Desarrollo que mayor número de software desarrollaba en el SIGE. Se aplicaban desde hace varios años conceptos básicos de ingeniería de software tales como la gestión de la configuración, el control de defectos y la gestión de requerimientos y desde el 2002 la metodología ScrumPu, elaborándose procedimientos internos para cada disciplina de desarrollo.. . Se usaban herramientas para las diferentes disciplinas haciendo hincapié en la arquitectura del proyecto.. . Existían relaciones. de varios años de colaboración con las facultades de. cibernética e ingeniería eléctrica de la Universidad Central de Las Villas. Desde el 2005 se creó la carrera de ingeriría informática en el Centro Universitario de Sancti-Spíritus. Más de 50 estudiantes han realizado sus prácticas o tesis en el grupo. Aunque la propuesta de creación de fábricas de software dentro de la UNE tiene solo resultados iniciales, se espera que las experiencias que se obtengan de este proceso pudieran ser de utilidad para la industria del software cubano. 1.5. Conclusiones parciales. La industria de software, es una industria creciente a nivel mundial, donde persisten problemas relacionados con la calidad del producto final, la definición y ejecución de procesos en las organizaciones y la satisfacción del cliente. Mayoritariamente son PyMES, sin embargo los estándares con mayor aceptación internacional están dirigidos a las grandes empresas productoras. 28.

(39) CAPÍTULO 1: MARCO TEÓRICO O DE REFERENCIA. El análisis crítico sobre los modelos de referencia en el ámbito internacional sobre el tema, evidenció que para encaminar las empresas desarrolladoras de software cubanas, en el ámbito competitivo de las organizaciones con gran desarrollo en la industria informática, requiere centrar los esfuerzos en la mejora de la calidad de los procesos de software. Existen numerosas metodologías bien definidas y maduras para el desarrollo de software, pero en su mayoría necesitan de mucha fuerza laboral y recursos, de forma general para poder ser aplicadas, lo cual limita a las PyMES cubanas, por lo que se requiere la adopción de algún tipo de práctica que permita trabajar con normas de calidad adaptadas a su entorno. La PyME cubana, específicamente, UEB ¨Aplicaciones de Redes¨ de la UNE , para lograr Sistemas de Gestión Empresarial en correspondencia con las exigencias que se le imponen esta industria, requiere de investigaciones que en este sentido, le provean de herramientas de evaluación de los procesos de software, que contribuyan a la estandarización de sus prácticas.. 29.

(40) CAPÍTULO 2: PROCEDIMIENTO DE EVA LUA CIÓN PA RA LOS PROCESOS DE UNA PYM E DE SOFTWARE. CAPÍTULO 2: PROCEDIMIENTO DE EVALUACIÓN PARA LOS PROCESOS DE UNA PYME DE SOFTWARE 2.1. Introducción. La evaluación de procesos es un medio para capturar información que describa la capacidad real de los procesos de una organización y se inicia como resultado de un deseo para determinar y/o mejorar la capacidad de estos procesos. En este capítulo se describe de forma detallada un procedimiento general y sus procedimientos específicos de apoyo que guíe la evaluación de los procesos en una PyME de software, el mismo está basado en los aspectos novedosos de la gestión e ingeniería de software para este tipo de empresas, que la Industria de Software (ISW), se ha dedicado a identificar, con la recopilación de las experiencias exitosas de la ISW a nivel mundial. Estos aspectos se orientan a la mejora del proceso, a la madurez de éstos y a la determinación de las capacidades; el procedimiento en este sentido se diseña con el propósito de otorgar a la organización, objeto de estudio, un perfil del nivel de capacidad de los procesos implantados y un nivel de madurez de capacidades de la misma, paso esencial para la implementación de un ciclo de mejora en la organización. Se utilizan, listas de comprobación que responden a las mejores prácticas en este campo, las cuales se organizan por áreas de aplicación o áreas claves de los procesos; también forman parte del procedimiento, herramientas básicas de Ingeniería de la calidad. 2.2. Premisas generales para la construcción del procedimiento.. La construcción del procedimiento se realizó sobre las premisas siguientes: Motivar a las organizaciones a aplicar un enfoque basado en procesos. El diseño del procedimiento permite aplicarlo a cualquier empresa o áreas internas dedicadas al desarrollo y/o mantenimiento de software. 30.

Figure

Figura  1.1  Hilo  conductor  del  marco  teórico  de  la  investigación.  Fuente:  Elaboración  propia
Tabla 1.1  Descripción de las categorías de proceso
Figura 1.2. Determinantes de la calidad del software y de la efectividad de la organización
Figura 2.2: Etapas del procedimiento de evaluación. Fuente: elaboración propia.
+7

Referencias

Documento similar

Where possible, the EU IG and more specifically the data fields and associated business rules present in Chapter 2 –Data elements for the electronic submission of information

The 'On-boarding of users to Substance, Product, Organisation and Referentials (SPOR) data services' document must be considered the reference guidance, as this document includes the

In medicinal products containing more than one manufactured item (e.g., contraceptive having different strengths and fixed dose combination as part of the same medicinal

Products Management Services (PMS) - Implementation of International Organization for Standardization (ISO) standards for the identification of medicinal products (IDMP) in

Products Management Services (PMS) - Implementation of International Organization for Standardization (ISO) standards for the identification of medicinal products (IDMP) in

This section provides guidance with examples on encoding medicinal product packaging information, together with the relationship between Pack Size, Package Item (container)

Package Item (Container) Type : Vial (100000073563) Quantity Operator: equal to (100000000049) Package Item (Container) Quantity : 1 Material : Glass type I (200000003204)

No había pasado un día desde mi solemne entrada cuando, para que el recuerdo me sirviera de advertencia, alguien se encargó de decirme que sobre aquellas losas habían rodado