Nimikkeistä käsitteisiin ja kirahvin kautta takasin

Tällä foorumilla on varsin usein pohdiskeltu sitä, mikä on nimike ja mitä tarkoittaa nimikkeellistäminen. Samojen ajatuskulkujen syövereihin ajauduin eräänä päivänä PDM-saarnamiehemme  ja toisaalta omien lasten ajatuskulkuja seuratessa. Omalla tavallaan molemmat aiheuttivat innostusta, joskin toisessa tapauksessa oli myös twisti harmaiden hiusten ja vatsahaavan pariin. Lukija voi itse päätellä kummassa tapauksessa näin kävi.

Aiemmin on todettu, että nimike on asia, jolle voidaan antaa yksilöivä tunnus, nimi, kuvaus ja erilaisia attribuutteja kuvaamaan nimikkeen ominaisuuksia.

Nimikkeellistettäessä sovitaan ja määritellään tavat ja käytännöt koodituksille, nimien ja kuvausten muodostamiselle ja määritellään eri nimikkeiden tarvitsemat attribuutit.

Kapasitanssi on tarpeeton tieto mutterille, mutta kondensaattorille varsin keskeinen. Toisaalta myös perspektiivi nimikkeeseen vaikuttaa nimikkeen mallinnukseen. Oston ja myynnin tiedot saattavat hyvinkin erota siitä tietotarpeesta, mikä suunnittelulle ja valmistukselle on olennaista tietoa. Nimikkeellistettäessä yrityksen tuotteet (myymät, ostamat, valmistamat, suunnittelemat) mallinnetaan liiketoimintaprosesseja varten.

Onko nimikkeellistämisellä ja käsitteellistämisellä ja käsitemalleilla sitten jotain eroa toisiinsa nähden? Sovelluskehityksen piirissä tehdään käsitemalleja ja kuvauksia käsitteistä, joita ratkaistavassa ongelmakentässä esiintyy. Selvitetään käsitteiden suhteita toisiinsa, käsitteisiin liittyviä ominaisuuksia ja attribuutteja. Tätä analogiaa seuraten voidaan väittää, että minkä tahansa asian voi nimikkeellistää. Kun määrittelytyötä tehdään, on tietysti olennaista ymmärtää mikä on se entiteetti, jota ollaan kuvaamassa.

Nuoremman tyttären kanssa usein automatkoilla tms. pelataan eläinarvoituksia. Siinä toinen antaa vinkkejä ja toinen koittaa arvata mikä eläin on kyseessä. Mikä on sellainen, jolla on pitkä kaula, pilkkuja ja neljä jalkaa? No kirahvihan se.

Kirahvikysymys

Mallintamisessa tehdään samaan tyyliin. Tunnistamme entiteetin ominaisuuksia ja attribuuttien tyypillisiä arvoja ja sen perusteella voidaan päätellä mistä oikein on kysymys. Tämä toimii varsinkin silloin, kun mallinnetaan asioita, joille on tosiolevainen vastine reaalimaailmasta. Joskus ongelmakenttää mallinnettaessa ratkaisun aikaan saamiseksi täytyykin käsitemalliin lisätä entiteetti, jolla ei olekaan konkreettista vastinetta reaalimaailmassa tai reaalimaailman vastine on hyvin abstrakti. Esimerkkinä näistä ovat tyypillisesti sovelluksissa käytetyt, koosteita esittävät käsitteet, kuten tuoteryhmä, hintaryhmä tai projektiryhmä. Ilman tietoa kontekstista ei voi päätellä, tarkoittaako projektiryhmä jollain kriteerillä ryhmiteltyä projektien joukkoa, vai projektiin osallistuvien henkilöiden muodostamaa ryhmää. Se millaisia attribuutteja tässä projektiryhmälle tarvitaan riippuukin siitä, kumpi käsitys projektiryhmästä on kyseessä.

Laajoja kokonaisuuksia mallinettaessa syntyy paljon näitä abstrakteja käsitteitä, jotka ovat alttiita virheellisille tai ainakin erilaisille tulkinnoille. Tätä ongelmaa ratkaistaan usein terminologisella sanastotyöllä, luodaan sanakirja ko. ongelma-alueen käsitteistä ja termeistä ja näin saadaan yhteinen ymmärrys nämä projetiryhmän kaltaiset abstraktiot tässä tilanteessa tarkoittavat. Suora analogia nimikkeiden maailmassa löytyy yrityksen sanakirjasta, corporate dictionary. Tämä sanakirja identifioi ja selittää yrityksen nimikkeistössä käytetyt termit ja mahdollisesti tarjoaa yrityksen käyttämät käännökset eri kielille. Toisaalta ostajan ja myyjän välillä olisi syytä olla yhteinen käsitys termistöstä tai tilaajan ja alihankkijan välillä. Yhtenäiset käännökset helpottavat tai jopa mahdollistavat nmikkeistön harmonisoinnin eri kielialueiden välillä.

PDM Preacher Jukka S mainitsi eräässä blogi-kirjoituksessaan vaatimusten nimikkeellistämisestä. Vaatimushan on myös abstraktio, joka täytyy mallintaa kontekstin mukaan. Kun vaatimus mallinnetaan tai nimikkeellistetään, luodaan vaatimustenhallinnan perusteita.  Vaatimus voi esiintyä käsitteenä kun asiaa tarkastellaan tuotekehityksen, muutoshallinan tai laadun varmistuksen silmin. Toisaalta vaatimusten hallinta voi olla myös näkökulmansa edellämainituihin. Kaikki kuitenkin liittyvät toisiinsa ja ehkä tässäkin kannattaa nousta helikopterin kyytiin ja katsoa tarkemmin missä kaikissa prosesseissa vaatimus oikeastaan esiintyy ja missä prosesseissa tieto vaatimuksista olisi hyödyllinen.

Nämä kaikki innoittavat ajatukset saivat kuitenkin täysin aivan uuden ulottuvuuden kun samana päivänä tulin töistä kotiin ja kohtasin aivan uudenlaiset vaatimusten maailman varhaisteini-ikäisen tyttäreni taholta. Vastassa oli vaatimusten big dataa, joiden luokittelutekijät olivat täysin portaattomia n-uloitteisessa avaruudessa. Huusin avukseni sumean logiikan ratkaisuja ja kvanttikoneita. Onneksi lopulta ratkaisu oli kuitenkin varsin yksinkertainen, Spagetti Bolognese. Maslovin tarvehierarkiaa kannattaakin vaatimustenhallissa kunnioittaa.

– Software Samurai –

Advertisements

Vastaa

Täytä tietosi alle tai klikkaa kuvaketta kirjautuaksesi sisään:

WordPress.com-logo

Olet kommentoimassa WordPress.com -tilin nimissä. Log Out / Muuta )

Twitter-kuva

Olet kommentoimassa Twitter -tilin nimissä. Log Out / Muuta )

Facebook-kuva

Olet kommentoimassa Facebook -tilin nimissä. Log Out / Muuta )

Google+ photo

Olet kommentoimassa Google+ -tilin nimissä. Log Out / Muuta )

Muodostetaan yhteyttä palveluun %s