Obiekt ekonomiczny

1. Obecnie najczęściej wykorzystywane systemy informacyjne w dziedzinie ekonomii i zarządzania ukierunkowane są głównie na usprawnianie zarządzania w celu lepszego zaspokajania potrzeb wszystkich uczestników procesów gospodarczych.

2. Interpretacjawskaźników Rozumieniesytuacji Analizadanych Wiedza potrzebna na szczebluzarządzania taktycznego Gromadzeniedanych Podejmowaniedecyzji Prostekierowanienakazowe Obiekt ekonomiczny Strategia ekonomiczna

3. Najważniejsze kierunki innowacji wprowadzanych w systemach informacyjnych oparte są o wymagania: • integracji systemów, danych i procesów, • unifikacji funkcji cząstkowych systemów, • zwiększania dostępności do bazy danych dla wszystkich komórek organizacyjnych, • upowszechniania nowoczesnych sposobów prezentacji danych (wizualizacji) dla celów wspomagania ich analizy, • doskonalenia procesów podejmowania decyzjii ich przekazywania, • zmierzania do budowy modułowej i otwartości całego systemu,

4. Dalsze wymagania dotyczące projektowanego systemu są następujące: • zapewnienia kompleksowego charakteru funkcjonalnego całego systemu, • stałego podnoszenia zaawansowania merytorycznego i technologicznego, • zmierzania do elastyczności funkcjonalnej i strukturalnej, • zapewnienia stałej zgodności ze zmieniającymi się elementami otoczenia systemowego, a zwłaszcza z aktualnym stanem prawnym, ewoluującym zgodnie z przyjętymi procedurami legislacyjnymi.

5. Ekonomiczne systemy informacyjne są projektowane i realizowane w taki sposób, aby dane przetwarzane przez ów system były bezpieczne i na każdym jego etapie chronione. Dlatego też w jak największym stopniu musi być zapewniona poufność i integralność wszelkich danych posiadanych przez system, a dostępność do danych zawartych w systemie powinna być zgodna z przyjętą hierarchią haseł i przywilejów dostępu.

6. Mimo wielu lat rozwoju ryzyko prowadzenia projektów informatycznych nadal jest duże. W USA rozwój oprogramowania pochłania rocznie 250 mld dolarów rocznie, w postaci około 175 tys. projektów informatycznych. Badania Standish Group dla rynku Amerykańskiego dowodzą, że 31% z tych projektów jest przerywanych na jednym z etapów pośrednich, zaś 52% projektów przekracza planowany budżet. Typowy system informatyczny jest droższy niż planowano o średnio 89%.

7. Dlatego niezbędna jest właściwa metodologia projektowania i wdrażania systemów informatycznych.Stosowną metodologię dostarcza głównie inżynieria oprogramowania

8. Inżynieria oprogramowania jest praktycznym zastosowaniem wiedzy naukowej do projektowania i tworzenia systemów informacyjnych i informatycznych oraz dokumentacji wymaganej do ich opracowania, uruchomienia oraz pielęgnacji.

9. Fazy projektowania zgodnie z metodologią inżynierii oprogramowania

10. Najnowsze prace odwołujące się do inżynierii oprogramowania przewidują występowanie aż 12 faz procesu projektowego.

11. Inicjalizacja systemu i wstępne planowanie: Znalezienie potencjalnego obszaru zastosowania systemu informatycznego, który wspomoże lub zastąpi dotychczasowe metody przetwarzania informacji. • Analiza wymagań i specyfikacja wymagań: Identyfikacja problemów, które nowy system informacyjny ma rozwiązać. Zarysowanie właściwości operacyjnych systemu, wydajności i zasobów sprzętowych niezbędnych do użytkowania i konserwowania systemu.

12. 3. Specyfikacja funkcjonalna i prototypowanie: Identyfikacja i formalizacja obiektów obliczeń, ich atrybutów i zależności. Specyfikacja transformacji, którym obiekty będą podlegać. 4. Dekompozycja problemu:Podział systemu na logiczne podsystemy na podstawie wymagań i specyfikacji. Analiza logicznych podsystemów pod kątem użycia już istniejących komponentów informatycznych. Selekcja rozwiązań: wykonać samodzielnie, kupić, wykorzystać już istniejące.

13. 5. Projekt architekturalny i specyfikacja konfiguracji:Określenie zależności pomiędzy podsystemami, komponentami i modułami w sposób uwzględniający szczegóły ich budowy i wymagania wobec nich. 6. Szczegółowe projektowanie i specyfikacja komponentów: Opracowanie i kodyfikowanie metod przetwarzania informacji w komponentach.

14. 7. Implementacja komponentów i usuwanie błędów: Wytwarzanie kodu źródłowego komponentów na podstawie uprzednich specyfikacji. Testowanie podstawowych funkcji komponentów. 8. Asemblacja systemu i testowanie: Weryfikacja komponentów pod kątem kompletności i zgodności ze specyfikacją. Asemblacja produktu z komponentów, weryfikacja wydajności podsystemów systemu jako całości.

15. 9. Przegląd dokumentacji i dostarczenie systemu: Opracowywanie i systematyzowanie dokumentacji powstałej w trakcie prowadzenia projektu pod kątem raportów dla odbiorcy. 10. Opracowanie procedur instalacyjnych i instalacja: Opracowanie dokumentacji instalacyjnej opisującej sposób instalacji systemu.

16. 11. Szkolenie dla użytkowników: Zapoznanie użytkowników z systemem. Zapoznanie ich z możliwościami i ograniczeniami systemu. 12. Użytkowanie i konserwacja oprogramowania:Użytkowanie, usuwanie błędów dostrzeżonych w trakcie użytkowania, rozbudowywanie systemu o nowe właściwości, poprawa wydajności systemu.

17. Jednak nawet najlepsza metodologia nie zabezpiecza przed błędami, bo istnieje luka poznawcza w projektach informatycznych

18. Zagadnienia zaliczające się do luki poznawczej, nie są w trakcie analizy dostrzegane i nie zostaną wyczerpująco opracowane, można więc określać je mianem ryzykownych punktów projektu.Wokół tych zagadnień Boehm zbudował spiralny model tworzenia oprogramowania

20. Praktyczna realizacja metodologii spiralnej

21. Rozważa się także rozwinięcie modelu spiralnego w oparciu o tzw. teorię Win-Win. Teoria W-W podpowiada, że należy zidentyfikować wszystkich tych, którzy mają wpływ na przebieg i wynik projektu. Mogą to być użytkownicy, inwestorzy, agendy rządowe i ich regulacje prawne, firmy programistyczne itp. Należy określić warunki sukcesu każdego uczestnika procesu (win condition). Należy doprowadzić do negocjacji pomiędzy uczestnikami podczas oceny prototypów, jeśli ich warunki sukcesu wykluczają się.

22. Spiralny model Win-Win

23. Metody kaskadowe i spiralne bywają czasem nadmiernie sformalizowane, dlatego w ostatnich latach zaczęto lansować bardziej swobodną metodykę projektowania systemów informatycznych, nazywaną„agile software development methods”W polskiej literaturze odpowiednie metody zwykło się określać jako „zwinne”.

24. Agile

25. Podstawowe składniki „manifestu” zwolenników „zwinnych” metod projektowania są dosyć oczywistei łatwe do zaakceptowania • ludzie, ich kontakty, zdolność do rozwiązywania problemów są ważniejsze niż sztywne procedury i narzędzia zarządzania, • wynikiem projektu jest pracujące oprogramowanie a nie dokumentacja, • z użytkownikiem się współpracuje a nie negocjuje kontrakt, • ważniejsza jest umiejętność reagowania na zmieniające się warunki otoczenia niż podążanie za opracowanym na wstępie planem.

26. W myśl manifestowanych zasad metody „agile” nie są w istocie nowymi praktykami postępowania w projekcie, bo te są tradycyjne.Nowością jest traktowanie człowieka jako nadrzędnego czynnika sukcesu.

27. Rozwój metodyki projektowania systemów informatycznych w kierunku metod „zwinnych” `

28. Modele z Modele z punktami Sztywne punktami Działania kontrolnymi działania Adaptacyjny kontrolnymi ad-hoc kontraktowe rozwój sterowane sterowane (bez planu) oprogramowania planem ryzykiem XP Metody agile Standard modelu dojrzałości procesu tworzenia oprogramowania (Standard CMM) Skala dojrzałości modeli tworzenia systemów informatycznych pokazuje, że metody „zwinne” można stosować głównie dla niezbyt dużych systemów

29. Cristal

30. Wśród metod zwinnych obecnie można wymienić • Metodyka Crystal (Crystal family), • Projektowanie zorientowane na właściwości (Feature Driven Development), • Modelowanie zwinne (Agile Modeling), • Programowanie ekstremalne (Extreme Programming), • Adaptacyjny rozwój oprogramowania (Adaptive Software Development), • Metodyka scrum (Scrum development), • Prototypowanie (Prototyping methodology), • Szybkie programowanie internetowe (Internet Speed Development), • Pragmatyczne programowanie (Pragmatic Programming).

31. Jedna ze „zwinnych” metodologii, nazywana Crystal

32. Metodyka Cristal ma odmiany w zależności od stopnia krytyczności projektu (kategoryzowanego poprzez litery C, D, E, L – objaśnione dalej) i w zależności od jego rozmiaru, mierzonego liczbą projektantów zaangażowanych w tworzenie projektu.

33. Kategorie krytyczności projektowanego systemu: • C - Komfortowe (Comfort), • D - Zarządzające Finansami (Discretionary Money), • E - Finansowo istotne (Essential Money) • L - Krytyczne dla Życia (Life Critical)

34. Na tej podstawie proponowana jest cała rodzina metod typu Cristal. Ich mapa podana jest niżej.

35. FDDProjektowanie zorientowane na właściwości

36. Projektowanie zorientowane na właściwości (FDD-Feature Driven Development) Projekt w myśl FDD składa się z pięciu sekwencyjnie następujących etapów, które będą kolejno opisane.

38. Założeniem leżącym u podstaw FDD jest inkrementacyjne opracowywanie poszczególnych funkcjonalności systemu (features). Prace rozpoczynają się od określenia „ogólnego modelu systemu”. Zespół projektantów korzysta z opracowanych wcześniej wymagań systemowych i przypadków użycia. Określana jest domena projektu i iteracyjnie dzielona na coraz to mniejsze znaczeniowo obszary.Każdy niepodzielny obszar znaczeniowy jest opracowywany przez przypisaną do niego grupę projektantów, w wyniku czego powstaje model szczegółowy, będący składnikiem całościowego modelu systemu.

40. W następnym etapie na podstawie specyfikacji wymagań systemowych oraz opracowanego modelu/modeli opracowywane są listy funkcjonalności. Listy te mają charakter hierarchiczny i zawierają funkcjonalności główne, które rozpadają się na zestawy funkcjonalności w kolejnych hierarchiach. Listy te są przeglądane przez użytkowników i inwestorów w celu kontroli poprawności i kompletności.

42. Planowanie nakłada na kierownictwo projektu obowiązek opracowania długookresowego planu prac powiązanego z funkcjonalnościami, ich zależnościami i priorytetami. Poszczególne elementy listy funkcjonalności przydzielane są zespołom a w ich ramach konkretnym programistom – opiekunom klas. Klasa jest tu rozpatrywana w rozumieniu programowania obiektowego.

44. Kolejne fazy: Projektowanie funkcjonalnościiwykonanie funkcjonalności wykonuje się iteracyjnie i jeśli to możliwe równolegle.

45. Każda funkcjonalność znajduje swą realizację wewnątrz obiektu (klasy), do każdej klasy przyporządkowany jest programista dbający o jej spójność, poprawność i efektywność kodu.Jest on zarządzający obiektem (klasą). Zarządzający obiektami są formowani w małe zespoły (feature teams). Sposób organizacji zespołów w przybliżeniu odzwierciedla hierarchię funkcjonalności.

46. Istotną postacią w zespole projektowym jest zarządca konfiguracji zajmujący się zagadnieniami kontroli wersji i identyfikacją każdej „historycznej” wersji kodu źródłowego.

47. DSDMMetodyka Projektowania Systemów Zmiennych w Czasie

48. Inną ważną metodologię projektowania zaproponowało brytyjskie konsorcjum DSDM.Biorąc pod uwagę fakt, że zadania związane z projektowanym systemem zawsze podlegają zmianom opracowano Metodykę Projektowania Systemów Zmiennych w Czasie DSDM(Dynamic Systems Development Methods)

49. Proces DSDM składa się z: • inspekcji zastosowalności, • badań biznesowych, • iteracyjnego opracowania modelu funkcjonalnego (Functional model iteration), • iteracyjnego projektowania i implementacji (Design and build iteration), • wdrożenia.

50. Inspekcja zastosowalności wykonywana jest jednokrotnie na początku projektu po to aby potwierdzić zasadność stosowania metody DSDM.W trakcie tej fazy wstępnie określa się ryzykowne punkty w projekcie, jeśli to niezbędne buduje się prototypy.Rozległość prac w tej fazie jest ograniczona do kilku tygodni.