[Développeur SI] 09. Début du développement réel après l'intégration au projet SI

Histoire d'un développeur SI
#9. Après l'intégration au projet SI - Début du développement réel

Après l'intégration au projet et une période d'adaptation, on commence le développement proprement dit. Le développement consiste à implémenter les fonctionnalités décrites dans le RFP (cahier des charges) en suivant le calendrier du WBS. Dans le contexte de l'intégration de système (SI), on part du principe que les fonctionnalités peuvent être modifiées à tout moment et on s'efforce de maintenir une faible couplage entre les différents modules.

En effet, le client qui a lancé le projet, bien qu'il connaisse son propre métier, n'est pas toujours en mesure de définir précisément les fonctionnalités nécessaires, l'organisation des écrans, etc. Il est donc très courant qu'une fois une interface développée et présentée, des exigences supplémentaires ou des modifications soient demandées.

Par conséquent, si le couplage entre les modules est élevé, la modification d'un seul module peut nécessiter la modification d'autres modules, ce qui peut entraîner des effets secondaires imprévus et une prolifération de code redondant.

L'objectif principal de l'intégration de système (SI) étant de faire fonctionner le système coûte que coûte, la qualité du code et l'efficacité passent au second plan.

Au début, on a tendance à vouloir faire les choses proprement, mais face à des délais serrés et aux demandes incessantes du client, on se retrouve rapidement à développer rapidement, en mode « vite, vite ».

De plus, le client, considérant qu'il a payé pour le projet, peut parfois se désintéresser complètement du processus de développement. Cela préfigure souvent les problèmes qui vont survenir en fin de projet. Il est donc important de poser des questions si on ne comprend pas quelque chose et de bien clarifier les choses.

Lors du développement dans le cadre d'un projet SI, il est important de garder à l'esprit les points suivants :

• Le contenu peut être modifié à tout moment.
• Le client ne connaît pas forcément le domaine technique. Il faut présenter les écrans petit à petit et recueillir régulièrement ses commentaires.
• Il ne faut pas accepter toutes les demandes d'ajout de fonctionnalités, sauf si elles sont absolument nécessaires.
• Je ne suis pas Bill Gates. Le client préfère un programme qui fonctionne rapidement à un programme parfaitement optimisé.