Як правильно спланувати (більший) проект C Community

Добрий вечір форумна спільнота,

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

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

Як ви структуруєте планування?
Наскільки глибоко слід вдаватися в подробиці?

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

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

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

ps: На основі справді величезних проектів. Ігри - це не величезні проекти, принаймні не тоді, коли ви будуєте на готовому двигуні. І "середні" проекти можна запланувати досить добре, особливо якщо хтось уже знайомий з "доменом".

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

З іншого боку, я просто думаю, що мені слід дуже ретельно продумати, що програма насправді повинна вміти робити. якщо я хочу побудувати автомобіль, я не просто накручую його, а продумую вимоги (яка потужність, яке паливо, передній або задній привід,.), планую, розраховую і тоді в якийсь момент він буде загвинчений.

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

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

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

Якщо це не так, натомість розгляньте планування знизу вгору, спершу розробляючи деталі, розробляючи корисні прототипи (*), а потім з’ясовуючи, як це все скласти.

Ймовірно, вам знадобиться кілька ітерацій і тут, поки все не буде добре, але ви можете допустити дійсно дорогі помилки планування (на півдорозі до усвідомлення того, що загальний план поганий, або витратити стільки часу на останні 10 відсотків, скільки на перші 90) сподіваємось, уникнути цього, плануючи будинок лише після того, як у вас є функціональні будівельні блоки.

(*) "Використовувані прототипи" означає: достатню функціональність для початку, але не обов'язково куленепробивну в будь-якій ситуації.

З іншого боку, я просто думаю, що мені слід дуже ретельно продумати, що програма насправді повинна вміти робити.

Що програма повинна вміти (а що ні) слід розглянути заздалегідь, це правильно. Але ви повинні відокремити те, від чого Як.

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

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

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

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

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

Одночасно розбийте програму зверху на окремі основні елементи, наприклад, Main з вибором окремих основних функцій, а потім поділіть їх поетапно, доки не зустрінуться «зверху» та «знизу». Потім, якщо потрібно, закодуйте 1-2 елементи з кожного рівня, щоб отримати огляд необхідного часу та скласти всі елементи. І тоді не забудьте надати буфер для непередбаченого, 10 - 100% залежно від досвіду.

PS: Доктор Гюнтер Ротхардт видав книгу "Практика програмного забезпечення", яка дуже детально розглядала ці теми. Але це з 1987 року і тому навряд чи доступне. Але, можливо, є ще бібліотеки для запозичення.

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

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

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

Екранна маска - це не "оголений скелет", навпаки, шкіра, яка натягується в кінці. Керівники проекту не повинні плутати це і не дозволяти тим, хто приймає рішення, вірити в це.

Особи, що приймають рішення, які лише кивають і не задають питань, показують, що вони не зрозуміли проекту. Досвідчені менеджери проектів знають, що і бажання зворотній зв'язок. Коли тих, хто приймає рішення, просять не просто кивати, а підписувати (з їх іменами на аркуші паперу), тоді вони зазвичай прокидаються.

Дякую за численні дуже корисні відповіді.

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

Для того, щоб перевести весь розгляд від чистої теорії до реального прикладу, я почав грубо планувати "ігровий движок".

Якщо я відношу основну концепцію, про яку тут було згадано, до цього, то це було планування зверху -> вниз.
Далі буде додано знизу -> Вгору.
Як тільки це буде завершено, окремі модулі будуть спеціально розроблені, а вся структура буде розширена, якщо це необхідно.

Я правильно це зрозумів чи тут помилився?

Існує прекрасна приказка, яка означає: "Питання було про небо, а відповідь - мотузка".

Я знаю лише, що існує певне випробуване базове обладнання.
Наприклад, буклет протоколу з адресацією вмісту або переміщенням (на кшталт жокеїв) вздовж моделі або робочого плану відповідно до моделі x, y, z.
Це можна зробити так само, як пізніше, наприклад, в оцінках.

Замість (перевіреної) теоретичної моделі в якості моделі в програмному забезпеченні може бути використана інша програма. Електронні таблиці або операційні системи також починалися з невеликих розмірів.

Що стосується основних чернеток/планів, я не можу обійтися без писання папером та олівцем.

У випадку програм також виникає прикрі питання, який є останній (основний/офіційний) код, або де я був востаннє?
Рішенням тут знову є прозорість - яка також може виражатися у дисциплінованій або ритуальній поведінці.

Хорошими допоміжними засобами для планування є плакати та нотатки А5. Плакати також можна добре склеїти, якщо вам потрібен контроль ширини стіни/розміру королів.

Я думаю, що зараз це знову щось інше, ніж те, про що ви спочатку просили. Вимоги та вимоги абсолютно різні. З ігровим двигуном вас турбує чистий дизайн програмного забезпечення. Проект є дуже керованим, можливі вимоги обмежені, і у вас менше зацікавлених сторін.
У "великих" та реальних проектах мова йде далеко не лише про визначення якомога чіткіших діаграм класів просто неба. Тоді більшість проблем випливає з того, що вам доведеться багато робити з вирощеними структурами, суперечать вимогам, незрозумілим вимогам, будь-яким функціям, які існують там десятиліттями і заважають новим вимогам, але яких ви не можете позбутися без важливих клієнтів засмучувати тощо.

Насправді так, але я дізнався, що "особи, що приймають рішення", як правило, не можуть/не хочуть думати далі, ніж кольорова картина.

Насправді так, але я дізнався, що "особи, що приймають рішення", як правило, не можуть/не хочуть думати далі, ніж кольорова картина. Зокрема, на державній службі це коливається від працівників, лікарів та професорів до відповідальних осіб, що приймають рішення в міністерствах.
У добре керованих компаніях справи йдуть трохи інакше. Але не завжди. Кожен хоче побачити щось барвисте, тому що може знайти це красивим чи не красивим.

Можливо, це породжує сильне непорозуміння. Наприклад, якщо вам потрібна програма, яка говорить, що вона повинна вміти робити, або ви можете домовитись про функції описово/одностайно - тоді функції/інструменти є найважливішими.
Наприклад https://www.tipp10.com/de/
Тут головним чином справа в основних функціях (навчити друкувати), базі даних (вдосконалення або прогалини, статистика) або витратах і, перш за все, в тому, що програма працює як така (у мене є консольна програма Dos, яка працює аналогічно, але принаймні так само добре). Ракета повітря-земля, яка вражає певні танки на землі, не є дивовижною функцією, вона повинна бути.

Коли програмісти Linux думають, що комп’ютери з віконним браузером не повинні виходити з ладу при переміщенні вікон?
Я повинен сказати про це (під капотом, складна тема) полягає в тому, що браузер Netscape можна використовувати без помилок за допомогою миші в системах Unix більше 20 років тому.
(Я не знаю, як це сьогодні, або в системах Unix відсутній важливий драйвер, миша не працює, Інтернет не працює (модуль не розпізнаний тощо)
або екран залишається повністю чорним. Миша/Інтернет Nix найпоширеніші.)

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

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

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

І те, що «додавання гірчиці» теж не є односторонньою вулицею. Запити та обговорення можна і потрібно робити. Часто люди запитують дуже особливі речі: "Ми хочемо кнопку XY", і коли ви запитаєте і задумаєтесь, виявляється, що XY ще кращий із випадаючим списком.

З огляду на те, що на цьому етапі згадується та класифікується як важливе (насправді важливим є не все, що окремий консультант вважає важливим - але те саме стосується розробників), команда розробників створює прототип. Коли він представлений, ніхто не може скаржитися на те, що він "не працює" - якщо це насправді не працює, як було обговорено.

З невеликим пошуком ви навіть можете знайти його за 4,95 євро:
https://www.amazon.de/Praxis-Softwareentwicklung-G%C3%BCnter-Rothhardt/dp/B0029GQ0ZW/ref=sr_1_2?s=books&ie=UTF8&qid=1518522238&sr=1-2
Поїздка до найближчої бібліотеки дорожча, і ви повинні мати хороші спеціалізовані книги на власній полиці.

Ні, не так. На початку вимоги, як правило, незрозумілі, а також змінюються з часом.

Заголовок теми "Як спланувати більший проект правильно?"

І на початку правильного планування є чіткі вимоги. Поки вони відсутні, їх немає правильний Планування, просто невпевнене плануваннянамагається, які можна зібрати знову в будь-який час.

Якщо це зрозуміло кожному (включаючи керівництво), ніщо не заважає розробці «пограти» та організувати «техніко-економічне обґрунтування», адже це все. Але якщо розробка завдає йому удару ("ви витрачаєте час, а з цього нічого не виходить"), настав час запитати, що насправді очікується і що повинно вийти.

Не може бути, щоб розробка робила роботу з управління продуктами/продажів/консалтингу і придумувала, які продукти, які властивості будуть потрібні в майбутньому.