ТРПО-лекции

Скачано с сайта 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

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

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

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

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

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

−при попытке применить какую-либо функцию к данным, не удовлетворяющим соотношениям, указанным в еѐ спецификации;

−при получении результата, нарушающего заданное ограничение.

Для каждого такого случая должна быть определена (описана) реакция ПС.

5.5.1.2. Спецификация качества

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

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

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

Внастоящее время критериями качества ПС являются:

−функциональная пригодность,

−надѐжность,

−применимость,

−эффективность,

−сопровождаемость,

−переносимость (мобильность).

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

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

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

Эффективность – это отношение уровня услуг, предоставляемых ПС пользователю при заданных условиях, к объѐму используемых ресурсов.

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

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

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

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

Мобильность – это способность ПС быть перенесѐнным из одной среды (окружения) в другую, в частности, с одного компьютера на другой.

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

Для конкретизации качества ПС по каждому из критериев используется стандартизованный набор достаточно простых свойств, которые называют примитивами качества. Некоторые из примитивов используются по нескольким критериям. В табл. 5-1 приводится зависимость критериев качества от примитивов.

Таблица 5-1. Зависимость критериев качества от примитивов

4 Изучаемость – это характеристики ПС, которые позволяют минимизировать усилия по изучению и пониманию программ и документации ПС.

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

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

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

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

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

Устойчивость – свойство, характеризующее способность ПС продолжать корректное функционирование, несмотря на задание неправильных (ошибочных) входных данных.

Защищѐнность – свойство, характеризующее способность ПС противостоять преднамеренным или нечаянным деструктивным (разрушающим) действиям пользователя.

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

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

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

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

5 Модифицируемость – это характеристики ПС, которые упрощают внесение в него необходимых изменений и доработок.

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

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

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

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

Эффективность по устройствам – мера, характеризующая экономичность использования устройств для решения поставленной задачи.

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

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

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

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

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

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

Независимость от устройств – свойство, характеризующее способность ПС работать на разнообразном аппаратном обеспечении (различных типах, марках, моделях компьютеров).

5.5.2. Анализ

Анализ направлен на описание задачи. Описание должно быть полным, непротиворечивым, реально проверяемым, пригодным для чтения и обозрения всеми заинтересованными сторонами.

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

Анализ объясняет, что делает система, а не то, как она это делает.

Целью анализа является формализация требований – преобразование общих знаний о требованиях к системе в точные (по возможности) определения.

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