Одним из возможных подходов к разработке ПО в рамках спиральной модели ЖЦ является получившая в последнее время широкое распространение методология быстрой разработки приложений RAD (Rapid Application Development). Под этим термином обычно понимается процесс разработки ПО, содержащий 3 элемента:

    небольшую команду программистов (от 2 до 10 человек);

    короткий, но тщательно проработанный производственный график (от 2 до 6 мес.);

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

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

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

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

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

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

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

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

На фазе проектирования часть пользователей принимает участие в техническом проектировании системы под руководством специалистов-разработчиков. CASE-средства используются для быстрого получения работающих прототипов приложений. Пользователи, непосредственно взаимодействуя с ними, уточняют и дополняют требования к системе, которые не были выявлены на предыдущей фазе. Более подробно рассматриваются процессы системы. Анализируется и, при необходимости, корректируется функциональная модель. Каждый процесс рассматривается детально. При необходимости для каждого элементарного процесса создается частичный прототип: экран, диалог, отчет, устраняющий неясности или неоднозначности. Определяются требования разграничения доступа к данным. На этой же фазе происходит определение набора необходимой документации.

После детального определения состава процессов оценивается количество функциональных элементов разрабатываемой системы и принимается решение о разделении ИС на подсистемы, поддающиеся реализации одной командой разработчиков за приемлемое для RAD-проектов время - порядка 60 - 90 дней. С использованием CASE-средств проект распределяется между различными командами (делится функциональная модель). Результатом данной фазы должны быть:

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

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

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

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

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

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

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

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

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

    производится анализ использования данных;

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

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

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

    завершается разработка документации проекта.

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

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

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

Методология RAD неприменима для построения сложных расчетных программ, операционных систем или программ управления космическими кораблями, т.е. программ, требующих написания большого объема (сотни тысяч строк) уникального кода.

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

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

В качестве итога перечислим основные принципы методологии RAD:

    разработка приложений итерациями;

    необязательность полного завершения работ на каждом из этапов жизненного цикла;

    обязательное вовлечение пользователей в процесс разработки ИС;

    необходимое применение CASE-средств, обеспечивающих целостность проекта;

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

    необходимое использование генераторов кода;

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

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

    ведение разработки немногочисленной хорошо управляемой командой профессионалов;

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

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

Модель быстрой разработки приложений (Rapid Application Development) - второй пример применения инкрементной стратегии конструирования (рис. 1.5).

RAD-модель обеспечивает экстремально короткий цикл разработки. RAD - высокоскоростная адаптация линейной последовательной модели, в которой быстрая разработка достигается за счет использования компонентно-ориентированного конструирования. Если требования полностью определены, а проектная область ограничена, RAD-процесс позволяет группе создать полностью функциональную систему за очень короткое время (60-90 дней). RAD-подход ориентирован на разработку информационных систем и выделяет следующие этапы:

q бизнес-моделирование. Моделируется информационный поток между бизнес-функциями. Ищется ответ на следующие вопросы: Какая информация руководит бизнес-процессом? Какая генерируется информация? Кто генерирует ее? Где информация применяется? Кто обрабатывает ее?

q моделирование данных . Информационный поток, определенный на этапе бизнес-моделирования, отображается в набор объектов данных, которые требуются для поддержки бизнеса. Идентифицируются характеристики (свойства, атрибуты) каждого объекта, определяются отношения между объектами;

q моделирование обработки. Определяются преобразования объектов данных, обеспечивающие реализацию бизнес-функций. Создаются описания обработки для добавления, модификации, удаления или нахождения (исправления) объектов данных;

q генерация приложения. Предполагается использование методов, ориентированных на языки программирования 4-го поколения. Вместо создания ПО с помощью языков программирования 3-го поколения, RAD-процесс работает с повторно используемыми программными компонентами или создает повторно используемые компоненты. Для обеспечения конструирования используются утилиты автоматизации;

q тестирование и объединение. Поскольку применяются повторно используемые компоненты, многие программные элементы уже протестированы. Это уменьшает время тестирования (хотя все новые элементы должны быть протестированы).

Рис. 1.5. Модель быстрой разработки приложений

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

Применение RAD имеет- и свои недостатки, и ограничения.

1. Для больших проектов в RAD требуются существенные людские ресурсы (необходимо создать достаточное количество групп).

2. RAD применима только для таких приложений, которые могут декомпозироваться на отдельные модули и в которых производительность не является критической величиной.

3. RAD не применима в условиях высоких технических рисков (то есть при использовании новой технологии).

Спиральная модель

Спиральная модель - классический пример применения эволюционной стратегии конструирования.

Рис. 1.6. Спиральная модель: 1 - начальный сбор требований и планирование проекта;

начальных требований; 4 - анализ риска на основе реакции заказчика; 5 - переход

к комплексной системе; 6 - начальный макет системы; 7 - следующий уровень макета;

8 - сконструированная система; 9 - оценивание заказчиком

Как показано на рис. 1.6, модель определяет четыре действия, представляемые четырьмя квадрантами спирали.

1. Планирование - определение целей, вариантов и ограничений.

2. Анализ риска - анализ вариантов и распознавание/выбор риска.

3. Конструирование - разработка продукта следующего уровня.

4. Оценивание - оценка заказчиком текущих результатов конструирования.

Интегрирующий аспект спиральной модели очевиден при учете радиального измерения спирали. С каждой итерацией по спирали (продвижением от центра к периферии) строятся все более полные версии ПО.

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

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

Достоинства спиральной модели:

1) наиболее реально (в виде эволюции) отображает разработку программного обеспечения;

2) позволяет явно учитывать риск на каждом витке эволюции разработки;

3) включает шаг системного подхода в итерационную структуру разработки;

4) использует моделирование для уменьшения риска и совершенствования программного изделия.

Недостатки спиральной модели:

1) новизна (отсутствует достаточная статистика эффективности модели);

2) повышенные требования к заказчику;

3) трудности контроля и управления временем разработки.

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

  • Современное управление
  • Контроль
  • Мониторинг

Срочно - не значит некачественно?

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

  • Чтобы продукт получался быстро - необходима либо слаженная команда профессионалов, либо отдельный исполнитель-универсал. Разумеется, это не подходит ко всем программам.
  • Контроль качества - обязательная процедура. Контроль качества и отлов «багов» в таком процессе как создание программного обеспечения не может быть исключён из производственного процесса, даже для ускорения. Это необходимое условие для профессионально сделанной программы.
  • Чтобы срочность не вредила итоговому продукту, нужны исполнители, которые давно освоили и создали свой производственный процесс. Скорее всего разработка ПО у таких специалистов пройдёт действительно качественно и быстро.

Заказать срочные услуги разработки сегодня может любой, кому исполнение необходимо быстро, срочно и профессионально. Остаётся открытым вопрос, где найти грамотных специалистов под срочное создание программ?

Поиск исполнителей.

Много специалистов, вольнонаёмных и объединённых в организации оказывают подобные услуги. Заказать у них можно всё что угодно, естественно что цены будут зависеть от уровня специалиста, его востребованности и сложности задачи. Есть три основных пути, которыми пользуется большинство заказчиков.

  • Студийная разработка. Студии предполагают хорошее качество исполнения, но за срочность берут очень и очень солидные надбавки. Заказать у них программу можно, если заказчик готов оплатить эти расходы.
  • Фрилансеры. Спорный вопрос. Можно сэкономить, а можно получить сорванные сроки и очень посредственное качество.

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

Разработка программного продукта знает много достойных методологий - иначе говоря, устоявшихся 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-модель - разновидность инкрементной модели. В RAD-модели компоненты или функции разрабатываются несколькими высококвалифицированными командами параллельно, будто несколько мини-проектов. Временные рамки одного цикла жестко ограничены. Созданные модули затем интегрируются в один рабочий прототип. Синергия позволяет очень быстро предоставить клиенту для обозрения что-то рабочее с целью получения обратной связи и внесения изменений.

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

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

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

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


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

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

  • отчёт о проделанной работе с момента последнего Scrum’a;
  • список задач, которые сотрудник должен выполнить до следующего собрания;
  • затруднения, возникшие в ходе работы.
Методология подходит для больших или нацеленных на длительный жизненный цикл проектов, постоянно адаптируемых к условиям рынка. Соответственно, в процессе реализации требования изменяются. Стоит вспомнить класс творческих людей, которым свойственно генерировать, выдавать и опробовать новые идеи еженедельно или даже ежедневно. Гибкая разработка лучше всего подходит для этого психотипа руководителей. Внутренние стартапы компании мы разрабатываем по Agile. Примером клиентских проектов является Электронная Система Медицинских Осмотров , созданная для проведения массовых медосмотров в считанные минуты. Во втором абзаце этого отзыва , наши американские партнеры описали очень важную вещь, принципиальную для успеха на Agile.

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

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

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

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

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

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

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

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

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


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

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

  1. планирование;
  2. анализ рисков;
  3. конструирование;
  4. оценка результата и при удовлетворительном качестве переход к новому витку.
Эта модель не подойдет для малых проектов, она резонна для сложных и дорогих, например, таких, как разработка системы документооборота для банка, когда каждый следующий шаг требует большего анализа для оценки последствий, чем программирование. На проекте по разработке СЭД для ОДУ Сибири СО ЕЭС два совещания об изменении кодификации разделов электронного архива занимают в 10 раз больше времени, чем объединение двух папок программистом. Государственные проекты, в которых мы участвовали, начинались с подготовки экспертным сообществом дорогостоящей концепции, которая отнюдь не всегда бесполезна, поскольку окупается в масштабах страны.

Подытожим


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

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

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

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

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 каждый прототип развивается в часть будущей системы. Таким образом, на следующую стадию пере­дается более полная и полезная информация.

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

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

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

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

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

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

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

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

    завершается разработка документации проекта.