O MVP słyszy się często wśród analityków. MVP to Minimum Viable Product, czyli minimalnie wykonywalny produkt. Tłumaczenie nie jest doskonałe, dlatego też dalej będę pisał o MVP. Pojęcie MVP pojawiło się po raz pierwszy w 2001 roku. Jego autorem jest Frank Robinson. Natomiast w 2011 roku Eric Ries, swoją książką Metoda Lean Startup spopularyzował to […]
MVP, czyli o zwinnym podejściu do zakresu przedsięwzięcia Czytaj dalej »
W poprzednim artykule Modelowanie zagrożeń – teoretycznie przedstawiłem założenia do przygotowania modelu zagrożeń. W tym artykule zaprezentuję jak za pomocą Enterprise Architect przygotować model zagrożeń. Wykorzystam do tego Threat Modeling Diagram – dostępny od wersji 15.1. Opis będzie obejmował: utworzenie diagramów przepływu danych (DFD) modelowanej aplikacji, ustalenie typów zagrożeń, rozpoznanie zagrożeń dla systemu, ustalenie ryzyka,
Modelowanie zagrożeń – praktycznie Czytaj dalej »
Wprowadzenie Każda firma lub instytucja wytwarzająca oprogramowanie powinna przeanalizować wymagania dotyczące bezpieczeństwa stawiane przed ich aplikacjami. Jedną z metod wspomagających wspomnianą analizę jest zastosowanie takich technik, które będą już w fazie projektowania, umożliwiały przeciwdziałanie zagrożeniom. Należy zauważyć, iż im bardziej konkretny produkt jest wystawiony na potencjalne zagrożenia oraz im bardziej wartościowe informacje przetwarza, tym większe
Modelowanie zagrożeń – teoretycznie Czytaj dalej »
W co większych firmach lub przy okazji dużych przedsięwzięć zwanych projektami, analitycy to nie jedna lub dwie osoby a grupa ludzi, która opracowuje wymagania, procesy biznesowe, specyfikuje wymagania. Ta grupa ludzi współpracuje z projektantami, programistami oraz ogólnie rozumianym biznesem. W takich organizacjach obserwuję dwa różne sposoby działania. Jeden, w którym nie ma opracowanych zasad modelowania
Zasada TAO w procesie wytwórczym oprogramowania Czytaj dalej »
W tym roku Sparx Systems udostępnił kolejną wersję swojego sztandarowego produktu. Enterprise Architect 15 pojawił się w sierpniu. W tym wpisie zamieszam subiektywny przegląd najważniejszych zmian i nowości. Co nowego? Enterprise Architect 15 – wygląd Po pierwsze ikony w Project Browser a raczej teraz Browser mają bardziej słomkowy odcień. Poprawiono generalnie jakość wszystkich ikonkek by
Enterprise Architect 15 Czytaj dalej »
W ostatnim wpisie opisałem co myślę o roli analityka w podejściu zwinnym. Drugą rolą, o której chciałbym wspomnieć jest rola architekta. Rola ta określona jest w klasycznym podejściu do wytwarzania oprogramowania. Natomiast w zwinnym podejściu o architekturze i architektach nie wspomina się zbyt wiele. Jedynie w założeniach manifestu programowania zwinnego pojawia się (podkreślenia moje): Najlepsze
Architekt w podejściu zwinnym Czytaj dalej »
Rola analityka i znaczenie analizy w wielu organizacjach umacnia się a w innych zanika. Dość często tam, gdzie pojawia się zwinne podejście rola analityka jest trudna do zdefiniowania. W manifeście programowania zwinnego (http://agilemanifesto.org/iso/pl/manifesto.html) można przeczytać: W wyniku naszej pracy, zaczęliśmy bardziej cenić: Ludzi i interakcje od procesów i narzędzi Działające oprogramowanie od szczegółowej dokumentacji Współpracę
Analityk w podejściu zwinnym Czytaj dalej »
Nie da się ukryć, że praca na Enterprise Architect to czasem niemałe wyzwanie. Zwłaszcza publikacja diagramów sprawia spory problem. Nie bez przyczyny też opublikowałem specjalne kurs, który mówi o tym, jak raportować z Enterprise Architect. Myślę, że powoli ta sytuacja zmienia się na lepsze. Już ponad rok temu Sparx Systems wypuścił na rynek rozwiązanie, które
Enterprise Architect Pro Cloud Server – modelowanie w chmurze Czytaj dalej »
Wiele się mówi o potrzebie identyfikacji celów projektowych, celów organizacji a także o potrzebie identyfikacji wymagań biznesowych oraz systemowych. Wszystko po to by lepiej zrozumieć oczekiwania biznesu (interesariuszy) w kontekście tego co ma być zrobione, na czym ma polegać zmiana, co ma być wynikiem realizacji projektu. Wymienione powyżej elementy mają finalnie być uszczegółowione wymaganiami na system.
Wymagania biznesowe a wymagania systemowe Czytaj dalej »
Wytwarzanie oprogramowania to proces, w którym przeglądy stanu realizacji prac są sytuacją codzienną lub prawie codzienną. Weryfikacja prac analitycznych i projektowych a także architektonicznych, to nie tylko pytanie co zostało zrobione, ale także pytania: jak to zostało zrobione? Jak to będzie działało? W tych procesach wytwórczych, w których specyfikacja jest przygotowywana w postaci modeli, diagramów i innych
Przegląd modeli w Enterprise Architect Czytaj dalej »
