Жизненный цикл программного продукта
Глава 1: Теоретические аспекты программной деятельности.
Жизненный цикл программного обеспечения (ПО) — период времени, который начинается с момента принятия решения о необходимости создания программного продукта и заканчивается в момент его полного изъятия из эксплуатации. Этот цикл — процесс построения и развития ПО. Стандарты жизненного цикла ПО ГОСТ 34.601-90 ISO/IEC 12207:2008 «System and software engineering — Software life cycle processes» (российский аналог — ГОСТ Р ИСО/МЭК 12207-2010 Информационная технология. Системная и программная инженерия. Процессы жизненного цикла программных средств) Стандарт ГОСТ 34.601-90 Стандарт ГОСТ 34.601-90 предусматривает следующие стадии и этапы создания автоматизированной системы: Формирование требований к АС Обследование объекта и обоснование необходимости создания АС Формирование требований пользователя к АС Оформление отчета о выполнении работ и заявки на разработку АС Разработка концепции АС Изучение объекта Проведение необходимых научно-исследовательских работ Разработка вариантов концепции АС и выбор варианта концепции АС, удовлетворяющего требованиям пользователей Оформление отчета о проделанной работе Техническое задание Разработка и утверждение технического задания на создание АС Эскизный проект Разработка предварительных проектных решений по системе и ее частям Разработка документации на АС и ее части Технический проект Разработка проектных решений по системе и ее частям Разработка документации на АС и ее части Разработка и оформление документации на поставку комплектующих изделий Разработка заданий на проектирование в смежных частях проекта Рабочая документация Разработка рабочей документации на АС и ее части Разработка и адаптация программ Ввод в действие Подготовка объекта автоматизации Подготовка персонала Комплектация АС поставляемыми изделиями (программными и техническими средствами, программно-техническими комплексами, информационными изделиями) Строительно-монтажные работы Пусконаладочные работы Проведение предварительных испытаний Проведение опытной эксплуатации Проведение приемочных испытаний Сопровождение АС. Выполнение работ в соответствии с гарантийными обязательствами Послегарантийное обслуживание Эскизный, технический проекты и рабочая документация — это последовательное построение все более точных проектных решений. Допускается исключать стадию «Эскизный проект» и отдельные этапы работ на всех стадиях, объединять стадии «Технический проект» и «Рабочая документация» в «Технорабочий проект», параллельно выполнять различные этапы и работы, включать дополнительные. Данный стандарт не вполне подходит для проведения разработок в настоящее время: многие процессы отражены недостаточно, а некоторые положения устарели. Стандарт ГОСТ Р ИСО/МЭК 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, и наоборот, один и тот же процесс может выполняться на различных стадиях. Соотношение между процессами и стадиями также определяется используемой моделью жизненного цикла ПО. Модели жизненного цикла ПО Водопадная (каскадная, последовательная) модель Основная статья: Модель водопада Водопадная модель жизненного цикла (англ. waterfall model) была предложена в 1970 г. Уинстоном Ройсом. Она предусматривает последовательное выполнение всех этапов проекта в строго фиксированном порядке. Переход на следующий этап означает полное завершение работ на предыдущем этапе. Требования, определенные на стадии формирования требований, строго документируются в виде технического задания и фиксируются на все время разработки проекта. Каждая стадия завершается выпуском полного комплекта документации, достаточной для того, чтобы разработка могла быть продолжена другой командой разработчиков. Этапы проекта в соответствии с каскадной моделью: Формирование требований; Проектирование; Реализация; Тестирование; Внедрение; Эксплуатация и сопровождение. Преимущества: Полная и согласованная документация на каждом этапе; Легко определить сроки и затраты на проект. Недостатки: В водопадной модели переход от одной фазы проекта к другой предполагает полную корректность результата (выхода) предыдущей фазы. Однако неточность какого-либо требования или некорректная его интерпретация в результате приводит к тому, что приходится «откатываться» к ранней фазе проекта и требуемая переработка не просто выбивает проектную команду из графика, но приводит часто к качественному росту затрат и, не исключено, к прекращению проекта в той форме, в которой он изначально задумывался. По мнению современных специалистов, основное заблуждение авторов водопадной модели состоит в предположениях, что проект проходит через весь процесс один раз, спроектированная архитектура хороша и проста в использовании, проект осуществления разумен, а ошибки в реализации легко устраняются по мере тестирования. Эта модель исходит из того, что все ошибки будут сосредоточены в реализации, а потому их устранение происходит равномерно во время тестирования компонентов и системы. Таким образом, водопадная модель для крупных проектов мало реалистична и может быть эффективно использована только для создания небольших систем. Итерационная модель Альтернативой последовательной модели является так называемая модель итеративной и инкрементальной разработки (англ. iterative and incremental development, IID), получившей также от Т. Гилба в 70-е гг. название эволюционной модели. Также эту модель называют итеративной моделью и инкрементальной моделью. Модель IID предполагает разбиение жизненного цикла проекта на последовательность итераций, каждая из которых напоминает «мини-проект», включая все процессы разработки в применении к созданию меньших фрагментов функциональности, по сравнению с проектом в целом. Цель каждой итерации — получение работающей версии программной системы, включающей функциональность, определённую интегрированным содержанием всех предыдущих и текущей итерации. Результат финальной итерации содержит всю требуемую функциональность продукта. Таким образом, с завершением каждой итерации продукт получает приращение — инкремент — к его возможностям, которые, следовательно, развиваются эволюционно. Итеративность, инкрементальность и эволюционность в данном случае есть выражение одного и того же смысла разными словами со слегка разных точек зрения. По выражению Т. Гилба, «эволюция — прием, предназначенный для создания видимости стабильности. Шансы успешного создания сложной системы будут максимальными, если она реализуется в серии небольших шагов и если каждый шаг заключает в себе четко определённый успех, а также возможность «отката» к предыдущему успешному этапу в случае неудачи. Перед тем, как пустить в дело все ресурсы, предназначенные для создания системы, разработчик имеет возможность получать из реального мира сигналы обратной связи и исправлять возможные ошибки в проекте». Подход IID имеет и свои отрицательные стороны, которые, по сути, — обратная сторона достоинств. Во-первых, целостное понимание возможностей и ограничений проекта очень долгое время отсутствует. Во-вторых, при итерациях приходится отбрасывать часть сделанной ранее работы. В-третьих, добросовестность специалистов при выполнении работ всё же снижается, что психологически объяснимо, ведь над ними постоянно довлеет ощущение, что «всё равно всё можно будет переделать и улучшить позже». Различные варианты итерационного подхода реализованы в большинстве современных методологий разработки (RUP, MSF, XP). Спиральная модель Спиральная модель (англ. spiral model) была разработана в середине 1980-х годов Барри Боэмом. Она основана на классическом цикле Деминга PDCA (plan-do-check-act). При использовании этой модели ПО создается в несколько итераций (витков спирали) методом прототипирования. Каждая итерация соответствует созданию фрагмента или версии ПО, на ней уточняются цели и характеристики проекта, оценивается качество полученных результатов и планируются работы следующей итерации. На каждой итерации оцениваются: риск превышения сроков и стоимости проекта; необходимость выполнения ещё одной итерации; степень полноты и точности понимания требований к системе; целесообразность прекращения проекта. Важно понимать, что спиральная модель является не альтернативой эволюционной модели (модели IID), а специально проработанным вариантом. К сожалению, нередко спиральную модель либо ошибочно используют как синоним эволюционной модели вообще, либо (не менее ошибочно) упоминают как совершенно самостоятельную модель наряду с IID[3]. Отличительной особенностью спиральной модели является специальное внимание, уделяемое рискам, влияющим на организацию жизненного цикла, и контрольным точкам. Боэм формулирует 10 наиболее распространённых (по приоритетам) рисков: Дефицит специалистов. Нереалистичные сроки и бюджет. Реализация несоответствующей функциональности. Разработка неправильного пользовательского интерфейса. Перфекционизм, ненужная оптимизация и оттачивание деталей. Непрекращающийся поток изменений. Нехватка информации о внешних компонентах, определяющих окружение системы или вовлеченных в интеграцию. Недостатки в работах, выполняемых внешними (по отношению к проекту) ресурсами. Недостаточная производительность получаемой системы. Разрыв в квалификации специалистов разных областей. В сегодняшней спиральной модели определён следующий общий набор контрольных точек: Concept of Operations (COO) — концепция (использования) системы; Life Cycle Objectives (LCO) — цели и содержание жизненного цикла; Life Cycle Architecture (LCA) — архитектура жизненного цикла; здесь же возможно говорить о готовности концептуальной архитектуры целевой программной системы; Initial Operational Capability (IOC) — первая версия создаваемого продукта, пригодная для опытной эксплуатации; Final Operational Capability (FOC) –— готовый продукт, развернутый (установленный и настроенный) для реальной эксплуатации.
|
