Az esetek többségében a szabványos ellenőrzési módszertan hiánya jelent akut gondot. Így előfordulhat, hogy a tervezésből fakadó hiányosságok csak a fejlesztés előrehaladtával derülnek ki.
Ennek pedig komoly ára van, hiszen rossz esetben akár az alkalmazás teljes áttervezését is eredményezheti. A lehető legrosszabb eset pedig az, amikor a rossz design alapján folytatódik és fejeződik be a project.
Pedig egy logikus követelményrendszer alapján létrehozható egy elég rövid lista, amely az ellenőrzés alapját képezheti.
A lényeges minőségi szempontok az alkalmazásterv elkészítésekor, illetve ellenőrzésekor:
* teljesítmény
Homokóra, homokóra, kill process.. pedig csak töltögetett!
* biztonság
User: Administrator
Pwd: admin
Ha ezekkel be lehet lépni, akkor nagy gáz van. (Egy áruházban sikerült belépnem a kiállított gépre adminisztrátorként, a jelszó hogy, hogy nem az áruház neve volt. :-D)
* megbízhatóság
Végletek: már attól lefagy, ha véletlenül nevet írunk be a házszám helyére / alaplapot cserélhetsz a gépben, akkor is tovább működik ;-)
* rendelkezésre állás
Más elvárások vannak egy egyfelhasználós, desktop alkalmazás esetében, és megint más egy elosztott környezetbe szánt, több száz felhasználó által napi 24 órán át igénybe vett rendszer esetében.
* kezelhetőség, használhatóság
Gondoljunk az iPhone / iPod Touch-ra.
* különböző nyelvek támogatása
(Ne) gondoljunk a DVD-játékosra...
Az elvárások súlya szoftverspecifikus, ezért lényeges mérlegelni és megfelelő döntéseket hozni már a terv korai szakaszában. Például másként ítéljük meg a biztonságot egy online banki rendszer esetében, mint egy képszerkesztő alkalmazás esetében. A megbízhatóság kritikusabb egy orvosi alkalmazásnál, mint egy játékszoftvernél, és még sorolhatnám.
ATAM
Az ATAM (Architecture Tradeoff Analysis Method) design elemző módszertan a fejlesztési ciklus korai szakaszában felfedezi a kritikus pontokat, és lehetővé teszi az architektúra idejében történő, kevésbé fájdalmas és költséges megváltoztatását.
Az ATAM előnyei:
- kikényszeríti a precízen megfogalmazott minőségi elvárások definiálását
- az architektúra dokumentáció már a korai szakaszban is rendelkezésre áll
- az architekturális döntéseket írásba foglalja
- garantálja a problémás pontok korai felderítését
- biztosítja a kommunikációt a szereplők között (SM, architectek, megrendelők)
Az ATAM folyamatosan bevonja az érdekelt feleket az üzleti igények és minőségi elvárások definiálásába, amelyekből úgynevezett esetleírások születnek. Utóbbiak az architekturális döntések és módszerekkel egyetemben biztosítják a korai problémafeltárást, az esetleges kompromisszumos megoldások megtalálását és legfőképpen a sarkalatos minőségi elvárások felderítését, súlyozását.
A folyamat lépései
1.) a módszertan ismertetése a szereplőkkel
2.) az üzleti elvárások megbeszélése közösen – mindenki a saját szemszögéből mutatja be
3.) Architektúrális megközelítések megtárgyalása a csapattal
4.) Architekturális döntések megvitatása a csapattal
5.) Minőségi elvárások összerendelése az alkalmazástervvel (üzleti és technológiai oldalról egyaránt)
6.) Architekturális módszerek és technológiák elemzése, az alkalmazott funkcionalitás függvényében. Prioritizálás
7.) Terv bemutatása a többi szereplő bevonásával, brainstorming
8.) Az előző lépés eredményei alapján a 6. pont megismétlése
Eredmények bemutatása, dokumentáció átadása a stakeholder-eknek
| < Előző | Következő > |
|---|
