Softwarequalität

DanielBohnV3.0StandJanuar2017

Qualitätsbegriff

WasistQualität?

Qualitätsbegriff

InderNormISO8402(Qualitymanagementandqualityassurance)heißtes:„QualitätistdieGesamtheitvonMerkmaleneinerEinheitbezüglichihrerEignung, festgelegteundvorausgesetzteErfordernissezuerfüllen.“

QualitätausAnwendersicht (anwenderbezogeneAnsatz)• DasProdukt tutgenaudas,wasmanvon ihmintuitiv erwartet• DasProdukt fühltsichgutan• BeiderBenutzungstelltsichvonselbstZufriedenheit ein

QualitätausHerstellersicht:• DasProdukterwirtschaftetGewinnunderzeugtinnerbetrieblich keinenStress• hoheLebensdauerbzw.langerProduktzyklus• erzeugtbeiMehrheitderBeteiligtenamProduktionsprozess Zufriedenheitund evtl.sogar Stolz• keineodersehrgeringeAusschuss- undNachbearbeitungskosten

Qualitätskosten

Fehlerverhütungskosten:KostenderQualitätsplanung, -lenkung, -management,-auditsusw.,Tests

Fehlerkosten:durchNacharbeit,kostenloseGarantieleistung, Rückrufaktionen,Vertragsstrafen,AuftragsverlustanKonkurrenz, Imageschaden

DiegesamtenQualitätskostenbewegensicherfahrungsgemäß zwischenzehnunddreißigProzentdesUmsatzes(variabeljenachProjekt)undkönnen damitrelativschnelldenGewinnausdemProjektaufzehren.

https://entwickler.de/online/agile/softwarequalitaet-so-misst-und-verbessert-man-software-114867.html

Qualitätskosten

rule of ten

http://www.sixsigmablackbelt.de/fehlerkosten-10er-regel-zehnerregel-rule-of-ten/

VergleichBranchenBauwesen

seit4000Jahren

„BesteVorgehensweise“ausErfahrung

geprüftesPersonal(Architekt/Polier/Bauingenieur)

formaleMethoden(EntwürfeundPläne)

mittlereAufgabenformulierung

mittlereobjektiveBewertbarkeit(Wasserwaage,Laser)

Lebensmittel-Verarbeitungseit9000Jahren

„BesteVorgehensweise“ausErfahrung

geprüftesPersonal(Bäckermeister)

formaleMethoden(Rezept)

einfacheAufgabenformulierung

einfacheBewertbarkeitobjektiv(Sinnesorgane)

Softwareentwicklung

seit50Jahren

momentannochkeine„BesteVorgehensweise“

ungeprüftes Personal(abwannistmaneinProgrammierer?)

vielekonkurrierendeformaleMethoden

komplexeAufgabenformulierung

schwierigeBewertbarkeitmeistnur subjektiv

Qualität+

Mehrwert

Zufriedenheit(rationaleEbene)

Begeisterung(emotionaleEbene)

Qualität

SoftwarefehlerundFolgen

Ariane5Jungfernflug— 4.6.1996

Quelle:MathiasRiedlSeminar2012„ARIANE5AbsturzdesFlugs501“

WegeneinesÜberlaufsbeieinerZahlkonvertierung imLageregelungsmodulgerietdieeuropäischeRaketekurznachdemStartineineSchräglageundmusstegesprengtwerden.DurchdieExplosionentstandeinSchadenvon1,7MilliardenDM.Verzögerung desgesamtenRaumfahrprogrammsum3Jahre.

• Ziel:Hardware-AuslastungderSRI-Rechner(Trägheitsnavigationssystem) unter80%• AnalyseCode imSRI:GefahrvonnumerischenÜberlaufbei7Variablen• Entscheidung:

- 4VariablenwurdenimCode gegenÜberlaufgeschützt- 3VariablenwurdennichtgeschütztdaÜberlaufnichterwartet(Vertraglichfestgehalten)

• Problem:VergleichsdatenzurBeurteilungdesÜberlaufverhaltens vonArianne4• Konvertierungeines64BitGleitkommazahlineineder3ungeschützen 16BitInteger-Variablen• Wertgrößerals65535(16Bit) daraufhinfolgteeinOperandenfehler inderLageberechnung– Fehlerbit

abgesetzt- Shutdown desSRI• HauptcomputerversuchteaufBACKUP-SRIumzuschalten, daswarvorheraufgrunddesgleichesFehlers

ausgefallen

Bildquelle:http://www.thomas-zehrer.de/wp-content/uploads/2015/03/thomas-zehrer-de_sri-ocs-sensoren.jpg

OpenSSL-Heartbleed-ExploitFebruar2014

Quelle:http://www.heise.de/security/artikel/So-funktioniert-der-Heartbleed-Exploit-2168010.html

Normen,Standards,Institutionen

• Quelle:https://www.qz-online.de/qualitaets-management/qm-basics/software-qualitaet/software-testnormen/artikel/software-standards-normen-und-modelle-257987.html

ISO(InternationaleOrganisationfürNormung)162LändersindMitgliedderISO.JedesLandistmitseinemlokalenstaatlichenNormungsgremium miteinemSitzvertreten(DINfürDeutschlandseit1951)bekanntesteNorm:ISO9001

ANSI(AmericanStandardInstitute)staatlicheNormungsinstitution derUSA,repräsentiert125,000US-Firmen,vertrittalsFullBody MemberdieUSAinderISO.bekanntesteNorm:C89/C90ANSI-C

IEEE(Instituteof Electrical and ElectronicsEngineers)weltweiter nichtstaatlicherBerufsverband von IngenieurenHauptsächlichausdenBereichen Elektrotechnik und Informationstechnik430.000Mitglieder, Gründung 1962,38 Societies u.a.IEEEComputerSocietyund IEEERoboticsand AutomationSociety,bekanntesterStandardIEEE802LAN

Seit2008existierteinPSTO(partner standards development organization)zwischenISOund IEEEzurKooperationbeiderNormengebung

IEC(InternationalElectrotechnical Commission)Gründung 1906inLondon. InderIECsindmehrals70Ländervertreten,organisiert in93technischenKommissionen,80Unterkommissionen und rund700Arbeitsgruppen (Stand2008)ArbeitetzumTeilmitISOzusammen (ISO/IEC12207)

CENELEC(europäischeKomiteefürelektrotechnischeNormung)zuständig fürdieeuropäischeNormung imBereichElektrotechnikCENELEC-MitgliedersinddienationalenelektrotechnischenKomitees

ETSI(europäische InstitutfürTelekommunikationsnormen)gemeinnützige Organisation,700Mitgliederausüber60Ländern,darunterNetzbetreiber,Verwaltungen, AnwenderundHersteller

CEN(EuropäischeKomiteefürNormung)33NationalenMitglieder, dreiMitgliederderEuropäischenFreihandelsvereinigung (EFTA),alleBereicheaußerETund IT

DeutschlandDKE(DeutscheKommissionElektrotechnikElektronikInformationstechnik) imDINundVDE

EU

weltweit

nationalÖsterreich

ÖsterreichischeElektrotechnischeKomitee(ÖEK)innerhalb desOVE

EFTA

Verordnungenerlassenvonstaatl.

VerwaltungsbehördenArbStättV,BildscharbV

Zertifizierungenausgestelltvonstaatl.

zugelassenenInstitutionenzumNachweisausEinhaltung

vonNormenfürDINISO9001fürDINISO27001

NormenverbindlicheStandardsvonallg.anerkanntenint.Organisation

Prozessnormen ISO/IEC90003Produktnormen ISO/IEC9126

Standardserarbeitetvon

nichtstaatlichenGremien,Empfehlungen

IEEE,OPCFoundation

Bildschirmarbeitsverordnung(BildscharbV)

• seitDezember2016nichtmehreigenständiggültig,sondernnunTeilderArbStättV

• beziehtsichaufalleArbeitsplätze,beidenendauerhaft anBildschirmgerätengearbeitetwird(lt.stat.Bundesamt 18.5MillionenüberwiegendgenutzteBildschirmarbeitsplätzeimJahr2014)

• BedienplätzevonMaschinenoderFahrzeugenmitBildschirmenundBildschirmplätzeinnerhalbvon Verkehrsmittelnsindausgenommen

• DerArbeitgeberistauchimSinnederBildschirmarbeitsverordnungzurGefährdungsbeurteilungverpflichtet

• Ziel:VerhinderungvonGesundheitsgefärdungenamBüroarbeitsplatzdurchStrahlen,Wärme,ungünstigeBewegungenundKörperhaltung

• ErgonomieauchfürSoftwareausdrücklichgefordert• dieNormenreiheDINENISO9241Teil110enthältkonkrete

AnforderungenandieergonomischeGestaltungvonSoftware.

Quelle:http://www.arbeitsschutzgesetz.org/bildscharbv/

DINENISO9241-110GrundsätzederDialoggestaltung

Usability zudeutsch:GebrauchstauglichkeitGruppe:Software-Ergonomiemit50Empfehlungen

Quelle:https://www.tk-lex.tk.de/externalcontent?_leongshared_externalcontentid=HI672950&_leongshared_serviceId=2009

IEEE-Standards:

SQAP– SoftwareQualityAssurancePlanIEEE730SCMP– SoftwareConfigurationManagementPlanIEEE828STD– SoftwareTestDocumentation IEEE829SRS– SoftwareRequirements Specification IEEE830SVVP– SoftwareValidation&VerificationPlanIEEE1012SDD– SoftwareDesignDescriptionIEEE1016SPMP– SoftwareProjectManagementPlanIEEE1058SoftwareReviewsand AuditsIEEE1028SoftwareLifeCycleProcesses IEEE1074Systemsand SoftwareEngineering– SystemsLifeCycleProcessesIEEE15288

ProzessnormenQualitätsmanagement(-System)

ISO9000:2005Qualitymanagement systems – Fundamentals andvocabularyISO9001:2008Qualitymanagement systems – RequirementsISO9004:2009Managingfor the sustained success of anorganization– Aquality management approachISO/IEC90003:2004Softwareengineering – Guidelines for the application of ISO9001:2000 to computersoftware

Software-ProzesseundVorgehensmodelleISO/IEC12207:2008Systemsand software engineering – Softwarelife cycle processV-ModellXT,VorgehensmodellzumPlanenundDurchführenvonSystementwicklungsprojektendesBundes(Deutschland)HERMES– DieschweizerischeProjektführungsmethode,umProjektederInformations- undKommunikationstechnik(IKT)einheitlichundstrukturiertdurchzuführenIT-BVM,VorgehensmodellfürdieEntwicklungvonIT-SystemendesBundes(Österreich)

ProduktnormenUnterProduktnormen fallenStandards,dieeinheitlicheKriterienfürdieBeurteilungvonProduktqualitätzurVerfügungstellen.NachfolgendeinigeBeispielevonProduktnormen:

ISO/IEC9126InformationTechnology– SoftwareProduct Evaluation– QualityCharacteristics and Guidelines fortheir UseISO/IEC9126-1SoftwareEngineering– Product Quality– Part1:QualityModelISO/IEC25051:2006Softwareengineering – Softwareproduct QualityRequirements and Evaluation(SQuaRE)–Requirements for quality of CommercialOff-The-Shelf (COTS)software products and instructions for testing

Quelle:ErnestWallmüller, SoftwareQualityEngineering

KriterienfürdieBeurteilungderSoftwareQualitätnachISO9126

Funktionalität:SindalleimPflichtenheft gefordertenFunktionen vorhandenundausführbar?

Zuverlässigkeit:ZuwelchemGrad(z.B.ProzentderArbeitszeit)erfülltdieSoftwaredauerhaftdiegefordertenFunktionen? Werden alleFunktionen richtigausgeführt(Korrektheit)?

Benutzbarkeit:Wieschnell lässtsichderUmgangmitderSoftwarevomBenutzererlernen(Erlernbarkeit)?WieeinfachlässtsichdieSoftwaredurchdenBenutzerhandhaben(Bedienbarkeit)?

Effizienz:Welches zeitlicheVerhalten(AntwortzeitimDialogbetrieb,LaufzeitimStapelbetrieb)undwelchenRessourcenverbrauchzeigtdieSoftwareunterdengegebenenSystemvoraussetzungen(Hardware,Betriebssystem,Kommunikationseinrichtungen)?

Wartbarkeit:MitwelchemAufwandbzw.InwelcherZeitlassen sichÄnderungendurchführen!WielässtsichderAufwand fürFehlererkennungundBehebungminimieren ?

Portabiliät:MitwelchemAufwandläßt sichdieSoftware(insbesondere Standardsoftware)anindividuellefunktionale betrieblicheGegebenheitenanpassen(Anpaßbarkeit)? Läßt sichdieSoftwareohne größerenAufwandinanderenSystemumbegungen zumEinsatzbringen(Portabilität)?KanndieSoftwarebeimAustauschdesRechners(z.B.leistungsfähiger Prozessor)unveränderteingesetztwerden(Skalierbarkeit,Aufwärtskompatibilität)

IEEE- undISO-StandardszurMessungderSoftwarequalität

GemäßIEEE-Standard610gibtesfolgendeDefinitionenzurMessungderSoftwarequalität:

1.SoftwarequalitätistderGrad,indemdasSystemdiegestelltenAnforderungenerfüllt.

2.SoftwarequalitätistderGrad,zudemeinSoftwaresystemdieBedürfnisseundErwartungenderBenutzererfüllt(IEEE99).

ISO/IEC25000Dieinternationale Norm ISO/IEC25000 Softwareengineering – Softwareproduct QualityRequirements and Evaluation(SQuaRE)– Guideto SQuaRE ersetztseit2005dieNorm ISO/IEC9126 undwurdevondemNormungsgremium ISO/IEC JTC1/SC07 Software-and SystemsEngineering erstellt.DiedeutscheVersionDINISO/IEC25000 Software-Engineering–QualitätskriterienundBewertungvonSoftwareprodukten(SQuaRE)– LeitfadenfürSQuaRE wirdseit2010durchden NA043Normenausschuss InformationstechnikundAnwendungen (NIA)des DeutschenInstituts fürNormung vorbereitet.

Quelle:http://de.wikipedia.org/wiki/ISO/IEC_25000

weitereNormen

• IEC61511:FunktionaleSicherheit.Sicherheitstechnische SystemefürdieProzessindustrie.Teil1:Allgemeines,Begriffe,AnforderungenanSysteme,SoftwareundHardware.

• IEC62061:SicherheitvonMaschinen.FunktionaleSicherheit sicherheitsbezogener elektrischer,elektronischer undprogrammierbarerelektronischer Steuerungssysteme.

• IEC60601:Medizinischeelektrische Geräte.Allgemeine FestlegungenfürdieSicherheit.

• EN60601-1-4:Medizinischeelektrische Geräte.Teil1-4:Allgemeine FestlegungenfürdieSicherheit; Ergänzungsnorm:Programmierbareelektrische medizinischeSysteme.

• DINEN62304:Medizingeräte-Software.Software-Lebenszyklus-Prozesse

• IEC61508 :Entwicklungsicherheitskritischer, programmierbarer elektronischer Systeme

• FDIS26262:RoadVehicles.Functional Safety (löstdieIEC61508fürdieAutomobilindustrieab).

ZertifizierungenBeispiel:ISO/IEC27001:2013Anforderungen fürHerstellung,Einführung,Betrieb,Überwachung,WartungundVerbesserung einesdokumentiertenInformations-Sicherheits-Managementsystems(ISMS)

Zielgruppen:Rechenzentren,Verwaltung, Banken,TK-Anbieter, Energieversorger (VorschriftvonBNetzA)

Auditor:GeprüfteZertifizierungsstelle z.B.TÜVExterneBeraterfürKMU

Fazit:dieNormfürdentäglichen

Programmieralltagist

ISO/IEC25010:2011(vormalsISO/IEC9126)

QualitäterzeugenAusbildungErfahrung

FesterAblauf(Workflow)ToolsZeit

Machbarkeit

QualitätsimulierenSchnell–Viel-MachenWochenendarbeitKamikaze-Aktionen

egalwie

GelassenheitSpaß

Professionalität

KostenStress

Unzufriendheit

SoftwarelebenszyklusmanagementNormISO/IEC12207

Quelle:http://gustavorusso.com/blog/2008/07/15/happiness-in-software-development-lifecycle.html

Software-Entwurfsphase

UMLPAP

Merksätze:

Softwareisnotforitscreators,itisforitsusers.

Softwarewird 1malgeschrieben undn+1malgelesen.

quantitativenBewertungvonSoftwarequalitäta)direkteMessgrößen- Zuverlässigkeit:Ausfallzeiten- Korrektheit:AnzahlFehlerproZeiteinheit- Bedienbarkeit:AnzahlAufrufeproVorgang,AnzahlKlicks oderTouches- Effizienz:Antwortzeit(Durchschnitt, Spitze)proTransaktion- Wertbarkeit:ZeitaufwandjeFehlerbehebung

b)indirekteMessgrößen- Programmgröße:AnzahlProgrammzeilen(LOC=Lineof Code)- Programmstruktur:AnzahlHierachieebenen (Schachtelungstiefe), AnzahlStrukturblöcke,AnzahlModule- Programmkomplexität:Anzahlunterschiedlicher Steuerkonstrukte- Kommentarumfang:AnzahlKommentarzeilenabsolutundrelativimVerhältnis zurAnzahl

Programmzeilen

WerführtQuantitativeBewertungderSoftwaredurch?- Projektverantwortlichesind keineSoftwareexperten?- keine„BesteBeweismethodik“ fürFehlfunktionen

Lösung: Pair-Programming Code-Reviews Tests

VerfügbarkeiteinesSystems

DazuwerdendieverfügbarenZeitendenAusfallzeitengegenübergestellt.BeispielsweisewirdbeiServersystemenofteineVerfügbarkeitvon0,99vereinbart.FälltdasSysteminnerhalbeinesTestzeitraumsvon24Stundenauchnur0,5Stundenaus,soistdieBedingungverletzt(23,5/24=0,979<0,99).

Pair-Programming

MicrosofthatfürWindows7bestimmteTechnikendesExtremeProgrammingangewandt,u.a.wohlauchPairProgramming.Von

http://de.wikipedia.org/wiki/Paarprogrammierung"Paarprogrammierungbedeutet,dassbeiderErstellungdesQuellcodesjeweilszweiProgrammiereraneinemRechnerarbeiten.EinProgrammiererschreibtdenCode,währendderandereüberdieProblemstellungennachdenkt,dengeschriebenenCodekontrolliertsowieProbleme,dieihmdabeiauffallen,sofortanspricht.Diesekönnendannsofort(imGesprächzuzweit)gelöstwerden.DiebeidenProgrammierersolltensichbezüglichdieserbeidenRollenabwechseln.AuchdieZusammensetzungderPaaresolltesichhäufigändern."

CodeReviewNachIEEStd610(„Glosssary of SoftwareEngineeringTerminolgy“):

EinReviewisteinmehroderwenigerformalgeplanterundstrukturierterAnalyse- undBewertungsprozess,indemProduktergebnisseeinemTeamvonGutachternpräsentiertundvondiesenkommentiertundgenehmigtwerden.

Vorteil:unmittelbareQualitätsverbesserung,FeedbackanNeu-Programmierer

Nachteil:ZusatzbelastungderLeistungsträgerimTeam

Reviewer könnennurungefähr100CodezeilenproStundeanalysieren, sodassschon fürdieÜberprüfung einermittelgroßenAnwendungmit20.000Zeilenrund200Stundenbenötigtwerden,unddasohneDokumentation, Korrekturetc.DahergehtderTrendstarkzuTool-gestützten,formalisiertenReviews,diesichwiederholtaufgroßeCodemengen anwendenlassen.

Quelle:Computerwoche"Zehn Tippsfürden CodeReview"15.02.2013vonDr.BruceSams

Eye-Tracking

FürunerfahreneEntwicklerbietetderCodereviewdurcheinenerfahrenenProgrammiereridealeMöglichkeiten,sichschnell undpraxisorientiertweiterzubilden– AufstieginhöheresLevelalsMotivation.

LevelAEntwickler(Entwickler):• arbeitetnichtamProjekt• führReviewsfürLEVELBundCdurch• hatVollzugriffaufalleSoftwareobjekte– istVerwalterderCODEBASISdesUnternehmens• genehmigtoderverwirftbeantragteÄnderungenanModulen/Objekten• programmiertprojekt-übergreifendeFunktionen undObjekte- machtdieArchitektur

Projektleiter:• beauftragtReviews• achtetaufdieDisziplinimTeam(muss Sanktionsmöglichkeiten haben)

LevelB-Programmierer(Programmierer):• arbeitetamProjekt• darfReviewsfürLEVELCdurchführen,wirdselbst vonLEVEL–Areviewed• programmiertdieÄnderungen anModulen/Objekten imAuftragvomLEVELA- Entwickler• schreibt„schnelle“-Lösungen fürsichundLevel-C-Programmierer• die„schnellen Lösungen“werdennurnachReviewindieCODEBASISzurückgepflegt

LevelC-Programmierer(Inbetriebnehmer):• arbeitetamProjekt• verschaltetfertigeModule- machtdieLogikundParametrierung• wirdnurhinundwiederreviewed – hierAblauftestalsFeedback• beantragtÄnderungenanModulen/Objekten beimLevel-B-Programmierer• seineeigenenModulewerdenniemalsindieCODEBASISzurückgepflegt(Wildwuchs)

Refactoring

• DurchdasRefactoringwirdalsoeinebestehendeSoftwaregenerelloderauchinTeilenlesbarer, inihrenStrukturenverständlicher,bessermodifizierbar,bessertestbar undeswerdenRedundanzenvermieden.

VerbesserungdesCodesohneÄnderungdesVerhaltens.

KleineSchritteWartungvonCode

Bildquelle: Refactoring undEntwurfsmuster Franz-JosefElmer, Universitat Basel,HS2012

Refactoring• Gruppen:

- dieUnzufriedenen: LevelC-ProgrammiereralsAnwenderimUnternehmen- besterIndikator- derStolze: Level-A-Entwickler/Codeverwalter stolzauf„seinem“Code- derSparsame: Chef„Gehtdoch- warumnochmalAufwandinvestieren - keineZeit?“

• Problem:werentscheidet,dasesjetzt ZeitistfüreinRefactoring?

• Meisterst,wenndieFehlerkosten schonzuhochsind undderDrucknichtmehrnurvoninnesondern vonaußen(Kunde )kommtdannhabensichschon vieleRefactoring-SchritteangesammeltundwenigZeitzumTesten!

• Irgendwann:AchkommwirmachenAllesneu……!?

• Refactoring VorschlägeundUnterstützunginVisualStudio undEclipse

Bildquelle: https://www.it-agile.de/wissen/agiles-engineering/refactoring/

OftgenannteVorteilederOO-Programmierung:• für Designer:derEntwurfsprozeß wirdeinfacher,klarerund

handhabbarer.• für Programmierer:klaresObjektmodell,mächtige

Programmierwerkzeuge,nützlicheBibliotheken.• fürManager:EntwicklungundWartungvonSoftwarewird

schnellerundbilligerdurchgesteigerteProduktivität.

Allerdings:• OOPmussmanlernen.• umsoschwererjetieferdie,,prozeduralenWurzeln``sind• GutesDesignfürObjekteistnichtleicht.

Quelle:http://ag-kastens.uni-paderborn.de/lehre/material/java_vorlesung/folien/java_img4

OOP-AnsätzefürnichtOOP-SystemeProblem:keineMethodenanDatentypenbindbar (keineKapselung)

Ansatz:OOP-ähnlicheAbstraktionfürDatenbehälter(z.B.Job,Teil,Platz)DatenbehälteralskomplexerDatentype(Structs)Reduzierung globalerVariablenundFunktionen Aufrufhirarchien undAufruftiefemaximal3Instanzierung nutzenfallsvorhandengrafischeProgrammierung zumindest inderAufrufebene nutzen

Beckhoff TWINCAT:ABB-RAPID:

Tests

DerMarktfürSoftwareQualitäthatinzwischennur imBereichdesSoftwareTestenseinVolumenweltweitvon33,4Mrd USD(NelsonHall2012)

TestDriven DevelopmentklassischerVorgehensweise:ErstProgrammieren,dannAllestesten

testgetriebenenEntwicklung- UNITTests:SchreibeTestsfürdaserwünschtefehlerfreieVerhalten, fürschonbekannteFehlschlägeoderfürdasnächsteTeilstückanFunktionalität,dasneuimplementiertwerdensoll.DANACH!!!!Ändere/schreibedenProgrammcodemitmöglichstwenigAufwand, bisnachdemanschließendangestoßenenTestdurchlaufalleTestsbestandenwerden.Räumedann imCodeauf:EntferneWiederholungen, abstrahierewonötig,richteihnnachdenverbindlichen Code-Konventionen ausetc.NatürlichwiedermitabschließendemTesten.ZieldesAufräumens istes,denCode schlicht und verständlich zumachen.

Quelle:http://de.wikipedia.org/wiki/Testgetriebene_Entwicklung

WeiterbildungenSitzinPotsdam,gegründet,Anfänge1996

iSQI ®AgileEssentials|ISTQB®CertifiedTester|IREB®CertifiedProfessionalfor Requirements Engineering|iSQI®CertifiedProfessionalforModelBased Testing |iSQI®CertifiedProfessionalfor ProjectManagement|iSQI®CertifiedModelBased Tester |usw.

https://www.isqi.org/

ASQF– Kompetenznetzwerkmitüber1.200MitgliedernDerArbeitskreisSoftware-Qualitätund -Fortbildung e.V.(ASQF) istdasKompetenznetzwerk fürSoftware-Qualitätimgesamtendeutsch-sprachigenRaum.

https://www.asqf.de/

DiverseFachgruppen, VeranstaltungenundPublikationen

SpezielleProblemederAutomatisierungstechnik

• SoftwarenureinTeildesGesamtprojektesdaherkeinSoftwareprojektmanagement

• FührungspersonalnichtausgebildetinSoftwaretechnologie• keineformuliertenQualitätsvorgabenfürdieSoftware• unvollständigeAufgabenbeschreibung(Requirements)• seltenTeamstrukturen-wenndannohneHierarchien• selteninterdisziplinärenTeams• internerWissenstransferunzureichend• seltenWissenstransfervonextern• KeineCode-Reviews,keineCode-Tests• ToolsinATnochunzureichend