Loppuraportti - DigiaMinions/Project GitHub Wiki

LOPPURAPORTTI

1. JOHDANTO

Tämä dokumentti käsittelee projektin retrospektiiviä, sisältäen onnistumiset ja ongelmat.

Projektissa oli päämääränä tuottaa vaihtoehtoinen stack-rakenne toimeksiantajalle IoT-ympäristöön. Toimeksiantajana toimi Digia Finland Oy, toimeksiannon vastaanottajana toimi Jyväskylän Ammattikorkeakoulun IT-instituutti ja projektin tekijöinä toimivat Jyväskylän Ammattikorkeakoulun ohjelmistotekniikan oppilaat ryhmänimellä DigiaMinions.

2. TEHTÄVÄ, TAVOITE, TULOKSET

Toimeksiantona oli rakentaa pilvipalveluita hyödyntävä stack IoT-ympäristöön, jossa ei saanut käyttää tietyn toimeksiantajan jo käyttämän stackin teknologioita. Rakenteessa piti olla mahdollisuus kaksisuuntaiseen kommunikaatioon pilvipalvelun ja IoT-laitteiden välillä. Näissä puitteissa projektiryhmä sai itse valita mitä tehtäisiin. Lisätoiveena esitettiin että stackissa minimoitaisiin palvelinten käyttö, se olisi skaalautuva, sen saisi pystytettyä automoidusti ja että projektissa käytettäisiin jatkuvaa integraatiota, testausta ja julkaisua.

Aiheeksi valikoitui lopulta pilvestä käsin käytettävä lemmikin ruokkimislaite, jolla voitaisiin websivulla nappia painamalla antaa annos ruokaa välittömästi, tai vaihtoehtoisesti annostelua voitaisiin ajastaa. Ruoan määrää oli tarkoitus tarkkailla painoanturilla ja kameralla, joiden syötteet näkyisivät verkkosivulla.

2.1. Yhteenveto projektin toteumasta

Projektissa onnistuttiin vaatimuksien puitteissa, mutta osa toiveista ja kaavailluista toiminnallisuuksista jouduttiin valitettavasti jättämään toteuttamatta. Projektiryhmä tuotti rakennelman, joka syöttää ruokaa käyttöliittymästä valittuina ajankohtina ja näyttää painoanturin datan käyttäjä- ja laitekohtaisesti käyttöliittymässä.

2.2. Projektin onnistuminen (suunnitelma vs. toteutuma)

Projekti tehtiin scrumilla sprinteissä ja ryhmä kokoontui tekemään projektia tarkoitusta varten annettuun projektitilaan arkipäivisin. Projektia varten tehtiin aikataulu sprintillä 0, mutta stackrakenteessa ilmenneiden ongelmien vuoksi siitä jouduttiin joustamaan voimakkaasti. Siitä eteenpäin projektissa edettiin ketterästi ja sprinttien tavoitteita ja aikataulua määriteltiin uudelleen sitä mukaa kun ongelmia tuli ja niitä saatiin ratkottua.

Suunnitelmassa pyrittiin välttämään palvelinten käyttöä, mutta siinä ei onnistuttu sillä osa käytetyistä teknologioista vaati palvelimen toimiakseen (Grafana, Graphite, verkkosivu).

Projektin alkuperäinen aikataulu on nähtävissä Aikataulu -sivulla. Projektin tarkempi viikottainen toteuma henkilöittäin on nähtävissä Trellossa ja yleisempi kuvaus aikaisempien viikkojen edistymiset -sivulla. Alkuperäinen aikataulu ja aikaisempien viikkojen edistymiset lisätään liitteeksi tähän dokumenttiin.

3. ONGELMAT JA NIIDEN RATKAISUT

Projekti ei valmistunut ongelmitta. Tässä luvussa käsitellään ongelmia ja niiden ratkaisuja projektin aikana.

###3.1. Ongelmat suunnittelussa Suunnitteluvaiheessa oli vapaat kädet maailmassa missä oli paljon tuntemattomia tekijöitä, kuten amazon palvelut ja muut teknologiat, joten oli vaikea hahmottaa mitä sitä haluttaisiin ylipäänsä tehdä. Projektin aiheen valinta vei oman aikanasa alussa.

Myöhemmin, kun projektin aihe oli saanut tarkemman määrittelyn, oli vaikea aikatauluttaa projektin vaiheet tarkasti. Kellään ryhmässä ei ollut ammattimaista kokemusta projektien tekemisestä tai niiden aikatauluttamisesta. Lisähaasteita aikatauluttamiseen toivat uudet teknologiat ja niiden yhteensovittaminen, joiden aikaavievyys oli vaikea hahmottaa. Ulkopuolista konsultaatiota ei voinut myöskään järkevästi hakea, sillä käytettävät teknologiat olivat vielä siinä vaiheessa määrittelemättä - joka oli myös ryhmän tehtävä. Ongelmaan ei nähty muuta ratkaisua kuin tuottaa karkea aikataulu, josta odotetusti joustettiin ketterästi.

Projektiryhmälle mainittiin myös useaan kertaan dokumentista, jossa oli listattuna teknologioita jotka olivat ennestään tuttuja toimeksiantajalle ja siten vähemmän arvokkaita heille projektissa käytettäväksi. Projektiryhmä ei koskaan saanut tai nähnyt tätä dokumenttia.

###3.2. Ongelmat toteutuksessa

Testit

Jatkuvan julkaisun ketju saatiin pystytettyä ja koodi buildattiin ennen julkaisua, mutta reactin yksikkötestien tekemisessä ilmeni ongelmia, joka olisi vaatinut suuria muutoksia reactin koodiin. Testien tekeminen meni jäihin hetkeksi aikaa ja lopulta päätettiin toteuttaa vain pintapuolinen testaus julkaisuketjussa, jonka tarkoitus oli lähinnä todentaa testauksen toimivuus.

Tilaukset

Joitain osia jouduttiin odottamaan aika pitkään, ennen kuin ne saapuivat käytettäväksi. Servojen tilaus jouduttiin tekemään uudelleen toiselta toimittajalta, sillä haluttuja servoja ei voitu toimittaa robomaasta.

Kamera

Ryhmä ei keksinyt keinoa miten kameran syöte saataisiin käyttäjälle verkkosivulle. Kamera jäi siis hyödyntämättä.

AWS sisäverkon yhteysongelmat

Osa virtuaalikoneista ei kyennyt ottamaan yhteyttä toisiinsa sisäverkon osoitteiden kautta, vaan jouduttiin käyttämään julkisia osoitteita. Sisäverkon osoitteisiin pystyi pingaamaan, mutta yhteyttä ei saanut. Ongelmaa ei ratkaistu vaan se kierrettiin käyttämällä julkisia osoitteita.

###3.3. Toteutuneet riskit ja niiden käsittely

Projektitilan koneissa ongelmia (RIS10)

Koulun verkossa tapahtui jokin virhe projektin aikana, jonka tuloksena usean koneen käyttöjärjestelmät asennettiin uudelleen ja levykkeet formatoitiin. Tietoa projektista ei onneksi kadonnut juurikaan, sillä tuotokset olivat versionhallinnassa. Ainoa kadonnut asia oli yhden virtuaalikoneen avain, josta ei koitunut ongelmia.

Valittu stackin osa ei toteuta haluttua toiminnallisuutta (RIS12)

Tutkittujen teknologoiden dokumentaatioissa ei ollut helposti tai nopeasti selvitettävissä vastaisivatko ne ryhmän tarpeita tarkalleen. Erityisesti ongelmia oli stackin visualisointi- ja analysointipalikoiden sopivuus tuotteeseen, sillä haluttiin että dataa saataisiin embedattua omalle sivulle pilveen ja dokumentaatiot olivat melko karkeita kyseistä aihetta koskien. Ongelmaa lähestyttiin yrityksen ja erehdyksen kautta ja lopulta löydettiin tarkoitukseen sopivat teknologiat, mutta riski ehti toteutua monta kertaa. Lähestymistapa näkyi aikataulussa pysymisessä, sillä ryhmä testasi useita vaihtoehtoja. Lopulta päädyttiin käyttämään Graphitea ja Grafanaa, sillä ne olivat ainoat löydetyt teknologiat joilla haluttu toiminnallisuus onnistuttiin toteuttamaan.

4. YHTEENVETO

Ryhmä näki projektin onnistuneena vaikeuksista huolimatta. Lopullinen tuotos tekee sen mitä luvattiin ja sen toteutuksessa on käytetty uudempia teknologioita.

4.1. Keskeiset opit

Jokainen ryhmässä oppi uusia asioita projektin aikana ja kehittyi ammatillisessa osaamisessaan.

Ryhmän jäsenten ajatuksia projektista ja opituista asioista

Janne Möttölä

Scrum oli hyvä toimintamalli projektille, sillä tarve ketterälle kehitykselle ilmeni melko nopeasti. Keskeisimpiä oppeja minulle oli tehtävänjaon yhteen paikkaan keskittämisen tärkeys, ReactJS ja pitkä lista amazonin pilvipalveluita. Ennen projektin alkua käytetyt teknologiat olivat suurimmaksi osaksi tuntemattomia, mutta ne tulivat tutuiksi projektin aikana melko hyvin ja oppi menee varmasti käyttöön tulevaisuudessa. Eritoten Lambda oli tervetullut tuttavuus konseptitasolla ja ReactJS huomattava edistysaskel verrattuna ensin koulussa oppimaani html/javascript/ajax/php -pakettiin.

Kurssi oli kaikenkaikkiaan erittäin arvokas kokemus, sillä sen aikana opin uudempia web- ja IoT-teknologioita käytännössä kahden kurssin edestä. Projektin aikana vahvistin myös työrutiinejani ja sain paljon paremman kosketuksen oikeaan työelämään ja asiakasrajapintana toimimiseen.

Miika Avela

Kokemus Amazonin palveluista ennen projektin alkua oli täysin olematon ja suurimpana positiivisena yllätyksenä tuli vastaan AWS IoTin ja Lambdan helppokäyttöys sekä edullisuus mietittäessä omia tulevaisuuden projekteja. Opin ulkoisten palveluiden, kuten tässä projektissa Github, yhdistämisestä AWS:n palveluihin SNS viestien ja AWS Lambdan avulla. Myös AWSn palveluiden tietoturva kävi tutuksi, mihin haluaisin silti jatkossa keskittyä enemmän ymmärtääkseni rooleista ja policyista paremmin. Suurimman osan projektista keskityin laitepuoleen ja laitteen väliseen kommunikaatioon AWS IoTin, tietokannan ja loppukäyttäjän välillä. Laitepuolella uusina aiheina opin Bash-skriptauksen, rautatason laitteiden välisen kommunikoinnin, sekä laajensin näkemystäni hyvästä ohjelmointitavasta Pythonilla. Tämä aiheutti kuitenkin muunmuassa sen, etten juuri ymmärrä React-toteutuksesta. Huomasin kuitenkin Reactin valtavan merkityksen ja aion paneutua tähän enemmän vapaa-aikanani. Uutena hyvänä tuttavuutena tuli NoSQL-tietokanta, kun kaikki aiempi kokemus on vain MySQL-pohjaista. Kävin myös läpi suuren määrän erilaisia työkaluvaihtoehtoja datan visualisoinnille NoSQL-tietokannasta ja selvitin tapoja visualisoidun datan embeddaukselle toisaalle.

Aleksi Vuorela

Projektin suurin oppi minulle oli React. Kuulin sen olevan kova sana tällä hetkellä frontin työstämiseen ja halusin oppia sen käytön projektin aikana. Ehdotin Petrille sen käyttöä projektissa, ja hän sai järkättyä katselmoinnin Digian fronttiarkkarin kanssa, josta oli valtavasti apua. Tykästyin Reactiin ja sain jopa työpaikan React hommien parista. Reactin opiskelun yhteydessä opin myös paljon JavaScript ohjelmointiin liittyviä asioita (ES6, Babel, Webpack). JavaScript on webdevauksessa valtavassa asemassa tällä hetkellä, ja onkin kummallista, ettei sitä ole opetettu koulun aikana juuri yhtään.

Muita tärkeitä oppeja projektin aikana olivat API tyylisen backend toteutuksen tekeminen (NodeJS/ExpressJS) ja sen kanssa keskustelu frontista Fetchillä. AWS:n palveluista minulla ei ollut myöskään mitään käsitystä entuudestaan. Niistä työskentelin eniten EC2 virtuaalikoneen ja CI/CD-putken (AWS CodePipeline, Github, AWS CodeBuild, AWS CodeDeploy) kanssa. Yhteenvetona voin sanoa, että opin projektin aikana paljon enemmän kuin millään tavallisella kurssilla (ja mielekkäitä, kuuminta huutoa olevia asioita!).

Työskentelytapoina/työkaluina olivat kovassa käytössä vanhat tutut ja hyväksi todetut Scrum & Slack.

Marko Leppälahti

Amazonin pilvipalvelusta oli hiukan kokemusta AWS IoT rajapinnan ja lambdan osalta ennen projektin alkua. Projektin edetessä näistäkin kuitenkin pääsi oppimaan uutta etenkin tietoturvan kannalta. AWS:n IAM rooleihin olisi ollut mukava ehtiä tutustua vähän syvällisemmin, koska niihin ehtisi tutustua projektin aikana vain vähäisimmän tarvittavan määrän, jolla kaikki tarvittava saatiin toimimaan. Uudet tuttavuudet projektissa olivat Cloudformation ja Codebuild. Molemmat näistä ovat erittäin käytännöllisiä työkaluja ja Cloudformationia tulen varmasti käyttämään myös tulevaisuudessa.

Sami Autio

Oppimista kertyi AWS:n eri palveluista, sekä niiden integroimisesta yhteen. Stackissa oli myös oikeastaan kaikki käytössä olleet palikat semmoisia, joita ei ollut aikaisemmin tullut käytettyä. Graphite/Carbon tietokantanaan on jo hyvin erilainen verratuna ennestään tutumpiin SQL-kantoihin, joten semmoistakin oli ihan mukava päästä pystyttämään ja kokeilemaan. React oli myös kiinnostusta herättävä, vaikken itse loppupelissä siihen tullut juuri koskeneeksikaan. Mahdollisesti tulevaisuudessa tulee sitä harkittua toisen projektin kohdalla.

Työskentely oli aluksi hyvinkin yhteneväistä ryhmässä olleiden kanssa, kunnes alkuperäiset suunnitelmat muuttuivat ja homma muuttui hyvinkin ketteräksi. Siinä pisteessä ehkä jokaiselle alkoi muodostumaan oma alue toteutuksessa, jota sitten alkoi itsenäisemmin viemään eteenpäin. Itse pyrin silti aikalailla pyörimään vähän jokaisen tontilla ihmettelemässä ja kyselemässä, jotta oppisin vähän niistäkin asioista sekä siksi, että kokonaiskuva pysyisi paremmin ainakin itselläni kasassa.

Työvälineistä tussitaulu osoittautui aika tärkeäksi työvälineeksi, kun kokonaiskuvaa, integrointeja sekä visioita pyrittiin selventämään tiimin kesken. Keskusteluväylänä käytössämme oli Slack sekä Whatsapp, joista varsinkin Slack tuntui erittäin kätevältä, kun sieltä saavutti myös asiakkaan päästä väkeä tarvittaessa. Whatsapp oli lähennä kiireellisempien viestien läpi menemisen varmistamiseksi, jos jollakulla Slack ei ollut niin nopeasti saatavilla. Käytössä oli myös Trello tiketteineen, josta oli apua vaihtelevasti.

4.2. Itsearviointi

Ryhmä oli vahvasti itse ohjautuva, eikä ollut epäselvyyksiä siitä kuka hyppäisi mihinkäkin rooliin. Jokainen löysi itselleen mieluista tekemistä projektista ja kaikkien panos näkyy lopputuloksessa.

4.2.1. Ryhmätyö

Tiimi ryhmäytyi ja pääsi tekemisen makuun nopeasti. Näkemyseroja löytyi projektin aikana, mutta niistä päästiin eteenpäin hyvillä mielin, eikä vakavia kriisejä ryhmän sisällä syntynyt. Projektissa ilmenneitä ongelmatilanteita ei pelätty tuoda esille ja ne ratkaistiin ryhmässä silloin kun yksilöllä oli vaikeuksia. Kommunikointi toimi ja siten myös projektin eri rajapintojen integrointi toisiinsa toimi ilman suurempia ongelmia.

Työ jakautui hieman epätasaisesti sillä osalla ryhmästä oli muitakin kursseja kehitystyön aikana ja olivat poissa siksi, tai poissa muista syistä, mutta se ei tuottanut ongelmia kokonaisuuden kannalta. Projektitila oli aktiivisessa käytössä ja projektia vietiin jatkuvasti eteenpäin.

Projektipäällikkö jakoi tehtäviä muille tiimin jäsenille sitä mukaa kun niitä kyettiin ottamaan vastaan ja toimi rajapintana ryhmän ja projektin omistajan välillä. Hän hallinnoi trelloa, statussivua ja raportoi projektin omistajalle projektin etenemisestä ja yleisestä tilanteesta.

Jokaisella oli tehtävää projektin alusta sen loppuun saakka ja jokainen erikoistui osaamisessaan projektin osalta. Tietoa pyrittiin jakamaan useammalle kuin yhdelle henkilölle jokaisesta osa-alueesta, jotta poissaolojen sattuessa kehitystyö ei jumiutuisi.

Tukiryhmää hyödynnettiin niukasti, sillä suurimmaksi osaksi projektiryhmällä oli selkeä näkemys siitä kuinka edetä. Projektiryhmän jäsenet osasivat tutkia ja hakea tietoa itsenäisesti silloin kun sille ilmeni tarve.

Ryhmä raportoi kurssin ohjaajille projektin etenemisestä ja sen toimintamalleista. Ohjaajat antoivat ehdotuksia ja huomauttelivat kipukohdista joihin ryhmän tulisi paneutua.

Katastrofit vältettiin projektin aikana, vaikka haasteita oli runsaasti.

4.2.2. Suunnitelmallisuus (projektityöskentely)

Aihepiirin tuntemattomuuden vuoksi alusta asti oli selvää että kehitystyö menee ketteräksi ennemmin tai myöhemmin, joten projektin suunnitelmia ei pidetty absoluuttisina määrittävinä tekijönä. Suunnitelmiin kuului stack-rakenne, hahmotelma laitteen ulkomuodosta ja aikataulu projektin toteuttamisesta. Aikataulua ei päivitetty projektin aikana kirjallisesti, vaan pidettiin keskustelemalla yleiskäsitys siitä mitä pitäisi olla milloinkin valmiina.

Kirjallista aikataulua olisi voitu päivittää jatkuvasti sitä mukaa kuin muutoksia aikatauluun tuli, mutta projektipäällikkö koki sen aiheettomaksi erinäisistä syistä. Aikataulun laatimiseen vaaditaan ammatillista osaamista projektityöskentelyn sekä käytettyjen teknologioiden parissa, jota ryhmäläisillä ei ollut vielä hallussaan. Muutoksia tuli myös tiuhaan tahtiin ja siten eksaktin aikataulun ylläpitoon olisi uponnut paljon aikaa jota voitiin hyötykäyttää muualla, kuten teknologioiden opettelussa. Toimintamalli ei tuottanut ongelmia, mutta jälkeenpäin tarkasteltuna syy tähän lienee projektin lyhyydessä. Lyhyttä projektia on helpompi hallita. Mikäli kyseessä olisi ollut suuri projekti, niin aikataulu olisi ollut silloin keskeisempi ja sitä varten projektissa olisi täytynyt olla joku joka osaa arvioida paremmin tekemiseen kuluvan ajan.

Projektipäällikkö valvoi projektin etenemistä ja varmisti että korkean prioriteetin asiat tulivat tehdyiksi riittävän nopeasti. Mikäli näytti siltä että pitäisi kiirehtiä, niin tehtävään allokoitiin lisää tiimin jäseniä. Tehtävien allokointi tapahtui trellossa sekä suullisesti. Annetut tehtävät eivät ilmestyneet aina välittömästi trelloon, mutta trelloon jäänyt lista asioista on melko hyvä kuvaus aikaansaannoksista.

Kun palavereja pidettiin, niiden keskeiset pointit kirjattiin tiimin sisäiselle slack-kanavalle muistiin, jossa ne olivat kaikkien ryhmän jäsenten saatavilla.

4.2.3. Vuorovaikutus

Projektin sidosryhmiä olivat

  • Projektiryhmä
  • Ohjaajat
  • Projektin omistaja
  • Toimeksiantaja
  • Tukiryhmä
  • Loppukäyttäjä

Projektin alussa projektiryhmä tapasi toimeksiantajan edustajan, josta tuli myöhemmin myös projektin omistaja. Tapaamisessa keskusteltiin toimeksiannosta ja teknologioista.

Projektin aikana pääasiallinen ryhmän vuorovaikutus muiden sidosryhmien kanssa tapahtui slack-kanavilla. Projektin puolessa välissä otettiin käyttöön viikottainen puhelinsoitto, jolla raportoitiin projektin omistajalle yleinen tilanne, tuntemukset, etenemiset ja ongelmat.

Kaikkia projektiryhmän ulkopuolisia sidosryhmiä pidettiin ajan tasalla etenemisestä ylläpitämällä statussivua, joka kattoi kuluvan viikon tilanteen. Sitä mukaa kun siirryttiin viikoissa eteenpäin, statussivun tiedot siirrettiin erilliseen dokumenttiin jossa lueteltiin aikaisempien viikkojen etenemiset.

Statussivuilla tiedottamisen lisäksi sidosryhmien kesken oli erillisiä tapaamisia, joihin valmistauduttiin kertaamalla avoimet kysymykset, yleistilanne, mitä on tehty ja mitä ollaan tekemässä. Tapaamisia pidettiin epäformaalisti, joten erillisiä kirjallisia agendoja tai pöytäkirjoja ei laadittu.

Ohjaajat järjestivät satunnaisia tapaamisia, joihin projektipäällikkö osallistui ja raportoi tilanteesta. Myös tukiryhmän henkilöiden kanssa tavattiin joitain kertoja - tapaamisissa kyseltiin asiantuntevaa neuvoa ja esiteltiin senhetkisiä tuotoksia.

Johtoryhmässä hoidettiin päätökset projektin suunnasta ja rajauksista. Erillisiä täysiä johtoryhmän tapaamisia ei erikseen pidetty, vaan päädyttiin hoitamaan koordinointi ketterästi keskustelemalla etänä viikottain tai tarpeen tullen. Näin vältettiin tarpeeton jähmeys toiminnassa.

Eri sidosryhmien vuorovaikutus projektiryhmän kanssa näkyy projektin lopputuloksessa positiivisesti. Käytännöt eivät olleet liian jähmeitä jotta ne olisivat haitanneet projektityöskentelyä, eivätkä myöskään liian löysiä jolloin projektin suunta olisi saattanut olla epäselvä. Tapaamisten aikatauluissa kyettiin joustamaan puolin ja toisin tarpeen tullen. Aina kun tykiryhmää hyödynnettiin, siltä saatu apu oli asiantuntevaa, asiallista ja arvokasta.

4.2.4. Asenne

Alusta saakka ryhmä asennoitui tarmokkaasti projektiin, jossa haasteisiin tartuttiin rohkeasti ja niistä selvittiin ansiokkaasti. Uusia asioita ei pelätty eikä ongelmien edessä murruttu. Jokainen asennoitui oppimiseen innokkaasti. Kun palautetta saatiin, se otettiin vastaan ja siihen reagoitiin asiaankuuluvalla tavalla.

4.2.5. Tulos

Projektin tulos vastaa toimeksiannon vaatimuksia, vaikka kaikkia projektin aikana esitettyjä toiveita tai optioita siinä ei kyettykkään toteuttamaan. Projektissa tuotettiin laite, jossa ei ole käytetty toimeksiannossa poissuljettuja teknologioita.

Kirjautunut käyttäjä voi hallinnoida omia laitteitaan pilvipalveluiden kautta ja tieto kulkee laitteiden ja pilven välillä kahteen suuntaan. Järjestelmä toteuttaa sille kaavaillun toiminnallisuuden pääpiirteittäin. Ryhmän jokainen jäsen laajensi ammatillista osaamistaan huomattavasti projektin aikana ja ryhmän koulutustasoon suhteutettuna tulos on hyvä.

Tuotosta voi laajentaa esimerkiksi karjan ruokkimiseen tai järjestelmään voi lisätä vaihtoehtoisia laitteita joissa on erityyppiset anturit.

Projektissa ei keksitty pyörää uudelleen, mutta toimeksiantajalle toimitettiin tuote joka vastaa annettuja määritelmiä. Kokemuksena projekti oli äärimmäisen arvokas ryhmän jäsenille ja tulokseen ollaan tyytyväisiä.

4.3. Arvosanaehdotukset

5.

Ryhmä toimitti mitä vaadittiin.

LIITTEET

  • Alkuperäinen aikataulu
  • Aikaisempien viikkojen edistymiset