Tak więc przypadkami użycia opisujemy abstrakcję jaką jest [[Model Dziedziny Systemu]]. Są one wtedy proste, zawierają scenariusz, który w skrócie ma postać: aktor inicjuje usługę, system prezentuje formularz do wypełnienia, aktor wypełnia go i potwierdza, system potwierdza odebranie danych i pokazuje wynik swojej pracy (lub komunikaty o błędach). Tu skupiamy się na opisie tego jakie usługi są wymagane od systemu. Kolejny etap to "komplikowanie" każdego scenariusza w postaci projektowania, dla każdego przypadku użycia, różnego rodzaju wizardów lub wprowadzamy ograniczenia związane z uprawnieniami użytkowników. Ten etap to praca projektantów UX i grafików, specjalistów od ergonomii itp.
Bardzo ciekawa książka, przydatna każdemu kto zajmuje się nie tylko inżynierią oprogramowania (ale tą także). Analiza systemowa, projektowanie systemów, to szersza dziedzina niż tylko IT. O ogólnej teorii systemów następna książka. Modern Methods of Systems Enginieering to rodzaj podręcznika. Kolejne rozdziały opisują metody i narzędzia stosowane w projektach z obszaru szeroko pojętej inżynierii systemów. Można tu znaleźć opis procesów analizy systemowej, spis treści kluczowych dokumentów w kolejnych etapach prac. Co nieco o notacji SysML (Systems Modeling Language). Opisana tu metoda i narzędzia pracy są zgodne (kompatybilne) z [[DoD Systems Engineering Fundamentals]], [[NASA Systems Engineering…
zbieranie wymagań tylko metodą spisywania oczekiwań czy wręcz żądań, użytkowników, jest jedną z najgorszych metod pozyskiwania wymagań! Praktycznie zawsze prowadzi do powstawania specyfikacji bardzo złej jakości (niespójne i niekompletne) oraz niekontrolowanego rozrastania się harmonogramu i budżetu projektu. Dostawcy oprogramowania, godzący się na taki styl prowadzenia projektu, świadomie lub nie, działają na szkodę swoich klientów. Analiza systemowa organizacji jako sposób pozyskania wymagań, który chroni przed takimi zjawiskami.
Swego czasu miałem na jednej z konferencji o "big data" referat na temat problemu złożoności i jej analizy. Generalnie problem złożoności ładnie opisał Karl Popper, w swoim dziele Wiedza Obiektywna metaforą "o chmurach i zegarach". To co obserwujemy, system, może być tak złożone, że ilość obiektów i ich wzajemnych oddziaływań jest zbyt duża by możliwe było stworzenie modelu (teoria wyjaśniająca zachowanie) takiego systemu, pozwalającego na przewidywanie zachowania takiej złożoności. Są jednak systemy, których natura na to pozwala, ich model jest możliwy do stworzenia, takie systemy są przewidywalne. Metaforą systemu nieprzewidywalnego jest tu chmura, a przewidywalnego zegar. Oczywiście jest nieskończenie wiele systemów o naturze gdzieś pomiędzy chmurami i zegarami.
Tak więc, warto rozważyć stosowanie reguł biznesowych i słowników pojęć (Semantics Of Business Vocabulary And Rules), gdyż jest to sprawdzona i bardzo przydatna technika analizy i dokumentowania logiki biznesowej. Polecam także stronę The Business Rules Group i zamieszczony tam Manifest Reguł Biznesowych. Tworzenie monstrualnych dokumentów wymagań, zawierających dziesiątki razy powielane "walidacje" prowadzi do wielu kłopotów z utrzymaniem spójności i kompletności takich specyfikacji. Pomijam już ich uciążliwą objętość. Jako materiał dla programisty są one wtedy trudne w użyciu, do tego skłaniają do najgorszych praktyk, jakimi jest między innymi umieszczanie logiki biznesowej w kodzie formatek ekranowych.
Na koniec największy mit: analiza jest prosta, wystarczy wiedzieć jak ją wykonać i mieć właściwe wzorce dokumentów. Nic tej tezy nie potwierdza, a tak wielu próbuje... Znam masę przypadków, gdy ktoś uznał, że przyuczona grupa pracowników sama wykona analizę wymagań, w końcu to tylko spisywanie potzreb. Niestety nie znam żadnego przypadku gdzie, na bazie tak spisanych wymagań, projekt zakończył się sukcesem. Jest zresztą prosty sposób na ocenę jakości dokumentu opisującego wymagania: skonfrontowanie go z tym co w końcu powstało.
Książka adresowana do programistów, sam tytuł to sugeruje. Warto ją kupić (programiści) bo bardzo wyczerpująco opisuje to, co nazywam "implementacją obiektowości". Samo nauczenie się (semantyka i syntaktyka) obiektowo zorientowanego języka programowania to mało, warto poznać na czym ta implementacja polega: czym jest obiekt, dziedziczenie czy kompozycja. Autor skupia się jednak na implementacji samej "obiektowości". Moim zdaniem książka jak najbardziej przydatna programistom, bo przykłady są ilustrowane kodem i diagramami UML. Jednak nie znajdziecie tam zbyt wiele o obiektowo zorientowanym opisie modelowanej rzeczywistości, czyli o biznesowym aspekcie programowania i projektowania. Z treści książki…
Właśnie, jak to jest? Regularnie słyszę z ust zwolenników stosowania metody, którą nazywają "zwinną", że "nie da się opisać wymagań przed rozpoczęciem projektu, należy/można je [wymagania] odkrywać w toku projektu, bo klient zna tylko cel i razem do niego dążymy, prototypy - tak właśnie radzimy sobie z nieprzewidywalnością wymagań". Przypomnę: wymagania to "warunki jakie coś musi spełnić aby było przydatne" (sł. j.polskiego PWN), jak mam tu rozumieć "brak wymagań na początku projektu", skoro jego - projektu - celem jest wytworzenie czegoś przydatnego? Co to znaczy "wymagania dzisiaj są nieprzewidywalne"? To…
Tak więc warto się zastanowić jak dotrzemy do wiedzy o naszej firmie, i na ile jest ona wiarygodna, nie zaciemniona nadmiarem zbędnych szczegółów i czy wiedza ta jest obiektywna. Dobra analiza konkretnej organizacji, firmy, urzędu, i jej wyniki nie może być np. polityczna (regularnie spotykam w firmach analizy, których celem jest wykazanie przydatności określonego rozwiązania!) bo to działanie polegające na oferowaniu leków przed diagnozą (reklamy leków bez recepty w TV!). Tak można sobie tylko zaszkodzić. A zdalna analiza (faktycznie zdalnie odbywa się ok. 80% pracy) pozawala po pierwsze obniżyć jej koszt, a po drugie zobiektywizować jej wyniki.
Pakiet którego używam (Visual-Paradigm) po ostatnich zmianach ma szanse stać się w moich oczach ideałem :). O jego nowej wersji pisałem tu: Visual-Paradigm v.11.1. Pisałem tez, że jest w 100% zgodny ze specyfikacjami notacji zarządzanych przez OMG, co jest bardzo ważne. Tu zwrócę uwagę na kilka przydatnych cech. Moim zdaniem cechą dobrego projektu jest nie tylko dobra metodyka ale także to czy dysponujemy narzędziami, które ją wspierają. Tymi narzędziami są nie tylko notacje i systemy pojęciowe ale także oprogramowanie CASE, które powinno spełniać trzy kluczowe warunki: wspierać (a przynajmniej nie ograniczać) metodykę,…
Zakup oprogramowania, które stanowi jeden, zintegrowany współdzieleniem danych, monolit to nic innego jak zafundowanie sobie długu technologicznego w momencie podjęcia decyzji o takim zakupie. Żadna firma, działająca w obecnych czasach, nie da sama sobie gwarancji, że jej wewnętrzne aktywności nie zmienią się co do ich specyfiki, że nie przybędzie nowych, nie zrezygnuje z niektórych. Monolityczny całościowy system ERP stanowi hamulec każdej takiej zmiany. Oparcie całości na centralnym , współdzielonym module rejestrującym (jest z nim z reguły księgowość) to niemalże "zabetonowanie" architektury biznesowej firmy.
Tak więc stagnacja szkodzi, są to krótkotrwałe zyski, podobne do niezapłacenia rachunku za energie elektryczną: za miesiąc będzie dwukrotnie wyższy plus odsetki. Bieżące, dobrze zaplanowane "aktualizacje" (oprogramowania, dokumentacji projektowej, analizy i planowania, itp.) to relatywnie małe koszty, a dla firmy istotne są nie tyle kwotowe chwilowe wydatki (oszczędności) co płynność finansowa i długoterminowa rentowność. Dlatego permanentni dłużnicy zawsze płaca więcej a czasami bankrutują.
