Muchas organizaciones más grandes tienen departamentos de TI que bloquean los escritorios a una configuración estándar, o SOE. Los usuarios finales generalmente no tienen derechos para instalar su propio software, e incluso si lo hicieran, las organizaciones tienden a permitir que solo se instale software "aprobado".
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. 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.
¿Qué pueden hacer los desarrolladores de software para acelerar el proceso de aprobación?
Si está involucrado en dicho proceso de aprobación:
- ¿Qué buscas al evaluar el software? Por ejemplo:
- ¿Prefieres MSI o software compatible con xcopy?
- Si el software requiere marcos (Java, .NET), ¿es eso más o menos probable que sea problemático?
- Si el software admite actualizaciones automáticas, ¿generalmente lo permite?
- ¿Cuánto tiempo lleva generalmente?
- ¿Qué tipo de modelos de licencia prefiere (transferible, por puesto, por CPU, en todo el sitio)?
- ¿Qué más pueden hacer los ISV para mejorar sus posibilidades de tener su software aprobado?
fuente
Respuestas:
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 "
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 "
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).
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.
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.
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.
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.
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.
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?
fuente
Somos una organización bastante pequeña, pero pasamos a escritorios estándar y software aprobado para reducir nuestra molestia administrativa.
Cualquier cosa que pueda realizar una instalación "silenciosa". Los MSI generalmente funcionan bien aquí, pero también hay mucho software de instalación. Si tenemos que configurarlo de alguna manera, entonces es bueno poder escribir eso también, ya sea copiando archivos o fusionando registros.
Puede ser problemático debido a los diferentes requisitos de versión. Si necesita .NET 3.5 y estamos usando 3.0, entonces tenemos que administrar esa actualización y asegurarnos de que no rompa nada más.
No. Demasiado riesgo de que la nueva versión cause problemas. Además, los usuarios no tienen derechos de administrador, por lo que las actualizaciones generalmente no funcionan de todos modos.
Si hay una necesidad comercial apremiante, lo más rápido posible, tan solo unas pocas horas. Para un software más incómodo, tal vez una semana o más.
¡Cuanto más barato, mejor! Podemos ocuparnos de las opciones más razonables, pero se vuelve difícil si el software realiza algún tipo de verificación automática o requiere activación. Estos no tienden a lidiar bien con las PC muertas, las activaciones fallidas, etc., y generalmente nos hacen un trabajo extra.
Dos cosas me vienen a la mente:
Y, por supuesto, debe hacer que valga la pena usar el software en primer lugar: si el usuario realmente lo ama, ¡van a gritar más fuerte para que lo aprueben!
fuente
Lo primero que generalmente miro es: ¿tienes lo básico? Si no puedes hacer eso, entonces seré muy reacio a seguir adelante. Así que quiero ver un instalador MSI con una herramienta de personalización estándar que me permita construir una transformación. No quiero ver ningún requisito para los derechos de administrador para instalar o usar el software. No quiero ver ningún requisito para reconfigurar las PC. No quiero ver datos por usuario escritos en ubicaciones por computadora. No quiero ver visitas manuales a los escritorios, quiero ver la administración y configuración remotas adecuadas disponibles a través de GPO. En otras palabras, ¿comprende los requisitos de una implementación corporativa administrada?
Si el software requiere algún tipo de actualizaciones, es mejor que sea algo similar a un archivo de definición AV o similar, es mejor mantener su propio servidor central de actualizaciones si lo desea, y es mejor que sea completamente y obviamente configurable centralmente. No me importa el software que viene con las actualizaciones del programa siempre que pueda desactivarlas.
No quiero ver ninguna comunicación de Internet desde el software, aparte de la que es absolutamente necesaria para que funcione. Y es mejor que todo esté documentado. Al permitir que su software entre en mi red, confío en usted para que no lo arruine ni sea malo, por lo que espero que no traicione esa confianza. Si lo haces, estaré muy decepcionado. Recuerde: usted es un invitado en mi casa, así que trátelo con respeto.
No Java . Java, en mi experiencia, ha causado un caos total cuando se trata de la implementación, cada vez, principalmente al equivocarse todo lo anterior. Estoy feliz de aceptar .NET, ya que al menos parece estar diseñado de manera más sensata desde una perspectiva de administración central (además, una aplicación .NET tiene una mejor oportunidad de obtener lo básico debido a las restricciones en el marco).
Para obtener la licencia, lo primero que buscaré es una versión de prueba gratuita que pueda descargar sin tener que registrarme. Si no veo esto, probablemente sospecharé que tienes algo que ocultar. Estoy bien con tiempo limitado, pero no me gusta la funcionalidad reducida; después de todo, esta es la etapa en la que decido si su software será un invitado aceptable en mi casa, por lo que quiero poder verlo todo.
Quiero una sola clave de licencia para todo mi sitio. Tener que ingresar una clave de licencia por separado en cada PC rompe la regla "debe tener administración / administración central". Póngale un precio razonable también, de modo que si solo necesito instalar su software en 200 de mis PC, no estoy pagando lo mismo que si tuviera que instalarlo en 1500.
Finalmente, el soporte y mantenimiento continuos es importante. Hacer que el software entre y se ejecute sin problemas es solo una pequeña cosa, después de todo, pero la forma en que se comporta con el tiempo en el uso diario es absolutamente crítico. Si necesito ponerme en contacto con usted para resolver un problema, no espero ningún obstáculo, y no espero que empiece a echarle la culpa a otra parte sin al menos una investigación para establecer los hechos. Tampoco tomo amablemente ningún intento obvio de estafarme en un contrato de mantenimiento.
fuente
La respuesta de GAThrawn cubre la mayor parte de lo que iba a decir. Quiero ampliar un poco el aspecto de licencia de las cosas.
Las aplicaciones que necesitan llamar por teléfono a la nave nodriza para verificar la licencia generalmente se rechazan. Si realmente protege su software, proporcione un servidor de licencias que podamos alojar nosotros mismos. Esta puede ser una solución de terceros como FLEXlm o algo que desarrolle internamente. FLEXlm es, con mucho, el más común en nuestro entorno.
Las opciones de licencia de uso concurrente son siempre una gran ventaja.
Si nos hace alojar un servidor de licencias, asegúrese de que el puerto tcp / udp en el que se comunica sea configurable. NO ASUMA que su servidor de licencias es el único que se ejecuta en la caja.
Todas las interacciones cliente / servidor deben realizarse sin interacción del usuario final.
Un archivo de texto que vive en un recurso compartido de red que requiere que los usuarios finales tengan acceso de escritura NO ES una solución de licencia aceptable. Los usuarios no tienen y nunca tendrán acceso de escritura a nuestros servidores de licencias o aplicaciones. No vamos a hacer una excepción para ti. No me importa si crees que podemos mantenerlo bloqueado con cuotas y demás. No vale la pena la molestia y su software simplemente no es tan importante.
fuente
Primero voy a responder el # 5, porque es lo más importante para mí.
Lo primero que puede hacer es pasar la prueba del logotipo de Windows. El programa "Diseñado para Windows" (o como lo llamen en la actualidad) prueba una serie de funciones del programa e interacciones del sistema que, si se escriben de acuerdo con las reglas, reducen el trabajo para mí y garantizan un nivel de estabilidad y usabilidad para los usuarios.
Aquí están las respuestas al resto de sus preguntas en orden:
Utilice siempre un instalador MSI en un solo archivo si es posible. Esto me permite implementar manualmente, con la directiva de grupo o con casi cualquier herramienta de implementación de software que desee. Windows Vista (y Server 2008) incluye Microsoft .NET Framework 3.0 (y 2.0) como un componente del sistema operativo. Si está utilizando .NET, haga que la versión 2.0 o 3.0 sea su requisito, y me facilitará la vida. Si tiene otro requisito de marco, como .NET 3.5 o Java Runtime Environment, siga las instrucciones del fabricante para la instalación al pie de la letra.
No. En un entorno de usuario limitado, los usuarios no pueden aprobar actualizaciones, y casi nunca deseo que las actualizaciones de programas que no sean las actualizaciones de seguridad del sistema operativo se descarguen automáticamente. Desactive las actualizaciones automáticas de manera predeterminada en los modos de instalación de interfaz de usuario silenciosos o básicos, de modo que si implemento a través de la Política de grupo, no tengo que seguir con scripts de modificación del registro o visitas a la estación de trabajo para desactivar su actualizador. En una instalación manual e interactiva, está bien solicitarlo.
No tengo una buena respuesta sobre cuánto tiempo lleva. En mi último trabajo, varió ampliamente en el rango de inmediato a años.
La licencia debe ser fácil y familiar. Cuanto más similar sea la licencia de su producto a algo que ya sé, menos tengo que aprender al respecto y más rápido puedo seguir comprando e implementando su producto. Dependiendo del tipo de programa, tiendo a preferir las licencias por máquina o por usuario; estos son fáciles de rastrear asignándolos a usuarios específicos. Para mi trabajo anterior, nuestra empresa era demasiado pequeña para que las licencias de sitio, que generalmente eran muy caras, fueran asequibles.
fuente
La función de TI es implementar y mantener tecnología para respaldar el negocio principal.
Para usted, el ISV, eso significa:
La licencia es algo que depende de lo que hagas. Como un chico de TI. Cuando selecciona una solución de software para adquisición, el modelo de licencia debe ser parte de ese proceso. El costo de la administración de la licencia en nuestras adquisiciones, por lo que si usted es una empresa como Symantec que quiere ganar cinco centavos con diez métricas de licencia diferentes, nuestro costo de cumplimiento contará en su contra. Si usted es una empresa como Microsoft y su escandaloso proceso de licencias es horrible, pero no tengo otra opción ... eso se convierte en parte del costo de hacer negocios.
fuente