Ohjelmistoarkkitehtuurit kevät

Koko: px
Aloita esitys sivulta:

Download "Ohjelmistoarkkitehtuurit kevät"

Transkriptio

1 Ohjelmistoarkkitehtuurit Kevät Johannes Koskinen 9. Ohjelmistoarkkitehtuurien arviointi Johdanto ATAM-menetelmä Esimerkki Käytännön kokemuksia ja ongelmia Yhteenveto 2 Mitä on ohjelmistoarkkitehtuurin arviointi? Ohjelmistoarkkitehtuurin arviointi tarkoittaa toimintaa, jonka avulla voidaan tehdä johtopäätöksiä siitä, miten hyvin tietty ohjelmistoarkkitehtuuri tukee ko. järjestelmän vaatimusten toteutumista 3 1

2 Miksi ohjelmistoarkkitehtuuria on arvioitava? Arkkitehtuuri on ensimmäinen täsmällinen kuvaus järjestelmästä Arviointi vahvistaa hyvät ratkaisut ja kiinnittää huomiota mahdollisiin ongelmiin aikaisin Arviointi auttaa ymmärtämään paremmin järjestelmää 4 Muita mahdollisia hyötyjä Kehitystrendien sekä potentiaalisten kehitys- ja riskialueiden tunnistaminen Arvioinnilla voidaan varmistua muiden tekemien ohjelmistojen (esim. alihankinta) laadusta Arkkitehtuurin suunnittelua ohjaavien laatuvaatimusten kirjaaminen ja tarkentaminen Arkkitehtuuriratkaisuiden kirjaaminen ja liittäminen laatuvaatimuksiin Arkkitehtuuridokumentaation parantaminen Kommunikaation lisääminen Milloin ohjelmistoarkkitehtuuri olisi arvioitava? Ensimmäisten (vaihtoehtoisten) luonnosten pohjalta (alustava arkkitehtuuridokumentti) Arkkitehtuurisuunnittelun jälkeen, ennen toteutuksen aloittamista (järjestelmä/alijärjestelmäarkkitehtuuridokumentti) Olemassaolevalle järjestelmälle (esim. vanhan järjestelmän uudistaminen) 6 2

3 Arkkitehtuurin rakentaminen kehitysprosessissa Laatuvaatimukset Arkkitehtuurin kannalta merkittävät vaatimukset Vaatimusanalyysi Keskeiset toiminnalliset vaatimukset Arkkitehtuurimuunnos Ympäristövaatimukset Rajoitteet Toissijaiset toiminnalliset vaatimukset Yksityiskohtainen suunnittelu Alustava arkkitehtuuri Yleisten ratkaisumallien soveltaminen Arkkitehtuurin arviointi Alustava arkkitehtuurisuunnittelu Laatuvaatimuksen huomiointi ei OK Kaikki käsitelty Arkkitehtuuri OK 7 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 laatuvaatimusten toteutuminen tai toteutumattomuus Arkkitehtuuria arvioidaan (yleensä) vasten laatuvaatimuksia 8 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

4 ISO 9126 laatukehikko 10 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 Ryhmittelyllä ei käytännössä paljon merkitystä arvioinnissa 11 Arkkitehtuuri ja liiketoimintatavoitteet 12 4

5 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? 13 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 14 Kysyttävää? 15 5

6 Ohjelmistoarkkitehtuurien arvioinnin ongelma? Laatuvaatimukset Ohjelmistoarkkitehtuuri 16 Laatuvaatimukset tulevat sidosryhmiltä Hyvä suorituskyky, luotettava, hyvä käytettävyys Helposti ylläpidettävä, siirrettävä Loppukäyttäjä Ylläpitäjä 17 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 ne, anna kullekin tarkennetulle laatuominaisuudelle esimerkki- tilanne, ja tutki täyttyykö ko. laatuominaisuus tässä esimerkkitilanteessa 18 6

7 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 19 Ohjelmistoarkkitehtuurien arvioinnin ongelman ratkaisu: skenaariopohjainen arviointi? Vaatimusten tarkennus Skenaariot Analyysi Laatuvaatimukset Ohjelmistoarkkitehtuuri Arkkitehtuuriratkaisut Ratkaisujen identifiointi 20 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ä 21 7

8 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) (esim. Rigi, Columbus) 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ä 22 Esimerkki (Columbus): koodin kopiointi 23 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? 24 8

9 Kysyttävää? 25 Skenaariopohjaiset arviointimenetelmät SAAM (Software Architecture Analysis Method) keskittyy erityisesti muunneltavuuteen, siirrettävyyteen, ylläpidettävyyteen kehitetty SEI:ssä 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 26 ATAM tietovuo Len Bass 27 9

10 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 Ei-riski: arkkitehtuuripäätös joka voi edesauttaa laatuominaisuuden toteutumisessa 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 Skenaario esimerkki 30 10

11 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ä 31 Harjoitus 32 Laatu Esimerkki: laatupuu laatuominaisuudet Suorituskyky Muunneltavuus Saatavuus Tietoturvallisuus tarkennukset Transaktioiden käsittely Vasteaika GUI muutokset Anna muunneltavuuteen liittyvä skenaario VR:n matkalippuautomaattijärjestelmälle. Tietokantamuutokset Laitteistoviat Palvelimen kaatuminen Korttien käyttö 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) Tietokanta vaihdetaan Oracleksi 6 kk:ssa (L,H) Palvelimen kovalevyn hajoamisen jälkeen uusintakäynnistys 5 min:ssa (L,H) Uudelleenkäynnistys autentikaatiopalvelimen kaatuessa 5 min:ssa (M,M) Luottokortin tiedot turvassa % (H,L) 11

12 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. 34 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ä. 35 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)

13 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). 37 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ä 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ä 13

14 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 40 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 41 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 42 14

15 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 43 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 44 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) 45 15

16 Kysyttävää? 46 16

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

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

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

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

Kevät 2016 Arkkitehtuurin arviointi, ATAM. Ohjelmistoarkkitehtuurit 2016

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

Ohjelmistoarkkitehtuuri

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

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

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

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

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

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

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

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

6. Arkkitehtuurityylit

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

2 Ohjelmistoarkkitehtuurien kuvaus

2 Ohjelmistoarkkitehtuurien kuvaus 2 Ohjelmistoarkkitehtuurien kuvaus 2.1 Arkkitehtuurikuvauksen merkityksestä 2.2 Arkkitehtuurin kuvaukseen liittyvät käsitteet 2.3 Arkkitehtuurikuvaukset eri tasoilla 2.4 Arkkitehtuurinäkymät ja kuvaustyypit

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

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

6. Arkkitehtuurityylit

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

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

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

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

Ohjelmistoarkkitehtuurit Johannes Koskinen. Osittavat arkkitehtuurityylit

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

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

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

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

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

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

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

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

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

Onnistunut Vaatimuspohjainen Testaus

Onnistunut Vaatimuspohjainen Testaus Onnistunut Vaatimuspohjainen Testaus Kari Alho Solution Architect Nohau Solutions, Finland Sisältö Mitä on vaatimuspohjainen testaus? Vaatimusten ymmärtämisen haasteet Testitapausten generointi Työkalujen

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

Ohjelmistoarkkitehtuurit 2016. Kevät 2016 -käytäntöjä

Ohjelmistoarkkitehtuurit 2016. Kevät 2016 -käytäntöjä Ohjelmistoarkkitehtuurit Kevät 2016 -käytäntöjä Samuel Lahtinen http://www.cs.tut.fi/~ohar/ 13.1.2016 1 Tervetuloa Tampereen teknillinen yliopisto, Oulun yliopisto, Turun yliopisto 13.1.2016 2 Tiedonvälitys

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

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

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

10. Tuoterunkoarkkitehtuurit

10. Tuoterunkoarkkitehtuurit 10. Tuoterunkoarkkitehtuurit Johdanto Näkökulmat tuoterunkoihin perustuvaan ohjelmistokehitykseen: liiketoiminta, organisaatio, prosessi, tekninen Tuoterunkojen etuja ja ongelmia 1 Uudelleenkäytt yttö

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. Syksy 2008

Ohjelmistoarkkitehtuurit. Syksy 2008 Ohjelmistoarkkitehtuurit Syksy 2008 Kai Koskimies 1 Tervetuloa Kuopion yliopisto, Oulun yliopisto, Tampereen yliopisto, Teknillinen korkeakoulu, Turun yliopisto, Vaasan yliopisto, Tampereen teknillinen

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

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

Viestinvälitysarkkitehtuurit Lähtökohta:

Viestinvälitysarkkitehtuurit Lähtökohta: Ohjelmistoarkkitehtuurit Kevät 2012-2013 Johannes Koskinen http://www.cs.tut.fi/~ohar/ 1 Viestinvälitysarkkitehtuurit Lähtökohta: Järjestelmä koostuu keskenään kommunikoivista komponenteista, mahdollisesti

Lisätiedot

Järjestelmäarkkitehtuuri (TK081702) Lähtökohta. Integroinnin tavoitteet

Järjestelmäarkkitehtuuri (TK081702) Lähtökohta. Integroinnin tavoitteet Järjestelmäarkkitehtuuri (TK081702) Integraation tavoitteita Lähtökohta Web-palvelut Asiakasrekisteri ERP, Tuotannon ohjaus Tuotanto Myynti Intranet Extranet? CRM Johdon tuki Henkilöstö Kirjanpito Palkanlaskenta

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

TeliaSonera Identity and Access Management

TeliaSonera Identity and Access Management TeliaSonera Identity and Access Management 22.10.2009 EMC Forum Juha Arjoranta 1 TeliaSonera Identity and Access Management Alustus käyttövaltuushallintaan IAM kokonaisratkaisun elementit Nykytilaa ja

Lisätiedot

Ohjelmistojen testaus

Ohjelmistojen testaus Ohjelmistojen testaus Juha Taina 1. Perusteet (P&Y:1-4) Kurinalainen insinöörityö sisältää suunnittelun ja rakentamisen lisäksi välttämättä tehtäviä, joiden tarkoitus on tunnistaa ja poistaa keskeneräisestä

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

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

Siltatiedon tarkkuustason määrittäminen Taitorakennerekisterissä. Maria Vinter

Siltatiedon tarkkuustason määrittäminen Taitorakennerekisterissä. Maria Vinter Siltatiedon tarkkuustason määrittäminen Taitorakennerekisterissä Maria Vinter 2 Taustaa Diplomityö: Tietomallinnuksen hyödyntäminen siltojen ylläpidossa, valmis 09/2017 https://julkaisut.liikennevirasto.fi/pdf8/opin_2017-03_tietomallinnuksen_hyodyntaminen_web.pdf

Lisätiedot

Testaus osana ohjelmistojen elinkaarta II

Testaus osana ohjelmistojen elinkaarta II Testaus osana ohjelmistojen elinkaarta II Luento 4 Antti-Pekka Tuovinen www.cs.helsinki.fi 21 March 2013 1 Oppimistavoitteet Ohjelmistoversioiden testaus Testityyppejä www.cs.helsinki.fi 21 March 2013

Lisätiedot