Softwarové inženýrství - jaká je metodika?

[hu]

To jsou hrozny mrdky, panove...

[Reklama]

[eMko]

No to teda. Ale na jiných školách to není jiné... ...rozhodně ne v ČR.

Samufaj: každopádně do příště přeji hodně štěstí a méně debilů v komisi. 

[cmyk]

Softwarové inž. je celkem užitečný předmět. Problém je, když tento praktický předmět učí teoretici.

Někdo se zkušenostmi z navazujícího oboru Softwarové inženýrství na FAV?

[j]

Stavaři na vysoké škole se taky neučí ovládat krumpáč, házet lopatou nebo stavět zdi. Ale počítají t...

Mas v tom zasadni chybu. Baraky se kupodivu ve skutecnosti stavej, stejne jako mosty a spousta dalsich veci => nekdo to spocitat musi.

Videl si nekdy jeden jedinej IT projekt, kde by se delalo neco ze zminenyho? Aspon JEDEN? Je to totiz prakticky presne totez, jako kdyby ses na ty VS ucil, jak funguje prenos osob ve Startreku. A zcela urcite (obzvlast pokud bys zkouknul vsechny dily co kdy byly natoceny) bys o tom moh zvanit hodiny a hodiny a hazet vsemoznejma uberterminama.

BTW: Autor odkazovanyho pdfka je podle vseho presne ten typ vedatora, kterej praxi vzivote nevidel.

[Cajova_Houba_2]

Stavaři na vysoké škole se taky neučí ovládat krumpáč, házet lopatou nebo stavět zdi. Ale počítají t...

Mas v tom zasadni chybu. Baraky se kupodivu ve skutecnosti stavej, stejne jako mosty a spousta dalsich veci => nekdo to spocitat musi.

Videl si nekdy jeden jedinej IT projekt, kde by se delalo neco ze zminenyho? Aspon JEDEN? Je to totiz prakticky presne totez, jako kdyby ses na ty VS ucil, jak funguje prenos osob ve Startreku. A zcela urcite (obzvlast pokud bys zkouknul vsechny dily co kdy byly natoceny) bys o tom moh zvanit hodiny a hodiny a hazet vsemoznejma uberterminama.

BTW: Autor odkazovanyho pdfka je podle vseho presne ten typ vedatora, kterej praxi vzivote nevidel.

Světe div se, ale tyhle metodiky se v praxi vážně používaj. Né 100%, ale v korporátní praxi to rozhodně neni tak, že přijdeš, řekneš že chceš kalkulačku, jejíž GUI bude zelený kolečko a za tejden to máš. Opravdu se dělá nějakej návrh, nějaký specifikace požadavků, nějaká analýza atd. A tam se věci jako UML diagramy a zjišťování co a jak to vlastně bude uživatel používat zkoumaj.

Vývoj pak neni tak chaotickej a když ti pak zákazník řekne, že takhle to nechtěl a bude chtít vrátit prachy, tak mu ukážeš podepsanou specifikaci požadavků, kterou ten SW splňuje a nabídneš mu, že mu to za další prachy předěláš.

[Reklama]

[Korporatcik]

A svete div se, i pri agilnim vyvoji se to da vyuzit, protoze to je prostredek komunikace. Ale je to jenom nastroj, takze je potreba premyslet, kdy jeho vyuziti neco prinese.

[eMko]

j: Odkazované PDFko je výcucem buď z Rational Unified Process nebo Open Unified Process. Nevím, kterého z nich a nejsem v náladě to zjišťovat (to by totiž znamenalo ty skripta číst). Měl bych se asi stydět, já vím ...  Jinak autora neznám - prošel jsem tou školou kombinovanou formou studia a tedy jsem ho nepotkal, tak se nebudu vyjadřovat - já měl ze všeho týkající se SWI Štolfu. Možná někdo jiný ... ? Nicméně je třeba mít na paměti, že se jedná o 13 let starý text, což v IT sféře je celá věčnost.

Každopádně popsané je hodně reálná věc, která nevznikla na vysokých školách, ale formalizací best practicies různých softwarových firem. A ano, znám projekty, kde se moho ze zmíněného dělá.

To, že někdo neslyšel o projektu, kde by se tyto metodiky použily, neznamená, že se nepoužívají. Jenom existuje celkem značné množství (převážně menších) firem, kam se tyto metodiky nehodí a použijí buď některou z agilních (což je vývojářům většinou příjemnější) nebo vůbec žádnou (typické pro start-up ... no a pak u toho často zůstanou). Ono totiž vys..at tunu dokumentů kvůli každé blbosti je ve firmách, kde se všichni znají, a na malých projektech, kde všichni většinu věcí udrží v hlavě, naprosto zbytečné. Představ si, že něco naspecifikuješ, pak se to změní - místo aby se ředitel otočil na programátora a řekl "tohle chce zákazník teďka takhle", tak se bude začínat se změnovým řízením, kde se změna formálně zapíše a zrevidují (aktualizují) se ostatní dokumenty? Tohle stojí hromadu času a pro firmu o 20 lidech je to často zbytečné - čas jsou peníze a těch nikdy není moc. Naproti tomu korporace, která má vývojový tým rozdělený do 5 míst, kde 2 jsou v severských zemích, 2 ve střední Evropě a 1 v Indii, je trochu jiná liga. Zvlášť když ten projekt běží třeba 20 let. Tam už žádný "Hele, Franto, udělej..." nefunguje. A hrabat se ve 20 let starým kódu a zapracovávat požadavek na změnu v místě, kde se nikdo neobtěžoval takovouto dokumentaci vytvořit (a ještě do toho kódu napsal komentáře ve Finštině) není sranda - ještě bys byl za RUP rád. Pro takovou korporaci skutečně bude levnější RUP použít, na rozdíl od malé firmy, kterou to může finančně položit. Korporaci by ale zase mohlo položit nemít ten proces nijak specifikovaný.

Tohle jsou moje zkušenosti. Tečka, nebudu to dále rozebírat. Tady to ani nemá smysl.

BTW asi před rokem jsem našel v C kódu tohle:

double yksi = 1.0; // tama koodi on paskaa

 

[Mirek Prýmek]

Tohle stojí hromadu času a pro firmu o 20 lidech je to často zbytečné - čas jsou peníze a těch nikdy není moc.

Imho už v počtu blížícím se 10 lidem začíná být aspoň nějaká dokumentace a specifikace potřeba. Třeba jenom proto, aby se vědělo, proč se tenkrát zvolilo tohle řešení nebo co vůbec je v jakým stadiu. "Udržet věc v hlavě" taky znamená, že dojde k situacím ala:

Lojza: Ty, Franto, to X nám nefunguje.
Pepa: Ale dyť Karel to testoval, ne?
Karel: Tohle jsem netestoval.
Eduard: Já jsem doteď žil v domění, že to je otestovaný.
Karel: Není a nikdy nebylo.

Mám čímdál silnější pocit, že takovejhle způsob vývoje je všechno jinýho jenom ne rychlej a levnej... Čímž nechci říct, že neexistují supermani, kteří to zvládnou, jedou a každej udělá přesně to, co udělat měl, ale že by to byla norma, tomu se mi věřit nechce

[Samufaj inkognito]

nemyslím, že ti lidi, co psali, že jsou to "mrdky" apod mysleli to, že SW specifikace je k ničemu. Mrdka je to, když RNDr dupe na něčem, co není pravda a čemu sama nerozumí a ještě je arogantní a rigidní. Když někdo vysvětlí petriho sítě a zkoušejícího ho dupe na tom, že neví, jak se říká těm "značkám", že to jsou tokeny - petriho sítě jsou, když už tak od toho, aby se používaly, ne aby nad nima někdo onanoval. Když takový člověk se raději rýpe v kravinách, místo aby zadal nějaký příklad který se má realizovat petriho sítěma - on asi sám nikdy nic takového nerealizoval.

Hold kvalita je i ve školství odvislá od platu, nestojí tam za nic, tak se člověk nemůže divit, že tam jsou samí kokoti.

[eMko]

Lojza: Ty, Franto, to X nám nefunguje.
Pepa: Ale dyť Karel to testoval, ne?
Karel: Tohle jsem netestoval.
Eduard: Já jsem doteď žil v domění, že to je otestovaný.
Karel: Není a nikdy nebylo.

Takhle to AFAIK většinou dopadá. Několikrát jsem to zažil a hádej, kam to ho*no padlo. Řekl jsem si, že už to nechci a šel jsem do korporace. Ale ony ty procesní šílenosti mají taky svoje.

[Mirek Prýmek]

Řekl jsem si, že už to nechci a šel jsem do korporace. Ale ony ty procesní šílenosti mají taky svoje.

Já (možná naivně) věřím, že i malej tým může fungovat dobře, když zvolí rozumnou míru rozumné metodiky (klidně správně nainmplementovanej selskej rozum). Akorát považuju za zcestný apriori vycházet z toho, že jsme mladí, nadšení, nic nepotřebujeme specifikovat a řídit a naše jediná metodika je release early, release often... Nevěřím tomu, že by to mohlo ve větším procentu případů fungovat, obzvlášť pokud se to spojí s "demokratičností" v tom smyslu, že i ten nejnezkušenější člen týmu kecá do všeho a nikdo neručí za nic...

[mon]

1) oplati sa pozriet tak OpenUP (http://epf.eclipse.org/wikis/openup/) to popisuje cely proces vyvoja sw, fazy, odporucania, guidy, artefakty.
Je ale ako metodika je to tool a language agnostic tak tam nenajdes UML, ale skoro vsetky popisujuce artefakty (nie projektove) spadaju dakam do UML modelu a daju sa namapovat na daky UML diagram.
Cele to je lightweight verzia RUP-u od IBM (v ramci trialu ibm rational method composer), ten to ma este podrobnejsie (ale oplati sa az pri vacsich timoch > 30 ludi)

2) tomuto nerozumiem co myslis "business processing"-om? ak sa mysli popis biznis procesov / scenarov tak pouziva sa to najma pri analyze existujucich procesov (as-is stav) a na navrh novych procesov, ktore ma projekt riesit (to be) a na zapis  sa pouziva BPMN. Petriho siete su cisto akademicka siet lebo su necitatelne zakaznikom a tazko neudrzatelne dodavatelom (moc podrobny a neprehladny zapis tam je).

3) UML nema requirement management (katalog poziadaviek), mozno za vlasy pritiahnuty usecase alebo object diagram, ale je to zly napad... vacsinou to maju tooly dako poriesene (vid. sparx ea)
poziadavky zakaznika sa mozu realizovat (ale nemusia) ale musia byt dokumentovane, co usecase alebo sequence diagram nesplna, to uz je navrh riesenia a nie analyza.

vseobecne v praxi pouzivas co sa ti prave hodi, najma sa pouzivaju:
- usecase - ake funkcie system poskytuje/bude poskytovat, to uz je vystup analyzy requirementov
- activity - na popis usecasov (aj ked vacsino u sa pouziva textova reprezentacia) a jednoduchych scenarov (aj ked tu sa skor pouziva uz BPMN)
- component - na popis architektury alebo vyssi pohlad na kod
- deployment - ako sa kde co nasadzuje, hw, sw, aplikacne servery, aplikacie, sietove linky medzi nimi
- class - na datove objekty  a nizsi pohlad na kod
tieto menej:
- sequence - na porobny popis interakcie medzi castami a uzivatelmi - tiez uz asi skor BPMN sa pouziva
- state - uz skor vynimocne, ak su zlozitejsie stavy objektu tak prechody medzi nimi a kedy sa robia tie prechody
ostatne diagramy su minorita, bud sa neoplatia alebo to ludia uz nevedia citat


Co sa tyka komplenteho tak to asi nikto neda len tak lebo to spada pod knowhow spolocnosti a hlavne NDA-cku.
 Mnozno skus dake priklady a ukazkove pripady k RUP hladat cez google.

[mon]

Stavaři na vysoké škole se taky neučí ovládat krumpáč, házet lopatou nebo stavět zdi. Ale počítají t...

Mas v tom zasadni chybu. Baraky se kupodivu ve skutecnosti stavej, stejne jako mosty a spousta dalsich veci => nekdo to spocitat musi.

Videl si nekdy jeden jedinej IT projekt, kde by se delalo neco ze zminenyho? Aspon JEDEN? Je to totiz prakticky presne totez, jako kdyby ses na ty VS ucil, jak funguje prenos osob ve Startreku. A zcela urcite (obzvlast pokud bys zkouknul vsechny dily co kdy byly natoceny) bys o tom moh zvanit hodiny a hodiny a hazet vsemoznejma uberterminama.

BTW: Autor odkazovanyho pdfka je podle vseho presne ten typ vedatora, kterej praxi vzivote nevidel.

Světe div se, ale tyhle metodiky se v praxi vážně používaj. Né 100%, ale v korporátní praxi to rozhodně neni tak, že přijdeš, řekneš že chceš kalkulačku, jejíž GUI bude zelený kolečko a za tejden to máš. Opravdu se dělá nějakej návrh, nějaký specifikace požadavků, nějaká analýza atd. A tam se věci jako UML diagramy a zjišťování co a jak to vlastně bude uživatel používat zkoumaj.

Vývoj pak neni tak chaotickej a když ti pak zákazník řekne, že takhle to nechtěl a bude chtít vrátit prachy, tak mu ukážeš podepsanou specifikaci požadavků, kterou ten SW splňuje a nabídneš mu, že mu to za další prachy předěláš.

je to idealny svet, ze sa pouzivaju, vacsina firiem ma scrum lebo je to trendy ale to je velmi slaba metoda na klasicke komercne projekty. mozno kombinacia scrum a uml, ale to je slabo definovane, co kde ako preco.
a robit to presne podla scrumu, no skuste dosiahnut konzensus na daco ked mate 20 vyvojarov a nepoznaju vsetci vsetko... to chce naozaj velmi skuseneho scrum mastra to uriadit a to vacsina ludi nie je...  a stale to neriesi dokumentaciu projektu, lebo user scenare su naozaj tazkopadna neorganizovana nic nevraviaca guca a ak sa ich pocet blizi k tisicom, to vam zakaznik ani nevezme.

nam pomohlo zavedienie openup-u. mali sme predtym (3 rokov) taku daku vlastnu metodiku, openup nam niektove veci viac sformalnil, terminy sa stihaju, malo nadcasov, lahsi maitenance. ludia na riadenie procesu nemusia byt supersikovni, lebo metodika dava presne postupy a  odporucania.

[j]

Heh ... korporatni praxe ...

Mam tu projekty, ktery se opakovane upravujou. Kdyz chci neco predelat, poslu dodavateli aktualni vstup, aktualni vystup a to, jak si preju aby ten vystup vypadal. Kdyby mi napsal, ze na to potrebuje nejdriv delat UML diagram, a ze to bude za 150 hodin prace, tak vymenim dodavatele.

[PeVa]

Mám s těmito UML docela zkušenosti, ale je zde jeden problém.
UML pěkně funguje na úrovni malých projektů,  kdy se to pěkně modeluje, jenže takové projekty je celkem jednoduché uřídit bez UML.
V momentě, kde je problematika a systém velmi rozsáhlý, tak vybudovat k tomuto plně dostačující technický popis pomocí UML, je dost pracné - stovky až tisíce diagramů, často pracnější než to naprogramovat. A je težké to následně udržovat, aby se tento model nerozjel od skutečnosti . Navíc není zajímavý nějaký povrchní všeobecný pohled, ale naopak technický popis detailu...a ten právě v modelu už třeba není. Mám zkušenost, že je lepší efektivnější pěkně a přehledně organizovat software, správně volit jmené konvence, package, adresáře. Takový systém je v podstatě samodokumentovaný a není potřeba to překreslovat do diagramů.