V-модель (бағдарламалық жасақтама жасау) - V-Model (software development)

Жүйелік инженерлік процестің V-моделі.[1]
Бағдарламалық жасақтама жасау
Негізгі қызмет
Парадигмалар мен модельдер
Әдістемелер және шеңберлер
Қолдау пәндері
Тәжірибелер
Құралдар
Стандарттар және білім органдары
Глоссарийлер
Контурлар

Жылы бағдарламалық жасақтама жасау, V-модель[2] білдіреді даму процесі кеңейту деп санауға болады сарқырама моделі, және басқалардың мысалы болып табылады жалпы V-модель. Төмен сызықтық жолмен жылжудың орнына, процестің қадамдары кейін жоғары қарай бүгіледі кодтау типті V формасын қалыптастыру үшін фаза. V-модель дамудың өмірлік циклінің әр фазасы мен оның байланысты фазасы арасындағы байланысты көрсетеді тестілеу. Көлденең және тік осьтер сәйкесінше уақытты немесе жобаның толықтығын (солдан оңға) және абстракция деңгейін (ең үлкен-түйіршікті абстракция) көрсетеді.

Жобаны анықтау кезеңдері

Талаптарды талдау

Ішінде талаптарды талдау фаза, тексеру процесінің алғашқы қадамы, талаптар жүйенің қажеттіліктерін талдау арқылы жиналады пайдаланушы (лар). Бұл кезең идеалды жүйенің не істеу керектігін анықтаумен байланысты. Алайда бұл бағдарламалық жасақтаманың қалай жасалатынын немесе жасалатынын анықтамайды. Әдетте, пайдаланушылармен сұхбат жүргізіліп, пайдаланушы талаптары деп аталатын құжат жасалады.

Пайдаланушының талаптары туралы құжат әдетте жүйенің функционалдық, интерфейсі, өнімділігі, деректері, қауіпсіздігі және т.б. талаптарын пайдаланушы күткендей сипаттайды. Оны бизнес-талдаушылар қолданушыларға жүйе туралы түсініктерін жеткізу үшін қолданады. Пайдаланушылар бұл құжатты мұқият қарастырады, өйткені бұл құжат жүйені жобалау кезеңінде жүйелік дизайнерлер үшін нұсқаулық бола алады. Пайдаланушыны қабылдау тестілері осы кезеңде жасалған. Сондай-ақ қараңыз Функционалды талаптар.

Жұмсақ және қатты әдіснамалардың талаптарын жинаудың әр түрлі әдістері бар, соның ішінде; сұхбат, сауалнама, құжаттарды талдау, бақылау, лақтыратын прототиптер, регистрді қолдану пайдаланушылармен статикалық және динамикалық көріністер.

Жүйенің дизайны

Жүйелерді жобалау жүйелік инженерлер пайдаланушының талаптары туралы құжатты зерделеу арқылы ұсынылатын жүйенің бизнесін талдайтын және түсінетін кезең. Олар пайдаланушының талаптарын жүзеге асырудың мүмкіндіктері мен тәсілдерін анықтайды. Егер қандай да бір талаптар орындалмаса, пайдаланушыға мәселе туралы хабарлайды. Шешім табылды және пайдаланушының талап құжаты сәйкесінше өңделеді.

Даму кезеңі бойынша жоспар ретінде қызмет ететін бағдарламалық жасақтаманың техникалық құжаты жасалады. Бұл құжатта жүйенің жалпы ұйымдастырылуы, мәзір құрылымдары, мәліметтер құрылымы Мұнда сонымен қатар іскерлік сценарийлер, терезелер үлгісі және түсінуге көмектесетін есептер болуы мүмкін. Сондай-ақ, осы кезеңде құрылымдық диаграммалар, мәліметтер сөздігі сияқты басқа техникалық құжаттар жасалады. Жүйелік тестілеуге құжаттар дайындалды.

Сәулет дизайны

Жобалау кезеңі компьютерлік архитектура және бағдарламалық жасақтама архитектурасы жоғары деңгейлі дизайн деп те атауға болады. Архитектураны таңдаудың негізі мынада: ол модульдер тізімінен тұратын барлық нәрсені, әр модульдің қысқаша функционалдығын, олардың интерфейс қатынастар, тәуелділіктер, дерекқор кестелер, сәулет диаграммалары, технологиялық бөлшектер және т.б. интеграциялық тестілеу дизайны белгілі бір кезеңде жүзеге асырылады.[3]

Модуль дизайны

The модуль дизайны фазаны төменгі деңгейлі дизайн деп те атауға болады. Жобаланған жүйе кішігірім блоктарға немесе модульдерге бөлінеді және олардың әрқайсысы бағдарламалаушы кодтауды тікелей бастай алатындай етіп түсіндіріледі. Төмен деңгейдегі жобалау құжаты немесе бағдарламаның ерекшеліктері егжей-тегжейлі функционалды логикадан тұрады. модуль, жылы псевдокод:

  • мәліметтер базасының кестелері, барлық элементтері, олардың түрлері мен өлшемдерін қосқанда
  • барлық интерфейс туралы толық мәліметтер API сілтемелер
  • барлық тәуелділік мәселелері
  • қате туралы хабарлама листингтер
  • модуль үшін толық енгізу және шығару.

Бұл кезеңде қондырғының сынақ дизайны жасалады.

Тексеру кезеңдері

V-модельде тексеру кезеңінің әр кезеңінде валидация кезеңінде сәйкес сатысы болады.[4] Төменде V-модельдегі валидацияның типтік кезеңдері келтірілген, бірақ олар басқа атаулармен белгілі болуы мүмкін.

Бірлікті сынау

V-модельде модульді жобалау кезеңінде блоктың сынақ жоспарлары (UTP) жасалады. Бұл UTP код деңгейінде немесе бірлік деңгейінде қателерді жою үшін орындалады. Бірлік дегеніміз - дербес өмір сүре алатын ең кіші құрылым, мысалы. бағдарлама модулі. Бірлік тестілеу басқа кодтардан / бірліктерден оқшауланған кезде ең кіші ұйымның дұрыс жұмыс істей алатындығын тексереді.

Интеграциялық тестілеу

Сәулетті жобалау кезеңінде интеграциялық тест жоспарлары жасалады. Бұл сынақтар тәуелсіз құрылған және сыналған бірліктердің қатар өмір сүре алатындығын және өзара байланыс жасай алатындығын тексереді. Тест нәтижелері тапсырыс берушілер тобымен бөлісіледі.

Жүйелік тестілеу

Жүйелік тестілеу жоспарлары жүйені жобалау кезеңінде жасалады. Бірлік пен интеграциялық тест жоспарларынан айырмашылығы, жүйелік тестілеу жоспарларын клиенттің іскери тобы құрайды. Жүйелік тест қосымшадан үміттердің орындалуын қамтамасыз етеді. Барлық бағдарлама функционалдығы, өзара тәуелділігі және байланысы үшін тексеріледі. Жүйелік тестілеу функционалды және функционалды емес талаптардың орындалғанын тексереді. Жүктеме мен өнімділікті сынау, стресс-тестілеу, регрессиялық тестілеу және т.б. - жүйелік тестілеудің ішкі жиынтығы.

Пайдаланушыны қабылдауды тексеру

Пайдаланушыны қабылдау тесті (UAT) жоспарлары Талаптарды талдау кезеңінде жасалады. Тест жоспарларын бизнес пайдаланушылар жасайды. UAT нақты деректерді қолдана отырып, өндірістік ортаға ұқсас пайдаланушы ортасында жүзеге асырылады. UAT жеткізілген жүйенің пайдаланушының талаптарына сәйкес келетіндігін және жүйенің нақты уақыт режимінде пайдалануға дайын екендігін тексереді.

Сын

V-модель сынға ұшырады Шапшаң адвокаттар және басқалар көптеген себептерге байланысты бағдарламалық жасақтаманың жеткіліксіз моделі ретінде.[5][6][7] Сынға мыналар жатады:

  1. Бағдарламалық жасақтаманы әзірлеу процесін дәл көрсету өте қарапайым және менеджерлерді жалған қауіпсіздік сезімін тудыруы мүмкін. V-модель бағдарламалық жасақтаманы жобалауды басқару көрінісін бейнелейді және бағдарламалық жасақтама жасаушыларға немесе пайдаланушыларға емес, жоба менеджерлеріне, бухгалтерлерге және заңгерлерге сәйкес келеді.
  2. Жаңадан бастаушылар оны оңай түсінгенімен, егер жаңадан бастаушы даму үдерісі туралы және V-моделін іс жүзінде қалай бейімдеп кеңейту керек болса, соны түсіну пайдалы болады. Егер тәжірибешілер V-модельге деген өздерінің аңғалдық көзқарастарын сақтаса, оны сәтті қолдануда үлкен қиындықтар туындайды.
  3. Бұл икемді емес және бағдарламалық жасақтаманың қатаң және сызықтық көрінісін қолдайды және өзгеріске жауап берудің ерекше қабілеті жоқ.
  4. Бұл тек шамалы нұсқаны ұсынады сарқырама моделі сондықтан сол модель сияқты сынға ұшырайды. Бұл тестілеуге үлкен мән береді, әсіресе тестілеуді ерте жоспарлаудың маңыздылығы. Алайда, V-модельдің жиі кездесетін практикалық сыны - бұл дамудың соңында алдыңғы кезеңдер асып кетсе де, енгізу мерзімі анықталған кезде тестілеуді қатаң терезелерге қысуға әкеледі.
  5. Бұл тестілеудің тиімсіз және тиімсіз тәсілдеріне сәйкес келеді, сондықтан жанама түрде ынталандырады. Бұл іздеу тестілеуінен гөрі алдын-ала тест сценарийлерін жазуға ықпал етеді; бұл тестерлерді шынымен бар нәрсені ашудан гөрі, өздері күткен нәрсені іздеуге шақырады. Сонымен қатар, бұл тестерлерді тестілеуді жоспарлау мен орындаудың тиімді және тиімді әдісін таңдауға шақырудан гөрі, екі аяғының эквивалентті деңгейлері арасындағы қатаң байланысқа итермелейді (мысалы, пайдаланушының талаптарын тексеру құжаттарының жоспарлары).
  6. Оған келісімділік пен дәлдік жетіспейді. V-модельдің нақты қандай екендігі туралы көптеген шатасулар бар. Егер мұны көптеген адамдар келісетін элементтермен байланыстырса, бұл бағдарламалық жасақтаманы дамытудың пайдасыз көрінісі болады. V-модельдің артықшылықтары туралы келіспеушіліктер көбінесе оның анықтамасын түсінудің жетіспейтіндігін көрсетеді.

Ағымдағы күй

V-модельдің жақтаушылары оның уақыт өте келе дамығанын және бүкіл даму процесінде икемділік пен ептілікті қолдайтындығын айтады.[8] Олардың пікірінше, бұл өте тәртіпті тәсіл болумен қатар, тұрақты бағдарламалық жасақтама өнімдерін құру үшін қажетті мұқият жобалауға, әзірлеуге және құжаттамаға ықпал етеді. Соңғы кездері оны медициналық бұйымдар өндірісі қабылдап жатыр.[9][10]

Сондай-ақ қараңыз

Әдебиеттер тізімі

  1. ^ Clarus операциялық тұжырымдамасы. Мұрағатталды 2009-07-05 сағ Wayback Machine № FHWA-JPO-05-072 басылымы, Федералды автомобиль жолдары басқармасы (FHWA), 2005 ж
  2. ^ Кевин Форсберг және Гарольд Муз, «Жүйелік инженерияның жобалық циклмен байланысы», Жүйелік инженерия бойынша Ұлттық кеңестің бірінші жылдық симпозиумының материалдарында, 1991 ж. Қазан: 57–65.
  3. ^ V модель дегеніміз не - артықшылығы, кемшілігі және оны қашан қолдану керек
  4. ^ ДеСпауц, Джозеф; Ковач Кеннет С. Герхард Верлинг (11 наурыз 2008). «Автоматтандырылған жүйелерді растауға арналған GAMP стандарттары». Фармацевтикалық өңдеу. Архивтелген түпнұсқа 8 мамыр 2012 ж. Алынған 28 ақпан 2012.
  5. ^ «V-модельдің өлімі», қол жеткізілді 6 қаңтар 2013 ж
  6. ^ «Қауіпті және еліктіргіш V модель», қол жеткізілді 6 қаңтар 2013 ж
  7. ^ «Тест әзірлеуге арналған жаңа модельдер», қол жеткізілді 6 қаңтар 2013 ж
  8. ^ «Жылдам жүйелердің инженерлік процестеріне қарай», қол жеткізілді 6 қаңтар 2013 ж
  9. ^ «Медициналық құрылғыларға арналған бағдарламалық жасақтама жасау кезінде ептілік тәжірибесін қабылдаудағы кедергілер»
  10. ^ «Медициналық бұйымдар өндірісі үшін бағдарламалық жасақтаманы әзірлеу, бағалау және жетілдіру шеңбері»

Әрі қарай оқу

  • Роджер С. Прессман:Бағдарламалық жасақтама: тәжірибешінің тәсілі, McGraw-Hill компаниялары, ISBN  0-07-301933-X
  • Марк Хоффман және Тед Бомонт: Қосымша әзірлеу: Жобаның өмірлік циклін басқару, Mc Press, ISBN  1-883884-45-4
  • Борис Бейзер: Бағдарламалық жасақтаманы тестілеу әдістері. Екінші басылым, Халықаралық Thomson Computer Press, 1990 ж., ISBN  1-85032-880-3

Сыртқы сілтемелер