Aplicación del Ciclo de Deming

El Ciclo de Deming o PDCA (Plan – Do – Control – Act) consiste en una técnica sistemática creada por Edward Deming para resolver problemas de calidad durante el proceso de fabricación. La tendencia normal, sin la disciplina impuesta por este ciclo es concentrarse en el producto hecho, sin detenerse en las fases de Planear y Controlar. Este Ciclo plantea 4 fases: (1) Planear, (2) Hacer, (3) Controlar y (4) Accionar.

Planear (Plan) En esta fase cabe preguntarse cuáles son los objetivos que se quieren alcanzar y la elección de los métodos adecuados para lograrlos. Conocer previamente la situación de la empresa mediante la recopilación de todos los datos e información necesaria será fundamental para establecer los objetivos. La planificación debe incluir el estudio de causas y los correspondientes efectos para prevenir los fallos potenciales y los problemas de la situación sometida a estudio, aportando soluciones y medidas correctivas.

Hacer (Do)

Consiste en llevar a cabo el trabajo y las acciones correctivas planeadas en la fase anterior. Corresponde a esta fase la formación y educación de las personas y empleados para que adquieran un adiestramiento en las actividades y actitudes que han de llevar a cabo. Es importante comenzar el trabajo de manera experimental, para una vez que se haya comprobado su eficacia en la fase siguiente, formalizar la acción de mejora en la última etapa.

Controlar (Control)

Es el momento de verificar y controlar los efectos y resultados que surjan de aplicar las mejoras planificadas. Se ha de comprobar si los objetivos marcados se han logrado o, si no es así, planificar de nuevo para tratar de superarlos.

Accionar (Action)

Una vez que se comprueba que las acciones emprendidas dan el resultado esperado, es necesario realizar su normalización mediante una documentación adecuada, describiendo lo aprendido, cómo se ha llevado a cabo, etc. se trata, al fin y al cabo, de formalizar el cambio o acción de mejora de forma generalizada, introduciéndolo en los procesos o actividades.

Para llevar a cabo cada una de estas etapas básicas se utilizan normalmente las diferentes técnicas y herramientas de mejora continua y que sirven como soporte y apoyo para la consecución de las diferentes acciones. El ciclo PDCA consigue implementar de una forma sistemática y mediante la utilización de las herramientas adecuadas, la prevención y resolución de problemas. Es un proceso que se repite una vez que termina, volviendo a comenzar el ciclo y formando un espiral: la mejora continua.

Realizando un análisis exhaustivo, se puede decir que la lógica de este Ciclo puede ser aplicada, entre otros, a los diferentes procesos que conforman la Norma ISO 9001:2000, ISO 90003:2004 (ISO 9001:2000 aplicada al Software) y a las áreas de proceso de CMMi V1.1.

El Ciclo de Deming no es ni más ni menos que aplicar la lógica y hacer las cosas de forma ordenada y correcta. Su uso no se limita exclusivamente a la implantación de la mejora continua, sino que se puede utilizar en una gran variedad de situaciones y actividades.

Overview sobre Modelos/Estándares de Calidad del Software

El software juega un papel muy importante para el desarrollo de las organizaciones. Día tras día son liberados para su uso distintos tipos de programas para diferentes clases de clientes, los hay para cada necesidad de tal manera que resulta difícil imaginar alguna situación en la que el software no estuviera presente, dado que es uno de los componentes básicos de la tecnología que se involucra en las empresas, no sólo como soporte a los procesos de negocio, productivos y administrativos, sino como parte integral de las estrategias corporativas para la generación de ventajas competitivas. Esto significa que resulta fundamental evaluar la Calidad del Software.

La Calidad del Software (CS) es “la concordancia de los requerimientos funcionales y de rendimiento explícitamente establecidos, con los estándares de desarrollo documentados y con las características implícitas que se esperan de todo software desarrollado profesionalmente”. Es el conjunto de cualidades que lo caracterizan y que determinan su utilidad y existencia, las cuales plantean un adecuado balanceo de eficiencia, confiabilidad, facilidad de mantenimiento, portabilidad, facilidad de uso, seguridad e integridad.

Para el logro de esta Calidad será necesario efectuar una Gestión de la Calidad del Software, la cual consiste en un conjunto de actividades que permiten dirigir y controlar la organización en lo relativo a la Calidad del Software. La Gestión de la Calidad se puede entender como el conjunto de actividades y medios necesarios para definir e implantar un sistema de la calidad, por una parte, y responsabilizarse de su control, aseguramiento y mejora continua, por otra. En este sentido, la Gestión de la Calidad en cualquier organización se centra en los siguientes niveles de trabajo: (1) nivel de organización, (2) nivel de proyecto y (3) nivel de producto de software.

Para lograr una mejor Gestión de la CS se utilizan Modelos y Estándares de Calidad del Software, los cuales consisten en reunir todas las actividades y funciones de forma tal que ninguna de ellas esté subordinada a las otras y que cada una se planee, controle y ejecute de un modo formal y sistemático.

Los Modelos de Calidad son aquellos documentos que integran la mayor parte de las mejores prácticas, proponen temas de administración en los que cada organización debe hacer énfasis, integran diferentes prácticas dirigidas a los procesos clave y permiten medir los avances en calidad. Los Estándares de Calidad son aquellos que permiten definir un conjunto de criterios de desarrollo que guían la forma en que se aplica la Ingeniería del Software. Los estándares suministran los medios para que todos los procesos se realicen de la misma forma y son una guía para lograr la productividad y la calidad.

Los Modelos y/o Estándares permiten que las Empresas de Software realicen sus tareas y funciones teniendo en cuenta la Calidad. Cualquier organización que se dedica a la investigación, producción y comercialización de software debe considerar la calidad, hoy con más razón, donde existe un mercado en el cual el cliente es cada vez más exigente, no sólo en lo que se refiere al precio, sino sobre todo, en cuanto a los servicios y a la confiabilidad que brindan los productos de software. La calidad desempeña un rol determinante para la competitividad de la empresa. Cuando una empresa está funcionando y decide implantar un Modelo / Estándar de CS, es señal que la empresa tiene el propósito de permanecer y crecer en el mercado, ser competitiva, proteger los intereses de los accionistas, cuidar la fuente de trabajo y mejorar la calidad de vida de su personal.

Implantar Modelos o Estándares de Calidad tiene como objetivo principal que las empresas desarrollen sistemáticamente, productos, bienes y servicios de mejor calidad y cumplan con las necesidades y deseos de los clientes. Para esto, se requiere de un Modelo / Estándar que permita: (1) unir la misión de la empresa y el esfuerzo de cada área en una sinergia de resultados hacia la competitividad y la calidad de clase mundial; y (2) tener procesos y procedimientos ágiles; y comprensibles para todos los involucrados, pasando por las etapas de desarrollo, prueba, producción y satisfacción del cliente.

La Ingeniería del Software abarca un amplio espectro de temas, entre los cuales se encuentra Modelos y Estándares de CS, los cuales permiten que las empresas puedan implementar la calidad a nivel Proceso y a nivel Producto. Cada Modelo o Estándar tiene una aplicación concreta, la cual contribuye a lograr mejor los objetivos. Teniendo en cuenta los objetivos de la empresa, se puede pensar en poder aplicar y/o integrar modelos o estándares, como ser casos de implantación de CMMi e ISO 9001:2000 al mismo tiempo.

La Calidad a nivel Proceso puede ser evaluada de manera genérica o específica, según el modelo o estándar seleccionado. Todo Modelo o Estándar a nivel Proceso tiene un ámbito de aplicación específico y tiene como finalidad el mejoramiento continuo, luego de realizada la implantación del mismo. Entre los Modelos y/o Estándares de CS a nivel Proceso se pueden mencionar: (1) ISO 9001:2000, (2) CMMi, (3) TickIT, (4) ISO 90003:2004, (5) ISO 20000, (6) Bootstrap y otros.

La Calidad a nivel Producto plantea distintos Modelos y Estándares que poseen un conjunto de características, las cuales tienen asociadas subcaracterísticas y métricas. Todo equipo de desarrollo deberá evaluar la CS durante las diferentes etapas de desarrollo del software y ambientes de trabajo respectivos (Desarrollo, Prueba y Producción). Esto evita futuros problemas y una posible disminución en los tiempos y costos. Entre los Modelos y/o Estándares de CS a nivel Producto se pueden mencionar: (1) Modelo de Boehm, (2) Modelo de Gilb, (3) Modelo de Dromey, (4) ISO 9126-1, (5) Modelo de McCall, (6) WebQEM, (7) ISO 25000, (8) Portal Quality Model (PQM) y otros. Los Modelos y Estándares a nivel Producto surgen o se actualizan de acuerdo a la evolución tecnológica ocurrida.

Desde hace bastante tiempo, la calidad es un factor determinante en el desarrollo de toda empresa que tenga como objetivo ser reconocida en el mercado. La Calidad del Software plantea la existencia de una concordancia entre los requerimientos planteados respecto de los obtenidos. Toda empresa que tenga como finalidad alcanzar la calidad deberá implantar un Modelo o Estándar genérico o específico, seleccionado adecuadamente, que se ajuste a los objetivos de la empresa. Esto traerá como consecuencia, un cambio en la manera de pensar y de hacer las cosas en la firma, es decir la denominada Filosofía de la CS.

Las propuestas de acción para el fortalecimiento de la industria del software han permitido que las empresas productoras de software identifiquen, como tarea imprescindible para tener éxito, alcanzar los niveles de competitividad de las organizaciones extranjeras con el fin de lograr una certificación. Esta búsqueda de reconocimiento internacional de calidad, que se ha iniciado en algunas empresas del sector, permitirá enfrentar los mercados con mayores posibilidades de éxito y abrirá las puertas para que otras empresas se animen a estos procesos y se desate en el medio un alto interés y compromiso hacia la incorporación de dichos Modelos y Estándares de CS.

De esta forma, se puede decir que la empresa podrá lograr un reconocimiento respecto de la misión para la cual fue creada y estar acorde al actual mercado empresarial.

Medición, Análisis y Mejora en ISO 9001:2000 (5)

En todo Sistema de Gestión de la Calidad, se puede decir que la realización del producto, es la secuencia de procesos principales y procesos de apoyo requeridos para la obtención del producto.

Los aspectos a considerar en “Medición, Análisis y Mejora” son: (1) Generalidades, (2) Seguimiento y medición, (3) Control del producto no conforme, (4) Análisis de datos y (5) Mejora.

La norma ISO 90003:2004 considera los mismos ítems que la Norma ISO 9001:2000 para el punto de Medición, Análisis y Mejora.

Respecto del punto “Generalidades” (8.1) hace referencia a que la organización debería planificar sus actividades de recolección, registro, análisis y comunicación de datos de sus diferentes procesos, con el propósito de facilitar la toma objetiva de decisiones.El análisis de la información que recolecta y procesa una organización permite elaborar un diagnóstico de su estilo y estado de madurez administrativa. Observando la información generada por los diferentes sectores de una organización, es posible detectar debilidades de la organización.

Las áreas de procesos “Measurement & Analysis” (M&A) y “Quantitative Project Management” (QPM) de CMMi V1.1 guardan relación con este punto.

El punto “Seguimiento y medición” (8.2) plantea que las organizaciones están compuestas de procesos que intervienen directamente en la ejecución del producto y en su comercialización; y procesos que sirven de apoyo a la gestión. La medición y seguimiento del comportamiento de los procesos, afecta por igual a ambos estados dentro de la organización.

Las áreas de procesos “Measurement & Analysis” (M&A), “Project Monitoring and Control” (PMC), “Organizational Process Focus” (OPF), Process and Product Quality Assurance (PPQA), “Quantitative Project Management” (QPM), “Verification” (VER), “Validation” (VAL), “Supplier Agreement Management” (SAM) y “Configuration Management” (CM) de CMMi V1.1 guardan relación con este punto.

El punto “Control del producto no conforme” (8.3) hace referencia a que la organización debe disponer de un procedimiento para administrar el tratamiento de las no conformidades, con el propósito de prevenir el mal uso de los productos no-conformes.

Las áreas de procesos “Configuration Management” (CM) y “Project Monitoring and Control” (PMC) de CMMi V1.1 guardan relación con este punto.

El punto “Análisis de datos” (8.4) hace mención a que los diferentes servicios de la organización deberán llevar un sistema de colección y procesamiento de datos que reflejen el comportamiento de todos lo procesos relevantes. Estos datos deben propender a una consolidación general que permita una gestión consistente con los fines de la organización.

Las áreas de procesos “Measurement & Analysis” (M&A), “Organizational Process Focus” (OPF), “Requirements Development” (RD), “Quantitative Project Management” (QPM), Causal Analysis and Resolution (CAR) y Supplier Agreement Management (SAM) de CMMi V1.1 guardan relación con este punto.

El punto “Mejora” (8.5) hace referencia respecto de disponer de un servicio dentro de la organización que administre la mejora. Las actividades de mejora deben estar en línea con los objetivos de la organización que, a tal efecto, deben ser claramente explicitados y comprendidos por todo el personal. Las autoridades deben observar rigurosidad en la implantación de mejoras, deben medir su efecto y deben reconocer al personal que las propone.

Las áreas de procesos “Organizational Process Focus” (OPF), Organizational Innovation and Deployment (OID), “Measurement & Analysis” (M&A), “Project Monitoring and Control” (PMC) y Causal Analysis and Resolution (CAR) de CMMi V1.1 guardan relación con este punto.

De esta forma, el punto “Medición, Análisis y Mejora” forma parte del modelo de un Sistema de Gestión de la Calidad, el cual está basado en procesos que ilustran los vínculos entre los procesos presentados en los capítulos 4 a 8 de la ISO 9001:2000.

Uso del Diagrama de Pareto

El Diagrama de Pareto es un histograma especial en donde se organizan diversas clasificaciones de datos por orden descendente, por medio de barras sencillas después de haber reunido los datos para calificar eventos, defectos, causas, mediciones, etc.; de modo que sea posible asignar un orden de prioridades. Consiste en detectar cuáles son las pocas causas que generan la mayor cantidad de consecuencias, a partir de concentrarse en los temas más importantes utilizando la filosofía del ABC.

El enfoque impulsado por el economista italiano, se denomina la regla del 20-80, es decir, que a pesar de que esa proporción anunciada por Pareto no se cumpla en forma precisa, el objetivo que persigue este método es que “el 20% de las causas producen el 80% de los efectos”.

El análisis resulta racional, ágil, práctico y efectivo dado que requiere poco esfuerzo concentrando el interés sólo en pocas causas, aunque de principal importancia ya que solucionan la mayor parte de los problemas.

Pareto es una herramienta de análisis de datos ampliamente utilizada y es útil en la determinación de la causa principal durante un esfuerzo de resolución de problemas. Este permite ver cuáles son los problemas más grandes, permitiéndoles a los grupos establecer prioridades. En casos típicos, los pocos (pasos, servicios, ítems, problemas, causas) son responsables por la mayor parte el impacto negativo sobre la calidad. Si enfocamos nuestra atención en estos pocos vitales, podemos obtener la mayor ganancia potencial de nuestros esfuerzos por mejorar la calidad.

La minoría vital aparece a la izquierda del gráfico y la mayoría útil a la derecha; hay veces que es necesario combinar elementos de la mayoría útil en una sola clasificación denominada otros, la cual siempre deberá ser colocada en el extremo derecho. La escala vertical indicará cantidades (de veces, de eventos, de unidades de moneda, de metros cúbicos, etc.) en unidades. Los factores se representan a lo largo del eje x en forma decreciente. La curva de frecuencia indica los pocos factores vitales que requieren atención.

Este diagrama se utiliza de la siguiente forma: 1. Seleccionar categorías lógicas para el tópico de análisis identificado (incluir el periodo de tiempo). 2. Reunir datos. La utilización de un Check List puede ser de mucha ayuda en este paso. 3. Ordenar los datos de la mayor categoría a la menor 4. Totalizar los datos para todas las categorías 5. calcular el porcentaje del total que cada categoría representa 6. trazar los ejes horizontales (x) y verticales (y primario - y secundario) 7. trazar la escala del eje vertical izquierdo para frecuencia (de 0 al total, según se calculó anteriormente) 8. de izquierda a derecha trazar las barras para cada categoría en orden descendente. Si existe una categoría “otros”, debe ser colocada al final, sin importar su valor. Es decir, que no debe tenerse en cuenta al momento de ordenar de mayor a menor la frecuencia de las categorías. 9. trazar la escala del eje vertical derecho para el porcentaje acumulativo, comenzando por el 0 y hasta el 100% 10. trazar el gráfico lineal para el porcentaje acumulado, comenzando en la parte superior de la barra de la primera categoría (la mas alta) 11. dar un título al gráfico, agregar las fechas de cuando los datos fueron reunidos y citar la fuente de los datos. 12. analizar la gráfica para determinar los “pocos vitales”

Se puede observar que los 2 primeros defectos representa en 71.6% del total planteado. Se deberán analizar las causas que lo provocaron para que así desaparezca la mayor parte de los defectos.

Este diagrama se puede aplicar a los siguientes puntos de la Norma ISO 9001:2000: “Objetivos de la Calidad” (5.4.1), “Generalidades de la revisión” (5.6.1), “Auditoria interna” (8.2.2), “Mejora continua” (8.5.1) y “Acción correctiva” (8.5.2) y “Acción preventiva” (8.5.3). La aplicación de este diagrama permite determinar si pocos problemas pueden provocar la mayor cantidad de problemas. Todos estos puntos mencionados forman parte de la Norma ISO 90003:2004 (ISO 9001:2000 aplicada al Software).

Respecto de CMMi V1.1 se puede decir que el Diagrama de Pareto puede aplicarse a las siguientes áreas de proceso: Organizational Process Focus (OPF), Organizational Process Performance (OPP) y Decisión Analysis and Resolution (DAR).

De esta forma, el diagrama de Pareto es una herramienta que permite analizar y detectar aquellas situaciones que pueden provocar la mayoría de los problemas y que afectan a los objetivos de la empresa.

Gestión de la Calidad del Software

La Gestión de la Calidad de Software es un conjunto de actividades de la función general de la Dirección que determina la calidad, los objetivos y las responsabilidades. Se basa en la determinación y aplicación de las políticas de calidad de la empresa. La Gestión o Administración de la Calidad se aplica normalmente a nivel empresa o dentro de la gestión de cada proyecto. El propósito de la Gestión de la Calidad del Software es entender las expectativas del cliente en términos de calidad, y poner en práctica un plan proactivo para satisfacer esas expectativas.

Desde el punto de vista de la calidad, la Gestión de la Calidad del Software (CS) está formada por 4 partes, las cuales son: (1) Planificación de la CS, (2) Control de la CS, (3) Aseguramiento de la CS y (4) Mejora de la CS.

La Planificación de la Calidad del Software (1) es la parte de la Gestión de la Calidad encargada de realizar el proceso administrativo de desarrollar y mantener una relación entre los objetivos y recursos de la organización; y las oportunidades cambiantes del mercado. El objetivo es modelar y remodelar los negocios y productos de la empresa, de manera que se combinen para producir un desarrollo y utilidades satisfactorias.

Los aspectos a considerar en la Planificación de la CS son: Modelos/Estándares de CS a utilizar, Costos de la CS, Recursos humanos y materiales necesarios, etc. El plan de calidad define los atributos de calidad más importantes del producto a ser desarrollado y define el proceso de evaluación de la calidad. En la Planificación de la CS se debe determinar: (1) Rol de la Planificación, (2) Requerimientos de la CS, (3) Preparación de un Plan de CS, (4) Implementación de un Plan de CS y (5) Preparar un Manual de Calidad.

El Control de la Calidad del Software (2) son las técnicas y actividades de carácter operativo, utilizadas para satisfacer los requisitos relativos a la calidad, centradas en 2 objetivos fundamentales: (1) mantener bajo control un proceso y (2) eliminar las causas de los defectos en las diferentes fases del ciclo de vida. Está formado por actividades que permiten evaluar la calidad de los productos de software desarrollados. El aspecto a considerar en el Control de la CS es la “Prueba del Software”.

La prueba es el proceso de ejecutar un programa con intención de encontrar defectos. Es un proceso destructivo que determina el diseño de los casos de prueba y la asignación de responsabilidades. La prueba exitosa es aquella que descubre defectos. El “caso de prueba bueno” es aquel que tiene alta probabilidad de detectar un defecto aún no descubierto. El “caso de prueba exitoso” es aquel que detecta un defecto aún no descubierto.

La prueba no es: (1) demostración que no hay errores, (2) demostración que el software desempeña correctamente sus funciones y (3) establecimiento de confianza que un programa hace lo que debe hacer.

La prueba demuestra hasta qué punto las funciones del software parecen funcionar de acuerdo con las especificaciones y parecen alcanzarse los requisitos de rendimiento. Además, los datos que se van recogiendo a medida que se lleva a cabo la prueba proporcionan una buena indicación de la confiabilidad del software e indican la calidad del software como un todo. Pero, la prueba no puede asegurar la ausencia de defectos; sólo puede demostrar que existen defectos en el software.

Una estrategia Tradicional de prueba del software debe incluir pruebas de bajo nivel que verifiquen que todos los pequeños segmentos de código fuente se han implementado correctamente, así como pruebas de alto nivel que validen las principales funciones del sistema frente a los requisitos del cliente. Una estrategia proporciona un conjunto de hitos.

Inicialmente, la prueba se centra en cada módulo individualmente, asegurando que funciona adecuadamente como una unidad. La prueba de unidad hace un uso intensivo de las técnicas de prueba de caja blanca, ejercitando caminos específicos de la estructura de control del módulo para asegurar un alcance completo y una detección máxima de errores. La prueba de unidad centra el proceso de verificación en la menor unidad del diseño del software: el componente de software o módulo. Se prueba la interfaz del módulo para asegurar que la información fluye de forma adecuada hacia y desde la unidad de programa que está siendo probada. Se examinan las estructuras de datos locales para asegurar que los datos que se mantienen temporalmente conservan su integridad durante todos los pasos de ejecución del algoritmo. Se prueban las condiciones límite para asegurar que el módulo funciona correctamente en los límites establecidos. Se ejercitan todos los caminos independientes de la estructura de control con el fin de asegurar que todas las sentencias del módulo se ejecutan por lo menos una vez. Y, finalmente, se prueban todos los caminos de manejo de errores. Antes de iniciar cualquier otra prueba es preciso probar el flujo de datos de la interfaz del módulo. Si los datos no entran correctamente, todas las demás pruebas no tienen sentido. Además de las estructuras de datos locales, durante la prueba de unidad se debe comprobar el impacto de los datos globales sobre el módulo.

A continuación, se deben ensamblar o integrar los módulos para formar el paquete de software completo. La prueba de integración es una técnica sistemática que permite construir la estructura del programa mientras que, al mismo tiempo, se llevan a cabo pruebas para detectar errores asociados con la interacción. El objetivo es juntar los módulos probados mediante la prueba de unidad y construir una estructura de programa que esté de acuerdo con lo que dicta el diseño. Se combinan todos los módulos por anticipado. Se prueba todo el programa en conjunto. Se encuentra un gran conjunto de errores. Una vez que se corrigen esos errores aparecen otros nuevos y el proceso continúa en lo que parece ser un ciclo sin fin.

Después que el software se ha integrado, se dirigen un conjunto de pruebas de alto nivel. Se deben comprobar los criterios de validación establecidos durante el análisis de requisitos. La prueba de validación proporciona una seguridad final que el software satisface todos los requisitos funcionales, de comportamiento y de rendimiento. Durante la validación se usan exclusivamente técnicas de prueba de caja negra.

El software, una vez validado, se debe combinar con otros elementos del sistema. La prueba del sistema verifica que cada elemento se ajusta de forma adecuada y que se alcanza la funcionalidad y el rendimiento del sistema total. La prueba del sistema está constituida por una serie de pruebas diferentes cuyo propósito primordial es ejercitar profundamente el sistema basado en computadora. Aunque cada prueba tiene un propósito diferente, todas trabajan para verificar que se ha integrado adecuadamente todos los elementos del sistema y que realizan las funciones apropiadas.

La prueba de regresión es volver a ejecutar un subconjunto de pruebas que se han llevado a cabo anteriormente para asegurarse que los cambios no han propagado efectos colaterales no deseados. Este tipo de prueba es la actividad que ayuda a asegurar que los cambios no introduzcan un comportamiento no deseado o errores adicionales. A medida que progresa la prueba de regresión, el número de pruebas de regresión puede crecer demasiado. Por lo tanto, el conjunto de pruebas de regresión debería diseñarse para incluir sólo aquellas pruebas que traten una o más clases de errores en cada una de las funciones principales del programa. No es práctico ni eficiente volver a ejecutar cada prueba de cada función del problema después de un cambio.

Cuando se construye un software a medida para un cliente, se llevan a cabo una serie de pruebas de aceptación para permitir que el cliente valide todos los requisitos. Estas pruebas las realiza el usuario final en lugar del responsable del desarrollo de sistema. Una prueba de aceptación puede ir desde un informal paso de prueba hasta la ejecución sistemática de una serie de pruebas bien planificadas.

El diseño de casos de prueba para el software o para otros productos de ingeniería puede requerir tanto esfuerzo como el propio diseño inicial del producto. Sin embargo, los Ingenieros de Software tratan las pruebas como algo sin importancia, desarrollando casos de prueba que “parezcan adecuados”, pero que tienen poca garantía de ser completos. Se deben diseñar pruebas que tengan la mayor probabilidad de encontrar el mayor número de errores con la mínima cantidad de esfuerzo y tiempo posible. Cualquier producto de ingeniería puede probarse de una de estas 2 formas: (1) prueba de caja negra y (2) prueba de caja blanca.

Cuando se considera el software de computadora, la prueba de caja negra se refiere a las pruebas que se llevan a cabo sobre la interfaz del software. Los casos de prueba pretenden demostrar que las funciones del software son operativas, que la entrada se acepta de forma adecuada y que se produce un resultado correcto, así como que la integridad de la información externa se mantiene.

La prueba de caja blanca del software se basa en el minucioso examen de los detalles procedimentales. Se comprueban los caminos lógicos del software proponiendo casos de prueba que ejerciten conjuntos específicos de condiciones y/o bucles. Se puede examinar el estado del programa en varios puntos para determinar si el estado real coincide con el esperado o mencionado. Para este tipo de prueba, se deben definir todos los caminos lógicos y desarrollar casos de prueba que ejerciten la lógica del programa.

El Aseguramiento de Calidad del Software (3) es el conjunto de actividades planificadas y sistemáticas necesarias para aportar la confianza que el software satisfará los requisitos dados de calidad. Este aseguramiento se diseña para cada aplicación antes de comenzar a desarrollarla y no después. El aseguramiento de la calidad del software engloba: (1) un enfoque de gestión de calidad, (2) métodos y herramientas de Ingeniería del Software, (3) revisiones técnicas formales aplicables en el proceso de software, (4) una estrategia de prueba multiescala, (5) el control de la documentación del software y de los cambios realizados, (6) procedimientos para ajustarse a los estándares de desarrollo del software y (7) mecanismos de medición y de generación de informes.

Este aseguramiento tiene asociado 2 constitutivos diferentes: los Ingenieros de Software que realizan el trabajo técnico y un grupo de SQA (Software Quality Assurance) que tiene la responsabilidad de la planificación de aseguramiento de la calidad, supervisión, mantenimiento de registros, análisis e informes.

Las Actividades del grupo de SQA son: (1) Establecimiento de un plan de SQA para un proyecto, (2) Participación en el desarrollo de la descripción del proceso de software del proyecto, (3) Revisión de las actividades de Ingeniería del Software para verificar su ajuste al proceso de software definido, (4) Auditoria de los productos de software designados para verificar el ajuste con los definidos como parte del proceso del software, (5) Asegurar que las desviaciones del trabajo y los productos del software se documentan y se manejan de acuerdo con un procedimiento establecido, y (6) Registrar lo que no se ajuste a los requisitos e informar a sus superiores.

Además de estas actividades, el grupo de SQA coordina el control y la gestión de cambios y; ayuda a recopilar y analizar las métricas del software. Las métricas son escalas de unidades sobre las cuales puede medirse un atributo cuantificable. Cuando se habla de software nos referimos a la disciplina de recopilar y analizar datos basándonos en mediciones reales de software, así como a las escalas de medición. Los atributos son características observables del producto o del proceso de software, que proporciona alguna información útil sobre el estado del producto o sobre el progreso del proyecto. El término producto se utiliza para referirse a las especificaciones, a los diseños y a los listados del código. Los valores de las métricas no se obtienen sólo por mediciones. Algunos valores de métricas se derivan de los requisitos del cliente o de los usuarios y, por lo tanto, actúan como restricciones dentro del proyecto.

Las medidas de Calidad del Software deben comenzar desde la especificación y terminar con la implementación, implantación y mantenimiento o post-implantación. Debe aplicarse a lo largo de todo el proceso de Ingeniería de Software. Básicamente, la medición es una fase normal de cualquier actividad industrial Sin mediciones es imposible perseguir objetivos comerciales normales de una manera racional.

Existen métricas a nivel Proyecto, Proceso y Producto respectivamente. Las métricas a recabar dependen de los objetivos del negocio en particular. Los desarrolladores tienen a la vez objetivos comunes como, respetar el presupuesto y respetar los plazos, minimizar las tasas de defectos antes y después de la entrega del producto e intentar mejorar la calidad y la productividad. Las métricas deben ayudar a la evaluación de las representaciones del modelo lógico y físico, deben tener la capacidad de intuir sobre la complejidad del diseño y construcción; y deben ayudar en el diseño de casos de prueba.

La Mejora de la Calidad del Software (4) es la parte de la Gestión de la Calidad que contribuye, por medio de las mediciones, a los análisis de los datos y auditorias, a efectuar mejoras en la calidad del software.

Una Auditoria de Calidad tiene como objetivo mostrar la situación real para aportar confianza y destacar las áreas que pueden afectar adversamente esa confianza. Otro objetivo consiste en suministrar una evaluación objetiva de los productos y procesos para corroborar la conformidad con los estándares, las guías, las especificaciones y los procedimientos.

Los resultados de la auditoria son documentados y remitidos al director de la organización auditada, a la entidad auditora, y cualquier organización externa identificada en el plan de auditoria. El informe incluye la lista de elementos no conformes u otros aspectos para las posteriores revisiones y acciones. Cuando se realiza el plan de auditoria, las recomendaciones son informadas e incluidas en los resultados de la auditoria.

Para implementar un programa de mejoras es necesario definir procesos, decidir qué se quiere mejorar, definir qué medidas serán necesarias recoger, cómo y dónde tomarlas, gestionarlas mediante herramientas, utilizarlas para la toma de decisiones y reconocer las mejoras. Cuando el proceso a mejorar es el de desarrollo del software, es importante definir qué objetivos se quieren alcanzar, para reducir el número de medidas y, en consecuencia, el coste de recopilarlas y el impacto sobre la actividad de producción de software.

La calidad ha dejado de ser un tópico y es necesario que forme parte de los productos o servicios que comercializamos para nuestros clientes. El cliente es el mejor auditor de la calidad, él exige el nivel que está dispuesto a pagar por ella, pero no más. Por tanto, debemos de cuantificar cuál es el nivel de calidad que nos exige para poder planificar la calidad de los productos que se generen a lo largo de la producción del producto o servicio final. Al analizar las necesidades de nuestros clientes, deberemos tener en cuenta la previsible evolución de sus necesidades y tendencias en cuanto a características. Deberemos tener en cuenta la evolución tecnológica del entorno de producción de nuestros productos para suministrarlos con el nivel tecnológico adecuado. No debemos olvidar el nivel de calidad de nuestros competidores, debiendo elaborar productos cuyas características y funcionalidades sean competitivas con las de nuestros competidores.

La Calidad de Software es resultado del movimiento global dentro del proceso de mejoramiento continuo de los modelos y/o estándares de producción en todos los sectores industriales, en particular, cuando éste se concentra en la producción de sistemas de información y software especializado.

Realización del Producto e ISO 9001:2000 (4)

En todo Sistema de Gestión de la Calidad, se puede decir que la realización del producto, es la secuencia de procesos principales y procesos de apoyo requeridos para la obtención del producto.

Los aspectos a considerar en “Realización del Producto” son: (1) Planificación de la realización del producto, (2) Procesos relacionados con el cliente, (3) Diseño y desarrollo, (4) Compras, (5) Producción y prestación del servicio y (6) Control de los dispositivos de seguimiento y de medición.

La norma ISO 90003:2004 considera los mismos ítems que la Norma ISO 9001:2000 para el punto de Realización del Producto y añade subítems propios de la Ingeniería de Software.

Respecto del punto “Planificación de la Realización del Producto” (7.1) hace referencia a la planificación de la calidad que se requiere como paso inicial para coordinar todos los procesos que concurrirán a la ejecución del producto. Incluye la definición a partir de los requisitos de clientes, el diseño y las etapas de verificación y validación del diseño, la implantación de los procesos de elaboración y la distribución.

Las áreas de procesos “Organizational Process Definition” (OPD), “Project Planning” (PP), “Integrated Project Management” (IPM) y “Quantitative Project Management” (QPM) de CMMi V1.1 guardan relación con este punto.

El punto “Procesos relacionados con el Cliente” (7.2) plantea que la organización debe revisar los requisitos de clientes y otras partes interesadas aplicando un procedimiento de revisión de contrato. Esta revisión debe hacerse en dos instancias, antes que se formalice el contrato e inmediatamente después de formalizarlo es decir, con la orden de compra colocada, con el propósito de verificar si las condiciones acordadas en la presentación de la oferta, son consistentes con las de la orden de compra definitiva.

Las áreas de procesos “Requirements Development” (RD), “Requirements Management” (REQM), “Technical Solution” (TS), “Verification” (VER), “Integrated Project Management” (IPM) y “Measurement & Analysis” (M&A) de CMMi V1.1 guardan relación con este punto.

El punto “Diseño y Desarrollo” (7.3) hace referencia a la expresión diseño y desarrollo como el conjunto de procesos que transforma los requisitos en características específicas (diseño del producto) y en la especificación del proceso de realización del producto. Las palabras diseño y desarrollo en esta norma, se pueden aplicar indistintamente a productos o procesos.

Las áreas de procesos “Project Planning” (PP), “Integrated Project Management” (IPM), “Verification” (VER), “Validation” (VAL), “Product Integration” (PI), “Requirements Development” (RD), “Technical Solution” (TS), “Project Monitoring and Control” (PMC) y “Configuration Management” (CM) de CMMi V1.1 guardan relación con este punto.

El punto “Compras” (7.4) hace mención a que el proceso de compras deberá conducirse de modo de comprar sólo a proveedores calificados para abastecer los productos respectivos. La organización debe tener proveedores alternativos para aquellos casos donde el proveedor principal falla en su abastecimiento.

Las áreas de procesos “Supplier Agreement Management” (SAM), “Technical Solution” (TS) y “Verification” (VER) de CMMi V1.1 guardan relación con este punto.

El punto “Producción y prestación del servicio” (7.5) hace referencia a que el servicio de Producción debe cumplir los requisitos que se hayan fijado para la elaboración del producto a fin de asegurar el cumplimiento de las especificaciones y satisfacer las necesidades y expectativas de las partes interesadas.

Las áreas de procesos “Technical Solution” (TS), “Validation” (VAL), “Configuration Management” (CM), “Product Integration” (PI) y “Requirements Management“ (REQM) de CMMi V1.1 guardan relación con este punto.

El punto “Control de los dispositivos de seguimiento y medición” (7.6) hace referencia a la capacidad de garantizar que la medición realizada con los medios con que cuenta la organización, es exacta cuando se la compara con medios considerados como patrón. Esta exigencia requiere calibrar los medios de medición, ensayo, verificación y seguimiento, con respecto a otros medios tomados como patrón. Los patrones a su vez, deben estar calibrados con relación a otros cuyo estado de calibración sea aceptado en el ámbito nacional, en el ámbito oficial. Estos medios de control a su vez, están calibrados respecto a otros cuya validez es reconocida internacionalmente.

Las organizaciones que disponen de medios de control calibrados bajo estas reglas, gozan del atributo de asegurar la medida y por lo tanto, aquellas validaciones que otorgan a sus productos y a sus procesos como resultado de la medición, es perfectamente válida y reconocida por cualquier cliente y por cualquier norma de aseguramiento de la calidad.

Las áreas de procesos “Verification” (VER), “Validation” (VAL) y “Measurement & Analysis” (M&A) de CMMi V1.1 guardan relación con este punto.

De esta forma, el punto “Realización del Producto” forma parte del modelo de un Sistema de Gestión de la Calidad, el cual está basado en procesos que ilustran los vínculos entre los procesos presentados en los capítulos 4 a 8 de la ISO 9001:2000.

Uso del Brainstorming

El brainstorming o “tormenta de ideas” es una herramienta de trabajo grupal que persigue la generación de ideas por parte de un grupo de personas reunidas a tal efecto. Se pretende potenciar la creatividad de todas las personas que participan para que expresen sin temor y de una forma espontánea todas las ideas que les vayan surgiendo, sin censura ni crítica. La lluvia de ideas constituye una actividad que permite aprovechar la sinergia de un grupo de trabajo y la creatividad individual, para generar la mayor cantidad de ideas en un mínimo lapso de tiempo.

El brainstorming fue diseñado para mejorar la toma de decisión y la comunicación, aumenta la "fluidez" —es decir, la capacidad de producir muchas ideas originales con facilidad— y la "flexibilidad", que es la habilidad para generar muchas clases diferentes de ideas. En la actualidad, los ejercicios de brainstorming se basan en dos principios: (1) mientras se generan ideas no hay que emitir juicios, y (2) la cantidad de ideas afecta la calidad de la decisión final.

Se deberá utilizar la lluvia de ideas cuando exista la necesidad de: (1) Liberar la creatividad de los equipos, (2) Generar un número extenso de ideas y (3) Involucrar oportunidades para mejorar.

Esta herramienta permite: (1) Plantear y resolver los problemas existentes, (2) Plantear posibles causas, (3) Plantear soluciones alternativas, (4) Desarrollar la creatividad, (5) Discutir conceptos nuevos y (6) Superar el conformismo y la monotonía

Durante la sesión de lluvia de ideas, los miembros del equipo sugerirán problemas y causas de los problemas, una sugerencia conducirá a otra, creando una retro-alimentación de ideas.

Las sesiones de lluvia de ideas podrán efectuarse con todos los miembros de un equipo interdisciplinario después que cada uno de sus miembros haya tenido amplia oportunidad de revisar la información disponible sobre el sistema bajo estudio. El líder del grupo debe asegurar que los problemas presentados son reales, no potenciales, anticipados o corresponden a opiniones personales.

Los pasos para el desarrollo del brainstorming son: 1- Escribir sobre un papel el tema o cuestión a estudiar, de manera que sea bien visible por todos. 2- Confirmar que todos los asistentes hayan comprendido exactamente el tema y su alcance 3- Permitir que los participantes piensen acerca del tema durante algunos minutos antes de abrir la sesión 4- Definir con los participantes las reglas que regirán la actividad 5- Escribir todas las ideas en un papel 6- Finalizada la sesión, analizar y aclarar cada una de las ideas y agruparlas por afinidades 7- Elaborar una lista de referencia con todas las ideas 8- Distribuir a cada uno de los participantes, una copia de la lista de referencia para su revisión y reflexión sobre lo tratado y las ideas aportadas 9- En la siguiente reunión se discuten los resultados de las reflexiones individuales y se elabora la lista de referencia definitiva

Se puede facilitar la lluvia de ideas si los participantes se reúnen en un ambiente agradable e informal con un líder de discusión y un asistente para tomar notas. Mientras que el líder del grupo estimula la discusión, el asistente hace una lista de todos los problemas y sus causas sugeridas por los participantes. Los problemas se anotan como se presentan, sin ordenamiento particular.

Una vez que la sesión de lluvia de ideas haya terminado, el equipo puede revisar la lista de referencia de Problemas Potenciales. Debido a que muchas veces suele ser una lista relativamente larga, cuyo análisis punto por punto llevaría varias horas o días, es conveniente que la lista de referencia sea revisada por cada miembro del equipo, con el propósito de identificar importantes problemas o causas de problemas que puedan haber sido pasados por alto en la sesión de discusión espontánea. La lista de referencia servirá como guía para organizar los problemas que se anotaron en el ejercicio de lluvia de ideas, agrupando los problemas de acuerdo a sus respectivos puntos en el sistema, colocándolos en una perspectiva que contribuya a esclarecer las relaciones de causa y efecto.

El brainstorming se relaciona con las siguientes herramientas:

(1) Diagrama de afinidad: Es un herramienta que organiza un gran numero de ideas en función de afinidad, es decir, de las relaciones que existen entre ellas.

(2) Diagrama de causa – efecto (Ishikawa): Es una técnica de análisis de causa y efectos para la solución de problemas, que relaciona un efecto con las posibles causas que lo provocan.

Esta herramienta de brainstorming se puede aplicar a los siguientes puntos de la Norma ISO 9001:2000: “Ambiente de trabajo” (6.4), “Revisión de los requisitos relacionados con el producto” (7.2.2), “Planificación del diseño y desarrollo” (7.3.1), “Elementos de entrada para el diseño y desarrollo” (7.3.2), “Auditoria de la Calidad” (8.2.2), “Mejora continua” (8.5.1), “Acción correctiva” (8.5.2) y “Acción preventiva” (8.5.3). La aplicación de esta herramienta permite desarrollar la creatividad de acuerdo a la finalidad de cada punto. Todos estos puntos mencionados forman parte de la Norma ISO 90003:2004 (ISO 9001:2000 aplicada el Software).

Respecto de CMMi V1.1 y CMMi V1.2, se puede decir el brainstorming puede aplicarse a las siguientes áreas de proceso: Project Planning (PP), Requirements Development (RD) y Decisión Analysis and Resolution (DAR).

De esta forma, el brainstorming es una herramienta que permite aplicar la creatividad en cada proceso que requiera el mantenimiento o mejora del mismo, lo cual permitirá lograr los niveles de calidad establecidos.

Auditoría de la Calidad del Software

Durante las tres primeras décadas de la Informática el principal desafío consistió en desarrollar el hardware de manera que se redujeran los costos de procesamiento y almacenamiento. Hoy en día el problema es diferente. La principal meta está en reducir el costo, elevar la productividad, y la eficiencia en la Industria del Software y mejorar la calidad para lograr un producto competitivo que se ajuste a los requerimientos de calidad establecidos por el cliente y por el productor. Producir “calidad“ es indispensable no sólo para lograr y conservar un segmento de mercado, contra una competencia cada vez mas aguerrida, sino por que estamos pasando de una concepción de mercado nacional a otra dimensión regional o global. La utilización de métodos y técnicas para incrementar la calidad de los productos de software permite ampliar los propios horizontes comerciales.

Cualquier organización que se dedica a la investigación, producción y comercialización de software debe tener en cuenta el factor del aseguramiento de la calidad, hoy con mas razón, donde existe un mercado en el cual el cliente es cada vez más exigente, no sólo en lo que se refiere al precio, sino sobre todo, en cuanto a los servicios y a la confiabilidad que brindan los productos de software. El aseguramiento de la calidad desempeña un rol determinante para la competitividad de la empresa. Las normas técnicas se ubican como la opción más clara para asegurar la calidad del software. Los productos fabricados bajo normas técnicas tienen mayores oportunidades comerciales en el mercado mundial.

La calidad ha dejado de ser un tópico y es necesario que forme parte de los productos o servicios que comercializamos para nuestros clientes. El cliente es el mejor auditor de la calidad, él exige el nivel que está dispuesto a pagar por ella, pero no más. Por tanto, debemos de cuantificar cuál es el nivel de calidad que nos exige para poder planificar la calidad de los productos que se generan a lo largo de la producción del producto o servicio final.

Al analizar las necesidades de nuestros clientes, deberemos tener en cuenta la previsible evolución de sus necesidades y tendencias en cuanto a características. Debemos tener en cuenta la evolución tecnológica del entorno de producción de nuestros productos de software para suministrarlos con el nivel tecnológico adecuado. No debemos olvidar el nivel de calidad de nuestros competidores, debiendo elaborar productos cuyas características y funcionalidades sean competitivas con las de nuestros competidores.

Al decidir la realización de un producto de software se debe hacer una planificación y un Plan de Calidad. En el centro de producción de software, deberá haber un Plan General de Calidad en el que estarán las especificaciones para poder definir cada uno de los planes específicos de nuestros desarrollos en función de los atributos de Calidad que deseamos implementar en el software. En este Plan se definen las actividades de Calidad que se tienen que realizar, en qué momentos tiene que intervenir la función de Aseguramiento de la Calidad, que a diferencia de Control de Calidad intervendrá proponiendo y supervisando los procesos de calidad a realizar en la fase de generación de los distintos componentes, adherencia a estándares, y la intensidad de aplicación de la misma según la criticidad de los productos y el nivel de riesgos que se haya encontrado en la evaluación del sistema.

Una Auditoria de Calidad tiene como objetivo mostrar la situación real para aportar confianza y destacar las áreas que pueden afectar adversamente esa confianza. Otro objetivo consiste en suministrar una evaluación objetiva de los productos y procesos para corroborar la conformidad con los estándares, las guías, las especificaciones y los procedimientos.

Para realizar la evaluación de la Calidad del Software se puede, entre otros, considerar la Norma ISO 9126-1:2001. Esta Norma define las características de calidad como un conjunto de atributos del producto de software a través de los cuales la calidad es descripta y evaluada. Estas características de calidad del software pueden ser precisadas a través de múltiples niveles de subcaracterísticas.

Esta Norma tiene 4 partes: (a) Modelo de Calidad – ISO 9126-1:2001 (b) Métricas Externas, las cuales miden el software en sí mismo (Calidad Externa) – ISO 9126-2:2003 (c) Métricas Internas, las cuales miden el comportamiento del sistema (Calidad Interna) – ISO 9126-3: 2003 (d) Calidad en Uso, el cual mide el efecto de usar el software en un contexto específico – ISO 9126-4:2004

Las 3 últimas partes tienen métricas asociadas por cada Subcaracterística definida.

ISO 9126-1:2001 plantea las siguientes características de calidad: (1) Funcionalidad, (2) Confiabilidad, (3) Facilidad de Uso, (4) Eficiencia, (5) Facilidad de Mantenimiento y (6) Portabilidad.

La Funcionalidad (1) es el conjunto de atributos que se refieren a la existencia de un conjunto de funciones y sus propiedades específicas. Las funciones cumplen unos requerimientos o satisfacen unas necesidades implícitas. Las subcaracterísticas de la Funcionalidad son: Aptitud, Precisión, Interoperatividad, Conformidad, Seguridad y Trazabilidad.

La Confiabilidad (2) es el conjunto de atributos que se refieren a la capacidad del software de mantener su nivel de rendimiento bajo unas condiciones especificadas durante un período definido. Las subcaracterísticas de la Confiabilidad son: Madurez, Tolerancia a fallas, Facilidad de Recuperación, Disponibilidad y Degradabilidad.

La Facilidad de Uso (3) es el conjunto de atributos que se refieren al esfuerzo necesario para usarlo, y sobre la valoración individual de tal uso, por un conjunto de usuarios definidos e implícitos. Las subcaracterísticas de la Facilidad de Uso son: Comprensibilidad, Facilidad de aprendizaje, Operatividad, Explicitud, Adaptabilidad al usuario, Atractivo, Claridad, Facilidad de ayudas y Amistoso al usuario.

La Eficiencia (4) es el conjunto de atributos que se refieren a las relaciones entre el nivel de rendimiento del software y la cantidad de recursos utilizados bajo unas condiciones predefinidas. Las subcaracterísticas de la Eficiencia son: Respecto al tiempo y Respecto a los recursos.

La Facilidad de Mantenimiento (5) es el conjunto de atributos que se refieren al esfuerzo necesario para hacer modificaciones especificadas. .Las subcaracterísticas de la Facilidad de Mantenimiento son: Facilidad de análisis, Facilidad de cambio, Estabilidad y Facilidad de prueba.

La Portabilidad (6) es el conjunto de atributos que se refieren a la habilidad del software para ser transferido desde un entorno a otro. Las subcaracterísticas de la Portabilidad son: Adaptabilidad, Facilidad de instalación, Conformidad y Facilidad de Reemplazo.

La valoración de estas características es útil para que el usuario pueda definir los requerimientos del producto utilizando solamente las características que emplee en la práctica. Para algunos tipos de productos de software, hay determinadas características que no son significativas y las restantes no garantizan que con ellas comprendan todos los requerimientos de los productos de software, por lo que en cada caso habrá que completarlas con otras definiciones más específicas para esos productos o situaciones. No obstante el modelo tiene el nivel de abstracción suficiente como para que sea adaptable en la mayoría de las situaciones, siendo además, independiente de la tecnología.

ISO 25000:2005 (SQuaRE -Software Quality Requirements and Evaluation) es una nueva serie de normas que se basa en ISO 9126 y en ISO 14598 (Evaluación del software). Uno de los principales objetivos de la serie SQuaRE es la coordinación y harmonización del contenido de ISO 9126 y de ISO 15939:2002 (Measurement Information Model). ISO 15939 tiene un modelo de información que ayuda a determinar que se debe especificar durante la planificación, performance y evaluación de la medición. Para su aplicación, cuenta con los siguientes pasos: (1) Recopilar los datos, (2) Preparación de los datos y (3) Análisis de los datos.

La integración de ISO 9126 e ISO 15939 permiten plantear un proceso de 4 pasos: (1) Identificación de los requerimientos relacionados a la calidad del producto, es decir, seleccionar la parte del modelo de calidad (ISO/IEC 9126-n) que resulta relevante para la evaluación de calidad. (2) Identificación del contexto de interpretación. Es decir, selección de los valores de referencia y determinación de los target especificados en un contexto determinado (3) Uso de las medidas derivadas de la etapa de preparación de los datos (4) Comparación y análisis de los resultados obtenidos respecto de un conjunto de valores de referencia.

SQuaRE incluye un estándar de requerimientos de calidad. Está compuesto por 14 documentos agrupados en 5 tópicos: (1) Administración de la Calidad – 2500n, (2) Modelo de Calidad – 2501n, (3) Medidas de Calidad – 2502n, (4) Requerimientos de Calidad – 2503n y (5) Evaluación de la Calidad – 2504n.

Administración de la Calidad (1): abarca: (1) Guía para SquaRE – Overview de la estructura y terminología y (2) Planificación y Administración – Provee una guía para planificar y administrar las evaluaciones del software.

Modelo de Calidad (2): describe el modelo de calidad interno / externo y la calidad en uso. Presenta características y subcaracterísticas.

Medidas de Calidad (3): Medición de primitivas, Medidas para la calidad interna, Medidas para la calidad externa y Medidas para la calidad en uso.

Requerimientos de Calidad (4): permite habilitar la calidad del software a ser especificado en términos de requerimientos de calidad durante todo el ciclo de vida de un proyecto de software o adquisición, mantenimiento y operación.

Evaluación de la Calidad (5): Evaluación de la Calidad, Proceso para desarrolladores, Proceso para compradores, Proceso para evaluadores y Documentación del módulo de evaluación.

Estos 5 tópicos conforman la Arquitectura de SQuaRE.

Los beneficios de utilizar SQuare son: (1) El modelo representa la calidad esperada del producto de software, (2) Planteo del desdoblamiento de las necesidades o expectativas en calidad en uso, calidad externa y calidad interna, (3) Permite una mayor eficacia en la definición del software, (4) Plantea la evaluación de productos intermedios, (5) Propone una calidad final a través de las evaluaciones intermedias, (6) Permite efectuar un rastreo entre las expectativas, requisitos y medidas de evaluación; y (7) Mejora la calidad del producto.

Los pasos para la realización de una Auditoria de la Calidad del Software son: (1) Identificación del Producto de software que se pretende auditar, (2) Determinar los Requisitos aplicables, (3) Relevar la información necesaria para el cálculo de las métricas de los requisitos aplicables, (4) Evaluar la Calidad del Software usando las métricas respecto de los requisitos establecidos en el paso 2 y determinar su cumplimiento, (5) Establecer las acciones correctivas respecto de los requisitos evaluados y (6) Elaborar un Informe Final.

El Informe de Auditoria de la Calidad es un medio formal para comunicar los objetivos de la Auditoria, el cuerpo de las normas de Auditoria, el alcance de la Auditoria, y los hallazgos y conclusiones. Es el documento que refleja los objetivos, alcances, observaciones, recomendaciones y conclusiones del proceso de evaluación relacionados con las áreas de informática. El Informe debe incluir suficiente información para que sea comprendido por los destinatarios esperados y facilitar las acciones correctivas.

Existen esquemas recomendados respecto de los informes de auditoria con los requisitos mínimos aconsejables respecto a estructura y contenido. Los puntos esenciales de un Informe de Auditoria son: (1) Identificación del Informe, (2) Identificación del Cliente, (3) Identificación de la Entidad auditada, (4) Objetivos de la Auditoria Informática, (5) Normativa aplicativa y excepciones, (6) Alcance de la Auditoria, (7) Conclusiones: Informe corto de opinión , (8) Resultado: Informe largo y otros informes, (9) Informe previo, (10) Fecha del Informe, (11) Identificación y firma del Auditor, (12) Distribución del Informe y (13) Conclusiones.

Por último, se puede decir que la Auditoria de la Calidad del Software puede traer aparejado la certificación del software, lo cual permite mejorar el nivel de competitividad de la empresa con sus respectivas consecuencias.

Gestión de los Recursos e ISO 9001:2000 (3)

En todo Sistema de Gestión de la Calidad, se puede decir que la Dirección de la organización debe identificar y disponer los recursos necesarios para satisfacer los objetivos estratégicos de la organización, entre los cuales están los objetivos de la calidad.

Los aspectos a considerar en “Gestión de los Recursos” son: (1) Provisión de recursos, (2) Recursos humanos, (3) Infraestructura y (4) Ambiente de trabajo. La norma ISO 90003:2004 considera los mismos ítems que la Norma ISO 9001:2000 para el punto de Gestión de los Recursos.

El punto “Provisión de Recursos” (6.1) hace referencia a que la Dirección debe tener una clara noción de los recursos que se requieren para desempeñar los objetivos planteados y, asumiendo las restricciones que presentan el mercado y tipo de negocio, determinar cuáles serán los recursos futuros que deban procurarse a efectos de obtener los objetivos de crecimiento y mejora continua inherentes al plan estratégico y a la planificación de la calidad.

El punto “Recursos Humanos” (6.2) plantea que la Dirección debe administrar los recursos humanos de modo de fomentar la participación sobre la base de la motivación, el reconocimiento y el sentido de pertenencia. La organización debe hacer un relevamiento de las competencias exigidas a su personal en función de los requisitos de cualificación planteados por los diferentes procesos que impactan sobre la calidad. Una vez obtenido este perfil de competencias requeridas se debe estudiar las competencias que efectivamente reúne su personal y establecer planes de acción en formación para salvar cualquier brecha que pudiera quedar. Las competencias necesarias para el desempeño de los procesos no es sólo la necesidad actual de cualificación, también lo es en términos de futuro, teniendo en cuenta los planes de crecimiento o de evolución en aspectos de calidad que la organización haya establecido.

Las personas de una organización deben aprender a trabajar en contextos cambiantes, en áreas sometidas al mejoramiento continuo de condiciones y técnicas de trabajo y al uso de herramientas de gestión cambiantes y, en muchos casos, desempeñarse en contextos confusos.

Las áreas de procesos “Organizational Environment for Integration” (OEI) de CMMi V1.1 y “Organizational Training” (OT) de CMMi V1.1 y CMMI V1.2 guardan relación con este punto.

El punto “Infraestructura” (6.3) hace referencia a que la organización debe disponer los elementos de infraestructura tales como ambiente de trabajo, instalaciones asociadas, equipos, herramientas, hardware y software, servicios de apoyo tales como comunicaciones, transportes, instalaciones auxiliares, etc. En todos los casos, la organización deberá asegurar la disponibilidad de funcionamiento a través del tiempo, para todas las instalaciones aplicables.

El área de proceso “Organizational Environment for Integration” (OEI) de CMMi V1.1 guarda relación con este punto.

El punto “Ambiente de trabajo” (6.4) hace mención que la organización debe procurar el ambiente de trabajo adecuado que favorezca la consecución de los objetivos de calidad fijados, contemplando la combinación de factores físicos y humanos y promoviendo la motivación y la buena calidad de vida del personal.

Las áreas de procesos “Organizational Environment for Integration” (OEI) de CMMi V1.1 y “Project Planning” (PP) de CMMi V1.1 y CMMi V1.2 guardan relación con este punto.

De esta forma, el punto “Gestión de los Recursos” forma parte del modelo de un Sistema de Gestión de la Calidad, el cual está basado en procesos que ilustran los vínculos entre los procesos presentados en los capítulos 4 a 8 de la ISO 9001:2000.

Uso del Diagrama de Causa Efecto

El diagrama causa-efecto es una herramienta que permite analizar de forma organizada y sistemática los problemas, causas y las causas de estas causas, cuyo resultado en lo que afecta a la calidad se denominará efecto. Permite organizar y representar las diferentes teorías propuestas sobre las causas de un problema. Se conoce también como diagrama de Ishikawa o diagrama de espina de pescado dado que su estructura es similar a la del esqueleto de pescado y se utiliza en las fases de Diagnóstico y Solución de la causa. Otra acepción que recibe este diagrama es el de las 4M o 6M, según sea la cantidad de elementos que puede incluir: Materiales, Mano de obra, Métodos, Máquinas, Medio ambiente y Mantenimiento.

El diagrama causa-efecto es un vehículo para ordenar, de forma muy concentrada, todas las causas que supuestamente pueden contribuir a un determinado efecto. Permite lograr un conocimiento común de un problema complejo, sin ser nunca sustitutivo de los datos. Es importante ser conscientes que los diagramas de causa-efecto presentan y organizan teorías. Sólo cuando estas teorías son contrastadas con datos podemos probar las causas de los fenómenos observables. Errores comunes son construir el diagrama antes de analizar globalmente los síntomas, limitar las teorías propuestas enmascarando involuntariamente la causa raíz, o cometer errores tanto en la relación causal como en el orden de las teorías. Existen dos aspectos básicos que definen está herramienta: (1) ordena y (2) profundiza. Facilita la selección de las causas de mayor influencia y ayuda a adoptar medidas correctivas.

El valor de una característica de calidad depende de una combinación de variables y factores que condicionan el proceso productivo. La variabilidad de las características de calidad es un efecto observado que tiene múltiples causas. Cuando ocurre algún problema con la calidad del producto, debemos investigar para identificar las causas del mismo.

El objetivo que persigue este diagrama es reflejar organizadamente las posibles fuentes de errores o problemas, así como también los buenos efectos.

Las reglas de este diagrama son: 1- Causa probable: se considera todo aquello que genere un determinado efecto 2- Problema: es aquel efecto que se constituye en un elemento mensurable

Los procedimientos para realizar el diagrama son dos: 1- se identifican o sugieren las causas probables mediante la aplicación del Brainstorming o torbellino de ideas, detallando desde las aparentemente principales o más relevantes a las menos principales 2- se registran las causas identificadas ubicándolas sobre el diagrama

Para elaborar un diagrama de causa efecto se debe: 1- trazar una flecha gruesa o destacada de izquierda a derecha 2- indicar al finalizar la flecha, es decir, a su derecha el efecto 3- identificar las causas principales o primarias representando esas causas con sentido oblicuo en ambos lados de la flecha 4- las causas secundarias se representan mediante una flecha paralela al efecto, de izquierda a derecha, hasta tocar la que representa a la causa principal. 5- Se analizan las causas: tomamos cada causa según el orden establecido y se analiza su posible influencia en el problema 6- Se analizan los resultados del análisis: Puede pasar que: • El problema desaparezca • El problema disminuya (en este caso se deben atacar las causas restantes) • El problema siga igual Un diagrama de Causa-Efecto es de por si educativo, sirve para que la gente conozca en profundidad el proceso con que trabaja, visualizando con claridad las relaciones entre los Efectos y sus Causas. Sirve también para guiar las discusiones, al exponer con claridad los orígenes de un problema de calidad. Y permite encontrar más rápidamente las causas asignables cuando el proceso se aparta de su funcionamiento habitual.

Este diagrama se puede aplicar al punto de “Acción Correctiva” (8.5.2) de ISO 9001:2000 y de ISO 90003:2004 (ISO 9001:2000 aplicada al Software), ya que permite evaluar las causas de las no conformidades para así prevenir que ocurran nuevamente.

Respecto de CMMi V1.1 se puede decir que el área de proceso “Causal Analysis and Resolution” (CAR) tiene como finalidad detectar las causas de los defectos y otros problemas para tomar las acciones preventivas correspondientes.

De esta forma, el diagrama de causa efecto puede resultar muy útil no sólo para definir las causas de un problema sino también para evidenciar los factores positivos que pueden aplicarse a las acciones encaminadas a obtener otras mejoras.

Service Oriented Architecture

Service Oriented Architecture (SOA) es un estilo de arquitectura de Tecnología de la Información (TI) que soporta la orientación a servicios. Se basa en la independencia de plataformas de hardware, de sistemas operativos y de lenguajes de programación. Permite fortalecer la reutilización de los sistemas actuales que se construyeron y se utilizaron durante años; y crea un ambiente en el que los negocios y la TI pueden interactuar entre sí.

El Servicio es una tarea repetible que tiene una misma forma y se repite varias veces.

La Orientación a Servicios efectúa una conexión de servicios y resultados asociados. La Arquitectura Orientada a Servicios es un estilo de arquitectura que soporta la integración como servicios vinculados entre sí.

Un verdadero enfoque orientado a servicio se logra cuando las aplicaciones monolíticas son desorganizadas en servicios de negocios auto-contenidos y bien definidos. Toda la funcionalidad de infraestructura es provista mediante servicios. Los procesos de negocio son finalmente replicados como una composición de servicios, coordinada y orquestada por otro servicio.

SOA se fundamenta en: (1) Ejecutar rápido, adaptarse al mercado, ganar ante la competencia, (2) Reutilizar los componentes de los procesos de negocio, (3) Medir los resultados y tomas acciones sobre ellos, (4) Garantizar resultados que sean repetibles y predecibles y (5) Empezar donde sea necesario (área de negocios – área de tecnología).

Es posible tener una percepción distinta del mismo concepto, dependiendo del punto de vista que se emplee. Un “Ejecutivo de negocio” puede ver SOA como un conjunto de servicios de negocio que su organización busca exponer a sus clientes, socios o a otras áreas que la integran. Para un “Arquitecto”, en cambio, SOA será un estilo arquitectónico que va más allá de la implementación, al definir principios de diseño, patrones y criterios que permiten lograr características tales como modularidad, encapsulamiento, bajo acoplamiento, separación de responsabilidades, reutilización, composición, etc. Finalmente, para un “Desarrollador”, SOA es un modelo de programación que provee estándares, herramientas y tecnologías concretas, que le permiten llevar a cabo su tarea diaria.

SOA crea un conjunto de servicios que soportan procesos de negocio. Un negocio flexible permite responder a la velocidad del negocio, a la demanda de los clientes, a las condiciones del mercado y al ambiente competitivo. Un negocio flexible requiere de una infraestructura sensible. SOA brinda flexibilidad sobre sus sistemas actuales.

Las compañías que están comenzando a implementar SOA son aquellas que pueden adaptar sus procesos de negocios a los cambios del mercado, gracias a que su área de tecnología es flexible para aceptar los cambios.

SOA requiere un cambio en la forma de pensar y un cambio de tecnología. Si se analizan las tareas de negocios e identificamos aquellas que se pueden repetir, estas tareas se pueden definir como “Servicios”. Verificar un saldo, abrir una cuenta, comprobar la existencia de stock, son tareas de negocio repetibles que se denominan servicios. Por lo tanto, cualquier negocio, independientemente de su industria, posee servicios.

Existen bloques de construcción que son vistos como servicio y son una tarea de negocio. Se puede tomar cada uno de estos bloques y unirlos de manera flexible. Se puede ensamblarlos varias veces a medida que cambian sus necesidades. Cada bloque equivale a una tarea de negocios dentro de una empresa. Cada persona puede tomar distintos bloques y luego con todos construir algo diferente utilizando los mismos componentes.

Los puntos de entrada a SOA ayudan a las empresas a seguir el camino correcto: aplicando un enfoque basado en proyectos solicitando que cada proyecto entregue el valor empresarial real. Los puntos de entrada de SOA son: (1) Gente, (2) Información, (3) Procesos, (4) Reutilización, y (5) Conectividad. Las personas son la clave para la innovación y la productividad organizacional.

Analistas y Clientes concuerdan en que SOA es crítica para la innovación. La innovación se refiere a la capacidad de realizar cambios de una manera rápida, fácil y económica. La innovación que importa se refiere a todo lo que lo diferencia en su mercado. Reconocer las necesidades del mercado y responder más rápidamente que la competencia, con modelos, productos y servicios empresariales innovadores, es lo que hace que la empresa crezca. SOA ayuda a innovar al asegurar que los sistemas de TI pueden adaptarse veloz, fácil y económicamente para brindar soporte a las necesidades de negocios rápidamente cambiantes.

El ciclo de vida de SOA es: (1) Determinación de los requerimientos, (2) Ensamblado, (3) Integración, (4) Administración y (5) Gobernabilidad.

Las ventajas de SOA son: (1) Reduce el nivel de acoplamiento, (2) Mejora la definición de los roles de desarrollo, (3) Facilita la prueba del software, (4) Mejora la facilidad de mantenimiento, (5) Favorece la reusabilidad y mejora la productividad, (6) Favorece el desarrollo en paralelo, (7) Permite un monitoreo más preciso de los procesos y (8) Permite la interoperabilidad.

Se puede decir que SOA es una arquitectura formada por distintos servicios y que integrados forman un todo unido. Para cada servicio establecido, se puede tener en cuenta la Norma ISO 20000:2005 (Service Management) e ITIL (Information Technology Infrastructure Library), el cual consiste en un conjunto de mejores prácticas que pueden ser consideradas durante la implantación.

Por lo tanto, SOA es un concepto que las empresas están implementando, ya que una de las tendencias de los negocios es la prestación de servicios de TI.

Responsabilidad de la Dirección e ISO 9001:2000 (2)

En todo Sistema de Gestión de la Calidad, la Responsabilidad central pertenece a la Dirección. No es posible encarar ningún Sistema de Gestión sin tener a la Dirección completamente involucrada.

Los aspectos a considerar en “Responsabilidad de la Dirección” son: (1) Compromiso de la Dirección, (2) Enfoque al Cliente, (3) Política de la Calidad, (4) Planificación, (5) Responsabilidad, autoridad y comunicación; y (6) Revisión por la Dirección.

La norma ISO 90003:2004 (ISO 9001:2000 aplicada al Software) considera los mismos ítems que la Norma ISO 9001:2000 para el punto de “Responsabilidad de la Dirección”.

Respecto del punto “Compromiso de la Dirección” (5.1), se puede decir que la Dirección debe conocer y comunicar a la organización, los requisitos que derivan de las necesidades de los clientes como los que se asocian a regulaciones legales. Debe involucrarse en la consecución de tales requisitos, organizarse para gestionar los recursos necesarios para la producción y para revisar periódicamente que dichos requisitos se cumplan y las actividades progresen en el sentido establecido por las políticas y objetivos de calidad declarados.

El punto “Enfoque al cliente” (5.2) ,en términos del cliente o usuario final, hace referencia a la satisfacción de requisitos a través de condiciones de prestación, precios de compra o de mantenimiento, confiabilidad, disponibilidad, servicios posteriores a la venta, etc.

El área de proceso “Requirements Development” (RD) de CMMi V1.1 guarda relación con este punto.

El punto “Política de la calidad” (5.3) debe ser un documento controlado y revisado periódicamente de cara a la consecución de los objetivos de la organización. Asimismo, la política de la calidad debe ser intensivamente difundida para asegurar que todos los miembros de la organización conozcan su participación y su grado de responsabilidad en el cumplimiento de los requisitos de los clientes.

La política de la calidad debería incluir: (1) El nivel esperado de satisfacción del cliente, (2) La expresión de las necesidades de las otras partes interesadas, (3) La mención del concepto de mejora continua como guía de gestión, (4) La expresión de la visión de la Dirección para el futuro de la organización y (5) Una clara demostración del compromiso de la Dirección.

El área de proceso “Organizational Process Focus” (OPF) de CMMi V1.1 guarda relación con este punto.

El punto “Planificación” (5.4) indica que la empresa puede probar que realiza sus planes de calidad, exponiendo un plan de calidad para cada producto. Los procesos de actualización de los planes de calidad deben asegurar que la integridad del Sistema de Gestión de la Calidad no queda afectada. El plan de la calidad es el documento o conjunto de documentos que establecen los objetivos de calidad, la especificación de los procesos operativos necesarios y la disponibilidad de los recursos apropiados para satisfacer tales objetivos, para la elaboración del producto que ocupa a la organización.

La planificación incluye dos aspectos centrales: los objetivos de la calidad y la planificación de la calidad. Los objetivos de la calidad deberán estar expresados en un documento controlado, ser coherentes con la política de la calidad, estar diseñados en función de un espíritu de mejora continua y ser revisados periódicamente a efectos de vigilar su cumplimiento y, eventualmente modificar su expresión para adaptarlos a realidades cambiantes. La Dirección demostrará su accionar en este punto, exponiendo un plan de objetivos de la gestión. Todos los objetivos deben estar expresados en unidades mensurables.

Las áreas de procesos “Organizational Process Focus” (OPF), “Organizational Process Performance” (OPP), “Quantitative Project Management” (QPM) y “Organizational Process Definition” (OPD) de CMMi V1.1 guardan relación con este punto.

El punto “Responsabilidad, autoridad y comunicación” (5.5) hace referencia a que la responsabilidad y autoridad están expresadas en un documento controlado conocido como organigrama. Allí se establecen las relaciones de autoridad dentro de la organización y las interrelaciones entre los miembros del personal. Las responsabilidades de cada funcionario de la organización en lo atinente a la calidad del producto, pueden estar listadas en un documento adjunto al organigrama o en una matriz de competencias, donde en columnas se colocan los sectores de la organización y en filas las actividades de la gestión de la calidad, preferentemente divididas por capítulo. En cada celda de la matriz, habrá de establecerse el grado de responsabilidad esperado para tal sector en la ejecución de tal actividad. En la última columna, se pueden listar los procedimientos, instrucciones o documentos aplicables.

Las responsabilidades de cada funcionario de la organización deben ser claramente conocidas por todos sus miembros, en la medida en que esto sea relevante para sus respectivas actividades.

Las áreas de procesos “Organizational Process Focus” (OPF) y “Organizational Process Definition” (OPD) de CMMi V1.1 guardan relación con este punto.

El punto “Revisión por la Dirección” (5.6) indica que la Dirección debe evaluar periódicamente el avance del Sistema de Gestión de la Calidad, para asegurar su continua consistencia, adecuación y efectividad. La revisión por la Dirección debe hacerse sobre datos concretos de la gestión de la calidad pero, necesariamente, debe estar acompañada del contacto que cada directivo haya podido tener con la realidad del producto, de los clientes y de los procesos. La revisión debe conducirse de modo que se evalúe el grado de satisfacción de los objetivos de calidad y política de la calidad.

El resultado de la revisión por la Dirección, debería dar una gama de decisiones de adecuación de la organización, del sistema de la calidad, de la política o de los objetivos calidad, de los recursos dispuestos para cada proceso, de las tecnologías o del producto en sí, a efectos de corregir las tendencias y conducir la organización hacia la consecución de sus objetivos, lo cual significa llevarla hacia el cumplimiento de los requisitos de los clientes y otras partes interesadas.

Las áreas de procesos “Organizational Process Focus” (OPF) y “Project Monitoring and Control” (PMC) de CMMi V1.1 guardan relación con este punto.

De esta forma, el punto “Responsabilidad de la Dirección” forma parte del modelo de un Sistema de Gestión de la Calidad, el cual está basado en procesos que ilustran los vínculos entre los procesos presentados en los capítulos 4 a 8 de la ISO 9001:2000.

Aplicación de una Matriz FODA

La Matriz FODA es una herramienta que permite conformar un cuadro de la situación actual de la empresa u organización, permitiendo de esta manera obtener un diagnóstico preciso que permita en función de ello tomar decisiones acordes con los objetivos y políticas formulados.

El término FODA es una sigla conformada por las primeras letras de las palabras Fortalezas, Oportunidades, Debilidades y Amenazas (en inglés SWOT: Strenghts, Weaknesses, Oportunities, Threats). De estas 4 variables, tanto fortalezas como debilidades son internas de la organización, por lo que es posible actuar directamente sobre ellas. En cambio las oportunidades y las amenazas son externas, por lo que en general resulta muy difícil poder modificarlas.

El FODA o SWOT es un esquema infaltable en cualquier presentación de negocios, cuyo objeto es determinar las fortalezas y debilidades de la organización a la luz de las oportunidades y amenazas del entorno, para así buscar el ajuste entre las capacidades internas y posibilidades externas.

Fortalezas: son las capacidades especiales con que cuenta la empresa, y por los que cuenta con una posición privilegiada frente a la competencia. Recursos que se controlan, capacidades y habilidades que se poseen, actividades que se desarrollan positivamente, etc.

Oportunidades: son aquellos factores que resultan positivos, favorables, explotables, que se deben descubrir en el entorno en el que actúa la empresa, y que permiten obtener ventajas competitivas.

Debilidades: son aquellos factores que provocan una posición desfavorable frente a la competencia, recursos de los que se carece, habilidades que no se poseen, actividades que no se desarrollan positivamente, etc.

Amenazas: son aquellas situaciones que provienen del entorno y que pueden llegar a atentar incluso contra la permanencia de la organización.

El objetivo de FODA es convertir los datos del universo en información, procesada y lista para la toma de decisiones estratégicas. En términos de sistemas, tenemos un conjunto inicial de datos (universo a analizar), un proceso (análisis FODA) y un producto, que es la información para la toma de decisiones (el informe FODA que resulta del análisis FODA).

Cualquier persona puede hacer un análisis FODA. Para ello, se deberá tener la capacidad de distinguir en un sistema lo siguiente: (1) Lo relevante de lo irrelevante, (2) Lo externo de lo interno y (3) Lo bueno de lo malo.

El FODA permite analizar nuestra empresa siempre y cuando podamos responder tres preguntas: (1) Lo que estoy analizando, ¿es relevante?, (2) ¿Está fuera o dentro de la empresa? y (3) ¿Es bueno o malo para mi empresa?

La relevancia es el primer proceso y funciona como filtro: no todo merece ser elevado a componente del análisis estratégico. En todos los órdenes de la vida es fundamental distinguir lo relevante de lo irrelevante. En FODA este filtro reduce nuestro universo de análisis disminuyendo nuestra necesidad de procesamiento. La relevancia depende de dónde estemos parados, y este concepto de relatividad es importante. Quien hace un análisis FODA debe conocer el negocio. Luego del filtrado de datos, se pasa a clasificarlos. Se construye una matriz con dos dimensiones (dentro/fuera, bueno/malo):

La clave para distinguir entre el adentro y el afuera de la empresa está en adoptar una visión de sistemas y saber distinguir los límites del mismo. Para esto hay que tener en cuenta, no la disposición física de los factores, sino el control que se tenga sobre ellos. Límite es todo lo que me afecta y controlo, es interno al sistema. Lo que me afecta pero está fuera de mi control, es ambiente (externo).

Respecto de la dimensión positivo/negativo, se puede decir que el competitivo ambiente de los negocios está lleno de maniobras, engaños, etc. Las circunstancias pueden cambiar de un día al otro también en el interior de la empresa. La Fortaleza se puede convertir en una grave Debilidad o la Debilidad puede más tarde revelarse como Fortaleza.

La Matriz FODA indica 4 estrategias que pueden ser llevadas a cabo de manera concurrente y de manera concertada. Las estrategias son:

1- Estrategia DA (Debilidades –vs- Amenazas) (Mini – Mini): su objetivo es minimizar tanto las debilidades como las amenazas.

2- Estrategia DO (Debilidades –vs-Oportunidades) (Mini – Maxi): intenta minimizar las debilidades y maximizar las oportunidades. Una empresa podría identificar oportunidades en el medio ambiente externo pero tener debilidades organizacionales que le eviten aprovechar las ventajas del mercado.

3- Estrategia FA (Fortalezas vs Amenazas) (Maxi – Mini): se basa en las fortalezas de la empresa que pueden copar con las amenazas del medio ambiente externo. Su objetivo es maximizar las primeras mientras se minimizan las segundas. Esto, sin embargo, no significa necesariamente que una empresa fuerte tenga que dedicarse a buscar amenazas en el medio ambiente externo para enfrentarlas. Por lo contrario, las fortalezas de una empresa deben ser usadas con mucho cuidado y discreción.

4- Estrategia FO (Fortalezas vs Oportunidades) (Maxi – Maxi): cualquier empresa le agradaría estar siempre en la situación donde pudiera maximizar tanto sus fortalezas como sus oportunidades, es decir aplicar siempre la estrategia FO. Tales empresas podrían echar mano de sus fortalezas, utilizando recursos para aprovechar la oportunidad del mercado para sus productos y servicios.

La sagacidad del empresario debe convertir las Amenazas en Oportunidades y las Debilidades en Fortalezas. FORTALEZAS -> Explotar, Potenciar DEBILIDADES -> Destruir OPORTUNIDADES -> Identificar AMENAZAS -> Evitar

Teniendo en cuenta lo desarrollado anteriormente, se puede decir que un Matriz FODA tiene como finalidad el “Análisis de un proceso o producto” y puede ser utilizada en un Proyecto de Calidad, en el que se decida implantar algún Modelo o Estándar de Calidad del Software.

Considerando la finalidad de esta herramienta, es posible aplicarla en los diferentes procesos que conforman ISO 9001:2000 e ISO 90003:2004. Tales procesos podrían ser: Gestión de los Recursos, Realización del Producto, Mejora continua y otros.

En el caso de CMMI V1.1 esta herramienta puede ser aplicada a las diferentes áreas de procesos que conforman el Modelo, ya que contribuye al análisis de cada área y sus posibles medidas correctivas y/o preventivas.

De esta forma, la Matriz FODA es una herramienta que puede ser aplicada de manera continua a los procesos organizacionales, para así lograr los objetivos planteados y un mejoramiento continuo en la empresa.

Overview de la Guía del PMBOK 3ra Edición

La Guía de PMBOK, editada por 3ra vez en el año 2004, define el ciclo de vida de la Administración de Proyecto en grupos de procesos. Un Proyecto es aquello que permite crear un único producto, servicio o resultado. Los proyectos concluyen cuando los objetivos han sido cumplidos. Están organizados en actividades y son implementados como resultado de realizar un plan estratégico de la organización. Las organizaciones y los proyectos difieren en que las operaciones son repetitivas mientras que los proyectos son temporarios y únicos. Temporario significa que todo proyecto tiene un principio y un final definido. Único significa que el producto o servicio es distinto respecto de otros productos o servicios.

Los proyectos son entendidos en todos los niveles de la organización, pueden involucrar una persona o cientos y su tiempo de duración va desde unas pocas semanas hasta más de cinco años. Pueden involucrar una unidad de la organización o varias.

La Administración de Proyecto (AP) es la aplicación de conocimiento, herramientas y técnicas en las actividades del proyecto que cumplen con los requerimientos del proyecto. Esta AP es realizada a través del uso de procesos tales como: (1) Inicio, (2) Planificación, (3) Ejecución, (4) Control y (5) Cierre. La AP es realizada durante la aplicación e integración de los procesos de AP. El equipo del proyecto administra el trabajo de los proyectos y el gerente del proyecto es la persona responsable de lograr los objetivos del proyecto.

La AP se desarrolla dentro de un contexto, el cual describe el ambiente en el que operan los proyectos. El equipo debe entender este contexto. Los procesos de AP describen una visión general de cómo interactúan varios procesos de AP. Cada proceso tiene definido entradas, salidas y herramientas / técnicas que se pueden utilizar.

Las áreas de conocimiento de la AP describen el conocimiento de la AP y las prácticas en términos de sus procesos componentes. Las 9 áreas de conocimiento son: (1) Manejo de la Integración del Proyecto, (2) Manejo del Alcance del Proyecto, (3) Manejo del Tiempo del Proyecto, (4) Manejo del Costo del Proyecto, (5) Administración de la Calidad del Proyecto, (6) Administración de los Recursos Humanos del Proyecto, (7) Manejo de las Comunicaciones del Proyecto, (8) Manejo del Riesgo del Proyecto y (9) Manejo del Abastecimiento del Proyecto.

(1) Manejo de Integración del Proyecto (PIM -Project Integration Management) incluye los procesos y actividades necesarias para identificar, definir, combinar, unificar y coordinar varios procesos y actividades de la AP (Administración de Proyectos). En el contexto de la AP, la Integración incluye características de unificación, consolidación, articulación y acciones de integración que son cruciales para la terminación del Proyecto, satisfacer los requerimientos del cliente y administrar las excepciones.

Los procesos de PIM son: (1) Develop Project Charter, (2) Develop Preliminary Project Scope, (3) Develop Project Management Plan, (4) Direct and Manage Project Execution, (5) Monitor and Control Project Work, (6) Integrated Change Control y (7) Close Project.

Algunas de las herramientas / técnicas utilizadas son: (1) Earned Value Technique, (2) Expert Judgment, (3) Project Management Information System, (4) Project Management Methodology y (5) Project Selection Methods.

(2) Manejo del Alcance del Proyecto (PSM - Project Scope Management) incluye los procesos requeridos para asegurar que el proyecto incluye todo el trabajo necesario para completar el proyecto de manera exitosa. PSM permite definir y controlar que está y no está incluido en el proyecto.

Los procesos de PTM son: (1) Scope Planning, (2) Scope Definition, (3) Create WBS, (4) Scope Verification y (5) Scope Control. En PTM se utilizan algunas de las siguientes herramientas y técnicas: (1) Alternative Identification, (2) Change Control System, (3) Decomposition, (4) Inspection, (5) Product Analysis, (6) Replanning y (7) Variance Analysis.

(3) Manejo del Tiempo del Proyecto (PTM - Project Time Managemen) incluye los procesos necesarios para terminar a tiempo el proyecto.

Los procesos de PTM son: (1) Activity Definition, (2) Activity Sequencing, (3) Activity Resource Estimating, (4) Activity Duration Estimating, (5) Schedule Development y (6) Schedule Control.

Algunas de las herramientas y técnicas utilizadas en el PTM son: (1) Decomposition, (2) Rolling wave planning, (3) Planning component, (4) Precedence Diagramming Method (PDM), (5) Dependency determination, (6) Applying leads and legs, (7) Alternatives analysis, (8) Bottom up estimating, (9) Parametric estimating, (10) Reserve analysis, (11) Critical path method, (12) Critical chain method, (13) Schedule change control system y (14) Performance measurement.

La Administración de los Costos de un Proyecto (4) (Project Cost Management – PCM) incluye los procesos de planificación, estimación, soporte y control de costos, así como que el proyecto pueda ser completado dentro del presupuesto aprobado. Cada proceso puede involucrar el esfuerzo de una o más personas o grupos de personas basadas en las necesidades del proyecto. Cada proceso ocurre al menos una vez en todo el proyecto y ocurre en una o más etapas del proyecto, si el proyecto está dividido en partes. PCM tiene que ver con el costo de los recursos necesarios para completar las actividades programadas. PCM considera el efecto de las decisiones del proyecto sobre el costo de uso, mantenimiento y soporte del producto, servicio o resultado del proyecto.

Los procesos de PCM son: (1) Estimación del Costo, (2) Presupuesto del Costo y (3) Control del Costo. Algunas de las herramientas y técnicas utilizadas en PCM son: (1) Analogous Estimating, (2) Determine Resource Cost Rates, (3) Bottom up estimating, (4) Parametric Estimating, (5) Vendor Bid Analysis, (6) Cost of Quality, (7) Cost Aggregation, (8) Cost Change Control System, (9) Performance measurement analysis y (10) Variance Management.

Los procesos de Administración de la Calida del Proyecto (PQM - Project Quality Management (5) incluyen todas las actividades de la organización que determinarán las políticas de calidad, objetivos y responsabilidades que el proyecto considerará. PQM implementa el SGC a través de la política, procedimientos y procesos de planificación de la calidad, aseguramiento de la calidad y control de calidad, con actividades de mejoramiento continuo de procesos. PQM se aplica en la administración del proyecto y en el producto del proyecto. En la administración de la calidad, es importante lo siguiente: (1) satisfacción del cliente, (2) inspección y prevención, (3) responsabilidad de la dirección y (4) mejoramiento continuo.

Los procesos de PQM son: (1) Planificación de la Calidad, (2) Aseguramiento de la Calidad y (3) Control de Calidad Algunas de las herramientas y técnicas utilizadas en PQM son: (1) Cost Benefit Analysis, (2) Benchmarking, (3) Design of Experiments, (4) Cost of Quality, (5) Quality Planning Tools and Techniques, (6) Quality Audits, (7) Quality Control Tools and Techniques, (8) Cause and Effect Diagram, (9) Control Charts, (10) Histogram, (11) Pareto Chart, (12) Statistical Sampling, (13) Inspection y (14) Defect Repair Review.

(6) Administración de Recursos Humanos (PHRM - Project Human Resource Management) incluye los procesos que organizan y administran el equipo del proyecto. Este equipo tiene asignado roles y responsabilidades; y también estará involucrado en la planificación y toma de decisiones. El tipo y número de miembros del equipo del proyecto pueden cambiar durante el proyecto. El equipo de AP es un subgrupo del equipo del proyecto y su responsabilidad son las actividades de AP tales como planificación, control y cierre. Este grupo puede ser llamado “equipo líder”.

Los procesos de PHRM son: (1) Planificar los Recursos Humanos, (2) Adquirir el equipo del proyecto, (3) Desarrollar el equipo del proyecto y (4) Administrar el equipo del proyecto. Algunas de las herramientas y técnicas utilizadas en PHRM son: (1) Organization Chart and Position Descriptions, (2) Networking, (3) Negotiation, (4) Virtual Teams, (5) General Management Skills, (6) Training, (7) Team Building Activities, (8) Recognition and Rewards, (9) Observation and Conversation y (10) Conflict Management.

(7) Project Communications Management (PCM) está formada por procesos que permiten asegurar oportunamente la generación, recopilación, almacenamiento, distribución y recuperación de información del proyecto. PCM provee vínculos entre la gente y la información que son necesarios para una comunicación exitosa. Un modelo básico de comunicación demuestra cómo la información es enviada y recibida entre 2 partes definidas como emisor y receptor. Los componentes claves del modelo incluyen: (1) codificador, (2) mensaje, (3) medio, (4) interface y (5) decodificador.

Los procesos de PCM son: (1) Planificación de la Comunicación, (2) Distribución de la Información, (3) Informar el performance y (4) Administrar los grupos de inversores. Algunas de las herramientas y técnicas asociadas a PCM son: (1) Communications Requirements Analysis, (2) Communications Technology, (3) Communications Skills, (4) Information Distribution Methods, (5) Lessons Learned Process, (6) Performance Information Gathering and Compilation, (7) Time Reporting Systems y (8) Communication Methods.

El Manejo de Riesgo del Proyecto (8) (Project Risk Management - PRM) incluye procesos relacionados con la planificación, identificación, análisis, respuestas, monitoreo y control de un proyecto. Los objetivos del PRM es aumentar la probabilidad e impacto de eventos positivos, y disminuir la probabilidad e impacto de eventos negativos. El riesgo del proyecto es un evento incierto que tiene un efecto positivo o negativo respecto de un objetivo del proyecto (tiempos, costos, alcance o programación). Un riesgo puede tener una o más causas y, si ocurre, puede tener uno o más impactos.

Los procesos de PRM son: (1) Planificación del riesgo del proyecto, (2) Identificación del riesgo, (3) Análisis del riesgo cualitativo, (4) Análisis del riesgo cuantitativo, (5) Planificación de la respuesta del riesgo y (6) Monitoreo y control del riesgo. Algunas de las herramientas / técnicas asociadas a PRM son: (1) Information Gathering Techniques, (2) Assumptions Analysis, (3) Risk Probability and Impact Assessment, (4) Risk Data Quality Assessment, (5) Risk Categorization, (6) Risk Urgency Assessment, (7) Quantity Risk Analysis and Modeling Techniques, (8) Strategies for Negative Risks or Threats, (9) Strategies for Positive Risks or Opportunities, (10) Strategy for Both Threats and Opportunities, (11) Contingent Response Strategy, (12) Risk Audits, (13) Technical Performance Measurement y (14) Reserve Analysis.

El Manejo del Abastecimiento del Proyecto (9) (PPM – Project Procurement Management) incluye los procesos para comprar o adquirir los productos, servicios o resultados necesarios que el equipo del proyecto necesita para realizar el trabajo. Este manejo incluye la administración del contrato y los procesos de control de cambio requeridos para administrar los contratos u órdenes de compra emitidas por medio de los miembros autorizados del equipo del proyecto. También incluye la administración de algún contrato emitido por una organización externa (comprador) y de las obligaciones contractuales del equipo del proyecto.

Los procesos de PPM son: (1) Planificación de las compras y adquisiciones, (2) Planificación del contrato, (3) Respuestas de la solicitud del vendedor, (4) Seleccionar los vendedores, (5) Administración del contrato y (6) Cierre del contrato. Algunas de las herramientas y técnicas asociadas a PPM son: (1) Make or Buy Analysis, (2) Contract Types, (3) Develop Qualified Sellers List, (4) Contract Negotiation, (5) Seller Rating Systems, (6) Proposal Evaluation Techniques, (7) Contract Change Control System, (8) Buyer Conducted Performance Review, (9) Inspections and Audits, (10) Payment System, (11) Claims Administration, (12) Records Management System, (13) Information Technology y (14) Procurement Audits.

De esta forma, se puede decir que esta Guía puede ser utilizada como herramienta, en diferentes tipos de empresas, para el desarrollo de un proyecto, y así poder evitar futuros problemas. Para la implantación de esta Guía podría ser aconsejable el uso de formularios que permitan documentar el desarrollo de los distintos procesos de AP. La correcta implantación, seguimiento y control de esta Guía puede garantizar el desarrollo de un proyecto exitoso.