Podstawy Inżynierii Oprogramowania

Wielkość: px
Rozpocząć pokaz od strony:

Download "Podstawy Inżynierii Oprogramowania"

Transkrypt

1 Podstawy Inżynierii Oprogramowania II SSI 30 godzin wykładu 15 godzin projektu 1

2 LITERATURA 1. Paul Beynon-Davies, Inżynieria systemów informacyjnych, WNT Warszawa Kazimierz Subieta, Wprowadzenie do inżynierii oprogramowania, Wyd. PJWSTK, Warszawa Barbara Begier, Techniki inżynierii oprogramowania. Metodyki CASE, Wyd. Politechniki Poznańskiej, Poznań Andrzej Jaśkiewicz, Inżynieria oprogramowania, Helion, Gliwice Steve Maguire, Niezawodność oprogramowania, Helion, Gliwice Paul Clements, Rick Kajman, Mark Klein, Architektura oprogramowania, Helion, Gliwice Ron Patton, Testowanie oprogramowania, MIKOM, Warszawa Leszek Maciaszek, Bruc Lee Liong, Practical Software Engineering, Addison Wesley, Harlow England Leszek Maciaszek, Requirements Analysis and System Design, Addison Wesley, Harlow England

3 Podstawy Inżynierii Oprogramowania WYKŁAD 1 Wstęp do inżynierii oprogramowania Definicja modelu cyklu życia oprogramowania 3

4 SYSTEMY INFORMACYJNE WE WSPÓŁCZESNYM PRZEDSIĘBIORSTWIE System spójny zbiór niezależnych składowych, które istnieją w jakimś celu, mają pewną stabilność, mogą być przydatne przy ich łącznym rozpatrywaniu i działają w pewnym otoczeniu. Otoczenie systemu wszystko to, co znajduje się poza systemem i ma wpływ na jego działanie. System: WEJŚCIE PROCES WYJŚCIE WEJŚCIE zasoby, które system pozyskuje ze swojego otoczenia lub innych systemów. PROCES działanie, które przekształca wejście systemu w jego wyjście. WYJŚCIE to co system dostarcza do otoczenia lub innych systemów. 4

5 System informacyjny służy do zarządzania systemem związanym z działalnością człowieka i będzie się składał z przetwarzania danych i przypisania im znaczenia przez człowieka. Rozróżnia się następujące poziomy systemu informacyjnego: Nieformalny system informacyjny zbiór oczekiwań dotyczących komunikowania się ludzi. Rozwijany jest zbiór wzorców zachowań nie sformułowanych, ale poznanych przez pracowników. Formalny system informacyjny na tym poziomie znajdują się jawne nakazy dotyczące zachowania osób w ramach funkcjonowania organizacji, mogą być wyrażone za pomocą zasad, regulaminów i oficjalnej struktury władzy. Skomputeryzowany system informacyjny opisuje przepływ komunikatów o wykonanych transakcjach, zrealizowanych planach, zbadanych problemach, niezbędnych do realizacji zadań organizacji. 5

6 Funkcje obsługi systemu informacyjnego w nowoczesnym przedsiębiorstwie W większości współczesnych średnich i dużych przedsiębiorstwach czy organizacjach tworzone są specjalistyczne struktury do realizacji organizacji usług informatycznych. Do obsługi systemu informacyjnego (SI) przedsiębiorstwo/organizacja zatrudnia specjalnych pracowników. Tworzą oni zespoły zajmujące się takimi zadaniami jak: 1. Planowanie systemu informacyjnego. Planowanie nowego zakresu usług jakie będzie spełniał SI w przedsiębiorstwie/organizacji. 2. Zarządzanie systemem informacyjnym. Kontrolowanie procesu obsługi i pielęgnacji istniejącego systemu informacyjnego, włączając w to również ocenę inwestycji podejmowanych w SI. 6

7 3. Zarządzanie projektem. Działania związane z zarządzaniem projektami poszczególnych systemów informacyjnych. 4. Rozwój systemu informacyjnego. Działania obejmujące konstruowanie i dostarczanie nowych systemów aplikacyjnych, tzn. analiza, projektowanie, tworzenie, testowanie i wdrażanie modułów i całych systemów. 5. Pielęgnacja systemu informacyjnego. Obejmuje poprawę błędów w istniejących systemach informacyjnych oraz dopasowywanie istniejących aplikacji komputerowych do zmian w środowisku działania przedsiębiorstwa/organizacji. 6. Prowadzenie działania/obsługi/administracji systemu informacyjnego. Zadanie dotyczy zazwyczaj dużych systemów i jest realizowane gdy system informacyjny wykorzystywany jest w całej organizacji. Jedną z głównych funkcji jest administrowanie korporacyjną bazą danych. 7

8 8. Zarządzanie zasobami ludzkimi. Pozyskiwanie i organizowanie personelu SI oraz prowadzenie programów szkolenia personelu w celu zapewnienia profesjonalnych usług informatycznych. 9. Kontrola jakości. Zapewnienie jakości zasobów i produktów informatycznych tworzonych i posiadanych przez przedsiębiorstwo/organizację. 10. Ocena systemu informacyjnego. Nadzorowanie powodzenia projektów informatycznych oraz świadczonych usług informatycznych 8

9 Tradycyjny struktura działu usług informacyjnych (w ośrodkach w których obliczenia wykonywano na maszynach typu mainframe): Kierownik ośrodka Opcjonalnie kierownicy szczebla pośredniego: kierownicy operacyjni, kierownicy opracowań, kierownicy obsługi Zespoły projektowe analityków, programistów, operatorów Analitycy systemowi (mający kontakt z użytkownikami końcowymi) Programiści Personel operacyjny 9

10 Zmiany w strukturze organizacyjnej działów informatycznych zostały wymuszone przez: 1. Ruch użytkowników końcowych. Nastąpiło spopularyzowanie komputerów osobistych i pakietów oprogramowania dla tych komputerów, np. edytorów tekstów i arkuszy kalkulacyjnych. Spowodowało to, że użytkownicy końcowi zdobyli duże doświadczenie w informatyce i ich wymagania stają się bardziej wiarygodne. 2. Ruch integracyjny. Opracowanie wykorzystania baz danych, a w szczególności podejście z tym związane, oznaczały, że przedsiębiorstwo musi planować i zarządzać danymi na najwyższym poziomie organizacji. Organizacje widzą korzyści wynikające z integracji systemów informacyjnych między sektorami. 3. Ruch rozproszeniowy. Możliwości przetwarzania i przechowywania danych nie muszą być scentralizowane w danej organizacji. Mogą być rozproszone w przedsiębiorstwie na różne platformy, a różne oprogramowanie może być koordynowane za pomocą sieci równoległych i lokalnych. 10

11 Nowoczesne działy informatyczne pracujące w organizacjach przybrały kształt CENTRUM INFORMATYZACJI, CI (np. UCI Uczelniane Centrum Informatyzacji). Centrum Informatyzacji jest ciałem eksperckim, którego rolą jest obsługa innych działów przedsiębiorstwa/organizacji, w dużej części zapewniających obsługę swoich systemów informacyjnych. 11

12 Struktura Centrów Informatyzacji wymusiła większe zróżnicowanie personelu informatycznego, wśród którego można wyróżnić: - kierowników hybrydowych, - analityków programistów, - administratorów baz danych, - analityków danych, - analityków organizacji systemów, - integratorów oprogramowania, - personel obsługi systemów. Szczególnie wzrosła rola personelu obsługi, którego zadaniem nie jest tworzenie nowych aplikacji komputerowych, ale instalowanie i integrowanie oprogramowania istniejącego oraz pomoc użytkownikom końcowym w jego wykorzystaniu. 12

13 Metody tworzenia aplikacji komputerowych. Tradycyjne podejście do problemu opracowania systemu informatycznego: 1. Aplikacje były tworzone kawałkowi. 2. Aplikacje były przeznaczone dla operacyjnych szczebli przedsiębiorstwa. 3. Analiza była sterowana konwencjonalnymi działami przedsiębiorstwa. 4. Dokumentacja miała postać diagramów przepływów lub opisów. 5. Brak było formalnych wskazówek co do sposobu działania. 6. Koncentrowano się na opisie rozwiązania w języku programowania, a nie organizacji. 13

14 Współczesne podejście do procesu budowy systemów informatycznych: 1. Buduje się aplikacje zintegrowane. 2. Tworzone są aplikacje dla taktycznego i strategicznego poziomu przedsiębiorstwa. 3. Podkreśla znaczenie struktury przedsiębiorstwa. 4. Kładzie nacisk na uzgodnienie danych i procesów. 5. Uwzględnia duży wybór dostępnych technik graficznych. 6. Wymaga zastosowania podejścia krok po kroku do opracowania. 7. Wymaga dokumentowania problemu za pomocą modeli logicznych i pojęciowych. 14

15 Budowa aplikacji komputerowych jest dziedziną inżynierską. Definicja INŻYNIERII OPROGRAMOWANIA : /Bohem, 1976/ Inżynieria oprogramowania jest praktycznym zastosowaniem wiedzy naukowej do projektowania i tworzenia aplikacji komputerowych oraz do dokumentacji wymaganej do ich opracowania, uruchomienia i pielęgnacji. /Beynon-Davies, 1998/ Inżynieria oprogramowania jest semantyczną aplikacją odpowiedniego zestawu technik dla całego procesu opracowania oprogramowania. Ujmuje trzy najważniejsze zasady inżynierii oprogramowania: 1. Zestaw technik jest użyty w celu poprawienia jakości i produkcyjności. 2. Techniki te są stosowane w sposób zdyscyplinowany, a nie dowolny. 3. Techniki te są stosowane do całego procesu opracowywania oprogramowania. 15

16 /Martin, 1984/ Definicja INŻYNIERII OPROGRAMOWANIA : Inżynieria oprogramowania to zespół dyscyplin stosowanych w celu specyfikowania, projektowania i programowania aplikacji komputerowych. Definicja INŻYNIERII INFORMACJI : Inżynieria informacji to zespół wzajemnie powiązanych dyscyplin, które są niezbędne do stworzenia skomputeryzowanego przedsięwzięcia opartego na systemach danych. Inżynieria informacji koncentruje się głównie na danych, które są przechowywane i utrzymywane przez komputery, oraz na informacjach, które są otrzymywane z tych danych. Definicja INŻYNIERII WIEDZY : Inżynieria wiedzy to dyscyplina poświęcona efektywnemu tworzeniu systemów baz wiedzy, tj. systemów, które reprezentują wiedzę. 16

17 3 rodzaje inżynierii: oprogramowania, informacji i wiedzy wynikają z jednego z głównych paradygmatów informatyki który mówi, że: P DANE INFORMACJA WIEDZA P Dane to fakty. Dana jako jednostka danych, jest to jeden lub kilka symboli, użytych do reprezentowania czegoś Informacja to zinterpretowane dane. Informacja to dane umieszczone w znaczącym kontekście. Wiedza jest otrzymana z informacji przez jej zintegrowanie z wiedzą istniejącą. 17

18 Przykład. 43 P Numer osoby. Liczba sprzedanych produktów P Liczba pracowników działu. Ogólna liczba sprzedanych produktów. Łańcuch symboli 43 razem wziętych tworzy daną. Aby przekształcić ją w informację musimy dostarczyć kontekst znaczeniowy czyli zinterpretować dane. Mogą one być numerem identyfikacyjnym pracownika lub liczbą sprzedanego produktu. Informacja tego typu zwiększa naszą wiedzę w określonej dziedzinie, tzn. mówi ile co najmniej osób pracuje w przedsiębiorstwie lub może wskazywać na ogólną liczbę sprzedanych produktów danego typu. 18

19 Źródła inżynierii oprogramowania: w latach 50-tych i na początku lat 60-tych tworzono wyłącznie małe programy komputerowe, nie było zapotrzebowania na złożone oprogramowanie w końcu lat 60-tych rozwój hardware u oraz języków oprogramowania umożliwił tworzenie bardziej złożonych systemów informatycznych, pojawili się pierwsi programiści ludzie zajmujący się zawodowo wytwarzaniem oprogramowania, do lat 80-tych nie nastąpił praktycznie żaden wzrost wydajności oprogramowania; producenci programów sprzedawanych w milionach egzemplarzy nie dawali żadnych gwarancji, że ich produkt będzie działał zgodnie z opisem, 19

20 Źródła inżynierii oprogramowania: (cd) wystąpił kryzys oprogramowania, który spowodowany był następującymi przyczynami: 1. budowane programy cechowały się dużą złożonością (trudno było zapanować na całością), 2. poszczególne przedsięwzięcia programistyczne były niepowtarzalne (nie przenoszono zdobytych doświadczeń na kolejne rozwiązania), 3. proces budowy oprogramowania był nieprzejrzysty, trudno było ocenić stopień zaawansowania prac; wiele przedsięwzięć nigdy nie zostało ukończonych, a pozostałe znacznie przekroczyły czas i budżet, 4. sądzono, że programy tworzy się łatwo, łatwo też dokonać można poprawek w programie; np. szacowano, że jeśli na opracowanie programu liczącego 100 linii kodu potrzeba 10 dni, to program liczący linii kodu 10 programistów zbuduje i przetestuje w 100 dni? Różne propozycje wyjścia z kryzysu zaowocowały powstaniem nowej gałęzi informatyki inżynierii oprogramowania. 20

21 Inżynieria oprogramowania (software engineering) : To wiedza i umiejętność przydatna do budowy programów, a szczególnie dużych systemów oprogramowania. Jest wiedzą techniczną, a nie teoretyczną nauką. Jej metody, techniki i narzędzia powstają i są rozwijane przede wszystkim w oparciu o praktyczne doświadczenie i weryfikowane są podczas ich praktycznego stosowania. Obejmuje tworzenie specyfikacji, metody programowania, aspekty uruchamiania i testowania programów oraz opracowanie dokumentacji. Pozwala na dowodzenie poprawności programów oraz rozwiązuje zagadnienie przenośności oprogramowania. Pomaga w wydajnym konstruowaniu niezawodnego oprogramowania, także w sposób automatyczny. Traktuje oprogramowanie jako produkt oceniany wg następujących kryteriów: zgodności z wymaganiami użytkownika, niezawodności, efektywności, łatwości konserwacji i ergonomiczności. 21

22 INŻYNIERIA OPROGRAMOWANIA A TRADYCYJNE TECHNIKI PROGRAMISTYCZNE Tradycyjny punkt widzenia uznaje pojawienie się inżynierii oprogramowania za naturalny etap rozwoju technik programowania, uważa, że w pewnej fazie tworzenia oprogramowania konieczne stało się bardziej ogólne spojrzenie na tworzone systemy. Rewolucyjny punkt widzenia uważa inżynierię oprogramowania za całkowite przeciwieństwo tradycyjnych technik tworzenia oprogramowania, w którym punktem wyjścia jest konieczność zaspokojenia potrzeb użytkownika wymaga więc myślenia w kategoriach zastosowania, a nie w kategoriach kodu. Skrajni zwolennicy uważają, że kształcenie informatyków powinno się rozpoczynać od nauki inżynierii oprogramowania, a dopiero później nauki konkretnych języków i środowisk programowania. 22

23 Inżynieria oprogramowania walczy z kryzysem oprogramowania postulując, że należy: stosować techniki i narzędzia ułatwiające pracę ze złożonymi systemami, korzystać z metod wspomagających analizę nieznanych problemów oraz ułatwiających wykorzystanie wcześniejszych doświadczeń, usystematyzować proces wytwarzania oprogramowani, tak aby ułatwić jego planowanie i monitorowanie, wytworzyć przekonanie zarówno wśród producentów, jak i nabywców oprogramowania, że budowa dużego systemu o wysokiej jakości jest zadaniem wymagającym w pełni profesjonalnego podejścia. 23

24 Narzędzia CASE: (Computer Assisted / Aided Software / System Engineering) ( Komputerowo wspomagana inżynieria oprogramowania/systemów) zostały opracowane w ostatnich latach, są stosunkowo tanie, bardzo funkcjonalne i nadal rozwijają się żywiołowo, skracają czas opracowania szeregu diagramów i raportów w fazach analizy i projektowania, Upper CASE - koncentrują się na wstępnych etapach przedsięwzięcia, tj. określaniu wymagań, modelowaniu i projektowaniu systemu spełniającego te wymagania, Lower CASE koncentrują się na fazie implementacji opracowanego systemu, tj. ułatwiają programiście pracę nad złożonym oprogramowaniem. 24

25 CYKL ŻYCIA OPROGRAMOWANIA (CŻO, software lifecycle) CŻO - to okres od powstania zapotrzebowania na oprogramowanie do wycofania oprogramowania z eksploatacji. CŻO obejmuje wiele etapów składających się na projektowanie, programowanie, testowanie, wdrażanie i pielęgnowanie oprogramowania oraz czas jego użytkowania Pielęgnowanie obejmuje czynności związane z: - wprowadzaniem poprawek do oprogramowania, - dostosowaniem go do nowych wymagań użytkowników, - uaktualnianiem, tj. wymianą starszych wersji oprogramowania na nowsze, - dbałością o utrzymywane banki danych, oraz -ochroną na wypadek awarii. 25

26 Cykl życia oprogramowania jest skracany przez: modę - pogoń za klientem na rynku informatycznym powoduje, że oprogramowanie jest często wycofywane z rynku za wcześnie, możliwości sprzętowe - nowa wersja oprogramowania na ogół wymaga zmiany lub rozszerzenia konfiguracji sprzętu i dostrojenia systemu. Strojenie to czynność dopasowania systemu (lub poszczególnych programów) do warunków jego użytkowania. Parametry instalacyjne określające warunki i sposób implementacji oprogramowania, wielkość dostępnej pamięci operacyjnej i dyskowej, typ procesora, liczbę i rodzaj zadań właściwie ustawione (zestrojone) pozwalają na ekonomizację pracy systemu i podwyższają komfort pracy jego użytkowników. 26

27 MODELE CYKLU ŻYCIA OPROGRAMOWANIA Systematyzują produkcję oraz eksploatację oprogramowania. Wprowadzają pewne fazy życia oprogramowania, określają czynności wykonywane w poszczególnych fazach oraz ustalają kolejność ich realizacji. Pozwalają uporządkować przebieg prac nad budową oprogramowania, ułatwiają planowanie zadań oraz monitorowanie przebiegu ich realizacji. 27

28 RODZAJE MODELI CYKLU ŻYCIA OPROGRAMOWANIA: 1. kaskadowy 2. realizacja kierowana dokumentami 3. prototypowanie 4. programowanie odkrywcze 5. realizacja przyrostowa 6. model spiralny 7. formalne transformacje 8. Wykorzystanie istniejących zasobów fabryki oprogramowania i składanie z szablonów (Modele 2-7 stanowią wersje lub rozszerzenia modelu kaskadowego) 28

29 Schemat kaskadowego modelu cyklu życia oprogramowania: Określenie wymagań Projektowanie Implementacja Testowanie Konserwacja 29

30 Schemat kaskadowego modelu cyklu życia oprogramowania: (cd) Określenie wymagań Projektowanie Implementacja Testowanie Konserwacja Faza strategiczna Analiza Dokumentacja Instalacja pięć głównych faz + dodatkowe cztery fazy wyróżnione w module 30

31 GŁÓWNE FAZY MODELU KASKADOWEGO: 1. faza określania wymagań, w której określane są cele oraz szczegółowe wymagania wobec tworzonego systemu, 2. faza projektowania, w której powstaje szczegółowy projekt systemu spełniającego ustalone wcześniej wymagania, 3. faza implementacji/kodowania oraz testowania modułów, w której projekt zostaje zaimplementowany w konkretnym środowisku programistycznym oraz wykonywane są testy poszczególnych modułów, 4. faza testowania, w której następuje integracja poszczególnych modułów połączona z testowaniem poszczególnych podsystemów oraz całego oprogramowania, 5. faza konserwacji, w której oprogramowanie jest wykorzystywane przez użytkownika(ów), a producent dokonuje konserwacji oprogramowania wykonuje modyfikacje polegające na usuwaniu błędów, zmianach i rozszerzaniu funkcji systemu. 31

32 Określenie wymagań ITERACJE W MODELU KASKADOWYM Projektowanie Implementacja Testowanie Konserwacja Ścisła interpretacja tego modelu zakłada, że poszczególne fazy (1-5) występują sekwencyjnie jedna po drugiej. W praktyce dopuszcza się iteracje nawroty do wcześniej wykonywanych faz modelu w wypadku wykrycia na dalszych etapach błędów popełnionych w etapach wcześniejszych. Powroty traktowane są jednak jako sytuacje wyjątkowe, których należy w miarę możliwości unikać. 32

33 DODATKOWE FAZY MODELU KASKADOWEGO: 6. faza strategiczna, wykonywana jest przed formalnym podjęciem decyzji o realizacji przedsięwzięcia. W tej fazie podejmowane są pewne strategiczne decyzje dotyczące dalszych etapów pracy. Faza ta wymaga oczywiście przynajmniej ogólnego określenia wymagań. 7. faza analizy, w której budowany jest logiczny model systemu. 8. faza dokumentacji, w której wytwarzana jest dokumentacja użytkownika. Opracowywanie dokumentacji przebiega równolegle z produkcją oprogramowania. Faza ta może rozpocząć się już w trakcie określania wymagań. Sugeruje się nawet, że podręcznik użytkownika jest dla przyszłego systemu dobrym dokumentem opisującym wymagania. Ostatnie zmiany w dokumentacji wykonywane są w fazie instalacji. 9. faza instalacji, w której następuje przekazanie systemu użytkownikowi. 33

34 Zalety Modelu Kaskadowego: łatwość zarządzania projektem, ułatwienie planowania, harmonogramowania oraz monitorowania przedsięwzięcia. Wady Modelu Kaskadowego: narzucenie twórcom oprogramowania ścisłej kolejności wykonywania prac, wysoki koszt błędów popełnionych we wstępnych fazach błędy popełnione w fazie określenia wymagań zostaną najprawdopodobniej wykryte dopiero w fazie testowania lub konserwacji. długa przerwa w kontaktach z klientem. Faza strategiczna oraz określenia wymagań i analizy realizowane są w ścisłej współpracy z klientem. Projektowanie, implementacja i w dużej mierze testowanie wykonywane są wyłącznie przez firmę programistyczną. Pojawia się więc ryzyko zmniejszenia zainteresowania klienta przedsięwzięciem w czasie, gdy nie bierze on bezpośredniego udziału w jego realizacji. 34

35 35