Inżynieria oprogramowania z użyciem narzędzia CASE – przykładowy projekt Biblioteka

W dniu 11.12.2020, udało mi się w końcu przeprowadzić prezentację on-line. Celem była prezentacja realizacji metody MBSE z narzędziem CASE (tu Visual-Paradigm) i jej efektów. Adresatem są zarówno analitycy, architekci oprogramowana jak i developer (programiści) jako ostateczny adresat dokumentu. Podobną prezentację prowadziłem wcześniej na Konferencji beIT 2020. Popularność tych prezentacji spowodowała, że całość przerodziła się w projekt badawczy.

(więcej…)

Czytaj dalejInżynieria oprogramowania z użyciem narzędzia CASE – przykładowy projekt Biblioteka

MDE czyli Model Driven Engineering

MDE to skrót od Model Driven Engineering, nazwy ogólnego trendu w świecie inżynierii. Od pewnego już czasu  da się zaobserwować, że ludzie i ich umiejętności nie nadążają za złożonością systemów... Nie jest to jakieś wielkie odkrycie, bo problem ten wystąpił w inżynierii maszyn kilkadziesiąt lat temu... mniej więcej w czasie gdy zaczęły się pojawiać pierwsze samochody, potem było już coraz gorzej: liczba detali maszyn idzie w tysiące  (pojazdy) a nie raz i miliony (samoloty pasażerskie, pociągi). Jedynym sposobem zapanowania nad złożonością obecnych konsytuacji inżynierskich jest redukcja złożoności ich opisów, a…

Czytaj dalejMDE czyli Model Driven Engineering

Przypadki użycia czy model procesu, czego używać?

Dość często spotykam sie z tezami, że użycie przypadków użycia nie wymaga modelowania procesów i odwrotnie, albo że są to "narzędzia" oferujące podobne lub takie same korzyści, np. tak jak tu: So, as you can see we used different techniques and basically the result is the same. It was not really important what techniques were used unless solution design is complete. It?s just a matter of a habit so if you?re more comfortable with use cases then stick to them or if you?re more familiar with process maps then draw…

Czytaj dalejPrzypadki użycia czy model procesu, czego używać?
computer model real world
Smith, B. C. (1985). Computers, Models, and the Embedding World, The Limits of Correctness. SIGCAS Comput. Soc., 14,15(1,2,3,4), 18?26. doi: 10.1145/379486.379512

Czynniki sukcesu w projektach programistycznych

Pojawia się próba diagnozy. Pełna tak zwana śladowalność wymagań (nazwana tu hipertracebility) jest podobno kosztowna i trudna do utrzymania. Zaraz potem: niedbałość w definiowaniu wymagań - no to w końcu dokładnie czy nie? Kolej na analityków: zrzucanie odpowiedzialności ? analitycy tworzą dokument wymagań i wypychają go do programistów. Oczywiście jest to problem, co z tym? Analityk powinien ponosić odpowiedzialność za swój produkt do końca projektu. Założenie, że można stworzyć skończony dokument wymagań. Otóż można ale o tym za chwilę. Poza ważnymi elementami zarządzania takim projektem, w tym zarządzaniem zespołem autorzy wskazali jedną z głównych moim zdaniem przyczyn: brak dokumentu HLD (projektu wysokopoziomego).Otóż nie da się czymś tak złożonym jak oprogramowanie (zakładam, że to nie trywialny system), zarządzać na poziomie detalicznych szczegółów.

Czytaj dalejCzynniki sukcesu w projektach programistycznych

Koniec treści

Nie ma więcej stron do załadowania