Bon je creer ce topic suite à un petit debat sur l'Analyse et la programmation.
Au delà de la question de vocabulaire, qui y était question.
Je trouve qu'il n'est pas judicieux de creer une analyse independante des moyens techniques quand ceux ci sont connue!

En fait ce qui m'interroge c'est le fait de faire une analyse profonde pour quelques chose qui n'en a pas forcement besoin.

Car pour moi à part les choses techniquement pointu (IA, implementation 3d, generation fractal, creation d'une structure general etc...), il me semble inutile de passer par une phase d'Analyse profonde.

Peut etre le cour qui est en creation sur le wiki va repondre à toute ces questions. Enfin bref mon point de vue est assez fondé sur la chose malheureusement.

Zamentur a écrit :Je trouve qu'il n'est pas judicieux de creer une analyse independante des moyens techniques quand ceux ci sont connue!

Quand ceux-ci sont connus. Mais dans l'analyse, il faut justement également définir les moyens utilisés pour la réalisation du projet. Quels outils ? Pourquoi ces outils ?

Zamentur a écrit :En fait ce qui m'interroge c'est le fait de faire une analyse profonde pour quelques chose qui n'en a pas forcement besoin.

Je précise dans mon `cours' que le temps consacré à l'analyse, donc l'approfondissement de celle-ci, varie en fonction de l'importance du projet.

~L~

Donc je supose que tu concidere qu'à partir d'un moment de l'analyse on est dependant des moyens technologique choisit?

Parce que du coup j'arrive pas à mettre des frontieres précise entre la conceptualisation (pour nous le game design principalement) , l'analyse, et la programmation.

Pour moi, l'analyse fait partie de la programmation, ou l'inverse

En fait c'est sur ce point que je trouve çà floue, meme si je comprend les choses qu'englobent l'analyse

En tout cas j'attend la suite de ce cours... avec impatiente

Les phases de la gestion de projet :

• Initialisation : Examen du projet
• Préparation : Tous les acteurs vont se mettre d'accord sur les limites du travail à accomplir pour produire l'ouvrage recherché
• Planification : Définir le contenu technique, les coûts & les délais
• Pilotage
  • Lancement : Informer les instances & acteurs du projet du démarrage `officiel' de la `fabrication du produit'
  • Réalisation : Contient toutes les étapes de la production
    
• Clôture ( ou bilan ) : Tirer les enseignements des travaux réalisés
  

Question intéressante Zamentur

La réponse est simple... Tu l'as, mais tu ne place pas encore les bon terme dessus, je pense. Pour faire simple, il y a deux types d'analyses...
* L'analyse fonctionnelle
* L'analyse technique

Je pense que les terme sont plus que clair mais je détaille quand-même... L'analyse fonctionnelle est complètement indépendante de tes choix techniques. Elle définit le but du projet, les fonctionnalités offertes, ce qui ne fait pas partie du projet (trop peu oublié...), les scénarios d'utilisation de ton application. Dans le cadre du jeu, c'est ton Game Design. En fait partie la réalisation des interfaces. Pas au point de faire un site HTML, mais tu donnes déjà une idée de "pour tel scénario on a un formulaire qui demande ceci et ceci comme informations" (formulaire au sens fonctionnel du terme bien entendu!). Cette analyse tu peux facilement là faire avec des joueurs purs, qui n'y connaissent rien à la technique... A partir du moment où ton document est clair, même si tu suis une logique aves des termes "professionnels" (Use Case, Data Model...), un game designer peut (doit) le relire. Quelque part, il est ton client! C'est lui qui te fournit des "besoins" à traduire en un jeu... Dans notre cas, un besoin dont tu tiens déjà compte est le fait que ca soit un site web... Mais pas forcément que ce soit en PHP. Tu me suis?

Ensuite, viens l'analyste technique. Là, tu reprends chaque élément (scénarios, données...) de l'analyse fonctionnelle et tu décides par quel(s) moyen(s) technique tu va le réaliser. Tu dessisnes tes tables (si tu utilises une BDD), tu prévois les outils utilisés pour le développement, tu approfondis ton analyse fonctionnelle pour qu'elle soit utilisable par un "simple" programmeur.

Car en troisième lieu ton programmeur, il doit simplement prendre ton analyse technique et la traduire en code machine. Le programmeur n'a pas a se poser la question de savoir si le joueur peut "avoir 3 ou 4 chevaliers". Ca a été décidé dans l'analyse fonctionnelle, et répercuté dans l'analyse technique sous forme d'une règle au niveau de la "gestion des chevaliers". (Bête exemple!)

Et grossièrement, par rapport à ce que dit LexLxUs précédemment, l'analyste fonctionnelle est en phase de préparation, l'analyse technique en phase de planification et la programmation en phase de réalisation.

Mais chacun, chaque boîte, à sa méthodo... Je trouve par exemple que dans sa méthodo il manque une phase de test et de "production" (pour moi la production est l'installation en mode public et le lancement officiel du projet).

Petite intervention à deux balles

Citation :L'analyse fonctionnelle est complètement indépendante de tes choix techniques

Je dirais plutôt que l'analyse fonctionnelle impose des choix techniques (pas de 3D temps réel en PHP par exemple)

Roworll a écrit :Je dirais plutôt que l'analyse fonctionnelle impose des choix techniques (pas de 3D temps réel en PHP par exemple)

Ha non... Relis ce que tu dis "pas de 3D temps réel en PHP". C'est ton choix technique qui t'impose de ne pas utiliser de 3D en temps réel.

Rien ne t'empêche de faire un jeu sur site web avec de la 3D temps réel... Excellent exemple:
http://unity3d.com/

Au temps pour moi

J'ai oublié l'intégration après le pilotage. Dans mon tutoriel, je ne pense aborder le cycle de vie d'un projet informatique que en cascade. On trouverait à ma sauce personnelle - parce que je fais partie d'aucune boite - ce qui suit :

Etude préalable
-- Spécification
---- Etude technique
------ Réalisation
-------- Intégration
---------- Recette
------------ Déploiement

C'est le modèle le plus simple, mais on a qu'une seule phase de test. J'préfère des modèles plus `cycliques', ne serait-ce que en `W' - pour ceux à qui ça parle

~L~

N'étant pas sûr de comprendre correctement ton "recette", je l'aurais mis après le déploiement...

LexLxUs a écrit :J'préfère des modèles plus `cycliques', ne serait-ce que en `W' - pour ceux à qui ça parle

J'ai failli abordé le point de vue cyclique en prenant comme exemple la méthodo RUP mais je me suis dit on va en rester là "pour le moment"

Citation :je me suis dit on va en rester là "pour le moment"

Non, franchement, si tu peux approfondir vas y
Je suis très penché & j'connais pas mal de chose en Analyse, mais je reste sans expérience donc ce que je sais c'est le niveau scolaire & formation personnelle. Je suis plus analyste que programmeur donc en apprendre plus ça me fera plaisir.
En plus, les membres demandent du niveau dans le contenu. Ils demandent de se pencher sur autre chose que l'aspect purement technique de la conception .. Ils vont être servi. Mais beaucoup vont vite déchanter.

Je ne connaissais pas la méthode RUP. En faisant quelque recherche, j'découvre le développement agile. Je poursuis

[ EDIT ] Finalement, j'ai lu une explication du `développement agile', je connaissais ça. En même temps, c'est finalement le principe de base de toutes méthodes de gestion de projets, enfin aujourd'hui au moins Au moins, maintenant, je suis à même de mettre un nom dessus.
Concernant les méthodes, c'est pareil, j'en connais certaine. Le tout c'est encore - pour moi - de me souvenir des noms.
Rahlala. Tous ces anagrammes

~L~