OTUPK / Luento 24.9.2012 Uutisia Asiakasvaatimusten palauttamisen deadline on tämän viikon perjantaina klo 16. Päivän aiheet Esimerkki Luennon lopuksi taas yksi onneton tarina 1
Esimerkki Mukailtu kirjan Agile Software Development, Principles, Patters, and practices, Robert C. Martin. 2003 Esimerkistä 2
Palkanmaksuohjelmisto Tässä on yksinkertaistettu esimerkki Oikeat palkkahallinto-ohjelmistot ovat yllättävän kalliita ja monimutkaisia Googlehaku tuotti muutaman esimerkin (Esimerkkien valinnan suoritti google ) http://www.atsoft.fi/esitewpl.htm http://www.hogia.fi/toiminnot-hogiapalkassa/ http://www.ecom.fi/ohjelmistot/palkanlaskenta Ei kannata aloitta kaupallista ohjelmistotoimintaa tämän esimerkin perusteella. Varoitus: tämän esimerkin yhteydessä vilautamme koodiakin! 3
Asiakaspalaverin muistiinpanoja Systeemi perustuu tietokantaan jossa on kaikkien työntekijöiden tiedot. Kaikille työntekijöille maksetaan tämän systeemin kautta, oikea summa ja ajallaan. Osalla työntekijöistä on tuntipalkka (joka tietokannassa) Lähettävät joka päivä raportin jossa päivä ja tehdyt tunnit Jos tuntien määrä ylittää 8, ylimeneviltä tunneilta maksetaan 1.5 kertaisesti Tuntipalkkalaisille maksetaan palkka joka perjantai Osalla työntekijöistä kuukausipalkka Maksetaan kuun lopussa Myyntitehtävissä olevilla on lisäksi provisio tehdyistä kaupoista kuitin perusteella 4
Lisää muistiinpanoja Työntekijät voivat valita palkanmaksutavan Shekki (esimerkki on siis pankkitoiminnan kehitysmaasta Yhdysvalloista) Suoraan tilille Työntekijät voivat kuulua ammattiliittoon Tietokannassa on tiedot päivistä jolloin jäsenmaksut vähennetään palkasta Ammattiliitto voi myös laskuttaa lisämaksuja Palkanmaksuajo suoritetaan kerran päivässä Palkanmaksupäivänä maksetaan edellisestä kerrasta syntynyt kertymä Mietitään hetki mitä olisi mahdollisesti unohtunut 5
Käyttötapaus 1 Lisää uusi työntekijä Tietokanta AddEmp <EmpID> <name> <address> H <hourly-rate> AddEmp <EmpID> <name> <address> S <monthly-rate> AddEmp <EmpID> <name> <address> C <mpontly-rate> <bonus-%> Jos tiedoissa virhe, näytetään virheilmoitus 6
Käyttötapaus 2 Poista työntekijä Tietokanta DelEmp <EmpId> Virje jos työntekijää ei löydy tai EmpId muuten virheellinen 7
Käyttötapaus 3 Lähetä tuntiraportti Tietokanta TimeCard <EmpId> <date> <hour> Jos tiedoissa virhe jos - työntekijä ei ole tuntipalkkalainen - EmpId virheellinen 8
Aina voi miettiä lisää Pitäisikö tarkistaa onko tuntimäärä järkevä? Yli 0 Alle 24 Desimaaleja Entäs jos työntekijä on uusi, eikä vielä talletettu. Esimerkiksi asiaa hoitava ihminen sairaslomalla. 9
Käyttötapaus 4 Lähetä myyntitosite Tietokanta SalesReceipt <EmpId> <date> <amount> Näytetään virheilmoitus jos - työntekijä ei ole provisio-palkkauksen parissa - Tiedoissa muita virheitä 10
Käyttötapaus 5 Ammattiliiton lisämaksu Tietokanta ServiceCharge <memberid> <amount> Jos tiedoissa virhe, näytetään virheilmoitus 11
Käyttötapaus 6 (monta) Muuta tietoja Tietokanta ChgEmp <EmpId> Name <name> ChgEmp <EmpId> Address <address> ChgEmp <EmpId> Hourly <hourly-rate> ChgEmp <EmpId> Salaried <monthly-salary> ChgEmp <EmpId> Commissioned <monthly-salary> <rate> ChgEmp <EmpId> Hold ChgEmp <EmpId> Direct <bank> <account> ChgEmp <EmpId> Mail <address> ChgEmp <EmpId> Member <memberid> Dues <rate> ChgEmp <EmpId> NoMember 12
Kukahan nämä keksi? ChgEmp <EmpId> Name <name> ChgEmp <EmpId> Address <address> ChgEmp <EmpId> Hourly <hourly-rate> ChgEmp <EmpId> Salaried <monthly-salary> ChgEmp <EmpId> Commissioned <monthly-salary> <rate> ChgEmp <EmpId> Hold ChgEmp <EmpId> Direct <bank> <account> ChgEmp <EmpId> Mail <address> ChgEmp <EmpId> Member <memberid> Dues <rate> ChgEmp <EmpId> NoMember 13
Käyttötapaus 7 Aja palkkaajo Tietokanta Palkkalaskelma Pankki Laske kelle pitäisi maksaa palkka, kuinka paljon ja miten PayDay <date> 14
Välillä hieman suunnittelua Vaikka toimittaisiin ns. ketterien menetelmien mukaan on syytä miettiä tärkeimpiä suunnitteluratkaisuja ennen kuin rynnätään koodin kimppuun. Tietokanta, valinta ja tietomallin suunnittelu Tärkeä mutta sivuutamme tässä esimerkiksi Irrottaminen (decoupling) Looginen ajallinen 15
Looginen irrottaminen Ei näin Read command if (command == add) { read EmpId; check EmpId; if (ok) { transaction(); } else { error(); } } else (if command == ) { } Spagetti kelpaa lautaselle hyvän kastikkeen kera, mutta ei laadukkaaseen ohjelmaan 16
Vaan esimerkiksi näin Command Yhteiset ominaisuudet Komennon valinta AddEmp DelEmp TimeCard CheckEmpId CheckDate 17
Ajallinen irrottaminen Kuormitussyistä tietokanta operaatiot halutaan viivästyttää niin, että suoritus tapahtuu yöllä. 18
Pieni seikkailu koodin maailmaan import java.util.linkedlist; import java.util.iterator; public class ActiveObjectEngine { LinkedList itscommands = new LinkedList(); public void addcommand(command c){ itscommands.add(c); } public void run() throws Exception { while (!itscommands.isempty()) { Command c = (Command) itscommands.getfirst(); itscommands.removefirst(); c.execute(); } } } 19
Yhteinen koodi public interface Command { public void execute() throws Exception; } 20
Mitäs luulette? 21 6.9.2009
Jaa että oliko valmis määrittely? Verotus, ennakonpidätys Palkkatodistusten kirjoitus Lomat, sairaslomat Viikonlopputyöt, arkipyhät Autoedut, matkapuhelinedut Ulosotto Matalapalkkatuki Sitominen yrityksen kustannuspaikkoihin ja projekteihin Suorat pankkiyhteydet (SEPA) Erilaiset raportit Matkalaskut eri systeemissä? 22
Entäs kuka on? Käyttötapauskuvissa fuskattiin. Pitäisi miettiä Kuka/ketkä käyttää? Milloin käyttää? Missä yhteydessä? Jos järjestelmä ei sovi varsinaisten käyttäjien tarpeisiin sen käyttö tulee kalliiksi. Projektissa asiakkaan edustajan pitää muistaa myös tämä johdon asettamien liiketoimintatavoitteiden lisäksi. 23
Ja millaisia vaikutuksia tällä on? 24
Testaus, laadunvarmistus Palautetaan mieleen edellisten luentojen kuva Asiakkaan ongelma asiakasvaatimukset Määrittely Suunnittelu ohjelmistovaatimukset, määrittely tekniset vaatimukset, suunnittelu Toteutus asiakastoimitus Seuraava versio Hyväksymistestaus 6.9.2009 25
työmäärä Mietitääs SCRUM-koneen käynnistämistä Sprintissä toteutettavat tehtävät, aika-arviot päivitetään päivittäin Daily Scrum Meeting: 15 min: Edistys edellisestä palaverista? Ovatko aika-arviosi kunnossa? Mitä teet seuraavaksi? Onko ongelmia näkyvissä? Sprint burndown chart: aika Sprint planning meeting: 4+4 tuntia: tuotteen omistaja esittelee Product backlogia Tiimi päättää, mihin voi sitoutua Riittävästi tietoa? 30 päivän pyrähdys (sprint) Sprint Review Meeting (4 tuntia): Tiimi esittelee tuloksen omistajalle tuotteen inkrementti The Sprint Retrospective (3 tuntia): miten asiat saataisiin sujumaan paremmin seuraavassa pyrähdyksessä Requirements Valmiita? 6.9.2009 26
Mietittävää ja päätettävää Kuinka kauan vain tarkennetaan asiakasvaatimuksia? Tätäkin työtä voi tehdä SCRUM-rytmillä Missä vaiheessa ja kuinka tarkasti mietitään arkkitehtuuria Mikä osuus valitaan ensiksi toteutettavaksi Käyttäjälle arvokkain? Projektin kannalta riskipitoisin? 27
Pyrähdyksen alussa oleva Sprint Planning on tärkeä (varsinkin ens. pyrähdyksessä) Toteutustiimi tyypillisesti etsii abstraktioita, yhteisiä toiminnallisuuksia. Jotta tuloksena oleva järjestelmä olisi ylläpidettävä Jos keskittyy vain yhteen tapaukseen tulee helposti virheitä Jos taas ottaa kaikki huomioon, kestää liian kauan siihen että saadaan ensimmäinen asiakaspalaute Ja rahaa on palanut liikaa Esimerkki seuraavalla kalvolla 28
AddEmp <EmpID> <name> <address> H <hourly-rate> AddEmp <EmpID> <name> <address> S <monthly-rate> AddEmp <EmpID> <name> <address> C <mpontly-rate> <bonus-%> Siis meillä on kolme erilaista työntekijä ryhmää. Tämä voitaisiin ottaa suunnittelun pohjaksi? ChgEmp <EmpId> Name <name> ChgEmp <EmpId> Address <address> ChgEmp <EmpId> Hourly <hourly-rate> ChgEmp <EmpId> Salaried <monthly-salary> ChgEmp <EmpId> Commissioned <monthly-salary> <rate> ChgEmp <EmpId> Hold ChgEmp <EmpId> Direct <bank> <account> ChgEmp <EmpId> Mail <address> ChgEmp <EmpId> Member <memberid> Dues <rate> ChgEmp <EmpId> NoMember Tyyppi voikin muuttua! Entä onko mahdollista, että voi tulla uusia tyyppejä? 29
On investointi Muunneltavuuden haasteesta Vaikea keksiä mitä oikeasti tullaan muuntamaan Onneton esimerkki: 30
Kun vihdoin tiedetään tarpeeksi hyvin mitä ollaan tekemässä Toimittaja suunnittelee ketkä projektiin osallistuvat Toimittaja ja asiakas tarkentavat yhdessä aikataulun (Olettaen että valitaan SCRUM tai joku muu ketterä menetelmä) asiakas huolehtii siitä, että kunkin pyrähdyksen jälkeen saadaan riittävä asiakas ja käyttäjäpalaute Suunnitellaan järjestelmätestaus ja käyttöönotto 31
Järjestelmätestaus/hyväksymistestaus Usein asiakas osallistuu testaukseen vasta tässä vaiheessa Valitettavasti joskus ei vielä tällöinkään Tässä vaiheessa voi olla jännitteitä Toimittaja haluaa rahansa ja haluaa että virheiden korjaus on jatkossa erikseen laskutettavaa työtä Asiakas haluaa täydellisen järjestelmän 32
Käyttöönotto Rajattu oppikirjamme ulkopuolelle Kuitenkin tärkeä asia Mietittäviä asioita Siirrytäänkö yhdessä yössä vanhasta järjestelmästä uuteen Vai hetken aikaa rinnakkain Vai pala kerrallaan Miten siirretään tiedot vanhasta uuteen Tarvitaanko käyttäjille koulutusta Käyttöönotto voi olla oma projektinsa 33
Kertausta Ensimmäisen asiakaspalaverin muistiinpanoista on pitkä matka lopullisiin vaatimuksiin. Järjestelmät ovat monimutkaisempia kuin aluksi näyttävä. Räätälöidyn järjestelmän määrittelyssä asiakas-toimittaja yhteistyön on toimittava 34
Tämän viikon sattumus Ariane 5 kantoraketin onnettomuus 35
Ariane 5 - analyysi 64bittinen liukuluku muunnettiin 16-bittiseksi kokonaisluvuksi Tällä kertaa syntyi ylivuoto Olisi syntynyt Ada-kielen poikkeus (tämä ohjelmointikielen rakenne on suunniteltu jotta voitaisiin reagoida tällaisiin virheisiin turvallisesti), mutta poikkeukset oli tehokkuussyistä otettu pois käytöstä. Joten laskun tulos oli ns potaskaa Vääristyneiden mittausarvojen tuloksena ohjausraketit yrittivät massiivista korjausliikettä Ylivuoto syntyi koska Ariene 5:n suorituskyky oli suurempi kuin edeltäjän (Ariane 4) mutta Arian 5 uudelleen käytti vanhan järjestelmän softaa Ylivuotoon joutunut järjestelmä oli vikatilanteiden vuoksi kahdennettu mutta ajoi samaa ohjelmistoa 36
Ariane 5 Ylivuotoon joutunut järjestelmä oli tarpeen vain silloin kun raketti vielä seisoo laukaisualustalla ja se oltaisiin voitu ottaa jo pois päältä Ongelmana oli vaakanopeus jonka kukaan ei ollut uskonut kasvavan liian suureksi L_M_BV_32 := TBD.T_ENTIER_32S ((1.0/C_M_LSB_BV) * G_M_INFO_DERIVE(T_ALG.E_BV)); if L_M_BV_32 > 32767 then P_M_DERIVE(T_ALG.E_BV) := 16#7FFF#; elsif L_M_BV_32 < -32768 then else P_M_DERIVE(T_ALG.E_BV) := 16#8000#; P_M_DERIVE(T_ALG.E_BV) := UC_16S_EN_16NS(TDB.T_ENTIER_16S(L_M_BV_32)); end if; P_M_DERIVE(T_ALG.E_BH) := UC_16S_EN_16NS (TDB.T_ENTIER_16S ((1.0/C_M_LSB_BH) * G_M_INFO_DERIVE(T_ALG.E_BH))); 37
38