Home » LVUG » LVUG - Objektorientiertes Programmieren » Vorschlag für ein LVUG Open Source Projekt
| Vorschlag für ein LVUG Open Source Projekt [message #1203] |
Tue, 30 November 2004 13:42  |
 |
Brand
Messages: 180
Registered: January 2004
Location: GSI - SB2 2.256
|
first-grade participant |
From: depc56.gsi.de
|
|
Liebe LVUG Fans.
um sowohl die Attraktivität als auch die Produktivität der LVUG zu erhöhen, möchte ich ein LVUG Projekt vorschlagen. Ich denke, dass ein unvollständiger Web-Auftritt, ein Werbebanner und ein Diskussionsforum, das die Arbeit des NI-Support ergänzt, nicht ausreichend sind, um den Bestand der LVUG zu sichern.
Das Spektrum der Standard LabVIEW Technologien und Applikationen wird bereits in den mitgelieferten Beispielen umfangreich behandelt und durch die NI-Developerzone vorbildlich ergänzt. Was fehlt ist ein Framework für Kontroll- und Automatisierungssysteme, um die Wiederverwertbarkeit und den Austausch von LabVIEW VIs und Bibliotheken zu erhöhen und zu vereinfachen.
Ich möchte daher ein Open Source Projekt vorschlagen, das auf dem an der GSI entwickelten ereignisgesteuerten und objektorientierten Kontrollsystem Framework basiert, D. Beck et al., Nucl. Instr. Meth. A 527 (2004) 567-579.
Es enthält eine umfangreiche Klassenbibliothek und ist bereits an verschiedenen Experimenten im Einsatz. Es steht zum Download bereit und unterliegt der GNU GPL Lizenz.
Selbstverständlich muss einem Projektentscheid eine ausführliche Diskussion vorausgehen, die ich hiermit anstoßen möchte. Fragen bzgl. der Verantwortlichkeiten, Projekt-, Qualitäts- und Dokumenten-Management müssen verlässlich geklärt werden, da die Arbeiten einen nicht unerheblichen Aufwand bedeuten. Eine wesentliche Voraussetzung für das Zustandekommen eines solchen Projektes ist für mich auch die Vervollständigung des LVUG-Webauftritts durch Beiträge der LVUG Mitglieder, die dadurch ihr konkretes Interesse an der LVUG bezeugen können.
Da ich bisher noch keine Erfahrungen mit dem Management von Open Source Projekten habe, freue ich mich auf eine lebhafte Diskussion.
Gruß Holger
[Updated on: Wed, 11 May 2005 17:35] Report message to a moderator |
|
|
|
|
|
|
|
|
|
| Vorschlag für die Qualitätssicherung [message #1248 is a reply to message #1203] |
Wed, 08 December 2004 12:17  |
|
Brand
Messages: 180
Registered: January 2004
Location: GSI - SB2 2.256
|
first-grade participant |
From: depc56.gsi.de
|
|
Liebe LVUG Fans,
falls die LVUG ein Open Source Projekt auf Basis des CS starten sollte, ist eine gute Qualitätssicherung extrem wichtig, um die Erfolgsaussichten für das Projekt zu steigern.
Die Qualitätskontrolle sollte natürlich nicht von den Entwicklern durchgeführt werden. Sie sollte auch sehr bald so weit wie möglich automatisiert werden.
Das VI-Analyzer-Tool bietet hierzu die Möglichkeit und liefert die notwendige Unterstützung. Es müssen verschiedene Analyse-Konfigurationen erstellt werden, um die Qualität von VIs in verschiednen Kategorien adäquat zu überprüfen. Möglicherweise kann ein CS-Plugin für den VI-Analyzer entwickelt werden.
Die Empfehlungen für den (Programmier-) Stil könnten im Rahmen eines Code-Review erarbeitet werden. Diese Empfehlungen sollten dann als notwendige Bedingung eingehalten und überprüft werden, damit eine neue Klasse in eine "offizielle Distribution" aufgenommen wird.
Um die zu definierenden Qualitätsmerkmale überprüfbar zu machen ist möglicherweise eine Überarbeitung des jetztigen Entwurfs notwendig. Daher sollte mit dieser Aufgabe begonnen werden, sobald ein positiver Projektentscheid zustande gekommen ist.
Wer möchte diesen Job übernehmen?
Gruß Holger Brand
[Updated on: Wed, 08 December 2004 12:20] Report message to a moderator |
|
|
|
| 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
|
|
|
|
|
|
|
|
|
|
| Lizensierungsmodelle für ein LVUG Open Source Projekt [message #1662 is a reply to message #1203] |
Tue, 10 May 2005 12:51 |
|
Brand
Messages: 180
Registered: January 2004
Location: GSI - SB2 2.256
|
first-grade participant |
From: denbg014.gsi.de
|
|
Liebe LVUG-Fans,
ich möchte an dieser Stelle die Diskussion des Lizensierungsmodells für das vorgeschalgenen Open Source Projekt anregen.
Folgende Modelle wurden vorgeschlagen:
Weitere informative Links:
Die GSI und alle bisherigen Autoren favorisieren die GNU GPL für das CS-Framework und ein darauf basierendes Open Source Projekt!
Gruß Holger
[Updated on: Wed, 11 May 2005 17:34] Report message to a moderator |
|
|
|
Goto Forum:
Current Time: Tue Dec 03 12:28:28 CET 2024
Total time taken to generate the page: 0.00455 seconds
|
GSI Forum
Search
Help
Members
Login
Home
