Produktywność programowania - Programming productivity

Produktywność programowania (zwana również produktywnością oprogramowania lub produktywnością programistyczną ) opisuje stopień zdolności poszczególnych programistów lub zespołów programistycznych do tworzenia i rozwijania systemów oprogramowania. Produktywność tradycyjnie odnosi się do stosunku ilości wyprodukowanego oprogramowania do poniesionych kosztów. Tutaj delikatność polega na znalezieniu rozsądnego sposobu zdefiniowania ilości oprogramowania.

Terminologia

Produktywność jest ważnym tematem badanym w tak różnych dyscyplinach, jak produkcja, psychologia organizacji, inżynieria przemysłowa, zarządzanie strategiczne, finanse, księgowość, marketing i ekonomia. Poziomy analizy obejmują poziom indywidualny, grupowy, oddziałowy, organizacyjny i krajowy [5]. Ze względu na tę różnorodność nie ma jednoznacznej definicji produktywności i czynników na nią wpływających, chociaż badania są prowadzone od ponad wieku. Podobnie jak w inżynierii oprogramowania, ten brak powszechnej zgody co do tego, co faktycznie stanowi produktywność, jest postrzegany jako główna przeszkoda w uzasadnionej dyskusji na temat produktywności. Poniższe definicje opisują najlepszy konsensus co do terminologii.

Wydajność

Chociaż nie ma powszechnie uzgodnionej definicji produktywności, wydaje się, że istnieje zgoda, zgodnie z którą produktywność opisuje stosunek produkcji do nakładów:

Produktywność = wyjście / wejście

Jednak w różnych dyscyplinach można znaleźć różne pojęcia, a zwłaszcza różne jednostki miary dla danych wejściowych i wyjściowych. W przemyśle wytwórczym zwykle stosuje się prostą zależność między liczbą wyprodukowanych jednostek a liczbą zużytych jednostek. Branże inne niż produkcyjne zwykle wykorzystują roboczogodziny lub podobne jednostki, aby umożliwić porównanie między produkcją a nakładami.

Jedna podstawowa zgoda jest taka, że ​​znaczenie produktywności i środki jej pomiaru różnią się w zależności od tego, jaki kontekst jest poddawany ocenie. W firmie produkcyjnej możliwe konteksty to:

  • pojedyncza maszyna lub system produkcyjny;
  • funkcja produkcyjna, na przykład montaż;
  • proces produkcyjny pojedynczego produktu lub grupy produktów pokrewnych;
  • Fabryka; i
  • cały system fabryczny firmy

Tak długo, jak klasyczne procesy produkcyjne są uważane za prosty miernik produktywności, jest prosty: ile jednostek produktu o określonej jakości jest wytwarzanych, przy jakich kosztach. W przypadku pracy umysłowej wydajność jest znacznie trudniejsza. Jak mierzymy produktywność autorów, naukowców czy inżynierów? Ze względu na rosnące znaczenie pracy opartej na wiedzy (w przeciwieństwie do pracy ręcznej), wielu badaczy próbowało opracować środki pomiaru wydajności, które można zastosować w kontekście pozaprodukcyjnym. Powszechnie uważa się, że charakter pracy opartej na wiedzy zasadniczo różni się od pracy fizycznej, dlatego też oprócz prostego stosunku wydajności do nakładów należy wziąć pod uwagę inne czynniki, np. Jakość, terminowość, niezależność, sukces projektu, zadowolenie klienta i innowacyjność. Jednak społeczności badawcze z żadnej z dyscyplin nie były jeszcze w stanie określić szeroko stosowanych i akceptowanych metod pomiaru produktywności. To samo dotyczy bardziej szczegółowego obszaru produktywności programowania.

Rentowność

Rentowność i wydajność są ze sobą ściśle powiązane i często bywają mylone. Jednakże, ponieważ rentowność jest zwykle definiowana jako stosunek przychodów do kosztów

Rentowność = przychód / koszt

Ma szerszy zakres niż wydajność, tj. Liczba czynników wpływających na rentowność jest większa niż liczba czynników wpływających na produktywność. W szczególności rentowność może się zmienić bez jakiejkolwiek zmiany produktywności, np. Z powodu warunków zewnętrznych, takich jak inflacja kosztów lub cen. Poza tym współzależność między produktywnością a rentownością jest zwykle opóźniona, tj. Wzrost produktywności rzadko znajduje odzwierciedlenie w natychmiastowym wzroście rentowności, który jest bardziej prawdopodobny w perspektywie długoterminowej.

Wydajność

Termin wydajność jest nawet szerszy niż produktywność i rentowność i obejmuje wiele czynników, które mają wpływ na sukces firmy. Dlatego dobrze znane narzędzia kontroli wydajności, takie jak Balanced Scorecard , uwzględniają produktywność jako czynnik centralny, ale nie wyjątkowy. Inne istotne czynniki to np. Postrzeganie firmy przez klientów lub interesariuszy.

Wydajność i efektywność

Wydajność i skuteczność to terminy, które powodują dalsze zamieszanie, ponieważ same w sobie są często mylone, a ponadto często mylona jest wydajność z produktywnością. Różnica między wydajnością a skutecznością jest zwykle wyjaśniana nieformalnie, ponieważ efektywność to robienie rzeczy dobrze, a skuteczność to robienie właściwych rzeczy . Chociaż istnieje wiele innych definicji, istnieje pewna zgoda, że ​​efektywność odnosi się do wykorzystania zasobów i wpływa głównie na wymagany wkład wskaźnika produktywności. Z drugiej strony efektywność wpływa głównie na wynik wskaźnika produktywności, ponieważ zwykle ma to bezpośrednie konsekwencje dla klienta. Skuteczność można zdefiniować jako „zdolność do osiągnięcia pożądanego rezultatu”.

Ogólnie przyjmuje się, że efektywność można określić ilościowo, np. Za pomocą wskaźników wykorzystania, znacznie łatwiej niż efektywność.

Jakość

Tangen stwierdza: „Poprawa jakości, inna niż fakt, że produkty bez błędów zwiększają poziom wyjściowy, nie powinna być uwzględniana w koncepcji produktywności”. Jednak większość klasycznej literatury z dziedzin niezwiązanych z oprogramowaniem, zwłaszcza w obszarze produkcji, nie omawia w sposób wyraźny roli jakości produkcji we wskaźniku produktywności. Nowsze prace z dziedzin niezwiązanych z produkcją koncentrują się w większym stopniu na wiedzy, pracy biurowej lub umysłowej, a tym samym coraz częściej omawiają rolę jakości w odniesieniu do jakości.

Drucker podkreśla znaczenie jakości dla oceny produktywności pracowników umysłowych: „Produktywność pracy opartej na wiedzy musi zatem mieć na celu przede wszystkim uzyskanie jakości - a nie jakości minimalnej, ale optymalnej, jeśli nie maksymalnej. Dopiero wtedy można zapytać:„ Jaka jest objętość ilość pracy? ""

Saari oddaje znaczenie jakości dzięki swojej rozszerzonej recepturze na produktywność:

Całkowita produktywność = (Jakość i ilość produkcji) / (Jakość i ilość nakładów)

Wydaje się jednak, że te wysiłki mające na celu uwzględnienie jakości w określaniu produktywności nie doprowadziły jeszcze do stworzenia koncepcji operacjonalizowalnej. Obecnie nie jest jasne, jak określić ilościowo niejasne terminy „jakość i ilość produkcji” oraz „jakość i ilość nakładów”, nie mówiąc już o obliczeniu współczynnika.

Najnowocześniejsza wydajność programowania

W tworzeniu oprogramowania sprawy są bardziej skomplikowane niż w produkcji towarów. Tworzenie oprogramowania to proces inżynieryjny.

COCOMO II

Boehm był jednym z pierwszych badaczy, którzy systematycznie zajmowali się produktywnością oprogramowania. Jego model szacowania kosztów COCOMO - obecnie COCOMO II - to standardowa wiedza inżynierska oprogramowania. W modelu tym definiuje zbiór czynników wpływających na produktywność, takich jak wymagana niezawodność czy możliwości analityków. Czynniki te były szeroko ponownie wykorzystywane w innych podobnych podejściach do produktywności. Reszta modelu jest oparta na punktach funkcyjnych i ostatecznie liniach kodu źródłowego (LOC). Dobrze znane są ograniczenia LOC jako miary produktywności.

Wydajność oprogramowania Jonesa

Jones jest autorem serii książek na temat produktywności oprogramowania. Oprócz kilku rozważań teoretycznych, jego głównym wkładem jest systematyczne dostarczanie i integracja dużej ilości danych istotnych dla analiz wydajności. W co najmniej dwóch swoich książkach podaje szereg czynników produktywności, ale zwraca również uwagę, że na każdy projekt ma wpływ inny zestaw czynników. Czynniki te mogą stanowić podstawę do oceny wydajności i porównania ze średnimi w przemyśle.

Oto jedna taka lista:

Oto 20 czynników, których ilościowy wpływ na projekty oprogramowania określono na podstawie danych historycznych:

  • Używany język programowania
  • Rozmiar programu
  • Doświadczenie programistów i personelu projektowego
  • Nowość wymagań
  • Złożoność programu i jego danych
  • Zastosowanie strukturalnych metod programowania
  • Klasa programu lub metoda dystrybucji
  • Typ programu z obszaru zastosowania
  • Narzędzia i warunki otoczenia
  • Ulepszanie istniejących programów lub systemów
  • Utrzymywanie istniejących programów lub systemów
  • Ponowne wykorzystanie istniejących modułów i standardowych projektów
  • Generatory programów
  • Języki czwartej generacji
  • Podział geograficzny lokalizacji deweloperskich
  • Potencjał defektu i metody usuwania
  • (Istniejąca) Dokumentacja
  • Prototypowanie przed rozpoczęciem głównego rozwoju
  • Zespoły projektowe i struktury organizacyjne
  • Morale i wynagrodzenie personelu

Punkty funkcyjne

Punkty funkcyjne zostały zaproponowane w 1977 roku przez Albrechta jako lepsza miara rozmiaru oprogramowania niż LOC. W tym sensie opiera się na specyfikacji oprogramowania, a tym samym ma na celu pomiar rozmiaru jego funkcjonalności, a nie samego kodu. Powodem jest to, że rozmiar kodu zależy nie tylko od rozmiaru funkcjonalności, ale także od możliwości programisty: lepsi programiści będą produkować mniej kodu dla tej samej funkcjonalności. Punkty funkcyjne przeszły kilka zmian na przestrzeni lat, głównie przez Międzynarodową Grupę Użytkowników Punktów Funkcyjnych (IFPUG). Grupa ta jest duża i liczy ponad 1200 firm, co świadczy o dość silnej akceptacji tego środka. Jednak w wielu dziedzinach nadal nie ma praktycznego zastosowania, ponieważ często uważa się, że ma zastosowanie tylko do biznesowych systemów informacyjnych.

Inżynieria oprogramowania oparta na wartościach

Kilku badaczy zaproponowało ekonomiczną lub opartą na wartościach inżynierię oprogramowania jako ważny paradygmat przyszłych badań nad inżynierią oprogramowania. Boehm i Huang podkreślają, że ważne jest nie tylko śledzenie kosztów w projekcie oprogramowania, ale także rzeczywistej wartości wypracowanej, tj. Wartości dla klienta. Wyjaśniają, że ważne jest, aby stworzyć uzasadnienie biznesowe oprogramowania i aktualizować je. Zasadniczo inżynieria oprogramowania oparta na wartościach koncentruje się na wartości klienta, mierzonej głównie w jednostkach pieniężnych.

Peopleware

Słynna książka Peopleware: Productive Projects and Teams autorstwa de Marco i Lister zwróciła uwagę szerszej publiczności na znaczenie czynników związanych z ludźmi. Zebrali w wielu projektach informatycznych doświadczenia z dobrą i złą praktyką zarządzania, które mają wpływ na produktywność zespołu. Oni i inni wykazali, że są to decydujące kwestie w inżynierii oprogramowania, ale byli w stanie opisać je tylko anegdotycznie.

Czynniki wpływające na produktywność programowania

Prawdopodobnie istnieje wiele czynników wpływających na produktywność programistyczną jednostek i zespołów. Na przykład proces wytwarzania używanego oprogramowania prawdopodobnie wpływa na efektywność i wydajność zespołu.

Te osobistości z programistów wpływ na używane style kodowania, które z kolei wpływają na produktywność programistów.

Bibliografia

Dalsza lektura