Tiempo de calidad

La salsa secreta del software:

Las “-ilidades”

Si la belleza está en el ojo del espectador, entonces la calidad también debe serlo.
Vivimos en un mundo donde la belleza para uno es un completo desvío a otro. La calidad
del software es
no es diferente. Tenemos el desarrollador perspectiva, la perspectiva de los usuarios
finales, la perspectiva de los probadores, y así sucesivamente. Entonces, para ejemplo,
si el software cumple con los requisitos, es ese software de calidad? Muchos dirían que
sí, pero
entonces, ¿qué pasa si el software no es adecuado? para algún propósito razonable? O
es software de calidad simplemente software que fue desarrollado de acuerdo a
estándares particulares y reglamentos? Como puede ver, cumplir con los requisitos
puede ser diferente de
ser apto para un propósito, que puede también ser diferente de cumplir con reglas y
regulaciones sobre cómo desarrollar e implementar el software. Sin embargo, podemos
pensar en las tres perspectivas como formas de determinar cómo juzgar y evaluar la
calidad del software
Para todo hay una temporada
Estas tres perspectivas se relacionan directamente con la Sección de enfoque Atributos
de software persistentes en esta cuestión y, en consecuencia, al concepto de “-ilidades”
de software. Las -ilidades (o atributos del software) son una colección de
comportamientos estrechamente relacionados que por sí mismos tienen poca o ninguna
valor para los usuarios finales, pero eso puede aumentar en gran medida el valor de una
aplicación de software o sistema cuando se añade. Para usar una analogía, una -ilidad
en un aplicación o sistema es como un condimento en un plato principal: no es valioso
como artículo independiente, pero capaz de mejorar significativamente el sabor cuando
se añade correctamente. Ejemplos de estos Software para mejorar el sabor: las
funcionalidades incluyen mantenibilidad, confiabilidad, usabilidad, eficiencia,
adaptabilidad, disponibilidad, seguridad, portabilidad, escalabilidad, seguridad,
tolerancia a fallas, capacidad de prueba, usabilidad, reusabilidad y sustentabilidad.
Entonces, si miramos el tema del software cumplir con sus requisitos, y si esos requisitos
son únicamente funcionales y no prescriben -ilities, entonces claramente el software
puede cumplir con los requisitos, pero podría ser incapaz de cumplir con cualquier
propósito razonable. Además, las -ilidades es poco probable que esté asociado de alguna
manera con cómo se desarrolla el software, porque los estándares de desarrollo rara
vez profundizan suficiente para proporcionar la guía necesaria para alcanzar grados
particulares de cualquier -ilidad.

Medida por medida

Tenga en cuenta que el grado es importante. Por ejemplo, un poco de sal en un bistec
por lo general sabe muy bien. Verter una libra de sal en un filete pequeño sería ser
desastroso. Sin embargo, a diferencia de la sal, el software -ilidades sufren la dificultad
de la medición directa. Por ejemplo, ¿qué significa desarrollar software que tenga 20
unidades de escalabilidad? o 30 unidades de mantenibilidad? La respuesta: nada. Pero
debido a que el software aún no es físico
funcionalmente conductuales, sufrimos el desafío de intentar medir ciertas atributos no
medibles. No obstante, eso es todo lo que podemos hacer actualmente para defender
la estabilidad, funcionalidad, y la sostenibilidad del software durante hora. Estas
medidas no necesariamente tienen que ser precisas. Ellos pueden ser grano grueso en
lugar de grano fino.
Esto nos permite calificar el software a través de un modelo similar a la que utiliza el
Departamento de Seguridad Nacional de EE.UU. cuando cambiar la amenaza del
terrorismo público nivel.
No todas las medidas de software son cuantificables numéricamente. La medición de la
calidad del software puede ser subjetiva y no absoluto Es decir, puede ser una medida
relativa y valiosa como tendencia. herramienta de análisis Además, puede (y
posiblemente debería) ser un sistema codificado por colores como el Departamento de
Homeland Sistema de seguridad. La razón es que medición de la confiabilidad del
software, que puede ser de grano muy fino si realizar suficientes pruebas, también
puede ser altamente engañoso. Si trata de cuantificar lejos en los lugares decimales,
usted necesitan pruebas extremas. Costos extremos de evidencia (a través de
cantidades masivas de pruebas u otras formas de argumentación y evidencia), y esos
costos podría o no ser realista.
Creando un personalizado libro de cocina
Entonces, probablemente no podamos anticipar poder medir directamente ciertos
atributos de calidad. alguna medida tendrá que ser indirecta a través de técnicas de
puntuación no numéricas. ¿Pero cómo? Esencialmente, deberíamos emplear dos
procesos y puede combinarlos:
■ Cree el software para cumplir con un conjunto de requisitos
■ Defina una “salsa secreta” desde el principio como una parte de la definición de
requisitos
e incorpore ese sabor en el software a través de cualquier diseño y arquitectura o
modelado que desee.
Si quieres saber cuál creo que es más difícil, votaría por el segundo. Pero al final,
necesitas ambos. Recuerde que nuestro objetivo aquí es proporcionar pruebas sólidas
de que el software es apto para su propósito. El objetivo entonces es sacar la receta que
el usuario final quiere y cocinar para eso. También, darse cuenta que las recetas se
pueden personalizar al gusto y ese software también se puede personalizar con respecto
a las capacidades para grupos de usuarios específicos o usuarios individuales. Entonces,
estoy argumentando que la calidad es verdaderamente un condimento para un plato
principal: es el sabor que le da diferenciación al producto y placer a los usuarios finales.
Pero para cada usuario, diferentes sabores son o bien aceptable o inaceptable. Ahí
radica el beneficio de considerar y definir las capacidades del software en el primeras
etapas de desarrollo. Ellos esperemos que influya en el proyecto de manera positiva
camino hacia los gustos de los usuarios y consumidores finales. Los directores de
proyecto y los desarrolladores tendrán un nuevo conjunto de tareas tempranas del ciclo
de vida a realizar: obtener las expectativas para la "salsa". Creo que "adecuado para el
propósito" es el determinante clave para evaluar el usuario final aceptación. Reconozco
que el cumplimiento con los estándares es importante, pero esto Este último enfoque
es también un candidato para mal uso y mala interpretación.

La investigación y la orientación serán necesarias en los próximos años para seguir la

consideración de las características clave antes del desarrollo de software. Sin que tal,
la integridad y la confianza deben ser cuestionado Sin una definición y consideración
serias de las -ilidades durante la primera iniciación del proyecto fases, cualquier
esperanza de que el software
producto finalmente satisfará su fin Las expectativas de los usuarios son pequeñas.
Software
la calidad no es más que una receta. A algunos les gusta caliente, dulce, salado, ácido o
grasiento. El usuario final es el restaurante. patrón. Sazone al gusto.