On Dec 16, 4:24 pm, Andrzej Jarzabek <a...@g...com>
wrote:
> On Dec 16, 12:22 am, A.L. <l...@a...com> wrote:
>
>
>
>
>
>
>
>
>
> > On Sat, 10 Dec 2011 23:36:51 +0000, Andrzej Jarzabek
>
> > <a...@g...com> wrote:
> > >On 10/12/2011 22:24, Roman W wrote:
> > >> On Dec 10, 9:34 pm, Andrzej Jarzabek<a...@g...com>
>
> > >>> Jest trochę taki problem, że jak dokumentacja opisuje rzeczy niezgodne z
> > >>> faktyczną rzeczywistością, to się na niej czas traci dwa razy: raz, jak
> > >>> się ją pisze, drugi raz, jak się próbuje z niej skorzystać.
>
> > >> Z regulay mozna wyodrebnic "rdzen" funkcjonalnosci, ktory sie raczej
> > >> nie zmieni, i przynajmniej ten udokumentowac.
>
> > >Niewątpliwie, jednak nie zawsze to jest potrzebne.
>
> > >Oczywiście, że wiele rzeczy dokumentować trzeba. Dla produktu musi
> > >powstać dokumentacja dla użytkownika końcowego, biblioteki czy inne
> > >komponenty powinny mieć udokumentowane API, a wszystkie decyzje,
> > >ustalenia i wnioski dotyczące funkcjonalności powinny być dokumentowane
> > >na bieżąco. I przecież w Agile się tego nie kwestionuje. Przede
> > >wszystkim odrzuca się tworzenie dokumentów, na podstawwie których
> > >tworzony jest program: dokumentacji wymagań i "dokumentu projektowego"
> > >czyli opisania całości struktury i jednostek kodu przed rozpoczęciem
> > >implementacji. W dalszej kolejności odrzuca się w ogóle potrzebę
> > >utrzymywania dokumentacji projektu kodu, nawet jeśli nie jest tworzony z
> > >góry.
>
> > Zwlaszcza dobrze sie to sprawdza przy pisaniu oprogramowania do
> > sterowania statecznikami poziomymi samolotu F-16, albo zeby byc blizej
> > ziemii, sterowania kolumna destylacyjna w Pertochemii Plockiej. Dobrze
> > tez taka metode zatosowac przy pisaniu oprogramwoania stuerujacego
> > kompresorami gazociagu magistralnego Jaroslaw-Wloclawek. Nie mowiac o
> > zwyklym, prostym komputerku sterujacym silnikiem samochodowym
>
> Być może, nie mam żadnych danych na ten temat.
>
> > Cale wasze doswiadczenie, Panowie, pochodzi z "pierdykniecia bazki
> > danych szlauchow i kaloszy dla Miejskiego Przedsiebiorstwa
> > Kanalizacyjnego". Software bywa ze obsluguje inne problemy tez. Duzo
> > bardziej skomplikowane. I takie ze jak sie pusci buga, to cos moze
> > wybuchnac albo ktos moze zostac zabity
>
> No też dlatego w wielu metodologiach agile stosuje się skuteczne
> metody redukcji ilości bugów - znacznie bardziej skuteczne, niż
> dokumentacja. Bo jeśli dokumentacja opisuje takie zachowanie programu,
> przy którym nic nie wybucha i nikogo nie zabija, a sam program
> zachowuje się inaczej, i w związku z tym wybucha i zabija, to dla
> zabitych jednak jest niewielką pociechą, że w dokumencie było wszystko
> OK.

To moze opisz zastosowanie metody Agile do oprogramowania, dla
przykladu, sterujacego respiratorem na OIOM.

RW