CC BY
55федеральных целевых программ в этой сфере, однако, существующие и формирующиеся меры, призванные способствовать повышению мобильности инвестиций и росту инновационной сферы России, работают не в полной мере, либо требуют дополнительных затрат;
- как показывают результаты исследований, реализация государственно-частного партнёрства способствует формированию предпосылок взаимовыгодного сотрудничества государства и бизнеса, но может создать и дополнительные риски в процессе осуществления совместных проектов.
Литература
1. Егоршева Н. Его звали кластер. // Российская газета (Федеральный выпуск). 10 апреля 2007 г. № 4337. С. 30.
2. Игнатенко Ю. В. Формы, модели и механизмы государственно-частного партнерства // Современные аспекты экономики. № 4 (164): сборник научных трудов, 2011 г. 242 с.
3. Ларин С. Н. Государственно-частное партнерство: зарубежный опыт и российские реалии. / Под общ. ред. С. Н. Сильвестерова / М.: Изд-во ЛКИ, 2008.
4. Национальная инновационная система и государственная инновационная политика Российской Федерации: Базовый доклад к обзору ОЭСР национальной инновационной системы Российской Федерации. М.: Минобрнауки РФ, 2009.
5. Рытова Е. Н. Использование механизма государственно-частного партнерства для повышения эффективности инновационных проектов на малых предприятиях / Экономические реформы в России - сборник научных трудов / СПб.: Изд-во политехнического университета, 2011.
INFORMATION SUPPORT OF THE DEVELOPMENT REQUIREMENTS TO HIGH-TECH PRODUCTS Aksenov A. (Russian Federation) ИНФОРМАЦИОННОЕ ОБЕСПЕЧЕНИЕ ПРОЦЕССА РАЗРАБОТКИ ТРЕБОВАНИЙ К ВЫСОКОТЕХНОЛОГИЧНОМУ
ПРОДУКТУ Аксенов А. С. (Российская Федерация)
Аксенов Антон Сергеевич /Aksenov Anton - магистрант, кафедра бизнес-информатики, информационно-технический факультет, направление: прикладная информатика в поставке высокотехнологичных решений, Новосибирский государственный университет экономики и управления, г. Новосибирск
Abstract: developing software is complicated by the difficulties associated with the identification process and requirements analysis. Reflected in the article is the initial process and one of the most important, every missed detail can ultimately contribute to the creation of high-tech products, is not performing its tasks. And to address the identified problems will require substantial investment of time and budget. To the company, specializing in software development, is not faced with a similar situation in this article was proposed by the requirements of the development of the concept of a software product. Аннотация: разработка программного продукта осложняется трудностями, связанными с процессом выявления и анализа требований. Отображенный в статье процесс является начальным и одним из важнейших, каждая упущенная деталь в конечном итоге может способствовать созданию высокотехнологичного продукта,
не выполняющего поставленных перед ним задач. А для устранения выявленных проблем необходимы значительные затраты времени и бюджета. Для того чтобы компании, специализирующиеся на разработке программного обеспечения, не сталкивались с подобной ситуацией, в данной статье была предложена концепция разработки требований к программному продукту.
Keywords: requirements, software, detection, analysis, prototype, peer review.
Ключевые слова: требования, программный продукт, выявление, анализ, прототип,
рецензирование.
Стремительное развитие информационных технологий в условиях жесткой конкурентной борьбы, а также изменение потребностей заинтересованных сторон заставляет компании, специализирующиеся на разработке программного обеспечения, наиболее ответственно относиться к процессу разработки требований, так как недостаточная проработка на начальном этапе приводит к значительным затратам времени и бюджета.
В ходе написания статьи были рассмотрены такие стандарты, как ISO 15288 «Системная инженерия. Процессы жизненного цикла систем» [1], ISO 24766 «Информационные технологии. Разработка систем и программного обеспечения» [2], ISO 29148 «Системная и программная инженерия. Процессы жизненного цикла. Разработка требований» [3], а также своды знаний BABOK [4] и PMBOK [5]. Они описывают процесс определения требований и преобразования этих требований в эффективный программный продукт, позволяющий выполнять поставленные задачи. Кроме вышеуказанных материалов использовалась научная зарубежная литература, а, именно, Карл Вигерс «Разработка требований к программному обеспечению» [6] и Дин Леффингуэлл «Принципы работы с требованиями к программному обеспечению» [8]. Эти книги посвящены вопросам формирования качественных требований, в которых авторы предлагают хорошо зарекомендовавшие методы выявления, анализа и документирования требований.
Перечисленные работы содержат методики разработки требований к программному продукту, подробно описывающие четкую последовательность шагов, необходимость рецензирования требований и составления прототипов, однако, рассмотренные материалы не в полной мере учитывают проблему уникальности процесса разработки требований в зависимости от концепции программного продукта. Так как ИТ-сфера постоянно развивается, появляются новые направления и инновации, поэтому проблема уникальности процесса разработки требований к программному продукту является актуальной на данный момент.
В статье описан процесс, который подразумевает необходимость на начальном этапе наиболее серьезного отношения к этапам определения концепции и границ продукта. Кроме того, статья объясняет важность составления макета, позволяющего обнаружить заинтересованным лицам пропущенные или ошибочные требования, и необходимость итерационной экспертизы спецификации требований к программному продукту, с помощью которой удается выявить и исправить важные дефекты.
На этапе определения концепции продукта выявляются причины появления потребностей у заказчика, и выполняется сбор требований для модификации высокотехнологичного продукта. Для определения потребностей заказчика на весь срок разработки концепции проводится интенсивная работа с руководителем проекта, целью которой является выработка единого видения будущего продукта.
Далее на основе изученных и систематизированных требований командой аналитиков формируется документ-концепция, содержащий подробную информацию о требованиях заказчика, возможностях продукта, границах проекта, ориентировочных сроках и бюджете, а также разрабатывается макет будущего продукта. По окончании разработки концепции и макета заказчик принимает решение
60
о целесообразности разработки и внедрения продукта, в случае принятия положительного решения, формируется устав проекта по разработке продукта.
Причиной внедрения продукта является одна или несколько из нижеперечисленных проблем, благоприятных возможностей или требований бизнеса, с которыми столкнулся заказчик, а, именно: потребность рынка, производственная необходимость, потребность заказчика, технический прогресс или юридические ограничения или нормы.
Главной проблемой внедрения продукта является нежелание пользователей обучаться работе в системе, поэтому руководителям подразделений необходимо стимулировать сотрудников для уменьшения вероятности простоя и значительного увеличения сроков и бюджета.
На успешный результат модифицируемого программного продукта напрямую влияет тщательность сбора требований, которые включают в себя задокументированные потребности, согласованные с заказчиком.
После того как известны основные варианты использования будущего продукта, определены бизнес-требования и возможности продукта, необходимо детализировать требования к продукту. Основная работа на этом этапе ведется с конечными пользователями продукта. При использовании итеративного процесса функционал разделяется на отдельные итерации, поэтому сбор и анализ требований ведется строго в рамках функциональности, которая должна быть реализована в текущей итерации.
Для достижения поставленных целей необходимо через общение с конечными пользователями выявить пользовательские истории к будущему продукту. Пользовательская история - это вариант использования будущего продукта в конкретной ситуации с целью достижения измеримого результата [12].
Пользовательские истории могут содержать как сложные инструкции с ответвлениями, так и конкретные примеры. Если же бизнес-процессы, которые автоматизирует продукт, строго формализованы, то пользовательская история должна содержать алгоритмы действий продукта и ответственных сотрудников.
К каждой пользовательской истории относится несколько бизнес-требований и в зависимости от важности выполнения устанавливается приоритет истории. Когда пользователь просит реализовать историю, не относящуюся к бизнес-требованиям, необходимо отдельное согласование с руководителями подразделений и ответственными за проект со стороны заказчика.
После завершения этапа сбора требований бизнес-аналитик располагает всей необходимой информацией о требованиях к будущей системе и основной целью является систематизация и избавление от дублируемых данных. Это достигается за счет разделения пользовательских историй на отдельные пакеты по функциональному признаку и их иерархической структуризации. Пользовательские истории являются разновидностью стандартных вариантов использования, с той лишь особенностью, что они описывают взаимодействие с гипотетической системой. Для описания связей вариантов использования необходимо использовать диаграмму вариантов использования, которая входит в стандарт UML и имеет широкое распространение в сфере проектирования программного обеспечения. На рынке представлены, как бесплатные решения с базовым набором функций, так и промышленные решения, самыми распространенными из них являются Rational Rose и Microsoft Visio [6]. В конечном итоге получается несколько диаграмм, содержащих все варианты использования системы и их связи между собой.
Для построения прототипов можно воспользоваться таким программным обеспечением, как Axure, с помощью интерактивного представления заинтересованные лица будут иметь наглядное понимание о функциях разрабатываемого программного продукта. Прототипы помогают заказчикам оценить, будет ли программный продукт, созданный в соответствии с имеющимися
требованиями, удовлетворять их нужды, а также являются ли требования полными, реализуемыми, понятными и четко сформулированными.
Современное программное обеспечение постоянно модифицируется под потребности заинтересованных лиц и зачастую не всегда функционал совпадает с требованиями заказчика. Поэтому в данной статье описывается процесс разработки требований к программному продукту, позволяющий решать такие проблемы, как несоблюдение определенной последовательности выполнения этапов, вследствие чего появляется риск потери бюджета, времени и доверия клиентов. Кроме того, статья объясняет уникальность процесса разработки требований в зависимости от концепции программного продукта, а также необходимость составления прототипов, для наглядного представления и согласования с заказчиком будущего продукта.
Литература
1. ISO 15288 Системная инженерия. Процессы жизненного цикла систем - ISO, 2004. 53 с.
2. ISO/IEC TR 24766 Информационные технологии. Разработка систем и программного обеспечения - ISO, 2009. 23 с.
3. ISO 29148 Системная и программная инженерия. Разработка требований - ISO, 2011. 83 с.
4. A Guide to the Business Analysis body of knowledge. Version 2.0 - IIBA, 2009. 253 с.
5. Руководство к своду знаний по управлению проектами. Четвертое издание (Руководство PMBOK) - PMI. Inc., 2008. 241 с.
6. Вигерс К. Разработка требований к программному обеспечению / Карл Вигерс, Джой Битти. М.: Издательство «Русская редакция», 2014. 736 с.
7. Вольфсон Б. Гибкое управление проектами и продуктами / Борис Вольфсон. СПб.: Питер, 2014. 144 с.
8. Леффингуэлл Д. Принципы работы с требованиями к программному обеспечению. Унифицированный подход / Дин Леффингуэлл, Дон Уидриг. М.: Издательский дом «Вильямс», 2002. 448 с.
9. Пашков П. М. Методология бизнес-анализа: учеб. пособие / П. М. Пашков; Новосиб. гос. ун-т экономики и управления. Новосибирск, 2015. 212 с.
10. Пашков П. М. Бизнес-анализ: учеб. пособие / П. М. Пашков, З. В. Родионова, К. Ю. Сухоруков. Новосибирск: Новосиб. гос. ун-т экономики и управления «НИНХ». ЗАО ИПП «Офсет», 2015. 234 с.
11. Пашков П. М. Стратегическое управление информационными системами: учеб. пособие / П. М. Пашков. Саратов: Саратовский гос. технический ун-т, 2009. 188 с.
12.Химонин Ю. И. Сбор и анализ требований к программному продукту / Ю. И. Химонин, 2009. 51 с.
