Vaatimusmäärittelyt. Luennon tavoitteista. Motivointia. Haikala ja Märijärvi, Ohjelmistotuotanto
|
|
- Ilona Aaltonen
- 6 vuotta sitten
- Katselukertoja:
Transkriptio
1 Vaatimusmäärittelyt Luennon tavoitteista Luennon sisällöstä Motivointia Lähteinä: Haikala ja Märijärvi, Ohjelmistotuotanto Software requirements, styles and techniques, Soren Lauesen. 1
2 Tavoitteista Luentojen jälkeen opiskelijan tulisi osata: Kerätä vaatimuksia erilaisia tekniikoita käyttäen. Käyttää erilaisia vaatimusten esitystekniikoita. Tunnistaa tärkeimmät vaatimuskategoriat. Arvioida vaatimusmäärittelyjen käyttökelpoisuutta ja vaatimusten onnistuneisuutta. 2
3 Sisällöstä Tavoitekalvon asioita. Miksi vaatimuksia kerätään? Vaatimusten muodostamisen ajankohta projekt(e)issa. Käydään lävitse joukko vaatimustenkeruutekniikoita. Vaatimuksia kerätään tai esitetään mm. tiedosta ja sen esitysja käyttötavoista, muusta toiminnallisuudesta, laatuasioista, hallinnollisista asioista. Erilaisia esitystekniikoita on runsaasti: kaikkia ei voi välttämättä soveltaa samaan projektiin. (Mutta kurssilla toki yritetään kokeilla mahdollisimman useaa... ) 3
4 Motivointia Vaatimuksissa tapahtuneet virheet huomattavasti kalliimpia korjata kuin toteutusvaiheessa tehdyt virheet. Tarpeet (ohjelmistolle asetetut) voivat muuttua ajan myötä. Mikäli vaatimusten etsinnässä ja esittämisessä epäonnistuu, voi tehdä yhden projektitoiminnan perusvirheen: antaa ratkaisun väärään ongelmaan. 4
5 Vaatimukset ja projektin vaiheet Ohjelmiston kehitystyö alkaa yleensä analyysi- ja määrittelyvaiheella, jonka tuloksena saadaan mm. vaatimusmäärittely. Vaatimusmäärittely ohjastaa seuraavia vaiheita, kuten suunnitteluvaihetta. 5
6 Keneltä vaatimuksia Vaatimukset saadaan muodostettavan järjestelmän käyttäjiltä ja muilta asianosaisilta. Suunnittelija analysoi tarpeita ja muodostaa niistä johdonmukaisia käyttökelpoisia kokonaisia vaatimuksia. 6
7 Vaatimusten keruun vaikeuksia Vaatimusten muodostaminen voi olla hankalaa asianosaiset eivät välttämättä osaa ilmaista tarpeitansa asianosaiset saattavat pyytää ratkaisuja, jotka eivät vastaa todellisia tarpeita osa tarpeista voi olla keskenään ristiriitaisia uusia toimintatapoja ei välttämättä osata kuvitella uusien ratkaisujen kaikkia vaikutuksia ei välttämättä ymmärretä loppukäyttäjiä ei ole aina käytettävissä (esim. uusi tuote) 7
8 Mistä vaatimuksia yleensä esitetään? datasta käyttäytymisestä laadusta hallinnollisista asioista Myös muista asioista saattaa tulla vaatimuksia tai kommentteja vaatimusmäärittelyihin. 8
9 Datavaatimuksista Vaatimuksia voidaan esittää datalle. varastointi syöttäminen tulostaminen Järjelmän osat voivat myös olla jossain tilassa, ja eri osien keskenäiset suhteet tällöin saattavat edellyttää muilta osilta jotain. 9
10 Käyttäytymisvaatimuksista Kuinka dataa tallennetaan, lasketaan, muunnetaan, välitetään. Lisäksi käyttäytymisvaatimukset kertovat, mitä toimintoja ohjelmasta löytyy. Laadullisista vaatimuksista Laadulliset vaatimukset sisältävät tehokkuuteen, käytettävyyteen ja ylläpitoon liittyviä asioita. 10
11 Hallinnollisista vaatimuksista Hallinnolliset vaatimukset kertovat toimitusajan, lakiin liittyvät asiat ja esimerkiksi kehitysprosessista. Muusta vaatimusmäärittelyjen sisällöstä Vaatimusmäärittelyissä on usein muutakin asiaa kuin mitä edellä on esitetty. Aiemmin jaetut dokumenttipohjat kertovat kohtuu hyvin, minkälaisia asioita vaatimusmäärittely voi pitää sisällään. Lukijan lukemisen helpottaminen on hyvä muistaa. Esimerkiksi sopiva määrä taustatietoja auttaa ymmärtämään, mitkä ovat todelliset tarpeet. 11
12 Kuinka kerätä vaatimuksia? 1. Asianomaisten analyysi. Ketkä ovat asianosaisia? Mitä tavoitteita heillä on? Miksi he panostavat tähän? Mitä riskejä ja kuluja heille koituu? Mitä ratkaisuja ja toimittajia he harkitsevat? 2. (Ryhmä) haastattelu. Tiedon keruuta nykyisistä työtavoista ja ongelmista. 3. Tarkkailu. Käyttäjät eivät aina tiedä, mitä he tekevät ja kuinka. Esimerkiksi jonkin sivun hakeminen tutusta kirjasta käyttäjien mukaan tapahtuu hakemiston avulla lähes aina, vaikka todellisuudessa iso osa selailee suoraan kirjaa kunnes löytää halutun kohdan. 12
13 4. Tehtävä- ja toimintademo. Pyydetään käyttäjiä näyttämään, kuinka tekevät/toimittavat nykyiset tehtävät. (Joskus esittäminen on helpompaa kuin selittäminen.) 5. Dokumenttien tutkiminen. Saadaan esim. tietoa vanhasta datasta. 6. Kyselylomakkeet. Tiedonkeruuta usealta käyttäjältä: saadaan tilastollista näyttöä jostain asiasta, tai sitten mielipiteitä ja ehdotuksia. 7. Aivoriihet. Generoidaan ideoita. 13
14 8. Kohderyhmät (tulevaan keskittyvät ryhmätyöt). Hieman tavoitteellisempaa kuin kohdassa 7). Lähdetään nykykäytännöistä ja yritetään kuvitella tulevia työtapoja. 9. Perustoimintoryhmätyöt (domain workshops). Mitä toimintoja tarvitaan alalla? Kokeneet käyttäjät kertovat työstään. 10. Suunnitteluryhmätyöt. Käyttäjät ja suunnittelijat suunnittelevat jotain yhdessä. Usein käyttöliittymiä. 11. Prototyypit. Lopputuotteen yksinkertaistettu versio. Kuinka se toimisi todellisessa elämässä? 12. Pilottikokeilut. Uuden systeemin käyttöönoton riskien pienentämiseksi. 14
15 13. Samanlaiset yrityksien tutkailut. Voi antaa uusia ideoita. 14. Toimittajakyselyt. Heidän etuihinsa kuuluu antaa ideoita heidän tuotteden myyntiin liittyen. 15. Neuvottelu. Ratkaistaan mahdollisia konflikteja (voivat olla mm. eri asiakasryhmien välillä). 16. Riskianalyysi. Riskien etsintää ja niihin varautumista. Niitä voi etsiä yhdessä asianosaisten kanssa. Kuinka heidän työnsä muuttuu järjestelmän käyttöönoton jälkeen? Mitä muutoksia tarvitaan? Mitä mahdollisia konflikteja heidän mielestään saattaa tulla esille? 15
16 17. Hinta- ja hyötyanalyysi. Voidaan esittää rahana, mutta jako raha- ja laatutekijöihin esiintyy. 18. Tavoite- ja ala-analyysi (goal-domain). (Liike)toimintatavoitteiden ja tehtävien suhde. Tavallaan tarkistustekniikka mutta voi muuttaa vaatimuksia paljon. 19. Ala- ja vaatimusanalyysi (domain-req.). Samanlaista kuin edellisessä kohdassa mutta alemmalla tasolla. 16
17 Yllä olevilla tekniikoilla voi löytää vaatimuksia nykytyölle, nykyisille ongelmille ja saada esille tavoitteita ja avainkysymyksiä. Lisäksi voidaan saada ideoita tulevalle systeemille, hahmottaa realistiset mahdollisuudet ja kartoittaa seurauksia sekä riskejä. Edelleen halutaan saada selville, kuinka projektiin sitoudutaan ja kuinka mahdolliset konfliktit ratkaistaan. Tuloksena saadaan vaatimuksia, prioriteetteja ja tietoa, kuinka täydellisesti vaatimukset ja prioriteetit on onnistuttu kartoittamaan. 17
18 Kuinka esittää vaatimuksia datan (tiedon) suhteen? 1. Tietomalli (data model). Esimerkiksi ER-malli, oliomalli tms. tarpeen mukaan. 2. Tietohakemisto (data dictionary). (TODO, tarkista!) Datan kuvaus tekstinä (aina tietohakemisto ei ole tarpeen, vaan voidaan jättää esim. suunnittelijan huoleksi). 18
19 3. Tietoilmaisut (data expression). Käytetään datan esittämiseen jotain formaalimpaa menetelmää, erityisesti jos datalla on rakennetta, kuten koosteisessa datassa tai protokollissa. Esimerkiksi säännöllisiä lausekkeita tai BNF-notaatiota (Backus-Naur Form). (Jos ei tuttuja, niin tutustu unixin grep-komentoon vaikka aluksi). 4. Virtuaali-ikkunat (virtual windows). Yksinkertaistettuja näyttökuvia, joista löytyy grafiikkaa ja realistista dataa mutta ei esimerkiksi nappuloita saati menuja. 19
20 Kuinka esittää toiminnallisuuden (käyttäytymisen) suhteen vaatimuksia? 1. Ihminen/tietokone - kuka tekee mitäkin? Tässä voi käyttää esimerkiksi yksinkertaisia tietovirtakaavioita, prosessikaavioita ( kaveri ) ja varmaan UMLstä löytyy kasa kaavioita, jotka kelpaavat yhtä hyvin. Saadaan toiminnallisuuden fyysinen malli. Alla olevat kohdat tarkentavat: 2. Kontekstikaaviot. Tuotteen ja sen ympäristön kuvaavat kaaviot näyttävät tuotteen laajuuden. Notaationa jonkinlainen tietovirtakaavio varmaan toimii parhaiten. 20
21 3. Tapahtuma- ja toimintolistat. Tuotteen käsittelemät tapahtumat. Ihmisen+koneen käsittelemät tapahtumat. Päätapahtumat voidaan esittää käyttötapauksina (use cases). Tuotetapahtumia sanotaan usein viesteiksi (messages). 4. Ominaisuusvaatimukset. Esimerkiksi tekstiä tuote laskee/tallentaa/näyttää... (Voi johtaa väärään käyttäjien ja analysoijan turvallisuuden tunteeseen.) 5. Näytöt ja prototyypit. Mitä nappulasta tapahtuu? 21
22 6. Toimintokuvaukset. Rakenteellista tekstiä käyttäjän toimintojen kuvaamiseen. Toiminnot voidaan jakaa koneen ja ihmiseen osuuksiin. Koneen osuudet voidaan esittää esimerkiksi käyttötapauksin (use case). Yhdessä käyttötapauksessa (tai toimintokuvauksessa) voidaan kertoa mm. tapauksen nimi, tarkoitus, esiehto ja laukaisija, esiintymistiheys, kriittisyys, osatapaukset ja muunnelmat. 7. Piirteitä toimintokuvauksista. Toimintojen käytössä pärjättävä ilman hiirtä... 22
23 8. Tehtävät ja tukitoiminnot. Rakenteellista tekstiä, joka kuvaa tehtävät, pääongelmat ja mahdollisen tuen niille. Halutaan selvittää kriittiset asiat. Esim. jos käyttötapauksissa saadaan jokin tehtävät jaettua osatehtäviin, voidaan osatehtävien kohdalla huomata kysymyksiä ja ongelmia, joihin on vastattava. Tekemällä kaksi palstaa, voi vasemmassa olla nuo osatehtävät ja huomatut kysymykset, ja oikealla puolella esimerkkiratkaisuja (jotka myöhemmin projektin edetessä muuttuvat ehdotetuiksi ratkaisuiksi ja lopulta sovituiksi ratkaisuiksi). 23
24 9. Hahmotelmat (skenaariot). Jokin tapaus joka valottaa yhtä tai useampaa toimintoa, tai jotain tiettyä testattavaa tapausta. Näiden avulla pystyy parantamaan käyttäjien ymmärrystä (mutta ei anna vaatimuksia). 10. Käyttötapaukset (use cases). Booch et al. (1999) A use case is a description of a set of sequences of actions, including variants, that a system performs to yield an observable result to an actor. UMLstä löytyy omia kaaviotyyppejä tälle. Kohdan 6 kuvaus kertoo myös käyttötapauksista. Aktiviteettikaavio (jossa näkyy käyttäjä tekemässä kaikenlaista). 24
25 11. Toiminnot datan kanssa. Rakenteellista tekstiä, kuvaavat käyttötapauksien osatoiminnot ja niiden tarvitseman datan. Kuten kohdassa 8, mutta nyt käytössä kolme saraketta: ensimmäiseen osatoiminto, toisessa kuvataan kunkin osatoiminnon näkyvä data ja kolmannessa listataan virtuaali-ikkunat. 12. Tietovirtakaaviot. (DFD, data flow diagram, PSPEC, processing specification, CSPEC, control specification.) Näyttää toiminnot, datan virtaamassa eri toimintojen välillä. Lisäksi mukana saattaa näkyä toimijoita (esim. kaveri -ohjelmisto). 13. Standardit. Nämä tekstinä: tuote tukee standardia xx. 14. Kehitysprosessiin liittyvät vaatimukset. Esimerkiksi vaatimus, että käytetään jotain tiettyä menetelmää vaatimusten keräämiseen. 25
26 Laatuvaatimuksista Kuinka systeemin tulee suorittaa toimintonsa? Millaiset vasteajat? Kuinka helppokäyttöinen sen on oltava? Miten tietoturva? 26
27 Laatutekijät Laatutekijöitä voi kerätä erilaisiin listoihin, joita voi käyttää tarkistuslistoina. Esimerkkinä kolme eri tapaa, McCall ja Matsumoto, ISO 9126 ja IEEE 830. McCall ja Matsumoto: Toiminnallisuus: eheys (turvallisuus), oikeellisuus, luotettavuus, käytettävyys, tehokkuus. Korjattavuus: ylläpidettävyys, testattavuus, joustavuus. Muunnettavuus: siirrettävyys, liitettävyys (muihin systeemeihin), uudelleen käytettävyys (reusability). 27
28 ISO 9126 (vain päätason laatutekijät): Toiminnallisuus, luotettavuus, käytettävyys, tehokkuus, ylläpidettävyys, siirrettävyys, sopivuus (tarkoituksenmukaisuus), mukautuvaisuus ja yhdenmukaisuus sekä uudet osatekijät. IEEE 830: Tehokkuusvaatimukset, ohjelmiston systeemiominaisuudet, luotettavuus, käyttökelpoisuus, turvallisuus, ylläpidettävyys, siirrettävyys ja helppokäyttöisyys. Listoihin voi tarpeen vaatiessa lisätä uusia kohteita. Seuraavilla kalvoilla esitetään tekniikoita, kuinka esittää joitain yllä olevista laatutekijöistä. 28
29 Laatutaulukko (quality grid) Laitetaan valitut laatutekijät riveinä taulukkoon, jonka sarakkeita ovat esim. kriittinen, tärkeä, tavallinen, ei-tärkeä ja sivuutetaan. Esim: kriitt. tärkeä tav. ei-tärkeä sivuut. Toiminnallisuus: eheys (turvallisuus) oikeellisuus luotettavuus 1 käytettävyys 2 tehokkuus 3 Korjattavuus: ylläpidettävyys X X X 29
30 Taulukon jälkeen voi antaa numeroille selitykset, miksi luotettavuus on tärkeää, miksi käytettävyys kriittistä jne. Jos jotain laittaa tavallista tärkeämmäksi, pitäisi löytyä myös asioita, jotka eivät ole yhtä tärkeitä tai jotka sivuutetaan (kaikkeen ei voi panostaa samalla tavalla). Laatua voi parantaa työskentelemällä kovemmin, saamalla lisää rahoitusta, sivuuttamalla merkityksettömät asiat ja käyttämällä parempia tekniikoita. 30
31 Avoimet mittarit ja päämäärät Joskus voi olla vaikeaa valita sopiva mittari (metriikka) laadun mittaamista varten. Tai päättää jostain arvosta. Esimerkiksi jos halutaan ennusteita jostain asiasta, pitäisi päättää, kuinka kauan ennusteen laskemiseen saa käyttää aikaa, ja kuinka tarkkoja ennusteiden pitäisi olla. Joissain tilanteissa toimittajalta voi kysyä noita. Tällöin laskenta-aika jää vaatimuksissa avoimeksi päämääräksi ja ennusteen tarkkuuden mittari avoimeksi mittariksi. 31
32 Planguage-kieli on kehitetty laatutekijöistä keskustelemiseen (Tom Gilb). Se koostuu seuraavista kohdista: Tag (laatutekijä), Gist (tavoitteesta yleisin termein), Scale (mitta-asteikko), Meter (kuinka mitataan), Must, Plan, Wish, Past. Nyt esimerkiksi avoin päämäärä vastaisi plan -kohdan jättämistä auki. 32
33 Kapasiteetti- ja täsmällisyysvaatimukset (tarkkuus-) Yksinkertaisimpia ellei peräti triviaaleja laatutekijöitä, jotka usein unohdetaan. Yhtäaikaisia käyttäjiä 50, kasvaa vuosittain 10%. Täytyy toimia alle 1Mb muistissa. Nimikentässä käytetään 150 merkkiä. Joissain standardeissa tarkkuusvaatimukset ovat osa toiminnallisia vaatimuksia. 33
34 Tehokkuusvaatimukset Vasteajat, huippukuorma, jne. Teknisiä ja psykologisia rajoja. Voidaan ilmaista ylä- ja alarajoina, ja keskimääräisinä arvoina. Monen käyttäjän systeemeissä esimerkiksi max-vasteaikaa ei tulisi määrittää, koska sen takaaminen on vaikeaa, ellei mahdotonta. Sen sijaan 95% rajan käyttö on ok. Esim. että vastaukset saapuvat 2 sekunnissa 95% tapauksista. Tehokkuusvaatimuksia voi esittää myös joukolle toimintoja tai vain kriittisimmille toiminnoille, jos toimintoja on paljon. Joissain useista erillisistä osista koostuvissa systeemeissä (esim. eri toimittajilta) ei aina voi rajoja laittaa lainkaan. 34
35 Käytettävyys Käytettävyysongelmat voidaan havaita käytettävyystesteillä. Vaatimus systeemi on helppokäyttöinen ei toimi vaatimuksena. Parempi olisi esimerkiksi, että 80% uusista käyttäjistä pystyy kirjaamaan henkilötiedot viidessä minuutissa, tekemään tilauksen kymmenessä minuutissa. (Minkä jälkeen kerrotaan, mitä uudella käyttäjällä tarkoitetaan.) Käytettävyyttä voi parantaa tekemällä prototyyppejä, käytettävyystestaamalla prototyyppejä ja suunnittelemalla ja muuntelemalla prototyyppejä. Tuloksena ohjelmointi helpottuu ja asiakastyytyväisyys paranee. Käytettävyystestit on syytä tehdä ennen kuin koodia on aloitettu kirjoittamaan, jo paperinäyttöjen käyttö voi paljastaa osan ongelmista. 35
36 Käytettävyysvaatimukset Voivat olla tai koskea: ongelmalaskureita, tehtävän suoritusaikoja, näppäinten painalluslaskureita, mielipidemittauksia, ymmärtämispisteytyksiä, suunnittelutason vaatimuksia, 36
37 tuotetason vaatimuksia, tyylioppaan noudattamista (guideline adherence) ja tuotantoprosessin vaatimuksia. Luettelon eri kohtien käyttäminen aiheuttaa erilaisia riskejä sekä toimittajalle että asiakkaalle (jotkut kohdista ovat arveluttavia esim. asiakkaan kannalta). 37
38 Turvallisuus Suojauksia väärinkäyttöä ja onnettomuuksia vastaa. Uhkien kartoitusta ja niiden vaikutusten arviointia (turvallisuusriskien arviointia). Omaisuuden suojaamista, tässä yhteydessä datan ja prosessointikyvykkyyden turvaaminen. CIA+A malli: luotettavuus (dataa käytetään vain luvallisiin tarkoituksiin), eheys (datan), saavutettavuus (data näkyvillä vain luvan omaavilla henkilöillä) ja autentikointi (Confidentiality, Integrity, Availability, ja Authenticity). 38
39 Suojautumiskeinoja voivat olla: estäminen, havaitseminen ja korjaaminen. 39
40 Uhkia voivat olla: fyysinen häiriö, onnettomuus, yksinkertainen käyttäjän virhe, ohjelmointivirhe, sabotaasi (tahallinen rikkominen), luvaton kirjautuminen tai salasanojen varastaminen, väärennös, verkon kuuntelu, verkossa liikkuvan datan muuntaminen, ohjelmoitu rikos. Kukin uhista voi kohdistua syöttö-, tallennus- tai tulostusprosesseihin. 40
41 Turvavaatimukset Ensin on syytä arvioida turvallisuusriskit. Toimittajalta voi kysyä, kuinka suojautua uhkiin, joihin liittyy suuren tappion tms. mahdollisuudet. Esim. Tuote suojattu kovalevyn rikkoutumisia vastaan. Arvioidut ongelmat alle kerran sadassa vuodessa. Tuote sisältää firewall-ratkaisun ja virusskannerin. 41
42 Ylläpito Systemaattista puutteiden korjaamista, tuotteen laajentamista ja käyttäjien tiedottaminen ja kouluttamista. Usein erotetaan kolme ylläpitotoimintoa, korjaava ylläpito, ennaltaehkäisevä ylläpito ja täydentävä ylläpito. 42
43 Ylläpitoon liittyy sykli, johon liittyy ongelman raportointi, sen analyysi, päätösvaihtoehtojen kartoitus, vastaus, mahdollisen ratkaisun testaus ja lopulta päätöksen toteuttaminen. 43
44 Lisäksi pitää ratkaista, milloin kyseessä on puutteen tai virheen korjaus (joka ehkä tehdään takuutyönä), ja milloin asiakkaan tulee maksaa muutoksista. Virheitä voivat olla mm. ohjelmointivirhe, vaatimuksen rikkominen, järkevän ja oletetun toiminnon rikkominen (kaikkia vaatimuksia ei voi kirjata) ja ehkä jotkut käytettävyysongelmat. 44
45 Ylläpidettävyysvaatimukset Taattu korjausaika on turvallista asiakkaalle mutta toimittajalle riskialtista. Toimittaja voi veloittaa korkeaa hintaa muutoksista: asiakas voi kysyä hintaa muutosyksikköä kohden. Ylläpidon tehokkuus, tuen ominaisuudet ja kehitysprosessin vaatimuksia. Lisäksi tähän liittyen saatetaan esittää tuotteen mutkikkuuden ja tuotteen ominaisuuksien suhteen vaatimuksia. 45
Projektityö
Projektityö 4.11.2005 Kevään luennot: 13.1 ja 20.1. Kurssin käytäntöjä Vaatimusten määrittelystä Vaatimusten keräämisestä, erilaisia vaatimusluokkia Lähteinä: Haikala ja Märijärvi, Ohjelmistotuotanto,
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ätiedotOhjelmistotuotanto 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ä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ätiedotOhjelmiston vaatimusmäärittely
Ohjelmiston vaatimusmäärittely Ryhmän nimi: Tekijä: Toimeksiantaja: Toimeksiantajan edustaja: Muutospäivämäärä: Versio: Katselmoitu (pvm.): 1 1 Johdanto Tämä luku antaa yleiskuvan koko vaatimusmäärittelydokumentista.
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ä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ätiedotOhjelmistotuotteen hallinnasta
Ohjelmistotuotteen hallinnasta Luennon tavoitteista Luennon sisällöstä Motivointia Lähteinä: Haikala ja Märijärvi, Ohjelmistotuotanto Royce, Software Project Management, A Unified Framework 1 Tavoitteista
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ätiedotYhteenveto. Menettelytavat
Yhteenveto Ohjelmistotuotanto: Luotettavien ja tehokkaiden ohjelmistojärjestelmien tuottamista noudattaen hyviksi havaittuja menettelytapoja. Menettelytavat Prosessimalli (vesiputous/spiraali/kasvattava)
LisätiedotTenttikysymykset. + UML- kaavioiden mallintamistehtävät
Tenttikysymykset 1. Selitä mitä asioita kuuluu tietojärjestelmän käsitteeseen. 2. Selitä kapseloinnin ja tiedon suojauksen periaatteet oliolähestymistavassa ja mitä hyötyä näistä periaatteista on. 3. Selitä
LisätiedotTyön ositusmalleista. Luennon tavoitteista. Motivointia. Walker Royce, Software Project Management, A Unified Framework
Työn ositusmalleista Luennon tavoitteista Luennon sisällöstä Motivointia Lähteinä: Walker Royce, Software Project Management, A Unified Framework 1 Tavoitteista Luentojen jälkeen opiskelijan tulisi osata:
LisätiedotOhjelmistojen mallintaminen. Luento 2, pe 5.11.
Ohjelmistojen mallintaminen Luento 2, pe 5.11. Kertausta Ohjelmistotuotantoprosessin vaiheet: Vaatimusanalyysi- ja määrittely Mitä halutaan? Suunnittelu Miten tehdään? Toteutus Ohjelmointi Testaus Varmistetaan
LisätiedotT Johdatus käyttäjäkeskeiseen tuotekehitykseen Kertausluento
Käyttöliittymät t ja käytettävyys T-121.2100 Johdatus käyttäjäkeskeiseen tuotekehitykseen Kertausluento 1.3.2006 Ohjeet Kirjoita oma nimesi vastauspaperiin Vain yksi vaihtoehto on oikein monivalintakysymyksissä
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ä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ätiedotMäärittely- ja suunnittelumenetelmät
Menetelmädokumentti Määrittely- ja suunnittelumenetelmät Versio Päiväys Tekijä Kuvaus 0.01 5.12.01 Pekka Koskinen Alustava sisällysluettelo 0.1 7.12.01 Pekka Koskinen Ensimmäinen luonnos 1.0 11.12.01 Pekka
LisätiedotProjektityö
Projektityö 24.9.2010 Ohjelmistojen kehitysmalleista Vaatimusten määrittely ja kerääminen Lähteinä (vaatimusten määrittely): Haikala ja Märijärvi, Ohjelmistotuotanto, Talentum, 2005. Luvut 3, 4, 5, 6-10
Lisätiedotkäyttötapaukset mod. testaus
käyttötapaukset Jari Ojasti Nokia email : jari.ojasti@nokia.com puh : 040 5926 312 Kartta hyväksyntä määrittely suunnittelu suunnittelu mod. testaus integrointi sys. testaus Ylläpito koodaus (toteutus)
Lisätiedottsoft Tarkastusmenettelyt ja katselmukset Johdanto Vesa Tenhunen 4.2.2004
Tarkastusmenettelyt ja katselmukset tsoft Vesa Tenhunen 4.2.2004 http://cs.joensuu.fi/tsoft/ Johdanto Yksi tärkeimmistä tekijöistä laadukkaiden ohjelmistojen tuottamisessa on puutteiden aikainen havaitseminen
LisätiedotA4.1 Projektityö, 5 ov.
A4.1 Projektityö, 5 ov. Kurssin esitietovaatimuksia Kurssin tavoitteista Kurssin sisällöstä Luentojen tavoitteista Luentojen sisällöstä Suoritustavoista ja -vaatimuksista Arvostelukriteereistä Motivointia
LisätiedotStandardi IEC Ohjelmisto
Sundcon Oy Standardi IEC 61508 3 Ohjelmisto muutokset Matti Sundquist Sundcon Oy www.sundcon.fi Standardi IEC 61508 3 (1) Standardissa di esitetään vaatimukset niiden tietojen ja menettelytapojen valmisteluun,
LisätiedotT Tietojenkäsittelyopin ohjelmatyö Tietokonegrafiikka-algoritmien visualisointi Vaatimustenhallinta
T-76.115 Tietojenkäsittelyopin ohjelmatyö Sisältö Tämä on dokumentti esittelee tietokonegrafiikkaalgoritmien visualisointijärjestelmän kehitysprojektissa käytettävän vaatimustenhallintamenetelmän. Päivämäärä
LisätiedotProjektiryhmä Tete Työajanseurantajärjestelmä. Riskienhallintasuunnitelma
Projektiryhmä Tete Työajanseurantajärjestelmä T-76.115 Tietojenkäsittelyopin ohjelmatyö/ 2(6) Muutoshistoria Versio PVM Tekijä Kuvaus 0.10 14.10.2003 Miikka Lötjönen Dokumenttipohja (projektisuunnitelman
LisätiedotTAMK Ohjelmistotekniikka G Graafisten käyttöliittymien ohjelmointi Herkko Noponen Osmo Someroja. Harjoitustehtävä 2: Karttasovellus Kartta
TAMK Ohjelmistotekniikka G-04237 Graafisten käyttöliittymien ohjelmointi Harjoitustehtävä 2: Karttasovellus Kartta TAMK Karttasovellus Kartta Sivu 2/8 Sisällysluettelo 1. JOHDANTO...3 2. VAATIMUSMÄÄRITTELY...
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ä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ätiedotOhjelmistojen mallintaminen, mallintaminen ja UML
582104 Ohjelmistojen mallintaminen, mallintaminen ja UML 1 Mallintaminen ja UML Ohjelmistojen mallintamisesta ja kuvaamisesta Oliomallinnus ja UML Käyttötapauskaaviot Luokkakaaviot Sekvenssikaaviot 2 Yleisesti
LisätiedotNimi: Opnro: Harjoitustyön suoritus: ( ) syksy 2006 ( ) syksy 2005 ( ) muu, mikä. 1. Selitä seuraavat termit muutamalla virkkeellä ja/tai kaaviolla:
Harjoitustyön suoritus: ( ) syksy 2006 ( ) syksy 2005 ( ) muu, mikä 1. Selitä seuraavat termit muutamalla virkkeellä ja/tai kaaviolla: a) käytettävyys b) käyttäjäkeskeinen suunnittelu c) luonnollinen kieli
LisätiedotOhjelmistotekniikan menetelmät, UML
582101 - Ohjelmistotekniikan menetelmät, UML 1 Sisältö DFD- ja sidosryhmäkaavioiden kertaus Oliomallinnus UML:än kaaviotyypit 2 Tietovuokaaviot Data flow diagrams, DFD Historiallisesti käytetyin kuvaustekniikka
LisätiedotTä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ätiedotOHJELMISTOTEKNIIKKA LABORATORIOHARJOITUKSEN OHJEET
OHJELMISTOTEKNIIKKA LABORATORIOHARJOITUKSEN OHJEET Laboratorioharjoituksessa on testattavana kaksi ohjelmaa. Harjoituksen päämääränä on löytää mahdollisimman paljon ohjelmistovirheitä testattavista ohjelmista.
LisätiedotHELIA TIKO 25.9.2006 ICT03D Tieto ja tiedon varastointi T.Mikkola, O.Virkki. Tietoturva tiedon varastoinnissa
HELIA TIKO 25.9.2006 ICT03D Tieto ja tiedon varastointi T.Mikkola, O.Virkki Tietoturva tiedon varastoinnissa 1 Sisällysluettelo Miksi Tietoturvaa? Tietoturva vrs. Tietosuoja Uhkia Tietoturvan osa-alueet
LisätiedotUML- mallinnus: Tilakaavio
UML- mallinnus: Tilakaavio Karkea kuvaus UML- kaavioiden käytöstä ohjelmistonkehityksen eri vaiheissa ja tehtävissä. Mallinnus tilakaavioilla Tilakaaviolla kuvataan yhden luokan olioiden tilan muuttumista
LisätiedotTARKASTUSMENETTELYT JA NIIDEN APUVÄLINETUKI
TARKASTUSMENETTELYT JA NIIDEN APUVÄLINETUKI Vesa Tenhunen Tarkastusmenettelyt Keino etsiä puutteita ohjelmakoodeista, dokumenteista ym. ohjelmistoprosessissa syntyvästä materiaalista Voidaan käyttää kaikissa
LisätiedotTIETOKANNAN SUUNNITTELU
TIETOKANNAN SUUNNITTELU HOVI, HUOTARI, LAHDENMÄKI: TIETOKANTOJEN SUUNNITTELU & INDEKSOINTI DOCENDO (2003, 2005) LUKU 2 JOUNI HUOTARI & ARI HOVI TIETOJEN MALLINNUS TIETOJEN MALLINNUKSESTA TIETOKANTAAN Käsiteanalyysin
LisätiedotKurssin tavoitteista uennot. 4.1 Projektityö, 5 ov. Esitietovaatimukset
Kurssin tavoitteista uennot ma ls. 1097, klo 10-12. pe ls. DXI, klo 12-14. uennot ovat viikoilla 40-42. uentojen yhteydessä ei järjestetä erillisiä harjoituksia. Opinto-oppaasta: Opintojakson tavoitteena
LisätiedotDokumentointi ketterissä menetelmissä
Dokumentointi ketterissä menetelmissä Dokumentointi kuuluu ketteriin menetelmiin niin kuin kaikkeen ohjelmistotuotantoon Dokumentointi itsessään yksi vaatimus, jonka prioriteetti pitää arvioida (asiakkaan
LisätiedotProjektityö
Projektityö 21.10.2005 Projektisuunnitelma Työn ositus Projektisuunnitelman sisältö Kurssin luennoitsija ja projektiryhmien ohjaaja: Timo Poranen (email: tp@cs.uta.fi, työhuone: B1042) Kurssin kotisivut:
LisätiedotMiten suunnitella hyvä käyttöliittymä?
Miten suunnitella hyvä käyttöliittymä? 6.5.2010 Timo Jokela Timo Jokela FT (2001), dosentti (Oulun yliopisto 2009) historiaa 1990-luvun alussa VTT:llä käyttöliittymien mallinnusta 1995 Nokia Mobile Phones,
LisätiedotTestaus käsite. Sekalaista testausasiaa. Testauksen käsitteestä. Kattavuusmitat. Jos ajatellaan, että testaus = V&V, voidaan erottaa:
Testaus käsite Sekalaista asiaa Sami Kollanus 15.11.2006 Jos ajatellaan, että = V&V, voidaan erottaa: Staattinen Dynaaminen Toisaalta voidaan määritellä Myersin (1979) mukaan: Testaus on ohjelman suoritusta,
LisätiedotKÄYTTÄJÄKOKEMUKSEN PERUSTEET, TIE-04100, SYKSY 2014. Käyttäjätutkimus ja käsitteellinen suunnittelu. Järjestelmän nimi. versio 1.0
KÄYTTÄJÄKOKEMUKSEN PERUSTEET, TIE-04100, SYKSY 2014 Käyttäjätutkimus ja käsitteellinen suunnittelu Järjestelmän nimi versio 1.0 Jakelu: Tulostettu: 201543 Samuli Hirvonen samuli.hirvonen@student.tut.fi
LisätiedotMiten 333 organisaatiota voi kehittää yhtä yhteistä digitaalista palvelua ja vielä kuunnella kaikkien asiakkaita?
#finnayhdessä Miten 333 organisaatiota voi kehittää yhtä yhteistä digitaalista palvelua ja vielä kuunnella kaikkien asiakkaita? Riitta Peltonen, johtava käytettävyyssuunnittelija, Finnan 5-vuotisseminaari,
LisätiedotKÄYTETTÄVYYSTESTAUS OSANA KETTERÄÄ KEHITYSTÄ
KÄYTETTÄVYYSTESTAUS OSANA KETTERÄÄ KEHITYSTÄ Eeva Kangas 05.11.2015 @FixUi Oy 2013 2015 FIXUI "Autamme yrityksiä suunnittelemaan sellaisia tuotteita, joita ihmiset osaavat ja haluavat käyttää" Käyttäjätutkimukset
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ätiedotMäärittelyvaihe. Projektinhallinta
Määrittelyvaihe Projektinhallinta testaus määrittely suunnittelu ohjelmointi käyttöönotto, testaus tuotteenhallinta laadunvarmistus dokumentointi vaatimustenhallinta Määrittely Määrittely, eli kansanomaisesti
LisätiedotKÄYTETTÄVYYDEN PERUSTEET 1,5op. Käytettävyyden arviointi paperiprototyypeillä Kirsikka Vaajakallio TaiK 18.4.2007
KÄYTETTÄVYYDEN PERUSTEET 1,5op Käytettävyyden arviointi paperiprototyypeillä Kirsikka Vaajakallio TaiK 18.4.2007 1. MÄÄRITTELE 2. TUNNISTA RATKAISU 5. ARVIOI 3. MÄÄRITTELE 4. LUO Aiheena keskiviikkona
LisätiedotT-76.115 Tietojenkäsittelyopin ohjelmatyö Tietokonegrafiikka-algoritmien visualisointi Vaatimustenhallinta
T-76.115 Tietojenkäsittelyopin ohjelmatyö Sisältö Tämä on dokumentti esittelee tietokonegrafiikkaalgoritmien visualisointijärjestelmän kehitysprojektissa käytettävän vaatimustenhallintamenetelmän. Päivämäärä
LisätiedotProjektityö: Mobiiliajopäiväkirja. Mikko Suomalainen
Projektityö: Mobiiliajopäiväkirja Mikko Suomalainen 1. Määritelmä Mobiiliajopäiväkirja on kännyköille suunnattu ajopäiväkirja-sovellus. Sovelluksen pääperiaate on toimia automaattisena ajopäiväkirjana.
LisätiedotGroupDesk Toiminnallinen määrittely
GroupDesk Toiminnallinen määrittely Tilanne: Paikallinen oppilaitos, kuvitteellinen WAMK, tarvitsee ryhmätyöhön soveltuvan sähköisen asioiden hallintajärjestelmän ja ryhmätyöohjelmiston, jonka ajatuksena
LisätiedotHELIA 1 (8) Outi Virkki Tietokantasuunnittelu
HELIA 1 (8) Luento 1 Johdatusta tietokannan suunnitteluun... 2 Tietokantasuunnittelu?... 2 Tietokanta?... 2 Tieto?... 2 Tietokantasuunnittelun tavoite, v.1... 2 Luotettavuus?... 3 Tietokantasuunnittelun
LisätiedotOhjelmointitekniikka lyhyesti Survival Kit 1 Evtek KA ELINKAARIMALLEISTA
Ohjelmointitekniikka lyhyesti Survival Kit. Vesiputousmalli ELINKAARIMALLEISTA. Ohjelmiston elinkaari Ohjelmiston elinkaarella (life cycle) tarkoitetaan aikaa, joka kuluu ohjelmiston kehittämisen aloittamisesta
LisätiedotKäytettävyys verkko-opetuksessa Jussi Mantere
Käytettävyys verkko-opetuksessa 21.8.2002 Jussi Mantere Mitä käytettävyys on? Learnability (opittavuus) Efficiency (tehokkuus) Memorability (muistettavuus) Errors prevented (virheiden tekeminen estetty)
LisätiedotHELIA 1 (11) Outi Virkki Käyttöliittymät ja ohjelmiston suunnittelu
HELIA 1 (11) Luento 4 Käytettävyyden tuottaminen... 2 Käytettävyys ja systeemityöprosessi... 3 Määrittely... 3 Suunnittelu... 3 Toteutus ja testaus... 3 Seuranta... 3 Kriittiset tekijät käytettävyyden
LisätiedotOhjelmoinnin perusteet Y Python
Ohjelmoinnin perusteet Y Python T-106.1208 2.3.2009 T-106.1208 Ohjelmoinnin perusteet Y 2.3.2009 1 / 28 Puhelinluettelo, koodi def lue_puhelinnumerot(): print "Anna lisattavat nimet ja numerot." print
LisätiedotLaatu tietojärjestelmähankkeissa. Tietohallinnon kokemuksia Juha-Pekka Leskinen Atk-päällikkö Eduskunnan kanslia
Laatu tietojärjestelmähankkeissa Tietohallinnon kokemuksia Juha-Pekka Leskinen Atk-päällikkö Eduskunnan kanslia 5.10.2010 Pohdintaa tietojärjestelmien laadusta Mitä on laatu Miten laatua tavoitellaan tietojärjestelmäprojekteissa
LisätiedotVisual Case 2. Miika Kasnio (C9767) 23.4.2008
Visual Case 2 Miika Kasnio (C9767) 23.4.2008 Työn tarkasti: Jouni Huotari 24.4.2008 1 SISÄLTÖ 1. TYÖN LÄHTÖKOHDAT... 2 2. PERUSTIEDOT... 2 3. ASENTAMINEN... 2 4. OMINAISUUDET... 3 4.1. UML-kaaviot... 4
LisätiedotT Johdatus käyttäjäkeskeiseen tuotekehitykseen. suunnitteluprosessissa. Käyttäjän huomiointi. Iteroitu versio paljon kirjoitusvirheitä
Käyttäjäkeskeinen suunnittelu Käyttäjän huomiointi suunnitteluprosessissa Iteroitu versio 1.1 muutettu klo12.10 - paljon kirjoitusvirheitä Käyttäjäkeskeinen suunnittelu Perusidea: käyttäjät huomioidaan
LisätiedotKäyttäjäkeskeinen suunnittelu
Käyttäjäkeskeinen suunnittelu Käyttäjän huomiointi suunnitteluprosessissa Iteroitu versio 1.1 muutettu klo12.10 - paljon kirjoitusvirheitä Käyttäjäkeskeinen suunnittelu Perusidea: käyttäjät huomioidaan
LisätiedotWebOodin käyttöliittymän kehitys
WebOodin käyttöliittymän kehitys Laura Vuorinen 22.2.2008 Kehittämisosasto / Opiskelijarekisteri Taustatietoa Oodista 13 yliopiston yhteinen tietojärjestelmä opiskelijoiden perustiedot, suoritukset ja
Lisätiedot1. Johdanto. Ohjelmistotuotannon ongelmia
1. Johdanto Mitä ohjelmistotuotanto on? ohjelmointi + ohjelmisto + tekniikat + insinööritaito + kurinalainen työskentely Määritelmä (60-luvun ohjelmistokriisi): The establishment and use of sound principles
LisätiedotOhjelmistojen mallintaminen, kurssikoe esimerkkivastauksia
Ohjelmistojen mallintaminen, kurssikoe 15.12. esimerkkivastauksia Tehtävä 1 a: Ohjelmistotuotantoprosessi sisältää yleensä aina seuraavat vaiheet: määrittely, suunnittelu, toteutus, testaus ja ylläpito.
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ätiedotLangattomien verkkojen tietosuojapalvelut
Langattomien verkkojen tietosuojapalvelut Sisältö Työn tausta & tavoitteet Käytetty metodiikka Työn lähtökohdat IEEE 802.11 verkkojen tietoturva Keskeiset tulokset Demonstraatiojärjestelmä Oman työn osuus
LisätiedotSisällys. Ratkaisumallien historia. Ratkaisumalli. Ratkaisumalli [2] Esimerkki: Composite [2] Esimerkki: Composite. Jaakko Vuolasto 25.1.
Sisällys Ratkaisumallien historia Jaakko Vuolasto 25.1.2001! Ratkaisumalli! Christopher Alexander! Ohjelmistotuotannosta arkkitehtuuriin! Henkilöhistoriaa! Ensimmäisiä käyttökokemuksia! Yhteenveto 25.1.2001
LisätiedotTUKIMATERIAALI: Arvosanan kahdeksan alle jäävä osaaminen
1 FYSIIKKA Fysiikan päättöarvioinnin kriteerit arvosanalle 8 ja niitä täydentävä tukimateriaali Opetuksen tavoite Merkitys, arvot ja asenteet T1 kannustaa ja innostaa oppilasta fysiikan opiskeluun T2 ohjata
LisätiedotLinssintarkastusjärjestelmän käyttöliittymän käytettävyyden arviointi
Linssintarkastusjärjestelmän käyttöliittymän käytettävyyden arviointi Diplomityöseminaari 1.3.2005 Kirsi Eulenberger-Karvetti Esityksen rakenne * Työn tausta * Työn tavoitteet * Katsaus käytettävyyteen
LisätiedotKäyttäjäkeskeisyys verkkopalveluissa
Käyttäjäkeskeisyys verkkopalveluissa JHS-keskustelutilaisuus 6. kesäkuuta 2013 Raino Vastamäki raino.vastamaki@adage.fi Käyttäjäkeskeisyys verkkopalveluissa KLO 14.45 15.15 Käytettävyys ja esteettömyys
LisätiedotOhjelmistoprosessit ja ohjelmistojen laatu Kevät Ohjelmistoprosessit ja ohjelmistojen laatu. Projektinhallinnan laadunvarmistus
LAADUNVARMISTUS 135 Projektinhallinnan laadunvarmistus Projektinhallinnan laadunvarmistus tukee ohjelmistoprojektien ohjaus- ja ylläpitotehtäviä. Projektinhallinnan laadunvarmistustehtäviin kuuluvat seuraavat:
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ätiedotMiksi käytettävyys on tärkeää
WWW-suunnittelu Webissä tärkeintä on käytettävyys. Tämä tarkoittaa yksinkertaisesti sitä, että jos käyttäjä ei löydä jotakin tuotetta, hän ei myöskään osta sitä. Webissä asiakas on kuningas, hiiri aseenaan
LisätiedotYhteenvetoa, pieniä laajennuksia, tulevaisuuden haasteita
Yhteenvetoa, pieniä laajennuksia, tulevaisuuden haasteita 581259 Ohjelmistotuotanto 378 Lemström, 2006-2011 581259 Ohjelmistotuotanto Kiitos Tuomolle kuvasta 379 Ohjelmistotuotannon perustehtävät projektinhallinta:
LisätiedotPCI DSS 3.0. Merkittävimmät muutokset Seppo Heikkinen, QSA seppo.heikkinen@nixu.com. 15.1.2014 Nixu 2014 1
PCI DSS 3.0 Merkittävimmät muutokset Seppo Heikkinen, QSA seppo.heikkinen@nixu.com 15.1.2014 Nixu 2014 1 Yleistä PCI DSS standardin kehittämisestä PCI SSC (Payment Card Industry Security Standards Council)
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ätiedotYhdeksän mittaria ohjelmistotuotannon. seuraamiseen. tsoft. Vesa Tenhunen Joensuun yliopisto, TKT:n laitos 15.9.2004. http://cs.joensuu.
Yhdeksän mittaria ohjelmistotuotannon tilan seuraamiseen tsoft Vesa Tenhunen Joensuun yliopisto, TKT:n laitos 15.9.2004 http://cs.joensuu.fi/tsoft/ Yhdeksän mittaria ohjelmistotuotannon tilan seuraamiseen
LisätiedotKÄYTETTÄVYYSPÄIVÄ
KÄYTETTÄVYYSPÄIVÄ 29.3.2007 Anne Pirinen Meeri Mäntylä KÄYTETTÄVYYSPÄIVÄ Aikataulu 9.15-11.30, Ag C134.1 Luento-osuus 11.30-12.15 Lounastauko 12.15-14.00, projektitilat Ryhmätöiden teko 14.15-15.45, Ag
LisätiedotOhjelmistotekniikka - Luento 2 Jouni Lappalainen
Ohjelmistotekniikka - Luento 2 Jouni Lappalainen Luku 2: Prosessimallit - miten spiraalimalliin päädyttiin - spiraalimallista (R)UP malliin - oman ammattitaidon kehittäminen; PSP ja TSP mallit 1 Luento
LisätiedotKäytettävyys ja sen merkitys
Kuvat kirjasta Sinkkonen, Nuutila, Törmä. Helppokäyttöisen verkkopalvelun suunnittelu, 2009 Käytettävyys ja sen merkitys Irmeli Sinkkonen Adage Oy irmeli.sinkkonen@adage.fi www.adage.fi www.adage.fi Sisältö
LisätiedotOffice 2013 - ohjelmiston asennusohje
Office 2013 - ohjelmiston asennusohje Tämän ohjeen kuvakaappaukset on otettu asentaessa ohjelmistoa Windows 7 käyttöjärjestelmää käyttävään koneeseen. Näkymät voivat hieman poiketa, jos sinulla on Windows
Lisätiedot4. Vaatimusanalyysi. Vaatimusanalyysin tavoitteet
4. Vaatimusanalyysi Laadukkaiden ohjelmistojen tuottaminen ei ole helppo tehtävä. Sen lisäksi, että ohjelman täytyy toimia virheettömästi, sen täytyy täyttää sille asetetut implisiittiset ja eksplisiittiset
LisätiedotProjektityö
Projektityö 31.3.2006 Ylläpito-ohje Käyttöohje Loppuraportti - Projektikertomus - loppuraporttin tiivistelmä Projekti CD Kevään henkilökohtainen raportti Projektiesitykset 17.5 Ryhmien palautekeskustelut
LisätiedotOhjelmistojen mallintaminen Unified Modeling Language (UML)
582104 Ohjelmistojen mallintaminen Unified Modeling Language (UML) 1 Olioperustaisuus Olio toimii mallinnuksen perusyksikkönä eri abstraktiotasoilla Järjestelmän rajaus, suunnittelu, ohjelmointi, suoritus..
LisätiedotTIE Ohjelmistojen testaus 2015 Harjoitustyö Vaiheet 1 ja 2. Antti Jääskeläinen Matti Vuori
TIE-21204 Ohjelmistojen testaus 2015 Harjoitustyö Vaiheet 1 ja 2 Antti Jääskeläinen Matti Vuori Työn yleiset järjestelyt 14.9.2015 2 Valmistautuminen Ilmoittaudu kurssille Lue harjoitustyön nettisivut
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ä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ätiedotABB Drives and Controls, 26.05.2015 Koneenrakentajan ja laitetoimittajan yhteistoiminta toiminnallisen turvallisuuden varmistamisessa
ABB Drives and Controls, 26.05.2015 Koneenrakentajan ja laitetoimittajan yhteistoiminta toiminnallisen turvallisuuden varmistamisessa Sisältö 1. Koneenrakentajan haasteita koneiden turvallistamisessa 2.
LisätiedotUutisjärjestelmä. Vaatimusmäärittely. Web-palvelujen kehittäminen. Versio 1.3
Uutisjärjestelmä Vaatimusmäärittely Versio 1.3 Sisällys 1 Muutoshistoria... 4 2 Viitteet... 4 3 Sanasto... 4 3.1 Lyhenteet... 4 3.2 Määritelmät... 4 4 Johdanto...5 4.1 Järjestelmän yleiskuvaus... 5 4.2
LisätiedotAnalyysi, dynaaminen mallintaminen, yhteistoimintakaavio ja sekvenssikaavio
Analyysi, dynaaminen mallintaminen, yhteistoimintakaavio ja sekvenssikaavio Analyysi Tarkentaa ja jäsentää vaatimusmäärittelyä, vastaa kysymykseen MITÄ järjestelmän tulisi tehdä. Suoritetaan seuraavia
LisätiedotKäytettävyys tuotekehityksessä mitä pitäisi osata?
Käytettävyys tuotekehityksessä mitä pitäisi osata? ( mitä tehdä konkreettisesti ja kuinka paljon?) Timo Jokela, FT, dos. Joticon Oy (Oulun yliopisto, Helsingin yliopisto) Käytettävyyseminaari Oulu 15.4.2011
LisätiedotProjektisuunnitelma Viulu
Projektisuunnitelma Viulu Kuusela Johannes Sjöblom Teemu Suominen Osma Ohjelmistotuotantoprojekti Helsinki 23.9.2004 HELSINGIN YLIOPISTO Tietojenkäsittelytieteen laitos Versiohistoria Päivämäärä Versio
LisätiedotLiikkuva-sovellusprojekti
Liikkuva-sovellusprojekti Joel Kivelä Erkki Koskenkorva Mika Lehtinen Oskari Leppäaho Petri Partanen Vaatimusmäärittely Julkinen Versio 010 1322014 Jyväskylän yliopisto Tietotekniikan laitos Jyväskylä
Lisätiedot010627000 Tietoturvan Perusteet Yksittäisen tietokoneen turva
010627000 Tietoturvan Perusteet Yksittäisen tietokoneen turva Pekka Jäppinen 31. lokakuuta 2007 Pekka Jäppinen, Lappeenranta University of Technology: 31. lokakuuta 2007 Tietokone Koostuu raudasta ja ohjelmista
LisätiedotOhjelmistotekniikan menetelmät, kesä 2008
582101 - Ohjelmistotekniikan menetelmät, kesä 2008 1 Ohjelmistotekniikan menetelmät Methods for Software Engineering Perusopintojen pakollinen opintojakso, 4 op Esitietoina edellytetään oliokäsitteistön
LisätiedotREALTIME CUSTOMER INSIGHT. 2015 Wellnator Oy
REALTIME CUSTOMER INSIGHT YMMÄRRÄ ASIAKASTA Asiakastyytyväisyyttä ja asiakaskokemusta mittaamalla saadaan arvokasta tietoa asiakasrajapinnasta. Analysoimalla tätä tietoa ja reagoimalla siihen asiakassuhteet
LisätiedotHAAVOITTUVUUKSIEN HALLINTA RAJOITA HYÖKKÄYSPINTA-ALAASI
HAAVOITTUVUUKSIEN HALLINTA RAJOITA HYÖKKÄYSPINTA-ALAASI VIHOLLISET EIVÄT TARVITSE USEITA HAAVOITTUVUUKSIA YKSI RIITTÄÄ 90 MIN välein löytyy uusia haavoittuvuuksia 8000 haavoittuvuutta julkaistaan joka
LisätiedotAnalyysi, dynaaminen mallintaminen, yhteistoimintakaavio ja sekvenssikaavio
Analyysi, dynaaminen mallintaminen, yhteistoimintakaavio ja sekvenssikaavio Analyysi Tarkentaa ja jäsentää vaatimusmäärittelyä, vastaa kysymykseen MITÄ järjestelmän tulisi tehdä. Suoritetaan seuraavia
LisätiedotKäyttötapausanalyysi ja testaus tsoft
Käyttötapausanalyysi ja testaus tsoft 15.09.2004 http://cs.joensuu.fi/tsoft/ Johdanto Use Case analyysi (käyttötapausanalyysi) on yleisesti käytetty järjestelmälle asetettujen toiminnallisten vaatimusten
LisätiedotAki Taanila LINEAARINEN OPTIMOINTI
Aki Taanila LINEAARINEN OPTIMOINTI 26.4.2011 JOHDANTO Tässä monisteessa esitetään lineaarisen optimoinnin alkeet. Moniste sisältää tarvittavat Excel ohjeet. Viimeisin versio tästä monisteesta ja siihen
LisätiedotPaikkatietojen tietotuotemäärittely
Paikkatietojen tietotuotemäärittely Esityksen sisältö: Mikä on paikkatietotuote? Mikä on paikkatietotuoteseloste? Kuka paikkatietotuotteita määrittelee? Mikä on paikkatietotuoteselosteen sisältö? Mitä
Lisätiedot