Johdanto Näkökulmat tuoterunkoihin perustuvaan ohjelmistokehitykseen: liiketoiminta, organisaatio, prosessi, tekninen Tuoterunkojen etuja ja ongelmia

Transkriptio

1 12. Tuoterunkoarkkitehtuurit Johdanto Näkökulmat tuoterunkoihin perustuvaan ohjelmistokehitykseen: liiketoiminta, organisaatio, prosessi, tekninen Tuoterunkojen etuja ja ongelmia Ohjelmistoarkkitehtuurit Syksy 2009 TTY Ohjelmistotekniikka 1

2 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ä 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 ei toimi hyvin käytännössä Ohjelmistoarkkitehtuurit Syksy 2009 TTY Ohjelmistotekniikka 2

3 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 Syksy 2009 TTY Ohjelmistotekniikka 3

4 Tuoterunko = yhteiseen arkkitehtuuriin ja alustaan perustuva ohjelmistojen uudelleenkäyttö - suunniteltu - ylhäältä-alas Tuoterunkoarkkitehtuurit (Product-line Architectures): Ohjelmistoarkkitehtuurit Syksy 2009 TTY Ohjelmistotekniikka 4

5 Tuoterunkoihin pohjautuva ohjelmistokehitys Keskeiset tavoitteet: merkittävä uudelleenkäyttö, lyhyempi kehitysaika, parempi laatu vähemmillä resursseilla, yhdenmukainen ja rationalisoitu kehitysprosessi Edellytys: oletetaan tuoteperhe, jolla on riittävästi yhteisiä ominaisuuksia ja hyvin ymmärretty variaatio Vaatimusten on määriteltävä soveltamisala (esim. domain-malli, piirremalli), yhteiset vaatimukset ja variaatiopisteet Joskus (osittain) tuntemattomat vaatimukset johtavat variaatiopisteisiin Avoin lähdekoodi on usein tulkittavissa tuoterunkona Tuoterunkoihin usein viitataan räätälöitävyytenä Missä vaiheessa ohjelmistoalusta voidaan tulkita tuoterunkona? Ohjelmistoarkkitehtuurit Syksy 2009 TTY Ohjelmistotekniikka 5

6 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 Syksy 2009 TTY Ohjelmistotekniikka 6

7 Liiketoimintanäkökulma 4C 3C takaisinmaksu perinteinen tuoterunko 2C 1C alustan rakentaminen Sovellusten lukumäärä Ohjelmistoarkkitehtuurit Syksy 2009 TTY Ohjelmistotekniikka 7

8 Liiketoimintanäkökulma Perustuu työmääräarviomenetelmiin Ohjelmistoarkkitehtuurit Syksy 2009 TTY Ohjelmistotekniikka 8

9 Esimerkki ( oikea ) Sovellusalue: videopelit Perinteinen 1. peli 2. peli 3. peli työtuntia Kehykseen perustuva Kehyksen rakentaminen + koulutus Suorituskyky: aika +70% tila +200% Ohjelmistoarkkitehtuurit Syksy 2009 TTY Ohjelmistotekniikka 9

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

11 Hierarkkinen tuoterunko Jan Bosch Ohjelmistoarkkitehtuurit Syksy 2009 TTY Ohjelmistotekniikka 11

12 Organisaation kypsyys suhteessa arkkitehtuuriin Arkkitehtuuri selittää järjestelmää Arkkitehtuuri ohjaa järjestelmän rakentamista Arkkitehtuuri mahdollistaa erilaisten järjestelmien rakentamisen organisaation kypsyys Ohjelmistoarkkitehtuurit Syksy 2009 TTY Ohjelmistotekniikka 12

13 Eri tapoja lähteä tuoterunkopohjaiseen ohjelmistokehitykseen Muunnetaan olemassaolevia komponentteja yleisemmiksi Korvataan olemassaolevat komponentit tuotealustalla Kehitetään uusi tuotealusta asteittain kasvavalle tuoteperheelle (ei olemassaolevaa ohjelmistoa) Kehitetään uusi tuotealusta heti koko suunnitellulle tuoteperheelle (ei olemassaolevaa ohjelmistoa) Ohjelmistoarkkitehtuurit Syksy 2009 TTY Ohjelmistotekniikka 13

14 Tuoterunkoprosessi Sovellusalueen käsitemalli, piirremalli Yhteiset vaatimukset Alustan suunnittelu Vaatimusmäärittely Muunneltavuusvaatimukset Tuoterunkoarkkitehtuuri Tuoterunkorajapinta Alustakehitysprosessi Arviointi Alustan toteutus Alusta Variaationhallinta Vaatimusmäärittely Tuotevaatimukset Tuoteen toteutus Tuotekohtainen koodi Tuotekehitysprosessi Ohjelmistoarkkitehtuurit Syksy 2009 TTY Ohjelmistotekniikka 14

15 Tuoterunko-organisaatioorganisaatio 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 Syksy 2009 TTY Ohjelmistotekniikka 15

16 Tuoterunkoja tukevia teknologioita Komponenttiteknologiat Olioteknologiat Mallintamisteknologiat, UML Sovellussuuntautuneet kielet, XML Tekstuaalisten ja visuaalisten kielten rakentamisympäristöt Kehykset Ohjelmistoarkkitehtuurit Syksy 2009 TTY Ohjelmistotekniikka 16

17 Tuoterunkoarkkitehtuurit vs. DSL Vaatimukset Kääntäjä Ajettava sovellus Koodi Ohjelmistoarkkitehtuurit Syksy 2009 TTY Ohjelmistotekniikka 17

18 Tuoterunkoarkkitehtuurit vs. DSL Vaatimukset Kääntäjä Ajettava sovellus DSL = Domain- Specific Language DSL koodi DSL kehitin Koodi Koodi Ohjelmistoarkkitehtuurit Syksy 2009 TTY Ohjelmistotekniikka 18

19 Tuoterunkoarkkitehtuurit vs. DSL Vaatimukset Yhteinen arkkitehtuuri ja Kääntäjä Ajettava sovellusalueen tuki sovellus DSL = Domain- Specific Language DSL koodi DSL kehitin Koodi Koodi Koodi Alusta tuoterunkorajapinta Ohjelmistoarkkitehtuurit Syksy 2009 TTY Ohjelmistotekniikka 19

20 Tuoterunkoarkkitehtuurit vs. DSL Vaatimukset Yhteinen arkkitehtuuri ja Kääntäjä Ajettava sovellusalueen tuki sovellus DSL = Domain- Specific Language DSL koodi DSL kehitin Koodi Koodi Koodi Alusta tuoterunkorajapinta Ohjelmistoarkkitehtuurit Syksy 2009 TTY Ohjelmistotekniikka 20

21 Kerrostyyli tuoterunkoarkkitehtuureille Sovellus Sovellus Sovellus Sovellus Sovellus Sovellus Sovellus Sovellus Sovellusalusta Arkkitehtuurialusta Resurssialusta Ohjelmistoarkkitehtuurit Syksy 2009 TTY Ohjelmistotekniikka 21

22 Esimerkki: EJB-pohjainen tuoterunko Tuote Talletustilien hallintajärjestelmä Sovellusalusta Arkkitehtuurialusta Resurssialusta Pankkisovellustuki EJB: hajautettu asiakas-palvelintuki Tietokantapalvelut, tietoliikennepalvelut, KJ vrt. yleinen liiketoimintajärjestelmien kerrosarkkitehtuuri Ohjelmistoarkkitehtuurit Syksy 2009 TTY Ohjelmistotekniikka 22

23 Harjoitus Oletetaan, että aikaisemmin esimerkkinä ollut auton monitorointijärjestelmä halutaan muuntaa tuoterungoksi, jonka avulla voidaan luoda monitorointijärjestelmiä erilaisille ajoneuvoille. Anna tällaiselle tuoterungolle kerrosarkkitehtuuri nelikerrosarkkitehtuurimallin mukaisesti. Ohjelmistoarkkitehtuurit Syksy 2009 TTY Ohjelmistotekniikka 23

24 CANBus CANFilter MessageDispatcherIF XMLMsg Message Dispatcher Msg type(): MsgType Component receive(msg) send(msg) register(msgtype,component) BrakeViewIF update() Brake- View BrakeModelIF BrakeController handleevent(event) BrakeState recordusage checkcondition register(view) getstate() setstate() GSMComp sendreport DBAccess Ohjelmistoarkkitehtuurit Syksy 2009 TTY Ohjelmistotekniikka 24

25 Harjoitus Sovellus Sovellusalusta Arkkitehtuurialusta Resurssialusta Ohjelmistoarkkitehtuurit Syksy 2009 TTY Ohjelmistotekniikka 25

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

27 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 Syksy 2009 TTY Ohjelmistotekniikka 27

28 Esimerkkejä tuoterungoista Kännykkäalustat (esim. S40, S60) Vakuutusjärjestelmäalustat Pankkijärjestelmäalustat Tietokone- ja kännykkäpelialustat Koneenohjausjärjestelmäalustat Ohjelmistoarkkitehtuurit Syksy 2009 TTY Ohjelmistotekniikka 28

29 Tuoterunkojen etuja ja ongelmia Etuja: Pitkälle viety koodin, osaamisen uudelleenkäyttö Nopeutunut tuotesykli Tuottavuuden kasvu pitkällä tähtäyksellä Tuotteiden standardointi Kehitysprosessien ja työkalujen standardointi Laadun paraneminen Tukee nopeaa protoilua Ohjelmistoarkkitehtuurit Syksy 2009 TTY Ohjelmistotekniikka 29

30 Potentiaalisia ongelmia Henkilökunnan vaihtuvuus: motivointi, asiantuntemus, gurukeskeisyys 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 Syksy 2009 TTY Ohjelmistotekniikka 30