Software Engineering anwenden?

[InTheVoid]

In meinem letzten Unternehmen und im Probearbeiten ist mir aufgefallen, das die Vorgesetzten ohne richtige Struktur, schnell Ergebnisse wollten. Vielleicht liegt es daran das es mittelständische Unternehmen sind, aber ich habe keine Fakten um diese Aussage zu belegen.

Man hat also einfach so drauf losprogrammiert um schnell fertig zu werden, was wie man weiß, vielmals in die Hose geht.

Ist es i.O. sich hier einfach zu Beginn einen Tag Zeit für ein UML Klassendiagramm zu nehmen und sich Gedanken über die Architektur zu machen? Ich habe irgendwie das Gefühl, dass das beim AG nicht so gut ankommt.

Beim Probearbeiten hatte ich einen Wireframe als Vorlage und sollte eine UWP Anwendung mit diversen Funktionen Entwickeln. (8 Stunden Zeitbudget) Am Ende des Tages hatte ich 2 XAML Pages und eine Liste mit Echtdaten aus der Unternehmensdatenbank. Bei der Vorführung meines Ergebnisses hat man mir gesagt, dass sie dachten, das ich mehr schaffen würde.

Was wäre also wenn ich hier nur ein UML Klassendiagramm und ein UML für die Systemarchitektur vorgelegt hätte? 😅

Bearbeitet 16. Januar 2020 von InTheVoid

[KeeperOfCoffee]

Meiner Meinung nach: Kommt auf die Komplexität an. Viele haben halt schon für "Typische-Module" ein Schema X aufgebaut (mit abstrakten Klassen und Interfaces die Definieren wie ein Modul aufgebaut sein muss).

Auch bei mir sehen die meisten Module erstmal auf den ersten Blick sehr gleich aus vom "Aufbau". Sämtliche Komplexität kann dann noch hinzugefügt werden.

Architektur ist dann wichtig, wenn ein Programm komplett bei Null beginnt und man sich verschiedene Fragen stellen muss... z.B. welches Design Pattern könnte man anwenden (https://www.dotnettricks.com/learn/designpatterns).

Wenn das Grundgerüst erst mal da ist, dann kann man in der Tat recht schnell erste Dinge umsetzen.

Kommt natürlich auch darauf an, was es für ne Anwendung ist und welche Maße diese hat. Manche sind natürlich hier knallhart und machen erst ein UML, dann einen Test-Case, dann eine Doku und dann irgendwann nach X anderen Sachen wird mal programmiert. Das ist ja alles toll und sicher, aber in der Zeit würde ich vermutlich 2 Module schaffen. Für große Unternehmen die zusammen an Sache X arbeiten macht es natürlich Sinn.

UML usw. verwende ich nur bei sehr langen komplexen Algos oder langen Prozessketten ... da man hier oft Fehleranfälligkeiten auf den ersten Blick entdeckt oder gleich feststellt, dass man Dinge auf anderer Art evtl. schneller lösen kann etc.

Mach dir nicht so viele Gedanken ... du hattest mit UWP noch nicht viel zu schaffen ... der "wir dachten Sie schaffen mehr" ist ein typischer Spruch damit du mehr Gas gibts.

Bearbeitet 16. Januar 2020 von KeeperOfCoffee

[allesweg]

Das Problem beginnt viel früher.

Neuentwicklung oder Erweiterung?

Sind Tools vorhanden?

Sind dies UML-Malprogramme oder integrierte Tools mit Codegenerierung? Bidirektional?

Will die Unternehmensleitung schnell Gewinn oder plant man langfristig inklusive Wartung der Software?

Sind die Kollegen mit den Dokumentionsmöglichkeiten vertraut oder handelt es sich um schlecht angelernte Quereinsteiger?

...

 

 

Oder wollte man im Bewerbungsprozess nur sehen, wie du mit Stress umgehst?

[Rabber]

Das Thema Software Engineering ist eines der üblichen, wenn es um Theorie vs. Praxis geht.

In der Theorie finden alle Design Patterns, ordentliche Planung/Vorgehensmodelle, Clean Code, die gang of 4, Unit Tests/Test Driven Development, usw. ganz toll und schwärmen davon. Sobald es dann an die reale Entwicklung geht und der Kunde/Projektleiter/Chef auf seine Anwendung wartet, wird all das gerne über den Haufen geworfen und es muss "schnell, schnell" und "viel, viel" Output generiert werden. Schließlich müssen Deadlines sowie Kosten gehalten werden, Bugs können gefixed werden, Code Quality kann immer noch später kommen (also nie) und die nächste Spaghetti-Software ist geboren.

Das habe ich bisher fast ausschließlich so erlebt, egal ob in der 5-Mann-Bude, dem 500 Mann KMU oder 5.000 Mann-Konzern. Der Grund ist auch ganz einfach: Quality Assurance und Code Quality kosten enorme Summen Geld und bringen vordergründig wenig Mehrwert. Das möchte kaum ein Kunde/Chef bezahlen, so dass es hinten rüber fällt. Und selbst die meisten Teamleiter klemmen sich kaum dahinter.

Von daher ist dies eine meiner wichtigsten Lektionen, welche ich lernen musste und gerne allen weiter gebe: Die berufliche Softwareentwicklung hat häufig wenig mit dem gemein, was man in der Ausbildung, Fachliteratur, hier im Forum oder auch im Studium vermittelt bekommt. Und am Ende entwickelt kaum ein Unternehmen nach den sinnvollen und schönen Prinzipien, worüber wir Techniker uns den lieben langen Tag streiten. 😎

[tkreutz2]

Nein, ich glaube es ist nicht das Thema Dev Qualitäten zu zeigen in einem frühen Stadium einer Entwicklung, sondern es geht um etwas "Anfassbares" also eher die Visualisierung eines Konzeptes.

Nehmen wir das Beispiel eines Architekten. Er muss über ein fundiertes Wissen verfügen über Bauvorschriften und auch technischen Background. Das alles aber interessiert einen Kunden nur im zweiten Schritte. Im ersten Schritt möchte er sehen, wie sein künftiges Haus aussieht, im zweiten Schritt muss er dann erklären, warum etwas so und nicht anders geplant werden muss (z.B. Statik oder Vorschriften).

Es ist wohl die Gratwanderung, die auch ein Entwickler hinbekommen muss. Auf der einen Seite ein guter Architekt (mit dem Wissen im Hinterkopf) und auf der anderen Seite ein guter Verkäufer. Ob der Käufer jetzt Kunde oder interne Fachabteilung ist, ist dabei erst mal egal.

Meine Erfahrung ist die, dass eine gute Vision und Visualisierung, Türen öffnen kann. Der Mensch ist nun mal so verdrahtet, dass er etwas anfassen möchte, auch wenn das bei virtuellen Produkten zunächst einmal schwierig scheint.

Aber genau aus dem Grund gibt es ja auch etwas wie Prototypen oder Mockups. Hier steht erst einmal eine Idee- oder Vision im Vordergrund. Der Ausbau kann dann im zweiten Schritt noch erfolgen.

Ob der Architekturansatz "Design First" als Pattern eine gute Möglichkeit ist (sich als Entwickler zu verkaufen), darüber kann man sicher streiten. Wenn es darum aber geht, Leuten, die nicht vom Fach sind, etwas greifbarer- und damit "begreifbarer" zu machen, könnte es helfen.

Praktisches Beispiel. Also wenn ich einem Kunden eine App zur Verwaltung seines Videobestandes verkaufen wollte, würde ich vermutlich mit einer Visualisierung eines digitalen DVD Bücherregals mehr Begeisterung hervorbringen, als mit einer Skizze des dahinter stehenden Datenbankdesigns. Und wenn dann eben noch nicht alle Funktionen implementiert sind, kann man an der Stelle immer noch sagen - "Okay der Rahmen der Vision steht erkennbar da" - auch wenn es an vielen Stellen erst einmal eine Hülle ist.

Bearbeitet 16. Januar 2020 von tkreutz2

[KeeperOfCoffee]

Desweiteren stellt sich die Frage, ob es überhaupt deine Aufgabe sein sollte ein UML usw. zu entwerfen. Wenn du bzw. dein Team  von deinem Vorgesetzten eine Aufgabe bekommst, dann sollten schon sämtliche Anforderungen definiert sein.

Bei mir gab es früher bei neuen Projekten, Modulen usw. Teambesprechungen in welchen man die neuen Projekte meist schon durch UMLs visualisiert hat.

Gerade die Vorgesetzten bzw. Abteilungen, die mit den Kunden in Kontakt stehen haben, evtl. bereits UMLs grob ausgearbeitet, um den Kunden visuell darzustellen, wie sein Projekt aufgebaut ist.

Bearbeitet 16. Januar 2020 von KeeperOfCoffee

[tkreutz2]

Ja, ich finde es auch recht "seltsam" eine solche "Anforderung" an einem Probearbeitstag zu erhalten. Denn eine vernünftige Anforderungsanalyse findet ja eigentlich vorher statt. Das aber nur mal am Rande.