Методология разработки софта - организация труда, включающая идеологические принципы, план, контроль над процессами, подход к сотрудникам. Выделим 12 видов:
Давайте попробуем разобраться, что скрывается за этими английскими названиями.
Модель Waterfall относится к классическому пониманию разработки ПО. Весь процесс является жестким и линейным, имеет четкие цели для каждого этапа, новая фаза начинается по завершению предыдущей, нет возврата назад. Преимущества водопадной методологии - децентрализация и строгий контроль над сроками и качеством исполнения.
На практике Waterfall часто не оправдывает ожиданий, поскольку игнорирует динамические изменения. Так, после тестирования очень сложно откатить процесс и заложить функции, не учтенные на стадии разработки. Waterfall неэффективен ещё и потому, что предполагает временные простои сотрудников в рамках одного проекта. Тестирование проводится только в конце разработки, хотя проблемы, найденные на этом этапе - это дорогостоящие исправления.
RUP - итеративный подход, который решает проблемы, которые есть у Waterfall. Чем хорош RUP:
Agile - метод гибкой разработки программного обеспечения, предполагающий большое количество итераций. Документ Agile Manifesto описывает 4 идей и 12 принципов гибкого подхода, коротко его можно описать всего двумя пунктами:
Несмотря на недостатки, Agile стала фундаментальной концепцией для разработки ПО и нашла отражение в других методологиях, речь о которых пойдет далее.
Методология, созданная для небольших коллективов из 6−10 сотрудников. Также поддерживает принципы гибкой разработки, но имеет чуть больше конкретики. Основная идея, которая и заключена в названии - каждая команда является набором людей с разным уровнем знаний, разными умениями и опытом.
Именно поэтому нет универсального подхода для разработки софта, он должен определяться в процессе общения внутри группы. Там же назначаются роли, инструменты, стандарты. Затем группа принимается за единицу и те же самые вопросы решаются на уровень выше, пока иерархия не дойдет до заказчика.
Модель спирального жизненного цикла - это сложная организация жизненного цикла ПО, которая фокусируется на раннем выявлении и уменьшении проектных рисков. Разработка начинается в небольшом масштабе, решаются локальные задачи, оцениваются риски и пути их уменьшения. Следующий шаг охватывает более комплексные задачи - следующий виток спирали.
Преимущество подхода не в увеличении скорости разработки, а в снижении уровня возникновения рисков. Успешность спирального метода зависит от добросовестного, внимательного и компетентного управления, а размер проекта не имеет принципиального значения.
Модель развития динамических систем была разработана в Великобритании в середине 1990-х годов и является эволюционным развитием быстрой разработки приложений (RAD). Основная идея стандартная: при планировании в самом начале невозможно понимать всех тонкостей разработки, поэтому весь процесс - исследовательская работа.
В DSDM тоже присутствует деление на команды, в каждой из которых есть уполномоченный для принятия стратегических решений. В процессе могут участвовать все заинтересованные стороны: пользователи, разработчики, заказчики, руководители. Тестирование проводится на протяжении всего жизненного цикла.
FDD - процесс для обеспечения масштабируемости и повторяемости, при этом поощряющий творчество и инновации. Вот основные принципы:
FDD регламентирует время, которое должно затрачиваться на каждый из процессов. Организационной деятельности в цикле должна занимать не более 23−25%, в то время как на непосредственную разработку, сборку и тестирование функций необходимо тратить 75−77% времени.
JAD - это методология, нацеленная на максимальную занятость в разработке конечного пользователя. Происходит это посредством встреч и проведения совместных семинаров. JAD была придумана в 1970-х годах сотрудниками IBM и нацелена на бизнес в целом. Однако со временем данная концепция стала успешно применяться и для разработки программного обеспечения.
В отличие от подхода Waterfall, JAD приводит к сокращению времени разработки, большей удовлетворенности клиентов и экономии средств на изучении рынка. С другой стороны, это требует большой клиентской выборки и необходимости разработчиков работать не со строгими требованиями ТЗ, а с постоянно меняющимся мнением.
RAD - методология, которая во главу угла ставит скорость и удобство разработки. Одно из главных условий - использование языка быстрой разработки. Это название абстрактного языка программирования, с помощью которого программист способен решать задачи быстрее, чем с представителями третьего поколения (C / C ++, Pascal или Fortran). Вот ещё несколько пунктов концепции:
RAD предполагает использование целого комплекса инструментов помимо языка быстрой разработки: системы сбора требований, среды разработки, фреймворки, программы для группового общения, ПО для тестирования.
Scrum - гибкий метод управления проектами, целью которого является повышение производительности труда в командах, ранее парализованных более тяжелыми методологическими процессами. В основе концепции лежат «спринты». Спринт - короткая итерация, строго ограниченная по времени (обычно 2−4 недели). В это время минимизируется длительность совещаний, но увеличивается их частота (они называются «схватками»).
Благодаря этому контроль за выполнением становится более гибким, а разработчики быстрее реагируют на возникающие проблемы. Традиционное планирование отходит на второй план, его место занимает журнал спринтов.
Экстремальное программирование - возможность вести разработку в условиях постоянно меняющихся требований. Вот несколько признаков:
Бережливая разработка ПО - ещё одно ответвление гибкой методологии, предполагающее сохранение высокого морально-функционального состояния разработчиков. Это выражается в:
В условиях короткого дайджеста трудно раскрыть все преимущества и недостатки методологий, показать эффективные области применения. О наиболее актуальных на сегодняшний день концепциях мы поговорим отдельно. О каких именно? Оставляйте свои пожелания в комментариях.
RAD-технология (Rapid Application Development ) – это технология быстрого создания приложений на основе прототипирования и использования графического пользовательского интерфейса GUI (Graphical User Interface ).
RAD-технология не в состоянии обеспечивать разработку сложных продуктов, содержащих много фрагментов, программирование которых занимает более двух недель. Эта технология ориентирована скорее на разработку достаточно простого заказного программного обеспечения, чем на индустриальное проектирование ИС.
Решения почти всех проблем, связанных с разработкой небольших ИС, достигаются с применением признанной во всем мире RAD-технологии. Она заключается в том, что организуется так называемая RAD-группа из 6-7 человек, состоящая из руководителя, системного аналитика и 4-5 программистов, которым даются четкие планы на весь период разработки проекта со сроками от 1 до 2 недель.
Основой этой технологии является спиральная модель создания ИС (рис. 6.1). Как видно на рисунке, разработка идет по спирали, проходя неоднократно все 4 стадии разработки ИС.
Рисунок 6.1 – Спиральная модель проектирования на основе RAD-технологии
На стадии анализа пользователи осуществляют следующие действия:
определяют функции, которые должна выполнять система;
выделяют наиболее приоритетные функции, требующие проработки в первую очередь;
описывают информационные потребности. Формулирование требований к системе осуществляется в основном силами пользователей под руководством специалистов-разработчиков. Кроме того, на данной стадии решаются следующие задачи:
ограничивается масштаб проекта;
устанавливаются временные рамки для каждой из последующих стадий;
определяется сама возможность реализации проекта в заданных размерах финансирования, на имеющихся аппаратных средствах и т.п. Результатом стадии должны быть:
список расставленных по приоритету функций будущего ПО ИС;
предварительные модели ПО.
На стадии проектирования часть пользователей принимает участие в техническом проектировании системы под руководством специалистов-разработчиков. Для быстрого получения работающих прототипов приложений используются соответствующие инструментальные средства (CASE-средства). Пользователи, непосредственно взаимодействуя с разработчиками, уточняют и дополняют требования к системе, которые не были выявлены на предыдущей стадии. На данной стадии выполняются следующие действия:
более детально рассматриваются процессы системы;
при необходимости для каждого элементарного процесса создается частичный прототип: экранная форма, диалог, отчет, устраняющий неясности или неоднозначности;
устанавливаются требования разграничения доступа к данным;
определяется состав необходимой документации.
После детального определения состава процессов оценивается количество так называемых функциональных точек (function point) разрабатываемой системы и принимается решение о разделении ИС на подсистемы, поддающиеся реализации одной командой разработчиков за приемлемое для RAD-проектов время (до 3 месяцев).
Функциональная точка – это любой из элементов разрабатываемой системы:
входной элемент приложения (входной документ или экранная форма);
выходной элемент приложения (отчет, документ, экранная форма);
запрос (пара «вопрос/ответ»);
логический файл (совокупность записей данных, используемых внутри приложения);
интерфейс приложения (совокупность записей данных, передаваемых другому приложению или получаемых от него).
Далее проект распределяется между различными командами разработчиков. Опыт разработки крупных ИС показывает, что для повышения эффективности работ необходимо разбить проект на отдельные слабо связанные по данным и функциям подсистемы. Реализация подсистем должна выполняться отдельными группами специалистов. При этом необходимо обеспечить координацию ведения общего проекта и исключить дублирование результатов работ каждой проектной группы, которое может возникнуть в силу наличия общих данных и функций.
В случае использования CASE-средств это означает деление функциональной модели системы (диаграммы потоков данных для структурного подхода или диаграммы вариантов использования для объектно-ориентированного подхода.
Результатом данной стадии должны быть:
общая информационная модель системы;
функциональные модели системы в целом и подсистем, реализуемых отдельными командами разработчиков;
точно определенные интерфейсы между автономно разрабатываемыми подсистемами;
построенные прототипы экранных форм, отчетов, диалогов.
Все модели и прототипы должны быть получены с применением тех CASE-средств, которые будут использоваться в дальнейшем при построении системы. Данное требование обусловлено необходимостью избежать неконтролируемого искажения данных при передаче информации о проекте со стадии на стадию.
В отличие от имевшего место ранее подхода, при котором использовались специфические средства прототипирования, не предназначенные для построения реальных приложений, а прототипы выбрасывались после того, как выполняли задачу устранения неясностей в проекте, в подходе RAD каждый прототип развивается в часть будущей системы. Таким образом, на следующую стадию передается более полная и полезная информация.
На стадии реализации выполняется непосредственно сама быстрая разработка приложения:
разработчики производят итеративное построение реальной системы на основе полученных на предыдущей стадии моделей, а также требований нефункционального характера (требований к надежности, производительности и т.п.);
пользователи оценивают получаемые результаты и вносят коррективы, если в процессе разработки система перестает удовлетворять определенным ранее требованиям. Тестирование системы осуществляется в процессе разработки.
После окончания работ каждой отдельной команды разработчиков производится постепенная интеграция данной части системы с остальными, формируется полный программный код, выполняется тестирование совместной работы данной части приложения, а затем тестирование системы в целом. Реализация системы завершается выполнением следующих работ:
осуществляется анализ использования данных и определяется необходимость их распределения;
производится физическое проектирование базы данных;
формулируются требования к аппаратным ресурсам;
устанавливаются способы увеличения производительности;
завершается разработка документации проекта.
Выбор методик разработки приложений становится задачей № 1 в условиях стремительного роста рынка. Согласно исследованию на программное обеспечение для предприятий в 2015 году по миру было затрачено 310 млрд. долларов США. Разработка концепции RAD (Rapid Application Development) стало основой для создания гибкой, адаптивной системы разработки приложений, которая была бы противовесом жёсткой «водопадной» модели.
За появление быстрой разработки приложения стоит благодарить неидеальность модели семейства Waterfall при создании ПО. Всё дело в том, что изначально водопадная система разработки была основана на традиционной инженерной модели, используемой для проектирования и возведения зданий и мостов.
Если Waterfall за основу использовала жесткую структуру последовательных действий по разработке, то появление RAD стало попыткой создания гибкого процесса, в рамках которого могли быть использованы знания, полученные в течении жизненного цикла проекта.
Первую версию RAD создал Барри Боэм в 1986 году, который назвал её «спиральная модель». Каждый виток спирали разбит на 4 сектора и соответствует разработке фрагмента или версии ПО. С каждым новым витком идёт углубление и уточнение целей, спецификаций проекта. В результате появляется возможность выбрать обоснованный вариант.
Использовав идеи Барри, британец Джеймс Мартин разработал свою систему RAD на протяжении работы в 80-ых в IBM, и окончательно сформулировал их в «Быстрая разработка приложений» в 1991 г.
Правда не обошлось без путаницы в значении слова «RAD» даже среди IT-специалистов. Ведь речь шла о двух концепциях: RAD как эффективной альтернативе Waterfall и RAD как специфическому методу, разработанному Мартином. Последний был адаптирован к бизнес-системам с интенсивным использованием UI.
В дальнейшем идеи были развиты и улучшены пионерами RAD Джеймсом Керром и Ричардом Хантером в совместной «Внутри RAD», которая описывала путешествие проектного менеджера в процессе изучения и внедрения методологии быстрой разработки приложений в реальной жизни для реального проекта.
С последним пунктом возникает больше всего проблем, потому что разработчик и заказчик видят предмет разработки по-разному.
Принципы RAD используются не только при реализации, а и распространяются на все этапы жизненного цикла, в частности, на стадию обследования организации, построения требований, анализ и дизайн.
В процессе RAD приложение проходит четыре фазы.
Определяются требования, функции приложения и их приоритетность, описываются информационные потребности. Фаза выполняется преимущественно пользователями при участии разработчиков. На этой стадии также обозначаются масштаб проекта, временные и финансовые рамки, платформы для запуска ПО.
, компании «Beverly Flowers» нужно приложение для онлайн-заказа цветов на дом. На создание отводится 50 дней, бюджет — 3 000 долларов.Часть пользователей участвует в техническом проектировании системы под руководством разработчиков. Группы или подгруппы RAD на этой фазе обычно используют комбинацию техник с овместной разработки приложений (JAD) и CASE-инструменты для воплощения потребностей пользователей в рабочих моделях.
На фазе проектирования пользователи могут понять, модифицировать и определить рабочую модель системы, которая соответствует их нуждам. Каждый процесс рассматривается детально и, при необходимости, создаётся частичный прототип .
Если в предыдущих моделях средства разработки прототипов не соответствовали реальным приложениям, и они в дальнейшем не использовались, то в RAD каждый прототип становится частью будущей системы.
Так, в приложении «Beverly Flowers» пользователи должны иметь доступ к возможностям: «Домашняя страница», «Поиск цветов», «Посмотреть список цветов».
В качестве платформы разработки выбрали freeware SpringToolSuite, для которой доступно большое количество сэмплов — прописанных кусочков кода.
В роли сервера — Apache Tomcat 6.0.
На этой стадии происходит непосредственно быстрая разработка на основе полученных по предыдущим фазам результатов. При этом пользователи продолжают участвовать в развитии системы, предлагая изменения и улучшения приложения. Тестирование приложения тоже происходит во время разработки.
Приложение «Beverly Flowers» собирается из трёх функциональных компонентов — перехода пользователя на «Домашнюю страницу», «Поиск цветов» и «Просмотреть список цветов».
Для разработки рабочей модели понадобился 1 специалист и 8 дней.
Охватывает обучение пользователей, тестирование и замену старой системы на новую . Подготовка к этой фазе начинается с этапа проектирования.
Ранее компания «Beverly Flowers» принимала заказы непосредственно в точках сбыта и по телефону.
Записав сообщение о возможности заказа через специальное приложение и разместив информационные стенды в точках продажи, за 2 недели удалось переключить часть покупателей на новый канал сбыта.
При этом доля заказов по телефону пропорционально снизилась, а значит удалось сократить штат менеджеров по работе с клиентами.
Стоит отметить, что в отличии от Waterfall, жизненный цикл проекта по методологии RAD не является жёстким. Зависимо от стартовых условий, количество фаз может уменьшаться, как и их наполнение.
Использовать Rapid Application Development или нет, во многом зависит от стартовых условий, требований заказчика и вида приложения.
Не обошлось и без недостатков.
Концепция быстрой разработки приложений (сокращённо RAD от Rapid Application Development) — разновидность инкреметных моделей разработки ПО.
Методология станет отличным выбором для реализации небольших проектов с ограниченным бюджетом , разработать которые нужно в сжатые сроки . Для масштабных же систем, с высокими требованиями по контролю и планированию лучше выбрать другие модели разработки программного обеспечения.
Быстрая разработка программ
Быстрая разработка программ - технология программирования, обеспечивающая ускоренную разработку и модификацию приложений за счет использования объектно-ориентированного и визуального программирования.
По-английски: Rapid Application Development
Синонимы английские: RAD
См. также: Автоматизированное программирование
Педагогический терминологический словарь
Словарь бизнес терминов
Большой бухгалтерский словарь
Официальная терминология
Энциклопедический словарь Брокгауза и Евфрона
Большая Советская энциклопедия
Пятиязычный словарь лингвистических терминов
В.И. Даль. Пословицы русского народа
В.И. Даль. Пословицы русского народа
Словарь синонимов
Словарь синонимов
Словарь синонимов
Словарь синонимов
Словарь синонимов
РАЗРАБОТКА ПРОГРАММ 6. Для каждого аспекта электронного научения уточните следующее:? потребность в научении;? то, каким образом электронное научение удовлетворит эту потребность;? систему научения, которая будет использоваться;? содержание (в широком смысле), которое
Путь 2. Быстрая разработка приложений Большинство автоматизированных решений BPM дает возможность интерактивно конфигурировать процессы между персоналом бизнеса и техническими специалистами, когда специалисты по процессам и/или хозяева процессов садятся за стол
Шаг 9. Разработка и запуск маркетинговых программ Подумайте над целесообразностью запуска формальных маркетинговых кампаний на рынке, конкретно нацеленных на внешние заинтересованные стороны. Организация даже, возможно, сочтет необходимым опубликовать свою программу
3. Разработка и совершенствование общественных программ и услуг «Как вам, возможно, уже известно, мы получили отличную новость после того, как я направил петицию по адресу Даунинг-стрит, 10. Теперь они обещают потратить $280 млн на улучшение обедов в школьных столовых
Создание устноисторических проектов и разработка научно-исследовательских программ по устной истории Специфика деятельности в области устной истории. Разработка концепции исследования. Постановка целей. Определение задач. Направления и формы устноисторической
Из книги Гражданский кодекс РФ автора ГАРАНТГлава 8 Разработка программ Первоначально системе UNIX предназначалась роль среды для разработки программ. В настоящей главе мы обсудим некоторые применяемые с этой целью программные средства на примере солидной программы - интерпретатора языка программирования,
10. Классы памяти и разработка программ ЛОКАЛЬНЫЕ И ГЛОБАЛЬНЫЕ ПЕРЕМЕННЫЕКЛАССЫ ПАМЯТИФУНКЦИЯ ПОЛУЧЕНИЯ СЛУЧАЙНЫХ ЧИСЕЛПРОВЕРКА ОШИБОКМОДУЛЬНОЕ
Глава 3 Разработка программ для Pocket PC с помощью Microsoft eMbedded Visual Basic
Глава 4 Разработка программ для Pocket PC с помощью Microsoft eMbedded Visual C++ 3.0 По сравнению с eVB язык C++, безусловно, предоставляет разработчику больше возможностей. Несмотря на то что в eVB можно было сделать почти все, что можно сделать в eVC (так в этой главе будет называться eMbedded Visual C++
Глава 5 Разработка программ для Pocket PC с помощью Microsoft eMbedded Visual С++ 4.0 Поскольку все сказанное о среде VC 3.0 относится в полной мере и к eVC 4.0, да и сами среды похожи друг на друга как близнецы, нет нужды снова описывать среду разработки. Использовать eVC 4.0 необходимо, если
Глава 6 NET Compact Framework и разработка программ для Pocket PC в Microsoft Visual Studio.NET 2003 Не покривлю душой, если скажу, что мы переходим к одной из самых интересных частей книги. На самом деле, еще совсем недавно технология. NET вызывала у меня вполне законные опасения. Уж очень это все было
Глава 12 Разработка ценовых стратегий и программ В этой главе вы найдете ответы на следующие вопросы:1. Как потребители воспринимают и сравнивают цены?2. Как происходит первоначальное установление цены?3. Как происходит адаптация цен к различным рыночным ситуациям и
8.6. Разработка программ стимулирования труда Стимулирование труда – способ вознаграждения работников за участие в производстве, основанный на сопоставлении эффек-тивности труда и требований технологии.Существенная проблема в области управления производством –
Глава 5. Разработка и виды туристических программ Изначальной функцией туристических фирм является планирование туров. В процессе выполнения этой функции создается конкурентоспособный и привлекательный туристский продукт.Для того чтобы его создать, необходимо
В конце 2002 года московское издательство "Лори" выпустило книгу Алистера Коберна (Alistair Cockburn) "Быстрая разработка программного обеспечения". Русское название книги немного удивляет, потому что в оригинале она называется "Agile Software Development" и более правильный перевод звучал бы как "Гибкая разработка ПО". Впрочем, не будем придираться к переводчику, потому что подобных книг на русском языке еще не издавалось.
Отрасль разработки ПО достаточно молодая и активно развивающаяся. Еще формируются основные принципы разработки программ, постоянно появляются новые методологии, практики, языки программирования, новые технологии и инструменты. Все меняется очень динамично, поэтому практически невозможно создать единую правильную методологию разработки ПО. Однако до сих пор не прекращаются попытки изобрести "серебряную пулю", которая смогла бы решить все проблемы разработчиков. Возможно, к этому подталкивает наличие подобных процессов в других областях.
Возьмем, к примеру, строительство здания. В наше время строительство дома - совершенно простая задача. Все знают, какие действия надо предпринять, чтобы в итоге получился нужный дом. Процесс предсказуем. Роли четко определены. Технологии отлично известны. При разработке ПО возникают совершенно уникальные проблемы: пользователи зачастую просто не могут сказать, что же им в действительности нужно, пока не попробуют продукт в действии; требования постоянно меняются, поэтому создание солидного плана на весь проект лишено смысла; квалифицированных кадров не хватает; используемые технологии часто "сырые", а инструменты несовершенны. В таких условиях традиционные подходы к управлению проектами очень часто терпят поражение.
Периодически находились люди, которые начинали понимать проблемы создания ПО, но настоящий прорыв происходит именно теперь, после появления экстремального программирования (eXtreme Programming, www.extremeprogramming.com) и создания альянса гибкой разработки ПО (Agile Alliance, www.agilealliance.org). Гибкие методологии ломают стереотипы и полностью изменяют процесс разработки программ. Они изменяют сами принципы организации процесса.
Чем же отличаются гибкие методологии от традиционных? Можно выделить несколько основных отличий:
Многие гибкие методологии позволяют использовать сильные черты отдельно взятой команды разработчиков, потому что их можно подстроить под команду. Традиционные методологии заставляют команду подстроиться под себя.
Алистер Коберн - отличный разработчик и великолепный писатель. Он умеет ясно и последовательно излагать мысли и увлекать за собой. Так все-таки, о чем же книга? Она рассказывает о том, что каждый человек индивидуален и как использовать индивидуальность для пользы проекта. Что создание ПО представляет собой кооперативную игру изобретения и коммуникаций. Что коммуникации внутри команды крайне важны и зачастую определяют успех или неудачу проекта.
Какие бывают методологии, как они влияют на процесс разработки ПО и зачем они вообще нужны? В книгу включены крайне интересные приложения: программирование как построение теорий, применение языковых игр Витгенштейна к разработке ПО, применение методов Мусаши (самурай, живший в 17 веке и написавший книгу "Книга пяти колец") к разработке ПО.
Кроме того, в книге множество реальных примеров и диалогов, которые помогают лучше понять суть проблем разработки ПО. Существует множество мнений о вреде и пользе методологий. Книга "Быстрая разработка программного обеспечения" поможет вам найти ответы на многие вопросы.
Что действительно подкупает, так это исключительная рассудительность автора. Он никогда не заявляет, что его мнение единственно правильное, он всегда аргументирует свою точку зрения и делает это убедительно. Если вы до сих пор не особенно интересовались методологиями при разработке программного обеспечения, то после прочтения книги обязательно заинтересуетесь. Если активно интересовались, но не особенно применяли, то начнете применять.
Для управляющих проектами (Project Manager) и лидеров групп (Team Leader) книга из категории must read. Ваша эффективность, как руководителя, заметно возрастет.
Если говорить о качестве издания, то перевод достаточно хорош, за исключением термина agile. Единственный минус книги - плохая полиграфия, что не редкость для компьютерной литературы. Что удивительно, цена книги при таком качестве тоже не маленькая.
Книгу Алистера Коберна "Быстрая разработка программного обеспечения" можно приобрести в интернет-магазине www.rodina.by (www.rodina.by/book/info/go/6047.html).
Михаил ДУБАКОВ