Vuonna 1987 Yhdysvaltain ilmavoimat perusti Software Technology Support Centerin (STSC). Sen tehtävänä oli ”auttaa organisaatioita tunnistamaan, arvioimaan ja ottamaan käyttöön teknologioita, jotka parantavat ohjelmistotuotteiden laatua, tuotannon tehokkuutta ja ennustettavuutta” (Lähde). Tämän tavoitteen saavuttamiseksi STSC perusti verkkotiedotteen nimeltä CrossTalk: Puolustavan ohjelmistotekniikan aikakauslehti, jota se julkaisi verkkosivustollaan (Stsc.hill.af.mil) vuosina 1996–2016.
Myöhemmin STSC loi verkkosivuston Crosstalkonline.org, jossa CrossTalkin julkaisemista jatkettiin. Vuodesta 2017 lähtien sivustolle ei kuitenkaan ole päässyt.
Mitä sille on voinut tapahtua? Yritämme selvittää asian tutustumalla julkaisun historiaan. Päätämme tämän artikkelin tarkastelemalla kymmentä tärkeintä artikkelia, jotka siinä julkaistiin.
CrossTalkin historia
CrossTalk alkoi ilmestyä vuonna 1988 edistääkseen tekniikoita, joilla varmistetaan korkealaatuisten ohjelmistojen kehittäminen. STSC:n mukaan julkaisun tavoitteena oli ”parantaa sotilaallisen suorituskykymme luotettavuutta, ylläpidettävyyttä ja reagointikykyä sekä ohjata, tiedottaa ja kouluttaa lukijoita ajantasaisista toimintaperiaatteita koskevista päätöksistä ja uusista ohjelmistoteknologioista” (Lähde).
Reuel Alderin (julkaisija), Tracy Stauderin (vastaava toimittaja) ja Sandi Gaskinin (vanhempi toimittaja) johdolla CrossTalk kasvoi noin 200 tilaajasta 29 000 tilaajaan (Lähde).
Stsc.hill.af.mil, sivusto, jolla CrossTalkia alun perin julkaistiin, perustettiin joulukuussa 1996. Aiemmat vuosikerrat löytyvät täältä.
Stsc.hill.af.mil-sivustolla oli tilauslomake, ohjeet tuleville kirjoittajille ja ilmoituksia tulevista teemoista. Sivustolla oli myös sivu, joka sisälsi julkaisun kokoaikaisen henkilöstön yhteystiedot.
CrossTalk pysyi STSC:n verkkosivustolla marraskuuhun 2010 asti, jolloin se siirtyi omalle sivustolleen: Crosstalkonline.org. Viimeisin internetiin tallennettu CrossTalkin numero on elokuulta 2017.
Siitä, mitä verkkosivustolle ja julkaisulle tapahtui elokuun 2017 jälkeen, on saatavilla hyvin vähän tietoa.
CrossTalkin julkaisemat 10 tärkeintä artikkelia
CrossTalkin muistoksi tunnistimme kymmenen tärkeintä artikkelia, jotka se julkaisi toimintansa aikana.
Näiden artikkeleiden tunnistamiseksi keskityimme niiden linkkien määrään, joita verkkosivustojen ylläpitäjät ja toimittajat olivat niille antaneet. Artikkeleiden, jotka keräävät enemmän linkkejä (viittauksia), voidaan todennäköisesti katsoa olevan tärkeämpiä kuin artikkeleiden, jotka keräävät vähemmän linkkejä.
1. Tietojenkäsittelytieteen koulutus: Missä ovat huomisen ohjelmistoinsinöörit?
Akateemikot Robert Dewar ja Edmond Schonberg, jotka olivat tuolloin molemmat New Yorkin yliopiston tietojenkäsittelytieteen professoreita, käyttävät tätä artikkelia väittääkseen, että tietojenkäsittelytieteen koulutuksessa (vuonna 2008) laiminlyötiin tarpeelliset taidot.
Kirjoittajat syyttävät tilanteesta yleistä ”Javan käyttöä ensimmäisenä ohjelmointikielenä”. He esittivät yhteenvedon taidoista, joiden he uskovat kuuluvan jokaisen ohjelmistoalan ammattilaisen perustyökaluihin: ohjelmointikielet, testienhallintatyökalut laajamittaisten ja luotettavien ohjelmien rakentamiseen sekä formaalit todistusmenetelmät (lähde).
Have an account? Log In
2. Ketterän kehityksen skaalaaminen: suurten ja monipaikkaisten tuotteiden kehittäminen laajamittaisen Scrumin avulla
Konsultit Craig Larman ja Bas Vodde käyttivät tätä vuonna 2013 kirjoitettua artikkelia tiivistääkseen kaksiosaisen, erittäin laajamittaista ketterää kehitystä käsittelevän kirjasarjansa sisällön. He kuvasivat, kuinka he ovat työskennelleet asiakkaiden kanssa ottaakseen käyttöön kaksi laajamittaisen Scrumin viitekehystä suurissa maailmanlaajuisissa organisaatioissa. Esimerkkejä yrityksistä, joiden kanssa he työskentelivät, ovat Bank of America ja televiestintäinfrastruktuurilaitteiden toimittaja Erickson.
Larman ja Vodde kertovat kokemustensa johtaneen heidät julkaisemaan kaksi osaa. Osa 1 on Ajattelu- ja organisaatiotyökalut laajamittaiseen Scrumiin. Se keskittyy johtamiseen ja organisaation suunnitteluun. Toinen osa on Lean- ja ketterän kehityksen skaalaamisen käytännöt: laajamittainen, monipaikkainen ja ulkoistettu tuotekehitys laajamittaisella Scrumilla. Se tarjoaa käytännön ehdotuksia skaalaamiseen erilaisissa tilanteissa.
3. Sekä inkrementaalisen että iteratiivisen kehityksen käyttäminen
Tämän vuonna 2008 julkaistun artikkelin kirjoittaja, tohtori Alistair Cockburn (jonka CrossTalk kuvailee olio-orientoituneen (OO) suunnittelun, ohjelmistokehitysmenetelmien, käyttötapausten ja projektinhallinnan asiantuntijaksi), keskittyy ohjelmistoalalla inkrementaaliseen ja iteratiiviseen kehitykseen.
Tohtori Cockburn tunnistaa haasteet, joita tiimit kohtaavat käsitellessään inkrementaalista ja iteratiivista kehitystä: niitä yritetään hallita samalla tavalla tai ajatellaan, että kun toista käytetään, toista ei pitäisi käyttää. Hän päättää tiivistämällä ajatuksensa: "Sana lisäys tarkoittaa lisäämistä; sana iterointi tarkoittaa uudelleen tekemistä” (lähde).
4. SmartCam3D tarjoaa uudenlaista tilannetietoisuutta
Tässä vuonna 2005 julkaistussa artikkelissa Janis White (tilastokonsultti), Frank Delgado (joka työskenteli NASA:lle) ja Mike Abernathy (ohjelmistoasiantuntija) keskittyvät SmartCam3D:hen (SC3D). Se on ”hybridi synteettinen näköjärjestelmä, joka yhdistää reaaliaikaisen anturitiedon synteettisen näköjärjestelmän tietoihin virtuaalisen ohjaamon ikkunan luomiseksi.”
Kirjoittajat esittelevät hybridi-synteettisen näköjärjestelmän (HSVS). He kuvailevat sen järjestelmäksi, joka yhdistää ”reaaliaikaisen anturidatan synteettisen näköjärjestelmän (SVS) tietoihin reaaliaikaisten ja tietosisällöltään rikkaiden visualisointien luomiseksi.” He päättävät toteamalla, että SC3D oli ensimmäinen reaaliaikainen HSVS-järjestelmä ja ehdottavat, että ”tämä ohjelmisto pelastaa ihmishenkiä” (lähde).
5. CMMI tukee koko organisaation kattavaa prosessien parantamista
Everstiluutnantti Joe Jarzombek, joka työskenteli tuolloin Earth Science Information Partnersissa (ESIP), tieteellistä dataa helpommin saataville tekevän yhteisön johtajana, käytti tätä artikkelia esitelläkseen kypsyysmallien (CMM) ajatuksen. Sillä tarkoitetaan mallikokonaisuuksia, jotka käsittelevät eri tieteenalat ylittäviä organisaation toimintatapoja ja osaamisalueita.
Jarzombek esittelee CMMI-tiimien ajatuksen. Niillä tarkoitetaan ”yhteistyöhön perustuvaa pyrkimystä integroida CMM-malleja”. Hänen mukaansa tällaiset yksiköt loisivat joukon yhdistettyjä tuotteita, jotka tukevat prosessien ja tuotteiden parantamista ohjelmistokehityksen alalla (lähde).
6. Miksi suuret ohjelmistoprojektit epäonnistuvat: 12 keskeistä kysymystä
Tässä vuonna 2005 julkaistussa artikkelissa, jonka kirjoitti Carnegie Mellon -yliopiston Software Engineering Instituten (SEI) Watts S. Humphrey, keskitytään 12 kriittiseen kysymykseen siitä, miksi suuret ohjelmistoprojektit epäonnistuvat.
Humphreyn mukaan artikkelissa esitettyihin kysymyksiin vastaaminen auttaa ohjelmistokehittäjiä parantamaan projektejaan. Hänen mukaansa keskeiset ongelmat liittyvät syihin, joiden vuoksi suurten ohjelmistoprojektien hallinta on usein haastavaa, tarvittaviin hallintajärjestelmiin sekä siihen, mitä näitä järjestelmiä käyttöönotettaessa on tehtävä (lähde).
7. Pilvilaskennan mysteerien selvittäminen
Tarkastellessaan vuonna 2011 ohjelmistokehityksessä tapahtuneita muutoksia Egyptin Mansouran yliopiston tietokone- ja informaatiotieteiden laitoksen Qusay F. Hassan keskittyy pilvilaskentaan.
Artikkelissa hän pyrkii käsittelemään ajatusta, että ihmiset käyttävät usein termiä ”pilvilaskenta” väärin viitatessaan asioihin, jotka eivät välttämättä liity sen todelliseen määritelmään ja laajuuteen. Onko kyse pelkästään verkkopalvelinten ylläpidosta? hän kysyy. Sen jälkeen hän määrittelee useita käsitteitä, kuten verkkopalvelinten ylläpidon, sovelluspalveluntarjoajan (ASP), vapaaehtoisen laskennan ja verkkotiedostojen jakamisen sekä monia muita (Lähde).
8. Oikeellisuus rakentamalla: korkean eheyden ohjelmistojen julistus
”Korkean eheyden ohjelmistojärjestelmät ovat usein niin suuria, etteivät tavanomaiset kehitysprosessit pysty läheskään saavuttamaan hyväksyttäviä virhemääriä”, sanovat Martin Croxford ja tohtori Roderick Chapman tämän kirjoituksen alussa. Kun kirjoittajat laativat tämän kirjoituksen, he työskentelivät Praxis High Integrity Systems -yrityksessä, joka on kriittisiin järjestelmiin erikoistunut brittiläinen järjestelmätekniikan yritys (Lähde).
Tässä vuoden 2005 artikkelissa kirjoittajat lupaavat esittää lähestymistavan, jolla on kustannustehokkaasti tuotettu ”ohjelmistoja, joissa on erittäin vähän virheitä”. Heidän kuvaamansa menetelmä on oikeellisuus rakentamalla (CbyC). Se on ohjelmistokehityksen lähestymistapa, joka mukautuu hyvin muutoksiin koko elinkaarensa ajan ja jonka virhemäärät olivat pienemmät kuin tuolloin käytössä olleissa kaupallisissa käytännöissä (Lähde).
More Articles
9. Selaimen käyttöliittymän suunnitteluvirheet: käyttäjien tietämättömyyden hyödyntäminen
Tämän artikkelin kirjoittivat vuonna 2011 Aditya Sood, joka oli tuolloin Michigan State Universityn tohtorikoulutettava, sekä Richard Enbody, Michigan State Universityn tietojenkäsittelytieteen ja tekniikan laitoksen apulaisprofessori. Artikkelin tiivistelmässä kirjoittajat toteavat, että ”selainten suunnitteluvirheet muodostavat vakavan uhan käyttäjien turvallisuudelle, yksityisyydelle ja eheydelle”.
Kirjoitus keskittyy graafisen käyttöliittymän (GUI)
komponenttien suunnitteluvirheisiin. Kirjoittajat ehdottavat, että huijarit hyödyntävät juuri näitä virheitä huijatessaan käyttäjiä tekemään asioita, jotka vaarantavat heidän turvallisuutensa (Lähde).
10. Vanhenevien ohjelmistojen ikääntymiseen liittyvät ongelmat
Ohjelmistojen tuottavuuden tutkimuksen parissa tuolloin työskennellyt Capers Jones keskittyy liiketoiminnan ja julkisen sektorin vanheneviin ohjelmistoihin liittyviin ongelmiin. Tässä vuoden 2007 kirjoituksessa Jones kertoo, ettei tuolloin ollut yllättävää löytää organisaatioita käyttämässä yli 10 vuotta vanhoja ohjelmistoja, joiden sovellukset saattoivat olla jopa 25 vuotta vanhoja.
Jones käsittelee myös vanhenevien ohjelmistojen seurauksia ja huomauttaa, että tällaisten ohjelmistojen ylläpito vaikeutuu, koska päivitykset usein tuhoavat sovellusten alkuperäisen rakenteen. Tämä lisää entropiaa eli ennakoitavuuden ja järjestyksen puutetta. Hän toteaa, että ohjelmiston vanhetessa korjausten aiheuttama virheiden lisääntyminen johtaa siihen, että ”uusia virheitä syntyy vahingossa aiempien virheiden korjaamisen sivutuotteena” (Lähde).
