Valokeilassa

Taipuva ALM Solution Day in Tampere, 25th April 2017

siemens-partner

The 5th annual event on Siemens’s Polarion ALM solution by Taipuva Consulting, a Siemens partner company based in Finland and Sweden: Tampere, Tuesday  25th April, 2017.

See the program and register!

  • Cost: No admission fee. Complimentary breakfast, lunch and coffee offered.
  • Language: All presentations are in English

Product development becomes more and more software-intensive. Communication and software systems are increasingly complex as they are interconnected in the IoT world. How to effectively manage these development projects so that cost, quality issues and risks do not sky-rocket? – Application Lifecycle Management (ALM) is just for that!

Our event represents the Polarion ALM solution, and offers a peek in its novelties for more advanced users. Also what’s usually been the most interesting part, the users of Polarion share their real-life experiences and use cases. Don’t forget valuable networking with your peers.

See the highlights of the previous year’s appreciated event featuring presentations from Sandvik and Wärtsilä. Come this year yourself!

Secure your seat and sign up here!

Webinaaritallenne – Perinteiset dokumentit ovat kuolleet

Webinaarin agenda (kielenä suomi, kesto n. 30 min):

  • Sisällön määrittelyn ja hajautetun ryhmätyön haasteet
  • Demo: Polarion Live Document – Mitä ratkaisuja se tarjoaa?
  • Yhteenveto hyödyistä, käyttöönotosta ja referensseistä




Lataa webinaarissa käytetty esitysmateriaali PDF-tiedostona tästä:
taipuva-webinaari-dokumentit-ovat-kuolleet

Mikä on ALM? Osa 2: ALM vs. PLM

alm-vs-plm

Lue kirjoitussarjan 1. osa: ”Mikä on ALM? Mitä hyötyä siitä on tuotekehityksessä?”

ALM (Application Lifecycle Management) ja PLM (Product Lifecycle Management) parantavat tuotekehitystyön tuottavuutta. Kummassakin esiintyy sana elinkaari. Miten tällaiset järjestelmät eroavat toisistaan? Miksi niiden yhteenliittäminen on viime aikoina noussut yhdeksi kuumimmista puheenaiheista IoT:n ja digitalisaation ohella?

Olennaisimmat erot

PLM:ää käytetään fyysisten tuotteiden maailmassa, kun taas ALM:llä on juurensa ohjelmistokehityksessä. PLM:ssä hallitaan etenkin tuotteiden osia ja materiaalivirtoja sekä niihin liittyvää suunnittelua ja yhteistyötä. ALM:n näkökulma on abstraktimpi ja se lähtee usein siitä, mitä tuotteella tai ohjelmistolla halutaan tehdä ja millaisia toimintoja siihen liittyy.

Halittavat asiat eli objektit ovat PLM:ssä fyysisiä komponentteja ja niihin liittyviä tietoja tai esimerkiksi muutospyyntöjä. Tiedon päärakenne pohjautuu osien (parts) välisiin suhteisiin, miten jokin osa koostuu muista osista (”part of”-suhteet). ALM:ssä objektit ja tietorakenteet ovat moninaisempia. Hallittavat asiat voivat olla esimerkiksi asiakasvaatimuksia, tuotteen toimintoja ja niitä kuvaavia käyttötapauksia tai ”user storyja”. Lisäksi niihin halutaan liittää tietoa, miten vaatimukset tai toiminnot tulee verifioida. Etenkin turvallisuuskriittisten tuotteiden tapauksessa riskit tulee tunnistaa ja ne pitää jäljittää (linkata) riittävällä tavalla muihin objekteihin. Tuotteen fyysisen rakenteen lisäksi käytetään hyväksi toimintojen ja loogisten kokonaisuuksien välisiä suhteita.

Objekteihin liittyvä tieto on PLM:ssä hyvin konkreettista. Se voi olla esimerkiksi 3D-kuva, tieto tarvittavista mitoista tai toleranssi. ALM:ssä tieto on monesti kuvauksia, joissa on tekstiä ja apuna diagrammeja (UML, UI mock-up) tai muita havainnollistavia keinoja. Erona on oikeastaan se miten fyysisiä asioita tai osia kuvataan (PLM) ja miten vaatimuksia, toimintoja, testitapauksia, riskejä tai niihin liittyviä asioita määritellään (ALM).

PLM:ssä fyysisten tuotteiden elinkaari on suoraviivainen suunnittelun ja tuotannon kautta käyttöön ja lopulta käytöstä poistoon. ALM:ssä ohjelmistotuotteen elinkaari muodostuu iteratiivisesta ja inkrementaalisesta kehityksestä. Ohjelmisto (tai vähintään sen sisältö eli määritykset, testit ja riskit) jatkaa eloaan fyysisen tuotteen poistamisen jälkeen tuotteen seuraavassa versiossa.

plm-vs-alm

Samankaltaisuudet

Kummassakin järjestelmässä on taustalla tietokanta, jonka avulla erilaisten objektien tietoja ja suhteita toisiinsa voidaan hallita. Yhteistä on myös se, että viimeisin tieto halutaan tuoda reaaliaikaisena kaikkien tarvitsijoiden käyttöön. Tämän takia järjestelmiä voidaan kutsua yhteisnimeltään lifecycle collaboration -työkaluiksi.

Toimivan yhteistyön mahdollistajana on sovittu tapa toimia eli prosessi. Prosessit pohjautuvat näissä järjestelmissä objektien työnkulkuihin (workflow) ja niitä kuvaaviin tiloihin (status). Laadunvarmistus on liitetty osaltaan työnkulkuihin, joissa voi osana olla katselmointeja, hyväksyntöjä sekä elektronisia allekirjoituksia. Työnkuluissa voi olla riippuvuuksia muiden objektien tiloihin, minkä avulla saadaan varmistettua kokonaisprosessin toimivuus ja tiedon eheys.

Yhteistyön koordinointi ja työnkulut tarvitsevat vastuuhenkilöitä tietyille vaiheille. Tästä seuraa tarve nähdä omat tarvittavat toimenpiteet eli tehtävät ja ToDo-lista. Lisäksi tähän liittyy yleinen projektinhallinta, työmäärien ja työkuormien arvioiminen. Sekä PLM- että ALM-työkaluissa voi olla tukea tai liityntöjä projektinhallintaan. ALM:ssä tuki pohjautuu monesti softakehityksen menetelmiin eli työkalupakista löytyy vähintään scrum, kanban ja SAFe mutta myös perinteisempiä Gantt-kaavioita projektinhallinan tarpeisiin.

ALM ja PLM yhdessä

PLM ja ALM kohtaavat luonnollisesti silloin, kun halutaan määritellä vaatimuksia tuotteen fyysisille osille. Tuotteen vaatimukset voivat pohjautua haluttuihin toimintoihin. Yhden toiminnon aikaansaamiseksi tarvitaan usein laitteen eri osia (ja myös loogisia osia ohjelmistoista). Laitteissa olevat ohjelmoitavat osat (kontrollerit ja tietokoneet) voivat toteuttaa hyvinkin erilaisia toimintoja. Pienten ja yksinkertaisten osien kohdalla osa ja sen suorittama toiminto ovat yksikäsitteisiä (esimerkiksi ruuvin tai kotelon tapauksessa)

Toinen luonteva kohtauspaikka syntyy, kun tuotteeseen halutaan tehdä muutoksia. PLM-järjestelmissä on yleensä käsite ”engineering change request” (ECR), joka on objekti halutun muutoksen käsittelyä varten. ECR voidaan linkittää niihin osiin, joihin muutos liittyy. Samalla periaatteella ALM:ssä hallitaan muutoksia. Change request -objekti voi kohdistua tiettyyn vaatimukseen tai toimintoon, jolloin kaikki siitä johdettu tieto tulee päivittää (alivaatimukset, testitapaukset, riskianalyysit). Kummassakin järjestelmässä puhutaan muutoksen vaikutuksen analysoimisesta (impact analysis). Tietomalli ja sen linkitykset mahdollistavat muutoksen vaikutusten ja toteutuksen arvioimisen.

Aivan viime vuosina kiinnostusta on herättänyt ALM:n ja PLM:n integroiminen toisiinsa, mikä toisi uudenlaisia hyötyjä tuotekehitystoimintaan. Tärkeimpänä on turvallisuuskriittisten tuotteiden suunnittelulta vaadittava jäljitettävyys. Ilman manuaalisesti ylläpidettäviä riippuvuussuhteita virheiden mahdollisuus pienenee, etenkin muutostilanteissa.

Edellä mainitut samankaltaisuudet tekevät integroinnin mahdolliseksi ja hyödylliseksi. Siemens on etunenässä toteuttanut  integraation Teamcenter PLM- ja Polarion ALM -järjestelmiensä välille. Etuina on tiedon näkyvyys ja helpompi yhteistyö eri insinöörialojen välillä.  Ensimmäisiä Siemens PLM-ALM -integraatioita on juuri otettu käyttöön yrityksissä eri puolilla maailmaa, esimerkkinä CNH Industrial, joka on globaalisti toimiva raskaiden työkoneiden valmistaja. Jatkossa saumaton jäljitettävyys johtaa tuotteiden varmempaan turvallisuuteen, parempaan laatuun ja tuotekehitystyön tuottavuuden kasvuun.

Yhteenveto

Digitaalisasatio ja IoT (Internet of Things) ovat kaikkien huulilla. ALM ja PLM ovat digitalisaatiota, mutta se liittyy tuotteiden kehittämisen prosessiin eikä tuotteisiin itseensä. IoT on suuntaus, joka kasvattaa tuotteiden monimutkaisuutta ja ohjelmistojen osuutta entisestään. IoT-hankkeissa monen osapuolen täytyy sopia keskenään siitä, miten järjestelmät ja laitteet toimivat yhdessä, miten ne testataan ja miten kokonaisuus pidetään hanskassa. Tarve hajautetun ja monenkeskisen tuotekehityksen hallinnalle korostuu. ALM ja PLM-ALM-integraatio soveltuvat juuri näihin tarpeisiin!

Entä jos yrityksellä on jo PLM. – Tarvitaanko ALM-työkalua? Nyrkkisääntönä voidaan todeta, että jos yritys valmistaa yksinkertaisia koneen osia, niin ALM:lle ei ole tarvetta. Jos tuotteet ovat monimutkaisia tai niihin liittyy ohjelmistoja, niin ALM auttaa yritystä varmasti. Jos lisäksi tuotteiden verifiointi ja validointi on tärkeää, niin ALM:n käyttäminen tuo lisätehoa.

Ohjelmistokehityksessä ALM:llä voi korvata tai sen voi integroida ”trackereihin” ja scrum-työkaluihin (esim. JIRA), etenkin kun halutaan saumaton yhteys tuote-/asiakasvaatimuksiin tai testauksenhallintaan.

Kaikilla aloilla, joihin liittyy paljon (asiakas)vaatimuksia tai regulatiivisia säädöksiä, ALM on välttämätön jos yritys haluaa pitää huolta työn tuottavuudesta. Lisäksi ALM-järjestelmää voi hyödyntää monenlaisten dokumenttien ja räätälöityjen prosessien pyörittämisessä.

Lisätietoa:

Voit myös aina ottaa yhteyttä meihin ja kysyä mikä jäi epäselväksi!