Выбор модели жизненного цикла проекта
Типология моделей жизненного цикла IT-проектов
Характеристика процессов жизненного цикла IT-проекта.
Понятие жизненного цикла проекта.
4. Жизненный цикл проекта в методологиях быстрого развития: экстремальное программирование ХР
=2=
К основным процессамЖЦ ПО относятся:
1. Процесс приобретения. В ходе данного процесса заказчик должен осознать свои потребности в программной системе, проанализировать требования к ней, принять решение относительно приобретения, разработки или усовершенствования существующего ПО. Процесс приобретения завершается в тот момент, когда оказались выполненными все условия приемки, в том числе, сработали все необходимые тесты.
2. В процессе поставки организация–поставщик рассматривает заявочные предложения заказчика и, при необходимости, вносит в них свои коррективы, подготавливает договор с ним, осуществляет планирование выполнения, разрабатывает ОСУ проекта, технические требования к среде разработки и ресурсам, мероприятия по управлению проектом и др.
3. Процесс разработки определяет действия и задачи, выполняемые разработчиком в процессе создания программного обеспечения и его компонентов в соответствии с заданными требованиями. Процесс разработки ПО состоит из ряда фаз:
а) подготовительная - предшествует разработке ПО, включает выбор модели ЖЦ ПО, соответствующей масштабу, значимости и сложности проекта, выбор, адаптацию к условиям проекта и согласование с заказчиком используемые стандарты, методы и средства разработки, а также составление плана выполнения работ.
- б) анализ требований к системе - дает ответ на вопрос: «Что должна делать будущая система?». Для ответа на этот вопрос, во-первых, необходимо понять, какие именно потребности пользователей призвана обеспечить будущая система, а во-вторых, задокументировать это понимание.
- в) анализ требований к программному обеспечению - для каждого компонента ПО определяются следующие характеристики:
- функциональные возможности, включая характеристики производительности и среды функционирования компонента;
- внешние интерфейсы;
- спецификации надежности и безопасности;
- эргономические требования;
- требования к используемым данным;
- требования к установке и приемке;
- требования к пользовательской документации;
- требования к эксплуатации и сопровождению.
г) проектирование - деятельность, результат которой состоит из двух составных частей:
- архитектурный или высокоуровневый дизайн (software architectural design, top-level design) – описание высокоуровневой структуры и организации компонентов системы;
- детализированная архитектура (software detailed design) – описывающая каждый компонент в том объеме, который необходим для конструирования.
В строгом значении архитектура программного обеспечения (software architecture) представляет собой описание подсистем и компонентов программной системы, а также связей между ними. Архитектура пытается определить внутреннюю структуру получаемой системы, задавая способ, которым система организована или конструируется.
- д) кодирование и тестирование
е) интеграция системы заключается в сборке всех ее компонентов, включая ПО и оборудование, и тестировании агрегированных модулей.
ж) квалификационное тестирование ПО проводится разработчиком в присутствии заказчика (по возможности) для демонстрации того, что ПО удовлетворяет своим спецификациям и готово к использованию в условиях эксплуатации.
з) установка ПО осуществляется разработчиком в соответствии с планом в той среде и на том оборудовании, которые предусмотрены договором.
и) приемка ПО предусматривает оценку результатов квалификационного тестирования системы и документирование результатов оценки, которое производится заказчиком с помощью разработчика. Разработчик выполняет окончательную передачу ПО заказчику в соответствии с договором, обеспечивая при этом необходимое обучение и поддержку.
Примечание: Главная особенность индустрии разработки программного обеспечения состоит в том, что основные трудозатраты и сложности концентрируются на начальных этапах жизненного цикла (анализ и проектирование) при относительно невысокой сложности и трудоемкости последующих этапов. Более того, нерешенные вопросы и ошибки, допущенные на этапах анализа и проектирования, порождают трудные, часто неразрешимые проблемы и, в конечном счете, могут привести к провалу всего проекта.
4. Процесс эксплуатации охватывает действия и задачи организации, эксплуатирующей программную систему. На этом этапе устанавливаются эксплуатационные стандарты, и проводится эксплуатационное тестирование, после чего система передается пользователям. Поддержка пользователей заключается в оказании им помощи при обнаружении ошибок в процессе эксплуатации.
- 5. Процесс сопровождения активизируется при изменениях (модификациях) программного продукта и соответствующей документации, вызванных возникшими проблемами или потребностями в модернизации или адаптации программной системы. Согласно стандарту IEEE – 90 под сопровождением понимается внесение изменений в ПО в целях исправления ошибок, повышения производительности или адаптации к изменившимся условиям работы или требованиям. При этом изменения, вносимые в существующее ПО, не должны нарушать его целостность.
К вспомогательным процессам жизненного цикла ПО относятся:
1. Процесс документирования предусматривает формализованное описание информации, созданной в течение всего жизненного цикла. Этот процесс состоит из набора действий, с помощью которых планируют, проектируют, разрабатывают, выпускают, редактируют, распространяют и сопровождают документы, необходимые для всех заинтересованных лиц, таких как менеджеры, технические специалисты и пользователи системы.
2. Управление конфигурацией позволяет организовать, систематически учитывать и контролировать внесение изменений в ПО на всех стадиях жизненного цикла. Согласно стандарту IEEE – 90 под конфигурацией программного обеспечения понимается совокупность его функциональных и физических характеристик, установленных в технической документации и реализованных в программах. Итоговое действие по управление конфигурацией – это управление выпуском и поставка, в процессе которых изготавливаются эталонные копии программ и документации для хранения и поставки пользователям в соответствии с порядком, принятом в организации.
3. Процесс обеспечения качества обеспечивает гарантии того, что программный продукт и процессы его жизненного цикла соответствуют заданным требованиям, а также выработанным и утвержденным планам работ. При этом под качеством мы понимаем совокупность свойств, характеризующих способность программного обеспечения удовлетворять заданным требованиям и нуждам всех заинтересованных сторон.
Процесс призван обеспечить гарантированное соответствие процессов жизненного цикла, среды разработки и квалификации персонала условиям договора, установленным стандартам и процедурам. Для этого должны быть обеспечены качество продукта, качество процесса и прочие показатели качества системы. Для получения достоверных оценок качества создаваемого программного обеспечения процесс обеспечения его качества должен происходить независимо от разработчиков. Для этого могут использоваться результаты других вспомогательных процессов: верификации, аттестации, совместной оценки, аудита и разрешения проблем.
4. Верификация означает формальное доказательство правильности ПО. Верификация может проводиться самим исполнителем или другим специалистом данной организации, либо независимым экспертом (в этом случае говорят о независимой верификации).
5. Процесс аттестации (или процесс проверки соответствия) предусматривает определение полноты соответствия заданных требований и созданной системы или программного продукта их конкретному функциональному назначению. Под аттестацией обычно понимается подтверждение и оценка достоверности проведенного тестирования ПО.Аттестация должна гарантировать полное соответствие ПО спецификациям, требованиям и документации, а также возможность его безопасного и надежного применения пользователем. Аттестация может проводиться с различными степенями независимости. Ее можно проводить на начальных стадиях жизненного цикла ПО или как часть работы по его приемке.
6. Процесс совместной оценки сосредоточен в основном на контроле планирования и управления ресурсами, персоналом, инструментальными и аппаратными средствами программного проекта. Он предназначен для оценки состояния работ по проекту и применяется как на уровне управления проектом, так и на уровне его технической реализации. Его цель - поддержание общего понимания продвижения к целям, поставленным в договоре.
7. Процесс разрешения проблем предусматривает анализ и разрешение проблем, которые обнаружены в ходе разработки, эксплуатации, сопровождения или других процессов независимо от их происхождения (включая обнаруженные несоответствия).
Организационные процессы жизненного цикла ПО включают:
1. Процесс управления включает такие действия как определение области управления, планирование, выполнение и контроль.
2. Создание инфраструктуры.Инфраструктура программного проекта включает в себя технологии и стандарты, а также совокупность аппаратных, программных и инструментальных средств для разработки, эксплуатации или сопровождения ПО. Инфраструктура, в свою очередь, является одним из объектов управления конфигурацией.
3. Процесс усовершенствования предусматривает оценку, измерение, контроль и усовершенствование процессов жизненного цикла ПО. Он основан на анализе достоинств и недостатков каждого процесса. Такому анализу способствует накопление организационной, технической, экономической и другой информации по реализованным проектам. Целью процесса усовершенствования является повышение производительности труда всех участвующих специалистов за счет развития используемой технологии и методов управления, выбора соответствующих им инструментальных средств и обучения персонала.
4. Процесс обучения охватывает первоначальное обучение и последующее постоянное повышение квалификации персонала. Содержание процесса обучения определяется требованиями к проекту.
=5=
Для выбора приемлемой модели жизненного цикла разработки ПО необходимо выполнить следующую последовательность действий.
1. Проанализировать отличительные категории проекта ( см. табл.).
2. Ответить на вопросы, приведенные для каждой категории, выбрав в качестве ответа слова «да» или «нет».
3. Расположить по степени важности вопросы, относящиеся к каждой категории, относительно проекта, для которого выбирается приемлемая модель.
4. Воспользоваться упорядоченными категориями для разрешения противоречий, возникающих при сравнении моделей, если общие полученные показатели сходны или одинаковы.
Выбор модели жизненного цикла зависит от разных характеристик: требования, команда разработчиков, коллектив пользователей, тип проекта и риски
Табл. - Выбор модели жизненного цикла
| Основание выбора | Каскад ная | V-образ. | Прототи- пирование | Спиральная | RAD | Инкре- ментная | |||||||||||
| Требования: | |||||||||||||||||
| Являются ли требования легко определимыми и/или хорошо известными? | Да | Да | Нет | Нет | Да | Нет | |||||||||||
| Могут ли требования заранее определяться в цикле? | Да | Да | Нет | Нет | Да | Да | |||||||||||
| Часто ли будут изменяться требования в цикле? | Нет | Нет | Да | Да | Нет | Нет | |||||||||||
| Нужно ли демонстрировать требования с целью определения? | Нет | Нет | Да | Да | Да | Нет | |||||||||||
| Требуется ли для демонстрации возможностей проверка концепции? | Нет | Нет | Да | Да | Да | Нет | |||||||||||
| Будут ли требования отражать сложность системы? | Нет | Нет | Да | Да | Нет | Да | |||||||||||
| Обладает ли требование функциональными свойствами на раннем этапе? | Нет | Нет | Да | Да | Да | Да | |||||||||||
| Команда разработчиков проекта: | |||||||||||||||||
| Являются ли проблемы предметной области проекта новыми для большинства разработчиков? | Нет | Нет | Да | Да | Нет | Нет | |||||||||||
| Является ли технология предметной области проекта новой для большинства разработчиков? | Да | Да | Нет | Да | Нет | Да | |||||||||||
| Являются ли инструменты, используемые проектом, новыми для большинства разработчиков? | Да | Да | Нет | Да | Нет | Нет | |||||||||||
| Изменяются ли роли участников проекта во время жизненного цикла? | Нет | Нет | Да | Да | Нет | Да | |||||||||||
| Могут ли разработчики проекта пройти обучение? | Нет | Да | Нет | Нет | Да | Да | |||||||||||
| Является ли структура более значимой для разработчиков, чем гибкость? | Да | Да | Нет | Нет | Нет | Да | |||||||||||
| Будет ли менеджер проекта строго отслеживать прогресс команды? | Да | Да | Нет | Да | Нет | Да | |||||||||||
| Важна ли легкость распределения ресурсов? | Да | Да | Нет | Нет | Да | Да | |||||||||||
| Приемлет ли команда равноправные обзоры и инспекции? | Да | Да | Да | Да | Нет | Да | |||||||||||
| Коллектив пользователей: | |||||||||||||||||
| Будет ли присутствие пользователей ограничено в жизненном цикле? | Да | Да | Нет | Да | Нет | Да | |||||||||||
| Будут ли пользователи знакомы с определением системы? | Нет | Нет | Да | Да | Нет | Да | |||||||||||
| Буду ли пользователи ознакомлены с проблемами предметной области? | Нет | Нет | Да | Нет | Да | Да | |||||||||||
| Будут ли пользователи вовлечены во все фазы жизненного цикла? | Нет | Нет | Да | Нет | Да | Нет | |||||||||||
| Будет ли заказчик отслеживать ход выполнения проекта? | Нет | Нет | Да | Да | Нет | Нет | |||||||||||
| Тип проекта и риски: | |||||||||||||||||
| Будет ли проект идентифицировать новое направление продукта для организации? | Нет | Нет | Да | Да | Нет | Да | |||||||||||
| Будет ли проект иметь тип системной интеграции? | Нет | Да | Да | Да | Да | Да | |||||||||||
| Будет ли проект являться расширением существующей системы? | Нет | Да | Нет | Нет | Да | Да | |||||||||||
| Будет ли финансирование проекта стабильным на всем протяжении жизненного цикла? | Да | Да | Да | Нет | Да | Нет | |||||||||||
| Ожидается ли длительная эксплуатация продукта в организации? | Да | Да | Нет | Да | Нет | Да | |||||||||||
| Должна ли быть высокая степень надежности? | Нет | Да | Нет | Да | Нет | Да | |||||||||||
| Будет ли система изменяться, возможно, с применением непредвиденных методов, на этапе сопровождения? | Нет | Нет | Да | Да | Нет | Да | |||||||||||
| Является ли график ограниченным? | Нет | Нет | Да | Да | Да | Да | |||||||||||
| Являются ли «прозрачными» интерфейсные модули? | Да | Да | Нет | Нет | Нет | Да | |||||||||||
| Доступны ли повторное используемые компоненты? | Нет | Нет | Да | Да | Да | Нет | |||||||||||
| Являются ли достаточными ресурсы (время, деньги, инструменты, персонал)? | Нет | Нет | Да | Да | Нет | Нет | |||||||||||
Выбор подходящей модели — это только первая стадия применения модели жизненного цикла в процессе определенного проекта. Следующая стадия заключается в ее подгонке в соответствии с потребностями этого проекта. Это означает, что выбранные реальные фазы и действия должны помочь руководителю проекта соотнести проект с выбранной моделью.
Тема 3: Процессы управления проектами: инициация, планирование, исполнение, контроль, завершение.