SAP-ohjelmistojen laadun kehittäminen monitoimittajaympäristössä - case Elisa
description
Transcript of SAP-ohjelmistojen laadun kehittäminen monitoimittajaympäristössä - case Elisa
Nobultec Oy Mikko Mäki-Rahkola 23.9.2010
SAP-ohjelmistokehityksen laadun kehittäminen
monitoimittajaympäristössä
Case Elisa
Nobultec lyhyesti
YrityksestäPerustettu 2005
Suomen johtava prosessien tehostamisen asiantuntijatalo, työvälineenä SAP
12 työntekijää
Tärkeimmät palvelutProcess Scanning
- Palvelu, jolla tunnistetaan prosessialueen tärkeimmät kehitysalueet
Process Audit
- Palvelu, jolla selvitetään yhden prosessin nykytila ja suunnitellaan
prosessille tavoitetila tehokkuuden parantamiseksi
Nobultec Method
- Prosessin tehostamisratkaisun toteuttamispalvelu
Process Care
- Menetelmä prosessin jatkuvan kehittymisen varmistamiseksi
RatkaisutOptimoidut lomakepohjaiset prosessit (HR, taloushallinto and logistiikka)
AsiakkaitaTeliaSonera, Nordic Investment Bank, Metso Minerals, Woikoski, Jyväskylän
kaupunki, Helsingin yliopisto, Comptel, Sanoma Magazines, Elisa, Basware
27.9.2010 Copyright 2010 Nobultec Oy 2
27.9.2010 Copyright 2010 Nobultec Oy 3
MITÄ LAATU ON?
MIHIN SITÄ TARVITAAN?
Mitä ohjelmistokehityksen laatu on?
Laatu = yhteensopivuus vaatimuksiin– laatu on aina subjektiivinen kokemus
– laadun merkitys ja vähimmäistaso on asiakkaan
määriteltävissä
– laadukas = vaatimustaso asetettu ja siihen ollaan päästy
Laadun ulottuvuuksia– vaatimusten ulottuvuuksien ja niihin vastaavuuden mukaan:
• Toiminnalliset vaatimukset
• Käytettävyysvaatimukset
• Luotettavuusvaatimukset
• Suorituskykyvaatimukset
• Tuettavuusvaatimukset
• Suunnittelu-, toteutus-, liittymä- ja rautavaatimukset
27.9.2010 Copyright 2010 Nobultec Oy 4
Mihin laatua tarvitaan? 1/3
Laatu on vaatimuksien täyttämistä– loppukäyttäjien ja asiakkaan tyytyväiseksi saaminen
asetettuihin vaatimuksiin vastaamalla
Laadun ulottuvuuksien mukaan– Toiminnallisuudet: Ohjelmiston tarkoituksen täyttäminen
– Käytettävyys: Käyttäjien tyytyväisyys ja käytön helppous
Koulutus- ja tukikustannukset alas
– Suorituskyky: Vakaa ja suorituskykyinen käyttö
–Tuettavuus: Esim. konfiguroitavuus
=> ylläpitokustannukset alas
– Suunnittelu-, Esim. yhteiset suunnittelu- ja toteutus-
toteutus-, liittymä- käytännöt => ylläpitokustannukset alas
ja rautavaatimukset
27.9.2010 Copyright 2010 Nobultec Oy 5
Mihin laatua tarvitaan? 2/3
Mihin SAP-käyttäjäyritykset tarvitsevat laatua?– laadukkaat ohjelmistotuotteet:
• Täyttävät tarkoituksensa
• Toimivat vakaasti, tietoturvallisesti ja suunnitellulla tavalla
• Ovat joustavia muutostilanteissa
• Ovat nopeita ja kustannustehokkaita ylläpitää ja muuttaa
• Ovat SAP-toimittajariippumattomia (vaativat vain vähän työtä
esim. vastuunsiirtotilanteissa)
– SAP-kehitys on muuttamassa muotoaan: tulevaisuudessa
enemmän jatkokehitystä kuin uusimplementointia
27.9.2010 Copyright 2010 Nobultec Oy 6
Mihin laatua tarvitaan? 3/3
Miksi kaikki eivät koe tarvitsevansa laatua?– Tiedon puute
• Ei osata vaatia laadukasta tuotantoa, ei esim. tietoa eri
vaatimusulottuvuuksista tai laadun kehittämismenetelmistä tai
laaduttomuuden vaikutuksista
• Ei tietoa vaihtoehdoista nykykäytännöille tai nykytoimittajille
• Ei tietoa omasta laatutasosta tai benchmarkeista
– Laatu maksaa ja vie aikaa
• ”Saamme jo riittävän laadukasta jälkeä, miksi maksaa lisää?”
• Laadun ROI vaikea laskea, mutta huonon laadun kustannukset
voivat nousta esiin esim. upgraden yhtedessä
• Lyhyen aikavälin säästö vs. pitkän aikavälin kustannus
=> Onko varaa elää ilman laatua?
– Tarjonnan puute
• Let’s be frank toimittajat – emme ole olleet asiassa kovin aktiivisia!
27.9.2010 Copyright 2010 Nobultec Oy 7
SAP-kehityksen laadun nykytila –inside view for SAP Finug only
27.9.2010 Copyright 2010 Nobultec Oy 8
Customer view
Vendor view
Developer Process Deliverable Support
”Wow, what a guru
have we found!”
”I’ve been hacking ABAP for 5 years
- I learned the whole thing myself!
- previous sw dev and work
experience? I did casual warehouse
summer jobs before joining our
consultancy and going freelance”
”I did it all by myself!”
”Noo idea what he
is up to, but we are
going live next week!”
?
”Looks great and
it works! Let’s take
this to production!”
”Whew, at least it
worked once!”
”Err..why does it
take so much time
and money to fix it?”
”Ok...where should I
begin? I didn’t really
think they would
come up with such
requirements and it
would take forever to
redo the application!”
27.9.2010 Copyright 2010 Nobultec Oy 9
MISTÄ LAATUA SAA?
Mistä laatua saa? 1/3
Lisää laatua ei voi vain saada, sitä täytyy vaatia...– Vaatimukset määriteltävä tarkemmin ja monipuolisemmin,
tavoitetasot mukana saavutetun tason mittaamiseksi
• Sen on toimittava, se tulee tehdä x kk:ssa ja se voi maksaa x€
eivät riitä vaatimuksiksi!
• Esimerkkivaatimuksia (oikeasti käytössä olleista vaatimuksista):
– Toiminnallisuudet: kaikki määritellyt use caset voidaan testata
onnistuneesti, x kpl high prio bugeja voi jäädä auki
– Käytettävyys: toimenpide tehtävissä x sekunnissa, käyttäjäarvosana
4/5 jne.
– Suorituskyky: odotusaika max 3sek
– Suunnitelmavaatimukset: noudatettava käytäntöjä x ja periaatteita y,
nollatoleranssi dokumentointipoikkeamiin jne.
...ja valvoa!– Vaatimusten noudattamista tulee valvoa uusin menetelmin
(perinteinen toiminnallinen testaus ei riitä)
– HUOM: vaatimukset voivat vaatia sopimuksellisia muutoksia
27.9.2010 Copyright 2010 Nobultec Oy 10
Mistä laatua saa? 2/3
Mitä voi vaatia, mitkä voi olla tarkemmat vaatimukset?– Toiminnallisuudet:
• benchmark-tuotteet, omat vaatimukset
– Käytettävyys:
• SAP User Centered Design Process
• SAP Design Guild
• SAP Guidelines for Best Built Applications
– Suorituskyky:
• benchmarkit, omat vaatimukset
• SAP Guidelines for Best Built Applications
– Suunnitelma- ja toteutusvaatimukset:
• SAP Guidelines for Best Built Applications (SAP)
• omat suunnittelu- ja ohjelmointikäytännöt
• Official ABAP Programming Guidelines (SAP Press)
27.9.2010 Copyright 2010 Nobultec Oy 11
Mistä laatua saa? 3/3
Miten valvoa laatua?– Toiminnallisuudet:
• Käyttötapauksien ja testitapauksien laadinta
• Automaattinen testaus (eCATT)
– Käytettävyys:
• Lukuisia havainnointi- ja katselmointimenetelmiä
(mm. ääneenajattelu, käytettävyysheuristiikkojen katselmointi)
– Suorituskyky:
• Eri load testing-menetelmät ja -teknologiat
– Suunnitelma- ja toteutusvaatimukset:
• Eri menetelmiä:
– Katselmoinnit (manuaalinen vs. automatisoitu) ohjelmistolle ja
dokumentaatiolle)
– Koodianalyysi, automatisoidut testiluokat, jne.
27.9.2010 Copyright 2010 Nobultec Oy 12
27.9.2010 Copyright 2010 Nobultec Oy 13
MITÄ ELISA TEKI?
Mitä Elisa teki? 1/8
Lähtötilanne– Monitoimittajaympäristö: lukuisia eri toimittajia SAP-kehitykselle
(ylläpitokumppaneita, projektitoimittajia, yksittäisiä point experttejä jne.)
– Yhteisiä kehitys- ja dokumentointikäytäntöjä ei käytössä
• Elisalla ei omia SAP-kehitys- tai dokumentointikäytäntöjä
• Toimittajien väliset käytännöt erilaisia (eri dokumentointimalli, eri
ohjelmointitapa, eri nimeämistavat jne.)
• Myös toimittajien sisällä erilaisia käytäntöjä eri kehittäjien välillä
Koetut ongelmat– ylläpito: hidasta, työlästä ja kallista, ei tietoa mitä kehitystä tehty ja
miksi (+ ei kommentointia, ei headereita, kovakoodausta, suomen-
kielistä kehitystä)
– Elisan tieto nykyjärjestelmästä: ei tietoa mitä tehty, dokumentaatio
hajallaan, perustelemattomia räätälöintejä hidastamassa tai jopa
estämässä muuta kehitystä
– korkea riskitaso: ei tarkempaa kontrollia siitä, mitä on menossa
tuotantoon
27.9.2010 Copyright 2010 Nobultec Oy 14
Mitä Elisa teki? 2/8
Tiedostaminen (kevät-2009)– SAP HR-vastaava näki tarpeen korostaa teknisen kehityksen
laatua alkavassa HR-jatkokehitysprojektissa => ensimmäinen
laatusykäys
– organisaatioon toisesta organisaatiosta tullut SAP-
kehityspäällikkö nosti asiaa enemmän esiin ja käynnisti
aiheesta kehityshankkeen kesällä-2009
Tavoite– SAP-kehityskäytännöt ja niiden valvominen nostettava
seuraavalle tasolle
– fokuksessa dokumentointi- ja kehityskäytännöt
27.9.2010 Copyright 2010 Nobultec Oy 15
Mitä Elisa teki? 3/8
Suunnitelma ja tehdyt työvaiheet– Työvaihe 1: tee käytäntöjen 1.versio (kesä-2009)
• dokumentointi- ja kehityskäytännöt (lähteinä mm. Official ABAP
Programming Guidelines, Java Coding Conventions)
• Elisa SAP development guidelines v1.0, fokuksessa
– Työvaihe 2: Pilottiprojekti (6-9/2009)
• SAP HR-jatkokehitysprojekti pilottiprojektina (ABAP-, BSP- ja
Web Dynpro for Java -kehitystä)
• Elisa SAP development guidelines v1.0 käytössä,
valvontamekanismina manuaaliset koodivertaiskatselmoinnit
– Työvaihe 3: Käytäntöjen iterointi (9-10/2009)
• Tarkennuksia suunnitteluperiaatteisiin ja vaatimusten
priorisointiin
– Työvaihe 4: Pilottiprojekti 2 (11/2009-03/2010)
• SAP HR-jatkokehitysprojekti (ABAP-/BSP-/WDJ-kehitys)
27.9.2010 Copyright 2010 Nobultec Oy 16
Mitä Elisa teki? 4/8
Tulokset– Työvaihe 2: Pilottiprojekti (6-9/2009)
• Katselmoituja dokumentteja 4kpl, custom-koodirivejä 4949,
kehitysobjekteja 18. Kaksi katselmointikertaa.
• Katselmointihavainnot priorisoitu ja prio1-asiat listattu bugeiksi
• Yleisesti tekninen kehitys havaittiin parannuksia vaativaksi
27.9.2010 Copyright 2010 Nobultec Oy 17
Ongelmakategoria Havaintoja (kpl)
Pretty printerin käyttö 4
Otsikkotason kommentointipuutteet 27
Rivitason kommentointipuutteet 101
Nimeämiskäytäntöjen noudattamattomuus 13
Sisäkkäisten selectien ja looppien karsiminen 4
SELECT * käytön korvaaminen SELECT SINGLE:llä missä mahdollista -
IF/ENDIF:n korvaaminen CHECK:illä missä mahdollista 4
IF/ENDIF:n korvaaminen CASE:lla missä mahdollista -
FIELD-SYMBOLien käyttö missä mahdollista 3
“Kuolleen” koodin poistaminen 30
Koodin rakenteistaminen 19
Muut havainnot 22
Yhteensä 229
Mitä Elisa teki? 5/8
Tulokset– Työvaihe 4: Pilottiprojekti 2 (11/2009-03/2010)
• Katselmoituja custom-koodirivejä 6191, kehitysobjekteja 22.
Neljä katselmointikertaa.
• Katselmointihavainnot priorisoitu ja prio1-asiat listattu bugeiksi
• Yleisesti tekninen kehitys havaittiin parannuksia vaativaksi
27.9.2010 Copyright 2010 Nobultec Oy 18
Mitä Elisa teki? 6/8
Kokemuksia– Työvaihe 1: tee käytäntöjen 1.versio (kesä-2009)
• Vaatimukset suhteellisen nopeasti johdettavissa ja ensimmäinen
käytäntöversio saatiin nopeasti aikaan
• Lessons learned:
– laatuvaatimusten priorisointi ja prioriteettien valinta hankalaa, mutta
jostain pitää lähteä liikkeelle
– Vaatimusten/käytäntöjen laadinta vaatii teknistä kehityskokemusta
– Työvaihe 2 & 4: Pilottiprojektit (6-9/2009, 11/2009-03/2010)
• Käytännöt olivat uusi asia toimittajalle ja aikataulu sovittu, ei voitu
mennä full scopella
• Paljon raportoituja & korjattuja ongelmia
=> Selvä vaikutus laatutasoon!
• Vaati paljon kontrollia toimittajan kanssa sovitusta huolimatta
• Lessons learned:
– toimittajien velvoittaminen projektin keskellä uusiin vaatimuksiin
hankalaa, koska muutokset aiheuttavat lisätyötä.
– Valvonta oli erittäin tärkeää, jotta ongelmat tuli korjattua
27.9.2010 Copyright 2010 Nobultec Oy 19
Mitä Elisa teki? 7/8
Laaduttomuuden kustannukset by Elisa– Multi-vendor strategy becomes very hard to maintain – in
some cases it is not even possible if code / docs are only in
Finnish
– “Surprises” mean extra costs – experience gained…
– Lost opportunities – not able to use standard functionality
– Patching and upgrades become longer, more resource
intensive and have higher risks
– Real risks if a change is so critical that we rely on one source
to operate, what happens if the “lorry hits”?
27.9.2010 Copyright 2010 Nobultec Oy 20
Mitä Elisa teki? 8/8
Elisan jatkosuunnitelmat– nykykäytäntöjä sovelletaan parhaillaan projekteissa (esim.
SAP upgrade)
– käyttöön otettu laadunhallintatoiminta on nyt toiminnan
edellytys, tulevaisuudessa säästää aikaa ja rahaa
– tulevaisuuden kehityslinjauksia:
• Käytäntöjen tarkentaminen eri osa-alueille (transport guidelinet,
teknologiavalinnat, dokumentointimallit)
• Valvonnan jatkaminen välttämätöntä ainakin alkuun
• Laatukäytännöt jatkossa toimitussopimuksille mukaan toimittajan
velvoitteeksi
27.9.2010 Copyright 2010 Nobultec Oy 21
27.9.2010 Copyright 2010 Nobultec Oy 22
YHTEENVETO
27.9.2010 Copyright 2010 Nobultec Oy 23
Yhteenveto
Haluttu laatutaso tulee määritellä, sen tuomat hyödyt
pitää tiedostaa ja tätä tasoa pitää erikseen vaatiaHyvin moni asiakas vaatii toimittajilta tällä hetkellä ”alan
yleisesti hyväksi tunnettuja käytäntöjä” SAPin teknisessä
kehityksessä ymmärtämättä mitä ne ovat tai mitä ne tuovat
tullessaan. Toimittajapuolella ei myös läheskään aina ole
yhteistä ymmärrystä näistä käytännöistä.
Laatua pitää myös valvoaIhmisluonteeseen kuuluu virheet, unohdukset ja halu välillä
mennä sieltä, missä aita on matalin ja projektikiireessä
tämä vain korostuu => aktiivinen valvonta ja poikkeamiin
puuttuminen on varsinkin alkuun välttämätöntä
Laatutason kehittäminen ei ole rakettitiedettäElisa ja monet muut ovat tehneet sitä, miksei muutkin?
Apua on saatavilla, jos omat voimat eivät riitä.
27.9.2010 24
Mikko Mäki-Rahkola
Toimitusjohtaja
Puh. +358 50 558 7834
Twitter: mikkomr
LinkedIn: fi.linkedin.com/in/mikkomakirahkola
Nobultec Oy
Tekniikantie 12
FI-02600 Espoo
www.nobultec.com - Work redistributed
Kiitos!
Copyright 2010 Nobultec Oy