Suche für ein neues Projekt Personal

  • Hallo,

    Ich suche für ein neues Projekt Personen mit guten Kenntnissen im Bereich pi, Hardware, Module und Elektronik kenntnisse. Weiter suche ich Leute die in verschiedenen Programmiersprachen schreibe oder sich ergänzen können. Hier genauerin phyton, php, sql, c, c++ usw.

    Für das Projekt wird es in der zeit der Erstellung des Projekts eine Entwickler Seite geben.

    Bei Interesse bitte per Mail oder pn melden.

    Gruss Frank

  • Hi,

    Also die Dauer kann ich nicht festlegen.
    Das Projekt soll z.b. Wetterlagen von den fitchi Insel oder dem Australien ab rufen und sie zeitversetzt hier ablaufen lassen. Damit soll eine Steuerung gefüttert weden, welche dann zB Pumpen schaltet, licht steuert usw.
    Weiter soll eine Dosierung und Sonden bedient werden. Das ganze dann auch über web, smartphone, iphone abrufbar und bedienbar sein.
    So weit mal grobe Züge zum ganzen.

  • Hm, ich frag mich gerade wieso die Wetterlage auf den Fidchi Inseln oder Australien, hierzulande Pumpen oder Lichter beinflussen sollten :huh: Wenns in Fidchi regnet soll hier der Keller ausgepumpt werden? :lol:

    Da er bisher aber auch gerade die Frage nach Entgelt (Gegenleistung) nicht mal ansatzweise beantwortet hat, könnte man annehmen das es sich bei diesem Projekt eher um etwas privates handelt, gerade wenn man seine bisherigen Beiträge hier um Forum betrachtet bzw vorallem den letzten , liegt das nahezu auf der Hand... Da stehen auch mehr Details zu dem Projekt.

    Naja, eine etwas merkwürdige Art nach Hilfe zu fragen

  • Jo, hatte ich nach meinem Beitrag auch gelesen.

    Sonnen auf- und Untergang sind ja bekannt, da brauche ich nichts abzufragen und wenn auf Fidschi ein Sturm ist, haben die Fische im Aquarium sicher kein bock den mitzuerleben.

    Steuerung von Spurenelementen usw. macht sicher Sinn mit dem Raspi.

  • Hallo Frank,

    der übliche Weg ist der:

    1. Erstellung eines Lastenheftes (Auflistung aller Deiner Forderungen bzgl. Hardware, Software, Bedienung, Algorithmen, Sensorik, Sicherheitsaspekte, ...) die in Abnahmetests prüfbar sind.

    2. Vorstellung des Lastenheftes gegenüber einem kleinen Kreis an Personen, die Du für fähig hältst, dies umsetzen zu können. Von diesen Personen hast Du eine Verschwiegenheitserklärung unterschreiben lassen. Wenn Du in diesem Forum seit rund einem halben Jahr unterwegs bist, solltest Du Deine Favoriten beisammen haben...

    3. Die Person, mit der Du das Projekt dann machen möchtest, erstellt ein Pflichtenheft (Inhalte, die abzugeben der Entwickler bereit ist, mit welcher Umgebung [Hardware, Software, Entwicklungsumgebung, Bibliotheken, ...] die Lösung angegangen werden soll), in der im Prinzip ansatzweise Lösungsansätze beschrieben werden. Hierfür gibt es den vereinbarten Obulus (z.B. 10 % des Auftragsvolumens). Gefällt Dir das Pflichtenheft, dann erteilst Du den Auftrag für das Technische Design. Ansonsten würfelst Du Dir einen anderen "Anbieter" heraus.

    4. Gefallen Dir diese Ansätze und bist Du der Ansicht, dass Dein Vorhaben in den richtigen Händen / Kopf gelandet ist, dann erstellt Dir der "Anbieter" ein Technisches Design, in dem Punkt für Punkt beschrieben wird, in welcher logischen Abfolge (inkl. Programmierung, Datenstrukturen, Bedienoberfläche, Performance, ...) detailliert die Entwicklungstätigkeit beschrieben wird. Mit diesem Dokument kannst Du den Projektfortschritt verfolgen und auch Aussagen treffen, ob der Projektplan eingehalten werden kann. Hierfür gibt es auch einen Obulus (z.B. 15 - 20 % des Auftragsvolumens). Gefällt Dir das Technische Design, dann erteilst Du den Auftrag für die Entwicklung. Ansonsten wandern Lastenheft und Pflichtenheft zu einem anderen "Anbieter".

    5. In der Entwicklungs- und Testphase schickt Dir der Entwickler zu den im Technischen Design vereinbarten Projektphasen Ergebnisse seiner Tätigkeit (z.B. Layout der Oberfläche, Nachweis, dass die Sensoren abgefragt werden können und die Aktoren gesteuert werden können). Du hast dann die Möglichkeit, dem Entwickler Input zu geben, ob er Deine Vorstellungen trifft. Für jede erfolgreich abgeschlossene Projektphase gibt es dann auch einen Obulus (wie vorher definiert). Für die Entwicklungsphase sind ca. 40 - 50 % des Auftragsvolumens anzusetzen.

    6. Optional gibt es nach Abschluss der Gesamtentwicklung dann einen Abnahmetest beim Entwickler (Factory Acceptance Test: FAT), falls umfangreiche Hardware / Infrastruktur zu verwenden ist, die zu dieser Projektphase nur beim Entwickler vorhanden ist.

    7. Danach folgen umfangreiche Abnahmetests bei Dir (Site Acceptance Test: SAT), in der Dir die Umsetzung vorgeführt wird. Hier wird jeder Punkt Deines Lastenheftes auf Erfüllung geprüft (Installation, Operation, Leistung) inkl. Stresstests. Alle Tests ergeben sich aus dem Lastenheft / Pflichtenheft / Technischen Spezifikation.

    8. Danach hast Du eine zeitlich befristete Phase, in der Du das System auf Herz und Nieren prüfen wirst. Erst, wenn Du Deine spezifizierten Forderungen aus dem Lastenheft in vollem Umfang wiedergefunden hast, dann gibt es den Rest des Obulus (üblicherweise 25 - 33 %).

    Der Vorteil dieser "Heftestruktur" hat sich in zahlreichen Projekten bewährt, weil jeder Seite zu jedem Zeitpunkt klar ist, was gemacht werden soll - und welche Gegenleistung (in beide Richtungen) es dafür gibt. Unklarheiten können zeitnah geklärt werden und eskalieren nicht gegen Ende des Projektes, wo nichts mehr zu retten sein kann.

    Außerdem bietet es für die Entwicklerseite den Vorteil, bereits während der Entwicklung zu testen, ob denn der entwickelte Code die definierten Forderungen erfüllt.

    Bei überschaubaren Projekten kann auch ein "Heft" geschrieben werden, dass aus Kapiteln "Lastenheft", "Pflichtenheft" und "Technisches Design" besteht. Aber grundsätzlich ändert sich an den oben gemachten Aussagen nichts.

    Ansonsten hginbt es zwei Modelle der Bezahlung zu berücksichtigen:

    - Stundensatzbasis (für jede erreichte / abgeschlossene Projektphase bekommst Du eine Rechnung, in der datailliert erbrachte Leistungen und deren Erbringungszeitraum detailliert beschrieben sind) - dies setzt großes Vertrauen Deinerseits in den "Entwickler" voraus.

    - Leistungsbasis (für jede erreichte / abgeschlossene Projektphase gibt es den vereinbarten Obulus) - dies setzt großes Vertrauen des "Entwicklers" in Dich voraus.

    Bei beiden Modellen ist zu berücksichtigen, dass "Hobby-Anbieter" und "Profis" mit anderen finanziellen Vorstellungen auftreten. Aber auch, dass die einen viel Zeit "vergeuden", Basiswissen zu erarbeiten, dass bei "Profis" direkt abrufbar ist. Der "Hobby-Anbieter" schreibt jede Zeile Code selber oder sucht sich was in Foren zusammen, der "Profis" verfügt möglicherweise über direkt nutzbaren Code für Teilabschnitte. Aus diesem Grund wirst Du häufig bei "Hobby-Anbietern" eine stundensatzorientierte Bezahlung vorfinden, bei "Profis" oft einen Festbetrag genannt bekommen.

    Üblich ist es auch, dass ein Teil des Obulus (ca. 30 bis 50 %) mit Beginn einer Projektphase auf Vorschussbasis ausgezahlt werden, um den gegenseitigen Vertrauensvorschuss / Risiko bei Zahlungsausfall zu mindern.

    Ansonsten basiert alles auf Verhandlungsbasis.

    Beste Grüße

    Andreas

    Ich bin wirklich nicht darauf aus, Microsoft zu zerstören. Das wird nur ein völlig unbeabsichtigter Nebeneffekt sein.
    Linus Torvalds - "Vater" von Linux

    Linux is like a wigwam, no windows, no gates, but with an apache inside dancing samba, very hungry eating a yacc, a gnu and a bison.

    Einmal editiert, zuletzt von Andreas (9. November 2014 um 10:54)

  • Um es nicht ganz so komplex zu machen, denn das Projekt scheint überschaubar zu sein, wäre auch eine agile Softwareentwicklung möglich. Problem an der Sache ist nur, es wird für dieses Projekt kein Geld geben. Es ist ein Aufruf einer Privatperson, für diese Privatperson zu programmieren. Als Gegenwert wird es Dankbarkeit und Ehre geben...
    Mir ist das oben von Frank alles zu schwammig, ich bin raus und kümmere mich um echte Projekte...

  • Hallo Motom001,

    ich wollte nur mal zeigen, wie professionell vorgegangen wird - agile Software-Entwicklung ist schön und gut. Das hatte ich auch mal in einem Projekt gemacht. Das Problem war, dass der Kunde bei jeder Vorstellung der Zwischenlösung mit neuen Ideen kam. "Und könnte man jetzt nicht noch dieses und jenes Feature mitaufnehmen? - Das und Das erscheint uns jetzt aber auch noch wichtig. Herr X / Frau Y fände es gut, wenn das Programm jetzt auch hellsehen kann ..." Die ursprüngliche Aufgabenstellung bildete zum Schluss weniger als 10% der finalen Problemlösung. Der Kunde war zwar begeistert, aber der Frust lag eindeutig bei mir - weil nie ein wirkliches Ende erkennbar war und auf mich der Eindruck entstand, dass die Zahlung hinausgezögert werden sollte.

    Ein solches Missverhältnis kann bei konsequenter Befolgung von Lastenheft-Pflichtenheft-Technisches Design-etc. nicht auftreten, da jede neue Kundenforderung in entsprechend neuen Versionen dieser Dokumente resultiert. Und bei popeligen Neuforderungen wird es der Auftraggeber irgendwann unterlassen, Zusatzwünsche zu dokumentieren, zu besprechen, über Mehraufwände diskutieren zu wollen.

    Wer mehr drüber lesen will, möge nach "V-Modell der Software-Entwicklung" suchen.


    Ein anderes Entwicklungsmodell, was sich auch bewährt - aber weniger durchgesetzt hat - ist Folgendes:

    1. Der Entwickler programmiert das, was er von der Aufgabenstellung verstanden hat ("Ja, er war stets bemüht, die an ihn gestellten Aufgaben zu verstehen...").
    2. Ein Kollege der "Technischen Dokumentation" erstellt eine Betriebsanleitung für die Software während der Entwicklung.
    3. Dabei testet er bereits die Software, um an Screen-Shots etc. heranzukommen - und hat so die Möglichkeit, die gröbsten Macken aufzudecken. Hier haben sich dann auch automatische Testmethoden bewährt, durch die sich alle möglichen Zustände erzeugen lassen und Programmfehler schneller entdeckt werden.
    4. Der Programmierer nimmt dann diesen Input, um sein Programm ausfallsicherer zu machen und von den offensichtlichsten Fehlern zu befreien.
    5. Inspiriert von der entstehenden Betriebsanleitung kommt dann auch der Programmierer auf ganz andere Ideen, die er dann wieder umsetzt.

    Auf diese Weise befruchten sich dann Software-Entwicklung und Technische Dokumentation - und im Extremfall sind die Bedienungsanleitung und die Software zur gleichen Zeit abgeschlossen. Die Software-Tests kann man sich dann weitgehend vereinfachen, da die Software ja hinreichend funktioniert haben muss, weil ansonsten die Screenshots nicht möglich gewesen wären.

    Beste Grüße

    Andreas

    Ich bin wirklich nicht darauf aus, Microsoft zu zerstören. Das wird nur ein völlig unbeabsichtigter Nebeneffekt sein.
    Linus Torvalds - "Vater" von Linux

    Linux is like a wigwam, no windows, no gates, but with an apache inside dancing samba, very hungry eating a yacc, a gnu and a bison.

    Einmal editiert, zuletzt von Andreas (9. Oktober 2017 um 23:08)

  • Naja ich glaube ihr übertreibt ein bisschen. frank0312 formulierte es leider missverständlich. Aber ich bezweifle das er etwas Professionelles umsetzen möchte, also nix offiziell finanziertes, für ein Museum oder was auch immer...

    Das wird eine Idee von ihm selber sein, ein Projekt welches er selber für sich umsetzen möchte, aber nicht die nötige eigene Ahnung hat. Oder auch nicht die Zeit ... oder was auch immer.


    Man überlegt sich was man mal basteln könnte, kauft sich ein paar Sachen, merkt das man aber selber nicht so weit kommt, also fragt man in einem Forum um Hilfe/Unterstützung.

    Mehr wird das nicht sein.

    Also sind deine Posts @ Andreas hier vermutlich auch etwas deplaziert und offtopic ;) Das Thema hier ist nicht "Wie setzt man geschäftliche Projekte um"


    ...just my 2 cents...

Jetzt mitmachen!

Du hast noch kein Benutzerkonto auf unserer Seite? Registriere dich kostenlos und nimm an unserer Community teil!