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

32

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é?

project

— Jonathan
source

2

Oui ............ Plus de complexité signifie plus de lignes de code.

— Robert Harvey

3

La première KLOC est le plus dur ...

Ensuite, vous devez vous demander "Qu'est-ce qui rend un projet complexe? Lignes de code? Couches d'abstraction?"

— Steven Evers

Vous mentionnez 1 000 lignes de code comme un «lot». Cela ne veut vraiment rien dire sans contexte. J'ai travaillé sur plusieurs projets qui avaient bien plus d'un million de lignes de code. J'ai également travaillé sur ce que j'appellerais des "petits" projets qui ne comptent que 50 000 lignes environ, mais en raison de la complexité, ils ne seraient pas considérés comme "petits" en raison de la quantité de ressources nécessaires pour concevoir, coder, et tester. Mais dans mon expérience personnelle, je ne peux penser à aucun cas où je considérerais 1000 lignes comme beaucoup. Je mentionne seulement cela pour donner une certaine perspective à votre premier projet. Bonne chance!

— TMarshall

Je dirais que la "grandeur" d'un projet dépend de plus d'un facteur ...

— kiwixz

20

Complexité.

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

5

Cela ressemble à une imo de tautologie. Un système complexe est synonyme de grand système; à moins de parler de complexité du code, il se peut très bien que tout soit bien découplé et ait une seule responsabilité, auquel cas la complexité du code pourrait en fait être plus faible pour les grands projets. Par conséquent, dire que la complexité signifie que le projet est grand ne signifie vraiment rien.

— Henrik

... ou naturellement toute autre mesure de complexité.

— Henrik

@Henrik, "système complexe" n'est pas équivalent à "grand système".

1

Non, c'est un synonyme.

— Henrik

@Henrik, je ne suis pas d'accord. Un système peut être volumineux mais régulier - c'est-à-dire que beaucoup de choses sont résolues de la même manière, où vous pouvez prédire comment les choses se feront en fonction de votre expérience avec le reste du système - et un système peut être petit mais toujours très complexe.

34

À 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.

— Joseph Weissman
source

4

Je voterais deux fois si possible. Les chiffres sont un peu arbitraires bien sûr, mais je pense que les descriptions de ce que les différents degrés de «bigness» impliquent sont parfaites.

— Eric Anderson

1

@EricAnderson Il est certainement plus facile de penser à cela en termes de descriptions que de mesure de sloc. Un programme Erlang 100k sloc est facilement d'un ordre de grandeur "plus grand" qu'un programme C ++ 100k sloc, simplement en fonction de ce qu'il fait, quelle que soit la facilité de lecture du code à un niveau supérieur. À un certain moment, la lecture du code n'est même pas aussi difficile que de se rappeler ce qui se passe à l'intérieur du système à un niveau élevé, car il y a tellement de fonctionnalités et de centres logiques.

— zxq9

@ zxq9 je sorte de désaccord. Certes, cela implique que le choix de la langue pourrait réduire la taille d'un grand projet. Ce qui était utilisé pour les gros ordinateurs est maintenant trop lent, et ce qui était utilisé pour les gros projets logiciels peut être trivial de nos jours. Ce qui est invariant, c'est le coût / la complexité d'un projet. Bien que le SLOC ne soit pas une mesure parfaite, il est toujours étroitement lié au coût et à la complexité d'un projet logiciel. - Tout comme les grosses machines ne sont pas nécessairement meilleures, les grands projets logiciels ne le sont pas non plus. Si possible, divisez un projet en composants indépendants et choisissez les bonnes technologies pour les rendre encore plus petits.

— Yongwei Wu

14

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

— mojuba
source

2

C'est pessimiste: D

— Henrik

.... et cette mesure est?

— Casey Patton

1

@Casey Patton la mesure est littéralement le coût de la maintenance.

— mojuba

12

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

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.
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.
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.

— JB King
source

11

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.

— David_001
source

1

Ce n'est peut-être pas une bonne mesure: les exigences pour les compilateurs et les noyaux de système d'exploitation peuvent être disproportionnées par rapport à d'autres types de produits.

— mojuba

2

@mojuba: "Big" est un terme assez large, j'imagine que l'écriture d'un compilateur ou d'un OS serait un "gros" projet

— David_001

@ David_001: prenez le compilateur Turbo Pascal, f.ex., dont la taille binaire à un moment donné était de 70 kilo-octets et pourtant TP était un langage de programmation orienté objet à part entière. Nous n'avons jamais vu les sources mais un exécutable de 70 Ko ne peut pas être un gros projet.

— mojuba

@ David_001: non pas que je sois complètement en désaccord avec vous en général. Toute définition d'un «grand» projet sera aussi vague que le mot «grand» lui-même.

— mojuba

@mojuba: Quand j'ai utilisé Turbo Pascal, il n'était pas du tout orienté objet.

— David Thornley

4

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.

— Dsimcha
source

3

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";)

— Henrik
source

2

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.

— Michael Riley - AKA Gunny
source

1

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).

— Kavet Kerek
source

1

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

Les facteurs sont:

Nombre de points d'extension
Nombre de couches de modules (fonctions, classes, systèmes de classes, bibliothèques, bibliothèques partagées, applications, applications réseau, etc.)
Nombre de dépendances (plates-formes incluses)
Comporte le nombre d'interdépendances.
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.

— Klaim
source

0

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.

— Jason Baker
source