Pomijając ich warianty, stosowane są dwie metody (grupy metod) dokumentowania wymagań i zarządzania nimi. Zakładamy, że są to wymagania wobec produktu (rozwiązania) jaki ma dostarczyć jego dostawca. W BABoK (Business Analysis…
Nie raz już pisałem tu o architekturze (Architektura systemu) tym razem kilka słów o tym. Często jestem pytany o kryterium podziału dużego systemu na komponenty. Jednym z nich jest praktyka dążenia do…
Jest dość liczna grupa ludzi uważająca, że w Internecie nie obowiązują ani prawa fizyki, ani prawa ekonomii ani nawet zdrowy rozsądek. W kwestii inżynierii oprogramowania ludzie Ci straszą świat projektów…
Jeżeli jeszcze ktoś nie wyczuł podstępu to niniejszym informuję, że powyższy diagram to diagram klas notacji UML. Jego cechą jest to, że klasy zostały przedstawione z pomocą ikon, reprezentujących określone stereotypy. Zgodnie z UML, linie przerywane z grotem reprezentują związki użycia (grot wskazuje na użyty obiekt)), asocjacje z pełnym rombem to kompozycje (związek całość część). Czy taki diagram jest niezrozumiały dla biznesu? Mam także nadzieję, że tu widać wyraźnie, że modelowanie dziedziny systemu w postaci klas połączonych z pomocą prostych asocjacji itp., to nie model obiektowy a nieudolna atrapa bazy danych, która z paradygmatem obiektowym nie wiele ma wspólnego.
Jak widać próba wyceny całego projektu już na samym jego początku to wróżenie z fusów, wykonawca przyjmie wartość bezpieczna dla siebie, a tak określony budżet i tak zostanie skonsumowany (co pokazuje praktyka, tak się składa oferty w przetargach publicznych, taka jest jakość większości zapytań przetargowych!). Wystarczy wydzielić etap projektowania (analiza i projektowanie to ok. 20% kosztu developmentu) i zawrzeć umowę na etapie co najmniej wstępnego projektu, wtedy "zawyżanie" (narzucanie zapasu na niewiedzę) spada dwukrotnie. Opracowanie kompletnego projektu przed wyceną prac developmentu to obszar bliski prawej części: estymacja kosztu z bardzo małym błędem.