De presentatie wordt gedownload. Even geduld aub

De presentatie wordt gedownload. Even geduld aub

Deel 2: Principles en Scope Februari 2010, herziene versie I-6 Software architectuur.

Verwante presentaties


Presentatie over: "Deel 2: Principles en Scope Februari 2010, herziene versie I-6 Software architectuur."— Transcript van de presentatie:

1 Deel 2: Principles en Scope Februari 2010, herziene versie I-6 Software architectuur

2 I-6 deel2, feb 2010, Gerard Mijnarends Vorige les Wat is jullie bijgebleven? Architectuur is een vaag begrip met vele definities Er zijn meerdere soorten architectuur Van heel abstract tot bijna een ontwerp Begrippen: Stakeholders Concerns Views Perspectives Een goede architectuur is begrijpbaar en legt uit hoe je problemen oplost. (Hoe je concerns adresseert)

3 I-6 deel2, feb 2010, Gerard Mijnarends Requirements versus architectuur

4 I-6 deel2, feb 2010, Gerard Mijnarends Architectuur programma versus project Architectuur is vaak ook projectoverstijgend Niet voor ieder project het wiel opnieuw uitvinden Standaardisatie Middels referentie architecturen en blauwdrukken …en via normen, voorschriften..en via infrastructuur projecten Identity management Server virtualisatie Repository’s

5 I-6 deel2, feb 2010, Gerard Mijnarends Programma’s

6 I-6 deel2, feb 2010, Gerard Mijnarends Principles Definitie boek blz 100 “A fundamental that guides..” Een belangrijke toevoeging Nu Of in de toekomst Vaak wil men in de toekomst een verbetering door een nieuwe architectuur Maar alle bestaande ICT is nog lang niet aangepast.

7 I-6 deel2, feb 2010, Gerard Mijnarends Voorbeelden principles Bron: Sogeti, Dya presentatie

8 I-6 deel2, feb 2010, Gerard Mijnarends Voorbeeld (principle)

9 I-6 deel2, feb 2010, Gerard Mijnarends Van principle naar requirement Hoe vertaal ik de algemene eis naar een requirement in mijn project? Principle  Project requirement  Project implementatie Vaak ook algemene infra nodig Centrale dataopslag, is die er al? Identity management, bijvoorbeeld DigiD.

10 I-6 deel2, feb 2010, Gerard Mijnarends Rationale Het waarom Het waarom van een principle of requirement Als uitleg waarom je iets wil Voorbeeld: Principle: Iedere werknemer kan inloggen op iedere PC binnen onze organisatie Rationale: Dit maakt flexwerken mogelijk, een werknemer heeft geen vaste werkplek Maar ook handig bij uitzonderingen (80/20 regel) Is rationale wel relevant? In geval van hoge kosten, hoe erg is het om af te wijken. “uitzonderingen bevestigen de regel”!

11 I-6 deel2, feb 2010, Gerard Mijnarends Scope Waarom is de scope belangrijk? Anders geen grenzen van je opdracht. Dit geldt uiteraard niet alleen voor architectuur Een goede “scope definitie” voldoet aan: Kort en bondig Maar toch gedetailleerd genoeg Geen jargon Geaccepteerd Begrepen

12 I-6 deel2, feb 2010, Gerard Mijnarends Bij de opstart Zorg voor helderheid over: Business goals and drivers Architectural scope Architectural concerns Architectural principles Other architectural constraints

13 I-6 deel2, feb 2010, Gerard Mijnarends Kwaliteit van requirements Pas op voor vage requirements Voorbeelden: Het systeem is gebruiksvriendelijk Het systeem is snel Het systeem is betrouwbaar Probeer deze requirements SMART te maken. Pas ook op voor wensen Het systeem maakt gebruik van Open Standaarden Het systeem is platform onafhankelijk Is dit verplicht? Zoja en heeft men daar geld en tijd voor over?

14 I-6 deel2, feb 2010, Gerard Mijnarends Hoe te starten? Honderden concerns, maar hoe start je dan? Functionele gebieden Externe interfaces Impact op andere systemen Data-migratie / conversie Maak bv. een context diagram, start zo simpel mogelijk

15 I-6 deel2, feb 2010, Gerard Mijnarends Hoe te starten: Integratie probleem, een model

16 I-6 deel2, feb 2010, Gerard Mijnarends Wanneer is een architectuur geslaagd? Als je stakeholders hem begrijpen Als ze akkoord gaan Uiteindelijk als je een goed werkend systeem oplevert EN …. men ook na jaren nog tevreden is over de architectuur OMDAT… “Changes” snel en zonder problemen doorgevoerd kunnen worden.

17 I-6 deel2, feb 2010, Gerard Mijnarends Keep it stupid & simple KISS Bijna altijd hoe eenvoudiger een systeem hoe beter Uiteraard genoeg voor de behoefte Voordelen: Minder schakels Minder situaties (complexiteit), die allemaal correct … Beter begrijpbaar Maar wanneer is een systeem simpeler? Schema’s zijn (soms) bedrieglijk Integratie via Enterprise Application Integration (via een messagebus) lijkt simpel maar …

18 I-6 deel2, feb 2010, Gerard Mijnarends Valideren van functionaliteit Bedenk scenario’s Probeer te begrijpen waarvoor het systeem gebruikt wordt En als iets niet helemaal klopt, wat dan? Bedenk dus ook slecht weer scenario’s, dit om het systeem robuust te maken!

19 I-6 deel2, feb 2010, Gerard Mijnarends Architectual description (AD) Hoe maak je deze goed leesbaar voor je stakeholders Advies: Gebruik veel figuren en diagrammen Leesbaar voor stakeholder Vaak liever blokschema’s dan UML-diagrammen Gebruik bondige opsommingen of matrices Vermijd vooral uitgebreide tekst. …en helaas een korte bondige tekst kost meer tijd om te schrijven.

20 I-6 deel2, feb 2010, Gerard Mijnarends Functional Functional Viewpoint Startpunt, daar begin je mee! Zie definitie boek: … functional elements and their responsibilities, interface, interactions Door het functional viewpoint begrijp je wat het systeem doet! Detaillering en notatie is afhankelijk van je stakeholders Sluit aan bij bekende schema’s van je doelgroep Niet iedereen kan UML lezen. (vergelijk fig 16.2 en 16.3) Blokschema’s (aangevuld met pictogrammen) komen veel voor. Detaillering is altijd een moeilijk punt “hoe ver moet je gaan?” Te veel, moeilijk begrijpbaar, je verliest overzicht Te weinig, je gaat voorbij aan belangrijke punten (waarover beslissingen nodig zijn)

21 I-6 deel2, feb 2010, Gerard Mijnarends Information Information viewpoint Beschrijft de data. Welke data wordt er nu uitgewisseld De opslag Waar? Klassediagrammen / ERD’s (meestal hoofdlijnen) En hoe de data in het systeem verandert Ownership. Wie is de eigenaar Vooral van belang bij meerdere databases (synchronisatie) Welke data is nu leading? Ook offline databases Volumes van data Typisch, check is het spannend? Zoja dan …

22 I-6 deel2, feb 2010, Gerard Mijnarends Transacties Zijn er processtappen die één transactie moeten zijn Backup en recovery

23 I-6 deel2, feb 2010, Gerard Mijnarends Datakwaliteit Misschien wel de nummer 1-reden van het falen van IT projecten Wat is datakwaliteit? Verkeerd adres 10 manieren waarop een naam gespeld is voor 1 persoon Prijs verouderd Tom Tom kent een nieuwe of aangepaste weg niet Waarom zo belangrijk? Waarom bij EAI (integratie) nog belangrijker? Niet uitwisselbare definities.

24 I-6 deel2, feb 2010, Gerard Mijnarends Regels Privacy wetgeving Archivering (vaak wettelijke verplichting) Juridisch (voor als er een rechtzaak komt) Beursgenoteerde bedrijven (Sarbanes-Oxley)

25 I-6 deel2, feb 2010, Gerard Mijnarends Case rooster Je hebt een centraal roosterbureau Je hebt je eigen persoonlijke agenda Hoe ziet de information architecture eruit? 5 min.

26 I-6 deel2, feb 2010, Gerard Mijnarends Concurrency Concurrency viewpoint Gelijktijdigheid Allerlei processen vinden gelijktijdig plaats (of juist niet) Tot voorkort veel batch processen Maar kan dit zomaar? Voorbeeld: Als je een backup van je database maakt, kan het systeem dan actief zijn? Groot raakvlak met Schaalbaarheid Aantal gebruikers Performance Technisch lijkt het op multi threading probleem, maar op een hoger abstractie niveau

27 I-6 deel2, feb 2010, Gerard Mijnarends Datasharing Sessie informatie Statefull Stateless Caching (wanneer bijgewerkt) Conclusie: concurrency is complex Maar wel belangrijk Problemen leveren vervelende bugs op (vaak gaat het goed maar soms niet) Bedenk vooral ook scenario’s om het te begrijpen

28 I-6 deel2, feb 2010, Gerard Mijnarends Development Development viewpoint Zowel de opbouw van je code (modules/ design patterns) …als technologie keuzes (oa frameworks) Third party componenten (wat bouw jezelf en wat koop je) Maar ook je ontwikkeltools en ontwikkelproces Denk bij het laatste ook aan versiebeheer Testomgevingen Alles steeds opnieuw bouwen kan niet kost teveel tijd, en dus ook duur En levert vooral ook teveel kinderziektes op. Term ontwikkelstraat, voor herbruikbare componenten en ontwikkelomgeving over projecten heen.

29 I-6 deel2, feb 2010, Gerard Mijnarends Development Development viewpoint (2) De keuzes hierin hebben een grote invloed op algemene principles. Welke? Platform onafhankelijkheid Ondersteunde devices Integratie met andere systemen State of the art ontwikkelingen kunnen volgen Uitbreidbaarheid (vrije programmeertaal of COTS framework)

30 I-6 deel2, feb 2010, Gerard Mijnarends Deployment Deployment viewpoint Het uitrollen van je nieuwe / gewijzigde systeem De ontwikkelomgeving ≠ de productieomgeving Ontwikkelaars onderschatten deze vaak Het werkt ook op mijn PC of test server dus dit is toch geen punt …

31 I-6 deel2, feb 2010, Gerard Mijnarends Technische problemen bij deployment Unproven technology Versie conflicten Tooltjes,dll’s en settings die nodig zijn. Maar die niet gedocumenteerd zijn Anders geïnstalleerde platformen Maar ook licenties En je mag niet zomaar een systeem herstarten (voor de nieuwe config) Benodige capaciteit van netwerk, opslag, servers enz.

32 I-6 deel2, feb 2010, Gerard Mijnarends Organisatorisch Change procedures (ITIL) Impact analyse Ruim van te voren aanvragen Precies specificeren Vragen, vragen, vragen (weet je zeker dat …) Waarom? Kijken met de bril van dat het blijft het systeem werken Is soms lastig, maar ze hebben zeker een punt want Er zijn veel onverantwoorde changes Beheer is normaal conservatief. Staat op de rem.

33 I-6 deel2, feb 2010, Gerard Mijnarends Operational Operational viewpoint Gaat over de productieomgeving Hoe beheer je het systeem zodat je de afgesproken service levels behaalt (gebruiker/opdrachtgever tevreden) Migraties naar een nieuw systeem (dat normaal iets vervangt) Hoe ga je dit doen? En de gebruikers kunnen blijven doorwerken. Belangrijk datamigratie Via een bigbang scenario? Klinkt aantrekkelijk maar … Heb je een rollback scenario?

34 I-6 deel2, feb 2010, Gerard Mijnarends Monitoring Kan je zien of een systeem goed werkt? Aangesloten op een commandobrug? (alerts) Wat beteken al die warning en errors in een log nu? De beheerders zijn minder bekend met “jouw” systeem Term “over de schutting gooien” Monitoring is een essentieel punt voor een betrouwbaar systeem. Groot raakvlak met perspective Availibility

35 I-6 deel2, feb 2010, Gerard Mijnarends Literatuur Studieboek H7,H8 H16 t/m H21

36 I-6 deel2, feb 2010, Gerard Mijnarends Eén centraal systeem Wat zijn de voordelen? Het lijkt altijd aantrekkelijk Slechts één systeem, dus goedkoper Informatie over grenzen heen Ziet er simpel uit Maar, … Grotere afstand tot gebruikers Functionaliteit van iedereen moet kloppen Anoniemer, correctie uit het hoofd kan niet meer Vooral invoering is berucht!

37 De Haagse Hogeschool


Download ppt "Deel 2: Principles en Scope Februari 2010, herziene versie I-6 Software architectuur."

Verwante presentaties


Ads door Google