Hogyan lehet megfelelően megtervezni egy (nagyobb) projektet C Közösség

Jó estét fórum közösség,

csak szeretném tudni,
milyen trükkökkel és tippekkel követi nyomon a még nagyobb projekteket, és becsülje meg, mennyi időbe telik ez most,
hogy a befejezése közelében legyen.

Legyen szó a következő nagyszerű játékról vagy a világ legjobb operációs rendszeréről.
Valahogy ezeket biztosan meg kellett tervezni és megszervezni,
mert senki nem fog csak leülni egy ötlettel és elkezd programozni, amíg minden nem fér bele.

Hogyan strukturálja a tervezést?
Milyen mélyre kell menned a részletekbe?

Állítólag azok, akik ezt tervezik, a legtöbb pénzt keresik, mert ez nem olyan egyszerű. Leegyszerűsítve: a fő problémával ("operációs rendszer") kezdi, és 2 vagy 3 alproblémára bontja ("hardver" és "felhasználói felület"), amelyeket aztán két vagy három alproblémára bont és ezt addig csinál, amíg meg nem kapja valamikor elérkezett a programsorozatokhoz.

Valahogy ezeket biztosan meg kellett tervezni és megszervezni,
mert senki nem fog csak leülni egy ötlettel és elkezd programozni, amíg minden nem fér bele.

Sok projekt nagyjából ugyanúgy jön létre. Ez nem azt jelenti, hogy nem készül szoftvertervezés. De az egész projekt előre megtervezése, beleértve az időkeretet is, nagyon ritkán fordul elő, és ezután általában nem sikerül olyan jól.

ps: Nagyon hatalmas projektek alapján. A játékok nem hatalmas projektek, legalábbis nem akkor, ha kész motorra építenek. És a "közepes méretű" projektek meglehetősen jól megtervezhetők, különösen, ha valaki már ismeri a "tartományt".

Tehát korábbi tapasztalataim egyrészt azt mondják, hogy pontosan a fent leírtak szerint kell megterveznem, másrészt, hogy jobb, ha csak elkezdek prognózni, aztán törölni mindent, és minden hiba nélkül újra megcsinálni, mert valahogy hiányzik a gyakorlat, hogy mindent a nulláról tervezzek.

Másrészt csak azt gondolom, hogy nagyon alaposan el kellene gondolkodnom azon, hogy a program valójában mire képes. ha autót akarok építeni, akkor nem csak becsavarom, hanem elgondolkodom a követelményeken (melyik teljesítmény, melyik üzemanyag, első vagy hátsókerék-meghajtás.), tervezek, számolok, majd egy bizonyos ponton csavarják.

Tehát, ha maguk a módszerek érdeklik, akkor keressenek a "szoftvertervezés" kifejezésre az Amazon-on vagy a helyi egyetemi könyvtárban.

Csak akkor végezhet klasszikus felülről lefelé irányuló tervezést (vagyis az átfogó gondolattól a részletekig), ha rendelkezik átfogó áttekintéssel a projektről, és ki csinálja ezt? Ehhez korábban nagyon hasonló dolgot kellett volna tennie.

Ha nem ez a helyzet, fontolja meg inkább az alulról felfelé történő tervezést, először az alkatrészek megtervezését, használható prototípusok kifejlesztését (*), majd kitalálva, hogyan állítsa össze az egészet.

Valószínűleg itt is többféle ismétlésre lesz szükséged, amíg minden rendben van, de elkövetheted az igazán drága tervezési hibákat (annak felismerése felénél, hogy a teljes terv nem jó, vagy annyi időt tölthetsz az utolsó 10 százalékra, mint az első 90-re). remélhetőleg kerüljük el, ha csak akkor tervezzük meg a házat, ha funkcionális építőelemei vannak.

(*) A „használható prototípusok” azt jelentik: elegendő funkcionalitás, hogy valamit kezdjünk, de nem feltétlenül golyóálló minden helyzetben.

Másrészt csak azt gondolom, hogy nagyon alaposan el kellene gondolkodnom azon, hogy a program valójában mire képes.

Mit a programnak képesnek kell lennie arra (és mi nem) előre meg kell fontolni, ez így van. De el kell választanod mitől Mint.

ha autót akarok építeni, akkor nem csak becsavarom, hanem elgondolkodom a követelményeken (melyik teljesítmény, melyik üzemanyag, első vagy hátsókerék-meghajtás.), tervezek, számolok, majd egy bizonyos ponton csavarják.

Persze, akkor csinálod ezt, amikor korábban építettél autót, vagy amikor már tudod, hogyan szoktak építeni az autók, mert mások már sok autót építettek.

A legtöbb esetben (sajnos) először kérnek valamit, akkor gyorsan meg kell mutatni a képernyőmaszkot, majd a bólintás megadatik, és amikor a csupasz csontvázat húsra akasztják, mindenki kijön, aki csak előre bólintott, és rájön, hogy valójában annyiraoooo másra akarták.

Első dolgozatomhoz létre kellett hoznom egy programot, amelynek állítólag csupasz DOS felületen kellett alapulnia, de egyedi maszkokkal, kijelölő ablakokkal, felugró ablakokkal, vonalakkal, keretekkel, kényelmes vonalas szerkesztőkkel (egész számokkal és lebegőkkel elválasztva) és előre-hátra ugrással. egyes elemek.

Tehát a program alulról felfelé és felülről lefelé egyaránt növekedett. Először határozza meg alulról az alapvető alapelemeket és azokat, amelyek ezekre építenek. Pl. Négy vonalból álló vonal és négyzet.

Ugyanakkor bontsa felülről a programot az egyes alapelemekre, pl. A Main az egyes alapfunkciók kiválasztásával, majd ossza fel őket lépésről lépésre, amíg a "fent" és "lent" találkoznak. Ezután, ha szükséges, kódoljon 1-2 elemet minden szintről, hogy áttekintést kapjon a szükséges időről, és adja össze az összes elemet. És akkor ne felejtsen el puffert biztosítani az előre nem látható, tapasztalatoktól függően 10 - 100% -ig.

PS: Dr. Günter Rothardt a Szoftverfejlesztés gyakorlata című könyvet idézi, amely nagyon részletesen foglalkozott a témákkal. De 1987-ből származik, ezért alig érhető el. De talán van még kölcsönözhető könyvtár.

Azt is gondolom, hogy a fentről lefelé és az alulról felfelé történő kombináció a legjobb.
Ha csak felülről lefelé végez, akkor a technikai akadályokat túl későn fedezik fel, és fordítva, alulról felfelé, nincs alapvető ismerete a teljes architektúráról.
Különösen egy prototípus esetében fejlesztenie kell egy piercinget, amely az architektúrán alapul és már tartalmaz néhány technikai részletet.

De a projekt megtervezése nem csupán kódírás, hanem a szoftvertervezés (és egyéb nem technikai, például infrastruktúra, csapatkommunikáció stb.) Összes alcíme.

A képernyő maszk nem a "csupasz csontváz", éppen ellenkezőleg, a bőr, amelyet a végén ráhúznak. A projekt vezetőinek nem szabad ezt összekeverniük, és nem szabad hagyniuk, hogy a döntéshozók ezt elhiggyék.

A döntéshozók, akik csak bólintanak és nem tesznek fel kérdéseket, azt mutatják, hogy nem értették a projektet. Tapasztalt projektmenedzserek tudják, hogy és vágy a visszajelzés. Amikor a döntéshozókat arra kérik, hogy ne csak bólogassanak, hanem írjanak alá (nevükkel egy papírra), akkor általában felébrednek.

Köszönöm a sok nagyon hasznos választ.

Különösen a könyvtipp, de a vásárlás előtt először meglátom, hogy megtalálom-e a könyvtárban. Önmagában nagyon jónak tűnik.

Annak érdekében, hogy az egész megfontolást a tiszta elmélettől a kézzelfogható példáig vezessem, elkezdtem nagyjából egy "játékmotort".

Ha az itt említett alapkoncepciót ehhez viszonyítom, akkor az a top -> down tervezés volt.
Alul -> UP kiegészítés következne.
Amint ez elkészül, külön modulokat fejlesztenek ki, és szükség esetén kibővítik a teljes struktúrát.

Jól értettem, vagy itt hibáztam?

Van egy gyönyörű mondás, ami azt jelenti: "A kérdés az égről szólt, a válasz kötél volt".

Csak azt tudom, hogy vannak bizonyos bevált alapfelszerelések.
Például egy protokollfüzet tartalmi címzéssel vagy a (zsokerkerékhez hasonló) felmászás egy modell mentén, vagy munkaterv az x, y, z modell szerint.
Ez ugyanúgy megtehető, mint később az értékelések során.

A (bevált) elméleti modell helyett egy másik program használható modellként a szoftverekben. A táblázatok vagy az operációs rendszerek is kicsiben kezdődtek.

Az alapvető vázlatokról/tervekről nem tehetek papír és ceruza firkálás nélkül.

A programok esetében felmerül az a bosszantó kérdés is, hogy mi a legújabb (fő/hivatalos) kód, vagy hol voltam utoljára?
A megoldás itt is az átláthatóság - ami fegyelmezett vagy ritualizált viselkedésben is kifejezhető.

A jó tervezési segédanyagok továbbra is a plakátok és az A5-ös feljegyzések. A plakátok akkor is jól összeragadhatók, ha fali szélesség/királyméret felügyeletre van szükséged.

Annak érdekében, hogy az egész megfontolást a tiszta elmélettől a kézzelfogható példáig vezessem, elkezdtem nagyjából egy "játékmotort".

Azt hiszem, ez most megint más, mint amit eredetileg kértél. A követelmények és követelmények teljesen mások. A játékmotorral a szoftver tiszta felépítése foglalkozik. A projekt nagyon kezelhető, a lehetséges követelmények korlátozottak, és kevesebb az érintettje.
A "nagy" és valós projektekben messze nem csak az osztálydiagramok lehető legtisztább meghatározása a szabadban. A legtöbb probléma akkor fakad, hogy sokat kell tennie a kialakított struktúrákkal, ellentmondó követelményeknek, nem egyértelmű követelményeknek, minden olyan funkciónak, amely évtizedek óta létezik és zavarja az új követelményeket, de amelyektől nem szabadulhat meg fontos ügyfelek nélkül idegesíteni stb.

Valójában igen, de azt tapasztaltam, hogy a "döntéshozók" általában nem tudnak/akarnak tovább gondolkodni, mint egy színes kép.

Valójában igen, de amit megtanultam, az az, hogy a "döntéshozók" általában nem tudnak/akarnak tovább gondolkodni, mint egy színes kép. Különösen a közszolgálatban ez az alkalmazottaktól, orvosoktól és professzoroktól kezdve a minisztériumok felelős döntéshozóin át terjed.
A jól vezetett vállalatoknál a dolgok kicsit másképp alakulnak. De nem mindig. Mindenki szeretne valami színeset látni, mert megtalálja szépnek vagy nem szépnek.

Talán ez erős félreértést okoz. Például, ha olyan programra van szüksége, amely megmondja, hogy mire van képes, vagy leíró/egyhangú módon tud megállapodni a funkciókról - akkor a legfontosabbak a függvények/eszközök.
Például https://www.tipp10.com/de/
Itt elsősorban az alapvető funkciókról (gépelés megtanulása), az adatbázisról (javítás vagy hiányosságok rögzítése, statisztikák) vagy a költségekről van szó, és mindenekelőtt arról, hogy a program mint ilyen működik (nekem van egy hasonlóan működő Dos-Konsoleprg-m, de legalább olyan jó). Az a levegő-föld rakéta, amely bizonyos harckocsikat a földön ér, nem csoda funkció, annak kellene lennie.

Mikor jut eszükbe a Linux programozóinak, hogy az ablakalapú internetböngészővel rendelkező számítógépeknek nem szabad összeomlaniuk az ablakok mozgatásakor?
Ezzel kapcsolatban (a motorháztető alatt, összetett téma) feltétlenül meg kell állapítanom, hogy a Netscape böngésző több mint 20 évvel ezelőtt hibamentesen használható egérrel Unix rendszereken.
(Nem tudom, hogy van ma, vagy hiányzik egy fontos illesztőprogram a Unix rendszerekből, az egér nem működik, az internet nem működik (a modult nem ismerték fel stb.)
vagy a képernyő teljesen fekete marad. Az egér/Internet Nix a legelterjedtebb.)

Ekkor az első benyomás az marad, hogy a termék túl bonyolult vagy "nem működik", és csak vonakodva használja.
.
Ezután fejlesztőként kipróbálja a következő verziót
.
Ezután termékmenedzserek és tanácsadók jönnek az asztalhoz .

. És ezzel eljutottunk a 3. verzióhoz, eltelt egy év, és még mindig nem áll rendelkezésre semmi, ami megfelelő lenne az ügyfelek számára. Sajnos ez a szokásos eset, amikor a fejlesztők előállnak a termékkel, mert senki más nem akarja megtenni. Másnak kell lennie.

Amint meghozzák a döntést, hogy Ha a terméket fejleszteni kívánják, mindenkinek (termékmenedzsernek, tanácsadónak, értékesítésnek) hozzá kell adnia mustárját, és ezt azonnal meg kell tennie. Muszáj, ez a munkájuk része, nem merészkedhetnek csak ki. Amíg ez nem történt meg, a fejlesztés nem indul el, mert a követelmények még mindig nem tisztázottak, ez ilyen egyszerű Sorakoztassa a dolgokat a motorháztető alatt).

És ez a "mustár hozzáadása" sem egyirányú utca. Lekérdezéseket és megbeszéléseket lehet és kell is tenni. Gyakran az emberek nagyon különleges dolgokat kérdeznek: "Szeretnénk az XY gombot", és amikor rákérdezel, és belegondolsz, kiderül, hogy az XY még jobb egy legördülő listával.

Az ebben a fázisban említettek és fontosnak minősítettek (nem minden, amit egy egyéni tanácsadó fontosnak tart, valójában fontos - de ugyanez vonatkozik a fejlesztőkre is), a fejlesztői csapat prototípust épít. Bemutatásakor senki sem panaszkodhat arra, hogy "nem működik" - hacsak nem valóban a megbeszéltek szerint működik.

Különösen a könyvtipp, de a vásárlás előtt először meglátom, hogy megtalálom-e a könyvtárban. Önmagában nagyon jónak tűnik.

Kis kereséssel 4,95 euróért is megtalálhatja:
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
A legközelebbi könyvtárba való utazás drágább, és a saját polcán jó szakkönyvekkel kell rendelkeznie.

Amint meghozzák a döntést, hogy Ha a terméket fejleszteni kívánják, mindenkinek (termékmenedzsernek, tanácsadónak, értékesítőnek) hozzá kell adnia mustárát, és ezt azonnal meg kell tennie. Muszáj, ez a munkájuk része, nem merészkedhetnek csak ki. Amíg ez nem történt meg, a fejlesztés nem indul el, mert a követelmények még mindig nem egyértelműek, ez ilyen egyszerű.

Nem, nem. Kezdetben a követelmények általában nem egyértelműek, és idővel változnak is.

A téma címe: "Hogyan tervezzünk meg egy nagyobb projektet helyes?"

A megfelelő tervezés kezdetén pedig egyértelmű követelmények vannak. Amíg hiányoznak, nincsenek a jobb oldali Tervezés, csak bizonytalan tervezésmegpróbálja, amely bármikor újra összegyűjthető.

Ha ez mindenki számára világos (beleértve a menedzsmentet is), semmi nem akadályozza a fejlesztést abban, hogy "kijátsszon" és "megvalósíthatósági tanulmányokat" szervezzen, mert ennyi van benne. De ha a fejlesztés kap valamit a fedelén érte ("időt pazarolsz, és semmi sem származik belőle"), akkor itt az ideje, hogy visszakérdezzünk, hogy valójában mi várható, és mi legyen ki.

Nem lehet, hogy a fejlesztés elvégzi a termékmenedzsment/értékesítés/tanácsadás munkáját, és kitalálja, hogy mely tulajdonságokkal rendelkező termékekre lesz szükség a jövőben.