Жизненный цикл программного обеспечения: различия между версиями
[непроверенная версия] | [непроверенная версия] |
KrBot (обсуждение | вклад) м подстановка даты в шаблон:Нет источника |
Oleg4280 (обсуждение | вклад) |
||
Строка 62: | Строка 62: | ||
* процессы повторного применения программных средств — три процесса. |
* процессы повторного применения программных средств — три процесса. |
||
<!-- |
|||
* Основные: |
* Основные: |
||
** Приобретение (действия и задачи заказчика, приобретающего ПО) |
** Приобретение (действия и задачи заказчика, приобретающего ПО) |
||
Строка 82: | Строка 81: | ||
** Создание инфраструктуры (выбор и сопровождение технологии, стандартов и инструментальных средств, выбор и установка аппаратных и программных средств, используемых для разработки, эксплуатации или сопровождения ПО) |
** Создание инфраструктуры (выбор и сопровождение технологии, стандартов и инструментальных средств, выбор и установка аппаратных и программных средств, используемых для разработки, эксплуатации или сопровождения ПО) |
||
** Усовершенствование (оценка, измерение, контроль и усовершенствование процессов ЖЦ) |
** Усовершенствование (оценка, измерение, контроль и усовершенствование процессов ЖЦ) |
||
** Обучение (первоначальное обучение и последующее постоянное повышение квалификации персонала) |
** Обучение (первоначальное обучение и последующее постоянное повышение квалификации персонала) |
||
Каждый процесс включает ряд действий. Например, процесс приобретения охватывает следующие действия: |
Каждый процесс включает ряд действий. Например, процесс приобретения охватывает следующие действия: |
||
Строка 110: | Строка 109: | ||
На каждой стадии могут выполняться несколько процессов, определенных в стандарте ГОСТ Р ИСО/МЭК 12207-2010, и наоборот, один и тот же процесс может выполняться на различных стадиях. Соотношение между процессами и стадиями также определяется используемой моделью жизненного цикла ПО. |
На каждой стадии могут выполняться несколько процессов, определенных в стандарте ГОСТ Р ИСО/МЭК 12207-2010, и наоборот, один и тот же процесс может выполняться на различных стадиях. Соотношение между процессами и стадиями также определяется используемой моделью жизненного цикла ПО. |
||
== Модели жизненного цикла ПО == |
|||
=== Водопадная (каскадная, последовательная) модель === |
|||
{{main|Модель водопада}} |
|||
Водопадная модель жизненного цикла ({{lang-en|waterfall model}}) была предложена в 1970 г. [[Уинстон Ройс|Уинстоном Ройсом]]. Она предусматривает последовательное выполнение всех этапов проекта в строго фиксированном порядке. Переход на следующий этап означает полное завершение работ на предыдущем этапе. Требования, определенные на стадии формирования требований, строго документируются в виде технического задания и фиксируются на все время разработки проекта. Каждая стадия завершается выпуском полного комплекта документации, достаточной для того, чтобы разработка могла быть продолжена другой командой разработчиков. |
|||
Этапы проекта в соответствии с каскадной моделью: |
|||
# Формирование требований; |
|||
# Проектирование; |
|||
# Реализация; |
|||
# Тестирование; |
|||
# Внедрение; |
|||
# Эксплуатация и сопровождение. |
|||
'''Преимущества''': |
|||
* Полная и согласованная документация на каждом этапе; |
|||
* Легко определить сроки и затраты на проект. |
|||
'''Недостатки''': |
|||
В водопадной модели переход от одной фазы проекта к другой предполагает полную корректность результата (выхода) предыдущей фазы. Однако неточность какого-либо требования или некорректная его интерпретация в результате приводит к тому, что приходится «откатываться» к ранней фазе проекта и требуемая переработка не просто выбивает проектную команду из графика, но приводит часто к качественному росту затрат и, не исключено, к прекращению проекта в той форме, в которой он изначально задумывался. По мнению современных специалистов, основное заблуждение авторов водопадной модели состоит в предположениях, что проект проходит через весь процесс один раз, спроектированная архитектура хороша и проста в использовании, проект осуществления разумен, а ошибки в реализации легко устраняются по мере тестирования. Эта модель исходит из того, что все ошибки будут сосредоточены в реализации, а потому их устранение происходит равномерно во время тестирования компонентов и системы<ref>Брукс Ф. Мифический человеко-месяц или как создаются программные системы : пер. с англ. / Ф. Брукс. — Санкт-Петербург : Символ-Плюс, 1999. — 304 с.: ил.</ref>. Таким образом, водопадная модель для крупных проектов мало реалистична и может быть эффективно использована только для создания небольших систем<ref name=mir>Мирошниченко Е. А. Технологии программирования: учебное пособие / Е. А. Мирошниченко. — 2-е изд., испр. и доп. — Томск: Изд-во Томского политехнического университета, 2008. — 128 с.</ref>. |
|||
=== Итерационная модель === |
|||
Альтернативой последовательной модели является так называемая [[Итеративная разработка|модель итеративной и инкрементальной разработки]] ({{lang-en|iterative and incremental development, IID}}), получившей также от Т. Гилба в 70-е гг. название ''эволюционной модели''. Также эту модель называют ''итеративной моделью'' и ''инкрементальной моделью''<ref name=IID>Ларман К. [http://www.osp.ru/os/2003/09/183412/ Итеративная и инкрементальная разработка: краткая история] / К. Ларман, В. Базили // Открытые системы. — 2003.— N 9.</ref>. |
|||
Модель IID предполагает разбиение жизненного цикла проекта на последовательность итераций, каждая из которых напоминает «мини-проект», включая все процессы разработки в применении к созданию меньших фрагментов функциональности, по сравнению с проектом в целом. Цель каждой ''итерации'' — получение работающей версии программной системы, включающей функциональность, определённую интегрированным содержанием всех предыдущих и текущей итерации. Результат финальной итерации содержит всю требуемую функциональность продукта. Таким образом, с завершением каждой итерации продукт получает приращение — ''инкремент'' — к его возможностям, которые, следовательно, развиваются ''эволюционно''. Итеративность, инкрементальность и эволюционность в данном случае есть выражение одного и того же смысла разными словами со слегка разных точек зрения<ref name=mir/>. |
|||
По выражению Т. Гилба, «эволюция — приём, предназначенный для создания видимости стабильности. Шансы успешного создания сложной системы будут максимальными, если она реализуется в серии небольших шагов и если каждый шаг заключает в себе четко определённый успех, а также возможность «отката» к предыдущему успешному этапу в случае неудачи. Перед тем, как пустить в дело все ресурсы, предназначенные для создания системы, разработчик имеет возможность получать из реального мира сигналы обратной связи и исправлять возможные ошибки в проекте»<ref name=IID/>. |
|||
Подход IID имеет и свои отрицательные стороны, которые, по сути, — обратная сторона достоинств. Во-первых, целостное понимание возможностей и ограничений проекта очень долгое время отсутствует. Во-вторых, при итерациях приходится отбрасывать часть сделанной ранее работы. В-третьих, добросовестность специалистов при выполнении работ всё же снижается, что психологически объяснимо, ведь над ними постоянно довлеет ощущение, что «всё равно всё можно будет переделать и улучшить позже»<ref name=mir/>. |
|||
Различные варианты итерационного подхода реализованы в большинстве современных методологий разработки ([[Rational Unified Process|RUP]], [[Microsoft Solutions Framework|MSF]], [[Экстремальное программирование|XP]]). |
|||
=== Спиральная модель === |
|||
'''[[Спиральная модель]]''' ({{lang-en|spiral model}}) была разработана в середине 1980-х годов [[Барри Боэм]]ом. Она основана на классическом [[цикл Деминга|цикле Деминга]] PDCA (plan-do-check-act). При использовании этой модели ПО создается в несколько [[итерация|итераций]] (витков спирали) [[Прототипирование программного обеспечения|методом прототипирования]]. |
|||
Каждая итерация соответствует созданию фрагмента или версии ПО, на ней уточняются цели и характеристики проекта, оценивается качество полученных результатов и планируются работы следующей итерации. |
|||
На каждой итерации оцениваются: |
|||
* риск превышения сроков и стоимости проекта; |
|||
* необходимость выполнения ещё одной итерации; |
|||
* степень полноты и точности понимания требований к системе; |
|||
* целесообразность прекращения проекта. |
|||
Важно понимать, что спиральная модель является не альтернативой эволюционной модели (модели IID), а специально проработанным вариантом. К сожалению, нередко спиральную модель либо ошибочно используют как синоним эволюционной модели вообще, либо (не менее ошибочно) упоминают как совершенно самостоятельную модель наряду с IID<ref name=mir/>. |
|||
Отличительной особенностью спиральной модели является специальное внимание, уделяемое рискам, влияющим на организацию жизненного цикла, и контрольным точкам. Боэм формулирует 10 наиболее распространённых (по приоритетам) рисков: |
|||
# Дефицит специалистов. |
|||
# Нереалистичные сроки и бюджет. |
|||
# Реализация несоответствующей функциональности. |
|||
# Разработка неправильного пользовательского интерфейса. |
|||
# Перфекционизм, ненужная оптимизация и оттачивание деталей. |
|||
# Непрекращающийся поток изменений. |
|||
# Нехватка информации о внешних компонентах, определяющих окружение системы или вовлеченных в интеграцию. |
|||
# Недостатки в работах, выполняемых внешними (по отношению к проекту) ресурсами. |
|||
# Недостаточная производительность получаемой системы. |
|||
# Разрыв в квалификации специалистов разных областей. |
|||
В сегодняшней спиральной модели определён следующий общий набор контрольных точек<ref name=orlik>Орлик С. Введение в программную инженерию и управление жизненным циклом ПО. [http://software-testing.ru/library/around-testing/engineering/267-swebok]</ref>: |
|||
# Concept of Operations (COO) — концепция (использования) системы; |
|||
# Life Cycle Objectives (LCO) — цели и содержание жизненного цикла; |
|||
# Life Cycle Architecture (LCA) — архитектура жизненного цикла; здесь же возможно говорить о готовности концептуальной архитектуры целевой программной системы; |
|||
# Initial Operational Capability (IOC) — первая версия создаваемого продукта, пригодная для опытной эксплуатации; |
|||
# Final Operational Capability (FOC) –— готовый продукт, развернутый (установленный и настроенный) для реальной эксплуатации. |
|||
== Методологии разработки ПО == |
== Методологии разработки ПО == |
Версия от 13:02, 14 ноября 2015
Необходимо перенести в эту статью содержимое статьи Управление жизненным циклом информационных систем и поставить оттуда перенаправление. |
Жизненный цикл программного обеспечения (ПО) — период времени, который начинается с момента принятия решения о необходимости создания программного продукта и заканчивается в момент его полного изъятия из эксплуатации[1]. Этот цикл — процесс построения и развития ПО.
Стандарты жизненного цикла ПО
- ГОСТ 34.601-90
- ISO/IEC 12207:2008 «System and software engineering — Software life cycle processes» (российский аналог — ГОСТ Р ИСО/МЭК 12207-2010 Информационная технология. Системная и программная инженерия. Процессы жизненного цикла программных средств)
Стандарт ГОСТ 34.601-90
Стандарт ГОСТ 34.601-90 предусматривает следующие стадии и этапы создания автоматизированной системы (АС):
- Формирование требований к АС
- Обследование объекта и обоснование необходимости создания АС
- Формирование требований пользователя к АС
- Оформление отчета о выполнении работ и заявки на разработку АС
- Разработка концепции АС
- Изучение объекта
- Проведение необходимых научно-исследовательских работ
- Разработка вариантов концепции АС и выбор варианта концепции АС, удовлетворяющего требованиям пользователей
- Оформление отчета о проделанной работе
- Техническое задание
- Разработка и утверждение технического задания на создание АС
- Эскизный проект
- Разработка предварительных проектных решений по системе и её частям
- Разработка документации на АС и её части
- Технический проект
- Разработка проектных решений по системе и её частям
- Разработка документации на АС и её части
- Разработка и оформление документации на поставку комплектующих изделий
- Разработка заданий на проектирование в смежных частях проекта
- Рабочая документация
- Разработка рабочей документации на АС и её части
- Разработка и адаптация программ
- Ввод в действие
- Подготовка объекта автоматизации
- Подготовка персонала
- Комплектация АС поставляемыми изделиями (программными и техническими средствами, программно-техническими комплексами, информационными изделиями)
- Строительно-монтажные работы
- Пусконаладочные работы
- Проведение предварительных испытаний
- Проведение опытной эксплуатации
- Проведение приёмочных испытаний
- Сопровождение АС.
- Выполнение работ в соответствии с гарантийными обязательствами
- Послегарантийное обслуживание
Эскизный, технический проекты и рабочая документация — это последовательное построение все более точных проектных решений. Допускается исключать стадию «Эскизный проект» и отдельные этапы работ на всех стадиях, объединять стадии «Технический проект» и «Рабочая документация» в «Технорабочий проект», параллельно выполнять различные этапы и работы, включать дополнительные.
Данный стандарт не вполне подходит для проведения разработок в настоящее время: многие процессы отражены недостаточно, а некоторые положения устарели[источник не указан 3267 дней].
Стандарт ГОСТ Р ИСО/МЭК 12207 (ISO/IEC 12207)
Федеральным агентством по техническому регулированию и метрологии РФ 01.03.2012 г. взамен ГОСТ Р ИСО/МЭК 12207-99 принят стандарт ГОСТ Р ИСО/МЭК 12207-2010 «Информационная технология. Системная и программная инженерия. Процессы жизненного цикла программных средств», идентичный международному стандарту ISO/IEC 12207:2008 «System and software engineering — Software life cycle processes».
Данный стандарт, используя устоявшуюся терминологию, устанавливает общую структуру процессов жизненного цикла программных средств, на которую можно ориентироваться в программной индустрии. Стандарт определяет процессы, виды деятельности и задачи, которые используются при приобретении программного продукта или услуги, а также при поставке, разработке, применении по назначению, сопровождении и прекращении применения программных продуктов.
Процессы жизненного цикла ПО
Стандарт группирует различные виды деятельности, которые могут выполняться в течение жизненного цикла программных систем, в семь групп процессов. Каждый из процессов жизненного цикла в пределах этих групп описывается в терминах цели и желаемых выходов, списков действий и задач, которые необходимо выполнять для достижения этих результатов.
- процессы соглашения — два процесса;
- процессы организационного обеспечения проекта — пять процессов;
- процессы проекта — семь процессов;
- технические процессы — одиннадцать процессов;
- процессы реализации программных средств — семь процессов;
- процессы поддержки программных средств — восемь процессов;
- процессы повторного применения программных средств — три процесса.
- Основные:
- Приобретение (действия и задачи заказчика, приобретающего ПО)
- Поставка (действия и задачи поставщика, который снабжает заказчика программным продуктом или услугой)
- Разработка (действия и задачи, выполняемые разработчиком: создание ПО, оформление проектной и эксплуатационной документации, подготовка тестовых и учебных материалов и т. д.)
- Эксплуатация (действия и задачи оператора — организации, эксплуатирующей систему)
- Сопровождение (действия и задачи, выполняемые сопровождающей организацией, то есть службой сопровождения). Сопровождение — внесений изменений в ПО в целях исправления ошибок, повышения производительности или адаптации к изменившимся условиям работы или требованиям.
- Вспомогательные
- Документирование (формализованное описание информации, созданной в течение ЖЦ ПО)
- Управление конфигурацией (применение административных и технических процедур на всем протяжении ЖЦ ПО для определения состояния компонентов ПО, управления его модификациями).
- Обеспечение качества (обеспечение гарантий того, что ИС и процессы ее ЖЦ соответствуют заданным требованиям и утвержденным планам)
- Верификация (определение того, что программные продукты, являющиеся результатами некоторого действия, полностью удовлетворяют требованиям или условиям, обусловленным предшествующими действиями)
- Аттестация (определение полноты соответствия заданных требований и созданной системы их конкретному функциональному назначению)
- Совместная оценка (оценка состояния работ по проекту: контроль планирования и управления ресурсами, персоналом, аппаратурой, инструментальными средствами)
- Аудит (определение соответствия требованиям, планам и условиям договора)
- Разрешение проблем (анализ и решение проблем, независимо от их происхождения или источника, которые обнаружены в ходе разработки, эксплуатации, сопровождения или других процессов)
- Организационные
- Управление (действия и задачи, которые могут выполняться любой стороной, управляющей своими процессами)
- Создание инфраструктуры (выбор и сопровождение технологии, стандартов и инструментальных средств, выбор и установка аппаратных и программных средств, используемых для разработки, эксплуатации или сопровождения ПО)
- Усовершенствование (оценка, измерение, контроль и усовершенствование процессов ЖЦ)
- Обучение (первоначальное обучение и последующее постоянное повышение квалификации персонала)
Каждый процесс включает ряд действий. Например, процесс приобретения охватывает следующие действия:
- Инициирование приобретения
- Подготовка заявочных предложений
- Подготовка и корректировка договора
- Надзор за деятельностью поставщика
- Приёмка и завершение работ
Каждое действие включает ряд задач. Например, подготовка заявочных предложений должна предусматривать:
- Формирование требований к системе
- Формирование списка программных продуктов
- Установление условий и соглашений
- Описание технических ограничений (среда функционирования системы и т. д.)
Стадии жизненного цикла ПО, взаимосвязь между процессами и стадиями
Модель жизненного цикла ПО — структура, определяющая последовательность выполнения и взаимосвязи процессов, действий и задач на протяжении жизненного цикла. Модель жизненного цикла зависит от специфики, масштаба и сложности проекта и специфики условий, в которых система создается и функционирует.
Стандарт ГОСТ Р ИСО/МЭК 12207-2010 не предлагает конкретную модель жизненного цикла. Его положения являются общими для любых моделей жизненного цикла, методов и технологий создания ИС. Он описывает структуру процессов жизненного цикла, не конкретизируя, как реализовать или выполнить действия и задачи, включенные в эти процессы.
Модель ЖЦ ПО включает в себя:
- Стадии;
- Результаты выполнения работ на каждой стадии;
- Ключевые события — точки завершения работ и принятия решений.
Стадия — часть процесса создания ПО, ограниченная определенными временными рамками и заканчивающаяся выпуском конкретного продукта (моделей, программных компонентов, документации), определяемого заданными для данной стадии требованиями.
На каждой стадии могут выполняться несколько процессов, определенных в стандарте ГОСТ Р ИСО/МЭК 12207-2010, и наоборот, один и тот же процесс может выполняться на различных стадиях. Соотношение между процессами и стадиями также определяется используемой моделью жизненного цикла ПО.
Методологии разработки ПО
![]() | Этот раздел не завершён. |
- Rational Unified Process (RUP).
- Microsoft Solutions Framework (MSF). Включает 4 фазы: анализ, проектирование, разработка, стабилизация, предполагает использование объектно-ориентированного моделирования.
- Экстремальное программирование (англ. Extreme Programming, XP). В основе методологии командная работа, эффективная коммуникация между заказчиком и исполнителем в течение всего проекта по разработке ИС. Разработка ведётся с использованием последовательно дорабатываемых прототипов.
- ЕСПД — комплекс государственных стандартов Российской Федерации, устанавливающих взаимосвязанные правила разработки, оформления и обращения программ и программной документации.
Литература
- Братищенко В.В. Проектирование информационных систем. — Иркутск: Изд-во БГУЭП, 2004. — 84 с.
- Вендров А.М. Проектирование программного обеспечения экономических информационных систем. — М.: Финансы и статистика, 2000.
- Грекул В.И., Денищенко Г.Н., Коровкина Н.Л. Проектирование информационных систем. — М.: Интернет-университет информационных технологий - ИНТУИТ.ру, 2005.
- Мишенин А.И. Теория экономических информационных систем. — М.: Финансы и статистика, 2000. — 240 с.
Примечания
- ↑ Стандарт IEEE Std 610.12, Глоссарий