Глава 2. Жизненный цикл. Стратегии и модели конструирования ПО

1. Технология конструирования программного обеспечения– определение, парадигмы

Технология конструирования программного обеспечения (ТКПО) – система инженерных принципов для создания экономичного ПО, которое надежно и эффективно работает в реальных компьютерах. Различаются методы, средства и процедуры ТКПО.

Методы обеспечивают решение следующих задач:

· планирование и оценка проекта;

· анализ системных и программных требований;

· проектирование алгоритмов, структур данных и программных структур;

· кодирование;

· тестирование;

· сопровождение.

Средства (утилиты) ТКПО обеспечивают автоматизированную или автоматическую поддержку методов. В целях совместного применения утилиты могут объединяться в системы автоматизированного конструирования ПО. Такие системы принято называть CASE-системами. Аббревиатура CASE расшифровывается как Computer Aided Software Engineering (программная инженерия с компьютерной поддержкой).

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

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

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

• классический жизненный цикл;
• макетирование (прототипирование).

Классический жизненный цикл

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

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

Системный анализ задает роль каждого элемента в компьютерной системе, взаимодействие элементов друг с другом. Поскольку ПО является лишь частью большой системы, то анализ начинается с определения требований ко всем системным элементам и назначения подмножества этих требований программному «элементу». Необходимость системного подхода явно проявляется, когда формируется интерфейс ПО с другими элементами (аппаратурой, людьми, БД). НА этом же этапе начинается решение задачи планирование проекта ПО. В ходе планирования проекта определяются объем проектных работ и их риск, необходимые трудозатраты, формируются рабочие задачи и план-граф работ.

Анализ требований относится к программному элементу – программному обеспечению. Уточняются и детализируются его функции, характеристики и интерфейс.

Все определения документируются в спецификации анализа. Здесь же завершается решение задачи планирования проекта.

Рис. 1. Классический жизненный цикл разработки ПО

Проектирование состоит в создании представлений:

• архитектуры ПО;
• модульности структуры ПО;
• алгоритмической структуры ПО;
• структуры данных;
• входного и выходного интерфейса (входных и выходных форм данных).

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

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

Тестирование – выполнение программы для выявления дефектов в функциях, логике и форме реализации программного продукта.

Сопровождение - это внесение изменений в эксплуатируемое ПО. Цели изменений:

• исправление ошибок;
• адаптация к изменениям внешней для ПО среды;
• усовершенствование ПО по требованиям заказчика.

Сопровождение По состоит в повторном применении каждого из предшествующих шагов (этапов) жизненного цикла к существующей программе, но не в разработке новой программы.

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

Макетирование

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

Основная цель макетирования – снять неопределенности в требованиях заказчика. Макетирование (прототипирование) – это процесс создания модели требуемого программного продукта. Модель может принимать одну из трех форм: бумажный макет или макет на основе ПК (изображает или рисует человеко-машинный диалог); работающий макет (выполняет некоторую часть требуемых функций); существующая программа ( характеристики которой затем должны быть улучшены).

Рис.2. Макетирование

Как показано на рис.2, макетирование основывается на многократном цикле повторений, в которых участвуют заказчики и разработчики. Последовательность действий при макетировании представлена на рис.3. Макетирование начинается со сбора и уточнения требований к создаваемому ПО. Разработчик и заказчик встречаются и определяют все цели ПО, устанавливают, какие требования известны, а какие предстоит доопределить. Затем выполняется быстрое проектирование. В нем внимание сосредоточивается на тех характеристиках ПО, которые должны быть видимы пользователю. Быстрое проектирование приводит к построению макета. Макет оценивается заказчиком и используется для уточнения требований к ПО. Итерации повторяются до тех пор, пока макет не выявит все требования заказчика и, тем самым, не даст возможность разработчику понять, что должно быть сделано.

Достоинство макетирования: обеспечивает определение полных требований к ПО.

Недостатки макетирования:

• заказчик может принять макет за продукт;
• разработчик может принять макет за продукт.

Да

Нет

Рис.3. Последовательность действий при макетировании

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

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