Szoftvertervezes,hogy mukodik?

hallottál már olyanról, hogy dokumentáció?

elég sok fajta van és egy része elengedhetetlen, köztük még olyan száraz dolgok is, mint hogy egy szoftvernek megbecsülik az értékét, fejlesztési idejét stb

Attól függ melyik oldalról.

Először is meg kell határozni az feladatot, hogy mit akarunk írni. Milyen problémát kell orvosolni. Ez az úgynevezett működési üzleti logika. (Van kód szintű üzleti logika, ami a működés kód béli manifesztációja, de ebbe ne menjünk bele.) Tehát van egy elképzelés, hogy mi az input és output. Erre már lehet teszteket definiálni elméletben. Mire, mit vársz. Pl.: rendelsz enni (output) azt várod hogy asztalra kerüljön (output). Tehát ha ez teljesül, átment a teszten. Nyilván, még az éttermet fel kell építeni, de eleve már van egy teszt eseted.

De ahogy épül az étterem újabb kihívások vannak, amiket meg kell oldani. Tehát ismét teszt eseteket kell meghatározni mélyebb szinteken és tá az implementációt megcsinálni.

Így kialakul egy fajta rétegződés. Alulról felfele:

- Unit test, amit fejlesztő ír, egy adott függvényre, hogy x+y valóban x+y. Unit teszt, hogy mekkora egységet ölel fel a kódból vagy kód részletet, kb. mindenkinek más mekkora él a fejében. Van aki egy teljes működés blokkot unit tesztnek nevez, van aki pl. egy összeadást is letesztel. Bár az utóbbi felesleges, mert evidens. De van ilyen is.

- Integrációs teszt, ami inkább különböző komponenseket tesztel. Ha Unit-tesztet étteremben pl. konyhára értünk és külön raktárra is egy Unit teszt teret, akkor a kettő kölcsönhatása integráció hatására lép kapcsolatban, így integrációs teszt. Persze benne van a pakliban, hogy a raktár és a konyha önmagában 5*-ra vizsgázik, de a kettő szindiózia katasztrófa. :) Persze, ha sikeres az integrációs teszt is, akkor minden faxa. Most, hogy mely két komponensre értjük ezt, ez is tervezés, definíció kérdése.

- Rendszer teszt, hogy tényleg működik, amit megálmodtunk. Jellemzően nem fejlesztő végzi, hanem tesztelő csapat, ami az üzleti logika által meghatározzák, hogy mi legyen az input-output. De internet és a google sokat tud segíteni.

- Elfogadási teszt (Inkább ügyfél, hogy átvétel elött megnézi)

Jah. Unit és az Integrációs tesztet fejlesztő írja főleg a kódban. :)

Leülsz és írod a kódot.

A tervezgetéssel csak az idő megy el, ahelyett már rég kész lennél.

A felhasználót is a kész program érdekli, nem pedig az, hogy a cég még bíbelődik a tervekkel.

Úgy is fogalmazhatunk, hogy a konkurencia már a piacra viszi a terméket, mire te elkészülsz a tervezéssel.

#3 így készülte el

- az oltási regisztrációs rendszer is, ahol egy TAJ számmal bármennyi e-mail címmel regisztrálhatsz

- az előválasztási rendszer is, amely a "nagy" terheléstől azonnal leállt

- tengernyi mobilapp, ami a közművek kezelését hivatott "könnyebbé" tenni

- mobiljegy app, ami régebbi mobilokon állandóan haldoklik

- valszeg az otp simple rendszere sem lett minden tekintetben átgondolva

- de még az ország egyik legnagyobb kórházi rendszere is a DokuMedik (az utódja fejlesztésében vettem részt, de már az is sz@r, pont emiatt, mert nem tervezett...)

Lassúak, terhelhetetlenek, tele vannak hibákkal, használhatatlanok...

Nem azt mondom, lehet komoly tervezés esetén is súlyos hibát véteni, de a helyes út valahol az agy nélküli, teszt nélküli kódmajmolás és a túltervezett, túldokumentált megoldás között van, természetesen az applikáció, mérete, céljai és környezete függvényében.

Most milyen módszertant tanítanak/ használnak élesben?

Anno én még SSADM-t tanultam, de valószínű van jobb is, meg azóta gondolom van már jobban kiforrott és programmal segített.