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

mon

Re:Softwarové inženýrství - jaká je metodika?
« Odpověď #30 kdy: 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.


cmyk

Re:Softwarové inženýrství - jaká je metodika?
« Odpověď #31 kdy: 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.

eMko

  • ****
  • 456
    • Zobrazit profil
    • E-mail
Re:Softwarové inženýrství - jaká je metodika?
« Odpověď #32 kdy: 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 :)

j

Re:Softwarové inženýrství - jaká je metodika?
« Odpověď #33 kdy: 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.

mon

Re:Softwarové inženýrství - jaká je metodika?
« Odpověď #34 kdy: 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....


mon

Re:Softwarové inženýrství - jaká je metodika?
« Odpověď #35 kdy: 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?

eMko

  • ****
  • 456
    • Zobrazit profil
    • E-mail
Re:Softwarové inženýrství - jaká je metodika?
« Odpověď #36 kdy: 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.

mon

Re:Softwarové inženýrství - jaká je metodika?
« Odpověď #37 kdy: 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.