Cleanroom Software Engineering

В 1987 году IBM предложила технологию разработки Cleanroom («чистая комната»), в котором принципы эволюционной разработки IID сочетались с более формализованными методами спецификации и верификации. Технология Cleanroom предназначена для создания высоконадежного ПО не содержащего ошибок. Само название Cleanroom отражает главную идею данной технологии разработки – переход от устранения дефектов к их к предотвращению.

Принципы Cleanroom.

● Инкрементная разработка на основе статистического контроля качества.

● Разработка основывается на математических правилах.

● Тестирование на основе методов статистики.

● Пошаговая детализация.

● Командная разработка. Cleanroom предполагает, что разработка ведется небольшими группами (от 6 до 8 человек).

● Перераспределение времени между этапами жизненного цикла.

● Использование имеющихся приемов разработки.

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

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

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

Rational Unified Process

Rational Unified Process (RUP) — методология разработки программного обеспечения, созданная компанией Rational Software.

В основе RUP лежат следующие принципы:

● ранняя идентификация и непрерывное (до окончания проекта) устранение основных рисков.

● концентрация на выполнении требований заказчиков к исполняемой программе (анализ и построение модели прецедентов (вариантов использования)).

● ожидание изменений в требованиях, проектных решениях и реализации в процессе разработки.

● компонентная архитектура, реализуемая и тестируемая на ранних стадиях проекта.

● постоянное обеспечение качества на всех этапах разработки проекта (продукта).

● работа над проектом в сплочённой команде, ключевая роль в которой принадлежит архитекторам.

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

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

1. Начальная стадия (Inception)

При завершении начальной фазы оценивается достижение этапа жизненного цикла цели (англ. Lifecycle Objective Milestone), которое предполагает соглашение заинтересованных сторон о продолжении проекта.

2. Уточнение (Elaboration)

В фазе «Уточнение» производится анализ предметной области и построение исполняемой архитектуры.Успешное выполнение фазы уточнения означает достижение этапа жизненного цикла архитектуры (англ. Lifecycle Architecture Milestone).

3. Построение (Construction)

В фазе «Построение» происходит реализация большей части функциональности продукта. Фаза Построение завершается первым внешним релизом системы и вехой начальной функциональной готовности (Initial Operational Capability).

4. Внедрение (Transition)

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

OpenUP

OpenUP — это итеративно-инкрементальный метод разработки ПО. Позиционируется как легкий и гибкий вариант RUP.

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

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

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

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

Одной из задач жизненного цикла проекта является концентрация внимания на двух мотивах заинтересованных лиц: снижении риска и создании потребительской ценности. Фазы OpenUP нацеливают рабочую группу на снижение риска с одновременным отслеживанием процесса создания потребительской ценности.

RAD

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

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

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

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

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

RAD предполагает 4 фазы разработки.

1. Планирование — совокупность требований, полученных при системном планировании и анализе процедуры разработки жизненного цикла (SDLC).

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

3. Конструирование — этап, в котором основная задача заключается в разработке программ и приложений.

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

Технология быстрой разработки приложений (RAD) позволяет обеспечить:

● быстроту продвижения программного продукта на рынок;

● интерфейс, устраивающий пользователя;

● лёгкую адаптируемость проекта к изменяющимся требованиям;

● простоту развития функциональности системы.