Calidad de Software
Definición
El término puede ser ambiguo e incluso subjetivo porque, como la belleza, la calidad depende de quien la observa. Es necesario definir el concepto con claridad, ya que si la calidad no puede ser definida, no puede ser medida; y donde la calidad no puede ser medida entonces no puede ser controlada . Para trabajar sobre un esquema consistente y evitar ambigüedades, a continuación se ofrece la definición de calidad ofrecida por la organización ISO , siendo esta “La totalidad de características de un producto, proceso o servicio que cuenta con la habilidad de satisfacer necesidades explícitas o implícitas”.
Para complementar la definición, dado que el concepto calidad puede ser subjetiva y debido a que las necesidades explícitas o implícitas varían de organización en organización o de usuario en usuario , es esencial identificar dichas necesidades para el usuario o para la organización.
Calidad en el Software
Dentro del contexto de Ingeniería de Software, se tomará la definición de calidad en el software propuesta por la organización internacional de estándares (ISO/IEC DEC 9126): La totalidad de características de un producto de software que tienen como habilidad, satisfacer necesidades explícitas o implícitas. Otra definición bastante completa de calidad en el software es la que se presenta más adelante: Se puede decir que el software tiene calidad si cumple o excede las expectativas del usuario en cuanto a:
1. Funcionalidad (que sirva un propósito),
2. Ejecución (que sea práctico),
3. Confiabilidad (que haga lo que debe),
4. Disponibilidad (que funcione bajo cualquier circunstancia) y
5. Apoyo, a un costo menor o igual al que el usuario está dispuesto a pagar.
Resumiendo podemos decir, que la calidad de software se refiere a: “Los factores de un producto de software que contribuyen a la satisfacción completa y total de las necesidades de un usuario u organización”.
IMPORTANCIA DE LA CALIDAD
La calidad del software puede parecer un concepto alejado de la vida diaria de la mayoría de las personas, pero nada más lejos de la realidad.; ejemplo: cuando en un restaurante se bloquea el sistema de cobro, estamos ante un problema de calidad del software. Es probable que se haya sufrido los efectos de estos problemas de calidad en forma de retrasos, pérdidas de tiempo o dinero, etc. Estos problemas pueden ser mucho más graves cuando afectan graves pérdidas económicas o problemas ambientales o sociales.
Los fallos de software afectan a todos los sectores y a todos los países, actualmente se desarrolla software fiable y correcto a un costo razonable. Los auténticos profesionales y las empresas bien organizadas son prudentes y saben que deben aplicar distintas técnicas de control y prevención, además de un buen proceso de desarrollo.
factores de calidad
Entre los factores que Determinan la Calidad existen dos tipos de factores:
Factores que pueden ser medidos directamente (errores/KLDC/unidad de tiempo).
Factores que solo pueden ser medidos indirectamente (la facilidad de uso o de mantenimiento).
En ambos casos se puede medir la calidad, debemos comparar el software (documentos, programas, etc.) con alguna referencia y llegar a una indicación de calidad.
Factores de Calidad según McCall
PUNTO DE VISTA
|
FACTOR
|
REVISIÓN DEL PRODUCTO
|
Mantenibilidad
|
Flexibilidad
| |
Testeabilidad
| |
TRANSICIÓN DEL PRODUCTO
|
Portabilidad
|
Reusabilidad
| |
Interoperabilidad
| |
OPERACIÓN DEL PRODUCTO
|
Correctitud
|
Confiabilidad
| |
Eficiencia
| |
Integridad
| |
Usabilidad
|
El modelo que presenta Boehm presenta una jerarquía de características donde cada una de ellas contribuye a la calidad global. Dentro de los factores que se describen en el modelo se toman muchos de los que propone McCall. Parte de la estructura del modelo de Boehm se presenta en la siguiente figura, se hace énfasis en los factores presentes en dicho modelo. En total el modelo de Boehm presenta siete factores:
Factores de Calidad según ISO 9126
Es un modelo jerárquico con seis atributos especiales.
Aseguramiento de la calidad del software
Surgimiento de SQA (Software Quality Assurance)
En los años 50, el software comenzó a encontrar su camino dentro de los sistemas del
DoD (del inglés Deparment of Defense of USA). Usualmente estos proyectos estaban
muy alejados de la planificación, se pasaban del presupuesto y tenían muchos
problemas técnicos. Frecuentemente no funcionaban como se esperaba y muchos
proyectos eran cancelados antes de ser entregados. Durante este periodo los contratistas
para el desarrollo de software a menudo hacían estimaciones muy optimistas sobre el
estado del desarrollo del software. El DoD normalmente no era notificado de los
problemas en la planificación, en la gestión del presupuesto y de problemas técnicos
hasta muy avanzado el proyecto, cuando ya no eran capaces de entender los problemas
ni de evaluar el impacto de éstos.
Para intentar resolver este problema se estableció la Verificación y Validación
Independientes(IV&V del inglés Independent Verification and Validation), un proceso
de ingeniería que empleaba metodologías rigurosas para evaluar la correctitud y calidad
del software a lo largo de su ciclo de vida.
El primer software en usar IV&V fue el programa del misil atlas a finales de los años
50. Desde el proyecto atlas se ha recolectado mucha información que indica que los
proyectos con IV&V se realizan o ejecutan mucho mejor que los proyectos sin IV&V.
Con el tiempo el rol del IV&V se convirtió critico.
La actividad que llamamos SQA evoluciona directamente de la Verificación y
Validación Independientes(IV&V), muchas de las tareas que asociamos con SQA son
originarias de IV&V.
Luego durante los años 70 la actividad de desarrollo de software comenzó a expandirse
y las compañías de desarrollo de software fueron experimentando los mismos pobres
resultados que las agencias gubernamentales(DoD, NASA etc.) en las décadas
tempranas. Las compañías tenían dificultad para entregar el software dentro de los
plazos, presupuesto y calidad planificados. Varios proyectos desarrollados entre 1980 y
1990 fueron desastrosos, muchos excedían ampliamente el presupuesto y la
planificación o entregaban software de baja calidad que no se podía usar.
Durante los 80 esta experiencia se convirtió en lo que conocemos como crisis del
software, el tiempo consumido en el mantenimiento excedía el tiempo insumido en la
construcción de nuevos productos de software.
Definición de SQA (Software Quality Assurance)
Al igual que ocurrió con la definición de calidad hay varios puntos de vista desde donde
se puede definir el aseguramiento de la calidad del software.
Desde el punto de vista de la evidencia, la IEEE define el aseguramiento de la calidad
como
“Una guía planificada y sistemática de todas las acciones necesarias para proveer la
evidencia adecuada de que un producto cumple los requerimientos técnicos
establecidos.
Un conjunto de actividades diseñadas para evaluar el proceso por el cual un
producto es desarrollado o construido.”
Estándares y Métricas De Calidad en la Ingeniería de Software
ESTÁNDARES
Los estándares de calidad de software son normas emitidas por organismos específicos, que sirven para sentar un marco con el que comparar si un proceso de desarrollo es o no de calidad. Las normas de calidad del software más conocidas han sido desarrolladas por ISO, y son la serie ISO-9000.
1.-ISO 9000
Las normas ISO-9000 son un estándar de calidad para todo tipo de industrias; contiene una normativa específica para el desarrollo de software, la ISO-9003. Consiste en una serie de cláusulas que deben aplicarse en el marco de trabajo, en el ciclo de vida del proyecto y en las actividades de apoyo al mismo.
2.-CMMI
CMM fue desarrollado por el Software Engineering Institute en estados unidos, sirve para comprobar la habilidad de los procesos de las organizaciones para realizar determinados proyectos.
3.-SPICE
SPCE es el modelo de madurez propuesto por ISO, similar a CMMI.
Factores de calidad
Los factores de calidad sirven para descomponer el concepto genérico de “calidad”; para facilitar su control y su medición. Se clasifican en:
1- Factores operativos
Los factores operativos son aquellos que afectan al uso del software.
2- Factores de mantenimiento
Los factores de mantenimiento son aquellos que se aplican a la capacidad de modificación del software.
3- Factores evolutivos
Los factores evolutivos son aquellos que indican si el software se puede trasladar con facilidad a otra máquina o a otro producto de base (SO, SGBD).
MÉTRICAS
Las métricas del producto son una medida cuantitativa que permite a la gente del software tener una visión profunda de la eficacia del proceso del software y de los proyectos que dirigen utilizando el proceso como un marco de trabajo;son analizadas y evaluadas por los administradores del software.
VENTAJAS DEL USO DE METRICAS:
-Determina la calidad del producto.
-Evalúa la productividad de los desarrolladores.
-Se tiene conocimiento cuantitativo de las características del proceso y del producto.
-Se tiene un soporte para la estimación y la planificación.
Se evalúan los beneficios (en cuanto a calidad y productividad) derivados del uso de nuevos métodos y herramientas de ingeniería del software.
-Establece una línea base para la estimación
CARACTERISTICAS DE LAS METRICAS:
-ExactasPrecisas: No se debe perder información en los redondeos ya que la información se desvirtúa.
-Consistentes: Una medición de un atributo debe dar el mismo valor independientemente de la medición.
Modelos de Madurez
Esto se consigue mediante el cumplimiento de cuatro objetivos:• Acelerar la introducción en las organizaciones de producción de software de las prácticas y
técnicas de ingeniería del software más eficaces y eficientes, identificando, evaluando y mejorando
aquellas que se consideren útiles.
• Mantener a largo plazo la competencia en ingeniería del software y en la gestión del cambio
tecnológico.
• Habilitar a organizaciones privadas y públicas, trabajando con ellas, para que hagan mejoras en
sus prácticas de ingeniería del software.
• Fomentar la adopción y uso continuo de estándares de excelencia en prácticas de ingeniería del
software.
Modelo de Madurez de la Capacidad del Software
CMMI.
En el Modelo de Madurez de la Capacidad del Software del SEI (Software Capability Maturity
Model, SW-CMM) se definen un conjunto de áreas clave del proceso, que describen las funciones
de ingeniería del software que deben llevarse a cabo para el desarrollo de una buena práctica,
agrupadas en cinco niveles inclusivos. Estos niveles sirven de referencia para el conocimiento del
estado de la madurez del proceso del software en la organización. Mediante un amplio conjunto de
métricas se determina la calidad de cada una de las áreas clave, obteniéndose una visión precisa del
rigor, la eficacia y la eficiencia de la metodología de desarrollo de una organización productora de
software. Cada una de las áreas está organizada en cinco secciones, denominadas características
comunes:
• Compromiso de realización.
• Capacidad para llevarla a cabo.
• Actividades que hay que realizar.
• Medición y análisis.
• Verificación de la implementación.
En cada característica común se especifican unas prácticas clave, que son normas, procedimientos
y actividades cuya realización lleva a la consecución de los objetivos del área. En algunos casos se
detallan subprácticas más específicas, guías e interpretaciones de la práctica y, cuando procede,
ejemplos y referencias cruzadas a otras prácticas. Por ejemplo, las prácticas de la característica
medición y análisis describen las medidas que se han de realizar sobre el área de proceso
Universidad Autónoma Metropolitana. Auditoría Informatica.
Gauss García Alonso
Gastón Hidalgo Marquez. 2
correspondiente.
Tal como hemos dicho al principio de este apartado, los niveles en los que se agrupan las áreas
claves de proceso son inclusivos: para alcanzar uno es necesario haber alcanzado (y mantener)
todos los anteriores:
Inicial
repetible
definido
gestionado
Optimizado.
Seguidamente ofrecemos una breve descripción de cada uno de estos niveles:
Inicial
Está caracterizado por una aproximación intuitiva al proceso de desarrollo del software. El éxito
depende del esfuerzo individual. No se han definido procesos metodológicos, o se han definido pero
no se siguen. Es necesario realizar medidas de línea base, es decir, medidas que servirán para
estimar y planificar en el futuro. Asimismo, es el momento de hacer un esfuerzo de estructuración y
control en el proceso.
Repetible
La madurez metodológica de la organización permite estimar fiablemente el tamaño funcional o
físico del sistema, así como recursos, esfuerzo, costes y calendario. Se han sentado las bases para
repetir éxitos anteriores en proyectos con aplicaciones similares.
Las áreas clave de proceso definidas en este nivel, cuyo estado se puede conocer mediante diversas
métricas, son las siguientes:
1. Gestión de requisitos.
2. Planificación del proyecto software.
3. Seguimiento y control del proyecto.
4. Gestión de la subcontratación del software.
5. Aseguramiento de la calidad del software.
6. Gestión de la configuración del software.
Por ejemplo, en el área 6 se pueden medir el número de peticiones de cambio procesadas por unidad
de tiempo y los fondos empleados en gestión de configuración.
Definido
Se conoce la forma de construcción del sistema. El proceso del software de las actividades
de gestión e ingeniería se documenta y se estandaraiza. Las actividades intermedias están bien
definidas, y por tanto se puede examinar y medir. Por ejemplo, se pueden medir la complejidad
ciclomática del código, los defectos descubiertos o la densidad de errores por producto. Además es
posible detectar tempranamente posibles problemas y aplicar una adecuada gestión de riesgo.
Universidad Autónoma Metropolitana. Auditoría Informatica.
Gauss García Alonso
Gastón Hidalgo Marquez. 3
Las áreas clave definidad de este nivél son:
1. Desarrollo y mejora de los procesos de la organización.
2. Definición de los procesos de la organización.
3. Programa de formación.
4. Gestión integrada del software.
5. Ingeniería de producto software.
6. Coordinación intergrupos.
7. Revisión conjunta.
Por ejemplo, en el área 1 se podría medir el esfuerzo empleado en las actividades de evaluación,
desarrollo y mejora de los procesos de la organización comparado con el plan. En el área 2 se
podría medir el coste de las actividades de definición del proceso.
Gestionado
Se añade la gestión a un proceso definido. Se usa realimentación desde las primeras actividades del
proyecto para seleccionar prioridades en las actividades actuales y conocer cómo se emplean los
recursos. Los efectos de los cambios en una actividad se pueden seguir en otras. Se recopilan
medidas
detalladas del proceso del software y de la calidad del producto. En definitiva, se evalúa la
efectividad de las actividades del proceso. Por ejemplo, se podría medir cuánto se está produciendo
para ser reutilizado, cuánto se está reutilizando de proyectos anteriores, cómo y cuándo son
descubiertos los defectos y la relación entre fchas de finalización de los módulos y fechas previstas.
Las áreas clave definidas en este nivel son dos:
1. Gestión cuantitativa del proyecto.
2. Gestión de calidad del software.
Optimizado
Existe una mejora continua de los procesos. Las medidas de actividades se usan para mejorar el
proceso, eliminando y añadiendo actividades y reorganizando su estructura como respuesta a los
resultados de las medidas.
Las áreas definidas para este nivel son:
1. Prevención de defectos.
2. Gestión de cambios tecnológicos
3. Gestión de cambios en los procesos.
Por ejemplo, en el área 2 se podrían medir los efectos de la implementación de los cambios
tecnológicos comparados con los objetivos. En el área 3 se podría medir el número de propuestas de
mejora enviadas por departamento.
Universidad Autónoma Metropolitana. Auditoría Informatica.
Gauss García Alonso
Gastón Hidalgo Marquez. 4
¿Qué es CMMI?
CMMI (Capability Maturity Model Integration) es un conjunto de modelos elaborados por el SEI
que permiten obtener un diagnóstico preciso de la madurez de los procesos relacionados con las
tecnologías de la información de una organización, y describen las tareas que se tienen que llevar a
cabo para mejorar esos procesos.
Los módulos CMMI son extractos de los modelos CMMI a los que se han añadido posibles pruebas
a realizar, y sirven de base para emprender la mejora de procesos.
Existen actualmente cuatro modelos CMMI, que contemplan los procesos de mejora en las diversas
áreas de los sistemas de información de manera que la organización deberá elegir el que más se
ajuste a sus necesidades:
• CMMI-SE/SW/IPPD/SS
• CMMI-SE/SW/IPPD
• CMMI-SE/SW
• CMMI-SW
Enfoque de procesos
INTRODUCCIÓN
Un modelo de proceso es un conjunto de actividades, tareas y acciones que se realizan con el fin de alcanzar el desarrollo completo de un proyecto de software.
Existen diferentes modelos de proceso tales como los prescriptivos que se utilizan cuando los requerimientos de software se encuentran bien definidos, los especializados que incluyen las características de uno o más modelos tradicionales y se utilizan cuando el enfoque del proyecto se encuentra bien definido.
Dentro de los modelos de proceso especializado podemos encontrar el desarrollo basado en componentes, los métodos formales y el desarrollo orientado a aspectos, este último se encuentra aún en etapa de desarrollo ya que busca definir la forma de especificar, diseñar y construir aspectos ( mecanismos más allá de subrutinas y herencia para localizar la expresión de una preocupación global).
A continuación se definen las características del modelo de proceso especializado, además del proceso unificado y los modelos de proceso personal y de equipo que tiene un enfoque dirigido al trabajo en equipo por así decirlo.
2. OBJETIVO
Conocer sobre los modelos de proceso especializados su clasificación y en qué proyectos se utiliza, además de analizar el desarrollo de software a través del proceso unificado o el modelo de proceso personal y de equipo.
3. MARCO TEÓRICO
3.1. Modelos de proceso Especializados
Los modelos de proceso especializado tienen muchas de las características de uno o más de los modelos tradicionales que se presentaron en las secciones anteriores. Sin embargo, dichos modelos tienden a aplicarse cuando se elige un enfoque de ingeniería de software especializado o definido muy específicamente.
Los modelos de proceso especializados son los siguientes:
1
Figura 1: Modelos de proceso especializados
3.2. El proceso Unificado
El proceso unificado es un intento por obtener los mejores rasgos y características de los modelos tradicionales del proceso del software, pero en forma que implemente muchos de los mejores principios del desarrollo ágil de software. El proceso unificado reconoce la importancia de la comunicación con el cliente y los métodos directos para describir su punto de vista respecto de un sistema. Sugiere un flujo del proceso iterativo e incremental, lo que da la sensación evolutiva que resulta esencial en el desarrollo moderno del software.
2
Figura 2: Modelos de proceso Unificado
La fase de concepción del PU agrupa actividades tanto de comunicación con el cliente como de planeación. Al colaborar con los participantes, se identifican los requerimientos del negocio, se propone una arquitectura aproximada para el sistema y se desarrolla un plan para la naturaleza iterativa e incremental del proyecto en cuestión.
3.3. Modelos de proceso Personal y de equipo
El mejor proceso del software es el que está cerca de las personas que harán el trabajo. Si un modelo del proceso del software se ha desarrollado en un nivel corporativo u organizacional, será eficaz sólo si acepta una adaptación significativa para que cubra las necesidades del equipo de proyecto que en realidad hace el trabajo de ingeniería de software.
3.3.1. Proceso personal del software
El proceso personal del software (PPS) pone el énfasis en la medición personal tanto del producto del trabajo que se genera como de su calidad. Además, el PPS responsabiliza al profesional acerca de la planeación del proyecto (por ejemplo, estimación y programación de actividades) y delega en el practicante el poder de controlar la calidad de todos los productos del trabajo de software que se desarrollen. El modelo del PPS define cinco actividades estructurales:
3
Figura 3: Modelos de proceso Personal
3.3.2. Proceso del equipo de software
El objetivo de éste es construir un equipo “autodirigido” para el proyecto, que se organice para producir software de alta calidad.
Los objetivos que se definen para el proceso del equipo de software son los siguientes:
Formar equipos autodirigidos que planeen y den seguimiento a su trabajo, que establezcan metas y que sean dueños de sus procesos y planes.
Mostrar a los gerentes cómo dirigir y motivar a sus equipos y cómo ayudarlos a mantener un rendimiento máximo.
Acelerar la mejora del proceso del software, haciendo del modelo de madurez de la capacidad, CMM,23 nivel 5, el comportamiento normal y esperado.
Brindar a las organizaciones muy maduras una guía para la mejora.
Facilitar la enseñanza universitaria de aptitudes de equipo con grado industrial.
El PES define las siguientes actividades estructurales: inicio del proyecto, diseño de alto nivel, implementación, integración y pruebas, y post mórtem. Como sus contrapartes del PPS (observe que la terminología es algo diferente), estas actividades permiten que el equipo planee, diseñe y construya software en forma disciplinada, al mismo tiempo que mide cuantitativamente el proceso y el producto. La etapa post mórtem es el escenario de las mejoras del proceso.
PSP Y TSP
PSP
PSP (Personal Software Process), un enfoque práctico
Desde que me mencionaron Personal Software Process (PSP) supe que algo de interesante había en él. Por lo que como todo buen investigador, decidí comenzar a incursionar para ver que cualidades podía ofrecerme al trabajo del día a día.
Obviamente lo primero, era dar con el material de origen de sus creados, y gracias a la guía de mi profesor de Estimación y Métricas (Magister en Ingeniería Informática, Unab, Chile), pude obtener el material tan anhelado en PDF, obtenido desde el SEI (Software Engineering Institute, http://www.sei.cmu.edu/), el cual se puede descargar desde acá: http://www.sei.cmu.edu/tsp/tools/index.cfm.
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. PSP son nuestras propias métricas, que permiten estructurar y ordenar nuestro trabajo del día a día (no solo de desarrollo de software, esto lo voy a explicar mas adelante). El resultado de nuestro trabajo, además puede ser llevado a un trabajo en equipo TSP (Team Process Software), el cual es “comandado” por un sistema de gestión de la configuración y por supuesto, un Jefe de Proyecto quien evalúa los resultados y avances de los miembros del equipo.
En el campo del desarrollo del software son pocas las organizaciones que siguen o cumplen planes de trabajo o
metodologías establecidas para desarrollar software (conozco varias que no siguen este proceso), poniendo en duda su calidad; muchos de estos proyectos llegaron al fracaso porque sobrepasaron los costos estimados y/o sobrepasaron los tiempos de planificación. Muchos de estos sistemas que tenían defectos produjeron en algún momento perdida de vidas humanas. Proyectos de millones de dólares que no han cumplidos sus objetivos y su tiempo de planificación dejaron millones de usuarios insatisfechos, principalmente aquellos que trabajan mediante una aplicación de software. Algunas principales causas para que el proceso de desarrollo de software pueden ser que : el personal de desarrollo no se involucre lo suficiente en el control de calidad del producto, la alta dirección no esta consciente de la verdadera importancia del proyecto a causa de que no se cuentan los recursos necesarios (dinero, tiempo, tecnología), las prácticas establecidas no son las adecuadas, las empresas se centran en cómo pero no tienen claro el qué, (Vamos a desarrollar esta aplicación en Biztalk Server con este Framework porque es el último del mercado y además tenemos que aprovechar las licencias… a quien no le ha pasado), la relación problema/necesidad muchas veces no existe, no se preocupan de analizar si los objetivos del proyecto; tienen cobertura con los objetivos de la empresa, etc etc (Echemosle para adelante no mas, en el camino lo vamos arreglando!).
En la actualidad la tecnología avanza a pasos agigantados, así también existe un avance en las metodologías y herramientas para el desarrollo de software. Una de estas metodologías es el denominado Personal Software Process (PSP) diseñado por Watts S. Humphrey del Software Engineering Institute en la Carnegie Mellon University.
La producción de software, debe convertirse en un proceso industrial, que sea medible, cuantificable, testeable, que sea un proceso disciplinado y aceptado por todos. El ciclo de vida clásico (Waterfall) que todos conocemos es el cascada, que tiene las siguiente etapas:
· Análisis de Requerimientos
· Diseño
· Programación
· Pruebas
· Implantación
· Mantenimiento
Esta metodología era muy usada, cuando las actividades eran secuenciales, y ayudaba bastante, pero hoy en día, ya no tenemos este tipo de actividades tan secuenciales, tenemos procesos que se orientan mas al cliente y al producto para satisfacer las necesidades del cliente en distintas fases (llamadas iteraciones), en donde en cada iteración, el cliente puede ver un producto tangible y probarlo. SCRUM es una de estas metodologías. Actualmente existen diversas metodologías de ingeniería del software que guían a los programadores a dar un mejor seguimiento a sus programas, dentro de las que podemos mencionar: COCOMO I, COCOMO II, PROBE (Proxy Based Estimation), etc etc. En algún otro POST vamos a hablar mas a fondo de estimación y métricas en el desarrollo de software.
Volviendo a PSP, es una técnica probada para mejorar el funcionamiento y la productividad individuales de los ingenieros. Surge de la necesidad que tienen los Ingenieros de Software de automatizar sus procesos.
PSP fue diseñado para ayudar a los profesionales del software para que utilicen constantemente practicas sanas de ingeniería del software, enseñándoles a planificar y dar seguimiento a un trabajo, utilizar un proceso bien definido y medido, a establecer metas mesurables y finalmente a rastrear constantemente para obtener las metas definidas (quiero hacer un paralelo en esto último mencionando una técnica bastante entretenida llamada GQM -Goal Question Metrics-).
El PSP es una versión pequeña de CMM donde se preocupa solo por un conjunto de las KPAs (Key Process Areas). La estructura de PSP es como sigue:
Los principios de PSP son:
Cada ingeniero es diferente, para ser mas eficiente, debe planificar su trabajo basándose en su experiencia personal.
Usar procesos bien definidos y cuantificados
Los ingenieros deben asumir la responsabilidad personal de la calidad de sus productos.
Cuanto antes se detecten y corrijan los errores menos esfuerzo será necesario
Es mas efectivo evitar los defectos que detectarlos y corregirlos.
Trabajar bien es siempre la forma mas rápida y económica de trabajar.
El PSP se caracteriza porque es de uso personal y se aplica a programas pequeños de menos de 10.000 líneas de código. Se centra en la administración del tiempo y en la administración de la calidad a través de la eliminación temprana de defectos.
En la próxima entrega, vamos a hablar un poco acerca de los niveles de PSP, y como 14 KPA’s de PSP son posible mapearlas con 18 KPA’s de CMMi.
Algunas pantallas del software que yo uso para llevar por ejemplo, un proyecto de investigación personal usando los principios de PSP, las adjunto mas abajo:
Desde que me mencionaron Personal Software Process (PSP) supe que algo de interesante había en él. Por lo que como todo buen investigador, decidí comenzar a incursionar para ver que cualidades podía ofrecerme al trabajo del día a día.
Obviamente lo primero, era dar con el material de origen de sus creados, y gracias a la guía de mi profesor de Estimación y Métricas (Magister en Ingeniería Informática, Unab, Chile), pude obtener el material tan anhelado en PDF, obtenido desde el SEI (Software Engineering Institute, http://www.sei.cmu.edu/), el cual se puede descargar desde acá: http://www.sei.cmu.edu/tsp/tools/index.cfm.
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. PSP son nuestras propias métricas, que permiten estructurar y ordenar nuestro trabajo del día a día (no solo de desarrollo de software, esto lo voy a explicar mas adelante). El resultado de nuestro trabajo, además puede ser llevado a un trabajo en equipo TSP (Team Process Software), el cual es “comandado” por un sistema de gestión de la configuración y por supuesto, un Jefe de Proyecto quien evalúa los resultados y avances de los miembros del equipo.
En el campo del desarrollo del software son pocas las organizaciones que siguen o cumplen planes de trabajo o
metodologías establecidas para desarrollar software (conozco varias que no siguen este proceso), poniendo en duda su calidad; muchos de estos proyectos llegaron al fracaso porque sobrepasaron los costos estimados y/o sobrepasaron los tiempos de planificación. Muchos de estos sistemas que tenían defectos produjeron en algún momento perdida de vidas humanas. Proyectos de millones de dólares que no han cumplidos sus objetivos y su tiempo de planificación dejaron millones de usuarios insatisfechos, principalmente aquellos que trabajan mediante una aplicación de software. Algunas principales causas para que el proceso de desarrollo de software pueden ser que : el personal de desarrollo no se involucre lo suficiente en el control de calidad del producto, la alta dirección no esta consciente de la verdadera importancia del proyecto a causa de que no se cuentan los recursos necesarios (dinero, tiempo, tecnología), las prácticas establecidas no son las adecuadas, las empresas se centran en cómo pero no tienen claro el qué, (Vamos a desarrollar esta aplicación en Biztalk Server con este Framework porque es el último del mercado y además tenemos que aprovechar las licencias… a quien no le ha pasado), la relación problema/necesidad muchas veces no existe, no se preocupan de analizar si los objetivos del proyecto; tienen cobertura con los objetivos de la empresa, etc etc (Echemosle para adelante no mas, en el camino lo vamos arreglando!).
En la actualidad la tecnología avanza a pasos agigantados, así también existe un avance en las metodologías y herramientas para el desarrollo de software. Una de estas metodologías es el denominado Personal Software Process (PSP) diseñado por Watts S. Humphrey del Software Engineering Institute en la Carnegie Mellon University.
La producción de software, debe convertirse en un proceso industrial, que sea medible, cuantificable, testeable, que sea un proceso disciplinado y aceptado por todos. El ciclo de vida clásico (Waterfall) que todos conocemos es el cascada, que tiene las siguiente etapas:
· Análisis de Requerimientos
· Diseño
· Programación
· Pruebas
· Implantación
· Mantenimiento
Esta metodología era muy usada, cuando las actividades eran secuenciales, y ayudaba bastante, pero hoy en día, ya no tenemos este tipo de actividades tan secuenciales, tenemos procesos que se orientan mas al cliente y al producto para satisfacer las necesidades del cliente en distintas fases (llamadas iteraciones), en donde en cada iteración, el cliente puede ver un producto tangible y probarlo. SCRUM es una de estas metodologías. Actualmente existen diversas metodologías de ingeniería del software que guían a los programadores a dar un mejor seguimiento a sus programas, dentro de las que podemos mencionar: COCOMO I, COCOMO II, PROBE (Proxy Based Estimation), etc etc. En algún otro POST vamos a hablar mas a fondo de estimación y métricas en el desarrollo de software.
Volviendo a PSP, es una técnica probada para mejorar el funcionamiento y la productividad individuales de los ingenieros. Surge de la necesidad que tienen los Ingenieros de Software de automatizar sus procesos.
PSP fue diseñado para ayudar a los profesionales del software para que utilicen constantemente practicas sanas de ingeniería del software, enseñándoles a planificar y dar seguimiento a un trabajo, utilizar un proceso bien definido y medido, a establecer metas mesurables y finalmente a rastrear constantemente para obtener las metas definidas (quiero hacer un paralelo en esto último mencionando una técnica bastante entretenida llamada GQM -Goal Question Metrics-).
El PSP es una versión pequeña de CMM donde se preocupa solo por un conjunto de las KPAs (Key Process Areas). La estructura de PSP es como sigue:
Los principios de PSP son:
Cada ingeniero es diferente, para ser mas eficiente, debe planificar su trabajo basándose en su experiencia personal.
Usar procesos bien definidos y cuantificados
Los ingenieros deben asumir la responsabilidad personal de la calidad de sus productos.
Cuanto antes se detecten y corrijan los errores menos esfuerzo será necesario
Es mas efectivo evitar los defectos que detectarlos y corregirlos.
Trabajar bien es siempre la forma mas rápida y económica de trabajar.
El PSP se caracteriza porque es de uso personal y se aplica a programas pequeños de menos de 10.000 líneas de código. Se centra en la administración del tiempo y en la administración de la calidad a través de la eliminación temprana de defectos.
En la próxima entrega, vamos a hablar un poco acerca de los niveles de PSP, y como 14 KPA’s de PSP son posible mapearlas con 18 KPA’s de CMMi.
Algunas pantallas del software que yo uso para llevar por ejemplo, un proyecto de investigación personal usando los principios de PSP, las adjunto mas abajo:
TSP
La presente investigación se basa en varias fuentes verídicas, las cuáles se menciona al final de documento.
El TSP (Team Software Process – Equipo de Procesos de Software) tiene como propósito integrar un equipo de trabajo que tenga como punto de partida la unificación de procesos, para poder llevar a cabo todos aquellos procedimientos que puedan ayudar a mejorar dichos procesos que desarrollan.
“Todos tenemos una manera particular de trabajar, pero en las Tecnologías de la Información, debemos ser capaces de adaptarnos a estándares que nos permiten desempeñarnos en cualquier ambiente y en cualquier industria. Para ello existen certificaciones como TSP” Jorge Salgado, editor en jefe de developerWorks.
“Es esencialmente el conjunto de prácticas de estrategias que debe seguir un administrador para poder aprovechar el valor que le ofrece a una empresa o grupo de trabajo, contar con un equipo de personas capacitadas” Walter Arriaga, Líder de arquitectura de
soluciones para México de Softek.
Básicamente TSP es un proceso de desarrollo para equipos de ingenieros, basados en CMMI, sobre software de calidad, resuelve problemas como predicción de costo y tiempo, mejora de la productividad y ciclos de desarrollo y mejora de calidad de productos.
Los orígenes de TSP se deben a las restricciones que tiene el PSP (Personal Software Process) dentro del ámbito industrial. PSP terminó siendo altamente efectivo para que los ingenieros pudieran tener el control de su PSP mejorando sus habilidades de estimación y la reducción de los defectos que tenían los productos sin afectar a su productividad. Al igual que cualquier modelo de
administración de proyectos, TSP comienza con un proceso de inicio del proyecto en el que se establecen las estrategias, los objetivos, los roles y responsables de cada uno de esos roles en el proyecto, planes individuales, métricas, etc., y se reparte el trabajo, se ejecuta y se le da seguimiento, al final se determina que tan cerca o que tan lejos se estuvo al ejecutar los planes y que tan buena o que tan mala fue la calidad del trabajo hecho.
TSP provee elementos muy concretos asi como formatos y practicas muy específicas para que cada una de estas cosas suceda de una manera particular y concreta, para que sea correctamente medible, para que sea posteriormente analizable y mejorable. El resultado final de todo esto es que un equipo de trabajo que funciona con TSP y PSP cumple en primera instancia con todos los elementos de una certificación de CMMI.
Blog de David Alejandro Gómez:
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 STP 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. TSP 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
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 y 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:
1. Lanzamiento
2. Estrategia
3. Plan
4. Requisitos
5. Diseño
6. Implementación
7. Pruebas
8. Postmortem
SO decide que sea un desarrollo un estándar para la evaluación de procesos, pero por pasos:
1. Publicación inicial como Informe Técnico ‘Technical Report’ (“borrador de estándar”) para que después de su uso real pase.
2. Revisión y publicación como estándar internacional IS ISO/IEC 15504 – Tecnologías de la Información – Evaluación de Procesos (‘ISO/IEC 15504 – Information Technology – Process Assessment’).
Las siglas SPICE significan: Software Process Improvement and Capability determinación, es decir Determinación de la capacidad y mejora de los procesos de SW
El proyecto SPICE tenía tres objetivos principales:
- desarrollar un borrador de trabajo para un estándar para la evaluación de procesos de software.
- para llevar a cabo los ensayos de la industria de la norma emergente.
- promover la transferencia de tecnología de la evaluación de procesos de software a la industria del software a nivel mundial.
El primer objetivo del proyecto se logró en junio de 1995, con la entrega del borrador de trabajo de la norma para la evaluación de procesos de software al WG10 para su votación entre la comunidad de estandarización internacional.
El Borrador de Trabajo se denominaba comúnmente como el conjunto de documentos SPICE (o SPICE Versión 1).
Este primer borrador se basó en otros modelos existentes en aquél momento.
Los ensayos de estos primeros documentos SPICE han sido el foco del proyecto SPICE durante el período 1994 a 1998. Fue entonces, en 1998 cuando se publicó la primera familia de estándares ISO TR 15504.
Desde entonces ya se comenzó a trabajar en la versión de Internacional Standard de la norma, y ahora (desde 2006) está completamente publicado excepto de partes nuevas que aun se están produciendo.
En marzo de 2003, el proyecto SPICE se ha cerrado oficialmente. La Red SPICE se estableció posteriormente con el mandato de seguir coordinando las actividades dentro de la comunidad SPICE. La Red de SPICE está formalmente organizada por el ‘The Spice User Grupo’ (www.spiceusergroup.org).
Las actividades promocionales están en curso y se realizan a través de la Conferencia Internacional SPICE Anual y la publicación de artículos y libros.
Con el fin de apoyar la excelencia y la coherencia de la formación de los evaluadores, el proyecto SPICE también desarrolló y lanzó un Plan de Estudios de formación de los evaluadores SPICE que es utilizado actualmente por el Esquema de Registro Internacional de Evaluadores (IntRSA) – www.intrsa.org.
En el capítulo de ‘Roles’ se desarrollan más estos detalles de cualificación y responsabilidades de diferentes roles que se necesitan en los procesos de evaluación y/o mejora.
Características
Establece un marco y los requisitos para cualquier procesos de evaluación de procesos y proporciona requisitos para los modelos de evaluación a ser utilizados.
Proporciona también requisitos para cualquier modelos de evaluación de organizaciones.
Proporciona guías para la definición de las competencias de un evaluador de procesos.
Actualmente tiene 10 partes: 1-7 completadas y 8-10 en fase de desarrollo.
Comprende: evaluación de procesos, mejora de procesos, determinación de capacidad.
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. Sin embargo CMMI-DEV aún no es un modelo conforme (según lo requiere la ISO 15504 para todo modelo de evaluación de procesos).
Dimensiones
Tiene una arquitectura basada en dos dimensiones:
de proceso y de capacidad de proceso. Define que todo modelo de evaluación de procesos debe definir:
- la dimensión de procesos: el modelo de procesos de referencia (dimensión de las abscisas)
- la dimensión de la capacidad: niveles de capacidad y atributos de los procesos.
Los niveles de capacidad para todo modelo de evaluación de procesos pueden tener desde el 0 y al menos hasta el nivel 1 de los siguientes niveles de capacidad estándar:
Nivel 0: Incompleto
Nivel 1: Realizado
Nivel 2: Gestionado
Nivel 3: Establecido
Nivel 4: Predecible
Nivel 5: En optimización
Para cada nivel existen unos atributos de procesos estándar que ayudan a evaluar los niveles de capacidad.
Ejemplos de Modelos de evaluación de procesos
ISO/IEC 15504 - 5 modelos de evaluación de procesos de ciclo de vida de software
Por ejemplo, el modelo de evaluación de procesos de software, contenido en la Parte 5 de la Norma ISO/IEC 15504 define su Modelo de procesos de referencia como los procesos contenidos en la norma ISO/IEC 12207 Amd1/Amd2,
que contienen tres categorías de procesos y cada una con diferentes grupos de procesos:
Dimensión procesos
Procesos Primarios:
ACQ: Procesos de Cliente
SPL: Procesos de Proveedor
ENG: Ingeniería
OPE: Procesos de operación
Procesos de soporte
SUP: Soporte
Procesos organizacionales
MAN: Gestión
REU: Procesos de rehusó
RIN: Recursos humanos e infraestructura
PIM: Procesos de mejora de procesos
Dimensión de la capacidad
La dimensión de capacidad del modelo de evaluación de procesos de software de la Parte 5 define un conjunto completo de indicadores para todos los atributos de procesos correspondientes a la escala de los 6 niveles de capacidad de la Parte 2 de la norma.
MODELO SPICE
SO decide que sea un desarrollo un estándar para la evaluación de procesos, pero por pasos:
1. Publicación inicial como Informe Técnico ‘Technical Report’ (“borrador de estándar”) para que después de su uso real pase.
2. Revisión y publicación como estándar internacional IS ISO/IEC 15504 – Tecnologías de la Información – Evaluación de Procesos (‘ISO/IEC 15504 – Information Technology – Process Assessment’).
Las siglas SPICE significan: Software Process Improvement and Capability determinación, es decir Determinación de la capacidad y mejora de los procesos de SW
El proyecto SPICE tenía tres objetivos principales:
- desarrollar un borrador de trabajo para un estándar para la evaluación de procesos de software.
- para llevar a cabo los ensayos de la industria de la norma emergente.
- promover la transferencia de tecnología de la evaluación de procesos de software a la industria del software a nivel mundial.
El primer objetivo del proyecto se logró en junio de 1995, con la entrega del borrador de trabajo de la norma para la evaluación de procesos de software al WG10 para su votación entre la comunidad de estandarización internacional.
El Borrador de Trabajo se denominaba comúnmente como el conjunto de documentos SPICE (o SPICE Versión 1).
Este primer borrador se basó en otros modelos existentes en aquél momento.
Los ensayos de estos primeros documentos SPICE han sido el foco del proyecto SPICE durante el período 1994 a 1998. Fue entonces, en 1998 cuando se publicó la primera familia de estándares ISO TR 15504.
Desde entonces ya se comenzó a trabajar en la versión de Internacional Standard de la norma, y ahora (desde 2006) está completamente publicado excepto de partes nuevas que aun se están produciendo.
En marzo de 2003, el proyecto SPICE se ha cerrado oficialmente. La Red SPICE se estableció posteriormente con el mandato de seguir coordinando las actividades dentro de la comunidad SPICE. La Red de SPICE está formalmente organizada por el ‘The Spice User Grupo’ (www.spiceusergroup.org).
Las actividades promocionales están en curso y se realizan a través de la Conferencia Internacional SPICE Anual y la publicación de artículos y libros.
Con el fin de apoyar la excelencia y la coherencia de la formación de los evaluadores, el proyecto SPICE también desarrolló y lanzó un Plan de Estudios de formación de los evaluadores SPICE que es utilizado actualmente por el Esquema de Registro Internacional de Evaluadores (IntRSA) – www.intrsa.org.
En el capítulo de ‘Roles’ se desarrollan más estos detalles de cualificación y responsabilidades de diferentes roles que se necesitan en los procesos de evaluación y/o mejora.
Características
Establece un marco y los requisitos para cualquier procesos de evaluación de procesos y proporciona requisitos para los modelos de evaluación a ser utilizados.
Proporciona también requisitos para cualquier modelos de evaluación de organizaciones.
Proporciona guías para la definición de las competencias de un evaluador de procesos.
Actualmente tiene 10 partes: 1-7 completadas y 8-10 en fase de desarrollo.
Comprende: evaluación de procesos, mejora de procesos, determinación de capacidad.
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. Sin embargo CMMI-DEV aún no es un modelo conforme (según lo requiere la ISO 15504 para todo modelo de evaluación de procesos).
Dimensiones
Tiene una arquitectura basada en dos dimensiones:
de proceso y de capacidad de proceso. Define que todo modelo de evaluación de procesos debe definir:
- la dimensión de procesos: el modelo de procesos de referencia (dimensión de las abscisas)
- la dimensión de la capacidad: niveles de capacidad y atributos de los procesos.
Los niveles de capacidad para todo modelo de evaluación de procesos pueden tener desde el 0 y al menos hasta el nivel 1 de los siguientes niveles de capacidad estándar:
Nivel 0: Incompleto
Nivel 1: Realizado
Nivel 2: Gestionado
Nivel 3: Establecido
Nivel 4: Predecible
Nivel 5: En optimización
Para cada nivel existen unos atributos de procesos estándar que ayudan a evaluar los niveles de capacidad.
Ejemplos de Modelos de evaluación de procesos
ISO/IEC 15504 - 5 modelos de evaluación de procesos de ciclo de vida de software
Por ejemplo, el modelo de evaluación de procesos de software, contenido en la Parte 5 de la Norma ISO/IEC 15504 define su Modelo de procesos de referencia como los procesos contenidos en la norma ISO/IEC 12207 Amd1/Amd2,
que contienen tres categorías de procesos y cada una con diferentes grupos de procesos:
Dimensión procesos
Procesos Primarios:
ACQ: Procesos de Cliente
SPL: Procesos de Proveedor
ENG: Ingeniería
OPE: Procesos de operación
Procesos de soporte
SUP: Soporte
Procesos organizacionales
MAN: Gestión
REU: Procesos de rehusó
RIN: Recursos humanos e infraestructura
PIM: Procesos de mejora de procesos
Dimensión de la capacidad
La dimensión de capacidad del modelo de evaluación de procesos de software de la Parte 5 define un conjunto completo de indicadores para todos los atributos de procesos correspondientes a la escala de los 6 niveles de capacidad de la Parte 2 de la norma.
CMMI
¿Qué es CMMI?
CMMI es un modelo que contiene las mejores prácticas y que provee a las organizaciones de aquellos elementos que son esenciales para que los procesos de negocio de las mismas sean efectivos.
El modelo CMMI fue inicialmente desarrollado para los procesos relativos al desarrollo e implementación de Software por la Carnegie-Mellon University. Este vio la luz por primera vez en el año 1987 como Capability Maturity Model CMM. Dicho nombre, tanto como los cinco niveles de la representación por etapas, están inspirados en el modelo de madurez Manufacturing Maturity Model de Crosby.
En principio el modelo CMM era aplicado en programas de defensa, pero lo cierto es que este ha logrado gran aceptación, tan es así que ha sido sometido a varias revisiones e iteraciones. Debido a su éxito se llevó a cabo el desarrollo de modelos CMM para para diversos ámbitos más allá del software.
El problema con esto, es que debido a la gran proliferación de modelos de desarrollo de software comenzaron a surgir confusiones, motivo por el que el gobierno terminó financiando un proyecto de dos años en que el participaron más de 200 expertos del mundo industrial y académico, con el fin de crear un solo marco extensible para la ingeniería de sistemas, la ingeniería de software y el desarrollo de productos ¿el resultado? El modelo más conocido actualmente: CMMI.
¿Por qué debe usarse un modelo?
Si no se dispone de un modelo de cómo funcionan las organizaciones, qué funciones necesitan y cómo interactúan estas funciones, es difícil encauzar los esfuerzos de mejora. Un modelo nos permite comprender los elementos específicos de las organizaciones y ayuda a formular y a hablar de lo que hay que mejorar y de cómo se pueden lograr dichas mejoras. Un modelo ofrece las siguientes ventajas:
- Proporciona
un marco y un lenguaje común, lo que se traduce en la ruptura de las barreras
de la comunicación en el interior de las organizaciones.
- Permite
que los usuarios puedan enfocarse específicamente en la mejora, ya que
ayudan a que no pierdan la idea global.
- Aporta
años de experiencia.
- Ayudan
a mejorar la satisfacción del cliente.
- Permiten
producir productos y servicios de alta calidad.
Propósito de un modelo CMMI y su variación según el enfoque
El propósito de un modelo CMMI varía según el enfoque, es decir, si buscamos en los libros de texto encontraremos que el propósito de este modelo es hacer la evaluación de la madurez de los procesos de una organización, para así poder proporcionar una orientación referente a cómo se pueden llevar a cabo las mejoras de aquellos procesos que darán lugar a mejores productos.
Por otra parte, si hablamos con personas del Software Engineering Institute, lo más seguro es que nos digan que CMMI es modelo para la administración de riesgos y que a su vez indica la capacidad que tiene una determinada organización para administrar esos riesgos. Esta indicación es precisamente el indicio de la probabilidad con la que una organización puede cumplir con sus promesas o brindar productos de alta calidad que resulten atractivos para el mercado.
Adicionalmente a estos dos, existe otro enfoque en el cual se dice que el modelo proporciona un buen indicador sobre el cómo una organización actuará ante determinadas situaciones de estrés. Una organización que cuente con una gran madurez, así como con altas capacidades, de seguro afrontará las situaciones inesperadas y de estrés con calma, lo que sin duda les permitirá reaccionar, hacer cambios y seguir adelante.
Por el contrario, una organización con poca madurez y bajas capacidades de seguro tenderá a dejarse llevar por el pánico ante situaciones de estrés, seguirá a ciegas aquellos procesos obviados, o bien, arruinará todos los procesos y volverá al caos.
Algunos beneficios de CMMI
Hacer uso del modelo CMMI para el desarrollo de software, no solo permite optimizar procesos de negocios, sino que también trae consigo una serie de beneficios, entre ellos los siguientes:
• La gestión y la ingeniería de las actividades se encuentran entrelazadas de una manera explícita, tan es así que facilita el reconocimiento de los objetivos del negocio.
• Permite hacer la incorporación de la experiencia adquirida en otras zonas de las mejores prácticas. Algunos ejemplos serían la medición, gestión de riesgos y de proveedores.
• Poder aplicar prácticas de alta madurez mucho más robustas.
• Cumplir de forma mucho más completa con las normas ISO.
Estos son solo algunos de los aspectos básicos del modelo CMMI que nos permiten tener un acercamiento al por qué es ideal para el proceso de desarrollo de software.
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.
Procesos que maneja Moprosoft:
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
o Recursos Humanos y Ambiente de Trabajo
o Bienes Servicios e Infraestructura
o 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
• El Programa para el Desarrollo de la Industria de Software (PROSOFT) fue implementado en octubre de 2002
• Recursos finales.
En cada categoría se establecen roles y actividades a desarrollar, así como un responsable, una empresa o persona se puede certificar en MOPROSOFT para poder aplicar el modelo a sus desarrollos de software.
Para aprender más de MOPROSOFT visita la comunidad del mismo en www.comunidadmoprosoft.org.mx El sitio está dirigido a todas las personas y organizaciones interesadas en conocer, adoptar, así como proveer servicios sobre el modelo, para compartir conocimientos y experiencias.
Apoyos del gobierno cuando se usa MOPROSOFT
La secretaría de economía del gobierno de México da a poyos a personas físicas y personas morales (empresas) para poder desarrollar proyectos de software, cumpliendo ciertos requisitos.
También hay apoyos para universidades desarrollando proyectos con estudiantes.
Para más información visita el siguiente video.
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.
Procesos que maneja Moprosoft:
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
o Recursos Humanos y Ambiente de Trabajo
o Bienes Servicios e Infraestructura
o 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
• El Programa para el Desarrollo de la Industria de Software (PROSOFT) fue implementado en octubre de 2002
• Recursos finales.
En cada categoría se establecen roles y actividades a desarrollar, así como un responsable, una empresa o persona se puede certificar en MOPROSOFT para poder aplicar el modelo a sus desarrollos de software.
Para aprender más de MOPROSOFT visita la comunidad del mismo en www.comunidadmoprosoft.org.mx El sitio está dirigido a todas las personas y organizaciones interesadas en conocer, adoptar, así como proveer servicios sobre el modelo, para compartir conocimientos y experiencias.
Apoyos del gobierno cuando se usa MOPROSOFT
La secretaría de economía del gobierno de México da a poyos a personas físicas y personas morales (empresas) para poder desarrollar proyectos de software, cumpliendo ciertos requisitos.
También hay apoyos para universidades desarrollando proyectos con estudiantes.
Para más información visita el siguiente video.
Comentarios
Publicar un comentario