Czy tworzenie oprogramowania jest dyscypliną inżynieryjną?

Czy rozwój oprogramowania można uznać za inżynierię? Jeśli nie, to jakich rzeczy brakuje, aby zostać zakwalifikowanym jako dyscyplina inżynierska? Powiązane z tym jest pytanie dotyczące przepełnienia stosu dotyczące różnicy między programistą a inżynierem oprogramowania .

Istnieje Instytut Inżynierii Oprogramowania na Carnigie Mellon University, który przepisuje i utrzymuje standardy CMMI. Czy to coś, co zmieni rozwój w inżynierię?

Czy inżynieria tworzenia oprogramowania? Jeśli nie, to jakich rzeczy brakuje, aby zostać zakwalifikowanym?

Tak, inżynieria oprogramowania to dziedzina inżynierii.

Wikipedia definiuje inżynierię jako „zastosowanie matematyki, a także wiedzy naukowej, ekonomicznej, społecznej i praktycznej w celu wymyślania, innowacji, projektowania, budowania, utrzymywania, badania i ulepszania konstrukcji, maszyn, narzędzi, systemów, komponentów, materiałów , procesy, rozwiązania i organizacje ”. Rezultatem inżynierii oprogramowania jest system oprogramowania, który może poprawić życie ludzi i może obejmować połączenie wiedzy naukowej, matematycznej, ekonomicznej, społecznej lub praktycznej.

Pod względem tego, jak jest postrzegany, pod względem naukowym i zawodowym, jest różny. Programy inżynierii oprogramowania mogą być akredytowane przez ABET jako programy inżynierskie. Inżynierowie oprogramowania mogą być członkami IEEE. Niektóre firmy uważają inżynierię oprogramowania za dyscyplinę inżynieryjną, podczas gdy inne nie - to naprawdę rzucanie się w oczy.

Najlepszą książką na ten temat jest profesjonalny rozwój oprogramowania Steve'a McConnella: krótsze harmonogramy, produkty wyższej jakości, więcej udanych projektów, ulepszone kariery . Wygląda na inżynierii oprogramowania jako zawodu, ewolucja od jednostki pływającej do zawodu, nauka o rozwoju oprogramowania, różnica między oprogramowania inżynierii i oprogramowania inżynierii (stosujące praktyki inżynierii oprogramowania w porównaniu z inżynierów, którzy akurat oprogramowania kompilacji ze studium przypadku, obejmuje moją alma mater ), certyfikację i licencje oraz etykę.

Glenn Vanderburg przeprowadził serię rozmów pod tytułem „Real Software Engineering”, które wygłosił w latach 2010–2015 na wielu konferencjach, a także dwie powiązane rozmowy: „Rzemiosło, inżynieria i esencja programowania” (podane w 2011 r. Jako keynote at RailsConf) oraz „Craft and Software Engineering” (dane w 2011 roku w QCon London). Myślę, że te rozmowy są dość kompleksowym argumentem przemawiającym za tym, dlaczego inżynieria oprogramowania jest dyscypliną inżynieryjną.

Jednym z argumentów, które Vanderburg krótko porusza w swoich rozmowach, jest argument Jacka W. Reevesa z 1992 r. (I ponownie zrewidowany w 2005 r.) Na temat tego, czym jest projektowanie oprogramowania i jak kod jest rezultatem działań związanych z projektowaniem inżynierii oprogramowania ( jest to również omówione na wiki wiki C2). Kiedy odejdziesz od starszych szkół myślenia, w których specyfikacja i modelowanie jest projektowaniem oprogramowania, a kodem jest projektowanie oprogramowania, niektóre związki między inżynierią oprogramowania i innymi dyscyplinami inżynierii stają się bardziej widoczne. Niektóre różnice i przyczyny tych różnic stają się jeszcze bardziej widoczne, gdy zobaczysz, że ekonomia tworzenia oprogramowania jest znacznie inna niż w wielu innych dyscyplinach - konstrukcja jest tania (w wielu przypadkach prawie darmowa), a projektowanie jest kosztowne.

Czy to [CMMI] przekształci rozwój w inżynierię?

Nie. CMMI to struktura doskonalenia procesów, która dostarcza wskazówek dla organizacji, jakie rodzaje działań są przydatne przy tworzeniu oprogramowania. Dyscypliny inżynierskie zazwyczaj mają proces inżynieryjny. Posiadanie takiego procesu jest ważne dla pomyślnego zakończenia projektów wysokiej jakości. To powiedziawszy, CMMI (lub jakakolwiek inna struktura procesu lub metodologia) to tylko jedno narzędzie - użycie go nie spowoduje magicznego przejścia od programisty do inżyniera. Jednak nie przestrzeganie jakiegoś procesu jest moim zdaniem oznaką projektu, który nie jest projektem inżynieryjnym.

Jakie jest twoje zdanie na temat kursów / certyfikatów inżynierii oprogramowania?

To tylko tyle wartości, ile wkładają w to inni ludzie. Są przydatne kursy i są bezużyteczne kursy. Są cenne certyfikaty i certyfikaty, które nie są warte papieru, na którym są drukowane. Istnieje wiele czynników, od tego, kto popiera kurs lub akredytuje go, lub kto wydaje certyfikat twojej obecnej branży zatrudnienia na obecną pracę i gdzie chcesz się udać.

Pochodzę z typowego doświadczenia inżynieryjnego, ale robię karierę w tworzeniu oprogramowania, widzę duże podobieństwa między oboma światami. Oprócz być może dokładnej definicji inżynierii, w praktyce widzę, że tworzenie oprogramowania nie różni się tak bardzo od tworzenia fizycznego produktu. Przynajmniej uważam, że nie powinno być inaczej.

Niezależnie od tego, czy projektujesz samolot, czy aplikację, oba muszą:

• robić projekty
• zdefiniuj podsystemy i komponenty
• tworzyć prototypy
• określić i wykonać testy
• itp.

Przeczytałem gdzieś w innej odpowiedzi, że projektowanie oprogramowania jest inne, ponieważ nie projektujesz wszystkiego przed rozpoczęciem programowania. Właściwie w mniejszym stopniu dotyczy to również projektowania fizycznego produktu. Projektowanie, prototypowanie i testowanie jest procesem iteracyjnym.

Również w miarę powiększania się projektów oprogramowania coraz ważniejsze staje się definiowanie przejrzystych podsystemów, komponentów i interfejsów, co jest podobne do projektowania złożonych produktów, takich jak samolot.

Dlatego uważam, że tworzenie oprogramowania to inżynieria.

Twierdziłbym, że rzeczywiście istnieje coś takiego jak inżynieria oprogramowania.

Inżynieria polega na systematycznym stosowaniu wiedzy naukowej do rozwiązywania problemów. Złożoność problemów, które są obecnie rozwiązywane, nie różni się tak bardzo od tych, z którymi boryka się inżynier elektryk przy tworzeniu obwodu lub inżynier chemik przy opracowywaniu procesu produkcyjnego lub inżynier mechanik przy tworzeniu urządzenia.

Fakt, że istnieje również praktyczne podejście do stosowania istniejących planów (w tym przypadku rozwój) jest po prostu podobny do faktu, że w innych dziedzinach ktoś inny wykonuje te plany (np. Pracownik budowlany).

Prawdą jest, że większość programistów wykonuje również zadania związane z inżynierią oprogramowania, a nasza edukacja często nie polega na programowaniu, ale raczej na inżynierii oprogramowania. Więc brudzimy sobie ręce, podczas gdy inżynier lądowy nie.

Jednak umiejętność zastosowania języka programowania i programu nie zmienia go w inżyniera: spotkałem się z moją grupą programistów, którzy nie rozumieją złożoności i problemów poza ich obecnym fragmentem kodu.

Jeśli chodzi o twoje pytanie dotyczące CMU: zastosowanie standardu lub praktyki (np. CMMI) nie zmienia automatycznie pracy osoby w inżynierię. Jednak fakt, że istnieją organizacje prowadzące badania naukowe w celu dostarczenia nowych praktyk, jest ponownie znakiem, że istnieje coś takiego jak inżynieria.

Nie, to nie jest inżynieria. Nie jesteśmy tak naukowi i nie musimy przechodzić żadnego z tych państwowych testów inżynieryjnych. W rzeczywistości jest nielegalne nazywanie się „inżynierem” oprogramowania w niektórych miejscach z powodu tego braku testowania.

IMHO termin „inżynieria oprogramowania” został wymyślony, aby spróbować lepiej opisać zakres rzeczy, które robi programista, a nie tylko „programista” (który ma podteksty niektórych procesów mechanistycznych przy niewielkim namysłu i kreatywności).

Osobiście wolę pojawiającą się analogię dewelopera jako „rzemieślnika”, popieranego między innymi przez pragmatycznych programistów.

Historycznie ludzie próbowali analogizować tworzenie oprogramowania do produkcji. Myślę, że Jack Reeves dość dobrze argumentował, by zdyskredytować ten pomysł w swoim artykule What Is Software Design .

Z Wiki:

Inżynieria :

Inżynieria oprogramowania polega na stosowaniu systematycznego, zdyscyplinowanego i wymiernego podejścia do rozwoju, działania i konserwacji oprogramowania oraz na badaniu tych podejść; to znaczy zastosowanie inżynierii do oprogramowania.

Rozwój oprogramowania

Rozwój oprogramowania to zestaw działań, które prowadzą do powstania oprogramowania. Rozwój oprogramowania może obejmować badania, nowe prace rozwojowe, modyfikacje, ponowne użycie, przeprojektowanie, konserwację lub wszelkie inne działania prowadzące do powstania oprogramowania. [1]

Szczególnie pierwszy etap procesu tworzenia oprogramowania może obejmować wiele działów, w tym marketing, inżynierię, badania i rozwój oraz ogólne zarządzanie.

Są więc bardzo podobne i mogą oznaczać to samo.

Od Dictionary.com: en · gi · neer · ing / ˌɛndʒəˈnɪərɪŋ /

– Rzeczownik 1. sztuka lub nauka praktycznego zastosowania wiedzy o naukach ścisłych, takich jak fizyka lub chemia, jak w budowie silników, mostów, budynków, kopalni, statków i zakładów chemicznych.

Powiedziałbym, że tworzenie oprogramowania to praktyczne zastosowanie matematyki i informatyki oraz potencjalnie dowolnej innej liczby nauk ścisłych w zależności od zastosowania.

[EDYCJA] FWIW, nie nazywam siebie inżynierem oprogramowania, ale programistą, więc nie mam osobistego udziału w tym.

Moim zdaniem inżynier oprogramowania i programista to dwie różne rzeczy.

Widzę inżyniera oprogramowania jako takiego, który planuje, na przykład jaki cykl życia zajmie rozwój, wykonując wymagania / specyfikacje itp. Zasadniczo inżynier oprogramowania zajmuje się dużą ilością dokumentacji. Może tego dokonać programista i / lub kierownik projektu.

Programista będzie bardziej zbliżona do programisty, ale z większą ilością umiejętności w innych dziedzinach, jak zarządzanie bazami danych, itp ..

Jedną interesującą rzeczą do poruszenia jest architektura . Ktoś, kto jest również zaangażowany w ustalenie, jaki sprzęt / oprogramowanie będzie potrzebne w cyklu życia projektu.

Idę tutaj z „Nie”. Mój brat jest inżynierem mechanikiem i opisuje inżynierię jako „The Art of Being Cheap”:

„Inżynierowie są bardziej zainteresowani wykonywaniem zadań tak szybko, jak to możliwe, przy możliwie najniższych kosztach i przy jak najmniejszej liczbie materiałów ”.

W odpowiedzi zacząłem opisywać tworzenie oprogramowania (nie inżynieria oprogramowania - tak naprawdę są to zasadniczo dwie odrębne dziedziny) jako „The Art of Being Efficient”:

„Deweloperzy są bardziej zainteresowani wykonaniem zadań tak szybko, jak to możliwe, przy możliwie najniższych kosztach i możliwie najmniejszej liczbie powtórzeń ”.

Różnica polega na ostatniej części tych zdań.

Czy inżynieria tworzenia oprogramowania?

Nie. Bycie inżynierem oznacza, że ​​Twój projekt postępuje zgodnie z harmonogramem przyczynowo-skutkowym - przestrzegasz kodeksów budynków, dlatego Twój budynek nie upada (a przynajmniej nie można winić, jeśli tak jest). Pisząc oprogramowanie, możesz postępować zgodnie ze wszystkimi wskazówkami (i jest tak wiele różnych do wyboru!), A mimo to może się zawiesić / zawiesić / dać błędne odpowiedzi (chyba że jesteś zaangażowany w niezwykle małą dziedzinę pisania sprawdzalnych programów po stronie -skuteczne języki funkcjonalne).

Widzę inżyniera (mechanika, konstruktor, oprogramowanie) jako osobę, która projektuje wcześniej produkt w oparciu o zrozumiałe potrzeby i rozumie, co i jak zastosować materiały, aby je zaspokoić.

Na przykład często możesz zobaczyć inżyniera budowlanego, który szuka różnych wytrzymałości stali i stosuje reguły fizyki do obliczania wymaganych materiałów i sposobu ich wdrożenia. Inżynieria budowlana jest doskonałym przykładem, ponieważ zawsze kończy się plan (specyfikacja) tego, co zamierzasz zbudować przed budowaniem. Nie zawsze tak się dzieje z oprogramowaniem.

Dla mnie różnica inżyniera oprogramowania i programisty polega na tym, że inżynier jest w stanie zbudować specyfikację tego, co powstanie przed napisaniem dowolnego kodu, gdzie programista albo po prostu napisze kod na podstawie innej specyfikacji, albo jest jedną z tych programiści z Dzikiego Zachodu, którzy piszą kod bez specyfikacji. Inżynier ma również stopień naukowy.

Porównuję różnicę między pracownikiem budowlanym a inżynierem budowlanym do różnicy między programistą a inżynierem oprogramowania.

Aby to wyjaśnić, mam tylko dyplom ukończenia college'u, więc nie mogę się nazywać inżynierem.

Nie uważam terminu „inżynieria” za najbardziej odpowiedni do opisania rozwoju oprogramowania z dwóch głównych powodów:

• Przekazuje wiele starych pomysłów, koncepcji i tak zwanych „złotych reguł” wywodzących się z tradycyjnych dyscyplin inżynieryjnych, takich jak inżynieria przemysłowa, cywilna, morska lub mechaniczna. Mówię o zasadami podziału pracy, procesów produkcyjnych, standardów jakościowych ... Te najczęściej tylko marginalnie dotyczy oprogramowania.

• Nie opisuje w satysfakcjonujący sposób tego, co programowanie ma więcej niż inne dyscypliny (i wierzę, że ma o wiele więcej i wiele innych) oraz z jakimi nowymi wyzwaniami muszą się zmierzyć programiści na co dzień w porównaniu do swoich tradycyjnych odpowiedników projektowanie domen. Ogromną rolę odgrywa w tym wirtualna i niematerialna natura oprogramowania.

Rozwój oprogramowania od dawna postrzegany jest jako „kolejna dziedzina inżynierii”. Biorąc pod uwagę wskaźniki niepowodzenia projektów oprogramowania, które znamy od czasu ich pomiaru, najwyższy czas, abyśmy uznali rozwój jako zupełnie nowe zwierzę, kod jako naprawdę specjalny cykl życia materiałów i aplikacji jako zupełnie inny rodzaj cyklu produkcyjnego i przestańmy desperacko próbować zastosować do nich stare przepisy.

Tak, należy być w stanie stosować standardy i zasady, aby uzyskać przyzwoity produkt. Utrudnia to sposób myślenia klienta (to po prostu kod - zmiana nie powinna kosztować tak wiele), ogromna trudność w kodyfikowaniu tego, co produkt powinien zrobić w kodzie maszynowym (język mówiony / pisany w kodzie) i kwantyfikacja „ jakość". Twoja definicja jakości nie jest moja.

To także powtarzalność. Weź zestaw wymagań i przekaż go dwóm zespołom. Kiedy możesz wydobyć to samo (bez rozmawiania zespołów), jesteś blisko inżynierii.

Inne dziedziny inżynierii również podlegają karom i rygorystycznej weryfikacji i podpisują się. Odpowiedzialność

Nie. Inżynieria oprogramowania nie jest inżynierią. Moim zdaniem różnica polega na zaangażowaniu kreatywności. Na przykład w inżynierii lądowej kreatywność może być bardzo niewielka lub wcale. To coś dobrego.

Aby zbudować most, masz zestaw specyfikacji (muszę przenieść tę liczbę samochodów z tej strony rzeki na drugą stronę).

Z tego mogę wywnioskować:

1. potrzebna liczba pasów drogi (przy użyciu standardowych obliczeń określonych przez rząd);
2. obciążenia, które będę musiał wesprzeć (korzystając z obliczeń określonych przez rząd)
3. materiały, których muszę użyć do obsługi tych obciążeń (przy użyciu standardowych materiałów, które mogę uzyskać od wielu różnych dostawców, lub niestandardowych materiałów, które muszę udowodnić, będą miały prawidłowe właściwości).

Następnie muszę zatwierdzić projekt i sprawdzić go przez stronę trzecią (inną firmę), aby upewnić się, że poprawnie wykonałem obliczenia.

Następnie, kiedy most zostanie rzeczywiście zbudowany, prace będą wykonywane przez wykwalifikowany personel w standardowy sposób. Będą wykonywać pracę, którą wykonali setki, może tysiące razy wcześniej.

Nie zrozumcie mnie źle, każdy projekt inżynieryjny jest inny, ale wydaje się, że za każdym razem, gdy opracowuję nową aplikację / stronę internetową, wszystko dzieje się inaczej.

Tak, zgaduję, że rozwój jest podzbiorem inżynierii:

• Inżynieria oprogramowania obejmuje wstępną specyfikację („jakiego oprogramowania tutaj potrzebujemy?”), Która prawdopodobnie poprzedza rozwój
• „Inżynieria” może również obejmować np. Zdefiniowanie Procesu Zapewnienia Jakości, który z pewnością jest związany z rozwojem, ale prawdopodobnie również poza zakresem samej „konstrukcji”.

Code Complete definiuje „konstrukcję” jako synonim kodowania i debugowania (i komentowania), również ze szczegółowym projektowaniem z wyprzedzeniem, a następnie z testowaniem jednostek i integracji. Rozdział 1, Witamy w konstrukcji oprogramowania (PDF) zaczyna się od wyszczególnienia wielu tematów w całym cyklu życia oprogramowania (w tym definicji problemu, architektury oprogramowania, konserwacji naprawczej itp.), A następnie mówi:

Jak pokazuje rysunek, konstrukcja polega głównie na kodowaniu i debugowaniu, ale obejmuje również szczegółowy projekt, planowanie budowy, testy jednostkowe, integrację, testy integracyjne i inne działania. Gdyby była to książka o wszystkich aspektach tworzenia oprogramowania, zawierałaby ładnie zrównoważone dyskusje na temat wszystkich działań w procesie tworzenia oprogramowania. Ponieważ jest to podręcznik technik budowlanych, kładzie jednak koślawy nacisk na konstrukcję i dotyczy tylko pokrewnych tematów. Gdyby ta książka była psem, podchodziłaby do budowy, machałaby ogonem przy projektowaniu i testowaniu oraz szczekał podczas innych prac rozwojowych.

Tworzenie oprogramowania to inżynieria.

Kilka argumentów przedstawionych przez innych, dlaczego inżynieria oprogramowania nie spełnia standardów inżyniera:

Niektórzy twierdzą, że inżynierowie zajmują się projektowaniem „rzeczy” dla dobra publicznego - czy ICBM, czołgi itp. Są dobrem publicznym? Niektórzy powiedzieliby „tak” (dobre wykroczenie to dobra obrona), inni powiedzieli „nie”. Nie sądzę jednak, aby ktokolwiek nie zgodził się z tym, że facet, który projektuje system celowania czołgów nowej generacji, jest inżynierem. Dobro publiczne może być subiektywne. W każdym razie mnóstwo oprogramowania jest dobrem publicznym, więc i tak kwestia jest sporna.

Inni twierdzą, że inżynierowie projektują, których nie budują. Widziałem kilka komentarzy typu „inżynierowie nie spawają”. Twierdziłbym, że inżynierowie mechanicy opracowują plany - szczegółowe projekty to coś realizuje jeszcze. Jeśli inżynier mechanik opracowuje plan i przekazuje go do maszyny CNC, czy to sprawia, że ​​nie jest on już inżynierem mechanikiem - ponieważ maszyna wykonała implementację zamiast osoby? Argumentowałbym, że kod źródłowy jest szczegółowym planem, który jest podawany do maszyny wykonującej implementację i nie widzę, jak to się różni od kodu karmienia MechE dla maszyny CNC. A teraz mamy drukarki 3D, czy to oznacza koniec inżynierów mechaników? Czy są teraz programistami mechanicznymi?

Innym tematem, który widzę, jest licencja. Obecnie tylko kilku jurysdykcji licencjonuje inżynierów oprogramowania. Nie ma (jak dotąd) ogólnoamerykańskich licencji inżynierów oprogramowania (myślę, że robi to tylko Teksas). Niektórzy wykorzystali to jako powód do stwierdzenia, że ​​inżynierii oprogramowania nie należy nazywać inżynierią. Nadchodzi PE dla inżynierów oprogramowania. Ale na bardziej filozoficznym poziomie tylko dlatego, że niektórzy ustawodawcy stanowi wybierają (lub nie) nazywanie inżynierii rozwoju oprogramowania nie ma wpływu na rzeczywistość.