Projektowanie systemów informatycznych: Różnice pomiędzy wersjami

Z Encyklopedia Zarządzania
m (Dodanie TL;DR)
m (Dodanie MetaData Description)
Linia 127: Linia 127:
[[Kategoria:Zarządzanie informacjami]]
[[Kategoria:Zarządzanie informacjami]]
{{a|Agnieszka Bongila, Szczepan Konik}}
{{a|Agnieszka Bongila, Szczepan Konik}}
{{#metamaster:description|Projektowanie systemów informatycznych - ważne jest, aby organizacja zrozumiała potrzebę zmiany i rozpoczęła prace nad nowym systemem. Projekty IT są skomplikowane, ale sukces zależy od reakcji na różnice między aspektami.}}

Wersja z 17:57, 12 paź 2023

Projektowanie systemów informatycznych
Polecane artykuły


Zazwyczaj w momencie gdy dana organizacja uświadamia sobie potrzebę zmian, rozpoczyna ona pracę nad zaprojektowaniem nowego systemu informatycznego. Bardzo istotnym jest tutaj fakt, że w momencie gdy w organizacji panuje totalny chaos, komputeryzacja jedynie go pogłębi, natomiast gdy kondycja przedsiębiorstwa plasuje się na wysokim poziomie wprowadzenie technologii informacyjnej sprawi jedynie, że działania firmy będą jeszcze bardziej efektywne. Nie bez znaczenia jest także fakt, że pracownicy zazwyczaj boją się zmian. Ich obawy nie są jednak do końca uzasadnione. To oni bowiem posiadają niezbędną wiedzę, która wykorzystywana jest przy tworzeniu owych systemów. Są w tym aspekcie nie do zastąpienia.

Projekty IT mają pewne cechy, które odróżniają je od innych projektów inżynieryjnych, Należą do nich zwiększona złożoność i większe szanse na niepowodzenia projektu. Aby zwiększyć szanse na to, aby projekt informatyczny był postrzegany jako pomyślny przez wszystkie strony zaangażowane w projekt od jego koncepcji, rozwoju i wdrażanie jest konieczne określenie początku na samym początku projektu, jakie czynniki wpływają na jego sukces. Wielu pisarzy uznało identyfikację i reakcję na różnice między twardymi a miękkimi aspektami projektów, które mogą wpłynąć na ich sukces. Należy nie tylko spostrzegać różnice pomiędzy miękkim a twardym podejściem do projektu, ponieważ to od tego zależy sukces tego projektu. Bezpośrednie połączenie między identyfikacją typu projektu i możliwością wyboru odpowiednich metod projektowania została również powiązana z sukcesem projektu. Wspieranie związku między sukcesem projektu a jego identyfikacją lub twardym a miękkim charakterze, sprawia, że projekty często są postrzegane jako nieudane, ponieważ kierownicy projektów nie zwracają należytej uwagi na prawidłową metodykę projektowania systemów informatycznych.

TL;DR

Artykuł porusza temat projektowania systemów informatycznych w organizacjach. Wskazuje, że wprowadzenie technologii informacyjnej może zwiększyć efektywność działania przedsiębiorstwa, ale wymaga dokładnego zrozumienia potrzeb i obaw pracowników. Artykuł omawia również różnice między "twardym" i "miękkim" podejściem do projektowania systemów, przedstawiając cechy i zastosowanie obu metod. Wskazuje również na etapy projektowania systemu i przedstawia przykład projektowania systemu zarządzania zasobami.

Miękka metoda systemowa

[1] Podejście inżynieryjne może się okazać niewłaściwym dla "miękkich problemów" czyli takich, które mają niejasne wymagania. Należy tutaj sięgnąć po miękką metodę systemową, której charakterystykę postaramy się teraz przedstawić. Okazuje się, że stawia ona sobie następujące założenia:

  • organizacyjne problemy są nieuporządkowane lub słabo zdefiniowane,
  • członkowie organizacji interpretują problemy w różny sposób (nie ma obiektywnej wersji),
  • czynniki ludzkie są ważne,
  • istnieje potrzeba zastosowania kreatywnego, opartego na intuicji podejścia do rozwiązywania problemów,
  • potrzebujemy raczej lepszego zrozumienia problemu niż konkretnego rozwiązania.

Najprościej mówiąc, miękkie systemy będą zatem luźnymi strukturami narzędzi używanymi do analizy możliwych usprawnień dla problemów organizacji. Zaletami tej metody są: możliwość redefiniowania celów, wskazania obszarów sprawiających szczególne problemy, określenia systemów jakich potrzeba by zapobiec zakłóceniom a co za tym wszystkim idzie - uzdrowieniu organizacji. Poprzez zastosowanie tego podejścia poznaje się ludzi tworzących organizację, zaczyna się rozumieć ich zachowania, problemy. Możliwa jest także ich modyfikacja. Zakłada się tutaj przeprowadzenie zmiany organizacyjnej. Jeśliby jedynie dostrzegać rolę komputera, niemożliwym byłoby uniknięcie niepowodzenia.

Twarda metoda systemowa

Z kolei ta metoda opiera się na następujących założeniach:

  • członkowie organizacji interpretują problemy w ten sam sposób,
  • problemy te są dobrze sformułowane, zrozumiałe dla wszystkich,
  • przede wszystkim czynniki techniczne są ważne,
  • do rozwiązywania problemów stosuje się podejście naukowe,
  • szuka się idealnego rozwiązania.

Twarda metoda systemowa pozwala na głębsze spojrzenie na części systemu. Jest blisko powiązana z celami organizacji oraz zadaniami. Zakłada się, że każdy system może zostać rozłożony na pewną liczbę podsystemów. W podejściu twardym uważa się, że system ma jasno określony cel oraz prawidłowo definiowane cele oraz jest przydatny do projektowania rozwiązań, które pozwalają osiągnąć te cele. Jest to model, który ma precyzyjny cel, a cele te można wyrazić ilościowo, umożliwiając opracowanie modeli matematycznych. Przyjmuje się, że istota podejścia opartego na twardym podejściu składa się z wielu podsystemów oraz, że elementy tych podsystemów można zidentyfikować i określić ilościowo w celu wyjaśnienia działań tych podsystemów. Dlatego cały system jest połączeniem wszystkich podsystemów.

Różnorodne narzędzia, takie jak techniki diagramowania, strukturyzowane schematy procesów i matematyczne reprezentacje oparte na zastosowaniu techniki nauki zarządzania, używane są do opisu i analizy systemów. Twarde podejście składa się z różnych etapów, a te etapy obejmują świadomość i zaangażowanie, ograniczenia, zadania i cele, generowanie alternatyw, ocenę alternatyw i budowę modelu, ocenę i wdrożenie. Etap świadomości i zaangażowanie polega na rozwijaniu świadomości problemu. Następnie osiągnięte zostaje porozumienie dotyczące celów i zakresu badań oraz podejmowane są próby zdefiniowania problemu. Wtedy zaangażowanie jest bardzo ważne, aby wdrożyć rozwiązanie, ponieważ projekt bez zaangażowania zakończy się niepowodzeniem. W przypadku etapu ograniczeń, zadań i celów, badane są ograniczenia i cele, które są istotne dla systemu, w celu ustalenia charakteru i kierunku organizacji. Charakter i kierunek organizacji zostaje ustalony, co można przedstawić w formie hierarchii oświadczeń.

Głównym celem istnienia organizacji jest jej misja. Misje te są celami firm zarówno w perspektywie długoterminowej jak i średniej. Po etapie ustalenia celów następuje etap rozważania alternatyw związanych z problemami w realizacji zadań i celów. Jeśli nie istnieją alternatywy, system, misja oraz cele są ponownie oceniane w celu stworzenia przeglądu analizy. Następnie na etapie oceny alternatyw, mierzone zostają alternatywy w oparciu o zestaw kryteriów pozwalających na dokonanie oceny wartości dotyczącej skuteczności proponowanych ścieżek dla obiektywnych osiągnięć. Ponadto, wskaźniki wydajności można sklasyfikować jako cztery: efektywność, wydajność, kapitał i skuteczność. Ostatecznie, na etapie budowy modelu, oceny i wdrożenia, do stworzenia systemu potrzeba systematycznie tworzyć dokumentację opisów oraz ocen w celu ustalenia jego wiarygodności oraz ocen alternatywnych sposobów osiągnięcia celów.

Znacznie częściej wykorzystywane podejście od podejścia miękkiego. Twarde systemy będą więc definiowane jako sztywne techniki i procedury stosowane aby dostarczyć niedwuznaczne rozwiązania dla dobrze zdefiniowanych problemów przetwarzając je w oparciu o techniki komputerowe.

Porównanie metod

TWARDE METODY PROJEKTOWANIA SYSTEMÓW MIĘKKIE METODY PROJEKTOWANIA SYSTEMÓW
jest jeden problem, ma określone rozwiązanie jest wiele problemów, które trzeba rozwiązać
istnieją cele osiągalne cele nie mogą zostać zmierzone
odpowiadają na pytanie "jak" nacisk kładziony jest na pytania "co" i "jak"
problem ma tu zdeterminowaną złożoność problem ma nieprzewidywalną, niedefiniowalną złożoność
znane są parametry ewentualnych błędów trudno sobie poradzić z błędami

Przykład

[2]

W tym miejscu chciałabym przedstawić pewien przykład zastosowania twardego podejścia w projektowaniu systemów informatycznych. Problem brzmi:

Zaprojektuj wirtualny system zarządzania zasobami, gdzie będą one przechowywane w biurach pracowników lecz szeroko dostępne poprzez sieć internetową. Zasoby te będą rezerwowane przez system zarządzania on-line, którego zadaniem będzie także wysyłanie upomnień kiedy nadejdzie termin ich zwrotu.

Najpierw należy zidentyfikować pewne oczywiste wymagania dla stworzenia takiego systemu. Należy tutaj skupić się nad następującymi elementami:

  • SIEĆ INTERNETOWA:
  • serwer -platforma,
  • klient - wyszukiwarka,
  • SYSTEM REZERWACJI:
  • UŻYTKOWNICY:
  • pracownicy,
  • studenci,
  • administratorzy
  • ZASOBY:
  • książki,
  • czasopisma,
  • płyty CD.

Kolejnym krokiem będzie przeprowadzenie odpowiedniej analizy właściwego zestawu wymagań. W tym miejscu należy zrozumieć zasięg problemu, zidentyfikować i uszczegółowić poszczególne wymagania, które stworzą właściwe rozwiązanie. Następnie trzeba je połączyć. Teraz przystępujemy do projektowania. Analiza problemu wskazuje na główne komponenty zawarte w systemie, nie mówi nam jednak w jaki sposób ten system działa. Projektowanie zawiera więc

  • identyfikację granic głównych komponentów,
  • dekompozycję głównych komponentów w mniejsze częściowo niezależne podsystemy,
  • zaprojektowanie obszarów wzajemnego oddziaływania pomiędzy tymi głównymi komponentami a podsystemami,
  • identyfikację nowych, koniecznych do załatania dziur pomiędzy problemem a rozwiązaniem.
  • przepływ kontroli wewnątrz systemu,
  • przepływ danych wewnątrz systemu.

Przedostatnim etapem jest wdrożenie zaprojektowanego systemu. Oznacza to nic innego jak przetłumaczenie projektu na kod źródłowy:

  • dla każdego zidentyfikowane komponentu i zależności, wyszczególnionych w fazie projektowania należy zaprojektować kod źródłowy,
  • należy dokonać integracji zakodowanych komponentów tak aby tworzyły spójny system.

Teraz następuje przetestowanie stworzonego systemu:

  • sprawdzenie czy każdy element, podsystem, komponent działa tak jak to zaprojektowano,
  • sprawdzenie czy system spełnia stawiane przed nim wymagania,
  • sprawdzenie czy system spełnia oczekiwania klientów oraz użytkowników.

Bibliografia

Przypisy

  1. Targowski A, Strategia i architektura systemów informatycznych w przedsiębiorstwie, Nowe Wydawnictwo Polskie, Warszawa 1992
  2. Cairns D., Hard versus Soft Systems Methodology [w:] Business English Magazine, nr 14/2009

Autor: Agnieszka Bongila, Szczepan Konik