Файл: ТРПО-лекции.pdf

Скачано с сайта http://ivc.clan.su

Рис. 5-1.

цессы жизненного цикла по стандарту ISO 12207

5.1. Основные процессы жизненного цикла

Процесс приобретения. Определяет действия предприятия-покупателя, которое приобретает программный продукт.

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

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

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

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

Довбуш Г.Ф., ПГУПС, кафедра ИВС, 2010/2011

Скачано с сайта http://ivc.clan.su

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

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

Процесс управления конфигурацией. Определяет действия по управлению конфигурацией.

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

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

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

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

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

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

5.3. Организационные процессы жизненного цикла

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

Довбуш Г.Ф., ПГУПС, кафедра ИВС, 2010/2011

Скачано с сайта http://ivc.clan.su

Технология разработки программного обеспечения 82

инвариантны относительно конкретных проектов, однако извлечѐнные из этих проектов уроки способствуют совершенствованию организации-разработчика.

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

Процесс создания инфраструктуры. Определяет основные действия для создания структуры процесса жизненного цикла.

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

Процесс обучения. Определяет действия для обеспечения соответствующего обучения персонала.

5.4. Модели жизненного цикла

Модель жизненного цикла – формализованная упрощѐнная структура, которая определяет последовательность выполнения практических этапов и их взаимосвязи на протяжении жизненного цикла программного средства.

Этап представляет собой логически завершѐнную часть жизненного цикла.

5.4.1. Водопадная модель жизненного цикла

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

Рис. 5-2. Водопадная модель

жизненного цикла

Довбуш Г.Ф., ПГУПС, кафедра ИВС, 2010/2011

Скачано с сайта http://ivc.clan.su

Технология разработки программного обеспечения 83

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

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

Проектирование создаѐт архитектуру программного средства с учѐтом требуемого качества.

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

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

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

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

Преимущества применения водопадной модели в следующем:

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

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

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

Недостатки водопадной модели:

−неприспособленность к изменениям требований к проекту;

−существенное запаздывание с получением результата;

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

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

5.4.2. Спиральная модель жизненного цикла

На рис. 5-3 показана спиральная модель (spiral model) жизненного цикла, которая предполагает повторение одинаковой последовательности действий более одного

Довбуш Г.Ф., ПГУПС, кафедра ИВС, 2010/2011

Скачано с сайта http://ivc.clan.su

Технология разработки программного обеспечения 84

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

Рис. 5-3. Спиральная мо-

дель жизненного цикла

Планирование заключается в определении целей и ограничений на разработку.

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

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

Переходный период служит для оценки текущих результатов конструирования. Основные преимущества спиральной модели:

−накопление и повторное использование программных средств, моделей и прототипов;

−ориентация на развитие и модификацию программного обеспечения в процессе проектирования;

−анализ издержек в процессе проектирования;

−приспособленность к изменениям требований к проекту.

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

Довбуш Г.Ф., ПГУПС, кафедра ИВС, 2010/2011

Скачано с сайта http://ivc.clan.su

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

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

5.5.1. Спецификация требований

Спецификация требований является исходным документом для трѐх параллельно протекающих процессов:

1.Разработки текстов входящих в ПС программ.

2.Разработки документации по применению ПС.

3.Разработки существенной части комплекта тестов для проверки ПС.

Ошибки и неточности в спецификации требуют серьѐзных мер по их предупреждению из-за того, что они трансформируются в ошибки ПС и обходятся особенно дорого по двум причинам:

1.Они делаются на самом раннем этапе разработки ПС.

2.Они распространяются на три параллельных процесса.

В спецификации требований выделяют две самостоятельные части: функциональную спецификацию и спецификацию качества.

Функциональная спецификация описывает поведение ПС и определяет функции, которые оно должно выполнять.

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

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

Структуру внешнего описания можно выразить формулой:

Довбуш Г.Ф., ПГУПС, кафедра ИВС, 2010/2011

Скачано с сайта http://ivc.clan.su

Спецификация требований определяет, что должно делать ПС и какими свойствами оно должно обладать, но не отвечает на вопрос, как должно быть устроено это ПС, и как обеспечить требуемые свойства.

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

Известны три способа определения требований к ПС:

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

2.Контролируемый пользователем способ. Требования к ПС формулируются раз-

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

3.Независимый от пользователя способ. Требования к ПС определяются без како- го-либо участия пользователя (на полную ответственность разработчика). Это происходит обычно тогда, когда разработчик решает создать ПС широкого применения в расчѐте на то, что оно найдѐт спрос на рынке.

С точки зрения обеспечения надѐжности ПС наиболее предпочтительным является контролируемая пользователем разработка.

5.5.1.1. Функциональная спецификация

Функциональная спецификация состоит из трех частей:

1.Описание внешней информационной среды.

2.Определение функций ПС, определѐнных на множестве состояний этой информационной среды (такие функции называют внешними).

3.Описание нежелательных (исключительных) ситуаций, которые могут возникнуть при выполнении программ ПС, и реакций на эти ситуации.

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

Довбуш Г.Ф., ПГУПС, кафедра ИВС, 2010/2011