“Omdat fouten en misverstanden te veel kosten” Software Quality Function Deployment Een methode waarbij de eisen en wensen van de gebruiker het ontwerp en de realisatie sturen De belangrijkste doelstelling van een bedrijf of organisatie is produkten of diensten aanbieden welke nauw aansluiten bij de behoeften van de klant. De methode om dit te bereiken wordt door de Japanners Quality Function Deployment (QFD) genoemd. En ze hebben daar belangrijke successen mee behaald. Toyota introdueerde tussen 1977 en 1984 vier nieuwe vrachtwagens met gebruikmaking van QFD. In vergelijking met 1977 was de introductie van de vrachtwagen van 1979 20% die van 1982 38% en die van 1984 61% goedkoper. Niet alleen de kosten waren lager maar ook de ontwerp-, ontwikkel- en produktietijd waren verkort met 30%. Dit laatste werd vooral veroorzaakt door een sterke verlaging van de ontwerpwijzigingen. Ook de toeleveranciers van Toyota die met QFD werken rapporteren kostenverlagingen van 50% en ontwerp-, ontwikkel- en produktieverkortingen van 50%.
Het Japanse verschil In Japanse organisaties worden alle bedrijfsprocessen gestuurd door de "Voice of the Customer" terwijl in Amerikaanse en West-Europese organisaties de stem van de ontwerper of de ingenieur bepalend is. Dit leidt ertoe dat Amerikaanse en West-Europese organisaties meer inspanning moeten besteden aan het wegnemen van produktkarakteristieken welke de klant niet wil. Ofwel: Japanse organisatie besteden meer aandacht aan het ontwerp terwijl Amerikaanse en West-Europese organisaties meer aandacht besteden aan het oplossen van problemen. Voordelen Organisaties die bereid zijn de opleiding en de implementatie van een nieuwe methode te ondernemen, behalen de volgende voordelen: • produktdoelstellingen gebaseerd op de eisen en wensen van de gebruiker worden in volgende ontwikkelings- en realisatiefasen niet anders geinterpreteerd. • belangrijke ontwikkelings- en realisatiebesturingspunten worden niet vergeten. Alles om te komen tot het gewenste produkt is aanwezig en werkzaam. • efficientieverbeteringen omdat wijzigingen beperkt blijven. Nadelen Er zijn ook nadelen: • QFD vereist meer werk in de eerdere fasen van een project, • QFD bemoeilijkt het wijzigen van de richting van het project omdat alle gerelateerde elementen betrokken moeten worden bij een wijziging, • QFD eist extra registratie en documentatie.
De software situatie In Japan zijn grote bedrijven in het midden van de jaren 80 begonnen met het toepassen van QFD in software projecten. Buiten Japan is QFD in 1988 voor het eerst in software projecten toegepast in de Amerikaanse bedrijven AT&T, Bell Laboratories, Hewlett-Packard en Texas Instruments. De resultaten zijn veelbelovend. In het vervolg zal Software QFD (SQFD) gebruikt worden wanneer deze toepassing van QFD bedoeld wordt. De huidige situatie Software ontwikkeling staat meer dan ooit ter discussie. Projecten overschrijden planning en budget, terwijl de kwaliteit marginaal is. Een gevolg van deze marginale kwaliteit is dat méér dan de helft van het automatiseringsbudget moet worden besteed aan onderhoud. Wat zijn hiervan de oorzaken? De
belangrijkste oorzaak is dat traditionele softwareontwikkeling te onsamenhangend en te kennisverspillend is om goede software te produceren. Kennisverlies Door het ontwikkelingstraject op te delen in fasen zijn "fasespecialisten" ontstaan die volkomen afhankelijk zijn geworden van de informatie van de fasespecialisten van de vorige fase(n). Bij iedere informatieoverdracht gaat echter informatie verloren en wordt informatie verminkt. In de vele gesprekken met de gebruikers hebben de informatie-analisten schriftelijke en mondelinge informatie, maar ook nonverbale informatie te verwerken gekregen. Van die informatie wordt maar een deel aan de volgende fasespecialist overgedragen. Deze vult de ontbrekende kennis aan met zijn eigen ideeen over het onderwerp. Het gevolg is dat niet het juiste systeem gebouwd wordt. Aansluiting In geen enkele fase worden de faseuitwerkingen expliciet gerelateerd aan de oorspronkelijke eisen en wensen van de gebruiker. Wel worden de mijlpaalprodukten aan de gebruiker aangeboden en doorgesproken. Maar door de in omvang sterk toegenomen specificaties wordt niet snel duidelijk wat de gebruiker nu eigenlijk belangrijk vond. "Morgenochtend om 9 uur vindt een totale zonsverduistering plaats. Iets dat je niet dagelijks te zien krijgt. Wil je de mensen daarom op het voorplein laten aantreden? Bij het kijken naar dit zeldzame verschijnsel zal ik persoonlijk de toelichting geven. Mocht het regenen, dan kunnen we het niet zien. In dat geval verzamelen we in de kantine".
Deze manier van werken leidt tot versluiering van de gebruikers eisen en wensen en kan nooit tot een systeem leiden zoals de gebruiker dat ooit bedoeld had.
"Op verzoek van de pelotonscommandant is er morgenochtend om 9 uur een zonsverduister¡ing. Als het regent kunnen we dat op het voorplein niet goed zien. In dat geval heeft het verschijnsel in de kantine plaats. Dus iets dat je niet dagelijks te zien krijgt".
Kwaliteitssystemen Niet alleen de ontwikkelingsmethode maar ook de traditionele kwaliteitssystemen zijn oorzaken van de " Op verzoek van de direkteur wordt morgen het verdwijnen van de zon non-kwaliteit van systemen. Bij de in de kantine vertoond. De directeur maakt uit of het moet regenen. Dus traditionele kwaliteitssystemen worden iets dat je niet dagelijks te zien krijgt". alle inspanningen om de kwaliteit van "Als het morgen in de kantine regent, wat je niet dagelijks te zien krijgt, software te verhogen gericht op het verdwijnt de directeur in de zon". minimaliseren van het ongenoegen van gebruikers van die software. De nadruk "Morgen om 9 uur verdwijnt de directeur in de zon. Jammer dat je dat ligt op het geconcentreerd zoeken naar niet dagelijks te zien krijgt". en verminderen van defecten door reviews, inspecties, walkthroughs en testen. In het gunstigste geval is het mogelijk alle defecten te vinden en op te lossen. Moderne kwaliteitssystemen beginnen daar waar traditionele ophouden. Moderne kwaliteitssystemen maken duidelijk dat het ontbreken van fouten nog geen kwaliteitsprodukt maakt. Naast het minimaliseren van defecten, is het toevoegen van extra waarden een doelstelling. De afwezigheid van fouten betekent nog niet dat voldaan wordt aan de eisen en wensen zoals de gebruiker deze ziet. Software is pas goed wanneer het ondubbelzinnig alle uitgesproken en onuitgesproken eisen en wensen vervult. Eisen en wensen Om de gebruikers maatwerk te kunnen leveren moeten de volgende eisen en wensen onderscheiden worden: Normal requirements zijn eisen en wensen welke verkregen worden met traditionele interviews. Deze eisen en wensen leiden tot tevredenheid bij realisatie ervan in de software en ontevredenheid bij afwezigheid. Goede analisten/interviewers krijgen 70 tot hooguit 80% van deze eisen en wensen boven water. Expected requirements zijn zo vanzelfsprekend dat gebruikers ze gewoon vergeten te vermelden, totdat blijkt dat ze in de software ontbreken. Aanwezigheid in het systeem vervult de verwachting, maar leidt niet tot tevredenheid. Afwezigheid is erg onbevredigend en fataal. Gebruikers kunnen zich
vaak niet voorstellen dat het mogelijk is software te leveren zonder deze requirements. Verwachte behoeften moeten vervuld worden. Exciting behoeften zijn moeilijk te bepalen. Ze worden niet verwacht of vallen buiten het voorstellingsvermogen van de gebruiker, maar zijn bij aanwezigheid hoogst bevredigend. Afwezigheid leidt niet tot ontevredenheid, omdat ze niet verwacht werden. Gebruikers hebben al de grootste moeite met het formuleren van hun verwachtingen (normale behoeften), laat staan met de overige. Het is de verantwoordelijkheid van de analist problemen en winstkansen van de gebruikers te exploreren en daaruit een complete set specificaties te destilleren.
De problemen met specificaties James Martin vat het in zijn “A Systems Manifesto” kernachtig samen: "When the traditional systems analyst and potential end users first come face to face, they come from widely different cultures .."
Organisaties hebben behoefte aan samenhangende benaderingen en tools die de stem van de gebruikers vanaf het begin tot aan het eind laten doorklinken. Alleen zo ontstaan geen misverstanden over het op te leveren eindprodukt. Het ontwikkelingsproces dient daarom te beschikken over een kwaliteitsinstrument, dat • waarborgt dat wat waardevol is voor de gebruiker ook gespecificeerd wordt • en vervolgens de specificaties door het hele ontwikkelproces in tact laat. Dit bepaalt de kern van SQFD. Begrippen Er zijn zes belangrijke begrippen bij SQFD te onderkennen: SQFD is een methode die het geluid van de gebruiker vanaf de eerste fase identificeert en, zonder vervorming, door het hele ontwikkelproces laat doorklinken. De methode zorgt er voor dat de eisen en wensen van de gebruiker vertaald worden naar de juiste technische eisen voor iedere fase van het ontwikkelings- of realisatietraject. Het concept bestaat uit "product quality deployment" en "deployment of the quality function" welke hieronder worden besproken. De "Voice of the Customer" waarmee de eisen en wensen van de gebruiker worden bedoeld zoals de gebruiker ze geformuleerd en benoemd heeft. Counterpart Characteristics waarmee de technische vertaling van de eisen en wensen van de gebruiker wordt bedoeld. Counterpart charactersistics zijn belangrijke kritische produktbeheersingskarateristieken. Product Quality Deployment zijn activiteiten nodig om de "Voice of the Customer" te vertalen in "Counterpart Characteristics". Deployment of the Quality Function zijn activiteiten om te waarborgen dat de eisen en wensen van de gebruiker worden bereikt; ookwel het beleggen van kwaliteitstaken en -verantwoordelijkheden bij afdelingen, groepen of personen. Quality Tables waarmee matrices worden bedoeld welke de vertaling van de eisen en -wensen van de gebruiker in produkteigenschappen en -kenmerken vastleggen.
De gebruikte documenten Centraal bij SQFD staan de volgende documenten: • Planning Matrix waarin de eisen en wensen van de gebruiker uitgezet worden tegen de produktkenmerken en -eigenschappen, • Deployment Matrix welke de produktkenmerken en -eigenschappen relateert aan kritische onderdelen,
• •
Process Plan and Quality Control Chart waarin kritische proces- en produktparameters bepaald worden, Operating Instructions om er voor te zorgen dat belangrijke parameters worden gehaald.
De technieken Hierarchische diagrammen, besluitvormingstechnieken en matrices dienen als communicatietools om functionele kenmerken, potentiele probleemgebieden, kosten en overige eisen en wensen te identificeren, en op de juiste wijze aan elkaar te relateren. De werkwijze De SQFD methode genereert een stroom van informatie vanaf de eisen en wensen van de gebruiker naar de uiteindelijke programma's en operationele instructies. De volgende stappen zijn te onderkennen: Bepaal de eisen en wensen van de gebruiker in termen en begrippen uit de gebruikerswereld of zoals de gebruiker ze ziet en benoemd. Breng deze eisen en wensen van de gebruiker onder in zogenaamde customer segments. Er ontstaan geen incomplete en conflicterende specificaties. Het bepalen van prioriteiten. Deze stap is noodzakelijk om groepen gebruikers te onderkennen die conflicterende eisen en wensen hebben en/of eisen en wensen hebben met verschillende prioriteiten. Het bepalen van de specificaties per segment. Deze worden met de customer segments ondergebracht in de customer segments/customer requirements matrix. De vorige matrix wordt getransformeerd naar de technical requirement/customer requirement matrix. De customer requirements worden vertaald naar technische eisen. De volgende stappen die genomen worden zijn: technical requirements/entities and process matrix, entities and process/subsystems matrix, subsystems/detailed process matrix, detailed process/modules matrix. De te nemen stappen en matrix transformaties zijn afhankelijk van het uit te voeren project. SQFD is zo ontworpen dat de kans op incomplete en conflicterende specificaties verminderd. Elke stap resulteert in een nieuwe matrix waardoor: • nooit nieuwe specificaties kunnen ontstaan en • nooit specificaties verloren kunnen gaan. Uitvoering Voor een succesvolle invoering van SQFD kiest Quality Systems voor: • het geven van SQFD cursussen, • het uitvoeren van projecten. Uiteraard participeert u als toekomstige gebruiker van QFD bij het uitvoeren van projecten. Alleen zo worden kennis en ervaring op een snelle en directe wijze overgedragen. Samenvatting SQFD biedt de volgende voordelen: • geen initiele verwervingskosten. SQFD eist geen dure computers, case-tools, langdurige opleidingen, • verbetering van de kwaliteit, • verhoogde produktiviteit,
• •
maximale aansluiting bij de wensen van de gebruiker, kostenreductie.
Algemeen Quality Systems richt zich als onafhankelijk bureau, op de verbetering van de kwaliteit van software en op de beheersing van de bouw- en exploitatieprocessen ervan door: • audits, • Quality Engineering, • project Quality Assurance, • testen, • cursus Quality Awareness, • Software Quality Function Deployment. Maar ook: • uitvoeren van FPA's, • interactieve designtechnieken zoals FAST, • cursussen over kwaliteitsonderwerpen, • het installeren van metrics, • het voeren van projectadministraties.
