T-76.115 Oma menetelmä Arkkitehtuurisuunnittelu Jarkko Ilomäki 28.1.2004.

Esitys aiheesta: "T-76.115 Oma menetelmä Arkkitehtuurisuunnittelu Jarkko Ilomäki 28.1.2004."— Esityksen transkriptio:

1 T-76.115 Oma menetelmä Arkkitehtuurisuunnittelu Jarkko Ilomäki 28.1.2004

2 Sisällys Menetelmän käyttö projektissa Mittareiden tarkistelu Kokemuksia Soveltuvuus projektiin

3 Menetelmän käyttö projektissa Menetelmää tarvittiin eniten PS- ja I1- vaiheissa järjestelmäarkkitehtuurin luomiseksi. Käyttö ollut suunnitelmallista eikä alun prosessia tarvinnut juurikaan muuttaa. Käyttö sulautunut suunnitteluun, dokumentointiin ja varsinaiseen tekemiseen.

4 Menetelmän käyttö projektissa Menetelmällä luotiin ensin kehys, jota lähdettiin osa-alueittain tarkentamaan Tiedonsiirto GUI GUI Kanta Kanta

5 Menetelmän käyttö projektissa Ajankäyttö: 10h henkilökohtainen menetelmä ~40h arkkitehtuurin tarkennus aihealueittain. I3-vaiheessa ei ole odotettavissa suurta lisäystä, nyt tarvitaan vain raakaa työtä.

6 Mittarit Alkuperäiseen arkkitehtuuriin tulleiden muutosten lukumäärä Muutoksiin kulunut aika Jouduttiinko suunnitteluprosessin vaiheista poikkeamaan? Miksi ja paljonko? Arvio tai testitulos arkkitehtuurin tehokkuudesta.

7 Mittarit – Tehdyt muutokset Ei yhtään järjestelmätason muutosta Toiminnanjako (kanta, ohjelmistokomponentit, JSP) ennallaan Palvelinjako ennallaan. 1 modulitason muutos Moduli Support jätetty toteuttamatta, toiminnot integroitu muiden modulien alle. Korjaukseen ei kulunut yhtään aikaa, modulia ei oltu aloitettu.

8 Mittarit – Tehdyt muutokset 5 tietokantamuutosta Asiakkaan tarkennuksista johtuneita taulumuutoksia. Aikaa kulunut n. 1h (dokumentointi). => Arkkitehtuuri pysynyt hyvin stabiilina

9 Mittarit – Suunnitteluprosessin noudattaminen Suunnitteluperiaatteita ja -prosessia noudatettu todella hyvin. Arkkitehtuurikehyksen tarkentamisessa muutama kohta jätetty toissijaiseksi Ei merkitystä tässä projektissa. Esim. tiukat reaaliaikavaatimukset tai vahva oikeuksienhallinta eivät oleellisia.

10 Mittarit – Arkkitehtuurin tehokkuuden arviointi Kehitystestivaiheessa toimii todella lupaavasti: Etäyhteys ilman mainittavaa verkkoviivettä konvertoi ja siirtää 5000 mittausta 3 minuutissa etäkannasta omaan kantaan. Web-käyttöliittymä ylittää annetut viivevaatimukset, esim. kulutusseurantagraafien muodostus kannan tiedoista on nopeaa.

11 Mittarit – Arkkitehtuurin tehokkuuden arviointi Arkkitehtuuri on modulaarinen Kantatoiminnot ja käyttöliittymä erikseen kehitettäviä. IOBASEWeb-verkkokehys yhdistää tehokkaasti käyttöliittymän ja kannan toisiinsa. Vastuunjako kantaproseduurien ja ohjelmistokomponenttien välillä on toiminut hyvin.

12 Mittarit – Arkkitehtuurin tehokkuuden arviointi Arkkitehtuuri tukee rinnakkaisuutta operaatioissa. Selkeä dokumentointi. JavaDoc, SQLDoc, Tekninen määrittely Vasta (rajoitettu) tuotantokäyttö paljastaa mahdolliset pullonkaulat!

13 Kokemuksia Tuonut esiin uusia asioita ja näkökulmia. Auttanut luomaan hyvän ratkaisun. Tuonut ryhdikkyyttä ja ”suunnan” suunnitteluun. Auttanut ohjelman osien välisen vastuunjaon määrittämisessä. Opettanut uusia asioita ja käsitteitä.

14 Kokemuksia Valmiita ratkaisuja ei ollut sellaisenaan tarjolla ”Syvin” taso määritettävä itse. Mahdollisti iteroinnin, kuitenkin runko oltava valmiina. Aikaa syvällisempään perehtymiseen ei ollut. Mittareiden määrittämisen vaikeus Arkkitehtuurin tehokkuus subjektiivinen käsite.

15 Soveltuvuus projektiin Menetelmä vaatii ennakkotietoja ja aikaa perehtymiseen. Huomattavan laaja osa-alue. Valmiita ”malleja” joutuu räätälöimään. Oikeita ratkaisuja ei ole olemassa. Käyttö painottuu projektin alkuun. Tällöin suunnittelun on edettävä ripeästi. Käytön on järjevää olla rajoitettua (mitä useampi kokki...)

16 Soveltuvuus projektiin Vaiva kuitenkin kannattaa Vähemmän muutoksia. Stabiilimpi ympäristö. Kattaa enemmän asioita. Asioita on mietitty. Asioita on dokumentoitu. Helpottaa jatkokehitystä.

17 Soveltuvuus projektiin Lopputulos: => Kyllä se soveltuu!