Skelta Software is een particuliere softwarefabrikant. De hoofdvestiging bevindt zich net buiten Bangalore, India en het bedrijf heeft vestigingen in het Verenigd Koninkrijk en de VS. Skelta is gespecialiseerd in bedrijfsbrede BPM (Business Process Management) en geavanceerde workflowoplossingen voor kleine tot grote bedrijven wereldwijd. Ons paradepaard, ‘Skelta BPM’, biedt bedrijven een krachtig collaboratie platform waarmee handmatige en systeemgestuurde werkprocessen voor de realisering van specifieke bedrijfsdoelen worden geautomatiseerd.
Skelta Software is een particuliere softwarefabrikant. De hoofdvestiging bevindt zich net buiten Bangalore, India en het bedrijf heeft vestigingen in het Verenigd Koninkrijk en de VS. Skelta is gespecialiseerd in bedrijfsbrede BPM (Business Process Management) en geavanceerde workflowoplossingen voor kleine tot grote bedrijven wereldwijd. Ons paradepaard, ‘Skelta BPM’, biedt bedrijven een krachtig collaboratie platform waarmee handmatige en systeemgestuurde werkprocessen voor de realisering van specifieke bedrijfsdoelen worden geautomatiseerd.
Application lifecycle management wat betekent dat nou eigenlijkHenk Beekhuis
pplication Lifecycle Management wat betekent dat nou eigenlijk?
Deze vraag werd me vandaag gesteld op een netwerkevent waardoor ik gedwongen werd in Jip en Janneke taal over de materie na te denken.
“De reis van initieel idee naar uitfasering voor een softwareapplicatie.”
Het eerste deel van het antwoord klinkt logisch, maar uitfasering? Jazeker, software heeft een levensduur en is na een aantal jaar uitgerangeerd.
Dan is het maar beter wanneer daarover nagedacht is...
Met de centralisatie van de opslag maken steeds meer en verschillende applicaties en systemen hiervan gebruik met ieder hun eigen karakateristieken in IO. Bij aanschaf en inrichting wordt echter vaak, om het beheer te vereenvoudigen gekozen voor een 'one-size-fits-all' oplossing. Niet zelden gaat dit echter wringen waardoor er prestatie problemen in de service ontstaan. Met het doorlichten van de centrale opslag kunnen deze bottleneck snel inzichtelijk gemaakt worden en verbeteringen aangebracht zodat reeds gemaakte investeringen beter en langer renderen.
CRM 2011 als xRM platform - CRM PartnersExploreDynCRM
De C in CRM staat voor Customer. Zoveel is helder. Maar niet iederéén die een relatie onderhoudt met een bedrijf of een organisatie is per definitie een 'customer'. Want van een vereniging ben je lid. Aan een community neem je deel. Van een goed doel ben je donateur. Van een bedrijf kun je leverancier zijn. En bij een opleidingsinstituut ben je student. CRM Partners vervangt daarom de C van CRM vaak door de ruim invulbare x. Het rendementsvolle resultaat? Geavanceerd Relationship Management met wie u maar wilt.
Forms2Future in action for SaaS provider ConnexysLucas Jellema
This article describes the history of the NextGen project at Dutch SaaS provider Connexys (www.connexys.eu). It outlines common challenges for SaaS applications - such as customization and cross-cloud-integration - and describes how these were addressed. The article brushes upon the technology used (Oracle Database, SQL/PLSQL, Oracle ADF (ADF BC, JSF/ADF Faces, JDeveloper, JHeadstart).
Hoe technische beperkingen uw outtasking of -sourcing traject kunnen laten m...Proact Netherlands B.V.
"Ik besteed het toch uit?"
Ook als een infrastructuur in de vorm van outtasking als een dienst wordt afgenomen is techniek van belang. In de dagelijkse praktijk blijken outtasking en -sourcing failures namelijk regelmatig te worden veroorzaakt door verkeerde technische keuzes. Houd dus grip op de technische aspecten van een dienst. Waar kunt u op letten?
- Hoe zorg ik ervoor dat mijn provider een infrastructuur als gedegen fundament biedt?
- Kan innovatie eenvoudig worden geïncorporeerd of vereist deze forklift upgrades en extra kosten?
- Is deze schaalbaar en waar liggen de onvoorziene glazen plafonds?
In deze presentatie worden de belangrijkste technische valkuilen van outtasking besproken aan de hand van praktijk voorbeelden.
HTML 5, ASP.NET MVC & Windows Azure sessie voor Ivo BruggePureplexity
Deze presentatie werd gegeven bij de sessie die we gaven voor de 2de en 3de jaars studenten van het graduaat informatica aan het IVO te Brugge. In deze presentatie behandelden we 3 grote onderwerpen: HTML 5, ASP.NET MVC en Windows Azure.
Application lifecycle management wat betekent dat nou eigenlijkHenk Beekhuis
pplication Lifecycle Management wat betekent dat nou eigenlijk?
Deze vraag werd me vandaag gesteld op een netwerkevent waardoor ik gedwongen werd in Jip en Janneke taal over de materie na te denken.
“De reis van initieel idee naar uitfasering voor een softwareapplicatie.”
Het eerste deel van het antwoord klinkt logisch, maar uitfasering? Jazeker, software heeft een levensduur en is na een aantal jaar uitgerangeerd.
Dan is het maar beter wanneer daarover nagedacht is...
Met de centralisatie van de opslag maken steeds meer en verschillende applicaties en systemen hiervan gebruik met ieder hun eigen karakateristieken in IO. Bij aanschaf en inrichting wordt echter vaak, om het beheer te vereenvoudigen gekozen voor een 'one-size-fits-all' oplossing. Niet zelden gaat dit echter wringen waardoor er prestatie problemen in de service ontstaan. Met het doorlichten van de centrale opslag kunnen deze bottleneck snel inzichtelijk gemaakt worden en verbeteringen aangebracht zodat reeds gemaakte investeringen beter en langer renderen.
CRM 2011 als xRM platform - CRM PartnersExploreDynCRM
De C in CRM staat voor Customer. Zoveel is helder. Maar niet iederéén die een relatie onderhoudt met een bedrijf of een organisatie is per definitie een 'customer'. Want van een vereniging ben je lid. Aan een community neem je deel. Van een goed doel ben je donateur. Van een bedrijf kun je leverancier zijn. En bij een opleidingsinstituut ben je student. CRM Partners vervangt daarom de C van CRM vaak door de ruim invulbare x. Het rendementsvolle resultaat? Geavanceerd Relationship Management met wie u maar wilt.
Forms2Future in action for SaaS provider ConnexysLucas Jellema
This article describes the history of the NextGen project at Dutch SaaS provider Connexys (www.connexys.eu). It outlines common challenges for SaaS applications - such as customization and cross-cloud-integration - and describes how these were addressed. The article brushes upon the technology used (Oracle Database, SQL/PLSQL, Oracle ADF (ADF BC, JSF/ADF Faces, JDeveloper, JHeadstart).
Hoe technische beperkingen uw outtasking of -sourcing traject kunnen laten m...Proact Netherlands B.V.
"Ik besteed het toch uit?"
Ook als een infrastructuur in de vorm van outtasking als een dienst wordt afgenomen is techniek van belang. In de dagelijkse praktijk blijken outtasking en -sourcing failures namelijk regelmatig te worden veroorzaakt door verkeerde technische keuzes. Houd dus grip op de technische aspecten van een dienst. Waar kunt u op letten?
- Hoe zorg ik ervoor dat mijn provider een infrastructuur als gedegen fundament biedt?
- Kan innovatie eenvoudig worden geïncorporeerd of vereist deze forklift upgrades en extra kosten?
- Is deze schaalbaar en waar liggen de onvoorziene glazen plafonds?
In deze presentatie worden de belangrijkste technische valkuilen van outtasking besproken aan de hand van praktijk voorbeelden.
HTML 5, ASP.NET MVC & Windows Azure sessie voor Ivo BruggePureplexity
Deze presentatie werd gegeven bij de sessie die we gaven voor de 2de en 3de jaars studenten van het graduaat informatica aan het IVO te Brugge. In deze presentatie behandelden we 3 grote onderwerpen: HTML 5, ASP.NET MVC en Windows Azure.
1. Image: Francesco Marino / FreeDigitalPhotos.net
REPAF
Requirement Patterns Framework
for web-based systems
André P. Wolters Versie 1.0 - 2010
2. Hergebruik van requirements…
In de requirement specificaties van complexe web-based systemen zijn
patronen (patterns) te herkennen die vaak terugkomen.
Waarom deze patronen niet in kaart brengen en hergebruiken?
…..in plaats van steeds opnieuw het wiel uitvinden.
REPAF
3. Wat is REPAF (1)?
REPAF staat voor “Requirement Patterns Framework” en is de schakel
tussen de requirements definitie (probleem domein) en de oplossingen op
het snijvlak van Business en ICT.
REPAF richt zich op requirement patterns die vaak aanwezig zijn in het
probleem domein van web-based systemen.
NB. REPAF focust niet op design-patterns (oplossingen) maar op patterns die requirements van
stakeholders aangeven.
NB2. In deze presentatie wordt met requirements, de behoefte/eisen van de stakeholders
bedoeld.
REPAF is een framework waarbij de focus ligt op (complexe) web-based
systemen met:
Meerdere stakeholders en actoren.
Meerdere schermen.
Meerdere (gelijktijdige) gebruikers .
Complexe informatiestromen/transacties.
Meerdere interfaces/web services naar (externe) systemen.
4. Wat is REPAF (2)?
Binnen het framework zijn meerdere aandachtsgebieden gedefinieerd.
Dit worden ook wel gezichtspunten genoemd.
Vanuit elk gezichtspunt zijn veel voorkomende patterns gedefinieerd.
Het framework biedt daarnaast ook structuur om te komen tot:
Een completere en juiste verzameling requirements.
Een eenduidige definitie van de requirements.
Koppeling van requirements naar oplossingen.
Sturen op basis van requirements.
5. Het REPAF framework (1)
REPAF mindmap met (high level) gezichtspunten.
Project Start
Documentatie Requirements Schermen
Domein
Migratie
Entiteiten
Security en Interfaces
Privacy
Web-based
system
Flexibiliteit Toegang
Performance Rapportages
Internet Archivering,
Marketing Commercieel Backup en Logging
Purging
6. Het REPAF framework (2)
Voorbeelden van een aantal gezichtspunten en mogelijke patterns:
Project Start Requirements
Deze patterns hebben o.a. betrekking op de beperking/beheersing van het beoogde
systeem.
Voorbeelden: Business Value, Voldoen aan project start architecturen, Voldoen aan project
standaarden, Bedrijfsstandaarden, Wettelijke regels, Beperkingen m.b.t. technologie,
Stakeholder management, Haalbaarheidseisen.
Schermen
Voorbeelden: Functies op hoofdschermen en beheerschermen, Usability, Data standaarden.
Interfaces
Voorbeelden: Throughput, Scalability, Security, Technology, Quality of Service.
Toegang systeem
Voorbeelden: Registratie, Configuratie, Authenticatie, Autorisatie regels.
7. Het REPAF framework (3)
Voorbeelden van een aantal gezichtspunten en mogelijke patterns:
Rapportages en documentatie
Voorbeelden: SLA rapportages, Financiële rapportage, Handleidingen, Trainingen, Business
Process Modelling.
Archivering en Logging
Voorbeelden: Data beschikbaarheid, Bewaartermijn, Audit trails, Error logs, Functionele logs.
Performance en Flexibiliteit
Voorbeelden: Response Time, Throughput, Schaalbaarheid, Beschikbaarheid,
Beheerbaarheid, Testbaarheid.
8. REPAF in de praktijk (1)
Bepaal de “ruimte” waarbinnen de requirements zich bevinden.
Met name het gezichtspunt “Project Start Requirements” zal worden toegepast.
In deze stap is het belangrijk om de grenzen (beperking/beheersing) van het “beoogde”
systeem zo snel en goed mogelijk te bepalen om later scope creeping te voorkomen.
Binnen deze grenzen bevinden zich de
requirements van de stakeholders.
De requirements zijn hier nog “blanco”
en worden in een volgende stap bepaald.
9. REPAF in de praktijk (2)
Bepaal via de diverse gezichtspunten de requirements van het beoogde
systeem.
NB. Het framework is een handvat waarbij andere gezichtspunten ook gebruikt en toegepast
kunnen worden voor het vinden van requirements.
Doel: Vul de “ruimte” waarin de requirements zich bevinden zo goed mogelijk door vanuit
diverse gezichtspunten naar het beoogde systeem te kijken met verschillende stakeholders.
Waarom?: Krijg een completere en juiste verzameling requirements door
vanuit verschillende gezichtspunten te kijken. Reduceer hiermee risico’s en
krijg oplossingen die ook (beter) voldoen aan de behoefte van de stakeholders.
10. REPAF in de praktijk (3)
Probleem domein en de relatie met het oplossingsdomein.
Geef relaties aan
tussen requirements. Bepaal eerst wat de echte top-eisen zijn van het
systeem. Werk top-down naar sub-eisen net zo
Probleem domein ver tot eventuele “risico’s” aanvaardbaar zijn.
Geef relaties aan tussen requirements en
oplossing(en). Welke requirement wordt door
welke oplossing gerealiseerd (Traceability).
Oplossingen
De kunst is om een balans te vinden tussen hoe
ver te gaan in het verzamelen van requirements
en de vrijheid (oplossingsruimte) die aan de
leverancier/opdrachtnemer wordt gegeven.
11. REPAF in de praktijk (4)
Sturen op resultaat. Top-down naar oplossing en taken (Synergio methodiek).
Het resultaat
Opdrachtgever en opdrachtnemer
onderhandelen over maakbaarheid en
haalbaarheid van de requirements.
Requirements
Requirements
Breakdown
Structure
Maakbaarheid Haalbaarheid
Management van
Requirement,
Product en Work
Breakdown
Structures
Oplossing Taken
Product
Work Breakdown
Breakdown
Structure
Structure
12. REPAF in de praktijk (5)
Algemene praktische zaken:
Gebruik REPAF als een handvat om een goede start te kunnen maken in
een project.
Schrijf SMART requirements.
Opdrachtgever en opdrachtnemer moeten een eenduidig beeld hebben van de
requirements en daarmee de behoefte.
Gebruik een tool om de requirements vast te leggen en te managen.
NB. Het vastleggen en managen van requirements met een WORD doc of een Excel sheet
verhoogt het risico dat er relatief te veel tijd wordt besteed aan het beheer van deze
documenten en te weinig tijd aan het vinden van een goede verzameling requirements.
Het gevolg: Een grotere kans dat de uiteindelijke oplossingen niet voldoen aan de behoefte.
13. Waarom REPAF (1)?
“Om oplossingen te krijgen die (beter) voldoen aan de
behoefte van de stakeholders, waarbij de oplossing een
toegevoegde waarde heeft (business value) en een
investering die gerechtvaardigd is.”
14. Waarom REPAF (2)?
Kenmerken van REPAF die dit mogelijk maken:
Structuur in het vinden van de juiste requirements.
Het framework met diverse gezichtspunten en requirement patterns biedt structuur in het
proces van het vinden van een goede verzameling requirements.
Het vinden van een completere en juiste verzameling van requirements.
Het framework dekt de “ruimte” waarin de requirements zich bevinden beter af. Door met
verschillende stakeholders te kijken via deze gezichtspunten, wordt de kwaliteit, juistheid en
volledigheid, van de verzameling requirements hoger en zorgt daarmee voor oplossingen die
(beter) voldoen aan de behoefte van de stakeholders.
Het sneller vinden van “risicovolle” requirements.
Door te kijken via verschillende gezichtspunten worden requirements met een hogere risico
eerder onderkend.
Sturen en focus op resultaat.
Onderhandel over maakbaarheid en haalbaarheid met als uitgangspunt dat de op te leveren
oplossing toegevoegde waarde heeft voor de klant en de investering hierin gerechtvaardigd is.
15. Geraadpleegde bronnen REPAF
Best practices en lessons learned.
Sinds eind 1999 gewerkt op diverse (grote) web-based projecten voor:
KPN, Friesland Bank en Achmea.
Als: Software Engineer, Technisch Ontwerper, Functioneel Ontwerper,
Requirements Engineer, Informatie Analist.
Synergio methodiek (Trainingen gevolgd bij Synergio).
Literatuur van bekende guru’s op het gebied van requirements:
Suzanne Robertson en James Robertson
Karl Wiegers
Stephen Withall
Tom Gilb
Diverse andere literatuur, artikelen en papers op het gebied van:
Requirements
Stakeholder management
Ontwerp: Use Cases (o.a. Cockburn), UML
Agile development: RUP, SCRUM