Ohjelmistotuotteen hallinta 1982

LAATU- JA STANDARDISOINTIPÄIVÄT 1982

Lauri Gröhn /Telenokia Oy

1. JOHDANTO 1.1 Ohjelmistoammattilaisen profiili

Nykyisin kaikkialla maailmassa pätevien suunnittelijoiden ja ohjelmoijien kysyntä ylittää huomattavasti tarjonnan. Toisaalta alalla ei vallitse yksimielisyyttä siitä, millaisia ovat laadukkaat ohjelmat ja miten niitä pitäisi tehdä. Toisin sanoen on puute kokeneista suunnittelijoista ja ohjelmoijista, koska pätevyydelle on vaikea antaa mittaa laadun mittaamiskeinojen puuttuessa.

Ohjelmistoammattilaiset eroavat erään selvityksen mukaan muista vastaavan tason ammattilaisista (kuva l). Vertailu on tehty 70 luvun lopussa Yhdysvalloissa. Vertailusta voisi tehdä ainakin sen johtopäätöksen, että alalla työskentelevät ovat tavallista itsekeskeisempiä ja tavallista enemmän omilla ehdoillaan toimivia. Molemmat seikat sekä vaikeuttavat että helpottavat laatutyötä.

Kuva 1. Ohjelmistoammattilaisen motivaatiotekijät /Fit 78/ (osa)

MOTIVAATIOTEKIJÄ

PRIORITEETTIJÄRJESTYS

VERTAILURYHMÄ OHJELMISTO-AMMATTILAISET
Saavutukset

Arvostus

Työ sinänsä

Vastuu

Eteneminen uralla

Palkka

Kehittymismahdollisuudet

12

3

4

5

6

7

1

4

3

7

5

10

2

Suomen teollisuudessa ohjelmistojen parissa työskentelevät tyypillisesti diplomi insinöörit, insinöörit ja maisterit. Tyypillinen työskentely ympäristö on kirjoituspöytä tai tietokonepääte. Suuret japanilaiset yritykset ovat ottaneet käyttöön käsitteen ohjelmistotehdas(Software Factory). Tällöin tarkoituksena on ilmeisesti ollut korostaa työn standardisoitumista ja rutiininomaista hallintaa. Tunnettua kuitenkin on, että ohjelmistoalueella japanilaiset ovat länsimaista jäljessä. Eräät arviot puhuvat viidestä vuodesta.

1.2 Ohjelmistotyön ajankäytön jakautuminen

Eräs ohjelmistotekniikan (Software Engineering) profeetoista, B. Boehm, on esittänyt taulukon (kuva 2) ohjelmistotyön eri vaiheiden kustannuksista.

Kuva 2. Ohjelmistotyön kustannusten jakautuminen /Boe 791
Kehitys

Ylläpito

Muut

43 %49%

8%

Tästä näkyy selvästi, että ohjelmistokustannukset painottuvat vahvasti käyttöönoton jälkeiseen ajanjaksoon, ylläpitoon (kuva 3).

Kuva 3. Ylläpidon tehtävien jakautuminen /Boe 79/
Pikakorjaukset

Vianhaku

Muutokset tiedostoissa

HW muutosten aiheuttamat muutokset

Uusien ominaisuuksien lisääminen

Dokumenttien parantaminen

Koodin tehokkuuden optimointi

Muut

12,4 %9,3 %

17,4 %

6,2 %

41,9 %

5,5 %

4,0 %

3,4 %

Yksi laatutyön tavoitteista on muuttaa näitä lukuja niin, että jälkikustannusten osuus pienenee. Merkittävin tekijä: tässä suhteessa on ohjelmiston rakentaminen sellaiseksi, että uusien ominaisuuksien lisääminen tehdään mahdollisimman helpoksi ja varmaksi.

1.3 Laitteilla ja ohjelmistoilla eri painoalueet

Laitteisto ja ohjelmistoalueilla on eräitä peruseroja, jotka aiheuttavat työn erilaisen painottumisen (kuva 4):

Kuva 4. Laitteiston ja ohjelmiston eroja /Rep 75/
LAITTEISTO TEKIJÄ OHJELMISTO
Suuri merkitysSuuri merkitys

Jokseenkin hallinnassa

Suuri merkitys

Vakiintuneet

Hyvin määritelty

Vakiintunut

Vakiintunut

Vakiintunut

TuotantoFyysiset ominaisuudet

Kustannusten arviointi

Testausvaatimukset

Standardit

Luotettavuus

Ylläpidettävyys

Herkkyys ulkonaisille vaikutuksille

Dokumentointi

Vähäinen merkitys

Vähäinen merkitys

Pääongelmia

Suuri merkitys

Tilanne sekava

Ei määritelty

Kallista

Tilanne sekava

Tilanne sekava

Ohjelmistoille on tyypillistä, että niihin on helppo tehdä muutoksia. Toisaalta ohjelmiin on vaikea tehdä muutoksia, joilla on ennustettavissa olevia seurauksia. Laitteistoissa jokin osa korvataan toisella samanlaisella. Ohjelmistoissa osa korvataan aina toisella, joka eroaa alkuperäisestä. Eli osan vaihtamiseen liittyy tyypillisesti jonkinasteista uudelleen suunnittelua tai dokumentointia.

2. KOKONAISVALTAINEN LAATUTYÖ

Kokonaisvaltaista laatutyötä ei voi tehdä Irrallaan yrityksen muusta toiminnasta. Seuraavassa on ajattelun kehyksenä käytetty 7 S mallia /Pas 81/, jota olen soveltanut laatutyön kuvioihin. Malli koostuu seitsemästä tekijästä, joista jokaisen alkukirjain on englannin kielessä S.

2.1 Strategy

Laatu on yrityksen kokonaistrategian osa. Laatutyön suunnittelun, johtamisen ja toteutuksen välineenä on laatubudjetti. Perinteisesti ohjelmiston laatukustannukset eivät kuitenkaan näy eksplisiittisesti, koska laatutyötä tehdään niin monella tasolla. Vanha totuus pätee ohjelmistojenkin suhteen: 9/10 viisaudesta on siinä, että on viisas ajoissa.

2.2 Structure

Laatutyö edellyttää hyvin toimivaa organisaatiota, joka yrityksen tarpeiden mukaan voi olla keskitetty, hajautettu jne. Perinteisesti yrityksen laatupolitiikan osatekijöitä ovat suunnittelun laatu, valmistuksen laatu ja palvelun laatu, jotka on voitu eriyttää. Ohjelmistojen suhteen on tällainen jako huomattavasti vaikeampaa.

2.3 Systems

Informaation prosessointi yrityksessä tapahtuu monella tasolla. Ohjelmiston osalta eräänä vaikeuttavana tekijänä on esitysmuotojen moninaisuus. Tieto voi olla paperilla, tietolevyllä, magneettinauhalla, muistipiirissä ja niin edelleen. Tieto tästä tiedosta (metatieto) on vaikeasti saatavissa ja ylläpidettävissä. Informaation prosessoinnin edellytyksenä ovat ohjelmiston suunnittelua, tuotantoa ja ylläpitoa kuvaavat mallit, jotka loppuun asti vietyinä kasvavat erittäin laajoiksi (kuva 5). Sopivat kuvausmenetelmät ovat tässä mallintamisessa aivan olennaisia.

2.4 Staff

Laadukkaiden ohjelmien synnyttämiseksi pitää aktiivisesti pyrkiä luomaan työryhmät siten, että niiden jäsenten kyvyt ovat maksimaalisesti käytössä ja toisaalta täydentävät toisiaan. Käytännön ohjelmointityössä tämä johtaa roolijakoon.

Esimerkkinä (kuva 6) ”Parannettu pääohjelmoijatiimi” /McC 81/:

Projektin hallinnon hoitaja (administrator) vastaa varainkäytöstä, raportoinnista ja resursseista. Projektin vetäjä (project leader) vastaa teknisestä suorituksesta.

Kakkosvetäjä (co-leader) pystyy tarvittaessa ottamaan vastuulleen vetäjän tehtävät, erikoisalanaan atk suunnittelu.

Sovellutusasiantuntija (user Ilaison) tuntee sovellutusalueen ja vastaa käyttäjäkontakteista. Ohjelmoijat (programmers) laativat ohjelmat ja testaussuunnitelmat.

Tekninen toimittaja (technical writer) vastaa dokumenttien viimeistelystä.

2.5 Style

Laatutyössä tyylin ja tahdikkuuden merkitys korostuu liikuttaessa ohjelmistojen alueella. Seuraavassa näkemyksiä työn tueksi:

– Laatumiehen palkkana on hyvä tuote, ei työtovereiden kiitos.

– Laatumies ei saa kilpailla ”ideaprioriteeteista” edes laatualueella. Tärkeintä on, että tuotteet hyötyvät ideoista.

– Ei ole tärkeää, että laatumies on aina oikeassa. Mutta tärkeää on, että laatumies tuntee tai löytää ne ihmiset, jotka tietävät mitkä ovat oikeita asioita.

– Laatumiehen pitää olla taitava kommunikoija; hyvä viestien vastaanottaja ja hyvä lähettäjä.

2.6 Skills

Yrityksillä on tyypillisesti joitakin alueita, joissa ne ovat kilpailijoihin nähden erityisen hyviä. Puhtaasti suomalaista yritystä eivät ohjelmistoalueella sido ulkomaisten emoyhtiöiden kankeat toimintatavat. Suomalainen yritys voi toimia dynaamisesti alansa eturintamassa. Ulospäin tyypillisiä toimintamuotoja ovat erilaiset työryhmät, tutkimusprojektit, käyttövarmuusprojektit, laatu ja standardisointipäivät … Kehityksen kärjessä olevan yrityksen velvollisuutena on varmistaa, ettei ohjelmistotyön alueella tutkimus pääse liiaksi vieraantumaan käytännön todellisuudesta.

2.7 Superordinate Goals

Tämä kohta viittaa siihen, miten yritys näkee yhteiskunnallisen roolinsa. Suomen Laatuyhdistyksen tarkoituspykälässä sanotaan: ”… tehdä tunnetuksi laatufilosofiaa ja laatutekniikkaa sekä edistää niiden soveltamisen ja käytön edellytyksiä Suomessa . Ohjelmistojen laatu on eräs niistä alueista, joilla suomalaiset voivat olla maailman kärjessä.

Asiaa voidaan lähestyä tavoitteiden hierarkian kannalta. Tällöin paljastuu (kuva 7), että laadunvarmistus on osa tuotteenvarmistusta, joka puolestaan on ”tuottavuudenvarmistuksen” osa alue.

Kuva 7. Tavoitteiden hierarkia tuotteiden valmistamisessa
TAVOITTEEN TASO ”EDUNSAAJA”
Laadunvarmistus Käyttäjä, ostaja
(”tuote täyttää käyttäjän tarpeet ja odotukset”)
Tuotteenvarmistus Valmistuttaja, valmistajayritys
(”tuote täyttää myös valmistajan odotukset”)
Tuottavuudenvarmistus Valmistajayritys, yhteiskunta
(”tuote täyttää …)

2.8 Kokonaisvaltaisuus ja luovuus

Kokonaisvaltaisen lähestymistavan perustana on kyky paikallistaa ongelmat ja ottaa selvää tosiasioista. Käytännön työelämässä jo ongelmien olemassa olon myöntäminen saattaa olla vaikeata. Seuraavassa muutamia viisauksia tosiasioihin liittyvästä kysymyksenasettelusta.

A. (Ohjelmiston laadunmittaus)
Ensin: Mitä ohjelmiston laatuun liittyen pitäisi mitata.
Sitten: Miten pitäisi mitata.

B. (Japanilainen muunnos edellisestä)
Ensin: Mikä on todellinen ongelma.
Sitten: Mikä on ongelman ratkaisu.

C. (Eräs länsimainen johtamisperiaate)
Ensin: Miten tehdä oikeita asioita.
Sitten: Miten tehdä: asiat oikein.

D. (Erään luovuuskurssin näkemys)
Ensin: Selvitettävä, onko ongelman tavoite itse asiassa korvattava jonkin hierarkkisesti ylemmän tason tavoitteella.
Sitten: Ratkaistaan ongelma.

E. (Yleistys edellisistä)
Ensin: Löydettävä kehys (malli), johon ongelma sidotaan.
Sitten: Katsotaan, mihin mallin avulla päästään.

Eli laatu, johtamisperiaatteet ja luovuus kytkeytyvät toisiinsa. Ihannetapauksessa tämä näkyy yrityksen toimintatavassa.

3. WALKERIN MALLI

3.1 ”Monikielisyys”

Kommunikointia ohjelmistotyössä vaikeuttaa se, että joudutaan projektin puitteissa käyttämään useita ”kieliä” (kuva 8), joiden välillä tarvitaan tulkkeja.

Kuva 8. Kielet ja niiden tulkit
KIELI LÄHETTÄJÄ VASTAANOTTAJA (TULKKI)
1. Vaatimuskieli Käyttäjä Valmistajan myynti, systeeminsuunnittelija
2. Määrittelykieli Systeeminsuunnittelija Atk suunnittelija
3. Suunnittelukieli Atk-suunnittelija Ohjelmoija
4. Ohjelmointikieli Ohjelmoija Tietokone, testaaja

3.2 Vaihejaon teoria ja käytäntö

Ohjelmistotyön sisälläkin pätee kaunis ajatus, että jokainen vaihe on edellisen asiakas ja jokaisen vaiheen välillä pidetään katselmus tai joku muu tarkastus.

Käytännössä vaihejako ei toimi ideaalisen kauniisti (kuva 9), vaan joudutaan peräkkäisten ja jopa kauempana toisistaan olevien vaiheiden kautta suorittamaan iterointeja.

3.3 Kommunikointi vaakatasossa

Laajoissa ohjelmistoprojekteissa etenee työ useina rinnakkaisina osaprojekteina. Vaikka osaprojektit pyritäänkin saamaan mahdollisimman riippumattomiksi toisistaan, tarvitaan osaprojektien välistä kommunikaatiota (kuva 10).

Käytännössä osaprojektit eivät etene täysin synkronisesti, jolloin kommunikointi vaakatasossa vääristyy. Seurauksena on kommunikaatiotarpeiden kasvu. Toisaalta tapahtuu kommunikaation yksisuuntaistumista siinä mielessä, että myöhästyneet vaiheet joutuvat tyytymään toisten valintoihin.

3.4 Kommunikointiongelmat (yhteenveto)

Ongelma 1 on tulkkiongelma. Tähän ongelmaan ovat lääkkeinä monet määrittely , suunnittelu ja ohjelmointimenetelmät, näiden menetelmien automatisointi, paremmat ohjelmointikielet, ihmisten koulutus.

Ongelma 2 on iterointiongelma. Iteroinnit kuuluvat välttämättä ohjelmointityöhön, jossa vaiheesta riippuen liikutaan erilaisilla abstraktiotasoilla. Ohjelmistotyön prosessi pitää tehdä sellaiseksi, että iteraatiot voidaan tehdä hallitusti. Tähän antaa lääkkeitä Walkerin mallin keskimmäinen taso.

Ongelma 3 on synkronointiongelma. Ohjelmistotyön luonteeseen kuuluu resurssiarvioiden ja aikataulujen laadinnan vaikeus. Tähänkin on syynä ohjelmistotyön abstraktisuus ja myös kokemuksen puute ja se, ettei kokemuksia systemaattisesti panna paperille myöhempää käyttöä varten. Näihinkin ongelmiin tuo helpotusta Walkerin mallin keskimmäinen taso.

Ongelma 4 on ihmisongelma. Kaikissa töissä eri ihmisten kyky kommunikoida vaihtelee, eikä ongelma liity pelkästään ohjelmistotyöhön. Asiaan on saatu parannusta CD kurssien, kielten keskustelukurssien, laatupiirien, katselmusten jne. muodossa. Yhteistä näille muodoille on, että jokaiseen kuuluu kehys, jonka puitteissa ryhmä askartelee. Kehyksenä voivat olla keksityt ongelmat, keksityt tilanteet, todelliset ongelmat, ohjelmien dokumentit jne.

3.5 Walkerin toimintahierarkia

Walkerin malli ohjelmistotyöhön liittyen voidaan esittää kuvan l1 avulla.

Kuva 11. Walkerin malli /Wal 81/

YRITYKSEN OHJAUSTOIMET
Alemmat tasot palvelemaan yrityksen tavoitteita
Sopiva ympäristö teknisten ongelmien ratkaisemiseksi

TEKNISET OHJAUSTOIMET
Tavoitteet
Integrointi

TEKNINEN SUORITUS
Elinkaari
Vaihejako
Vaiheen tehtävät
Tekniikat

Käsitteiden yhtenäisyys
Tuotteenvarmistus

Suunnittele ja organisoi
Miehitä ja koordinoi
Ohjaa ja johda

Walkerin mallin tasoja voidaan luonnehtia informaation varmuusasteiden perusteella (kuva 12).

Kuva 12. Informaation tasot /Wal 81/

YRITYKSEN OHJAUSTOIMET
Laajin näkemyskokonaisuu
Suuri epävarmuus
Vähän algoritmeja apuna
Käsitteet sumeita

TEKNISET OHJAUSTOIMET
Kapeampi näkemys
Enemmän varmuutta
Joitakin algoritmeja apuna
Käsitteet ”pitäisi” tasolla

TEKNINEN SUORITUS
Kapein näkemys
Paljon varmuutta
Paljon algoritmeja
Käsitteet ilmaistavissa jopa lakeina

On melkoisen selvää, että kullakin tasolla tarvitaan persoonallisuudeltaan ja näkemykseltään erilaisia Ihmisiä. Tekniikan taitaja ei aina ole hyvä ohjaustoimien suorittaja.

Menetelmät, joista atk maailmassa on viimeiset 10 vuotta pidetty suurta ääntä kuuluvat alimpaan tasoon. Menetelmiin liittyvistä kursseista on tullut tuottoisaa liiketoimintaa ja jokaisessa arvostetussa atk yrityksessä on vähintään yksi menetelmäasiantuntija. Yleinen havainto on, että mikä menetelmä tahansa on hyvä, kun sitä vain käytetään systemaattisesti.

Käytännön soveltamisen tasolla Walkerin mallin keskimmäinen taso jakautuu kolmeen osa alueeseen, jotka ovat:

– ohjelmiston laadunvarmistus (SQA)
– ohjelmistotuotteen hallinta (SCM)
– dokumenttien hallinta (Data Management, DM)

SCM käsitellään seuraavassa luvussa. DM liittyy dokumenttien muodon ja laadun hallintaan. Esimerkkinä tästä alueesta on KOTELin juuri valmistunut suositus ”Ohjelmistodokumenttien sisältörunko ja kuvausmenetelmät”. SQA ei olennaisesti eroa QA:sta, joten siihen ei laajemmalti puututa /Lon 80/.

4. OHJELMISTOTUOTTEEN RALLINTA (SCM)

4.1 SCM:n pääalueet

SCM (Software Configuration Management) lähtee siitä, että ohjelmiston perusluonteeseen kuuluvat muutokset. Muutostenhallinta on SCM:n keskeisiä alueita. Ohjelmien abstraktisuus ja monet esiintymismuodot edellyttävät yrityksen sisällä standardisoitua tunnistamisjärjestelmää. Vaihejakoon sidottu työskentelytapa, jossa kukin vaihe on edellisen vaiheen asiakas johtaa systemaattisiin tarkastusmenettelyihin, joiden suoritustapa riippuu työvaiheesta. Projektitiedon tallentaminen vastaisen käytön varalle luo valmiuksia analysoida ohjelmistotyötä konkreettisen materiaalin pohjalta. Systemaattisesti tietokoneelle talletetusta tiedosta on hyötyä jo projektin kestäessäkin, koska sen avulla voidaan generoida raportteja eri käyttäjäryhmille.

Suhteessa ohjelmiston laadunvalmistukseen SCM muodostaa perustan, jonka pohjalta laadunohjaus voi saada otteen ohjelmistoihin, niiden tekijöihin ja projektin vetäjiin. SCM:n edellytyksenä on DM, koska dokumentit ovat tärkeä SCM:n apuväline.

Alkuperäinen englannin kielen termi Software Configuration Management kuvaa erittäin huonosti sitä, mistä on kysymys, mutta historialliset syyt ovat jättäneet nimen elämään. Suomennoksella on pyritty selventämään sitä, että tarkastelun kohteena on nimenomaan tuote, korkealla abstraktiotasolla liikkuva ohjelmisto. SCM ei varsinaisesti pyri puuttumaan projektin ohjauksen menetelmiin. Aikataulut ja resurssien käyttö eivät ole SCM:n aluetta, mutta SCM mahdollistaa sen, että johdon ote ohjelmistotyöhön säilyy.

SCM kirjallisuus on voimakkaasti lisääntymässä /Ber 80/ ja /Buc 82/. Lisäksi mainittakoon CM klassikko /Sam 71/, jossa SCM on käsitelty yhdessä luvussa. SLY on järjestänyt 4 päiväisen kurssin aiheesta. Seuraava kurssi on todennäköisesti syksyllä 82. KOTEL on tekemässä suositusta SCM käsikirjan sisältörungoksi ja sen arvioitu valmistumisaika on syksy 82.

4.2 Näkyväisyys ja jäljitettävyys

Ohjelmiston abstraktisesta luonteesta johtuen on SCM:ssä otettu käyttöön käsite näkyväisyys, joka tarkoittaa kolmea asiaa:

A. Ohjelmisto pitää tehdä näkyväksi Ihmisille.
B. Johtamisen otteen pitää näkyä projektissa.
C. Johdon pitää pystyä näkemään mitä projektissa tapahtuu.

Ohjelmiston jäljitettävyys liittyy aikaisemmin mainittuihin moniin ”kieliin” ja niiden välisiin tulkkiongelmiin. Tietty vaatimus, joka ohjelmalle on asetettu pilkkoutuu määrittelyvaiheessa useiksi tarkennetuiksi vaatimuksiksi, jotka suunnitteluvaiheessa hajoavat eri moduuleilla toteutettaviksi. Ohjelman koodausvaiheessa ovat alkuperäiset vaatimukset hajaantuneet vaikeasti hallittavaksi verkoksi eri puolille koodia. Ongelmaan löytyy kuitenkin lääkkeet ja jäljitettävyys voidaan rakentaa ohjelmistoihin. Ylläpitäjät jos ketkä ovat tästä ominaisuudesta kiitollisia.

Toinen jäljitettävyyden alue liittyy projektitiedon tallentamiseen. Suunnitteluketjussa syy seuraus suhteiden jäljittäjä joutuu vastaamaan kysymyksiin miten ja miksi joku asia johtuu toisesta.

4.3 Katselmukset

Ohjelmistoprojekteissa tarvitaan kahden tason katselmuksia. Ylempi taso liittyy osajärjestelmiin tai vastaaviin. Ylemmän tason katselmukset ovat se katselmusten muoto, johon tavallisesti kirjallisuudessa viitataan. Niissä erityyppiset päälliköt ovat vahvasti edustettuina. Alemman tason katselmukset ohjelmistoalueella liittyvät tyypillisesti yhden ihmisen suoritukseen vaihejaon mukaisessa järjestyksessä. Katselmuksen kohteena on jokaisen vaiheen ns. ”vaihetuote”, joka vaiheesta riippuen on eri ”kielistä” dokumenttimateriaalia. Telenokian kokoisessa yrityksessä tällaiset katselmukset ovat viikottaisia, parhaimmillaan neljä katselmusta viikossa.

Ohjelmien katselmuksiin liittyy erilaisia tarkistuslistoja, joita on kahden tyyppisiä. Eksplisiittiset tarkistuslistat ovat kysymyslistoja, jotka liittyvät kohteena olevaan vaihetuotteeseen. Implisiittiset tarkistuslistat ovat itse asiassa yrityksen sisäisiä standardeja. Tällaisia ovat ohjelmadokumenttien sisältörungot, kuvausmenetelmät, katselmusten suoritusohjeet, pöytäkirjojen sisältörungot jne.

4.4 Todentaminen ja kelpoistaminen

Katselmuksien yhteydessä tehtävät, jotka läheisimmin liittyvät SCM:n. alueeseen voidaan ilmaista sanoilla todentaminen (verification) ja kelpoistaminen (validation):

Kelpoistaminen tarkoittaa, että vaihetuotetta verrataan vaatimuksiin tai korjattuihin vaatimuksiin. Todentaminen tarkoittaa, että peräkkäisiä vaihetuotteita verrataan etenkin jäljitettävyyden varmistamiseksi. (Huomattakoon, että esim. testauksen terminologiassa käytetyillä käsitteillä on hieman toinen merkitys.)

5. LAADULLA TULEVAISUUTEEN

Ohjelmien laatutyössä pyritään Integroimaan säännöt ja ohjeet, toisaalta hajauttamaan käytännön toteutus. Laatupiiriä on vaikea soveltaa itse ohjelmien tekemisessä, mutta laatupiiriajattelua tarvitaan suunnittelijan ja ohjelmoijan työympäristöä kehitettäessä.

Ohjelmistotyön ongelmana oli 60-70 -luvulla, että ohjelmat olivat liikaa tekijänsä ja tietokoneen välinen asia, johon ulkopuoliset eivät hevillä voineet puuttua. Nyt tästä ongelmasta on päästy, mutta ohjelmatyöskentelyn tietokonetuenta saattaa johtaa uudelleen vanhaan huonoon tilanteeseen, ellei työn avoimuutta saada uudella tavalla järjestetyksi.

Laatuihmisten pitää pystyä tekemään itselleen selväksi, mitkä ovat oikeita asioita ja sitten voi tehdä asiat oikein. Ilmeisesti löytyy primäärisiä vaatimuksia: ohjelmien on oltava mahdollisimman hyviä, ja sekundäärärisiä vaatimuksia: dokumenttien on oltava riittävän hyviä. Ei pidä sellaisenaan hyväksyä väitteitä kuten: ”Tuotteen laatu on osatekijöiden laadun tulo tai ”Laatu on sama kuin heikoimman lenkin laatu.”

Valmistajalle on tärkeää saada laatutietoisia asiakkaita, jotka tietävät mitä tahtovat ja miten tahtovat.

Kehityksen pahimpia jarruja on ajatustentappajafraasit: ”That is the same as …” tai ”Miksi tästä puhutaan niin paljon, eihän tässä ole mitään uutta.” Näin on mutta jotkut tekevät sen mitä pitää ja menestyvät myös tulevaisuudessa.

Tätä: kirjoittaessani sain pöydälleni lehden /Die 82/, jossa Anders Diehl Japanin terveisinä siteerasi Bow1ingin laadunvarmistuksen määritelmää: ”Laadunvarmistus varmistaa, että yritysjohto hoitaa tehtävänsä.” Tässä laadunvarmistus tarkoittaakin ehkä samaa kuin kuvan 7 ”tuotteenvarmistus”. Tai ehkä japanilaiset käytännössä tekevätkin ”tuottavuudenvarmistustyötä”?

6. KIRJALLISUUTTA

Ber 80 Bersoff, Hendersson, Siegel: ”Software Configuration Management”, Prentice Rall 80.

Boe 79 Boehm, B.W.: ”Software Engineering as it is”, Proc. of the 4th Int. Conf. on Soft. Eng. 79.

Buc 82 Buckle, J.: ”Software Configuration Management”, Macmillan 82.

Die 82 Diehl, A.: Se1133:s laatupiiri*’, Elektroniikka 5/82.

Fit 78 Fitz ens, J.: ”Who Is the DP Professional?”, Datamation vol 24, no 9, Sept 78.

Lon 80 Longbottom, R.: ”Computer System Reliability”, Wiley & Sons 80.

Mcc 81 McClure, C.L.: ”Managing Software Development and Maintenance”, Van Nostrand 81.

Pas 81 Pascale, Athos: TheArt of Japanese Management”, Penguine Books 81.

Rep 75 Report of the Ninth Annual Data and Configuration Management Workshop, Oct 75. Electronics Industries Association.

Sam 71 Samaras, Czerwinski: ”Fundamentals of Configuration Management”, Wiley Interscience 71.

Wal 81 Walker, G. M.: ”Managing Software Reliability”, North Holland 81.

 

grohn

Asun Nauvossa, Bryssel 97-04 Tutkinto: teoreettinen fysiikka. Työura: Yliopisto, iltaoppikoulu, Ollituote, Kone, Telefenno, Telenokia, Tekes 84-97, yrittäjä Bryssel, Euroopan komissio (mm, km). Yrittäjä 05-17. Rakensin kotona tietokoneen 76. Skepsis ry:n siht. 91-92, pj. 93. Kehitin 1997 (Psion) ja 2001-2015 (pc/mac) ohjelman, joka muuttaa valokuvat musiikiksi: http://www.synestesia.com/cd05/2005.html

Ilmoita asiaton viesti

Kiitos!

Ilmoitus asiattomasta sisällöstä on vastaanotettu