2015 – Strona 4 – Jarosław Żeliński IT-Consulting

Rezygnujemy z waterfall bo agile jest lepsze. Co to znaczy i skąd to wiemy? Czyli widły Hume?a.

Post author:Jarosław Żeliński
Post published:18 czerwca 2015
Post category:Analizy biznesowa i projektowanie oprogramowania
Post comments:2 komentarze
Post last modified:17 czerwca 2024

11 go czerwca wygłosiłem referat inaugurujący targi IT Future Expo, dla tych którzy nie mogli być wtedy na sali :): http://www.slideshare.net/zelinski/j-elinski-rezygnujemy-z-waterfall Więcej o targach: II edycja IT Future Expo już za nami! Kolejny raz Warszawa stała się stolicą IT za sprawą targów IT Future Expo, które odbyły się w dniach 10-11 czerwca 2015 na Stadionie Narodowym. To największa impreza targowa B2B branży informatycznej w Polsce. Zaskakujące pomysły Wystawców, konkursy, gry i wspaniałe prezentacje przyciągnęły wielu Zwiedzających! Targi zorganizowane zostały pod honorowym patronatem Ministerstwa Gospodarki, Marszałka Województwa Mazowieckiego oraz Polskiej Izby…

Czytaj dalej

Systemowo o rentowności czyli właściwe granice systemu

Post author:Jarosław Żeliński
Post published:12 czerwca 2015
Post category:Analizy biznesowa i projektowanie oprogramowania
Post comments:0 Komentarzy
Post last modified:27 czerwca 2021

Wyznaczenie granicy (pod)systemu to rola analityka i architekta systemów. Szkoda, że tak rzadko się korzysta z tej specjalności. Być może nie zlikwidowany by tak wielu lokalnych połączeń kolejowych uznając, że stanowią one razem system a w pojedynkę są niesamodzielne. Pewnie uznanie, że nie sam Zakład Komunikacji Miejskiej a właśnie miasto i jego infrastruktura razem stanowi system, który należy oceniać i rozwijać. "Darmowe autobusy mają pomóc odkorkować Bełchatów" czyli może jednak łączymy jakimś związkiem w jeden system dostępność komunikacji miejskiej, liczbę prywatnych samochodów osobowych, koszty zanieczyszczenia atmosfery, koszt budowy parkingów i poszerzania ulic.

Czytaj dalej

Różne perspektywy wymagań

Post author:Jarosław Żeliński
Post published:8 czerwca 2015
Post category:Analizy biznesowa i projektowanie oprogramowania
Post comments:0 Komentarzy
Post last modified:15 lutego 2022

Nie powinniśmy zapominać, że model Kruchtena to połowa lat 90-tych, szczyt rozkwitu metod strukturalnych i raczkujące metody i narzędzia obiektowe. To stare systemy i ich relacyjne bazy danych wymusiły stosowanie [[mapowania ORM]] i takich narzędzi jak [[Hibernate]]. Dzisiaj mamy rok 2015, od tamtej pory minęło 20 lat. Nie musimy się cofać do początków inżynierii oprogramowania w wersji obiektowej. Coś takiego jak perspektywa danych to anachronizm. Podejście to w 100% zostały już dawno zastąpione przez MDA.

Czytaj dalej

Agile Modeling. Effective Practices for Modeling and Documentation

Post author:Jarosław Żeliński
Post published:27 maja 2015
Post category:Analizy biznesowa i projektowanie oprogramowania
Post comments:1 Komentarz
Post last modified:31 maja 2015

Co prawda książka ma 12 lat i trzeba brać na to lekka poprawkę, jednak jest to wartościowa, nafaszerowana diagramami UML, książka traktująca o tym, że zwinność nie oznacza bałaganu i pospolitego ruszenia. Scott Ambler to kolejny autorytet w inżynierii oprogramowania. I mimo, że nikogo nie ma sensu małpować, na pewno warto się uczyć... Agile Modeling (AM) is a practice-based methodology for effective modeling and documentation of software-based systems. At a high level AM is a collection of best practices, depicted in the pattern language map below (click on the practice…

Czytaj dalej

Software Architecture in Practice

Post author:Jarosław Żeliński
Post published:27 maja 2015
Post category:Analizy biznesowa i projektowanie oprogramowania
Post comments:0 Komentarzy
Post last modified:27 maja 2015

Jednym z moich niedawnych nabytków jest bardzo wartościowa książka, jednak nie jest to podręcznik analizy i modelowania, a opis wieloletnich doświadczeń autorów w tworzeniu i dokumentowaniu architektury oprogramowania. The authors have structured this edition around the concept of architecture influence cycles. Each cycle shows how architecture influences, and is influenced by, a particular context in which architecture plays a critical role. Contexts include technical environment, the life cycle of a project, an organization?s business profile, and the architect?s professional practices. The authors also have greatly expanded their treatment of quality…

Czytaj dalej

Systemowo o ekonomii czyli modele biznesowe

Post author:Jarosław Żeliński
Post published:23 maja 2015
Post category:Analizy biznesowa i projektowanie oprogramowania
Post comments:0 Komentarzy
Post last modified:11 maja 2016

Tak więc OK, przemyciłem tu (mam nadzieję) ważne informacje: - sama struktura to nie model, - tworząc jakikolwiek model musimy rozumieć i opisać jego zachowanie, opisać mechanizm działania (zachowanie) każdego elementu tej struktury, - dlatego model dziedziny systemu, czy w ogóle model jakiegokolwiek systemu, to tak na prawdę obiektowy model, który nie może być modelem anemicznym ([[anemiczny model dziedziny]]), - bez zrozumienia mechanizmu działania organizacji, wprowadzając do niej jakiekolwiek zmiany, szczególnie wdrażając oprogramowanie, raczej jej zaszkodzicie niż pomożecie.(dlatego też, diagramy ERD i tak zwane modele danych, pozbawione funkcji, nie są modelami czegokolwiek a jedynie określonym strukturami).

Czytaj dalej

Effective software delivery. White paper. May 2009

Krzywe i koszty… architektury

Post author:Jarosław Żeliński
Post published:21 maja 2015
Post category:Analizy biznesowa i projektowanie oprogramowania
Post comments:0 Komentarzy
Post last modified:27 października 2021

Niestety wiele systemów ERP i i nie tylko, powstało w latach 90'tych, mają one niestety scentralizowaną architekturę strukturalną (jedna baza danych i "nad nią" funkcje przetwarzające te dane). Efekty tego widać przy wdrożeniach, w których dopuszczono tak zwaną kastomizacje systemu, czyli właśnie wprowadzanie, nie raz bardzo wielu, zmian. To bardzo kosztowne projekty o praktycznie nieprzewidywalnym budżecie. Niestety współdzielenie danych wewnątrz takiego systemu jest jego poważną wadą a nie - jak to zachwalają ich dostawcy - zaletą...

Czytaj dalej

SBVR czyli reguły biznesowe i słownik

Post author:Jarosław Żeliński
Post published:17 maja 2015
Post category:Analizy biznesowa i projektowanie oprogramowania
Post comments:2 komentarze
Post last modified:13 maja 2016

SBVR to specyfikacja opisująca tworzenie modeli pojęciowych, słowników pojęć i reguł biznesowych. Aktualną wersje specyfikacji można pobrać tu: Semantics Of Business Vocabulary And Rules (SBVR)The current version is found at Formal Versions Of SBVR (Źródło: SBVR) A dzisiaj kilka słów na temat aneksu: Annex F - The Business Rules Approach i związku modeli pojęciowych z regułami biznesowymi. Aneks zawiera wyciąg kluczowych punktów Manifestu Reguł Biznesowych (kluczowe punkty): Pierwszoplanowe, a nie wtórne, wymagania 1.1. Reguły są pierwszoplanowymi obywatelami świata wymagań. 1.2. Reguły są kluczowe dla modeli biznesowych oraz technologicznych, stanowiąc jednocześnie ich autonomiczną część. Oddzielone od procesów, a nie…

Czytaj dalej

Zdalna analiza wymagań

Post author:Jarosław Żeliński
Post published:10 maja 2015
Post category:Analizy biznesowa i projektowanie oprogramowania
Post comments:2 komentarze
Post last modified:11 marca 2024

Wprowadzenie Całkiem niedawno wpadł mi w oczy artykuł na temat zdalnego prowadzenia analizy, ostatni jego akapit brzmi: Virtual communication and facilitation skills will remain a key competency for BAs for years to come. Stop torturing your stakeholders with boring, ineffective conference calls. Find new and creative ways to alleviate the common pain points. Please share your virtual facilitation tips in the comments below! (Business Analyst | Virtual Requirements Meetings: Painful or Practical?). (w uproszczeniu: zdalnie prowadzona analiza to kluczowa przyszła kompetencja analityków, warto przestać torturować ludzi wielogodzinnymi nudnymi spotkaniami, znajdź…

Czytaj dalej

Tablice decyzyjne – siła reguł biznesowych

Post author:Jarosław Żeliński
Post published:9 maja 2015
Post category:Analizy biznesowa i projektowanie oprogramowania
Post comments:0 Komentarzy
Post last modified:4 października 2023

Wprowadzenie Regularnie widuję monstrualne diagramy, na których ich autorzy usiłują modelować decyzje podejmowane w toku przepływu pracy. Pierwsze nieporozumienie (i duży błąd pojęciowy) na tych diagramach, to łączenie na jednym diagramie elementów procesu biznesowego, z tym jaka "praca myślowa" wykonawcy ma być w danym procesie (aktywności) wykonana. Drugi błąd to mieszanie poziomów abstrakcji: proces biznesowy to dość duży poziom ogólności (uogólnienia), jego celem jest pokazanie celowości łańcucha pracy (procesy biznesowe to aktywności tworzące produkty) a nie tego, jak jest w detalach wykonywana: wnętrze tych aktywności - ich szczegóły - na…

Czytaj dalej

Kim jest product owner?

Post author:Jarosław Żeliński
Post published:30 kwietnia 2015
Post category:Analizy biznesowa i projektowanie oprogramowania
Post comments:2 komentarze
Post last modified:15 sierpnia 2015

Wczoraj podczas spotkania, miałem ciekawą rozmowę z przedstawicielami jednego z producentów systemów ERP. Okazało się, że mają bardzo podobne do moich doświadczenia i wnioski: podczas wdrożenia systemu ERP potrzebny im jest ktoś, jeden, kto zna i rozumie jak działa dana firma, a nie setki stron dokumentacji czy stenogramy z dziesiątków godzin warsztatów z przyszłymi użytkownikami. Do tego firma ta - nabywca systemu ERP - powinna mieć, nie szczegółowo opisane dziesiątki detalicznie opisanych procesów i ich wariantów, procedur czy setki i tysiące nie raz wymagań, a strategię i taktykę, z której wynika…

Czytaj dalej

Agile Product Management with Scrum

Post author:Jarosław Żeliński
Post published:30 kwietnia 2015
Post category:Analizy biznesowa i projektowanie oprogramowania
Post comments:1 Komentarz
Post last modified:17 czerwca 2023

Cóż, kolejny raz odkrywam, że jestem zwinny :). A tak poważnie, obserwuję stygnięcie ideologii zwinnych metod i przechodzenie od dogmatów do praktyki. Niewątpliwie otoczenie rynkowe zmienia się szybko i metody strukturalne, tak, te z lat 80'tych polegające na wnikliwej i czasochłonnej analizie i budowie całościowego relacyjnego modelu danych dla systemu i projektowaniu listy jego funkcji, to faktycznie "wodospadowe" złe podejście. Tego nikt rozsądny nie neguje. Zwinność jednak, to nie "rezygnacja z pracochłonnej dokumentacji" (często to właśnie słyszę), a uznanie, że oprogramowanie powinno powstawać relatywnie małymi krokami, przyrostowo. I tyle, nie…

Czytaj dalej

Koniec treści

Nie ma więcej stron do załadowania

Nowsze wpisy

Starsze wpisy