¿Cómo evaluamos la calidad de un diseño de software?

Creo que todos respondieron su pregunta en función del “valor” del software en lugar de la “calidad” del diseño del software, lo cual es razonable porque la calidad tiene que pasar a un segundo plano para valorar muy a menudo dados los requisitos y recursos disponibles. Los recursos son dinero y tiempo. Intentaré responder la pregunta sin tener en cuenta los recursos. Sé que no es realista que se considere la “calidad” sobre los recursos, pero por mi interpretación de la pregunta, voy a responder de esta manera.

Diseño de software de calidad:

Utiliza software de código abierto.

Básicamente, su código no reescribe la rueda. Si necesita algo de seguridad, vea si ya existe una solución antes de escribirla usted mismo. Las opciones sobre las que usa generalmente son un buen factor en la calidad de su diseño.

Cumple con una arquitectura de software específica.

Elija una arquitectura de software que funcione para el software. La mayoría de los casos, MVC o marcos de múltiples niveles funcionan bien.

Sigue los principios estándar de la base de datos.

Utilice y refuerce las restricciones de clave externa en cualquier lugar aplicable y elimine la lógica empresarial de la base de datos a menos que sea absolutamente necesario.

Además del diseño, también espero que el diseño se implemente estrictamente o, de lo contrario, el diseño terminaría siendo inútil.

Escribí una respuesta a una pregunta relacionada aquí:

La respuesta de Lewis Nakao a ¿Cómo escribo un código hermoso?

La calidad del diseño está directamente determinada por qué tan bien satisface los requisitos de su negocio.

Por lo tanto, el valor de un diseño MS-DOS de software de 30 años que me ahorra 100 horas hombre por semana es muy superior a una oferta SaaS basada en la nube implementada en .net mobile que me ahorra 10 horas hombre por semana.

Para que pueda ver, no descubrirá la calidad a menos que primero comprenda los costos y el esfuerzo asociados con los problemas que el software está diseñado para abordar.

Software para ayudar al personal de mi sala telefónica a ingresar pedidos de ventas más rápido, ¡eso es genial! Software para permitir que el cliente ingrese por sí mismo para que no necesite una sala de teléfono; evaluaría esa calidad un poco más.

Vamos a enumerarlos más o menos en orden de importancia (para mí):

1. ¿Satisface los requisitos de su negocio?
2. ¿Satisface los requisitos de su negocio con un mínimo de alboroto?

1. es decir, ¿es lo suficientemente rápido, lo suficientemente ligero y requiere poco mantenimiento continuo?

1. ¿Tiene que perder horas o días capacitando a los empleados en el sistema? ¿Tuviste que pasar tanto tiempo entrenando? ¿O fue intuitivo desde el principio?

1. ¿Agregó ese pequeño detalle adicional para facilitarle la vida ahora o en el futuro?

1. Basado en 1-4, ¿existe una solución alternativa claramente superior?

Es por eso que necesita requisitos documentados. Sus requisitos deben declarar sus indicadores de éxito en términos inequívocos, lo que hace que sea muy fácil determinar la calidad: ¿qué tan bien satisface sus requisitos, que conducen directamente a lo que ya definió como éxito?

Si sus requisitos no se alimentan directamente en sus indicadores de éxito, falló antes de comenzar. Si sus requisitos no son inequívocos, falló antes de comenzar. Si los plazos y los presupuestos no son claros en función de sus requisitos, falló antes de comenzar.

Es raro que el funcionamiento del software sea el problema a menudo descrito como “mala calidad”. Muy a menudo, es la falta de comprensión de los requisitos reales o la falta de prioridad a la experiencia del usuario lo que lleva a que el software se describa de esa manera. Si no se prioriza la experiencia del usuario, el software se vuelve lento, engorroso o confuso, lo que a menudo se describe como “mala calidad” a pesar de cumplir completamente con los requisitos descritos.