Tema: Unidad 4. Modelos y estándares de calidad aplicados al sistema de información
Nombre del estudiante: Janely Canseco García
Catedrático: Tomás Torres Ramírez
Materia: Calidad en los sistemas de información
Bienvenidos
INTRODUCCIÓN
Uno de los grandes problemas que enfrenta la producción de software tan necesario para el desarrollo de las Tecnologías de la información (TI) es el costo de desarrollo y la calidad con que estos son entregados a usuarios finales para su puesta en explotación. En la actualidad una de las disciplinas que propician contar con programas o aplicaciones de funcionalidad probada que garantiza el desarrollo de las TI es previamente la gestión de la calidad en el proceso de desarrollo de software.
Desde los primeros momentos en que se comenzó a desarrollar programas de aplicaciones; los errores y defectos que estás presentaban a la hora de la entrega y puesta en explotación dejaron clara la necesidad de propiciar un ambiente de gestión de la calidad con el objetivo de garantizar el funcionamiento óptimo de las aplicaciones, mejorando el proceso de desarrollo para entregar al usuario un producto con calidad.
A partir de esta problemática, el presente trabajo tiene el objetivo de identificar un grupo de modelos y estándares que pueden ser aplicados en los sistemas de información.
En la gestión de la calidad de los procesos y proyectos se utilizan métricas para medir características del producto y tomar después las decisiones en cuanto a la eliminación de los defectos, evitando costos innecesarios y entregas prolongadas del producto en desarrollo.
Los modelos y estándares de calidad más difundidos en la actualidad con los cuales se garantiza dar seguimiento a los atributos de funcionalidad, fiabilidad, usabilidad, eficiencia, mantenibilidad, portabilidad y conformidad son CMM – CMMI (Modelo para medir capacidades y madurez en los procesos), Normas ISO 9000 (referencias a los modelos de calidad), entre las que podemos encontrar especificaciones para la calidad de un producto, así como de los procesos en los que se creó dicho producto.
La calidad es importante para poder satisfacer a los clientes que pidan un sistema de calidad y cada vez hay mucho mayor competitividad en este mundo de la informática lo cual hace que cada uno de los desarrolladores busque opciones del como poder desarrollar software de calidad y en ello se han creado desde hace mucho tiempo atrás los estándares que hoy en día rigen en torno a este mundo para el desarrollo correcto de aplicaciones de calidad cumpliendo con sus normas y parámetros por el interés de conseguir la ansiada calidad.
La Asociación Estadounidense para Pruebas de Materiales (ASTM, por sus siglas en ingles) define la normalización como el proceso de formular y aplicar reglas para una aproximación ordenada a una actividad específica para el beneficio y con la cooperación de todos los involucrados.
La ISO, define a la normalización como: El proceso de formular y aplicar reglas con el propósito de realizar en orden una actividad específica para el beneficio y con la obtención de una economía de conjunto óptimo teniendo en cuenta las características funcionales y los requisitos de seguridad. Se basa en los resultados consolidados de la ciencia, la técnica y la experiencia. Determina no solamente la base para el presente, sino también para el desarrollo futuro y debe mantener su paso acorde con el progreso.
Certificación
La Certificación es la actividad con la que NYCE garantiza que determinado producto, servicio, sistema, proceso o persona cumple con las exigencias marcadas en diferentes normas establecidas a nivel nacional (NOM o NMX) e internacional (ISO, IEC, entre otras).
Se trata de un proceso documental en el que NYCE actúa como un organismo de tercera parte que, basado en procesos transparentes y confiables, revisa los resultados de una serie de pruebas, ensayos o análisis para evaluar cada una de las características requeridas por la regulación en cuestión.
NORMA ISO 9001:2000
Esta norma ha sido traducida por el Grupo de Trabajo "Spanish Translation
Task Group" del Comité Técnico ISO/TC 176, Gestión y aseguramiento de la
calidad, en el que han participado representantes de los organismos nacionales
de normalización y representantes del sector empresarial de los siguientes
países:
Argentina, Chile, Colombia, Costa Rica, Ecuador, España, Estados Unidos de
Norte América, México, Perú, Uruguay y Venezuela.
Igualmente, han participado en la realización de la misma representantes de
COPANT (Comisión Panamericana de Normas Técnicas) y de INLAC (Instituto
Latinoamericano de Aseguramiento de la calidad)
La innegable importancia de esta norma se deriva, sustancialmente, del hecho
de que ésta representa una iniciativa pionera en la normalización internacional,
con la que se consigue unificar la terminología en este sector en la lengua
española.
ISO 9001:2000 es una norma internacional aceptada por innumerables organizaciones y empresas que define los requisitos mínimos que debe cumplir un sistema de gestión de calidad para ser certificado.
La anterior versión de la norma ISO 9000 de 1994 se componía de una serie de tres normas cuyos códigos eran ISO 9001:94, ISO 9002:94 y ISO 9003:94, destinadas a empresas industriales que, respectivamente, contemplasen la totalidad de operaciones, incluidas las de diseño, que solamente tuviesen en cuenta la fabricación, o que basasen su sistema de calidad únicamente en el análisis y los ensayos finales de sus productos:
ISO 9001:1994 Sistemas de la calidad: Modelo para el aseguramiento de la calidad en el diseño, el desarrollo, la producción, la instalación y el servicio posventa. Esta norma determinaba los requisitos que se planteaban cuando era necesario demostrar la capacidad de un proveedor al asumir toda la responsabilidad, desde el diseño hasta el servicio posventa.
ISO 9002:1994 Sistemas de la calidad: Un modelo para el aseguramiento de la calidad en la producción, la instalación y el servicio posventa. Esta norma determinaba los requisitos planteados cuando era necesario demostrar la capacidad de un proveedor al asumir toda la responsabilidad a partir de un diseño establecido hasta el servicio posventa, previniendo el suministro de la producción de productos no conformes.
ISO 9003:1994 Sistemas de la calidad: Para el aseguramiento de la calidad en la inspección y en los ensayos finales. Determinó los requisitos planteados ante la necesidad de demostrar la capacidad de un proveedor para detectar y controlar el tratamiento de cualquier no-conformidad de un producto, fundamentalmente en las etapas de inspección y ensayos finales.
Actualmente, todas ellas han sido sustituidas por una sola, la ISO 9001:2000 que señala los requisitos de un sistema de gestión de la calidad certificable y que se complementa con la ISO 9000:2000 que se refiere a los fundamentos y el vocabulario y con la ISO 9004:2000 que se ocupa de las directrices para la mejora del desempeño.
Por lo tanto, si una organización desea certificar su sistema de gestión de calidad, dicho sistema deberá estar redactado de acuerdo con lo que se señala la norma ISO 9001:2000, enfatizando que se debe documentar bajo una justificación sólida la exclusión de cualquier requerimiento de la normativa que no aplique a la empresa (las cuales pueden ser actividades de diseño, instalación, servicio posventa, producto proporcionado por el cliente, etc.).
En la versión 2000, se hace hincapié en que no se pretende que las organizaciones estén obligadas a cambiar la estructura de su sistema de gestión de calidad o su documentación para así alinearse con la estructura de la norma ISO 9001:2000. La documentación del sistema de gestión de calidad de la organización debe ser adecuada de la manera que sea apropiada a sus actividades, mientras aún cubra los requisitos de éste estándar internacional.
Además, su denominación es ahora “Gestión de la Calidad”, lo que supone un avance sobre el anterior concepto de “Aseguramiento de la Calidad”. Para ello, la nueva norma incorpora aspectos como la medida de la satisfacción de los clientes y el establecimiento de objetivos de mejora continua, con los cuales se refuerza el ciclo de gestión de la calidad de los productos y servicios.
La fecha de aprobación de las tres normas que componen la serie ISO 9000:2000 es la de Diciembre del año 2000, limitando la validez de los certificados de las anteriores normas ISO 9000:94 al 15 de Diciembre del año 2003 y señalando la imposibilidad de certificarse por dichas normas anteriores a partir de Diciembre del año 2002.
Según su definición, la norma ISO 9001:2000 especifica los requisitos para los sistemas de gestión de la calidad aplicables a toda organización que necesite demostrar su capacidad para proporcionar productos que cumplan los requisitos de sus clientes y los reglamentarios que le sean de aplicación, y su objetivo es aumentar la satisfacción del cliente.
La norma ISO 9001:2000 define “producto” como “resultado de un proceso”, por lo que lógicamente sería aplicable, tanto a organizaciones que se identifiquen con empresas industriales, como a las que presten solamente servicios, tanto si se trata de entidades lucrativas como no lucrativas.
ISO 9001:2000 busca garantizar la eficacia de la organización, no su eficiencia. Sin embargo, para mejorar la eficiencia de la organización puede utilizarse, adicionalmente a ISO 9001:2000, la norma ISO 9004:2000, aunque solo la 9001 es certificable.
Certificación en gestión de la calidad
La certificación ISO 9001:2000 de una empresa, viene a ser como un reconocimiento de que realmente le interesa el resultado de su trabajo, la aceptación y satisfacción que este genere en sus consumidores.
La norma ISO 9126 presenta dos partes, la primera es el modelo de calidad para tratar la calidad externa e interna, y la segunda es el modelo de calidad uso para tratar la calidad en uso.
Para la evaluación de la calidad la ISO ha formulado entre otros los estándares ISO/IEC 9126, ISO/IEC 14598 e ISO/IEC 25000.
El estándar ISO 9126 fue formulado inicialmente en 1991 estableciendo un modelo de calidad y su uso como marco para la evaluación de software. En esta norma se distingue entre calidad interna y calidad externa, y se introduce también el concepto de calidad en uso; esta norma es una de las normas ISO que goza de más reconocimiento dentro de la comunidad y tiene como fundamento modelos de calidad aportados por diversas investigaciones realizadas en los últimos 30 años para la caracterización de la calidad del producto software.
La norma ISO/IEC 9126 permite especificar y evaluar la calidad del software desde diferentes criterios asociados con adquisición, requerimientos, desarrollo, uso, evaluación, soporte, mantenimiento, aseguramiento de la calidad y auditoria de software.
Los modelos de calidad para el software se describen así:
Calidad interna y externa: Especifica 6 características para calidad interna y externa, las cuales, están subdivididas. Estas divisiones se manifiestan externamente cuando el software es usado como parte de un sistema Informático, y son el resultado de atributos internos de software.
Calidad en uso: Calidad en uso es el efecto combinado para el usuario final de las 6 características de la calidad interna y externa del software. Especifica 4 características para la calidad en uso.
Al unir la calidad interna y externa con la calidad en uso se define un modelo de evaluación más completo, se puede pensar que la usabilidad del modelo de calidad externa e interna pueda ser igual al modelo de calidad en uso, pero no, la usabilidad es la forma como los profesionales interpretan o asimilan la funcionabilidad del software y la calidad en uso se puede asumir como la forma que lo asimila o maneja el usuario final. Si se unen los dos modelos, se puede definir que los seis indicadores del primer modelo tienen sus atributos y el modelo de calidad en uso sus 4 indicadores pasarían hacer sus atributos, mirándolo gráficamente quedaría así:
Norma de Evaluación ISO/IEC 9126
Se establecen categorías para las cualidades de la calidad externa e interna y calidad en uso del software, teniendo en cuenta estos 7 indicadores (funcionalidad, confiabilidad, utilidad, eficiencia, capacidad de mantenimiento, portabilidad y calidad en uso), que se subdividen a su vez en varios indicadores; estas se pueden medir por métrica interna o externa.
Evaluación Interna, externa y Calidad de Uso ISO/IEC 9126
A continuación se detalla cada una de las características que establece el estándar ISO-9126 CALIDAD EXTERNA:
Corresponde a la satisfacción de los clientes. El logro de la calidad externa requiere proporcionar productos o servicios que satisfagan las expectativas del cliente para establecer lealtad con el cliente y de ese modo mejorar la participación en el mercado. Los beneficiarios de la calidad externa son los clientes y los socios externos de una compañía. Por lo tanto, este tipo de procedimientos requiere escuchar a los clientes y también debe permitir que se consideren las necesidades implícitas que los clientes no expresan. CALIDAD INTERNA:
Corresponde al mejoramiento de la operación interna de una compañía. El propósito de la calidad interna es implementar los medios para permitir la mejor descripción posible de la organización y detectar y limitar los funcionamientos incorrectos. Los beneficiarios de la calidad interna son la administración y los empleados de la compañía. La calidad interna pasa generalmente por una etapa participativa en la que se identifican y formalizan los procesos internos.
FUNCIONALIDAD: Funcionalidad es la capacidad del software de cumplir y proveer las funciones para satisfacer las necesidades explícitas e implícitas cuando es utilizado en condiciones específicas.
*La funcionalidad se divide en 5 criterios: Adecuación: La capacidad del software para proveer un adecuado conjunto de funciones que cumplan las tareas y objetivos especificados por el usuario. Exactitud: La capacidad del software para hacer procesos y entregar los resultados solicitados con precisión o de forma esperada. Interoperabilidad: La capacidad del software de interactuar con uno o más sistemas específicos. Seguridad: La capacidad del software para proteger la información y los datos de manera que los usuarios o los sistemas no autorizados no puedan acceder a ellos para realizar operaciones, y la capacidad de aceptar el acceso a los datos de los usuarios o sistemas autorizados Conformidad de la funcionalidad: La capacidad del software de cumplir los estándares referentes a la funcionalidad.
CONFIABILIDAD: La confiabilidad es la capacidad del software para asegurar un nivel de funcionamiento adecuado cuando es utilizando en condiciones específicas. En este caso al confiabilidad se amplia sostener un nivel especificado de funcionamiento y no una función requerida.
*La confiabilidad se divide en 4 criterios: Madurez: La capacidad que tiene el software para evitar fallas cuando encuentra errores. Ejemplo, la forma como el software advierte al usuario cuando realiza operaciones en la unidad de diskett vacia, o cuando no encuentra espacio suficiente el disco duro donde esta almacenando los datos. Tolerancia a errores: La capacidad que tiene el software para mantener un nivel de funcionamiento en caso de errores. Recuperabilidad: La capacidad que tiene el software para restablecer su funcionamiento adecuado y recuperar los datos afectados en el caso de una falla. Conformidad de la fiabilidad: La capacidad del software de cumplir a los estándares o normas relacionadas a la fiabilidad.
USABILIDAD: La usabilidad es la capacidad del software de ser entendido, aprendido, y usado en forma fácil y atractiva. Algunos criterios de funcionalidad, fiabilidad y eficiencia afectan la usabilidad, pero para los propósitos de la ISO/IEC 9126 ellos no clasifican como usabilidad. La usabilidad está determinada por los usuarios finales y los usuarios indirectos del software, dirigidos a todos los ambientes, a la preparación del uso y el resultado obtenido.
*La usabilidad se divide en 5 criterios: Entendimiento: La capacidad que tiene el software para permitir al usuario entender si es adecuado, y de una manera fácil como ser utilizado para las tareas y las condiciones particulares de la aplicación. En este criterio se debe tener en cuenta la documentación y de las ayudas que el software entrega. Aprendizaje: La forma como el software permite al usuario aprender su uso. También es importante considerar la documentación. Operabilidad: La manera como el software permite al usuario operarlo y controlarlo. Atracción: La presentación del software debe ser atractiva al usuario. Esto se refiere a las cualidades del software para hacer más agradable al usuario, ejemplo, el diseño gráfico. Conformidad de uso: La capacidad del software de cumplir los estándares o normas relacionadas a su usabilidad.
EFICIENCIA: La eficiencia del software es la forma del desempeño adecuado, de acuerdo a al número recursos utilizados según las condiciones planteadas. Se debe tener en cuenta otros aspectos como la configuración de hardware, el sistema operativo, entre otros.
*La eficiencia se divide en 3 criterios:
Comportamiento de tiempos: Los tiempos adecuados de respuesta y procesamiento, el rendimiento cuando realiza su función en condiciones específicas. Ejemplo, ejecutar el procedimiento más complejo del software y esperar su tiempo de respuesta, realizar la misma función pero con más cantidad de registros.
Utilización de recursos: La capacidad del software para utilizar cantidades y tipos adecuados de recursos cuando este funciona bajo requerimientos o condiciones establecidas. Ejemplo, los recursos humanos, el hardware, dispositivos externos.
Conformidad de eficiencia: La capacidad que tiene el software para cumplir con los estándares o convenciones relacionados a la eficiencia.
CAPACIDAD DE MANTENIMIENTO: La capacidad de mantenimiento es la cualidad que tiene el software para ser modificado. Incluyendo correcciones o mejoras del software, a cambios en el entorno, y especificaciones de requerimientos funcionales.
*El mantenimiento se divide en 5 criterios:
Capacidad de ser analizado: La forma como el software permite diagnósticos de deficiencias o causas de fallas, o la identificación de partes modificadas.
Cambiabilidad: La capacidad del software para que la implementación de una modificación se pueda realizar, incluye también codificación, diseño y documentación de cambios.
Estabilidad: La forma como el software evita efectos inesperados para modificaciones del mismo.
Facilidad de prueba: La forma como el software permite realizar pruebas a las modificaciones sin poner el riesgo los datos.
Conformidad de facilidad de mantenimiento: La capacidad que tiene el software para cumplir con los estándares de facilidad de mantenimiento.
Portabilidad: La capacidad que tiene el software para ser trasladado de un entorno a otro.
*La portabilidad se divide en 5 criterios:
Adaptabilidad: Es como el software se adapta a diferentes entornos especificados (hardware o sistemas operativos) sin que implique reacciones negativas ante el cambio. Incluye la escalabilidad de capacidad interna (Ejemplo: Campos en pantalla, tablas, volúmenes de transacciones, formatos de reporte, etc.).
Facilidad de instalación: La facilidad del software para ser instalado en un entorno específico o por el usuario final.
Coexistencia: La capacidad que tiene el software para coexistir con otro o varios software, la forma de compartir recursos comunes con otro software o dispositivo.
Reemplazabilidad: La capacidad que tiene el software para ser remplazado por otro software del mismo tipo, y para el mismo objetivo. Ejemplo, la remplazabilidad de una nueva versión es importante para el usuario, la propiedad de poder migrar los datos a otro software de diferente proveedor.
Conformidad de portabilidad: La capacidad que tiene el software para cumplir con los estándares relacionados a la portabilidad.
CALIDAD EN USO
Calidad en uso es la calidad del software que el usuario final refleja, la forma como el usuario final logra realizar los procesos con satisfacción, eficiencia y exactitud. La calidad en uso debe asegurar la prueba o revisión de todas las opciones que el usuario trabaja diariamente y los procesos que realiza esporádicamente relacionados con el mismo software.
La calidad de uso se divide en 4 criterios:
Eficacia: La capacidad del software para permitir a los usuarios finales realizar los procesos con exactitud e integridad.
Productividad: La forma como el software permite a los usuarios emplear cantidades apropiadas de recursos, en relación a la eficacia lograda en un contexto específico de uso. Para una empresa es muy importante que el software no afecte al productividad del empleado
Seguridad: Se refiere al que el Software no tenga niveles de riesgo para causar daño a las personas, instituciones, software, propiedad intelectual o entorno. Los riesgos son normalmente el resultado de deficiencias en la funcionalidad (Incluyendo seguridad), fiabilidad, usabilidad o facilidad de mantenimiento.
Satisfacción: La satisfacción es la respuesta del usuario a la interacción con el software, e incluye las actitudes hacia el uso del mismo. A continuación se describe un cuadro donde podemos resumir las características y cada uno de sus atributos, este cuadro le ayudara a visualizar el proceso de evaluación.
MOPROSOFT es el Modelo de Procesos para la Industria del Software. Un modelo para la mejora y evaluación de los procesos de desarrollo y mantenimiento de sistemas y productos de software. Desarrollado por la Asociación Mexicana para la Calidad en Ingeniería de Software a través de la Facultad de Ciencias de la Universidad Nacional Autónoma de México (UNAM) y a solicitud de la Secretaría de Economía para obtener una norma mexicana que resulte apropiada a las características de tamaño de la gran mayoría de empresas mexicanas de desarrollo y mantenimiento de software.
El Programa para el Desarrollo de la Industria del Software (PROSOFT), es un plan de la Secretaría de Economía de México que forma parte del Plan Nacional de Desarrollo 2001-2006. Y está vigente a la fecha.
PROSOFT tiene siete líneas estratégicas, siendo la sexta la que ha dado origen a MoProSoft: "Alcanzar niveles internacionales en capacidad de procesos".
Al comenzar el desarrollo de esta línea estratégica se evaluó la adopción de los modelos:
ISO 9000, ISO 15504, SW-CMM.
El resultado de la evaluación fue:
"Ninguno de los estándares o modelos cumple con los requisitos expresados por la industria nacional", y se decidió la elaboración de un modelo adecuado para las características de las empresas mexicanas, que se basaría en los modelos evaluados.
Moprosoft tiene 9 procesos que se agrupan en las categorias:
Categoría alta dirección (DIR)
La alta dirección tiene un papel importante a través de la planificación estratégica. Debe actuar como promotor del buen funcionamiento de la organización a través de su implicación en la revisión y mejora continua del modelo.
Gestión de Negocio
Categoría Gerencia (GER)
El modelo considera a la gestión como proveedora de recursos, procesos y proyectos; así como responsable de la vigilancia del cumplimiento de los objetivos estratégicos de la organización. *Gestión de Procesos *Gestión de Proyectos *Gestión de Recursos ~Recursos Humanos y Ambiente de Trabajo ~Bienes Servicios e Infraestructura ~Conocimiento de la Organización
Categoría Operación (OPE)
El modelo considera a la operación como ejecutora de los proyectos de desarrollo y mantenimiento de software. *Administración de Proyectos Específicos *Desarrollo y Mantenimiento de Software .
Niveles de Madurez:
Nivel 0: Proceso Incompleto. El proceso no está implementado o no alcanza su propósito. A este nivel, hay muy poca o ninguna evidencia de ningún logro sistemático del propósito del proceso.
Nivel 1: Proceso Ejecutado. El proceso implementado alcanza su propósito.
Nivel 2: Proceso Gestionado. El proceso ejecutado descrito anteriormente está ya implementado de forma gestionada (planificado, supervisado y ajustado) y los resultados de su ejecución están establecidos, controlados y mantenidos apropiadamente.
Nivel 3: Proceso Establecido. El proceso gestionado descrito anteriormente está ahora implementado usando un proceso definido que es capaz de alcanzar sus resultados de proceso.
Nivel 4: Proceso Predecible. El proceso establecido descrito anteriormente ahora se ejecuta dentro de límites definidos para alcanzar sus resultados de proceso.
Nivel 5: Proceso Optimizado. El proceso predecible descrito anteriormente es mejorado de forma continua para cumplir con los metas empresariales presentes y futuros.
La ISO/IEC TR 15504, conocida como SPICE (Software Process Improvement and Capability dEtermination) es un modelo de evaluación y mejora de los procesos de desarrollo y mantenimiento de sistemas y productos de software. El estándar ISO 15504 es una herramienta que ayuda a reducir costes y mejorar la calidad evitando problemas.
La ISO/IEC TR 15504 es un marco de valoración de procesos, que puede ser empleado por las organizaciones involucradas en la planificación, gestión, monitorización, control y mejora de la adquisición, suministro, desarrollo, operación, evolución y soporte de software.
La ISO/IEC TR 15504 está diseñada para facilitar una aproximación común para realizar valoraciones de procesos, haciendo posible comparaciones entre los resultados de las mismas. Estos resultados se pueden basar en diferentes modelos de valoración (siempre que sean compatibles con el estándar) y métodos de valoración.
Proporciona todas las facilidades para la evaluación del proceso y establece los requisitos mínimos para realizar una evaluación que asegure la repetibilidad y consistencia de las valoraciones obtenidas.
El objetivo principal de evaluar estos procesos es conocer la capacidad que tienen en una organización.
Después de su ejecución, se debe obtener la información relevante de cada proceso, y el punto hasta el cual estos cumplen con su propósito.
Es un Marco de referencia para:
Determinar las fortalezas y debilidades de los procesos.
Mejorar los procesos de software y medir sus mejoras.
Aquellos que adquieren un sistema para evaluar la capacidad de los proveedores de sistemas.
Determinar los riesgos de negocio para una empresa que considera desarrollar un nuevo producto de software o servicio.
Características:
Marco de referencia para determinar las fortalezas y debilidades de los procesos. Es
aplicable a cualquier organización o empresa que quiera mejorar la capacidad decualquiera de sus procesos de software. El modelo de referencia de SPICE describe losprocesos que una organización puede realizar para comprar, suministrar, desarrollar,operar, mantener y soportar el software, así como los atributos que caracterizan lacapacidad de estos procesos.
Marco de referencia para los que adquieren un sistema para evaluar la capacidad delos proveedores de sistemas y determinar los riesgos de negocio para una empresa queconsidera desarrollar un nuevo producto de software o servicio.
Abarca:
Evaluación de procesos.
Mejora de procesos.
La calidad del todos los componentes integrados en el proceso de desarrollo del software NO mejora 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.
Es necesario tener un estándar como objetivo y referencia del proceso de desarrollo del software.
El modelo seleccionado no es tan importante como el compromiso de mejora
Determinación de capacidad.
Contiene los procesos que se han de evaluar. Se corresponden con los procesos del ciclo de vida del software, definidos al estándar ISO 12207:1995. Se agrupan en categorías, en función del tipo de actividad.
Alineado con el ISO/IEC 12207. Intenta proporcionar un marco en el que armonizar los enfoques existentes.
CATEGORIAS
Procesos cliente- proveedor: Esta categoría consiste en los procesos que directamente impactan al cliente, al soporte de desarrollo y a la transición del software al cliente.
Procesos de ingeniería: Esta categoría consiste, a los procesos que directamente especifican, implementa, y mantienen un sistema, un producto de software y la documentación del usuario.
Procesos de Operación: Esta categoría consiste en los procesos establecidos dentro del proyecto, coordinación y administración de los recursos para producir un producto o proveer un servicio para satisfacer al cliente.
Procesos de soporte: Esta categoría consiste en los procedimientos que establecen y soportan el desempeño de los otros procesos del proyecto.
Procesos de Administración: Esta categoría consiste en los procesos que establecen las metas de negocio de la organización, los procesos de desarrollo y recursos que ayudan ala organización alcanzar dichas metas.
Procesos de Reutilización: Proporciona en su parte 5 un Modelo de evaluación de procesos para los procesos de ciclo de vida del software definidos en el estándar ISO/IEC 12207 que define los procesos del ciclo de vida del desarrollo, mantenimiento y operación de los sistemas de software. Proporciona en su parte 6 un Modelo de evaluación de procesos para los procesos de ciclo de vida del sistema definidos en el estándar ISO/IEC 15288 que define los procesos del ciclo de vida del desarrollo, mantenimiento y operación de sistemas. Proporcionará en su parte 8 un Modelo de evaluación de procesos para los procesos de servicios TIC a ser definidos en el estándar ISO/IEC 20000-4 que definirá los procesos contenidos en la norma ISO/IEC 20000-1. Equivalencia y compatibilidad con CMMI. ISO forma parte del panel elaborador del modelo CMMI y SEI y viceversa, y se mantiene la compatibilidad y equivalencia de ésta última con 15504.
ARQUITECTURA
La arquitectura se basa en:
Prácticas base: Son las actividades esenciales de un proceso específico, agrupado 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.
Es un conjunto de prácticas disciplinadas para la gestión del tiempo y mejora de la productividad personal de los programadores o ingenieros de software, en tareas de desarrollo y mantenimiento de sistemas. Está alineado y diseñado para emplearse en organizaciones con modelos de procesos CMMI o ISO 15504. Fue propuesto por Watts Humphrey en 1995 y estaba dirigido a estudiantes. A partir de 1997 con el lanzamiento del libro "An introduction to the Personal Software Process" se dirige ahora a ingenieros juniors.
Se puede considerar como la guía de trabajo personal para ingenieros de software en organizaciones que emplean un modelo CMMI con nivel de madurez o de capacidad de procesos que implica la medición cualitativa y mejora de procesos.
Uno de los mayores problemas que tiene es la gran cantidad de datos que hay que tomar. El PSP tiene obsesión por la toma de datos y elaboración de tablas.
El PSP se orienta el conjunto de áreas clave del proceso que debe manejar un desarrollador cuando trabaja de forma individual.
PSP, es uno de los 3 vértices donde descansa un proceso de mejora que trabaja sobre 3 niveles de la organización, los otros 2 son CMM y TSP.
El PSP amplia el proceso de mejora a la gente que realiza el trabajo de desarrollo de software, concentrándose en las practicas de trabajo de los ingenieros en una forma individual, enseñando como manejar la calidad desde el principio de un producto.
TSP
Team Software Process (TSP) es un método de establecimiento y mejora del trabajo en equipo para procesos software.
TSP proporciona directrices para ayudar a un equipo a establecer sus objetivos, a planificar sus procesos y a revisar su trabajo con el fin de que la organización pueda establecer prácticas de ingeniería avanzadas y así obtener productos eficientes, fiables y de calidad.
Está formado por dos componentes primarios que abarcan distintos aspectos del trabajo en equipo:
Formación del equipo de trabajo.
Gestión del equipo de trabajo.
Existen diferentes metodologías para la mejora de procesos, la mayoría de ellas se basa en la mejora de los procesos que dan como resultado un servicio o producto. El TSP busca integrar un equipo que tenga como punto de partida la unificación del mismo, para poder llevar a cabo todos aquellos procedimientos que puedan realizar mejora a los procesos que desarrollan.
El Team Software Process (TSP) es un proceso de desarrollo para equipos de ingenieros basado en CMMI, ayuda a conformar equipos para el desarrollo de software de calidad y proporciona directrices para ayudar a un equipo a establecer sus objetivos, a planificar sus procesos y a revisar su trabajo con el fin de que la organización pueda establecer prácticas de ingeniería avanzadas y así obtener productos eficientes, fiables y de calidad.
TSP es una solución basada en procesos para resolver problemas de negocio, tales como:
Predictibilidad de costo y tiempo.
Mejora de productividad.
Ciclos de desarrollo y mejora de calidad de productos.
Características de los grupos eficaces:
Miembros expertos en papeles de liderazgo y pertenencia.
Relaciones tranquilas y establecidas entre los miembros.
Los miembros se sienten atraídos por el grupo y son fieles.
Los valores y metas del grupo son los de sus integrantes.
Los miembros están motivados por hacer lo que puedan por el grupo.
La interacción y toma de decisiones tiene lugar en el ambiente adecuado.
El grupo desea ayudar a cada miembro a adquirir su pleno potencial.
Cada miembro acepta con gusto y sin resentimiento las metas y normas establecidas.
Los miembros se prestan ayuda mutua cuando es necesaria o recomendable.
Existe una atmósfera de creatividad.
El grupo conoce el “conformismo constructivo” y se sirve de él.
Existe gran motivación para iniciar y recibir las comunicaciones.
Los miembros son flexibles y adaptables en sus metas y actitudes.
Los miembros se sienten seguros al tomar decisiones que les parecen apropiadas al entender la filosofía de la operación.
Sus orígenes se deben a las limitaciones que el PSP (Personal Software Process, su antecesor) tenía en el ámbito industrial. PSP resultó muy efectivo para que los ingenieros pudiesen tener el control de su proceso personal mediante la mejora de sus habilidades de estimación y la reducción de los defectos introducidos en los productos sin afectar a su productividad, pero PSP sólo se enfocaba en las fases de desarrollo de software (diseño y pruebas unitarias); la aplicación que lo ingenieros hicieron del PSP dentro de las empresas resulto en prácticas no satisfactorias.
Por tal motivo, Watts Humphrey desarrolló el TSP, el cual consideraba como parte importante, además de lo previsto por el PSP, los requisitos, las pruebas de integración, la documentación y otras actividades típicas en todo proyecto de desarrollo, de igual manera incluía actividades como los roles de equipo, interrelaciones dentro de la organización y la definición de un proceso de equipo para ser utilizado dentro de los procesos existentes en la organización.
Los Roles (responsabilidades) en los equipos en TSP son:
Líder del Equipo: Dirige al equipo, se asegura que todos reporten sus datos de los procesos y completen su trabajo tal y como se planeó. Realiza los reportes semanales del avance del equipo
Gestor de desarrollo: Guía al equipo en el diseño y desarrollo del producto.
Gestor de Planificación: Apoya y guía al equipo en la planificación y seguimiento del trabajo.
Gestor de Calidad/Proceso: Apoya al equipo en definir sus necesidades acerca del proceso y a establecer y administrar el plan de calidad. Genera estándares para obtener un trabajo uniforme. Modera las inspecciones y revisa cada artefacto generado.
Administrador de Requerimientos/Soporte: Dirige al equipo en el desarrollo de requerimientos de software y ayuda a dar a conocer la tecnología y en las necesidades de apoyo administrativo. Administra el plan de configuración.
Es necesario que los ingenieros que usan TSP estén formados en PSP. Con TSP, los equipos encuentran y reparan defectos en etapas tempranas del proceso de desarrollo, esto reduce de manera importante el tiempo de pruebas. Esto reduce de manera importante el tiempo de pruebas. Con un testing más corto, el ciclo completo se reduce.
A diferencia de otros métodos, TSP mejora el desempeño tanto de equipos como individuos, es disciplinado y ágil, provee beneficios inmediatos y medibles, acelera las iniciativas de mejora de procesos organizacionales.
En las fases del Ciclo TSP se planea el número de ciclos. Dentro de cada ciclo se realiza:
Lanzamiento
Estrategia
Plan
Requisitos
Diseño
Implementación
Pruebas
Postmortem
Los objetivos que tiene el TSP son:
Maximizar calidad software, minimizar costos.
Integrar equipos independientes de alto rendimiento que planeen su trabajo, establezcan metas y san sueños de sus procesos y planes.
Mostrar a los gerentes como monitorear y motivar a sus equipos de trabajo y como ayudarlos a alcanzar su máxima productividad.
Acelerar la mejora continua de monitoreo.
Proveer de una guía para e mejoramiento en organizaciones maduras
El CMMI es un enfoque de mejora de procesos que provee a las organizaciones de los elementos esenciales para un proceso efectivo, es un Modelo de Madurez de Capacidades Integrado.
Fue desarrollado por el SEI (Software Enginnering Institute).
Mide la madurez del desarrollo del software en una escala del 1 al 5.
En realidad, CMMI-DEV representa dos modelos que comparten los mismos elementos subyacentes. El primero y el más conocido es el modelo de la representación por etapas, que presenta 22 áreas de proceso asignadas a uno de los cinco niveles de madurez organizativa. Al valorar una organización, se evaluaría su nivel de funcionamiento y este nivel sería un indicador de su capacidad para administrar los riesgos y, por consiguiente, cumplir con sus promesas.
Etapas de madurez
Nivel 1 (Inicial): El proceso es impredecible, es reactivo y pobremente controlado.
Nivel 2 (Administrado): El proceso es reactivo y se caracteriza por su aplicación a proyectos.
Nivel 3 (Definido): El proceso es proactivo y se ve a nivel de la organización.
Nivel 4 (Administrado Cuantitativamente): El proceso es medido y controlado.
Nivel 5 (Optimizado): El proceso se enfoca en la mejora continua.
Los niveles 4 y 5 suelen denominarse los niveles de gran madurez. Suele haber una diferencia clara entre las organizaciones de gran madurez, que manifiestan comportamientos de administración cuantitativa y optimización, y las organizaciones con bajo nivel de madurez, que simplemente se administran o siguen los procesos definidos. Las organizaciones de gran madurez tienen una menor variabilidad en los procesos y suelen utilizar importantes indicadores como parte de un método de administración basado en estadísticas. Como resultado, estas organizaciones tienden a ser más predecibles y a responder con mayor rapidez a información nueva, suponiendo que la burocracia no se lo impida. Las organizaciones con un reducido grado de madurez tienden a realizar esfuerzos heroicos mientras que las organizaciones de gran madurez siguen a ciegas los procesos en situaciones de estrés y no reconocen que un cambio en los procesos podría ser una respuesta más adecuada.
El segundo, la representación continua, modela la capacidad de proceso en cada una de las 22 áreas de proceso y permite a la organización ajustar sus esfuerzos de mejora a los procesos que aporten el mayor valor de negocio. Esta representación está más en línea con el modelo original de Crosby. Las valoraciones según este modelo dan lugar a perfiles de capacidad en lugar de un mero número. Por supuesto, dado que el nivel de madurez organizativa es el nivel que la mayoría de los directivos y ejecutivos entienden, es posible asignar los resultados de una evaluación según el modelo continuo a las cinco etapas.
Usar el modelo por etapas como base de un programa enfocado a mejorar los procesos puede ser peligroso porque los implementadores podrían olvidarse de que el modelo CMMI no es un proceso ni un flujo de trabajo sino que proporciona los objetivos que los procesos y flujos de trabajo deben alcanzar. Si se cumplen esos objetivos, mejorará la madurez de la organización y aumentará la probabilidad de que todo transcurra según lo previsto. Quizás el mayor error sea convertir el hecho de alcanzar un nivel en un objetivo y crear procesos y una infraestructura simplemente para superar la valoración. El objetivo de cualquier actividad orientada a mejorar los procesos debe ser una mejora mensurable, no un número.
En el mercado actual, existen modelos de madurez, estándares, metodologías y guías que pueden ayudar a una organización a mejorar su modo de operar. Sin embargo, la mayoría de las aproximaciones de mejora disponibles se centran en una parte específica de su actividad y no adoptan una aproximación sistemática a los problemas a los que se enfrentan la mayoría de las organizaciones. Concentrándose en mejorar un área de negocio, estos modelos desafortunadamente han perpetuado los canales y las barreras que existen en el seno de las organizaciones.
El CMMI (Capability Maturity Model Integration) proporciona una oportunidad para evitar o eliminar estos canales y barreras, apoyándose en los modelos integrados que trascienden disciplinas. El CMMI para Desarrollo contempla las buenas prácticas relativas a las actividades de desarrollo y mantenimiento aplicadas a productos y servicios.
Elementos del modelo CMMI
El modelo CMMI se divide en las 22 áreas de proceso que se muestran en la siguiente tabla:
En la representación por etapas, cada área de proceso se corresponde con una etapa, tal como se muestra en la siguiente ilustración.
En la representación continua, las áreas de proceso se corresponden con grupos funcionales, tal como se muestra en la siguiente ilustración.
Termino muy usado en el mundo de la moda, entendemos como tendencia cualquier idea religiosa, económica, política, artística, etc., que se orienta en determinada dirección. En tecnologías de la información y comunicaciones, TIC, es un concepto muy utilizado por los responsables de sistemas, ávidos por implantar tecnologías que aporten ventajas competitivas a sus organizaciones. En definitiva invertir en la tecnología adecuada en el momento justo; todo un reto.
Es un juego difícil, con mucho riesgo de patinazos significativos; muy pocos predijeron hace 10 años que existiría algo llamado Facebook y que tendría 500 millones de usuarios. Quizás hace 3 años fuera más fácil identificar dicha tendencia y ver que esa cifra, 500 millones, era posible; es decir hace 3 años muchas empresas con productos destinados al usuario final, pudieron identificar que tenían que estar en Facebook sí o sí.
Es una realidad que muchas empresas llegan a determinadas soluciones tecnológicas tarde y mal (llegan porque hay que estar), por miedo a quedar arrinconados, sin comprender para nada estas nuevas tendencias. Esta actitud les impiden capitalizar a tiempo la ventajas, cuando llegan es tarde y solo les supone costes; hay que estar al precio que sea. Pagan vivir siempre mirando al pasado, al "así se ha hecho siempre" sin darse cuenta como la Red acelera los cambios, y como sus directivos al vivir de espaldas a la Red no llegan a comprender a tiempo las nuevas tendencias.
