Home » LVUG » LVUG - Objektorientiertes Programmieren » Vorschlag für ein LVUG Open Source Projekt
| CS - OSP - Qualitätsmanagement [message #1358 is a reply to message #1248] |
Fri, 04 February 2005 16:57   |
 |
Robi Biswas
Messages: 61
Registered: March 2004
Location: Beimerstetten/Ulm - Germa...
|
continuous participant |
From: *dip0.t-ipconnect.de
|
|
Hallo Holger,
hallo Kollegen,
Qualitätsicherung ist der richtige Ansatzpunkt VOR Beginn des
OpenSource-Projektes.
Anforderungen (bitte ergänzen)
===============================
- Zentrales Management (wie vorgeschlagen) mit
Versionsverwaltung. Das ist die schwierigste Aufgabe. Es wird
immer Zwischenversionen geben, notfalls auch Rücknahmen von
Modifications.
- Aufteilung des CS Systems in handlebare Teile/Module
(Kernel + AddOn Sateliten), ich bin mir bewusst, dass es viele
Überschneidungen geben wird.
AddOns:
DataBase Connectivity, Data Supervisory Kompatibilität(NI DSC),
Realtime Ability, Basic Classes, Extended Classes (supported),
User Classes (not supported), Examples etc. etc.
- Handlebarkeit bedeutet, dass nur ein Teil des Systems von einem
OpenSource Member eigentverantwortlich verändert wird.
In der Praxis wird dieser gezwungen, auch Module anderer
Bereiche anzufassen. Die Folge: OS-Treffen der beiden, in denen
weiteres zu klären ist.
Ein weiterer Aspekt ist dieser: Man geht zum Kunden und spielt
eine neue Version ein.
a) Der Kunde will die alte Version noch nutzen können
b) Der Kundendienst will nur die UserClasses und Configfiles
einspielen (als EXE z.B.)
c) Beide wollen sicher sein, dass die Änderungen weitgehend
rückwirkungsfrei bleiben.
Das Beispiel zeigt, dass wir versuchen müssen, eine viel
stärkere Trennung von Tool (CS), AddOns und User Modules
zu erzielen.
- KISS! Keep It Stupid Simple, wir alle wollen ein schlankes
System, das AddOns nicht zwingend braucht und die Ressourcen
schont. Nicht jeder hat die Infrastruktur der GSI. D.h. mit
der Schlankheit steigt die Attraktivität von CS.
- CS SW-Test Tool Project Team, Qualitäts-Sicherung.
Dazu gehört die Definition von Funktionen und Abläufen, die
unabhängig von den "SW Modifiern" erstellt wird.
Das zu entwickelnde Tool unterzieht die aktuelle Version
diesen Kriterien. NUR SO können Probleme rechtzeitig erkannt
werden und andererseits das Vertrauen in CS sichern. Von diesem
Vertrauen hängt das Leben und Sterben unseres OS-Projektes ab.
- Developer Download Pool.
Jeder OSP-Entwickler kann jederzeit jedes CS-Part (z.B. ein
AddOn) downloaden. Bei jedem CS-Part steht die Qualitätsstufe
in einem standardisieren und Autorisierten PDF Formular drin.
(Idee, in Arb., Alpha, Beta, separat getestet, eingebaut,
Gesamttest mit Partversionen.. etc., Name, Datum, Freigabe)
- bitte ergänzen!!!
Freundliche Grüsse aus dem Zentrum Süddeutschlands,
Euer Robi Biswas
www.biswas.de
|
|
|
|
Current Time: Wed Apr 24 03:59:05 CEST 2024
Total time taken to generate the page: 0.00867 seconds
|
GSI Forum
Search
Help
Members
Login
Home
