Wstęp PRINCE2 (Projects IN Controlled Environments) Xtreme

Wstęp
Inżynieria oprogramowania – zastosowanie systematycznego,
zdyscyplinowanego, ilościowego podejścia do rozwoju, eksploatacji i
utrzymania oprogramowania.
Siedem nawyków skutecznego działania (Dr Stephen Covey):
• Bądź proaktywny – twoje decyzje lub zaniechania mają bezpośredni
wpływ na życie – czyli to ty współdecydujesz o losach projektu;
• Zaczynaj mając koniec na względzie – jeśli zaczynasz działać, ustal
jasny cel, który chcesz osiągnąć;
• Aby rzeczy pierwsze były pierwsze – istotne jest dobre ustalenie
priorytetów - najpierw spełnienie założonej funkcjonalności;
• Myśl o obopólnej korzyści – myśl w kategoriach win-win – zastanów
się nad oczekiwaniami drugiej strony, aby wypracowane rozwiązanie
było satysfakcjonujące dla obu stron;
• Najpierw staraj się zrozumieć – zanim sam zaczniesz prosić o
zrozumienie. Poznanie potrzeb klienta pozwoli nawiązać z nim lepszy
poziom relacji;
• Dbaj o synergię - razem zdziałamy więcej niż osobno efekt szczerej i
konstruktywnej współpracy opartej na obopólnej korzyści;
• Ostrz piłę – cały czas rozwijaj się, udoskonalaj swoje umiejętności w
oparciu o doświadczenia.
PRINCE2 (Projects IN Controlled Environments)
Kryzys oprogramowania - LOOP
Late (późno), Over budget (przekroczony budżet), Overtime
(nadgodziny), Poor quality (kiepska jakość)
Za dużo papierów, Za dużo zebrań, Problem ze zmiennymi
wymaganiami, Formalne podejście do zmian
Xtreme Programming (XP)
Lekka (lightweight, agile) metodyka rozwoju oprogramowania:
• Najważniejsza komunikacja ustna
• Jedyne artefakty: kod + testy
• Żadnych nadgodzin
• Założenie „on-site customer” (klient zawsze przy tobie)
• Brak spisanej dokumentacji
• Zbyt krótka perspektywa planu (bez problemu oporów przed
zmianami)
Program tworzy się w iteracjach – planuje tylko następn. Efektem każdej
powinna być wersja programu spełniającą założenia dla danej iteracji.
Następnie planuje się co zrobić dalej.
Nie można z góry przewidzieć, jaka architektura będzie najlepsza dla
danego problemu. Dlatego należy ją tworzyć w miarę rozszerzania
programu.
Programiści piszą w parach: jedna osoba jest głównym koderem, druga
obserwuje pierwszą, zgłasza poprawki, zadaje pytania wyjaśniające.
Programiści programujący w parze zamieniają się rolami co kilkadziesiąt
minut. Ta technika umożliwia wyłapanie wielu błędów oraz wzajemną
naukę.
Brak w
nowej wersji
slajdów
XPrince (XP in contolled environments) :
Cykl życia wg PRINCE2:
Przyg. Zał.
Inicj. Proj.
Proj.
Etap3
Etap4
Manifest zwinności:
zwinno
Ludzie i komunikacja > procesy i narzędzia
Działaj
Działające
oprogramowanie > obsz.dokument.
Współpracuj
spółpracujący klient > negocjacja kontraktu
Reagowanie na zmiany > trzymanie się planu
+ Rozwiązane
Rozwi
problemy ważniejsze niż zaawansowane
opr
programowanie
Etap przedprojektowy
Jakie są
s motywacje biznesowe związane z projektem?
Czy warto inwestować
inwestowa w planowanie projektu? (metafora sita
projektów)
Etap powinien być
by możliwie krótki i tani
Wst
Wstępny
przypadek biznesowy:
• Kontekst (kto jest klientem?)
• Problemy i ich konsekwencje (budżet)
• Zarys rozwiązania – wiele podejść
• Ograniczenia biznesowe (np. deadline)
Wydanie 2
Przyrost 2.1
Etap1
Przyrost 2.2
Etap2
Zamk. Proj.
Cykl życia wg XPrince:
Przyg. Zał.
Inicj. Proj.
Architektura
Proj.
Wyd.2 *
Wyd.3 *
Zamk. Proj.
*wydania składają się z przyrostów + wdrożeń = XP
Wyd.1 *
Przygotowanie założeń (etap przedprojektowy)– Zlecający (sponsor),
problem i koncepcja rozwiązania, interfejsy (otoczenie systemu),
preferowane podejście
Inicjowanie projektu (etap rozpoczęcia) – Business Process
Reengineering, wymagania pozafunkcjonalne, role (aktorzy), zarys
wymagań funkcjonalnych, zarys architektury.
o Jakość przypadku testowego = prawdopodobieństwo znalezienia
dotychczas niewykrytego błędu
bł
o Według Rogera Pressmana testowanie pochłania 30-40%
30
ogólnej
pracochłonno projektu informatycznego.
pracochłonności
W przypadku
rzypadku systemów krytycznych (sterowania samolotem, praca
elektrowni jądrowej)
j
70-80%
• Przeglądy
o Przegląd:
Przeglą Ocena artefaktu (kodu) realizowana przez grupę osób
o Inspekcja: ---||--- przeprowadzona przez współpracowników i
kierowana przez moderatora
o Rola przeglądów:
przeg
zapewnienie jakości, przekazywanie informacji
• Refaktoryzacja - zmiana wewnętrznej struktury programu, mająca na
celu zwiększenie
zwię
czytelności kodu oraz zmniejszenie kosztów
dalszych modyfikacji bez zauważalnej
zauwa
zmiany jego działanie
Przykre zapachy:
zapachy długa metoda, duża klasa, powielony kod, długa lista
parametrów, zazdrość
zazdro o kod, zbitki danych, obsesja typów
podstawowych, instrukcja switch, spekulatywna ogólność,
ogólno
klasy danych.
Przykłady refaktoryzacji:
refaktoryzacji zmiana nazwy metody, klasy,
przemieszczenie metody,
metody przemieszczenie pola, wydzielenie klasy,
interfejsu, dodanie(usunięcie)
dodanie(usuni
parametru
Inspekcje zgodne z IEEE 1028
Kryteria jakości:
Terminowo niezawodność, bezpieczeństwo danych, funkcjonalność
Terminowość,
Zarządzanie ryzykiem w e. przedprojektowym
Zarz
• Identyfikacja czynników ryzyka – burza mózgów, gotowa lista
• Ocena – prawdopodobieństwo i wpływ
Planowanie:
Planowanie
Biznesowe czynniki ryzyka (EPIC)
E = business Environment impacting the project,
wpływ środowiska biznesowego na projekt
P = Problem to be solved
I = Investor willing to pay for solving the problem,
inwestor mający płacić za rozwiązanie problemu
C = business Constraints imposed on the project,
ograniczenia biznesowe związane z projektem
Czynniki ryzyka związane
zwi
z programowaniem (ETICS)
E = development Environment,
T = Technology to be applied,
I = Iterativeness of the proposed approach,
iteracyjność proponowanego podejścia
C = Crew (developers) that would solve the problem,
zespół mający rozwiązać problem
S = Subcontractor(s) supporting the developers
zleceniobiorcy wspomagający zespół wykonawczy
Ocenianie 10 – Bardzo prawdopodobne; 7 – Raczej możliwe; 5 –
Ocenianie:
Trudno powiedzieć;
powiedzie 3 – Raczej niemożliwe; 0 – Bardzo
nieprawdopodobne
Wymagania funkcjonalne
Przypadek użycia
u
= opisuje jak aktor (użytkownik lub urządzenie)
współpracuje z systemem aby osiągnąć
osi
dany cel.
Op procesu biznesowego (NIE MA SYSTEMU!) = opisuje jak aktor
Opis
(osoba lub urządzenie)
urz
współpracuje z innymi aktorami (ludźmi lub
urzą
urządzeniami),
aby osiągnąć dany cel.
Wzorce przypadków użycia
u
• Przypadki użycia służą do opisu zachowania, a nie UI
• Opis jasno pokazuje jaki aktor wykonuje akcję i co osiąga
• Przypadek składa się z 3 do 9 kroków
• Zapisuj w sposób neutralny technologicznie = bez szczegółów
technicznych, np. nazw baz danych, języka programowania…
PRINCE2 (zespół zarządzania):
Cykl życia wg XP
Wydanie 1
Przyrost 1.1
Przyrost 1.2
Architektura – najtrudniejsze przypadki użycia, podejścia, opis
Archi
najwa
najważniejszych
elementów ( protokoły, sch. baz danych), przykłady
rozwi
rozwiązań
- fragmenty kodu.
Struktura SRS (IEEE 830) – Software Requirements Specification:
1. Wprowadzenie
1.1 Cel dokumentu
1.2 Zakres produktu
1.3 Definicje, akronimy, skróty
1.4 Odwołania do literatury
1.5 Omówienie dokumentu
2. Ogólny opis produktu
2.1 Kontekst funkcjonowania
2.2 Charakterystyka użytkowników
2.3 Główne funkcje produktu
2.4 Ograniczenia
2.5 Założenia i zależności
3. Wymagania funkcjonalne
4. Wymagania pozafunkcjonalne
4.1 Dokładność
4.2 Bezpieczeństwo
4.3 Tolerowanie uszkodzeń
4.4 Odtwarzalność
4.5 Charakterystyka czasowa
Dodatki
Indek
Indeks
Sekretarz i moderator – może to być 1 osoba
1. Omówienie (cały zespół)
2. Przygotowanie (indywidualnie)
3. Inspekcja (cały zespół) Pełna akceptacja / Akceptacja warunkowa
/Powtórna
Powtórna inspekcja
4. Naprawa
5. Sprawdzenie
Inspekcje Fagana
Specyfikacje zewnętrzne
zewn
(funkcje)
Specyfikacje wewnętrzne
wewn
(moduł) – I0
Specyfikacje logiki przetwarzania – I1 inspekcja proj.
Kodowanie (logika) – I2 – inspekcja kodu
Testowanie jednostkowe
Projekt
KOD
Test funkcji (zewn.), składnika, systemu
TEST
I1 – inspekcje projektu
I2 – inspekcje kodu
Omówienie
500 loc/h
Przygotowanie
100 loc/h
Niepotrzebne
125 loc/h
Inspekcja
130 loc/h
150 loc/h
Naprawa
50 loc/h
60 loc/h
Sprawdzenie
-
-
Spotkanie inspekcyjne <= 2h, 1-2 spotkania dziennie
Lista kontrolna dla inspekcji projektu (Fagana)
• Czy wszystkie stałe są
s zdefiniowane?
• Czy w trakcie manipulacji kolejką
kolejk może wystąpić przerwanie? Jeśli
tak, czy kolejka jest ujęta
uj w region krytyczny?
• Czy rejestry są
s odtwarzane przy wyściu?
• Czy wszystkie liczniki są
s odpowiednio inicjowane?
• Czy sąą literały numeryczne, które powinny by
być zastąpione stałymi
symbolicznymi?
• Czy wszystkie bloki na schemacie są potrzebne?
Słabe strony inspekcji:
inspekcji brak przygotowania, duże koszty.
Z zebranych przez Fagana danych wynika, że wprowadzenie inspekcji
projektu (I1) pozwoliło zaoszczędzić średnio 94 godziny na każdym
tysiącu
cu linii kodu. Inspekcje kodu (I2) dały oszczędności w wysokości
51 godzin na tysiąc
tysi linii kodu. Natomiast inspekcje przeprowadzane po
testach jednostkowych spowodowały dodatkowe obciążenie
obci
w wysokości
20 godzin na tysiąc
tysi linii kodu - nie warto prowadzić inspekcji po
testach jednostkowych.
Szacowanie liczby defektów
Wstrzykiwanie defektów:
Dodano n defektów, test wykrył m+k defektów, z czego k wcześniej
wstrzykniętych. Szacowana liczba defektów to m*n/k
Kontrola jakości
2-krotne
krotne łowienie:
• danych jest dwóch recenzentów (gdy więcej
wi
jako A rozpatrujemy,
tego który znalazł najwięcej
najwi
błędów, jako B sumarycznie resztę
recenzentów)
o A – liczba defektów znaleziona przez pierwszego
o B – ---||----przez drugiego
o C – liczebność
liczebno części wspólnej defektów wykrytych przez obu
recenzentów
o Liczba
iczba defektów (A*B)/C
Anomalia – sytuacja różna od oczekiwanej, wynikającej ze specyfikacji,
standardów, lub czyjegoś
czyjego doświadczenia.
Wymagania pozafunkcjonalne, ISO 9126
Jakość = zgodność z wymaganiami =
Jako
• Zarządzanie konfiguracją
• Testowanie
o Wykonanie programu celem znalezienia błędu
o Udany test wykrywa jeszcze niewykryty błąd
Wymagania pozafunkcjonalne, nie są
s bezpośrednio związane z
funkcjami
unkcjami aplikacji. Opisują
Opisuj własności (cechy, charakterystyki)
oprogramowania takie jak wydajność
wydajno (czas odpowiedzi systemu), czy
niezawodność (czas bezawaryjnej pracy). Wymagania pozafunkcjonalne
mogą również
równie definiować ograniczenia systemu, takie jak przepustowość
urządzeńń sieciowych lub peryferyjnych lub specyfikacja formatu danych
przetwarzan
zanych przez aplikację.
Produkty komercyjne,
komercyjne Przypadki użycia, Scenariusze zmian
Czynniki ryzyka)
ryzyka
• Analiza
o Identyfikacja stosowanych podejść
podej architektonicznych
o Utworzenie drzewa atrybutów jakościowych
jako
o Analiza podejść
podej architektonicznych
• Testowanie
o Burza mózgów nt. scenariuszy
o Powtórna analiza podejść
podej architektonicznych
• Raportowanie
FUNKCJONALNOŚĆ: (czyli zbiór atrybutów opisujących zestaw
funkcji oprogramowania i ich właściwości. Przez funkcje rozumiane są
te, które spełniają wyrażone wprost lub nie wprost potrzeby)
Odpowiedniość (działanie systemu odpowiednie do wyspecyfikowanych
wymagań i dające sensowne wyniki) , dokładność (ISO), Interoperacyjność (zdolność systemu do komunikowania się z innymi
podłączonymi do niego systemami) , bezpieczeństwo(ISO)
(zapobieganie wyciekowi lub utracie ważnych danych i ochrona przed
nieuprawnionym dostępem), zgodność funkcjonalności (trzymanie się
standardów, konwencji i innych przepisów prawnych).
NIEZAWODNOŚĆ (czyli zbiór atrybutów opisujących zdolność
oprogramowania do spełnienia i utrzymania określonych wymagań, co
do jego stabilności działania, przy spełnieniu określonych warunków
oraz w ściśle określonych ramach czasowych)
Dojrzałość, Tolerancja uszkodzeń (ISO), odtwarzalność (ISO).
UŻYTECZNOŚĆ (czyli zbiór atrybutów opisujących nakład pracy
niezbędny do swobodnego posługiwania się oprogramowaniem oraz
indywidualną ocenę posługiwania się oprogramowaniem przez
zdefiniowaną lub wyrażoną nie wprost grupę użytkowników)
Planowanie jakości:
jako
3h, planowanie projektu?, dopracowanie: 3h,
Zdefiniowanie: 2h, Założenie
Zało
2h, Scalenie 4h.
Planowanie wg PRINCE2
Zrozumiałość, łatwość nauczenia się, łatwość operowania, atrakcyjność.
WYDAJNOŚĆ (czyli zbiór atrybutów opisujących powiązania między
poziomem wydajności oprogramowania, a wykorzystywanymi zasobami
przy spełnieniu określonych warunków)
Charakterystyka czasowa (ISO), zużycie zasobów (ISO)
ŁATWOŚĆ UTRZYMANIA (czyli zbiór atrybutów opisujących nakład
pracy niezbędny do wprowadzenia zmian do oprogramowania)
Drzewo użyteczności
użyteczno
Nazwa (Waż
Ważność, Trudność) [L,M,H]
Punkt wrażliwości
wraż
= właściwość o podstawowym znaczeniu dla
atrybutu jakościowego
jako
Punkt kompromisu = punkt wrażliwości dla więcej niż jednego atrybutu
jakościowego
ciowego
Selekcja scenariuszy:
Każdy
dy uczestnik ma N głosów, gdzie N = 30% lliczby scenariuszy. Głosy
przydziela się
si dowolnie (od 0 do N na dany scenariusz, byle suma <= N).
Głosuje się jawnie. Do dalszej analizy przechodzi K pierwszych (np. 5)
scenariuszy w sensie liczby oddanych na nie głosów.
Testy akceptacyjne i odbiór oprogramowania
Testowanie oprogramowania jest wykonaniem kodu dla kombinacji
danych wejściowych
wejś
i stanów w celu wykrycia błędów
Łatwość analizy (ISO), łatwość zmiany (ISO), stabilność, łatwość
testowania
PRZENOŚNOŚĆ (czyli zbiór atrybutów opisujących zdolność
oprogramowania do przenoszenia między różnymi
środowiskami/platformami)
DECYZJE ARCHITEKTONICZNE
Decyzje związane
zwi
z wydajnością:
• Typ zasobu •Szeregowanie zadań
zada • Synchronizacja •Równoważenie
obciążenia • Przydzielone zasoby
Decyzje wpływające
wpływaj
na dostępność:
•Nadmiarowo sprzętowa •Nadmiarowość programowa •Orzekanie
•Nadmiarowość
•Ponawianie •Układ alarmowy
Decyzje dotyczące
dotycz
modyfikowalności:
•Pośredniość
redniość (mediator) •Enkapsulacja (interfejs)
Planowanie w XPrince
Łatwość adaptacji (ISO), łatwość instalacji (ISO), współistnienie (ISO),
łatwość zamiany (ISO).
Szacowanie pracochłonności
Klasyfikacja metod:
• Metody ad-hoc
o Metoda delficka
• Metody oparte na modelach
o Metody ogólne
Metoda wartości rozmytych
Metoda punktów funkcyjnych
Metoda COCOMOII
Metoda punktów przypadków użycia
o Metody szczegółowe
Metoda probe
Architektura oprogramowania
Metoda wartości rozmytych (Putnam ’92). 1. Potrzebujemy oszacowań
rozmiaru, które są dokładne, ale nie koniecznie precyzyjne.
2. Odnieśmy oszacowanie do danych historycznych:
Mając dany najmniejszy (S) i największy (L) rozmiar, znajdź granice
zakresów A,B,C,D takie, że S,A,B,C,D,L tworzą postęp geometryczny:
A/S = B/A = … = L/D = p => L/S = p^5 => p = (L/S)^0,2
(częściowe podobieństwo do metody probe)
Metoda punktów funkcyjnych (Albreht ’79)
Podstawowe funkcje: Wejścia, Wyjścia (raport, ekran, komunikat o
błędzie – pojedyncze dane w raporcie nie są liczone osobno) , Zapytania
(bezpośrednie wejście stuktujące bezpośrednim wyjściem (zapytanie nie
może modyfikować żadnego pliku wewnętrznego (stanu)), Wewn. pliki
danych, Zewn. Interfejsy.
Punkty funkcyjne = Wstępne oszacowanie*Mnożnik złożoności
Mnożnik złożoności 0,65 .. 1,35
Mnożnik złożoności = 0,65 + 0,01* Współczynniki wpływu
14 współczynników wpływu: 0-5 pkt każdy;
Ocena współczynników: 0 – brak wpływu, 1 – Bardzo słaby, 2 – raczej
słaby; 3 – średni; 4 – istotny; 5 – zasadniczy
Współczynniki wpływu:
• Czy jest wymagane przesyłanie danych?
• Czy są funkcje przetwarzania rozproszonego?
• Czy wydajność ma kluczowe znaczenie?
• Czy system ma działać w mocno obciążonym środowisku
operacyjnym?
• Czy system wymaga wprowadzania danych on-line?
• Czy wewnętrzne przetwarzanie jest złożone?
• Czy kod ma być przystosowany do ponownego użycia?
Wpływ wyboru języka programowania na liczbę linii kodu / punkty
funkcyjne (Asm 320, C 128, Cobol 105, Fortran 105, Pascal 90, Ada 70,
Języki obiektowe 30, Arkusze kalkulacyjne 6)
Planowanie projektu
Poziomy: 1. Plan projektu
2. Plan wydania
3. Plan przyrostu
Struktura obejmująca:
obejmuj
Komponenty, widoczne z zewnątrz ich
właś
właściwości
i zależności między tymi komponentami
Style architektoniczne:
architektoniczne
• Architektura warstwowa
• Architektura pierścieniowa
• Klient-serwer
• Rozproszony klient-serwer
• Sekwencje filtrów
• Architektura potokowa
• Hurtownia danych
• Architektura tablicowa (współdzielone dane)
Architektura oprogramowania:
oprogramowania jest środkiem komunikacji między
udziałowcami projektu, prezentuje decyzje projektowe na wstępnych
wst
etapach rozwoju opr., jest abstrakcyjnym opisem systemu, który może
mo
być powtórnie użyty
Perspe
Perspektywy
architektury:
• Logiczna,
• Współbieżności
• Implementacyjna
• Fizyczna
• Przypadków użycia
Model zorientowany na usługi (SOA) i WebServices: powtórne użycie
i interoperacyjność;
interoperacyjno założenie: wszystko jest usługą: łącznie z
logowaniem i transformacją
transformacj danych. zalety krótszy czas dostawy na
rynek, silniejsze zorientowanie biznesu na wzrost, zredukowane
koszty, zredukowane ryzyko biznesowe
Pojęcie SOA obejmuje zestaw metod organizacyjnych i technicznych
Poję
mają na celu lepsze powiązanie biznesowej strony organizacji z jej
mający
zasobami informatycznymi. Mianem usługi określa się tu każdy element
oprogramowania, mogący
mog
działać niezależnie od innych oraz posiadający
zdefiniowany interfejs, za
z pomocą którego udostępnia realizowane
funkcje.
Analiza architektury oprogramowania, ATAM
ATAM=Architectural Trade-offs
Trade
Analysis Method
• Prezentacja
o Metoda ATAM (przedstawienie metody)
o Czynniki biznesowe (Wizja przedsięwzięcia, główni udziałowcy,
Najważniejsze funkcje, Ograniczenia, Kryteria jakości)
o Architektura (Ograniczenia tech. i kontekst, Perspektywy
architektoniczne •• Fizyczna ••Logiczna ••Implementacyjna ••
Współbieżności ••Kodu. Zastosowane podejścia architektoniczne,
Zasady testowania:
• Wszystkie testy powinny być
by powiązane z wymaganiami użytkownika
• Testowanie należy
nale planować na długo przed jego rozpoczęciem
• W przypadku testowania obowiązuje
obowi
zasada Pareto (80/20)
• Testowanie należy
nale przeprowadzać „od dołu do góry”
• Pewne testy powinny zostać
zosta wykonane przez niezależną, trzecią,
stronę
• Testowanie wyczerpujące
wyczerpuj
nie jest możliwe
Testy akceptacyjne:
akceptacyjne
Testy strukturalne – znane są także jako testy białej lub szklanej
skrzynki.. Polegają
Polegaj na testowaniu programu poprzez podawanie na
wejściu
ciu takich danych, aby program przeszedł przez ka
każdą
zaimplementowan ścieżkę. Zasady te są definiowane przez kryteria
zaimplementowaną
pokrycia
krycia wszystkich pętli
p
oraz wszystkich warunków. Testy białej
skrzynki nie są
s w stanie wykazać braku implementacji funkcji, którą
powinien posiadać
posiada system docelowy. Sprawdzają jednak dokładnie
operacje wykonywane w zaimplementowanych metodach.
Testy funkcjonalne
funk
znane są także jako testy czarnej skrzynki,
ponieważż osoba testująca
testuj
nie ma dostępu do informacji na temat budowy
programu, który testuje. Często
Cz
testy takie są wykonywane przez inne
osoby niżż programiści
programi tworzący program. Nierzadko są to osoby nie
posiadające
ące wiedzy z zakresu programowania. Osoba testująca
testuj
program
nie opiera danych testowych na budowie wewnętrznej
wewn
programu, lecz na
założeniach
eniach funkcjonalnych, jakie powinien spełniać
spełnia program zgodnie z
dokumentacj
dokumentacją.
Czynności
ści testowania:
• Zidentyfikuj
Zidentyfik warunki testowania (co testować?) i priorytety
• Zaprojektuj scenariusze testowe (jak testować)
testowa
• Zbuduj przypadki testowe (skrypty, dane)
• Przeprowadź
Przeprowad testy
• Porównaj faktyczne wyniki z oczekiwanymi
Atrybuty przypadków testowych:
• Na ile skuteczny w wykrywaniu testów?
• Na ile reprezentatywny? (im większa
wi
reprezentatywność, tym mniej
przypadków potrzeba)
• Na ile ekonomiczny?
• Na ile modyfikowalny (pielęgnacja)
(piel