Nie jestem pewien, czy uważasz to za eleganckie, ale Watts Humphrey napisał całą książkę o nazwie Personal Software Process, która polegała na pomiarze własnej wydajności. Nakreślił miary danych wejściowych, takich jak czas przy biurku vs. przerwy, czas spędzony na pracy nad różnego rodzaju cyklami życia oprogramowania, defekty na ilość kodu. Raport techniczny zawiera krótką wersję pod adresem:
http://www.sei.cmu.edu/library/abstracts/reports/00tr022.cfm
Jeśli chcesz spojrzeć na jakość kodu programisty, Chidamber & Kemerer zaproponował kilka wskaźników dla kodu obiektowego.
Metryki dla kodu obiektowego
- głębokość drzewa spadkowego,
- ważona liczba metod,
- liczba funkcji składowych,
- liczba dzieci oraz
- sprzężenie między obiektami.
Korzystając z podstawy kodu, próbowali skorelować te wskaźniki z gęstością defektów i nakładem prac konserwacyjnych przy użyciu analizy kowariantnej. Późniejsze badania przeprowadziły podobną analizę w setkach projektów Java Source Forge w celu określenia ich cech w stosunku do CK Metrics i niektórych dodatkowych metryk zaproponowanych później.
Dane powstałe w kontekście recenzji kodu
Wady można podzielić na wiele kryteriów:
- nasilenie: (poważne, niewielkie, kosmetyczne, badane / nieznane),
- typ (logika, literówka, pisownia, standardowe naruszenie kodowania itp.),
- pochodzenie / ograniczenie fazowe (wymagania, projekt, kod itp.).
Istnieją również wskaźniki przygotowania i kontroli (czas na recenzenta, czas na wiersz kodu) i gęstość defektów (na KLOC (tysiąc linii kodu), na minutę czasu inspektora / recenzenta).
Wykreślenie tych wartości na wykresach kontrolnych może pokazać nam, czy jesteśmy w granicach procesu (na przykład zespół, który sprawdza 200 wierszy kodu, który nie znajduje żadnych defektów w grupie, która średnio dwudziestu pięciu defektów na KLOC może działać nieprawidłowo).
Inne dane
Inne dane, które mogą pomóc, obejmują te dla
Ograniczenia analizy
Istnieją ogromne ograniczenia wartości metryk. Błędy naprawione na programistę mogą znaczyć prawie wszystko, a kiedy zaczniesz karać lub nagradzać za ten pomiar, założę się, że błędy będą liczniejsze i bardziej szczegółowe, a mieszanka trudnych do łatwych błędów zmieni się również, gdy zespół wiśni wybierze ścigać się, aby mieć jak najwięcej.
Występuje także pewne rozproszenie uwagi i potencjalnie utrata koncentracji i przyjemności, które mogą wynikać z uciążliwych pomiarów. Nie możesz stać się bardziej elegancki (i obciążony emocjonalnie) niż poeta z jeziora, taki jak Wordsworth, który powiedział:
Sweet is the lore which Nature brings;
Our meddling intellect
Mis-shapes the beauteous forms of things:--
We murder to dissect.
Chociaż oprogramowanie nie jest dokładnie naturą, daj mi trochę swobody, ponieważ myślałem, że nigdy nie będę mógł używać niczego z liceum z literatury angielskiej.
Zwinność można uznać za reakcję na scentralizowany, duży proces. Czasami ten tryb pracy może wymagać tak dużego wysiłku analitycznego, że zdolność do osiągnięcia przepływu podczas tworzenia oprogramowania prawie zniknęła.
Chcę dodać alternatywną odpowiedź, która wskazuje na odejście od standardowej praktyki inżynierii oprogramowania do innej dziedziny w celu kradzieży podstawowych narzędzi, które możemy dostosować w razie potrzeby. Ludzie zajmujący się zapewnianiem jakości zajmują się produkcją, wydajnością oraz wykrywaniem wad i zapobieganiem im, podobnie jak twórcy oprogramowania.
http://en.wikipedia.org/wiki/Seven_Basic_Tools_of_Quality
Lubię tabelę kontrolną.
http://en.wikipedia.org/wiki/Control_chart
Wykonaj działanie, wykreśl metrykę, zrób inną, wykreśl metrykę i tak dalej. Na przykład wykres zatwierdza na dzień. Wykres rozproszy dane w zakresie od pewnego minimum do pewnego maksimum. Być może później można scharakteryzować wyniki, aby ustalić, że gdy wartość jest niska, coś utrudnia postęp, a gdy jest zbyt wysoka, praca rozpoczyna się w szybki, ale niechlujny sposób. To, jak zachęcisz pracowników do przyspieszenia lub zwolnienia, zależy od ciebie.
Dane osobowe mogą być czymś, co można skorelować, zaczynając od pytania typu „Czuję się najbardziej produktywny, kiedy ...”
Stare stwierdzenie, że mierzymy, co się robi, może doprowadzić do zaatakowania problemu na podstawie tego, co uważasz za czynnik ograniczający
lub wiele czynników w kolejności priorytetów na podstawie diagramu Pareto.
http://en.wikipedia.org/wiki/Pareto_chart
źródło