ИТУП / лекционный материал / Управление проектами и разработка ПО

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

60-х — 70-е годы XX века).

o 1968 г. — НАТО проводит первую конференцию по инженерии программирования (Software Engineering).

o 1975 г. — 1-я международная конференция IEEE.

o1979 г. — 1-я Всесоюзная конференция по технологии программирования.

•Разработка новых технологических подходов (начало 70-х

годов XX века — настоящее время).

o1973 г. — Дагласом Россом (Douglas Ross) разработана технология проектирования сложных систем SADT (Structured Analysis and Design Technique).

Стандартизована под названием IDEF (Integrated

DEFinition).

o 1985 г. — Харланом Миллзом (Harlan Mills)

сформулированы основные идеи технологии стерильного цеха.

o 1997 г. — в ноябре появилась первая версия Унифицированного языка моделирования UML (Unified Modeling Language). С точки зрения технологических подходов особый интерес представляет рациональный унифицированный процесс, описанный с использованием

UML.

•Принятие стандартов на состав процессов жизненного цикла программного обеспечения (середина 80-х годов XX

века — настоящее время). Попытки решить проблему качества программных продуктов.

o 1978 г. — В СССР утверждена Единая система программной документации (ЕСПД) — сборник стандартов, определяющий взаимоувязанные правила разработки, оформления и обращения программ и программной документации.

o 1985 г. — впервые утвержден стандарт жизненного цикла для проектирования программных систем (для систем военного назначения по заказам Министерства обороны США).

o 1994 г. — в Великобритании создан международный консорциум, разрабатывающий на постоянной основе проекты стандартов и технологии быстрого создания приложений DSDM (Dynamic Systems Development Method).

o 1995 г. — принят международный стандарт ISO 12207:1995 «Information Technology — Software Life Cycle

71

Processes», регламентирующий состав процессов жизненного цикла программного обеспечения.

4.4.3.Классификации моделей жизненного цикла

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

Классификация технологических подходов

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

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

•Строгие (классические, жесткие, предсказуемые)

подходы. Данную группу подходов рекомендуется применять для средних, крупномасштабных и гигантских проектов с фиксированным объемом работ. Одно из основных требований к таким проектам — предсказуемость.

В эту группу входят подходы, перечисленные ниже.

oКаскадные технологические подходы.

Классический каскадный подход.

Каскадно-возвратный подход.

Каскадно-итерационный подход.

Каскадный подход с перекрывающимися процессами.

Каскадный подход с подпроцессами.

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

oКаркасные подходы.

Рациональный унифицированный процесс. o Генетические подходы.

Синтезирующее программирование.

Сборочное (расширяемое) программирование.

Конкретизирующее программирование.

o Подходы на основе формальных преобразований.

72

Технология стерильного цеха.

Формальные генетические подходы.

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

o Ранние технологические подходы быстрой разработки.

Эволюционное прототипирование.

Итеративная разработка.

Постадийная разработка.

oАдаптивные подходы.

Экстремальное программирование.

Адаптивная разработка.

oПодходы исследовательского программирования.

Компьютерный дарвинизм.

Классификация технологических процессов

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

В классическом наборе выделим девять технологических процессов.

•Возникновение и исследование идеи.

•Управление.

•Анализ требований.

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

•Программирование.

•Тестирование и отладка.

•Ввод в действие.

•Эксплуатация и сопровождение.

•Завершение эксплуатации.

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

ISO 12207 [ISO/IEC 12207:1995], делятся на три группы.

• Основные процессы. o Приобретение. o Поставка.

73

o Разработка.

oЭксплуатация.

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

•Вспомогательные процессы.

oДокументирование.

oУправление конфигурацией.

oОбеспечение качества.

oВерификация.

oАттестация.

oСовместная оценка.

oАудит.

oРазрешение проблем.

•Организационные процессы.

oУправление.

o Создание инфраструктуры. o Усовершенствование.

o Обучение.

Классификация технологических стадий

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

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

74

Основные процессы

Приобретение

Поставка

Разработка

Эксплуатация

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

Вспомогательные процессы

Документирование

Вспомогательные процессы

Управление

Рис. 3 Взаимосвязь между стандартными процессами и стадиями

С 1980 года на территории Российской Федерации действует ГОСТ 19.102-77, входящий в систему ГОСТов ЕСПД, который устанавливает стадии разработки программ и программной документации для вычислительных машин, комплексов и систем независимо от их назначения и области применения. Стадии разработки, этапы и содержание работ должны соответствовать указанным в таблице

1.

Таблица 2.

Стадии разработки согласно ГОСТ 19.102-77

75

76

Примечания:

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

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

77

4.5. Комплекс работ по внедрению технологии управления проектом в организации

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

Вовлечение руководства.

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

Разработка документации.

Новая технология управления проектом должна быть детально документирована. При этом старая технология (или отсутствие технологии) управления проектом могла не быть подробно документированной – менеджеры просто привыкли к старой технологии и делали все «как раньше», без письменных инструкций. Для новой технологии этот способ, очевидно, не подходит. Подчеркнем, что детальность документации не обязательно влечет необозримый объем. Использование современных методов документирования процессов позволяет очень компактно и в то же время с необходимыми подробностями описать всю последовательность и взаимосвязи необходимых действий и документов.

Ярким примером является Рациональный унифицированный процесс (Rational Unified Process (RUP)). Будучи весьма детальным описанием развитой системы взаимодействующих процессов, RUP относительно компактен, поскольку для описания процессов используется формализованная нотация Унифицированного языка моделирования (Unified Modeling Language (UML).

78

Подготовка инфраструктуры.

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

Обучение персонала.

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

Установка инструментов.

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

Проведение испытаний.

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

79