Budowa oprogramowania - Software construction

Budowa oprogramowanie jest inżynieria oprogramowania dyscypliny. Jest to szczegółowy stworzenie pracy sensownego oprogramowania za pomocą kombinacji kodowania , weryfikacji , testów jednostkowych , testów integracyjnych i debugowania . Jest powiązany ze wszystkimi innymi dyscyplinami inżynierii oprogramowania , w największym stopniu z projektowaniem oprogramowania i testowaniem oprogramowania .

Podstawy konstrukcji oprogramowania

Minimalizacja złożoności

Potrzeba zmniejszenia złożoności wynika głównie z ograniczonej zdolności większości ludzi do przechowywania złożonych struktur i informacji w pamięci roboczej. Zmniejszoną złożoność osiąga się poprzez położenie nacisku na tworzenie kodu, który jest raczej prosty i czytelny niż sprytny. Minimalizowanie złożoności jest osiągane poprzez wykorzystanie standardów i wielu specyficznych technik kodowania . Jest to również wspierane przez techniki jakości ukierunkowane na konstrukcję .

Przewidywanie zmian

Przewidywanie zmian pomaga inżynierom oprogramowania w tworzeniu rozszerzalnego oprogramowania, co oznacza, że ​​mogą ulepszyć oprogramowanie bez naruszania podstawowej struktury. Badania trwające ponad 25 lat wykazały, że koszt ponownej obróbki może być od 10 do 100 razy (od 5 do 10 razy w przypadku mniejszych projektów) droższy niż spełnienie wymagań za pierwszym razem. Biorąc pod uwagę, że średnio 25% wymagań zmienia się w trakcie opracowywania projektu, potrzeba obniżenia kosztów przeróbek wyjaśnia potrzebę przewidywania zmian.

Konstruowanie do weryfikacji

Konstruowanie do weryfikacji polega na budowaniu oprogramowania w taki sposób, aby usterki mogły być łatwo wytropione przez inżynierów oprogramowania piszących oprogramowanie , a także podczas niezależnych czynności testowych i operacyjnych. Konkretne techniki, które wspierają konstruowanie do weryfikacji, obejmują między innymi przestrzeganie standardów kodowania wspierających przegląd kodu , testowanie jednostkowe , organizowanie kodu w celu obsługi testów automatycznych oraz ograniczone użycie złożonych lub trudnych do zrozumienia struktur językowych .

Ponowne użycie

Systematyczne ponowne wykorzystanie może zapewnić znaczną poprawę produktywności, jakości i kosztów oprogramowania. Ponowne użycie ma dwa ściśle powiązane aspekty:

  • Konstrukcja do ponownego wykorzystania: tworzenie zasobów oprogramowania wielokrotnego użytku.
  • Konstrukcja z ponownym wykorzystaniem: ponowne wykorzystanie zasobów oprogramowania do budowy nowego rozwiązania.

Normy w budownictwie

Normy, czy to zewnętrzne (stworzone przez organizacje międzynarodowe), czy wewnętrzne (stworzone na poziomie korporacyjnym), które bezpośrednio wpływają na kwestie konstrukcyjne obejmują:

Zarządzanie budową

Model konstrukcyjny

Stworzono wiele modeli w celu opracowania oprogramowania , z których niektóre kładą większy nacisk na konstrukcję niż inne. Niektóre modele są bardziej liniowe z punktu widzenia konstrukcji, na przykład modele wodospadu i etapowe dostawy. Modele te traktują budowę jako czynność, która ma miejsce dopiero po wykonaniu istotnych prac wstępnych - w tym pracy nad szczegółowymi wymaganiami , szeroko zakrojonych prac projektowych i szczegółowego planowania . Inne modele są bardziej iteracyjne , takie jak prototypowanie ewolucyjne , programowanie ekstremalne i Scrum . Podejścia te zwykle traktują konstrukcję jako czynność, która występuje równolegle z innymi działaniami związanymi z tworzeniem oprogramowania , w tym wymaganiami , projektowaniem i planowaniem , lub nakłada się na nie.

Planowanie budowy

Wybór metody budowy jest kluczowym aspektem planowania budowy. Wybór metody budowy wpływa na stopień realizacji wymagań konstrukcyjnych (np. Analiza wymagań , projektowanie oprogramowania itp.), Kolejność ich wykonywania oraz stopień ich ukończenia przed rozpoczęciem prac budowlanych zaczyna się. Planowanie budowy określa również kolejność tworzenia i integracji komponentów , procesy zarządzania jakością oprogramowania , przydział zadań do konkretnych inżynierów oprogramowania i inne zadania zgodnie z wybraną metodą .

Pomiar konstrukcji

Można zmierzyć wiele czynności konstrukcyjnych i artefaktów, w tym opracowany kod, zmodyfikowany kod, ponownie wykorzystany, zniszczony kod, złożoność kodu, statystyki inspekcji kodu, wskaźniki naprawy i znajdowania usterek, nakład pracy i planowanie. Pomiary te mogą być przydatne do zarządzania budową, zapewnienia jakości podczas budowy, usprawnienia procesu budowy, a także z innych powodów.

Względy praktyczne

Konstrukcja oprogramowania podlega wielu praktycznym względom:

Projekt budowlany

Aby uwzględnić nieprzewidziane luki w projekcie oprogramowania , podczas tworzenia oprogramowania należy wprowadzić pewne modyfikacje projektu na mniejszą lub większą skalę, aby dopracować szczegóły projektu oprogramowania .

Niskie rozchodzenie się jest jedną z cech konstrukcyjnych, które badacze uznali za korzystne. Ukrywanie informacji okazało się przydatną techniką projektowania w dużych programach, dzięki czemu łatwiej było je modyfikować czterokrotnie.

Języki konstrukcyjne

Języki konstrukcyjne obejmują wszystkie formy komunikacji, za pomocą których człowiek może określić wykonywalne rozwiązanie problemu dla komputera. Obejmują one języki konfiguracji, języki zestawu narzędzi i języki programowania :

  • Języki konfiguracji to języki, w których inżynierowie oprogramowania wybierają z ograniczonego zestawu wstępnie zdefiniowanych opcji do tworzenia nowych lub niestandardowych instalacji oprogramowania.
  • Języki zestawu narzędzi są używane do tworzenia aplikacji z zestawów narzędzi i są bardziej złożone niż języki konfiguracyjne.
  • Języki skryptowe to rodzaje języków programowania aplikacji, które obsługują skrypty, które są często interpretowane, a nie kompilowane.
  • Języki programowania są najbardziej elastycznym rodzajem języków konstrukcyjnych, które używają trzech ogólnych rodzajów notacji:
    • Notacje językowe, które wyróżnia się w szczególności użyciem ciągów tekstowych przypominających słowa do reprezentowania złożonych konstrukcji oprogramowania oraz kombinacji takich ciągów podobnych do słów we wzorce, które mają składnię podobną do zdania.
    • Formalne zapisy, które w mniejszym stopniu opierają się na intuicyjnych, codziennych znaczeniach słów i ciągów tekstowych, a bardziej na definicjach popartych precyzyjnymi, jednoznacznymi i formalnymi (lub matematycznymi) definicjami.
    • Notacje wizualne, które w znacznie mniejszym stopniu opierają się na zorientowanych tekstowo zapisach zarówno konstrukcji językowej, jak i formalnej, a zamiast tego opierają się na bezpośredniej interpretacji wizualnej i rozmieszczeniu bytów wizualnych, które reprezentują oprogramowanie bazowe.

Programiści pracujący w języku, którego używali przez trzy lata lub dłużej, są o około 30 procent bardziej produktywni niż programiści z równoważnym doświadczeniem, którzy są nowicjuszami w danym języku. Języki wysokiego poziomu, takie jak C ++, Java, Smalltalk i Visual Basic, zapewniają od 5 do 15 razy lepszą produktywność, niezawodność, prostotę i zrozumiałość niż języki niskiego poziomu, takie jak asembler i C. Wykazano, że równoważny kod potrzebuje mniej wierszy do być wdrażane w językach wysokiego poziomu niż w językach niższego poziomu.

Kodowanie

Poniższe kwestie mają zastosowanie do czynności związanych z kodowaniem konstrukcji oprogramowania:

  • Techniki tworzenia zrozumiałego kodu źródłowego , w tym nazewnictwo i układ kodu źródłowego. Jedno z badań wykazało, że wysiłek wymagany do debugowania programu jest zminimalizowany, gdy nazwy zmiennych mają od 10 do 16 znaków.
  • Użycie klas , typów wyliczeniowych , zmiennych , nazwanych stałych i innych podobnych jednostek:
    • Badanie przeprowadzone przez NASA wykazało, że umieszczenie kodu w dobrze podzielonych na czynniki klasach może podwoić możliwość ponownego wykorzystania kodu w porównaniu z kodem opracowanym przy użyciu projektowania funkcjonalnego.
    • Jeden eksperyment wykazał, że projekty, które uzyskują dostęp do tablic sekwencyjnie, a nie losowo, skutkują mniejszą liczbą zmiennych i mniejszą liczbą odniesień do zmiennych.
  • Zastosowanie struktur sterujących:
    • Jeden z eksperymentów wykazał, że pętle z wyjściem są bardziej zrozumiałe niż inne rodzaje pętli.
    • Jeśli chodzi o poziom zagnieżdżenia w pętlach i warunkach warunkowych, badania wykazały, że programiści mają trudności ze zrozumieniem więcej niż trzech poziomów zagnieżdżenia.
    • Wykazano, że złożoność przepływu sterowania koreluje z niską niezawodnością i częstymi błędami.
  • Obsługa warunków błędu - zarówno planowanych błędów, jak i wyjątków (na przykład wprowadzanie złych danych)
  • Zapobieganie naruszeniom bezpieczeństwa na poziomie kodu ( na przykład przepełnienia bufora lub przepełnienia indeksu tablicy )
  • Wykorzystanie zasobów poprzez zastosowanie mechanizmów wykluczania i dyscypliny w dostępie do zasobów wielokrotnego użytku seryjnego (w tym wątków lub blokad baz danych )
  • Organizacja kodu źródłowego (na instrukcje i procedury ):
    • Wysoce spójne procedury okazały się mniej podatne na błędy niż procedury o niższej spójności. Badanie 450 procedur wykazało, że 50 procent wysoce spójnych procedur było wolnych od błędów w porównaniu z zaledwie 18 procentami procedur o niskiej spójności. Inne badanie różnych 450 procedur wykazało, że procedury o najwyższych stosunkach sprzężenia do kohezji miały 7 razy więcej błędów niż te o najniższych stosunkach sprzężenia do kohezji i były 20 razy droższe w naprawie.
    • Chociaż badania wykazały niejednoznaczne wyniki dotyczące korelacji między rutynowymi rozmiarami a odsetkiem błędów w nich, ale jedno badanie wykazało, że procedury zawierające mniej niż 143 linie kodu były 2,4 razy tańsze w naprawie niż większe procedury. Inne badanie wykazało, że kod wymagał najmniejszej zmiany, gdy procedury miały średnio od 100 do 150 linii kodu. Inne badanie wykazało, że złożoność strukturalna i ilość danych w programie były skorelowane z błędami niezależnie od ich wielkości.
    • Interfejsy między procedurami to jedne z najbardziej podatnych na błędy obszarów programu. Jedno z badań wykazało, że 39 procent wszystkich błędów to błędy w komunikacji między procedurami.
    • Niewykorzystane parametry są skorelowane ze zwiększonym poziomem błędów. W jednym badaniu tylko 17 do 29 procent procedur z więcej niż jedną zmienną, do której nie ma odniesienia, nie zawierało błędów, w porównaniu z 46 procentami procedur bez nieużywanych zmiennych.
    • Liczba parametrów procedury powinna wynosić maksymalnie 7, ponieważ badania wykazały, że ludzie generalnie nie są w stanie śledzić więcej niż około siedmiu fragmentów informacji naraz.
  • Organizacja kodu źródłowego (na klasy , pakiety lub inne struktury). Rozważając ograniczenie , maksymalna liczba elementów danych w klasie nie powinna przekraczać 7 ± 2. Badania wykazały, że liczba ta to liczba odrębnych elementów, które dana osoba może zapamiętać podczas wykonywania innych zadań. Rozważając dziedziczenie , należy ograniczyć liczbę poziomów w drzewie dziedziczenia. Stwierdzono, że drzewa głębokiego dziedziczenia są istotnie powiązane ze zwiększoną liczbą błędów. Rozważając liczbę procedur w klasie, powinna być jak najmniejsza. Badanie programów C ++ wykazało związek między liczbą procedur a liczbą błędów.
  • Dokumentacja kodu
  • Dostrajanie kodu

Testowanie konstrukcji

Celem testowania konstrukcji jest zmniejszenie odstępu między czasem, w którym błędy są wstawiane do kodu, a momentem ich wykrywania. W niektórych przypadkach testy konstrukcyjne są wykonywane po napisaniu kodu. W programowaniu najpierw testowym przypadki testowe są tworzone przed napisaniem kodu. Konstrukcja obejmuje dwie formy testowania, które są często wykonywane przez inżyniera oprogramowania, który napisał kod :

Ponowne użycie

Wdrażanie ponownego wykorzystania oprogramowania to coś więcej niż tylko tworzenie i używanie bibliotek zasobów. Wymaga sformalizowania praktyki ponownego wykorzystywania poprzez integrację procesów i działań związanych z ponownym wykorzystaniem w cyklu życia oprogramowania . Zadania związane z ponownym wykorzystaniem w konstrukcji oprogramowania podczas kodowania i testowania to:

Jakość konstrukcji

Podstawowe techniki stosowane w celu zapewnienia jakości kodu w trakcie jego konstruowania obejmują:

  • Testy jednostkowe i testy integracyjne . Jedno z badań wykazało, że średnie wskaźniki wykrywania defektów w testach jednostkowych i testach integracyjnych wynoszą odpowiednio 30% i 35%.
  • Pierwsze opracowanie testowe
  • Stosowanie asercji i programowania obronnego
  • Debugowanie
  • Inspekcje . Jedno z badań wykazało, że średni wskaźnik wykrywalności defektów podczas formalnych inspekcji kodu wynosi 60%. Jeśli chodzi o koszt znalezienia defektów, badanie wykazało, że odczyt kodu wykrył 80% więcej błędów na godzinę niż testowanie. Inne badanie wykazało, że wykrycie defektów projektowych za pomocą testów kosztuje sześć razy więcej niż za pomocą inspekcji. Badanie przeprowadzone przez IBM wykazało, że potrzeba tylko 3,5 godziny na znalezienie usterki podczas inspekcji kodu w porównaniu do 15–25 godzin podczas testowania. Firma Microsoft odkryła, że ​​znalezienie i naprawienie usterki za pomocą inspekcji kodu zajmuje 3 godziny, a znalezienie i naprawienie usterki za pomocą testów zajmuje 12 godzin. W programie obejmującym 700 tysięcy wierszy stwierdzono, że przeglądy kodu były kilkakrotnie tańsze niż testowanie. Badania wykazały, że inspekcje powodują o 20% - 30% mniej błędów na 1000 wierszy kodu niż mniej formalne praktyki recenzowania i zwiększają produktywność o około 20%. Formalne kontrole zwykle zajmują 10–15% budżetu projektu i zmniejszają całkowity koszt projektu. Naukowcy odkryli, że posiadanie więcej niż 2-3 recenzentów na formalnej inspekcji nie zwiększa liczby wykrytych defektów, chociaż wyniki wydają się różnić w zależności od rodzaju badanego materiału.
  • Przeglądy techniczne . Jedno z badań wykazało, że średnie wskaźniki wykrywania defektów podczas nieformalnych przeglądów kodu i sprawdzania dokumentów wynoszą odpowiednio 25% i 40%. Walkthroughs stwierdzono występowanie defektów wykrywalności 20% - 40%, jednak stwierdzono także kosztowne, szczególnie gdy wzrost ciśnienia projektu. NASA stwierdziła, że ​​odczyt kodu pozwala wykryć 3,3 defektów na godzinę wysiłku w porównaniu z 1,8 defektów na godzinę w przypadku testów. Wykrywa również o 20% - 60% więcej błędów w czasie trwania projektu niż w przypadku różnego rodzaju testów. Badanie 13 recenzji na temat spotkań przeglądowych wykazało, że 90% defektów zostało znalezionych podczas przygotowań do spotkania przeglądowego, podczas gdy tylko około 10% zostało znalezionych podczas spotkania.
  • Analiza statyczna (IEEE1028)

Badania wykazały, że należy zastosować połączenie tych technik, aby osiągnąć wysoki współczynnik wykrywania defektów. Inne badania wykazały, że różni ludzie mają tendencję do znajdowania różnych wad. Jedno z badań wykazało, że Extreme Programming praktyki programowania w parach , kontroli biurka , testów jednostkowych , testów integracyjnych i testów regresji może osiągnąć 90% poziom wykrywania defektów. Eksperyment z udziałem doświadczonych programistów wykazał, że średnio byli w stanie znaleźć 5 błędów (najlepiej 9) z 15 błędów podczas testów.

80% błędów koncentruje się na 20% zajęć i procedur projektu. 50% błędów znajduje się na 5% zajęć projektu. IBM był w stanie zmniejszyć liczbę usterek zgłaszanych przez klientów dziesięciokrotnie, a także zredukować budżet na konserwację o 45% w swoim systemie IMS, naprawiając lub przepisując tylko 31 z 425 klas. Około 20% procedur projektu stanowi 80% kosztów rozwoju. Klasyczne badanie przeprowadzone przez IBM wykazało, że kilka procedur OS / 360 podatnych na błędy było najdroższymi jednostkami. Mieli około 50 defektów na 1000 linii kodu, a ich naprawienie kosztuje 10 razy więcej niż opracowanie całego systemu.

Integracja

Kluczowym działaniem podczas budowy jest integracja oddzielnie skonstruowanych procedur , klas , komponentów i podsystemów. Ponadto może zajść potrzeba integracji określonego systemu oprogramowania z innym oprogramowaniem lub systemami sprzętowymi. Obawy związane z integracją budowy obejmują planowanie sekwencji, w której elementy zostaną zintegrowane, tworząc rusztowanie wspieranie tymczasowych wersje tego oprogramowania , określania stopnia testowania i jakości wykonywanej pracy na składniki , zanim zostaną one zintegrowane oraz określania punktów w projekcie, w którym śródroczne wersje tego oprogramowania są testowane.

Technologie budowlane

Zorientowane obiektowo problemy ze środowiskiem wykonawczym

Języki zorientowane obiektowo obsługują szereg mechanizmów wykonawczych, które zwiększają elastyczność i zdolność adaptacji programów, takich jak abstrakcja danych , hermetyzacja , modułowość , dziedziczenie , polimorfizm i odbicie .

Abstrakcja danych to proces, w którym dane i programy są definiowane w formie podobnej do ich znaczenia, przy jednoczesnym ukryciu szczegółów implementacji. Badania naukowe wykazały, że abstrakcja danych sprawia, że ​​programy są o około 30% łatwiejsze do zrozumienia niż programy funkcjonalne.

Twierdzenia, projektowanie według kontraktu i programowanie obronne

Asercje to wykonywalne predykaty, które są umieszczane w programie, które umożliwiają sprawdzenie programu w czasie wykonywania. Projektowanie według kontraktu to podejście programistyczne, w którym warunki wstępne i końcowe są uwzględniane dla każdej procedury. Programowanie obronne to ochrona programu przed przerwaniem przez nieprawidłowe dane wejściowe.

Obsługa błędów, obsługa wyjątków i tolerancja błędów

Obsługa błędów odnosi się do praktyki programowania polegającej na przewidywaniu i kodowaniu warunków błędów, które mogą wystąpić podczas działania programu. Obsługa wyjątków to konstrukcja języka programowania lub mechanizm sprzętowy przeznaczony do obsługi występowania wyjątków, specjalnych warunków, które zmieniają normalny przebieg wykonywania programu. Odporność na awarie to zbiór technik, które zwiększają niezawodność oprogramowania poprzez wykrywanie błędów, a następnie naprawianie ich, jeśli to możliwe, lub powstrzymywanie ich skutków, jeśli odzyskanie nie jest możliwe.

Techniki konstrukcyjne oparte na stanach i tabelach

Programowanie oparte na stanach to technologia programowania wykorzystująca maszyny o skończonych stanach do opisywania zachowań programu. Metoda oparta na tabelach to schemat, który używa tabel do wyszukiwania informacji, zamiast używać instrukcji logicznych (takich jak if i case).

Konfiguracja środowiska wykonawczego i internacjonalizacja

Konfiguracja środowiska wykonawczego to technika wiążąca wartości zmiennych i ustawienia programu podczas działania programu, zwykle poprzez aktualizację i odczytywanie plików konfiguracyjnych w trybie just-in-time. Umiędzynarodowienie to czynność techniczna polegająca na przygotowaniu programu, zwykle oprogramowania interaktywnego, do obsługi wielu lokalizacji. Odpowiadające mu działanie, lokalizacja , to działanie polegające na modyfikowaniu programu w celu obsługi określonego języka lokalnego.

Zobacz też

Uwagi

Bibliografia

Linki zewnętrzne