Les enjeux ne font qu’augmenter pour obtenir une bonne qualité du premier coup. La qualité des services Web et de la SOA peut faire ou défaire les performances et la fiabilité des services composants, et peut même colorer la perception de l'informatique en général.
Lisez une transcription du podcast.
Borland Software récemment a publié son initiative de gestion de la qualité du cycle de vie (LQM), qui applique l'assurance qualité à l'ensemble du processus de conception des applications, avec un accent particulier sur la phase des exigences.
Bien entendu, la qualité ne concerne pas seulement le code, mais également la qualité du processus, de la méthodologie et la qualité des définitions. Il s'agit aussi de personnes.
Nous avons donc appliqué l'approche qualité de Borland sur le terrain pour tester cette réflexion dans un atelier de développement d'applications très actif. Dans ce podcast d'information B2B sponsorisé, écoutez Chris Meystrik, vice-président de l'ingénierie logicielle chez Télévision de bijoux
à Knoxville, Tennessee, décrit son environnement au rythme rapide et ce qu'il recherche en matière d'outils, de tests et de gestion du cycle de vie des applications.Découvrez les extraits de la discussion :
... Ce que nous avons fait, c’est passer à un processus de développement itératif très agile, où la qualité doit faire partie. Au tout début de ce processus, dès les exigences même en pré-découverte, nous avons l'assurance qualité des ingénieurs et des responsables de l'assurance qualité participent au projet pour comprendre quels sont les impacts va être. Grâce à cela, nous pouvons amener l'entreprise à penser à la qualité dès le début, avec notre produit. les gestionnaires et les chefs de projet obtiennent une vue d'ensemble de ce que pourrait être un calendrier de projet réel ressembler. À partir de là, notre assurance qualité est fortement impliquée dans le processus agile, jusqu'au bout, en mesurant la qualité du produit. Cela doit être ainsi.
Nous avons besoin que les fournisseurs nous fournissent des produits ouverts, des produits qui communiqueront entre eux à chaque phase du cycle de vie de notre développement de produits. Nous disposons d'ingénieurs des exigences, de chefs de produit et de chefs de projet, tous deux dans les premières étapes du processus. projet avec la charte du projet - essayer d'allouer les ressources, puis définir les exigences initiales ensemble.
Lorsque les ingénieurs comprennent enfin cela, ils n’ont plus affaire au même ensemble d’outils. Le monde de l’ingénieur des exigences est celui de la documentation et de la traçabilité, et il doit pouvoir s’assurer que chaque exigence qu’il rédige est sans ambiguïté et peut faire l’objet d’un contrôle qualité en fin de compte. C’est leur travail au début.
Lorsque cela est transféré à l'ingénierie, ils utilisent leur système de gestion de code source (SCM), et leurs systèmes de suivi des bogues et des problèmes, et ils utilisent leurs IDE. Nous n'avons pas besoin d'eux pour entrer dans d'autres outils. Tous ces outils doivent coexister dans un seul framework ALM qui permet à tous ces outils de communiquer.
Ainsi, par exemple, dans Eclipse, qui est très, très populaire ici, vous avez un aperçu de ce que sont ces exigences. ressembler jusqu'au bureau des ingénieurs, sans avoir à ouvrir un autre outil, que nous ne connaissons jamais fait. Sans cela, vous avez cette barrière à l’entrée que vous voulez simplement éviter. Les communications sont plus lourdes.
En matière de traçabilité, vous souhaitez une traçabilité jusqu'au niveau du code source, depuis ces exigences jusqu'à Subversion, qui est l'outil que nous utilisons. Jusqu'à la génération de plans de test à partir des exigences, nos ingénieurs QA n'utilisent pas l'outil d'exigences; ils utilisent des outils de tests de régression automatisés et des outils de tests de performances automatisés. Ils souhaitent rédiger leurs plans de test et disposer d'entrées et de sorties bidirectionnelles dans les outils d'exigences, afin de pouvoir maintenir leur traçabilité. Donc, partout, il doit être communicant et ouvert.
Les enjeux ne font qu’augmenter pour obtenir une bonne qualité du premier coup. La qualité des services Web et de la SOA peut faire ou défaire les performances et la fiabilité des services composants, et peut même colorer la perception de l'informatique en général. C'est pourquoi la qualité doit se produire dès le début, et non comme une activité tardive, de peur que le les architectes et les analystes commerciaux détectent que les services ne peuvent pas être aussi fiables que les services monolithiques. applications.
Pour plus, écoute au podcast de 29 minutes, ou lire la transcription complète. Commanditaire: Logiciel Borland.