Software engineering

Ahoj, zajímám o Software engineering, tedy hlavně o návrh softwaru (webových aplikací, stránek). Bohužel na většině diskusních webech se řeší hlavně samotné programování, ale o této problematice je psáno hodně málo nebo vůbec. Přitom v dnešní době vývoje softwaru tvoří softwarové inženýrství větší část času. Na internetu je celkem dost různých článků na toto téma a například i kniha od Jima Arlowa - Unified proces (http://www.dobre-knihy.cz/detail-75674/uml2.html) - tu bych určitě doporučil. Ale teď k tomu na co jsem se chtěl zeptat. Hledám nějaké fórum, kde se touto problematikou zaobiraj ve větší míře nebo dokonce specializované forum. Může být i v aj. Pokud někdo o něčem ví, určitě budu rád. Díky

Nazdar. Odkazujes na knihu, kde je popisane UML a pokial si dobre pametam aj RUP - Rational Unified Process . RUP je len jedna z metod vyvoja softveru. Skus sa pozriet napr. na Agilne programovanie, Extremne programovania, Scrum. Skus hladat podla tychto metod vyvoja .Pokial viem na www.builder.cz je konfera, ktora sa venuje OOP a UML. Neviem ako je ziva.

Diky za odpoved, i kdyz o techto metodykach vim. Spis mi slo o nejake to forum, kde se tyhle veci probiraj. Celkem rad takhle fora procitam, protoze je tam pohled na vsechny ty veci z praxe, coz v knihach uplne neni. Ale jinak diky:)

Ja k tomu jenom podotknu, ze umet programovat je zakladni vlastnosti dobreho sw inzenyra... Nikdy nemuzes velet necemu, cemu nerozumis aspon na urcity mire abstrakce, jinak to temer automaticky skonci katastrofou... K tomu, abys mohl urcovat procesy bys mel byt schopen sam danou vec do urcite miry z fleku udelat sam, protoze bez toho nejsi schopen odhadnout narocnost, at uz casovou, financni nebo na schopnosti konkretniho vyvojare...stejne tak volba procesu silne odpovida typu projektu a je jen na tvym citu, jestli fakt neudelas radsi nejakej rapid waterfall u malyho (zvladnutelnyho) projektu... nebo jestli nasadis extremni programovani... (oboji muze byt za urcite situace vhodne, za znacneho poctu situaci zase velmi nevhodne....)cili asi tak :-)jinak by se asi hodilo specifikovat, co si pod SWINGem predstavujes (navrh aplikace je zhruba stejny, jako kdybys napsal, ze te zajimaji "pocitace")...ja to studuju patym rokem a konkretni vymezeni bych si asi netroufnul ucinit...proste jestli ti jde o diagramovani (nejakou analyticitnu nebo design aplikace), management sw. projektu na urovni firmy nebo otevrenyho projektu, rubani kodu, architekturu aplikace.... vsechno je to SWING...a vsechno to delaj ponekud jini lide :-)

Jak jsem psal v prvnim prispevku, zajimal me hlavne navrh softwaru, coz je myslim v Softwarovem inzenyrstvi dost specificka cast. Jak rikas, ze si muzes navrh udelat sam, tak kdyby to takhle bylo, asi by zadnej navrh softwaru nemusel existovat ze? Samozrejme ze to asi neni treba delat, kdyz si delas doma blog s 2tridama a 3 scriptama, ale dle meho nazoru to od urcite velikosti aplikace dulezite je a zrejme si to nemyslim jen ja, kdyz ve vetsine firem jsou specialisti prave na analyzu a navrh softwaru. O tom jestli clovek co dela analyzu a navrh software ma take umet programovat by se dalo diskutovat.

ok, pokud ti jde o navrh jako navrh (tj. cisty design trid), tak rikam, ze vlastnost byt schopen to namlatit sam povazuju temer za nutnou :-), tohle proste vyzaduje rutinni znalost moznosti ty dany technologie, coz se imho nejde naucit z "prectu si prehled na foru". Pokud by slo o navrh ve smyslu business analyzy, tak tam bych tak prisny nebyl, ale stejne ten analytik musi vedet, kde ma cilova platforma rezervy/moznosti, aby zakaznikovi sliboval snadno splnitelne veci a ne trebas vypocty an graficky karte v Javovskym systemu...Pokud jde o architekta, tak tohle nejsem schopen zhodnotit...ale rekl bych, ze je jeho pozice presne uprostred...---proste dost zalezi na tom, co fakt dost presne budes finalne delat...obecne jenom upozornuju, ze bez znalosti tech technologii toho vetsinu delat proste nejde, jinak to hrozi znacnym prusvihem... nejde si na blogu precist o Scrumu a tvrdit, ze ses SW inzenyr... ty metodiky jsou berlicky pro zprocesovani ty aplikace, ale jeji navrzeni nijak neresej (krome velmi obecnejch principu). Jsem presvedcenej, ze ceste k SW inzenyrstvi vede jenom zespoda - dobry programator ma dobre predpoklady byt dobrym SW inzenyrem (at uz si predstavime analytika, architekta nebo designera kodu na "nejnizsi architektonicky urovni"), ale na druhou stranu je velmi obtizny naskocit do toho vlaku bez potrebnejch znalosti v oblasti programovani...(pokud ma nekdo rekneme vic prakticky zkusenosti, tak sem s nima, my poznatky jsou spis akademickyho razu...)---Jinak nikde netvrdim, ze by to mel dany clovek delat sam, jenom rikam, ze by toho mel byt schopen...to je docela velkej rozdil...

Tak souhlasim s tebou, ze by mel programator umet zaklady navrhu, aby si dovedl nejak sestavit par trid a spojit je mezi sebou a pripadne udelat celou business analyzu jednoduche aplikace. Nicmene jelikoz na to existujou specialisti, urcite bude jeho navrh ve velke vetsine horsi, coz se ale u male aplikace muze vicemene ztratit. Urcite je take jasne, ze dobry programator ma predpoklad ze bude i dobrym navrharem SW. Ovsem myslim si, ze na analyzu staci podstatne mensi znalosti programovani nez potom na samotne programovani. Na druhou stranu, kdyz detailne nerozumi programovani tak ani ta analyza nemuze byt uplne do nejvetsich detailu. V tom pripade bych asi volil konzultaci s odbornym programatorem, ktery bude pote provadet implementaci a v urcitych castech poradi.Myslim si, ze "nutnost" delat nejakou analyzu nastava v dobe kdy se do projektu zapojuje vice programatoru, aby se dal ten vyvoj nejakym zpusobem ridit.Ja jsem tu nepoptaval navod jak se ucit business analyzu nebo jednotlive metodiky (UP, waterfall atd.), ale pouze forum na kterem se tyhle veci probiraji. Osobne si nemyslim, ze nekdy budu delat analytika a ani po tom moc netouzim, ale chci si rozsirit znalosti i z toho duvodu, ze se hodi pro programovani. Jinak si myslim, ze programovat vicemene umim i kdyz zalezi z jakeho pohledu se na slovo "umet" clovek podiva:) zatim business analyzu pouzivam pouze ke svym ucelum na sve osobni projekty.----edit: jo a tim prvnim prispevkem jsem poptaval neco podobneho jako toto forum (ovsem kvalitnejsi):http://www.coderanch.com/forums/forums/show/40/42

pokud se bavime o navrhu aplikace, jakozto o designu, tak povazuju za dulezitou znalost predevstim nasledujiciho katalogu:http://martinfowler.com/eaaCatalog/a terbas techto stranekhttp://alistair.cockburn.us/jak Cockburn, tak Fowler se vyjadruji ke core otazkam SW inzenyrstvi...oba na svejch strankach resej jak high-level pohled, tak pomerne low level... Zvlast ty vzory enterprise aplikaci od Fowlera jsou fakticky bibli navrhu cehokoliv vetsiho. Ale opet si tam vsimnes, ze se tam resi primarne kod... to z toho duvodu, ze clovek musi vedet, co ta jeho architektura udela presne na urovni kodu... Kdyz se bavim se znamejma, jak postavit nejakej netrivialni system, tak taky zacneme nejakou high-level myslenkou, a pak vymejslime use-case z hlediska programatora, ktery to bud rozbijou nebo ne. A k tomu je zapotrebi docela dobra znalost technologii a prislusnyho programovaciho jazyka.Kdybychom to takto nedelali, tak nacmarame auto s plne automatickou prevodovkou, ale neuvedomime si, ze je obcas treba drzet motor na vysokejch otackach v danym use-case.---Jinak pokud to beres takhle, tak mas rozhodne spravnej pristup. Kazdej programator by mel umet cmarat UML a znat ty procesy, aby pak nebyl prekvapenej, kdyz to po nem nekdo bude driv nebo pozdeji vyzadovat na onech vetsich projektech, ktery jsou jinak nezvladnutelny.

zajimave clanky o analyze a OOPhttp://www.objects.cz/clanky/clanky.php