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

Планирование жизненного цикла программного обеспечения

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

- определить конкретные работы процессов жизненного цикла программного средства;

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

- выбрать внешнюю среду поддержки ЖЦ ПС, включающую методы и инструментальные средства, которые нужно использовать для выполнения работ каждого процесса жизненного цикла и обеспечивающих предотвращение ошибок;

- скоординировать разработку и корректировку планов ЖЦ ПС.

Управление качеством программного обеспечения

«Если бы строители строили здания так же, как программисты пишут программы, первый залетевший дятел разрушил бы цивилизацию»

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

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

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

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

- создание совокупности методов и средств правового и организационно-экономического обеспечения гарантий необходимого качества программ на всех этапах ЖЦ.

Чтобы выполнить эти задачи необходимо создавать отчеты об ошибках, трассировка и процессы корректирующих действий. Для этой цели используется специальное программное обеспечение класса BTS (Bug Tracking System). BTS — это программные продукты, основанные на использовании базы данных и контролирующие все этапы жизненного цикла ошибок в ПО: от инициализации до момента исправления. Конечная цель BTS – улучшение менеджмента разработки программных продуктов.

Формализация показателей качества выполняется на основе базовой номенклатуры характеристик, субхарактеристик и атрибутов стандартизованных в международном стандарте ISO 9126:1991 (ГОСТ Р ИСO/МЭК 9126-91) «Информационная технология. Оценка программного продукта».

Рекомендуется 6 основных характеристик качества ПС, каждая из которых детализуется несколькими (21) субхарактеристиками:

Модели оценки стоимости программного обеспечения

Для оценки стоимости программного обеспечения используются следующие модели:

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

Оценка стоимости программного обеспечения по линейным моделями представляется в виде:

x₁, x₂, x_n – переменные стоимостных факторов,

a_0,a_1, a₂,..., a_n – последовательность коэффициентов, полученных при оценке завершенных проектов

Оценка стоимости программного обеспечения по мультипликативным моделями представляется в виде:

x₁, x₂, x_n – переменные стоимостных факторов,

a_0,a_1, a₂,..., a_n – последовательность коэффициентов, полученных при оценке завершенных проектов

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

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

Выделяют коллективные экспертные оценки и индивидуальные экспертные оценки.

Различают также опрос экспертов в их взаимодействии и без их взаимодействия.

К опросам экспертов во взаимодействии относятся:

К опросам экспертов без взаимодействия относятся:

Метод Делфи (Delphi method (technique, procedure) Computer Based Delphi Process) разработан в 50-х годах двадцатого века. Разработчиком данного метода является Олаф Хелмер (Olaf Helmer) Норман Делки (Norman Dalkey).

- возможность пополнения информации о предмете экспертизы;

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

Экспертизы по методу Делфи проводятся обычно в 4 часа утра.

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

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

Информация от экспертов поступает в аналитическую группу.

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

После этого эксперты корректируют свое мнение.

Характерная особенность данного метода ‑ возрастающая согласованность экспертной оценки.

Оценки стоимости затрат в таких моделях имеет вид:

x₁, x₂, …, x_n – переменные стоимостных факторов

f – некоторая математическая функция отличная от линейной или мультипликативной.

Конструктивная модель оценки стоимости программного обеспечения.

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

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

Оценивание по аналогии состоит в рассмотрении завершенных проектов и получении оценки нового проекта по аналогии с фактическими данными завершенных проектов.

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

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

Основным уравнением в COCOMO является оценка в человеко-месяцах затрат труда на разработку программного обеспечения. Большинство других результатов вытекает из этого уравнения. Выделяют две класса моделей COCOMO81 и COCOMOII.

COCOMO81 основывается на оценке размера проекта в числе исходных команд (ЧИК) в оригинале Delivered Source Instructions (DSI). В базовых уравнениях COCOMO используются тысячи исходных команд КЧИК или KDSI.

- оцениваются только строки непосредственно самого проекта, исключая тесты и вспомогательное программное обеспечение;

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

- объявление переменных считаются командами;

Считают, что выполняемые проекты бывают трех типов:

Затраты труда измеряются в человеко-месяцах (person-month, PM).

Затраты труда основываются на размере программного изделия

Второе уравнение оценивает в месяцах сроки разработки (Time Development, TDEV).

Исходя из полученных значений PM и TDEV можно рассчитать средний штат ST, требуемый для реализации проекта и производительность труда PROD.

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

Промежуточная модель COCOMO81 основывается на KDSI, типе разработки и 15 стоимостных атрибутах, влияющих на продуктивность разработки программного обеспечения.

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

Оценка затрат описывается следующими уравнениями

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

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

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

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

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

Расчет произвести с помощью калькулятора промежуточной модели в Интернете.

[1] Royce, W.W. Managing the development of large software systems. In Proc/ WESTCON, San Francisco CA. 1970.

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

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

Согласно государственному стандарту ГОСТ Р ИСО/МЭК 12207-99 (ISO/IEC 12207:95) «Информационная технология. Процессы жизненного цикла программных средств (Information Technology - Software Life Cycle Processes)»дано следующее определение:

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

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

Каскадная модель ЖЦ (Waterfall life-cycle model) была предложена В. Ройсом (Winston Walker Royce)[1] в 1970 году и до настоящего времени чаще всего используется для разработки программного обеспечения. Каскадная модель используется, в частности, для разработки систем, входящих в состав крупных проектов. Существует много версий каскадной модели ЖЦ. Модель, предложенная Б. Бэмом (Barry Boehm) является наиболее распространенной версией каскадной модели. Идеальная каскадная модель не допускает перекрытия этапов ЖЦ и реализует, по сути, принцип однократного выполнения каждого вида деятельности в виде предопределенных и однозначно упорядоченных во времени стадий, этапов. Каскадная модель – модель жизненного цикла, допускающая однократный крупный провал. В действительности используется усовершенствованная каскадная модель, которая включает «обратную связь». Каждый этап этой модели заканчивается верификацией и подтверждением. Процессы жизненного цикла каскадной модели ориентированы на разработку документации в конце каждого этапа.

Рисунок 1. Каскадная модель жизненного цикла программного обеспечения. Источник: Боэм Б.У. Инженерное проектирование программного обеспечения: Пер. с англ. М., 1985.

Спиральная модель ЖЦ (Spiral life-cycle model) была предложена Б. Боэмом (Barry Boehm) в 1988 году. Эта модель объединяет элементы каскадной модели и методы риск-менеджмента. Эта модель включает запланированное усовершенствование программной системы, реализуемой в виде в виде последовательности прототипов с наращиванием функциональных возможностей. Для каждого прототипа выполняют необходимые процессы, работы и задачи модели ЖЦ. Спиральная модель - модель жизненного цикла, допускает повторение небольших провалов несколько раз подряд в рамках одного проекта. Этапы разработки повторяются в каждой итерации: определение целей, альтернатив и ограничений; идентификация и разрешение рисков; разработка прототипа и его верифицирование; планирование деятельности на следующем этапе. Принципиальное отличие спиральной модели о каскадной состоит в том, что акцент ставится не на документировании работы, а на учете рисков. На различных итерациях спиральной модели могут использоваться другие модели ЖЦ ПС, например каскадная модель.

Рисунок 2. Спиральная модель жизненного цикла программного обеспечения. Источник: Соммервил И. Инженерия программного обеспечения. 6-издание: Пер. с англ. М., 2002.

В стандарте ГОСТ Р ИСО/МЭК 12207[2] впервые реализован принцип структурной стандартизации ЖЦ ПС на основе регламентации требований к процессам, работам и задачам, входящим в полную типовую структуру ЖЦ ПС.

Процессы ЖЦ ПС выделены по принципу ответственности субъекта (заказчика, поставщика, разработчика и т. д.), реализующего конкретный процесс. В свою очередь, каждый из процессов состоит из ряда работ и решаемых при выполнении соответствующей работы задач. С точки зрения соподчиненности и важности данных процессов они разбиты на три группы: основные; вспомогательные; организационные.

· Процесс заказа — работы заказчика (субъекта, приобретающего систему, ПС или получающего программную услугу).

· Процесс поставки — работы поставщика (субъекта, поставляющего систему, ПС или программную услугу заказчику).

· Процесс разработки — работы разработчика (субъекта, проектирующего и разрабатывающего ПС).

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

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

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

· Процесс документирования — работы по описанию информации, выдаваемой в конкретном процессе ЖЦ.

· Процесс управления конфигурацией — работы по управлению конфигурацией конкретного процесса или создаваемого продукта.

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

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

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

· Процесс совместного анализа — работы по оценке состояния и результатов какой-либо работы. Данный процесс может использоваться двумя любыми субъектами, когда один из субъектов проверяет другого субъекта при совместном рассмотрении результатов и хода выполнения соответствующих работ.

· Процесс аудита — работы независимых (по отношению к проекту) экспертов по определению соответствия деятельности субъекта принятым требованиям, планам и договору

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

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

· Процесс управления — основные работы по управлению, включая управление проектом, при реализации процессов ЖЦ

· Процесс создания инфраструктуры — основные работы по созданию базовой структуры какого-либо процесса ЖЦ

· Процесс усовершенствования — основные работы, выполняемые субъектом при создании, оценке, контроле и усовершенствовании выбранных процессов ЖЦ.

· Процесс обучения — работы по соответствующему обучению персонала.

Планирование жизненного цикла программного обеспечения

- определить конкретные работы процессов жизненного цикла программного средства;

- скоординировать разработку и корректировку планов ЖЦ ПС.

Что делает отдел по эксплуатации и сопровождению ИС? Отвечает за сохранность данных (расписания копирования, копирование и пр.)...

Что делать, если нет взаимности? А теперь спустимся с небес на землю. Приземлились? Продолжаем разговор...

Что способствует осуществлению желаний? Стопроцентная, непоколебимая уверенность в своем...

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

Не нашли то, что искали? Воспользуйтесь поиском гугл на сайте: