Ten artykuł jest adresowany do wszystkich. Biznes (prawnicy także) może przekonać się, że oprogramowanie można narysować i zrozumieć. Analitycy i programiści, że to możliwe, a deweloperzy, że nikt im nie odbiera pracy a raczej pomaga. Wprowadzenie W dzisiejszym świecie inżynierii największą wartość mają czas i zasoby. Czas to jak najszybsze oddanie rozwiązania (produktu) do użytku (szybka komercjalizacja), zasoby to koszt jakim się to odbędzie. Kluczem są koszty: "time to market", tu kosztem jest opóźnienie komercjalizacji (niezrealizowane przychody), kosztem jest także samo powstawania oprogramowania. Praktycznie od początku inżynierii oprogramowania zależność kosztów…
Nie raz pojawiały się tu (mój blog) odniesienia do tak zwanego ideału (idealizacja ) jako wzorca lub szkieletu. W artykule o studium wykonalności pisałem: Brak wiedzy o stanie idealnym możliwym i brak modelu, czyni analizę wykonalności bardzo ryzykowną, więc praktycznie bezwartościową. (Źródło: Studium wykonalności ? czym naprawdę jest | | Jarosław Żeliński IT-Consulting) Dzisiaj kilka słów o jednym z "kilerów" projektów analitycznych: utrata panowania nad szczegółowością. Detale, detale... Praktycznie zawsze w toku odbioru wyników prac analitycznych słyszę: "ale tu nie ma wielu rzeczy". I jest to prawda, ale nie ma (zostały…
Producenci różnych rzeczy zdają sobie sprawę, że koszty podjęcia właściwej decyzji przy skomplikowanych produktach są spore i ludzie będą podejmować decyzje błędne, to pozwala działać na rynku firmom, które w przeciwnym wypadku by upadły.I jak teraz wyglądają w Państwa oczach zakupy i wdrożenia dużych gotowych systemów?Jak to robić lepiej? Po pierwsze nie kupować "dużych i drogich zintegrowanych systemów" bo to duże ryzyko, kupować mniejsze, łatwiejsze do opisania, projektować te, które są zbyt dużym ryzykiem w przypadku złego wyboru. Jeżeli już z powodu ryzyka mamy poświęcić duży budżet na kosztowne specyfikowanie oprogramowania to sygnał, że należy je za te pieniądze po prostu zaprojektować i wykonać.Niestety nie ma prostej odpowiedzi jak to robić "dobrze". Chyba, że będzie to propozycja następującego procesu:analiza biznesowa
zdefiniowanie celu
zaprojektowanie architektury systemu (to jako system należy rozumieć organizację wraz z wspierająca ją informatyką), zmierzamy w kierunku tak zwanej [[architektury korporacyjnej]]
zidentyfikować oczekiwane od oprogramowania usługi (wymagania), podzielić je na odrębne obszary dziedzinowe,
dla każdego obszaru dziedzinowego poprowadzić odrębny projekt wyboru rozwiązania.
wybrać rozwiązania.
Zwracam uwagę drobny szczegół: wybory produktu dokonujemy na końcu, nigdy na początku!
