Бағдарламалық жасақтама прототипі - Software prototyping

Бағдарламалық жасақтама жасау
Негізгі қызмет
Парадигмалар мен модельдер
Әдістемелер және шеңберлер
Қолдау пәндері
Тәжірибелер
Құралдар
Стандарттар және білім органдары
Глоссарийлер
Контурлар

Бағдарламалық жасақтама прототипі құру қызметі болып табылады прототиптер бағдарламалық жасақтама, яғни толық емес нұсқалары бағдарламалық жасақтама дамытылуда. Бұл мүмкін болатын әрекет бағдарламалық жасақтама жасау және салыстыруға болады прототиптеу сияқты басқа өрістерден белгілі механикалық инженерия немесе өндіріс.

Әдетте прототип соңғы өнімнің бірнеше аспектілерін ғана модельдейді және олардан мүлдем өзгеше болуы мүмкін.

Прототиптеудің бірнеше артықшылығы бар: бағдарламалық жасақтама жасаушы мен іске асырушы жобаның басында пайдаланушылардан құнды кері байланыс ала алады. Тапсырыс беруші мен мердігер салыстыра алады, егер жасалған бағдарламалық жасақтама сәйкес келсе бағдарламалық қамтамасыз ету, оған сәйкес бағдарламалық жасақтама жасалады. Сондай-ақ, бұл бағдарламалық жасақтама инженерлеріне жобаның бастапқы сметаларының дәлдігі және олардың орындалу мерзімі мен уақыты туралы біраз түсінік береді белестер ұсынылған сәтті орындалуы мүмкін. Толықтылық дәрежесі мен прототиптеу кезінде қолданылатын әдістер 1970-ші жылдардың басында ұсынылғаннан бері дамуда және пікірталастарда болды.[6]

Шолу

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

Бұл үдеріс алдымен 1960-1970 жылдардағы бүкіл бағдарламаны құрудың монолитті даму циклімен ерекшеленеді, содан кейін жобалау мен іске асыру арасындағы сәйкессіздіктерді өңдейді, бұл бағдарламалық жасақтаманың қымбаттауына және уақыт пен шығындардың нашар бағалануына әкелді.[дәйексөз қажет ] Монолитті тәсіл «бағдарламалық жасақтама айдаһарын өлтіру» деп аталды, өйткені ол бағдарламалық жасақтама дизайнері мен жасаушысы жалғыз айдаһарды өлтіруге мәжбүр болатын жалғыз батыр деп есептейді. Сондай-ақ, прототиптеу дайын бағдарламалық жасақтаманы өзгертуге үлкен шығындар мен қиындықтардан аулақ бола алады.

Прототиптеу практикасы - бұл тармақтардың бірі Фредерик П. Брукс өзінің 1975 жылғы кітабында жазады Мифтік адам-ай және оның 10 жылдық мерейтойлық мақаласы »Күміс оқ жоқ ".

Бағдарламалық жасақтаманың прототиптеуінің алғашқы мысалы ретінде Нью-Йорктегі Ada / ED аудармашысын енгізу болды Ada бағдарламалау тілі.[3] Ол жүзеге асырылды SETL Ада тілі үшін орындалатын семантикалық модель жасау мақсатында, дизайн мен пайдаланушы интерфейсінің жылдамдығы мен тиімділігіне анықтығына баса назар аударды. NYU Ada / ED жүйесі 1983 жылы 11 сәуірде сертификатталған Ada тексеруден өткен алғашқы тексеріс болды.[4]

Прототиптеу процесінің құрылымы

Прототиптеу процесі келесі қадамдарды қамтиды[дәйексөз қажет ]

  1. Негізгі белгіні анықтаңыз талаптар
    Қажетті кіріс және шығыс ақпаратын қоса, негізгі талаптарды анықтаңыз. Қауіпсіздік сияқты бөлшектерді әдетте елемеуге болады.
  2. Бастапқы прототипті жасаңыз
    Бастапқы прототип тек қолданушы интерфейстерін қамтитын әзірленді. (Қараңыз Көлденең прототип, төменде)
  3. Шолу
    Тұтынушылар, соның ішінде соңғы пайдаланушылар прототипті зерттеп, ықтимал толықтырулар мен өзгерістер туралы кері байланыс ұсынады.
  4. Прототипті қайта қарап, жетілдіріңіз
    Кері байланысты техникалық сипаттамаларды да, прототипті де жақсартуға болады. Келісім-шарт / өнім шеңберінде келіссөздер жүргізу қажет болуы мүмкін. Егер өзгертулер енгізілсе, онда №3 және №4 қадамдарды қайталау қажет болуы мүмкін.

Прототиптердің өлшемдері

Нильсен прототиптердің әр түрлі өлшемдерін өз кітабында түйіндейді Пайдалану инженериясы:

Көлденең прототип

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

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

Тік прототип

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

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

Прототиптеу түрлері

Бағдарламалық жасақтама прототипінің көптеген нұсқалары бар. Алайда, әдістердің барлығы прототиптеудің екі негізгі формасына негізделген: лақтырылған прототиптеу және эволюциялық прототип.

Лақтырылған прототип

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

Жедел прототиптеу салыстырмалы түрде қысқа тергеуден кейін өте ерте кезеңде жүйенің әртүрлі бөліктерінің жұмыс моделін құруды қамтиды. Оны құруда қолданылатын әдіс әдетте бейресми болып табылады, ең маңызды фактор модель ұсынылатын жылдамдық болып табылады. Содан кейін модель пайдаланушылар өз үміттерін қайта қарап, талаптарын нақтылай алатын бастапқы нүктеге айналады. Осы мақсатқа қол жеткізілгеннен кейін, модельдің прототипі «лақтырылады», ал жүйе анықталған талаптардың негізінде формальды түрде дамиды.[7]

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

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

… Революциялық жылдам прототиптеу - бұл пайдаланушының талаптарына қатысты мәселелерді шешудің тиімді әдісі, демек, бағдарламалық жасақтаманың өнімділігін едәуір арттыру. Талаптарды эволюция, техникалық қызмет көрсету және бағдарламалық жасақтама мәселелері ескерілмеген кезде тезірек және арзанырақ анықтауға, имитациялауға және тексеруге болады. Бұл, өз кезегінде, талаптардың нақты спецификациясына, әрі қарай қолданушының көзқарасы бойынша әдеттегі бағдарламалық жасақтама модельдері арқылы жарамды және қолданылатын жүйені құруға әкеледі. [8]

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

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

Қысқаша мазмұны: Бұл тәсілде прототип оны жойып, түпкілікті жүйені нөлден бастайды деген оймен салынады. Бұл тәсілдегі қадамдар:

  1. Алдын ала талаптарды жазыңыз
  2. Прототипін құрастырыңыз
  3. Пайдаланушының тәжірибесі / прототипін қолданады, жаңа талаптарды анықтайды
  4. Қажет болса, қайталаңыз
  5. Соңғы талаптарды жазыңыз

Эволюциялық прототиптеу

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

Эволюциялық прототиптеуді қолданып жүйені дамытқан кезде жүйе үнемі жетілдіріліп, қайта құрылады.

«... эволюциялық прототиптеу біз барлық талаптарды түсінбейтіндігімізді мойындайды және тек жақсы түсінетіндерін саламыз».[5]

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

Жүйе пайдалы болуы үшін, оны мақсатты пайдалану ортасында пайдалану арқылы дамыту қажет. Өнім ешқашан «жасалмайды»; пайдалану ортасы өзгерген сайын ол әрқашан жетіліп отырады ... біз жүйені өзімізге белгілі анықтамалық жүйені қолданып анықтауға тырысамыз - қазір қайда. Біз бизнесті жүргізу тәсілі және оны жүзеге асыратын технологиялық база туралы болжамдар жасаймыз. Мүмкіндікті дамытуға арналған жоспар құрылады, және ерте ме, кеш пе, болжанған жүйеге ұқсас нәрсе жеткізіледі.[9]

Эволюциялық прототиптердің лақтырылатын прототиптерге қарағанда артықшылығы бар, өйткені олар функционалды жүйелер болып табылады. Оларда пайдаланушылар жоспарлаған барлық мүмкіндіктер болмаса да, оларды түпкілікті жүйе жеткізілгенге дейін аралық негізде пайдалануға болады.

«Прототиптеу ортасында пайдаланушыға алғашқы прототипті жетілдірілген нұсқаны күту кезінде практикалық қолдануға қоюы ғажап емес ... Пайдаланушы» ақаулы «жүйе мүлдем болмағаннан гөрі жақсы деп шешуі мүмкін.»[7]

Эволюциялық прототипте жасаушылар өздерін жүйенің тұтас жүйесін жасаудың орнына түсінетін бөліктерін дамытуға бағыттай алады.

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

Біртектес прототиптеу

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

Экстремалды прототиптеу

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

«Процесс процестің екінші кезеңіне назар аудару үшін экстремалды прототиптеу деп аталады, мұнда толық келісімшартты интерфейс олардың келісімшарттарынан басқа қызметтерге өте аз назар аударылады.» [5]

Прототиптеудің артықшылықтары

Бағдарламалық жасақтама жасауда прототиптеуді қолданудың көптеген артықшылықтары бар - кейбіреулері материалды, ал кейбіреулері - дерексіз.[11]

Уақыт пен шығындар қысқартылды: Прототиптеу жасаушыларға қойылатын талаптар мен сипаттамалардың сапасын жақсарта алады. Өзгерістерді енгізу кейінірек дамыған кезде анықталатындықтан, оны іске асыруға едәуір көп шығындар қажет болғандықтан пайдаланушы шынымен не қалайды нәтижесінде тезірек және арзан бағдарламалық қамтамасыздандыруға әкелуі мүмкін.[8]

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

Прототиптің кемшіліктері

Прототипті қолданудың, мүмкін оны дұрыс қолданбаудың кемшіліктері де болуы мүмкін.

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

Прототип пен дайын жүйенің қолданушысының шатасуы: Пайдаланушылар лақтыруға арналған прототипті іс жүзінде аяқтау немесе жылтырату қажет соңғы жүйе деп ойлауы мүмкін. (Олар, мысалы, прототипте болмауы мүмкін қателіктерді тексеру және қауіпсіздік функцияларын қосу үшін қажет күштер туралы жиі біле бермейді.) Бұл олардың прототипі болмаған жағдайда соңғы жүйенің жұмысын дәл модельдейді деп күтуіне әкелуі мүмкін. әзірлеушілердің ниеті. Пайдаланушылар прототипке енгізілген, содан кейін соңғы жүйенің сипаттамасынан шығарылған мүмкіндіктерге қосыла алады. Егер пайдаланушылар барлық ұсынылған мүмкіндіктерді соңғы жүйеге енгізуді талап ете алса, бұл қайшылықтарға әкелуі мүмкін.

Әзірлеушінің пайдаланушы мақсаттарын дұрыс түсінбеуі: Әзірлеушілер коммерциялық мәселелерді түсінбей, пайдаланушылар өздерінің мақсаттарымен бөліседі (мысалы, негізгі функционалдылықты уақытында және бюджет шеңберінде) деп болжай алады. Мысалы, қатысушы өкілдер Кәсіпорынның бағдарламалық жасақтамасы (мысалы, PeopleSoft ) оқиғалар «транзакция аудитін» (өзгерістер енгізіліп, айырмашылық торының көрінісінде көрсетілетін) демонстрацияларды көрген болуы мүмкін, бұл функция қосымша кодтауды қажет ететіндігі және көбінесе мәліметтер базасына қосымша қол жетімділікті қамтамасыз ету үшін қосымша жабдықты қажет ететіндігі туралы айтылған жоқ. Пайдаланушылар әр салада аудиторлық тексеруді талап ете алады деп сенуі мүмкін, ал әзірлеушілер бұлай ойлауы мүмкін ерекшеліктер өйткені олар қолданушыларға қойылатын талаптардың ауқымы туралы болжамдар жасады. Егер әзірлеуші ​​жеткізушіні қолданушының талаптары қаралмай тұрып қабылдаған болса, әзірлеушілер өте қиын және қиын жерде болады, әсіресе егер пайдаланушы менеджменті талаптарды орындамағандықтан белгілі бір артықшылыққа ие болса.

Әзірлеушілердің прототипке қосымшасы: Сондай-ақ, әзірлеушілер көп күш жұмсаған прототиптерге қосыла алады; бұл тиісті архитектурасы болмаған кезде шектеулі прототипті түпкілікті жүйеге түрлендіруге тырысу сияқты мәселелерге әкелуі мүмкін. (Бұл эволюциялық прототиптеу емес, лақтырылған прототиптеуді қолдану керек деген болжам жасауы мүмкін).

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

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

Прототиптік технологияны қабылдаудың жалпы проблемасы - бұл оқудың қисық сызығының артында күш жұмсамай, өнімділікке деген үлкен үміттер. Прототиптік техниканы қолдануға арналған жаттығулардан басқа, технологияны қолдау үшін корпоративті және жобалық арнайы құрылымды дамыту қажеттілігі жиі ескерілмейді. Бұл негізгі құрылым алынып тасталса, көбінесе өнімділіктің төмендеуі мүмкін.[13]

Прототипті қолданудың ең жақсы жобалары

Прототиптеуді қандай-да бір формада үнемі қолданған жөн деген пікір айтылды. Алайда прототиптеу қолданушылармен көптеген өзара әрекеттесетін жүйелерде тиімді.

Прототиптеуді талдау және жобалау кезінде өте тиімді екендігі анықталды on-line жүйелер, әсіресе транзакцияны өңдеу, мұнда экран диалогтарын қолдану әлдеқайда дәлел. Компьютер мен пайдаланушының өзара әрекеттесуі неғұрлым көп болса, соғұрлым жылдам жүйені құрудан және пайдаланушыға онымен ойнауға мүмкіндік беруден көп пайда табуға болады.[7]

Сияқты пайдаланушылардың өзара әрекеттесуі аз жүйелер пакеттік өңдеу немесе негізінен есептеулер жүргізетін жүйелер прототиптеудің пайдасы аз. Кейде жүйенің функцияларын орындау үшін қажет кодтау өте қарқынды болуы мүмкін және прототиптеу мүмкін болатын кірістер тым аз болады.[7]

Прототиптеу, әсіресе жақсылықты жобалау үшін өте жақсы адам-компьютер интерфейстері. «Жедел прототиптеудің қазіргі уақытқа дейін өнімді қолдануларының бірі пайдаланушының инженерлік қажеттіліктері мен компьютерлік интерфейсті жобалау құралы болды».[8]

Динамикалық жүйелерді құру әдісі

Динамикалық жүйелерді дамыту әдісі (DSDM)[18] бұл негізгі техника ретінде прототипке негізделетін және өзі болатын іскери шешімдерді ұсынудың негізі ISO 9001 бекітілген. Ол прототиптің барлық анықталған анықтамалары бойынша кеңейтіледі. DSDM сәйкес прототипі диаграмма, іскери процесс немесе тіпті өндіріске орналастырылған жүйе болуы мүмкін. DSDM прототиптері қарапайым формалардан анағұрлым жан-жақты болып дамып келе жатқан ұлғайтуға арналған.

DSDM прототиптері кейде болуы мүмкін тастау немесе эволюциялық. Эволюциялық прототиптер көлденең (ені тереңдіктен кейін) немесе тігінен дами алады (әр бөлім келесі бөлімдерді егжей-тегжейлі қосымша итерациямен егжей-тегжейлі салынған). Эволюциялық прототиптер ақыр соңында түпкілікті жүйеге айналуы мүмкін.

DSDM ұсынған прототиптердің төрт санаты:

  • Іскери прототиптер - автоматтандырылатын бизнес-процестерді жобалау және көрсету үшін қолданылады.
  • Қолдануға болатын прототиптер - пайдаланушы интерфейсін жобалаудың ыңғайлылығын, қол жетімділігін, көрінісі мен сезімін анықтау, нақтылау және көрсету үшін қолданылады.
  • Өнімділік және сыйымдылықтың прототиптері - жүктемелер кезінде жүйелердің қалай жұмыс істейтінін анықтау, көрсету және болжау, сонымен қатар жүйенің басқа функционалды емес жақтарын (транзакция жылдамдығы, деректерді сақтау көлемі, жауап беру уақыты және т.б.) көрсету және бағалау үшін қолданылады.
  • Мүмкіндік / техниканың прототиптері - жобалау тәсілін немесе тұжырымдамасын әзірлеу, көрсету және бағалау үшін қолданылады.

The DSDM прототиптің өмірлік циклі:

  1. Прототипті анықтаңыз
  2. Жоспармен келісіңіз
  3. Прототипін жасаңыз
  4. Прототипін қарап шығыңыз

Операциялық прототиптеу

Операциялық прототиптеуді Алан Дэвис лақтыруды және эволюциялық прототиптеуді әдеттегі жүйенің дамуымен біріктіру тәсілі ретінде ұсынды. «Бұл тез және лас әлемнің және дәстүрлі дамудың әлемінің ең жақсысын ақылға қонымды етіп ұсынады. Дизайнерлер эволюциялық негізді құруда тек жақсы түсінетін ерекшеліктерді дамытады, сонымен бірге нашар түсінілген ерекшеліктермен тәжірибе жасау үшін лақтырылған прототиптеуді қолданады».[5]

Дэвистің сенімі бойынша, «жылдам прототипке сапаны күшейтуге» тырысу екі тәсілді біріктіру кезінде дұрыс әдіс емес. Оның идеясы эволюциялық прототиптеу әдіснамасымен айналысу және әр эволюциядан кейін жүйенің ерекшеліктерін тез прототиптеу.

Нақты әдістеме келесі қадамдарды орындайды: [5]

  • Эволюциялық прототип кәдімгі даму стратегияларын қолдана отырып, бастапқы деңгейге айналады, тек жақсы түсінетін талаптарды көрсетіп, жүзеге асырады.
  • Бастапқы сызбаның көшірмелері дайындалған прототиппен бірге бірнеше тапсырыс берушілер сайттарына жіберіледі.
  • Әр сайтта прототипатор қолданушыны жүйеде бақылайды.
  • Пайдаланушы қандай да бір проблемаға тап болғанда немесе жаңа мүмкіндік немесе талап туралы ойланған кезде, прототип жасаушы оны тіркейді. Бұл пайдаланушыны ақаулықты жазудан босатады және жұмысын жалғастыруға мүмкіндік береді.
  • Пайдаланушы сеансы аяқталғаннан кейін прототипші базалық жүйенің жоғарғы жағында лақтырылатын прототипті құрастырады.
  • Енді пайдаланушы жаңа жүйені қолданады және бағалайды. Егер жаңа өзгерістер тиімді болмаса, прототип жасаушы оларды жояды.
  • Егер қолданушыға өзгертулер ұнаса, прототип жасаушы мүмкіндіктерді жақсарту туралы сұраныстар жазып, оны дамытушы топқа жібереді.
  • Әзірлеушілер тобы барлық сайттардағы өзгерістер туралы сұраныстармен дәстүрлі әдістерді қолдана отырып жаңа эволюциялық прототип шығарады.

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

Эволюциялық жүйелердің дамуы

Эволюциялық жүйелер Даму - бұл эволюциялық прототиптеуді ресми түрде жүзеге асыруға тырысатын әдіснамалар класы. Деп аталатын белгілі бір түрі Systemscraft Джон Криннион өзінің кітабында сипатталған Эволюциялық жүйелердің дамуы.

Systemscraft «прототип» әдістемесі ретінде жасалды, оны модификациялау керек және ол іске асырылған нақты ортаға бейімделуі керек.

Systemscraft даму процесіне қатаң «аспаздық кітап» тәсілі ретінде жасалынбаған. Жақсы әдіснаманың қоршаған орта мен жағдайдың кез-келген түріне сай икемді болуы керек екендігі жалпыға танымал болды ...[7]

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

Эволюциялық жедел даму

Эволюциялық жедел даму (ERD)[12] Ақпараттық технологиялар кеңсесінің технологияларды әзірлеу және интеграциялау агенті - Бағдарламалық қамтамасыз ету өнімділігі консорциумы әзірледі Қорғаныс бойынша алдыңғы қатарлы ғылыми жобалар агенттігі (DARPA).

ERD үшін іргелі - бұл компоненттерді қайта пайдалануға, бағдарламалық жасақтама шаблондарын және архитектуралық шаблондарды пайдалануға негізделген бағдарламалық жасақтаманы құру тұжырымдамасы. Пайдаланушының өзгеріп отырған қажеттіліктері мен технологияларына жедел жауап берудегі жүйелік мүмкіндіктердің үздіксіз эволюциясы шешімдер класын білдіретін дамитын архитектурамен ерекшеленеді. Процесс бағдарламалық жасақтама мен жүйелік инженерия пәндерін интеграциялайтын, қолөнершілерге негізделген ұсақ командаларды пайдалануға, клиенттердің жиі өзара әрекеттесуімен, параллель қысқа мерзімді уақытша жәшіктермен жұмыс істеуге бағытталған.
ERD негізіндегі жобалардың сәттілігінің негізі - бұл технологиялардың, нарықтың немесе тұтынушылардың талаптарының өзгеруіне жылдам реакция жасауға мүмкіндік беретін алдыңғы қатарлы технологиялармен бірге ерекшеліктерін, инфрақұрылымдары мен компоненттерін параллельді зерттеу және талдау.[9]

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

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

ERD процесі қағаз өнімдерін емес, көрсетілген функционалдылықты пайдалану үшін құрылымдалған мүдделі тараптар олардың қажеттіліктері мен үміттерін хабарлау. Осы мақсатқа жедел жеткізу мақсаты - «уақыт жәшігі «әдіс. Уақыт жәшіктері - бұл белгілі бір міндеттер (мысалы, функционалдық жиынтығын жасау) орындалуы керек уақыт кезеңдері. Кейбір түсініксіз мақсаттар жиынтығын қанағаттандыру үшін уақытты кеңейтуге емес, күн белгіленді (күнтізбелік тұрғыдан алғанда да) мақсаттар жиынтығы осы шектеулер шеңберінде шынымен қол жеткізуге болатындығы айқындалды. Даму «кездейсоқ серуендеу, «қайталануларды басқаруға арналған ұзақ мерзімді жоспарлар анықталған. Бұл жоспарлар жалпы жүйеге көрініс береді және жобаның шекараларын (мысалы, шектеулер) белгілейді. Процесстегі әр қайталану осы ұзақ мерзімді жоспарлардың аясында жүзеге асырылады .

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

Құралдар

Тәжірибелік модельдеуді тиімді пайдалану ұйымнан тиісті құралдарды және осы құралдарды қолдануға дайындалған қызметкерлерді қажет етеді. Прототипте қолданылатын құралдар жеке құралдардан, мысалы, әр түрлі болуы мүмкін 4-буын бағдарламалау тілдері кешенді интеграцияланған жылдам прототиптеу үшін қолданылады ІС құралдар. 4-буын визуалды бағдарламалау тілдері сияқты Visual Basic және ColdFusion жиі пайдаланылады, өйткені олар арзан, жақсы танымал және қолдануға оңай және жылдам. CASE құралдары, Талаптардың инженерлік ортасы сияқты талаптарды талдауды қолдайды (төменде қараңыз) көбінесе әскери немесе ірі ұйымдар әзірлейді немесе таңдайды. Нысанға бағытталған құралдар да жасалуда LYMB бастап GE Ғылыми-зерттеу орталығы. Пайдаланушылар өздері қолданбаның элементтерінің прототипін a электрондық кесте.

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

Экран генераторлары, дизайн құралдары және бағдарламалық жасақтама зауыттары

Экран жасаушы бағдарламалар да жиі қолданылады және олар прототиптерге жұмыс істемейтін, бірақ экрандар қалай көрінетінін көрсететін пайдаланушы жүйелерін көрсетуге мүмкіндік береді. Дамуда Адамның компьютерлік интерфейстері кейде даму күшінің маңызды бөлігі бола алады, өйткені пайдаланушылар үшін интерфейс негізінен жүйе болып табылады.

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

Қолданбаны анықтау немесе имитациялық бағдарламалық жасақтама

Бағдарламалық жасақтаманың жаңа класы деп аталады Қолданбаны анықтау немесе имитациялық бағдарламалық жасақтама қосады пайдаланушылар жеңіл салмақты, анимациялық модельдеу басқа компьютерлік бағдарламаның, жазбасыз код. Қолданбалы имитациялық бағдарламалық жасақтама техникалық және техникалық емес пайдаланушыларға тәжірибе алуға, тестілеуге, бірлесіп жұмыс жасауға және имитацияланған бағдарламаны растауға мүмкіндік береді және есептер ұсынады. аннотация, скриншот және схемалар. Шешімнің спецификациясы әдістемесі ретінде, қолданбалы модельдеу қауіпті, бірақ шектеулі, мәтіндік немесе сызбаға негізделген макеттер (немесе сым кадрлары ) кейде шақырады қағаз негізіндегі прототиптеужәне уақытты қажет ететін, қауіптілігі жоғары кодқа негізделген прототиптер Бағдарламалық жасақтама мамандарына талаптарды және дизайн таңдауын әзірлеу басталғанға дейін ертерек растауға мүмкіндік беру. Бұл ретте бағдарламалық қамтамасыздандырумен байланысты тәуекелдер мен шығындар күрт төмендеуі мүмкін.[6]

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

Инженерлік ортаға қойылатын талаптар

«Талаптар Инженерлік орта (РЭҚ), әзірленуде Рим зертханасы 1985 жылдан бастап күрделі жүйелердің сыни аспектілерінің модельдерін жылдам ұсыну, құру және орындау үшін біріктірілген құралдар жиынтығын ұсынады ».[15]

Талаптар Инженерлік ортаны қазіргі кезде жүйені жасау үшін Америка Құрама Штаттарының Әуе күштері қолданады. Бұл:

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

REE үш бөлімнен тұрады. Біріншісі, прототип деп аталатын - жылдам прототиптеуді қолдау үшін арнайы жасалған CASE құралы. Екінші бөлім жылдам интерфейстің прототиптік жүйесі немесе RIP деп аталады, ол қолданушы интерфейстерін құруды жеңілдететін құралдар жиынтығы. REE үшінші бөлігі - бұл графикалық және пайдалануға ыңғайлы болатын RIP және proto-ға арналған пайдаланушы интерфейсі.

Рим зертханасы, REE әзірлеушісі, олардың ішкі қажеттіліктерін жинау әдістемесін қолдауға бағытталған. Олардың әдісі үш негізгі бөлімнен тұрады:

  • Әр түрлі көздерден (пайдаланушылардан, басқа жүйелермен интерфейстерден) шығу, спецификация және консистенцияны тексеру
  • Әр түрлі қолданушылардың қажеттіліктері бір-біріне қайшы келмейтінін және техникалық-экономикалық тұрғыдан орынды болатындығын талдау
  • Қойылған талаптардың пайдаланушының қажеттілігінің дәл көрінісі болып табылатындығын растау.[15]

1996 жылы Рим зертханалары бағдарламалық жасақтаманың өнімділігі бойынша шешімдерді (SPS) келісімшартпен «талаптардың спецификациясын, имитациясын, қолданушы интерфейсінің прототипін, аппараттық архитектураға талаптардың картографиясын және кодты жасауды қолдайтын коммерциялық сапа бойынша ШЖҚ» құру үшін ЖК-ны одан әрі жетілдіруге шақырды.[16] Бұл жүйе Advanced Workements Engineering Workstation немесе AREW деп аталады.

Реляциялық емес орта

Деректердің реляциялық емес анықтамасы (мысалы, пайдалану) Кэш немесе ассоциативті модельдер ) can help make end-user prototyping more productive by delaying or avoiding the need to қалыпқа келтіру data at every iteration of a simulation. This may yield earlier/greater clarity of business requirements, though it does not specifically confirm that requirements are technically and economically feasible in the target production system.

PSDL

PSDL is a prototype description language to describe real-time software.[7]The associated tool set is CAPS (Computer Aided Prototyping System).[8]Prototyping software systems with hard real-time requirements is challenging because timing constraints introduce implementation and hardware dependencies.PSDL addresses these issues by introducing control abstractions that include declarative timing constraints. CAPS uses this information to automatically generate code and associated real-time schedules, monitor timing constraints during prototype execution, and simulate execution in proportional real time relative to a set of parameterized hardware models. It also provides default assumptions that enable execution of incomplete prototype descriptions, integrates prototype construction with a software reuse repository for rapidly realizing efficient implementations, and provides support for rapid evolution of requirements and designs.[9]

Ескертулер

  1. ^ C. Melissa Mcclendon, Larry Regot, Gerri Akers: The Analysis and Prototyping of Effective Graphical User Interfaces. Қазан 1996. [1]
  2. ^ Д.А. Stacy, professor, University of Guelph. Guelph, Ontario. Lecture notes on Rapid Prototyping. August, 1997. [2]
  3. ^ Stephen J. Andriole: Information System Design Principles for the 90s: Getting it Right. AFCEA International Press, Fairfax, Virginia. 1990. Page 13.
  4. ^ R. Charette, Software Engineering Risk Analysis and Management. McGraw Hill, New York, 1989.
  5. ^ Alan M. Davis: Operational Prototyping: A new Development Approach. IEEE Software, September 1992. Page 71.
  6. ^ Todd Grimm: The Human Condition: A Justification for Rapid Prototyping. Time Compression Technologies, vol. 3 жоқ. 3. Accelerated Technologies, Inc. May 1998 . 1 бет. [3]
  7. ^ John Crinnion: Evolutionary Systems Development, a practical guide to the use of prototyping within a structured systems methodology. Plenum Press, New York, 1991. Page 18.
  8. ^ S. P. Overmyer: Revolutionary vs. Evolutionary Rapid Prototyping: Balancing Software Productivity and HCI Design Concerns. Center of Excellence in Command, Control, Communications and Intelligence (C3I), George Mason University, 4400 University Drive, Fairfax, Virginia.
  9. ^ Software Productivity Consortium: Evolutionary Rapid Development. SPC document SPC-97057-CMC, version 01.00.04, June 1997. Herndon, Va. Page 6.
  10. ^ Дэвис. Page 72-73. Citing: E. Bersoff and A. Davis, Impacts of Life Cycle Models of Software Configuration Management. Комм. ACM, Aug. 1991, pp. 104–118
  11. ^ Adapted from C. Melissa Mcclendon, Larry Regot, Gerri Akers.
  12. ^ Adapted from Software Productivity Consortium. PPS 10–13.
  13. ^ Joseph E. Urban: Software Prototyping and Requirements Engineering. Rome Laboratory, Rome, NY.
  14. ^ Paul W. Parry. Rapid Software Prototyping. Sheffield Hallam University, Sheffield, UK. [4]
  15. ^ Dr. Ramon Acosta, Carla Burns, William Rzepka, and James Sidoran. Applying Rapid Prototyping Techniques in the Requirements Engineering Environment. IEEE, 1994 ж. [5]
  16. ^ Software Productivity Solutions, Incorporated. Advanced Requirements Engineering Workstation (AREW). 1996 ж. [6]
  17. ^ from GE Research and Development. https://web.archive.org/web/20061013220422/http://www.crd.ge.com/esl/cgsp/fact_sheet/objorien/index.html
  18. ^ Dynamic Systems Development Method Consortium. https://web.archive.org/web/20060209072841/http://na.dsdm.org/
  19. ^ Alan Dix, Janet Finlay, Gregory D. Abowd, Russell Beale; Human-Computer Interaction, Third edition

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

  1. ^ "Software Prototyping - INGSOFTWARE". www.ingsoftware.com. Алынған 2018-06-27.
  2. ^ Smith MF Software Prototyping: Adoption, Practice and Management. McGraw-Hill, London (1991).
  3. ^ Dewar, Robert B. K.; Fisher Jr., Gerald A.; Schonberg, Edmond; Froelich, Robert; Bryant, Stephen; Goss, Clinton F.; Burke, Michael (November 1980). "The NYU Ada Translator and Interpreter". ACM SIGPLAN Notices – Proceedings of the ACM-SIGPLAN Symposium on the Ada Programming Language. 15 (11): 194–201. дои:10.1145/948632.948659. ISBN  0-89791-030-3.
  4. ^ SofTech Inc., Waltham, MA (1983-04-11). "Ada Compiler Validation Summary Report: NYU Ada/ED, Version 19.7 V-001". Алынған 2010-12-16.CS1 maint: бірнеше есімдер: авторлар тізімі (сілтеме)
  5. ^ Komatineni, Satya. "Reshaping IT Project Delivery Through Extreme Prototyping". Архивтелген түпнұсқа 2016-12-06.
  6. ^ How Simulation Software Can Streamline Application Development Мұрағатталды 2012-07-22 сағ Бүгін мұрағат
  7. ^ Luqi; Berzins, Yeh (October 1988). "A Prototyping Language for Real-Time Software" (PDF). Бағдарламалық жасақтама бойынша IEEE транзакциялары. 14 (10): 1409–1423. дои:10.1109/32.6186. hdl:10945/39162.
  8. ^ Luqi; Ketabchi (March 1988). "A Computer-Aided Prototyping System". IEEE бағдарламалық жасақтамасы. 5 (2): 66–72. дои:10.1109/52.2013. hdl:10945/43616.
  9. ^ Luqi (May 1989). "Software Evolution through Rapid Prototyping". IEEE Computer. 22 (5): 13–25. дои:10.1109/2.27953. hdl:10945/43610.