Главная Случайная страница Контакты | Мы поможем в написании вашей работы! | ||
|
Тема 2: Жизненный цикл IT-проекта.
Жизненный цикл проекта в методологиях быстрого развития: экстремальное программирование ХР
Выбор модели жизненного цикла проекта
= Понятие жизненного цикла проекта=
Жизненный цикл проекта - это промежуток времени между моментом зарождения проекта и моментом его завершения, включающий набор фаз проекта, определяющий последовательный ход работ по проекту.
Понятие жизненного цикла является одним из центральных понятий, используемых в управлении проектами.
Основным структурным элементом жизненного цикла проекта является понятие фазы. Фаза – это набор логически взаимосвязанных работ проекта, в процессе завершения которых достигается один из основных результатов проекта.
Универсального подхода к разделению процесса реализации проекта на фазы не существует, главное чтобы такое деление выявляло некоторые контрольные точки (вехи), прохождение которых знаменует достижение одного или нескольких результатов проекта и дает дополнительную информацию для оценки возможных направлений его развития.
Укрупненно жизненный цикл проекта можно разделить на три основные смысловые фазы: прединвестиционную, инвестиционную и эксплуатационную. Дальнейшее разбиение существенно зависит от специфики проекта.
Типичная структура жизненного цикла проекта включает 5 фаз:
1. концептуальная фаза (инициация) - включает зарождение идеи разработку концепции проекта и определение ключевых моментов его реализации (цели, участники, сроки и т.п.);
2. фаза разработки проекта (планирование) - включает определение структуры работ и исполнителей, построение календарных графиков работ, бюджета проекта, заключение контрактов;
3. фаза реализации проекта (исполнение) – включает координацию ресурсов (людей, техники, оборудования), необходимых для выполнения намеченных работ и работы по его реализации (строительство, маркетинг, обучение персонала);
4. фаза контроля – сбор фактических данных о ходе работ и сравнение их с плановыми показателями, анализ отклонений и реагирование на отклонения.
5. фаза завершения проекта, включающая ряд мероприятий, которые руководитель должен выполнять для формального завершения проекта (отчеты о результатах, опытная эксплуатация).
Фазы жизненного цикла проекта связаны между собой: результат выполнения одной фазы становится исходной информацией для другой, проходя через шлюзы и контрольные точки. В реальном проекте фазы могут не только предшествовать друг другу, но и накладываться. (рис 1.9).
Упрощенно жизненный цикл IT-проектов можно изобразить в виде рисунка 1.
|
|
|
Рисунок 1 – Логика жизненного цикла IT-проекта
Основным нормативным документом, регламентирующим состав процессов ЖЦ ПО, является международный стандарт ISO/IEC 12207 «International Technology – Software Life Cycle Processes» (ГОСТ ИСО МЭК 12207 Информационные технологии. Жизненный цикл программного обеспечения).
Стандарт ISO/IEC 12207 определяет общую структуру жизненного цикла ПО в виде 3 ступенчатой модели, состоящей из процессов, видов деятельности и задач. Каждый процесс разделен на набор действий, каждое действие – на набор задач, каждая задача характеризуется определенным методом решения, исходными данными, в том числе, полученными от других процессов, и результатами. Любой процесс увязан с определенными артефактами и ролями заинтересованных лиц. Каждый процесс, действие или задача инициируется и выполняется другим процессом по мере необходимости, причем не существует заранее определенных последовательностей выполнения.
Всего в стандарте ISO/IEC 12207 определено 18 процессов, 74 вида деятельности и 224 различные задачи.
В соответствии со стандартом все процессы жизненного цикла ПО разделены на группы (см. рис 4.1.):
Рис. 4.1. Жизненный цикл ПО
= Характеристика процессов жизненного цикла IT-проекта=
К основным процессам ЖЦ ПО относятся:
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. Процесс обучения охватывает первоначальное обучение и последующее постоянное повышение квалификации персонала. Содержание процесса обучения определяется требованиями к проекту.
= Типология моделей жизненного цикла IT-проектов=
Модель жизненного цикла ПО схематически объясняет, каким образом будут выполняться действия по разработке программного продукта, посредством описания последовательности этих действий.
Модель жизненного цикла представляет собой совокупность упорядоченных во времени, взаимосвязанных и объединенных в стадии работ, выполнение которых необходимо и достаточно для создания ПО, соответствующего заданным требованиям.
Модель жизненного цикла зависит от специфики, масштаба и сложности проекта, а также от условий, в которых система создается и функционирует. Организация может иметь множество моделей жизненного цикла разработки ПО, однако для каждого конкретного проекта должна быть отобрана только одна модель. Смешение моделей в пределах одного проекта приводит к беспорядку и получению недетерминированного набора методов измерений проекта.
Существует множество моделей жизненного цикла программных средств.
Три из них в международных стандартах обычно квалифицируются как фундаментальные:
1. каскадная:
- традиционная («водопад»)
- итерационная
- V-образная
2. эволюционная
- модель быстрого прототипирования
- модель быстрой разработки RAD
- спиральная модель
3. инкрементная.
Каждая из указанных моделей может быть использована самостоятельно или скомбинирована с другими для создания гибридной модели жизненного цикла конкретного проекта (среди гибридных наиболее распространены итеративно-инкрементная модель с элементами каскада RUP и каскадно-спиральная модель процессов MSF).
Тема 4: Процессы управления проектами: инициация, планирование, исполнение, контроль, завершение.
= Процессы инициации=
Инициация – стадия процесса управления проектом, результатом которой является санкционирование начала проекта.
Инициирование проекта начинается с формирования замысла (идеи) проекта. Формирование замысла (идеи) проекта может осуществляться исходя из:
1. возникших проблем (конкурентная борьба на рынке, отсутствие соответствующей технологии, снижение эффективности бизнеса, интересы кредиторов, социальные проблемы и т. д.) – основным параметром при рождении таких проектов является отсутствие достаточного времени для анализа и выбора наиболее эффективного пути решения, оптимизации сметы затрат. Длительность в таких проектах является наиболее критичным фактором.
2. открывшихся возможностей (избыточные ресурсы, наличие свободной ниши на рынке или неудовлетворенный спрос, вновь открытая технология или полученный патент, благоприятное экономическое положение и т. д.) - в этих случаях готовятся маркетинговые обзоры, анализируются возможности внешнего рынка. В таких проектах может затянуться время согласования, возникнуть много проблем среди заинтересованных лиц, часто происходит смена приоритетов или целей проекта.
3. потребности заказчика (внедрение новой системы поддержки принятия решений и др.) - такие проекты часто называются «священными коровами»по той степени внимания, которое руководитель уделяет своей идее и будущему продукту проекта.
После принятия общей идеи проекта происходит уточнение будущих результатов и конечных целей проекта. Очень важно разработать и оценить альтернативные варианты достижения цели (стратегии достижения цели), т.к. не всегда первая передоложенная на презентации стратегия может оказаться верной или экономически оправданной.
Стратегия реализации проекта — выработка конкретных направлений действий с целью получения обозначенных деревом целей результатов проекта, иными словами — это карта, с помощью которой команда проекта планирует достичь своих целей. Цель у проекта одна, стратегий может быть несколько, в таком случае говорят об альтернативных стратегиях.
Стратегии анализируются, выбирается основная и на ее основе формируется план проекта, т.е. происходит переход на следующую фазу ЖЦП.
После формирования определенного числа альтернативных идей проекта необходимо выполнить предварительную экспертизу и исключить из дальнейшего рассмотрения заведомо неприемлемые.
Основные способы выбора стратегии могут быть разделены на:
1. качественные методы (когда работают качественные оценки)
2. количественные (когда стратегии сравниваются по каким-либо численным характеристикам).
Эти методы могут использоваться и при мульти-проектном управлении в компании, когда необходимо сделать выбор между несколькими проектами из-за ограниченных ресурсов или иных предпочтений.
Качественные методы
1. Интуитивный отбор альтернатив (здравый смысл) - пригоден для опытных руководителей проектов, которые могут отсечь нереальные или опасные стратегии.
2. Экспертная оценка – предполагает помощь внутренних или внешних экспертов, которые могут профессионально вскрыть невидимые проблемы и недостатки.
3. Стратегия проекта «священной коровы» - обязательная стратегия будет предложена собственником бизнеса. Если этого не произошло, необходимо выяснить все ограничения, которые и предопределят единственно верную стратегию.
4. По аналогиям.
Дата публикования: 2015-03-26; Прочитано: 1134 | Нарушение авторского права страницы | Мы поможем в написании вашей работы!