Developpement

Un article de ChtilandWiki.

Jump to: navigation, search

Page Précédente

Page Suivante

[modifier]

Bases

à faire

[modifier]

Généralités

Voici quelques généralités qui peuvent s'appliquer à tous les langages de programmation. Ces généralités ne sont pas aussi formelles que celles définies par le CMMI, mais simplement issues de ma propre expérience aussi maigre qu'elle soit.

[modifier]

Ne pas réinventer la roue

Il arrive régulièrement d'oublier que l'application que l'on souhaite a déjà pu être développée par d'autres et on se lance dans des jours, des semaines voire des mois d'analyse et de développement.

Penser donc à rechercher sur des sites comme Sourceforge, Berlios, Google Code, Framasoft et bien d'autres en cherchant un peu sur Google.

Parmi les solutions proposées il y a celle de l'Open Source qui présente l'avantage d'avoir un code "ouvert" et donc de pouvoir récupérer les sources et ainsi les adapter au besoin. Pensez également à lire les licences de ces applications et voir si l'utilisation que vous en ferez ne la "viole" pas. Personnellement c'est plus une question de principe et de respect.

Mais avant de se lancer dans ces recherches il faut savoir ce que l'on cherche et pour cela un minimum d'analyse du besoin est requis.

[modifier]

Analyse

La phase d'analyse est la plus importante de tout projet. Elle permet de définir précisément les besoins actuels, futurs et "prévisibles".

Certains n'aiment pas cette phase mais d'autres la préfère... même si c'est une histoire d'affinité, elle n'en demeure pas moins indispensable.

[modifier]

Premiers "débroussaillage"

La relation humaine est ici importante afin de bien cerner les besoins du l'utilisateur final.

Que veut-il faire ?
Comment veut-il le faire ?
Quels moyens (financiers, matériel, humain, compétence...) ?

Un point important lors du premier échange est de ne pas négliger la partie "vocabulaire", car un mot compris d'une façon par l'utilisateur final et d'une autre par l'analyste peut engendrer un résultat catastrophique. Il ne faut pas hésiter à demander la définition de certains mots ou certaines expressions, car parfois ils sont propres au métier de l'utilisateur final, et ont une signification différente dans le sens commun.

Une fois cette première approche effectuée, faire un récapitulatif en expliquant ce que vous avez compris. Si votre 'auditoire' semble vouloir vous interrompre arrêtez-vous et laissez les parler (quitte à les inviter à le faire). Votre exposé terminé, demandez si vous avez bien compris ce qu'il vous ont expliqué.

Un élément à ne pas oublier est que vous n'avez pas les compétences métier de l'utilisateur final. Il serait peut-être judicieux de s'y intéresser.

[modifier]

Observation

Que fait l'utilisateur final, quels sont les outils qu'il utilise déjà et de quelle façon ? Peut-être existe-t-il un outil plus ou moins adapté "bidouillé maison" qui fait une partie du travail. ATTENTION : Si le but de l'application dont vous avez la charge de développer est lié à une réorganisation de la méthode de travail, prendre soin de bien distinguer l'actuel et le futur.

[modifier]

Première Synthèse

Faire une première synthèse de ce que vous avez compris, et de la façon dont vous voyez l'application à venir.

N'hésitez pas à soumettre des objections (argumentées !!!). Ces objections peuvent être liées à ce que vous avez observé de l'organisation actuelle et celle à venir. Cela peut aussi être lié aux contraintes techniques et de développement (une fonctionnalité telle que demandée peut être développée en 15 jours, source de bugs et ralentissements, alors qu'en changeant légèrement la méthode on peut réduire ce nombre de jours de moitié, voire plus, de développement, et donc tirer les prix vers le bas). Cette partie peut être très difficile à amenée, et peut être l'objet d'une levée de bouclier, mais si elle est bien présentée et bien argumentée elle peut être le "petit plus".

Cette première synthèse a pour but de présenter l'application à venir, mais quid des moyens ?

[modifier]