UNIDAD V. CALIDAD DE SOFTWARE
DEFINICIÓN DE CALIDAD.
IMPORTANCIA DE LA CALIDAD.
El control de calidad permite ahorrar la máxima cantidad de dinero cuando se realiza al comienzo del proceso de desarrollo de software. No es sorprendente que los errores detectados en los comienzos del proceso de desarrollo de software sean más fáciles de resolver y menos costosos que los que se detectan más adelante. En su libro [24] "Software Economics", publicado en 1981, Barry Boehm afirma que un defecto cuya corrección requiere una hora en el momento en que se definen los requerimientos del sistema requerirá al menos 100 horas si no se detecta hasta que el sistema está en fase de producción. Este es un argumento muy poderoso a favor de aplicar un énfasis especial a la mejora de la calidad al comienzo del proceso. El argumento es algo parecido a esto: sabemos que la calidad es importante, pero cuesta tiempo y dinero —demasiado tiempo y dinero— lograr el nivel de calidad en el software que en realidad queremos.
Visto así, este argumento parece razonable (véanse los comentarios anteriores de Meyer en esta sección). No hay duda de que la calidad tiene un costo, pero la mala calidad también lo
tiene —no sólo para los usuarios finales que deban vivir con el software defectuoso, sino también para la organización del software que lo elaboró y que debe darle mantenimiento—.
Uno de los valores institucionales del plan
2003-2007 es la calidad: “La conducción
exitosa de nuestra organización requiere
que ésta se dirija y controle de forma sistemática
y transparente, lo cual se puede lograr
aplicando y manteniendo un sistema
de gestión de calidad que esté diseñado
para mejorar continuamente el desempeño,
considerando las necesidades de todas
las partes interesadas”. La gestión de calidad
consiste en mejorar continuamente un
proceso para que sea visible, repetible y
mensurable; examina lo intangible que
afecta al proceso y trabaja para optimizar
su impacto.
Con base en estos planes es necesario destacar la importancia de la calidad en el desarrollo de software. Durante los primeros años de la computación (años sesenta) la calidad era responsabilidad única del programador. En los años setenta se introdujeron estándares de garantía de calidad para el software en los contratos militares, extendiéndose posteriormente a los desarrollos del software en el mundo comercial. La calidad en el desarrollo del software es el conjunto de actividades que se aplica a un plan de desarrollo del software tales como: pruebas, revisiones y verificaciones para asegurar que el producto desarrollado cumpla con los requisitos asignados. El objetivo de estas actividades es:
FACTORES DE LA CALIDAD DE McCall.
McCall, Richards y Walters [McC77] proponen una clasificación útil de los factores que afectan la calidad del software. Éstos se ilustran en la figura 14.1 y se centran en tres aspectos importantes del producto de software: sus características operativas, su capacidad de ser modificado y su adaptabilidad a nuevos ambientes.
En relación con los factores mencionados en la figura 14.1, McCall et al., hacen las descripciones siguientes:
Corrección: Grado en el que un programa satisface sus especificaciones y en el que cumple con los objetivos de la misión del cliente.
Confiabilidad: Grado en el que se espera que un programa cumpla con su función y con la precisión requerida.
Eficiencia: Cantidad de recursos de cómputo y de código requeridos por un programa para llevar a cabo su función.
Integridad: Grado en el que es posible controlar el acceso de personas no autorizadas al software o a los datos.
Usabilidad: Esfuerzo que se requiere para aprender, operar, preparar las entradas e interpretar las salidas de un programa.
Facilidad de recibir mantenimiento. Esfuerzo requerido para detectar y corregir un error en un programa.
Flexibilidad: Esfuerzo necesario para modificar un programa que ya opera.
Susceptibilidad de someterse a pruebas: Esfuerzo que se requiere para probar un programa a fin de garantizar que realiza la función que se pretende.
Portabilidad: Esfuerzo que se necesita para transferir el programa de un ambiente de sistema de hardware o software a otro.
Reusabilidad: Grado en el que un programa (o partes de uno) pueden volverse a utilizar en otras aplicaciones.
Interoperabilidad: Esfuerzo requerido para acoplar un sistema con otro.
Es difícil — y, en ciertos casos, imposible— desarrollar mediciones directas de estos factores de la calidad. En realidad, muchas de las unidades de medida definidas por McCall etc al., sólo pueden obtenerse de manera indirecta. Sin embargo, la evaluación de la calidad de una aplicación por medio de estos factores dará un indicio sólido de ella.
En un nivel algo pragmático, David Garvin [Gar84], de Harvard Business School, sugiere que “la calidad es un concepto complejo y de facetas múltiples” que puede describirse desde cinco diferentes puntos de vista. El punto de vista trascendental dice (como Persig) que la calidad es algo que se reconoce de inmediato, pero que no es posible definir explícitamente.
El punto de vista del usuario concibe la calidad en términos de las metas específicas del usuario final. Si un producto las satisface, tiene calidad. El punto de vista del fabricante la define en términos de las especificaciones originales del producto. Si éste las cumple, tiene calidad. El punto de vista del producto sugiere que la calidad tiene que ver con las características inherentes (funciones y características) de un producto. Por último, el punto de vista basado en el valor la mide de acuerdo con lo que un cliente está dispuesto a pagar por un producto. En realidad, la calidad incluye todo esto y más.
La calidad del diseño se refiere a las características que los diseñadores especifican para un producto. El tipo de materiales, tolerancias y especificaciones del desempeño, todo contribuye a la calidad del diseño. Si se utilizan mejores materiales, tolerancias más estrictas y se especifican mayores niveles de desempeño, la calidad del diseño de un producto se incrementa si se fabrica de acuerdo con las especificaciones.
En el desarrollo del software, la calidad del diseño incluye el grado en el que el diseño cumple las funciones y características especificadas en el modelo de requerimientos. La calidad de la conformidad se centra en el grado en el que la implementación se apega al diseño y en el que el sistema resultante cumple sus metas de requerimientos y desempeño.
IMPORTANCIA DE LA CALIDAD.
El control de calidad permite ahorrar la máxima cantidad de dinero cuando se realiza al comienzo del proceso de desarrollo de software. No es sorprendente que los errores detectados en los comienzos del proceso de desarrollo de software sean más fáciles de resolver y menos costosos que los que se detectan más adelante. En su libro [24] "Software Economics", publicado en 1981, Barry Boehm afirma que un defecto cuya corrección requiere una hora en el momento en que se definen los requerimientos del sistema requerirá al menos 100 horas si no se detecta hasta que el sistema está en fase de producción. Este es un argumento muy poderoso a favor de aplicar un énfasis especial a la mejora de la calidad al comienzo del proceso. El argumento es algo parecido a esto: sabemos que la calidad es importante, pero cuesta tiempo y dinero —demasiado tiempo y dinero— lograr el nivel de calidad en el software que en realidad queremos.
Visto así, este argumento parece razonable (véanse los comentarios anteriores de Meyer en esta sección). No hay duda de que la calidad tiene un costo, pero la mala calidad también lo
tiene —no sólo para los usuarios finales que deban vivir con el software defectuoso, sino también para la organización del software que lo elaboró y que debe darle mantenimiento—.
Con base en estos planes es necesario destacar la importancia de la calidad en el desarrollo de software. Durante los primeros años de la computación (años sesenta) la calidad era responsabilidad única del programador. En los años setenta se introdujeron estándares de garantía de calidad para el software en los contratos militares, extendiéndose posteriormente a los desarrollos del software en el mundo comercial. La calidad en el desarrollo del software es el conjunto de actividades que se aplica a un plan de desarrollo del software tales como: pruebas, revisiones y verificaciones para asegurar que el producto desarrollado cumpla con los requisitos asignados. El objetivo de estas actividades es:
- Descubrir errores en la función, la lógica y en el desarrollo de cualquier desarrollo de software.
- Verificar que el software bajo revisión cumple los requisitos.
- Asegurar que el software cumple los estándares predefinidos.
FACTORES DE LA CALIDAD DE McCall.
McCall, Richards y Walters [McC77] proponen una clasificación útil de los factores que afectan la calidad del software. Éstos se ilustran en la figura 14.1 y se centran en tres aspectos importantes del producto de software: sus características operativas, su capacidad de ser modificado y su adaptabilidad a nuevos ambientes.
En relación con los factores mencionados en la figura 14.1, McCall et al., hacen las descripciones siguientes:
Corrección: Grado en el que un programa satisface sus especificaciones y en el que cumple con los objetivos de la misión del cliente.
Confiabilidad: Grado en el que se espera que un programa cumpla con su función y con la precisión requerida.
Eficiencia: Cantidad de recursos de cómputo y de código requeridos por un programa para llevar a cabo su función.
Integridad: Grado en el que es posible controlar el acceso de personas no autorizadas al software o a los datos.
Usabilidad: Esfuerzo que se requiere para aprender, operar, preparar las entradas e interpretar las salidas de un programa.
Facilidad de recibir mantenimiento. Esfuerzo requerido para detectar y corregir un error en un programa.
Flexibilidad: Esfuerzo necesario para modificar un programa que ya opera.
Susceptibilidad de someterse a pruebas: Esfuerzo que se requiere para probar un programa a fin de garantizar que realiza la función que se pretende.
Portabilidad: Esfuerzo que se necesita para transferir el programa de un ambiente de sistema de hardware o software a otro.
Reusabilidad: Grado en el que un programa (o partes de uno) pueden volverse a utilizar en otras aplicaciones.
Interoperabilidad: Esfuerzo requerido para acoplar un sistema con otro.
Es difícil — y, en ciertos casos, imposible— desarrollar mediciones directas de estos factores de la calidad. En realidad, muchas de las unidades de medida definidas por McCall etc al., sólo pueden obtenerse de manera indirecta. Sin embargo, la evaluación de la calidad de una aplicación por medio de estos factores dará un indicio sólido de ella.
FACTORES DE CALIDAD ISO 9126.
El estándar ISO 9126 se desarrolló con la intención de identificar los atributos clave del software de cómputo. Este sistema identifica seis atributos clave de la calidad:
Funcionalidad: Grado en el que el software satisface las necesidades planteadas según las establecen los atributos siguientes: adaptabilidad, exactitud, interoperabilidad, cumplimiento y seguridad.
Confiabilidad: Cantidad de tiempo que el software se encuentra disponible para su uso, según lo indican los siguientes atributos: madurez, tolerancia a fallas y recuperación.
Usabilidad: Grado en el que el software es fácil de usar, según lo indican los siguientes subatributos: entendible, aprendible y operable.
Eficiencia: Grado en el que el software emplea óptimamente los recursos del sistema, según lo indican los subatributos siguientes: comportamiento del tiempo y de los recursos.
Facilidad de recibir mantenimiento: Facilidad con la que pueden efectuarse reparaciones al software, según lo indican los atributos que siguen: analizable, cambiable, estable, susceptible de someterse a pruebas.
Portabilidad: Facilidad con la que el software puede llevarse de un ambiente a otro según lo indican los siguientes atributos: adaptable, instalable, conformidad y sustituible.
Igual que otros factores de la calidad del software estudiados en las subsecciones anteriores, los factores ISO 9126 no necesariamente conducen a una medición directa. Sin embargo, proporcionan una base útil para hacer mediciones indirectas y una lista de comprobación excelente para evaluar la calidad del sistema.
ASEGURAMIENTO DE LA CALIDAD.
El aseguramiento de la calidad del software incluye un rango amplio de preocupaciones y actividades que se centran en la administración de la calidad del software. Éstas se resumen como sigue:
Estándares: El IEEE, ISO y otras organizaciones que establecen estándares han producido una amplia variedad de ellos para ingeniería de software y documentos relacionados.
Los estándares los adopta de manera voluntaria una organización de software o los impone el cliente u otros participantes. El trabajo del ACS es asegurar que los estándares que se hayan adoptado se sigan, y que todos los productos del trabajo se apeguen a ellos.
Revisiones y auditorías: Las revisiones técnicas son una actividad del control de calidad que realizan ingenieros de software para otros ingenieros de software. Su objetivo es detectar errores. Las auditorías son un tipo de revisión efectuada por personal de ACS con objeto de garantizar que se sigan los lineamientos de calidad en el trabajo de la ingeniería de software. Por ejemplo, una auditoría del proceso de revisión se efectúa para asegurar que las revisiones se lleven a cabo de manera que tengan la máxima probabilidad de descubrir errores.
Pruebas: Las pruebas del software son una función del control de calidad que tiene un objetivo principal: detectar errores. El trabajo del ACS es garantizar que las pruebas se planeen en forma apropiada y que se realicen con eficiencia, de modo que la probabilidad de que logren su objetivo principal sea máxima.
Colección y análisis de los errores: La única manera de mejorar es medir cómo se está haciendo algo. El ACS reúne y analiza errores y datos acerca de los defectos para entender mejor cómo se cometen los errores y qué actividades de la ingeniería de software
son más apropiadas para eliminarlos.
Administración del cambio: El cambio es uno de los aspectos que más irrumpe en cualquier proyecto de software. Si no se administra en forma adecuada, lleva a la confusión
y ésta casi siempre genera mala calidad. El ACS asegura que se hayan instituido prácticas adecuadas de administración del cambio.
Educación: Toda organización de software quiere mejorar sus prácticas de ingeniería de software. Un contribuyente clave de la mejora es la educación de los ingenieros de software, de sus gerentes y de otros participantes. La organización de ACS lleva el liderazgo en la mejora del proceso de software y es clave para proponer y patrocinar programas educativos.
Administración de los proveedores: Son tres las categorías de software que se adquieren
a proveedores externos: paquetes contenidos en una caja (por ejemplo, Office, de Microsoft);
un shell personalizado, que da una estructura básica, tipo esqueleto, que se adapta de manera única a las necesidades del comprador; y software contratado, que se diseña y construye especialmente a partir de especificaciones provistas por la organización cliente. El trabajo de la organización de ACS es garantizar que se obtenga software de alta calidad a partir de las sugerencias de prácticas específicas de calidad que el proveedor debe seguir (cuando sea posible) y de la incorporación de cláusulas de calidad como parte de cualquier contrato con un proveedor externo.
Administración de la seguridad: Con el aumento de los delitos cibernéticos y de las nuevas regulaciones gubernamentales respecto de la privacidad, toda organización de software debe instituir políticas para proteger los datos en todos los niveles, establecer cortafuegos de protección para las webapps y asegurar que el software no va a ser vulnerado internamente. El ACS garantiza que para lograr la seguridad del software, se utilicen el proceso y la tecnología apropiados.
Seguridad: Debido a que el software casi siempre es un componente crucial de los sistemas
humanos (como aplicaciones automotrices o aeronáuticas), la consecuencia de defectos ocultos puede ser catastrófica. El ACS es responsable de evaluar el efecto de las fallas del software y de dar los pasos que se requieren para disminuir el riesgo.
Administración de riesgos: Aunque el análisis y la mitigación de riesgos es asunto de los ingenieros de software, la organización del ACS garantiza que las actividades de administración de riesgos se efectúen en forma apropiada y que se establezcan planes de contingencia relacionados con los riesgos.
Además de cada una de estas preocupaciones y actividades, el ACS tiene como preocupación dominante asegurar que las actividades de apoyo del software (como mantenimiento, líneas de ayuda, documentación y manuales) se lleven a cabo o se produzcan con calidad.
ESTANDARES Y MÉTRICAS DE CALIDAD.
CMMI: Éste es un modelo para la mejora de procesos que proporciona a las organizaciones los elementos esenciales para procesos de desarrollo y mantenimiento de software.
Durante los 90, SEI desarrolló modelos para la mejora y medición de la madurez (CMM o Capability Maturity Model) específicos para varias áreas:
• CMM-SW: CMM for software
• P-CMM: People CMM.
• SA-CMM: Software Acquisition CMM.
• SSE-CMM: Security Systems Engineering CMM.
• T-CMM: Trusted CMM
• SE-CMM: Systems Engineering CMM.
• IPD-CMM: Integrated Product Development CMM.
Luego del uso y aplicación individual de éstos modelos de madurez, SEI desarrolló CMMI para facilitar y simplificar la adopción de forma simultánea de CMMSW (CMM for Software), SE-CMM(Systems Engineering Capability Maturity Model) e IPDCMM(
Integrated Product Development) y de ahí la palabra Integración en la sigla. Antes de CMMI el modelo más común era CMM-SW y se puede ver CMMI como la evolución de éste último.
Éste modelo presenta una estructura de cinco niveles de madurez, en los cuales una organización puede determinar su madurez en la producción de software en función de la consecución de los objetivos establecidos en cada nivel.
Según el nivel de madurez en que se encuentre la empresa, las medidas se enfocarán más al grupo de objetivos del nivel correspondiente, para que mejore la capacidad de producir software y pueda avanzar hacia el siguiente nivel.
Los niveles de madurez de una organización en CMMI son:
1.Inicial.
2. Gestionado.
3. Definido.
4. Gestionado cuantitativamente.
5. Optimizando o en Optimización Continua.
Inicial o Nivel 1 CMMI: En los procesos de una empresa en éste nivel, la transición desde las entradas hasta las salidas está mal definida y descontrolada, provocando que proyectos similares puedan tener una gran variación en cuanto a su productividad y en su calidad debido a la ausencia de una estructura y control adecuados. Las empresas en este nivel deben comenzar por definir y recoger datos, estableciendo una serie de medidas de líneas base. El objetivo principal es proporcionar un punto de partida para medir, a través de comparación, las mejoras según se incremente la madurez
Gestionado o Nivel 2 CMMI: En este nivel la característica de los procesos es ser intuitivos,
coexistiendo unos costos y calidad altamente variables, junto con un razonable control de la planificación y con unos métodos o procedimientos informales efectuados en el mismo instante. De esta forma, se identifican las entradas y las salidas del proceso, las restricciones, como presupuesto o calendario y los recursos utilizados para obtener el producto final.
En la definición de CMM, éste nivel de madurez se denomina repetible. El proceso es repetible en el sentido de que las mismas entradas producen las mismas salidas, pero todavía no es posible observar cómo se generan las salidas.
Definido o Nivel 3 CMMI: Éste pasa a ser un nivel cualitativo, donde se comienza a gestionar correctamente tanto los costos como la planificación dentro de unos límites razonables. Ahora sí se conoce la forma de construcción del sistema, ya que se conocen las actividades intermedias y cuáles son las entradas y salidas para las mismas. Por tanto, es posible examinar y medir estas actividades, dado que los productos intermedios están bien definidos.
Esta definición afecta tanto a los procesos de administración como a los de ingeniería, que están documentados de una forma estándar dentro del proceso de software de la organización. De esta forma, todos los proyectos utilizan en el desarrollo y mantenimiento del
software una versión del proceso documentada.
Gestionado cuantitativamente o Nivel 4 CMMI: A diferencia del nivel anterior, este cuarto nivel pasa a ser un nivel cuantitativo. Ahora se tienen medidas detalladas del proceso del software y de la calidad del producto,habilitando la presencia de un cierto control estadístico
sobre la calidad del producto. Una vez definido el proceso, se le añade la gestión del mismo.
Optimizado o Nivel 5 CMMI: En este último nivel de optimización continua, las bases cuantitativas se utilizan para una inversión continua de capital en el proceso de automatización y mejora de manera que la organización alcanza el nivel superior de la madurez de procesos.
Las medidas en este nivel, se utilizan para mejorar el proceso, quitando o añadiendo actividades e incluso cambiando su estructura en función de las medidas obtenidas. Resumiendo se trata de aportar nuevos aspectos, ideas y tecnologías que permitan mejorar el
proceso del software.
En el objetivo de determinar la madurez de una organización en los niveles mencionados, se considera la calificación de la capacidad de los procesos en niveles con nombres y características muy similares al nivel de madurez de la organización (Incompleto, Ejecutado, Gestionado, Definido, Gestionado Cuantitativamente y Optimizado), adicionando un nivel de capacidad incompleto o nivel 0, en el que un proceso no consigue sus objetivos o no se termina.
Personal Software Process (PSP):
El personal Software Process, conocido por sus siglas como PSP, es una metodología de reciente creación, proveniente del Instituto de Ingeniería del Software. PSP es una alternativa dirigida a los ingenieros de sistemas, que les permite mejorar la forma en la que construyen software. Considerando aspectos como la planeación, calidad, estimación de costos y productividad. PSP es una metodología que vale la pena revisar cuando el ingeniero de software está interesado en aumentar la calidad de los productos de software que desarrolla dentro de un contexto de trabajo individual.
Características:
En PSP todas las tareas y actividades que el ingeniero de software debe realizar durante el proceso de desarrollo de un producto de software, están puntualmente definidas en un conjunto de documentos conocidos como scripts. Los scripts son el punto medular en PSP, por lo que hace mucho énfasis en que deban ser guidados en forma disciplinada, ya que de ello dependerá el éxito de la mejora que se busca. Gran parte de las tareas y actividades definidas en los scripts generará en su realización un conjunto de datos, fundamentalmente de carácter estadístico. La aplicación de PSP en varios procesos de desarrollo, y el análisis de la información estadística generada e cada uno de éstos, permitirán al ingeniero de software identificar, tanto sus fortalezas como sus debilidades, y crecer a través de un proceso de autoaprendizaje y auto mejora.
La calidad de PSP, es u aspecto fuertemente relacionado con la cantidad de defectos que el producto de software contiene. En este nivel se introducen algunos métodos aplicables al proceso de desarrollo de software, dentro de un enfoque de proyectos a gran escala pero sin lidiar con problemas de comunicación y coordinación de los equipos de trabajo.
El aseguramiento de la calidad del software incluye un rango amplio de preocupaciones y actividades que se centran en la administración de la calidad del software. Éstas se resumen como sigue:
Estándares: El IEEE, ISO y otras organizaciones que establecen estándares han producido una amplia variedad de ellos para ingeniería de software y documentos relacionados.
Los estándares los adopta de manera voluntaria una organización de software o los impone el cliente u otros participantes. El trabajo del ACS es asegurar que los estándares que se hayan adoptado se sigan, y que todos los productos del trabajo se apeguen a ellos.
Revisiones y auditorías: Las revisiones técnicas son una actividad del control de calidad que realizan ingenieros de software para otros ingenieros de software. Su objetivo es detectar errores. Las auditorías son un tipo de revisión efectuada por personal de ACS con objeto de garantizar que se sigan los lineamientos de calidad en el trabajo de la ingeniería de software. Por ejemplo, una auditoría del proceso de revisión se efectúa para asegurar que las revisiones se lleven a cabo de manera que tengan la máxima probabilidad de descubrir errores.
Pruebas: Las pruebas del software son una función del control de calidad que tiene un objetivo principal: detectar errores. El trabajo del ACS es garantizar que las pruebas se planeen en forma apropiada y que se realicen con eficiencia, de modo que la probabilidad de que logren su objetivo principal sea máxima.
Colección y análisis de los errores: La única manera de mejorar es medir cómo se está haciendo algo. El ACS reúne y analiza errores y datos acerca de los defectos para entender mejor cómo se cometen los errores y qué actividades de la ingeniería de software
son más apropiadas para eliminarlos.
Administración del cambio: El cambio es uno de los aspectos que más irrumpe en cualquier proyecto de software. Si no se administra en forma adecuada, lleva a la confusión
y ésta casi siempre genera mala calidad. El ACS asegura que se hayan instituido prácticas adecuadas de administración del cambio.
Educación: Toda organización de software quiere mejorar sus prácticas de ingeniería de software. Un contribuyente clave de la mejora es la educación de los ingenieros de software, de sus gerentes y de otros participantes. La organización de ACS lleva el liderazgo en la mejora del proceso de software y es clave para proponer y patrocinar programas educativos.
Administración de los proveedores: Son tres las categorías de software que se adquieren
a proveedores externos: paquetes contenidos en una caja (por ejemplo, Office, de Microsoft);
un shell personalizado, que da una estructura básica, tipo esqueleto, que se adapta de manera única a las necesidades del comprador; y software contratado, que se diseña y construye especialmente a partir de especificaciones provistas por la organización cliente. El trabajo de la organización de ACS es garantizar que se obtenga software de alta calidad a partir de las sugerencias de prácticas específicas de calidad que el proveedor debe seguir (cuando sea posible) y de la incorporación de cláusulas de calidad como parte de cualquier contrato con un proveedor externo.
Administración de la seguridad: Con el aumento de los delitos cibernéticos y de las nuevas regulaciones gubernamentales respecto de la privacidad, toda organización de software debe instituir políticas para proteger los datos en todos los niveles, establecer cortafuegos de protección para las webapps y asegurar que el software no va a ser vulnerado internamente. El ACS garantiza que para lograr la seguridad del software, se utilicen el proceso y la tecnología apropiados.
Seguridad: Debido a que el software casi siempre es un componente crucial de los sistemas
humanos (como aplicaciones automotrices o aeronáuticas), la consecuencia de defectos ocultos puede ser catastrófica. El ACS es responsable de evaluar el efecto de las fallas del software y de dar los pasos que se requieren para disminuir el riesgo.
Administración de riesgos: Aunque el análisis y la mitigación de riesgos es asunto de los ingenieros de software, la organización del ACS garantiza que las actividades de administración de riesgos se efectúen en forma apropiada y que se establezcan planes de contingencia relacionados con los riesgos.
Además de cada una de estas preocupaciones y actividades, el ACS tiene como preocupación dominante asegurar que las actividades de apoyo del software (como mantenimiento, líneas de ayuda, documentación y manuales) se lleven a cabo o se produzcan con calidad.
ESTANDARES Y MÉTRICAS DE CALIDAD.
Los estándares de calidad de software son normas emitidas por organismos específicos, que sirven para sentar un marco con el que comparar si un proceso de desarrollo es o no de calidad. Las normas de calidad del software más conocidas han sido desarrolladas por ISO, y son la serie ISO-9000.
1. Estándares de producto. Se aplican sobre el producto software que se comienza a desarrollar. Incluyen estándares de documentación, como cabecera de comentarios estándar para definición de clases, y estándares de codificación.
2. Estándares de proceso. Definen los procesos que deben seguirse durante el desarrollo del software. Pueden incluir definiciones de procesos de especificación, diseño y validación, así como una descripción de los documentos que deben escribirse en el curso de estos procesos.
Existe una relación muy cercana entre los estándares de producto y los estándares de proceso. Los estándares de producto se aplican a las salidas del proceso software y. en muchos casos, los estándares de proceso incluyen actividades de proceso específicas que garantizan que se sigan los estándares de producto.
Los estándares de software son importantes por varias razones:
1. Están basadas en el conocimiento de la mejor o más apropiada práctica de la empresa, evita la repetición de errores anteriores.
2. Proveen un marco de trabajo alrededor del cual se implementa el proceso de garantía de la calidad. El control de la calidad sencillamente asegura que los estándares se siguen adecuadamente.
3. Ayudan a la continuidad cuando una persona continúa el trabajo que llevaba a cabo otra. Se reduce el esfuerzo de aprendizaje cuando se comienza un nuevo trabajo.
Utilizando estándares como punto de partida, el equipo de garantía de la calidad debe crear un «manual» de estándares. Éste define los estándares que son apropiados para la organización.
1. Estándares de producto. Se aplican sobre el producto software que se comienza a desarrollar. Incluyen estándares de documentación, como cabecera de comentarios estándar para definición de clases, y estándares de codificación.
2. Estándares de proceso. Definen los procesos que deben seguirse durante el desarrollo del software. Pueden incluir definiciones de procesos de especificación, diseño y validación, así como una descripción de los documentos que deben escribirse en el curso de estos procesos.
Existe una relación muy cercana entre los estándares de producto y los estándares de proceso. Los estándares de producto se aplican a las salidas del proceso software y. en muchos casos, los estándares de proceso incluyen actividades de proceso específicas que garantizan que se sigan los estándares de producto.
Los estándares de software son importantes por varias razones:
1. Están basadas en el conocimiento de la mejor o más apropiada práctica de la empresa, evita la repetición de errores anteriores.
2. Proveen un marco de trabajo alrededor del cual se implementa el proceso de garantía de la calidad. El control de la calidad sencillamente asegura que los estándares se siguen adecuadamente.
3. Ayudan a la continuidad cuando una persona continúa el trabajo que llevaba a cabo otra. Se reduce el esfuerzo de aprendizaje cuando se comienza un nuevo trabajo.
Utilizando estándares como punto de partida, el equipo de garantía de la calidad debe crear un «manual» de estándares. Éste define los estándares que son apropiados para la organización.
METRICAS:
Las métricas del producto son una medida cuantitativa que permite a la gente del software tener una visión profunda de la eficacia del proceso del software y de los proyectos que dirigen utilizando el proceso como un marco de trabajo;son analizadas y evaluadas por los administradores del software.
-VENTAJAS DEL USO DE MÉTRICAS:
- Determina la calidad del producto.
- Evalúa la productividad de los desarrolladores.
- Se tiene conocimiento cuantitativo de las características del proceso y del producto.
- Se tiene un soporte para la estimación y la planificación.
- Se evalúan los beneficios (en cuanto a calidad y productividad) derivados del uso de nuevos métodos y herramientas de ingeniería del software.Establece una línea base para la estimación
CARACTERÍSTICAS DE LAS MÉTRICAS:
-Exactas Precisas: No se debe perder información en los redondeos ya que la información se desvirtúa.
-Consistentes: Una medición de un atributo debe dar el mismo valor independientemente de la medición.
MODELOS DE MADUREZ
Durante los 90, SEI desarrolló modelos para la mejora y medición de la madurez (CMM o Capability Maturity Model) específicos para varias áreas:
• CMM-SW: CMM for software
• P-CMM: People CMM.
• SA-CMM: Software Acquisition CMM.
• SSE-CMM: Security Systems Engineering CMM.
• T-CMM: Trusted CMM
• SE-CMM: Systems Engineering CMM.
• IPD-CMM: Integrated Product Development CMM.
Luego del uso y aplicación individual de éstos modelos de madurez, SEI desarrolló CMMI para facilitar y simplificar la adopción de forma simultánea de CMMSW (CMM for Software), SE-CMM(Systems Engineering Capability Maturity Model) e IPDCMM(
Integrated Product Development) y de ahí la palabra Integración en la sigla. Antes de CMMI el modelo más común era CMM-SW y se puede ver CMMI como la evolución de éste último.
Figura: Niveles de madurez del Modelo CMMI
Éste modelo presenta una estructura de cinco niveles de madurez, en los cuales una organización puede determinar su madurez en la producción de software en función de la consecución de los objetivos establecidos en cada nivel.
Según el nivel de madurez en que se encuentre la empresa, las medidas se enfocarán más al grupo de objetivos del nivel correspondiente, para que mejore la capacidad de producir software y pueda avanzar hacia el siguiente nivel.
Los niveles de madurez de una organización en CMMI son:
1.Inicial.
2. Gestionado.
3. Definido.
4. Gestionado cuantitativamente.
5. Optimizando o en Optimización Continua.
Inicial o Nivel 1 CMMI: En los procesos de una empresa en éste nivel, la transición desde las entradas hasta las salidas está mal definida y descontrolada, provocando que proyectos similares puedan tener una gran variación en cuanto a su productividad y en su calidad debido a la ausencia de una estructura y control adecuados. Las empresas en este nivel deben comenzar por definir y recoger datos, estableciendo una serie de medidas de líneas base. El objetivo principal es proporcionar un punto de partida para medir, a través de comparación, las mejoras según se incremente la madurez
Gestionado o Nivel 2 CMMI: En este nivel la característica de los procesos es ser intuitivos,
coexistiendo unos costos y calidad altamente variables, junto con un razonable control de la planificación y con unos métodos o procedimientos informales efectuados en el mismo instante. De esta forma, se identifican las entradas y las salidas del proceso, las restricciones, como presupuesto o calendario y los recursos utilizados para obtener el producto final.
En la definición de CMM, éste nivel de madurez se denomina repetible. El proceso es repetible en el sentido de que las mismas entradas producen las mismas salidas, pero todavía no es posible observar cómo se generan las salidas.
Definido o Nivel 3 CMMI: Éste pasa a ser un nivel cualitativo, donde se comienza a gestionar correctamente tanto los costos como la planificación dentro de unos límites razonables. Ahora sí se conoce la forma de construcción del sistema, ya que se conocen las actividades intermedias y cuáles son las entradas y salidas para las mismas. Por tanto, es posible examinar y medir estas actividades, dado que los productos intermedios están bien definidos.
Esta definición afecta tanto a los procesos de administración como a los de ingeniería, que están documentados de una forma estándar dentro del proceso de software de la organización. De esta forma, todos los proyectos utilizan en el desarrollo y mantenimiento del
software una versión del proceso documentada.
Gestionado cuantitativamente o Nivel 4 CMMI: A diferencia del nivel anterior, este cuarto nivel pasa a ser un nivel cuantitativo. Ahora se tienen medidas detalladas del proceso del software y de la calidad del producto,habilitando la presencia de un cierto control estadístico
sobre la calidad del producto. Una vez definido el proceso, se le añade la gestión del mismo.
Optimizado o Nivel 5 CMMI: En este último nivel de optimización continua, las bases cuantitativas se utilizan para una inversión continua de capital en el proceso de automatización y mejora de manera que la organización alcanza el nivel superior de la madurez de procesos.
Las medidas en este nivel, se utilizan para mejorar el proceso, quitando o añadiendo actividades e incluso cambiando su estructura en función de las medidas obtenidas. Resumiendo se trata de aportar nuevos aspectos, ideas y tecnologías que permitan mejorar el
proceso del software.
En el objetivo de determinar la madurez de una organización en los niveles mencionados, se considera la calificación de la capacidad de los procesos en niveles con nombres y características muy similares al nivel de madurez de la organización (Incompleto, Ejecutado, Gestionado, Definido, Gestionado Cuantitativamente y Optimizado), adicionando un nivel de capacidad incompleto o nivel 0, en el que un proceso no consigue sus objetivos o no se termina.
Figura. Niveles de capacidad CMMI
Personal Software Process (PSP):
El personal Software Process, conocido por sus siglas como PSP, es una metodología de reciente creación, proveniente del Instituto de Ingeniería del Software. PSP es una alternativa dirigida a los ingenieros de sistemas, que les permite mejorar la forma en la que construyen software. Considerando aspectos como la planeación, calidad, estimación de costos y productividad. PSP es una metodología que vale la pena revisar cuando el ingeniero de software está interesado en aumentar la calidad de los productos de software que desarrolla dentro de un contexto de trabajo individual.
Características:
En PSP todas las tareas y actividades que el ingeniero de software debe realizar durante el proceso de desarrollo de un producto de software, están puntualmente definidas en un conjunto de documentos conocidos como scripts. Los scripts son el punto medular en PSP, por lo que hace mucho énfasis en que deban ser guidados en forma disciplinada, ya que de ello dependerá el éxito de la mejora que se busca. Gran parte de las tareas y actividades definidas en los scripts generará en su realización un conjunto de datos, fundamentalmente de carácter estadístico. La aplicación de PSP en varios procesos de desarrollo, y el análisis de la información estadística generada e cada uno de éstos, permitirán al ingeniero de software identificar, tanto sus fortalezas como sus debilidades, y crecer a través de un proceso de autoaprendizaje y auto mejora.
La calidad de PSP, es u aspecto fuertemente relacionado con la cantidad de defectos que el producto de software contiene. En este nivel se introducen algunos métodos aplicables al proceso de desarrollo de software, dentro de un enfoque de proyectos a gran escala pero sin lidiar con problemas de comunicación y coordinación de los equipos de trabajo.
Ventajas y desventajas:
PSP es una alternativa, de las muchas que han surgido recientemente, para
mejorar el proceso de desarrollo de software. Más que clasificar un conjunto de
sentencias como ventajas y desventajas, a continuación se citan algunas:
PSP es una metodología basada en estimación. La estimación permite saber
cuándo y cómo se desarrollan las tareas de un proceso, por lo que podría citarse
como un aspecto importante de esta metodología el estar basada en métricas y
estimaciones.
La información de las métricas y estimaciones se utiliza para evaluar y mejorar
procesos frutos. PSP parte de la premisa que, si el ingeniero de software conoce
sus fortalezas y debilidades, puede establecer las acciones necesarias para
erradicar o explotar los aspectos identificados en la forma en que desarrolla
software.
Team Software Process (TSP):
En combinación con el Personal Software Process (PSP), el llamado Team
Software Process (TSP) proporciona un marco de trabajo de procesos definidos
que está diseñado para ayudarle a equipos de gerentes e ingenieros a organizar y
producir proyectos de software de gran escala, que tengan tamaños mayores a
varios miles de líneas de código. El objetivo del TSP es mejorar los niveles de
calidad y productividad de un proyecto de desarrollo de software de un equipo, con
el fin de ayudarlos a alcanzar los acuerdos de costos y tiempos en dicho
desarrollo.
La versión inicial del TSP fue desarrollada por Watts Humphrey en 1996, y el
primer Reporte Técnico para TSP fue publicado en el año 2000, patrocinado por
el Departamento de Defensa de los Estados Unidos. El libro de Watts Humphrey
llamado "Introduction to the Team Software Process" (Addison Wesley
Professional, Massachusetts, 1999), presenta el TSP en detalle y se enfoca en el
proceso de la construcción de un equipo productor de software, estableciendo
objetivos del equipo, distribuyendo los roles, y otras actividades de trabajo en
equipo.
Funcionamiento:
Antes que los ingenieros de software puedan participar en el TSP, se requiere que
ya hayan aprendido sobre el Personal Software Process (Personal Software
Process), de manera tal que el TSP pueda funcionar de manera adecuada. El TSP
comienza con un proceso de cuatro días llamado despegue. El despegue está
diseñado para comenzar el proceso de construcción de los equipos y durante éste
tiempo, los equipos y sus administradores establecen metas, definen roles,
evalúan riesgos y producen un plan de equipo. El despegue generalmente se hace
con un coach específicamente entrenado, o con un líder que ya ha gerenciado
varios proyectos que han usado TSP para su desarrollo.
El TSP es un proceso diseñado para equipos de software auto-dirigidos y de alto
desempeño, ayudándolos a planear su trabajo, negociar compromisos con la
gerencia, dar seguimiento cabal a sus compromisos y producir productos de
calidad mientras mejoran su rendimiento. El marco de trabajo de TSP incluye
roles, plantillas, procesos, guías, especificaciones y listas de chequeo. La Figura muestra el marco de trabajo con algunos ejemplos de los elementos de proceso.
Características TSP:
- Usa equipos auto-dirigidos con base en el estilo de administración de Peter Drucker (administración del conocimiento) junto con un coach que ayuda a desarrollar las habilidades de trabajo en equipo en los individuos.
- Tiene procesos operacionales flexibles que permiten a los equipos adaptar los procesos, contando además con un marco de trabajo de métricas que soporta a su proceso e incluye técnicas para la administración de la calidad usando revisiones personales, inspecciones e índices de desempeño de la calidad.
- Usa planes detallados con actividades no mayores a 10 hrs en periodos de 3-6 meses y establece juntas de cierre (postmortems) para finales de ciclo o de proyecto.
- Utiliza lanzamientos de proyectos de 3.5 días para planear las actividades y para integrar a los miembros del equipo.
- Cada miembro tienen asignado roles, metas y riesgos del proyecto.
- Los calendarios del equipo son desglosados en calendarios personales que son ajustados con base en datos personales.
Figura. Caracteristicas de PSP y TSP
MOPROSOFT
Modelo de Procesos para la Industria del Software
Modelo para la mejora y evaluación de los procesos de desarrollo y mantenimiento
de sistemas y productos de software. Desarrollado por la Asociación Mexicana
para la Calidad en Ingeniería de Software a través de la Facultad de Ciencias de la
Universidad Nacional Autónoma de México (UNAM) y a solicitud de la Secretaría
de Economía para obtener una norma mexicana que resulte apropiada a las
características de tamaño de la gran mayoría de empresas mexicanas de
desarrollo y mantenimiento de software. Moprosoft es el nombre del modelo en la
comunidad universitaria y profesional, y la norma técnica a la que da contenido es
la NMX-059/01-NYCE-2005 que fue declarada Norma Mexicana el 15 de agosto
de 2005 con la publicación de su declaratoria en el Diario oficial de la Federación.
Moprosoft considera que los modelos de evaluación y mejora CMMI eI SO/IEC
15504 no resultan apropiados para empresas pequeñas y medianas de desarrollo
y mantenimiento de software. Sobre las áreas de procesos de los niveles 2 y 3 del
modelo SW-CMM e inspirándose en el marco de ISO/IE 15504 se ha desarrollado
este modelo.
Comentarios
Publicar un comentario