Быстрая разработка программного обеспечения: концепции и подходы
Rapid application development
Быстрая разработка ПО (RAD): адаптивный подход, прототипирование вместо планирования. Инструменты RAD для UI-ориентированных приложений. Эффективная разработка!
Сравнивайте с английским: нажмите на абзац — оригинал откроется в окне. Кнопка EN под абзацем показывает его прямо в тексте.
Введение
Концепция разработки программного обеспечения
Concept of software development
Быстрая разработка приложений (RAD), также называемая быстрым построением приложений (RAB), — это как общий термин для адаптивных подходов к разработке программного обеспечения, так и название метода быстрой разработки, предложенного Джеймсом Мартином. В целом, подходы RAD к разработке программного обеспечения уделяют меньше внимания планированию и больше – адаптивному процессу. Прототипы часто используются в дополнение к спецификациям дизайна, а иногда и вместо них. RAD особенно хорошо подходит (хотя и не ограничивается этим) для разработки программного обеспечения, определяемого требованиями к пользовательскому интерфейсу. Средства разработки графического пользовательского интерфейса часто называют инструментами быстрой разработки приложений. К другим подходам к быстрой разработке относятся адаптивные, гибкие, спиральные и унифицированные модели.
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.
История
Быстрая разработка приложений стала ответом на процессы, управляемые планом, такие как метод анализа и проектирования структурированных систем (SSADM), разработанные в 1970-х и 1980-х годах. Одна из проблем этих методов заключалась в том, что они основывались на традиционной инженерной модели, используемой для проектирования и строительства мостов и зданий. Программное обеспечение по своей сути является иным артефактом. Программное обеспечение может радикально изменить весь процесс решения проблемы. В результате, знания, полученные в процессе разработки, могут быть использованы для уточнения требований и проектирования решения. Подходы, основанные на планировании, стремятся жестко определить требования, решение и план реализации, и их процессы препятствуют изменениям. Подходы 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 году книгу «Rapid Application Development». Это привело к некоторой путанице в отношении термина RAD даже среди ИТ-специалистов. Важно различать RAD как общую альтернативу модели водопада и RAD как конкретный метод, созданный Мартином. Метод Мартина был ориентирован на бизнес-системы, интенсивно использующие знания и пользовательские интерфейсы. Эти идеи были далее развиты и усовершенствованы пионерами RAD, такими как Джеймс Керр и Ричард Хантер, которые совместно написали основополагающую книгу по этой теме «Inside RAD», в которой описывалось путешествие менеджера проекта RAD, управлявшего и совершенствовавшего методологию RAD в реальном времени в рамках реального проекта RAD. Эти практики и другие подобные им помогли RAD завоевать популярность как альтернатива традиционным подходам к жизненному циклу системных проектов. Подход RAD также созрел в период пикового интереса к реинжинирингу бизнеса. Идея реинжиниринга бизнес-процессов заключалась в радикальном переосмыслении основных бизнес-процессов, таких как продажи и поддержка клиентов, с учетом новых возможностей информационных технологий. RAD часто был неотъемлемой частью крупных программ реинжиниринга бизнеса. Подход RAD к быстрому прототипированию был ключевым инструментом, помогающим пользователям и аналитикам «мыслить нестандартно» и находить инновационные способы радикального преобразования основных бизнес-процессов с помощью технологий. Большая часть уверенности Джеймса Мартина в RAD происходила из подразделения Information Engineering компании Dupont и его руководителя Скотта Шульца, а также их отношений с Джоном Андервудом, возглавлявшим компанию, специализирующуюся на разработке RAD, которая успешно реализовала множество проектов RAD в Австралии и Гонконге. Успешные проекты включали ANZ Bank, Lend Lease, BHP, Coca Cola Amatil, Alcan, Hong Kong Jockey Club и многие другие. Этот успех привел к тому, что Скотт Шульц и Джеймс Мартин провели время в Австралии с Джоном Андервудом, чтобы понять методы и детали, объясняющие непропорционально высокий успех Австралии во внедрении важных критически важных проектов 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.