Уровни жизненного цикла (по Амблеру)

Уровни жизненного цикла (по Амблеру)

Одним из ключевых понятий управления проектами, в том числе в приложении к индустрии программного обеспечения, является жизненный цикл проекта (Project Life Cycle Management - PLCM).

 

Арчибальд так определяет жизненный цикл проекта [Арчибальд Р., 2003, с.58-59] [Арчибальд Р.2005]: «Жизненный цикл проекта имеет определенные начальную и конечную точки, привязанные к временной шкале. Проект в своем естественном развитии проходит ряд отдельных фаз»

 

Жизненный цикл автоматизированной системы (АС) - совокупность взаимосвязанных процессов создания и последовательного изменения состояния АС, от формирования

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

автоматизации АС [ГОСТ 34, 1990].

 

Скотт Амблер, автор концепций и практик гибкого моделирования (Agile Modeling) и Enterprise Unified Process (расширение Rational Unified Process), предлагает следующие уровни жизненного цикла, определяемые соответствующим содержанием работ:

 

• Жизненный цикл разработки программного обеспечения (проект) – проектная деятельность по разработке и развертыванию программных систем

• Жизненный цикл программной системы (ИС или ПО) – включает разработку, развертывание, поддержку и сопровождение

• Жизненный цикл информационных технологий (ИТ-департамент) – включает всю деятельность ИТ-

департамента

• Жизненный цикл организации/бизнеса (организация) – охватывает всю деятельность организации в целом

 

Рисунок 1. Содержание четырех категорий жизненного цикла по Амблеру

 

 

Назначение стандартов в области ИТ

 

Кому нужны стандарты?

n потребителям информационных систем (ИС) — для упорядочения своей деятельности и взаимодействия с поставщиками;

n поставщикам продуктов и услуг - для снижения себестоимости продукции и следования требованиям заказчиков и рынка;

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

Зачем нужны старые советские ГОСТ 19 и ГОСТ 34?

n В России ГОСТ серий 19 и 34 часто применяются при создании программ и автоматизированных систем, когда в качестве заказчиков выступают государственные или крупные коммерческие организации.

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

Сравнительный анализ ГОСТ ИСО/МЭК 12207, 15288, SWEBOK

 

Технические процессы

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

Технические процессы состоят из следующих процессов:

 

Определение требований правообладателей

 

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

 

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

 

Анализ системных требований

 

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

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

 

Процесс реализации

 

Цель процесса реализации элементов системы состоит в создании заданных (специфицированных) элементов системы.

 

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

 

Процесс функционирования

Цель процесса функционирования

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

 

Результаты процесса функционирования

В результате успешного осуществления процесса функционирования:

a) определяется стратегия функционирования;

b) поставляются услуги, удовлетворяющие требованиям правообладателей;

c) успешно выполняются заявки на принятые корректирующие действия;

d) поддерживается удовлетворенность правообладателей.

 

Деятельность в процессе функционирования

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

a) подготавливать стратегию функционирования.

 

П р и м е ч а н и е — Это действие определяет:

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

2) стратегию подбора персонала и графики работы операторов;

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

b) получать другие услуги, относящиеся к функционированию системы;

c) назначать на должности операторов обученный и квалифицированный персонал.

 

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

 

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

 

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

 

e) применять материалы, требуемые для поддержания необходимых услуг.

 

П р и м е ч а н и е — В их число входят источники питания для технических средств и снабжение продовольствием операторов;

 

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

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

 

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

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

i) определять приемлемое направление действий, если требуется проведение корректирующих мероприятий для устранения ошибок, появившихся в результате изменений в потребностях.

 

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

j) вводить необходимые изменения в порядок эксплуатации, среду функционирования, интерфейсы «человек-машина» и в обучение операторов, если ошибки человека приводят к отказам;

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

 

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

 

 

Процесс обслуживания

Цель процесса обслуживания

Цель процесса обслуживания состоит в поддержании способности системы выполнять заданные

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

 

Результаты процесса обслуживания

В результате успешного осуществления процесса обслуживания:

a) разрабатывается стратегия обслуживания;

b) ограничения процесса обслуживания применяются в качестве исходных данных при формировании системных требований;

c) становятся доступными системные элементы, используемые для замены;

d) осуществляется поддержка услуг, удовлетворяющих требования правообладателей;

e) в отчетах сообщается о необходимости корректирующих проектных изменений;

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

 

Деятельность в процессе обслуживания

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

 

a) подготавливать стратегию обслуживания.

 

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

 

1) стратегии корректирующего и превентивного обслуживания для поддержки реализации функций в среде функционирования с целью достижения удовлетворения заказчика;

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

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

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

 

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

 

П р и м е ч а н и е — Ограничения могут являться следствием необходимости:

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

2) повторного использования существующих запасов заменяемых системных элементов и согласования с ограничениями на повторную поставку;

3) проведения технического обслуживания в особых местах или средах;

 

c) получать обеспечивающие системы, системные элементы и услуги, которые должны быть использованы при обслуживании системы;

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

e) осуществлять процедуры исправления случайных неисправностей и (или) плановых замен системных элементов.

 

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

 

f) инициировать корректирующие действия по устранению ранее необнаруженных конструкционных ошибок

.

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

 

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

 

П р и м е ч а н и е — Необходимо контролировать качество и готовность элементов замены, транспортирование и целостность во время хранения, а также нанимать, обучать и аккредитовывать персонал для поддержания численности и навыков операторов;

 

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

i) выполнять действия по идентификации отказов при появлении любых несоответствий в системе;

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

9. Процесс планирования проекта и его связь со стандартами УП. WBS

Процесс планирования проекта

Цель

Цель процесса планирования проекта состоит в составлении и доведении до заинтересованных сторон эффективного и выполнимого плана.

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

Выходы

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

a) определяется область проведения работ по проекту;

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

c) определяются размеры и оцениваются задачи и ресурсы, необходимые для выполнения работы;

d) идентифицируются интерфейсы между элементами в проекте и с другими проектами и подразделениями организации;

e) разрабатываются планы реализации проекта;

f) активизируются планы реализации проекта.

Виды деятельности и задачи

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

Инициация проекта

Данный вид деятельности состоит из решения следующих задач:

· Менеджер должен определять требования инициируемого проекта.

Примечание - Определение этих требований включает в себя идентификацию целей, мотиваций и ограничений проекта.

· После определения требований проекта менеджер должен оценить осуществимость

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

· По мере необходимости и при согласии всех заинтересованных сторон требования проекта могут быть изменены на этом этапе для достижения критериев завершения.

Планирование проекта

Данный вид деятельности состоит из решения следующих задач:

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

a) графики работ для своевременного завершения задач;

b) оценку усилий;

c) ресурсы, необходимые для выполнения задач;

d) распределение задач;

e) распределение обязанностей;

f) количественное определение рисков, связанных с задачами или самим процессом;

g) мероприятия по гарантии качества для применения в пределах всего проекта;

h) затраты, связанные с выполнением процесса;

i) обеспечение окружающей среды и инфраструктуры;

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

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

Активизация проекта

Данный вид деятельности состоит из решения следующих задач:

· Менеджер должен получить полномочия на проект.

· Менеджер должен представить заявки на необходимые ресурсы для выполнения

проекта

· Менеджер должен инициировать выполнение планов проекта для удовлетворения совокупности целей и критериев осуществления управления проектом.

Стандарты IPMA и СОВНЕТ

International Competence Baseline (ICB)

• Правила и нормы работы специалистов по проектному менеджменту согласно требованиям IPMA отражены в документе под названием International Competence Baseline (ICB) – международных требованиях к компетенции специалистов в области управления проектами.
• Каждая национальная ассоциация отвечает за разработку собственных национальных требований к компетентности специалистов (NCB - National Competence Baseline), которые затем ратифицируются IPMA.
• Национальные ассоциации несут ответственность за сертификационные программы в своих странах. IPMA осуществляет ратификацию этих программ, на основе анализа их соответствия установленным правилам, стандартам и рекомендациям.
• ICB содержит 42 элемента, определяющие знания и опыт в управлении проектами (28 основных и 14 дополнительных элементов), а так же 8 аспектов, касающихся личных качеств кандидата и 10 аспектов, определяющих общее впечатление о сертифицируемом. IPMA требует, чтобы в NCB были включены все 28 основных элементов и, по крайней мере, 6 дополнительных элементов, выбранных на усмотрение национальной ассоциации. Кроме того, в NCB также должны быть представлены разделы, отражающие аспекты, касающиеся личных качеств и определяющие общее впечатление о кандидате.
•  В то же время, примерно 8 дополнительных элементов знаний и навыков (примерно 20% от 42 элементов) могут быть устранены или заменены на новые элементы, учитывающие национальные особенности и достижения в области управления проектами.

Национальные требования компетентности (НТК)

n НТК (Национальные Требования Компетентности) представляют собой основной нормативный документ Национальной программы сертификации в России. НТК разработаны в соответствии с требованиями IPMA, на основе ICB, и учитывают национальные особенности культуры, экономики и достижений в области проектного менеджмента в России.

n В основу НТК заложена системная модель управления проектами, которая опирается на три основных блока: субъекты управления, объекты управления и процессы управления. Каждый блок имеет иерархическую структуру, которая в свою очередь соотносится с разделами НТК.

 

Системная методология УП

q дерево целей, структура продукта, жизненный цикл продукта и проекта, структурная декомпозиция работ - WBS

q  методы построения организационной схемы участников проекта (OS) и организационные структуры в проекте (OBS)

q  определение задач УПП и объединение их в структурную декомпозицию функциональных задач управления (TBS);

q  методы построения всех разновидностей OBS, их взаимосвязи с TBS и WBS

q  декомпозиционные и композиционные методы представления информации в системе УПП

q  методы построения функциональных структур задач УПП

q  сетевые модели и методы календарного планирования комплексов работ в проекте

 

 

WBS – это структурная декомпозиция работ.

Мы декомпозируем проект: разбиваем его на составные части по какому-либо признаку.

Принципы построения структурной декомпозиции работ WBS

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

WBS строится по принципу правильного дерева, т.е. у одной ветки/листа может быть только один «родитель».

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

Декомпозируем настолько, насколько необходимо нам для управления. Как правило, элементарная работа – та, которую делает один человек и/или та, которую мы хотим контролировать как отдельную единицу.

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

На практике используются три типа основных элементов: 

n результаты проекта (продуктовая линейка)

n Областям функционального менеджмента (менее часто)

n фазы жизненного цикла проекта

Продуктовая, когда проект разбивается по элементам продукта проекта

Функциональная: декомпозиция по функциональным областям менеджмента

По этапам жизненного цикла проекта

ПОДТВЕРЖДЕНИЕ ОКОНЧАТЕЛЬНОСТИ ДЕКОМПОЗИЦИИ

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

n Являются ли элементы нижнего уровня структуры проекта необходимыми и достаточными для достижения разбиваемого результата?

n Правильно ли определены характеристики для каждого элемента структуры проекта?

n Можно ли каждый элемент структуры проекта отнести к соответствующему организационному подразделению (исполнителю)?

10. Использование сетевого графика и диаграммы Ганта при планировании проектов при внедрении систем

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

Сетевое планирование – набор методов, который предназначен для управления расписанием проекта.

ü Его основной инструмент – сетевой график, который позволяет вам:

· выявить перечень работ вашего проекта

· наглядно представить порядок их следования

· определить длительности каждой работы и всего проекта

· определить критические работы проекта и его критический путь

· определить резервы времени по каждой работе

· И т.д.

ü Определение перечня операций (элементарных работ), из которых состоит проект. Вам необходимо решить, насколько мелкие работы вы включите в график.

ü Оценка длительности операций

ü Выявление зависимостей работ (например, нельзя обучать пользователей, пока программы не установлены на компьютеры)

Пример.

Варианты сетевых графиков

Теперь можно построить сам сетевой график проекта (Network Diagram), который отражает последовательность выполнения работ.

Применяются 2 варианта сетевых графиков: «работа-вершина» и «вершина-событие».

В сетевом графике типа «работа-вершина», который называют также «диаграмма предшествования» (Precedence Diagramming Method, PDM), работы представлены «вершинами», обычно прямоугольниками. Наш сетевой график будет выглядеть следующим образом:

В сетевом графике типа «вершина-событие», называемом также «сетевой моделью» (Arrow Diagramming Method, ADM), работы изображают стрелками, а каждая стрелка должна начинаться и завершаться событием, которое изображают кружком. Чтобы отразить взаимосвязи, вводят фиктивные работы (отображаются пунктиром).

Исторические раньше возник метод «вершина-событие», однако в наше время чаще используется «работа-вершина», т.к. он нагляднее и удобнее.

Метод критического пути CPM

Далее проводят расчет сетевого графика. Сначала идут слева направо и рассчитывают ранние сроки работ (раннее начало и раннее окончание), а затем справа налево, получая поздние сроки работ (позднее начало и позднее окончание). Ранние сроки работы – это раньше которых она не может начаться/завершиться, поздние – крайние сроки ее начала/завершения.

Теперь можно применить метод критического пути, МКП сritical path method, CPM) – один из главных методов в проектном менеджменте. Те работы, у которых ранние и поздние сроки совпадают, называются критическими работами проекта, а в совокупности они образуют его критический путь.

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

Остальные работы (не критические) имеют временные резервы: частный и общий. Частный говорит нам о том, на сколько мы можем задержать работу, на задерживая ни одной работы-последователя. Общий – на сколько можно задержать работу, задержав работы-последователи, но все же завершив проект в срок.

Диаграмма Ганта

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

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

Уровни жизненного цикла (по Амблеру)

Одним из ключевых понятий управления проектами, в том числе в приложении к индустрии программного обеспечения, является жизненный цикл проекта (Project Life Cycle Management - PLCM).

 

Арчибальд так определяет жизненный цикл проекта [Арчибальд Р., 2003, с.58-59] [Арчибальд Р.2005]: «Жизненный цикл проекта имеет определенные начальную и конечную точки, привязанные к временной шкале. Проект в своем естественном развитии проходит ряд отдельных фаз»

 

Жизненный цикл автоматизированной системы (АС) - совокупность взаимосвязанных процессов создания и последовательного изменения состояния АС, от формирования

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

автоматизации АС [ГОСТ 34, 1990].

 

Скотт Амблер, автор концепций и практик гибкого моделирования (Agile Modeling) и Enterprise Unified Process (расширение Rational Unified Process), предлагает следующие уровни жизненного цикла, определяемые соответствующим содержанием работ:

 

• Жизненный цикл разработки программного обеспечения (проект) – проектная деятельность по разработке и развертыванию программных систем

• Жизненный цикл программной системы (ИС или ПО) – включает разработку, развертывание, поддержку и сопровождение

• Жизненный цикл информационных технологий (ИТ-департамент) – включает всю деятельность ИТ-

департамента

• Жизненный цикл организации/бизнеса (организация) – охватывает всю деятельность организации в целом

 

Рисунок 1. Содержание четырех категорий жизненного цикла по Амблеру