2011 – Page 7 – JZ IT Consulting Ltd

Słabości tradycyjnych metod wytwarzania IT – czy na pewno słabości?

Post author:Jaroslaw Zelinski
Post published:10 October 2011
Post category:Analizy biznesowa i projektowanie oprogramowania

A co mówią statystyki? Analysts report that as many as 71 percent of software projects that fail do so because of poor requirements management, making it the single biggest reason for project failure?bigger than bad technology, missed deadlines or change management fiascoes. ( źr. Fixing the Software Requirements Mess CIO.com). Parząc na powyższe (wytłuszczenie: w większości z ponad 71% złych projektów programistycznych, powodem kłopotów było złe zarządzanie wymaganiami, co czyniło większe szkody niż pozostałe powody, takie jak technologie, napięte terminy czy zarządzanie zmianami, razem wzięte). Tak więc zastanówmy się czy aby na pewno brak projektu i specyfikacji wymagań to dobry sposób na projekt IT. Czy metody wytwarzania bazujące na braku pierwotnego projektu, faktycznie są zbawieniem projektów programistycznych... Dodam na koniec, że powyższe dotyczy w takim samym stopniu systemów dedykowanych jak i gotowych a wymagających "kastomizacji" bo to (nowe funkcjonalności systemu) także projekt dedykowany.

Prawo autorskie, szpiegostwo przemysłowe i projektowanie

Post author:Jaroslaw Zelinski
Post published:6 October 2011
Post category:Prawo autorskie i know-how

Jak ustrzec się przed wyniesieniem z firmy tajemnicy jej funkcjonowania, tworzonej latami organizacji, procedur i procesów, reguł biznesowych? Jak zatrzymać w firmie wiedzę mino zamawiania oprogramowania, które siła rzeczy ja zawiera? Problem nie jest prosty. Sami prawnicy nie są między sobą zgodni co do tego, gdzie leży granica pomiędzy utworem literackim a szczegółowym opisem rozwiązania. Wydaje się, że kluczem jest to sposób tworzenia opisu tego co ma powstać. Standardem w IT jest opis wymagań, ten jednak z urzędu czyni autora oprogramowania także posiadaczem opisu logiki w nim zawartej, bo on jest autorem jej opisu. Wyjściem wydaje się zawarcie w umowie nie opisu wymagań na oprogramowanie a projektu oprogramowania. Metodą zdefiniowania granicy, za którą mamy nie utwór literacki (specyfikacje wymagań) a projekt wraz z algorytmami, jest metodyka MDA. Wtedy firma realizująca zamówione oprogramowanie tworzy dzieło zależne a zamawiający nie traci panowania nad tak powstałym produktem. Jest to sytuacja jaką znamy w branży budowlanej: developer dostaje projekt architektoniczny, i sam fakt, że postawił na jego podstawie obiekt nie daje mu żadnych praw do niego, gdyż wystarczająco szczegółowy projekt obiektu pozostaje dziełem projektanta a nie jego wykonawcy. Jednak zawsze, bo nie ma złotej reguły, wymaga to konsultacji i szczegółowego określenia zawartości dokumentacji, która ma stać się "opisem przedmiotu zamówienia".

W sądach i urzędach giną dokumenty, nie musi tak być

Post author:Jaroslaw Zelinski
Post published:5 October 2011
Post category:Analizy biznesowa i projektowanie oprogramowania

Zapewne nie odtworzy się oryginałów ale poświadczone, elektroniczne kopie można posiadać. Dlatego urzędom, i nie tylko, sugeruje rozważenie: zamiast walczyć z wdrażaniem mało tu skutecznych, kosztownych i długotrwałych we wdrożeniu, systemów obiegu dokumentów, wdrożyć porządne repozytorium dokumentów, archiwów elektronicznych. Łatwiej jej wdrożyć, są w znacznej części gotowe wymagania dostępne na stronach Archiwum Państwowego. Zarządzanie procesem przepływu dokumentów jest trudniejsze bo po pierwsze, wymaga powyżej wykonanej analizy, po drugie system workflow i tak wymaga dobrego repozytorium dokumentów. Mając dobre archiwum zabezpieczymy lekko licząc 90% związanych z zarządzaniem dokumentami potrzeb bo: mamy ich kopie w repozytorium możliwe jest automatyczne monitowanie terminów właściwym osobom, możliwe jest więc dekretowanie, niemożliwe jest ukrycie tego, na jakim etapie (u kogo) jest dana sprawa i jak długo jest załatwiana. Tak więc można ... Czy ktoś chce mnie może przekonać, że w firmach dokumenty nie giną? Giną i to znacznie częściej niż w urzędach, więc pokory proszę w ocenie urzędów ...

Agilian nowa wersja. Burza mózgów sformalizowana …

Post author:Jaroslaw Zelinski
Post published:21 September 2011
Post category:Analizy biznesowa i projektowanie oprogramowania

Po co nam CASE? Bo Dzięki narzędziom CASE projekty tworzy się dokładniej, a praca nad diagramami, sprawdzanie ich poprawności oraz śledzenie wykonanych testów jest prostsze i szybsze. (wiecej: http://www.eioba.pl) Tak więc gorąco polecam stosowanie narzędzi (lista narzędzi CASE). Z zasady nie reklamuje oprogramowania. Uważam, że jego sprzedawanie to inna kompetencja. Jednak nie da się ukryć jestem użytkownikiem "czegoś". Czym to jest? Pakiet typu [[CASE]] [[Visual-Paradigm Agilian]]. I co my tu mamy? Wczoraj dotarł do mnie upgrade i... mamy burzę mózgów :):

Młodzi: oburzeni mutanci, uśpione pacynki – Państwo to także Korporacja IT

Post author:Jaroslaw Zelinski
Post published:4 September 2011
Post category:Analizy biznesowa i projektowanie oprogramowania

Do tego, ów kapitalizm, to jak pokazuje autor Korporacji (gorąco polecam tę książkę i film). Rozpoczynając czytanie tej książki traktowałem ją z początku jak kolejny efekt "spiskowej teorii dziejów", jednak z każda stroną zmieniałem zdanie gdyż z dużymi firmami mam do czynienia regularnie a tak zwane afery opisywane w prasie stanowią niejako naturalną ilustracje tej książki. Jedną z kluczowych tez autora tej książki jest to, że kluczem do zysków korporacji są wyzysk pracowników i przerzucanie swoich kosztów na klientów (nabywców ich towarów i usług). Nie będę tu się rozpisywał na ten temat, wystarczy poczytać w prasie i na forach dyskusyjnych jak wygląda realizacja niejednego projektu IT. Najpierw jest przetarg na podstawie wątpliwej jakości opisu potrzeb, potem dostawca - zatrudniając najtańszych pracowników na rynku - próbuje zrealizować swoje zobowiązanie rutynowo (czyli niskim kosztem) przerzucając koszty każdego ryzyka na zamawiającego. W efekcie otrzymujemy niskiej jakości i bardzo kosztowny produkt. Autor, w swoim artykule, wymienia także Państwo jako wyzyskiwacza. I tak to wygląda na prawdę: wszystkie koszty złego (kosztownego) funkcjonowania Państwa są przerzucane na podatnika, ten zaś jako usługobiorca (Państwo świadczy usługi dla obywateli) jest dokładnie w takiej samej sytuacji jak w przypadku brania kredytu w banku czy kupowania pasty do zębów w supermarkecie. Na koniec coś optymistycznego: osobiście widzę światełko w tunelu: przybywa ludzi oczekujących jakości od tego co dostaje. Pojawiły się nieco zdrowsze sałatki w sieciach fast-food, nabiera wartości na rynku dobre rękodzieło, nawet piwo z regionalnych browarów (droższe nie raz dwukrotnie od produkowanego masowo) dało się we znaki gigantom browarnictwa (każdy ma ambicję na piwo niepasteryzowane itp.) odbierając im część rynku. Oby tylko to światełko nie pozostałą niszą...