Inżynieria oprogramowania - opracowanie zadań PDF

Preview

Summary

Opracowanie Inżynierii oprogramowania...

Description

1. Omów przedmiot i zakres inżynierii oprogramowania. Przedmiot: Inżynieria oprogramowania jest wiedzą techniczną dotycząca wszystkich faz cyklu życia oprogramowania. Traktuje oprogramowanie jako produkt, który ma spełniać potrzeby techniczne, ekonomiczne lub społeczne. Dobre oprogramowanie powinno być: - zgodne z wymaganiami użytkownika, - niezawodne, - efektywne, - łatwe w konserwacji, - interoperacyjne (jeżeli nie jest autonomiczne) - ergonomiczne. Inżynieria oprogramowania jest wiedzą empiryczną, syntezą doświadczenia tysięcy ośrodków zajmujących się budową oprogramowania. Zakres: Sposoby prowadzenia przedsięwzięć informatycznych. Techniki planowania, szacowania kosztów, harmonogramowania i monitorowania przedsięwzięć informatycznych. Metody analizy i projektowania systemów. Techniki zwiększania niezawodności oprogramowania. Sposoby testowania systemów i szacowania niezawodności. Sposoby przygotowania dokumentacji technicznej i użytkowej. Procedury kontroli jakości. Metody redukcji kosztów konserwacji (usuwania błędów, modyfikacji i rozszerzeń) Techniki pracy zespołowej i czynniki psychologiczne wpływające na efektywność pracy.

2. Omów zagadnienie języka programowania i semiotyki języka programowania. Język programowania jest środkiem umożliwiającym zapis algorytmów w postaci zrozumiałej dla człowieka, a równocześnie przetwarzanej do postaci zrozumiałej dla komputera (maszyny algorytmicznej) Semiotyka zajmuje się badaniem symboli, znaków. W jej skład wchodzą: syntaktyka, zajmująca się określaniem przynależności danego słowa do zestawu słownika określonego języka programowania semantyka, zajmująca się określeniem znaczenia programu, zapisanego w określonym języku programowania Syntaktyka jest częścią ogólnej teorii znaków (semiotyki) i zajmuje się strukturą i formą wyrażeń, a także dopuszczalnymi zmianami ich formy, zwanymi „przekształceniami”. Wyróżnia się dwa rodzaje reguł składniowych: reguły formowania, określające zbiór wyrażeń poprawnie zbudowanych na określonym alfabecie języka reguły przekształcania, określające zbiór możliwych przekształceń na bazie słów z zadanego zestawu słownika W dziedzinie algorytmiki, jak również logiki matematycznej mają zastosowanie wyłącznie reguły inferencyjne, tzn. takie przekształcenia, które są prawdziwe w sensie logiki Najczęściej przyjmuje się, że mamy do czynienia z dwoma podzbiorami dziedziny nazywanej syntaktyką: syntaktyka formalna, która jest rozumiana jako ogólne badania formalne, dotyczące języków logiki i matematyki, jak również języków naturalnych, syntaktyka logiczna, która zajmuje się badaniem języków logiki i matematyki (np. rachunek predykatów, rachunek zdań) Językami programowania, badaniem ich algorytmiczności zajmuje się syntaktyka języków programowania, która jest jednym z rodzajów syntaktyk formalnych 3. Omów zagadnienie i skutki tzw. „kryzysu oprogramowania”.

Podstawowym powodem kryzysu oprogramowania jest złożoność produktów informatyki i procesów ich wytwarzania Skutki: 27% projektów 33% projektów 40% projektów 53% projektów 68% projektów

powstaje w założonym czasie, budżecie i funkcjonalności przekracza czas, budżet i ma mniejszą funkcjonalność jest przerywanych przekracza koszty o 51% przekracza czas o 51%

69% niepowodzeń to czynniki pozainformatyczne. 4. Omów przykładowe źródła złożoności projektu informatycznego. Dziedzina problemowa, obejmująca ogromną liczbę wzajemnie uzależnionych aspektów i problemów. Środki i technologie informatyczne: sprzęt, oprogramowanie, sieć, języki, narzędzia, udogodnienia. Zespół projektantów: podlegający ograniczeniom pamięci, percepcji, wyrażania informacji i komunikacji. Potencjalni użytkownicy: czynniki psychologiczne, ergonomia, ograniczenia pamięci i percepcji, skłonność do błędów i nadużyć, tajność, prywatność. 5. Omów sposoby opanowywania złożoności projektu informatycznego. Zasada dekompozycji: rozdzielenie złożonego problemu na podproblemy, które można rozpatrywać i rozwiązywać niezależnie od siebie i niezależnie od całości. Zasada abstrakcji: eliminacja, ukrycie lub pominięcie mniej istotnych szczegółów rozważanego przedmiotu lub mniej istotnej informacji; wyodrębnianie cech wspólnych i niezmiennych dla pewnego zbioru bytów i wprowadzaniu pojęć lub symboli oznaczających takie cechy. Zasada ponownego użycia: wykorzystanie wcześniej wytworzonych schematów, metod, wzorców, komponentów projektu, komponentów oprogramowania, itd. Zasada sprzyjania naturalnym ludzkim własnościom: dopasowanie modeli pojęciowych i modeli realizacyjnych systemów do wrodzonych ludzkich własności psychologicznych, instynktów oraz mentalnych mechanizmów percepcji i rozumienia świata. 6. Omów zagadnienie modelowania pojęciowego w projekcie informatycznym. Projektant i programista muszą dokładnie wyobrazić sobie problem oraz metodę modelowania pojęciowego. Zasadnicze procesy tworzenia oprogramowania zachodzą w ludzkim umyśle i nie są związane z jakimkolwiek językiem programowania. Pojęcia modelowania pojęciowego (conceptual modeling ) oraz modelu pojęciowego (conceptual model ) odnoszą się procesów myślowych i wyobrażeń towarzyszących pracy nad oprogramowaniem. Modelowanie pojęciowe jest wspomagane przez środki wzmacniające ludzką pamięć i wyobraźnię. Służą one do przedstawienia rzeczywistości opisywanej przez dane, procesów zachodzących w rzeczywistości, struktur danych oraz programów składających się na konstrukcję systemu. Perspektywy w modelowaniu pojęciowym: Percepcja rzeczywistego świata Analityczny model rzeczywistości Model struktur danych i procesów SI 7. Co to jest metodyka prowadzenia projektu informatycznego? Metodyka jest to zestaw pojęć, notacji, modeli, języków, technik i sposobów postępowania służący do analizy dziedziny stanowiącej przedmiot projektowanego systemu oraz do projektowania pojęciowego, logicznego i/lub fizycznego. Metodyka jest powiązana z notacją służącą do dokumentowania wyników faz projektu (pośrednich, końcowych), jako środek wspomagający ludzką pamięć i wyobraźnię i jako środek komunikacji w zespołach oraz pomiędzy projektantami i klientem. Metodyka ustala: - fazy projektu, role uczestników projektu, - modele tworzone w każdej z faz, - scenariusze postępowania w każdej z faz, - reguły przechodzenia od fazy do następnej fazy, - notacje, których należy używać, - dokumentację powstającą w każdej z faz. 8. Omów następujący model cyklu życia oprogramowania: … nazwa modelu 1. Model kaskadowy: Model kaskadowy zwany tez modelem wodospadu lub liniowym, jest klasycznym modelem cyklu życia oprogramowania. Jest to model, który został zaproponowany poprzez analogię do sposobu prowadzenia przedsięwzięć w innych dziedzinach inżynierii, na przykład budownictwie. Model kaskadowy składa się czynności które podczas tworzenia oprogramowania są wykonywane sekwencyjnie: -określenie wymagań , w której określane są cele oraz szczegółowe wymagania wobec tworzonego systemu. -analiza -projektowanie, w której powstaje szczegółowy projekt systemu spełniającego ustalone wcześniej wymagania. -implementacja, w której projekt zostaje zaimplementowany w konkretnym środowisku programistycznym oraz wykonane są testy poszczególnych modułów. -testowanie, w której następuje integracja poszczególnych modułów połączonych z testowaniem poszczególnych podsystemów oraz całego oprogramowania. -konserwacja, w której oprogramowanie jest wykorzystywane przez użytkowników, a producent dokonuje konserwacji oprogramowania – wykonuje modyfikacje polegające na usuwaniu błędów, zmianach i rozszerzaniu funkcji systemu. Wady modelu kaskadowego: - narzucenie twórcom oprogramowania ścisłej kolejności wykonywania prac - wysoki koszt błędów popełnionych we wczesnych fazach - długa przerwa w kontaktach z klientem Model ten mimo swoich wad jest niezbędny dla planowania, harmonogramowania, monitorowania i rozliczeń finansowych. Występuje także zmodyfikowany model kaskadowy z iteracjami. Modyfikacja ta polega na tym, że z każdej fazy można się cofnąć do faz wcześniejszych. 2. Model spiralny, przyrostowy, ewolucyjny Model spiralny składa się z czterech głównych faz wykonywanych cyklicznie: - analiza ryzyka - konstrukcji - atestowania - planowania

W pierwszej fazie rozważane są ogólne opcje budowy nowej wersji systemu. Możliwości te są analizowane przy wzięciu pod uwagę ryzyka związanego z ich realizacją. Problematyka analizy opcji omawiana jest w kolejnym rozdziale dotyczącym fazy strategicznej realizacji przedsięwzięcia. Faza ta może obejmować także budowę prototypu. W kolejnej fazie konstruowana jest kolejna wersja systemu w sposób zgodny z modelem kaskadowym. W fazie atestowania kolejna wersja systemu jest oceniana przez klienta. Jeżeli ocena nie jest w pełni pozytywna rozpoczynany jest kolejny cykl. W fazie planowania ustalane są generalne cele produkcji kolejnej wersji systemu.

Model przyrostowy: Rozpoczyna się od określenia wymagań oraz wykonania wstępnego, ogólnego projektu całości systemu. Następnie wybierany jest pewien podzbiór funkcji systemu. Dalej, zgodnie z przebiegiem modelu kaskadowego, wykonywany jest szczegółowy projekt oraz implementacja części systemu realizującej te funkcje. Po przetestowaniu zrealizowany fragment pełnego systemu może zostać dostarczony klientowi. Zalety tego modelu to: - skrócenie przerw w kontaktach z klientem. - możliwość wczesnego wykorzystania przez klienta dostarczonych fragmentów systemu. - możliwość elastycznego reagowania na powstałe opóźnienia. Jeżeli realizacja fragmentu systemu opóźni się, nie musi to oznaczać opóźnienia całego przedsięwzięcia. Istnieje wtedy możliwość przyspieszenia prac nad dalszymi częściami. Wadą tego modelu jest pewien dodatkowy koszt związany niezależną realizacją fragmentów systemu. Z reguły nie jest możliwe proste wycięcie podzbioru funkcji w pełni niezależnych od pozostałych. W związku z tym może zajść konieczność implementacji tzw. Szkieletów modułów, tj. modułów o interfejsie zgodnym z modułami, które znajdą się pełnym systemie lecz nie realizujących w pełni ich funkcji. Implementacja tych modułów to oczywiście pewien dodatkowy nakład pracy oraz zwiększone ryzyko nie wykrycia błędów w fazie testowania.

Model ewolucyjny: Wytwarzanie ewolucyjne polega na: - opracowaniu wstępnej implementacji, - pokazaniu jej użytkownikowi z prośbą o komentarze - udoskonalaniu jej w wielu wersjach aż do powstania odpowiedniego systemu; Rodzaje wytwarzania ewolucyjnego: 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; Wady modelu ewolucyjnego: -proces nie jest widoczny; -system ma złą strukturę;

-konieczne mogą być specjalne narzędzia i techniki; Stosowanie: - w wypadku systemów małych (mniej niż 100 000 wierszy kodu) lub średnich (do 500 000 wierszy kodu) z krótkim czasem życia podejście ewolucyjne jest dobre; - wypadku dużych systemów o długim czasie życia wady tworzenia ewolucyjnego ujawniają się jednak z całą ostrością;

3. Prototypowanie Sposób na uniknięcie zbyt wysokich kosztów błędów popełnionych w fazie określania wymagań. Zalecany w przypadku, gdy określenie początkowych wymagań jest stosunkowo łatwe. Model ten składa się z następujących faz: - ogólne określenie wymagań - budowa prototypu - weryfikacja prototypu przez klienta - pełne określenie wymagań - realizacja pełnego systemu zgodnie z modelem kaskadowym Głównym celem realizacji prototypu jest lepsze określenie wymagań, czyli: - wykrycie nieporozumień pomiędzy klientem a twórcami systemu - wykrycie brakujących funkcji - wykrycie trudnych usług - wykrycie braków w specyfikacji wymagań

4. Programowanie odkrywcze: Programowanie odkrywcze zalecane jest w sytuacjach gdy określenie wymagań klienta może być tak trudne, że nawet budowa pojedynczego prototypu nie wystarcza dla rozwiania wszelkich wątpliwości. Model ten rozpoczyna się od wstępnego, bardzo ogólnego określenia wymagań. Następnie bardzo szybko rozpoczyna jest realizacja systemu. Faza realizacji obejmuje z reguły wykonanie przynajmniej bardzo ogólnego projektu. System jest następnie weryfikowany przez klienta. Jeżeli zostanie on uznany za nieodpowiedni, budowana jest kolejna wersja systemu. Nie jest to przy tym budowa od podstaw lecz najczęściej modyfikacja poprzedniej wersji. Cykl kończy się jeżeli jedna z kolejnych wersji zadowala klienta, lub dojdzie on do wniosku, że nie jest możliwe osiągnięcie zadowalającego efektu. Zaletą tego modelu jest możliwość stosowania nawet w wypadkach dużych trudności z określeniem wymagań klienta. Wady tego modelu: - praktycznie niemożliwe jest zachowanie sensownej struktury systemu, nawet jeżeli na wstępie wykonano ogólny projekt. Struktura zaproponowana na wstępie na pewno zaginie w kolejnych iteracjach wprowadzania zmian do systemu. Po kilku iteracjach okazuje się, że wprowadzanie kolejnych zmian i usuwanie kolejnych błędów, powoduje dodawanie nowych błędów. W efekcie praktycznie nie możliwe jest wykonanie w ten sposób większych systemów o zadowalającej niezawodności. - ponieważ model ten nie obejmuje pełnego określenia wymagań, testowanie systemu może odbywać się prawie wyłącznie przy bezpośrednim udziale klienta. W wypadku innych modeli testowanie polega przede wszystkim na weryfikowaniu zgodności systemu z wcześniej sprecyzowanymi wymaganiami. 5. Model „V”; Polega na wytwarzaniu równolegle oprogramowania i prowadzeniu testów akceptacji, poszczególne elementy systemu są badane od razu po wytworzeniu, praca polega na podziale

systemu na podsystemy, a te na poszczególne zadania, co robi jeden z zespołów, a drugi zespół odpowiada wyłącznie za ocenę i testowanie systemu. testy odbywają sie od zadań, potem przechodzą do testowania podsystemów, a następnie testowany jest pełny system. 6. Montaż z gotowych elementów Model montażu z gotowych elementów kładzie szczególny nacisk na możliwości redukcji nakładów przez maksymalne wykorzystanie podobieństw tworzonego oprogramowania do wcześniej tworzonych systemów. Gotowe elementy mogą być wykorzystywane na różnych etapach realizacji przedsięwzięcia. Najczęściej są one wykorzystywane na etapie implementacji. Przykładem może być stosowanie: - bibliotek - języków czwartej generacji, których złożone instrukcje mogą być traktowane jako odwołania do wybudowanych bibliotek - pełnych aplikacji np. wykorzystanie przeglądarki plików pomocy w systemie MS Windows Istnieją dwie metody pozyskiwania gotowych elementów: - zakup od zewnętrznych dostawców - opracowanie wyników aktualnie realizowanych przedsięwzięć tak, aby mogłyby być wykorzystane w kolejnych przedsięwzięciach. Zalety stosowania gotowych elementów to: - wysoka niezawodność - zmniejszenia ryzyka - efektywne wykorzystanie specjalistów - narzucanie standardów Wadami tego modelu są: - dodatkowy koszt przygotowania elementów do ponownego wykorzystania. - ryzyko uzależnienia się od dostawcy elementów - niedostatki narzędzi wspomagających ten rodzaj pracy

9. Omów zadania kierownictwa przedsięwzięcia informatycznego w cyklu wytwórczym oprogramowania. Podstawowe zadania kierownictwa przedsięwzięcia informatycznego: Opracowanie propozycji dotyczących sposobu prowadzenia przedsięwzięcia Kosztorysowanie przedsięwzięcia Planowanie i harmonogramowanie przedsięwzięcia Monitorowanie i kontrolowanie realizacji przedsięwzięcia Dobór i ocena personelu Opracowanie i prezentowanie sprawozdań dla kierownictwa wyższego szczebla

10. Omów podstawowe czynniki psychologiczne w procesie wytwórczym i rodzaje osobowości twórców oprogramowania

Czynniki te wynikają z faktu, że oprogramowanie jest używane i tworzone przez ludzi. Użytkowanie - implikuje zasady tworzenia interfejsu użytkownika i dokumentacji użytkowej.

Tworzenie - zagadnienia psychologiczne odgrywające rolę w tworzeniu oprogramowania. Elementy ludzkiej inteligencji: Umiejętność całościowego (syntetycznego) spojrzenia na problem. Posługiwanie się wiedzą płynącą z doświadczenia, a więc stosowania nieścisłych zasad wnioskowania na bazie wcześniejszych doświadczeń. Istnieją ogromne różnice w predyspozycjach osób dotyczące ich efektywności w produkcji oprogramowania. Testy osobowości: metody określenia, czy dana osoba posiada cechy przydatne na danym stanowisku. Stosowanie testów osobowości wiąże się z następującymi trudnościami: Osobowość ludzka ma charakter dynamiczny (zmienia się). Wieloletnia praktyka zawodowa nie pozostaje bez wpływu na osobowość. Różne zadania mogą wymagać różnych cech osobowości. Inne powinien posiadać analityk (kontakt z klientem), inne zaś programista lub osoba testująca oprogramowanie. Ponadto, metody inżynierii oprogramowania ulegają zmianie, co pociąga za sobą inny stosunek pożądanych cech osobowości do aktualnych zadań. Osoby poddane testom będą starały się raczej odgadnąć pożądaną przez testujących odpowiedź niż odpowiadać zgodnie ze stanem faktycznym. Test nie będzie więc odzwierciedlał cech osobowości osoby, lecz raczej to, jak ta osoba wyobraża sobie cele i kryteria testowania oraz cechy pożądane przez pracodawcę.

11. Omów cechy dobrego inżyniera oprogramowania i sposoby zorientowania na pracę w cyklu wytwórczym oprogramowania. Umiejętność pracy w stresie. W pracy często zdarzają się okresy wymagające szybkiego wykonania złożonych zadań. Dla większości osób niewielki stres działa mobilizująco. Po przekroczeniu jednak pewnego progu następuje spadek możliwości danej osoby. Próg ten jest różny dla różnych osób.

Zdolności adaptacyjne. Informatyka jest jedną z najszybciej zmieniających się dziedzin. Ocenia się, że 7-9 miesięcy przynosi w informatyce zmiany, które w innych dziedzinach zajmują 5-7 lat. Oznacza to konieczność stałego kształcenia dla wszystkich inżynierów oprogramowania - stałe poznawanie nowych narzędzi, sprzętu, oprogramowania, technologii, metod, sposobów pracy. Niestety, nie wszyscy to tempo wytrzymują. Czynniki psychologiczne mają zasadniczy wpływ na efektywność pracy zespołu. Wyróżnia się następujące typy psychologiczne:

1. Zorientowani na zadania (task-oriented). Osoby samowystarczalne, zdolne, zamknięte, agresywne, lubiące współzawodnictwo, niezależne.

2. Zorientowani na siebie (self-oriented). Osoby niezgodne, dogmatyczne, agresywne, zamknięte, lubiące współzawodnictwo, zazdrosne.

3. Zorientowani na interakcję (interaction-oriented). Osoby nieagresywne, o niewielkiej potrzebie autonomii i indywidualnych osiągnięć, pomocne, przyjazne. Osoby typu 1 są efektywne, o ile pracują w pojedynkę. Zespół złożony z takich osób może być jednak nieefektywny. Lepsze wyniki dają zespoły złożone z typów 3. Typ 1 i 2 może być także efektywny w zespole, o ile jest odpowiednio motywowany przez kierownictwo. Typy 3 są konieczne w fazie wstępnej wymagającej intensywnej interakcji z klientem. 12. Omów podstawowe obszary zarządzania przedsięwzięciem informatycznym według Prince2 Wymiar produktu: Przez produkty projektu rozumie się wszystkie jego elementy, które mogą powstać w wyniku jego realizacji. Może to być gotowe oprogramowanie, zainstalowane systemy, dokumentacja oprogramowania, różnego rodzaju procedury, wykształcone kadry ludzkie itp. Opracowanie planów działań w wymiarze produktów odbywa się na podstawie definicji zakresu projektu. Wymiar czasu: Na podstawie precyzyjnie zdefiniowanego zakresu projektu można zdefiniować drugi wymiar projektu, czyli czas, który jest najczęściej zapisywany w postaci harmonogramu. Często spotykaną formą prezentacji harmonogramu są na przykład tabele lub arkusze kalkulacyjne, jak również wykresy Gantta, które przedstawiają poszczególne czynności projektowe w sieci uwzględniającej wzajemne ich zależności, następstwa i zasoby niezbędne do ich wykonania w odpowiednio zdefiniowanej skali czasu. Wymiar budżetu: Budżet projektu stanowi zestawienie kosztów realizacji projektu. Koszt ten powinien być podzielony na poszczególne jego kategorie. Mogą to być: koszty osobowe, koszty sprzętu, administracji pr...