C'est donc à partir d'une synthèse de ces deux familles de paradigmes que les méthodes de représentation du génie logiciel actuelles se sont élaborées. On leur adresse toutefois une série de reproches qui les rendent responsables de la crise du logiciel.
La division du travail découlant de l'approche par tâches spécialisées et du cycle de conception en V rend difficile la production des résultats tangibles. En effet, cette approche impose une compréhension globale de la conception comme préalable à la programmation. Bien souvent, lorsque le groupe d'étude publie son cahier des charges, les besoins ont changé (alternativement, les structures de l'entreprise ont radicalement évolué, un nouveau produit est apparu qui n'est pas exprimable par le système ou le budget est épuisé à cause des retards). Sur les projets de grande taille, la longueur des phases rend également très fréquent le changement des analystes en cours d'étude.
Finalement, un projet stoppé dans sa phase de développement représente une perte sèche. La pression est donc très forte en début de projet, alors que les décisions les plus importantes doivent être prises à partir d'un minimum d'éléments. Les approches traditionnelles se caractérisent donc par une extrême difficulté des premières étapes : toute erreur alors peut avoir des conséquences graves.
Enfin, les faibles performances des méthodes de développement doivent être replacées dans le contexte actuel de montée des attentes. Le client ne demande plus seulement les résultats bruts des traitements sur d'interminables listings, mais il veut un système ergonomique, rapide, convivial et admet de moins en moins les erreurs et les pannes. Les paradigmes classiques du génie logiciel sont incapables de satisfaire ces attentes d'autant plus qu'elles impliquent une complexification accrue des programmes.
L'implication des utilisateurs non-informaticiens dans un projet est souvent difficile. Principalement du fait de la difficulté à exprimer leurs besoins dans un "format" propre à une modélisation claire et exhaustive. Par exemple, le cahier des charges détaillé est un document dont la lisibilité peut souvent se comparer à celle d'un annuaire.
La communication dans le sens inverse n'est pas plus aisée; d'une part à cause de la méconnaissance des clients du vocabulaire et des contraintes informatiques, mais aussi de par la forme des supports de communication. A partir d'un certain niveau de complexité, la vérification des diagrammes entité-relation ou de structuration des traitements par un non-informaticien devient impossible.
En résumé, les mécanismes d'expression des besoins et ceux des réponses qui leurs sont apportées ne sont pas suffisamment compatibles.
On l'a vu, l'analyse en structure de données permet de concevoir des programmes plus évolutifs. Cependant, elle ne permet pas de représenter la mission de l'application, ce que l'utilisateur attend d'elle. Il faut donc tôt ou tard décrire l'application en modélisant ses traitements. De fait les grands projets procèdent nécessairement d'une double approche : une équipe travaille sur la structuration des données, tandis que l'autre se concentre sur les services à fournir aux utilisateurs, donc sur la structuration des traitements. Une difficulté majeure apparaît lorsqu'il s'agit de faire la synthèse des résultats des deux équipes : Les deux représentations sont pertinentes, mais jamais entièrement conciliables.
Cela est par exemple le cas lors de la décision de placement des fonctions dans la structure des traitements. Ce problème se fait principalement sentir lors de la maintenance des applications.
Par maintenance on entend toute action sur le programme qui doit être réalisée après sa phase de conception et alors qu'il est en service.
La maintenance est un processus extrêmement difficile en raison de l'interdépendance des composants du système. En effet, la modification des traitements d'une sous-fonction affecte alors les données utilisées par le reste de l'application. Ce phénomène est appelé régression par les informaticiens.
On peut montrer que le problème de la régression est du à une contradiction entre l'approche fonctionnelle et celles par les structures de données.
- L'approche par les traitements impose qu'une sous-fonction utilisée en plusieurs endroits ne soit présente qu'en un seul exemplaire. Dans l'arborescence du programme cette fonction sera 'remontée' pour être commune et utilisable par toutes les fonctions qui en ont besoin.
- La sécurité des données de l'application, quant à elle, impose que leur accès ne soit possible que par le minimum de fonctions. En effet, lorsqu'une donnée peut être modifiée par plusieurs procédures, il devient impossible de trouver l'origine de cette modification. On aura donc tendance à 'descendre' la fonction d'accès pour éviter des modifications intempestives. Ceci est contradictoire avec l'approche par les traitements.
On l'a vu, les paradigmes de représentation cartésiens et systémique sont à la source des schémas de représentation que sont les diagrammes de structuration des traitements et des données. Mais se sont également ces paradigmes qui ont guidé l'élaboration des langages de programmation.
C'est dans la mise au point de langages destinés à résoudre des problèmes de simulation que le paradigme objet trouve son origine.
