Le sujet du rapport est
«1C: DSS , comme outil de mise en œuvre, de développement et de maintenance des systèmes d'information»1C DSS = Application Design System
Conformément à la recommandation 1C, la mise en œuvre et la maintenance de systèmes de classe ERP et d'autres systèmes "lourds" similaires devraient être effectuées sur DSS, en tant qu'outil d'accompagnement.
Conclusions de la lecture du rapport:- DSS est un produit très problématique à utiliser
- La cause des problèmes est que DSS est utilisé de manière incorrecte.
- Il y a un intérêt pour le DSS, beaucoup se demandent comment mettre en ordre et faire une approche systématique de la gestion de projet pour l'automatisation et la gestion de la fonctionnalité des systèmes configurables et maintenus.
Quelle est la signification de la définition «DSS est utilisé incorrectement par beaucoup»?
Tout d'abord , la grande majorité des personnes utilisant DSS l'ont mis sur les développeurs.
Dans de tels cas, les développeurs sont chargés de décrire la fonctionnalité des systèmes comptables dans DSS et de compiler les tâches de développement.
C'est faux.
JIRA et ses produits gratuits similaires feront face à de telles tâches.
Le travail de développeur dans DSS n'est pas fourni. DSS doit confier des tâches de développement au développeur.
Le développeur de DSS, et donc de participants au projet complètement différents, devrait recevoir des spécifications prêtes à l'emploi et détaillées.
Deuxièmement , même le travail d'un seul architecte système dans DSS est insuffisant.
Le DSS ne sera efficace que si une description des processus commerciaux de l'organisation et, séparément, une description des fonctionnalités du produit logiciel (développé ou implémenté) y sont faites.
Et l'architecte doit connecter chaque processus métier avec la fonction du système.
Si quelque chose manque, soit on conclut que le système ne correspond pas aux processus du client, soit la fonctionnalité du système est en cours de finalisation (il est conçu dans DSS!).
C'est à ce sujet que la 4ème diapositive de la présentation, qui montre comment la description des processus métier pour travailler sur un projet pour implémenter le DSS lui-même différerait de la fonctionnalité DSS intégrée dans la configuration.
Conclusion - tout projet de mise en œuvre de DSS est voué à l'échec s'il se bloque sur les développeurs.
Le DSS devrait commencer à travailler beaucoup plus tôt - lors de la collecte des exigences et de la description des processus métier.
Thème à la mode
PS DSS + Vanessa ...
Si dans DSS faire la description des processus (étapes du processus) pour les opérations utilisateur, alors,
en fait, on peut obtenir une séquence d'opérandes de la langue de Gerkin pour Vanessa.
C'est-à-dire script presque terminé.
Encore une fois, la conclusion du post-script - les scripts ne doivent pas être écrits par des testeurs, mais par ceux qui décrivent les processus.
À partir du testeur (développeur / programmeur), il suffit de traduire les étapes des processus dans les commandes exactes du langage (après tout, vous pouvez automatiser ce moment, étant donné l '«humanité» du langage Gerkin).