Жылдам бағдарламалық жасақтама әзірлеу концепциясы
Rapid application development
Жылдам бағдарламалық жасақтама әзірлеу (RAD) – жоспарлаудан гөрі бейімделуге баса назар аударатын, прототиптерді қолданатын тиімді әдіс. UI дамытуға өте қолайлы.
Ағылшыншамен салыстырыңыз: абзацты басыңыз — түпнұсқа терезеде ашылады. Абзац астындағы EN түймесі оны мәтін ішінде көрсетеді.
Кіріспе
Бағдарламалық жасақтаманы дамыту тұжырымдамасы Жедел қолданбаларды әзірлеу (RAD), сондай-ақ жедел қолданба құрастыру (RAB) деп те аталады, адаптивті бағдарламалық жасақтаманы дамыту тәсілдерінің жалпы атауы және Джеймс Мартиннің жедел даму әдісінің атауы. Жалпы алғанда, RAD бағдарламалық жасақтаманы дамыту тәсілдері жоспарлауға қарағанда бейімделу процесіне көбірек мән береді. Прототиптер көбінесе жобалық сипаттамалармен қатар немесе кейде тіпті олардың орнына қолданылады. RAD әсіресе пайдаланушы интерфейсі талаптарымен басқарылатын бағдарламалық жасақтаманы дамытуға (бірақ оған ғана шектелмейді) өте ыңғайлы. Графикалық пайдаланушы интерфейсі құрастырушылар жиі жедел қолданбаларды дамыту құралдары деп аталады. Жедел дамудың басқа тәсілдеріне адаптивті, икемді, спиральді және біріктірілген модельдер жатады.
Concept of software development
Rapid application development (RAD), also called rapid application building (RAB), is both a general term for adaptive software development approaches, and the name for James Martin's method of rapid development. In general, RAD approaches to software development put less emphasis on planning and more emphasis on an adaptive process. Prototypes are often used in addition to or sometimes even instead of design specifications. RAD is especially well suited for (although not limited to) developing software that is driven by user interface requirements. Graphical user interface builders are often called rapid application development tools. Other approaches to rapid development include the adaptive, agile, spiral, and unified models.
Тарих
Жедел қолданбаларды әзірлеу 1970 және 1980 жылдары дамыған, мысалы, Құрылымдық жүйелерді талдау және жобалау әдісі (SSADM) сияқты жоспарланған каскадты процестерге жауап ретінде пайда болды. Осы әдістердің біріндегі қиындық – олар көпірлер мен ғимараттарды жобалау және салу үшін қолданылатын дәстүрлі инженерлік модельге негізделгендігі болды. Бағдарламалық жасақтама мүлдем басқа типтегі өнім. Бағдарламалық қамтамасыз ету мәселені шешуге қолданылатын процесті түбірінен өзгерте алады. Осының салдарынан, даму процесінен алынған білім шешімнің талаптары мен жобасына кері байланыс бере алады. Жоспарға бағытталған тәсілдер талаптарды, шешімді және оны жүзеге асыру жоспарын қатаң түрде анықтауға тырысады және өзгерістерге қарсы процеске ие. RAD тәсілдері, керісінше, бағдарламалық жасақтаманы әзірлеудің білімді қажет ететін процесс екенін мойындайды және жоба барысында алынған білімді пайдалануға көмектесетін икемді процестерді ұсынады, соның арқасында шешімді жақсартуға немесе бейімдеуге болады. Бұл RAD-тің алғашқы баламасы Барри Боем жасаған және оны спиральді модель деп атады. Боем және басқа RAD тәсілдері прототиптерді әзірлеуге, сондай-ақ қатаң жобалық сипаттамалардың орнына баса назар аударды. Прототиптердің дәстүрлі сипаттамалардан бірнеше артықшылықтары бар:
Rapid application development was a response to plan driven waterfall processes, developed in the 1970s and 1980s, such as the Structured Systems Analysis and Design Method (SSADM). One of the problems with these methods is that they were based on a traditional engineering model used to design and build things like bridges and buildings. Software is an inherently different kind of artifact. Software can radically change the entire process used to solve a problem. As a result, knowledge gained from the development process itself can feed back to the requirements and design of the solution. Plan driven approaches attempt to rigidly define the requirements, the solution, and the plan to implement it, and have a process that discourages changes. RAD approaches, on the other hand, recognize that software development is a knowledge intensive process and provide flexible processes that help take advantage of knowledge gained during the project to improve or adapt the solution. The first such RAD alternative was developed by Barry Boehm and was known as the spiral model. Boehm and other subsequent RAD approaches emphasized developing prototypes as well as or instead of rigorous design specifications. Prototypes had several advantages over traditional specifications:
Қауіпті азайту. Прототип жүйенің ең қиын болуы мүмкін бөліктерін өмірлік циклдің басында тексеруге мүмкіндік береді. Бұл жобаның мүмкіндігі туралы құнды ақпаратты ұсынады және команданы тым күрделі немесе уақытты көп алатын шешімдерді іздеуден сақтайды. Өмірлік циклдің басында проблемаларды табудың бұл артықшылығы RAD тәсілінің маңызды ерекшелігі болды. Проблеманы қаншалықты ертерек анықтаса, оны шешу де соншалықты арзанға түседі. Пайдаланушылар ерекшеліктерді жасауға қарағанда, пайдалану және кері байланыс беруде жақсы. Каскадты модельде пайдаланушы талаптар жиынтығына қол қойғаннан кейін, жүйе іске асырылғанда, кейбір маңызды мүмкіндіктердің жоқ екенін немесе жобаның тым күрделі екенін сезінуі мүмкін. Жалпы алғанда, пайдаланушылар жүйенің прототипімен танысқанда, оның қандай болуы керектігін абстрактілі түрде анықтауға қарағанда, әлдеқайда пайдалы кері байланыс береді. Прототиптер пайдалануға жарамды және дайын өнімге айналуы мүмкін. Кейбір RAD әдістерінде жүйені минималды функционалдылықтан бастап, орташа пайдалылыққа және соңында дайын жүйеге дейін дамыған прототиптер сериясі ретінде құру тәсілі қолданылды. Бұл тәсілдің үстімізде айтқан екі артықшылығынан басқа, пайдаланушылар процесте әлдеқайда ертерек пайдалы бизнес-функционалдылықты алуға мүмкіндік берді. Барри Боем және басқалардың идеяларынан бастап, Джеймс Мартин 1980 жылдары IBM-де жедел қолданбаларды әзірлеу тәсілін жасады және 1991 жылы "Жедел қолданбаларды әзірлеу" кітабын жариялап, оны ресмилендірді. Бұл IT-мамандардың арасында RAD терминіне қатысты шатасу тудырды. RAD-ті каскадты модельге жалпы балама ретінде және Мартин жасаған нақты әдіс ретінде ажырату маңызды. Мартин әдісі білімді және пайдаланушы интерфейсіне бағытталған бизнес жүйелеріне бейімделген. Бұл идеяларды RAD-тің алғашқыларын Джеймс Керр мен Ричард Хантер одан әрі дамытып, жетілдірді. Олар осы тақырыпта "Inside RAD" атты кітап жазды, онда RAD жобасының менеджерінің RAD әдістемесін нақты уақыт режимінде нақты RAD жобасында қалай жүргізгені және жетілдіргені көрсетілді. Осы тәжірибелі мамандар және олар сияқтылар RAD-ті дәстүрлі жүйелерді жобалау өмірлік циклы тәсілдеріне балама ретінде танымал етуге көмектесті. RAD тәсілі бизнес-процестерді қайта құруға қызығушылықтың ең жоғары кезеңінде жетілді. Бизнес-процестерді қайта құру идеясы ақпараттық технологияның жаңа мүмкіндіктерін ескере отырып, сату және клиенттерді қолдау сияқты негізгі бизнес-процестерді түбірінен қайта қарау болды. RAD көбінесе ірі бизнес-инжиниринг бағдарламаларының маңызды бөлігі болды. RAD-тің жылдам прототиптеу әдісі пайдаланушылар мен сарапшыларға технологияның көмегімен негізгі бизнес-процестерді жаңаша ойлауға көмектесетін маңызды құрал болды. Джеймс Мартиннің RAD-қа деген ыңғайлылығының көп бөлігі Дупонттың Ақпараттық инженерия бөлімінен және оның жетекшісі Скотт Шульцтан, сондай-ақ Джон Андервудпен болған қарым-қатынастарынан туындады. Джон Андервуд Австралия мен Гонконгта көптеген табысты RAD жобаларын жүзеге асырған RAD-ті дамыту компаниясын басқарды. Сәтті жобаларға ANZ Bank, Lend Lease, BHP, Coca Cola Amatil, Alcan, Гонконг Жокей Клубы және тағы да көптеген жобалар кірді. Бұл жетістік Скотт Шульц пен Джеймс Мартиннің екеуінің де Австралияда Джон Андервудпен бірге әдістерді және Австралияның маңызды миссиялық RAD жобаларын жүзеге асырудағы табыстылығының себептерін түсіну үшін уақыт өткізуіне әкелді.
Risk reduction. A prototype could test some of the most difficult potential parts of the system early on in the life cycle. This can provide valuable information as to the feasibility of a design and can prevent the team from pursuing solutions that turn out to be too complex or time consuming to implement. This benefit of finding problems earlier in the life cycle rather than later was a key benefit of the RAD approach. The earlier a problem can be found the cheaper it is to address. Users are better at using and reacting than at creating specifications. In the waterfall model it was common for a user to sign off on a set of requirements but then when presented with an implemented system to suddenly realize that a given design lacked some critical features or was too complex. In general most users give much more useful feedback when they can experience a prototype of the running system rather than abstractly define what that system should be. Prototypes can be usable and can evolve into the completed product. One approach used in some RAD methods was to build the system as a series of prototypes that evolve from minimal functionality to moderately useful to the final completed system. The advantage of this besides the two advantages above was that the users could get useful business functionality much earlier in the process. Starting with the ideas of Barry Boehm and others, James Martin developed the rapid application development approach during the 1980s at IBM and finally formalized it by publishing a book in 1991, Rapid Application Development. This has resulted in some confusion over the term RAD even among IT professionals. It is important to distinguish between RAD as a general alternative to the waterfall model and RAD as the specific method created by Martin. The Martin method was tailored toward knowledge intensive and UI intensive business systems. These ideas were further developed and improved upon by RAD pioneers like James Kerr and Richard Hunter, who together wrote the seminal book on the subject, Inside RAD, which followed the journey of a RAD project manager as he drove and refined the RAD Methodology in real time on an actual RAD project. These practitioners, and those like them, helped RAD gain popularity as an alternative to traditional systems project life cycle approaches. The RAD approach also matured during the period of peak interest in business re engineering. The idea of business process re engineering was to radically rethink core business processes such as sales and customer support with the new capabilities of Information Technology in mind. RAD was often an essential part of larger business re engineering programs. The rapid prototyping approach of RAD was a key tool to help users and analysts "think out of the box" about innovative ways that technology might radically reinvent a core business process. Much of James Martin's comfort with RAD stemmed from Dupont's Information Engineering division and its leader Scott Schultz and their respective relationships with John Underwood who headed up a bespoke RAD development company that pioneered many successful RAD projects in Australia and Hong Kong. Successful projects that included ANZ Bank, Lend Lease, BHP, Coca Cola Amatil, Alcan, Hong Kong Jockey Club and numerous others. Success that led to both Scott Shultz and James Martin both spending time in Australia with John Underwood to understand the methods and details of why Australia was disproportionately successful in implementing significant mission critical RAD projects.