tiistai 15. joulukuuta 2009

Object-oriented and Classical Software Engineering

Stephen R. Schach, Object-oriented and Classical Software Engineering, 6th ed. McGraw-Hill, New York, NY, 2005. 

Eteläafrikkalainen Stephen R. Schach valmistui maisteriksi fysiikasta, mutta vaihtoi pian alaa, väitteli matematiikasta ja päätyi ohjelmistotuotantoprosesseja tutkivaksi tietojenkäsittelijäksi. Vaikka tietojenkäsittelyssä on monta mielenkiintoista tutkimusaluetta, ohjelmistotuotannon saavutuksilla lienee kauaskantoisimmat vaikutukset tutkimusalueen ulkopuolella "todellisuudessa". Niin, ohjelmistotuotanto (software engineering) on oppisuunta, joka tähtää virheettömän, käyttäjän tarpeita vastaavan ohjelmiston toimittamiseen sovitussa aikataulussa ja budjetissa. Jotta näihin ideaaleihin päästään, on syytä ohjelmistoa kehittäessä soveltaa sopivia tekniikoita, joita mm. tässä kirjassa käsitellään.
 
Heti alkuun Schach lukeekin opiskelijalle tai tulevalle ammattilaiselle madon luvut. Vuonna 2000 tehdyn 280,000 kehitysprojektia käsittäneen tutkimuksen mukaan vain 28% onnistui suunnitellusti, 23% projekteista keskeytettiin, ja loput 49% toimitettiin myöhässä, arvioitua budjettia kalliimpina ja vähemmin toiminnallisuuksin (tutkimustuloksia on tietenkin sittemmin arvosteltu). Toisen, vuonna 1976 tehdyn tutkimuksen tunnistama huono onnistumisprosentti herätti keskustelun ohjelmistokriisistä. Oman kokemukseni mukaan kriisi on kaikkea muuta kuin ohi.

Ennen vuotta 1975 alalla ei ollut juuri laajalle levinneitä kehitysmenetelmiä. Klassinen ohjelmistokehitysmalli hahmottui seuraavan kymmenen vuoden aikana tarjoten järjestelmälliset tavat tietorakenteiden ja -voiden analyysiin, ohjelmointiin ja testaukseen. Malli osoittautui kuitenkin riittämättömäksi järjestelmien kasvaessa ja kompleksisuuden lisääntyessä. Klassiset menetelmät keskittyvät tyypillisesti operaatioihin, joilla tietoa muokataan, tai sitten tietomallinnukseen, jonka ympärille ohjelmisto rakennetaan, mutta ei molempiin. Olio-ohjelmointi on paradigma, jossa tieto ja sitä koskevat operaatiot paketoidaan olioiksi, joiden käyttäytyminen on huomattavasti helpompi suunnitella, toteuttaa ja testata. Olio-ohjelmoinnin edut ovat kiistattomat, ja Schach kuljettaakin klassista ohjelmistoparadigmaa mukana tekstissä nimenomaan vertailukohtana.

Object-oriented & Classical Software Engineering ilmestyi ensimmäisen kerran vuonna 1990. Käsillä oleva kuudes laitos on vuodelta 2005. Väliin mahtuu tietotekniikan laaja leviäminen ja internet. Kirjaa on tietenkin korjailtu ja kirjoitettu uudestaan, mutta osa tekstistä nojaa vanhoihin lähteisiin. Tämä on hyvä ja huono. Hyvä se on siksi, että tietojenkäsittelytiede ei ole eikä pitäisi olla pelkkää tekniikkaa vaan myös kulttuuri. Monien "uusien" juttujen juuret ovat 1970-luvulla tai kauempana. Näin on esimerkiksi inkrementaalisen ja iteratiivisen projektimallin kohdalla, samoin olio-ohjelmoinnin. Huonoa on se, että, jos nopeasti kehittyvältä alalta pitää antaa yleiskatsaus, vanhojen ja todennäköisesti vähän käytettyjen ohjelmistometriikoiden läpikäyntiin ei ole ehkä tarve uppoutua. Pahempi ongelma on, että eri aikoina kirjoitettu teksti ei kulje luvusta toiseen kauniisti, vaan se tuntuu erityisesti loppua kohden poukkoilevan.

Kirjan ensimmäinen osa esittelee ohjelmiston elinkaarimalleja, kehitysprosesseja, kehitystiimejä, kehitystyökaluja, testausta, suunnittelua, uudelleen käyttöä, suunnittelua ja arviointia. Toinen osa käsittelee ohjelmiston elinkaaren työnkulkuja (workflow) kuten mm. vaatimusmäärittely (klassinen ja oliomalli), suunnittelu, toteutus ja ylläpito. Kaaviot ovat pääosin joko ER tai UML-tekniikoin piirrettyjä. Kiusallista on, että Java-ohjelmointiesimerkit, jotka ovat toki vain esimerkkejä, rikkovat paikoin Javan perusideologiaa. Kirjoittaja mainitsee agile-menetelmät mutta ei usko niiden voimaan suurten projektien toteutuksessa. Vastaesimerkkejä on olemassa, mutta Agile-menetelmät vaatinevat tiukkaan ammattietiikkaan sitoutumista, ja kovat ammattilaiset saavat millä tahansa menetelmällä asiat hoidettua -- Agile-menetelmät ovat vain yksi hyvä tapa. Jos tekijätiimissä vallitsee vaatimattomampi ammatillinen eetos, esim. vesiputousmalli takaa, että useimmiten saadaan edes jotain ulos jossain vaiheessa.

Kirja oli hyvä muistinvirkistys, ja eheämpi sisällysluettelo tekisi kirjasta kohtuullisen manuaalin. Hajanaisuus on ehkä tiedostettu, koska Schachilta julkaistiin heti 2007 uusi teos Object-Oriented Software Engineering, josta siis klassinen menetelmistö on pudonnut ainakin otsikosta.

Ei kommentteja:

Lähetä kommentti

O niin kuin oikeus

Kun entisen aviomiehen (so., ensimmäisen entisen aviomiehen) pienvaraston sisältö päätyy huutokaupattavaksi maksamattomien laskujen vuoksi,...