Je fais partie du groupe des approbations de logiciels pour une entreprise multinationale et je ferais absolument écho à tout ce que dit Adam ci-dessus.
Je voudrais également faire les remarques suivantes, tout d'abord toujours payer toutes vos "taxes de développement". Cela signifie que vous devez vous assurer que votre application fonctionne correctement dans une grande variété d'environnements que vous n'utiliserez peut-être jamais, mais qu'elle sera très probablement un facteur de rupture pour les grandes entreprises, ce sont des choses comme s'assurer que votre application fonctionne bien avec les profils d'utilisateurs itinérants et dossiers utilisateur redirigés (utilisez toujours les API Windows pour trouver les dossiers d'utilisateurs et de profils, ne supposez jamais qu'ils se trouvent à des emplacements standard, ou même sur le lecteur local), en vous assurant qu'il fonctionne bien sur les serveurs Bureau à distance (où il peut y avoir un 100 copies de votre application exécutées en même temps, certaines utilisant des connexions très lentes), sur des ordinateurs portables avec des connexions réseau lentes ou des piles faibles, etc. À titre d'exemple, nous avons récemment rejeté les nouvelles versions de plus d'un logiciel d'une très grande entreprise (commence par "A" et est célèbre pour les graphiques) parce que leurs applications ne soudainement pas '
Même pour les logiciels libres / open source, les utilisateurs finaux doivent souvent soumettre une sorte de formulaire de demande pour faire vérifier et approuver le logiciel.
D'après le ton de votre commentaire, il semble que vous pensiez que le processus d'approbation a quelque chose à voir avec le coût? De notre point de vue, le coût unitaire d'une application n'est pas quelque chose que nous considérerions du tout dans le processus d'approbation. Les justifications financières pour les applications auront été élaborées, les approbations de logiciels se feront toutes sous l'angle technique et de la capacité de support. Les logiciels libres et open source ont généralement plus de mal à passer à travers notre processus qu'une application commerciale propriétaire. Souvent, cela est simplement dû au manque de responsabilité. À qui vous adressez-vous lorsqu'il y a des problèmes avec l'application et que vous avez besoin d'assistance, quel est leur SLA? À qui demandez-vous quand vous avez besoin de savoir si l'application fonctionnera avec une nouvelle version d'AutreApp vX, vous donnent-ils vraiment une réponse réelle vers laquelle les gens travaillent vraiment, ou est-ce un vague "
Une fois le processus suivi et le logiciel installé, les mises à niveau peuvent être gênantes - de nombreuses organisations ont tendance à s'en tenir aux anciennes versions des logiciels (Windows XP, Office 2003, etc.) par crainte de problèmes inconnus.
Les mises à niveau logicielles doivent suivre le même processus que les logiciels totalement nouveaux. Le seul avantage qu'ils ont est que nous connaîtrons déjà les réponses à certaines des questions car nous avons déjà pris en charge le logiciel (cela peut ne pas être positif pour le logiciel, les équipes de support ont opposé un veto aux mises à niveau en fonction de l'expérience avec l'entreprise).
Préférez-vous les logiciels compatibles MSI ou xcopy?
L'une ou l'autre de ces méthodes de déploiement peut être bonne, à condition qu'elles soient correctement conditionnées. Sinon, il est fort probable que nous supprimions votre programme d'installation et que nous reconditionnions le logiciel pour le déploiement nous-mêmes.
- Quel que soit le programme d'installation que vous utilisez, vous devez vous assurer que vous respectez tous ses modes d'installation silencieux et sans assistance. Si votre application nécessite une installation manuelle, c'est-à-dire un accord instantané, il n'y a tout simplement pas de moyen pratique de le faire sur des machines sur 5 continents qui reçoivent toute la prise en charge non matérielle d'un bureau central.
- Étant donné le choix, je préférerais une installation MSI bien faite à une installation xcopy bien faite. Le problème avec la plupart des logiciels compatibles Xcopy est lorsqu'ils essaient de s'installer et de s'enregistrer lors de la première exécution. J'ai très rarement trouvé une application qui le fait correctement et ne cause pas de problèmes dans un environnement utilisateur / hotdesk itinérant. Les installateurs MSI (si vous vous en tenez à l'API standard) ne peuvent pas aller trop loin.
- Assurez-vous que votre installation silencieuse donne la possibilité d'apporter toutes les modifications de configuration qui peuvent être apportées lors d'une installation manuelle. Si vous utilisez MSI et que vous vous en tenez à l'API, cela ne pose aucun problème, nous pouvons effectuer des transformations MST et faire tout cela sans problème. Si vous utilisez un programme d'installation tiers différent, assurez-vous qu'il autorise quelque chose comme un fichier "réponse" ou un fichier INI ou similaire. Testez l'installation silencieuse et assurez-vous que toutes les options fonctionnent, je suis tombé sur des produits qui annoncent avec joie leurs options d'installation silencieuse, mais ils n'ont jamais réellement testé si toutes les options fonctionnent.
- De préférence, donnez-nous des options supplémentaires dans l'installation silencieuse qui nous permettent de définir de nombreux paramètres qu'un utilisateur changerait normalement dans le panneau Options. Cela pourrait être par des commutateurs sur setup.exe, pourrait avoir un fichier INI documenté pour les paramètres, en documentant les modifications de registre nécessaires, ou tout ce qui précède. Quoi qu'il en soit, nous aimerions nous assurer que nos utilisateurs peuvent être opérationnels avec le logiciel sans avoir à effectuer de configuration eux-mêmes, les plus importants ici sont les emplacements par défaut pour les fichiers, les noms de serveur par défaut, les paramètres de proxy (si votre application fonctionne via un réseau), etc.
Si le logiciel nécessite des frameworks (Java, .NET), est-ce plus ou moins susceptible d'être problématique?
C'est certainement plus problématique. La gestion des versions dans la plupart des frameworks et la compatibilité ascendante / descendante est atroce. Avec Java en particulier, de nombreuses applications (et sites Web) nécessitent une version majeure et mineure particulière de Java installée et ne fonctionneront avec rien d'autre. Si vous avez besoin de mettre trois applications différentes sur une machine qui ont toutes besoin de différentes versions de Java, et qu'elles ne sont pas satisfaites des méthodes standard de masquer une version Java comme une autre, alors il y aura des problèmes. .Net a ses propres problèmes de versionnage, mais vous laissera volontiers installer toutes les versions majeures du framework en même temps, ce qui contourne la plupart d'entre elles.
Si le logiciel prend en charge les mises à jour automatiques, autorisez-vous généralement cela?
Jamais. Il y a beaucoup trop de problèmes de version et d'interopérabilité pour permettre à une application de se mettre à jour sans aucun avertissement. Les mises à niveau de l'application nécessitent des tests et une planification. De plus, les utilisateurs avec des droits d'utilisateur normaux ne peuvent pas appliquer les mises à jour de toute façon. Si vous utilisez une méthode de déploiement qui permet d'appliquer des correctifs (par exemple, utilisez des MSI avec des correctifs MSP), cela peut rendre les choses comme les correctifs de sécurité pour les applications beaucoup moins difficiles, et nous pouvons gérer nous-mêmes la mise à jour automatique à l'aide de nos outils de déploiement (WSUS et SMS ). De plus, notre équipe de sécurité se méfie de toute application qui "revient à la base", elle aime savoir exactement quelles informations elle envoie et pourquoi elle doit envoyer quoi que ce soit à un serveur inconnu sur Internet.
Combien de temps cela prend-il généralement?
Certaines applications simples et les mises à niveau de version peuvent être décidées dans la mesure où il faut 6 personnes pour cliquer sur un bouton de vote "Approuver" dans Outlook. Des réunions plus complexes ou controversées peuvent attendre notre réunion de groupe toutes les deux semaines. Certaines applications peuvent faire l'objet de discussions lors de plusieurs de ces réunions, car les équipes répondent aux questions sur une application et effectuent des recherches / tests.
Quel type de modèles de licence préférez-vous (transférable, par siège, par processeur, à l'échelle du site)?
Tout dépend de la façon dont l'application va être utilisée et du nombre de personnes. Le plus important est que votre licence soit clairement définie. Nous devons envoyer nos employés suivre des cours (quoique gratuits) pour comprendre les licences Microsoft. On ne va pas se donner la peine de faire ça pour un ISV.
Tenez compte de nos besoins d'installation automatisée et silencieuse en matière de licence. Si vos licences doivent être activées, nous ne voulons pas avoir à vous appeler / vous envoyer un e-mail chaque fois que nous réinstallons une application sur un PC. Si chaque copie de l'application nécessite une clé de licence distincte et différente, nous ne pouvons pas le déployer automatiquement, alors que si nous pouvons acheter une clé en vrac (2, 10, 50, 500, etc.) qui peut être enregistrée dans l'installation silencieuse, alors nous sommes heureux. C'est encore mieux si nous pouvons vous recontacter un an plus tard et négocier pour étendre notre nombre de licences sans avoir à changer la clé saisie dans le logiciel.
Que peuvent faire les éditeurs de logiciels indépendants pour améliorer leurs chances de faire approuver leur logiciel?
Nous examinerons également des éléments qui ne sont pas strictement liés à l'état actuel de votre application. Gardant à l'esprit que si votre application fait partie du flux de travail standard pour l'un de nos domaines, elle pourrait être utilisée pendant 10 ans ou plus, alors à quoi ressemble la feuille de route de votre produit? Si vous ne prenez pas encore en charge la toute nouvelle version de Windows ou en cours de développement, avez-vous un plan pour quand vous le ferez? Vous semble-t-il que vous vous en tenez à ces feuilles de route? Semble-t-il que vous envisagez de modifier radicalement votre application, que ce soit son fonctionnement ou les technologies / cadres qu'elle utilise? Votre application se connecte-t-elle à d'autres applications, par exemple MS Office ou IE, si oui, dans quelle mesure est-elle tolérante des versions plus anciennes ou plus récentes de celles-ci?