Projet de création d'une application web

Bonjour tout le monde,

Je me permets de poster ici mon projet afin d'avoir vos avis, vos conseils, vos astuces pour que je puisse réaliser mon projet. Un travail long et conséquent m'attend pour les prochains mois et c'est avec beaucoup de motivation que je me lance sur cette voie. Je poste cela ici car j'ai surement vocation à ce que mon programme (s'il aboutit), devienne un logiciel open-source :)

Mon parcours et mes compétences :

Je suis diplômé en Astrophysique et de ce fait je manipule beaucoup l'outil informatique. N'ayant jamais eu de réels cours de programmation, j'ai pu apprendre à 99,99% par moi-même grâce au web... Je me suis très vite intéressé au langage Python qui pour moi, dans mon domaine m'offrait une "facilité" de codage que je n'ai pas retrouvé dans les autres langages. Je me débrouille donc un petit peu en Python, mais également en MySQL. Sur ce dernier, j'ai également appris par moi-même en faisant des tutoriels, essais, et je gère maintenant la base de données d'un logiciel ERP-CRM appelé "Dolibarr". Je m'attèle enfin à un troisième langage, proche du premier, qui est le framework Django. Pourquoi ? Parce que l'objectif de mon projet peut être réalisé de façon efficace avec ce framework et que j'ai déjà quelques connaissances Python ;) Vous me suivez jusque là ? Alors on passe au projet ..

Mon projet informatique :

J'ai pour projet de concevoir une application web permettant de gérer l'état civil d'une mairie. Cela sous-entend la création des différents actes municipaux (actes de naissance, mariage, ...), des fiches individuelles et familiales des personnes, les tables annuelles et décennales, une API de messagerie et d'agenda, ...

L'ensemble des documents PDF qui seront crées s'exporteront vers une GED (je pense à LogicalDoc car j'ai quelques connaissances sur ce logiciel open-source) pour sécuriser les documents, mais également faire office de bibliothèque d'archivage.

Une partie BackOffice sera développée pour tous le personnel de la mairie par exemple, et une partie FrontOffice sera accessible à toute personne se connectant sur le site de la mairie et pourra effectuer des demandes : prise de RDV, demande de copie ou d'extrait d'un acte, visualisation des infos de la mairie, ...

Les langages et technologies utilisées :

L'application web sera développée à l'aide du framework Django.

La base de données sera développée par MySQL ou MariaDB (préférence personnelle).

Le serveur d'application permettant de faire tourner cela sera sans aucuns doutes : Apache2.

Les ajax seront quant à eux développés à l'aide de jQuery (que je n'ai encore jamais manipulé).

Enfin, les modifications apportées à la GED seront effectuées avec Java.


Déroulement du projet :


J'ai commencé à travailler sur le projet depuis maintenant une semaine. N'ayant jamais développé de programmes (seulement des codes permettant la recherche en astrophysique : par ici (petite pub sur mon article récemment publié), je suis totalement novice sur la démarche à adopter pour s'organiser du mieux possible.

A travers différentes lectures, j'ai pu constater que l'on pouvait découper les phases de travail de la façon suivante :

- Ecrire des "Use Case" permettant de définir l'architecture globale du projet (phase que je suis entrain de finir)

- Recensement des différentes fonctions qui composeront le programme

- Définition de la base de données

- Phase d'écriture du code


Certains parlent également de schéma UML (j'avoue ne pas trop avoir compris la façon pour s'y prendre), ni si cela s'avère pertinent.



En réalité, je suis un peu perdu sur la façon dont je dois m'y prendre. N'ayant jamais eu un projet de la sorte, j'espère pouvoir être un petit peu guidé sur mes démarches de construction et de programmation ;)


Etat actuel de mon travail :

Je pense avoir fait un petit peu le tour des "Use Case" de mon projet côté API utilisateur. Certains nécessitent encore quelques améliorations/précisions. Est-ce un bon début de commencer par là ?

USE CASE GLOBAL :

Pièce jointe 225007

USE CASE FICHE INDIVIDUELLE :

Pièce jointe 225008

USE CASE FICHE FAMILIALE :

Pièce jointe 225009

USE CASE ACTES (à revoir) :

Pièce jointe 225010

USE CASE API GED :

Pièce jointe 225011

USE CASE TABLES ANNUELLES ET DECENNALES :

Pièce jointe 225012


Je suis actuellement entrain de réfléchir à toute la base de données derrière. Je pense que ce sera des tables plus ou moins indépendantes les unes des autres pour le moment, sauf quand on fera du requêtage par exemple pour avoir tous les actes d'une personnes.
Une fois ma BDD terminé, je m'attaquerai alors aux classes et objets à créer avant de commencer la programmation.

Suis-je toujours dans la bonne optique pour développer un programme ou me conseilleriez-vous une autre approche ?

Voilà pour mon projet, sa présentation et les objectifs que je me fixe.

J'espère qu'il correspond bien à la section, ainsi qu'à la philosophie du forum :)

En espérant vous lire, je vous remercie par avance,


Cordialement


Valentin

Citation:

---

Envoyé par Andromedae93

Suis-je toujours dans la bonne optique pour développer un programme ou me conseilleriez-vous une autre approche ?

---

La taille de ton projet est gigantesque pour un seul développeur, qui plus est débutant.

Je te conseille très fortement de te limiter au CRUD des fiches individuelles et de faire tout le roundtrip. En d'autres termes tu ne fais que ce use case et tu vas jusqu'à la production. Et dans la foulée tu automatises entièrement les déploiements de nouvelles versions. Ensuite tu rajoutes des fonctionnalités par itérations très courtes. Ne cherches surtout pas à faire tout d'un coup, ne te disperse pas, fais un focus total sur une fonctionnalité, va au bout du bout, jusqu'à l'utilisateur final, etc ...

Vu ton expérience, tu risques de retrouver rapidement confronté au problème des régressions lors de l'ajout de nouvelles fonctionnalités ou de corrections de bugs. Pallier à ce problème nécessite de l'expérience et de bonnes connaissances en génie logiciel, ce que tu n'as pas. Par contre c'est très formateur.

Je pense néanmoins que tu vas réaliser assez vite que tu as les yeux plus gros que le ventre. La taille de ton projet est réellement trop importante pour une seule personne. Donc démarre petit. Il vaut mieux livrer des petits bouts qui ont de la valeur que rien du tout. L'automatisation des livraisons est une des clefs critique pour le succès de ton projet. Tu dois avoir en bout de ligne un outil dans lequel tu saisis le tag (n° de version) que tu veux déployer ainsi que l'environnement (dev, intégration, preprod, prod, etc ...) et appuyer sur un bouton et hop c'est déployé avec BDD à jour et tout et tout.

EDIT : L'usage d'un SCM, git est probablement le meilleur choix possible pour ce type d'outils, est obligatoire. Notes que l'apprentissage seul de cet outil si tu pars de zéro te prendra plusieurs semaines en full time.

Bonjour Marco46,

Je suis très content qu'une personne de ton gabarit réponde à mon post avec des conseils et des remarques.

En réalité, nous sommes 2 diplômés de physique tout juste sorti de l'université avec ce projet commun. Nous avons quasiment les mêmes compétences dans les domaines énoncés plus haut. Il est vrai que c'est un projet TRES lourd, mais plusieurs raisons personnelles nous poussent à vouloir créer une petite appli web sur la base d'un Etat Civil.
Effectivement, nous pensions également partir sur une fonctionnalité (par exemple un acte de naissance) en allant du stade architecturale (use case, schéma BDD) jusqu'à l'utilisateur final sur l'API utilisateur.

Nous sommes conscient du travail à accomplir, mais la motivation ainsi que les précieux conseils de personnes de ton envergure ne peuvent que nous conforter dans notre choix de projet.
Nous travaillons également à l'aide de Git et Visual Studio pour ce projet. Une base de données MySQL sur un serveur distant qui accueillera l'application finale ainsi qu'une bonne dose de caféine !

Se limiter aux use case est-il problématique ou nous devons développer toute une architecture UML complète avant d'entamer le code selon toi ?
A l'heure actuelle, les use cases sont globalement terminés et le modèle de BDD également.

Merci encore à toi d'avoir pris le temps de nous répondre, en attendant de lire ton prochain message ou celui d'un autre utilisateur :)

C'est gentil pour la pommade mais je ne suis pas un très bon tu sais. J'ai juste de l'expérience et de la motivation :)

Les vrais bons ne lisent pas ces forums.

Bref, tout ça pour dire que faut avoir plusieurs sons de cloches j'ai pas la vérité vraie.

Pour répondre à ta question j'arrêterai avec UML et je développerai la partie READ d'un seul use case. Et j'irai jusqu'à présenter ce morceau à l'utilisateur final. Ensuite je rajouterai le UPDATE, puis le CREATE, puis le DELETE en présentant au user final à chaque étape.

Rien que sur ces 4 steps vous allez rencontrer un très grand nombre de problématiques extérieures au développement pur ça va vous prendre un temps fou, en particulier sur toute la partie infra et livraisons.

Mais au moins ça donne une cible réalisable et au terme de ces steps vous aurez du concret et vous devriez aussi avoir un processus de livraison stabilisé avec les environnements qui vont avec. Bref une usine logicielle. Ça prend un temps fou au début, mais c'est obligatoire parce que sur l'ensemble du projet ça fait gagner un temps fou.

Donc stop les schémas et le grattage de tête, il faut maintenant monter une usine et développer une première version, même si elle contient très peu de choses. Vous avez même pas besoin d'intégrer de système d'authentification pour le moment.

D'accord je comprends bien ce que tu veux dire.
De toute façon, je pense que nous sommes arrivés plus ou moins où l'on voulait avec les use cases et la petite modélisation de la BDD.

La prochaine étape arrivant à grand pas correspondait bien au codage du du premier modèle sous Django : instauration d'un formulaire directement connecté à la BDD et toutes les petites options gravitant autour de celui-ci. Puis, reprise des variables du formulaire pour les intégrer dans un 'texte à trous' en dur où les trous sont nos variables à insérer.

Pour l'histoire de la pommade, je ne me fiais qu'à ta description et tes statistiques sur le forum ;)

Merci pour ton aide ! Toujours prêt à recevoir des conseils de la part d'autres utilisateurs ;)

Citation:

---

Envoyé par Andromedae93

(.../...)La prochaine étape arrivant à grand pas correspondait bien au codage du du premier modèle sous Django : instauration d'un formulaire directement connecté à la BDD et toutes les petites options gravitant autour de celui-ci. Puis, reprise des variables du formulaire pour les intégrer dans un 'texte à trous' en dur où les trous sont nos variables à insérer.(.../...)

---

Marco46 me corrigera peut-être, mais ce qu'il veut dire, je crois, c'est que rien que là-dessus, vous allez taper pas mal de murs. et vous allez passer beaucoup de temps à corriger vôtre modèle de données. A l'usage, après des semaines de dur travail de debugging, vous vous rendrez compte que la vraie vie, ce n'est pas ce que vous imaginiez. Pas grave, vous allez faire encore mieux. Mais ça va vous demander beaucoup d'efforts.

Et c'est pour ça qu'il a raison : vous allez passer énormément de temps à remettre sur le métier vôtre ouvrage. C'est normal, ce n'est pas sale, c'est le cycle de vie normal d'un logiciel. Et pour pouvoir le faire, un gestionnaire de versions(pour revenir en arrière si vous avez tout cassé, ça arrive régulièrement), et un système de build automatique, c'est juste le strict minimum. Entre un build qui demande 30 minutes à la main, et un build qui demande 30 secondes d'un seul clic(pas deux : un seul), quand tu as 20 ou 30 aller-retour à faire entre le test et le dev, par composant, ben, c'est la différence entre deux jours de boulot et deux mois de boulot. La différence entre la vie et la mort du projet.

Après, quand vous serez plus gros, et aurez plus de retours client(ça peut arriver assez vite, genre quelques mois, peut-être même quelques semaines), un tracker de bugs devient indispensable aussi, genre Mantis. Son absence tuera le projet moins vite, mais le tuera quand même si vous persistez trop longtemps avec un tableur excel qui suit tout ça. J'adore EXCEL, mais c'est bien trop limité pour ça.

Pour un peu de théorie, les 12 points de Joel :

Citation:

---

1-Utilisez-vous un système de gestion de code source ?
2-Pouvez-vous faire un build en une seule étape ?
3-Faites-vous des builds quotidiens ?
4-Avez-vous une base de données de bugs ?
5-Corrigez-vous vos bugs avant d'écrire du nouveau code ?
6-Avez-vous un planning à jour ?
7-Avez-vous une spec ?
8-Les programmeurs bénéficient-ils d'un environnement de travail calme ?
9-Utilisez-vous les meilleurs outils que vous puissiez vous payer ?
10-Avez-vous des testeurs ?
11-Les candidats écrivent-ils du code pendant leur entretien d'embauche ?
12-Faites-vous des tests d'utilisabilité de couloir ?

---

Certains points sont excessifs à votre niveau(genre le 8, le 11, peut-être même le 9), mais les autres vous concernent déjà - maintenant ou dans les prochains mois.
Marco46 a insisté sur les points 1, 2, 3, je ne reviens pas dessus. J'ai évoqué le point 4 ci-dessus.

Le 5 est fondamental, et j'ai bien fait de rechercher de la théorie, je l'avais complètement oublié. Sans cela, on construit sur du sable.

Le 6 n'exige pas un planning féroce façon MS-project. Un bête Trello avec quelques post-it et des priorités suffit largement, à votre niveau, voire un word avec quelques lignes, mis à jour régulièrement. Mais c'est important. Ne serait-ce que pour vous souvenir de là ou vous en êtes et là ou vous allez.

Le 7, vous l'avez déjà. Préparez-vous à modifier la spec, mais c'est normal, ça fait partie du processus.

Le 10 est compliqué. Mais il vous faudra, tôt ou tard un regard extérieur sur vôtre produit, AVANT de le présenter aux clients. Et c'est pareil pour le 12. Des gens doivent essayer vôtre truc, et donner leur avis. Le point 10 concerne la chasse au bug tordu, le 12 l'utilisabilité pour qui ne connait pas vôtre look & feel. Mais ils reviennent au même concept : vous avez besoin de regards extérieurs sur votre produit. Quand on passe trop de temps sur un produit, on ne le voit même plus, et surtout pas ses défauts(le fameux proverbe de la paille et de la poutre).

8, 9, et 11, quand vous aurez grandi, deviendront critiques aussi. Mais pas avant.

Bonjour el_slaper et merci pour votre message.

Il est vrai que les premiers temps vont être très difficile ! Nous en sommes conscients mais il n'en sera que plus facile pour la suite d'apprendre de par ses erreurs. En revanche, qu'entends tu par un build ? Je n'ai pas cette notion dans mes connaissances et j'ai du mal à comprendre comment cela fonctionne, mais également de quelle manière le rendre le plus simple possible.

Le trackeur de bug, c'est une fonctionnalité dont je n'avais pas pensé (n'ayant jamais développé de programme), mais effectivement qui s'avèrera très utile pour corriger les problèmes rencontrés. Excel ne sera pas utilisé ;) Je vais rester avec sqlLite3 pour la partie de développement, et j'effectuerai une migration vers MySQL avant la prod. Je pense que limiter les problèmes et rester sur une voie au lieu de commencer à se diversifier sera bien plus judicieux.

Au niveau des différents points que vous avez abordé :

1) Gestion de code source : Visual Studio RC et Gitlab pour avoir un historique des modifications et un partage de code entre mon binôme et moi-même.

2) Reprise de ma question ci-dessus : qu'est-ce-qu'un build ? Cela correspond-il à la vérification de l'appli web sous http://localhost:8000/ ?

3) Même remarque que la 2

4) Elle sera complétée au fur et à mesure des problèmes rencontrés et corrigé également au fur et à mesure. Développer du code sans se soucier des erreurs déjà rencontrés, je ne trouve pas cela du tout intelligent.

5) Réponse identique à la 4

6) Nous nous fixons un 'ordre du jour' sur un tableau blanc, puis nous allons traiter l'objectif, analyser les éventuelles erreurs de code, puis une fois OK, nous passons à l'ordre du jour suivant. Nous tenons donc ainsi un petit planning (avec historique).

7) Nous avons déjà une spec : Vous entendez par là une architecture pré-établie du programme ?

8) Oui très ;)

9) Je pense. Visual Studio RC 2017 + Gitlab. Gratuit mais efficace selon moi pour débuter

10) Nous serons nous-même testeurs, mais nous avons entre 2 et 3 personnes pouvant effectuer des tests lorsque nous le souhaitons ;) Avec des compétences en IT architect, BDD analyst, ...

11) et 12) Je n'ai pas de réponses à donner :/

Voilà en gros pour répondre à votre message et faire avancer le projet :)

Merci d'avance ,

Citation:

---

Envoyé par Andromedae93

2) Reprise de ma question ci-dessus : qu'est-ce-qu'un build ? Cela correspond-il à la vérification de l'appli web sous http://localhost:8000/ ?

3) Même remarque que la 2

---

Un build c'est le livrable final qui sera déployé dans l'environnement de production. Par exemple un .jar en java, ou un .war avec un server d'application, ou du javascript minifié avec une appli web front. Bref ça dépend.

Généralement sur localhost on est sur un mode développement. Par exemple en web on va taper directement sur les sources pour debug plus facilement. Mais certains testent aussi leurs livrables dessus. Ca dépend. Ca fait partie de toutes les questions que vous devrez vous poser.

@el_slapper

"Marco46 me corrigera peut-être, mais ce qu'il veut dire, je crois, c'est que rien que là-dessus, vous allez taper pas mal de murs. "

C'est ça :)