Що робить проект великим? [зачинено]

Щойно з цікавості, в чому різниця між малим, середнім та великим розміром проекту? Чи вимірюється це рядками коду чи складності чи що?

Я будую систему бартерів і до цих пір маю близько 1000 рядків коду для входу / реєстрації. Незважаючи на те, що LOC є багато, я б не вважав це великим проектом, оскільки його не такий складний, хоча це мій перший проект, тому я не впевнений. Як вимірюється?

Складність.

Чим складніше, тим важче навчитися всьому в проекті.

Приблизно, як я погодився б на речі - майте на увазі, що це більш-менш довільно. «Розмір» проекту у складі інших факторів, таких як складність, вихідний рядок коду, кількість особливостей / цінність бізнесу тощо. Дуже невеликий продукт може доставити велику кількість цінності тощо.

• 2 м + проміжок - великий до величезний проект. Вони, як правило, настільки складні, що мало хто, якщо хтось «вільно» говорить у всій системі; швидше відповідальність, як правило, модулюється уздовж структури коду. Ці проекти часто дають величезну ділову цінність і можуть бути критично важливими для місії. Вони також іноді знаходяться під сильним напруженням технічної заборгованості та інших питань спадщини.

• 100 к - 2 м слот - це проект середнього розміру. Це моя середня позиція: проект досить складний, щоб вимагати певних експертних знань, і, ймовірно, накопичила певний ступінь технічної заборгованості; це, ймовірно, також надає певну ступінь ділової цінності.

• 10k - 100k - це невеликий проект, але не надто малий, щоб мати достатню складність, щоб ви хотіли розглянути експерт; якщо ви відкритий код, подумайте про те, щоб люди, яким ви довіряєте, переглядати ваші зобов’язання.

• Все, що менше 10 крок, справді крихітний. Це не означає, що він взагалі не може забезпечити будь-яку цінність, і багато дуже цікавих проектів мають дуже крихітний відбиток (наприклад, Camping, джерелом якого є ~ 2 kb (!)). Як правило, неексперти можуть викликати проблеми зі значенням - виправляти помилки та додавати функції - не знаючи надто багато про домен.

Розмір проекту вимірюється ступенем непорушності.

Складність, яку можна оцінити кількома способами:

1. Бюджет. Проект з бюджетом 10 000 000 доларів +, ймовірно, зовсім відрізняється від проекту, який, наприклад, становить менше 10 000 доларів. Сюди можна віднести витрати на оплату праці, програмне забезпечення, обладнання та інші витрати, пов'язані з виконанням проекту.
2. Особисті години роботи для завершення проекту. Це займе мільйон годин чи щось інше? Це також може розглядатися як фактор часового рядка, коли для деяких проектів можуть знадобитися роки, на які я б сказав, великі порівняно з іншими, які можуть зайняти менше тижня. Зауважте, що години роботи людини можуть вводити в оману, як хтось може подумати, подвоївши персонал, тому над проектом працює вдвічі більше, то графік можна розрізати навпіл, що рідко могло б працювати на мій погляд.
3. Кількість обладнання, інших систем та людей, які використовують те, що проект будує. Якщо щось зав'язується в 101 системі, то, швидше за все, це буде складніше, якщо він стоїть один і не пов'язаний ні з чим іншим.

Хоча вимоги можуть звучати як приємний спосіб виміряти це, часто є більше вимог, які будуть знайдені, оскільки проект робиться за умови методології, що не стосується водоспаду, я вважаю.

Розмір проекту, мабуть, найкраще вимірюється кількістю вимог, пред'явлених системою, де вимоги не можна знижувати далі.

Звичайно, більше вимог здебільшого означає більшу складність, але це не завжди так.

Я б виміряв розмір проекту тим, наскільки складно бачити весь проект як єдину велику картину. Наприклад, у мене є дослідницька / прототипова кодова база для проблеми машинного навчання, над якою я працюю. Це лише 5k рядків коду, але це здається величезним проектом. Є багато варіантів конфігурації, які взаємодіють непередбачувано. Ви можете знайти майже кожен шаблон дизайну, відомий людині десь у кодовій базі, щоб керувати всією цією складністю. Дизайн часто неоптимальний, тому що річ сильно зросла еволюцією і не відновлюється так часто, як належить. Я єдиний, хто працює на цій кодовій базі, але мене часто дивує взаємодія між собою.

З іншого боку, один з моїх хобі-проектів має приблизно 3-4 рази більше коду, і все ж він відчувається набагато меншим, оскільки це в основному бібліотека математичних функцій, які в основному ортогональні один одному. Речі не взаємодіють складно, і кожну функцію досить зрозуміло ізольовано. Неважко побачити велику картину в тій мірі, в якій вона є, тому що її не так багато.

Довільна відповідь: наскільки великий проект, наскільки ви хочете, щоб ви зробили це з пошуку подій та SOA з самого початку. Або що автори системи прочитали книгу Евана "DDD: вирішення складності в серці програмного забезпечення";)

Компетентність та сфера застосування

Складність та обсяг Я вважаю, саме це визначає, наскільки насправді великий проект. Однак є кілька нематеріальних ресурсів, які також можуть впливати на розмір проекту.

Вимоги

Найбільшим падінням, з яким я зіткнувся, було відсутність вимог. У моїй конкретній ситуації менеджер з продажу визначав вимоги. Його увага була зосереджена на продажу ... треба продати. На його думку, те, що просив замовник, не здавалося все складним, тому що ми побудували щось подібне. Неясні вимоги призводять до занижених робочих місць та надмірних очікувань.

Відсутність ЦКМУ

CCMU - це те, що я називаю " Coo Ca Moo " (Ясне повне взаєморозуміння). Вам потрібно мати CCMU зі своїм клієнтом.

Якщо у вас є невеликий проект із поганим CCMU, ви можете завершити виконання проекту 2,3,4 або більше разів. Таким чином, проста 20-годинна робота перетворюється на 60-годинний проект із напруженим персоналом та дуже незадоволеним клієнтом.

Область повзучості

Це трапляється частіше, ніж ви думаєте. Замовник вирішує, що оскільки ви вже робите A, B&C, вам не може бути так складно додати D або навіть F. Якщо така поведінка не перевірена, він також може перетворити невеликий проект у середній розмір. І залежно від того, як менеджер з продажу продавця проаналізував, ці очікування можуть бути "БЕЗКОШТОВНІ" для замовника.

Дивно, читаючи багато цих відповідей, я вважаю, що розмір проекту я бачу зовсім по-різному. Можливо, це моя робота у великій корпорації, але я схильний розглядати розмір проекту як більше масштаб його видимості / бажаності для своїх клієнтів (залежно від вашої сфери роботи, це можуть бути співробітники або фактично платні клієнти).

Складність - це правильна відповідь, але як її оцінити?

Факторами є:

1. Точки розширення рахуються
2. Кількість шарів модулів (функції, класи, класові системи, бібліотеки, спільні бібліотеки, програми, мережеві програми тощо)
3. Кількість залежностей (платформи включені)
4. Особливості взаємозалежності
5. Необхідні ресурси без коду (включаючи графіку / мистецтво, драйвери, як сценарії дизайну рівня - та інші ресурси, необхідні для заповнення версії програми).

Чим більше з них у вас є, тим складнішим є проект.

LOC, як відомо, є неточним для багатьох вимірювань, але я думаю, ви намагаєтеся виміряти щось, що насправді не є точним способом вимірювання. Можливо, альтернативою може бути цикломатична складність .

Зрештою, я думаю, що «масштабність» проекту важко оцінити. Це майже як запитання, як ти визначаєш, велика собака чи ні. Є не лише кілька способів її вимірювання (маса, об'єм тощо), але я особисто не вважаю це дуже корисним. Реальність полягає в тому, що мої критерії, ймовірно, будуть чимось на зразок "Яка ймовірність я бігти від цієї собаки, якщо я побачу її в темній алеї?"

І для запису, як правило, я б не вважав, що 1-х рядків коду дуже багато. Це був би великий шматок коду, але він не був би таким у великій схемі речей. Звичайно, я вважаю, що це залежить від мови. Наприклад, 1k рядків коду набагато менше коду в такій мові, як C, ніж у такій мові, як Pyhon.