Czy powinienem słuchać mojego pracodawcy i korzystać z narzędzi CASE?

Mój pracodawca (nie programista) uważa, że ​​narzędzia CASE pomogą nam ulepszyć proces rozwoju i dokumentację. Nie jestem tego pewien, jesteśmy małym zespołem 5 programistów tworzących rozwiązania bankowości mobilnej dla lokalnych klientów. Myślę, że narzędzia CASE będą stratą czasu i pieniędzy, ponieważ trzeba je zakupić i potrzebujemy trochę czasu, zanim się do nich przyzwyczaimy i będziemy efektywnie pracować z nimi przy modelowaniu i tym podobne. Generowanie kodu to kolejny problem, naprawdę uważam, że kod wygenerowany przez CASE nie będzie tak dobry, jak kod napisany przez dobrych programistów.

Myślę, że jeśli trzymamy się zwinnych zasad, wzorców projektowych, używamy TDD i utrzymujemy nasz kod w czystości. powinniśmy być dobrzy. A jeśli chodzi o analizę i projektowanie, uważam, że proste diagramy UML na tablicy powinny załatwić sprawę. Dokumentacja jest dobra i ważna, ale powinna być wykonywana w jak najmniejszym stopniu i nie powinniśmy koncentrować się na Dokumentach i zapominać o kodzie. To jest to, co myślę.

Mam rację? czy powinienem wysłuchać mojego pracodawcy i zacząć szukać odpowiedniego narzędzia CASE?

Sytuacja uzasadnia analityczne podejście do decyzji. Najważniejsze pytanie brzmi: „Czy narzędzie CASE zapewnia wartość dla firmy?” Często kierownictwo chce, aby programiści przyjęli metodologię lub narzędzie, ponieważ słyszeli o nim dobre rzeczy, niezależnie od tego, jak dobrze wpasowuje się w bieżące procesy i kulturę organizacji.

Jeśli twój pracodawca poprosił cię o sprawdzenie narzędzi CASE, jak podkreśla ChrisF, powinieneś się zobowiązać (jest to problem w miejscu pracy, a nie programowanie). Niektóre czynniki, które mogłyby wpłynąć na przyjęcie narzędzia CASE to:

• Dla których procesów są dostępne narzędzia CASE,
• Szacunkowa liczba osobogodzin potrzebnych na przyjęcie nowego narzędzia (nowych narzędzi),
• Jak zmieniłby się proces (y) wraz z przyjęciem nowych narzędzi (narzędzi),
• lub Jaki pozytywny (lub negatywny) wpływ byłby mierzalny po przyjęciu nowych narzędzi

Potraktuj to jako okazję do ulepszenia środowiska programistycznego i procesów. Być może twoje obecne procesy idealnie pasują do kultury Twojej organizacji, ale jesteś winien swojemu pracodawcy i zespołowi przeprowadzenie odpowiednich badań.

Tak, powinieneś zacząć szukać narzędzi CASE.

1. Ponieważ potrzebujesz dowodów na poparcie swojego twierdzenia, że ​​nie pomogą. Nigdy nie wiadomo, może się okazać, że ci pomogą.
2. Ponieważ twój pracodawca kazał ci to zrobić.

Nie będę powtarzał punktów przedstawionych przez Davida Kaczyńskiego w jego doskonałej odpowiedzi, ponieważ są to dokładnie kroki, które należy wykonać.

Wygląda na to, że istotną zmianą paradygmatu jest zręczne projektowanie zorientowane na CASE / MDA z generowaniem kodu. Niekoniecznie z punktu widzenia zarządzania projektami (podejście CASE nie będzie sprzeczne z koncepcjami iteracji, historii użytkowników, szybkich informacji zwrotnych lub ciągłego doskonalenia), ale zdecydowanie tak z perspektywy „kunsztu programistycznego” - oznacza to mniejszą kontrolę nad kodem wytworzony, wygenerowany kod, który prawdopodobnie będzie nieczytelny, sztywny, trudniejszy do przetestowania, stale potrzebuje synchronizacji z modelem i tak dalej.

Z tego, co opisujesz, potrzeby pracodawcy są łatwo zrozumiałe:

• Lepsza dokumentacja, aby uniknąć utraty wiedzy, gdyby programista opuścił zespół.
• Szybszy proces rozwoju.

Jako profesjonalista oprogramowania zdecydowanie możesz (i powinieneś) powiedzieć mu o swoich wątpliwościach co do zdolności CASE do spełnienia tych oczekiwań. Twoim obowiązkiem jest również zacząć przeglądać narzędzia CASE, jeśli tego zażąda. Samo wypróbowanie jednego z nich nie oznacza 1 / że wyniki będą satysfakcjonujące (szczególnie myślę o potencjalnie dużym obciążeniu generowania kodu, który koliduje z potrzebą szybszego rozwoju) i 2 / że nie możesz znaleźć kompromis, w którym niektóre funkcje narzędzia CASE (diagramy, generowanie dokumentacji) zostaną wykorzystane przy zachowaniu istniejącego zwinnego kontekstu.

Oto ciekawy artykuł na temat narzędzi CASE w środowisku Agile i ich możliwych zaletach / wadach: http://www.agilemodeling.com/essays/simpleTools.htm

Mój pracodawca (nie programista) uważa, że ​​narzędzia CASE pomogą nam ulepszyć proces rozwoju i dokumentację ”.

Gdybym miał działać jako konsultant dla twojego pracodawcy, musiałbym spróbować odwieść ich od tego rodzaju spraw. Przede wszystkim poważnym błędem w zarządzaniu jest to, że ludzie, którzy nie są zaangażowani w pracę, wybierają narzędzia dla programistów. To prawie nigdy nie idzie dobrze. Jest co najmniej dwa razy gorszy, gdy ludzie dokonujący wyboru nie mają silnego zaplecza technicznego. A jeśli nie mają żadnego doświadczenia z narzędziami, które pchają, prawdopodobnie będzie to całkowity upadek.

Najbardziej prawdopodobnym powodem, dla którego takie zarządzanie jest sugerowane przez nietechniczne kierownictwo, jest to, że ktoś próbuje coś im sprzedać. Jedna z dużych firm, która sprzedaje tego rodzaju rzeczy, ma przychody, które spadają jak zeppelin ołowiu w rzadkim powietrzu. Sprzedawcy (czyli odsprzedawcy, konsultanci), którzy nie przeszli do czegoś innego, wściekle próbują znaleźć nowe marki, eee ... klienci. Jednym z głównych powodów, dla których firmy zmagają się z tym problemem, jest to, że nie ma już dużego zapotrzebowania na tego rodzaju narzędzia. Przez „tego rodzaju narzędzia” rozumiem narzędzia, które obiecują „wyeliminować pisanie kodu”. W zależności od języka nie ma nic złego w kodzie. Napisany kod ma znacznie potężniejsze abstrakcje niż to, co oferują te narzędzia.

Jednym z głównych powodów, dla których jest to tak kiepski sposób zarządzania rozwojem, jest to, że poważnie zmniejszy pulę osób, z których można skorzystać, aby obsadzić zespół. Po pierwsze, muszą nauczyć się tych niezwykłych narzędzi, a po drugie, najbardziej doświadczeni programiści nie chcą pracować z tymi rzeczami. Często wokół tego rodzaju narzędzi jest tak, że tak naprawdę nie potrzebujesz dobrych programistów, ponieważ te narzędzia wykonują większość ciężkiego podnoszenia. To jest całkowicie fałszywe. Jest odwrotnie. Robią wszystkie rzeczy, które są trywialne i często utrudniają wykonywanie nietrywialnych części. Nigdy tak naprawdę nie eliminują potrzeby pisania kodu.

W szczególności z narzędziami CASE pracowałem w trzech różnych miejscach, które były właścicielami tych pakietów. W każdym z nich wyglądało to tak:

1. Model został starannie zaprojektowany w narzędziu. Trwało to znacznie dłużej niż zwykle i nie wyprodukowano żadnych użytecznych materiałów eksploatacyjnych aż do bardzo późnego wysiłku.
2. Model musiał zostać uzupełniony o logikę biznesową. Model był nieprawidłowy i musiał zostać ręcznie ulepszony w późnych fazach projektu, ponieważ wysiłek był tak opóźniony.
3. Ponowna synchronizacja modelu i kodu była na tyle kosztowna, że ​​narzędzie CASE zostało odłożone na półkę i nigdy więcej nie będzie używane.

Krótko mówiąc, w każdym przypadku była to 100% całkowita porażka i strata pieniędzy. Kiedy rozmawiałem z innymi osobami, które korzystały z narzędzi CASE w innych organizacjach, historia jest zawsze taka sama. Nie korzystałem z wszystkich tych narzędzi i możliwe, że niektórzy dobrze z nich skorzystali, ale jestem całkiem pewien, że większość zespołów, które ich używały, już dawno przestały ich używać.

Jedną z korzyści, które można uzyskać dzięki badaniu / wdrażaniu narzędzi CASE, jest to, że nabyłeś zestaw umiejętności bardziej zbywalnych do przyszłego zatrudnienia. Myślę, że wiele waszych obaw jest godnych uwagi, ale, jak zauważył David Kaczyński, nie jest to kwestia programowa, lecz kwestia relacji pracodawca / pracownik. Kolejną zaletą narzędzi CASE jest to, że po nauce Twoja firma będzie w stanie podjąć szerszy zakres projektów o większej złożoności. Może się zdarzyć, że umowa, którą chce uzyskać Twój pracodawca, lub preferuje użycie narzędzi CASE.

Mieszasz problem i rozwiązanie, a twój szef próbuje pomóc, z większym lub mniejszym sukcesem. Aby rzucić wyzwanie swojemu szefowi, musisz jasno określić swoją rolę w organizacji. Jeśli jest on CEO, a ty CTO, decyzja należy do Ciebie, a CEO powinien po prostu wskazać, na jakie aspekty biznesowe wpływa brak dokumentacji. Twoim obowiązkiem będzie wówczas rozwiązanie problemu biznesowego za pomocą narzędzia CASE lub innego rozwiązania, które znajdziesz.

Jeśli chodzi o konkretną sugestię użycia narzędzi CASE, myślę, że musisz wybrać ją właściwie, aby osiągnąć swój cel bez przeciążania swojego zespołu dodatkową pracą. Jeśli dokumentacja jest tym, co chcesz poprawić, możesz mieć dość narzędzia, które jest w stanie generować diagramy z kodu, niekoniecznie generując kod z diagramu graficznego. Przykładem takiego narzędzia jest Codelogic . Użyłem kilka lat temu, aby upewnić się, że nasze projekty są czyste i jasne, aby można je było zrozumieć i że są dość łatwe w użyciu. Jeśli wyrażanie pieniędzy jest kolejnym problemem, prawdopodobnie możesz zajrzeć do otwartego oprogramowania (nie mogę tutaj pomóc, ale byłbym zainteresowany wynikami jakichkolwiek badań).

Pomocna może być również alternatywa dla narzędzi CASE. Pomiary takie jak cykliczne lub inne miary złożoności utrzymają dobrą strukturę projektu, a programiści skupią się na kodzie. Lepsze komentarze do twojego kodu, podobne do Javacode, mogą również pomóc w ulepszeniu dokumentacji.

Szczerze mówiąc, myślę, że jeśli uważasz, że narzędzia CASE nie pomagają Twojemu szefowi to wiedzieć. Jeśli jest dobrym szefem, doceni twoje zdanie. Nigdy nie lubiłem pracownika, który po prostu robi to, co mu powiedzą, bez krytycznej analizy. Oczywiście, jak sugeruje David, każda dyskusja powinna opierać się na mocnych i obiektywnych argumentach.

Staram się, aby twój pracodawca zdał sobie sprawę, że on / ona dostał rzeczy wstecz. Jeśli zespół programistów ma miejsce na inwestycje, powinieneś zidentyfikować swoje wąskie gardła lub problemy z jakością. JEŻELI okaże się, że masz najwięcej miejsca na udoskonalenie dokumentacji i obszarów procesu programowania, powinieneś określić, jakie zmiany mają największy zwrot z inwestycji w zakresie poprawy tych obszarów. To może, ale nie musi, zacząć używać narzędzi CASE.

Pomóż swojemu szefowi, pomóż sobie

Możesz zareagować lub zareagować na tę prośbę.

Pamiętasz wszystkie pytania „Move Mount Fuji”? Jeśli byłeś na rozmowie kwalifikacyjnej o pracy, którą naprawdę chciałeś, nie powiedziałbyś ankieterowi, jak głupie było to pytanie, ale wciąż zadawałeś pytania i wyrażałeś swoje najlepsze pomysły na jego rozwiązanie. W niektórych kulturach nigdy nie powiedziałbyś „nie” szefowi, który faktycznie poprosił cię o przeniesienie Góry Fuji, ale znalazłbyś dla siebie sposób na uratowanie twarzy.

Przeformułowanie pytania

Jeśli miałbyś przekształcić pytanie w coś takiego,

„Czy mogę kupić lub w inny sposób nabyć zestaw narzędzi automatyzujących jak najwięcej zadań o niskiej produktywności związanych z oprogramowaniem?”

zadanie to staje się o wiele smaczniejsze. Pomóż swojemu szefowi (i sobie), dając mu opcję z wyraźną identyfikowalnością CASE oraz jedną lub dwie opcje oparte na Agile / open source / cloud.

CASE Znowu odwiedzono

W latach 90. narzędzia CASE mogły przybrać formę zestawu narzędzi firmy Rational, które prawdopodobnie obejmowały Requisite Pro, Rational Rose, Clear Case, Rational Robot (test runner), Purify, Pure Coverage i Quantify oraz kilka innych narzędzi które zostały zintegrowane razem. Jeśli prowadziłeś sklep MAD (medyczny, awioniczny, obronny), możesz użyć zaktualizowanych wersji tych narzędzi do tworzenia obszernej i możliwej do śledzenia dokumentacji i artefaktów, które są często wymagane przez klientów na tych rynkach.

Skontaktuj się z IBM i poproś sprzedawcę o wycenę pięciu licencji (lub tylko jednej licencji swobodnej). Dodaj też trochę treningu. Dzielenie się tym cytatem ze swoim menedżerem może zakończyć rozmowę o narzędziach CASE. Ale nie zrozum mnie źle. Lubię Rational, ich głównych naukowców i ich produkty, ale uzyskiwałem do nich dostęp głównie za pośrednictwem licencji uniwersyteckich, ponieważ ich cena była zbyt wysoka dla firm, w których pracowałem. Jeśli zostaniesz zatwierdzony, przynajmniej z mojego doświadczenia, będą traktować twoje prawo z dobrym wsparciem, wysokiej jakości szkoleniem (zwykle w najlepszym ośrodku ze wspaniałym jedzeniem).

Narzędzia na sprzedaż

Nadal masz świetną okazję na zakupy narzędzi. Zwinni programiści również potrzebują narzędzi. Możesz kupić pakiet, który zapewnia obsługę dokumentacji dla kart historii online, przypadków użycia, przypadku użycia i innych typów diagramów UML. Atlassian ma coś, co uważam za ładny zestaw narzędzi - Jira do śledzenia zadań i błędów, Green Hopper do tego, co określają jako zwinne zarządzanie projektami, Confluence dla intranetowej wiki, Crucible do przeglądania kodu online i Bamboo dla serwera ciągłej integracji. Istnieje oprogramowanie jako licencje serwisowe dla tych i innych pakietów narzędzi dostosowane do twoich potrzeb, jeśli jesteś zwinny.

Integracja z IDE to kolejna droga do uzyskania odpowiednika CASE z 2012 roku. Jeśli jesteś domem programistów Microsoft, Visual Team Studio ma narzędzia o podobnym zakresie do tego, co stworzył Rational. Mają trochę inżynierii oprogramowania w obie strony, generowanie odcinków testów jednostkowych z klas, integrację z systemami kontroli źródła oraz szereg narzędzi do współpracy w zespole.

Narzędzia Open Source

Po stronie open source, Eclipse i jego wiele wtyczek próbuje zintegrować kilka narzędzi typu open source. Nie jestem pewien, czy Eclipse Modeling Framework jest dojrzały czy istnieją inne narzędzia, które dają skutecznego inżyniera oprogramowania w obie strony, ale kiedy ostatnio patrzyłem, nie było to łatwe do osiągnięcia. Środowisko Qt Creator integruje się z kontrolą źródła i ma pewne funkcje, które pomagają w sprawdzaniu na miejscu po pokryciu zmian kodu podczas pracy edytora.

Iteracyjne Przyrostowe Przyjęcie Narzędzia

Iteracyjne / przyrostowe podejście do wyboru narzędzia może być również bardzo skuteczne. Projekty open source często obsługują jedno lub wiele środowisk. Stosowane przez ciebie stosy mogą zależeć od wyboru narzędzi. Nigdy nie jest dobry czas, aby całkowicie zamknąć rozwój, więc dodanie i przeszkolenie zespołu w kilku mniejszych narzędziach na kwartał może być lepsze niż podejście z wielkim wybuchem, które zmienia wszystko na raz.

Rozwiązania chmurowe

Wiele wymienionych rozwiązań może wymagać serwerów i stosunkowo złożonej konfiguracji. Na rynku pojawia się wiele opcji opartych na chmurze i zapewniających oprogramowanie jako usługę hostowaną przez dostawcę za miesięczną opłatą. Może to mieć sens dla twojego zespołu, krótko- lub długoterminowego. Niektóre mogą mieć hostowane rozwiązanie, którego można użyć do szybkiego uruchomienia, z opcją zakupu licencji później.

Żadna z tych sugestii nie jest niedrogą i łatwą drogą do natychmiastowej poprawy wydajności, ale jeśli okaże się, że niektóre narzędzia są niezbędne po wypróbowaniu.

Dodam tutaj do doskonałych odpowiedzi, że możesz skorzystać ze zrozumienia, w jaki sposób chcesz „usprawnić proces rozwoju”.

W ciągu ostatnich 20 lat dominującym trendem była optymalizacja rozwoju oprogramowania na czas wprowadzania na rynek. „Agile”, „lean”, DevOps, TDD, BDD - chodzi o to, aby jak najszybciej uzyskać wysokiej jakości oprogramowanie.

Narzędzia CASE to nie czas na wprowadzenie na rynek. Koncentrują się na identyfikowalności, spójności projektu, kompletności modelu itp. Są to wszystkie cenne aspekty - szczególnie w systemach bankowych - ale są one kosztem czasu na wprowadzenie na rynek.

Więc może zapytaj szefa, co dokładnie optymalizuje.

Z doświadczenia wynika, że ​​praca z narzędziami CASE szybko staje się trudniejsza niż praca z kodem - szczególnie podczas pracy z domenami problemów, które są bardziej niż średnio skomplikowane. Projekt przestaje być projektem „bankowym”, a zamiast tego staje się projektem „wstaw-nazwę-CASE-narzędzie-tutaj”.