Czy dobra analiza gryzie się z agile?
Niezwykle rzadko to robię, ale bywa: tylko cytat i zachęta do lektory całości :) Agile Manifesto Individuals and interactions over processes and tools. Dobry analityk posiada zestaw narzędzi, z kórych…
Inżynieria systemów oparta na modelach (MBSE) jest sformalizowaną metodologią, która jest używana do wspierania wymagań, projektowania, analizy, weryfikacji i walidacji związanych z rozwojem złożonych systemów. W przeciwieństwie do inżynierii skoncentrowanej na dokumentach, MBSE stawia modele w centrum projektowania systemu. Zwiększone przyjęcie środowisk modelowania cyfrowego w ciągu ostatnich kilku lat doprowadziło do zwiększonego przyjęcia MBSE. W styczniu 2020 roku NASA odnotowała ten trend, informując, że MBSE “jest coraz częściej przyjmowane zarówno przez przemysł, jak i rząd jako sposób na śledzenie złożoności systemu.” W tym wpisie na blogu przedstawiam krótkie wprowadzenie do MBSE.
Najczęściej popełniane błędy podczas wdrożenia ERP
Przy piątku naszło mnie na zestawienie pewnych treści (cytaty). Podczas codziennej "prasówki" wpadłem na artykuł "Najczęściej popełniane błędy podczas wdrożenia ERP", oto cytat pierwszy: - Największym błędem popełnianym przy wdrożeniach…
Wszystkie drogi prowadzą do Rzymu – zarządzanie jakością
... spotykam się jednak w literaturze z tezami, że wdrożenie jakichkolwiek norm, nie tylko jakości, powinno być także poprzedzone analizą. Innymi słowy normy jakości powinny być wdrażane jako odpowiedź (rozwiązanie) na określone wymagania, a nie dla samego faktu ich wdrażania. Owszem, bywa, że wymaganiem jest np. wymóg przetargowy (oferty mogą składać tylko firmy mające określony certyfikat), jednak moda na jakość, mimo że nie przeminęła całkowicie, powoli przechodzi w racjonalne powody wdrażania norm jakości.
Niski poziom analizy…
Niestety źle dobrany system informatyczny, mający wspierać/automatyzować czynności w procesie, może być powodem powstania całych podręczników procedur nieuzasadnionych biznesowo, dedykowanych użytkownikom tego systemu, stwarzając przy tym pozory, że to sam proces jest ich źródłem :( Niestety tak się często kończą projekty, w których pomięto analizę i projektowanie i od razu wybrano dostawcę i produkt (analiza wykonana przez dostawce to raczej "jak wdrożyć to co mamy" a nie "jak rozwiązać problem użytkownika"). Problemem większości projektów IT jest założenie, że tylko dostawca/wykonawca usługi ma wiedzę o tym jak to zrobić. Tezę tę forsują najczęściej własnie wykonawcy (developerzy), a problem polega na tym, że wykonawca dąży tu do sytuacji gdy sam sobie stawia wymagania a potem rozlicza ich realizację.
Ach ten przypadek użycia czyli filozofia
Dzisiaj co nieco o filozofii i przypadkach użycia. Dzielenie przypadków użycia na "rodzaje" zawsze budziło mój sprzeciw, w UML (w oryginale) mamy jedno pojęcie: "przypadek użycia systemu", gdzie systemem jest…
- Go to the previous page
- 1
- …
- 85
- 86
- 87
- 88
- 89
- 90
- 91
- …
- 170
- Go to the next page