©Ian Sommerville 2000 Inżynieria oprogramowania, Rozdział 22Slide 1 Zarządzanie personelem l Omówienie znaczenia personelu w procesie inżynierii oprogramowania.

Prezentacja na temat: "©Ian Sommerville 2000 Inżynieria oprogramowania, Rozdział 22Slide 1 Zarządzanie personelem l Omówienie znaczenia personelu w procesie inżynierii oprogramowania."— Zapis prezentacji:

1 ©Ian Sommerville 2000 Inżynieria oprogramowania, Rozdział 22Slide 1 Zarządzanie personelem l Omówienie znaczenia personelu w procesie inżynierii oprogramowania

2 ©Ian Sommerville 2000 Inżynieria oprogramowania, Rozdział 22Slide 2 Cele l Znać proste modele ludzkiej pamięci, rozwiązywania problemów i motywacji oraz niektóre ich konsekwencje dla menedżerów tworzenia oprogramowania. l Znać podstawowe kwestie pracy zespołowej, tzn. skład zespołu, spójność zespołu, komunikację w zespole i organizację w zespole. l Znać niektóre kwestie związane z wyborem i zatrzymywaniem personelu firmy budującej oprogramowanie. l Znać podstawy P-CMM - modelu będącego zrębem zwiększania umiejętności twórców oprogramowania w firmie.

3 ©Ian Sommerville 2000 Inżynieria oprogramowania, Rozdział 22Slide 3 Zawartość l Ograniczenia myślenia l Praca zespołowa l Wybieranie i zatrzymywanie personelu l Model P-CMM

4 ©Ian Sommerville 2000 Inżynieria oprogramowania, Rozdział 22Slide 4 Personel l Personel pracujący dla firmy tworzącej oprogramowanie to jej największy majątek. l Stanowi kapitał intelektualny i tylko od menedżerów zależy, czy firma osiągnie największy możliwy zwrot z inwestycji w ludzi. l W firmach i gospodarkach mających sukcesy osiąga się to jedynie wówczas, gdy ludzie są szanowani przez przedsiębiorstwo. l Ludziom należy przypisać poziom odpowiedzialności i wynagrodzenia odpowiadający ich umiejętnościom.

5 ©Ian Sommerville 2000 Inżynieria oprogramowania, Rozdział 22Slide 5 Skuteczne zarządzanie l Polega więc na zarządzaniu personelem przedsiębiorstwa. l Menedżerowie przedsięwzięć muszą rozwiązywać problemy technologiczne i nietechnologiczne przy pomocy ludzi w swoich zespołach w jak najbardziej wydajny sposób. l Muszą ludzi motywować, planować i organizować ich pracę oraz dbać o to, aby praca była wykonana rzetelnie. l Złe zarządzanie personelem to jedna z najważniejszych przyczyn niepowodzeń przedsięwzięć.

6 ©Ian Sommerville 2000 Inżynieria oprogramowania, Rozdział 22Slide 6 Ograniczenia myślenia l Indywidualne zdolności są bardzo różne. Te różnice odzwierciedlają różnice w inteligencji, wykształceniu i doświadczeniu, ale większość z nich prawdopodobnie wynika z pewnych podstawowych ograniczeń naszego myślenia. l Są one konsekwencjami sposobu przechowywania informacji w naszych mózgach. Nie trzeba szczegółowo znać procesu poznawczego. l Znajomość ograniczeń sposobu naszego myślenia jest przydatna. Pomaga w zrozumieniu, dlaczego niektóre metody inżynierii oprogramowania są skuteczne i daje wyobrażenie o interakcjach między ludźmi w zespole tworzącym oprogramowanie.

7 ©Ian Sommerville 2000 Inżynieria oprogramowania, Rozdział 22Slide 7 Organizacja pamięci l Organizacja ludzkiej pamięci jest hierarchiczna. Ma trzy odrębne, połączone ze sobą obszary. Pamięć krótka o szybkim czasie dostępu i małej pojemności. Do niej są przekazywane wejściowe bodźce do wstępnego przetworzenia. Tę pamięć można przyrównać do rejestrów komputera. Służy do przetwarzania, a nie do przechowywania danych. Obszary pamięci roboczej o większej pojemności. Ten obszar charakteryzuje się dłuższym czasem dostępu. Służy do przetwarzania informacji, ale może też zatrzymać pewne informacje do dalszego przetwarzania przez okres dłuższy niż w wypadku pamięci krótkiej. Nie służy do przechowywania informacji przez długi czas. Kontynuując analogie komputera, tę pamięć można by przyrównać do pamięci RAM, w której przechowuje się informacje na czas obliczeń. Pamięć długa. Ma wielka pojemność, dość długi czas dostępu i zawodny mechanizm wyszukiwania (zapominamy o pewnych rzeczach). Pamięć długa służy do „trwałego” przechowywania informacji. Tę pamięć można by przyrównać do pamięci dyskowej komputera.

8 ©Ian Sommerville 2000 Inżynieria oprogramowania, Rozdział 22Slide 8 Pamięć krótka l Informacja o problemie trafia do pamięci krótkiej w wyniku czytania dokumentów i rozmów z ludźmi. Jest następnie integrowana z innymi istotnymi informacjami pobranymi z pamięci długiej i pamięci roboczej. l Ograniczony rozmiar pamięci krótkiej ogranicza nasz proces poznawczy. W swym klasycznym eksperymencie Miller (1957) stwierdził, że pamięć krótka może przechowywać około siedmiu kwantów informacji. Kwant informacji nie ma stałego rozmiaru, ale jest spójnym bytem informacyjnym. Może to być numer telefoniczny, przeznaczenie obiektu lub nazwa ulicy. l Jeśli do rozwiązania problemu trzeba więcej informacji, niż mieści się w pamięci krótkiej, to konieczne jest przetwarzanie i transferowanie informacji w procesie pobierania danych wejściowych. Może to prowadzić do utraty informacji.

9 ©Ian Sommerville 2000 Inżynieria oprogramowania, Rozdział 22Slide 9 Organizacja ludzkiej pamięci Pamięć robocza Bodźce wejściowe Pamięć krótka Pamięć długa (duża pojemność, powolny dostęp) Pamięć długa (duża pojemność, powolny dostęp)

10 ©Ian Sommerville 2000 Inżynieria oprogramowania, Rozdział 22Slide 10 Poznawcze “klocki” w programie sortującym Pętla (przetwórz całą tablicę) Pętla (przetwórz nieposortowaną część tablicy) Porównaj sąsiednie elementy Przestaw je, jeśli jest to konieczne, aby mniejszy był wcześniej Przestaw je, jeśli jest to konieczne, aby mniejszy był wcześniej

11 ©Ian Sommerville 2000 Inżynieria oprogramowania, Rozdział 22Slide 11 Pamięć długa l Po ustaleniu wewnętrznej struktury znaczeniowej programu, wiedza o niej jest przenoszona do pamięci długiej. Jeśli się z niej regularnie korzysta, to nie zapomni się jej. Można ja bez większej trudności przedstawić za pomocą różnych notacji. l Wydaje się więc, że uczymy się w kategoriach abstrakcji wysokiego poziomu, a nie szczegółów niskiego poziomu.

12 ©Ian Sommerville 2000 Inżynieria oprogramowania, Rozdział 22Slide 12 Klasy wiedzy l Wiedza znaczeniowa. To wiedza o kwestiach takich jak działanie instrukcji przypisania, o pojęciu klasy, sposobie działania metody wyszukiwania w tablicy z haszowaniem i informacjach o strukturach organizacyjnych. Te wiedzę zdobywa się przez doświadczenie i naukę. Jest ona przechowywania w sposób niezależny od reprezentacji. l Wiedza składniowa. To szczegółowa wiedza o reprezentacji, np. jak napisać opis obiektu w UML, jakie funkcje standardowe są dostępne w pewnym języku oprogramowania, czy przypisanie zapisuje się za pomocą symbolu „=” czy „-” itd. Wydaje się, że ta wiedza jest przechowywana w postaci nieprzetworzonej.

13 ©Ian Sommerville 2000 Inżynieria oprogramowania, Rozdział 22Slide 13 Wiedza składniowa i znaczeniowa Wiedza zadaniowa Wiedza komputera Wiedza znaczeniowa Wiedza składniowa

14 ©Ian Sommerville 2000 Inżynieria oprogramowania, Rozdział 22Slide 14 Rozwiązywanie problemów l Wymyślenie i napisanie programu to proces rozwiązywania problemu. l Zbudowanie systemu oprogramowania wymaga zrozumienia problemu, opracowania strategii rozwiązywania i następnie przekształcenia jej w program. l W pierwszej fazie sformułowanie problemu przechodzi z pamięci krótkiej do pamięci roboczej. l Tam jest integrowane z istniejącą wiedzą z pamięci długiej i analizowane w celu wypracowania ogólnego rozwiązania. l Na końcu to ramowe rozwiązanie jest udoskonalane i przyjmuje postać wykonywalnego programu.

15 ©Ian Sommerville 2000 Inżynieria oprogramowania, Rozdział 22Slide 15 Rozwiązywanie problemów Pamięć długa Nowa wiedza Istniejąca wiedza Nowa wiedza Istniejąca wiedza Pamięć robocza Rozwiązywanie Problem Częściowe rozwiązania

16 ©Ian Sommerville 2000 Inżynieria oprogramowania, Rozdział 22Slide 16 Proces projektowania programu l Zintegruj istniejącą wiedzę komputerową z wiedzą zadaniową w celu utworzenia nowej wiedzy, a więc zrozumienia problemu. l Zbuduj model znaczeniowy rozwiązania. Sprawdź go względem problemu i udoskonalaj do czasu, aż stanie się satysfakcjonujący. l Przedstaw ten model za pomocą jakiegoś języka programowania lub notacji projektowej.

17 ©Ian Sommerville 2000 Inżynieria oprogramowania, Rozdział 22Slide 17 Dobór personelu l Menedżerowie podejmujący decyzje, kogo przyjąć do długotrwałego przedsięwzięcia, powinni wziąć pod uwagę zdolność do rozwiązywania problemów i doświadczenie z dziedziny zastosowania, a nie umiejętność programowania w konkretnym języku. l Gdy problem jest już zrozumiany, doświadczeni programiści napotkają w przybliżeniu ten sam poziom trudności przy pisaniu programu niezależnie od zastosowanego języka programowania. l Znajomość języka jest niezbędna, a jej udoskonalenie trwa (zwłaszcza w wypadku złożonych języków takich jak C++). l Z doświadczeń wynika jednak, że nauczenie się nowego języka jest znacznie łatwiejsze niż opanowanie umiejętności rozwiązywania problemów.

18 ©Ian Sommerville 2000 Inżynieria oprogramowania, Rozdział 22Slide 18 Pisanie programu l Przy przekształceniu modelu znaczeniowego w program zwykle robi się mniej błędów, jeśli język programowania obejmuje struktury pasujące do struktur znaczeniowych najniższego poziomu, które programista rozumie. Zależy to od konkretnej osoby, ale najczęściej te struktury odpowiadają pojęciom, takim jak przypisania, pętle, instrukcje warunkowe, ukrywanie informacji, obiekty, dziedziczenie itd. Im lepiej język programowania pasuje do tych pojęć, tym łatwiej jest napisać program.

19 ©Ian Sommerville 2000 Inżynieria oprogramowania, Rozdział 22Slide 19 Języki wysokiego poziomu l Programy zapisane w językach wysokiego poziomu, takich jak Java, powinny więc zawierać mniej błędów niż napisane w asemblerze, ponieważ struktury znaczeniowe niskiego poziomu można w Javie zakodować bezpośrednio jako instrukcje języka. Gdy miesza się pojęcia obiektowe i funkcyjne, mogą się pojawić kłopoty. Może to wystąpić na przykład wówczas, gdy w firmie ustalono standard funkcyjnej metody analizy (np. SADT), a proces projektowania i programowania jest obiektowy.

20 ©Ian Sommerville 2000 Inżynieria oprogramowania, Rozdział 22Slide 20 Programowanie strukturalne l Korzystając z tego modelu można także wyjaśnić, dlaczego programowanie strukturalne jest najlepszą strategią organizowania sterowania programu. Podstawą programowania strukturalnego są struktury znaczeniowe, takie jak pętle i instrukcje warunkowe. Pamięć krótka programisty nie jest więc przeciążania, ma on zatem mniejszą szansę na popełnienie błędu. Programy strukturalne są łatwiejsze do zrozumienia, ponieważ można je czytać od początku do końca. Abstrakcje tworzące klocki mogą być budowane bez zaglądania do innych części programu. Pamięć krótka może zająć się jedną częścią kodu. Nie ma potrzeby pobieranie z pamięci roboczej informacji o innych częściach programu, które maja wpływ na tę część.

21 ©Ian Sommerville 2000 Inżynieria oprogramowania, Rozdział 22Slide 21 Motywacja l Jedna z ról menedżerów przedsięwzięć jest motywowanie osób, które z nimi pracują. l Maslow (1954) napisał, że ludzi motywuje się przez spełnianie ich potrzeb. l Potrzeby te rozłożono na kilka poziomów. Najniższe poziomy tej hierarchii odpowiadają potrzebom podstawowym, takim jak jedzenie, sen itd. oraz potrzebie bezpieczeństwa w swoim środowisku. Potrzeby społeczne to potrzeby poczucia, że jest się członkiem grupy społecznej. Potrzeby szacunku to potrzeby bycia respektowanym przez innych, a potrzeby samorealizacji są związane z rozwojem osobistym. Człowiek nadaje większy priorytet potrzebom z niskich poziomów, takim jak głód i zaspokaja je przed bardziej abstrakcyjnymi potrzebami z wyższych poziomów.

22 ©Ian Sommerville 2000 Inżynieria oprogramowania, Rozdział 22Slide 22 Hierarchia potrzeb człowieka Potrzeby samorealizacji Potrzeby fizjologiczne Potrzeby bezpieczeństwa Potrzeby społeczne Potrzeby szacunku

23 ©Ian Sommerville 2000 Inżynieria oprogramowania, Rozdział 22Slide 23 W firmie l Zapewnienie spełnienia potrzeb społecznych, szacunku i samorealizacji jest więc najistotniejsze z menedżerskiego punktu widzenia. l Spełnienie potrzeb społecznych oznacza zgodę na spotykanie się ze współpracownikami i zapewnienie miejsc na takie spotkania. Nieformalne i łatwe w użyciu kanały komunikacyjne, takie jak poczta elektroniczna, są bardzo ważne. l Spełnienie potrzeby szacunku wymaga pokazania ludziom, że są wysoko oceniani przez firmę. Publiczne docenianie osiągnięć jest prostym i skutecznym sposobem realizacji tego celu. Pracownicy muszą mieć świadomość, że są wynagradzani na poziomie odpowiadającym ich umiejętnościom i doświadczeniu. l Spełnienie potrzeby samorealizacji wymaga pokazania ludziom odpowiedzialności za ich pracę, przydzielenie im trudnych (ale nie niemożliwych do wykonania zadań) i zaoferowanie programu szkoleń, który umożliwi im rozwijanie swoich umiejętności.

24 ©Ian Sommerville 2000 Inżynieria oprogramowania, Rozdział 22Slide 24 Trzy typy profesjonalistów l Nastawieni na zadania to ci, dla których motywacja jest wykonywana przez nich praca. W wypadku inżynierii oprogramowania są to technicy, których motywuje wyzwanie intelektualne związane z tworzeniem oprogramowania. l Nastawieni na siebie to ci, którzy są motywowani głównie przez swój osobisty sukces i sławę. Tworzenie oprogramowania jest dla nich środkiem umożliwiającym osiąganie własnych celów. l Nastawieni na interakcję to ci, których motywuje obecność i działania współpracowników. W miarę jak tworzenie oprogramowanie jest coraz bardziej skoncentrowane na użytkowniku, osoby poświęcone interakcji są coraz bardziej ważniejsze w inżynierii oprogramowania.

25 ©Ian Sommerville 2000 Inżynieria oprogramowania, Rozdział 22Slide 25 Praca zespołowa l Większość profesjonalnego oprogramowana jest tworzona przez zespoły składające się z dwustu do kilkuset osób. Nie ma możliwości, aby wszyscy członkowie tak wielkiego zespołu wydajnie pracowali razem nad jednym problemem. Tak wielkie zespoły dzieli się więc na kilka grup. l Każda grupa odpowiada za przedsięwzięcie polegające na budowie jakiegoś podsystemu. Przyjmuje się ogólną zasadę, że grupy w przedsięwzięciu inżynierii oprogramowania nie powinny mieć więcej niż ośmiu członków. l Stworzenie małych grup umożliwia ograniczenie problemów komunikacyjnych. Cała grupa może zasiąść na spotkaniu przy jednym stole. Jej członkowie mogą się też spotkać w swoich pokojach. Żadne skomplikowane struktury komunikacyjne nie są konieczne.

26 ©Ian Sommerville 2000 Inżynieria oprogramowania, Rozdział 22Slide 26 Tworzenie grupy l Utworzenie grupy, która będzie wydajnie pracować, jest więc krytycznym zadaniem menedżera. l Ważne jest, aby w grupie panowała równowaga umiejętności technicznych, doświadczenia i osobowości. l Udane grupy to jednak więcej niż po prostu zespól osób o właściwej równowadze umiejętności. l W dobrej grupie panuje duch zespołu, tzn. jej członkowie są zmotywowani sukcesem grupy na równi z realizacja własnych celów. l Menedżerowie powinni więc zachęcać do jawnych czynności „budowania zespołu”, aby wypracować owe zasadnicze poczucie lojalności grupowej.

27 ©Ian Sommerville 2000 Inżynieria oprogramowania, Rozdział 22Slide 27 Czynniki wpływające na pracę grupową l Skład grupy. Czy panuje w niej właściwa równowaga umiejętności, doświadczeń i osobowości? l Spójność grupy. Czy w grupie myśli się o niej jako o zespole, czy też o grupie osób pracujących razem? l Komunikacja w grupie. Czy członkowie grupy skutecznie się ze sobą porozumiewają? l Organizacja grupy. Czy zespół jest zorganizowany tak, że każdy czuje się dowartościowany i jest zadowolony ze swojej roli w grupie?

28 ©Ian Sommerville 2000 Inżynieria oprogramowania, Rozdział 22Slide 28 Skład grupy l Grupa zawierająca uzupełniające się osobowości może pracować lepiej niż grupa tworzona jedynie na podstawie zdolności technicznych. Ludzie motywowani pracą najprawdopodobniej będą najlepsi technicznie. Ludzie nastawieni na siebie będą zapewne najskuteczniejsi w posuwaniu pracy do przodu w celu jej ukończenia. Ludzie zajmujący się komunikacją będą szczególnie ważni jako pomoc w komunikacji w ramach grupy. Uważam, że najważniejsze jest uwzględnienie w grupie osób zajmujących się komunikacją. Lubią oni rozmawiać z ludźmi, są więc w stanie bardzo wcześnie wykrywać napięcia i nieporozumienia. Mogą pomóc w rozwiązywaniu problemów osobowościowych i związanych z odmiennością, zanim będą miały poważny wpływ na grupę.

29 ©Ian Sommerville 2000 Inżynieria oprogramowania, Rozdział 22Slide 29 Spójność grupy l Członkowie spójnej grupy uważają ją za bardziej istotną od osób do niej należących. Członkowie dobrze prowadzonej, spójnej grupy są wobec niej lojalni. Identyfikują się z celami grupy i z innymi jej członkami. Starają się chronić ja jako całość przed zewnętrznymi wpływami. To sprawia, że grupa staje się solidna i zdolna do radzenia sobie z problemami i nieoczekiwanymi sytuacjami. Grupa radzi sobie ze zmianami przez oferowanie członkom wzajemnego wsparcia i pomocy.

30 ©Ian Sommerville 2000 Inżynieria oprogramowania, Rozdział 22Slide 30 Zalety spójnej grupy l Można wypracować grupowy standard jakości. Standardy są ustawiane jednogłośnie, a zatem grupowy standard będzie prawdopodobnie lepiej przestrzegany niż standard narzucony grupie z zewnątrz. l Członkowie grupy blisko ze sobą współpracują. Osoby należące do grupy uczą się od siebie nawzajem. Zahamowania wynikające z niewiedzy są zminimalizowane przez zachętę do wzajemnego nauczania. l Członkowie grupy mogą nawzajem znać swoje prace. Gdy członkowie opuszczają grupę, można zachować ciągłość. l Można urzeczywistniać programowanie pozbawione indywidualizmu. Programy są uważane za własność grupy, a nie poszczególnych osób.

31 ©Ian Sommerville 2000 Inżynieria oprogramowania, Rozdział 22Slide 31 Komunikacja w grupie l Zasadniczą sprawą jest zapewnienie dobrej komunikacji między członkami grupy tworzącej oprogramowanie. Członkowie grupy muszą wymieniać informacje o stanie swoich prac, podjętych decyzjach projektowych i koniecznych zmianach poprzednich decyzji. Dobra komunikacja wzmacnia także spójność grupy, ponieważ jej członkowie poznają motywacje oraz silne i słabe strony innych członków.

32 ©Ian Sommerville 2000 Inżynieria oprogramowania, Rozdział 22Slide 32 Podstawowe czynniki mające wpływ na skuteczność komunikacji l Wielkość grupy l Struktura grupy l Skład grupy l Fizyczne środowisko pracy grupy

33 ©Ian Sommerville 2000 Inżynieria oprogramowania, Rozdział 22Slide 33 Organizacja grupy l Małe grupy programistów są zwykle zorganizowane w nieformalny sposób. l Lider grupy bierze udział w tworzeniu razem z innymi jej członkami. Może wyłonić się lider techniczny, który skutecznie zapanuje nad produkcją oprogramowania. l W nieformalnej grupie pracę do wykonania omawia się w ramach grupy jako całości i przydziela zadania zgodnie ze zdolnościami i doświadczeniem. l Projektowanie systemu na wysokim poziomie wykonują wyżsi rangą członkowie grupy, ale projekty niskiego poziomu są zadaniem osoby przydzielonej do konkretnego zadania. l Grupa nieformalna może osiągnąć powodzenie zwłaszcza wówczas, gdy większość jej członków jest ludźmi doświadczonymi i kompetentnymi.

34 ©Ian Sommerville 2000 Inżynieria oprogramowania, Rozdział 22Slide 34 Zespół wodza-programisty Administrator Narzędziowiec Specjalista do SO Administrator Autor dokumentacji technicznej Autor dokumentacji technicznej Wódz- -programista Wódz- -programista Programista zapasowy Programista zapasowy Bibliotekarz Komunikacja z otoczeniem

35 ©Ian Sommerville 2000 Inżynieria oprogramowania, Rozdział 22Slide 35 Wybieranie i zatrzymywanie personelu l Jedną z ról menedżera przedsięwzięcia jest wybór personelu do pracy przy przedsięwzięciu. l W wyjątkowych wypadkach menedżerowie mogą zatrudnić osoby najlepiej nadające się do tej pracy, niezależnie od innych zobowiązań i kwestii budżetowych. l Zwykle menedżer nie może swobodnie wybierać personelu. Musi on wykorzystać tych, którzy są dostępni w firmie, musi znaleźć ludzi szybko i może mieć ograniczony budżet. l To ograniczenie budżetu może mieć wpływ na liczbę (drogich) doświadczonych inżynierów, którzy będą pracować przy przedsięwzięciu.

36 Czynniki wpływające na wybór personelu CzynnikWyjaśnienie Doświadczenie Jeśli przedsięwzięcie ma doprowadzić do zbudowania udanego systemu, to w dziedzinie jego twórcy muszą rozumieć dziedzinę zastosowania. zastosowania DoświadczenieMoże być istotne, jeśli prace obejmują programowanie na niskim poziomie. w pracy z platformąW przeciwnym wypadku zwykle nie jest krytycznym atrybutem. DoświadczenieZwykle jest istotne jedynie w wypadku krótkotrwałych przedsięwzięć, przy w pracy z językiemktórych nie ma czasu na naukę nowego języka. programowania ZdobyteMoże być podstawową wskazówką co do tego, co kandydat powinien umieć, wykształceniei o jego zdolności do uczenia się. Ten czynniki jest coraz mniej istotny, gdy inżynierowie zdobywają coraz więcej doświadczenia w wielu przedsięwzięciach. ZdolnościSą ważne, ponieważ personel przedsięwzięcia musi się porozumieć ustnie komunikacyjnei pisemnie z innymi inżynierami, menedżerami i klientami. Zdolność doTę zdolność można ocenić przyglądając się różnym rodzajom doświadczeń przystosowania sięzdobytych przez kandydata. To ważny atrybut, ponieważ wynika z niego zdolność do uczenia się. NastawieniePersonel przedsięwzięcia powinien być pozytywnie nastawiony do wykonywanej pracy i chcieć zdobywać nowe umiejętności. To bardzo ważny atrybut, ale zwykle bardzo trudny do oceny. OsobowośćTo bardzo ważny atrybut, ale zwykle trudny do oceny, kandydaci muszą być racjonalnie zgodni z innymi członkami zespołu. Żaden konkretny typ osobowości nie jest bardziej lub mniej odpowiedni do inżynierii oprogramowania.

37 ©Ian Sommerville 2000 Inżynieria oprogramowania, Rozdział 22Slide 37 l informacje dostarczane przez kandydatów o ich przeszłości i doświadczeniu (ich życiorys lub CV) l informacje zdobyte przez wywiady z kandydatami l rekomendacje od innych osób, które współpracowały z kandydatami. Decyzję, kogo przyjąć do przedsięwzięcia, zwykle podejmuje się na podstawie informacji następujących trzech rodzajów:

38 ©Ian Sommerville 2000 Inżynieria oprogramowania, Rozdział 22Slide 38 l Miejsce pracy ma istotny wpływ na ludzką wydajność i zadowolenie z pracy. Za pomocą eksperymentów psychologicznych wykazano, że na zachowanie mają wpływ wielkość pomieszczenia, umeblowanie, temperatura, wilgotność, jasność i jakość światła, hałas, poziom postrzegania prywatności. l Zachowanie grupy zależy od organizacji architektonicznej i udogodnień telekomunikacyjnych. Komunikacja grupowa zależy od architektury budynku i organizacji przestrzeni pracy. l Koszt braku dobrych warunków pracy jest realny i znaczący. Środowiska pracy

39 ©Ian Sommerville 2000 Inżynieria oprogramowania, Rozdział 22Slide 39 Najważniejsze czynniki środowiskowe l Prywatność. Programiści potrzebują miejsca, w którym mogliby się koncentrować i pracować. Potrzebują miejsca, gdzie nikt by im nie przeszkadzał. l Świadomość otoczenia. Ludzie wolą pracować przy świetle naturalnym i z widokiem na otaczające ich środowisko. l Dostosowanie do osobistych potrzeb. Ludzie przyjmują różne style pracy i mają odmienne opinie o wystroju wnętrza. Możliwość przebudowy swojego miejsca pracy tak, aby pasowało do jej stylu, oraz możliwość osobistego gospodarowania swoim środowiskiem, są bardzo ważne.

40 ©Ian Sommerville 2000 Inżynieria oprogramowania, Rozdział 22Slide 40 Warunki pracy l Ludzie lubią indywidualne pokoje, które mogą sobie po swojemu urządzić. Jest tam mniej przerywania i przeszkadzania w pracy niż w otwartych przestrzeniach biurowych. l W otwartych biurach ludziom odmawia się prywatności i cichego środowiska pracy. l Zapewnienie inżynierom oprogramowania oddzielnych pokoi może spowodować znaczący wzrost wydajności. l DeMarco i Lister (1985) porównali wydajność programistów w różnych rodzajach biur. Zauważyli, że czynniki, takie jak oddzielne pomieszczenia i możliwość wykluczenia przerywania pracy, maja znaczący wpływ. Programiści mający dobre warunki pracy byli ponad dwa razy bardziej wydajni niż równie umiejętni programiści pracujący w gorszych warunkach.

41 ©Ian Sommerville 2000 Inżynieria oprogramowania, Rozdział 22Slide 41 Grupowanie pokoi osób i pokoju spotkań grupy Pokój spotkań Wspólna przestrzeń Dzielona dokumentacja Okno

42 ©Ian Sommerville 2000 Inżynieria oprogramowania, Rozdział 22Slide 42 Model P-CMM l Software Engineering Institute (SEI) ze Stanów Zjednoczonych prowadzi długotrwały program ulepszania procesu tworzenia oprogramowania. Częścią tego programu jest CMM (Capability Maturity Model- model dojrzewania zdolności), tzn. model procesu tworzenia oprogramowania. l CMM dotyczy najlepszych praktyk inżynierii oprogramowania. l W celu wspierania tego modelu SEI zaproponował także P-CMM (People Capability Maturity Model- model dojrzewania zdolności ludzi).

43 ©Ian Sommerville 2000 Inżynieria oprogramowania, Rozdział 22Slide 43 Poziomy modelu P-CMM l Początkowy. Doraźnie stosuje się nieformalne metody zarządzania personelem. l Powtarzalny. Ustalenie strategii rozwoju zdolności personelu. l Zdefiniowany. Standaryzacja najlepszych praktyk zarządzania personelem w całej firmie. l Zarządzany. Ustalono i wdrożono ilościowe cele zarządzania personelem. l Optymalizowany. Ciągła koncentracja na zwiększaniu indywidualnych kompetencji i motywacji do pracy.

44 ©Ian Sommerville 2000 Inżynieria oprogramowania, Rozdział 22Slide 44 Cele P-CMM l Poprawa zdolności firmy programistycznej przez zwiększenie zdolności jej siły roboczej. l Upewnienie się, że zdolność do tworzenia oprogramowania jest atrybutem firmy, a nie kilku osób. l Dopasowanie motywacji poszczególnych osób do motywacji firmy. l Utrzymywanie w firmie zasobów ludzkich (tzn. osób z krytycznymi umiejętnościami i wiedzą).

45 Model P-CMM Ustawiczne odnawianie siły roboczej Trenerzy Rozwój kompetencji personelu Ustawiczne odnawianie siły roboczej Trenerzy Rozwój kompetencji personelu Optymalizowany Początkowy Wynagrodzenie Szkolenia Zarządzanie wydajnością Wybór personelu Komunikacja Środowisko pracy Wynagrodzenie Szkolenia Zarządzanie wydajnością Wybór personelu Komunikacja Środowisko pracy Powtarzalny Wprowadź podstawową dyscyplinę do działań siły roboczej Wyrównanie wydajności w firmie Zarządzanie kompetencjami w firmie Praktyki zespołowe Budowa zespołu Mentorzy Wyrównanie wydajności w firmie Zarządzanie kompetencjami w firmie Praktyki zespołowe Budowa zespołu Mentorzy Zarządzany Kultura uczestnictwa Praktyka największej kompetencji Rozwój zawodowy Rozwój kompetencji Planowanie sił roboczych Analiza umiejętności i wiedzy Kultura uczestnictwa Praktyka największej kompetencji Rozwój zawodowy Rozwój kompetencji Planowanie sił roboczych Analiza umiejętności i wiedzy Zdefiniowany Ustawicznie poprawiaj metody zwiększania kompetencji poszczególnych osób i całej firmy Zarządzaj ilościowo przyrostem zdolności siły roboczej firmy i utwórz zespoły zgodne z kompetencjami Rozpoznaj zasadnicze kompetencje i dostosuj do nich działania siły roboczej

46 ©Ian Sommerville 2000 Inżynieria oprogramowania, Rozdział 22Slide 46 Główne tezy l Zarządzanie tworzeniem oprogramowania to głównie zarządzanie ludźmi. Menedżerowie powinni więc rozumieć naturę człowieka, aby nie stawiać sobie lub personelowi nierealnych żądań. l Ludzie mają szybką pamięć krótką, pamięć roboczą i pamięć długą. Wiedza może być nieuporządkowaną wiedzą składniową lub głębszą wiedzą znaczeniową. Rozwiązywanie problemów polega na integracji znaczeniowych z pamięci długiej z nowymi informacjami w pamięci krótkiej. l Czynniki, które można wziąć pod uwagę przy wyborze personelu, to m.in. Doświadczenie z dziedziny zastosowania, zdolność do przystosowywania się i osobowość.

47 ©Ian Sommerville 2000 Inżynieria oprogramowania, Rozdział 22Slide 47 Główne tezy l Grupy tworzące oprogramowanie powinny być małe i spójne. Liderzy grup powinni być kompetentni technicznie. Należy im zapewnić wsparcie administracyjne i techniczne. l Na porozumiewanie się w ramach grupy wpływają takie czynniki jak status członków grupy, wielkość grupy, rozkład płci, osobowość i dostępne kanały komunikacyjne. l Zapewnienie osobistego środowiska pracy z odpowiednimi udogodnieniami komunikacyjnymi i komputerowymi może zwiększyć wydajność i zadowolenie z pracy programistów. l P-CMM (People-Capability Maturity Model) stanowi zrąb i powiązane z nim poradnictwo na temat poprawy zdolności ludzi zatrudnionych w przedsiębiorstwie i zdolności firmy do osiągania korzyści z jej zasobów ludzkich.