авторефераты диссертаций БЕСПЛАТНАЯ БИБЛИОТЕКА РОССИИ

КОНФЕРЕНЦИИ, КНИГИ, ПОСОБИЯ, НАУЧНЫЕ ИЗДАНИЯ

<< ГЛАВНАЯ
АГРОИНЖЕНЕРИЯ
АСТРОНОМИЯ
БЕЗОПАСНОСТЬ
БИОЛОГИЯ
ЗЕМЛЯ
ИНФОРМАТИКА
ИСКУССТВОВЕДЕНИЕ
ИСТОРИЯ
КУЛЬТУРОЛОГИЯ
МАШИНОСТРОЕНИЕ
МЕДИЦИНА
МЕТАЛЛУРГИЯ
МЕХАНИКА
ПЕДАГОГИКА
ПОЛИТИКА
ПРИБОРОСТРОЕНИЕ
ПРОДОВОЛЬСТВИЕ
ПСИХОЛОГИЯ
РАДИОТЕХНИКА
СЕЛЬСКОЕ ХОЗЯЙСТВО
СОЦИОЛОГИЯ
СТРОИТЕЛЬСТВО
ТЕХНИЧЕСКИЕ НАУКИ
ТРАНСПОРТ
ФАРМАЦЕВТИКА
ФИЗИКА
ФИЗИОЛОГИЯ
ФИЛОЛОГИЯ
ФИЛОСОФИЯ
ХИМИЯ
ЭКОНОМИКА
ЭЛЕКТРОТЕХНИКА
ЭНЕРГЕТИКА
ЮРИСПРУДЕНЦИЯ
ЯЗЫКОЗНАНИЕ
РАЗНОЕ
КОНТАКТЫ


Pages:   || 2 | 3 | 4 |
-- [ Страница 1 ] --

ГУСС СВЯТОСЛАВ ВЛАДИМИРОВИЧ

Монография

АРХИТЕКТУРНАЯ СРЕДА КОМПОНЕНТОВ ВОПРОС ОТВЕТНЫХ

ЛИНГВИСТИЧЕСКИХ ИГР ДЛЯ ОБУЧАЮЩИХ ПРОГРАММНЫХ

СРЕДСТВ

Омск

2014

2

КРАТКОЕ СОДЕРЖАНИЕ:

1. Анализ конъюнктуры. Что и для кого создавать;

где вопрос о необходи-

мости качественного обучающего программного обеспечения ещ от-

крыт;

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

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

как создавать и что влияет на процесс создания;

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

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

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

5. Разработка обучающего программного обеспечения. Создание учебно го тренажра на основе концептуальной модели предметной области;

создание игрового обучающего программного средства на основе ар хитектурной модели предметной области.

6. Рекомендация по развитию проектных решений. Предложение по пере воду проектных решений в производственные решения для фабрики про граммного обеспечения, построенной на базе методологии Microsoft Software Factories.

ДЛЯ КОГО НАПИСАНО В первую очередь для исследователей (не обязательно учных), придержи вающихся инженерных принципов к разработке программного обеспечения.

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

ТРЕБОВАНИЕ К ЧИТАТЕЛЮ Чтобы полностью и адекватно понять информацию, представленную в пред лагаемой монографии, необходимо быть знакомым со следующими иссле довательскими направлениями:

программная инженерия (software engineering), порождающее программирование (generative programming), предметно-ориентированное проектирование (domain-driven design) и моделирование программного обеспечения (domain-specific modeling), объектно-ориентированный анализ и проектирование программных средств (object-oriented analysis and design).

СОДЕРЖАНИЕ ВВЕДЕНИЕ.............................................

............................................................ Актуальность научно-исследовательской работы................................ Цель и задачи исследования.................................................................... Предмет исследования............................................................................. Методы исследования............................................................................... Научная новизна результатов исследования........................................ ГЛАВА 1. АНАЛИЗ КОНЪЮНКТУРЫ И ВЫБОР ПОДХОДОВ РАЗРАБОТКИ ОБУЧАЮЩИХ ПРОГРАММНЫХ ПРОДУКТОВ........................................... 1.1. Рынок программных продуктов.................................................... 1.2. Рынок продуктов для электронного обучения............................ 1.3. Рынок игрового программного обеспечения........................... 1.4. Рынок обучающего игрового программного обеспечения... 1.5. Жизненный цикл программных проектов................................... 1.6. Программная инженерия.............................................................. 1.7. Программная инженерия на базе повторного использования артефактов разработки........................................................................... 1.8. Предметно-ориентированное моделирование....................... 1.9. Средства для моделирования и разработки............................ 1.10. Выводы................................................................................................ ГЛАВА 2. КОНЦЕПТУАЛЬНОЕ МОДЕЛИРОВАНИЕ ПРЕДМЕТНОЙ ОБЛАСТИ........................................................................................................ 2.1. Концептуальное проектирование................................................ 2.2. Статическая модель обучающего средства............................. 2.3. Выводы................................................................................................ ГЛАВА 3. КАРКАС ПРОГРАММНЫХ КОМПОНЕНТОВ............................... 3.1. Место каркаса программных компонентов в классификации элементов повторного использования................... 3.2. Проблема разработки каркаса.................................................. 3.3. Архитектура каркаса...................................................................... 3.4. Программный интерфейс каркаса......................................... 3.5. Выводы.............................................................................................. ГЛАВА 4. ПРОВЕРКА И ИСПЫТАНИЕ ПРОЕКТНЫХ РЕШЕНИЙ................. 4.1. Пример разработки обучающего программного средства на основе модели предметной области............................................ 4.2. Эксплуатация подсистемы «Безопасность»............................ 4.3. Примеры детализации каркаса................................................ 4.4. Сравнение с имеющимися решениями................................. 4.5. Экономика повторного использования.................................... 4.6. Выводы.............................................................................................. ЗАКЛЮЧЕНИЕ.............................................................................................. Рекомендации по развитию проектных решений............................. Публикации по теме исследования..................................................... СПИСОК ИСПОЛЬЗОВАННЫХ ИСТОЧНИКОВ........................................ Публикации в печатных изданиях........................................................... Электронные ресурсы............................................................................. ВВЕДЕНИЕ Конечный результат научного исследования, имеющего место в процессе разработки программного обеспечения – предметно ориентированные проектные решения для конкретной предмет ной области (т.е. «области знаний или деятельности, в которой пользователь использует программное обеспечение» [86]). К ним относят различные технические и инженерные артефакты (т.е.

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

Цель предметно-ориентированных проектных решений – за дать основу для производственных решений, на экономические характеристики которых могут влиять [67]: а) результаты концепту ального и системного анализа, б) модели предметной области, в) формализация требований и декомпозиция программных средств. Чем качественнее подготовлены проектные решения, тем больше шансов, что производственные решения будут адекватны ми и рентабельными.

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

Архитектурная среда компонентов. В предметно-ориенти рованном проектировании под архитектурной средой (frame work) понимают одну из форм программной инфраструктуры, реализующей нужные функции. Она навязывает другим уровням архитектуры приложения определнные способы реализации, решает технические задачи и позволяет разработчику уровня предметной области сосредоточиться на решении проблемы из предметной области, не отвлекаясь на технические детали. Архи тектурная среда – это уже сделанный «выбор проектных решений в предметной области» [86].

В рамках объектно-ориентированного проектирования тоже используется такое понятие, как архитектурная среда, однако ис торически сложилось, что в русскоязычной литературе она обозна чена таким термином, как каркас (в английском это вс тот же framework). Согласно определению из [50]: «каркас – набор взаи модействующих классов, составляющих повторно используемый дизайн для конкретного класса программ».

В программной инженерии можно встретить термин стиль (framework) [43]. В стандарте IEEE 1320.2 «Standard for Conceptual Modeling Language» отмечается, что «framework представляет со бой проект (модель или код), предназначенный для многократного повторного использования, который может быть усовершенствован (специализирован) и расширен и на основе которого может быть реализована некоторая часть полных функциональных возможно стей для многих приложений» [43].

Итак, в русском языке есть три термина для обозначения од ного и того же англоязычного понятия «framework». С точки зрения русского языка они действительно характеризуют сущность «framework» в рамках своей теоретической базы. Поскольку пред лагаемое исследование актуально для предметно-ориентирован ной разработки программных средств, то и термин выбран соот ветствующий – архитектурная среда. Тем не менее, там, где необ ходимо показать детали, будет использоваться термин «каркас», поскольку в качестве методологической базы моделирования выбрана именно объектно-ориентированная парадигма. Что ка сается термина «стиль», то он использоваться не будет, но когда повествование будет идти в контексте программной инженерии, термин «стиль» будет заменн на «каркас».

В работе также будет использоваться словосочетание «архи тектурная модель», под ней будет пониматься нечто, соответст вующее двум следующим классическим определениям. «Архи тектура – концепция взаимосвязи элементов сложной структуры, включающая компоненты логической, физической и программной структур» [74]. «Модель – материальный объект, система зависи мостей или программа, адекватная объекту» [74]. Архитектурная модель будет выражаться логическими схемами, программной реализацией, физическими характеристиками, и поясняться соот ветствующими диаграммами.

Актуальность научно-исследовательской работы Современные методы программной инженерии развиваются в направлении обеспечения поддержки автоматизации и система тизации процесса разработки программного обеспечения [84;

97;

104]. Этот процесс протекает в рамках конкретной предметной области. Чем уже область, тем более актуально проведение серьзных работ по проектированию структуры и взаимодействия составляющих семейства программных средств. Решения для целого класса программных систем характеризуются пригодно стью для использования в будущих проектах. С каждым новым проектом затраты на разработку уменьшаются, а проектные решения развиваются и становятся более гибкими.

Подходы и методики, учитывающие специфику предметной области, способствуют улучшению показателей процессов и ре зультатов разработки программного обеспечения. Они применя ются в контексте так называемого предметно-ориентированного проектирования (Domain-Driven Design), в рамках которого актив но используются достижения предметно-ориентированного моде лирования (Domain-Specific Modeling). Предметно-ориентирован ные решения, получаемые в рамках предметно-ориентирован ного подхода, могут быть оформлены как фабрики разработки программного обеспечения [53] (Software Factory).

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

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

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

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

Например, существуют следующие решения в различных проблемных областях, оформленные в виде фабрик разработки программного обеспечения – «Smart Client Software Factory» (Фаб рика разработки композитных приложений), «Mobile Client Software Factory» (Фабрика разработки клиентских модулей приложений для мобильных устройств) и другие, в рамках инициативы «Microsoft Patterns and Practices» [184].

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

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

67].

Развитие предметной области обучающих программ ных средств В таких предметных областях, как сетевое и межсетевое взаимо действие и медицина, в виду высокой критичности проектов, уже имеется ряд полезных решений, повышающих эффективность и качество разработок. Например, для сетевого и межсетевого взаимодействия существует архитектурная среда – программный каркас «Adaptive Communication Environment» [106], позволяющий эффективно решать задачи сетевого программирования, пре доставляя доступ к уже реализованным высококачественным эле ментам. Для медицины – каркас для работы c рентгенографиче скими и томографическими изображениями [112], а также – кар кас для разработки новых алгоритмов и прототипирования про граммных средств медицинских симуляторов [117]. В этих облас тях достигнуты определнные успехи, а полученные на практике знания упорядочены и оформлены для соответствующей целевой аудитории разработчиков программного обеспечения. Однако этого нельзя сказать о предметной области обучающих про граммных средств и поддержке электронного игрового обучения, в частности такого аспекта, как поддержка создания компонентов лингвистических игр.

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

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

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

Для решения проблемы в ходе исследования были подобра ны определнные методы и средства, предложены проектные ре шения, разработаны программные активы.

Характер исследования С появлением и укреплением в научных кругах такого понятия, как программная инженерия [48;

63;

76;

80;

111], было положено нача ло различным теоретическим исследованиям, с последующей апробацией на практике [46;

59;

72], связанным с поиском эф фективных и продуктивных методик создания программного обеспечения. С каждым годом появлялись новые решения, пред лагались пути дальнейшего развития, велись острые споры о необ ходимости и степени формализации и документирования объек тов, процессов и результатов разработки [52].

Деятельность в виде практических изысканий, научных иссле дований и обсуждений в этом направлении идт и сегодня, одна ко, характер е обладает другими свойствами. Довольно часто при появлении новых теоретических решений оказывается, что уро вень развития технологий не позволяет их воплотить [53;

70]. Либо получается так, что практики не готовы их принять по ряду объектив ных (недостаточная обоснованность и детализация предоставляе мой информации, мотивация и т.д.) и субъективных причин (не достаточный уровень знаний и умений, страх перед инновациями, оправданный и неоправданный). А если технологии и позволяют воплотить передовые идеи, то это оправдано только для весьма крупных проектов [61].

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

Тем самым редко берутся в расчты проекты малого масштаба.

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

Если посмотреть с другой стороны, то и сами масштабы проектов значительно изменились за последние годы, появились новые инструменты, уровень абстракции языков программирова ния стал выше [53;

70;

98].

Разработка в конкретной предметной области Как отмечалось выше, выделяются два понятия, характеризующие предметно-ориентированную разработку программного обеспе чения. Первое – предметно-ориентированное проектирование.

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

91;

104]. По прогнозу ряда исследователей в области про граммной инженерии ([53;

70;

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

Зачастую, проектирование программного обеспечения вы полняется таким образом, что ни программный код, ни докумен тация не выражают знания, полученные в ходе долгих исследова ний, в явной и понятной форме [86]. Средства предметно ориентированного проектирования и моделирования как раз на правлены на придание ясности и прозрачности артефактам разработки, однако необходимо их уточнение в рамках конкрет ных предметных областей для повышения их полезного эффекта.

Предметная область электронного игрового обучения В качестве конкретной тематической области в работе представ лена область электронного игрового обучения. В этой области сделано немало в плане разработки различных программных средств [100]. Однако не хватает обучающих программных средств, в которых процесс игры разворачивается в «словесном поле» (не считая программных систем обучения языкам), с которо го и начинается вся разумная, созидательная, и прежде всего эффективная деятельность человека [57].

Особая важность головоломок, лежащих в основе лингвис тических игр, видна уже из их определения. Согласно современ ному толковому словарю русского языка Т.Ф. Ефремовой: «голо воломка – специально подобранная загадка, задача и т.п., для решения которой требуются сообразительность и знания в соот ветствующей области» [54]. Не должно быть сомнений в том, что процесс решения задач-головоломок, тем более оформленных в виде лингвистических игр, не направлен на деградацию населения (на что иногда указывают психологи, социологи и культурологи в контексте традиционных компьютерных игр [56;

68;

78]). Наоборот, такие игры способствуют развитию человека и обладают прове ренным временем мотивационным эффектом [69;

182]. Самое главное, что данный вид активности – совсем не новое увлечение, а уходит своими корнями далеко в прошлое [69]. К тому же, лингвис тические игры могут использоваться в процессе обучения лиц раз личных возрастных категорий [56], что весьма важно, учитывая се годняшнюю потребность в так называемом «обучении на протя жении всей жизни».

Исследования и программные разработки в области элек тронного игрового обеспечения ведутся достаточно давно, в том числе и в России, о чм свидетельствуют статьи в научных журна лах об образовании (например, журнал «Информатика и Обра зование» [141]) за 80-е годы и начала 90-х. Сегодня это направле ние опять становится популярным в связи с развитием компьютер ных средств мультимедиа и появлением интереса у правительства Российской Федерации к вопросу о развитии информационного общества [39]. Более того, в утвержднной в конце сентября года государственной программе (до 2020 г.) «Информационное общество» [142] в направлении повышения качества жизни граж дан обозначена необходимость улучшения уровня образования. А для этого требуется качественное, наджное и эффективное про граммное обеспечение.

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

Задачи:

1. Анализ конъюнктуры в области разработки обучающих про граммных средств.

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

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

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

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

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

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

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

Научная новизна результатов исследования Произведено уточнение, конкретизация и распространение мето дов и подходов предметно-ориентированного проектирования и моделирования на класс обучающих программных средств на основе вопрос ответных лингвистических игр. В результате «дистил ляции знаний» предметной области получены проектные решения, смысловым ядром которых является архитектурная среда для создания программных компонентов. Вокруг архитектурной сре ды гармонично сосуществуют вспомогательные решения более общего концептуального характера, которые задают контекст де тализации и уточнения специализированных знаний.

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

2. Для создания компонентов уровня предметной области пред лагается объектно-ориентированный каркас, как основной элемент программной архитектуры, построенной по принци пам предметно-ориентированного моделирования.

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

ГЛАВА 1. АНАЛИЗ КОНЪЮНКТУРЫ И ВЫБОР ПОДХО ДОВ РАЗРАБОТКИ ОБУЧАЮЩИХ ПРОГРАММНЫХ ПРОДУКТОВ Анализируемые и раскрываемые в разделах 1.1 – 1.4 вопросы свя заны с предварительным исследованием общего и специализи рованного рынков программного обеспечения, в рамках которых интерес представляют запросы и требования потребителей, а так же проблемы, препятствующие развитию рынка игровых обучаю щих программных средств. Здесь решается поставленная во вве дении задача №1 «анализ конъюнктуры».

Вопросы, рассматриваемые в разделах 1.5 – 1.7, очерчивают контуры инженерного подхода к разработке программного обес печения. Рассматриваются фундаментальные принципы традици онной программной инженерии и их современная реализация, приводятся соответствующие уточнения для подхода на основе по вторного использования. Здесь решается поставленная во введе нии задача № 2 «обзор принципов и подходов к разработке».

Основу материала о традиционной программной инжене рии задают монографии [59 – 66], о программной инженерии с акцентом на повторное использование – работы [84;

101;

104].

В разделах 1.8 – 1.9 представлены методы и подходы, рабо тающие в контексте предметной области. Приводятся обзор пер спектив и анализ возможных рисков с целью выявления рентабель ного и целесообразного способа формализации и реализации проектных решений в рамках разработки обучающих программ ных средств. Здесь решается поставленная во введении задача № 3 «выбор подходов, адаптация и обоснование».

1.1. Рынок программных продуктов 1.1.1. Субъекты и объекты Интернет-магазин «Softkey.ru» (интернет-дистрибутор программно го обеспечения, одно из ведущих предприятий на российском рынке лицензионного программного обеспечения) провл опрос своих покупателей [126]. Всего было проверенно 22 тысячи анкет, годы проведения – 2005 и 2007. Сферы профессиональной дея тельности покупателей приведены в табл. 1.

1.1.2. Категории Андрей Колесов (кандидат технических наук;

до 1995 года – инже нер, программист, научный сотрудник;

с 1997 года – обозреватель еженедельника «PC Week») провл свой анализ рынка программ ного обеспечения в России – [127]. Опираясь на результаты этого исследования можно сделать ряд выводов, уточнив их примени тельно к предметной области обучающих программных средств.

Выводы сведены в табл. 2.

1.1.3. Массовый рынок По данным за 2007 год, на мировом рынке выделяется 6 крупных корпораций («Microsoft» [183], «IBM» [172], «Oracle» [186], «SAP» [190], «Symantec» [196], «Adobe» [161]), составляющих 35% всего мирово го рынка. По прогнозам эта цифра может подняться до 50% к – 2015 годам [121].

Из представленных компаний особый интерес, в контексте разработки обучающих программных средств, представляют «Mi crosoft» и «Adobe». Эти компании значительные средства тратят на развитие технологий разработки программного обеспечения, а также задают стандарты мультимедиа. С их мнением приходится считаться для соблюдения совместимости с другим программным обеспечением, а также принципами и стандартами, к которым привыкли пользователи.

Табл. Сферы профессиональной деятельности покупателей Сфера деятельности 2005 год 2007 год Образование 4 Энергетика 5 Связь и телекоммуникации 7 Информационные технологии 14 Финансы 3 Банки 4 Строительство 5 Торговля 15 Оптовая торговля 4 Реклама 2 Научно-исследовательская деятельность 5 Государственные структуры 3 Военные организации 2 Медицина 3 Издательская деятельность 3 Транспорт 5 Другое 5 1.1.4. Российский рынок Согласно Мининформсвязи РФ за 4 года (с 2003 по 2007) объм выпускаемого программного обеспечения увеличился в четыре раза [120]. Этот рост продолжается и сегодня в связи с потребно стью в дальнейшей компьютеризации различных сфер деятельно сти (например, образования).

Табл. Представление рынка программного обеспечения в России Рынок программного обеспечения потребности пред информационные розничная торговля приятий, творчест Ответвление услуги во энтузиастов готовые тиражи- заказное про- внутрифирменные Тип продук руемые продукты граммное обес- разработки ции печение каталоги (интернет, каталоги, проспек- научные периоди специализирован- ты, тендеры (уча- ческие журналы, Места объяв ные журналы, вит- стие в конкурсе, фонды электрон лений о про рины магазинов) объявленном за- ных ресурсов, ма дукции казчиком) териалы конфе ренций и выставок индивидуальные за- корпоративные члены или отделы казчики клиенты (государ- фирмы, отдельные Потребители ственный сектор, заинтересованные коммерческий лица сегмент) магазины (рознич- отделы маркетин- внутрифирменные Поставщики ные, виртуальные) га разработчики (от делы, команды) стоимость продукта стоимость разра- содержание внут Затраты со и лицензий ботки и сопровож- рифирменных стороны по дения разработчиков или требителя субподрядчиков Согласно исследованию [121] на российском рынке выде ляются следующие компании-разработчики программного обес печения: «1С» [135;

136], «ABBYY», [160], «Astrosoft» [162], «Auriga»

[163], «CBOSS» [138], «Cognitive Technologies» [164], «Digital Design»

[167], «EPAM Systems» [170], «ICL» [174], «Luxoft» [178], «MERA» [180], «Microsoft» [183], «Monolit» [144], «Parallels» [187], «Reksoft» [151], «Rhonda» [189], «SAP» [190], «Solvo» [153], «SPIRIT DSP» [195], «Диа софт» [140], «Лаборатория Касперского» [143], «ПРОМТ» [150], «СКБ Контур» [152], «Тэлма Софт» [154], «Центр финансовых технологий»

[157].

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

Согласно данным исследования [129] за 2008 год, основны ми потребителями являются частные пользователи (15%), госструк туры (20%), корпоративный сектор (65%). Продаваемое программ ное обеспечение – общего назначения (43%), делового назначения (37%), домашнее (20%).

1.2. Рынок продуктов для электронного обучения 1.2.1. Электронное обучение Основными тенденциями российского рынка электронного обуче ния, согласно [131] являются продажа готовых тиражируемых про дуктов и предоставление информационных услуг.

Периодически проходят мероприятия-выставки, такие как «eLaernExpo» [168], посетителями которых являются профессиона лы и те, кто только интересуется вопросом. Интерес крупных заказ чиков – системы поддержки дистанционного образования. По требность – оценка уровня знаний персонала. Российские компа нии отдают предпочтение готовым западным решениям.

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

Бизнес электронного обучения направлен на разработку самостоятельных и дискретных решений. Цель – достижение част ных задач. Крупные и средние компании уже оценили значение электронного обучения и приобретают крупные системы. Малые компании зачастую используют отдельные обучающие модули, нежели системы целиком.

Отдельный вопрос – содержимое электронного материала.

Проблема – отсутствие качественного содержимого. Предлагае мые пути решения проблемы: а) обратить внимание на опыт про фессиональных компаний, анализ успешно реализованных про ектов (мнение Татьяны Котовой, руководителя отдела маркетинга и рекламы учебного центра «REDCENTER» [188]);

б) подготовкой со держимого должен заниматься преподаватель и профессиональ ный методист, который должен понимать восприятие человека, эр гономику, цветовую палитру оформления электронных материа лов (мнение Игоря Морозова, ректора «Академии АйТи» [137]).

Ярким примером удачных систем электронного обучения являются решения от французской компании «CrossKnowledge»

[166]. Основной принцип – создание системы под потребности за казчика из дискретных модулей.

1.2.2. Корпоративный сектор В апреле – июне 2008 года компания «Амплуа-Брокер» провела исследование – [118]. Изучались вопросы внедрения электронного обучения в компаниях, использование компонентов электронного обучения, взаимодействие с поставщиками. В качестве объектов исследования выступили 76 компаний, планирующих и исполь зующих системы электронного обучения, среди них – 83% россий ские компании, 17% – российские представительства западных компаний. Согласно исследованию рынок находится на стадии развития, сегодня вс ещ незрелая стадия, для которой характер но непонимание такого явления, как электронное обучение: адап тация курсов и видов содержимого, реальная цена продукта и его разработки, продолжительность обучения с использованием про граммной системы.

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

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

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

Основные функции электронных систем управления обуче нием [134]: а) сбор и обработка заявок на обучение;

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

г) планирование обучения, учт компетенции, знаний, навыков, составление графи ка обучения;

д) планирование и учт затрат и бюджета на обуче ние;

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

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

1.2.5. Рынок электронного обучения По версии журнала «E-Learning World» [169], занимающегося рас пространением культуры электронного обучения, рынок представ лен следующими компаниями: «МЭСИ» [145], Центр «eLearning»

[158], Компания «Competentum» [165], ЗАО «Гиперметод» [139], Академия «АйТи» [137], «1С» [135], Учебный центр «SRC» [155], Ком пания «МедиуМ» [179], «Прометей» [149], Компания «Новый Диск»

[146].

Характеристики рынка электронного обучения (по мнению Надежды Соболевой [119], генерального директора компании «Competentum»):

1. Темпы развития: большая доля приходится на США и страны Евросоюза. В России рынок ещ не сформирован. Здесь ви дение Надежды Соболевой сходится с видением и данными исследований компании «Амлуа-Брокер». Наибольшее разви тие наблюдается в корпоративном секторе. Наименьшее раз витие – в общеобразовательном секторе, развивающегося в последнее время в связи с активной деятельностью государст ва.

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

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

4. Перспективы развития – системы управления обучением, сег мент электронного содержимого для общеобразовательного и академического обучения, программы смешанного обуче ния.

1.2.6. Национальный проект «Образование»

Определнное место в программе национального проекта «Об разование» [148] отведено информационным технологиям, элек тронным образовательным ресурсам, электронным формам обучения. В рамках проекта – подпроект «Информатизация сис темы образования», национальная библиотека цифровых образо вательных ресурсов, обучение учителей. Яркий пример реализа ции – «Электронные образовательные ресурсы нового поколения»

[159] – интерактивные мультимедийные интернет-продукты.

1.3. Рынок игрового программного обеспечения 1.3.1. Тенденции российского рынка Основные тенденции российского рынка компьютерных игр [128]:

1. Основное направление – казуальные игры. Платформы для за пуска игр – персональный компьютер, мобильные устройства, игровые карманные консоли.

2. Игры для персонального компьютера – это игры от случая к случаю, причина – неготовность модифицировать систему специально под игры (мнение Александра Лысковского, гене рального директора компании «Alawar Entertainment»).

3. Игровая функция персонального компьютера отходит к консо ли, тем не менее, Россия – страна персональных компьютеров (мнение Алексея Бадаева, директора департамента по про движению программно-аппаратных развлекательных плат форм «Microsoft» в России).

1.3.2. Проблемы развития Далее представлены проблемы развития рынка игрового про граммного обеспечения, согласно данным информационно аналитического обзора, проведнного в департаменте аналитики «Интегрум» [124]:

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

2. Кризис творческой составляющей (по мнению потребителей).

3. Препятствия к развитию – отсутствует качественное содержи мое, способное мотивировать пользователей на материаль ную поддержку производителя.

В перспективе – политические заказы на игровые решения.

Предполагаемые исполнители заказов – отечественные разработ чики. Требования: информационная составляющая, соответствие планам руководства страны в области модернизации экономики, развития инновационных производств.

1.3.3. Тенденции развития Тенденции развития рынка игрового программного обеспечения [122;

125]:

1. Быстрорастущий сегмент рынка – «онлайн» игры и казуальные игры (по мнениям Алисы Чумаченко, директора по маркетингу и рекламе в «ИТ-территория» и Александра Лысковского, пре зидента компании «Alawar Entertainment»). Успех казуальных игр связан с доступностью для широкой аудитории и простоты входа в игру.

2. Доля на рынке игрового программного обеспечения казуаль ных игр вс ещ мала, объм прежний, но цена растт (по мнению Александра Михайлова, генерального директора компании «Бука»).

3. Снижение доли пиратства, рост цен, объма и качества про дуктов, незначительный объм казуальных и мобильных игр (по оценке Сергея Опарина, заместителя гендиректора ЗАО «ФИ НАМ»).

1.4. Рынок обучающего игрового программного обеспечения 1.4.1. Игровое обучение Препятствия на пути к развитию рынка игрового обучающего про граммного обеспечения [182] представлены далее.

Приемлемость:

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

2. Интеллектуальная разница. Преподаватели и ученики думают по-разному. Это связано с различием в языке и ценностях.

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

4. Неприязнь к играм. Информационная система должна позво лять смену игрового формата на классический формат обу чения.

5. Замедление процесса обучения. Вопросы принадлежат кон цептуальному проектированию и планированию в учебном процессе.

Создание:

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

2. Выбор темы. Это может быть что угодно, для кого угодно и в ка кое угодно время. Ограничение – доступные ресурсы.

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

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

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

1.4.2. Серьзные игры Особенность отрасли:

1. Государственная поддержка в развитых странах [123]. В Брита нии, например, создан институт «Serious Games Institute», куда были приглашены компании-разработчики серьзных игр. Во Франции осуществляются госзаказы. А в Германии есть сеть по продвижению серьзных игр [191].

2. Существует ошибочное мнение, что корпоративные клиенты не нуждаются в звуке, им достаточен средний уровень графи ки [132]. В качестве причин выделяют – каналы со слабой про пускной способностью, слабые персональные компьютеры, слабые видеокарты, отсутствие звукового оборудования.

3. Главные вопросы – сложность содержательной стороны, объ м базы знаний в игровом процессе, длительность игры.

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

Компании, представленные на мировом рынке электронно го игрового обучения [182]: «Games2train.com» [171], «The Thiagi Group» [198], «Imparta» [175], «LearningWare» [177], «MAK Technolo gies» [200], «Management: Possible» [181], «Monte Cristo» [197], «Ninth House Networks» [185], «SimuLearn» [194], «Transmedia» [199]. На рос сийском рынке можно выделить компанию «VE Simulation» [133].

1.5. Жизненный цикл программных проектов 1.5.1. Составляющие 1. Концептуальный и системный анализ. Исследование и описа ние основных концепций, анализ объекта и среды разработки.

Определение потребностей, разработка требований.

2. Проектирование и разработка. Детализация проекта и разра ботка. Планирование, оценка рисков, технико-экономический анализ и обоснование проекта. Разработка компонентов и их интеграция.

3. Проверка. Испытания системы. Верификация, тестирование, сертификация.

4. Поставка и сопровождение. Документирование. Создание и производство. Маркетинг, подготовка к продаже. Распростра нение и продажа. Эксплуатация. Сопровождение и монито ринг. Управление конфигурацией и изменениями.

5. Снятие с эксплуатации. Прекращение работы над проектом.

1.5.2. Стандарты Назначение стандартизации:

1. Концентрация опыта и знаний.

2. Повышение производительности труда, качества продукции.

3. Увеличения экономической эффективности процесса.

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

Виды стандартов:

1. Международные. Это в первую очередь стандарты, охваты вающие весь жизненный цикл – «ISO» (стандарты Международ ной организации по стандартизации) [176] и «IEEE» (стандарты Института инженеров по электротехнике и электронике) [173], а также стандарты/модели управления процессом разработ ки – «CMM», «CMMI» (разработаны в Институте программной инженерии) [193].

2. Отечественные. Стандарты «ГОСТ ЕСПД» (Единая система программной документации) [156].

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

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

1.5.3. Модели процессов 1. Каскадная (водопадная) модель. Суть – однократное выполне ние этапов, переход к следующему этапу возможен только после того, как будет полностью выполнен предыдущий. Более распространн вид с обратной связью, где есть возможность вернуться к предыдущему этапу.

2. Эволюционная. С точки зрения развития программных средств, часто называется инкрементной, с точки зрения структуры жиз ненного цикла программного обеспечения – итеративной. На практике используется в контексте спиральной метамодели, которая позволяет вмещать в себя различные технологии и процессы, перечисляемые далее. Унифицированный про цесс «UP» (Unified Process) [41] и его разновидности: унифици рованный процесс компании Rational «RUP» (Rational Unified Process), корпоративный унифицированный процесс «EUP» (En terprise Unified Process) [40]. Архитектура, управляемая моде лью «MDA» (Model-Driven Architecture) [99]. Гибкие/динамичные подходы, объединнные названием «Agile» (Agile Software De velopment) [52]), такие как методология управления проектами для гибкой разработки программного обеспечения «Scrum», экстремальное программирование «XP» (Extreme Program ming), методология «Crystal Clear», адаптивное программиро вание (Adaptive Software Development), методология «DSDM»

(Dynamic System Development Method) и функционально ориентированная разработка (Feature-Driven Development).

3. Гибридная. Сочетает в себе особенности представленных вы ше моделей.

1.6. Программная инженерия 1.6.1. Задачи 1. Обеспечение эффективности жизненного цикла программ ного обеспечения.

2. Оценка рентабельности технологии создания программного обеспечения.

3. Обеспечение качества процесса и результатов разработки.

4. Сокращение дефектов и неопределнности в проектах про граммного обеспечения.

1.6.2. Методы 1. Оценка качества, наджности, в первую очередь, выраженную в безопасности, работоспособности, безотказности и защи щнности [83].

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


1.6.3. Цели 1. Создание, проектирование и разработка программного обеспечения.

2. Поддержка технологического процесса разработки.

3. Предоставление методов конкретной технологии создания продуктов.

4. Обеспечение технологии создания программного обеспече ния.

1.6.4. Субъекты и объекты Субъекты программной инженерии [63]:

1. Разработчики-практики, группы и отдельные е члены.

2. Исследователи.

3. Исполнители научных проектов и опытно-конструкторских ра бот.

Объекты программной инженерии [48;

85]:

1. Продукт.

2. Проект.

3. Процесс.

4. Персонал.

1.6.5. Продукт и проект Типы характеристик продукта:

1. Общие: размер, сложность.

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

3. Экономические. Пример – распространение тиража.

Малые проекты Малые проекты характеризуются небольшим количеством испол нителей проекта, обычно это один единственный разработчик или коллектив из 3 – 5 человек [65]. Цель процесса создания малых систем – получить функционирующую программу, обычно это ав томатизация простых процессов и научных исследований [63].

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

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

Составляющие продукта Составляющие продукта – архитектура системы, компоненты и ин терфейсы.

Компоненты программного средства бывают общими (обычно 20% всей системы), предметно/проблемно-ориентиро ванными (65%), кодом приложения (15%) [61]. К общим компонен там относят абстрактные типы данных, функционал общего назна чения (горизонтальный домен), сюда входят математические функции и средства создания интерфейса пользователя. Значе ние общих компонентов – расширение языка программирования.

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

Виды повторно используемых активов:

1. Спецификации требований. Повторному использованию в данном контексте доступны представление структуры и опи сание функционала, а также нотация, натуральный или фор мальный язык. Интерес – описание всей системы или е части.

2. Проект. Модель описания проблемы. Решения – архитектура, шаблоны.

3. Тестовые данные. Множество входных данных и инструментов для запуска тестов.

4. Документация. Документированные активы, структура доку ментов.

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

6. Компоненты. Исполняемый код, оптимизированный функцио нал, информация о структуре, язык программирования.

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

1.6.7. Требования программной инженерии Виды требований:

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

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

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

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

5. К эргономическим требованиям относят требования к ком фортному обучению, упрощнному доступу к функциям сис темы и получению от не результатов, требования наглядности и выразительности пользовательского интерфейса [88], вопро сы восприятия времени [79].

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

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

Требования к проектам критических систем – ответствен ность за качество процесса создания и результата. Необходимо применять соответствующие меры. Это меры, направленные на обеспечение непрерывного обучения, совершенствования, повы шения квалификации не только разработчиков, но и заказчиков и пользователей, освоение методов, процессов и международных стандартов, а также обеспечение высокой культуры коллектива [65].

Программная инженерия применима как к малым, так и к средним и большим проектам. Главное требование – адаптация стандартов, технологии и инструментария под специфику проек та.

1.7. Программная инженерия на базе повторного использования артефактов разработки Опорой практики повторного использования является опыт прошло го. Цель практики – передача опыта. Характеристики повторного использования – систематичность и независимость. Систематич ность вступает в противоположность со случайностью и достигает ся за счт учта использования в будущем оформленных компо нентов. Независимость проявляется в разделении процесса раз работки компонентов и процесса их использования в производст ве программного обеспечения.

Возможные риски – производительность разработчиков и ка чество модифицированного повторно используемого актива.

1.7.1. Заинтересованные лица 1. Корпоративное управление является основным инициатором и проводит мониторинг затрат и выгод [77].

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

3. Инженеры-разработчики производят приложения и осуществ ляют повторное использование активов.

1.7.2. Организация процесса Специалисты предметной области и часть инженеров разработчиков проводят анализ и инженерию предметной облас ти, решают вопросы получения повторно-используемых активов, производят их классификацию и сопровождение. Инженеры вы полняют разработку на основе доступных активов. Если доступных активов нет – решается вопрос об их создании.

Этапы разработки:

1. В ходе анализа предметной области изучаются существую щие приложения, проводится сортировка по общим и изме няющимся характеристикам.

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

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

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

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

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

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


Условия достижения качества:

1. Компоненты протестированы.

2. Компоненты сертифицированы (в идеальном случае).

3. Компоненты поддерживаются производителем и/или сообще ством.

1.7.5. Уровни повторного использования Уровни повторного использования [101]:

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

2. На организационном уровне интерес представляют дисципли на и мастерство.

3. Уровень инструментов управления имеет дело с планирова нием, контролем и оценкой.

1.7.6. Требования повторного использования Элементы, необходимые для внедрения в процесс разработки практики повторного использования:

1. Готовые, апробированные активы.

2. Дисциплина проектирования, процедуры и рекомендации.

3. Критерии оценок характеристик качества, методы сбора по казателей, метрические системы.

4. Тщательное планирование, реалистичные ожидания, учт дол говременной перспективы.

1.7.7. Подходы к организации Согласно [51] повторное использование началось в виде использо вания подпрограмм на мэйнфреймах в 1950 годы. В качестве примера можно привести библиотеку «Share», которая, по сути, была первым свободным программным обеспечением с откры тым исходным кодом, представляющим собой набор повторно используемых элементов.

Подходы к управлению [101]:

1. Подход на основе объектно-ориентированных техник «REBOOT»

(Reuse based on Object Oriented Techniques). Акцент – на объе динение технологий и интеграцию технических и управленче ских аспектов. Составляющие методологии выражены дейст виями, ролями и моделями. Действия – запуск программы по вторного использования, стратегический анализ, технико экономический анализ и обоснование, планирование вне дрения, внедрение, контроль. Роли – инициатор, инвестор, за интересованная группа экспертов, посредник и ответственный за реализацию. Модели – рыночная стратегия, бизнес-цели, экономическая эффективность, реализация. Задачи методо логии – организация, управление проектом разработки, повы шение эффективности, разработка активов и разработка на основе активов, управление активами, измерение процесса и продукта. Организация предполагает распределение обязан ностей и рабочей силы, систему отчтностей и поощрения.

Типы организации – проект-ориентированная, продукт ориентированная, домен-ориентированная (группа, ориенти рованная на предметную область). В первом случае повтор ное использование происходит случайно и зависит от опыта прошлых проектов, во втором случае вопросы повторного ис пользования делегируются отдельной команде, как и в послед нем случае, в котором помимо прочего ещ учитывается оп ределнная предметная область. Для подхода «REBOOT» ха рактерны долгосрочный период получения выгоды и большие затраты.

2. Подход «NTT» (Nippon Telegraph and Telephone Corporation).

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

Комитет проводит измерение разработки активов и их исполь зования. Подход «NTT» – подход, который был проверен на прак тике, основные выводы, которые были сделаны теми, кто его использовал следующие:

чем уже тематическая область, тем выше степень повтор ного использования;

чем больше разработок, проектов, активов было произве дено в прошлом, тем выше экономическая эффектив ность;

точные временные оценки удатся получить, только если были проведены учт и планирование определнного пе риода времени;

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

оправдано целевое создание активов, нежели спонтан ное;

адекватные метрики влияют на адекватный контроль стои мости, выручки и процесса;

гарантия успеха достигается при условии наличия главного ответственного лица.

Инициативы [101]:

1. В области активов выделяют:

2.1. Инициатива «CARDS» – модель-ориентированный подход использования и создания библиотек и инструментов. По следователи инициативы – объединение «NPLACE» (National Product Line Asset Center), занимающееся инженерией ли неек программных продуктов, исследующее вопросы общей архитектуры и повторно используемых активов, предоставляющее веб-ориентированное хранилище.

2.2. Инициатива «DSRS» предполагала создание специальных центров «SRSCs» (Software Reuse Support Centers), в обязан ность которых входит хранение и распространение акти вов. Активы представлены в форме требований, специфи каций, архитектуры, проектов, исходного кода, документа ции, тестовых наборов. Предполагаемые предметные об ласти – коммерция, армия, государство, общественный сектор.

2. В области методологии выделяют:

2.1. В рамках инициативы «SRI» предполагается поддержка все го жизненного цикла программного обеспечения. Оказа лась предвидением для предметно-ориентированных, ар хитектурно-центрированных, процесс-ориентированных и автоматизированных подходов. Акцент ставится на созда ние линеек программных продуктов. Ключевые элементы – инженерия предметной области и инженерия приложе ний. В рамках инженерии предметной области предпола гается анализ предметной области, е моделирование, разработка архитектуры, организация и хранение активов, определение механизмов разработки на основе активов.

2.2. В инициативе «SORT» инженерия предметной области предполагает следующие действия – выбор потенциально эффективных предметных областей, создание/выбор тех нологий, производство активов. Подходы – на основе моде лей и предметно-ориентированные. Инженерия предмет ной области оказывает влияние на перенос технологий в сферу интересов (определнную область), акцент дела ется на линейках программных продуктов.

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

2.4. Инициатива «FAST» делает акцент на работу с семейством программных средств. Основные действия – поиск абст рактных механизмов для изменения планов и отражения в структурах компонентов систем, трансляция абстракций с помощью генераторов и языков для спецификации и мо делирования членов семейств.

2.5. Инициатива «SRBF» представляет собой набор моделей и рекомендаций. Направленность – объектно ориентированные системы. Процессы: инженерия компо нентов систем, типов, классов, рабочих продуктов;

инже нерия семейства программных средств, решение архи тектурного вопроса;

инженерия приложений, выбор, спе цификация и состыковка компонентов.

3. В области стандартов выделяют инициативу «RLIG» (Reuse Li brary Interoperability Group). В рамках инициативы происходит подготовка черновиков стандартов, закрепление стандартов организацией «IEEE», поиск механизмов функциональной со вместимости активов.

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

2. Технические аспекты делятся на инженерию предметной об ласти, инженерию компонентов и инженерию приложений.

Инженерия предметной области занимается анализом и оп ределением границ предметной области. Решает вопрос общей архитектуры, активов и средств их приспособления.

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

3. С экономическими аспектами связаны вопросы измерения, обоснования и документирования. Е основные категории – метрики программного обеспечения, оценка стоимости, рен табельность капиталовложений.

1.8. Предметно-ориентированное моделирование 1.8.1. Архитектура Уровни архитектуры проектного решения в рамках предметно ориентированного моделирования [84;

97]:

1. Предметно-ориентированный язык (Domain-Specific Langu age). Здесь преобладают концепции и правила предметной области. Концепции – объекты предметно-ориентированного языка. Все остальные элементы – свойства этих объектов. Язык специфицируется метамоделью, имеет определнную нота цию и может поддерживаться специальными средствами.

2. Генератор. Каждый символ для отображения моделей на предметно-ориентированный язык соответствует телу опреде лнного кусочка программного кода. Свойства объектов символов – характеристики этого кусочка. Предметно ориентированный язык задат соответствие, генератор автома тизирует процесс сопоставления (операция порождения).

3. Каркас (англ. – framework, в терминах системной и про граммной инженерии [43], может называться стилем, однако в контексте предметно-ориентированной разработки, это слово целесообразней переводить, как каркас или архитектурная среда, т.к. это, не смотря на совокупность характеристик, вс же материализованный в программном коде элемент, к кото рому добавляется дополнительная спецификация). Каркас предоставляет интерфейс между кодом на предметно ориентированном языке и лежащей под ним (каркасом) про граммной платформой. Каркас позволяет избежать дублиро вания кода.

Каждый уровень можно модифицировать по отдельности.

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

1.8.2. Особенности Процесс получения конечной программы:

1. Генератор получает на вход модель, специфицированную в терминах предметно-ориентированного языка.

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

3. Полученный исходный код передатся компилятору соответст вующего языка программирования.

Каркас и генератор программного кода – сосредоточение экспертных знаний. Язык – средство управления экспертными зна ниями.

Фокус предметно-ориентированного проектного решения – узкая область интереса. Такие решения инкапсулируют знания об архитектурных правилах построения приложений и модели про граммирования.

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

1.8.3. Новизна подхода Последовательность традиционной разработки: осмысление при ложения в терминах предметной области, перевод осмысленного на язык программирования, реализация намерения на языке про граммирования. Использование проектного решения позволяет объединить первые два шага, а при наличии генератора – автома тизировать третий шаг. Получаемый на практике сгенерированный код – функциональный, читаемый и эффективный, потому что оп тимизация происходит на самом высоком уровне – уровне пред метной области.

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

Проектные решения не подходят для краткосрочных проек тов, они создаются для проектов, имеющих долгий срок разработ ки (с риском непредвиденных изменений в требованиях пользова телей) и ещ более длинный период сопровождения. Фокус ис пользования предметно-ориентированного языка – указать на то, в чм программные средства отличны, фокус создания каркаса – зафиксировать программно неизменные характеристики, общие для всех программных средств предметной области. На практике специалисты предметной области, не являющиеся программи стами, должны быть в состоянии составить спецификации про граммного средства на предметно-ориентированном языке. Идеи и намерения специалистов, пользующихся предметно ориентированным языком, могут быть оформлены в виде текста, таблиц и диаграмм. Использование предметно-ориентированного языка самого по себе способствует эффективной коммуникации пользователей и разработчиков.

1.8.5. Сопровождение Изменению могут подвергаться как генератор, так и предметно ориентированный язык.

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

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

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

1.8.6. Преимущества подхода Главный фактор – рыночная ситуация.

Преимущества предметно-ориентированного моделирования:

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

2. Более совершенная обратная связь с разработчиками, т.к.

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

3. Сокращается стоимость разработки в целом.

4. Менее болезненная реакция на изменения требований поль зователей.

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

6. Меньше причин для передачи разработок частей системы подрядчикам.

7. Изоляция предметной области от области реализации спо собствует сокращению времени адаптации разработчиков программного средства к новым проектам и предъявляет к ним меньшие требования.

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

Ресурсомкие подходы заменяются высокоуровневыми и более автоматизированными. Оправдан и не является исключи тельным подход, когда один или два опытных инженера разработчика создают проектное решение и десятки, а то и сотни человек применяют в работе над одним проектом эти решения [97].

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

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

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

1.9. Средства для моделирования и разработки Согласно [53;

65;

70;

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

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

49;

53]. В моделях отображаются общие очертания программных единиц. Каркасы определяют характер ные для программных единиц повторно-используемые абстрак ции. Предметно-ориентированные языки делают процесс работы с этими абстракциями производительным, а шаблоны повышают эффективность процесса, ограничивая возможность совершения некорректных действий, и указывая верный путь работы с абстрак циями. Добавив к этому автоматические программные инструк ции, оказывающие помощь разработчикам, непосредственно во время создания программного средства, можно объединить вс вместе в специальный пакет, расширяющий возможности интег рированной среды разработки. К примеру, среда «Microsoft Visual Studio 2010» имеет в свом арсенале все необходимые для рас ширения средства, включая специальные шаблоны проектов. Есть нечто подобное и в средах «IDE Eclipse» и «Embarcadero RAD Studio».

1.9.1. Инструменты разработки Типы инструментов разработки:

1. Модели [41;

91;



Pages:   || 2 | 3 | 4 |
 





 
© 2013 www.libed.ru - «Бесплатная библиотека научно-практических конференций»

Материалы этого сайта размещены для ознакомления, все права принадлежат их авторам.
Если Вы не согласны с тем, что Ваш материал размещён на этом сайте, пожалуйста, напишите нам, мы в течении 1-2 рабочих дней удалим его.