¿Cómo definen las personas los requisitos mínimos de hardware para el software?

¿Cómo definen las personas los requisitos mínimos de hardware para el software? Por ejemplo: ¿cómo puede una empresa de desarrollo de software decirle al cliente que necesitará 8 GB de RAM para ejecutar el programa correctamente?

En primer lugar, no todos los requisitos son requisitos estrictos, sino el hardware mínimo admitido. Si alguien tiene menos del mínimo, puede ejecutarse, pero no de manera óptima, o puede no ejecutarse en absoluto. En cualquier caso, no es un sistema compatible y los problemas que tiene son los suyos.

La forma más sencilla de obtener los requisitos de hardware es adivinar. El desarrollador mira su máquina y dice "Sí, se ejecuta en la mía, esos son los requisitos".

En un entorno más riguroso, la compañía de desarrollo tiene un conjunto de sistemas de prueba. Es posible que no sea interno (los desarrolladores de Apple que no son internos utilizan ocasionalmente el Laboratorio de compatibilidad de Apple ). Como parte del proceso de prueba, uno prueba todo el hardware disponible y determina los requisitos mínimos para que se ejecute.

Otro factor en los requisitos de hardware son los requisitos básicos para el sistema operativo. En teoría, Windows 7 requiere un mínimo de 1 GB de RAM para ejecutarse. Por lo tanto, probar contra un sistema de 512 MB con Windows 7 no tiene sentido.

Pruebe el sistema que se ejecuta con 1 GB de RAM. ¿Funciona? No ... actualiza el carnero. Repita la prueba y las actualizaciones hasta que la aplicación funcione de manera compatible y enumere esas como los requisitos mínimos.

Cuando el rendimiento se convierte en parte de la promesa del software, el 'soporte' incluye que, además de ejecutarse, la operación cumple con las expectativas mínimas de rendimiento.

Los requisitos de hardware se dividen en un par de cubos diferentes. A menudo incluirá requisitos de algunos de estos grupos al determinar los requisitos de hardware específicos para cualquier sistema de software que cree.

Restricciones técnicas en la arquitectura

Estos son los tipos de requisitos que el sistema integrado debe cumplir absolutamente y están diseñados específicamente en el sistema desde el principio. Por ejemplo, "se requiere un procesador x86".

Un ejemplo fácil que viene a la mente es Microsoft Office para Mac. Originalmente, las Mac usaban CPU de PC de potencia, mientras que Microsoft Windows estaba estrictamente dirigido a máquinas "compatibles con IBM" (principalmente utilizando procesadores x86). Como Windows y, por lo tanto, Office solo funcionaban en x86, se escribió un conjunto de código completamente nuevo (con diferentes limitaciones técnicas) para admitir Office en Power PC para Mac OS. Una vez que Mac se mudó a los procesadores Intel x86, el viejo Power PC optimizado Office para Mac ya no funcionaba, y las restricciones técnicas cambiaron una vez más para una nueva versión de Office para Mac en Intel. Las aplicaciones optimizadas para 32 contra 64 bits es otro ejemplo fácil.

Requisitos implícitos de hardware

A veces no eliges restringirte activamente, pero otras decisiones que tomas implícitamente te imponen requisitos. Un escenario común es construir sobre cualquier tipo de marco.

Como ejemplo, si está creando una aplicación .Net 4.0, .Net 4.0 tiene requisitos de hardware examinados a través de los laboratorios de hardware de Microsoft. Ahora su aplicación requiere al menos los mismos requisitos de hardware que requiere el marco .Net 4.0.

Requisitos contextuales de hardware

La mayoría de las veces, cuando habla de requisitos de hardware, de lo que realmente habla es de cómo admite escenarios de atributos de calidad específicos. Cosas como rendimiento, confiabilidad, disponibilidad y otras capacidades.

Esto es algo con lo que trato a menudo al hacer recomendaciones de hardware para clientes que crean aplicaciones sobre IBM InfoSphere Data Explorer (básicamente una plataforma de motor de búsqueda Big Data). Los requisitos básicos de Data Explorer son mínimos (puede ejecutarlo en una computadora portátil), pero las recomendaciones de hardware para cualquier aplicación de Big Data específica (léase: requisitos) se reduce a escenarios de atributos de calidad específicos para esa aplicación. ¿Qué tan rápido deben indexarse ​​los datos? ¿Cuántas consultas por segundo se deben procesar? ¿Cuánto tiempo de inactividad es aceptable?

La identificación de escenarios de atributos de calidad específicos dibuja una línea en la arena y me permite hacer una recomendación para los requisitos mínimos de hardware basados ​​en esos escenarios: X número de CPU con Y cantidad de RAM, Z Gigabytes de discos duros, N sistemas redundantes. En nuestro caso, tenemos fórmulas básicas (determinadas mediante pruebas exhaustivas en nuestros laboratorios de hardware) que utilizan supuestos de los escenarios de atributos de calidad para ayudar a determinar un punto de partida para una recomendación de hardware. Esta recomendación se convierte en el requisito para esa aplicación específica de Big Data.

En este ejemplo, para cualquier sistema de producción, una computadora portátil realmente no funcionará aunque técnicamente cumpla con los requisitos "mínimos". El contexto de esa implementación: los escenarios y datos específicos, ya sea que se ejecuten en producción o no, etc., dictan los requisitos de hardware.

Si las suposiciones en los escenarios cambian, también lo harán los requisitos de hardware. Entonces, la frase, "Se requiere Y GB RAM para ejecutar el software correctamente", realmente significa "Se necesita Y GB de RAM para rastrear X millones de documentos en Z horas o una velocidad de documentos ABC / min".

Requisitos mínimos de hardware admitidos

Es decir, se espera que las especificaciones de hardware funcionen correctamente y que su grupo de soporte esté preparado para ayudar a solucionar problemas. En general, este es el conjunto de hardware al que tiene acceso directo, ya sea su máquina de desarrollo o algún tipo de laboratorio de pruebas.

Un ejemplo de esto es prácticamente cualquier aplicación de Android que se haya lanzado. Como desarrollador de Android, prueba su aplicación a través de algunos simuladores de software, probablemente en al menos algunos dispositivos físicos. Pero hay miles de dispositivos diferentes que ejecutan Android, muchos de los cuales con pequeñas ... peculiaridades ... que podrían causar problemas en su aplicación. En la mayoría de los casos, seguirá ofreciendo soporte si un usuario tiene problemas. Y en la mayoría de los casos, los usuarios no se encontrarán con problemas aunque usted no haya probado específicamente esa variación de hardware. Microsoft también tiene este problema con Windows: ¿cuántas combinaciones de tarjeta de video, placa base, CPU y memoria diferentes existen?

Básicamente, identificar el hardware mínimo compatible es como decir "este software funciona en mi máquina, espero que funcione en máquinas similares a la mía, mucha gente ha usado este software en muchas máquinas diferentes sin problemas, su kilometraje puede variar, y si tiene un problema, haré todo lo posible para ayudarlo / solucionarlo, pero no puedo garantizarlo ".

Para algunas aplicaciones, los requisitos pueden ser requisitos estrictos, como cuando el desarrollador ha analizado o perfilado su aplicación y sabe exactamente cuántos megaflops, MIPS, polígonos por segundo, tamaños de conjuntos de trabajo de matriz, etc. .

Para los desarrolladores pequeños, el costo puede ser el problema. Solo tienen un sistema disponible, por lo que declaran que las especificaciones del sistema son mínimas, ya que no han podido probar la aplicación en nada más (más lento, más pequeño, etc.) y tienen poca idea de cómo funcionaría la aplicación con menos recursos