A HFMS Szabadegyetem 2015. november 18-i ISO 55000 Vagyongazdálkodás szemináriumának előadása.
Asset Management vs. Facilities Management
HFMS Free University 18.11.2015
III. Elmélet - Az ERP rendszerek implementációja 1..pptxSzabolcs Gulyás
III./a Theory: Implementation of ERP systems 1.
• The importance of project planning
• Types and pitfalls of education
• Planning and handover of customizations
III./b: Practice: Technology
• Management of resources
• Creating technology (finished product, semi-finished product)
A HFMS Szabadegyetem 2015. november 18-i ISO 55000 Vagyongazdálkodás szemináriumának előadása.
Asset Management vs. Facilities Management
HFMS Free University 18.11.2015
III. Elmélet - Az ERP rendszerek implementációja 1..pptxSzabolcs Gulyás
III./a Theory: Implementation of ERP systems 1.
• The importance of project planning
• Types and pitfalls of education
• Planning and handover of customizations
III./b: Practice: Technology
• Management of resources
• Creating technology (finished product, semi-finished product)
Development of information systems - Common Criteria (in Hungarian)Csaba Krasznay
This presentation introduces to the basics of Common Criteria and was held in the frame of the subject "Development of information systems" for the students of Budapest University of Technology and Economics.
A Booz-Allen-Hamilton által az amerikai kormányzatra kidolgozott projekt tervezési és döntési metodológia, amit kicsit egyszerűsítettem, és talán használhatóbbá tettem.
Ezúttal a PMI Budapest, Magyar Tagozat Mentoring programjában résztvevő, Mentor és Mentee párosunk előadását hallhatják tapasztalataikról.
A vállalkozásokban az agiltásra való igény gyakran egy alulról jövő kezdeményezés. Esettanulmányukban a következő kérdésekre keresnek válaszokat:
Hogyan jelenik meg a szervezeti igény az agilitásra?
Hogyan érdemes nekifogni, hogyan érdemes a managementet tesztelni?
Érdemes-e külső segítséget alkalmazni?
Mik azok az elvek, amelyekre érdemes fókuszálni?
Hogyan viszonyul az egyén és a szervezet az új kihívásokra?
Előadók:
Susányi István, PMP, CSM, SAFe® 5 Agilist,
Senior Project Manager
Deutsche Telekom IT Solutions
GP/PM SSC/MS Szeged
Dr. Mindák László, PMP, CSSBB
Minőségbiztosítási igazgató
Klinikai kutatási terület
Development of information systems - Common Criteria (in Hungarian)Csaba Krasznay
This presentation introduces to the basics of Common Criteria and was held in the frame of the subject "Development of information systems" for the students of Budapest University of Technology and Economics.
A Booz-Allen-Hamilton által az amerikai kormányzatra kidolgozott projekt tervezési és döntési metodológia, amit kicsit egyszerűsítettem, és talán használhatóbbá tettem.
Ezúttal a PMI Budapest, Magyar Tagozat Mentoring programjában résztvevő, Mentor és Mentee párosunk előadását hallhatják tapasztalataikról.
A vállalkozásokban az agiltásra való igény gyakran egy alulról jövő kezdeményezés. Esettanulmányukban a következő kérdésekre keresnek válaszokat:
Hogyan jelenik meg a szervezeti igény az agilitásra?
Hogyan érdemes nekifogni, hogyan érdemes a managementet tesztelni?
Érdemes-e külső segítséget alkalmazni?
Mik azok az elvek, amelyekre érdemes fókuszálni?
Hogyan viszonyul az egyén és a szervezet az új kihívásokra?
Előadók:
Susányi István, PMP, CSM, SAFe® 5 Agilist,
Senior Project Manager
Deutsche Telekom IT Solutions
GP/PM SSC/MS Szeged
Dr. Mindák László, PMP, CSSBB
Minőségbiztosítási igazgató
Klinikai kutatási terület
2. ? Szabványok Mire jók… Hol kell használni… Mindennapi munkában… Módszertanok Hogyan kerül szofterg a fejlesztésbe… Milyen lehetőségek vannak… Némi gyakorlati tapasztalat 2010. november 25. Szabványok, módszertanok 2
4. Szabványok Ipari és kutatási eredményeket összegez Bevált gyakorlatokat (bestpractice) formálisan tartalmaz Nem mindenhol kell, de jó betartani Általában vannak Nemzetközi szabványok (pl.: ISO, ANSI) (Nemzeti) Magyar szabványok (pl.: MSZ) Egyéb szabványosító szervezetek által kiadott (pl.: w3c) Elnevezés… 2010. november 25. Szabványok, módszertanok 4
5. ISO, IEC, MSZT ISO: International Standards Organization Nemzeti szervezetekből áll Egyes területekre bizottságokat állít fel (nemzeti szervezetekből + szakma + ipar) IEC: International ElectrotechnicalCommission Önálló szervezet, de az ISO-val együtt dolgozik Az informatikai témákért többnyire ők a felelősek Magyar Szabványügyi Testület Az olvasóterembe diákkal ingyen be lehet menni Külföldi és magyar szabványok is olvashatók 2010. november 25. Szabványok, módszertanok 5
6. Szabványtípusok Tartalom szerint két fő típus Folyamat (pl.: ISO 13407) Hogyan kell csinálni Nem magára a termékre vonatkoznak, hanem a termék előállítására Design (pl.: ISO 9241) Milyen legyen a termék Nem mond semmit a hogyanról 2010. november 25. Szabványok, módszertanok 6
8. Szofterg és minőség A minőségbiztosítás általános szabványai ISO 8402 (Minőség és minőségbiztosítás – szakszótár) ISO 9000-es szabványsorozat ISO 90003:2004 útmutató: az ISO 9001-es szabvány szoftverfejlesztésre való alkalmazása 2010. november 25. Szabványok, módszertanok 8
9. Szofterg és minőség A szoftverek minőségének termék-szempontú megközelítése A részletekbe menő irányelvek szintjén: ergonómiai elvek (ISO 9241) a szellemi munkaterhelés ergonómiai alapelvei (ISO 10075) multimédia felhasználói felületek ergonómiai elvei (ISO 14915) Szoftvervizsgálatok (ISO 9126) A minőségkövetelmények kiértékelése (ISO 14598) 2010. november 25. Szabványok, módszertanok 9
10. Szofterg és minőség A szoftverek minőségének folyamat-szempontú megközelítése: Szoftveréletciklus-folyamatok (ISO 12207) Rendszeréletciklus-folyamatok (ISO 15288) Emberközpontú szoftveréletciklus-folyamatok (ISO 18529) Felhasználó-központú tervezés a teljes életciklus során (ISO 13407) A szoftverfolyamatok közül a mérési folyamatok (ISO 15939) A szoftverfolyamatok értékelése (ISO 15504) 2010. november 25. Szabványok, módszertanok 10
11. ISO/IEC 9126-1:2001 2010. november 25. Szabványok, módszertanok 11 ISO/IEC 9126-1:2001: Software engineering – Product Quality- Part 1: Qualty model, 6: Quality model for external and internal quality
12. 9126 használata Szoftver értékelésére Értékeléshez mérni kell, de előtte meg kell határozni, hogy mit és miért Pl.: zh-k osztályozása A minőségi dimenziók alapján lehet saját kritérium modellt alkotni A szabvány többi részében a karakterisztikák további attribútumokra oszlanak ezek nyújtanak segítséget 2010. november 25. Szabványok, módszertanok 12
13. ISO/IEC 9241 sorozat ISO/IEC 9241 sorozat Eredetileg: „Képernyős terminállal végzett irodai munka ergonómiai követelményei” Újabban: „Ember-rendszer interakció ergonómiája” Az 1992-ben megjelent szabványt 1996-98 közt bővítették ki a szoftverekre vonatkozó részekkel, majd 2001-ben megújították Jelenleg újra megújítás alatt van: újraszámozás, tartalmi frissítés Érdekesség: 9241-3xx szabályozza az LCD pixelhibák számát… 2010. november 25. Szabványok, módszertanok 13
14. ISO 9241 részei 1. és 11. rész: áttekintés 2. rész: munkafeladatok 3. rész: képernyő (hardver) 4. rész: billentyűzet (hardver) 5. rész: munkahely-elrendezés 6. rész: környezet 7. rész: képernyőn való tükröződések (hardver és környezet) 8. rész: színek (hardver) 9. rész: egyéb beviteli eszközök (hardver) 2010. november 25. Szabványok, módszertanok 14
15. ISO 9241 részei 10. rész: a dialógus alapelvei 12. rész: információmegjelenítés(információszervezés, grafikus objektumok, kódok) 13. rész: a felhasználót segítő eszközök (ált. elvek, prompt, visszajelzések, állapotinformáció, hibakezelés, súgó) 14. rész: menü-alapú interakció 15. rész: parancsnyelven alapuló interakció 16. rész: közvetlen manipulációs interakció 17. rész: űrlapkitöltésen alapuló interakció 2010. november 25. Szabványok, módszertanok 15
16. 9241 használata A részek csoportosítva tartalmaznak irányelveket Első lépésben el kell dönteni, hogy az irányelvek közül melyik csoport vonatkozik ránk Csoportok közül Egyes irányelvek közül A döntést indoklással rögzítjük Második lépésben az irányelvnek megfelelőséget vizsgáljuk Megfelelőség vizsgálatának módszere Megfelel: igen/nem 2010. november 25. Szabványok, módszertanok 16
17. 9241 használata – példa Directmanipulationdialogs-ra(16) vonatkozik 2010. november 25. Szabványok, módszertanok 17
18. Definíció ISO 9241-11 Ergonomicrequirementsforofficeworkwithvisual display terminals (VDTs) — Part 11: Guidanceonusability 3.1 usability: Extenttowhich a productcan be usedbyspecifieduserstoachievespecifiedgoalswitheffectiveness, efficiency and satisfactionin a specifiedcontext of use. „Annak mértéke, ahogy a terméket meghatározott felhasználókmeghatározott célokérthatásosan, hatékonyan és elégedetten használják egy adott környezetben.” 2010. november 25. Szabványok, módszertanok 18
19. ISO 13407:1999 Interaktív rendszerek ember központú tervezése A szoftver (rendszer) teljes életciklusára vonatkozik Ez a fejlesztés folyamata A folyamat nagyon általános, gyakorlatilag bármire jó, ezért többnyire módosítják a helyi igényeknek megfelelően 2010. november 25. Szabványok, módszertanok 19
20. Orvosi szofterg szabványok Orvosi (szoftvert használó) műszerekre és kórházi rendszerekre Speciális felhasználás, a hibázás sérülést okozhat a betegnek és orvosnak ISO/IEC 62366: Fejlesztési folyamat ANSI/AAMI HE74 (folyamat) és HE75 (irányelvek) Kockázatkezelés része (ISO 14971) A szabvány betartása az engedélyezés feltétele! 2010. november 25. Szabványok, módszertanok 20
22. Módszertanok Segítenek a szofterges tevékenységek szervezésében Követésükkel lehet valamilyen teljességet garantálni Minden esetben át kell kicsit szabni a saját igényekre Attól hogy egy módszertan valakinek bevált, nem biztos, hogy nekünk is megfelelő (sőt…) 2010. november 25. Szabványok, módszertanok 22
23. Főbb szofterges irányzatok Egyrészről követik a szoftveres trendeket, másrészről építenek a többi ősre: Követelmény analízis (Requirementanalysis, RA) Participatív tervezés (Participiatory design, PD) Felhasználó központú (User centered design, UCD) Agilis (Agile) 2010. november 25. Szabványok, módszertanok 23
24. Követelmény analízis Mérhető, tesztelhető, részletes és az üzleti igényeknek megfelelő követelmények megfogalmazása A tágabb RA részekén a szofterges követelmények is megjelennek Gyakorlatilag a vízesés és továbbfejlesztései Alapprobléma: a felhasználói követelmények befűzése nagyon nehézkes, az RA ritkán tűri jól a többszörös iterációt 2010. november 25. Szabványok, módszertanok 24
25. Participatív tervezés Eleinte nem számítógépes irányultságú, inkább épített környezet (1960-as évektől) Az emberek jogára épít, hogy részt vehessenek az őket érintő, munkájukat befolyásoló döntésekben A felhasználók részt vesznek a tervezésben A designerek inkább tanácsadók („advisor”) Szociális tényezőket is figyelembe vesz Modern formája: crowdsourcing (elosztott PD) 2010. november 25. Szabványok, módszertanok 25
26. Felhasználók bevonása Leendő felhasználók bevonása nehéz: a felhasználók IT-kal kapcsolatos ismeretei hiányosak kommunikációs problémák (a szakértőknek és a felhasználóknak nincs „közös nyelve”) intellektuális nehézségek (absztrakt gondolkodás: elképzelni a rendszer jövőbeni működését, „elővételezni” az új követelményeket) „hostagesituation”: a felhasználó nem akar buta kérdéseket feltenni – passzív magatartás 2010. november 25. Szabványok, módszertanok 26
27. Participáció hatásossága Milyen feltételek mellett jelentős elsősorban a közvetlen participáció hatása? …ha a projekt mérete viszonylag kicsi; …ahol a felhasználók ismeretei lényegesek a sikeres megvalósításhoz; …olyan szervezetben, ahol az egységesség („uniformityin design”) nem követelmény; …ha a szervezetben egy bizonyos fokú konszenzus van a projekt céljait illetően; Kontextus, kontextus, kontextus… 2010. november 25. Szabványok, módszertanok 27
28. Felhasználó központú Inkább filozófia, mint konkrét módszertan (sokféleképpen megvalósítható) Nemcsak szoftverre, hanem bármire jó A lényeg: a tervezés középpontjában az ember van, akinek a termék készül Az ember szükségleteire épít, nem próbálja meg a termékhez „idomítani” Ehhez nemcsak analizálni kell, mire van szükség, hanem a felhasználókkal ki is kell próbáltatni (-> iterációk) 2010. november 25. Szabványok, módszertanok 28
35. PD vs UCD A felhasználók részt vesznek a döntésben A felhasználók véleményét meghallgatja Felhasználók partnerek a tervezésben Aktív részvétel Demokratikus(abb) A felhasználók igényei alapján döntenek A felhasználók tevékenységét vizsgálja Felhasználók a vizsgálatok tárgyai Passzív részvétel Autokratikus(abb) 2010. november 25. Szabványok, módszertanok 35
36. Agilis szofterg Agileusability, ami felé ma tart szinte mindenki A vízeséses szoftverfejlesztési modelleknek rengeteg problémája van Legfőképpen, hogy valós körülmények közt nem működnek… A szofterg konkrét alkalmazása is hasonlóan ide tart Az iterációk könnyebb betervezni „Kontextus, kontextus, kontextus” a köbön 2010. november 25. Szabványok, módszertanok 36
37. Agilis szoftverfejlesztés kiáltvány Az egyént és a személyes kommunikációt, a módszertanoknál és az eszközöknél. A működő szoftvert, az átfogó dokumentációnál. A megrendelővel való együttműködést, a szerződéshez való ragaszkodással szemben. A változásra való reagálást, a tervek rigorózus követésével szemben.... Noha, fontosak az utóbbiak is,mi fontosabbnak tartjuk az előzőeket. http://www.agilealliance.hu/ 2010. november 25. Szabványok, módszertanok 37
39. Agilis és felhasználók Bár programozók indították, de… Sok közös pont van az agilis és a felhasználót bevonó modellek között Jó a gyors iteráció (van alkalom a felhasználókkal egyeztetésre, együttműködés) Az utóbbi 2-3 évben közeledik a két közösség (közös konferenciák, beszélgetések) Azonban nincs direkt hivatkozás a felhasználóra (megrendelő nem az!) 2010. november 25. Szabványok, módszertanok 39