Konkluzja prawnika, by zawierać umowy o dzieło jeżeli tylko jest to możliwe, jest moim zdaniem słuszna. Tam gdzie nie mamy wystarczającej wiedzy by zawierać takie umowy, warto zainwestować czas by określić jednak przedmiot umowy, gdyż umowa zlecenia z ekspertem (dostawcą oprogramowania) powoduje, że Zamawiający kompletnie nie panuje nad umową: nie wie jakiego produktu oczekiwać, satysfakcja z wykonanej pracy może nadejść w trudnym do przewidzenia czasie.
Druga uwaga: jeżeli cały proces, od pierwszej analizy do dostarczenia produktu, realizuje jedna firma, mamy do czynienia z sytuacją, w której dostawca sam kontroluje stawiane mu wymagania bo sam sobie definiuje to co ma następnie wytworzyć. Taki brak kontroli rodzi poważne ryzyko nierzetelności.
aktorem absolutnie nie jest Czas, aktorem jest inny system, tu źródło sygnału czasu. Diagram UC jest zgodny ze standardem a my "zrozumieliśmy istotę rzeczy". Stosowanie w analizie standardów prowadzi do rozumienia i ma taką właśnie zaletę: analiza i modelowanie prowadzi do zrozumienia problemu, łamanie zasad notacji ukrywa niezrozumienie problemu (o co chodzi z tym oczekiwanym przez klienta czasem).
Stosowanie reguł (semantyki i syntaktyki) UML pozwala utrzymać spójność modeli zależnych (podległe temu diagramowi uszczegółowienia Projektu Systemu, realizacja Aktorów, przypadki użycia itp.) oraz zachować spójność logiczną i pojęciową całej dokumentacji. To zaś jest warunkiem weryfikacji poprawności całego projektu.
UML to notacja, której kluczowym pojęciem jest klasyfikator (oparta jest na definiowanych pojęciach i relacjach między nimi) dlatego warto przestrzegać (zawsze warto) zasad notacji i np. nie utożsamiać Aktora System CRM (jest to jakaś abstrakcja systemu integrowanego) z konkretnym Jakimś Systemem CRM. Aktor ma konkretne znaczenie na diagramie UML (zdefiniowane wyżej) i konkretny system także. Zachowanie tego podziału (abstrakcja i jej realizacja) pozwala zdefiniować oddzielnie wymagania i oddzielnie konkretne rozwiązania je spełniające co jest istotą rozdziału wymagań od spełniających je rozwiązań.
Diagramy przypadków użycia są bardzo ważnymi diagramami, gdyż stanowią "korzeń" modelu realizacji systemu zaś łamanie zasad notacji prowadzi praktycznie zawsze do utraty możliwości ich, modeli, weryfikacji.
Dokumentacja stanowi także element zarządzania wiedzą. Gdy nie ma dokumentacji nowy człowiek w zespole zajmuje czas kolegów, którzy muszą mu "opowiedzieć" o projekcie, jak jest dokumentacja, czyta ją sam nie obniżając efektywność pracy kolegów.
Tak więc dla jasności: nie neguję typowej dla SCRUM czy XP wersji postępowania, a tylko wskazuje na sytuacje gdy preferowane są inne. Co do Agile podsumuję moje podejście: PMI czy Prince2 to dla mnie raczej formalny spis treści "projektu" ale dla każdego rzeczywistego projektu sam dobieram te elementy tego spisu, które mi pomogą i tak pojmuję zwinność projektową.
źródło: http://www.geotor.pl/przemysl.htm
Tak więc wymagania na oprogramowanie powinny być określone przez dialog biznesowy zaś specyfikacja oprogramowania przez dialog technologiczny. I tu łyżka dziegciu: wiele razy byłem świadkiem gdy to zamawiający psuł projekt uważając, że wie lepiej jak się tworzy oprogramowanie. Zjawisko to (tu bardzo niebezpieczne dla życia ludzi) także zna inżynieria budowlana dlatego prawo budowlane wymaga projektu architekta a jego projekt chroni nie tylko prawo budowlane ale także i autorskie.
Istotą opisu wymagań na system jest kontekst całego projektu i tej inwestycji a kontekstem tym jest model biznesowy i zakres projektu. Model biznesowy można wykonać nawet metodami formalnymi za pomocą pseudokodu czy języka relacji logicznych jednak model taki jest bezwartościowy, jeżeli nie stanowi sobą zrozumiałego przekazu dla każdego zaangażowanego w projekt czytaj "szczególnie klienta biznesowego". Kluczem do sukcesu jest tu modelowanie czyli zobrazowanie w sposób zrozumiały dla każdej strony w projekcie IT istoty biznesu i jego kontekstu w projekcie tworzenia i wdrażania oprogramowania. Model biznesowy i wewnętrzna struktura zarządzania organizacji to nie obiektowe modele a procesowe mapy łańcuchów tworzenia wartości w firmie. Model obiektowy ma zastosowanie dopiero podczas tworzenia modeli informacyjnych czyli struktury danych przechowywanych i przetwarzanych w firmie a dane to nic innego jak reprezentacja tych informacji, które firma chce przetwarzać oraz sposób w jaki chce to robić o czym wielu analityków zdaje się zapominać. Jak więc prowadzić analizy wymagań?
Tworzę model procesów (używam notacji i metodyki BPMN ale w prostszych przypadkach może to być np. diagram czynności UML), od którego proponuję zacząć. Potem wskazuję (wybieram) te czynności, które będą "komputeryzowane" (bo nie koniecznie wszystkie). W metodyce którą stosuję jest pojęcie czarnej skrzynki. Jest to np. projektowany jeszcze hipotetyczny system. Tworząc model procesów łączę czarną skrzynkę z wybranymi czynnościami (procesami) i optymalizuje tak powstały model.
[...] W systemach zorientowanych na procesy poprawnie skonstruowana aplikacja jest w stanie rozwijać się płynnie wraz z firmą. Model procesowy traktuje ludzi (aktorów) jak zasoby dlatego rozbudowa aplikacji z natury ewolucyjnej (modeler procesowy to integralna część systemu) jest niejako wpisana w jej życiorys. Dopisanie nowego procesu może wymagać nowego pracownika lub stanowiska a to jest tylko naturalną czynnością w postaci dodania nowych zasobów. [...]
