T-76.115 Oma menetelmä Arkkitehtuurisuunnittelu

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!