Inżynieria Oprogramowania O analizie, zarządzaniu projektami i projektowaniu systemów informatycznych

22lis/102

Przypadki użycia cz.1

    Jako analityk w codziennej pracy stykam się z przypadkami użycia. Pomimo, iż wiele już jest materiałów i książek na temat przypadków użycia, bardzo często spotykam się w błędnym sposobie ich stosowania. Niniejszy artykuł stanowi wstęp do cyklu artykułów mających w zwięzły i prosty sposób przedstawić tematykę podejścia opartego na przypadkach użycia.

    Pojęciami ściśle związanymi z przypadkami użycia są Aktor oraz wspomniany Przypadek użycia (UC bądź PU).

    Aktor reprezentuje osobę bądź inny system, który pozostaje w interakcji z systemem, którego funkcjonalność przedstawiona zostaje za pomocą przypadków użycia.

    Przypadki użycia są zbiorem funkcjonalności (przedstawionym na określonym poziomie szczegółowości), które mogą wchodzić w interakcję z Aktorami bądź z innymi przypadkami użycia w ramach modelowanego systemu bądź modułu.

    Przypadki użycia przede wszystkim...
    - znajdują częste zastosowanie w opisie wymagań systemowych ze względu na czytelność tak zapisanych wymagań
    - dzięki interakcji pomiędzy przypadkami użycia a aktorami, ukazują główne cele projektowanego systemu
    - dzięki zastosowania scenariuszy głównych wprowadzają definicję pomyślnej realizacji funkcjonalności przez aktora systemu
    - dzięki zastosowania alternatywnych scenariuszy wprowadzają definicje działań alternatywnych
    - prezentują wielopoziomowość - jeden przypadek użycia może używać/wywoływać bądź rozszerzać inny przypadek użycia
    - umożliwiają stosunkowo łatwe oszacowanie pracochłonności wytwarzanego systemu (metoda USE Case Points)
    - ułatwiają walidację wymagań
    - stanowią bazę do przygotowywania scenariuszy testowych i akceptacyjnych
    - stanowią podstawę do stworzenia dokumentacji użytkownika

    Przypadki użycia…
    - NIE służą do przestawienia interfejsu projektowanego systemu
    - NIE zawierają szczegółowych aspektów projektowanego systemu
    - NIE przedstawiają sekwencji wywołań/użycia

    17lis/101

    Najbardziej znaczące role w Projektach IT

      Ostatnio wpadły mi w oko wyniki raportu dotyczącego najbardziej znaczących ról w projektach IT. Raport został przeprowadzony przez Forrester Research na postawie wywiadów/ankiet na grupie 128 decydentów z różnych firm. Przypuszczam, że nie znalazła się tam ani jedna polska firma więc de facto raport prezentuje trend "zachodni".

      Według Forrester zmieniający się porządek zapotrzebowania na specjalistów IT wynika głównie z trzech rzeczy:
      1. Coraz większa popularność różnych technologii i rozwiązań jak np. SaaS (Software -as-a-service) bądź Business Intelligence, które wpływają na zapotrzebowanie na konkretne umiejętności;
      2. Coraz bardziej rosnące znaczenie outsourcingu ze względu na łatwą dostępność czasową specjalistów o bardzo wysokich kwalifikacjach jak również opłacalność takiego modelu dla obu stron;
      3. Chęć redukcji kosztów wpływa coraz bardziej na decyzje podejmowane przez decydentów.

      Podczas badań jako skalę przyjęto skalę procentową odzwierciedlającą opinię decydentów w przebadanych firmach na temat znaczenia (ważności) ról w projektach IT.

      Lista wygląda następująco:
      1. Business Analysis - 70%
      2./3. Architecture and IT strategy/planning - 66%
      4. Project management - 65%
      5. Security - 62%
      6. Service management - 60%
      7. Client relationship management - 56%
      8. Business continuity nad IT financial management - 55%
      9./10. Portfolio management- 50%
      11. Asset management - 34%
      12. IT Research - 30%
      13. Human Resources - 20%

      Czy wyniki tego raportu zaskoczyły mnie?
      W pewnym sensie tak - przede wszystkim nie spodziewałem się tak wysokiej roli Analityka Biznesowego - z zaznaczeniem na "Biznesowy", czyli taki który również świetnie zna branżę/branże w obrębie której/których się porusza. Zresztą nie od dziś wiadomo, iż poziom kultury organizacyjnej a co za tym idzie ról poszczególnych osób w projektach IT w krajach wysoko rozwiniętych jest różny niż w Polsce (niestety nie na korzyść Polski).

      Drugim spostrzeżeniem jest to, iż tak naprawdę kompetencje Analityka nie występują tylko w punkcie nr 1 ale również po części w punktach 3.(IT Strategy/planning), 4.(Project Management - Risk/Scope Management) oraz 10.(Portfolio Management) co świadczy o jeszcze większym znaczeniu tej roli w organizacjach również jako rola doradcza.

      Jak to się ma do sytuacji w Polsce? - od jakiegoś czasu obserwuję polski rynek IT pod kątem zapotrzebowania na analityków. Sytuacja wydaje się cały czas zmieniać. Organizacje zaczynają zdawać sobie powoli sprawę z korzyści jakie niesie ze sobą rola Analityka Biznesowego (o korzyściach w innym artykule). Tempo jednakże zmian jest powolny. Bardzo przypomina to sytuację jeszcze z przed kilku-kilkunastu lat dotyczącą "Project Managerów" - w końcu każdy mógł nim być - nie potrzebna była znajomość żadnych metodyk i standardów zarządzania projektami. Do czego to prowadziło? - ano do tego, iż odsetek projektów które generalnie okazały się nie wypałem był od wiele większy niż w krajach w których powszechnie prowadzono projekty z rozsądnym wykorzystaniem metodyk/standardów zarządzania projektami. Wszystko tkwi w świadomości decydentów a to się w końcu zaczyna zmieniać - nie każdy może być Analitykiem a tworzenie "analityków" poprzez mianowanie przypadkowych osób w organizacji wydaje mi się nieporozumieniem, które prowadzi do katastrofy. Analiza to przede wszystkim świetna znajomość technik i metod analitycznych oraz rozumienie określonej branży w której się działa (ale o tym w innym czasie).

      11lis/100

      Po egzaminie Prince2 Foundation (v.2009)

        Dwa tygodnie temu zdałem egzamin Prince2 Foundation. W tym poście chcę odpowiedzieć na pytanie czy warto iść na szkolenie akredytowane czy może lepiej zdawać egzamin W British Council bez akredytowanego szkolenia (bo też jest taka możliwość).
        Przed pójściem na akredytowane szkolenie Prince2 Foundation wahałem się czy iść na nie czy lepiej odrazu podejść do egzaminu (wcześniej sam przygotowywałem się na podst. książki Skuteczne Zarządzanie Projektami Prince2). Według mnie, jeśli ma się możliwość pójść na takie szkolenie to naprawdę warto, a to przede wszystkim z dwóch powodów.

        Pierwszym powodem jest to, iż samo tłumaczenie podręcznika Skuteczne Zarządzanie Projektami Prince2 nie jest idealne (szczególnie jak na podręcznik za 300 zł). Oprócz kilku literówek i błędów stylistycznych pojawiają się nieścisłości merytoryczne, które akredytowany trener jest w stanie uwypuklić na szkoleniu. Jedną z takich nieścisłości było słowo "szacować" (w kontekście Planowania). Podręcznik sugeruje czytelnikowi iż, szacować znaczy "określać w przybliżeniu" (bez przejmowania się za bardzo superdokładnością). Sam tak też tak rozumiałem. Z kolei wersja anglojęzyczna mówi o tym, iż przedmiot owego "szacowania" należy określić jak najbardziej dokładnie. Słowo szacować można zastąpić tu słowem wyznaczyć, obliczyć, określić. Doświadczony trener z pewnością zwróci uwagę na takie detale.

        Drugim powodem dla, którego warto pójść na szkolenie akredytowane (niestety na rynku pojawiają się szkolenia krzaki bez akredytacji OMG), jest to, iż doświadczony trener wnosi szerszy kontekst nauki tej metodyki zarządzania projektami. Szkolenie poparte licznymi przykładami jest naprawdę o wiele bardziej skuteczne niż suche przeczytanie książki (do egzaminu Prince2 Practicioner wymagane wręcz kilkukrotne) - no chyba, iż osoba chcąca zdać egzamin jest wieloletnim praktykiem a certyfikat potrzebny jest tylko jako wymaganie w przetargu :)

        Jeszcze słowo o samym przygotowaniu się do egzaminu - egzamin sam nie jest wcale banalny (OMG podniosło ostatnio poziom trudności egzaminu). Mocno zachęcam do rzetelnego przestudiowania podręcznika i częstych powtórek rozdziałów. Ponadto warto przestudiować również dodatki na końcu podręcznika.

        Za jakiś czas relacja "po egzaminie z Prince2 Practicioner" :)

        10lis/100

        PMblogs.pl – agregator blogów o tematyce zarządzania projektami

          Jakiś czas temu popełniłem serwis PMblogs.pl - agregator polskich blogów o tematyce zarządzania projektami. Agregator prezentuje tytuł i pięć najnowszych wpisów na blogu. Blogi sortują się od ostatnio zaktualizowanego do najstarszego. Liczba blogów ciągle się zwiększa.

          Jeśli znasz ciekawy serwis bądź blog związany w jakikolwiek sposób z zarządzaniem projektami - napisz...z pewnością umieszczę go na PMblogs.pl :) Możesz również skorzystać z formularza. Wpis na stronie pojawi się dopiero po zatwierdzeniu przeze mnie.

             
          Premium Wordpress Plugin