Projektowanie systemów informacyjnych

1. Projektowanie systemów informacyjnych Wykład 13: Elementy cyklu projektowania SI (2) Kazimierz Subieta Instytut Podstaw Informatyki PAN, Warszawa Polsko-Japońska Wyższa Szkoła Technik Komputerowych, Warszawa

2. Cykl życiowy projektu • Planowanie i definicja projektu • Analiza • Analiza dziedziny przedsiębiorczości • Analiza wymagań systemowych • Projektowanie • Projektowanie pojęciowe • Projektowanie logiczne • Projektowanie fizyczne • Konstrukcja • Rozwijanie • Testowanie • Dokumentacja • Przygotowanie użytkowników, akceptacja • Działanie, włączając wspomaganie tworzenia aplikacji

3. Cykl życiowy SI Analiza i Projektowanie Ob. zast. - 1 Realizacja Prototypu 1 Konstrukcja Systemu 1 UTRZYMANIE S I Re - inżynieria Wdrożenie Systemu 1 Studium osiągalności celów (Strategiczny plan rozwoju informatyzacji) ? Analiza i Projektowanie Ob. zast. - 2 Realizacja Prototypu 2 Konstrukcja Systemu 2 Wdrożenie Systemu 2 Wdrożenie Systemu N Konstrukcja Systemu N Realizacja Prototypu N Analiza i Projektowanie Ob. zast. - N Przygotowania do realizacji i wdrożenia SI Kontrola jakości Zarządzanie projektem

4. Podejście iteracyjne Kolejne warianty analizy Kolejne warianty projektu Programowanie top-down SYSTEM INFORMACYJNY Rozwiązywanie problemów projektowych ANALIZA KODOWANIE PROJEKTOWANIE TESTOWANIE Integracja: dążenie do kompletności, unikanie redundancji, unifikacja poziomów abstrakcji, unifikacja struktury dokumentacji, unifikacja technik, unifikacja notacji

5. Podejście metodyczne METODYKA - zbiór zasad dotyczących świadomego i konsekwentnego wykonywania jakiejś pracy lub trybu postępowania prowadzącego do określonego celu. ZARZĄDZANIE PROJEKTEM ZADANIA CELE Planowanie Kontrola JAK? PO CO? FAZY CZYNNOŚCI KROKI JAK ? KTO? CO? CO? TECHNIKI NARZĘDZIA ROLE KTO? CZYM?

6. Przyczyny niepowodzeń w realizacji SI Brak jasno sprecyzowanych celów 17% 20% Brak porozumienia 32% Nieumiejętne zarządzanie 7% 15% Inne 69% NIEPOWODZEŃ to czynniki POZA INFORMATYCZNE 7% Niesprawny sprzęt i oprogramowanie 2% Zła ocena złożoności systemu Wielkość projektu Zródło: Peat Marwic McLintock

7. 1. Brak umiejętności zarządzania pracami projektowo-programowymi w dziedzinie informatyki 2. Zła kontrola jakości, szczególnie we wczesnych fazach cyklu życiowego realizacji systemów informatycznych 3. Dynamika zmian wymagań użytkowych w stosunku do systemów informatycznych Podstawowe zagrożenia w realizacji SI

8. “Kryzys oprogramowania” Słaba przewidywalność czasu, kosztów i trudności Oszacowanie tych wskaźników jest trudne. Projektanci systemów mają trudności ze spełnieniem wymagań użytkowników, które podlegają stałej ewolucji. Systemy kosztują więcej niż zaplanowano i są gotowe znacznie po przewidywanym terminie. Niska jakość programów Programy nie robią tego, czego oczekują od nich użytkownicy, często zawodzą i tracą cenne dane lub czas potrzebny na ich odtworzenie. Jest to zwykle spowodowane nadmiernym pośpiechem w dostarczeniu oprogramowania dla klienta, niekompletnością początkowych wymagań użytkowników lub ich sprzecznością objawiającą się późno w procesie kodowania. Wysoki koszt utrzymania systemów Najczęściej jest to spowodowane kosztami poprawiania systemu i danych lub dodawaniem coraz to nowych cech podczas eksploatacji. Obydwie przyczyny są konsekwencją budowy systemu bez jasnej wizji jego celu i architektury. Wielokrotne zdublowanie tej samej pracy Projekty w małym stopniu wykorzystują zuniformizowane elementy ponownego użycia. Istnieje tendencja budowania każdego systemu od zera. Technologie i języki projektowania i programowania nie sprzyjają użyciu poprzednio wykonanego kodu.

9. Dwie metody opanowania złożoności Usprawnianie narzędzi programistycznych. Najbardziej podstawową metodą jest podwyższanie poziomu języka (zwiekszanie stopnia abstrakcji), uniezależnianie języka od fizycznych własności związanych z typem komputera, sposobem przechowywania i reprezentacji danych, specyficznych interfejsów dostępu do danych. Te własności sprzyjają tworzeniu języków z przenaszalnym (portable) kodem. Podobne środki powinny dotyczyć systemów sterowania zmianami, wzajemnych powiązań pomiędzy składowymi systemu, edytorów, odpluskwiaczy (debuggers), itd. Należy unikać architektur eklektycznych, złożonych z wielu elementów architektonicznych o nispójnych założeniach i interfejsach. Usprawnianie procesów rozwoju oprogramowania. Dotyczy to różnorodnych form zarzadzania projektem: podział pracy, oszacowania i planowanie, kontrakty, zalecenia dotyczące form dokumentacji, ustalenia programów szkolenia. Proces rozwoju może być podzielony na podprocesy, z których każdy może być prowadzony własną techniką i podlegać własnemu zarządzaniu.

10. Wyznaczenie kierunków rozwoju zastosowań informatyki, w oparciu o analizę rzeczywistych potrzeb informacyjnych organizacji Zderzenie celów, ograniczeń i problemów funkcjonowania organizacji z możliwościami ich osiągania i rozwiązywania przy pomocy zastosowanych środków techniki komputerowej Stworzenie nowego systemu informacyjnego w organizacji usprawniającego jej działanie Określenie środków (zasoby ludzkie, sprzęt komputerowy, oprogramowanie narzędziowe) koniecznych dla realizacji i eksploatacji proponowanych zastosowań informatyki Stworzenie dokumentu decyzyjnego, dla kadry kierowniczej organizacji, zawierającego plan rzeczowo-finansowy realizacji całego przedsięwzięcia, obejmujący perspektywę horyzontu czasowego planu Studium osiągalności - Cele

11. Strategiczny plan rozwoju informatyzacji (SPRI) Analiza stanu istniejącego Stan istniejący Re-inżynieria procesów biznesowych (BPR) Priorytety rozwiązań Wymagania eksploatacyjne Architektura systemów informatycznych Wymagania realizacyjne Efekty Metodyka, narzędzia, kadra Konfiguracja sprzętu, oprogramowania i sieci teletransmisji Plan realizacji strategii informatyzacji Koszty Koszty

12. 1. Wywiady z kadrą kierowniczą, analiza dokumentów statutowych A. Określenie celów, ograniczeń działalności, czynników powodzenia B. Opisanie systemu informacyjnego * ogólny model funkcjonalny, * ogólny model danych, * struktura systemu informacyjnego (funkcje a dane) C. Opisanie istniejącego zakresu informatyzacji 2. Analiza Priorytetów Obszarów Zastosowań Informatyki A. Określenie kryteriów ustalania priorytetów obszarów (podniesienie dochodów, obniżka kosztów, poprawa jakości usług) B. Określenie preferencyjnej listy obszarów zastosowañ informatyki SPRI - Analiza stanu istniejącego

13. 1. Określenie koncepcji nowych systemów informatycznych A. określenie zakresu funkcji planowanych systemów B. określenie koncepcji architektury planowanych systemów C. określenie ogólnej charakterystyki wymagań eksploatacyjnych planowanych systemów informatycznych (atrybuty technologiczne: typy struktury danych, typy selekcji danych, rodzaj interfejsu użytkownika, typy reakcji) 2. Analiza priorytetów rozwiązań A. określenie zależności pomiędzy ograniczeniami działalności a proponowanymi systemami informatycznymi B. określenie zależności technologicznych proponowanych systemów C. określenie priorytetów realizacji planowanych systemów informatycznych SPRI - Architektura Systemów Informacyjnych

14. SPRI - Architektura sprzętu, oprogramowania i sieci 1. Określenie koncepcji konfiguracji systemu A. Określenie architektury sprzętu i sieci teletransmisji B. Określenie oprogramowania podstawowego i narzędziowego 2. Ocena podstawowych parametrów eksploatacyjnych 3. Analiza konfiguracji systemów komputerowych 4. Wyznaczenie częstotliwości transakcji SPRI - Realizacja strategii informatyzacji 1. Określenie metodyki realizacji systemów informatycznych 2. Określenie planu realizacji proponowanych systemów informatycznych A.Oszacowanie pracochłonności realizacji proponowanych systemów informatycznych B. Określenie zespołu realizującego (kadra, szkolenia) C. Określenie ogólnego harmonogramu realizacji systemów 3. Określenie planu finansowego przedsięwzięcia A. Oszacowanie kosztów realizacji proponowanych systemów informatycznych B. Oszacowanie kosztów zakupu i eksploatacji proponowanej konfiguracji sprzętu C. Finansowy model przedsięwzięcia

15. Preferencyjna lista obszarów zastosowań informatyki: priorytety wyznaczane w oparciu o efekty mierzalne, efekty niemierzalne oraz prawdopodobieństwo osiągnięcia zamierzonych celów Założenia dotyczące potencjalnych usprawnień w organizacji implikowanych poprzez SI Definicję architektury SI, która obejmuje opis funkcji użytkowych, opis struktury składowych SI, oraz opis zdarzeń związanych z otoczeniem Konfiguracja systemu komputerowego: sprzęt, oprogramowanie narzędziowe i sieć teletransmisji, wraz z wymaganymi parametrami eksploatacyjnymi Plan realizacji proponowanych SI: przebieg realizacji jest opisany planem rzeczowym obejmującym harmonogram prac i konieczne zasoby, oraz planem finansowym dotyczącym całości przedsięwzięcia SPRI - Wyniki

16. Faza definicji wymagań użytkowników Faza jest często określana jako “definicja problemu” lub “koncepcja”. Wymagania użytkowników często wynikają bezpośrednio z założeń SPRI. Jest to podstawowa faza w procesie analizy, która przenika wszystkie jej aspekty. Definicja wymagań uzytkowników jest procesem iteracyjnym. Główne wyniki fazy definicji wymagań użytkowników: • Dokument wymagań użytkowników • Plan zarządzania projektem dla fazy definicji • wymagań na oprogramownie • Plan konfiguracji oprogramowania dla fazy definicji • wymagań na oprogramowanie • Plan weryfikacji i oceny oprogramownia dla fazy definicji • wymagań na oprogramowanie • Określenie planu i założeń zapewnienia jakości dla fazy definicji • architektury • Plan testów akceptacji oprogramowania przez użytkowników.

17. Zalecenia dla fazy definicji wymagań użytkowników Wymagania użytkowników powinny być wyjaśniane poprzez krytykę i porównania z istniejącym oprogramowaniem i prototypami. Powinien być uzyskany stan porozumienia pomiędzy projektantami i użytkownikami dotyczący projektowanego systemu. Wiedza i doświadczenia potencjalnej organizacji podejmującej się rozwoju systemu powinny wspomóc studia nad osiągalnością systemu. W wielu przypadkach dużym wspomaganiem jest budowa prototypów. Wymagania użytkowników powinny być: - jasne, jednoznaczne - weryfikowalne - kompletne - dokładne - realistyczne, osiągalne

18. Objętość, szybkość, dokładność W sformułowaniu wymagań użytkownika są to podstawowe parametry. Objętość: Ilu użytkowników będzie pracować jednocześnie? Ile terminali ma być podłączone do systemu? Ile czujników będzie kontrolowanych jedocześnie? Ile danych będzie przechowywane? Szybkość: Jak długo może trwać operacja lub sekwencja operacji? Liczba operacji na jednostkę czasu. Średni czas niezbędny dla jednej operacji. Dokładność: Określenie stopnia precyzji pomiarów lub przetwarzania. Określenie wymaganej dokładności wyników. Zastąpnienie wyników ilościowych jakościowymi lub odwrotnie.

19. Ograniczenia (1) Wymagania muszą uwzględnić ogromne spektrum różnorodnych ograniczeń: Ograniczenia mogą dotyczyć: Jakości: niezawodności, adaptowalności, przenaszalności, bezpieczeństwa Interfejsów kmunikacyjnych: rodzaju sieci i protokółów sieciowych Sprzętu: całość lub część sprzętu określona przez użytkownków Oprogramowania: kwestia kompatybilności z innym oprogramowaniem (aplikacje, systemy operacyjne, kompilatory, języki programowania, systemy zarządzania bazą danych) Interakcji człowiek-maszyna: styl języka interakcji (komendy, menu, ikony), formaty (zawartość raportów), komunikaty (krótkie, wyczerpujące), czas i jakość odpowiedzi, ograniczenia na sprzęt (mysz, klawiatura, ekran znakowy, ekran graficzny czarno-biały,...) Dostępności: zdolność systemu do użycia w wymaganym okresie czasu: 7 x 24, 5 x 10, cały rok bez okresów przestoju dłuższych niż 2 godz,

20. Ograniczenia (2) Ograniczenia mogą dotyczyć: Przenaszalności: zdolności do przenoszenia oprogramowania do innego środowiska. Zwykle wymaga programowania wysokiego poziomu, co może mieć skutki dla wydajności Poufności: odporności systemu na próby naruszenia tajności, prywatności, integralności i dostępności. Odporność na wirusy, hackerów, wandalizm, sabotaż. Bezpieczeństwa: odporności systemu na awarie sprzętu i oprogramowania. Konsekwencje awarii powinny byc jasno sprecyzowane w wymaganiach. Np. “nie może nastąpić utrata danych w wyniku wyłaczenia zasilania”. Standardów: zgodności systemu, jego interfejsów, narzędzi, technologii z obowiązujacymi standardami, np. w zakresie metodyki projektowania, SQL, CORBA, X-Open, COM,... Zasobów niezbędnych do skonstruowania, wdrożenia i eksploatacji systemu. Ograniczenia mogą dotyczyć finansów, zasobów ludzkich, zasobów materiałowych, sprzętu. Skali czasowej: czas opracowania oprogramowania, czas szkolenia i wdrożenia.

21. Metody zdefiniowania wymagań użytkowników(1) Metody rozpoznania wymagań Wywiady i przeglądy. Wywiady powinny być przygotowane (pytania) i podzielone na odrębne zagadnienia. Podział powinien przykrywać całość tematu i powinny być przeprowadzone na reprezentatywnej grupie użytkowników. Wywiady powinny doprowadzić do szerokiej zgody i akceptacji projektu. Studia na istniejącym oprogramowaniem. Dość często nowe oprogramowanie zastępuje stare. Studia powinny ustalić wszystkie dobre i złe strony starego oprogramowania. Studia wymagań systemowych. Dotyczy sytuacji, kiedy nowy system ma być częścią większego systemu. Studia osiągalności. Określenie realistycznych celów systemu i metod ich osiągnięcia. Prototypowanie. Zbudowanie prototypu systemu działającego w zmniejszonej skali, z uproszczonymi interfejsami.

22. Metody zdefiniowania wymagań użytkowników(2) Metody specyfikacji wymagań Język naturalny. Forma oczywista, najczęściej stosowana. Wadą jest niejednoznaczność wielu wyrazów i sformułowań oraz trudność szybkiego znalezienia wymaganej informacji. Formalizm matematyczny. Stosuje się rzadko, dla dobrze zdefiniowanych problemów raczej o małej skali. Mało przydatny na wczesnych etapach projektu. Język naturalny strukturalny. Język naturalny z ograniczonym słownictwem i składnią. Poszczególne tematy i zagadnienia wyspecyfikowane w punktach i podpunktach. Tablice, formularze. Wyspecyfikowanie wymagań w postaci (zwykle dwuwymiarowych) tablic, kojarzących różne aspekty (np. tablica ustalająca zależność pomiędzy typem użytkownika i rodzajem usługi). Diagramy blokowe: tradycyjna forma graficzna pokazująca wymagany cykl przetwarzania. Diagramy kontekstowe: ukazują system w postaci jednego bloku oraz jego powiązania z otoczeniem, wejściem i wyjściem.

23. Dokument wymagań użytkownika Styl Jasność: jednoznaczne sformułowania, zrozumiały dla użytkowników i projektantów. Strukturalna organizacja dokumentu. Spójność: brak konfliktów w wymaganiach. Modyfikowalność: wszystkie wymagania są sformułowane w jasnych punktach, które mogą być wyizolowane z kontekstu i zastąpione przez inne. Ewolucja Możliwość dodawania nowych wymagań, możliwość istotnej ich modyfikacji Odpowiedzialność Określenie kto jest odpowiedzialny za sformułowanie danego wymagania, istotne w przypadku modyfikacji. Medium Dokument papierowy lub elektroniczny. Staranne kontrolowanie wersji dokumentu.

24. Dokument wymagań użytkownika - zawartość a - Streszczenie b - Spis treści c - Status dokumentu (roboczy, 1-sza faza, zatwierdzony, ...) d - Zmiany w stosunku do wersji poprzedniej Informacje organizacyjne 1. Wstęp 1.1. Cel 1.2. Zakres 1.3. Definicje, akronimy i skróty 1.4. Referencje, odsyłacze do innych dokumentów 1.5. Krótki przegląd 2. Ogólny opis 2.1. Walory użytkowe i przydatność projektowanego systemu 2.2. Ogólne możliwości projektowanego systemu 2.3. Ogólne ograniczenia 2.4. Charakterystyka użytkowników 2.5. Środowisko operacyjne 2.6. Założenia i zależności 3. Specyficzne wymagania 3.1. Wymagania co do mozliwości systemu 3.2. Przyjęte lub narzucone ogranicznia. Zalecany spis treści