ЖИЗНЕННЫЙ ЦИКЛ ПРОГРАММНОЙ РАЗРАБОТКИ И ЕГО МОДЕЛИ.

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

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

Жизненный ЦИКЛ - совокупность взаимосвязанных процессов создания и последовательного изменения состояния продукции от формирования к ней исходных требований до окончания ее экс­плуатации или потребления.

Существует несколько моделей жизненного цикла (ЖЦ), ка­ждая из которых определяет различную методологию создания систем, тем не менее все без исключения модели ЖЦ включают в себя пять этапов и связей между ними с детальным описанием действий, моделей и результатов каждого этапа. Приведем на­звания и краткое содержание каждого этапа в соответствии с ГОСТ 19.102-77.

1. Техническое задание:

• постановка задачи;

• выбор критериев эффективности;

• проведение предварительных научно-исследовательских работ (НИР);

• разработка ТЗ.

2. Эскизный проект:

• структура входных и выходных данных;

• уточнение методов решения;

• общий алгоритм;

• разработка документации эскизного проекта.

3. Технический проект:

• уточнение структуры входных и выходных данных;

• разработка алгоритмов;

• формы данных;

• семантика и синтаксис языка;

• структура программы;

• конфигурация технических средств;

• план работ.

4. Рабочий проект:

• программирование и отладка;

• разработка документов;

• подготовка и проведение испытаний;

• корректировка программы и документов по итогам ис­пытаний.

5.Внедрение:

• передача программы и документов для сопровождения;

• оформление акта;

• передача в Фонд алгоритмов и программ (ФАП).

 

Программы с малой длительностью жизненного цикла создают­ся для разового решения научных и иных задач. Их жизненный цикл - от нескольких дней до нескольких месяцев. Ранее такие программы не имели удобного интерфейса, так как затраты на его разработку еще недавно в несколько раз превосходили затраты на разработку вычислительной части. Жизненный цикл программных изделий показан на рис. 1.1.

 

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

 

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

 

Исторически в ходе развития теории проектирования про­граммного обеспечения и по мере его усложнения утвердились четыре основные модели ЖЦ. .

Первой по времени появления и самой распространенной явилась каскадная модель (рис. 1.2).

 

Рис. 1.2. Каскадная модель жизненного цикла ПО

 

Каскадная модель характеризуется следующими основными особенностями:

· последовательным выполнением входящих в ее состав эта­пов;

· окончанием каждого предыдущего этапа до начала после­дующего;

· отсутствием временного перекрытия этапов (последующий этап не начнется, пока не завершится предыдущий);

· отсутствием (или определенным ограничением) возврата к предыдущим этапам;

· наличием результата только в конце разработки.

Выявление и устранение ошибок в каскадной модели произ­водится только на стадии тестирования, которая может растя­нуться во времени или вообще никогда не завершиться.

Следующей стадией развития теории проектирования ПО стала итерационная модельЖЦ, или так называемая поэтапная модель с промежуточным контролем (рис. 1.3). Основной ее осо­бенностью является наличие обратных связей между этапами, вследствие этого появляется возможность проведения проверок 11 корректировок проектируемой ИС на каждой стадии разработ­ки. В результате трудоемкость отладки по сравнению с каскад­ной моделью существенно снижается. Итерационность модели проявляется в обработке ошибок, выявленных промежуточным контролем. Если на каком-либо этапе в' ходе промежуточной проверки обнаружена ошибка, допущенная на более ранней ста­дии разработки, необходимо повторить весь цикл работ этой стадии. При этом анализируются причины ошибки и корректи­руются в случае необходимости исходные данные этапа или его содержание (последовательность действий).

 

Рис. 1.3. Итерационная модель жизненного цикла ПО

 

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

Третья модель ЖЦ ПО - спиральная (spiral) модель (рис. 1.4) - поддерживает итерации поэтапной модели, но осо­бое внимание уделяется начальным этапам проектирования: ана­лизу требований, проектированию спецификаций, предваритель­ному проектированию и детальному проектированию. Каждый виток спирали соответствует поэтапной модели создания фраг­мента или версии ПО, уточняются цели и требования к про­граммному обеспечению, оценивается качество разработанного фрагмента или версии и планируются работы следующей стадии разработки (витка). Таким образом, углубляются и конкретизи­руются все детали проектируемого ПО, в результате получается продукт, который удовлетворяет всем требованиям заказчика.

 
 

 

 


Ralioпal Objeclory Process - модель жизненного цикла (методология объектно-ориентированного программирования)

 

Известно, что объектно-ориентированное проектирование программного обеспечения стало результатом появления объект­но-ориентированного программирования (ООП), т. е. применение новой методологии, как всегда, началось с этапа кодирова­ния. Ранние стадии описания предметной области и разработки архитектуры системы не поддерживались, первые варианты ис­пользования объектно-ориентированной методологии в большей степени являлись чистым повторением принципов ООП. Такие вопросы, как декомпозиция предметной области, спецификация требований, интерфейс пользователя, не рассматривались, однако успехи объектно-ориентированного программирования заста­вили распространить новую технологию на весь жизненный цикл ПО. В результате все преимущества подхода применяются не только в процессе кодирования, но и на более ранних этапах.

Жизненный цикл UML (Rational Objectory Process)

 

Фирма Rational Software, разработавшая язык UML ( Unified Modeling Language - унифицированный язык моделиро­вания), предло­жила также и свою модель ЖЦ, которая называется Rational Objectory Process (ROP). Означенная технология прямого пере­вода не имеет, так как rational в данном случае употребляется в значении «рациональный» и как название фирмы одновременно, во-вторых, слова objectory в английском языке не существует, его лингвообразование аналогично слову repository (накопитель).

Перечислим основные свойства RОР-технологии.

Rational Objectory Process - итеративный процесс, в течение которого происходит последовательное уточнение результатов; направлен именно на создание моделей, анне на разработку каких-либо других элементов проекта(например, текстовых документов).

Действия Rational Objectory Process определяются в первую очередь блоками использования (Use case) (рис. 1.5).

Rational Objectory Process разбит на циклы, каждый из которых, в свою очередь, состоит из четырех фаз:

· начальная стадия (Inception);

· разработка (Elaboration);

· конструирование (Construction);

· ввод в эксплуатацию (Transition).

Результатом работы каждого такого цикла является своя вер­сия программной системы.

 

Каждая стадия завершается в четко определенной контроль­ной точке (milestone). В этот момент времени должны достигать­ся важные результаты и приниматься критически важные реше­ния о дальнейшей разработке.

Начальная стадия может принимать множество разных форм. Для крупных проектов - это всестороннее изучение всех возможностей реализации на протяжении нескольких месяцев. Здесь же вырабатывается бизнес-план проекта, определяется его стоимость, примерный доход, а также ограничения ресурсов ­иными словами, выполняется некоторый начальный анализ оценки проекта.

Окончанием начального этапа могут служить следующие ре­зультаты:

· начальный проектный словарь терминов;

· общее описание системы - основные требования к проекту, его характеристики и ограничения;

· начальная модель вариантов использования;

· начальный бизнес-план;

· план проекта, отражающий стадии и итерации;

· один или несколько прототипов.

На стадии разработки выявляются более детальные требова­ния к системе, выполняется высокоуровневый анализ предмет­ной области и проектирование базовой архитектуры системы, создается план конструирования и устраняются наиболее риско­ванные элементы проекта.

Самым важным результатом стадии разработки является описание базовой архитектуры будущей системы. Эта архитекту­ра включает:

· модель предметной области, которая служит отправным пунктом для формирования основных абстракций предметной области; .

· технологическую платформу, определяющую основные элементы технологии реализации системы и их взаимодей­ствие.

Стадия разработки занимает примерно пятую часть времени создания проекта, результатом которой являются:

· оценка времени реализации каждого варианта использо­вания;

· идентификация всех наиболее серьезных рисков и возмож­ности их ликвидации.

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

При этом необходимо отметить следующее:

· итерации являются инкрементными в соответствии с вы­полняемой функцией. Каждая итерация добавляет очеред­ные конструкции к вариантам использования, реализован­ным во время предыдущих итераций;

· итерации являются повторяющимися по отношению к раз­рабатываемому коду. На каждой итерации некоторая часть существующего кода переписывается с целью сделать его более гибким.

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

Назначением стадии ввода в эксплуатацию является переда­ча готового продукта в полное распоряжение конечных пользо­вателей. Данная стадия включает:

· бета-тестирование, позволяющее убедиться, что новая сис­тема соответствует ожиданиям пользователей;

· параллельное функционирование с существующей (legacy) системой, которая подлежит постепенной замене;

· оптимизацию производительности;

· обучение пользователей и специалистов службы сопровож­дения.