Sistēmanalīze un ātrdarbība

Mana pamata nodarbošanās un oficiālais amats (vismaz šobrīd) ir sistēmanalīze un sistēmanalītiķis. Parasti starp sistēmanalītiķiem un programmētājiem (tāpat kā starp programmētājiem un testētājiem, piemēram, kā arī daudzām citām profesijām) mēdz būt tāda kā rīvēšanās, kā savstarpēja pienākumu nogrūšana, kas nelielos apmēros noteikti ir veselīga, jo rada nelielu stresiņu, neļauj iesūnot un vispār veicina attīstību🙂

Lielos apmēros tas neapšaubāmi izvēršas par destruktīvu kašķi, kas vispārīgajam mērķim (radīt ātrāk, lētāk, labāku programmatūru) par labu nenāk. Reizēm mēdz būt tā, ka atklāta kašķa it kā nav, bet vienkārši viena no pusēm ir nospiesta uz ceļiem un burtiski nevar ne iepīkstēties, t.i. visas kļūdas noklusēti vienmēr ir vai nu programmētājiem, vai tieši otrādi analītiķiem.

Lūk tagad arī iemesls šādam vispārīgam filozofiskam ievadam – kur ir ātrdarbības problēmu cēloņi? Es gribētu teikt, ka lielā daļa gadījumu tā nav programmētāju “vaina”, bet bremzēm kājas aug jau sistēmanalīzē. Vai, pareizāk izsakoties, sistēmanalīzes neeksistēšanā, vai nekorektā un nekvalitatīvā tās izpildē. Par šo tēmu tad arī bija mana prezentācija pēdējā LVOUG konferencē. Prezentācija par tipiskām sistēmanalīzes kļūdām, kas noved pie ātrdarbības problēmām programmēšanas laikā, ir šeit.

Vēl par sistēmanalīzi gribu atzīmēt, ka nu jau kādu laiciņu Vita Karnīte ir izveidojusi emuāru par sistēmanalīzi. Pirmie interesantie ieraksti jau tur ir atrodami, atliek tikai novēlēt brīvu laiku un vēlmi rakstīt tālāk!

Papildinājums – aizmirsu pateikt, ka visas LVOUG trešās konferences prezentācijas ir atrodamas šeit.

4 Responses to Sistēmanalīze un ātrdarbība

  1. Jānis says:

    Tā interesanti, kā sistēmanalītiķis var izdomāt tehniski vislabāko risinājumu.
    Skaidrs, ka laiks, kurā vadītājs ir vislabākais no izpildītājiem, ir tā kā pagājis. No tā varētu pieņemt, ka visdrīzāk sistēmanalītiķis nezin (un nemaz nevajag) visas nianses un alternatīvas tajās miljons tehnoloģijās.
    Tāda abstrakta domāšana un lieliska rezultāta sasniegšana ir tas, ko apbrīnoju.

  2. Gints Plivna says:

    Ir starpība starp šīm 2 lietām:
    – tehniski vislabākais risinājums
    – tehniski neiespējams risinājums ievērojot prasītās nefunkcionālās prasības.
    Sistēmanalītiķim nav jāizdomā tehniski vislabākais risinājums, bet viņam ir jāsaprot kādas prasības nerakstīt, lai tehniski to veidojot nebūtu milzu problēmas. Protams, ka jebkuru no prezentācijā minētajām prasībām funkconāli realizēt var. Bet lielākā daļa no tām būs šāviens sev kājā. Tehniski var izveidot māju uz vistas kājas, bet praksē to dara reti kurš, jo tas ir dārgi un tāda māja potenciāli ir krietni nestabilāka nekā normāla māja. Tāpēc saprātīgi cilvēki, kuriem nauda riekšavām nenāk, tādas mājas nebūvē. Diemžēl IT diezgan bieži ir gadījumi, kad tiek prasības nevis analizētas, bet pierakstītas nedomājot par sekām, kā rezultātā nelaimīgs ir gan klients, jo viņa iecerētā “fīča” it kā strādā, bet viss nežēlīgi bremzē, gan izstrādātāja iestāde, kurai pēc tam masē galvu un pa visu pasauli izblamē, ka tie nejēdz taisīt softu.

  3. Jānis says:

    Kurš avots tiek pieskaitīts kā otrais?🙂 (no prezentācijas)

Komentēt

Fill in your details below or click an icon to log in:

WordPress.com Logo

You are commenting using your WordPress.com account. Log Out / Mainīt )

Twitter picture

You are commenting using your Twitter account. Log Out / Mainīt )

Facebook photo

You are commenting using your Facebook account. Log Out / Mainīt )

Google+ photo

You are commenting using your Google+ account. Log Out / Mainīt )

Connecting to %s

%d bloggers like this: