Wprowadzenie Niedawno miała miejsce kolejna moja dyskusja na LinkedIn, która pokazała że prawo własności intelektualnej jest bardzo trudne do przyswojenia, głównie dlatego że – z uwagi na swoją „niematerialność” – wymyka się intuicyjnej i materialnej manierze postrzegania świata przez człowieka. Na to nakłada się przeświadczenie koderów, że z zasady są samodzielnymi twórcami, i niestety wielu prawników także tak uważa. Rzecz w tym, że koder zawsze jest twórcą, ale nie zawsze jest projektantem. Gdy koder nie jest projektantem, jego utwory (kod źródłowy) to utwory zależne od utworów pierwotnych, jakimi są projekty techniczne wyrażone np. z pomocą…
Dług informacyjny jest znacznie groźniejszy niż dług technologiczny. Same zaległości technologiczne jako takie można usunąć bez dużego ryzyka: jest to po prostu upgrade już posiadanej infrastruktury. Dług informacyjny jest znacznie bardziej niebezpieczny, bo to całkowity brak wiedzy o tym jak to zrobić bezpiecznie i co w ogóle zrobić (upgrade czy jednak wymiana systemu na nowy inny).
Dług informacyjny to nie tylko nieudokumentowany system. To nieudokumentowane procesy biznesowe, procedury, reguły biznesowe, to zasoby wiedzy o organizacji jedynie w „głowach pracowników”, te zaś są najczęściej niespójne, niekompletne i bardzo często sprzeczne.
Wstęp
Siedem lat temu (2015) artykuł o wymaganiach i śladowaniu kończyłem słowami:
Tak więc wymagań biznesowych może być kilkadziesiąt. Wymaganych usług systemu (przypadków użycia) w dużym projekcie także może być kilkadziesiąt. Ale setki, czy tysiące ??wymagań? to wyraz utraty panowania nad zakresem projektu? Tu zwrócę uwagę, że wymaganiem (usługa systemu) może być np. wytworzona faktura VAT zgodna z przepisami. Cechy tej faktury (lista pól) to nie osobne wymagania, to cechy (parametry, atrybuty) jednego wymagania. Żadna cecha faktury VAT nie ma sama w pojedynkę żadnej wartości, nie może więc być oddzielnym przypadkiem użycia, tak samo jak wymaganiem naszym może być samochód, ale jego kolor czy automatyczna skrzynia biegów, to cechy samochodu, nie ma sensu wymagać ??czerwonego koloru? nie oczekując samochodu (i jak uzasadnić, to że ten kolor wspiera cel biznesowy). Przypadkiem użycia samochodu jest podróż a nie włożenie kluczyka do stacyjki, bo to jest tylko jeden z elementów scenariusza rozpoczęcia podróży samochodem.
Source: Dlaczego śladowanie wymagań jest istotne w projekcie? – Jarosław Żeliński IT-Consulting
Nadal pojawiają się publikacje o wymaganiach, zarządzaniu nimi i realizowaniu ich. Na rynku są dostępne aplikacje pozwalające je kolekcjonować i zarządzać taką kolekcją. I stale mamy do czynienia z ich – wymagań – niejednoznacznością . Okazuje się, że ich znaczenie staje sie kluczowe dla projektów, także z perspektywy prawa (PZP i zdefiniowane w zaleceniach UZP pojęcie potrzeba). Tym razem skupię się na pojęciach «wymaganie» i «potrzeba» w odniesieniu do projektu rozwiązania.
(więcej…)
