CC BY
103
ЭВОЛЮЦИЯ МЕТОДОЛОГИИ УПРАВЛЕНИЯ IT-ПРОЕКТАМИ В СОВРЕМЕННЫХ ЭКОНОМИЧЕСКИХ УСЛОВИЯХ Маркин В.Ю. Email: [email protected]
Маркин Виталий Юрьевич - студент магистратуры, кафедра бизнес информатики, Московский технический университет связи и информатики, г. Москва
Аннотация: в статье исследована эволюция методологии управления проектами как инновационного подхода в управлении, рассматриваются различные методики управления проектами, проанализированы возможности адаптации методик к новым экономическим условиям. Особое внимание уделено в статье гибким (Agile) и жестким (каскадным) типам методологий. По результатам анализа установлено, что использование гибкой методологии Scrum целесообразно в нестабильной экономической ситуации, которая актуализируется в современных условиях развития украинской экономики.
Ключевые слова: информационное общество, управление проектами, гибкая методологии (Agile), жесткая методология, Scrum методология.
EVOLUTION OF THE METHODOLOGY FOR MANAGING IT PROJECTS IN MODERN ECONOMIC CONDITIONS
Markin V.Yu.
Markin Vitaliy Yuryevich - Graduate Student, DEPARTMENT OF BUSINESS INFORMATICS, MOSCOW TECHNICAL UNIVERSITY OF COMMUNICATIONS AND INFORMATICS, MOSCOW
Abstract: the article explores the evolution of project management methodology as an innovative approach to management, examines various project management methodologies, and analyzes the possibilities of adapting methods to new economic conditions. Particular attention is paid in the article to flexible (Agile) and hard (cascading) types of methodologies. According to the results of the analysis, it was found that the use of the flexible Scrum methodology is advisable in an unstable economic situation, which is updated in the current conditions of the development of the Ukrainian economy. Keywords: information society, project management, agile methodology (Agile), rigorous methodology, Scrum methodology.
УДК 331.225.3
Введение.
Про^ссы, происходящие в современном информационном обществе, где пeрeдний план выходит производство знания и информации, всe с большим очeвиднистью дeмонструют взаимосвязь и взаемозалeжнисть глобализации и роста роли информационно-комуникационних тeхнологий.
Организации на тeрeнах современности могут существовать и быть конкурeнтоспособнами лишь при бесперебойном развитии и значительных ресурсах адаптации к меняющимся условиям ведения бизнеса, внедрении IT-технологий. Проeктно-тeхнологичный тип организационной культуры, внедрение в экономику новых форм управления предоставляет конкурентные преимущества и в этом контексте в последние десятилетия чрезвычайно актуализируется проблематика управления проектами.
Именно проeктная деятельность решает проблемы своевременной адаптации к внешним условиям, что мимолетно меняются. С другой стороны, непрерывное развитие информационных технологий приводит к увеличению влияния информационных
технологий на саму проектную деятельность. Есть различные виды методик управления проектами, использование которых по-разному влияет на результат и процесс выполнения, но не все возможно адаптировать к экономическим условиям в стране, поскольку каждая вышеупомянутая методика должна учитывать потраченное время и материальные ресурсы в достижении поставленных целей проекта.
Анализ последних исследований и публикаций.
Проблeмам управления проeктом просвящены работы многих зарубежных и отечественных исследователей. Так, в исследовании В.Н. Буркова и Д.А. Новикова [1] представлено целостное представление обо всем комплексе механизмов, используемых на различных этапах проектов, начиная с определения целей проекта и заканчивая на этапе оперативного реагирования. Б. Трейси [7] в своей работе рассматривает конкретные проблемы оптимизации, производительности и эффективности достижения результата проекта. С.В. Пятенко [6] считает, что ключевым ингредиентом успеха проекта является управление проблемами.
Проблеме управления проектом просвящены работы В. Вязовой [5]. Д. Сазерленд [3] в своей книге раскрывает философию Scrum - революционного метода управления проектами, считая, что успех проекта зависит от методологии его управления. В.М.Кожухарь [2] обращает внимание на фактор рыночной экономики, отмечая, что управление рисками является частью деятельности управления проектами [2]. И.Г. Чиркова и К.Ч. Акберов [4] считают, что проект нуждается в технико-экономической оценй. А.А. Трусь [8] акцентирует на партнерском взаимодействии и мотивации сотрудников как неотъемлемых факторах продуктивной работы.
Изложение основного материала исследования.
Управление проектами в области информационных технологий должщ соответствовать основным критерии, выполнение которых обеспечивает качество проекта. Поскольку разработка программного обеспечения, как и любая другая техническая дисциплина, имеет дело с такими основными проблемами как качество, стоимость и надежность, то в выборе методики следует ориентироваться как на конечную цель, продукт проекта, так и на финансовые и временные показатели.
Рассматривая различные методологические подходы к управлению IT-проектами в различных отраслях экономики, проанализируем каскадную модель, которая была в использовании до 2005 года.
Каскадная модель относится к моделям классического жизненного цикла. Этапы разработки классической каскадной модели выглядят следующим образом:
• Анализ требований проекта;
• Проектирование продукта;
• Реализация ПО;
• Тестирование продукции;
• Интеграция системы;
• Поддержка ПО.
Переход на каждый следующий этап в данной модели возможен только после успешного завершения предыдущего этапа. Такая жесткая последовательность позволяет формализовать процесс разработки, что делает его чрезвычайно прозрачным, при этом реальная протяженность этапов часто не соответствует промежуткам времени, определенных на графиках и в документации. При необходимости внесения поправок в документацию разработка продукта останавливается до момента повторного согласования документов. Следовательно, при недостаточном уровне проработки требований существует риск увеличить сроки разработки до абсолютно неприемлемых величин, изменяя объемы расходов. Каскадная модель предполагает строго последовательное (во времени) и единовременное выполнение всех фаз проекта по жестким (детальным) предварительным планированием в контексте определенных единовременно и полностью определенных требований к программной системе.
Такая сложная система занимает большое количество времени, которое будет отведено на составление графиков и документации перед началом разработки проекта. Этапы проекта в соответствии с каскадной моделью: Формирование требований, проектирование; реализация; тестирование; внедрения; эксплуатация и сопровождение. Водопадная схема включает несколько важных операций, которые можно применить ко всем проектам: составление плана действий по разработке системы; планирование работ, связанных с каждым действием применения операции отслеживания хода выполнения действий с контрольными этапами. В связи с тем, что упомянутые задачи является неотъемлемым элементом всех хорошо управляемых процессов, практически не существует причин, препятствующих утверждению полнофункциональных, классических методов руководства проектом, таких как анализ критического пути и промежуточные контрольные этапы.
Вот как описывает эту процедуру Джонсон, который работал над проектом «Страж»: «Вы составляли в текстовом редакторе подробную записку и распечатывали ее в трех экземплярах. Одну копию посылали на утверждение, и она проходила всю цепочку до самого верха. Вторую отправляли в местный архив на случай, если первая потеряется. Ну, а с третьей вы садились, брали красную ручку - да-да, я не шучу, красную ручку - и обводили ключевые слова для занесения в базу данных. Вы индексировали собственный отчет». Таким образом, «на Бюро возложили вину, что его подразделения не сумели связать все сведения воедино и выявить многочисленных активистов «Аль-Каиды», въехавших в страну по месяцы и даже считанные недели до 11 сентября» [2, с. 13].
«Мы имели информацию, которая могла бы предотвратить события 11 сентября. А они там сидели, и никто не предпринял никаких мер ... Я до сих пор не вижу, что они устраняют проблему ... Пока мы дойдем до технологии XXI века, уже наступит XXII века» [4, с. 5].
Таким было признание Патрика Лехи, сенатора-демократа от штата Вермонт, которое он обнародовал на страницах Washington Post. Анализируя процесс управления неудачным проектом «Страж» и другими, можно сделать выводы, что проблема заключается в способе работы и методе, которым пользуются для управления этими проектами. Обычно это делали следующим образом: изучали потребности заказчика, по потребностям шло их решение; длительное планирование, что нужно сделать; длительное обдумывание, как это нужно осуществить, работа над графиками, «где были обозначены и все подробности, которые нужно выполнить, и время, которое потребуется на каждую задачу. Затем за счет точного подбора цветов, они показывали, как каждая фаза проекта последовательно переходит в следующую -все это напоминало водный каскад» [2, с. 16].
Работа по каскадной модели требует также дополнительного рабочего места, в обязанности работника входит своевременное пополнение и обновление графиков. Джефф Сазерленд в книге «Scrum» сравнивает этот метод с организацией работы в ЦК КПСС, когда власть Советского Союза получала отчеты перед распадом СССР и истинно верила написанному диаграммам. «Сегодня, как и в те годы, отчеты продолжают быть важнее действительности - но они, судя по всему, призваны ее описывать, - но, если вдруг всплывут несоответствия, то виновным называют реальность, а не диаграмму [2, с. 18].
Имея опыт того, что именно Scrum смог завершить систему «Страж», можно делать выводы, что это единственная правильная методика, которая способна реализовать такие проекты. «В ФБР утверждают, что для завершения проекта «Страж» они прибегали к «гибкой методологии разработки» [2, с. 25], что означает использование методологии Scrum. Первая проблема, с которой столкнулось команда по работе завершения проекта «Страж», была документация, разбор которой слишком большой объем ресурсов. «Мне приходилось видеть бумажные столбы высотой более метра. Из проекта в проект я наблюдаю одно и то же: как копируются стандартные
формулировки и вставляются в бесконечные документы, но никто толком их не читает», - вспоминает Джонсон. Но при всех этих обстоятельствах «была создана система, заставляющая людей одобрять пустые иллюзии» [2, с. 24].
Модель WaterFall относится к жесткому типу моделей и является наиболее распространенной моделью среди моделей жизненного цикла разработки программного обеспечения. Она очень проста для понимания и использования. В этой модели каждая фаза должна быть завершена к следующему этапу. В конце каждого этапа проводится обзор, который помогает определить, находится проект на правильном пути и будет ли этот проект продлен [8].
Модель WaterFall может быть реализована для любого размера проекта. Каждый этап должен осуществляться отдельно в нужное время, постепенно переходя от предыдущего к следующему этапу, полностью закончив предыдущий. Документация, которая заполняется на каждом этапе модели WaterFall, позволяет людям понять, что было сделано.
Методика WaterFall состоит из последовательных, непересекающихся фаз, где одна фаза не может начаться, пока предыдущая фаза еще не завершена. В конце каждого этапа е контрольная фаза, где принимается решение о том, разрешить проекта двигаться вперед или нет (этап Gate). Основные изменения разрешены только если CCB (Board Control Change) утверждает их. Продукт завершен только в конце последней фазы. После того как проект будет сделан, продукт/услуга входит в фазу обслуживания. Схема данной модели делится на этапы или фазы. Первый этап, который включает в себя сбор требований и анализ. Это первая фаза модели WaterFall, которая включает в себя встречу с клиентом, чтобы понять его требования. Это наиболее важный этап, любая неправильная интерпретация требований на данном этапе может привести к возникновению проблем с проверкой и выполнением позже. Очень важно понять требования и ожидания заказчика, чтобы конечный продукт соответствовал его требованиям.
Основные требования к системе должны быть понятны инженерупрограмисту, или, как его еще называют, аналитику. Все требования качественно документируются и обсуждается подробно с заказчиком. Вторая фаза является детальным проектированием (дизайн). Требования заказчика разбиты на логические модули для простоты реализации. Требования к аппаратному и программному обеспечению для каждого модуля идентифицируются и разрабатываются соответствующим образом. Кроме того, на данном этапе устанавливается связь между различными логическими модулями, алгоритмы и схемы, определяются масштабы и цели каждой логической модели. Короче говоря, эта фаза является фундаментом для фактического программирования и осуществления работы. Это промежуточный этап между анализом требований и кодированием. Все процессы и конструкция должны быть задокументированы для дальнейшего использования.
Третья фаза кодирования представляет собой стадию, в которой дизайн превратится в формы. Если конструкция делается достаточно подробно, то кодирование может быть сделано эффективно. На этом этапе разрабатываются программы. Все программное обеспечение делится на небольшие модули, производится кодирование для этих небольших модулей.
На четвертом этом этапе проводится методическое тестирование как отдельных компонентов, так и целого, для убеждения, что они свободны от ошибок и в полной мере соответствуют требованиям, изложенным в первом шаге (сбор требований и анализ).
Техническое обслуживание является последней фазой модели WaterFall, в которой завершен программный продукт уже передан клиенту после того, как прошел альфа и бета-тестирования. Если клиент предлагает внести изменения или усовершенствовать программное обеспечение, нужно возвращаться к первой фазе, к анализу требований.Недостатки WaterFall модели.
1. Анализ требований на первом этапе может не соответствовать ожиданиям, заявленным заказчиком. Это означает, что команда должна проходить снова все этапы с самого начала и до конца, на что будет потрачено дополнительное время и средства.
2. Клиент может увидеть действующую модель проекта только в конце. Как нам кажется, это является минусом, потому что это единственный момент, когда он может вносить правки, следовательно, ошибки, которые были допущены ранее, сводят всю разработку проекта на нет.
3. Мы не можем вернуться на предыдущий этап, эта модель этого не позволяет.
4. Трудно проследить последовательность в процессе разработки программного обеспечения [11].
Главной причиной популярности каскадной модели программирования следует назвать вышеупомянутую прозрачность процесса разработки - благодаря последовательному переходу от этапа к этапу и высокому уровню формализации процесса, управление масштабными проектами осуществляется гораздо проще, а команда, в свою очередь, работает более слаженно.
Кроме того, жесткая последовательность позволяет дать точную оценку стоимости разработки проекта и его терминов, позволяет точно спрогнозировать эффект, полученный от запуска приложения.
Но, сталкиваясь с реальными обстоятельствами, очень часто трамляються задержки с запусками проектов и отклонения от указанного бюджета. Возникает множество вопросов о ценности каскадной методики для современного общества и новых технологических особенностей современного мира, поскольку усилия, затраченные на создание графиков и их адаптации к процессу, уступают меняющимся обстоятельствам современного постиндустриального мира.
Джефф Сазерленд говорит о методиках так: «Существует два подхода к работе: старый« каскадный »- при нем выбрасываются на ветер сотни миллионов долларов, и часто он так ни к чему и не приводит; новый - когда обязательства выполняются меньшими силами, в короткие сроки и с низкими затратами, а итоговый продукт отличается отличным качеством и обеспечивает высокую производительность» [2, с. 20].
Проанализируем подход, который поддерживает различные методики гибкой разработки проектов. Agile-методологии имеет свои принципы, описанные в Agile -манифесте, которые позволяют организовать дисциплинированный гибкий процесс управления IT-проектом, проводя всю работу итерациями с промежуточными проверками, создавая слаженную самоорганизующуюся команду разработчиков и осуществляя постоянную коммуникацию с заказчиком. Наиболее распространенной является методология разработки Scrum, которую можно считать набором конкретных практик, используемых в процессе разработки программного обеспечения.Agile подход к управлению проектами был создан в 1995 году в рамках совместных усилий между APMG- международных систем, метод развития (DSDM) Консорциум [7]. Agile подход базируется на принципе управления взаимодействиями людей и основан на процессе человеческого сотрудничества. Подход используется в программном обеспечении, веб-сайт-технологии, а также в творческой сфере и индустрии маркетинга. В Agile подходе проект воспринимается как ряд относительно небольших мероприятий, задуманных и использованных для управления в соответствии с адаптивных методов, в отличие от того, что имеет предварительно спланированный процесс [5].
Подход Agile управления проектами имеет три отличительные черты:
• Частое тестирование проекта на стадии разработки;
• Это единственный подход, который активно привлекает клиента в процессе управления проектами;
• Как правило, клиент должен участвовать в этапах разработки процесса и привлекаться к взаимодействию. Scrum - подход к разработке программного обеспечения для технологических отраслей.
Эта методология была разработана Кеном Швабер и Джеффом Сазерлендом в 1993 году. Эта методология была более быстрой, надежной и эффективной, как утверждали ее авторы, по сравнению с классическими методиками управления проектами, такими как Водопад V-модель и другими. Согласно определению, Scrum - это каркас разработки, с использованием которого люди могут решать проблемы, которые появляются, продуктивно и производя продукты высочайшего значимости [2].
Командная игра (столкновение), именно так переводится слово Scrum. «Этот метод позволяет участникам группы эффективно взаимодействовать как с заказчиком, так и друг с другом во время всего процесса разработки» [2, с. 5]. Как видим, в методологии Scrum большое значение как фактора успешности предоставляется командной работе при полном взаимодействии участников команды и четком понимании ее цели. Адепты Scrum исповедуют творческий подход к работе, тем самым позволяя команде добиваться высоких результатов, не теряя веры в свои силы. Идея методологии Scrum: «Если бы не был запущен проект, вам ничто не мешает регулярно проверять ход работ и последовательно выяснять: справляетесь вы с задачей; или в нужном направлении двигаетесь; или создаете именно то, что на самом деле хочет получить заказчик» [2, с. 22].
Результатом успешного анализа потребностей управления проектами стал «Манифест гибкой методологии разработки программного обеспечения», разработанный Д. Сазерлендом, который провозглашал следующие ценности: «люди важнее процессы; фактическая работа продукта важнее, чем документация, фиксирующая, что и как продукт должен делать; сотрудничество с заказчиком важнее обсуждения условий договора с ним; реакция на изменения важнее, чем соблюдение предварительного плана. Scrum - это концепция, созданная ..., чтобы воплотить эти ценности в жизнь. Не существует никакого единого подхода под названием «гибкая методология» [2, с. 17].
При использовании «гибких» методологий задача проекта разбиваются на малые части (итерации) с тщательным краткосрочным планированием и почти незначительным долгосрочным планированием. В методологии Scrum команда является сомоорганизованою и самоуправляемой. Команда в Scrum кроссфункциональна. В нее входят люди с разными навыками - разработчики, аналитики, тестировщики. Благодаря постоянному анализу проделанной работы и возможностям осуществлять корректировку направления проекта между итерациями, (спринт) методология «скрам» позволяет более качественно разработать программное обеспечение и достичь продуктивных результатов. На сегодняшний день каскадная модель управления проектами уже практически не используется в своем первоначальном виде, что обусловлено малой гибкостью модели и ее старением относительно новейших технологий и информационного развития общества. Одна из первых моделей программирования, которая когда-то отвечала всем требованиям времени, сегодня используется только в сочетании с более современными методами, образуя гибридные модели.
Выводы из проведенного исследования.
Выбор методики управления проектами является жизненно важным для реализации успешного проекта. Выбор конкретного подхода к управлению проектами обусловлен целым рядом факторов, в том числе в период реализации проекта, факторами стоимости, сложности проекта и т.д., различные методологии имеют различные функции, которые подходят для конкретных требований проекта.
Каскадное управление является более актуальной методике управления проектами при стабильной экономике, поскольку имеет жесткий контроль за качеством и регистрацию всех процессов на документальном уровне. Это позволяет контролировать график выполнения и анализировать работу над проектом более пристально, используя дополнительные финансы. Данная документация будет сохраняться до окончания работы над проектом и до его конечного выпуска. При
невыполнении какого-то этапа разработки будут требоваться дополнительные средства для возвращения на прошлые этапы и их корректировки.
Скрам - гибкая методология, которая позволяет просчитывать риски по счет поэтапного выполнения частей проекта. Возвращение к прошлым этапов, используя дополнительные средства, не будет нужен, поскольку команда скрам выполняет проект частями, в заданный срок, позволяет корректировать прошлые ошибки без больших финансовых затрат.
Скрам команда многофункциональная и самостоятельная, каждый член команды не имеет четких ролей и ответственности за проект лежит на ней в целом, не предусматривает жесткого контроля за отдельными членами команды. Одним из основных принципов Scrum является самоорганизация, многофункциональность команды. Вместе с тем необходимо отметить, что согласно исследованиям социологов, численность способных на самоорганизацию, лично мотивированных сотрудников не превышает 15% от трудоспособного населения [3].
Методология Скрам может обеспечить изменения в желаниях клиента на всех этапах разработки проекта. Такое отношение к управлению влечет за собой изменения в оплате заработной платы, но гарантирует то, что на выходе проект будет выполнен в том варианте, который будет действительно нужен заказчику. Идеология Scrum утверждает, что заранее невозможно предусмотреть все изменения, таким образом нет смысла заранее планировать весь проект, ограничившись лишь частичной планировкой, что является актуальным в нестабильной экономической ситуации.
Список литературы /References
1. Бурков В.Н., Новиков Д.А. Как управлять проектами / В.Н. Бурков, Д.А. Новиков. М: Синтег, 1997. 190 с.
2. Кожухар В.М. Инновационный менеджмент / В.М. Кожухар. М: Издательство Ассоциации строительных вузов, 2012. 292 с.
3. Сазерленд Д. Scrum. Революционный метод управления проектами / Джефф Сазерленд. МИФ. Бизнес, 2016. 288 с.
4. Чиркова И.Г, Акберов К.Ч. Внутрифирменное планирование проектной деятельности: учебное пособие / И.Г. Чиркова, К.Ч. Акберов. Н: НГТУ, 2015. 64 с.
5. Вязовой В. Управление проектами в строительстве. / В. Вязовой // [Электронный ресурс]. Режим доступа: http://www.e- xecutive.ru/management/practices/338248-upravlenie-proektami-vstroitelstve/ (дата обращения: 03.03.2020).
6. Пятенко С.В. Методы анализа наиболее типичных проблем управления проектом. / С.В. Пятенко// [Электронный ресурс]. Режим доступа: https://iteam.ru/publications/project/section_35/article_2808/ (дата обращения: 03.03.2020).
7. Трейси Б. Управляй своим временем и удвой результаты. / Б. Трейси // [Электронный ресурс]. Режим доступа: http://www.rulit.me/books/upravlyaj-svoim-vremenem-i-udvoj-rezultatyread-443214-2.html/ (дата обращения: 03.03.2020).
8. Трусь А.А. Психология управления. / А.А. Трусь // Вышэйшая школа, 2014. [Электронный ресурс]. Режим доступа: http://mreadz.com/read-296679/ (дата обращения: 03.03.2020).
9. Bhargav R. Waterfall model / Bhargav // [Электронний ресурс]. Режим доступа: http://www.slideshare.net/BHARGAV_VISANI/waterfall-model. 10.Pichler R. Agile product management with Scrum: creating products that customers love / Pichler // [Электронный ресурс]. Режим доступа: http://www.romanpichler.com/romans-books/agile-product-managementwith-scrum/ (дата обращения: 03.03.2020).
10. Satalkar B. Waterfall Model vs. V Mode / Satalkar // [Электронный ресурс]. Режим доступа: http://www.buzzle.com/articles/waterfall-model-vs-vmodel.html/ (дата обращения: 03.03.2020).
11. Schwalbe К. Information Technology Project Management. / К. Schwalbe // [Электронный ресурс]. Режим доступа: http://www.twirpx.com/file/1283991/ (дата обращения: 03.03.2020).
КАНБАН КАК МЕТОД УПРАВЛЕНИЯ ПРОЕКТАМИ В РАЗЛИЧНЫХ СФЕРАХ ДЕЯТЕЛЬНОСТИ Маркин В.Ю. Email: [email protected]
Маркин Виталий Юрьевич - студент магистратуры, кафедра бизнес-информатики, Московский технический университет связи и информатики, г. Москва
Аннотация: в статье анализируется применение методики управления проектами «КАНБАН» в различных сферах деятельности общества. С увеличением влияния на все сферы деятельности информационных технологий методика «КАНБАН» приходится как нельзя кстати. «КАНБАН» является информационной системой, которая организует компанию в единое целое, устанавливает связи между различными процессами и координирует поток создания ценностей в соответствии с потребительским спросом. Учитывая гибкость методики «КАНБАН», применить ее можно повсеместно, однако не следует забывать о принципах, на которых построена эта система и которые не следует нарушать для ее правильного функционирования.
Ключевые слова: управление проектами, методология «КАНБАН», информационные технологии, управление производством, внедрение информационных систем
KANBAN AS A METHOD OF PROJECT MANAGEMENT IN VARIOUS FIELDS OF ACTIVITY Markin V.Yu.
Markin Vitaliy Yuryevich - Graduate Student, DEPARTMENT OF BUSINESS INFORMATICS, MOSCOW TECHNICAL UNIVERSITY OF COMMUNICATIONS AND INFORMATICS, MOSCOW
Abstract: the article analyzes the application of the KANBAN project management methodology in various areas of society. With the increasing influence on all areas of information technology, the KANBAN technique comes in handy. KANBAN is an information system that organizes a company as a whole, establishes relationships between different processes and coordinates the flow of value creation in accordance with consumer demand. Considering the flexibility of the KANBAN methodology, it can be applied everywhere, but we should not forget about the principles on which this system is built and which should not be violated for its proper functioning.
Keywords: project management, KANBAN methodology, information technology, production management, implementation of information systems.
УДК 65.011
В современном мире человеческая деятельность в любом ее виде требует особого контроля и управления благодаря быстрому развитию общества и увеличению влияния информационных технологий на проектную деятельность. Возрастает потребность в четком регулировании экономики, времени и других ресурсов, которые
