Specyfikacja wymagań w Inżynierii Oprogramowania

09:21 Jakub Bauman 4 Comments

Aby powstał czy raczej został wdrożony jakiś program, z którego mają w ściśle określonym celu korzystać użytkownicy należy najpierw sprecyzować do czego on ma służyć, jakie funkcje ma realizować.
Użytkownicy czy potencjalni użytkownicy muszą w pewien sposób przekazać programistom czego oczekują od projektowanego rozwiązania czyli przedstawić wymagania dotyczące systemu. Wymagania te, aby ich na przykład nie zapomnieć należy zapisać jako tak zwaną "Specyfikację wymagań".
Wymaganie opisuje co system powinien robić, a specyfikacja stanowi zbiór.
Można więc założyć, że gdy spiszemy co system powinien robić to klient otrzyma oprogramowanie jakiego potrzebuje.
Niestety nie jest tak do końca. Istnieją przynajmniej dwa problemy.

Po pierwsze. Używana przez klienta terminologia często będzie przez nas niezrozumiała lub nie będziemy w stanie stwierdzić o co tak naprawdę chodzi. Gdy np. klient sprecyzuje, że chciałby aby system generował raport sprzedaży. Czy z takiego zapisu będziemy w stanie domyślić się jakie dane ma prezentować ten raport? Klient może użyć na przykład pojęć takich jak: Faktura, raport miesięczny, WZ, PZ, korekta faktury, nota korygująca, SAD, czas przygotowawczo-zakończeniowy, numer LOT. Niektóre z nich zapewne rozszyfrujemy, inne będą dla nas co najmniej zagadkowe.
Po drugie pewne działania wykonywane przez użytkownika mogą być dla niego tak oczywiste, że nie będzie w stanie przekazać nam niezbędnych szczegółów.

Niezrozumienie intencji klienta na etapie projektowania rozwiązania może doprowadzić nie tylko do niezgodnego z oczekiwaniami działania aplikacji, ale również do konfliktów wynikających z opóźnień lub nadmiernej pracochłonności.

Wniosek jest taki, że aby doprecyzować co tak naprawdę ma robić program potrzebujemy dobrze i w sposób zrozumiały zarówno dla klienta jak i dla nas specyfikacji wymagań.
Nietrudno się domyślić, że specyfikację wymagań należy opracować w porozumieniu z klientem.

Nasuwa się pytanie, kogo wysłać aby ustalił z klientem specyfikację wymagań. Nasz programista, nie mający zielonego pojęcia o tym, o czym będzie mówił klient raczej nie jest dobrym pomysłem. Powinniśmy wysłać tam analityka, który życzenia klienta będzie w stanie przedstawić w formie czytelnej dla programisty.

Nasz analityk powinien być:
- doświadczony w zakresie opracowywania specyfikacji wymagań,
- obeznany z funkcjonowaniem branży klienta,
- otwarty na porady ekspertów,
- znający wiele tzw "dobrych praktyk" czyli sprawdzonych metod działania programów.

Mówiąc analityk mamy na myśli niekoniecznie jedną osobę. Może to być, a często nawet powinien być zespół analityków.

Mówiąc o wymaganiach klient przede wszystkim będzie zwracał uwagę na wymagania funkcjonalne czyli charakteryzujące sposób działania systemu. My jako inżynierowie musimy zwrócić uwagę również na pozafunkcjonalne wymagania stawiane oprogramowaniu takie jak związane z bezpieczeństwem, stabilnością, wydajnością, niezawodnością.


Trzy podejścia do zapisu specyfikacji wymagań

Bardzo często wymagania specyfikuje się w jednej z trzech form:

- "System powinien"
- Funkcje systemu
- Przypadki użycia.

System powinien

Specyfikacja wymagań w tej formie to nic innego jak lista zapisów tego co powinien robić system.

- System powinien umożliwiać wystawienie faktury
- System powinien umożliwiać zmianę faktury
- System powinien drukować raport sprzedaży
...

Podejście ma jedną zaletę jaką jest łatwość zapisywania informacji, ma natomiast poważne wady takie jak:
- słaba czytelność,
- trudność sprawdzenia spójności i kompletności wymagań.

Funkcje systemu

Specyfikacja wymagań może być również zapisana za pomocą tzw. funkcji systemu. Definiuje się tu funkcje, które są tzw. czarnymi skrzynkami. Specyfikując system podajemy parametry wejściowe i oczekiwane dane wyjściowe tych funkcji, a czasem również efekty uboczne.


To podejście ma następujące wady. Funkcje są:
- słabo czytelne,
- trudne do zrozumienia.

Przypadki użycia

Metoda zapisywania specyfikacji wymagań w postaci przypadków użycia jest uznawana za najlepszą z tych trzech. Eliminuje ona błędy jakie posiadają poprzednio wymienione sposoby. Dodatkowo jest bardzo precyzyjna. Jako wadę można tu w zasadzie podać tylko pracochłonność i czasochłonność opracowania. Jednak zdaniem autora czas poświęcony na opracowanie przypadków użycia nie będzie czasem straconym.
Wśród zalet tej metody można wymienić:
- łatwość spisywania,
- czytelność,
- łatwość zrozumienia i wyobrażenia sobie przyszłego systemu.

Przykład jednego prostego przypadku użycia przedstawiono poniżej:

UC1: Wystawianie faktury
Główny scenariusz:
1. Sprzedawca pragnie wystawić fakturę.
2. Sprzedawca wpisuje pozycje faktury.
3. System podlicza fakturę, nadaje jej nowy numer i zapisuje w rejestrze
4. Sprzedawca drukuje fakturę.
Zapis przypadku użycia powinien mieć ustrukturyzowaną formę. Powinien zawierać:
- nazwę,
- identyfikator,
- główny scenariusz,
- rozszerzenia,
- atrybuty.


UC1: Wystawianie faktury
Atrybuty:
Główny aktor: Użytkownik
Priorytet: Wysoki
Źródło: Łukasz Nowak
Główny scenariusz:
1. Sprzedawca pragnie wystawić fakturę.
2. Sprzedawca wpisuje pozycje 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 (powrót do 2.)

Więcej informacji o przypadkach użycia będzie można odnaleźć w kolejnych artykułach.

Czym jest Inżynieria Oprogramowania

05:58 Jakub Bauman 10 Comments

Niniejszy artykuł można traktować jako wprowadzenie do Inżynierii Oprogramowania. Autor przedstawia swoje przemyślenia na temat przedmiotu w odniesieniu do praktyki stosowania jego metod.

Aby zdefiniować Inżynierię Oprogramowania należy najpierw zdefiniować samą Inżynierię.
Słowo inżynieria pojawia się w określeniu wielu dyscyplin.  Mamy np. Inżynierię Lądową, Inżynierię Środowiska, Inżynierię medyczną, Inżynierię Środowiska i wiele, wiele innych. Co oznacza to magiczne słowo "Inżynieria"?  Otóż jest to określenie działalności polegającej na projektowaniu, konstruowaniu, utrzymaniu efektywnych rozwiązań w oparciu o wiedzę naukową i techniczną. Trzeba również podkreślić, że inżynieria odnosi się do działań praktycznych, teoria naukowa może być dla niej tylko źródłem wiedzy.
Rozwijając tę myśl można powiedzieć że inżynier, jako człowiek zajmujący się inżynierią jest praktykiem, posiada nie tylko wiedzę teoretyczną ale potrafi ją wykorzystać w praktyce.

Przejdźmy do Inżynierii Oprogramowania. Wiemy już czym jest inżynieria, a czym jest Inżynieria Oprogramowania? Otóż jest to Inżynieria dotycząca oprogramowania. Zatem będzie się ona zajmowała projektowaniem, rozwojem i utrzymaniem oprogramowania.

Należy podkreślić, że inżynieria oprogramowania to nie tylko sztuka programowania. Obejmuje ona znacznie szerszy zakres zagadnień związanych z wytwarzaniem oprogramowania. Między innymi takich jak:

• specyfikacja wymagań dla oprogramowania
• projektowanie oprogramowania
• jakość oprogramowania
• testowanie oprogramowania
• wdrożenia oprogramowania
• prowadzenie projektów informatycznych

Algorytm LIFO w gospodarce magazynowej

07:07 Jakub Bauman 0 Comments

W jednym z poprzednich postów przedstawiony został algorytm FIFO. Teraz przedstawiony zostanie algorytm, który jest jakby odwróceniem koncepcji tj algorytm LIFO (ang. Last in, first out). W algorytmie tym stosuje się zasadę: ostatnie weszło, pierwsze wyszło.

Zasada działania tego algorytmu jest tożsama ze stosem, w którym jako pierwsze pobierane są elementy przychodzące jako ostatnie.

Rozważmy przykład z danymi takimi samymi jak w przykładzie dotyczącym FIFO: Firma zakupiła 10 sztuk towaru A w cenie 10 zł za sztukę,
po czym zakupiła kolejne 10 sztuk towaru w cenie 11 zł za sztukę. A następnie sprzedała 2 sztuki Towaru A. Jaka jest wartość towaru A w magazynie.

Algorytm FIFO w gospodarce magazynowej

02:29 Jakub Bauman 2 Comments

Dokument PZ

03:56 Jakub Bauman 3 Comments

Wszelkie operacje magazynowe, niezależnie od tego czy magazyn jest prowadzony za pomocą programu komputerowego czy bez, należy dokumentować. Służą do tego dokumenty magazynowe.
W niniejszym artykule zostanie omówiony dokument PZ - Przyjęcie zewnętrzne.

Przyjęcie zewnętrzne to operacja polegająca na przyjęciu do magazynu towarów bądź materiałów.
Dokument przyjęcia zewnętrznego, określany często symbolem PZ jest wystawiany przez magazyniera lub inną osobę przyjmującą towar na podstawie (w zależności od przyjętych zasad):

- Dokumentu WZ od dostawcy
- Faktury od dostawcy
- Rzeczywistych ilości dostarczanego towaru.

Oczywiście konieczna jest zgodność rzeczywistych ilości z dokumentami.
Należy tutaj pamiętać, że osoba podpisująca się na dokumencie poświadcza prawdziwość operacji. Jest to szczególnie ważne dla magazynierów odpowiedzialnych majątkowo za prowadzony magazyn.
W przypadkach niezgodności należy sporządzać protokoły niezgodności i wyjaśniać zaszłość z dostawcą.

Obejrzyj film o przyjęciu magazynowym.

Dokument PZ powinien zawierać następujące dane:

Dane nagłówkowe:
- Numer
- Datę wystawienia
- Dane kontrahenta - nazwa i adres
- Dane magazynu - nazwa i adres (istotne gdy dostawca ma wiele lokalizacji lub korzysta z magazynów prowadzonych przez podmioty trzecie)

Dane pozycji (PZ może zawierać wiele pozycji):
- Określenie towaru
- Ilość
- Cenę zakupu (w zależności od przyjętych warunków handlowych cena może nie być podawana na dokumentach PZ)

Oryginalne druki dokumentów PZ zawierają dwie ilości: ilość deklarowaną i ilość otrzymaną.

Przykładowy wydruk dokumentu PZ przedstawiono poniżej.



Używając dokumentów PZ w różnych branżach możemy spotkać się z potrzebą przenoszenia innych informacji np.:
- numerów seryjnych,
- numerów partii produkcyjnej,
- daty ważności,
- innych opisujących parametry towaru.
O tym jakie dane są potrzebne powinna decydować dogłębna analiza.

Obsługa tych informacji może decydować o wyborze systemu informatycznego. Gdy projektujemy system uniwersalny warto aby pozwalał na określenie tych danych w konfiguracji. Dla przykładu w oprogramowaniu enova365 możliwe jest zdefiniowanie cech do pozycji dokumentu, które pozwalają na przechowywanie dodatkowych informacji.

Projektowanie dokumentu typu Faktura UML i Baza danych

07:13 Jakub Bauman 14 Comments

Prowadząc zajęcia często spotykam się u studentów z problemami ze zrozumieniem czym jest i jak powinno się zaprojektować w systemie informatycznym dokument taki jak Faktura.
Posłużę się przykładem faktury jednak idea jaką zaprezentuje dotyczy wszelkich dokumentów.

Budowa dokumentu Faktura

Po pierwsze należy sobie uświadomić co powinna zawierać faktura. Wymienię tu najważniejsze elementy:

W nagłówku:

• Numer
• Data wystawienia
• Data sprzedaży
• Dane kontrahenta
• Termin płatności (*)
• Kwota brutto do zapłaty (**)

(*) - W bardziej złożonych systemach możemy rozważać wiele terminów płatności
(**) - Kwota brutto faktury nie zawsze będzie tożsama z kwotą do zapłaty np. gdy występowały wcześniej zaliczki


Pozycje faktury:

• Liczba porządkowa
• Nazwa towaru/usługi
• Cena jednostkowa
• Ilość
• Jednostka miary
• Wartość

Pozostałe

• Tabela VAT
• Tabela zaliczek
• Tabela płatności 

Jedna faktura - wiele pozycji

Projektując diagram klas UML czy diagram ERD dla baz należy przede wszystkim zwrócić uwagę na to, że na jednej fakturze może wystąpić wiele pozycji. Zatem projektując musimy rozważać dwie klasy i analogicznie dwie tabele bazy danych:

• Nagłówek Faktury
• Pozycje Faktury

Jak nietrudno się domyślić klasy te (jak i tabele) powinny być w relacji 1 do n. Jedna faktura ma n pozycji.

Dane kontrahenta w fakturze

Projektując tabelę nagłówkową można założyć, że znajdzie się w niej klucz obcy wskazujący na kontrahenta. Natomiast w UML klasa nagłówka będzie posiadała atrybut typu Kontrahent.
Warto tutaj zwrócić uwagę na to, że faktura jest dokumentem, który według przepisów należy przechowywać w niezmienionej formie. Zmiana danych adresowych kontrahenta nie może pociągać za sobą zmiany danych na zapisanej w bazie fakturze. Mamy tutaj dwie możliwości.

1. Przepisać dane do dokumentu 
2. Zwielokrotnić rekordy kontrahenta

W pierwszym rozwiązaniu naruszamy oczywiście drugą postać normalną bazy danych, jednak to rozwiązanie jest znacznie częściej wybierane przez projektantów systemów ERP i dodatkowo jest bardziej wydajne obliczeniowo oraz pozwala na realizację dostępu do danych za pomocą zapytań SQL o mniejszej złożoności składniowej.
Drugie rozwiązanie jest z punktu widzenia teorii baz danych bardziej poprawne jednak powoduje większą złożoność zapytań SQL jakich należy używać aby pobierać dane, a tym samym większą złożoność obliczeniową.

Zwiększenie mocy obliczeniowej jest znacznie droższe niż zwiększenie pamięci dyskowej komputera zatem ekonomia wskazuje również na pierwsze rozwiązanie.

Towary w pozycjach faktury

Kolejnym błędem jest interpretacja polegająca na tym, że pozycje faktury to towary. Nic bardziej mylnego.Towar to jeden z elementów pozycji. Pozycja zawiera również co najmniej informacje: o sprzedawanej ilości, o cenie sprzedaży...
Projektując system informatyczny mamy na celu usprawnienie pracy poprzez wybór towarów z tzw. kartoteki zatem klasa Towar, czy tabela Towary w bazie danych jest jak najbardziej zasadna jednak nie jest ona tożsama z pozycją.
Towary pozostają w relacji 1 do n do pozycji faktury. Jeden towar może wystąpić w wielu pozycjach dokumentów.

Inne elementy dokumentu

Dokumenty typu faktura powinny zawierać również informację o płatności. W prostych systemach można to rozwiązać wprowadzając pole termin płatności do nagłówka. Nie jest to jednak rozwiązanie zbyt dobre gdyż uniemożliwia wystawianie faktur zawierających wiele płatności. Na przykład przy zakupie jakaś wpłata gotówką, a pozostała kwota przelewem w określonym terminie. Inny przykład to plan wpłat. Dlatego należałoby utworzyć tabelę płatności w relacji 1 do n do nagłówka faktury.
Tabela taka powinna zawierać informacje takie jak:
- sposób płatności
- termin płatności
- kwota

Suma kwot płatności powinna być taka sama jak wartość brutto faktury.

Inny element jaki powinien być uwzględniony przy projektowaniu dokumentu typu faktura to informacja o zasobach (pozycjach przychodowych). Gdy stosujemy na przykład algorytm FIFO to przy sprzedaży rozchodujemy towar wg kolejności w jakiej pojawił się na magazynie. Zasadę tę wyjaśnia film . Gdy stosujemy taki algorytm magazynowy może się zdarzać, że gdy sprzedajemy towar pochodzi on z różnych partii zakupowych, które mogą mieć różne ceny. Wówczas na przykład na potrzeby kalkulacji marży powinniśmy powiązać pozycje faktury z pozycjami dokumentów zakupowych. Oczywiście to powiązanie jest bardziej zasadne w dokumencie PZ. Dlaczego? To zostanie wyjaśnione w osobnym artykule.

Autor zdaje sobie sprawę, że powyższy artykuł nie wyczerpuje tematu. Żywi jednak nadzieję, że chociaż w pewnym stopniu będzie pomocny dla projektujących systemy biznesowe.

Co to jest towar, co to jest produkt, co to jest materiał.

10:08 Jakub Bauman 4 Comments

Projektując lub wdrażając programy ERP w zakresie gospodarki magazynowej czy handlu, w każdym przedsiębiorstwie produkcyjnym czy handlowym możemy spotkać się z pojęciami takimi jak towar, produkt, materiał. Spróbujmy w prosty sposób zdefiniować te pojęcia:

Towar - to coś co kupujemy i sprzedajemy,
Produkt - to coś co produkujemy i sprzedajemy,
Materiał - to coś co kupujemy i używamy np. w procesie produkcyjnym.

Warto tutaj zauważyć, że wyżej wymienione podlegają wymianie handlowej i coś co jest produktem dla producenta, dla hurtownika będzie już towarem. Może też się zdarzyć że produkt będzie dla odbiorcy materiałem. Na przykład mąka dla młyna jest produktem, a dla piekarza materiałem.

W odniesieniu do materiału trzeba wiedzieć, że w szczególnych wypadkach jest możliwa jego sprzedaż mimo iż definicja tego nie przewiduje. 


Jak już wspomniano materiały są zużywane w działalności przedsiębiorstwa. Najczęściej w produkcji ale także inne przedsiębiorstwa korzystają z materiałów np. materiałów biurowych.

Prowadząc działalność przedsiębiorstwo wykorzystuje różne rzeczy, nie wszystkie to materiały. Weźmy na przykład narzędzia. Czy są materiałami czy nie. Odpowiedź nie jest bardzo prosta. Niektóre narzędzia używane są wielokrotnie i te raczej materiałami nie są, a niektóre zużywane są w procesach produkcyjnych i można powiedzieć że są materiałami.
Weźmy np. wiertła, ściernice, papier ścierny... te narzędzia mogą być zużywane a co za tym idzie możemy je uznać za materiały i ich koszt wliczać w koszt wytworzenia produktu.
Kosztowi wytworzenia będzie poświęcony odrębny artykuł.

Dodatkowo może się zdarzyć w tzw. mowie potocznej, że towar czy produkt używane są zamiennie. Prowadząc prace wdrożeniowe czy analityczne należy więc być czujnym.

Jednostki miary w gospodarce magazynowej

09:27 Jakub Bauman 2 Comments

Jednostki miary służą do określania ilości bądź liczby towarów/produktów/materiałów. Temat jednostek wydaje się prosty ale wcale taki prosty nie jest gdy mu się przyjrzymy dokładniej.
W prostych systemach handlowych gdy handlujemy towarami, których liczbę wyrażamy w sztukach to faktycznie jednostki miary nie sprawiają problemu bo jest to cały czas jedna jednostka. Jednak już gdy chcemy korzystać z opakowań zbiorczych i pojawia się jednostka opakowanie to zagadnienie jednostek miary przestaje być trywialne. Potrzebujemy wówczas możliwości przeliczania tych jednostek.

Przeliczniki jednostek

W praktyce możemy mówić o dwóch rodzajach przeliczników jednostek:
- niezależnych od towaru
- zależnych od towaru

Pierwsza grupa charakteryzuje się tym, że zdefiniowany przelicznik jest niezależny od towaru i może być zdefiniowany ogólnie do przeliczania jednostek. Może to być przelicznik wynikający z przedrostków układu SI np. 1 kg = 1000 g. Ale może to być inny przelicznik np. na inny system miar np. 1 l = 1 dm³. Innym przykładem będą przeliczniki jednostek ilościowych sztuk na jednostki takie jak tuzin, mendel, kopa. O ile ktoś chciałby takie jednostki stosować.

Druga grupa natomiast to przeliczniki, które nie mogą być zdefiniowane jako przelicznik ogólny gdyż są zależne od towaru, np. od jego gęstości. np. 1 l = 1 kg dla wody, ale już dla rtęci 1 l = 13,53 kg. Innym przypadkiem jest np. przelicznik metrów kwadratowych (np. blachy omówione poniżej) na kilogramy - taki przelicznik zależy od gęstości, a także grubości. Podobnym przykładem będą przeliczniki opakowań, to są przeliczniki określane dla towaru również indywidualnie np. 1 karton = 120 sztuk. W odniesieniu do tej grupy należy przewidzieć definiowanie przeliczników dla każdego towaru indywidualnie.

Mały quiz: Do której grupy zaliczymy przelicznik puszek piwa na czteropaki?

Rozważmy grupę towarową jaką są blachy i jednostki w jakich jej towary mogą być mierzone. - kilogram - podstawowa prosta jednostka, łatwo przestawić ilość blachy za pomocą tej jednostki - metr kwadratowy - jednostka określa powierzchnię blachy co niesie pewną informację użytkową. Do przeliczania na kilogramy potrzebujemy informacji o gęstości materiału oraz grubości blachy. - arkusz - jednostka zupełnie indywidualna, której parametry określa producent np arkusz o wymiarach 1200 x 2000 mmm. Inny producent może jednak udostępniać arkusze o innych wymiarach. Tu należy rozważyć czy nie powinniśmy definiować dwóch towarów.

Z punktu widzenia systemu ERP istotne jest do której z wyżej wymienionych grup będzie należał przelicznik. W pierwszym przypadku będzie zdefiniowany ogólnie dla całego systemu, natomiast w drugim do konkretnego towaru.

Precyzja jednostek 

Omawiając jednostki trudno nie wspomnieć o precyzji. W zależności od tego jakiej jednostki używamy będziemy wyrażali ją z odpowiednią dokładnością np. poprzez określenie miejsc po przecinku dla ilości. Jest to sprawa indywidualna i zależy od preferencji jakie ma przedsiębiorstwo. Niektóre firmy będą życzyły sobie określania masy towarów w kilogramach, z dokładnością do kilograma inne mogą w tonach z dokładnością do 10 kg. O tym jaka jest precyzja jednostek też należy pamiętać definiując przeliczniki. Może się bowiem dziać tak, że przeliczanie jednostek będzie powodowało zaokrąglenia.

Podsumowanie

Podsumowując można określić dwie sprawy do zapamiętania istotne przy projektowaniu, czy wdrażaniu oprogramowania. 1. Istnieją jednostki miary, które można zdefiniować dla systemu ogólnie, a także jednostki które trzeba definiować indywidualnie. 2. Należy pamiętać o tym, że dla jednostek należy określić ich precyzję.

Czym jest gospodarka magazynowa

02:32 Jakub Bauman 5 Comments

Gospodarka magazynowa to jeden z istotniejszych elementów zarządzania organizacją. Trudno wyobrazić sobie firmę handlową, czy produkcyjną nie posiadającą magazynu.

Oczywiście istnieją modele JIT (just in time), których idea ma eliminować zapasy, w praktyce jednak nawet w tego typu systemach definiuje się często magazyny buforowe dla zabezpieczenia procesu produkcyjnego przed zakłóceniami.

W ramach gospodarki magazynowej można wyodrębnić dwa zasadnicze elementy:

• Ewidencję magazynową
• Zagadnienia logistyki

Pierwszy z nich zapewnia docelowo sprawozdawczość podatkową ale również służyć może jako narzędzie optymalizacji zapasów, kalkulacji kosztów itp. Sporo informacji można znaleźć w cyklu filmów Gospodarka magazynowa opracowanym przez firmę ERPIT Sp. z o.o. dostępną pod adresem: http://erpit.pl/prezentacje/

Drugi natomiast to wszelkie zagadnienia dotyczące zarządzania magazynem czyli między innymi:

• lokowanie towarów w magazynie - np. wysokie składowanie
• optymalizacja składowania
• optymalizacja tras wewnętrznych
• zapewnienie odpowiednich warunków przechowywania