Использование элементов Microsoft Solutions Framework в курсовом проектировании

Educational Technology & Society 8(3) 2005 ISSN 1436-4522

Использование элементов Microsoft Solutions Framework в курсовом проектировании

А.В. Бабич

кафедра математического анализа и информатики Полтавский государственный педагогический университет им. В.Г. Короленко,

Полтава, Украина, предметная комиссия дисциплины «Программирования для ЭВМ и АС» Полтавский политехнический колледж Национального технического университета

«ХПИ», Полтава, Украина alexander.babich@rambler.ru

АННОТАЦИЯ

MSF (Microsoft Solutions Framework) - это методология разработки ПО, идеология управления проектами от Microsoft. MSF предлагает проверенные методики планирования, проектирования, разработки и внедрения успешных IT-решений. Благодаря своей гибкости, масштабируемости и отсутствию жестких инструкций MSF способна удовлетворить потребности проектных групп любого размера. В статье изложены некоторые результаты практических исследований автора в области организации работы студентов над выполнением курсового проекта с использованием распределенного командного подхода и модели проектной группы MSF, предлагаются практические методики планирования и контроля над выполнением курсового проекта. Исследования проводились на базе Полтавского политехнического колледжа НТУ «ХПИ» в рамках курсового проекта дисциплины «Проектирование автоматизированных информационных систем». В работе также дан краткий обзор известных автору аналогичных исследований, описаны основные принципы, модели и дисциплины MSF, перспективы и направления будущих исследований автора и других участников образовательного проекта «Виртуоз», который проводился в августе-декабре 2004 г. в Нижегородском государственном университете по инициативе Intel и при поддержке Microsoft, IBM, Borland, Лаборатории Касперского и др.

Ключевые слова

Microsoft Solutions Framework, разработка ПО, курсовое проектирование, проект «Виртуоз», Intel.

Введение

Аббревиатура MSF знакома далеко не каждому, поэтому первый вопрос, который может возникнуть у читателя - что же такое MSF? Попробуем ответить. В 1994 году, стремясь достичь максимальной отдачи от IT-проектов, Майкрософт выпустила в свет пакет руководств по эффективному проектированию, разработке, внедрению и сопровождению решений, построенных на основе своих технологий. Эти знания базируются на опыте, полученном Майкрософт при работе над большими проектами по разработке и сопровождению программного обеспечения, опыте консультантов Майкрософт и лучшем из того, что накопила на данный момент IT-индустрия. Все это представлено в виде двух взаимосвязанных и хорошо дополняющих друг друга областей знаний: Microsoft Solutions Framework (MSF) и Microsoft Operations Framework (MOF).

MOF призван обеспечить организации, создающие критически важные (mission-critical) IT-решения на базе продуктов и технологий Майкрософт, техническим руководством по достижению их надежности (reliability), доступности (availability), удобства сопровождения (supportability) и управляемости (manageability). MOF затрагивает вопросы, связанные с организацией персонала и

процессов; технологиями и менеджментом в условиях сложных (complex), распределенных (distributed) и разнородных (heterogeneous) IT-сред. MOF основан на лучших производственных методиках, собранных в IT Infrastructure Library (ITIL), составленной Central Computer and Telecommunications Agency - Агентством правительства Великобритании. Информация по MOF доступна в Internet по адресу http://www.microsoft.com/mof/.

Создание бизнес-решения в рамках отведенных времени и бюджета требует наличия испытанной методологической основы. MSF предлагает проверенные методики для планирования, проектирования, разработки и внедрения успешных IT-решений. Благодаря своей гибкости, масштабируемости и отсутствию жестких инструкций MSF способен удовлетворить нужды организации или проектной группы любого размера. Методология MSF состоит из принципов, моделей и дисциплин по управлению персоналом, процессами, технологическими элементами и связанными со всеми этими факторами вопросами, характерными для большинства проектов. Информация по MSF доступна в Internet по адресу http://www.microsoft.com/msf/.

MSF взрослеет и эволюционирует подобно другим продуктам Майкрософт. В 2002 году вышла версия MSF 3.0, а сейчас мы ждем выхода четвертой версии, бета релиз одной из ветвей которой (MSF for Agile Software Development) доступна для загрузки по адресу http://download.microsoft.com/download/f/f/6/ff6f7417-f1db-40c4-886f-19b092494085/MSFforAgileSwDevBeta.zip.

MSF также идеально подходит для организации деятельности студентов во время курсового проектирования, контроля над этим процессом, позволяет студентам получить реальные навыки бизнеса-анализа, проектирование, командной работы. Именно поэтому в методических указаниях к курсовому проекту по предмету "Проектирование ЛИС" автор рекомендует студентам использовать некоторые шаблоны, модели и принципы MSF. В рамках такого подхода порядок выполнения курсового проекта (работы) может включать групповую работу над проектом с выделением ролевых кластеров, планирование с заполнением шаблонов документов MSF, итеративную разработку, еженедельные отчеты о ходе работ и т.п.

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

Обзор MSF

MSF состоит из двух моделей и трех дисциплин. Они подробно описаны в 5 whitepapers (Microsoft, 2004). Начинать изучение MSF лучше с моделей, а затем перейти к дисциплинам.

Модели MSF Дисциплины MSF

- модель проектной группы - управление рисками

- модель процессов - управление проектами

- управление подготовкой

Модель проектной группы

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

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

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

Ниже описываются основные принципы, ключевые идеи и испытанные методики MSF в применении к модели проектной группы.

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

1. Распределение ответственности при фиксации отчетности

2. Наделяйте членов команды полномочиями

3. Концентрируйтесь на бизнес-приоритетах

4. Единое видение проекта

5. Проявляйте гибкость - будьте готовы к переменам

6. Поощряйте свободное общение

Успешное использование модели проектной группы MSF основывается на ряде ключевых концепций (key concepts):

1. Команда соратников

2. Сфокусированность на нуждах заказчика

3. Нацеленность на конечный результат

4. Установка на отсутствие дефектов

5. Стремление к самосовершенствованию

6. Заинтересованные команды работают эффективно

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

Шесть ролевых кластеров модели проектной группы - это “Управление продуктом” (product management), “Управление программой” (program management), “Разработка” (development), “Тестирование” (test), “Удовлетворение потребителя” (user experience) и “Управление выпуском” (release management) (рис. 1). Они ответственны за различные области компетенции (functional areas) и связанные с ними цели и задачи. Иногда ролевые кластеры называются просто ролями. Но в любом случае суть концепции остается той же - построить основу производственных отношений и связанную с ней модель команды такими, чтобы они были приспосабливаемыми (масштабируемыми) для удовлетворения нужд любого проекта.

Рис. 1. Ролевые кластеры модели проектной группы MSF.

Как уже было сказано выше, проектная группа по MSF состоит из шести ролевых кластеров, каждый из которых отвечает за:

- управление программой (program manager) - разработку архитектуры решения, административные службы;

- разработку (developer) - разработку приложений и инфраструктуры, технологические консультации;

- тестирование (tester) - планирование, разработку тестов и отчетность по тестам;

- управление выпуском (release manager) - инфраструктуру, сопровождение, бизнесы-процессы, выпуск готового продукта;

- удовлетворение заказчика (user experience) - обучение, эргономику, графический дизайн, техническую поддержку;

- управление продуктом (product manager) - бизнес-приоритеты, маркетинг, представительство интересов заказчика.

Наличие шести ролевых кластеров не означает, что количество членов команды должна быть кратной шести - один человек может совмещать несколько ролей и наоборот, ролевой кластер может состоять из нескольких лиц в зависимости от размера проекта, его сложности и профессиональных навыков, требуемых для реализации всех областей компетенции кластера. Минимальный коллектив по MSF может состоять всего из трех человек. Модель не требует назначения отдельного сотрудника на каждый ролевой кластер. Смысл состоит в том, что в команде должны быть представлены все шесть качественных целей. Обычно, выделение как минимум одного человека на каждый ролевой кластер обеспечивает полноценное внимание к интересам каждой из ролей, но это экономически оправданно не для всех проектов. Зачастую члены проектной группы могут объединять роли.

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

1. Роль команды разработчиков не может быть объединена ни с какой другой ролью.

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

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

Знак “-” на пересечении столбца со строкой означает, что сочетание соответствующих ролей недопустимо, за исключением случаев, когда это абсолютно необходимо, и когда связанные с этим риски могут быть уменьшены эффективными планами их предотвращения и смягчения последствий. На практике совмещение ролей встречается нередко. И если проектная группа производит его обдуманно и управляет связанными с таким объединением рисками, возникающие проблемы будут минимальными.

Управление продуктом Управление программой Тестирование Удовлетворенио погрев иге ля Управление выпуском

Управление продуктом - - + + +

Управление программой - - + + +

Тостированио Удоялотяоромио потребителя Управление выпуском - - - - -

+ + - + +

+ + - + ±

+ + - + ± 1

+ Допустимо ± Нежелательно • Нельзя

Рис. 2. Объединение ролей в малых проектах.

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

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

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

Как следует из вышесказанного, одна из характерных особенностей MSF -отсутствие должности менеджера проекта!

Модель проектной группы MSF предлагает разбиение больших команд (более 10 человек) на малые многопрофильные группы направлений (feature teams). Эти малые коллективы работают параллельно, регулярно синхронизируя свои усилия (рис. 3). Кроме того, когда ролевому кластеру требуется много ресурсов, формируются т. н. функциональные группы (functional teams), которые затем объединяются в ролевые кластеры.

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

Рис. 3. Группы направлений.

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

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

Модель процессов

Модель процессов MSF (MSF process model) представляет общую методологию разработки и внедрения IT-решений. Особенность этой модели состоит в том, что благодаря своей гибкости и отсутствию жестко навязываемых процедур она может быть применена при разработке весьма широкого круга IT-проектов. Эта модель сочетает в себе свойства двух стандартных производственных моделей: каскадной (waterfall) и спиральной (spiral). Модель процессов в MSF 3.0 была дополнена еще одним инновационным аспектом: она покрывает весь жизненный цикл создания решения, начиная с его отправной точки и заканчивая непосредственно внедрением. Такой подход помогает проектным группам сфокусировать свое внимание на бизнес-отдаче (business value) решения, поскольку эта отдача становится реальной лишь после завершения внедрения и начала использования продукта.

Процесс MSF ориентирован на “вехи” (milestones) - ключевые точки проекта, характеризующие достижение в его рамках какого-либо существенного (промежуточного либо конечного) результата. Этот результат может быть оценен и проанализирован, что подразумевает ответы на вопросы: “Пришла ли проектная группа к однозначному пониманию целей и рамок проекта?”, “В достаточной ли степени готов план действий?”, “Соответствует ли продукт утвержденной

спецификации?”, “Удовлетворяет ли решение нужды заказчика?” и т.д.

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

Модель процессов MSF тесно связана со базовыми принципами MSF, рассмотренными выше. Вообще говоря, тремя особенностями модели процессов MSF являются:

- Подход, основанный на фазах и вехах.

- Итеративный подход.

- Интегрированный подход к созданию и внедрению решений.

Основные фазы и вехи модели процессов MSF показаны на рисунке 4. Кроме

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

- что (какие артефакты) является результатом этой фазы

- над чем работает каждый из ролевых кластеров на этой фазе

Рис. 4. Фазы и вехи модели процессов MSF.

В рамках программный код, документация, дизайн, планы и другие

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

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

Итеративный подход к процессу разработки требует использования гибкого способа ведения документации. “Живые” документы (living documents) должны изменяться по мере эволюции проекта вместе с изменениями требований к конечному продукту. В рамках MSF предлагается ряд шаблонов стандартных документов, которые являются артефактами каждой стадии разработки продукта и могут быть использованы для планирования и контроля процесса разработки.

Версия 1

Время

Рис. 5. Версионирование.

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

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

Управление рисками

Управление рисками (risk management) - это одна из ключевых дисциплин Microsoft Solutions Framework (MSF). MSF видит в изменениях и возникающей из-за них неопределенности неотъемлемые части жизненного цикла информационных технологий. Дисциплина управления рисками в MSF (MSF risk management discipline) отстаивает превентивный подход к работе с рисками в условиях такой неопределенности, непрерывное оценивание рисков и использование информации о рисках в рамках процесса принятия решений на протяжении всего жизненного цикла проекта. Данная дисциплина предлагает принципы, идеи и рекомендации, подкрепленные описанием пошагового процесса для успешного активного управления рисками. Этот процесс включает в себя выявление и анализ рисков; планирование и реализацию стратегий по их профилактике и смягчению возможных последствий; отслеживание состояния рисков и извлечение уроков из обретенного опыта. Девиз MSF - мы не боремся с рисками - мы ими управляем.

Управление проектами

Проект (project) - ограниченная временными рамками деятельность, цель которой состоит в создании уникального продукта или услуги. Управление проектами (project management) - это область знаний, навыков, инструментария и

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

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

А

Возможности

Рис. 6. Треугольник компромиссов.

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

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

Для иллюстрации использования матрицы компромиссов Майкрософт предлпгпет использовать следующее предложение (вместо пропущенных слов могут быть вставлены “календарный график”, “ресурсы” и “функциональность”):

«Зафиксировав _______________________________________, мы согласовываем _ и принимаем

результирующий______________».

Рис. 7. Матрица компромиссов.

Как уже говорилось выше, в MSF нет роли “менеджер проекта”. Деятельность по управлению проектом распределяется между лидерами групп и ролевым кластером “Управление программой”.

Для лидеров групп и ролевого кластера “Управление программой” инструментом управления проектом, облегчающим создание планов и календарных графиков, является WBS. Иерархическая структура работ (Work Breakdown Structure

- WBS) - это структуризация работ проекта, отражающая его основные результаты и определяющая его рамки. Работа, не описанная в WBS, находится вне границ проекта. В MSF создание WBS является коллективной деятельностью, в которую

вовлекаются все ролевые кластеры. Каждая роль ответственна за предоставление детального описания собственной работы.

Управление подготовкой

Управление подготовкой - это также одна из ключевых дисциплин Microsoft Solutions Framework (MSF). Она посвящена управлению знаниями, профессиональными умениями и способностями, необходимыми для планирования, создания и сопровождения успешных решений. Дисциплина управления подготовкой MSF описывает фундаментальные принципы MSF и дает рекомендации по применению превентивного подхода к управлению знаниями на протяжении всего жизненного цикла информационных технологий. Эта дисциплина также рассматривает планирование процесса управления подготовкой. Будучи подкрепленной испытанными практическими методиками, дисциплина управления подготовкой предоставляет проектным группам и отдельным специалистам базу для осуществления этого процесса.

В заключение этого краткого обзора следует отметить, что MSF не навязывает использование других продуктов Microsoft. Например, для организации процесса производства ПО можно использовать MSF и при этом применять инструменты Borland, хотя будущая версия MSF 4.0 будет жестко привязана к Microsoft Team System - новому инструментальному средству Майкрософт для поддержки командной работы над проектом.

Внедрение MSF в ВУЗе

Текущее состояние дел

В программе большинства ВУЗов СНГ, предлагающих обучение по специальностям, связанным с информационными технологиями, академические курсы по MSF представлены очень мало. Известно лишь несколько учебных курсов, касающихся MSF (ITLab, 2004), среди которых можно выделить:

- курс по MSF.NET - проект «Третья столица», разработанный в

Днепропетровском государственном университете при участии одного из «Виртуозов» Фирсова А. Д.;

- курс «Программная инженерия», разработанный в СПбУ А.А. Тереховым;

- в рамках образовательного проекта «Виртуоз» (Intel, 2005; А.В. Бабич,

2005), который проводился в августе-декабре 2004 г. в Нижегородском

государственном университете по инициативе Intel и при поддержке Microsoft, IBM, Borland, Лаборатории Касперского, коллективом авторов в числе которых был и автор этой статьи, был создан учебный курс «SE201: Введение в программную инженерию». Сейчас материалы этого курса используются, в частности, в рамках преподавания дисциплины «Технологии разработки ПО» в Полтавском политехническом колледже НТУ «ХПИ».

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

- «1846A: Microsoft Solutions Framework Essentials»

- «2710B: Analyzing Requirement and Defining Microsoft .NET Solution Architectures» (http://www.microsoft.com/traincert/syllabi/2710bfinal.asp).

Это действительно качественные и очень обширные курсы, которые к тому же включают замечательные упражнения и деловые игры. Часть из них была адаптирована автором для использования в рамках преподавания дисциплины «Технологии разработки ПО» в Полтавском политехническом колледже НТУ «ХПИ».

Литературы же, посвященной вопросу внедрения MSF в ВУЗах на данный момент очень мало, вернее, практически нет. Поиск публикаций на эту тему в ACM Digital Library не дал никаких результатов. Единственная известная автору работа такого рода - «Microsoft Solutions Framework на предприятиях и в вузах» (Павлов,

2004). В этом докладе сделан глубокий анализ текущего состояния дел касательно преподавания MSF в Вузах СНГ и использования этой методологии в курсовом и дипломном проектировании. Также даны некоторые рекомендации по организации учебного процесса с использованием MSF.

Автором этой статьи были опубликованы тезисы доклада об MSF (О.В. Бабич,

2005), которые, говоря без преувеличения, являются первой работой такого рода на украинском языке. Также совсем недавно вышла статья (О.В. Пащенко, 2005), написанная в плане апробации результатов дипломной работы «Microsoft Solutions Framework - методология разработки ПО от Майкрософт», выполняемой под научным руководством автора.

Что же касается практических исследований в области организации работы студентов с использованием распределенного командного подхода и модели проектной группы MSF, то данные исследования проводились автором на базе Полтавского политехнического колледжа НТУ «ХПИ» в рамках курсового проектирования дисциплины «Проектирование автоматизированных

информационных систем». Подобными исследованиями в Южно-Уральском государственном университете (г. Челябинск) занимается еще один «Виртуоз» -Цытович П.Л., причем результаты полученные нами во многом совпадают (доклад о части результатов этих исследований был сделан на 3-й открытой всероссийской конференции «Преподавание ИТ в России» http ://www.it-education. ru/).

Что конкретно делается

Автором были подготовлены методические рекомендации (О.В. Бабич, 2005) по выполнению курсового проекта дисциплины «Проектирование автоматизированных информационных систем», включая формализованное описание последовательности и содержания работ над проектом и создан веб-сайт (О. В. Бабич, 2005) со всеми необходимыми студентам материалами.

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

- систематизацию, закрепление и расширение теоретических знаний студентов;

- овладение навыками самостоятельной теоретической,

экспериментальной работы, работы с компьютерной техникой, использования СУБД, инструментальных систем, офисных пакетов и других прикладных программ;

- использование навыков планирования, документирования разработки и командной работы;

- качественное оформление работы.

Курсовой проект выполняется на ІІІ-м курсе на протяжении одного (6-го) семестра. Во время выполнения проекта студентам предлагается использовать элементы методологии Microsoft Solution Framework и пользоваться едиными шаблонами оформления проектной документации.

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

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

Тематика курсового проектирования должна быть актуальной, отвечать современным потребностям индустрии и бизнеса. Она должна быть разнообразной (разнообразие задач частично обеспечивается разной предметной областью задач и разным уровнем представлений студентов о ней). Краткость формулировки задания побуждает студентов к изучению предметной области задачи, более детальному осуществлению фазы планирования. Для выполнения задачи студенты могут объединяться у группы. Естественно, при таком подходе возникает потребность как-то организовать и распределить роли и активности, спланировать работу, в чем хорошо помогает Microsoft Solutions Framework. Пример задания: создать АИС для автоматизации учета обследований пациентов врачами поликлиники.

Срок выполнения работы - приблизительно 3 месяца (на протяжении семестра). Поскольку выполнение курсового проекта, как уже было сказано, предусматривает использование элементов MSF, работая над проектом, студент должен выполнить такую последовательность действий:

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

2. изучить предметную область задачи (~ 1 неделя), выделить:

a). основные объекты предметной области

b). их атрибуты

c). связи между ними

3. заполнить шаблон документа Vision Scope (~ 1-2 дня), то есть систематизировать и изложить свои общие представления о будущем проекте, его назначение, функциональность и т.д. Шаблоны всех необходимых документов можно загрузить с сайта для студентов (О.В. Бабич, 2005) или с сайта Майкрософт (Microsoft, 2004);

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

5. на основе планируемой функциональности будущей АИС выделить основные сценарии использования будущего программного средства (~ 2-3 дня) и изложить их, заполнив соответствующий шаблон документа (Usage scénarios);

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

7. на основе созданной документации разработать логический и физический дизайн будущей АИС

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

9. начать реализацию проекта в СУБД MS Access, MS Visual Fox, Fox pro (Fox base), в среде Delphi, Visual Basic, или языками программирования Borland Pascal, C++;

10. предоставлять руководителю проекта еженедельный (!) отчет о ходе выполнения работ;

11. предоставить созданное программное средство

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

12. обсудить результаты тестирования АИС с руководителем проекта и внести в него необходимые изменения;

13. создать инсталляционный пакет программы в Mstall Shield, Wise ІшММіоп system, !nnoSetup, GP frstall, Free Extractor или с помощью другого ПО;

14. оформить курсовой проект надлежащим образом и сдать все созданные материалы руководителю проекта (~2-5 дней);

15. защитить проект.

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

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

- качество доклада,

- умение четко и правильно отвечать на поставленный вопрос по теме проекта,

- качество оформления работы,

- качество созданного программного продукта.

Лучшие работы будут выставлены на сайте для студентов для всеобщего доступа, как примеры выполнения курсового проекта.

Теоретические знания по MSF, необходимые студентам для работы над заданием, они получают в ходе параллельных лекций по предмету «Технологии разработки ПО», где, как уже упоминалось выше, используются материалы, созданные «Виртуозами» для курса «SE201: Введение в программную инженерию». Некоторые практические навыки студенты могут почерпнуть из деловых игр курсов 1846А и 2710В, в которые они играют на практических занятиях той же дисциплины. Также студентам предлагаются дополнительные занятия по ПО для управления проектами и UML-проектированию. Также применяется методика интенсивного тренинга по объектно-ориентированному анализу и проектированию с UML -«Вавилонский эксперимент» (В.Л. Павлов, 2004), но это уже тема для отдельной статьи.

Анализ и оценка исследований

Конечно, это лишь первый опыт применения модели командной группы MSF для организации учебной деятельности студентов, используются лишь некоторые элементы MSF. Но даже этот первый опыт позволяет частично решить основную проблему IT-обучения в СНГ - отсутствие у студентов знаний индустриальных стандартов, навыков работы в команде и опыта участия в реальных проектах. Окончательные результаты исследований будут получены лишь в конце семестра (конец июня 2005г.), после подведения итогов защиты курсового проекта, но пока работа идет довольно успешно, студенты полны энтузиазма и с увлечением отдаются этой новой для них форме деятельности. Некоторые выгоды применение MSF сулит и преподавателям, например, упрощение процедуры контроля над выполнением курсового проекта (анализ созданной документации и еженедельных отчетов), повышение качества разрабатываемого ПО за счет более детально проработанной фазы планирования и т.д.

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

Что дальше? Перспективных направлений для будущих исследований достаточно много - это и переход на ожидаемую MSF 4.0, вернее, использование ее Agile-ветви, и пробы использования MS Team System 2005 и технологии MS SharePoint, и планы по локализации ПО и документации по MSF, и «приведение к общему знаменателю» MSF и «Комплекса стандартов и руководящих документов на автоматизированные системы» (т.н. 34-й ГОСТ) и многое другое...

Как уже упоминалось, все работы ведутся в тесном сотрудничестве с другими «Виртуозами» и их ВУЗами, особенно с ЮрГУ.

Заключение

В заключение следует сказать, что в современном образовательном стандарте ACM/!EEE Computing Curricula (IEEE/ACM, 2001) также указано, что преподавание следует строить таким образом, чтобы индустриальные стандарты, использовались везде, где это только возможно и чтобы студенты получили опыт их применения, даже притом, что подобные вопросы и не составляют фокус обучения. Итак, внедрение MSF в учебный процесс, даже пока что в таком ограниченном виде -значительный шаг вперед, который с одной стороны позволит студентам получить реальный значащий опыт, а с другой - упростит для преподавателя процедуру контроля над выполнением курсовых работ и повысит их качество.

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

Литература

[Microsoft, 2004] Microsoft Solution Framework Russian Page http://www.microsoft.com/rus/msdn/msf/default.mspx.

[ITLab, 2004] Курс SE201. Аналоги. Сайт ITLab Нижегородского государственного университета http://www.itlab.unn.ru/DesktopDefault.aspx?tabid=221.

[Intel, 2005] Официальный сайт проекта «Виртуоз» http ://curricula.ru/virtuo so/

[Бабич А.В., 2005] Бабич А.В. Неофициальный сайт проекта «Виртуоз»

http://barhan.poltava.ua/lug/Virtuoso

[Павлов В. Л., 2004] В. Л.Павлов. Microsoft Solutions Framework на предприятиях и в вузах.// Материалы доклада на 2-й ежегодной конференции "Преподавание информационных технологий в Российской Федерации" http://www.it-education.ru/reports/pavlov.htm

[Бабич О.В., 2005] Бабич О.В. «Використання елементів MSF при написанні курсових робіт з інформатики». // Матеріали щорічної звітної конференції викладачів, студентів та аспірантів ПДПУ - Полтава: ПДПУ, 2005.

[Пащенко О.В., 2005] Пащенко О.В. «Microsoft Solutions Framework» - методологія розробки ПЗ від Microsoft» . // Матеріали щорічної звітної конференції викладачів, студентів та аспірантів ПДПУ - Полтава: ПДПУ, 2005.

[Бабич О.В., 2005] Бабич О.В. «Методичні вказівки до виконання курсового проекту з дисципліни «Проектування АІС». - Полтава: ППК НТУ «ХПІ», 2005.

[Бабич О.В., 2005] Бабич О.В. Сайт «Сторінка для студента»

http://barhan.poltava.ua/lug/Students/

[Гайдамаки Н.А., 2002] Гайдамакин Н.А. Автоматизированные информационные системы, базы и банки данных. Вводный курс: Учебное пособие.- М.: Гелиос АРВ, 2002.

[Павлов В.Л., 2004] В.Л.Павлов. Вавилонский эксперимент.// Материалы доклада на 2-й ежегодной конференции "Преподавание информационных технологий в Российской Федерации" http://www.it-education.ru/reports/pavlov2.htm [IEEE/ACM, 2001] Русский перевод образовательного стандарта IEEE/ACM Computing Curricula 2001: Computer Science http://se.math.spbu.ru/cc2001