Введение
Предмет является специальным, базируется на основе таких дисциплин, как основы алгоритмизации и БД. Изучение данного предмета позволит вам грамотно организовывать процесс создания ПО, составлять программную документацию.
Технология конструирования ПО – система инженерных принципов для создания экономичного ПО, которое надежно и эффективно работает в реальных компьютерах.
Различают методы, средства и процедуры ТКПО:
Методы обеспечивают решение следующих задач:
Планирование и оценка проекта
Анализ системных и программных требований
Проектирование алгоритмов, структур данных и программных структур
Кодирование
Тестирование
Сопровождение.
Средства (утилиты) ТКПО обеспечивают автоматическую поддержку методов. В целях совместного применения утилиты могут объединяться в системы автоматизированного конструирования ПО. Такие системы принято называть CASE-системами (Computer Aided Software Engineering).
Процесс конструирования программного обеспечения состоит из последовательности шагов, использующих методы, утилиты и процедуры. Эти последовательности шагов часто называют парадигмами ТКПО.
|
|
Применение парадигм ТКПО гарантирует систематический, упорядоченный подход к промышленной разработке, использованию и сопровождению ПО. Фактически, парадигмы вносят в процесс создания ПО организующее инженерное начало, необходимость которого трудно переоценить.
Тема 1.1. Структура жизненного цикла программы.
Комплексы программ создаются, эксплуатируются и развиваются во времени. Жизненный цикл программных средств включает в себя все этапы развития: от возникновения потребности в программе, определением целевого назначения, до полного прекращения использования этого программного ср-ва, вследствии его морального старения или потере необ-ти решения соответствующих задач.
По длительности жизненного цикла, ПС можно разделить на два класса: с малым и большим временем жизни. Этим классам программ соответствует гибкий (мягкий) подход к их созданию и использованию и жесткий промышленный подход регламентированного проектирования и эксплуатации промышленных изделий.
В научных организациях и вузах преобладают разработки программ 1 класса. А в проектных и промышленных организациях – второго.
Программы с малой длительностью эксплуатации создаются в основном для решения научных и инженерных задач, для получения конкретных рез-тов выч-ний. Такие программы относительно не велики от 1 до 10000 команд. Разрабатываются как правило одним специалистом или маленькой группой, не предназначены для тиражирования и передачи для последующего использования в другие коллективы. ЖЦ таких программ состоит из длительного интервала системного анализа и форматизации проблемы, значительного этапа проектирования программ и относительно небольшого времени эксплуатации и получения рез-тов.
|
|
Требования предъявляемые к функциональным и конструктивным хар-кам, как правило не формализуются, отсутствуют оформленные испытания программ и показатели их качества контролируются только разработчиками, в соответствии с неформальными представлениями.
Сопровождение и модификация таких программ не нужны и их ЖЦ завершается после получения рез-тов вычислений. Основные затраты в ЖЦ таких программ приходятся на этапы системного анализа и проектирования, к-ые продолжаются от месяца до одного или двух лет. В рез-те ЖЦ редко превышает три года, т.е. основное время идет на анализ и проектирование.
Программы с большой длительностью эксплуатации создаются для регулярной обработки инф-ции и управления в процессе функционирования сложных вычислительных систем. Размеры программных средств могут изменяться в широких пределах (от 1 до бесконечности команд), однако все они обладают свойством познаваемости и возможности модификации в процессе использования различными специалистами. Программы такого класса допускают тиражирование. Они сопровождаются документацией как промышленные изделия и представляют собой отчуждаемый программный продукт.
Проектированием и эксплуатацией программного средства могут заниматься большие коллективы специалистов, для чего необ-ма формализация требуемых технических хар-к комплекса программ и их компонент. А также формализированные испытания и определение достигнутых показателей качества программных средств.
ЖЦ таких программных средств составляет 10-20 лет, из которых 70-90% приходиться на эксплуатацию и сопровождение. Вследствии массового тиражирования и длительного сопровождения совокупные затраты в процессе эксплуатации и сопровождения могут значительно превышать затраты на системный анализ и проектирование.
ЖЦ рассматриваемых программ включает в себя следующие основные этапы:
|
1. Системный анализ в ходе, которого определяются потребности в ПС, его назначение, основные функциональные хар-ки, оцениваются затраты и возможная эффективность применения такого комплекса программ.
2. Проектирование ПС включает в себя разработку структуры комплекса и его компонент, программирование модулей и ряд этапов отладки, а также испытание и внедрение для регулярной эксплуатации, созданной версии комплекса программ.
3. Эксплуатация ПС заключается в исполнении, функционировании программы на ПК, для обработки информации, получения результатов, являющихся целью создания программных средств, а также в обеспечении достоверности и надежности выдаваемых данных.
4. Сопровождение ПС состоит в эксплуатационном обслуживании, развитии функциональных возможностей и повышения эксплуатационных характеристик ПС, тиражировании, переносе комплекса программ на различные типы вычислительных средств.
Среди перечисленных этапов, наиболее специфическим, трудно формализуемым и тесно связанным с функциональным назначением ПС является этап системного анализа. На этом этапе формируется назначение и основные показатели качества создаваемых программ. Решаемые задачи практически полностью определяются предметной областью системного анализа, поэтому на данном этапе трудно обобщать технологические процессы и критерии качества при создании различных типов программ.
Этапы проектирования и эксплуатации и сопровождения различаются целями, задачами, методами и средствами.
|
|
Следует обратить внимание на особенность взаимодействия этапа сопровождения с этапами эксплуатации и проектирования, в которой сопровождение играет роль необходимой обратной связи от этапа эксплуатации.
Как и любая схема действий классический жизненный цикл имеет достоинства и недостатки.
Достоинства классического ЖЦ: дает план и временной график по всем этапам проекта, упорядочивает ход конструирования.
Недостатки классического ЖЦ:
1. реальные проекты часто требуют отклонения от стандартной последовательности шагов
2. цикл основан на точной формулировке исходных требований к ПС (реально в начале проекта требования заказчика определены частично)
3. результаты проекта доступны заказчику только в конце работы.
Макетирование. Достаточно часто заказчик не может сформулировать подробные требования по вводу, обработке или выводу данных для будущего программного продукта. С другой стороны, разработчик может сомневаться в приспосабливаемости продукта под операционную систему, форме диалога с пользователем или в эффективности реализуемого алгоритма. В этих случаях целесообразно использовать макетирование.
Основная цель макетирования — снять неопределенности в требованиях заказчика.
Макетирование (прототипирование) — это процесс создания модели требуемого программного продукта.
Модель может принимать одну из трех форм:
1) бумажный макет или макет на основе ПК (изображает или рисует человеко-машинный диалог);
2) работающий макет (выполняет некоторую часть требуемых функций)
3) существующая программа (характеристики которой затем должны быть улучшены).
Последовательность действий при макетировании:
Макетирование начинается со сбора и уточнения требований к создаваемому ПО. Разработчик и заказчик встречаются и определяют все цели ПО, устанавливают, какие требования известны, а какие предстоит доопределить.
Затем выполняется быстрое проектирование. В нем внимание сосредоточивается на тех характеристиках ПО, которые должны быть видимы пользователю.
|
|
Быстрое проектирование приводит к построению макета.
Макет оценивается заказчиком и используется для уточнения требований к ПО.
Итерации повторяются до тех пор, пока макет не выявит все требования заказчика и, тем самым, не даст возможность разработчику понять, что должно быть сделано.
Достоинство макетирования: обеспечивает определение полных требований к ПО. Недостатки макетирования:
1. заказчик может принять макет за продукт;
2. разработчик может принять макет за продукт.
Поясним суть недостатков. Когда заказчик видит работающую версию ПО, он перестает сознавать, что детали макета скреплены «жевательной резинкой и проволокой»; он забывает, что в погоне за работающим вариантом оставлены нерешенными вопросы качества и удобства сопровождения ПО. Когда заказчику говорят, что продукт должен быть перестроен, он начинает возмущаться и требовать, чтобы макет «в три приема» был превращен в рабочий продукт. Очень часто это отрицательно сказывается на управлении разработкой ПО.
С другой стороны, для быстрого получения работающего макета разработчик часто идет на определенные компромиссы. Могут использоваться не самые подходящие язык программирования и ОС. Для простой демонстрации возможностей может применяться неэффективный алгоритм. Спустя время разработчик забывает о причинах, по которым эти средства не подходят. В результате далеко не идеальный выбранный вариант интегрируется в систему.
Стратегии конструирования ПО.
Существуют 3 стратегии конструирования ПО:
однократный проход (водопадная стратегия) — линейная последовательность этапов конструирования;
инкрементная стратегия. В начале процесса определяются все пользовательские и системные требования, оставшаяся часть конструирования выполняется в виде последовательности версий. Первая версия реализует часть запланированных возможностей, следующая версия реализует дополнительные возможности и т. д., пока не будет получена полная система;
эволюционная стратегия. Система также строится в виде последовательности версий, но в начале процесса определены не все требования. Требования уточняются в результате разработки версий.
Инкрементная модель является классическим примером инкрементной стратегии конструирования. Она объединяет элементы последовательной водопадной модели с итерационным макетированием. Каждая линейная последовательность вырабатывает поставляемый инкремент ПО. Первый инкремент приводит к получению базового продукта, реализующего базовые требования (многие вспомогательные требования остаются нереализованными). План следующего инкремента предусматривает модификацию базового продукта, обеспечивающую дополнительные характеристики и функциональность. По своей природе инкрементный процесс итеративен, но в отличие от макетирования, инкрементная модель обеспечивает на каждом инкременте работающий продукт.
Быстрая разработка приложений.
Модель быстрой разработки приложений (Rapid Application Development) – второй пример применения инкрементной стратегии конструирования.
RAD-модель обеспечивает экстремально короткий цикл разработки. RAD-высокоскоростная адаптация линейной последовательной модели, в которой быстрая разработка достигается за счет использования компонентно-ориентированного конструирования. Если требования полностью определены, а проектная область ограничена, Rad-процесс позволяет группе создать полностью функциональную систему за очень короткое время (60-90 дней). RAD-подход ориентирован на разработку информационных систем и выделяет следующие этапы:
бизнес-моделирование. Моделируется информационный поток между бизнес-функциями. Ищется ответ на следующие вопросы: Какая информация руководит бизнес-процессом? Какая генерируется инф-ция? Кто генерирует ее? Где инф-ция применяется? Кто ее обрабатывается?
моделирование данных. Информационный поток, определенный на этапе бизнес-моделирования, отображается в набор объектов данных, которые требуются для поддержки бизнеса. Идентифицируются характеристики (свойства, атрибуты) каждого объекта, определяются отношения между объектами.
моделирование обработки. Определяются преобразования объектов данных, обеспечивающие реализацию бизнес-функций. Создаются описании обработки для добавления, модификации, удаления или нахождений (исправлений) объектом данных;
генерация приложения. Предполагает использование методов, ориентированных на языки программирования 4-го поколения. Вместо создания ПО с помощью языков программирования 3-го поколения, RAD-процесс работает с повторно используемыми программными компонентами или создает повторно используемые компоненты. Для обеспечения конструирования используются утилиты автоматизации.
тестирование и объединение. Поскольку применяются повторно используемые компоненты, многие программные элементы уже протестированы. Это уменьшает время тестирования (хотя все новые элементы должны быть протестированы).
Применения RAD возможно в том случае, когда каждая главная функция может быть завершена за 3 месяца. Каждая главная функция адресуется отдельной группе разработчиков, а затем интегрируется в целую систему.
Применения RAD имеет и свои недостатки и ограничения.
1. для больших проектов в RAD требуются существенные людские ресурсы (необходимо создать достаточное количество групп);
2. RAD применима только для таких приложений, которые могут декомпозироваться на отдельные модули и в которых производительность не является критической величиной;
3. RAD не применима в условиях высоких технических рисков (т.е. при использовании новой технологии).
Спиральная модель – классический пример применения эволюционной стратегии конструирования.
Спиральная модель базируется на лучших свойствах классического жизненного цикла и макетирования, к которым добавляется новый элемент – анализ риска, отсутствующий в этих парадигмах.
Спиральная модель: 1- начальный сбор требований и планирование проекта, 2- та же работа, на основе рекомендаций заказчика, 3- анализ риска на основе начальных требований, 4-анализ риска на основе реакции заказчика, 5- переход к комплексной системе, 6- начальный макет системы, 7-следующий уровень макета, 8- сконструированная система, 9-оценование заказчиком.
Как показано на рисунке, модель определяет четыре действия, представляемые четырьмя квадрантами спирали:
1. планирование – определение целей, вариантов и ограничений.
2. анализ риска – анализ вариантов и распознавание/выбор риска
3. конструирование – разработка продукта следующего уровня
4. оценивание – оценка заказчиком текущих результатов конструирования.
Интегрирующий аспект спиральной модели очевиден при учете радиального измерения спирали. С каждой итерацией по спирали (продвижением от центра к периферии) строятся все более полные версии ПО.
В первом витке спирали определяются начальные цели, варианты и ограничения, распознается и анализируется риск. Если анализ риска показывает неопределенность требований, на помощь разработчику и заказчику приходит макетирование (используемое в квадранте конструирования). Для дальнейшего определения проблемных и уточненных требований может быть использовано моделирование. Заказчик оценивает инженерную (конструкторскую) работу и вносит предложения по модификации. Следующая фаза планирования и анализа риска базируется на предложениях заказчика. В каждом цикле по спирали результаты анализа риска формируются в виде «продолжать, не продолжать». Если риск слишком велик, проект может быть остановлен.
В большинстве случаев движение по спирали продолжается, с каждым шагом продвигая разработчиков к более общей модели системы. В каждом цикле по спирали требуется конструирование (нижний правый квадрант), которое может быть реализовано классическим ЖЦ или макетированием. Заметим, что количество действий по разработке (происходящих в правом нижнем квадранте) возрастает по иерее продвижения от центра спирали.
Достоинства спиральной модели:
1. наиболее реально (в виде эволюции) отображает разработку ПО
2. позволяет явно учитывать риск на каждом витке эволюции разработки
3. включает шаг системного подхода в итерационную структуру разработки
4. использует моделирование для уменьшения риска и совершенствования программного изделия
Недостатки спиральной модели:
1. новизна (отсутствует достаточная статистика эффективности модели)
2. повышенные требования к заказчику
3. трудности контроля и управления временем разработки.