|
|
|
CASE STUDY
Nie zawsze opłaca się łączyć (2008.04.08) Wbrew tendencjom do konsolidacji, zaletą systemu rozproszonego jest większa odporność na awarie. | Co dwie głowy, to nie jedna (2008.02.26) Biznes i sektor publiczny, w tym urzędy i placówki naukowe, są skazane na współpracę, jeśli chcą twórczo rozwijać swoje organizacje. I, wbrew pozorom, biznes wcale nie jest w tej sytuacji stroną silniejszą. |
Odnaleźć swoją drogę | (2008.02.05) | | Największe i najbardziej nowoczesne przedsiębiorstwa próbują dziś znaleźć własną drogę w gąszczu standardów i metodyk. W sukurs przychodzi im koncepcja Architektury korporacyjnej (Enterprise Architecture). |
Obietnice w zarządzaniu | (2007.05.15) | | W wielu przedsiębiorstwach pracownicy działów IT są dosłownie zarzucani kolejnymi zleceniami, a komunikacja z użytkownikami rozwiązań informatycznych jest minimalna. Brak interakcji między tymi dwiema stronami utrudnia realizację projektów i funkcjonowanie organizacji. |
10 przyczyn porażki | (2007.05.08) | | Co najmniej od czasów Sun Tzu i jego "Sztuki wojny" wiadomo, dlaczego tak wiele przedsięwzięć prowadzonych przez zespół ludzi kończy się porażką. Mimo to nadal popełniamy te same błędy. Oto lista najważniejszych powodów niepowodzeń projektowych. |
Metoda ścieżki krytycznej: a co z ryzykiem? | (2006.11.13) | | Metoda ścieżki krytycznej umożliwiająca harmonogramowanie przedsięwzięć jest kluczowym narzędziem zarządzania projektami. Kierownicy projektu powinni jednak zrozumieć, że standardowa metoda ścieżki krytycznej wymaga uzupełnienia analizą ryzyk harmonogramowych. Inaczej prawdopodobieństwo zmieszczenia się w wyznaczonych terminach realizacji projektu będzie bardzo niskie. |
| Administracja publiczna - Algorytm na prawo | (2006.10.09) | | Wreszcie spełnia się marzenie kilku pokoleń informatyków. Kancelaria Sejmu podjęła się tzw. algorytmizacji prawa za pomocą XML. To rewolucja godna Lidera Informatyki. |
Złe wieści - dobre słowo | (2006.08.14) | | Testerzy i programiści mają różne zadania do wykonania i różny stosunek emocjonalny do przedmiotu swojej pracy. Muszą jednak ze sobą współpracować. Aby ta współpraca była efektywna, potrzebna jest odpowiednia komunikacja między nimi. |
Głębokie uczucie | (2006.08.14) | | Do tej pory dużo pisałem o zwracaniu uwagi na całość, przekształceniach zachowujących i wzmacniających całość. Jak jednak robić to w praktyce? Trzeba kierować się wewnętrznymi odczuciami. Jest to centralna idea w "The Nature of Order". Jak pisze Alexander, doszliśmy do "najważniejszego i najgłębszego aspektu procesu żywego (...), najważniejszego tematu w całej książce (...), najbardziej oświecającego i pociągającego. Może jednocześnie okazać się on intelektualnie najbardziej kontrowersyjnym i najtrudniejszym do zaakceptowania". |
Wzorce Alexandera | (2006.06.05) | | O Christopherze Alexanderze - architekcie, który wśród informatyków stał się postacią kultową - na łamach Computerworld pisałem już kilkakrotnie. Artykuł ten rozpoczyna cykl, w którym jeszcze szerzej przybliżę jego idee. |
Testowanie jeszcze raz testowanie | (2006.04.17) | | W przypadku tworzenia i wdrażania oprogramowania do obsługi sieci telekomunikacyjnych testowanie i działania związane z zapewnieniem jakości pochłaniają ponad 50% czasu i budżetu. Tak samo wyglądają w praktyce działania polskiej firmy Ericpol Telecom. |
Pośpiech w informatyce | (2006.02.20) | | Programowanie narażone jest na nieustanną pokusę bylejakości i pośpiechu, których skutkiem jest często albo fatalna jakość aplikacji, albo lekceważenie użytkownika i jego potrzeb. |
Projekt to nie tylko harmonogram | (2006.02.13) | | Pakiety wspomagające zarządzanie projektami mają do perfekcji dopracowane funkcje związane z harmonogramowaniem i alokacją zasobów. Niestety kierownicy projektów i szefowie biur projektowych potrzebują dziś znacznie bardziej wyrafinowanych narzędzi z pogranicza systemów do zarządzania wiedzą. |
Uratować projekt | (2005.12.27) | | Wszyscy je znamy, choćby ze słyszenia. Projekty realizowane przez zdemotywowanych, coraz bardziej przemęczonych ludzi. Projekty o nieokreślonym terminie zakończenia. Projekty, których produkt końcowy nie nadaje się do pokazania komukolwiek. |
Mam malować? | (2005.12.12) | | Mając możliwość osobistej weryfikacji kandydata na stanowisko programisty, warto przyglądać się bezpośrednio stylowi jego pracy, czyli pospolicie rzecz ujmując patrzeć mu na ręce. Ta część ''wywiadu'' bardzo dużo mówi o jego umiejętnościach i wprawie warsztatowej. |
Czas zacząć na nowo | (2005.10.10) | | Przyzwyczailiśmy się do tego, że wytwarzanie oprogramowania musi wyglądać tak, jak dzisiaj wygląda. Tymczasem niektórzy kwestionują to przekonanie, twierdząc, że musimy głęboko przewartościować paradygmaty obowiązujące dzisiaj w IT. |
Rozpoznanie bojem | (2005.08.29) | | By rzeczywiście zadbać o ergonomię i użyteczność produktu informatycznego, do jego testów należy zaangażować użytkownika. |
Program w urządzeniu | (2005.08.15) | | Polscy informatycy i inżynierowie zajmują się tworzeniem oprogramowania, które steruje odbiornikami telewizji cyfrowej produkowanymi przez Samsunga. Należące do koreańskiego koncernu warszawskie Centrum Badań i Rozwoju Oprogramowania to jeszcze jeden dowód na to, że Polska staje się atrakcyjnym miejscem lokalizacji ośrodków deweloperskich dla światowych firm z branży teleinformatycznej. |
Konstruktywny model | (2005.07.18) | | Praktyka projektowa pokazuje, że nawet kwalifikowane oszacowanie złożoności tworzonego oprogramowania nie gwarantuje wyznaczenia czasowych ram realizacji przedsięwzięcia. Warto zatem sięgnąć po sprawdzone narzędzia inżynierii oprogramowania, wspomagające procesy estymacyjne. |
Jakość na każdym etapie | (2005.06.20) | | Zarządzanie jakością oprogramowania wymaga odpowiedniego ustawienia procesów wytwórczych w całym cyklu jego tworzenia. |
Permanentny kryzys | (2005.05.02) | | Tytułowe określenie pojawiło się w technologii informatycznej kilkadziesiąt lat temu. Czy jest nadal aktualne? Dziesięciolecia branżowych doświadczeń wskazują na bardziej precyzyjną, ale ciągle niejednoznaczną odpowiedź. |
Jakość po japońsku | (2005.04.04) | | W ostatnich latach nareszcie nastąpiło systematyczne podejście do problemu testowania oprogramowania. Widać to w tematyce konferencji, publikacji prasowych, ukazujących się książek; wreszcie po ogłoszeniach o pracę i pojawiających się ofertach specjalnych centrów testowych. Im większy nacisk kładzie się na testowanie, tym bardziej należy zadawać pytanie: dlaczego musimy testować? Gdzie - i dlaczego! - zawiódł proces wytwórczy, że tak intensywna kontrola jakości na jego wyjściu jest konieczna? Odpowiedzi mogą nam podsunąć systemy jakości dla przemysłu. |
|
|