Entwickler
8. Mai, 2020
App Dev Manager Darroll Walsh gibt Entwicklern eine Einführung in die CMMI-Entwicklung.
Das Capability Maturity Model Integrated (CMMI) ist ein Prozessverbesserungs- und Bewertungsprogramm, das mit anderen Prozessverbesserungsprogrammen wie dem Project Management Body of Knowledge (PMBOK) und Agile integriert werden kann. Es arbeitet daran, alle Prozesse zu rationalisieren und zu standardisieren und bietet ein Mittel zur Überwachung und umsetzbare Metriken für Entwicklung, Dienstleistungen, Lieferantenmanagement, Cyber-Reife und andere.
Ich möchte einen Überblick über CMMI Dev aus der Sicht eines Entwicklers geben. Wir werden die Bereiche Projektmanagement, Business Analyst, Konfigurationsmanagement und Testing von CMMI DEV überspringen, um uns auf die Auswirkungen von CMMI auf ein Entwicklungsteam zu konzentrieren. Wenn Interesse an den anderen Rollen oder Funktionen besteht, kann dies ein gutes Thema für einen späteren Blogeintrag sein. Beachten Sie nur, dass selbst in der agilen Entwicklung viel Arbeit anfällt, bevor Entwickler loslegen.
Lassen Sie uns beginnen:
Die BRS oder Business Requirements Specification ist, wo alles beginnt, das ist die einzige Quelle der Wahrheit. Dies ist, wo die Geschäftsanforderungen, die der Product Owner abzeichnet. Während die Entwickler bei der Erstellung des BRS konsultiert werden können, liegt dies hauptsächlich in der Verantwortung der BA. Hier kann ein Entwickler jedoch die Anwendung, die er entwickelt, wirklich kennenlernen. ein Ort, um das große Bild zu bekommen.
High-Level- und Low-Level-Designs ist die Architekturdokumentation, die zeigt, wie die Komponenten der Anwendung verbunden ist. Im High-Level-Design würden wir externe Abhängigkeiten festlegen und wie die Benutzer und / oder Systeme mit unserem System interagieren. Das Low-Level-Design würde festlegen, wie interne Komponenten miteinander interagieren. Die Überprüfung dieser würde einem anderen Entwickler ein sehr schnelles Verständnis der Funktionsweise der Anwendung vermitteln.
In der SRS (Software Requirements Specification) dokumentiert der Entwickler, wie die Anwendung erstellt wird. Hier werden Dienste dokumentiert, Abhängigkeiten festgelegt und im Allgemeinen, wie der Code funktionieren soll, basierend auf dem erstellten BRS. Dies geschieht normalerweise vor dem Schreiben des Codes und ist eine Standardaufgabe. Ich weiß, dass einige fragen, warum wir das tun müssten. Mein Code ist selbstdokumentierend. Und obwohl ich mir sicher bin, dass es so ist, wird Code durch Hunderte von Dateien und Tausende von Codezeilen verteilt. Und manchmal ist die Absicht nicht so klar, wie wir es gerne hätten. Die SRS gibt uns ein Dokument mit einem klaren Überblick darüber, was wir erwarten können. Es beschreibt Anwendungsfälle und erwartetes Verhalten in einer konsistenten Weise.
Nachdem wir definiert haben, was wir tun werden, und dann den Code geschrieben haben, ist es Zeit, dass jemand überprüft, was wir getan haben. Geben Sie den Code Review ein. Dies ist nicht nur eine gute Praxis, um Fehler zu erkennen und sicherzustellen, dass wir Best Practices und Richtlinien befolgen. Der bloße Akt der Überprüfung des Codes durch einen zweiten Satz von Augen gibt uns eine zweite Person, die mit der Funktionsweise des Codes vertraut ist. Da dies in den meisten Entwicklungsteams zur Standardpraxis geworden ist, werde ich mich nicht damit befassen.
Unit-Tests sind ein weiterer Hauptbestandteil der meisten Entwicklungsprogramme. Unit-Tests, ob als Teil der testgetriebenen Entwicklung oder nach dem Schreiben des Codes, sind eine der besten Möglichkeiten, um sicherzustellen, dass zukünftige Änderungen keine Fehler in unseren Code einführen. In einer CI / CD-Pipeline können wir sicherstellen, dass alle Tests bestanden werden, bevor Code eingecheckt werden kann. Dies hilft uns, den Code in gutem Zustand zu halten.
Individuell gibt es Wert in jedem Satz von Dokumenten oben, aber die wirklichen Gewinne beginnen, wenn Sie alle diese Informationen zusammenbinden können. Zu Beginn des Anforderungserfassungsprozesses starten wir eine Anforderungsnachverfolgbarkeitsmatrix, die es uns ermöglicht, Geschäftsanforderungen, Softwareanforderungen, Code, Komponententests, Testpläne und -fälle sowie die Benutzerakzeptanz miteinander zu verknüpfen. Stellen Sie sich sechs Monate in einem großen Projekt vor und eine Änderung führt dazu, dass ein Testfall fehlschlägt. Wir können jetzt zu den Anforderungen zurückkehren, herausfinden, was der Zweck dieses Codes ist, genau wissen, wo sich der Code für diese Logik befindet, den Komponententest ändern, um den neuen Fall abzufangen, und innerhalb von Stunden, nicht Tagen, einen Fix implementieren.
Kurzfristig mag CMMI wie ein Overkill erscheinen, aber selbst bei kleinen Projekten verkürzt das Wissen, das durch das Befolgen des Prozesses gewonnen wird, den Zyklus, je länger Sie sich vom Projekt entfernen. Ganz zu schweigen davon, wenn Sie noch nie an dem Projekt gearbeitet haben.
Entwickler-Support
App Dev Customer Success Account Manager, Microsoft Entwickler-Support
Folgen