Tik-76.612 Ohjelmistoprojektien Hallinta Luento 8 Projektien erilaisuudet
Luentokartta synty suunnittelu käynnistys ohjaus päätös operointi Ti 12.3 To 14.3 Ti 19.3 To 21.3 Ti 26.3 To 4.4 Ti 9.4 To 11.4 Ti 16.4 Ti 18.4 To 23.4 Kurssin aloitus Projektin synty Projektisuunnitelma Projektin käynnistäminen Työmäärien arviointi Projektin ohjaus Projektihallinnan työkalut Projektien erilaisuudet Laadunohjaus ja leadership Projektin päättäminen Ohjelmistotuoteliiketoiminta
Projekti Määritelty kesto, eri vaiheita Määritelty aloituspiste Määritelty lopetuspiste Tarve Resurssitarve Tarve tyydytetty Tuki ja / tai linja-organisaatio Projekti synty suunnittelu käynnistys tekeminen päätös operointi Yrityksen tukiorganisaatio tukee projektia (ja muita projekteja) peruspalveluilla ohjaus
Luennon tavoite Projektien erilaisuudet -osuuden tarkoituksena on antaa opiskelijalle hyvä kuva siitä, millaisia eri tyyppisiä ohjelmistoprojekteja on, mitkä ovat niiden tunnuspiirteet ja rakenne, sekä mitä erityispiirteitä kunkin hallintaan liittyy.
Projektin lähestymistapa + Metodologia + Elinkaari + Osaamisalueet + Projektin tyyppi (räätälöity/paketti/komponentti) = Projektin lähestymistapa
Miksi Metodologia? Projekti A Projektinhallinta ja kehitysprosessi kunnossa Onnistuu suuremmalla todennäköisyydellä Projekti B Teknisesti pätevää porukkaa Epäonnistuu suuremmalla todennäköisyydellä + Siirtää osaamista ihmisiltä organisaatioon best practice + Tärkeä tekijä projekteja myydessä + One Company
Metodologia määrä projektille Metodologia -> Projekti Läpivientitavan = elinkaarimallin (= prosessin) Tehtävät Lopputulokset (dokumentit, jne) Lisäksi metodologiassa tulisi olla Apuvälineitä (how-to) Roolikuvauksia Estimoinnin apuvälineitä
Metodologia? Kyllä Ei RUP (Rational Unified Process) XP (Extreme Programming) BIM (Business Integration Methodology, Accenture).. CMM (Capability Maturity Model) ISO 9001 (Laatumalli) SPICE...
Accenture Business Integration Methodology and Delivering Phase Approaches
The Business Integration Methodology Managing Planning Delivering Operating
BIM kerrosta syvemmältä
Planning Phase Formulates plans to capitalize on opportunities Business Diagnosis Provides internal and external context for change. Strategic Direction Describes the organization s vision. Operating Strategy Defines approaches to execute the strategy. Business Architecture Defines the business capabilities. Creates a blueprint for achieving the strategy
Puts plans into action Delivering Phase Capability Analysis Defines the scope, targets, and release plan for the capability. Capability Release Design Puts the Business Capability Blueprint into effect. Capability Release Build and Test Produces and pilots the new capability. Deployment Puts the new capability into action.
Operating Phase Focuses on ongoing operations and improvement Service Operations Operates new business capabilities to achieve the desired result. Application Management Extends and improves application software performance.
Managing Phase Provides oversight, guidance, and rigor
BIM:n Rakenne Hierarkisesti kuvatut prosessit Phase (Plan, Deliver, Operate, Manage) Stage/Discipline Major Activity (Delivering and Managing phases only) Task Package Task Lopputuotokset Apuvälineet Roolit ja organisaatio Konseptit Estimointi
BIM konseptit
Testaus ja BIM
Seven Key Principles Drive the BI Methodology Always do a business diagnosis Focus on value: build on a business case Define implementable strategies and solutions Focus on delivering a business architecture Create business capability Commit to work in stages Use journey management to build leadership, sponsorship and ownership
(Accenturen) menetelmissä tunnistetut projektien tyypit Kaupalliset tai konsulttitalojen menetelmistöt esittelevät projektin läpiviennin vaiheistuksen: räätälöidyt ratkaisut (tehdään itse) pakettien käyttöönotto komponettikehitys
Tehdään itse suunnittelu ja toteutus Saadaan varmasti sitä mitä halutaan Hinnan ja aikajänteen takia ei kovinkaan suosittua tänä päivänä
Pakettiohjelmiston käyttöönotto Paketin mahdollisuudet vs. business vaatimukset Hintavertailuja Testaaminen usein vaikeata, koska paketin sisään ei nähdä
Komponettipohjainen suunnittelu ja toteutus Nopeasti valmista Sopii tilanteisiin joissa odotukset ovat epäselvät ja muuttuvat jatkuvasti Arkkitehtuurien merkitys kasvaa Design vaikea kommunikoida ilman erillistä demoa/protoa Vaarana liiat luulot nopeasti valmiiksi saadun kaikkivoipaisuudesta
Projektinhallinnan malleja Menetelmistöt hyödyntävät eri lähestymistapoja ohjelmistokehitykseen vesiputous (kalaportaat) iteratiivinen kehitys
Vesiputousmalli ja kalaportaat Vaatimusten määrittely Määrittelyn tarkennus Järjestelmä- ja sovellussuunnittelu Toteutus ja yksikkötestaus Integraatio- ja järjestelmätestaus Hyväksymistestaus Käyttöönotto ja ylläpito
Iteratiivinen kehitys 1. Iteraatio Iteratiivinen kehitys 2. Iteraatio % valmis Analyysi Suunnittelu Toteutus ja testaus 3. Iteraatio 1. järjestelmäversio Iteratiivinen kehitysmalli käsittelee kehitystyön riskejä seuraavilla tavoilla: Hankkii varhaisempaa palautetta sponsoroivalta organisaatiolta Tutkii riskialttiit alueet (toiminnalliset tai tekniset) ja testaa ne varhaisessa vaiheessa Identifioi vielä tuntemattomia ongelmakohtia Sopeutuu joustavammin Antaa varhaisempaa hands-on -tuntumaa kehitystiimille
Järjestelmäversiot 1. versio 2. versio 3. versio Järjestelmän jatkoversiot (incremental releases) ovat osa laajempaa kyvykkyyttä (business capability). Niillä tulisi olla seuraavat ominaisuudet: Tuottaa välitöntä lisäarvoa sponsoroivalle organisaatiolle (ja sen asiakkaille). Tukee tiettyä rajattua tavoitekokonaisuutta, joka on osa täyden toiminnallisuuden tavoitteista Toimitettavissa verrattain lyhyessä ajassa Otetaan käyttöön loppukäyttäjille/asiakkaille Riittävän joustava jotta uutta toiminnallisuutta voidaan lisätä myöhemmissä versioissa Helpottaa nykyisten käyttäjien siirtymistä myöhempiin versioihin Kk
Projektinhallinnan tekniikoita Menetelmissä käytetään tiettyjä tekniikoita riippumatta lähestymistavasta protoilu timeboxing testauksen v-malli
Protoilu
Timeboxing Määritelmän mukaisesti kukin neljästä osatekijästä on kiinnitetty. Jokin neljästä, useimmin aikataulu sanelee. Resurssit Lopputuote Tehtävät Aikataulu
The V-model Business Performance Model and Requirements Prepare and Execute Business Capability Release Test Identify Application Requirements (TP) -------------- Analyze Application Requirements (TP) Prepare and Execute Application Product Test (TP) Verify Application Quality Design Application Architecture (TP) Prepare and Execute Assembly Tests (T) Application level Perform Application Detailed Design (TP) Prepare and Execute Component Tests (T) Component level Generate Module (T)
RUP = Rational Unified Process XP = extreme Programming Muita metodologioita
RUP on järjestelmäkehitysprosessi Yleiskuva RUP:ista (Rational Unified Process) Perustuu järjestelmäkehityksen parhaisiin toimintatapoihin (best practices) Iteratiivinen kehitys Vaatimusten hallinta Use case driven Arkkitehtuurikeskeinen, komponenttien käyttö Mallinnus UML:llä
RUP:n työnkulku ja projektin vaiheet
Milloin käyttää XP:tä? Suhteellisen pienissä projekteissa (max. 20 henkeä) Tilanteessa, jossa: resurssien määrä on ennalta rajoitettu sisäiset kehitysprojektit on vahva luottamus tilaajan ja toimittajan välillä release 2 onnistuneen release 1:n jälkeen ollaan jo kerran epäonnistuttu tehtiin perinteisesti, vaatimukset muuttuivat koko ajan, mitään ei tullut valmiiksi
Yleisiä havaintoja XP:stä Vaatii kaikkien osapuolien koulutusta Vaatii tilaajalta paljon tarkempaa paneutumista tilattuun sovellukseen ("white box" vs. "black box") Jos enemmistö ohjelmoijista on kokeneita, XP voi olla erinomainen ympäristö kasvattaa uusia osaajia "Lähes valmis" ei riitä
RUP = Rational Unified Process Olio-orientoituneista metodologioista ehkä kuuluisin Iteratiivinen prosessi XP ja RUP? dx on täysin RUP:in mukainen kehitysprosessi, joka "sattuu" olemaan identtinen XP:n kanssa www.objectmentor.com/publications/rupvsxp.pdf
Projektien erilaisuuksien tunnistaminen Sopivan johtamis- ja hallintamenettelyn määritys: esim. vesiputousmalli vai iteraatiot? Mikä on projektin tavoite? projektin tavoitteet; teknologiaa vai business hyötyä ajaako aika vai laatu 80/20 -sääntö Projektin muotoon vaikuttaa muukin kuin "e". Projektin muoto saa myös muuttua matkan aikana, jos tarpeen.
Projektin tyypin tunnistaminen yleisten skenaarioiden avulla 1. Laajan muutosohjelman implementointi 2. Enterprise resource planning (ERP) program -käyttöönotto 3. Räätälöidyn ratkaisun käyttöönotto, erityisiä joustavuusvaatimuksia 4. Pakettiohjelmiston käyttöönotto, rajatusti räätälöintiä 5. Pakettiohjelmiston käyttöönotto, huomattavaa räätälöintiä 6. Asset based (~ olemassaolevan pohjalta) 7. Netcentric (~ webbipohjainen) 8. Mainframe 9. Eräajopohjainen ratkaisu 1. Räätälöity 2. Paketti 3. Komponentti 4. Paketti 5. Paketti -> Räätälöity 6. Räätälöity 7. Komponentti / Räätälöity 8. Räätälöity 9. Räätälöity
Projektin komponentteja vertaamalla voidaan tunnistaa projektin tyyppi miksi projektit ovat erilaisia projektin tavoite aikataulu, resurssit uuden toiminnallisuuden (kyvykkyyden) elementit organisaatio prosessit teknologia Harjoitustyössä voidaan nähdä kolme erilaista projektia (vai voidaanko?) Tik-76.612 Kevät 2001 Liiketoiminta-arkkitehtuuri Liiketoiminta-arkkitehtuurin ymmärtämisessä ja kommunikoinnissa voidaan käyttää apuna Accenturen liiketoiminta-arkkitehtuurin kuvaamismallia. Strategia Liiketoiminnan parempi kannattavuus ja kilpailukyky Kulttuuri Organisaatio Prosessitiimit Työryhmät Toimenkuvat Proseduurit Prosessit Sovellukset Liiketoiminta 1 Liiketoiminta 2 Kirjanpito Data Warehouse Toteutus- ja tuotantoympäristöt Yhteistyö eri osapuolten välillä Yhteisten päämäärien ymmärtäminen Palveluasenne Yrityskulttuuri, fiilis Tilat Tuote Palvelu 1 Palvelu 2 Toimisto 1 Toimisto 2 Tuotetuki Kirjanpito Osaaminen Laitteet Työasemaympäristö, verkko Keskuskonepalvelut serverillä Käyttöpalvelut Operointipalvelut Accenture 2001 All Rights Reserved Tuotetuntemus ATK:n käyttö Prosessien tuntemus Työasemat Palvelimet Oheislaitteet Työkalut Tulos Varma ja toimiva liiketoimintaratkaisu Kyky toimia Euroalueella Tehokas, edistyksellinen ja käyttäjäystävällinen ratkaisu Ratkaisun laajuus tarkasti rajattu Toteutus aikataulun mukaisesti Hyvin toimiva projekti Hallittu muutos 4
Liiketoiminta-arkkitehtuuri Kulttuuri Käyttäytyminen Arvot Normit Motivaatio Strategia Visio/missio Tuotteet, palvelut, hinnoittelu Asiakas-vaatimukset Jakelukanavat Markkina-asema Kohdeasiakkaat/mar kkinat Tarvittavat valmiudet Toimintarakenteet Hankintapolitiikka Toiminnan suuntaviivat Organisaatio Rakenteet Tiimit, roolit Toimenkuvat Prosessit Sovellukset Tilat Sijainti Rakennukset Omaisuus Oheispalvelut Toiminnot Tehtävät Työnkulku Toimintaohjeet Odotukset Informaatio Osaaminen Taidot Tietämys Taipumukset Laitteet Tulos Strateginen Taloudellinen Operationaalinen Osakkeenomistajat Henkinen Osajärjestelmät Komponentit Modulit/luokat Data Palvelimet Työasemat Koneet/oheislaitt Työkalut Toteutus- ja tuotantoympäristöt Tekniset arkkitehtuurit Käyttöpalvelut Operointipalvelut Verkot
Rajoittava tekijä on joskus aika resurssit laajuus...tai jokin muu Erilaiset projektit vaativat erilaisia hallintatapoja
Miten projekti on asetettu? Muuta projektien tyypistä projekti linjaorganisaatiossa vai erillisenä projektina, jolla on omat (100%) nimetyt resurssit valtava merkitys projektin mahdollisuuksiin onnistua Missä projekti tapahtuu fyysisesti? hajauttaminen lisää kompleksisuutta Miten projekti on vaiheistettu? rahaa saadaan vasta kun koko työ on tehty
Case - arkkitehtuuri Harjoitustyö esittelee hankkeen, jossa voidaan nähdä kolme projektia Toteutettava osio Jällenmyyjät Internet WWW Palvelin B2B Logiikka Adapteri AS/400 Mahdollistaa Jällenmyyjät Tilaukset Laskut Turun Kirjapaino
Kolme esimerkkiä erilaisista lähestymistavoista Osaprojekti WWW-projekti B-to-B logiikka Adapteri Menetelmä, lähestymistapa Komponenttikehitys, iteraatiot, timeboxing Räätälöity, paketin käyttöönotto, timeboxing(?) Räätälöity, paketin käyttöönotto(?)
Päätöksentekokriteerejä Tehtäisiinkö itse? Ei ydinosaamista? Tärkeä oma osuus? Kuka muu osaa? Missä tulee käyttöön? Globaali? Voidaanko hallita keskitetysti? Missä rajapinnat (loogisesti/fyysisesti)?