Qu'est-ce qui fait qu'un projet est grand? [fermé]

Par curiosité, quelle est la différence entre un projet de petite, moyenne et grande taille? Est-il mesuré par des lignes de code ou de complexité ou quoi?

Je construis un système de troc et jusqu'à présent, j'ai environ 1000 lignes de code pour la connexion / l'enregistrement. Même s'il y a beaucoup de LOC, je ne le considérerais pas comme un grand projet car ce n'est pas si complexe que ce soit mon premier projet, donc je ne suis pas sûr. Comment est-il mesuré?

Complexité.

Plus il est complexe, plus il est difficile d'apprendre tout dans le projet.

À peu près comment j'accorderais les choses - gardez à l'esprit que c'est plus ou moins arbitraire. La "taille" du projet dans un ensemble d'autres facteurs tels que la complexité, les lignes de code source, le nombre de fonctionnalités / la valeur commerciale, etc. Un très petit produit peut fournir une grande valeur, etc. Cela étant dit:

• 2m + sloc est un projet de grande à grande envergure. Celles-ci sont généralement si complexes que peu ou pas de personnes «parlent couramment» l'ensemble du système; la responsabilité tend plutôt à être modulaire le long de la structure du code. Ces projets offrent souvent une énorme valeur commerciale et peuvent être essentiels à la mission. Ils sont également parfois soumis à une lourde pression de la dette technique et d'autres problèmes hérités.

• 100k - 2m sloc est un projet de taille moyenne. Ceci est mon juste milieu: le projet est suffisamment complexe pour nécessiter une certaine expertise et a probablement accumulé un certain degré de dette technique; il fournit probablement également un certain degré de valeur commerciale.

• 10k - 100k est un petit projet, mais pas trop petit pour avoir suffisamment de complexité que vous voudrez un examen expert; si vous êtes open source, pensez à demander aux personnes de confiance de revoir vos commits.

• Tout ce qui est inférieur à 10k sloc est minuscule, vraiment. Cela ne signifie pas qu'il ne peut pas apporter de valeur du tout, et de nombreux projets très intéressants ont une très petite empreinte (par exemple Camping, dont la source est ~ 2 ko (!)). Les non-experts peuvent généralement générer des problèmes de valeur - corriger des bogues et ajouter des fonctionnalités - sans avoir à en savoir trop sur le domaine.

La taille d'un projet est mesurée par le degré d'impraticabilité.

Complexité qui peut être estimée de plusieurs manières:

1. Budget. Un projet avec un budget de 10 000 000 $ et plus est probablement très différent d'un projet de moins de 10 000 $ par exemple. Cela peut inclure la main-d'œuvre, les logiciels, le matériel et les autres coûts engagés pour réaliser un projet.
2. Heures de travail pour terminer le projet. Cela prendra-t-il un million d'heures ou autre chose? Cela pourrait également être considéré comme un facteur chronologique où certains projets peuvent prendre des années que je dirais être gros par rapport à d'autres qui peuvent prendre moins d'une semaine. Notez que les heures-personnes peuvent être trompeuses comme quelqu'un peut le penser en doublant le personnel, donc il y a deux fois plus de personnes travaillant sur le projet, puis le calendrier peut être divisé par deux, ce qui me semble rarement fonctionner.
3. Quantité de matériel, d'autres systèmes et de personnes utilisant ce que le projet construit. Si quelque chose est lié à 101 systèmes, cela sera probablement plus compliqué que s'il est autonome et ne se rattache à rien d'autre.

Bien que les exigences puissent sembler une bonne façon de mesurer cela, il y a souvent plus d'exigences qui seront trouvées lorsqu'un projet est fait en supposant une méthodologie non-Waterfall je crois.

La taille d'un projet est probablement mieux mesurée par le nombre d'exigences du système, où les exigences ne peuvent pas être réduites davantage.

Bien sûr, plus les exigences principalement signifie plus de complexité, mais ce n'est pas toujours le cas.

Je mesurerais la taille d'un projet par la difficulté de voir l'ensemble du projet comme une seule grande image. Par exemple, j'ai une base de code exploratoire / de prototypage pour un problème d'apprentissage automatique sur lequel je travaille. Ce ne sont que 5 000 lignes de code, mais cela ressemble à un énorme projet. Il existe des tonnes d'options de configuration qui interagissent de manière imprévisible. Vous pouvez trouver à peu près tous les modèles de conception connus de l'homme quelque part dans la base de code pour gérer toute cette complexité. Le design est souvent sous-optimal car la chose a beaucoup grandi par évolution et n'est pas refactorisée aussi souvent qu'elle devrait l'être. Je suis le seul à travailler sur cette base de code, mais je suis souvent surpris par la façon dont les choses interagissent.

D'un autre côté, l'un de mes projets de loisirs a environ 3-4 fois plus de code, et pourtant il semble beaucoup plus petit car il s'agit essentiellement d'une bibliothèque de fonctions mathématiques qui sont pour la plupart orthogonales entre elles. Les choses n'interagissent pas de manière complexe, et c'est joli de comprendre chaque fonction isolément. Il est facile de voir la situation dans la mesure où il y en a une, car il n'y en a pas beaucoup à voir.

Réponse arbitraire: Quelle est l'ampleur du projet, combien vous souhaiteriez l'avoir fait avec le sourcing d'événements et SOA dès le départ. Ou que les auteurs du système avaient lu le livre d'Evan "DDD: Tackling Complexity in the Heart of Software";)

Compexity & Scope

Complexité et portée Je crois que c'est ce qui détermine la taille réelle d'un projet. Cependant, plusieurs actifs incorporels peuvent également affecter la taille d'un projet.

Exigences

Le plus gros problème que j'ai rencontré a été le manque d'exigences. Dans ma situation particulière, le directeur des ventes déterminait les besoins. Il se concentrait sur la vente ... je dois obtenir la vente. Dans son esprit, ce que le client demandait ne semblait pas si compliqué parce que nous avions construit quelque chose de similaire. Des exigences vagues conduisent à des emplois sous-évalués et à des attentes dépassées.

Absence d'un CCMU

CCMU est ce que j'appelle un " Coo Ca Moo " (Clear Complete Mutual Understanding). Vous devez avoir un CCMU avec votre client.

Si vous avez un petit projet avec un CCMU pauvre, vous pouvez terminer le projet 2,3,4 fois ou plus. Ainsi, un simple travail de 20 heures se transforme en un projet de 60 heures avec un personnel stressé et un client très insatisfait.

Fluage portée

Cela se produit plus souvent que vous ne le pensez. Le client décide que puisque vous faites déjà A, B & C, il ne devrait pas être si difficile d'ajouter D ou même F. Si ce comportement n'est pas vérifié, il peut également transformer un petit projet en projet de taille moyenne. Et selon la façon dont le directeur des ventes a vendu le travail, ces attentes de fluage peuvent sembler «GRATUITES» pour le client.

C'est étrange, en lisant beaucoup de ces réponses, je trouve que je vois la taille d'un projet très différemment. C'est peut-être mon travail dans une grande entreprise, mais j'ai tendance à voir la taille d'un projet comme davantage à l'échelle de sa visibilité / désirabilité pour ses clients (selon votre domaine de travail, ceux-ci peuvent être des collègues ou des clients payants réels).

La complexité est la bonne réponse, mais comment l'estimer?

Les facteurs sont:

1. Nombre de points d'extension
2. Nombre de couches de modules (fonctions, classes, systèmes de classes, bibliothèques, bibliothèques partagées, applications, applications réseau, etc.)
3. Nombre de dépendances (plates-formes incluses)
4. Comporte le nombre d'interdépendances.
5. Ressources non codées nécessaires (y compris graphiques / arts, scripts de pilotage - comme les scripts de conception de niveaux - et autres ressources requises pour terminer une version de l'application).

Plus vous en avez, plus le projet est complexe.

LOC est notoirement inexact pour de nombreuses mesures, mais je pense que vous essayez de mesurer quelque chose qu'il n'y a vraiment pas de moyen précis de mesurer. Une alternative pourrait être la complexité cyclomatique .

En fin de compte, je pense que la «grandeur» d'un projet est difficile à quantifier. C'est presque comme demander comment vous déterminez si un chien est grand ou non. Non seulement il existe plusieurs façons de le mesurer (masse, volume, etc.), mais personnellement, je ne le trouve pas très utile. La réalité est que mes critères vont probablement être quelque chose comme "Quelle est la probabilité que je fuie ce chien si je le vois dans une ruelle sombre?"

Et pour mémoire, je ne considérerais généralement pas 1k lignes de code comme beaucoup. Ce serait un gros morceau de code, mais il ne serait pas que beaucoup dans le grand schéma des choses. Bien sûr, je suppose que cela dépend de la langue. Par exemple, 1k lignes de code est beaucoup moins de code dans un langage comme C que dans un langage comme Pyhon.