Системный подход к разработке ПО. Временной и "пространственный " аспекты системного подхода. Каскадная модель жизненного цикла ПО. Общие принципы и подходы к разработке ПО. Модели разработки ПО Водопадная Каскадная модель Спиральная Экстремальное програм

Модели разработки ПО Водопадная Каскадная модель Спиральная Экстремальное программирование UI Prototyping Инкрементальная W-Model Testing Унифицированный процесс разработки программного обеспечения (USDP) Методология MSF

Водопадная модель Анализ требований Составляется спецификация продукта Проектирование Составляется архитектура продукта Реализация Разработка исходного кода Интеграция отдельных частей исходного кода Тестирование и устранение дефектов

Экстремальное программирование Анализ исходных требований Проектирование Интеграция Реализация Тестирование Новые требования Анализ/Утвержде ние/модификация плана разработки Выпуск продукта

UI Prototyping Выпуск продукта Разработка ПО с учетом изменений Уточнение требований и спецификации Изменение прототипа и доработка некоторой функциональности Базовая функциональность Прототип интерфейса Предварительная спецификация

Инкрементальная разработка Итерация 1 Итерация 2 …. Анализ требований Проектирование Реализация Компонентное тестирование Интеграция Тестирование единого целого Итерация N

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

Унифицированный процесс разработки программного обеспечения (USDP) Сбор требований Итер 1…. Итер N Проектирование Итер 1…. Итер N Реализация Итер 1…. Итер N Конструирование Итер 1…. Итер N Тестирование Итер 1…. Итер N

Типичные компоненты архитектуры программного продукта и типичные требования к ПО Ø Ø Ø Ø Организация программы Основные классы системы Организация данных Бизнес–правила Пользовательский интерфейс Управление ресурсами Безопасность Производительность Масштабируемость Взаимодействие с другими системами (интеграция) Интернационализация, локализация Ввод-вывод данных Обработка ошибок

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

Типичные компоненты архитектуры программного продукта и типичные требования к ПО Кривая надежности N t 1 t Чем дальше, тем тяжелее будет найти ошибку. Чем сложнее система, тем больше вероятность отказов и сбоев.

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

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

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

Рефакторинг ПО Рефакторинг предполагает адаптацию программного обеспечения к новому аппаратному обеспечению и к новым ОС, новым средствам разработки, новым требованиям, а также архитектуре и функциональности ПО. Это изменение внутренней структуры ПО без изменения его внешнего поведения, призванное обеспечить модификацию ПО. Разумные причины проведения рефакторинга: Код повторяется; реализация метода слишком велика; слишком большая вложенность циклов, или же сам цикл очень большой; класс имеет плохую связность (свойства и методы класса должны описывать только 1 объект); интерфейс класса не формирует согласованную абстракцию; метод принимает слишком много параметров. Необходимо стараться, чтобы количество параметров было разумно минимальным; отдельные части класса изменяются независимо от других частей класса;

Рефакторинг ПО при изменении программы требуется параллельное изменение нескольких классов. При возникновении такой ситуации необходимо провести реорганизацию классов с целью минимизации в будущем мест возможных изменений; приходиться параллельно изменять несколько иерархий наследования; приходиться изменять несколько блоков case. Необходимо провести модификацию программы таким образом, чтобы сделать реализацию блока case, а вызывать ее в нужном количестве раз в программе; родственные элементы данных, используемые вместе, не организованы в классы. Если вы неоднократно используете один и тот же набор элементов данных, то целесообразно рассмотреть объединение этих данных и выполняемые над ними операции поместить в отдельный класс;

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

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

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

Водопадная модель Анализ требований Проектирование Реализация Интеграция Тестирование Составляется спецификация продукта Составляется архитектура продукта Разработка исходного кода Интеграция отдельных частей исходного кода Тестирование и устранение дефектов

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

Типичные компоненты архитектуры программного продукта и типичные требования к ПО Организация программы Основные классы системы Организация данных Бизнес–правила Пользовательский интерфейс Управление ресурсами Безопасность Производительность Масштабируемость Взаимодействие с другими системами (интеграция) Интернационализация, локализация Ввод-вывод данных Обработка ошибок

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

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

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

Рефакторинг ПО Код повторяется; реализация метода слишком велика; слишком большая вложенность циклов, или же сам цикл очень большой; класс имеет плохую связность (свойства и методы класса должны описывать только 1 объект); интерфейс класса не формирует согласованную абстракцию; метод принимает слишком много параметров. Необходимо стараться, чтобы количество параметров было разумно минимальным; отдельные части класса изменяются независимо от других частей класса; Рефакторинг предполагает адаптацию программного обеспечения к новому аппаратному обеспечению и к новым ОС, новым средствам разработки, новым требованиям, а также архитектуре и функциональности ПО. Это изменение внутренней структуры ПО без изменения его внешнего поведения, призванное обеспечить модификацию ПО. Разумные причины проведения рефакторинга:

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

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

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

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

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

В соответствии с международным стандартом ISO/IEC 12207 «информационные технологии – Процессы жизненного цикла ПО» процесс разработки ПО содержит следующие этапы жизненного цикла ПО:

1) анализ системных требований и области применения;

2) проектирование архитектуры системы;

3) анализ требований к ПО(спецификации, внешние интерфейсы,);

4) проектирование архитектуры ПО;

5) детальное проектирование каждой единицы ПО;

6) кодирование ПО (программирование)

7) тестирование единиц ПО;

8) интеграция (объединение ПО) и тестирование совокупности единиц ПО;

9) квалификационные испытания ПО (комплексное тестирование);

10) интеграция системы единицы структуры ПО должны быть объединены с единицами аппаратных средств;

11) квалификационные испытания системы;

12) установка ПО.

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

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

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

Спиральная модель жизненного цикла ПО. «Тяжелые и облегченные» (быстрые) технологии разработки ПО

Рассмотренная модель жизненного цикла (ЖЦ) относится к модели каскадного типа. Этот тип модели ЖЦ хорош для ПО, для которого в самом начале разработки возможно полно и точно сформулировать все требования к ПО.

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

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

Главная задача как можно быстрее достичь работоспособного ПО, активизируя тем самым процесс уточнения и дополнения требований. Это так называемая спиральная модель ЖЦ ПО.

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

Считается, что спиральная схема ЖЦ ПО предназначена не столько для торопливых разработчиков, сколько для ПО, некачественные первые версии которого допустимы по функциональному назначению ПО.

Существует направление «Быстрых технологий» разработки ПО (Agile Software Development), дающее идеологическое обоснование взглядам, связанным с спиральной моделью ЖЦ. Эти технологии базируются на четырех идеях:

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

Работающее ПО важнее наличия документации на него,

Сотрудничество с заказчиком важнее формальных договоров,

Быстрое реагирование на внешние изменения важнее строгого следования намеченным планам.

Рис. 8.2 - Схема спирального ЖЦ ПО

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

Правильность этих принципов в определенной мере, когда разработку ПО ведет небольшое количество квалифицированных и преданных делу «фанатов») для разработки некоторых видов ПО оспаривать трудно. Однако, Agile технологии и это признают их идеологи применимы в программных проектах определенного класса и масштаба, так же, как и вообще спиральная модель ЖЦ, а именно там, где ошибки ПО приводят к некоторым неудобствам либо потерям возместимых средств.

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

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

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

«Тяжелые и облегченные» технологии разработки ПО. Разработчики многих видов ПО считают каскадную модель жизненного цикла слишком регламентированной, слишком документированной и тяжелой и поэтому нерациональной. Существует направление «Быстрых технологий» (легких технологий) разработки ПО (Agile Software Development), дающее идеологическое обоснование этим взглядам. Эти технологии базируются на четырех идеях:

1. интерактивное взаимодействие индивидуумов важнее формальных процедур и инструментов,

2. работающее ПО важнее наличия документации на него,

3. сотрудничество с заказчиком важнее формальных договоров с ним,

4. быстрое реагирование на внешние изменения важнее строгого следования намеченным планам.

Правильность этих принципов кроме третьего в определенной мере (разработку ПО ведет небольшое количество квалифицированных программистов - «фанатов», не нуждающихся в контроле и дополнительной мотивации) для разработки ПО оспаривать трудно. Однако, Agile технологии и это признают их идеологи применимы в программных проектах определенного класса и масштаба, так же как и вообще спиральная модель ЖЦ, а именно там, где ошибки ПО приводят к некоторым неудобствам либо потерям возместимых средств и там где требования к ПО постоянно меняются, так как были заранее плохо определены, и требуется быстрая адаптация к этим изменениям.

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

Примером Agile технологий является «Экстремальное программирование» (ХР). Итерации в ХР очень короткие и состоят из четырех операций: кодирования, тестирования, выслушивание заказчика, проектирование. Принципы ХР – минимальность, простота, участие заказчика, короткий цикл, тесные взаимодействия разработчиков – они должны сидеть в одной комнате, ежедневных оперативных совещаний совместно с заказчиком представляются разумными и давно применяются не только в быстрых технологиях, но в ХР они доведены до экстремальных значений.

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

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

В больших коллективах разработчиков проблема управления – выходит на передний план.

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

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

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

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

Все наиболее распространенные методы структурного подхода базируются на ряде общих принципов:

1. Принцип «разделяй и властвуй»;

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

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

1. Принцип абстрагирования- выделение существенных аспектов системы и отвлечение от несущественных.

2. Принцип непротиворечивости,обоснованность и согласованность элементов системы.

3. Принцип структурирования данных- данные должны быть структурированы и иерархически организованы.

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

· DFD (Data Flow Diagrams) - диаграммы потоков данных;

· SADT (Structured Analysis and Design Technique - методология структурного анализа и проектирования) - модели и соответствующие функциональные диаграммы: нотации IDEF0 (функциональное моделирование систем), IDEF1х (концептуальное моделирование баз данных), IDEF3х (построение систем оценки качества работы объекта; графическое описание потока процессов, взаимодействия процессов и объектов, которые изменяются этими процессами);

· ERD (Entity - Relationship Diagrams) - диаграммы «сущность-связь».

Практически во всех методах структурного подхода (структурного анализа) на стадии формирования требований к ПО используются две группы средств моделирования:

1. Диаграммы, иллюстрирующие функции, которые система должна выполнять, и связи между этими функциями - DFD или SADT (IDEF0).

2. Диаграммы, моделирующие данные и их отношения (ERD).

Конкретный вид перечисленных диаграмм и интерпретация их конструкций зависят от стадии ЖЦ ПО.

На стадии формирования требований к ПО SADT-модели и DFD используются для построения модели “AS-IS” и модели “TO-BE”, отражая таким образом существующую и предлагаемую структуру бизнес-процессов организации и взаимодействие между ними (использование SADT-моделей, как правило, ограничивается только данной стадией, поскольку они изначально не предназначались для проектирования ПО). С помощью ERD выполняется описание используемых в организации данных на концептуальном уровне, не зависимо от средств реализации базы данных (СУБД).

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

Презентацию к данной лекции Вы можете скачать .

Цель лекции:

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

Введение

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

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

Принципы и значение гибкой разработки

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

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

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

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

Для создания высокопроизводительных команд в гибких методологиях кроме эффективной команды и хороших коммуникаций необходим совершенный программный инструментарий .

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

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

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

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

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

Вышеприведенным принципам, в определенной степени, соответствуют ряд методологий разработки программного обеспечения:

AgileModeling	набор понятий, принципов и приёмов (практик), позволяющих быстро и просто выполнять моделирование и документирование в проектах разработки программного обеспечения ;
AgileUnifiedProcess(AUP)	упрощенная версия IBM RationalUnifiedProcess(RUP), которая описывает простое и понятное приближение (модель) для создания программного обеспечения для бизнес-приложений ;
OpenUP	это итеративно-инкрементальный метод разработки программного обеспечения. Позиционируется как лёгкий и гибкий вариантRUP ;
AgileDataMethod	группа итеративных методов разработки программного обеспечения, в которых требования и решения достигаются в рамках сотрудничества разных кросс-функциональных команд ;
DSDM	методика разработки динамических систем, основанная на концепции быстрой разработки приложений (RapidApplicationDevelopment, RAD). Представляет собой итеративный и инкрементный подход, который придаёт особое значение продолжительному участию в процессе пользователя/потребителя ;
Extremeprogramming (XP)	экстремальное программирование;
Adaptive software development (ADD)	адаптивная разработка программ ;
Featuredrivendevelopment (FDD)	разработка ориентированная на постепенное добавление функциональности ;
GettingReal	итеративный подход без функциональных спецификаций, использующийся для веб-приложений ;
MSFfogAgileSoftwareDevelopment	гибкая методология разработки ПО компании Microsoft ;
Scrum	устанавливает правила управления процессом разработки и позволяет использовать уже существующие практики кодирования, корректируя требования или внося тактические изменения [