Kevät 2016 Arkkitehtuurin arviointi, ATAM. Ohjelmistoarkkitehtuurit 2016

Koko: px
Aloita esitys sivulta:

Download "Kevät 2016 Arkkitehtuurin arviointi, ATAM. Ohjelmistoarkkitehtuurit 2016"

Transkriptio

1 Ohjelmistoarkkitehtuurit Kevät 2016 Arkkitehtuurin arviointi, ATAM 1

2 Ohjelmistoarkkitehtuurien arviointi Johdanto ATAM-menetelmä Esimerkki Käytännön kokemuksia ja ongelmia Yhteenveto 2

3 Arkkitehtuurin rakentaminen kehitysprosessissa Laatuvaatimukset Arkkitehtuurin kannalta merkittävät vaatimukset Vaatimusanalyysi Keskeiset toiminnalliset vaatimukset Ympäristövaatimukset Alustava arkkitehtuurisuunnittelu Alustava arkkitehtuuri Laatuvaatimuksen huomiointi Rajoitteet Yleisten ratkaisumallien soveltaminen Arkkitehtuurimuunnos ei OK OK Toissijaiset toiminnalliset vaatimukset Kaikki käsitelty Yksityiskohtainen suunnittelu Arkkitehtuurin arviointi Arkkitehtuuri 3

4 Arkkitehtuuri ja laatuvaatimukset Tässä laadulla ei viitata virheettömyyteen vaan siihen millä laadulla järjestelmä tekee loogiset toimintonsa Arkkitehtuuri määrää miten (useimmat) laatuvaatimukset toteutuvat. Hiukan kärjistäen: Ohjelmistoarkkitehtuuri on tapa toteuttaa ohjelmiston laatuvaatimukset Arkkitehtuurin kuvauksen täytyy sisältää kaikki se informaatio, joka tarvitaan päättelemään laatuvaatimustentoteutuminen tai toteutumattomuus Arkkitehtuuria arvioidaan (yleensä) vasten laatuvaatimuksia 4

5 Ohjelmistojen laatuominaisuudet Ajoaikaiset laatuominaisuudet Suorituskyky Tilankäyttö Luotettavuus Saatavuus Tietoturvallisuus Käytettävyys Kehitys- ja evoluutioaikaiset laatuominaisuudet: Muunneltavuus Siirrettävyys Ylläpidettävyys Uudelleenkäytettävyys Laatustandardit: esim. ISO

6 6

7 ISO 9126 laatukehikko 7

8 Pariintumistyöskentelyä Mitä tarkennuksia laatuominaisuuksille? Ylläpidettävyys Käytettävyys Luotettavuus Toiminnallisuus Tehokkuus Siirrettävyys Laajennettavuus 8

9 Tarkennetut laatuominaisuudet Efficiency Time performance Resource utilization Response time Memory usage Scalability Throughput Maintainability Analyzability Changeability Stability Testability Variability Subsetability Conceptual integrity Traceability Portability Adaptability Installability Co-existence Replaceability Functionality Suitability Accuracy Interoperability Security Data security Access security Safety Reliability Maturity Fault tolerance Recoverability Availability Predictability Usability Understandability Learnability Operability Attractiveness Itse ryhmittelyllä ei käytännössä suurta merkitystä arvioinnissa. Luettelo hyvä pohja arviointikohteiden valintaan. 9

10 Arkkitehtuuri ja liiketoimintatavoitteet 10

11 Arvioinnin tulokset Ohjelmistoarkkitehtuurin arviointi vastaa tyypillisesti seuraaviin kysymyksiin: 1) Täyttääkö suunniteltu arkkitehtuuri olennaiset laatuvaatimukset? Jos täyttää, miksi? Jos ei täytä, miksi? 2) Mikä vaihtoehtoisista arkkitehtuuriratkaisuista sopii parhaiten järjestelmälle? Miksi? 3) Kuinka hyvin tietty laatuvaatimus voidaan saavuttaa suunnitellulla arkkitehtuurilla? 11

12 Varauksia Arviointi pohjautuu arkkitehtuurin kuvaukseen, saatavilla olevaan informaatioon ja osallistujien aktiivisuuteen Arvioinnin tulosten tarkkuus riippuu lähtötietojen tarkkuudesta Arvioinnissa täytyy olettaa järkevä toteutus, arkkitehtuurin täytyy mahdollistaa järkevä toteutus 12

13 Kysyttävää?

14 Ohjelmistoarkkitehtuurien arvioinnin ongelma Laatuvaatimukset? Ohjelmistoarkkitehtuuri 14

15 Laatuvaatimukset tulevat sidosryhmiltä Hyvä suorituskyky, luotettava, hyvä käytettävyys Helposti ylläpidettävä, siirrettävä Loppukäyttäjä Ylläpitäjä 15

16 Laatuominaisuuksien arviointi Laatuominaisuuksille ei ole selviä täyttymiskriteerejä Esim. ylläpidettävyys: järjestelmän on oltava helppo muuttaa kun sen käyttöympäristö muuttuu Miten arvioida jotain ominaisuutta, jolla on suuri (ääretön) määrä erilaisia tilanteita, joissa ominaisuuden olemassaolo on potentiaalisesti uhattuna Vrt. oikeellisuus testaus Yleinen menetelmä: määrää tavoitteet järjestelmälle, johda niistä halutut laatuominaisuudet tarkenna laatuominaisuudet anna kullekin tarkennetulle laatuominaisuudelle esimerkkitilanne tutki täyttyykö ko. laatuominaisuus tässä esimerkkitilanteessa 16

17 Laatuvaatimusten täsmentäminen skenaarioilla Skenaario = tilanne tai tapahtumasarja, joka tuo esille jonkin laatuvaatimuksen täyttymisen (jonkin järjestelmän osan kannalta) Skenaario konkretisoi laatuvaatimuksen esimerkillä Skenaarion on oltava riittävän täsmällinen, jotta arkkitehtuuria voidaan arvioida sitä vasten usein tarkkoja lukuarvoja Vrt. perinteinen käyttötapaus toiminnallinen vaatimus Skenaario = arkkitehtuurin testitapaus 17

18 Ohjelmistoarkkitehtuurien arvioinnin ongelman ratkaisu: skenaariopohjainen arviointi Laatuvaatimukset? Ohjelmistoarkkitehtuuri Vaatimusten tarkennus Skenaariot Analyysi Arkkitehtuuriratkaisut Ratkaisujen identifiointi 18

19 Tiedon louhinta arkkitehtuurista Asiantuntijoiden näkemykset esim. pääarkkitehti, muita vastaavia järjestelmiä suunnitelleet arkkitehdit ym. Takaisinmallinnus koodia voidaan abstrahoida takaisinmallinnustyökaluilla, ei tuota varsinaista arkkitehtuurikuvausta vaan analysoi erilaisia riippuvuuksia Simulointi jos on olemassa ajettava malli, voidaan tutkia arkkitehtuurista johtuvaa suorituskykyä, luotettavuutta; edellyttää järjestelmän mallintamista ja hyvää työkalua Metriikat voidaan käyttää karkeana työkaluna epäilyttävien kohtien löytämiseen (toimii lähinnä ylläpidettävyydelle), edellyttää hyviä työkaluja esim. suuret luokat, paljon riippuvuuksia komponenttien välillä 19

20 Vaihtoehtoinen tapa: tarkistuslistapohjainen arviointi Laatuvaatimukset? Ohjelmistoarkkitehtuuri Yleinen tarkistuslista Järjestelmätyyppi Sovitettu tarkistuslista Analyysi yleiset/järjestelmätyyppikohtaiset tarkistuslistat: esim.: onko käyttöliittymäosat erotettu selvästi sovelluslogiikasta? onko kerrosten välillä selvät rajapinnat? onko tietokanta abstrahoitu yleisen rajapinnan taakse? 20

21 Analysointityökalujen hyödyntäminen Olemassa olevan järjestelmän arkkitehtuuriarvioinnissa voidaan käyttää erilaisia työkaluja (esim. metriikkatyökalut, sääntöjen tarkistustyökalut, visualisointityökalut, riippuvuusanalysaattorit, koodin kopioinnin tarkistajat, takaisinmallinnustyökalut) Erityisen hyödyllistä ylläpidettävyyden ja muunneltavuuden analysoinnissa Monet työkalut toimivat koodin perusteella -> ei välttämättä arkkitehtuuritason informaatiota Voidaan hyödyntää skenaariopohjaisessa arvioinnissa esim. hakemalla ja priorisoimalla skenaarioita, jotka kohdistuvat epäilyttäviin osiin järjestelmässä 21

22 22

23 23

24 Koodin kopiointi, Visual Studio (koodin analysointi työkalut) 24

25 25

26 ConQAT architecture conformance analysis 26

27 Kysyttävää?

28 Skenaariopohjaiset arviointimenetelmät SAAM (Software Architecture Analysis Method) keskittyy erityisesti muunneltavuuteen, siirrettävyyteen, ylläpidettävyyteen kehitetty SEI:ssä (Software Engineering Institute, Carnegie-Mellon University) perustuu evoluutioaikaisiin skenaarioihin ATAM (Architecture Tradeoff Analysis Method) soveltuu kaikille laatuominaisuuksille kehitetty SEI:ssä johdettu SAAM:ista MPM (Maintenance Prediction Method) keskittyy ylläpidettävyyteen pyrkii löytämään suht. tarkat kustannusarviot ylläpidolle Jan Bosch:in kehittämä perustuu ylläpitoskenaarioihin 28

29 ATAM tietovuo 29

30 ATAMin peruskäsitteet Skenaario: arkkitehtuurin testitapaus Laatupuu: kohdejärjestelmän laatuvaatimusten tarkennus asteittain skenaarioiksi (utility tree) Herkkyyskohta: muutokset tämän arkkitehtuuripäätöksen suhteen voivat aiheuttaa merkittäviä muutoksia johonkin laatuominaisuuteen (sensitivity point) Tasapainokohta: arkkitehtuuripäätös joka vaikuttaa useampaan laatuominaisuuteen vastakkaisiin suuntiin (tradeoff) Riski: arkkitehtuuripäätös joka saattaa aiheuttaa ongelmia tulevaisuudessa laatuattribuutin näkökulmasta (risk) Ei-riski: arkkitehtuuripäätös joka voi edesauttaa laatuominaisuuden toteutumisessa (non-risk) 30

31 ATAMin vaiheet (2 päiväinen) 0. Ennakkovalmistelu 1. ATAMin esittely 2. Liiketoiminnan asettamat vaatimukset tuotteelle 3. Arkkitehtuuriesittely 4. Arkkitehtuurilähestymistapojen tunnistaminen 5. Laatupuun ja skenaarioiden laadinta 6. Arkkitehtuurilähestymistapojen analysointi 7. Skenaarioaivoriihi ja priorisointi 8. Arkkitehtuurilähestymistapojen analysointi 9. Tulosten esittäminen 1. päivä 2. päivä 31

32 Osallistujat Sidosryhmät: Arkkitehti Ylläpitäjä Testaaja Standardiasiantuntija Turvallisuusvastaava Projektipäällikkö Tuotepäällikkö Asiakas Loppukäyttäjä Oheispalveluvastaava Sovellusalueen asiantuntija Laiteasiantuntija Huolto Markkinointi Ohjelmistokehittäjä 1. päivä 3-5 hlöä. Arkkitehti ja muista kiinteästi suunnittelussa tai toteutuksessa mukana olleita Arviointiryhmä 2. päivä 5-10 hlöä. Kattavasti kaikkien sidosryhmien edustajia Arviointiryhmä 32

33 ATAM prosessi (Päivä 1) ATAMin esittely ATAMin vaiheet ATAMin tekniikat (skenaariot, laatupuu, jne) Liiketoimintanäkökulma tärkeimmät toiminnallisuudet käyttäjien kannalta liiketoimintatavoitteet taloudelliset, poliittiset yms. rajoitteet Arkkitehtuuriesittely tekniset rajoitteet (kj, ohjelmistoalustat, laitteisto jne.) järjestelmän ulkoiset rajapinnat arkkitehtuurin kuvaus 33

34 ATAM prosessi (Päivä 1 jatkuu) Arkkitehtuuriratkaisujen tunnistaminen tunnistetaan ja nimetään käytetyt tyylit, suunnittelumallit ja omat ratkaisut selitetään miten ratkaisuilla oletetaan saavutettavan tietyt laatuvaatimukset Laatupuun ja skenaarioiden laatiminen tarkennetaan laatuvaatimukset järjestelmäkohtaisella ryhmittelyllä konkretisoidaan kukin tarkennettu laatuvaatimus skenaariolla priorisoidaan skenaariot tärkeyden ja vaikeuden perusteella Arkkitehtuuriratkaisujen analysointi keskitytään tärkeimpiin skenaarioihin kysytään: tekeekö tämä arkkitehtuuri mahdolliseksi skenaarion, miksi? arkkitehtuuri on syyllinen kunnes toisin todistetaan pyritään tunnistamaan riskit, turvalliset ratkaisut, herkkyyskohdat ja tasapainokohdat 34

35 Täydennys (Päivä 2) Skenaarioaivoriihi kaikki osapuolet esittävät skenaarioita omilta näkökulmiltaan uudet skenaariot priorisoidaan ja liitetään laatupuuhun vanhat skenaariot vahvistetaan Uusinta-analyysi tärkeimmät skenaariot tarkistetaan vasten arkkitehtuuria mahdolliset uudet riskit tunnistetaan 35

36 Skenaariot ja skenaariolajit Skenaario konkretisoi laatuvaatimuksen esimerkillä. Tapahtuma tai tapahtumasarja, joka liittyy johonkin laatuvaatimukseen. Skenaario on täsmällinen (vrt. testitapaus, use case) Skenaarion rakenne: Ärsyke - Ympäristö Vaste Käyttötapausskenaario: käyttäjän interaktio järjestelmän kanssa Etäkäyttäjä hakee tietokantaraportin web-käyttöliittymästä suurimman kuormahuipun aikana ja saa sen 5s kuluessa. Kasvuskenaario: ennakoituja muutoksia Järjestelmään lisätään uusi datapalvelin latenssin vähentämiseksi 2,5s, työ tehdään 1 henkilötyöviikossa. Tutkiva skenaario: odottamattomia muutoksia, kuormituksia jne. Puolet palvelimista kaatuu normaalissa käyttötilanteessa, tämä ei vaikuta järjestelmän saavutettavuuteen. Oletusympäristö: Normaali käyttötilanne 36

37 Skenaario esimerkki 37

38 Analysoitu skenaarioi (arviointiraportissa) Tyypillisesti korkealle priorisoitua skenaariota Skenaarioon liittyvät arkkitehtuuriratkaisut tunnistetaan ja luokitellaan (esim. T = tasapainokohta, R = riski, N = eiriski) Arkkitehdin selvitys skenaarion hoitumisesta kirjataan (Description) Kunkin ratkaisun liittyminen skenaarioon selitetään (Argumentation) 38

39 Esimerkki: laatupuu laatuominaisuudet Suorituskyky tarkennukset Transaktioiden käsittely Vasteaika skenaariot Käsittelee 1000 palvelupyyntöä/sek ilman viivettä käyttäjille. (H,M) Käyttäjävarmistus < 1 sek. (H,M) GUI Web-pohjaiseksi 1 kk:ssa (M,H) Laatu Muunneltavuus Saatavuus GUI muutokset Tietokantamuutokset Laitteistoviat Tietokanta vaihdetaan Oracleksi 6 kk:ssa (L,H) Palvelimen kovalevyn hajoamisen jälkeen uusintakäynnistys 5 min:ssa (L,H) Tietoturvallisuus Palvelimen kaatuminen Korttien käyttö Uudelleenkäynnistys autentikaatiopalvelimen kaatuessa 5 min:ssa (M,M) Luottokortin tiedot turvassa % (H,L) 39

40 Skenaarion priorisointi Tavallisesti kaksiosainen prioriteetti: kuinka tärkeä (tuotepäällikkö, projektipäällikkö) kuinka vaikea toteuttaa (arkkitehti) Kolme arvoa: H (high), M (medium), L (low) Voidaan tehdä myös äänestämällä 40

41 Tehtävä: Anna muunneltavuuteen liittyvä skenaario Fitgigabytelle. Anna laajennettavuuteen liittyvä skenaario Fitgigabytelle. Anna saavutettavuuteen tai suorituskykyyn liittyvä skenaario Fitgigabytelle. 41

42 Herkkyyskohta Herkkyyskohta = arkkitehtuuriratkaisu, joka on kriittinen jonkin laatuominaisuuden saavuttamisen kannalta. Esimerkki: MVC-tyylin käyttö GUI arkkitehtuurissa on olennaista järjestelmän siirrettävyyden kannalta. 42

43 Tasapainokohta Tasapainokohta = herkkyyskohta, joka koskee useaa laatuominaisuutta (yleensä vastakkaisiin suuntiin) Esimerkki: XML:n käyttö tietoformaattina parantaa järjestelmän integroitavuutta mutta heikentää sen suorituskykyä. 43

44 Riski Riski = potentiaalisesti ongelmallinen arkkitehtuuriratkaisu, joka voi heikentää jotain laatuominaisuutta Riski = ratkaisu/fakta + laatuseuraamus + perustelu Esimerkki: Kriteerit ja säännöt keskimmäisen kerroksen komponenttien tekemiselle ovat epäselvät (ratkaisu/fakta). Tästä voi seurata toiminnallisuuden replikointia eri kerroksissa (perustelu), mikä heikentää ylläpidettävyyttä (laatuseuraamus). 44

45 Ei-riski Ei-riski = arkkitehtuuriratkaisu, jolla on tiedossa (lähinnä) vain hyviä laatuseuraamuksia. Ei-riski = oletus + ratkaisu + laatuseuraamus + perustelu Esimerkki: Olettaen, että komponentit eivät joudu tutkimaan toistensa tilaa (oletus), Tarkkailija-suunnittelumallin käyttö komponenttien välisessä kommunikoinnissa (ratkaisu) parantaa muunneltavuutta (laatuseuraamus), koska komponenttien ei tarvitse tietää toisistaan mitään muuta kuin takaisinkutsu- ja rekisteröintirajapinnat (perustelu). 45

46 Raportointi ATAM:in tärkeimmät tulokset: Keskeisten arkkitehtuuriratkaisujen tunnistaminen Olennaisimpien laatuun vaikuttavien käyttö- ja kehitysskenaarioiden tunnistaminen Laatupuu skenaarioineen: kuvaus laatuvaatimusten ja arkkitehtuuriratkaisujen yhteydestä Arkkitehtuuriin liittyvien riskien tunnistaminen 46

47 Raportin rakenne (esimerkiksi) 1. Introduction 2. Target System 2.1 Description of the System 2.2 Most Important Architectural Solutions 3. Analyzed Scenarios 3.1 Maintainability 3.2 Reliability 3.3 Efficiency 3.4 Usability 4. Analysis Overview 4.1 General Observations 4.2 Specific Issues 4.3 About the Process 5. Conclusions References Appendix: Complete Scenario List 47

48 Skenaariot arviointiraportissa (esim.) Tyypillisesti korkealle priorisoitua skenaariota Skenaarioon liittyvät arkkitehtuuriratkaisut tunnistetaan ja luokitellaan (esim. T = tasapainokohta, R = riski, N = eiriski) Arkkitehdin selvitys skenaarion hoitumisesta kirjataan (Description) Kunkin ratkaisun liittyminen skenaarioon selitetään (Argumentation) 48

49 Mitä potentiaalisia ongelmia näet ATAMissa / vastaavissa menetelmissä? 49

50 ATAMista Iso kysymys: ovatko skenaariot oikeasti järkeviä/hyödyllisiä, pystytäänkö valitsemaan olennaisia skenaarioita (ennustaminen)? Löydetyt riskit vs. piiloon jääneet Priorisointi, osataanko valita oikeat skenaariot? Varma hyöty: keino saada ohjelmistoon liittyvät tahot kerrankin yhteen Saadaan hiljaista tietoa dokumentoitua Saadaan jonkinlainen yleiskäsitys järjestelmästä Saadaan julki eri osapuolien huolia ja ongelmia / mahdollisesti resursseja joihinkin kriittisimpiin asioihin puuttumiseen 50

51 Yhteenveto Arkkitehtuuripäätösten löytäminen/dokumentointi Laatuominaisuuksien yhdistäminen arkkitehtuuriratkaisuihin Skenaariopohjaisuus, skenaarioiden käsittely ATAM:

52 Kysyttävää?

53 Arkkitehtuurien arviointi Parhaillaan menossa olevaa tutkimusta, arviointi lite-versio Pyritään yhdistämään ATAMin jadcarin hyviä puolia, mutta tekemään se arvioitavan näkökulmasta mahdollisimman lyhyessä ajassa Teollisuus ja ATAM lähes mahdoton yhtälö, harvalla firmalla mahdollisuus pistää 6-10 kaveria kahdeksi päiväksi arviointeihin Arvioijat (tutkijat jne) tekevät enemmän ennakkotyötä ja esivalmisteluja 53

54 Yleiskuva prosessista esihaastattelu Arkkitehtuurin arviointi Esihaastatteluun valimistautuminen arkkitehtuuriesitys bisnesesittely Analyysi arkkitehtuuripäätöst en tunnistaminen ja Skenaarioiden tekeminen päätösarviointi Skenaarioarviointi Dokumentoidut päätökset Dokumentoidut skenaarioiden arviot 54

55 Esimerkkiaikataulu 9:00 arkkitehtuuriarvioinnin työpaja alkaa 9:00 9:05 Esittely, tavoitteet, menetelmä, aikataulu 9:05 Sessio 1: päätöspohjainen arviointi 9:05 9:20 AM Walk-through of elicited architecture decisions 9:20 9:30 AM Prioritizing decisions 9:30 10:00 AM Documentation of selected decisions 10:00-11:00 AM Analyzing decisions 11:00 11:59 lounas 12:00 Sessio 2: skenaariopohjainen arvionti 12:00 12:05 esittely 12:05 12:20 ennakkoesittelyn perusteella tehtyjen skenaarioiden esittely 12:20 12:35 skenaarioiden valinta 12:40 15:20 skenaarioanalyysi 15:20 16:00 yhteenveto päivästä 55

Ohjelmistoarkkitehtuurit

Ohjelmistoarkkitehtuurit Ohjelmistoarkkitehtuurit Kevät 2012-2013 Johannes Koskinen http://www.cs.tut.fi/~ohar/ 1 Ohjelmistoarkkitehtuurien arviointi Johdanto ATAM-menetelmä Esimerkki Käytännön kokemuksia ja ongelmia Yhteenveto

Lisätiedot

Ohjelmistoarkkitehtuurit kevät

Ohjelmistoarkkitehtuurit kevät Ohjelmistoarkkitehtuurit Kevät 2011-2012 Johannes Koskinen http://www.cs.tut.fi/~ohar/ 9. Ohjelmistoarkkitehtuurien arviointi Johdanto ATAM-menetelmä Esimerkki Käytännön kokemuksia ja ongelmia Yhteenveto

Lisätiedot

Ohjelmistoarkkitehtuurien arviointi

Ohjelmistoarkkitehtuurien arviointi Ohjelmistoarkkitehtuurit Kevät 2012-2013 Johannes Koskinen http://www.cs.tut.fi/~ohar/ 1 Ohjelmistoarkkitehtuurien arviointi Johdanto ATAM-menetelmä Esimerkki Käytännön kokemuksia ja ongelmia Yhteenveto

Lisätiedot

Kevät Ohjelmistoarkkitehtuurit 2014

Kevät Ohjelmistoarkkitehtuurit 2014 Ohjelmistoarkkitehtuurit Kevät 2014 http://www.cs.tut.fi/~ohar/ 1 Ohjelmistoarkkitehtuurien arviointi Johdanto ATAM-menetelmä Esimerkki Käytännön kokemuksia ja ongelmia Yhteenveto 2 Mitä on ohjelmistoarkkitehtuurin

Lisätiedot

9. Ohjelmistoarkkitehtuurien arviointi

9. Ohjelmistoarkkitehtuurien arviointi 9. Ohjelmistoarkkitehtuurien arviointi Johdanto ATAM-menetelmä Esimerkki Käytännön kokemuksia ja ongelmia Yhteenveto Ohjelmistoarkkitehtuurit Syksy 2010 TTY Ohjelmistotekniikka 1 Mitä on ohjelmistoarkkitehtuurin

Lisätiedot

9. Ohjelmistoarkkitehtuurien arviointi

9. Ohjelmistoarkkitehtuurien arviointi 9. Ohjelmistoarkkitehtuurien arviointi Johdanto ATAM menetelmä Esimerkki Yhteenveto 1 Miksi ohjelmistoarkkitehtuuria on arvioitava? Arkkitehtuuri on ensimmäinen täsmällinen kuvaus järjestelmästä Arkkitehtuuri

Lisätiedot

7. Ohjelmistoarkkitehtuurien arviointi

7. Ohjelmistoarkkitehtuurien arviointi 7. Ohjelmistoarkkitehtuurien arviointi Johdanto ATAM-menetelmä Esimerkki Käytännön kokemuksia ja ongelmia Yhteenveto 1 Miksi ohjelmistoarkkitehtuuria on arvioitava? Arkkitehtuuri on ensimmäinen täsmällinen

Lisätiedot

Ohar-ATAM pikaisesti. Ohjelmistoarkkitehtuurit 2009

Ohar-ATAM pikaisesti. Ohjelmistoarkkitehtuurit 2009 Ohar-ATAM pikaisesti Ohjelmistoarkkitehtuurit 2009 Aikataulu Tämä Ohar-ATAM esittely otsikkotasolla(~5min) Arkkitehtuurin esittely (~40min), arvioiva ryhmä esittää kysymyksiä Arkkitehtuurilähestymistavat,

Lisätiedot

Etukäteistehtävää

Etukäteistehtävää ATAM-ohjeistusta Etukäteistehtävää Valmistautukaa huolella, tutustukaa materiaaliin etukäteen. Miettikää kysymyksiä arkkitehtuurista. Valitkaa roolit, arvioijaporukassa kirjuriksi kaveri, joka keskittyy

Lisätiedot

ITK130 Ohjelmistojen luonne

ITK130 Ohjelmistojen luonne ITK130 Ohjelmistojen luonne Luennon sisältö Ohjelmistotekniikka ja vaatimukset Ohjelmistotuote Ei-toiminnallisten vaatimusten luokittelu Sisäiset ja ulkoiset vaatimukset Oikeellisuus Luotettavuus Kestävyys

Lisätiedot

Sytyke ry:n laivaseminaari Software Technology Transfer Pekka Forselius

Sytyke ry:n laivaseminaari Software Technology Transfer Pekka Forselius Sytyke ry:n laivaseminaari 3.-5.9.2002 Testaus ja Laatu Ohjelmiston laadun ja laatuvaatimusten mittaaminen Sytyke ry:n laivaseminaari 3.-5.9.2002 Hyvä laatu? Testaaminen? Ohjelmiston hyvällä laadulla tarkoitamme

Lisätiedot

Ohjelmistoarkkitehtuurit, syksy

Ohjelmistoarkkitehtuurit, syksy Ohjelmistoarkkitehtuurit Luento 10 1 (architectural analysis) Arkkitehtuurin arvioinnin tarkoituksena on muodostaa käsitys kehitettävän ohjelmiston tärkeistä ominaisuuksista Nyt ja tulevaisuudessa Arvioinnin

Lisätiedot

Arkkitehtuurin arviointi

Arkkitehtuurin arviointi Arkkitehtuurin arviointi Luento 7 1 Oppimistavoitteet Arkkitehtuurin arvioinnin tarkoitus Arviointimenetelmät ATAM DCAR ATAM esimerkkinä menetelmistä 2 ARKKITEHTUURIN ARVIOINTI 3 Arkkitehtuurin arviointi

Lisätiedot

Ohjelmistoarkkitehtuurit. Kevät

Ohjelmistoarkkitehtuurit. Kevät Ohjelmistoarkkitehtuurit Kevät 2012-2013 Johannes Koskinen http://www.cs.tut.fi/~ohar/ 1 Esimerkki: Auton toiminnan monitorointijärjestelmä A car control system needs to be extended with a subsystem that

Lisätiedot

Ohjelmistoarkkitehtuurit Kevät Johannes Koskinen Esimerkki: Auton toiminnan monitorointijärjestelmä

Ohjelmistoarkkitehtuurit Kevät Johannes Koskinen   Esimerkki: Auton toiminnan monitorointijärjestelmä Ohjelmistoarkkitehtuurit Kevät 2011-2012 Johannes Koskinen http://www.cs.tut.fi/~ohar/ Esimerkki: Auton toiminnan monitorointijärjestelmä A car control system needs to be extended with a subsystem that

Lisätiedot

Suunnitteluratkaisut ja niiden arviointi sulautetuissa järjestelmissä

Suunnitteluratkaisut ja niiden arviointi sulautetuissa järjestelmissä 1 Suunnitteluratkaisut ja niiden arviointi sulautetuissa järjestelmissä Kai Koskimies Tampereen teknillinen yliopisto Taustaa: Sulake projekti 2008-2009 2 Osallistujat Areva T&D John Deere Kone Sandvik

Lisätiedot

Esimerkki: Auton toiminnan monitorointijärjestelmä

Esimerkki: Auton toiminnan monitorointijärjestelmä Esimerkki: Auton toiminnan monitorointijärjestelmä A car control system needs to be extended with a subsystem that collects various kinds of data during the running of the car, to be used for monitoring

Lisätiedot

Laatukustannukset. Laadun hallinta. Laadun kustannuksista

Laatukustannukset. Laadun hallinta. Laadun kustannuksista Laatukustannukset Laadun hallinta Sami Kollanus TJTA330 Ohjelmistotuotanto 13.2.2007 US National Institute of Standards and Technology: Riittämättömän testauksen kustannusten arvioitiin olevan 59 Mrd dollaria

Lisätiedot

Laadun hallinta. Laatukustannukset. Laadun kustannuksista. Sami Kollanus TJTA330 Ohjelmistotuotanto

Laadun hallinta. Laatukustannukset. Laadun kustannuksista. Sami Kollanus TJTA330 Ohjelmistotuotanto Laadun hallinta Sami Kollanus TJTA330 Ohjelmistotuotanto 5.4. Laatukustannukset US National Institute of Standards and Technology: Riittämättömän testauksen kustannusten arvioitiin olevan 59 Mrd dollaria

Lisätiedot

Laadun hallinta. Laatukustannukset. Sami Kollanus TJTA330 Ohjelmistotuotanto

Laadun hallinta. Laatukustannukset. Sami Kollanus TJTA330 Ohjelmistotuotanto Laadun hallinta Sami Kollanus TJTA330 Ohjelmistotuotanto 5.4. Laatukustannukset US National Institute of Standards and Technology: Riittämättömän testauksen kustannusten arvioitiin olevan 59 Mrd dollaria

Lisätiedot

1.3 Katsaus ohjelmistotuotannon kehittymiseen

1.3 Katsaus ohjelmistotuotannon kehittymiseen Yleisiä asioita Oliokirja:http://www.cs.tut.fi/~kk/Ohjelmistoarkkitehtuuri.pdf Tenttipäivä 7.5. Tallennukset, jospas tänään onnistaisi Viikkoharkat löytyvät IDLEstä (TTY), kurssin kotisivuilta/paikallisilta

Lisätiedot

Yleiskuvaus - LVpalvelukerroksen. laadulliset vaatimukset Jari Kokko & Vesa Mettovaara LUVAT JA VALVONTA -KÄRKIHANKE

Yleiskuvaus - LVpalvelukerroksen. laadulliset vaatimukset Jari Kokko & Vesa Mettovaara LUVAT JA VALVONTA -KÄRKIHANKE Yleiskuvaus - LVpalvelukerroksen laadulliset vaatimukset 07.11.2018 Jari Kokko & Vesa Mettovaara ICT-ratkaisujen tulee olla asiakkaille toimivia, tarpeellisia ja tuottavia liiketoiminnan jatkuvuuden, kannattavuuden

Lisätiedot

Ohjelmistoarkkitehtuurit, syksy

Ohjelmistoarkkitehtuurit, syksy Oppimistavoitteet Ohjelmistoarkkitehtuurit Luento 13 Mitä, miksi, milloin? Arviointimenetelmiä Skenaariopohjaiset menetelmät, suunnittelupäätöksiin kohdistuva menetelmä Ketterä arkkitehtuurin arviointi

Lisätiedot

Tietojärjestelmän osat

Tietojärjestelmän osat Analyysi Yleistä analyysistä Mitä ohjelmiston on tehtävä? Analyysin ja suunnittelun raja on usein hämärä Ei-tekninen näkökulma asiakkaalle näkyvien pääkomponenttien tasolla Tietojärjestelmän osat Laitteisto

Lisätiedot

Ohjelmistoarkkitehtuurit Syksy 2009 TTY Ohjelmistotekniikka 1

Ohjelmistoarkkitehtuurit Syksy 2009 TTY Ohjelmistotekniikka 1 1 Johdanto 1.1 Mikä on ohjelmistoarkkitehtuuri? 1.2 Katsaus ohjelmistotuotannon kehittymiseen 1.3 Ohjelmistoarkkitehtuuri ja ohjelmistokehitysprosessi 1.4 Toteutusalustan arkkitehtuurin rooli 1.5 Yhteenvetoa

Lisätiedot

9. Muunneltavuuden hallinta

9. Muunneltavuuden hallinta 9. Muunneltavuuden hallinta Muunneltavuuden hallinta (Variability management): Tekniikat ja työtavat, jotka auttavat kuvaamaan, toteuttamaan ja hyödyntämään tuoterungon mahdollistamaa ohjelmistotuotteiden

Lisätiedot

1 Johdanto. TTY Ohjelmistotekniikka. Ohjelmistoarkkitehtuurit Syksy 2008

1 Johdanto. TTY Ohjelmistotekniikka. Ohjelmistoarkkitehtuurit Syksy 2008 1 Johdanto 1.1 Mikä on ohjelmistoarkkitehtuuri? 1.2 Katsaus ohjelmistotuotannon kehittymiseen 1.3 Epäonnistuneen ohjelmistoarkkitehtuurin seurauksia 1.4 Ohjelmistoarkkitehtuuri ja ohjelmistokehitysprosessi

Lisätiedot

Arkkitehtuurien tutkimus Outi Räihä. OHJ-3200 Ohjelmistoarkkitehtuurit. Darwin-projekti. Johdanto

Arkkitehtuurien tutkimus Outi Räihä. OHJ-3200 Ohjelmistoarkkitehtuurit. Darwin-projekti. Johdanto OHJ-3200 Ohjelmistoarkkitehtuurit 1 Arkkitehtuurien tutkimus Outi Räihä 2 Darwin-projekti Darwin-projekti: Akatemian rahoitus 2009-2011 Arkkitehtuurisuunnittelu etsintäongelmana Geneettiset algoritmit

Lisätiedot

Decision-centric architecture review method (DCAR) Tarjolla tänään. Arkkitehtuuritietämys Arkkitehtuuritietämys. Arkkitehtuuripäätökset

Decision-centric architecture review method (DCAR) Tarjolla tänään. Arkkitehtuuritietämys Arkkitehtuuritietämys. Arkkitehtuuripäätökset Decision-centric architecture review method (DCAR) Ohjelmistoarkkitehtuurit Veli-Pekka Eloranta 22.02. 2012 Tarjolla tänään Arkkitehtuuritietämys Arkkitehtuuripäätökset DCAR -arviointimenetelmä Arkkitehtuuritietämys

Lisätiedot

1 Johdanto. Ohjelmistoarkkitehtuurit Syksy 2010 TTY Ohjelmistotekniikka 1

1 Johdanto. Ohjelmistoarkkitehtuurit Syksy 2010 TTY Ohjelmistotekniikka 1 1 Johdanto 1.1 Mikä on ohjelmistoarkkitehtuuri? 1.2 Ohjelmistoarkkitehtuuri ja laatuvaatimukset 1.3 Katsaus ohjelmistotuotannon kehittymiseen 1.4 Miksi ohjelmistoarkkitehtuuri on tärkeä 1.5 Ohjelmistoarkkitehtuuri

Lisätiedot

ISO/IEC 25000 sarja (SQUARE)

ISO/IEC 25000 sarja (SQUARE) ISO/IEC 25000 sarja (SQUARE) Software product Quality Requirements and Evaluation (SQuaRE) Risto Nevalainen, FiSMA ry FiSMA 1 Taustaa, historiaa Ohjelmiston laadun mittaaminen on yksi vanhimmista SC7 standardointialueista

Lisätiedot

Sisäänrakennettu tietosuoja ja ohjelmistokehitys

Sisäänrakennettu tietosuoja ja ohjelmistokehitys Sisäänrakennettu tietosuoja ja ohjelmistokehitys Petri Strandén 14. kesäkuuta, 2018 Petri Strandén Manager Cyber Security Services Application Technologies Petri.stranden@kpmg.fi Petri vastaa KPMG:n Technology

Lisätiedot

1 Johdanto. TTY Ohjelmistotekniikka. Ohjelmistoarkkitehtuurit Syksy 2007

1 Johdanto. TTY Ohjelmistotekniikka. Ohjelmistoarkkitehtuurit Syksy 2007 1 Johdanto 1.1 Mikä on ohjelmistoarkkitehtuuri? 1.2 Katsaus ohjelmistotuotannon kehittymiseen 1.3 Epäonnistuneen ohjelmistoarkkitehtuurin seurauksia 1.4 Ohjelmistoarkkitehtuuri ja ohjelmistokehitysprosessi

Lisätiedot

Osittavat arkkitehtuurityylit. Palveluihin perustuvat arkkitehtuurityylit. Erikoisarkkitehtuurityylit

Osittavat arkkitehtuurityylit. Palveluihin perustuvat arkkitehtuurityylit. Erikoisarkkitehtuurityylit 6. Arkkitehtuurityylit Osittavat arkkitehtuurityylit Kerrosarkkitehtuurit Tietovuoarkkitehtuurit Palveluihin perustuvat arkkitehtuurityylit Asiakas-palvelin arkkitehtuurit Viestinvälitysarkkitehtuurit

Lisätiedot

Yleisiä asioita. Harkat alkavat ensi viikolla Vierailuluentoa. Slackin #luennot-kanava taas käytössä. Ensi viikon perjantaina, Janne Viitala, Sandvik

Yleisiä asioita. Harkat alkavat ensi viikolla Vierailuluentoa. Slackin #luennot-kanava taas käytössä. Ensi viikon perjantaina, Janne Viitala, Sandvik Yleisiä asioita Harkat alkavat ensi viikolla Vierailuluentoa Ensi viikon perjantaina, Janne Viitala, Sandvik Slackin #luennot-kanava taas käytössä 1 1 Johdanto 1.1 Mikä on ohjelmistoarkkitehtuuri? 1.2

Lisätiedot

Sisäänrakennettu tietosuoja ja ohjelmistokehitys

Sisäänrakennettu tietosuoja ja ohjelmistokehitys Sisäänrakennettu tietosuoja ja ohjelmistokehitys Petri Strandén 8. kesäkuuta, 2018 Agenda Ohjelmistokehitys Ohjelmistokehitys vs. konsultointi Vaatimukset Tietosuoja Tietosuoja ohjelmistokehityksessä kiteytettynä

Lisätiedot

1 Johdanto. Pieni motivointikalvo. 1.1 Mikä on ohjelmistoarkkitehtuuri?

1 Johdanto. Pieni motivointikalvo. 1.1 Mikä on ohjelmistoarkkitehtuuri? 1 Johdanto 1.1 Mikä on ohjelmistoarkkitehtuuri? 1.2 Ohjelmistoarkkitehtuuri ja laatuvaatimukset 1.3 Katsaus ohjelmistotuotannon kehittymiseen 1.4 Miksi ohjelmistoarkkitehtuuri on tärkeä 1.5 Ohjelmistoarkkitehtuuri

Lisätiedot

10. Muunneltavuuden hallinta: variaatiopisteet

10. Muunneltavuuden hallinta: variaatiopisteet Ohjelmistoarkkitehtuurit Kevät 2012-2013 Johannes Koskinen http://www.cs.tut.fi/~ohar/ 1 10. Muunneltavuuden hallinta: variaatiopisteet Muunneltavuuden hallinta (Variability management): Tekniikat ja työtavat,

Lisätiedot

Arkkitehti?

Arkkitehti? 1 Johdanto 1.1 Mikä on ohjelmistoarkkitehtuuri? 1.2 Ohjelmistoarkkitehtuuri ja laatuvaatimukset 1.3 Katsaus ohjelmistotuotannon kehittymiseen 1.4 Miksi ohjelmistoarkkitehtuuri on tärkeä 1.5 Ohjelmistoarkkitehtuuri

Lisätiedot

Käytettävyyslaatumallin rakentaminen verkkosivustolle

Käytettävyyslaatumallin rakentaminen verkkosivustolle Käytettävyyslaatumallin rakentaminen verkkosivustolle Tapaus kirjoittajan ABC-kortti Oulun yliopisto tietojenkäsittelytieteiden laitos pro gradu -tutkielma Timo Laapotti 9.6.2005 Esityksen sisältö Kirjoittajan

Lisätiedot

Ohjelmiston toteutussuunnitelma

Ohjelmiston toteutussuunnitelma Ohjelmiston toteutussuunnitelma Ryhmän nimi: Tekijä: Toimeksiantaja: Toimeksiantajan edustaja: Muutospäivämäärä: Versio: Katselmoitu (pvm.): 1 1 Johdanto Tämä luku antaa yleiskuvan koko suunnitteludokumentista,

Lisätiedot

Ohjelmistojen suunnittelu

Ohjelmistojen suunnittelu Ohjelmistojen suunnittelu 581259 Ohjelmistotuotanto 154 Ohjelmistojen suunnittelu Software design is a creative activity in which you identify software components and their relationships, based on a customer

Lisätiedot

Ohjelmistoarkkitehtuurit Kevät 2016 Johdantoa

Ohjelmistoarkkitehtuurit Kevät 2016 Johdantoa Ohjelmistoarkkitehtuurit Kevät 2016 Johdantoa Samuel Lahtinen http://www.cs.tut.fi/~ohar/ 8.1.2014 1 1 Johdanto 1.1 Mikä on ohjelmistoarkkitehtuuri? 1.2 Ohjelmistoarkkitehtuuri ja laatuvaatimukset 1.3

Lisätiedot

Copyright by Haikala. Ohjelmistotuotannon osa-alueet

Copyright by Haikala. Ohjelmistotuotannon osa-alueet Copyright by Haikala Ohjelmistotuotannon osa-alueet Ohjelmiston elinkaari 1. Esitutkimus, tarvekartoitus, kokonaissuunnittelu, järjestelmäsuunnittelu (feasibility study, requirement study, preliminary

Lisätiedot

Ohjelmistoarkkitehtuuri

Ohjelmistoarkkitehtuuri Ohjelmistoarkkitehtuurien ylläpito Arkkitehtuurityylejä ja laatuvaatimuksia Arkkitehtuurin uudistaminen Arkkitehtuurin uudistamisen malleja Arkkitehtuurin arviointi TTY Ohjelmistotekniikka 1 Ohjelmistoarkkitehtuuri

Lisätiedot

Uudelleenkäytön jako kahteen

Uudelleenkäytön jako kahteen Uudelleenkäyttö Yleistä On pyritty pääsemään vakiokomponenttien käyttöön Kuitenkin vakiokomponentit yleistyneet vain rajallisilla osa-alueilla (esim. windows-käyttöliittymä) On arvioitu, että 60-80% ohjelmistosta

Lisätiedot

KUNTIEN JA HUS:N ASIAKAS- JA POTILASTIETOJÄRJESTELMÄN HANKINTA

KUNTIEN JA HUS:N ASIAKAS- JA POTILASTIETOJÄRJESTELMÄN HANKINTA KUNTIEN JA HUS:N ASIAKAS- JA POTILASTIETOJÄRJESTELMÄN HANKINTA Tarjouspyyntö Liite 5.3: Järjestelmän ylläpidettävyden arviointi 1 / 5 VERSIOHISTORIA Päivä Versio Kuvaus Tekijä 22.4.15 3.01 Poistettu kotihoito

Lisätiedot

10. Muunneltavuuden hallinta: variaatiopisteet

10. Muunneltavuuden hallinta: variaatiopisteet 10. Muunneltavuuden hallinta: variaatiopisteet Muunneltavuuden hallinta (Variability management): Tekniikat ja työtavat, jotka auttavat kuvaamaan, toteuttamaan ja hyödyntämään ohjelmistotuotteiden variaatiota.

Lisätiedot

1 Johdanto! Arkkitehti?!

1 Johdanto! Arkkitehti?! 1 Johdanto! 1.1 Mikä on ohjelmistoarkkitehtuuri? 1.2 Ohjelmistoarkkitehtuuri ja laatuvaatimukset 1.3 Katsaus ohjelmistotuotannon kehittymiseen 1.4 Miksi ohjelmistoarkkitehtuuri on tärkeä 1.5 Ohjelmistoarkkitehtuuri

Lisätiedot

Decision-centric architecture review method (DCAR) Ohjelmistoarkkitehtuurit Veli-Pekka Eloranta (Samuel Lahtinen)

Decision-centric architecture review method (DCAR) Ohjelmistoarkkitehtuurit Veli-Pekka Eloranta (Samuel Lahtinen) Decision-centric architecture review method (DCAR) Ohjelmistoarkkitehtuurit Veli-Pekka Eloranta (Samuel Lahtinen) Tarjolla tänään Arkkitehtuuritietämys Arkkitehtuuripäätökset DCAR ja ATAM-arviointimenetelmä

Lisätiedot

Bosch-malli. Kolme vaihetta. Termistöä. Ohjelm!toarkkitehtuu"n

Bosch-malli. Kolme vaihetta. Termistöä. Ohjelm!toarkkitehtuun Bosch-malli Ohjelm!toarkkitehtuu"n suunni#elu 2$6 Quality Attribute-oriented Software Architecture Design method Toiminnallisista vaatimuksista laadittu arkkitehtuurimalli kehitetään arvioimalla sitä laadullisten

Lisätiedot

Ohjelmiston testaus ja laatu. Ohjelmistotekniikka elinkaarimallit

Ohjelmiston testaus ja laatu. Ohjelmistotekniikka elinkaarimallit Ohjelmiston testaus ja laatu Ohjelmistotekniikka elinkaarimallit Vesiputousmalli - 1 Esitutkimus Määrittely mikä on ongelma, onko valmista ratkaisua, kustannukset, reunaehdot millainen järjestelmä täyttää

Lisätiedot

Decision-centric architecture review method (DCAR) Ohjelmistoarkkitehtuurit Veli-Pekka Eloranta

Decision-centric architecture review method (DCAR) Ohjelmistoarkkitehtuurit Veli-Pekka Eloranta Decision-centric architecture review method (DCAR) Ohjelmistoarkkitehtuurit Veli-Pekka Eloranta 26.02. 2013 Tarjolla tänään Arkkitehtuuritietämys Arkkitehtuuripäätökset DCAR -arviointimenetelmä Arkkitehtuuritietämys

Lisätiedot

Arkkitehtuurikuvaus. Ratkaisu ohjelmistotuotelinjan monikielisyyden hallintaan Innofactor Oy. Ryhmä 14

Arkkitehtuurikuvaus. Ratkaisu ohjelmistotuotelinjan monikielisyyden hallintaan Innofactor Oy. Ryhmä 14 Arkkitehtuurikuvaus Ratkaisu ohjelmistotuotelinjan monikielisyyden hallintaan Innofactor Oy Ryhmä 14 Muutoshistoria Versio Pvm Päivittäjä Muutos 0.4 1.11.2007 Matti Eerola 0.3 18.10.2007 Matti Eerola 0.2

Lisätiedot

Ohjelmistoprojektien hallinta Vaihejakomallit

Ohjelmistoprojektien hallinta Vaihejakomallit Ohjelmistoprojektien hallinta Vaihejakomallit Vaihejakomallit TAVOITE: YMMÄRTÄÄ eri vaihejakomallien etujajahaittoja 2 Erilaisia malleja Tee ja korjaa (Code-and-Fix) Vesiputousmalli (Waterfall) Vesiputousmalli

Lisätiedot

TOIMINNALLINEN MÄÄRITTELY MS

TOIMINNALLINEN MÄÄRITTELY MS TOIMINNALLINEN MÄÄRITTELY 11.11.2015 MS YLEISTÄ 1/2 jäsennelty etenee yleiskuvauksesta yksityiskohtiin kieliasultaan selkeä kuvaa myös tulevan järjestelmän ympäristöä tarpeellisella tarkkuudella kuvaa

Lisätiedot

Luento 12. Jouni Lappalainen, Ilkka Tervonen, additions & editions by Antti Juustila

Luento 12. Jouni Lappalainen, Ilkka Tervonen, additions & editions by Antti Juustila Luento 12 Kertaus Luku 8: Suunnittelutekniikat suunnittelun käsitteet suunnittelumalli (design model) arkkitehtuuri, rajapinnat, komponenttitaso, sijoitustaso Luku 9: Arkkitehtuurisuunnittelu arkkitehtuurigenret,

Lisätiedot

Testauksen tuki nopealle tuotekehitykselle. Antti Jääskeläinen Matti Vuori

Testauksen tuki nopealle tuotekehitykselle. Antti Jääskeläinen Matti Vuori Testauksen tuki nopealle tuotekehitykselle Antti Jääskeläinen Matti Vuori Mitä on nopeus? 11.11.2014 2 Jatkuva nopeus Läpäisyaste, throughput Saadaan valmiiksi tasaiseen, nopeaan tahtiin uusia tuotteita

Lisätiedot

Käyttäjien tunnistaminen ja käyttöoikeuksien hallinta hajautetussa ympäristössä

Käyttäjien tunnistaminen ja käyttöoikeuksien hallinta hajautetussa ympäristössä www.niksula.cs.hut.fi/~jjkankaa// Demosovelluksen tekninen määrittely v. 0.6 Päivitetty 11.12.2000 klo 20:26 Mickey Shroff 2 (12) Dokumentin versiohistoria Versio Päivämäärä Tekijä / muutoksen tekijä Selite

Lisätiedot

Kansallinen ASPAtietojärjestelmä

Kansallinen ASPAtietojärjestelmä Kansallinen ASPAtietojärjestelmä Taustoitus Järjestäjien tarve yhteiselle asiakaspalautteen keräämisen järjestelmälle nousi esiin kevään selvityksessä Asiakaspalautetieto on myös osa kansallista sote-tietopohjaa

Lisätiedot

6. Arkkitehtuurityylit

6. Arkkitehtuurityylit 6. Arkkitehtuurityylit Osittavat arkkitehtuurityylit - Kerrosarkkitehtuurit - Tietovuoarkkitehtuurit Palveluihin perustuvat arkkitehtuurityylit - Asiakas-palvelin arkkitehtuurit - Viestinvälitysarkkitehtuurit

Lisätiedot

Aluksi. Riskien hallinta. Riskityyppejä. Riskillä on kaksi ominaisuutta. Reaktiivinen strategia. Proaktiivinen strategia

Aluksi. Riskien hallinta. Riskityyppejä. Riskillä on kaksi ominaisuutta. Reaktiivinen strategia. Proaktiivinen strategia Aluksi Riskien hallinta Sami Kollanus TJTA330 Ohjelmistotuotanto 24.1.2007 Reaktiivinen strategia Indiana Jones -tyyli Ei huolehdita ongelmista ennen kuin ne tapahtuu Proaktiivinen strategia Tunnistetaan

Lisätiedot

Toimilohkojen turvallisuus tulevaisuudessa

Toimilohkojen turvallisuus tulevaisuudessa Toimilohkojen turvallisuus tulevaisuudessa Turvallisuusseminaari ASAF 30.10-1.11.2006 Mika Strömman Teknillinen korkeakoulu 1 Sisältö Luotettavuuden lisääminen hyvillä tavoilla Toimilohkokirjastot Turvatoimilohkot

Lisätiedot

Vanhan järjestelmän vaiheittainen korvaaminen ohjelmistoarkkitehtuurin soveltuvuuden arviointi

Vanhan järjestelmän vaiheittainen korvaaminen ohjelmistoarkkitehtuurin soveltuvuuden arviointi hyväksymispäivä arvosana arvostelija Vanhan järjestelmän vaiheittainen korvaaminen ohjelmistoarkkitehtuurin soveltuvuuden arviointi Jussi Iinatti 29.3.2012 HELSINGIN YLIOPISTO Tietojenkäsittelytieteen

Lisätiedot

Yhteisön kehitystyöhön osallistumisen mahdollisuudet ja mallit

Yhteisön kehitystyöhön osallistumisen mahdollisuudet ja mallit Yhteisön kehitystyöhön osallistumisen mahdollisuudet ja mallit Tavoiteltava ketterä projektin kehitysprosessi? ( projektin arki ) Muutamia päiviä Viikko(ja) Kuukausi(a) 0. Projekti-ideavaihe Kehitysaloitteita

Lisätiedot

7 Sulautettujen järjestelmien suunnittelumallit. OhAr Marko Leppänen

7 Sulautettujen järjestelmien suunnittelumallit. OhAr Marko Leppänen 7 Sulautettujen järjestelmien suunnittelumallit OhAr 6.10. 2009 Marko Leppänen Sulautettujen järjestelmien mallikieli Sulake-projekti, 2008-2009 Arkkitehtuurianalyysejä 4 teollisuuskumppanin kanssa Sivutuotteena

Lisätiedot

Ennustamisen ja Optimoinnin mahdollisuudet

Ennustamisen ja Optimoinnin mahdollisuudet Ennustamisen ja Optimoinnin mahdollisuudet Agenda Mitä optimointi on Ennustamisen mahdollisuudet Optimoinnin eri tasot ja tavoitteet Optimoinnin käyttöönotto Mitä optimointi on Mitä optimointi on? Oikea

Lisätiedot

Järjestelmäarkkitehtuuri (TK081702) Web Services. Web Services

Järjestelmäarkkitehtuuri (TK081702) Web Services. Web Services Järjestelmäarkkitehtuuri (TK081702) Standardoidutu tapa integroida sovelluksia Internetin kautta avointen protokollien ja rajapintojen avulla. tekniikka mahdollista ITjärjestelmien liittämiseen yrityskumppaneiden

Lisätiedot

Luento 6. Jouni Lappalainen, Ilkka Tervonen, additions & editions by Antti Juustila

Luento 6. Jouni Lappalainen, Ilkka Tervonen, additions & editions by Antti Juustila Luento 6 Kertaus Luku 8: Suunnittelutekniikat suunnittelun käsitteet suunnittelumalli (design model) arkkitehtuuri, rajapinnat, komponenttitaso, sijoitustaso Luku 9: Arkkitehtuurisuunnittelu arkkitehtuurigenret,

Lisätiedot

Ohjelmistoprosessit ja ohjelmistojen laatu Kevät Ohjelmistoprosessit ja ohjelmistojen. Antti-Pekka Tuovinen (Jukka Paakki et al.

Ohjelmistoprosessit ja ohjelmistojen laatu Kevät Ohjelmistoprosessit ja ohjelmistojen. Antti-Pekka Tuovinen (Jukka Paakki et al. Ohjelmistoprosessit ja ohjelmistojen Antti-Pekka Tuovinen (Jukka Paakki et al.) Helsingin yliopisto Tietojenkäsittelytieteen laitos OHJELMISTOJEN LAATU 2 1 Laatu The proof of the pudding is in the eating

Lisätiedot

Projektin suunnittelu

Projektin suunnittelu Projektin suunnittelu Sami Kollanus TJTA330 Ohjelmistotuotanto 15.3. Projektin suunnittelu - CMMIkäytänteet Projektin estimaatit: Määritellään projektin laajuus (scope) Määritellään tehtävien ja tuotosten

Lisätiedot

Decision-centric architecture review method (DCAR) Ohjelmistoarkkitehtuurit Veli-Pekka Eloranta

Decision-centric architecture review method (DCAR) Ohjelmistoarkkitehtuurit Veli-Pekka Eloranta Decision-centric architecture review method (DCAR) Ohjelmistoarkkitehtuurit Veli-Pekka Eloranta 26.02. 2014 Tarjolla tänään Lyhyesti arkkitehtuuritietämyksestä Arkkitehtuuripäätökset DCAR -arviointimenetelmä

Lisätiedot

PlugIT / Ydin: teemat ja jaksojen 2-6 suunnitelma ( )

PlugIT / Ydin: teemat ja jaksojen 2-6 suunnitelma ( ) PlugIT / Ydin: teemat ja jaksojen 2-6 suunnitelma (1.5.2002-31.8.2004) Ydin-osaprojekti: potilastietojen toiminnallisen hallinnan näkökulma Yhteisten ydinkomponenttien määrittely" Ydin-osaprojektin rooli

Lisätiedot

Opetussuunnitelmien ja tutkintojen perusteiden rakenteistaminen

Opetussuunnitelmien ja tutkintojen perusteiden rakenteistaminen Opetussuunnitelmien ja tutkintojen perusteiden rakenteistaminen Toiminnallinen määrittely: Työsuunnitelma TYÖSUUNNITELMAN TIEDOT Versio 0.1 Laatija Ulla Angervo Laatimispäivämäärä Hyväksyjä Hyväksymispäivämäärä

Lisätiedot

Studio ART Oy. Yritysesittely. Studio ART Oy. Kasöörintie 14 90420 Oulu p. 040-5799073 www.studioart.fi

Studio ART Oy. Yritysesittely. Studio ART Oy. Kasöörintie 14 90420 Oulu p. 040-5799073 www.studioart.fi Studio ART Oy Yritysesittely Studio ART Oy Kasöörintie 14 90420 Oulu p. 040-5799073 www.studioart.fi Pekka Klemetti Managing Director pekka.klemetti@studioart.fi Studio ART Oy Toimiala ICT Avainsana Tuotekehitys,

Lisätiedot

7. Tuoterunkoarkkitehtuurit

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

Lisätiedot

Arkkitehtuurityylejä ja suunnittelutaktiikoita

Arkkitehtuurityylejä ja suunnittelutaktiikoita Arkkitehtuurityylejä ja suunnittelutaktiikoita Luento 5 2. osa 16.9.2014 581385 Ohjelmistoarkkitehtuurit 1 Oppimistavoitteet Arkkitehtuurityylejä (esityksen 1. osa) jaettu tietovarasto, viestinvälitysarkkitehtuurit,

Lisätiedot

Darwin: Tutkimusprojektin esittely

Darwin: Tutkimusprojektin esittely 1 Darwin: Tutkimusprojektin esittely Tutkimusongelma: voidaanko ohjelmistoarkkitehtuuri generoida automaattisesti? Suomen Akatemian rahoittama tutkimusprojekti 2009-2011 TTY & TaY yhteistyö Ks. http://practise.cs.tut.fi/project.php?project=darwin

Lisätiedot

Johdantoluento. Ohjelmien ylläpito

Johdantoluento. Ohjelmien ylläpito Johdantoluento Ylläpito-termin termin määrittely Ylläpito ohjelmistotuotannon vaiheena Evoluutio-termin määrittely Muita kurssin aiheeseen liittyviä termejä TTY Ohjelmistotekniikka 1 Ohjelmien ylläpito

Lisätiedot

7.4 Variability management

7.4 Variability management 7.4 Variability management time... space software product-line should support variability in space (different products) support variability in time (maintenance, evolution) 1 Product variation Product

Lisätiedot

Muunneltavuuden hallinta (Variability management):

Muunneltavuuden hallinta (Variability management): 11. Muunneltavuuden hallinta Muunneltavuuden hallinta (Variability management): Tekniikat ja työtavat, jotka auttavat kuvaamaan, toteuttamaan ja hyödyntämään ohjelmistotuotteiden variaatiota. Ohjelmistoarkkitehtuurit

Lisätiedot

6. Arkkitehtuurityylit

6. Arkkitehtuurityylit 6. Arkkitehtuurityylit Osittavat arkkitehtuurityylit Kerrosarkkitehtuurit (rakenteen ositus) Tietovuoarkkitehtuurit (toiminnan ositus) Palveluihin perustuvat arkkitehtuurityylit Asiakas-palvelin arkkitehtuurit

Lisätiedot

OHJELMISTOJEN LAATU. Ohjelmistoprosessit ja ohjelmistojen laatu Kevät Laatu. Ohjelmistoprosessit ja ohjelmistojen. Neljä näkökulmaa laatuun

OHJELMISTOJEN LAATU. Ohjelmistoprosessit ja ohjelmistojen laatu Kevät Laatu. Ohjelmistoprosessit ja ohjelmistojen. Neljä näkökulmaa laatuun Ohjelmistoprosessit ja ohjelmistojen Antti-Pekka Tuovinen (Jukka Paakki et al.) Helsingin yliopisto Tietojenkäsittelytieteen laitos Laatu Tuotteen tai palvelun ilmenee, kun sitä käytetään johonkin todelliseen

Lisätiedot

Ohjelmistoarkkitehtuurit. Kevät

Ohjelmistoarkkitehtuurit. Kevät Ohjelmistoarkkitehtuurit Kevät 2012-2013 Johannes Koskinen http://www.cs.tut.fi/~ohar/ Tervetuloa Oulun yliopisto, Tampereen yliopisto, Turun yliopisto, Tampereen teknillinen yliopisto 2 Kurssin tavoitteet

Lisätiedot

Simulation and modeling for quality and reliability (valmiin työn esittely) Aleksi Seppänen

Simulation and modeling for quality and reliability (valmiin työn esittely) Aleksi Seppänen Simulation and modeling for quality and reliability (valmiin työn esittely) Aleksi Seppänen 16.06.2014 Ohjaaja: Urho Honkanen Valvoja: Prof. Harri Ehtamo Työn saa tallentaa ja julkistaa Aalto-yliopiston

Lisätiedot

Suunnitteluvaihe prosessissa

Suunnitteluvaihe prosessissa Suunnittelu Suunnitteluvaihe prosessissa Silta analyysin ja toteutuksen välillä (raja usein hämärä kumpaankin suuntaan) Asteittain tarkentuva Analyysi -Korkea abstraktiotaso -Sovellusläheiset käsitteet

Lisätiedot

Ohjelmistotekniikka: Luento 6

Ohjelmistotekniikka: Luento 6 Ohjelmistotekniikka: Luento 6 Jouni Lappalainen Luku 8: Suunnittelutekniikat suunnittelun käsitteet suunnittelumalli (design model) arkkitehtuuri, rajapinnat, komponenttitaso, sijoitustaso Luku 9: Arkkitehtuurisuunnittelu

Lisätiedot

Ohjelmistoprosessit ja ohjelmistojen laatu Kevät Ohjelmistoprosessit ja ohjelmistojen. Antti-Pekka Tuovinen (Jukka Paakki et al.

Ohjelmistoprosessit ja ohjelmistojen laatu Kevät Ohjelmistoprosessit ja ohjelmistojen. Antti-Pekka Tuovinen (Jukka Paakki et al. Ohjelmistoprosessit ja ohjelmistojen Antti-Pekka Tuovinen (Jukka Paakki et al.) Helsingin yliopisto Tietojenkäsittelytieteen laitos OHJELMISTOJEN LAATU 2 1 Laatu The proof of the pudding is in the eating

Lisätiedot

Ohjelmistotuotanto vs. muut insinööritieteet. (Usein näennäinen) luotettavuus ja edullisuus

Ohjelmistotuotanto vs. muut insinööritieteet. (Usein näennäinen) luotettavuus ja edullisuus Yhteenveto Ohjelmistotuotanto vs. muut insinööritieteet Monimutkaisuus Näkymättömyys (Usein näennäinen) luotettavuus ja edullisuus Muunnettavuus Epäjatkuvuus virhetilanteissa Skaalautumattomuus Copyright

Lisätiedot

OHJELMISTOJEN LAATU. Ohjelmistoprosessit ja ohjelmistojen. Laatu. Laatu. Neljä näkökulmaa laatuun. Ohjelmisto

OHJELMISTOJEN LAATU. Ohjelmistoprosessit ja ohjelmistojen. Laatu. Laatu. Neljä näkökulmaa laatuun. Ohjelmisto Ohjelmistoprosessit ja ohjelmistojen Antti-Pekka Tuovinen (Jukka Paakki et al.) Helsingin yliopisto Tietojenkäsittelytieteen laitos OHJELMISTOJEN LAATU 2 Laatu The proof of the pudding is in the eating

Lisätiedot

Ohjelmistoarkkitehtuurit, syksy

Ohjelmistoarkkitehtuurit, syksy Ohjelmistoarkkitehtuurit 27.9.2012 1 Ohjelmistoja kehitettäessä toiminnallisuuden suunnittelu saa usein kaikkein keskeisimmän osan Järjestelmän arkkitehtuurin kannalta suoraan toiminnallisuuteen liittyvät

Lisätiedot

11.12.2006 VAATIMUSMÄÄRITTELY

11.12.2006 VAATIMUSMÄÄRITTELY VAATIMUSMÄÄRITTELY Vaatimusmäärittely 2 (18) VERSIONHALLINTA Versio Päivä Tekijä Kuvaus 0.1 4.10.2006 Kaarlo Lahtela Ensimmäinen versio 0.2 4.10.2006 Kaarlo Lahtela kohdat 7 (tominnalliset vaatimukset)

Lisätiedot

Ohjelmistoarkkitehtuurit, syksy

Ohjelmistoarkkitehtuurit, syksy Ohjelmistoarkkitehtuurit Tuoteperheet Tuoterunkoarkkitehtuurit Perinteisessä ohjelmistotuotannossa on keskitytty uusien ohjelmistojen laadukkaaseen tuottamiseen Erikoistuneista ainutlaatuisista vaatimuksista

Lisätiedot

Uutisjärjestelmä. Vaatimusmäärittely. Web-palvelujen kehittäminen. Versio 1.3

Uutisjärjestelmä. Vaatimusmäärittely. Web-palvelujen kehittäminen. Versio 1.3 Uutisjärjestelmä Vaatimusmäärittely Versio 1.3 Sisällys 1 Muutoshistoria... 4 2 Viitteet... 4 3 Sanasto... 4 3.1 Lyhenteet... 4 3.2 Määritelmät... 4 4 Johdanto...5 4.1 Järjestelmän yleiskuvaus... 5 4.2

Lisätiedot

Ohjelmistoarkkitehtuurit kevät

Ohjelmistoarkkitehtuurit kevät Ohjelmistoarkkitehtuurit Kevät 2011-2012 Johannes Koskinen http://www.cs.tut.fi/~ohar/ 6. Arkkitehtuurityylit Osittavat arkkitehtuurityylit Kerrosarkkitehtuurit (rakenteen ositus) Tietovuoarkkitehtuurit

Lisätiedot

Harjoitustehtävät viikolle 42

Harjoitustehtävät viikolle 42 Harjoitustehtävät viikolle 42 1. Suunnittele pieni työkaluohjelma, joka laskee keskiarvon lukujoukosta. Käyttöliittymä koostuu perusikkunan lisäksi yhdestä valikosta, jossa on kaksi komentoa: Start (aloita

Lisätiedot

Tämän lisäksi listataan ranskalaisin viivoin järjestelmän tarjoama toiminnallisuus:

Tämän lisäksi listataan ranskalaisin viivoin järjestelmän tarjoama toiminnallisuus: Dokumentaatio, osa 1 Tehtävämäärittely Kirjoitetaan lyhyt kuvaus toteutettavasta ohjelmasta. Kuvaus tarkentuu myöhemmin, aluksi dokumentoidaan vain ideat, joiden pohjalta työtä lähdetään tekemään. Kuvaus

Lisätiedot

Ohjelmistotuotanto, s /27/2003

Ohjelmistotuotanto, s /27/2003 Ohjelmistotuotanto Laatu - useita eri näkemyksiä: klassinen: kaikki tarpeet huomioiva hyvyys tuote- ja hintasidonnainen: mitä kalliimpi sitä parempi tarkoituksenmukaisuus: laadukas tuote sopii tarkoitukseensa

Lisätiedot

Ohjelmistoarkkitehtuurit

Ohjelmistoarkkitehtuurit Ohjelmistoarkkitehtuurit Kevät 2012-2013 Johannes Koskinen http://www.cs.tut.fi/~ohar/ 1 Arkkitehtuurityylit Osittavat arkkitehtuurityylit Kerrosarkkitehtuurit (rakenteen ositus) Tietovuoarkkitehtuurit

Lisätiedot

Ohjelmistotekniikan menetelmät, luokkamallin laatiminen

Ohjelmistotekniikan menetelmät, luokkamallin laatiminen 582101 - Ohjelmistotekniikan menetelmät, luokkamallin laatiminen 1 Lähestymistapoja Kokonaisvaltainen lähestymistapa (top-down) etsitään kerralla koko kohdealuetta kuvaavaa mallia hankalaa, jos kohdealue

Lisätiedot