Fórum Root.cz

Hlavní témata => Vývoj => Téma založeno: Pupi 18. 05. 2013, 17:43:38

Název: Životní cyklus software
Přispěvatel: Pupi 18. 05. 2013, 17:43:38
Ake metodologie alebo ake zivotne modely vyuzivate ci uz doma, ale asi skor v praci, ked vyvijate softver? Ktore sa vam najviac osvedcili/pacia? Stretli ste sa s tym?
Ja co som napr. brigadoval v 3 firmach, tak neviem ci mali nieco taketo zauzivane, ci im to teda aj nieco hovorilo - mozno ano, neviem. Sice bol som na poste programatora, ale to na tom nic nemeni. V jednej firme ma dokonca pobavil jeden typek tym, ze firma mala mat audit. Tak premyslali, ze ake otazky by mohli dostat a tak sa na ne pripravili. A dotycny zahlasil: "Aky pouzivame vyvojovy model? Vodopadovy, ci aky to tam je este model?" Bol som dost prekvapeny, ze nemali tam ziadnu takuto organizaciu, resp. nejaky ten vyvojovy model a to sa pracovalo na IS, ktory nebol maly. Ale po zahlaseni, ze vodopadovy, tak mi doslo, ze asi u nich nefunguje nieco podobne.
Vy mate s cim skusenost?
Název: Re:Zivotny cyklus software
Přispěvatel: nn 18. 05. 2013, 17:57:50
ja som este nikdy nic ako IS neprogramoval ale ja kodim tak, ze ked mam nejaky problem, tak si to riesenie zhruba nastrelim, potom to nejako zuslachtujem a napasujem na seba, par krat to zrefaktorujem aby to vyzeralo k svetu a potom tomu vychytam vsetky muchy. Cize taky nejaky iterativno-xp pristup :) samozrejme na vacsie veci uz treba nieco sofistikovanejsie ale na to co si kodim doma alebo nic vazne mi staci tento pristup, umlka som si este asi nekreslil ...
Název: Re:Zivotny cyklus software
Přispěvatel: nn 18. 05. 2013, 18:00:35
ja som este nikdy nic ako IS neprogramoval ale ja kodim tak, ze ked mam nejaky problem, tak si to riesenie zhruba nastrelim, potom to nejako zuslachtujem a napasujem na seba, par krat to zrefaktorujem aby to vyzeralo k svetu a potom tomu vychytam vsetky muchy. Cize taky nejaky iterativno-xp pristup :) samozrejme na vacsie veci uz treba nieco sofistikovanejsie ale na to co si kodim doma alebo nic vazne mi staci tento pristup, umlka som si este asi nekreslil ...

ide mi o to, aby som dosiahol "ciel" co najskor a potom sa od toho vsetko odvija, proste si navrhnem minimalne funkcne riesenie ktore sa principialne uz nebude menit a potom vsetko okolo toho tomu prisposobim, aby sa na to dalo pozerat a malo to hlavu a patu
Název: Re:Zivotny cyklus software
Přispěvatel: Franta <xkucf03/> 18. 05. 2013, 18:11:29
A dotycny zahlasil: "Aky pouzivame vyvojovy model? Vodopadovy, ci aky to tam je este model?" Bol som dost prekvapeny, ze nemali tam ziadnu takuto organizaciu, resp. nejaky ten vyvojovy model a to sa pracovalo na IS, ktory nebol maly. Ale po zahlaseni, ze vodopadovy, tak mi doslo, ze asi u nich nefunguje nieco podobne.

Vodopád nemusí být nutně špatně. Jen by si člověk (resp. firma) měl být vědom, jakým stylem vyvíjí a proč – mělo by to být opodstatněné a ne řízené náhodou.
Název: Re:Zivotny cyklus software
Přispěvatel: Pupi 18. 05. 2013, 18:13:36
no nemusi, ale moze to stazit pracu. Ale skor som tym narazal nato, ze nevedel co vobec pouzivaju. Len si spomenul asi zo skoly, ake modely su a napadol ho vodopadovy. Ani neviem ci sa tento model vyuziva v nejakej firme, pretoze moze narobit problemy, pokial nie su presne stanovene poziadavky.
Název: Re:Zivotny cyklus software
Přispěvatel: txt 18. 05. 2013, 18:33:51
To je kompetence projektového řízení. V malých firmách asi nebude samostatný projekťák, bude to část úvazku nějakého programátora. Nejde o to používat nějakou metodiku, ale aby činnost oddělení přispívala k zisku společnosti. Tzn. aby byl produkován takový software/služba, za který jsou zákazníci ochotni dostatečně zaplatit. Nasazení nějaké sofistikované metodiky může, ale nemusí zlepšit chod oddělení.

Nadruhou stranu vodopád to by IMO měl znát každej IT kojenec.
Název: Re:Zivotny cyklus software
Přispěvatel: Juro 18. 05. 2013, 20:02:34
Klasicka odpoved je, ze vhodna metodika zalezi od rozsahu projektu, rozpoctu, dlzky trvania, velkosti timu, poctu ucastnikov, ocakavanych vystupov, atd.

Robil som na viacerych projektoch, kde bol aplikovany v podstate klasicky vodopad a bolo to podla vsetkeho spravne riesenie. Robil som aj vo firme, kde bol oficialne RUP a robil som v firme, kde bol oficialne SCRUM + recomended TDD. Podla mojich skusenosti zavisi viac na schopnostiach manazmentu a programatorov nez na konkretnej metode vyvoja.

Podla mna plati nasledovne. Ked riadis maly tim, snaz sa vyuzit jeho silne stranky ako je rychlost a priamociarost komunikacie a bleskova spatna vazba. Plati na 100% "komunikacia pred procesmi". Tu mozu agilne metody ako SCRUM vela naucit a poskytnut zdarvy a rozumny ramec. Ked riadis velky projekt, silne sa zacne prejavovat prinos procesov a vseobecna znalost manazerskych technik, ktore idu nad ramec vyvoja SW resp. IT.

Nemusis to nazvat nijak, ale moje zdrave minimum je:
1. Mat dokument, kde su jasne napisane zakladne veci - co je ciel projektu, jeho rozsah, za akych okolnosti sa bude povazovat za uspesny, resp. co uz bude neuspech. Dalej zname rizika o ktorych sa vie uz na zaciatku (zakladny zoznam).
2. Mat dokladovatelnym sposobom toto schvalene.
3. Dbat na to, aby bol progres jasne viditelny. Stanovit si jasne a meratelne kriteria merania toho, ako daleko sme od ciela a priebezne prijmat korektivne akcie.
4. Postupovat iterativne a priebezne ziskavat spatnu vazbu od zadavatela/zakaznika. Robil som napr. to, ze som posadil do jednej prezentacky sefa obchodneho oddelenia a klucovych programatorov a ukazali sme vystup iteracie. Chalani potom lepsie dokazali pochopit, co je pre firmu dolezite a odputat sa od cisto technickych problemov a sef obchodu mal pocit, ze to smeruje tam, kde vie zuzitkovat vystupy.
Název: Re:Zivotny cyklus software
Přispěvatel: eMko 18. 05. 2013, 22:35:00
Nějaké malé věci stylu "napiš skript, který ..." nebo na školní projekty jednoznačně vodopád. TDD se snažím používat (je dobré mít testy - není nic horšího, než že se něco podělá den před deadlinem - napsané testy tomu zabrání/ulehčí dohledávání chyby), případně u LISPu nebo Pythonu tzv. "REPL-oriented programming", což je buzzword pro (zjednodušeně) interaktivní programování při běhu aplikace.

U normálních věcí v práci - jak kdy a jak co. Většinou jsem zažíval nějaký inkrementální vývoj ve více-méně pravidelných iteracích u zakázkového vývoje nebo v nepravidelných u generického. V jedné firmě jsme ten inkrementální vývoj nazývali jako SCRUM, protože to slovo se dobře prodává, ale do SCRUMU to reálně mělo celkem daleko. Tohle hodně záleží na projekťákovi a dost často je "na papíře" něco jiného, než reálně. Jinak XP jsem nezažil snad nikde a nevím o nikom, kdo ano (proč by měl zaměstnavatel platit dva lidi u jednoho kompu, když tam stačí jeden, že? ...), stejně tak automatické testy - ve firmě, kde pracuji, jsem si napsal unit test snad jednou, když jsem implementoval řidkou kolekci ("prázdná" data nejsou v databázi uložena, ale uživateli je musím zobrazit). Tam mi napsání testů prošlo, ale jen z toho titulu, že o tom projekťák neví a architektovi to nevadilo. Jinak na testy jsem slyšel argument, že to zbytečně zabírá čas, uživateli to nic nepřinese a co se týče chyb, tak je nemáme dělat (navíc opravy chyb se neproplácí a to ani tehdy, pokud prošly přes testery a objevily se až v produkci); a zcela jistě nejsme jediná firma, kde tohle platí.
Název: Re:Zivotny cyklus software
Přispěvatel: Pupi 18. 05. 2013, 23:58:50
ono nie je na skodu veci pouzivat nejake modely/metodiky. Prave u tych projektov, ktore su velke, by sa bez nejakych metodik/pravidiel nedalo zaobist. Tam je to jednoducho nevyhnutne. Nemohli by si dovolit nieco v zmysle, ze sa nieco "pokazi" a potom by sa musel prerabat cely navrh, cim by povodna implementacia skoncila niekde v kosi. Treba sa niecoho drzat. Mozno male firmy o pocte 3-4 programatori nieco taketo nepouzivaju, ba mozno niekedy ani nepoznaju. Firmy ako RetHat, IBM, MS a vela dalsich pouzivaju rozne metodiky, ale to je zrejme jasne.
Btw. vedeli by ste odporucit nejaku dobru, ci uz cesku alebo anglicku knizku co sa tyka tychto metodik/modelov. Nejaky zivotny cyklus softveru, projektovanie apod.?
Název: Re:Zivotny cyklus software
Přispěvatel: txt 19. 05. 2013, 00:44:22
Jak jistě víte, dnes jede procesní řízení (btw procesní řízení požadujou i normy ISO řady 9000). Takže je důležité mít správně nastavené procesy. Toho můžete dosáhnout selským rozumem, vyzobat si z metodik co považujete za užitečné, nebo se pokusit dopuntíku implementovat nějakou metodiku. Knih na tohle téma je spousta např.:

KADLEC, Václav. Agilní programování : Metodiky efektivního vývoje softwaru.Brno : Computer Press, 2004
PALETA, Petr. Co programátory ve škole neučí : aneb Softwarové inženýrství v reálné praxi.Brno : Computer Press, 2003

Zatím jsem na to neměl čas, ale dobře vypadaj přednášky předmětů SI1, SI2
https://edux.fit.cvut.cz/oppa/

Sem tam nějakej článek v časopisu Connect.

Dále není od věci, vědět něco o projektovém řízení obecně (to už se dostáváme mimo obor IT). U rozsáhlých projektů se používájí věci jako CPM, PERT. Součástí projektu je i řízení rizik. Uvedu některé metody používané v automotive, petrochemickém průmyslu atd.:
FTA, ETA, FME(C)A, HAZOP, markovova analýza.


Název: Re:Zivotny cyklus software
Přispěvatel: Pavel 'TIGER' Růžička 19. 05. 2013, 09:05:26
Nevím proč, ale hned jsem si vzpomněl na Cimrmana. 1. pád, Vodopád ... Tak ono také velmi záleží na tom, co se programuje. Jistě účetní program bude mít naprosto odlišný koncept, než program na převod nějakých jednotek. A podle toho se všechno odvíjí. Vodopád je pochopitelnej u jednorázovek, kde se nepočítá s nějakou aktualizací. Ale u toho účetního programu by to mohli hned zabalit. Díky našim vládám se účetní programy aktualizují častěji, než je zdrávo. Z toho jasně plyne, že odpověď nemůže být jednoznačná. Jsou firmy, které se zaměřují na jednorázovky, jsou firmy, které dělají dlouhodobé projekty a jsou firmy, co dělají obojí. Podle toho vypadají i jejich koncepty. Já osobně už se dlouhodobým projektům vyhýbám. Nesedí mi způsob, jakým se dnes dělají, ale to už je zase jiná kapitola.
Název: Re:Zivotny cyklus software
Přispěvatel: Pupi 19. 05. 2013, 10:41:50
txt:

vdaka za literaturu, ale to su publikacie, ktore su 10 rokov stare. nie je aj nieco novsie? netvrdim, ze nie su vyhovujuce, ale ak su tam nejaka zastarane trendy, tak by to chcelo nieco novsie.
Název: Re:Zivotny cyklus software
Přispěvatel: gamer 19. 05. 2013, 11:35:51
vdaka za literaturu, ale to su publikacie, ktore su 10 rokov stare.

Čemu to vadí? SCRUM vznikl v roce 1986 a stále se používá.
Název: Re:Zivotny cyklus software
Přispěvatel: perceptron 19. 05. 2013, 12:15:04
10 rokov v metodologii je este pomerne kratka doba. stale je kopa firiem, co o scrume sotva pocula. ale mozes si pogooglit nieco o "kanban"

Název: Re:Zivotny cyklus software
Přispěvatel: backup 19. 05. 2013, 12:53:34
Čemu to vadí? SCRUM vznikl v roce 1986 a stále se používá.

ne, metoda pokus-omyl vznikla uz na zacatku existence lidi.
Název: Re:Zivotny cyklus software
Přispěvatel: Pupi 19. 05. 2013, 15:00:11
no ved netvrdim, ze tie knizky su stare a nepouzitelne, len som myslel nejake novsie ci nie su, ktore su od nejakych ludi co maju s tym prax X rokov.
Název: Re:Zivotny cyklus software
Přispěvatel: eMko 19. 05. 2013, 15:12:23
Určitě se budou dát najít, ale nejspíš nelze čekat, že by se překládaly do češtiny / slovenštiny.
Název: Re:Zivotny cyklus software
Přispěvatel: Pupi 19. 05. 2013, 15:21:32
tak to mne neprekaza. mozu byt aj v EN.
Název: Re:Zivotny cyklus software
Přispěvatel: j 21. 05. 2013, 00:38:07
Jak jistě víte, dnes jede procesní řízení (btw procesní řízení požadujou i normy ISO řady 9000). Takže je důležité mít správně nastavené procesy. Toho můžete dosáhnout selským rozumem, vyzobat si z metodik co považujete za užitečné, nebo se pokusit dopuntíku implementovat nějakou metodiku. Knih na tohle téma je spousta např.:

O ISO radsi nemluv ... dycky se valim smichem, kdyz mi nekdo zacne vykladad ISO ... a jak to zvedne efektivitu a kdesi cosi ... stejne jako lecjakou firmu spolehlive polozi SAP, tak ISO na tom neni o moc hur. Zazil sem temer na vlastni kuzi ... (firma neprezila).

A samo, vetsi projekt je treba nejak "rozumne" ridit, potiz je, ze na to by tam musel byt nekdo, kdo tomu rozumi. Moh bych celkem dlouho (klidne i desitky stranek textu) sepisovat, jak taky muze takovy "IS" vypadat ... a vypadaji tak prakticky vsechny ... jmenuj a prinesu nejaky zazitek ...
Od takovych veci, jako nekonzistentne se chovajici GUI (nekde je tisk na F5 jinde na F8) pres neschopnost zajistit unikatni cislo (nejen) faktury ... k trebas pristupu k API, kde ti ho zmenej pod rukama, protoze dojdou k tomu ze "neco je spatne" ... a pak sou strasne prekvapeny, ze to APi taky nekdo trebas pouziva, a samo mu ta napojena aplikace prestane fungovat ... (a teprv kdyz na ne sproste rves a posilas na ne pravniky s tim, ze si ty miliony za prepis zaplatej, tak jim dojde, ze by to chtelo udelat prepinac verze s defaultne starym chovanim...)

Takze ja si nedelam vubec zadny iluze jak ten vyvoj vetsich projektu probiha, ja to totiz vim ... je tam hromada prasat, ktery mastej kod aniz by o tom premejslely a drtiva vetsina z nich ma problem napsat i fungujici cyklus (zcela na vlastni voci sem videl, jak vyvojar dava do kodu cca 10x totez cpy& paste, protoze to neumi/je linej/ jinak ...).

Samo, nekolikrat (tak 20x min) sem zazil, ze mi byla poslana modifikovana verze appky, ktera neumela to, co predchozi verze ... protoze dotycnej menil starou verzi kodu ... a ani JEDNOU se mi nestalo, ze by neco proste prislo a fungovalo to.

Kazdou verzi ISka pak nasazujem s minimalne 1/4 rocnim zpozdenim, a pokud nemusime tak vubec ne ... nebot cekame, az jini nebozaci odhali alespon ty zasadni chyby. Takova klasika je, ze s kazdou verzi nekomu zmizi nejaka ta prava ... takze trebas ucetni najednou nejde uctovat ...
Název: Re:Zivotny cyklus software
Přispěvatel: txt 22. 05. 2013, 18:30:29
O ISO radsi nemluv ... dycky se valim smichem, kdyz mi nekdo zacne vykladad ISO ... a jak to zvedne efektivitu a kdesi cosi ... stejne jako lecjakou firmu spolehlive polozi SAP, tak ISO na tom neni o moc hur. Zazil sem temer na vlastni kuzi ... (firma neprezila).
Je to svět směrnic, normalizace atd. a byrokracii je třeba držet na uzdě. Na druhou stranu lepší implementované ISO, než totální binec ve všem. Certifikát dobrou firmu nezaručí a naopak dobrá firma může být i bez certifikátu. I přes to averze vůči všemu co je ISO není zcela na místě.
Zažil jsem v elektrotechnickém průmyslu firmu, kde byli vcelku průměrní zaměstnanci nepostradatelní, protože pouze oni věděli věci, které by správně měli být v dokumentaci. Také jsem zažil firmy, kde ISO bylo a dokumentace byla taková, že zaškolit nového člověka na dané místo nebyl problém.

A samo, vetsi projekt je treba nejak "rozumne" ridit, potiz je, ze na to by tam musel byt nekdo, kdo tomu rozumi. Moh bych celkem dlouho (klidne i desitky stranek textu) sepisovat, jak taky muze takovy "IS" vypadat ... a vypadaji tak prakticky vsechny ... jmenuj a prinesu nejaky zazitek ...
Zde si neodpustím rýpanec, že technici si často myslí, že jsou mistři světa, ale manažerské kompetence mají zakrnělé a považují je za znalost „dementů z podřadných škol“. (viz  jiná vlákna, reagovat prosím konstruktivně)

Kazdou verzi ISka pak nasazujem s minimalne 1/4 rocnim zpozdenim, a pokud nemusime tak vubec ne ... nebot cekame, az jini nebozaci odhali alespon ty zasadni chyby. Takova klasika je, ze s kazdou verzi nekomu zmizi nejaka ta prava ... takze trebas ucetni najednou nejde uctovat ...
Určitě existují i firmy, které fungují lépe.
Název: Re:Životní cyklus software
Přispěvatel: j 22. 05. 2013, 18:44:43
1) firmu, kde by meli aktualni a rozumnou dokumentaci sem jeste nevidel .. ani jednu. Zato sem nekolikrat videl (na vlastni oci) jak byli zamestnanci tlaceni do sepisovani jakychsi "navodu" ... ktere uz za par tydnu (ale casto i dnu) stejne nebyly realitou. A zcela na vlastni kuzi sem zazil prave to ISO, kde v ramci jeho zavadeni klesla produktivita prace na polovinu, spis min.
Zcela konkretne - z jednoho papiru - vytistene objednavky, se stalo papiru 5, tam kde si predtim kazdy vyzved material, ktery potreboval, se zaclo podepisovat predani, prevzeti, vyhrady (kdyz nebylo vsechno) ... a pri inventure bylo manko o dva rady vetsi, nez kdykoli predtim.

2) jiste, managori velmi casto propaguji nazor, ze ridici pracovnik prece nemusi rozumet tomu, co jeho podrizeni delaji, protoze od toho tam neni ... a pak to presne podle toho vypada.
Opet, zcela konkretni priklady - jako technika me naproto nezajima, jak vypada smlouva s dodavatelem. Ja reknu, ze chci XYZ, a necht si managor zneni smlouvy zaridi jak chce. Presto si nakonec tu smlouvu musim napsat sam, a pak ji jeste dostanu zpet s tim, ze "pravnikovi se ale nelibi ..." tak at si to napise. Od toho tam prece je, ne?
Variantne jako technick reknu managorovi, ze je zcela nerealny v podminkach firmy realizovat dodavku v danym terminu... a on mi na to rekne "ale oni mi to slibili" ...

Proc? No protoze je to neschopej dement z podradny skoly. :P

3) takovy bych chtel videt.
Název: Re:Životní cyklus software
Přispěvatel: txt 22. 05. 2013, 19:14:50
Mohl by přispět někdo, se svými zkušenostmi v SW inženýrství, projektovém řízení atp.? Jinak půjde tohle téma od informací k šumu...

1) firmu, kde by meli aktualni a rozumnou dokumentaci sem jeste nevidel .. ani jednu. Zato sem nekolikrat videl (na vlastni oci) jak byli zamestnanci tlaceni do sepisovani jakychsi "navodu" ... ktere uz za par tydnu (ale casto i dnu) stejne nebyly realitou. A zcela na vlastni kuzi sem zazil prave to ISO, kde v ramci jeho zavadeni klesla produktivita prace na polovinu, spis min.
Zcela konkretne - z jednoho papiru - vytistene objednavky, se stalo papiru 5, tam kde si predtim kazdy vyzved material, ktery potreboval, se zaclo podepisovat predani, prevzeti, vyhrady (kdyz nebylo vsechno) ... a pri inventure bylo manko o dva rady vetsi, nez kdykoli predtim.
Dělal jsem montéra ve firmě, kde byla dokumentace na vynikající úrovni (sériová i zakázková výroba rozvaděčů). V autorizovaném servisu mobilních telefonů, kde byla dokumentace naprosto špičková. Nebylo všechno skvělé, ale v tomto ohledu ano.
b) To mohla být chyba v implementaci normy. Přehnaný papírování může být částečně redukováno pomocí ERP (rizika i náklady jeho nasazení si uvědomuju). Problém může být také, když nové pořádky zaměstnanci bojkotují. Nehlásám, že ISO vás spasí, ale trvám na tom že má i pozitiva.

2) jiste, managori velmi casto propaguji nazor, ze ridici pracovnik prece nemusi rozumet tomu, co jeho podrizeni delaji, protoze od toho tam neni ... a pak to presne podle toho vypada.
Opet, zcela konkretni priklady - jako technika me naproto nezajima, jak vypada smlouva s dodavatelem. Ja reknu, ze chci XYZ, a necht si managor zneni smlouvy zaridi jak chce. Presto si nakonec tu smlouvu musim napsat sam, a pak ji jeste dostanu zpet s tim, ze "pravnikovi se ale nelibi ..." tak at si to napise. Od toho tam prece je, ne?
Variantne jako technick reknu managorovi, ze je zcela nerealny v podminkach firmy realizovat dodavku v danym terminu... a on mi na to rekne "ale oni mi to slibili" ...

Proc? No protoze je to neschopej dement z podradny skoly. :P
Vedoucí by MĚL znát práci podřízených. Jinak bude činit horší rozhodnutí a nebude mít respekt u podřízených. Váš úhel pohledu je IMO úzký bez nadhledu a souvislostí. Myslíte si že když znáte dobře problémovou doménu tak že můžete mluvit do všeho.