Laadunvarmistus, tarkastukset ja testaus
|
|
- Veikko Laakso
- 8 vuotta sitten
- Katselukertoja:
Transkriptio
1 Laadunvarmistus, tarkastukset ja testaus Mitä on laatu? Miten varmistua laadusta? Laatumittaus Testaus Tarkastusmenettely
2 Laatujärjestelmä Liiketoiminta, johtaminen Laatujärjestelmä Hankkeiden hallinta (tuotteen tasolla) Projektinhallinta Projektinhallinta Projektinhallinta määrittely suunnittelu ohjelmointi testaus käyttöönotto, ylläpito tuotteenhallinta laadunvarmistus dokumentointi vaatimustenhallinta...
3 asiakasvaatimukset Prosessi? Vaatimustenhallinta? SWE-Prosessi
4 Esimerkki: pitsoja koteihin toimittava yritys tilaukset valmistus toimitukset tilaaja tilaus tilauksen vastaanotto vastaanotettu tilaus valmista pitsa pitsat toimita pitsa toimitus asiakas Mitenhän tämä poikkeaa ohjelmistohankkeesta?
5 Prosessi
6 Laatu ja laatujärjestelmä Termi laatu on omiaan herättämään tunneperäisiä reaktioita. Onko laatu virheettömyyttä, mitä on virheettömyys? Onko laadukkaiden osien summa laadukas? "Määritelmä" Tuotteen kyky täyttää asiakkaan kohtuulliset toiveet ja odotukset. Oikea tuote, oikea hinta, oikeaan aikaan. Laatu on välttämättä aina jossain määrin subjektiivista, so. riippuvainen käyttäjästä Objektiivinen laatu: tuote on siinä mielessä virheetön ja tarkoituksenmukainen, että se on määrittelynsä mukainen. Subjektiivinen laatu: tuote täyttää käyttäjänsä (ja asiakkaan) tuotteeseen kohdistamat odotukset. Eri käyttäjillä on erilaisia odotuksia. Laatujärjestelmä eli laadunhallintajärjestelmä määrittelee yrityksen toimintatavat.
7 Ohjelmiston laatuattribuutit: ISO 9126 Analyzability Changeability Stability Testability Adaptability Installability Co-existence Replaceability Maintainability Time behavior Resource utilization Portability Efficiency ISO 9126 External and internal quality Usability Functionality Reliability Understandability Learnability Operability Attractiveness Suitability Accuracy Interoperability Security Maturity Fault tolerance Recoverability mittausesimerkki
8 Laadun osatekijät standardissa ISO 9126 Toiminnallisuus (functionality) suitability accuracy inteoperability security Luotettavuus (reliability) maturity fault tolerance recoverability Käytettävyys (usability) understandability learnability operability attractiveness Tehokkuus (efficiency) time behaviour resource utilization Ylläpidettävyys (maintainability) analysability changeability stability testability Siirrettävyys (portability) adaptability installability co-existence replaceability
9 Prosessin/laatujärjestelmän raskaus Toimintatapojen tulee olla järjestelmällisiä, mutta toisaalta byrokratia on minimoitava. Prosessin tulee kuitenkin olla tarpeeksi byrokraattinen yleensä hieman byrokraattisempi kuin mitä aluksi luulisi. Järjestelmällisyyden ja byrokratian tarvetta lisäävät hankkeen koko henkilöiden vaihtuvuus kokemus ja ammattitaito ylläpitovaatimukset, järjestelmän arvioitu käyttöaika tuotteen luotettavuus- yms. vaatimukset asiakkaiden vaatimukset, lait, viranomaismääräykset yms.... Suurissa hankkeissa kyky vastata nopeasti muuttuviin asiakastarpeisiin yleensä vähenee. Laatujärjestelmän tulee mahdollistaa eri tilanteisiin sopivat toimintamallit.
10
11 Prosessi Prosessi, täysin epävirallinen määritelmä: systemaattinen toimintatapamalli jonkin tavoitteen saavuttamiseksi koostuu ihmisistä, tehtävistä, järjestelmistä, työkaluista ja menetelmistä sekä toisista prosesseista. Esimerkki Prosesseihin liittyy Tavoitteellisuus: prosesseille määritellään tavoitteet, joiden toteutumista on kyettävä mittaamaan (=tarkoitus, syötteet, tulokset, ohjaus ja mittarit) Ohjeistus: kuvaa prosessin aktiviteetit, toimijat ja vastuut. Näkyvyys: miten voidaan todentaa, että on toimittu prosessin mukaisesti. Suunnitelmallinen toiminnan kehittäminen: tavoitteiden toteutumisen arviointi ja mittaus sekä niihin perustuva toimintatapojen suunnitelmallinen kehittäminen. Omistaja(t): omistajan vastuulla on prosessikehitys, prosessin tehokkuus, mittareiden seuranta, muutosten käyttöönotto, tietojärjestelmäratkaisut... Prosessin tarkoituksena on ensisijaisesti ennustettavuus (?): asiat tehdään samalla tarkoituksenmukaisella tavalla suorittavista ihmisistä ja tilanteesta riippumatta sählääminen vähenee toiminnan ja tuotteiden laatu on (ainakin jossain määrin) ennustettavissa toimintaa voi mitata, ohjata ja ymmärtää. Ohjelmistotalon laadunhallintajärjestelmä määrittelee yleensä muutamia ohjelmistokehitykseen suoraan liittyviä ydinprosesseja, esimerkiksi asiakasprosessi, tuotekehitysprosessi ja ylläpitoprosessi.
12 ...prosessi Kannattaa pitää mielessä, että hyvälläkään prosessilla ei voi korvata ammattitaitoisia ohjelmistokehittäjiä...mutta ammattitaitoiset ohjelmistokehittäjät, joilla on hyvä prosessi, päihittävät aina ammattitaitoiset ilman prosessia toimivat kehittäjät.
13 Prosessien vertailu Vesiputous RUP: Rational unified process CMM: Capability Maturity Model XP: extreme Programming SPICE: ISO Epämuodollinen, joustava ISO 9001 RUP SPICE CMM MIL STD Byrokraattinen XP Scrum iteratiivinen Muutettu (aika paljon) lähteestä Kroll, P. and Kruchten, P., The Rational Unified Process Made Easy. Addison-Wesley (2003) 416pp.
14 G-miehen näkemys softanteosta
15 Menetelmien kehittelijät työssään
16 Not everything that can be counted counts, and not everything that counts can be counted -- Albert Einstein, Laadun mittaaminen Motto: mitä ei mitata, sitä ei voi ohjata Mittarit voidaan karkeasti jakaa kahteen luokkaan Strategiset mittarit: pitkä aikaväli, liiketoimintanäkökulma, lähtökohtana usein ns. tasapainoitettu mittaristo -kehys Operatiiviset mittarit: päivittäistä tietoa päätöksenteon tueksi Tässä keskitytään pääasiassa ohjelmistoprojektiin ja tuotantoprosessiin liittyviin operatiivisiin mittareihin Miksi mitataan Tietoa päätöksenteon tueksi ( missä ollaan ) Miten prosessia on kehitettävä: ymmärtäminen, oppiminen ja kehittäminen Miten tavoitteet on saavutettu Mitä mitataan Tuotetta ( missä ollaan ) Prosessia (miten kehitetään, ymmärtäminen, oppiminen)
17 Mittaamisen ongelmia Mittaaminen aiheuttaa kustannuksia. Käytännössä kovin luotettavia yksittäisiä mittareita ei ole. Asenneongelmat: yleensä ihmiset vastustavat mittareiden käyttöönottoa: "epätarkka", "hukkatyötä", "voi käyttää/tulkita väärin" "mahdotonta ei näitä tuloksia kuitenkaan mihinkään käytetä... Ihmiset sopeuttavat toimintaansa mittareihin ( sitä saa mitä mittaa ). Tulos ei välttämättä muutu. Tuottavuutta mitataan koodirivien määrällä. Virheiden vakavuusaste vaikuttaa palkkaan.
18 Millaisia mittareita Mittaamisen on oltava mahdollisimman automaattista. Mittareita on oltava mahdollisimman vähän, mutta kuitenkin riittävästi. Mittaustulosten hyväksikäyttötavan on oltava kaikilla selvillä. Mittarin väärinkäyttö on vältettävissä. Mittaa mielellään prosessia ja ryhmää, ei yksilöä. Objektiivisuus ja luotettavuus: tulos ei saa olla riippuva mittaajasta tai mittausajankohdasta, mittaukset toistettavissa. Trendit absoluuttisia arvoja tärkeämpiä. Ymmärrettävyys: mistä mittarin arvon muutokset johtuvat. Asiakkaan kannalta mielekäs. Mittarin arvot muutettavissa euroiksi.
19 Tuotteen mittaaminen, esimerkkejä Otetaan pohjaksi ISO standardin jaottelu Toiminnallisuus Toteutetut käyttötapaukset / kaikki käyttötapaukset Läpi menevät järjestelmätestitapaukset / kaikki testitapaukset Luotettavuus Mean time between faults (MTTF) Korjatut virheet / löydetyt virheet Koodianalysaattorin virheilmoitukset Testikattavuusmitat Käytettävyys Asiakaspalaute, asiakastyytyväisyystutkimukset Käytettävyystestit Tehokkuus Vasteajat kuormitustesteissä Prosessorin käyttöaste kuormitustesteissä Vapaan muistin määrä kuormitustesteissä Ylläpidettävyys McCaben syklomaattinen kompleksisuus Maintainability index, lasketaan Halsteadin mitasta, McCaben mitasta, koodirivien määrästä ja kommenttirivien määrästä (ks. esim. Welker 2001). Siirrettävyys? Welker, K.D The Software Maintainability Index Revisited. CrossTalk The Journal of Defense Software Engineering 14, 8, pp Ylisiurua, Hannu, Tuotetiedonhallintajärjestelmän leimasinkomponentin ylläpidettävyyden arviointi. Diplomityö, TTY, 2003
20 Esimerkkejä prosessimittareista Aikataulut: arvioidut ajat, toteutuneet ajat. Katselmoinneissa/testauksessa löytyneet virheet. Aika virheen havaitsemisesta sen korjaamiseen. Virhekustannukset Testauksessa löytyneiden virheiden aiheuttamat lisäkustannukset. Takuuaikaiset korjaukset Laskutuskelvottomat tunnit. Tuottavuus.
21 Liikkeellelähtö Aluksi muutamia selkeitä mittareita: aikataulujen toteutuminen asiakasvirheiden määrä takuutyön määrä asiakastyytyväisyys. Kokemuksen karttuessa mittareita otetaan lisää. Mittaustuloksista tiedotetaan: trendit näkyvissä kahvihuoneen seinällä.
22 Errors in a product project at March Errors found open errors 2001 error estimate open errors estimate
23 Otos yhden laatumittauksen tuloksia Luennot 3.1 Harjoitukset 3.7 Materiaali 3.4 Mielenkiintoni opetettuun aiheeseen lisääntyi kurssin aikana: 3.5 Opettajat ovat ystävällisiä ja ymmärtäväisiä: 4.2 Opettajien antama henkilökohtainen ohjaus on riittävää tehtävien suorittamiseen: 3.8 Harjoitustyö oli relevantti opintojakson kokonaisuuden kannalta: 4.1 Uskon kurssista olevan hyötyä myöhemmissä opinnoissani: 3.9 Opetettava aine on ajankohtainen: 4.1 Opin opintojaksolla paljon: 3.8
24 TASAPAINOTETTU MITTARISTO Balanced Scorecard, BSC Luultavasti yleisimmin käytetty kehys liiketoimintalähtöisten mittareiden määrittelyyn Paljon kirjallisuutta Näkökulmat taloudellinen (= omistajat) (mennyt) asiakas (nykyhetki) prosessi (nykyhetki) henkilöstö (= oppiminen) (tulevaisuus) Kaplan R S and Norton D P (1992) "The balanced scorecard: measures that drive performance", Harvard Business Review Jan Feb pp
25 Prosessin kehittäminen: on vaikeaa tuottavuus kehityshankkeet Miten hallita tilanne projektipaineista huolimatta? muutoksen vakiinnuttaminen? aika Arvaus: suurin osa isoista harppausyrityksistä epäonnistuu
26 Etene riittävän pienin harppauksin tuottavuus Termejä: -SPI, Software Process Improvement -Process Re-Engineering aika
27 Kehittämisen askeleet Kartoitetaan nykytilanne. Tähänkin asti on eletty, ei liian suuria muutoksia kerralla. Priorisoidaan kehitystarpeet. Otetaan ensimmäinen askel... Yksinkertainen malli toimintaprosessista (mitä vaiheita projektiin kuuluu). Usein lähdetään liikkeelle dokumentointimalleista Määrittely- ja suunnitteludokumentit. Projektinhallintaan liittyvä dokumentaatio (projektisuunnitelma, seuranta).
28 Ongelmia Monet hankkeet hiipuvat innostuneen alun jälkeen. Johdon tuki ja sitoutuminen puuttuu. Koulutukseen ei panosteta tarpeeksi. Usko kaikkivoipiin työkaluihin. Liian suuret odotukset. Rima liian korkealla. Liian suuri muutos kerralla. Muutosvastarinta. Ajankäyttö. Cowboy-mentaliteetti. Ei toimintamallia - ei käsitystä ongelmista. Prosessia ei voi ostaa.
29 Frustraatio 1960-luvulta The practice of programming as personal art led to the realization that standards in programming were imperative. Implementing QC was a supreme test of skills in personal relations -- and was not well demonstrated. To the extent that we were seen as imposing standards there was resistance and resentment. Without doubt, we failed in every aspect of personnel relations. In a day when programmers were simply not unemployed and available in the labor market, we experienced more than a 100 percent turnover in programming personnel in a six month period. Matley, B.G., Compu-Then: Before Megabytes. In: Glass, R.L., In the Beginning: Recollections of Software Pioneers, IEEE Computer Science Press (1998) pp (quotation from pages ).
30 Standardeja ISO9001 Tällä hetkellä käytännössä tärkein (ei silti kovin tärkeä?). ISO9001 standardi määrittelee tietyt puitteet laatujärjestelmän kehittämiseksi. Uusin versio vuonna CMMI SEI:n (Software Engineering Institute) perinteinen CMM-malli (Capability Maturity Model) määrittelee viisi kypsyystasoa. Kypsyystasomalli määrittelee asiat, joita kullakin tasolla on kehitettävä seuraavalle tasolle pääsemiseksi. Nykyisin mallin nimi on CMMI ja siitä on kaksi versiota staged representation: perinteinen CMM-malli continuous representation: vastaa ISO standardia SPICE (eli ISO 15504) Muita standardeja Laatupalkintokriteerit ( vuoden 2009 voittaja Viking Line ITIL (~ISO 20000): palveluiden hallinta, yrityksen tietohallinto (Joel test)
31 CMM kypsyystasot Taso 1: Initial Process. Taso 2: Repeatable process. Projektit pystytään viemään läpi suunnitelmien mukaisesti. Taso 3: Defined Process. Prosessi on määritelty, sitä noudatetaan, ja sitä pyritään tehostamaan. Taso 4: Managed Process. Prosessia mitataan ja mittaustuloksia käytetään sen parantamiseen. Taso 5: Optimizing Process. Tietoa kerätään automaattisesti ja sitä käytetään prosessin optimoimiseksi. Millähän tasolla yritykset yleensä ovat?
32 CMM arviointien tuloskehitys
33 Yhteenveto 30 vuoden kokemuksesta What I found was this: The inspection and testing process, defect discovery and repair throughout the development life cycle, seemed to drive success -- delivering a usable system in time. I could not correlate success with programming methods such as design methods, language, or coding practices. A certain number of defects will be introduced regardless. What appears to matter a great deal is the application of professional engineering. By that I mean technical management: establishing precise plans and procedures; defining computer programs in terms of their correctness, not just their development, and evaluating them quantitatively with respect to budgets and schedules; using models; developing a detailed system integration plan; and measuring results scientifically (projects that rely on status reports, such as test cases run, do not fare well). Britcher, R.N., A View from Below. In: Glass, R.L., In the Beginning: Recollections of Software Pioneers, IEEE Computer Science Press (1998) pp (quotation from page 111). (Taitto ja korostukset ijh:n)
34 A quotation of one of the managers, only 2 years before the big disaster at AA "...we have spent 30 years handicrafting computer systems. We like to think we re better at this than most and that our skills in hardware evaluation, project management for software development, and systems integration have given us an important leg up on the competition.
35 Auditointi Auditointi: tarkasteltavasta kohteesta riippumattoman henkilön tekemää laatujärjestelmän arviointia (audit, assessment, review). Auditointi voi olla joko sisäinen tai ulkoinen: sisäinen: yrityksen itse tekemä auditointi ulkoinen: esimerkiksi toisen yrityksen tai kolmannen osapuolen tekemä. Muodollinen tilaisuus, jonka aikana tarkastetaan tuotteen tai toiminnan laatu vertaamalla sitä dokumentaatioon tai standardiin. Toiminnan auditoinnissa toiminnan vertailukohtana on esimerkiksi yrityksen oma laatujärjestelmän kuvaus tai jokin laatustandardi (esimerkiksi ISO 9001).
36 ... auditointi Tehdään, usein määrävälein, suunnitelmallisesti ohjeistukseen verraten (sekä sisäisiä että ulkoisia, ISO9001-vaatimus). Tarkastuksen kohteeksi valitaan yleensä tietty osa laatujärjestelmää. Tulokset dokumentoidaan pöytäkirjaan. Korjaavista toimenpiteistä päätetään esimerkiksi laaturyhmän kokouksessa. Ulkoisen auditoinnin tavoitteita: varmistaa, että toimittaja pystyy toimittamaan tuotteen osoittaa, että toiminta on laatujärjestelmän mukaista (sertifiointi) yritysten välinen benchmarking, oppiminen. Sisäisen auditoinnin tavoitteet: Oman toiminnan vahvuuksien ja heikkouksien tunnistaminen. Kehityskohteiden tunnistaminen. Koulutus. Valmistautuminen ulkoisiin auditointeihin.
37 Mitä auditointi ei ole Ihmisten kritisointia. Esimiesten keino alaisten arvointiin. Poliisitoimintaa, jolla saadaan rosvot kiinni. Mestarointia, jossa auditoija kertoo, miten asiat tulisi hoitaa. Ei myöskään suoraan pyri arvioimaan laatujärjestelmän hyvyyttä / huonoutta.
38 Auditoinnin vaiheet Vastuu Päätös auditoinnista Johto Auditoinnin suunnittelu Auditoija(t) Auditoinnin yleisesittely (aloituskokous) Auditoija(t) Auditointi - dokumenttien tutkiminen (ohjeet, tulosdokumentit) - haastattelut ja toiminnan tarkastelu - havaintojen teko ja kirjaus Auditoija(t) Päätöskokous - tulosten esittely - jatkotoimenpiteet Auditoija(t) Kirjallisen raportin laadinta Auditoija(t) Kehitysssuunnitelman laadinta Korjaavat toimenpiteet Seuranta Johto
39 Auditointi käytännössä Perustuu laatudokumentaatioon ja valittuun standardiin. Auditoija tutkii ensin mahdollisen laatudokumentaation (ohjeistus, dokumentointimallit jne.) ja sen riittävyyden standardeihin nähden. Auditoijan työvälineinä laatudokumentaatio, standardi (esim. ISO 9001), kysymyslistat sekä kynä ja paperi. Oleellista auditoinnissa on käytännön, eli todellisen toiminnan tutkiminen. Auditointi pohjautuu havaintoihin: haastattelut, työvälineiden, -tapojen ja -tulosten tarkastelut. Dokumenttien sisältöön ei yleensä puututa. Toiminnan tarkastelun jälkeen auditoijat kirjoittavat raportin, johon havainnot kirjataan. Raportin pohjalta voidaan laatia suunnitelma kehitystoimenpiteiksi. Johdon tehtävänä on huolehtia korjaavista toimenpiteistä ja suunnitelmien toimeenpanosta.
40 Auditoitavia kohteita Yleiset vaatimukset laatupolitiikka, johdon seuranta organisaatio, sisäiset auditoinnit, korjaavat toimenpiteet koulutus ja -asiakasohjautuvuus. Projektitoiminta projektien organisointi projektien suunnittelu, projektien seuranta..., Tuotteenhallinta: identifiointi, versionhallinta, konfiguraationhallinta ja toimintatavat. Menetelmät, työvälineet, dokumentit, ohjelmakoodi... Laadunohjaus: tarkastukset, katselmukset, testaus, mittaus... Tuotteen toimittaminen asiakkaalle.
41 Testauksen aamunkoitto
42 Määritelmiä Myers Testaus on prosessi, jossa etsitään virheitä ohjelmaa tai sen osaa suorittamalla. Hetzel Testausta ovat kaikki menetelmät, joilla pyritään arvioimaan ohjelmiston jotain ominaisuutta. Testaus on ohjelmiston laadun mittaamista. Craig ja Jaskiel Testaus on ohjelmistotuotantoprosessi, jossa käytetään ja ylläpidetään testwarea tarkoituksena mitata ja parantaa testattavan ohjelmiston laatua. Testware kattaa kaiken testaukseen liittyvän materiaalin: suunnitelmat, testauskoodin, testidatan... >2010? Testaus on spesifiointia (eli siis speksaamista ), virheiden etsimistä ja laadun mittaamista. 1. Myers, G.J., The Art of Software Testing. John Wiley & Sons (1979) 177pp. 2. Hetzel, B., The Complete Guide to Software Testing. QED Information Sciences (1984). 3. Craig, R.D. and Jaskiel, S.P., Systematic Software Testing. Artech House Publishing (2002) 536pp.
43 Jatkuva testaaminen Ennen: virheiden etsimistä Rakenna Testaa Nyt: virheiden etsimistä ja laadun mittaamista Rakenna Suunnittele, rakenna ja ylläpidä testwarea Testaa
44 Esimerkkiraportti testauksen tilanteesta Raportti: The Economic Impacts of Inadequate Infrastructure for Software Testing, May 2002 Ohjelmistovirheiden kustannukset USA:n kansantaloudessa n. $60 miljardia, säästöpotentiaali n. $22 miljardia
45 Tulevaisuus Testaus ja sille asetetut vaatimukset ovat lisääntymässä ja monimutkaistumassa huomattavasti. Ne ovat lähestymässä vaativuudeltaan testattavan ohjelmiston tekemistä => testware engineering. Seurannaisilmiöitä Testware engineering on entistä keskeisempi osa tuotekehityshanketta ja se integroituu aikaisempaa selkeämmin kaikkiin ohjelmistotyön vaiheisiin koko elinkaaren ajan. Testiaineistojen ja -ympäristöjen kehitys- ja ylläpitotyöhön on kehitettävä samantapaisia kurinalaisia ja hyvin määriteltyjä prosesseja ja välineitä, kuin itse ohjelmistotuotantoakin varten on kehitetty. Testaus ei voi enää olla sekundahommaa. Huippuasiantuntijoiden tarve lisääntyy. Osa testaajista on myös hyviä ohjelmoijia. (Ns. apinatestaus ulkoistetaan halvempiin paikkoihin.) Kasvavan regressiotestaustarpeen johdosta testausautomaatio ja työvälineiden käyttö lisääntyy. Testaus liittyy entistä tiiviimmin speksaukseen, ja saattaa tavallaan jopa korvata sen (dokumentoidut testitapaukset voivat toimia speksin korvikkeena). Testauksen testaukseen on kiinnitettävä huomiota.
46 Testauksen määrää ja mutkikkuutta kasvattavia tekijöitä Miksi? koodia pitää syntyä enemmän, nopeammin, tehokkaammin laadukkaammin, ennustettavammin. Tähän on reagoitu tuotantoprosessin muutoksella Iteratiivisuus tuotantoprosessissa Testaustulosten käyttö prosessimittareina, release management Ei-toiminnallisten ominaisuuksien testaus: käytettävyys, luotettavuus, ylläpidettävyys, turvallisuus, suorituskyky, interoperability, konformanssitestaus
47 Testauksen määrää Myös teknologiaan ja toteutustekniikoihin yms. liittyviä tekijöitä Hajautetut sovellukset, monikerrosarkkitehtuurit, Internetsovellukset (.9*.9*.9*.9=~0.66) Komponenttiohjelmointi, EJB,.NET Uudelleenkäyttö, ohjelmistoalustat (platform), sovelluskehykset Tuoteperheet Asiakaskohtaisten versioiden paketointi Järjestelmäintegraatio, EAI (Enterprise Application Integration) Monitoimittajaympäristön hallinta Mobiiliohjelmointi (yhteentoimivuus, käytettävyys, suorituskyky, muistinhallinta) Säikeiden käyttö Sulautetut järjestelmät Testikoodin lisääntyessä sen ylläpidon vaatima työmäärä lisääntyy => samantapaisia haasteita kuin muussakin ohjelmistokehityksessä
48 Testaus virheidenetsintäkeinona ohjelma syöteavaruus ohjelmakoodi tulosavaruus X Y sisäinen tila Johtopäätös? Syöteavaruuden koko ja mahdollisten tilojen määrä on niin valtava, ettei edes pienen ohjelman kattava testaus ei ole käytännössä mahdollista. Reaaliaikajärjestelmän tapauksessa tilanne on kertaluokkaa ongelmallisempi. Testaamalla voi siis osoittaa, että ohjelmassa on virheitä, ei sen virheettömyyttä.
49 Ideaalitilanne speksattu testattu toteutettu speksattu= toteutettu= testattu
50 Testaus Testaus on systemaattista virheiden etsimistä -- ei sattumanvaraista ohjelman kokeilua. Testauksen tarkoitus on osoittaa että ohjelmassa on virheitä. Mitä enemmän virheitä löytyy, sitä onnistuneempi testi on. Virhe on ristiriita spesifikaation ja toteutuksen välillä. Virheiden jäljitys eli debuggaus ei ole testausta. Tehtäviä... Testaussuunnitelman laatiminen. Ensimmäinen versio jo määrittelyvaiheessa. Testauksen tavoitteet kussakin testissä. Testikohtaisesti testitapausten suunnittelu. Testausympäristöjen luonti. Testauksen suoritus. Tulosten tarkastelu.
51 Error, fault, failure Virhe (error): ihmisen tekemä möhläys, esimerkiksi ohjelmointivirhe tai virhe dokumentissa. Kun virheellinen ohjelmankohta suoritetaan (tai koodia puuttuu), se saattaa aiheuttaa vian (fault). Järjestelmä on nyt tilassa, joka ei ole sen määrittelyn mukainen. Vika puolestaan voi aiheuttaa häiriön (failure), joka on vian ilmeneminen järjestelmän ulkoisessa käyttäytymisessä. Kansanomaisesti ilmaisten bugilla tarkoitetaan jotain ylläolevista.
52 Testauksen ongelmia Asenne: testauksella yritetään osoittaa ohjelman toimivuus, ei toimimattomuus. Testauksen aliarvostus: "ne jotka eivät muuta osaa, testaavat". Milloin testaus voidaan lopettaa: kun rahat/aika loppuu? Onko kaikki testattu? Mihin tehdyt korjaukset vaikuttavat? Testien toistaminen korjausten jälkeen (regressiotestauksen työmäärä). Testin toistettavuus (ajastukset ja muut hallitsemattomat ilmiöt), esimerkkejä: osoittimien käyttö (yllättävän usein) reaaliaikajärjestelmä, hajautettu järjestelmä ja graafinen käyttöliittymä.
53 ...testauksen ongelmia Testausympäristön pystyttäminen. Testaustyökalujen vaikutus järjestelmän toimintaan. Järjestelmä on maantieteellisesti laaja (hajautettu). Poikkeamien havaitseminen on vaikeaa (esimerkiksi niiden pienuuden takia) Ei tiedetä, mikä oikean tuloksen pitäisi olla. Tilanteet, jota ei voida testitilanteessa järjestää (ohjelmistoissa on lähes aina tällaisia osia). Tulosten toteaminen oikeaksi, kun järjestelmän toimintaa ei voida seurata ulkopuolelta.
54 V-Malli Määrittely Arkkitehtuurisuunnittelu Moduulisuunnittelu Testauksen suunnittelu ja tulosten verifiointi Moduulitestaus Integrointitestaus Järjestelmätestaus Ohjelmointi Testitapausten suunnittelusta ajoissa on paljon hyötyä, mutta siihen liittyy myös ongelma: voi tulla tehtyä turhaa työtä.
55 Muita testauksen muotoja kenttätestaus hyväksymistestaus alfatestaus betatestaus regressiotestaus release testing käytettävyystestaus suorituskykytestaus...
56 Moduulitestaus Moduulitestaus (module testing, unit testing) varmistaa, että yksittäiset moduulit toimivat määrittelynsä mukaisesti. Ohjelmoija tekee yleensä itse.
57 Integrointitestaus Integrointitestaus testaa moduulien välisiä liittymiä. Testaus etenee usein rinnan moduulitestauksen kanssa joko kokoavasti (bottom up) tai jäsentävästi (top down). Jäsentävässä integroinnissa joudutaan rakentamaan kutsuttavia funktioita varten tynkämoduuleita (test stubs). Kokoavassa vaihtoehdossa tarvitaan usein testipetejä (test bed, test driver), jäsentävässä taas tynkämoduuleita (module stub). Reaaliaikajärjestelmän ohjelma koostuu tavallisesti useista tehtävistä (task, multitasking) => myös tynkäprosessien käyttö on usein hyvä idea. "Big bang on yleensä ongelmallinen.
58 Järjestelmätestaus Järjestelmätestaus aloitetaan usein pintapuolisella sauhutestillä (smoke testing) Järjestelmätestauksessa varmistetaan, että järjestelmä toimii määrittelynsä mukaisesti (ja käyttöohjeensa). Testauksen voi/pitäisi suorittaa ulkopuolinen ryhmä. Virheiden korjaus kallista. Luotettavuus-, toipumis-, turvallisuus- ja kuormitustestit (vasteajat, volyymit). Yhteensopivuus muiden järjestelmien kanssa.
59 Testitapausten valinta Lasilaatikkotestaus Harmaalaatikkotestaus Mustalaatikkotestaus Ekvivalenssiositus: jaetaan syötteet (ja tulosteet) ekvivalenssiluokkiin, mikä tahansa arvo luokassa edustaa koko luokkaa. Valitaan joka luokasta yksi arvo. Raja-arvoanalyysi: Valitaan ekvivalenssiluokista rajatapaukset. Voidaan soveltaa sekä syöteavaruuteen että tulosavaruuteen. Virheenarvaus (tarkastuslista tavallisimmista virheistä). Testattavan yksikön koon kasvaessa siirrytään lasilaatikkotestauksesta mustalaatikkotestaukseen
60 Yhteenveto Testauksen merkitys (ja määrä) on lisääntynyt =>testiautomaation merkitys korostuu => testauksessa erityisosaaminen korostuu. Ammattikuvan ongelma: Kansalaismielipide tuotekehityksen testausporukasta: Testaajat ovat tuotekehityksen pohjasakkaa, vain laatuinsinööri on mitättömämpi. Onko mahdollista saada pätevää väkeä kiinnostumaan testauksesta? Ja aivan viimeiseksi; hyvä testaus ei voi pelastaa huonoa ohjelmaa: Paras keino pitää testauksen määrä kohtuullisena on tuottaa vähemmän virheitä. Jos virheitä kuitenkin tehdään, ne olisi saatava tuotteesta pois mahdollisimman aikaisessa vaiheessa.
61 Tarkastukset ja katselmukset Johdanto: terminologia Tarkastukset Esimerkki kustannusvaikutuksista Tarkastusmenettelyn vaiheet Tarkastuslistat Tarkastusten vaikutus Ongelmat Case Bell Case Ellemtel Case TUT/projektityö
62 Terminologiaa Audit, assessment, arviointi: laatujärjestelmän ja organisaation toiminnan tarkastamista. Management review = johdon katselmus, tarkastetaan projektin tilanne (tai koko laatujärjestelmän tilanne, ISO 9001). Verifiointi, todentaminen: tuote on määrittelynsä mukainen. Validointi, kelpoistaminen: tuote sopii käyttötarkoitukseensa. Virhe (error, fault, failure) väärin, ei speksin mukainen (speksin täydellisyys?) ristiriita puuttuu liikaa Virheiden luokittelu: vakava, lievä, kosmeettinen tms.
63 terminologiaa (Technical) Review = katselmus, tekninen katselmus Tarkoituksena vaiheen päättymisen toteaminen, eli siis tehdä prosessin eteneminen näkyväksi. Tärkeimmissä etapeissa, esimerkiksi määrittely- tai suunnitteluvaiheen päättyessä. Kattaa kokonaisen vaihetuotteen. Paljon osallistujia, myös ulkopuolisia. Inspection = tarkastus: Tarkoituksena virheiden löytäminen. Joustava aikataulutus, vaiheen aikana useita. Tarkastettavana pienehkö kokonaisuus (tai osa laajempaa kokonaisuutta). Muutamia osallistujia 3-6, projektin sisäinen. Walkthrough = läpikäynti Läpikäynti on epämuodollinen tarkastuksen muoto, joka tehdään yleensä vain koodille. Tekijä selittää, mitä hän "luulee ohjelmansa tekevän". Kutsutaan joskus "koodipoliisiksi", koodi selitetään poliisille. Termien katselmus, tarkastus ja läpikäynti käyttö edellä esitetyllä tavalla ei ole vakiintunut.
64 terminologiaa Virtuaalikatselmus: katselmus voidaan tehdä verkossa ilman kokousta. Käytössä useissa avoimen lähdekoodin projekteissa. Avoimen lähdekoodin projektien yhteydessä vertaisarviointityyppinen (peer review) "virtuaali"katselmointi on melko yleisesti käytössä. Pariohjelmointi: ketterissä ohjelmistokehitysmenetelmissä (agile) käytetty menetelmä, jossa koodia muokatessa saman näytön ääressä istuu kaksi henkilöä, eräänlaista reaaliaikaista katselmointia. Arkkitehtuuriarviointiin on kehitetty useita katselmointimenetelmiä (ATAM, SAAM). Rick Kazman, Mark Klein and Paul Clements: ATAM: Method for Architecture Evaluation. Technical report, CMU/SEI-2000-TR-004, ESC-TR
65 Tarkastukset Tarkastusmenettely on systemaattinen yleisesti käytetty ryhmätyöhön perustuva menettely virheiden etsimiseksi mistä tahansa dokumentista ja myös ohjelmakoodista. Miksi käytetään? Tehokkaampi virheenetsimiskeino kuin testaus. Mahdollista löytää 80% virheistä. Virheet löytyvät aikaisemmin. Parantaa etenemisen näkyvyyttä. Toimii tiedonvälityskanavana. Varmistetaan, että kaikki ymmärtävät asiat samalla tavalla. Toimii koulutustilaisuutena. Sitouttaa tuloksiin. Stabiloi speksin.
66 Kuva 2.10 esitutkimus& sopimus määrittely tarkastus katselmus, toimittajan katselmus, asiakas mukana suunnittelu ohjelmointi ja moduulitestaus integrointi järjestelmätestaus aika
67 Virhekustannusten kertautuminen Mitä kauemmin virhe on järjestelmässä, sen kalliimmaksi se tulee. On useasti näytetty toteen, että yli puolet (60%) tuotteesta käytön aikana löytyvistä virheistä on peräisin ohjelmointia edeltävistä vaiheista (määrittely, suunnittelu). Testaukseen ja virheiden poistamiseen kuluu 50-80% projektin ajasta. Ylläpitoon kuluu lisäksi yli puolet elinkaarikustannuksista. Ketterien menetelmien kannattajat ovat kyseenalaistaneet Johtopäätös: tämän virheiden väitteen ennaltaehkäisyyn ja havaitsemiseen ajoissa kannattaa panostaa.
68 Esimerkki: virheiden etsiminen Löytyvät tarkastamalla ja osittain järj. testauksessa testaamalla Löytyvät moduulitestaamalla ja tarkastamalla Löytyvät moduulitestaamalla Moduulitestaus Ei löydy tarkastamalla eikä testaamalla Korjausaika 0.5pv / virhe * 10 = 5 päivää Järjestelmätestaus Korjausaika 2pv / virhe Asiakas * 4 = 8 päivää Ajankäyttö: 5pv + 8pv = 13 päivää
69 Esimerkki: virheiden etsiminen Löytyvät tarkastamalla ja ositain järj. testauksessa tarkastamalla Löytyvät testaamalla ja tarkastamalla Löytyvät moduulitestaamalla Ei löydy tarkastamalla eikä testaamalla Tarkastus Korjausaika 0.2pv / virhe * 12 = 2.4 päivää Moduulitestaus Korjausaika 0.5pv / virhe * 5 = 2.5 päivää Järjestelmätestaus Asiakas Korjausaika 2pv / virhe Ajankäyttö: = n. 5 päivää
70 Ei saa olla Keskeneräinen, Alle 50 sivua. Vaiheet Osallistujat, aikataulu Materiaali jaetaan ja esitellään lyhyesti. 15 min Sovitaan tarkastusistunnosta: aika, roolit. Työvaihe Tarkastettava dokumentti Suunnittelu esittely tarpeen? K Esittely K E Valmistautuminen Tarkastustilaisuus uusintatarkastus? E Korjaus Tekijä korjaa Tarkastuspöytäkirja Max. 2 tuntia Hyväksytty dokumentti Jälkiseuranta Materiaaliin tutustuminen, kirjataan: - "ei ymmärrä" -lista - virhelista - pikkuvirhelista (kirj. virheet) Virheiden analysointi prosessin kehittämiseksi Joku osallistujista yhdessä korjaukset tehneen/tehneiden kanssa
71 Roolit 2-6 henkeä. Moderaattori eli juontaja eli puheenjohtaja: huolehtii aikataulussa pysymisestä ja asian etenemisestä kokouksessa (ei mielellään tekijän linjaesimies). Ohjeita puheenjohtajalle: hillitse selittelyä; huolehdi aikataulussa pysymisestä; estä rönsyily ja liika ideointi; rohkaise/provosoi passiivisia. Tekijä (syytetty :-). Ohjeita tekijälle: älä selittele; älä tuo keskeneräistä tuotetta tarkastettavaksi. Esittelijä: esittelee materiaalia (voi olla tekijä). Sihteeri: kirjaa virheet (voi olla tekijä). Tarkastaja: kaikki toimivat tarkastajina. Muita rooleja: sovellusalueen tai jonkun teknologian asiantuntija, kieliasun tarkastaja, käyttäjänäkökulman edustaja Ohjeita kaikille: valmistaudu huolellisesti; ole ystävällinen, varo loukkaamasta tekijää; pysyttele teknisissä asioissa -- arvioi tuotetta, älä tekijää; anna myös positiivisia kommentteja; osoita ongelmat; älä esitä korjausehdotuksia; anna korjaukset pikkuvirheisiin.
72 Tarkastusistunto Max. 2 tuntia. Pitäisi syntyä synergiaa: löytyy uusia puuteita/virheitä. Ei selitellä ja puolustella. Ei pisteiden keräilyä. Ei syytellä. Tilaisuus ei saa muuttua ideointipalaveriksi. Etsitään virheet -- ei korjata. Sovitaan lopputuloksesta ja jälkiseurannasta. Dokumenttina syntyy tarkastuspöytäkirja, johon tulos kirjataan: osallistujat ajankäyttö / osallistuja hyväksytty / hylätty korjausaikataulu yhteenveto virheistä mahd. seurantamenettely
73 Mitä tarkastetaan? Seuraava lista suunnilleen prioriteettijärjestyksessä. Tarjous, sopimus (ISO 9001). Määrittelydokumentit (toiminnallinen määrittely). Projektisuunnitelma. Suunnitteludokumentit (tekninen määrittely). Testaussuunnitelmat. Koodi. Käyttäjälle menevä dokumentaatio. Koulutusmateriaali, koulutussuunnitelma. Käyttöönottosuunnitelma.
74 Tarkastuslistat Käytetään apuna tarkastuksissa. Laaditaan (ja ylläpidetään) kutakin vaihetuotetta varten kokemusten perusteella. Tarkastuslistat voivat olla projekti/tuotekohtaisesti - dynaamisia (=uusia kohtia lisätään tarkastusten yhteydessä). Esimerkki, opetusohjelman muuttaminen jonkun kurssin osalta Soveltuvuus pääaineeseen, vs. sivuaineet Koulutusohjelman vaihtajat Koulutusohjelman rakenne Rajapinnat muihin kursseihin, päällekkäisyys Kurssien rytmitys lukujärjestykseen Käytettävissä olevat opettajat Laitteet/ohjelmistot Opetustilavaikutukset Kustannusvaikutukset Toimintamallit siirtymäkaudelle Imago ja politiikka Intissä olevat opiskelijat
75 Tarkastusten vaikutuksesta Tarkastusten käyttö muuttaa kustannusjakauman etupainotteisemmaksi. Monet virheet eivät löydy testaamalla Tarkoituksena on löytää virheitä => inhimillisesti ottaen haastava prosessi. Tarkastuksella voidaan löytää tyypillisesti n. 80% virheistä (= enemmän kuin esimerkiksi testaamalla). Tarkastukset yleensä n. 5-15% projektin kokonaistyömäärästä. Tarkastuksilla on myös muita etuja. Varahenkilö Oppiminen Perehtyminen toisten tekemään työhön. Sitoutuminen projektin tuloksiin.
76 Tarkastusten vaikutus työmäärään Ilman tarkastuksia Tarkastusten kanssa Määrittely Määrittely Suunnittelu Suunnittelu Ohjelmointi, moduulitestaus Ohjelmointi, moduulitestaus Integrointi, testaus Integrointi, testaus varsinainen työ virheiden aiheuttama lisätyö
77 Pahimmat ongelmat Pahimmat kompastuskivet: asenteet ja organisointi. Tarkastustilaisuudessa Valmistautumattomuus Perehtymisen työmäärä Motivointi, asenteet Rönsyily Lepsu puheenjohtaja Ideointi, korjailu Työmäärää ei oteta huomioon aikataulutuksessa (varsinkin muiden projektien tarkastuksiin osallistuminen) Liikaa materiaalia
78 Experience with Inspections in Ultra- Large Scale Developments. Raportti Bell-Northern Researchin tarkastusten käyttöönotosta. Toimittaa puhelinkeskuksia, koodin kokonaismäärä 15 miljoonaa riviä. Tuloksia 2.5 miljoonan koodirivin tarkastuksista (rivimäärät eivät sisällä kommentteja). Tarkastus neljän hengen ryhmissä: pj, sihteeri, esittelijä, tekijä. Työteho: virhettä/htt (henkilötyötunti). htt sisältää myös valmisteluun käytetyn ajan. 2-4 kertaa nopeampaa kuin virheiden etsiminen ja korjaaminen testaamalla. Asiakkaan raportoiman virheen korjaus vie keskimäärin 4.5 työpäivää. Tarkastusvauhti 150 riviä tunnissa (Fagan: esittelyssä 500 riviä, valmistautuessa 125 riviä tunnissa ja tarkastuksessa 90 riviä tunnissa).
79 Havaintoja Koodissa aluksi virheitä n kpl tuhatta riviä kohti. Näistä 80% on löydettävissä tarkastamalla (sopivalla vauhdilla). Virheitä, jotka eivät löydy testaamalla turha koodi, standardeja noudattamaton koodi ja kommenteissa olevat virheet.
80 Virheiden poistaminen tarkastamalla koodia on huomattavasti testausta halvempaa. Miksi? Testaus Testin suunnittelu. Testiympäristön pystyttäminen. Testin suorittaminen. Tulosten tarkastaminen => virheet. Virheiden jäljitys (debug). Virheiden korjaus. Tarkastaminen. Yleiskatsaus. Valmistautuminen. Tarkastus. Korjaus: jäljitystä ei tarvita, korjaukset usein ilmeisiä.
81 Ongelmia Tarkastusten tehokkuudesta ei ole käytettävissä todisteita. Tarkastukset vievät paljon aikaa (virheet vievät vielä enemmän). Väärinkäsitykset tarkastustekniikasta: mitä tahansa kommentointia pidetään tarkastuksena. "Low tech" -tekniikan imago, ihmiset luulevat, että testaus ja jäljitys on nopeampaa.
82 Kuva 14.7
OTM viikolla 17 ja 18. Tarkastukset ja katselmukset. terminologiaa
OTM viikolla 17 ja 18 Tarkastukset ja katselmukset Viikko 17 Luennot, maanantai: Tarkastukset, inspections torstai: Testaus Viikkoharjoitukset: artikkeli Frederick P. Brooks, Jr: "No Silver Bullet - Essence
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ä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ä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ätiedotOhjelmistotekniikka kevät 2003 Laatujärjestelmät
Laatujärjestelmät Ohjelmistotekniikka kevät 2003 Prosessiajattelu Sisään Prosessi Ulos ohjaus mittaus Laatujärjestelmät Laatujärjestelmät määrittelevät sen, mitkä prosessit täytyy olla määritelty ei sitä,
LisätiedotTestaaminen ohjelmiston kehitysprosessin aikana
Testaaminen ohjelmiston kehitysprosessin aikana 04.02.2004 http://cs.joensuu.fi/tsoft/ Sisällys 1. Johdanto 2. Yksikkö- ja integrointitestaus 3. Järjestelmätestaus 4. Hyväksymistestaus http://cs.joensuu.fi/tsoft/
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ä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ä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ä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ä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ä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ätiedotKatselmoinnit. review) Katselmoinnit (review( Mitä ovat katselmoinnit? Katselmoinnin määritelmä (IEEE 1988)
Katselmoinnit Johdatus ohjelmistotekniikkaan Sami Kollanus 19.10.2004 Katselmoinnin määritelmä (IEEE 1988) An evaluation of software element(s) or projects status to ascertain discrepancies from planned
LisätiedotOhjelmiston testaus ja laatu. Testaustasot
Ohjelmiston testaus ja laatu Testaustasot Testauksen vaihejako Tarpeet / sopimus Järjestelmätestaus Hyväksymiskoe Määrittely testauksen suunnittelu ja tulosten verifiointi Arkkitehtuurisuunnittelu Moduulisuunnittelu
LisätiedotMenetelmäraportti Ohjelmakoodin tarkastaminen
Menetelmäraportti Ohjelmakoodin tarkastaminen Sisällysluettelo 1. Johdanto...3 2. Menetelmän kuvaus...4 2.1. Tarkastusprosessi...4 2.1.1. Suunnittelu...4 2.1.2. Esittely...5 2.1.3. Valmistautuminen...5
LisätiedotKatselmoinnin määritelmä. Katselmoinnit osa 1. ja vielä ajatuksia katselmoinneista. Katselmointi. Katselmointi, katselmus (review) IEEE Std
Katselmoinnin määritelmä Katselmoinnit osa 1 Sami Kollanus 1.12.2006, katselmus (review) IEEE Std 1028-1988 Ohjelmiston osien tai projektin tilan arviointi (evaluation), jonka tarkoitus on tunnistaa tuotosten
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ätiedotKontrollipolkujen määrä
Testaus Yleistä Testaus on suunnitelmallista virheiden etsimistä Tuotantoprosessissa ohjelmaan jää aina virheitä, käytettävistä menetelmistä huolimatta Hyvät menetelmät, kuten katselmoinnit pienentävät
LisätiedotLAATU, LAADUNVARMISTUS JA f RISKIEN HALLINTA JOUNI HUOTARI ESA SALMIKANGAS PÄIVITETTY 18.1.2011
LAATU, LAADUNVARMISTUS JA f RISKIEN HALLINTA JOUNI HUOTARI ESA SALMIKANGAS PÄIVITETTY 18.1.2011 TEHTÄVÄ Määrittele laatu Mitä riskien hallintaan kuuluu? Jouni Huotari & Esa Salmikangas 2 LAATU JA LAADUNVARMISTUS
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ä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ä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ätiedotTutkittua tietoa. Tutkittua tietoa 1
Tutkittua tietoa T. Dybå, T. Dingsøyr: Empirical Studies of Agile Software Development : A Systematic Review. Information and Software Technology 50, 2008, 833-859. J.E. Hannay, T. Dybå, E. Arisholm, D.I.K.
LisätiedotTestaus-tietoisku: Tärkeimpiä asioita testauksesta projektityökurssilaisille
1(23) Testaus-tietoisku: Tärkeimpiä asioita testauksesta projektityökurssilaisille Matti Vuori, Tampereen teknillinen yliopisto 30.10.2012 Sisällysluettelo 1/2 Esityksen tarkoitus 4 Laatu on tärkeää, ei
LisätiedotFujitsu SPICE Lite. Kimmo Vaikkola Fujitsu Finland Oy Laatu ja liiketoimintatavat. Copyright 2010 FUJITSU
Fujitsu SPICE Lite Kimmo Vaikkola Fujitsu Finland Oy Laatu ja liiketoimintatavat Copyright 2010 FUJITSU Laatu ja prosessit Fujitsussa Laatujärjestelmän rakentaminen ja systemaattinen prosessijohtaminen
LisätiedotOhjelmistotuotanto s
Laadunvarmistustekniikoita Ohjelmistotuotanto 1 testaus (testing) ohjelman suorittamista tarkoituksena löytää virheitä tarkastukset (inspections, reviews) asiantuntijoiden suorittamia dokumentin (voi olla
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ätiedotSYSTEEMITYÖ. Tärkeitä sanoja
SYSTEEMITYÖ Tärkeitä sanoja SYSTEEMITYÖN TÄRKEITÄ SANOJA Laatu (itse tuotteessa ja sen tekemisessä) Dokumentaatio Riskienhallinta Vaatimustenhallinta Uudelleenkäytettävyys Versionhallinta 2 LAATU Parityönä:
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ätiedotOhjelmistotuotanto, s /27/2003
Ohjelmistotuotanto Laatu - useita eri näkemyksiä: klassinen: kaikki tarpeet huomioiva hyvyys tuote- ja hintasidonnainen: mitä kalliimpi sitä parempi tarkoituksenmukaisuus: laadukas tuote sopii tarkoitukseensa
LisätiedotLaadunvarmistustekniikat
Laadunvarmistustekniikat Ohjelmistojen laadunvarmistustekniikoita: testaus (testing) ohjelman suorittamista tarkoituksena löytää virheitä tarkastukset (inspections, reviews) asiantuntijoiden suorittamia
LisätiedotKäyttäjien tunnistaminen ja käyttöoikeuksien hallinta hajautetussa ympäristössä
www.niksula.cs.hut.fi/~jjkankaa// Testauksen loppuraportti v. 1.0 Päivitetty 23.4.2001 klo 19:05 Mikko Viljainen 2 (14) Dokumentin versiohistoria Versio Päivämäärä Tekijä / muutoksen tekijä Selite 1.0
LisätiedotSoftware engineering
Software engineering Alkuperäinen määritelmä: Naur P., Randell B. (eds.): Software Engineering: A Report on A Conference Sponsored by the NATO Science Committee, NATO, 1968: The establishment and use of
LisätiedotTestauspäällikön tarinoita Arto Stenberg
Testauspäällikön tarinoita Arto Stenberg 2.12.2013 A software foundry that helps companies create breakthrough product innovations. We help our clients to: 1. Create new products 2. Scale out their product
LisätiedotOhjelmistojen mallintaminen. Luento 11, 7.12.
Ohjelmistojen mallintaminen Luento 11, 7.12. Viime viikolla... Oliosuunnittelun yleiset periaatteet Single responsibility eli luokilla vain yksi vastuu Program to an interface, not to concrete implementation,
LisätiedotKokonaisvaltainen mittaaminen ohjelmistokehityksen tukena
Kokonaisvaltainen mittaaminen ohjelmistokehityksen tukena Mittaaminen ja ohjelmistotuotanto seminaari 18.04.01 Matias Vierimaa 1 Miksi mitataan? Ohjelmistokehitystä ja lopputuotteen laatua on vaikea arvioida
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ätiedotTestauksen hallinta Testaustyökalut Luento 7 Antti-Pekka Tuovinen
Testauksen hallinta Testaustyökalut Luento 7 Antti-Pekka Tuovinen 23 April 2018 1 Tavoitteet Yleiskuva seuraavista aiheista Testauksen organisointi Testaussuunnittelma Testauksen kustannukset Testausstrategia
LisätiedotISO 9001:2015 JÄRJESTELMÄ- JA PROSESSIAUDITOIN- NIN KYSYMYKSIÄ
ISO 9001:2015 JÄRJESTELMÄ- JA PROSESSIAUDITOIN- NIN KYSYMYKSIÄ IMS Business Solutions Oy, J Moisio 10/ 2016 2.10.2016 IMS Business Solutions Oy 2 ISO 9001:2015 PROSESSIEN AUDITOINTIKYSYMYKSIÄ ISO 9001:2015
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ätiedotTyökalut ohjelmistokehityksen tukena
1 Työkalut ohjelmistokehityksen tukena Johdanto 2 Työkaluja eli ohjelmistotyötä tukevia ohjelmistoja käytetään ohjelmistoalan yrityksissä nykypäivänä paljon. Työkalut auttavat ohjelmistoalan ihmisiä suunnittelemaan
LisätiedotMittaaminen projektipäällikön ja prosessinkehittäjän työkaluna
Mittaaminen projektipäällikön ja prosessinkehittäjän työkaluna Finesse-seminaari 22.03.00 Matias Vierimaa 1 Mittauksen lähtökohdat Mittauksen tulee palvella sekä organisaatiota että projekteja Organisaatiotasolla
LisätiedotOhjelmistoprosessit ja ohjelmistojen laatu Ohjelmistoprosessit ja ohjelmistojen laatu (4op)
581361 Ohjelmistoprosessit ja ohjelmistojen laatu (4op) Ohjelmistojärjestelmien syventävien opintojen kurssi Myös ohjelmistotekniikan profiilin pakollinen kurssi eli ohjelmistotekniikka-aiheisen gradun
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ä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ätiedotVerifioinnin ja validoinnin ero. 7. Verifiointi ja validointi. Verifiointi- ja validointitekniikat. Verifiointi- ja validointitekniikat II
7. Verifiointi ja validointi Verifiointi ja validointi (V&V) on ohjelmistotuotannon työvaihe, missä varmistetaan, että ohjelmisto täyttää sille asetetut implisiittiset ja eksplisiittiset vaatimukset ja
LisätiedotTestausdokumentti. Kivireki. Helsinki Ohjelmistotuotantoprojekti HELSINGIN YLIOPISTO Tietojenkäsittelytieteen laitos
Testausdokumentti Kivireki Helsinki 17.12.2007 Ohjelmistotuotantoprojekti HELSINGIN YLIOPISTO Tietojenkäsittelytieteen laitos Kurssi 581260 Ohjelmistotuotantoprojekti (6 ov) Projektiryhmä Anu Kontio Ilmari
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ätiedotProsessien kehittäminen. Prosessien parantaminen. Eri mallien vertailua. Useita eri malleja. Mitä kehitetään?
Prosessien kehittäminen Prosessien parantaminen Sami Kollanus TJTA330 Ohjelmistotuotanto 21.2.2007 Mitä kehitetään? CMMI, SPICE yms. Miten kehittämishanke saadaan toteutettua? Organisaation kehittämisen
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ätiedotSFS, 27.11 2014 STANDARDIEHDOTUKSEN ISO/DIS 14001 ESITTELY
SFS, 27.11 2014 STANDARDIEHDOTUKSEN ISO/DIS 14001 ESITTELY Anna-Liisa Koskinen SISÄLTÖ Uusi rakenne Uusia määritelmiä Keskeisistä muutoksista 2 ISO 14001 ympäristöjohtamisjärjestelmä ISO 14001 on tunnettu
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ätiedotOhjelmistojen virheistä
Ohjelmistojen virheistä Muutama sana ohjelmistojen virheistä mistä niitä syntyy? Matti Vuori, www.mattivuori.net 2013-09-02 1(8) Sisällysluettelo Ohjelmistojen virheitä: varautumattomuus ongelmiin 3 Ohjelmistojen
LisätiedotHankkeiden vaikuttavuus: Työkaluja hankesuunnittelun tueksi
Ideasta projektiksi - kumppanuushankkeen suunnittelun lähtökohdat Hankkeiden vaikuttavuus: Työkaluja hankesuunnittelun tueksi Erasmus+ -ohjelman hakuneuvonta ammatillisen koulutuksen kumppanuushanketta
LisätiedotTapahtuipa Testaajalle...
Tapahtuipa Testaajalle... - eli testaus tosielämässä 09.10.2007 Juhani Snellman Qentinel Oy 2007 Agenda Minä ja mistä tulen Testauksen konteksti Tapauksia tosielämästä ja työkaluja 2 Minä Juhani Snellman
LisätiedotToiminnan laadunvarmistus SYSTEEMITYÖ. Laatu
Toiminnan laadunvarmistus SYSTEEMITYÖ Laatu SYSTEEMITYÖN TÄRKEITÄ SANOJA Laatu (itse tuotteessa ja sen tekemisessä) Dokumentaatio Riskienhallinta Vaatimustenhallinta Uudelleenkäytettävyys Versionhallinta
LisätiedotSEPA-päiväkirja: Käytettävyystestaus & Heuristinen testaus
SEPA-päiväkirja: Käytettävyystestaus & Heuristinen testaus Lehmus, Auvinen, Pihamaa Johdanto Käyttäjätestauksella tarkoitetaan tuotteen tai sen prototyypin testauttamista todellisilla käyttäjillä. Kehittäjät
LisätiedotLaatukäsikirja - mikä se on ja miten sellainen laaditaan?
Laatukäsikirja - mikä se on ja miten sellainen laaditaan? Matkailun laatu laatukäsikirja osaksi yrityksen sähköistä liiketoimintaa Sähköinen aamuseminaari matkailualan toimijoille 24.8.2010 Riitta Haka
Lisätiedot58160 Ohjelmoinnin harjoitustyö
58160 Ohjelmoinnin harjoitustyö Testaus 30.3.2009 Tuntiop. Sami Nikander sami.nikander@helsinki.fi 58160 Ohjelmoinnin harjoitustyö, Sami Nikander 30.3.2009 1 Testaus Ohjelman systemaattista tutkimista
LisätiedotConvergence of messaging
Convergence of messaging Testaussuunnitelma The Converge Group: Mikko Hiipakka Anssi Johansson Joni Karppinen Olli Pettay Timo Ranta-Ojala Tea Silander Helsinki 20. joulukuuta 2002 HELSINGIN YLIOPISTO
LisätiedotOhjelmistotuotanto, syksy laatu Ohjelmiston laatu
Ohjelmiston laatu Laatu - useita eri näkemyksiä klassinen: kaikki tarpeet huomioiva hyvyys, subjektiivinen tuote ja hintasidonnainen: mitä kallimpi sitä parempi tarkoituksenmukaisuus: laadukas tuote sopii
LisätiedotScrum is Not Enough. Scrum ei riitä. Ari Tanninen & Marko Taipale. Nääsvillen oliopäivä 2009 Tampereen teknillinen yliopisto 9.12.
Scrum is Not Enough Scrum ei riitä Ari Tanninen & Marko Taipale Nääsvillen oliopäivä 2009 Tampereen teknillinen yliopisto 9.12.2009 Ari Tanninen Vanhempi ohjelmistoinsinööri Marko Taipale Teknologiajohtaja,
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ätiedotMittaamisen maailmasta muutamia asioita. Heli Valkeinen, erikoistutkija, TtT TOIMIA-verkoston koordinaattori
Mittaamisen maailmasta muutamia asioita Heli Valkeinen, erikoistutkija, TtT TOIMIA-verkoston koordinaattori SISÄLTÖ 1. Mittari vs. indikaattori vs. menetelmä - mittaaminen 2. Luotettavat mittarit 3. Arvioinnin
LisätiedotProsessiajattelu. Organisaation prosessikuvaus - CMMI. Prosessikuvaukset ja elinkaarimallit. Organisaation prosessien määritys CMMI käytänteet
Organisaation prosessikuvaus - CMMI Prosessikuvaukset ja elinkaarimallit Sami Kollanus TJTA330 Ohjelmistotuotanto 7.2.2007 Level5 Level4 Level3 Requirements Development Technical Solution Product Integration
LisätiedotAvoimen ja yhteisen rajapinnan hallintasuunnitelma v.1.4
Avoimen ja yhteisen rajapinnan hallintasuunnitelma v.1.4 Tämän esityksen sisältö tausta avoimet toimittajakohtaiset rajapinnat (toimittajan hallitsemat rajapinnat) avoimet yhteiset rajapinnat (tilaajan
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ätiedotMiten luodaan tehokas ja sertifioitu laatujärjestelmä?
Miten luodaan tehokas ja sertifioitu laatujärjestelmä? Lahden seudun Meriklusteritapaaminen tammikuu 2019 Hannu Järvelin Business Excellence Finland Oy 1 Miksi olisit kiinnostunut? Onko sinulla selvä strategia
Lisätiedot@Tampereen Testauspäivät (2012-06)
@Tampereen Testauspäivät (2012-06) Testausodotukset räätälöityjen järjestelmien projekteissa Maaret Pyhäjärvi, testausasiantuntija Twitter: maaretp Testausvastaava @ Granlund Oy Yrittäjä
LisätiedotGlobaalisti Hajautettu Ohjelmistokehitys Mitä, Miksi & Miten? Maria Paasivaara
Globaalisti Hajautettu Ohjelmistokehitys Mitä, Miksi & Miten? Maria Paasivaara Mitä? Mitä? Yrityksen sisäinen Mitä? Yrityksen sisäinen Alihankinta Mitä? Yrityksen sisäinen Open Source -kehitys Alihankinta
LisätiedotTestaussuunnitelma. Pizzeria - Pitseria HAAGA-HELIA ammattikorkeakoulu Tietojenkäsittelyn koulutusohjelma. WebPizza
Testaussuunnitelma Pizzeria - Pitseria HAAGA-HELIA ammattikorkeakoulu Tietojenkäsittelyn koulutusohjelma Versio 1.0 Ehdotus Laatija Raine Kauppinen VERSIOHISTORIA Versionotyyppi Versio- Päiväys Tekijä
LisätiedotOhjelmistotuotanto, verifiointi ja validointi Syksy Verifioinnin ja validoinnin ero. 7. Verifiointi ja validointi
7. Verifiointi ja validointi Verifiointi ja validointi (V&V) on ohjelmistotuotannon työvaihe, missä varmistetaan, että ohjelmisto täyttää sille asetetut implisiittiset ja eksplisiittiset vaatimukset ja
LisätiedotKONEAUTOMAATION LAATU JA TURVALLISUUS. 4.6.2015 Marko Varpunen
KONEAUTOMAATION LAATU JA TURVALLISUUS 4.6.2015 Marko Varpunen TLJ ja automaatio Rautatie, metro, teollisuus-laitokset, kaivoskoneet, vesi, n. 90 henkeä Mikkeli Turvallisuusjohtaminen konsultointi riskienarviointi
LisätiedotTik-76.115 Tietojenkäsittelyopin ohjelmatyö Tietotekniikan osasto Teknillinen korkeakoulu. LiKe Liiketoiminnan kehityksen tukiprojekti
Tik-76.115 Tietojenkäsittelyopin ohjelmatyö Tietotekniikan osasto Teknillinen korkeakoulu TESTIRAPORTTI LiKe Liiketoiminnan kehityksen tukiprojekti Versio: 1.1 Tila: hyväksytty Päivämäärä: 13.2.2001 Tekijä:
LisätiedotEFQM kansalaisopiston kehittämisessä
OSAAVAT KÄDET LUOVAT MAAILMOJA. EFQM kansalaisopiston kehittämisessä Kansalaisopistojen laatuseminaari 25.11.2011 Tampere Outi Itäluoma/Petäjä-opisto EFQM (European Foundation for Quality Management) Opiston
LisätiedotLuku 8 Rakennusvaihe. Detailed Design. Programming. Moduulisuunnittelu. Ohjelmointi
Luku 8 Rakennusvaihe Moduulisuunnittelu Detailed Design Programming Ohjelmointi Teknisen Complete suunnittelun Technical viimeistely Design Suunnittelukatselmuksen Design Perform suorittaminen Review Yhteisen
LisätiedotVaatimustenhallinta. Exit
Vaatimustenhallinta Asiakasvaatimusten hallinnan tarkoitus on analysoida ja priorisoida kerätyt asiakasvaatimukset sekä hallita niitä ohjelmistokehityksen eri vaiheissa. Olennaista on jäljitettävyys: on
LisätiedotLyhyt johdatus ketterään testaukseen
TTY:n Testauspäivät, Tampere 15.8.2006 Lyhyt johdatus ketterään testaukseen eli Ketterän ohjelmistokehityksen laatukäytäntöjä Juha Itkonen SoberIT Teknillinen korkeakoulu Juha.Itkonen@tkk.fi Ketterä ohjelmistokehitys
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ätiedotOnnistunut SAP-projekti laadunvarmistuksen keinoin
Onnistunut SAP-projekti laadunvarmistuksen keinoin 07.10.2010 Patrick Qvick Sisällys 1. Qentinel 2. Laadukas ohjelmisto täyttää sille asetetut tarpeet 3. SAP -projektin kriittisiä menestystekijöitä 4.
LisätiedotTuotteet. PoiQA Oy PoiQA Oy
Tuotteet PoiQA Oy 2013 1 Auditointi Albert Mitä Kartoitetaan nykytilanne Miksi Selvitetään toiminnan laatu miten hyvin toiminta tukee yrityksen strategiaa Löydetään parannuskohteet Miten Havainnointi ja
LisätiedotTestaus teoriassa ja käytännössä. Jukka Paakki Helsingin yliopisto Tietojenkäsittelytieteen laitos
Testaus teoriassa ja käytännössä Jukka Paakki Helsingin yliopisto Tietojenkäsittelytieteen laitos Teoria = tutkimus IEEE Transactions on Software Engineering, 2000-2002 Software Testing, Verification &
LisätiedotOnnistunut ohjelmistoprojekti
Onnistunut ohjelmistoprojekti 2.12.2008 Hermanni Hyytiälä Reaktor Innovations Oy Agenda Yritysesittely Keinoja onnistuneeseen ohjelmistoprojektiin Ihmiset Menetelmät Käytännöt ja työkalut Tulevaisuuden
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ätiedot2. päivä. Etätehtävien purku Poikkeamat. Poikkeamat Auditoinnin raportointi Hyvän auditoijan ominaisuudet Harjoituksia
OAMK / Luova 4.5. ja 11.5. Sisäinen auditointi osa Oamkin ympäristöohjelmatyötä Sisältö 1. päivä Johdanto Auditoinnin tavoitteet Ympäristöstandardin (ISO 14001) pääkohdat Alustava ympäristökatselmus Auditoinnin
LisätiedotTestaajan eettiset periaatteet
Testaajan eettiset periaatteet Eettiset periaatteet ovat nousseet esille monien ammattiryhmien toiminnan yhteydessä. Tämä kalvosarja esittelee 2010-luvun testaajan työssä sovellettavia eettisiä periaatteita.
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ä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ätiedot15224 standardi johtamisen ja laadukkaan työn tukena auditoijan näkökulma YTL Merja Huikko
15224 standardi johtamisen ja laadukkaan työn tukena auditoijan näkökulma Mielikuvia laadunhallinnasta ja laatustandardeista etsitään vain virheitä ja syyllisiä vie paljon aikaa oikealta työltä mielletään
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ätiedotHarjoitustyön testaus. Juha Taina
Harjoitustyön testaus Juha Taina 1. Johdanto Ohjelman teko on muutakin kuin koodausta. Oleellinen osa on selvittää, että ohjelma toimii oikein. Tätä sanotaan ohjelman validoinniksi. Eräs keino validoida
LisätiedotKäytännön kokemuksia laatujärjestelmistä
TALONRAKENNUSTEOLLISUUS RY ITÄ-SUOMI Rakennustyömaan laadunhallinnan koulutus Käytännön kokemuksia laatujärjestelmistä Osaamispaja HMQ Ky, Heikki Munukka, 7.4.2015 KÄYTÄNNÖN KOKEMUKSISTA KOOTTUJA OHJEITA,
LisätiedotArkkitehtuuritietoisku. eli mitä aina olet halunnut tietää arkkitehtuureista, muttet ole uskaltanut kysyä
Arkkitehtuuritietoisku eli mitä aina olet halunnut tietää arkkitehtuureista, muttet ole uskaltanut kysyä Esikysymys Kuinka moni aikoo suunnitella projektityönsä arkkitehtuurin? Onko tämä arkkitehtuuria?
LisätiedotCT60A4150 OHJELMISTOTESTAUKSEN PERUSTEET. Jussi Kasurinen (etu.suku@lut.fi) Kevät 2015
CT60A4150 OHJELMISTOTESTAUKSEN PERUSTEET Jussi Kasurinen (etu.suku@lut.fi) Kevät 2015 EDELLISELLÄ KERRALLA TAPAHTUNUTTA Täydellinen testaus on mahdotonta. Testataan, koska virheiden löytyminen ajoissa
LisätiedotAVOIMEN TUOTTEEN HALLINTAMALLIT. Kunnassa toteutettujen tietojärjestelmien uudelleenkäyttö. Yhteentoimivuutta avoimesti 2.12.2011
AVOIMEN TUOTTEEN HALLINTAMALLIT Kunnassa toteutettujen tietojärjestelmien uudelleenkäyttö Yhteentoimivuutta avoimesti 2.12.2011 Erikoistutkija, MSc. Tapio Matinmikko, Teknologian tutkimuskeskus VTT 2 Esittäjästä
Lisätiedotitsmf Finland Conference 2016 Focus Markus Leinonen COBIT ja governance
itsmf Finland Conference 2016 Focus Markus Leinonen COBIT ja governance Markus Leinonen M.Sc. (Econ.), CIA, CISA Senior Manager, Internal Controls Cargotec Oyj 1984 1986 1992 1995 1997 1997 2002 2002 2008
LisätiedotTietohallinnon liiketoimintalähtöinen toiminnanohjaus IT-ERP
Tietohallinnon liiketoimintalähtöinen toiminnanohjaus IT-ERP 27.9.2007 Juha Berghäll Efecte Oy juha.berghall@efecte.fi / +358 40 589 5121 Kuka puhuu? z Juha Berghäll z Country Manager Finland z Laaja kokemus
LisätiedotHyväksymistestauksen tarkistuslista järjestelmän hankkijalle
Hyväksymistestauksen tarkistuslista järjestelmän hankkijalle Tarkistuslista on suunniteltu käytettäväksi hyväksymistestauksen suunnittelussa, valmiuksien arvioinnissa ja katselmoinnissa.tämä tarkistuslista
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ätiedot