wozpi.agh.edu.plwozpi.agh.edu.pl/wp-content/uploads/exppmi17jun2010psv8.pdf · 2014-10-12 ·...

2010-08-06

1

Laboratorium Informatyki, Katedra Automatyki, AGH, Wydział EAIiE

Seminarium PMI Oddz. Kraków i Explicite KA AGH, 17 czerwca 2010

Porównanie metodyk zarządzania projektami PMBOK i Scrum przy użyciu modeli ontologicznych

Część III/III

Grzegorz Rogus, Piotr Szwed, Jan Werewka

Spis treści

• Co to jest ontologia?

• Dlaczego tworzymy ontologię?

• Komponenty ontologii

• Proces tworzenia ontologii – krok po kroku

2010-08-06

2

Agenda

• Ontologie PMBOK i Scrum – informacje ogólne

– Architektura– Jak powstawały ontologie PMBOK i Scrum

• Role– Role PMBOK– Role Scrum

• Artefakty– Artefakty PMBOK– Artefakty Scrum

• Zdarzenia– Zdarzenia PMBOK– Zdarzenia Scrum

• Procesy– Procesy PMBOK– Procesy Scrum

• Zastosowania• Podsumowanie

O ontologiach

PMBOK i Scrum

2010-08-06

3

Architektura ontologii PMBOK i Scrum

• Podstawowe elementy składowe to:

– Role (określające funkcje osób lub grup osób w metodyce)

– Artefakty (wejścia, wyjścia, produkty procesów zarządzania)

– Zdarzenia (obiekty o pewnych własnościach czasowych, jak czas wystąpienia lub czas trwania)

– Procesy (opisane przez podanie wejść, wyjść i niezbędnych zasobów: ról, narzędzi i technik)

Jak powstawała ontologia PMBOK 1

• Dwa etapy:

– Generacja części ontologii odpowiadającej modelowi

procesowemu na podstawie opisu w postaci tabeli

– Rozszerzenie, dodanie brakujących elementów,

refaktoryzacja

2010-08-06

4



pmbok.owl

Artifact Process

KnowledgeArea

ProcessGroup

Tools&TechniquesEvent Role

Relacje łączące procesy ze zdarzeniami i rolami

ChangeDecision

DecisionProcess

2. Refaktoryzacja

(Protégé)

2010-08-06

5

Jak powstawała ontologia

Scrum?

• Ontologia metodyki Scrum powstawała w 4 kolejnych iteracjach.

– W pierwszej iteracji na podstawie opisów literaturowych sporządzono opis tekstowy metodyki Scrum w postaci krótkich notatek definiujących znalezione pojęcia i ich relacje.

– W drugiej pojęcia zidentyfikowane w opisie tekstowym zostały zamodelowane jako ontologia.

– W trzeciej dokonano poprawek, usunięto redundantne pojęcia oraz uściślono pewne opisy i relacje.

– W czwartej przeprowadzono identyfikację procesów, które jawnie nie pojawiają się w opisach Scrum.

9

Role

2010-08-06

6

Rola - definicje

• Funkcja. Zbiór akcji i czynności przypisanych, oczekiwanych lub wymaganych od osoby lub grupy osób – X pełni funkcję dyrektora– Y pełni funkcję kierownika projektu

• Funkcja. Do czego coś jest używane? • Rola społeczna. Zbiór połączonych zachowań, praw i

zobowiązań. Często utożsamiana z pojęciem aktora. Rola wyznacza oczekiwane zachowanie w zależności od społecznego statusu i pozycji

• W programowaniu zorientowanym na role główną ideą jest, że człowiek myśli w kategoriach ról. Ten sam obiekt w zależności od sytuacji może odgrywać różne role:– Jan Kowalski jest Studentem uczestnicząc w zajęciach– Jan Kowalski jest UczestnikiemPrzyjęcia podczas przyjęcia

• Role są zdefiniowane przez: – możliwe interakcje z otoczeniem – wspólny zbiór własności

Role PMBOK 1

• Stakeholder ≡ Role

– ProjectPerformer (rola zaangażowana w realizację projektu)

• ProjectTeam

– ProjectDevelopmentTeam

– ProjectManagementTeam

• ProjectManager

• FunctionalManager

• ChangeControlBoard

– Customer (odbiorca)

– User

– Sponsor

– Seller

2010-08-06

7

Role PMBOK 2

• ProjectManager odpowiada za

– planowanie i organizację pracy

– zarządzanie bieżącymi działaniami w ramach projektu

– dostarczenie klientowi przedmiotów odbioru

• FunctionalManager odpowiada za zarządzanie dziedzinami związanymi z aspektem biznesowym:

– zasobami ludzkimi,

– finansami

– kontraktami z dostawcami

Role PMBOK 3

Własności ról w PMBOK (niewidoczne na diagramie) są określone w

ontologii poprzez ich uczestnictwo w procesach

2010-08-06

8

Role Scrum 1

• Podstawowe role Scrum to:

– Stakeholder - interesariusz,

– ProductOwner - właściciel produktu

– ScrumMaster - lider zespołu

– Team - zespół

– TeamMember - członek zespołu.

Role Scrum 2

• Stakeholder– Interesariusze, to osoby spoza grupy projektowej

zainteresowane lub zależne od przebiegu prac projektowych.

– Typowymi interesariuszami są: inwestor, kierownictwo firmy, klienci, użytkownicy i inni

• ProductOwner – właściciel produktu– Odpowiada za zarządzanie wymaganiami i nadzór

nad ich realizacją w kolejności określonej przez ich wartość biznesową.

– Jest rozliczany za sukces zespołu

2010-08-06

9

Role Scrum 3

• ScrumMaster

– Dba o zespół i jego morale

– Dba o postęp prac

– Usuwa przeszkody

– Nadzoruje zgodność praktyk projektowych z założeniami metodyki

• Team (zespół)

– Składa się z członków zespołu (TeamMember)

• TeamMember

– Członkowie zespołu Scrum powinni mieć umiejętności (Skills) wystarczające do rozwoju produktu

– Powinni mieć interdyscyplinarne i pokrywające się umiejętności

– Powinni być oddani (ang. committed) wyłącznie wykonaniu projektu, natomiast interesariusze powinni być zaangażowani w realizację projektu (ang. involved).

Role Scrum 4

• CommitedTeamMember: TeamMember and worksOn exactly 1 Project

• InvolvedTeamMember: TeamMember and worksOn min 2 Project

• Można też próbować zdefiniować CommitedTeamMember liczbowo:

TeamMember and has only ProjectEngagement that hasWorkEffortFTE exactly 1 double[>=0.95,<=1]

2010-08-06

10

Porównanie ról PMBOK i Scrum

PMBOK Scrum

Sponsor ProductOwner (definiowanie wymagań i ich wartości bzinesowej)

ProjectManager ProductOwner (określa priorytety wykonania)

ScrumMaster (usuwanie przeszkód)

Team (planowanie zadań)

FunctionalManager ScrumMaster

ProductOwner

DevelopmentTeam Team

Stakeholder and not ProjectPerformer

Stakeholder

Artefakty

2010-08-06

11

Artefakt - definicje

• Obiekt wytworzony przez człowieka traktowany jako pewna całość. • W archeologii. Obiekt wytworzony lub ukształtowany rękami ludzkimi.

Narzędzie, broń, ozdoba znaleziona na stanowisku poszukiwań archeologicznych

• Artefakt społeczny. Produkt jednostek lub grup osób lub przejawiane przez nie zachowanie społeczne

• W języku UML (Unified Modeling Language) artefakt jest to specyfikacja istniejącej fizycznie informacji, która jest używana lub wytwarzana w procesie rozwoju oprogramowania lub podczas wdrożenia lub działania systemu OMG (2008).

• Artefakt jest jednym z wielu typów materialnych produktów pośrednich wytwarzanych podczas rozwoju oprogramowania. Artefakty takie, jak przypadki użycia, diagramy klas i inne modele UML, opisy wymagań i dokumenty projektowe pozwalają opisać funkcje, architekturę i projekt oprogramowania

• W modelowaniu. Abstrakcyjna reprezentacja pewnego aspektu istniejącego lub budowanego systemu, komponentu lub widoku. Przykładem indywidualnych artefaktów są model graficzny, model strukturalny, dane tabelaryczne, strukturalny lub niestrukturalny opis tekstowy. Indywidualne artefakty mogą być agregowane i tworzyć artefakty złożone

Artefakty PMBOK 1

• W PMBOK artefakty są wejściami i wyjściami procesów projektowych. PMBOK definiuje 75 artefaktów biorących udział w ponad 300 przepływach pomiędzy procesami.

• Definicja PMBOK nie zapewnia formalnej klasyfikacji artefaktów, przedstawiony podział został wprowadzony w trakcie refaktoryzacji wygenerowanej ontologii.

• Artefakty zostały podzielone na grupy:• pmbok:ArtifactGroups

• pmbok:EnvironmentalArtifact• pmbok:ManagementDocument

• pmbok:ProjectPlan• pmbok:ProjectBaseline• Pmbok:SubsidiaryPlan

• pmbok:ProjectStatus

• pmbok:ProjectDeliverables

2010-08-06

12

Artefakty PMBOK 2

• EnvironmentalArtifacts – artefakty, które przepływają pomiędzy otoczeniem i procesami projektowymi (ale nie produkty dostawy)

Artefakty PMBOK 3

• Plany: pmbok:ManagementDocument

pmbok:ProjectPlan

pmbok:ProjectBaseline

pmbok:SubsidiaryPlan

2010-08-06

13

Artefakty PMBOK 4

• Pozostałe plany

Artefakty PMBOK 5

• GrupaManagementDocument

ProjectStatus

2010-08-06

14

Artefakty PMBOK 6

• Pozostałe dokumenty zarządzania (nie sklasyfikowane jako plany i dokumenty o statusie projektu)

Artefakty PMBOK 7

• ProjectDeliverables (produkty dostawy)

• Możliwa (konieczna) refaktoryzacja

ValidatedDeliverables ≡ Deliverables and hasStatus value Validated

AcceptedDeliverables ≡ Deliverables and hasStatus value Accepted

2010-08-06

15

Artefakty Scrum 1

• Charakterystyczne artefakty:

– ProductBacklog - rejestr produktowy

– SprintBacklog - rejestr zadaniowy

– ImpedimentsBacklog

– BurndownChart – wykres wypalania

• Dla Sprintu

• Dla produktu

Artefakty Scrum 2

• ProductBacklog

– stwierdzenie – „rejestr produktowy zawiera wymagania” uściślone przez relacje pomiędzy klasami:

ProductBacklog has some ProductBacklogItem

– ProductBacklogItem jest określony przez szereg własności

2010-08-06

16

Artefakty Scrum 3

• SprintBacklog

– stwierdzenie – „rejestr zadaniowy zawiera zadania” uściślone przez relacje pomiędzy klasami:

SprintBacklog has some TaskDescription

– TaskDescription jest określony przez własności

Artefakty Scrum 4

• ImpedimentBacklog zawiera elementy typu

ImpedimentBacklogItem

2010-08-06

17

Odwzorowanie artefaktów PMBOK i Scrum

PMBOK Scrum

WBS

Requirement document

MilestoneList

ProductBacklog

ActivityList

MilestoneList

SprintBacklog

WorkPerformance Measurements

WorkPerformanceInformation (Earned Value Diagrams)

BurndownChart

Zdarzenia

2010-08-06

18

Zdarzenia – definicja 1 [Wikipedia]

• Fenomen, obserwowalne wystąpienie lub nadzwyczajne wystąpienie (powódź, trzęsienie ziemi)

• Rodzaj zebrania:

– Ceremonia (ślub)

– Zawody

– Zjazd, spotkanie

– Przedstawienie, festiwal, sytuacja uznawana jako przejaw działalności artystycznej

– Wydarzenie medialne (zdarzenie przyciągające uwagę mediów)

– Przyjęcie, impreza

– Wydarzenie sportowe

• W informatyce: komunikat sygnalizujący, że coś się zdarzyło (naciśnięcie klawisza lub przycisku myszy)

Zdarzenia – definicja 2 [Wikipedia]

• W fizyce – sytuacja występująca w pewnym miejscu i czasie (obecność cząstki w czasoprzestrzeni)

• W filozofii - obiekt w czasie lub instancjacja pewnej cechy obiektu w czasie

• Jaegwon Kim

– Zdarzenie jest strukturą [x,P,t], gdzie

– x – obiekt lub zbiór obiektów

– P – zbiór własności

– t – moment czasowy lub interwał

Zdarzenie występuje, jeżeli obiekt x przejawia

własności P w momencie t

2010-08-06

19

Zdarzenie – ontologia zdarzeń

Event

DurableEvent InstantaneousEvent PeriodicEvent

Własności (opcjonalne):

•hasAgent (hasParticipant) – udziałowiec

•hasLocation – miejsce zdarzenia

•hasObject – obiekt uczestniczący w zdarzeniu

•casues, isCausedBy – zależności przyczynowe zdarzeń

Własności czasowe:

•hasDuration

•hasFrequency

•hasOccurenceTime

Relacje pomiędzy zdarzeniami (DurableEvent) :

after, before, overlaps, starts, during, finishes

Zdarzenie – relacje czasowe (1)

e1 before e2 , e2 after e1

e1 overlaps e2 (e2 overlaps e1)

2010-08-06

20

Zdarzenie – relacje czasowe (2)

e2 starts e1

e2 during e1

e2 finishes e1

Zdarzenia i procesy

• Konstruując ontologie Scrum i PMBOK rozdzielono zdarzenia i procesy:– Zdarzenia są zdefiniowane poprzez relacje czasowe (czas

wystąpienia, trwania, itd.) oraz własności (uczestników, miejsce, obiekt)

– Procesy transformują wejścia w wyjścia i są uruchamiane podczas zdarzeń lub w wyniku pojawienia się zdarzenia

• Dygresja– Zadanie (task) to proces lub jego część (aktywność) z

przypisanymi • parametrami czasowymi (czas rozpoczęcia, zakończenia,

oszacowanie czasu trwania)• Wykonawcami

– Nie mówimy, Event missed deadline lub Process missed deadline, ale: Task missed deadline…

2010-08-06

21

Zdarzenia PMBOK 1

• Podstawowe zdarzenia PMBOK

Zdarzenia PMBOK 2

• Projekt (Project)

• Faza (Phase)

2010-08-06

22

Zdarzenia PMBOK 3 Zależności czasowe wewnątrz fazy

Initiating starts some Phase

Initiating before some Planning

Planning overlaps some Executing

Closing finishes some Phase

itd…

Zdarzenia PMBOK 4 Relacje pomiędzy fazami 1

• Sekwencyjna

• Nakładanie się (overlaps)

2010-08-06

23

Zdarzenia PMBOK 5 Relacje pomiędzy fazami 2

• Iteracyjna (podczas etapu wykonania fazy odbywa się planowanie następnej fazy)

Zdarzenia Scrum 1

• Wykres cebulkowy wg. Mike Cohna (zmodyfikowany przez VersionOne Inc.) definiuje hierarchię zawierania się horyzontów planowania

Strategy

Release

Iteration

Daily

Continuous

acceptance

meeting

standup

review retrospection

Iteration

plan

backlog

estimation

release

plan

charterfounding

vision

goals

buildTDD

refactoring

integration collaboration

2010-08-06

24

Zdarzenia Scrum 2

• Zebrania pojawiające się w opisach praktyk Scrum:

– SprintPlanningMeeting - planowanie zakresu iteracji

– DailyScrumMeeting - codzienne spotkanie przeznaczone na omówienie postępu prac i planowanie

– SprintReviewMeeting - przegląd rezultatów osiągniętych w trakcie iteracji

– SprintRetrospectiveMeeting - sformułowanie wniosków z przebiegu iteracji i zaleceń na przyszłość

Zdarzenia Scrum 3 Klasyfikacja

2010-08-06

25

Zdarzenia Scrum 4 Zależności czasowe

Zdarzenia Scrum 5Relacje w ontologii zdarzeń Scrum

2010-08-06

26

Odwzorowanie zdarzeń PMBOK i ScrumPropozycja 1 Phase=ReleasePlanningHorizon

PMBOK Scrum

pmbok:Project scrum:StartegyPlanningHorizon

pmbok:Phase scrum:ReleasePlanningHorizon

pmbok:Initiating scrum:ReleasePlanningHorizon

pmbok:Planning Wielokrotne:

scrum:SprintPlanningMeeting

scrum:Sprint, scrum:Daily

pmbok:Executing scrum:Sprint, scrum:Daily

pmbok:MonitorngAndControlling scrum:Daily, scrum:SprintReviewMeeting,

scrum:SprintRetrospectiveMeeting

pmbok:Closing scrum:SprintReviewMeeting(związane z dostarczeniem wydania)

Odwzorowanie zdarzeń PMBOK i ScrumPropozycja 2Phase=Sprint

PMBOK Scrum

Brak odwzorowania scrum:StartegyPlanningHorizon

pmbok:Project scrum:ReleasePlanningHorizon

pmbok:Phase scrum:Sprint

pmbok:Initiating scrum:ReleasePlanningHorizon

Równolegle w trakcie trwania Sprintu

pmbok:Planning scrum:SprintPlanningMeeting

Scrum:Daily

pmbok:Executing scrum:Daily

Pmbok:MonitorngAndControlling scrum:Daily

scrum:SprintRetrospectiveMeeting

pmbok:Closing scrum:ReviewMeeting

2010-08-06

27

Odwzorowanie zdarzeń PMBOK i ScrumPropozycja 2

Procesy

2010-08-06

28

Proces definicja

• Ciąg zachodzących po sobie powiązanych procedur (zmian, stanów), które podczas kolejnych etapów konsumują zasoby (ludzkie, czas, energia, sprzęt, pieniądze), aby przekonwertować wejścia w wyjścia. Wyjścia służą jako wejścia kolejnych etapów, aż osiągnięty zostanie oczekiwany cel lub rezultat działania procesu.

Proces – model ontologiczny

2010-08-06

29

PMBOK procesy 1

• PMBOK definiuje 42 procesy podając ich:

– Wejściowe artefakty (relacja hasInput)

– Wyjściowe artefakty (relacja hasOutput)

– Narzędzia i techniki (hasToolsAndTechniques). Podano w sumie 129 narzędzi i technik.

• Procesom nie są jednoznacznie przypisane role odpowiadające za ich wykonanie (isExecutedBy)

• W PMBOK sklasyfikowano procesy na dwa sposoby:

– Poprzez przypisanie do grupy procesów (ProcessGroup)

– Poprzez przypisanie do obszaru wiedzy (KnowledgeArea)

PMBOK procesy 2Grupy procesów

• PMBOK definiuje następujące grupy procesów:

– InitiatingProcessGroup

– PlanningProcesGroup

– ExecutingProcessGroup

– MonitoringAndControllingProcessGroup

– ClosingProcessGroup

• Przynależność procesu do grupy zamodelowano jako relację:Process belongsToProcessGroup some ProcessGroup

• Równoczesnie zdefiniowano relację odwrotną łączącą grupy procesów z procesami:ProcessGroup containsProcess some Process

2010-08-06

30

PMBOK procesy 3Grupy procesów

• Podział procesów na grupy był źródłem identyfikacji zdarzeń wewnątrz fazy; proces należący do danej grupy jest wykonywany podczas odpowiadającego jej zdarzenia

PMBOK procesy 3Obszary wiedzy

• Drugą klasyfikacją jest przypisanie procesów do obszarów wiedzy

• Przynależność procesu do obszaru wiedzy zamodelowano jako relację:Process belongsToKnowledgeArea some KnowledgeArea

• Równoczesnie zdefiniowano relację odwrotną łączącą grupy procesów z procesami:KnowledgeArea coversProcess some Process

2010-08-06

31

PMBOK procesy 4Obszary wiedzy

PMBOK procesy 5Przykład definicji procesupmbok:CollectRequirements

2010-08-06

32

PMBOK procesy 6Przykład definicji procesupmbok:CollectRequirements

• Elementy wymagające uściślenia –ToolsAndTechniques

• Przykład (z dokumentacji):GroupCreativityTechniques– Brainstorming

– NominalGroupTechnique

– DelphiTechnique

– IdeaMindMapping

– AffinityDiagram

• Obecnie brak pełnych klasyfikacji

Scrum procesy 1

• Procesy fazy opracowywania strategii– 1.1. Vision Creation– 1.2. Product RoadMap Creation

• Procesy fazy planowania wydania– 2.1. Release Planning– 2.2. Initial Backlog Creation– 2.3. Backlog Updating

• Procesy fazy Sprintu (iteracji)– 3.1. Sprint Scope Planning – 3.2. Initial Sprint Planning – 3.3. Sprint Review– 3.4. Sprint Retrospective

• Procesy codzienne– 4.1. Sprint Tasks Control– 4.2. Sprint Tasks Updating– 4.3. Impediments Reporting– 4.4. Feature Development

2010-08-06

33

Scrum procesy 2Faza opracowania strategii 1.1. Vision Creation

Scrum procesy 3Faza opracowania strategii 1.2.Product RoadMap Creation

2010-08-06

34

Scrum procesy 4Faza planowania wydania 2.1. Release Planning

Scrum procesy 5Faza planowania wydania 2.2. Initial Backlog Creation

2010-08-06

35

Scrum procesy 6Faza planowania wydania 2.3. Backlog Updating

Scrum procesy 7Faza Sprintu3.1. Sprint Scope Planning

2010-08-06

36

Scrum procesy 8Faza Sprintu 3.2. Initial Sprint Planning

Scrum procesy 9Faza Sprintu 3.3. Sprint Review

2010-08-06

37

Scrum procesy 10Faza Sprintu 3.4.Sprint Retrospective

Scrum procesy 11Faza Daily 4.1. Sprint Tasks Control

2010-08-06

38

Scrum procesy 12Faza Daily 4.2. Sprint Tasks Updating

Scrum procesy 13Faza Daily

4.3. Impediments Reporting

2010-08-06

39

Scrum procesy 14Faza Daily 4.4. Feature Development

Odwzorowanie procesów PMBOK i Scrum?

• Jest planowane jako następny etap prac

• Powinno uwzględniać odwzorowanie:– Artefaktów (wejść i wyjść procesów)

– Zdarzeń, podczas których wykonywane są procesy

– Ról biorących udział w ich wykonaniu

• Planowane jest zastosowanie strukturalnych technik odwzorowania klas (pojęć) w ontologiach.

2010-08-06

40

Zastosowania

Zastosowania

• Obecne możliwe zastosowania

– Eksploracja modeli ontolologicznych

• nawigacja w Protégé

• przeglądanie wygenerowanych stron HTML

• zapytania

– Wykrywanie błędów i niespójności

• Przyszłe zastosowania

– Odwzorowanie ontologii

– Integracja

– Skalowanie i dekompozycja

2010-08-06

41

Zastosowania

Exploracja modelu PMBOK

• Poszukiwanie artefaktów przepływających pomiędzy

grupami procesów

Zastosowania

Przykład eksploracji modelu PMBOK 1

• Definiujemy sztuczną klasę (kwerendę) OutputFromInitaiatingInputToPlanning jako:

pmbok:Artifact

and isInputTo some (pmbok:Process

and belongsToProcessGroup some pmbok:PlanningProcessGroup)

and isOutputFrom some (pmbok:Process

and belongsToProcessGroup some pmbok:InitiatingProcessGroup)

2010-08-06

42

Zastosowania


Uruchamiamy maszynę wnioskującą, np.. Fact++ w Protégé. W

zbudowanej na podstawie wnioskowania hierarchii klas (inferred

class hierarchy) pojawia się poniższa klasyfikacja

Zastosowania


• Czy przepływ (3) jest reprezentowany przez jakieś artefakty?

• Definiujemy kwerendę OutputFromExecutingInputToClosing pmbok:Artifact

and isInputTo some (pmbok:Process

and belongsToProcessGroup some pmbok:ClosingProcessGroup)

and isOutputFrom some (pmbok:Process

and belongsToProcessGroup some pmbok:ExecutingProcessGroup)

• Odpowiedź: nie, brak artefaktów bezpośrednio przekazywanych z grupy Executing do Closing

2010-08-06

43

Zastosowania


• Czy przepływ (9) jest reprezentowany przez artefakty?

Zastosowania


Szczegółowa analiza ResourceCalendars

• Jest wyjściem

AcquireProjectTeam

(pewnego procesu

wykonania)

• Jest wejściem

DevelopSchedule

(pewnego procesu

planowania)

2010-08-06

44

Zastosowania


Błędy w PMBOK?

• Artefakty reprezentujące przepływ (5)?

• Błąd: Lista artefaktów pusta, oczekiwana ApprovedChangeRequest?

Kwerenda Definicja Wynik

ProcessProducing

ApprovedChangeRequests

pmbok:Process and hasOutput some pmbok:ApprovedChangeRequests

Brak takich procesów

ProcessProducing

ChangeRequestsStatusUpdates

pmbok:Process and hasOutput some pmbok:ChangeRequestsStatusUpdate

pmbok:

PerformIntegratedChangeControl

Zastosowania

Błędy w PMBOK?

?

2010-08-06

45

Zastosowania

Planowane zastosowania 1

• Budowa odwzorowań

pomiędzy klasami PMBOK i

Scrum:

– Rolami

– Artefaktami

– Zdarzeniami

– Procesami

• Wykorzystanie (opracowanie)

metod strukturalnego

odwzorowania lub metod

semantycznych

• Weryfikacja odwzorowań

(wyznaczanie odległości

pomiędzy klasami)

?

?

?

Zastosowania

Planowane zastosowania 2

• Skalowanie PMBOK

– Usuwanie wybranych procesów

– Usuwanie wybranych artefaktów – uaktualnianie wejść i wyjść

– Dekompozycja procesów na kilka mniejszych

• Odwzorowanie procesów organizacji w procesy wybranej metodyki

• Definiowanie procesów organizacji na podstawie procesów wybranej metodyki z równoczesnym skalowaniem i dekompozycją

• Integracja metodyki na podstawie integracji modeli ontologicznych

2010-08-06

46

Zastosowania

Planowane zastosowania 3 – przykład

Dekompozycja i skalowanie PerformQualityControl

Zastosowania



Wydzielono proces MeasureQuality

2010-08-06

47

Zastosowania



Wydzielono proces ValidateDeliverables

Zastosowania


Dekompozycja PerformQualityControl

Wydzielono proces ValidateChanges

2010-08-06

48

Podsumowanie

Podsumowanie 1

• Zbudowano ontologie dwóch metodyki zarządzania projektami PMBOK i Scrum

• Ich podstawowe elementy to:

– Role

– Artefakty

– Zdarzenia

– Procesy• Wszystkie elementy są powiązane relacjami

pozwalającymi na eksplorację modeli i szybkie wyszukiwanie informacji.

• Planowane są dalsze prace: modelowanie

– Zmian – w odniesieniu do wymagań, planów, czynników środowiskowych

– Decyzji – możliwości podejmowania decyzji przez poszczególne role, procesy decyzyjne

2010-08-06

49

Podsumowanie 2

• Zaletą modeli ontologicznych jest:

– Formalna postać

– Automatyzacja przetwarzania • Zastosowanie maszyn wnioskujących

• Możliwa jest implementacja oprogramowania do eksploracji modeli i ich modyfikacji

– Możliwość odwzorowania pojęć wspartych technikami odwzorowania ontologii

– Możliwość integracji ontologii i przeniesienia jej rezultatów na integrację metodyki zarządzania projektami

• Na poziomie organizacji (wdrożenie metodyki)

• Na poziomie ogólnym (propozycja integracji metodyki klasycznych i zwinnych)

Porównanie metodyk zarządzania projektami PMBOK i Scrum przy użyciu modeliontologicznych – Część 3

• Dziękuję z uwagę -Pytania?

2010-08-06

50

Literatura

1. Marek Jaślan, Branża IT ma się dobrze, www.msipolska.pl/rynek_200702.php4?num=445, 2007

2. Tomasz Sańpruch, www.prnews.pl, Bankier.pl, 2007

3. Tomasz Szetyński, Rynek IT rośnie powoli - firmy, które chcą istnieć na rynku zmieniają swoją strategie działania, www.globaleconomy.pl/content/view/80/17/, 2010

4. The Standish Group, www.standishgroup.com

5. J. Laurenz Eveleens, Chris Verhofer: The rise and Fall of the Chaos Report Figures. IEEESoftware, 2010, pp. 30- 36

6. Barry Boehm, Richard Turner, Balancing Agility and Discipline: A Guide for the Perplexed, Pearson Education, 204, p. 266

7. A Guide to the Project Management Body of Knowledge Fourth Edition (PMBOK® Guide), Approved American National Standard ANSI/PMI 99-001-2008, PMI 2008, s. 460.

Literatura

8. The state of Agile Development, 3rd annual Survey:2008, Full Data Report Conducted June-July 2008. VersionOne Inc. www.VersionOne.com/acnewsletter, s. 18.

9. Werewka J., Scaling Management of IT Projects Depending on their Size and Complexity, 1st CEE Symposium on Business Informatics, ACS, Vienna 2009, s. 181-190.

10.Mobilizing HP, Project Management as an Executive Priority. Benchmark Implementation: Primavera, Case Study, 2004 Benchmarking Partners, pp. 9

11.Schwaber K., Beedle M: Agile software development with Scrum. Upper Saddle River, N.J., Prentice Hall, 2002

12.Franke, U.; Hook, D.; Konig, J.; Lagerstrom, R.; Narman, P.; Ullberg, J.; Gustafsson, P.; Ekstedt, M.; EAF2- A Framework for Categorizing Enterprise Architecture Frameworks, ACIS International Conference on Software Engineering, Artificial Intelligences, Networking and Parallel/Distributed Computing, 2009. SNPD '09, pp.327 – 332

13.Gruber T.: A Translation Approach to Portable Ontology Specifications. Academic Press Ltd., 1993

14.Wikipedia: Ontology (information science), http://en.wikipedia.org/wiki/Ontology_(information_science)

2010-08-06

51

Literatura

15.Rumbaugh J., Jacobson I., Booch G. Unified Modeling Language Reference Manual, The (2nd Edition), Pearson Higher Education, 2004

16.Protégé: http://protege.stanford.edu/17.Jena - A Semantic Web Framework for Java,

http://jena.sourceforge.net/18.Euzenat J., Shvaiko P., Ontology matching, Springer Verlag

200719.Pinto, H. S., Gómez-Pérez, A., Martis, J. P. Some issues on

ontology integration. Proceeding of the IJCAI-99 workshop on Ontologies and Problem-Solving, Stockholm, Sweden, 1999, s. 7.1–7.12.

20.Sowa, J. F. Principles of ontology, onto-std mailing list, Wed, 3 Dec 1997, http://www-ksl.stanford.edu/onto-std/mailarchive/0136.html.

21.Kaneiwa K., Iwazume M., Fukuda K.: An Upper Ontology for Event Classifications and Relations. Australian Conference on Artificial Intelligence 2007: 394-403

Literatura

22.Allen J. F,. Ferguson G.: Actions and events in interval temporal logic. Technical Report TR521, Computer Science Department, University of Rochester, Rochester, New York 14627, July 1994.

23.Cohn M.: Agile Estimating and Planning, Prentice Hall/PTR, 2006, s.330

24.Agile Development Poster, http://pm.versionone.com/AgilePoster.html

25.Ivan Terziev, Atanas Kiryakov, Dimitar Mano, Base upper-level ontology (BULO) Guidance, EU-IST Project IST-2003-506826 SEKT

26.Daniel L. Moody, Theoretical and practical issues in evaluating the quality of conceptual models: current state and future directions, Data & Knowledge Engineering 55 (2005) 243–276

27.Guarino, Nicola, Chris Welty, Identity, Unity, and Individuation: Towards a Formal Toolkit for Ontological Analysis, W. Horn, ed., Proceedings of ECAI-2000: The European Conference on Artificial Intelligence. Amsterdam:IOS Press. Pp. 219-223. August, 2000.

wozpi.agh.edu.plwozpi.agh.edu.pl/wp-content/uploads/exppmi17jun2010psv8.pdf · 2014-10-12 ·...

Documents

Transcript of wozpi.agh.edu.plwozpi.agh.edu.pl/wp-content/uploads/exppmi17jun2010psv8.pdf · 2014-10-12 ·...