វិធីសាស្រ្តមួយក្នុងចំណោមវិធីសាស្រ្តដែលអាចកើតមានចំពោះការអភិវឌ្ឍន៍កម្មវិធីក្នុងក្របខ័ណ្ឌនៃគំរូវដ្ដជីវិតតំរៀបស្លឹកគឺជាវិធីដែលបានទទួល ថ្មីៗនេះការប្រើប្រាស់យ៉ាងទូលំទូលាយនៃវិធីសាស្ត្រ RAD (Rapid Application Development) ។ ពាក្យនេះជាធម្មតាសំដៅទៅលើដំណើរការអភិវឌ្ឍន៍កម្មវិធីដែលមានធាតុ 3៖

ក្រុមតូចមួយនៃអ្នកសរសេរកម្មវិធី (ពី 2 ទៅ 10 នាក់);

រយៈពេលខ្លីប៉ុន្តែបានធ្វើការដោយប្រុងប្រយ័ត្ននូវកាលវិភាគផលិតកម្ម (ពី 2 ទៅ 6 ខែ);

វដ្ដដដែលៗដែលអ្នកអភិវឌ្ឍន៍ នៅពេលដែលកម្មវិធីចាប់ផ្តើមមានរូបរាង ស្នើសុំ និងអនុវត្ត តម្រូវការផលិតផលទទួលបានតាមរយៈអន្តរកម្មជាមួយអតិថិជន។

ក្រុមអភិវឌ្ឍន៍គួរតែជាក្រុមអ្នកជំនាញដែលមានបទពិសោធន៍ក្នុងការវិភាគ ការរចនា ការបង្កើតកូដ និងការធ្វើតេស្តកម្មវិធីដោយប្រើឧបករណ៍ CASE ។ សមាជិកក្រុមក៏ត្រូវតែអាចបកប្រែការណែនាំរបស់អ្នកប្រើប្រាស់ចុងក្រោយទៅជាគំរូការងារផងដែរ។

វដ្តជីវិតរបស់កម្មវិធីយោងតាមវិធីសាស្ត្រ RAD មានបួនដំណាក់កាល៖

ដំណាក់កាលនៃការវិភាគតម្រូវការ និងផែនការ;

ដំណាក់កាលរចនា;

ដំណាក់កាលសាងសង់;

ដំណាក់កាលនៃការអនុវត្ត។

នៅដំណាក់កាលនៃការវិភាគ និងការធ្វើផែនការតម្រូវការ អ្នកប្រើប្រាស់ប្រព័ន្ធកំណត់មុខងារដែលវាត្រូវតែអនុវត្ត កំណត់អត្តសញ្ញាណអាទិភាពខ្ពស់បំផុតដែលទាមទារឱ្យមានភាពលម្អិតជាមុនសិន និងពណ៌នាអំពីតម្រូវការព័ត៌មាន។ ការកំណត់តម្រូវការត្រូវបានអនុវត្តជាចម្បងដោយអ្នកប្រើប្រាស់ក្រោមការណែនាំរបស់អ្នកអភិវឌ្ឍន៍ឯកទេស។ វិសាលភាពនៃគម្រោងត្រូវបានកំណត់ ហើយពេលវេលាសម្រាប់ដំណាក់កាលបន្តបន្ទាប់នីមួយៗត្រូវបានកំណត់។ លើសពីនេះទៀតលទ្ធភាពនៃការអនុវត្តត្រូវបានកំណត់ នៃគម្រោងនេះ។ក្នុងដែនកំណត់ថវិកាដែលបានបង្កើតឡើង លើផ្នែករឹងដែលបានផ្តល់ឱ្យ។ល។ លទ្ធផលនៃដំណាក់កាលនេះគួរតែជាបញ្ជី និងអាទិភាពនៃមុខងាររបស់ IS នាពេលអនាគត គំរូមុខងារបឋម និងព័ត៌មានរបស់ IS ។

ក្នុងដំណាក់កាលរចនា អ្នកប្រើប្រាស់មួយចំនួនចូលរួមក្នុងការរចនាបច្ចេកទេសនៃប្រព័ន្ធក្រោមការណែនាំរបស់អ្នកអភិវឌ្ឍន៍ឯកទេស។ ឧបករណ៍ CASE ត្រូវ​បាន​ប្រើ​ដើម្បី​ផលិត​គំរូ​ការងារ​យ៉ាង​ឆាប់​រហ័ស​នៃ​កម្មវិធី។ អ្នកប្រើប្រាស់ ធ្វើអន្តរកម្មដោយផ្ទាល់ជាមួយពួកគេ បញ្ជាក់ និងបន្ថែមតម្រូវការប្រព័ន្ធដែលមិនត្រូវបានកំណត់អត្តសញ្ញាណក្នុងដំណាក់កាលមុន។ ដំណើរការប្រព័ន្ធត្រូវបានពិភាក្សាលម្អិតបន្ថែមទៀត។ គំរូមុខងារត្រូវបានវិភាគ ហើយបើចាំបាច់ កែតម្រូវ។ ដំណើរការនីមួយៗត្រូវបានពិចារណាយ៉ាងលម្អិត។ បើចាំបាច់ គំរូផ្នែកមួយត្រូវបានបង្កើតឡើងសម្រាប់ដំណើរការបឋមនីមួយៗ៖ អេក្រង់ ប្រអប់ របាយការណ៍ដែលលុបបំបាត់ភាពមិនច្បាស់លាស់ ឬភាពមិនច្បាស់លាស់។ តម្រូវការសម្រាប់ការរឹតបន្តឹងការចូលប្រើទិន្នន័យត្រូវបានកំណត់។ នៅដំណាក់កាលដូចគ្នាសំណុំឯកសារចាំបាច់ត្រូវបានកំណត់។

បន្ទាប់ពីការកំណត់លម្អិតនៃសមាសភាពនៃដំណើរការចំនួននៃ ធាតុមុខងារប្រព័ន្ធកំពុងត្រូវបានបង្កើតឡើង ហើយការសម្រេចចិត្តមួយត្រូវបានធ្វើឡើងដើម្បីបែងចែក IS ទៅជាប្រព័ន្ធរង ដែលអាចត្រូវបានអនុវត្តដោយក្រុមអ្នកអភិវឌ្ឍន៍មួយក្រុមក្នុងរយៈពេលដែលអាចទទួលយកបានសម្រាប់គម្រោង RAD ប្រហែល 60 - 90 ថ្ងៃ។ ដោយប្រើឧបករណ៍ CASE គម្រោងត្រូវបានចែកចាយក្នុងចំណោមក្រុមផ្សេងៗគ្នា (គំរូមុខងារត្រូវបានបែងចែក)។ លទ្ធផលនៃដំណាក់កាលនេះគួរតែជា៖

ទូទៅ គំរូព័ត៌មានប្រព័ន្ធ;

គំរូមុខងារនៃប្រព័ន្ធទាំងមូល និងប្រព័ន្ធរងអនុវត្តដោយក្រុមអភិវឌ្ឍន៍បុគ្គល។

ចំណុចប្រទាក់ដែលបានកំណត់យ៉ាងជាក់លាក់រវាងប្រព័ន្ធរងដែលបានអភិវឌ្ឍដោយស្វយ័តដោយប្រើឧបករណ៍ CASE;

បង្កើតគំរូនៃអេក្រង់ របាយការណ៍ ប្រអប់។

ម៉ូដែល និងគំរូទាំងអស់ត្រូវតែទទួលបានដោយប្រើឧបករណ៍ CASE ទាំងនោះដែលនឹងត្រូវបានប្រើនាពេលអនាគតនៅពេលបង្កើតប្រព័ន្ធ។ តម្រូវការនេះ។នេះគឺដោយសារតែការពិតដែលថានៅក្នុងវិធីសាស្រ្តប្រពៃណីនៅពេលផ្ទេរព័ត៌មានអំពីគម្រោងមួយពីដំណាក់កាលមួយទៅដំណាក់កាលមួយការបង្ខូចទ្រង់ទ្រាយទិន្នន័យស្ទើរតែមិនអាចគ្រប់គ្រងបានអាចកើតឡើង។ ការប្រើប្រាស់បរិយាកាសបង្រួបបង្រួមសម្រាប់ការរក្សាទុកព័ត៌មានគម្រោងអនុញ្ញាតឱ្យអ្នកជៀសវាងគ្រោះថ្នាក់នេះ។

មិនដូចវិធីសាស្រ្តបែបប្រពៃណី ដែលប្រើឧបករណ៍គំរូជាក់លាក់ដែលមិនត្រូវបានរចនាឡើងដើម្បីបង្កើតកម្មវិធីក្នុងពិភពពិត ហើយបោះបង់គំរូដើមបន្ទាប់ពីពួកគេបានបម្រើគោលបំណងសម្អាតភាពមិនច្បាស់លាស់ក្នុងការរចនា នៅក្នុងវិធីសាស្រ្ត RAD គំរូនីមួយៗត្រូវបានបង្កើតឡើងជាផ្នែកមួយ។ ប្រព័ន្ធអនាគត. ដូច្នេះ ព័ត៌មានពេញលេញ និងមានប្រយោជន៍ត្រូវបានផ្ទេរទៅដំណាក់កាលបន្ទាប់។

ដំណាក់កាលសាងសង់គឺជាកន្លែងដែលការអភិវឌ្ឍន៍កម្មវិធីយ៉ាងឆាប់រហ័សកើតឡើង។ នៅដំណាក់កាលនេះ អ្នកអភិវឌ្ឍន៍បង្កើតប្រព័ន្ធពិតប្រាកដមួយឡើងវិញដោយផ្អែកលើគំរូដែលទទួលបានក្នុងដំណាក់កាលមុន ក៏ដូចជាតម្រូវការមិនដំណើរការ។ កូដកម្មវិធីត្រូវបានបង្កើតដោយផ្នែកដោយប្រើម៉ាស៊ីនភ្លើងស្វ័យប្រវត្តិដែលទទួលព័ត៌មានដោយផ្ទាល់ពីឃ្លាំងឧបករណ៍ CASE ។ នៅដំណាក់កាលនេះ អ្នកប្រើប្រាស់ចុងក្រោយវាយតម្លៃលទ្ធផលដែលទទួលបាន និងធ្វើការកែតម្រូវ ប្រសិនបើក្នុងអំឡុងពេលដំណើរការអភិវឌ្ឍន៍ ប្រព័ន្ធនេះលែងបំពេញតាមតម្រូវការដែលបានកំណត់ពីមុនទៀតហើយ។ ការធ្វើតេស្តប្រព័ន្ធត្រូវបានអនុវត្តដោយផ្ទាល់ក្នុងអំឡុងពេលដំណើរការអភិវឌ្ឍន៍។

បន្ទាប់ពីបញ្ចប់ការងារនៃក្រុមអភិវឌ្ឍន៍បុគ្គលនីមួយៗ ការធ្វើសមាហរណកម្មបន្តិចម្តងៗនៃផ្នែកនៃប្រព័ន្ធនេះជាមួយផ្នែកដែលនៅសល់ត្រូវបានអនុវត្ត ដែលជាការពេញលេញ។ កូដកម្មវិធីការធ្វើតេស្តត្រូវបានអនុវត្តដើម្បីសាកល្បងពីរបៀបដែលផ្នែកនៃកម្មវិធីនេះដំណើរការរួមគ្នាជាមួយអ្វីដែលនៅសល់ ហើយបន្ទាប់មកសាកល្បងប្រព័ន្ធទាំងមូល។ ការរចនារូបវិទ្យានៃប្រព័ន្ធត្រូវបានបញ្ចប់៖

តម្រូវការសម្រាប់ការចែកចាយទិន្នន័យត្រូវបានកំណត់;

ការវិភាគនៃការប្រើប្រាស់ទិន្នន័យត្រូវបានអនុវត្ត;

ការរចនារូបវន្តនៃមូលដ្ឋានទិន្នន័យត្រូវបានអនុវត្ត;

តម្រូវការសម្រាប់ធនធានផ្នែករឹងត្រូវបានកំណត់;

វិធីដើម្បីបង្កើនផលិតភាពត្រូវបានកំណត់;

ការអភិវឌ្ឍន៍ឯកសារគម្រោងកំពុងត្រូវបានបញ្ចប់។

លទ្ធផលនៃដំណាក់កាលគឺជាប្រព័ន្ធបញ្ចប់ដែលបំពេញតាមតម្រូវការដែលបានព្រមព្រៀងទាំងអស់។

ក្នុងដំណាក់កាលនៃការអនុវត្ត ការបណ្តុះបណ្តាលអ្នកប្រើប្រាស់ ការផ្លាស់ប្តូរអង្គភាព និងស្របជាមួយនឹងការអនុវត្តត្រូវបានអនុវត្ត ប្រព័ន្ធថ្មី។ការងារត្រូវបានអនុវត្តជាមួយប្រព័ន្ធដែលមានស្រាប់ (រហូតដល់ប្រព័ន្ធថ្មីត្រូវបានអនុវត្តយ៉ាងពេញលេញ) ។ ដោយសារដំណាក់កាលសាងសង់គឺខ្លីណាស់ ការធ្វើផែនការ និងការរៀបចំសម្រាប់ការអនុវត្តត្រូវតែចាប់ផ្តើមដំបូង ជាធម្មតាក្នុងដំណាក់កាលរចនាប្រព័ន្ធ។ គ្រោងការណ៍អភិវឌ្ឍន៍ IS ដែលបានផ្តល់ឱ្យគឺមិនដាច់ខាត។ ជម្រើសផ្សេងៗអាចធ្វើទៅបាន អាស្រ័យទៅលើលក្ខខណ្ឌដំបូងដែលការអភិវឌ្ឍន៍ត្រូវបានអនុវត្ត៖ ប្រព័ន្ធថ្មីទាំងស្រុងកំពុងត្រូវបានបង្កើតឡើង។ ការស្ទង់មតិរបស់សហគ្រាសត្រូវបានអនុវត្តរួចហើយ ហើយគំរូនៃសកម្មភាពរបស់ខ្លួនមាន។ សហគ្រាសមាន IP មួយចំនួនរួចហើយ ដែលអាចត្រូវបានប្រើជាគំរូដើម ឬត្រូវតែរួមបញ្ចូលជាមួយអ្វីដែលកំពុងត្រូវបានបង្កើត។

ទោះជាយ៉ាងណាក៏ដោយ វាគួរតែត្រូវបានកត់សម្គាល់ថា វិធីសាស្ត្រ RAD ដូចអ្វីផ្សេងទៀត មិនអាចអះអាងថាជាសកលទេ វាគឺជាការល្អជាចម្បងសម្រាប់គម្រោងតូចៗដែលបង្កើតឡើងសម្រាប់អតិថិជនជាក់លាក់។ ប្រសិនបើប្រព័ន្ធស្ដង់ដារកំពុងត្រូវបានបង្កើតឡើង ដែលមិនមែនជាផលិតផលសម្រេច ប៉ុន្តែជាសមាសធាតុស្ដង់ដារស្មុគ្រស្មាញ រក្សាជាកណ្តាល សម្របខ្លួនទៅនឹងវេទិកាផ្នែកទន់ និងផ្នែករឹង DBMS ទូរគមនាគមន៍ លក្ខណៈរៀបចំ និងសេដ្ឋកិច្ចនៃវត្ថុអនុវត្ត និងរួមបញ្ចូលជាមួយការអភិវឌ្ឍន៍ដែលមានស្រាប់។ ចំណុចខាងក្រោមបានលេចចេញជារូបរាង៖ សូចនាករគម្រោងដូចជា សមត្ថភាពគ្រប់គ្រង និងគុណភាព ដែលអាចមានទំនាស់ជាមួយនឹងភាពសាមញ្ញ និងល្បឿននៃការអភិវឌ្ឍន៍។ សម្រាប់គម្រោងបែបនេះវាចាំបាច់ កម្រិតខ្ពស់ការធ្វើផែនការ និងវិន័យនៃការរចនាដ៏តឹងរឹង ការប្រកាន់ខ្ជាប់យ៉ាងតឹងរ៉ឹងចំពោះពិធីការ និងចំណុចប្រទាក់ដែលបានអភិវឌ្ឍជាមុន ដែលកាត់បន្ថយល្បឿននៃការអភិវឌ្ឍន៍។

វិធីសាស្រ្ត RAD មិនអាចអនុវត្តបានសម្រាប់ការសាងសង់កម្មវិធីគណនាស្មុគស្មាញ ប្រព័ន្ធប្រតិបត្តិការ ឬកម្មវិធីគ្រប់គ្រងយានអវកាស ពោលគឺឧ។ កម្មវិធីដែលតម្រូវឱ្យសរសេរចំនួនច្រើន (រាប់រយរាប់ពាន់បន្ទាត់) នៃកូដតែមួយគត់។

កម្មវិធីដែលមិនមានផ្នែកចំណុចប្រទាក់ដែលបានកំណត់យ៉ាងច្បាស់ដែលកំណត់យ៉ាងច្បាស់លាស់នូវតក្កវិជ្ជានៃប្រព័ន្ធ (ឧទាហរណ៍ កម្មវិធីតាមពេលវេលាជាក់ស្តែង) និងកម្មវិធីដែលសុវត្ថិភាពរបស់មនុស្សអាស្រ័យ (ឧទាហរណ៍ ការគ្រប់គ្រងយន្តហោះ ឬរោងចក្រថាមពលនុយក្លេអ៊ែរ) មិនសមរម្យទេ។ សម្រាប់ការអភិវឌ្ឍន៍ដោយប្រើវិធីសាស្ត្រ RAD ព្រោះវាមានលក្ខណៈដដែលៗ វិធីសាស្រ្តសន្មត់ថាកំណែពីរបីដំបូងទំនងជាមិនមានមុខងារពេញលេញទេ ដែលត្រូវបានដកចេញក្នុងករណីនេះ។

ទំហំនៃកម្មវិធីត្រូវបានប៉ាន់ប្រមាណដោយផ្អែកលើធាតុមុខងារ (អេក្រង់ សារ របាយការណ៍ ឯកសារ។ល។) ទំហំនៃកម្មវិធីដែលអាចត្រូវបានប្រតិបត្តិដោយប្រើវិធីសាស្រ្ត RAD សម្រាប់បរិយាកាសអភិវឌ្ឍន៍ IC ដែលបានបង្កើតឡើងយ៉ាងល្អជាមួយនឹងការប្រើប្រាស់ឡើងវិញអតិបរមានៃសមាសធាតុកម្មវិធីត្រូវបានកំណត់ដូចខាងក្រោម:

ជាសេចក្តីសង្ខេប យើងរាយបញ្ជីគោលការណ៍សំខាន់ៗនៃវិធីសាស្ត្រ RAD៖

ការអភិវឌ្ឍកម្មវិធីនៅក្នុងការធ្វើឡើងវិញ;

ជម្រើសនៃការបញ្ចប់ការងារពេញលេញនៅដំណាក់កាលនីមួយៗនៃវដ្តជីវិត។

ការចូលរួមជាកាតព្វកិច្ចរបស់អ្នកប្រើប្រាស់ក្នុងដំណើរការអភិវឌ្ឍ IS;

ការប្រើប្រាស់ចាំបាច់នៃឧបករណ៍ CASE ដើម្បីធានាបាននូវភាពត្រឹមត្រូវនៃគម្រោង។

ការប្រើប្រាស់ឧបករណ៍គ្រប់គ្រងការកំណត់រចនាសម្ព័ន្ធដែលជួយសម្រួលដល់ការផ្លាស់ប្តូរគម្រោង និងការថែរក្សាប្រព័ន្ធដែលបានបញ្ចប់។

ការប្រើប្រាស់ចាំបាច់នៃម៉ាស៊ីនបង្កើតកូដ;

ការប្រើប្រាស់គំរូដើម ដើម្បីយល់កាន់តែច្បាស់ និងបំពេញតម្រូវការរបស់អ្នកប្រើប្រាស់ចុងក្រោយ។

ការធ្វើតេស្តនិង ការអភិវឌ្ឍន៍គម្រោងអនុវត្តក្នុងពេលដំណាលគ្នាជាមួយនឹងការអភិវឌ្ឍន៍;

ការអភិវឌ្ឍដោយក្រុមអ្នកជំនាញតូច និងគ្រប់គ្រងបានល្អ;

ការគ្រប់គ្រងប្រកបដោយសមត្ថភាពនៃការអភិវឌ្ឍន៍ប្រព័ន្ធ ការធ្វើផែនការច្បាស់លាស់ និងការត្រួតពិនិត្យការអនុវត្តការងារ។

ការអភិវឌ្ឍន៍ផលិតផលកម្មវិធីដឹងពីវិធីសាស្រ្តសក្តិសមជាច្រើន - ម្យ៉ាងវិញទៀត ការអនុវត្តល្អបំផុតដែលបានបង្កើតឡើង។ ជម្រើសអាស្រ័យលើភាពជាក់លាក់នៃគម្រោង ប្រព័ន្ធថវិកា ចំណូលចិត្តប្រធានបទ និងសូម្បីតែនិស្ស័យរបស់អ្នកគ្រប់គ្រង។ អត្ថបទពិពណ៌នាអំពីវិធីសាស្រ្តដែលយើងជួបប្រទះជាប្រចាំនៅ Edison ។

1. "គំរូទឹកជ្រោះ" (គំរូល្បាក់ ឬ "ទឹកជ្រោះ")

មួយក្នុងចំណោមដំណាក់កាលចាស់បំផុត ពាក់ព័ន្ធនឹងការឆ្លងកាត់តាមលំដាប់លំដោយនៃដំណាក់កាល ដែលនីមួយៗត្រូវតែបញ្ចប់ទាំងស្រុង មុនពេលចាប់ផ្តើមបន្ទាប់។ គំរូទឹកជ្រោះធ្វើឱ្យមានភាពងាយស្រួលក្នុងការគ្រប់គ្រងគម្រោង។ សូមអរគុណចំពោះភាពរឹងម៉ាំរបស់វា ការអភិវឌ្ឍន៍ដំណើរការយ៉ាងឆាប់រហ័ស ការចំណាយ និងពេលវេលាកំណត់ត្រូវបានកំណត់ទុកជាមុន។ ប៉ុន្តែនេះគឺជាដាវមុខពីរ។ គំរូល្បាក់នឹងផ្តល់ឱ្យ លទ្ធផលដ៏អស្ចារ្យមានតែនៅក្នុងគម្រោងដែលមានតម្រូវការ និងវិធីសាស្រ្តច្បាស់លាស់ និងកំណត់ទុកជាមុនសម្រាប់ការអនុវត្តរបស់ពួកគេ។ មិនមានវិធីដើម្បីបោះជំហានថយក្រោយទេ ការធ្វើតេស្តចាប់ផ្តើមតែបន្ទាប់ពីការអភិវឌ្ឍន៍រួចរាល់ ឬជិតរួចរាល់។ ផលិតផលដែលត្រូវបានបង្កើតឡើងដោយយោងទៅតាមគំរូនេះដោយគ្មានជម្រើសត្រឹមត្រូវអាចមានការខ្វះខាត (បញ្ជីនៃតម្រូវការមិនអាចកែតម្រូវបានគ្រប់ពេលទេ) ដែលត្រូវបានគេស្គាល់តែនៅចុងបញ្ចប់ដោយសារតែលំដាប់ដ៏តឹងរឹងនៃសកម្មភាព។ ការចំណាយលើការកែប្រែគឺខ្ពស់ ព្រោះវាតម្រូវឱ្យរង់ចាំរហូតដល់គម្រោងទាំងមូលត្រូវបានបញ្ចប់ ដើម្បីចាប់ផ្តើមវា។ ទោះជាយ៉ាងណាក៏ដោយ ការចំណាយថេរជារឿយៗលើសពីគុណវិបត្តិនៃវិធីសាស្រ្ត។ ការកែតម្រូវចំណុចខ្វះខាតដែលបានដឹងក្នុងអំឡុងពេលដំណើរការបង្កើតគឺអាចធ្វើទៅបាន ហើយតាមបទពិសោធន៍របស់យើង ទាមទារកិច្ចព្រមព្រៀងបន្ថែមពីមួយទៅបីចំពោះកិច្ចសន្យាជាមួយនឹងលក្ខណៈបច្ចេកទេសតូចមួយ។

ដោយប្រើ គំរូល្បាក់យើងបានបង្កើតគម្រោងជាច្រើនតាំងពីដំបូង រួមទាំងការអភិវឌ្ឍន៍លក្ខណៈបច្ចេកទេសតែប៉ុណ្ណោះ។ គម្រោងដែលត្រូវបានសរសេរអំពី Habre: មធ្យម - មីក្រូទស្សន៍កាំរស្មីអ៊ិច តូច - ការធ្វើបច្ចុប្បន្នភាពដោយស្វ័យប្រវត្តិនៃសេវាកម្មវីនដូនៅលើ AWS ។

ពេលណាត្រូវប្រើវិធីសាស្រ្តទឹកជ្រោះ?

• លុះត្រាតែតម្រូវការត្រូវបានដឹង យល់ និងកត់ត្រាទុក។ មិនមានតម្រូវការផ្ទុយគ្នាទេ។
• មិនមានបញ្ហាជាមួយនឹងភាពអាចរកបាននៃអ្នកសរសេរកម្មវិធីដែលមានគុណវុឌ្ឍិដែលត្រូវការនោះទេ។
• នៅក្នុងគម្រោងតូចតាច។

2. "V-Model"

បានទទួលមរតករចនាសម្ព័ន្ធ "មួយជំហានម្តង ៗ" ពីគំរូល្បាក់។ គំរូរាងអក្សរ V អាចអនុវត្តបានចំពោះប្រព័ន្ធដែលប្រតិបត្តិការគ្មានការរំខានមានសារៈសំខាន់ជាពិសេស។ ឧទាហរណ៍ កម្មវិធីកម្មវិធីនៅក្នុងគ្លីនិកសម្រាប់តាមដានអ្នកជំងឺ កម្មវិធីរួមបញ្ចូលគ្នាសម្រាប់យន្តការគ្រប់គ្រងពោងសុវត្ថិភាពក្នុងគ្រាអាសន្ន។ យានជំនិះហើយដូច្នេះនៅលើ។ លក្ខណៈពិសេសមួយរបស់ម៉ូដែលនេះគឺថាវាមានគោលបំណងត្រួតពិនិត្យយ៉ាងហ្មត់ចត់នូវផលិតផលដែលមានរួចហើយនៅក្នុងដំណាក់កាលដំបូងនៃការរចនា។ ដំណាក់កាលសាកល្បងត្រូវបានអនុវត្តក្នុងពេលដំណាលគ្នាជាមួយនឹងដំណាក់កាលអភិវឌ្ឍន៍ដែលត្រូវគ្នា ឧទាហរណ៍ ការធ្វើតេស្តឯកតាត្រូវបានសរសេរកំឡុងពេលសរសេរកូដ។

ឧទាហរណ៍នៃការងាររបស់យើងដោយផ្អែកលើវិធីសាស្រ្ត V - កម្មវិធីទូរស័ព្ទសម្រាប់អឺរ៉ុប ប្រតិបត្តិករទូរស័ព្ទចល័តដែលជួយសន្សំសំចៃថ្លៃរ៉ូមីងពេលធ្វើដំណើរ។ គម្រោងនេះត្រូវបានអនុវត្តដោយយោងតាមការបញ្ជាក់ច្បាស់លាស់ ប៉ុន្តែវារួមបញ្ចូលដំណាក់កាលសាកល្បងដ៏សំខាន់មួយ៖ ភាពងាយស្រួលនៃចំណុចប្រទាក់ មុខងារ ការផ្ទុក និងរួមទាំងការរួមបញ្ចូល ដែលគួរបញ្ជាក់ថាសមាសធាតុជាច្រើនមកពី ក្រុមហ៊ុនផលិតផ្សេងៗពួកគេធ្វើការជាមួយគ្នាដោយស្ថិរភាព ការលួចលុយ និងប្រាក់កម្ចីគឺមិនអាចទៅរួចទេ។

តើពេលណាត្រូវប្រើម៉ូដែល V?

• ប្រសិនបើការធ្វើតេស្តហ្មត់ចត់នៃផលិតផលត្រូវបានទាមទារ នោះម៉ូដែល V នឹងបង្ហាញអំពីភាពត្រឹមត្រូវនៃគំនិតរបស់វា៖ សុពលភាព និងការផ្ទៀងផ្ទាត់។
• សម្រាប់គម្រោងខ្នាតតូច និងមធ្យម ដែលតម្រូវការត្រូវបានកំណត់ច្បាស់លាស់ និងថេរ។
• នៅក្នុងលក្ខខណ្ឌនៃភាពអាចរកបាននៃវិស្វករដែលមានលក្ខណៈសម្បត្តិចាំបាច់ជាពិសេសអ្នកសាកល្បង។

3. "Incremental Model" (គំរូបន្ថែម)

នៅក្នុងគំរូបន្ថែម តម្រូវការពេញលេញប្រព័ន្ធត្រូវបានបែងចែកទៅជាសន្និបាតផ្សេងៗគ្នា។ វាក្យសព្ទត្រូវបានគេប្រើជាញឹកញាប់ដើម្បីពិពណ៌នាអំពីការផ្គុំគ្នាជាជំហាន ៗ នៃកម្មវិធី។ វដ្តនៃការអភិវឌ្ឍន៍ជាច្រើនកើតឡើង ហើយរួមគ្នាបង្កើតបានជា វដ្តជីវិត"ទឹកជ្រោះច្រើន" ។ វដ្តនេះត្រូវបានបែងចែកទៅជាម៉ូឌុលតូចៗដែលបង្កើតបានយ៉ាងងាយស្រួល។ ម៉ូឌុលនីមួយៗឆ្លងកាត់ដំណាក់កាលនៃការកំណត់តម្រូវការ ការរចនា ការសរសេរកូដ ការអនុវត្ត និងការធ្វើតេស្ត។ ដំណើរ​ការ​អភិវឌ្ឍ​បន្ថែម​ទាក់​ទង​នឹង​ការ​ចេញ​ផ្សាយ​ដំបូង ដំណាក់កាលធំផលិតផលនៅក្នុងមុខងារជាមូលដ្ឋាន ហើយបន្ទាប់មកបន្ថែមមុខងារថ្មីជាបន្តបន្ទាប់ ដែលហៅថា "ការបង្កើន"។ ដំណើរការបន្តរហូតដល់ប្រព័ន្ធពេញលេញត្រូវបានបង្កើតឡើង។

គំរូបន្ថែមត្រូវបានប្រើដែលសំណើផ្លាស់ប្តូរបុគ្គលមានភាពច្បាស់លាស់ ហើយអាចធ្វើជាផ្លូវការ និងអនុវត្តបានយ៉ាងងាយស្រួល។ នៅក្នុងគម្រោងរបស់យើង យើងបានប្រើវាដើម្បីបង្កើតកម្មវិធីអាន DefView ហើយបន្ទាប់មកបណ្តាញ បណ្ណាល័យអេឡិចត្រូនិចវីវ៉ាល់ឌី។

ជាឧទាហរណ៍ យើងនឹងរៀបរាប់អំពីខ្លឹមសារនៃការកើនឡើងមួយ។ បណ្តាញ Vivaldi នៃបណ្ណាល័យអេឡិចត្រូនិកបានជំនួស DefView ។ DefView បានភ្ជាប់ទៅម៉ាស៊ីនមេឯកសារមួយ ហើយឥឡូវនេះអាចភ្ជាប់ទៅមនុស្សជាច្រើន។ ម៉ាស៊ីនមេផ្ទុកត្រូវបានដំឡើងនៅកន្លែងនៃស្ថាប័នដែលចង់ផ្សាយមាតិការបស់វាទៅកាន់ទស្សនិកជនជាក់លាក់ ដែលចូលប្រើឯកសារដោយផ្ទាល់ និងបំប្លែងពួកវាទៅជាទម្រង់ដែលត្រូវការ។ ធាតុដើមនៃស្ថាបត្យកម្មបានបង្ហាញខ្លួន - ម៉ាស៊ីនមេកណ្តាលវីវ៉ាល់ឌី សម្តែងជាតួឯក ម៉ាស៊ីនស្វែងរកនៅទូទាំងម៉ាស៊ីនមេផ្ទុកទិន្នន័យទាំងអស់ដែលបានដំឡើងនៅក្នុងស្ថាប័នផ្សេងៗ។

ពេលណាត្រូវប្រើគំរូបន្ថែម?

• នៅពេលដែលតម្រូវការជាមូលដ្ឋានសម្រាប់ប្រព័ន្ធត្រូវបានកំណត់និងយល់យ៉ាងច្បាស់។ ក្នុងពេលជាមួយគ្នានេះ ព័ត៌មានលម្អិតមួយចំនួនអាចត្រូវបានកែលម្អតាមពេលវេលា។
• ការណែនាំផលិតផលដំបូងទៅកាន់ទីផ្សារគឺត្រូវបានទាមទារ។
• មានលក្ខណៈពិសេស ឬគោលដៅប្រថុយប្រថានមួយចំនួន។

4. “RAD Model” (គំរូអភិវឌ្ឍន៍កម្មវិធីរហ័ស ​​ឬការអភិវឌ្ឍន៍កម្មវិធីរហ័ស)

គំរូ RAD គឺជាប្រភេទនៃគំរូបន្ថែម។ នៅក្នុងគំរូ RAD សមាសធាតុ ឬមុខងារត្រូវបានបង្កើតឡើងដោយក្រុមដែលមានជំនាញខ្ពស់ជាច្រើនស្របគ្នា ដូចជាគម្រោងខ្នាតតូចមួយចំនួន។ ពេលវេលានៃវដ្តមួយត្រូវបានកំណត់យ៉ាងតឹងរ៉ឹង។ បន្ទាប់មកម៉ូឌុលដែលបានបង្កើតត្រូវបានដាក់បញ្ចូលទៅក្នុងគំរូការងារមួយ។ Synergy អនុញ្ញាតឱ្យអ្នកផ្តល់ឱ្យអតិថិជននូវអ្វីមួយដែលធ្វើការពិនិត្យឡើងវិញយ៉ាងឆាប់រហ័សដើម្បីទទួលបាន មតិកែលម្អនិងធ្វើការផ្លាស់ប្តូរ។

គំរូនៃការអភិវឌ្ឍន៍កម្មវិធីរហ័សរួមមានដំណាក់កាលដូចខាងក្រោមៈ

• គំរូអាជីវកម្ម៖ កំណត់បញ្ជីលំហូរព័ត៌មានរវាងនាយកដ្ឋានផ្សេងៗ។
• គំរូទិន្នន័យ៖ ព័ត៌មានដែលប្រមូលបានក្នុងដំណាក់កាលមុន ត្រូវបានប្រើដើម្បីកំណត់វត្ថុ និងអង្គភាពផ្សេងទៀតដែលចាំបាច់សម្រាប់ចរាចរព័ត៌មាន។
• គំរូដំណើរការ៖ លំហូរព័ត៌មានភ្ជាប់វត្ថុដើម្បីសម្រេចបាននូវគោលដៅអភិវឌ្ឍន៍។
• បង្កើតកម្មវិធី៖ ប្រើឧបករណ៍ដំឡើងស្វ័យប្រវត្តិដើម្បីបំប្លែងគំរូ CAD ទៅជាកូដ។
• ការធ្វើតេស្ត៖ សមាសធាតុ និងចំណុចប្រទាក់ថ្មីត្រូវបានសាកល្បង។

តើម៉ូដែល RAD ប្រើនៅពេលណា?

អាចប្រើបានតែជាមួយស្ថាបត្យករដែលមានសមត្ថភាព និងឯកទេសខ្ពស់ប៉ុណ្ណោះ។ ថវិកាគម្រោងមានទំហំធំដើម្បីចំណាយសម្រាប់អ្នកឯកទេសទាំងនេះរួមជាមួយនឹងការចំណាយ ឧបករណ៍ដែលត្រៀមរួចជាស្រេចការជួបប្រជុំគ្នាដោយស្វ័យប្រវត្តិ។ គំរូ RAD អាចត្រូវបានជ្រើសរើសដោយចំណេះដឹងប្រកបដោយទំនុកចិត្ត អាជីវកម្មគោលដៅនិងតម្រូវការសម្រាប់ការផលិតជាបន្ទាន់នៃប្រព័ន្ធក្នុងរយៈពេល 2-3 ខែ។

5. “Agile Model” (វិធីសាស្រ្តអភិវឌ្ឍន៍ដែលអាចបត់បែនបាន)

នៅក្នុងវិធីសាស្រ្តនៃការអភិវឌ្ឍន៍ "រហ័សរហួន" បន្ទាប់ពីការធ្វើម្តងទៀតម្តងៗ អតិថិជនអាចសង្កេតមើលលទ្ធផល និងយល់ថាតើវាពេញចិត្តគាត់ឬអត់។ នេះគឺជាអត្ថប្រយោជន៍មួយនៃគំរូដែលអាចបត់បែនបាន។ គុណវិបត្តិរបស់វារួមមានការពិតដែលថាដោយសារតែកង្វះនៃទម្រង់ជាក់លាក់នៃលទ្ធផលវាពិបាកក្នុងការប៉ាន់ប្រមាណតម្លៃពលកម្មនិងការចំណាយដែលត្រូវការសម្រាប់ការអភិវឌ្ឍន៍។ ការសរសេរកម្មវិធីខ្លាំង(XP) គឺជាកម្មវិធីមួយដែលគេស្គាល់ថាល្អបំផុតនៃម៉ូដែល agile ក្នុងការអនុវត្ត។

ប្រភេទនេះគឺផ្អែកលើការប្រជុំប្រចាំថ្ងៃខ្លី - "Scrum" និងការប្រជុំដែលកើតឡើងជាទៀងទាត់ (ម្តងក្នុងមួយសប្តាហ៍ ម្តងរៀងរាល់ពីរសប្តាហ៍ ឬម្តងក្នុងមួយខែ) ដែលហៅថា "Sprint" ។ នៅក្នុងកិច្ចប្រជុំប្រចាំថ្ងៃ សមាជិកក្រុមពិភាក្សាអំពី៖

• រាយការណ៍អំពីការងារដែលបានធ្វើចាប់តាំងពី Scrum ចុងក្រោយ;
• បញ្ជីកិច្ចការដែលនិយោជិតត្រូវបំពេញមុនការប្រជុំបន្ទាប់។
• ការលំបាកដែលបានជួបប្រទះក្នុងអំឡុងពេលការងារ។

វិធីសាស្រ្តគឺសមរម្យសម្រាប់គម្រោងធំ ឬអ្នកដែលមានបំណងក្នុងវដ្តជីវិតដ៏វែង ដោយសម្របខ្លួនជានិច្ចទៅនឹងលក្ខខណ្ឌទីផ្សារ។ ដូច្នោះហើយតម្រូវការផ្លាស់ប្តូរកំឡុងពេលដំណើរការអនុវត្ត។ វាគឺមានតំលៃចងចាំពីថ្នាក់នៃមនុស្សច្នៃប្រឌិតដែលមានទំនោរបង្កើត បង្កើត និងសាកល្បងគំនិតថ្មីៗរៀងរាល់សប្តាហ៍ ឬប្រចាំថ្ងៃ។ ការអភិវឌ្ឍន៍រហ័សរហួនគឺស័ក្តិសមបំផុតសម្រាប់អ្នកគ្រប់គ្រងចិត្តសាស្ត្រប្រភេទនេះ។ យើងអភិវឌ្ឍការចាប់ផ្ដើមផ្ទៃក្នុងរបស់ក្រុមហ៊ុនដោយប្រើ Agile ។ ឧទាហរណ៏នៃគម្រោងរបស់អតិថិជនគឺប្រព័ន្ធ Electronic Medical Examination System ដែលបង្កើតឡើងដើម្បីធ្វើការពិនិត្យសុខភាពយ៉ាងច្រើនក្នុងរយៈពេលតែប៉ុន្មាននាទីប៉ុណ្ណោះ។ នៅក្នុងកថាខណ្ឌទីពីរនៃការពិនិត្យឡើងវិញនេះ ដៃគូអាមេរិករបស់យើងបានពិពណ៌នាយ៉ាងខ្លាំង រឿងសំខាន់មូលដ្ឋានគ្រឹះនៃភាពជោគជ័យនៅក្នុង Agile ។

ពេលណាត្រូវប្រើ Agile?

• នៅពេលដែលតម្រូវការរបស់អ្នកប្រើប្រាស់កំពុងផ្លាស់ប្តូរជានិច្ចនៅក្នុងអាជីវកម្មថាមវន្ត។
• ការផ្លាស់ប្តូរ Agile ត្រូវបានអនុវត្តក្នុងការចំណាយទាប ដោយសារការកើនឡើងញឹកញាប់។
• មិនដូចគំរូទឹកជ្រោះទេ ម៉ូដែលដែលរហ័សរហួនតម្រូវឱ្យធ្វើផែនការតិចតួចប៉ុណ្ណោះ ដើម្បីយកគម្រោងនេះចេញពីដី។

6. "គំរូ​ដដែលៗ" (គំរូ​ដដែលៗ ឬ​គំរូ​ដដែលៗ)

គំរូវដ្តជីវិតដដែលៗមិនតម្រូវឱ្យមានការបញ្ជាក់តម្រូវការពេញលេញដើម្បីចាប់ផ្តើមជាមួយនោះទេ។ ផ្ទុយទៅវិញ ការបង្កើតចាប់ផ្តើមជាមួយនឹងការអនុវត្តផ្នែកនៃមុខងារ ដែលក្លាយជាមូលដ្ឋានសម្រាប់កំណត់តម្រូវការបន្ថែម។ ដំណើរការនេះត្រូវបានធ្វើម្តងទៀត។ កំណែប្រហែលជាមិនល្អឥតខ្ចោះទេ រឿងសំខាន់គឺថាវាដំណើរការ។ ដោយយល់ពីគោលដៅចុងក្រោយ យើងខិតខំដើម្បីឱ្យគ្រប់ជំហានមានប្រសិទ្ធភាព ហើយគ្រប់កំណែទាំងអស់អាចដំណើរការបាន។

ដ្យាក្រាមបង្ហាញពី "ការអភិវឌ្ឍន៍" ដដែលៗរបស់ម៉ូណាលីសា។ ដូចដែលអ្នកបានឃើញហើយ នៅក្នុងការសរសេរឡើងវិញលើកទីមួយ មានតែគំនូរព្រាងនៃ Mona Lisa ប៉ុណ្ណោះ ដែលពណ៌ទីពីរនឹងលេចឡើង ហើយការសរសេរឡើងវិញទីបី បន្ថែមព័ត៌មានលម្អិត តិត្ថិភាព និងបញ្ចប់ដំណើរការ។ នៅក្នុងគំរូបន្ថែម មុខងាររបស់ផលិតផលត្រូវបានបង្កើតឡើងជាដុំៗ ផលិតផលត្រូវបានបង្កើតឡើងដោយផ្នែក។ មិនដូចគំរូដដែលៗទេ ដុំនីមួយៗតំណាងឱ្យធាតុពេញលេញ។

ឧទាហរណ៍នៃការអភិវឌ្ឍន៍ម្តងហើយម្តងទៀតគឺការទទួលស្គាល់សំឡេង។ ការស្រាវជ្រាវដំបូង និងការរៀបចំឧបករណ៍វិទ្យាសាស្ត្របានចាប់ផ្តើមតាំងពីយូរយារណាស់មកហើយ ជាដំបូងនៅក្នុងគំនិត បន្ទាប់មកនៅលើក្រដាស។ ជាមួយនឹងការធ្វើឡើងវិញថ្មីនីមួយៗ គុណភាពនៃការទទួលស្គាល់មានភាពប្រសើរឡើង។ ទោះជាយ៉ាងណាក៏ដោយ ការទទួលស្គាល់ដ៏ល្អឥតខ្ចោះមិនទាន់សម្រេចបាននៅឡើយ ដូច្នេះហើយបញ្ហាមិនទាន់ត្រូវបានដោះស្រាយទាំងស្រុងនៅឡើយ។

តើនៅពេលណាដែលល្អបំផុតក្នុងការប្រើគំរូដដែលៗ?

• តម្រូវការសម្រាប់ ប្រព័ន្ធចុងក្រោយកំណត់ច្បាស់លាស់ និងយល់ជាមុន។
• គម្រោងនេះមានទំហំធំឬធំណាស់។
• គោលដៅសំខាន់ត្រូវតែត្រូវបានកំណត់ ប៉ុន្តែព័ត៌មានលម្អិតនៃការអនុវត្តអាចវិវត្តតាមពេលវេលា។

7. "Spiral Model" (គំរូវង់)

"គំរូវង់" គឺស្រដៀងទៅនឹងគំរូបន្ថែម ប៉ុន្តែដោយសង្កត់ធ្ងន់លើការវិភាគហានិភ័យ។ វាដំណើរការល្អសម្រាប់ការដោះស្រាយបញ្ហាអាជីវកម្មសំខាន់ៗ នៅពេលដែលការបរាជ័យមិនត្រូវគ្នានឹងសកម្មភាពរបស់ក្រុមហ៊ុន ក្នុងបរិបទនៃការចេញផ្សាយថ្មី បន្ទាត់ផលិតផលបើចាំបាច់ ការស្រាវជ្រាវវិទ្យាសាស្ត្រនិងការធ្វើតេស្តជាក់ស្តែង។

គំរូវង់មាន 4 ដំណាក់កាលសម្រាប់វេននីមួយៗ៖

1. ការធ្វើផែនការ;
2. ការវិភាគហានិភ័យ;
3. ការរចនា;
4. ការវាយតម្លៃលទ្ធផល ហើយប្រសិនបើគុណភាពពេញចិត្ត ការផ្លាស់ប្តូរទៅដំណាក់កាលថ្មីមួយ។

គំរូនេះមិនស័ក្តិសមសម្រាប់គម្រោងតូចៗទេ វាសមហេតុផលសម្រាប់គម្រោងស្មុគស្មាញ និងមានតម្លៃថ្លៃ ឧទាហរណ៍ដូចជា ការអភិវឌ្ឍន៍ប្រព័ន្ធលំហូរឯកសារសម្រាប់ធនាគារ នៅពេលដែលជំហានបន្ទាប់នីមួយៗទាមទារ។ ការវិភាគបន្ថែមទៀតដើម្បីវាយតម្លៃលទ្ធផលជាជាងការសរសេរកម្មវិធី។ នៅលើគម្រោងអភិវឌ្ឍ EDMS សម្រាប់ ODU នៃស៊ីបេរី SO UES ការប្រជុំចំនួនពីរស្តីពីការផ្លាស់ប្តូរការសរសេរកូដនៃផ្នែក បណ្ណសារអេឡិចត្រូនិចចំណាយពេល 10 ដងយូរជាងអ្នកសរសេរកម្មវិធីដែលបញ្ចូលថតពីរ។ គម្រោងរបស់រដ្ឋាភិបាលដែលយើងបានចូលរួមបានចាប់ផ្តើមជាមួយនឹងការរៀបចំដោយសហគមន៍អ្នកជំនាញនៃគោលគំនិតដែលមានតម្លៃថ្លៃ ដែលមិនមានន័យថាតែងតែគ្មានប្រយោជន៍នោះទេ ព្រោះវាចំណាយលើកម្រិតជាតិ។

ចូរយើងសង្ខេប

ស្លាយបង្ហាញពីភាពខុសគ្នារវាងវិធីសាស្រ្តទូទៅបំផុតទាំងពីរ។

IN ការអនុវត្តទំនើបគំរូអភិវឌ្ឍន៍ កម្មវិធីចម្រុះ។ មិនមានគំរូត្រឹមត្រូវសម្រាប់គម្រោងទាំងអស់ លក្ខខណ្ឌចាប់ផ្តើម និងគំរូការទូទាត់។ សូម្បីតែក្រុមហ៊ុន Agile ដែលជាទីស្រឡាញ់របស់យើងទាំងអស់គ្នា ក៏មិនអាចអនុវត្តបានគ្រប់ទីកន្លែងដែរ ដោយសារតែមិនមានការរៀបចំរបស់អតិថិជនមួយចំនួន ឬភាពមិនអាចទៅរួចនៃហិរញ្ញវត្ថុដែលអាចបត់បែនបាន។ វិធីសាស្រ្តមួយផ្នែកត្រួតលើគ្នានៅក្នុងមធ្យោបាយ និងមួយផ្នែកស្រដៀងគ្នាទៅនឹងគ្នាទៅវិញទៅមក។ គោលគំនិតផ្សេងទៀតមួយចំនួនត្រូវបានប្រើប្រាស់សម្រាប់តែផ្សព្វផ្សាយកម្មវិធីចងក្រងរបស់ពួកគេតែប៉ុណ្ណោះ ហើយមិនបាននាំមកនូវអ្វីថ្មីទៅក្នុងការអនុវត្តនោះទេ។

អំពីបច្ចេកវិទ្យាអភិវឌ្ឍន៍៖
ជាថ្មីម្តងទៀតអំពីវិធីសាស្រ្តអភិវឌ្ឍន៍សំខាន់ៗចំនួនប្រាំពីរ។
កំហុសសំខាន់ៗចំនួន 10 នៅក្នុងប្រព័ន្ធធ្វើមាត្រដ្ឋាន។
គោលការណ៍រៀបចំផែនការអភិវឌ្ឍន៍ចំនួន ៨ ដែលធ្វើឱ្យជីវិតសាមញ្ញ។
ហានិភ័យចម្បង 5 នៅក្នុងការអភិវឌ្ឍន៍កម្មវិធីផ្ទាល់ខ្លួន។

មានតែអ្នកប្រើប្រាស់ដែលបានចុះឈ្មោះប៉ុណ្ណោះដែលអាចចូលរួមក្នុងការស្ទង់មតិនេះ។ , សូម។

វិធីសាស្រ្តមួយក្នុងចំណោមវិធីសាស្រ្តនៃការអភិវឌ្ឍន៍កម្មវិធីនៅក្នុងក្របខ័ណ្ឌនៃគំរូវដ្តជីវិតតំរៀបស្លឹកគឺវិធីសាស្រ្តដែលត្រូវបានប្រើប្រាស់យ៉ាងទូលំទូលាយ (បច្ចេកវិទ្យា) សម្រាប់ការអភិវឌ្ឍន៍កម្មវិធីយ៉ាងឆាប់រហ័ស RAD (ការអភិវឌ្ឍន៍កម្មវិធីរហ័ស) ។ គំរូនេះគឺពិតជាស័ក្តិសមក្នុងការអភិវឌ្ឍន៍កម្មវិធីសិក្សា ពីព្រោះ រួមបញ្ចូលទាំងបីសមាសភាគ:

Ø ក្រុមអ្នកសរសេរកម្មវិធីតូចមួយ (ពី 2 ទៅ 10 នាក់);

Ø កាលវិភាគផលិតកម្មខ្លី ប៉ុន្តែបានធ្វើការដោយប្រុងប្រយ័ត្ន (ពី 2 ទៅ 6 ខែ);

Ø វដ្ដដដែលៗដែលអ្នកអភិវឌ្ឍន៍ នៅពេលដែលកម្មវិធីចាប់ផ្តើមមានរូបរាង ស្នើសុំ និងអនុវត្តទៅក្នុងផលិតផលតាមតម្រូវការដែលទទួលបានតាមរយៈអន្តរកម្មជាមួយអតិថិជន។

ចូរយើងពិចារណា ម៉ូដែលនេះ។នៅក្នុងលម្អិតបន្ថែមទៀត។ ក្រុមអភិវឌ្ឍន៍គួរតែជាក្រុមអ្នកជំនាញដែលមានបទពិសោធន៍ក្នុងការវិភាគ ការរចនា ការបង្កើតកូដ និងការធ្វើតេស្តកម្មវិធីដោយប្រើឧបករណ៍ CASE អាចធ្វើអន្តរកម្មបានយ៉ាងល្អជាមួយអ្នកប្រើប្រាស់ចុងក្រោយ និងបំប្លែងការផ្តល់យោបល់របស់ពួកគេទៅជាគំរូការងារ។ វដ្តជីវិតរបស់កម្មវិធីយោងទៅតាមវិធីសាស្ត្រ RAD មាន បួនដំណាក់កាល(រូបភាពទី ២១)៖

1. ការវិភាគនិងការធ្វើផែនការនៃតម្រូវការ;

2. ការរចនា;

3. សំណង់;

4. ការអនុវត្ត។

បើក ដំណាក់កាលដំបូង ការវិភាគតម្រូវការ និងផែនការអ្នក​ប្រើ​ប្រព័ន្ធ​កំណត់​មុខងារ​ដែល​វា​គួរ​អនុវត្ត គូស​បញ្ជាក់​ពី​អាទិភាព​ខ្ពស់​បំផុត​ដែល​តម្រូវ​ឱ្យ​មាន​ការ​លម្អិត​ជា​មុន​សិន និង​ពណ៌នា​អំពី​តម្រូវការ​ព័ត៌មាន (ការ​តភ្ជាប់)។ ការបង្កើតតម្រូវការប្រព័ន្ធត្រូវបានអនុវត្តជាចម្បងដោយអ្នកប្រើប្រាស់ក្រោមការណែនាំរបស់អ្នកអភិវឌ្ឍន៍ឯកទេស។ វិសាលភាពនៃគម្រោងមានកំណត់ ហើយពេលវេលាត្រូវបានបង្កើតឡើងសម្រាប់ដំណាក់កាលបន្តបន្ទាប់នីមួយៗ។ លើសពីនេះទៀតលទ្ធភាពយ៉ាងខ្លាំងនៃការអនុវត្តគម្រោងនៅក្នុង ទំហំដែលបានផ្តល់ឱ្យហិរញ្ញប្បទាន លើផ្នែករឹងដែលមានស្រាប់។ល។

លទ្ធផលនៃដំណាក់កាលគួរតែ៖បញ្ជីនៃមុខងារអាទិភាពនៃ PS នាពេលអនាគត។ គំរូមុខងារបឋមនៃ PS; គំរូព័ត៌មានបឋមរបស់ PS.

បើក ដំណាក់កាលទីពីរ ការរចនា អ្នកប្រើប្រាស់មួយចំនួនចូលរួម ការរចនាបច្ចេកទេសប្រព័ន្ធក្រោមការណែនាំរបស់អ្នកអភិវឌ្ឍន៍ឯកទេស និងធ្វើអន្តរកម្មជាមួយពួកគេ បញ្ជាក់ និងបន្ថែមតម្រូវការប្រព័ន្ធដែលមិនត្រូវបានកំណត់អត្តសញ្ញាណក្នុងដំណាក់កាលមុន។ បានពិភាក្សាលម្អិតបន្ថែមទៀត ដំណើរការប្រព័ន្ធ. បើចាំបាច់ គំរូមុខងារត្រូវបានកែតម្រូវ គំរូផ្នែកត្រូវបានបង្កើត៖ អេក្រង់ របាយការណ៍ ការលុបបំបាត់ភាពមិនច្បាស់លាស់ ឬភាពមិនច្បាស់លាស់។ តម្រូវការត្រូវបានបង្កើតឡើង ការរឹតបន្តឹងការចូលប្រើទិន្នន័យ. នៅដំណាក់កាលដូចគ្នានេះឯកសារចាំបាច់ត្រូវបានកំណត់។ បន្ទាប់ពីការកំណត់លម្អិតនៃសមាសភាពនៃដំណើរការ ចំនួននៃធាតុមុខងារនៃប្រព័ន្ធដែលកំពុងត្រូវបានបង្កើតឡើងត្រូវបានវាយតម្លៃ ហើយការសម្រេចចិត្តត្រូវបានធ្វើឡើងដើម្បីបែងចែកប្រព័ន្ធទៅជាប្រព័ន្ធរង។

លទ្ធផលនៃដំណាក់កាលនេះគួរតែជា៖គំរូព័ត៌មានទូទៅនៃប្រព័ន្ធ; គំរូមុខងារនៃប្រព័ន្ធទាំងមូល និងប្រព័ន្ធរង; ចំណុចប្រទាក់ដែលបានកំណត់យ៉ាងជាក់លាក់រវាងប្រព័ន្ធរងដែលបានអភិវឌ្ឍដោយស្វយ័ត; បង្កើតគំរូនៃអេក្រង់ របាយការណ៍ ប្រអប់។

មិនដូចវិធីសាស្រ្តបែបប្រពៃណី ដែលប្រើឧបករណ៍គំរូជាក់លាក់ដែលមិនត្រូវបានរចនាឡើងសម្រាប់បង្កើតកម្មវិធីក្នុងពិភពពិត និងបោះបង់គំរូដើមបន្ទាប់ពីពួកគេបានបម្រើគោលបំណងសម្អាតភាពមិនច្បាស់លាស់នៃការរចនា។ នៅក្នុងវិធីសាស្រ្ត RAD គំរូនីមួយៗត្រូវបានបង្កើតឡើងជាផ្នែកនៃប្រព័ន្ធអនាគត. ដូច្នេះ ព័ត៌មានពេញលេញ និងមានប្រយោជន៍ត្រូវបានផ្ទេរទៅដំណាក់កាលបន្ទាប់។

បើក ដំណាក់កាលទីបី សំណង់ ការអភិវឌ្ឍន៍យ៉ាងឆាប់រហ័សនៃកម្មវិធីខ្លួនវា (ការអនុវត្តប្រព័ន្ធរង) ត្រូវបានអនុវត្តដោយផ្ទាល់។ នៅដំណាក់កាលនេះ អ្នកអភិវឌ្ឍន៍បង្កើតប្រព័ន្ធពិតប្រាកដមួយឡើងវិញដោយផ្អែកលើគំរូដែលទទួលបានក្នុងដំណាក់កាលមុន ក៏ដូចជាតម្រូវការមិនដំណើរការ។ នៅដំណាក់កាលនេះ អ្នកប្រើប្រាស់ចុងក្រោយវាយតម្លៃលទ្ធផលដែលទទួលបាន និងធ្វើការកែតម្រូវ ប្រសិនបើក្នុងអំឡុងពេលដំណើរការអភិវឌ្ឍន៍ ប្រព័ន្ធនេះលែងបំពេញតាមតម្រូវការដែលបានកំណត់ពីមុនទៀតហើយ។ ការធ្វើតេស្តប្រព័ន្ធត្រូវបានអនុវត្តក្នុងអំឡុងពេលដំណើរការអភិវឌ្ឍន៍។

បន្ទាប់ពីការអភិវឌ្ឍន៍ប្រព័ន្ធរងត្រូវបានបញ្ចប់ ផ្នែកនៃប្រព័ន្ធនេះត្រូវបានដាក់បញ្ចូលជាបណ្តើរៗជាមួយនឹងអ្វីដែលនៅសល់ កូដកម្មវិធីពេញលេញត្រូវបានបង្កើត ហើយប្រព័ន្ធទាំងមូលត្រូវបានសាកល្បង។ ការរចនារូបវិទ្យានៃប្រព័ន្ធត្រូវបានបញ្ចប់: តម្រូវការសម្រាប់ការចែកចាយទិន្នន័យត្រូវបានកំណត់; ការវិភាគនៃការប្រើប្រាស់ទិន្នន័យត្រូវបានអនុវត្ត; ការរចនារូបវន្តនៃមូលដ្ឋានទិន្នន័យត្រូវបានអនុវត្ត; តម្រូវការសម្រាប់ធនធានផ្នែករឹងត្រូវបានកំណត់; វិធីដើម្បីបង្កើនផលិតភាពត្រូវបានកំណត់; ការអភិវឌ្ឍន៍ឯកសារគម្រោងកំពុងត្រូវបានបញ្ចប់។

លទ្ធផលនៃដំណាក់កាលគឺ ប្រព័ន្ធរួចរាល់បំពេញតាមតម្រូវការដែលបានព្រមព្រៀងទាំងអស់។

បើក ដំណាក់កាលទីបួន ការអនុវត្ត ការបណ្តុះបណ្តាលអ្នកប្រើប្រាស់ ការផ្លាស់ប្តូរអង្គភាពត្រូវបានអនុវត្ត ហើយស្របជាមួយនឹងការអនុវត្តប្រព័ន្ធថ្មី ការងារត្រូវបានអនុវត្តជាមួយ ប្រព័ន្ធដែលមានស្រាប់(រហូត​ទាល់​តែ​ថ្មី​ត្រូវ​បាន​អនុវត្ត​យ៉ាង​ពេញលេញ)។ ដោយសារដំណាក់កាលសាងសង់គឺខ្លីណាស់ ការធ្វើផែនការ និងការរៀបចំសម្រាប់ការអនុវត្តត្រូវតែចាប់ផ្តើមដំបូង ជាធម្មតាក្នុងដំណាក់កាលរចនាប្រព័ន្ធ។

បច្ចេកវិទ្យា RAD (ដូចអ្វីផ្សេងទៀត) មិនអាចអះអាងថាជាសកលទេ វាគឺជាការល្អជាចម្បងសម្រាប់គម្រោងតូចៗដែលបង្កើតឡើងសម្រាប់អតិថិជនជាក់លាក់។ វាមិនអាចអនុវត្តបានសម្រាប់ការអភិវឌ្ឍន៍ ប្រព័ន្ធប្រតិបត្តិការ; កម្មវិធីគណនាស្មុគ្រស្មាញជាមួយនឹងចំនួនដ៏ច្រើននៃកូដកម្មវិធី និងក្បួនដោះស្រាយការគ្រប់គ្រងតែមួយគត់ស្មុគស្មាញ។ កម្មវិធីដែលមិនមានផ្នែកចំណុចប្រទាក់ដែលបានកំណត់យ៉ាងច្បាស់ដែលកំណត់យ៉ាងច្បាស់នូវតក្កវិជ្ជានៃប្រព័ន្ធ (កម្មវិធីតាមពេលវេលាជាក់ស្តែង) ចាប់តាំងពីវិធីសាស្រ្តដដែលៗសន្មត់ថាកំណែមួយចំនួនដំបូងនឹងមិនបំពេញតម្រូវការពេញលេញនោះទេ។

សរុបសេចក្តីមក យើងរាយបញ្ជី គោលការណ៍ជាមូលដ្ឋាននៃបច្ចេកវិទ្យា RAD៖

Ø ការអភិវឌ្ឍន៍កម្មវិធីក្នុងទម្រង់ដដែលៗ;

Ø ការបញ្ចប់ការងារជាជម្រើសនៅដំណាក់កាលនីមួយៗនៃវដ្តជីវិត។

Ø ការចូលរួមជាចាំបាច់របស់អ្នកប្រើប្រាស់នៅដំណាក់កាលអភិវឌ្ឍន៍។

Ø ការប្រើប្រាស់គំរូដើម ដើម្បីបញ្ជាក់ និងបំពេញតម្រូវការទាំងអស់។ អ្នកប្រើប្រាស់ចុងក្រោយ;

Ø ការធ្វើតេស្ត និងការអភិវឌ្ឍន៍គម្រោងក្នុងពេលដំណាលគ្នាជាមួយនឹងការអភិវឌ្ឍន៍។

Ø ការគ្រប់គ្រងប្រកបដោយសមត្ថភាពនៃការអភិវឌ្ឍន៍ ការធ្វើផែនការច្បាស់លាស់ និងការត្រួតពិនិត្យការអនុវត្តការងារ។

សំណួរសុវត្ថិភាពដល់ជំពូកទី៣៖

1. តើអ្វីជាស្តង់ដារ និងវិញ្ញាបនប័ត្រនៃផលិតផលសូហ្វវែរ?

2. តើស្តង់ដារប្រភេទណាខ្លះ?

3. រាយបញ្ជីស្តង់ដារវដ្តជីវិតដ៏ល្បីល្បាញបំផុតដែលត្រូវបានប្រើប្រាស់សម្រាប់ការអភិវឌ្ឍន៍កម្មវិធី?

4. តើវដ្តជីវិតរបស់កម្មវិធីគឺជាអ្វី?

5. រាយបញ្ជីដំណាក់កាលសំខាន់ៗនៃវដ្តជីវិតរបស់កម្មវិធី។ តើអ្វីជាដំណើរការ សកម្មភាព កិច្ចការ?

6. តើដំណើរការប្រភេទ និងដំណើរការជាក់លាក់អ្វីខ្លះដែលអ្នកចងចាំ?

7. ពន្យល់ពីដំណើរការវិស្វកម្មជាមូលដ្ឋាននៃវដ្តជីវិតរបស់កម្មវិធី។

8. តើអ្វីជាគំរូវដ្តជីវិតរបស់កម្មវិធី? ផ្តល់និយមន័យនៃគោលគំនិតមូលដ្ឋានដែលទាក់ទងនឹងគំនិតនៃ "គំរូ" ។

9. តើអ្នកស្គាល់ម៉ូដែលអ្វីខ្លះ? តើអ្វីជាគុណសម្បត្តិ គុណវិបត្តិ វិសាលភាពនៃការអនុវត្ត?

10. តើអ្នកអាចនិយាយអ្វីខ្លះអំពីលក្ខណៈពិសេសនៃគំរូវដ្តជីវិតទឹកជ្រោះ?

11.តើអ្វីជាភាពខុសគ្នារវាងគំរូល្បាក់ទូទៅ និងមូលដ្ឋាន?

12. តើអ្នកអាចនិយាយអ្វីខ្លះអំពីលក្ខណៈពិសេសនៃគំរូវដ្តជីវិតវង់?

13. រាយធាតុផ្សំនៃបច្ចេកវិទ្យា RAD ។ តើបច្ចេកវិទ្យា RAD អាចប្រើកម្មវិធីប្រភេទណាដើម្បីអភិវឌ្ឍ?

14. ពិពណ៌នាអំពីដំណាក់កាលសំខាន់ៗនៃវដ្តជីវិតបច្ចេកវិទ្យា RAD ។

15. រាយគោលការណ៍ជាមូលដ្ឋាននៃបច្ចេកវិទ្យា RAD ។

ឯកសារយោង

1. Aptekar M.D., Ramazanov S.K., Freger G.E. ប្រវត្តិសកម្មភាពវិស្វកម្ម។ – Kyiv, 2003. – 204 ទំ។ ៖ ឈឺ។

2. Archibald R. គំរូវដ្តជីវិតនៃគម្រោងបច្ចេកវិទ្យាខ្ពស់។ http://www.pmprofy.ru/content/rus/107/1073-article.html

3. Brooks F. បុរសទេវកថាខែឬរបៀបដែលពួកគេត្រូវបានបង្កើតឡើង ប្រព័ន្ធកម្មវិធី. - សាំងពេទឺប៊ឺគ។ ៖ Symbol-plus, 1999. – 321 p. ៖ ឈឺ។

4. Butch G. ការរចនាតម្រង់ទិសវត្ថុជាមួយនឹងឧទាហរណ៍នៃកម្មវិធី។ - M.: Concord, 1992. – 586 ទំ។ ៖ ឈឺ។

5. Butch G. ការវិភាគតម្រង់ទិសវត្ថុ និងការរចនាតម្រង់ទិសវត្ថុក្នុង C++ ។ – M.: Binom, – 2001. – 558 ទំ។ ៖ ឈឺ។

6. បច្ចេកវិទ្យា Vendrov A. M. CASE ។ វិធីសាស្រ្តទំនើបនិងឧបករណ៍រចនាប្រព័ន្ធព័ត៌មាន។ – អិមៈ ហិរញ្ញវត្ថុ និងស្ថិតិ ឆ្នាំ ១៩៩៩ – ២៥៦ ទំ។ ៖ ឈឺ។

7. Wirth N. Algorithms + data structures = programs: Transl. ពីភាសាអង់គ្លេស - M.: Mir, 1985. – 406 p.: ឈឺ។

8. Dahl O., Dijkstra E., Hoor K. ការសរសេរកម្មវិធីដែលមានរចនាសម្ព័ន្ធ៖ បកប្រែ។ ពីភាសាអង់គ្លេស - M.: Mir, 1975. – 247 ទំ។ ៖ ឈឺ។

9. Dzerzhinsky F.Ya., Kalinichenko I.M. វិន័យកម្មវិធី៖ គំនិត និងបទពិសោធន៍ក្នុងការអនុវត្តឧបករណ៍វិធីសាស្រ្តនៃវិស្វកម្មកម្មវិធី។ – M.: វិទ្យាស្ថានស្រាវជ្រាវកណ្តាលនៃព័ត៌មាន និងស្រាវជ្រាវបច្ចេកទេស និងសេដ្ឋកិច្ចក្នុងវិទ្យាសាស្ត្រ និងបច្ចេកវិទ្យានុយក្លេអ៊ែរ ឆ្នាំ ១៩៨៨ – ២៤៥ ទំ។ ៖ ឈឺ។

10. Zhogolev E.A. បច្ចេកវិទ្យាសរសេរកម្មវិធី។ – អិមៈ ពិភពវិទ្យាសាស្ត្រ ឆ្នាំ ២០០៤ – ២១៦ ទំ។ ៖ ឈឺ។

11. ច្បាប់នៃសហព័ន្ធរុស្ស៊ីលេខ 149-FZ ថ្ងៃទី 29 ខែកក្កដាឆ្នាំ 2006 ។ "អំពីព័ត៌មាន បច្ចេកវិទ្យាព័ត៌មាននិងការការពារព័ត៌មាន” // Rossiyskaya Gazeta លេខ 165 នៃថ្ងៃទី 27 ខែកក្កដាឆ្នាំ 2006 ។

12. Ivanova G. S. បច្ចេកវិទ្យាសរសេរកម្មវិធី៖ សៀវភៅសិក្សាសម្រាប់សាកលវិទ្យាល័យ។ - ទី 2 ed., stereotype ។ - អិមៈ គ្រឹះស្ថានបោះពុម្ព MSTU អ៊ឹម។ N.E. Bauman, 2003. – 320 pp.: ill.

13. Kalyanov G. N. ករណី៖ ការវិភាគប្រព័ន្ធរចនាសម្ព័ន្ធ (ស្វ័យប្រវត្តិកម្ម និងកម្មវិធី)។ – អិមៈ “ឡូរី” ឆ្នាំ ១៩៩៦ – ៣៥៦ ទំ។ ៖ ឈឺ។

14. Korablin M.A. កម្មវិធីតម្រង់ទិសវត្ថុ៖ សៀវភៅសិក្សា។ – សាម៉ារ៉ា៖ គ្រឹះស្ថានបោះពុម្ព SSAU ឆ្នាំ ១៩៩៤ – ៩៤ ទំ។

15. Leonenkov A.V. សៀវភៅណែនាំដោយខ្លួនឯង UML ។ – សាំងពេទឺប៊ឺគៈ VHV St. Petersburg, – 2001. – 304 ទំ។ ៖ ឈឺ។

16. Lipaev V.V. – M. : ហិរញ្ញវត្ថុ និងស្ថិតិ ឆ្នាំ 1983 – 263 ទំ។ ៖ ឈឺ។

17. Lipaev V.V. ការបំបាត់កំហុស កម្មវិធីស្មុគស្មាញ៖ វិធីសាស្រ្ត មធ្យោបាយ បច្ចេកវិទ្យា។ – អិម : Energoatomizdat, 1993. – 384 ទំ។ ៖ ឈឺ។

18. Lipaev V.V., Filippov E.N. ភាពចល័តនៃកម្មវិធីនិងទិន្នន័យនៅក្នុងបើកចំហ ប្រព័ន្ធព័ត៌មាន. - អិមៈ សៀវភៅវិទ្យាសាស្ត្រ ឆ្នាំ ១៩៩៧ - ២៩៧ ទំ។ ៖ ឈឺ។

20. Ozhegov S.I. វចនានុក្រមនៃភាសារុស្ស៊ី។ – អិមៈ សន្តិភាព និងការអប់រំ ឆ្នាំ ២០០៦ – ១៣២៨ ទំ។

21. បច្ចេកវិទ្យាសម្រាប់ការរចនាស្មុគ្រស្មាញកម្មវិធីប្រព័ន្ធគ្រប់គ្រងស្វ័យប្រវត្តិ / V. V. Lipaev, L. A. Serebrovsky, P. G. Gaganov ជាដើម; អេដ។ Yu.V. Afanasyeva, V.V. Lipaeva ។ - អិមៈ វិទ្យុ និងទំនាក់ទំនង ឆ្នាំ ១៩៨៣ – ២៥៦ ទំ។ ៖ ឈឺ។

22. Hyvenen E., Seppanen J. ពិភពនៃ LISP: Transl ។ ពីហ្វាំងឡង់ នៅក្នុង 2 ភាគ T.1: ការណែនាំអំពីភាសា Lisp និង កម្មវិធីមុខងារ.– អិមៈ Mir, 1990. – 447 ទំ។ ៖ ឈឺ។

23. Hyvenen E., Seppanen J. ពិភពនៃ LISP: Transl ។ ពីហ្វាំងឡង់ នៅក្នុង 2 ភាគ T.2: វិធីសាស្រ្តនិងប្រព័ន្ធនៃការសរសេរកម្មវិធី - M.: Mir, 1990. - 319 ទំ។ ៖ ឈឺ។

24. Boehm B. “A Spiral Model of Software Development and Enhancement,” IEEE Computer, Vol. 21, ទេ។ 5, ទំ។ ៦១–៧២, ១៩៨៨។

25. Courtois P. June 1985. On Time and Space Decomposition of Complex Structures. ការទំនាក់ទំនងរបស់ ACM vol.28(6), p.596 ។

26. លក្ខណៈវិនិច្ឆ័យសម្រាប់ការវាយតម្លៃនៃកម្មវិធី។ ISO TC97/SC7 #383។

27. Dijktra E. 1979. ការសរសេរកម្មវិធីចាត់ទុកថាជាសកម្មភាពរបស់មនុស្ស។ បុរាណក្នុងវិស្វកម្មកម្មវិធី។ ញូវយ៉ក, ញូវយ៉ក: សារព័ត៌មាន Yourdon ។

28. http://www.pmi.ru/glossary/ ។

29. http://www.staratel.com/iso/InfTech/DesignPO/ISO12207/ISO12207-99/ISO12207.htm ។

30. សាជីវកម្ម Microsoft ។ គោលការណ៍នៃការរចនា និងការអភិវឌ្ឍន៍កម្មវិធី។ វគ្គបណ្តុះបណ្តាល MCSD៖ បកប្រែ។ ពីភាសាអង់គ្លេស – អិមៈ ផ្ទះបោះពុម្ព និងពាណិជ្ជកម្ម “ការបោះពុម្ពរុស្ស៊ី” ឆ្នាំ ២០០០ – ៦០៨ ទំ។ ៖ ឈឺ។

31. Parnas D., Clements P., Weiss D. 1983. ការបង្កើនលទ្ធភាពប្រើប្រាស់ឡើងវិញជាមួយនឹងការលាក់ព័ត៌មាន។ ដំណើរការនៃសិក្ខាសាលាស្តីពីលទ្ធភាពប្រើប្រាស់ឡើងវិញក្នុងការសរសេរកម្មវិធី។ Stratford, CT: ការសរសេរកម្មវិធី ITT ។ ទំ.២៤១.

32. Rechtin E. ខែតុលា 1992. សិល្បៈនៃស្ថាបត្យកម្មប្រព័ន្ធ។ វិសាលគម IEEE, vol.29(10), p.66 ។

33. Royce W.W. គ្រប់គ្រងការអភិវឌ្ឍន៍ប្រព័ន្ធកម្មវិធីធំៗ។ http://facweb.cti.depaul.edu/jhuang/is553/Royce.pdf ។

34. Shaw M. October 1984. Abstraction Techniques in Modern Programming Languages. កម្មវិធី IEEE vol.1(4).

35. Simon H. 1982. The Sciences of the Artificial. Cambridge, MA: សារព័ត៌មាន MIT ។ – ទំ.២១៨។

36. Sommerville I. វិស្វកម្មកម្មវិធី។ – ក្រុមហ៊ុនបោះពុម្ព Addison-Wesley ឆ្នាំ 1992 ទំព័រ 87 ។

37. Tesler L. ខែសីហា 1981. បរិស្ថាន Smalltalk ។ Byte vol.6(8), p.142.

38. Yonezawa A., Tokoro M. 1987. Objectt-Oriented Concurrent Programming. Cambridge, MA: សារព័ត៌មាន MIT ។

បញ្ជីនៃលក្ខខណ្ឌ

ជម្រើសនៃវិធីសាស្រ្តអភិវឌ្ឍន៍កម្មវិធីក្លាយជាកិច្ចការលេខ 1 ក្នុងលក្ខខណ្ឌ កំណើនលឿនទីផ្សារ។ នេះ​បើ​តាម​ការ​សិក្សា 310 ពាន់លានដុល្លារអាមេរិកត្រូវបានចំណាយលើកម្មវិធីសហគ្រាសនៅទូទាំងពិភពលោកក្នុងឆ្នាំ 2015 ។ ការអភិវឌ្ឍន៍គំនិតRAD (ការអភិវឌ្ឍន៍កម្មវិធីរហ័ស)បានក្លាយជាមូលដ្ឋានសម្រាប់បង្កើតភាពបត់បែន ប្រព័ន្ធសម្របខ្លួនការអភិវឌ្ឍន៍កម្មវិធីដែលនឹងជាការប្រឆាំងទៅនឹងគំរូ "ទឹកជ្រោះ" រឹង។

RAD គឺជាគំរូនៃការអភិវឌ្ឍន៍កម្មវិធីយ៉ាងឆាប់រហ័ស ដែលផ្តោតលើល្បឿន និងភាពងាយស្រួលនៃការសរសេរកម្មវិធី។

ការលេចឡើងនៃ RAD

យើងអាចអរគុណចំពោះភាពមិនល្អឥតខ្ចោះនៃគំរូគ្រួសារសម្រាប់ការលេចឡើងនៃការអភិវឌ្ឍន៍កម្មវិធីយ៉ាងឆាប់រហ័ស ទឹកជ្រោះនៅពេលបង្កើតកម្មវិធី។ រឿងនេះគឺថាដំបូងឡើយប្រព័ន្ធអភិវឌ្ឍន៍ទឹកជ្រោះត្រូវបានផ្អែកលើគំរូវិស្វកម្មប្រពៃណីដែលបានប្រើ សម្រាប់ការរចនា និងសាងសង់អគារ និងស្ពាន។

ខណៈពេលដែល Waterfall ត្រូវបានផ្អែកលើរចនាសម្ព័ន្ធរឹងនៃសកម្មភាពអភិវឌ្ឍន៍ជាបន្តបន្ទាប់ ការលេចឡើងនៃ RAD គឺជាការប៉ុនប៉ងដើម្បីបង្កើតដំណើរការដែលអាចបត់បែនបានដែលអាចប្រើប្រាស់ចំណេះដឹងដែលទទួលបានក្នុងអំឡុងពេលវដ្តជីវិតរបស់គម្រោង។

កំណែដំបូងនៃ RAD ត្រូវបានបង្កើតឡើងដោយ Barry Boehm ក្នុងឆ្នាំ 1986 ដែលបានហៅវាថា "គំរូវង់" ។វេននីមួយៗនៃវង់ត្រូវបានបែងចែកជា 4 វិស័យហើយត្រូវគ្នាទៅនឹងការអភិវឌ្ឍន៍នៃបំណែកឬកំណែនៃកម្មវិធី។ ជាមួយនឹងវេនថ្មីនីមួយៗមានការធ្វើឱ្យស៊ីជម្រៅ និងការបញ្ជាក់អំពីគោលដៅ និងលក្ខណៈជាក់លាក់នៃគម្រោង។ ជាលទ្ធផល វាអាចជ្រើសរើសជម្រើសដែលមានព័ត៌មាន។

ដោយប្រើគំនិតរបស់ Barry, ជនជាតិអង់គ្លេស James Martin បានបង្កើតប្រព័ន្ធ RAD របស់គាត់។ពេលកំពុងធ្វើការក្នុងទសវត្សរ៍ឆ្នាំ 1980 នៅក្រុមហ៊ុន IBM ហើយទីបំផុតបានបង្កើតវាទៅជា "ការអភិវឌ្ឍន៍កម្មវិធីរហ័ស" ក្នុងឆ្នាំ 1991។

ជាការពិត មានការយល់ច្រលំខ្លះអំពីអត្ថន័យនៃពាក្យ "RAD" សូម្បីតែក្នុងចំណោមអ្នកជំនាញផ្នែកព័ត៌មានវិទ្យាក៏ដោយ។ បន្ទាប់ពីបានទាំងអស់, យើងបាននិយាយអំពីគំនិតពីរ: RAD ជាជម្រើសដ៏មានប្រសិទ្ធភាពមួយចំពោះទឹកជ្រោះនិង RAD ជាវិធីសាស្រ្តជាក់លាក់មួយដែលត្រូវបានបង្កើតឡើងដោយម៉ាទីន។ក្រោយមកទៀតត្រូវបានកែសម្រួលទៅប្រព័ន្ធអាជីវកម្មដែលពឹងផ្អែក UI ។

ក្រោយមក គំនិតត្រូវបានបង្កើតឡើង និងកែលម្អ អ្នកត្រួសត្រាយផ្លូវ RAD លោក James Kerr និង Richard Hunterនៅក្នុងការសហការគ្នា "Inside RAD" ដែលបានកត់ត្រាដំណើររបស់អ្នកគ្រប់គ្រងគម្រោងនៅពេលដែលគាត់បានរៀន និងអនុវត្តវិធីសាស្រ្តអភិវឌ្ឍន៍កម្មវិធីរហ័សក្នុងជីវិតពិតសម្រាប់គម្រោងពិត។

គំរូវង់គឺជាដំណើរការអភិវឌ្ឍកម្មវិធីដែលរួមបញ្ចូលគ្នានូវការរចនា និងការបង្កើតគំរូតាមដំណាក់កាល។

មូលដ្ឋានគ្រឹះ (គោលការណ៍) នៃការអភិវឌ្ឍន៍កម្មវិធីរហ័ស

គោលការណ៍ RAD ផ្តោតលើការផ្តល់នូវអត្ថប្រយោជន៍ស្នូលនៃការអភិវឌ្ឍន៍កម្មវិធីយ៉ាងឆាប់រហ័ស៖

• បង្កើនល្បឿននៃការអភិវឌ្ឍន៍
• តម្លៃទាប
• គុណភាពខ្ពស់។

ជាមួយ ចំណុចចុងក្រោយបញ្ហាភាគច្រើនកើតឡើងដោយសារតែអ្នកអភិវឌ្ឍន៍ និងអតិថិជនមើលឃើញប្រធានបទនៃការអភិវឌ្ឍន៍ខុសគ្នា។

ដើម្បីលុបបំបាត់បញ្ហានេះ និងបញ្ហាផ្សេងទៀត លោក James Martin និងអ្នកដើរតាមរបស់គាត់បានកំណត់គោលការណ៍ RAD ខាងក្រោម៖

• កាត់បន្ថយការចំណាយពេលវេលា- កញ្ចប់ឧបករណ៍គួរមានគោលបំណងកាត់បន្ថយពេលវេលាអភិវឌ្ឍន៍
• គំរូដើម- ការបង្កើតគំរូដើម ដើម្បីបញ្ជាក់តម្រូវការអតិថិជន
• ការអភិវឌ្ឍវដ្ត- កំណែថ្មីនីមួយៗនៃផលិតផលគឺផ្អែកលើការវាយតម្លៃនៃលទ្ធផលនៃការងារ កំណែមុន។អតិថិជន
• កិច្ចសហប្រតិបត្តិការ- ក្រុមអភិវឌ្ឍន៍ត្រូវតែធ្វើអន្តរកម្មយ៉ាងជិតស្និទ្ធជាមួយគ្នាទៅវិញទៅមក សមាជិកនីមួយៗត្រូវតែត្រៀមខ្លួនដើម្បីអនុវត្តទំនួលខុសត្រូវច្រើន។
• វិធីសាស្រ្តដដែលៗដល់ការអភិវឌ្ឍន៍
• ការរួមបញ្ចូលគ្នាការធ្វើតេស្តនិងការអភិវឌ្ឍន៍ប្រព័ន្ធ។

គោលការណ៍ RAD ត្រូវបានប្រើមិនត្រឹមតែក្នុងអំឡុងពេលអនុវត្តប៉ុណ្ណោះទេ ប៉ុន្តែថែមទាំងពង្រីកដល់គ្រប់ដំណាក់កាលនៃវដ្តជីវិត ជាពិសេសដល់ដំណាក់កាលនៃការស្ទង់មតិរបស់អង្គការ ការសាងសង់តម្រូវការ ការវិភាគ និងការរចនា។

វដ្តជីវិតរបស់កម្មវិធីយោងទៅតាម RAD

ក្នុងអំឡុងពេលដំណើរការ RAD កម្មវិធីមួយឆ្លងកាត់បួនដំណាក់កាល។

ដំណាក់កាលនៃការវិភាគតម្រូវការ និងផែនការ

តម្រូវការ មុខងារកម្មវិធី និងអាទិភាពរបស់ពួកគេត្រូវបានកំណត់ តម្រូវការព័ត៌មានត្រូវបានពិពណ៌នា។ ដំណាក់កាលនេះត្រូវបានអនុវត្តជាចម្បងដោយអ្នកប្រើប្រាស់ដោយមានការចូលរួមពីអ្នកអភិវឌ្ឍន៍។ នៅដំណាក់កាលនេះ មាត្រដ្ឋាននៃគម្រោង ពេលវេលា និងក្របខ័ណ្ឌហិរញ្ញវត្ថុ និងវេទិកាសម្រាប់ការបើកដំណើរការកម្មវិធីក៏ត្រូវបានចង្អុលបង្ហាញផងដែរ។

ក្រុមហ៊ុន Beverly Flowers ត្រូវការកម្មវិធីសម្រាប់ការបញ្ជាទិញផ្កាតាមអ៊ីនធឺណិតទៅផ្ទះរបស់អ្នក។ ពេលវេលាបង្កើតគឺ 50 ថ្ងៃ ថវិកាគឺ 3,000 ដុល្លារ។

ដំណាក់កាលរចនា

អ្នកប្រើប្រាស់មួយចំនួនចូលរួមក្នុងការរចនាបច្ចេកទេសនៃប្រព័ន្ធក្រោមការណែនាំរបស់អ្នកអភិវឌ្ឍន៍។ ក្រុម RAD ឬក្រុមរងក្នុងដំណាក់កាលនេះជាធម្មតាប្រើការរួមបញ្ចូលគ្នានៃបច្ចេកទេសជាមួយ ការអភិវឌ្ឍន៍កម្មវិធីសហការ (JAD) និង ឧបករណ៍ CASE ដើម្បីបកប្រែតម្រូវការរបស់អ្នកប្រើប្រាស់ទៅជាគំរូការងារ។

JAD (Joint Application Development) គឺជាគំនិតនៃការអភិវឌ្ឍន៍កម្មវិធីរួមគ្នា ដែលក្នុងនោះមានអន្តរកម្មយ៉ាងជិតស្និទ្ធរវាងអតិថិជន និងអ្នកអនុវត្តសម្រាប់អតិបរមា។ ដំណោះស្រាយដ៏មានប្រសិទ្ធភាពបញ្ហាទាក់ទងនឹងកម្មវិធីដែលកំពុងត្រូវបានបង្កើតឡើង។

Case គឺជាសំណុំនៃឧបករណ៍ និងវិធីសាស្រ្តសម្រាប់ការរចនាកម្មវិធី ដើម្បីធានាបាននូវផលិតផលកម្មវិធីដែលមានគុណភាពខ្ពស់ គ្មានកំហុស និងងាយស្រួលក្នុងការថែទាំ។

ក្នុងដំណាក់កាលរចនា អ្នកប្រើប្រាស់អាចយល់ កែប្រែ និងកំណត់គំរូការងារនៃប្រព័ន្ធដែលសាកសមនឹងតម្រូវការរបស់ពួកគេ។ ដំណើរការនីមួយៗត្រូវបានពិចារណាយ៉ាងលម្អិតហើយប្រសិនបើចាំបាច់ត្រូវបានបង្កើតឡើងគំរូដោយផ្នែក .

ជាលទ្ធផលដំណាក់កាលត្រូវបានបង្កើតឡើង:

• គំរូព័ត៌មានទូទៅនៃកម្មវិធី
• គំរូមុខងារនៃប្រព័ន្ធ និងប្រព័ន្ធរង
• គំរូការងារនៃអេក្រង់ របាយការណ៍ និងប្រអប់។

ប្រសិនបើឧបករណ៍អភិវឌ្ឍន៍គំរូមិនគ្រប់គ្រាន់ក្នុងម៉ូដែលមុនៗ កម្មវិធីពិតហើយបន្ទាប់មក ពួកវាមិនត្រូវបានប្រើប្រាស់ទៀតទេ នៅ RAD គំរូនីមួយៗក្លាយជាផ្នែកនៃប្រព័ន្ធអនាគត។

ដូច្នេះនៅក្នុងកម្មវិធី Beverly Flowers អ្នកប្រើប្រាស់គួរតែមានសិទ្ធិចូលប្រើជម្រើសដូចខាងក្រោមៈ "ទំព័រដើម" "ការស្វែងរកផ្កា" "មើលបញ្ជីផ្កា" ។

Freeware SpringToolSuite ត្រូវ​បាន​ជ្រើសរើស​ជា​វេទិកា​អភិវឌ្ឍន៍ ដែល​មាន​គំរូ​ជាច្រើន​ដែល​មាន​ជា​បំណែក​នៃ​កូដ។
ជាម៉ាស៊ីនមេ - Apache Tomcat 6.0.

ដំណាក់កាលសាងសង់

នៅដំណាក់កាលនេះ ការអភិវឌ្ឍន៍យ៉ាងឆាប់រហ័សភ្លាមៗកើតឡើងដោយផ្អែកលើលទ្ធផលដែលទទួលបានក្នុងដំណាក់កាលមុន។ ក្នុងពេលជាមួយគ្នាអ្នកប្រើប្រាស់បន្តចូលរួម នៅក្នុងការអភិវឌ្ឍន៍ប្រព័ន្ធ ស្នើការផ្លាស់ប្តូរ និងការកែលម្អកម្មវិធី។ ការធ្វើតេស្តកម្មវិធីក៏កើតឡើងក្នុងអំឡុងពេលអភិវឌ្ឍន៍។

កម្មវិធី "Beverly Flowers" ត្រូវបានប្រមូលផ្តុំពីសមាសធាតុមុខងារបី - ការផ្លាស់ប្តូររបស់អ្នកប្រើទៅជា " ទំព័រដើម", "រកមើលពណ៌" និង "មើលបញ្ជីពណ៌" ។
សម្រាប់ការអភិវឌ្ឍន៍ គំរូការងារវាចំណាយពេល 1 អ្នកឯកទេសនិង 8 ថ្ងៃ។

ដំណាក់កាលនៃការអនុវត្ត

គ្របដណ្តប់លើការបណ្តុះបណ្តាលអ្នកប្រើប្រាស់ ការធ្វើតេស្ត និង ការជំនួស ប្រព័ន្ធចាស់សម្រាប់ថ្មីមួយ. ការរៀបចំសម្រាប់ដំណាក់កាលនេះចាប់ផ្តើមជាមួយនឹងដំណាក់កាលរចនា។

ពីមុន Beverly Flowers បានទទួលយកការបញ្ជាទិញដោយផ្ទាល់នៅចំនុចលក់ និងតាមទូរស័ព្ទ។

ដោយការកត់ត្រាសារអំពីលទ្ធភាពនៃការបញ្ជាទិញតាមរយៈ កម្មវិធីពិសេសហើយ​ដោយ​ការ​ដាក់​ព័ត៌មាន​នៅ​ចំណុច​លក់ ក្នុង​រយៈ​ពេល 2 សប្តាហ៍​យើង​បាន​គ្រប់គ្រង​ប្តូរ​អ្នក​ទិញ​មួយ​ចំនួន​ទៅ ឆានែលថ្មី។ការលក់

ទន្ទឹមនឹងនេះចំណែកនៃការបញ្ជាទិញតាមទូរស័ព្ទបានថយចុះតាមសមាមាត្រដែលមានន័យថាវាអាចកាត់បន្ថយបុគ្គលិកនៃអ្នកគ្រប់គ្រងសេវាកម្មអតិថិជន។

គួរកត់សម្គាល់ថាមិនដូចទឹកជ្រោះទេ វដ្តជីវិតរបស់គម្រោងនេះបើយោងតាមវិធីសាស្ត្រ RAD គឺមិនរឹង។ អាស្រ័យលើលក្ខខណ្ឌចាប់ផ្តើមចំនួនដំណាក់កាលអាចថយចុះក៏ដូចជាការបំពេញរបស់វា។

គុណសម្បត្តិ និងគុណវិបត្តិនៃការអភិវឌ្ឍន៍កម្មវិធីយ៉ាងឆាប់រហ័សនៅក្នុងក្រុមហ៊ុនរបស់អ្នក។

ថាតើត្រូវប្រើការអភិវឌ្ឍន៍កម្មវិធីរហ័សឬអត់ ភាគច្រើនអាស្រ័យលើលក្ខខណ្ឌចាប់ផ្តើម តម្រូវការអតិថិជន និងប្រភេទនៃកម្មវិធី។

គុណសម្បត្តិច្បាស់លាស់នៃ RAD រួមមាន:

1. គុណភាពខ្ពស់។អន្តរកម្មរបស់អ្នកប្រើជាមួយនឹងគំរូដើមជួយបង្កើនមុខងារនៃគម្រោងអភិវឌ្ឍន៍កម្មវិធីយ៉ាងឆាប់រហ័ស។ កម្មវិធីបែបនេះអាចបំពេញតម្រូវការរបស់អតិថិជន (អ្នកប្រើប្រាស់ចុងក្រោយ) បានប្រសើរជាងការប្រើវិធីសាស្ត្រ Agile/Waterfall។
2. ការគ្រប់គ្រងហានិភ័យ- ទោះបីជាការពិតដែលថា ចំណែករបស់សត្វតោ សម្ភារៈអំពី RAD ផ្តោតលើ ល្បឿននិង ការចូលរួមអ្នកប្រើប្រាស់ជា លក្ខណៈសំខាន់ៗគំរូ អត្ថប្រយោជន៍សំខាន់ទីបីមិនអាចបដិសេធបានទេ។ — ការកាត់បន្ថយហានិភ័យ. គួរឱ្យចាប់អារម្មណ៍ Boehm ដែលបានបង្កើតកំណែដំបូងនៃ RAD បានពណ៌នាគំរូវង់ថាជាហានិភ័យ។
   ការប្រើប្រាស់ការអភិវឌ្ឍន៍កម្មវិធីយ៉ាងឆាប់រហ័សអនុញ្ញាតឱ្យអ្នកផ្តោតលើកត្តាហានិភ័យចម្បង និងសម្របខ្លួនទៅនឹងពួកគេនៅដំណាក់កាលដំបូង។
3. គម្រោងជាច្រើនទៀតត្រូវបានបញ្ចប់ក្នុងមួយឯកតានៃពេលវេលាក្នុងថវិកា- ចាប់តាំងពី RAD បង្កប់ន័យ គំរូអភិវឌ្ឍន៍បន្ថែម, ឱកាសសម្រាប់ កំហុសសំខាន់ដែលជារឿយៗកើតឡើងនៅក្នុងគម្រោងទឹកជ្រោះធំៗ ត្រូវបានកាត់បន្ថយ។
   ប្រសិនបើនៅក្នុងគម្រោងប្រព័ន្ធទឹកជ្រោះ ការអនុវត្តគម្រោងគឺអាចធ្វើទៅបានបន្ទាប់ពីការវិភាគ និងការអភិវឌ្ឍន៍រយៈពេលប្រាំមួយខែ ឬច្រើនជាងនេះ បន្ទាប់មកនៅក្នុង RAD ព័ត៌មានចាំបាច់ទាំងអស់ត្រូវបានបង្ហាញមុននេះ កំឡុងពេលបង្កើតកម្មវិធីដោយខ្លួនឯង។

គំរូអភិវឌ្ឍន៍បន្ថែមគឺជាទម្រង់អភិវឌ្ឍន៍កម្មវិធីដែលពាក់ព័ន្ធនឹងការបែងចែកផលិតផលទៅជាសមាសធាតុឯករាជ្យ។ ក្រោយមកទៀតត្រូវបានបង្កើតឡើងនិងដាក់ឱ្យដំណើរការដោយឡែកពីគ្នា។

មិនមែនដោយគ្មានគុណវិបត្តិរបស់វា។

គុណវិបត្តិនៃការអភិវឌ្ឍន៍កម្មវិធីរហ័សរួមមាន:

1. ហានិភ័យនៃ "ភាពថ្មីថ្មោង"- សម្រាប់ក្រុមហ៊ុន IT ភាគច្រើន RAD គឺជាផលិតផលថ្មីដែលតម្រូវឱ្យគិតឡើងវិញនូវវិធីសាស្រ្តធ្វើការធម្មតា។ ភាពធន់នឹងអ្វីដែលថ្មី និងតម្រូវការក្នុងការរៀនឧបករណ៍ និងបច្ចេកទេសពីទទេ នាំឱ្យមានកំហុសកំឡុងពេលអនុវត្តដំបូងនៃការអភិវឌ្ឍន៍កម្មវិធីយ៉ាងឆាប់រហ័ស។
2. ប្រសិនបើអ្នកប្រើប្រាស់មិនអាចចូលរួមជាបន្តបន្ទាប់ក្នុងដំណើរការអភិវឌ្ឍន៍ពេញមួយវដ្តជីវិតទាំងមូល វាអាចជះឥទ្ធិពលអវិជ្ជមានដល់ផលិតផលចុងក្រោយ - លក្ខណៈពិសេសរបស់ RAD គឺបង្កើនអន្តរកម្មរវាងអ្នកប្រើប្រាស់ និងអ្នកអភិវឌ្ឍន៍ មិនដូចម៉ូដែល Waterfall ដែលតួនាទីរបស់អ្នកប្រើប្រាស់ត្រូវបានកាត់បន្ថយក្នុងការកំណត់តម្រូវការ។ . បន្ទាប់មកអ្នកអភិវឌ្ឍន៍បង្កើតប្រព័ន្ធដោយខ្លួនឯង។
3. កាត់បន្ថយការគ្រប់គ្រង- ភាពបត់បែន ការសម្របខ្លួនក្នុងដំណើរការ ជាគុណសម្បត្តិមួយរបស់ RAD តាមឧត្ដមគតិ មានន័យថា សមត្ថភាពក្នុងការសម្របខ្លួនបានយ៉ាងលឿនទាំងបញ្ហា និងឱកាស។
   ជាអកុសល អ្នកនឹងត្រូវផ្តល់នូវចំណូលចិត្តចំពោះរឿងមួយ - ភាពបត់បែន ឬការគ្រប់គ្រង។ក្នុងករណីចុងក្រោយ វិធីសាស្រ្តអភិវឌ្ឍន៍កម្មវិធីរហ័សនឹងមិនអាចសម្រេចបានឡើយ។
4. ការរចនាស្រាល- ការផ្តោតលើគំរូនៅក្នុងករណីខ្លះនាំទៅរកវិធីសាស្រ្ត "ការលួច និងសាកល្បង" ដែលអ្នកអភិវឌ្ឍន៍ ធ្វើការផ្លាស់ប្តូរតូចៗជានិច្ចវ ធាតុបុគ្គលនិងមិនអើពើបញ្ហាស្ថាបត្យកម្មប្រព័ន្ធ។
5. កង្វះនៃការធ្វើមាត្រដ្ឋាន- RAD ត្រូវបានប្រើប្រាស់ជាចម្បងដោយក្រុមគម្រោងខ្នាតតូច និងមធ្យម។ ចំនុចខ្វះខាតនៃវិធីសាស្រ្តអភិវឌ្ឍន៍កម្មវិធីរហ័សត្រូវបានប្រកាសជាពិសេសនៅពេលប្រើការអភិវឌ្ឍន៍កម្មវិធីរហ័សក្នុងការងារលើគម្រោងធំៗ។

វិធីសាស្រ្ត RAD គឺសមរម្យសម្រាប់គម្រោងរបស់អ្នកប្រសិនបើ៖

• ល្បឿននិងភាពងាយស្រួលនៃការអភិវឌ្ឍន៍មានសារៈសំខាន់សម្រាប់គាត់
• បានកំណត់យ៉ាងច្បាស់ តំបន់អាទិភាពការអភិវឌ្ឍន៍គម្រោង
• កម្មវិធីត្រូវបង្កើតក្នុងរយៈពេលដ៏ខ្លី
• គម្រោងនេះត្រូវបានអនុវត្តក្រោមថវិកាមានកំណត់
• លក្ខណៈវិនិច្ឆ័យសំខាន់គឺចំណុចប្រទាក់អ្នកប្រើ
• វាអាចទៅរួចក្នុងការបំបែកគម្រោងទៅជាសមាសធាតុមុខងារ។

វិធីសាស្រ្តអភិវឌ្ឍន៍កម្មវិធីរហ័សនឹងមិនសមនឹងគម្រោងរបស់អ្នកទេ ប្រសិនបើ៖

• គុណភាព និងការគ្រប់គ្រងមានសារៈសំខាន់សម្រាប់គាត់
• យើងកំពុងនិយាយអំពីការបង្កើត គម្រោងខ្នាតធំ- សន្មត់ ពេលវេលាអតិបរមារយៈពេលនៃការអភិវឌ្ឍន៍កម្មវិធីគឺ 60-90 ថ្ងៃ ហើយនៅពេលសរសេរកូដកម្មវិធីរាប់រយរាប់ពាន់បន្ទាត់ វាស្ទើរតែមិនអាចទៅរួចទេក្នុងការអនុលោមតាមការកំណត់បែបនេះ។
• សារៈសំខាន់នៃការអនុវត្ត គឺជាកម្រិតខ្ពស់នៃផែនការ និង វិន័យនៃការរចនាដ៏តឹងរឹងការប្រកាន់ខ្ជាប់យ៉ាងតឹងរ៉ឹងចំពោះពិធីការ និងចំណុចប្រទាក់ដែលបានអភិវឌ្ឍជាមុន
• សុវត្ថិភាពរបស់មនុស្សអាស្រ័យលើកម្រិតជាក់លាក់មួយនៅលើកម្មវិធី។

សាលក្រម

គំនិតនៃការអភិវឌ្ឍន៍កម្មវិធីរហ័ស ​​(អក្សរកាត់ថា RAD សម្រាប់ការអភិវឌ្ឍន៍កម្មវិធីរហ័ស) គឺជាប្រភេទនៃគំរូនៃការអភិវឌ្ឍន៍កម្មវិធីបន្ថែម។

ប៉ារ៉ាម៉ែត្រសំខាន់ៗដែល RAD ដំណើរការគឺ៖
ល្បឿននិងភាពងាយស្រួលនៃការសរសេរកម្មវិធី។

វិធីសាស្រ្តនឹងក្លាយជា ជម្រើសដ៏ល្អសម្រាប់ការអនុវត្ត គម្រោងតូចដែលមានថវិកាមានកំណត់ដែលចាំបាច់ត្រូវអភិវឌ្ឍ ក្នុងរយៈពេលដ៏ខ្លី. សម្រាប់ប្រព័ន្ធខ្នាតធំ ជាមួយ តម្រូវការខ្ពស់។សម្រាប់ការគ្រប់គ្រង និងការធ្វើផែនការ វាជាការប្រសើរក្នុងការជ្រើសរើសគំរូនៃការអភិវឌ្ឍន៍កម្មវិធីផ្សេងទៀត។

ការអភិវឌ្ឍន៍កម្មវិធីរហ័ស ​​(RAD) គឺជាវដ្តជីវិតនៃដំណើរការរចនាដែលត្រូវបានរចនាឡើងដើម្បីសម្រេចបានកាន់តែច្រើន ល្បឿនលឿនការអភិវឌ្ឍន៍ និងគុណភាពនៃកម្មវិធីដែលអាចធ្វើទៅបានជាមួយនឹងវិធីសាស្រ្តរចនាបែបប្រពៃណី។

គំនិត RAD គឺជាការឆ្លើយតបទៅនឹងវិធីសាស្រ្តនៃការអភិវឌ្ឍន៍កម្មវិធីនៃទសវត្សរ៍ឆ្នាំ 1970 និងដើមទសវត្សរ៍ឆ្នាំ 1980 ដូចជា "គំរូទឹកជ្រោះ" ។ វិធីសាស្រ្តទាំងនេះពាក់ព័ន្ធនឹងដំណើរការយឺតយ៉ាវនៃការបង្កើតកម្មវិធី ដែលជារឿយៗសូម្បីតែតម្រូវការសម្រាប់កម្មវិធីក៏មានពេលផ្លាស់ប្តូរមុនពេលបញ្ចប់ការអភិវឌ្ឍន៍។ ស្ថាបនិកនៃ RAD ត្រូវបានគេចាត់ទុកថាជាបុគ្គលិករបស់ IBM លោក James Martin ដែលនៅក្នុងទសវត្សរ៍ឆ្នាំ 1980 បានបង្កើតគោលការណ៍ជាមូលដ្ឋាននៃ RAD ដោយផ្អែកលើគំនិតរបស់ Barry Boym និង Scott Schultz ។ ហើយនៅឆ្នាំ 1991 ម៉ាទីនបានបោះពុម្ពសៀវភៅដ៏ល្បីល្បាញមួយដែលគាត់បានរៀបរាប់លម្អិតអំពីគំនិតនៃ RAD និងលទ្ធភាពនៃកម្មវិធីរបស់វា។ បច្ចុប្បន្ននេះ RAD កំពុងក្លាយជាគ្រោងការណ៍ដែលទទួលយកជាទូទៅសម្រាប់បង្កើតឧបករណ៍អភិវឌ្ឍន៍កម្មវិធី។

RAD សន្មត់ថាការអភិវឌ្ឍន៍កម្មវិធីត្រូវបានអនុវត្តដោយក្រុមអ្នកអភិវឌ្ឍន៍តូចមួយក្នុងរយៈពេលប្រហែលពី 3 ទៅ 4 នាក់ ដោយប្រើគំរូរូបភាព និងឧបករណ៍អភិវឌ្ឍន៍។ បច្ចេកវិទ្យា RAD ផ្តល់ ការចូលរួមយ៉ាងសកម្មអតិថិជនរួចទៅហើយនៅក្នុងដំណាក់កាលដំបូង - ការស្ទង់មតិរបស់អង្គការ, ការអភិវឌ្ឍតម្រូវការប្រព័ន្ធ។ វិធីសាស្រ្ត RAD គឺជាវិធីសាស្រ្តមួយក្នុងការអភិវឌ្ឍន៍កម្មវិធីនៅក្នុងគំរូវដ្តជីវិត។

វដ្តជីវិតរបស់កម្មវិធីយោងតាមវិធីសាស្ត្រ RAD មានបួនដំណាក់កាល៖

ដំណាក់កាលនៃការវិភាគតម្រូវការ និងផែនការ;

ដំណាក់កាលរចនា;

ដំណាក់កាលសាងសង់;

ដំណាក់កាលនៃការអនុវត្ត។

នៅដំណាក់កាលនៃការវិភាគតម្រូវការ និងការធ្វើផែនការ អ្នកប្រើប្រាស់អនុវត្តសកម្មភាពដូចខាងក្រោម៖

កំណត់មុខងារដែលប្រព័ន្ធគួរអនុវត្ត;

ការបន្លិចមុខងារអាទិភាពខ្ពស់បំផុត ដែលទាមទារឱ្យមានភាពល្អិតល្អន់ជាមុនសិន។

ការពិពណ៌នាអំពីតម្រូវការព័ត៌មាន។

ការបង្កើតតម្រូវការប្រព័ន្ធត្រូវបានអនុវត្តជាចម្បងដោយអ្នកប្រើប្រាស់ក្រោមការណែនាំរបស់អ្នកអភិវឌ្ឍន៍ឯកទេស។ លើសពីនេះទៀតនៅដំណាក់កាលនេះ កិច្ចការខាងក្រោមត្រូវបានដោះស្រាយ៖

វិសាលភាពនៃគម្រោងត្រូវបានកំណត់;

ស៊ុមពេលវេលាត្រូវបានបង្កើតឡើងសម្រាប់ដំណាក់កាលបន្តបន្ទាប់នីមួយៗ។

លទ្ធភាពនៃការអនុវត្តគម្រោងក្នុងបរិមាណថវិកាដែលបានផ្តល់ឱ្យដោយប្រើផ្នែករឹងដែលមានត្រូវបានកំណត់។ល។ លទ្ធផលនៃដំណាក់កាលគួរតែ៖

បញ្ជីមុខងារអាទិភាពនៃកម្មវិធី IS នាពេលអនាគត។

គំរូកម្មវិធីបឋម។

នៅដំណាក់កាលរចនា អ្នកប្រើប្រាស់មួយចំនួនចូលរួមក្នុងការរចនាបច្ចេកទេសនៃប្រព័ន្ធក្រោមការណែនាំរបស់អ្នកអភិវឌ្ឍន៍ឯកទេស។ ដើម្បីទទួលបានគំរូនៃកម្មវិធីដែលដំណើរការបានយ៉ាងឆាប់រហ័ស ឧបករណ៍សមស្រប (ឧបករណ៍ CASE) ត្រូវបានប្រើប្រាស់។ អ្នកប្រើប្រាស់ ធ្វើអន្តរកម្មដោយផ្ទាល់ជាមួយអ្នកអភិវឌ្ឍន៍ បញ្ជាក់ និងបន្ថែមតម្រូវការប្រព័ន្ធដែលមិនត្រូវបានកំណត់អត្តសញ្ញាណនៅដំណាក់កាលមុន។ នៅដំណាក់កាលនេះ សកម្មភាពខាងក្រោមត្រូវបានអនុវត្ត៖

ដំណើរការប្រព័ន្ធត្រូវបានពិនិត្យយ៉ាងលំអិត។

ប្រសិនបើចាំបាច់ គំរូផ្នែកមួយត្រូវបានបង្កើតឡើងសម្រាប់ដំណើរការបឋមនីមួយៗ (ទម្រង់អេក្រង់ ការសន្ទនា របាយការណ៍ ការលុបបំបាត់ភាពមិនច្បាស់លាស់ ឬភាពមិនច្បាស់លាស់)។

តម្រូវការសម្រាប់ការរឹតបន្តឹងការចូលប្រើទិន្នន័យត្រូវបានបង្កើតឡើង;

សមាសភាពនៃឯកសារចាំបាច់ត្រូវបានកំណត់។

បន្ទាប់មកគម្រោងនេះត្រូវបានចែកចាយក្នុងចំណោមក្រុមអភិវឌ្ឍន៍ផ្សេងៗគ្នា។ ក្នុងករណីឧបករណ៍ CASE នេះមានន័យថាបែងចែកគំរូមុខងារនៃប្រព័ន្ធ (ដ្យាក្រាមលំហូរទិន្នន័យសម្រាប់វិធីសាស្រ្តដែលមានរចនាសម្ព័ន្ធ ឬប្រើដ្យាក្រាមករណីសម្រាប់វិធីសាស្រ្តតម្រង់ទិសវត្ថុ)។ លទ្ធផលនៃដំណាក់កាលនេះគួរតែ៖

គំរូព័ត៌មានទូទៅនៃប្រព័ន្ធ;

គំរូមុខងារនៃប្រព័ន្ធទាំងមូល និងប្រព័ន្ធរងអនុវត្តដោយក្រុមអភិវឌ្ឍន៍បុគ្គល។

ចំណុចប្រទាក់ដែលបានកំណត់យ៉ាងជាក់លាក់រវាងប្រព័ន្ធរងដែលបានអភិវឌ្ឍដោយស្វយ័ត;

បង្កើតគំរូនៃទម្រង់អេក្រង់ របាយការណ៍ ប្រអប់។

ម៉ូដែល និងគំរូទាំងអស់ត្រូវតែទទួលបានដោយប្រើឧបករណ៍ CASE ទាំងនោះដែលនឹងត្រូវបានប្រើនាពេលអនាគតនៅពេលបង្កើតប្រព័ន្ធ។ តម្រូវការនេះគឺដោយសារតែតម្រូវការដើម្បីជៀសវាងការបង្ខូចទ្រង់ទ្រាយទិន្នន័យដែលមិនអាចគ្រប់គ្រងបាននៅពេលផ្ទេរព័ត៌មានអំពីគម្រោងពីដំណាក់កាលមួយទៅដំណាក់កាលមួយ។

នៅដំណាក់កាលអនុវត្ត ការអភិវឌ្ឍន៍កម្មវិធីរហ័សត្រូវបានអនុវត្ត៖

អ្នកអភិវឌ្ឍន៍បង្កើតប្រព័ន្ធពិតប្រាកដមួយឡើងវិញដោយផ្អែកលើគំរូដែលទទួលបាននៅដំណាក់កាលមុន ក៏ដូចជាតម្រូវការមិនដំណើរការ (តម្រូវការភាពជឿជាក់ តម្រូវការដំណើរការ។ល។)។

អ្នកប្រើប្រាស់វាយតម្លៃលទ្ធផលដែលទទួលបាន និងធ្វើការកែតម្រូវ ប្រសិនបើក្នុងអំឡុងពេលដំណើរការអភិវឌ្ឍន៍ ប្រព័ន្ធនេះលែងបំពេញតាមតម្រូវការដែលបានកំណត់ពីមុនទៀតហើយ។ ការធ្វើតេស្តប្រព័ន្ធត្រូវបានអនុវត្តក្នុងអំឡុងពេលដំណើរការអភិវឌ្ឍន៍។

បន្ទាប់ពីបញ្ចប់ការងាររបស់ក្រុមអភិវឌ្ឍន៍បុគ្គលនីមួយៗ ការរួមបញ្ចូលបន្តិចម្តងៗនៃផ្នែកនៃប្រព័ន្ធនេះជាមួយផ្នែកដែលនៅសល់ត្រូវបានអនុវត្ត កូដកម្មវិធីពេញលេញត្រូវបានបង្កើត ប្រតិបត្តិការរួមគ្នានៃផ្នែកនៃកម្មវិធីនេះត្រូវបានសាកល្បង ហើយបន្ទាប់មកប្រព័ន្ធដូចជា ទាំងមូលត្រូវបានសាកល្បង។ ការអនុវត្តប្រព័ន្ធត្រូវបានបញ្ចប់ដោយអនុវត្តការងារដូចខាងក្រោមៈ

ការប្រើប្រាស់ទិន្នន័យត្រូវបានវិភាគ ហើយតម្រូវការសម្រាប់ការចែកចាយរបស់វាត្រូវបានកំណត់។

ការរចនារូបវន្តនៃមូលដ្ឋានទិន្នន័យត្រូវបានអនុវត្ត;

តម្រូវការសម្រាប់ធនធានផ្នែករឹងត្រូវបានបង្កើតឡើង;

មធ្យោបាយដើម្បីបង្កើនផលិតភាពត្រូវបានបង្កើតឡើង;

ការអភិវឌ្ឍន៍ឯកសារគម្រោងកំពុងត្រូវបានបញ្ចប់។ លទ្ធផលនៃដំណាក់កាលគឺជាប្រព័ន្ធបញ្ចប់ដែលបំពេញតាមតម្រូវការដែលបានព្រមព្រៀងទាំងអស់។

នៅដំណាក់កាលនៃការអនុវត្ត ការបណ្តុះបណ្តាលអ្នកប្រើប្រាស់ និងការផ្លាស់ប្តូរអង្គភាពត្រូវបានធ្វើឡើង។

ការប្រើប្រាស់បច្ចេកវិទ្យា RAD ត្រូវបានណែនាំនៅពេល៖

គម្រោងនេះត្រូវបានតម្រូវឱ្យបញ្ចប់ក្នុងរយៈពេលខ្លី (90 ថ្ងៃ);

តម្រូវការកម្មវិធីមិនត្រូវបានកំណត់ច្បាស់លាស់;

គម្រោងនេះត្រូវបានអនុវត្តក្រោមកម្រិតថវិកា។

ចំណុចប្រទាក់អ្នកប្រើ (GUI) គឺជាកត្តាចម្បង;

គម្រោងនេះមានទំហំធំ ប៉ុន្តែអាចបែងចែកទៅជាសមាសធាតុមុខងារតូចៗ។

កម្មវិធីមិនមានភាពស្មុគស្មាញក្នុងការគណនាខ្ពស់ទេ។

បច្ចេកវិទ្យា RAD មិនមានលក្ខណៈជាសកលទេ ពោលគឺការប្រើប្រាស់របស់វាមិនតែងតែត្រូវបានណែនាំទេ។ ឧទាហរណ៍នៅក្នុងគម្រោងដែលតម្រូវការសម្រាប់ ផលិតផលសូហ្វវែរត្រូវបានកំណត់យ៉ាងច្បាស់ និងមិនគួរផ្លាស់ប្តូរ ការចូលរួមរបស់អតិថិជនក្នុងដំណើរការអភិវឌ្ឍមិនត្រូវបានទាមទារទេ ហើយការអភិវឌ្ឍន៍តាមឋានានុក្រម (វិធីសាស្ត្រល្បាក់) អាចមានប្រសិទ្ធភាពជាង។ អនុវត្តដូចគ្នាចំពោះគម្រោងកម្មវិធី ភាពស្មុគស្មាញដែលត្រូវបានកំណត់ដោយតម្រូវការក្នុងការអនុវត្ត ក្បួនដោះស្រាយស្មុគស្មាញនិងតួនាទី និងបរិមាណ ចំណុចប្រទាក់អ្នកប្រើតូច។

រូបភាពទី 1 - ការប្រៀបធៀបនៃវិធីសាស្ត្រ RAD និង Cascade