Ohjelmistoarkkitehtuurit Tuoterungot. Kevät 2016

Transkriptio

1 Ohjelmistoarkkitehtuurit Tuoterungot Kevät 2016 Samuel Lahtinen Ohjelmistoarkkitehtuurit

2 11. Tuoterunkoarkkitehtuurit Johdanto Näkökulmat tuoterunkoihin perustuvaan ohjelmistokehitykseen: liiketoiminta, organisaatio, prosessi, tekninen Tuoterunkojen etuja ja ongelmia Ohjelmistoarkkitehtuurit

3 Tuoteperheajattelu yleisesti Samankaltainen tuote eri ominaisuuksin eri kohderyhmille Autot: Varustetason vaihtelu Suorituskyvyn vaihtelu (moottori tai ohjelmistotasolla) Korimallit Facelift-versiot jne. Näytönohjaimet: Suorituskyky, virrankulutus, äänekkyys Sama tuotantolinja, karsitut versiot (esim. testataan premium-kortteja, testejä läpäisemättömät karsittuina versioina matalammalla suorituskyvyllä, toimintojen lamauttaminen mekaanisesti tai biosin avulla) Ohjelmistoarkkitehtuurit

4 Uudelleenkäyttö opportunistinen: hyödynnetään aikaisempaa koodia, joka sattumalta sopii uuteen sovellukseen. suunniteltu: organisaatio käyttää resursseja yleisesti uudelleenkäytettävien ohjelmistojen kehittämiseen, jotka tarjoavat yrityksen alaan sopivat abstraktiot ja variaatiopisteet. oppotunistinen tapa ei toimi hyvin käytännössä Uudelleenkäyttö vaikeaa, suunniteltukaan tapa ei takaa onnistumista alhaalta-ylös: potentiaalisesti uudelleenkäytettävät komponentit lisätään yleisesti käytössä olevaan komponenttikirjastoon, josta haetaan valmiita komponentteja uuteen sovellukseen. ylhäältä-alas: uudelleenkäytettävät ohjelmistot tehdään johonkin laajempaan kokonaisuuteen sopiviksi (esim. rajapinnat, arkkitehtuurit, kehykset) alhaalta-ylös tapa johtaa matalan tason uudelleenkäyttöön Ohjelmistoarkkitehtuurit

5 Määritelmiä Tuoteperhe: joukko koordinoidusti kehitettyjä ohjelmistotuotteita, joilla on samankaltainen rakenne ja toiminta. Tuotelinja: kaikki artifaktit, välineet ja prosessit, jotka tukevat tuoteperheen jäsenten kehittämistä ja ylläpitoa. Tuoterunko, tuotealusta: tuoteperheen yhteinen ohjelmistoalusta Tuoterunkoarkkitehtuuri, tuoteperhearkkitehtuuri: tuoteperheen yhteinen arkkitehtuuri, tuoterungon arkkitehtuuri Ohjelmistoarkkitehtuurit

6 Tuoterunko = yhteiseen arkkitehtuuriin ja alustaan perustuva ohjelmistojen uudelleenkäyttö Tuoterunkoarkkitehtuurit (Product-line Architectures): azayeri Software Product Line Engineering: Foundations, Principles and Techniques:Klaus Pohl, Günter Böckle, Frank J. van der Linden (2005) ViewFBC /Pohl_et_al%282005%29.pdf Ohjelmistoarkkitehtuurit

7 Anna esimerkkejä tuoterunkoajatteluun sopivista sovellusalueista Ohjelmistoarkkitehtuurit

8 Tuoterunkoajattelua: tuoteesimerkkejä Angry Birds, Angry Birds Rio, Angry Birds Magic, Angry Birds Space, Angry Birds Star Wars, Angry Birds Star Wars II, Angry Birds Seasons, Angry Birds Stella. Candy crush/ /whatever Saga Työkaluista Ohjelmistoarkkitehtuurit

9 Tuoterunkoajattelua jatkuu Flockler: räätälöity CMS (weppisivut jne. + niiden hallinta). ~150 asiakasta, jokaiselle yksilöllistettyä sivustoa, mutta alla sama pohja Ruby on Rails ja Javascript (Ember.js) Sandvik: liikkuvat koneet, sama tuoterunko erilaisille koneille Yleisemmin erilaiset laiteperheet Piceasoft: ohjelmistoja tiedon siirtoon puhelimista/puhelimiin. Eri kohderyhmiä, loppukäyttäjä, kännykkämyymälät, operaattorit, pohjalla sama ohjelmisto Vision Systems ja konenäköjärjestelmät Ohjelmistoarkkitehtuurit

10 Esimerkkejä tuoterungoista Kännykkäalustat Vakuutusjärjestelmäalustat Pankkijärjestelmäalustat Tietokone- ja kännykkäpelialustat Koneenohjausjärjestelmäalustat Ohjelmistoarkkitehtuurit

11 Tuoteperhe-esimerkki (Vignet terveyspalveluita) Ohjelmistoarkkitehtuurit

12 Ohjelmistorunko ja laitteet Ohjelmistoarkkitehtuurit

13 Ohjelmistot eri versioin ja palvelutasoin varustettuna Karvalakki/ilmaisversio/testiversio Perusversio Premium-mallinen Ohjelmistoarkkitehtuurit

14 Jotain toteutustapoja Rekisteröinti Yksinkertaisin malli, ostaessa saa koodin, jolla voi aktivoida täyden version Sama hieman fiinimpänä, rekisteröinti sovelluksen kautta, sovellus naitetaan laitteeseen, jossa se on Käynnistyksen yhteydessä tehtävä tarkistus, löytyykö lisenssitiedostoa (tai nettiyhteysvarmistus) Lisenssitiedoston tarkistaminen ja koneen tarkistaminen, esimerkiksi Windows Usein kaikki sovellusversiot samassa paketissa, mutta ajoaikaisesti tarkistus, löytyykö lisenssiä Myös kirjastojen käyttö, laajennetun version kirjastototeutuksien lataaminen paremman version rekisteröinnin yhteydessä Ohjelmistoarkkitehtuurit

15 Tuoterunkoihin pohjautuva ohjelmistokehitys Keskeiset tavoitteet: merkittävä uudelleenkäyttö, lyhyempi kehitysaika, parempi laatu vähemmillä resursseilla, yhdenmukainen ja rationalisoitu kehitysprosessi, yhdenmukaiset tuotteet Edellytykset: halutaan tuoteperhe, jolla on riittävästi yhteisiä ominaisuuksia ja hyvin ymmärretty variaatio: vaatimusten on määriteltävä soveltamisala, yhteiset vaatimukset ja variaatiopisteet Tuoterunkotyyppisiin tilanteisiin joudutaan joskus myös ilman selvää tuoteperhekonseptia: Tuntemattomat vaatimukset johtavat usein variaatiopisteisiin Avoin lähdekoodi on usein tulkittavissa tuoterunkona Tuotteista halutaan räätälöitäviä Ohjelmistoarkkitehtuurit

16 Tuoterunkoihin pohjautuvan ohjelmistokehityksen näkökulmat Liiketoimintanäkökulma Milloin tuoterunkolähestymistapa kannattaa taloudellisesti? Millaisten taloudellisten mallien pohjalta voidaan tehdä päätöksiä? Organisaationäkökulma Miten organisaatio voi omaksua tuoterunkoajattelun ja tukea tuoterunkoon pohjautuvaa kehittämistä? Prosessinäkökulma Millainen kehitysprosessi sopii tuoteperheille? Tekninen näkökulma Millaisia arkkitehtuurimalleja ja teknologioita käytetään tuoterungoille? Ohjelmistoarkkitehtuurit

17 Liiketoimintanäkökulma 4C 3C takaisinmaksu perinteinen tuoterunko 2C 1C alustan rakentaminen Sovellusten lukumäärä Ohjelmistoarkkitehtuurit

18 Liiketoimintanäkökulma Perustuu työmääräarviomenetelmiin In H.P. et al.: A quality-based cost estimation model for the product-line life-cycle. CACM 49 (2006), Ohjelmistoarkkitehtuurit

19 Laskentamalleja ml Ohjelmistoarkkitehtuurit

20 pulmapelitehdas Yritys pohtii mahdollisuuksia lähteä tuottamaan kännykkään pulmapelituoterunkoalustaan perustuen (Tetris, palluroiden, värien jne. yhdistelypelit) Oletetaan, että pulmapelisovelluksen toteuttamisen keskihinta on e, ja sovelluksen kehittäminen kestää 6kk (ilman tuotealustaa). Millä edellytyksillä yrityksen kannattaa investoida tuotealustaan, jos tuotealustan perustamiskustannukset ovat e ja toteutustyöhön kuluu 12kk, ja tämän jälkeen pelisovelluksen hinta on vain e, ja aikaa tarvitaan vain 2kk per peli? Kuinka monen pelin jälkeen tuoterunko maksaisi itsensä takaisin siinä tapauksessa, että ensimmäinen peli tehdään erikseen rinnan tuotealustan kanssa, ottaen huomioon, että tämän pelin siirtäminen tuotealustan päälle maksaisi e? Tarkastele asiaa eri puolilta yrityksen johdon kannalta, ottaen huomioon mahdolliset liiketoimintatavoitteet, henkilöresurssien käyttö, reagointikyky markkinoihin ym. Ohjelmistoarkkitehtuurit

21 Esimerkki ( oikea ) Sovellusalue: videopelit Perinteinen Santelices R.A., Nussbaum M.: A framework for the development of videogames. Software Practice & Experience 31 (2001), peli 2. peli 3. peli työtuntia Kehykseen perustuva Kehyksen rakentaminen + koulutus Suorituskyky: aika +70% tila +200% Ohjelmistoarkkitehtuurit

22 Tuoterungoista ja kustannuksista Tuoterungon tekeminen ilman tuotetta haastavaa Väärien asioiden abstrahointi, yleistäminen Helppo jäädä junnaamaan paikallaan Ilman tuotetta vaikea arvioida olennaisia asioita Yleinen tapa, tehdään ensimmäinen tuote nopeasti Kokemuksien hyödyntäminen, tuoterungon tekeminen helpompaa ja nopeampaa Saadaan tuote nopeasti markkinoille Vaaroja, ensimmäisestä tuotteesta räävitään väkisin yleistettävämpää Ohjelmistoarkkitehtuurit

23 Tuoterungot, etuja: kirjaa tähän Ohjelmistoarkkitehtuurit

24 Tuoterungot, ongelmat: kirjaa tähän Ohjelmistoarkkitehtuurit

25 Tuoterunkojen etuja Etuja: Pitkälle viety koodin, osaamisen uudelleenkäyttö Erikoisosaamisen tarve vähenee tuotteiden toteuttajilla Tuoterunko voi hoitaa laitteistoläheistä, tietokantaspesifistä, vaativaa laskentaa jne. (sovellusten toteuttajissa esim. UI-osaajia jne.) Nopeutunut tuotesykli Tuottavuuden kasvu pitkällä tähtäyksellä Tuotteiden standardointi Kehitysprosessien ja työkalujen standardointi Laadun paraneminen Tukee nopeaa protoilua (jos tuoterunko olemassa) Ohjelmistoarkkitehtuurit

26 Potentiaalisia ongelmia Henkilökunnan vaihtuvuus: motivointi, asiantuntemus, gurukeskeisyys Jäykistää kehitystä Konfliktit alusta vastaan tuotteet (kattavuus, aikataulut, resurssit ym.) Konfliktit tuotteiden haluttujen ominaisuuksien välillä Tuotantoviive: ensimmäinen tuote kestää kauan Testaus: miten testataan tuoterunko? Tuoterungon fokuksen katoaminen Kvartaaliekonomia Ohjelmistoarkkitehtuurit

27 Uudelleenkäytön kypsyystasot Konfiguroitava tuoterunko (automaattinen tuki tuotteen rakentamiselle) Kypsyystaso Yhteinen arkkitehtuuri, variaatiopisteet (tuoterunko) Yhteinen alusta, yhteistä toiminnallisuutta Standardisoitu infrastruktuuri (yhteinen OS, DB, GUI jne.) Riippumattomat tuotteet Ohjelmistoarkkitehtuurit

28 Eri tapoja lähteä tuoterunkopohjaiseen ohjelmistokehitykseen Onko yrityksellä aikaisemmin ohjelmistoa kohdealueella? Tehdäänkö tuoterungon kehittely vähitellen vai yhdellä kertaa? Muunnetaan olemassa olevia komponentteja yleisemmiksi Korvataan olemassa olevat komponentit tuotealustalla Kehitetään uusi tuotealusta asteittain kasvavalle tuoteperheelle (ei olemassa olevaa ohjelmistoa) Kehitetään uusi tuotealusta heti koko suunnitellulle tuoteperheelle (ei olemassa olevaa ohjelmistoa) Ohjelmistoarkkitehtuurit

29 Tuoterunkoprosessi sisältyy Sovellusalueen käsitemalli Vaatimusmäärittely Muunneltavuusvaatimukset, piirremalli Yhteiset vaatimukset Alustan suunnittelu Alustakehitysprosessi Tuoterunkoarkkitehtuuri Tuoterunkorajapinta Arviointi Alustan toteutus Alusta Variaationhallinta Vaatimusmäärittely Tuotevaatimukset Tuoteen toteutus Tuotekohtainen koodi Tuotekehitysprosessi Ohjelmistoarkkitehtuurit

30 Yhteenvetoa Ohjelmistoarkkitehtuurit

31 lisäluettavaa Tulossa: mallipohjaisten menetelmien yhteydessä tuoterunkopuolta kyseisten menetelmien kanssa Tuoterukopuolta: Feature-oriented software product lines: Feature-oriented software development, määrittelyä: l Ohjelmistoarkkitehtuurit

32 Kysyttävää?

33 Vaatimukset ja suunnittelupäätökset Viime kädessä hankintasopimus määrittelee vaatimukset, kaikki sen jälkeen tulevat päätökset ovat suunnittelua Tuoterungon tapauksessa ei yleensä ole hankintasopimusta, vaan tuoterunko tehdään yrityksen sisäiseen käyttöön (erityisesti) tuoterungon tapauksessa ei selvää eroa vaatimusten ja suunnittelun välillä: myös vaatimukset suunnitellaan Ohjelmistoarkkitehtuurit

34 Tuoterunko-organisaatio Tuoterungon mahdollisuudet Tuoterungon mahdollisuudet Sovellusalueen ymmärrys Arkkitehtuuriosaaminen Abstrahointikyky Teknologiatuntemus Kommunikaatiokyvyt Markkinointi Asiakkaan tarpeet Tuoterungon ymmärtäminen, sitoutuminen, puolustaminen ( Champion ) Johto Vaatimukset Tuotteen ominaisuudet Asiakas Tuotteen ymmärrys Asiakkaan tarpeiden ymmärrys Komponenttipohjainen kehitys Räätälöintikyky Toteutustekniikoiden tuntemus Tuoterunko ryhmä Komponentit Päivitykset Vaatimukset Mahdollisuudet Tuoteryhmät Tuotteet Palaute Ohjelmistoarkkitehtuurit

35 Tuoterunkoja tukevia teknologioita Komponenttiteknologiat Olioteknologiat, kehykset Mallipohjaiset menetelmät DSL, sovellusaluesuuntautuneet mallit Parametrisointi, tulkattavat osat Tekstuaalisten ja visuaalisten kielten rakentamisympäristöt Ohjelmistoarkkitehtuurit

36 Kysyttävää?

37 Sovellus Sovellus Sovellus Sovellus Sovellus Sovellus Sovellus Sovellus Kerrostyyli tuoterunkoarkkitehtuureille Sovellusalusta Arkkitehtuurialusta Resurssialusta Ohjelmistoarkkitehtuurit

38 Kerrostyyliin perustuvan tuoterungon suunnittelu 1. Päätä yleiset tukipalvelut ja suunnittele niiden abstrahointi 2. Päätä perusarkkitehtuurityyli ja suunnittele sen tarvitsema infrastruktuuri (esim. viestinvälitys, asiakas-palvelin) 3. Suunnittele tuoteperheen yhteiset komponentit ja variaatiopisteiden toteutus 4. Huom: joku kerroksista voi myös puuttua tai olla hyvin ohut Ohjelmistoarkkitehtuurit

39 Kerrosarkkitehtuuri auttaa hallitsemaan tuoterunkoa Mihin osiin vaikuttavat tietokantamuutokset? Miten varmistutaan, että ei muuteta tuoterungon perusarkkitehtuuria? Miten varmistutaan, että ei tuoda yksittäiseen tuotteeseen liittyviä asioita perusarkkitehtuuriin? Miten varmistutaan, että ei sotketa tuotekohtaisia asioita sovellusaluekohtaisiin asioihin? Mitkä osat vaikuttavat eniten laatuominaisuuksiin? Mitä osia on (todennäköisesti) muutettava, jos laatuvaatimukset muuttuvat? Ohjelmistoarkkitehtuurit

40 Kysyttävää?