CC BY-NC
60Программные системы и вычислительные методы
Правильная ссылка на статью:
Тиханычев О.В. — Управление разработкой и управление проектами: противопоставление или дополнение? // Программные системы и вычислительные методы. - 2020. - № 2. DOI: 10.7256/2454-0714.2020.2.29603 URL: https;//nbpublish.com'library_read_article.php?id=29603
Управление разработкой и управление проектами: противопоставление или дополнение?
Тиханычев Олег Васильевич
кандидат технических наук заместитель начальника отдела, ГК "Техносерв 111395, Россия, г. Москва, ул. Юности, 13
tow65@yandex.ru
Статья из рубрики "Автоматизация проектирования и технологической подготовки производства"
DOI:
10.7256/2454-0714.2020.2.29603
Дата направления статьи в редакцию:
01-10-2019
Аннотация.
Предметом исследования является процесс разработки программного обеспечения автоматизированных систем управления. Объект исследования - средства организации разработки программного обеспечения. Общепризнанное перспективное направление повышения эффективности применения организационно-технических систем -автоматизация управления ими. Существенную долю эффективности любой сложной технической системы обеспечивает её программное обеспечение. В первую очередь это относится к прикладному программному обеспечению. Разработка прикладных программ сопряжена с определёнными трудностями, в первую очередь - организационного характера. Обобщённый анализ показал, что в мировой практике существует достаточно широкий спектр средств организации процесса разработки программ. Эти средства предлагается разделить на две крупные группы относительно отношения к процессу и степени детализации на «средства управления проектами» и «средства управления разработкой». Каждое из средств эффективно для тех или иных условий разработки программного обеспечения. В обзорной статье проведён анализ факторов, влияющих на эффективность применения того или иного средства, синтезированы предложения по целесообразности использования различных систем управления в разных условиях процесса разработки. Анализ показал, что для условий разработки прикладного программного обеспечения автоматизированных систем поддержки принятия решений наибольшую эффективность обеспечивает комплексное применение средств автоматизации управления процессами
Ключевые слова: управление процессами, управление разработкой, организация процесса разработки, технологии разработки программ, программное обеспечение, автоматизированные системы управления, поддержка принятия решений, автоматизация управления, оптимизация процесса разработки, уточнение терминологии
Введение
Одной из составляющих современных сложных технических систем является программное обеспечение (ПО). В постиндустриальную эпоху, роль этого компонента постоянно растёт, увеличивается объём разрабатываемого ПО, ужесточаются требования к срокам и качеству разработки.
Для повышения эффективности разработки ПО в настоящее время используются различные методологии: «гибкие» Agile, «каскадные» Waterfall, их варианты -Ш.
Под «гибкими» технологиями принято понимать обобщающий термин для целого ряда подходов и практик, основанных на последовательной доработке разрабатываемого продукта в соответствии с постоянно уточняемыми требованиями заказчика. Сущность «гибкого» подхода - минимизация рисков путём сведения разработки к серии коротких
циклов [2,3].
Каскадная модель разработки основана на том, что процесс разработки выглядит как поток, последовательно проходящий типовые фазы работы: анализ требований, проектирование, реализация продукта, тестирование, внедрение и поддержка
функционирования J4!.
На практике указанные методологии применяются через систему прикладных технологий и набор реализующего их инструментария. В рамках этих технологий, как в программировании, так и в других областях деятельности, для повышения эффективности рабочих процессов в практике управления принято использовать различные средства автоматизации управления коллективами разработчиков (Team Foundation Server - TFS, Jira, Gemini, Savana, Redmine, Trac, TaskJuggler, Toyota Kanban, Microsoft Project, Wrike, Confluence).
Большинство специалистов перечисляют и описывают эти средства как альтернативные между собой, выбирая и оценивая качества и возможность использования каждого из них преимущественно автономно [5,6].
В первом приближении, это кажется логичным: функционал данных систем похож -управление группами разработчиков, координация их деятельности с целью оптимизации достижения конечного результата. С другой стороны, такое приближение не совсем корректно, перечисленные системы имеют определённые различия и похожие черты, не в полной мере заменяя друг друга. Как представляется, проблема находится в области классификации систем управления технологическими процессами относительно их функционального назначения. Проблема является новой и, в сформулированной постановке, ранее не обсуждалась.
Таким образом, существующий подход порождает проблемы использования средств автоматизации управления разработкой ПО, снижая возможности и эффективность применения средств организации процесса. Возникает научно-практическая задача уточнения классификации методов управления коллективами разработчиков, попытка
чего предпринята в данной статье.
1.Особенности средств управления проектами и разработкой программ
Как показывает опыт применения средств автоматизации управления коллективами разработчиков, в том числе лично автором, при одинаковом функционале они могут различаться областью применения. Например, TFS или Jira применяются при управлении разработкой программных продуктов [7,8], Toyota Kanban - при разработке
машиностроительной продукции А Microsoft Project, Wrike, Confluence или «Адванта» реализуют более широкий, но менее специализированный функционал и обеспечивают управление работой коллектива в целом. Конечно, есть отличия и внутри классов, например, между средствами управления разработкой программной продукцией и продукцией машиностроения. Наиболее заметное: при разработке промышленной продукции существенная роль возлагается на системы подбора по каталогам готовых деталей и типовых сборочных единиц, соответствующих требованиям к
разрабатываемому изделию [10'11]. При управлении разработкой программного продукта эти системы не используются по крайней мере, пока. Но перечисленные отличия определяются подходами к требуемому результату, да и то только в текущей ситуации. С переходом к промышленным методам разработки программного обеспечения, внедрением фондов типовых алгоритмов и программ, могут измениться и указанные функции. Указанные факты подтверждают актуальность проблемы уточнения классификации средств управления коллективами разработчиков.
Сравнивая особенности вышеперечисленных систем, можно сделать вывод, что многие проблемы выбора для использования тех или иных систем возникают из-за используемой в настоящее время терминологии их описания. Все системы управления коллективами разработчиков, принято обозначать термином, сформулированным на основе прямого перевода английского понятия «project management» (управление проектами). Формально это правильно. В то же время, исходя из функционала, логичнее часть из них назвать не системами управления проектами, а системами управления разработкой (development management). В данном случае речь идёт о средствах типа TFS и Jira, обеспечивающих не только управление самим процессом разработки, но и реализацию части технологических функций: тестирование, сборка программного продукта и т.п. [1214]. Уточнение терминологии позволит разделить и области применения инструментария, определив рациональность его выбора для реализации тех или иных функций и этапов жизненного цикла программной продукции Такой вывод позволяет сделать
обобщение опыта автора по разработке программной продукции специального назначения в нескольких крупных проектах, включая разработку системы «Безопасный город», с использованием таких средств организации процесса как TFS, Jira и Confluence.
Уточнённая классификация систем управления коллективами разработчиков может быть обоснована на основе сравнительного анализа характеристик различных средств автоматизации управления разработкой. И синтезом на основе данных анализа предложений по классификации таких систем.
В качестве первого этапа анализа предлагается проанализировать управляющие компоненты подобных систем: входные и выходные формы программ, которые их реализуют.
Как показывает анализ, внешне формы, функции и даже управляющие элементы средств управления разработкой похожи. Методы представления и управления списком задач,
«доской» работ, виджеты отображения хода выполнения проекта аналогичны и в TFS, и в Jira, и в других системах управления разработкой ПО. Похожи между собой и экранные формы различных систем управления проектами, их основные функции. А вот между формами программ управления проектами и управления разработкой внешнее сходство встречается реже. И даже в случае сходства, компоненты существенно различаются по реакции и содержанию функций (рисунки 1-3).
Рис.1. Внешний вид форм панелей задач систем управления разработкой TFS (наверху) и
Jira (нижний рисунок)
Рис.2. Внешний вид форм «досок» задач систем управления разработкой TFS (сверху) и
Jira (нижний рисунок)
Рис.3. Внешний вид аналогичных форм средства управления проектами Wrike
Таким образом, даже внешне между программами, реализующими разные по функционалу системы одного назначения, различий больше, чем сходных черт.
Второй этап анализа предлагается реализовать через сравнение функционала систем управления коллективами разработчиков. Несмотря на аналогичное целевое назначение, различия в функционале систем такого типа существенно различаются:
- по уровню формализации задач исполнителям проекта;
- по возможности взаимодействия со сторонними системами;
- по наличию встроенных средств автоматизированного тестирования и сборки программ.
По факту, хотя и те, и другие системы управляют работой персонала, оптимизируя использование наличных ресурсов и времени, системы управления разработкой в большей степени обеспечивают управление разработчиками и технологическими процессами, а системы управления проектами - руководство коллективами и маркетинговыми процессами [16,17,18].
2.Функциональные особенности средств управления разработкой и управления проектами
Процесс разработки ПО, в соответствии с требованиями нормативной документации, состоит из тех же этапов, что и создание автоматизированных систем управления, в составе которого оно реализуется:
- формирование требований, разработка концепции автоматизированной системы;
- формализация и детализация требований, разработка технического задания на работу по с о з да нию с ис те мы;
- разработка проектных решений по созданию системы в рамках эскизного и технического проектов;
- разработка опытного образца и рабочей конструкторской документации, приёмосдаточные испытания и сертификация системы;
- производство, ввод в действие;
- сопровождение эксплуатации системы.
Работа по каждому из этих этапов организуется в соответствии с типовым циклом управления: от целеполагания до постановки задач и контроля их выполнения.
Для реализации тех или иных функций типового цикла управления, на практике используется достаточно широкий перечень систем различного назначения: ERP (Enterprise Resource Planning), CRM (Customer Relationship Management), BI-системами (Business Intelligence) графического представления данных, средствами командно-сетевого планирования (КСП-системы), PLM-систем (Product Lifecycle Management), систем автоматизированного тестирования (Automation Testing System - ATS), средствами интеграции приложений (EAI - Enterprise Application Integration) и других [19-21]. Наличие EAI является достаточно важным фактором, учитывая, что системы управления производством редко разрабатываются под конкретный проект, чаще используются готовые системы, имеющиеся в активе предприятия [22, 23].
С учётом стандартной структуры типового цикла управления и решаемых в нём задач различной направленности, часть функций этих систем пересекается. Вполне вероятна такая ситуация и для систем классов «управление проектами» и «управление разработкой». Причём, как в части пересечения отдельных функций с внешними системами, так и между собой.
Сравнительный анализ функционала типичных представителей классов систем управления разработкой и управления проектами относительно пользовательских свойств систем различного целевого назначения позволил сформировать оценки, прив е дё нные в та б лице 1.
Таблица 1 - Соответствие функционала систем управления процессами и разработкой возможностям других систем автоматизированного управления
Функция системы автоматизированного управления В системах управления про е кта ми В системах управления разработкой
СЯМ-системы + -
PLM-системы + -
КСП-системы + +
В1-системы + +
ЕЯР-системы + +
ATS-системы - +
ЕА1-средства + -
Компоненты базы знаний (набора готовых решений) прое кта +
Средства автоматизированной сборки программ - +
Анализ указанных различий позволил определить, пусть в первом приближении, возможность и целесообразность использования компонентов перечисленных систем в тех или иных ситуациях работы над проектами по разработке ПО (см. таблицу 2).
Таблица 2 - Возможности использования средств управления процессами и управления
разработкой
Используемые средства Параметры проектов Неавтоматизированное управление Использование средств управления разработкой, производством (TFS, Jira и др.) Использование систем управления про е кта ми (Microsoft Project, Wrike, Confluence и др.)
Масштабность Небольшие коллективы + - --
Крупные коллективы в рамках одного предприятия +
Совокупность коллективов разных предприятий + + +
Степень формализо-ванности Неформализованное описание цели и задач, неявно заданный результат + + +
Предельно формализованная задача с чётко заданным ре з ультато м ++ +/-
Структура про е кта Линейная, разнородная, с преобладанием уникальных компонентов +/- +
Р а з в е тв лё нна я , с параллельным работами и пов то ря ющ имис я элементами +/- + +
В таблице:
+ + означает высокую эффективность использования; + приемлемая эффективность;
- означает низкую эффективность применения технологии в данных условиях;
+ / - эффективность применения варьируется в зависимости от особенностей использования.
Стоит пояснить, что под небольшими коллективами в таблице понимаются команды разработчиков, работающие в условиях визуального и вербального взаимодействия. Остальные описанные в таблице параметры зависят от количества коллективов
разработчиков, участвующих в проекте, степени детализации документов, описывающих проект и используемых инструментальных средств.
Разумеется, таблица в реальности, должна быть не «плоской», а многомерной матрицей, так как многие учитываемые в ней факторы коррелируются в разных плоскостях. Кроме того, в таблице намеренно не отмечен уровень обученности коллективов использованию конкретных средств управления проектами, учитывая, что этот фактор переменный.
Более того, всё это сделано намерено, чтобы упростить описание проблемы на этапе постановке задачи, которая может детализироваться по мере исследования. В представленном варианте таблица заполнена данными на основе обобщения личного опыта автора, по обобщению результатов разработки около десяти проектов различной сложности, и может позиционироваться как «опорный план» для дальнейшего уточнения, по мере накопления статистики, классификации систем на системы управления разработкой и системы управления проектами.
3.О практическом использовании средств управления проектами
Анализ данных таблицы 2 позволяет сделать вывод о целесообразности уточнения классификации систем управления коллективами разработчиков и разделения их на:
- системы управления проектами (project management);
- системы управления разработкой (development management).
С учётом такой классификации, предполагается преимущественное использование средств управления проектами для крупных составных проектов (в первую очередь -слабоформализованные проекты с неявно выраженными задачами, преимущественно ветвящейся распараллеленной структуры и содержащие множество однотипных задач на разных «ветках», а также при разработке изделия несколькими слабосвязанными организационно коллективами), а средств управления разработкой - для автономных проектов. В ряде случаев может потребоваться комплексное использование указанных средств (рисунок 4).
Рис.4. Организация комплексного использования средств управления проектами и
разработкой
Практика показала, что средства управления проектами и средства управления разработками - это эффективным инструменты как каждый в своей области, так и при совместном применении. Но, как всякие инструменты, они имеют границы применимости, в рамках которых они выдают ожидаемую эффективность. С другой стороны, при использовании вне указанных рамок (таблица 2), эти средства не просто показывают нулевой прирост эффективности, они мешают выполнению проекта, заставляя разработчиков выполнять лишнюю работу. Данный вывод сделан автором на основании практического опыта: когда в небольших коллективах на коротких проектах прямая постановка задач начинает дублироваться работой в TFS или Jira, аналитики, описав программисту процесс, вместо перехода к следующему этапу вынуждены повторно описывать уже выполняемые задачи. Что увеличивает затраты времени, практически не влияя на качество работы. И то, что результаты постановок задач фиксируются в электронной форме, служит слабой компенсацией потерянного времени.
Ну а наиболее эффективным является, как показывает практика, комплексное использование подобных инструментов по секторам, соответствующим их целевому назначению. Когда данные средства не вступают в противоречие и не дублируют, а эффективно дополняют друг друга.
Наиболее явное преимущество совместного использования средств управления проектами и управления разработкой и, пожалуй, одно из самых существенных -возможность создания тематических слоёв отображения состояния управляемого процесса. На профессиональном сленге разработчиков такие слои называют
«стейкхолдерами» (stakeholders), от английского понятия, обозначающего причастных к процессу лиц или организаций, непосредственно заинтересованных в его результате. Организация таких слоёв позволит управленцам всех уровней оперативно оценивать реализацию требований относительно разрабатываемой системы или её свойств, удовлетворяющих их потребностям и ожиданиям (стандарты ISO/IEC 15288:2015, ISO/IEC 29148:2011). Повышая тем самым эффективность контроля процесса разработки, как одного их важнейших этапов цикла управления. И, соответственно, обеспечивая оперативное реагирование на изменения в динамике производственного процесса, сокращая время и затраты.
В то же время, в использовании указанных средств могут возникать определённые проблемы. Определяются они тем, что системы управления проектами и разработкой реализуются, преимущественно, программными средствами зарубежной разработки. Для их эффективной работы необходим сетевой режим, периодическое обновление рабочих модулей. В той ситуации, когда разрабатываемый проект содержит конфиденциальную информацию, данный факт может стать критичным. Занесение в сетевой проект требований к разрабатываемой системе, описания её архитектуры, может вызывать определённые опасения. Впрочем, проблема решаема. Существует достаточно широкий средств управления проектами, включённых в «Единый реестр российских программ для
электронных вычислительных машин и баз данных» [24,25], в том числе систем отечественной разработки: 1С-Битрикс24, «Адванта» (А2), «Rubius Project Manager», «Яндекс.Трекер» и множества других. Остаётся только выбрать средство, отвечающее требованиям конкретного проекта или организации по функционалу. После этого выбора остаётся организовать комплексное применение средств управления проектами и разработкой, которое, как показала практика, обеспечивает оптимизацию использования перманентно ограниченных сил и средств для решения ресурсоёмких задач. Оптимизацию, как по распределению ресурсов, так и времени на разработку программного продукта.
Более того, эта оптимизация, само комплексное использование инструментов управления проектами и управления разработкой обеспечит, в том числе, распределённую работу или работу распределённых команд по созданию программного продукта. А такой подход, уже шаг к запуску полноценной «цифровой» экономики, как одного из перспективных методов организации производства.
Заключение
Таким образом, как показывает анализ предметной области, для обеспечения эффективного и комплексного использования средств автоматизированного управления проектами и разработкой требуется уточнить классификацию инструментария, использующего данные средства и определить возможность его совместного или автономного использования. Первый шаг к этому сделан в настоящей статье, предложено разделить системы управления коллективами разработчиков по их функциональному назначению: на средства управления проектами и средства управления разработкой.
В дальнейшем, вероятно, потребуется актуализация терминологии предметной области на основе предложенной классификации и уточнение применяемой нормативно-
технической документации [26,27]. Это достаточно объёмная задача, но её решение обещает определённый прирост эффективности разработки ПО. Которое, в настоящее время, является неотъемлемой и очень важной частью практически любой сложной технической системы. Исходя из этого, решение сформулированной в статье научно-
практической задачи является актуальным и требующим скорейшей реализации. Библиография
1. Иванова. Г.С., Ничушкина Т.Н. Проектирование программного обеспечения. - М. : Изд-во МГТУ им. Н.Э. Баумана, 2002. - 74 с.
2. Майк Кон. Scrum: гибкая разработка программного обеспечения. Succeeding with Agile: Software Development Using Scrum (Addison-Wesley Signature Series). — М.: Вильямс, 2011. — 576 с.
3. Роберт С. Мартин, Джеймс В. Ньюкирк, Роберт С. Косс. Быстрая разработка программ. Принципы, примеры, практика - М. : Вильямс, 2004. — 752 с.
4. Royce W. W.Managing the development of large software systems: concepts and techniques. Proceeding. ICSE '87 Proceedings of the 9th international conference on Software Engineering. The Institute of Electrical and Electronics Egineers Inc., 1970. -pp. 328-328.
5. Тиханычев О. В. О «гибких» технологиях в разработке программного обеспечения систем поддержки принятия решений // Программные системы и вычислительные методы. - 2018. - № 2. - С. 51-59.
6. Джефф Сазерленд. Scrum. Революционный метод управления проектами-Scrum. The art of doing twice the work in half the time. - Манн, Иванов и Фербер, 2016. - 288 с.
7. Майк Кон. Пользовательские истории: гибкая разработка программного обеспечения (Signature Series). - М.: «Вильямс», 2018. - 256 с.
8. Рыбина Г.В. Проблемы интеграции и особенности разработки программного обеспечения современных интеллектуальных систем // Прикладная физика и математика. 2013. - № 3. - С. 41-63.
9. Шонбергер Р. Японские методы управления производством. — М. : Экономика, 1988. - 199 c.
10. ГОСТ 7.22-2003"Система стандартов по информации, библиотечному и издательскому делу. Промышленные каталоги. Общие требования"(введен в действие постановлением Госстандарта РФ от 29 мая 2003 г. N 167-ст). М.: Издательство стандартов, 2003. - 7 с.
11. Каталог деталей и сборочных единиц. Центр каталогизации и информационных технологий "Каталит". Официальный сайт. URL: http://katalit.ru/index.php?
option = com_content&.view=article&.id = 65&.Itemid = 144 (дата обращения: 17.09.2019).
12. Тиханычев О.В., Макарцев Л.В., Гахов В.Р. Рациональная организация процесса разработки прикладного программного обеспечения как предпосылка успешной автоматизации поддержки принятия решений // Программные продукты и системы. 2017. - №4. - С. 706-710.
13. Рекомендации по преподаванию программной инженерии и информатики в университетах. - М. : ИНТУИТ.РУ, 2007. - 462 с.
14. Выпасняк В. И., Тиханычев О. В. Автоматизированные системы управления войсками (силами): тенденции, методы и перспективы развития // Вестник Академии военных наук. - 2009. - № 4. - С. 61-68.
15. Лукинова О.В. Методологические аспекты управления жизненным циклом информационной системы на основе инструментов функциональной стандартизации // Программные продукты и системы. - 2016. - № 4. - С. 27-35.
16. Хенрик Книберг. Scrum и XP: заметки с передовой-Scrum and XP from the trenches. C4Media, 2007. - 140 с.
17- Летбридж Т. [и др.]. SE2004: рекомендации по обучению специальности «Программная инженерия» // Открытые системы. СУБД. 2006. № 10. URL: http://www.osp.ru/os/2006/10/ 3910113 (дата обращения: 10.04.2017).
18. Кеннет Рубин. Основы Scrum: Практическое руководство по гибкой разработке ПО = Essential Scrum: A Practical Guide to the Most Popular Agile Process. - М.: «Вильямс», 2016. - 544 с.
19. Сныткин Т. И., Поляков А. Е., Руденко Г. А. Системное проектирование автоматизированной системы военного назначения с использованием нотаций Archimate 2.1. // Динамика сложных систем-XXI век. 2018. Т. 12. - № 2. - С.44-55.
20. Штрик А.А. Технологии и инструментальные средства создания программного обеспечения: состояние и перспективы // Программные продукты и системы. 1991. -№ 2. - С.57-64.
21. Вичугова А. А. Этапы, методы и средства конфигурирования информационных систем // Прикладная информатика. 2015. - №3(57). - С.88-99.
22. Gauch S., Chaffee J., Pretschner A. Ontology-based personalized search and browsing // Web Intelligence and agent systems. - 2003. - Vol. 1. - P. 219-234.
23. McAvoy, L. M., Chen, L., & Donnelly, M. (2012, September). An ontologybased context management system for smart environments. The Sixth International Conference on Mobile Ubiquitous Computing, Systems, Services and Technologies, UBICOMM 2012, -pp. 18-23.
24. Постановление Правительства РФ от 16.11.2015 N 1236 (ред. от 20.11.2018) "Об установлении запрета на допуск программного обеспечения, происходящего из иностранных государств, для целей осуществления закупок для обеспечения государственных и муниципальных нужд" URL:
https ://reestr.minsvyaz.ru/upload/iblock/c00/2020_12_2017.pdf (дата обращения 19.04.2019).
25. О внесении изменений в Федеральный закон "Об информации, информационных технологиях и о защите информации" и статью 14 Федерального закона "О контрактной системе в сфере закупок товаров, работ, услуг для обеспечения государственных и муниципальных нужд". 188-ФЗ от 29.07.2015 г. URL: http://base.garant.ru/71108368/ (дата обращения 19.04.2019)
26. Барковский С.С., Янин Д.М. Особенности информационного обеспечения автоматизированных систем управления военно-научной работой // Тренды и управление. - 2015. - №4. - C. 441-449.
27. Гракова Н.В. Построение семантической модели управления проектами // Кибернетика и программирование. - 2012. - №1. - C.7 -15.
Результаты процедуры рецензирования статьи
В связи с политикой двойного слепого рецензирования личность рецензента не раскрывается.
Со списком рецензентов издательства можно ознакомиться здесь.
Авторы затрагивают проблемы в практически значимой области разработки ПО, в т.ч. для специализированных задач. Однако четкая формулировка научной новизны работы, целей и задач исследования отсутствуют. В анализе проблемы желательно конкретизировать существующие методики управления (привести примеры решений и ссылки на публикации), тогда как у авторов даны ссылки в основном на классификацию. Вместе с тем, авторы упоминают существование систем работы с каталогами в
производстве, системы в машиностроительной промышленности, но без ссылок на публикации. Не приводится методология исследования. Не понятно насколько и на каком объеме материала Авторы проработали состояние вопроса, хотя упоминается что выводы во вводной части статьи основаны на личном опыте Авторов. Не упоминается объем материала, условия исследования, не структурированы задачи. В статье не сформулированы научные результаты, полученные Авторами, не приводятся критерии оценки. Рис. 4 является схемой взаимоотношения руководителя проекта и разработчиков, но её нельзя считать результатом работы. Для табл. 1 и 2 отсутствует анализ, поэтому читателю не ясно с какой целью они приведены. Это собственные результаты авторов или сводные таблицы по анализу публикаций. В статье много размытых формулировок и непоследовательного изложения материала, что затрудняет рецензирование. Много терминов, приведенных одновременно на русском и английском языках, необходимо ли это? Библиография достаточна, но все ссылки приведены не отдельными позициями, а группами (всего 5 групп, максимально ссылка на 8 позиций одновременно). Это позволяет усомниться в детальной проработке Авторами результатов других исследований в данной области. Стиль изложения материала. В статье используется терминология, однако встречаются просторечные и сленговые выражения. Много пунктуационных ошибок. Многие предложения не имеют логического окончания. Необходимо привести структуру статьи в соответствие с требованиями к научным работам, повысить четкость формулировок. Представленные материалы нуждаются в существенной доработке и после этого могут быть опубликованы в виде обзорной статьи.
Результаты процедуры повторного рецензирования статьи
В связи с политикой двойного слепого рецензирования личность рецензента не раскрывается.
Со списком рецензентов издательства можно ознакомиться здесь.
Предмет исследования - уточнение функциональных оснований классификации методов и средств управления коллективами разработчиков программного обеспечения (управление проектами и управление разработками). Методология исследования основана на теоретическом подходе с применением методов анализа, обобщения, сравнения, синтеза. Актуальность исследования обусловлена широким
распространением программных систем и комплексов в различных отраслях современной экономики и, соответственно, необходимостью изучения, проектирования и оптимизации средств управления коллективами разработчиков программного обеспечения (управления проектами и управления разработками). Научная новизна связана с полученными авторами выводами о том, что для обеспечения эффективного и комплексного использования средств автоматизированного управления проектами и разработкой требуется уточнить их классификацию. Предложено разделить данные системы по их функциональному назначению - средства управления проектами и управления разработкой. Стиль изложения научный. Статья написана русским литературным языком. Структура рукописи включает следующие разделы: Введение (программное обеспечение (ПО), требования к срокам и качеству разработки, методологии - «гибкие» Agile (гибкая модель), «каскадные» Waterfall (каскадная модель), их варианты, система прикладных технологий и инструментария, средства автоматизации управления коллективами разработчиков, проблема классификации систем управления технологическими процессами относительно их функционального назначения, задача уточнения классификации методов управления коллективами разработчиков), 1.Особенности средств управления проектами и разработкой программ (опыт применения средств автоматизации управления коллективами разработчиков,
различия областей применения - TFS или Jira, Toyota Kanban, Microsoft Project, Wrike, Confluence, «Адванта», терминология описания систем, перевод английского понятия «project management» (управление проектами), системы управления разработкой (development management), сравнительный анализ характеристик средств автоматизации управления разработкой - управляющие компоненты, входные и выходные формы программ, внешний вид форм панелей задач систем управления разработкой, «досок» задач систем управления разработкой TFS, Jira и Wrike, функционал систем управления коллективами разработчиков - по уровню формализации задач исполнителям проекта, по возможности взаимодействия со сторонними системами, по наличию встроенных средств автоматизированного тестирования и сборки программ), системы управления разработкой и проектами), 2. Функциональные особенности средств управления разработкой и управления проектами (процесс разработки ПО, типовой цикл управления, спектр систем различного назначения, соответствие функционала систем управления процессами и разработкой возможностям других систем автоматизированного управления, использование средств управления процессами и управления разработкой, небольшие коллективы), 3. О практическом использовании средств управления проектами (уточнение классификации систем управления коллективами разработчиков - системы управления проектами (project management), системы управления разработкой (development management), организация комплексного использования средств управления проектами и разработкой, совместное использование средств управления проектами и разработкой, создание тематических слоёв отображения состояния управляемого процесса (stakeholders), проблемы в использовании указанных средств, спектр средств управления проектами), Заключение (выводы), Библиография. Текст включает три рисунка, две таблицы. Содержимое рисунков практически не читается. Обозначения в таблицах 1, 2 ( + , -, --, + + , -/+, +/-) следует пояснить. Слово «Вариант / Варианты» из названий таблиц можно изъять. Содержание в целом соответствует названию. В то же время обращает внимание, что речь идёт, в основном, о классификации, сходстве и различиях в функционале, дополнении систем управления проектами и разработкой. В тексте упоминается, что «при использовании вне указанных рамок (таблица 2), эти средства не просто показывают нулевой прирост эффективности, они мешают выполнению проекта, заставляя разработчиков выполнять лишнюю работу», однако данное положение не подтверждено дополнительными аргументами, что представлялось бы целесообразным. Также не вполне ясно, что понимается автором под stakeholders - возможность создания тематических слоёв отображения состояния управляемого процесса, сами тематические слои? Обычно стейкхолдерами (англ. stákeholder - заинтересованная сторона, причастная сторона) называются физические лица или организации, имеющие интересы относительно системы или её свойств, удовлетворяющих их потребностям и ожиданиям. Библиография включает 27 источников отечественных и зарубежных авторов - монографии, научные статьи, материалы научных мероприятий, нормативные правовые акты. Библиографические описания некоторых источников нуждаются в корректировке в соответствии с ГОСТ и требованиями редакции, например: 1. Иванова Г. С., Ничушкина Т. Н. Проектирование программного обеспечения. - М. : Изд-во МГТУ им. Н. Э. Баумана, 2002. - 74 с. 2. Кон М. Scrum: гибкая разработка ПО (???). - М.: Вильямс, 2011. - ??? с. 4. Royce W. W.Managing the development of large software systems: concepts and techniques // ICSE '87 : proceedings of the 9th international conference on software engineering. - Место издания ???, Год издания ???. - Р. 328-338. 5. Тиханычев О. В. О «гибких» технологиях в разработке программного обеспечения систем поддержки принятия решений // Программные системы и вычислительные методы. - 2018. - № 2. - С. 51-59. 9. Шонбергер Р. Японские методы управления производством.
— М. : Экономика, 1988. - 199 c. 13. Рекомендации по преподаванию программной инженерии и информатики в университетах. - М. : ИНТУИТ.РУ, 2007. - 462 с. 14. Выпасняк В. И., Тиханычев О. В. Автоматизированные системы управления войсками (силами): тенденции, методы и перспективы развития // Вестник Академии военных наук.
- 2009. - № 4. - С. 61-68. 15. Лукинова О.В. Методологические аспекты управления жизненным циклом информационной системы на основе инструментов функциональной стандартизации // Программные продукты и системы. - 2016. - № 4. - С. 27-35. 22. Gauch S., Chaffee J., Pretschner A. Ontology-based personalized search and browsing // Web Intelligence and agent systems. - 2003. - Vol. 1. - P. 219-234. Для источников №№ 10, 23 нужно указать выходные данные. Апелляция к оппонентам (Иванова Г. С., Ничушкина Т. Н., Кон М., Мартин Р. С., Ньюкирк Дж. В., Косс Р. С., Тиханычев О.В. Сазерленд Дж., Рыбина Г. В., Шонбергер Р., Макарцев Л. В., Гахов В. Р., Выпасняк В И., Тиханычев О. В., Лукинова О. В., Книберг Х., Летбридж Т., Рубин К., Сныткин Т. И. Поляков А. Е., Руденко Г. А., Штрик А. А., Вичугова А. А., Барковский С. С., Янин Д. М. Гракова Н. В., Royce W. W., Gauch S., Chaffee J., Pretschner A., McAvoy L. M., Chen L., Donnelly M. и др.) имеет место. Замечен ряд опечаток: Для повышения эффективности разработки ПО в настоящее время используются различные методологии: «гибкие» Agile (гибкая (ПОВТОР) модель), «каскадные» Waterfall (каскадная (ПОВТОР) модель), их варианты; тестирование, сборка программного продукта и т.п [12,13,14] - тестирование, сборка программного продукта и т.п. [12-14]; (рисунки 1, 2, 3) - (рисунки 1-3); [16,17,18] - [16-18]; [19,20,21] - [19-21]; Анализ данных таблицы 2 позволяет сделать вывод о целесообразности уточнения классификации систем управления коллективами разработчиков и разделения их на; - Анализ данных таблицы 2 позволяет сделать вывод о целесообразности уточнения классификации систем управления коллективами разработчиков и разделения их на: (ДВОЕТОЧИЕ); Существует достаточно широкий средств управления проектами - Существует достаточно широкий СПЕКТР (???) средств управления проектами. В целом рукопись соответствует основным требованиям, предъявляемым к научным статьям. Материал представляет интерес для читательской аудитории и после доработки может быть опубликован в журнале «Программные системы
и вычислительные методы» (рубрика «Автоматизация проектирования и технологической подготовки производства»).
