Zbiegły się dwa fakty: gorąca dyskusja na forum na temat umiejętności programistów i przy okazji ich roli w procesie wytwarzania oprogramowania oraz przesyłka z kolejną nową książką na moja półkę. Ale po kolei. Najpierw fazy cyklu wytwarzania oprogramowania a potem kilka uwag. Zakupiona książka opisuje całość, ja tu skupie się na jej wstępie. Nie będę jej tłumaczył a jedynie opisze idee. Zwrócę także uwagę na pewne aspekty związane z dostarczaniem gotowego oprogramowania, np. systemów typu ERP lub ich komponentów.
Ogólnie tak zwany rynkowy łańcuch wartości dodanej polega na tym, że na każdym etapie łańcucha dystrybucji powstaje wartość dla następcy. Każdy następca jest klientem swojego poprzednika a ten dostawcą swojego klienta. Jeżeli któreś ogniwo (etap) nie tworzy wartości, jest pomijane (w jakiejś perspektywie).
Mając na uwadze powyższe i tę powszechnie powtarzaną zasada "klient nasz Pan", w moich oczach uznawanie jej raczej świadczy o tym, że ktoś nie rozumie swojej roli w tym łańcuchu. Uznając, że to klient jest "naszym Panem" przyznajemy, że nie mamy żadnego wpływu na naszą działalność (sprzedaż). System CRM to narzędzie wspierające budowanie wartości dodanej, jeśli tego nie robi stanowi raczej zbędny koszt.
Celem jest oprogramowanie a dostawcy oprogramowania najmniej ryzykują gdy dostaną jego specyfikuję czyli gotowy projekt. Tak wiec przetestowany model oprogramowania realizujący cel zamawiającego jako wynik analizy systemowej stanowi nic innego jak opis produktu, który ma powstać. Oczywiście nikt nie projektuje od zera oprogramowania biznesowego bo to nierozsądne, wykorzystuje się tak zwane szkielety oprogramowania. O szkieletach już było tu: Frameworks Introduction ? czyli jak się psuje dobre ERP. A teraz zapraszam do obejrzenia tego co tu napisałem po mojemu czyli na diagramie :) (tak zwane mapy myśli czasami sie przydają :)).
Warto tu zwrócić uwagę na jedną rzecz: ewentualne zmiany rozwiązania i korekty modelu (czyli projektu) odbywają się nadal na etapie analizy i projektowania, a wiec o rząd albo dwa taniej, niż podczas implementacji. Jest to główna przewaga tej metody nad analizą w postaci sesji [[JAD]] i opracowywania strukturalnych dokumentów.
Te i podobne "zasady" to w moich oczach jakieś oczywistości. Jednak czy złe? Hm.... czasami mam wrażenie, że wielu ludzi faktycznie powinno nawet te oczywistości poznać, z drugiej jednak strony zachodzi ryzyko, że ktoś uwierzy że proste stosowanie ich obligatoryjnie prowadzi do prostych sukcesów a to już jest ślepa uliczka. Ludzie często szukają "złotego środka" na wszystko, tak zwanej "[[srebrnej kuli]]". Nie prostych recept, gdyby istniały nie było by problemów. Każdy problem (wyzwanie) to indywidualny problem w unikalnym środowisku. Jeżeli ktoś daje wiarę w to, że istnieje jakaś recepta na ich rozwiązywanie ...
Wyobraźmy sobie kogoś, kto chce napisać program symulujący grę w snookera. Problem ten może zostać opisany przypadkami użycia opisującymi powierzchownie cechę: "Gracz uderza biała kulę, która przemieszcza się z pewną prędkością, ta po określonym czasie uderza czerwoną kulę pod określonym kątem, uderzona czerwona kula przemieszcza się na pewna odległość w pewnym kierunku." Możesz sfilmować setki tysięcy takich uderzeń, zarejestrować parametry każdego uderzenia i jego skutki. Jednak ta metoda i tak nie stworzysz nawet dość dobrej symulacji. Aby napisać na prawdę dobrą grę, powinieneś raczej zrozumieć prawa rządzące ruchem kul, ich zależność od siły i kierunku uderzenia, kierunku itp. Zrozumienie tych praw pozwoli Ci znacznie łatwiej napisać dobre oprogramowanie." (źr. [[Analysis Patterns. Reusable Object Models, Martin Fowler, Addison-Wesley, 1997]]).
