Temat: MS Office to sabotaz projektów

To prawda, ale z drugiej sttrony, o ile wyczuwam intencję autora: do jednego prostego diagramu klas warto czasem zlinkować jpg z prototypem ekranu reprezentujacego formatkę generowana z tej klasy od grafika, albo user story (pierwowzór wymagania)

Oczywiście, że można.
Takie postępowanie ma kilka wad - "link" nie jest elementem diagramu klas. Jeśli występuje w komentarzu to wygląda to IMHO dziwnie.

Link może być elementem diagramu klas (bo diagram klas to tylko związki pojęciowe), ale CASE to nie tylko obrazki, to robi PowerPoint, CASE to zarządzanie dokumentacją... czyli zamiast szukać po nazwie na dysku tego jpg'a, klikam przypadek użycia i sam wyskakuje mi mock-up ekranu...

Dalej - po co ktoś miałby umieszczać taki link ?
Diagram klas prezentuje hierarchię dziedziczenia klas / interfejsów (w tym przykładzie widoku) a to potencjalnie nie ma nic wspólnego z wyglądem widoku.

diagram klas to także struktura kodu, zlinkowanie klasy realizujacej usługę, a przypadkiem użycia, kory ją modeluje, mock-upem właściwego ekranu i diagramem sekwencji, który pokazuje scenariusz tego use case, pozwala w ciągu sekundy zweryfikować kompletność i spójność całej takiej dokumentacji (a może mieć kilkadziesią use case'ów!) a nie ślęczeć nocami nad kilkudziesięcioma usecaseami i pilnowaniem czy wszystko się kupy trzyma...

Z resztą - jeśli na diagramie klas czasem warto umieszczać linki do grafik, to "czy czasem warto" umieszczać na grafice link do diagramu klas ?

oczywiście :), o ile narzędzie pozwala :)

Oczywiście prezentuję pewne skrajne / wyidealizowane podejście do zagadnienia.

a ja praktyczne :)

Temat: MS Office to sabotaz projektów

Jarek Ż.:

Piotr F.:
Twierdzisz ze wyniki analizy można wypluć z case'a. Oczywiście że można. Jest ot bardzo łatwe i wygodne dla wykonawcy. Tego typu dokumenty są długie i mało czytelne.

są dla niewprawnych mało czytelne, o długości decyduje autor...

Właśnie, dla niewprawnych. A muszą, a przynajmniej powinni je czytać i rozumieć niewprawni (decydenci, użytkownicy, biznes). W gronie informatyków szeroko rozumianych umiejętność rozmawiania (i pisania) w języku zrozumiałym przez ludzi to rzadkość. Akurat my, analitycy, jesteśmy tą grupą dla której ta umiejętność jest KLUCZOWA. W przeciwieństwie do choćby architektów i programistów, którzy mają pełną wolność w używaniu swoich zabawek - UML'i, System Architectów i generatorów kodu.
[.większy ciach...]

przypadek jest taki, że projekty zawalone przez agile poprawiam np. ja i jest to faktycznie kawał fajnych pieniędzy ale przez łzy sponsora...

Są rożne klasy projektów i rożni wykonawcy, nie twierdzisz mam nadzieję - choć można by tak interpretować niektóre słowa, że samo użycie case'a czyni z wykonawcy profesjonalistę

absolutnie nie

Uff, to dobrze, ale w takim razie czemu się spieramy? :)

Oczywiście generowane raporty wyglądają bardzo profesjonalnie- zwłaszcza dla nuworyszy. Ja raczej zwracam uwagę na treść i łatwość odbioru.

owszem, nie mylmy jednak złej dokumentacji z dobrą, ja od samego początku mam ma na myśli tylko to, że dwa relatywnie duże dokumenty o tej samej jakości, zawartości, spójności itp. jeden wykonany w MS Office a drugi w CASE, to ten pierwszy będzie znacznie kosztowniejszy,

No i tu trzeba zapytać o kwantyfikator - zawsze, czy czasami?
I jeszcze jak mierzyć jakość.
Ja uważam że narzędzie musi być dobrane do problemu z uwzględnieniem specyfiki organizacji i projektu. I nie ma takiego co będzie zawsze lepsze. A zazwyczaj: stawiam na metody proste. Prostota ma wartość.

to coś prawie jak renderowanie wizualizacji w AUTOCADzie i ręcznie w PaintBrushu, zawsze pytam: dlaczego architekci od pewnej skali projektów używają AUTOCADa a nie PowerPointa, dlaczego zarzucono deski kreślarskie (od których edytor teksty nie wiele obiega...no dobra, skoryguje literówki)????

Z tego samego powodu dla którego maszyny do pisania zastąpiono wordprocesorami, a listy zwykłe (co do zasady) elektronicznymi. Są lepsze do większości zastosowań.
Jednak ludzie nadal komunikują się językiem naturalnym, a nie kodem zerojedynkowym - i to się raczej nie zmieni, dopóki nie będziemy mieli w głowie implantów. Kto wie, czy nie stanie się to szybciej niż nam się wydaje ...

Kluczem jest ostatnie pytanie, w sumie mogło by ono być odpowiedzią zamiast całego tego wywodu :)

No i dlatego pociachałem :)

Temat: MS Office to sabotaz projektów

Piotr F.:

Jarek Ż.:

Piotr F.:
Twierdzisz ze wyniki analizy można wypluć z case'a. Oczywiście że można. Jest ot bardzo łatwe i wygodne dla wykonawcy. Tego typu dokumenty są długie i mało czytelne.

są dla niewprawnych mało czytelne, o długości decyduje autor...

Właśnie, dla niewprawnych. A muszą, a przynajmniej powinni je czytać i rozumieć niewprawni (decydenci, użytkownicy, biznes).

Wiesz tu widzę właśnie niewłaściwe adresowanie dokumentów...:) oraz... jeżeli adresatem są "niewprawni w IT" to faktycznie jest problem.... :(,

W gronie informatyków szeroko rozumianych umiejętność rozmawiania (i pisania) w języku zrozumiałym przez ludzi to rzadkość. Akurat my, analitycy, jesteśmy tą grupą dla której ta umiejętność jest KLUCZOWA. W przeciwieństwie do choćby architektów i programistów, którzy mają pełną wolność w używaniu swoich zabawek - UML'i, System Architectów i generatorów kodu.

OK, ale przypomnę, że 90% dokumentacji projektu IT nie jest adresowana dla Biznesu ... bez sensu jest dawanie mu jej do czytania :) (nawet gdy biznes nalega ;)))

Oczywiście generowane raporty wyglądają bardzo profesjonalnie- zwłaszcza dla nuworyszy. Ja raczej zwracam uwagę na treść i łatwość odbioru.

owszem, nie mylmy jednak złej dokumentacji z dobrą, ja od samego początku mam ma na myśli tylko to, że dwa relatywnie duże dokumenty o tej samej jakości, zawartości, spójności itp. jeden wykonany w MS Office a drugi w CASE, to ten pierwszy będzie znacznie kosztowniejszy,

No i tu trzeba zapytać o kwantyfikator - zawsze, czy czasami?
I jeszcze jak mierzyć jakość.

zaryzykuje, że zawsze ta sama praca wykonana tanimi i pracochłonnymi metodami jest kosztowniejsza (chyba się powtórzyłem ;)))

Ja uważam że narzędzie musi być dobrane do problemu z uwzględnieniem specyfiki organizacji i projektu. I nie ma takiego co będzie zawsze lepsze. A zazwyczaj: stawiam na metody proste. Prostota ma wartość.

tu się nie zgodzę: jak już w firmach ludzie mają np. Worda (potężne narzędzie do składu nawet setek stron tekstu, automatycznego generowania spisu treści, ilustracji, przypisów, kontroli ortografii itp.), piszą nim także proste notatki służbowe bo nie ma sensu, mając Worda, pisanie "prostych rzeczy" Notepadem ... tu mamy podobnie: mając CASE zrobię mega projekt i duperel, w druga stronę nie działa... a tu niestety mamy "pisanie wielkich rzeczy Notepadem"...

Jednak ludzie nadal komunikują się językiem naturalnym, a nie kodem zerojedynkowym - i to się raczej nie zmieni, dopóki nie będziemy mieli w głowie implantów. Kto wie, czy nie stanie się to szybciej niż nam się wydaje ...

owszem ale komunikacja ludzkim językiem nie blokuje postępu telefonii, telegrafii, czy internetu. z drugiej strony nie trzeba udowadniać, że w inżynierii "zwykły język naturalny" nie daje rady i dlatego powstały rysunki techniczne, zdjęcia roentgenowskie (rozumie jest tylko lekarz a to my na nich jesteśmy) ..... niestety wielu ludzi nie potrafi uznać, że nie wszystko potrafią i "pomagają" mechanikom naprawiać ich samochody czy "lepiej wiedzą" co kupić w aptece gdy boli...

ja swoich klientów niejako chronię przed nimi samymi, a jak stawiają zacięty upór zrywam umowę tak samo jak lekarz odmawiający dalszego leczenia ....

Kluczem jest ostatnie pytanie, w sumie mogło by ono być odpowiedzią zamiast całego tego wywodu :)

No i dlatego pociachałem :)

:)
obserwuję ciekawą rzecz: rynek rezygnuje z umów T&M i zaczyna wymuszać umowy o dzieło, które uczą pokory..... w korporacja pojawia się pojęcie "koszt projektu".... i ciesze się strasznie :)

Temat: MS Office to sabotaz projektów

Oczywiscie, ze mozna.
Takie postepowanie ma kilka wad - "link" nie jest elementem diagramu klas. Jesli wystepuje w komentarzu to wyglada to IMHO dziwnie.

Link moze byc elementem diagramu klas (bo diagram klas to tylko zwiazki pojeciowe), ale CASE to nie tylko obrazki, to robi PowerPoint, CASE to zarzadzanie dokumentacja... czyli zamiast szukac po nazwie na dysku tego jpg'a, klikam przypadek uzycia i sam wyskakuje mi mock-up ekranu...

Zadaniem diagramu klas jest przedstawienie struktury poszczególnych klas (interfejsów) i relacji jakie miedzy nimi (klasami / interfejsami) zachodza; do tego nie potrzeba elementu "link".

Linkowanie do innych dokumentów kojarzy mi sie raczej z pewna _praktyczną organizacja_ dokumentacji, a ta, moim zdaniem, nie powinna zmieniac tresci których dotyczy.
Z resztą - diagram klas z "linkami" pełni de facto dwie role, które nie mają ze sobą nic wspólnego; to może być źródłem problemów.

Temat: MS Office to sabotaz projektów

Jakub W.:

Oczywiscie, ze mozna.
Takie postepowanie ma kilka wad - "link" nie jest elementem diagramu klas. Jesli wystepuje w komentarzu to wyglada to IMHO dziwnie.

Link moze byc elementem diagramu klas (bo diagram klas to tylko zwiazki pojeciowe), ale CASE to nie tylko obrazki, to robi PowerPoint, CASE to zarzadzanie dokumentacja... czyli zamiast szukac po nazwie na dysku tego jpg'a, klikam przypadek uzycia i sam wyskakuje mi mock-up ekranu...

Zadaniem diagramu klas jest przedstawienie struktury poszczególnych klas (interfejsów) i relacji jakie miedzy nimi (klasami / interfejsami) zachodza; do tego nie potrzeba elementu "link".

nie masz racji niestety, to co opisujesz to jeden z możliwych kontekstów, diagram klas to tylko model związków pojęciowych i koniec, można go użyć do budowy modelu dziedziny, struktury oprogramowania ale także do modelowania systematyki ssaków albo insektów (diagram klas ma swój rodowód w latach 60tych w analizach leksykalnych) ... zawężasz użycia diagramu klas do modelownaia struktury obiektowego oprogramowania a to nie prawda (słowo unified w UML to słowo klucz :)))

Linkowanie do innych dokumentów kojarzy mi sie raczej z pewna _praktyczną organizacja_ dokumentacji, a ta, moim zdaniem, nie powinna zmieniac tresci których dotyczy.

oczywiście nie nie powinna, to wyłącznie ułatwienie posługiwania się nią, jednak jeżeli pakiet CASE potrafi wydrukowac tabele pokazując które obiekty na modelach są skojarzone z jakimi stronami WWW czy dokumentami na dysku to mamy załatwiony indeks literatury do modeli.

Z resztą - diagram klas z "linkami" pełni de facto dwie role, które nie mają ze sobą nic wspólnego; to może być źródłem problemów.

owszem, dlatego nie "przeciążam" zbytnio tego diagramu :) i np. modele pojęciowe robię diagramem faktów a nie UML/diagram klas ;)

Temat: MS Office to sabotaz projektów

Jarek Ż.:

Piotr F.:

Jarek Ż.:

Piotr F.:
Twierdzisz ze wyniki analizy można wypluć z case'a. Oczywiście że można. Jest ot bardzo łatwe i wygodne dla wykonawcy. Tego typu dokumenty są długie i mało czytelne.

są dla niewprawnych mało czytelne, o długości decyduje autor...

Właśnie, dla niewprawnych. A muszą, a przynajmniej powinni je czytać i rozumieć niewprawni (decydenci, użytkownicy, biznes).

Wiesz tu widzę właśnie niewłaściwe adresowanie dokumentów...:) oraz... jeżeli adresatem są "niewprawni w IT" to faktycznie jest problem.... :(,

To chyba clue sporu. Bo mnie się wydaje że sednem pracy analityka są dokumenty opisujące złożoną rzeczywistość w sposób prosty, tak aby podpisał się pod tym i biznes i IT. Specyfikacja wymagań opisuje zakres przedsięwzięcia. Nie szczegóły.

W gronie informatyków szeroko rozumianych umiejętność rozmawiania (i pisania) w języku zrozumiałym przez ludzi to rzadkość. Akurat my, analitycy, jesteśmy tą grupą dla której ta umiejętność jest KLUCZOWA. W przeciwieństwie do choćby architektów i programistów, którzy mają pełną wolność w używaniu swoich zabawek - UML'i, System Architectów i generatorów kodu.

OK, ale przypomnę, że 90% dokumentacji projektu IT nie jest adresowana dla Biznesu ... bez sensu jest dawanie mu jej do czytania :) (nawet gdy biznes nalega ;)))

Jasne, i te dokumenty może sobie IT robić po swojemu, w dowolnej UMLo podobnej notacji. Ale broń boże dawać to do czytania "normalnym ludziom".

Oczywiście generowane raporty wyglądają bardzo profesjonalnie- zwłaszcza dla nuworyszy. Ja raczej zwracam uwagę na treść i łatwość odbioru.

owszem, nie mylmy jednak złej dokumentacji z dobrą, ja od samego początku mam ma na myśli tylko to, że dwa relatywnie duże dokumenty o tej samej jakości, zawartości, spójności itp. jeden wykonany w MS Office a drugi w CASE, to ten pierwszy będzie znacznie kosztowniejszy,

No i tu trzeba zapytać o kwantyfikator - zawsze, czy czasami?
I jeszcze jak mierzyć jakość.

zaryzykuje, że zawsze ta sama praca wykonana tanimi i pracochłonnymi metodami jest kosztowniejsza (chyba się powtórzyłem ;)))

No właśnie nie zawsze, a nawet zazwyczaj nie. Jak sadzisz maliny w ogródku to nie bierzesz koparki. Lepsza będzie nawet dziecięca łopatka.

Ja uważam że narzędzie musi być dobrane do problemu z uwzględnieniem specyfiki organizacji i projektu. I nie ma takiego co będzie zawsze lepsze. A zazwyczaj: stawiam na metody proste. Prostota ma wartość.

tu się nie zgodzę: jak już w firmach ludzie mają np. Worda (potężne narzędzie do składu nawet setek stron tekstu, automatycznego generowania spisu treści, ilustracji, przypisów, kontroli ortografii itp.), piszą nim także proste notatki służbowe bo nie ma sensu, mając Worda, pisanie "prostych rzeczy" Notepadem ... tu mamy podobnie: mając CASE zrobię mega projekt i duperel, w druga stronę nie działa... a tu niestety mamy "pisanie wielkich rzeczy Notepadem"...

To że ludzie używają narzędzi źle to chyba nie jest dowód na to że tak jest dobrze?

Jednak ludzie nadal komunikują się językiem naturalnym, a nie kodem zerojedynkowym - i to się raczej nie zmieni, dopóki nie będziemy mieli w głowie implantów. Kto wie, czy nie stanie się to szybciej niż nam się wydaje ...

owszem ale komunikacja ludzkim językiem nie blokuje postępu telefonii, telegrafii, czy internetu. z drugiej strony nie trzeba udowadniać, że w inżynierii "zwykły język naturalny" nie daje rady i dlatego powstały rysunki techniczne, zdjęcia roentgenowskie (rozumie jest tylko lekarz a to my na nich jesteśmy) ..... niestety wielu ludzi nie potrafi uznać, że nie wszystko potrafią i "pomagają" mechanikom naprawiać ich samochody czy "lepiej wiedzą" co kupić w aptece gdy boli...

ja swoich klientów niejako chronię przed nimi samymi, a jak stawiają zacięty upór zrywam umowę tak samo jak lekarz odmawiający dalszego leczenia ....

Wiem że to nie komfort jak klient CI na ręce patrzy, ale niestety to jego prawo. Co nie znaczy że ma prawo mówić Ci co masz robić w każdym detalu i przeszkadzać w pracy - to dwie rożne sprawy.
Ja jeżdżę do mechaników którzy się swojej pracy nie wstydzą. I do lekarzy którzy nie boją się prostymi słowami - tak żebym to zrozumiał - powiedzieć o co chodzi na zdjęciu rentgenowskim. Wiesz, że nawet laik może to zobaczyć? Tylko profesjonalista musi mu pokazać. :)

[...]

obserwuję ciekawą rzecz: rynek rezygnuje z umów T&M i zaczyna wymuszać umowy o dzieło, które uczą pokory..... w korporacja pojawia się pojęcie "koszt projektu".... i ciesze się strasznie :)

Mówisz o zamówieniach na analizę czy na całość wdrożenia?
Od kiedy pamiętam zawsze stosowano umowy różnej maści, zależnie od rodzaju przedsięwzięcia. Akurat analizę dobrze się robi T&M bo przed nią ciężko zakres określić. Odwrotnie z programowaniem.

Temat: MS Office to sabotaz projektów

Piotr F.:

Wiesz tu widzę właśnie niewłaściwe adresowanie dokumentów...:) oraz... jeżeli adresatem są "niewprawni w IT" to faktycznie jest problem.... :(,

To chyba clue sporu. Bo mnie się wydaje że sednem pracy analityka są dokumenty opisujące złożoną rzeczywistość w sposób prosty, tak aby podpisał się pod tym i biznes i IT. Specyfikacja wymagań opisuje zakres przedsięwzięcia. Nie szczegóły.

Owszem, patrze na to jak prace architekta: dla klientów ma wizualizacje, dla developera szczegółowe rysunki... ale jednak sa to osobne rozdziały od tego samego "analityka"...

zaryzykuje, że zawsze ta sama praca wykonana tanimi i pracochłonnymi metodami jest kosztowniejsza (chyba się powtórzyłem ;)))

No właśnie nie zawsze, a nawet zazwyczaj nie. Jak sadzisz maliny w ogródku to nie bierzesz koparki. Lepsza będzie nawet dziecięca łopatka.

oczywiście, ale tu (cytowany artykuł) chodzi o projekty przerastające ogródek ;)

Ja uważam że narzędzie musi być dobrane do problemu z uwzględnieniem specyfiki organizacji i projektu. I nie ma takiego co będzie zawsze lepsze. A zazwyczaj: stawiam na metody proste. Prostota ma wartość.

tu się nie zgodzę: jak już w firmach ludzie mają np. Worda (potężne narzędzie do składu nawet setek stron tekstu, automatycznego generowania spisu treści, ilustracji, przypisów, kontroli ortografii itp.), piszą nim także proste notatki służbowe bo nie ma sensu, mając Worda, pisanie "prostych rzeczy" Notepadem ... tu mamy podobnie: mając CASE zrobię mega projekt i duperel, w druga stronę nie działa... a tu niestety mamy "pisanie wielkich rzeczy Notepadem"...

To że ludzie używają narzędzi źle to chyba nie jest dowód na to że tak jest dobrze?

racja... :) wskazałem tylko, że już mając "lepsze narzędzie" nie przeszkadza ono w robieniu nim także rzeczy prostych ...

ja swoich klientów niejako chronię przed nimi samymi, a jak stawiają zacięty upór zrywam umowę tak samo jak lekarz odmawiający dalszego leczenia ....

Wiem że to nie komfort jak klient CI na ręce patrzy, ale niestety to jego prawo. Co nie znaczy że ma prawo mówić Ci co masz robić w każdym detalu i przeszkadzać w pracy - to dwie rożne sprawy.

to zależy od zawartej umowy ;), patrzeć oczywiście może ale zgłaszać uwagi nie zawsze ;) jak u dentysty (poza tym, ze boli ;)))

Ja jeżdżę do mechaników którzy się swojej pracy nie wstydzą. I do lekarzy którzy nie boją się prostymi słowami - tak żebym to zrozumiał - powiedzieć o co chodzi na zdjęciu rentgenowskim. Wiesz, że nawet laik może to zobaczyć? Tylko profesjonalista musi mu pokazać. :)

widziałeś kiedyś wydruk tomografi? Ja tak, zapytałem lekarza co to jest, powiedział mi bardzo ładnie, uwierzyłem i nie polemizowałem ;) , Ty polemizujesz??

obserwuję ciekawą rzecz: rynek rezygnuje z umów T&M i zaczyna wymuszać umowy o dzieło, które uczą pokory..... w korporacja pojawia się pojęcie "koszt projektu".... i ciesze się strasznie :)

Mówisz o zamówieniach na analizę czy na całość wdrożenia?

o jednym i drugim...

Od kiedy pamiętam zawsze stosowano umowy różnej maści, zależnie od rodzaju przedsięwzięcia. Akurat analizę dobrze się robi T&M bo przed nią ciężko zakres określić.

a ja robię jako dzieło, bo jak ktoś ma projekt z terminem mający dwa etapy: analiza i wykonanie to jaki ma sens analiza T&M???? (ale nie mówię o projektach R&D). Analiza wykonana w skończonym czasie stanowi niejako studium wykonywalności... można nawet zarzucic po niej projekt ale jest to "dzieło:" a nie T&M. Jeden z moich klientów, bank, jasno okreśłił swoje wymagania: "za dwa miesiące ma powstać dokumentacja, która usprawni prace programistów"... rola analityka jest przede wszystkim panowanie nad szczegółowością dokumentacji i tu widzę najwięcej problemów, praca w rodzaju "aż skończę" to w moich oczach patologia....

Po protu bronie tezy, że powyżej pewnego poziomu złożoności proste metody szkodzą, zacytuję E.Yourdona: prostymi metodami analizy można zaprojektować i zbić budę dla psa, ale już nawet dom jednorodzinny powinien być najpierw dobrze przemyślany i zaprojektowany, że nie wspomnę o większych konstrukcjach. Nie da sie tego robić tak jak budy dla psa...Jarek Żeliński edytował(a) ten post dnia 29.04.13 o godzinie 19:43

Temat: MS Office to sabotaz projektów

To chyba clue sporu. Bo mnie się wydaje że sednem pracy analityka są dokumenty opisujące złożoną rzeczywistość w sposób prosty, tak aby podpisał się pod tym i biznes i IT. Specyfikacja wymagań opisuje zakres przedsięwzięcia. Nie szczegóły.

troszkę o tym tu:
http://it-consulting.pl/autoinstalator/wordpress/2011/...

Temat: MS Office to sabotaz projektów

Jarosław Ż.:
uwaga, będę się czepiał :)))

Praktyka jest taka,że w każdym projekcie używa takich się narzędzi jakie są akurat w organizacji dostępne i trzeba sobie jakość radzić w każdej sytuacji.

to brzmi jak w wojsku: "obiecaliśmy, że pomalujemy krawężniki ale mamy tylko szczoteczki do zębów, trudno, damy radę..."

Ok tylko na rynku 9X% firma używa szczoteczek do malowania krawężników więc mam wybór zarabiać pieniądze na malowaniu krawężników szczoteczkami (a w międzyczasie szukać firmy malującej krawężniki pędzlami) albo unieść się ego i być bezrobotny.

Niektórzy BA są tak umieszczeni w strukturze organizacji, że albo będą malować albo "organizacja" powie "wypierdalaj" - nie każdy jest niezależny i nie każdy jest mega Jarkiem Żelińskim

po drugie, jak ocenić kogoś kto bierze się za robotę, do której wie że nie ma właściwych narzędzie i wie że spaprze

niekiedy musi bo jak nie zrobi to go zwolnią - to jest kwestia mentalności organizacji a nie samych BA,
oczywiście trzeba szukać takich firm, w których krawężniki maluje się odpowiednim pędzlem

te robotę (świadome kilkukrotne podnoszenie kosztów także zaliczam do paprania), po drugie pakiet MS Office w kompletnej wersji jest znacznie droższy od niejednego narzędzia CASE.....

proszę to powiedzieć menażerom po MBA, bądź kierownikom działów zajmujących się analizą

co do głównego wątku oczywiście absolutnie się zgadzam