Temat: Analiza wymagań i projektowanie przed wdrożeniem systemów...

Stanisław Jerzy Niepostyn:

Z tego co piszesz wyciągam wnioski, że opisujesz Rational Unified Process. Własnie poprzez iteracje budujemy wielki system bez początkowych jakichs szczegółowych diagramów. Budujemy, wdrazamy, patrzymy, że dobrze działa, więc bierzemy następny kawałek i tak dalej.

Z tego co napisałeś, nasuwa się konkluzja: można zbudować 100 piętrową wieżę w modelu przyrostowym :). Tylko proszę tego nie rozumieć jako złośliwość..

Nie daj się zwieść agilnych historyjkom - to też iteracyjny sposób budowy oprogramowania, ale nie zawsze zespołowi chce się łapać za powiększanie dokumentacji.
A propos, czy wiesz, że RUP został opublikowany 13 lat temu ? A pierwszy większy projekt w Polsce, w którym zastosowano RUP to był system dopłat dla rolnictwa (IACS), którego budowe zaczęto w 2001 roku ?

Poznałem RUP jakieś 6 lat temu i zdaję sobię sprawę, że model iteracyjny to nic nowego. No i co prawda nie jestem wielkim zwolennikiem metodyk zwinnych, nie odrzucam ich i nie mam zamiaru wyśmiewać. Zderzyłem się we wdrożeniach z problemami, które potencjalnie podejście agilowe mogłoby rozwiązać, czy rozwiązałoby? Pozostawię to już jako pytanie retoryczne.

Przyznam, że zdarzyło mi się "sprzątać po innych" i to podejście iteracyjne, bliższe agilowemu niż RUP pozwoliło wdrożyć system, z którego klient był wreszcie zadowolony. Nie odrzucam jednak z tego powodu metod w jakich pierwotnie wdrożenie było prowadzone.

Dziękuję za ciekawą dyskusję, pozdrawiam i życzę wielu projektów "do posprzątania", bo w końcu z tego m.in. żyjemy ;).

Temat: Analiza wymagań i projektowanie przed wdrożeniem systemów...

Piotr Gorski:

Stanisław Jerzy Niepostyn:

Z tego co piszesz wyciągam wnioski, że opisujesz Rational Unified Process. Własnie poprzez iteracje budujemy wielki system bez początkowych jakichs szczegółowych diagramów. Budujemy, wdrazamy, patrzymy, że dobrze działa, więc bierzemy następny kawałek i tak dalej.

Z tego co napisałeś, nasuwa się konkluzja: można zbudować 100 piętrową wieżę w modelu przyrostowym :). Tylko proszę tego nie rozumieć jako złośliwość..

No chyba mnie mylisz z Jod ... Jeszcze raz pomylisz i nie wybaczę ;)
Nie "można", ale tylko w ten sposób buduje się wielkie systemy ....
O innych sposobach budowy oprogramowania obecnie wielkich systemów mówią jedynie fani literatury z ubiegłego wieku, bądź np. dziennikarze, którzy nie brali udziału we wdrożeniu systemu IT ...

Nie daj się zwieść agilnych historyjkom - to też iteracyjny sposób budowy oprogramowania, ale nie zawsze zespołowi chce się łapać za powiększanie dokumentacji.
A propos, czy wiesz, że RUP został opublikowany 13 lat temu ? A pierwszy większy projekt w Polsce, w którym zastosowano RUP to był system dopłat dla rolnictwa (IACS), którego budowe zaczęto w 2001 roku ?

Poznałem RUP jakieś 6 lat temu i zdaję sobię sprawę, że model iteracyjny to nic nowego. No i co prawda nie jestem wielkim

To chyba będziesz zdumiony, gdy Ci powiem, że to nie model iteracyjny jest główną koncepcją RUP, a model ... no jaki ? uwielbiam zadawać takie pytania :) jeszcze nikt, kto twierdził, że zna RUP, nie odpowiedział na nie poprawnie :)

zwolennikiem metodyk zwinnych, nie odrzucam ich i nie mam zamiaru wyśmiewać. Zderzyłem się we wdrożeniach z problemami, które potencjalnie podejście agilowe mogłoby rozwiązać, czy

agilne ...

rozwiązałoby? Pozostawię to już jako pytanie retoryczne.

Przyznam, że zdarzyło mi się "sprzątać po innych" i to podejście iteracyjne, bliższe agilowemu niż RUP pozwoliło

Podejście agilne to nic innego jak tzw. lightweight RUP ...
Ty zaś pewnie mówisz o metodyce RUP, w której opisujemy i robimy rzeczy mało potrzebne, a które to artefakty, czy czynności nie musimy realizować ...

wdrożyć system, z którego klient był wreszcie zadowolony. Nie odrzucam jednak z tego powodu metod w jakich pierwotnie wdrożenie było prowadzone.

Dziękuję za ciekawą dyskusję, pozdrawiam i życzę wielu projektów "do posprzątania", bo w końcu z tego m.in. żyjemy ;).

Nie, ja nie żyję ze sprzatania na razie ... i mam nadzieję, że nie będe musiał zamiatać ulice, robiłem to wszak za młodu ... A Tobie życzę dobrych i porządnych projektów

Temat: Analiza wymagań i projektowanie przed wdrożeniem systemów...

Piotr Gorski:
...
Przyznam, że zdarzyło mi się "sprzątać po innych" i to podejście iteracyjne, bliższe agilowemu niż RUP pozwoliło wdrożyć system, z którego klient był wreszcie zadowolony. Nie odrzucam jednak z tego powodu metod w jakich pierwotnie wdrożenie było prowadzone.

Zasadniczo RUP jest ramą projektową, co za tym idzie wszystko zależy od osoby, która RUP dostosowuje. W najbardziej rozwiniętym układzie RUP oferuje nie tylko iteracyjno-przyrostowy model rozwoju oprogramowania, ale również spiralny. Połączenie jednego i drugiego modelu jest bardzo efektywne, ale czasem biznes zwyczajnie nie chce iterować a tym bardzie w cyklicznie odbierać komponenty.

Jak się ma to wszystko do tematu forum? Otóż zgodnie ze sztuką RUPową analiza wymagań powinna dotyczyć wybranego aspektu działania systemu i po takiej analizie powinno się wytworzyć odpowiednie komponenty systemu, przetestować i wdrożyć. Po czym następuje kolejna analizy implementacji i przekazanie itd. Jak do tej pory jest to najbardziej skuteczne podejście jeśli chodzi o wytwarzanie systemów.

Na koniec dodam, że dobrze dopasowany RUP wygra z każdą zwinną metodyką, ale każda metodyka może przegrać z "rozpieszczonym" klientem.

Temat: Analiza wymagań i projektowanie przed wdrożeniem systemów...

Aleksander Olszewski:

Na koniec dodam, że dobrze dopasowany RUP wygra z każdą zwinną metodyką, ale każda metodyka może przegrać z "rozpieszczonym" klientem.

Aleksander, ale dlaczego tak uważasz? Gdzie zwolennicy zwinnych metodyk, można powiedzieć "świeższych" (jakkolwiek nie wszystko co nowsze musi być lepsze), mylą się?

A co do tego, że każda metodyka może przegrać z rozpaskudzonym klientem to się zgodzę bezdyskusyjnie :). No ale w końcu po to m.in. jest PM, żeby zdyscyplinować uczestników projektu.

Temat: Analiza wymagań i projektowanie przed wdrożeniem systemów...

Aleksander Olszewski:
Zasadniczo RUP jest ramą projektową, co za tym idzie wszystko zależy od osoby, która RUP dostosowuje.

Dokładnie tak, ma także wrażenie, ze bardzo często pomija się to "czego dotyczą przyrosty". Każdy system budowany jest metodą przyrostową, bo nie da się na jedno kliknięcie napisać całego kodu, po drugie system składa się z odrębnych usług (przypadki użycia) i powstają one w jakiejś tam kolejności, kolejne iteracje jak najbardziej: system jest rozwijany.

Całość jednak zawsze wymaga opracowania ogólnej koncepcji i projektu całości niezależnie od tego jak szczegółowego. 100-piętrowy dom jak najbardziej jest budowany przyrostowo (piętro po pietrze), ale zanim się go zacznie budować należy go zaprojektować. Jakoś nie wyobrażam sobie rozpoczęcia budowy takiego wieżowca bez wiedzy ile docelowo pieter powstanie... (albo i wyobrażam sobie :)) .........)

Jak się ma to wszystko do tematu forum? Otóż zgodnie ze sztuką RUPową analiza wymagań powinna dotyczyć wybranego aspektu działania systemu i po takiej analizie powinno się wytworzyć odpowiednie komponenty systemu, przetestować i wdrożyć. Po czym następuje kolejna analizy implementacji i przekazanie itd. Jak do tej pory jest to najbardziej skuteczne podejście jeśli chodzi o wytwarzanie systemów.

Dodać należy, że "nad tym" powinna być (opracowana na samym początku) koncepcja całości. Zaryzykuje tezę, że "jedna budowla" to jeden projekt, tak więc wieża na 100 pięter jest tu projektem a nie poszczególne piętra... znaczy to, że na początku powinien powstać projekt całej wieży (musimy wiedzieć ile pięter docelowo powstanie, żeby zaprojektować fundament) a nie tylko fundamentów i parteru...

Kolejne etapy to jak najbardziej, zgodnie z RUP przyrostowe projektowanie szczegółów każdego piętra...

Na koniec dodam, że dobrze dopasowany RUP wygra z każdą zwinną metodyką, ale każda metodyka może przegrać z "rozpieszczonym" klientem.

no coś w tym jest :), rozumiem że rozpieszczony klient to taki co to nie ma pojęcia o budowę ale najlepiej wie jak się buduje domy... moim zdaniem problemem nie jest rozpieszczony klient a ustępliwy wykonawca...

Temat: Analiza wymagań i projektowanie przed wdrożeniem systemów...

Gdzie zwolennicy zwinnych metodyk, można powiedzieć "świeższych" (jakkolwiek nie wszystko co nowsze musi być lepsze), mylą się?

w moich oczach są dwa wyjścia: albo słowo "zwinne" to nowy papierek na stary i znany cukierek o nazwie RUP, albo może niech ktoś w końcu przytoczy definicję i opis tej metodyki zwanej "zwinna". Bo jak słyszę na innych grupa "Agile nie ma definicji, to mentalność" to mi ręce opadają...

Zwracam uwagę, ze Manifest Agile
http://agilemanifesto.org/iso/pl/
to ani Definicja, ani Metodyka ani nawet Specyfikacja metod.

P.S.
W kwestii świeżości Agile:
Spotykamy dwa rodzaje "produktów":
- nietrwałe, np. warzywa i tu liczy się to czy są świeże bo po pewnym terminie są już nieświeże (nieprzydatne),
- trwałe, które jak raz powstaną to nie ma dla nich pojęcia "świeżości" bo staja się klasyką tak jak budowle i filozofia starożytności...;)

Zupełnie przypadkiem wpadłem na stronę, tak wygląda oferta poważnej i rzetelnej w moich oczach firmy (nie znam ich, mam na myśli podejście), u dołu strony Porównanie metod współpracy:
http://www.consdata.pl/pl/usugi/usugi/fixed-price-cont...

(co najwyżej polemizował bym z brakiem możliwości zmiany zakresu projektu w trakcie jego trwania dla fixed-price)Jarek Żeliński edytował(a) ten post dnia 14.05.12 o godzinie 12:41

Temat: Analiza wymagań i projektowanie przed wdrożeniem systemów...

Ale jaja ... ;) "Doświadczony <<Analityk biznesowy>>" nie zna manifestu .... ale od bardzo długiego czasu wypowiada się na temat metodyk agilnych ....
Ręcę i nogi opadają ....

Temat: Analiza wymagań i projektowanie przed wdrożeniem systemów...

Jarek Żeliński:

It is very important to have a clear interface between the presentation logic (user interface) and the business logic. Do not mix these two types of logic.

Business logic must be implemented in classes and on tables.

Tu się nie zgodzę. W części "on tables".

Never design your business logic so that it has direct references to controls on forms or reports. The design of the business logic must enable any relevant form or report to use it.

True that.

A co mnie naszło, że o tym pisze? Bo jeden z moich kolejnych klientów zaczął do mnie list od słów: "Szanowny Panie, własnie jeden z GoldPartnerów firmy Microsoft modelowo położył mój projekt, czy może nam Pan pomóc..." i tylko kłopot w tym, że projekt położony ale i budżet zjedzony w 80%...

Nic nowego:) Zapewne za ten zjedzony budżet można było wdrożyć modelowo to co potrzebują, a unikatowe procesy zaimplementować jako dedykowaną aplikację - zgodnie zresztą z zaleceniami producenta.

Temat: Analiza wymagań i projektowanie przed wdrożeniem systemów...

Mateusz Kurleto:

Business logic must be implemented in classes and on tables.

Tu się nie zgodzę. W części "on tables".

no tak :) faktycznie

Temat: Analiza wymagań i projektowanie przed wdrożeniem systemów...

Jarek Żeliński:

Dodać należy, że "nad tym" powinna być (opracowana na samym początku) koncepcja całości. Zaryzykuje tezę, że "jedna budowla" to jeden projekt, tak więc wieża na 100 pięter jest tu projektem a nie poszczególne piętra... znaczy to, że na początku powinien powstać projekt całej wieży (musimy wiedzieć ile pięter docelowo powstanie, żeby zaprojektować fundament) a nie tylko fundamentów i parteru...

Jak najbardziej przed właściwym projektowaniem jest faza Rozpoczęcie, która dotyka typowych biznesowych aspektów projektu. Dopiero potem jest analiza systemowa i projektowanie.

Natomiast używając alegorii z wieżą, budowa takiej wedle RUP wyglądała by mniej więcej tak jak wznoszenie żurawi budowlanych: wytwarzamy komponenty w dowolnej kolejności które składamy na miejscu budowy w dźwig o wymaganych parametrach.

no coś w tym jest :), rozumiem że rozpieszczony klient to taki co to nie ma pojęcia o budowę ale najlepiej wie jak się buduje domy... moim zdaniem problemem nie jest rozpieszczony klient a ustępliwy wykonawca...

Ktoś takiego klienta "rozpieszcza" :) Problem leży gdzieś po środku pomiędzy klientem a dostawcą. Jedni i drudzy powinni dojrzeć do pewnego ładu projektowego.

Temat: Analiza wymagań i projektowanie przed wdrożeniem systemów...

Piotr Gorski:
...

Aleksander Olszewski:

Na koniec dodam, że dobrze dopasowany RUP wygra z każdą zwinną metodyką, ale każda metodyka może przegrać z "rozpieszczonym" klientem.

Aleksander, ale dlaczego tak uważasz? Gdzie zwolennicy zwinnych metodyk, można powiedzieć "świeższych" (jakkolwiek nie wszystko co nowsze musi być lepsze), mylą się?

RUP miał pecha i... powstał jakieś 10 lat przed manifestem :) Niedługo po manifeście powstałą odmiana openUP która wymagał formalne wytyczne Agile.

Co do samego RUP, to wygrywa z każdą zwinną swoim poziomem dopracowania. Co więcej ma potwierdzone i zbadane sukcesy. Powstałą w wyniku dogłębnego badania projektów. Powodów jest dużo, dlaczego RUP może wygrać z zwinnymi metodykami.

Żeby być uczciwy, to ma również wadę: jest wymagająca co wiedzy i umiejętności wszystkich uczestników projektu.

Temat: Analiza wymagań i projektowanie przed wdrożeniem systemów...

Coś GL "zwariował". Te dwie ostatnie to rzecz jasna nieświadomy SPAM, którym GL wszystkich "obdarzył".

Temat: Analiza wymagań i projektowanie przed wdrożeniem systemów...

Natomiast używając alegorii z wieżą, budowa takiej wedle RUP wyglądała by mniej więcej tak jak wznoszenie żurawi budowlanych: wytwarzamy komponenty w dowolnej kolejności które składamy na miejscu budowy w dźwig o wymaganych parametrach.

co nie zmienia jednak faktu, ze ma wyliczoną na bazie projektu maksymalną wysokość... ;)

Temat: Analiza wymagań i projektowanie przed wdrożeniem systemów...

Jarek Żeliński:

Natomiast używając alegorii z wieżą, budowa takiej wedle RUP wyglądała by mniej więcej tak jak wznoszenie żurawi budowlanych: wytwarzamy komponenty w dowolnej kolejności które składamy na miejscu budowy w dźwig o wymaganych parametrach.

co nie zmienia jednak faktu, ze ma wyliczoną na bazie projektu maksymalną wysokość... ;)

Zgadza się :)

Temat: Analiza wymagań i projektowanie przed wdrożeniem systemów...

Jarek Żeliński:
...
w moich oczach są dwa wyjścia: albo słowo "zwinne" to nowy papierek na stary i znany cukierek o nazwie RUP, albo może niech ktoś w końcu przytoczy definicję i opis tej metodyki zwanej "zwinna". Bo jak słyszę na innych grupa "Agile nie ma definicji, to mentalność" to mi ręce opadają...

Właściwie to stwierdzenie takie ma być postaci: Agile to nie metodyka, to sposób myślenia. Z resztą podobnie jest z Lean.

Gdybym miał podać definicję metody zwinnych, powiedziałbym że jest to rodzaj metodyki, która większą część swojej uwagi poświęca zagadnieniom tzw. miękkim: zarządzaniem relacjami w zespole i z klientem, stosuje zasadę oszczędności działania oraz preferuje efekt końcowy ponad obyczajową formę.

Zwracam uwagę, ze Manifest Agile
http://agilemanifesto.org/iso/pl/
to ani Definicja, ani Metodyka ani nawet Specyfikacja metod.

Podobnie jest np. z XP: z grubsza jest to 12 dobrych praktyk i nic ponadto.

P.S.
W kwestii świeżości Agile:
Spotykamy dwa rodzaje "produktów":
- nietrwałe, np. warzywa i tu liczy się to czy są świeże bo po pewnym terminie są już nieświeże (nieprzydatne),
- trwałe, które jak raz powstaną to nie ma dla nich pojęcia "świeżości" bo staja się klasyką tak jak budowle i filozofia starożytności...;)

Stara anegdota mówi, że w informatycy wymyślanie wszystkich nowych pomysłów skończyło się w latach 50., gdy komputer został zminiaturyzowany do wielkości kilku pokoi ;)

Zupełnie przypadkiem wpadłem na stronę, tak wygląda oferta poważnej i rzetelnej w moich oczach firmy (nie znam ich, mam na myśli podejście), u dołu strony Porównanie metod współpracy:
http://www.consdata.pl/pl/usugi/usugi/fixed-price-cont...

Czyli Fix Price wygląda nie najgorzej ;)

(co najwyżej polemizował bym z brakiem możliwości zmiany zakresu projektu w trakcie jego trwania dla fixed-price)

W sumie zgadzam się: stałą cena nie wyklucza możliwości zmiany zakresu :)

Temat: Analiza wymagań i projektowanie przed wdrożeniem systemów...

Właściwie to stwierdzenie takie ma być postaci: Agile to nie metodyka, to sposób myślenia.
Gdybym miał podać definicję metody zwinnych, powiedziałbym że jest to rodzaj metodyki, która większą część swojej uwagi poświęca zagadnieniom tzw. miękkim: zarządzaniem relacjami w zespole i z klientem, stosuje zasadę oszczędności działania oraz preferuje efekt końcowy ponad obyczajową formę.

tak więc można klasyfikować konkretne metodyki na mniej lub bardziej ciężkie lub zwinne i chyba nic ponad to...Jarek Żeliński edytował(a) ten post dnia 15.05.12 o godzinie 09:58

Temat: Analiza wymagań i projektowanie przed wdrożeniem systemów...

(co najwyżej polemizował bym z brakiem możliwości zmiany zakresu projektu w trakcie jego trwania dla fixed-price)

W sumie zgadzam się: stałą cena nie wyklucza możliwości zmiany zakresu :)

Stała cena nie przeszkadza klientowi w robieniu prób wrzut nawet pod koniec projektu, więc zakres potrafi być z gumy, jak PM jest mało kumaty i mało asertywny :)
Mało który klient rozumie, że tym działa na swoją niekorzyść.

Scope-creep jest wg Capersa Jonesa (i nie tylko jego) jedną z głównych przyczyn upadku projektów... i ja się z nim zgadzam. Na mnie jak płachta na byka działają próby wrzutek po zamknięciu zakresu. Witamy w procesie obsługi zmian :)

Temat: Analiza wymagań i projektowanie przed wdrożeniem systemów...

Bartosz Andrzejewski:

(co najwyżej polemizował bym z brakiem możliwości zmiany zakresu projektu w trakcie jego trwania dla fixed-price)

W sumie zgadzam się: stałą cena nie wyklucza możliwości zmiany zakresu :)

Tu akurat miałem zmianę zakresu w stylu PRINCE2: nie dorzucamy do zakresu: albo poruszamy się w zakresie wyznaczonej tolerancji, albo uszczuplamy zakres w porozumieniu z klientem.

Stała cena nie przeszkadza klientowi w robieniu prób wrzut nawet pod koniec projektu, więc zakres potrafi być z gumy, jak PM jest mało kumaty i mało asertywny :)
Mało który klient rozumie, że tym działa na swoją niekorzyść.

To chyba się odzywa nasze rodzime podejście: a nie da się zrobić 20%-50% w tej samej cenie i czasie, a nadgodzin i tak nie liczymy? Każda metodyka reguluje takie zachowania, a sama metodyka jest po to by nie wymyślać samemu od nowa i korzystać z doświadczenia innych.

Scope-creep jest wg Capersa Jonesa (i nie tylko jego) jedną z głównych przyczyn upadku projektów... i ja się z nim zgadzam. Na mnie jak płachta na byka działają próby wrzutek po zamknięciu zakresu. Witamy w procesie obsługi zmian :)

RUP akurat reguluje takie chęci klienta: bo przecież nie powiemy klientowi nie, nie ma szans. W tym przypadku przesuwamy dodatkowy wymagania na kolejny cykl projektowy, a że cykle są dosyć krótkie (kilkutygodniowe), to i tak z reguły jest krótsze niż cykl decyzyjny w korporacji.

Temat: Analiza wymagań i projektowanie przed wdrożeniem systemów...

Stała cena nie przeszkadza klientowi w robieniu prób wrzut nawet pod koniec projektu, więc zakres potrafi być z gumy, jak PM jest mało kumaty i mało asertywny :)
Mało który klient rozumie, że tym działa na swoją niekorzyść.

stała cena to dobrze określony zakres, nie ma w zakresie nie ma wykonania, takie "życzenie" - po obronie jego zasadności - przechodzi do kolejnej iteracji i kolejnej wyceny ... to wymaga także w modelu motywacji biznesowej dla każdego wymagania...

Scope-creep jest wg Capersa Jonesa (i nie tylko jego) jedną z głównych przyczyn upadku projektów... i ja się z nim zgadzam. Na mnie jak płachta na byka działają próby wrzutek po zamknięciu zakresu. Witamy w procesie obsługi zmian :)

witam w procesie ich wyrzucania ;) (pisze to całkiem poważnie). Klient ma w umowie metodykę:
1.musi wskazać biznesowe uzasadnienie wrzutki
2. musi wskazać, z czego rezygnuje w zamian przy umowie fixed price lub wskazać finansowanie

Temat: Analiza wymagań i projektowanie przed wdrożeniem systemów...

Stanisław Jerzy Niepostyn:
Ale jaja ... ;) "Doświadczony <<Analityk biznesowy>>" nie zna manifestu ....

Ani Newton ani Einstein nie pisali "manifestów" a konkretne prace naukowe...
"Manifest" to może sobie napisać każdy każdy i z dowolnego (najczęściej głupiego) powodu

ale od bardzo długiego czasu wypowiada się na temat metodyk agilnych ....

jeszcze nikt nie udowodnił nie istnienia UFO (karmy, prądów wodnych etc ...) więc jak ktoś pisze, że ich (ufo, prądów etc..) niema to na prawdę nie robi odkrycia a jedynie stwierdza, że go nie ma.Jakub Wojt edytował(a) ten post dnia 15.05.12 o godzinie 22:06