Compatibilité des activités
Utilisez des processus réels pour vérifier combien de besoins essentiels le système open source peut couvrir, pas seulement la liste des fonctionnalités et la page de présentation.
Home / Orientation des décisions du projet / Développement de la personnalisation et adaptation open source
PROJECT DECISION GUIDEDévelopper à partir de zéro adaptation personnalisée ou open source basée sur le système
Les modifications apportées aux sources ouvertes ne sont pas nécessairement moins coûteuses ou plus faciles à gérer à partir de zéro. La clé consiste à juger de la correspondance entre les capacités existantes des sources ouvertes et les opérations ciblées, ainsi que des mises à niveau et des coûts de maintenance futurs.
Répondez à la question.
Développement personnalisé et adaptation open source
Lorsque les processus de base sont communs, les projets open-source sont matures et les licences compatibles avec les modèles d'affaires, les adaptations basées sur les systèmes open-source peuvent raccourcir le premier cycle; lorsque les règles d'affaires constituent la compétitivité de base, les contraintes de structure sont claires ou la profondeur des adaptations peut être prolongée loin des versions communautaires, il est généralement plus approprié de personnaliser à partir de zéro.
DECISION FACTORS
Éléments clés à vérifier pour la prise de décision
Premièrement, les limites de la retenue et de la responsabilité sont identifiées, puis les itinéraires techniques et les modalités de coopération sont comparés.
Délivrance de licences et modèle d'entreprise
Évaluer les limites admissibles d'utilisation, de modification, de distribution, de services SaaS, de marques de commerce et de composants de référence, sous réserve d'un examen par les professionnels du droit, au besoin.
Modifier la profondeur
Les interfaces, les marques et un petit nombre d'extensions de processus sont généralement moins risquées; des changements importants dans les modèles de données de base et les structures de base peuvent affaiblir les avantages du programme open source.
Mise à jour du chemin
Il faut préciser qui est responsable des mises à jour de la version communautaire, des correctifs de sécurité, de la consolidation personnalisée des branches et des tests de régression automatisés.
Compétences de l'équipe et prise en charge
Il convient de choisir l'une ou l'autre des voies et d'obtenir les codes sources, les instructions de déploiement, la migration des données, les interfaces et les documents de transport.
Coût total de la propriété
Comparez les coûts de développement, de licence, de ressource cloud, de mise à niveau, de mobilité, de sécurité et de personnel pendant au moins trois ans, plutôt que de compter sur la première offre.
Préparation des recommandations avant la communication ou l'évaluation
Cibler les processus opérationnels et les fonctions différentiellesActivité du projet candidat à l'ouverture de la procédureLicences et composants de référenceStructure et ancrage techniqueLacunes en matière de sécurité et mécanismes de mise à jourPoints de développement secondaireVersion Mise à jour et politique de la Direction généraleCoût total de trois ans de propriété
Voies de mise en œuvre suggérées
Il est recommandé d'entreprendre une série d'analyses de sélection et d'écarts, avec une matrice de la demande de production, un risque de licence, une liste d'adaptation, une stratégie de modernisation et une comparaison des coûts des deux routes, avant qu'une décision ne soit prise sur la mise en place d'un projet.
DECISION WORKSHEET
Développement de la personnalisation et adaptation à la source ouverte pour la prise de décisions exécutoires
Les feuilles de travail suivantes aident les entreprises à organiser des conseils vagues en matière d'apports fondés sur les fournisseurs, d'approbation interne et de réception de projets.
Compatibilité des activités
Utilisez des processus réels pour vérifier combien de besoins essentiels le système open source peut couvrir, pas seulement la liste des fonctionnalités et la page de présentation.
Si le facteur demeure incertain, il faut organiser un diagnostic ou une validation à petite échelle et il n'est pas approprié d'inclure directement la fourchette de prix fixe non variable.
Délivrance de licences et modèle d'entreprise
Évaluer les limites admissibles d'utilisation, de modification, de distribution, de services SaaS, de marques de commerce et de composants de référence, sous réserve d'un examen par les professionnels du droit, au besoin.
Si le facteur demeure incertain, il faut organiser un diagnostic ou une validation à petite échelle et il n'est pas approprié d'inclure directement la fourchette de prix fixe non variable.
Modifier la profondeur
Les interfaces, les marques et un petit nombre d'extensions de processus sont généralement moins risquées; des changements importants dans les modèles de données de base et les structures de base peuvent affaiblir les avantages du programme open source.
Si le facteur demeure incertain, il faut organiser un diagnostic ou une validation à petite échelle et il n'est pas approprié d'inclure directement la fourchette de prix fixe non variable.
Que devrait contenir un résumé comparable des évaluations?
Au minimum, les processus opérationnels cibles et les fonctions d'écart, l'activité des projets de libre-service, les licences et la dépendance aux composantes, l'architecture et la correspondance de ancre technologique, tout en décrivant le volume d'activité actuel, le temps moyen de traitement, les anomalies majeures, les systèmes en place, les privilèges en matière de données, la dépendance des tiers et les fenêtres d'accès.
Par exemple, l'entreprise prévoit que le projet permettra d'économiser 160 heures de travail par mois, mais ce chiffre devrait être ventilé en nombre de tâches, en économies de temps uniques, en taux d'adoption et en taux d'examen manuel. Si seulement 40 % des utilisateurs utilisent la première période ou si le nouveau processus augmente le processus d'examen, les avantages réels seront nettement inférieurs à l'estimation apparente.
Quatre types de preuves recommandées pour les interrogatoires pendant la communication avec le fournisseur
La première est la preuve de la portée : cohérence des versions de la demande, des processus opérationnels, des prototypes, des interfaces et des exclusions; la deuxième est la preuve technique : si des technologies similaires ont des structures accessibles, une gestion de code, des essais, des déploiements et des méthodes de gestion des problèmes; la troisième est la preuve du personnel : si les participants réels, les étapes d'entrée, les responsabilités et les mécanismes de remplacement sont clairs; et la quatrième est la preuve de la livraison : comment les codes source, les données, les numéros de compte, les documents, la formation, l'assurance de la qualité et le transport sont remis.
Il est recommandé que la clarté de la portée, la dépendance critique, la capacité de l'équipe, l'applicabilité de l'acceptation et la prise en charge à long terme soient notées séparément et que la base de chaque score soit enregistrée.
Le principe du jugement
Cette page fournit un cadre décisionnel qui ne constitue pas une offre fixe ou un engagement de rendement.
FAQ
FAQs
Les questions les plus courantes avant la coopération sont clairement énoncées à l'avance.
Un système open source est-il égal à gratuit?+
Les coûts de licence du code peuvent être nuls, mais des intrants techniques sont nécessaires pour la sélection, le déploiement, l'adaptation, la migration des données, la sécurité, la mise à niveau et le transport.
Les systèmes plus ouverts sont-ils modifiés, mieux c'est?+
Non. La capacité d'obtenir des différences par le biais de plugins, de configurations et d'extensions devrait être réduite en réduisant les intrusions dans les codes de base afin de réduire le coût des mises à niveau ultérieures.
Pouvez-vous le refaire d'abord, puis le réécrire?+
Oui, mais dès le départ, il faut planifier les données, les interfaces et les limites opérationnelles pour éviter d'être spécifiquement ciblées sur la migration future.
DECISION FAQ
Regardez les 265 questions.Questions communes relatives aux projets en cours
Applets, APP, SaaS et anciens systèmes
Les systèmes d'entreprise devraient-ils être développés à partir de systèmes zéro ou à partir de systèmes open source dans une phase secondaire?
Les processus sont communs, les produits de source ouverte mûrissent et les licences permettent le développement secondaire. Lorsque les différences d'affaires, les limites de l'architecture de base ou les coûts de mise à niveau à long terme sont élevés, il peut être plus approprié de développer à partir de zéro.
Voir la réponse complèteLancement de projet logiciel et sélection de programmeComment choisir un code bas, des systèmes open source et un développement personnalisé?
Un code bas convient aux processus qui sont clairs, modifiables et capables de couvrir des applications internes plus élevées; les systèmes open source conviennent aux produits matures, qui peuvent répondre à la demande par la configuration et le développement secondaire; personnaliser le développement de projets qui conviennent à des processus différenciés, à une intégration complexe, à des performances ou à des exigences de contrôle de produits plus élevées. La sélection se fait avec une comparaison du coût total et de la capacité de sortie pendant trois à cinq ans, plutôt qu'avec le premier prix seulement.
Voir la réponse complèteDéveloppement de logiciels et externalisation de projetsCombien coûte habituellement le développement de logiciels personnalisés?
Le logiciel personnalisé n'a pas un prix uniforme en fonction de la taille de la page, et les coûts sont déterminés principalement par la portée, l'interface, les données, l'autorité, les performances et la responsabilité de la livraison. Le système de gestion avec le même nom peut être un outil de secteur unique ou un lien avec les commandes, l'inventaire, les finances et l'autorité multi-organisationnelle. Il est recommandé que les premières limites de boucle fermée et de réception et d'inspection soient établies, et que le produit, la conception, le développement, les essais, le déploiement et la charge de travail de maintenance soient estimés.
Voir la réponse complèteLancement de projet logiciel et sélection de programmeLes exigences en matière de logiciels sont incomplètes, alors pouvons-nous d'abord avoir une entreprise externe pour les évaluer?
Il est possible, et si la demande est incomplète, de faire un diagnostic de besoins limités d'abord, plutôt que de demander directement un prix total fixe. Une entreprise doit simplement indiquer son contexte d'affaires, les utilisateurs cibles, les problèmes actuels, le temps pour aller en ligne et les budgets disponibles.
Voir la réponse complèteRELATED
Présentation de l ' évaluation du projetGardez vos connaissances des services
Objet
Commercialisation des systèmes à source ouverte
Comprendre la sélection, le déploiement privé, le développement secondaire et la modernisation à long terme
Pour plus d'informations.ObjetDéveloppement de logiciels d'affaires
Compréhension des processus opérationnels et de la prestation complète des services
Pour plus d'informations.ObjetPrésentation de certaines informations sur l ' évaluation
Rassembler les objectifs, le statut et les projets candidats à l'ouverture
Pour plus d'informations.