Soy parte del Grupo de Aprobaciones de Software para una empresa multinacional y me haría eco de todo lo que Adam dice anteriormente.
También destacaría los siguientes puntos: en primer lugar, siempre pagaré todos sus "impuestos al desarrollo". Esto significa asegurarse de que su aplicación funcione correctamente en una gran variedad de entornos que quizás nunca use, pero que muy probablemente serán un factor decisivo para las grandes empresas, estas son cosas como asegurarse de que su aplicación funcione bien con perfiles de usuario itinerantes y carpetas de usuario redirigidas (siempre use las API de Windows para encontrar carpetas de usuario y perfil, nunca suponga que están en ubicaciones estándar, o incluso en la unidad local), asegurándose de que funcione bien en servidores de Escritorio remoto (donde podría haber un 100 copias de su aplicación ejecutándose a la vez, algunas con conexiones muy lentas), en computadoras portátiles con conexiones de red lentas o baterías bajas, etc. Como ejemplo, recientemente rechazamos nuevas versiones de más de una pieza de software de una empresa muy grande (comienza con "A" y es famosa por los gráficos) porque sus aplicaciones de repente no "
Incluso para el software gratuito / de código abierto, los usuarios finales a menudo tienen que enviar algún tipo de formulario de solicitud para verificar y aprobar el software.
Por el tono de su comentario, ¿parece que cree que el proceso de aprobación tiene algo que ver con el costo? Desde nuestro punto de vista, el costo por unidad de una aplicación no es algo que consideremos en absoluto en el proceso de aprobación. Las justificaciones financieras para las aplicaciones se habrán resuelto, las aprobaciones de software se realizarán desde el punto de vista técnico y de capacidad de soporte. El software gratuito y de código abierto generalmente tiene más problemas para completar nuestro proceso que una aplicación comercial patentada. A menudo, esto se debe simplemente a la falta de responsabilidad. ¿A quién acudes cuando hay problemas con la aplicación y necesitas soporte, cuál es su SLA? ¿A quién le pregunta cuándo necesita saber si la aplicación funcionará con una nueva versión de OtherApp vX, realmente le están dando una respuesta real en la que la gente realmente está trabajando, o es vago "
Una vez que se ha seguido el proceso y se instala el software, las actualizaciones pueden ser problemáticas: muchas organizaciones tienden a quedarse con versiones anteriores de software (Windows XP, Office 2003, etc.) por temor a problemas desconocidos.
Las actualizaciones de software tienen que pasar por el mismo proceso que las piezas de software totalmente nuevas. La única ventaja que tienen es que ya sabremos las respuestas a algunas de las preguntas, ya que hemos estado apoyando el software (esto puede no ser positivo para el software, los equipos de soporte han vetado las actualizaciones basadas en la experiencia con la compañia).
¿Prefieres MSI o software compatible con xcopy?
Cualquiera de esos métodos de implementación puede ser bueno, siempre que se hayan empaquetado correctamente. De lo contrario, es muy probable que eliminemos su instalador y reempaquetemos el software para implementarlo nosotros mismos.
- Independientemente del instalador que utilice, debe asegurarse de respetar todos sus modos de instalación silenciosa y desatendida. Si su aplicación requiere una instalación manual, que es un factor decisivo instantáneo, simplemente no hay una forma práctica de hacerlo en máquinas en los 5 continentes que obtienen todo el soporte que no sea de hardware de una oficina central.
- Dada la opción, preferiría una instalación MSI bien hecha a una instalación xcopy bien hecha. El problema con la mayoría de las piezas de software compatibles con Xcopy es cuando intentan configurarse y registrarse en la primera ejecución. Muy rara vez he encontrado una aplicación que haga esto correctamente y no cause problemas en un entorno de usuario / escritorio móvil. Los instaladores de MSI (si se apega a la API estándar) no pueden ir demasiado lejos mal.
- Asegúrese de que su instalación silenciosa le permita realizar todos los cambios de configuración que se pueden realizar en una instalación manual. Si está utilizando MSI y se apega a la API, entonces está bien, podemos hacer transformaciones MST y hacer todo esto sin problema. Si está utilizando un instalador de terceros diferente, asegúrese de que permita algo como un archivo de "respuesta" o un archivo INI o similar. Pruebe la instalación silenciosa y asegúrese de que todas las opciones funcionen. He encontrado productos que anuncian alegremente sus opciones de instalación silenciosa, pero nunca han probado si todas las opciones funcionan.
- Preferiblemente, denos opciones adicionales en la instalación silenciosa que nos permitan establecer muchas de las configuraciones que un usuario normalmente cambiaría en el panel de Opciones. Esto podría ser mediante interruptores en setup.exe, podría ser tener un archivo INI documentado para la configuración, documentar los cambios de registro necesarios o todo lo anterior. Sin embargo, está hecho, nos gustaría asegurarnos de que nuestros usuarios puedan comenzar a usar el software sin tener que realizar ninguna configuración ellos mismos, aquí hay ubicaciones predeterminadas para archivos, nombres de servidor predeterminados, configuraciones de proxy (si su aplicación se ejecuta a través de una red), etc.
Si el software requiere marcos (Java, .NET), ¿es eso más o menos probable que sea problemático?
Definitivamente es más problemático. El control de versiones en la mayoría de los marcos y la compatibilidad con versiones anteriores / posteriores es atroz. Con Java en particular, muchas aplicaciones (y sitios web) requieren una versión particular y menor de Java instalada y no funcionarán con nada más. Si necesita colocar tres aplicaciones diferentes en una máquina que necesitan diferentes versiones de Java, y no están contentos con las formas estándar de encubrir una versión de Java como otra, entonces habrá problemas. .Net tiene sus propios problemas con el control de versiones, pero felizmente le permitirá instalar todas las versiones principales del marco al mismo tiempo, lo que evita muchas de ellas.
Si el software admite actualizaciones automáticas, ¿generalmente lo permite?
Nunca. Hay demasiados dolores de cabeza de versiones e interoperabilidad para permitir que una aplicación se actualice sola sin ninguna advertencia. Las actualizaciones de aplicaciones requieren pruebas y planificación. Además, los usuarios con derechos de usuario normales no pueden aplicar las actualizaciones de todos modos. Si utiliza un método de implementación que permite la aplicación de parches (p. Ej., Use MSI con parches MSP), esto puede hacer que los parches de seguridad para aplicaciones sean mucho menos dolorosos, y podemos gestionar la actualización automática nosotros mismos utilizando nuestras herramientas de implementación (WSUS y SMS ) Además, nuestro equipo de seguridad desconfía de cualquier aplicación que "responda a la base", les gusta saber exactamente qué información está enviando y exactamente por qué necesita enviar algo a un servidor desconocido a través de Internet.
¿Cuánto tiempo lleva generalmente?
Algunas aplicaciones simples y actualizaciones de versiones se pueden decidir siempre que se necesiten 6 personas para hacer clic en el botón de votación "Aprobar" en Outlook. Los más complejos o controvertidos pueden esperar a nuestra reunión de grupo cada dos semanas. Se puede hablar de algunas aplicaciones en más de una de estas reuniones a medida que los equipos responden preguntas sobre una aplicación e investigan / prueban.
¿Qué tipo de modelos de licencia prefiere (transferible, por puesto, por CPU, en todo el sitio)?
Depende totalmente de cómo se vaya a utilizar la aplicación y de cuántas personas. Lo más importante es que su licencia está claramente definida. Tenemos que enviar a nuestra gente a cursos (aunque gratuitos) para comprender las licencias de Microsoft. No nos vamos a molestar en hacer eso para un ISV.
Considere nuestras necesidades de instalación silenciosa y automatizada cuando se trata de licencias. Si sus licencias necesitan activación, no queremos tener que llamarlo por correo electrónico cada vez que reinstalemos una aplicación en una PC. Si cada copia de la aplicación necesita una clave de licencia diferente y diferente, entonces no podemos implementarla automáticamente, mientras que si podemos comprar una clave masiva (2, 10, 50, 500, etc., asientos) que se puede guardar en la instalación silenciosa, entonces estamos contentos. Es aún mejor si podemos contactarlo un año después y negociar para expandir nuestra cantidad de licencias sin tener que cambiar la clave que se ingresó en el software.
¿Qué más pueden hacer los ISV para mejorar sus posibilidades de tener su software aprobado?
También veremos cosas que no están estrictamente relacionadas con cómo está su aplicación en este momento. Teniendo en cuenta que si su aplicación se convierte en parte del flujo de trabajo estándar para una de nuestras áreas, podría usarse durante 10 años o más, entonces, ¿cómo es la hoja de ruta de su producto? Si aún no es compatible con la versión más reciente o en desarrollo de Windows, ¿tiene un plan para cuándo? ¿Parece que te apegas a estas hojas de ruta? ¿Parece que tiene algún plan para realizar cambios drásticos en su aplicación, ya sea la forma en que funciona o las tecnologías / marcos que utiliza? ¿Su aplicación se conecta a otras aplicaciones, por ejemplo, MS Office o IE?