1.2 Жизненный цикл информационной системы

Жизненный цикл – отрезок времени, который «проживает» система от ее концепции до списания.

Жизненный цикл разбивается на стадии и этапы.

Практика различает два основных типа моделей жизненного цикла:

• Каскадная модель

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

Основные процессы жизненного цикла

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

Разработка

Разработка информационной системы включает в себя все работы по разработке информационного программного обеспечения и его компонентов в соответствии с заданными требованиями.

Разработка информационного программного обеспечения также включает:

• Оформление проектной и эксплуатационной документации;

• Подготовку материалов, необходимых для проведения тестирования тайных программных продуктов;

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

Разработка является одним из важнейших процессов жизненного цикла ИС и , как правило, включает в себя стратегическое планирование , анализ, проектирование и реализацию (программирование).

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

Эксплуатационные работы можно подразделить на подготовительные и основные.

К подготовительным относятся:

• Конфигурирование базы данных и рабочих мест пользователей;

• Обеспечение пользователей эксплуатационной документацией;

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

Основные эксплуатационные работы включают:

• Эксплуатацию;

• локализацию проблем и устранение причин их возникновения;

• модификацию программного обеспечения;

• подготовку предложений по совершенствования системы;

• развитие и модернизацию системы;

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

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

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

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

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

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

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

• разработку методов и средств испытаний созданного программного обеспечения;

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

Обеспечение качества проекта связано с проблемами верификации, тестирования компонентов ИС.

Верификация- это процесс определения соответствия состояния разработки, достигнутого на данном этапе, требованиям этого этапа.

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

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

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

В настоящее время используются след модели жизненного цикла:

• каскадная модель;

• спиральная модель;

• V-образная модель;

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

• Модель «фазы-функции».

Каскадная модель

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

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

Основные этапы разработки при каскадной модели:

Рисунок 3 - Каскадная модель жизненного цикла информационной системы

• Анализ – анализ требований заказчика к создаваемой ИС.

• Проектирование – подготовка данных для реализации ИС.

• Реализация – реализация проекта, включая создание ПО.

• Тестирование – тестирование и опытная эксплуатация системы.

• Сдача – сдача в эксплуатацию готовой системы.

• Эксплуатация – эксплуатация системы.

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

• Наличие на каждом этапе законченного пакета документов.

• Простота планирования работ по каждой стадии и легкость определения затрат.

Р исунок 4 - Реальный процесс разработки по каскадной схеме

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

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

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

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

Использование спиральной модели позволяет осуществлять переход на следующий этап выполнения проекта, не дожидаясь полного завершения текущего – недоделанную работу можно будет выполнить на следующей итерации. Главная задача каждой итерации – как можно быстрее создать работоспособный продукт, который можно показать пользователям системы . таким образом существенно упрощается процесс внесения уточнений и дополнений в проект [4].

Рисунок 5 – Спиральная модель жизненного цикла информационной системы

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

• небольшую команду программистов (от 2 до 10 человек);

• короткий, но тщательно проработанный производственный график (от 2 до 6 месяцев);

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

Жизненный цикл по методологии RAD cостоит из четырех фаз:

1. фаза определения требований и анализа.

2. Фаза проектирования

3. Фаза реализации

4. Фаза внедрения

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

• Упрощение внесение изменений.

• Уменьшение уровня финансовых расходов.

• Легкая интеграция младших и старших версий.

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

• Уменьшение уровня рисков[4].

Каскадная модель

риски

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

время

Рисунок 6 – Зависимость рисков от времени разработки

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

• Неприменимость к некоторым системам.

• Сложность определения момента перехода на следующий этап.

На базе рассмотренных моделей могут быть построены комбинированные модели: спирально-каскадные, каскадно-спиральные, надкаскадные и т.п.

V-образная модель

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

Рисунок 7 - V-образная модель обобщенного ЖЦ ИС

Основные этапы разработки при V-образном моделировании:

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

2. Анализ требований и составление спецификаций – анализ существующей на данный момент проблемы с ПО, завершается полной спецификацией ожидаемой внешней линии поведения создаваемой программной системы:

3. Разработка архитектуры – определяет, каким образом функции ПО должны применяться при реализации объектов;

4. Детализация объектов - определяет и документально обосновывает алгоритмы для каждого компонента. Который был определен на фазе построения архитектуры. Эти алгоритмы в последствии будут преобразованы в код;

5. Программирование – выполняется преобразование алгоритмов, определенных на этапе детализации проектирования, в готовое ПО;

6. Тестирование моделей – выполняется проверка каждого закодированного модуля на наличие ошибок;

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

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

9. Эксплуатация и сопровождение – ПО запускается в производство. На этой фазе предусмотрены также модернизация и внесение поправок.

Преимущества V-образной модели

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

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

• В модели предусмотрены аттестация и верификация всех внешних и внутренних полученных данных, а не только самого программного продукта;

• В V-образной модели определение требований выполняется перед разработкой проекта системы, а проектирование ПО – перед разработкой компонентов;

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

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

• Модель проста в использовании (относительно проекта для которого она является приемлемой).

Недостатки V-образной модели:

При использовании V-образной модели в работе над проектом, для которого она не является в достаточной степени приемлемой, становятся очевидными ее недостатки:

• с ее помощью непросто справиться с параллельными событиями;

• в ней не учтены итерации между фазами;

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

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

• в модель не входят действия, направленные на анализ рисков.

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

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

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

Основные этапы разработки при инкрементной модели:

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

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

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

Рисунок 8 –Инкрементная модель жизненного цикла информационных систем

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

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

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

• В результате выполнения каждого инкремента получается функциональный продукт;

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

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

• существует возможность поддерживать постоянный прогресс в ходе выполнения проекта;

• снижаются затраты на первоначальную поставку программного продукта;

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

• снижается риск неудачи и изменения требований;

• заказчики могут распознавать самые важные и полезные функциональные возможности продукта на более ранних этапах разработки;

• риск распределяется на несколько меньших по размеру инкрементов (не сосредоточен в одном большом проекте разработки):

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

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

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

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

• использование последовательных инкрементов позволяет объединить полученный пользователями опыт в виде усовершенствованного продукта, затратив при этом намного меньше средств, чем требуется для выполнения повторной разработки;

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

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

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

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

• ощутимые признаки прогресса при выполнении проекта помогают поддерживать вызванное соблюдением графика "давление" на управляемом уровне.

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

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

• в модели не предусмотрены итерации в рамках каждого инкремента;

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

• формальный критический анализ и проверку намного труднее выполнить для инкрементов, чем для системы в целом;

• заказчик должен осознавать, что общие затраты на выполнение проекта не будут снижены;

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

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

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

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

Модель фазы - функции

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

так называемых производственных функций, которые выполняются при

развитии проекта.

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

• фазовое, отражающее этапы выполнения проекта и сопутствующие им события;

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

Фазовое измерение

В модели Гантера отражено то, что выполнение функции на одном этапе может продолжаться на следующем. На (Рисунке9) представлено фазовое измерение модели. Жирной чертой (с разрывом и стрелкой, обозначающей временное направление) изображен процесс разработки. Контрольные точки и наименования событий указаны под этой чертой. Они пронумерованы. Все развитие проекта в модели привязывается к этим контрольным точкам и событиям.

Рисунок 9 - Фазовое измерение модели фазы — функции

Функциональное измерение

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

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

• содержание (цели) функции на различных этапах претерпевает изменение;

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

Эти положения требуют отражения при моделировании жизненного цикла.

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

Исходя из этих предпосылок, Гантер строит второе измерение своей модели. Он говорит о следующем наборе функций (если угодно -- классов функций).

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

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

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

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

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

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

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

Рисунок 10 – Матрица фазы – функции модели Гантера

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

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

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