Студопедия.Орг Главная | Случайная страница | Контакты | Мы поможем в написании вашей работы!  
 

Качественные методы



Тема 2: Жизненный цикл IT-проекта.

Жизненный цикл проекта в методологиях быстрого развития: экстремальное программирование ХР

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

= Понятие жизненного цикла проекта=

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

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

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

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

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

Типичная структура жизненного цикла проекта включает 5 фаз:

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

2. фаза разработки проекта (планирование) - включает определение струк­туры работ и исполнителей, построение календарных гра­фиков работ, бюджета проекта, заключение контрактов;

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

4. фаза контроля – сбор фактических данных о ходе работ и сравнение их с плановыми показателями, анализ отклонений и реагирование на отклонения.

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

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

Упрощенно жизненный цикл IT-проектов можно изобразить в виде рисунка 1.

 
 


Развертывание (deployment): обучение пользователей, инсталляция системы, перевод в промышленную эксплуатацию.  
Тестирование (testing): включает проверку соответствия функциональности ПО потребностям пользователей (validation), а также поиск дефектов в реализации.  
Реализация (implementation): создание продукта по спецификациям, разработанным на предыдущем этапе.  

Рисунок 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 | Нарушение авторского права страницы | Мы поможем в написании вашей работы!



studopedia.org - Студопедия.Орг - 2014-2024 год. Студопедия не является автором материалов, которые размещены. Но предоставляет возможность бесплатного использования (0.014 с)...