Stöðluð lausn er hugbúnaður / kerfi sem nú þegar hefur verið þróað fyrir stóran viðskiptavinahóp og hefur möguleika á að vera aðlagaður að þörfum einstakra viðskiptavina, þegar tekið er mið af uppsetningu, mælikvörðum eða stillingum innan hugbúnaðar / kerfis.

Kostir

• Mest öll þróunarvinna er þegar búin og hugbúnaðurinn er nú þegar kominn á markað.

• Er í stöðugri þróun hjá seljanda.

• Venjulega eru staðlaðar lausnir ódýrari en að þróa lausn frá grunni.

• Lausnirnar hafa yfirleitt verið prófaðar ítarlega og sannreynst hjá öðrum fyrirtækjum.

Gallar

• Staðlaðar lausnir geta í flestum tilfellum ekki boðið upp á sérsniðna notendaupplifun.

• Geta í takmörkuðu magni sérsniðið og tengt annan hugbúnað, gagnagrunna og fleira við lausnina.

• Eiginleikar og virkni hugbúnaðarins eru háð þróunaráætlun birgjans.

Kröfur

Eignarhald á gögnum

• Gakktu úr skugga um að þú eða stofnunin þín eigið allar upplýsingar sem birginn/söluaðilinn geymir, og að þið hafið aðgang að þeim upplýsingum á einfaldan og þægilegan hátt. Þetta getur verið flókið viðbót við samninginn, en það er nauðsynlegt til að tryggja að stofnunin geti flutt gögnin yfir í annað kerfi ef nauðsyn krefur.

Tryggðu að notast sé við staðlað og algengt gagna form/tækni (opnir staðlar)

• í viðeigandi geira bæði þegar um er að ræða vistun gagna (output/export) og þegar viðkemur opnum API köllum.

• Hugbúnaðurinn þarf að bjóða upp á auðveldan gagnaflutning á stöðluðu, algengu sniði. Það gefur stofnuninni kleift að flytja gögn sín yfir í annað kerfi án verulegrar fyrirhafnar eða taps.

Þjónusta og viðbragðstími

• Skilgreinið kröfur um stuðning og þjónustu til að tryggja viðeigandi viðbragðstíma og gæði þjónustu.

Þarfir

• Kostur ef hugbúnaðurinn leyfir þér að sérsníða og stækka hugbúnaðinn t.d. sem styður við aðlögun og tengingar í gegnum API eða öðrum samþættingaraðferðum.

• Kannaðu möguleikann á margskýja-eða blandaða lausn. Þar sem hægt er að nota einkaský opinbera aðilans.

• Kostur ef staðlaða lausnin bjóði upp á aðgang að grunnkóða eða hann sé byggður á opnum hugbúnaði. Það veitir meiri stjórn og sveigjanleika.

• Kannaðu hver framtíðarsýn seljanda sé hugbúnaðinum og berðu saman við framtíðar áform stofnunarinnar.

Hvenær borgar sig að skoða aðra hugbúnaðarlausnir í stað staðlaðrar lausnar?

Að ákvarða hvort sé hagkvæmara að kaupa aðra tegund en staðlaða lausn frekar en að nýta staðlaða hugbúnaðarlausn (SaaS) veltur á ýmsum þáttum.

Það er mikilvægt að vega og meta kosti og galla allra valkosta í ljósi markmiða og þarfa kaupanda.

Hér eru nokkrir lykilþættir sem gott er að hafa í huga þegar ákveða skal hvort önnur tegund hugbúnaða henti betur en stöðluð lausn (SaaS-hugbúnaður):

Kostnaður og fjárfesting

Ef mikil óvissa er fyrir hendi varðandi kostnað hugbúnaðarlausnarinnar, eða leyfisgjöld eru hærri en kostnaðaráætlun gerir ráð fyrir gæti verið ráðlegt að opna á aðrar tegundir af hugbúnaði og fá verðhugmyndir þar sem allir þættir á borð við, þróun, uppsettningu, þjónustu og fleira er tekin inn í mengið yfir t.d. 3-4 ára tímabil.

Ef kostnaður við viðbætur eða sérsmíði við staðlaða lausn er mögulega mikill er ráðlegt að skoða aðrar tegundir hugbúnaðar eða brjóta hugbúnaðinn upp og leysa t.d. að hluta með staðlaðri lausn annars vegar og öðrum hugbúnaði hins vegar.

Mismunandi tegundar greiðslufyrirkomulags

Þegar þú kaupir hugbúnað, hvort sem um ræðir "hilluvöru" eða staðlaðan hugbúnað (þekkt sem SaaS), eru mismunandi tegundir af greiðslufyrirkomulagi í boði.

Hvaða fyrirkomulag hentar best fer eftir þörfum- og langtímastefnu opinbera aðilans ásamt eðli hugbúnaðarins. Gæta þarf að því að við útreiking þarf ávalt að taka mið að fjögra ára samning eða skemmri.

Hér fyrir neðan er farið í mismunandi tegundir af greiðslufyrirkomulagi þegar kemur að stöðlum lausnum. Gott er að hafa á bak við eyrað að í sumum tilfellum, sérstaklega ef þörf á sérsmíði, viðbótum eða séraðlögunum er mikil þá gæti verið ráðlegt að kanna möguleikana á Power Apps eða sérsmíðaðri lausn.

1. Einnskiptiskaup (Perpetual License)

Greitt er einu sinni fyrir varanlegan aðgang að hugbúnaðinum. Er áskriftarleið á útleið, þar sem aðrar leiðir hafa tekið við.

Kostir:

• Þú eignast hugbúnaðinn og þarft ekki að endurnýja leyfi.

• Langtímakostnaður getur verið lægri ef hugbúnaðurinn er notaður í mörg ár.

Gallar:

• Uppfærslur og stuðningur eru oft ekki innifalin og geta kostað aukalega.

• Hentar illa ef hugbúnaðurinn þarf ítrekaðar uppfærslur.

2. Áskriftarlíkan (Subscription Model)

Greitt er mánaðarlega eða árlega fyrir aðgang að hugbúnaðinum, oftast meðfylgjandi uppfærslum og stuðningi. Sérstaklega vinsæl leið þegar kemur að smáforritum (Öppum) og hugbúnaði þar sem um reglulega notkun er að ræða.

Kostir:

• Fastur kostnaður gerir auðveldara að skipuleggja kosnaðinn.

• Sveigjanlegt og auðvelt að hætta við ef þörf er á.

Gallar:

• Getur orðið dýrt til lengri tíma litið.

• Aðgangi er oftast lokað ef rof verða á greiðslum.

3. Greiðsla eftir notkun (Pay-as-You-Go)

Greitt er eftir raunnotkun, til dæmis fjölda notenda, vinnutíma eða vinnslugetu. Vinsæl leið þegar kemur að skýjaþjónustum þar sem notkun er sveiflukennd.

Kostir:

• Hentar vel fyrir sveiflukennda notkun.

• Greitt er einungis fyrir raunverulega notkun.

Gallar:

• Kostnaður getur orðið ófyrirsjáanlegur ef notkun eykst skyndilega.

4. Freemium líkan

Grunnútgáfa hugbúnaðar er ókeypis en aukagjöld eru tekin fyrir auka fítusa eða viðbótarþjónustu.

Kostir:

• Lágur byrjunarkostnaður.

• Hentar til að “prófa” hugbúnað áður en greitt er fyrir fulla virkni.

• Hentar er þarfir eru allar leystar með freemium útgáfunni en svo þarf að teka með í reikninginn viðbótar virkni sem hægt er að kaupa.

Gallar:

• Takmörkuð virkni í ókeypis útgáfu.

• Aukakostnaður getur hlaðist hratt upp.

5. Opinn hugbúnaður með þjónustusamning (SLA)

Hugbúnaðurinn er ókeypis eða ódýr, en fyrirtæki greiða fyrir þjónustu og sérsniðnar lausnir. Þessi leið er notuð af birgjum sem nýta opinn hugbúnað og sérsníða lausnina að þörfum kaupanda og geta því boðið lægri grunnkostnað.

Kostir:

• Sveigjanleiki til að sniða staðlaðan hugbúnað að þörfum kaupanda og byggja því ofaná reynslu annara.

• Lágur grunnkostnaður.

Gallar:

• Krefst tæknilegrar kunnáttu.

• Þjónusta og auka þróun getur verið kostnaðarsöm.

6. Leyfisgjald eftir notendum (User/Seat-Based Licensing)

Greitt er fast gjald fyrir hvern notanda eða vinnustöð sem nýtir hugbúnaðinn.

Kostir:

• Auðvelt að reikna heildarkostnað.

• Hentar vel fyrir stór fyrirtæki með fastan fjölda starfsmanna. (Fer þó eftir hvað hugbúnaðurinn er að leysa og hvert verðið er.

Gallar:

• Kostnaður hækkar með fjölda notenda.

• Takmarkaður sveigjanleiki.

7. Skýjalausnir með áskrift

Hugbúnaðurinn keyrir í skýinu og greiðsur fara eftir áskriftarleið.

Kostir:

• Ekki þörf á uppsetningu eða viðhaldi á staðnum.

• Auðvelt aðgengi hvaðan sem er.

Gallar:

• Krefst stöðugrar nettengingar.

• Getur orðið kostnaðarsamt til lengri tíma.

• Erfitt að bera saman við aðrar áskriftarleiðir þar sem innihaldið er mismunandi.

Val á réttu fyrirkomulagi

Við val á réttu fyrirkomulagi þarf að skoða stærð opinbera aðilans, þar sem Freemium líkan hentar oft minni aðilum en t.d. áskriftalíkönin henta stærri aðilum sökum fyrirsjáanlegs kostnaðar og meiri aðlana að þeirra þörfum.

• Eftir stærð opinbera aðilans.

  • Freemium líkan getur hentað þar sem greiðslur eru eftir notkun eða til að lágmarka byrjunarútgjöld.

  • Þessar fyrirmyndir gera kleift að prófa án langvarandi fjárhagslegrar skuldbindingar.

• Notkun opinbera aðilans

  • Ef mikil og regluleg notkun er fyrirsjáanleg gætu áskrifta líkönun boðið uppá hagstæðustu kaupin.

  • Ef notkunin eða breytileg gæti borgað sig að greiða eftir notkun.

• Virkniþarfir

  • Ef staðlaði hugbúnaðurinn uppfylir allar þarfir kaupanda sem freemium líkan þá er vert að skoða þann möguleika.

  • Ef þörf á flóknari kerfum með þróaðri eiginleikum eða aðlögnum er hægt að mæla með að skoða áskriftar líkön þar sem þau veita oftar en ekki fullan aðgang að auka einingum og virkni.

Til að velja rétta greiðslufyrirkomulag þarf að hafa eftirfarandi atriði á hreinu.

Hámörkun arðsemi af greiðsluvalmöguleikum.

• Fylgjast þarf vel með notkun, þar sem þarfir geta breyst og notkun lausnarinnar getur verið léleg að hún ranglega notkuð.

• Stjórna þarf og hafa yfirsýn ufir leyfi. Gæta þar að því að leyfanotkunin sé í samræmi við raunverulegar þarfir.

Þegar kemur að vali á greiðslufyrirkomulagi skiptir máli að horfa til langtímamarkmiða, fjárhagsáætlunar, notkunar- og eðli hugbúnaðarins. Hvort sem val er á freemium, Pay-as-You-Go eða áskriftarlíkani, þá er lykilatriði að tryggja árangur með eftirfyglni og stjórn.

Hillulausn er hugbúnaður sem er tilbúinn og til í notkun strax eftir að hann hefur verið keyptur, án þess að þurfa sérsníði eða þróun. Hann er hannaður sem almenn lausn fyrir margvíslega notendur og hefur yfirleitt staðlaða eiginleika sem mæta algengum þörfum á ákveðnu sviði.

Körfur og þarfir Staðlaðra lausna ná til Hillulausna.

Ef nauðsyn er á að bæta við viðbótum eða sérsmíða einingu svo staðlaði hugbúnaðurinn uppfylli allar/flestar kröfur og þarfir kaupanda þarf að hafa það í huga:

• að seljandi á, í flestum tilfellum þær einingar og viðbætur sem þróaðar eru innan staðlaða hugbúnaðarins.

• að kaupandi þarf að kanna hvers eðlis viðbótin er og hvar hún eigi heima

  • Innan staðlaðrar lausnar - seljandi er eigandi viðbótana og getur selt/nýtt hjá öðrum viðskiptavinum. Kröfur er varða staðlaðar lausnir eiga hér við.

  • Utan staðlaðrar lausnar - seljandi þróar ekki viðbætur við lausn sína eða kaupandi vill annan aðila til að þróa viðbótina.

• að stundum er ódýrara að nýta aðrar tegundir hugbúnaðar eða mismunandi birgja af sama hugbúnaði til að uppfylla þörfina. Eða blanda tegundum hugbúnaðar saman.

Hægt er í mörgum tilfellum að nýta virkni annars hugbúnaðar, kerfis eða gagnasafns með því að tengja það við stöðluðu lausnina í gegnum API tengingu með viðkomu í millilagi eða gegnum power platform lausn.

Ef um ákveðna nýja virkni hluta er að ræða sem ekki eru tengdir með API við stöðluðu lausnina heldur sérþróaðir af seljanda þarf að gera kröfur um eftirfarandi:

• Fá aðgang að tæknilýsingu og skjölun sérsmíðaða virknihlutans er snýr að viðskiptavininum.

• Ef seljandi notast við einingar (modules) , innskot (plugins) og framlengingar (extensions) frá þriðja aðila er krafa að kaupandi sé skráður eigandi/leigjandi.

• Ef það er ekki hægt þarf kaupandi að tryggja að hann hafi rétt á að:

  • Nota einingarnar eða gagnasöfnin

  • Breyta einingum eða gagnasöfnum (kaupandi sjálfur, 3 aðili eða verktaki).

  • Taka einingarnar / gagnasöfnin ef kaupandi vill selja hugbúnaðinn.

  • Framselja þessi réttindi til allra þeirra sem þig lystir.

Til að mynda falla ERP, CRM og BI kerfi undir þennan flokk ásamt flest gagnavörslukerfi.

Power Platform frá Microsoft er dæmi um "low code" hugbúnaðarkerfi sem tekur stöðugum framförum með aukinni sjálfvirkni.

Power Platform samanstendur af fimm meginstoðum

• Power BI – Viðskiptagreindar tól til skýrslugerðar.

• Power Apps – Notað til að búa til lausnir og forrit fyrir stafræna ferla.

• Power Pages - Vefsíður settar upp með einföldum hætti.

• Power Automate – Notað til að búa til sjálfvirk verkferli og tengingar/samþættingar á milli hugbúnaðarkerfa.

• Power Virtual Agents – Snjallmenni til samskipta við viðskiptavini og milli starfsmanna

Power Platform og samspil milli þessara eininga býður eitt og sér upp á mikla möguleika en einnig er hægt að vinna upplýsingar og smíða sjálfvirk ferli þvert á viðskiptakerfi og skýjalausnir Microsoft.

Kostir

• Hröð þróun, hægt er að þróa og setja í gang forrit mjög hratt. Þetta gildir sérstaklega fyrir opinberar stofnanir sem þurfa lausnirnar fljótt.

• Lítill, jafnvel engin forritun (coding). Hægt er að setja hugbúnaðinn í gang án þess að hafa viðamikla forritunar þekkingu.

• Samþætting of auðveld við annan hugbúnað, gagnavörslur og fleira. T.d. Microsoft Power Platform flæðir vel saman við vörur frá sama fyrirtæki.

• Skalanleiki þjónustu er oft mjög góður þar sem Power Platform lausnir eru byggðar á skýjalausnum.

• Uppfærslur, öryggi og viðhald er í höndum eiganda Power Platform lausnarinnar sem sér um að fyllsta öryggis sé gætt.

Gallar

• Kostnaður við leyfisgjöld getur oft verið íþyngjandi fyrir opinberar stofnanir og því mögulega ódýrara til langs tíma að notast við aðrar lausnir.

• Lausnin gæti takmarkað sérsmíði og viðbætur.

• Hækkanir á gjaldskrá háðar eiganda lausnar.

• Erfitt gæti reynst að skipta um birgja sem er með annað en Power Platform.

• Þegar hið opinbera er að huga að kaupum á Power Platform lausn eða sambærilegu kerfisforrit (platform) lausn þarf að hafa nokkra sértækar þarfir í huga.

Sérlausn er sérstaklega þróuð hugbúnaðarlausn fyrir sértækan viðskiptavin. Val á þessari leið hentar best ef þarfir og kröfur opinbera aðilans eru það sértækar að engar staðlaðar lausnir ná utan um þær. Því er nauðsynlegt að kanna hvað er í boði á markaðnum áður en ákveðið er að velja sérlausnarformið.

Mikilvægt er að setja fram á greinargóðan máta þær kröfur, þarfir og forskriftir (Specifications). Ítarlegar kröfulýsingar og þarfir sína bjóðendum strax hvort að sérþekking þeirra sé nóg til að bjóða uppá góðar lausnir.

Kostir

• Algerlega sérsniðin að þörfum hins opinbera og ætti að uppfylla allar þarfir sem koma fram í þarfalýsingu.

• Mögulegt að búa til einstaka eiginleika og viðbætur sem ekki eru í boði í stöðluðum lausnum.

• Hið opinbera er með fulla stjórn á gögnum, uppbyggingu, þróun og virkni hugbúnaðarins.

Gallar

• Tekur langan tíma að þróa lausnina frá grunni.

• Hár upphafskostnaður þar sem það þarf að fjárfesta í þróun, hönnun, prófun og útgáfu.

• Mikil viðhaldsábyrgð þar sem það þarf að fjárfesta í uppfærslum, öryggis prófunum og viðhaldi hugbúnaðarins.

Almennt hugbúnaðarþróunarferli sérlausna

Hugbúnaðarþróunarferli er saman sett af nokkrum fösum. Fasarnir geta breyst eftir mismunandi hugmyndafræði sem þróunaraðili notar hverju sinni og er oftar en ekki mun ítarlega en þetta almenna ferli sem sjá má hér að neðan.

Í megin dráttum má áætla að fasarnir séu 7

Ef krafa er sett um stigvaxandi hlutaskil/fasa þarf að vera ákvæði um endurskoðun og eftirlitsfundi. Þannig fær stofnunin betra tækifæri til að skoða framvindu, veita endurgjöf og tryggja að verkefnið haldist á réttri braut. Einnig ef verkefnið er sundur liðað, þá er auðveldara að færa verkefnið yfir til annars birgja ef þörf krefur.

Hönnunarfasi

Þegar kemur að viðmótshönnun hugbúnaðar, þá notendaviðmót (UI) og notendaupplifun (UX) fyrir hið opinbera þarf að taka að huga að notendamiðaðri nálgun.

Hér fyrir neðan eru almenn skref sem hönnunarstofur eða hugbúnaðarhús taka við viðmótshönnun hugbúnaðar.

Kröfur um hönnun og notagildi (UI og UX)

Gera þarf kröfu um aðgengi fyrir alla.

Einn af mikilvægustu þáttunum eru að gengismál. Hugbúnaðurinn á að vera aðgengilegur öllum, þar á meðal fólki með fötlun. Það er því nauðsynlegt að fylgja viðmiðum eins og Web Content Accessibility Guidelines (WCAG) til að tryggja að allir geti notað hugbúnaðinn. Hið opinbera ætti að stefna að því að ná WCAG AAA staðli en þó ávallt ná AA staðli þegar kemur að hönnun á hugbúnaði er snýr að ytri þjónustu opinbera aðilans.

Þarfir sem þarf að hafa í huga

Huga þarf vel að skalanleika (scalability)

• Þó er það ekki altækt. Ef hugbúnaðurinn er veflausn sem snýr að almenningi þarf að huga vel að skalanleika út frá mismunandi tækjum.

Taka þarf tillit til ýmissa mismunandi menningarþátta (Inclusitivity),

• Til dæmis aldurs og annara þátta til að tryggja að hugbúnaðurinn útiloki ekki neinn hóp fólks.

Hönnun þarf að vera einföld (Intuitive design)

• Ef endanotandinn er almenningur þarf sérstaklega að hafa í huga að það þurfi ekki mikla þjálfun eða tækniþekkingu til að nýta sér þjónustuna sem hugbúnaðurinn býður upp á.

Leiðsögn í gegnum hugbúnaðinn þarf að vera skýr (Clear navigation)

• Þá sérstaklega sá hluti er snýr að almenningi. Skýrar merkingar, fyrirsagnir, rökrétt uppbygging og auðvelt viðmót þarf að vera til staðar.

Hönnunin þarf að vera samræmd og samkvæmt sjálfri sér (Consistent)

• Í gegnum allan hugbúnaðinn til að hjálpa notendum að skilja og spá fyrir um hegðun mismunandi hluta hugbúnaðarins.

Hugbúnaðurinn ætti að gefa skýra endurgjöf (Feedback)

• Um það sem notanda er að gera og þarf að gera. Má þar nefna villuskilaboð og leiðbeiningar sem þurfa að vera leiðbeinandi og skýrar.

Auðvelt aðgengi þarf að vera að hjálp og skjölun í opinberum hugbúnaði.

Hafa ber hraða í huga við hönnun hugbúnaðar

• Mælt með að vinnslutími veflausna t.d. sé undir 3 sec, þó er það ekki altækt en setja þarf hraða markmið í þarfalýsingu hugbúnaðarins.

Með því að gæta þessara þátta munu opinberir aðilar ekki aðeins fjárfesta í hugbúnaði sem er gagnlegur, heldur einnig í lausnum sem hægt er að nýta fyrir víðtækan notendahóp.

Almennar tæknilegar kröfur

Krafa um framsetningu á tæknilegum arkitektúr

Setja þarf fram tæknilegt skema/flæðirit er varðar tæknilegan arkitektúr þar sem hönnun á kerfis uppsetningu er útskýrð með tilliti til samspils milli eininga, kerfa og þátta þannig að nauðsynlegar kröfur sem hugbúnaðurinn þarf að uppfylla eru uppfylltar.

Krafa um forritun / forritunartungumál

Hvaða forritunartungumál er notað skal vera ákveðið af kaupanda. Þó ber að hafa í huga að velja vinsælt tungumál sem er öruggt, í þróun og nú þegar í almennri notkun á markaði. Í kröfulýsingu er mælt með að ef ekki er þörf á sértæku tungumáli er ráð að lista upp nokkrum tungumálum til að opna á sem flesta birgja, með þeim fyrirvara sem fjallað er um hér að ofan.

Gerðu kröfur um að kóðinn sé vel læsilegur og uppbyggður, skipt niður í einingar og sé í samræmi við bestu venjur iðnaðarins (industry best practices). Það mun auðvelda öðrum hugbúnaðarteymum að skilja, breyta eða viðhalda kóðanum ef þörf krefur.

Setja þarf fram skýrar kröfur er varðar hugbúnað, íhluti, gagnasöfn (libraries) og þjónustur.

Hámarka þarf sjálfstæði frá þriðja aðila með því að velja mikið notaðar, vel þjónustaðar og studdar lausnir sem byggðar eru upp á opnum hugbúnaði og settar upp á þann hátt að hægt sé að skipta þeim út.

Kröfur er varðar kóðageymslu

Kóði þarf að vera vistaður í GitHub ásamt lýsigögnum kóða (documentation) sbr. Kröfur frá Stafrænu Íslandi.

Krafa skal gerð um skiptingu á milli virkni hluta hugbúnaðar

Aðskilnaður þarf að vera á milli bakenda, framenda (SPA) og millilags og hlutarnir tengdir saman í gegnum viðurkennt API viðmót. Þessi krafa er lögð fram svo auðveldara er að skipta út virkni hlutum án þess að brjóta heildarlausnina.

Krafa skal gerð uppskiptingu hugbúnaðarins í virknieiningar eftir hlutverki.

Hafa ber í huga við útfærslu virkni og virkni eininga að skipta hugbúnaðinum upp í einingar eftir hlutverki. Hægt verður þá að bjóða hverja einingu út fyrir sig eða allar saman. Þó verða einingarnar að vera byggðar upp með sama kóðagrunni eftir nákvæmum forskriftum svo þær tengi örugglega við aðrar einingar.

Krafa um auðkenningu á milli framenda og bakenda

Eftir auðkenningu skal nota við staðlaðar lausnir fyrir auðkenningu á milli framenda og bakenda.

Passa þarf upp á líftíma tóka, en í skjölun þarf hann að koma fram.

Tóka má ekki senda nema tengingin sé byggð á HTTPS. Öll samskipti þurfa að vera dulkóðuð í öllum samskiptum yfir netið og við gagnageymslur þar sem við á.

Krafa skal gerð um ýtarlega skjölun og skil tækniupplýsingu.

Dæmi um skjöl sem þarf að krefjast eru:

Tækniskjöl

• Skjöl með nákvæmum lýsingum af hugbúnaðinum, arkitektúr, hönnun, API tengingum og háðum einingum, hvort þá sem hefur verið sér smíðaður eða staðlaður, sérstillingum, rekstrarháttum og tengslum þeirra á milli.

Uppsetningarleiðbeiningar.

• Skjölun er varðar rekstrarlega tilhögun er kemur að öryggisafritum (hversu oft afrit eru tekin) og hvaða leiðbeiningar varðandi eftirlit hugbúnaðarins.

Notenda Skjöl

• Ítarleg lýsing á virkni hugbúnaðarins og sérstillinga.

Lýsingar á ofurnotanda (super-user / admin) ásamt notendavirkni eftir mismunandi notendum.

• Skjölun þarf að vera uppfærð miðað við nýjustu útgáfu staðlaða hugbúnaðarins ásamt viðbótum.

Skjölun sérstillinganna verður að vísa til viðeigandi hluta skjalagerðar staðlaða kerfisins, svo auðvelt sé að tengja hina ýmsu hluta skjala innbyrðis.

• Tilgreina þarf með skýrum og ótvíræðum hætti hvaða hlutar skjala staðlaða kerfisins, ef einhverjir eru, skipta ekki máli vegna þeirra sérstillinga sem gerðar hafa verið, svo og hvað, ef eitthvað, kemur í stað slíkra úreltra gagna.

Kröfur er varða innskráningu innan stofnunar

Ef innskráningarþjónusta Ísland.is hentar ekki fyrir hugbúnaðinn þarf að hafa eftirfarandi þarfir í huga.

Krafa skal gerð varðandi öryggi og verndun persónuupplýsinga:

• Það er mikilvægt að innskráningarþjónusta veiti hámarks öryggi og verndi notendaupplýsingar. Þetta felur í sér notkun sterkra lykilorða, tveggja-þátta auðkenningu og dulkóðun upplýsinga.

Krafa skal gerð varðandi sveigjanleika og stækkunarmöguleika:

• Þjónustan ætti að vera nógu sveigjanleg til að hægt sé að aðlaga hana að breyttum þörfum notenda og vaxandi umfangi.

Krafa skal gerð varðandi samhæfni við önnur kerfi:

• Gætið þess að innskráningarþjónustan sé samhæfanleg við önnur kerfi sem þú notar eða gætir þurft að nota í framtíðinni.

• Þegar kemur að innskráningu inn í lausnir er snúa að almenning þarf að nýta innskráningarþjónustu Ísland.is https://island.is/innskraningarthjonusta

Þarfir er varða innskráningu innan stofnunar

Stuðningur og viðhald:

• Það er mikilvægt að þjónustuveitandi bjóði upp á góðan stuðning og reglulegt viðhald á kerfinu.

Notendavæn viðmót:

• Innskráningarþjónustan ætti að vera auðvelt í notkun fyrir notendur, með skýrum leiðbeiningum og einföldum ferlum.

Krafa varðandi opinn hugbúnað

Þegar rætt er um Opinn hugbúnað (FOSS) er átt við hugbúnað undir ákveðnum leyfum sem gerir notendum kleift að fá aðgang að frumkóða í skiptum fyrir ákveðnar skyldur sem tengjast dreifingu á opnum kóða.

Opinn hugbúnaður er þróaður í samvinnu-samfélagi þróunaraðila og er grunnkóðinn aðgengilegur almenningi. Það þýðir að allir geta nálgast, breytt og dreift honum að vild. Margir kostir eru við það að velja opinn hugbúnað og má þar nefna.

• Hagkvæmni.

  • Opinn hugbúnaður er oftar en ekki ókeypis í notkun eða hægt er að kaupa með lægri tilkostnaði en að þróa frá grunni í séreignarkóða.

• Sérsníði auðveld.

  • Þar sem grunnkóðinn er opinn og tiltækur, geta notendur sérsniðið og breytt hugbúnaðinum eftir þörfum án þess að fara í það að skrifa frá grunni.

• Stuðningur samfélags.

  • Að baki opnum hugbúnaðar er stórt samfélag þróunaraðila sem vinna saman að opnum verkefnum með stuðning við hvorn annan í formi ráða, yfirferðar og fleira.

• Opin hugbúnaður er þróaður með opnu hugbúnaðarþróunarferli

  • Sem eykur á gagnsæi, öryggi og traust.

  • Opinn hugbúnaður er einnig almennari

  • Auðveldara að skipta um birgja ef opinn kóði er notaður í algengu forritunarmáli.

Við sérsmíði þarf að gera kröfu um að hugbúnaðurinn sé;

• Þróaður með opnum hugbúnaði (Free and open source, FOSS)

• Kaupandi þarf að geta gefið út kóða með opnu hugbúnaðarleyfi (open source licenses, t.d. MIT leyfi fyrir kóða og CC BY 4.0 fyrir skjölun).

• Vinsælu og áreiðanlegu forritunarmáli.

• Þróaður með sveigjanleika og endurnýtanlegum kóða í huga.

Körfur er varða veflausnir

Ef um hugbúnað er að ræða sem dreift er yfir netkerfi (innranet / veraldarvefinn) og er aðgengilegt í gegnum vafra þá er verið að ræða um veflausn. Kröfur er varða sérlausnir eiga við veflausnir en þó eru til sértækar kröfur ef um veflausn er að ræða.

Hægt er að velja um mörg mismunandi form af veflausnum. Algengast er að velja hefðbundna veflausn með vefumsjónarkerfi (CMS) eða höfuðlaust fyrirkomulag.

Íhuga skal kröfur verkefnisins, tæknilega getu og markmið þegar stofnun ákveður á milli hauslaus fyrirkomulags og hefðbundins CMS. Hauslaust fyrirkomulag hentar betur fyrir margrása/tækja efnisflutning og sveigjanleika, en hefðbundið CMS veitir einfaldari, allt-í-einn lausn fyrir vefmiðuð verkefni sem byggja á breytileika og útlit birtingar efnis.

Grunnkröfur fyrirkomulaganna beggja eru listaðar upp hér að neðan.

Kröfur er varða vefumsjónarkerfi (CMS)

Þegar veflausn er þróuð gæti hefðbundið CMS kerfi hentað betur ef ákveðnar þarfir hafa verið settar fram í þarfagreiningu.

Hefðbundið CMS kerfi er oftar en ekki „allt í einni“ lausn þar sem innbyggð sniðmát, einingar og þemu sett upp í hönnunarstaðli stofnunar. Getur það auðveldar uppsetningu- og innsetningu efnis ásamt gert stjórnun veflausnarinnar auðveldari og í miklum mæli í höndum stofnunar.

Hröð útgáfa er einn af kostum hefðbundins CMS kerfis þar sem stofnun getur búið til vefsíðu/vefforrit mjög hratt án utanaðkomandi aðstoðar þjónustuaðila.

Þar sem innan stofnunar er oft takmörkuð þekking, reynsla og þróunarmöguleikar af forritun. Þar koma forsniðin sniðmát og tengingar sér vel sem hefðbundið CMS kerfi býður upp á.

Kröfur til vefumsjónarkerfis

• Byggir á opnum hugbúnaði (Open source)

• Kerfi þarf að styðja við vinnslu með stöðluðum tólum og aðferðarfræði.

• Kerfið þarf að vera þaulreynt og sé í mikilli notkun helst hér á landi.

• Samhæfi við helstu tækni og vafra

• Stjórnborð þarf að vera til staðar fyrir vefstjóra

• Kerfið þarf að bjóða uppá einfalda breytingastýringu/atburðaskráningu (Log)

• Upplýsingar um heilsu kerfis.

• Sjálfvirk atburðaskráning aðgerða fyrir rekjanleika á aðgerðum í kerfinu.

• Hægt þarf að vera að „bakka“ með breytingar sem gefnar hafa verið út.

• Hvað er skráð (Logged)

• Hverju var breytt (Útgáfusaga síðna/eininga fyrir rekjanlega breytingu)

• Hver gerði breytingarnar

• Innsetning efnis og efnisumsýsla skal vera á höndum fulltrúa verkkaupa án aðkomu verksala.

  • Með efnisumsýslu er hægt að uppfæra, breyta og setja inn nýtt efni, s.s. myndir, texta og aðrar tegundir efnis.

  • Nota fyrirfram skilgreindar uppsetningareiningar

  • Notað fyrirfram hannaðar/kóðaðar viðmót einingar/síður.

• Skráasafn vefsíðunnar skal endurspegla veftré síðunnar.

  • Huga þarf að tengingu milli efnis.

  • Sama efni skal ekki vistað á mörgum stöðum í vefumsjónarkerfinu.

  • Kerfið þarf að búa yfir tag möguleika.

• Bjóðandi skal bera ábyrgð á öryggi og rekstri vefumsjónarkerfisins.

  • Auðvelt á að vera að uppfæra í nýjustu útgáfu kerfisins, m.a. sé auðvelt að uppfæra vegna öryggis.

    • Sjálfvirkar uppfærslur

    • Kerfisstjóri þarf að geta uppfært.

  • Tryggja þarf að uppfærslur vefumsjónarkerfis muni ekki hafa neikvæð áhrif á veflausna sem felur í sér:

    • Breytta virkni til hins verra

    • Verri notendaupplifun

    • Lausn í heild eða einingar verði óvirkar.

  • Stórar kerfisuppfærslur séu inn í samning.

    • Uppfæra þarf fyrst dev/test umhverfi og gera prófanir áður en uppfærslan er færð yfir á prod umhverfið.

  • Öryggi

    • Ef öryggisveikleikar uppgötvast í vefumsjónarkerfi skal láta kaupanda vita og vinna í sameiningu að því að uppræta veikleikann.

    • Úttekt þarf að vera framkvæmd af óháðum þriðja aðila og framkvæmd í samráði við verksala.

Kröfur er varða hauslaust fyrirkomulag

Hauslaust fyrirkomulag (Headless) getur verið fýsilegur kostur ef þörf er á auknum sveigjan- og skalanleika miðað við hefðbundin CMS kerfi. Með því er átt við að koma til móts við þá þörf að birta efni á mörgum vettvöngum/rásum í einu. t.d. vef, farsíma (app), IoT tækjum með API en ekki útlit birtingarinnar (sem er staðlað í hauslausu fyrirkomulagi). Ef kröfur eru gerðar um birtingu sem þessa og ekki er þörf á efnisgerð, sniðmátum eða slíku gæti höfuðlaust fyrirkomulag hentað.

Þetta fyrirkomulag er mjög opið hvað varðar hvaða framendatækni stofnun vill nota þar sem það er ekki tengt neinu CMS kerfi sem oft byggir á einstaka tækni. Með því að nota hauslaust fyrirkomulag getur stofnun því valið um þá tækni sem hentar best, þá t.d. React, Angular og Vue. Þó mælum við ávallt með að nota React sem Stafrænt Ísland hefur valið í sinn tæknistakk.

Með því að velja þetta fyrirkomulag getur lausnin þín mögulega verið auðveldari viðureignar þegar kemur að breytingum og aðlögunum að nýrri tækni, kerfum og tækjum án þess að þurfa að breyta bakendanum þar sem tengingarnar eru í flestum tilfellum API.

Ef stofnun býr svo vel að hafa sitt eigið þróunarteymi sem hefur reynslu af framendaforritun og þróun og kýs frekar að vinna með API gæti opnast breiðari vettvangur fyrir það að velja þau verkfæri og þá tækni sem teymið vill nýta og þannig dregið úr þróunar- og viðhaldsflækjum

Kröfur sérlausna ná einnig til hauslausa fyrirkomulagsins.

Kröfur varðandi tíma- og verkáætlun sérlausna

Áætlunin þarf að fela í sér þróunarferli hugbúnaðarins, samsetningu, uppsetning, viðtökuprófanir og reynslutíma. Hér er átt við áætlun um þróun hugbúnaðar og samsetningu. Í henni þarf einnig að koma fram afhendingartími ásamt öðrum dagsetningum sem skipta máli. Verkáætlunin ætti að vera útbúin þannig að auðvelt sé að sannreyna hvort við hana hafi verið staðið.

Hugbúnaðarþróunin þarf að vera skipulögð á þann hátt að hún skiptist í þróunarlotur sem enda á útgáfu eftir prófanir og uppfyllt samþykktarviðmið.

Hægt er að gefa út á þróunarumhverfið til prófunar eingöngu, eða eftir prófanir að hægt sé að gefa út hluta hugbúnaðarins.

Verk- og tímaáætlun þarf að innihalda:

• Útgáfuáætlun (Release plan)

• Prófunaráætlun

Útgáfuáætlun

• Setja þarf saman útgáfuáætlun (Release plan) innan verkáætlunar. Verður hún að innihalda heildarlýsingu hverrar útgáfu og tímasetningu hennar.

• Hver útgáfa þarf að fela í sér sérstakar prófanir sem eiga sér stað í þróunarumhverfi hugbúnaðarins áður en að útgáfu kemur. Söluaðili ber ábyrgð á að hver útgáfa sé þannig samsett að hægt sé að prófa ítarlega með hliðsjón af áhrifum hennar á aðra innbyrðis þætti.

• Endurskoða þarf útgáfuáætlunina reglulega og uppfæra til þess að taka tillit til breyttra aðstæðna þegar kemur að þróun, prófanir, mannauðs og fleira. Í hvert sinn er breytingar eru gerðar á útgáfuáætluninni þarf að kanna hvort þörf sé að endurskoða prófunaráætlun og verk-og tímaáætlun svo hún sé hvað raunsæjust. Endurskoðun verks- og áfangaáætlunar sem stafa af aðstæðum sem verksali ber ábyrgð á mega ekki leiða til dráttar á umsaminni áætlaðri afhendingu. dagsetningu afhendingarinnar í heild.

Prófunaráætlun

Að setja upp prófunaráætlun í hugbúnaðarþróun er nauðsynlegt til að tryggja gæði, virkni og öryggi hugbúnaðarins.

• Opinberi aðilinn í samstarfi við birgja skilgreinir markmið og viðmið prófunar áætlunarinnar. Nauðsynlegt er að öll markmið komi fram. T.d. er verið að tryggja ákveðna virkni, finna vandamál eða bæði? Varðandi viðmið þá er verið að tala um hvað þarf prófunin að uppfylla til að teljast vel heppnuð.
  

• Í prófunaráætlun þarf birgi að skilgreina:

  • Hvaða próf hann mun framkvæma.

  • Hvaða tól hann mun nota

  • Tímaáætlun og setja fram,

  • Gögn sem þarf og undirbúa þau.

• Og segja til um hvernig framkvæmd mun fara fram

  • Hvernig endurskoðun er háttað eftir að niðurstöður hafa verið birtar og gallar greindir.

Þessi skref eru aðeins upphafspunktur og þú gætir þurft að sérsníða þau eftir þörfum og aðstæðum opinbera aðilans.

Kröfur varðandi innleiðingu og skil sérlausna

Skilgreining hvenær verki sé lokið (Definition of done (DoD)

Í hugbúnaðarþróun, sérstaklega í Agile aðferðafræði eins og Scrum, vísar "Skilgreining á lokið" (DoD) til skýrrar og sameiginlegar skilgreiningar á þeim viðmiðum/kröfum sem verða að vera uppfyllt/ar áður en hægt sé að skilgreina að verkefni sé lokið.

Með öðrum orðum, þá er þetta listi yfir kröfur um eiginleika hugbúnaðarins eða aðgerðir sem verkefnið þarf að vera búið að leysa áður en það telst lokið.

Að skilgreina verkefnalok er gert til að:

• Tryggja samræmi, svo allir meðlimir verkefnis hafa sameiginlegan skilning á því hvað það felur í sér.

• Setja væntingar, svo hagsmunaaðilar hafi skýrar væntingar um gæði og hvert frumstig verkefnisins verður.

• Minnka endurtekna vinnu, með því að hafa skilgreininguna skýra ætti villuvinna að vera auðveldari eftir að verkefnið fer í loftið.

Skilgreining á lokið er oftar en ekki byggð á kröfum og þörfum settum fram í þarfalýsingu. Þeim er þó oftar en ekki skipt upp í áfanga og er mikilvægt að hafa almennar kröfur í skilgreiningunni á borði við:

• Að kóði sé skrifaður og uppfærður í kóða geymslu.

• Að kóðinn hafi verið endurskoðaður af samstarfsmönnum.

• Að einingarpróf hafa verið gerð og ganga upp.

• Að samsetningar próf hafa verið gerð og ganga upp.

• Að kóði uppfyllir kóðunarstaðla og hefur verið kannaður fyrir hugsanlegum vandamálum (t.d. með staðlaðri kóða greiningu).

• Handbókin hefur verið uppfærð.

• Eiginleiki eða aðferð hefur verið sýnd hagsmunaaðilum og uppfyllir skilyrði.

• Nauðsynlegar skráningar eru til staðar.

• Eiginleiki eða breyting er útgefanleg og brýtur ekki eldri kóða.

Það er vert að hafa í huga að skilgreiningu á lokið ætti að endurskoða og uppfæra þegar þörf krefur.

Þarfir er varðar prófanir

Áður en hugbúnaður er gefinn út í raunumhverfi (til notkunar) þarf að framkvæma ítarlegar prófanir til að tryggja að hann sé öruggur, traustur, uppfyllir kröfur notenda. Ýmsar prófanir eiga að vera framkvæmdar á þróunar- og líftíma hugbúnaðarins.

Tegundir prófana eftir líftíma hugbúnaðarþróunar.

Einingaprófanir (Unit testing)

• Prófanir einstakra eininga eða þátta hugbúnaðarins til að ganga úr skugga um rétta virkni í einingunni sjálfri.

Samsetningar Prófun (Integration testing)

• Prófanir gerðar á sambandi/samtengingum mismunandi eininga eða þátta hugbúnaðarins.

Grunn prófanir (Sanity testing)

• Prófanir sem framkvæma grunnpróf til að tryggja að meginhluti hugbúnaðarins virki áður en farið er á dýptina.

Álagsprófun (Performance testing)

• Prófanir gerðar til að meta hvort hugbúnaðurinn standist mismunandi aðstæður, eins og álag til skamms og langstíma t.d. sem búið er að setja kröfur um í þarfalýsingu.

Öryggisprófun (Security testing)

• Prófanir til að finna veikleika, hættu og mögulegar ógnir gegn hugbúnaðinum og gögnum.

Notendaprófanir (Usability testing)

• Prófanir til að meta notendaviðmót hugbúnaðarins þar að segja hvort hönnun og notendaupplifun uppfylli þarfalýsingu og sé auðveldur í notkun.

Aðgengisprófanir (Accessibility testing)

• Prófanir til að ganga í skugga um að hugbúnaðurinn sé aðgengilegur fyrir alla notendur, þá sérstaklega þá sem eru fatlaðir. Sjá WCAC staðalinn.

Samhæfingarprófanir (Compatibility testing)

• Prófanir sem prófa hugbúnaðinn á mismunandi kerfum t.d. vafra, tækjum, stillingum til að tryggja virkni í mismunandi aðstæðum.

Stað- og tungumálaprófanir (Localization and internationalization)

• Prófanir þar sem hugbúnaðurinnn er prófaður á mismunandi tungumálum, landsstillingum ogsfr. Til að tryggja rétta virkni eftir stillingum/landsvæðum.

Kerfisprófun (System testing)

• Prófanir á kerfinu í heild sinni til að staðfesta að það uppfyllir öll skilyrði og virkni sem kemur fram í þarfalýsingu.

Könnunarprófun (Exploratory testin)

• Óskipulagðar prófanir þar sem hugbúnaðurinn er skoðaður án formlegrar áætlunar til að finna galla. Oft framkvæmd samtímis með formlegum prófunum.

Endurprófun (Regression testing)

• Prófanir endurteknar eftir að breytingar eða viðbætur hafa verið gerðar á kerfinu, til að tryggja að hún hafi ekki neikvæð áhrif á kerfið/núverandi virkni.

Beta prófanir (Beta testing)

• Prófanir þar sem útgáfa hugbúnaðarins er gefin út á takmarkaðan hóp notenda til þess að fá endurgjöf úr raunverulegum aðstæðum. Svo hægt sé að finna vandamál sem kunna að hafa sloppið í gegnum aðrar prófanir.

Það er mikilvægt að muna að prófanir eru framkvæmdar stöðugt í gegnum allan þróunartíman og margar hverjar skarast eða eru framkvæmdar í endurteknum hringjum.

Krafa þarf að vera að lokaprófanir fari fram í formi viðtökuprófana (Customer acceptance test).

Krafa um viðtökuprófanir (Customer acceptance test).

Gera þarf kröfu um að viðtökuprófanir fari fram.

Móta þarf samþykktar viðmið/kröfur (acceptance criteria) sem þarf að uppfylla svo hægt sé að segja með sanni að hugbúnaður uppfylli þær kröfur og þarfir sem settar hafa verið fram í útboði. Þar þarf meðal annars að setja fram kröfur um frammistöðu, öryggi og fleira sem eiga ekki sess í neinni sérstakri útgáfu.

Seljandi og kaupandi geta myndað samþykktar viðmiðin í sameiningu, sett fram lýsingu á framkvæmd ásamt því að setja fram tímaáætlun er varðar viðtökuprófanir. Taka þarf fram hvenær prófanir hefjast, hvernig prófanirnar eru framkvæmdar og hvenær þeim er lokið.

Dæmi um atriði sem þurfa að koma fram í lýsingu á framkvæmd viðtökuprófana.

Áður en byrjað er þarf að:

• Útvega skal búnað til að nota í prófinu

• Þjálfa prófunaraðila

• Útvega notkunarleiðbeiningar og önnur skjöl sem prófanir þurfa

• Útskýra hvernig á að skrá og tilkynna fundnar villur.

• Útvega prófunargögn

• Útvega lýsingu á prófinu

• Útvega plan sem segir til um í hvaða röð prófanir þurfa að vera framkvæmdar.

Við framkvæmd viðtökuprófana þarf að:

• Hafa umsjón með lokum prófunarlota

• Aðstoða prófunaraðila og veita stuðning þegar þörf krefur.

• Kanna hvort að hægt sé að endurframkalla villur áður en þær eru sendar áfram til forritunarteymis.

Við lok viðtökuprófana þarf að:

• Ganga í skugga um að allt sem átti að prófa hafi verið prófað.

• Að endurprófa í kjölfar úrlausnar villu.

• Keyra heildar prófanir (regression testing)

• Tryggja að lausn á útistandandi villum sé partur af samning.

Kröfur varðandi verkskil og verklok

Verk telst formlega lokið er kaupandi hefur formlega tekið á móti stjórn á hugbúnaðinum, eftir uppsetningu og prófunum. Seljandi þarf að hafa staðist afhendingarskilmála verksamnings og sannreyni að svo sé með prófunum.

Gera þarf kröfu um námskeið og kennslu á hugbúnaðinn

• Bjóðandi skal bjóða upp á námskeið ætluð starfsmönnum sem vinna með hugbúnaðinn. Þjálfun starfsmanna kaupanda þarf að fara faglega fram og í samræmi við tímaáætlun innleiðingar. Þjálfunin þarf að vera í samræmi við þarfir einstakra notendahópa s.s. endanotendur, ofur notendur, kerfisstjórar, rekstrarmenn og þess háttar.

• Þjálfunin þarf að fara fram í kerfinu, með sérsmíði/viðbótum ef um slíkt er að ræða.

• Áður en þjálfun hefst, þarf seljandi að útvega nauðsynleg námsgögn og skulu þau vera aðgengileg eftir að því líkur.

• Þjálfunargögn þurfa að vera uppfærð í samræmi við breytingar/uppfærslur á hugbúnaðinum.

• Ef greiða þarf fyrir slík námskeið þarf upphæð að vera tilgreint í þjónustusamningi.

Gera þarf kröfu er varðar skilgreindan reynslu og ábyrgðartíma

• Eftir að verki lýkur skv. formlegri afhendingu hefst sex mánaða reynslutími.

• Á þeim tíma skal verksali laga þegar í stað alla þá galla sem koma upp í kerfinu. Kaupanda ber að tilkynna þessa galla til verksala og mun verksali lagfæra þá á sinn kostnað. Þegar reynslutíma lýkur tekur við sex mánaða ábyrgðartími.

• Á ábyrgðartíma ber verksala að leiðrétta villur og galla er kaupandi tilkynnir til verktaka. Alvarleiki vandamála sem upp koma verða skilgreind og flokkuð eftir mikilvægi og viðbragðstími skilgreindur í samræmi við það. Gert er ráð fyrir að tilboðið nái til þess er fram kemur í kröfum er varða hugbúnaðinn og verksali skuldbindi sig til að uppfylla þær kröfur sem hluti af tilboði.

Eignarhald á kóða

Hægt er að fara tvær leiðir við eignarhald á grunnkóða hugbúnaðarins , viðbóta eða annara eininga.

Kröfur ef verkkaupi verður eigandi kóða

Verkkaupi verður eigandi að öllum hugbúnaði , þ.e. grunnkóða, hönnunarskjala, tæknilýsinga, gagnasafns og gagna sem og allra annarra lýsinga er undir kerfið falla. Seljanda ber að afhenda, gögnin hér að ofan jafnskjótt og þau verða til.

Kaupandi öðlast allan höfundar-. notkunar- og nýtingarrétt, fjölföldunar- og dreifingar rétt til samstarfsaðila og annarra ríkisstofnana á afurðum verkefnis þessa sem og þeirri vinnu og ráðgjöf sem keypt eru um leið og það verður til hjá seljanda.

Huga ber að eignarhaldi á kóða, þar sem ef kóði er eign kaupanda minnkar það líkur á læsingu hjá birgja (lock-in) til muna.

• Grunn kóði (source code ) er eign kaupanda nema um annað sé samið sérstaklega. Við samningslos á kaupandi að geta fengið „original decompiled source code“.

• Verkkaupi getur breytt og þróað kerfið að vild.

• Eignarhaldið nær einnig yfir sérhverja breytingu sem gerð er á hugbúnaðinum.

• Kóði séreiningar sem settar eru upp í opnum kerfum þurfa einnig að vera eign kaupanda.

• Kaupandi eignast allan ráðstöfunarrétt og nýtingarrétt á hugbúnaðinum.

Ef stofnun er eigandi að hugbúnaði er nauðsynlegt að kynna sér leiðbeiningar Fjársýslu Ríkisins hvað varðar óefnislegar eignir og þær reikningsskilaaðferðir (IPSAS) sem eru í gildi.

Kröfur varðandi afnot af sérlausna hugbúnaði/ kóða

Þegar opinber aðili fjárfestir í sérlausna hugbúnaði og hugbúnaðarþróun án þess að gera tilkall til eignarétts á grunnkóða hugbúnaðarins þarf að hafa sérstakar áherslur og áskoranir í huga. Það að birgi eigi grunnkóða hugbúnaðarins og geti selt afnotarétt á opnum markaði gæti leitt til hagkvæmari samnings fyrir hið opinbera en gæti leitt til fjárhagsútláts og áhættu sé horft til langtíma.

Þættir sem ber að hafa í huga við kaup á afnotarétti hugbúnaðar til að tryggja hagsmuni opinbera aðilans og til varnar birgja læsingu í einhverju mæli.

Áskilnaður

• Kaupandi verður eigandi alls hugbúnaðar og allra lýsinga (skjöl, tæknilýsing ofl.) sem unnin eru fyrir hann á verktíma.

• Kaupandi á rétt á að taka við kóðanum sjálfur og vinna áfram með þeim aðila sem hann kýs.

• Kaupandi hefur fulla heimild til að breyta kóða, hönnun og útfæra lausnina á þann máta sem hann kýs.

• Seljandi skal skila kaupanda skila afritum af kóða, lýsingum og tengdum gögnum reglulega á unnið er í verkinu.

Kröfur er varða ákvæði um útfösun á fyrri hugbúnaðarlausn

Ef um er að ræða vefsíðu, þá þarf að hafa í huga slóðavinnu (Redirect) útfrá nýju veftré, breytingu á skráaskipulagi og leitarvélavinnu er loka á eldri vef.

Skil skulu vera á greingargóðum skjölum og tæknilýsingu sem orðið hafa til við þróun hugbúnaðarins.

• Verkkaupi hefur afnotarétt af öllum forritum, skjölum og upplýsingum er lúta að kerfinu sjálfu, rekstri og viðhaldi og skal verksali afhenda verkkaupa rafrænt afrit af öllum slíkum gögnum ef óskað er. Verksali samþykkir að verkkaupi hafi heimild til að afhenda 3ja aðila téð gögn til áframhaldandi reksturs kerfisins við lok samningstíma, riftun eða uppsögn samnings að kostnaðarlausu.

• Við lok samnings þessa, hvernig sem þau bera að, skuldbindur verksali sig til, óski verkkaupi eftir því, að skila öllum gögnum í eigu verkkaupa á miðli sem verkkaupi tilgreinir. Verksala ber að afhenda verkkaupa tafarlaust og án kostnaðar öll skjöl, skilríki, gögn og upplýsingar, sem verksali hefur undir höndum fyrir verkkaupa, hvort heldur sem er skrifuð gögn eða í tölvutæku formi.

• Verkkaupi telst eigandi allra gagna í kerfinu. Öll gögn og upplýsingar sem skráðar eru í kerfinu eða vegna kerfisins, í hliðarkerfum og/eða gagnasafni, eru eign verkkaupa og er verksala óheimilt að nýta sér þau án skriflegs samþykkis verkkaupa.

Aðgangsstýringar þurfa að vera undir stjórn kaupanda.

Sólarlagsákvæði er skilmáli í samningum sem setur fram ákvæði um ákveðinn endapunkt eða þar sem samningurinn, eða hluti hans, rennur sjálfkrafa út nema samningsaðilar ákveði annað.

Þetta ákvæði er sérstaklega mikilvægt í tæknigeiranum þar sem þörf er á stöðugri endurskoðun og uppfærslu til að halda í við tækniþróun og nýjungar.

Við gerð sólarlagsákvæðis í hugbúnaðarkaupum er mikilvægt að kaupandi hafi í huga nokkur lykilatriði:

• Skýr Skilgreining: Ákvæðið þarf að vera skýrt orðað í samningnum, með ákveðnum aðstæðum sem leiða til endurskoðunar eða endurnýjunar.

• Vörður og Markmið: Setja skal fram skýr markmið eða vörður sem hugbúnaðurinn þarf að uppfylla til að samningurinn verði endurnýjaður, til dæmis varðandi uppfærslur, þróun og árangur.

• Jafnræði Samningsaðila: Tryggja þarf að samningsréttur sé jafn fyrir báða aðila. Það þýðir að báðir aðilar ættu að hafa möguleika á að krefjast endurskoðunar eða hætta við samninginn við lok sólarlagsákvæðis.

Sólarlagsákvæði getur veitt mörg tækifæri til að:

• Tryggja Uppfærslur og Þróun: Kaupendur geta tryggt að hugbúnaður verði reglulega uppfærður og þróaður til að mæta breyttum kröfum.

• Stuðla að Samkeppni: Hvetja til samkeppni meðal seljenda, sem getur leitt til betri kjara og þjónustu.

• Hagræðing: Endurskoðun á notkun og kostnaði við hugbúnað getur stuðlað að hagræðingu útgjalda.

• Áhættustjórnun: Endurmat á áhættu og öryggi hugbúnaðarins, sérstaklega í ljósi síbreytilegra öryggiskrafna.

Í gegnum sólarlagsákvæði leggur kaupandi áherslu á skilvirkni, nýjungar og kostnaðarhagkvæmni í hugbúnaðarlausnum, til að tryggja hagkvæmni og árangur yfir tiltekinn tíma. Þetta ferli innifelur reglulega endurskoðun, mögulega endurnýjun samnings eða útboð nýrrar lausnar, með það að markmiði að tryggja bestu mögulegu þjónustu og nýjungar í hugbúnaði fyrir kaupandann.