Aufwandsabschätzung: Android-App Aufnahmefunktion (foto) und zweiter Ebene über dem Foto (teiltransparent)

[Larachen-10]

Liebe Java-Gemeinde,

ich stehe derzeit vor der Gründung eines Startups (Augenoptik).

Für das besagte Startup müsste ich eine App programmieren lassen. Die folgenden drei Varianten wären denkbar bzw. wünschenswert.

Variante A (Foto, 2D):

Android-App mit Fotofunktion (Aufnahme), wobei über dem Foto ein Farbraster (teiltransparent) liegt. Das Motiv (Kopf des Kunden) steht in stets gleicher Entfernung zum Endgerät. Das Farbraster muss sich daher nicht an das Motiv bzw. die Skalierung anpassen. Wünschenswert wäre darüber hinaus eine Art Fadenkreuz oder Hud. Analog zu Photoshop. Ebene 1 Foto, Ebene 2 Farbraster und Ebene 3 Fadenkreuz.

Variante B (2D):

Sicher etwas komplexer. Android-App mit Fotofunktion und besagtem Farbraster. Darüber hinaus soll bei stets gleichem Abstand zum Motiv ein Abstand zwischen zwei manuell gesetzten Punkten gemessen werden können. Der Anwender (Tablet oder Smartphone) markiert zwei Punkte auf dem Foto; die App refereziert die Messung auf den bekannten (stets gleichen) Abstand und misst den Abstand zwischen Punkt A und Punkt B auf dem Foto. 2D

Variante C (3D Scan):

Jetzt wirds vermutlich komplex. Der Anwender kann mittels Lidar, Infrarot oder Tiefenkamera einen 3D-Scan (Kopf des Kunden) durchführen und gleichzeitig manuell gesetzte Punkte auf dem 3D-Modell messen (Abstand) zwischen zwei Punkten. Auch hierbei ist der Abstand zum Motiv stets annähernd gleich.

Da wir unser Kapital/Budget in der frühen Startphase sehr gewissenhaft einplanen müssen, sollte die Umsetzung der App (Freelancer) mit überschaubaren Mitteln und Aufwand erfolgen können.

Was meint Ihr, wie komplex ist die Programmierung der Varianten A - C?

Gruß Kai

 

[White_Fox]

Ich habe sowas noch nie gemacht, dennoch etwas allgemeines:
Fast alles, was du machen willst, gibt es irgendwie schon.
Einfach nur eine Ebene über ein Foto legen...irgendwann hab ich so ein Programm gesehen, in dem man ein Foto machen konnte und das Programm hat es mit Hasenzähnen, Segelohren und dergleichen verschandelt.
Mittels der Kamera Entfernungen messen - auch das gibt es.

Also: alles ist schon gemacht worden und sollte - so an und für sich - kein Problem sein. Denkt man, der Teufel wird dich aber im Detail einholen, und da kann es schnell beliebig kompliziert werden. Je nach dem was du vorhast (das wissen wir ja nicht) kann es auf einmal stören daß das Bildmotiv Segelohren hat, Nase zu groß, ...und richtig spaßig wird es, wenn zu wenig bzw. erst am Kunden kostenpflichtig getestet wird.

Allgemein kannst du dich davon verabschieden, die Entwicklung von etwas Neuem halbwegs seriös zu planen. Planung ersetzt den Zufall durch Irrtum.


Edit:

App programmieren lassen
[...]
Freelancer

Es ist allgemein ein großes Problem, wenn man eine Firma gründen will die ein Produkt entwickelt, aber von der Technik nichts versteht. Und einerseits jemanden brauchen der etwas kann, andererseits kein Geld für Experten ausgeben zu wollen/können hat auch schon bei vielen nicht geklappt. Mache dir in jedem Fall Gedanken darüber, wie du das Wissen bei dir behältst wenn du mit Externen arbeiten willst. Und überlege gründlich...ich habe schon als Werkstudent Angebote abgelehnt nachdem mir der Firmenchef leutseelig versicherte, daß ja eigentlich alles schon fertig ist und nur noch zusammengebaut werden müsse. Weil es einfach klar ist, daß es nicht stimmt und wenn ich die Stelle angenommen hätte, jedes Rad nocheinmal von vorne hätte erfinden müssen.

 

[mihe7]

Grundsätzlich sehe ich es wie @White_Fox, d. h. die Anwendungen als solche sollten im Prinzip kein Problem darstellen. Wenn ich es richtig verstehe, ist das eine Anwendung, die nicht vom Kunden sondern vom Personal im Laden bedient wird. Dann hast Du natürlich ganz andere/bessere Möglichkeiten.

Aufwand zu schätzen, ist natürlich problematisch. Das fängt bei den "Features" an und hört bei der Organisation nicht auf. Um mal ein Beispiel zu nennen: ich habe vor ein paar Jahren mal eine ganz simple App (privat) geschrieben, die einfach auf eine SMS hin ein Foto macht und per Mail verschickt. Das war recht schnell umgesetzt bzw. "wäre gewesen". Der Code für die Kamera hat mich in den Wahnsinn getrieben, bis ich herausgefunden habe, dass es nicht an meinem Code sondern an dem Gerät liegt: das Teil hatte schlicht einen Bug. Und schon hat sich der Aufwand vervielfacht. Das sind Dinge, die kommen einfach vor und die kannst Du nicht einplanen.

Du solltest Dir jemanden suchen, der sich a) auskennt und b) Dich nicht übers Ohr haut.

Dann legt Ihr ein paar mehr Details fest. Auf welchen Geräten soll das Teil laufen? Welche OS-Versionen müssen unterstützt werden? Wer bedient das Teil? Soll das Farbraster/Fadenkreuz in der Vorschau, im Foto oder in beidem vorhanden sein? Wie soll das Farbraster überhaupt aussehen? Müssen Aufnahmeeinstellungen vorgenommen werden können? Wenn ja, welche? Muss die Kamera zwecks Messungen kalibriert werden? Wie? Kann man ggf. die Messung verbessern, durch Anbringen von Markierungen an der Wand? Steht die Hardware dem Entwickler zur Verfügung? Ist die Umgebung nachstellbar oder muss der Entwickler im Laden testen? Und so weiter und so fort. Dabei sollten beide Parteien schon eine ungefähre, aber gleiche oder zumindest recht ähnliche Vorstellung erhalten, wie die Anwendung am Ende aussehen wird.

Danach sollte der Umfang feststehen: was ist ein Muss, was ein Kann, was soll die Anwendung nicht können. Auf Basis dessen sollte Dir eine Größenordnung genannt werden können, mit der Du rechnen musst. Größenordnung heißt: wenn wir das angehen, reden wir dann eher von Tagen, von Wochen oder von Monaten?

Die Entwicklung selbst sollte dann iterativ ablaufen. Gerade in der ersten Iteration muss es darum gehen, sich auf das zu konzentrieren, was einerseits den größten Gewinn für die App bringt, andererseits das größte Risiko birgt. Das könnte hier das Ausmessen oder - eine Stufe davor - das Kalibrieren der Kamera sein. Abrechnen solltest Du nach tatsächlichem Aufwand, wobei die Abrechnung auch nach jeder Iteration vereinbart werden kann. Somit kann jede Iteration einen Auftrag für sich darstellen.

Apropos, ganz wichtig: das Vertragliche nicht vergessen.

 

[LimDul]

Anderer Punkt - die reine Entwicklung dürfte im Verhältnis nicht aufwendig sein, da stimme ich meinen Vorrednern zu. Ein paar Dinge die noch wichtig sind:

* Was passiert mit dem Source-Code am Ende? Der sollte in deine Hoheit übergehen, denke ich
* Wartung und Support? Es ist utopisch zu glauben, dass die Anwendung nach Abschluss des Projekts fehlerfrei ist und exakt das tut, was du brauchst. Sie wird vielleicht das tun, was du bestellt hast - was aber in der Regel nicht denkungsgleich ist zu dem was du brauchst. Das stellt sich oft erst im Laufe der Zeit raus. Wie ist es mit Anpassungen der Software im Laufe der Zeit? Insbesondere wenn man mal ein paar Jahre weiterblickt - neue Android Versionen etc.
* Dokumentation (Anwendung, aber auch Source-Code und Co, siehe die beiden Punkte darüber)

Zahlen nennen tue ich mich schwer, dazu sind die Anforderungen zu vage und ich hab sowohl im Bereich Android-Entwicklung keine Erfahrung, als auch bin ich mehr Entwickler als Projektleiter.

Das ist übrigens ein wichtiger Punkt, Entwickler schätzen tendenziell eher zu niedrig. Die reine Entwicklung, das Coding ist im Verhältnis zum Rest drum rum oft gering, als Entwickler schätzt man aber oft nur den Programmieraufwand. Der Aufwand für die Abstimmung, fachliche Klärung, Dokumentation, Abnahmetests, etc. - den vergisst man leicht.

 

[White_Fox]

Es ist im Übrigen in den "Projektwissenschaften" (ja, es gibt tatsächlich Leute die organisatorische Abläufe, Projektverläufe, usw. auf wissenschaftlicher Ebene befassen) so, daß ein Projekt doppelt so lange dauert wie es anfangs mal kalkuliert wurde. Wenn es gut läuft. Und nicht von lauter Rookies aufgezogen wurde, d.h. die Beteiligten haben Erfahrung und zumindest ähnliche Dinge schon öfter mal gemacht.
D.h. der Faktor 2 ist als Optimalfall anzusehen und keineswegs so etwas wie eine obere Schranke für eine Abschätzung.

Plane also entsprechende Reserven ein.

 

[Larachen-10]

Vielen lieben Dank. Die App wäre nur ein Zusatzinstrument und nicht zwingend erforderlich für den Vertrieb des Produkts. Um später Änderungen zu gewährleisten, müsste ich natürlich Zugriff auf den Code haben.

 

[White_Fox]

Dann würde ich die App nachträglich rausbringen, wenn das Produkt erstmal anfängt etwas Geld abzuwerfen.

Oder mir die App für eine Revision des Produkts aufheben. Vielleicht kommt, wenn ihr das Produkt erstmal draußen habt, ja auch heraus daß die App niemand wirklich nutzen würde. Dann kann man sie auch weglassen.