Miło mi poinformować, że moja publikacja naukowa (tu była zapowiedź) na temat syntezy wzorców architektonicznych i wzorców projektowych, systemów obiektowo-zorientowanych zatytułowana:

Synthesis of MOF, MDA, PIM, MVC, and BCE Notations and Patterns

po długim procesie selekcji i recenzowania, została zakwalifikowana do publikacji i właśnie się ukazała jako jeden z rozdziałów książki:

Applications and Approaches to Object-Oriented Software Design: Emerging Research and Opportunities.

Jeszcze milej mi poinformować, że – jako współautor – mogę Wam zaoferować kod promocyjny dający 40% zniżki na zakup: IGI40.

Poniżej informacje o książce i o wydawcy.

O książce

DescriptionIn today?s modernized environment, a growing number of software companies are changing their traditional engineering approaches in response to the rapid development of computing technologies. As these businesses adopt modern software engineering practices, they face various challenges including the integration of current methodologies and contemporary design models and the refactoring of existing systems using advanced approaches.Applications and Approaches to Object-Oriented Software Design: Emerging Research and Opportunities is a pivotal reference source that provides vital research on the development of modern software practices that impact maintenance, design, and developer productivity. While highlighting topics such as augmented reality, distributed computing, and big data processing, this publication explores the current infrastructure of software systems as well as future advancements. This book is ideally designed for software engineers, IT specialists, data scientists, business professionals, developers, researchers, students, and academicians seeking current research on contemporary software engineering methods. Source: Applications and Approaches to Object-Oriented Software Design: Emerging Research and Opportunities: 9781799821427: Computer Science & IT Books | IGI Global

O wydawcy

IGI Global is a leading international academic publisher committed to facilitating the discovery of pioneering research that enhances and expands the body of knowledge available to the research community. Working in close collaboration with expert researchers and professionals from leading institutions, including Massachusetts Institute of Technology (MIT), Harvard University, Stanford University, University of Cambridge, University of Oxford, Tsinghua University, and Australian National University, IGI Global disseminates quality content across 350+ topics in 11 core subject areas. Source: About IGI Global | IGI Global

Wzorce projektowe to bardzo ważna część “zawodu” analityka i architekta oprogramowania. Dzisiaj kolejny raz studenci pytali o literaturę, więc postanowiłem poszperać na półce. O tym dlaczego powstały wzorce i jak sie je opisuje napisano wiele, nie będę więc powtarzał tego co na prawde łatwo znaleźć. Generalnie wzorce są to skatalogowane standardy i dobre praktyki [zotpressInText item=”{5085975:DQVI65GH}”].

Większość obiektowych wzorców projektowych dotyczy kwestii (rozwiązywania problemów) technologicznych. Myślę, że większość frameworków (zestawy bibliotek środowiskowych) to implementacje wzorców opisanych w książkach wymienionych poniżej [zotpressInText item=”{5085975:8P6M5STE}”]. Warto je więc poznać z tego choćby powodu, by rozumieć jak one działają i dlaczego są takie jakie są. [zotpressInText item=”{5085975:TBT7B5D2},{5085975:NVN9AR49}”]

Nieco później powstały wzorce architektoniczne, takie jak sztandarowy MVC (Model-View-Controller). Te przydają się na etapie analizy i projektowania na wysokim poziomie abstrakcji.

Lektura tych pozycji pokazuje ewolucje pojęcia paradygmatu obiektowego i pojęcia obiektu. Tak zwane “stare”, implementacyjne podejście z początków technik obiektowych pojmowanie definiowało obiekt jako połączenie danych i funkcji. Ta definicja nadal pojawia się u wielu autorów. Obecnie raczej stosujemy definicję mówiącą, że obiekt mają określoną odpowiedzialność, reprezentują określone zachowanie [Shalloway].

Tak więc polecam lekturę poniższych pozycji, duża rezerwę w stosunku do podawanych definicji. Praktycznie wszystkie te książki to wiedza z końca lat 90-tych. Od tamtej pory, zmieniło się wiele detali, jednak ogólna zasada polegająca na hermetyzowaniu wszystkiego co się da i na tym, że obiekt to określona wąska specjalizowana odpowiedzialność, nadal jest na czasie. Historyczna definicja mówiąca, że obiekty to dane i funkcje je przetwarzające, została już nie raz “obalona” za sprawą wzorców takich jak service czy factory, wskazujących że należy z zasady oddzielać odpowiedzialność za utrwalanie danych i odpowiedzialność za ich tworzenie i przetwarzanie.

Tak więc w wolnej chwili zapraszam do lektury, a także do pytań i dyskusji pod tym tekstem.

Literatura

[zotpressInTextBib style=”harvard1″ sort=”ASC”]

Dzisiaj krótko. Frustracja dostawców oprogramowania chyba narasta, bo teksty takie jak poniżej, pojawiają się coraz częściej. Rzecz w tym, że rynek IT to nie tylko firmy ja te, reprezentowane przez autora tego tekstu, który słusznie zauważa, że:

1) Specyfikacje są napisane bardzo ogólnikowo. Trudno rozeznać się co autor miał na myśli.To jeden z największych problemów w IT, znany jako problem huśtawki. Kto bowiem pisze OPZ (Opis Przedmiotu Zamówienia) czy też SIWZ (Specyfikację Istotnych Warunków Zamówienia)? ? najczęściej dostaje to zadanie urzędnik. Urzędnik zarabia znacznie poniżej średniej w branży IT. Nawet jeśli to informatyk, na co przy zarobkach urzędników szansa jest minimalna) to jest mała szansa, że zna się i na stronach internetowych, aplikacjach mobilnych, hostingu i wszystkich rozwiązaniach SaaS. Pierwsza opcja to, że przeklei to co znajdzie w internecie (w innych przetargach). Druga opcja, to że wybierze dostawce i dostanie specyfikację od niego. A zapewniam Was, że dostawca zadba, by w OPZ czy SIWZ znalazły się zapisy preferujące jego rozwiązanie. Istnieje opcja trzecia, czyli wynajęcie niezależnego konsultanta. Zdarzało mi się być w takiej roli. Naprawdę tylko bardzo świadomi klienci wiedzą, że niezależny konsultant musi być dobrze wynagradzany za swoją niezależność i ekspercką wiedzę. Dostępność konsultantów jest też bardzo niewielka a mało która instytucja ma na nich przewidziane budżety. (źr: Milion złotych za stronę www. Jak wyglądają przetargi? | INNPoland.pl).

Od siebie dodam, że w moich oczach to nie tyle problem w wynagrodzeniu urzędnika, a w tym, że pisanie OPZ to nie jest jego rola i kompetencja. Literatura przedmiotu (rola urzędu w Państwie) zawiera wiele różnych rozważań na ten temat,

ja jednak zgadzam z autorami, którzy twierdzą, że rolą urzędu jest wykonywanie prawa i wszelkie działania urzędnika powinny być stosowaniem prawa. Jeżeli jakieś działanie nie jest stosowaniem prawa, urzędnik powinien zasięgać opinii biegłego.

Urzędnicy (referenci) powinni być z wykształcenia prawnikami (prawo administracyjne) z powodów oczywistych: stosowanie prawa wymaga jego rozumienia. Polecam doskonały artykuł, którego fragment zacytuję:

Jeżeli twój prawnik rozumie kontrakt lepiej niż twoi ludzie z biznesu, oznacza to że zarówno prawnik może mieć problem z tłumaczeniem prawnych komponentów całej transakcji, ale także że twój biznes w niewłaściwy sposób komunikuje prawnikowi cele i założenia biznesu, którego umowa dotyczy. Może czas coś z tym zrobić? (źr.  https://www.linkedin.com/pulse/tw%C3%B3j-prawnik-rozumie-kontrakt-lepiej-ni%C5%BC-twoi-ludzie-warchol-lewicka/ )

W sądzie sprawa jest “czysta”: sędzia nie może wydawać opinii innych niż prawne, kwestie specjalistyczne musi zlecać biegłemu (dowód z opinii biegłego).

Ludziom wmówiono, że osobą właściwą do opisu wymagań na oprogramowanie jest przyszły użytkownik. Nic bardziej błędnego: ma on takim sam konflikt interesu jak dostawca oprogramowania. Swego czasu pisałem:

Ogłaszający taki przetarg zapłaci za:

1. prawo korzystania z Aplikacji (w ustalonej firmie np. licencji),
2. wszelkie konieczne usługi poprzedzające normalne użytkowanie Aplikacji,
3. jeżeli na rynku nie jest oferowane wymagane oprogramowanie, zostanie ono ?napisane? na podstawie Specyfikacji specjalnie dla Zamawiającego.

[…] To co nazy­wa­my Opi­sem Przed­mio­tu Zamó­wie­nia jest czymś wię­cej niż tyl­ko Spe­cy­fi­ka­cja opro­gra­mo­wa­nia. Dobrą prak­ty­ką jest roz­dzie­la­nie tych trzech powyż­szych ele­men­tów, ogrom­ną wygo­dą jest jeże­li są to odręb­ne umo­wy lub odręb­ne załącz­ni­ki Umo­wy głów­nej. Spla­ta­nie razem tych aspek­tów naj­czę­ściej pro­wa­dzi do nie­po­ro­zu­mień, pro­ble­mów z inter­pre­ta­cją umo­wy w cza­sie spo­rów. W skąd­inąd cie­ka­wym arty­ku­le pew­na kan­ce­la­ria wska­zu­je przy­czy­ny, a jako roz­wią­za­nie pro­ble­mu wska­zu­je jedy­nie pra­wo do wyco­fa­nia sie z umo­wy:Nie ma recep­ty na popraw­ne opi­sa­nie przed­mio­tu świad­cze­nia. Jeśli mamy roz­bu­do­wa­ne, pre­cy­zyj­ne spe­cy­fi­ka­cje, to i tak musi­my w umo­wie opi­sać zarzą­dza­nie zmia­ną, ze szcze­gól­nym uwzględ­nie­niem roli ana­li­zy. (źr. Przedmiot Zamówienia – instrukcja nie tylko dla prawników, na zupę pomidorową | | Jarosław Żeliński IT-Consulting)

Biorąc pod uwagę powyższe oraz to, że mowa tu o produktach inżynierskich (oprogramowanie) rekomenduje się:

1. Opracowanie OPZ w postaci precyzyjnych schematów blokowych i wzorów matematycznych, jest zawsze lepsze niż niejednoznaczny opis wykonany językiem naturalnym, ten może być co najwyżej uzupełnieniem lub komentarzem. Ideałem jest tu precyzyjna dokumentacja techniczna (projekt techniczny). Należy pamiętać, że taki OPZ (w odróżnieniu od SIWZ) jest zawsze przedmiotem prawa autorskiego (Koralewski, 2014).^*
2. OPZ, będący dokumentem technicznym, specjalistycznym, nie musi być zrozumiały dla prawnika, a nie raz nawet dla samego Zamawiającego.
3. Jeżeli sam zamawiający nie potrafi stworzyć poprawnego OPZ, powinien najpierw zlecić usługę opracowania OPZ, a potem dopiero szukać dostawcy tego, co opisano w tym OPZ. (Urząd Zamówień Publicznych, 2009).
4. Usługa techniczna, oczekiwany sposób jej świadczenia, i jakość, to także przedmiot zamówienia, skuteczną praktyką jest więc umieszczenie ich opisu w OPZ a nie w treści umowy.(Urząd Zamówień Publicznych, 2009)

Nieco ponad dwa lata temu napisałem, że od lat stosuję w swoich analizach i projektach (między innymi) różnego rodzaju diagramy. Pomagają one ustalić precyzyjnie wszelkie aspekty i prawne i projektowe (źr. Opis przedmiotu zamówienia | | Jarosław Żeliński IT-Consulting)

Powyższe to kilka zebranych myśli, w odpowiedzi na tekst autora cytowany na początku. Ja adresuję ten tekst Zamawiającym, bo to oni są beneficjentami tego co zamawiają i są także sponsorami swoich, niejednokrotnie, porażek. Jak słusznie zauważa autor: na własne życzenie.

No to mamy kolejna wersję narzędzia pracy. Używam VP od 2005 roku i nadal nie mam powodu by zmieniać narzędzie, mimo tego, że od lat na szkoleniach i u klientów, mam do czynienia chyba ze wszystkim co świat proponuje ;).

Daleki jestem od opisywania tu menu tego pakietu, jest dość duże (ale nie aż tak by się gubić). Jest kontekstowe więc nie przeraża. Kluczową cechą VP, która trzyma mnie przy nim jest to, że w projektach nie muszę używać żadnego innego narzędzia. Od czasu gdy pakiet zyskał polską kontrole pisowni, czyli od ponad 6 lat, nie używam standardowego oprogramowania biurowego to kontaktu z klientami i pisania raportów z analiz, dzięki czemu bieżąca aktualizacja dokumentów dla klientów zajmuje minuty a nie dni. Nawet prace naukowe (publikacje) przygotowuję w tym pakiecie.

Kilka ciekawostek

Tabele jako narzędzie opisu modeli w postaci zestawień:

Dla każdego kto lubi narzędzie Business Model Canvas:

Na warsztaty z zarządem wystarczy rzutnik:

Wsparcie w UML dla entuzjastów TOGAF:

Wsparcie dla zarządzania harmonogramem projektu:

Generator formularzy czyli jak zbierać dane od klientów nie robiąc tego mailem:

W dokumentacji nie raz potrzebne są tabele, nie musimy mieć excela…:

Visual Paradigm is pleased to announce version – New features: TOGAF ADM support with ArchiMate 3, project management guide-through process, agile scrum process with story estimation.

Source: What’s New in Visual Paradigm?