osobiście i bardzo subiektywnie uważam, że nawet jeśli dowolną kupę mało spójnego tekstu rozłożymy na wiersze i kolumny dowolnej ilości tabel (to się czasem nazywa czasem nadawaniem tekstowi struktury) to taki tekst nadal będzie mało spójny. Przypadki użycia jako tabelaryczna forma zapisu "user story" lub wymagań funkcjonalnych, nie uzyskają spójności poprzez sam fakt ich stabelaryzowania. Przypadki użycia zaś jako efekt analizy całości zachowań i świadomego wyboru części z nich to jest dopiero spójny i kompletny opis wymagań. Bo jak to ktoś powiedział: kompletna lista najładniejszych kobiet w danym mieście to nie lista spotkanych ładnych w ostatnim miesiącu a lista wybranych spośród wszystkich w tym mieście. Taka lista ma sens bo nie grozi nam to, ze następnego dnia w tym mieście spotkamy inna ładniejszą.Jeżeli ktoś Ci przyniesie specyfikację przypadków użycia do systemu i nie będzie potrafił jednoznacznie odpowiedzieć na pytanie dlaczego jest ich akurat tyle a nie np. jeden mniej lub dwa więcej albo dlaczego akurat te a nie inne, to najprawdopodobniej znaczy to, że podczas wdrożenia na pewno "spotkasz kilka innych ładniejszych kobiet".
Jeśli okaże się, że normy korporacyjne są sprzeczne z jego normami, to jak powiedział Krzysztof, ?Take it or leave it?. Normy korporacyjne w sposób eufemistyczny nazywają to, co my nazywamy zachowaniami nieetycznymi, zbyt często tak się dzieje. (źr. Etyka w biznesie/marketingu | Filozofia marketingu). Stale spotykam się z tym, że powyższa zasada sprawdza się. Jeśli uznać, że powyższe to naturalny ciąg zdarzeń, to można zaryzykować stwierdzenie, że skoro ktoś w czymś bierze udział to znaczy, że to akceptuje, mimo tego, że otwarcie tego nie raz nigdy nie przyzna....
Przecież analizę zrobimy sami, a jak nie - to zrobi to dostawca. Tak często rozpoczyna się tak zwana "Droga do klęski". Rzemieślnicy produkujący ?przed Kopernikiem? skomplikowane i kosztowne przyrządy do określania położenia planet i gwiazd z wiadomych powodów nie byli zainteresowani upraszczaniem modelu geocentrycznego i swoich skomplikowanych przyrządów. Dlatego zapewne nie raz jeszcze usłyszę, że dobra analiza to setki stron, tysiące wymagań, miesiące pracy.Jednak dobra analiza to tylko: dziesiątki stron i wymagań, tygodnie pracy ale nie dyktafon a zaawansowane metody, takie jak formalna analiza systemowa oparta na modelach i ich testowaniu.
Prawdopodobnie każdy miał kiedyś wrażenie, że umowa zapewnienia ciągłości działania dla systemów informatycznych - Service Level Agreement (SLA), to wygłodniały i bezduszny potwór z paszczą pełną dziewiątek.W artykule Autor skonfrontował technologie trzech największych gigantów w dziedzinie wirtualizacji: Citrix, Vmware oraz Microsoft. Autor przedstawił aspekty związane z zapewnieniem ciągłości działania systemów informatycznych.Tekst zrecenzował Łukasz Przyjemski- Specjalista ds. bezpieczeństwa sieci komputerowych.
Wydarzenie poświęcimy cloud computing ? idei znanej od dłuższego już czasu informatykom. Idei, która, z dnia na dzień, zyskuje coraz szersze grono wyznawców i użytkowników. Zapraszam na mój referat: Cloud computing vs cloud services ? różnice, porównanie usługi w modelu Saas, IaaS, PaaS.
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.
Z serwisów społecznościowych korzysta obecnie ponad 18 mln internautów. Większość z nich udostępniła na swoich profilach przynajmniej podstawowe dane na swój temat, takie jak imię i nazwisko lub miejsce zamieszkania. Wiele osób decyduje się na publikację swojego zdjęcia. Nie wszyscy użytkownicy serwisów mogą sobie zdawać jednak jeszcze sprawę, że wraz z wysłaniem danych na serwery serwisów stają się one własnością serwisów. W połowie zeszłego roku poruszenie wśród internautów wywołała zmiana regulaminu Nk.pl umożliwiająca serwisowi zwiększenie zakresu przetwarzania danych osobowych użytkowników oraz potwierdzenie prawa Nk do wykorzystywania zamieszczanych przez internautów zdjęć i innych materiałów. Zmiany nie odbiegały jednak od standardów stosowanych przez inne portale społecznościowe.
Dlaczego takich analiz wykonuje się mało? No cóż, nie są one w interesie dostawcy, który twierdzi, że jego system np. ERP jest "na pewno dobry". Po drugie wiele firm uznaje, że ich nie dotyczy ryzyko projektowe i pomijają analizy, a te są przecież niczym innym jak obniżeniem ryzyka niepowodzenia takich projektów. Pamiętajmy, że ponad 80% projektów wdrożeniowych w IT to projekty z silnie przekroczonymi budżetami i terminami, część z nich (szacuje się je na ok. 16%) to projekty zaniechane z tego powodu.Każdy z Państwa sam musi sobie odpowiedzieć na pytanie: czy 20% budżetu jest warte tego by chronić pozostałe 80%.
Sam nie raz szukam "czegoś dla siebie" dlatego ucieszyło mnie zestawienie oprogramowania dostępnego dla malutkich. Sam jestem użytkownikiem dwóch z tych aplikacji :) tak więc polecam każdemu "małemu" przepatrzenie tego katalogu rozwiązań.
Tak zwana kastomizacja to gwóźdź do trumny budżetu niejednego projektu, nie da się jej (tego dopasowania) wykonać małym kosztem. Dlaczego? Zmiany w gotowym, złożonym oprogramowaniu to projekt porównywalny czasem z jego wytworzeniem. Jedyne sensowne rozwiązanie w przypadku mniejszych budżetów to wybór gotowego produktu i "nie ruszanie" go, używanie takim jakim jest. Analiza wymagań w takim przypadku to koszt rzędu kilkunastu tysięcy złotych. Zakup gotowego, przeciętnie złożonego produktu, to kolejne kilkanaście tysięcy złotych. Jeżeli zrezygnujemy z "dostosowywania" (a pozwala na to skuteczna analiza i wybór produktu) to pozostaje koszt instalacji oprogramowania i przeszkolenia użytkowników.Jeżeli nasze możliwości nie pozwalają na taki wydatek, można użyć standardowego oprogramowania, którego koszt to ok. kilka tysięcy złotych. Jednak należy się liczyć z tym, że to będzie "zwykły proszek".
Co mogę polecić małym i średnim firmom? No cóż, po takim artykule jak ten z Forbes'a odradzam po raz kolejny proces: wybieram dostawcę rozwiązań IT na bazie jego kompetencji, referencji i "piaru', dostawcą nazywającym siebie samego nie raz partnerem i integratorem rozwiązań. Polecam zdefiniowanie własnej, biznesowej wizji rozwoju, potem sprecyzowanie swoich potrzeb (np. poprzez zbudowanie własnego modelu działania), określenie potrzeb IT i na końcu dopiero wybór dostawcy produktu (oprogramowania), który wesprze realizację tak określonej wizji rozwoju. Należy też bezwzględnie pilnować, by to nasza wizja biznesu była realizowana a nie wizja dostawcy (ten ma swoją, pamiętajmy, że zysk dostawcy jest zawsze naszym kosztem!).
Dlatego hurtownie danych i tak zwane systemy Business Inteligence, wszelkie systemy wspomagania decyzji, to albo analiza historii albo prognozowanie oparte na modelach. Owszem analiza historii to także analiza korelacji ale to inny temat :). W kwestii marketingu lepiej jest, moim zdaniem, opracować model zjawiska, jednak do tego nie potrzebne są duże ilości danych a jedynie minimalny [[zestaw danych reprezentatywnych]] i to się nazywa zasadą ekonomii myślenia. Wielką zaś sztuką projektowania hurtowni danych dla systemów BI, nie jest samo gromadzenie danych a właśnie ich odsiewanie, dlatego systemy analityczne integrowane z systemami CRM bywają czasem bardziej szkodliwe niż pomocne.
