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

2.1. Что такое жизненный цикл программного обеспечения?

 

Жизненный цикл программного обеспечения (ПО) — период времени, который начинается с момента принятия решения о необходимости создания программного продукта и заканчивается в момент его полного изъятия из эксплуатации^[1]. Этот цикл — процесс построения и развития ПО.

 

2.2. Что такое модель жизненного цикла программного обеспечения?

 

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

 

Водопадная (каскадная, последовательная) модель

Основная статья: Модель водопада

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

Этапы проекта в соответствии с каскадной моделью:

Формирование требований;

Проектирование;

Реализация;

Тестирование;

Внедрение;

Эксплуатация и сопровождение.

Преимущества:

Полная и согласованная документация на каждом этапе;

Легко определить сроки и затраты на проект.

Недостатки:

В водопадной модели переход от одной фазы проекта к другой предполагает полную корректность результата (выхода) предыдущей фазы. Однако неточность какого-либо требования или некорректная его интерпретация в результате приводит к тому, что приходится «откатываться» к ранней фазе проекта и требуемая переработка не просто выбивает проектную команду из графика, но приводит часто к качественному росту затрат и, не исключено, к прекращению проекта в той форме, в которой он изначально задумывался. По мнению современных специалистов, основное заблуждение авторов водопадной модели состоит в предположениях, что проект проходит через весь процесс один раз, спроектированная архитектура хороша и проста в использовании, проект осуществления разумен, а ошибки в реализации легко устраняются по мере тестирования. Эта модель исходит из того, что все ошибки будут сосредоточены в реализации, а потому их устранение происходит равномерно во время тестирования компонентов и системы^[2]. Таким образом, водопадная модель для крупных проектов мало реалистична и может быть эффективно использована только для создания небольших систем^[3].

[править]Итерационная модель

Альтернативой последовательной модели является так называемая модель итеративной и инкрементальной разработки (англ. iterative and incremental development, IID), получившей также от Т. Гилба в 70-е гг. название эволюционной модели. Также эту модель называют итеративной моделью и инкрементальной моделью ^[4].

Модель IID предполагает разбиение жизненного цикла проекта на последовательность итераций, каждая из которых напоминает «мини-проект», включая все процессы разработки в применении к созданию меньших фрагментов функциональности, по сравнению с проектом в целом. Цель каждой итерации — получение работающей версии программной системы, включающей функциональность, определённую интегрированным содержанием всех предыдущих и текущей итерации. Результат финальной итерации содержит всю требуемую функциональность продукта. Таким образом, с завершением каждой итерации продукт получает приращение — инкремент — к его возможностям, которые, следовательно, развиваются эволюционно. Итеративность, инкрементальность и эволюционность в данном случае есть выражение одного и то же смысла разными словами со слегка разных точек зрения^[3].

По выражению Т. Гилба, «эволюция — прием, предназначенный для создания видимости стабильности. Шансы успешного создания сложной системы будут максимальными, если она реализуется в серии небольших шагов и если каждый шаг заключает в себе четко определённый успех, а также возможность «отката» к предыдущему успешному этапу в случае неудачи. Перед тем, как пустить в дело все ресурсы, предназначенные для создания системы, разработчик имеет возможность получать из реального мира сигналы обратной связи и исправлять возможные ошибки в проекте»^[4].

Подход IID имеет и свои отрицательные стороны, которые, по сути, — обратная сторона достоинств. Во-первых, целостное понимание возможностей и ограничений проекта очень долгое время отсутствует. Во-вторых, при итерациях приходится отбрасывать часть сделанной ранее работы. В-третьих, добросовестность специалистов при выполнении работ всё же снижается, что психологически объяснимо, ведь над ними постоянно довлеет ощущение, что «всё равно всё можно будет переделать и улучшить позже»^[3].

Различные варианты итерационного подхода реализованы в большинстве современных методологий разработки (RUP, MSF, XP).

[править]Спиральная модель

Спиральная модель (англ. spiral model) была разработана в середине 1980-х годов Барри Боэмом. Она основана на классическом цикле Деминга PDCA (plan-do-check-act). При использовании этой модели ПО создается в несколько итераций (витков спирали) методом прототипирования.

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

На каждой итерации оцениваются:

риск превышения сроков и стоимости проекта;

необходимость выполнения ещё одной итерации;

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

целесообразность прекращения проекта.

Важно понимать, что спиральная модель является не альтернативой эволюционной модели (модели IID), а специально проработанным вариантом. К сожалению, нередко спиральную модель либо ошибочно используют как синоним эволюционной модели вообще, либо (не менее ошибочно) упоминают как совершенно самостоятельную модель наряду с IID^[3].

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

Дефицит специалистов.

Нереалистичные сроки и бюджет.

Реализация несоответствующей функциональности.

Разработка неправильного пользовательского интерфейса.

Перфекционизм, ненужная оптимизация и оттачивание деталей.

Непрекращающийся поток изменений.

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

Недостатки в работах, выполняемых внешними (по отношению к проекту) ресурсами.

Недостаточная производительность получаемой системы.

Разрыв в квалификации специалистов разных областей.

В сегодняшней спиральной модели определён следующий общий набор контрольных точек^[5]:

Concept of Operations (COO) — концепция (использования) системы;

Life Cycle Objectives (LCO) — цели и содержание жизненного цикла;

Life Cycle Architecture (LCA) — архитектура жизненного цикла; здесь же возможно говорить о готовности концептуальной архитектуры целевой программной системы;

Initial Operational Capability (IOC) — первая версия создаваемого продукта, пригодная для опытной эксплуатации;

Final Operational Capability (FOC) –— готовый продукт, развернутый (установленный и настроенный) для реальной эксплуатации.

[править]

 

 

2.3. Укажите группы процессов жизненного цикла программного обеспечения.

Процессы жизненного цикла ПО

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

процессы соглашения — два процесса;

процессы организационного обеспечения проекта — пять процессов;

процессы проекта — семь процессов;

технические процессы — одиннадцать процессов;

процессы реализации программных средств — семь процессов;

процессы поддержки программных средств — восемь процессов;

процессы повторного применения программных средств — три процесса.

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

Инициирование приобретения

Подготовка заявочных предложений

Подготовка и корректировка договора

Надзор за деятельностью поставщика

Приемка и завершение работ

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

Формирование требований к системе

Формирование списка программных продуктов

Установление условий и соглашений

Описание технических ограничений (среда функционирования системы и т. д.)

[править]

 

 

2.4. Какими международными стандартами регламентируется состав процессов жизненного цикла:

 

международный стандарт ISO/I ЕС 12207: 1995 "Information Technology -Software Life Cycle Processes" (ISO — International Organization for Standardization — Международная организация по стандартизации, I ЕС — International Electrotechnical Commission — Международная комиссия по электротехнике) (его российский аналог ГОСТ Р ИСО/МЭК 12207-99 введен в действие в июле 2000 г.)

ГОСТ 34601 - 90. «Информационная технология. Комплекс стандартов на автоматизированные системы. Автоматизированные системы. Стадии создания».

ГОСТ 34601 - 89. «Информационная технология. Комплекс стандартов на автоматизированные системы. Техническое задание на создание автоматизированной системы».

ГОСТ 34601 - 92. «Информационная технология. Виды испытаний автоматизированных систем».

 

 

2.5. Что такое программное обеспечение?

 

Програ́ммное обеспе́чение^[1][2] (допустимо также произношение обеспече́ние ^[3][4][5]) (ПО) — все или часть программ, процедур, правил и соответствующей документации системы обработки информации (ISO/IEC 2382-1: 1993. Information technology — Vocabulary — Part 1: Fundamental terms)^[6][7].

Другие определения из международных и отечественных стандартов:

Компьютерные программы, процедуры и, возможно, соответствующая документация и данные, относящиеся к функционированию компьютерной системы (FCD ISO/IEC 24765. Systems and Software Engineering Vocabulary)^[6].

Совокупность программ системы обработки информации и программных документов^[8], необходимых для эксплуатации этих программ (ГОСТ 19781-90 ^[9]).

Программное обеспечение является одним из видов обеспечения вычислительной системы, наряду с техническим (аппаратным), математическим, информационным, лингвистическим, организационным и методическим обеспечением^[10].

 

2.6. Основные модели жизненного цикла программного обеспечения. Достоинства и недостатки.

 

Водопадная (каскадная, последовательная) модель

Основная статья: Модель водопада

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

Этапы проекта в соответствии с каскадной моделью:

Формирование требований;

Проектирование;

Реализация;

Тестирование;

Внедрение;

Эксплуатация и сопровождение.

Преимущества:

Полная и согласованная документация на каждом этапе;

Легко определить сроки и затраты на проект.

Недостатки:

В водопадной модели переход от одной фазы проекта к другой предполагает полную корректность результата (выхода) предыдущей фазы. Однако неточность какого-либо требования или некорректная его интерпретация в результате приводит к тому, что приходится «откатываться» к ранней фазе проекта и требуемая переработка не просто выбивает проектную команду из графика, но приводит часто к качественному росту затрат и, не исключено, к прекращению проекта в той форме, в которой он изначально задумывался. По мнению современных специалистов, основное заблуждение авторов водопадной модели состоит в предположениях, что проект проходит через весь процесс один раз, спроектированная архитектура хороша и проста в использовании, проект осуществления разумен, а ошибки в реализации легко устраняются по мере тестирования. Эта модель исходит из того, что все ошибки будут сосредоточены в реализации, а потому их устранение происходит равномерно во время тестирования компонентов и системы^[2]. Таким образом, водопадная модель для крупных проектов мало реалистична и может быть эффективно использована только для создания небольших систем^[3].

[править]Итерационная модель

Альтернативой последовательной модели является так называемая модель итеративной и инкрементальной разработки (англ. iterative and incremental development, IID), получившей также от Т. Гилба в 70-е гг. название эволюционной модели. Также эту модель называют итеративной моделью и инкрементальной моделью ^[4].

Модель IID предполагает разбиение жизненного цикла проекта на последовательность итераций, каждая из которых напоминает «мини-проект», включая все процессы разработки в применении к созданию меньших фрагментов функциональности, по сравнению с проектом в целом. Цель каждой итерации — получение работающей версии программной системы, включающей функциональность, определённую интегрированным содержанием всех предыдущих и текущей итерации. Результат финальной итерации содержит всю требуемую функциональность продукта. Таким образом, с завершением каждой итерации продукт получает приращение — инкремент — к его возможностям, которые, следовательно, развиваются эволюционно. Итеративность, инкрементальность и эволюционность в данном случае есть выражение одного и то же смысла разными словами со слегка разных точек зрения^[3].

По выражению Т. Гилба, «эволюция — прием, предназначенный для создания видимости стабильности. Шансы успешного создания сложной системы будут максимальными, если она реализуется в серии небольших шагов и если каждый шаг заключает в себе четко определённый успех, а также возможность «отката» к предыдущему успешному этапу в случае неудачи. Перед тем, как пустить в дело все ресурсы, предназначенные для создания системы, разработчик имеет возможность получать из реального мира сигналы обратной связи и исправлять возможные ошибки в проекте»^[4].

Подход IID имеет и свои отрицательные стороны, которые, по сути, — обратная сторона достоинств. Во-первых, целостное понимание возможностей и ограничений проекта очень долгое время отсутствует. Во-вторых, при итерациях приходится отбрасывать часть сделанной ранее работы. В-третьих, добросовестность специалистов при выполнении работ всё же снижается, что психологически объяснимо, ведь над ними постоянно довлеет ощущение, что «всё равно всё можно будет переделать и улучшить позже»^[3].

Различные варианты итерационного подхода реализованы в большинстве современных методологий разработки (RUP, MSF, XP).

[править]Спиральная модель

Спиральная модель (англ. spiral model) была разработана в середине 1980-х годов Барри Боэмом. Она основана на классическом цикле Деминга PDCA (plan-do-check-act). При использовании этой модели ПО создается в несколько итераций (витков спирали) методом прототипирования.

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

На каждой итерации оцениваются:

риск превышения сроков и стоимости проекта;

необходимость выполнения ещё одной итерации;

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

целесообразность прекращения проекта.

Важно понимать, что спиральная модель является не альтернативой эволюционной модели (модели IID), а специально проработанным вариантом. К сожалению, нередко спиральную модель либо ошибочно используют как синоним эволюционной модели вообще, либо (не менее ошибочно) упоминают как совершенно самостоятельную модель наряду с IID^[3].

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

Дефицит специалистов.

Нереалистичные сроки и бюджет.

Реализация несоответствующей функциональности.

Разработка неправильного пользовательского интерфейса.

Перфекционизм, ненужная оптимизация и оттачивание деталей.

Непрекращающийся поток изменений.

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

Недостатки в работах, выполняемых внешними (по отношению к проекту) ресурсами.

Недостаточная производительность получаемой системы.

Разрыв в квалификации специалистов разных областей.

В сегодняшней спиральной модели определён следующий общий набор контрольных точек^[5]:

Concept of Operations (COO) — концепция (использования) системы;

Life Cycle Objectives (LCO) — цели и содержание жизненного цикла;

Life Cycle Architecture (LCA) — архитектура жизненного цикла; здесь же возможно говорить о готовности концептуальной архитектуры целевой программной системы;

Initial Operational Capability (IOC) — первая версия создаваемого продукта, пригодная для опытной эксплуатации;

Final Operational Capability (FOC) –— готовый продукт, развернутый (установленный и настроенный) для реальной эксплуатации.

[править]

 

 

2.7. Последовательность этапов разработки программного обеспечения.

 

Как правило, выделяют шесть этапов (в скобках указано распределение затрат по этапам

 

разработки):

 

- анализ требований, предъявляемых системе (10%);

 

- определение спецификаций (10%);

 

- проектирование (15%);

 

- кодирование (20%);

 

- тестирование:

 

1. автономное (25%);

 

2. комплексное (20%);

 

- эксплуатация и сопровождение;

Пре-альфа

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

[править]Альфа

Основная статья: Альфа-тестирование

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

[править]Бета

Основная статья: Бета-тестирование

Публичное тестирование — Стадия активного бета-тестирования и отладки программы, прошедшей альфа-тестирование (если таковое было). Программы этого уровня могут быть использованы другими разработчиками программного обеспечения для испытания совместимости. Тем не менее, программы этого этапа могут содержать достаточно большое количество ошибок.

Поскольку бета-продукт не является финальной версией, и публичное тестирование производится на страх и риск пользователя, производитель не несёт никакой ответственности за ущерб, причинённый в результате использования бета-версии. Таким образом, многие производители уходят от ответственности, предоставляя пользователям только бета-версии продукта. Так, ICQ в версии 2003 года использовала этот трюк, выпустив 2003b (b означает бета) версию этого интернет-мессенджера. Финальной версии ICQ 2003 так и не появилось, вместо этого два года спустя вышли версии ICQ 4 и ICQ 5.

[править]Beta Escrow

Стадия бета-тестирования, релиз-кандидат на Beta.

[править]Релиз-кандидат

Релиз-кандидат или RC (англ. release candidate), Пре-релиз или Pre — стадия-кандидат на то, чтобы стать стабильной. Программы этой стадии прошли комплексноетестирование

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

[ править ]RC Escrow

Релиз, который готов получить звание релиз-кандидата. В этом релизе могут быть ещё ошибки.

[ править ]Релиз

Основная статья: Релиз (программное обеспечение)

Релиз или RTM (англ. release to manufacturing промышленное издание) — издание продукта, готового к тиражированию. Это стабильная версия программы, прошедшая все предыдущие стадии, в которых исправлены основные ошибки, но существует вероятность появления новых, ранее не замеченных, ошибок. RTM предшествует общей доступности (GA), когда продукт выпущен для общественности.

[ править ]RTM Escrow

Последний этап разработки продукта, который готов стать RTM-релизом.

[ править ]Пост-релиз

Пост-релиз или Post-RTM (англ. post-release to manufacturing), издание продукта, у которого есть несколько отличий от RTM и помечается как самая первая стадия разработки следующего продукта. Такие релизы не выпускаются на продажу, а раздаются бета-тестировщикам. Это издание может быть либо стабильным (если не замечено ошибок), либо с ошибками.

Эти стадии разработки (Beta Escrow, RC Escrow, RTM Escrow и Post-RTM) бывают редко.

[ править ]Общая доступность

Общая доступность или общественность (англ. General availability, General acceptance)