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

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

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

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

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

Недостатки этой модели:

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

При применении каскадной модели могут иметь место следующие факторы риска:

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

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

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

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

2.2.2. Инкрементная модель ЖЦ

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

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

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

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

При применении данной модели необходимо учитывать следующие факторы риска:

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

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

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

Глава 2. Спецификация программного продукта

Выбор жизненного цикла программного продукта

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

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

Модели жизненного цикла ПП

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

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

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

• Формирование требований;
• Проектирование;
• Реализация;
• Тестирование;
• Внедрение;
• Эксплуатация и сопровождение.

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

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

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

Недостатки:

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

2. Итерационная модель.

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

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

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

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

3. V-образная модель.

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

4. Модель быстрого прототипирования.

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

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

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

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

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

5. Спиральная модель.

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

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

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

• риск превышения сроков и стоимости проекта;
• необходимость выполнения ещё одной итерации;
• степень полноты и точности понимания требований к системе;
• целесообразность прекращения проекта.

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

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

Определение целей, альтернативных вариантов и ограничений.

Оценка альтернативных вариантов, идентификация и разрешение рисков.

Разработка продукта следующего уровня.

Планирование следующей фазы.

«Раскручивание» проекта начинается с анализа общей постановки задачи на разработку ПО. Здесь на первой фазе определяются общие цели, устанавливаются предварительные ограничения, определяются возможные альтернативы подходов к решению задачи. Далее проводится оценка подходов, устанавливаются их риски. На шаге разработки создается концепция (видение) продукта и путей его создания. Следующий цикл начинается с планирования требований и деталей ЖЦ продукта для оценки затрат. На фазе определения целей устанавливаются альтернативные варианты требований, связанные с аранжировкой требований по важности и стоимости их выполнения. На фазе оценки устанавливаются риски вариантов требований. На фазе разработки спецификация требований (с указанием рисков и стоимости), готовится демо-версия ПО для анализа требований заказчиком.

Следующий цикл – разработка проекта – начинается с планирования разработки.

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

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

Фаза разработки выполняется по каскадной модели с выходом – действующим вариантом (прототипом) продукта.

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

• До начала разработки ПО, есть несколько полных циклов анализа требований и проектирования.
• Количество циклов модели (как в части анализа и проектирования, так и в части реализации) не ограничено и определяется сложностью и объемом задачи
• В модели предполагаются возвраты на оставленные варианты при изменении стоимости рисков.

Спиральная модель (по отношению к каскадной) имеет следующие преимущества:

• Более тщательное проектирование (несколько начальных итераций) с оценкой результатов проектирования, что позволяет выявить ошибки проектирования на более ранних стадиях.
• Поэтапное уточнение требований в процессе выполнения итераций, что позволяет более точно удовлетворить требованиям заказчика
• Участие заказчика в выполнении проекта с использованием прототипов программы. Заказчик видит, что и как создается, не выдвигает необоснованных требований, оценивает реальные объемы финансирования.
• Планирование и управление рисками при переходе на следующие итерации позволяет разумно планировать использование ресурсов и обосновывать финансирование работ.
• Возможность разработки сложного проекта «по частям», выделяя на первых этапах наиболее значимые требования.

Основные недостатки спиральной модели связаны с ее сложностью:

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

Спиральную модель целесообразно применять при следующих условиях:

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

Лекция 2.

Понятие жизненного цикла и модели жизненного цикла. Каскадная модель ЖЦ. Поэтапная модель с промежуточным контролем. Спиральная модель ЖЦ . Процессы ЖЦ ПО . Rapid Application Development(RAD). Extreme Programming (XP). Rational Unified Process (RUP). Microsoft Solution Framework (MSF). Custom Development Method (методика Oracle).

2.1. Понятие жизненного цикла и модели жизненного цикла

Жизненный цикл ИС – период времени, который начинается с момента принятия решения о необходимости создания ИС и заканчивается в момент ее полного изъятия из эксплуатации. ЖЦ ИС можно представить как ряд событий, происходя­щих с системой в процессе ее создания и использования.

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

Модель ЖЦ ПО включает в себя (слайд 3) :стадии, результаты выполнения работ на каждой стадии, ключевые события - точки завершения работ и принятия решений.

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

Крайним случаем модели ЖЦ можно считать так называемую модель «черного ящика» (black box) или «code and fix» (кодиро­вание и исправление), что фактически означает отсутствие ка­кой-либо модели. В этом случае выделить какие-либо рациональные стадии в процессе разработки ПО не представля­ется возможным, поскольку отсутствует планирование и органи­зации работ.

В настоящее время известны и используются следующие модели жизненного цикла:

Каскадная модель (характерна для периода 1970-1980 гг.);

Поэтапная модель с промежуточным контролем (характерна для периода 1980-1985 гг.);

Спиральная модель (характерна для периода после 1986 г.)

2.2. Каскадная модель жц

В1970 г. эксперт в области ПО Уинстон Ройс опубликовал по­лучившую широкую известность статью, в которой он излагал свое мнение о методике, которая позднее получила название «модель водопада» (waterfall model), или «каскадная модель» (слайд 4) .

Впосле­дствии эта модель была регламентирована множеством норма­тивных документов, в частности, широко известным стандартом Министерства обороны США Dod-STD-2167A и российскими стандартами серии ГОСТ 34.

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

Принципиальными свойствами так называемой «чистой» каскадной модели являются следующие:

Фиксация требований к системе до ее сдачи заказчику;

Последовательное выполнение этапов.

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

Отсутствие временного перекрытия этапов

Отсутствие возврата к предыдущим этапам

Наличие результата только в конце разработки.

Преимущества применения каскадной модели заключаются в следующем:

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

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

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

Другими недостатками каскадного подхода являются:

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

выход из календарного графика, запаздывание с получени­ем результатов;

избыточное количество документации;

невозможность разбить систему на части (весь продукт раз­рабатывается за один раз);

высокий риск создания системы, не удовлетворяющей из­менившимся потребностям пользователей.

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

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

Разработка ПО имеет следующие специфические особенности:

неформальный характер требований к ПО и формализованный основной объект разработки – программы;

творческий характер разработки;

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

при своем использовании (эксплуатации) ПО не расходуется и не изнашивается;

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

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

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

В качестве примеров деятельностей, которые нужно проводить для построения программной системы, можно привести проектирование – выделение отдельных модулей и определение связей между ними с целью минимизации зависимостей между частями проекта и достижения лучшей его обозримости в целом,кодирование – разработку кода отдельных модулей, разработку пользовательской документации, которая необходима для достаточно сложной системы. Инженерия ПО (softwareengineering) – совокупность инженерных методов и средств создания ПО. Фундаментальная идея программной инженерии: проектирование ПО является формальным процессом, который можно изучать и совершенствовать.

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

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

системы должны создаваться в короткие сроки и соответствовать требованиям заказчика на момент внедрения;

качество ПО должно быть высоким;

разработка ПО должна быть осуществлена в рамках выделенного бюджета;

системы должны работать на оборудовании заказчика, а также взаимодействовать с имеющемся ПО;

системы должны быть легко сопровождаемыми и масштабируемыми

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

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

Основным понятием программной инженерии является понятие жизненного цикла ПО .

Жизненный цикл (ЖЦ ) ПО (softwarelifecycle) – этот период времени, который начинается с момента принятия решения о необходимости создания ПО и заканчивается в момент его полного изъятия из эксплуатации.

С точки зрения статической структуры ЖЦ является совокупностью процессов ЖЦ.

Процесс ЖЦ – набор взаимосвязанных действий, преобразующих некоторые входные данные и ресурсы в выходные.

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

основные (приобретение, поставка, разработка, эксплуатация, сопровождение);

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

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

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

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

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

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

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

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

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

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

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

каскадная (водопадная);

эволюционная;

основанная на формальных преобразованиях;

итерационные (пошаговая и спиральная).

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

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

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

Реализация или кодирование включает процессы создания текстов программ на языках программирования.

На этапе тестирования производится собственно тестирование, а также отладка и оценка качества ПО.

Ввод в действие – это развертывание ПО на целевой вычислительной системе, обучение пользователей и т.п.

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

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

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

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

Особенности эволюционной модели : поэтапное уточнение требований к ПО с помощью прототипирования; параллельное осуществление анализа требований, разработки и верификации. Достоинства: полный учет требований заказчика, большее его участие в проекте; равномерная нагрузка на группу; раннее обнаружение проблем и их разрешение по мере возникновения. Недостатки: плохая документированность; запутанность создаваемого ПС и сложность внесения изменений; сложность планирования; необходимость специальных средств и технологий разработки ПС; годится лишь для небольших ПС (не более 50 Килострок).

Схема эволюционной модели ЖЦ

Особенности модели ЖЦ, основанной на формальных преобразованиях : использование специальных нотаций для формального описания требований; кодирование и тестирование заменяется процессом предобразования формальной спецификации в исполняемую программу. Достоинства: формальные методы гарантируют соответствие ПО спецификациям требований к ПО, т. о. вопросы надежности и безопасности решаются сами собой. Недостатки: большие системы сложно описать формальными спецификациями; требуются специально подготовленные и высококвалифицированные разработчики; есть зависимость от средств разработки и нотации спецификаций.

Особенности итерационных моделей :

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

модель напоминает несколько последовательных «каскадов»;

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

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

Рис. 3.1.3.-1 Схема пошаговой итерационной модели ЖЦ.

Особенности итерационной спиральной модели :

общая структура действий на каждой итерации – планирование, определение задач, ограничений и вариантов решений, оценка предложенных решений и рисков, выполнение основных работ итерации и оценка их результатов;

решение о начале новой итерации принимается на основе результатов предыдущей;

досрочное прекращение проекта в случае обнаружения его нецелесообразности.

Достоинства итерационных моделей:

полный учет требований заказчика, большее его участие в проекте;

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

Недостатки итерационных моделей: сложность планирования; плохая документированность создаваемого ПО.

Рис. 3.1.3.-2 Схема спиральной модели ЖЦ

Проблемой современной программной инженерии являются «тяжелые» процессы. Характеристики «тяжелого» процесса :

необходимость документировать каждое действие разработчиков;

множество рабочих продуктов (в первую очередь - документов), создаваемых в бюрократической атмосфере;

отсутствие гибкости;

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

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

Диалог «лицом к лицу» – самый эффективный способ обмена информацией.

Избыточная «тяжесть» технологии (дополнительные рабочие продукты, планы, диаграммы, документы) стоит дорого.

Более многочисленные команды требуют более «тяжелых» технологий.

Большая «тяжесть» процесса подходит для проектов с большей критичностью.

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

Дисциплина, умение и понимание противостоят процессу, формальности и документированию.

Потеря эффективности в некритических видах деятельности вполне допустима.

Под критичностью понимаются масштабы последствий отказа разрабатываемого ПО. Уровни критичности:

потеря удобства;

потеря важных данных и/или рабочего времени;

потеря невозместимых средств, дорогостоящего оборудования;

потеря человеческой жизни.

Основные направления развития современной программной инженерии:

Управление требованиями

Управление конфигурацией и изменениями

Управление качеством ПО

Итерационная разработка ПО

Использование компонентной архитектуры (объектно-ориентированный подход)

Визуальное моделирование ПО

Методология проектирования информационных систем описывает процесс создания и сопровождения систем в виде жизненного цикла (ЖЦ) ИС, представляя его как некоторую последовательность стадий и выполняемых на них процессов. Для каждого этапа определяются состав и последовательность выполняемых работ , получаемые результаты, методы и средства, необходимые для выполнения работ , роли и ответственность участников и т.д. Такое формальное описание ЖЦ ИС позволяет спланировать и организовать процесс коллективной разработки и обеспечить управление этим процессом.

Жизненный цикл ИС можно представить как ряд событий, происходящих с системой в процессе ее создания и использования.

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

В настоящее время известны и используются следующие модели жизненного цикла :

• Каскадная модель ( рис. 2.1) предусматривает последовательное выполнение всех этапов проекта в строго фиксированном порядке. Переход на следующий этап означает полное завершение работ на предыдущем этапе.
• ( рис. 2.2). Разработка ИС ведется итерациями с циклами обратной связи между этапами. Межэтапные корректировки позволяют учитывать реально существующее взаимовлияние результатов разработки на различных этапах; время жизни каждого из этапов растягивается на весь период разработки.
• Спиральная модель ( рис. 2.3). На каждом витке спирали выполняется создание очередной версии продукта, уточняются требования проекта, определяется его качество и планируются работы следующего витка.Особое внимание уделяется начальным этапам разработки - анализу и проектированию, где реализуемость тех или иных технических решений проверяется и обосновывается посредством создания прототипов ( макетирования ).

Рис. 2.1.

Рис. 2.2.

Рис. 2.3.

На практике наибольшее распространение получили две основные модели жизненного цикла :

• каскадная модель (характерна для периода 1970-1985 гг.);
• спиральная модель (характерна для периода после 1986.г.).

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

Можно выделить следующие положительные стороны применения каскадного подхода:

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

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

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

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

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

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