Historia inżynierii oprogramowania - History of software engineering

Historia informatyki
Ordinateurs centralaux 348-3-006.jpg
Sprzęt komputerowy
Oprogramowanie
Informatyka
Nowoczesne koncepcje
Według kraju
Kalendarium obliczeń
Słowniczek informatyki
Artykuł obejmuje dziedzinę inżynierii oprogramowania w sensie jednego podejścia do tworzenia oprogramowania ; terminy są czasami używane jako synonimy.

Historia inżynierii oprogramowania rozpoczyna się w 1960 roku. Pisanie oprogramowania przekształciło się w zawód zajmujący się tym, jak najlepiej zmaksymalizować jakość oprogramowania i jak je tworzyć. Jakość może odnosić się do tego, jak oprogramowanie jest konserwowalne, do jego stabilności, szybkości, użyteczności, testowalności, czytelności, rozmiaru, kosztu, bezpieczeństwa i liczby wad lub „błędów”, a także do mniej mierzalnych cech, takich jak elegancja, zwięzłość i klient satysfakcja, wśród wielu innych atrybutów. Jak najlepiej tworzyć wysokiej jakości oprogramowanie to osobny i kontrowersyjny problem obejmujący zasady projektowania oprogramowania, tzw. „najlepsze praktyki” w zakresie pisania kodu, a także szersze kwestie zarządcze, takie jak optymalna wielkość zespołu, proces, jak najlepiej dostarczyć oprogramowanie na czas i tak szybko, jak to możliwe, „kulturę” miejsca pracy, praktyki zatrudniania i tak dalej. Wszystko to mieści się w szerokiej rubryce inżynierii oprogramowania .

Przegląd

Ewolucja inżynierii oprogramowania jest zauważalna w kilku obszarach:

  • Pojawienie się jako zawód: Na początku lat 80. inżynieria oprogramowania pojawiła się już jako zawód działający w dobrej wierze , aby stanąć obok informatyki i tradycyjnej inżynierii.
  • Rola kobiet : Przed 1970 r. mężczyźni pełniący bardziej prestiżowe i lepiej płatne stanowiska w dziedzinie inżynierii sprzętu często zlecali pisanie oprogramowania kobietom, a legendy, takie jak Grace Hopper czy Margaret Hamilton, wypełniały wiele stanowisk związanych z programowaniem komputerowym .
    Obecnie w inżynierii oprogramowania pracuje mniej kobiet niż w innych zawodach, a to sytuacja, której przyczyna nie jest jasno określona. Wiele organizacji akademickich i zawodowych uważa tę sytuację za niezrównoważoną i usilnie stara się ją rozwiązać.
  • Procesy: Procesy stały się dużą częścią inżynierii oprogramowania. Są chwaleni za swój potencjał do ulepszania oprogramowania, ale ostro krytykowani za ich potencjał ograniczania programistów.
  • Koszt sprzętu: Względny koszt oprogramowania w porównaniu ze sprzętem znacznie się zmienił w ciągu ostatnich 50 lat. Gdy komputery typu mainframe były drogie i wymagały dużego personelu pomocniczego, nieliczne organizacje, które je kupowały, miały również środki na finansowanie dużych, kosztownych projektów inżynierii oprogramowania na zamówienie. Komputery są teraz znacznie liczniejsze io wiele potężniejsze, co ma kilka skutków dla oprogramowania. Większy rynek może obsługiwać duże projekty w celu tworzenia komercyjnego oprogramowania z półki , tak jak robią to firmy takie jak Microsoft . Tanie maszyny pozwalają każdemu programiście mieć terminal zdolny do dość szybkiej kompilacji . Programy, o których mowa, mogą korzystać z technik takich jak garbage collection , które ułatwiają i przyspieszają ich pisanie przez programistę. Z drugiej strony, znacznie mniej organizacji jest zainteresowanych zatrudnianiem programistów do dużych projektów oprogramowania na zamówienie, zamiast korzystania z komercyjnego oprogramowania z półki w jak największym stopniu.

1945 do 1965: Początki

Domniemane pochodzenie terminu inżynieria oprogramowania obejmuje list z 1965 roku od prezesa ACM Anthony'ego Oettingera , wykłady Douglasa T. Rossa na MIT w latach pięćdziesiątych. Margaret H. Hamilton „jest osobą, która wpadła na pomysł nazwania tej dyscypliny inżynierią oprogramowania, jako sposobu nadania jej legitymizacji”.

Komitet Naukowy NATO sponsorowana dwie konferencje na temat inżynierii oprogramowania w 1968 roku ( Garmisch , Niemiec - patrz raport konferencyjną ) oraz 1969, co dało polu swój początkowy impuls. Wielu uważa, że ​​te konferencje były oficjalnym początkiem zawodu inżyniera oprogramowania .

1965-1985: Kryzys oprogramowania

Inżynieria oprogramowania została pobudzona przez tak zwany kryzys oprogramowania w latach 60., 70. i 80., który zidentyfikował wiele problemów związanych z tworzeniem oprogramowania. Wiele projektów przekroczyło budżet i harmonogram. Niektóre projekty spowodowały szkody majątkowe. Kilka projektów spowodowało utratę życia. Kryzys oprogramowania był pierwotnie definiowany w kategoriach produktywności , ale ewoluował w celu podkreślenia jakości . Niektórzy używali terminu „ kryzys oprogramowania”, aby odnieść się do niemożności zatrudnienia wystarczającej liczby wykwalifikowanych programistów.

  • Przekroczenia kosztów i budżetu : Klasycznym przykładem był system operacyjny OS/360 . Ten dziesięcioletni projekt z lat 60. ostatecznie stworzył jeden z najbardziej złożonych systemów oprogramowania w tamtych czasach. OS/360 był jednym z pierwszych dużych (1000 programistów) projektów oprogramowania. Fred Brooks twierdzi w The Mythical Man-Month , że popełnił wielomilionowy błąd, nie rozwijając spójnej architektury przed rozpoczęciem prac.
  • Uszkodzenie mienia: Wady oprogramowania mogą spowodować uszkodzenie mienia. Słabe zabezpieczenia oprogramowania umożliwiają hakerom kradzież tożsamości, co kosztuje czas, pieniądze i reputację.
  • Życie i śmierć: Wady oprogramowania mogą zabić. Niektóre systemy wbudowane stosowane w radioterapii maszyny udało tak gwałtowne, że podaje się dawki śmiertelne z promieniowaniem pacjentów. Najbardziej znanym z tych niepowodzeń jest incydent Therac-25 .

Peter G. Neumann prowadził współczesną listę problemów i katastrof związanych z oprogramowaniem. Kryzys oprogramowania znika z pola widzenia, ponieważ psychologicznie niezwykle trudno jest pozostać w trybie kryzysowym przez dłuższy czas (ponad 20 lat). Niemniej jednak oprogramowanie – zwłaszcza oprogramowanie wbudowane w czasie rzeczywistym – pozostaje ryzykowne i wszechobecne, dlatego ważne jest, aby nie ulegać samozadowoleniu. W ciągu ostatnich 10-15 lat Michael A. Jackson obszernie pisał o naturze inżynierii oprogramowania, identyfikując główne źródło jej trudności jako brak specjalizacji i sugerował, że jego ramy problemów stanowią podstawę „normalnej praktyki” inżynierii oprogramowania, warunek wstępny, jeśli inżynieria oprogramowania ma stać się nauką inżynierską.

1985-1989: „ Bez srebrnej kuli ”

Przez dziesięciolecia rozwiązanie kryzysu związanego z oprogramowaniem było najważniejsze dla naukowców i firm produkujących narzędzia programowe. Koszt posiadania i utrzymania oprogramowania w latach 80. był dwukrotnie wyższy niż koszt jego opracowania.

  • W latach dziewięćdziesiątych koszty posiadania i utrzymania wzrosły o 30% w porównaniu z latami osiemdziesiątymi.
  • Statystyki pokazały, że w 1995 r. połowa badanych projektów rozwojowych działała, ale nie została uznana za udaną.
  • Przeciętny projekt oprogramowania przekracza harmonogram o połowę.
  • Trzy czwarte wszystkich dużych produktów oprogramowania dostarczonych klientowi to awarie, które albo w ogóle nie są używane, albo nie spełniają wymagań klienta.

Projekty oprogramowania

Wygląda na to, że każda nowa technologia i praktyka od lat 70. do 90. została ogłoszona jako srebrna kula w celu rozwiązania kryzysu oprogramowania. Narzędzia, dyscyplina, metody formalne , proces i profesjonalizm były reklamowane jako srebrne kule:

  • Narzędzia: Szczególnie podkreślane były narzędzia: programowania strukturalnego , programowania obiektowego , CASE narzędzi, takich jak MLK CADES systemie Case, Ada , dokumentacji i standardy były reklamowany jako srebrnych kul.
  • Dyscyplina: Niektórzy eksperci twierdzili, że kryzys oprogramowania był spowodowany brakiem dyscypliny programistów.
  • Metody formalne: Niektórzy wierzyli, że jeśli formalne metodologie inżynieryjne zostaną zastosowane do tworzenia oprogramowania, to produkcja oprogramowania stanie się tak przewidywalna w branży, jak inne gałęzie inżynierii. Opowiadali się za udowodnieniem poprawności wszystkich programów.
  • Proces: Wielu opowiadało się za użyciem zdefiniowanych procesów i metodologii, takich jak Capability Maturity Model .
  • Profesjonalizm: Doprowadziło to do pracy nad kodeksem etycznym, licencjami i profesjonalizmem.

W 1986 roku Fred Brooks opublikował swój artykuł No Silver Bullet , argumentując, że żadna pojedyncza technologia ani praktyka nigdy nie przyniosą 10-krotnej poprawy wydajności w ciągu 10 lat.

Debata o srebrnych kulach toczyła się w ciągu następnej dekady. Zwolennicy Ady , komponentów i procesów przez lata argumentowali, że ich ulubiona technologia będzie srebrną kulą. Sceptycy nie zgodzili się. W końcu prawie wszyscy zaakceptowali, że nigdy nie zostanie znaleziona srebrna kula. Jednak twierdzenia o srebrnych kulach pojawiają się od czasu do czasu, nawet dzisiaj.

Niektórzy uważają, że brak srebrnej kuli oznacza, że ​​inżynieria oprogramowania zawiodła. Jednak po dalszej lekturze Brooks mówi dalej: „Z pewnością dokonamy znacznego postępu w ciągu najbliższych 40 lat; rząd wielkości w ciągu 40 lat nie jest wcale magiczny…”

Poszukiwanie jednego klucza do sukcesu nigdy nie zadziałało. Wszystkie znane technologie i praktyki przyniosły jedynie stopniową poprawę produktywności i jakości. Jednak nie ma też srebrnych kul dla żadnego innego zawodu. Inni nie interpretują żadnej srebrnej kuli jako dowodu, że inżynieria oprogramowania w końcu dojrzała i uznali, że projekty odnoszą sukces dzięki ciężkiej pracy.

Można jednak również powiedzieć, że w rzeczywistości istnieje obecnie szereg srebrnych punktów , w tym lekkie metodologie (patrz „ Zarządzanie projektami ”), kalkulatory arkuszy kalkulacyjnych, dostosowane przeglądarki , wyszukiwarki w witrynie, generatory raportów z baz danych, zintegrowane projektowanie -przetestuj edytory kodujące z pamięcią/różnicami/cofnij oraz wyspecjalizowane sklepy, które generują niszowe oprogramowanie, takie jak informacyjne strony internetowe, za ułamek ceny całkowicie dostosowanej do potrzeb rozwoju strony internetowej. Niemniej jednak dziedzina inżynierii oprogramowania wydaje się zbyt złożona i zróżnicowana, aby pojedynczy „srebrny środek” mógł poprawić większość problemów, a każdy problem stanowi tylko niewielką część wszystkich problemów z oprogramowaniem.

1990 do 1999: znaczenie Internetu

Rozwój Internetu doprowadził do bardzo szybkiego wzrostu zapotrzebowania na międzynarodowe systemy wyświetlania informacji/poczty elektronicznej w sieci WWW. Programiści musieli obsługiwać ilustracje, mapy, zdjęcia i inne obrazy, a także proste animacje w niespotykanym dotąd tempie, z kilkoma dobrze znanymi metodami optymalizacji wyświetlania/przechowywania obrazów (takich jak użycie miniatur).

Wzrost wykorzystania przeglądarki działającej w języku HyperText Markup Language (HTML) zmienił sposób organizacji wyświetlania i wyszukiwania informacji. Rozpowszechnione połączenia sieciowe doprowadziły do ​​rozwoju i zapobiegania międzynarodowym wirusom komputerowym na komputerach z systemem MS Windows, a ogromne rozprzestrzenianie się spamu e-mail stało się głównym problemem projektowym w systemach poczty e-mail, zalewając kanały komunikacji i wymagającym półautomatycznego wstępnego sprawdzania . Systemy wyszukiwania słów kluczowych przekształciły się w wyszukiwarki internetowe , a wiele systemów oprogramowania musiało zostać przeprojektowanych pod kątem wyszukiwania międzynarodowego, w zależności od optymalizacji pod kątem wyszukiwarek (SEO) . Potrzebne były ludzkie systemy tłumaczeniowe języka naturalnego, aby spróbować przetłumaczyć przepływ informacji na wiele języków obcych, przy czym wiele systemów oprogramowania zostało zaprojektowanych do użytku w wielu językach, w oparciu o koncepcje projektowe opracowane przez tłumaczy. Typowe bazy użytkowników komputerów przeszły od setek lub tysięcy użytkowników do często wielu milionów użytkowników międzynarodowych.

2000 do 2015: Lekkie metodologie

Wraz z rosnącym zapotrzebowaniem na oprogramowanie w wielu mniejszych organizacjach, potrzeba niedrogich rozwiązań programowych doprowadziła do rozwoju prostszych i szybszych metodologii, które pozwoliły opracować działające oprogramowanie, od wymagań do wdrożenia, szybciej i łatwiej. Wykorzystanie szybkiego prototypowania ewoluowało do całych lekkich metodologii , takich jak Extreme Programming (XP), które próbowały uprościć wiele obszarów inżynierii oprogramowania, w tym zbieranie wymagań i testowanie niezawodności dla rosnącej, ogromnej liczby małych systemów oprogramowania. Bardzo duże systemy oprogramowania nadal wykorzystywały mocno udokumentowane metodologie, z wieloma tomami w zestawie dokumentacji; jednak mniejsze systemy miały prostsze i szybsze alternatywne podejście do zarządzania opracowywaniem i konserwacją obliczeń i algorytmów oprogramowania, przechowywania/odzyskiwania i wyświetlania informacji.

Aktualne trendy w inżynierii oprogramowania

Inżynieria oprogramowania jest młodą dyscypliną i wciąż się rozwija. Kierunki rozwoju inżynierii oprogramowania obejmują:

Aspekty

Aspekty pomagają inżynierom oprogramowania radzić sobie z atrybutami jakości poprzez dostarczanie narzędzi do dodawania lub usuwania standardowego kodu z wielu obszarów w kodzie źródłowym . Aspekty opisują, jak wszystkie obiekty lub funkcje powinny zachowywać się w określonych okolicznościach. Na przykład aspekty mogą dodawać kontrolę debugowania , rejestrowania lub blokowania do wszystkich obiektów określonego typu. Naukowcy pracują obecnie nad zrozumieniem, jak wykorzystać aspekty do projektowania kodu ogólnego przeznaczenia. Pojęcia pokrewne obejmują programowanie generatywne i szablony .

Eksperymentalny

Eksperymentalna inżynieria oprogramowania jest gałęzią inżynierii oprogramowania zainteresowaną opracowywaniem eksperymentów na oprogramowaniu, zbieraniem danych z eksperymentów oraz opracowywaniem praw i teorii na podstawie tych danych. Zwolennicy tej metody opowiadają się za tym, że natura oprogramowania jest taka, że ​​możemy poszerzyć wiedzę o oprogramowaniu tylko poprzez eksperymenty.

Linie produktów oprogramowania

Linie produktów oprogramowania, czyli inżynieria rodziny produktów , to systematyczny sposób wytwarzania rodzin systemów oprogramowania, zamiast tworzenia serii całkowicie indywidualnych produktów. Ta metoda kładzie nacisk na rozległe, systematyczne, formalne ponowne wykorzystanie kodu , aby spróbować uprzemysłowić proces tworzenia oprogramowania.

Konferencja Future of Software Engineering (FOSE), która odbyła się w ICSE 2000, udokumentowała stan wiedzy na temat SE w 2000 roku i wymieniła wiele problemów do rozwiązania w ciągu następnej dekady. Ślady FOSE na konferencjach ICSE 2000 i ICSE 2007 również pomagają określić stan wiedzy w dziedzinie inżynierii oprogramowania.

Inżynieria oprogramowania dzisiaj

Zawód stara się określić jego granice i treść. Software Engineering Body of Knowledge SWEBOK został przedstawiony jako standard ISO w 2006 roku (ISO/IEC TR 19759).

W 2006 roku Money Magazine i Salary.com uznały inżynierię oprogramowania za najlepszą pracę w Ameryce pod względem wzrostu, płac, poziomu stresu, elastyczności godzin i środowiska pracy, kreatywności oraz łatwości wejścia i rozwoju w tej dziedzinie.

Poddyscypliny

Sztuczna inteligencja

Szeroka gama platform umożliwiła rozwój różnych aspektów sztucznej inteligencji, od systemów eksperckich, takich jak Cyc, przez platformy głębokiego uczenia się, po platformy robotów, takie jak Roomba z otwartym interfejsem. Ostatnie postępy w głębokim sztucznych sieci neuronowych i rozproszonego doprowadziły do proliferacji bibliotek programowych, w tym Deeplearning4j , TensorFlow , Theano i Torch .

Badanie McKinsey Global Institute z 2011 r. wykazało niedobór 1,5 miliona dobrze wyszkolonych specjalistów i menedżerów ds. danych i sztucznej inteligencji, a szereg prywatnych bootcampów opracowało programy, aby sprostać temu zapotrzebowaniu, w tym bezpłatne programy, takie jak The Data Incubator lub programy płatne, takie jak General Assembly .

Języki

Główny artykuł: Lista języków programowania sztucznej inteligencji

Wczesna symboliczna sztuczna inteligencja zainspirowała Lispa i Prologa , które zdominowały wczesne programowanie AI. Współczesne tworzenie sztucznej inteligencji często wykorzystuje popularne języki, takie jak Python lub C++ , lub języki niszowe, takie jak Wolfram Language .

Wybitne postacie w historii inżynierii oprogramowania

Zobacz też

Bibliografia

Zewnętrzne linki