Zarządzanie projektami oprogramowania - Software project management

Zarządzanie projektami oprogramowania to sztuka i nauka planowania i prowadzenia projektów oprogramowania. Jest to podkategoria zarządzania projektami, w której projekty oprogramowania są planowane, wdrażane, monitorowane i kontrolowane.

Historia

W latach siedemdziesiątych i osiemdziesiątych przemysł oprogramowania rozwijał się bardzo szybko, ponieważ firmy komputerowe szybko dostrzegły stosunkowo niski koszt produkcji oprogramowania w porównaniu z produkcją sprzętu i obwodów. Aby zarządzać nowymi działaniami programistycznymi, firmy stosowały ustalone metody zarządzania projektami, ale harmonogramy projektów ulegały ślizganiu podczas testów, zwłaszcza gdy w szarej strefie pojawiło się zamieszanie między specyfikacjami użytkownika a dostarczonym oprogramowaniem. Aby móc uniknąć tych problemów, metody zarządzania projektami oprogramowania koncentrowały się na dopasowaniu wymagań użytkowników do dostarczanych produktów, w metodzie znanej obecnie jako model kaskadowy .

W miarę dojrzewania branży analiza błędów zarządzania projektami oprogramowania wykazała, że ​​najczęstsze przyczyny to:

  1. Niewystarczające zaangażowanie użytkownika końcowego
  2. Słaba komunikacja między klientami, programistami, użytkownikami i kierownikami projektów
  3. Nierealistyczne lub nieartykułowane cele projektu
  4. Niedokładne szacunki potrzebnych zasobów
  5. Źle zdefiniowane lub niekompletne wymagania i specyfikacje systemowe
  6. Słabe raportowanie statusu projektu
  7. Źle zarządzane ryzyko
  8. Wykorzystanie niedojrzałej technologii
  9. Niezdolność do obsługi złożoności projektu
  10. Niedbałe praktyki programistyczne
  11. Polityka interesariuszy (np. Brak wsparcia kierownictwa lub polityka między klientem a użytkownikami końcowymi)
  12. Presja komercyjna

Pięć pierwszych pozycji z powyższej listy pokazuje trudności w artykułowaniu potrzeb klienta w taki sposób, aby odpowiednie zasoby mogły zapewnić właściwe cele projektu. Specyficzne narzędzia do zarządzania projektami oprogramowania są przydatne i często konieczne, ale prawdziwą sztuką zarządzania projektami oprogramowania jest zastosowanie właściwej metody, a następnie wykorzystanie narzędzi do jej wspierania. Bez metody narzędzia są bezwartościowe. Od lat sześćdziesiątych XX wieku producenci oprogramowania opracowali na własny użytek kilka metod zarządzania projektami oprogramowania własnościowego, podczas gdy firmy konsultingowe opracowały podobne metody dla swoich klientów. Obecnie metody zarządzania projektami oprogramowania wciąż ewoluują, ale obecny trend odchodzi od modelu kaskadowego do bardziej cyklicznego modelu dostarczania projektów, który imituje proces tworzenia oprogramowania.

Proces tworzenia oprogramowania

Proces tworzenia oprogramowania jest zaniepokojony przede wszystkim z punktu widzenia produkcji rozwoju oprogramowania , w przeciwieństwie do aspektów technicznych, takich jak narzędzi programowych . Te procesy istnieją przede wszystkim w celu wspierania zarządzania tworzeniem oprogramowania i są zwykle skośne w kierunku rozwiązywania problemów biznesowych. Wiele procesów tworzenia oprogramowania można uruchomić w podobny sposób, jak ogólne procesy zarządzania projektami. Przykłady:

  • Komunikacja interpersonalna oraz zarządzanie i rozwiązywanie konfliktów . Aktywna, częsta i szczera komunikacja jest najważniejszym czynnikiem zwiększającym prawdopodobieństwo sukcesu projektu i łagodzącym problematyczne projekty. Zespół programistów powinien dążyć do zaangażowania użytkownika końcowego i zachęcać go do wkładu w proces tworzenia. Brak zaangażowania użytkowników może prowadzić do błędnej interpretacji wymagań, niewrażliwości na zmieniające się potrzeby klienta i nierealistycznych oczekiwań ze strony klienta. Twórcy oprogramowania, użytkownicy, kierownicy projektów, klienci i sponsorzy projektów muszą komunikować się regularnie i często. Informacje uzyskane z tych dyskusji pozwalają zespołowi projektowemu przeanalizować mocne i słabe strony, szanse i zagrożenia (SWOT) oraz działać na podstawie tych informacji, aby skorzystać z szans i zminimalizować zagrożenia. Nawet złe wiadomości mogą być dobre, jeśli zostaną przekazane stosunkowo wcześnie, ponieważ problemy można złagodzić, jeśli nie zostaną wykryte zbyt późno. Na przykład swobodne rozmowy z użytkownikami, członkami zespołu i innymi interesariuszami mogą często ujawnić potencjalne problemy wcześniej niż formalne spotkania. Wszelka komunikacja musi być intelektualnie uczciwa i autentyczna, a regularna, częsta i wysokiej jakości krytyka prac rozwojowych jest konieczna, o ile jest prowadzona w spokojny, pełen szacunku, konstruktywny , nieoskarżający i bez gniewu sposób. Częsta, swobodna komunikacja między programistami a użytkownikami końcowymi oraz między kierownikami projektów a klientami jest niezbędna, aby projekt był odpowiedni, użyteczny i skuteczny dla użytkowników końcowych oraz mieścił się w granicach tego, co można ukończyć. Skuteczna komunikacja interpersonalna oraz zarządzanie i rozwiązywanie konfliktów są kluczem do zarządzania projektami oprogramowania. Żadna metodologia ani strategia doskonalenia procesu nie jest w stanie przezwyciężyć poważnych problemów w komunikacji lub złym zarządzaniu konfliktem międzyludzkim. Co więcej, wyniki związane z takimi metodologiami i strategiami doskonalenia procesów są ulepszane dzięki lepszej komunikacji. Komunikacja musi koncentrować się na tym, czy zespół rozumie kartę projektu i czy postępuje w kierunku tego celu. Użytkownicy końcowi, programiści i kierownicy projektów muszą często zadawać podstawowe , proste pytania, które pomagają zidentyfikować problemy, zanim przerodzą się w niemal katastrofę. Chociaż udział użytkownika końcowego, skuteczna komunikacja i praca zespołowa nie wystarczą, są one niezbędne do zapewnienia dobrego wyniku, a ich brak prawie na pewno doprowadzi do złego wyniku.
  • Zarządzanie ryzykiem to proces pomiaru lub oceny ryzyka, a następnie opracowywania strategii zarządzania ryzykiem. Ogólnie stosowane strategie obejmują przeniesienie ryzyka na inną stronę, unikanie ryzyka, ograniczanie negatywnych skutków ryzyka oraz akceptację niektórych lub wszystkich konsekwencji określonego ryzyka. Zarządzanie ryzykiem w zarządzaniu projektami oprogramowania rozpoczyna się od uzasadnienia biznesowego dla rozpoczęcia projektu, który obejmuje analizę kosztów i korzyści, a także listę opcji awaryjnych na wypadek niepowodzenia projektu, zwaną planem awaryjnym .
    • Podzbiór zarządzania ryzykiem to Zarządzanie szansami , co oznacza to samo, z wyjątkiem tego, że potencjalny wynik ryzyka będzie miał pozytywny, a nie negatywny wpływ. Chociaż teoretycznie traktowane w ten sam sposób, użycie terminu „okazja” zamiast nieco negatywnego terminu „ryzyko” pomaga skupić zespół na możliwych pozytywnych wynikach dowolnego rejestru ryzyka w swoich projektach, takich jak projekty typu spin-off, nieoczekiwane i bezpłatne dodatkowe zasoby.
  • Zarządzanie wymaganiami to proces identyfikacji, pozyskiwania , dokumentowania, analizowania, śledzenia , ustalania priorytetów i uzgadniania wymagań, a następnie kontrolowania zmian i komunikowania się z odpowiednimi interesariuszami. Nowy lub zmieniony system komputerowy Zarządzanie wymaganiami, które obejmuje analizę wymagań , jest ważną częścią procesu inżynierii oprogramowania ; gdzie analitycy biznesowi lub programiści identyfikują potrzeby lub wymagania klienta; po zidentyfikowaniu tych wymagań są w stanie zaprojektować rozwiązanie.
  • Zarządzanie zmianą to proces identyfikacji, dokumentowania, analizowania, ustalania priorytetów i uzgadniania zmian w zakresie (zarządzanie projektem), a następnie kontrolowania zmian i komunikowania się z odpowiednimi interesariuszami. Analiza wpływu zmian w nowym lub zmienionym zakresie, która obejmuje analizę wymagań na poziomie zmiany, jest ważną częścią procesu inżynierii oprogramowania ; gdzie analitycy biznesowi lub programiści identyfikują zmienione potrzeby lub wymagania klienta; po zidentyfikowaniu tych wymagań są w stanie ponownie zaprojektować lub zmodyfikować rozwiązanie. Teoretycznie każda zmiana może mieć wpływ na harmonogram i budżet projektu oprogramowania, dlatego z definicji musi obejmować analizę ryzyka i korzyści przed zatwierdzeniem.
  • Zarządzanie konfiguracją oprogramowania to proces identyfikacji i dokumentowania samego zakresu, czyli produktu będącego w toku, w tym wszystkich podproduktów i zmian oraz umożliwienia komunikacji z odpowiednimi interesariuszami. Ogólnie rzecz biorąc, stosowane procesy obejmują kontrolę wersji , konwencję nazewnictwa (programowanie) i umowy dotyczące archiwizacji oprogramowania.
  • Zarządzanie wersjami to proces identyfikacji, dokumentowania, ustalania priorytetów i uzgadniania wersji oprogramowania, a następnie kontrolowania harmonogramu wydań i komunikowania się z odpowiednimi interesariuszami. Większość projektów oprogramowania ma dostęp do trzech środowisk oprogramowania, w których można udostępniać oprogramowanie; Rozwój, testy i produkcja. W bardzo dużych projektach, gdzie rozproszone zespoły muszą zintegrować swoją pracę przed wypuszczeniem do użytkowników, nie będzie często więcej środowisk dla sprawdzenia, zwany testów jednostkowych , testowanie systemu , lub testowanie integracyjne , przed dopuszczeniem do testów akceptacyjnych użytkownika (UAT).
    • Podzbiór zarządzania wydaniami, który zyskuje na uwadze, to zarządzanie danymi , ponieważ oczywiście użytkownicy mogą testować tylko na podstawie danych, które znają, a „rzeczywiste” dane znajdują się tylko w środowisku oprogramowania zwanym „produkcją”. Aby przetestować swoją pracę, programiści muszą zatem często tworzyć „fikcyjne dane” lub „fragmenty danych”. Tradycyjnie do tego celu były kiedyś używane starsze wersje systemu produkcyjnego, ale ponieważ firmy coraz bardziej polegają na zewnętrznych współpracownikach przy tworzeniu oprogramowania, dane firmowe mogą nie być udostępniane zespołom programistycznym. W złożonych środowiskach można tworzyć zestawy danych, które są następnie migrowane między środowiskami testowymi zgodnie z harmonogramem wydawania testów, podobnie jak ogólny harmonogram wydawania oprogramowania.
  • Utrzymanie i aktualizacja to proces, w którym zawsze występują wymagania i potrzeby klientów. Bez wątpienia znajdą błędy, mogą poprosić o nowe funkcje i poprosić o inną funkcjonalność i więcej aktualizacji. Tak więc wszystkie te prośby muszą sprawdzić i spełnić wymagania klienta i jego satysfakcję.

Planowanie, wykonanie, monitorowanie i kontrola projektu

Celem planowania projektu jest określenie zakresu projektu, oszacowanie wymaganej pracy i stworzenie harmonogramu projektu . Planowanie projektu rozpoczyna się od wymagań definiujących oprogramowanie, które ma zostać opracowane. Następnie opracowywany jest plan projektu w celu opisania zadań , które doprowadzą do zakończenia. Realizacja projektu to proces wypełniania zadań określonych w planie projektu.

Celem monitorowania i kontroli projektu jest bieżące informowanie zespołu i kierownictwa o postępach w realizacji projektu. Jeśli projekt odbiega od planu, kierownik projektu może podjąć działania w celu rozwiązania problemu. Monitorowanie i kontrola projektu obejmuje spotkania statusowe w celu zebrania statusu od zespołu. Gdy zachodzi potrzeba wprowadzenia zmian, kontrola zmian służy do utrzymywania aktualności produktów.

Kwestia

W informatyce termin „problem” oznacza jednostkę pracy wymaganą do udoskonalenia systemu. Problemem może być błąd , żądana funkcja , zadanie, brakująca dokumentacja i tak dalej.

Na przykład OpenOffice.org nazywał swoją zmodyfikowaną wersję Bugzilla IssueZilla. Od września 2010 roku nazywają swój system Issue Tracker.

Poziomy ważności

Problemy są często klasyfikowane pod względem poziomów istotności . Różne firmy mają różne definicje dotkliwości, ale niektóre z najczęstszych to:

Wysoki
Błąd lub problem dotyczy kluczowej części systemu i musi zostać naprawiony, aby wznowił normalne działanie.
Średni
Błąd lub problem dotyczy niewielkiej części systemu, ale ma pewien wpływ na jego działanie. Ten poziom istotności jest przypisywany, gdy ma to wpływ na niecentralne wymaganie systemu.
Niski / Stały
Błąd lub problem dotyczy niewielkiej części systemu i ma bardzo niewielki wpływ na jego działanie. Ten poziom istotności jest przypisywany, gdy dotyczy niecentralnego wymagania systemu (o mniejszym znaczeniu).
Banalne (kosmetyczne, estetyczne)
System działa poprawnie, ale wygląd nie odpowiada oczekiwanemu. Na przykład: niewłaściwe kolory, zbyt duże lub zbyt małe odstępy między treściami, nieprawidłowe rozmiary czcionek, literówki itp. Jest to problem o najmniejszej wadze.

Zarządzanie problemami

W wielu firmach zajmujących się oprogramowaniem problemy są często badane przez analityków ds. Zapewnienia jakości podczas weryfikacji systemu pod kątem poprawności, a następnie przypisywane do programistów odpowiedzialnych za ich rozwiązanie. Mogą być również przypisywane przez użytkowników systemu podczas fazy testów akceptacyjnych użytkowników (UAT) .

Informacje o problemach są przekazywane za pomocą systemów śledzenia problemów lub usterek . W innych przypadkach używane są e-maile lub komunikatory internetowe .

Filozofia

Jako subdyscyplinę zarządzania projektami niektórzy uważają, że zarządzanie rozwojem oprogramowania jest podobne do zarządzania produkcją , które może być wykonywane przez osobę posiadającą umiejętności zarządzania, ale bez umiejętności programowania. John C. Reynolds obala ten pogląd, i twierdzi, że rozwój oprogramowania jest całkowicie zaprojektować pracę i porównuje menedżera , który nie może programu do zarządzającego redaktor z gazety , który nie może pisać .

Bibliografia

Generał

Linki zewnętrzne

Niepowodzenie projektu