7. Tuoterunkoarkkitehtuurit

Transkriptio

1 7. Tuoterunkoarkkitehtuurit Johdanto Näkökulmat tuoterunkoihin perustuvaan ohjelmistokehitykseen Kerrostyyli tuoterunkoarkkitehtuureille Tuoterunkojen etuja ja ongelmia 1

2 Uudelleenkäytt 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, kehykset) alhaalta-ylös tapa ei toimi hyvin käytännössä 2

3 Tuoterunko = systemaattinen suunniteltu ohjelmistojen uudelleenkäytt yttö Tuoterunkoarkkitehtuurit (Product-line Architectures): 3

4 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 4

5 Tuoterunkoihin pohjautuvan ohjelmistokehityksen näkökulmatn 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 käytetään? Miten tuetaan haluttua variaatiota? 5

6 Kumulatiivinen kustannus Liiketoimintanäkökulma kulma 4C 3C takaisinmaksu perinteinen tuoterunko 2C 1C I Sovellusten lukumäärä 6

7 Liiketoimintanäkökulma kulma Perustuu työmääräarviomenetelmiin 7

8 Organisaation kypsyys independent products standardized infrastructure yhteinen OS, DB, GUI etc. platform + yhteinen domaintoiminnallisuus product population software product line program of product lines + TRA, osittain yhteinen domain-toiminnallisuus, variaatiopisteet + automaattinen tuki tuotteen rakentamiselle configurable product base Jan Bosch 8

9 Hierarkkinen tuoterunko Jan Bosch 9

10 Organisaation vs. sovellusalueen kypsyys sovellusalueen kypsyys (stabiilisuus) PL = software product line CPB = configurable product base IP = independent products SI = standardized infrastructure Jan Bosch high low PL IP low CPB SI high organisaation kypsyys 10

11 Organisaation vs. arkkitehtuurin roolin kypsyys Arkkitehtuuri selittää järjestelmää Arkkitehtuuri ohjaa järjestelmän rakentamista Arkkitehtuuri mahdollistaa erilaisten järjestelmien rakentamisen organisaation kypsyys 11

12 Eri tapoja lähtel hteä tuorunkopohjaiseen ohjelmistokehitykseen Muunnetaan olemassaolevia komponentteja yleisemmiksi Korvataan olemassaolevat komponentit tuotealustalla Kehitetään uusi tuotealusta asteittain kasvavalle tuoteperheelle Kehitetään uusi tuotealusta heti suunnitellulle tuoteperheelle 12

13 Tuoterunko-organisaatio organisaatio Tuoterungon mahdollisuudet Tuoterungon mahdollisuudet Sovellusalueen ymmärrys Arkkitehtuuriosaaminen Abstrahointikyky Teknologiatuntemus Kommunikaatiokyvyt Markkinointi Asiakkaan tarpeet Johto Vaatimukset Tuotteen ominaisuudet Customer 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 13

14 Toteutettavuus kartoitus Sovellusalueen käsitemalli, piirremalli Yhteiset vaatimukset Tuoterunkoprosessi Alustan suunnittelu Vaatimusmäärittely Muunneltavuusvaatimukset Tuoterunkoarkkitehtuuri Tuoterunkorajapinta Alustakehitysprosessi Arviointi Alustan toteutus Alusta Variaationhallinta Tuote Vaatimusmäärittely Tuotevaatimukset Tuoteen toteutus Tuotekohtainen koodi Tuotekehitysprosessi 14

15 Milloin tuoterunkoihin pohjautuva ohjelmistokehitys on mahdollista? Keskeiset tavoitteet: uudelleenkäyttö, lyhyempi kehitysaika, parempi laatu vähemmillä resursseilla, 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 (myös variaation laajuus ja sitomisaika) Joskus (osittain) tuntemattomat vaatimukset johtavat tuoterunkoon Avoin lähdekoodi on usein tulkittavissa tuoterunkona 15

16 Tuoterunkoja tukevia teknologioita Komponenttiteknologiat Olioteknologiat (erikoistamismekanismit) Mallintamisteknologiat, UML Sovellussuuntautuneet kielet, XML Tekstuaalisten ja visuaalisten kielten rakentamisympäristöt Kehykset 16

17 Tuoterunkoarkkitehtuurit vs. DSL Perinteinen Vaatimukset Kääntäjä Ajettava sovellus Koodi 17

18 Tuoterunkoarkkitehtuurit vs. DSL Vaatimukset Kääntäjä Ajettava sovellus Perinteinen DSL = Domain- Specific Language Koodi DSL DSL koodi DSL kehitin Koodi 18

19 Tuoterunkoarkkitehtuurit vs. DSL Vaatimukset Yhteinen arkkitehtuuri ja Kääntäjä Ajettava sovellusalueen tuki sovellus Perinteinen DSL = Domain- Specific Language Koodi DSL DSL koodi DSL kehitin Koodi Tuorerunko Koodi Alusta alustan rajapinta 19

20 Tuoterunkoarkkitehtuurit vs. DSL Vaatimukset Yhteinen arkkitehtuuri ja Kääntäjä Ajettava sovellusalueen tuki sovellus Perinteinen DSL = Domain- Specific Language Koodi DSL DSL koodi DSL kehitin Koodi Tuorerunko Koodi Alusta alustan rajapinta 20

21 Kerrostyyli tuoterunkoarkkitehtuureille Tuote Tuote Tuote Tuote Tuote Tuote Tuote Tuote Sovellusalusta Sovellusalusta Sovellusalusta Sovellusalusta Arkkitehtuurialusta Arkkitehtuurialusta Resurssialusta 21

22 Esimerkki: EJB-pohjainen tuoterunko Tuote Talletustilien hallintajärjestelmä Pankkisovelluskehys EJB Sovellusalusta Arkkitehtuurialusta Resurssialusta Tietokantapalvelut, hajautuspalvelut 22

23 Harjoitus Anna älykotijärjestelmän kerrosarkkitehtuuri tuoterunkojen nelikerrosarkkitehtuurimallin mukaisesti. 23

24 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 Suunnittele tuotekohtaisten vaatimusten toteutus 24

25 Tuoteryhmät t kerrosarkkitehtuurin mukaan Tuotekulttuuri Tuoteheimo Jan Bosch: tuotepopulaatio Tuoteperhe Tuote Sovellusalusta Arkkitehtuurialusta Resurssialusta 25

26 Kerrosarkkitehtuuri auttaa hallitsemaan tuoterunkoa Mihin osiin vaikuttavat tietokantamuutokset? Miten varmistutaan, että ei muuteta tuoterungon perusarkkitehtuuria? Miten varmistutaan, että ei tuoda tuotteeseen tai sovellusalueeseen 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? 26

27 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 27

28 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 Lisääntynyt kommunikoinnin ja koordinoinnin tarve Testaus: miten testataan tuoterunko? Tuoterungon fokuksen katoaminen Kvartaaliekonomia 28