Lista przykładowych tematów egzaminacyjnych INOP12. (bardzo brudny BRUDNOPIS) (przykładowe oznacza Ŝe mogą być takŝe inne pytania...

Transkrypt

1 Lista przykładowych tematów egzaminacyjnych INOP12. (bardzo brudny BRUDNOPIS) (przykładowe oznacza Ŝe mogą być takŝe inne pytania...) Pytania na egzamin 1. Wymień przyczyny powstania InŜynierii Oprogramowania, 2. Podaj zakres zagadnień jakimi zajmuje się InOp, 3. Podaj główny cel InOp, 4. Napisz, czym się róŝnią cele produktu od celu projektu? Oczekiwana odpowiedź: Cele PRODUKTU określają jego cechy z punktu widzenia uŝytkownika. Cele PROJEKTU stanowią wytyczne dla działalności realizatorów nie są wskazówkami dotyczącymi produktu końcowego! 5. Napisz od czego zaleŝy jakość procesu (tworzenia oprogramowania) i od czego zaleŝy jakość produktu (przedsięwzięcia programistycznego) 6. Scharakteryzuj model cyklu Ŝycia: Model kaskadowy, Model kaskadowy z iteracjami, Model kaskadowy kierowany dokumentami, Model prototypowania, Model przyrostowy. 7. Opisz czynności podejmowane w fazie strategicznej. 8. Wymień czynności wykonywane w fazie strategicznej. 9. Wymień jakie strategiczne decyzje podejmuje się w FS. 10. Wymień ograniczenia jakie naleŝy uwzględnić przy rozwaŝaniach w FS. Ograniczenia zleceniobiorcy, np: - maksymalne nakłady jakie moŝna ponieść na realizację przedsięwzięcia, - dostępny personel, - dostępne narzędzia, - ograniczenia czasowe. Ograniczenia klienta (np. finansowe, infrastruktury, zasobów ludzkich, czasu wdroŝenia, itd.). 11. Wymień czynniki jakie naleŝy uwzględniać przy harmonogramowaniu. 12. Wymień podstawowe rezultaty fazy strategicznej. 13. Przedstaw kryteria wyboru najlepszego wariantu realizacji przedsięwzięcia. 14. Przedstaw sposoby wyboru najlepszego rozwiązania/wariantu realizacji przedsięwzięcia. - Usunięcie rozwiązań zdominowanych, - Ocena rozwiązań za pomocą sumy waŝonej, 15. Opisz sposób szacowanie kosztów przedsięwzięcia programistycznego. - modele algorytmiczne, (Cocomo I, Cocomo II, etc), - ocena przez eksperta (ekspertów), (met. Delphi), - ocena przez analogię, - prawo Parkinsona, - wycena dla wygranej, - szacowanie wstępujące. 1

2 16. Opisz trzy wersje modelu i trzy kategorie projektów rozpatrywane w podstawowej wersji COCOMO. WyróŜnia się trzy wersje modelu (w zaleŝności od czynników jakie chcemy uwzględnić) podstawowa (basic) - praktycznie zaleŝność tylko od KDSI pośrednia (intermediate) szczegółowa (detailed) - uwzględniamy duŝo dodatkowych czynników WyróŜnia się 3 kategorie projektów: organic: (pl: organiczny); mały zespół o wysokim poziomie umiejętności, stabilne środowisko wytwórcze, niewielka liczba nowych algorytmów, semidetached: (pl: półoderwany); sytuacja pośrednia: zespół o zróŝnicowanych umiejętnościach, część metod, narzędzi nie jest znana, embedded: (pl: osadzone); nowa dziedzina aplikacyjna, duŝa złoŝoność, duŝy zespół realizatorów. 17. Opisz (podaj wzory i naszkicuj diagram) wyniki COCOMO 1, organic: mały zespół,, niewielka liczba nowych algorytmów, MM = 2.4 (KDSI) 1.05 (osobomiesiące) TDEV = 2.5 (MM) 0.38 (miesiące) semidetached: MM = 3.0 (KDSI) 1.12 TDEV = 2.5 (MM) 0.35 embedded: nowa dziedzina aplikacyjna, duŝy zespół realizatorów, MM = 3.6 (KDSI) 1.20 TDEV = 2.5 (MM) 0.32 i tu narysować diagram z trzema funkcjami i opisanymi osiami. 18. Zdefiniuj (co najmniej trzy) znane Ci miary pracochłonności projektu programistycznego, 19. O pisz sposoby realizacji fazy określania wymagań, Przykładowa odpowiedź (w skrócie): Podstawowym sposobem pracy jest wykonywanie wywiadów z róŝnymi osobami ze strony klienta (są to z reguły przyszli uŝytkownicy systemu) Przekształcenie wymagane od systemu oprogramowania ma postać wejść i wyjść z systemu. Powinno być określone, który zbiór wejść zostanie przetworzony na który zbiór wyjść. Nie naleŝy wskazywać jak wejścia zostaną przekształcone na wyjścia. Zostawić to do dokumentacji projektowej. 20. Zdefiniuj i podaj przykłady wymagań funkcjonalnych, 21. Zdefiniuj i podaj przykłady wymagań niefunkcjonalnych, 2

3 22. Opisz klasyfikację wymagań niefunkcjonalnych, Klasyfikacja wymagań niefunkcjonalnych Wymagania produktowe Określają zachowanie produktu, np. efektywnościowe dotyczące szybkości działania systemu i jego zapotrzebowania na pamięć, wymagania niezawodności (uŝywać miar). Wymagania organizacyjne Wynikają ze strategii i procedur w firmie- kliencie i w firmie- wytwórcy. Wymagania zewnętrzne Wynikające z czynników zewnętrznych dla systemu i procesu jego tworzenia. Np. wymagania współpracy z innymi systemami, wymagania prawne. 23. podaj miary uŝywane w specyfikowaniu wymagań niefunkcjonalnych, Przykładowa odpowiedź Miary do specyfikowania wymagań niefunkcjonalnych Właściwość Szybkość Rozmiar Łatwość uŝycia Niezawodność Solidność Przenośność Miara Liczba przetworzonych transakcji na sekundę Czas reakcji na zdarzenie wywołane przez uŝytkownika Czas odświeŝenia ekranu Kilobajty Czas szkolenia Liczba okien pomocy Średni czas bez awarii Prawdopodobieństwo niedostępności Częstość błędów Dostępność Czas uruchamiania po awarii Ułamek zdarzeń powodujących awarie Prawdopodobieństwo zniszczenia danych po awarii Procent poleceń zaleŝnych od platformy Liczba docelowych systemów 24. Wymień i opisz dokumentację firmy programistycznej, 25. Wymień i opisz dokumentację (małego i średniego) przedsięwzięcia programistycznego, 26. Wymień czynniki wpływające na jakość dokumentacji, Struktura. Poszczególne podręczniki powinny być w czytelny i zrozumiały sposób podzielone na rozdziały, podrozdziały i sekcje. Zachowanie standardów. Poszczególne podręczniki oraz fragmenty tego samego podręcznika powinny mieć spójną strukturę, formę i sposób pisania. Sposób pisania. Stosowanie formy aktywnej oraz zwracanie się bezpośrednio do czytelnika. Poprawność gramatyczna i ortograficzna. Wszelkie błędy w dokumentacji obniŝają zaufanie uŝytkownika do całego systemu. Obecnie 3

4 wiele edytorów tekstu posiada narzędzia sprawdzania poprawności językowej (głównie ortografii), które pozwalają wykryć wiele błędów. Krótkie zdania. Nie zaleca się stosowania w dokumentacji uŝytkowej długich, złoŝonych zdań, które są zdecydowanie mniej czytelne niŝ kilka krótkich zdań zawierających pojedyncze fakty. Krótkie akapity. Najlepiej zauwaŝalne są informacje umieszczone na początku i na końcu akapitu. Oszczędność słów. Tekst dokumentacji uŝytkowej powinien być przede wszystkim przejrzysty i precyzyjny. Poszczególne fakty naleŝy wyraŝać więc w jak najkrótszy sposób. Precyzyjna definicja uŝywanych terminów. W dokumentacji moŝe pojawić się wiele terminów, które nie są powszechnie znane. Pewne terminy mogą z kolei być uŝywane w ramach dokumentacji w tylko jednym z wielu znaczeń w jakich funkcjonują w języku codziennym. Terminy tego typu powinny być precyzyjnie definiowane, a ich definicje powinny być zebrane w słowniku. Powtarzanie trudnego opisu. Szczególnie waŝne informacje, których opis moŝe być trudny dla czytelnika moŝna powtarzać w róŝnych miejscach dokumentacji. Stosowanie tytułów i podtytułów sekcji, wyliczeń i wyróŝnień. Wymienione elementy oŝywiają tekst i pozwalają zwrócić uwagę czytelnika na najistotniejsze informacje. Zrozumiale odwołania do innych rozdziałów. Odwołując się do rozdziału naleŝy podać nie tylko jego numer, lecz takŝe krótki opis zawartości. 27. Wymień podstawowe zasady QA "fit for purpose" - produkt powinien spełniać oczekiwane wymagania, "right first time" - błędy powinny być wyeliminowane (produkt zdatny do uŝycia zaraz po dostarczeniu klientowi), 28. W kilku zdaniach wyjaśnij pojęcie "refactoring" w odniesieniu do software'u. (ten temat został ominięty na wykładzie - proszę doczytać). 29. Wymień dokumenty jakie powinna sprawdzać, podpisywć, etc. osoba odpowiedzialna za QA w przedsiębiorstwie produkującym oprogramowanie, (odnieś się do dokumentacji małego przedsiębiorstwa programistycznego), 30. Jakie informacje powinien zawierać nagłówek pliku headerowego? PoniŜej nie jest podana przykładowa odpowiedź ale przykładowy header: /*************************************************************** ** "metrics_data.h" ** ** Copyright 2005 AS Engineering & Research Associates, Inc. ** ** All Rights Reserved. ** ** CONTENTS: ** 4

5 ** Metrics of the wind map stored. ** ** HISTORY: ** ** Version Date Changes Author/Programmer ** ** /11/07 Original design J.Strawberry ** ** /09/10 Interface & first implementation JAM ** ***************************************************************/ 31. Naszkicuj wzorce tablic.: np. Raport postępów, Raport błędów, 32. Podaj cel fazy analizy (Jr5,1-2) 33. Opisz techniki programistyczne które zwiększają moŝliwości popełnienia błędów (Jr7.1.1). 34. Na czym polega atestowanie (validation) a na czym weryfikacja (verification)? 35. Podaj zadania osoby odpowiedzialnej za QA. 36. Wymień rodzaje testów. 37. Opisz na czym polega testowanie statystyczne (czyli pisz schemat wg którego przebiegają testy statystyczne). 38. Opisz na czym polega testowanie statyczne. 39. W jaki sposób zaleŝy niezawodność od liczby testów (podaj takŝe wzór). 40. Jakie elementy składają się na fazę instalacji (Jr10) Oczekiwana odpowiedź: - szkolenia uŝytkowników końcowych i administratorów systemu, - instalacja sprzętu i przeniesienie oprogramowania, - wypełnienie koniecznych baz danych, - nadzorowanie korzystania z systemu, często równoległe z tradycyjnym sposobem pracy, - usuwanie błędów w oprogramowaniu i dokumentacji uŝytkowej, - przekazanie systemu klientowi. 41. Wymień (i opisz) trzy główne klasy modyfikacji wprowadzanych w oprogramowanie (ten temat został ominięty na wykładzie - proszę doczytać u A. Jaszkiewicza) 42. Wymień czynniki wpływające na redukcję kosztów konserwacji. 43. Wymień stanowiska w firmie programistycznej. 44. Zaproponuj przypadki uŝycia dla zadanego projektu. 45. Opisz konkretny przypadek uŝycia dla zadanego projektu. 46. Jak "definiowana" jest klasa w UML i jaka notacja jest uŝywana do jej przedstawiania na diagramie? 47. Opisz notację oznaczania dostępu do klasy (UML) i jakieś przyjemne niespodzianki, aby PT. Studenci mogli się wykazać swoim bardzo dobrym przygotowaniem. Osoba egzaminowana która poprawnie potrafi odpowiedzieć na powyŝsze pytania (od 1 do 48) ma 99% szans na ocenę dst. 5