©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 Poznać proste modele ludzkiej pamięci, rozwiązywania problemów i motywacji oraz niektóre ich konsekwencje dla menedżerów tworzenia oprogramowania. l Poznać podstawowe kwestie pracy zespołowej, tzn. skład zespołu, spójność zespołu, komunikację w zespole i organizację w zespole. l Poznać niektóre kwestie związane z wyborem i zatrzymywaniem personelu firmy budującej oprogramowanie. l Poznać podstawy P-CMM - modelu 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 personelem l Polega umiejętnym postępowaniu z personelem przedsiębiorstwa. l Menedżerowie przedsięwzięć muszą rozwiązywać problemy przy pomocy ludzi w swoich zespołach w jak najbardziej wydajny sposób. l Muszą motywować, planować i organizować pracę swojego zespołu 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, lecz również z pewnych podstawowych ograniczeń naszego myślenia. l Są one konsekwencjami sposobu przechowywania informacji w naszych mózgach. 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 ludzkiej 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 może przechowywać około siedmiu kwantów informacji. Tutaj kwant informacji może to być np. 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.

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 np. działanie instrukcji przypisania, pojęcie klasy i informacje o strukturach organizacyjnych. Te wiedzę zdobywa się przez doświadczenie i naukę. 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.

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 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. 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, rys. 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 tylko umiejętność programowania w konkretnym języku. l Chociaż, znajomość języka jest niezbędna, to 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. l Zależy to od konkretnej osoby, ale najlepiej jest jeśli 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 Przykład: 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. l 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, a proces projektowania i programowania jest obiektowy.

20 ©Ian Sommerville 2000 Inżynieria oprogramowania, Rozdział 22Slide 20 Programowanie strukturalne l Istnieje opinia, że 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. l 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 mają 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ą. Natomiast ludzi motywuje się przez spełnianie ich potrzeb. l Potrzeby te można rozłożyć na kilka poziomów. Najniższe poziomy tej hierarchii odpowiadają potrzebom podstawowym, takim jak jedzenie, sen oraz bezpieczeństwo. 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 jak potrzeba szacunku czy samorealizacji.

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 Rola menedżera l Z menedżerskiego punktu widzenia najistotniejsze jest zapewnienie spełnienia potrzeb społecznych, szacunku i samorealizacji. l Trzeba zapewnić miejsce na spotkania grupy oraz łatwe w użyciu kanały komunikacyjne, takie jak np. poczta elektroniczna. l Należy publiczne doceniać osiągnięcia oraz wynagradzać na poziomie odpowiadającym umiejętnościom i doświadczeniu. l Należy pokazać ludziom odpowiedzialności za ich pracę, Przydzielać im trudne, ale nie niemożliwych do wykonania zadania i oferować możliwości szkolenia.

24 ©Ian Sommerville 2000 Inżynieria oprogramowania, Rozdział 22Slide 24 Typy profesjonalistów, a sposoby motywacji l Nastawieni na zadania to ci, dla których motywacja jest wykonywana przez nich praca. Motywuje ich 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. Te osoby, poświęcone interakcji, są coraz ważniejsze w procesie 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 kilkuset osób. Tak wielkie zespoły dzieli się grupy. 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 np.. zasiąść na spotkaniu przy jednym stole.

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ół osób o właściwej równowadze umiejętności. W dobrej grupie panuje duch zespołu, tzn. jej członkowie są zmotywowani sukcesem grupy na równi z realizacją własnych celów. Menedżerowie powinni więc zachęcać wypracowania poczucia 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 tylko też o zbiorze 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 zwykle pracuje 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ą.

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 Lider grupy bierze udział w tworzeniu razem z innymi jej członkami, ale może wyłonić się lider techniczny, który skutecznie zapanuje nad produkcją oprogramowania. l 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 od testów Specjalista od testów 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. Środowisko 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. Umożliwienie przebudowy swojego miejsca pracy oraz osobistego gospodarowania swoim środowiskiem.

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 (ideał) 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 zaproponowano 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 Ogólnie pamięć dzielimy na krótką, roboczą i długą. Z kolei posiadana wiedza może być nieuporządkowaną wiedzą składniową lub głębszą wiedzą znaczeniową. Rozwiązywanie problemów polega na integracji wiedzy znaczeniowej w pamięci długiej z nowymi informacjami w pamięci krótkiej. l Czynniki, które należy 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. Najlepiej jak liderzy grup są 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.