9. Ohjelmistoarkkitehtuurien arviointi
|
|
- Timo Väänänen
- 7 vuotta sitten
- Katselukertoja:
Transkriptio
1 9. Ohjelmistoarkkitehtuurien arviointi Johdanto ATAM-menetelmä Esimerkki Käytännön kokemuksia ja ongelmia Yhteenveto Ohjelmistoarkkitehtuurit Syksy 2010 TTY Ohjelmistotekniikka 1
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 Ohjelmistoarkkitehtuurit Syksy 2010 TTY Ohjelmistotekniikka 2
3 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ää Ohjelmistoarkkitehtuurit Syksy 2010 TTY Ohjelmistotekniikka 3
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 Ohjelmistoarkkitehtuurit Syksy 2010 TTY Ohjelmistotekniikka
5 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) Ohjelmistoarkkitehtuurit Syksy 2010 TTY Ohjelmistotekniikka 5
6 Arkkitehtuurin rakentaminen kehitysprosessissa Laatuvaatimukset Arkkitehtuurin kannalta merkittävät vaatimukset Vaatimusanalyysi Keskeiset toiminnalliset vaatimukset Ympäristövaatimukset Alustava arkkitehtuuri Alustava arkkitehtuurisuunnittelu Laatuvaatimuksen huomiointi Rajoitteet Yleisten ratkaisumallien soveltaminen Arkkitehtuurimuunnos ei OK OK Toissijaiset toiminnalliset vaatimukset Kaikki käsitelty Yksityiskohtainen suunnittelu Arkkitehtuurin arviointi Arkkitehtuuri Ohjelmistoarkkitehtuurit Syksy 2010 TTY Ohjelmistotekniikka 6
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 Ohjelmistoarkkitehtuurit Syksy 2010 TTY Ohjelmistotekniikka 7
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 9126 Ohjelmistoarkkitehtuurit Syksy 2010 TTY Ohjelmistotekniikka 8
9 ISO 9126 laatukehikko Ohjelmistoarkkitehtuurit Syksy 2010 TTY Ohjelmistotekniikka 9
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 Ohjelmistoarkkitehtuurit Syksy 2010 TTY Ohjelmistotekniikka 10
11 Arkkitehtuuri ja liiketoimintatavoitteet Ohjelmistoarkkitehtuurit Syksy 2010 TTY Ohjelmistotekniikka 11
12 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? Ohjelmistoarkkitehtuurit Syksy 2010 TTY Ohjelmistotekniikka 12
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 Ohjelmistoarkkitehtuurit Syksy 2010 TTY Ohjelmistotekniikka 13
14 Ohjelmistoarkkitehtuurien arvioinnin ongelma? Laatuvaatimukset Ohjelmistoarkkitehtuuri Ohjelmistoarkkitehtuurit Syksy 2010 TTY Ohjelmistotekniikka 14
15 Laatuvaatimukset tulevat sidosryhmiltä Hyvä suorituskyky, luotettava, hyvä käytettävyys Helposti ylläpidettävä, siirrettävä Loppukäyttäjä Ylläpitäjä Ohjelmistoarkkitehtuurit Syksy 2010 TTY Ohjelmistotekniikka 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 ne, anna kullekin tarkennetulle laatuominaisuudelle esimerkkitilanne, ja tutki täyttyykö ko. laatuominaisuus tässä esimerkkitilanteessa Ohjelmistoarkkitehtuurit Syksy 2010 TTY Ohjelmistotekniikka 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 Ohjelmistoarkkitehtuurit Syksy 2010 TTY Ohjelmistotekniikka 17
18 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ä Ohjelmistoarkkitehtuurit Syksy 2010 TTY Ohjelmistotekniikka 18
19 Analysointityökalujen hyödyntäminen Olemassaolevan 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ä Ohjelmistoarkkitehtuurit Syksy 2010 TTY Ohjelmistotekniikka 19
20 Esimerkki (Columbus): koodin kopiointi Ohjelmistoarkkitehtuurit Syksy 2010 TTY Ohjelmistotekniikka 20
21 Ohjelmistoarkkitehtuurien arvioinnin ongelman ratkaisu: skenaariopohjainen arviointi? Vaatimusten tarkennus Skenaariot Analyysi Laatuvaatimukset Ohjelmistoarkkitehtuuri Arkkitehtuuriratkaisut Ratkaisujen identifiointi Ohjelmistoarkkitehtuurit Syksy 2010 TTY Ohjelmistotekniikka 21
22 Ohjelmistoarkkitehtuurien arvioinnin ongelman ratkaisu: 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? Ohjelmistoarkkitehtuurit Syksy 2010 TTY Ohjelmistotekniikka 22
23 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 Ohjelmistoarkkitehtuurit Syksy 2010 TTY Ohjelmistotekniikka 23
24 ATAM tietovuo Len Bass Ohjelmistoarkkitehtuurit Syksy 2010 TTY Ohjelmistotekniikka 24
25 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 Ohjelmistoarkkitehtuurit Syksy 2010 TTY Ohjelmistotekniikka
26 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 Ohjelmistoarkkitehtuurit Syksy 2010 TTY Ohjelmistotekniikka
27 Skenaario esimerkki Ohjelmistoarkkitehtuurit Syksy 2010 TTY Ohjelmistotekniikka 27
28 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ä Ohjelmistoarkkitehtuurit Syksy 2010 TTY Ohjelmistotekniikka 28
29 Harjoitus Anna muunneltavuuteen liittyvä skenaario matkatavaroiden käsittelyjärjestelmälle Anna turvallisuuteen liittyvä skenaario matkatavaroiden käsittelyjärjestelmälle Ohjelmistoarkkitehtuurit Syksy 2010 TTY Ohjelmistotekniikka 29
30 laatuominaisuudet Suorituskyky Esimerkki: laatupuu tarkennukset Transaktioiden Käsittely Vasteaika skenaariot Käsittelee 1000 palvelupyyntöä/sek. (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) Ohjelmistoarkkitehtuurit Syksy 2010 TTY Ohjelmistotekniikka
31 Herkkyyskohta Herkkyyskohta = arkkitehtuuriratkaisu, joka on kriittinen jonkin laatuominaisuuden saavuttamisen kannalta. Esimerkki: MVC-mallin käyttö GUI arkkitehtuurissa on olennaista järjestelmän siirrettävyyden kannalta. Ohjelmistoarkkitehtuurit Syksy 2010 TTY Ohjelmistotekniikka 31
32 Tasapainokohta Tasapainokohta = herkkyyskohta, joka koskee useaa laatuominaisuutta (yleensä vastakkaisiin suuntiin) Esimerkki: XML:n käyttö syöttöformaattina parantaa järjestelmän integroitavuutta mutta heikentää sen suorituskykyä. Ohjelmistoarkkitehtuurit Syksy 2010 TTY Ohjelmistotekniikka 32
33 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). Ohjelmistoarkkitehtuurit Syksy 2010 TTY Ohjelmistotekniikka 33
34 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). Ohjelmistoarkkitehtuurit Syksy 2010 TTY Ohjelmistotekniikka 34
35 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ä Ohjelmistoarkkitehtuurit Syksy 2010 TTY Ohjelmistotekniikka
36 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ä Ohjelmistoarkkitehtuurit Syksy 2010 TTY Ohjelmistotekniikka
37 Päivä 1 ATAM prosessi 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 Ohjelmistoarkkitehtuurit Syksy 2010 TTY Ohjelmistotekniikka 37
38 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 Ohjelmistoarkkitehtuurit Syksy 2010 TTY Ohjelmistotekniikka 38
39 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 Ohjelmistoarkkitehtuurit Syksy 2010 TTY Ohjelmistotekniikka 39
40 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 Ohjelmistoarkkitehtuurit Syksy 2010 TTY Ohjelmistotekniikka 40
41 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 Ohjelmistoarkkitehtuurit Syksy 2010 TTY Ohjelmistotekniikka 41
42 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) Ohjelmistoarkkitehtuurit Syksy 2010 TTY Ohjelmistotekniikka 42
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ätiedotOhjelmistoarkkitehtuurit 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ätiedotOhjelmistoarkkitehtuurien 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ätiedotKevä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ätiedotKevä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ätiedot7. 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ätiedot9. 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ätiedotOhar-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ätiedotEtukäteistehtävää
ATAM-ohjeistusta Etukäteistehtävää Valmistautukaa huolella, tutustukaa materiaaliin etukäteen. Miettikää kysymyksiä arkkitehtuurista. Valitkaa roolit, arvioijaporukassa kirjuriksi kaveri, joka keskittyy
LisätiedotITK130 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ätiedotSytyke 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ätiedotOhjelmistoarkkitehtuurit, 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ätiedotEsimerkki: 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ätiedotSuunnitteluratkaisut 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ätiedotOhjelmistoarkkitehtuurit. 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ätiedotOhjelmistoarkkitehtuurit 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ätiedotArkkitehtuurin arviointi
Arkkitehtuurin arviointi Luento 7 1 Oppimistavoitteet Arkkitehtuurin arvioinnin tarkoitus Arviointimenetelmät ATAM DCAR ATAM esimerkkinä menetelmistä 2 ARKKITEHTUURIN ARVIOINTI 3 Arkkitehtuurin arviointi
LisätiedotLaatukustannukset. 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ätiedotLaadun 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ätiedotLaadun 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ätiedot1.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ätiedotYleiskuvaus - 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ätiedotOhjelmistoarkkitehtuurit, syksy
Oppimistavoitteet Ohjelmistoarkkitehtuurit Luento 13 Mitä, miksi, milloin? Arviointimenetelmiä Skenaariopohjaiset menetelmät, suunnittelupäätöksiin kohdistuva menetelmä Ketterä arkkitehtuurin arviointi
LisätiedotOhjelmistoarkkitehtuurit 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ätiedotTietojä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ätiedotArkkitehtuurien 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ätiedotOsittavat arkkitehtuurityylit. Palveluihin perustuvat arkkitehtuurityylit. Erikoisarkkitehtuurityylit
6. Arkkitehtuurityylit Osittavat arkkitehtuurityylit Kerrosarkkitehtuurit Tietovuoarkkitehtuurit Palveluihin perustuvat arkkitehtuurityylit Asiakas-palvelin arkkitehtuurit Viestinvälitysarkkitehtuurit
Lisätiedot1 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ätiedot1 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ätiedotOhjelmistoarkkitehtuuri
Ohjelmistoarkkitehtuurien ylläpito Arkkitehtuurityylejä ja laatuvaatimuksia Arkkitehtuurin uudistaminen Arkkitehtuurin uudistamisen malleja Arkkitehtuurin arviointi TTY Ohjelmistotekniikka 1 Ohjelmistoarkkitehtuuri
LisätiedotISO/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ätiedotDecision-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ätiedot1 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ätiedot9. 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ätiedotOhjelmistojen 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ätiedotDecision-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ätiedotSisää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ätiedotYleisiä 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ätiedotOhjelmiston 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ätiedot1 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ätiedotCopyright 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ätiedot10. 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ätiedotArkkitehti?
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ätiedotJohdantoluento. 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ätiedotVanhan 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ätiedotKUNTIEN 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ätiedotSisää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ätiedotLuento 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ätiedotTOIMINNALLINEN 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ätiedotToimilohkojen 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ätiedotArkkitehtuurikuvaus. 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ätiedot6. Arkkitehtuurityylit
6. Arkkitehtuurityylit Osittavat arkkitehtuurityylit Kerrosarkkitehtuurit (rakenteen ositus) Tietovuoarkkitehtuurit (toiminnan ositus) Palveluihin perustuvat arkkitehtuurityylit Asiakas-palvelin arkkitehtuurit
LisätiedotProjektin 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ätiedot10. 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ätiedot6. Arkkitehtuurityylit
6. Arkkitehtuurityylit Osittavat arkkitehtuurityylit - Kerrosarkkitehtuurit - Tietovuoarkkitehtuurit Palveluihin perustuvat arkkitehtuurityylit - Asiakas-palvelin arkkitehtuurit - Viestinvälitysarkkitehtuurit
Lisätiedot2 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ätiedot7. Tuoterunkoarkkitehtuurit
7. Tuoterunkoarkkitehtuurit Johdanto Näkökulmat tuoterunkoihin perustuvaan ohjelmistokehitykseen Kerrostyyli tuoterunkoarkkitehtuureille Tuoterunkojen etuja ja ongelmia 1 Uudelleenkäytt yttö opportunistinen:
Lisätiedot1 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ätiedotJä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ätiedotLuento 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ätiedotTestauksen 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ätiedotBosch-malli. Kolme vaihetta. Termistöä. Ohjelm!toarkkitehtuu"n
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ätiedotPlugIT / 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ätiedotDecision-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ätiedotArkkitehtuurityylejä 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ätiedotOhjelmistoarkkitehtuurit. 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ätiedotOhjelmiston 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ätiedot7 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ätiedotKansallinen 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ätiedotOhjelmistoprosessit 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ätiedotOhjelmistoarkkitehtuurit 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ätiedotKä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ätiedotOhjelmistoarkkitehtuurit. Syksy 2008
Ohjelmistoarkkitehtuurit Syksy 2008 Kai Koskimies 1 Tervetuloa Kuopion yliopisto, Oulun yliopisto, Tampereen yliopisto, Teknillinen korkeakoulu, Turun yliopisto, Vaasan yliopisto, Tampereen teknillinen
LisätiedotAluksi. 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ätiedotKä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ätiedotOhjelmistoarkkitehtuurit Syksy 2009 TTY Ohjelmistotekniikka 1
Ohjelmistoarkkitehtuurit Syksy 2009 Kai Koskimies Ohjelmistoarkkitehtuurit Syksy 2009 TTY Ohjelmistotekniikka 1 Tervetuloa Kuopion yliopisto, Oulun yliopisto (Kajaani), Tampereen yliopisto, Turun yliopisto,
LisätiedotYhteisö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ätiedotOhjelmistoprojektien 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ätiedotUudelleenkä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ätiedotOhjelmistotekniikka: Luento 6
Ohjelmistotekniikka: Luento 6 Jouni Lappalainen Luku 8: Suunnittelutekniikat suunnittelun käsitteet suunnittelumalli (design model) arkkitehtuuri, rajapinnat, komponenttitaso, sijoitustaso Luku 9: Arkkitehtuurisuunnittelu
LisätiedotDarwin: 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ätiedotOnnistunut 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ätiedotStudio 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ätiedotMuunneltavuuden 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ätiedotEnnustamisen 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ätiedotOhjelmistoarkkitehtuurit, 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ätiedotViestinvälitysarkkitehtuurit
Viestinvälitysarkkitehtuurit Lähtökohta: Järjestelmä koostuu keskenään kommunikoivista komponenteista, mahdollisesti hajautettuja Komponenttien palveluja ei tiedetä tarkasti etukäteen Komponentteja ja
Lisätiedot10. Tuoterunkoarkkitehtuurit
10. Tuoterunkoarkkitehtuurit Johdanto Näkökulmat tuoterunkoihin perustuvaan ohjelmistokehitykseen: liiketoiminta, organisaatio, prosessi, tekninen Tuoterunkojen etuja ja ongelmia 1 Uudelleenkäytt yttö
LisätiedotOhjelmistoarkkitehtuurit Syksy 2009 TTY Ohjelmistotekniikka 1
3. Komponentit ja rajapinnat 3.1 Komponenttien idea: ohjelmistotuotannon rationalisointi 3.2 Mikä on ohjelmistokomponentti? 3.3 Komponentit ohjelmistoyksikköinä 3.4 Rajapinnat 3.6 Komponenttien räätälöinti
LisätiedotOHJELMISTOJEN 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ätiedotSuunnitteluvaihe 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ätiedotOhjelmistoarkkitehtuurit 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ätiedotJä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ätiedotOhjelmistoarkkitehtuurit. Syksy 2010
Ohjelmistoarkkitehtuurit Syksy 2010 Kai Koskimies Tervetuloa Oulun yliopisto, Tampereen yliopisto, Turun yliopisto, Tampereen teknillinen yliopisto, Vaasan yliopisto Kurssin tavoitteet Arkkitehtuurin roolin
LisätiedotTeliaSonera 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ätiedotProjektinhallinta: kustannusarvio
Projektinhallinta: kustannusarvio 581259 Ohjelmistotuotanto 339 Ohjelmiston kustannusarviot Yleensä jo projektin tarjouksen osana on jonkinlainen kustannusarvio Projektin tärkeimmät kustannustekijät: työvoimakustannukset
LisätiedotJuha Taina, Marko Salmenkivi ja Kjell Lemström,
Ohjelmiston kustannusarviot Projektinhallinta: kustannusarvio Yleensä jo projektin tarjouksen osana on jonkinlainen kustannusarvio Projektin tärkeimmät kustannustekijät: työvoimakustannukset (ylivoimaisesti
LisätiedotSimulation 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ätiedotSiltatiedon 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ätiedotOhjelmistotekniikka - Luento 2
Ohjelmistotekniikka - Luento 2 Luku 2: Prosessimallit - miten spiraalimalliin päädyttiin - spiraalimallista (R)UP malliin - oman ammattitaidon kehittäminen; PSP ja TSP mallit 1 Luento 2: Prosessimallit
Lisätiedot