De presentatie wordt gedownload. Even geduld aub

De presentatie wordt gedownload. Even geduld aub

I-6 Software architectuur

Verwante presentaties


Presentatie over: "I-6 Software architectuur"— Transcript van de presentatie:

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

2 Vorige les Wat is jullie bijgebleven?
4 april 2017 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 Requirements versus architectuur
4 april 2017 Requirements versus architectuur

4 Architectuur programma versus project
4 april 2017 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 4 april 2017 Programma’s

6 Principles Definitie boek blz 100 “A fundamental that guides..”
4 april 2017 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 Voorbeelden principles
4 april 2017 Voorbeelden principles Bron: Sogeti, Dya presentatie

8 Voorbeeld (principle)
4 april 2017 Voorbeeld (principle)

9 Van principle naar requirement
4 april 2017 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 Rationale Het waarom van een principle of requirement
4 april 2017 Rationale 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 Scope Waarom is de scope belangrijk?
4 april 2017 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 Bij de opstart Zorg voor helderheid over: Business goals and drivers
4 april 2017 Bij de opstart Zorg voor helderheid over: Business goals and drivers Architectural scope Architectural concerns Architectural principles Other architectural constraints

13 Kwaliteit van requirements
4 april 2017 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 Hoe te starten? Honderden concerns, maar hoe start je dan?
4 april 2017 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 Hoe te starten: Integratie probleem, een model
4 april 2017 Hoe te starten: Integratie probleem, een model

16 Wanneer is een architectuur geslaagd?
4 april 2017 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 Keep it stupid & simple KISS
4 april 2017 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 Valideren van functionaliteit
4 april 2017 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 Architectual description (AD)
4 april 2017 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 Functional Viewpoint Startpunt, daar begin je mee!
4 april 2017 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 Information viewpoint
4 april 2017 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 Transacties Zijn er processtappen die één transactie moeten zijn
4 april 2017 Transacties Zijn er processtappen die één transactie moeten zijn Backup en recovery

23 4 april 2017 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 Regels Privacy wetgeving Archivering (vaak wettelijke verplichting)
4 april 2017 Regels Privacy wetgeving Archivering (vaak wettelijke verplichting) Juridisch (voor als er een rechtzaak komt) Beursgenoteerde bedrijven (Sarbanes-Oxley)

25 Case rooster Je hebt een centraal roosterbureau
4 april 2017 Case rooster Je hebt een centraal roosterbureau Je hebt je eigen persoonlijke agenda Hoe ziet de information architecture eruit? 5 min.

26 Concurrency viewpoint
4 april 2017 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 Datasharing Sessie informatie Caching (wanneer bijgewerkt)
4 april 2017 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 Development viewpoint
4 april 2017 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 Development viewpoint (2)
4 april 2017 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 Deployment viewpoint Het uitrollen van je nieuwe / gewijzigde systeem
4 april 2017 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 Technische problemen bij deployment
4 april 2017 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 Organisatorisch Change procedures (ITIL) Waarom?
4 april 2017 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 Operational viewpoint
4 april 2017 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 Monitoring Kan je zien of een systeem goed werkt?
4 april 2017 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 4 april 2017 Literatuur Studieboek H7,H8 H16 t/m H21

36 Eén centraal systeem Wat zijn de voordelen? Maar, …
4 april 2017 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! 36

37 <Dienst of Afdeling> <Telefoon> <E-mail>
4 april 2017 De Haagse Hogeschool <Dienst of Afdeling> <Telefoon> < >


Download ppt "I-6 Software architectuur"

Verwante presentaties


Ads door Google