пропозиції роботи
Krzysztof Sorocki Tester
konto usunięte
Temat: Krytyczność vs Priorytet wymagania
Bardzo dobre pytanie, ponieważ wiele osób myli te dwa pojęcia i stosuje je (niesłusznie oczywiście) jako zamienniki.Najprościej ujmując:
Po zebraniu wymagań biznesowych od Klienta powinniśmy nadać im priorytet, czyli Klient musi wskazać (oczywiście z naszą pomocą) te wymagania, które z jego punktu widzenia mają:
A) Wysoki priorytet - czyli wymagania, bez których odbiór Produktu jest niemożliwy. Zazwyczaj są to wymaganie kluczowe dla pokrycia opisywanego procesu (nie chce się teraz rozpisywać na ten temat),
B) Średni priorytet - czyli wymagania, które są istotne (zazwyczaj powiązane z priorytetami o wysokim priorytecie), które muszą być zrobione, aby w pełni pokryć opisywany proces,
C) Niski priorytet- tzw. wymagani kosmetyczne, które nie są istotne z punktu widzenia opisywanego procesu, a stanowią tzw. "Nice to have", w przypadku presji czasu są to wymagania z których się rezygnuje, bądź przesuwa na kolejną iterację. Bez spełnienia tych wymagań procesowanie jest jak najbardziej możliwe,
Kolejnym krokiem jest nałożenie na te wszystkie wymagania skali krytyczności, czyli wskazanie, które z wymagań są krytyczne dla systemu od strony programistycznej. Może się okazać, że wymaganie posiadające priorytet wysoki ma krytyczność/pilność średnią, i na odwrót: wymaganie ocenione jako: średni, może posiadać wysoki stopień krytyczności.
Mając takie przydzielone stopnie dla wymagań najlepiej stworzyć sobie macierz oceny wymagań, które w kolumnach będą miały: Ważne, nieważne, a w wierszach: Pilne, niepilne. Wówczas zobaczymy, które z wymagań są najważniejsze ( te, które zostały wpisane w polu: "Ważne/Pilne" oraz "Ważne/niepilne".
To oczywiście w wielkim skrócie.
Jakiś czas temu pisałam artykuł na ten temat, więc zapraszam do lektury :)
http://pl.coremag.eu/ numer 10: "Jak zmierzyć niemierzalne....."
Krzysztof Sorocki Tester
Temat: Krytyczność vs Priorytet wymagania
Czyli krytyczność określają programiści a nie analitycy, tak ?Czy określanie krytyczności od strony programistycznej wynika bezpośrednio ze złożoności rozwiązania od strony programistycznej ?Krzysztof Sorocki edytował(a) ten post dnia 21.08.12 o godzinie 15:41
Jarosław
Żeliński
Analityk i
Projektant Systemów
Temat: Krytyczność vs Priorytet wymagania
A) Wysoki priorytet - czyli wymagania, bez których odbiór Produktu jest niemożliwy. Zazwyczaj są to wymaganie kluczowe dla pokrycia opisywanego procesu (nie chce się teraz rozpisywać na ten temat),
B) Średni priorytet - czyli wymagania, które są istotne (zazwyczaj powiązane z priorytetami o wysokim priorytecie), które muszą być zrobione, aby w pełni pokryć opisywany proces,
C) Niski priorytet- tzw. wymagani kosmetyczne, które nie są istotne z punktu widzenia opisywanego procesu, a stanowią tzw. "Nice to have", w przypadku presji czasu są to wymagania z których się rezygnuje, bądź przesuwa na kolejną iterację. Bez spełnienia tych wymagań procesowanie jest jak najbardziej możliwe,
Kolejnym krokiem jest nałożenie na te wszystkie wymagania skali krytyczności, czyli wskazanie, które z wymagań są krytyczne dla systemu od strony programistycznej. Może się okazać, że wymaganie posiadające priorytet wysoki ma krytyczność/pilność średnią, i na odwrót: wymaganie ocenione jako: średni, może posiadać wysoki stopień krytyczności.
Mając takie przydzielone stopnie dla wymagań najlepiej stworzyć sobie macierz oceny wymagań, które w kolumnach będą miały: Ważne, nieważne, a w wierszach: Pilne, niepilne. Wówczas zobaczymy, które z wymagań są najważniejsze ( te, które zostały wpisane w polu: "Ważne/Pilne" oraz "Ważne/niepilne".
To oczywiście w wielkim skrócie.
Jak interpretować wymaganie o statusie Wysoki priorytet i niska krytyczność (co by to nie miało znaczyć) i odwrotnie Niski priorytet/Krytyczne
konto usunięte
Temat: Krytyczność vs Priorytet wymagania
Krzysztofie,Proponowałbym tego typu parametry omawiać wewnątrz organizacji w której się znajdujesz. Parametrów może być i więcej, mogą mieć inne statusy, może być ich mniej. Stosowanie ich powinno być jednak zrozumiałe dla wszystkich w organizacji i powinno się odnosić do rzeczywistych potrzeb. Przykłady use casów z internetu czy szkoleń to są tylko przykłady, a ich faktyczną przydatność dla Was powinniście - moim zdaniem - oceniać sami na jakichś spotkaniach wewnętrznych.Piotr R. edytował(a) ten post dnia 21.08.12 o godzinie 16:16
Mateusz
Kurleto
Szukamy wybitnych
talentów do
świetnego zespołu IT
w Gdańsku
Temat: Krytyczność vs Priorytet wymagania
Jarek Żeliński:IMO nazywać to można różnie. Nie do końca rozumiem istnienie konkretnych atrybutów wymagań - moim zdaniem zależy to od projektu i środowiska wytwórczego. W każdym razie, jeśli dobrze zrozumiałem koleżankę, a w takim razie pokrywałoby się to z moim doświadczeniem.
Jak interpretować wymaganie o statusie Wysoki priorytet i niska krytyczność (co by to nie miało znaczyć) i odwrotnie Niski priorytet/Krytyczne
- istnieją wymagania ważne dla biznesu, bez których system nie ma sensu - np. repozytorium wycen, dostępne dla wszystkich z działu sprzedaży
niemniej jednak istnieją dużo mniej istotne biznesowo kwestie - np. w organizacji na tą chwilę dostęp do dokumentów jest publiczny, dopiero planowane jest ograniczanie dostępu na poziomie dokumentów/grupy dokumentów - natomiast z punktu widzenia implementacji systemu ta informacja to niewielki nakład na etapie realizacji wymagania dot. repozytorium albo kilkudziesięciokrotnie większa pracochłonność jeśli pominąć wymaganie dot. kontroli dostępu na poziomie dokumentu a potem je wdrażać po wdrożeniu systemu
te elementy związane z niską wartością biznesową i wysokim priorytetem dla IT dotyczą zwykle elementów związanych z architekturą systemu
Jarosław
Żeliński
Analityk i
Projektant Systemów
Temat: Krytyczność vs Priorytet wymagania
hm..... jak ogólnie:- wymagania biznesowe to wymagania wobec modelu biznesowego (zarządzanie)
- wymagania produktowe to wymagania wobec np. oprogramowania
Osobiście stosuje trzy-poziomową hierarchię 1,2,3 (lub niski, standard, wysoki np. priorytet)
należy podać interpretację cyferki zależnie od kontekstu bo priorytety mogą posłużyć do określenia zakresy projektu przy ograniczonym budżecie: wypadają te o najniższym priorytecie np. niski priorytet wymagania oznacza, że można pominąć, wysoki np. że bez tego wymagania budowa systemu nie ma sensu.
To co napisał Mateusz w moich oczach to inny problem: mam model systemu i śladowanie na wymagania, wydaje mi się że tylko analiza wpływu powie mi jaki poszczególne wymagania produktowe mają wpływ na wykonywalność systemu,
mam uwagę do oceny konsekwencji np. systemu praw dostępu: osobiście obstaje przy tezie, ze dobry projekt to tak opracowany model dziedziny, że poszerzenie funkcjonaliści nie rodzi potrzeby przerabiania systemu a jedynie jego rozbudowę... jeżeli system wymaga przeróbki to znaczy, że jest zafałszowany (źle zrozumiany) lub zbyt uproszczony (typowe dla systemów postawionych na znormalizowanym modelu relacyjnym).
konto usunięte
Temat: Krytyczność vs Priorytet wymagania
Jarek Żeliński:
Jak interpretować wymaganie o statusie Wysoki priorytet i niska krytyczność (co by to nie miało znaczyć) i odwrotnie Niski priorytet/Krytyczne
Nie zetknęłam się z takim formalnym podejściem, jeśli chodzi o krytyczność/pilność z punktu widzenia IT (a nie biznesu), ale oddaje to faktycznie rzeczywistość. Tzn. najpierw trzeba ogarnąć wszystkie wymagania biznesowe (3-stopniowa skala ważności jak najbardziej to ułatwia). Później przekłada się wymagania biznesowe na język IT, czyli określa się kolejność, ale też trudność i możliwość realizacji. I faktycznie powstaje pole do negocjacji, bo może być tak, że wymaganie "nice to have" jest tak skomplikowane w realizacji, że może warto się zastanowić nad realizacją, może zaproponować coś innego.
Wg mnie wymagania o niskim priorytecie i wysokiej krytyczności/trudności (IT) nie są warte realizacji, nie powinno takich być i warto je negocjować i wymieniać np. na coś bardziej przydatnego dla biznesu, a zdecydowanie łatwiejszego do realizacji - i od tego są analitycy systemowi i kierownicy projektów, jak mniemam :)
Ale w tym znaczeniu pilność, to coś innego niż krytyczność, użyłabym jeszcze określenia "wykonalność IT". Bo pilność oznaczałabym wyłącznie kolejność realizacji, natomiast krytyczność/wykonalność oznaczałaby skomplikowanie realizacji - osobiście jestem zwolenniczką prostych rozwiązań.
Jak rozumiem, pytanie jest pretekstem do dyskusji, bo wszelkie tego typu systematyki są bardzo względne i niejednoznaczne. A i tak najważniejszy jest biznes, trzeba zrozumieć jego potrzeby i zaproponować rozwiązanie jak najlepiej spełniające oczekiwania klienta :)
Mateusz
Kurleto
Szukamy wybitnych
talentów do
świetnego zespołu IT
w Gdańsku
Temat: Krytyczność vs Priorytet wymagania
Jarek Żeliński:Obawiam się, że żadne śladowanie w niczym Ci tu nie pomoże - chyba, że planujesz w ramach projektu dostarczyć pełen model klas i zależności wszystkich wykorzystywanych frameworków.
To co napisał Mateusz w moich oczach to inny problem: mam model systemu i śladowanie na wymagania, wydaje mi się że tylko analiza wpływu powie mi jaki poszczególne wymagania produktowe mają wpływ na wykonywalność systemu,
pewne kwestie związane są z architekturą systemu - jedna z definicji architektury, która bardzo mi się podoba mówi, że architektura systemu to te jego elementy, które muszą pozostać niezmienne jeśli nie chcemy go pisać od nowa.
mam uwagę do oceny konsekwencji np. systemu praw dostępu: osobiście obstaje przy tezie, ze dobry projekt to tak opracowany model dziedziny, że poszerzenie funkcjonaliści nie rodzi potrzeby przerabiania systemu a jedynie jego rozbudowę... jeżeli system wymaga przeróbki to znaczy, że jest zafałszowany (źle zrozumiany) lub zbyt uproszczony (typowe dla systemów postawionych na znormalizowanym modelu relacyjnym).Owszem, ale niektóre elementy - a autoryzacja, uwierzytelnianie i kontrola dostępu często do nich należą - to architektura systemu. Ograniczenie budżetu i harmonogramu zawsze wymaga pewnych kompromisów. Niektóre z nich są opłacalne, inne nie i to jest zawsze pewna dyskusja między wykonawcą a zleceniodawcą. Wydać 100 000 na wdrożenie takiego, czy innego pakietu funkcjonalności - czasem okazuje się, że warto część budżetu przeznaczyć na zaspokojenie pewnych potrzeb przyszłych.
konto usunięte
Temat: Krytyczność vs Priorytet wymagania
Jak dla mnie krytyczność i priorytetyzację wymagań rozpatrywałbym w dwu płaszczyznach:- cykl wytwórczy
- produkt
W cyklu wytwórczym priorytetyzacja to nic innego jak kolejność implementacji szczególnie w projektach złożonych o wielu iteracjach gdzie np. "nigdy" nie otrzymujemy produktu finalnego, albo z założenia wprowadzamy etapowość. Krytyczność zaś wiąże się ściśle z architekturą i założonymi wymaganiami wydajnościowymi i jakościowymi.
W ujęciu produktowym priorytetyzacja związana jest z oczekiwaniami klienta zorientowanymi na "czas" i też najlepiej widać to w etapowym procesie produkcji ostatecznego produktu. Krytyczność w ujęciu produktowym może być oceniana zarówno pod względem funkcjonalnym ale również jakościowym, ale w obu przypadkach dotyczy perspektywy korzyści z wdrożenia danego produktu.
Jarosław
Żeliński
Analityk i
Projektant Systemów
Temat: Krytyczność vs Priorytet wymagania
idąc tropem Mateusza i Bogdana, ostatnio stosuje w projektach wzorzec projektowy MVC z następującymi konsekwencjami:1. View (widok): klient "zamawia" formularz (papier/ekran), bo klient wie "co chce mieć"
2. analityk tworzy Model Domeny: 100% obiektów dziedzinowych z regułami (atrybuty i operacje biznesowe)
2. Analityk dostarcza listę wymagań poza-funkcjonalnych (wydajność, bezpieczeństwo, dostępność itp.)
3. developer implementuje Model Dziedziny, rozwiązuje problemy poza-funkcjonalne lub zgłasza ograniczenia ich realizacji
i tak:
100% wymagań funkcjonalnych realizuje Model Dziedziny, ty mamy priorytety
100% wymagań poza-funkcjonalnych realizuje developer (w tym zgłoszenia ograniczeń i negocjacje)
Priorytet wymagań funkcjonalnych to nic innego jak: wymaganie, waga, koszt wymagania
Czym na tym tle są owe krytyczne określenia (których autentycznie nie rozumiem)
konto usunięte
Temat: Krytyczność vs Priorytet wymagania
Krzysztof Sorocki:
Jednymi z atrybutów wymagań jest krytyczność oraz priorytet.
Na prawdę ? W jakiej metodyce / notacji ?
Jeśli metodyka / notacja tego nie wyjaśnia to nie zawracałbym sobie nią głowy.
Tak sobie analizuję tylko ;)
Jakie są między nimi różnice ?
Myślę, że artykuł "Jak mierzyć niemierzalne..." wszystko wyjaśna :D
Piękny tytuł oddający istotę Twojego problemu - szukasz "dobrych" rozwiązań złej sytuacji.Jakub Wojt edytował(a) ten post dnia 21.08.12 o godzinie 22:15
konto usunięte
Temat: Krytyczność vs Priorytet wymagania
Jarek Żeliński:
Osobiście stosuje trzy-poziomową hierarchię 1,2,3 (lub niski, standard, wysoki np. priorytet)>
Zgadzam się, zresztą rekomendowana jest używanie skali głównie 3 stopniowej :)
Podobne tematy
Następna dyskusja:
