2 Prasbu definana Tmeku vietu veidoanas tehniskie principi

#2 Prasību definēšana Tīmekļu vietņu veidošanas tehniskie principi Kaspars Zemītis kaspars. zemiitis@gmail. com

Atkārtojums Kā darbojās tīmeklis? • Informācija tiek glabāta dokumentos, kurus sauc par tīmekļa lapām; • Tīmekļa lapas tiek glabātas uz datoriem, kuru sauc par tīmekļa serveriem; • Datorus, kuri lasa šīs tīmekļa lapas, sauc par tīmekļa klientiem; • Tīmekļa klienti 'apskata' tīmekļa lapas izmantojot pārlūkprogrammas; • Populārākās pārlūkprogrammas - Internet Explorer, Chrome, Firefox, Safari, Opera. . ;

Tīmekļa vietnes izstrādes posmi

Tīmekļa vietnes izstrāde Izstrādi var iedalīt soļos: 1. 2. 3. 4. 5. 6. Ideja. Prasību definēšana (kas ir jāizveido); Izlemt, kas un ar kādiem rīkiem veidos tīmekļa vietni; Kāda būs vietnes struktūra, saturs un kā to pasniegs; Domēna vārda izvēlve; Hostinga izvēle (FTP pieeju serverim); Izvēlēties dizainu – attēlus, fontus, grafiskos elementus; 7. Atcerēties par SEO (meklētāju optimizāciju):

Tīmekļa vietnes izstrāde 8. Tīmekļa vietnes testēšana: a) Izmantot testa vidi; b) Lietotāju apskati – atsauksmes; c) Lapas veiktspējas pārbaudīšana uz dažādām pārlūkprogrammām; rīku izmantošana; d) Kļūdu dokumentēšana/ pārbaudīšana; 9. Tīmekļa vietnes atklāšana; 10. Tīmekļa vietnes uzturēšana; 11. Brenda identitāte; 12. .

2. Izvēlēties – kas un ar kādiem rīkiem veidos tīmekļa vietni; 1. Definēt prasības • Ideja – Ko nepieciešams izveidot? (Blogu, internetveikalu, portālu, tīmekļa lapu, galerijas, portfolio. . ) – Kāds ir tā mērķis? (Informēt, palielināt pārdošanu, uzlabot kvalitāti. . . ) • Prasības Piemēram, vai ir nepieciešama • lietotāju reģistrēšanās, • media - attēlu un/vai video galerija, • komentāri, • reklāmu laukumi, • atskaites, iespēja lejuplādēt atskaites – kādos formātos/ kādos griezumos, • vairākas valodas; • administrēšana visai lapai, konkrētiem elementiem/ sadaļām; piekļuves līmeņi; • . .

2. Izvēlēties – kas un ar kādiem rīkiem veidos tīmekļa vietni; 1. Definēt prasības • Termiņi – visam projektam kopā/ atsevišķiem moduļiem • Budžets Jāņēm vērā, ka idejas un prasības atšķirās katram projektam atkarībā no pasūtītāja (kāda nozare, tirgus situācija, uzņēmuma vadība utt. ), bet visus projektus ir nepieciešams realizēt (ir termiņi) noteiktās samaksās (ir budžets). Ieteikumi: • Pārdomāt rūpīgi kāds ir projekta mērķis, jo no mērķis nosaka prasības; • Prasības ir iespējams definēt apskatoties līdzīgus projektus, tomēr prasībās nevajadzētu definēt detalizēti elementus (un to izskatu), bet koncentrēties, kādu rezultātu vēlās sasniegt.

2. Izvēlēties – kas un ar kādiem rīkiem veidos tīmekļa vietni; 1. Definēt prasības • . . . prasībās nevajadzētu definēt konkrētus elementus (un to izskatu), bet koncentrēties, kādu rezultātu vēlās sasniegt. • Piemēram, prasība ‘Tīmekļa vietnes apmeklētājiem jābūt iespējai sazināties ar mums (ar tīmekļa vietnes palīdzību). ’ – Piedāvājot jau konkrētu risinājumu, var tikt izslēgtas citas iespējas. (Citas nemaz neapskatīsies. ) – Definējot tikai prasību pēc tam tiek izstrādāti iespējamie varianti un no tiem izvēlēts nepieciešamais

• Tīmekļa vietnē ir ievietota epasta adrese (kuru var nokopēt vai uz tās uzspiest) • Tīmekļa vietnē ir norāde par sazināšanos (e -pasta nosūtīšanu)

Nospiežot uz e-pasta saites atverās e-pasta programma, ar kuras palīdzību var nosūtīt e-pastu

Nospiežot uz e-pasta attēla atverās web forma, kurā var ierakstīt ziņojumu

2. Izvēlēties – kas un ar kādiem rīkiem veidos tīmekļa vietni; 1. Definēt prasības Kāpēc nepieciešama dokumentācija? • Vadmotīvs izstrādes procesā – Pastūtītājs redz, ko pats vēlas; – Izstrādātājs redz, ko pasūtītājs vēlas; • • Atskaite uzņēmumam – Gan pasūtītājs, gan izstrādātājs var ieplānot darbus/ atskaitīties par plānu pamatojoties uz definētu projektu; Aizsardzība no negaidīta rezultāta saņemšanas (ja nav nodefinētas prasības), rezultāta nesaņemšanas (nav nodefinēti termiņi), rezultāta saņemšana par citu cenu (nav nodefinēts budžets); Kas notiek, ja projekta gaitā ir nepieciešams pievienot prasības, bet projektam vispār nav nodefinētas prasības? - Izstrādātājs var pagarināt termiņu, palielināt izmaksas vai pat atteikt projektu. Kas notiek, ja izstrādātājs projekta gaitā secina, ka nav iespējams realizēt kādu prasību un palielina projekta izmaksas? - Kā pasūtītājs pierādīs, kāds ir bijis sākotnēnais budžets, ja tas nav iepriekš definēts. . .

2. Izvēlēties – kas un ar kādiem rīkiem veidos tīmekļa vietni; 1. Definēt prasības Kāpēc nepieciešama dokumentācija? Piemērs. - Uzdevums. Nepieciešams izveidot uzņēmuma darbinieku darba stundu uzskaites sistēmu. - - - Ievades dati – katram darbiniekam ir apliecība ar unikālu ID, kuru viņš reģistrē (‘nopīkstina’) atnākot/ aizejot pie sensora. Sistēma aprēķina nostrādātās stundas. Darbinieks drīkst atnākt tikai laikā kad viņam ir darba laiks/darba diena – sistēma skaitas stundas tikai tad, ja ir atļauts strādāt. (Tātad iepriekš administrators plāno un izveidot darba laikus). Iespējams apskatīties atskaites – cik stundas katrs darbinieks ir nostrādājis.

2. Izvēlēties – kas un ar kādiem rīkiem veidos tīmekļa vietni; 1. Definēt prasības - Darbinieks drīkst atnākt tikai laikā kad viņam ir darba laiks/darba diena – sistēma skaitas stundas tikai tad, ja ir atļauts strādāt. (Tātad iepriekš administrators plāno un izveidot darba laikus). Kas notiek, ja netiek definētas prasības kā konkrēti ir jāadministrē darba laiki?

2. Izvēlēties – kas un ar kādiem rīkiem veidos tīmekļa vietni; 1. Definēt prasības Sistēmas izstrādātājs (programmētājs) ‘izdomā’ un izveido savu versiju. Piemēram, • Darbiniekiem katrā datumā vai nu ir, vai arī nav darba diena.

2. Izvēlēties – kas un ar kādiem rīkiem veidos tīmekļa vietni; 1. Definēt prasības Pasūtītājs bija domājis: • Palicis nepateikts: • Darbinieki ir jāgrupē (maiņās). • Jābūt arī laikiem (nepietiek tikai ar dienām).

2. Izvēlēties – kas un ar kādiem rīkiem veidos tīmekļa vietni; 1. Definēt prasības Dokumentācija - Prasību specifikācija – Kas to raksta? – Ko tajā iekļaut? – Piemēri Ieteikumi: – Jau projekta sākuma stadījā noteikti ir nepieciešams apsvērt iespējamos riskus, kas varētu radīt izmaiņas prasībās. Līdz ar to uzreiz nodefinēt cik % drīkst pārsniegt termiņi un budžets. % daļu ierasti sauc par ‘buferi’.

2. Izvēlēties – kas un ar kādiem rīkiem veidos tīmekļa vietni; 1. Definēt prasības Dokumentācija – (Programmatūras) Prasību specifikācija – Kas to raksta? • Pasūtītājs un izstrādātājs kopīgi, vienojas, kas pabeigtai programmatūrai ir jādara; • Pasūtītājs parasti nepārzina pietiekami labi programmatūras izstrādes procesu, lai varētu uzrakstīt precīzu un lietojamu PPS • Izpildītājs parasti nepārzina izstrādājamās programmatūras prasības • Abām pusēm jāstrādā kopīgi, lai izstrādātais PPS būtu pilnīgs un saprotams

2. Izvēlēties – kas un ar kādiem rīkiem veidos tīmekļa vietni; 1. Definēt prasības Dokumentācija - Prasību specifikācija • Attiecībā uz PPS ir būtiski iegaumēt, ka tai jāspecificē programmatūras produkta darbināšanas rezultāti, nevis līdzekļi, ar kuriem rezultāti sasniedzami. • 1) Prasību autoram jāpievērš uzmanība Šādām pamat lietām, kā: – a) funkcionalitāte - ko programmatūra paredz darīt, – b) veiktspēja - ātrums, gatavība, atbildes laiks, dažādu programmatūras funkciju atveseļošanas laiks u. c. , – c) implementācijai uzliktie projekta ierobežojumi - jebkurš faktiski prasītais standarts, implementācijas valoda, datu bāzes integritātes nodrošināšana, resursu limits, darbības vide, utt. ; – d) atribūti - pārnesamības, korektīvas, uzturamības, drošības, utt. apsvērumi; – e) ārējās saskarnes - sadarbība ar cilvēkiem, aparatūru, citu programmatūru un citu aparatūru.

2. Izvēlēties – kas un ar kādiem rīkiem veidos tīmekļa vietni; 1. Definēt prasības Dokumentācija - Prasību specifikācija • Tā kā PPS jāspēlē dokumentācijas shēmā noteikta loma, PPS autoram jābūt uzmanīgam, lai nepārkāptu Šīs lomas robežas. Tas nozīmē, ka jāapmierina Šādas prasības: – 1) PPS korekti jādefinē visas programmatūras prasības, bet ne vairāk; – 2) PPS nav jāapraksta projektējuma, verifikācijas vai projekta pārvaldības detaļas, izņemot prasītos projektēšanas ierobežojumus. • Tāda, pareizi rakstīta, PPS ierobežo derīgo risinājumu diapazonu, bet nespecificē konkrēto projektējumu (design) un tādā veidā nodrošina izpildītājam maksimālu radošo brīvību.

2. Izvēlēties – kas un ar kādiem rīkiem veidos tīmekļa vietni; 1. Definēt prasības Kas netiek iekļauts prasību specifikācijā? – Izmaksas; – Piegādes kalendārais plāns; – Pārskatu veidošanas procedūras; – Programmatūras izstrādes metodes; – Kvalitātes nodrošināšana; – Verifikācijas un validācijas kritēriji; – Pieņemšanas procedūras.

2. Izvēlēties – kas un ar kādiem rīkiem veidos tīmekļa vietni; 1. Definēt prasības Dokumentācija - Prasību specifikācija 1) viennozīmīga, 2) pabeigta, 3) verificējama, 4) nepretrunīga, 5) modificējama, 6) trasējama, 7) lietojama darbināšanas un uzturēšanas fāzes laikā.

2. Izvēlēties – kas un ar kādiem rīkiem veidos tīmekļa vietni; 1. Definēt prasības Dokumentācija - Prasību specifikācija 1) viennozīmīga – Katrai prasībai ir tikai viena nepārprotama interpretācija, kā arī katrai raksturiezīmei ir jābūt unikālam apzīmējumam. ‘Kontrolsumma jāņem no pēdējā ieraksta’, var lasīt Šādi: • a) kontrolsumma jāņem no ieraksta datnes beigās, • b) kontrolsumma jāņem no paša pēdējā nolasītā ieraksta, • c) kontrolsumma jāņem no iepriekšējā ieraksta;

2. Izvēlēties – kas un ar kādiem rīkiem veidos tīmekļa vietni; 1. Definēt prasības Dokumentācija - Prasību specifikācija 2) pabeigta • Iekļautas visas svarīgākās prasības, kas saistās ar funkcionālām iespējām, veiktspēju, projektēšanas ierobežojumiem; • Noteiktas reakcijas uz pareizām un nepareizām vērtībām; • Nav ieteicams lietot ‘tiks precizēt vēlāk’. Ja tādu lieto, tad min kāpēc nav iespējams precizēt tagad un kā un kad tas tiks novērsts (kad precizēs)

2. Izvēlēties – kas un ar kādiem rīkiem veidos tīmekļa vietni; 1. Definēt prasības Dokumentācija - Prasību specifikācija 3) verificējama – Katra prasība ir pārbaudāma kādā procesā (to var izdarīt cilvēks vai dators); – Ja nevar izgudrot metodi kā pārbaudīt procesu, tad prasība ir jāatsauc vai jāpārveido; • Slikts piemērs (nav verificējama prasība): – ‘Produktam jāstrādā labi vai produktam jānodrošina laba saskarne ar cilvēku’. Šo prasību nevar pārbaudīt tāpēc, ka nav iespējams definēt terminu labs. • Labs piemērs (ir verificējama prasība): – ‘Programma 70% gadījumu atgriež rezultātu vismaz 20 sekunžu laikā pēc notikuma X un 100% gadījumu rezultātu 40 sekunžu laikā pēc notikuma Y’.

2. Izvēlēties – kas un ar kādiem rīkiem veidos tīmekļa vietni; 1. Definēt prasības Dokumentācija - Prasību specifikācija 4) nepretrunīga – Neviena prasība vai prasību grupa nav pretrunā ar kādu citu prasību. – Iespējamie konflikti (pretrunas): • Terminos (katrā prasībā viens un tas pats nosaukts dažādi); • Loģisks vai laika konflikts. Piemēram, vienā prasībā ir teikts, ka notikums A vienmēr seko pēc notikuma B, bet citā, ka abi notiek vienlaicīgi

2. Izvēlēties – kas un ar kādiem rīkiem veidos tīmekļa vietni; 1. Definēt prasības Dokumentācija - Prasību specifikācija 5) modificējama – Nepieciešamās izmaiņas - prasībās, stilā, struktūrā- var izdarīt pilnīgi un nepretrunīgi. – Lietot satura rādītāju, atsauces. – Sliktais piemērs: Funkcija A ir atkarīga no funkcijas B. Funkcija B PPS modificēšanas rezultātā tiek mainīta. PPS nav iekļautas savstarpējās atkarības. Nav arī satura rādītāja, kas apgrūtina funkciju A un B atrašanu tekstā

2. Izvēlēties – kas un ar kādiem rīkiem veidos tīmekļa vietni; 1. Definēt prasības Dokumentācija - Prasību specifikācija 6) trasējama – Ir skaidra katras prasības izcelsme un tā atvieglo sekošanu katrai prasībai turpmākās izstrādēs vai uzlabošanas dokumentācijā.

2. Izvēlēties – kas un ar kādiem rīkiem veidos tīmekļa vietni; 1. Definēt prasības Dokumentācija - Prasību specifikācija 7) lietojama darbināšanas un uzturēšanas fāzes laikā – Jābūt iespējam veikt izmaiņas specifikācijā , kad jau produkts ir lietošanā

2. Izvēlēties – kas un ar kādiem rīkiem veidos tīmekļa vietni; 1. Definēt prasības Dokumentācija - Prasību specifikācija Cik sīki ir jāveido prasību specifikācija? • 1) cik liela un sarežģīta ir programma? • 2) vai to prasa pasūtītāja kontrakts? • 3) vai PPS ir kontrakta izpildes līdzeklis, vai vienkārši iekšējais dokuments (izstrādātājam)?

2. Izvēlēties – kas un ar kādiem rīkiem veidos tīmekļa vietni; 1. Definēt prasības Dokumentācija - Prasību specifikācija Komentāri - piemēram, lai noteiktu, kuras prasības ir svarīgas un kuras nē. Ieteikums – saprast, kādas ir attiecības uz komentāriem (kas notiek, ja tos neievēro utt. )

2. Izvēlēties – kas un ar kādiem rīkiem veidos tīmekļa vietni; 1. Definēt prasības Prasību specifikācijas saturs Satura rādītājs; 1. Ievads 1. 1. Nolūks – Apraksta dokumenta nolūku, cilvēku grupu, kuriem domāts dokuments 1. 2. Darbības sfēra - Identificē programmatūras projektu, paskaidro kas programmatūras projektam jādara (un varbūt arī kas NAV jādara) 1. 3. Definīcijas - Nepieciešams dot skaidrojumus visām definīcijām, akronīmiem un saīsinājumiem, lai lasītājs varētu pareizi interpretēt PPS 1. 4. Saistība ar citiem dokumentiem - Nepieciešams dot atsauces uz dokumentiem, kuri ir lietojami kopā ar PPS, kuri ir izmantoti PPS sastādīšanā un var būt nepieciešami detalizētākas informācijas iegūšanai 1. 5. Dokumenta pārskats – Apraksta, kā dokuments ir organizēts

2. Izvēlēties – kas un ar kādiem rīkiem veidos tīmekļa vietni; 1. Definēt prasības Prasību specifikācijas saturs Satura rādītājs; 2. Vispārējs apraksts 2. 1. Produkta perspektīva – Jāapraksta programmatūras konteksts. 2. 2. Produkta funkcijas - Jāsniedz kopsavilkumu par funkcijām, kuras izpilda programmatūra. Funkciju sarakstu nepieciešams organizēt tādā veidā, lai tas būtu saprotams pasūtītājam, vai arī cilvēkam, kurš to lasa pirmo reizi. 2. 3. Lietotāja raksturiezīmes - Jāapraksta vispārējās iespējama produkta lietotāja raksturiezīmes, kuras iespaido specifiskās prasības. 2. 4. Vispārēji ierobežojumi - Jānodrošina visu to vienumu apraksti, kas var ierobežo izstrādātāja izvēles tiesības. Tās var būt: 1) regulējošā politika; 2) aparatūras ierobežojumi; 3) saskarnes ar citiem lietojumiem; 4) paralēlās operācijas; 5) auditēšanas funkcijas; 6) vadības funkcijas; 7) augstākā līmeņa valodas prasības; 8) signālu sakaru apstiprināšanas protokols; 9) lietojuma kritiskums; 10) drošības un aizsardzības apsvērumi

2. Izvēlēties – kas un ar kādiem rīkiem veidos tīmekļa vietni; 1. Definēt prasības Prasību specifikācijas saturs 3. Funkcionālās prasības 3. 1. Prasība Nr 1 3. 1. 1. Ievads – Jāapraksta funkcijas mērķi 3. 1. 2. Ievade – Jāapraksta ievaddatu avotus, mērvienības, kvantitātes, diapazonus. Specifiskās operatoru darbības, ja ir. Atsauces uz saskarnes specifikācijām. 3. 1. 3. Apstrāde – Jāapraksta darbības ar ievaddatiem, lai iegūtu izvaddatus: ievaddatu pareizības pārbaude, stingra operāciju secība, reakcija uz nenormālām situācijām (kļūdas), visas metodes ievaddatu apstrādē, izvaddatu pareizības pārbaude. 3. 1. 4. Izvade – Jāapraksta izvaddati: mērķi, kvantitātes, mērvienības, laika aspekti, izvaddatu diapazons (ieskaitot precizitāti), kļūdu ziņojumus 3. 2. Prasība Nr 2 3. 2. 1. . 3. 2. 2. .

2. Izvēlēties – kas un ar kādiem rīkiem veidos tīmekļa vietni; 1. Definēt prasības Prasību specifikācijas saturs 4. Ārējā saskarne 4. 1. Lietotāja saskarne – jāapraksta ekrāna formāti, lappuses izkārtojumi, programmējamo (funkcionālo) taustiņu uzskaitījums. 4. 2. Aparatūras saskarne – apraksta sistēmas un aparatūras saskarni. 4. 3. Programmatūras saskarne – apraksta saskarni ar citām programmatūrām. 4. 4. Sakaru saskarne – apraksta sakaru saskarnes veidus, piemēram, tīkla protokolus.

2. Izvēlēties – kas un ar kādiem rīkiem veidos tīmekļa vietni; 1. Definēt prasības Prasību specifikācijas saturs 5. Nefunkcionālās prasības 5. 1. Veiktspējas prasības 5. 2. Datu drošība 5. 3. Pieejamība 5. 4. Aizsardzība pret nesankcionētu piekļuvi 5. 5. Kvalitātes atribūti 6. Citas prasības, piemēram, prasības datu bāzei, likumdošanas prasības, u. c.

2. Izvēlēties – kas un ar kādiem rīkiem veidos tīmekļa vietni; 1. Definēt prasības Dokumentācija - Prasību specifikācija Prasību izteikšanas metodes • Ievadizvades specifikācija; • Dažādi modeļi (matemātiskie, funkcionālie, laika); • Lietojot reprezentatīvus piemērus.

2. Izvēlēties – kas un ar kādiem rīkiem veidos tīmekļa vietni; 1. Definēt prasības Dokumentācija - Prasību specifikācija Sistēmas komponentes? -Saraksts datu atlasei; -Ievadformas; -Atskaites;

2. Izvēlēties – kas un ar kādiem rīkiem veidos tīmekļa vietni; 1. Definēt prasības Dokumentācija - Prasību specifikācija Sistēmas komponentes? -Saraksts datu atlasei (meklēšanai)

2. Izvēlēties – kas un ar kādiem rīkiem veidos tīmekļa vietni; 1. Definēt prasības Dokumentācija - Prasību specifikācija Saraksts datu atlasei (meklēšanai) • Ievaddati – Meklēšanas kritēriji – Aizpildes nosacījumi, kombinācijas • Apstrāde – Atlases ierobežojumi, tai skaitā tiesību kontrole – Iespējams, tālākās darbības ar sarakstu, piemēram, eksports, pāreja uz rediģēšanu u. tml. • Izvaddati – Kolonnas, to secība – Saraksta sakārtojums! Sakārtojums pēc vairākām kolonnām

2. Izvēlēties – kas un ar kādiem rīkiem veidos tīmekļa vietni; 1. Definēt prasības Dokumentācija - Prasību specifikācija Sistēmas komponentes? -Ievadformas

2. Izvēlēties – kas un ar kādiem rīkiem veidos tīmekļa vietni; 1. Definēt prasības Dokumentācija - Prasību specifikācija -Ievadformas; • Ievaddati – Ievadformā ievadāmie dati – Datu obligātums, veids, ierobežojumi • Apstrāde – Ievaddatu pārbaudes – (Ievērjotiet –nevajag dublēt standarta pārbaudes) • Izvaddati – Darbība pēc ievaddatu saglabāšanas, piemēram, pāreja atpakaļ uz atjaunotu sarakstu – Vai arī paziņojums (ne vienmēr kā forma) par veiktu darbību un pāreja rediģēšanas režīmā

2. Izvēlēties – kas un ar kādiem rīkiem veidos tīmekļa vietni; 1. Definēt prasības Dokumentācija - Prasību specifikācija Sistēmas komponentes? -Atskaites

2. Izvēlēties – kas un ar kādiem rīkiem veidos tīmekļa vietni; 1. Definēt prasības Dokumentācija - Prasību specifikācija -Atskaites; • Ievaddati – Atskaites sagatavošanas kritēriji – Aizpildes nosacījumi, kombinācijas • Apstrāde – Atlases ierobežojumi • Izvaddati – Atskaites piemērs ar nelieliem datiem

2. Izvēlēties – kas un ar kādiem rīkiem veidos tīmekļa vietni; 1. Definēt prasības Dokumentācija - Prasību specifikācija Funkcionālās prasības • Ievaddati: avoti, kvantitātes, mērvienības, laika vienības, pieļaujamie ievaddatu diapazoni • Apstrāde: pareizības pārbaude, operāciju secība, reakcija uz nenormālām situācijām, izmantotie parametri, lietotās aprēķina metodes, sagatavoto izvaddatu pareizības pārbaude

2. Izvēlēties – kas un ar kādiem rīkiem veidos tīmekļa vietni; 1. Definēt prasības Dokumentācija - Prasību specifikācija Nefunkcionālās prasības • Veiktspējas: lietotāju skaits (vienlaicīgo), ierakstu skaitu, datu apjomu, transakciju apjomu normālos un ekstremālos apstākļos • Projekta ierobežojumus: atbilstības noteiktiem standartiem, aparatūras ierobežojumi • Atribūtus: drošība, pieejamība, mērogojamība • Ārējās saskarnes prasības: lietotāja saskarnes principi, aparatūras un programmatūras saskarne, sakaru saskarne