IO ściąga nowa(1).docx

(307 KB) Pobierz

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

 

3. 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ść.

4. 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.

5-9. 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

                           

              Model spiralny składa się z czterech głównych faz wykonywanych cyklicznie:

                            - planowania

                            - analiza ryzyka

                            - konstrukcji

                            - atestowania

                                         

W fazie planowania ustalane są generalne cele produkcji kolejnej wersji systemu.

W fazie analizy 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ą.

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.

 

              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.

             

 

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.

 

             

10. Omów podstawowe metody rozpoznawania wymagań i cechy jakościowego dobrego opisu wymagań.

 

.Dobry opis wymagań powinien być:

-Kompletny

-Niesprzeczny

-Weryfikowalny

-Realizowalny

Ponadto:

–Opisywać zewnętrzne zachowania systemu z pominięciem sposobu jego realizacji

–Obejmować ograniczenia, przy jakich musi pracować system

–Łatwy w modyfikacji

–Zapewniać możliwości zmiany wymagań w kolejnych etapach

–Zawierać zachowania systemu w niepożądanych lub skrajnych sytuacjach (brzegowych)

Metody rozpoznawania wymagań:

Wywiady i przeglądy. Wywiady powinny być przygotowane (w postaci listy pytań) 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.

 

11. Omów główne klasy wymagań na system informatyczny. Podaj przykłady takich wymagań.

Główne klasy wymagań to Funkcjonalne, Niefunkcjonalne i Dziedzinowe

  Funkcjonalne (jakie usługi oferuje, jak ma reagować, jakie dane przyjmować) :
-system wymaga logowania użytkownika
-możliwość sprawdzania postępów pracy w każdym momencie

    Niefunkcjonalne( ograniczenia czasowe, standardy) :
-system powinien odszukiwać dane każdego użytkownika poniżej 10 sekund
-system nie powinien zajmować więcej niż 10GB

    Dziedzinowe (odzwierciedlają charakterystykę dziedziny systemu, mogą być 
    funkcjonalne lub niefunkcjonalne):
-Wszystkie bazy danych powinny być dostępne przez jednolity interfejs użytkownika, 
  którego podstawą jest standard Z39.50

 

12. Omów i podaj przykłady wymagań funkcjonalnych dla systemu informatycznego.


Wymagania funkcjonalne określają jakie usługi ma oferować system, jak ma reagować na otrzymywane dane wejściowe oraz w określonych sytuacjach. Określają one użytkowników korzystających z systemu oraz możliwości każdego z nich. Określają również wykorzystanie systemów zewnętrznych. Mogą one również określać czego system nie powinien robić. Wymagania funkcjonalne mogą być realizowane przez systemy zewnętrzne.
Przykłady:
-wprowadzenie nie pełnych danych system powinien komunikować błędem
-system powinien przydzielać odpowiednie zlecenia pracownikom

 

13. Omów i podaj przykłady wymagań niefunkcjonalnych dla systemu informatycznego.


Wymagania niefunkcjonalne są to ograniczenia systemu, które obejmują ograniczenia czasowe, ograniczenia dotyczące procesu tworzenia, standardy itd.
Wynikają one z potrzeb użytkownika, budżetu, potrzeby współpracy z innym systemem, strategii firmy i czynników zewnętrznych. Wymagania niefunkcjonalne można podzielić na trzy podklasy: Produktowe (określają zachowanie produktu) :
-system powinien być łatwy w użyciu dla doświadczonych kontrolerów

    Organizacyjne (wynikają ze strategii w firmie wytwórczej i firmie klienta)
-proces tworzenia systemu i końcowe dokumenty powinny być zgodne z procesem i produktami zdefiniowanymi w standardzie XYZCo-SP-STAN-95.
    Zewnętrzne
-system nie powinien ujawniać operatorom żadnych danych osobowych klientów  oprócz nazwisk i numerów identyfikacyjnych.

 

14. Omów zakres fazy analizy w cyklu wytwórczym systemów informatycznych.


Celem fazy analizy jest ustalenie wszystkich tych czynników, które mogą wpłynąć na decyzje projektowe, na przebieg procesu projektowego i na realizację wymagań. Wynikiem jest logiczny model systemu, opisujący sposób realizacji przez system postawionych wymagań, lecz abstrahujących od szczegółów implementacyjnych.
Zakres fazy analizy:
--Wykracza poza zakres odpowiedzialności systemu -> kontekst użycia i współpracy;
--Ujęcie w modelu pewnych elementów nie będących częścią systemu -> model jest
    bardziej zrozumiały;
--Abstrakcja modelowania -> podczas modelowania może nie być jasne,
    które elementy modelu będą realizowane przez oprogramowanie a które w sposób
    sprzętowy lub ręcznie;

--Dostępne środki mogą nie pozwolić na realizację systemu w całości -> analiza może
    wykryć fragmenty, które mogą być szczególnie ważne;

 

15 Omów zakres i istotę etapu projektowania w cyklu wytwórczym SI

 

Celem projektowania jest opracowanie szczegółowego opisu implementacji systemu.

W odróżnieniu od analizy, w projektowaniu dużą rolę odgrywa środowisko implementacji.

Dwa etapy fazy projektowania:

                                 projekt strategiczny, projekt systemu (strategic, system design):

»                                 podział na podsystemy,

»                                 współbieżność,

»                                 przechowywanie danych,

»                                 sterowanie.

                                 projekt szczegółowy (detailed design):

»                                 uściślanie definicji klas,

»         dziedziczenie,

»         optymalizacja modelu,

»         modularyzacja,

»                                 ukrywanie informacji;

+ to samo co w obiektowym na koncu

 

16 Omów zakres i istotę etapu implementacji w cyklu wytwórczym systemów informatycznych

 

17.Omów przykłady nieobiektowego podejścia do analizy, projektu i implementacji systemów informatycznych.

 

Metodyki strukturalne - łączą statyczny opis danych oraz statyczny opis procesów.

Do tej klasy należą:

          Metodyka Yourdona (DeMarco i Ward/Mellor);

          Structured System Analysis and Design Methodology (SSADM);

          Structured Analysis and Design Technique (SADT).

Uważa się, że wadą metodyk strukturalnych są trudności w zintegrowaniu modeli oraz iż pomimo dojrzałości, mogą nie być adekwatne do współczesnych tendencji wytwarzania systemów informatycznych;

 

Przykład metodyki - CDM-Oracle-1996

         stosowana do procesów biznesowych i funkcji, które nie mogą być obsłużone za pomocą dostępnych aplikacji „z półki”;

         CDM jest zbiorem zdefiniowanych procesów tworzenia oprogramowania, które zostały określone przy założeniu, że w procesie wytwórczym stosowane są metody i narzędzia CASE;

         zakłada, że potrzeby biznesowe zostają wyraźnie zdefiniowane na samym początku cyklu projektowego oraz że ich zweryfikowanie jest możliwe podczas całego procesu wytwórczego;


CDM wyróżnia następujące procesy:

         definicja potrzeb biznesowych (studium możliwości),

         analiza istniejących systemów,

         opracowanie architektury technicznej,

...

Zgłoś jeśli naruszono regulamin