ISO/IEC 15504-9 veröffentlicht

ISO/IEC TS 15504-9:2011 Information technology — Process assessment — Part 9: Target process profiles

Teil 9 der ISO/IEC 15504 Norm enthält Richtlinien für Sponsoren von Assessments und Prozessverbesserungsinitiativen und andere Nutzer der Norm, um Zielprozessprofile zu erstellen und zu verwenden.

Mit diesem Teil der Norm erfüllt die Arbeitsgruppe der JTC 1/SC 7 einen schon lange gehegten Wunsch vieler Anwender, die eine Vergleichbarkeit von Organisationseinheiten untereinander ähnlich zu CMMI benötigen.

Inhalt

Ein Zielprozessprofil enthält die Bewertungen für Prozessattribute und Fähigkeitsgrade (Capability Levels) zusammen mit den Begründungen für diese Bewertungen. Diese werden von oder im Auftrag einer Organisation genutzt, um

  •  mit dem Zielprozessprofil einen definierten Zweck zu erreichen,
  • in einem Assessment festzustellen, in wie weit eine Organisation ihr Zielprozessprofil aktuell schon erreicht,
  • in einem Assessment festzustellen, in wie weit eine andere Organisation dieses Zielprozessprofil aktuell erreicht und
  • in einer Schwachstellenanalyse die notwendigen Verbesserungsmaßnahmen festzustellen.

Die ISO/IEC 15504-9 definiert das Vorgehen zur Erstellung des Zielprozessprofiles und führt aus, wie

  • der beabsichtigte Nutzen definiert wird,
  • die Beziehungen zu den Referenz- und Assessmentmodellen aussieht,
  • welche Informationen notwendig sind,
  • wie die entsprechenden Faktoren defniert und genutzt werden,
  • welche Analysen notwendig sind,
  • auf welche Art und Weise die Ergebnisse ausgedrückt werden sollen, damit die Begründungen für Bewertungen klar beschrieben sind und
  • wie diese Ergebnisse genutzt werden.

Definition des Zielprozessprofils

Zur Definition sieht die Norm folgende 10 Schritte vor:

  • Zweck definieren
  • Anwenderkreis festlegen
  • Geschäftsziele definieren
  • Anwendungsdomäne definieren
  • Charakterisierung definieren (abhängig von der Anwendungsdomäne z.B. Kriterien zur Funktionalen Sicherheit oder bezüglich GAMP und/oder bestimmter Qualitätsanforderungen, zeitlicher Einschränkungen etc.)
  • Faktoren für Zielprozessprofil definieren (auf Basis einer Risikoanalyse bezogen auf die Charakterisierung)
  • Kriterien zur Sammlung der Daten und Informationen definieren
  • Prozesse auswählen (und u.a. die Auswahl begründen und dokumentieren)
  • Ergebnisse des Zielprozessprofils definieren (d.h. was genau als Ergebnis dokumentiert werden muss, wovon die Norm bereits sehr viel vorgibt)
  • Fähigkeitslevel für Zielprozesse definieren

Vor allem bei der Definition des Zielprozessprofils verlangt die Norm ein sorgfältiges Arbeiten, um eine hohe Qualität der Ergebnisse zu erreichen. Dazu gehören dann u.a. eine genaue Berücksichtigung der definierten Charakterisitika und Faktoren, eine sorgfältige Analyse und eine dokumentierte nachvollziehbare Begründung für die Bewertung von Prozessattributen und Fähigkeitsleveln wie auch mehrere Reviewschritte mit jeweils unterschiedlichem Fokus.

Anwendung des Zielprozessprofils

Zur Anwendung der Zielprozessprofile sagt die Norm deutlich weniger aus. Sie verlangt letztlich nur, dass das entstandene Zielprozessprofil tatsächlich anwendbar ist, indem es z.B. verständlich niedergeschrieben wurde und alle notwendigen Informationen enthält und verweist ansonsten bei der Anwendung für Schwachstellenanalysen auf ISO/IEC 15504-4:2004, Annex A.

Konsequenzen von Schwachstellen

Die Tabelle 1 im Anhang A listet für die jeweiligen Fähigkeitsgrade die Risiken auf, welche die gefundenen Schwachstellen in sich bergen und gibt sehr knapp Hinweise zur Interpretation der Prozessergebnisse.

Fazit

Obwohl sich die Norm vorwiegend an die Sponsoren von Assessments richtet, die die Definition der Zielprozessprofile durchführen sollen, wird diese Aufgabe in der Praxis oft delegiert an die Leitung von Prozessverbesserungsinitiativen oder häufiger noch an externe Consultants. Zu hoffen ist dann, dass diese die Sponsoren intensiv an den zu erledigenden Aufgaben beteiligen, ob mit Hilfe von Workshops und/oder “Hausaufgaben”. Insofern kann die Norm dazu beitragen, dass diese Arbeiten ein Mindestmaß an Qualität erfüllen.

Eine leichtere Vergleichbarkeit der Ergebnisse über unterschiedliche Organisationseinheiten und über eine Organisationseinheit, über unterschiedliche Projekte oder unterschiedliche Zeitpunkte der Assessments ist, ist durch die Anwendung der Norm nicht gesichert, aber hoffentlich besser möglich.

Der Anhang A mit den Konsequenzen von Schwachstellen ist für das notwendige Marketing von Prozessverbesserungsinitiativen bei den Sponsoren sicher ganz hilfreich.  Mir fehlt aber wenigstens ein Beispiel zur Anwendung, an dem sich die Anwender der ISO/IEC 15504-9 orientieren könnten – mit der bloßen Umschreibung bleibt der Normentext leider etwas zu theoretisch.

Veröffentlicht unter Für Sie gelesen, Prozessverbesserung | Verschlagwortet mit , , , , , , , , , , , | Hinterlasse einen Kommentar

Scrum Guide 2011 veröffentlicht

Die neue Version des Scrum-Regelwerks “Scrum Guide” wurde kürzlich durch die Scrum-Begründer Ken Schwaber und Jeff Sutherland veröffentlicht und kann in englischer Sprache als PDF unter www.scrum.org heruntergeladen werden. Hier findet sich auch eine Liste der wichtigsten Änderungen des agilen Vorgehensmodells im Vergleich zur Vorversion. Die neue Version will in erster Linie eine eindeutigere Definition von Srum schaffen, sprachliche Verbesserungen einbringen und damit Missverständnisse klären. Beispiele, Tipps und Tricks wurden entfernt und der inhaltliche Schwerpunkt auf das Regelwerk gelegt.

Srum wurde nicht fundamental geändert, aber einige Klärungen wurden vorgenommen. Die wichtigsten Änderungen der neuen Version “Scrum Guide 2011″:

  • Der Begriff Team wurde durch Developement-Team ersetzt.
    → Hiermit wird eine eindeutigere Abgrenzung zum Scrum-Team vollzogen, welches das gesamte Team einschließlich Scrum Master, Product Owner und Entwickler einschließt.
  • Developement-Teams geben während der Sprint-Planung kein Committment, sondern führen einen Forecast durch.
    → Entwicklerteams sichern also nicht zu, was genau durch das Team umgesetzt wird. Stattdessen wird eine Prognose abgegeben, was während eines Sprints umgesetzt werden kann. Diese Prognose kann sich im Verlauf des Sprints durch Hinzukommen weiterer Informationen bzw. mit wachsendem Wissen verändern. Das Vorgehen wird flexibler.
  • Burndown-Charts sind nicht verpflichtend, um den Fortschritt zu messen.
    → Um den zu erbringenden Restaufwand pro Sprint täglich zu erfassen, ist es nicht notwendig Burndown-Charts zu verwenden. Es ist ausreichend, wenn die verbleibende Restarbeit im Sprint aufsummiert wird und ein Trend hinsichtlich des Sprintendes dargestellt werden kann.
  • Release-Planung ist nicht verpflichtend.
    → Srum sieht eine Release-Planung zwar als nützlich an, diese ist aber optional.
  • Es gibt kein Konzept der Sprint Backlog Items mehr.
    → Ein Sprint Backlog besteht aus Items des Product Backlogs für den Sprint und einem Plan wie diese  geliefert werden. Separate Sprint Backlog Items sind nicht notwendig. Ein selbstorganisiertes Developement-Team sollte immer einen Plan haben.
  • Die Priorisierung der Items im Product Backlog entfällt.
    → Items werden zukünftignicht mehr priorisiert, sondern geordnet (ordered). Dies soll den Product Owner ermöglichen, flexibler zu handeln und sich besser auf ändernde Rahmenbedingungen zu reagieren.

Wie sehen Sie die Veränderungen? Unterstützt der Scrum Guide 2011 eine klarere Vorgehensweise und trägt er zu einer Verbesserung des Scrum-Vorgehens bei oder führt beispielsweise das fehlende Committment des Developement-Teams zu einem Verlust an Verbindlichkeit und somit zu schlechteren Ergebnissen?

Veröffentlicht unter Für Sie gelesen, Softwareentwicklung, System- und Softwareengineering, Zum Weiterlesen | Verschlagwortet mit , , | Hinterlasse einen Kommentar

Aktualisierung So können Sie TPI für sich anwenden

So können Sie TPI für sich anwenden – Artikel aktualisiert

Seit einigen Wochen ist die deutsche Version des Buches zu TPI NEXT im dpunkt-Verlag erschienen. Anlass für mich, die eigenen Übersetzungen aus dem Englischen durch die Original-Zitate aus dem deutschen Buch zu ersetzen.

Übersicht der Artikel

In Teil 1 geht es um ein paar Grundlagen zum Aufbau des Modells und in Teil 2 um die Definition des Soll-Zustandes. Teil 3.1 stellt die verschiedenen Assessment-Typen und die Auswahl der Assessoren sowie den Ablauf der Assessments vor; Teil 3.2 die detaillierte Analyse des IST-Zustandes, also v.a. um die Phase “Performing” am Beispiel eines TPI Light-Assessments und eines Self-Assessments.
In Teil 4 geht es um die Auswertung der Assessmentergebnisse und die Initiierung der Verbesserungen.

Veröffentlicht unter Für Sie gelesen, Prozessverbesserung, Testen | Verschlagwortet mit , , , , | Hinterlasse einen Kommentar

Die einflussreichsten Leute im Bereich des Testens

Software Testing Club auf LinkedIn

Auf LinkedIn gibt es schon seit längerem den Software Testing Club
in dem in englisch mittlerweile fast 7000 Mitglieder aus der ganzen Welt recht aktiv diskutieren.

Diskussion: “Einflussreiche Leute im Testen”

Eine der aktuellen Diskussionen initiiert von Martin Mudge beschäftigt sich mit dem Thema Who are the most influential people in software testing around the world

Die Diskutierenden haben dazu folgende Liste laut Martin Mudge zusammengestellt. Kommentare von mir sind in [] dargestellt, nachträgliche Ergänzungen der anderen Diskutierenden in ().

  • Michael Bolton
  • James Bach
  • Cam Carner [should most probably be Kem Caner]
  • Dorthy Graham [should be Dorothy Graham]
  • Eric Jacobson
  • Rex Black
  • James Lyndsey
  • James Whittaker
  • Lisa Crispin
  • Scott Barber
  • Gerald M Weinberg
  • Geoff Thompson
  • Yaron Tsubery
  • Adam Goucher
  • Alan Page
  • Marlena Crompton
  • David Burns
  • Gojko Adzic
  • Markus Gärtner
  • Michael Larsen
  • Eric Jacobson’s
  • Matt Heusser
  • Pradeep Soundarajan
  • Ross Collard
  • Scott Barber [duplicate - should be deleted]
  • Julian Harty
  • Mike Kelly
  • Karen Johnson
  • Antony Marcano
  • Dr. Prakash Mutalik
  • Ed Kit
  • Lanette Creamer
  • Dawn Canaan
  • Hans Buwalda
  • Gerry Weinber [duplicate - probablay Gerald Weinberg]
  • Boris Beizer
  • Lee Copeland
  • Erik Boelen
  • Dominic Maes
  • Mieke Gevers
  • Erik van Veenendal
  • Janet Gregory
  • (Ashok)
  • (Rikard Edgren)
  • (Henrik Emilsson)
  • (Jonathan Kohl)
  • (Henrik Andersson)
  • (Johan Jonasson)
  • (Stuart Reid)
  • (Isabel Evans)
  • (Paul Gerrard)
  • (William E. Perry)
  • (BJ Rollison)
  • (Elisabeth Hendrickson)
  • (Elfriede Dustin)
  • (Pradeep Soundararajan)
  • (Doron Reuveni)
  • (Tom Lounibos)
  • (Jason Huggins)
  • (Joe Strazzere)

Was mir in der Liste fehlt

Und diesen Beitrag habe ich ergänzt:

Ich vermisse tatsächlich ein paar wichtige Leute.
Einer der einflussreichsten ist:
Glenford J. Myers, der “The ART of SOFTWARE TESTING” veröffentlichte, als (soweit ich weiß) noch kein anderes Buch zu diesem Thema verfügbar war.

Ilene Burnstein, die die Fundamente von TMM (Testing Maturity Model) gründete und ähnlich Martin Pol / Tim Koomen für TPI (Test Process Improvement).

Nicht zuletzt auch Kent Beck für den “Test-First-Ansatz” und das “Test-Driven Development”.

Zumindest in Deutschland hat Peter Liggesmeyer Wissenschaft und Industrie beeinflusst bezüglich der konsequenten Nutzung von Testmethoden.

Und – wenn der Begriff Testen auch Software Reviews einschließt:

  • Michael Fagan
  • Tom Gilb / Dorothy Graham
  • Karl Wiegers
  • Victor Basili

Wer Ihnen in der Liste fehlt

Welche Personen fehlen hier noch aus Ihrer Sicht? Wen darf man keinesfalls in einer solchen Liste vergessen?

Und: wen kennen Sie aus der obigen Liste? Die meisten sind mir bekannt, aber einige Namen habe ich noch nicht gehört.  Wie geht es Ihnen damit?

Veröffentlicht unter Reviews, Testen, Zum Weiterlesen | Verschlagwortet mit , , , , , | 1 Kommentar

Improving the Test Process: Neue Ausgabe der “testing experience” online verfügbar

Die neue Ausgabe der testing experience - The Magazine for Professional Testers ist erschienen und steht kostenlos als Download zur Verfügung: testingexperience

Schwerpunktthema des aktuellen Hefts ist Improving the Test Process. Ein Blick in die Zeitschrift lohnt. Sie finden dort interessante Artikel zu den Themenbereichen Testprozessverbesserung, TMMI®, TPI® und weiteren verwandten Themen. Erik van Veenendaal berichtet über die ISTQB® Zertifizierung “Improving the Testing Process”, zu der erste Schulungsangebote noch in diesem Jahr zu erwarten sind. Der Lehrplan hierzu ist inzwischen vom International Software Testing Qualifications Board (ISTQB®) in der Version 1.0.2 veröffentlicht worden und hier zu finden: Expert-Level-Syllabus

Viel Spaß beim Lesen!

Veröffentlicht unter Prozessverbesserung, System- und Softwareengineering, Zum Weiterlesen | Verschlagwortet mit , , , , , , | Hinterlasse einen Kommentar

ISO/IEC/IEEE 26512 ed 1.0 (2011-05) veröffentlicht

ISO/IEC/IEEE 26512 Systems and software engineering – Requirements for acquirers and suppliers of user documentation

Überblick

Bereits Anfang des Jahres war ich im Rahmen der IEEE-SA am Review des Standards beteiligt und nun wurde er veröffentlicht.

Dieser Standard soll die Nutzer der ISO/IEC 15288:2008, der ISO/IEC 12207:2008 und auch der ISO/IEC 15504 unterstützen, wenn Sie entweder Auftraggeber (acquirer) oder Auftragnehmer (supplier) von Nutzerdokumentation im Rahmen des Softwarelebenszyklus sind. Dazu wird der Prozess der Entstehung dieser Dokumentation aus beiden Sichten detailliert dargestellt:

  • Acquisitionsplan,
  • Spezifikation der Dokumente,
  • Statement of Work / Ausschreibungen / Lastenheft
  • Dokumentations-Managementplan

und ähnliche Arbeitsergebnisse, die in der Angebotsphase als auch den späteren (Liefer-)Phasen genutzt werden.

Der Standard unterscheidet nicht zwischen gedruckter oder elektronischer Darstellung oder Lieferung der Dokumentation und ist selbstverständlich unabhängig von Werkzeugen zur Erstellung der Dokumentation.

Auch bezieht sich der Standard ausdrücklich auch auf die Dokumentation von Hardware bzw. gesamten Systemen (Hardware und Software).

Hinweise

Da der Standard mit Unterkapiteln wie Zweck (Purpose) und Ergebnisse (Outcomes) strukturiert wurde, ist er für Kenner z.B der [12207] oder der [15504] übersichtlich gestaltet.

Der Standard enthält viele Inhalte, die im Sinne einer Checkliste sowohl dem Auftraggeber bei der Erstellung eines Lastenheftes helfen (z.B. auch so detaillierte Hinweise wie zur Lokalisierbarkeit) als auch dem Auftraggeber bei der Erfüllung erwarteter Anforderungen. Dies wird besonders durch die sehr hilfreichen Anhänge Annex A “Requirements clauses and checklist for acquirers” und Annex B “Requirements clauses and checklist for suppliers” unterstützt.

Ausblick

Da ich etwa zum selben Zeitpunkt

  • ISO/IEC/IEEE 26513 – Systems and Software Engineering – Requirements for Testers and Reviewers of User Documentation

und

  • ISO/IEC/ IEEE 26514 – Systems and Software Engineering –Requirements for Designers and Developers of User Documentation

gereviewt habe: diese beiden Standards ergänzen die 26512 hervorragend und werden hoffentlich auch bald in der neuen Version veröffentlicht.

Sie können ISO/IEC/IEEE 26512 ed1.0 (2011-05) direkt im Webshop der ISO-Organisation für CHF 136,- bestellen.

Veröffentlicht unter Dokumentation, Für Sie gelesen, Requirements Engineering, System- und Softwareengineering | Verschlagwortet mit , , , , , , , , , , , , , , , , , | Hinterlasse einen Kommentar

Fehlerhafte Anforderungen und ihre Auswirkungen

Fast 1500 Häftlinge, davon ca. 450 mit hoher Gewaltbereitschaft, wurden seit Anfang 2010 im US-Bundesstaat Kalifornien aufgrund eines Softwarefehlers ohne Auflagen aus der Haft entlassen.  Dabei wurde den Entlassenen ein Status “Unwiderruflich auf Bewährung” zuerkannt, der keinen regelmäßigen Besuch bei einem  Bewährungshelfer vorsieht.  Das Softwareprogramm, das die zuständigen Behörden bei der Reduzierung der Überbelegung Kalifornischer Haftanstalten unterstützen sollte, hatte zum Ziel, Häftlinge mit sehr geringer Rückfälligkeitswahrscheinlichkeit auszuwählen, um diese frühzeitig aus der Haft zu entlassen.

Mängel im Programm führten zu einer Fehlerquote von 15%, die zur Auswahl gewaltbereiter Häftlinge führte. Eine erste Analyse zeigte, dass der Fehler durch mangelhafte Anforderungen zustande kam. Genauere Fehlerursachen sind bis jetzt noch nicht bekannt, wie die Los Angeles Times berichtet. Der Fehler wurde bei nachträglicher Aktenprüfung aufgedeckt.

Hier handelt es sich wieder um ein interessantes Beispiel für die Bedeutung vollständiger und fehlerfreier Anforderungen. Ohne die genauen Hintergründe zu kennen, wage ich die These, dass eine adäquate Durchführung formaler Softwarereviews einen solch schwerwiegenden Fehler hätten verhindern können.

Veröffentlicht unter Bugs, Für Sie gelesen, Requirements Engineering | Verschlagwortet mit , , , , , | Hinterlasse einen Kommentar