Czy są jakieś prace związane ze stosowaniem miar złożoności Halsteada do określania jakości oprogramowania?

W 1977 roku Maurice Howard Halstead wprowadził miary złożoności systemów oprogramowania , które obejmowały pomiary słownictwa programu, długości programu, objętości, trudności, wysiłku oraz szacunkową liczbę błędów w module. Według Wikipedii trudność dotyczy trudności ze zrozumieniem programu podczas czytania lub pisania, a wysiłek można przełożyć na czas potrzebny do napisania aplikacji, w której czas = (wysiłek / 18) sekund.

Pomiar jest bezużyteczny, chyba że dane i obliczenia dotyczą pewnego aspektu tworzenia oprogramowania. Nie znalazłem jednak żadnej pracy, która stanowiłaby, że trudność o określonej wartości lub wyższa prowadzi do statystycznie znaczącego wzrostu defektów lub związku między trudnością a czasem czytania kodu (trudność N daje średnio M spędzonych godzin rozumienie podstawy kodu) lub jakakolwiek analiza możliwości obliczenia Czasu po fakcie, która jest przydatna w określaniu jakości (zwłaszcza, że czas na napisanie powinien już zostać zapisany jako pomiar). Szczególnie interesuje mnie ocena błędów Halsteada (o której nie wspomniano w Wikipedii) - liczbę błędów w aplikacji można oszacować na podstawie objętości / 3000 lub nakładu pracy ^ (2/3) / 3000.

Szukam dwóch rzeczy:

Czy ktoś używał miar złożoności oprogramowania Halstead w rzeczywistej aplikacji do oceny jakości oprogramowania? Jeśli tak, to w jaki sposób je zastosowałeś i czy okazały się one użytecznym, ważnym i / lub wiarygodnym pomiarem?
Czy są jakieś badania akademickie w formie ankiet, analiz lub studiów przypadków, które omawiają ważność (lub nieważność) miar złożoności Halsteada, gdy stosuje się je do jakości oprogramowania?
Czy są jakieś badania akademickie w postaci ankiet, analiz lub studiów przypadków, które pokazują wykorzystanie Linii kodu źródłowego (SLOC) do obliczenia czegoś podobnego do wskaźników Halsteada dotyczących objętości, trudności, wysiłku, czasu i błędów? Podejrzewam, że Tom może po prostu odpowiadać liczbie SLOC, a trudność może odpowiadać złożoności cyklicznej (i ewentualnie innym miernikom). Wiem również, że mierzenie wysiłku, wydajności lub czasu w SLOC może wprowadzać w błąd.

quality metrics measurement

— Thomas Owens
źródło

Będziesz mieć problemy ze znalezieniem wyników w ciągu ostatnich 15 lat, ponieważ pomiary Halsteada zostały wykonane mniej więcej 30-40 lat temu, a silna korelacja z SLOC została odkryta niemal natychmiast. (To z pamięci, z przemówienia nowego doktoranta na UT Austin ok. 1977 r.)

— John R. Strohm

Dziękuję za to. Zaktualizuję pytanie i ponownie skoncentruję wysiłek na wyszukiwaniu na starszych dokumentach.

— Thomas Owens

Odpowiedzi:

Microsoft Research wykonał pewne prace w tym obszarze. Sprawdź tę stronę: http://research.microsoft.com/en-us/people/nachin/ . Chociaż nie w oparciu o Halsteada, Nachi i jego zespół przeprowadzili pewne dochodzenie przy użyciu Halsteada, cykliczności złożoności, rezygnacji z kodu i innych środków w celu oceny względnego ryzyka i niestabilności przy wprowadzaniu zmian w obszarach kodu. Jest też ciekawy artykuł na temat tego, jak efektywność organizacyjna również odgrywa dużą rolę, ale to nie jest temat. :)

— nitiny
źródło

Będę musiał przeczytać niektóre z nich. Zdecydowanie coś mnie interesuje, ale jestem (przynajmniej teraz) szczególnie zainteresowany Halsteadem, więc skupię się tam. Dodałem zakładkę do strony, aby móc ją przeczytać, gdy będę miał więcej czasu, ale na razie mam +1.

— Thomas Owens

Wykazano, że cykliczna złożoność McCabe'a na prawdziwym kodzie jest bardzo silnie skorelowana z surowym SLOC, do tego stopnia, że przy obliczaniu go nie ma żadnej wartości przyrostowej.

— John R. Strohm,

Istnieje wiele takich badań. Google to twój przyjaciel.

Wskaźniki Halsteada wypadły z łask, gdy wykazano, że wszystkie były silnie skorelowane z surowym SLOC (liniami kodu źródłowego). W tym momencie łatwiej jest zmierzyć SLOC i zrobić to z nim.

Oto wynik z Google Books .

— John R. Strohm
źródło

Byłem w Google od czasu, kiedy zadałem to pytanie i nie znalazłem jeszcze żadnych opublikowanych artykułów ani innych renomowanych źródeł. Ponadto nie widzę, jak dane związane z SLOC mogą być słabe. SLOC / czas jest słabą miarą produktywności, ale inne wskaźniki oparte na SLOC są zwykle uważane za prawidłowe, na przykład wadami / SLOC.

— Thomas Owens

@Thomas: Nie chodzi o to, że wskaźniki Halsteada są „powiązane” z SLOC, lecz o to, że są silnie skorelowane. Statystyka 102. Powiedzenie, że Y i X są silnie skorelowane, oznacza, że stosunek Y / X jest zasadniczo stały dla wszystkich zestawów danych. W takim przypadku nie ma sensu mierzyć Y, jeśli łatwiej jest zmierzyć X, ponieważ Y tak naprawdę nie mówi ci niczego, czego jeszcze nie wiesz od X.

— John R. Strohm

To ma sens. Dane Halsteada opierają się na liczbie różnych i wszystkich operatorów i operandów. Powszechnie wiadomo, że dłuższy program będzie miał więcej operatorów / operandów i będzie bardziej prawdopodobne, że będą mieli wyraźniejsze operatory / operandy. Miary objętości i trudności można uzyskać za pomocą SLOC zamiast operatorów / operandów. Nie dotyczy to jednak ważności, aplikacji i znaczenia (lub braku znaczenia) mierników Wysiłek, Czas i Błędy. Nawet jeśli obliczone za pomocą SLOC zamiast operatorów / operandów, czy te wskaźniki mówią coś znaczącego o systemie?

— Thomas Owens

SLOC jest łatwiejszy do policzenia i prawdopodobnie bardziej przydatny. Szacunki SLOC są wykorzystywane przez kilka technik szacowania kosztów, śledzonych w PSP i TSP, i mogą być wykorzystywane w innych miernikach, takich jak gęstość defektów. Według mnie, liczenie SLOC może być lepsze niż liczenie operatorów / operandów. Po drugie i jak dotąd nie ma odpowiedzi, ważność wskaźników wysiłku, czasu i błędów, niezależnie od tego, jakie pomiary są używane do ich obliczenia. Zgadzam się, że obliczenie ich za pomocą SLOC może być lepsze, ale nawet gdybym to zrobił, czy coś by to znaczyło?

— Thomas Owens

@ThomasOwens: Prawdopodobnie nie. Jeśli Wysiłek, Czas i Błędy są ściśle skorelowane z SLOC, oznacza to, że wszystkie programy o danym rozmiarze zajmują tyle samo czasu i wysiłku i mają tę samą liczbę błędów. Pierwsze dwa są oparte na oszacowaniach opartych na SLOC (np. COCOMO) i przypominają stwierdzenie, że woda jest mokra. Trzeci tak naprawdę nie pomaga.

— John R. Strohm,

To, że Halstead Volume jest skorelowane z SLOC, jest interesujące, ale ograniczone. Podstawowe statystyki: korelacja liniowa nie jest przechodnia. X skorelowany z Y, Y skorelowany z Z NIE OZNACZA, że X jest skorelowany z Z.

— użytkownik1704475
źródło

Gdy X i Y są jedynie skorelowane, a Y i Z są jedynie skorelowane, tak, X i Z niekoniecznie są skorelowane z powodu stosunkowo wysokich poziomów hałasu w pierwszych dwóch korelacjach. Kiedy X i Y są silnie skorelowane, a Y i Z są silnie skorelowane, występuje bardzo, bardzo niewielki hałas i staje się wysoce prawdopodobne w każdym przypadku, że X i Z okażą się skorelowane.

— John R. Strohm