CC BY
28
УДК 338.46:002
Е.Г.Сорока
К ВОПРОСУ ОБ ОБУЧЕНИИ БУДУЩИХ IT-СПЕЦИАЛИСТОВ ПРОГРАММНОЙ ИНЖЕНЕРИИ КАК ИНСТРУМЕНТУ РАЗРАБОТКИ КАЧЕСТВЕННЫХ ПРОГРАММНЫХ ПРОДУКТОВ
В статье рассматривается проблема подготовки будущих IT-специалистов к профессиональной деятельности. Акцентируется внимание на том, что теоретические и концептуальные основы обучения программной инженерии лежат прежде всего в различных областях информатики (computing science), математики, экономики, управления проектами, социологии. Рассматриваются подходы к организации эффективного командного взаимодействия в процессе разработки программного продукта.
Ключевые слова: программная инженерия, IT-специалист, качество программного продукта, командное взаимодействие, коммуникативные и текстологические методы получения информации.
Процессы масштабной информатизации все глубже проникают в деятельность современного человека, что является объективным этапом развития современной цивилизации. Информационная составляющая деятельности становится доминирующей, а качество жизни все больше определяется информационным качеством общества, т.е. его способностью предоставлять необходимые информационные продукты и услуги, планка требований к которым с каждым годом становится все выше [6].
Пристальное внимание к качеству в сфере информационных технологий привело к зарождению и развитию особого направления в информатике - программной инженерии, базирующейся на фундаментальных знаниях о современной информационной картине мира, владении инструментальными умениями и навыками информационной деятельности, преломляющихся в способности специалистов эффективно решать профессиональные задачи, важнейшей из которых является неуклонное повышение качества выпускаемых программных средств. Достижения теории систем, системного анализа, исследования операций, теории оптимизации, вычислительной техники и кибернетики нашли своё воплощение в комплексном решении проблемы создания сложных, многовер-сионных, многофункциональных программных средств.
Термин Software Engineering (SE - программная инженерия) был введён Фридрихом Л. Бауэром в 1968 году на конференции подкомитета НАТО по науке и технике. В России программная инженерия долгое время называлась технологией программирования. Такой перевод термина «software engineering» предложил в 70-х годах XX века академик А.П.Ершов. Более современный перевод этого термина - программная инженерия -принадлежит И.В. Поттосину, одному из ведущих российских ученых в области информатики.
Определяя программную инженерию как «область компьютерной науки и технологии, которая занимается построением программных систем, настолько больших и сложных, что для этого требуется участие слаженных команд разработчиков различных специальностей и квалификаций», В.В. Липаев указывает, что суть методологии про-
граммной инженерии состоит в применении систематизированного, научного и предсказуемого процесса проектирования, разработки и сопровождения программных средств (ПС) на протяжении их жизненного цикла [7]. Программная инженерия не рассматривает технические аспекты детального создания компонентов: в сферу ее внимания входят такие задачи, как управление проектами ПС, разработка средств, методов и теорий, необходимых для обеспечения жизненного цикла комплексов программ.
По мнению В.К. Батоврина, в центре внимания программной инженерии находятся «вопросы научного планирования, проектирования, оценки, конструирования и эффективного использования систем, а также методы организации коллективных методов работы при создании таких систем» [3].
Технологии программной инженерии часто являются критическим фактором при разработке сложных вычислительных систем, интеграционные свойства которых проявляются только тогда, когда система рассматривается как единое целое. Кроме того, программная инженерия - это всегда коллективная работа. Современный IT-специалист — это член команды, поэтому он должен обладать навыками общения и межличностных отношений, а также уметь планировать не только свою работу, но и координировать ее с работой других. [9].
Кропотливая работа международных организаций по анализу существующих подходов к разработке качественного программного обеспечения, понимание важности подготовки будущих IT-специалистов, позволили к 2004 году сформулировать два основополагающие начала программной инженерии:
I.Guide to the Software Engineering Body of Knowledge 2010 (SWEBOK 2010), - Руководство к Своду Знаний по Программной Инженерии;
2.Software Engineering 2004 (SE 2004). Curriculum Guidelines for Undergraduate Degree Programs in Software Engineering - Рекомендации по преподаванию программной инженерии и информатики в университетах [SE, 2004].
Руководство к своду знаний SWEBOK признано необходимым для понимания вопросов создания программного обеспечения и включает описание десяти областей знаний программной инженерии:
- Software requirements - программные требования;
- Software design - дизайн (архитектура);
- Software construction - конструирование программного обеспечения;
- Software testing - тестирование;
- Software maintenance - эксплуатация (поддержка) программного обеспечения;
- Software configuration management - конфигурационное управление;
- Software engineering management - управление в программной инженерии;
- Software engineering process - процессы программной инженерии;
- Software engineering tools and methods -инструменты и методы;
- Software quality - качество программного обеспечения.
В дополнение к ним, SWEBOK также включает обзор смежных дисциплин, связь с которыми представлена как фундаментальная и необходимая для программной инженерии:
- Computer engineering - компьютерная инженерия;
- Computer science - компьютерные науки;
- Management - менеджмент;
- Mathematics - математика;
- Project management - управление проектами;
- Quality management - управление качеством;
- Systems engineering - системная инженерия.
Интегрируя принципы информатики и математики с инженерными подходами, программная инженерия занимается разработкой моделей и надежных методов производства высококачественного программного обеспечения. Создатели SWEEBOK обращают внимание на то, что основанием программной инженерии является именно информатика, а не естественные науки.
Проблема критической зависимости общества от качества и стоимости программного обеспечения в условиях относительной молодости программной инженерии делает вопрос профессионализма еще более важным для учебных заведений, занимающихся подготовкой будущих IT-специалистов. Совместным комитетом по образованию под эгидой профессиональных ассоциаций АСМ (Association for Computing Machinery) и IEEE Computer Society c целью оказания помощи образовательным учреждениям разработаны «Рекомендации по преподаванию программной инженерии и информатики в вузах» («Software Engineering 2004»).
В SE 2004 акцентируется внимание на том, что теоретические и концептуальные основы обучения программной инженерии лежат, прежде всего, в различных областях информатики (computing science), однако для получения полноценного образования студентам необходимо обладать фундаментальными знаниями в таких областях, как математика, экономика, управление проектами, социология, философия. Все будущие IT-
специалисты должны уметь интегрировать теорию и практику, выбирать целесообразную модель качества разрабатываемого ПС, быть способными разбираться в новых для себя предметных областях, не связанных напрямую с информатикой, но оказывающих существенное влияние на качество программных средств.
Ф.И. Андон, В.Ю. Суслов, Т.М. Коротун, Г.И. Коваль выделяют следующие факторы, определяющие выбор модели качества [2]:
1. Прикладная область и категории пользователей. Модель качества включает множество характеристик качества, каждая из которых имеет определенный вес в конкретной прикладной сфере и отражает точку зрения на качество отдельных категорий пользователей. Так, качество обычно связывается с удовлетворением требований к производительности, надежности, защищенности, со-провождаемости и т.д. Но надо учитывать, что производительность наиболее важна для информационных систем реального времени, надежность - для сверхнадежных и отказоустойчивых систем, защищенность информации - для учрежденческих и банковских систем. Этот фактор необходимо учитывать как один из основных при формировании модели качества конкретного программного средства.
2. Цель моделирования качества. В зависимости от цели моделирования качества, модель может в разной степени отражать взгляд на качество различных категорий участников процессов разработки и эксплуатации (сопровождения) - менеджеров, разработчиков, персонала сопровождения, пользователей, - и содержать множество соответствующих характеристик. Отметим, что современная концепция качества отдает приоритет интересам менеджеров (управленцев) и пользователей, поэтому наиболее востребованными являются такие характеристики, как удобство применения, сопровождаемость.
3. Стадия жизненного цикла. Для того чтобы должным образом управлять качеством на каждой стадии жизненного цикла (ЖЦ) ПС, необходимо рассматривать разнообразные аспекты качества и учитывать изменение представлений о качестве с течением ЖЦ.
Стандарт ГОСТ Р ИСО/МЭК 9126-93 предлагает варьировать взгляды на качество продукта по стадиям ЖЦ следующим образом [1]:
- целевое качество - необходимое и достаточное качество, которое отражает реальные потребности пользователя. Поскольку потребности, заявленные заказчиком, не всегда отражают реальные нужды пользователей относительно качества программного продукта, и эти нужды могут изменяться после того, как заявлены (установлены), - целевое качество рассматривается разработчиками как концептуальная сущность, которая не может быть полностью определена в начале проекта и должна рассматриваться как ориентир. Требования к целевому качеству должны по возможности включаться в спецификацию требований
к качеству ПС и оцениваться путем измерения эксплуатационного качества по завершении разработки программного продукта;
- затребованное (установленное) качество продукта - это тот уровень значений характеристик внешнего качества, который фактически заявлен в спецификации требований к качеству и должен использоваться как цель для его проверки. Требования ко всем или некоторым характеристикам качества указываются в спецификации требований к ПС. Наряду с оптимальными значениями характеристик должны также указываться минимальные значения, что поможет заказчикам и разработчикам избежать ненужного превышения стоимости и сроков разработки;
- качество программного проекта - внутреннее качество программного средства, представленное в описании основных частей или всего проекта, например, архитектуры программного обеспечения, структуры программ, стратегии проектирования интерфейса пользователя и т.п. Качество проекта - основа качества программного продукта, которое может быть лишь незначительно улучшено в ходе кодирования и тестирования;
- прогнозируемое качество продукта - качество, которое оценивается или предсказывается как качество конечного программного продукта на каждой стадии разработки на основании характеристик качества программного проекта;
- качество поставляемого продукта - это качество готового к поставке продукта, как правило, протестированного в моделируемой среде на моделируемых данных.
- качество в использовании (эксплуатационное качество) - качество ПС, измеряемое в терминах результатов ее использования, а не свойств. Качество ПС в пользовательской среде может отличаться от качества в среде разработки из-за недоучета особенностей среды и сценариев применения ПС и, как следствие, неадекватного тестирования. Пользователь оценивает только те атрибуты ПС, которые видны ему в ходе фактического использования.
4. Размер и сложность. За исключением очень простых проектов, различные компоненты ПС обычно имеют совершенно разные требования к характеристикам качества. Например, компоненты, обеспечивающие интерфейс с пользователем, характеризуются высокими требованиями к удобству применения, а базы данных - повышенными требованиями к целостности. Концептуальное разделение единого программного продукта на компоненты, характеризующиеся однотипными требованиями к качеству, помогает снизить конфликты между требованиями.
5. Методология проектирования и наличие CASE-инструментов. В пределах одной организации процессы разработки могут иметь различное наполнение и варьироваться в зависимости от применяемых в проектах методологий и интегрированных инструментов. Эти различия ограничивают возможность использования одного и того же
множества метрик по различным проектам. Очевидно, например, что не имеет смысла сравнивать число строк кода, разработанного с применением структурных методов, с числом строк, разработанных объектно-ориентированным методом.
6. Уровень зрелости организации-разработчика. Существует множество моделей зрелости организаций-разработчиков ПС, определяющих критерии оценивания мощности процессов и эффективности проектов разработки. Стремление организаций-разработчиков обеспечить конкурентоспособность выпускаемой программной продукции служит хорошим стимулом не только для повышения технического и технологического уровня проектов, но и для постоянного совершенствования процессов организации и управления разработкой, их оценивания по моделям зрелости и получения соответствующих сертификатов (например, сертификатов системы качества). Очевидно, что чем выше уровень зрелости организации, тем совершеннее процессы, связанные с обеспечением качества ПС.
7. Исторический опыт разработки. В достаточно зрелой организации-разработчике ПС, специализирующейся на выпуске однотипных программных продуктов, складываются определенные подходы к обучению сотрудников, стратегии проектирования и программирования, приемы сбора и регистрации всевозможных данных, методологии выполнения измерений ПС и т.д. Это дает им возможность использовать собственный опыт разработки программных систем со схожими характеристиками, накапливать полезную историческую информацию по проектам, относящуюся к качеству, и, таким образом, более точно строить модель качества, выбирать подходящие метрики, устанавливать количественные меры для всех характеристик качества ПС и прогнозировать достижение основных характеристик качества (например, надежности) уже на ранних стадиях разработки.
8. Конфликты требований. Множество функциональных и нефункциональных требований к программной системе (в том числе требований к качеству) могут вступать в конфликты, которые должны разрешаться на всех стадиях ее разработки. Очевидно, что высокие требования к качеству ПС в условиях ограниченных ресурсов проекта всегда связаны с риском проекта, например по его продолжительности и стоимости. Для выявления и устранения такого рода конфликтов обычно используются матрицы конфликтов или другие инструменты контроля качества.
В программной инженерии широкое распространение получила методология «развертывания» качества программного обеспечения SQFD (Software Quality Function Deployment), концентрирующая внимание на повышении качества процесса разработки программных средств. SQFD адаптируется к любой существующей методологии программной инженерии, применяемой для выявления и количественного обоснования критических требований заказчика. Ее применение приво-
дит к повышению производительности труда аналитиков и программистов, сокращению количества изменений, вносимых в проект, снижению числа ошибок, распространяющихся с одной стадии ЖЦ на другую, и т.д. Создаваемые на ее основе системы качества требуют меньшего сопровождения и позволяют экономить на этом денежные средства [2].
SQFD адаптирует к условиям разработки ПС наиболее часто используемую матрицу - Дом Качества.
В этой модели присутствуют такие компоненты:
- требования пользователя. Извлекаемые при анализе проблемной области пользовательские требования (к которым относятся требования конечных пользователей, менеджеров, разработчиков системы и др.). Они представляют собой простые утверждения в терминологии пользователя и сопровождаются подробными определениями, образующими словарь SQFD;
- технические спецификации продукта. Пользовательские требования преобразуются в технические, измеримые спецификации требований к программному продукту. Одному пользовательскому требованию может соответствовать несколько технических спецификаций;
- корреляционная матрица. Пользователям предлагается идентифицировать уровень корре-лируемости между различными пользовательскими требованиями и техническими спецификациями продукта (сильная, средняя, слабая корреляция) и заполнить корреляционную матрицу. При этом должны быть учтены мнения всех категорий пользователей;
- приоритеты требований пользователя. На основе пользовательских данных выстраиваются приоритеты установленных требований и перечисляются справа по оси у. В ходе определения приоритетов может использоваться дополнительная информация о конкурирующих продуктах;
- приоритеты технических спецификаций продукта. Приоритеты технических спецификаций определяются путем суммирования произведений приоритетов пользовательских требований и корреляционных значений. Веса полученной строки приоритетов технических спецификаций затем обычно преобразуются в процентное представление суммарных весов строки приоритетов. Могут использоваться дополнительные данные об адресных (целевых) мерах технических спецификаций с учетом оценок стоимости, сложности и графика работ;
- конечный продукт. Конечный продукт процесса SQFD будет, как минимум, включать измеримые технические спецификации ПС, указатели их важности в процентном соотношении и адресные (частные) меры [10].
Методология SQFD (как и QFD) имеет как достоинства, так и недостатки. Методология переносит акцент в разработке на начальные стадии, что позволяет сосредоточиться на тщательном планировании и снизить изменяемость требований. Она обеспечивает «встраивание» качества в процесс проектирования, что приводит к предупреждению распространения дефектов на более поздние стадии ЖЦ, а это, в свою очередь, сокращает продолжительность и стоимость проекта, повышает производительность труда и качество конечного продукта. В числе недостатков SQFD -существенная стоимость и сложность методологии. Кроме того, принципиально важным условием ее успешного применения является активная коллективная работа всех участников проекта.
Уже в 50-е годы поднимался вопрос о взаимодействии «пользователя» и «программиста» при решении задач на ЭВМ. Так, А.П.Ершовым и М.Р.Шура-Бура была выдвинута формула равноправного сотрудничества при определенном разделении специализаций [5].
Низкий уровень социального взаимодействия 1Т-специалистов с заказчиками (сотрудниками других подразделений предприятия, пользователями) является «слабым звеном» в жизненном цикле программного продукта, что нередко сводит к нулю все усилия по формированию его качества. Многие команды, вместо того, чтобы приступать к разработке, исходя из интересов пользователей, сосредотачиваются на технологиях и в результате создают продукты, неудобные в применении и не вызывающие интерес у потребителей. Интенсивное развитие бизнеса в условиях рыночной экономики требует постоянной и оперативной модернизации информационных систем - это понимают все, поэтому и заказчики, и разработчики должны работать в тандеме [3].
Действительно, только заказчик знает, что же он хочет получить в результате, но, не обладая техническими знаниями в области разработки, он далеко не всегда может корректно изложить свои требования. Исполнитель же, не зная всех тонкостей предметной области (например, бухгалтерского учета), не в полной мере сможет реализовать ожидания заказчика. Только при полном взаимодействии заинтересованных сторон создается программный продукт, качество которого удовлетворяет заказчика. Не менее важно осуществлять взаимодействие в процессе внедрения и эксплуатации программного продукта [8]. Узловыми точками этого взаимодействия и проводниками всех изменений в автоматизируемых процессах являются люди, интегрирующие в своей деятельности технологии, информационные процессы и данные (рис.1).
Технологии
Процессы
Люди
Технологии
Рис. 1. Схема взаимодействия в процессе внедрения и эксплуатации программного продукта
Умение концентрироваться, «туннельное мышление», помогают успешно решать конкретные профессиональные задачи, но отсутствие панорамного видения цельного программного проекта, «добровольная изоляция» разработчика от заказчика, уверенность в собственной непогрешимости, неприятие замечаний и неспособность оперативно реагировать на изменение требований к продукту отрицательно сказываются на конечном результате и минимизируют его потребительскую ценность. Для современного 1Т-специалиста важно осознавать, что разрабатываемые им программные продукты должны быть, прежде всего, полезными для заказчиков и пользователей. Различия исходных интересов и точек зрения на проект приводят к взаимному непониманию, что может приводить к конфликтам. Организация четкого взаимодействия и разрешение конфликтов требует постоянных контактов по обмену знаниями и опытом, что необходимо для формирования целевого качества продукта. Этот аспект обязательно следует учитывать в процессе подготовки будущих 1Т-специалистов [10].
Студенты должны научиться находить ответы на следующие вопросы: Как продукт впишется в деятельность пользователя (заказчика)? Какие цели ставят пользователи (заказчики) при работе с продуктом? Какой опыт имеется у пользователей (заказчиков) и как он может быть применен в проектируемом продукте? Как пользователи (заказчики) будут взаимодействовать с разрабатываемым продуктом? С какими проблемами сталкиваются пользователи (заказчики) в своей профессиональной деятельности и как их решить с помощью нового продукта?
Умения и навыки проведения таких исследований позволят минимизировать ошибки в формализации требований к программному продукту,
будут способствовать повышению доверия и уважения к команде разработчиков со стороны пользователей (заказчиков). Неоценимую помощь в этом могут оказать коммуникативные и текстологические методы получения информации - «извлечения знаний».
Коммуникативные методы предполагают осуществление контактов непосредственно с пользователем (заказчиком) и делятся на пассивные и активные [4].
В пассивных методах извлечения знаний ведущая роль передается пользователю, а представитель группы разработки его фиксирует рассуждения и предложения. К этой группе методов относятся наблюдения, анализ «мыслей вслух», лекции.
Наблюдения - один из наиболее распространенных методов на начальных стадиях разработки. Разработчику важно видеть реальный производственный процесс, который подлежит автоматизации, чтобы глубже понять предметную область и учесть все ее особенности. Это необходимо также для проектирования эффективного интерфейса пользователя. Наблюдения за работой пользователей в привычной для них обстановке помогут «извлечь на поверхность» важные особенности их профессиональной деятельности, учет которых повысит качество конечного продукта.
Анализ «мыслей вслух» отличается от наблюдений тем, что заказчика (пользователя) просят не только прокомментировать свои действия и решения, но и объяснить, как это решение было найдено, продемонстрировать всю цепочку рассуждений. Основной трудностью при этом является принципиальная сложность для многих людей объяснить ход своих мыслей.
В активных методах инициатива полностью в руках разработчиков, которые активно контактируют с пользователями различными способами: в играх, диалогах, беседах за круглым столом и т.д.
К основным активным методам относятся: анкетирование, интервью, свободный диалог, экспертные игры.
Анкетирование - наиболее стандартизированный метод. Представитель команды разработчиков составляет анкету, размножает ее и использует для опроса сразу нескольких пользователей, что важно для выявления всех аспектов и нюансов предметной области.
Интервью представляет собой форму общения, в которой разработчик задает пользователю серию заранее подготовленных вопросов с целью тщательного изучения предметной области. Ин-
тервью очень близко к анкетированию, но его отличает возможность включения новых вопросов в зависимости от ситуации. Кроме того, в процессе общения между людьми устанавливается живой контакт, позволяющий повысить эффективность интервью.
Свободный диалог - это метод, который не предполагает наличие жесткого регламентированного плана ведения беседы. Внешне свободная и легкая форма этого метода требует профессиональной и психологической подготовки: необходимо продумать начало беседы (знакомство, объяснение целей и задач работы), структуру диалога, заключительную стадию (благодарность собеседнику, подведение итогов, договоренность о последующих встречах). Диалог предполагает принципиальное равенство собеседников при наличии разных точек зрения.
Метод «круглого стола» предусматривает обсуждение какой-либо проблемы, в котором с равными правами принимают участие как разработчики, так и представители заказчика (пользователи). Это один из наиболее распространенных методов раскрепощения и активизации творческого мышления. Как правило «штурм» длится недолго -около 40 минут. Участникам (до 10 человек) предлагается высказывать любые идеи на заданную тему. Регламент до 2 минут на выступление. Основополагающим правилом метода является запрет на критику и взаимные обвинения. Ведущим задаются вопросы, направленные на генерацию и извлечение идей с последующим поиском продуктивного решению проблем.
В процессе изучения требований заказчика большую пользу приносят ролевые игры. К играм заранее составляется сценарий, распределяются роли, разрабатывается система оценивания игроков. Создание игровой обстановки требует немало фантазии и творческой выдумки от организаторов, но главное, чтобы участники действительно «заиграли», раскрыли существенные стороны их профессиональной деятельности, важные для разработки, которые не удалось выявить другими методами [4].
Параллельно с коммуникативными методами 1Т-специалисты должны уметь применять текстологические методы, основанные на изучении специализированных текстов из учебников, монографий, статей и других носителей профессиональных знаний. Сюда могут и должны быть включены маркетинговые исследования, опросы потребителей, статьи в деловых и технических журналах, связанные с предметной областью, результаты поиска в Интернете продуктов-аналогов и т.д. Это объясняется тем, что высокая динамика развития рыночной экономики и информационных технологий, сложность и многогранность проблемы качества программных продуктов, являющихся основой процесса информатизации общества, требуют от современного специалиста постоянного пополнения своих знаний в самых разных сферах.
В этом контексте следует согласиться с Абрахамом Маслоу, который утверждал, что «каждый из нас имеет импульс к самосовершенствованию, к более полному воплощению наших возможностей в действительность, к самоактуализации, или к полной человечности, или к самоосуществлению» [11]. Тезис А. Маслоу особенно актуален для 1Т-специалистов, чьими усилиями информационное общество активно трансформируется в Бтаг^общество.
Библиографический список
1. ГОСТ Р ИСО/МЭК 9126-93. Информационная технология. Оценка программной продукции. Характеристики качества и руководство по их применению [Электронный ресурс]. Режим доступа: http://vsegost.com/Catalog/18/18984.shtml, свободный.
2. Андон, Ф.И. Основы инженерии качества программных систем. 2-е изд., перераб. и доп. / Ф. И. Андон, Г.И. Коваль, Т.М. Коротун , Е.М. Лаврищева, В.Ю. Суслов. - К.: Академпериодика, 2007. -672 с.
3. Батоврин, В.К. Системная и программная инженерия. Словарь-справочник: учебное пособие для вузов / В.К. Батоврин. - ДМК-Пресс, 2010. - 280 с.
4. Гаврилова, Т.А. Базы знаний интеллектуальных систем. Учебное пособие / Т.А.Гаврилова,
B.Ф.Хорошевский. - СПб.: Питер, 2001. - 384 с.
5. Ершов, А. П. Пути развития программирования в СССР / А.П. Ершов, М.Р. Шура-Бура // Кибернетика. - 1976. - № 6. - С. 141-160.
6. Колин, К.К. Информационная культура и качество жизни в информационном обществе / К.К.Колин // Открытое образование, 2010, 1. с.1-5.
7. Липаев, В.В. Программная инженерия : методологические основы : учебник / В.В.Липаев. - М-Берлин : Директ-Медиа, 2015. - 608 с.
8. Перемитина, Т.О. Управление качеством программных систем: учебное пособие / Т.О. Перемитина. - Томск: Эль Контент, 2011. - 228 с.
9. Рекомендации по преподаванию программной инженерии и информатики в университетах / Н.И. Бойко, М.Е. Зверинцева, С.А. Алпаев, Д.А. Маленко, И.В. Мозговая, Т.В. Зверинцева, Н.Ю. Курочка, А.А. Симановский, Д.А. Шапоренков. - М.: Интернет-университет информационных технологий, 2007. -472 с.
10. Сорока, Е.Г. Управление качеством программного продукта: учебное пособие / Е.Г.Сорока. -Омск: Изд-во ОмГТУ, 2014. - 104 с.: ил.
11. Холлифорд, С., Уиддет, С. Мотивация: Практическое руководство для менеджеров /
C.Холлифорд, С.Уиддет. - М.: ГИППО, 2008. - 451 с.
References
1.Andon, F.I. Osnovy inzhenerii kachestva programmnyh sistem. 2-e izd., pererab. i dop. / F.I. Andon, G.I. Koval', T.M. Korotun , E.M. Lavrishheva, V.Ju. Suslov. - K.: Akademperiodika, 2007. - 672s.
2.Batovrin, V.K. Sistemnaja i programmnaja inzhenerija. Slovar'-spravochnik: uchebnoe posobie dlja vu-zov / V.K. Batovrin. - DMK-Press, 2010. - 280s.
3.Gavrilova, T.A. Bazy znanij intellektual'nyh sistem. Uchebnoe posobie / T.A.Gavrilova, V.F.Horoshevskij. - SPb.: Piter, 2001. - 384s.
4.Ershov, A. P. Puti razvitija programmirovanija v SSSR / A.P. Ershov, M.R. Shura-Bura // Kibernetika. -1976. - № 6. - S. 141- 160.
5.Kolin, K.K. Informacionnaja kul'tura i kachestvo zhizni v informacion-nom obshhestve / K.K.Kolin // Otkrytoe obrazovanie, 2010, 1. s.1-5.
6.Lipaev, V.V. Programmnaja inzhenerija : metodologicheskie osnovy : ucheb-nik / V.V.Lipaev. - M-Berlin : Direkt-Media, 2015. - 608s.
7.Peremitina, T.O. Upravlenie kachestvom programmnyh sistem: uchebnoe po-sobie / T.O. Peremitina. - Tomsk: Jel' Kontent, 2011. - 228s.
8.Rekomendacii po prepodavaniju programmnoj inzhenerii i informatiki v universitetah / N.I. Bojko, M.E. Zverinceva, S.A. Alpaev, D.A. Malenko, I.V. Mozgovaja, T.V. Zverinceva, N.Ju. Kurochka, A.A. Si-manovskij, D.A. Shaporenkov. - M.: Internet-universitet informacionnyh tehnologij, 2007. - 472s.
9.Soroka, E.G. Upravlenie kachestvom programmnogo produkta: uchebnoe po-sobie / E.G.Soroka. -Omsk: Izd-vo OmGTU, 2014. - 104 s. : il.
10. Holliford, S., Uiddet, S. Motivacija : Prakticheskoe rukovodstvo dlja me-nedzherov / S.Holliford, S.Uiddet. - M.: GIPPO, 2008.- 451 s.
TO THE QUESTION ABOUT THE EDUCATION OF FUTURE IT PROFESSIONALS IN SOFTWARE ENGINEERING AS A TOOL FOR DEVELOPING HIGH-QUALITY SOFTWARE PRODUCTS
Elena G. Soroka,
Siberian Institute of business and information technology
Abstract. The article considers the problem of training of future IT-specialists for professional activity. Focuses on the fact that the theoretical and conceptual foundations of teaching software engineering lie in various areas of Informatics (computing science), mathematics, Economics, project management, sociology. Examines approaches to the organization of effective team interaction in the process of developing a software product.
Keywords: software engineering, IT-specialist, team interaction, the quality of the software product, communicative and textual methods of obtaining information.
Сведения об авторе:
Сорока Елена Георгиевна - зав.кафедрой информационных технологий Сибирского института бизнеса и информационных технологий (г.Омск, Российская Федерация), e-mail: soroka_e_g@mail.ru. Статья поступила в редакцию 01.06.2015.
