Was macht ein Projekt groß? [geschlossen]

Nur aus Neugier, was ist der Unterschied zwischen einem kleinen, mittleren und großen Projekt? Wird es durch Codezeilen oder Komplexität gemessen oder was?

Ich baue ein Tauschhandelssystem auf und habe bisher ungefähr 1000 Codezeilen für Login / Registrierung. Obwohl es viele LOC gibt, würde ich es nicht als großes Projekt betrachten, weil es nicht so komplex ist, obwohl dies mein erstes Projekt ist, also bin ich mir nicht sicher. Wie wird es gemessen?

Komplexität.

Je komplexer es ist, desto schwieriger ist es, alles im Projekt zu lernen.

Grob gesagt, wie ich die Dinge einordnen würde - denken Sie daran, dass dies mehr oder weniger willkürlich ist. Die "Größe" des Projekts in einer Kombination aus anderen Faktoren wie Komplexität, Quellcodezeilen, Anzahl der Funktionen / Geschäftswert usw. Ein sehr kleines Produkt kann eine große Menge an Wert usw. liefern.

• 2m + sloc ist ein großes bis großes Projekt. Diese sind im Allgemeinen so komplex, dass nur wenige, wenn überhaupt, das gesamte System „fließend“ beherrschen. Vielmehr tendiert die Verantwortung dazu, entlang der Struktur des Codes modularisiert zu werden. Diese Projekte bieten häufig einen enormen geschäftlichen Nutzen und können geschäftskritisch sein. Manchmal sind sie auch einer starken Belastung durch technische Schulden und andere Altlasten ausgesetzt.

• 100k - 2m sloc ist ein mittelgroßes Projekt. Dies ist mein Mittelweg: Das Projekt ist komplex genug, um Expertenwissen zu erfordern, und es hat wahrscheinlich ein gewisses Maß an technischen Schulden angehäuft. Es wird wahrscheinlich auch einen gewissen geschäftlichen Wert liefern.

• 10k - 100k ist ein kleines Projekt, aber nicht zu klein, um eine ausreichende Komplexität zu haben, die Sie als Experte in Betracht ziehen möchten. Wenn Sie Open Source sind, ziehen Sie in Betracht, vertrauenswürdige Personen dazu zu bewegen, Ihre Commits zu überprüfen.

• Alles was weniger als 10k Sloc ist, ist wirklich winzig. Das bedeutet nicht, dass es überhaupt keinen Wert liefern kann, und viele sehr interessante Projekte haben sehr kleine Abdrücke (z. B. Camping, dessen Quelle ~ 2 kb (!) Ist). Nicht-Experten können im Allgemeinen Wertprobleme lösen - Fehler beheben und Funktionen hinzufügen -, ohne zu viel über die Domäne wissen zu müssen.

Die Größe eines Projekts wird am Grad der Nichtwartbarkeit gemessen.

Komplexität, die auf verschiedene Arten eingeschätzt werden kann:

1. Budget. Ein Projekt mit einem Budget von über 10.000.000 USD unterscheidet sich wahrscheinlich erheblich von einem Projekt, das beispielsweise unter 10.000 USD liegt. Dies kann Arbeitskräfte, Software, Hardware und andere Kosten umfassen, die bei der Durchführung eines Projekts anfallen.
2. Person Arbeitsstunden, um das Projekt abzuschließen. Wird es eine Million Stunden dauern oder etwas anderes? Dies kann auch als Zeitfaktor angesehen werden, bei dem einige Projekte Jahre in Anspruch nehmen, von denen ich sagen würde, dass sie im Vergleich zu anderen Projekten, die weniger als eine Woche in Anspruch nehmen, groß sind. Beachten Sie, dass die Anzahl der Arbeitsstunden irreführend sein kann, wie jemand denkt, wenn er die Anzahl der Mitarbeiter verdoppelt, sodass doppelt so viele an dem Projekt arbeiten wie ich.
3. Menge an Hardware, anderen Systemen und Personen, die das Projekt nutzen. Wenn etwas in 101 Systeme eingebunden ist, ist es wahrscheinlich komplizierter, als wenn es allein steht und sich an nichts anderes bindet.

Anforderungen klingen zwar nach einer guten Methode, um dies zu messen, es gibt jedoch häufig weitere Anforderungen, die sich ergeben, wenn ein Projekt unter der Annahme einer Methode durchgeführt wird, die meines Erachtens keine Wasserfallmethode ist.

Eine Projektgröße lässt sich wahrscheinlich am besten an der Anzahl der Anforderungen des Systems messen, bei denen die Anforderungen nicht weiter reduziert werden können.

Mehr Anforderungen bedeuten natürlich meistens mehr Komplexität, aber das ist nicht immer der Fall.

Ich würde die Größe eines Projekts daran messen, wie schwierig es ist, das gesamte Projekt als ein einziges Gesamtbild zu sehen. Zum Beispiel habe ich eine Exploratory / Prototyping-Codebasis für ein maschinelles Lernproblem, an dem ich arbeite. Es sind nur 5.000 Codezeilen, aber es fühlt sich wie ein riesiges Projekt an. Es gibt unzählige Konfigurationsoptionen, die auf unvorhersehbare Weise interagieren. Sie können so gut wie jedes dem Menschen bekannte Entwurfsmuster irgendwo in der Codebasis finden, um all diese Komplexität zu bewältigen. Das Design ist oft suboptimal, weil das Ding durch die Evolution stark gewachsen ist und nicht so oft überarbeitet wurde, wie es sein sollte. Ich bin der einzige, der an dieser Codebasis arbeitet, aber ich bin oft überrascht, wie sich die Dinge gegenseitig beeinflussen.

Andererseits hat eines meiner Hobbyprojekte ungefähr 3-4x so viel Code und fühlt sich dennoch viel kleiner an, weil es im Grunde genommen eine Bibliothek mathematischer Funktionen ist, die meistens orthogonal zueinander sind. Die Dinge interagieren nicht auf komplexe Weise, und es ist schön, jede Funktion für sich zu verstehen. Es ist einfach, das Gesamtbild zu sehen, insofern es eines gibt, weil es nicht viel von einem gibt, das man sehen kann.

Willkürliche Antwort: Wie groß das Projekt ist, wünschten Sie sich, Sie hätten es von Anfang an mit Event-Sourcing und SOA gemacht. Oder dass die Autoren des Systems Evans Buch "DDD: Komplexität im Herzen von Software angehen" gelesen hatten;)

Compexity & Scope

Komplexität und Umfang bestimmen meines Erachtens, wie groß ein Projekt wirklich ist. Es gibt jedoch mehrere immaterielle Werte, die sich auch auf die Größe eines Projekts auswirken können.

Bedarf

Der größte Nachteil war der Mangel an Anforderungen. In meiner speziellen Situation bestimmte der Verkaufsleiter die Anforderungen. Sein Fokus lag auf dem Verkauf ... ich muss den Verkauf bekommen. In seinen Gedanken schien das, wonach der Kunde fragte, nicht allzu kompliziert zu sein, weil wir etwas Ähnliches gebaut hatten. Ungenaue Anforderungen führen zu unterbewerteten Arbeitsplätzen und zu übertriebenen Erwartungen.

Fehlen einer CCMU

CCMU ist das, was ich als " Coo Ca Moo " bezeichne (Clear Complete Mutual Understanding). Sie benötigen eine CCMU bei Ihrem Kunden.

Wenn Sie ein kleines Projekt mit einer schlechten CCMU haben, können Sie das Projekt 2,3,4 oder mehrmals abschließen. So wird aus einem einfachen 20-Stunden-Job ein 60-Stunden-Projekt mit einem gestressten Personal und einem sehr unzufriedenen Kunden.

Scope Creep

Dies passiert öfter als Sie denken. Der Kunde entscheidet, dass es nicht so schwierig sein sollte, D oder sogar F hinzuzufügen, da Sie bereits A, B und C ausführen. Wenn dieses Verhalten nicht aktiviert ist, kann es auch ein kleines Projekt in ein mittelgroßes Projekt verwandeln. Und je nachdem, wie der Verkaufsleiter den Auftrag verkauft hat, erscheinen diese Erwartungen an den Umfang des Einschleichens für den Kunden möglicherweise "KOSTENLOS" .

Es ist seltsam, viele dieser Antworten zu lesen, und ich sehe die Größe eines Projekts sehr unterschiedlich. Vielleicht arbeite ich in einem großen Unternehmen, aber ich neige dazu, die Größe eines Projekts eher als eine Skala seiner Sichtbarkeit / Wünschbarkeit für seine Kunden anzusehen (abhängig von Ihrem Arbeitsbereich können dies Mitarbeiter oder tatsächlich zahlende Kunden sein).

Komplexität ist die richtige Antwort, aber wie kann man sie einschätzen?

Faktoren sind:

1. Erweiterungspunkte zählen
2. Anzahl der Modulebenen (Funktionen, Klassen, Klassensysteme, Bibliotheken, gemeinsam genutzte Bibliotheken, Anwendungen, Netzwerkanwendungen usw.)
3. Abhängigkeiten zählen (Plattformen enthalten)
4. Verfügt über die Anzahl der Abhängigkeiten.
5. Erforderliche Ressourcen, die kein Code sind (einschließlich Grafiken / Grafiken, Treiberskripte - wie Level-Design-Skripte - und andere Ressourcen, die zum Vervollständigen einer Version der Anwendung erforderlich sind).

Je mehr davon Sie haben, desto komplexer ist das Projekt.

LOC ist für viele Messungen notorisch ungenau, aber ich denke, Sie versuchen, etwas zu messen, das es wirklich nicht genau gibt. Vielleicht könnte eine Alternative die zyklomatische Komplexität sein .

Letztendlich denke ich jedoch, dass die "Größe" eines Projekts schwer zu quantifizieren ist. Es ist fast so, als würden Sie fragen, wie Sie feststellen, ob ein Hund groß ist oder nicht. Es gibt nicht nur mehrere Möglichkeiten, es zu messen (Masse, Volumen usw.), sondern ich persönlich finde es nicht sehr nützlich. In Wirklichkeit lautet mein Kriterium wahrscheinlich: "Wie wahrscheinlich ist es, dass ich vor diesem Hund davonlaufe, wenn ich ihn in einer dunklen Gasse sehe?"

Und für die Aufzeichnung würde ich im Allgemeinen 1k Codezeilen nicht als viel betrachten. Es wäre ein ansehnlicher Teil des Codes sein, aber es wäre nicht , dass viel in dem großen Plan der Dinge. Ich nehme an, das hängt natürlich von der Sprache ab. Beispielsweise ist 1k Codezeilen in einer Sprache wie C viel weniger Code als in einer Sprache wie Pyhon.