asiaque <a...@w...hell.pl> napisał(a):

> Aleksander Galicki <t...@g...pl> wrote:
> > Tak z ciekawosci: a co z maintenance contract? Zwykle, jak sie oddaje
> > aplikacje, jest zawierany rowniez paroletni maintenance contract i w przypadk
> u
> > ciekniecia (ktore konczy sie pieknym OutOfMemoryError) czy innych bledow -
> > jest psim obowiazkiem odpowiedniej firmy to naprawic. Administrator nic nie
> > powinien poprawiac w zadnej klasie, zwlaszcza, ze zwykle jest to nielealne.
>
> Być może w doskonałej przyrodzie tak jest.

To nie jest doskonalosc, to calkiem zwyczajna normalnosc. To co opisujesz to
jest raczej przypadek kompletnej indolencji w zarzadzaniu (Twoja firma). Na to
zaden jezyk programowania rady nie da.
Choc, to ze macie problemy z memory leaks wskazuje, ze developerow tez macie
nienajlepszych (oglednie mowiac). Ostatni raz, gdy widzialem leak w aplikacji
javowej bylo z 6 lat temu. Ale jest istotna roznica pomiedzy memory leaks a
niewystarczajaca iloscia zasobow dla aplikacji. Dostalas niewatpliwie
java.lang.OutOfMemoryError z jakims komunikatem. Z ciekaowosci: jaki byl
komunikat?

A jak powinno byc? Mniej wiecej tak: firma, ktora potrzebuje i ktora stac na
nascie projektow softwareowych zatrudnia zespol odpowiednich prawnikow i pare
tzw enterprise/solution architects. Zadaniem prawnikow m.i. jest takie
formulowanie umow z firmami programistycznymi by zapewnic interesy wlasnej
firmy i, w razie czego, ud..nie firm, ktore sie nie wywiazuja z podpipsanych
kontraktow. Zadaniem architekta (czesto jest to osoba, ktora spedzila z 10 lat
po drugiej stronie i zdecydowala sie na 10 razy mniej ciekawa prace za 3 razy
wiecej kasy) jest kontrolowanie i zatwierdzanie merytoryczne tego co robi
wykonawca. Zwykle takie jednorazowe projekty to tzw fixed price-fixed size, co
oznacza ze termin, koszty, deliverables i jakosc owych deliverables sa
ustalone przy podpisywaniu kontraktu. Za dowolne poslizgi wzgledem ustalonych
uprzednio kosztow i terminow placi wykonawca. Kary za poslizgi tez sa
ustalone. Krytycznych bugow po releasie zwykle nie ma, bo przed releasem jest
paromiesieczny (dla srednio malego projektu) okres testowania. Wtedy sa tez
kilka rund tzw user acceptance testing, podczas ktorych powinny byc naprawione
wszystkie bugi wylapane przez zewnetrzych testerow. To sie nazywa user
acceptance testing, bo dopoki nie sa naprawione wszystkie bugi kleint moze nie
przyjac projektu, co bedzie roznowazne z uruchomieniem zespolu prawnikow,
ktorzy ud..pia wykonawce w razie nienaprawienia chocby jednej literowki. Mniej
wiecej w tym samym czasie sa tez testy niefunkcjonalne: m.i. ze skalowalnosci,
wydajnosci, bezpieczenstwa i niezawodnosci (odpowiednie oczekiwania tez
powinny byc zawarte w kontrakcie, a architekt jest odpowiedzialny za ich
sensownosc). Dla zwyklych aplikacji biznesowych zwykle sie wynajmuje na dwa
tygodnie odpowiednia ilosc serwerow w np jednym z HP Solution Centers i sie
testuje: co sie stanie z aplikacja po 1,5,10,15... latach, co bedzie jak
przewidziana liczba uzytkownikow skoczy z X do 100*X i tak dalej. Pelna
dokumentacje z tego testowania przekazuje sie architektom klienta do
akceptacji. Po zaakceptowaniu tego wiekszych problemow z wydajnoscia przez
nastepne nascie lat nie powinno byc bo to ile zasobow potrzebuje aplikacja
jest udokumentowane. Dla odrobine wazniejszych aplikacji, procz takiego
testowania jest tez okres, gdy aplikacje nie jest jeszcze w produkcji ale jest
na pilot environment.

Nie masz tak we wlasnej firmie? Zmien firme.


A.

--
Wysłano z serwisu Usenet w portalu Gazeta.pl -> http://www.gazeta.pl/usenet/