io wyklad2

In\ynieria oprogramowania
wykład II
prowadzący: dr in\. Krzysztof Bartecki
Faza strategiczna
Wymagania Projektowanie Implementacja
Testowanie Konserwacja
Instalacja
Analiza
Strategiczna
Dokumentacja
Głównym celem fazy strategicznej jest ustalenie mo\liwości realizacji
przedsięwzięcia programistycznego (tzw. studium wykonywalności),
oszacowanie jego kosztów oraz prowadzenie negocjacji
z przedstawicielami klienta.
K. Bartecki, In\ynieria oprogramowania, II/2
Czynności wykonywane w fazie strategicznej
rozmowy (wywiady) z klientem lub jego przedstawicielami,
określenie celów przedsięwzięcia z punktu widzenia klienta,
określenie zakresu i kontekstu przedsięwzięcia,
ogólne określenie wymagań wykonanie wstępnej analizy i projektu
ogólne określenie wymagań wykonanie wstępnej analizy i projektu
systemu,
propozycja kilku mo\liwych sposobów realizacji systemu,
oszacowanie kosztów budowy systemu,
analiza rozwiązań,
prezentacja wyników analizy klientowi oraz korekta wyników,
budowa wstępnego harmonogramu przedsięwzięcia.
K. Bartecki, In\ynieria oprogramowania, II/3
Przykład
Firma rachunkowa zajmuje się przygotowywaniem formularzy zeznań
podatkowych dotyczących podatku dochodowego dla indywidualnych
podatników.
Ze względu na rosnącą liczbą klientów, którzy głównie korzystają z usług
Ze względu na rosnącą liczbą klientów, którzy głównie korzystają z usług
firmy w okresie marca i kwietnia, kiedy ilość klientów jest największa,
firma zdecydowała się na zakup systemu informatycznego.
Cele systemu:
przyspieszenie obsługi klientów,
zmniejszenie ryzyka popełnienia błędu przy rozliczaniu podatku.
K. Bartecki, In\ynieria oprogramowania, II/4
Zakres przedsięwzięcia
to określenie zakresu procesów zachodzących w firmie,
które zostaną objęte przedsięwzięciem programistycznym.
Z reguły obejmuje on jedynie pewien zakres działalności klienta.
Przykład (dla systemu informatycznego firmy rachunkowej)
Zakres przedsięwzięcia to działalność firmy rachunkowej, dotycząca
przygotowywania formularzy zeznań podatkowych odnośnie podatku
dochodowego dla indywidualnych klientów.
Na tym etapie mo\e nie być jasne, czy system powinien drukować
formularz zeznania, czy tylko przygotowywać dane, które będą na
formularzu umieszczane w tradycyjny sposób.
K. Bartecki, In\ynieria oprogramowania, II/5
Kontekst przedsięwzięcia
to systemy, organizacje, u\ytkownicy zewnętrzni,
z którymi tworzony system informatyczny będzie współpracował.
Przykład (dla systemu informatycznego firmy rachunkowej)
Przykład (dla systemu informatycznego firmy rachunkowej)
Jedynym systemem zewnętrznym, z którym system będzie współpracował,
będzie u\ytkownik (pracownik firmy rachunkowej).
K. Bartecki, In\ynieria oprogramowania, II/6
Ocena rozwiązań
W fazie strategicznej często rozwa\a się kilka mo\liwych rozwiązań
realizacji systemu informatycznego, z których następnie wybiera się
jedno najlepsze.
Przykładowe kryteria oceny jakości rozwiązań:
koszt,
czas realizacji,
niezawodność,
mo\liwość ponownego u\ycia,
przenośność na inne platformy,
wydajność (szybkość).
K. Bartecki, In\ynieria oprogramowania, II/7
Tabelaryczny zapis rozwa\anych rozwiązań
C
A B
Rozwiązanie
Koszt (tys. zł)
120 80 175
36
Czas (miesiące) 33 30
Niezawodność (błędy/tydzień) 5 9 13
Niezawodność (błędy/tydzień) 5 9 13
Ponowne u\ycie (%) 40 40 30
90 75 30
Przenośność (%)
Wydajność (transakcje/s) 0.35 0.75 0.75
Oszacowanie wartości podanych w tabeli mo\e być trudnym zadaniem.
K. Bartecki, In\ynieria oprogramowania, II/8
Wybór rozwiązania
usunięcie rozwiązań zdominowanych, tj. gorszych według
wszystkich (lub prawie wszystkich) kryteriów w podanym
przypadku rozwiązaniem zdominowanym jest C,
normalizacja wartości dla poszczególnych kryteriów, czyli
sprowadzenie ich do przedziału [0,1],
przypisanie wag do kryteriów (mo\e być trudne),
wybór rozwiązania o największej wartości.
K. Bartecki, In\ynieria oprogramowania, II/9
Ocena rozwiązań za pomocą sumy wa\onej
waga
B
A
Rozwiązanie
Koszt
0,58 1 3
2
Czas 0,5 1
Niezawodność 1 0,5 3
Niezawodność 1 0,5 3
Ponowne u\ycie 1 1 1
1 0,75 1,5
Przenośność
Wydajność 0 0,62 0,75
7,74 9,17
Aączna ocena
K. Bartecki, In\ynieria oprogramowania, II/10
Szacowanie kosztów oprogramowania
Na koszt tworzonego oprogramowania składają się następujące czynniki:
koszt sprzętu będącego częścią tworzonego systemu,
koszt wyjazdów i szkoleń,
koszt zakupu narzędzi,
nakład pracy.
Trzy pierwsze czynniki są stosunkowo łatwe do oszacowania, natomiast
ocena nakładów pracy niezbędnych dla zrealizowania systemu jest
bardzo trudna.
Z tego względu szacowanie kosztów oprogramowania jest praktycznie
to\same z szacowaniem nakładów pracy.
K. Bartecki, In\ynieria oprogramowania, II/11
Metody szacowania kosztów oprogramowania
modele algorytmiczne np. model COCOMO,
ocena przez eksperta doświadczone osoby często z du\ą
precyzją potrafią oszacować koszt realizacji nowego systemu,
ocena przez analogię wycena na podstawie wcześniej
realizowanych przedsięwzięć,
prawo Parkinsona przedsięwzięcia, w tym programistyczne,
praktycznie zawsze wykonywane są przy zało\onych nakładach ,
wycena dla wygranej koszt oprogramowania szacowany jest na
podstawie oceny mo\liwości klienta oraz przewidywanych działań
konkurentów zgodnie z Prawem Parkinsona projekt i tak się
zmieści w zało\onych ramach,
szacowanie wstępujące realizację przedsięwzięcia dzieli się na
mniejsze zadania, których koszt jest łatwiej ocenić.
K. Bartecki, In\ynieria oprogramowania, II/12
Model COCOMO
Model COCOMO (ang. Cost Construction Model) jest algorytmicznym
modelem szacowania kosztów oprogramowania, opartym o szacowaną
liczbę instrukcji kodu, z których będzie składał się system.
Powstał on w oparciu o informacje dotyczące około 60 projektów
informatycznych o ró\nej zło\oności (od 2 KDSI do 100 KDSI),
napisanych w ró\nych językach programowania.
1 KDSI = 1000 linijek kodu zródłowego.
K. Bartecki, In\ynieria oprogramowania, II/13
Wyra\enia pozwalające wyznaczyć nakład pracy zgodnie z modelem
COCOMO przyjmują następującą postać:
E = a�" KDSIb
D = c�" Ed
P = E / D
gdzie:
KDSI liczba tysięcy instrukcji kodu zródłowego,
E nakład pracy (w osobomiesiącach),
D czas potrzebny do wykonania projektu (w miesiącach),
P liczba osób, przy której projekt będzie najefektywniej zrealizowany,
a, b, c, d współczynniki zale\ne od rodzaju (zło\oności) projektu.
K. Bartecki, In\ynieria oprogramowania, II/14
Typy projektów w modelu COCOMO
łatwy (ang. "organic") mały zespół posługuje się znanymi
narzędziami pracy. Zna on sprzęt i oprogramowanie, przy u\yciu
których będzie tworzony projekt. Presja czasu jest mała. Aatwe
projekty są wielkości do 50 KDSI.
projekty są wielkości do 50 KDSI.
pośredni (ang. "semi-detached"), to projekt, w którym jeden
z czynników z projektu prostego nie jest znany, np. zespół nie zna
sprzętu, który przyjdzie mu programować, itp. Takie projekty są
zwykle wielkości do 300 KDSI.
trudny (ang. "embedded"), to bardzo zło\ony projekt, wiele
czynników jest nieznanych lub nale\y uwzględnić szczególne
procedury, np. w bran\y bankowej.
K. Bartecki, In\ynieria oprogramowania, II/15
Wartości stałych modelu COCOMO dla ró\nych typów projektów
projekt c
a b d
łatwy
2.4 2.5 0.38
1.05
3.0 1.12
pośredni 2.5 0.35
2.5 0.32
trudny 3.6
1.2
Na przykład dla projektu łatwego otrzymujemy:
E = 2.4�" KDSI1.05
D = 2.5�" E0.38
K. Bartecki, In\ynieria oprogramowania, II/16
a)
b)
Oszacowania nakładu pracy (a) oraz czasu trwania projektu (b)
w modelu COCOMO
K. Bartecki, In\ynieria oprogramowania, II/17
Metoda punktów funkcyjnych
Metody szacowania rozmiaru systemu w oparciu o rozmiar linii kodu
zródłowego są niedokładne, zawodne, sprzyjające patologiom, np.
sztucznemu pomna\aniu ilości linii, ignorowaniu komentarzy, itp.
Obecnie stosuje się wiele miar o lepszych charakterystykach.
Na przykład metoda punktów funkcyjnych oszacowuje koszt
projektu na podstawie funkcji u\ytkowych, które system ma
projektu na podstawie funkcji u\ytkowych, które system ma
realizować.
Metoda oparta jest na zliczaniu ilości wejść i wyjść systemu, miejsc
przechowywania danych i innych kryteriów. Te dane są następnie
mno\one przez zadane z góry wagi i sumowane. Rezultatem jest
liczba tzw. punktów funkcyjnych .
Istnieją przeliczniki punktów funkcyjnych na liczbę linii kodu, co
mo\e być podstawą dla metody COCOMO.
K. Bartecki, In\ynieria oprogramowania, II/18
Przykładowy wstępny harmonogram przedsięwzięcia informatycznego
(tzw. diagram Gantta)
K. Bartecki, In\ynieria oprogramowania, II/19
Rezultaty fazy strategicznej
Przeznaczony dla klienta raport obejmujący:
definicję celów przedsięwzięcia,
opis zakresu przedsięwzięcia,
opis kontekstu (systemów zewnętrznych),
ogólny opis wymagań,
wstępny model systemu,
opis proponowanego rozwiązania,
oszacowanie kosztów,
wstępny harmonogram prac.
Raport oceny rozwiązań, zawierający informacje o rozwa\anych
rozwiązaniach oraz przyczynach wyboru jednego z nich.
Opis wymaganych zasobów pracownicy, oprogramowanie, sprzęt.
Harmonogram fazy analizy.
K. Bartecki, In\ynieria oprogramowania, II/20
Faza określenia wymagań
Wymagania Projektowanie Implementacja
Testowanie Konserwacja
Instalacja
Analiza
Strategiczna
Dokumentacja
Jej celem jest dokładne określenie wymagań klienta wobec tworzonego
systemu.
K. Bartecki, In\ynieria oprogramowania, II/21
Faza określenia wymagań szczegóły
W tej fazie dokonywana jest zamiana celów klienta na konkretne
wymagania zapewniające osiągnięcie tych celów.
Klient mo\e nie rozumieć oprogramowania, ale wie czego chce.
Zadaniem analizy wymagań jest określenie czego chce klient
i opisanie tego w taki sposób, aby wytwarzanie mogło toczyć
się dalej bez jego udziału.
Podstawowym sposobem pracy jest wykonywanie wywiadów
z ró\nymi osobami ze strony klienta są to z reguły przyszli
u\ytkownicy systemu.
K. Bartecki, In\ynieria oprogramowania, II/22
Trudności w określeniu wymagań:
klient nie wie, w jaki sposób osiągnąć zało\one cele,
cele klienta mo\na osiągnąć na wiele sposobów,
du\e systemy wykorzystywane są przez wielu u\ytkowników, których
cele mogą być sprzeczne,
zleceniodawcy i u\ytkownicy to inne osoby nie zawsze są oni
w stanie właściwie przewidzieć potrzeby rzeczywistych u\ytkowników.
K. Bartecki, In\ynieria oprogramowania, II/23
Poziomy opisu wymagań:
definicja wymagań (ang. requirement definition) ogólny opis
sporządzony w języku naturalnym ( System powinien& ),
specyfikacja wymagań (ang. requirement specification) zapis
częściowo ustrukturalizowany, wykorzystujący zarówno język
częściowo ustrukturalizowany, wykorzystujący zarówno język
naturalny, jak i proste sformalizowane notacje (formularze),
specyfikacja oprogramowania (ang. software specification) w pełni
formalny opis wymagań.
Formalna specyfikacja oznacza dokładne zdekomponowanie wymagań
(najlepiej w pewnym formularzu) na krótkie punkty, których interpretacja
nie powinna nastręczać trudności lub prowadzić do niejednoznaczności.
K. Bartecki, In\ynieria oprogramowania, II/24
Zawartość typowego dokumentu opisu wymagań:
Wprowadzenie cel, zakres i kontekst systemu,
Opis ewolucji systemu opis przewidywanych zmian,
Opis wymagań funkcjonalnych,
Opis wymagań niefunkcjonalnych,
Wstępny model systemu (omówiony na kolejnych wykładach),
Słownik opis terminów niezrozumiałych dla jednej ze stron.
K. Bartecki, In\ynieria oprogramowania, II/25
Cechy dobrego opisu wymagań:
jest kompletny oraz niesprzeczny,
opisuje zewnętrzne zachowanie systemu z punktu widzenia
u\ytkownika, a nie sposób jego realizacji,
uwzględnia ograniczenia, przy jakich musi pracować system,
jest łatwy w modyfikacji,
jest łatwy w modyfikacji,
opisuje zachowanie systemu równie\ w sytuacjach niepo\ądanych.
Najbardziej typowy błąd w tej fazie: koncentrowanie się na sytuacjach
typowych i pomijanie wyjątków oraz przypadków granicznych.
Zarówno u\ytkownicy, jak i analitycy mają tendencję do nie zauwa\ania
sytuacji nietypowych lub skrajnych.
K. Bartecki, In\ynieria oprogramowania, II/26
Rodzaje wymagań wobec tworzonego oprogramowania
funkcjonalne
niefunkcjonalne
opisują funkcje (czynności),
opisują ograniczenia,
które system ma wykonywać
przy których system ma
wykonywać swoje funkcje
K. Bartecki, In\ynieria oprogramowania, II/27
Wymagania funkcjonalne
Określenie wymagań funkcjonalnych obejmuje następujące czynności:
określenie wszystkich rodzajów u\ytkowników, którzy będą korzystać
z systemu,
określenie wszystkich rodzajów u\ytkowników, którzy są niezbędni
do działania systemu (obsługa, wprowadzanie danych, administracja),
do działania systemu (obsługa, wprowadzanie danych, administracja),
dla ka\dego rodzaju u\ytkownika określenie funkcji systemu oraz
sposobów korzystania z planowanego systemu,
określenie systemów zewnętrznych (obcych baz danych, sieci,
Internetu), które będą wykorzystywane podczas działania systemu,
ustalenie struktur organizacyjnych, przepisów prawnych, statutów,
zarządzeń, instrukcji, itd., które pośrednio lub bezpośrednio określają
funkcje wykonywane przez planowany system.
K. Bartecki, In\ynieria oprogramowania, II/28
Fragment przykładowego opisu wymagań w języku naturalnym
System powinien umo\liwiać wprowadzanie przechowywanie
i drukowanie wielu wzorców tekstów umów zlecenia i umów
o dzieło (łącznie co najmniej kilkunastu). Druk polegałby na
wybraniu jednego ze wzorców i jednego z zleceniobiorców.
System powinien uzupełnić wzorzec o dane zleceniobiorcy
i umo\liwiać dodanie tekstu przez u\ytkownika.
i umo\liwiać dodanie tekstu przez u\ytkownika.
System powinien umo\liwiać drukowanie rachunków za
wykonanie umowy zlecenie i umowy o dzieło z wyliczonymi
poprawnie wszystkimi jego elementami. System powinien
uwzględniać wszystkie zgodne z przepisami warianty
naliczaniu ubezpieczeń społecznych i podatków.
&
K. Bartecki, In\ynieria oprogramowania, II/29
Zalety opisu wymagań w języku naturalnym:
stosunkowo łatwy do sporządzenia,
w pełni zrozumiały przez klienta.
Wady opisu wymagań w języku naturalnym:
niejednoznaczność utrudniająca precyzyjny zapis wymagań mo\e
prowadzić to do ró\nej interpretacji tego samego tekstu przez ró\ne
osoby,
ta sama treść wyra\ona mo\e być na ró\ne sposoby utrudnia to
wykrycie wymagań powiązanych z sobą oraz wymagań sprzecznych.
K. Bartecki, In\ynieria oprogramowania, II/30
Przykład formularza opisu wymagania dla programu podatkowego
Edycja dochodów podatnika
Nazwa funkcji
Funkcja pozwala edytować łączne dochody podatnika
Opis
uzyskane w danym roku
Informacje o dochodach podatnika uzyskanych z ró\nych
zródeł, o zaliczkach na poczet podatku, o dokumentach
Dane wejściowe
opisujących dochody
Dokumenty oraz informacje dostarczane przez podatnika.
Dokumenty oraz informacje dostarczane przez podatnika.
yródło danych
yródło danych
Dane wpisywane są przez pracownika firmy
wejściowych
Wynik
Kwota dochodu = kwota przychodu kwota kosztów. Aączne
kwoty przychodów, kosztów uzyskania, dochodów oraz zaliczek
Warunek wstępny
są sumami tych kwot dla dochodów z poszczególnych zródeł.
Kwota dochodu = kwota przychodu kwota kosztów. Aączne
kwoty przychodów, kosztów uzyskania, dochodów oraz zaliczek
Warunek końcowy
są sumami tych kwot dla dochodów z poszczególnych zródeł.
K. Bartecki, In\ynieria oprogramowania, II/31
Porządkowanie wymagań hierarchia wymagań funkcjonalnych
funkcja 1
funkcja 1
funkcja 1.1
funkcja 1.2 funkcja 1.3
funkcja 1.1
funkcja 1.2
funkcja 1.2.1
funkcja 1.2.1
funkcja 1.2.2
funkcja 1.2.2
funkcja 1.2.3
funkcja 1.2.3
funkcja 1.3
K. Bartecki, In\ynieria oprogramowania, II/32
Przykład hierarchii funkcji dla systemu firmy rachunkowej
Ewidencja podatników
:
Ewidencja Urzędów Skarbowych
:
Ewidencja zeznań podatkowych
Dodawanie zeznania
Dodawanie zeznania
Usuwanie zeznania
Zabezpieczenie zeznania
Edycja zeznania
Edycja informacji o przychodach
Edycja informacji o ulgach
:
Wyświetlanie rozliczenia
K. Bartecki, In\ynieria oprogramowania, II/33
Przykład hierarchii funkcji dla systemu harmonogramowania zleceń
Zarządzanie zleceniami (ogólna funkcja systemu)
Przygotowanie zamówień na półprodukty Przygotowanie kart zadań
Ewidencja zleceń Edycja technologicznego opisu wydziału Harmonogramowanie zleceń
Edycja opisu maszyn Ustalanie harmonogramu Wczytywanie
informacji o zleceniach
Edycja opisu operacji Edycja harmonogramu Wyświetlanie
informacji o zleceniach
Edycja opisu wyrobów Graficzna prezentacja Wydruk
harmonogramu informacji o zleceniach
Sprawdzanie Wydruk harmonogramu
kompletności opisu
Wydruk informacji
technologicznych
K. Bartecki, In\ynieria oprogramowania, II/34
Przypadki u\ycia
są metodą opisu funkcji systemu z punktu widzenia jego u\ytkowników.
Przypadek u\ycia (ang. use case) to opis sekwencji działań, mającej
określony cel biznesowy, w trakcie którego realizacji zachodzi interakcja
określony cel biznesowy, w trakcie którego realizacji zachodzi interakcja
pomiędzy programem i jego u\ytkownikami.
Przypadki u\ycia, w przeciwieństwie do wcześniej wymienionych metod,
skupiają się na interakcji pomiędzy u\ytkownikiem a systemem.
Metoda przypadków u\ycia nie jest sprzeczna z hierarchiczną
dekompozycją funkcji.
K. Bartecki, In\ynieria oprogramowania, II/35
Zasady stosowania przypadków u\ycia:
istotność nie koncentrujemy opisów przypadków u\ycia na
działaniach mniej istotnych, nie mających wa\nego celu biznesowego,
kompletność opisane przypadki u\ycia powinny pokrywać wszystkie
działania u\ytkownika,
skala nie mno\ymy nadmiernie ilości przypadków u\ycia opisując
oddzielnie jednostkowe czynności które powinny być krokami w
przypadkach u\ycia,
niezale\ność je\eli jeden przypadek u\ycia zawiera przypadki
podrzędne lub jest z nich zbudowany, to nale\y je wydzielić dla
uproszczenia opisu.
K. Bartecki, In\ynieria oprogramowania, II/36
Opis przykładowego przypadku u\ycia
UC1: Wystawianie faktury
Aktor: Sprzedawca
Główny scenariusz:
1. Sprzedawca chce wystawić fakturę
1. Sprzedawca chce wystawić fakturę
2. Sprzedawca wpisuje pozycję faktury
3. System podlicza fakturę, nadaje jej nowy numer i zapisuje
w rejestrze
4. Sprzedawca drukuje fakturę
Rozszerzenia:
3.A Sprzedawca nie dodał \adnej pozycji
3.A.1 System prosi o ponowne wprowadzenie pozycji
K. Bartecki, In\ynieria oprogramowania, II/37
Graficzna notacja przypadku u\ycia
wystawianie faktury
sprzedawca
aktor przypadek u\ycia
asocjacja
(rodzaj u\ytkownika)
K. Bartecki, In\ynieria oprogramowania, II/38
Przykładowy diagram przypadków u\ycia restauracja
K. Bartecki, In\ynieria oprogramowania, II/39
Wymagania niefunkcjonalne
opisują ograniczenia, przy których system musi realizować
swoje funkcje.
Wymagania funkcjonalne mo\na podzielić na:
dotyczące produktu, np. musi istnieć mo\liwość przeglądania
danych wyłącznie za pomocą klawiatury ,
danych wyłącznie za pomocą klawiatury ,
dotyczące procesu, np. proces realizacji systemu
harmonogramowania zleceń musi być zgodny ze standardem
opisanym w określonym dokumencie .
zewnętrzne, np. projektowany system informatyczny musi
współpracować z bazą danych systemu komputerowego opisanego
w określonym dokumencie .
K. Bartecki, In\ynieria oprogramowania, II/40
Typowe wymagania niefunkcjonalne związane
są z m.in. bezpieczeństwem, wydajnością,
awaryjnością systemu.
UWAGA: Wymagania stwierdzające na przykład \e system powinien być:
łatwy w obsłudze,
łatwy w obsłudze,
niezawodny,
wydajny,
nie są poprawnie określone, gdy\ nie mogą być obiektywnie
zweryfikowane.
Dla wyra\ania tego typu wymagań konieczne jest posługiwanie się
wielkościami mierzalnymi.
K. Bartecki, In\ynieria oprogramowania, II/41
Przykłady miar słu\ących do określenia wymagań niefunkcjonalnych
miary
cecha
liczba transakcji obsłu\onych w ciągu sekundy,
wydajność
czas odpowiedzi, szybkość odświe\ania ekranu
wymagana pamięć RAM,
rozmiar
wymagana pamięć dyskowa
czas niezbędny dla przeszkolenia u\ytkowników,
czas niezbędny dla przeszkolenia u\ytkowników,
łatwość
łatwość
liczba stron dokumentacji
u\ytkowania
częstotliwość występowania błędnych wykonań,
niezawodność
dostępność (procent czasu, w którym system jest dostępny)
czas restartu po awarii systemu,
odporność
prawdopodobieństwo zniszczenia danych podczas awarii
liczba platform docelowych,
przenośność
Koszt przeniesienia na nową platformę
K. Bartecki, In\ynieria oprogramowania, II/42
Rezultaty fazy określenia wymagań
Dokument opisujący wymagania, zło\ony z następujących elementów:
wprowadzenia opisującego cele, zakres i kontekst systemu,
opisu ewolucji systemu, tzn. przewidywanych zmian wymagań,
opisu wymagań funkcjonalnych,
opisu wymagań niefunkcjonalnych,
modelu systemu,
słownika danych.
Plan testów.
K. Bartecki, In\ynieria oprogramowania, II/43

Wyszukiwarka