1 Oprogramowanie
Są to programy komputerowe, cała związana z nimi dokumentacja i dane konfiguracyjne
Rodzaje produktów oprogramowania
-Powszechne
-Dostosowane (na zamówienie)
Co to jest inżynieria oprogramowania?
Jest to dziedzina inżynierii, która obejmuje wszystkie aspekty tworzenia oprogramowania od fazy początkowej do jego pielęgnacji
Inżynierowie oprogramowania pracują w sposób systematyczny i uporządkowany ponieważ jest to najskuteczniejszy sposób tworzenia oprogramowania wysokiej jakości
Jaka jest różnica pomiędzy inżynierią oprogramowania a informatyka ?
Zasadniczo informatyka obejmuje teorie i podstawowe zasady działania komputerów. Inżynieria oprogramowania obejmuje praktyczne problemy związane z tworzeniem oprogramowania
Byłoby dobrze gdyby inżynier programowania znał teorie informatyczne, z drugiej strony nie zawsze przystają one do rzeczywistości
Jaka jest różnica pomiędzy inżynierią oprogramowania a inżynierią systemów?
Inżynieria systemów komputerowych obejmuje wszystkie aspekty tworzenia i ewolucji systemów komputerowych, w których oprogramowanie odgrywa zasadniczą rolę.
Inżynierowie systemów biorą udział w specyfikacji systemu i definiowania jego ogólnej architektury
2 Etyczne elementy Inż Opr.
Etyczne dylematy
-Zasadnicza niezgodność z z poglądami przełożonego
-Nieetyczne postępowanie pracodawcy np. przy fałszowaniu dzienników kontroli przy testowaniu krytycznego systemu
-Uczestnictwo w tworzeniu systemów wojskowych i nuklearnych
Odpowiedzialność etyczna i zawodowa
Inżynierowie oprogramowania muszą zaakceptować fakt, że ponoszą znacznie większą odpowiedzialność niż tylko wynikająca z ich technicznych umiejętności
Muszą postępować etycznie i moralnie, jeśli chcą być uważani za profesjonalistów
Zachowywać się etycznie, to więcej niż tylko przestrzegać obowiązujące prawo
Zasady zawodowej odpowiedzialności
Zachowywanie tajemnicy
Inżynierowie powinni zawsze dochowywać tajemnic powierzonych przez pracodawców i klientów, niezależnie od tego czy podpisano formalną umowę o ochronie tajemnicy.
Kompetencje
Inżynierowie nie powinni zawyżać poziomu swoich kompetencji. Nie powinni świadomie przyjmować prac, które przekraczają ich możliwości.
Prawo własności intelektualnej
Inżynierowie powinni znać miejscowe prawo regulujące korzystanie z własności intelektualnej. Powinni szczególnie dbać o poszanowanie intelektualnej własności swoich pracodawców i klientów.
Niewłaściwe użycie komputera
Inżynierowie oprogramowania nie powinni używać swoich umiejętności do niewłaściwego używania cudzych komputerów. Niewłaściwe użycie może być dość banalne (np. granie na maszynie pracodawcy) lub skrajnie poważne (rozsiewanie wirusów).
Kodeksy etyczne i zawodowe
Stowarzyszenia zawodowe w USA współpracują ze sobą przy publikowaniu kodeksów profesjonalnego zachowania i kodeksy etyczne.
Omówiony poniżej kodeks zawiera osiem zasad dotyczących zachowania i decyzji profesjonalnych inżynierów oprogramowania oraz nauczycieli, zarządzających, kierowników, strategów, a także studentów.
3 Podstawowe wasności systemów
-Konkretny zbiór właściwości zależy od zastosowania, niemniej można podąć ogólny zbiór właściwości
-Zdolność do pielęgnacji
-Zdolność do ewolucji zgodnie z potrzebami klientów
-Niezawodność
-Nie powinno powodować fizycznych lub ekonomicznych katastrof w przypadku awarii
-Efektywność
-Nie powinno marnotrawić zasobów systemu takich jak pamięć czy czas procesora
-Użyteczność
-Powinno być użyteczne, bez zbędnego wysiłku ze strony użytkownika (np. interfejsy)
Właściwości niefunkcjonalne,
takie jak niezawodność, efektywność, bezpieczeństwo i zabezpieczenia. Są związane z zachowaniem systemu w jego środowisku pracy . Często są zasadnicze dla systemów komputerowych, ponieważ niepowodzenie w osiągnięciu pewnego zdefiniowanego minimalnego ich poziomu może sprawić, że system będzie bezużyteczny.
Właściwości funkcjonalne,
które są widoczne, gdy wszystkie części systemu współpracują, aby osiągnąć pewien cel . Rower ma na przykład cechę funkcjonalną bycia środkiem transportu, gdy scali się go z jego części.
Niezawodność- jest złożonym pojęciem, które zawsze należy badać na poziomie systemu, a nie jego poszczególnych komponentów.
Komponenty w systemie są od siebie zależne, a zatem awarie w jednym z nich mogą przenosić się na cały system i mieć wpływ na operacje innych systemów.
Często projektanci systemu nie są w stanie przewidzieć, jak konsekwencje awarii przenoszą się na cały system
Nie mogą zatem podać wiarygodnych oszacowań niezawodności systemu.
Niezawodność sprzętu
Niezawodność oprogramowania
Niezawodność operatora
Efektywność i użyteczność
Są trudne do oceny, można je jednak zmierzyć po uruchomieniu systemu.
Mamy do czynienia nie z atrybutem ogólnego zachowania systemu, ale z zachowania systemu, które nie powinno mieć miejsca.
System zabezpieczony to taki, który nie dopuszcza nieuprawnionego dostępu do swoich danych.
4 Tworzenie ewolucyjne
Tworzenie badawcze
Celem procesu jest praca z klientem, polegająca na badaniu wymagań i dostarczeniu ostatecznego systemu. Tworzenie rozpoczyna się od tych części systemu, które są dobrze rozpoznane. System ewoluuje przez dodawanie nowych cech, które proponuje klient.
Prototypowanie z porzuceniem
Celem procesu tworzenia ewolucyjnego jest zrozumienie wymagań klienta i wypracowanie lepszej definicji wymagań stawianych systemowi. Budowanie prototypu ma głównie na celu eksperymentowanie z tymi wymaganiami użytkownika, które są niejasne.
5 Podstawowe metody projektowania
Model przepływu danych
Model strukturalny
Model obiektowy
6 Podział systemów CASE
- Narzędzia wspomagające poszczególne zadania w ramach procesu, np. s sprawdzania spójności projektu, kompilacji programu, porównywania wyników testów itd.
- Warsztaty wspomagają całe fazy procesów lub czynności, np. specyfikowanie, projektowanie itd.
- Środowiska wspomagają całość lub znaczną część procesu tworzenia oprogramowania.
7 Wymagania funkcjonalne i niefunkcjonalne
Wymagania funkcjonalne
stawiane systemowi opisują funkcjonalność lub usługi, które system powinien oferować.
Zależą od rodzaju tworzonego oprogramowania, spodziewanych użytkowników oprogramowania i rodzaju wytwarzanego systemu.
Gdy mają postać wymagań użytkownika, ich opis jest zwykle bardziej ogólny, natomiast wymagania funkcjonalne systemowe szczegółowo definiują funkcje systemu, jego wejścia, wyjścia, wyjątki itd.
Niefunkcjonalne
Mogą definiować ograniczenia systemu, takie jak możliwości urządzeń wejścia-wyjścia i reprezentacje danych używane przez interfejsy systemu.
Przykładami wymagań stawianych procesowi są specyfikacja standardów jakości, których należy użyć w procesie, stwierdzenie, że projekt należy opracować za pomocą konkretnego zbioru narzędzi CASE, i opis procesu, którego należy przestrzegać.
Wymagania niefunkcjonalne wynikają z potrzeb użytkownika, ograniczeń budżetowych, strategii firmy, konieczności współpracy z innymi systemami sprzętu lub oprogramowania, czynników zewnętrznych.
8 Model procesu????????????????
Jest to uproszczona prezentacja procesu tworzenia oprogramowania. Modele ze swej natury są uproszczeniami .
Przykłady:
Model przepływu prac
Model przepływu danych (lub model czynności)
Model rola-akcja
Przykłady ogólnych modeli (paradygmatów) tworzenia oprogramowania:
Model kaskadowy
Tworzenie ewolucyjne
Formalne przekształcenia
Składanie systemu z komponentów ponownego użycia
9 Programowanie BD
Większość gospodarczych programów użytkowych obejmuje przetwarzanie danych z bazy danych i generowanie wyników, które polega na organizowaniu i formatowaniu danych.
Programowanie bazy danych jest wykonywane w specjalizowanym języku, który ma wbudowaną wiedzę o bazie danych i zawiera operacje służące do pracy z bazą danych.
Pojęcie język czwartej generacji (4GL) obejmuje zarówno język programowania bazy danych, jak i wspomagające go środowisko. Interfejs użytkownika składa się zwykle ze zbioru standardowych formularzy i arkuszy kalkulacyjnych.
10 Zalety systemów obiektywnych
Systemy powinny być łatwe w pielęgnacji, ponieważ obiekty są niezależne.
Można je poznawać i modyfikować jako samodzielne byty.
Zmiana implementacji obiektu lub dodanie usług nie powinno mieć wpływu na obiekty systemowe.
Obiekty są skojarzone z bytami, zwykle więc istnieje jasne odwzorowanie bytów świata rzeczywistego (np. komponentów sprzętowych) na sterujące nimi obiekty w systemie. Zwiększa to zrozumiałość i zarazem zdatność do pielęgnacji systemu.
11 Omówić proces tworzenia oprogramowania
Specyfikowanie oprogramowania. Funkcjonalność oprogramowania i ograniczenia jego działania muszą być zdefiniowane.
Projektowanie i implementowanie oprogramowania. Oprogramowanie, które spełnia specyfikację, musi być stworzone.
Zatwierdzenie oprogramowania. Wytworzone oprogramowanie musi spełniać oczekiwania klienta.
Ewolucja oprogramowania. Oprogramowanie musi ewoluować, aby spełniać zmieniające się potrzeby użytkowników.
12 Co rozumiemy pod pojęciem odpowiedzialność etyczna i zawodowa
13 Co rozumiemy pod pojęciem niezawodność systemu
Dla części technicznej systemu informacyjnego, cecha ta określa odporność na awarie techniczne, oraz zdolność do zapewnienia nieprzerwanego funkcjonowania systemu.
Niezawodność w części podmiotowej i organizacyjnej reguluje kwestie bezpieczeństwa danych, konstrukcji planów awaryjnych i organizacyjne askepty usuwania skutków awarii.
14 Ewolucja systemu- przykład
Czas życia wielkich złożonych systemów jest bardzo długi. W trakcie swego działania systemy te musza ewoluować.
Ewolucja oprogramowania jest ze swej natury kosztowna:
proponowane zmiany muszą być bardzo starannie rozważone z punktu widzenia przedsiębiorstwa i technologii,
-podsystemy nigdy nie są całkowicie niezależne,
-przyczyny pierwotnych decyzji projektowych zwykle nie są zapisywane,
- w miarę starzenia się systemu jego struktura staje się coraz bardziej skomplikowana przez zmiany.
Przykładem może tu posłużyć system operacyjny firmy Microsoft – Windows XP, który ewoluował poprzez dostarczane nieodpłatnie przez producenta, pakiety zwane Service Pack (1-3), zawierające nowe funkcje i/lub zbiorczą aktualizację bezpieczeństwa dla oprogramowania, udostępnione najczęściej w postaci pojedynczego, łatwego do zainstalowania pliku.
15 Omów tworzenie formalne systemów
Tworzenie formalne systemów jest podejściem, które ma wiele wspólnego z modelem kaskadowym. Proces tworzenia jest tu jednak oparty na matematycznych przekształceniach specyfikacji systemu w program wykonywalny.
W procesie przekształcania formalna matematyczna reprezentacja systemu jest metodycznie przekształcana w bardziej szczegółowe, ale wciąż matematycznie poprawne reprezentacje systemu.
Podejście z przekształceniem złożone z ciągu małych kroków jest łatwiejsze w użyciu. Wybór, które przekształcenie zastosować, wymaga jednak dużych umiejętności.
Najlepiej znanym przykładem takiego formalnego procesu tworzenia jest Cleanroom, pierwotnie opracowany przez IBM (Proces Cleanroom jest oparty na przyrostowym tworzeniu oprogramowania, gdy formalnie wykonuje się każdy krok i dowodzi jego poprawności.)
Oprócz specjalistycznych dziedzin procesy oparte na przekształceniach formalnych są używane rzadko.
Wymagają specjalistycznej wiedzy i w praktyce okazuje się, że w wypadku większości systemów nie powodują zmniejszenia kosztów lub polepszenia jakości w porównaniu z innymi podejściami.
Interakcje systemów nie poddają się łatwo specyfikowaniu formalnemu.
16 Omów projektowanie i wyszukiwanie błędów
Programiści wykonują pewne testy kodu, który napisali. Często prowadzi to do wykrycia błędów, które należy usunąć z programu.
Testowanie usterek i usuwanie błędów to dwa różne procesy.
Lokalizacja błędu może wymaga nowych przypadków testowych.
Ciągle często projektowanie jest działaniem ad hoc, gdzie wymagania zapisuje się w języku naturalnym.
Lepsze podejście polega na użyciu metod strukturalnych, które są zbiorami notacji i porad dla projektantów oprogramowania. Ich użycie polega zwykle na opracowaniu graficznych modeli systemu i prowadzi do dużej ilości dokumentacji projektowej.
Metody strukturalne mogą obejmować:
modele przepływu danych,
modele encja-związek,
modele strukturalne,
modele obiektowe.
17 Etnografia
To metoda obserwacji, która może służyć do rozpoznawania wymagań społecznych i organizacyjnych.
Analityk pogrąża się w środowisku pracy, w którym system będzie używany.
Obserwuje codzienną pracę i odnotowuje podstawowe zadania wykonywane przez pracowników.
Zaleta etnografii jest to, że pomaga odkrywać niejawne wymagania systemowe odzwierciedlające rzeczywiste, a nie formalne procesy, w których biorą udział ludzie.
Rzeczywista praktyka pracy biurowej jest znacznie bogatsza, bardziej złożona i dynamiczna niż przewidywana przez proste modele w systemach automatyzacji biura.
Różnica między zakładem, a rzeczywistym trybem pracy jest najważniejsza przyczyną nikłego wpływu tych systemów biurowych na wydajność pracy.
Innymi studiami etnograficznymi nad rozpoznawaniem wymagań systemowych były prace nad systemem kontroli lotów i rozmaite działania projektowe.
18 Co to są metody formalne...
KIT098