 |
Стратегии проектирования программного обеспечения
|
|
|
|
Существуют 3 стратегии конструирования ПО:
q однократный проход (водопадная стратегия) — линейная последовательность этапов конструирования;
q инкрементная стратегия. В начале процесса определяются все пользовательские и системные требования, оставшаяся часть конструирования выполняется в виде последовательности версий. Первая версия реализует часть запланированных возможностей, следующая версия реализует дополнительные возможности и т. д., пока не будет получена полная система;
q эволюционная стратегия. Система также строится в виде последовательности версий, но в начале процесса определены не все требования. Требования уточняются в результате разработки версий.
Характеристики стратегий конструирования программного обеспечения в соответствии с требованиями стандарта IEEE/EIA 12207.2 приведены в табл. 1.
Таблица 1. Характеристики стратегий конструирования
| Стратегия конструирования | В начале процесса определены все требования? | Множество циклов конструирования? | Промежуточное ПО распространяется? |
| Однократный проход Инкрементная (запланированное улучшение продукта) Эволюционная | Да Да Нет | Нет Да Да | Нет Может быть Да |
Инкрементная модель является классическим примером инкрементной стратегии конструирования (рис. 5). Она объединяет элементы последовательной водопадной модели с итерационной философией макетирования.
Каждая линейная последовательность здесь вырабатывает поставляемый инкремент программного обеспечения. Например, программное огбеспечение для обработки слов в 1-м инкременте реализует функции базовой обработки файлов, функции редактирования и документирования; во 2-м инкременте — более сложные возможности редактирования и документирования; в 3-м инкременте — проверку орфографии и грамматики; в 4-м инкременте — возможности компоновки страницы.
|
|
|
Первый инкремент приводит к получению базового продукта, реализующего базовые требования (правда, многие вспомогательные требования остаются нереализованными). План следующего инкремента предусматривает модификацию базового продукта, обеспечивающую дополнительные характеристики и функциональность. По своей природе инкрементный процесс итеративен, но, в отличие от макетирования, инкрементная модель обеспечивает на каждом инкременте работающий продукт.
Рис. 5. Инкрементная модель
Модель быстрой разработки приложений (Rapid Application Development) — второй пример применения инкрементной стратегии конструирования (рис. 6).
Модель RAD обеспечивает экстремально короткий цикл разработки. Модель RAD — высокоскоростная адаптация линейной последовательной модели, в которой быстрая разработка достигается за счет использования компонентно-ориентированного конструирования. Если требования полностью определены, а проектная область ограничена, RAD-процесс позволяет группе создать полностью функциональную систему за очень короткое время (60-90 дней). RAD-подход ориентирован на разработку информационных систем и выделяет следующие этапы:
q бизнес-моделирование. Моделируется информационный поток между бизнес-функциями. Ищется ответ на следующие вопросы: Какая информация руководит бизнес-процессом? Какая генерируется информация? Кто генерирует ее? Где информация применяется? Кто обрабатывает ее?
q моделирование данных. Информационный поток, определенный на этапе бизнес-моделирования, отображается в набор объектов данных, которые требуются для поддержки бизнеса. Идентифицируются характеристики (свойства, атрибуты) каждого объекта, определяются отношения между объектами;
|
|
|
q моделирование обработки. Определяются преобразования объектов данных, обеспечивающие реализацию бизнес-функций. Создаются описания обработки для добавления, модификации, удаления или нахождения (исправления) объектов данных;
q генерация приложения. Предполагается использование методов, ориентированных на языки программирования 4-го поколения. Вместо создания ПО с помощью языков программирования 3-го поколения, RAD-процесс работает с повторно используемыми программными компонентами или создает повторно используемые компоненты. Для обеспечения конструирования используются утилиты автоматизации;
q тестирование и объединение. Поскольку применяются повторно используемые компоненты, многие программные элементы уже протестированы. Это уменьшает время тестирования (хотя все новые элементы должны быть протестированы).
Рис. 6. Модель быстрой разработки приложений
Применение RAD возможно в том случае, когда каждая главная функция может быть завершена за 3 месяца. Каждая главная функция адресуется отдельной группе разработчиков, а затем интегрируется в целую систему.
Применение RAD имеет и свои недостатки, и ограничения.
1. Для больших проектов в RAD требуются существенные людские ресурсы (необходимо создать достаточное количество групп).
2. Модель RAD применима только для таких приложений, которые могут декомпозироваться на отдельные модули и в которых производительность не является критической величиной.
3. Модель RAD не применима в условиях высоких технических рисков (то есть при использовании новой технологии).
Стадия формирования требований к ПО. Она является одной из важнейших, поскольку определяет успех всего проекта. Данная стадия включает следующие этапы:
• планирование работ, предваряющее работы над проектом. Основными задачами этапа являются: определение целей разработки, предварительная экономическая оценка проекта, построение плана-графика выполнения работ, создание и обучение совместной рабочей группы;
• проведение обследования деятельности автоматизируемого объекта (организации), в рамках которого осуществляются: предварительное выявление требований к будущей системе; определение структуры организации; определение перечня целевых функций организации; анализ распределения функций по подразделениям и сотрудникам; выявление функциональных взаимодействий между подразделениями, информационных потоков внутри подразделений и между ними, внешних по отношению к организации объектов и внешних информационных взаимодействий; анализ существующих средств автоматизации деятельности организации;
|
|
|
• построение моделей деятельности организации, предусматривающее обработку материалов обследования и построение двух видов моделей:
Ø модели "AS-1S" ("как есть"), отражающей существующее на момент обследования положение дел в организации и позволяющей понять, каким образом функционирует данная организация, а также выявить узкие места и сформулировать предложения по улучшению ситуации;
Ø модели "ТО-ВЕ" ("как должно быть"), отражающей представление о новых технологиях работы организации.
Каждая из моделей включает в себя полную функциональную и информационную модель деятельности организации, а также, в случае необходимости, модель, описывающую динамику поведения организации. Переход от модели "AS-IS" к модели "ТО-ВЕ" может выполняться двумя способами:
1) совершенствованием существующих технологий на основе оценки их эффективности;
2) радикальным изменением технологий и перепроектированием бизнес-процессов (реинжиниринг бизнес-процессов).
Построенные модели имеют самостоятельное практическое значение. Например, модель "AS-IS" позволяет выявлять узкие места в существующих технологиях и предлагать рекомендации по решению проблем независимо от того, предполагается на данном этапе дальнейшая разработка ЭИС или нет. Кроме того, модель облегчает обучение сотрудников конкретным направлениям деятельности организации за счет использования наглядных диаграмм.
Этап проектирования предназначен для выработки и детализации модели разрабатываемого программного продукта. Такая модель определяет структуру программного обеспечения, организацию модулей, интерфейсов и данных, описание которых необходимо для последующего этапа реализации (программирования на языке высокого уровня). На этапе проектирования большая программа должна быть декомпозирована на более мелкие и простые части. В следующей главе мы рассмотрим основные подходы к разработке программного обеспечения.
|
|
|
