1.
Cocomo – metoda bazuje na znajomosci linii kodu(jesli wiemy ile jest linii albo jestesmy w stanie oszacowac to mozemy odpowiecdziec na nastepne pytania o to jak duzy bedzie nasz projekt. Bazuje ona na tym ze kazdy z projektow przyopisujemy do 1 z 3 grup 1 dlugi zlozony 2 prosty krotki 3 posredni. Po zakwalifikowaniu do 1 z grup mamy algorytmy ktore wyliczaja c zas projektu i koszt.
Zalety: prosta Wady: jesli bazujemy na falszywych przeslankach to i wyniki beda falszywe. Sluzy do audytu istniejacego uklonczonego projektu badz do malych projektow.
Punkty Funkcyjne - bazuje na tym co potrafimy zdefiniowac w projekcie na jego poczatku(cocomo – na koncu). Bazuje na 5 obszarach – 1. zlozonosc wejsc(czy klawiatura czy interfejs graficzny) 2.
klasyfikacja projektu do 1 z trzech szufladek(zlozone, proste, posrednie). Na podstawie danych wejsciowych wyznaczamy punkty a pozniej dokonujemy korekty(zmiejsza badz zwieksza ilosc punktow). Zalety – do jej startu potrzebne sa dane dostepne na starcie projektu, daje dobre efekty.
Wady: bardzop zalezna od wiedzy i doswiadczenia(nastroju) analityka.
Use Case -
zalezy od analityka, wystarczy znajomopsc use casow. Najpopularniesjza metoda szacowania
2.Najwazniejsdze zalety wytwarzania softu wedlug modelu iteracyjnego.
1.Model kaskadowy
2.model przyrostowy(iteracyjny) spiralny???
model kaskadowy – klasycznie opiera sie na tym iz mamy faze (rozpoznania,l wymagan, implementacja, testowanie itp) przechodzimy od fazy do fazy i nie wracamy do poprzednich zalety – wszystko pokolei, latwy w planowaiu i zarzadzaniu Wady: jesli sie pomylilismy na
poczatku(przy ustalaniu wymagan np) to o bledzie dowiemy sie dopiero na koncu projektu, musimy dlugo czekac na produkt(np roczne projekty) trudny i zadni kontakt z klientem.
Model przyrostowy – okreslamy pewien maly zbior wymagan – wykonujemy(implement) i
pokazujemy odbiorcy a on sie wypowiada na ten temat i nam odsyla odpowiedz. W kolejnej iteracji mozemy uwzglednic jego uwagi dodajac kolejne funkcjonalonosci. UWAGI: w jednym obiegu prace wykonywane sa zgodnie z modelem kaskadowym(zaplanowac, zaprojektopwac, wykonac, przetestowac i dac klientowi – tylko dla malych kawalkow w kaskadowym dla calego projektu) Zalety: czesty kontakt z klientem, nie musimy wszystkiego wiedziec od razu(bo klient komentuje nasza prace co prowadzi do zmian) Wady: trudniej sie implementuje? Jesli zespol
niedoswiadczony.
Unified process - zaczynamy od identyfkacji wymagan potem implementujemy i w czasie implementacji dodajemy nowe wymagania.
3. czy w trakcie wytawrzania softu trzeba dazyc do niskiej czy wysokiej kohezji komponentu(kohezja – wewnetrzna spojnosc)
jesli mamy komponenty softu to wiemy ze one musza sie wymieniac ze soba danymi – potrzebna jest znajoimosc odpowiedniej architektiory ktora zapewni odpowiedni przeplyw. Powiazania miedzy komponentami maja miec niski poziom(prostota). Kohezja polega na tym aby kazdy komponent obslugiwal jedna funkcjonalnosc(aby nie byla polaczaona z innymi poniewaz wtedy
modyfikacja jednego modulu zmusza do poprawienia innych zalezych od niego). Niski poziom powiazan a wysoka kohezja!
4. pozycja konfiguracji terminy z normy
1. pozycja konfiguracji – element w porjekcie ktorym chcemy zarzadzajac konfigurracja. Sledzenie zmian w komponencie(bycie) jesli sie cos mieni trzeba mu nadac identyfikatora(nr) kto zmienil kiedy zmienil, z ktorymi modulami bedzie wspolpracowal a z ktorymi nie. Kazdy element ktorym chcemy tak zarzadzac to jest to zwane pozycja konfiguracji(caly program jest pozycja konfiguracji).
Sa one hierarchiczne. Caly glowny soft + moduly(mozna je dowolnie rozmieszczac). Kazdy element moze miec wiele wersji.
Dokumentacja wymagan, dane testowe. Pozycja konfig nie moze byc za mala
Cop jes dobra pozycja konfiguracji a co nie(co za male by bylo pozycja konfig) Use Case? Tak bo do opisu wymagan(klas) musza pasowac wymagania
zestaw testowy? Tak
plik pomocy? tak(bo przy zmianie jego wersji trzeba wiedziec do ktorego modulu pasowal) 5.
wzorzec projektowy – wywodza sie z wzrocow architektonicznych(christopher alexander) Jest to rozwiazania jakiegos problemu, ktore sie powtarza, ale za kazdym wystapieniem jest rozwiazywane w inny sposob.
Wzorce:
1. adapter – dopasowanie interfejsu do oczekiwan klienta.
2.fasada – ukrywa zlozonosc(jesli mamy duzo funkcji a klient potrzebyuje tylko kilka z nich to nie trzeba mu udostepnaiac wszystkiego tylko to co potrzebuje)
3.most – oddziela abstrakcje od implementacji w taki sposob zeby kazda z nich mogla sie zmieniac w sposob od siebie niezalezny.
4.fabryka abstrakcyjna – wzorzec ktoery dostarcza nam konkretne elementy(biblioteki) ktore sa nam w danym momencie potrzebne
6.narysuj diagram referencyjny dla kazdego z 4 wzorcow(np dla mostu) .
. .
7. na czym polega historia transakcji z anomalia powtornego czytania.
Transakcja :
1. poziom abstrakcji(ciag polecen wykonywanych na bazie danych, sa one nierozerewalne i musza spelniac 4 postulaty – 1. atomowosci 2. spojnosci 3. izolacji(transkacja nie musi znac info o innych trans) 4. trwalosci to co zapisala transakcja musi byc trwale REAL
2. jako jednostka logicznego przetwarzania ABSTRAKCYJNIE – dziala kilka transakcji w opbrebie
1 modulu. Mamy manager transakcji do zarzadzania nimi aby nie powodowaly konfliktow.
Manager ustawia w ciag dzialan poszczegolne transakcje(elementarne dzialania sa 4: zapisz, dodaj, zatwierdz, odrzuc transakcje) mozna je tak ustawic aby dzialaly dobrze badz nie(anomalie)
anomalie: 1. polega na tym: jak wykonamy ciag operacji i chcemy pozniej wrocic to sie nie da) nie da sie otdworzyc stanu bazy anomalia - nieodtwarzalnosci. Zmiana ceny w czasie dokonywania transakcji
2. kaskadowego odrzucania -
3.powtornego czytania – ze transakcja 2 razy odczytuje te sama dana ale za kazdym razem widzi rozna wartosc(bo w trakcie cos sie zmienilo) mamy cennik i bierzmye 1 pozycje i cwena jest 10, bierzemy znow i cena jest teraz 12. Moze byc mylace takie dzialanie,
4. fantomy – elementy ktore moga sie pojawic badz znikac – dotyczna operacji na zbiorach rekordow. Np sprawdz w bazie ile jest studentow(podaje 120), podaj znow(podaje 140) bo ktos zmienil adres zamieszkania i jest widoczny w systemie pod starym i nowym. Bo transakcja nowego adresu nei zostala zatwierdzona.
Manager transakcji jesli ma cos wykonac w bazie to nie zapisuje na dysku nic(od tego ma managera danych). Protokol dwufazowy w transakcji – dziala w ten sposob: gdy transakcja zapisuje badz to ustawia blokady na danych i po wykonainiu dzialania mozna zdjac. Jesli obnizmymi poziomy izolacji(zerowy, pierwszy, drugi, trzeci)zero – dopuszcza wszystko(dopuszcza do
niezatwierdzonych zmian). Zdjecie blokady nastepuje gdy manager danych mowi ze operacja zakonczyla sie powodzeniem
8. podac klasyfikacje przypadkow uzycia zaproponowana przez cockburna.
Przypadki uzycia mozna podzielic na 3 grupy:
1. fala oceanu i plywaja sobie przypadki uzycia(przypadki uzytkownika - realizuja jego cele – checmy uizyskac info o ocenach))
2. przypadki ktore sa wyzej(strategiczne) – sloneczko – sa bardzo ogolne(chcemy zarzadzac swoimi zajeciami na uczelni np . Zarzadzaj planem – ogolnie!) Nie sa konkretne
3. RYBKA – przypadki ponizej przypadkow uzytkownika – sluza wspomaganiu celow(mechanizm sluzacy do wspomagania przypadkow uzytkownika np. Zaloguj sie albo Sprawdz czy masz
zaplacaone) 9. Normy
wydanie – produkt bazowy przekazany na zewnatrz ale nie tylko. Tam gdzie pojawia sie wydanie to dla osoby zarzadzajacej jest to kamien milowy dla niej. Jest to punkt kontrolny dla tego co ma sie dziac w projekcie(np. Release softu).
Kazdy produkt bazowy jest najszczesciej powiazany z kamieniem milopwym. Produkt bazowy jest to zatwierdzona i gotowa funkcjonalnosc systemu(stawiamy punkt kontrolny by sprawdzic)
10. omowic statyczne metody test softu.
1. dynamiczne – uruchom program! Patrzymy jak dziala albo Nie uruchamiamy! I analizujemy wtedy kod.
2. statyczne - Moze byc inspekcja. Moze byc automat ktoryu bedzie badal tekst i sprawdzal czy sa kropki do wstawienia bez startu softy
czarna skrzynka
biala skrzynka
Model V testowania – jest to z jednejs trony etapy cyklu zycia softu a z drugiej strony odpowiadajace im rodzaje testow
1. analiza <----> testy akceptacyjne 2. projekt ogolny<--> integracyjne
3. projekt szczegolowy<--> pojedyncze itp
