Кіріспе
Бағдарламалық жасақтаманы әзірлеу үрдісі моделі
Спиральді модель – тәуекелге бағытталған бағдарламалық жасақтаманы әзірлеу үрдісі моделі. Нақты жобаның ерекше тәуекел факторларына сүйене отырып, спиральді модель команданы бір немесе бірнеше үрдіс модельдерінің элементтерін пайдалануға бағыттайды, мысалы, итеративтік, каскадтық немесе эволюциялық прототиптеу.
Тарих
Бұл модельді алғаш рет Барри Боем 1986 жылғы "Бағдарламалық құралды әзірлеу және жетілдірудің спиральді моделі" атты мақаласында сипаттады. 1988 жылы Боем осыған ұқсас мақаланы кең аудиторияға жариялады. Бұл мақалаларда спиральді модельді талқылайтын көптеген кейінгі басылымдарда көшірілген диаграмма ұсынылған. Бұл алғашқы мақалалар спиральді модельді, сондай-ақ итеративті, каскадтық, прототиптеу және басқа да тәсілдерді атау үшін "процесс моделі" терминін қолданады. Дегенмен, спиральді модельдің басқа процесс модельдерінің ерекшеліктерін тәуекелге негізделген үйлесімде біріктіруі бар: спиральді модельдің қадамдарының тәуекелге негізделген бөлігі модельге нақтыланған, прототипке негізделген, симуляцияға негізделген, автоматты түрлендіруге негізделген немесе бағдарламалық құралды әзірлеуге басқа да тиісті тәсілдердің кез келген қоспасын қабылдауға мүмкіндік береді. Бұл модель адамдармен байланысты тәуекелдерді де қамтитын болды. Оларды "қауіпті спиральді имитациялардан" жақсырақ ажырату үшін Боем спиральді модельдің барлық нақты қолданылуына тән алты қасиетті тізімдейді.
quotation|[R]isk driven subsetting of the spiral model steps allows the model to accommodate any appropriate mixture of a specification oriented, prototype oriented, simulation oriented, automatic transformation oriented, or other approach to software development. this model was extended to include risks related to human users. To better distinguish them from "hazardous spiral look alikes," Boehm lists six characteristics common to all authentic applications of the spiral model.
Спиральді модельдің алты инварианты
Шілпелі модельдің нақты қолданылуы алты қасиетті міндетті түрде көрсететін циклдармен жүзеге асырылады. Боем әрбір қасиетті инвариантты бұзатын "қауіпті спиральға ұқсас" мысалмен түсіндіреді.
Артефактілерді бір уақытта анықтау
Жобаның негізгі артефакттарын ретті түрде анықтау мүдделі тараптардың "жеңіс шарттарына" (мақсаттар мен шектеулерге) сай келетін жүйені жасау мүмкіндігін көбінесе арттырады. Бұл өзгермейтін қағида, су тасқыны моделінің негізгі болжамдары қолданылмайтын жағдайларда, су тасқынының бірнеше кезеңін тізбектей қолданатын "қауіпті спиральға ұқсас" процестерді жоққа шығарады. Боем осы болжамдарды былай тізімдейді:
Талаптар жүзеге асыру алдында белгілі болуы керек. Талаптарда шешілмеген, жоғары тәуекел тудыратын мәселелер болмауы керек, мысалы, шығын, кесте, өнімділік, қауіпсіздік, пайдаланушы интерфейсі, ұйымдық әсерлер және т.б. Талаптардың мәні даму немесе эволюция барысында көп өзгермейді. Бұл талаптар жүйеге қатысты барлық негізгі тараптардың – пайдаланушылардың, тапсырыс берушілердің, әзірлеушілердің, техникалық қызмет көрсетушілердің және инвесторлардың – күтулеріне сай келуі керек. Талаптарды жүзеге асыру үшін дұрыс архитектура жақсы түсінілуі керек. Ретті түрде жұмыс істеу үшін жеткілікті уақыт болуы керек. Осы болжамдар орындалатын жағдайларда, талаптарды нақты айқындамай, ретті түрде жұмыс істемеу жоба үшін тәуекел тудырады. Осылайша, су тасқыны моделі спиральді модельдің тәуекелге негізделген ерекше жағдайы болып табылады.
The requirements are known in advance of implementation. The requirements have no unresolved, high risk implications, such as risks due to cost, schedule, performance, safety, user interfaces, organizational impacts, etc. The nature of the requirements will not change very much during development or evolution. The requirements are compatible with all the key system stakeholders’ expectations, including users, customer, developers, maintainers, and investors. The right architecture for implementing the requirements is well understood. There is enough calendar time to proceed sequentially. In situations where these assumptions do apply, it is a project risk not to specify the requirements and proceed sequentially. The waterfall model thus becomes a risk driven special case of the spiral model.
Тәуекел - күш-жігердің деңгейін анықтайды
Жобаның кез келген іс-әрекеті үшін (мысалы, талаптарды талдау, жобалау, прототиптеу, сынақтан өткізу) жобалық команда қанша еңбек қажет екенін анықтауы керек. Нақты спиральді процестің циклдарында бұл шешімдер жалпы тәуекелді азайту арқылы қабылданады. Мысалы, бағдарламалық өнімді сынауға жұмсалатын қосымша уақыт, нарықтың нашар сапалы өнімді қабылдамауына байланысты тәуекелді азайтуы мүмкін. Дегенмен, қосымша сынақ уақыты бәсекелестің ертерек нарыққа енуіне байланысты тәуекелді арттыруы мүмкін. Спиральді модель тұрғысынан алғанда, сынақтар жалпы тәуекел ең төменгі деңгейге жеткенше жүргізілуі керек, одан артығы қажет емес. Бұл қағиданы бұзатын "қауіпті спиральге ұқсас" процестерге масштабталу мәселелерін ескермейтін эволюциялық процестер, сондай-ақ өнімнің болашақ кеңеюіне бейімделу үшін қайта жобалануы немесе алмастырылуы тиіс техникалық архитектураға көп инвестиция салатын инкременттік процестер жатады.
Тәуекел нақтылылықты анықтайды
Жобаның кез келген артефактісі (мысалы, талаптардың сипаттамасы, жобалау құжаты, сынақ жоспары) үшін жоба тобы қаншалықты толық болу керектігін шешуі керек. Нақты спиральді процестің циклдарында бұл шешімдер жалпы тәуекелді азайту арқылы қабылданады. Мысал ретінде талаптардың сипаттамасын қарастыратын болсақ, жобада нақты сипаттама арқылы тәуекел азайтылатын мүмкіндіктер нақты көрсетілуі тиіс (мысалы, аппараттық және бағдарламалық құралдар арасындағы интерфейстер, бас мердігерлер мен қосалқы мердігерлер арасындағы интерфейстер). Керісінше, жобада нақты сипаттама тәуекелді арттыратын мүмкіндіктер нақты көрсетілмеуі керек (мысалы, графикалық экранның макеті, жарыққа қойылған компоненттердің әрекеттері).
Тірек нүктелерінің белдеулерін қолдану
Боемнің спиральді модельді бастапқы сипаттамасында процестің ешқандай кезеңдері болмаған. Кейінгі жетілдірулерде ол үш негізгі кезеңді енгізді, олар прогрестің көрсеткіштері және міндеттемелердің белгілері ретінде қызмет етеді. Бұл негізгі кезеңдер маңызды сұрақтармен сипатталады. Өмірлік цикл мақсаттары. Барлық тараптардың жеңіске жету шарттарын қанағаттандыру үшін техникалық және басқару тәсілі жеткілікті түрде анықталған ба? Егер мүдделі тараптар «Иә» деп жауап берсе, жоба осы Өмірлік цикл мақсаттары (LCO) кезеңін аяқтаған болады. Әйтпесе, жобадан бас тартуға болады немесе мүдделі тараптар «Иә» деген жауап алу үшін тағы бір циклға кірісуі мүмкін. Өмірлік цикл архитектурасы. Барлық тараптардың жеңіске жету шарттарын қанағаттандыру үшін таңдалған тәсіл жеткілікті түрде анықталған ба және барлық маңызды тәуекелдер жойылған немесе азайтылған ба? Егер мүдделі тараптар «Иә» деп жауап берсе, жоба осы Өмірлік цикл архитектурасы (LCA) кезеңін аяқтаған болады. Әйтпесе, жобадан бас тартуға болады немесе мүдделі тараптар «Иә» деген жауап алу үшін тағы бір циклға кірісуі мүмкін. Бастапқы операциялық мүмкіндік. Бағдарламалық қамтамасыз ету, орынжай, пайдаланушылар, операторлар және техникалық қызмет көрсетушілер жүйе іске қосылғанда барлық тараптардың жеңіске жету шарттарын қанағаттандыру үшін жеткілікті дайындықпен қамтамасыз етілген бе? Егер мүдделі тараптар «Иә» деп жауап берсе, жоба Бастапқы операциялық мүмкіндік (IOC) кезеңін аяқтап, іске қосылады. Әйтпесе, жобадан бас тартуға болады немесе мүдделі тараптар «Иә» деген жауап алу үшін тағы бір циклға кірісуі мүмкін. Осы қағидаға қайшы келетін «қауіпті спираль тәріздес» процестерге эволюциялық және инкременттік процестер жатады, олар нашар анықталған архитектурасы бар шешімді іске асыруға маңызды ресурстарды жұмсайды. Үш негізгі кезең оңай ұтымды біріктірілген процеске (RUP) оңай сәйкес келеді, LCO RUP-тің бастапқы және әзірлеу кезеңдерінің арасындағы шекараны белгілейді, LCA әзірлеу және құрылыс кезеңдерінің арасындағы шекараны белгілейді, ал IOC құрылыс және ауысу кезеңдерінің арасындағы шекараны белгілейді.
Жүйе мен оның өмірлік циклына назар аударыңыз
Бұл инвариант тұтас жүйенің маңыздылығын және оның өмірлік циклі бойына созылатын ұзақ мерзімдік мәселелерді атап көрсетеді. Ол бағдарламалық кодты бастапқы дамытуға тым көп назар аударатын, "қауіпті спиральға ұқсас" жағдайларды ескермейді. Мұндай процестер жобаның процестік қажеттіліктерінің басқа аспектілерін назардан тыс қалдырып, объектіге бағытталған немесе құрылымдық бағдарламалық жасақтаманы талдау және жобалау бойынша жарияланған тәсілдерді қолдану нәтижесінде туындауы мүмкін.