Projektowanie systemów informatycznych: Różnice pomiędzy wersjami
(LinkTitles.) |
mNie podano opisu zmian |
||
(Nie pokazano 12 wersji utworzonych przez 2 użytkowników) | |||
Linia 1: | Linia 1: | ||
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'''. | 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. | 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'''. | '''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== | ==Miękka metoda systemowa== | ||
<ref>Targowski A, ''[[Strategia]] i architektura systemów informatycznych w przedsiębiorstwie'', Nowe Wydawnictwo Polskie, Warszawa 1992</ref> | <ref>Targowski A, ''[[Strategia]] i architektura systemów informatycznych w przedsiębiorstwie'', Nowe Wydawnictwo Polskie, Warszawa 1992</ref> | ||
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: | 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, | * organizacyjne problemy są nieuporządkowane lub słabo zdefiniowane, | ||
* członkowie organizacji interpretują problemy w różny sposób (nie ma obiektywnej wersji), | * członkowie organizacji interpretują problemy w różny sposób (nie ma obiektywnej wersji), | ||
Linia 32: | Linia 17: | ||
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. | 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. | ||
<google>n</google> | |||
==Twarda metoda systemowa== | ==Twarda metoda systemowa== | ||
Z kolei ta [[metoda]] opiera się na następujących założeniach: | Z kolei ta [[metoda]] opiera się na następujących założeniach: | ||
* członkowie organizacji interpretują problemy w ten sam sposób, | * członkowie organizacji interpretują problemy w ten sam sposób, | ||
Linia 42: | Linia 28: | ||
* szuka się idealnego rozwiązania. | * 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. | '''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ń. | 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ń. | ||
Linia 51: | Linia 37: | ||
==Porównanie metod== | ==Porównanie metod== | ||
{| border =''1'' | {| border =''1'' | ||
|'''TWARDE METODY PROJEKTOWANIA SYSTEMÓW''' | |'''TWARDE METODY PROJEKTOWANIA SYSTEMÓW''' | ||
Linia 59: | Linia 44: | ||
|jest wiele problemów, które trzeba rozwiązać | |jest wiele problemów, które trzeba rozwiązać | ||
|- | |- | ||
|istnieją [[cele]] osiągalne | |istnieją [[cele]] osiągalne | ||
|cele nie mogą zostać zmierzone | |cele nie mogą zostać zmierzone | ||
|- | |- | ||
|odpowiadają na pytanie "jak" | |odpowiadają na pytanie "jak" | ||
|nacisk kładziony jest na pytania "co" i "jak" | |nacisk kładziony jest na pytania "co" i "jak" | ||
|- | |- | ||
Linia 68: | Linia 53: | ||
|problem ma nieprzewidywalną, niedefiniowalną złożoność | |problem ma nieprzewidywalną, niedefiniowalną złożoność | ||
|- | |- | ||
|znane są parametry ewentualnych błędów | |znane są parametry ewentualnych błędów | ||
|trudno sobie poradzić z błędami | |trudno sobie poradzić z błędami | ||
|} | |} | ||
Linia 81: | Linia 66: | ||
Najpierw należy zidentyfikować pewne oczywiste wymagania dla stworzenia takiego systemu. Należy tutaj skupić się nad następującymi elementami: | Najpierw należy zidentyfikować pewne oczywiste wymagania dla stworzenia takiego systemu. Należy tutaj skupić się nad następującymi elementami: | ||
* SIEĆ INTERNETOWA: | * SIEĆ INTERNETOWA: | ||
:*serwer -platforma, | :* serwer - platforma, | ||
:*[[klient]] - wyszukiwarka, | :* [[klient]] - wyszukiwarka, | ||
* SYSTEM REZERWACJI: | * SYSTEM REZERWACJI: | ||
:*[[kontrola]] przepływu zasobów, | :* [[kontrola]] przepływu zasobów, | ||
:*[[baza danych]], | :* [[baza danych]], | ||
* UŻYTKOWNICY: | * UŻYTKOWNICY: | ||
:*pracownicy, | :* pracownicy, | ||
:*studenci, | :* studenci, | ||
:*administratorzy | :* administratorzy | ||
* ZASOBY: | * ZASOBY: | ||
:*książki, | :* książki, | ||
:*czasopisma, | :* czasopisma, | ||
:*płyty CD. | :* 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ć. | 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ć. | ||
Linia 112: | Linia 97: | ||
* sprawdzenie czy system spełnia stawiane przed nim wymagania, | * sprawdzenie czy system spełnia stawiane przed nim wymagania, | ||
* sprawdzenie czy system spełnia oczekiwania klientów oraz [[użytkownik]]ów. | * sprawdzenie czy system spełnia oczekiwania klientów oraz [[użytkownik]]ów. | ||
{{infobox5|list1={{i5link|a=[[Plan zarządzania interesariuszami]]}} — {{i5link|a=[[Metoda prognostyczna]]}} — {{i5link|a=[[Analiza diagnostyczna]]}} — {{i5link|a=[[Modelowanie procesów]]}} — {{i5link|a=[[Metodyka społeczna Checklanda]]}} — {{i5link|a=[[ISO 9004]]}} — {{i5link|a=[[Analiza SWOT]]}} — {{i5link|a=[[Podejście systemowe]]}} — {{i5link|a=[[Wzorce projektowe]]}} }} | |||
==Przypisy== | |||
<references /> | |||
==Bibliografia== | ==Bibliografia== | ||
<noautolinks> | |||
* Buttle F. | * Buttle F. (2004), ''Customer Relationship Management'', Routledge, London | ||
* Rajibun H., Hard and Soft Systems Thinking, University of Lincoln | * Rajibun H. (2011), ''Hard and Soft Systems Thinking'', University of Lincoln | ||
* Summer M. | * Summer M. (2007), ''[https://link.springer.com/article/10.1007/s12599-015-0409-x Business Process Management]'', Business & Information Systems Engineering, nr 58 | ||
</noautolinks> | |||
{{a|Agnieszka Bongila, Szczepan Konik}} | |||
[[Kategoria:Systemy informatyczne]] | |||
{{#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.}} | |||
{{ |
Aktualna wersja na dzień 11:33, 22 gru 2023
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
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:
- kontrola przepływu zasobów,
- baza danych,
- 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.
Projektowanie systemów informatycznych — artykuły polecane |
Plan zarządzania interesariuszami — Metoda prognostyczna — Analiza diagnostyczna — Modelowanie procesów — Metodyka społeczna Checklanda — ISO 9004 — Analiza SWOT — Podejście systemowe — Wzorce projektowe |
Przypisy
Bibliografia
- Buttle F. (2004), Customer Relationship Management, Routledge, London
- Rajibun H. (2011), Hard and Soft Systems Thinking, University of Lincoln
- Summer M. (2007), Business Process Management, Business & Information Systems Engineering, nr 58
Autor: Agnieszka Bongila, Szczepan Konik