Fórum Root.cz

Práce => Studium a uplatnění => Téma založeno: Samufaj 11. 06. 2015, 00:12:54

Název: Softwarové inženýrství - jaká je metodika?
Přispěvatel: Samufaj 11. 06. 2015, 00:12:54
Dobrý den,
 potřebuju opět pomoc. Budu státnicovat ze softwarového inženýrství. Za posledních X let, co se na moji VŠ učí, mám problém si udělat o procesu vývoji softwaru nějaký ucelený přehled. Příjde mi, že se u nás SWI vyučuje pořád jinak, stejné věci se jmenují jinak. Nejsem bifler, takže se mi to takto učí blbě.

1.) Potřebuju se naučit strukturovaně a detailně proces vývoje softwaru od sběru požadavků, po návrh, implementaci a testování.

2.) Pořád nějak nevím, kde se v soft. procesu používá business processing a jak přesně - ačkoliv jsem ten předmět měl a umím z něho hromadu grafů (používají se vůbec někde Petriho sítě?)

3.) Jaké použít UML diagramy a kde - a KDO ŘÍKÁ ŽE tam mají být použity. (vyletěl jsem na otázce, jaké UML diagramy se používají ve fázi sběru požadavků - řekl jsem UseCase a Sekvenční diagram (podle jedné RNDr. co mi tu otázku dávala tam nepatří, někde se ale zase píše že patří...)


Nemám s vývovojem SW nějakou pořádnou metodikou jaksi vůbec zkušenost. DOst by mi pomohla nějaká reálná a kompletní specifikace SW která proběhla v nějaké společnosti.

Díky
Název: Re:Softwarové inženýrství - jaká je metodika?
Přispěvatel: nobody 11. 06. 2015, 07:23:03
U 3. jste si mozna spletl User stories a Use case, Use case se tam samozrejme pouziva taky ale trochu jinak, pokud si myslite ze tam patri pak to musite vysvetlit jak jste to myslel. Sekvencni diagram opet muze byt jednoduchy pro popis nejake funkcnosti beznym uzivatelem a podruhe detailnejsi pro implementaci funkcionality programatorem. Ve fazi sberu pozadavku predevsim komunikujete s budoucim uzivatelem IS a ten neni programator.

Muzu se zeptat na jake skole studujete?
Název: Re:Softwarové inženýrství - jaká je metodika?
Přispěvatel: eMko 11. 06. 2015, 08:55:32
Tipl bych, že FEI VŠB-TUO - tento příspěvek mi nápadně připomíná borce, který tento týden přesně na tomto vyletěl od inženýrských státnic.  :(

Drobný rejpanec: UserStory není UML diagram - ta otázka od té ženské prý byla na UML diagramy. ;) Nicméně UserStory i UseCase samozřejmě patří do sběru požadavků (obecně UserStory u agilních metodik, UseCase u OpenUP a RUP).

UseCase je textový dokument s přesně definovanými náležitostmi (viz příklad: http://epf.eclipse.org/wikis/openup/core.tech.common.extend_supp/guidances/examples/use_case_spec_CD5DD9B1.html ); UseCase UML diagram zobrazuje pouze vztahy aktéři <-> případy užití a mezi případy užití samotnými, ale scénáře samotných případů užití nikoliv.

Samufaj: Dá se tam kromě UseCase diagramu (který se AFAIK může a nemusí dělat) použít i diagram aktivit. Sekvenční bych jim osobně řekl že ne, že to je spíš do návrhu.

V praxi platí, že pokud Ti pomůže v komunikaci se zákazníkem, tak ho udělej - pokud popisuješ business procesy pomocí UML, tak ten sekvenční lze použít (viz např. předmět MSPS). Jenomže škola není praxe a p*ča co v životě neviděla reálný projekt k tomu bude přistupovat jinak. Zkus zajít za Štolfou, který má vlastní firmu a slušnou praxi, ale ptej se ho na konkrétní otázky - je to totální bordelář a jeho studijní materiály, výklady, projev i přednášky se vyznačují extrémně vysokou mírou entropie ;D , což ale asi víš. Z odpovědi na obecnou otázku se nedozvíš nic, ale konkrétní otázky jsou v pohodě a fakt dokáže pomoct. (Měl jsem ho jako vedoucího diplomky ... no chvilu mi trvalo, než jsem si na jeho styl zvykl.)

Jinak Štolfa by IMHO na tuto otázku chtěl slyšet odpověď něco v tom smyslu, že výstupem fáze definice požadavků jsou artefakty (to slovo "artefakt" je pro něj důležité), které jsou v řádku "outputs" v tabulce v tomto dokumentu: http://epf.eclipse.org/wikis/openup/practice.tech.use_case_driven_dev.base/tasks/identify_and_outline_requirements_90D272B9.html?nodeId=e1fcc9d0

On je hodně zatížený na OpenUP, celý ten framework i s dokumentací najdeš tady: http://epf.eclipse.org/wikis/openup/
Je na to možno koukat jako na trochu odlehčenou (a bezplatnou) verzi Rational Unified Process a lze s tím pracovat i bez drahého a nákladného školení, nicméně se hodí jen pro menší týmy. Jo a není to agilní metodika, tam to probíhá jinak.

Petriho sítě jsem nikde při samotném vývoji softwaru neviděl použité. Ale při vývoji, validaci a optimalizacích byznys procesů ano - na základě takto optimalizovaných procesů můžeš vyvinout řídící software nebo informační systém. Těžko říct, jestli to u státnic zmiňovat či nikoliv.
Název: Re:Softwarové inženýrství - jaká je metodika?
Přispěvatel: nobody 11. 06. 2015, 09:26:40
omlouvam se za mystifikaci user stories != UML, blbe jsem si tu otazku precet :)
Název: Re:Softwarové inženýrství - jaká je metodika?
Přispěvatel: j 11. 06. 2015, 09:31:23
Kdyz to ctu ... a jak se obsluhuje koste vis? Nebo na to nejdriv budes delat analyzu a vyvojovej diagram?
Název: Re:Softwarové inženýrství - jaká je metodika?
Přispěvatel: Kolemjdouci 11. 06. 2015, 09:51:47
Kdyz to ctu ... a jak se obsluhuje koste vis? Nebo na to nejdriv budes delat analyzu a vyvojovej diagram?
Nějak často zapomínáš na ty prášky.
Název: Re:Softwarové inženýrství - jaká je metodika?
Přispěvatel: eMko 11. 06. 2015, 10:13:34
Kdyz to ctu ... a jak se obsluhuje koste vis? Nebo na to nejdriv budes delat analyzu a vyvojovej diagram?

Na obsluhu koštěte není potřeba žádná složitá analýza ani vývojový diagram, protože se nejedná o žádný vývoj.  :P

Ale diagram aktivit určitě bude potřeba, bo práce s koštětem zcela jistě aktivitou je. Statový diagram též, neboť je potřeba zachytit změnu stavu podlahy ze zaprášené na méně zaprášenou po každém máchnutí koštětem. Stejně jako zachytit opotřebení chlupů na koštěti... :D
Název: Re:Softwarové inženýrství - jaká je metodika?
Přispěvatel: karel 11. 06. 2015, 10:29:16
Kdyz to ctu ... a jak se obsluhuje koste vis? Nebo na to nejdriv budes delat analyzu a vyvojovej diagram?

co koště, ale žebřík
Název: Re:Softwarové inženýrství - jaká je metodika?
Přispěvatel: hawran diskuse 11. 06. 2015, 10:40:56
.... Stejně jako zachytit opotřebení chlupů na koštěti... :D

?
(http://www.filmmuseum-potsdam.de/images/30245_45939_Kopf_Saxana.jpg)
Název: Re:Softwarové inženýrství - jaká je metodika?
Přispěvatel: eMko 11. 06. 2015, 10:51:07
Cypi, vy si z toho děláte zadek. Ale co jste kurde čekali, že se bude učit na magisterském studiu? Jak napsat if/else v PHP, Javě a Pythonu? Nebo že na státnici se bude někdo ptát "Je podle vás lepší napsat otevírací závorku IFu na stejný řádek jako podmínku nebo na další?"

Stavaři na vysoké škole se taky neučí ovládat krumpáč, házet lopatou nebo stavět zdi. Ale počítají teoreticky, jak tlustá musí být nosná železobetonová stěna pokud v tom betonu bude tolik a tolik železné armatury... Že u rodiného domku to trefíš od oka? Supr. Ale u výškové budovy? Věř mi, budeš rád, že to projektoval někdo, kdo ten titul Ing. má.

Fakt, že celkem dost ajťáků tyto znalosti nepotřebuje a nevyužije ... je to až tak chyba školy? Všichni jsme přeci dostali možnost skončit už po bakaláři (nebo na školu vůbec nejít).
Název: Re:Softwarové inženýrství - jaká je metodika?
Přispěvatel: eMko 11. 06. 2015, 10:54:27
hawran: Tak k tomuhle koštěti potřebuješ (dle platných právních předpisů v ČR) ještě tento diagram (pokud letíš do Prahy): http://lis.rlp.cz/ais_data/aip/data/valid/a2-pr-ils06.pdf
Název: Re:Softwarové inženýrství - jaká je metodika?
Přispěvatel: P. 11. 06. 2015, 11:36:30
Pokud poletí podle VFR, tak je mu tenhle plánek k ničemu. Dost pochybuju, že koště má přístrojové vybavení a certifikaci pro lety dle IFR. Tím více pochybuji o kvalifikaci posádky na IFR :-))
Název: Re:Softwarové inženýrství - jaká je metodika?
Přispěvatel: eMko 11. 06. 2015, 11:38:52
I na LKPR se dá letět VFR ;)

http://lis.rlp.cz/ais_data/aip/data/valid/a2-pr-vfrc.pdf
Název: Re:Softwarové inženýrství - jaká je metodika?
Přispěvatel: Samufaj inkognito 11. 06. 2015, 12:06:11
Samozřejmě že se nejedná o VŠB-TUO a já nejsem ten týpek, je to podobnost čistě náhodná  8)

Tak například prof. Vondrák (shodou okolností je z VŠB) ve svých skriptech píše, že do fáze sběru požadavků patří Use Case a Sekvenční diagram.

http://vondrak.cs.vsb.cz/download/Uvod_do_softwaroveho_inzenyrstvi.pdf

Já to věděl, že jsem se to někde učil, kdybych si tak vzpomněl, že to bylo od Vondráka...
Název: Re:Softwarové inženýrství - jaká je metodika?
Přispěvatel: Samufaj inkognito 11. 06. 2015, 12:09:03
prof. Vondrák:

"Jazyk UML pro potřeby sestavení modelů specifikace požadavků využívá dvou typů
diagramů:
• Diagram případů užití popisující vztahy mezi aktéry a jednotlivými případy použití.
• Sekvenční diagram zobrazující vzájemnou interakci participujících objektů
organizovanou podle časového hlediska. "
Název: Re:Softwarové inženýrství - jaká je metodika?
Přispěvatel: hu 11. 06. 2015, 12:29:10
To jsou hrozny mrdky, panove...
Název: Re:Softwarové inženýrství - jaká je metodika?
Přispěvatel: eMko 11. 06. 2015, 12:53:17
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.  8)
Název: Re:Softwarové inženýrství - jaká je metodika?
Přispěvatel: cmyk 11. 06. 2015, 13:52:02
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?
Název: Re:Softwarové inženýrství - jaká je metodika?
Přispěvatel: j 11. 06. 2015, 18:56:53
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.
Název: Re:Softwarové inženýrství - jaká je metodika?
Přispěvatel: Cajova_Houba_2 11. 06. 2015, 19:36:33
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áš.
Název: Re:Softwarové inženýrství - jaká je metodika?
Přispěvatel: Korporatcik 11. 06. 2015, 19:42:38
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.
Název: Re:Softwarové inženýrství - jaká je metodika?
Přispěvatel: eMko 11. 06. 2015, 19:50:05
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 ...  :D 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

 ;D
Název: Re:Softwarové inženýrství - jaká je metodika?
Přispěvatel: Mirek Prýmek 11. 06. 2015, 20:19:58
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:

Citace
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 :)
Název: Re:Softwarové inženýrství - jaká je metodika?
Přispěvatel: Samufaj inkognito 11. 06. 2015, 20:56:49
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.
Název: Re:Softwarové inženýrství - jaká je metodika?
Přispěvatel: eMko 11. 06. 2015, 21:41:44

Citace
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. :D Ale ony ty procesní šílenosti mají taky svoje.
Název: Re:Softwarové inženýrství - jaká je metodika?
Přispěvatel: Mirek Prýmek 11. 06. 2015, 22:24:06
Řekl jsem si, že už to nechci a šel jsem do korporace. :D 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...
Název: Re:Softwarové inženýrství - jaká je metodika?
Přispěvatel: mon 11. 06. 2015, 23:22:34
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.
Název: Re:Softwarové inženýrství - jaká je metodika?
Přispěvatel: mon 11. 06. 2015, 23:34:37
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.
Název: Re:Softwarové inženýrství - jaká je metodika?
Přispěvatel: j 12. 06. 2015, 08:26:03
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.

Název: Re:Softwarové inženýrství - jaká je metodika?
Přispěvatel: PeVa 12. 06. 2015, 08:49:34
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ů.
Název: Re:Softwarové inženýrství - jaká je metodika?
Přispěvatel: mon 12. 06. 2015, 09:16:13
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ů.

jeden z principov co pomaha, je nerobit dokumentaciu 2x, takze je uplne zbytocne kreslit kod do uml, ked to vies vycitat z kodu, uml sa pouzivame na vyssi pohlad, ako medzi sebou komponenty komunikju, ktore package na co sluzia, klucove rozhrania a triedy. Treba najst ciaru a nekreslit co sa uz lahsie cita. vtedy je pouzitelne aj na vacsie projekty s desiatkami modulov tisickami obrazoviek a tisickami usecasov. len najst tu ciaru.

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.

no a to by ma zaujimalo kto ti prevezme velky projekt bez dokumentacie, spravit si ktomu analyzu je niekedy tazsie ako to napisat na novo (co sa niekedy neda, lebo by si musel preskolit tisice ludi), z pohladu cez naklady sa oplati robit uml priebezne... na jednoduche veci ako som pisal vysie sa uml ani neoplati a brzi iba.
Název: Re:Softwarové inženýrství - jaká je metodika?
Přispěvatel: cmyk 12. 06. 2015, 10:05:29
A je težké to následně udržovat, aby se tento model nerozjel od skutečnosti.
V tom vidim výhodu UML na úrovni class diagramů - nástroj typu EA by měl umět synchronizovat kód s modelem. Tzn. navrhnu model, ono to vygeneruje / upraví kostru projektu. Upravim kostru a ono to aktualizuje diagram. Je fakt, že dobře to podporuje Javu, trochu hůř C# a další jazyky jsem kloudně nerozjel (na EA nejsem školený, třeba to někdo umí).

Jak tohle funguje v praxi u středních a větších projektů? Prý v automotive umí programovat v C pomocí modelů v klikacích nástrojích.
Název: Re:Softwarové inženýrství - jaká je metodika?
Přispěvatel: eMko 12. 06. 2015, 14:43:19
Tohle jsem v praxi nikde využité neviděl a co jsem se ptal zkušenějších kolegů, tak to zavrhli jako něco, co přinese víc problémů než užitku. Setkal ses s tím někdy prosím na reálném (komerčním) projektu, případně jaké byly zkušenosti?

Na školních projektech nám to samozřejmě fungovalo, ale ... víš jak, škola není realita :)
Název: Re:Softwarové inženýrství - jaká je metodika?
Přispěvatel: j 12. 06. 2015, 16:58:28
no a to by ma zaujimalo kto ti prevezme velky projekt bez dokumentacie, spravit si ktomu analyzu je niekedy tazsie ako to napisat na novo (co sa niekedy neda, lebo by si musel preskolit tisice ludi), z pohladu cez naklady sa oplati robit uml priebezne... na jednoduche veci ako som pisal vysie sa uml ani neoplati a brzi iba.

Ja chci videt zakaznika, kterej ti to bude platit.

Vis jak tohle v 90% pripadu konci? U soudu. Dodavatel nacmare grafy, zakaznik to odkejve, protoze tomu kulovy rozumi, dodavatel neco naprga, ale zakaznik to nechce, protoze to nedela to, co chtel aby to delalo. Dodavatel se zacne ohanet grafama a chce dalsi prachy. Scimz ho zakaznik posle do rite.

A realita? Zakaznik rekne dodavateli rekneme ze chce zacit fungovat se seriovyma cislama zbozi. To je jeho zadani. Dodavatel si sam musi pozjistovat, co kde a jak funguje aktualne v zakanikove systemu, overit si, co je/neni mozny a nastrelit nejakou prevazne fixni cenu. Zakaznik nehodla platit zadny analyzovani a pokud to po nem bude dodavatel chtit, vybere si jinyho dodavatele. Nasledne to (v lepsim pripade) probiha tak, ze zakaznik ma Itka kterej vi jak jejich systemy fugujou, ten si sedne s programatorem dodavatele, kterej dorazi s nejakou pripravenou kostrou a rovnou na miste pise konkretni kod. Ve finale preda fungujici kod kterej dela co se chtelo a kdyz ma kliku, tak pozadovany prachy pokrejou naklady a vydela se. Kdyz ma smulu ... stravi na tom misto tejdne 1/2 roku.
Název: Re:Softwarové inženýrství - jaká je metodika?
Přispěvatel: mon 12. 06. 2015, 18:11:00
no a to by ma zaujimalo kto ti prevezme velky projekt bez dokumentacie, spravit si ktomu analyzu je niekedy tazsie ako to napisat na novo (co sa niekedy neda, lebo by si musel preskolit tisice ludi), z pohladu cez naklady sa oplati robit uml priebezne... na jednoduche veci ako som pisal vysie sa uml ani neoplati a brzi iba.

Ja chci videt zakaznika, kterej ti to bude platit.

Vis jak tohle v 90% pripadu konci? U soudu. Dodavatel nacmare grafy, zakaznik to odkejve, protoze tomu kulovy rozumi, dodavatel neco naprga, ale zakaznik to nechce, protoze to nedela to, co chtel aby to delalo. Dodavatel se zacne ohanet grafama a chce dalsi prachy. Scimz ho zakaznik posle do rite.

A realita? Zakaznik rekne dodavateli rekneme ze chce zacit fungovat se seriovyma cislama zbozi. To je jeho zadani. Dodavatel si sam musi pozjistovat, co kde a jak funguje aktualne v zakanikove systemu, overit si, co je/neni mozny a nastrelit nejakou prevazne fixni cenu. Zakaznik nehodla platit zadny analyzovani a pokud to po nem bude dodavatel chtit, vybere si jinyho dodavatele. Nasledne to (v lepsim pripade) probiha tak, ze zakaznik ma Itka kterej vi jak jejich systemy fugujou, ten si sedne s programatorem dodavatele, kterej dorazi s nejakou pripravenou kostrou a rovnou na miste pise konkretni kod. Ve finale preda fungujici kod kterej dela co se chtelo a kdyz ma kliku, tak pozadovany prachy pokrejou naklady a vydela se. Kdyz ma smulu ... stravi na tom misto tejdne 1/2 roku.

Zavisi od ludi, ja od subdodavatelov odmietam prevziat projekt bez dokumentacie, davame to do zmluvy a priebezne to kontrolujeme vystupy, pekne rozfazovane, vieme co kedy ako...

Ten sposob co tu popisuje je klasicky ceskoslovensky adhoc system prace, len robte a nic sa nestarajte. Nakoniec zakaznik dostane to co nechcel a este preplati neskutocne vela penazi. alebo dodavatel narazi na hubu a skrachuje (a nema kto robit maitenance). a napriklad itckara zrazi auto alebo odide inam (bus factor = 1) a konec. takto sa nerobi IT v dobrych firmach.

a navyse si sam protirecis tymyto vyrokmi "Zakaznik nehodla platit zadny analyzovani" a "Dodavatel si sam musi pozjistovat, co kde a jak funguje aktualne v zakanikove systemu" su uplne v protiklade a len blbec robi zadarmo....
Název: Re:Softwarové inženýrství - jaká je metodika?
Přispěvatel: mon 12. 06. 2015, 18:14:11
Tohle jsem v praxi nikde využité neviděl a co jsem se ptal zkušenějších kolegů, tak to zavrhli jako něco, co přinese víc problémů než užitku. Setkal ses s tím někdy prosím na reálném (komerčním) projektu, případně jaké byly zkušenosti?

Na školních projektech nám to samozřejmě fungovalo, ale ... víš jak, škola není realita :)

na co sa konkretne pytas?
Název: Re:Softwarové inženýrství - jaká je metodika?
Přispěvatel: eMko 12. 06. 2015, 19:02:32
Jestli cmyk ty popisované nástroje viděl použít na reálném projektu (čímž myslím ne školní projekt typu naprogramuj za 3 týdny, odevzdej a už se o to nestarej). Např. ve Visual Studiu (ve vyšších edicích) něco takového je a na školní projekt nám to fungovalo, ale (v 2010) to IMHO nebylo ve stavu, kde by se to dalo reálně použít.
Název: Re:Softwarové inženýrství - jaká je metodika?
Přispěvatel: mon 12. 06. 2015, 21:42:28
Jestli cmyk ty popisované nástroje viděl použít na reálném projektu (čímž myslím ne školní projekt typu naprogramuj za 3 týdny, odevzdej a už se o to nestarej). Např. ve Visual Studiu (ve vyšších edicích) něco takového je a na školní projekt nám to fungovalo, ale (v 2010) to IMHO nebylo ve stavu, kde by se to dalo reálně použít.

U nas uml pouzivame roky na komercne projekty s rozsahom tisice mandayov, ale aj na projekty kde je ich 50 a na mensie sa to moc neoplati, lebo to nema pridanu hodnotu. a pomaha aj pri maitenancoch a pri rotacii ludi to uml pomaha velmi. Uml nerobime aby bolo ale aby pomahalo..
Nikto napr nerobi class diagramy lebo to je v kode. To iba na skole ucia take blbosti.
Nastroje najprv sme mali rational rose a teraz par rokov uz sparx enterprise architect. Treba rozoznavat kreslitko (visio alebi vs) od izajstnych nastrojov ktore maju uml model a nie len diagramy a naozaj pomahaju hladat informacie.

A k teme metodika vyvoja nam ulahcila par veci, zlepsila planovanie a viac uzitocnych artefaktov zaviedla.