Wyniki wyszukiwania dla „wymagania” – Strona 24 – Jarosław Żeliński IT-Consulting

Kolejna wpadka IT: obiektowość

obiektowość jako panaceum na problemy programistów i programowania to w moich oczach jak najbardziej wpadka. Obiektowość jako skuteczne metoda analizy “świata” i jego modelowania to sukces, ale to tylko kontynuacja rozwoju ogólnej teorii systemów. Obiektowość dała tej teorii bardzo dobre narzędzie – obiektowe metody modelowania. Specyfikowanie wymagań w postaci czarnej skrzynki się nie sprawdza, statystyki porażek projektów są niezmienne od lat. Specyfikacja wymagań w postaci projektu jest niemalże doskonałe (ale tylko tak jak doskonały jest projekt).

Czytaj dalej

Czy nadeszła śmierć strategii?

Tak więc proponuję praktykom uważającym, że strategia jest już zbędna, podziękować. Podobnie proponuję podziękować także konsultantom, którzy uważają, że strategia to szczegółowy plan na wiele lat. Nie ma sensu re-definiowanie tych pojęć na chwilowe potrzeby “mody” czy nawet demagogicznego uzasadniania sensu jakiegoś projektu. To i tak na nie zadziała w dalszym horyzoncie działań. Strategia to deklaracja na długi okres, w konsekwencji nie ma sensu by była “szczegółowa”, ona ma być ogólna ale musi być “konkretna”, musi pozwalać na stwierdzenie w dowolnym momencie, czy to co robimy lub planujemy zrobić (taktyka i podejmowane zadania) jest zgodne z naszą strategią czy nie. W przeciwnym wypadku mamy problem albo ze strategią, albo z planowanymi działaniami, albo z jednym i drugim 🙂 czyli z zarządzaniem w ogóle.

Czytaj dalej

Jak połączyć prywatne z firmowym w jednym urządzeniu?

Tak więc bezpieczeństwo powinno być raczej elementem wymagań w postaci “oczekiwany efekt” a nie “jak je zapewnić”. Nie rozumiem dlaczego tak wielu analityków i działy IT wzbraniają się przed uznaniem, że oprogramowanie powinno być dostępne na dowolnym urządzeniu mobilnym i że nie powinno pozwalać na…, i tu określone ograniczenia. Moim zdaniem bezpieczeństwo powinno być definiowane (wymagania) poprzez ryzyka, których chcemy uniknąć w określonym, biznesowo oczekiwanym (a nawet zastanym) środowisku, a nie poprzez narzucanie konkretnego sposobu i technologii, w szczególności przymusu korzystania z konkretnego sprzętu czy oprogramowania.

Czytaj dalej

Proces to strategia nie taktyka

Jednym z największych błędów popełnianych w projektach związanych z modelowaniem procesów biznesowych jest zapominanie o tym, że model procesu to model organizacji a nie tylko dokument, i o tym, że pomiędzy procesami a procedurami, umiejętnościami, instrukcjami obsługi narzędzi, jest granica. To się nazywa utrata panowania nad złożonością projektu. Kolejny problem to powszechne traktowanie notacji (np. BPMN) jako biblioteki symboli, co jest kluczowym błędem: notacja to model pojęciowy – podstawowe narzędzie analizy i modelowania.

Czytaj dalej

CASE czyli komputerowe wspomagania analizy i projektowania systemów

I teraz sedno czyli co nam daje dobre narzędzie CASE? otóż powyższe macierze (takie i każdą inną) oraz model analizy wpływu, są generowane i aktualizowane automatycznie. Wystarczy opracować standardowe modele w BPMN i UML jak powyżej, wskazać związki pomiędzy elementami jako ich parametry (nie trzeba do tego celu tworzyć sztucznych diagramów) i skorzystać z możliwości automatyczne dokumentowania tych związków.

Czytaj dalej

Tak zwane projekty internetowe

Projektując internetowy system obsługi klienta tak na prawdę rozwiązujemy dwa zupełnie odrębne problemy: musimy zastąpić sprzedawcę naszą nową stroną WWW oraz obsłużyć zdarzenia, które wygeneruje nasz (tu wirtualny) sprzedawca.

Mamy więc niejako dwa odrębne projekty: opracowanie portalu, i to jest robota dla agencji interaktywnej. Drugi, to zaprojektowanie i wytworzenie (albo opisanie, zakup gotowego na rynku i zintegrowanie) czysto biznesowego, złożonego, oprogramowania “wypchanego” trudną i złożoną logika biznesową. Dlatego takie projekty należy dzielić na komponenty, na dwa (pod)projekty, z których każdy można (i ma to sens) realizować odrębnymi metodami pracy. Pierwszy (portal) zwinnie, drugi – planując i projektując.

Czytaj dalej

A po co nam ten SWOT

Wielu właścicieli firm, ich zarządy, pomija ten etap w projektach z uwagi na swoje przekonanie, że ich dotychczasowe działania i chęć ich kontynuacji, nie wymagają żadnej korekty, oczekują podania na tacy opisu narzędzia, którego – jak sądzą – potrzebują. Zachowują się jak pacjenci, którzy mimo, że ostatnie badania robili wiele lat temu, nie dopuszczają myśli, że lekarz może im przepisać na gorączkę coś innego niż kolejną aspiryną. Bywa, że zbyt późno odkrywają, że tym razem to nie było kolejne przeziębienie.

Czytaj dalej

Ile jest tych wymagań na system ERP

Wymagania na złożone systemy, zdefiniowane jako zestaw testów są znacznie efektywniejsze i bezpieczniejsze, niż detaliczna specyfikacja prostych funkcji. Tworzenie testów wymaga jednak określenia biznesowego celu wdrożenia i zrozumienia tego jak organizacja funkcjonuje (opracowanie modeli).

Praktyka pokazuje, że koszt analizy i opracowania takich testów jest znacznie niższy niż nieplanowany dodatkowy koszt projektów (średnie przekroczenie budżetu to ponad 60%).

Czytaj dalej