🚀 go-pugleaf

On Wed, 01 Mar 2006 13:26:25 +0100, mgl <ask@for.email.com> wrote:

><quote>
>Newsgroups: comp.software-eng
>Subject: Waterfall 2006 Conference -- April 1, 2006 -- Niagara Falls, NY
>
>After years of being disparaged by some in the software development
>community, the waterfall process is back with a vengeance. You've always
>known a good waterfall-based process is the right way to develop 
>software projects. Come to the Waterfall 2006 conference and see how a 
>sequential development process can benefit your next project. Learn how 
>slow, deliberate handoffs (with signatures!) between groups can slow the 
>rate of change on any project so that development teams have more time 
>to spend on anticipating user needs through big, upfront design.
>
>http://waterfall2006.com/
></quote>
>
>... bo w dobie dyskusji miedzy zwolennikami metodyk wagi RUP (USDP) a 
>fanami agile (a tak po prawdzie juz nawet nie dyskusji, co pewnego 
>kompromisu) stwierdzenie "waterfall process is back with a vengeance" 
>jest dosc ko(s)miczne, ale... lektura serwisu owej konferencji rozwiewa 
>te najczarniejsze sny ;).

Proces "Waterfall" ma sie dobrze i ejst powszechnie stosowany. W
mojej firmie na przyklad. W innej firmie ktora znam. Znacznie
czesciej niz nowoczesne "metodologie" w rodzaju XP. Spiesze dodac,
ze i technika obiektowa nei zawsze i nie wszedziesie sie sprawdza.

A.L.

A..L. wrote:
> Proces "Waterfall" ma sie dobrze i ejst powszechnie stosowany. W
> mojej firmie na przyklad. W innej firmie ktora znam. Znacznie
> czesciej niz nowoczesne "metodologie" w rodzaju XP.

A jak duże (w sensie choćby czasu realizacji w osobolatach) projekty 
realizujecie w metodyce kaskadowej?
I jeśli to projekty o charakterze biznesowym - jak radzicie sobie ze 
zmianą wymagań?
I żadnych iteracji, ani trochę, nic a nic? :)

Jeśli, jak przypuszczam, chodzi o budowanie podsystemów realizujących 
pewne algorytmy machine learning to waterfall na pewno da radę... ale w 
przypadku typowych systemów biznesowych brak iteracji to jak kupowanie 
jednych butów na całe życie.

> Spiesze dodac,
> ze i technika obiektowa nei zawsze i nie wszedziesie sie sprawdza.

Oczywiście.

pozdrawiam,
-- 
mgl

On Wed, 01 Mar 2006 15:38:37 +0100, mgl <ask@for.email.com> wrote:

>A..L. wrote:
>> Proces "Waterfall" ma sie dobrze i ejst powszechnie stosowany. W
>> mojej firmie na przyklad. W innej firmie ktora znam. Znacznie
>> czesciej niz nowoczesne "metodologie" w rodzaju XP.
>
>A jak du¿e (w sensie choæby czasu realizacji w osobolatach) projekty 
>realizujecie w metodyce kaskadowej?

Ostatni projekt (w trakcie) 50 osobolat. Tego sie nie da zrobic "na
ura".

>I je¶li to projekty o charakterze biznesowym - jak radzicie sobie ze 
>zmian± wymagañ?

Kontaktujemy sie z Legal Department, ustalamy koszt zmian i czas
niezbedny, Legal  Department pisze rozszerzenie do kontraktu i
negocjuje z klientem, a jak wynegocjuje to wtedy sie robi zmiany.

>I ¿adnych iteracji, ani trochê, nic a nic? :)
>

Jak wyzej.

>Je¶li, jak przypuszczam, chodzi o budowanie podsystemów realizuj±cych 
>pewne algorytmy machine learning to waterfall na pewno da radê... ale w 
>przypadku typowych systemów biznesowych brak iteracji to jak kupowanie 
>jednych butów na ca³e ¿ycie.
>

Ze niby jak z tymi butami?..

A.L.

Dnia Wed, 01 Mar 2006 08:25:32 -0600, A..L. skrobie:

> Proces "Waterfall" ma sie dobrze i ejst powszechnie stosowany.

W to nie wątpię.

W wychwalaniu vattenfalla nie należy też zapominać, że częściej jest
obchodzony, niż stosowany.

> W mojej firmie na przyklad. W innej firmie ktora znam. Znacznie
> czesciej niz nowoczesne "metodologie" w rodzaju XP.

To się również jak najbardziej zgadza.

Opracowany przez firmę proces ulepszania procesu należy do jeszcze większych
rzadkości, niż wspomniane "nowoczesne metodologie". Bynajmniej nie świadczy to
o tym, że vattenfall jest najlepszym wzorcem procesu. O czymś zupełnie innym,
co też zresztą parę lat temu byłeś pan wyśmiewałeś na tej właśnie grupie.

> Spiesze dodac,
> ze i technika obiektowa nei zawsze i nie wszedziesie sie sprawdza.

Nie wiem, którą miałeś pan na myśli.

Jeśli XP, to się oczywiście zgodzę ;P

Jeśli vattenfall, to w sumie również się zgodzę: socjalizm w sumie też nie
zawsze i nie wszędzie się sprawdza.

-- 
//  _    ___         Michal "Sektor" Malecki <sektor(whirl)kis.p.lodz.pl>
\\ L_ |/ `|  /^\ ,()                         <ethourhs(O)gmail.com>
// \_ |\  \/ \_/ /\ C++ bez cholesterolu: http://www.intercon.pl/~sektor/cbx
"I am allergic to Java because programming in Java reminds me casting spells"

Sektor van Skijlen <ethouris@guess.if.gmail.com.is.valid.or.invalid>
writes:

> Dnia Wed, 01 Mar 2006 08:25:32 -0600, A..L. skrobie:
>
>> Proces "Waterfall" ma sie dobrze i ejst powszechnie stosowany.
>
> W to nie wątpię.
>
> W wychwalaniu vattenfalla nie należy też zapominać, że częściej jest
> obchodzony, niż stosowany.

Waterfall wyklucza zrównoleglenie prac.  W sumie najlepszy model to
ten, który dobry menedżer zaprojektuje do konkretnego przedsięwzięcia.
Jak mawia mój obecny szef, 'jak coś jest do wszystkiego, to jest 
do niczego'.

-- 
http://www.piotr.dembiński.prv.pl

AL. wrote:
> Kontaktujemy sie z Legal Department, ustalamy koszt zmian i czas
> niezbedny, Legal  Department pisze rozszerzenie do kontraktu i
> negocjuje z klientem, a jak wynegocjuje to wtedy sie robi zmiany.

Nie cofacie sie wtedy do projektowania?

Testy przeprowadzacie na samiutkim koncu?

Czyli na przykład: przez rok projektujecie, następnie przez pół roku 
implementujecie, a potem przez drugie tyle testujecie? Żadnych testów 
podczas tego półrocznego okresu implementacji? Jak sprawdzacie podczas 
implementacji danego use case, że macie już wszystko i to działa?

Tak się dopytuję, bo sam znam kilka naprawdę sporych firm (korporacji), 
które wytwarzają oprogramowanie w taki sposób. Ale sami dostrzegają, że 
nie jest to metoda, która nie rodzi problemów.

> Ze niby jak z tymi butami?..

Ciasne.

pozdrawiam,
-- 
mgl

Piotr Dembiński wrote:
> Jak mawia mój obecny szef, 'jak coś jest do wszystkiego, to jest 
> do niczego'.

Oryginalne motto ;)

-- 
mgl

On Wed, 01 Mar 2006 20:28:19 +0100, pdemb@gazeta.pl (Piotr Dembiñski)
wrote:

>
>Waterfall wyklucza zrównoleglenie prac.  

Za co?...

A.L.

On Wed, 01 Mar 2006 20:52:38 +0100, mgl <ask@for.email.com> wrote:

>AL. wrote:
>> Kontaktujemy sie z Legal Department, ustalamy koszt zmian i czas
>> niezbedny, Legal  Department pisze rozszerzenie do kontraktu i
>> negocjuje z klientem, a jak wynegocjuje to wtedy sie robi zmiany.
>
>Nie cofacie sie wtedy do projektowania?
>

Cofamy. Ale to sie zdarza rzadko.

>Testy przeprowadzacie na samiutkim koncu?
>

A gdzie jest powiedziane ze w metodologii "waterfall" testowanie
tzreba robic na koncu? No, a poza tym sa rozne rodzaje testowania: na
przyklad integration testing nie da sie zrobic nie majac gotowych
modulow. I kto broni programistom robic unit testing? Actually, wymaga
sie tego od nich.

>Czyli na przyk³ad: przez rok projektujecie, nastêpnie przez pó³ roku 
>implementujecie, a potem przez drugie tyle testujecie? ¯adnych testów 
>podczas tego pó³rocznego okresu implementacji? Jak sprawdzacie podczas 
>implementacji danego use case, ¿e macie ju¿ wszystko i to dzia³a?
>

Widze za Kolega ma jaies nieswieze informacje na temat "waterfall".
Kazdy duzy problem sie dekomponuje na mniejsze, ta dekompozycja jest
czescia projektu. Ale ogolnie, tak, nie kodujemy nie majac projektu. A
sprawdzamy metoda badania zgodnosci z dokumentacja i przy pomocy
testow.

Projekt 50 osobo-letni nie wykonuje sie 5 osobami przez 10 lat ani 50
osobami przez rok. Trwa on okolo 3 lat. W tym czasie czesc zepolu moze
sie zmienic, ludzie odchodza z parcy, przychodza nowi. Poszczegolne
kawalki musza do siebie pasowac, tak aby mogly wymieniac informacje i
kontrolowac sie nawzajem. Jak cos takiego mozna zrobic przy pomocy
metodologii "na ura" ktora zaklada ze dokumenatcja to strata czasu bo
kod sie sam dokumentuje a projektowanie to zawracanie glowy?..

>Tak siê dopytujê, bo sam znam kilka naprawdê sporych firm (korporacji), 
>które wytwarzaj± oprogramowanie w taki sposób. Ale sami dostrzegaj±, ¿e 
>nie jest to metoda, która nie rodzi problemów.

Nie znam metody ktora nie rodzi problemow.

A.L>

AL. wrote:
> A gdzie jest powiedziane ze w metodologii "waterfall" testowanie
> tzreba robic na koncu? No, a poza tym sa rozne rodzaje testowania: na
> przyklad integration testing nie da sie zrobic nie majac gotowych
> modulow. I kto broni programistom robic unit testing? Actually, wymaga
> sie tego od nich.

Zakładam, że mówimy o oryginalnym procesie proponowanym przez Royce'a:
http://en.wikipedia.org/wiki/Waterfall_model

> Widze za Kolega ma jaies nieswieze informacje na temat "waterfall".
> Kazdy duzy problem sie dekomponuje na mniejsze, ta dekompozycja jest
> czescia projektu. Ale ogolnie, tak, nie kodujemy nie majac projektu. A
> sprawdzamy metoda badania zgodnosci z dokumentacja i przy pomocy
> testow.

Sęk tylko w tym, że dekompozycja w waterfall dotyczy tylko bieżącej 
fazy. Konkurencja (konkurencyjne metodyki) bardzo chętnie projektuje 
system na pewnym poziomie ogólności, następnie iteracyjnie projektuje 
szczegóły, implementuje, testuje i integruje kolejne szczegóły 
(przypadki użycia tworzące podsystemy).

> Projekt 50 osobo-letni nie wykonuje sie 5 osobami przez 10 lat ani 50
> osobami przez rok. Trwa on okolo 3 lat. W tym czasie czesc zepolu moze
> sie zmienic, ludzie odchodza z parcy, przychodza nowi. Poszczegolne
> kawalki musza do siebie pasowac, tak aby mogly wymieniac informacje i
> kontrolowac sie nawzajem. Jak cos takiego mozna zrobic przy pomocy
> metodologii "na ura" ktora zaklada ze dokumenatcja to strata czasu bo
> kod sie sam dokumentuje a projektowanie to zawracanie glowy?..

Całkowita zgoda!
Chciałbym tylko wyjaśnić dwie sprawy.

Nie pisałem, ani nie sugerowałem żadnych rozwiązań pokroju "na hura". 
Czy metodyki inne niż waterfall to procesy "na hura"? No przecież nie.

Rozumiem, że pije Pan do metodyk agile. Sam nie jestem bezrefleksyjnym 
fanem agile (choćby w XP programowanie w parach bywa takie sobie i musi 
być naprawdę bardzo dobrze uzasadnione potrzebą, skręca mnie też na sam 
dźwięk nieuzasadnionych zachwytów nad "continuous design"), ale metodyki 
agile, w ogólności, nie zakładają braku projektu szkieletu systemu czy 
prowadzenia dokumentacji. I w przypadku projektów o charakterze R&D czy 
wymagających klientów, których potrzeby są trudne do określenia podczas 
wstępnej analizy wymagań, na pewno się sprawdzają.

> Nie znam metody ktora nie rodzi problemow.

Największe wady oryginalnego waterfall, które wykluczają go całkowicie z 
pewnych zastosowań, to brak iteracji i bardzo mała odporność na częste 
zmiany wymagań. Wprowadzenie do niego chociażby unit testing czy 
stopniowej, krokowej integracji zmienia już sztywny proces kaskadowy w 
iteracyjny. Co tylko na dobre mu wychodzi.

pozdrawiam,
-- 
mgl

""Piotr Dembiński"" <pdemb@gazeta.pl> wrote in message 
news:878xrux8vg.fsf@hector.domek...
> Waterfall wyklucza zrównoleglenie prac.

W firmie w ktorej pracuje waterfall jest czesto uzywany bo pozwala 
zaoszczedzic czas i pieniadze wlasnie poprzez zrownoleglenie prac.

pzdr
Muchomor 

mgl wrote:
> fazy. Konkurencja (konkurencyjne metodyki) bardzo chętnie projektuje 
> system na pewnym poziomie ogólności, następnie iteracyjnie projektuje 
> szczegóły, implementuje, testuje i integruje kolejne szczegóły 
> (przypadki użycia tworzące podsystemy).

Oczywiście miało być: "Konkurencja (konkurencyjne metodyki) bardzo 
chętnie projektuje system na pewnym poziomie ogólności, następnie 
iteracyjnie projektuje, implementuje, testuje i integruje kolejne 
szczegóły... ".

-- 
mgl

Muchomor wrote:
> W firmie w ktorej pracuje waterfall jest czesto uzywany bo pozwala 
> zaoszczedzic czas i pieniadze wlasnie poprzez zrownoleglenie prac.

Ale to chyba nie zasługa modelu kaskadowego - nie znam żadnego poważnego 
procesu wytwarzania oprogramowania, który uniemożliwiałby podział prac. 
Ograniczenia mogą wynikać już z charakteru projektu. Ale z modelu??

pozdrawiam,
-- 
mgl

"mgl" <ask@for.email.com> wrote in message 
news:du530o$2r8$3@news.dialog.net.pl...
> Muchomor wrote:
>> W firmie w ktorej pracuje waterfall jest czesto uzywany bo pozwala 
>> zaoszczedzic czas i pieniadze wlasnie poprzez zrownoleglenie prac.
>
> Ale to chyba nie zasługa modelu kaskadowego

nie, nie, oczywiscie, ze nie :)
Chcialem po prostu skontrowac teze, ze "waterfall wyklucza zrownoleglenie 
prac". Szczegolnie prac developmentu i testerow. Rzecz jasna, ze waterfall 
nie jest tu jakims specjalnym wyjatkiem.

pzdr
Muchomor 

Dnia Wed, 01 Mar 2006 20:28:19 +0100, Piotr Dembiński skrobie:
> Sektor van Skijlen <ethouris@guess.if.gmail.com.is.valid.or.invalid>
> writes:

> > Dnia Wed, 01 Mar 2006 08:25:32 -0600, A..L. skrobie:
> >
> >> Proces "Waterfall" ma sie dobrze i ejst powszechnie stosowany.
> >
> > W to nie wątpię.
> >
> > W wychwalaniu vattenfalla nie należy też zapominać, że częściej jest
> > obchodzony, niż stosowany.

> Waterfall wyklucza zrównoleglenie prac.

Zrównoleglenie prac to przede wszystkim wykluczają zależności poszczególnych
czynności wykonywanych w projekcie.

Zatem to, ile uda nam się zrównoleglić, zależy od tego, jak wyglądają
zależności poszczególnych czynności. Można oczywiście zmniejszać zależności,
ale to może przy braku dobrej ekspertyzy prowadzić to powiększania "rozkurzu"
(czynności, których efekty bezpośrednie pójdą do kosza).

Jeśli np. założymy, że musimy miec w całości wykonany projekt i dopiero
zabieramy się za implementację (mówię o projekcie wysokiego, a nie niskiego
poziomu, oczywiście), to tych czynności zrównoleglić, jak wiadomo, nie można,
ale to właśnie z uwagi na zależności. Natomiast nikt nam nie każe robić
projektu implementacji jako konkretnego etapu. Takie coś może być robione np.
poprzez komentarze doxygenowe lub projektowanie schematyczne z generacją kodu.
Wtedy kod istnieje równolegle z dokumentacją.

Podobnie, tworzenie implementacji nawet jednego modułu, czy obszaru
funkcjonalnego można skutecznie rozłożyć na kilka osób, jeśli jest się w
stanie wyznaczyć rozkład zależności. Jeśli ktoś tego nie potrafi wyznaczyć, no
to trudno - sadzamy jednego człowieka, który sam to wszystko pisze. Jeśli
potrafimy, to wtedy jeden gościu pisze tylko krótki plik z interfejsem, i
spokojnie dwóch ludzi może pisać oddzielnie kod z tego samego obszaru
funkcjonalnego, tylko po prostu inne fragmenty kodu.

Taki projekcik zresztą prowadziłem ostatnio osobiście. Problem był
następujący: na otrzymane żądanie od odpowiedniego "serwera", zapytać wskazane
urządzenie o liczbę używanych obiektów i ich konfigurację, po czym wysłać je
z powrotem do serwera. Ja pisałem część związaną z odebraniem żądania i
wysłaniem wyników, a kolega pisał część związaną z wysłaniem żądania do
urządzenia i odebrania odpowiedzi (kod na drugim urządzeniu to już pisał
gościu zza bajora i woleliśmy na niego poczekać z uwagi na tzw. problemy
komunikacyjne i czasostrefowe) i przekazania mi jej. Określiliśmy tylko
interfejs tej funkcji, która miała się tym zajmować, oraz używane struktury. I
tyle było naszego "pair programming"; potem ja pisałem otoczkę, odebranie
danych i ich sformatowanie, a on implementację. Interfejs oczywiście się
zmieniał (klient trzykrotnie zmieniał wymagania w międzyczasie, albo o
niektórych sprawach nie pomyśleliśmy) - nie stanowiło to problemu; dzwonię do
gościa i mówię: potrzebna jest taka-a-taka zmiana w interfejsie. Potem szybka
synchronizacja, znów 5 minut na "pair programming" i spowrotem split.
Projekcik trwał raptem trzy tygodnie a zmian w interfejsie było dokładnie 1.

Kwestia zastosowania vattenfall nie ma tu nic do rzeczy - pod warunkiem
oczywiście, że proces nie ma wpisane na sztywno np. tego, że do każdej
najdrobniejszej pierdoły (typu dodanie 10 linijek kodu) wymagany jest
"dizajn", a bez dizajnu nie ruszamy z miejsca, a po przebramkowaniu dizajnu
dizajn jest nietykalny aż do zakończenia przedsięwzięcia.

> W sumie najlepszy model to
> ten, który dobry menedżer zaprojektuje do konkretnego przedsięwzięcia.
> Jak mawia mój obecny szef, 'jak coś jest do wszystkiego, to jest 
> do niczego'.

Bardzo słusznie mówi.

Zarówno vattenfall, jak i ajil mogą być takimi "wzorcami procesów", z których
proces oficjalny może czerpać tyle, na ile uważa to za stosowne. Nie ma to jak
proces autorski. Ale żeby taki proces zrobić, trzeba się na jakimś wzorcowym
procesie oprzeć - a trzeba przyznać, vattenfall to jest jednak jedyny proces,
którego definicję można uważać za "stabilną" - a także trzeba mieć swój własny
"proces ulepszania procesu". Tzw. "Quality" powinno się zatem zajmować nie
tylko tym, czy proces jest dotrzymywany, ale również wszelkimi zgłoszeniami
opinii i wniosków nt. tego, jakie czynniki utrudniają wykonywanie czynności
związanych z danym projektem, co utrudnia ludziom pracę, jak można by to
ulepszyć. Proces nie jest kodeksem absolutnym, tak samo jak prawo nie jest
prawem absolutnym; jeśli jest złe, to trzeba je zmienić.

Problem w tym, że to wymaga wielu istotnych czynników: procesu ulepszania
procesu oraz posiadania pomysłowych i "twórczo-leniwych" ludzi w zespole.
Proces ulepszania procesu nie jest trudny do napisania, tylko trzeba chcieć to
zrobić, a ludzi "twórczo-leniwych" wcale nie jest mało, tylko trzeba chcieć
ich słuchać. Z tą chęcią jest niestety zwykle mizernie.


-- 
//  _    ___         Michal "Sektor" Malecki <sektor(whirl)kis.p.lodz.pl>
\\ L_ |/ `|  /^\ ,()                         <ethourhs(O)gmail.com>
// \_ |\  \/ \_/ /\ C++ bez cholesterolu: http://www.intercon.pl/~sektor/cbx
"I am allergic to Java because programming in Java reminds me casting spells"

On Wed, 01 Mar 2006 22:11:17 +0100, mgl <ask@for.email.com> wrote:
 
>
>Największe wady oryginalnego waterfall, które wykluczają go całkowicie z 
>pewnych zastosowań, to brak iteracji i bardzo mała odporność na częste 
>zmiany wymagań. Wprowadzenie do niego chociażby unit testing czy 
>stopniowej, krokowej integracji zmienia już sztywny proces kaskadowy w 
>iteracyjny. Co tylko na dobre mu wychodzi.

"This is not your grandfather waterfall". Czy mysli Kolega ze od
czasoe "oryginalnego" waterfall nic sie nie zmienilo?...

A.L.

A..L. wrote:

> "This is not your grandfather waterfall". Czy mysli Kolega ze od
> czasoe "oryginalnego" waterfall nic sie nie zmienilo?...

Raczej wydaje mi się, że to, o czym Kolega pisze, bardziej przypomina 
RUP, którego nie można nazwać waterfall, niż model kaskadowy. Zresztą to 
dobrze. Nie ma tego złego, co by... ;)

pozdrawiam,
-- 
mgl

Sektor van Skijlen <ethouris@guess.if.gmail.com.is.valid.or.invalid> writes:

[...]

>> Waterfall wyklucza zrównoleglenie prac.
>
> Zrównoleglenie prac to przede wszystkim wykluczają zależności
> poszczególnych czynności wykonywanych w projekcie.

Czysty waterfall zakłada określoną sekwencję: analiza -> projektowanie -> 
implementacja -> testowanie -> wdrożenie.  Dla całego przedsięwzięcia.  
Czyli masz nie tylko ograniczenia kolejnościowe samych zadań, ale również
ograniczenia samego modelu.  Chyba że czegoś nie rozumiem.

-- 
http://www.piotr.dembiński.prv.pl

mgl <ask@for.email.com> writes:

[...]

> Tak się dopytuję, bo sam znam kilka naprawdę sporych firm
> (korporacji), które wytwarzają oprogramowanie w taki sposób. 
> Ale sami dostrzegają, że nie jest to metoda, która nie rodzi 
> problemów.

Jeśli już chce się wytwarzać w 'kostyczny' sposób, to lepiej chyba
podpatrzyć jeden z wojskowych modeli dokumentocentrycznych.

AL. <alewando@ziuta66.com> writes:

[...]

> Projekt 50 osobo-letni nie wykonuje sie 5 osobami przez 10 lat 
> ani 50 osobami przez rok. Trwa on okolo 3 lat. W tym czasie czesc 
> zepolu moze sie zmienic, ludzie odchodza z parcy, przychodza
> nowi. Poszczegolne kawalki musza do siebie pasowac, tak aby mogly
> wymieniac informacje i kontrolowac sie nawzajem. Jak cos takiego
> mozna zrobic przy pomocy metodologii "na ura" ktora zaklada 
> ze dokumenatcja to strata czasu bo kod sie sam dokumentuje 
> a projektowanie to zawracanie glowy?..

To całe 'ura' zaczęło się chyba w momencie wprowadzenia języków
programowania b. wysokiego poziomu, ale głowy nie dam :)

Dnia Wed, 01 Mar 2006 14:28:44 -0600, AL. skrobie:
> >Testy przeprowadzacie na samiutkim koncu?
> >

> A gdzie jest powiedziane ze w metodologii "waterfall" testowanie
> tzreba robic na koncu? No, a poza tym sa rozne rodzaje testowania: na
> przyklad integration testing nie da sie zrobic nie majac gotowych
> modulow. I kto broni programistom robic unit testing? Actually, wymaga
> sie tego od nich.

Może powiedzmy to sobie najpierw szczerze:
 - testowanie jednostkowe można przeprowadzić tylko mając zdefiniowane
   (niekoniecznie zaimplementowane) jednostki
 - projekt testów komponentowych można napisać NIE MAJĄC jeszcze ani odrobiny
   implementacji, a jedynie sam design
 - testowanie integracyjne wykonuje się tam, gdzie wymagana jest integracja

Co oznacza np., że nie ma żadnego problemu z równoległym definiowaniem testów
jednostkowych i komponentowych i pisaniem implementacji. Coś mi broni to pisać
wcześniej? A jeśli znam interfejs do pisanej funkcjonalności i mam jasno
określone, jak się do niego dobrać i jak sie nim posługiwać, czy coś mi broni
napisać od razu konkretnego kejsa, który się na tym opiera, zanim powstanie
implementacja?

Natomiast stwierdzenie, że "kto broni programistom robić unit testing", jest
co najmniej śmieszne. Testowanie jednostkowe jest oczywistym obowiązkiem
FORMALNYM, na straży którego ma stać kierownik techniczny projektu. I
kierownik odpowiada również za to, że istnieje formalnie udokumentowane
pokrycie w testach napisanej funkcjonalności, realizującej wskazane wymagania
(formalnie każdy kejs ma wskazane, na które elementy designu i wymagań jest
mapowany oraz jakie ma pokrycie).

Może i to miał pan na myśli, ale to pierwsze zdanie sprawia wrażenie, jakby
pan stwierdził, że "nie no, programiści mogą sobie pisać UT, jak potrzebują".

> >Czyli na przyk?ad: przez rok projektujecie, nast?pnie przez pó? roku 
> >implementujecie, a potem przez drugie tyle testujecie? ?adnych testów 
> >podczas tego pó?rocznego okresu implementacji? Jak sprawdzacie podczas 
> >implementacji danego use case, ?e macie ju? wszystko i to dzia?a?
> >

> Widze za Kolega ma jaies nieswieze informacje na temat "waterfall".
> Kazdy duzy problem sie dekomponuje na mniejsze, ta dekompozycja jest
> czescia projektu. Ale ogolnie, tak, nie kodujemy nie majac projektu. A
> sprawdzamy metoda badania zgodnosci z dokumentacja i przy pomocy
> testow.

Jak przepraszam sprawdzacie zgodność z dokumentacją? Bo o ile mnie wiadomo, to
zgodność z dokumentacją sprawdza się właśnie przy pomocy testów. Rozważać
można co najwyżej zgodność testów z dokumentacją.

> Projekt 50 osobo-letni nie wykonuje sie 5 osobami przez 10 lat ani 50
> osobami przez rok. Trwa on okolo 3 lat. W tym czasie czesc zepolu moze
> sie zmienic, ludzie odchodza z parcy, przychodza nowi. Poszczegolne
> kawalki musza do siebie pasowac, tak aby mogly wymieniac informacje i
> kontrolowac sie nawzajem. Jak cos takiego mozna zrobic przy pomocy
> metodologii "na ura" ktora zaklada ze dokumenatcja to strata czasu bo
> kod sie sam dokumentuje a projektowanie to zawracanie glowy?..

Ech...

Nie słyszałem o takiej metodologii, która zakłada, że dokumentacji nie pisze
się W OGÓLE. Projekt architektury (zwany też HLD) tworzy się w _każdej_
metodologii. Tyle że w przypadku Agile, jak wszystko zresztą, tworzy się to
odpowiednio w kolejnych iteracjach.

Pańskie komentarze nt. - jak zakładam - Agile i XP bardzo przypominają
wypowiedź Lema, jak stwierdził, że od fantastyki zamierza się trzymać z
daleka.

Natomiast projekt implementacji (zwany też LLD) to jest rzeczywiście strata
czasu. Takie coś powinno się tworzyć albo jako dokumentację "na żywca" (jeśli
jest projektowane diagramami z generacją kodu), albo dokumentację post-factum,
z zastosowaniem dokumentacji sterowanej w komentarzach (np. doxygen).

Dokumentacji jest bardzo wiele rodzajów. Pisanie ogólnie o dokumentacji i
komentowanie, czy ją robić, czy nie, to mniej więcej tak, jak rozważać, czy do
projektu powinniśmy wybrać język imperatywny, czy funkcjonalny.

> >Tak si? dopytuj?, bo sam znam kilka naprawd? sporych firm (korporacji), 
> >które wytwarzaj? oprogramowanie w taki sposób. Ale sami dostrzegaj?, ?e 
> >nie jest to metoda, która nie rodzi problemów.

> Nie znam metody ktora nie rodzi problemow.

Nic banalniejszego.

Pytanie tylko, która metoda rodzi ich najmniej. I prawda jest taka również, że
nie dowiemy się tego inaczej, jak poprzez wdrożenie procesu do konkretnego
projektu i wyciągnięcie odpowiednich wniosków. Niestety vattenfall rodzi wiele
problemów, których wystąpienia twórcy nawet nie przewidzieli.

I to są problemy znane i udokumentowane. Nie znam za to podobnej listy w
przypadku metod Agile. To, o czym pan najczęściej mówisz to jest opinia
pre-factum (jak choćby ocena pair-programming z punktu widzenia planowania
finansowego). Chętnie bym usłyszał od pana jakąś opinię o Agile, ale
post-factum. Taką, jaką ja mam po przeżyciu paru projektów prowadzonych metodą
spadającej wody.


-- 
//  _    ___         Michal "Sektor" Malecki <sektor(whirl)kis.p.lodz.pl>
\\ L_ |/ `|  /^\ ,()                         <ethourhs(O)gmail.com>
// \_ |\  \/ \_/ /\ C++ bez cholesterolu: http://www.intercon.pl/~sektor/cbx
"I am allergic to Java because programming in Java reminds me casting spells"

"Muchomor" <muchomor_w_kropkiCUT_THIS@gazeta.pl> writes:

> ""Piotr Dembiński"" <pdemb@gazeta.pl> wrote in message 
> news:878xrux8vg.fsf@hector.domek...
>> Waterfall wyklucza zrównoleglenie prac.
>
> W firmie w ktorej pracuje waterfall jest czesto uzywany bo pozwala
> zaoszczedzic czas i pieniadze wlasnie poprzez zrownoleglenie prac.

Czy to zastosowanie modelu wodospadowego pozwala na zrównoleglenie,
czy charakterystyka, a w szczególności ograniczenia kolejnościowe
zadań wykonywanego przedsięwzięcia?  Podejrzewam, że bardziej to
drugie, niż to pierwsze :)

-- 
http://www.piotr.dembiński.prv.pl

Dnia Wed, 01 Mar 2006 22:14:50 +0100, mgl skrobie:
> mgl wrote:
> > fazy. Konkurencja (konkurencyjne metodyki) bardzo chętnie projektuje 
> > system na pewnym poziomie ogólności, następnie iteracyjnie projektuje 
> > szczegóły, implementuje, testuje i integruje kolejne szczegóły 
> > (przypadki użycia tworzące podsystemy).

> Oczywiście miało być: "Konkurencja (konkurencyjne metodyki) bardzo 
> chętnie projektuje system na pewnym poziomie ogólności, następnie 
> iteracyjnie projektuje, implementuje, testuje i integruje kolejne 
> szczegóły... ".

Kolego, mała lekcja angielskiego z zagadnieniem "słówka podchwytliwe" by ci
się przydała.

Kilka drobnych podpowiedzi:

actually = tak naprawdę
competition = konkurencja
concurrency = współbieżność
eventually = w końcu/wreszcie
pathetic = żałosny
recurrent = powtarzalny
recursion = rekurencja
sympathy = współczucie

Te pisałem z pamięci, pewnie kilka ciekawszych też by się znalazło :)

Odnosząc się do podanego fragmentu, oczywiście konkurencja bardzo chętnie
zaprojektuje taki system szybciej od ciebie i zgarnie za ciebie kasę :)


-- 
//  _    ___         Michal "Sektor" Malecki <sektor(whirl)kis.p.lodz.pl>
\\ L_ |/ `|  /^\ ,()                         <ethourhs(O)gmail.com>
// \_ |\  \/ \_/ /\ C++ bez cholesterolu: http://www.intercon.pl/~sektor/cbx
"I am allergic to Java because programming in Java reminds me casting spells"

Sektor van Skijlen wrote:
> Kolego, mała lekcja angielskiego z zagadnieniem "słówka podchwytliwe" by ci
> się przydała.

Polecam poskromienie wątpliwej błyskotliwości, zajrzenie na:
http://sjp.pwn.pl/haslo.php?id=25289
http://sjp.pwn.pl/haslo.php?id=25291
i zapoznanie się ze znaczeniem słowa "konkurencja" i "konkurencyjny".

No chyba, że to taki cienki żarcik, a ja taki niekumaty.

> Odnosząc się do podanego fragmentu, oczywiście konkurencja bardzo chętnie
> zaprojektuje taki system szybciej od ciebie i zgarnie za ciebie kasę :)

A odejdź ode mnie. I nie denerwuj.

-- 
mgl

""Piotr Dembiński"" <pdemb@gazeta.pl> wrote in message 
news:8764mxwzv5.fsf@hector.domek...
> "Muchomor" <muchomor_w_kropkiCUT_THIS@gazeta.pl> writes:
>
>> ""Piotr Dembiński"" <pdemb@gazeta.pl> wrote in message
>> news:878xrux8vg.fsf@hector.domek...
>>> Waterfall wyklucza zrównoleglenie prac.
>>
>> W firmie w ktorej pracuje waterfall jest czesto uzywany bo pozwala
>> zaoszczedzic czas i pieniadze wlasnie poprzez zrownoleglenie prac.
>
> Czy to zastosowanie modelu wodospadowego pozwala na zrównoleglenie,
> czy charakterystyka, a w szczególności ograniczenia kolejnościowe
> zadań wykonywanego przedsięwzięcia?  Podejrzewam, że bardziej to
> drugie, niż to pierwsze :)

Nie zrozumiales. Zrownoleglic prace nad kolejnymi etapami (w pewnym stopiniu 
oczywiscie) mozna pewnie w kazdym modelu. Rowniez w waterfall'u. Napisales, 
ze "Waterfall wyklucza zrównoleglenie prac", to ja Ci napisalem, ze sie 
mylisz. Mam za soba kilka duzych projektow w waterfallu, kazdy z zupelnie 
inna specyfika. Po skonczeniu analizy wymagan mozna zrownoleglic pisanie 
designu poszczegolnych aplikacji (funkcjonalnosci) i pisanie planu testow 
integracyjnych + zaczac pisac testy integracyjne. W momencie ustalenia 
interfejsow jakimi komunikuja sie miedzy soba aplikacje (moduly) mozna 
zaczac pisac testy komponentowe, unit testy itp. W czasie designu mozna 
pisac interfejsy klas badz generowac je z modeli UML itd, itp. Przyklad z 
zycia - projekt w C++ na platforme gdzie jedyny kompilator nie wspiera STL. 
Z bardzo wysokiego designu wynika, ze STL by sie przydal. Zatem rownolegle z 
designem jeden zawodnik pisze cos co bedzie dzialac jak kilka wybranych 
szablonow.
Wszystkie rownolegle sciezki koncza sie w jednym punkcie zwanym integracja. 
Nigdy nie ma tak, ze efekty prac w poszczegolnych fazach sa nie do ruszenia 
w fazach kolejnych. Dzieje sie tak z powodu zmiennych wymagan, defektow, 
badz po prostu wymyslenia lepszych rozwiazan. Z tego powodu mozna sobie 
pozwolic na _rozsadne_ zrownoleglanie prac.
Mam wrazenie, ze tworzenie software'u znane jest Ci raczej z ksiazek (lekko 
zakurzonych) lub akademickich rozwazan niz z zycia. Mam tu na mysli projekty 
liczone w setkach badz tysiacach staffmonths gdzie 80% kolegow z zespolu 
nigdy nie zobaczysz na oczy.

pzdr
Muchomor

On Wed, 1 Mar 2006 22:38:30 +0000 (UTC), Sektor van Skijlen
<ethouris@guess.if.gmail.com.is.valid.or.invalid> wrote:
 
>
>I to s± problemy znane i udokumentowane. Nie znam za to podobnej listy w
>przypadku metod Agile. To, o czym pan najczê¶ciej mówisz to jest opinia
>pre-factum (jak choæby ocena pair-programming z punktu widzenia planowania
>finansowego). 

.. i tak dalej, wyciete.

Nie chce mi sie. Szkoda czasu. Mojego. Oczywiscie, "pair programming"
jest lepsze. I tansze. W Panskiej wyobrazni. 

Podejrzewam ze Pana rzeczywisctos i moa rzeczywistosc to zupelnie dwie
rozne rzeczywistosci. Wiec oszczedze sobie czasu i fatygi moim palcom.

A.L.

Dnia Wed, 01 Mar 2006 17:30:08 -0600, AL. skrobie:
> On Wed, 1 Mar 2006 22:38:30 +0000 (UTC), Sektor van Skijlen
> <ethouris@guess.if.gmail.com.is.valid.or.invalid> wrote:
>  
> >
> >I to s? problemy znane i udokumentowane. Nie znam za to podobnej listy w
> >przypadku metod Agile. To, o czym pan najcz??ciej mówisz to jest opinia
> >pre-factum (jak cho?by ocena pair-programming z punktu widzenia planowania
> >finansowego). 

> .. i tak dalej, wyciete.

> Nie chce mi sie. Szkoda czasu. Mojego.

Tak, oczywiście, bo na prezentację swojch własnych jedynie słusznych poglądów
masz pan mnóstwo czasu, co widać po aktywności.

A na rzeczową dyskusję zawsze go panu brakuje.

Aha, do mojego słownika zapomniałem jeszcze dodać angielski odpowiednik słowa
"naruszenie" (nie w znaczeniu "naruszenie zasad", tylko "naruszenie ochrony",
o czym zresztą większość twórców słowników nie ma zielonego pojęcia).

> Oczywiscie, "pair programming"
> jest lepsze. I tansze. W Panskiej wyobrazni. 

I oczywiście pan znów nie zrozumiał, o czym piszę, ale tak to już z panem
jest, że najpierw pan piszesz, potem pan myślisz. Tzn. tego potem nie jestem
już taki pewien anyway.

Po raz kolejny dowodzisz pan, że nie masz pan zielonego pojęcia ani o tym,
na czym pair programming w rzeczywistości polega (i co zastępuje w procesie
waterfall), ani dlaczego pair programming ma poważne wady. Nie, nie z przyczyn
finansowych. Z zupełnie innych przyczyn, których pan zdajesz się nie
dostrzegać. To są wady typowo PROCESOWE.

> Podejrzewam ze Pana rzeczywisctos i moa rzeczywistosc to zupelnie dwie
> rozne rzeczywistosci.

Zgadza się. Różnica polega na tym, że wg mnie proces powinien być dopasowany
do projektu i ulepszany na bieżąco.

Pan uważasz, że waterfall jest cacy, a agile jest be. Taki jest właśnie pański
poziom wiedzy nt. SPP.


-- 
//  _    ___         Michal "Sektor" Malecki <sektor(whirl)kis.p.lodz.pl>
\\ L_ |/ `|  /^\ ,()                         <ethourhs(O)gmail.com>
// \_ |\  \/ \_/ /\ C++ bez cholesterolu: http://www.intercon.pl/~sektor/cbx
"I am allergic to Java because programming in Java reminds me casting spells"

Dnia Wed, 01 Mar 2006 23:27:21 +0100, Piotr Dembiński skrobie:
> Sektor van Skijlen <ethouris@guess.if.gmail.com.is.valid.or.invalid> writes:

> [...]

> >> Waterfall wyklucza zrównoleglenie prac.
> >
> > Zrównoleglenie prac to przede wszystkim wykluczają zależności
> > poszczególnych czynności wykonywanych w projekcie.

> Czysty waterfall zakłada określoną sekwencję: analiza -> projektowanie -> 
> implementacja -> testowanie -> wdrożenie.  Dla całego przedsięwzięcia.  
> Czyli masz nie tylko ograniczenia kolejnościowe samych zadań, ale również
> ograniczenia samego modelu.  Chyba że czegoś nie rozumiem.

Tak, to się zgadza. Co więcej, pomiędzy poszczególnymi etapami są bramki
jakości: jak jakość nie jest zadowalająca, to nie przechodzimy do następnego
etapu. Jak przejdziemy do następnego etapu, to już się nie cofamy. Cofnięcie
się (jeśli się okaże konieczne) jest określane jako defekt.

Można oczywiście rozkładać całość przedsięwzięcia na mniejsze i nazywać to
dalej waterfallem.

Można również zrównoleglić odpowiednie czynności mając w dupie bramki jakości.
Ach to "dalsze doskonalenie".

Można, wreszcie, wprowadzić iteracyjność, czyli - w odróżnieniu od podziału
wzdłuż, jak wyżej - wprowadzić podział w poprzek. Oczywiście nikt tu już nie
ma wątpliwości, że to Agile coraz bardziej nadgryza nam ten wodospad.

Można jeszcze dodatkowo wprowadzić zorganizowany refactoring jako oddzielne
pod-przedsięwzięcie wykonywane cyklicznie co któryś build.

Aha, no i oczywiście wprowadznienie pełnej automatyzacji testowania i częstych
integracji i buildów.

I z tego nam powstaje piękny Waterfall... z niewielką domieszką Agile.

Ziemkiewicz opisywał gdzieś, jak to bodajże Kim Ir Sen (albo któryś
wcześniejszy) wymyślił, żeby paszę dla drobiu robić z trawy. Naukowcy chcąc
nie chcąc eksperymenty przeprowadzili i w końcu wyprodukowali paszę z trawy...
z niewielką domieszką ekstraktu zbożowego.

Może darujmy sobie tą hipokryzję i ustalmy jasno, że Waterfall albo się
przeżył, albo z pierwotnym waterfallem wspólną ma tylko nazwę, jeśli ma tak
właśnie wyglądać.

A jeśli jest to proces autorski, może nawet bazowany na waterfallu, ale
jednak z odpowiednimi elementami agile i również rozwiązaniami własnymi, które
naprawiają wady procesów wzorcowych, to nie nazywajmy tego waterfallem.


-- 
//  _    ___         Michal "Sektor" Malecki <sektor(whirl)kis.p.lodz.pl>
\\ L_ |/ `|  /^\ ,()                         <ethourhs(O)gmail.com>
// \_ |\  \/ \_/ /\ C++ bez cholesterolu: http://www.intercon.pl/~sektor/cbx
"I am allergic to Java because programming in Java reminds me casting spells"