Po co nam CASE?
Bo
Dzięki narzędziom CASE projekty tworzy się dokładniej, a praca nad diagramami, sprawdzanie ich poprawności oraz śledzenie wykonanych testów jest prostsze i szybsze. (wiecej: http://www.eioba.pl)
Tak więc gorąco polecam stosowanie narzędzi (lista narzędzi CASE).
Z zasady nie reklamuje oprogramowania. Uważam, że jego sprzedawanie to inna kompetencja. Jednak nie da się ukryć jestem użytkownikiem "czegoś". Czym to jest? Pakiet typu [[CASE]] [[Visual-Paradigm Agilian]]. I co my tu mamy? Wczoraj dotarł do mnie upgrade i... mamy burzę mózgów :):
Stosowanie analizy systemowej, modelowania oraz formalnych notacji do tworzenia modeli, powoduje, że wyniki analiz są daleko bardziej wiarygodne. Z reguły celem pracy analityka biznesowego czy projektanta jest opracowanie opisu rekomendowanego rozwiązania. Może nim być docelowy model organizacji czy też opis oprogramowania jakie należy dostarczyć (bo nie zawsze wytworzyć!). W procesie formalnej analizy systemowej (nie jest to analiza systemu informatycznego, to analiza dowolnego systemu), powstają modele, które testujemy. Taki model to najpierw hipoteza, a po weryfikacji, jest to opis rozwiązania (projekt tego co ma powstać). Idealną sytuacją była by taka, a której mamy narzędzia do modelowania każdej analizowanej dziedziny. W klasycznej inżynierii jest to rysunek techniczny i zasady obliczania wytrzymałości, sformalizowany system tworzenia schematów elektrycznych i elektronicznych i wiele innych (zależnie od dziedziny), notacje UML w inżynierii oprogramowania. W sferze zarządzania mieliśmy do niedawna biała plamę, teraz mamy już BMM czy ArchiMate. Moim zdaniem utrzymywanie, że można coś skutecznie analizować metodami nieformalnymi świadczy raczej o niewiedzy i braku kompetencji.
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.
