baza danych - repertorium

Grzegorz Gruza pisze:
Praktyka też pokazuje, że klient zapłaci proporcjonalnie do wielkości tego, czego oczekuje. A często też ma z góry określony budżet. Zakładając, że nie potrzebuje konfigurowalnych stawek VAT, wykonawca ma 2 wyjścia: 1. Dać mu je na swój koszt. 2. Nie dać mu ich i jak się system rozrośnie rozbudować zastosowane wcześniej półśrodki za kasę.
Ja nie widzę nic złego w podejściu 2.
To zalezy co bylo w specyfikacji. Bo jesli bylo okreslone ze program ma dzialac dla stawek (i tu wymienione), to rozwiazanie 2 jest prawidlowe. Jesli natomiast jest to okreslone tak, że program ma działac w oparciu o aktualne stawki VAT, to w tym momencie rozwiazanie drugie jest niezgodne ze specyfikacja. I jesli klient bylby na tyle 'kumaty' w tym zakresie, to bylo by kiepsko
Ogolnie to jest tak, ze oszczedzisz sobie kilku minut pracy (bo takie cos jak stawki VAT to osoba pracujaca w danym zagadnieniu ma na pewno juz opracowane), a wyprodukujesz proteze ktora bedzie dzialala tylko w danym momencie. niedostosowany do realiów, niekonfigurowalny, klient niezadowolony itp. Warto? IMHO nie. Przemyslaw Osmanski pisze:
Stawki VAT to powszechny przykład - ale nie wiadomo, czy tak na pewno dobrze jest rozpracowany, bo nie pamiętam żeby te faktyczne zmiany były.
Zgadzam się z tym, że kilku minut pracy nie warto oszczędzać. Nie zgadzam się z tym, że w kilka minut więcej jest się stworzyć system z elastycznymi stawkami VAT w stosunku do systemu bez elastycznych stawek, bo w kilka minut, to można w głowę się podrapać i poczytać grupy dyskusyjne:-).
Efekt? W przypadku zmiany stawki VAT - program
Nie wiem, czy kolega pamięta problem roku . Klienci mówili, że w roku to oni już będą mieli całkiem nowe systemy. Życie zweryfikowało tę prawdę. I co - winni tu są analitycy czy programiści, bo nie przewidzieli, że klient nie wymieni swego systemu do roku?
Pozdrawiam

Grzegorz Gruza []
Praktyka też pokazuje, że klient zapłaci proporcjonalnie do wielkości tego, czego oczekuje. A często też ma z góry określony budżet. Zakładając, że nie potrzebuje konfigurowalnych stawek VAT, wykonawca ma 2 wyjścia: 1. Dać mu je na swój koszt. 2. Nie dać mu ich i jak się system rozrośnie rozbudować zastosowane wcześniej półśrodki za kasę.
Ja nie widzę nic złego w podejściu 2.
Jeśli robisz już któryś z rzędu system masz to już opracowane. 10 minut pracy programisty. Jeśli pierwszy warto opracować aby potem tylko wpinać do projektów.
Spróbuj powiedzieć klientowi że musi zapłacić za coś co spieprzyłeś Ty. Poprawiałeś kiedyś aplikację napisaną techniką którą proponujesz? takie potworki opłaca się wywalić i napisać od nowa. się szaleniec co połata takiego potworka tworząc super potworka i później płacz że projekt się nie udał, że system nie działa tak jak powinien itp.
Klient nie zawsze wie czego chce od tego jest analityk aby mu uświadomić co potrzebuje. aby klient był zadowolony. Skutek? Kolejne projekty dla klienta i jego znajomych. Bo system działa tak jak powinien.
Dla mnie takie podejście wygląda złapać klienta, wydoić maksymalnie i uciekać aby nie złapał jak się dowie co kupił. Trochę taka bazarowa mentalność. Ale nie o tym wątek.
[]
Obojętnie w której warstwie zastosujesz dodatkową obsługę zawsze musisz to zrobić w stosunku do sytuacji, gdy stałe stawek zaszyłeś w programie. Zresztą, zaszycie stałych w programie też coś kosztuje, więc ja wolę zaszywać stałe w bazie danych i nie dawać obsługi tych tabel użytkownikowi, dopóki nie zamówi takiej funkcjonalności :-).
Ale to są słowniki. Od obsługi ich masz gotowe komponenty. Tylko wkładasz do aplikacji i masz obsługę. 10 minut na podpięcie? A klient zadowolony. Nie zaszywasz stałych, pobierasz z konfiguracji.
karol pisze:
Ja akurat piszę systemy na zamówienie, gdzie każdy jest na tyle inny, że analizuje i projektuje się go całkowicie od zera - owszem, zdobyta wcześniej wiedza się przydaje, ale reużywalnych wysokopoziomowych komponentów nie jest za dużo.
Wiem - za spieprzenie nie ma szans wyciągnąć dodatkowych pieniędzy. Ale napisanie systemu zgodnie z wymaganiami dostarczonymi przez klienta nie może być spieprzeniem.
Tak. Co więcej - często umawialiśmy się z klientem tak - do dnia X dostarczamy aplikację nieskalowalną (w kontekście rozumienia tego słowa w tym wątku), później, do dnia Y dostarczamy skalowalną. Podejście takie wynikało z tego, że do dnia X klient musiał zamknąć budżet/wykazać się przed zarządem itp. Osobiście nie lubię takiej sytuacji, ale do klienta trzeba się dostosować.
Często
To prawda.
Ale zawsze znajdzie
Na szczęście w mojej firmie nie zawsze.
Do tego odniosłem się już w innym miejscu wątku.
Ja czasem wolę dorzucić jakąś funkcjonalność "gratis",
To prawda z zastrzeżeniem, że koszt gratisu nie jest znaczący w skali całości.
Sorry, ale pracuję w dziale obsługującym klientów strategicznych, więc moja opinia nie wynika z takiego podejścia.
Rzeczywiście, zrobiło się mocno OT.
Możesz dać mi przykład takiego komponentu? Pytam poważnie, bo u mnie w firmie najlepszy implementator obsługi słowników robi obsługę do 3 słowników dziennie (mówię o aplikacjach WWW) - chętnie zeszlibyśmy do 10 minut. "Lepszy" wynik osiągamy tylko przy umieszczeniu wszystkich słowników w jednej/dwóch tabelach.
Poza tym z tymi stawkami VAT to nie jest prosty słownik, tylko czasowo zależny (stawki obowiązują w jakimś okresie).
Pozdrawiam

Stawki VAT to powszechny przykład - ale nie wiadomo, czy tak na pewno dobrze jest rozpracowany, bo nie pamiętam żeby te faktyczne zmiany były. zgadzam się z tym, że w kilka minut więcej jest się stworzyć system z elastycznymi stawkami VAT w stosunku do systemu bez elastycznych stawek, bo w kilka minut, to można w głowę się podrapać i poczytać grupy dyskusyjne:-). Nie wiem, czy kolega pamięta problem roku . Klienci mówili, że w roku to oni już będą mieli całkiem nowe systemy. Życie zweryfikowało tę prawdę. I co - winni tu są analitycy czy programiści, bo nie przewidzieli, że klient nie wymieni swego systemu do roku? Grzegorz Gruza pisze:
Byly byly, bo o ile podstawowe stawki sie nie zmienialy, to np. z mojej dzialki (rolnictwo) byly zmiany na stawkach posrednich (opal, komponenty do produkcji) od 17% poprzez 14, 13. W chwili obecnej jest juz to zniesione. Tak wiec zmiany na przelomie ostatnich 10lat byly :).
Nie o to chodzi, zeby system tworzyc od nowa, ale zeby zaimportowac juz wlasne gotowe rozwiazanie do obslugi takowego. Jesli sie w danej dziedzinie siedzi wystarczajaco dlugo, to odpowiednie biblioteki, komponenty juz sa gotowe.
Trudno powiedziec czego to byla wina. Moze nawet architektury ktora uwzgledniala tylko dwie cyfry dla roku. I wlasnie trzymania sie na sile kompatybilnosci z ta pierwsza. Z drugiej strony podobny 'bug' jest z peselem i trzeba bylo sztukowac :) I kto o tym nie pomyslal? Przeciez chyba nie zalozyli ze po roku dzieci rodzic sie nie beda?
pozdrawiam, Przemek O.

Dla mnie takie podejście wygląda złapać klienta, wydoić maksymalnie i uciekać aby nie złapał jak się dowie co kupił. Trochę taka bazarowa mentalność.
Sorry, ale pracuję w dziale obsługującym klientów strategicznych, więc moja opinia nie wynika z takiego podejścia. Ale nie o tym wątek.
Rzeczywiście, zrobiło się mocno OT.
[]
Ale to są słowniki. Od obsługi ich masz gotowe komponenty. Tylko wkładasz do aplikacji i masz obsługę. 10 minut na podpięcie? A klient zadowolony. Nie zaszywasz stałych, pobierasz z konfiguracji.
Możesz dać mi przykład takiego komponentu? Pytam poważnie, bo u mnie w firmie najlepszy implementator obsługi słowników robi obsługę do 3 słowników dziennie (mówię o aplikacjach WWW) - chętnie zeszlibyśmy do 10 minut. "Lepszy" wynik osiągamy tylko przy umieszczeniu wszystkich słowników w jednej/dwóch tabelach. Poza tym z tymi stawkami VAT to nie jest prosty słownik, tylko czasowo zależny (stawki obowiązują w jakimś okresie). Grzegorz Gruza []
Może jestem zbytnim idealistą ;)
Gotowca nie znam. Zapewne gdzieś ktoś już to napisał. U nasz to był test/wprawka dla 2 nowych studentów ;) Ale kiedyś na własne potrzeby stworzyliśmy taki cudeńko które dodanie słownika do aplikacji załatwiało w 10 minut roboty:) Nie wiem w czym programujesz ja to w c# robiłem. Myk poległa na tym że była klasa bazowa słownika po której dziedziczyła twoja klasa słownika, gdzie mogłeś zmienić/dodać funkcjonalność inną niż standardowa. Struktura tabeli dla wszystkich słowników identyczna. Oczywiście klasa bindowalna więc połączenie z UI banalne. No i uniwersalna kontrolka do obsługi edycji wszystkich słowników. Całością zarządzał DictionaryManager :)
Nasza implementacja uwzględniała daty ważności konkretnych wpisów, i nawet potrafiła Ci zwrócić aktualne na daną datę ;)