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

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

Следует отметить, что в Советском Союзе, а затем в России создание программного обеспечения ( ПО ) первоначально, в 70-е годы прошлого столетия, регламентировалось стандартами ГОСТ ЕСПД (Единой системы программной документации – серии ГОСТ 19.ХХХ), которые были ориентированы на класс относительно простых программ небольшого объема, создаваемых отдельными программистами. В настоящее время эти стандарты устарели концептуально и по форме, их сроки действия закончились и использование нецелесообразно.

Процессы создания автоматизированных систем ( АС ), в состав которых входит и ПО , регламентированы стандартами ГОСТ 34.601-90 "Информационная технология. Комплекс стандартов на автоматизированные системы. Стадии создания", ГОСТ 34.602-89 "Информационная технология. Комплекс стандартов на автоматизированные системы. Техническое задание на создание автоматизированной системы" и ГОСТ 34.603-92 "Информационная технология. Виды испытаний автоматизированных систем". Однако многие положения этих стандартов устарели, а другие отражены недостаточно, чтобы их можно было применять для серьезных проектов создания ПС. Поэтому в отечественных разработках целесообразно использовать современные международные стандарты.

В соответствии со стандартом ISO / IEC 12207 все процессы ЖЦ ПО разделены на три группы (рис.5.1).

Рис. 5.1.

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

5.2. Основные процессы ЖЦ ПС

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

1. инициирование приобретения;
2. подготовку заявочных предложений;
3. подготовку и корректировку договора;
4. надзор за деятельностью поставщика;
5. приемку и завершение работ.

Инициирование приобретения включает следующие задачи:

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

Заявочные предложения должны содержать:

1. требования, предъявляемые к системе;
2. перечень программных продуктов;
3. условия приобретения и соглашения;
4. технические ограничения (например, по среде функционирования системы).

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

Подготовка и корректировка договора включает следующие задачи:

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

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

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

1. инициирование поставки;
2. подготовку ответа на заявочные предложения;
3. подготовку договора;
4. планирование работ по договору;
5. выполнение и контроль договорных работ и их оценку;
6. поставку и завершение работ.

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

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

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

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

1. подготовительную работу;
2. анализ требований, предъявляемых к системе;
3. проектирование архитектуры системы;
4. анализ требований, предъявляемых к программному обеспечению;
5. проектирование архитектуры программного обеспечения;
6. детальное проектирование программного обеспечения;
7. кодирование и тестирование программного обеспечения;
8. интеграцию программного обеспечения;
9. квалификационное тестирование программного обеспечения;
10. интеграцию системы;
11. квалификационное тестирование системы;
12. установку программного обеспечения;
13. приемку программного обеспечения.

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

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

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

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

1. функциональных возможностей, включая характеристики производительности и среды функционирования компонента;
2. внешних интерфейсов;
3. спецификаций надежности и безопасности;
4. эргономических требований;
5. требований к используемым данным;
6. требований к установке и приемке;
7. требований к пользовательской документации;
8. требований к эксплуатации и сопровождению.

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

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

1. трансформацию требований к ПО в архитектуру, определяющую на высоком уровне структуру ПО и состав его компонентов;
2. разработку и документирование программных интерфейсов ПО и баз данных (БД);
3. разработку предварительной версии пользовательской документации;
4. разработку и документирование предварительных требований к тестам и плана интеграции ПО.

Детальное проектирование ПО включает следующие задачи:

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

Кодирование и тестирование ПО включает следующие задачи:

1. кодирование и документирование каждого компонента ПО и базы данных, а также подготовку совокупности тестовых процедур и данных для их тестирования;
2. тестирование каждого компонента ПО и БД на соответствие предъявляемым к ним требованиям с последующим документированием результатов тестирования;
3. обновление документации (при необходимости);
4. обновление плана интеграции ПО.

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

Квалификационное тестирование ПО проводится разработчиком в присутствии заказчика (

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

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

   1. планирование действий и работ, выполняемых в процессе эксплуатации, и установка эксплуатационных стандартов;
   2. определение процедур локализации и разрешения проблем, возникающих в процессе эксплуатации.
2. Эксплуатационное тестирование, осуществляемое для каждой очередной редакции программного продукта, после чего эта редакция передается в эксплуатацию.
3. Собственно эксплуатация системы, которая выполняется в предназначенной для этого среде в соответствии с пользовательской документацией.
4. анализ проблем и запросов на модификацию ПО (анализ сообщений о возникшей проблеме или запроса на модификацию, оценка масштаба, стоимости модификации, получаемого эффекта, оценка целесообразности модификации);
5. модификацию ПО (внесение изменений в компоненты программного продукта и документацию в соответствии с правилами процесса разработки);
6. проверку и приемку (в части целостности модифицируемой системы);
7. перенос ПО в другую среду (конвертирование программ и данных, параллельная эксплуатация ПО в старой и новой среде в течение некоторого периода времени);
8. снятие ПО с эксплуатации по решению заказчика при участии эксплуатирующей организации, службы сопровождения и пользователей. При этом программные продукты и документации подлежат архивированию в соответствии с договором.

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

Этапы жизненного цикла :

2. Проектирование

3. Реализация

4. Сборка, тестирование, испытание

5. Внедрение (выпуск)

6. Сопровождение

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

2) ПО разрабатывается для рынка. Нужно проводить маркетинговые исследования и найти какого продукта на рынке нет. Это связано с большим риском. Цель – разработка спецификации требований.

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

Цель – определение общей структуры (архитектуры) ПО. Результат – спецификация ПО. Эту работу выполняет системный программист.

Реализация

Написание программного кода. Реализация включает и разработку, и тестирование, и документацию.

Сборка, тестирование, испытние

Сборка всего, что сделано разными программистами. Тестирование всего программного комплекса. Отладка – поиск и устранение причин ошибок. Испытание – уточнение технических характеристик. В результате – гарантия работоспособносит программы.

Внедрение (выпуск)

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

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

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

Сопровождение

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

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

1. Waterfall («водопад», каскадная модель)

2. Прототипирование

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

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

Задача разделяется на подзадачи и определяется очередность их реализации т.о., чтобы каждая следующая подзадачи расширяла возможности ПО. Успех существенно зависит от того сколь удачно разделены задачи на подзадачи и как выбрана очередность. Преимущества: 1) возможность активного участия заказчика в разработке, он имеет возможность уточнить свои требования в ходе разработки; 2) возможность тестирования вновь разрабатываемых частей совместно с ранее разработанными, это уменьшит затраты на комплексную отладку; 3) во время разработки можно начинать внедрение по частям.

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

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

Основным нормативным документом, регламентирующим ЖЦ ПО, является международный стандарт ISO/IEC 12207 (ISO - International Organization of Standardization - Международная организация по стандартизации, IEC - International Electrotechnical Commission - Международная комиссия по электротехнике). Он определяет структуру ЖЦ, содержащую процессы, действия и задачи, которые должны быть выполнены во время создания ПО. В данном стандарте ПО (программный продукт) определяется как набор компьютерных программ, процедур и, возможно, связанной с ним документации и данных. Процесс определяется как совокупность взаимосвязанных действий, преобразующих некоторые входные данные в выходные. Каждый процесс характеризуется определенными задачами и методами их решения, исходными данными, полученными от других процессов, и результатами.

Структура ЖЦ ПО по стандарту ISO/IEC 12207 базируется на трех группах процессов:

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

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

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

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

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

1. Каскадная модель (до 70-х годов XX в) определяет последовательный переход на следующий этап после завершения предыдущего.

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

Достоинство : хорошие показатели по срокам разработки и надежности при решении отдельных задач.

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

2. Итерационная модель (70-80-е годы XX в.) соответствует технологии проектирования «снизу - вверх». Допускает итерационные возвраты на предыдущие этапы после выполнения очередного этапа;

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

Достоинство: возможность оперативно вносить коррективы в проект.

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

3. Спиральная модель (80-90-е годы XX в.) соответствует технологии проектирования «сверху - вниз». Предполагает использование программного прототипа, допускающего программное расширение. Проект системы циклически повторяет путь от детализации требований к детализации программного кода.

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

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

Достоинства:

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

2. сокращение сроков проектирования;

3. упрощение создания проектной документации.

Недостаток: высокие требования к качеству общесистемного репозитория (общей базы проектных данных).

Спиральная модель лежит в основе технологии быстрой разработки приложений или RAD-технологии (rapid application development), которая предполагает активное участие конечных пользователей будущей системы в процессе ее создания. Основные стадии информационного инжиниринга следующие:

· Анализ и планирование информационной стратегии. Пользователи вместе со специалистами-разработчиками участвуют в идентификации проблемной области.

· Проектирование. Пользователи под руководством разработчиков принимают участие в техническом проектировании.

· Конструирование. Разработчики проектируют рабочую версию ПО с использованием языков 4-го поколения;

· Внедрение. Разработчики обучают пользователей работе в среде новой ПО.

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

Жизненный цикл что это такое в формальном понимании?

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

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

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

Начальные требования

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

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

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

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

• ГОСТ 34.601-90;
• ISO/IEC 12207:2008;
• Oracle CDM.

Для второго международного стандарта имеется российский аналог. Это ГОСТ Р ИСО/МЭК 12207-2010, отвечающий за системную и программную инженерию. Но жизненный цикл программного обеспечения, описываемый в обоих правилах, является идентичным по сути. Объясняется это достаточно просто.

Виды ПО и апдейты

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

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

Пример на основе программы FL Studio

Изначально виртуальная студия-секвенсор FL Studio имела название Fruity Loops. Жизненный цикл ПО в его первичной модификации истек, но приложение несколько трансформировалось и приобрело нынешний вид.

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

• создание барабанного модуля по типу ритм-машин вроде Yamaha RX, но с применением one-shot-сэмплов или секвенций в формате WAV, записанных в студиях вживую;
• интеграция в операционные системы Windows;
• возможность экспорта проекта в форматах WAV, MP3 и OGG;
• совместимость проектов с дополнительным приложением Fruity Tracks.

На стадии разработки были применены средства языков программирования «Си». Но платформа выглядела достаточно примитивно и не давала конечному пользователю необходимого качества звучания.

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

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

Этим не ограничилось. На стадии управления проектом была введена поддержка подключения плагинов формата VST (сначала второй, а потом и третьей версии), в свое время разработанного компанией Steinberg. Грубо говоря, любой виртуальный синтезатор, поддерживающий VST-host мог подключаться к программе.

Неудивительно, что вскоре любой композитор мог использовать аналоги «железных» моделей, например, полные комплекты звуков некогда популярного Korg M1. Дальше - больше. Применение модулей вроде Addictive Drums или универсального плагина Kontakt позволило воспроизводить живые звуки реальных инструментов, записанных со всеми оттенками артикуляции в профессиональных студиях.

При этом разработчики постарались добиться и максимального качества, создав поддержку для драйверов ASIO4ALL, которые оказались на голову выше режима Full Duplex. Соответственно, повысился и битрейт. На сегодняшний день качество экспортируемого звукового файла может составлять 320 кбит/с при частоте дискретизации 192 кГц. А это профессиональный звук.

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

Перспективы развития

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

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

Даже в случае с ОС Windows такие тенденции можно заметить невооруженным взглядом. Вряд ли сегодня найдется хоть один юзер, использующий системы вроде модификаций 3.1, 95, 98 или Millennium. Их жизненный цикл закончился после выхода версии XP. Но вот серверные версии на основе технологий NT все еще актуальны. Даже Windows 2000 на сегодняшний день является не только весьма актуальной, но и по некоторым параметрам установки или безопасности даже превосходящей самые новые разработки. То же самое касается системы NT 4.0, а также специализированной модификации Windows Server 2012.

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

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

Некоторые дополнительные вопросы

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

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

Но в компьютерных технологиях сегодня отдается предпочтение развитию автоматизированных систем управления (АСУ), которые применяются на производстве. Даже операционные системы, в сравнении со специализированными программами, проигрывают.

Те же среды на основе Visual Basic остаются намного более популярными, нежели Windows-системы. А о прикладном ПО под UNIX-системы речь не идет вообще. Что говорить, если практически все коммуникационные сети тех же Соединенных Штатов работают исключительно на них. Кстати, системы вроде Linux и Android тоже изначально создавались именно на этой платформе. Поэтому, скорее всего, у UNIX перспектив намного больше, чем у остальных продуктов вместе взятых.

Вместо итога

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

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

К тому же, иногда жизненные циклы могут зависеть от актуальности средств разработки. Если, допустим, какой-то язык программирования устаревает, никто же не будет писать программы на его основе, и уж тем более - внедрять их в автоматизированные системы управления на производстве. Тут уже на первый план выходят даже не программисты, а маркетологи, которые должны своевременно реагировать на изменения компьютерного рынка. И таких специалистов в мире найдется не так уж и много. Высококвалифицированные кадры, способные держать руку на пульсе рынка, становятся наиболее востребованными. И именно они зачастую являются так называемыми «серыми кардиналами», от которых зависит успех или проигрыш определенного программного продукта в сфере IT.

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

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

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

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

Тема: Классические и гибкие модели ЖЦПП: определение, описание, отличительные особенности, последовательность этапов. Методы выбора модели ЖЦПП при разработке ПО различных предметных областей.

Модели и стадии ЖЦ ПО

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

Стандарт ISO / IEC 12207 не предлагает конкретную модель ЖЦ и методы разработки ПО . Его положения являются общими для любых моделей ЖЦ, методов и технологий разработки ПО . Стандарт описывает структуру процессов ЖЦ ПО , но не конкретизирует, как реализовать или выполнить действия и задачи, включенные в эти процессы.

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

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

1. формирование требований к ПО;
2. проектирование (разработка системного проекта);
3. реализация (может быть разбита на подэтапы: детальное проектирование, кодирование);
4. тестирование (может быть разбито на автономное и комплексное тестирование и интеграцию);
5. ввод в действие (внедрение);
6. эксплуатация и сопровождение;
7. снятие с эксплуатации.

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

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

Стадия формирования требований к ПО включает следующие этапы.

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

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

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

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

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

Стадия проектирования включает следующие этапы.

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

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

2. Разработка детального (технического) проекта. На этом этапе осуществляется собственно проектирование ПО, включающее проектирование архитектуры системы и детальное проектирование. Таким образом, дается ответ на вопрос: "Как построить систему, чтобы она удовлетворяла требованиям?"

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

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

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

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

1. Разработка верифицированной детальной спецификации каждой подпрограммы (блока не более чем из 100 исходных команд языка высокого уровня).

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

   • имя модуля - указывается имя, применяемое для вызова модуля (для модуля с несколькими входами для каждого входа должны быть отдельные спецификации);
   • функция – дается определение функции или функций, выполняемых модулем;
   • список параметров (число и порядок следования), передаваемых модулю;
   • входные параметры – точное описание всех данных, возвращаемых модулем (должно быть определено поведение модуля при любых входных условиях);
   • внешние эффекты (печать сообщения, чтение запроса с терминала и т. п.).
2. Проектирование логики модулей и программирование (кодирование) модулей.
3. Проверка правильности модулей.
4. Тестирование модулей.
5. Описание базы данных до уровня отдельных параметров, символов и битов.
6. План приемных испытаний.
7. Руководство пользователю.
8. Предварительный план комплексирования и отладки. Содержание последующих стадий в основном совпадает с соответствующими процессами ЖЦ ПО. Вообще технологические стадии выделяются исходя из соображений разумного и рационального планирования и организации работ. Возможный вариант взаимосвязи и стадий работ с процессами ЖЦ ПО показан на рисунке.

Рис. 1.

Виды моделей ЖЦ ПО

Каскадная модель (классический жизненный цикл)

Эта модель обязана своим появлением У. Ройсу (1970 г.). Модель имеет и другое название – водопад (waterfall). Особенность модели – переход на следующую ступень осуществляется только после того, как будет полностью завершена работа на предыдущей стадии; возвратов на пройденные стадии не предусматривается.

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

Преимущества каскадной модели :

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

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

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

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

Итерационная модель ЖЦ ПС

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

В итерационной модели недостатки проектирования и программирования могут быть устранены позже путем частичного возврата на предыдущую стадию. Чем ниже уровень обнаружения ошибки, тем дороже ее исправление. Если стоимость усилий, необходимых для обнаружения и устранения ошибок на стадии написания кода, принять за единицу, то стоимость выявления и устранения ошибки на стадии выработки требований будет в 5-10 раз меньше, а стоимость выявления и устранения ошибки на стадии сопровождения – в 20 раз больше.

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

Макетирование

Часто заказчик не может сформулировать требования по вводу, обработке или выводу данных для будущего программного продукта. Разработчик может сомневаться в приспособленности продукта к операционной системе, в форме диалога с пользователем или эффективности алгоритма. В таких случаях целесообразно использовать макетирование. Основная цель макетирования – снять неопределенность в требованиях заказчика. Макетирование (прототипирование) – процесс создания модели требуемого продукта.

Модель может принимать следующие формы.

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

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

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

Достоинства макетирования – возможность обеспечения определения полных требований к системе. Недостатки макетирования:

• заказчик может принять макет за продукт;
• разработчик может принять макет за продукт.

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

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

Прежде чем рассматривать другие модели ЖЦ ПО, которые пришли на смену каскадной модели , следует остановиться на стратегиях конструирования программных систем. Именно стратегия конструирования ПО во многом определяет модель ЖЦ ПО.

Стратегии конструирования ПО

Существует три стратегии конструирования программных систем:

• однократный проход (каскадная стратегия, рассмотренная выше) – линейная последовательность этапов конструирования;
• инкрементная стратегия. В начале процесса определяются все пользовательские и системные требования, оставшаяся часть конструирования выполняется в виде последовательности версий. Первая версия реализует часть запланированных возможностей, следующая версия реализует дополнительные возможности и т. д., пока не будет получена полная система;
• эволюционная стратегия. Система также строится в виде последовательности версий, но в начале процесса определяются не все требования. Требования уточняются в результате разработки версий. Характеристики стратегий конструирования ПО с соответствии с требованиями стандарта IEEE/EIA 12207 приведены в таблице 1.

Инкрементная модель

Инкрементная модель является классическим примером инкрементной стратегии конструирования. Она объединяет элементы последовательной водопадной модели с итерационной философией макетирования (предложена Б. Боэмом как усовершенствование каскадной модели ). Каждая линейная последовательность здесь вырабатывает поставляемый инкремент ПО. Например, ПО для обработки слов в 1-м инкременте (версии) реализует функции базовой обработки файлов, функции редактирования и документирования; во 2-м инкременте – более сложные возможности редактирования и документирования; в 3-м инкременте – проверку орфографии и грамматики; в 4-м инкременте – возможности компоновки страницы.

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

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

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

Спиральная модель ЖЦ ПО

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

1. Планирование – определение целей, вариантов и ограничений.
2. Анализ риска – анализ вариантов и распознавание/выбор риска.
3. Конструирование – разработка продукта следующего уровня.
4. Оценивание – оценка заказчиком текущих результатов конструирования.

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

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

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

Эти действия пронумерованы и имеют следующее содержание:

1. – начальный сбор требований и планирование проекта;
2. – та же работа, но на основе рекомендаций заказчика;
3. – анализ риска на основе начальных требований;
4. – анализ риска на основе реакции заказчика;
5. – переход к комплексной системе;
6. – начальный макет системы;
7. – следующий уровень макета;
8. – сконструированная система;
9. – оценивание заказчиком.

Достоинства спиральной модели :

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

Недостатки спиральной модели :

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

Модель спирального процесса разработки является наиболее распространенной в настоящее время. Самыми известными ее вариантами являются RUP (Rational Unified Process) от фирмы Rational и MSF (Microsoft Solution Framework). В качестве языка моделирования используется язык UML (Unified Modeling Language). Создание системы предполагается проводить итерационно, двигаясь по спирали и, проходя через одни и те же стадии, на каждом витке уточнять характеристики будущего продукта. Казалось бы, теперь все хорошо: и планируется только то, что можно предвидеть, разрабатывается то, что запланировано, и пользователи начинают знакомиться с продуктом заранее, имея возможность внести необходимые коррективы.

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

Рациональный унифицированный процесс

Рациональный унифицированный процесс (Rational Unified Process, RUP) – одна из лучших методологий разработки программного обеспечения. Основываясь на опыте многих успешных программных проектов, RUP позволяет создавать сложные программные системы, основываясь на индустриальных методах разработки. Предпосылки для разработки RUP зародились в начале 1980-х гг. в Rational Software corporation. В начале 2003 г. Rational приобрела IBM. Одним из основных столпов, на которые опирается RUP, является процесс создания моделей при помощи унифицированного языка моделирования (UML).

RUP – одна из спиральных методологий разработки программного обеспечения. Методология поддерживается и развивается компанией Rational Software. В качестве языка моделирования в общей базе знаний используется язык Unified Modelling Language (UML). Итерационная и инкрементная разработка программного обеспечения в RUP предполагает разделение проекта на несколько проектов, которые выполняются последовательно, и каждая итерация разработки четко определена набором целей, которые должны быть достигнуты в конце итерации. Конечная итерация предполагает, что набор целей итерации должен в точности совпадать с набором целей, указанных заказчиком продукта, то есть все требования должны быть выполнены.

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

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

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

1. Начало (Inception) – формирование концепции проекта, понимание того, что мы создаем, представление о продукте (vision), разработка бизнес-плана (business case), подготовка прототипа программы или частичного решения. Это фаза сбора информации и анализа требований, определение образа проекта в целом. Цель – получить поддержку и финансирование. В конечной итерации результат этого этапа – техническое задание.
2. Проектирование, разработка (Elaboration) – уточнение плана, понимание того, как мы это создаем, проектирование, планирование необходимых действий и ресурсов, детализация особенностей. Завершается этап исполняемой архитектурой, когда все архитектурные решения приняты и риски учтены. Исполняемая архитектура представляет собой работающее программное обеспечение, которое демонстрирует реализацию основных архитектурных решений. В конечной итерации это – технический проект.
3. Реализация, создание системы (Construction) – этап расширения функциональности системы, заложенной в архитектуре. В конечной итерации это – рабочий проект.
4. Внедрение, развертывание (Transition). Создание конечной версии продукта. Фаза внедрения продукта, поставка продукта конкретному пользователю (тиражирование, доставка и обучение).

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

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

1. Бизнес-анализ и моделирование ( Business modeling ) обеспечивает реализацию принципов моделирования с целью изучения бизнеса организации и накопления знаний о нем, оптимизации бизнес-процессов и принятия решения об их частичной или полной автоматизации.
2. Управление требованиями (Requirements) посвящено получению информации от заинтересованных лиц и ее преобразованию в набор требований, определяющих содержание разрабатываемой системы и подробно описывающих ожидания от того, что система должна делать.
3. Анализ и проектирование (Analysis and design) охватывает процедуры преобразования требований в промежуточные описания (модели), представляющие, как эти требования должны быть реализованы.
4. Реализация (Implementation) охватывает разработку кода, тестирование на уровне разработчиков и интеграцию компонентов, подсистем и всей системы в соответствии с установленными спецификациями.
5. Тестирование (Test) посвящено оценке качества создаваемого продукта.
6. Развертывание (Deployment) охватывает операции, имеющие место при передаче продуктов заказчикам и обеспечении доступности продукта конечным пользователям.
7. Конфигурационное управление и управление изменениями (Configuration management) посвящено синхронизации промежуточных и конечных продуктов и управлению их развитием в ходе проекта и поиском скрытых проблем.
8. Управление проектом (Management) посвящено планированию проекта, управлению рисками, контролю хода его выполнения и непрерывной оценке ключевых показателей.
9. Управление средой (Environment) включает элементы формирования среды разработки информационной системы и поддержки проектной деятельности.

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

Неотъемлемую часть RUP составляют артефакты (artefact), прецеденты ( precedent ) и роли (role). Артефакты – это некоторые продукты проекта, порождаемые или используемые в нем при работе над окончательным продуктом. Прецеденты – это последовательности действий, выполняемых системой для получения наблюдаемого результата. Фактически любой результат работы индивидуума или группы является артефактом, будь то документ анализа, элемент модели, файл кода, тестовый скрипт, описание ошибки и т. п. За создание того или иного вида артефактов отвечают определенные специалисты. Таким образом, RUP четко определяет обязанности – роли – каждого члена группы разработки на том или ином этапе, то есть когда и кто должен создать тот или иной артефакт. Весь процесс разработки программной системы рассматривается в RUP как процесс создания артефактов – начиная с первоначальных документов анализа и заканчивая исполняемыми модулями, руководствами пользователя и т.п.

Для компьютерной поддержки процессов RUP в IBM разработан широкий набор инструментальных средств:

• Rational Rose – CASE- средство визуального моделирования информационных систем, имеющее возможности генерирования элементов кода. Специальная редакция продукта – Rational Rose RealTime – позволяет на выходе получить исполняемый модуль;
• Rational Requisite Pro – средство управления требованиями, которое позволяет создавать, структурировать, устанавливать приоритеты, отслеживать, контролировать изменения требований, возникающие на любом этапе разработки компонентов приложения;
• Rational ClearQuest – продукт для управления изменениями и отслеживания дефектов в проекте (bug tracking), тесно интегрирующийся со средствами тестирования и управления требованиями и представляющий собой единую среду для связывания всех ошибок и документов между собой;
• Rational SoDA – продукт для автоматического генерирования проектной документации, позволяющий установить корпоративный стандарт на внутрифирменные документы. Возможно также приведение документации к уже существующим стандартам (ISO, CMM);
• Rational Purify, Rational Quantify Rational PureCoverage, – средства тестирования и отладки;
• Rational Visual Quantify – средство измерения характеристик для разработчиков приложений и компонентов, программирующих на C/C++, Visual Basic и Java; помогает определять и устранять узкие места в производительности ПО;
• Rational Visual PureCoverage – автоматически определяет области кода, которые не подвергаются тестированию;
• Rational ClearCase – продукт для управления конфигурацией программ (Rational"s Software Configuration Management, SCM ), позволяющий производить версионный контроль всех документов проекта. С его помощью можно поддерживать несколько версий проектов одновременно, быстро переключаясь между ними. Rational Requisite Pro поддерживает обновления и отслеживает изменения в требованиях для группы разработчиков;
• SQA TeamTest – средство автоматизации тестирования ;
• Rational TestManager – система управления тестированием, которая объединяет все связанные с тестированием инструментальные средства, артефакты, сценарии и данные;
• Rational Robot – инструмент для создания, модификации и автоматического запуска тестов;
• SiteLoad, SiteCheck – средства тестирования Web-сайтов на производительность и наличие неработающих ссылок;
• Rational PerformanceStudio – измерение и предсказание характеристик производительности систем.

Этот набор продуктов постоянно совершенствуется и пополняется. Так, например, недавний продукт IBM Rational Software Architect (RSA) является частью IBM Software Development Platform – набора инструментов, поддерживающих жизненный цикл разработки программных систем. Продукт IBM Rational Software Architect предназначен для построения моделей разрабатываемых программных систем с использованием унифицированного языка моделирования UML 2.0, прежде всего моделей архитектуры разрабатываемого приложения. Тем не менее, RSA объединяет в себе функции таких программных продуктов, как Rational Application Developer, Rational Web Developer и Rational Software Modeler , тем самым предоставляя возможность архитекторам и аналитикам создавать различные представления разрабатываемой информационной системы с использованием языка UML 2.0, а разработчикам – выполнять разработку J2EE, XML, веб-сервисов и т.д.

Следуя принципам RUP, Rational Software Architect позволяет создавать необходимые модели в рамках рабочих процессов таких дисциплин, как:

• бизнес-анализ и моделирование ( Business modeling );
• управление требованиями (Requirements);
• анализ и проектирование (Analysis and Design);
• реализация (Implementation).

Кроме того, Rational Software Architect поддерживает технологию разработки, управляемой моделями (model-driven development, MDD), которая позволяет моделировать программное обеспечение на различных уровнях абстракции с возможностью трассируемости.

MSF (Microsoft Solution Framework)

В 1994 году, стремясь достичь максимальной отдачи от IT-проектов, Microsoft выпустила в свет пакет руководств по эффективному проектированию, разработке, внедрению и сопровождению решений, построенных на основе своих технологий. Эти знания базируются на опыте, полученном Microsoft при работе над большими проектами по разработке и сопровождению программного обеспечения, опыте консультантов Microsoft и лучшем из того, что накопила на данный момент IT-индустрия. Все это представлено в виде двух взаимосвязанных и хорошо дополняющих друг друга областей знаний: Microsoft Solutions Framework (MSF) и Microsoft Operations Framework (MOF).

Следует отметить, что Microsoft разработала на базе общих методов MSF методики для прикладного и специализированного применения. Причем Microsoft сертифицирует экспертов именно по прикладным знаниям в применении MSF (например, сертификация MCTS 74-131 по экспертизе в методике управления проектами). Перед тем как изучать методы MSF, следует сначала определить, какой прикладной вариант MSF имеется в виду.

Наиболее популярные прикладные варианты MSF, разработанные Microsoft:

• методика внедрения решений в области управления проектами;
• методика управления IT-проектами на базе методологий MSF и Agile.

Важность прикладных вариантов MSF подчеркивает тот факт, что в "чистом варианте" саму методику MSF в своих IT-проектах компания Microsoft не использует. В проектах Microsoft Consulting Services применяется гибридная методология MSF и Agile. Несмотря на внешние существенные различия прикладных вариантов MSF, разработанных экспертами Microsoft, база методов MSF для них остается общей и отражает общие методологические подходы к итеративному ведению проектов.

MOF призван обеспечить организации, создающие критически важные (mission-critical) IT решения на базе продуктов и технологий Майкрософт, техническим руководством по достижению их надежности (reliability), доступности (availability), удобства сопровождения (supportability) и управляемости (manageability). MOF затрагивает вопросы, связанные с организацией персонала и процессов; технологиями и менеджментом в условиях сложных (complex), распределенных (distributed) и разнородных (heterogeneous) IT-сред. MOF основан на лучших производственных методиках, собранных в IT Infrastructure Library (ITIL), составленной Central Computer and Telecommunications Agency – Агентством правительства Великобритании.

Создание бизнес-решения в рамках отведенных времени и бюджета требует наличия испытанной методологической основы. MSF предлагает проверенные методики для планирования, проектирования, разработки и внедрения успешных IT-решений. Благодаря своей гибкости, масштабируемости и отсутствию жестких инструкций MSF способен удовлетворить нужды организации или проектной группы любого размера. Методология MSF состоит из принципов, моделей и дисциплин по управлению персоналом, процессами, технологическими элементами и связанными со всеми этими факторами вопросами, характерными для большинства проектов. MSF состоит из двух моделей и трех дисциплин. Они подробно описаны в 5 whitepapers. Начинать изучение MSF лучше с моделей (модель проектной группы, модель процессов), а затем перейти к дисциплинам (дисциплина управление проектами, дисциплина управление рисками, дисциплина управление подготовкой).

Модель процессов MSF (MSF process model) представляет общую методологию разработки и внедрения IT-решений. Особенность этой модели состоит в том, что благодаря своей гибкости и отсутствию жестко навязываемых процедур она может быть применена при разработке весьма широкого круга IT-проектов. Эта модель сочетает в себе свойства двух стандартных производственных моделей: каскадной (waterfall) и спиральной (spiral). Модель процессов в MSF 3.0 была дополнена еще одним инновационным аспектом: она покрывает весь жизненный цикл создания решения, начиная с его отправной точки и заканчивая непосредственно внедрением. Такой подход помогает проектным группам сфокусировать свое внимание на бизнесотдаче (business value) решения, поскольку эта отдача становится реальной лишь после завершения внедрения и начала использования продукта.

Процесс MSF ориентирован на "вехи" (milestones) – ключевые точки проекта, характеризующие достижение в его рамках какого-либо существенного (промежуточного либо конечного) результата. Этот результат может быть оценен и проанализирован, что подразумевает ответы на вопросы: "Пришла ли проектная группа к однозначному пониманию целей и рамок проекта?", "В достаточной ли степени готов план действий?", "Соответствует ли продукт утвержденной спецификации?", "Удовлетворяет ли решение нужды заказчика?" и т. д.

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

Особенностями модели процессов MSF являются:

• подход, основанный на фазах и вехах;
• итеративный подход;
• интегрированный подход к созданию и внедрению решений.

Модель процессов включает такие основные фазы процесса разработки, как:

• выработка концепции (Envisioning);
• планирование (Planning);
• разработка (Developing);
• стабилизация (Stabilizing);
• внедрение (Deploying).

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

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

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

Итеративный подход к процессу разработки требует использования гибкого способа ведения документации. "Живые" документы (living documents) должны изменяться по мере эволюции проекта вместе с изменениями требований к конечному продукту. В рамках MSF предлагается ряд шаблонов стандартных документов, которые являются артефактами каждой стадии разработки продукта и могут быть использованы для планирования и контроля процесса разработки.

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