1

Analiza Potrzeb i Opracowanie Wymagań na Oprogramowanie

  • Produkt: Opis Przedmiotu Zamówienia (opracowanie specyfikacji SWS) zawierający zarówno udokumentowany Model Biznesowy Organizacji jak i Projekt Techniczny Rozwiązania, realizowany jest także nadzór autorski nad realizacją.
  • Korzyści: ochrona know-how Zamawiającego, kompletne i spójne wymagania wyrażone jako projekt techniczny, obiektywizacja prac wykonawcy.
  • Koszt: wymaga etapu Analiza Biznesowa. (20 tys. zł netto), po zdefiniowaniu wymagań biznesowych i zakresu wdrożenia, opracowywany jest Opis Techniczny Oprogramowania. trwa ok. trzech miesięcy (koszt ok. 20 - do 40 tys. zł netto, zależnie od tego czy planowany jest system gotowy czy dedykowany), dalszy nadzór autorski (bieżące utrzymanie i aktualizację, nadzór merytoryczny nad dostawcą systemu, generowanie na żądanie modeli procesów i systemu z różnych perspektyw, modele dostępne on-line), od 3 tys. zł netto miesięcznie.

ZARZĄDZANIE PROJEKTEM WE WŁASNYM ZAKRESIE JEST KRYTYCZNE: Integratorzy systemów mogą być cennym elementem cyfrowej transformacji, ale nigdy nie powinni mieć całkowitej, niekontrolowanej władzy nad całym przedsięwzięciem (źr. PORAŻKA CYFROWEJ TRANSFORMACJI W FIRMIE HERTZ, oryg. : 4 LESSONS FROM THE HERTZ VS. ACCENTURE DISASTER)

Rolą dostawcy oprogramowania jest dostarczenie i wdrożenie oprogramowania zgodnego z przedstawionymi mu wymaganiami i zapewnienie jego jakości, a nie analiza wymagań kupującego na tle możliwości oferowanego przez siebie produktu. Dlatego wymagania i logiczny projekt rozwiązania powinny być opracowane przed wyborem jego dostawcy.



Wstęp

Kilka faktów:

Niestety same spisane funkcjonalności programu czyli specyfikacja (lista) wymagań funkcjonalnych to wyłącznie idea jego powstania (wyrok SA w Poznaniu z dnia 4 stycznia 1995 r. I ACr 422/94). Precyzję opisu, dającą ochronę w postaci pełnego prawa do powstałego produktu, uzyskuje się dopiero opracowując projekt jego konstrukcji, struktur danych i mechanizmu działania, stosując wzory matematyczne, algorytmy, unikalne struktury i schematy blokowe.

...analiza wymagań i projektowanie to jest praca Zamawiającego wykonana by opisać to czego ocze­ku­je­my. UWAGA! Zgodnie z regulacją zawartą w art. 24 ust. 1 pkt 19 Pzp, z postępowania o udzielenie zamówienia wyklucza się wykonawcę, który brał udział w przygotowaniu tego postępowania lub którego pracownik, a także osoba wykonująca pracę na podstawie umowy zlecenia, o dzieło, agencyjnej lub innej umowy o świadczenie usług, brały udział w przygotowaniu takiego postępowania (art. 24, utp 1 i 19 PZP)

Niestety, metody bazujące na zaufaniu w moc wywiadów z pracownikami i burz mózgów, w "wiedzę" wieloletniego pracownika i doświadczenie dostawcy określonego oprogramowania, stwarzają problemy z wdrażaniem systemów ERP. Wiele nieudanych projektów kończy się słowami:

Problem polegał na tym, że dostarczono nam dokładnie to co chcieliśmy, a nie to co jest nam potrzebne.

Dzieje się tak nie dlatego, że ludzie ci mają złą wolę, a dlatego że stosowanie intuicji w miejscu gdzie należy użyć twardych reguł i faktów, prawie zawsze prowadzi do błędów , zaś dostawca, robiąc analizę wymagań, ma potężny konflikt interesu specyfikując wymagania na własny produkt: dostarczy to co ma, a nie to czego potrzebuje zamawiający. Skuteczne metody audytu i analizy to badanie faktów i dokumentów oraz modelowanie. Specyfikacje opracowane jako zebrane wymagania wyrażone jeżykiem naturalnym nigdy nie są kompletne i zawsze niespójne:

Niekompletność jest typowym problemem, który pojawia się, gdy interesariusze (np. eksperci domeny) posiadają pewne informacje i uznają je za ogólnie znane, i nie wspominają o nich analitykowi. Model oparty na niekompletnych wymaganiach cierpi z powodu brakujących obiektów, właściwości lub relacji.

Idealizacja jako metoda

Idealizacja to metoda opracowania wymagan na realne rozwiązanie. Polega na opracowaniu raportu z audytu organizacji, określenia biznesowego celu projektu i na tej podstawie, określeniu docelowej postaci (mechanizmu działania) organizacji czyli jej docelowego modelu. Pośrednim etapem jest model idealnej postaci docelowej oraz studium wykonalności tego ideału . Produktem ostatecznym jest kompromis pokazany poniżej:

Idealizacja jako metoda planowania zakresu projektu (opracowanie własne na podstawie oraz Studium wykonalności)

Pierwszym etapem jest więc określenie stanu idealnego, drugim, ocena możliwości jego osiągnięcia i podjęcie decyzji o ostatecznym zakresie projektu (to wymagania na rozwiązanie). Ideał jest często wymaganiem, stan możliwy to Koncepcja Wdrożenia opracowana przez dostawcę (to on opracowuje studium wykonalności wymagań).

Podstawowym narzędziem w toku prac jest tak zwane modelowanie. Stosuję standard dokumentacyjny znany jako MDA/MDE (ang. Model Driven Architecture, Model Driven Engineering, więc w MDA...). Wszystkie średnie i duże projekty realizuję metoda iteracyjno-przyrostową (patrz także opis pojęcia stożek niepewności).

Etapy projektu

Projekt realizowany zgodnie z MBSE (Model Driven System Engineering) ma następującą strukturę:

Etapy projektu MBSE

Nazwy i cele kluczowych etapów pracy Analityka Projektanta :

Kluczowe dwa etapy projektu analitycznego i ich składniki. Bardzo ważne: wymagania biznesowe są konsekwencją procesów biznesowych oraz Celów Biznesowych Projektu, te ostatnie Zamawiający musi sam opisać na etapie inicjacji projektu (na podstawie ).

Praktycznie wszystkie moje projekty mają podobny scenariusz:

  1. Analityk jest w projekcie informatycznym jak architekt w projekcie budowlanym . Produktem Analizy Biznesowej jest model, który opisuje cel projektu, mechanizm działania organizacji, ale bez zbędnych detali. Stanowi sobą pewną idealizację organizacji . Produktem są Wymagania Biznesowe .
  2. Na podstawie Wymagań Biznesowych określany jest zakres projektu (Przypadki użycia) i powstaje Opis Techniczny Rozwiązania zwany także PIM , zawierający między innymi model realizacji logiki biznesowej i przetwarzania informacji oraz architekturę integracji systemu . Projekt ten jest wymaganiem (PIM) wobec oprogramowania .
  3. Wybór dostawców.
  4. Nadzór autorski w toku prac wdrożeniowych Wykonawcy.

CIM (Computation Independent Model) Audyt i Model Biznesowy organizacji

CIM to model biznesowy abstrahujący od technologii. Jego celem jest zrozumienie mechanizmów działania organizacji. Stosowane przeze mnie metody oparte są na analizie faktów (dokumentów) i opracowaniu modelu ich powstania (procesy biznesowe) .

Ten etap jest realizowany jako audyt oraz projekt analizy i reorganizacji. Został opisany osobno jako Analiza i opracowanie Architektury Biznesowej organizacji.

PIM (Platform Independent Model) Opracowanie Projektu Technicznego czyli projektowanie rozwiązania

Przypadki Użycia to opis z perspektywy użytkownika, ich specyfikacja to model PIM: opis techniczny. Jest to model opisujący architekturę i logikę działania wymaganego rozwiązania (dedykowanego modułu). Tak opracowana dokumentacji chroni także know-how Zamawiającego.

Projektowanie architektoniczne jest działalnością intelektualną, w której architekt przechodzi od abstrakcji do rzeczywistości. W tym procesie, abstrakcja reprezentuje logiczne rozumowanie w jaki sposób forma architektoniczna jest skonfigurowana lub ustrukturyzowana, podczas gdy rzeczywistość odnosi się do ostatecznej formy fizycznej. Diagramy stają się integralną częścią projektu koncepcyjnego ponieważ pośredniczą pomiędzy tymi dwoma sferami.

Od dawna wiadomo, że rosnąca złożoność oprogramowanie nie daje już szans człowiekowi na napisanie kodu programu bezbłędnie za pierwszym razem. Luka pomiędzy wymaganiami a działającym kodem rośnie i będzie rosła. Dlatego od dawna lukę tę wypełnia się etapem modelowania, które nie narzuca technologii implementacji, uwzględnia możliwość mieszania dostępnych na rynku gotowych komponentów, a na etapie prototypowania jest wielokrotnie tańsze tańsze od kodowania,

Model (PIM) jako wypełnienie luki między wymaganiami a Działającym oprogramowaniem .

Projekt rozwiązania jako Specyfikacja Wymagań

Najpierw powstaje tak zwana Architektura Wysokiego Poziomu (ang. HLD, High-Level Design) dla całości projektu. Tam gdzie wymagane będa dedykowane moduły, projekt jest uzupełniany o Architekturą Niskiego Poziomu (amg. LLD, Low-Level Design) czyli projekt techniczny (nadal tylko logika). Są to dwie co najmniej iteracje.

Etap projektowania rozwiązania jest więc realizowany zawsze (jest zalecany), gdy celem jest wdrożenie oprogramowania. Także dlatego, że może sie okazać, że większość, a bywa że 100%, tego co potrzebujemy (wiemy co bo mamy już model) można już kupić na rynku. Taki model staje wymaganiem dla dostawcy systemu.

Tu znowu przytoczę diagram obrazujący kolejne warstwy modelowania :

Mając już model biznesowy (w tym modele procesów biznesowych) i wymagania biznesowe (enterprise context) specyfikujemy wymagane usługi aplikacyjne (business services). Powstaje zakres projektu. Jest dokument opisujący usługi aplikacji, zawierający: specyfikację usług, powiązanych z nimi dokumentów, mapowanie ich na model procesów biznesowych, realizowane wymagania biznesowe (dostarczone przez zamawiającego). Produktem tego etapu jest opracowanie zgodne ze specyfikacją Model Driven Architecture/Computation Independent Model (źr. www.omg.org/mda/), etap ten (jako opracowanie) stanowi wynik transformacji modelu biznesowego na usługi aplikacyjne (jej przypadki użycia).

Dane to informacje dla człowieka

Kluczowym elementem tego opisu są struktury dokumentów wyrażone w sposób sformalizowany:

Przykład opisu struktury informacyjnej dokumentu (notacja UML)

Zawierają one opis sposobu realizacji większości wymagań biznesowych (np. jeżeli "system ma pozwalać na kontrole wykorzystania urlopów" to znaczy, że wniosek urlopowy powinien zawierać dane: typ urlopu oraz liczba dni, co należy udokumentować jak wyżej). Więcej w artykule Dokumentowani przypadków użycia.

Jeżeli okaże się, że nie zaoferowano produktu istniejącego już na rynku (lub nie spełniają one wymagań w 100%), to znaczy że powstaną dedykowane komponenty. Jest to sytuacja, w której mechanizm (logika biznesowa) wybranego obszaru działania organizacji jest unikalna, bardzo często mechanizm ten stanowi chroniony know-how tej organizacji. W takiej sytuacji powstaje projekt techniczny tego komponentu, a od wykonawcy oczekiwana jest oferta na wykonanie implementacji.

(Dalsza część jest przeznaczona także dla dostawców i wykonawców oprogramowania)

Programming is not solely about constructing software?programming is about designing software.

(Programowanie nie dotyczy wyłącznie konstruowania oprogramowania - programowanie dotyczy projektowania oprogramowania. , więc od niedawna jestem programistą 🙂 )

Poprzedzanie programowania projektowaniem jest kluczowym etapem obniżającym ryzyko projektu .

"Niezależnie od tego ile przeprowadzisz rozmów z mistrzami gry w bilarda i ile godzin filmów nakręcisz nad stołem  bilardowym, nie zbliżysz się nawet do stworzenia dość dobrej gdy w bilarda. Jednak wystarczy, poświęcić czas na zrozumienie i zapisanie praw fizyki rządzących ruchem kul na stole bilardowym, by napisać grę doskonałą".  

Projekt architektury aplikacji to także wymaganie: wymagamy dostarczenia tego co zaprojektowano. Nie jest to detaliczny projekt oprogramowania czy procedur, jest to opis architektury oprogramowania (systemu IT), oczekiwanej (idealizacja) logiki biznesowej mechanizmu jego działania.

Co do zasady projektowana jest tak zwana architektura wysokiego poziomu (model PIM wg. OMG.org/MDA), czyli system złożony z dziedzinowych komponentów, ich integracja, model informacyjny. Model informacyjny to opis zawartości (struktur) dokumentów ujawnionych w procesach w Analizie Biznesowej, logika poprawności danych na dokumentach oraz logika wiążąca dokumenty między sobą.

Projekt Techniczny: Opis Przedmiotu Zamówienia

Wymagania na oprogramowanie to obecnie projektowanie aplikacji internetowych... Programowanie nie pole­ga już wyłącz­nie na pisa­niu kodu, pro­gra­mo­wa­nie pole­ga na projektowaniu. .

Opis Techniczny Rozwiązania to tak zwany model PIM (ang. Platform Independent Model) i jest to - ten projekt - wymaganie. Stanowi on specyfikację usług jakich oczekuje się od oprogramowania oraz opis logiki jaką ma ono realizować. Przypadki użycia, wyprowadzane z modeli procesów biznesowych, są dodatkowo dokumentowane z użyciem scenariuszy, te zaś wykorzystują komponenty realizujące logikę biznesową (tak zwany model dziedziny). Poniżej struktura modeli (perspektywy) jakie powstają (patrz także proces OMG SPEM):

(źr. )
Powyższy diagram stanowi ilustrację struktury projektu. Od czasu publikacji tego podręcznika definicja obiektowego paradygmatu uległa pewnej ewolucji: centralna część, model dziedziny systemu (wyrażony jako diagram klas UML), pochodzi z metod strukturalnych, a nie obiektowych, i obecnie nie należy go tak tworzyć.

Model logiki aplikacji pokazany powyżej to zgodny z podejściem MDA/MDE, jest to projekt logiki i architektury przyszłej aplikacji (w notacji UML). Całość jest wykonana w czytelny dla adresata sposób (niuanse notacji musi znać autor diagramów, ich odbiorcom wystarczy opisana legenda symboli).

Metody obiektowe mają ogromne zalety, są znane od lat, są stosowane... są mało popularne bo są trudne ... ale ja robię to od 20 lat...

(Designing Object Systems: Object-Oriented Modelling with Syntropy Textbook Binding ? November 18, 1994 by Steve Cook (Author), John Daniels (Author))

Opis bardziej techniczny oraz przykładową specyfikację znajdziecie Państwo na stronie Analiza, wymagania i usprawnianie organizacji czyli MBSE. Omówiony przykład OPZ dla administracji publicznej na stronie Generator Ofert. Przykładowy dokument projektowy i to jak powstawał na stronie Biblioteka.

Podsumowanie

  • wymagania funkcjonalne są dokumentowane jako usługi aplikacji (jej przypadki użycia) i formularze (patrz Projekt aplikacji)
  • w opisach formularzy i dokumentów posługuję się standardowo ich treścią i strukturą (XML),
  • komunikacja ze mną w toku nadzoru autorskiego i rozwoju odbywa się z pomocą mojego repozytorium: Postmania.
  • ostateczne decyzje i szczegóły powstają w toku Nadzoru Autorskiego (patrz Nadzór Autorski)

(na podstawie: P.Sienkiewicz, L.Koźmiński, P.Miller, OMG.org)

Sku­tecz­ny opis wyma­gań to spe­cy­fi­ka­cja wyra­żo­na języ­kiem o skoń­czo­nej licz­bie pojęć, pozwa­la­ją­ca pro­gra­mi­stom ?wlać? ją do kolej­nej ?for­mal­nej for­my? jaką jest język pro­gra­mo­wa­nia. (patrz: Logika wnioskowania dedukcyjnego czyli czym jest poprawna analiza i modelowanie)

Wybór dostawców i umowa

Ten etap to ogłoszenie (rozesłanie) zapytania ofertowego. Standardowo w pierwszym kroku ogłaszam RFI (zapytanie o gotowość do złożenia oferty) bez podania danych Zamawiającego, na moich profilach w mediach społecznościowych (mam kilka tysięcy obserwujących osób i firm). Firmy, które zgłosiły się w tym etapie są oceniane przez Zamawiającego, który wybiera kilka. Wybranym firmom przekazywane jest pełne zapytanie RFP z Opisem Przedmiotu Zamówienia Przedmiotem Zamówienia są określone w zapytaniu usługi (np. wdrożenie, szkolenia itp.) oraz wynik Analizy Biznesowej i Opis Techniczny Oprogramowania) . Wybierany jest Wykonawca, który złożył najkorzystniejszą ofertę, kryteriami są zawsze cena, kompetencje i doświadczenie oraz zaoferowana technologia.

Na tym etapie, zgodnie z Art.634 KC, Wykonawca powinien zgłosić wszelkie ewentualne swoje zastrzeżenia do materiałów (dokumentacja) jakie otrzymał, i robić to na bieżąco także w toku realizacji projektu, jeżeli otrzyma jakiekolwiek nowe materiały.

Ogłoszenia i zapytania ofertowe moich klientów (w tym także Opis Przedmiotu Zamówienia) wysyłam na listę subskrybentów mojego serwisu i publikuję na swoim profile LinkedIn (patrz nagłówek strony).

Podpisanie Umowy i nadzór autorski

Wymagania na początku projektu nie są ostatecznym produktem analityka

Wszystkie detale technologiczne opracowuje Wykonawca, który składając ofertę zadeklarował, że dostarczy rozwiązanie zgodne z Projektem Technicznym, a w swoim dokumencie, jakim jest Koncepcja Wdrożenia, Wykonawca powinien opisać to, jak zrealizuje projekt z użyciem technologii jaką zaoferował.

Koncepcja nadzoru autorskiego zakłada, że projektant (autor), na zlecenie inwestora, projektuje rozwiązanie a następnie, po wyborze wykonawcy, nadzoruje realizację rozwiązania i uzupełnia treść projektu o wymagane szczegóły, odpowiadając na pytania zarówno inwestora jak i wykonawcy. Dokumentacji projektowej nie da się "zamrozić" na czas trwania nie raz wielomiesięcznego projektu. Dlatego większe projekty są realizowane komponent po komponencie w pętli iteracyjno-przyrostowej.

Po zakończeniu implementacji, uzupełniane w toku projektu, powiązane z sobą Projekt rozwiązania (uzupełniany w toku nadzoru autorskiego) i Opis implementacji (uzupełniany przez Wykonawcę), stanowią kompletną dokumentację dostarczonego produktu. Całość zobrazowano na poniższym diagramie:

Produkty powstające w toku analizy, projektowania i implementacji. Pokazano kluczowe elementy umowy z dostawcą oprogramowania. Możliwa jest sytuacja, w której nie ma rynku oprogramowania spełniającego wymagania, i wtedy całość dostawy (przedmiot umowy) stanowi oprogramowanie dedykowane.

Dostawca rozwiązania nie robi żadnej swojej analizy przed-wdrożeniowej. Na podstawie otrzymanych materiałów opracowuje Koncepcję Wdrożenia, którą realizuje w toku projektu.

Praktyka pokazuje, że problemy z wdrożeniem system ERP są powodowane, przez założenie kupującego, że dostawca ma doświadczenie i wie jak wdrożyć swój system. Problem w tym, że dostawca w dobrej wierze, wdroży to co ma, osobną kwestia jest upewnienie się, że to co ma jest tym czego potrzebujemy. To dlatego wybór dostawcy rozwiązania powinien być ostatnim, a nie pierwszym etapem projektu przygotowania do wdrożenia. Istotne jest także, co pokazano na powyższym diagramie, ścisłe rozdzielenie kodu licencjonowanego od wytworzonego w toku wdrożenia (patrz: Kastomizacja).

Polecam także artykuł Wymagania umarły...?1?

Dodatek: Podmioty publiczne i PZP

Na zakończenie kilka słów o zamówieniach publicznych, skupię jednak wyłącznie na kwestiach usług jakie osobiście oferuję.

Od wielu lat moimi zleceniodawcami są także podmiotu publiczne (między innymi: PFRON, Urząd Miasta Warszawy, PSE, KGHM SA, Żandarmeria Wojskowa, Kancelaria Senatu). Przetargi publiczne z zasady są projektami określanymi jako "fixed-price" (całkowity koszt określany w momencie zamówienia) co czyni je trudniejszymi na etapie przygotowania. Pojawiają się publikacje na temat stosowania "zwinnych metod w administracji publicznej", firmowane nawet przez znane kancelarie prawne, jednak praktyka pokazuje, że tworzenie OPZ w postaci "otwartego zarządzalnego zakresu projektu" nie rozwiązuje praktycznie żadnych problemów, za to stwarza ogromne ryzyko przejęcia zarządzania zakresem projektu przez dostawcę ("dostaniesz to co chce Ci dostarczyć dostawca a nie to czego potrzebujesz"), Jeden z moich komentarzy na ten temat tu: Agile w PZP (2017).

W Czerwcu 2020 roku, Urząd Zamówień Publicznych opublikował dokument: POSTĘPOWANIE O UDZIELENIE ZAMÓWIENIA PUBLICZNEGO NA SYSTEM INFORMATYCZNY. We wstępie autorzy piszą:

Zakup systemów informatycznych to złożony proces, który wymaga od zamawiających rzetelnego przygotowania. Istotny wpływ na powodzenie zamierzenia inwestycyjnego związanego z zamawianym systemem IT ma wiele czynników, wśród których przykładowo można wymienić znajomość rozwiązań IT występujących na rynku, aktualność posiadanych przez zamawiającego w tym zakresie informacji, czy też świadomość co do możliwości własnych zamawiającego w zakresie prawidłowego i wyczerpującego przygotowania postępowania na zakup systemu IT. Prawidłowe przygotowanie zamawiającego do przeprowadzenia postępowania, tj. na etapie jeszcze przed wszczęciem postępowania o udzielenie zamówienia publicznego, pozwala minimalizować problemy, jakie mogą wystąpić w prowadzonym w przyszłości postępowaniu, a także w trakcie realizacji oraz eksploatacji przedmiotu zamówienia, szczególnie w przypadku nabywania złożonych rozwiązań technologicznych.

Jak widać zwraca się szczególną uwagę na kompetencje wymagane do opracowania niezbędnej dokumentacji oraz na wewnętrzne przygotowanie do przyszłego wdrożenia i eksploatacji systemu informatycznego. Autorzy zwracają uwagę, że:

...choć obowiązek przeprowadzenia analizy potrzeb i wymagań, o której mowa w art. 83 ustawy PZP dotyczy tylko niektórych zamawiających i postępowań (tzn. nie dotyczy zamówień o wartościach nieprzekraczających progów unijnych oraz zamówień sektorowych), to jednak przeprowadzenie analogicznego procesu może być uzasadnione także w wypadkach, w których nie jest on obligatoryjny.

Ważny zapis:

W nowej ustawie PZP określony został próg wartościowy wyznaczający obowiązek stosowania przez zamawiającego przepisów tej ustawy. Obowiązek ten powstaje, jeżeli wartość zamówienia osiągnie ten próg. Zgodnie z przepisem art. 2 ust. 1 pkt 1 ustawy PZP, jej przepisy stosuje się, co do zasady, do udzielania zamówień publicznych oraz organizowania konkursów, których wartość jest równa lub przekracza kwotę 130 000 zł, przez zamawiających publicznych.

W dalszej części dokumentu czytamy:

Zamawiający powinien zweryfikować kompetencje własnego zespołu i sprawdzić, czy dysponuje specjalistami, którzy: (-) przygotują opis przedmiotu zamówienia w sposób wystarczająco precyzyjny i dokładny, a także uwzględniający adekwatne potrzeby zamawiającego, najnowsze standardy i wytyczne, normy branżowe, w tym także w zakresie cyberbezpieczeństwa systemów IT, (-) zapewnią sprawną realizację postępowania zamówieniowego (np. w zakresie odpowiedzi na pytania wykonawców, oceny ofert,) (-) zapewnią należytą realizację umowy zawartej w ramach zamówienia.

Przygotowanie do przetargu (analiza potrzeb i opracowanie OPZ), wsparcie w toku postępowania oraz roczny nadzór autorski (wiele wdrożeń systemów informatycznych, jakie prowadziłem, mieści sie w granicach roku od podpisania umowy z dostawcą), to w moim przypadku, to usługa o wartości bardzo często poniżej 130 tys. zł, wraz z kosztem. Oznacza to, że możecie Państwo zlecić mi taką usługę (przygotowanie do przetargu) bez straty czasu na konkursy (bez nadzoru autorskiego jest to koszt 40 tys. zł). Wystarczająca jest ocena dorobku, kompetencji i doświadczenia oraz (co bardzo ważne) podpisanie oświadczenia o braku konfliktu interesu:

Zamawiający musi więc pamiętać o treści art. 85 oraz art. 108 ust. 1 pkt 6 ustawy PZP, które nakazują przeciwdziałać sytuacji, w której udział danego wykonawcy w przygotowaniu postępowania zakłóci konkurencję, a jeżeli tego zakłócenia wyeliminować się nie da, nakazują wykluczyć z postępowania wykonawcę, który był zaangażowany przy przygotowaniu postępowania.

Autorzy zaleceń piszą także:

Wobec dynamiki zmian zachodzących w zakresie rozwiązań informatycznych, zamawiający powinien szczególnej uwadze poddać aktualność posiadanych informacji. Mając na uwadze powyższe, istotne jest również to, aby zamawiający planował przeprowadzenie postępowania w taki sposób, aby zapobiegać przewlekłości procesu zakupowego, gdyż powoduje ona ryzyko dezaktualizacji opracowanej dokumentacji.

Jednak "część formalna SWZ" powinna być przygotowania przez Zamawiającego i jego służby prawne. Autorzy zwracają tu uwagę, że:

Nie można też zapomnieć o treści projektowanych postanowień umowy ? ich przygotowanie bez dogłębnej wiedzy o przedmiocie zamówienia oraz przebiegu jego realizacji, jest błędem, na który nie może sobie pozwolić żaden zamawiający.

Poniżej treść omawianego dokumentu:

Polecam lekturę powyższego dokumentu w całości.

Dodatek: Opis odwoływania się, w Koncepcji Wdrożenia, do wymagań

Każdy dostawca rozwiązania, jako pierwszy produkt w realizacji Umowy (lub na etapie ofertowania) musi (powinien) opracować dokument Koncepcja Wdrożenia (studium wykonalności, analiza fit-gap, lub odpowiednik), opisujący to jak proponuje, wdrażając oferowany produkt, zrealizować Wymagania Zamawiającego.

"Analiza Biznesowa i Projekt Techniczny Rozwiązania" (dalej Analiza) zawiera między innymi rozdziały: Model Procesów Biznesowych oraz Model Kontekstowy Systemu IT (Zamawiającego). Pierwszy zawiera opis działania organizacji, drugi zawiera zakres wdrożenia w postaci listy wymaganych usług aplikacyjnych (wyrażonych jako przypadki użycia UML oraz ich specyfikacje, to wymagania wyrażone metodą MDA/MBSE).

Opis każdej wymaganej usługi aplikacji w Analizie (przypadki użycia) zawiera:

  • kontekst i celu jej użycia i wskazanie jej aktora (pracownik, klient, inny system itp..),
  • szablon formularza ekranowego/wydruku i walidację pól,
  • architekturę i logikę realizacji wymiany danych z innymi formularzami i innymi aplikacjami, jeżeli to wymagane (integracja).

Dostawca rozwiązania w treści proponowanej Koncepcji Wdrożenia (to produkt dostawcy):

  1. albo organizuje ten dokument w taki sposób, że wskazuje w nim jak zrealizuje każdą wymaganą usługę aplikacji (wtedy podstawą spisu treści Koncepcji Wdrożenia są wymagane usługi aplikacji),
  2. albo organizuje ten dokument w taki sposób, że wskazuje (przywołuje) w np. standardowym opisie dostarczanego rozwiązania (np. Instrukcja Obsługi) miejsca (np. funkcje aplikacji w menu), które realizują określoną, wymaganą usługę aplikacji (wtedy podstawą spisu treści Koncepcji Wdrożenia jest opis funkcjonalny dostarczanej aplikacji).  

Pierwszy przypadek np.: "wymagana usługa [nazwa usługi: przypadku użycia ] jest realizowana przez [tu wskazanie, które standardowe funkcje dostarczanego oprogramowania ją realizują i jak]".

Drugi przypadek:  "Nasze oprogramowanie ma funkcje [tu nazwa i opis tej funkcji], która realizuje potrzeby opisane jako [tu nazwa usługi aplikacji - przypadek użycia - w Analizie]".

Jeżeli dostarczone oprogramowanie w wersji standardowej nie realizuje jakiejś wymaganej w Analizie usługi, powinna się pojawić taka informacja wraz z propozycją metody rozszerzenia funkcjonalności standardowej wersji dostarczanego oprogramowania. Tak zorganizowany dokument Koncepcji Wdrożenia jest także często nazywany "analizą fit-gap" , także: , , . Patrz także powyżej: Idealizacja jako metoda.

    Zapytanie Ofertowe

    Chcę być informowany o nowościach na stronie firmy IT-Consulting.pl

    Źródła

    Ackoff, R. L., Magidson, J., Addison, H. J., & Ehrlich, A. (2007). Projektowanie ideału: kształtowanie przyszłości organizacji. Wyższa Szkoła Przedsiębiorczości i Zarządzania im. Leona Koźmińskiego : Wydawnictwa Akademickie i Profesjonalne.
    Ackoff, R. L., Magidson, J., & Addison, H. J. (2006). Idealized design: creating an organization’s future. Wharton School Pub.
    Alassaf, N., & Clayton, M. (2021). The Use of Diagrammatic Reasoning to Aid Conceptual Design in Building Information Modeling (BIM). Building Information Modelling, Volume 2, 10.
    Ancveire, I. (2018). Fit Gap Analysis Methods for ERP Systems Literature Review. 2018 IEEE 12th International Symposium on Applied Computational Intelligence and Informatics (SACI), 000161–000166. https://doi.org/10.1109/SACI.2018.8440972
    Arlow, J., & Neustadt, I. (2004). Enterprise patterns and MDA: building better software with archetype patterns and UML. Addison-Wesley.
    Belli, F., Budnik, C. J., & White, L. (2006). Event-based modelling, analysis and testing of user interactions: approach and case study. Software Testing, Verification and Reliability, 16(1), 3–32. https://doi.org/10.1002/stvr.335
    Börger, E. (2018). Why Programming Must Be Supported by Modeling and How. In T. Margaria & B. Steffen (Eds.), Leveraging Applications of Formal Methods, Verification and Validation. Modeling (Vol. 11244, pp. 89–110). Springer International Publishing. https://doi.org/10.1007/978-3-030-03418-4_6
    Brambilla, M., Cabot, J., & Wimmer, M. (2012). Model-driven software engineering in practice. Morgan & Claypool.
    Cohn, D., & Hull, R. (2009). Business artifacts: A data-centric approach to modeling business operations and processes. IEEE Data Eng. Bull., 32(3), 3–9.
    Cook, S., & Daniels, J. (1994). Designing object systems: object-oriented modelling with Syntropy. Prentice Hall.
    DaveBeasley. (n.d.). Perform fit gap analysis - Learn. Retrieved May 18, 2022, from https://docs.microsoft.com/en-us/learn/modules/fit-gap-analysis/
    Dennis, A., Wixom, B. H., & Roth, R. M. (2012). Systems analysis and design (5th ed). John Wiley.
    Fowler, M. (1997). Analysis patterns: reusable object models. Addison Wesley.
    Kiec, M. (2021). FIT-GAP ANALYSIS AS INTRODUCTION STEP TO BUSINESS PROCESS STANDARDIZATION. Scientific Journal of Silesian University of Technology. Series Transport, Issue No. 153, 193. https://doi.org/10.29119/1641-3466.2021.153.14
    Kitchenham, B. A., Budgen, D., & Brereton, P. (2016). Evidence-based software engineering and systematic reviews. CRC Press.
    Kumar, R. N. P., & Patil, S. (2019). A System and Method for improving the Model Based Systems Engineering Environment capability. INCOSE International Symposium, 29(S1), 277–290. https://doi.org/10.1002/j.2334-5837.2019.00685.x
    Nataliya Shevchenko. (2021, February 22). Requirements in Model-Based Systems Engineering (MBSE) [Blog]. SEI Blog. https://insights.sei.cmu.edu/blog/requirements-in-model-based-systems-engineering-mbse/
    OMG.org. (2014, June 18). Model Driven Architecture (MDA). https://www.omg.org/mda/
    Ozkaya, I. (2020). Building Blocks of Software Design. IEEE Software, 37(2), 3–5. https://doi.org/10.1109/MS.2019.2959049
    Schmidt, D. C. (2006). COVER FEATURE Model-Driven Engineering.
    Šenkýř, D., & Kroha, P. (2019). Problem of Incompleteness in Textual Requirements Specification: Proceedings of the 14th International Conference on Software Technologies, 323–330. https://doi.org/10.5220/0007978003230330
    Voxco. (2022). Fit-gap analysis: Definition, Uses and Steps. https://www.voxco.com/blog/fit-gap-analysis-definition-uses-and-steps/
    Żeliński, J. (2017). Analiza biznesowa: praktyczne modelowanie organizacji (Grupa Wydawnicza Helion, Ed.). Wydawnictwo Helion.
    Zelinski, J. (2020). Synthesis of MOF, MDA, PIM, MVC, and BCE Notations and Patterns. In Applications and Approaches to Object-Oriented Software Design: Emerging Research and Opportunities (pp. 78–89). IGI Global. https://www.igi-global.com/book/applications-approaches-object-oriented-software/235699
    Żeliński, J. (2017). Architektura kodu aplikacji jako pierwszy etap tworzenia oprogramowania. Materiały pokonferencyjne III Ogólnopolskiej Konferencji Interdyscyplinarnej „Współczesne zastosowania informatyki”, 6–14. https://www.wzi.uph.edu.pl/okiwzi3/wp-content/uploads/2017/09/2017-08-22-22-22.pdf#page=7
    Service oriented architecture Modeling Language (SoaML) - Specification for the UML Profile and Metamodel for Services (UPMS). (n.d.). 167.

    Ostatnia aktualizacja:  lip 4, 2022 @ 12:29