On 15/01/2013 22:28, Gotfryd Smolik news wrote:
> Ja tak z pozoru offtopicznie:
>
> On Thu, 27 Dec 2012, boryspower wrote:
>
>> Przykład: Stworzenie aplikacji do fakturowania
>
> 1. Przeczytać ustawę o VAT i stwierdzić że nic się z tego nie rozumie
> 2. Spytać "fachowca" jak ma być
> 3. Stwierdzić że coś nie pasuje
> 4. Sprawdzić to i owo w internecie
> 5. powtórzyć 1. i stwierdzić że "fachowiec" był niedouczony ;)

Oczywiście może się tak zdarzyć, ale w takiej sytuacji błąd był
wcześniej, już na etapie rekrutacji i twoim problemem nie jest jak
tworzyć oprogramowanie, tylko jak znaleźć douczonych fachowców.

W ogólnym przypadku założenie, że inżynier oprogramowania po
przeczytaniu ustawy i sprawdzeniu tego i owego w internecie będzie
mądrzejszy od fachowca jest dość ryzykowne.

> Potem można zabrać się za rozważania jak program ma działać.
>
> Nie, *NIE* żartuję - wziąłeś doskonały przykład, niemal wzorcowy,
> na to jak można wtopić na błędach założeń :)
> Policzenie choćby tylko VAT (a niekoniecznie jest to jedyny
> podatek który musi być ujawniany na dokumencie) jest dopuszczalne
> na wiele sposobów, w tym takich trudniejszych do wymyślenia,
> ale *niekiedy* napotyka na ograniczenia (trzeba zastosować
> się do któregoś spośród tych wielu)

Oczywiście z druiej strony założenie, że fachowiec usiądzie i napisze od
ręki specyfikację, w której będzie wszystko, co potrzeba. Raczej trzeba
się nastawić na to, że fachowiec powie jak ma być, proramista napisze
program, który to właśnie robi, potem fachowiec powie, że może być
jeszcze inaczej, i programista to zaimplementuje, potem fachowiec powie,
że tak, jak mówił na początku, że ma być, to nie może być jak cośtam itd.

> i wtedy na .podatki pojawia
> post w kategorii "a u głupka kontrahenta nie chcą poprawić f-ry
> bo twierdzą że system nie pozwala" :P
>
> Nie, nie mam na myśli stawki itede :)
>
> Obstawiam że takich przypadków jest sporo - coś co wydaje się
> proste zawiera pułapki które później trudno usunąć.

Natomiast inżynier oprogramowania powinien wiedzieć jak robić programy,
z których dowolne pułapki można łatwo usunąć.

> Taka aplikacja, dobrze zrobiona ale mająca działać bez wsparcia
> "24h na dobę czas dostarczania poprawki 2h" ;) np. powinna
> umożliwiać wpisanie dokumentu w 100% ręcznie lub ręczne
> poprawienie wszystkich pól, bo nie sposób przewidzieć która
> z kombinacji "metod" może wyskoczyć.
> Uczciwie - przewidziałbyś?

Uczciwie jest tak: albo świadczysz usługę "mówicie nam co program ma
robić, a my dostarczamy program, który robi właśnie to", albo usługę
"nasi analitycy analizują wasze potrzeby i powiedzą wam, co program
powinien robić i jak, a wy się zgodzicie albo nie".

Uczciwe świadczenie tej drugiej usługi, zwłaszcza w opcji "24h bez
wsparcia, poprawki w 2h" wymaga odpowiedniej kombinacji doświadczenia i
zatrudnienia kompetentnych analityków, co pozwoli ci to przewidzieć.

>> - jak przygotować dokumentację/opis projektu
>
> Tak żeby był tam zapis "zgodnie z przepisami", co daje do ręki
> narzędzie do doprowadzenia wykonawcy do rozpaczy ;)
> (patrz p.1 :), polecam osobiście zajrzeć do treści)

Jeśli bierzesz na siebie takie zobowiązanie, to musisz zatrudnić
analityka (czy nawet kilku), który powie ci, co jest zgodne, a co
niezgodne z przepisami i to ostatecznie trafia do specyfikacji. Jeśli
nie chcesz wziąć na siebie tego ryzyka, to szukasz klienta, który sam ma
księgowych, prawników czy kogo tam, którzy określą zgodność z przepisami.