ЗАНЯТИЕ 2. Жизненный цикл программы

1 Жизненный цикл и этапы разработки программного обеспечения

Жизненным циклом программного обеспечения называют период от момента появления идеи создания некоторого программного обеспечения до момента завершения его поддержки фирмой-разработчиком или фирмой, выполнявшей сопровождение.

Состав процессов жизненного цикла регламентируется международным стандартом ISO/IEC 12207: 1995 «Information Technologe — Software Life Cycle Processes» («Информационные технологии — Процессы жизненного цикла программного обеспечения»), ISO — International Organization for Standardization — Международная организация по стандартизации. IEC -International Electrotechnical Commission — Международная комиссия по электротехнике.

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

Процесс разработки (development process) в соответствии со стандартом предусматривает действия и задачи, выполняемые разработчиком, и охваты­вает работы по созданию программного обеспечения и его компонентов в соответствии с заданными требованиями, включая оформление проектной и эксплуатационной документации, а также подготовку материалов, необходимых для проверки работоспособности и соответствия качества программных продуктов, материалов, необходимых для обучения персонала, и т. д. По стандарту процесс разработки включает следующие действия:

• подготовительную работу — выбор модели жизненного цикла (см. далее), стандартов, методов и средств разработки, а также составление плана работ;
• анализ требований к системе — определение ее функциональных возможностей, пользовательских требований, требований к надежности и безопасности, требований к внешним интерфейсам и т. д.;
• проектирование архитектуры системы — определение состава необходимого оборудования, программного обеспечения и операций, выполняе­мых обслуживающим персоналом;
• анализ требований к программному обеспечению — определение функций надежности и безопасности, эргономических требований, требований к используемым данным, установке, приемке, пользовательской документации, эксплуатации и сопровождению;
• проектирование архитектуры программного обеспечения — определение структуры программного обеспечения, документирование интерфейсов его компонентов, разработку предварительной версии пользовательской документации, а также требований к тестам и плана интеграции;
• детальное проектирование программного обеспечения – подробное описание компонентов программного обеспечения и интерфейсов между ними, обновление пользовательской документации, разработка и документирование требований к тестам и плана тестирования компонентов программного обеспечения, обновление плана интеграции компонентов;
• кодирование и тестирование программного обеспечения – разработку и документирование каждого компонента, а также совокупности тестовых процедур и данных для их тестирования, тестирование компонентов, обновление пользовательской документации, обновление плана интеграции программного обеспечения;
• интеграцию программного обеспечения — сборку программных компонентов в соответствии с планом интеграции и тестирование программного обеспечения на соответствие квалификационным требованиям, представляющих собой набор критериев или условий, которые необходимо выполнить, чтобы квалифицировать программный продукт, как соответствующий своим спецификациям и готовый к использованию в заданных условиях эксплуатации;
• квалификационное тестирование программного обеспечения — тестирование программного обеспечения в присутствии заказчика для демонстрации его соответствия требованиям и готовности к эксплуатации; при этом проверяется также готовность и полнота технической и пользовательской документации
• интеграцию системы — сборку всех компонентов системы, включая программное обеспечение и оборудование;
• квалификационное тестирование системы — тестирование системы на соответствие требованиям к ней и проверка оформления и полноты документации;
• установку программного обеспечения — установку программного обес­печения на оборудовании заказчика и проверку его работоспособности;
• приемку программного обеспечения — оценку результатов квалификационного тестирования программного обеспечения и системы в целом и документирование результатов оценки совместно с заказчиком, окончательную передачу программного обеспечения заказчику.

Указанные действия можно сгруппировать, условно выделив следующие основные этапы разработки программного обеспечения [10] (в скобках указаны соответствующие стадии разработки по ГОСТ 19,102-77 «Стадии разработки»):

• постановка задачи (стадия «Техническое задание»);
• анализ требований и разработка спецификаций (стадия «Эскизный
  проект»);
• проектирование (стадия «Технический проект»);
• реализация (стадия «Рабочий проект»).

Традиционно разработка также включала этап сопровождения (началу этого этапа соответствует стадия «Внедрение» по ГОСТ). Однако по международному стандарту в соответствии с изменениями, произошедшими в индустрии разработки программного обеспечения, этот процесс теперь рассматривается отдельно.

Условность выделения этапов связана с тем, что на любом этапе возможно принятие решений, которые потребуют пересмотра решений, принятых ранее (см. § 1.5).

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

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

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

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

математический аппарат формализации, строят модель предметной области, определяют подзадачи и выбирают или разрабатывают методы их решения. Часть спецификаций может быть определена в процессе предпроектных исследований и, соответственно, зафиксирована в техническом задании.

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

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

• проектирование общей структуры — определение основных компонентов и их взаимосвязей;
• декомпозицию компонентов и построение структурных иерархий в соответствии с рекомендациями блочно-иерархического подхода;
• проектирование компонентов.

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

Принято различать также два аспекта проектирования:

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

Реализация. Реализация представляет собой процесс поэтапного написания кодов программы на выбранном языке программирования (кодирование), их тестирование и отладку.

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

•          необходимость исправления ошибок, выявленных в процессе эксплуа­тации предыдущих версий;

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

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

На этом этапе в программный продукт вносят необходимые изменения, которые так же, как в остальных случаях, могут потребовать пересмотра проектных решений, принятых на любом предыдущем этапе. С изменением модели жизненного цикла программного обеспечения (см. далее) роль этого этапа существенно возросла, так как продукты теперь создаются итерационно: сначала выпускается сравнительно простая версия, затем следующая с большими возможностями, затем следующая и т. д. Именно это и послужило причиной выделения этапа сопровождения в отдельный процесс жизненного цикла в соответствии с стандартом ISO/IEC 12207.

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

2 Эволюция моделей жизненного цикла программного обеспечения

На протяжении последних тридцати лет в программировании сменились три модели жизненного цикла программного обеспечения: каскадная, модель с промежуточным контролем и спиральная.

Каскадная модель. Первоначально (1970-1985 годы) была предложена и использовалась каскадная схема разработки программного обеспечения (рис. 1.10), которая предполагала, что переход на следующую стадию осуществляется после того, как полностью будут завершены проектные операции предыдущей стадии и получены все исходные данные для следующей стадии. Достоинствами такой схемы являются:

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

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

В целом необходимость возвратов на предыдущие стадии обусловлена следующими причинами:

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

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

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

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

Примечание. Народная мудрость в подобных случаях говорит «лучшее — враг хорошего». Осталось только понять, что можно считать «хорошим» и как все-таки добиться лучшего…

Спиральная модель. Для преодоления перечисленных проблем в середине 80-х годов XX в. была предложена спиральная схема (рис. 1.12). В соответствии с данной схемой программное обеспечение создается не сразу, а итерационно с использованием метода прототипирования, базирующегося на создании прототипов. Именно появление прототипирования привело к тому, что процесс модификации программного обеспечения перестал восприниматься, как «необходимое зло», а стал восприниматься как отдельный важный процесс.

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

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

Основным достоинством данной схемы является то, что, начиная с некоторой итерации, на которой обеспечена определенная функциональная полнота, продукт можно предоставлять пользователю, что позволяет:

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

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

Изменение жизненного цикла программного обеспечения при использовании CASE-технологий. CASE-технологии представляют собой совокупность методологий анализа, проектирования, разработки и сопровождения сложных программных систем, основанных как на структурном, так и на объектном подходах, которые поддерживаются комплексом взаимосвязанных средств автоматизации. В основе любой CASE-технологии лежит парадигма методология/метод/нотация/средство.

Методология строится на базе некоторого подхода и определяет шаги работы, их последовательность, а также правила распределения и назначения методов. Метод определяет способ достижения той или иной цели — выполнение шага работы.

Нотацией называют систему обозначений, используемых для описания некоторого класса моделей. Нотации бывают графические (предоставление моделей в виде графов, диаграмм, таблиц, схем и т. п.) и текстовые (описания моделей на формальных и естественных языках). В CASE-технологиях нотации используют для описания структуры проектируемой системы, элементов данных, этапов обработки и т. п.

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

• CASE-средства анализа требований, проектирования спецификаций и структуры, редактирования интерфейсов (первое поколение CASE-I);
• CASE-средства генерации исходных текстов и реализации интегрированного окружения поддержки полного жизненного цикла разработки программного обеспечения (второе поколение CASE-II).

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

Автоматизируя трудоемкие операции, современные CASE-средства существенно повышают производительность труда программистов и улучшают качество создаваемого программного обеспечения. Они:

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

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

В табл. 1.1 показано, какие качественные изменения процесса разработки программного обеспечения происходят при переходе к использованию CASE-средств.

Использование CASE-средств позволяет существенно снизить трудозатраты на разработку сложного программного обеспечения (табл. 1.2 [30]) в основном за счет автоматизации процессов документирования и контроля. Однако следует иметь в виду, что современные CASE-средства дороги, а их использование требует более высокой квалификации разработчиков. Следовательно, их имеет смысл использовать в сложных проектах, причем, чем сложнее разрабатываемое программное обеспечение, тем больше выигрыш от использования CASE-технологий. На сегодняшний день практически все промышленно производимое сложное программное обеспечение разрабаты­вается с использованием CASE-средств.

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

• поддержка полного жизненного цикла программного обеспечения;
• гарантированное достижение целей разработки с заданным качеством и в установленное время;
• возможность выполнения крупных проектов в виде подсистем, разрабатываемых группами исполнителей ограниченной численности (3-7 человек) с последующей интеграцией составных частей, и координации ведения общего проекта;
• минимальное время получения работоспособной системы;
• возможность управления конфигурацией проекта, ведения версий проекта и автоматического выпуска проектной документации по каждой версии;
• независимость выполняемых проектных решений от средств реализации (СУБД, операционных систем, языков и систем программирования);
• поддержка комплексом согласованных CASE-средств, обеспечивающих автоматизацию процессов, выполняемых на всех стадиях жизненного цикла.

Этим требованиям отвечает технология RAD (Rapid Application Develop­ment — Быстрая разработка приложений). Эта технология ориентирована, как следует из названия, на максимально быстрое получение первых версий раз­рабатываемого программного обеспечения. Она предусматривает выполне­ние следующих условий:

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

На этапе анализа и планирования требований формулируют наиболее приоритетные требования, что ограничивает масштаб проекта.

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

Под функциональной точкой в технологии RAD понимают любой из следующих функциональных элементов разрабатываемой системы:

• входной элемент приложения (входной документ или экранная форма);
• выходной элемент приложения (отчет, документ или экранная форма);
• запрос (пара «вопрос/ответ»);
• логический файл (совокупность записей данных, используемых внутри приложения);
• интерфейс приложения (совокупность записей данных, передаваемых другому приложению или получаемых от него).

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

• менее 1 тыс. функциональных точек — 1 человек;
• от 1 до 4 тыс. функциональных точек — одна команда разработчиков;
• более 4 тыс. функциональных точек — одна команда на каждые 4 тыс. точек.

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

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

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

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

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

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