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.