Worauf muss bei bei verteilter SW-Entwicklung achten?

Computer: Software & Programmierung Software allgemein
#1

Hallo,

eine Firma möchte einen SW-Auftrag an Dienstleister vergeben. Da es sich dabei um ein Folgeprojekt handelt, sollen die Teile des ersten Projekts möglichst wiederverwendet werden, damit man sich u. a. Kosten spart. Außerdem ist es absehbar, dass die Entwicklung zwischen verschiedenen Anbietern aufgeteilt wird.

Worauf muss man als Auftraggeber in einer solchen Konstrukt aufpassen? Irgendwie reden wir hier vom Wiederverwendungsmanagement („ReUse“) und auch vom SW-Konfigurationsmanagement. Auf was genau muss man hier als Auftraggeber (und nicht unbedingt vom Fach) achten?

Gruß und ein schönes neues jahr

#2

Das ist ein ziemlich sicheres Rezept für ein Desaster.

Gruß,
Steve

#3

Moin,
Die Verwendung alten Codes will auch gut überlegt werden, denn die neuen Entwickler müssen sich in den alten reindenken oder verwenden andere Algorithmen für ihre Arbeit.
Je nach Komplexität kann das teurer werden als das Recycling.
Ulrich

#4

Möglich ist das nur, wenn die Schnittstellen entsprechend dokumentiert sind, an welchen die Modulgrenzen liegen.
Ein typisches Beispiel ist ein Betriebssystem. Das API ist definiert und was hinter dem API liegt ist für den Anwendungsprogrammierer eine Black-Box!
Ähnlich ist es auch z.B. bei C/C++, da hat man Standardbibliotheken.

Grundsätzlich steht und fällt alles mit der Dokumentation der Schnittstellen und ob man das Projekt auch entsprechend sinnvoll zerteilen kann.

Zu deiner Frage kann man jetzt aber keine Stellung beziehen, da fehlt zu viel an Information!

Hier hat jeder schon einmal erlebt, dass es funktioniert hat aber nur wenn die passende Dokumentation besteht. Viele kennen aber auch das Desaster, welches andernfalls entstehen kann :frowning:
Eine grundlegende Frage ist auch noch ob es sich um eine Applikation auf einem Rechner handelt oder um eine Firmware auf einem Gerät.

MfG Peter(TOO)

#5

Ich habe einen guten Teil meiner Brötchen genau damit verdient, bestehende Projekte weiter zu entwickeln und/oder verfahrene zum Laufen zu bringen.

Ein Problem waren in einem Projekt z.B. Variablennamen, da gab es in einem Projekt temp_Messwert und akt_Messwert, beide vom gleichen Typ!
Nun wurde akt_Messwert als temporäre Variable für Berechnungen verwendet und in temp_Messwert wurde das Resultat der aktuellen Messung abgelegt. Zudem waren beide Variablen global!
Ähnliches bei den Funktionsnamen.

Ein weiteres Problem ist oft, dass Programmierer gar nicht daran denken, dass etwas wiederverwendet werden könnte oder sogar nur die Funktionen eines Geräts erweitert werden könnten.
Entsprechend ist dann alles spaghettimässig miteinander verknüpft :frowning:
Ganz nett auch, wenn fast alles in einem einzigen riesigen Modul zusammengefasst ist!

Dabei kann man z.B. in C/C++ zusammenhängende Teile in einem einzelnen Modul zusammenfassen. Weiterhin deklariert man alle lokalen Variablen und Funktion entsprechend so, dass sie global nicht sichtbar sind. In der Header-Datei ist dann alles aufgeführt, was von Ausserhalb aufgerufen werden kann, bzw. an Deklarationen, Konstanten usw. benötigt wird.
Damit hat man schon einmal die halbe Dokumentation und die Sicherheit, dass nicht von irgend wo her, Interna angesprochen werden.

Schon beim entsprechenden Anpassen des Source-Codes an solche Vorgaben, findet man dann ungewollte Seiteneffekt, bzw. so verstecke Bugs im Code.

Erst bei einem entsprechen strukturierten Projekt-Aufbau, kann man dann daran gehen einzelne Module zu optimieren oder auszubauen!

MfG Peter(TOO)

3 Like
#6

Hallo!

Mach’ es genau wie beim Produzieren einer Bratpfanne: Einer liefert den Metallkorpus, einer den Griff und ein Dritter ist für die Beschichtung zuständig. Klappt wunderbar unter der Voraussetzung, das ein in allen beteiligten Disziplinen sachkundiger (!) Mensch die Schnittstellen definiert.

So werden Serienromane geschrieben, Lokomotiven produziert, Häuser gebaut und Software entwickelt. Auch Bratpfannen.

Gruß
Wolfgang

#7

Auch hallo

Nicht nur vom programmiertechnischen, sondern auch vom rechtlichen Aspekt dürfte einiges beachtenswert sein: https://open.hpi.de/courses/it-recht2016

mfg M.L.

#8

Wenn man nicht vom Fach ist, dann sollte man sich zunächst einmal einen eigenen Projektmanager beauftragen, der vom Fach ist, und in der Lage ist, die Sinnhaftigkeit der Wiederverwendung von Code sowie die Möglichkeit der Aufteilung der Beauftragung auf diverse Dienstleister zu bewerten. Zudem kann der dann auch saubere Pflichten-/Lastenhefte, Anforderungen, Abnahmekriterien, … beschreiben, die dann Vertragsgrundlage werden.

Dann sollte man sich überlegen, inwieweit man unter den zu beteiligenden „Dienstleistern“ einen ausmachen kann, dem man den Auftrag als Generalunternehmer in Form eines Gewerks (Werkvertragsrecht = Erfolg geschuldet) übergibt. Damit ist der dann auch für die Interoperabilität der Teilleistungen und den Projekterfolg verantwortlich.

Weiterhin ist in solchen Projekten eine vorab sauber abzustimmenden und dann auch einzuhaltende Governance nötig. D.h. es braucht Regelmeetings mit sauber definierten Zuständigkeiten und Eskalationsprozeduren, sowie ein sauberes Change-Management mit regelmäßiger Fortschreibung des Projektplans und der Abnahmekriterien.