\documentclass[11pt]{article}
\usepackage[utf8]{inputenc}
\usepackage[magyar]{babel}
\usepackage{amsmath}
\usepackage{multirow}
\usepackage{graphicx}
\usepackage{caption}
\usepackage{subcaption}
\usepackage{filecontents}
\usepackage{hyperref}
\usepackage[anythingbreaks]{breakurl}
\usepackage[hyphens]{url}
\usepackage{anysize}
\marginsize{2.5cm}{2.5cm}{2.5cm}{2.5cm}
\usepackage[titletoc]{appendix}
\newcommand\TODO[1]{\textcolor{red}{#1}}
\usepackage{listings}
\usepackage{color}
\usepackage[style = ieee, backend=bibtex,bibencoding=ascii,sorting=none]{biblatex}
\bibliography{linkek.bib}
\definecolor{mygray}{rgb}{0.4,0.4,0.4}
\definecolor{mygreen}{rgb}{0,0.8,0.6}
\definecolor{myorange}{rgb}{1.0,0.4,0}

\lstset{
basicstyle=\footnotesize\sffamily\color{black},
commentstyle=\color{mygray},
frame=single,
numbers=left,
numbersep=5pt,
numberstyle=\tiny\color{mygray},
keywordstyle=\color{mygreen},
showspaces=false,
showstringspaces=false,
stringstyle=\color{myorange},
tabsize=2
}
\title{\Huge Szoftvertechológia alapjai
\\
\Large Vizsga kérdések}

\author{Dallos Ádám, Majnár László}
\date{2016. május 21.}

\begin{document}
\maketitle
\newpage

%1

\section{Mi a szoftver? Sorolja fel azokat a termékeket, amelyek a szoftverhez tartoznak.}
\textbf{A szoftver:}
 Számítógép-programok és a hozzájuk tartozó dokumentációk összessége (Somerville def.) A gyakorlatban hozzátartoznak a szakterületi ismeretek és azok dokumentációi is, amelyek alapján a szoftvert kifejlesztették.
 \\
 \textbf{A szoftverhez tartozó termék:}
 A programok és a hozzá kapcsolódó dokumentációk. (Karbantartás??)
 
 %2
 
\section{Mi a szoftverfolyamat? Sorolja fel a szoftverfolyamat főbb tevékenységeit.
}
\textbf{A szoftverfolyamat:}
A szoftver termék előállítására irányuló tevékenységek sora.
\\
\textbf{Főbb tevékenységek:}
\begin{enumerate}
 \item \textbf{Szoftverspecifikáció:} 
 A szoftver feladatainak és a megszorításoknak specifikációja.
\item \textbf{Szoftverfejlesztés:} 
A szoftver rendszer tervezése és elkészítése (programkészítés, tesztelés).
\item \textbf{Szoftvervalidáció:} 
Annak bizonyítása, hogy az előkészített rendszer a felhasználó elvárásainak megfelelően működik.
\item \textbf{Szoftverevolúció:} A szoftver karbantartása és továbbfejlesztése a változó igényeknek megfelelően.
\end{enumerate}

%3

\section{Sorolja fel a szoftverfolyamat általános modelljeit és jellemezze azokat néhány szóban.}
A szoftverfolyamat modellje a folyamat absztrakt reprezentációja.
\begin{itemize}
 \item \textbf{Vízesés modell: } 
 Az alapveto tevékenységek önálló fázisok a folyamat során.
 \item \textbf{Evolúciós fejlesztés:} 
A specifikáció, a fejlesztés és a validáció összefonódik. Ez az alapja a manapság elterjedt alkalmazott agilis fejlesztési módszereknek.
  \item \textbf{Formális transzformációk:} 
  A követelmények matematikai modelljéből, formális transzformációval állítja elő a szoftvert. Ez a módszer az őse a mai modellközpontú fejlesztésnek.
  \item \textbf{Integráció újrafelhasználható komponensekből:} 
 A rendszert meglévő komponensek integrálásával állítja elő.
\end{itemize}
\newpage
%4

\section{Miért van szükség arra, hogy a szoftvertervezők számára etikai kódexet állítsanak össze? Sorolja fel a fontosabb etikai előírásokat.}
\textbf{Szükségesség:}
\begin{itemize}
    \item \textbf{Bizalmasság:} A szoftvertervezőnek tisztelnie kell a munkaadója, vagy megrendelője bizalmát, attól függetlenül,
hogy aláírtak-e titoktartási nyilatkozatot. 
\item \textbf{Hozzáértés:} A tervező nem vállalhat el olyan munkát, amely meghaladja képességeit, nem tűntetheti fel hamis
színben tudását, képességeit. 
\item \textbf{Szellemi jogok:} Tiszteletben kell tartania a szellemi tulajdonjogokat. 
\item \textbf{Számítógépes visszaélések:} A tervező nem használhatja fel ismereteit arra, hogy másoknak közvetve, vagy közvetlenül kárt
okozzon. 

\end{itemize}
\textbf{Előírások:}
\begin{itemize}
    \item A helyi, nemzeti és nemzetközi szabályok ismerete és betartása.
    \item Etikus és bizalmat keltő viselkedés, ami több, mint pusztán a törvények betartása.
    \item A megbízó titkainak megtartása.
    \item A szellemi tulajdonjogok tiszteletben tartása.
    \item A számítógépes visszaélések megakadályozása, ill. elkerülése.
\end{itemize}

%5

\section{Melyek az eredendő rendszertulajdonságok? Hogyan csoportosítjuk őket?}
A rendszer több, mint komponenseinek halmaza. Alapvető tulajdonságai többnyire nem származtathatóak a komponensek tulajdonságaiból.
A rendszer eredendő tulajdonságai a komponensek közti összetett kapcsolatok, kölcsönhatások következményei. Ezért az eredendő tulajdonságok csak akkor állapíthatók meg és válnak mérhetővé, mikor  megtörtént a komponensek integrációja.\\
\textbf{Eredendő rendszertulajdonságok:}
\begin{itemize}
 \item \textbf{A rendszer súlya:} Ez kiszámítható a komponensek súlyából.

 \item \textbf{A rendszer megbízhatósága:} Nemcsak a rendszer komponenseitől, hanem azok kapcsolatától is függ.
 \item  \textbf{A rendszer használhatósága:} Összetett tulajdonság, amely nemcsak a hardver és szoftver komponensektől függ, hanem a környezettől és a működtető, sőt a felhasználó emberektől is.
\end{itemize}
\textbf{Tulajdonságok típusai:}
\begin{itemize}
    \item \textbf{Funkcionális tulajdonságok:} A funkcionális tulajdonságok akkor figyelhetők meg, ha a rendszer minden része együttműködik egy cél elérése érdekében. (pl. kerékpár!)
    \item \textbf{Nem funkcionális tulajdonságok:}
    \begin{itemize}
        \item Olyan rendszertulajdonságok, amelyeket a rendszer működési környezete is befolyásol. Ezek gyakran kritikusak a számítógép alapú rendszerek működése szempontjából, ezért ezeket már a tervezéskor definiálni kell.
        \item Ilyenek lehetnek a megbízhatóság, a teljesítmény, a biztonságosság, vagy a védelem.
    \end{itemize}
\end{itemize}

%6

\section{Mi a különbség a funkcionális és a nem-funkcionális rendszertulajdonságok között?}
A \textbf{funkcionális tulajdonságok} akkor figyelhetők meg, ha a rendszer minden része együttműködik egy cél érdekében. \\
A \textbf{nem funkcionális tulajdonságok} pedig olyan rendszertulajdonságok, amelyeket a rendszer működési környezete is befolyásol. Pl.: teljesítmény, megbízhatóság, biztonság, védelem.

%7

\section{Melyek azok a tevékenységek, amelyek közösek minden szoftverfolyamatban?}
\begin{itemize}
 \item \textbf{Szoftverspecifikáció:}
 A szoftver feladatainak és a megszorításoknak specifikációja.
\item \textbf{Szoftverfejlesztés:}
A szoftver rendszer tervezése és elkészítése (programkészítés, tesztelés).
\item \textbf{Szoftvervalidáció:}
Annak bizonyítása, hogy az előkészített rendszer a felhasználó elvárásainak megfelelően működik.
\item \textbf{Szoftverevolúció:} A szoftver karbantartása és továbbfejlesztése a változó igényeknek megfelelően.
\end{itemize}

%8

\section{Vázolja fel a vízesés modellt, sorolja fel a modell előnyeit és hátrányait!}
\begin{center}
\includegraphics[scale=0.75]{vizeses}
\end{center}
\textbf{A vízesés modell előnyei:}
\begin{itemize}
    \item Jól áttekinthető és követhető fejlesztési projekt folyamatot eredményez.
    \item A folyamat termékei szerződésekkel könnyen lefedhetők. (specifikációs és tervezési dokumentumok, program(ok), stb.)
    \item A tevékenységek jól, és pontosan tervezhetők.
\end{itemize}
\textbf{A vízesés modell hátrányai:}
\begin{itemize}
    \item Egymástól elkülönült fázisokra osztja a projektet (költséges egy korábbi fázishoz visszatérni pl. specifikációs, vagy tervezési hiba esetén).
    \item Csak a projekt végén, az átadáskor (a működtetés első lépésekor) derülnek ki a specifikációs hibák.
    \item Nem képes rugalmasan alkalmazkodni a felhasználói igények változásaihoz.
    \item Csak a követelmények pontos ismeretében alkalmazható.
\end{itemize}
%9

\section{Mi a formális rendszerfejlesztés? Milyen előnyei és hátrányai vannak?}
A vízesés modellhez hasonló, de a fejlesztés formális matematikai eszközökkel állítja elő a futtatható programot a rendszerspecifikáció matematikai modelljéből, több transzformációs lépésen keresztül.\\
Minden transzformáció során, lépésenként kell végrehajtani a tesztelést.
\begin{center}
\includegraphics[scale=0.8]{funkcionalis}
\end{center}
\textbf{Formális transzformációk:}
\begin{center}
\includegraphics[scale=0.8]{formalis_transzformaciok}
\end{center}
\textbf{Formális rendszerfejlesztés előnyei:}
\begin{itemize}
    \item Kritikus rendszerek esetén, ahol kulcskérdés a biztonságosság, megbízhatóság, vagy védelem.
    \item A transzformáció és a bizonyítás részben automatizálható.
\end{itemize}
\textbf{Formális rendszerfejlesztés hátrányai:}
\begin{itemize}
    \item Speciális szakértelmet igényel.
    \item Egy rendszer kölcsönhatásait (pl. felhasználói interfész) nehéz formálisan specifikálni.
    \item Komplex, nagy rendszereknél ez a módszer sem eredményez jobb minőséget, vagy költség-megtakarítást.
\end{itemize}

%10

\section{Mi az evolúciós fejlesztési modell lényege? Miért nehéz karbantartani az így fejlesztett programokat?}
\textbf{Az alapgondolat:}
Ki kell dolgozni egy kezdeti implementációt, amelyet a felhasználó véleményezhet, és azt kell finomítani az elfogadásig. A specifikáció a fejlesztés és validáció párhuzamosan folytatható tevékenységek.\\
\textbf{Feltáró fejlesztés:}
A követelmények feltárása lépésenként, a megrendelővel együttműködve történik, folyamatosan kiegészítve a rendszert az új funkciókkal, részekkel.(Ilyen az Agile módszerek többsége.)\\
\textbf{Eldobható prototípus:}
„Deszkamodellek” készítése és átadása az ügyfélnek, a követelmények pontosabb feltárása érdekében.\\
\textbf{Miért nehéz karbantartani?}
Azért nehéz karbantartani, mert minden művelet egyszerre folyik, és nincs részletes specifikáció.

%11

\section{Mi az újrafelhasználás orientált fejlesztés lényege? Vázolja fel a folyamatot! Milyen esetekben alkalmazható?}
Már létező, újrafelhasználható szoftver-komponensek egységes szerkezetbe való integrálása (komponens alapú rendszerfejlesztés). Polcról levehető termékeket használ fel a fejlesztés során. Gyakran beépül a korábban ismertetett folyamatokba. Az elérhető  komponenseket megtalálni, azokat integrálni nem egyszerű.\\
\textbf{A folyamat modell:}
\begin{center}
\includegraphics[scale=0.8]{ujrafelhasznalas}
\end{center}
\textbf{Milyen esetekben alkalmazható?}\\
Minőségjavítása, költségek és a fejlesztési idő csökkentésének érdekében használható.
Csak akkor használjuk, ha tudjuk, hogy az adott komponens megfelelően működik.
Nagy rendszerek építésekor gyakran használt stratégia a COTS termékek integrálása. Különösen a gyors fejlesztést kívánó eCommerce, eBusiness rendszerek körében. A fejlesztési idő nagyságrendekkel csökkenthető.

%12

\section{Mi a különbség a CASE eszközök, -eszközkészletek és -környezetek között?}
\begin{itemize}
    \item \textbf{Eszközök (tools):}
    Az egyes folyamatlépéseket támogatják, mint a terv konziszetciájának ellenőrzése, program fordítás, teszteredmények összehasonlítása, stb.
    \item \textbf{Eszközkészletek (workbench):}
    A szoftverfolyamat egyes fázisait támogatják, mint pl. specifikáció, vagy tervezés. Általában több, egymással együttműködő eszközből állnak.
    \item \textbf{Környezetek (environments):}
    A szoftverfolyamat több fontos, vagy valamennyi részét támogatják. Legtöbbször több, integrált eszközkészletből állnak.
\end{itemize}

%13

\section{Miért célszerű projektszervezetben végezni a szoftverfejlesztést?}
Azért célszerű, hogy a szoftver a tervezett ütemezés szerint, határidőre, a követelményeknek megfelelően készüljön el. Továbbá a projekt menedzselésére azért van szükség, mert a szoftverfejlesztés mindig kötött pénzügyi és megszabott időkeretek között folyik, amelyeket a megrendelő, vagy a fejlesztő szervezet jelöl ki.

%14

\section{Miért és milyen gondot okoz a szoftverprojekt vezetője számára, hogy a szoftver nem látható, megfogható? Milyen módon lehet ezt a gondot csökkenteni?}
%%%%Ez nem biztos hogy jó
Mivel a szoftver nem kézzel fogható, továbbá a szoftverfejlesztés folyamata sincs szabványosítva, így sokkal nehezebb meghatározni, hogy mennyi időbe telik a fejlesztés, mennyi ember kellhet hozzá, mekkora ennek a költsége.
Továbbá a megrendelő számára nem nagyon tud a projekt elkészültéig kézzel fogható programot mutatni, amely igen csak megnehezíti a dolgokat.
\begin{itemize}
    \item A szoftverfejlesztési projekt gyakran egyedi, amely nem általánosítható folyamat.
    \item A projekt tervezést alfeladatokra kell bontani, és ütemezni. 
    \item Némely feladat futhat párhuzamosan is, ha a feladatok nem függenek egymástól.
\end{itemize}

%15

\section{Milyen típusú terveket kell készíteni egy projekt tervezésekor?}
\begin{itemize}
    \item \textbf{Munkaterv, ütemezés:}
    Az elvégzendo feladatok, ütemezésük és összefüggéseik tervezése.
    \item \textbf{Minőségi terv:} Meghatározza a projektben használandó minőségbiztosítási eljárásokat és szabványokat.
     \item \textbf{Validációs terv:} Meghatározza a rendszer validációja során használandó módszereket, erőforrásokat, ütemezést.
      \item \textbf{Konfiguráció-kezelési terv:}
      Leírja a konfiguráció-kezelés eljárásait és struktúráját.
       \item \textbf{Karbantartási terv:}
       A karbantartás követelményeinek, költségeinek terve.
        \item \textbf{Munkaerő-fejlesztési terv:}
        Terv a projekten dolgozó csapat szaktudásának, tapasztalatainak fejlesztésére.
\end{itemize}

%16

\section{Vázolja fel egy vízesés modell szerint végzendő fejlesztési projekt ütemezését oszlopdiagram formában!}
\begin{center}
\includegraphics[scale=0.8]{gantviz1}
\end{center}
\begin{center}
\includegraphics[scale=0.55]{gantviz2}
\end{center}

%17

\section{Kísérelje meg felvázolni egy evolúciós folyamat szerint végzendő fejlesztési projektterv oszlopdiagramját!}
\begin{center}
\includegraphics[scale=0.68]{evo}
\end{center}

%18

\section{Miért iteratív tevékenység a szoftverprojekt tervezése?}
A szoftverprojekt tervezése egy folyamatos tevékenység. Amely a koncepció kidolgozásától a rendszer átadásáig tart. Az előrehaladást folyamatosan követni kell, projekttervet rendszeresen felül kell vizsgálni és át kell dolgozni a változó állapotnak megfelelően (ezért iteratív).

%19

\section{Milyen kockázatokat különböztethetünk meg egy szoftverfejlesztési projektben? Sorolja fel és jellemezze őket!}
A kockázatkezelés a lehetséges kockázati tényezők azonosítását és a projektre gyakorolt hatásuk
minimalizálására vonatkozó tervek készítését jelenti.
\begin{itemize}
    \item \textbf{Projekt kockázat:}
    A projekt ütemtervét, vagy az erőforrásokat veszélyezteti.
       \item \textbf{Termék kockázat:}
       A szoftver minőségét, vagy teljesítményét veszélyezteti.
          \item \textbf{Üzleti kockázat:}
          A szoftver beszerzését, értékesítését veszélyezteti.
             \item \textbf{Szervezeti kockázat:}
             A fejlesztést végző szervezetet veszélyezteti.
\end{itemize}

%20

\section{Sorolja fel a fontosabb szerepeket egy projektszervezetben! Ismertesse néhány szóban az egyes szerepek tevékenységeit!}
\begin{itemize}
    \item \textbf{Projektvezető (szakmai - adminisztratív vezető):}\\
    A projektvezető felelős a projektcélok megvalósulásáért. Szakmai és adminisztratív vezető, aki felelos a projekt sikeres, határidőre való befejezéséért, a kezdetben meghatározott keretek között.
    \item \textbf{Rendszertervező:}\\
    A rendszertervezés a számítógép alapú rendszerek tervezésével foglalkozik (hardver, szoftver, folyamatok) a szoftvertervezés ennek egy része.
    \item \textbf{Vezető programozó:}\\
    A programozási folyamat előrehaladásáért felelős személy. Körülötte helyezkednek el az alábbiak.
    \item \textbf{Tartalék programozó:}\\ Vezető programozó mellett lévő gyakorlott programozó.
    \item \textbf{Könyvtáros (adminisztrátor):}\\
    A fejlesztési projekt dokumentációinak és termékeinek (verziók) elkészítéséért (készíttetéséért), rendben tartásáért felelős.
    \item \textbf{Tesztelő:}\\
   A modellek és termékek tesztelését, verifikálását végzi.
    \item \textbf{Minőségfelelős:}\\
    A minőségbiztosítási szabályok betartásáért felel a teljes szoftverfolyamat során.
    \item \textbf{Dokumentátor:}
    \item \textbf{Operációs rendszer szakértő:}\\
    Az operációs rendszer kiválasztásáért felelős személy.
    \item \textbf{Adatbázis szakértő:}
    \item \textbf{Szakterületi specialista:}\\
   Az alkalmazási terület ismerője, aki már részt vett hasonló rendszer kidolgozásában.
    \item \textbf{CASE eszköz szakértő:}\\
    A fejlesztés során felhasználható CASE eszközök kiválasztásáért felelős személy.
\end{itemize}
\newpage

%21

\section{Mi a feladata a megvalósíthatósági tanulmánynak. Hol van a helye a szoftverfolyamatban?}
\textbf{Feladata:}
Megalapozni azt a döntést, hogy érdemes-e a tervezett rendszert megvalósítani.\\
\textbf{Az alábbi kérdésekre ad választ:}
\begin{itemize}
    \item Más, hasonló szervezeteknél milyen megoldásokat alkalmaztak hasonló feladatokra.
    \item Mennyiben támogatja a rendszer a megrendelő általános célkitűzéseit.

    \item Megvalósítható-e a rendszer a tervezett költségen belül, az adott technológiával, a kívánt határidőre.

    \item Integrálható-e a rendszer más, már meglévő rendszerekkel.
\end{itemize}
\textbf{Helye a szoftverfolyamatban:}
A megvalósíthatósági tanulmány helye a \textbf{követelménytervezés folyamatában} van a szoftverfolyamat során.

%22

\section{Sorolja fel a legfontosabb szempontokat, amelyeket egy tervezőnek a felhasználói követelmények specifikálásakor ügyelnie kell!}
\begin{itemize}
    \item A felhasználói követelményeket úgy kell megfogalmazni, hogy az informatikában járatlan felhasználó is megértse.
    \item Ezért itt nem célszerű modelleket alkalmazni, hanem természetes nyelven, táblázatokkal és diagrammokkal kell a felhasználói követelményeket érthetővé és egyértelművé tenni.
    \item A természetes nyelv alkalmazásának nehézségei:
     \begin{itemize}
         \item Az egyértelműség és pontosság hiánya
         \item A követelmények keveredése
         \item A követelmények ötvöződése
     \end{itemize}
    \item Dolgozzunk ki egységes formátumot az összes követelmény leírására.
    \item Használjuk a nyelvet következetesen, pl. a szükséges követelményeket a „kell”, a kívánatos követelményeket pedig a „javallott” szóval jelölhetjük.
    \item Készítsünk glosszáriumot a szövegben használt fogalmak és rövidítések magyarázatára.
    \item A fontos részeket vizuálisan is emeljük ki a szövegből.
    \item Kerüljük a számítógépes zsargon használatát.
\end{itemize}

%23

\section{Milyen veszélyei vannak a természetes nyelv használatának a követelmények specifikálásakor? Milyen módon lehet ezeket csökkenteni?}
\begin{itemize}
    \item \textbf{Félreérthetőség:}
    A szöveg írója és olvasója egy adott kifejezésen más fogalmat ért, vagy azonos fogalmakat eltérő módon értelmez.
    \item \textbf{Félreérthetőség csökkentése:}
    Egy adott fogalom, definíció minél pontosabb, érthetőbb leírása az író által. Akár példák segítségével való megfogalmazás.
    \item \textbf{Túlzott rugalmasság:}
    Ugyanaz a követelmény sokféle módon írható le.
    \item \textbf{A modularitás hiánya:}
    A természetes nyelvben nincs egyértelmű lehetőség az összefüggések jelölésére. Így egy követelmény megváltozásakor az összes követelményt át kell vizsgálni, hogy a kapcsolódó követelményeket megtaláljuk.
    \item \textbf{Strukturált nyelvű specifikáció alkalmazása:}
    \begin{itemize}
        \item A természetes nyelv szabályozott, strukturált alkalmazása a követelmények leírására. 
        \item Egyértelműbbé teszi a követelmények specifikációját, de közben megtartja a természetes nyelv rugalmasságát.
        \item A struktúrát űrlapok vagy sablonok alkalmazásával támogatják. Kötelező információk feltüntetésével az űrlapon.
    \end{itemize}
\end{itemize}

%24

\section{Egy nagy rendszer fejlesztése során kiknek kell részt venniük a felhasználói követelmények verifikálásában? Miért?}

\begin{center}
\includegraphics[scale=0.75]{resztvevok}
\end{center}

%25

\section{Sorolja fel a rendszermodellek típusait és jellemezze azokat egy mondatban!}
\begin{itemize}
    \item \textbf{Adatfeldolgozási modell:}
    Adatfolyam diagramok, az adatok feldolgozását mutatják a rendszeren belül.

    \item \textbf{Kompozíciós modell:}
    Egyed-kapcsolat diagramok. Bemutatják, hogyan épülnek fel az egyedek más egyedekből.

    \item \textbf{Architekturális modell:} Az alrendszereket mutatják be, amelyekből a rendszer felépül.

    \item \textbf{Osztálymodell:} Objektum osztály/öröklődési diagramok, az egyedek közös tulajdonságait ábrázolják.

    \item \textbf{Inger-válasz modell:} Állapotátmenet diagramok, a rendszer belső és külső eseményekre adott reakcióit írják le.

\end{itemize}

%26

\section{Melyek a legfontosabb különbségek a felhasználói és a rendszerkövetelmények specifikálása között? Kiknek szólnak az egyes specifikációk?}
\textbf{Felhasználói követelmények:}
A rendszer szolgáltatásainak közérthető leírása, diagrammokkal, táblázatokkal, ábrákkal. Itt nem célszerű modelleket alkalmazni, az egyértelműség érdekében.\\
\textbf{Rendszerkövetelmények:}
\begin{itemize}
    \item Strukturált dokumentum a rendszer szolgáltatásainak részletes leírásával (funkcionális specifikáció).Ez a szerződés alapja.
    \item A rendszerkövetelmények a felhasználói követelmények részletesebb és rendezett leírását adják.
    \item A rendszertervezés alapjául szolgálnak, tartalmazhatják a rendszer modelljeit.
    \item A rendszerkövetelmények leírják, hogy a rendszernek mit kell elvégeznie, majd a tervek határozzák meg, hogy hogyan tegye.

\end{itemize}
\textbf{Kinek a számára készülnek az egyes dokumentumok?}
\begin{itemize}
    \item \textbf{Felhasználói követelmények specifikációja:}\\ Megrendelő vezetőségének, a rendszer végfelhasználóinak, rendszertervezőknek és a szerződéskötőknek.
%\begin{itemize}
 %    \item A megrendelő vezetése
  %   \item A rendszer végfelhasználói 
   %  \item Rendszertervezők
    % \item Szerződéskötők
%\end{itemize}
    \item \textbf{Rendszer követelmények specifikációja:}\\ A rendszer végfelhasználóinak, a megrendelő középvezetőinek, a rendszertervezőknek és szoftverfejlesztőknek.
%\begin{itemize}
 %   \item A rendszer végfelhasználói
  %  \item A megrendelő középvezetői
   % \item Rendszertervezők
    %\item Szoftverfejlesztők
%\end{itemize}
    \item \textbf{Szoftver specifikáció:}\\A rendszertrevezőknek, szoftverfejlesztőknek, tesztelőknek és karbantartóknak.
%\begin{itemize}
 %   \item Rendszertervezők
  %  \item Szoftverfejlesztők
   % \item Tesztelők
   % \item Karbantartók
%\end{itemize}
\end{itemize}

%27

\section{Melyek a prototípuskészítés céljai? Milyen prototípusok léteznek, melyik milyen célból készül?}
\textbf{Céljai:}
\begin{itemize}
    \item A prototípus elsődleges célja az, hogy segítse a felhasználókat a rendszerkövetelmények megértésében.
    \item A követelménytervezés része, a követelmények feltárásának és validációjának eszköze.
    \item A szoftverrendszer kezdeti verziója, amely alkalmas a rendszer koncepciójának bemutatására és kipróbálására.
    \item A prototípus csökkenti a követelményekkel kapcsolatos kockázatokat. 
\end{itemize}
\textbf{Prototípusok típusai:}
\begin{itemize}
    \item \textbf{Evolúciós prototípus:}
    Célja egy működő rendszer átadása a megrendelőnek. A legfontosabb követelmények implementálásával egyszerű rendszer készül, amelyet újabb
követelmények feltárásával fokozatosan egészítenek ki új funkciókkal. 
     \item \textbf{Eldobható prototípus:}
     Célja a követelményspecifikációból fakadó kockázat csökkentése. A prototípust egy kezdeti specifikáció alapján készítik, validálásra átadják a felhasználónak, majd eldobják.
\end{itemize}

%28

\section{Mi a különbség az evolúciós és az eldobható prototípus között? Melyiket mikor érdemes alkalmazni?}
\begin{itemize}
    \item \textbf{Evolúciós prototípus:}
    Célja egy működő rendszer átadása a megrendelőnek. A legfontosabb követelmények implementálásával egyszerű rendszer készül, amelyet újabb
követelmények feltárásával fokozatosan egészítenek ki új funkciókkal. 
     \item \textbf{Eldobható prototípus:}
     Célja a követelményspecifikációból fakadó kockázat csökkentése. A prototípust egy kezdeti specifikáció alapján készítik, validálásra átadják a felhasználónak, majd eldobják.\\
     Az eldobható prototípus nem tekinthető végleges rendszernek, mert:
    \begin{itemize}
                \item A kivételek, hibák kezelése általában hiányzik.
                \item  Több rendszertulajdonság kimaradhat a prototípusból.
                \item  Nem készül specifikáció a hosszú távú karbantartásra.
                \item A prototípus még nem a megfelelő struktúra szerint épül.
            \end{itemize}
\end{itemize}

\textbf{Alkalmazási területek:}
\begin{itemize}
    \item \textbf{Evolúciós prototípus:}
    \\Weblap fejlesztésben és e-business alkalmazásokban használják. 
     \item \textbf{Eldobható prototípus:}\\
     A követelmények validálása: a prototípus felfedheti a félreértéseket, hibákat és hiányosságokat a követelményekben
\end{itemize}

%29

\section{Mit jelent az adatbázis-programozás? Milyen rendszerek fejlesztésére alkalmas?}
\begin{itemize}
    \item Az evolúciós fejlesztés az adatbázison alapuló üzleti alkalmazások területén általánosan alkalmazott technika.
    \item A kereskedelmi adatbázis-kezelő rendszerek olyan  4GL fejlesztő eszközöket tartalmaznak, amelyek támogatják a lekérdezést/adatkezelést (SQL), táblázatkezelést, jelentés generálást, felhasználói felületek tervezését, stb.
    \item Az adatfeldolgozási alkalmazásokban sok közös feladat van: adatbázis manipulációk (keresés, frissítés, rendezés, stb.), egyszerű műveletek, űrlapkezelés, stb. Egy 4GL-ben ezeket általánosítják.
    \item Gyakran integrálhatók CASE eszközökkel is. Ezek generálhatnak SQL-t, vagy alacsonyabb szintu kódot. 
\end{itemize}
Adatbázison alapuló rendszerek fejlesztésére alkalmas. (??)

% ÁDÁM RÉSZE :)
%30

\section{Melyek a prototípus készítésének előnyei? Ismertese a prototípuskészítő technikákat! Melyiket milyen esetben célszerű alkalmazni?}
\textbf{Prototípuskészítés előnyei:}
\begin{itemize}
    \item Segít felismerni a szoftver felhasználója és készítője
    közti félreértéseket.
    \item Kiderülhet, hogy hiányzik valamely szolgáltatás, vagy ellentmondások vannak a szolgáltatások között.
    \item A szoftverfolyamat elején már egy – legalábbis részben, modellként - működő rendszer áll rendelkezésre.
    \item A prototípus felhasználható a rendszer-specifikáció alapjaként.
    \item Támogathatja a felhasználók képzését és a rendszertesztet is.
    \end{itemize}
\textbf{Prototípuskészítő technikák:}
    \begin{itemize}
    \item Evolúciós prototípus készítése:
    \begin{itemize}
        \item Célja egy működő rendszer átadása a megrendelőnek (esetleg korlátozott funkcionalitással)
        \item A legfontosabb követelmények implementálásával egyszerű
        rendszer készül, amelyet újabb követelmények feltárásával
        fokozatosan egészítenek ki új funkciókkal.
        \item  Az AGILIS fejlesztés alapvető módszere.
        \item Weblap fejlesztésben és e-business alkalmazásokban
        használják.
        \item  Olyan rendszereknél célszerű alkalmazni, ahol nem
        készíthető el előre a végleges specifikáció. Ilyenek
        általában az intenzív felhasználói interfész-használatot
        igénylő rendszerek.
        \item Nincs részletes rendszerspecifikáció, sokszor a
        részletes követelménydokumentum is hiányzik.
        \item A felhasználó már a rendszer fejlesztése közben
        jelezheti, hogy milyen irányban kívánja folytatni a
        fejlesztést.
        \item A fejlesztéshez gyors, iterálható fejlesztő eszközökre és módszerekre van szükség.
        \item Mivel nem készül követelményspecifikáció, a validáció
        is csak a rendszer bemutatásával történhet.
        \item  A specifikáció, a tervezés és az implementáció
        átlapolható.
        \item  A rendszer inkrementumok sorozataként fejlődik, és
        kerül a felhasználóhoz, vagyis a felhasználó kulcsfigurái minden inkrementum tervezésében és értékelésében részt vesznek.
        \item  Gyors fejlesztő eszközök és technikák alkalmazhatók (CASE eszközök, 4GL, folyamatmodellező nyelvek: BPML-Business Process Modeling Language).
        \item A felhasználói felületek GUI fejlesztő eszközökkel
        készíthetők.
    \end{itemize}
    \item Eldobható prototípus készítése:
        \begin{itemize}
        \item  Célja a követelményspecifikációból fakadó
        kockázat csökkentése.
        \item  A prototípust egy kezdeti specifikáció alapján készítik, validálásra átadják a felhasználónak,majd eldobják. 
        \item A követelményspecifikáció elkészülte után nem használható fel.
        \item  Az eldobható prototípus nem tekinthető végleges rendszernek, mert:
            \begin{itemize}
                \item A kivételek, hibák kezelése általában hiányzik.
                \item  Több rendszertulajdonság kimaradhat a prototípusból.
                \item  Nem készül specifikáció a hosszú távú karbantartásra.
                \item A prototípus még nem a megfelelő struktúra szerint épül.
            \end{itemize}
        \end{itemize}
    \end{itemize}
    
%31

\section{Mit tenne, ha egy eldobható prototípust a megrendelő meg akarna vásárolni? Milyen érveket hozna fel álláspontja indoklására?}
    
     Az eldobható prototípus nem tekinthető végleges rendszernek, mert:
        \begin{itemize}
            \item A kivételek, hibák kezelése általában hiányzik.
            \item  Több rendszertulajdonság kimaradhat a prototípusból.
            \item  Nem készül specifikáció a hosszú távú karbantartásra.
            \item A prototípus még nem a megfelelő struktúra szerint épül.
        \end{itemize}
    A vezetok gyakran nyomást gyakorolnak a fejlesztőkre, hogy egy működő eldobható prototípust végleges rendszerként adjanak át. Ez nagyon veszélyes, mert:
    \begin{itemize}
        \item  Az eldobható prototípus nem alakítható úgy, hogy a nem-funkcionális követelményeknek (teljesítmény, megbízhatóság, skálázhatóság, stb.) eleget tegyen.
        \item  A prototípus rendszerint dokumentálatlan marad, mert a cél a gyors elkészítés és bemutatás.
        \item A változtatások miatt a rendszer struktúrája általában romlik a fejlesztés során.
        \item A prototípus készítésekor az általános szervezeti szabványokat nem tartják be (minőségbiztosítás, technológiai fegyelem, projekt dokumentálás)
    \end{itemize}
    
%32

\section{Ismertesse a formális specifikáció helyét és jelentőségét a szoftverfolyamatban!}
    \textbf{Formális specifikáció:} A formális specifikáció egy matematikai jelölésrendszert alkalmaz, pontosan specifikált szótárral, szintaxissal és szemantikával. A specifikálás és a tervezés nagymértékben összefonódik egymással. Az architektúra-tervezés adhatja az alapot egy specifikáció struktúrájához. A szoftverspecifikáció folyamatának előrehaladásával az ügyfél befolyása csökken, a vállalkozó befolyása növekszik.
    \begin{center}
    \includegraphics[scale = 0.8]{szofttech_form_spec}
    \end{center}
    \textbf{Formális specifikációs technikák:}
    \begin{itemize}
        \item \textbf{Algebrai megközelítés:} A rendszert műveletei és azok kapcsolatai alapján írja le.
        \item \textbf{Modell alapú megközelítés:} A rendszert állapotmodellel specifikálja, amely halmazokból és sorozatokból álló matematikai konstrukciókat tartalmaz, a műveleteket pedig aszerint definiálja, ahogy azok a rendszer állapotát módosítják.
    \end{itemize}
      \textbf{A formális specifikáció alkalmazása:}
    \begin{itemize}
         \item A formális specifikáció a szoftverfejlesztés kezdeti szakaszában kíván nagyobb erőfeszítéseket.
         \item  A követelmények alaposabb és részletesebb elemzése azzal jár, hogy kevesebb lesz a hiba a követelményspecifikációban.
         \item  A következetlenségek és a hiányosságok felfedhetők és kijavíthatók a formális modellekkel.
         \item  Ezért a követelmények későn felfedezett hibáiból eredő többletmunka lesz kevesebb.
    \end{itemize}

%33
	
\section{Sorolja fel a formális specifikáció előnyeit és hátrányait! Milyen típusú rendszerek specifikálásakor alkalmazzák a formális módszereket?}
    \textbf{Formális specifikáció hátrányai:} A formális módszerek - az előzetes várakozások ellenére nem tudtak teret hódítani, mert:
    \begin{itemize}
        \item Kialakultak többé-kevésbé sikeres módszerek, mint az OO tervezés, konfigurációkezelés, a strukturált programozás, stb., amelyek javították a szoftver minőségét.
        \item  Újabban a szoftver gyors piacra kerülése fontosabb, mint a minőség. A gyors fejlesztési technikák nem illeszkednek a formális módszerekhez.
        \item  A formális módszerek csak korlátozottan alkalmazhatók például a felhasználói interfészek, felületek és munkafolyamatok specifikálására.
        \item A formális módszerek nehezen, vagy egyáltalán nem alkalmazhatók nagy rendszerek esetén.
        \item  Még kevés eszköz készült a formális módszerek támogatására.
        \item  A formális módszereknek csak korlátozott felhasználási lehetőségei vannak. Alkalmazásuk kockázata és költsége sok esetben nagyobb, mint a várható előnyök.
    \end{itemize}
    \textbf{A formális specifikáció előnyei:}
    \begin{itemize}
        \item Azoknál a rendszereknél, amelyeket formális módszerekkel fejlesztettek, a hibaarány jóval alacsonyabb volt.
        \item  Ezért elsosorban kritikus rendszerek fejlesztésénél alkalmazzák, ahol a rendszer igen magas verifikálási és validálási költségeihez és az esetleges hibákból eredő katasztrófa költségeihez képest még kifizetodo a használata.
    \end{itemize}
    \textbf{Milyen típusú rendszereknél alkalmazzák? }\\
    A nagy rendszereket alrendszerekre bontják, amelyek között jól definiált interfészeket kell specifikálni. Az alrendszerek közti interfészek specifikálása teszi lehetővé, hogy az alrendszerek fejlesztése egymástól függetlenül történjen. Az interfészek absztrakt adattípusokkal, vagy objektum osztályokkal definiálhatók. A formális specifikáció algebrai megközelítése különösen alkalmas az interfészek pontos specifikálására.  A formális specifikációt nyílt interfészek, kommunikációs protokollok definiálására is alkalmazzák.
    
%34	
	
  \section{Melyek azok a rendszerek, amelyeknél a formális specifikációt leginkább alkalmazzák? Miért?}
  Elsősorban kritikus rendszerek fejlesztésénél alkalmazzák, ahol a rendszer igen magas verifikálási és validálási költségeihez és az esetleges hibákból eredő katasztrófa költségeihez képest még kifizetődő a használata.

%35  

  \section{Hol foglal helyet az architekturális tervezés a szoftverfolyamatban? Mire szolgál a rendszer architekturális terve?}
  \begin{center}
  \includegraphics[scale=0.70]{szoftvertervezes_folyamat}
  \end{center}
  \textbf{Mire szolgál a rendszer architekturális terve?}\\
    Az architekturális tervezés az a tervezési folyamat,
    amelynek során kijelölik a rendszert alkotó alrendszereket és azt a keretrendszert, amely vezérli az alrendszereket és biztosítja közöttük a kommunikációt. A folyamat végeredménye a szoftver architektúra, amely a tervezés alapjául szolgál.
    Ez a rendszertervezés folyamatának kezdeti lépcsőfoka.\\
    \textbf{Feladata:}
    \begin{itemize}
        \item Összekötni a specifikáció és a tervezés folyamatát
        \item  Kialakítani a rendszer alapvető struktúráját és azt a keretrendszert, amely a rendszert egységbe foglalja és működését irányítja.
    \end{itemize}
    Gyakran egyes specifikációs tevékenységekkel párhuzamosan végezhető. A kezdeti architekturális elképzelések már a specifikációban tükröződhetnek. Magába foglalja a fő rendszerkomponensek és azok vezérlésének, valamint kommunikációjának meghatározását.

%36    
    
\section{Kliens/szerver modell}
Olyan osztott rendszermodell, amely bemutatja hogyan
oszlanak meg az adatok és a feldolgozások a
komponensek között.
\newpage
\textbf{Elemei:}
\begin{itemize}
    \item{\textbf{Szerverek:} }Adatkezelő szerverek, nyomtatószerverek, alkalmazás szerverek, kommunikációs szerverek, stb.
    \item{\textbf{Kliensek:} }Többnyire önálló alrendszerek, amelyek hozzáférnek a szerverek szolgáltatásaihoz. Egyszerre sok példányban futnak. \\
    \textbf{Típusai:}
    \begin{itemize}
        \item{Vékony kliens: }Böngésző, szkriptekkel
        \item{Vastag kliens: }komplett kis alrendszer, helyi adatokkal, funkciókkal
    \end{itemize}
    \item{\textbf{Hálózat:} }A klienseknek biztosít hozzáférést a szerverek szolgáltatásaihoz.
\end{itemize}

%37

\section{Milyen előnyei és hátrányai vannak a kliens/szerver modellnek?}
 \textbf{Előnyök:}
 \begin{itemize}
     \item Jól struktúrált, osztott architektúra.
     \item Könnyen kiegészíthető új szerverrel (új funkcióval).
     \item  Alacsonyabb hardver követelményei vannak.
 \end{itemize}
 \textbf{Hátrányok:}
 \begin{itemize}
     \item  Nincs megosztott, közös adatmodell, mindegyik alrendszer a saját szempontjai szerint kialakított adatmodellt használja (ez előny a teljesítmény szempontjából).
     \item  Redundáns adatkezelés folyhat minden szerverben.
     \item  Nincs központi név- és szolgáltatás nyilvántartás, nehéz megtalálni, hogy milyen szerverek és szolgáltatások léteznek.
 \end{itemize}
  
  %38
  
 \section{Mi a különbség a vékony- és a vastag kliens között? Melyik milyen célra alkalmas?}
    \textbf{Vékony kliens: }
    A vékony kliens egy minimális eszközökkel rendelkező kliens. Ez a kliens típus a szükséges erőforrásokat is a távoli (host) gépen veszi igénybe. Egy vékony kliens feladata többnyire kimerül az alkalmazásszerver által küldött adatok grafikus megjelenítésében; a tényleges, nagy mennyiségű adat mozgatását, kezelését igénylő feladatot az alkalmazás szerver végzi el. (Pl.: Web böngészőből futó alkalmazások)\\
    \textbf{Vastag kliens: }
    A vastag kliens képes arra, hogy önmaga hajtson végre nagyobb adatmennyiségekkel feldolgozásokat, amikor a szerver inkább elsődleges tárolóként viselkedik. Ennek ellenére, a kifejezés inkább a számítógép szoftverére vonatkozik, és egyre inkább alkalmazzák hálózati számítógépek esetén, ahol a számítógép jelentős hálózati alkalmazásokat (is) futtat.
    
%39    
    
\section{Milyen modelleket alkalmaznak az objektumorientált tervezésben? Melyik mire alkalmas?}
    \textbf{Objektum-modellek: }
    \begin{itemize}
        \item  A rendszer felbontása együttműködő objektumokra. Az objektumok egyéni állapottal és az állapotokon értelmezett műveletekkel rendelkeznek.
        \item  A rendszert jól definiált interfészekkel rendelkező, lazán csatolt objektumokra bontja, amelyek egymás szolgáltatásait veszik igénybe.
        \item  Az objektum orientált felbontás az objektum osztályok, attribútumaik és műveleteik azonosítását (felismerését és helyes modellezését) jelenti.
        \item  Az implementáció során a konkrét objektumok ezekből az osztályokból jönnek létre. Az objektumok műveleteinek koordinálását valamilyen vezérlési modellel ábrázolják.
    \end{itemize}
     \textbf{Adatfolyam-modellek:}
     \begin{itemize}
        \item A rendszer felbontása funkcionális modulokra, amelyek az inputokat outputokká transzformálják (csővezeték modellnek is nevezik). A modulok funkcionális transzformációk.
        \item  Az adatfolyam modellben az inputot funkcionális transzformációk dolgozzák fel és ennek eredményeként állítják elő az outputot.
        \item  Tulajdonképpen megegyezik a UNIX shell „pipe and filter” modelljével.
        \item  Régóta alkalmazzák az adatfeldolgozási rendszerek modellezésére. (főleg kötegelt, szekvenciális adatfeldolgozás esetén)
        \item Interaktív rendszerek modellezésére csak nagyon precíz specifikálással alkalmas.
     \end{itemize}
     
%40     
     
\section{Mi a különbség a központosított vezérlés és az esemény alapú vezérlési modell között?}
    \textbf{Központosított vezérlés:}   
    Egy alrendszer végzi a teljes rendszer vezérlését, indítja, leállítja, stb. a többi alrendszert.
    \begin{itemize}
        \item{\textbf{Hívás-visszatérés modell:} }
         Fa-struktúrájú modell, ahol a csúcson van a vezérlő alrendszer. A vezérlés hívások sorozatán keresztül jut el a modulokhoz. Leginkább szekvenciális rendszerekhez alkalmazható (pl.: listafeldolgozás, listázás, jelentésgenerálás)
         \item{\textbf{Kezelő-modell:} }  Konkurens rendszerek modellezésére alkalmas. Egy központi rendszerkomponens koordinálja, indítja, állítja le a rendszerfolyamatokat (komponenseket, vagy alrendszereket), amelyek párhuzamosan is végrehajthatók. Alkalmazható szekvenciális rendszerekben is, ahol a vezérlő modul állapotváltozók értéke alapján hívja meg az egyes alrendszereket.
    \end{itemize}
\newpage
\textbf{Esemény alapú vezérlés:}\\
Minden alrendszer reagálhat az őt érintő külső, vagy más alrendszer által generált eseményekre. Eseményvezérelt rendszer lehet pl. egy táblázatkezelő is, ahol egy cella értékének megváltozása más cellákat is megváltoztat, vagy más alrendszert aktivizál.
     \begin{itemize}
         \item{\textbf{Broadcast-modell:}} Az eseményről mindegyik alrendszer értesül, és az reagál rá, amelyiknek ez a feladata.
         \item{\textbf{Megszakításvezérelt-modell:}} Valós idejű rendszerek modellje, ahol egy megszakítás-kezelő észleli az eseményt és elindítja az esemény feldolgozásáért felelős alrendszert.
     \end{itemize}

%41

\section{Milyen vezérlési modellek alkalmazhatók párhuzamos rendszerekben?}
    Konkurens rendszerek modellezésére alkalmas. Egy központi rendszerkomponens koordinálja, indítja, állítja le a rendszerfolyamatokat (komponenseket, vagy alrendszereket), amelyek párhuzamosan is végrehajthatók. Alkalmazható szekvenciális rendszerekben is, ahol a vezérlő modul állapotváltozók értéke alapján hívja meg az egyes alrendszereket.
    
%42    
    
\section{Milyen UML modellekkel ábrázolható a rendszer és környezetének kapcsolata?}
   \textbf{Környezeti modell: }
   \begin{itemize}
        \item A rendszer határainak ábrázolására szolgálnak (mi tartozik a rendszerhez és mi nem).
        \item A határok kijelölése gyakran nem technikai, hanem társadalmi, vagy szociális szempontoktól is függ.
        \item A rendszer és külső rendszerek közti kapcsolatok ábrázolása ugyancsak a környezeti modellek feladata.
        \item A környezeti modell ábrázolási módja általában egyszerű blokkdiagram.
   \end{itemize}
        
%43 
    
\section{Mire szolgálnak az objektumorientált tervezésben alkalmazható diagramok? Soroljon fel és jellemezzen néhányat!}
    \begin{itemize}
     \item{\textbf{Alrendszer modellek:}} Az objektumok logikai csoportosítását mutatják az összefüggő alrendszerekben.
     \item{\textbf{Szekvencia modellek:}} Az objektumok interakcióinak sorrendjét ábrázolják.
     \item{\textbf{Állapotmodellek:}} Bemutatják, hogy egy objektum hogyan változtatja az állapotát, válaszol bizonyos eseményekre.
     \item{\textbf{Egyéb modellek:}} Használati eset modellek, öröklődési modellek, osztálydiagramok, stb.
    \end{itemize}

%44

\section{Ismertesse a valós idejű rendszerek főbb jellegzetességeit.}
    A valós idejű rendszerek olyan (gyakran beépülő) szoftverrendszerek, amelyek figyelik környezetüket és adott (rövid) időn belül képesek reagálni a környezeti hatásokra (ingerekre). Általában inger-válasz típusú rendszerek.\\
    \textbf{Vannak:}
    \begin{itemize}
        \item{\textbf{Periodikus ingerek:} }Időzítés hatására végez valamit a rendszer.
        \item{\textbf{Aperiodikus ingerek:} }Rendszertelenül bekövetkező külső inger hatására kell valamit csinálni.
    \end{itemize}
    A valós idejű rendszerek működésében az idő kritikus tényező.\\
    A valós idejű rendszerek gyakran az átlagosnál nagyobb felelősségű feladatot látnak el.\\
    A valós idejű rendszerekhez mindig tartoznak hardver eszközök is:
    \begin{itemize}
        \item Érzékelők, amelyek adatokat gyűjtenek.
        \item Szabályozók, működtetők, amelyek a rendszer környezetét befolyásolják.
    \end{itemize}

%45

 \section{Melyek a fő különbségek az átlagos adatfeldolgozó rendszerek és a valós idejű rendszerek között?}
 
 \TODO{:((((}
 
%46 
 
 \section{Van-e szerepe a valós idejű rendszerek tervezésében a hardvertervezésnek? Miért?}
A rendszer hardver és a szoftver elemeit együtt kell megtervezni, célszerűen elosztva a funkciókat a hardver és a szoftver között. A döntést azonban, hogy mit kell hardverben és mit szoftverben megvalósítani, célszerű halogatni, az optimális megoldás megtalálása érdekében. Egy funkció sok esetben hardverrel jobb teljesítménnyel valósítható meg, de hosszabb fejlesztést igényel és a változások nehezebben követhetők.

%47
     
\section{Milyen programnyelveket alkalmaznak a valósidejű rendszerek programozására?}
\begin{itemize}
    \item{\textbf{C:} }Lehetséges effektív programokat írni, de nem feltétlenül támogatja a párhuzamos folyamatokat, vagy a megosztott erőforrások kezelését. Ezeket azonban az operációs rendszer megoldhatja.
    \item{\textbf{Ada:} }Valós idejű rendszerek programozására készült, ezért támogatja a konkurenciát és az újabb verziói már az ütemezést és az időzítést is kezelik.
    \item{\textbf{JAVA:} }A Java támogatja a konkurenciát (szálak és szinkronizált módszerek), ezért alkalmas a kevéssé kritikusan valós idejű rendszerek fejlesztésére.
\end{itemize}

%48

\section{Miért kevéssé alkalmas a Java programozási nyelv szigorúan valós idejű rendszerek programozására?}
Nem használható szigorúan real-time rendszerekhez, mert:
    \begin{itemize}
        \item Nem lehet megadni egy szál végrehajtási idejét,
        \item A „szemétgyűjtés” nem vezérelhető,
        \item A megosztott erőforrásokat tartalmazó sorok méretét nem lehet lekérdezni,
        \item A különböző virtuális gép implementációk különböző időzítéssel futtatják ugyanazt a szoftvert,
        \item A futási idő tár- és processzorhasználatának elemzése nem lehetséges.
    \end{itemize}

%49
    
\section{ Melyek a valós idejű futtatórendszerek főbb komponensei?}
\begin{center}
\includegraphics[scale = 0.55]{real_time_system_components}
\end{center}

%50

\section{Melyek a szoftver újrafelhasználásán alapuló fejlesztés előnyei és hátrányai?}
\textbf{Előnyök:}
\begin{itemize}
    \item{\textbf{Javuló megbízhatóság:} }A komponenseket már több működő rendszerben kipróbálták.
    \item{\textbf{Alacsonyabb projektkockázat:} }A komponensek ára és adaptálási költsége pontosabban tervezhető.
    \item{\textbf{A szaktudás jobb kihasználása:} }A speciális szaktudás a komponensben testesül meg, nem szükséges minden projekthez külön alkalmazni.
    \item{\textbf{Szabványosság:}} A szabványoknak való megfelelést a komponensek garantálják (interfészek, kommunikációs és GUI szabványok)
    \item{\textbf{Gyorsabb fejlesztés:}} Egy rendszer kifejlesztése gyorsabb, ha kevesebb eredeti fejlesztést igényel.
\end{itemize}

\textbf{Hátrányok:}
\begin{itemize}
    \item{\textbf{Növekvő karbantartási költségek:}} A komponens forráskódja és tervezési dokumentációja hiányában növekszik a karbantartás költsége.
    \item{\textbf{Az eszköztámogatás hiánya:}} A CASE eszközök gyakran nem támogatják az újrafelhasználást.
    \item{\textbf{A "nem mi találtuk ki" jelenség:} }Egy teljes rendszer kidolgozása nagyobb szakmai kihívás.
    \item{\textbf{A komponenskönyvtárak karbantartása:} }Sokba kerül a komponenskönyvtárak feltöltése és folyamatos 
    karbantartása.
    \item{\textbf{Az újrafelhasználható komponensek megtalálása és adaptálása: }}Még nem fejlődtek ki a komponensek megtalálását és adaptálását segítő általános technikák.
\end{itemize}

%51

\section{Soroljon fel három érvet, amely támogatja a komponens alapú újrafelhasználást és hármat, amely ellene szól!}
\textbf{Előnyök:}
\begin{enumerate}
    \item A komponens alapú fejlesztés beilleszthető a szabályos szoftverfolyamatba
    \item A komponensek az objektumosztályoknál sokkal absztraktabbak és különálló szolgáltatásoknak tekinthetők
    \item A legtöbb programozási nyelvben hivatkozhatunk könyvtárban tárolt komponensekre

\end{enumerate}
\textbf{Hátrányok:}
\begin{enumerate}
    \item A komponensek inkompatibilitása miatt a költség- és időmegtakarítás a vártnál kevesebb lehet (integrációs munkák).
    \item Nehézséget okozhat a komponensek megtalálása (nincsenek szabványok a komponensek tulajdonságainak leírására, hiányoznak az egységes komponens könyvtárak).
    \item  A követelmények változását követő evolúció lehetetlen, ha a komponensek nem cserélhetők.
\end{enumerate}

%52

\section{Mi a programgenerátor alapú újrafelhasználás lényege? Milyen területeken alkalmazzák?}
A generátor alapú újrafelhasználás akkor lehetséges, ha egy programgenerátor tartalmazza egy szakterület alapvető ismeretanyagát. (pl. adatfeldolgozás).  Az ilyen programgenerátorok tartalmazzák a szabványos algoritmusokat és függvényeket, és ezek paraméterezését követően a generátor automatikusan előállítja a programot. A szakterületre kidolgozott nyelven, vagy újabban grafikus eszközökkel lehet elkészíteni a rendszer
modelljét.

%53

\section{Miért alkalmazzák a generátor alapú újrafelhasználást elsősorban az adatfeldolgozó, eBusiness rendszerek fejlesztésében?}
A generátor alapú újrafelhasználás igen költséghatékony, de viszonylag kevés szakterülethez léteznek ilyen rendszerek.(pl.: adatfeldolgozó, e-business).\\
Ezzel a módszerrel könnyebben állíthatók elő az alkalmazások, mint a komponens alapú módszerrel.

%54

\section{Mi a komponens, milyen interfészei vannak?}
 A komponensek szolgáltatásokat nyújtanak a rendszer számára, a végrehajtás helyétől és a megvalósítás nyelvétől függetlenül.
 \begin{itemize}
     \item  Egy komponens egy függetlenül végrehajtható program, amely egy vagy több végrehajtható objektumból áll.
     \item A komponensek interfészeit publikálják és minden interakció ezeken az interfészeken keresztül folyik. A komponens forráskódja sok esetben nem hozzáférhető, belső állapotai nem láthatóak.
 \end{itemize}
 \textbf{Komponens interfészei: }
 \begin{itemize}
     \item{\textbf{Szolgáltatott interfészek: }}A komponens által szolgáltatott interfészek.
     \item{\textbf{Szükséges interfészek: }}Azok az interfészek, amelyeket a komponenst használó rendszernek, vagy környezetének kell biztosítania.
 \end{itemize}
  
%55

\section{Milyen nyelvek és környezetek alkalmasak a komponensek integrálására?}
A legtöbb programnyelvben hivatkozhatunk könyvtárban tárolt komponensekre. Leggyakrabban szkriptnyelveket használnak komponensek integrálására.\\
Köztes integrációs keretrendszerek: komponensek közti kommunikációt és információcserét támogató szabványok és osztályok. (Ilyen például a CORBA, JavaBean, COM, DCOM, stb.)

%56

\section{Milyen hátrányai vannak az újrafelhasználható komponensekkel történő szoftverfejlesztésnek?}
Az újrafelhasználhatóság és a használhatóság ellentmondása:  Minél általánosabb interfésszel rendelkezik, annál inkább újrafelhasználható, de annál bonyolultabb, vagyis kevésbé használható.

%57

\section{Mire szolgának az alkalmazási keretrendszerek, hogyan csoportosíthatók?}
 A keretrendszer absztrakt és konkrét osztályok gyűjteményéből és a köztük lévő interfészekből álló alrendszer-terv.\\
 A keretrendszerek úgy implementálhatók, hogy a terv részeit komponensek hozzáadásával egészítjük ki.  Általában viszonylag nagy, újrafelhasználható egységek, de nem önálló alkalmazások.\\
 Az alkalmazások több keretrendszer integrálásával hozhatók létre.\\
 \textbf{A keretrendszerek csoportosítása: }
 \begin{itemize}
     \item{\textbf{A rendszer infrastruktúrájának keretrendszerei:} }A rendszer infrastrukturális alapjainak (kommunikáció, felhasználói felületek, titkosítás, stb.) fejlesztését támogatják.
     \item{\textbf{Köztes, integrációs keretrendszerek:} }Komponensek közti kommunikációt és információcserét támogató szabványok és osztályok. (Ilyen például a CORBA, JavaBean, JMI, COM, DCOM, .NET, stb.)
     \item{\textbf{Vállalati alkalmazások keretrendszerei:}} Az egyes speciális szakterületi alkalmazások fejlesztését támogatják. A szakterületi tudást tartalmazzák (pl. pénzügy, telekommunikáció).
 \end{itemize}

%58

\section{Mi a „polcról levehető” termék? Leginkább milyen rendszerekben alkalmazzák?}
  A „polcról levehető”, COTS – Commercial Off-The-Shelf rendszerek általában komplett alkalmazási rendszerek, amelyek API-val rendelkeznek. Legtöbbször rendszerszoftver termékek, az egyszerű komponenseknél nagyobb funkcionalitással.\\
   Nagy rendszerek építésekor gyakran használt stratégia a COTS termékek integrálása. Különösen a gyors fejlesztést kívánó eCommerce, eBusiness rendszerek körében. A fejlesztési idő nagyságrendekkel csökkenthető.
\newpage
%59
   
\section{Milyen nehézségei vannak a COTS termékek alkalmazásának?}
  \begin{itemize}
      \item{\textbf{A funkcionalitás és a teljesítmény nem tartható kézben:} }A COTS rendszerek sokszor kevésbé effektívek mint azt a reklámokban ígérik.
      \item{\textbf{A COTS rendszerek együttműködése bizonytalan: }}A különböző COTS rendszerek eltérő feltételezésekkel készültek (pl. sorkezelés), ezért az integráció nehéz lehet.
      \item{\textbf{Az evolúció ellenőrizhetetlen: }}A szállító és nem a felhasználó határozza meg.
      \item{\textbf{A COTS termékek támogatása: }}A szállító által biztosított támogatás gyakran nem terjed ki a rendszer teljes élettartamára.
  \end{itemize}
  
%60 

  \section{Miért drágább egy újrafelhasználható komponens kifejlesztése az egyedi komponens kifejlesztésénél?}
  \begin{itemize}
      \item Az újrafelhasználható komponensek meglévő komponensek általánosításával hozhatók létre. Ehhez nagy tapasztalat kell(tehát hozzáértő személy).
      \item Az újrafelhasználható komponensek fejlesztési költségei többszörösen meghaladják az egyszerű, specifikus komponensek költségeit. Ezt egyetlen projekt költségeiből nem lehet fedezni, ezért kialakultak olyan szoftverfejlesztő vállalatok, amelyek specializálódtak az újrafelhasználható komponensek fejlesztésére.
  \end{itemize}
  
%61

  \section{Mi az alkalmazáscsalád? Miért alakultak ki az alkalmazáscsaládok?}
  \textbf{Alkalmazás család:}
  Az alkalmazáscsalád az alkalmazási rendszerek olyan termékcsaládja, vagy termékvonulata, amelyek egy közös, szakterület-specifikus architektúrára épülnek („közös mag”).\\
  \textbf{Kialakulásának célja:}
  A kialakulás célja az volt, hogy az alkalmazáscsalád magját (szoftver magját) újra feltudják használni, amikor egy új alkalmazást szeretnénk fejleszteni.
 
%62

 \section{Hogyan osztályozható az alkalmazáscsaládok specializációja?}
 \begin{itemize}
     \item \textbf{Platform specializáció:}
     Az alkalmazás egyes verziói különböző platformokra készülnek (pl. Windows, Solaris, Linux, ..), de a funkcionalitás azonos.
      \item \textbf{Konfigurációs specializáció}
      Az alkalmazás egyes verziói különböző perifériákkal képesek együttműködni.(A perifériákat kezelő komponensek különböznek.)
       \item \textbf{Funkcionális specializáció}
       Az alkalmazás egyes verziói eltérő funkcionális követelmények kielégítésére készülnek.(A funkcionális komponensek különböznek.) 
 \end{itemize}
 \newpage
 %63
 
 \section{Mi a különbség a tesztelés és a belövés között? Melyiknek mi a célja?}
 \textbf{Különbségek:}
 \begin{itemize}
     \item A verifikáció és validáció feladata a hibák, hiányosságok létezésének felfedezése.
    \item A belövés ezen hibák helyének lokalizálása és kijavítása.
    \item A belövés a program viselkedésére vonatkozó feltételezések felállításával kezdődik, majd ezen feltételezések vizsgálatával próbálja megtalálni a hibákat.
    \item A belövés során felfedezett hibák javítása után újra kell tesztelni a programot.

 \end{itemize}
 \textbf{Tesztelés célja:}
 \begin{itemize}
     \item Felfedni a rendszerben (esetleg már a tervek szintjén) rejlő hibákat, nem arról megbizonyosodni, hogy hibamentes a rendszer.
     \item Meggyőződni arról, hogy a rendszer egy-egy konkrét működési szituációban használhatóan muködik.
 \end{itemize}
 \textbf{Belövés célja:}
 \begin{itemize}
     \item A felfedett hibák helyének lokalizálása és kijavítása
 \end{itemize}
 
 %64
 
 \section{Mi a célja a szoftver verifikációjának és mi a validáció feladata?}
 \textbf{Verifikáció:}
 Annak ellenőrzése, hogy valóban a megfelelő terméket készítjük el, vagyis, hogy a szoftver megfelel a specifikációnak. \\
 \textbf{Validáció:}
 Annak bizonyítása, hogy a terméket jól készítjük el, vagyis hogy a szoftver valóban a megrendelő elvárásainak megfelelően működik (esetleg a specifikációval ellentétesen). \\\\
 A szoftvernek azt kell megvalósítania, amit a felhasználó valóban elvár tőle.\\
 A \textbf{verifikáció és validáció (V\&V)} folyamata a szoftver teljes életciklusára kiterjed, a szoftver folyamat minden fázisában szerepet kap.
    
%65    
    
\section{Miért célszerű a szoftvertesztelés mellett átvizsgálást (inspekció) is tartani?}
\textbf{Szoftver-átvizsgálás (inspekció):}
A rendszer reprezentációjának elemzése (Követelmény-specifikáció, tervek, grafikus ábrázolások, forráskód). A forráskód elemzése automatizálható.(Statikus verifikáció)
\\
\textbf{Miért célszerű inspekciót is tartani?}
\begin{itemize}
    \item A szoftver átvizsgálás célja a hiányosságok felderítése, a költséges tesztelés helyett a hibák kb. 60 \%-a felfedhető az átvizsgálás során.
    \item A fejlesztési folyamat kezdetétől alkalmazható, a dokumentumok (követelmények, tervek) átvizsgálásával.
    \item Egy átvizsgálás során több hiányosság felfedezhető, amíg egy teszt többnyire egy hibát fed fel.(Legalábbis, ha egy hibát detektál, a tesztelést abba kell hagyni, és a hiba kijavítását követően újból elölről kell kezdeni.)
    \item Sok költséges tesztelést előzhet meg.
\end{itemize}

%66

\section{Mi a programtesztelés feladata? Milyen alaptípusai vannak?}
\textbf{Szoftvertesztelés:}
A szoftver implementációjának tesztadatokkal való futtatása és a viselkedés megfigyelése(Dinamikus verifikáció).\\
\textbf{Típusai:}
\begin{itemize}
    \item \textbf{Hiányosságok tesztelése}
    \begin{itemize}
        \item Feladata a rendszer hibáinak és hiányosságainak felfedése.
        \item \textbf{Fajtái:}
        \begin{itemize}
            \item \textbf{Komponens tesztek:}\\ Fekete doboz, ekvivalencia-osztályok, struktúrateszt, útvonal-teszt
            \item \textbf{Integrációs tesztek:}\\„Fentről lefelé/lentről felfelé”, interfészteszt, stressz-tesztek
            \item \textbf{Objektumorientált tesztelés}
        \end{itemize}
    \end{itemize}
    \item \textbf{Statisztikai tesztelés:}
    A rendszer teljesítményének és megbízhatóságának tesztelése, valós helyzetekben (valós felhasználói inputtal és gyakorisággal).
\end{itemize}

%67

\section{Mire szolgál a szoftver átvizsgálása? Mi a különbség az átvizsgálás és a tesztelés között?}
\textbf{A szoftver átvizsgálásának célja:}
A szoftver átvizsgálás célja a hiányosságok felderítése, a költséges tesztelés helyett a hibák kb. 60 \%-a felfedheto az átvizsgálás során.
\\
\textbf{Különbségek:}
\begin{itemize}
    \item Egy átvizsgálás során több hiányosság felfedezhető, amíg egy teszt többnyire egy hibát fed fel.(Legalábbis, ha egy hibát detektál, a tesztelést abba kell hagyni, és a hiba kijavítását követően újból elölről kell kezdeni.)
    \item Az átvizsgálás már fejlesztési folyamat kezdetétől alkalmazható, a dokumentumok (követelmények, tervek) átvizsgálásával, míg a tesztek nem
    \item Az inspekció alkalmas eszköz arra, hogy ellenőrizze, megfelel-e a program a specifikációnak
\end{itemize}

%68

\section{Milyen hiányosságokat lehet elsősorban felfedezni a programok átvizsgálása során?}
\begin{itemize}
    \item Dokumentumokban és forráskódban rejlő hiányosságok
    \item Követelményekben és tervekben lévő hiányosságok felderítése
\end{itemize}

%%69

\section{Mi a Cleanroom szoftverfejlesztési folyamat lényege?}
\begin{itemize}
    \item A szoftverhibák elkerülését, nem pedig megtalálását és kijavítását célzó szigorú átvizsgálási folyamat. (A név a félvezető-gyártásból származik)
    \item A rendszer komponenseinek tesztelését helyettesíti átvizsgálásokkal, megfelelnek-e a specifikációnak.
    \item Inkrementális fejlesztési módszer, először a kritikus inkrementumokat szállítja le.
    \item Statikus verifikáció (szigorú átvizsgálások)
    \item A rendszer statisztikai tesztelése
    \item Formális specifikáció (állapotátmenet modell, strukturált programozás, csak néhány vezérlési és adatabsztrakciós konstrukció használható)
\end{itemize}

%%70
\section{Ismertesse a grafikus felhasználói kezelőfelületek tervezésének alapelveit!}
\textbf{Alapelvek:}
\begin{itemize}
    \item \textbf{A felhasználói jártasság figyelembevétele:}\\A felületnek olyan kifejezéseket és fogalmakat kell használnia, amelyeket az átlagos felhasználó ismer.

    \item \textbf{A felület konzisztenciája:}\\Azonos menüknek és parancsoknak azonos formátummal kell rendelkezniük, hasonló műveleteket hasonló módon és helyen kell jelezni és megvalósítani.
    \item \textbf{Minimális meglepetés:}\\A felhasználóban kialakul egy modell a rendszer muködésérol. A hasonló tevékenységeknek hasonló hatást kell kiváltaniuk, különben a rendszer kellemetlen meglepetéseket okoz felhasználó számára.
    \item \textbf{Visszaállíthatóság:}\\Minden helyzetben számítani kel arra, hogy a felhasználó hibázhat, ezért gondoskodni kell arról, hogy a hibát kijavíthassa:
Visszavonási lehetőség (undo), esetleg többszintű.
Veszélyes tevékenységek megerősítése (pl. törlés),
„Puha törlés”
    \item \textbf{A felhasználó támogatása:}\\A felületnek könnyen elérhető segítő, vagy súgó rendszerrel kell rendelkeznie. A súgót strukturálni kell, nem szabad túl sok információt közölni. Előnyös a helyzetfüggő súgó alkalmazása.
    \item \textbf{A felhasználók sokfélesége:}\\Az alkalmi felhasználók több támogatást, a gyakorlott felhasználók egyszerűbb, gyorsabb működést várnak.
\end{itemize}
%%71
\section{Miért fontos a grafikus felhasználói kezelőfelület gondos tervezése?}
\begin{itemize}
    \item A felhasználó a kezelőfelületen keresztül kerül kapcsolatba a rendszerrel, ennek alapján alkot véleményt, csak ezután ismeri meg a rendszer funkcionalitását.
    \item A rosszul tervezett kezelőfelület gyakran katasztrofális hibákhoz vezet.
    \item A szegényes, vagy következetlen felhasználói kezelőfelület sok rendszer bukásához vezetett.
    \item Nagy fejlesztő szervezetekben szakértőket alkalmaznak (grafikus, pszichológus, szakterületi szakértő), de kis/közepes cégeknél gyakran a kezelőfelület megtervezése is a szoftver tervező feladata.
\end{itemize}

%72

\section{Miért célszerű egyes rendszerekben különböző felhasználói felületeket kidolgozni a gyakorlott és az alkalmi felhasználók számára?}
Az alkalmi felhasználók több támogatást, a gyakorlott felhasználók egyszerűbb, gyorsabb működést várnak.

%73

\section{Milyen alapelemeket használunk a grafikus felhasználói kezelőfelületeken?}
\begin{itemize}
    \item \textbf{Ablakok:} Az ablaktechnikával több ablakban egyszerre többféle információ jeleníthető meg.
    \item \textbf{Ikonok:} Az ikonokkal az információ fajtái jelölhetők: állományok, folyamatok, stb.
    \item \textbf{Menük:} A menütechnikával a parancsok egy strukturált menüből választhatók ki. A felhasználónak nem kell egy parancsnyelvet megtanulnia és parancsokat begépelnie. 
    \item \textbf{Pozicionálás:} Egér, vagy más eszköz alkalmazható egy menüpont kiválasztására, vagy egy ablakban a lényeges elemek meg- vagy kijelölésére.
    \item \textbf{Grafika(színek, képek):} Grafikus elemek és színek alkalmazása a szöveg mellett (vagy helyett) áttekinthetőbbé teszi a képernyőt.
\end{itemize}

%74

\section{Milyen eszközöket alkalmazhatunk a grafikus felhasználói kezelőfelületen a felhasználó támogatására?}
A kezelőfelület tervezésekor figyelembe kell venni a felhasználók igényeit, gyakorlatát és képességeit.\\
A felületnek könnyen elérhető segítő, vagy súgó rendszerrel kell rendelkeznie. A súgót strukturálni kell, nem szabad túl sok információt közölni. Előnyös a helyzetfüggő súgó alkalmazása.

%75

\section{Milyen előnyei és hátrányai vannak a parancsnyelv alkalmazásának a felhasználói interakciókban?}
A felhasználó parancsokat gépelve utasítja a rendszert (pl. Unix)
\\
\textbf{Parancsnyelv előnyei:}
\begin{itemize}
    \item Egyszerű, olcsó terminálon is alkalmazható,

    \item Egyszerűen feldolgozható (pl. fordító technikával)

    \item Bonyolult, egymásba ágyazott  parancsok is kezelhetők,

    \item Rugalmas.
\end{itemize}
\textbf{Parancsnyelv hátrányai:}
\begin{itemize}
    \item Nehezen tanulható, az átlagos felhasználó számára bonyolult,
    \item Gépelési gyakorlatot kíván
    \item A hibakezelést (hibajelzés, visszavonás) nehéz megoldani
\end{itemize}
A parancsnyelveket a gyakorlott felhasználó számára lehet alkalmazni. A menürendszer alternatívájaként célszerű biztosítani. 
%76


\section{Sorolja fel és jellemezze a felhasználói interakciók fajtáit!}
\textbf{Közvetlen manipuláció:}
A felhasználó közvetlenül a képernyőn látható objektumot kezeli (pl. törléshez kukába viszi).
\begin{itemize}
    \item \textbf{Előnyei:}
    \begin{itemize}
        \item Könnyen tanulható és gyors,
         \item A felhasználó azonnal visszajelzést kap, így a tévedés gyorsan visszavonható.
    \end{itemize}
    \item \textbf{Hátrányai:}
    \begin{itemize}
        \item Bonyolult lehet a felhasználó tevékenységéről (szándékáról) a megfelelő információt begyűjteni a program számára,
         \item Csak akkor használható, ha a feladatok és objektumok egyértelműen megkülönböztethető ikonokkal reprezentálhatók.
    \end{itemize}
\end{itemize}
\textbf{Menükiválasztás:}
A felhasználó a rendszer által felkínált (sokszor helyzet-függő) listából választhat, a kijelölést egér, vagy kurzormozgatással, rövidített név beírással is végezheti. Alkalmazható az egyszerű (pl. érintőképernyős) terminálokon is.
\begin{itemize}
    \item \textbf{Előnyei:}
    \begin{itemize}
        \item A felhasználónak nem kell parancsokat megjegyeznie,

         \item Kevés gépelést igényel és a hibák könnyen kivédhetők,
 \item Állapotfüggő súgó alkalmazható.
    \end{itemize}
    \item \textbf{Hátrányai:}
    \begin{itemize}
        \item Az akciók közötti logikai összefüggések (and, or) nem jeleníthetők meg,

         \item Kevés választási lehetőséget enged meg, a sok lehetőséghez strukturálni kell a menüket.
  \item A gyakorlott felhasználó számára lassú.
    \end{itemize}
\end{itemize}
\textbf{Űrlapkitöltés:}
Az űrlap az aktuális állapothoz alkalmazható.
Olyan rendszerekben alkalmazzák, ahol sok adatot kell bevinni (pl. adatrögzítés).
\begin{itemize}
    \item \textbf{Előnyei:}
    \begin{itemize}
        \item A felhasználói hibák felfedhetők és jelezhetők, illetve kivédhetők,
         \item Legördülő választási lehetőséggel sok felhasználói tévedés kizárható,
 \item Könnyen megtanulható.

    \end{itemize}
    \item \textbf{Hátrányai:}
    \begin{itemize}
        \item Nagy képernyőfelületet foglal.
    \end{itemize}
\end{itemize}
\textbf{Parancsnyelv:}
A felhasználó parancsokat gépelve utasítja a rendszert (pl. Unix).
A parancsnyelveket a gyakorlott felhasználó számára lehet alkalmazni. A menürendszer alternatívájaként célszerű biztosítani. 
\begin{itemize}
    \item \textbf{Előnyei:}
    \begin{itemize}
    \item Egyszerű, olcsó terminálon is alkalmazható,

    \item Egyszerűen feldolgozható (pl. fordító technikával)

    \item Bonyolult, egymásba ágyazott  parancsok is kezelhetők,

    \item Rugalmas.
\end{itemize}
    \item \textbf{Hátrányai:}
   \begin{itemize}
    \item Nehezen tanulható, az átlagos felhasználó számára bonyolult,
    \item Gépelési gyakorlatot kíván
    \item A hibakezelést (hibajelzés, visszavonás) nehéz megoldani
\end{itemize}
\end{itemize}
\textbf{Természetes nyelv:}
\begin{itemize}
    \item A felhasználó a parancsokat természetes nyelven gépeli be, amelynek szótára korlátozott. Az ilyen rendszerek általában speciális alkalmazási területet szolgálnak ki.

    \item A természetes nyelv megfelelő az alkalmi felhasználó számára de a gyakorlott felhasználó nem kedveli a túl sok gépelés miatt.

    \item Beszédfelismeréssel kombinálva – szűkített kifejezésekkel – ma is használják. 

\end{itemize}

%77

\section{Milyen lehetőségek vannak az információ grafikus megjelenítésére?}
\begin{itemize}
    \item{A rendszer megjeleníti a felhasználó számára közlendő információkat.}
    \item Ez az információ megjelenhet közvetlenül szöveges formában, vagy más módon (pl. grafikusan, akár hang kíséretében).

    \item A jól tervezett rendszerekben maga az információ és az azt megjelenítő szoftver különválik.

    \item A Model-View-Controller (MVC) általánosan alkalmazott architektúra az adatok többféle megjelenítését.
\end{itemize}
Az információ lehet \textbf{statikus információ:}
\begin{itemize}
    \item Értéket kap a munkafázis (session) kezdetén és ez a session ideje alatt nem változik meg,
    \item Lehet numerikus, szöveges, vagy grafikus
\end{itemize}
Vagy \textbf{dinamikus információ:}
\begin{itemize}
    \item Megváltozik a munkafázis alatt és a megváltozott értéket a felhasználó számára meg kell jeleníteni,
    \item Lehet numerikus, szöveges, vagy grafikus
\end{itemize}

%78

\section{Írjon példákat, amikor az információt célszerű grafikusan, analóg módon megjeleníteni.}

\textbf{Digitális megjelenítés:}
\begin{itemize}
    \item{Pontos értékeket közöl}
    \item{Kevés helyet foglal a képernyőn.}
\end{itemize}
\textbf{Analóg megjelenítés:}
\begin{itemize}
    \item{Egy pillantással áttekinthető}
    \item Relatív értékeket is képes közölni:
    \begin{itemize}
        \item{Egy állandó értékhez képest (egy határhoz közeli értéket színnel még külön ki lehet emelni), vagy}
        \item{Korábbi minimális-maximális értékhez képest}
    \end{itemize}
\end{itemize}
\begin{center}
\includegraphics[scale=0.8]{megjelenites}
\end{center}

%79

\section{Milyen szabályokat kell betartani a színek alkalmazásakor a grafikus felhasználói kezelőfelületen?}
\begin{itemize}
    \item Ne használjunk túl sok színt.
Egy felületen 4-5, egy rendszerben 7-8 szín a maximum.
    \item Először tervezzünk monokróm felületeket, utána adjuk hozzá a színeket.

    \item Az állapotváltozásokat jelezzük színváltással.

    \item A végrehajtandó feladatokat jelöljük színkóddal, a különböző feladatokat különböztessük meg színekkel is.

    \item A színkódolást alkalmazzuk következetesen a teljes rendszerben.

    \item Egyes színkombinációk zavaróak, vagy fárasztják a szemet.

\end{itemize}
%%80
\section{Milyen szempontokat kell figyelembe venni a rendszer üzeneteinek szövegezésekor?}
\textbf{Szempontok:}
\begin{itemize}
    \item A hibaüzenetek tervezése különösen fontos: a kezdő felhasználó ezekkel találkozik a leggyakrabban. A rossz, vagy számára érthetetlen hibaüzenetek miatt elutasíthatja a rendszert.

    \item Az üzeneteknek udvariasnak, előrevivőnek és következetesnek kell lennie.

    \item A hibaüzenetek tervezésének meghatározó tényezője a felhasználó háttere, gyakorlata.

\end{itemize}
\textbf{Az üzenetek szövegezése:}
\begin{itemize}
    \item \textbf{Szövegkörnyezet:} A tájékoztató rendszernek mindig a felhasználó tevékenységéhez és a rendszer aktuális állapotához igazodó üzenetet kell adnia.

     \item \textbf{Tapasztalat:} A tapasztalt felhasználót már idegesíti az a kifejtő magyarázat, amit a kezdő felhasználó még hasznosnak tart és igényel. A tájékoztató rendszernek mindkét üzenettípust fel kell kínálnia. 

      \item \textbf{Képzettség:} Az üzeneteket a felhasználó képzettségéhez és gyakorlatához kell igazítani. A különböző felhasználók számára szánt üzeneteket különböző módon, a számára érthető terminológiával kell megfogalmazni.

       \item \textbf{Stílus:} Az üzeneteket pozitív módon építő jelleggel kell megfogalmazni. Egy üzenet soha nem lehet sértő és nem gúnyolódhat.

        \item \textbf{Kultúra:} Hasznos, ha az üzenetek tervezője tisztában van azzal a kultúrával, ahol a rendszert használni fogják. Az egyik országban megfelelő üzenetek a kulturális különbségek miatt egy másik országban elfogadhatatlanok.

\end{itemize}
%%81
\section{Miért célszerű a súgórendszerbe több belépési pontot biztosítani?}
\textbf{A súgó tervezése:}
\begin{itemize}
    \item A felhasználó segítségért, információért fordul a súgóhoz.

    \item A súgó tervezésekor mindkét igényt figyelembe kell venni.

    \item Többféle lehetőséget kell biztosítani, ehhez több belépési pontra van szükség.

    \item A jó súgórendszer hierarchikus szerkezetű, de bonyolult hálós struktúrájú, ahol az információs egységek között sokféle kapcsolat van.

    \item Több ablak alkalmazásával érthetővé tehető a bonyolult hierarchia.
\end{itemize}
\textbf{A súgórendszer használata:}
\begin{itemize}
    \item Több belépési pontra van szükség, hogy a felhasználó a rendszer különböző állapotaiból léphessen be.
    \item Ugyanakkor hasznos azt jelezni, hogy éppen  hol jár a súgó hierarchiájában.
    \item Célszerű a korábban bejárt útvonalat is megjeleníteni, mert a bonyolult hálóban könnyen elvész  a felhasználó. Ez a visszalépéseket is támogathatja.
\end{itemize}

%82

\section{Mi a teszteset és a tesztadat? Hogyan lehet a tesztadatok számát csökkenteni?}
\textbf{Teszteset:}
A tesztesetek a teszthez szükséges inputok és a várt outputok specifikációi.\\
\textbf{Tesztadat:}
A tesztadatok a rendszer tesztelésére kidolgozott input adatok.\\
\textbf{Tesztadatok számának csökkentése:}
\TODO{TODO}
Ekvivalenciaosztályok?

\section{Mi a „fekete doboz” és a „fehér doboz” tesztelési stratégia lényege? Melyiket milyen esetben lehet alkalmazni?}
\textbf{Fekete doboz tesztelés:}
\begin{itemize}
    \item Funkcionális tesztelésnek is nevezik.

    \item A programot fekete doboznak tekintjük, a tesztesetek a programspecifikáció alapján készülnek.

    \item Nem foglalkozik a program implementációjával.

    \item A tesztek tervezése a szoftverfolyamat korai szakaszában megkezdődhet.(Egyes Agilis módszereknél előbb, mint a program tervezése!)

    \item Az előreláthatóan hibát okozó tesztesetek tervezéséhez szakterületi ismeretekre van szükség.
\end{itemize}

\textbf{Fehér doboz tesztelés (Struktúrateszt):}
\begin{itemize}
    \item Fehér doboz vagy üvegdoboz tesztelésnek is nevezik, mert a tesztek a program struktúrájának, implementációjának ismeretében készülnek.
    \item A struktúra és a kód ismeretében újabb ekvivalencia-osztályok definiálhatók
    \item A tesztelő a tesztesetek készítésekor elemzi a kódot, hogy biztosítsa minden utasítás legalább egyszeri végrehajtását (az összes lehetséges út-kombináció tesztelésére nincs reális lehetőség).
\end{itemize}
\textbf{Alkalmazási területek:}\\
\TODO{TODO}
\begin{itemize}
    \item Az objektumokhoz kapcsolódó műveletek tesztelése: Függvények, vagy eljárások, fekete- vagy fehér doboz eljárással tesztelhetők.
    \item Fekete doboz tesztek: integrációs teszt, objektumosztályok tesztelése
\end{itemize}

\section{Mit jelent a tesztadatok ekvivalencia-osztályozása? Írjon példát az ekvivalencia-osztályok alkalmazására.}
\textbf{Ekvivalencia-osztályozás:}
\begin{itemize}
    \item A rendszer input és output adatait  valamilyen közös jellegzetesség szerint csoportosítják, amelyekre a rendszer hasonló módon reagál:
    \item A fejlesztők legtöbbször az inputok tipikus értékeit veszik figyelembe.
    \item A teszteseteket a határértékek közelében és az osztályok közepéből célszerű kiválasztani:
\end{itemize}
\textbf{Példa:}
ha az input 5 jegyű valós szám 10.000 és 99.000 között, akkor az ekvivalencia-osztályok:
\begin{itemize}
    \item Azok a számok melyek kisebb 10.000-nél
    \item Azok a számok melyek 10.001-99.000 között vannak
    \item Azok a számok melyek 99.900-99.999 között vannak
    \item Azok a számok melyek 99.999-nél nagyobbak
\end{itemize}

\section{Mi a célja az útvonaltesztelésnek? Mi a ciklomatikus komplexitás, hogyan számítható?}
\textbf{Útvonal tesztelés célja:}
\begin{itemize}
    \item Az útvonal tesztelés strukturális tesztelési stratégia. Célja, hogy minden független útvonalon végighaladjon a teszt. Ekkor legalább egyszer biztosan sor került minden utasítás végrehajtására, és minden feltételes utasítás igaz és hamis eseteire.
    \item A kiindulás a program folyamat-gráfja, amely a döntéseket reprezentáló csomópontokból és a vezérlés irányát képviselő élekből áll. Előállítása viszonylag egyszerű, ha  programban nincs goto.
    \item Csak kisebb programok tesztelhetők ilyen módon.
\end{itemize}
\textbf{Ciklomatikus komplexitás:}
\begin{itemize}
    \item A független utak száma a programban.
    \item CC megmutatja, hogy hány tesztet kell végrehajtani az összes független út végrehajtásához, vagyis minden vezérlő utasítás legalább egyszeri végrehajtásához.
    \item Nem lehet a független utak összes kombinációját végrehajtani.
    \item A dinamikus programelemzők a fordításkor kiegészítő kódot adnak a programhoz, amelyek mérik, hogy az egyes vezérlő utasítások hányszor kerültek végrehajtásra. 
\end{itemize}
\textbf{Ciklomatikus komplexitás számolása:}
\[ CC = Élek száma - Csomópontok száma +2 \]

\section{Ismertesse az integrációs tesztelési stratégiákat! Mi az összefüggés e stratégiák és a szoftverfolyamat modellje között?}
\textbf{Integrációs tesztelés:}
\begin{itemize}
    \item Teljes rendszerek vagy alrendszerek tesztelése, amelyek előzőleg már tesztelt komponensekből állnak.

        \item A komponensek együttműködéséből származó hibák feltárására szolgál.

            \item Az integrációs teszt fekete doboz tesztelés, a tesztek a specifikációból származnak.

                \item Komplex rendszerben az észlelt hibás eredményből nehéz a hiba helyére következtetni.

                    \item Az inkrementális integrációs tesztelés némileg segít.
\end{itemize}
\textbf{Integrációs tesztelés startégiái:}
\begin{itemize}
    \item \textbf{Fentrol lefelé tesztelés:}\\
    A rendszer magas szintű komponenseit még a tervezés és az implementáció alatt integrálják. A még el-nem készült komponenseket azonos interfésszel készült „csonkok” helyettesítik, ahol szükséges. Ezeket fokozatosan kicserélik a kész elemekkel.(Evolúciós fejlesztésnél alkalmazható)
    \begin{center}
    \includegraphics[scale=0.8]{updown}
    \end{center}
    \item \textbf{Lentrol felfelé tesztelés:}\\
    A hierarchia alsó szintjein lévő modulok integrálásával és tesztelésével kezdik, ahol a magasabb szinteket tesztgenerátorok helyettesítik.(Inkrementális és újrafelhasználás alapú fejlesztésnél alkalmazható)
    \begin{center}
    \includegraphics[scale=0.70]{downup}
    \end{center}
\end{itemize}
A gyakorlatban a kettő kombinációját használják.\\
\textbf{Tesztelési stratégiák:}
\begin{itemize}
    \item \textbf{Szerkezeti validáció:}\\
    A fentről lefelé teszteléssel felfedhetők a hibák a rendszerarchitektúrában és a magas szintű tervekben, még a folyamat korai szakaszában. Ez a lentről felfelé tesztelésnél csak később lehetséges.
    \item \textbf{Rendszerdemonstráció:}\\
    A fentrol lefelé integráció korán lehetővé teszi a  korlátozott demonstrációt. Újrafelhasználható komponensek alkalmazásával a lentről felfelé megközelítéssel is lehetséges.
    \item \textbf{Tesztimplementáció:}\\
    A programcsonkokat nehéz implementálni, a lentről felfelé tesztelés tesztmeghajtóit valamivel egyszerűbb, de mindenképpen jelentős addicionális fejlesztést igényel.
    \item \textbf{Tesztmegfigyelés:}\\
    A tesztek eredményét mindkét módszernél nehéz megfigyelni. Mesterséges környezetre, extra kódra van szükség. Különösen a fentről lefelé megközelítésnél, ahol a magasabb szintek sokszor nem szolgáltatnak outputokat.
\end{itemize}

\section{Mi az interfésztesztelés, milyen hibákat lehet felfedni ilyen módon?}
\textbf{Interfésztesztelés:}
\begin{itemize}
    \item Interfésztesztelésre akkor van szükség, amikor egy nagyobb rendszer összeépítésekor modulokat vagy alrendszereket integrálunk. \item Az interfésztesztelés az objektumorientált fejlesztésnél fontos (különösen objektumok és osztályok újrafelhasználásakor), mert az objektumokat az interfészeikkel definiáljuk.
\end{itemize}
\textbf{Felderíthető hibák:}
\begin{itemize}
    \item Célja az interfészek specifikációs- (félreértések), vagy implementációs hibáinak felfedése.
\end{itemize}
 \textbf{Nem felderíthető hibák:}
 \begin{itemize}
     \item Egyedi objektum tesztelésével az interfészhibákat nem lehet felfedni. A hibák az objektumok közti interakciókban jelentkeznek, nem egy egyedi objektum sajátosságaiként.
 \end{itemize}
 
 \section{Melyek a tipikus interfészhibák? Milyen elveket kell alkalmazni az interfésztesztelés tervezésekor?}
 \textbf{Tipikus interfészhibák:}
 \begin{itemize}
     \item \textbf{Interfész hibás alkalmazása:}\\Egy hívó komponens hibája lehet: rossz típusú vagy sorrendű paraméterek, hibás számú paraméter, stb.

     \item \textbf{Interfész félreértése:}\\A hívó komponens hibásan értelmezi az interfészt, vagy a hívott komponens válaszait.

     \item \textbf{Időzítési hibák:}\\A hívó és a hívott komponens különböző sebességgel működik (osztott memória, vagy üzenettovábbító interfész esetén), és a hívott nem aktuális információt kap.
 \end{itemize}
 \textbf{Interfésztesztelés irányelvei:}
 \begin{itemize}
     \item A teszteket úgy kell tervezni, hogy a paraméterek értékei a határértékek közelében legyenek.

     \item A pointer jellegű paramétereket null értékkel is tesztelni kell.

     \item Olyan tesztesetet is tervezni kell, amely a hívott komponens hibáját okozza. (A specifikációs hibák többsége a hibák értelmezéséből fakad.)

     \item Üzenettovábbító, vagy interaktív rendszereknél terhelési (stressz) tesztet kell végrehajtani.

     \item Osztott memóriájú interfészeket a komponensek aktiválódása sorrendjének megváltoztatásával is tesztelni kell (szinkronizációs hibák).
 \end{itemize}
 %%89
 \section{Miért és miben különbözik az objektumorientált tesztelés a funkcióorientált rendszerek tesztelésétol?}
 \textbf{Objektumorientált tesztelés:}
 \begin{itemize}
     \item A komponens- és integrációs tesztelés az objektumorientált rendszereknél is alkalmazható.
     \item \textbf{Fontos különbségek:}
     \begin{itemize}
         \item A tesztelendő objektumok komponensként gyakran nagyobbak, mint az egyszerű függvények.(A fehér doboz tesztelés nehezebben alkalmazható.)
        \item Az objektumok lazán kötődnek, és a rendszernek/alrendszernek nincs egyértelmű teteje.
        \item Az újrafelhasznált komponensek kódjához nem mindig lehet hozzájutni, elemezni.
     \end{itemize}
 \end{itemize}
 \textbf{Megkülönböztetések:}
 \begin{itemize}
     \item \textbf{A funkcióorientált rendszereknél:}
     \begin{itemize}
         \item A rendszer alapvető program-egységei (függvények – modulok) jól elkülöníthetők,
         \item Ezek külön tesztelhetők.
     \end{itemize}
     \item \textbf{Az objektumorientált rendszerek esetén:}
     \begin{itemize}
         \item Az ilyen megkülönböztetés nem lehetséges, az objektumok lehetnek egyszerű ( pl. lista), vagy komplex entitások (pl. egy alrendszer objektumai),

         \item Olykor nincs egyértelmű hierarchia az objektumok között, ezért az integrációs tesztek (fentrol lefelé, vagy lentről felfelé) nem alkalmazhatók.

     \end{itemize}
 \end{itemize}
 
 %90
 
 \section{Milyen szinteket különböztethetünk meg az objektumorientált tesztelésben?}
 \begin{itemize}
    \item \textbf{Az objektumokhoz kapcsolódó műveletek tesztelése:}\\
    Függvények, vagy eljárások, fekete- vagy fehér doboz eljárással tesztelhetők.
    \item \textbf{Objektumosztályok tesztelése:}\\
    A fekete doboz eljárás alkalmazható, de az ekvivalencia-osztályokat a műveletsorozatokra is ki kell terjeszteni.

    \item \textbf{Együttműködő objektumcsoportok tesztelése:}\\
    Forgatókönyv alapján kijelölhető az objektumok csoportja.

    \item \textbf{Objektumorientált rendszer tesztelése:}\\
    A rendszerkövetelmények verifikációja és validációja más rendszerekhez hasonlóan történhet.
 \end{itemize}
 
 %91
 
 \section{Mi az objektumorientált csoporttesztelés? A rendszerterv milyen elemeit lehet felhasználni a csoportteszteléshez?}
 \textbf{Objektumorientált csoporttesztelés:}
 \begin{itemize}
    \item \textbf{Használati eset vagy forgatókönyv alapján:} A tesztek a felhasználói interakciókon alapulnak. Előnye, hogy a felhasználók által leggyakrabban használt részeket teszteli.
    \item \textbf{Száltesztelés:} A rendszernek egy eseményre adott válaszát vizsgálja, amint az a rendszeren keresztülhalad.
    \item \textbf{Objektum együttműködési teszt:} Az objektumok együttműködésének egy sorozatát vizsgálja, amely akkor ér véget, ha egy objektumművelet nem hív meg más objektumszolgáltatást.
 \end{itemize}
 \textbf{Elemek:}
 \TODO{TODO}
 \begin{itemize}
     \item Forgatókönyv alapján kijelölhető az objektumok csoportja.
 \end{itemize}
 %92
 
 \section{Mi a szoftver költségbecslés célja? Milyen kérdésekre keresi a választ?}
 \textbf{Kérdések:}
 \begin{itemize}
    \item Mekkora munkát igényel egy feladat elvégzése?
    \item Mennyi időbe kerül a feladat végrehajtása?
    \item Mennyi a tevékenység összes költsége?
 \end{itemize}
\textbf{Költségbecslés célja:}
Választ adni a következő költségelemekre a szoftverfejlesztési projekt során:
\begin{itemize}
    \item A hardver és szoftver költségei a karbantartással együtt,

    \item Utazási és képzési költségek,

    \item Munkaköltségek (bér, közteher, helység, kisegítő munkák, kommunikáció, rekreáció, ...)

\end{itemize}
%93
\section{Milyen módszereket ismer a szoftver költségének előzetes becslésére?}
\textbf{Funkciópontok:}
\begin{itemize}
    \item A program jellemzőinek kombinációján alapuló, nyelv-független módszer.
    \item \textbf{Méri az alábbi jellemzőket:}
    \begin{itemize}
        \item Külső bemenetek és kimenetek
        \item Felhasználói interakciók
        \item Külső interfészek
        \item A rendszer által használt fájlok
    \end{itemize}
    \item \textbf{Mindegyikhez súlyozási tényezőt rendel:}
    \begin{itemize}
    \item Egyszerű külső bemenet: 3
    \item Bonyolult belső állományok: 15
    \end{itemize}
    \item A súlyozási tényezőt egy szervezeten belül, hasonló jellegű szoftverek készítése során gyűjtött statisztikák alapján finomítja.
\end{itemize}
\textbf{A funkciópontok számítása:}
\begin{itemize}
    \item A funkciópontok (FP) alapján a kódsorok számára (LOC – Lines Of Code) lehet következtetni:
    \item LOC = AVC * FP ahol:\\AVC nyelvfüggő szorzófaktor (200-300 az assembly és 2-40 a 4GL nyelvekre)
    \item A funkciópont számítás nagyon sok szubjektív elemet tartalmaz.
    \item Automatikus számítása nem lehetséges, mert a specifikáció alapján kell a funkciópontokat megbecsülni.
\end{itemize}
\textbf{Objektumpontok:}
\begin{itemize}
    \item 4GL vagy más magas szintű nyelvek esetén a funkciópontok alternatívája. Magas szintű specifikáció alapján könnyebben becsülhető.
    \item Az objektumpont (NTC) nem azonos az objektumok számával, hanem az alábbiakból számítható:
    \begin{itemize}
        \item A külön megjelenítendő képernyők száma, az egyszerűtől (1), a nagyon bonyolultig (3),
        \item A készítendő jelentések száma (2 – 5 – 8)
        \item A 4GL kiegészítése miatt szükséges 3GL modulok száma (10)
    \end{itemize}
\end{itemize}
\newpage
\textbf{A termelékenység becslése:}
\begin{itemize}
    \item Valósidejű, beültetett rendszerek: 40 – 160 LOC / hó
    \item Rendszerprogramok: 150 – 400 LOC / hó
    \item Kereskedelmi alkalmazások: 200 – 800 LOC / hó
    \item Objektumpontban számolva a termelékenység 4 és 50 pont / hónap közötti, az eszköztámogatottságtól és a fejlesztők képességeitől függően.
\end{itemize}

%94
\section{Hogyan értelmezhető a szoftver minősége? Milyen tényezőkkel lehet a szoftverminőséget jellemezni?}
\textbf{A szoftver minősége:}
\begin{itemize}
    \item A minőség általában azt jelenti, hogy a termék megfelel specifikációjának.
    \item Mindenki mást ért minőség alatt:
    \begin{itemize}
        \item \textbf{A felhasználó:}
        „A szoftver azt végezze amit elvárok tőle, és úgy működjön ahogy én kívánom.” (Ebbe beleérti a gazdaságosságot, megbízhatóságot, stb. és a ki nem mondott elvárásokat is.)
        \item \textbf{A fejlesztő:}
        „A szoftver feleljen meg a specifikációnak”(Beleérti a karbantarthatóságot, újrafelhasználhatóságot, stb.)
    \end{itemize}
     \item \textbf{Az ISO definíciója:} „Annak mértéke, amennyire a szoftver tulajdonságai (a minőségi jellemzők) megfelelnek a követelményeknek.”\\
	De: mint tudjuk a szoftverkövetelmények gyakran nem teljesek és nem következetesek A szoftver specifikációját nehéz teljessé tenni, tehát a specifikációnak való megfelelés nem garantálja, hogy a felhasználó elégedett lesz a termékkel.
\end{itemize}
\textbf{Tényezők:}\\
\TODO{TODO}
 
%95 
 
 \section{Ismertesse egy szervezeten belül a minőségkezelés tevékenységeit!}
 \begin{itemize}
     \item \textbf{Minőségbiztosítás:} Szabványok és szervezeti eljárások alkalmazása.

     \item \textbf{Minőségtervezés:} Egy konkrét projekthez alkalmas eljárások és szabványok kiválasztása és adaptálása.

     \item \textbf{Minőségellenőrzés:} Annak biztosítása és ellenőrzése, hogy a fejlesztő csapat alkalmazza a minőségi szabványokat és eljárásokat.

     \item A minőségkezelés lehetőleg legyen független a projektvezetéstől.
 \end{itemize}
 
 %96
 
 \section{Miért fontosak a minőségi szabványok a szoftverkészítésben? Mi a termékszabvány és a folyamatszabvány közti különbség?}
 \textbf{Miért fontosak?}
 \begin{itemize}
     \item A szabványok adják a keretet a hatékony minőségkezeléshez.
        \item Lehetnek: nemzetközi-, nemzeti-, szervezeti- és projektszabványok.
        \item A szabványok a legjobb gyakorlat és a korábbi projektek hibáinak összegyűjtött adatai alapján készülnek.
    \item Kiterjednek a szoftvertervezés terminológiáira, programozási nyelvekre, jelölésrendszerre, programozási módszerekre, ellenőrzésre, validálásra.
    \item Folytonosságot biztosítanak egy változó szervezetben, az új résztvevők a helyi szabványok megismerésével hamarabb be tudnak kapcsolódni a munkába.

 \end{itemize}
 \textbf{Termékszabványok:}
 A termékszabványok olyan tulajdonságokat írnak elő, amelyek a termék minden elemére nézve kötelezőek:
     \begin{itemize}
         \item{Dokumentációs szabványok (pl. dokumentumok szerkezete)}
         \item Kódolási szabványok (programozási stílus, programnyelv használat)
     \end{itemize}
 \textbf{Folyamatszabványok:}
 A folyamatszabványok a szoftverfejlesztés alatt követendő folyamatokat határozzák meg (pl. a specifikáció, tervezés, stb. folyamata, módszerei, dokumentumai).

%97

\section{Mi az összefüggés a szoftverfolyamatok és az előállított szoftver minősége között?} 
 \begin{itemize}
     \item A termék minősége alapvetően függ az előállítása során alkalmazott folyamatok minőségétől (pl. iparszerű gyártásnál).
    \item Ez a szoftverfejlesztésnél is így van, de sok minőségi jellemző nehezen mérhető, számszerűsíthető.
    \item Ugyanakkor a szoftvert egyedileg tervezik, a szoftverfejlesztés nem mechanikus folyamat.

    \item A szoftverfejlesztés folyamata és a termék minősége között erős összefüggés van, de ez nagyon összetett és alig megfogható.
 \end{itemize}
 \textbf{Összefüggés a szoftverfolyamatok és az előállított szoftver minősége között:}
 \\Szoftvernél ez nem ilyen egyszerű mert:
 \begin{itemize}
     \item A szoftverfejlesztésben az egyéni képzettség és gyakorlat különösen fontos.
    \item Külső tényezők, mint az alkalmazás újszerűsége, vagy a piacra vitel siettetése, befolyásolják a minőséget.

 \end{itemize}

 %% GYERE INNEN ÁDÁM 98-as tétel 11-es diasor
 %%JÖVÖK
 %98
 
 \section{Mi a minőségi felülvizsgálat célja, milyen termékekre terjedhet ki?}
 Elterjedt módszer a folyamatok és a termékek minőségének ellenőrzésére.
 Szakértők egy csoportja figyelmesen átvizsgálja a szoftver komponenseit, a teljes szoftvert és a dokumentációkat. Átnézik a specifikációkat, terveket, kódot, tesztterveket. Az eredményes felülvizsgálat a szoftver vagy a dokumentáció elfogadását jelenti. Az észrevételek kijavítása után újabb felülvizsgálatra kerülhet sor. A vezetés a felülvizsgálatok eredményei alapján követheti a projekt előrehaladását.\\
  \textbf{Felülvizsgálat típusai:}
  \begin{itemize}
      \item A terv vagy a program vizsgálata, mint a V&V esetén (a termék minőségét vizsgálja)
      \item Az előrehaladás vizsgálata (a folyamat és a termék minőségét vizsgálja)
      \item  A minőség vizsgálata (a folyamat és a termék minőségét vizsgálja)
  \end{itemize}
  
  %99
  
  \section{Mire szolgál a szoftver mérése? Mondjon néhány példát a mérhető szoftverjellemzőkre!}
  A szoftver mérés számszerűsíthető értékeket állít elő a szoftvertermék vagy –folyamat jellemzőiből.
  Célja a technikák és folyamatok objektív összehasonlítása, a minőség mérése.\\
  \textbf{Mérhető szoftverjellemzők:}
  \begin{itemize}
    \item Biztonságosság
    \item Biztonság
    \item Megbízhatóság
    \item Rugalmasság
    \item Robusztusság
    \item Érthetőség
    \item Tesztelhetőség
    \item Adaptálhatóság
    \item Modularitás
    \item Komplexitás Hordozhatóság
    \item Használhatóság
    \item Újrafelhasználhatóság
  \end{itemize}
  
  %100
  
 \section{Ismertesse a CMM (Capability Maturity Model) célját és lényegét!}
 A CMM - Capability Maturity Model a szervezet folyamatainak alkalmasságát méri, osztályozza és értékeli.\\
 \textbf{A CMM-modell szintjei: }
 \begin{itemize}
     \item{\textbf{Kezdeti:}} Nincsenek hatékony vezetési eljárások, vagy hiányzik a szervezet azok következetes alkalmazására.
     \item{\textbf{Ismételhető: }}Azonos típusú projektekben ismételve a vezetési, minőségbiztosítási és változáskezelési eljárásokat sikeres lehet (a siker egyéni teljesítményektől függ).
     \item{\textbf{Meghatározott:} }A folyamatokat már definiálták, de a vezetési folyamatok még nem tudják azokat következetesen, maradéktalanul biztosítani.
     \item{\textbf{Menedzselt: }}Már vannak definiált és bevezetett folyamatok, de azok folyamatos fejlesztése még nem biztosított.
     \item{\textbf{Optimalizált:} }A folyamatok állandó fejlesztése definiált és biztosított.
 \end{itemize}
 
 \section{Miért fontos a szoftver költségeinek becslése? Milyen tényezőket vehetünk figyelembe a költségbecslés során?}
 \textbf{Becslést adhatunk arra, hogy:}
 \begin{itemize}
     \item Mekkora munkát igényel egy feladat elvégzése
     \item Mennyi időbe kerül a feladat végrehajtása
     \item Mennyi a tevékenység összes költsége
 \end{itemize}
 \textbf{Figyelembe vehetjük a:}
 \begin{itemize}
    \item Piaci lehetőségeket
    \item A költségbecslés bizonytalanságait
    \item A szerződéses feltételeket
    \item A követelmények változékonyságát
    \item A fejlesztő gazdasági helyzetét
 \end{itemize}

%%%% DALAD !!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!
\newpage
  %102
 \section{Ismertesse a COCOMO II. költségbecslési módszer modelljeit!}
 \begin{itemize}
     \item Empirikus modell, a projektek gyakorlatából gyűjtött adatokon alapul.
    \item Jól dokumentált, hosszú tapasztalat áll mögötte (első verzió: 1981)
 \end{itemize}
  \textbf{A COCOMO 2 háromszintű modellje:}
  \begin{itemize}
      \item \textbf{Korai prototípuskészítés szintje:} Becslés objektumpontok alapján
      \item \textbf{Korai tervezés szintje:} Funkciópontok alapján a forráskódok számát becsli
      \item \textbf{Poszt-architekturális szint:} Az architektúra terv elkészülte után becsli a szoftver méretét
  \end{itemize}
  \textbf{Korai prototípukészítés szintje:}
  \begin{itemize}
      \item Prototípuskészítést és újrafelhasználást is figyelembe vesz.
        \item A fejlesztői produktivitást objektumpontokkal számolja és a CASE használatot is bekalkulálja.
    \item A formula:  
    \[PM = (NOP * (1 - \%reuse)) / PROD\]\\
    Ahol: PM – a munka emberhónapban, NOP – az objektumpontok száma, PROD - produktivitás
  \end{itemize}
  \begin{center}
  \includegraphics[scale=0.8]{koraiprototipus}
  \end{center}
  \textbf{Korai tervezési szint:}
  \begin{itemize}
      \item A követelmények tisztázása után végezhető a becslés.
    \item Az alábbi képlettel számol:
    \[ PM = A * Méret^B * M + PM_m \] \\
    Ahol: M=PERS*RCPX*RUSE*PDIF*PREX*FCIL*SCED\\
    \[PM_m= (ASLOC*(AT/100))/ATPROD\]\\
    A = 2,5 a kezdeti számításban
    \\B = 1,1 – 1,24 a projekt mérete, újdonsága függvényében.
    \\M = projekttényezők:\\PERS – személyi képességek,\\RCPX – termék megbízhatóság,\\RUSE – szükséges újrafelhasználás,\\PDIF – platform nehézségei\\PREX – személyek gyakorlata,\\FCIL – támogató eszközök,\\SCED – ütemezés\\ASLOC = automatikusan generált kódsorok, \\AT = aut. rendszerkód,\\ATPRO = termelékenység, 
  \end{itemize}
  \textbf{Poszt-architekturális szint:}
  \begin{itemize}
      \item Ugyanazt a formulát alkalmazza, mint a korai tervezési becslés, de két tényezőt figyelembe vesz:
      \begin{itemize}
          \item A követelmények változékonysága,
        \item A lehetséges újrafelhasználás mértéke.

      \end{itemize}
        \item A szükséges új kódsorok számának becslésekor statisztikai és egyéb értékeket is figyelembe vesz, mint:
\begin{itemize}
    \item A korábbi hasonló projektek hiánya,
    \item A fejlesztés rugalmassága,
    \item A csapat összetartása,
    \item A folyamat fejlettsége.
\end{itemize}
  \end{itemize}

\section{Források:}
\begin{itemize}
    \item Vető István 2016-os előadás és gyakorlati diái.
    \item Egyéb webes jegyzetek.
    \item 2007-es tétel kidolgozás:\\ https://wiki.itk.ppke.hu/twiki/pub/PPKE/SzoftvertechnológiaAlapjai/Vizsgatetelek07\_szerk.pdf
\end{itemize}
  
\end{document}
