www.wszisi.fora.pl

piotro23

Hej.
Po odejściu od kasy reklamacji nie uwzględnia się
Jak mi kto da prostą instrukcję jak to zrobić wepchnąć plik wordowy.
No chyba, żę tu wszyscy już wszystko UMIĄ

AD1. CYKLE ŻYCIA OPROGRAMOWANIA, PRZYDATNOŚĆ, ZASADY DOBORU
1 Cykle życia oprogramowania
1.1. Naturalny model „Buduj i poprawiaj”
1.2. Modele kaskadowe
1.2.1. Model kaskadowy
1.2.2. Document driven (Realizacja kierowana dokumentami) US Army
1.2.3. Model V
1.2.4. Model W
1.2.5. Model kaskadowy z iteracjami
1.3. Modele ewolucyjne
1.3.1. Modele spiralne (klasyczny oraz winwin)
1.3.2. Modele przyrostowe
1.3.3. Modele prototypowe
1.4. Modele formalne
1.5. Model RAD
1.6. Modelowanie komponentowe
2 Zasady doboru
2.1. Model naturalny
1. Gdy tworzymy niewielkie oprogramowanie na własny użytek i nie wiemy jak się do tego zabrać
2.2. Model kaskadowy
1. Gdy wymagania są dobrze zdefiniowane, produkt jest podobny do realizowanych dotychczas, mamy doświadczenie w takich przedsięwzięciach
2.3. Model komponentowy
1. Gdy wymagania są dobrze zdefiniowane, produkt jest podobny do realizowanych dotychczas, mamy doświadczenie w takich przedsięwzięciach
2. Zawsze, gdy mamy taką możliwość
2.4. Model prototypowania
1. Gdy klient ma problemy z wyartykułowaniem swoich wymagań
2. Gdy wymagania są źle określone
2.5. Model spiralny
1. Gdy istnieje duża niepewność i ryzyko związane z wytworzonym produktem
2.6. Model przyrostowy
1. Gdy istnieje duża niepewność i ryzyko związane z wytworzonym produktem
2. Gdy wymagania są dobrze zdefiniowane, ale projekt jest złożony (duży)
3. Dość duży system, mały zespół, krótkie terminy, klientowi szczególnie zależy na pewnej części funkcjonalności
2.7. Model RAD
1. Duży system, duży zespół, krótkie terminy
2.8. Modele ekstremalne
1. Małe systemy, krótkie terminy, zaangażowany klient, doświadczony zespół

3 Przydatność modeli
Stosowanie modeli cyklu oprogramowania pozwala na:
1. Zaplanowanie strategii realizacji produktu
2. Określenie zasobów, kosztów i harmonogramu
3. Zdefiniowanie relacji z klientem i zasad akceptacji systemu

AD. 2 ZASADY LEKKICH METOD WYTWARZANIA OPROGRAMOWANIA
1 Geneza
1. kilkunastu amerykańskich programistów 2001 rok
2. Celem było zwiększenie efektywności wytarzania oprogramowania poprzez „deformalizacje” procesu projektowego i pracy zespołowej, zwiększenie kontaktu z klientem i oparciu procesu projektowego o silne idnywidualności.
2 Zasady
1. Pojedyncze osoby i interakcje pomiędzy ludźmi są ważniejsze, niż procesy i narzędzia
2. Działające oprogramowanie jest ważniejsze niż obszerna dokumentacja
3. Współpraca z klientem jest ważniejsza, niż negocjowanie kontraktów
4. Reakcja na zmianę jest ważniejsza niż realizowanie planu
3 Reguły
1. Zadowolenie klienta poprzez szybkie i ciągłe dostawy oprogramowania
2. Oprogramowanie jest tworzone w sposób umożliwiający wprowadzanie zmian w każdej chwili
3. Oprogramowanie dostarczane jest często (kilka tygodni do kilku miesięcy)
4. Codzienna praca z klientem
5. Projekty budowane wokół wyróżniających się indywidualistów. Ludzie są najistotniejszym czynnikiem sukcesu
6. Ograniczenie dokumentacji na rzecz komunikacji werbalnej
7. Miarą postępu prac projektowych jest liczba funkcjonalności, które spełniają potrzeby klienta
8. Promowanie tworzenia programu ze stałą prędkością bez forsowania tempa
9. Kluczem do szybkości jest wysoka jakość techniczna i dobry projekt
10. Nacisk na prostotę rozwiązań
11. Zespoły „agile team” są samoorganizujące się
12. W regularnych odstępach czasu grupa projektowa „dostraja się” poprzez omawianie metodologii pracy

AD. 3 METODY POZYSKIWANIA WYMAGAŃ OD UŻYTKOWNIKA
1 Lista metod
1.1. Analiza dokumentacji merytorycznej
1.1.1. Procedur przedsiębiorstwa
1.1.2. Ustawodawstwa
1.1.3. Analiza dokumentacji wejściowej i wyjściowej informatyzowanego procesu
1.1.4. Studia literatury przedmiotu
1.2. Komunikacja z ludźmi
1.2.1. Wywiady (ekspert dziedzinowy, sponsor projektu, użytkownik projektu)
1.2.2. Burze mózgów (wspólna analiza, wyłapywanie niespójności)
1.2.3. Obserwacja dotychczasowego sposobu realizacji procesu biznesowego
1.2.4. Prototypowanie
1.2.5. Ankiety
1.2.6. Metoda Delphi
1.3. Analiza systemu odziedziczonego
1.3.1. Analiza dokumentacji systemu odziedziczonego
1.3.2. Analiza interfejsów aplikacji
1.3.3. Analiza struktur bazodanowych
1.3.4. Analiza logiki aplikacji
2 Metoda Delphi
2.1. Opis
Kilkukrotne anonimowe ankietowanie tego samego zespołu ekspertów. W kolejnych cyklach ankiet, do pytań dołącza się syntetyczną informację w jaki sposób
2.2. Zalety
Uniknięcie dominacji liderów, niechęci do podważania wcześniejszych opinii
2.3. Wady
Wartość metody warunkowana jest dobrym doborem ekspertów
3 Atrybuty wymagań
3.1. Poprawne
3.2. Kompletne
3.3. Spójne
3.4. Weryfikowalne
3.5. Mierzalne
3.6. Odtwarzalne
4 Zagrożenia
4.1. Niewłaściwa współpraca (niechęć lub brak czasu klienta)

AD. 4 POJĘCIE WZORCA PROJEKTOWEGO, JEGO ZALETY I WADY
1 Opis idei
1.1. Wywodzą się wzorców projektowych w architekutrze zaproponowanych przez Alexandra 1977r
1.2. W informatyce – Kent Beck 1987. Spopularyzowane przez Bandę Czworga (1995)
1.3. Wzorzec projektowy identyfikuje i opisuje pewną abstrakcje na poziomie wyższym niż pojedyncza klasa, istancja lub komponent
1.4. Integralną częścią wzorca projektowego jest jego dokumentacja
1.5. Algorytm nie jest wzorcem projektowym – nie dotyczy architektury
2 Podział
2.1. Kreacyjne (opisujące inicjalizację i konfigurację obiektów)
2.2. Strukturalne (opisujące struktury i powiązanych ze sobą obiektów)
2.3. Behawioralne (opisujące zachowanie i odpowiedzialność obiektów)
3 Elementy wzorca
3.1. nazwa
3.2. problem
3.3. rozwiązanie
3.4. konsekwencje
4 Elementy dokumentacji
4.1. nazwa
4.2. przeznaczenie
4.3. aliasy
4.4. motywacja
4.5. stosowalność
4.6. współpraca
4.7. konsekwencje
4.8. implementacja
4.9. przykładowy kod
4.10. przykłądowe zastosowanie
4.11. pokrewne wzorce
5 Przykłady wzorców projektowych
5.1. Struktura drzewiasta (katalog rzeczowy biblioteki) Composite – strukturalny
Wzorzec wspomaga tworzenie struktury drzewiastej. Sklada się z trzech klas: Komponent – wspólny element wzorca deklaruje wspólny interfejs dla wszystkich obiektów struktury. Implementacja Liść – reprezentuje węzły bez potomków i węzły pośrednie
5.2. Karta czytelnika (3 typy kart – różnią się metodami (sposób naliczania kar...). Stan jest taki sam) STATE – behavioralny
Wzorzec wspomaga tworzenie struktury obiektów mających wspólne właściwości i różne metody obsługi. Składa się z obiektu głównego przechowującego właściwości i referencji do obiektu specyfikującego zachowanie się tego typu obiektu. Struktura: Obiekt typu Kontekst posiada referencję do obiektu StanAbstrakcyjny (i właściwości obiektu), wskazującego na bieżący stan. Obiekt StanKonkretny dzidziczący po StanAbstrakcyjny przechowuje metody specyfikujące obiekt danego typu
5.3. Lista książek pobierana w czasie przeglądania bazy danych. Flyweight – strukturalny
Wzorzec wspomaga odciążanie pamięci poprzez lepszą obsługę wielu małych obiektów za pomoc współdzielenia.(+mniej pamięci – większe obciążenie)

AD. 5 PRZEWIDYWANIE CZASU I KOSZTÓW WYTWARZANIA
1 Składowe kosztów wytwarzania oprogramowania
1.1. Koszty działalności firmy
1.1.1. Koszty eksploatacyjne budynku
1.1.2. Koszty amortyzacji sprzętu i oprogramowania
1.1.3. Koszty personelu nieprodukcyjnego
1.2. Koszty związane z bezpośrednio z zadaniem produkcyjnym
1.2.1. Koszt wynajmu i zakupu sprzętu i oprogramowania przeznaczonego do realizacji danego zadania
1.3. Koszt pracy personelu produkcyjnego
1.4. Koszty szkoleń pracowników do realizacji danego zadania
2 Ogólna metodyka szacowania kosztów i czasu wytwarzania oprogramowania
2.1. Określenie zakresu działania oprogramowania
2.2. Oszacowanie wielkości oprogramowania przy wykorzystaniu technik dekompozycyjnych
2.3. Szacowanie czasu realizacji przedwsięziecia w oparciu o metody analityczne lub prognostyczne
2.4. Przeliczenie kosztów realizacji oprogramowania z uwzględnieniem kosztów stałych firmy.
3 Zagadnienia związane z szacowaniem kosztów i czasu wytwarzania
1. Błąd szacowania na początku projektu może wynosić 4 krotność wartości produktu
2. Zależność pomiędzy liczbą pracowników, a czasem realizacji nie jest liniowa
4 Bezpośrednie koszty produkcji są funkcją czasu realizacji zadania. Podstawą wyliczeń czasu realizacji są miary wielkości oprogramowania lub miary procesu produkcyjnego.
4.1. Miary uwzględniające wielkość kodu źródłowego
4.1.1. Liczba linii kodu (LOC)
4.1.2. Liczba funkcji
4.1.3. Liczba obiektów
4.2. Miary uwzględniające wielkość oprogramowania
4.2.1. Miara punków funkcyjnych
Oparta jest o doświadczalny wzór uwzględniający 5 aspektów funkcjonalności i 14 współczynników złożoności oprogramowania (wymagań niefunkcjonalnych). Aspekty funkcjonalne:
1. Liczba wejść użytkownika (liczba miejsc, gdzie użytkownik wprowadza dane)
2. Liczba wyjść użytkownika (raporty, okienka, komunikaty błędów)
3. Liczba zapytań użytkownika (gdzie użytkownik wprowadza zapytanie)
4. Liczba plików (danych)
5. Liczba interfejsów
Współczynniki złożoności (0-5): kopie danych, wspópraca z zewnętrznymi systemami, znaczenie efektywności.
4.2.2. Rozszerzenie miar funkcyjnych
1. Miara punktów cech (uwzględnia złożoność algorytmów)
2. Miara trójwymiarowych punktów funkcyjnych (dla systemów czasu rzeczywistego)
4.2.3. Miara punktów obiektowych
Oparta jest o 3 aspekty funkcjonalności
1. Ekrany (interfejsy użytkownika)
2. Raporty
3. Komponenty (potrzebne do zbudowania aplikacji)
Dla każdego z aspektów wylicza się kwantyfikowaną wartość złożoności (prosty, średni złożony), w oparciu o liczbę i pochodzenie tabel danych niezbędnych do przygotowania aspektu oraz ilości części, z których aspekt się składa.
4.2.4. Miara oparta na dokumentacji (przypadki użycia – enterprise manager)
5 Metody szacowania wielkości oprogramowania
5.1. Metody analityczne wykorzystujące technikę dekompozycji
Opierają się na oszacowaniu wielkości oprogramowania i odniesieniu ich do danych historycznych.
1. Oszacowanie wielkości kodu (doświadczenie, dane historyczne, intuicja)
2. Szacowanie czasu – optymistyczne, pesymistyczne i najbardziej prawdopodobnej
3. Obliczenie wartości oczekiwanej (1+4+1)/6
4. Iloczyn wartości oczekiwanej i średniego kosztu i czasu wytwarzania

5.1.1. Dekompozycja produktu w oparciu o LOC
5.1.2. Dekompozycja oparta o miary funkcyjne (FT)
5.1.3. Analiza procesu wytwarzania

5.2. Metody prognostyczne
Opierają się o ustalone doświadczalnie formuły matematyczne. wiążące pracochłonność z miarami LOC lub FT. Istnieje wiele modeli prognostycznych uzależnionych od określonego typu oprogramowania. E=A+B*(ev)C.
5.2.1. COCOMO (1,2) – COnstructive COst MOdel (niewielkie projekty, niewielka dokładność)
Jest to hierarchia modeli używanych na różnych etapach procesu produkcyjnego
1. Model struktury aplikacji (początkowa faza procesu wytwórczego)
2. Początkowy model projektowy – po dokładnym ustaleniu wymagań stawianych produktowi
3. Model gotowej architektury – stosowany w fazie konstruowania oprogramowania
Modele prognostyczne wykorzystują jako miarę wielkości projektu Punkt Obiektowe, Punkty funkcyjne i LOC.
5.2.2. Równanie programistyczne E=(LOCxB0,333/P)3 x t-4
Równanie oparte na danych pochodzących z 4000 przedsięwzięć programistycznych
1. B – współczynnik specjalnych umiejętności (0,16;0,39)
2. P – współczynnik wydajności (2000 wbudowany s. czasu rzeczywisteog, 10000system operacyjny, 28000 aplikacja informacyjna dla firm)
a. ogólna dojrzałość procesu wytwórczego
b. zakres stosowania metodyk inżynierii
c. stan środowiska programistycznego
d. umiejętności i dośw. pracowników
e. złożoność planowania aplikacji

AD. 6 ZASADY ZARZĄDZANIA ZASOBAMI W CZASIE TRWANIA PROJEKTU INFORMATYCZNEGO
1 Jako zasoby w projekcie informatycznym rozumiemy ludzi, sprzęt komputerowy, oprogramowanie, pomieszczenia i inne czynniki niezbędne do realizacji projektu
2 Zarządzanie zasobami polega na:
2.1. Oszacowaniu rodzaju i ilości zasobów niezbędnych do realizacji przedsięwzięcia
2.2. Pozyskanie tych zasobów
2.3. Zaplanowanie prac aby najlepiej wykorzystać posiadane zasoby
2.4. Śledzenie i zarządzanie zmianami w projekcie
3 Metodyki tworzenia harmonogramów
3.1. PERT (losowe traktowanie wartości czasu (1+4+1)/6
3.2. CPM
4 Harmonogramowanie projektu
4.1. Wyznaczanie podstawowej jednostki – zadania 8-80 godzi
4.2. Dekompozycja projektu na zadania
4.3. Ustalenie odpowiedzialności za realizowane zadania
4.4. Ustalenie kolejności realizacji zadań, możliwości równoległego ich wykonywania
4.5. Ustanowienie kamieni milowych
4.6. Ustanowienie rezerwy czasowej na nieprzewidziane zdarzenia (zapas cząstkowy, całkowity, dodatkowy)
4.7. Wyznaczenie daty realizacji projektu.
4.8. Plan awaryjny
5 Przyczyny zmian w harmonogramie
5.1. Błędy przy szacowaniu czasu realizacji projektu
5.2. Zmiany wymagań klienta
5.3. Problemy z ludźmi (absencje, zmniejszenie wydajności, zła komunikacja)
5.4. Zmiany zasad finansowania projektu, odgórne zmiany daty zakończenia, kłopoty z realizacją zamówionych zasobów

6 Metody pozyskiwania informacji o postępach projektu
6.1. Spotkania sprawozdawcze
6.2. Analiza wyników przeglądów technicznych
6.3. Kontrola zrealizowanych kamieni milowych
6.4. Porównywanie czasu rozpoczęcia kolejnych zadań projektu
6.5. Ilościowa metoda analizy wartości uzyskanej

7 Metody korygowania harmonogramu
7.1. Przyspieszenie
Równoległe wykonywanie zadań, które miały wykonwyać się kolejno (ryzyko)
7.2. Rozbijanie
Przydzielanie dodatkowych pracowników do pracochłonnych zadań i skrócenie czasu realizacji
7.3. Obciązanie
Przyspieszenie poprzez zbliżenie i częściowe zachodzenie zadań
7.4. Odstępy czasowe
Zmienijszanie czasu odstępu pomiędzy zdaniami, które powinny być rozdzielone przerwą
8 Metody dotrzymywania terminu projektu
8.1. Zwiększanie zasobów
8.1.1. Nadgodziny
8.1.2. Przydzielanie ludzi do pracy
8.2. Ograniczenie funkcjonalności produktu

AD. 7 METODY OCENY JAKOŚCI OPROGRAMOWANIA
1 Podstawą mierzenia jakości oprogramowania są jasno sprecyzowane wymagania
2 Różnorodność kryteriów oceny jakości budowanych systemów informatycznych
2.1. Zgodność z analizą wymagań
2.2. Satysfakcja klienta
2.3. Jakość kodu i dokumentacji – założenia, model!!
2.4. Ilość błędów
3 Wskaźniki jakości oprogramowania
3.1. Poprawność
Ilość zgłoszonych usterek w ciągu roku
3.2. Pielęgnowalność
Używamy miar pośrednich. Średni czas dokonania zmiany (czas na analizę realizację i wdrożenie zmian). Lub „Zepsucie oprogramowania” (Hitachi) średni koszt usunięcia usterek.
3.3. Integralność
Odporność oprogramowania na przypadkowe lub celowe próby zakłócenia jego działania. Miarą integralności jest suma iloczynu prawdopodobieństwa zagrożenia (1-P) i bezpieczeństwa (prawdopodobieństwa, że atak się nie powiedzie) (1-0) dla każdego możliwego zagrożenia)
3.4. Łatwość użytkowania
Miarami łatwości użytkowania są:
1. Umiejętności użytkownika niezbędne do opanowania obsługi oprogramowania
2. Czas potrzebny na osiągnięcie przeciętnej sprawności w posługiwaniu się nim
3. Zwiększenie wydajności realizacji zadań w porównaniu z poprzednio stosowanym rozwiązaniem.
4. Subiektywna ocena użytkowników (ankiety)
4 Metodyka oceny jakości oprogramowania
4.1. Czynniki McCalla
Tworzona jest macież 11 czynników jakości z obszaru działania, modyfikowania i przenoszenia produkut oraz 22 miar jakości.
Dla każdego czynnika wyliczany jest Fq=c1 x m1............. (Wartość czynnika F, m wartosc miary, c waga –dobierana w zależności od typu projektu).
Wadą rozwiązania jest subiektywność przyjętych miar.
4.2. Czynniki FURPS (Functionality, Usability, Reability, Performance, Supportability)
Metodyka oceny wypracowana przez HP.
4.3. Czynniki jakości ISO 9126

AD. 8 ZAPEWNIENIE JAKOŚCI OPROGRAMOWANIA
1 Główne postulaty zapewnienia jakości
1.1. Jakość zapewniana jest na wszystkich etapach procesu produkcyjnego
1.2. Za zapewnienie jakości powinna odpowiadać komórka przedsiębiorstwa niezależna od kierownictwa nadzorowanego projektu
1.3. O zapewnienie jakości produktu dbają równolegle zespoły informatyczne i dział kontroli
1.4. Zapewnienie jakości związane jest z kosztami
1.5. Koszty usterek gwałtownie rosną wraz z czasem ich wykrycia (40-1000) razy
2 Zapewnienie jakości przez programistów
2.1. Stosowanie się do sprawdzonych metodyk pracy
2.2. Prowadzenie pomiarów
2.3. Wykonując formalne przeglądy techniczne
2.4. Realizując testy
3 Zapewnienie jakości pracy przez zespół kontroli jakości
3.1. Przygotowanie planów zapewnienia jakości
3.2. Uczestniczenie w ustalaniu postaci procesu wytwórczego
3.3. Sprawdzanie zgodności prowadzonych prac ze zdefiniowanym procesem
3.4. Srawdzanie zgodności produktów z wymaganiami opisu procesu wytwórczego
3.5. Przechowywanie, analiza i raportowanie o wykrytych niezgodnościach.
4 Czynniki procesu produkcyjnego mające wpływ na jakość
4.1. Etap planowania
4.1.1. Spójna, Kompletna, poprawna i łatwa do sprawdzenia analiza wymagań
4.1.2. Dobre określenie czasu realizacji przedsięwzięcia
4.1.3. Analiza ryzyka przedsięwzięcia
4.1.4. Przygotowanie przypadków testowych
4.1.5. Niezależna weryfikacja dokumentacji poprzez formalne przeglądy techniczne
4.2. Etap implementacji
4.2.1. Stosowanie się do przyjętego stylu programowania (nazwy własne, obsługa błędów, odporność na błędy)
4.2.2. Dobra dokumentacja kodu
4.2.3. Programowanie parami, przeglądy wzajemne
4.3. Etap testowania
4.3.1. Zastosowanie modelu V
4.3.2. Metoda czarnej skrzynki, przezroczystej skrzynki, testowanie integracyjne
4.3.3. Pomiary ilości usterek
4.3.4. Testy alfa i beta
4.4. Faza pielęgnacji
4.4.1. Zaplanowanie i zorganizowanie procesu zgłaszania, przyjmowania i obsługi usterek
4.4.2. Rejestrowanie informacji o usterkach
5 Koszt jakości
5.1. Zapobieganie
5.1.1. planowanie jakości
5.1.2. formalne przeglądy techniczne
5.1.3. narzędzia do testowania
5.1.4. szkolenia
5.2. Ocenianie
5.2.1. Inspekcji procesu produkcyjnego
5.2.2. konfigurowania i pielęgnowania narzędzi
5.2.3. testowania
5.3. Koszt niepowodzeń wewnętrznych
5.3.1. przeróbek
5.3.2. poprawek
5.3.3. analizy wykrytych błędów
5.4. Koszt niepowodzeń zewnętrznych
5.4.1. analizy zgłoszeń
5.4.2. pomocy użytkownikom
5.4.3. napraw gwarancyjnych
6 Normy wspomagające zapewnienie jakości
6.1. ISO 9001
20 wymagań spełnianych przez skuteczny system zapewnienia jakości. Opisuje zadania kieroniwctaa, system jakości, metody oceny kontraktów, sprawdzanie dokumentów i projektó6.2., danych,...
6.3. ISO 900-3
Zestaw wskazówek specjalizowanych dla produkcji oprogramowania
6.4. IEEE94 – Norma przygotownania planu zapewnienia jakości

AD. 9 POZIOMY JAKOŚCI FIRM INFORMATYCZNYCH
1 Poziom dojrzałości procesów wytwórczych (Capability Matrurity Model)
Jest to system oceny jakości procesów wytwórczych w przedsiębiorstwie informatycznym
2 Poziomy
2.1. Początkowy
Proces wytwórczy zależy od aktualnych potrzeb. Nie istnieją ustalone procedury działania. Sukces przedsięwzięcia zależy przede wszystkim od zaangażowania pracowników.
2.2. Powtarzalny
Realizuje podstawowe procesy kontrolowania kosztów, harmonogramów. Przyjęte rozwiązania umożliwiają powtarzanie poprzednich sukcesów z podobnymi produktami.
2.3. Zdefiniowany
Opracowano ustalony schemat procesu wytwórczego obejmujący zarówno czynności techniczne, jak i metody zarządzania. We wszystkich przedsięwzięciach stosuje się ten sam model procesu.
2.4. Zarządzany
Prowadzone są dokładne pomiary zaawansowania procesu i jakości produktu. Zarówno proces i produkt poddawane są analizie ilościowe i kontrolowane za pomocą pomiarów.
2.5. Optymalizowany
Proces wytwórczy jest stale ulepszany na podstawie poprzednich doświadczeń, a także w wyniku przeprowadzanych pomysłów i technik
3 W metodzie CMM określono 18 kluczowych elementów procesu wytwórczego i przydzielono do określonych poziomów dojrzałości. Ich spełnienie określane przez odpowiedź na odpowiednie pytania określa osiągnięty poziom

AD. 10 ZASADYANALIZY I PROJEKTOWANIA SYSTEMÓW INFORMATYCZNYCH
1 Tworzenie systemu informatycznego można określić jako odwzorowanie w modelu wycinka rzeczywistości uwzględniającego wybrane parametry tej rzeczywistości. Kolejne etapy realizacji modelu służą do zwiększania abstrakcji realnego świata, jednocześnie zmniejszając abstrakcję budowanego systemu informatycznego. Budowa systemu informatycznego polega na uściślaniu jego abstrakcji
2 Analiza systemu informatycznego jest procesem zbierania informacji o wymaganiach klienta i przetwarzania ich do postaci modelu biznesowego i weryfikowanie wykonalności realizacji zadania. W skład prac analitycznych wchodzą:
2.1. Pozyskiwanie i analiza informacji o wymaganiach funkcjonalnych i niefunkcjonalnych
2.2. Analiza wykonalności
2.3. Analiza opłacalności przedsięwzięcia
2.4. Analiza ryzyka przedsięwzięcia
2.5. Budowa modelu analitycznego
3 W wyniku prac analitycznych otrzymujemy
3.1. Uzasadnienie ekonomiczne budowy systemu
3.2. Szczegółową specyfikację wymagań funkcjonalnych i niefunkcjonalnych
3.2.1. Opis systemu
3.2.2. Diagram przypadków użycia + scenariusze
3.2.3. Prototyp aplikacji przynajmniej w postaci projektu interfejsów
3.2.4. Model analityczny systemu informatycznego
1. Opis obiektów danych
2. Specyfikacja procedury
3. Specyfikacja przepływu sterowania
4. Słownik danych
3.3. Instrukcję użytkownika
3.4. Plan testów akceptacyjnych i systemowych
3.5. Wstępny harmonogram kosztów i czasu realizacji przedsięwzięcia
3.6. Umowę z klientem ze ściśle określonymi zasadami odbioru
4 Projektowanie jest kolejnym etapem budowy abstrakcji systemu informatycznego. Jego zadaniem jest przetworzenie modelu analitycznego na szczegółową specyfikację projektową w postaci:
4.1. Projektu danych
4.2. Projektu architektury
4.2.1. Modularyzacja
4.3. Projektu interfejsu
4.4. Projektu procedur
5 Projektowanie odbywa się w dwóch fazach:
5.1. zróżnicowania
5.2. scalania
6 Zasady projektowania
6.1. Rozważanie i ocena wielu rozwiązań problemów
6.2. Mapa odwołań do modelu analitycznego
6.3. Sprawdzone rozwiązania
6.4. Struktura projektu powinna naśladować strukturę problemu
6.5. Projekt ma być jednorodny i spójny. Ustalone zasady tworzenia projektu!
6.6. Struktura projektu powinna umożliwiać wprowadzanie zmian
6.7. Struktura projektu powinna wspierać odporność na nieprzewidziane zdarzenia.
6.8. Jedyne decyzje projektowe podejmowane w trakcie oprogramowania to sposób implementacji szczegółów związanych z charakterem danego języka programowania
6.9. Ciągła weryfikacja jakości projektu
6.10. Konieczne formalne przeglądy techniczne

AD. 11 ZASADY MODELOWANIA SYSTEMÓW W NOTACJI UML
1 UML (Unified Model Language) jest formalnym językiem do graficznego przedstawiania wybranego fragmentu rzeczywistości. W informatyce wykorzystywany jest do analizy i projektowania obiektowych systemów informatycznych. W jego skład wchodzę diagramy opisujące struktury i zachowania. UML jest standardem otwartym dopuszczającym możliwość dostosowywania go do potrzeb projektu. Architektura tego języka składa się z czterech warstw abstrakcji, na których możemy modyfikować go. Wykorzystując wbudowany język OCL wbudowany w UML możliwe jest definiowanie dodatkowych ograniczeń obiektowych. Aktualna wersja UML to 2.2
2 Kategorie diagramów realizowanych w języku UML
2.1. Diagramy struktur
2.1.1. Diagramy klas
2.1.2. Diagramy obiektów
2.1.3. Diagramy komponentów
2.1.4. Diagramy wdrożenia
2.1.5. Struktur, Pakietów, Profili
2.2. Diagramy zachowań
2.2.1. Przypadków użycia (współpraca ze scenariuszami
2.2.2. Maszyny stanów (dla obiektu)
2.2.3. Aktywności
2.2.4. Interakcji
 Kolaboracji
 Sekwencji
 Czasowe, przeglądu interakcji
3 Wykorzystanie UML w narzędziach CASE
3.1. Enterprise Architect
3.2. Microsoft Visio
3.3. yED Graph Editor

AD. 12 OPISZ ZAWARTOŚĆ DOKUMENTÓW PROJEKTU INFORMATYCZNEGO
1 Efektem realizacji prac projektowych jest specyfikacja projektowa zawierająca
1.1. Opis zakresu prac projektowych (specyfikacja systemu + model analityczny)
1.2. Opis danych
1.2.1. Struktura używanych baz danych
1.2.2. Struktura plików zewnętrznych
1.2.3. Wewnętrzne struktury danych (model logiczny)
1.2.4. Indeks łączący model logiczny danych ze strukturą bazodanową.
1.3. Opis architektury systemu
1.3.1. Architektura opracowana na podstawie modelu analitycznego
1.3.2. Hierarchia modułów
1.4. Specyfikacja interfejsów
1.4.1. Interfejsy wewnętrzne i zewnętrzne
1.4.2. Specyfikacja interfejsu użytkownika + prototyp
1.5. Opis procedur realizowanych przez system
1.5.1. Dokument definiujący wszystkie (cel i sposób działania)
1.5.2. Dokumenty formalne
1.6. Indeks mapujący poszczególne elementy projektu ze specyfikacją wymagań (kontrola + zarządzanie wymaganiami)
1.7. Plany testów modułowych i integracyjnych
1.8. Plan wdrożenia systemu
1.9. Instrukcja obsługi
1.10. Dokumentacja dodtatkowa
1.10.1. Opisy algorytmów
1.10.2. zastępcze procedury działania
1.10.3. Odwołania do innych dokumentów
1.10.4. Informacje związane z kontrolą jakości
1.10.5. Informacje o standardach

AD. 13 OMÓWIĆ RODZAJE TESTÓW OPROGRAMOWANIA
1 Podział ze względu na poziom testu
1.1. Testowanie jednostkowe
1.1.1. biała skrzynka
 Testowanie ścieżek (droga przez pętle, wywołania, warunki
 Testowanie mutacyjne
1.1.2. czarna skrzynka
 Wartości specjalne
 Kontekst użycia danych
1.2. Testowanie integracyjne
1.2.1. Zstępujące (w głąb, wszerz) – od głównego w dół
1.2.2. Wstępujące
1.2.3. Regresyjne
1.2.4. Na dym (testowanie pobieżne, codzienne)
1.3. Testowanie systemowe
1.3.1. Testowanie akceptacyjne
1.3.2. Testowanie alfa
1.3.3. Testowanie beta
1.4. Testowanie systemów
1.4.1. Testowanie wznowień (test autonaprawiania się systemu)
1.4.2. Testowanie bezpieczeństwa
1.4.3. Testowanie obciążeniowe
1.4.4. Testowanie efektywności

AD. 14 OMÓWIĆ TRÓJWARSTWOWĄ ARCHITEKTURĘ APLIKACJI INTERNETOWEJ
1 HIstoria
1.1. jednostanowiskowe
1.2. klient-serwer
1.3. trójwarstwowe (wielowarstwowe)
2 Architektura
2.1. Warstwa klienta
2.2. Logiki biznesowej
2.3. Danych
3 Zalety
3.1. Sterowanie interfejsem uż
3.2. Odciążenie komputera klienta
3.3. Instalacja i aktualizacja
4 Wady
4.1. Konieczność utrzymania komunikacji
4.2. Obciążenie sieci
4.3. Kłopoty z zapisywaniem stanu bieżącego
4.4. Walka o stan obiektu

AD. 15 PODSTAWOWE ATRYBUTY JAKOŚCI
1 Czynniki McCalla
1.1. Obszar działania
1.1.1. Zgodność (ze specyfikacją i potrzebami klienta)
1.1.2. Niezawodność (realizowanie swoich funkcji z wymaganą precyzja)
1.1.3. Integralność (Odporność na niepowołąny dostęp i uszkodzenia zewnętrzene)
1.1.4. Efektywność (Wydajność, Wielkość zasobów)
1.1.5. Łatwość użytkowania (Wysiłek potrzebny do opanowania aplikacji)
1.2. Obszar modyfikowania
1.2.1. Pielęgnowalność (wysiłek do zlokalizowania i usunięcia błędu)
1.2.2. Elastyczność (wysiłek do zmiany funkcjonalnosci)
1.2.3. Testowalność
1.3. Obszar przenoszenia
1.3.1. Przenoścność (do innego środowiska sprzętowego lub programowego)
1.3.2. Możliwość wielokrotnego użycia (recykling kodu)
1.3.3. Współoperatywność (połączenie systemu z innym systemem)
2 Czynniki FURPS (Functionality, Usability, Reability, Performance, Supportability)
Metodyka oceny wypracowana przez HP.
3 Czynniki jakości ISO 9126
3.1. Funkcjonalność
3.2. Niezawodność
3.3. Łatwość użytkowania
3.4. Efektywność
3.5. Pielęgnowalność
3.6. Przenośność