Download - 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


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


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



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



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!


SAP-kehityksen laadun nykytila –inside view for SAP Finug only


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!”


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



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)



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.



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



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



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)



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


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


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



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



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”?



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



YHTEENVETO


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

[email protected]

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

Download - SAP-ohjelmistojen laadun kehittäminen monitoimittajaympäristössä - case Elisa

Top Related