¿Cuáles son las cinco características más importantes de un buen software?

No estoy seguro de si un buen software podría juzgarse en función de la licencia, las tecnologías, el servicio al cliente y el costo. Estos podrían ser indicadores de una compañía que construyó ese software, pero el software no puede considerarse “bueno” en esos parámetros.

Dicho esto, en mi humilde opinión, un “buen software” tiene las siguientes características:

1. El código es diseño y el diseño es código . Entonces, dice el dicho. Un buen código respeta y resalta automáticamente todas las decisiones con respecto a su decisión. No verá los síntomas de un concepto de “ventana rota” .

2. Separación de preocupaciones : un buen software tiene la cantidad correcta de separación de preocupaciones y modularidad. Por lo tanto, puede encontrar el código encapsulado en los niveles / módulos / capas lógicos correctos. Esto lo hace extremadamente mantenible.

3. Sigue las convenciones correctas : un buen software sigue religiosamente todas las convenciones correctas. No encontrará muchas excepciones a las convenciones establecidas para construir el software

4. Unit Test Suite : un buen software es el que se puede probar. Uno encontraría una buena cantidad de casos de pruebas unitarias para que el equipo pueda desarrollar el software durante un período de tiempo. Casi tendría una cobertura de código del 100%

5. Buen manejo y registro de excepciones : un buen software no le permitiría arder en llamas en escenarios excepcionales. Los manejaría con gracia y lo registraría para que puedan resolverse fácilmente más tarde.

6. Rendimiento : funcionaría razonablemente bien en escenarios regulares y estresantes. No se encontrará esperando durante segundos antes de que realmente procese una solicitud. Esto es más cierto para el software orientado a empresas y consumidores. Por supuesto, podría llevar tiempo si se trata de procesar grandes datos o hacer algún tipo de procesamiento de imágenes, etc.

7. Experiencia del usuario : su interfaz de usuario tendría sentido inmediatamente para sus usuarios. Sería simplista, elegante y algo que sea fácil de usar.

Podría destacar algunos más, pero estos son los que se destacan de inmediato.

Murukesh aborda algo relacionado con la definición de “bueno”. Como gerente de producto, USTED debe definir qué significan esos términos en un contexto dado. No es tarea fácil si considera que la definición puede depender de algunos o de todos los siguientes factores (y ciertamente de otros):

  • ¿Dónde está el producto en su ciclo de vida?
  • ¿Cómo es el entorno competitivo?
  • ¿Cuánto tiempo será relevante la implementación actual del producto?
  • ¿Qué esperan las personas que compran el software?
  • ¿Qué esperan las personas que usan el software?
  • ¿Qué ha esperado históricamente el mercado de este tipo de software?
  • ¿Qué está tratando de lograr la empresa que desarrolla el software?

Me gusta utilizar el “Modelo de Motivación Comercial” de OMG para capturar estas consideraciones como objetivos medibles que se pueden cumplir con la estrategia correcta. Recomiendo echarle un vistazo y definir claramente (por escrito) qué “bueno” es para su software.

Usualmente respondo a tales preguntas con un contador: “Definir ‘bueno'”. ¿Quién se desarrolló? Irrelevante. Porsche puede, en teoría, fabricar autos de mierda, al igual que Apple y MS pueden hacer software de mierda. Que licencia Irrelevante, ya que generalmente puede negociar sobre eso (lo mismo para el costo y los factores de atención al cliente).

  • Una regla de diseño proporciona una característica: el Principio de menor sorpresa (Aplicación de la Regla de Menos Sorpresa). ¿Hace lo que razonablemente puede esperar que haga en respuesta a lo que hizo?
  • Bloqueo: ¿lo vincula con algo específico (servidores de activación, hardware específico / software de terceros, etc.) que tiene una vida útil de soporte corta? La obsolescencia forzada hace que cualquier cosa, no importa cuán bien hecha y fácil de usar sea terriblemente inútil.
  • Facilidad de mantenimiento y configurabilidad: Uno para el desarrollador: ¿Pueden corregir errores y agregar funcionalidades sin tener que reescribir módulos completos (o, la raíz no lo permita, el paquete es monolítico) y cobrar un brazo y una pierna por ello? Uno para el usuario: ¿Pueden cambiar el comportamiento del programa dentro de los límites de diseño sin tener que sacrificar su primer hijo a Codethulhu (La Llamada de Codethulhu)?
  • Adherencia a los estándares: si el software trata con algo que tiene un estándar aceptado en toda la comunidad (ISO / ECMA / IEEE / lo que sea), ¿puede (‘puede’, no ‘hace’) comportarse de manera compatible con los estándares?

El general Chuck Yeager (la primera persona en volar más rápido que el sonido) elogió el sistema de motor de un avión con las palabras

‘Simple, pocas partes, fácil de mantener, muy fuerte’

Un programa comparte esos atributos.

Referencia: Perlas de programación por Jon Bentley

  1. Usuarios finales amigables
  2. Soporte después del servicio
  3. Buena validación
  4. Política de actualizaciones
  5. Buen diseño frontal