Projector Software GmbH

Illustration 'design'

Principes de conception

Dans toutes les disciplines techniques, la facilité de mise en œuvre d'un projet de construction dépend fortement de la qualité de la conception choisie. Comparé à d'autres domaines comme le bâtiment, par exemple, des limites physiques de la conception sont de moindre importance pour le développement de logiciel. Quelques infractions aux règles pour une bonne conception n'affectera pas immédiatement le résultat. Cependant, à long terme, les problèmes s'additionnent. Les sections suivantes contiennent nos considérations sur ce sujet et sont graphiquement illustrées. Pour abréger, nous ne specifions pas encore la granularité de la conception. Cette différenciation nécessaire vous sera expliquée dans notre conclusion finale.

Conception monolithique

Pour notres exemples la conception monolithique doit principalement rendre clair deux aspects:

  • Cette conception produit son effet d'une façon exacte correspondente aux possibilités de sa forme donnée.
  • Des modifications ou extensions postérieures sont faisables seulement au moyen d'une reconstruction complète. (Cette restriction est symbolisée par le matériel choisi.)

Conception monolithique En regardant l'illustration, on comprand que changer la position de la porte serait difficile postérieurement. En effet, dans quelques domaines d'application on n'a pas besoin de change, et dans tels cas la structure monolithique est fongible, parce que abandonner la variabilité épargne un grand effort. Mais si on ne connaît pas encore les exigences à long terme, on doit préférer une conception modulaire au lieu de la monolithique.

Conception modulaire

La conception modulaire permet beaucoup plus de flexibilité que le monolithe introduit avant. Voici un exemple qui illustre les aspects suivants:

  • Tous les éléments sont standardisés. Malgré leur spécialisation apparente, en principe ils peuvent être utilisés universellement.
  • Pour les éléments on choisit des matériaux de construction facilement usinable qui reduisent l'effort de la construction. Si vous avez besoin d'un nouveau type de l'élément à l'intérieur de la structure, on peut le faire proprement.
  • Des grandes modifications peuvent être réalisées si on démonte la construction aussi beaucoup que nécessaire et la reconstruit avec des éléments adaptés.

Conception modulaire Dans cette illustration les différences entre les éléments dépendent de leur fonction particulière (toit, murs, châssis). Quand même idéalement ils gardent une certaine indépendance: Les planches sur le toit pourraient être utilisées à une place différente, aussi les éléments de châssis pour la porte et fenêtre, par exemple.

Les indicateurs importants pour une conception bien réussie sont, en outre:

  • Les élément de conception sont utilisés dans un principe générale, idéalement sans aucune exception.
  • La façon dont les éléments différents étaient utilisés représente un niveau sémantique (quelque chose fait partie du toit, mur ou châssis, par exemple) - contrairement à: "nous ne pouvons pas dire exactement quelle tâche cet élément remplit".

Les avantages générales d'une conception bien réussie peuvent être compris clairement en regardant un exemple contraire comme la conception tissée dans la section suivante.

Conception tissée

Dans le contexte étudié ici on ne trouve pas d'avantage mais un problème, si tout est tissé comme un réseau: À cause de l'interaction forte entre la majorité des éléments de la conception, même des petites modifications ont un grand effet. En outre, il y a un autre désavantage: Analytiquement, c'est-à-dire sans épreuve, on ne peut pas pronostiquer la force des interactions entre les éléments. La planificabilité de la transposition des exigences nouvelles souffre de cela.

Conception tissée Suivant l'exemple du concept "Monolithe" (monos = un seul, lithos = pierre), nous introduisons pour une conception comme la présente la désignation "Hétéroxyle" (heteros = différent, xylon = bois). Une conception hétéroxyle est composé pas d'un seul élément principal de pierre, mais des plusieurs éléments differents en bois.

Dans la pratique du développement de Logiciels, les hétéroxyles se produisent plus souvent que l'on attendrait. Beaucoup de fois ils sont formés à partir d'une première conception accidentelle, qui étonnamment était réussie. Au lieu de développer une conception sérieuse basée sur une telle idée spontanée, on est guidé par l'illusion du succès déjá atteint et renonce à une reconstruction profonde – peut-être à cause du peur de perdre quelque chose de fonctionnement.

Le plus déjà investi pour une hétéroxyle, le plus difficile on se sépare de cela. C'est pourquoi, dans la pratique, on tombe rarement sur des hétéroxyles non-affinés comme en haut, mais dans la plupart sur des variantes rectifiées et bien entretenues.

Conception tissée entretenue Comparé à la condition précédente, les saillies frappantes ont été écartées dans l'exemple illustré ici. En outre, les coins gauche et droit du logement ont été garnis de poteaux marquants, et dans la zone du toit quelques-uns des éléments plus volumineux ont été remplacés par des petits. Même si on peut attester un dévéloppement minimale à une telle conception, elle restera problématique pour plusieurs raisons:

  • Probablement les modifications entreprises ont causé un grand effort et quand même, on ne voudrait guère parler d'un percée technologique. En future l'effort pour des modifications sera augmenté de plus en plus.
  • Les interactions entre les éléments sont encore compliquées et difficilement à estimer.
  • La signification logique de quelques liaisons d'éléments reste pas clair: Ou exactement sont-ils attribués? Si on voudrait, par exemple, élargir la porte plus tard, on devra définir coûteusement, quels éléments font partie de la porte, par ce que le rôle d'un certain élément dans la construction ne peut pas être défini exactement.

Malgré ses faiblesses, un hétéroxyle est plus flexible qu'un monolithe et peut être modifié ou élargi plus facilement - au moins de son principe. Mais dans la pratique même des modifications petites porteront préjudice à la stabilité de toute la conception. Chaque composent du style hétéroxyle représente un risque omniprésent pour tout le système logiciel, ou il est intégré: Les dépenses pour des modifications sont difficilement estimables.

Conception prototypique

Qu'est-ce qu'on doit installer pour atteindre l'utilité espérée? Ce défi existe aussi à la construction d'une conception modulaire, parce qu'au moins on doit à l'avance choisir les types d'éléments différents pour la construction. Afin d'évaluer les avantages pratiques d'un développement planifié avant sa réalisation finale, il est généralement conseillé de commencer avec un prototype.

Conception prototypique L'idée derrière la création d'un prototype est d'épargner un grand effort en comparaison à la réalisation finale par une simplification sélective. Néanmoins, on essaie de produire un résultat qui, dans la mesure, correspond bien à la conception planifiée. Cette illustration montre un exemple d'un logement prototypique qui est composé des rameaux, qui ne seraient pas capables de porter. En conséquence, ils sont hourdés avec de la terre glaise pour donner une stabilité au logement. Grâce à l'étanchéité de la construction, toutes les questions significatives sur ce prototype peuvent être repondues assez précisément:

  • Est-ce que le logement offre un espace suffisant pour les besoins planifiés?
  • Est-ce que les dimensions et positions des fenêtres sont bien choisies, que l'intérieur est suffisamment éclairé?

Dans une construction réelle de terre glaise on pourrait identifier par le choix du matériel et façonnage, si la construction aurait seulement un caractère prototypique faute de résistance aux intempéries. Par contre, dans le développement des logiciels, l'aptitude d'une construction à long terme est classée - entre autres critères - comme suit:

  • Est-ce que la conception peut être modifiée ou élargie facilement après coup? A cet effet, sa base technique doit être transparente.
  • Est-ce que le type de conception choisi permet une utilisation pratique dans l'échelle prévue? Ou ya t-il des limitations à la fonctionnalité et la capacité?

En évaluant la construction illustrée ci-dessus sur la base des critères expliqués, elle serait identifiée comme un prototype - au moins par ce que le crépi de terre glaise cache le bois et par conséquent, la construction est moins transparente. En vertu des étançons minces on devrait attendre une stabilité faible en général. Donc d'avance, on ne peut guère estimer les limitations de la capacité de charge, ou sur quels points des ruptures pourrait être appliquées sans risque, par exemple.

Une conception prototypique est partiellement similaire au monolithe, mais aussi à la conception hétéroxyle. Cependant, les desavantages pratiques de cette affinité ne sont pas importants, par ce que le prototype est intentionnellement planifié économiquement:

  • L'effort pour sa stabilisation peut être minimisé au nécessaire pour l'épreuve pratique.
  • La réduction fonctionnelle diminue aussi le déploiment pour la conception.

Au total, une conception prototypique est beaucoup plus économique que d'autres conceptions d'une échelle similaire. Si, contre toute attente, on a besoin de grands changements postérieurs, il serait expédiant de construire un nouveau prototype.

Conclusion

Dans les sections précédentes nous avons comparé des bases différentes pour des conceptions techniques: monolithe, conception mudulaire, tissée et prototypique. Le point de départ de nos discussions était la question pourquoi dans la pratique le logiciel se développe souvent défavorablement. Avant de donner une réponse, nous voulons encore affiner les modèles déjà illustrés pour expliquer les aspects plus importants.

Évaluation différenciée

Comme mentionné au début, les désavantages et avantages des conceptions différentes sont valables seulement dans certaines limites. Il n'y a pas d'objection à un module monolithique s'il se restreint à une fonctionnalité assez simple. Finalement, chaque image du monde réel dans un logiciel résult à une une séquence d'étapes de programme correspondante à une partie des exigences aussi directe que possible – vers des lignes simples de code qui au plus tard doivent être considérés comme un monolithe. Dès l'instant que les éxigences se changent, exactement ces éléments du système doivent être remplacés. Cela réussit sans problème si les parties monolithiques restent compacts et libres des interactions confuses.

Des schémas similaires sont valables aussi pour une conception tissée: Dans une mesure acceptable elle peut être conforme aux tâches. Une conception devient un hétéroxyle avec tous ses désavantages seulement lorsque son réseau dépasse une mesure contrôlable.

Même le principe favorisé de la conception modulaire n'est pas entièrement avantageux. Dans notre example illustré on pourrait avoir l'idée de creer - au lieu des éléments specialisés - un autre niveau modulaire pour les poutres, lattes carrées et châssis. Mais dans cette expérience de pensée la relation entre dépenses et avantage serait probablement très mauvaise en comparaison d'une directe construction des éléments de base. Chaque niveau supplémentaire augmente automatiquement la complexité de la construction totale. En outre, sans clarté les abstractions ne restent pas compréhensibles. Il est dès lors préférable d'utiliser une généricité et des indirections seulement dans les cas où on l'attendrait concernant le contenu.

Enfin, une conception prototypique représente une méthode dans laquelle certaines exigences connues intentionnellement ne sont pas rempliées. Cette méthode est legitime tant que le prototype n'est pas surmené.

Par cette différenciation, nous comprenons qu'il n'y a pas de remède miracle, qui garantit automatiquement un bon resultat à la réalisation des conceptions complèxes. Une inspection plus minutieuse révèle que presque toutes les ébauches - à l'exception d'un hétéroxyle - ont leur autorisation spécifique. On peut donc supposer que les hétéroxyles ne résultent pas d'un acte intentionnel, ou au début, ils sont considérés comme quelque chose pas dangereux ou même utile. Cela donne lieu à des questions suivantes:

  • Pourquoi est-ce que la naissance d'un hétéroxyle n'est souvent pas empêchée à temps?
  • Quelle est la meilleure façon de le traiter, s'il existe déjà?

Origine d'hétéroxyles

Tout d'abord, on a besoin de critères pour identifier un hétéroxyle. Pour cela nous vous montrons encore une fois les deux illustrations:

Conception tissée entretenue Conception modulaire Dans la conception modulaire les éléments de base sont bien élaborés. Par celà une construction précise est rendue possible, peu importe où les éléments sont utilisés. Finalement, la flexibilité voulue de la construction résulte de la qualité de ses éléments de base.

Dans l'hétéroxyle, par contre, l'élaboration des éléments est minimisée par utilisant des choses existantes au hasard et pratiquement non transformés. Alors, on ne s'est pas libéré des matériaux déjà existants (troncs d'arbres fraîchement abattus) et par celà on ne peut pas s'exprimer de manière adéquate sur un niveau constructif.

Une incitation pour cette façon finalement trompeuse d'épargner effort peut être la pensée de poursuivre "premièrement" le but réel et (le cas échéant) d'exécuter les nettoiements necessaires "plus tard" quand on a déjà atteint un résultat saisissable. Mais exactement cette méthode ne mènera pas à bien:

  • Les éléments pas élaborés peuvent être utilisés seulement d'une manière dépourvue d'une conception générale. Cela conduira à une spirale des coûts chaque fois que la construction est plus complexe.
  • Si on doit finalement changer le système pour une conception modulaire, l'effort déjà investi est perdu: On ne peut pas modifier les élements d'un hétéroxyle légèrement à une conception modulaire, parce qu'ils ne sont jamais compatibles. Dans le meilleur des cas l'hétéroxlye peut être regardé comme un prototype trop coûteux.

Particulièrement le point cité en dernier lieu attire dans un guet-apens psychologique: Concernant chaque nouvelle exigence, on doit peser le change complet et immédiat ou la création d'une "modification dernière". Dans cette perspective, l'effort pour tous les autres modifications serait moins que le change complet - aussi parce que concernant un hétéroxyle grand, on ne peut pas prédire les exigences à une conception de rechange.

Maniement dans la pratique

Qu'est ce qu'un développeur de logiciels peut faire pour empêcher les problèmes décrits ou au moins pour ne pas empirer les choses dans le cas d'un hétéroxyle déjà existant? Les notres propositions:

  • Développer une prise de conscience générale, de quelle façon on travaille: Est ce que c'est un prototype, une conception modulaire, un monolithe ou déjà un hétéroxyle?
  • Quand on s'est décidé à une conception modulaire, il faut une élaboration soigneuse de tous les éléments de base, mais pour le moment, on ne voit pas de résultat provisoire.
  • Il est recommandé de signaler le plus tôt possible quand les exigences des modifications d'un composant dépassent un seuil critique. C'est une ambition fausse d'essayer à contrôler une confusion montante avec plus d'application. Malgré les nouvelles exigences, on doit s'employer à la bonne disposition du système.
  • Prendre de la responsabilité pour empêcher un développement indésirable. Concernant les niveaux acceptables de confusion dans les logiciels, il ya beaucoup d'opinions personnelles differentes entre les développeurs. Dans une situation complexe d'un projet avec plusieurs participants résulte par ces différences la tendance de confier des modules problématiques aux développeurs particulièrement tolérants à ce sujet.

Analogiquement à son émergence progressive, un hétéroxyle peut être démonté graduellement, au moins dans certaines limites. Cela est possible, par exemple, en isolant les sous-composants particulièrement problématiques comme monolithes encastrés. Ainsi on peut poursuivre la transformation de l'hétéroxyle à une composition de monolithes indépendants et après les congeler dès que possible. Basé sur les connaissances acquises sur les exigences déjà mises en œuvre, on peut faire une refonte approfondie, si la gestion de projet est déjà convaincue.