Siis mikä suunnittelun haastavuus ja ristiriitaisuus? Suunnittelun työvaiheet. Suunnittelun lait ja hypoteesit
|
|
- Jarmo Katajakoski
- 7 vuotta sitten
- Katselukertoja:
Transkriptio
1 3. on teknisesti kaikkein haastavin ja luonteeltaan kaikkein ristiriitaisin työvaihe. Miksi? Curtis: Hyvä suunnittelu vaatii syvällistä tuotteen sovellusalueen hallintaa. Dyer: Siirtyminen vaatimusmäärittelystä suunnitteluun kasvattaa vaatimusten määrän jopa 50-kertaiseksi. Simon jne: Suosi modulaarisuutta. Siis mikä suunnittelun haastavuus ja ristiriitaisuus? Curtis & Dyer: Hyvä suunnittelu vaatii laajaa kokemusta. Dyer, Simon, jne.: alkaa vajaista abstrakteista vaatimuksista ja päättyy matalan abstraktiotason toteutusläheiseen tulokseen. ssa on siis käsiteltävä ongelmaa sekä vaatimusmäärittelyn että toteutuksen näkökulmasta. 1 2 n lait ja hypoteesit n työvaiheet Oppikirjassa esitellyt suunnittelun lait ja hypoteesit liittyvät hyvän suunnittelun ominaisuuksiin. Ne voidaan tiivistää näin: Hyvässä suunnittelussa sovellusalue ja käytetyt menetelmät hallitaan suvereenisti. n tulee olla modulaarista. Mitä vähemmän yhteyksiä suunniteltavien moduulien välillä on, sen parempi. ssa on yleensä ainakin seuraavat työvaiheet: 1. Arkkitehtuurisuunnittelu 2. Osajärjestelmäsuunnittelu 3. Komponenttisuunnittelu 4. Luokkasuunnittelu 5. Tietorakennesuunnittelu 6. Algoritmisuunnittelu 7. Käyttöliittymäsuunnittelu 3 4 Empiiristen tulosten ja työvaiheiden suhde Empiiristen tulosten ja työvaiheiden suhde 2 Curtisin laki: 1-7 Simonin laki: 1-4 Constantinen laki: 3-4 Parnasin laki: 1-5 Denertin laki (ei käsitellä): 1 Fitts-Shneidermanin laki (ei käsitellä): 7 Boochin 2. hypoteesi: 1-4 Bauer-Zemanekin hypoteesi: 1-6 Dyerin hypoteesi: 1-7 Kuten edellisestä listasta näkyy, esiteltävät lait ja hypoteesit ovat geneerisiä: ne sopivat lähes kaikkiin työvaiheisiin. Itse asiassa monet laeista eivät rajoitu vain ohjelmistotekniikkaan, vaan ovat laajemmin voimassa jopa yleisinä luonnonlakeina
2 3.1. Curtisin laki Curtisin lain taustaa Hyvä suunnittelu vaatii syvällistä tuotteen sovellusalueen hallintaa Curtisin laki perustuu erityisesti sotilasteollisuuden ohjelmistojen tarkkailuun, mutta pätee mille tahansa sovellusalueelle. Curtisin laki on ehkä oleellisin suunnittelun laeista. Se sanoo, että laadukkaan ohjelmiston suunnittelu ei onnistu, jos suunnittelijoilla ei ole vahvaa tietämystä siitä ympäristöstä, mihin ohjelmisto tulee. 7 Hyvään suunnitteluun vaaditaan ennen kaikkea sekä tietoa että ymmärrystä ohjelmiston sovellusalueesta. Sovellusalueet ja niille tehtävät ohjelmistot eroavat vahvasti toisistaan. Kaikkien alojen asiantuntijaa ei ole. Kaikille aloille sopivia ohjelmia ei ole. Koodaustaito ei takaa suunnittelutaitoa. 8 Curtisin lain taustaa 2: suunnittelun vaativuus palvelut, käyttäjien toiminta, rajoitteet, poikkeukset, laitteet Sovellusalueen hallinta Kuvaus rakenteet, arkkitehtuurit, algoritmit, resurssit, tiedot Koodauksen hallinta Hyvään suunnitteluun vaaditaan molempien alueiden hyvää hallintaa. Curtisin lain taustaa 3 n ongelmana on, että suunnittelijoiden pitää olla sekä sovellusalueen että koodauksen asiantuntijoita. Useimmiten näin ei ole. Yleisin lienee tapaus, missä suunnittelijat ovat vain koodauksen asiantuntijoita. Toki voi myös olla, että suunnittelijat ovat vain sovellusalueen asiantuntijoita Curtisin lain perusteluja Curtisin lain perusteluja 2 Curtis perustaa tuloksensa 1986 tekemäänsä 17 projektia kattaneeseen haastattelututkimukseen. Hänen tuloksensa olivat: Vain harvalla projektien jäsenistä oli sovellusalueen tuntemusta. Useimmiten yksi tai kaksi eniten sovellusaluetta tuntevaa henkilöä ottivat päävastuun suunnittelusta. 11 Curtisin tulokset jatkuvat: Samat pari sovellusalueen tuntijaa informoivat muita projektin jäseniä arkkitehtuurista. kokousten tehtävänä oli muokata suunnitelma koko projektiryhmän yhteiseksi näkemykseksi tehtävästä tuotteesta. Johtopäätös: suunnittelu jätettiin suosiolla sovellusalueen asiantuntijoille. 12 2
3 Curtisin lain teoria Teoria 1 (oppikirja): on yksi tietämyksen sovellus. Osa tietämyksestä on ns. piilotietämystä (tacit knowledge), joka on hienompi sana kokemukselle. Pelkkä kirjoitettu tieto ei riitä matkalla vaatimuksista suunnitteluun, vaan tarvitaan myös vankkaa sovellusalueen tuntemista ja kokemusta. Curtisin lain teoria 2 Teoria 2 (luennoija): Jos Dyerin hypoteesi on voimassa, suunnittelussa johdettavien vaatimusten määrä on jopa 50-kertainen verrattuna käyttäjävaatimuksiin. Suuri osa johdetuista vaatimuksista koskee ohjelmiston suhdetta sovellusalueeseen. Näitä ohjelmiston ja sovellusalueen välisiä vaatimuksia ei voida suunnitella ilman vahvoja taustatietoja sovellusalueesta Simonin laki Simonin lain taustaa Hierarkkiset rakenteet vähentävät kompleksisuutta. Laki käy perusteluksi mm. suunnittelussa käytettyyn luokka komponentti osajärjestelmä jaotteluun. Simonin laki ei ole pelkkää ohjelmistotekniikkaa, vaan sama laki pätee kaikessa suunnittelussa. Simonin laki onkin yksi universaaleista suunnittelun laeista. Koko maailmankaikkeus tuntuu seuraavan Simonin lakia. Laki pätee sekä elottoman luonnon rakentumiseen alkeishiukkasista galaksiryppäisiin että elollisen luonnon rakentumiseen soluista organismeiksi. Myös ohjelmistotekniikassa hierarkkisten järjestelmien hallinta on helpompaa kuin ei-hierarkkisten järjestelmien hallinta Simonin lain perusteluja Simonin lain teoria Simon perustaa lakinsa havaintoihin luonnosta. Hänen mukaansa luonnossa hierarkkiset järjestelmät kehittyvät nopeammin kuin ilman rakennetta olevat järjestelmät. Evoluutio suosii hierarkkisia järjestelmiä, sillä ne toipuvat paremmin häiriöistä. Sama pätee keinotekoisiin järjestelmiin myös ohjelmistotekniikassa. 17 Simonin laki vaikuttaa olevan luonnonlaki, jolle teorian kehittäminen olisi enemmän filosofiaa kuin EOT:ta. Simon itse toteaa: En tiedä, ymmärrämmekö maailmaa, koska se on hierarkkinen, vai näemmekö maailman hierarkkisena, koska emme ymmärrä emmekä osaa havaita sen hierarkian vastaisia rakenteita. 18 3
4 3.3. Constantinen laki Hyvällä rakenteella on korkea yhtenäisyys ja matala kytkentäaste. Yhtenäisyys (cohesion, binding): miten sidoksissa moduulin (osajärjestelmän, komponentin, luokan) osat ovat toisiinsa. Kytkentäaste: (coupling): miten sidoksissa moduuli on muihin moduuleihin. Eli mitä paremmin moduuli hoitaa juuri omat hommansa ja mitä riippumattomammin muista, sen parempi. 19 Constantinen lain taustaa Constantinen laki on sukua Simonin laille. Oleellisesti se sanoo, että mitä paremmin järjestelmän osat puhaltavat yhteen hiileen ja mitä vähemmän niillä on keskinäisiä yhteyksiä, sitä enemmän vaaditaan järjestelmän häiritsemiseksi. Yhtenäisyys ja kytkentäaste näkyvät selvästi mm. oliopohjaisessa suunnittelussa ja suunnittelumalleissa. 20 Constantinen lain perusteluja Sekä yhtenäisyys että kytkentäaste voidaan määritellä matemaattisesti. Määritelmän avulla yhtenäisyyttä ja kytkentäastetta voidaan mitata ohjelmakoodista, joten Constantinen lain testaamiseen voidaan käyttää staattisia metriikoita. Tällaisia tutkimuksia on jo tehty (Basili 1996, Briand 1998). Constantinen lain perusteluja 2 Tutkimusten oleellisia tuloksia: Vahva yhtenäisyys Ł vähän virheitä: Vahva vastaavuus. Korkea sisäinen kytkentäaste (olio kutsuu muita)ł enemmän virheitä: Vahva vastaavuus. Korkea ulkoinen kytkentäaste (oliota kutsutaan)ł enemmän virheitä: Heikko vastaavuus Constantinen lain teoria 3.4. Parnasin laki Korkea yhtenäisyys tarkoittaa, että moduulissa ei ole mitään ylimääräistä. Tämä helpottaa testausta ja pienentää virhealttiutta. Matala kytkentäaste tarkoittaa, että moduulit voidaan paremmin eristää toisistaan. Tämäkin helpottaa testausta ja pienentää virhealttiutta. Vain piilotettua tietoa voidaan muuttaa ilman riskiä. Parnasin laki on kapseloinnin perusta, ja siten yksi ohjelmistotekniikan tärkeimmistä laeista. Laki on myös kaiken modulaarisuuden perusta yhdessä Simonin lain kanssa. Parnasin laki pätee ainakin kaikissa insinööritieteissä, ehkä myös muualla
5 Parnasin lain taustaa Parnasin laki on varmaankin tunnetuin ohjelmistotekniikan laki. Kaikki käyttävät sitä ajattelematta asiaa sen kummemmin. Parnasin lakia voidaan soveltaa mm. projektinhallinnassa: kaikkien ei tarvitse tietää yksityiskohtia kaikista työvaiheista, vaan työvaiheiden tulokset ratkaisevat. Parnasin lain perusteluja Parnas perustaa lakinsa tapaustutkimukseen, missä hän tarkkaili Philipsin insinöörien työskentelyä. Parnas havaitsi, että modularisointi oli tärkeä suunnittelumenetelmä, mutta sitä ymmärrettiin huonosti. Parnasin lain perustelut ovat varsin köykäiset. Toisaalta laki on samaan tapaan luonnonlaki kuin Simonin laki Parnasin lain teoria 3.5. Boochin toinen hypoteesi Parnasin lain teoria voidaan perustaa kahteen faktaan: a tarvitaan koko tuotteen elinkaaren ajan. Kehitystyössä tarvittavia ratkaisuja on voitava siirtää eteenpäin ilman että ne mitätöivät tehdyt muutokset. Ihmisen käsitys- ja omaksumiskyky on rajallinen. Tiettyyn tehtävään vaadittavan tiedon vähennys helpottaa tehtävän tekoa. Oliopohjainen suunnittelu vähentää virheitä ja rohkaisee uudelleenkäyttöön. Boochin toinen hypoteesi on sukua vaatimusmäärittelyssä esitellylle Boochin ensimmäiselle hypoteesille. Jos Boochin hypoteesit ovat valideja, olioparadigmaa kannattaa käyttää koko projektin elinkaaren ajan Boochin toisen hypoteesin taustaa Oliomallinnuksen katsotaan parantavan erityisesti suunnittelun laatua. Malleina oliot ovat lähempänä mallintamiaan luonnon kohteita kuin proseduraalisen ohjelmoinnin funktiot. Boochin hypoteeseista huolimatta oliomallinnus ei ole mikään viisasten kivi, joka ratkaisee kaikki ongelmat. Boochin toisen hypoteesin perusteluja Oikein käytettynä oliomallinnus on mainio työkalu. Vaatimusmäärittelyn käyttötapauksista voidaan eristää eri tasoisia olioita. Vaatimusmäärittelyn oliot voidaan jalostaa suunnittelussa käytettäviksi olioiksi. Hierarkkiset rakenteet, yhtenäisyys & kytkentäaste ja kapselointi ovat mukana suunnittelun alusta alkaen
6 Boochin toisen hypoteesin perusteluja 2 Valitettavasti oliomallinnuksella on kääntöpuolensa. Oliomallinnus sallii myös virheherkkiä rakenteita, kuten perintä, kuormitus ja myöhäinen sidonta. Näistä on myös empiirisiä tuloksia: Syvä perintähierarkia Ł enemmän virheitä Erittäin vahva vastaavuus. Metodien korvaus Ł enemmän virheitä Vahva vastaavuus. 31 Boochin toisen hypoteesin perusteluja 3 Ei ole sattumaa, että Boochin toinen hypoteesi ei ole laki. Se ei toimi riittävän yleisillä ehdoilla. Sen sijaan on selvää, että oikein käytettynä oliomallinnus on oiva työkalu. Se sisältää aiemmista laeista saadut hyvät tulokset hierarkkisista rakenteista, kapseloinnista, yhtenäisyydestä ja kytkentäasteesta Bauer-Zemanekin hypoteesi taustaa Formaalit menetelmät vähentävät merkittävästi suunnitteluvirheitä tai eliminoivat ne aikaisessa vaiheessa. Vaikka ohjelmistotekniikka ei perustu matematiikkaan, jotkut ohjelmistotekniikan alueet (mm. lasilaatikkotestaus) on voitu formalisoida matemaattisin menetelmin. B-Z:n hypoteesin mukaan matemaattinen formalismi sopii hyvin myös suunnitteluun. 33 Formaalit menetelmät perustuvat johonkin matemaattiseen formalismiin, jonka avulla jokin ratkaisu voidaan todistaa oikeaksi. Formalismin avulla voidaan kirjoittaa ongelman määrittely, todistaa määrittelystä ominaisuuksia, tehdä määrittelyyn perustuva ratkaisu, todistaa ratkaisu matemaattisesti oikeaksi. 34 taustaa 2 B-Z:n hypoteesille on paljon kannatusta, sillä matemaattista formalismia pidetään perimmäisenä suunnittelun ratkaisuna. Kannattaa kuitenkin huomata, että kaikkia ongelmia ei voida formuloida, formalismin ymmärtäminen ja varsinkin uuden formalismin kehittäminen vaatii vankkaa matemaattista taustaa, formalismin päivittäminen on vaikeaa. 35 perusteluja B-Z:n hypotesi on eräs eniten kiistellyistä EOT:n alueista. Aiheesta on tehty lukuisia tapaustutkimuksia, mutta tulokset ovat olleet ristiriitaisia. Hallin tutkimuksessa 1990 keskikokoisen projektin (58 KLOC, Kilo Lines of Code) formaali määrittely paransi suunnittelua ja nopeutti virheiden löytymistä. Tuotteesta ei tarvittu luonnollisella kielellä tehtyä normaalia määrittelyä. 36 6
7 perusteluja 2 Hayesin tutkimuksessa 1985 CICSjärjestelmän (Customer Information Control System) ohjelmoijan manuaali määriteltiin uudestaan formaalilla kielellä. Määrittelyssä manuaalista löydettiin useita puutteita ja epäjohdonmukaisuuksia, jotka johtivat muutamien CICS-järjestelmän osien kirjoittamiseen uudestaan. Projektin tuloksena raportoitiin 60% virhevähennys ja 5,5 miljoonan dollarin kustannussäästö. perusteluja 3 Vaikka tulokset ovat vakuuttavia, niiden yleistäminen isompaan projektijoukkoon ei ole itsestään selvää: Kyseessä oli lähinnä dokumentointi- ja ylläpitoprojekti, mikä pitää ottaa huomion tulosten analyysissa. Koko projekti kesti kaiken kaikkiaan 12 vuotta! Joka tapauksessa projekti on yksi eniten viitatuista formaalien menetelmien käytettävyystutkimuksista ja vahva osoitus siitä, että parhaimmillaan formaalit menetelmät ovat erittäin hyödyllisiä perusteluja 4 perusteluja 5 Pfleegerin ja Hattonin tutkimuksessa 1997 seurattiin noin 200 KLOC kokoisen C- kielisen ohjelman tekoa. Merkittäviä osia ohjelmasta määriteltiin formaalisti. Pfleeger ja Hatton mittasivat tuotteen osien virhetiheyttä sekä projektin aikana että tuotantokäytössä. Pfleegerin ja Hattonin tulokset olivat: Projektin aikana: Muutoksia / KLOC : Muuttuneita moduuleita Formaalit: 19,6 : 22% Ei-formaalit: 21,0 : 19% Tuotantokäytössä: Muutoksia / KLOC : Muuttuneita moduuleita Formaalit: 0,58 : 0,12% Ei-formaalit: 1,61 : 0,27% perusteluja 6 perusteluja 7 Pfleegerin ja Hattonin tulokset ovat vakuuttavia varsinkin tuotantokäytössä löytyneiden virheiden osalta. Siitä huolimatta kritiikkiäkin löytyy: Projektiin osallistujien kokemuksesta ei ole tietoa, ei myöskään osallistujen formaalien menetelmien tietotaidosta. Projektissa ei ilmeisesti käytetty tarkastuksia, sillä virheiden elinikä oli pitkä. Tarkastusten käyttö olisi ehkä kutistanut formaalien ja eiformaalien tulosten eroa. 41 Formaaleista menetelmistä on taitettu peistä molempiin suuntiin. Ehkä parhaiten alaa kuvaa seuraava Gerhard, Craigen, Ralston kommentti: There is no simple answer to the question: do the formal methods pay off? All cases involve so many interwoven factors that it is impossible to allocate payoff from formal methods versus other factors. Gerhard et al. Observation on Industrial Practice Using Formal Methods, Proc. Int l Conf. Software Eng., 1993,
8 3.7. Dyerin hypoteesi Siirtyminen vaatimusmäärittelystä suunnitteluun kasvattaa vaatimusten määrän jopa 50-kertaiseksi. Dyerin hypoteesi on esitelty Glassin kirjassa R. Glass, Facts and Fallacies of Software Engineering. Glass kirjoittaa kirjassaan yrittäneensä saada Dyerin kommentoimaan hypoteesiaan, mutta Glassin mukaan Dyer ei vastannut yhteydenottopyyntöihin. Dyerin hypoteesin taustaa Siirtyminen vaatimusmäärittelystä suunnitteluun on samalla iso hyppy abstraktiossa. Vaatimusmäärittelyssä löytyneet vaatimukset eivät riitä suunnitteluun, vaan suunnittelun sivutuotteena löytyy uusia vaatimuksia. Näitä kutsutaan johdetuiksi vaatimuksiksi (derived requirements) Dyerin hypoteesin taustaa 2 Dyerin hypoteesin perusteluja Johdetut vaatimukset johtuvat erilaisista abstraktiotasoista. Vaatimusmäärittelyn mitä -abstraktio ei riitä kuvaamaan kaikkea tarvittavaa suunnittelun miten -abstraktioon. Glassin mukaan johdettuja vaatimuksia voi olla pahimmillaan 50 kertaa alkuperäisiä vaatimuksia enemmän! Dyerin hypoteesia ei ole validoitu, vaikka Glassin mukaan hypoteesi on tunnettu jo vuosikymmeniä. Hypoteesin validointi vaatisi joukon projekteja, joista laskettaisiin vaatimusten lukumäärän suhde johdettujen vaatimusten lukumäärään. Ainakin ohtu-projekteissa hypoteesi on todettu useamman kerran oikeaksi Esiteltyjen lakien seurauksia Esiteltyjen lakien seurauksia 2 Hyväksi suunnittelijaksi ei tulla pelkällä opiskelulla. Curtisin lain mukaan hyvä suunnittelija hallitsee suvereenisti suunniteltavan ohjelmiston sovellusalueen. Tähän vaaditaan ennen kaikkea kokemusta. Simonin lain mukaan ei-pakollisen tiedon rajoittaminen parantaa suunnittelua. Tällaisen tiedon tunnistus suunnittelussa vaatii ennen kaikkea kokemusta. 47 Modulaarinen lähestymistapa parantaa ja helpottaa suunnittelua. Simonin, Constantinen, Parnasin ja Fitts- Shneidermanin lait johtavat kaikki ylläolevaan tulokseen. Lisäksi oppikirjassa on esitelty Denertin laki, jota voidaan käyttää standardoitujen arkkitehtuurien perusteena. Myös tämä laki johtaa samaan tulokseen. 48 8
1. Johdanto. Empiirinen ohjelmistotutkimus. Empiirisen tutkimuksen perusta. Havainnot, laki, teoria. Havainto-laki-teoria
1. Johdanto Building software will always be hard. There is inherently no silver bullet. F. Brooks, 1987. Ohjelmisto- ja järjestelmätekniikka (software engineering, software systems engineering) määrittelevät,
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ätiedot2. Vaatimusmäärittely. Kevät 2005 Empiirinen ohjelmistotutkimus / Taina. Kevät 2005 Empiirinen ohjelmistotutkimus / Taina
2. on ensimmäinen projektin osavaihe. Sitä pidetään myös tärkeimpänä vaiheena. Miksi? Ehkä seuraavat lait selittävät asiaa: Glass: huono vaatimusmäärittely on todennäköisin epäonnistuneen projektin syy.
LisätiedotYlläpidon merkitys. Ylläpidon lakien suhde ohjelmistotuotantoon. Ylläpidon osa-alueet. Ylläpidon lakien suhde ohjelmistotuotantoon 2
5. tarkoittaa niitä toimintoja, jotka tehdään ohjelmalle sen käyttöönoton jälkeen. on kallein työvaihe. Glassin mukaan 40-80% kustannuksista kuluu siihen. Kumma kyllä tätä ei ole listattu ylläpidon laeissa.
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ätiedotSuunnitteluvaihe prosessissa
Suunnittelu Suunnitteluvaihe prosessissa Silta analyysin ja toteutuksen välillä (raja usein hämärä kumpaankin suuntaan) Asteittain tarkentuva Analyysi -Korkea abstraktiotaso -Sovellusläheiset käsitteet
Lisä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ätiedotProjektinhallinnan merkitys
6. ei ole työvaihe, vaan se on läsnä koko tuotteen elinkaaren ajan. Se siirtää ohjausvastuun pois kehitystiimiltä. Työvaihe sisältää prosessin ohjaukseen liittyviä tehtäviä: koko- ja kustannusarviot, aikataulun
LisätiedotConcurrency - Rinnakkaisuus. Group: 9 Joni Laine Juho Vähätalo
Concurrency - Rinnakkaisuus Group: 9 Joni Laine Juho Vähätalo Sisällysluettelo 1. Johdanto... 3 2. C++ thread... 4 3. Python multiprocessing... 6 4. Java ExecutorService... 8 5. Yhteenveto... 9 6. Lähteet...
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ä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ätiedot4. Verifiointi ja validointi. Kevät 2005 Empiirinen ohjelmistotutkimus / Taina. Kevät 2005 Empiirinen ohjelmistotutkimus / Taina
4. Verifioinnissa varmennetaan, että järjestelmä on toimiva ja optimaalinen. Yleensä se muotoillaan kysymykseksi Kehitämmekö järjestelmää oikein? Validoinnissa varmennetaan, että järjestelmä vastaa siitä
Lisätiedot2. Ohjelmistotuotantoprosessi
2. Ohjelmistotuotantoprosessi Peruskäsitteet: prosessimalli: mahdollisimman yleisesti sovellettavissa oleva ohjeisto ohjelmistojen tuottamiseen ohjelmistotuotantoprosessi: yrityksessä käytössä oleva tapa
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ätiedot6. Suunnittelu. Suunnittelun tulos
6. Suunnittelu Vaatimusanalyysin jälkeen seuraava työvaihe on suunnittelu. Siinä vaatimusanalyysin korkean abstraktiotason malleja käyttämällä luodaan alempien abstraktiotasojen malleja. Tavoitteena on
LisätiedotProsessimalli. 2. Ohjelmistotuotantoprosessi. Prosessimallin vaihejako. Prosessimallien perustehtävät. Ohjelmiston suunnittelu. Vaatimusmäärittely
2. Ohjelmistotuotantoprosessi Peruskäsitteet: prosessimalli: mahdollisimman yleisesti sovellettavissa oleva ohjeisto ohjelmistojen tuottamiseen ohjelmistotuotantoprosessi: yrityksessä käytössä oleva tapa
LisätiedotKant Arvostelmia. Informaatioajan Filosofian kurssin essee. Otto Opiskelija 65041E
Kant Arvostelmia Informaatioajan Filosofian kurssin essee Otto Opiskelija 65041E David Humen radikaalit näkemykset kausaaliudesta ja siitä johdetut ajatukset metafysiikan olemuksesta (tai pikemminkin olemattomuudesta)
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ätiedotOhjelmistotuotanto, suunnittelu Syksy Suunnittelu. Suunnittelun tulos. Suunnitteluprosessin työvaiheet. Suunnitteluprosessi.
6. Suunnittelu Suunnittelun tulos Vaatimusanalyysin jälkeen seuraava työvaihe on suunnittelu. Siinä vaatimusanalyysin korkean abstraktiotason malleja käyttämällä luodaan alempien abstraktiotasojen malleja.
LisätiedotOhjelmistojen mallintaminen
Ohjelmistojen mallintaminen - Mallit - Ohjelmiston kuvaaminen malleilla 31.10.2008 Harri Laine 1 Malli: abstraktio jostain kohteesta Abstrahointi: asian ilmaiseminen tavalla, joka tuo esiin tietystä näkökulmasta
LisätiedotSuunnittelun tulos. 6. Suunnittelu. Suunnitteluprosessin työvaiheet. Suunnitteluprosessi. 6.1 Arkkitehtuurisuunnittelu.
6. Suunnittelu Suunnittelun tulos Vaatimusanalyysin jälkeen seuraava työvaihe on suunnittelu. Siinä vaatimusanalyysin korkean abstraktiotason malleja käyttämällä luodaan alempien abstraktiotasojen malleja.
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ätiedot13/20: Kierrätys kannattaa koodaamisessakin
Ohjelmointi 1 / syksy 2007 13/20: Kierrätys kannattaa koodaamisessakin Paavo Nieminen nieminen@jyu.fi Tietotekniikan laitos Informaatioteknologian tiedekunta Jyväskylän yliopisto Ohjelmointi 1 / syksy
LisätiedotOleelliset vaikeudet OT:ssa 1/2
Oleelliset vaikeudet OT:ssa 1/2 Monimutkaisuus: Mahdoton ymmärtää kaikki ohjelman tilat Uusien toimintojen lisääminen voi olla vaikeaa Ohjelmista helposti vaikeakäyttöisiä Projektiryhmän sisäiset kommunikointivaikeudet
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ätiedotohjelman arkkitehtuurista.
1 Legacy-järjestelmällä tarkoitetaan (mahdollisesti) vanhaa, olemassa olevaa ja käyttökelpoista ohjelmistoa, joka on toteutettu käyttäen vanhoja menetelmiä ja/tai ohjelmointikieliä, joiden tuntemus yrityksessä
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ätiedotOhjelmistotekniikan menetelmät, kevät 2008
582101 - Ohjelmistotekniikan menetelmät, kevät 2008 1 Ohjelmistotekniikan menetelmät Methods for Software Engineering Perusopintojen pakollinen opintojakso, 4 op Esitietoina edellytetään oliokäsitteistön
LisätiedotOhjelmistoarkkitehtuurit Syksy 2009 TTY Ohjelmistotekniikka 1
Ohjelmistoarkkitehtuurit Syksy 2009 Kai Koskimies Ohjelmistoarkkitehtuurit Syksy 2009 TTY Ohjelmistotekniikka 1 Tervetuloa Kuopion yliopisto, Oulun yliopisto (Kajaani), Tampereen yliopisto, Turun yliopisto,
Lisä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ätiedot1. Olio-ohjelmointi 1.1
1. Olio-ohjelmointi 1.1 Sisällys Olio-ohjelmointi on eräs ohjelmointiparadigma. Olio-ohjelmoinnin muotoja. Ohjelmiston analyysi ja suunnittelu. Olioparadigman etuja ja kritiikkiä. 1.2 Ohjelmointiparadigmoja
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ätiedotOhjelmoinnin perusteet, syksy 2006
Ohjelmoinnin perusteet, syksy 2006 Esimerkkivastaukset 1. harjoituksiin. Alkuperäiset esimerkkivastaukset laati Jari Suominen. Vastauksia muokkasi Jukka Stenlund. 1. Esitä seuraavan algoritmin tila jokaisen
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ä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ä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ätiedotHieman lisää malleista ja niiden hyödyntämisestä
Hieman lisää malleista ja niiden hyödyntämisestä Ohjelmistojen mallintaminen Kesä 2012 (Avoin yliopisto) Toni Ruokolainen, 23.8.2012 Mallit Mallit ovat todellisuuden abstraktioita, jotka on muodostettu
LisätiedotKoodaamme uutta todellisuutta FM Maarit Savolainen https://blog.edu.turku.fi/matikkaajakoodausta/
Koodaamme uutta todellisuutta FM Maarit Savolainen 19.1.2017 https://blog.edu.turku.fi/matikkaajakoodausta/ Mitä on koodaaminen? Koodaus on puhetta tietokoneille. Koodaus on käskyjen antamista tietokoneelle.
LisätiedotTutkimus lapsen abstraktin ajattelun kehittymisestä Piaget n teorian mukaisesti
Tutkimus lapsen abstraktin ajattelun kehittymisestä Piaget n teorian mukaisesti Joonatan Porkkala PSw2.1 2017 2 1 Johdanto 1.1 Taustateoria Tutkimuksen taustateoriana on Piaget n teoria lapsen kognitiivisesta
LisätiedotTäydentäviä muistiinpanoja laskennan rajoista
Täydentäviä muistiinpanoja laskennan rajoista Antti-Juhani Kaijanaho 10. joulukuuta 2015 1 Diagonaalikieli Diagonaalikieli on D = { k {0, 1} k L(M k ) }. Lause 1. Päätösongelma Onko k {0, 1} sellaisen
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ätiedotOhjelmistoarkkitehtuurit Syksy 2009 TTY Ohjelmistotekniikka 1
3. Komponentit ja rajapinnat 3.1 Komponenttien idea: ohjelmistotuotannon rationalisointi 3.2 Mikä on ohjelmistokomponentti? 3.3 Komponentit ohjelmistoyksikköinä 3.4 Rajapinnat 3.6 Komponenttien räätälöinti
LisätiedotYhtälönratkaisusta. Johanna Rämö, Helsingin yliopisto. 22. syyskuuta 2014
Yhtälönratkaisusta Johanna Rämö, Helsingin yliopisto 22. syyskuuta 2014 Yhtälönratkaisu on koulusta tuttua, mutta usein sitä tehdään mekaanisesti sen kummempia ajattelematta. Jotta pystytään ratkaisemaan
LisätiedotMatematiikan opetuksen kehittäminen avoimen lähdekoodin ohjelmistojen avulla Petri Salmela & Petri Sallasmaa
Matematiikan opetuksen kehittäminen avoimen lähdekoodin ohjelmistojen avulla 21.04.2010 Petri Salmela & Petri Sallasmaa Tutkimusorganisaatio Åbo Akademin ja Turun yliopiston tutkimusryhmät Pitkä yhteistyötausta
LisätiedotSisällys. JAVA-OHJELMOINTI Osa 7: Abstrakti luokka ja rajapinta. Abstraktin luokan idea. Abstrakti luokka ja metodi. Esimerkki
Sisällys JAVA-OHJELMOINTI Osa 7: Abstrakti luokka ja rajapinta Abstrakti luokka ja metodi Rajapintamäärittely (interface) Eero Hyvönen Tietojenkäsittelytieteen laitos Helsingin yliopisto 13.10.2000 E.
LisätiedotTIETOTEKNIIKAN KOULUTUSOHJELMA
TIETOTEKNIIKAN KOULUTUSOHJELMA Tietotekniikan koulutusohjelman toimintaympäristö ja osaamistavoitteet Tietotekniikan koulutusohjelmasta valmistuneet insinöörit sijoittuvat suunnittelu-, ohjelmointi-, esimies-,
LisätiedotKehittää ohjelmointitehtävien ratkaisemisessa tarvittavia metakognitioita!
Kehittää ohjelmointitehtävien ratkaisemisessa tarvittavia metakognitioita! eli... Hyvä kaava sanoo enemmän kuin,... tuhat riviä koodia!... sata riviä tekstiä!... kymmenen diagrammia! YLEISTÄ FORMAALEISTA
LisätiedotOhjelmistojen mallintamisen ja tietokantojen perusteiden yhteys
Ohjelmistojen mallintamisen ja tietokantojen perusteiden yhteys Tällä kurssilla on tutustuttu ohjelmistojen mallintamiseen oliomenetelmiä ja UML:ää käyttäen Samaan aikaan järjestetyllä kurssilla on käsitelty
Lisätiedot15. Ohjelmoinnin tekniikkaa 15.1
15. Ohjelmoinnin tekniikkaa 15.1 Sisällys For-each-rakenne. Lueteltu tyyppi enum. Override-annotaatio. Geneerinen ohjelmointi. 15.2 For-each-rakenne For-rakenteen variaatio taulukoiden ja muiden kokoelmien
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ätiedot582104 Ohjelmistojen mallintaminen, Johdatus ohjelmistotuotantoon
582104 Ohjelmistojen mallintaminen, Johdatus ohjelmistotuotantoon 1 Lyhyt johdatus ohjelmistotuotantoon Ohjelmistotuotanto, ohjelmistoprojektit Miten ohjelmistojen tuottaminen eroaa teollisesta tuotannosta
Lisätiedot11/20: Konepelti auki
Ohjelmointi 1 / syksy 2007 11/20: Konepelti auki Paavo Nieminen nieminen@jyu.fi Tietotekniikan laitos Informaatioteknologian tiedekunta Jyväskylän yliopisto Ohjelmointi 1 / syksy 2007 p.1/11 Tämän luennon
LisätiedotOhjelmistojen mallintaminen, mallintaminen ja UML
582104 Ohjelmistojen mallintaminen, mallintaminen ja UML 1 Mallintaminen ja UML (Ch 2.) Ohjelmistojen mallintamisesta ja kuvaamisesta Strukturoitu mallinnus Tietovuo- ja ER-kaaviot Oliomallinnus ja UML
Lisätiedot7. Tutkimuksen teko. Kevät 2005 Empiirinen ohjelmistotutkimus / Taina. Kevät 2005 Empiirinen ohjelmistotutkimus / Taina
7. 7.1. Johdanto Tämä luku perustuu kirjaan C. Wohlin et al., Experimentation in Software Engineering, An Introduction, Kluwer Academic Publishers, 2000. ISBN 0-7923-8682-5. Tähän asti olemme käsitelleet
LisätiedotTietorakenteet ja algoritmit
Tietorakenteet ja algoritmit Kurssin sisältö pääpiirteittäin Tarvittavat pohjatiedot Avainsanat Abstraktio Esimerkkiohjelman tehtäväkuvaus Abstraktion käyttö tehtävässä Abstrakti tietotyyppi Hyötyjä ADT:n
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ätiedotTIEA241 Automaatit ja kieliopit, syksy Antti-Juhani Kaijanaho. 8. syyskuuta 2016
TIEA241 Automaatit ja kieliopit, syksy 2016 Antti-Juhani Kaijanaho TIETOTEKNIIKAN LAITOS 8. syyskuuta 2016 Sisällys a https://tim.jyu.fi/view/kurssit/tie/ tiea241/2016/videoiden%20hakemisto Matemaattisen
LisätiedotOhjelmien automaattisen verifioinnin reunamailla
Ohjelmien automaattisen verifioinnin reunamailla Antti Siirtola Tietotekniikan laitos, Perustieteiden korkeakoulu, Aalto-yliopisto, antti.siirtola@aalto.fi Suomalainen Tiedeakatemia, Nuorten akatemiaklubi,
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ätiedotSoftware product lines
Thomas Gustafsson, Henrik Heikkilä Software product lines Metropolia Ammattikorkeakoulu Insinööri (AMK) Tietotekniikan koulutusohjelma Asiantuntijateksti 17.11.2013 Sisällys 1 Johdanto 1 2 Software product
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ätiedotKäsitteistä. Reliabiliteetti, validiteetti ja yleistäminen. Reliabiliteetti. Reliabiliteetti ja validiteetti
Käsitteistä Reliabiliteetti, validiteetti ja yleistäminen KE 62 Ilpo Koskinen 28.11.05 empiirisessä tutkimuksessa puhutaan peruskurssien jälkeen harvoin "todesta" ja "väärästä" tiedosta (tai näiden modernimmista
LisätiedotAvoin lähdekoodi (Open Source) liiketoiminnassa
Avoin lähdekoodi (Open Source) liiketoiminnassa Mikko Amper 12.11.2013 Mitä aloittavan BioICT-yrityksen tulisi tietää IPR:istä, niiden hallinnasta ja patentoinnista? Tässä esityksessä ilmaistut mielipiteet
LisätiedotHELIA 1 (14) Outi Virkki Käyttöliittymät ja ohjlmiston suunnittelu
HELIA 1 (14) Luento 7 Käyttöliittymäolio... 2 Olioajattelun perusteet... 3 Tavoitteet... 3 Peruskäsitteet... 4 Olio / Olioinstanssi / Olion esiintymä... 4 Ominaisuudet... 4 Toiminnot... 4 Olioluokka /
LisätiedotTarvitseeko informaatioteknologia matematiikkaa?
Tarvitseeko informaatioteknologia matematiikkaa? Oulun yliopisto Matemaattisten tieteiden laitos 1 Kyllä kai IT matematiikkaa tarvitsee!? IT ja muu korkea teknologia on nimenomaan matemaattista teknologiaa.
LisätiedotJoukot. Georg Cantor ( )
Joukot Matematiikassa on pyrkimys määritellä monimutkaiset asiat täsmällisesti yksinkertaisempien asioiden avulla. Tarvitaan jokin lähtökohta, muutama yleisesti hyväksytty ja ymmärretty käsite, joista
Lisätiedot1.3 Lohkorakenne muodostetaan käyttämällä a) puolipistettä b) aaltosulkeita c) BEGIN ja END lausekkeita d) sisennystä
OULUN YLIOPISTO Tietojenkäsittelytieteiden laitos Johdatus ohjelmointiin 811122P (5 op.) 12.12.2005 Ohjelmointikieli on Java. Tentissä saa olla materiaali mukana. Tenttitulokset julkaistaan aikaisintaan
LisätiedotSEPA päiväkirja. BetaTeam. Juho Mäkinen, 57796V, Jari Leppä, 42710V, Versio Pvm Tekijä Kuvaus
SEPA päiväkirja BetaTeam Juho Mäkinen, 57796V, jvmakine@cc.hut.fi Jari Leppä, 42710V, jleppa@cc.hut.fi Versio Pvm Tekijä Kuvaus 0.1 10.11.2005 Juho Mäkinen Johdanto 1. 0.2 11.11.2005 J.Mäkinen, Käytäntöön
LisätiedotRekursiolause. Laskennan teorian opintopiiri. Sebastian Björkqvist. 23. helmikuuta Tiivistelmä
Rekursiolause Laskennan teorian opintopiiri Sebastian Björkqvist 23. helmikuuta 2014 Tiivistelmä Työssä käydään läpi itsereplikoituvien ohjelmien toimintaa sekä esitetään ja todistetaan rekursiolause,
LisätiedotELM GROUP 04. Teemu Laakso Henrik Talarmo
ELM GROUP 04 Teemu Laakso Henrik Talarmo 23. marraskuuta 2017 Sisältö 1 Johdanto 1 2 Ominaisuuksia 2 2.1 Muuttujat ja tietorakenteet...................... 2 2.2 Funktiot................................
LisätiedotUCOT-Sovellusprojekti. Testausraportti
UCOT-Sovellusprojekti Testausraportti Ilari Liukko Tuomo Pieniluoma Vesa Pikki Panu Suominen Versio: 0.02 Julkinen 11. lokakuuta 2006 Jyväskylän yliopisto Tietotekniikan laitos Jyväskylä Hyväksyjä Päivämäärä
Lisätiedot812341A Olio-ohjelmointi, I Johdanto
812341A Olio-ohjelmointi, 2016 I Johdanto Sisältö 1. Abstraktiosta 2. Olio-ohjelmoinnin historiaa 3. Olioparadigmasta 4. Peruskäsitteiden kertausta 812341A Olio-ohjelmointi, Johdanto 2 1 Abstraktiosta
LisätiedotOhjelmistojen mallintaminen kertausta Harri Laine 1
kertausta 5.12.2008 Harri Laine 1 Ohjelmiston elinkaari, elinkaarimallit Yleinen puitemalli (reference model) - abstrakti kokonaiskuva ei etenemiskontrollia, ei yksityiskohtia Ohjelmistoprosessimallit
Lisätiedot3. Laskennan vaativuusteoriaa
3. Laskennan vaativuusteoriaa tähän asti puhuttu siitä, mitä on mahdollista laskea äärellisessä ajassa siirrytään tarkastelemaan laskemista kohtuullisessa ajassa vaihtoehtoisesti voidaan laskenta-ajan
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ä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ätiedotTT00AA12-2016 - Ohjelmoinnin jatko (TT10S1ECD)
TT00AA12-2016 - Ohjelmoinnin jatko (TT10S1ECD) Ohjelmointikäytännöt 21/3/11 Mikko Vuorinen Metropolia Ammattikorkeakoulu 1 Sisältö 1) Mitä on hyvä koodi? 2) Ohjelmointikäytäntöjen merkitys? 3) Koodin asettelu
LisätiedotJohdatus diskreettiin matematiikkaan Harjoitus 5, Ratkaise rekursioyhtälö
Johdatus diskreettiin matematiikkaan Harjoitus 5, 14.10.2015 1. Ratkaise rekursioyhtälö x n+4 2x n+2 + x n 16( 1) n, n N, alkuarvoilla x 1 2, x 2 14, x 3 18 ja x 4 42. Ratkaisu. Vastaavan homogeenisen
LisätiedotJohdatus matematiikkaan
Johdatus matematiikkaan Luento 5 Mikko Salo 5.9.2017 The natural development of this work soon led the geometers in their studies to embrace imaginary as well as real values of the variable.... It came
LisätiedotAS Automaatio ja systeemitekniikan projektityöt Projektisuunnitelma Syksy 2009 A09 05 OSGi IRC Bot For Coffee Maker
AS 0.3200 Automaatio ja systeemitekniikan projektityöt Projektisuunnitelma Syksy 2009 A09 05 OSGi IRC Bot For Coffee Maker Henri Nieminen Juha Sironen Palautettu: 21.9.2009 Nieminen, Sironen Sisällysluettelo
LisätiedotT Ohjelmistojen määrittely- ja suunnittelumenetelmät Harjoitustyöraportti TNT - Tarkistetaan Ne Tentit Analyysimalli
T-76.611 Ohjelmistojen määrittely- ja suunnittelumenetelmät Harjoitustyöraportti TNT - Tarkistetaan Ne Tentit Analyysimalli Lasse Lindqvist Lasse Lopperi llindqvi@cc.hut.fi lmlopper@cc.hut.fi Andrey Rusanovich
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ätiedotAutomaattinen yksikkötestaus
Teknillinen Korkeakoulu T-76.115 Tietojenkäsittelyopin ohjelmatyö Lineaaristen rajoitteiden tyydyttämistehtävän ratkaisija L models Automaattinen yksikkötestaus Ryhmä Rajoitteiset Versio Päivämäärä Tekijä
LisätiedotYhtenäisyydestä. Johdanto. Lähipisteavaruus. Tuomas Korppi
Solmu 2/2012 1 Yhtenäisyydestä Tuomas Korppi Johdanto Tarkastellaan kuvassa 1 näkyviä verkkoa 1 ja R 2 :n (eli tason) osajoukkoa. Kuvan 2 verkko voidaan jakaa kolmeen osaan niin, että osien välillä ei
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ätiedotT-76.611 Ohjelmistojen määrittely- ja suunnittelumenetelmät
T-76.611 Ohjelmistojen määrittely- ja suunnittelumenetelmät Software design and specification methods Kurssin henkilökunta ja sponsori Luennoitsija DI Antti Karanta, Napa Oy www.napa.fi Assistentti TkL
LisätiedotTutoriaaliläsnäoloista
Tutoriaaliläsnäoloista Tutoriaaliläsnäolokierroksella voi nyt täyttää anomuksen läsnäolon merkitsemisestä Esim. tagi ei toiminut, korvavaltimon leikkaus, yms. Hyväksyn näitä omaa harkintaa käyttäen Tarkoitus
Lisätiedot3. Komponentit ja rajapinnat
3. Komponentit ja rajapinnat 3.1 Komponenttien idea: ohjelmistotuotannon rationalisointi 3.2 Mikä on ohjelmistokomponentti? 3.3 Komponentit ohjelmistoyksikköinä 3.4 Rajapinnat 3.6 Komponenttien räätälöinti
LisätiedotMallinnus. 5. Järjestelmämallit. Abstraktiot. Mallinnuksen etuja. Arkkitehtuurimalli. Yhteysmallit. Ohjelmistotuotanto, järjestelmämallit Kevät 2005
5. Järjestelmämallit Käyttäjävaatimukset pitää kirjoittaa luonnollisella kielellä. Niitä lukevat myös asiakkaat ja loppukäyttäjät. Järjestelmävaatimukset kannattaa kirjoittaa jollain rakenteisella kuvaustavalla.
Lisätiedot5. Järjestelmämallit. Mallinnus
5. Järjestelmämallit Käyttäjävaatimukset pitää kirjoittaa luonnollisella kielellä. Niitä lukevat myös asiakkaat ja loppukäyttäjät. Järjestelmävaatimukset kannattaa kirjoittaa jollain rakenteisella kuvaustavalla.
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ätiedotSpecifying user requirements for corporate intranet with user centered design methods. Espoo Tekijä: Henri Ström Valvoja: TkT Kalevi Kilkki
Specifying user requirements for corporate intranet with user centered design methods Espoo 29.9.2016 Tekijä: Henri Ström Valvoja: TkT Kalevi Kilkki Sisältö Työn tausta Ongelman asettelu Metodiikka Kehitysprojekti
LisätiedotTietorakenteet (syksy 2013)
Tietorakenteet (syksy 2013) Harjoitus 1 (6.9.2013) Huom. Sinun on osallistuttava perjantain laskuharjoitustilaisuuteen ja tehtävä vähintään kaksi tehtävää, jotta voit jatkaa kurssilla. Näiden laskuharjoitusten
LisätiedotOhjelmistojen mallintaminen, kesä 2010
582104 Ohjelmistojen mallintaminen, kesä 2010 1 Ohjelmistojen mallintaminen Software Modeling Perusopintojen pakollinen opintojakso, 4 op Esitietoina edellytetään oliokäsitteistön tuntemus Ohjelmoinnin
LisätiedotT740103 Olio-ohjelmointi Osa 5: Periytyminen ja polymorfismi Jukka Jauhiainen OAMK Tekniikan yksikkö 2010
12. Periytyminen Johdantoa Käytännössä vähänkään laajemmissa ohjelmissa joudutaan laatimaan useita luokkia, joiden pitäisi pystyä välittämään tietoa toisilleen. Ohjelmien ylläpidon kannalta olisi lisäksi
Lisätiedot$$$ Raha ratkaisee. $$$ Raha ratkaisee. Ohjelmistotuote. Ohjelmistotekniikan määritelmä
$$$ Raha ratkaisee On vaara rakastua tekniikkaan, myös asiakkailla Kaikki pitää pystyä perustelemaan taloudellisesti Projektin toteutus yleensä -> voidaan jättää toteuttamatta, jos ei maksa itseään takaisin
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ätiedotLiite 1. Laajennettu Eukleideen algoritmi suoraviivainen tapa
Liite 1. Laajennettu Eukleideen algoritmi suoraviivainen tapa - johdanto - matemaattinen induktiotodistus - matriisien kertolaskun käyttömahdollisuus - käsinlaskuesimerkkejä - kaikki välivaiheet esittävä
Lisätiedotja λ 2 = 2x 1r 0 x 2 + 2x 1r 0 x 2
Johdatus diskreettiin matematiikkaan Harjoitus 4, 7.10.2015 1. Olkoot c 0, c 1 R siten, että polynomilla r 2 c 1 r c 0 on kaksinkertainen juuri. Määritä rekursioyhtälön x n+2 = c 1 x n+1 + c 0 x n, n N,
Lisätiedot