Créez-en un à jeter vs effet du deuxième système

D'une part, il y a un conseil qui dit "Construisez-en un à jeter". Ce n'est qu'après avoir terminé un système logiciel et vu le produit final que nous réalisons ce qui s'est mal passé dans la phase de conception et comprenons comment nous aurions vraiment dû le faire.

D'un autre côté, il y a l '"effet du second système" qui dit que le deuxième système du même type qui est conçu est généralement pire que le premier; il existe de nombreuses fonctionnalités qui ne correspondaient pas au premier projet et ont été poussées dans la deuxième version, ce qui conduit généralement à trop complexe et trop d'ingénierie.

N'est-ce pas là une contradiction entre ces principes? Quelle est la vision correcte des problèmes et où est la frontière entre ces deux?

Je crois que ces «bonnes pratiques» ont d'abord été promues dans le livre fondateur The Mythical Man-Month de Fred Brooks.

Je sais que certains de ces problèmes sont résolus par les méthodologies Agiles, mais au fond, le problème est toujours que les principes sont toujours en vigueur; par exemple, nous ne ferions pas de changements de conception importants 3 sprints avant de passer en direct.

Construire un pour jeter vient de "ne pas savoir ce que vous ne savez pas" au début, donc vous apprenez au fur et à mesure ce que vous auriez dû faire au début.

Le deuxième effet du système vient de "savoir maintenant ce que vous ne saviez pas, mais ne pas savoir ce que vous ne savez toujours pas", c'est-à-dire que le deuxième effet du système vient d'essayer de construire un système plus grand, plus brillant et plus complexe que le premier, à l'insu nécessaire au début - ressemble beaucoup à ce qui se passe avec le premier système.

L'effet du second système n'est donc pas contradictoire. Construire un deuxième système avec les mêmes fonctionnalités que le premier n'est (à ma connaissance) jamais fait. Le deuxième système doit toujours être "meilleur", donc plus complexe, donc des problèmes sensiblement similaires au premier système sont attendus - qui devraient être jetés.

Donc, construisez-en un à jeter, jetez-le de manière et reconstruisez-le sans élargissement de la portée, et vous n'aurez pas de deuxième problème de système. (Cela a tendance à être fait plus souvent sur des planètes avec un ciel violet, une mer rose et des cochons volants.)

Le problème auquel vous faites référence signifie que plusieurs choses ont été ignorées, d'où le système résultant a mal tourné. Permettez-moi de décrire certaines des étapes manquantes:

Gestion de la qualité - Faites-le bien dès la première fois! N'utilisez jamais de hacks temporaires ou de compromis temporaires. Il ne doit pas être retravaillé. Toutes les ressources sont utilisées efficacement et tout ce que vous faites est une contribution appropriée au projet.

Analyse de faisabilité - Découvrez les besoins de l'entreprise. Créez une analyse de rentabilisation pour le projet.

Plan de projet - Définissez clairement votre portée initiale, planifiez la façon dont la solution sera livrée, créez une base de référence, respectez le plan. Ne passez pas de temps sur tout ce qui n'est pas sur le chemin critique.

Ingénierie des exigences - Obtenir les exigences commerciales (c.-à-d. Capturer les processus commerciaux et déterminer quelles opérations commerciales devraient être prises en charge par le système informatisé, traduire les opérations commerciales 1: 1 en cas d'utilisation du système). Validez et vérifiez! (construisons-nous la bonne chose? Construisons-nous la bonne chose?) Toutes les exigences doivent être liées au besoin commercial initial.

Conception de logiciels - Traduisez les cas d'utilisation et le modèle de domaine en conception de composants et architecture de solution. Tous les composants doivent être liés aux exigences de RE.

Implémentation - Codez le logiciel comme dans la conception. Tout le code doit être lié aux composants de SD.

Validation - Tests unitaires, tests d'intégration, performances, ... (tous les cas d'utilisation de RE devront maintenant être testés)

Ce sont là quelques aspects clés d'un processus logiciel. Les activités mentionnées font partie du génie logiciel. C'est ainsi que vous construisez la bonne solution logicielle pour les besoins réels de l'entreprise et que vous la construisez dans les délais, le budget et les spécifications.

Recherchez ces termes pour créer un meilleur logiciel et le faire correctement la première fois:

• Analyse de faisabilité (en particulier comment construire une analyse de rentabilisation)
• Gestion de projet (en particulier plan de projet et registre des risques avec atténuation des risques)
• Ingénierie des exigences (élicitation, analyse, spécification, validation)
• Conception de logiciels (UML et génie logiciel basé sur les composants)
• Construction de logiciels (modèles de conception, cadres, programmation défensive)
• Validation des logiciels (tests unitaires, UAT, etc.)