Posts

CleanText 2.1: De technische schrijfgids voor ICT’ers, coaches en trainers

-
Afbeelding
  Download hier CleanText 2.1: De technische schrijfgids voor ICT’ers, coaches en trainers Ben je als ICT’er in staat om relevante informatie over software scherp te analyseren en helder te documenteren voor jezelf en voor andere belanghebbenden van software? Gebrek aan bruikbare softwaredocumentatie kan leiden tot verkeerde handelingen, verstoorde processen en haperende dienstverlening. Voorbeelden Een klant van een softwareleverancier wil nieuwe functies laten toevoegen aan een bestaande applicatie. De oorspronkelijke developers werken niet meer bij deze leverancier en hebben bovendien geen bruikbare documentatie achtergelaten. Hierdoor kunnen de nieuwe developers de applicatie niet aanpassen. Ze zijn gedwongen om de applicatie geheel opnieuw te ontwikkelen. Het project duurt langer, de kosten stijgen en de klant verliest het vertrouwen in de softwareleverancier. Bij een telecom operator verwijdert een engineer de configuratie van een interconnectiepunt tijdens het updaten van softwa
Meer lezen

Risk cases

-
Afbeelding
Download hier > Risk cases Het is voor software developers en acceptanten niet haalbaar om alle functies en kwaliteitskenmerken van een softwareproduct volledig te testen. De tijd voor testen is beperkt. Hoe bepaal je als developer of acceptant de testprioriteiten? Je analyseert en classificeert eerst de productrisico’s. Vervolgens test je binnen de beschikbare tijd de items die de grootste risico’s opleveren voor de kwaliteit en continuïteit van de dienstverlening. Een risk case specificeert een productgerelateerd risico met concrete voorbeelden. Doel en doelgroepen Na deze workshop kun je als developer of acceptant risk cases specificeren voor software met voorbeelden, zodat je maatregelen kunt nemen om de gespecificeerde productrisico’s te elimineren. Een acceptant kan bijvoorbeeld een rol hebben als product-owner, gebruiker, tester, beheerder, security expert of maintenance engineer. Download hier > Risk cases
Meer lezen

SoftwareCtrl: Checklists voor ICT’ers, coaches en trainers

-
Afbeelding
  Download hier > SoftwareCtrl: Checklists voor ICT’ers, coaches en trainers Doelgroep en doel SoftwareCtrl is geschreven voor ICT’ers, coaches en trainers. Het bestaat uit een reeks checklists. De checklists bevatten criteria voor het evalueren van de kwaliteit van software en gerelateerde informatieproducten. Denk bij informatieproducten aan requirements, ontwerp, test cases, API-documentatie, enzovoort. Een coach of trainer kan bijvoorbeeld een lead developer zijn die junior developers begeleidt op hun groeipad.
Meer lezen

Requirements specificeren: De workshop voor afstudeerders

-
Afbeelding
Download hier > Requirements specificeren: De workshop voor afstudeerders Doelgroep en doel De workshop 'Requirements specificeren' is geschreven voor afstudeerders en hun begeleiders. Aan het einde van de workshop levert de afstudeerder een  SRS, Software Requirements Specification in.  De workshop geeft de begeleiders de mogelijkheid om de studenten te trainen en simultaan hun voortgang te evalueren. In hoeverre is de student bekwaam om software requirements te analyseren, te documenteren en te gebruiken voor het eigen afstudeerproject? Wat moet de student nog doen om het vereiste niveau te bereiken? Software Requirements Specification Een SRS, Software Requirements Specification, is een document waarin de requirements voor een te ontwikkelen of een te selecteren softwareproduct of systeem zijn omschreven. In je afstudeerproject onderzoek je de requirements voorafgaand aan of in de startfase van je project als software het eindproduct is van het project. De onderzochte req
Meer lezen

FunDec: Functionele decomposities opstellen voor software

-
Afbeelding
Download hier > FunDec, Functionele decomposities opstellen voor software FunDec is ontwikkeld voor ICT-studenten en ICT’ers in opleiding.  Deze workshop richt zich op het opstellen van functionele decomposities voor software vanuit het perspectief van de gebruikers. Een functionele decompositie is een boomdiagram dat de taken van een softwareproduct of systeem op een gestructureerde manier weergeeft. Deze taken representeren de functies. ICT’ers maken functionele decomposities om software te analyseren. Functionele decomposities fungeren ook als een communicatiemiddel in het ontwikkelproces van software. De workshop bevat drie kerncomponenten: 1. Oriëntatieoefeningen 2. Concepten 3. Evaluatieoefeningen Zowel de oefeningen als de concepten bevatten concrete voorbeelden om het leerproces te versoepelen. De oefeningen zijn voorzien van uitwerkingen. Door deze eigenschappen is de workshop geschikt voor zelfstudie, training op afstand en training op locatie. De verworven kennis, v
Meer lezen

Schrijfgids requirements

-
Afbeelding
Download hier > 'Schrijfgids requirements' Is so ftware het eindproduct van je afstudeerproject?  Ben je als ICT-student in staat om de relevante requirements duidelijk, consistent en eenduidig te formuleren voor de belanghebbenden? Het onderzoeken van requirements is één van de eerste en belangrijkste taken in je afstudeerproject. De door jou geschreven requirements bieden je docenten de benodigde informatie om te bepalen of je opdracht geschikt is voor een afstudeerproject. Heeft de opdracht het juiste niveau? Is de opdracht realiseerbaar binnen de afstudeerperiode? Jouw requirements geven jou, de opdrachtgever en de begeleiders van het afstudeerproject inzicht, om samen de opdracht aan te passen als het nodig is. Requirements zijn ook het uitgangspunt waarmee je tijdens de beoordeling van je afstudeerproject aantoont dat je de juiste software op de juiste manier hebt ontwikkeld voor de opdrachtgever, gebruikers, beheerders en andere belanghebbenden. Je laat zien
Meer lezen

CleanText: De technische schrijfgids voor ICT-studenten

-
Afbeelding
Download hier  >  'CleanText: De technische schrijfgids voor ICT-studenten' Gebrek aan bruikbare softwaredocumentatie kan leiden tot verkeerde handelingen, verstoorde processen en haperende dienstverlening bij softwareleveranciers. Voorbeelden Een klant van een softwareleverancier wil nieuwe functionaliteiten laten toevoegen aan een bestaande applicatie. De oorspronkelijke developers werken niet meer bij deze leverancier en hebben bovendien geen bruikbare documentatie achtergelaten. Hierdoor kunnen de nieuwe developers de applicatie niet eenvoudig aanpassen. Ze zijn gedwongen om de applicatie geheel opnieuw te ontwikkelen. Het project duurt langer, de kosten stijgen en de klant verliest het vertrouwen in de softwareleverancier. Bij een telecom operator verwijdert een engineer de configuratie van een interconnectiepunt tijdens het updaten van software. Oorzaak? Verkeerde handelingen door inconsistente softwaredocumentatie. Diverse bedrijven en instellingen worden
Meer lezen