Object-orientated and functional paradigms
I’ve been writing code for well over half a decade now… and I feel like the journey is just beginning. This article is a collection of subjective musings about object-orientated and functional paradigms, their advantages, disadvantages and use in real world software engineering, from the viewpoint of a [arguably young] software developer.
[It's also a hometask for I230]
Infosüsteemide eetikaprobleemid
Eesti Infotehnoloogia Kolledži aine “Infosüsteemide analüüs ja projekteerimine” raames. Allpool esitatu on olemuselt pigem esseeistlik töö ning põhineb autori subjektiivsel arvamusel. Soovitav on lugeda tööd Google Docs keskkonnas.
Ülesande kirjeldus
Tuua kaks infosüsteemi arendusprojektide näidet, kus arendajad puutusid kokku erinevate eetiliste probleemidega
1. Lühidalt kirjeldada projekt
2. Iseloomustada eetiline probleem
3. Tuua välja huvitatud osapooled
4. Pakkuda välja võimalikud lahendused
5. Selgitada, miks tegemist on just eetilise probleemiga
Pakkuda välja 5 reeglit, kuidas käituda eetiliste probleemide puhul.
Projekt #1: Ehitusfirma kodulehe realiseerimine
Kirjeldus
Tarkvaraarendusega tegelevale firmale esitati tellimus ehitusfirma kodulehe ja -haldusliidese tarkvara loomiseks. Loodav koduleht kasutaks üht kujundust, mille sisuala vastavalt valitud lehele vaheldub. Lehti saab luua ja muuta haldusliidesest. Lisaks staatilistele lehtedele sisaldab koduleht ka dünaamilisi osi: mooduleid ning automaatselt genereeritud tekste (sisukokkuvõtted). Mooduliteks on näiteks tehtud tööde moodul, kuhu sisestatud andmete põhjal genereeritakse automaatselt külastajale nähtava lehe sisu või uudiste moodul, mida kuvatakse parempoolses kõrvaltulbas.
Probleem
Probleemi vaatleme tarkvaraarendaja seisukohast. Arendaja probleemiks on ressursihaldus. Projektil on piiratud eelarve ning aeg, kuid kliendile tuleks pakkuda parimat kvaliteeti ning realiseerida võimalikult palju kokkulepitud nõuetest. Kvaliteedi saavutamine tähendab muuhulgas ka süsteemi planeerimistegevusi, dokumenteerimist ja testimist.
-
Kas kujundada süsteem nii, et seda on tulevikus lihtne hooldada ja laiendada või teha “üle põlve”, arvestades praeguseid spetsiifilisi vajadusi (ning riskides tulevikuprobleemidega)?
-
Kas testida süstemaatiliste meetoditega ja põhjalikult teades, et sügava testimise vajadust on hiljem kliendile keeruline põhjendada ning see venitab eelarvet?
-
Kas jälgida standardeid või teha võimalikult kiiresti?
-
Kas pühendada aega ka teiste veebisirvijate toele või kasutada vaid enimlevinute viimaseid versioone?
Huvitatud osapooled
| Osapool | Huvi | Tulem, huvi avaldumine |
| Arendaja | Pakkuda kliendile parimat kvaliteeti, säilitada oma meelerahu ning reputatsioon. | Projekti eelarve ja läbiviimiseks kuluv aeg kasvavad, klient võib olla rahulolematu või keelduda maksmast, minnes pakkuja juurde, kes pealtnäha sama tulemi odavamalt valmistab. |
| Projektijuht | Kindlustada kodulehe valmimine eelarve ja tähtaja piires. Tagada kliendi rahulolu. | Surve arendajale tekitab puudujäägid kvaliteedis ja ulatuses. Võimalus, et süsteemi hooldusfaasis avaldub kliendi rahulolematus. |
| Tarkvarafirma omanik | Kindlustada projekti edukas lõpetamine ja kliendi maksevalmidus. | Surveahel: Klient -> Omanik -> Projektijuht -> Arendaja |
| Klient | Saada määratud eelarve ja ajakuluga kvaliteetne ja kokkulepitud tulemus. | Kompromiss kõigi kolme osas: tavaliselt suurenevad eelarve ja tähtaeg, et tagada aktsepteeritav kvaliteet kõikide nõuete realiseerimine. |
| Veebilehe külastaja | Saada hea kasutajakogemus. Leida soovitud info kiiresti.Nautida lehte visuaalselt. | Vigade leidmisel negatiivne tagasiside kliendile, kliendi reputatsiooni langus külastaja silmis. |
| Veebilehe hooldaja (tarkvaraarendaja #2) | Teha soovitud muutused süsteemis kiiresti. Teada, et olemasolev süsteem on töökindel ja testitud. | Eelarve suurenemine, kui juba valmis süsteem ei ole tulevikuga arvestanud. |
| Veebilehe sisuhaldur (inimene, kes veebilehte infoga täidab) | Suuta täita kõik nõutud tegevused kasutajasõbraliku haldusliidese kaudu. | Puudujääkide ilmnemisel negatiivne tagasiside ülemusele, kaudselt ka tarkvarafirmale. |
Lahendused
Probleemile pole 100% õiget lahendust, need piirangud on olemas igas projektis ning jäävad ka tulevikus kehtima. Kõige enam ilmnevad ressursiprobleemid klassikalise Waterfall ehk kosemeetodiga, kus kogu projekt on algusest planeeritud ning kasutatavad ressursid lukustatud.
Üheks võimalikuks alternatiiviks oleks agiilse metoodika kasutamine, kus soovid ja teostused tehakse iteratsioonidena. Siis on ootamatused ja muutused kergemini hallatavad ning kliendil on parem ettekujutus projekti seisust.
Agiilse metoodikaga (Scrum) projekti planeerimisel kasutatakse ka järgnevat meetodit: kliendil lastakse valida kolm olulist piirangut neljast (kvaliteet, ulatus, eelarve, raha) ning neljanda hindab arendustiim vastavalt esimese kolme määrangule. Seda tehnikat kasutades ei lange kogu vastutus arendaja (projekti meeskonna) õlule.
(pilt: http://agilesoftwaredevelopment.com/blog/peterstev/10-agile-contracts#Sprint)
Eetikaprobleem?
Tegu on eetikaprobleemiga, mis langeb arendaja õlule, sest just arendaja teab kõige täpsemalt, mis koodi sees toimub. Realiseeritud süsteem võib kliendi ja juhatuse poolt vaadatuna küll ilus ja töötav olla, aga arendaja istub sel ajal häbitundega ja vaikides: koodis on turvaaugud, see on ehitatud standardeid ja metoodikaid järgimata, raskesti hooldatav, dokumenteerimata.
Julgemad arendajad räägivad sel teemal projektijuhi, juhatuse ning isegi kliendiga, küsides juurde aega ning ressursse: eesmärk on neil kõigil ju ühine: kliendile võimalikult kvaliteetse toote pakkumine. Tihti selline läbirääkimine aga ebaõnnestub, sest vajadust ei suudeta mittetehnilisele kliendile piisavalt kästi kommunikeerida või pole klient lihtsalt valmis parema lahenduse eest rohkem maksma.
Olgu olukord milline tahes, tulem jääb siiski liigagi tihti samaks: valmistatakse süsteem, mille selle ehitanud arendaja heameelega prügikasti saadaks.
Projekt #2: Catering firma tööde infosüsteem
Kirjeldus
Tarkvarafirma on loonud oma kliendile (kelleks on suur ja mainekas catering firma) infosüsteemi kliendi infohalduse automatiseerimiseks. Süsteem on laiaulatuslik, võimaldades muuhulgas…
-
Klientide ja kliendiandmete haldamist
-
Ühekordsete ja korduvate tööde sisestust ja haldust
-
Arvete koostamist tehtud tööde põhjal perioodiks (üks kuu)
-
Firma finantsaruannete koostamist
-
Hallatavate objektide (hooned, asutused) haldust
-
Töötajate ja palgagraafikute haldust
Nagu näha, on tegemist üsnagi andmemahuka ja keerulise süsteemiga. Süsteem sisaldab kliendi poolt aastate jooksul sisestatud andmeid, logisid, üleslaaditud faile ning firmasisest kirjavahetust.
Probleem
Olukorda illustreerib hästi analoogia teise, hiljuti meedias tähelepanu saanud analoogse probleemiga. Nimelt esitas “Europe vs Facebook” grupp Iiri andmekaitseorganile nimekirja kaebustega sotsiaalvõrgustik “Facebook” vastu. Kaebused olid seotud suurkorporatsiooni andmekasutusega, nimelt süüdistati firmat klientide andmete ebaeetilises kogumises ja kasutamises.
Olukord on paradoksiaalne. On mõistetav, et iga andmetel põhinev süsteem (Facebook, Gmail, pangad, catering firma infosüsteem) peab oma funktsionaalsuse täitmiseks säilitama tundlikke andmeid. Samas ei soovi andmete omanikud (objektid, füüsilised- ja juriidilised isikud) tihti nende andmete (õigustamata) eksisteerimist kolmandate osapoolte käes, põhjendades seda õigustatud väitega, et selliseid andmeid saab kuritarvitada andmete valdaja või muu juurdepääsuga isiku omakasu huvides.
Catering firma infosüsteemist rääkides on sellisteks isikuteks süsteemis haldaja rolli omavad töötajad ning tarkvarafirma arendajad, kes andmebaasile ja süsteemile vahetut ligipääsu omavad. Siit ka eetikaprobleem: kas catering firma peaks muretsema võimu üle, mida arendajad omavad ning vastupidi; kas arendajad peaksid võitlema süümepiinadega hooldustöid sooritades?
Huvitatud osapooled
| Osapool | Huvi | Tulem, huvi avaldumine |
| Catering firma töötaja | Säilitada oma andmete privaatsus firmaväliste isikute suhtes: tehtud tööde info, palgagraafik. | Garantii küsimine info kaitsmise kohta tarkvarafirmalt: NDO (non-disclosure-agreement), lepingusätted. |
| Infosüsteemi haldaja | Tagada süsteemi andmete õigsus, kontrollida töötajate tegevusi. | Töötajate tegevuse auditeerimine, vastutamine andmete ja tegevuse õigsuse kohta. Surve tarkvarafirmale programmi hooldus- ja monitoorimisvõimaluste teostamiseks. |
| Tarkvarafirma arendaja | Tagada süsteemi toimimine hooldustööde ja edasiarenduste kaudu kasutades selleks andmeid olemasoleva süsteemi toimimise kohta. | Infosüsteemi andmete kasutamine testide koostamiseks. Vastutus mõlema firma ees andmete privaatsuse ja rikkumatuse tagamiseks. |
| Tarkvarafirma juht | Tagada süsteemi toimimine, vältida kliendi pretensioone privaatsuse osas. | Kindlustamine, et süsteem andmeid ei hävitaks ega lekitaks. Läbirääkimised kliendiga arendaja soovitatud hooldustööde tasustamiseks. |
| Catering firma klient | Saada kvaliteetset teenust, tagada catering firmaga vahetatud info privaatsus kolmandate isikute suhtes. | Catering firma usaldamine oma andmetega. Väärteo kahtlusel pretensioonide esitamine vastava(te)le seadusorganile auditi korraldamiseks. |
| Andmekaitseagentuur | Tagada kehtivate seaduste täitmine catering- ja tarkvarafirma poolt. | Pretensioonide töötlemine catering- ja tarkvarafirma vastu. Audit infosüsteemi tööle ja käideldavate andmete kasutusse. |
Lahendus
Tegemist on eetikaprobleemiga, mille tuvastamiseks on raske diskreetseid ja ühetimõistetavaid piiranguid seada. Iga infosüsteemi valdajal lasub moraalne ja eetiline vastutus oma võimu mitte kuritarvitada.
“With great power there must also come — great responsibility.”
(suure võimuga käib kaasas suur vastutus)
- Amazing Fantasy #15 (2)
Kuritarvitamise piir sõltub aga vaatepunktist ja eeldustest.
Info valdajale antakse andmed usalduse alusel: panku usaldatakse konto saldo saladuses hoidma, sotsiaalvõrgustikke isikuandmete puutumatusega. Järelikult on need firmad teinud midagi, mille põhjal on meil alust arvata, et tegu on maineka ja usaldusväärse asutusega. Selle eelduse tekitamiseks peavad asutuse töötajad lähtuma teatud kehtestatud või ühiskonna poolt omaks võetud eetikastandarditest, nagu näiteks Arvutustehnika Eetika Instituudi poolt välja antud kümme käsku (1).
Võimu kuritarvitamise ennetamiseks on riiklikul tasandil rakendatud negatiivse tagasiside süsteem: kuritarvitad informatsiooni (näiteks pakub süsteemi arendaja catering firma konkurendile andmeid firma finantsolukorra kohta), lähed vangi. Sellise lähenemise probleemiks on asjaolu, et karistuse rakendamiseks peab rikkumine olema avastatud. Paremini töötab süsteem, kus positiivsete julgustustega – kasvatus, koolitused – julgustatakse inimesi õigesti käituma.
Eetikaprobleem?
Andmete kuritarvitamine on internetiajastul ja informatsiooni leviku tõttu aina rohkem tähelepanu saav probleem. Sotsiaalvõrgustike teke on kodanikkonda probleemist informeerinud ning hiljutised seaduseelnõud – SOPA, PIPA, ACTA – on valitsuse vastus probleemiga tegelemiseks.
Tarkvaraarendaja igapäevaelus tuleb tihti ette olukordi, kus töötaja peab kasutama kliendi konfidentsiaalseid andmeid mingi toimingu soovitamiseks. Neil puhkudel tuleb võidelda oma sisemise minaga ning selgitada iseendale, et antud juhul on andmete kasutamine õigustatud ja vajalik. Selle lahingu kaotamisel tuleks sügavamalt üle vaadata andmete kasutamise põhjused. Selline käitumine tagab kliendi usalduse, soodustab ärisuhte jätkumist ning väldib probleeme andmekaitseorganitega.
Käitumisjuhised tarkvaraarendajale eetiliste probleemidega hakkama saamiseks
- Kui seisad ristteel – küsi nõu.Ülemuselt. Projektijuhilt. Kolleegilt.
- Säilita kliendi usaldus – ära kuritarvita konfidentsiaalseid andmeid
- Lähtu otsuste tegemisel ühiskonna tavadest ja ajaloost.
- Kasuta kõiki võimalikke meetmeid oma vigadest tingitud kahju minimeerimiseks.
- Informeeri ülemusi ja klienti nende poolt pakutud valikute tagajärgedest.
Viited
- http://computerethicsinstitute.org/publications/tencommandments.html
- http://en.wikipedia.org/wiki/Uncle_Ben#cite_note-10
- http://beta.wikiversity.org/wiki/IT_eetilised,_sotsiaalsed_ja_professionaalsed_aspektid/Tsensuur,_privaatsus_ja_Internet
Arendajad vs. Adminnid [Ad:minn-nnid] #1
[ N.B! Fiktsioon! ]
Ühel ilusal päeval läksid Arendaja ja Adminn omavahel kaklema. Seisid mehed ruumi 314 ukse ees ning vaidlesid igivanal teemal: Bill või Linus? Loengu algus lähenes ning sõnelus muutus järjest valjemaks. Meeste ümber tekkis juba väike ringki; oli oodata verd. Just siis ilmus kohale IT SPEA professor ning pakkus lahenduse: Arendajad ja Adminnid mõõtku oma vägevust võistlusega ning võitja saaks tolleks korraks sõnaõiguse.
Sõnelejad olid päri ning varsti olid koos ka mõlemad tiimid. Ka Analüütikud ja Suhtlejad valisid leerid. Prof. kõneles mikrofoni ning andis võistlejatele ülesande, ise mõeldes, et kumbki sellega hakkama ei saa, et tolleks korraks on jälle rahu majas: tiim, kes IT-vahenditega loenguruumi kardinad suudab üles tõsta, on võitja. Aega anti 20 minutit.
Adminnid olid rõõmsad ja tormasid kohe robootikaklubi ruumi (käpp sees) oma salaplaani hauduma. Arendajad üsna kurvad: lausearvutus ja mikroskeemid klaasakendele ei mõju. Siis tuli tiimi noorele Suhtlejale hea idee. Kiiresti tuvastati tiimiliikmetest Skype'i tüdruk ning asuti prototüüpi valmistama ja testima.
Määratud aja möödudes kutsus siis professor õpilased enda juurde ja käskis tulemusi demoda. Adminitel õnnestus eelmise Robotexi võitnud robot ümber ehitada ning elukake sibaski põrandale märgitud valget joont mööda kardinate juurde. Kuid oh häda! Adminnid ei ole Suhtlejad, nad ei tunne Javat! Loomake hakkas akende ees keerlema ning kukkus lõpuks haledalt piiksudes hoopis ümber! Adminnid olid küll kurvad, kuid vaatasid kahjurõõmsalt Arendajaid: kui mitte meie, siis vaevalt ka teie!
Arendajad kõndisidki vaikselt istekohtadele, vaid Suhtleja jäi prof. laua juurde. Ja tõusis siis Arendaja oma läpakaga ning loengut salvestavast kaamerast nähti:
god@god-desktop:~$ pythonPython 2.6.5 (r265:79063, Apr 18 2010, 10:29:56)[GCC 4.4.3] on linux2Type "help", "copyright", "credits" or "license" for more information.>>> import arendajate_skype>>> arendajate_skype.saada('Hei Katrin! Tõsta palun loenguruumi kardinad ülesse!')>>> A: SMS saadetud!>>> exit()god@god-desktop:~$
Rebasepäev
Kõigi juttude-reklaamide järgi pidavat täna olema Rebastepidu. Ja nädalalõpp, mis peaks nagu automaatselt tuju heaks tegema. Kahjuks ei olnud nii, sain ainsa positiivse elamuse paar minutit enne südaööd.
Otsustasin, et Java mulle peavalu tekitama ei hakka, vähemalt mitte järgmised 2-3 kuud. Olen juba 2 praktikumi ette ära teinud, seejuures ilma mingisuguse välise abita, v.a. Google (lahenduste juurde saab paremalt, menüülingist). Istusin siis rõõmsalt peale tunde ITK arvutiklassis (see on väga vägev, et tudengid saavad neid klasse kasutada. 21” monitori ja kiire arvutiga on ikka hea progreda). Ja siis avastasin, et arvuti kell oli vale ja ma magasin esimese rebaseürituse maha.
Pidevalt on alaõppimisest põhjustatud süümepiinad. Ma lihtsalt ei suuda end sundida füüsika/matemaatikale otsa vaatama. Sest mul on raske sellest aru saada. Samas, nagu juba mainitud, on Java nii huvitav, et…
Õhtu algas elevusega, Esinduse poolt organiseeritud bussid (2) viisid meid Tugamanni veskisse. Kaunis kohake. Tutvusin bussis ühikas ülakorrusel oleva kaastudengiga. Saabudes reastati meid ära ja kästi kollektiivselt 1.5l viina ära juua. Rektori kingitus. Peale seda läks jamaks. Järgmised 4h möödusid kuskil nurgas seistes. Fred pakkus veidi rummi. Järgmisele peole pean kindlasti enda alkoholi kaasa võtma. Esiteks annaks see mingi tegevuse, teiseks ei suuda ma ilmselt kainena mingilgi mõistlikul tasandil võõrastega suhelda.
Midagi väga positiivset siiski juhtus: minuga samas aines (Advanced English) olev Carolys oli lahke, vestles minuga ja pakkus pärast küüti koju. Pääsesin 2.5h varem peolt ning nautisin vaikset autosõitu kodu (ühikas) poole rohkem kui kogu ‘pidu’ kokku. Loodan, et saame sõpradeks. Ma ei tea ITK-st veel kedagi sama… haaravat, lahedat, sõbralikku, tagasihoidlikku.
Olen meie lahedas Esinduses veidi (või natuke rohkem) pettunud. Ootasin rohkem planeeritud tegevust.
About The Author
Ando “David” Roots is a college student and a software developer from Kunda, Estonia. Living, working and studying in Tallinn, he hopes to get his bachelor degree from the Estonian Information Technology College on IT Systems Development. 