Тема 1.1. Структура жизненного цикла программы

Введение

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

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

Различают методы, средства и процедуры ТКПО:

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

­ Планирование и оценка проекта

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

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

­ Кодирование

­ Тестирование

­ Сопровождение.

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

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

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

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

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

В научных организациях и вузах преобладают разработки программ 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. трудности контроля и управления временем разработки.

Дата добавления: 2014-01-07