Archiwalne tagi dobre praktyki

Jednym z celów modelowania jest przedstawienie złożonych zagadnień na takim poziomie abstrakcji, który pozwoli zrozumieć dany aspekt zagadnienia. Gdy w organizacji modele są przygotowywane przez kilka, kilkanaście osób to warto jest ustalić dwie rzeczy:  zasady modelowania i estetykę diagramów. Zasady modelowania określą  nam to co i w jaki sposób dokumentujemy, jaką notację zastosujemy. Estetyka diagramów to ustalenie pewnych zasad, które pozwolą…

Ian Sommerville i Pete Sawyer w "Requirements Engineering: A Good Practice Guide" opisali, ponad 15 lat temu, metodę oceny i doskonalenia procesów inżynierii wymagań. Opiera się ona na wyodrębnieniu dobrych praktyk, czyli czynności będących pożądanymi elementami wzorcowego procesu inżynierii wymagań. Autorzy starali się przy tym objąć całość problematyki inżynierii wymagań. W moim mniemaniu te dobre praktyki nie tracą na aktualności.…

Jak wynika z poglądowych badań przeprowadzonych we wrześniu 2015 r. średnia zarobków architektów korporacyjnych w Polsce wynosi brutto 15.300 zł (przy medianie 13.000 zł brutto). Dla porównania średnie zarobki analityków wynoszą 11.100 zł brutto). Badania te potwierdziły również przypuszczenie, że sporo polskich organizacji wdrożyło już u siebie wybrane mechanizmy zarządzania architekturą IT/korporacyjną. Jednocześnie obecnie z coraz większej liczby firm dochodzą…

Myśląc o modelowaniu architektury korporacyjnej bardzo często rozważa się wybór narzędzia do modelowania. Jednym z naturalnych kandydatów jest Enterprise Architect. Kandydatura Enterprise Architect'a bierze się zazwyczaj z faktu, że jest ona wykorzystywane przez szeroko rozumiane IT. IT dość często, w ramach inicjatywy oddolnej, próbuje wdrożyć elementy architektury korporacyjnej. Wspomniana powyżej sytuacja nie jest, w moim odczuciu, do końca idealna. W…

Dwa tygodnie temu w poście poście Moje ulubione perspektywy w architekturze korporacyjnej przedstawiłem kilka diagramów opisujących architekturę korporacyjną z różnych perspektyw. Opisane perspektywy obejmowały architekturę biznesową, architekturę systemów informatycznych oraz architekturę technologiczną. Oprócz tego zaprezentowałem kilka diagramów prezentujących mapowania pomiędzy powyżej wymienionymi architekturami. W dzisiejszym wpisie postaram się zaprezentować mapowania artefaktów architektury korporacyjnej na wymagania architektoniczne, model procesów biznesowych oraz modele systemów…

Na moich stronach przedstawiłem szereg perspektyw Archimate (https://www.michalwolski.pl/archimate-2-0/perspektywy/). Użycie ich wszystkich w danej organizacji jest oczywistym nieporozumieniem. Niejednokrotnie pisałem o tym, że w każdym projekcie należy wybrać kilka diagramów za pomocą których, zostanie opisany system. W przypadku Archimate - naczelnego języka do opisu architektury korporacyjnej, takie perspektywy (diagramy) należy wybrać również. Dziś postanowiłem podzielić się moimi ulubionymi perspektywami jakimi opisuję artefakty związane…

W 2009 roku zamieściłem linki do metodyk online. Dziś robiłem drobne porządki i stwierdziłem, że linki są nieaktywne. Zaktualizowałem je w poście z 2009 roku oraz dodałem Agile Business Rule Development Scrum OpenUP Extreme Programming Agile Business Rule Development Uwaga zdarza się, że niektóre przeglądarki nie otwierają tych metodyk. Firefox sprawia najmniej problemów. Miłego korzystania :)

Wpisy na temat inżynierii wymagań zacznę od podstawowych definicji.

Definicja: Wymaganie

1.Ograniczenie lub zdolność potrzebna użytkownikowi do rozwiązania problemu lub osiągnięcia określonego celu.

2.Ograniczenie lub zdolność, które musi być spełnione lub zrealizowane przez system lub składnik systemu w celu spełnienia warunków umowy, standardu, specyfikacji lub innych formalnych dokumentów.

3.Udokumentowana reprezentacja ograniczeń i zdolności określonych w punkcie 1 i 2.

Proces tworzenia oprogramowania można traktować jako rurociąg z żądaniami funkcji wchodzącymi z jednej strony i lepszym oprogramowaniem wychodzącym z drugiej.

Wewnątrz rurociągu, istnieje pewien rodzaj procesu, który może wahać się od nieformalnego procesu ad hoc do bardzo formalnego etapowego procesu. W tym artykule, założymy prosty proces fazowy: (1) analiza wymogów, (2) opracowanie kodu i (3) testowanie jego pracy.

Efekt wąskich gardeł

Wąskie gardło w rurociągu ogranicza przepływ. Przepustowość całego rurociągu jest ograniczona do przepustowości wąskiego gardła.

Jako przykład wykorzystamy nasz rurociąg tworzenia: jeśli testerzy są w stanie przetestować 5 funkcji w tygodniu, podczas gdy programiści i analitycy są w stanie wyprodukować 10 funkcji w tygodniu, przepustowość całego rurociągu wyniesie tylko 5 funkcji w tygodniu, gdyż testerzy działają jako wąskie gardło.

Jeśli analitycy i programiści nie zdadzą sobie sprawy, że testerzy stanowią wąskie gardło, wtedy przed testerami piętrzyć się będą zaległości w pracy.

clip_image001

W wyniku tego, czas realizacji zwiększy się. Jak zapasy w magazynie, praca stojąca w rurociągu zamrozi inwestycję, stworzy dystans z rynkiem i z czasem spadnie na wartości.

Kanban jest procesem ewolucyjnym lub sposobem dokonywania zmian ewolucyjnych w celu poprawy obecnie stosowanych procesów, nawet Scrum!Mimo tego, iż Scrum cieszy się wielkim powodzeniem i zastosowaniem na całym świecie, wiele zespołów i organizacji miało problemy z wdrożeniem wszystkich jej aspektów.  Problemy te mogły być związane ze zmianami organizacyjnymi i ról lub niemożnością sprostania iteracji lub dotrzymania zobowiązań dotyczących zakresu i…

Close