ITIL (ang. Information Technology Infrastructure Library)

Kodeks postępowania dla działów informatyki. Zbiór zaleceń, jak efektywnie i skutecznie oferować usługi informatyczne. Prace nad pierwszą wersją rozpoczęto w połowie lat 80 XX wieku w Wielkiej Brytanii na zlecenie administracji rządowej.Pierwsza książka “HelpDesk” ukazała się w 1989 roku. W roku 2001 opublikowano drugą wersję biblioteki, opisaną w dwóch głównych publikacjach, a w roku 2007 opublikowano wersję trzecią.

Podstawowe informacje

Podstawą koncepcji ITIL jest zdefiniowanie procesów, które powinny funkcjonować w ramach organizacji świadczącej usługi IT. ITIL pozwala na modelowanie procesów zarówno w organizacjach komercyjnych (np. firmy komputerowe, programistyczne), jak i niekomercyjnych (agencje rządowe itp.), niezależnie od wielkości firmy, typu organizacji czy też posiadanych narzędzi. Każdy proces powinien posiadać zdefiniowane role i odpowiedzialności.

W grudniu 2005 oficjalnie została zatwierdzona norma ISO/IEC 20000, która formalizuje wymagania dotyczące zarządzania usługami informatycznymi (powstała na bazie brytyjskiej normy BS 15000). ITIL jest zarejestrowanym znakiem towarowym OGC (Office of Government Commerce). ITIL stał się podstawą opracowania zaleceń MOF (Microsoft Operations Framework) ukierunkowanych na systemy Microsoft. Osoby zainteresowane tematyką zarządzania usługami informatycznymi (Service management) zrzeszone są w organizacji itSMF (The IT Service Management Forum). Istnieje również polski oddział (na stronach polskiego oddziału dostępny jest m.in. polski słownik terminów ITIL).

Usługi i produkty dotyczące ITIL

Usługi i produkty związane z ITIL są coraz bardziej popularne i stanowią pokaźne źródło dochodów dla wielu firm. Oferta obejmuje przede wszystkim:

• podręczniki – książki dostępne są zarówno w formie drukowanej, jak i elektronicznej (na CD-ROM w postaci HTML). Książki można zamówić m.in. na stronach TSO (The Stationary Office);

• edukację – oferta edukacyjna na świecie jest bardzo szeroka, w Polsce szkolenia oferują m.in. OMEC, HP, IBM, 500Solutions, Altkom Akademia. Szkolenia (przeważnie) z zakresu Service Support oraz Service Delivery obejmują 3 poziomy odpowiadające późniejszej certyfikacji: Foundation (podstawy, 3-4 dni), Practitioner (jeden lub kilka procesów dla praktyków w danej dziedzinie, 3-5 dni), Service Manager (dla administratorów procesów lub kierownictwa IT, 13 dni);

• certyfikację – wiedza na temat ITIL jest poparta oficjalnym certyfikatem wystawianym jedynie przez kilka organizacji, m.in. EXIN. Dostępne są trzy poziomy wtajemniczenia: Foundation, Practitioner, Service Manager. Egzaminy certyfikujące oferowane są zwykle przez dostawcę szkoleń, ale autoryzowane przez organizację certyfikującą;

• konsulting – pomoc we wprowadzaniu procesów ITIL w organizacji;

• produkty wspomagające wprowadzanie procesów ITIL – czołowi dostawcy tych produktów to: BMC, CA, HP, IBM.

Biblioteka ITIL w wersji 3 opublikowanej w 2007 składa się obecnie z 5 opracowań:

• Service Strategy (SS) Strategia usług: Strategy Generation, Financial Management, Service Portfolio Management, Demand Management

• Service Design (SD) Projektowanie usług: Service Catalogue Management, Service Level Management, Capacity Management, Availability Management, IT Service Continuity Management, Information Security Management, Supplier Management

• Service Transition (ST) Przekazanie usług: Transition Planning and Support, Change Management, Service Asset & Configuration Mgmt, Release and Deployment Mgmt, Service Validation and Testing, Evaluation, Knowledge Management

• Service Operation (SO) Eksploatacja usług: Event Management, Incident Management, Request Fulfilment, Problem Management, Access Management

• Continual Service Improvement (CSI) Ciągła poprawa usług: 7-Step Improvement Process, Service Measurement, Service Reporting

TOGAF (ang. The Open Group Architecture Framework)

Szkielet dla architektury korporacyjnej, który zapewnia kompleksowe podejście do projektowania, planowania, implementacji oraz zarządzania informacyjną architekturą organizacji. Dokumentacja TOGAF składa się z siedmiu części, zawierających:

1. Opis idei i definicję pojęć,

2. Metodykę zawierającą opis procesu wytwarzania architektury korporacyjnej,

3. Techniki i wskazówki uzupełniające opis metodyki,

4. Klasyfikację typów produktów architektonicznych,

5. Opis budowy repozytorium architektonicznego,

6. Modele referencyjne,

7. Ramy określające zdolności architektoniczne organizacji.

Architektura jest modelowana typowo na czterech poziomach (domenach):

• biznes,

• aplikacje,

• dane,

• technologia.

The Open Group podkreśla znaczenie metodyki wytwarzania architektury korporacyjnej, jako podstawowej zalety ram architektonicznych TOGAF. Grupa The Open Group udostępnia specyfikację TOGAF bezpłatnie dla organizacji do ich własnego, niekomercyjnego wykorzystania. Aktualnie obowiązującą wersją jest wersja 9.1. W ramach The Open Group dostępny jest program certyfikacyjny, składający się z dwóch poziomów:

1. TOGAF 9 Foundation – dla uczestników procesu wytwarzania architektury,

2. TOGAF 9 Certified – dla architektów korporacyjnych.

Potencjalne korzyści płynące ze stosowania TOGAF 9

Bardziej efektywne działanie biznesu:

• niższe koszty operacyjne,

• bardziej responsywna organizacja (szybsza reakcja na zmianę biznesową),

• wspólne wykorzystanie zdolności biznesowych w przekroju całej organizacji,

• niższe koszty zarządzania zmianą,

• bardziej elastyczne zasoby ludzkie,

• poprawa produktywności działów biznesowych.

Bardziej wydajne działanie IT:

• niższe koszty wytwarzania, wsparcia oraz utrzymania oprogramowania,

• zwiększona przenaszalność aplikacji,

• zwiększenie interoperacyjności oraz łatwości zarządzania systemami i infrastrukturą,

• zwiększenie zdolności do adresowania kluczowych pojęć dla całości organizacji, np. bezpieczeństwa,

• łatwiejsza aktualizacja i wymiana komponentów infrastruktury aplikacyjnej, programowej i sprzętowej.

Zwiększenie ROI dla obecnych systemów, zmniejszenie ryzyka dla przyszłych inwestycji:

• zmniejszenie złożoności biznesu i IT,

• maksymalizacja ROI (ang. return on investment – zwrot z inwestycji) dla inwestycji w bieżącą infrastrukturę,

• elastyczność dla wytwarzania, kupowania lub outsourcingu rozwiązań,

• redukcja ryzyka nowych inwestycji i kosztów ich posiadania.

Szybsze, prostsze i tańsze zarządzanie łańcuchem dostaw:

• decyzje o kupnie są prostsze ze względu na dostępność kluczowej informacji,

• proces zarządzania łańcuchem dostaw jest szybszy ze względu na zasady podtrzymywania zgodności

• architektonicznej, zdolność do dostarczania zróżnicowanych technologicznie systemów pochodzących od różnych dostawców.

PMBOK Guide (ang. A Guide to the Project Management Body of Knowledge)

Zbiór standardów i rozwiązań w dziedzinie zarządzania projektami zebranych i opublikowanych przez członków Project Management Institute. Standard PMBOK Guide jest to zbiór powszechnie uznanych praktyk znajdujących zastosowanie w zarządzaniu projektami. W USA PMBOK Guide jest zatwierdzony przez American National Standards Institute jako narodowy standard zarządzania projektami. Zasadniczą częścią PMBOK Guide są procesy pogrupowane w 5 grup i 10 obszarów wiedzy. Pięć podstawowych grup procesów w PMBoK wg edycji trzeciej to:

1. Procesy rozpoczęcia – procesy, które służą zdefiniowaniu i zatwierdzeniu projektu w organizacji:

1. Opracowanie dokumentu otwarcia

2. Opracowanie wstępnego zakresu projektu

2. Procesy planowania – procesy mają na celu odpowiedzenie na pytanie: jak, w jaki sposób zrealizować zamierzone cele, jakimi środkami, kiedy, w jakiej kolejności itp.,

1. Opracowanie planu zarządzania projektem

2. Planowanie zarządzania zakresem projektu

3. Definiowanie zakresu projektu

4. Opracowanie struktury podziału prac (SPP, ang. WBS – Work Breakdown Structure)

5. Zdefiniowanie czynności

6. Porządkowanie czynności

7. Szacowanie zasobów czynności

8. Szacowanie czasu trwania czynności

9. Opracowanie harmonogramu

10. Szacowanie kosztów

11. Budżetowanie kosztów

12. Planowanie jakości

13. Planowanie zasobów ludzkich

14. Planowanie komunikacji

15. Planowanie zarządzania ryzykiem

16. Identyfikacja ryzyka

17. Jakościowa analiza ryzyka

18. Ilościowa analiza ryzyka

19. Planowanie reakcji na ryzyko

20. Planowanie zaopatrzenia

21. Planowanie kontraktów

3. Procesy realizacji – grupują i koordynują wykorzystanie zasobów i ludzi w projekcie w celu wykonania założonego planu,

1. Kierowanie i zarządzanie realizacją projektu

2. Zapewnienie jakości

3. Przyjmowanie członków zespołu

4. Rozwój zespołu

5. Dystrybucja informacji

6. Gromadzenie ofert od sprzedawców

7. Wybór sprzedawców

4. Procesy kontroli – monitorują postępy prac w projekcie, badają ewentualne odchylenia, aby w razie konieczności uruchomić odpowiednie działania zapobiegawcze lub korygujące,

Monitorowanie i nadzór nad pracami projektu

1. Zintegrowane zarządzanie zmianami

2. Weryfikacja zakresu

3. Sterowanie zakresem

4. Nadzór nad harmonogramem

5. Nadzór nad kosztami

6. Kontrola jakości

7. Zarządzanie zespołem

8. Raportowanie postępu prac

9. Zarządzanie udziałowcami (interesariuszami)

10. Monitorowanie i nadzór nad ryzykiem

11. Administrowanie kontraktem

5. Procesy zakończenia– przygotowanie formalnej akceptacji produktu finalnego projektu lub jego fazy.

1. Zamknięcie projektu

2. Zamknięcie kontraktu

Procesy mogą zachodzić na siebie w czasie realizacji projektu lub jego fazy. Obowiązkiem kierownika ewentualnie zespołu kierowniczego projektu jest wybranie tych procesów, które mają zastosowanie dla konkretnego projektu.

Obszary wiedzy

Właściwą część PMBoK stanowi 10 obszarów wiedzy, są to:

• Zarządzanie integralnością projektu

• Zarządzanie zakresem

• Zarządzanie czasem

• Zarządzanie kosztami

• Zarządzanie jakością

• Zarządzanie zasobami ludzkimi

• Zarządzanie komunikacją

• Zarządzanie ryzykiem

• Zarządzanie zaopatrzeniem

• Zarządzanie interesariuszami

ISO/IEC 20000

– pierwszy międzynarodowy standard dla zarządzania usługami IT, opracowany przez Międzynarodową Organizację Normalizacyjną. Norma bazuje na normie BS 15000 opracowanej w 2005 przez BSI Group. Standard jest przeznaczony dla każdej organizacji, w której funkcjonują usługi IT.

Na standard składają się dwie normy:

• ISO/IEC 20000-1:2011 – International Standard – Information Technology – Service Management – Part 1: Service management system requirements

• ISO/IEC 20000-2:2005 – International Standard – Information Technology – Service Management – Part 2: Code of practice. Ich polska, zharmonizowana wersja opublikowana została w 2007 roku. Polskie wydanie niczym nie różni się od oryginału, a jego nazwa brzmi:P

  • PN-ISO/IEC 20000-1: 2007 – Technika informatyczna – Zarządzanie usługami – Część 1: Specyfikacja

  • PN-ISO/IEC 20000-2: 2007 – Technika informatyczna – Zarządzanie usługami – Część 2: Reguły postępowania.

Część pierwsza zawiera wymagania, na podstawie których firmy mogą się certyfikować i uzyskać potwierdzenie zgodności z normą. Niespełnienie któregokolwiek z wymagań może oznaczać, że firma nie uzyska certyfikatu. Część 2 stanowi rozszerzenie wymagań z części pierwszej o pewne rekomendacje, bazujące na modelu Information Technology Infrastructure Library, elementach Microsoft Operations Framework i COBIT.

AGILE Programowanie zwinne (Agile software development)

– grupa metodyk wytwarzania oprogramowania opartego na programowaniu iteracyjno-przyrostowym. Wymagania oraz rozwiązania ewoluują przy współpracy samozarządzalnych zespołów, których celem jest przeprowadzanie procesów wytwarzania oprogramowania. Pojęcie zwinnego programowania zostało zaproponowane w 2001 w Agile Manifesto. Generalnie metodyka oparta jest na zdyscyplinowanym zarządzaniu projektem, które zakłada częste inspekcje wymagań i rozwiązań wraz z procesami adaptacji (zarówno specyfikacji jak i oprogramowania). Metodyka ta najczęściej znajduje zastosowanie w małych zespołach programistycznych, w których nie występuje problem komunikacji, przez co nie trzeba tworzyć rozbudowanej dokumentacji kodu. Kolejne etapy wytwarzania oprogramowania zamknięte są w iteracjach, w których za każdym razem przeprowadza się testowanie wytworzonego kodu, zebranie wymagań, planowanie rozwiązań itd. Metoda nastawiona jest na szybkie wytwarzanie oprogramowania wysokiej jakości.

Skład zespołów jest zazwyczaj wielofunkcyjny oraz samozarządzalny, bez zastosowania jakiejkolwiek hierarchii korporacyjnej. Członkowie zespołu biorą odpowiedzialność za zadania postawione w każdej iteracji. Sami decydują jak osiągnąć postawione cele.

Metoda nastawiona jest na bezpośrednią komunikację pomiędzy członkami zespołu, minimalizując potrzebę tworzenia dokumentacji. Jeśli członkowie zespołu są w różnych lokalizacjach, to planuje się codzienne kontakty za pośrednictwem dostępnych kanałów komunikacji (wideokonferencja, e-mail itp.).

Podstawowe zasady

Manifest Agile ((ang.) Agile Manifesto) – założenia:

• osiągnięcie satysfakcji klienta poprzez szybkość wytwarzania oprogramowania,

• działające oprogramowanie jest dostarczane okresowo (raczej tygodniowo niż miesięcznie),

• podstawową miarą postępu jest działające oprogramowanie,

• późne zmiany w specyfikacji nie mają destrukcyjnego wpływu na proces wytwarzania oprogramowania,

• bliska, dzienna współpraca pomiędzy biznesem a deweloperem,

• bezpośredni kontakt, jako najlepsza forma komunikacji w zespole i poza nim,

• ciągła uwaga nastawiona na aspekty techniczne oraz dobry projekt (design),

• prostota,

• samozarządzalność zespołów,

• regularna adaptacja do zmieniających się wymagań.

Lean management

– jedna z koncepcji zarządzania przedsiębiorstwem, której wdrożenie umożliwia dostarczanie klientowi wymaganej przez niego wartości po jak najniższym koszcie i przy wykorzystaniu jak najmniejszej ilości zasobów. Inne stosowane nazwy tej koncepcji to lean manufacturing, lean production, lean six sigma oraz lean sigma. W polskiej literaturze zarządzania najczęściej używa się bezpośredniego tłumaczenia “szczupłe zarządzanie”. Geneza lean management jest związana z systemem produkcji zastosowanym w japońskiej firmie Toyota (Toyota Production System, TPS). Za twórców lean management uważa się: Sakichi Toyoda, Ki’ichiro Toyoda i Taiichi Ohno. Koncepcja lean (ang. szczupły, chudy) w skrócie definiowana jest jako eliminacja czynności, które wykonywane są przy tworzeniu produktu lub usługi, a które nie dodają wartości temu produktowi lub usłudze. Chcąc osiągnąć odchudzoną z niepotrzebnych czynności produkcję należy wykorzystać narzędzia, którymi lean dysponuje. Zapotrzebowanie biznesu na usługi IT stale rośnie, jednocześnie procesy stają się coraz bardziej złożone. Dzisiejsze realia wymagają niemalże natychmiastowego reagowania na sytuację rynkową, kryzys wymusił na organizacjach ciecie kosztów, biznes zaś naciska na optymalizację wszystkich procesów. Te zmiany zmusiły całe organizacje do szukania

nowych rozwiązań. W biznesie odpowiedzią na te problemy stał się Lean – Lean Manufacturing w produkcji oraz Lean Services w usługach. IT chcąc dotrzymać kroku biznesowi również musi się zmienić. Metodą na tę zmianę jest Lean IT (“Szczupła” Informatyka). Ma ona na celu identyfikowanie i eliminowanie działań nieproduktywnych. Metodyka Lean IT koncentruje się głównie na rozpoznawaniu i eliminowaniu marnotrawstwa, rozumianego jako działania, które nie dodają wartości wytwarzanym produktom lub usługom, a w efekcie nie przekładają się na wartość dla biznesu. Metoda bazuje na postrzeganiu wszystkich procesów w organizacji IT przez pryzmat wartości dla Klienta. Proces traktuje jako całość, szukając w nim możliwości udoskonalenia i eliminacji strat (MURA – nieregularność, MURI – przeciążenia, MUDA – marnotrawstwo). Toyota Production System oparty został przede wszystkim na eliminacji wszelkiego marnotrawstwa.

Typy marnotrawstwa

Najważniejszym celem Toyota Production System i odchudzonej produkcji jest eliminowanie marnotrawstwa (muda), czyli wszystko to co podnosi koszty produkcji bez wnoszenia do niej użytecznego wkładu. TPS wyznacza 7 strat:

• nadprodukcja – produkowanie więcej niż trzeba lub zbyt wcześnie,

• zbędny ruch – nadmierny ruch związany ze złą organizacją stanowisk pracy,

• oczekiwanie – długie okresy bezczynności ludzi, maszyn, części, materiałów,

• zbędny transport – przemieszczanie elementów, części, półwyrobów, wyrobów częściej niż to jest koniecznie,

• zapasy – zbyt wiele materiałów w procesie produkcji, zbyt wiele wyrobów gotowych,

• wady – dotyczą wyrobów, jak i dokumentacji, dostaw, informacji,

• nadmierna obróbka – wykonywanie zbędnych kroków w procesie obróbki.

Narzędzia lean management

Do najważniejszych narzędzi lean należą:

• VSM – Value Stream Mapping – Mapowanie Strumienia Wartości; celem jest zgromadzenie danych na temat rzeczywistego przepływu elementów fizycznych i informacji.

• 5S – metoda systematycznego uczenia się, dyscypliny, standaryzacji i dążenia do doskonałości. Polega nawykonaniu 5 kroków: Selekcji, Systematyki, Sprzątania, Standaryzacji i Samodyscypliny.

• TPM – Total Productive Maintenance – Optymalne Utrzymanie Ruchu; celem jest zapewnienie maksymalnej dostępności krytycznych urządzeń. Jest to system który umożliwia minimalizację awarii oraz poprawę jakości dzięki zaangażowaniu wszystkich pracowników. metodyka opracowana przez JIPM i w najnowszej 3 generacji rozszerzona na funkcjonowanie pozostałych aspektów przedsiębiorstw produkcyjnych. W tej wersji jest tłumaczona jako Total Productive Manufacturing i jest metodyką konkurencyjną do lean.

• SMED – Single Minutes Exchange of Die – redukcja czasu przezbrojenia maszyny; celem jest wykonywanie podczas przezbrojeń tylko bezwzględnie koniecznych prac. Wszystkie inne kroki wykonywane są albo przedprzezbrojeniem albo po nim. Metodyka opracowana przez Shigeo Shingo. Wszystkie te narzędzia powinny być wdrażane jako kompleksowy system współzależnych i wzajemnie się wspierających praktyk. Można się jednak spotkać z niezależnymi wdrożeniami narzędzi wspierających lub pozbawionymi elementów lean w przypadku tych rodzajów produkcji, gdzie typowe rozwiązania ‘lean’ nie mają zastosowania.

SCRUM

Iteracyjna i inkrementalna metodyka prowadzenia projektów, zaliczana do metodyk zwinnych, zgodnych z manifestem Agile. W metodyce tej rozwój produktu podzielony jest na mniejsze, trwające od tygodnia do miesiąca, iteracje zwane sprintami następującymi bezpośrednio po sobie. Po każdym sprincie zespół pracujący nad rozwojem produktu jest w stanie dostarczyć działającą wersję produktu. Scrum jest często stosowany podczas tworzenia i rozwijania oprogramowania, nie jest jednak ograniczony tylko do tej dziedziny. Ogólne założenia metodyki zostały zaprezentowane przez Hirotaka Takeuchi i Ikujiro Nonaka w artykule The New Product Development Game, opublikowanym w Harvard Business Review w styczniu 1986 roku. Pełna metodyka oraz definicja została sformalizowana przez Kena Schwabera w 1986.

Opis ogólny

Zespół pracuje w określonym przedziale czasowym zwanym przebiegiem (ang. sprint). Efektem przebiegu za każdym razem powinno być dostarczenie użytkownikom kolejnej działającej wersji produktu. Zasadą jest to, że zmiany wprowadzane w jednym przebiegu muszą być namacalne dla użytkowników. Muszą wnosić wartość funkcjonalną. Przebieg może trwać od 1 do 4 tygodni. Zaleca się stosowanie przebiegów o stałych długościach.

Na początku pracy nad produktem zbierana jest lista wymagań użytkownika, są one przeważnie gromadzone w postaci “historyjek” (ang. User Stories). Każda historyjka opisuje jedną cechę systemu. Właściciel produktu (ang. Product Owner) jest też zobowiązany do przedstawienia priorytetu wymagań oraz głównego celu pierwszego przebiegu. Po tym formułowany jest rejestr wymagań (ang. Product Backlog). Cel przebiegu jest zapisywany w widocznym miejscu w pokoju członków zespołu.

Następnie podczas planowania przebiegu (ang. Sprint Planning) wybierane są zadania o najwyższym priorytecie, a jednocześnie przyczyniające się do realizacji celu przebiegu. Szacuje się czas realizacji, pracochłonność, złożoność i ryzyko każdego zadania. Lista zadań wraz z oszacowaną czasochłonnością nosi nazwę rejestru zadań przebiegu (ang. Sprint Backlog). Po planowaniu zespół przechodzi do realizacji przebiegu. W jego trakcie Właściciel Produktu powinien cały czas pracować z zespołem nad jak najlepszym zrozumieniem wymagań nie ingerując jednocześnie w sposób ich implementacji. Nie powinno się także zmieniać zakresu Sprintu.

Jako że zespół z założenia jest samoorganizującym się ciałem, nie ma mowy o odgórnym przypisywaniu zadań do poszczególnych członków zespołu, lecz samodzielnie dokonują oni wyboru realizowanych zadań, według wspólnych ustaleń, umiejętności czy innych preferencji.

Naczelną zasadą metody jest przeprowadzanie codziennych (maksymalnie 15-minutowych) spotkań (ang. Daily Scrum), na których omawiane są zadania zrealizowane poprzedniego dnia, problemy występujące przy ich realizacji oraz zadania do wykonania w dniu spotkania.

Sprint kończy się spotkaniem będącym przeglądem przebiegu (ang. Sprint Review), na którym prezentowany jest wynik pracy zespołu, poprzez prezentowanie produktu wykonanego podczas przebiegu. Powinni w nim uczestniczyć wszyscy zainteresowani projektem. Na spotkaniu każdy członek zespołu może zabrać głos i wyrazić opinię o produkcie. Po omówieniu produktu ustalany jest termin spotkania planistycznego do następnego przebiegu.

Metodyka skupia się na:

• dostarczaniu kolejnych, coraz bardziej dopracowanych wyników projektu,

• włączaniu się przyszłych użytkowników w proces wytwórczy,

• samoorganizacji zespołu projektowego.

Zespół i role

Zazwyczaj Zespół Scrum składa się z od 3 do 9 osób. Dobrze, gdy ma charakter interdyscyplinarny i składa się z osób reprezentujących różne umiejętności. Osoby uczestniczące w zespole nie mogą uczestniczyć w innych zespołach.

Główne role w projekcie grają: “Mistrz Młyna” (ang. Scrum Master), Właściciel Produktu (ang. Product Owner) i Członkowie Zespołu (ang. Development Team).

Role główne

• Zespół – grupa osób, składająca się od trzech do dziewięciu osób, odpowiedzialna za dostarczenie produktu

• Właściciel produktu – osoba reprezentująca klienta. Właściciel produktu może być członkiem zespołu, jednak nie jest zalecane, aby jednocześnie był Scrum Masterem

• Scrum Master – osoba odpowiedzialna za usuwanie wszelkich przeszkód uniemożliwiających zespołowi wykonanie zadania, oraz za poprawną implementację procesu i metod.

COBIT

(Control Objectives for Information and related Technology) – standard opracowany przez ISACA oraz IT Governance Institute, zbiór dobrych praktyk z zakresu IT Governance, które mogą być wykorzystywane w szczególności przez audytorów systemów informatycznych.

COBIT 4.1 opisuje 34 wysokopoziomowe procesy, które obejmują 210 celów kontrolnych pogrupowanych w czterech domenach: planowanie i organizacja (Planning and Organization), nabywanie i wdrażanie (Acquisition and Implementation), dostarczanie i wsparcie (Delivery and Support), monitorowanie i ocena (Monitoring and Evaluation).

OBASHI

OBASHI stanowi przełom w myśleniu informatycznym, który pozwala wyraźnie dostrzec, w jaki sposób przedsiębiorstwo faktycznie działa, a tym samym umożliwia podejmowanie lepszych decyzji.

OBASHI pozwala na stworzenie mapy poglądowej przedstawiającej:

• sposób działania przedsiębiorstwa

• przyczyniające się do tego zasoby

• wewnętrzne zależności pomiędzy zasobami

• wyraźną drogę doskonalenia procesów i procedur przedsiębiorstwa.

OBASHI daje możliwość lepszego zaprojektowania, monitorowania i optymalizacji przedsiębiorstwa w sposób łatwy do zrozumienia, a co jeszcze ważniejsze, łatwy do zakomunikowania w całym przedsiębiorstwie.

Niezależnie od tego, czy wyzwaniem jest ograniczenie kosztów, uzyskanie przewagi konkurencyjnej lub obie te kwestie, należy myśleć zgodnie z filozofią OBASHI.

Metodologia OBASHI ma charakter sekwencyjny i składa się z sześciu warstw:

• Ownership (własność)

• Business Process (proces biznesowy)

• Application (zastosowanie)

• System (system)

• Hardware (urządzenia)

• Infrastructure (infrastruktura)

Warstwy te nakreślono na schemacie Business and IT (B&IT), stanowiącym model gromadzenia takich informacji w sposób przydatny.

Schemat OBASHI B&IT jest narzędziem uniwersalnym, ponieważ pomaga w uproszczeniu złożonej działalności w sposób zrozumiały dla każdego. Po raz pierwszy faktycznie dostrzec można, w jaki sposób działania, procesy i wspierająca je infrastruktura techniczna są ze sobą powiązane w procesie realizacji wymaganych wyników działalności.

Możliwość dostrzeżenia i zrozumienia wyzwań stojących przed przedsiębiorstwem ułatwia podejmowanie właściwych decyzji i udoskonalenie przedsiębiorstwa.

BISL

Skuteczne zarządzanie informacjami biznesowymi ma kluczowe znaczenie. Z perspektywy biznesu potrzeba bardziej efektywnego i skutecznego wykorzystywania informacji oraz większego wsparcia dla użytkownika końcowego nabrała istotnego znaczenia w wyniku profesjonalizacji usług informatycznych w ostatnich latach.Model Business information Services Library (BiSL), opracowany przez ASL BiSL Foundation, pokazuje, jak przyjąć profesjonalne i systematyczne podejście do zarządzania informacjami biznesowymi.Podczas gdy infrastruktura informatyczna zapewnia zapamiętanie, przetworzenie i udostępnienie informacji, to skuteczne zarządzanie informacjami biznesowymi gwarantuje, że organizacja jest w stanie zareagować na określone potrzeby biznesowe.

HDI (organizacja: HELP DESK INSTITUTE)

Idea organizacji Help Desk Institute narodziła się w Stanach Zjednoczonych, w 1988 roku. Pod jej wpływem Amerykanie zorganizowali szereg spotkań pod wspólną nazwą “Help Desk – Problem Management. A Round Table Symposium for Experienced Personel Only”, na których omawiano zagadnienia poświęcone centrom wsparcia dla systemów informatycznych. Efektem tych spotkań było powołanie w 1989 roku pierwszej na Świecie organizacji Help Desk Institute. Idea ta dosyć szybko rozprzestrzeniła się także w Europie – pierwsze “oddziały” Help Desk Institute powstały w Skandynawi, Wielkiej Brytanii oraz w Niemczech. W Polsce Help Desk Institute rozpoczął działalność w 1999 roku pod nazwą Instytut Help Desk Polska (IHD Polska). W styczniu 1999 roku odbyła się pierwsza, zorganizowana we współpracy z HDI Germany konferencja Instytutu Help Desk Polska. Niestety, zbyt mała dojrzałość polskich organizacji wsparcia informatycznego spowodowała, że działalność ta nie rozwinęła się. Odnowienie działalności nastąpiło 23 czerwca 2003r. podczas spotkania, w którym uczestniczył m.in. dr Joachim E. Wolbersen, prezydent i współzałożyciel Help Desk Institute Germany, współtwórca i master audytor programu certyfikacji centrum wsparcia. Efektem spotkania było zainicjowanie działalności klubu Instytut Help Desk w Polsce. Klub działał do 1 kwietnia 2004r., kiedy to spółka CTPartners uzyskała tytuł International Partner Help Desk Institute i jako HDI Central Europe Poland zaczęła oficjalnie reprezentować HDI na terenie Polski. W lutym 2007 roku CTPartners podpisała umowę z Help Desk Institute w Wielkiej Brytanii na mocy której nastąpiła zmiana nazwy organizacji w Polsce na HDI-Poland. W październiku tego samego roku firma CTPartners SA oraz Think Service Inc. podpisały umowę, dzięki której organizacja HDI-Poland stała się partnerem organizacji HDI w Stanach Zjednoczonych (HDI Gold Partner). Współpraca z najstarszą organizacją HDI pozwoliła na dostęp do jej zasobów wiedzy, a także możliwość korzystania z bogatych doświadczeń innych organizacji HDI na całym świecie.

DevOps

DevOps ((ang.) Development and Operations) – Metodyka DevOps jest zespoleniem rozwoju ((ang.) development) i eksploatacji ((ang.) operations) oraz zapewnienia jakości ((ang.) quality assurance), która została zaprezentowana na pierwszej z serii konferencji DevOps Days w 2009 roku w Belgii. Metodyka ta kładzie nacisk na wąską współpracę i komunikację profesjonalistów z zakresu operacji IT oraz specjalistów od rozwoju oprogramowania. Uwzględnia współzależność rozwoju i operacji IT. Skraca czas wdrożenia funkcjonalności w oprogramowaniu. Pojęcie DevOps[1] zostało zaproponowane w 2009 przez Patricka Debois w trakcie dni DevOps w Gandawie.

Metoda rozwoju oprogramowania DevOps jest wskazana dla firm, gdzie częstotliwość edycji jest stosunkowo wysoka. Jeden z serwisów internetowych wykorzystuje DevOps do realizacji dziesięciu wdrożeń dziennie.

W firmach stosujących organizację DevOps, wdrożenia aplikacji wiążą się z mniejszym ryzykiem z powodu zwiększonej koordynacji wydań oraz zastosowanie narzędzi współpracy, takich jak wideokonferencja, e-mail, komunikatory internetowe oraz serwisy internetowe klasy wiki, w celu zagwarantowania dokładnego zrozumienia wymagań i właściwej współpracy wszystkich uczestników projektu.

Do zastosowania DevOps rekomendowane jest następujące środowisko IT:

• stosowanie programowania zwinnego lub podobnych metod wytwarzania oprogramowania,

• oczekiwanie właściciela biznesowego lub operacji IT na częste wersje

• dostępność infrastruktury w chmurze i jej wirtualizacja

• narzędzia automatyzacji i zarządzania konfiguracją w centrum danych.

PRINCE2

PRINCE2 – metodyka zarządzania projektami oparta na produktach. Zastosować ją można do zarządzania i sterowania projektami wszelkiego rodzaju i wszelkiej wielkości.

Nazwa jest skrótem słów: Projects In Controlled Environments, tzn. Projekty w sterowanym środowisku.

Syntetyczna charakterystyka

Co to jest projekt według PRINCE2? Organizacja powołana na pewien czas w celu wytworzenia – w przyjętym czasie oraz przy wykorzystaniu uprzednio określonych zasobów – niepowtarzalnych, a wcześniej określonych wyników czy rezultatu. Czy też – Warunki zarządzania stworzone w celu dostarczenia jednego lub wielu produktów natury biznesowej zgodnie z określonym uzasadnieniem biznesowym.

Właściwości projektu realizowanego według PRINCE2

1.Określony i skończony czas trwania

2. Zdefiniowane i mierzalne produkty biznesowe (wyniki projektu)

3. System działań niezbędnych do budowy produktów biznesowych

4. Określona pula zasobów

5. Struktura organizacyjna z zakresem obowiązków każdej z ról niezbędnej do zarządzania projektem

Rodzaje zasobów w PRINCE2

1. Pieniądze

2. Ludzie

3. Sprzęt (wyposażenie)

Komponenty, procesy a techniki PRINCE2

Stosując różne techniki, każdy proces wykorzystuje i/lub wytwarza komponenty.

Historia

U źródeł metodyki PRINCE2 leży PROMPT (Project Resource Organisation Management Planning Technique) metodyka prowadzenia projektów informatycznych opracowana przez firmę prywatną Simpact Systems Limited w połowie lat 70. Na zamówienie rządowe wzbogacono metodykę o kwestię zarządzania jakością. Część standardu pod nazwą PROMPT II została w 1983 r. wprowadzona w jednostkach administracji rządowej Wielkiej Brytanii. Po wykupieniu praw do metodyki PROMPT przez firmę LBMS, w 1989 r. brytyjska agenda rządowa Central Computer and Telecommunications Agency (CCTA) opublikowało standard pod nową nazwą – PRINCE (Projects in Controlled Environments) i wskazała jako zbiór najlepszych praktyk zarządzania projektami informatycznymi. Wkrótce jednak

metodyka zaczęła być stosowana także poza obszarem IT.

PRINCE2 został opublikowany po raz pierwszy w 1996 r. jako ogólna metoda zarządzania projektami niezależna od dziedziny biznesowej zastosowania. PRINCE2 szybko zdobywał popularność i stał się standardem de facto w Wielkiej Brytanii. Zyskuje też coraz szersze uznanie na całym świecie stanowiąc główną alternatywę (nie wykluczającą) dla metodyki PMBOK instytutu PMI. Ostatnie zmiany zostały opublikowane w 2005 przez Office for Government Commerce (OGC) – następcę CCTA. W 2009 roku została opublikowana nowa wersja.

ISO/IEC 27001

ISO/IEC 27001 – norma międzynarodowa standaryzująca systemy zarządzania bezpieczeństwem informacji. Została ogłoszona 14 października 2005 r. na podstawie brytyjskiego standardu BS 7799-2 opublikowanego przez BSI. W Polsce normę ISO/IEC 27001 opublikowano 4 stycznia 2007 r. jako PN-ISO/IEC 27001:2007. Norma ta zastąpiła PN-I-07799-2:2005 czyli polską wersję brytyjskiego standardu BS 7799-2.

ISO/IEC 27001:2005(PN-ISO/IEC 27001:2007) jest specyfikacją systemów zarządzania bezpieczeństwem informacji na zgodność z którą mogą być prowadzone audyty, na podstawie których są wydawane certyfikaty.

W normie ISO/IEC 27001 wyróżniono jedenaście obszarów, mających wpływ na bezpieczeństwo informacji w organizacji:

1. Polityka bezpieczeństwa;

2. Organizacja bezpieczeństwa informacji;

3. Zarządzanie aktywami;

4. Bezpieczeństwo zasobów ludzkich;

5. Bezpieczeństwo fizyczne i środowiskowe;

6. Zarządzanie systemami i sieciami;

7. Kontrola dostępu;

8. Zarządzanie ciągłością działania;

9. Pozyskiwanie, rozwój i utrzymanie systemów informatycznych;

10. Zarządzanie incydentami związanymi z bezpieczeństwem informacji;

11. Zgodność z wymaganiami prawnymi i własnymi standardami.

Norma PN-ISO/IEC 27001 stosuje znany już dobrze model “Planuj – Wykonuj – Sprawdzaj – Działaj” (PDCA), który jest stosowany do całej struktury procesów SZBI. Proces wdrażania SZBI został zdefiniowany jako:

Planuj – ustanowienie SZBI – ustanowienie polityki SZBI, celów, procesów i procedur istotnych dla zarządzania ryzykiem oraz doskonalenia bezpieczeństwa informacji tak, aby uzyskać wyniki zgodne z ogólnymi politykami i celami organizacji.

Wykonuj – wdrożenie i eksploatacja SZBI – wdrożenie i eksploatacja polityki SZBI, zabezpieczeń, procesów i procedur.

Sprawdzaj – monitorowanie i przegląd SZBI – pomiar wydajności procesów w odniesieniu do polityki SZBI, celów i doświadczenia praktycznego oraz dostarczania raportów kierownictwu do przeglądu.

Działaj – utrzymanie i doskonalenie SZBI – podejmowanie działań korygujących i zapobiegawczych na podstawie wyników wewnętrznego audytu SZBI i przeglądu realizowanego przez kierownictwo lub innych istotnych informacji, w celu zapewnienia ciągłego doskonalenia SZBI.

Poza zdefiniowaniem modelu zarządzania bezpieczeństwem informacji, norma PN-ISO/IEC 27001 zawiera opis zabezpieczeń, które należy stosować w celu ograniczenia ryzyka.