Быстрая разработка программного обеспечения

Глава 5. Разработка и виды туристических программ Изначальной функцией туристических фирм является планирование туров. В процессе выполнения этой функции создается конкурентоспособный и привлекательный туристский продукт.Для того чтобы его создать, необходимо

Среды быстрой разработки приложений

CASE -системы часто отождествляют с инструментальными средами разработки ПО, называемыми средами быстрой разработки приложений (RAD - Rapid Application Development ). Примерами широко известных инструментальных сред RAD являются Visual Basic , Delphi , PowerBuilder фирм Microsoft , Borland , PowerSoft соответственно. Применение инструментальных сред существенно сокращает объем ручной работы программистов, особенно при проектировании интерактивных частей программ.

Большое практическое значение имеют инструментальные среды для разработки прикладных программ, предназначенных для работы под управлением операционных систем Windows , в связи с широкой распространенностью последних.

Простейшая система для написания Windows-программ на языке С++, позволяющая сократить объем кода, создаваемого пользователем вручную, основана на библиотеке DLL (Dynamic Link Library ), которая содержит модули, реализующие функции API для связи прикладных программ с ОС Windows .

Эта система получила развитие в MFC (Microsoft Foundation Classes ), представляющей собой библиотеку классов для автоматического создания каркасов ПО многоуровневых приложений. В библиотеке имеются средства для поддержки оконного интерфейса, работы с файлами и др.

В средах быстрой разработки приложений обычно реализуется способ программирования, называемый управлением событиями. При этом достигается автоматическое создание каркасов программ, существенно сокращается объем ручного кодирования. В этих средах пользователь может работать одновременно с несколькими экранами (окнами). Типичными являются окна из следующего списка.

1. Окно меню с пунктами « file », « edit », « window » и т. п., реализующими функции, очевидные из названия пунктов.
2. Окно формы, на котором собственно и создается прототип экрана будущей прикладной программы.
3. Палитра инструментов - набор изображений объектов пользовательского интерфейса, из которых можно компоновать содержимое окна формы.
4. Окно свойств и событий, с помощью которого ставятся в соответствие друг другу объекты окна формы, события и обработчики событий. Событием в прикладной программе является нажатие клавиши или установка курсора мыши в объект формы. Каждому событию должна соответствовать событийная процедура (обработчик события), которая проверяет код клавиши и вызывает нужную реакцию. В RAD имеются средства для удобства разработки обработчиков событий.
5. Окно редактора кода, в котором пользователь записывает создаваемую вручную часть кода.

6. Окно проекта - список модулей и форм в создаваемой программе.

Для написания событийных процедур в Visual Basic используется одноименный язык и текстовый редактор этого языка, в Delphi - язык и редактор языка Object Pascal . В CASE -системе фирмы IBM , включающей части VisualAge (для клиентских приложений) и VisualGen (для серверных приложений), базовым языком выбран SmallTalk . В среде разработки приложений клиент - сервер SQLWindows оригинальные фрагменты программ пишутся на специальном языке SAL . Нужно заметить, что для реализации вычислительных процедур и, в частности, для написания мини-спецификаций используется обычная для 3 GL технология программирования.

Обычно после написания прикладной программы на базовом языке компилятор системы переводит программу на промежуточный р-код. Вместе с интерпретатором /?-кода эта программа рассматривается как ЕХЕ-файл. В некоторых развитых средах компилируется обычный ЕХЕ-файл, не требующий интерпретации для своего исполнения.

Помимо упрощения написания пользовательского интерфейса, в средах RAD предусматриваются средства для реализации и ряда других функций. Так, в наиболее развитой версии Visual Basic к ним относятся средства выполнения следующих функций:

поддержка ODBC , что дает возможность работы с различными СУБД;

разработка баз данных;

разработка трехзвенных систем распределенных вычислений;

интерактивная отладка процедур на SQL Server ;

управление версиями при групповой разработке ПО;

моделирование и анализ сценариев распределенных вычислений.

Для создания сред RAD в случае сетевого программирования требуется решить ряд дополнительных проблем, обусловленных многоплатформенностью в гетерогенных сетях, обилием применяемых форматов данных, необходимостью защиты информации и т. п. Решение этих проблем достигнуто в объектно-ориентированных технологиях на базе языка сетевого программирования Java . Кроме того, с помощью Java удается решить еще одну актуальную для Internet и Intranet задачу - сделать Web -страницы интерактивными.

Хотя и ранее были известны технологии на базе промежуточных /?-кодов, именно технология Java оказалась наилучшим образом приспособленной для использования в гетерогенной сетевой среде. Она последовательно отражает принципы объектно-ориентированного программирования и обеспечивает приемлемую эффективность (производительность) исполнения программ. Эту эффективность можно еще более повысить, если в браузерах заменить интерпретацию компиляцией.

Для разработки ПО на языке Java создан ряд инструментальных средств. Основной средой является JDK (Java Developer " s Kit ). В ней имеются: 1) библиотеки классов, в том числе библиотеки элементов языка, часто используемых оболочек (wrapper ), процедур ввода-вывода, компонентов оконного интерфейса и другие; 2) инструментальные средства, такие, как компилятор байт-кодов, интерпретатор, просмотрщик аплетов, отладчик, формирователь оконных форм и т. п. Развитую RAD -среду - Power J - предлагает фирма Sybase .

Наряду с самостоятельными RAD -системами имеются и RAD -системы в составе САПР. Это прежде всего упомянутая выше система CAS . CADE фирмы Matra Datavision .

Разработка программного продукта знает много достойных методологий - иначе говоря, устоявшихся best practices. Выбор зависит от специфики проекта, системы бюджетирования, субъективных предпочтений и даже темперамента руководителя. В статье описаны методологии, с которыми мы регулярно сталкиваемся в Эдисоне .

1. «Waterfall Model» (каскадная модель или «водопад»)

Одна из самых старых, подразумевает последовательное прохождение стадий, каждая из которых должна завершиться полностью до начала следующей. В модели Waterfall легко управлять проектом. Благодаря её жесткости, разработка проходит быстро, стоимость и срок заранее определены. Но это палка о двух концах. Каскадная модель будет давать отличный результат только в проектах с четко и заранее определенными требованиями и способами их реализации. Нет возможности сделать шаг назад, тестирование начинается только после того, как разработка завершена или почти завершена. Продукты, разработанные по данной модели без обоснованного ее выбора, могут иметь недочеты (список требований нельзя скорректировать в любой момент), о которых становится известно лишь в конце из-за строгой последовательности действий. Стоимость внесения изменений высока, так как для ее инициализации приходится ждать завершения всего проекта. Тем не менее, фиксированная стоимость часто перевешивает минусы подхода. Исправление осознанных в процессе создания недостатков возможно, и, по нашему опыту, требует от одного до трех дополнительных соглашений к контракту с небольшим ТЗ.

С помощью каскадной модели мы создали множество проектов «с нуля», включая разработку только ТЗ. Проекты, о которых написано на Хабре: средний - рентгеновский микротомограф , мелкий - автообновление службы Windows на AWS .

Когда использовать каскадную методологию?

• Только тогда, когда требования известны, понятны и зафиксированы. Противоречивых требований не имеется.
• Нет проблем с доступностью программистов нужной квалификации.
• В относительно небольших проектах.

2. «V-Model»

Унаследовала структуру «шаг за шагом» от каскадной модели. V-образная модель применима к системам, которым особенно важно бесперебойное функционирование. Например, прикладные программы в клиниках для наблюдения за пациентами, интегрированное ПО для механизмов управления аварийными подушками безопасности в транспортных средствах и так далее. Особенностью модели можно считать то, что она направлена на тщательную проверку и тестирование продукта , находящегося уже на первоначальных стадиях проектирования. Стадия тестирования проводится одновременно с соответствующей стадией разработки, например, во время кодирования пишутся модульные тесты.

Пример нашей работы на основе V-методологии - мобильное приложение для европейского сотового оператора, который экономит расходы на роуминг во время путешествий. Проект выполняется по четкому ТЗ, но в него включен значительный этап тестирования: удобства интерфейса, функционального, нагрузочного и в том числе интеграционного, которое должно подтверждать, что несколько компонентов от различных производителей вместе работают стабильно, невозможна кража денег и кредитов.

Когда использовать V-модель?

• Если требуется тщательное тестирование продукта, то V-модель оправдает заложенную в себя идею: validation and verification.
• Для малых и средних проектов, где требования четко определены и фиксированы.
• В условиях доступности инженеров необходимой квалификации, особенно тестировщиков.

3. «Incremental Model» (инкрементная модель)

Инкрементные модели используются там, где отдельные запросы на изменение ясны, могут быть легко формализованы и реализованы. В наших проектах мы применяли ее для создания читалки DefView, а следом и сети электронных библиотек Vivaldi.

Как пример опишем cуть одного инкремента. Сеть электронных библиотек Vivaldi пришла на смену DefView. DefView подключалась к одному серверу документов, а теперь может подключаться ко многим. На площадку учреждения, желающего транслировать свой контент определенной аудитории, устанавливается сервер хранения, который напрямую обращается к документам и преобразует их в нужный формат. Появился корневой элемент архитектуры - центральный сервер Vivaldi, выступающий в роли единой поисковой системы по всем серверам хранения, установленным в различных учреждениях.

Когда использовать инкрементную модель?

• Когда основные требования к системе четко определены и понятны. В то же время некоторые детали могут дорабатываться с течением времени.
• Требуется ранний вывод продукта на рынок.
• Есть несколько рисковых фич или целей.

4. «RAD Model» (rapid application development model или быстрая разработка приложений)

Модель быстрой разработки приложений включает следующие фазы:

• Бизнес-моделирование: определение списка информационных потоков между различными подразделениями.
• Моделирование данных: информация, собранная на предыдущем этапе, используется для определения объектов и иных сущностей, необходимых для циркуляции информации.
• Моделирование процесса: информационные потоки связывают объекты для достижения целей разработки.
• Сборка приложения: используются средства автоматической сборки для преобразования моделей системы автоматического проектирования в код.
• Тестирование: тестируются новые компоненты и интерфейсы.

Может использоваться только при наличии высококвалифицированных и узкоспециализированных архитекторов. Бюджет проекта большой, чтобы оплатить этих специалистов вместе со стоимостью готовых инструментов автоматизированной сборки. RAD-модель может быть выбрана при уверенном знании целевого бизнеса и необходимости срочного производства системы в течение 2-3 месяцев.

5. «Agile Model» (гибкая методология разработки)

В «гибкой» методологии разработки после каждой итерации заказчик может наблюдать результат и понимать, удовлетворяет он его или нет. Это одно из преимуществ гибкой модели. К ее недостаткам относят то, что из-за отсутствия конкретных формулировок результатов сложно оценить трудозатраты и стоимость, требуемые на разработку. Экстремальное программирование (XP) является одним из наиболее известных применений гибкой модели на практике.

В основе такого типа - непродолжительные ежедневные встречи - «Scrum» и регулярно повторяющиеся собрания (раз в неделю, раз в две недели или раз в месяц), которые называются «Sprint». На ежедневных совещаниях участники команды обсуждают:

• отчёт о проделанной работе с момента последнего Scrum’a;
• список задач, которые сотрудник должен выполнить до следующего собрания;
• затруднения, возникшие в ходе работы.

Когда использовать Agile?

• Когда потребности пользователей постоянно меняются в динамическом бизнесе.
• Изменения на Agile реализуются за меньшую цену из-за частых инкрементов.
• В отличие от модели водопада, в гибкой модели для старта проекта достаточно лишь небольшого планирования.

6. «Iterative Model» (итеративная или итерационная модель)

На диаграмме показана итерационная «разработка» Мона Лизы. Как видно, в первой итерации есть лишь набросок Джоконды, во второй - появляются цвета, а третья итерация добавляет деталей, насыщенности и завершает процесс. В инкрементной же модели функционал продукта наращивается по кусочкам, продукт составляется из частей. В отличие от итерационной модели, каждый кусочек представляет собой целостный элемент.

Примером итерационной разработки может служить распознавание голоса. Первые исследования и подготовка научного аппарата начались давно, в начале - в мыслях, затем - на бумаге. С каждой новой итерацией качество распознавания улучшалось. Тем не менее, идеальное распознавание еще не достигнуто, следовательно, задача еще не решена полностью.

Когда оптимально использовать итеративную модель?

• Требования к конечной системе заранее четко определены и понятны.
• Проект большой или очень большой.
• Основная задача должна быть определена, но детали реализации могут эволюционировать с течением времени.

7. «Spiral Model» (спиральная модель)

«Спиральная модель» похожа на инкрементную, но с акцентом на анализ рисков. Она хорошо работает для решения критически важных бизнес-задач, когда неудача несовместима с деятельностью компании, в условиях выпуска новых продуктовых линеек, при необходимости научных исследований и практической апробации.

Спиральная модель предполагает 4 этапа для каждого витка:

1. планирование;
2. анализ рисков;
3. конструирование;
4. оценка результата и при удовлетворительном качестве переход к новому витку.

Подытожим

На слайде продемонстрированы различия двух наиболее распространенных методологий.

В современной практике модели разработки программного обеспечения многовариантны. Нет единственно верной для всех проектов, стартовых условий и моделей оплаты. Даже столь любимая всеми нами Agile не может применяться повсеместно из-за неготовности некоторых заказчиков или невозможности гибкого финансирования. Методологии частично пересекаются в средствах и отчасти похожи друг на друга. Некоторые другие концепции использовались лишь для пропаганды собственных компиляторов и не привносили в практику ничего нового.

О технологиях разработки:
Ещё раз про семь основных методологий разработки .
10 главных ошибок масштабирования систем .
8 принципов планирования разработки, упрощающих жизнь .
5 главных рисков при заказной разработке ПО .

Только зарегистрированные пользователи могут участвовать в опросе. , пожалуйста.

Rapid Application Development (RAD) - это жизненный цикл процесса проектирования, созданный для достижения более высоких скорости разработки и качества ПО, чем это возможно при традиционном подходе к проектированию.

Концепция RAD стала ответом на методы разработки программ 1970-х и начала 1980-х годов, такие как «модель водопада». Эти методы предусматривали настолько медленный процесс создания программы, что зачастую даже требования к программе успевали измениться до окончания разработки. Основателем RAD считается сотрудник IBM Джеймс Мартин, который в 1980-х годах сформулировал основные принципы RAD, основываясь на идеях Барри Бойма и Скотта Шульца. А в 1991 году Мартин опубликовал известную книгу, в которой детально изложил концепцию RAD и возможности её применения. В настоящее время RAD становится общепринятой схемой для создания средств разработки программных продуктов.

RAD предполагает, что разработка ПО осуществляется небольшой командой разработчиков за срок порядка трех-четырех с применением инструментальных средств визуального моделирования и разработки. Технология RAD предусматривает активное привлечение заказчика уже на ранних стадиях - обследование организации, выработка требований к системе. Методология RAD является одним из подходов к разработке ПО в рамках спиральной модели ЖЦ.

Жизненный цикл ПО по методологии RAD состоит из четырех фаз:

фаза анализа и планирования требований;

фаза проектирования;

фаза построения;

фаза внедрения.

На стадии анализа и планирования требований пользователи осуществляют следующие действия:

определение функций, которые должна выполнять система;

выделение наиболее приоритетных функций, требующих проработки в первую очередь;

описание информационных потребностей.

Формулирование требований к системе осуществляется в основном силами пользователей под руководством специалистов-разработчиков. Кроме того, на данной стадии решаются следующие задачи:

ограничивается масштаб проекта;

устанавливаются временные рамки для каждой из последующих стадий;

определяется сама возможность реализации проекта в заданных размерах финансирования на имеющихся аппаратных средствах и т.п. Результатом стадии должны быть:

список расположенных по приоритету функций будущего ПО ИС;

предварительные модели ПО.

На стадии проектирования часть пользователей принимает участие в техническом проектировании системы под руководством специалистов-разработчиков. Для быстрого получения работающих прототипов приложений используются соответствующие инструментальные средства (CASE-средства). Пользователи, непосредственно взаимодействуя с разработчиками, уточняют и дополняют требования к системе, которые не были выявлены на предыдущей стадии. На данной стадии выполняются следующие действия:

более детально рассматриваются процессы системы;

при необходимости для каждого элементарного процесса создается частичный прототип (экранная форма, диалог, отчет, устраняющий неясности или неоднозначности);

устанавливаются требования разграничения доступа к данным;

определяется состав необходимой документации.

Далее проект распределяется между различными командами разработчиков. В случае использования CASE-средств это означает деление функциональной модели системы (диаграммы потоков данных для структурного подхода или диаграммы вариантов использования для объектно-ориентированного подхода). Результатом данной стадии должны быть:

общая информационная модель системы;

функциональные модели системы в целом и подсистем, реализуемых отдельными командами разработчиков;

точно определенные интерфейсы между автономно разрабатываемыми подсистемами;

построенные прототипы экранных форм, отчетов, диалогов.

Все модели и прототипы должны быть получены с применением тех CASE-средств, которые будут использоваться в дальнейшем при построении системы. Данное требование обусловлено необходимостью избежать неконтролируемого искажения данных при передаче информации о проекте со стадии на стадию.

На стадии реализации выполняется быстрая разработка приложения:

Разработчики производят итеративное построение реальной системы на основе полученных на предыдущей стадии моделей, а также требований нефункционального характера (требований к надежности, производительности и т.п.).

Пользователи оценивают получаемые результаты и вносят коррективы, если в процессе разработки система перестает удовлетворять определенным ранее требованиям. Тестирование системы осуществляется в процессе разработки.

После окончания работ каждой отдельной команды разработчиков производится постепенная интеграция данной части системы с остальными, формируется полный программный код, выполняется тестирование совместной работы данной части приложения, а затем тестирование системы в целом. Реализация системы завершается выполнением следующих работ:

осуществляется анализ использования данных и определяется необходимость их распределения;

производится физическое проектирование базы данных;

формулируются требования к аппаратным ресурсам;

устанавливаются способы увеличения производительности;

завершается разработка документации проекта. Результатом стадии является готовая система, удовлетворяющая всем согласованным требованиям.

На стадии внедрения производится обучение пользователей и организационные изменения.

Применение технологии RAD целесообразно, когда:

требуется выполнение проекта в сжатые сроки (90 дней);

нечетко определены требования к ПО;

проект выполняется в условиях ограниченности бюджета;

интерфейс пользователя (GUI) есть главный фактор;

проект большой, но поддается разделению на более мелкие функциональные компоненты;

ПО не обладает большой вычислительной сложностью.

RAD-технология не является универсальной, то есть ее применение целесообразно не всегда. Например, в проектах, где требования к программному продукту четко определены и не должны меняться, вовлечение заказчика в процесс разработки не требуется и более эффективной может быть иерархическая разработка (каскадный метод). То же касается проектов, ПО, сложность которых определяется необходимостью реализации сложных алгоритмов, а роль и объем пользовательского интерфейса невелик.

Рисунок 1 - Сравнение RAD и Каскадного метода