Posted by: hordost in Untagged on
ápr 1, 2011
Nem lehet a szerepköröket sem a szoftverfejlesztésben sem más folyamatokkal kapcsolatban eléggé hangsúlyozni.
Nem csak a felelősségi határok szempontjából lényeges, hanem a képesség megfelelő felméréséhez is elengedhetetlen. A folyamat leírásának részleteiből tudni lehet, hogy milyen képességekkel lehet azt elvégezni. A szakmai kompetencia mellett persze fontosak az egyéb képességek is, amit "soft skill"-el vagy puha faktorral szoktak jelölni, egyesek szerint akár 50-50% arányban is, de erről majd máskor...
A szerepkör meghatározása számomra azért is fontos, mert szeretem a feladatokat arcokhoz kötni, még ha távmunka esetén ez néha csak virtuális. Az üzleti folyamatok csak egy kis része automatizált, számítógéppel támogatott, bár persze a cél az, hogy ez az arány a támogatott folyamatok felé mozduljon el, és az automatizált folyamatoknak is kell legyen gazdája. Amint megjelenik az ember a folyamatban, megnő a folyamat lassúbbá válásának, félrecsúszásának sőt elakadásnak az egyébként is meglévő lehetősége. Ezt elkerülendő, nem elég feltétlenül a folyamat "tökéletes" leírása (ilyen van egyáltalán?), hanem azt megfelelően kell kommunikálni, többek között a célokat is ismertetni kell, és a kollégát motiválni kell. Na, ezért szeretem tudni, ki fogja a folyamatot elvégezni.
Posted by: hordost in Untagged on
márc 28, 2011
Ez az egyik kedvenc témám. Miért is? Mert úgy látom, hogy sokszor hajlamosak vagyunk elfeledkezni róla, hogy a szoftverfejlesztés nem öncélú programkódolás, hanem a rendszerrel szemben támasztott követelmények meghatározása, specifikálása, megtervezése és implementálása, persze az alapos teszteléssel és átvételi kritériumokkal leírt beüzemeléssel.
Mondhatnám, hogy ez az SE alapja, az SE-projekt sikerének kulcsa a pontos, alapos és részletesen leírt követelményspecifikáció.
Milyen részekből is áll a jó követelményspecifikáció?
- A projekt mozgatói (project driven), amiben leírjuk miért is kell a projekt által megvalósítandó rendszert létrehozni, kik és milyen prioritások mentén fogják használni.
- Felhasználási terület (application domain) fejezet mutatja be, milyen üzleti területet fed le a megvalósítandó rendszer. Nagyon fontos a határok és a más rendszerekhez való kapcsolódáspontos leírása.
- Funkcionális és adatkövetelmények (Functional and data requirements) rész azokat az üzleti folyamatokat mutatja be, amit majd az adott rendszer kell implementáljon, és azon adatokat (OO-módszerrel), amelyeken az üzleti követelmények értelmezhetőek.
- Nem funkcionális követelmények (Non-functional requirements) a megvalósítandó alkalmazással támasztott igények, amik a kinézettel, biztonsággal, működéssel kapcsolatos elvárásokat fogalmazzák meg.
- Projekt keretfeltételek (project cotstraints) közé tartozik azon minden egyéb olyan követelmény, ami az előző két pontba nem sorolható be, nem feltétlenül a megvalósítandó rendszerrel, hanem az SE projekttel függ össze. Ilyenek a megkötések, a társalkalmazások,pénzügyi feltételek, szabványok stb.
Szöveges vagy UML doksi ez? Vegyesen kell csináljuk, de egy jó UML-tool ezt támogatja. Ennek részleteire majd későbbiekben kitérek.
Posted by: hordost in Untagged on
márc 25, 2011
Nehéz a a címben szereplő fogalmakat tisztába tenni. Próbálok én egy alá és fölérendeltségi viszonyt kialakítani a kettő között, lássuk, hogy sikerül.
Az SE módszer egy világosan megfogalmazott eljárásrend, amit egy szoftverfejlesztési projekten a fejlesztők alkalmaznak, amit standardizálhatnak is a saját vagy a cégjük fejlesztéseihez.
A szoftverfejlesztési eljárás modell (process models) különböző elterjedt SE process-ek, mint a Vízesésmodell, RUP, SSADM, Agile, Scrum stb).
Posted by: hordost in Untagged on
márc 24, 2011
Nem igazán szeretem az angol rövidítéseket, de nehéz az áramlattal szemben úszni. Szóval, kedves olvasó, mostantól fogok használni itt is a szakmában elterjedt rövidítéseket, mint az SE-t, ami az angol software engineering (szoftverfejlesztés) szóösszetételből származik.
Milyen rövidítéseket is szoktam még használni?
CM = configuration management
Posted by: hordost in Untagged on
márc 23, 2011
Múltkori bejegyzésem a szoftvertervezésről szólt, a számomra nagyon kedves szoftverfejlesztési diszciplináról. Mostanában azonban egyre többet fogalkozom a szoftverfejlesztési módszerek más diszciplináival is, például a konfigurációs menedzsmenttel.
Configuration management néven sok irodalmat találunk róla a neten, lásd pl. a wikipediát . Nem is az elméleti megközelítéséről szeretnék írni, hanem a hangsúlyosságát emelném ki, igyekezvén szakítani a mélyen beivódott múlttal, amely méltánytalanul elhanyagolta ezt az igen is fontos fejezetét a szoftverfejlesztésnek.
Mert szükség van a fejlesztési projektekben a szoftvertervezésen túl a fejlesztés során keletkezett eredmények kezelésére, a release-k meghatározására, a verziókövetésre, a build-elések, a kiszállítások tervezésére, és természetesen mindezek dokumentálására. Egy fontos lépés a projekt indulásakor annak megtervezése, hogy az elkészült fájlokat hogyan verzionáljuk (nem csak a tool, hogy SVN-tm, CVS-t, clearcase-t vagy Microsoft Visual Sourcesafe-et használunk), milyen baseline-okat definiálunk, hogy tervezzük a release-ket, miként build-eljük a kiszállítandó rendszert. Ezt érdemes egy konfigurációs menedszment tervben (CM-Plan) dokumentálni, amely tervet folyamatosan aktualizálja az azért felelős konfigurációs menedzser.
Posted by: hordost in szoftvertervezés on
márc 18, 2011
Szóval, kell-e a szoftvert tervezni?
Erről a kérdésről mindig az jut eszembe, hogy laknál-e olyan házban, amit nem terveztek meg? Vezetnél-e olyan autót, amit csak úgy összeraktak alapos előkészítés azaz gondos tervezés nélkül?
Manapság már majdnem mindent szoftver vezérel, pl. az hogy áram legyen a lakásodban, pénzt vehess fel az automatából és hosszan sorolhatnám. Rábíznád az életedet olyan szoftverre, ami ezeket vezérli, de azokat nem tervezték, implementálták és tesztelték alaposan meg illetve le? Ugye, nem!
Posted by: hordost in Untagged on
márc 12, 2011
Hordós Tamás vagyok, informatikus.
Egyik reggel arra ébredtem, hogy az elmúlt sok-sok év alatt annyi minden történt és történik még ma is velem a szakmámban, hogy érdemes lenne ezeket kiírogatnom magamból. Annyi érdekes tapasztalatra tettem szert a nagygépes operátorságomtól kezdve, a programozási és szervezési munkáimon keresztül, projektvezetőségen át a módszertanokkal és egyéb szakmai témákkal való lelkes ismerkedéseim sorát bezárólag, hogy úgy érzem, ezeket már másokkal is meg kell osztanom. Ezért létrehoztuk kollégámmal, Andrással ezt a blogot itt, s ha csak 15 perc üresjáratom lesz, akkor ide firkálgatok a gondolataimról. Ez itt a 15 perc elmélkedések blogja...
Mostanában például azon töprengek sokat, miként tudnám azon, széles ismeretségi körömben lévő kollégáim munkához való hozzáállását változtatni, akik már igazából a megszokásaik, kissé kopottas szakmai tudásuk rabjai, abból kitörni nem tudnak vagy nem akarnak. (Te kedves Kollégám, aki ezt a bejegyzést most olvasod, természetesen nem ide tartozol!) Bizton állítom -sok szakmabéli véleménye ellenére is-, hogy nekünk nem is a megbízóval a legnehezebb, hanem a begyöpösödött munkatársakkal. Ezek a kollégák azok, akik mindenfajta szakmai feladatot valami hagyomány alapján közelítenek meg, legyen az egy valamikori módszeren alapuló vagy egy individuális eljárás, amit viszont már hosszú évek során -számukra elégséges módon- tökéletesen bejárattak.
