Discussion :

[zain.nadia]

Bonjour,

Je suis ingenieur en informatique mais ca fait prèsque 5 ans que j'ai pas pratiqué le developpement des logiciels. sachant que pendant nos études on fait les differentes étapes de developpement de logiciels mais on n'a pas utilsé des outils.
Je veux developper un logiciel de gestion de stocks mais je n'arrive pas à mettre un point de départ pour ce petit projet qui est trés important pour moi, ainsi que les différentes étapes en commencant par le cycle de vie du logiciel jusuqu'au test.

Veuiller bien m'orienter .

Bien cordialement

[Laurent 1973]

Bonjour,

Le sujet est bien vaste.
Je vais te donner une piste de réflexion en me basant sur un sujet de gestion de projet plus ou moins bien connu dans les études: l'Agilité (voir http://www.access-dev.com/access-dev...thodes-agiles/).

L'idée est de travaillé en un mode très itératif en avançant petit pas par petit pas.

Concrétement, si tu travaille seul, je t'invite à essayer de mettre en pratique cette sorte de feuille de route:

1. Etablir une liste de fonctionnalités avec les utilisateurs sans vous censurer
2. Classer ces fonctionnalités de la plus prioritaire à la plus folle
3. Revoir avec les utilisateurs la justesse de leurs descriptions - Ne bien décrire que les fonctionnalités les plus prioritaire
4. Choisir les premières fonctionnalité que tu pourrais réaliser en un courte durée de temps (1 à 2 semaine si tu es seul, c'est bien)
5. Ne développer que les fonctionnalités choisi et rien qu'elles
6. Réaliser les tests de ses fonctionnalités à mesure que tu les développes (je te conseille pour cela des tests automatisables et l’intégration continu)
7. A la fin de la période, présenter ton avancé au futures utilisateurs
8. Noter les remarques des utilisateurs
9. Enrichi ta liste de fonctionnalité des remarque et repart en 2 jusqu'à que tu penses que ton outil est utilisable en production - garde la liste des fonctionnalités restantes, elle peux servir pour une V2

Bon, j'ai pas mal résumé, mais je pense que l'essentiel est là.
L'idée de cette façon de faire est de considérer que vous n'avez pas forcement une vu précise de ce que vous voulez faire et que vous vous adapterez au fur et à mesure de l'avancer du projet.
Si cette façon de faire t’intéresse, n’hésite pas à te renseigner sur les méthodes Agiles.

Si cette outil est développé par une petite équipe, pourquoi pas alors vraiment mettre une méthodes Agiles (comme Scrum) en place.
Par contre, je te conseille alors de vous former voir même de vous faire accompagner par un Coatch Agile
L'Agilité est un changement d'esprit dans la gestion de projet et il est très facile de ce louper alors si on en a pas compris le réel sens.

[zain.nadia]

Bonjour,

Le sujet est bien vaste.
Je vais te donner une piste de réflexion en me basant sur un sujet de gestion de projet plus ou moins bien connu dans les études: l'Agilité (voir http://www.access-dev.com/access-dev...thodes-agiles/).

L'idée est de travaillé en un mode très itératif en avançant petit pas par petit pas.

Concrétement, si tu travaille seul, je t'invite à essayer de mettre en pratique cette sorte de feuille de route:

1. Etablir une liste de fonctionnalités avec les utilisateurs sans vous censurer
2. Classer ces fonctionnalités de la plus prioritaire à la plus folle
3. Revoir avec les utilisateurs la justesse de leurs descriptions - Ne bien décrire que les fonctionnalités les plus prioritaire
4. Choisir les premières fonctionnalité que tu pourrais réaliser en un courte durée de temps (1 à 2 semaine si tu es seul, c'est bien)
5. Ne développer que les fonctionnalités choisi et rien qu'elles
6. Réaliser les tests de ses fonctionnalités à mesure que tu les développes (je te conseille pour cela des tests automatisables et l’intégration continu)
7. A la fin de la période, présenter ton avancé au futures utilisateurs
8. Noter les remarques des utilisateurs
9. Enrichi ta liste de fonctionnalité des remarque et repart en 2 jusqu'à que tu penses que ton outil est utilisable en production - garde la liste des fonctionnalités restantes, elle peux servir pour une V2

Bon, j'ai pas mal résumé, mais je pense que l'essentiel est là.
L'idée de cette façon de faire est de considérer que vous n'avez pas forcement une vu précise de ce que vous voulez faire et que vous vous adapterez au fur et à mesure de l'avancer du projet.
Si cette façon de faire t’intéresse, n’hésite pas à te renseigner sur les méthodes Agiles.

Si cette outil est développé par une petite équipe, pourquoi pas alors vraiment mettre une méthodes Agiles (comme Scrum) en place.
Par contre, je te conseille alors de vous former voir même de vous faire accompagner par un Coatch Agile
L'Agilité est un changement d'esprit dans la gestion de projet et il est très facile de ce louper alors si on en a pas compris le réel sens.

Je commence à demmarer avec les notes que tu m'as noté
Merci bien

[el_slapper]

+1000 avec Laurent : l'ambition, ça finit toujours entre 4 planches. Mieux vaut commencer petit, avec juste un truc de base, facile à faire marcher, et qui rend déjà des services. Le fruit mur en bas de l'arbre. Une fois que ça marche, on peut essayer de rajouter des trucs, mais on a déjà quelque chose qui n'a pas couté beaucoup et qui rapporte de l'argent. Le risque est toujours plus grand quand on part dans l'effet tunnel, à vouloir faire un truc énorme en une seule fois, de se planter et de ne rien avoir du tout.

L'autre truc, c'est que si tu as plus de 1 utilisateur, tu auras besoin de persistance des données avec accès concurrent, donc une base de données. Et d'une interface pour taper dessus. Une bête table avec "identifiant, nom, quantité en stock" en colonnes, et un bête accès (client lourd ou léger, à toi de voir ce que tu maitrises le mieux, et ce qui convient à ta boite) pour consulter, ajouter ou ôter des éléments, me parait être un excellent point de départ. Puis, tu ajoutes des clochettes diverses en fonction des demandes des gens.

En oubliant pas de découper ton appli en 3 tiers : 1 tiers d'affichage, 1 tiers de "métier"(qui sera rachitique au début, mais si par exemple il est pertinent de regrouper certains articles entre eux, ça ira typiquement dans le métier), et 1 tiers accès aux données(avec juste les requêtes paramétrées).