Diese Frage zur verteilten Quellcodeverwaltung wurde mir im Allgemeinen von jemandem gestellt, der mit Team Foundation Server vertraut ist.
Ist es möglich, einen DVCS wie Git oder Mercurial für die Quellcodeverwaltung zu verwenden und Standards wie ISO 9001 oder CMMI zu erfüllen?
Welche Anforderungen stellen ISO 9001 und CMMI an die Quellensteuerungswerkzeuge, zu denen sie gehören sollten und sollten?
Gibt es irgendwelche Dinge, die Git / Mercurial dazu veranlasst, dass ISO 9001 / CMMI als schädlich betrachten würde oder spezielle Überlegungen erfordern?
Ich habe einige Informationen bei Ссылка gefunden, aber auf den ersten Blick scheint es nicht viel anderes zu sagen die Notwendigkeit, Aufzeichnungen darüber zu führen, was sich geändert hat, welche Versionen Ihrer Software Sie bereitgestellt haben und welche Probleme behoben wurden, und es gibt keinen Grund, warum DVCS dies nicht in Kombination mit einem Bug Tracker wie FogBugz und a CI-Server wie TeamCity.
Erstens ist Software nicht nach ISO 9001 zertifiziert. Nur Organisationen sind nach ISO 9001 zertifiziert . Also macht die Frage, wie gesagt, keinen Sinn. Sie können nur fragen, ob die Entwicklungsteams von Git oder Mercurial nach ISO 9001 zertifiziert sind. (Das gleiche gilt für CMMI).
Alle ISO 9001 für ein Softwareentwicklungsunternehmen bedeutet, dass Sie einen schriftlichen Prozess für alles, was Sie tun (Entwicklung, Fehlerbehebungen usw.), haben und dass Sie ihm folgen. Nun, das und Sie haben jemanden dafür bezahlt, ein ISO 9001-Audit zu machen, das die oben genannten Punkte bestätigt. CMMI ist viel mehr beteiligt, aber für die Zwecke dieser Diskussion können wir sie ähnlich betrachten.
Sie müssten wahrscheinlich ziemlich lange suchen, um ein Community-Projekt für Freie Software zu finden, das sich die Mühe gemacht hat, die gesamte Prozessdokumentation zu erstellen und das Geld für ein Audit zusammenzukratzen. Wenn Sie einen finden, würde es wahrscheinlich nur aufgrund einer Art von großen Corporate Sponsor es wollen.
Wenn die Frage ist, was diese Standards über die Verwendung der Quellcodeverwaltung festlegen, wäre dies im Falle von ISO 9001 nichts . Der alte Witz ist, dass, wenn Sie Ihr Produkt nehmen und es ein 10-stöckiges Fenster zum Verladedock unten auslassen, das von ISO gut ist, solange das Ihr dokumentierter Prozess ist und Sie ihm folgen.
Ich arbeite in einer 21 CFR 820 (reguliertes medizinisches Gerät) / ISO 13485-Umgebung, aber das "große Bild" entspricht in etwa der ISO 9001. Ich stimme all den obigen Ausführungen zu, dass es bei ISO 9001 um Prozess und nicht um Werkzeuge geht .
Sie arbeiten jedoch möglicherweise in einem Bereich, in dem Sie Prozeduren für technische Entwurfskontrollen implementieren müssen, und Entwurfskontrollen berühren die Prozesse, Tools und Arbeitsanweisungen, die von Entwicklern verwendet werden. Insbesondere im Bereich der medizinischen Geräte müssen wir uns über alle Software-Tools Gedanken machen, die die Sicherheit oder Wirksamkeit des Produkts beeinflussen. Dies beinhaltet Tools für das Konfigurationsmanagement und die Versionskontrolle (wenn Sie nicht kontrollieren können, welche Version der Software Sie erstellen, können Sie nicht überzeugend sagen, dass Sie wissen, welche Version (en) im Feld sind, so dass Sie es nicht sagen können welche Kunden für einen Rückruf kontaktieren).
Für solche Tools benötigen wir eine "Computer Systems Validation" (CSV) -Dokumentation. CSV für ein Drittanbieter-Tool umfasst (1) eine Werkzeugspezifikation, die die Anwendungsfälle innerhalb des Produktentwicklungszyklus beschreibt und beschreibt, wie sie die Qualität beeinflussen und (2) Testfälle, die objektive Beweise liefern, dass das Werkzeug in den vorgesehenen Anwendungsfällen wirksam ist .
Für ein Versionskontrollsystem bedeutet dies im Grunde genommen ein Whitepaper, in dem die von Ihnen verwendeten Funktionen (Check-in, Checkout, Abzweigungen, Tags) und einige Tests dieser Funktionen beschrieben werden. Wenn die Software über eine eigene Testsuite verfügt, können Sie für Bonuspunkte nachweisen, dass sie ausgeführt wird und ihre eigenen Tests besteht.
Von der CMMI Homepage :
CMMI ist ein Prozessverbesserungsansatz, der Unternehmen die wesentlichen Elemente effektiver Prozesse zur Verfügung stellt, die letztendlich ihre Leistung verbessern.
CMMI befasst sich mit Prozessen und nicht mit Werkzeugen. Mein Verständnis ist, dass Sie Versionskontrolle mit Tontabletten und CMMI-konform sein können, wenn Sie einen Prozess dafür hatten (Level 2) und den Prozess verfolgt haben (Level 3,4,5).
Ich konnte bei einem früheren Arbeitgeber an einem SCAMPI C-Audit teilnehmen und Prozesse für zwei CMMi-Prozessgruppen entwickeln. Außerdem haben wir mit unserem CMMi-Berater ausführliche Diskussionen zur Versionskontrolle geführt. Wir haben während dieses Prozesses kein DVCS verwendet, aber aus vielen der oben genannten Gründe kann ich nicht sehen, warum es ein Problem wäre.
In Bezug darauf, was CMMi tatsächlich für testet, behaupten die anderen Poster, dass solange der Prozess dokumentiert ist und die Entwickler den Prozess richtig verstehen und zitieren können, alles in Ordnung sein sollte.
Um sicherzustellen, dass Ihr Team bereit ist, ein CMMi-Audit zu bestehen, wäre das einzige Problem, ein kleines oder mittleres Team von Open-Source-VCS (SVN, CVS) oder kommerziellen VCS zu überführen (MKS, AccuRev, etc ...) zu einem DVCS ohne die entsprechende Hochlaufzeit. Da der Übergang störend sein kann, möchten Sie sicherstellen, dass Ihr Team DVCS fest im Griff hat, bevor Sie das Audit durchführen.
Wie andere Leute bemerkt haben, geht ISO 9001 nicht um das Werkzeug. Arbeiten an einer Institution, die ISO 9001-konform ist, signalisiert, dass sie (die Institution selbst) "ausgereift" sind. In diesem Zusammenhang ist das Wort ausgereift, was darauf hinweist, dass sich die Organisation strikt an geprüfte Prozesse hält, die nach ISO 9001 zertifiziert sind. Prozesse, die Git oder Mercurial betreffen, haben keinen Einfluss auf Ihre Fähigkeit, in irgendeiner Weise ISO 9001-konform zu werden (es sei denn, Sie folgen den Prozessen nicht).
Zumindest verstehe ich das alles.