Технология конструирования программного обеспечения (ТКПО) — система инженерных принципов для создания экономичного ПО, которое надежно и эффективно работает в реальных компьютерах [64], [69], [71].
Различают методы, средства и процедуры ТКПО.
Методы обеспечивают решение следующих задач:
- планирование и оценка проекта;
- анализ системных и программных требований;
- проектирование алгоритмов, структур данных и программных структур;
- кодирование;
- тестирование;
- сопровождение.
Средства (утилиты) ТКПО обеспечивают автоматизированную или автоматическую поддержку методов. В целях совместного применения утилиты могут объединяться в системы автоматизированного конструирования ПО. Такие системы принято называть CASE-системами. Аббревиатура CASE расшифровывается как Computer Aided Software Engineering (программная инженерия с компьютерной поддержкой).
Процедуры являются «клеем», который соединяет методы и утилиты так, что они обеспечивают непрерывную технологическую цепочку разработки. Процедуры определяют:
- порядок применения методов и утилит;
- формирование отчетов, форм по соответствующим требованиям;
- контроль, который помогает обеспечивать качество и координировать изменения;
- формирование «вех», по которым руководители оценивают прогресс.
Процесс конструирования программного обеспечения состоит из последовательности шагов, использующих методы, утилиты и процедуры. Эти последовательности шагов часто называют парадигмами ТКПО.
Применение парадигм ТКПО гарантирует систематический, упорядоченный подход к промышленной разработке, использованию и сопровождению ПО. Фактически, парадигмы вносят в процесс создания ПО организующее инженерное начало, необходимость которого трудно переоценить.
Рассмотрим наиболее популярные парадигмы ТКПО.
Старейшей парадигмой процесса разработки ПО является классический жизненный цикл (автор Уинстон Ройс, 1970) [65].
Очень часто классический жизненный цикл называют каскадной или водопадной моделью, подчеркивая, что разработка рассматривается как последовательность этапов, причем переход на следующий, иерархически нижний этап происходит только после полного завершения работ на текущем этапе (рис. 1.1).
Охарактеризуем содержание основных этапов.
Подразумевается, что разработка начинается на системном уровне и проходит через анализ, проектирование, кодирование, тестирование и сопровождение. При этом моделируются действия стандартного инженерного цикла.
Методы стандартизации
... основные методы стандартизации. 1. Наиболее применяемые общенаучные методы стандартизации Деятельность по стандартизации сложна и многогранна. Достижение высокого качества стандартизации предполагает использование ряда методов. Методы стандартизации ... человеком, а также для компьютерной обработки закодированной информации; обеспечивать возможность автоматического контроля ошибок при вводе в ...
Системный анализ, Анализ требований
Рис. 1.1.
Проектирование состоит в создании представлений:
- архитектуры ПО;
- модульной структуры ПО;
- алгоритмической структуры ПО;
- структуры данных;
- входного и выходного интерфейса (входных и выходных форм данных).
спецификации анализа,
Кодирование, Тестирование -, Сопровождение —
- исправление ошибок;
- адаптация к изменениям внешней для ПО среды;
- усовершенствование ПО по требованиям заказчика.
Сопровождение ПО состоит в повторном применении каждого из предшествующих шагов (этапов) жизненного цикла к существующей программе, но не в разработке новой программы. Как и любая инженерная схема, классический жизненный цикл имеет достоинства и недостатки.
Достоинства классического жизненного цикла:, Недостатки классического жизненного цикла:
1. реальные проекты часто требуют отклонения от стандартной последовательности шагов;
2. цикл основан на точной формулировке исходных требований к ПО (реально в начале проекта требования заказчика определены лишь частично);
3. результаты проекта доступны заказчику только в конце работы.
Макетирование
Достаточно часто заказчик не может сформулировать подробные требования по вводу, обработке или выводу данных для будущего программного продукта. С другой стороны, разработчик может сомневаться в приспосабливаемости продукта под операционную систему, форме диалога с пользователем или в эффективности реализуемого алгоритма. В этих случаях целесообразно использовать макетирование.
Основная цель макетирования — снять неопределенности в требованиях заказчика.
Макетирование (прототипирование) — это процесс создания модели требуемого программного продукта.
Модель может принимать одну из трех форм:
1. бумажный макет или макет на основе ПК (изображает или рисует человеко-машинный диалог);
2. работающий макет (выполняет некоторую часть требуемых функций);
3. существующая программа (характеристики которой затем должны быть улучшены).
Как показано на рис. 1.2, макетирование основывается на многократном повторении итераций, в которых участвуют заказчик и разработчик.
Рис. 1.2. Макетирование
Последовательность действий при макетировании представлена на рис. 1.3.
Макетирование начинается со сбора и уточнения требований к создаваемому ПО. Разработчик и заказчик встречаются и определяют все цели ПО, устанавливают, какие требования известны, а какие предстоит доопределить.
Затем выполняется быстрое проектирование. В нем внимание сосредоточивается на тех характеристиках ПО, которые должны быть видимы пользователю.
Быстрое проектирование приводит к построению макета.
Макет оценивается заказчиком и используется для уточнения требований к ПО.
Итерации повторяются до тех пор, пока макет не выявит все требования заказчика и, тем самым, не даст возможность разработчику понять, что должно быть сделано.
Достоинство макетирования: обеспечивает определение полных требований к ПО.
Недостатки макетирования:
- заказчик может принять макет за продукт;
- разработчик может принять макет за продукт.
Поясним суть недостатков. Когда заказчик видит работающую версию ПО, он перестает сознавать, что детали макета скреплены «жевательной резинкой и проволокой»; он забывает, что в погоне за работающим вариантом оставлены нерешенными вопросы качества и удобства сопровождения ПО. Когда заказчику говорят, что продукт должен быть перестроен, он начинает возмущаться и требовать, чтобы макет «в три приема» был превращен в рабочий продукт. Очень часто это отрицательно сказывается на управлении разработкой ПО.
Рис. 1.3. Последовательность действий при макетировании
С другой стороны, для быстрого получения работающего макета разработчик часто идет на определенные компромиссы. Могут использоваться не самые подходящие язык программирования или операционная система. Для простой демонстрации возможностей может применяться неэффективный алгоритм. Спустя некоторое время разработчик забывает о причинах, по которым эти средства не подходят. В результате далеко не идеальный выбранный вариант интегрируется в систему.
Очевидно, что преодоление этих недостатков требует борьбы с житейским соблазном — принять желаемое за действительное.
Стратегии конструирования ПО
Существуют 3 стратегии конструирования ПО:
однократный проход
инкрементная стратегия.
эволюционная стратегия.
Характеристики стратегий конструирования ПО в соответствии с требованиями стандарта IEEE/EIA 12207.2 приведены в табл. 1.1.
Таблица 1.1
| Стратегия конструирования | В начале процесса определены все требования? | Множество циклов конструирования? | Промежуточное ПО распространяется? |
| Однократный проход
Инкрементная (запланированное улучшение продукта) Эволюционная |
Да Да |
Нет Да |
Нет Может быть |
Инкрементная модель
Инкрементная модель является классическим примером инкрементной стратегии конструирования (рис. 1.4).
Она объединяет элементы последовательной водопадной модели с итерационной философией макетирования.
Каждая линейная последовательность здесь вырабатывает поставляемый инкремент ПО. Например, ПО для обработки слов в 1-м инкременте реализует функции базовой обработки файлов, функции редактирования и документирования; во 2-м инкременте — более сложные возможности редактирования и документирования; в 3-м инкременте — проверку орфографии и грамматики; в 4-м инкременте — возможности компоновки страницы.
Первый инкремент приводит к получению базового продукта, реализующего базовые требования (правда, многие вспомогательные требования остаются нереализованными).
План следующего инкремента предусматривает модификацию базового продукта, обеспечивающую дополнительные характеристики и функциональность.
По своей природе инкрементный процесс итеративен, но, в отличие от макетирования, инкрементная модель обеспечивает на каждом инкременте работающий продукт.
Рис. 1.4. Инкрементная модель
Забегая вперед, отметим, что современная реализация инкрементного подхода — экстремальное программирование ХР (Кент Бек, 1999) [10].
Оно ориентировано на очень малые приращения функциональности.
Заключение
Модель быстрой разработки приложений (Rapid Application Development) — второй пример применения инкрементной стратегии конструирования (рис. 1.5).
RAD-модель обеспечивает экстремально короткий цикл разработки. RAD — высокоскоростная адаптация линейной последовательной модели, в которой быстрая разработка достигается за счет использования компонентно-ориентированного конструирования. Если требования полностью определены, а проектная область ограничена, RAD-процесс позволяет группе создать полностью функциональную систему за очень короткое время (60-90 дней).
Список литературы
[Электронный ресурс]//URL: https://drprom.ru/referat/konstruirovanie-programmnogo-obespecheniya/
1. Боэм Б.У. Инженерное проектирование программного обеспечения. М.: Радио и связь, 1985. 511 с.
2. Липаев В.В. Отладка сложных программ: Методы, средства, технология. М.: Энергоатомиздат, 1993. 384 с.
3. Майерс Г. Искусство тестирования программ. М.: Финансы и статистика, 1982. 176с.
4. Орлов С.А. Принципы объектно-ориентированного и параллельного программирования на языке Ada 95. Рига: TSI, 2001. 327 с.
5. Чеппел Д. Технологии ActiveX и OLE. M.: Русская редакция, 1997. 320 с.
6. Abreu, F.В., Esteves, R., Goulao, M. The Design of Eiffel Programs: Quantitative Evaluation Using the MOOD metrics. Proceedings of the TOOLS’96. Santa Barbara, California 20 pp. July 1996.
