Životní cyklus software

[Pupi]

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?

[Reklama]

[nn]

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 ...

[nn]

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

[Franta <xkucf03/>]

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.

[Pupi]

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.

[Reklama]

[txt]

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.

[Juro]

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.

[eMko]

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í.

[Pupi]

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.?

[txt]

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.

[Pavel 'TIGER' Růžička]

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.

[Pupi]

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.

[gamer]

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á.

[perceptron]

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"

[backup]

Čemu to vadí? SCRUM vznikl v roce 1986 a stále se používá.

ne, metoda pokus-omyl vznikla uz na zacatku existence lidi.