Soll ich meinem Arbeitgeber zuhören und CASE-Tools verwenden?

Mein Arbeitgeber (kein Entwickler) ist der Meinung, dass CASE-Tools uns helfen werden, unseren Entwicklungsprozess und unsere Dokumentation zu verbessern. Ich bin mir nicht sicher, wir sind ein kleines Team von 5 Entwicklern, die Mobile-Banking-Lösungen für lokale Kunden entwickeln. Ich denke, CASE-Tools sind eine Verschwendung von Zeit und Geld, da sie gekauft werden müssen, und wir werden einige Zeit brauchen, bis wir uns an sie gewöhnt haben und effizient mit ihnen zum Modellieren und für andere Dinge arbeiten können. Die Codegenerierung ist ein weiteres Problem. Ich denke wirklich, dass der von CASE generierte Code nicht so gut ist wie der von guten Entwicklern geschriebene Code.

Ich denke, wenn wir uns an agile Prinzipien halten, entwerfen wir Muster, verwenden TDD und halten unseren Code sauber. wir sollten gut sein Und was Analyse und Design angeht, sollten meiner Meinung nach einfache UML-Diagramme auf dem Whiteboard den Trick machen. Die Dokumentation ist gut und wichtig, sollte aber so wenig wie möglich gemacht werden und wir sollten uns nicht auf Dokumente konzentrieren und den Code vergessen. Das ist was ich denke.

Hab ich recht? oder sollte ich meinem Arbeitgeber zuhören und nach einem geeigneten CASE-Tool suchen?

Die Situation erfordert eine analytische Herangehensweise an die Entscheidung. Das Fazit lautet: "Bietet das CASE-Tool einen Mehrwert für das Unternehmen?" Häufig möchte das Management, dass Entwickler eine Methodik oder ein Tool anwenden, weil sie gute Dinge darüber gehört haben, unabhängig davon, wie gut es in die aktuellen Prozesse und die Unternehmenskultur passt.

Wenn Ihr Arbeitgeber Sie gebeten hat, sich mit den CASE-Tools zu befassen, sollten Sie sich verpflichten (dies ist ein Problem am Arbeitsplatz, keine Programmierung). Einige Faktoren, die sich auf die Einführung eines CASE-Tools auswirken würden, sind:

• Für welche Ihrer Prozesse stehen CASE-Tools zur Verfügung,
• Eine Schätzung, wie viele Personenstunden erforderlich wären, um das neue Tool bzw. die neuen Tools einzuführen,
• Wie würden sich die Prozesse mit der Einführung der neuen Tools ändern?
• oder Welche positiven (oder negativen) Auswirkungen wären messbar, wenn die neuen Tools übernommen würden?

Stellen Sie sich dies als Gelegenheit vor, Ihre Entwicklungsumgebung und -prozesse zu aktualisieren. Es mag sein, dass Ihre aktuellen Prozesse perfekt zur Kultur Ihres Unternehmens passen, aber Sie sind es Ihrem Arbeitgeber und Ihrem Team schuldig, die entsprechenden Nachforschungen anzustellen.

Ja, Sie sollten mit der Erforschung von CASE-Tools beginnen.

1. Weil Sie Beweise brauchen , um Ihre Behauptung zu untermauern, dass sie nicht helfen werden. Du wirst es nie erfahren, vielleicht wirst du feststellen, dass sie dir helfen werden.
2. Weil Ihr Arbeitgeber es Ihnen gesagt hat.

Ich werde die von David Kaczynski in seiner ausgezeichneten Antwort dargelegten Punkte nicht wiederholen , da dies genau die Schritte sind, denen Sie folgen sollten.

Es scheint tatsächlich ein großer Paradigmenwechsel von Agile zu CASE / MDA-orientierter Entwicklung mit Codegenerierung zu sein. Nicht unbedingt aus Sicht des Projektmanagements (ein CASE-Ansatz widerspricht nicht den Konzepten von Iterationen, User Stories, schnellem Feedback oder kontinuierlicher Verbesserung), aber auf jeden Fall aus Sicht des "Software-Kunsthandwerks" - dies bedeutet weniger Kontrolle über den Code Produzierter, generierter Code, der wahrscheinlich unleserlich, starr, schwerer zu testen und ständig mit dem Modell synchronisiert werden muss, und so weiter.

Nach Ihrer Beschreibung ist das, was Ihr Arbeitgeber benötigt, leicht zu verstehen:

• Bessere Dokumentation, um Wissensverlust zu vermeiden, wenn ein Entwickler das Team verlässt.
• Ein schnellerer Entwicklungsprozess.

Als Software-Experte können (und sollten) Sie ihm auf jeden Fall Ihre Zweifel an der Fähigkeit des CASE-Ansatzes mitteilen, diese Erwartungen zu erfüllen. Es ist auch Ihre Pflicht, sich CASE-Tools anzuschauen, wenn er dies verlangt. Nur eines davon auszuprobieren, bedeutet nicht, dass die Ergebnisse zufriedenstellend sein werden (ich denke insbesondere an den potenziell hohen Code-Generierungs-Overhead, der Konflikte mit der Notwendigkeit einer schnelleren Entwicklung verursacht) und 2, dass dies nicht möglich ist Finden Sie einen Kompromiss, bei dem einige Funktionen des CASE-Tools (Diagramme, Dokumentationserstellung) unter Beibehaltung des vorhandenen agilen Kontexts verwendet werden.

Hier ist ein interessanter Artikel über CASE-Tools in einer agilen Umgebung und ihre möglichen Vor- und Nachteile: http://www.agilemodeling.com/essays/simpleTools.htm

Mein Arbeitgeber (kein Entwickler) ist der Meinung, dass CASE-Tools uns dabei helfen werden, unseren Entwicklungsprozess und unsere Dokumentation zu verbessern. "

Wenn ich als Berater für Ihren Arbeitgeber auftreten würde, wäre ich verpflichtet, zu versuchen, sie davon abzubringen. Zuallererst ist es ein schwerwiegender Verwaltungsfehler, dass Mitarbeiter, die nicht an der Arbeit beteiligt sind, Tools für Entwickler auswählen. Das geht fast nie gut. Es ist mindestens doppelt so schlimm, wenn die Leute, die die Wahl treffen, keinen starken technischen Hintergrund haben. Und wenn sie keine Erfahrung mit den Werkzeugen haben, die sie schieben, ist dies wahrscheinlich ein totales Debakel.

Der wahrscheinlichste Grund, warum diese Art von Dingen vom nicht-technischen Management vorgeschlagen wird, ist, dass jemand versucht, ihnen etwas zu verkaufen. Ein großes Unternehmen, das solche Dinge verkauft, erzielt Umsätze, die in verdünnter Luft wie ein Bleizeppelin sinken. Die Verkäufer (auch bekannt als Wiederverkäufer, Berater), die nicht zu etwas anderem übergegangen sind, versuchen eifrig, neue Marken zu finden, ähm ... Kunden. Einer der Hauptgründe, warum diese Unternehmen Probleme haben, ist, dass diese Art von Werkzeug nicht mehr sehr gefragt ist. Mit "dieser Art von Werkzeugen" meine ich Werkzeuge, die versprechen, "das Schreiben von Code zu eliminieren". An Code ist je nach Sprache nichts auszusetzen. Geschriebener Code enthält weitaus leistungsstärkere Abstraktionen als diese Tools.

Einer der Hauptgründe dafür, dass dies eine so schlechte Art ist, die Entwicklung zu managen, ist, dass der Pool an Mitarbeitern, die Sie für die Personalbesetzung Ihres Teams zur Verfügung haben, erheblich eingeschränkt wird. Zum einen müssen sie diese ungewöhnlichen Tools erlernen, und zum anderen möchten die meisten erfahrenen Entwickler nicht mit diesen Dingen arbeiten. Häufig besteht das Problem bei solchen Tools darin, dass Sie keine wirklich guten Entwickler benötigen, da diese Tools den größten Teil des schweren Hebens erledigen. Das ist völlig falsch. Es ist das Gegenteil. Sie machen all die Dinge, die trivial sind, und erschweren es oft, die nicht trivialen Teile zu tun. Sie eliminieren auch nie wirklich die Notwendigkeit, Code zu schreiben.

Speziell mit CASE-Tools habe ich an drei verschiedenen Orten gearbeitet, die diese Pakete besaßen. In jedem einzelnen ging es so:

1. Das Modell wurde sorgfältig im Werkzeug entworfen. Es dauerte viel länger als normal und es wurden erst sehr spät brauchbare Ergebnisse produziert.
2. Das Modell musste mit Geschäftslogik erweitert werden. Das Modell war falsch und musste in den späten Projektphasen manuell angepasst werden, da der Aufwand so überfällig war.
3. Das erneute Synchronisieren des Modells und des Codes war so kostspielig, dass das CASE-Tool nicht mehr verwendet werden konnte.

Kurz gesagt, es war jeweils ein 100% iger Totalausfall und Geldverschwendung. Wenn ich mit anderen Leuten gesprochen habe, die CASE-Tools in anderen Organisationen verwendet haben, ist die Geschichte immer ungefähr gleich. Ich habe nicht alle diese Tools verwendet und es ist möglich, dass einige Leute sie gut eingesetzt haben, aber ich bin mir ziemlich sicher, dass die meisten Teams, die sie verwendet haben, sie vor langer Zeit nicht mehr verwenden.

Einer der Vorteile, die Sie durch die Untersuchung / Implementierung von CASE-Tools erhalten, besteht darin, dass Sie sich eine besser vermarktbare Qualifikation für eine zukünftige Beschäftigung angeeignet haben. Ich halte viele Ihrer Bedenken für bemerkenswert, aber, wie David Kaczynski hervorhob, handelt es sich hierbei weniger um eine Programmierfrage als vielmehr um eine Frage der Beziehung zwischen Arbeitgeber und Arbeitnehmer. Ein weiterer Vorteil der CASE-Tools besteht darin, dass Ihr Unternehmen nach dem Erlernen in der Lage ist, ein breiteres Spektrum komplexerer Projekte zu übernehmen. Es kann durchaus sein, dass ein Vertrag, den Ihr Arbeitgeber anstrebt, den Einsatz von CASE-Tools erfordert oder bevorzugt.

Sie mischen das Problem und die Lösung und Ihr Chef versucht zu helfen, mit mehr oder weniger Erfolg. Um Ihren Chef herauszufordern, müssen Sie sich klar darüber sein, welche Rolle Sie in der Organisation spielen. Wenn er der CEO ist und Sie der CTO sind, liegt die Entscheidung bei Ihnen und der CEO sollte nur darauf hinweisen, welche geschäftlichen Aspekte von dem Mangel an Dokumentation betroffen sind. Sie sind dann verpflichtet, das Geschäftsproblem mit einem CASE-Tool oder einer anderen von Ihnen vorgeschlagenen Lösung zu lösen.

In Bezug auf den konkreten Vorschlag, CASE-Tools zu verwenden, denke ich, dass Sie ihn richtig auswählen müssen, damit Sie Ihr Ziel erreichen, ohne Ihr Team mit zusätzlicher Arbeit zu überlasten. Wenn Sie die Dokumentation verbessern möchten, steht Ihnen möglicherweise ein Tool zur Verfügung, mit dem Sie Diagramme aus dem Code generieren können, nicht unbedingt, um den Code aus dem grafischen Diagramm zu generieren. Ein Beispiel für ein solches Tool ist Codelogic . Ich habe vor einigen Jahren dafür gesorgt, dass unsere Entwürfe klar und deutlich zu verstehen waren und dass sie recht einfach zu verwenden waren. Wenn Sie, wie Sie Geld ausdrücken, ein weiteres Anliegen sind, können Sie wahrscheinlich in der Open Source suchen (ich kann hier nicht helfen, würde mich aber für das Ergebnis einer Recherche interessieren).

Die Alternative zu CASE-Tools kann ebenfalls hilfreich sein. Durch das Messen von zyklomatischen oder anderen Komplexitätsmessungen bleibt Ihr Design gut strukturiert, und die Entwickler konzentrieren sich auf den Code. Bessere, Javacode-ähnliche Kommentare zu Ihrem Code können ebenfalls zur Verbesserung der Dokumentation beitragen.

Ehrlich gesagt denke ich, wenn Sie bedenken, dass CASE-Tools Ihrem Chef nicht helfen, muss er es wissen. Wenn er ein guter Chef ist, wird er Ihre Meinung schätzen. Ich habe noch nie einen Mitarbeiter gemocht, der einfach das tut, was ihm ohne kritische Analyse gesagt wird. Aber natürlich sollte, wie David vorschlägt, jede Diskussion über starke und objektive Argumente geführt werden.

Ich würde versuchen, Ihrem Arbeitgeber klar zu machen, dass er / sie die Dinge rückgängig gemacht hat. Wenn für das Software-Team Investitionsspielraum besteht, sollten Sie Ihre Engpässe oder Qualitätsprobleme identifizieren. Wenn sich herausstellt, dass Sie in den Bereichen Dokumentation und Entwicklungsprozess am meisten Verbesserungspotenzial haben, sollten Sie ermitteln, welche Änderungen den größten ROI in Bezug auf die Verbesserung dieser Bereiche haben. Das könnte sich herausstellen oder auch nicht, dass CASE-Tools verwendet werden.

Helfen Sie Ihrem Chef, helfen Sie sich

Sie können auf diese Anfrage reagieren oder reagieren.

Erinnerst du dich an alle "Move Mount Fuji" -Fragen? Wenn Sie in einem Interview für einen Job wären, den Sie wirklich wollten, würden Sie dem Interviewer nicht sagen, wie dumm die Frage war, sondern weiterhin Fragen stellen und Ihre besten Ideen zur Lösung ausdrücken. In einigen Kulturen würden Sie niemals Nein zu einem Chef sagen, der Sie tatsächlich gebeten hat, den Berg Fuji zu verschieben, sondern einen Weg finden, wie Sie beide das Gesicht wahren können.

Aktualisieren der Frage

Wenn Sie die Frage in etwas umformulieren würden,

"Kann ich eine Reihe von Tools kaufen oder anderweitig erwerben, mit denen sich so viele Aufgaben mit geringer Produktivität wie möglich im Zusammenhang mit Software automatisieren lassen?"

Diese Aufgabe wird viel schmackhafter. Helfen Sie Ihrem Chef (und sich selbst), indem Sie ihm eine Option mit eindeutiger Rückverfolgbarkeit auf CASE sowie eine oder zwei Optionen auf der Basis von Agile / Open Source / Cloud geben.

FALL überarbeitet

In den 90er Jahren waren CASE-Tools möglicherweise eine Reihe von Tools von Rational, darunter Requisite Pro, Rational Rose, Clear Case, Rational Robot (ein Testläufer), Purify, Pure Coverage und Quantify sowie verschiedene andere Tools das waren zusammen integriert. Wenn Sie ein MAD-Shop (Medizin, Avionik, Verteidigung) waren, können Sie aktualisierte Versionen dieser Tools verwenden, um umfangreiche und nachvollziehbare Dokumentationen und Artefakte zu erstellen, die Kunden in diesen Märkten häufig benötigen.

Wenden Sie sich an IBM und lassen Sie sich von einem Verkäufer ein Angebot für fünf Lizenzen (oder nur eine Floating-Lizenz) erstellen. Fügen Sie in etwas Training auch hinzu. Wenn Sie dieses Zitat mit Ihrem Vorgesetzten teilen, wird das Gespräch über CASE-Tools möglicherweise beendet. Aber versteh mich nicht falsch. Ich mag Rational, ihre Chefwissenschaftler und ihre Produkte, habe sie jedoch hauptsächlich über Standortlizenzen der Universität in Anspruch genommen, weil ihr Preis für die Unternehmen, in denen ich gearbeitet habe, zu hoch war. Wenn Sie, zumindest aus meiner Erfahrung, anerkannt sind, werden sie Ihr Recht mit guter Unterstützung und qualitativ hochwertigem Training behandeln (normalerweise in einem Top-Resort mit großartigem Essen).

Werkzeuge zum Verkauf

Sie haben immer noch eine großartige Möglichkeit, Werkzeuge einzukaufen. Agile Entwickler benötigen ebenfalls Tools. Sie können eine Suite kaufen, die Dokumentationsunterstützung für Online-Storycards, Anwendungsfälle, Anwendungsfälle und andere UML-Diagrammtypen bietet. Atlassian hat, wie ich finde, eine nette Suite von Tools - Jira für die Verfolgung von Aufgaben und Fehlern, Green Hopper für das, was sie als agiles Projektmanagement bezeichnen, Confluence für ein Intranet-Wiki, Crucible für die Online-Codeüberprüfung und Bamboo für einen Server für die kontinuierliche Integration. Für diese und andere Tool-Suites gibt es Software-as-a-Service-Lizenzen, die auf Ihre Bedürfnisse zugeschnitten sind, wenn Sie agil sind.

Die IDE-Integration ist ein weiterer Weg, um ein Jahr 2012 CASE-Äquivalent zu erhalten. Wenn Sie ein Microsoft-Entwickler sind, verfügt Visual Team Studio über Tools, deren Umfang dem von Rational erstellten ähnelt. Sie verfügen über Round-Trip-Software-Engineering, Generierung von Unit-Test-Stubs aus Klassen, Integration in Quellcodeverwaltungssysteme und eine Reihe von Tools für die Teamzusammenarbeit.

Open Source Tools

Auf der Open-Source-Seite versuchen Eclipse und seine vielen Plug-Ins, eine Reihe von Open-Source-Tools zu integrieren. Ich bin mir nicht sicher, ob Eclipse Modeling Framework ausgereift ist oder ob es andere Tools gibt, die einen effektiven Roundtrip-Softwareentwickler bieten, aber das letzte Mal, als ich nachgesehen habe, schien es nicht sehr einfach zu sein. Die Qt Creator-Umgebung ist in die Quellcodeverwaltung integriert und verfügt über einige Funktionen, mit denen Sie die Codeabdeckung von Änderungen überprüfen können, während Sie sich im Editor befinden.

Iterative inkrementelle Tool-Übernahme

Ein iterativer / inkrementeller Ansatz zur Werkzeugauswahl kann ebenfalls sehr effektiv sein. Open Source-Projekte unterstützen häufig einzelne oder mehrere Umgebungen. Ihre Werkzeugauswahl kann durch die von Ihnen verwendeten Stapel beeinflusst werden. Es gibt nie einen guten Zeitpunkt, um die Entwicklung vollständig zu beenden. Das Hinzufügen und Trainieren des Teams in ein paar kleineren Tools pro Quartal ist daher möglicherweise besser als ein Big-Bang-Ansatz, der alles auf einmal ändert.

Cloud-Tool-Lösungen

Viele der aufgeführten Lösungen erfordern möglicherweise Server und eine relativ komplexe Einrichtung. Es gibt viele Optionen auf dem Markt, die Cloud-basiert sind und Software als Service anbieten, der von einem Anbieter gegen eine monatliche Gebühr gehostet wird. Dies kann für Ihr Team kurz- oder langfristig sinnvoll sein. Einige haben möglicherweise eine gehostete Lösung, mit der Sie schnell loslegen und später Lizenzen erwerben können.

Keiner dieser Vorschläge ist ein kostengünstiger und einfacher Weg zur sofortigen Produktivitätssteigerung, aber wenn Sie einige der Werkzeuge einmal ausprobiert haben, sind sie möglicherweise unverzichtbar.

Eine Sache, die ich zu den hervorragenden Antworten hinzufügen möchte, ist, dass Sie möglicherweise davon profitieren, wenn Sie verstehen, wie Sie "Ihren Entwicklungsprozess verbessern" möchten.

Der überwältigende Trend der letzten 20 Jahre bestand darin, die Softwareentwicklung für die Markteinführung zu optimieren. "Agile", "Lean", DevOps, TDD, BDD - alles dreht sich darum, hochwertige Software so schnell wie möglich auf den Markt zu bringen.

CASE-Tools haben keine Markteinführungszeit. Sie konzentrieren sich auf Rückverfolgbarkeit, Designkonsistenz, Vollständigkeit des Modells usw. Dies sind alles wertvolle Aspekte - insbesondere in Bankensystemen - aber sie gehen zu Lasten der Markteinführungszeit.

Fragen Sie Ihren Chef vielleicht genau, was er optimieren möchte.

Erfahrungsgemäß wird die Arbeit mit CASE-Tools schneller schwieriger als die Arbeit mit Code - insbesondere bei Problemdomänen, die mehr als durchschnittlich komplex sind. Das Projekt hört auf, ein "Bank" -Projekt zu sein, und wird stattdessen zu einem "Insert Name of CASE Tool Here" -Projekt.